実践ソフトウェアエンジニアリング 第3章 「規範的なプロセス」

• ウォーターフォールモデル
  • 古典的ライフサイクル
  • 問題点
    • やり直し・手戻りの危険性
    • 全ての要求を最初にまとめることは出来ない
    • 実際に動くアプリケーションはプロジェクトの後半まで入手できない
    • 開発者の待ち状態が多い
  • 要求が確定して順番どおりに作業が進められる場合は有効
• インクリメンタルプロセスモデル
  • インクリメンタルモデル
    • ウォーターフォールモデルの要素を繰り返し実行
    • 繰り返しアプリケーションを納品しユーザからのフィードバックを得る
  • RADモデル
    • 複数のチームが並行して開発を行う
    • コンポーネントや自動コード生成を重視
• 進化型プロセスモデル
  • プロトタイピング
    • プロトタイプを作成し、ユーザからのフィードバックを得る
    • プロトタイプの作成にはあまり手間や時間をかけない
    • 他のプロセスの一部としても用いられる
  • スパイラルモデル
    • 反復型のプロトタイピングモデルとウォーターフォールを結合させたモデル
    • リスク中心型のプロセスモデル
    • 徐々にシステムの定義と実装を拡大
    • 固定マイルストンを設定
  • コンカレント開発モデル
    • アクティビティの状態を管理する
  • まとめ(進化型プロセスモデル)
    • 継続的な変更、厳しいスケジュール、ユーザの満足に対応するため
    • 要求が決まっていないため計画を立てづらい
    • 高い品質ではなく柔軟性と拡張性・開発のスピードに焦点を当てるべき

なんか開発プロセス全体をカバーするプロセスと、プロセスの一部となる開発手法的なものがごっちゃになっているような気が…。
やっぱり進化型プロセスが良いけど、計画や見積もりがしにくいというところですねぇ。
品質よりも柔軟性と拡張性・開発のスピードを重視って、どこで見たか忘れたけど「リリースの遅れはすぐ忘れるが、品質が悪いのはずっと言われる」というのの正反対だな。どっちにしろ顧客との合意が無いと駄目なんだろうけど。
でもがんばってスケジュールに間に合わせてもすぐ忘れられるんだよなぁ…。不具合があっても致命的じゃなくてすぐ直せるんだったらそんなに目くじら立てなくてもと思うんだけど。お互いあら捜しやってるわけじゃないんだし。

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-