ソフトウェアのコスト見積り

モデルを用いた工数予測

奈良先端科学技術大学院大学

講義資料

出典

D. V. Ferens: “COCOMO,” in Encyclopedia of Software Engineering, J.J. Marciniak ed., John Weily and Sons, pp.103-110 (1994).大筆 豊：“ソフトウェアのコスト見積り技術”，情報処理，33，8，pp.906-911 (1992.8)．I. Sommerville: “Software Engineering,” 4th

ed., pp.587-610, Addison-Wesley (1996).山田 茂，高橋 宗雄：“ソフトウェアマネジメントモデル入門”，pp.36-50，共立出版（1993）．

ソフトウェア開発コスト

ハードウェアとソフトウェアの費用（保守費を含む）

旅費，訓練費

作業費（開発者への支払い）≒開発工数

光熱費

秘書等の間接的人員への支払い

ネットワーク費，通信費

ライブラリ等の集約的設備の費用

年金や社会保障費等

コスト見積り

ソフトウェア開発プロジェクトにおいて，必要となる作業に要するコストを，プロジェクト開始前，あるいは，プロジェクト実行中に推定すること．

見積り結果に基づき，

プロジェクト予算の算定

スケジュールの決定

ソフトウェア価格の決定

などが行われる．

コスト見積り手法

契約価格に基づく決定

パーキンソン（Parkinson）の法則

専門家による判定

類似プロジェクトからの類推

積算法

計算式等のコストモデルによる算出

契約価格に基づく決定

開発コストは，顧客がプロジェクトに投資可能なコストに一致するという考え．

開発コストは，開発するソフトウェアに必要とされる機能によって決まるのではなく，顧客の予算によって決まることになる．

パーキンソン（Parkinson）の法則

ソフトウェア開発コストは，「作業に利用できる時間を埋めるために拡大する」という考え．

開発コストは，客観的な分析によって決まるのではなく，利用できる資源により決まると考える．

例えば，納期まで1ヶ月で，担当者が5名であれば，必要な開発工数は5人月となる．．．

専門家による判定

開発プロジェクトの対象領域（ドメイン）や利用予定の開発技術に関する専門家複数人の意見を基にコストを見積る．

各専門家の意見を比較，検討し，最終的な見積り額は，専門家全員の合意の下に決定する．

例：デルファイ法

デルファイ法(Delphi Method)

Step1:専門家グループに，プログラムの要求仕様書と見

積り値記入用紙を配布する．

Step2:開発プログラムと見積り時の問題点を議論する．

Step3:相談せずに見積り値記入用紙に各自で記入する．

Step4:調整者が記入用紙を回収し，結果をまとめる．

Step5:見積り値のばらつきが許容範囲内であれば終了．そうでなければ，Step6へStep6:専門家グループが再度集合してStep4の結果を議論し，Step3へ．

見積り値記入用紙の例

1. プロジェクト名：2. 見積り年月日：3. 見積り実施回数：4. 見積り結果集計：

5. 次回の見積り値6. 見積り値に関する理由

0 20 40 60 80 100

× ×× × × ××

×：見積り値○：あなたの見積り値□：見積り中央値

(KLOC)

類似プロジェクトからの類推

開発するソフトウェアとよく似た過去のプロジェクトの実績に基づいてコストを見積る．

対象領域（ドメイン），開発業務や機能，開発方法，開発言語，．．．

見積りコストは最も安いが，精度は低い．

初期の見積りに利用されることが多い．

過去の類似プロジェクトに参加した人が見積る，あるいは，プロジェクト実績がデータベース化されていると信頼性が高くなる．

積算法

プロジェクトで必要となる作業を洗い出し，それら作業毎の工数を積み上げる．

作 業 の 洗 い 出 し 手 法 と し て は Work Breakdown Structure（WBS）がある．

標準タスク法：開発工程を標準的な作業（タスク）の集まりと定義する．開発組織の実績データに基づいて各タスクの工数を与える．

WBSの例

0.0 システムAの開発レベル0

WBSの例

0.0 システムAの開発

1.0 2.0 3.0 4.0 5.0 6.0

要求分析 システム仕様 設計 コーディング テスト 運用

レベル0

レベル1

WBSの例

0.0 システムAの開発

1.0 2.0 3.0 4.0 5.0 6.0

設計要求分析 システム仕様 コーディング テスト 運用

レベル0

3.1 3.2ユーザインタフェースコマンド処理

レベル1

レベル2

WBSの例

0.0 システムAの開発

1.0 2.0 3.0 4.0 5.0 6.0

設計要求分析 システム仕様 コーディング テスト 運用

レベル0

3.1 3.2

3.2.1 3.2.2

ユーザインタフェースコマンド処理

レベル1

レベル2

レベル3

入力 出力

標準タスク法における積算例

タスク 複雑度画面設計 単純 普通 複雑規模　大 a d g　　　　中 b e h　　　　小 c f i

標準タスクテーブル

a-i: 単位工数

プロジェクト要件

タスク 複雑度画面設計 単純 普通 複雑規模　大 A D G　　　　中 B E H　　　　小 C F I

A-I: 件数

タスク 複雑度画面設計 単純 普通 複雑規模　大 a*A d*D g*G　　　　中 b*B e*E h*H　　　　小 c*C f*F i*I

画面設計の工数

計算式等のコストモデルによる算出

コストに関する情報を基に作られたモデルを用いる方法．

モデルは，ソフトウェアに関する定量的情報（多くの場合は規模）とコストの関係を表す．

Walston and Felixモデル

COCOMOモデル

Putnumモデル

コスト見積りモデルの一般形

E=pLc

E: 開発工数（仕様決定後からシステムテストまでのコスト）

L: 開発規模

p: 生産性調整係数, c: 定数

D=qEd

D: 開発期間（仕様決定後からシステムテストまでの期間）

q: 定数, d: 定数

生産性変動要因

生産性調整係数p（E=pLｃ） に影響を与える要因．

人的要因（チームの大きさや熟練度）

問題要因（対象問題の型と重要性，仕様の構成，制約）

プロセス要因（言語，開発技法）プロダクト要因（対象システムの信頼性，規模,効率，構造）

資源要因（対象ハードウェア，開発期間，予算）

ツール（ライブラリ，コンパイラ，テストツール）

Walston and Felixモデル

IBMのFederal Systems Divisionにおける60個のプロジェクトのデータに基づくモデル．

対 象 プ ロ ジ ェ ク ト の 規 模 は 4,000 ～467,000SLOC，工数は12～11,758人月．

開発工数 E = 5.2(KLOC)0.91 （人月）

開発期間 D = 4.1(KLOC)0.36 = 2.47E 0.36 （月）

開発文書量 P = 49(KLOC)1.01 （ページ）

開発要員数 S = 0.54(KLOC)0.6 （人）C. Walston and C. Felix: “A method of programming measurement and estimation,” IBM Journal, 16, 1, pp.54-73 (1977).

COCOMO

B. BoehmがTRWで収集したデータに基づき提案したモデル（COnstructive COst MOdel）

開発規模をLOCで表し，工数を見積る．

パラメータによって，さまざまなプロジェクト形態にモデルが合うように工夫されている．

モデルの概念や適用方法に関する文書が整備されている．

多くの適用事例が報告されている．

B.W. Boehm: “Software Engineering Economics, Prentice-Hall (1981).

プロジェクトの形態

organicモード

比較的小規模の開発チームで，自社開発のような熟練度の高い開発形態．在庫管理システム，科学技術計算用パッケージ等の開発．

embeddedモード

開発チームが大規模．厳しい制約条件の下で要求仕様の変更も頻発する開発形態．OSの開発．

semi-detachedモード

上2モードの中間的形態．

COCOMOの階層

初級COCOMO：

プログラム規模のみを変数とする．

中級COCOMO：

プログラム規模と開発特性をパラメータとするモデル．

上級COCOMO：

プログラム規模と開発工程毎の開発特性をパラメータとするモデル．

初級COCOMO

開発工数 E = a(KLOC)b (a>0, b>1)開発期間 D = cEd (c>0, 0<d<1)

a b c d

organic 2.4 1.05 2.5 0.38

semi-detached 3.0 1.12 2.5 0.35

embedded 3.6 1.20 2.5 0.32

規模と工数の関係（初級ＣＯＣＯＭＯ）

0100200300400500600700800900

1000

10 20 30 40 50 60 70 80 90 100 110見積規模(KLOC)

organic

embedded

semi-detached

工数

(人月

)

中級COCOMO

調整された開発工数 E = E0 × Παi開発期間D = cEd (c>0, 0<d<1)

E0 : 平均的な開発工数

αi : 開発特性（コスト誘因）に基づく修正係数．15個あり，それぞれ6段階のレベルとレベル毎の修正係数が定義されている．

中級COCOMOによる見積り手順

STEP1:開発規模見積り値を得る．

STEP2:開発形態に応じた平均的な工数を見積る．

STEP3:15個の開発特性それぞれのランク付けをし，対応表より修正係数を求め，それらを掛け合わせる．

STEP4:STEP2で求めた平均的な工数にSTEP3で求めた修正係数を掛け，調整された工数を見積る．

STEP5:STEP5で求めた調整された工数に基づいて，開発期間等を見積る．

平均的工数の見積り

平均的開発工数 E0 = a(KLOC)b (a>0, b>1)

a b c d

organic 3.2 1.05 2.5 0.38

semi-detached 3.0 1.12 2.5 0.35

embedded 2.8 1.20 2.5 0.32

規模と平均的工数の関係

0

100

200

300

400

500

600

700

800

10 20 30 40 50 60 70 80 90 100 110

organic

semi-detached

embedded

見積規模(KLOC)

工数

(人月

)

開発特性（コスト誘因）

ソフトウェア特性信頼性の要求度，データベースの規模，製品の複雑さ

ハードウェア特性実行時間制約，主記憶制約，仮想計算機の複雑さ，ターンアラウンドタイム

開発要因特性要求分析者能力，アプリケーションの経験度，プログラミング能力，仮想計算機の経験度，プログラミング言語の経験度

プロジェクト特性近代的プログラミング手法の使用頻度，ソフトウェアツールの使用頻度，開発スケジュールの要求度

特性のランク付けの例（１）

信頼性の要求度： RELY

ランク 修正係数 基準

Very Low 0.75 Slight inconvenienceLow 0.88 Low, easily

recoverable lossesNominal 1.00 Moderate, recoverable

lossesHigh 1.15 High financial lossVery High 1.40 Risk to human lifeExtra High ---

特性のランク付けの例（２）

ターンアラウンドタイム： TURN

ランク 修正係数 基準

Very Low ---Low 0.87 InteractiveNominal 1.00 Avg. < 4 hrsHigh 1.07 4 hrs < Avg. < 12hrsVery High 1.15 12 hrs < Avg.Extra High ---

特性のランク付けの例（３）

プログラミング言語の経験度： LEXP

ランク 修正係数 基準

Very Low 1.14 < 1 month experienceLow 1.07 4 monthsNominal 1.00 1 yearHigh 0.95 3 yearsVery High ---Extra High ---

中級COCOMOの適用例

対象プロジェクト

対象ソフトウェア：マイクロプロセッサの通信ソフト

開発形態：Embeddedモード

開発規模の見積り値(STEP1)： 10KLOC

平均的な工数見積り値E0 = 2.8(10)1.20 = 44 （人月）

中級COCOMOの適用例（続き）

コスト誘因 システム概要 ランク αi

信頼性の要求度 普通 N 1.00データベースの規模 20,000バイト L 0.94製品の複雑さ 通信処理 VH 1.30実行時間制約 利用可能時間の70% H 1.11主記憶制約 65Kのうち45K H 1.06仮想計算機の複雑さ 民生用マイクロプロセッサ N 1.00ターンアラウンドタイム 2時間 N 1.00要求分析者能力 上級システム分析者 H 0.86アプリケーションの経験度 3年 N 1.00プログラミング能力 上級 H 0.86仮想計算機の経験度 6ヶ月 L 1.10プログラミング言 12ヶ月 N 1.00プログラミング手法 1年以上 H 0.91ツール 基本的なミニコンツール N 1.10スケジュール 9ヶ月 L 1.00

工数調整係数 1.17

中級COCOMOの適用例（続き）

調整された開発工数

E = E0 × Παi = 44 × 1.17 = 51 （人月）

開発期間

D = cEd = 2.5(51)0.39 = 9 （月）

上級COCOMO

中級COCOMO同様に，プログラム規模，及び，

開発特性（ソフトウェア，ハードウェア，要因，プロジェクト）をパラメータとするモデル．

15個の開発特性それぞれのランク付けを開発工

程毎に行い，対応表より工程毎の修正係数を求め，開発特性毎にその加重平均を求め，それらを掛け合わせる．

特性のランク付けの例

信頼性の要求度： RELY修正係数

要求分析＋概要設計

詳細設計コーディング＋単体テスト

結合テスト 全体

(15%) (30%) (30%) (25%) (100%)

Very Low 0.80 0.80 0.80 0.60 0.75

Low 0.90 0.90 0.90 0.80 0.88

Nominal 1.00 1.00 1.00 1.00 1.00

High 1.10 1.10 1.10 1.30 1.15

Very High 1.30 1.30 1.30 1.70 1.40

Extra High --- --- --- --- ---

Putnamモデル

Putnamが提案した，効果的なマクロ的工数投

入計画のためのモデル．

必要となる開発工数の時間変化を考慮した動的モデルである．

要求仕様定義以降の工程での工数の時間変化をRayleigh曲線で近似する．

工数と開発期間の関係からプロジェクト困難度を評価することが出来る．

Ｒａｙｌｅｉｇｈ曲線

Ｒａｙｌｅｉｇｈ曲線とする直感的理由

プロジェクトの計画策定や仕様作成を行う段階（プロジェクトの初期段階）では，ほんの少数の人員しか必要ない．

プロジェクトが進み詳細な仕事が必要になるにつれて，必要となる人員も増加し，やがて頂点に達する．

単体テストが終了するころには，必要な人員は減り始める．

リリース時には，必要な人員は1，2名程度である．

工数一定とすると．．．

無駄な工数

時間

工数

遅れて投入された工数

不足工数

開発の遅れ

遅れを取り戻すために必要となった工数

マンパワー方程式

(E > 0, td > 1)

Eｔ : 開発時刻tまでの累積工数 （人月または人年）

E : 総工数（開発工数＋保守工数） （人月または人）

td : が最大となる時刻（開発終了時刻＝開発期間D）

⎥⎦

⎤⎢⎣

⎡−⋅= 2

2

2 2exp

dd

t

ttt

tE

dtdE

ttd

dtdEt

dtdEt

開発 保守

累積工数

ttd

開発工数

Et

保守工数

61%

39%

0.39E⎟⎟⎠

⎞⎜⎜⎝

⎛⎥⎦

⎤⎢⎣

⎡−−= 2

2

2exp1

dt t

tEE

E

ソフトウェア方程式

(Ck > 0)L : 開発規模

Ck : 開発環境等に基づく補正係数

貧弱な開発環境： 2,000良好な開発環境： 8,000優秀な開発環境： 11,000

総工数Eと開発期間Dの関係

34

31

dk tECL =

dtdEt

43

3

43

3

DCL

tCLE

kdk==

プロジェクト困難度

例えば，総工数E=400（人年）のプロジェクトを3年で終えるとすると，

PD=400/(3*3)=44.4 （人／年）

半年短縮して2.5年で終えるとすると，

PD=400/(2.5*2.5)=64 （人／年）

となり，困難度が44%増加することになる．

02

2

22=

===t

t

d dtEd

DE

tEPD

まとめ

ソフトウェアの開発コスト≒開発工数

コスト見積りモデルは，ソフトウェアに関する定量的情報（多くの場合は「規模」）とコストの関係を表す．

コスト見積りモデルにより，開発期間やプロジェクト困難度も推定することが出来る．

より信頼度の高い見積りを行うためには，いくつかの見積り手法を併用し，それぞれの見積り結果をつき合わせて見ることが必要である．

2003年情報化実態調査

日経コンピュータ2003年11月17日号

特集：プロジェクト成功率は26.7％アンケート調査．

上場企業＆年間売上高100億円以上の企業が対象．

1,746社から回答あり（送付先は12,546社）．

「品質，コスト，進捗のすべてについて計画を遵守できた」＝「成功」と定義．

品質，コスト，納期の成功率

品質

要件定義，テスト，ユーザへの教育が不十分

予算規模が1000万弱のものは遵守率が高い

コスト

納期や品質よりは遵守率は高い

大規模プロジェクトほど悪い

予算規模が1000万弱のものは遵守率が高い

消費者対象のシステムは遵守率が高い

追加の開発作業の発生が主な原因（外注に投げるため）

納期

大規模プロジェクトほど納期が遅れる

予算規模が１億円で遵守率に差

消費者対象のシステムは遵守率が高い

要件定義が長引くことが最大の原因

その他

ＱＣＤを定量的に管理している企業が少ないＱ: 8.7%, C: 5.1%, D: 12.8%

対処療法が一般的

プロジェクトマネジメント技術の導入(PMBOK)が必要