Loading article…
ウォーターフォールモデルは、開発活動を線形の連続フェーズに分割したもので、各フェーズは互いに引き継がれ、各フェーズは前のフェーズの成果物に依存し、タスクの特化に対応します。[1]このアプローチは、エンジニアリング設計 の特定の領域で一般的です。ソフトウェア開発では、[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]これは、重要なシステムを実装すると、システムアナリストが考慮しなかった問題やエッジケースがほぼ必然的に明らかになるためです。
純粋なウォーターフォールモデルに問題があったことを受けて、「サシミ（重複フェーズ付きウォーターフォール）、サブプロジェクト付きウォーターフォール、リスク削減付きウォーターフォール」などの修正されたウォーターフォールモデルが導入されました。[17]
アメリカ国防総省などの一部の組織では、1994年に発表されたMIL-STD-498を皮切りに、進化的取得と反復的かつ漸進的な開発を奨励するウォーターフォール型の方法論に反対する姿勢を表明している。[24]
修正されたウォーターフォールモデル
「純粋な」ウォーターフォール モデルに見られる問題に対応して、多くの「修正ウォーターフォール モデル」が導入されました。これらのモデルは、「純粋な」ウォーターフォール モデルに対する批判の一部またはすべてに対処している可能性があります。
これらには、スティーブ・マッコーネルが「修正ウォーターフォール」と呼ぶラピッド開発モデルが含まれます。 [17]ピーター・デグレースの「サシミモデル」（重複するフェーズを持つウォーターフォール）、サブプロジェクトを持つウォーターフォール、リスク削減を持つウォーターフォール。「増分ウォーターフォールモデル」などの他のソフトウェア開発モデルの組み合わせも存在します。[25]
ロイスの最終モデル
ウィンストン・W・ロイスの最終的なモデルは、彼が当初の「ウォーターフォール モデル」を改良したもので、フィードバックはコード テストから設計 (コード テストで設計の欠陥が明らかになる) につながり (また、多くの場合、つながるはずであり、つながるはずである)、また設計から要件仕様に戻る (設計上の問題により、矛盾する要件や、満足できない/設計できない要件の削除が必要になることがある) ことを示しました。同じ論文でロイスは、大量のドキュメント化、作業の「可能なら 2 回」実行 (ソフトウェアプロジェクト管理で影響力のある書籍である Mythical Man Month の著者として有名なFred Brooks が「1 つを捨てる」計画を提唱したのと似た考え方)、および顧客を可能な限り関与させること ([[extreme program
最終モデルに関するロイスのコメントは次のとおりです。
- 分析とコーディングを始める前にプログラム設計を完了する
- 文書は最新かつ完全でなければならない
- 可能であれば作業を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: Proceedings of the 14th International Conference on Knowledge Technologies and Data-driven Business。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。
- ^ abc 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]
防水;デザイン