ウォーターフォールモデル

ウォーターフォールモデルは段階的に進めていくシステム開発の手法です。
特徴としては確実性を求めるために工程ごとにレビュー(成果物の確認)を行います。
文字通り「滝」を意味し、原則として前工程が完了しないと次工程には進みません。
すなわち、前工程への手戻りを最小限にします。今でも広く使われている手法の一つです。※工程にシステム移行、運用・保守を含まない場合もあります。

システム化する業務、範囲を明確にし、そのシステムに必要な機能や性能などを決定します。

システムのハードウェア・ソフトウェアの構成、手作業を設定します。

利用者の視点で、システムを構成するソフトウェアに求められる機能、能力、インタフェースなどを決定します。

決定したソフトウェア要件を開発者の視点から、どのように実現するかを決定します。

各プログラム内の構造設計を行い、ソフトウェア詳細設計書を作成します。

ソフトウェア詳細設計書に基づいてプログラミングを行います。

各テスト(単体・結合・総合・運用テスト)を行います。

テストが完了した後に、システムを本番の環境に移します。

実際に新システムを使用していて不具合があった場合は速やかに修正を行い、
新しい機能要求が挙がった場合には追加開発などを行ってシステムの保守をします。

ウォーターフォールモデルは、上流工程（要件定義）から確実に開発を進めていく手法です。
また、開発する内容やスケジュールをしっかりと決めてからプロジェクトが進みます。
そのため、プロジェクト全体の計画が立てやすく各工程ごとに区切り、承認後に次の工程に進むため、
工程ごとの成果物が確実に残り進捗管理しやすいです。
ウォーターフォールモデルでは、仕様変更をせずに済むように入念な要件定義をしなければなりません。
要件定義どおりにプロジェクトを進めれば、開発途中のリソースなどの管理もしやすいため、
スケジュールのズレも生じにくくなります。
そのため、適切な予定を組んで人員を割り当てることができ、大規模案件に向いています。
同じ理由から高い品質が求められるプロジェクトにも向いています。

ウォーターフォールモデルは基本”手戻り”は想定していない開発手法ですので、
テスト工程やリリース後に認識齟齬が発生した場合、
開発側に大きな負担がかかり納期遅延や予算超過に繋がってしまうことがあります。
更に、実際の開発が始まってからは仕様の変更を行いにくいため、
途中でユーザーの意見を取り入れることが難しいです。
よって、システムの仕様変更が発生する可能性が高い場合や短期間でリリースをして
ユーザーの反応を見たい場合には、ウォーターフォールモデルは向いていません。

システム開発手法の中でも有名なウォーターフォールモデルを説明させていただきました。
基本情報技術者試験やITパスポート試験でもよく出る問題です。
合格を目指して頑張りましょう。