こんな仕様書は読む気がしない - rabbit2goのブログ
ソフトウェア開発において、受け取っても読む気が失せる仕様書の例： 文字ばかりで図表が無い 機械、電気、建築など他のエンジニアリングでは図面でのやり取りが普通なのに、ソフトウェア開発ではなぜ文章に頼った意思疎通が多いのだろうか？確かに文章にしなければ表現できない内容も有るけれど、UMLのような図面を使う方が一目で分かりやすいし、「全てのケースでの考慮漏れがないか？」を知るためには表を使って条件を網羅的に整理するのが確実だろう。文章だらけの仕様書は「何か記載されていない項目があるのではないか？」という疑いを晴らすことが出来ないように思う。 背景説明が無い やたらと詳細な仕様が書かれているのに、「全体構成」や「概要」が記載されていないので、一体何についての資料なのか全体像がなかなか理解できない。書き手にとっては「アタリマエ」のことだろうけど、それを読み手に伝えるのが仕様書の役割だろう。仕様書は、
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
仕様書をTracのWikiに記載する - rabbit2goのブログ
「仕様書をSubversionとTracで管理する」に続いて、今回は仕様書をTracのWikiで作成する話。 Tracの登場以前に、仕様をPukiwikiで書き始めたのがそもそも発端だけど、Wikiを使うメリットとして下記が挙げられると思う。 仕様同士のリンク 経験的に言って、仕様書は一つだけでは収まらないことが多い。関連する仕様として、仕方なくたくさんのファイルを作っていく事になるのだけど、数が増えると相互参照が大変な作業になる。この点、WikiならWebのリンクを辿るだけなので、情報へのアクセスが容易だ。 仕様の一意性確保 （社内サーバにて）一意のURLと仕様が紐づけられるので、仕様として意味するところを明確に指定できる。ファイルだとファイル名に整理用の数字を入れたり、最新版の資料の置き場所を常に意識しておく必要があった。 ファイルよりも更新が簡単 気分的なものが大きいかも知れないけど
仕様書をSubversionとTracで管理する - rabbit2goのブログ
議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、WordやExcelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。 仕様変更の確実な履歴管理 Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い（誰かが変更箇所を承認してしまった等）ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。 ソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
