プロジェクト推定のLOC正しいパラメータですか？LOCはプロジェクト推定のための正しいパラメータですか？
プロジェクトの見積もりに推奨されるパラメータである可能性がある、LOC以外の コードの複雑さには、複雑さが増すほど多くのシナリオがありますか？
人々はプログラムの機能点について話しているので、ユースケース関連の情報を意味しますか？
私は、解析、設計、テストケースの準備、およびコード化からなる完全なソフトウェア開発の見積もりの確固たる基盤を見つけようとしています。
逆の場合にのみ使用します。
- 編集
ただし、いいえ。そうではありません。ほとんど役に立たない措置で、一般的には有害です。あなたが指摘しているように、コードは少なくても、ほとんど、常にです。
その他の点検は？さて、あなたは何を測定しようとしていますか？あなたが確認したいことの変化からどのような結果を見たいのですか？これらの変更に基づいて、どのような決定をしますか？迅速な開発で
スティーブ・マコーネル（マイクロソフトプレス、1996）：
異なるプログラミング 言語コードの行の与えられた数のため、このような異なる前髪 を生成するので、ソフトウェア業界の 多くは 移動でありますプログラム のサイズを見積もるには、 「機能ポイント」という小節に向かってください。ファンクションポイントは、 の入力、出力、照会、およびファイルの数の加重和に基づいて、 を基にしたプログラムサイズの合成数字です。 は、 というプログラムのサイズを独立した言語で考えることができるので、機能点は便利です。
詳細については、「機能ポイント」を参照してください。
LOCは、問題サイズを測定するプロキシ対策の1つです。
LOC見積もりを使用することができ、LOC数は過去のプロジェクトから比較的安価です。しかし、LOCは、他の答えによってすでに指摘されているように、問題の大きさに対するプロキシ以外のものに使用すると問題になる可能性があります。
問題のサイズは、一定の要件を満たしています。サイズの見積もりから、努力、スケジュール、およびコスト見積もりに進むことができます。これは、コストやスケジュールなどの計画立案者によって異なります。履歴データから、問題のサイズがどのように努力に変換され、どのように他の計画運転者が結果にさらに影響を与えるかを見つけることができます。したがって、サイズの測定値と労力を他のパラメータと比較し、推定プロセスを微調整する必要があります。文献にはいくつかのLOC対策が用意されていますが、使用しているテクノロジと使用しているチームを使用して、ドメインであまり正確ではありません。
問題サイズの他のプロキシは、ファンクションポイントとストーリーポイントです。機能ポイントに関する私の経験は、彼らがほとんど努力する価値がないということです。一方、アジャイルメソッドのストーリーポイントは、意図的に抽象的な（したがって、LOCに関する多くの問題を回避している）、スプリント単位で測定され、後続のスプリントへの即時フィードバックで測定されるため、非常にうまく機能します。
開発者は変更をテストするためにほとんどの時間を費やす可能性が高いため、コードの行は問題のサイズを示す良い指標にはなりません。
既存の大規模なアプリケーションがあるとしましょう.1行のコードを変更するのは簡単ではありませんが、テストの計画と実行には数週間かかることがあります。
同様に、簡単にテスト可能な単一の限定スコープモジュールに比較的大量のコードを追加することは数日で済むかもしれません。
*これは少なくとも行う必要があります。彼らがそれをテストするよりも時間を費やしているのであれば、おそらくバグがいっぱいです。そしてそれはあなたの専用QAチームに達する前に意味します。
いいえ、そうではありません。理由は簡単です：開発中に新しいコード行を作成する場合は、ソリューションに一歩近づいていますか？タスクを完了するために1000行のコードを見積もった場合、そのタスクで0.1％完了しましたか？
コード行はメトリックとして使用できますが、否定的な意味でのみ使用できます。多数のコード行では、より多くのバグがあると想定するのが妥当です。履歴データに基づいて、コード行とバグ数の間には一般的に線形相関があります。労働の
は検討する価値があるいくつかの有用なかつ測定可能な要因です。
要するに、コード行は、これまでに使用できた最悪の可能性のあるメトリックに非常に近いものです。
プロジェクトの期間について合理的な見積りを得る唯一の方法は、最終的な要件の一部を完全に実装して提供することです。次に、完了した作業とその複雑さを比較することによって残りの要件を見積もることができます。