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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ウォーターフォールモデルは、プロジェクトアクティビティを線形の順次フェーズに分解したものであり、各フェーズは前のフェーズの成果物に依存し、タスクの特殊化に対応します。[1] このアプローチは、エンジニアリング設計の特定の領域で一般的です。ソフトウェア開発では[1]概念、開始分析設計構築テスト展開メンテナンス[2]

ウォーターフォール開発モデルは、製造業建設業に端を発しています[要出典]高度に構造化された物理環境は、設計変更が開発プロセスではるかに早く非常に高価になることを意味しました。[要出典]ソフトウェア開発に最初に採用されたとき、知識ベースの創造的な仕事の代替案は認められていませんでした。[3] [より良い情報源が必要]

歴史

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

この論文では「ウォーターフォール」という用語は使用されていませんが、後に「ウォーターフォールモデル」として知られるプロセスの最初の正式な詳細図は、ウィンストンW.ロイスによる1970年の記事として引用されることがよくあります[5] [6] [7]しかし、彼はまた、テストがプロセスの最後にのみ行われたという事実に起因する大きな欠陥があると感じました。これは、「危険で失敗を招く」と彼は説明しました。[5]彼の論文の残りの部分では、変更されていないウォーターフォールアプローチに関連する「開発リスクのほとんどを排除する」ために必要であると彼が感じた5つのステップを紹介しました。[5]

Royceの5つの追加ステップ(開発のさまざまな段階で完全なドキュメントを作成することを含む)が主流になることはありませんでしたが、欠陥のあるプロセスと見なした彼の図は、「ウォーターフォール」アプローチを説明する際の出発点になりました。[8] [より良い情報源が必要]

「滝」という用語の最初の使用は、ベルとセイヤーによる1976年の論文にあったかもしれません。[9] [より良い情報源が必要]

1985年、米国国防総省は、ソフトウェア開発請負業者と協力するための基準であるDOD-STD-2167A [引用が必要]でこのアプローチを採用しました。この基準では、「請負業者は、次の6つのフェーズを含むソフトウェア開発サイクルを実装する必要があります。 :ソフトウェア要件分析、予備設計、詳細設計、コーディングと単体テスト、統合、およびテスト」。[10]

モデル

Royceの元のウォーターフォールモデル[要出典]では、次のフェーズが順番に続きます。

  1. システムおよびソフトウェア要件製品要件ドキュメントに記録
  2. 分析モデルスキーマ、およびビジネスルールの結果
  3. 設計ソフトウェアアーキテクチャを実現
  4. コーディングソフトウェアの開発証明統合
  5. テスト:欠陥体系的な発見とデバッグ
  6. 操作完全なシステムのインストール移行サポート、およびメンテナンス

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

ただし、さまざまな変更されたウォーターフォールモデル(ロイスの最終モデルを含む)には、このプロセスにわずかなバリエーションまたは大きなバリエーションが含まれる場合があります。[5]これらのバリエーションには、下流で欠陥が見つかった後に前のサイクルに戻ることや、下流のフェーズが不十分であると見なされた場合は設計フェーズに戻ることが含まれます。

サポート引数

ソフトウェアの生産サイクルの早い段階で時間を費やすと、後の段階でコストを削減できます。たとえば、初期段階で見つかった問題(要件仕様など)は、プロセスの後半で見つかった同じバグ(50〜200倍)よりも修正が安価です。[11]

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

ウォーターフォールモデルのさらなる議論は、ソースコードだけでなくドキュメント(要件ドキュメントや設計ドキュメントなど)にも重点を置いているということです[要出典]あまり完全に設計および文書化されていない方法論では、プロジェクトが完了する前にチームメンバーが離れると知識が失われ、プロジェクトが損失から回復するのが難しい場合があります。完全に機能する設計ドキュメントが存在する場合(Big Design Up Frontおよびウォーターフォールモデルの目的のように)、新しいチームメンバー、またはまったく新しいチームでさえ、ドキュメントを読むことで慣れることができるはずです。[13]

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

批評

クライアントは、動作するソフトウェアを確認する前に要件が正確にわからない可能性があるため、要件を変更すると、再設計、再開発、再テストが行​​われ、コストが増加します。[15]

設計者は、新しいソフトウェア製品または機能を設計するときに将来の問題に気付かない可能性があります。その場合、新たに発見された制約、要件、または問題を考慮しない設計に固執するよりも、設計を改訂する方が適切です。[16]

組織は、システムアナリストを雇用して既存の手動システムを調べ、それらが何を行い、どのように置き換えることができるかを分析することにより、クライアントからの具体的な要件の欠如に対処しようとする場合があります。ただし、実際には、システム分析とプログラミングを厳密に分離することは困難です。[17]これは、重要なシステムを実装すると、システムアナリストが考慮しなかった問題やエッジケースがほぼ必然的に明らかになるためです。

純粋なウォーターフォールモデルで認識された問題に対応して、「刺身(重複フェーズのあるウォーターフォール)、サブプロジェクトのあるウォーターフォール、リスク低減のあるウォーターフォール」などの修正されたウォーターフォールモデルが導入されました。[11]

米国国防総省などの一部の組織は、進化的獲得反復型および漸進的開発を奨励するMIL-STD-498から始まる、ウォーターフォールタイプの方法論に対して現在優先権を表明しています。[18]

アジャイルソフトウェア開発の支持者は、ウォーターフォールモデルはソフトウェアを開発するための効果のないプロセスであると主張しますが、一部の懐疑論者は、ウォーターフォールモデルは純粋に代替開発方法論を売り込むために使用される誤った議論であると示唆しています。[19]

Rational Unified Process(RUP)フェーズは、プロジェクトを軌道に乗せるためのマイルストーンのプログラム上の必要性を認めますが、フェーズ内での反復(特に分野内)を奨励します。RUPフェーズは、「ウォーターフォールのような」と呼ばれることがよくあります。[要出典]

変更されたウォーターフォールモデル

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

これらには、スティーブマコネルが「修正されたウォーターフォール」と呼ぶRapidDevelopmentモデルが含まれます。「インクリメンタルウォーターフォールモデル」など、他のソフトウェア開発モデルの組み合わせも存在します。[20]

ロイスの最終モデル

ロイス最終モデル

Winston W. Royceの最終モデル、彼の最初の「ウォーターフォールモデル」に対する彼の意図された改善は、フィードバックがコードテストから設計(設計のコードで発見された欠陥のテストとして)につながる可能性があることを示しました。要件仕様に戻って設計します(設計上の問題により、競合する要件やその他の方法で満たされない/設計できない要件を削除する必要がある場合があるため)。同じ論文で、ロイスは大量のドキュメントを提唱し、「可能であれば2回」の仕事をしました(ソフトウェアプロジェクト管理の影響力のある本である人月の神話を書いたことで有名なフレッドブルックスの感情に似ます「1つ捨てる」)、エクストリームプログラミング)。

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

  1. 分析とコーディングを開始する前に完全なプログラム設計
  2. ドキュメントは最新かつ完全でなければなりません
  3. 可能であれば2回仕事をする
  4. テストは計画、制御、監視する必要があります
  5. 顧客を巻き込む

も参照してください

参考文献

  1. ^ a b Petersen、Kai; ウォーリン、クレス; バカ、デジャン(2009)。ボマリウス、フランク; Oivo、Markku; Jaring、Päivi; アブラハムソン、ペッカ(編)。「大規模開発におけるウォーターフォールモデル」製品に焦点を当てたソフトウェアプロセスの改善ビジネス情報処理の講義ノート。ベルリン、ハイデルベルク:スプリンガー:386–400。土井10.1007 / 978-3-642-02152-7_29ISBN 978-3-642-02152-7
  2. ^ 「伝統的な滝のアプローチ」www.umsl.edu 2022-02-23を取得
  3. ^ a b ベニントン、ハーバートD.(1983年10月1日)。「大規模コンピュータプログラムの作成」(PDF)コンピューティングの歴史のIEEE年報IEEE教育活動部門。5(4):350–361。土井10.1109 /MAHC.1983.10102S2CID8632276 _ 2011年3月21日取得   2011年7月18日、WaybackMachineでアーカイブ
  4. ^ 米国、海軍数学コンピューティング諮問委員会(1956年6月29日)、デジタルコンピュータの高度なプログラミング方法に関するシンポジウム、[ワシントンDC]:海軍研究局、海軍省、OCLC 10794738 
  5. ^ a b c d Royce、Winston(1970)、「Managing the Development of Large Software Systems」(PDF)Proceedings of IEEE WESCON26(8月):1–9
  6. ^ 「滝」ブレーメン大学-数学とコンピュータサイエンス
  7. ^ アッバス、ノウラ; Gravell、Andrew M。; ウィルズ、ゲイリーB.(2008)。アブラハムソン、ペッカ; バスカヴィル、リチャード; キーラン・コンボイ; フィッツジェラルド、ブライアン; モーガン、ロレーヌ; 王、Xiaofeng(編)。「アジャイル手法の歴史的ルーツ:「アジャイル思考」はどこから来たのか?」ソフトウェアエンジニアリングとエクストリームプログラミングにおけるアジャイルプロセスビジネス情報処理の講義ノート。ベルリン、ハイデルベルク:スプリンガー:94–103。土井10.1007 / 978-3-540-68255-4_10ISBN 978-3-540-68255-4
  8. ^ コンラッド・ワイザート、ウォーターフォールの方法論:そのようなことはありません!
  9. ^ ベル、トーマスE.、およびTAセイヤー。ソフトウェア要件:それらは本当に問題ですか? ソフトウェア工学に関する第2回国際会議の議事録。IEEE Computer Society Press、1976年。
  10. ^ 「軍用規格防衛システムソフトウェア開発」(PDF)
  11. ^ a b c McConnell、Steve(1996)。迅速な開発:ワイルドソフトウェアのスケジュールを使いこなす。MicrosoftPress。ISBN 1-55615-900-5
  12. ^ 「ウォーターフォールソフトウェア開発モデル」2014年2月5日2014年8月11日取得
  13. ^ Arcisphereテクノロジー(2012)。「チュートリアル:ソフトウェア開発ライフサイクル(SDLC)」(PDF)2012年11月13日取得
  14. ^ Hughey、ダグラス(2009)。「従来のシステム分析と設計とアジャイル手法の比較」ミズーリ大学–セントルイス2014年8月11日取得
  15. ^ パーナス、デイビッドL。; クレメンツ、ポールC.(1986)。「合理的な設計プロセス:それを偽造する方法と理由」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクション(2):251–257。土井10.1109 /TSE.1986.6312940S2CID5838439 _ 2011年3月21日取得  
  16. ^ McConnell、Steve(2004)。コードコンプリート、第2版MicrosoftPress。ISBN 1-55615-484-4
  17. ^ Ensmenger、ネイサン(2010)。コンピューターボーイズが引き継ぐp。 42ISBN 978-0-262-05093-7
  18. ^ ラーマン、クレイグ; Basili、Victir(2003)。「反復型および増分型開発:簡単な歴史」IEEEコンピュータ(6月版)。36(6):47–56。土井10.1109 /MC.2003.1204375S2CID9240477_ 
  19. ^ ウォーターフォールシステム開発方法論…真剣に?DavidDischaveによる。2012年。2014年7月2日、 WaybackMachineでアーカイブ
  20. ^ 「方法論:設計方法」

外部リンク