1000行のコード(SLOC)で測定されるプログラムAを特定の言語とドメインで特定の複雑さで開発するには、時間Tかかりました。同じレベルの複雑さを持ち、同じドメインにあり、同じプログラミング言語で開発された、4000行と推定されるプログラムBの開発にかかる時間を決定する方法はありますか?
私にかかる時間は4Tよりも長くなると思います。 SLOCカウントが増加するにつれてTがどのように増加するかを推定する式はありますか?
人々はこのようなことを推定しようとする多くのモデルを開発しました。それらのいずれかが完全に信頼できる、または正確に近いと主張するつもりはありませんが、中途半端な合理的な見積もりを与えるために十分な要素を考慮に入れているように見えるいくつかがあります。
ほんの一例として、Barry BoehmのCOCOMO IIモデルは、状況に適度に適合しているようです。 1つ オンライン実装 によると、元の1 KLOCは約4人月の労力を要し、4 KLOCは約10人月かかるはずです(一連の前提条件について-自由に接続してください)開発の種類などにより適切な値)。
同時に、コード行が(ほとんどの場合)非常に優れた尺度であることはめったにないことを指摘した他の人にも同意する必要があります。関数ポイントに基づく推定(1つの可能性)は、私にはかなり正確に思えます。しかし、せいぜいかなり多くの作業が必要であり、特にこのようなかなり小規模なプロジェクトの場合、その作業を正当化するのに十分正確または信頼できる結果を生成するかどうか疑問に思われるかもしれません。
編集:Oops-間違ったリンクを貼り付けました(それは元のCOCOMOモデル用で、COCOMO IIではありませんでした。)COCOMO IIは少し作業がかかります(1分または30秒ではなく2)ですが、より正確な結果が(想定される)生成されます。 オンライン実装 が使用可能です。どのような場合でも、より多くの要素を考慮に入れようとします(たとえば、新しいプロジェクトで既存の1000行のコードの一部またはすべてを再利用します)。
LOCの観点からアプリケーションを定量化することはできません-機能しません。 Ever。だから、面倒を省いて、それをしないでください。
編集:これが何らかの宿題の質問でない限り...その場合、教授は微調整であり、あなたはより良い学校に行くべきです-n ^ 2
これは少し物議を醸しますが、プロジェクト管理では、SLOCは通常、推定タイムラインを決定するために使用されます(つまり、読み取り ソフトウェア推定:ブラックアートの謎を解く(ベストプラクティス(Microsoft)) );ただし、通常下線が引かれているのは、同様の問題の十分に大きなデータセットが必要であり、開発にかかる時間の傾向に気づき始めることができるということです。これは一般的に非常に大規模なコードベースにも適用され、100,000以上のSLOCに入るまで正確な推定を開始しないことに注意してください。
MainMa's ダイビングのアナロジーを少し構築すると、主要な都市を運転していて、すべての旅行が50 km未満の場合、最終的に旅行がある程度自信を持って言うことができるかもしれません通常の交通状況では約30分かかりますが、個々の旅行の範囲は、特定のインスタンスで15分から2時間かかる場合があります。
これは、すべてが同じではないため、特定の関数またはストーリーポイントを記述するのにかかる時間を見積もろうとするのに似ています。一部のデータを取得してレポートに変換するだけのストーリーポイントを解決するには、プロジェクトに精通している人が数時間しかかからない場合があります。プログラムが使用している基本的なキューコードを改善しようとすると、数日かかる場合があります。これは通常、開発者が特定のタスクの経験に基づいて見積もりを推進し、開発者に関連する歴史的証拠に基づいて物事を調整するため、 エビデンスベースのスケジューリング の方が優れています。これが、この手法がタスク推定に適している理由です。
前述のようにSLOCに戻ると、主要プロジェクトがいつ完了するかを推定するために使用できますが、大規模でしか十分にスケールダウンできず、同様の条件下で同様のプロジェクトの歴史的証拠が必要です。タイムラインの見積もりであり、それらは実際には一日の終わりのガイダンスとしてのみ使用されます。ダイビングのアナロジーに戻ります。これは、長距離のロードトリップ(つまり、1,500 kmから始まる)に似ています。これは、移動距離が非常に長いため、交通の一部を走行している旅行の一部に出くわしたとしても、長時間の速度制限。つまり、旅行を数回行った後、旅行中に平均化した速度と、A地点からB地点に到達するまでにかかる時間について、かなり妥当な見積もりを出すことができます。大規模プロジェクトでも同じです方法:プロジェクトの純粋なサイズにより、プロジェクトプランナーは「過去に同様の範囲のプロジェクトを行ったことがあるため、それらのプロジェクトと同じくらいの大きさになる可能性が高く、完了するまでの時間が長くなる可能性があります。それらに似ている。」
コードのバグを減らしたい場合は、多くの自動テストを作成して、コンポーネントを実行した後ではなくbeforeおよびwhileを実行する必要があります。準備ができています。さまざまな言語とプラットフォーム用のテストフレームワークがあります。あなたはテスト駆動開発について読むことができます、主題に関して多くのオンラインとオフラインのリソースがあります。
(プログラムの)開発に必要な時間(T)は、コード行(SLOC)の関数だけではありません。また、品質(Q)の関数でもあります(おそらくn + 1個以上の変数)。
Qが低い場合、TはSLOCとともにある程度直線的に増加します。 (コードの行数を増やすだけで、それは多かれ少なかれ身体活動です)。
Qが高くなると、Tは指数関数的に増加し始め、無限に近づきます。 (3つ以上のSLOCの完全にバグのないコードを書くのは非常に困難です)。
したがって、SLOCが与えられているだけではTを推定することはほとんど不可能だと思います。運が良ければ、±1桁の範囲でヒットするかもしれません。例えば。 10日と見積もると、1〜100日かかる場合があります。
4K行の単純なコードでは、1K行の複雑なコードの1/10の時間がかかる場合があります。また、4K行の複雑なコードでは、1K行の単純なコードの40倍の時間がかかる場合があります。メジャーは無意味です。