ウォーターフォールモデルの問題は何ですか？

ウォーターフォールモデルは、エンジニアリング設計の特定の領域に対する比較的線形の順次設計アプローチです。

ソフトウェア開発では、進行は、構想、開始、分析、設計、構築、テスト、展開、および保守のフェーズを経て、ウォーターフォールのように主に一方向に下向きに流れるため、反復性が低く柔軟なアプローチの1つになる傾向があります。ソフトウェア開発プロジェクトで使用されるフェーズは、通常、次のようになります。

1.要件

ソフトウェア開発やあらゆる種類のプロジェクト作成チームに興味がある場合は、作成しようとしているもののビジネスコンテキストを知りたいと思うでしょう。解決しようとしている問題の種類と、人々があなたにどのように反応するかを定義したいと思います。完成品。これらすべての「要件」を定義すると、次のステップに進むために必要な入力が得られます。

2.設計

このステップは、以前に決定したすべての要件を満たすために必要なすべてのステップで構成されています。ソフトウェア開発では、これはすべてのソフトウェアとハ​​ードウェアアーキテクチャ、プログラミング言語、データストレージなどを定義する部分です。これは、プロジェクトがエンドユーザーにとってどのように役立つかを決定する部分でもあります。

3.実装

このステップでは、計画で設計したものの構築を開始します。ウォーターフォールメソッドのこの部分は、前の手順で作成した基準を満たすことに専念しています。これは、開発チームの人々が参加して、前のステップで説明したすべてのことを実現する部分です。

4.検証

これは、開発チームが間違いを犯さないようにするために品質保証担当者が入る方法の一部です。これはまた、人々が自分の計画で何が機能しているか、何が機能していないかを理解する部分である可能性が最も高いです。

ご了承ください

プロジェクト開発者がすべてを満足させると、クライアントまたはエンドユーザーが参加し、プロジェクトを立ち上げる準備ができたら最後の呼び出しを行います。

ウォーターフォール方式では、特定の段階で問題が発生した場合、前の段階に戻って問題を確認できます。たとえば、計画の実施に問題があり、人々が彼らに渡された青写真に従っていることを知っている場合、マネージャーは彼らの計画を見て、そこから修正を行います。

滝の問題は何ですか？

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

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

したがって、組織が考えていた要件が実際に機能するという保証はありません。ここから、ウォーターフォールモデルには次の問題があることがわかります。

1. 人々は盲目的に計画に従います。

従来の方法では、人々は物事が実際に適切な場所に落ちているかどうかを気にせずに、適切な瞬間に物事がどのように起こるかにもっと注意を払います。計画は重要ですが、開発者と品質チェッカーが、特にクライアントまたはエンドユーザーで物事がどのように発生するかを理解することも重要です。また、プロジェクトに関与するすべての人が、テスト段階を待たずに、プロジェクトの遂行における特定のステップがどのように崩壊するかをすぐに言うことができることも重要です。

2. 順次のプロセスと変更にはコストがかかります

このアプローチでは、プロジェクトの進行に伴って定義された要件を変更することはできません。したがって、ソフトウェアがユーザーの要件を完全に満たしていない可能性があり、非効率的で機能が不十分になります。

開発者は、消費者の要件が変化したときに前のフェーズに戻って何かを変更することはできませんが、開発者は要件を変更する必要がある場所に戻って、そのフェーズを最初からやり直す必要があるため、不十分です。そのフェーズが完了するまで、彼は次のフェーズに進むことができません。

3. エンドユーザーは自分が何を望んでいるのかわかりません。

ほとんどの場合、エンドユーザーの心は絶えず変化しており、ほとんどの人はソフトウェア要件について漠然とした考えを持っており、ソフトウェアが開発されるにつれて、要件を指定します。

完成品をお客様にお渡しする時期になると、初期段階で意図的に別の言い方をしているにも関わらず、お客様はその仕上がりが気に入らない可能性があります。クライアントとエンドユーザーは、時間の経過とともに必要なものを簡単に変更できます。ウォーターフォールシステムには、計画を修正してプロジェクト全体をやり直すことなく、まだそれを解決する方法がありません。

4. 品質のテストが損なわれる可能性があります。

プロジェクトの結果を正確に予測することは不可能であり、チーム全体が時間に追われている場合、期限を守るためにテスト段階を短くすることができます。

5. 自分が実際にどのステージにいるのかはわかりません。

作成しようとしている製品は最後まで生産されないので、まだ計画中なのか、開発段階なのかはよくわかりません。つまり、視界が悪いために、予想以上にステージに時間を費やす可能性もあります。

結局、ウォーターフォール方式は剛性が高すぎるため、リスクが高すぎる可能性があります。あなたが機能し、何が機能しているかを理解するのに十分な柔軟性を備えた製品を生産できるようにするために。

関連リソース

• アジャイルとスクラム—ソフトウェア開発の記事（英語）（中国語）（日本語）