ホーム > 読んだ >

仕様変更に打ち勝つ
上流で固める仕様を絞り、変更前提の開発手法を取り込む

書誌

author森山徹
publisher日経 BP 社
year『日経オープンシステム 2002.4』p.94-115

目次

1感想
2抄録

履歴

editor唯野
2002.4.16読了
2002.4.16公開
2002.11.28修正

ソフトウェア開発における「仕様変更」はよくあることであり、既に仕様変更のないことを前提とした開発手法はありえない。個人的に日経オープンシステムは「おっ」と感じる特集でも実際に読んでみると総論的でいまいちという印象を抱くことが多い。実際のユーザ事例は非常にありがたいだけに、もう少し踏み込んだ内容だともっとよいのにと思う。

抄録

94-96

昨今の仕様変更の原因の多様化。特に新しい試みを行う際に仕様の詳細を後から詰めていく(詰めざるを得ない)という傾向が出てきている。当然、ウォーターフォール型では対応できないため、要求仕様よりも設計に時間をかけ、スパイラル型アプローチを取るといったスタイルが取られることになる。

  • 開発期間の短期化
  • 開発時に仕様を決める案件の増加
  • 外的要因による仕様変更の増加

96-99

上記の問題解決のポイントとして以下が挙げられる。かつ、それを短期間で成果として結実させる必要がある。もちろん、基本はユーザと SE のコミュニケーションであり、そこから仕様を肥大化させずに漏れをなくしていくということ。また、優先度によって範囲を絞り込むことも重要となる。一方、決定項目に関しては、変更の影響の大きくなるものを先に決めてしまい、GUI などは大体のところで開発に入るといった切り分けを行う。

  • 過不足のない仕様作りとユーザの合意を得る手法
  • 設計時の決定項目とそうでない項目の切り分け
  • 仕様変更を前提とした開発手法の整備

100-103

システム化の範囲を重要度で絞るのは仕様を肥大化させない上で有効な手段となる。(コア機能と周辺機能とに切り分けて、コア機能から着手するなど。)逆に入り込みやすい仕様として、既存システムの機能やレア・ケースをそのまま含めている場合などがある。これらはワークフローとして処理の流れを整理しユーザからの合意を得るというのが一般的な手段となる。レア・ケースの場合は費用対効果とシステム以外の代替手段の提示がポイントとなる。同時に判断しにくいものは後回しにするという切り分けも求められる。

全文を読まれる場合はログインしてください


Up