ウォーターフォール モデルの欠点を軽減するための方法論を教えてください。
8618 次
6 に答える
16
ウォーターフォールの問題は、それがモノリシックなステージで構成され、各建物が前のステージにあることです。したがって、システム全体が設計された後、コードは 1 つのチャンクで開発されます。これは、すべての要件が収集されて承認された後に行われます。
どんな変更も複雑な手続きによって承認され、すべての段階に波及しなければならないため、これは問題です。しかし、歴史の教訓は次のとおりです。変化は起こります。要件は常に不完全であったり、仕様が間違っていたり、コーディングに着手するまでに単に時代遅れになっています。システムが UAT に達したときに無効になる仮定に基づいて設計と構築が進められることがあまりにも多くあります。これは、必死の再作業とスリッページにつながります。
実際のところ、機能するソフトウェア ソフトウェア システムを想定するために必要な抽象的な思考が得意な顧客は多くありません。また、あまりにも多くの IT プロフェッショナルが、ビジネス ロジックを理解するのに必要な経験を欠いています。ウォーターフォールはこれらの真実を受け入れることを拒否します.
唯一の正直な要求仕様は、「見ればわかる」です。そのため、できるだけ早く実際のユーザーの前で動作するソフトウェアを入手することが重要です。短いイテレーションで段階的に機能するソフトウェアを提供することに焦点を当てた方法論は、「ウォーターフォール モデルの欠点を軽減」します。
元々は RADまたはDSDMでした。次に、XPがバナーを取り上げました。現在、アジャイルと、スクラムやかんばんなどの関連するものがあります。
では、なぜ人々はウォーターフォール方式に固執するのでしょうか?
アジャイルは、カウボーイ ハッカーがすべての退屈なプロセスを捨てて、コードを書くという、彼らが最も楽しんでいることに取り掛かるための隠れ蓑に過ぎないという一般的な認識があります。「エクストリーム プログラミング」のブランディングは確かにこの考えを助長しており、正直に言って、それは根拠のない主張ではありません。つまり、一部のコーダーは、計画、設計、または文書化をしない言い訳としてアジャイルを装っています。これは、アジャイルの実際の実践を反映したものではありません。アジャイルは、他の方法論と同じくらい厳格である必要があります。
また、アジャイルでは、顧客のスタッフがより多くの時間を費やす必要があり、多くの組織はこれを受け入れたがりません。また、請求書の費用を負担している人々は、下級スタッフに決定を下す権限を与えたがらないかもしれません。CustomerとUserの間には重要な違いがあります。
アウトソーシングに関して言えば、ウォーターフォール モデルは、成果物と段階的な支払いを一致させるための簡単なフレームワークを提供します。実際、契約上の側面はそれよりも強いかもしれません。EU では、1 億ユーロ以上の価値があるすべてのプロジェクトにウォーターフォールが義務付けられています。
最後に、ウォーターフォールがうまく機能するプロジェクトがあります。これらのプロジェクトには、安定しており、顧客と開発者の両方によく理解されている知識ドメインがあります。
最後の言葉
その失敗にもかかわらず、Waterfall は多くのプロジェクトを成功させてきました。これは、ハードワーク、適性、誠実さが方法論よりも重要だからです。
于 2010-05-15T07:13:21.713 に答える
4
ウォーターフォール モデルは、1970 年にウィンストン ロイス博士によって「大規模なソフトウェア システムの開発の管理」というタイトルの論文で文書化されました。基本的に、シーケンシャル開発に関する彼のアイデアの概要を説明します。彼のアイデアは、ソフトウェアが自動車と同様の方法で作成できるというものでした。この場合、車両はシーケンシャル/リニア フェーズでつなぎ合わされます。
この直線的なアプローチでは、ソフトウェアの一部が開始されると、その変更は実際には許可されません。エンド ユーザー/クライアントとの緊密な関係がないため、考えられる問題領域を概説するのが難しくなります。
注目に値するのは、ウォーターフォール モデルのいくつかのフェーズでは、開発期間に戻って小さな変更を加えるための十分な時間が「スプラッシュバック」を可能にすることです。時間の制約、関連する作業量、および予算により、このモデルを使用して大きな変更を行うことはできません。
ソフトウェアのパラダイム自体が変化するにつれて、ウォーターフォール モデルは古いものです。オブジェクト指向プログラミングは人気がありますが、当時はまだほとんど普及していませんでした。ウォーターフォール モデルを使用することで、欠陥が発見されたことは明らかであり、これが別の開発方法論につながっています。
では、代替案について説明します。インクリメンタル モデルは、Alistair Cockburn (2008) によって、さまざまな部分が異なる時間または速度で開発され、その特定の部分の完了時に統合されるステージングおよびスケジューリング戦略として説明されています。
基本的に、インクリメンタルは次のようになります。
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Analysis->Design->Code->Test
多くの利点には、ライフサイクルが柔軟であり、最初から変更できることが含まれます。動作するソフトウェアまたはパーツは、迅速かつ早期に生成されます。生成されたコードは、進行状況の反復が小さいため、テストと管理がより早く行われます。システムのすべての要件が最初にまとめられているわけではありません。概要だけです。これにより迅速な開始が可能になりますが、サポートされているシステム アーキテクチャなどを見逃す可能性があるため、一部のシステムでは不利になる可能性があります。
一方、反復では、システムの一部を再加工および修正して、システムを改善できます。これを可能にするための時間が設けられています。反復は、要件の完全な仕様から始まるわけではありません。開発は、ソフトウェアの一部のみを指定して実装することによって行われます。ソフトウェアは、さらなる要件を特定するためにレビューされます。これは、よりトップダウンです。アプローチ。この方法論の欠点は、すべての反復に互換性があることを確認することです。新しいイテレーションが承認されるたびに、開発者はバックワード エンジニアリングと呼ばれる手法を採用する場合があります。これは、新しいイテレーションが以前のものと互換性があることを確認するための体系的なレビューおよびチェック手順です。一定のイテレーションの主な利点は、クライアントが維持されることです。最終製品は要件を満たす必要があります。
他の方法論にはプロトタイピングが含まれます。進化と使い捨て。これらは、よりトップダウンのアプローチとも見なされます。どちらのプロセスもエンジニアリングから借用されています。エンジニアリングでは、構築するオブジェクトの縮尺モデルを構築するのが一般的です。モデルを構築することで、エンジニアは設計の特定の側面をテストできます。ソフトウェア開発プロトタイピングの方法論は、同じイデオロギーを提供します。プロトタイピングは、スタンドアロンの完全な開発方法論ではなく、より大規模でより伝統的な開発方法論の選択された部分を処理するためのアプローチと見なされます。
スローアウェイ プロトタイピング- スローアウェイ プロトタイピングは、開発されたプロトタイプを保持しません。使い捨てのプロトタイピングでは、プロトタイプを機能するシステムに変換する意図はまったくありません。代わりに、不明確なシステム設計の側面を実証するために、プロトタイプが迅速に開発されます。また、ユーザーやクライアントがさまざまな機能やインターフェイス特性を決定するのに役立つように開発することもできます。問題や不確実性に対処したら、プロトタイプを「破棄」し、学んだ原則を実際の製品の設計と文書化に使用できます。
進化的プロトタイピング- 進化的プロトタイピングでは、ターゲット システムのパーツをモデル化することから始めます。プロトタイピング プロセスが成功した場合は、それらのパーツからシステムの残りの部分を進化させます。このアプローチの重要な側面の 1 つは、プロトタイプが実際の生産システムになることです。このプロセスにより、システムの難しい部分をプロトタイプでうまくモデル化し、プロジェクトの早い段階で対処することができます。
他に検討すべき分野には、アジャイル -> スクラム、エクストリーム プログラミング、ペア プログラミングなどがあります。
短くしようとしましたが、人々はこの種のことについて本を書いており、議論すべきことがたくさんあります.
一見の価値があるかもしれません: Incremental and Iterative
于 2010-05-15T12:59:47.290 に答える
2
ウォーターフォール方式の代替方法は、「正しい方法で実行する」ことです。
あなたが工場の床の組立ラインにいるなら、滝は理にかなっているようです。しかし、私はそれが設計プロセスの一部として機能するのを見たことがありません...そしてソフトウェア開発はすべて設計プロセスです。したがって、ウォーターフォール方式は、高品質の製品の作成を容易にするのに役立たないという意味では実際には機能せず、むしろプロセスに焦点を合わせています。プロセスは素晴らしいかもしれませんが、それが生産する製品が二流である場合のポイントは何ですか？
于 2010-11-24T14:09:08.073 に答える
-1
ウォーターフォール モデルに関するリンクを次に示します。
http://www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html
于 2010-05-15T07:11:20.260 に答える