web-dev-qa-db-ja.com

プロジェクトの見積もり費用は[SLOC | COCOMO]によって異なりますか？

コードのソース行に依存するプロジェクトのコストを見積もることは論理的ですか？

などのツールから計算されたレポートのように

[誰か|雇用者|クライアント]に支払うように説得する方法はそれらのレポートに依存しますか？私のプロジェクトに基づいて$ 83,862のようなものを見ると、奇妙なことが起こります。

この見積もりの​​ために、開発者自身がより多くのコード行を書く場合があります。

それで、ソース行の数が価値がない場合、なぜ開発の[時々|なんらかの理由で]興味深い部分である必要があります。特に雇用者にとって、それは驚くべきことですが、価格設定に何の影響もないのですか？

ちょっと雇用者私は100万ドルの価値があるこのプロジェクトを開発しました。このソースコードカウンタープログラムはそれを証明します。

多分私は私の仕事の本当の価値を知りません、それを人々に公開し、それについていくつかのコメントを集めるか、それを見つけて、または私の知識に基づいて自分自身を推定するためにそれをいくつかの[専門家|コンサルタント]に示すべきですか？これらのソリューションは正しくないか、少なくとも論理的ではありません。

そして、私が自分で記述しなかったコードはどうなりますか。時々、コードの一部をコピーしてプロジェクトに[貼り付け|変更]することを意味します。

そして、この方法での見積もりが間違っている場合、これらのツールがコードのソース行、平均1時間あたりの作業およびその他の事実に関するレポートを生成する目的は何ですか。

オーロ ：

推定コスト

基本的なCOCOMOモデル を使用して、プロジェクトの推定コストを計算します。詳細に詳しい人のために、係数a = 2.4およびb = 105を使用しています。

見積もりはまだかなりずれているようです？

ソフトウェアコストの見積もりは、すべての変数がわかっている場合でも（確かにわかりません）、トリッキーなビジネスです。覚えておくべきことの1つは、COCOMOが大規模な制度的プロジェクトをモデル化するために作成されたことです。これは、多くの場合、分散型オープンソースプロジェクトと比較できません。 COCOMOは、開発時間だけでなく、高品質なソフトウェアの作成に伴う設計、仕様の草案作成、レビュー、および管理のオーバーヘッドを含むことを目的としています。

このモデルは、成熟した大規模なプロジェクトで最も正確なようです。活動の少ない若いプロジェクトは、通常、過大評価されます。

ohlohからの引用はSLOCだけではないことを知っています

pricingestimation
1
Alireza Savand

ソースコードの行に基づいて推定しないでください。必要な変更を実装するために必要な時間に基づいて見積もりを行う必要があります。これは、自分の経験とコードベースの広範な知識に基づいています。

あなたが述べたように、ソースコードの行に基づいて推定することは、開発者が必要でないときに意図的により多くのコードを書くことを意味するかもしれません。なぜこのようにコードベースを台無しにするのですか？

7
Bernard

LOCに基づいて推定することは意図的に悪いことであり、業界全体としてはそれから移行したと思いました。

ただし、開発者は自分の価値に応じて価格を設定する方法を知っている必要があります。特定の機能の費用がかかる理由をクライアントに正当化する必要がある場合は、それを行う必要があります。

クライアント/ボスは、低レベル（一般的に）で得られるものに過度に関心があり、結果に関心があります。彼らにとって、結果は価値があり、達成したので喜んでそれを支払うか、達成したが、それは価値があったよりもお金が多かったと考えています。

そして、端数を切り上げて、製品に含まれるコードの行数をクライアントに伝えると、それらは「かっこいい！」それは完全に抽象的なので、価格を変更しないでください。フォードはあなたのフィエスタに160bhpがあるとあなたに言って、あなたを「ああクール！しかし、あなたは彼らにさらに5000ポンドを投げません。

5
Nicholas Smith

コードの一部1：

return this.Data.Products.Where(c => c.IsEnabled).GroupBy(c => c.Category).Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

コードの一部2：

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

コードの一部3：

Func<Product, double> pricePredicate = c => c.Price;
Func<Product, bool> predicate = c => c.IsEnabled;
Func<Product, string> keySelector = c => c.Category;
Func<IGrouping<string, Product>, PricesPerCategory> finalSelector = c =>
    new PricesPerCategory(
        category: c.Key,
        minimum: c.Min(pricePredicate),
        maximum: c.Max(pricePredicate));

return this.Data.Products
    .Where(predicate)
    .GroupBy(keySelector)
    .Select(finalSelector);

これらの3つのコードは同じことを行いますで、おそらく同じILコードにコンパイルします。お気づきかもしれませんが、コードの品質を低下させながらLOCを拡大するためだけに過剰な変数とコード行が追加されたため、3番目のコードは読み取れません。

3番目の例では、誰かが悪いコードにもっとお金を払い、2番目の例ではより良いコードにもっとお金を払うのはなぜですか？

5
Arseni Mourzenko

この種の質問が出てくるときはいつでも、私はこの記事が出版されたときに紙の形で読んだことをいつも思い出しています。幸いなことに、それはネットに行きました： http://www.dvorak.org/blog/whatever-happened-to-wordstar-2/

特に、この引用は興味深いものです。

4か月で、バーナビーは137,000行の防弾アセンブリ言語コードを書きました。ルーベンシュタインは後に、バーナビーの生産量を42人年と計算したIBMの友人に確認しました。

記事によると、彼は4か月で1万37000行の（暗黙の）かなり欠陥のないコードを書きました。他の一部の個人は、この出力を42人年と推定しました。

見積もりでは、LOCを含む多くのファセットを組み合わせて、システム開発のコストを「見積もる」ことができます。

だから問題は、バーナビーがプロジェクトに取り組んだ4か月、またはそれと同等であると推定された42人の年にバーナビーに支払うかどうかということです。

これは正確な相関関係ではないことは知っていますが、それは考えるべきことです。

4
Michael Dean

いいえ、コード行を一定の作業量と同等にすることはお勧めできません。 LOCはプログラムのサイズの非常に大まかな見積もりとして使用できますが、それは否定的な特性です。必要以上に複雑なプログラムは必要ありません。最も単純なテトリスのクローンでさえ、恐ろしく作成すると、数百万行のコードが含まれる可能性があります。

別の方法として、このプロジェクトのスキルを備えたコンサルタントを見つけることをお勧めします。彼に仕事の説明を送り、見積もりを求めます。 （実際に彼を雇うつもりはないので、これは一番いいことではありません。後で昼食か何かを買ってください。）

コンサルタントが腕と脚を充電するのは、理論的には、必要な正確なスキルセットと知識ベースを使用してウォークインし、作業を迅速に完了できるためです。この価格の見積もりを表示すると、彼は少なくとももう少し幸せになるはずです。

自由市場は物事の真の価値を見つける素晴らしい手段です。

1
Philip