要件に費やされた時間と、プロジェクトの成功と開発時間への影響


15

作成に費やした時間、または要件について考える時間が開発時間に影響を与えることを示唆する証拠はありますか?Standish(1995)が行った研究は、不完全な要件(13.1%)がプロジェクトの失敗に寄与したことを示唆しています。要件分析に費やされた時間がプロジェクトの開発時間、またはプロジェクトの成功度に影響することを示す調査が行われましたか?


3
アジャイルモデルはここにどのように適合しますか?要件の時間(オンとオフ)を費やしていると言えますが、要件の「フェーズ」はありません。
ラファエル

1
@Raphaelに同意します。ソフトウェアエンジニアリングに関する質問を受け付けますか?または、この時点で「コンピューターサイエンス」と「ソフトウェアエンジニアリング」を区別することは価値がないというサイトの公式ポリシーですか。
Patrick87

1
@ Patrick87これをmetaに移動しましょう。
ラファエル

この質問は、既存のソフトウェアエンジニアリングおよびプロジェクト管理サイトにより適していると思われます。
アダムリア

回答:


10

Steve McConnell著のコード完了、表3-1を参照してください。彼は、欠陥が導入および検出された時期に基づいて、欠陥を修正する平均コストを比較します。建設時の検出には、要件時の検出の5〜10倍、リリース後の10〜100倍の費用がかかります。

この表は、次のソースに基づいています。

  1. 「ProgramnDevelopmentのエラーを減らすための設計およびコード検査」(Fagan 1976)

  2. ソフトウェアの欠陥の削除(Dunn 1984)

  3. 「Hughes Aircraftでのソフトウェアプロセスの改善」(Humphrey、Snyder、WIllis 1991)

そしてさらにいくつか


それだけでは十分ではありません。高価な間違いは十分に頻繁に発生する必要があり、適切な要件を見つけることによって十分に頻繁にキャッチする必要があります。そうしないと、要件を考え出すための追加費用が、間違い費用を上回る可能性があります。
ラファエル

それは本当だ。要件を急がせるのではなく、特定のポイントまでは、要件のエラーが少ないことを意味しますが、それはそれほど長くはないようです。
ジョー

10

はい、このトピックに関する多くの研究があります。もちろん、この質問はあらゆる種類のソフトウェア開発プロジェクトに答えるには一般的すぎますが、要件分析を適切に行うことが実装段階にプラスの影響を与えるという概念をサポートするいくつかのコンテキストからの証拠があります。この証拠は部分的に「法律」にまとめられており、次の3つの例があります。

Glassの法則: 要件の不備がプロジェクトの失敗の主な原因です。

この法律は、大規模なソフトウェア開発プロジェクトからの事例研究の証拠によって裏付けられています。Glassは、失敗したケースでは要件が多すぎ、変更が遅れて不安定であり、あいまいで不完全であることを発見しました。

これは、要件の品質とプロジェクトの成果との間に関係があることを示唆しています。

Boehmの最初の法則: エラーは、要件および設計アクティビティ中に最も頻繁に発生し、後で削除するほど高価になります。

また、これはケーススタディの証拠によって裏付けられ、次の方法で質問に答えるのに役立ちます。要件を適切に実行すると、システム内のエラーの数が減り、実装を開始する前にエラーを修正する方が、ハントするよりも安価になります実装が既に開始されている場合(またはさらに悪いことに、システムが既に出荷されている場合)にダウンします。

Boehmの第2の法則: プロトタイピング(特に)により、特にユーザーインターフェイスの要件と設計エラーが減少します。

これは、学生のコンテキストでの制御された実験によってバックアップされます。考えられる解釈の1つは、要件と設計段階が完全にドキュメント主導で理論的である必要はないということです。代わりに、要件と設計段階の一部としてプロトタイピングを実行します。これは、時間をかけて要件を検討することになりますが、プロジェクトの成功と実装時間に影響します。

同じ方向を指し示す他の多くの証拠もあります。実装の準備に時間を費やすことは、リスクが少なく、サプライズによるスケジュールのオーバーランの可能性が少ないという形で報われます。問題はテストに関するものではありませんが、適切な準備はテストにもプラスの影響を与えます。

これらの法律の参照は次のとおりです。

Glassの法律:Glass、RL:ソフトウェアの暴走。大規模なソフトウェアプロジェクトの失敗から学んだ教訓。ニュージャージー州アッパーサドルリバー:プレンティスホール1998

Boehmの最初の法則:Boehm、BW、McClean、RK、Urfrig、DB:大規模な信頼性の高いソフトウェアの設計に対する自動化された支援の経験。IEEE Trans on Software Engineering 1、1(1975)、125–133

Boehmの2番目の法則:Boehm、BW、Gray、TE、Seewaldt、T .:プロトタイピングと指定:マルチプロジェクト実験。IEEE Trans on Software Engineering 10、3(1984)、290-302

また、次の参考文献も参考になります:Endres、A.およびRombach、D. A Handbook of Software and Systems Engineering。経験的観察、法律および理論。ソフトウェアエンジニアリングに関するフラウンホーファーIESEシリーズ。アディソンウェスリー、2003年。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.