ウォーターフォールテクニックは段階に分かれています。 プロジェクトリーダーは、プロジェクト計画の各ステップに必要な時間（したがってお金）の見積もりを含める必要があります。 時間の見積もりは、どのプロジェクトでも本質的に問題があることを以前に確立しました。プロジェクトの初期段階で設定する必要がある場合はさらに問題があります。 ソフトウェアプロジェクトでは実行不可能です。 定義段階で、定性的に許容できる機能のリストがコンパイルされる可能性を考慮してください。 原則として、これにより、プロジェクトチームは、各機能の開発に必要な時間の現実的な見積もりを行うことができます。 ただし、実際には、不確実性が多すぎて公正な概算を提供できません。
ただし、実際には、不確実性が多すぎて公正な概算を提供できません。
- 多くの場合、機能が開発された後、クライアントはそれを必要としないことがわかります。 したがって、この機能の開発に費やされた時間は無駄と見なされる可能性があります。
- プロジェクトの過程を通じて、要件は変更される可能性があります。
- 機能を高コストで提供する必要がありますか、それとも低コストで提供する必要がありますか？ 多くの実装および実現手法があります。
- 機能はどのように技術的に設計されますか？ デザインは、それを作成するのに必要な時間に大きく影響します。
- 機能はどの程度高水準でなければなりませんか？ たとえば、Webアプリケーションは常に完全にアクセス可能である必要がありますか、それとも1年に数時間ダウンすることを許可する必要がありますか？
- ソフトウェアの問題を検出して修正するために必要な時間は、数分から数週間までさまざまです。
- 新しいソフトウェアをインストールしてお客様の現在のシステムと統合するのにどのくらい時間がかかりますか？
- 考えられる解決策に関する情報の欠如は、時間の見積もりにさらに影響を与えます。 さらに、必要な専門知識を習得するために必要な時間を見積もることは困難です。
上記のリストは、さまざまな変数が新しいソフトウェアの開発に必要な時間の長さに影響を与える可能性があることを示しています。 プロジェクトの開始時に機能を開発するために必要な時間の見積もりは、多くの場合、4倍低すぎるか4倍高すぎます。 これは、必要な時間が誤った見積もりの4倍または4分の1になる可能性があることを意味します。 プロジェクトが進展するにつれて、これらの見積もりはより正確になります。 機能設計が完了した後、マージンは25％に減少し、多すぎたり少なすぎたりします。 機能が開発された場合にのみ、高い信頼度で見積もりを行うことができます。
ソフトウェアのリスク #
プロジェクト管理ソフトウェア完全にエラーが発生することはありません。 広く使用されている有名なプログラム（Word、Excel、Explorer、OS X、PHP、Flashなど）でも、インターネットには既知の欠陥のリストがあります。 定期的に、ソフトウェアのバグを修正する新しいバージョンが市場に出回っています。 お客様は、ソフトウェアにエラーがないことを要求することがあります。 しかし実際には、そのような目標はソフトウェアの一部を完成させることを不可能にするでしょう。 さらに、ソフトウェアの障害はプログラムに固有のものではないことがよくあります。
Flashは、教育用ゲームの作成に使用されました。 クライアントは、ゲームをファイルとして取得し、自分のサーバーにインストールすることに同意しました。 プロジェクトの過程で、クライアントは、プレーヤーの競争力を高めるために、ゲームにハイスコア機能を追加するように要求しました。 これには、いくつかのPHPスクリプトコードが必要になります。 ゲーム開発者は、Linuxを実行している独自のサーバーでスクリプトコードを開発およびテストしました。 成功しました。 クライアントはゲームとスクリプトコードを受け取りました。 ただし、クライアントはWindowsサーバーを使用していたため、何らかの理由でスクリプトが正常に機能しなくなりました。 最高の成績は保持されませんでした。 プログラマーは、問題を修正するために最終的に1週間を必要とします。 結局のところ、PHPとWindowsは常に一緒にうまく機能するとは限りません。 スクリプト全体に間違いはまったくありませんでした。 彼はハックを使用してそれを機能させることができ、誰もが喜んでいました—しかし、誰がその追加の1週間の労働にお金を払うべきでしょうか？
別のソフトウェア開発プロジェクトには、教育用アプリケーションの作成も含まれていました。 問題は、ソフトウェアが開発者にとってはうまく機能したが、クライアントにとっては良くなかったということでした。 他のすべての可能性を使い果たした後、プログラマーはクライアントに訪問を支払うことにしました。 結局のところ、クライアントは1990年代初頭からPentiumIIIマシンを実行していました。 コンピュータの速度が遅いため、ソフトウェアのパフォーマンスが低下しました。 さらに、プログラマーはPentium IIIでソフトウェアを試しましたが、うまく機能しました。 さらに調査したところ、ウイルスとスパイウェアの感染により、顧客のPCの動作が遅いことがわかりました。
プロジェクト開発における不確実性の管理 #
上記の例で示された不確実性は、プロジェクト計画の作成。 さらに、それは当事者間の交渉を複雑にします。 誰かが実行しなければならない追加の労働に関連するリスクを負わなければなりません。 支払いが1時間ごとに行われる場合、クライアントはすべてのリスクを負います。 設定された料金が合意された場合（助成金によるプロジェクトの場合のように）、ソフトウェア開発者がリスクを負います。 3人以上が関与する場合、状況はより複雑になります。 このシナリオでは、プロジェクトに費やした追加時間のコストを誰が負担する必要がありますか？
誰が遅延の責任を問われるべきかについて、しばしば論争が起こります。 多くの場合、責任者を特定するのは困難です。 「遅延」は必要な時間数の誤った初期見積もりによって引き起こされたため、関係者の誰も責任を負わないことはかなり考えられます。 過剰なプロジェクト時間と誰が支払うべきかという問題は、情報技術業界における論争の一般的な原因です。
