COCOMOモデルの理解に関する問題
基本的な COCOMOモデル では、ソフトウェアの開発時間を推定するために使用されます
工数：a * KLOC ^ b = X人月
開発期間：c *作業量^ d = Yか月
ここで、a、b、c、dは、ソフトウェアプロジェクトのタイプに応じて、以下の表から派生した定数です。
質問1
X = 10とすると、工数は10人月に相当します。
10人月とは、このプロジェクトを完了するために必要な労力が、10人で作業している場合に1か月であることを意味しますか
[〜＃〜]または[〜＃〜]
10人月とは、10人がプロジェクトに取り組んでいる場合、プロジェクトを完了するために必要な労力は10か月であることを意味しますか。
質問2
定数に工数のSI単位が人月のようなSI単位がありますか
用語に戸惑う
行き過ぎる前に、あなたが本当に読むべき2冊の本：
基本的なCOCOMOモデルには、COCOMO IIモデルで古くなって対処されたいくつかの問題があります。引用されたウィキペディアのページから：
COCOMO IIはCOCOMO 81の後継であり、最新のソフトウェア開発プロジェクトの見積もりにより適しています。最新のソフトウェア開発プロセスと更新されたプロジェクトデータベースのサポートを強化します。新しいモデルの必要性は、ソフトウェア開発技術がメインフレームおよび夜間のバッチ処理からデスクトップ開発、コードの再利用性、および既製のソフトウェアコンポーネントの使用に移行したときに生じました。
「10人月」の努力は努力の推定ですが、それは完全に分割可能なタスクを想定しています。地面に10個の穴を掘る場合は、1人で10個の穴を掘るか、10人で1個の穴を掘ることができます。10人で約10倍速く処理できます。しばしば指摘されているように、これはソフトウェアプログラミングではうまく機能しません。
これに特に興味があるのは、最も効率的なスケジュールのパーセントの相対的なコストを調べるペーパー「プロジェクトの工数に対するスケジュール圧縮の効果」[ link ]です。
もう1つお読みください ソフトウェア推定ツールの仕組み ソフトウェア推定ツールのアルゴリズムを頻繁に引用される人々の1人によって書かれました。
労力/スタッフ=期間
お気づきのように、これはプログラミングには適していません。
私が書いたものから 長い時間 とうまく引用できなかったので、次の表に見積もりの終わりまで書き留めておきました（もう少し掘り下げて、 COCOMO IIスケジュール式 ）。デフォルトのスケジュール乗数（3.67）を使用して、推定時間の立方根（あなたのケースでは10か月）を掛けます。
3.67 * 101/3 = 7.9
これは、ソフトウェア開発プロジェクトのタイムラインの最良のケースを表しています。
これらの数字はどこから来たのですか？ 20kのプロジェクトを曲線にフィットさせる。
この7.9から、そこから得られることがいくつかあります。
- 最小の工数= 2x最適な納期（15.8ヶ月）
- 不可能の領域=ベストケースの納期の75％未満（5.9か月）
ココモとココモIIモデルの背後には多くのことが起こっています。これらの数値は、膨大な数のソフトウェアプロジェクトのサンプリングに適合します。モデルに何をフィードしているのかを理解しない限り（モデルが期待するものと一致するため）、得られる数値は、漠然と現実に似ていても一致しません。
また、推定プロセスの約2/3の過程を経ていることにも気づいてください。見積もられた労力（10人月）ではなく、スケジューリングを続行します。持続時間の最後のビットは、10匹の蛾の推定値が出て、3人を投げて3か月で完了すると、しばしばドロップまたは忘れられます（そして、それは不可能の領域にあるため失敗します）。
参考文献：
10人月とは、1人が10か月で仕事ができることを意味しますが、10人が1か月で仕事ができることも意味します。 これは純粋なフィクションです。次の標準的な例は政治的に正しくありませんが、説明のためです。女性が赤ん坊を生むには9ヶ月かかります。 9人の女性は、この9か月の間隔を1イオタ減らしません。読むThe Mythical Man Month。これはベームと一緒に読む必要があります。
コストの見積もりは、正しく行われると、受胎から出産までの9か月の間隔などの制約を考慮に入れて行われます。さらに良いことに、大規模なソフトウェアプロジェクトで醜い頭を必然的に発生させるランダムイベントを説明する必要があります。ソフトウェアプロジェクト管理における実践の現状（not最先端）は、既知の制約と、必然的に物事を遅くするランダムなナンセンスを考慮することです。これの別名：モンテカルロソフトウェアコストの見積もり。
補遺
電気会社が電気料金の基礎として使用するキロワット時のソフトウェアに相当する人月と考えてください。
10個のウィジェットを作成する契約を結んだとします。このタスクが完全に自動化されているとします。 1キロワットのアプライアンスにスイッチを入れて、1時間後にウィジェットを作成します。このジョブの総工数は10キロワット時です（ウィジェットあたり10ウィジェットx 1キロワット時）。 1つのアプライアンスを使用する場合は10時間、2つのアプライアンスを使用する場合は5時間でジョブを完了できます。 10台のアプライアンスで1時間で作業を完了できますか？理論的にはそうです。実際には、違います。まず、これらの追加のアプライアンスを調達する必要があります。次に、10個すべてを同時にオンにすると、ヒューズが切れます。あなたが地元の金物屋に行くときに問題になるのは、あなたが必要とするサイズの外になります。そのサイズのヒューズを探すのに何時間も費やすことになります。すでに手元にある2つのアプライアンスを使用したほうがよいでしょう。
チームサイズはモデルへの入力の1つです。既存の小規模で経験豊富なチームがある場合にのみ、適切な係数を使用できます。つまり、この一般的なクラスの問題について、チームが互いに協力して作業した経験があります。
おそらく1つまたは2つのメンバーを追加できますが、それ以上であれば、モデルの仮定を無効にできます。戻って新しい係数を使用して再計算すると、一般に、人を追加することによってプロジェクトをどれだけ遅らせることができるかについての見積もりが得られます。
赤ちゃんを持つ女性の例としては、そうすることでプロジェクトが「日常的な、人的能力の範囲内」から「物理的に可能であるかどうかに関係なく、第二次世界大戦規模のオープンエンドの遺伝子研究の取り組み」に移行します。
グラフには線がありませんが、推定できます...
COCOMOを使用した演習の目的は、他のソフトウェア推定方法論と同様に、2つの質問に答えることです。費用はどれくらいかかりますか。
COCOMOの工数と工数の月数の結果が意味することは、プロジェクトが終了すると、その月数に相当する給与が支払われると推定され、多くの月が過ぎてしまうことになります。カレンダーで。
それは一人の男がその数ヶ月でそれを行うことができることを意味しません、そしてそれは多くの男性が一ヶ月でそれをすることができることを意味しません。
COCOMOの見積もりは、成果物のソースコード行の見積もりに基づいており、成果物のソースコード行と費やした工数の両方を事後的に簡単に測定できるため、工数で結果が得られます。 1つは提供されたコードから直接取得され、もう1つはプロジェクトの給与データから直接取得されます。 COCOMOのマジックナンバーは、多数のプロジェクトのタイムカードデータと行数を事後的に測定することによって開発されました。
これにより、特定の組織に対して推定量を調整し、特定の組織の推定の全体的な品質を向上させることができます。ベームらは、すべての組織がこれを行うことを強く推奨しています。彼らが与える数字は、個々の組織にとって良い出発点ですが、それらは石板に刻まれており、最終的な回答ではありません。
基本的なCOCOMOは、両方の名目上の総工数を月単位で示します[〜＃〜] and [〜＃〜]名目上のプロジェクト期間（月単位）。その期間に必要な名目人数を取得するには、作業時間を期間で割ります。
それは名目です。基本的なCOCOMO DOES NOT ADDRESS圧縮または拡張された公称以外のスケジュール。管理モンキーレンチのスケジュールの影響を考慮するには、中級ココモまたは詳細ココモを使用する必要があります。
2番目の質問に答えるには、システムが正式に過小に指定されているため、Basic COCOMOの個々のマジックナンバーにユニットを割り当てることはできません。どのユニットがどのマジック番号に対応し、どのユニットが次元（因子ラベル）分析でキャンセルされるかを決定する方法はありません。