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

ウォーターフォールモデルは、開発活動を線形の連続フェーズに分割したものである。つまり、各フェーズは互いに引き継がれ、各フェーズは前のフェーズの成果物に依存し、タスクの特化に対応する。^{[1]このアプローチは、}エンジニアリング設計の特定の領域で一般的である。ソフトウェア開発では、^[1] 進行が主に一方向（ウォーターフォールのように下向き）に、構想、開始、分析、設計、構築、テスト、展開、保守のフェーズを流れるため、反復性と柔軟性の低いアプローチになる傾向がある。^{[2]ウォーターフォールモデルは、ソフトウェア開発で使用される最も初期のシステム開発ライフサイクル（}SDLC ）アプローチである。^[3]

ウォーターフォール開発モデルは、製造業と建設業で生まれました^[要出典] 。これらの業界では、高度に構造化された物理環境により、開発プロセスのかなり早い段階で設計変更に法外なコストがかかるようになりました^[要出典] 。このモデルがソフトウェア開発に初めて採用されたとき、知識ベースの創造的な作業に代わるものは認められていませんでした^{[4] 。}

歴史

ソフトウェア工学におけるこのようなフェーズの使用について説明した最初の発表は、1956年6月29日のデジタルコンピュータのための高度なプログラミング方法に関するシンポジウムでハーバート・D・ベニントンによって行われた。^{[5]この発表は}SAGE のソフトウェア開発に関するものだった。1983年にベニントンは序文を付けて論文を再出版し、フェーズはタスクの専門分野に応じて意図的に編成されており、プロセスは実際には厳密なトップダウン方式で実行されているのではなく、プロトタイプに依存していることを指摘した。^[6]^{[より良い情報源が必要]}

この論文では「ウォーターフォール」という用語は使われていないが、後に「ウォーターフォールモデル」として知られるプロセスの最初の正式な詳細図は、 1970年のWinston W. Royceの論文から引用されることが多い^[7]。^[8]^[9]^[10]しかし、彼は、テストがプロセスの最後にしか行われないことに起因する大きな欠陥があるとコメントし、それを「リスクが高く、失敗を招く」と表現した。^[8]彼の論文の残りの部分では、変更されていないウォーターフォールアプローチに関連する「開発リスクのほとんどを排除する」ために必要と思われる5つのステップを紹介した。^[8]

ロイスの5つの追加ステップ（開発のさまざまな段階で完全なドキュメントを作成することを含む）は、主流になることはありませんでしたが、彼が欠陥のあるプロセスとみなした図は、「ウォーターフォール」アプローチを説明する際の出発点となりました。^[11] ^[12]

「ウォーターフォール」という用語が最初に使われたのは、1976年にベルとセイヤーが発表した論文だったと思われる。^[13]^{[より詳しい情報源が必要]}

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

モデル

ロイスはウォーターフォールモデルを推奨も説明もしていないが、^[16]以下の段階に固執することは彼によって批判されている。

したがって、ウォーターフォールモデルでは、前のフェーズがレビューされ検証された場合にのみ、次のフェーズに進む必要があると主張しています。

しかし、さまざまな修正ウォーターフォールモデル（ロイスの最終モデルを含む）では、このプロセスにわずかな、または大きな変化が加えられることがあります。^[8]これらの変化には、下流で欠陥が見つかった後に前のサイクルに戻ることや、下流のフェーズが不十分であると判断された場合に設計フェーズに戻ることが含まれます。

支持する議論

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

一般的に、ウォーターフォール方式では、最初の 2 つのフェーズに 20～40% の時間を、コーディングに 30～40% の時間を、そして残りをテストと実装に充てるというプロジェクトスケジュールが立てられます。プロジェクト組織は高度に構造化される必要があるため、ほとんどの中規模および大規模プロジェクトには、プロジェクトのすべてのプロセスを規制する詳細な手順と制御のセットが含まれます。^[18]^{[検証失敗]}

ウォーターフォールモデルを支持するさらなる論拠は、ソースコードだけでなく、ドキュメント（要件ドキュメントや設計ドキュメントなど）も重視するという点である。^[要出典]設計とドキュメント化がそれほど徹底していない方法論では、プロジェクトが完了する前にチームメンバーが辞めた場合、知識が失われ、プロジェクトがその損失から回復することが困難になる可能性がある。完全に機能する設計ドキュメントが存在する場合（大規模な事前設計とウォーターフォールモデルの意図どおり）、新しいチームメンバーと新しいチームは、ドキュメントを読むことでプロジェクトに慣れることができるはずだ。^[19]

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

同様に、シミュレーションはウォーターフォールモデル内で重要な役割を果たすことができます。開発中のシステムのコンピューターシミュレーションまたは数学的シミュレーションを作成することで、チームは次のフェーズに進む前にシステムのパフォーマンスに関する洞察を得ることができます。シミュレーションにより、設計のテストと改良、潜在的な問題やボトルネックの特定、システムの機能とパフォーマンスに関する情報に基づいた決定が可能になります。

批判

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

設計者は、新しいソフトウェア製品や機能を設計する際に、将来の困難に気付いていない場合があります。その場合、最初に設計を修正することで、新たに発見された制約、要件、または問題を考慮して構築されていない設計と比較して効率が向上します。^[22]

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

アメリカ国防総省などの一部の組織では、1994年に発表されたMIL-STD-498を皮切りに、進化的取得と反復的かつ漸進的な開発を奨励するウォーターフォール型の方法論に反対する姿勢を表明している。^[24]

修正されたウォーターフォールモデル

「純粋な」ウォーターフォールモデルに見られる問題に対応して、多くの「修正ウォーターフォールモデル」が導入されました。これらのモデルは、「純粋な」ウォーターフォールモデルに対する批判の一部またはすべてに対処している可能性があります。

これらには、スティーブ・マッコーネルが「修正ウォーターフォール」と呼ぶラピッド開発モデルが含まれます。 ^[17]ピーター・デグレースの「サシミモデル」（重複するフェーズを持つウォーターフォール）、サブプロジェクトを持つウォーターフォール、リスク削減を持つウォーターフォール。「増分ウォーターフォールモデル」などの他のソフトウェア開発モデルの組み合わせも存在します。^[25]

ロイスの最終モデル

ウィンストン・W・ロイスの最終的なモデルは、彼が当初の「ウォーターフォールモデル」を改良したもので、フィードバックはコードテストから設計へ（コードテストで設計上の欠陥が明らかになるため）また設計から要件仕様へ（設計上の問題により、矛盾する要件や満たされない/設計不可能な要件の削除が必要になる可能性があるため）戻ることができる（べきであり、また往々にしてそうなる）ことを示した。^[要出典] 同じ論文でロイスは、大量のドキュメント作成、「可能であれば2度」作業を行うこと（ソフトウェアプロジェクト管理で影響力のある書籍「Mythical Man Month」の著者として有名なフレッド・ブルックスが「1つを捨てる」計画を立てることを提唱した考え方に似ている）、そして顧客を可能な限り関与させること（エクストリームプログラミングに似た考え方）も提唱した。

最終モデルに関するロイスのコメントは次のとおりです。

分析とコーディングを始める前にプログラム設計を完了する
文書は最新かつ完全でなければならない
可能であれば作業を2回行う
テストは計画、管理、監視する必要がある
顧客を巻き込む

参照

参考文献

^ ab Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). 「大規模開発におけるウォーターフォールモデル」。 Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (編)。製品重視のソフトウェアプロセス改善。ビジネス情報処理の講義ノート。第 32 巻。ベルリン、ハイデルベルク: Springer。 pp. 386–400。Bibcode :2009pfsp.book..386P。doi :10.1007/978-3-642-02152-7_29。ISBN 978-3-642-02152-7。
^ Tom Gilb . 「進化型デリバリーと「ウォーターフォールモデル」」「ACM SIGSOFTソフトウェアエンジニアリングノート. 10 (3): 49–61. doi :10.1145/1012483.1012490.
^ Linda Sherrell (2013). 「ウォーターフォールモデル」。科学と宗教の百科事典 (ALC Runehov、L. Oviedo (編))。ドルドレヒト、オランダ: Springer : 2343–2344。doi :10.1007 / 978-1-4020-8265-8_200285。ISBN 978-1-4020-8264-1。
^ Andreas P. Schmidt、Christine Kunzmann (2014 年 9 月 16 日)。知識成熟のための設計: 知識駆動型ソフトウェアから知識開発の促進のサポートまで。i-KNOW '14: 知識技術とデータ駆動型ビジネスに関する第 14 回国際会議の議事録。ACM。pp . 1–7。doi : 10.1145 /2637748.2638421。
^ 米国海軍数学計算諮問委員会（1956年6月29日）、「デジタルコンピュータの高度なプログラミング方法に関するシンポジウム」[ワシントンDC]：海軍研究局、海軍省、OCLC 10794738
^ Benington, Herbert D. (1983 年 10 月 1 日). 「大規模コンピュータプログラムの作成」(PDF) . IEEE Annals of the History of Computing . 5 (4). IEEE 教育活動部門: 350–361. doi :10.1109/MAHC.1983.10102. S2CID 8632276 . 2011 年 3 月 21 日閲覧。2011年7月18日、Wayback Machineにアーカイブ
^ Larman, Craig; Basili, Victor (2003 年 6 月)。「反復的および 漸進的開発: 簡単な歴史」(PDF)。コンピュータ。36 (6): 47–56。doi :10.1109/MC.2003.1204375 。
^ abcd Royce, Winston (1970)、「大規模ソフトウェアシステムの開発管理」(PDF)、IEEE WESCON 会議録、26 (8 月): 1–9
^ 「ウォーターフォール」。ブレーメン大学 - 数学およびコンピュータサイエンス。
^ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). 「アジャイル手法の歴史的ルーツ: 「アジャイル思考」はどこから来たのか?」(PDF)。Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (編)。ソフトウェアエンジニアリングとエクストリームプログラミングにおけるアジャイルプロセス。ビジネス情報処理の講義ノート。第 9 巻。ベルリン、ハイデルベルグ: Springer。pp . 94–103。doi : 10.1007 /978-3-540-68255-4_10。ISBN 978-3-540-68255-4。
^ Conrad Weisert、ウォーターフォール手法：そんなものは存在しない！
^ Lineberger, Rob (2024年4月25日)。アジャイルの継承: アジャイル後の世界でソフトウェア開発を管理するためのIT実践者向けガイド。ノースカロライナ州ダーラム: Sandprint Press。36ページ。ISBN 9798989149605。
^ Bell, Thomas E.、および TA Thayer。ソフトウェア要件: 本当に問題なのでしょうか?第 2 回国際ソフトウェアエンジニアリング会議の議事録。IEEE Computer Society Press、1976 年。
^ ab DOD-STD-2167 - 軍事規格：防衛システムソフトウェア開発"。米国国防省。1985-06-04。p. 11。
^ 「軍事標準防衛システムソフトウェア開発」(PDF)。
^ Lineberger, Rob (2024年4月25日)。アジャイルの継承: アジャイル後の世界でソフトウェア開発を管理するためのIT実践者向けガイド。ノースカロライナ州ダーラム: Sandprint Press。37ページ。ISBN 9798989149605。
^ ab McConnell, Steve (1996)。『Rapid Development: Taming Wild Software Schedules』。Microsoft Press。ISBN 1-55615-900-5。
^ 「ウォーターフォールソフトウェア開発モデル」。2014年2月5日。 2014年8月11日閲覧。
^ Arcisphere technologies (2012). 「チュートリアル: ソフトウェア開発ライフサイクル (SDLC)」(PDF) 。 2012 年 11 月 13 日閲覧。
^ Hughey, Douglas (2009). 「従来のシステム分析および設計とアジャイル手法の比較」ミズーリ大学セントルイス校2014年8月11日閲覧。
^ Parnas, David L.; Clements, Paul C. (1986). 「合理的な設計プロセス: それを偽装する方法と理由」(PDF) . IEEE Transactions on Software Engineering (2): 251–257. doi :10.1109/TSE.1986.6312940. S2CID 5838439 . 2011-03-21に取得。
^ McConnell, Steve (2004). Code Complete, 第 2 版. Microsoft Press. ISBN 1-55615-484-4。
^ エンスメンガー、ネイサン（2010年）。『The Computer Boys Take Over』MIT Press、p. 42。ISBN 978-0-262-05093-7。
^ Larman, Craig; Basili, Victir (2003). 「反復的および漸進的開発: 簡単な歴史」. IEEE Computer . 36 (6) (6 月版): 47–56. doi :10.1109/MC.2003.1204375. S2CID 9240477.
^ 「方法論：設計方法」。

外部リンク

ソフトウェア開発のウォーターフォールモデルの長所と短所を理解する
プロジェクトライフサイクルモデル: 違いと使用タイミング
RUP で滝を越える ( Philippe Kruchten著)
CSCとIBM Rationalが提携し、C-RUPを提供し、急速なビジネス変革をサポート
c2:滝
[1]

[:0-1] Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). 「大規模開発におけるウォーターフォールモデル」。 Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (編)。製品重視のソフトウェアプロセス改善。ビジネス情報処理の講義ノート。第 32 巻。ベルリン、ハイデルベルク: Springer。 pp. 386–400。Bibcode :2009pfsp.book..386P。doi :10.1007/978-3-642-02152-7_29。ISBN 978-3-642-02152-7。

[2] Tom Gilb . 「進化型デリバリーと「ウォーターフォールモデル」」「ACM SIGSOFTソフトウェアエンジニアリングノート. 10 (3): 49–61. doi :10.1145/1012483.1012490.

[3] Linda Sherrell (2013). 「ウォーターフォールモデル」。科学と宗教の百科事典 (ALC Runehov、L. Oviedo (編))。ドルドレヒト、オランダ: Springer : 2343–2344。doi :10.1007 / 978-1-4020-8265-8_200285。ISBN 978-1-4020-8264-1。

[4] Andreas P. Schmidt、Christine Kunzmann (2014 年 9 月 16 日)。知識成熟のための設計: 知識駆動型ソフトウェアから知識開発の促進のサポートまで。i-KNOW '14: 知識技術とデータ駆動型ビジネスに関する第 14 回国際会議の議事録。ACM。pp . 1–7。doi : 10.1145 /2637748.2638421。

[5] 米国海軍数学計算諮問委員会（1956年6月29日）、「デジタルコンピュータの高度なプログラミング方法に関するシンポジウム」[ワシントンDC]：海軍研究局、海軍省、OCLC 10794738

[benington-6] Benington, Herbert D. (1983 年 10 月 1 日). 「大規模コンピュータプログラムの作成」(PDF) . IEEE Annals of the History of Computing . 5 (4). IEEE 教育活動部門: 350–361. doi :10.1109/MAHC.1983.10102. S2CID 8632276 . 2011 年 3 月 21 日閲覧。2011年7月18日、Wayback Machineにアーカイブ

[7] ^ Larman, Craig; Basili, Victor (2003 年 6 月)。「反復的および 漸進的開発: 簡単な歴史」(PDF)。コンピュータ。36 (6): 47–56。doi :10.1109/MC.2003.1204375 。

[royce-8] Royce, Winston (1970)、「大規模ソフトウェアシステムの開発管理」(PDF)、IEEE WESCON 会議録、26 (8 月): 1–9

[9] 「ウォーターフォール」。ブレーメン大学 - 数学およびコンピュータサイエンス。

[10] Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). 「アジャイル手法の歴史的ルーツ: 「アジャイル思考」はどこから来たのか?」(PDF)。Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (編)。ソフトウェアエンジニアリングとエクストリームプログラミングにおけるアジャイルプロセス。ビジネス情報処理の講義ノート。第 9 巻。ベルリン、ハイデルベルグ: Springer。pp . 94–103。doi : 10.1007 /978-3-540-68255-4_10。ISBN 978-3-540-68255-4。

[11] Conrad Weisert、ウォーターフォール手法：そんなものは存在しない！

[:inheriting_agile-12] Lineberger, Rob (2024年4月25日)。アジャイルの継承: アジャイル後の世界でソフトウェア開発を管理するためのIT実践者向けガイド。ノースカロライナ州ダーラム: Sandprint Press。36ページ。ISBN 9798989149605。

[13] Bell, Thomas E.、および TA Thayer。ソフトウェア要件: 本当に問題なのでしょうか?第 2 回国際ソフトウェアエンジニアリング会議の議事録。IEEE Computer Society Press、1976 年。

[:1-14] DOD-STD-2167 - 軍事規格：防衛システムソフトウェア開発"。米国国防省。1985-06-04。p. 11。

[15] 「軍事標準防衛システムソフトウェア開発」(PDF)。

[inheriting_agile-16] Lineberger, Rob (2024年4月25日)。アジャイルの継承: アジャイル後の世界でソフトウェア開発を管理するためのIT実践者向けガイド。ノースカロライナ州ダーラム: Sandprint Press。37ページ。ISBN 9798989149605。

[rapid-17] McConnell, Steve (1996)。『Rapid Development: Taming Wild Software Schedules』。Microsoft Press。ISBN 1-55615-900-5。

[18] 「ウォーターフォールソフトウェア開発モデル」。2014年2月5日。 2014年8月11日閲覧。

[19] Arcisphere technologies (2012). 「チュートリアル: ソフトウェア開発ライフサイクル (SDLC)」(PDF) 。 2012 年 11 月 13 日閲覧。

[20] Hughey, Douglas (2009). 「従来のシステム分析および設計とアジャイル手法の比較」ミズーリ大学セントルイス校2014年8月11日閲覧。

[21] Parnas, David L.; Clements, Paul C. (1986). 「合理的な設計プロセス: それを偽装する方法と理由」(PDF) . IEEE Transactions on Software Engineering (2): 251–257. doi :10.1109/TSE.1986.6312940. S2CID 5838439 . 2011-03-21に取得。

[22] McConnell, Steve (2004). Code Complete, 第 2 版. Microsoft Press. ISBN 1-55615-484-4。

[23] エンスメンガー、ネイサン（2010年）。『The Computer Boys Take Over』MIT Press、p. 42。ISBN 978-0-262-05093-7。

[24] Larman, Craig; Basili, Victir (2003). 「反復的および漸進的開発: 簡単な歴史」. IEEE Computer . 36 (6) (6 月版): 47–56. doi :10.1109/MC.2003.1204375. S2CID 9240477.

[25] 「方法論：設計方法」。