11

LOCはプロジェクト見積もりの​​正しいパラメータですか？

LOC以外に、1行のコードで複雑さがはるかに長くかかるシナリオは非常に多く、プロジェクトの見積もりに推奨されるパラメーターは何でしょうか。

人々がプログラムの機能的なポイントについて話しているとき、それはユースケース関連の情報にとって意味がありますか？

分析、設計、テストケースの準備、コーディングで構成される完全なソフトウェア開発見積もりの​​確固たる基盤を見つけようとしています。提案してください。

4

6 に答える 6

3

Steve McConnell の Rapid Development (Microsoft Press、1996 年):

プログラミング言語が異なれば、与えられたコード行数に対してこのように異なるバングが生成されるため、ソフトウェア業界の多くは、プログラムのサイズを見積もるために「ファンクション ポイント」と呼ばれる尺度に移行しています。ファンクション ポイントは、入力、出力、照会、およびファイルの数の加重合計に基づく、プログラム サイズの総合的な尺度です。ファンクション ポイントは、プログラムのサイズを言語に依存しない方法で考えることができるので便利です。

詳細については、Google の「ファンクション ポイント」を参照してください。

于 2009-09-21T10:04:36.233 に答える
2

開発者はほとんどの時間を変更のテストに費やす可能性が高いため*、コード行数は問題の規模を示す適切な指標にはなりません。

既存の大規模なアプリケーションがあるとします。コードの 1 行を変更するのは簡単に思えるかもしれませんが、テストの計画と実行には数週間かかる場合があります。

同様に、簡単にテストできる範囲が限定された単一のモジュールに比較的大量のコードを追加しても、数日しかかからない場合があります。

*少なくともそうすべきです。コードのテストよりもコードの作成に多くの時間を費やしている場合は、おそらくバグでいっぱいです。つまり、専任の QA チームに届く前に。

于 2009-10-01T06:26:36.583 に答える
1

逆に使用する場合のみ。

- 編集

しかし、いいえ。そうではありません。これはほとんど役に立たない手段であり、一般的に有害です。お気づきのように、ほとんどの場合、コードが少ないほど優れています。

他に確認することはありますか？さて、あなたは何を測定しようとしていますか？あなたがチェックしているものの変化から、どのような結果を見たいですか? これらの変更に基づいて、どのような決定を下しますか?

于 2009-09-21T09:59:48.860 に答える
1

LOC は、問題のサイズを測定するための 1 つの代理尺度です。

LOC 推定を使用でき、LOC カウントは過去のプロジェクトから比較的安価に測定できます。ただし、他の回答ですでに指摘されているように、問題サイズのプロキシ以外に使用すると、LOC が問題になる可能性があります。

要件を考えると、問題のサイズはかなり一定です。サイズの見積もりから、労力、スケジュール、およびコストの見積もりに進むことができます。これは、コストやスケジュールなどの計画ドライバーによって異なります。履歴データから、問題のサイズが労力にどのように変換されるか、および他の計画ドライバーが結果にさらに影響を与える方法の相関関係を見つけることができます。そのため、サイズ測定と労力を他のパラメーターと比較して測定し、見積もりプロセスを微調整し続ける必要があります。文献で利用可能な LOC-to-effort の測定値がいくつかありますが、使用しているテクノロジーとチームを使用したドメインでは、それらはあまり正確ではありません。

問題サイズの他の指標は、ファンクション ポイントとストーリー ポイントです。ファンクション ポイントに関する私の経験では、努力する価値はほとんどありません。一方、アジャイル メソッドのストーリー ポイントは、意図的に抽象化され (LOC に関する多くの問題を回避する)、スプリントごとに測定され、次のスプリントに即座にフィードバックされるため、非常にうまく機能します。

于 2009-09-21T10:38:39.027 に答える
1

いいえ、そうではありません。理由は簡単です。開発中に新しいコード行を作成した場合、ソリューションに一歩近づいているのでしょうか。タスクを完了するのに 1000 行のコードを見積もった場合、そのタスクは 0.1% 完了していますか?

コードの行数は指標として使用できますが、マイナスの意味でのみ使用できます。コードの行数が多いほど、バグの数が多いと想定するのが合理的です。履歴データに基づくと、通常、コード行数とバグ数の間には線形の相関関係があります。

考慮に値する有用で測定可能な要素を次に示します。

  1. 労働時間。
  2. 費やした金額: テスターや顧客の手でバグを見つけるよりも、開発者のデスクトップでバグを見つけたいという現実を強く強制するため、これは良いものです)。
  3. 達成されたマイルストーン: 顧客がシステムを適切な日に利用できるか?
  4. 要件の完了: これは面白いことかもしれません。プロジェクト中に新しい顧客のニーズを発見したらどうしますか?

要するに、コードの行数は、これまでに使用した可能性のある最悪の指標に非常に近いものです。

于 2009-11-03T17:59:47.817 に答える
0

プロジェクトの期間を合理的に見積もる唯一の方法は、最終的な要件のサブセットを完全に実装して提供することです。次に、完成した作業と複雑さを比較することで、残りの要件を見積もることができます。

于 2010-01-25T20:00:48.677 に答える