ソフトウェアの工数見積もりにおけるCOCOMOおよびNASAデータセットの主な利点は何ですか？
COCOMOとNASAのデータセットは、ソフトウェアの取り組みの見積もりに関する体系的な文献レビューのほとんどで広く使用されています。その理由を知りたいのですが？私はこれら2つのデータセットを使用した多くの論文を読みましたが、著者はそれについて正当化していません。 COCOMO/NASAはPROMISEリポジトリで公開されていますが、他に正当な理由はありますか？ありがとう
理論XまたはYを裏付ける学術研究について尋ねるこのサイトで出てくる質問に答えようとすることがあります。
私が圧倒的に見つけたのは、ソフトウェア業界における学術研究と一般知識の間の大きなギャップです。理論のテストと構築へのアプローチとそれらの実験の結果の両方で。
99.999％の企業は、彼らの推定アプローチの科学的研究を試みることさえできるほど十分に一貫したアプローチと十分な蓄積されたデータを持たないという推測を危険にさらすでしょう。
今の学術論文でよく見られるのは、オープンソースプロジェクトを見るということです。なぜなら、これらはおそらく最新のソフトウェア開発をより代表しており、コミット、バグ、リリースなどに関する公的にアクセス可能なデータが大量にあるからです。
営利会社がこの種の情報を公開することに対する本当の動機はありません。
だから全体的にはあなたが正しいと思います。これらの研究は、公開されている数少ない研究の一部であるという理由だけで参照されることがよくあります。
私の経験では、間違いなく間違いでもあると付け加えておきます。たとえば、COCOMOがコード行に要約されることがわかります。ほとんどのプログラマーは、会議の数と会議の待機の遅延が完了時間にはるかに大きな影響を与えることに同意すると思います。
COCOMOとNASAのデータセットの主な利点は、それらが公開されている重要な推定データセットであることです。
それが唯一の利点であると挑発的に主張します。ここでの私の主要な議論はそれです：
- [〜＃〜] cocomo [〜＃〜] は、いくつかのソフトウェア属性とSLOC（コードのソース行）の間の統計的相関に基づくモデルであり、開発努力を表すと想定されています。しかし SLOCは、OOPの時代の労力推定に関連するメトリックではありません 。
- 使用されているデータセットは比較的古く（70年代と80年代 私の知る限り ）、現在のソフトウェアチャレンジと開発ツールおよびプラクティスを表していない。
- COCOMOの推定モデルは、事前に知っておく必要がある要件を想定しています。これは、たとえば、現代のアジャイル手法には適合しません。
同等のサイズの代替データセットは多くありません。十分な数の大きなプロジェクトがあり、体系的な測定と基準を一貫した方法で適用できる、個々のチームカルチャーの違いによる影響を受けない均一なプロジェクトの母集団を持つ大規模な組織はそれほど多くないため、...そのような機密情報を共有する準備ができている（競合分析に使用できる）。
大学でココモのテクニックを学びました。数学の実践以外では、それがそれ以降どこでも使われるのを見たことがありません。これは、ウォーターフォールモデルに従っていた場合でも同様です。
クリストファーが書いたものに加えて、今日のコードの数行はコードフォーマッターの機能である可能性があります。したがって、メトリックは無意味になります。たとえば、79列と119列を使用するソースのautopep8。
ココモを無視することをお勧めします。