システム開発見積り

1回目の見積りは、発注先を決めるための概算です。要件が固まる前の数字なので、確定した金額ではありません。

④ この違いがトラブルのもとになる

発注者として、「この見積りはどの段階のものか」を確認する——診断士として助言できる点です。

⑤ COCOMO（COnstructive COst MOdel）

COCOMOとは、B.W.ベームが提案した代表的な統計的コスト見積りモデルです。

⑥ COCOMOの考え方

COCOMOでは、ソフトウェアの生産性に影響を与えるさまざまな要因を明らかにし、開発形態や開発規模に応じたモデル式によって、ソフトウェア開発の工数や期間を推定します。

⑦ COCOMOの前提条件

COCOMOは、プログラムの規模を土台に、見積りをどの精度で行うか、どういう要員構成かといった係数を掛け合わせて工数を出します。この係数は自社の実績から決めるものなので、過去の開発環境と要員の力量を数値でためておかないと動きません。

必要な前提

⑧ 統計値がないと使えない

「過去の積み上げがあって初めて機能する手法」——これがCOCOMOの性格です。

⑨ 統計的コスト見積りモデルとは

⑩ 「プログラムの大きさに基づく」点

COCOMOは、プログラムの大きさ（規模）を出発点にします。

何を出発点にするかで、手法が分かれる——この整理が、次のテーマ以降の理解の土台になります。

⑪ 7つの手法を先に俯瞰する

この一覧を頭に入れておくと、それぞれの説明が入れ替えられていても気づけます。

2回目：要件定義終了後

なぜ増えたのか

発注者として備えること

「要件定義を別契約にする」のが実務的

COCOMOが中小企業の案件で使われにくい理由

実務では類推法が多い

この2つが現実的に多く使われます。

見積りが外れる要因

2つ目がとくに見落とされる

発注者側の体制も、見積りの前提です。この要因を織り込むのが、後で学ぶCoBRA法の発想です。

確認してみましょう

> 次の記述の正誤を判定せよ。

> a　ベンダは、ベンダ選定の際と、基本計画（要求分析／要件定義）終了後の計2回にわたって、システム開発費用の見積りを行うことが一般的である。

> b　COCOMOは、B.W.ベームが提案した代表的な統計的コスト見積りモデルである。

> c　COCOMOを用いるには、開発環境や開発要員の能力を統計値として累積しておく必要がある。

解答　a：○　b：○　c：○

いずれも正しい記述です。COCOMOは「統計的コスト見積りモデル」であり、統計値の累積が前提——この点を押さえておきましょう。

② 5つの機能区分

ファンクション数を算出する際は、機能を5つに区分します。

③ 複雑度別の重み

各機能について、単純・普通・複雑の複雑度別に個数を数え、重みを掛けます。

④ 算出の手順

⑤ 重みの意味

ファイル（データ構造）の設計が、最も手間がかかる——重みの大小が、この実感を反映しています。

⑥ LOC法との比較

ファンクションポイント法は開発現場で広く普及している手法です。

従来用いられていたプログラムの行数により開発規模を見積もるLOC法（Lines Of Code法）（またはプログラムステップ法）と比較されます。

⑦ ファンクションポイント法のメリット

LOC法と比較し、以下のようなメリットがあります。

⑧ 3つのメリットを整理する

⑨ LOC法の問題点

行数を増やすほど見積りが高くなる

ファンクションポイント法はこの問題を避けられます。

⑩ ユーザの理解を得やすい理由

機能の数は、ユーザが自分で数えられる——これが理解を得やすい理由です。

⑪ 開発の初期段階から使える理由

機能の数は、要件定義の段階で見えます。行数が見えるのはずっと後です。

WBS（Work Breakdown Structure：作業分割図）は、次節で学びます。

② トップダウン法

トップダウン法とは、全体システムを見積り可能なサイズのソフトウェアコンポーネントに細分化する見積り手法です。

③ 類推法

類推法とは、過去の類似プロジェクトの実績を基礎に見積る方法です。

最も直感的で、実務でもよく使われる手法です。

④ CoBRA法（Cost estimation, Benchmarking and Risk Assessment法）

開発コストが規模だけで決まらない理由

ソフトウェアの開発コストは、開発規模（製作したソースコード量や実現した機能量など）だけではなく、要求内容の変動や顧客の協力度合いなど、開発プロジェクトに介在する多種多様な要因（変動要因）に影響されます。

⑤ 従来の限界

しかしプロジェクトの初期段階では、組織やプロジェクトに特有の変動要因を見極めること、また、その影響を定量的に把握することが困難であることから、それに近い値を推定する手法で開発コストの見積りが行われてきました。

⑥ CoBRA法の内容

CoBRA法は、経験豊富なプロジェクトマネージャなどの見積り熟練者の経験および知識を抽出し、それを変動要因として定義・定量化することで、透明性と説明性が高いコスト見積りを実現する方法です。

⑦ CoBRA法の仮定

開発工数は開発規模に比例することを仮定するとともに、さまざまな変動要因によって工数増加が発生することを加味しています。

⑧ 「変動要因」がCoBRA法の目印

令和6年度の本試験では、この内容が「COSMIC法」の説明として出題され、誤りとされました。

⑨ COSMIC法

COSMIC法は、ソフトウェアの機能規模をユーザ視点から評価し、データの構造や流れに着目してソフトウェアの開発規模を見積る方法です。

利用者機能要件と機能プロセスに着目して、機能プロセスごとにデータの構造や流れを計測します。

⑩ COSMIC法の適用範囲

適用範囲が広く、ビジネスアプリケーションのほかにもリアルタイムシステムや組込みシステムにも適用できます。

⑪ ユーザ視点で評価（利用者機能要件）

ユーザの観点からソフトウェアがどのようなデータの流れを持っているかを分析し、実際に使われる機能を重視した評価ができるため、ユーザにとっての価値を明確に測定できます。

⑫ データの構造や流れに基づいて計測

COSMIC法は、データの流れを4つの基本的な操作（エントリ、エグジット、読込み、書込み）に分類して計測します。

4つの動作がどのくらいあるかを測ることで、ソフトウェアの機能規模を定量化します。

⑬ 4つの操作の覚え方

外部とのやり取りが2つ、内部とのやり取りが2つ——この対称性で整理できます。

⑭ DFDとの関係

COSMIC法が着目する「データの構造や流れ」は、第9章で学んだDFDが表すものと同じです。

データの流れを図にできれば、COSMIC法で計測できる——この関係があります。

⑮ 7つの手法の判別キーワード