太田です。
濱井さん
>仕様通りに開発するという観点からは、仕様の固定は早ければ早いほど良い
>でしょうが、顧客の満足を高めるという観点からは、仕様の固定は遅ければ
>遅いほど良いことになります。
>イテレーション型ならウォーターフォール型の失敗が完全に防げるというわけ
>ではありませんが、その確率は下げることができます。
>
>
>ウォーターフォール型の開発が生き延びてきたのは、顧客の満足を高めること
>より、仕様通りに開発することが重視されてきたことに一因があるように
>思えます。
濱井さんはビジネス的視点からウォーターフォール型プロセスを批判なさっていま
すが，ソフトウェアの不具合に対する法的責任という観点からはどうでしょうか。
基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
http://www.amazon.co.jp/exec/obidos/ASIN/4822281132/ref=sr_aps_d_1_1/250-1701196-4274662
という本の第14章「ソフトウェアの不具合に対する法的責任」では請負契約における
法的観点からのウォーターフォール開発プロセスの利点について書かれています。
#この章を読むと明確な仕様と契約を締結せずに，ほいほい変更を受け入れていくと
開発者側が以下に大きなリスクを負うことになるかが身にしみます。
#ちなみに別の章を読むと作者のKanerさん自体はウォーターフォール開発プロセスよ
り進化型開発プロセスを推奨しているような感もありますが，最終的にはこれはプロ
ジェクトマネージャーがトレードオフを考慮して選択すべき問題だとしています。
おおた
_________________________________________________________________
友達とのチャットツール MSN メッセンジャーのダウンロードはこちら
http://messenger.msn.co.jp/