滝モデル

ウォーターフォールモデルは、典型的なソフトウェア開発ライフサイクル（SDLC）の各フェーズを順番に実行するプロセスです。各フェーズは、次のフェーズを開始する前に完了し、各フェーズの結果が後続のフェーズを推進します。^{[ 1 ]}アジャイルなどの他のSDLC手法と比較すると、反復性と柔軟性が最も低いものの一つです。^{[ 1 ]}なぜなら、進行は、構想、要件分析、設計、構築、テスト、展開、保守の各フェーズを通して、ほぼ一方向に流れる（滝のように）からです。^{[ 2 ]} ウォーターフォールモデルは、最も初期のSDLC手法です。^{[ 3 ]} 最初に採用された当時は、知識ベースの創造的な作業に対する認識された代替手段はありませんでした。^{[ 4 ]}

ソフトウェアエンジニアリングにおけるこのようなフェーズの使用について説明した最初の既知のプレゼンテーションは、1956年6月29日にハーバート・D・ベニントンがデジタルコンピュータ向け高度プログラミング手法に関するシンポジウムで行ったものです。 ^{[ 5 ]}このプレゼンテーションはSAGE 用ソフトウェアの開発に関するものでした。1983年、ベニントンは、フェーズがタスクの専門化に従って意図的に組織化されていること、そしてプロセスは実際には厳密なトップダウン方式で実行されたのではなく、プロトタイプに依存していることを説明する序文を付けて、この論文を再出版しました。^{[ 6 ]}

論文では「ウォーターフォール」という用語は使われていませんが、このプロセスの最初の正式な詳細な図は、しばしばウィンストン・W・ロイスによる1970年の論文から引用されています^{[ 7 ]}。^{[ 8 ] [ 9 ] [ 10 ]}しかし、彼は、テストがプロセスの最後にしか行われないことに起因する重大な欠陥があるとコメントし、それを「危険で失敗を招く」と表現しました^{[ 8 ]} 。彼の論文の残りの部分では、変更されていないウォーターフォールアプローチに関連する「開発リスクのほとんどを排除する」ために必要だと彼が感じた5つのステップを紹介しました^{[ 8 ]} 。ロイスの5つの追加ステップ（開発のさまざまな段階で完全なドキュメントを作成することを含む）は主流にはなりませんでしたが、彼が欠陥のあるプロセスと考えていたものの図は、「ウォーターフォール」アプローチを説明する際の出発点となりました^{[ 11 ] [ 12 ] 。}

「滝」という用語が最初に使われたのは、ベルとセイヤーによる1976年の論文かもしれない。^{[ 13 ]}

1985年、米国国防総省は、ソフトウェア開発請負業者との作業に関するDOD-STD-2167規格でウォーターフォールモデルを採用しました。この規格では、ソフトウェア開発の反復^{[ 14 ]}を「ソフトウェア開発サイクルの連続するフェーズ」と呼び、「請負業者は、ソフトウェア要件分析、予備設計、詳細設計、コーディングと単体テスト、統合、テストの6つのフェーズを含むソフトウェア開発サイクルを実施しなければならない」と述べています。^{[ 14 ] [ 15 ]}

このモデルは、一連の手順を直線的に記述しています。さまざまなバージョンが存在しますが、以下にその本質を説明します。^{[ 16 ] [ 17 ] [ 18 ] [ 19 ]}

ソフトウェア開発サイクルの初期段階で時間を費やすことで、後の段階でのコストを削減できます。例えば、初期段階（要件定義など）で発見された問題は、プロセスの後半で発見された同じバグよりも修正コストが安くなります（50～200倍）。^{[ 23 ]}

一般的に、ウォーターフォール型開発手法では、プロジェクトスケジュールにおいて、最初の2つのフェーズに時間の20～40%、コーディングに30～40%、残りをテストと実装に費やすことになります。プロジェクト組織は高度に構造化される必要があるため、ほとんどの中規模および大規模プロジェクトには、プロジェクト上のすべてのプロセスを規制する詳細な手順と管理が含まれます。^{[ 24 ]}

ウォーターフォールモデルを支持するもう一つの論拠は、ソースコードだけでなく、ドキュメント（要件定義書や設計書など）にも重点を置いている点です。設計やドキュメント化が不十分な手法では、プロジェクトが完了する前にチームメンバーが離脱すると知識が失われ、プロジェクトがその損失から回復するのは困難になる可能性があります。完全に機能する設計書が存在する場合（これは、事前の大規模設計とウォーターフォールモデルの意図です）、新しいチームメンバーや新しいチームは、ドキュメントを読むことでプロジェクトに慣れることができるはずです。^{[ 25 ]}

ウォーターフォールモデルは構造化されたアプローチを提供します。モデル自体は、離散的で理解しやすく説明しやすいフェーズを直線的に進むため、理解しやすいです。また、開発プロセスにおける容易に識別できるマイルストーンも提供し、多くのソフトウェアエンジニアリングのテキストやコースで開発モデルの最初の例としてよく使用されます。^{[ 26 ]}

クライアントは、実際に動作するソフトウェアを見るまでは正確な要件を把握していない可能性があり、そのため後から要件を変更し、再設計、再開発、再テスト、コスト増加につながる可能性がある。^{[ 27 ]}

設計者は、新しいソフトウェア製品や機能を設計する際に、将来起こりうる困難を認識していない場合があります。その場合、新たに発見された制約、要件、または問題を考慮して設計されていないものと比較して、初期段階で設計を修正することで効率を高めることができます。^{[ 28 ]}

組織は、顧客からの具体的な要求が不足している場合、システムアナリストを雇用して既存の手動システムを調査し、その機能と置き換え方法を分析することで対処しようとすることがあります。しかし、実際には、システム分析とプログラミングを厳密に分離することは困難です。^{[ 29 ]}なぜなら、些細でないシステムを実装すると、システムアナリストが考慮していなかった問題やエッジケースが明らかになることが多いからです。

米国国防総省などの一部の組織は、1994年に発行されたMIL-STD-498を皮切りに、ウォーターフォール型の手法を好まないことを公言しており、進化的な取得と反復的かつ漸進的な開発を推奨している。^{[ 30 ]}

オリジナルの純粋なウォーターフォールモデルに問題があると認識されたため、その問題に対処するために多くの修正版が考案されました。これには、スティーブ・マコーネルが「修正ウォーターフォール」と呼ぶ高速開発モデルが含まれます: ^{[ 23 ]}ピーター・デグレースの「刺身モデル」（フェーズが重複するウォーターフォール）、サブプロジェクト付きウォーターフォール、リスク軽減付きウォーターフォール。また、「インクリメンタルウォーターフォールモデル」などの他のソフトウェア開発モデルの組み合わせも存在します。^{[ 31 ]}

ロイスの最終モデルは、フィードバックがコードテストから設計へ（コードテストによって設計上の欠陥が明らかになるため）、そして設計から要件仕様へと（設計上の問題によって、矛盾する要件や、その他の理由で満たされない/設計不可能な要件を削除する必要が生じる可能性があるため）つながる可能性があること を示しました。同じ論文でロイスは、大量のドキュメントを作成し、「可能であれば2回」作業を行うこと^{[ 32 ]}（ソフトウェアプロジェクト管理で影響力のある書籍である『人月の神話』の著者として有名なフレッド・ブルックスが提唱した「1つは捨てる」計画に似た考え方）、そして可能な限り顧客を巻き込むこと（エクストリームプログラミングに似た考え方）も提唱しました。

ロイスが最終モデルについて述べた内容は以下のとおりです。

1. 分析とコーディングを開始する前に、プログラム設計を完了してください。
2. 書類は最新かつ完全でなければならない。
3. 可能であれば、作業を2回行う。
4. 試験は計画、管理、監視されなければならない。
5. 顧客を巻き込む

ウィキメディア・コモンズには、ウォーターフォールモデルに関連するメディアがあります。

• ソフトウェア開発におけるウォーターフォールモデルの長所と短所を理解する
• プロジェクトライフサイクルモデル：その違いと使用タイミング
• フィリップ・クルーテン著『RUPと共に滝を越える』
• CSCとIBM Rationalが提携し、C-RUPを提供して迅速なビジネス変革を支援する
• c2:滝