COCOMOは、小さなプロジェクトに分割できる大きなプロジェクトをどのように処理しますか？
COCOMOを使用して、100 KLoC組み込みプロジェクトを作成するための労力を見積もりたいとしましょう。作業量調整係数を含まない場合、作業量は2.8 * 100 ^ 1.2 = 703になります。ただし、プロジェクトには2つの異なるコンポーネントがあります。紙の上では、各コンポーネントは50 KLoCの独自のプロジェクトであり、推定値を2 *（2.8 * 50 ^ 1.2）= 612に下げていると私は主張します。
どちらが正しい？ 2番目の見積もりは、全体を2つの完全に別個のプロジェクトとして2つの別個のチームなどで編成した場合にのみ正しいでしょうか？それはオーバーヘッドを増加させませんか、それゆえincrease元の見積もりよりも労力が増加しますか？それとも、COCOMOは、2つの推定値を実際に区別するには単純すぎて正確ではないのですか（それから、どちらかを単に「500〜1000程度」程度として扱う必要があります）。
ココモ理論的視点
COCOMOは、KLocのソフトウェアのサイズと作業量の間の統計的相関に基づくモデルです。使用したと思われる 中間モデル も、推定調整係数からの追加のコストドライバーを考慮しています。
ココモの推定原則は、製品は全体を形成する独立したソフトウェアであるということです。したがって、コードを2x50 Klocに分割でき、各部分が互いに独立して実行できる場合、計算は正しくなります。
ココモと現実
ただし、これは理想的でありそうもないケースのようです。
- 両方の部分がある程度相互依存している場合、EAFは各部分の複雑さが増すため（他の部分との相互依存のため）、信頼性要件の増加（他の部分はそれに依存するため）により増加します。これにより、分割された製品のEAFが1ではなく1.3になる場合、全体の作業量は795になります。最初の100KLocの見積もりよりも高い
- 両方の部分の相互依存性が高い場合、または相互依存性が高い場合でも、調整、同期、および通信の労力が増えるため、全体のKLocサイズは100KLoc = 2 * 50KLocにはなりません。とりわけ、複雑さの上に追加の同期/パフォーマンス制約があるため、EAFも同様に増加します。
結論として、あなたの理想的なケースは非常に仮説であり、確かに現実とはかけ離れています。
直感的には、この理想的ではない数値の方が確かに現実的であると感じることができます。大きな製品を2つに分割すると、追加の相互作用が処理されるため、より多くの努力が必要になります。 2つの部分の間でコードの再利用を管理することも、分離して変更することができないため、追加の課題が生じます。
ココモ精度
次のことに注意する必要があります。
- COCOMOの数値は、比較的少数の大規模プロジェクトに基づいています（古いソースでは、そのようなプロジェクトは70〜80であり、最近の研究では300を超える数値について言及しています）。
- COCMOは、すべての要件が事前にわかっていることを前提としているため、検出のオーバーヘッドはありません。
- ココモは実際には適応されていません インクリメンタルに対応 開発方法
- 最後に KLOCはもはや意味のある一貫した手段ではありません それから努力を引き出すことになると、私たちは誰でも多くの反復的な部分を持つ長いコードを書くことができますが、より良いデザインはコードの行数を減らすことができますが、より高い労力が必要になります。