ウォーターフォール法

要件から設計、実装、検証へと、段階の成果を確認しながら進める開発方式があります。
ウォーターフォール法（Waterfall method）は、主な開発活動を順序立て、前段階の成果を次段階の入力として扱うモデルです。
実際の手順には戻りや変更の扱いがあるため、一切の反復を認めない方法とだけ説明すると不正確になります。

段階を進める条件を決める

たとえば、既存設備へ接続する制御ソフトウェアを開発するとします。
接続する装置、入出力、性能の条件を確認し、設計へ渡す情報をそろえます。
設計を確認した後に実装し、条件を満たしたかを試験します。
各段階の完了条件、判断する人、保存する記録を明らかにすることで、受け渡しの認識を合わせます。

前提が安定しているかを調べる

接続先の仕様が明確でも、利用者の操作や例外の理解が十分とは限りません。
未確認の部分は試作品や事前試験で調べ、詳しく設計する前に疑問を減らします。
初期の文書が完成したことを、すべての要求が正しい証拠とは扱わないようにします。
後から誤りが見つかった場合に、影響する設計と試験を追える状態も必要です。

変更の影響を管理する

開発中に装置の仕様が変わったら、実装だけでなく、要求、設計、試験への影響を確認します。
変更を承認する人と、その条件を決め、関係する成果の版をそろえます。
必要な修正を禁止すれば品質が守られるとは限らず、逆に、記録なく変更すれば整合が崩れます。
何をいつ確定し、どう変更するかを共有する必要があります。

モデルを優劣で選ばない

NASAのソフトウェア工学資料も、すべての状況へ最適な単一のライフサイクルモデルはないと説明しています。
要求の変化、技術の不確実さ、検証と承認の条件に合わせて、進め方を選びます。
アジャイル製品開発と活動の目的がすべて異なるわけではなく、学ぶ間隔や変更の扱いに違いがあります。
投資判断の節目を持つステージゲート・プロセスとも、同じ方式だと決めつけないようにします。

参考資料