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

ソフトウェアのコスト見積り
モデルを用いた工数予測
奈良先端科学技術大学院大学
講義資料
出典
z
D. V. Ferens: “COCOMO,” in Encyclopedia of
Software Engineering, J.J. Marciniak ed.,
John Weily and Sons, pp.103-110 (1994).
z
大筆豊：“ソフトウェアのコスト見積り技術”，情報処理，
33，8，pp.906-911 (1992.8)．
I. Sommerville: “Software Engineering,” 4th
ed., pp.587-610, Addison-Wesley (1996).
z
z
山田茂，高橋宗雄：“ソフトウェアマネジメントモデル入
門”，pp.36-50，共立出版（1993）．
ソフトウェア開発コスト
z
z
z
z
z
z
z
z
ハードウェアとソフトウェアの費用（保守費を含む）
旅費，訓練費
作業費（開発者への支払い）≒開発工数
光熱費
秘書等の間接的人員への支払い
ネットワーク費，通信費
ライブラリ等の集約的設備の費用
年金や社会保障費等
コスト見積り
z
ソフトウェア開発プロジェクトにおいて，必要となる
作業に要するコストを，プロジェクト開始前，あるい
は，プロジェクト実行中に推定すること．
z
見積り結果に基づき，
プロジェクト予算の算定
z スケジュールの決定
z ソフトウェア価格の決定
などが行われる．
z
コスト見積り手法
z
z
z
z
z
z
契約価格に基づく決定
パーキンソン（Parkinson）の法則
専門家による判定
類似プロジェクトからの類推
積算法
計算式等のコストモデルによる算出
契約価格に基づく決定
z
開発コストは，顧客がプロジェクトに投資可能なコ
ストに一致するという考え．
z
開発コストは，開発するソフトウェアに必要とされる
機能によって決まるのではなく，顧客の予算によっ
て決まることになる．
パーキンソン（Parkinson）の法則
z
ソフトウェア開発コストは，「作業に利用できる時間
を埋めるために拡大する」という考え．
z
開発コストは，客観的な分析によって決まるのでは
なく，利用できる資源により決まると考える．
z
例えば，納期まで1ヶ月で，担当者が5名であれば，必
要な開発工数は5人月となる．．．
専門家による判定
z
開発プロジェクトの対象領域（ドメイン）や利用予定
の開発技術に関する専門家複数人の意見を基に
コストを見積る．
z
各専門家の意見を比較，検討し，最終的な見積り
額は，専門家全員の合意の下に決定する．
例：デルファイ法
z
デルファイ法(Delphi Method)
z
z
z
z
z
z
Step1:専門家グループに，プログラムの要求仕様書と見
積り値記入用紙を配布する．
Step2:開発プログラムと見積り時の問題点を議論する．
Step3:相談せずに見積り値記入用紙に各自で記入する．
Step4:調整者が記入用紙を回収し，結果をまとめる．
Step5:見積り値のばらつきが許容範囲内であれば終了．
そうでなければ，Step6へ
Step6:専門家グループが再度集合してStep4の結果を
議論し，Step3へ．
見積り値記入用紙の例
1. プロジェクト名：
2. 見積り年月日：
3. 見積り実施回数：
4. 見積り結果集計：
× × × × ×××
0
20
40
60
×：見積り値
○：あなたの見積り値
□：見積り中央値
5. 次回の見積り値
6. 見積り値に関する理由
80
100
(KLOC)
類似プロジェクトからの類推
z
開発するソフトウェアとよく似た過去のプロジェクト
の実績に基づいてコストを見積る．
z
z
z
z
対象領域（ドメイン），開発業務や機能，開発方法，開
発言語，．．．
見積りコストは最も安いが，精度は低い．
初期の見積りに利用されることが多い．
過去の類似プロジェクトに参加した人が見積る，あ
るいは，プロジェクト実績がデータベース化されてい
ると信頼性が高くなる．
積算法
z
z
z
プロジェクトで必要となる作業を洗い出し，それら
作業毎の工数を積み上げる．
作業の洗い出し手法としては Work
Breakdown Structure（WBS）がある．
標準タスク法：開発工程を標準的な作業（タスク）
の集まりと定義する．開発組織の実績データに基
づいて各タスクの工数を与える．
WBSの例
レベル0
0.0
システムAの開発
WBSの例
0.0
レベル0
レベル1
1.0
2.0
要求分析システム仕様
3.0
システムAの開発
4.0
5.0
設計コーディングテスト
6.0
運用
WBSの例
0.0
レベル0
レベル1
1.0
4.0
3.0
2.0
要求分析システム仕様
レベル2
システムAの開発
3.1
コマンド処理
5.0
設計コーディングテスト
3.2
ユーザインタフェース
6.0
運用
WBSの例
0.0
レベル0
レベル1
1.0
5.0
設計コーディングテスト
3.2
3.1
コマンド処理
レベル3
4.0
3.0
2.0
要求分析システム仕様
レベル2
システムAの開発
ユーザインタフェース
3.2.1
3.2.2
入力
出力
6.0
運用
標準タスク法における積算例
標準タスクテーブル
タスク
複雑度
画面設計単純普通複雑
規模　大
a
d
g
中
b
e
h
小
c
f
i
a-i: 単位工数
プロジェクト要件
タスク
複雑度
画面設計単純普通複雑
規模　大 A
D
G
中
B
E
H
小 C
F
I
A-I: 件数
画面設計の工数
タスク
画面設計
規模　大
中
小
単純
a*A
b*B
c*C
複雑度
普通複雑
d*D g*G
e*E h*H
f*F
i*I
計算式等のコストモデルによる算出
z
コストに関する情報を基に作られたモデルを用いる
方法．
z
モデルは，ソフトウェアに関する定量的情報（多くの
場合は規模）とコストの関係を表す．
z
z
z
Walston and Felixモデル
COCOMOモデル
Putnumモデル
コスト見積りモデルの一般形
z
E=pLc
E: 開発工数（仕様決定後からシステムテスト
までのコスト）
L: 開発規模
p: 生産性調整係数, c: 定数
z
D=qEd
D: 開発期間（仕様決定後からシステムテスト
までの期間）
q: 定数, d: 定数
生産性変動要因
生産性調整係数p（E=pLｃ）に影響を与える要因．
z
z
z
z
z
z
人的要因（チームの大きさや熟練度）
問題要因（対象問題の型と重要性，仕様の構成，
制約）
プロセス要因（言語，開発技法）
プロダクト要因（対象システムの信頼性，規模,効
率，構造）
資源要因（対象ハードウェア，開発期間，予算）
ツール（ライブラリ，コンパイラ，テストツール）
Walston and Felixモデル
z
z
IBMのFederal Systems Divisionにおける
60個のプロジェクトのデータに基づくモデル．
対象プロジェクトの規模は 4,000 ～
467,000SLOC，工数は12～11,758人月．
z
z
z
z
開発工数 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
z
B. BoehmがTRWで収集したデータに基づき提
案したモデル（COnstructive COst MOdel）
z
開発規模をLOCで表し，工数を見積る．
z
パラメータによって，さまざまなプロジェクト形態にモデル
が合うように工夫されている．
モデルの概念や適用方法に関する文書が整備されてい
る．
多くの適用事例が報告されている．
z
z
B.W. Boehm: “Software Engineering Economics,
Prentice-Hall (1981).
プロジェクトの形態
z
organicモード
z
z
embeddedモード
z
z
比較的小規模の開発チームで，自社開発のような熟練
度の高い開発形態．在庫管理システム，科学技術計算
用パッケージ等の開発．
開発チームが大規模．厳しい制約条件の下で要求仕様
の変更も頻発する開発形態．OSの開発．
semi-detachedモード
z
上2モードの中間的形態．
COCOMOの階層
z
初級COCOMO：
z
z
中級COCOMO：
z
z
プログラム規模のみを変数とする．
プログラム規模と開発特性をパラメータとするモデル．
上級COCOMO：
z
プログラム規模と開発工程毎の開発特性をパラメータと
するモデル．
初級COCOMO
z
z
開発工数 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
semidetached
3.0
1.12
2.5
0.35
embedded
3.6
1.20
2.5
0.32
工数(人月)
規模と工数の関係（初級ＣＯＣＯＭＯ）
1000
900
800
700
600
500
400
300
200
100
0
embedded
semi-detached
organic
10
20
30
40
50
60
70
見積規模(KLOC)
80
90
100 110
中級COCOMO
z
z
調整された開発工数 E = E0 × Παi
開発期間 D = cEd (c>0, 0<d<1)
E0 : 平均的な開発工数
αi : 開発特性（コスト誘因）に基づく修正係
数．15個あり，それぞれ6段階のレベル
とレベル毎の修正係数が定義されてい
る．
中級COCOMOによる見積り手順
STEP1:開発規模見積り値を得る．
STEP2:開発形態に応じた平均的な工数を見積る．
STEP3:15個の開発特性それぞれのランク付けをし，
対応表より修正係数を求め，それらを掛け
合わせる．
STEP4:STEP2で求めた平均的な工数にSTEP3
で求めた修正係数を掛け，調整された工数
を見積る．
STEP5:STEP5で求めた調整された工数に基づい
て，開発期間等を見積る．
平均的工数の見積り
z
平均的開発工数 E0 = a(KLOC)b (a>0, b>1)
a
b
c
d
organic
3.2
1.05
2.5
0.38
semidetached
3.0
1.12
2.5
0.35
embedded
2.8
1.20
2.5
0.32
規模と平均的工数の関係
800
embedded
700
工数(人月)
600
semi-detached
500
400
300
organic
200
100
0
10
20
30
40
50
60
70
見積規模(KLOC)
80
90
100
110
開発特性（コスト誘因）
z
ソフトウェア特性
z
z
ハードウェア特性
z
z
実行時間制約，主記憶制約，仮想計算機の複雑さ，ターンアラウ
ンドタイム
開発要因特性
z
z
信頼性の要求度，データベースの規模，製品の複雑さ
要求分析者能力，アプリケーションの経験度，プログラミング能力，
仮想計算機の経験度，プログラミング言語の経験度
プロジェクト特性
z
近代的プログラミング手法の使用頻度，ソフトウェアツールの使用
頻度，開発スケジュールの要求度
特性のランク付けの例（１）
z
信頼性の要求度： RELY
ランク
Very Low
Low
修正係数
0.75
0.88
Nominal
1.00
High
Very High
Extra High
1.15
1.40
---
基準
Slight inconvenience
Low, easily
recoverable losses
Moderate, recoverable
losses
High financial loss
Risk to human life
特性のランク付けの例（２）
z
ターンアラウンドタイム： TURN
ランク
Very Low
Low
Nominal
High
Very High
Extra High
修正係数
--0.87
1.00
1.07
1.15
---
基準
Interactive
Avg. < 4 hrs
4 hrs < Avg. < 12hrs
12 hrs < Avg.
特性のランク付けの例（３）
z
プログラミング言語の経験度： LEXP
ランク
Very Low
Low
Nominal
High
Very High
Extra High
修正係数
1.14
1.07
1.00
0.95
-----
基準
< 1 month experience
4 months
1 year
3 years
中級COCOMOの適用例
z
対象プロジェクト
z
z
z
z
対象ソフトウェア：マイクロプロセッサの通信ソフト
開発形態：Embeddedモード
開発規模の見積り値(STEP1)： 10KLOC
平均的な工数見積り値
z
E0 = 2.8(10)1.20 = 44 （人月）
中級COCOMOの適用例（続き）
コスト誘因
信頼性の要求度
データベースの規模
製品の複雑さ
実行時間制約
主記憶制約
仮想計算機の複雑さ
ターンアラウンドタイム
要求分析者能力
アプリケーションの経験度
プログラミング能力
仮想計算機の経験度
プログラミング言
プログラミング手法
ツール
スケジュール
システム概要
普通
20,000バイト
通信処理
利用可能時間の70%
65Kのうち45K
民生用マイクロプロセッサ
2時間
上級システム分析者
3年
上級
6ヶ月
12ヶ月
1年以上
基本的なミニコンツール
9ヶ月
工数調整係数
ランク
N
L
VH
H
H
N
N
H
N
H
L
N
H
N
L
αi
1.00
0.94
1.30
1.11
1.06
1.00
1.00
0.86
1.00
0.86
1.10
1.00
0.91
1.10
1.00
1.17
中級COCOMOの適用例（続き）
z
調整された開発工数
z
z
E = E0 × Παi = 44 × 1.17 = 51 （人月）
開発期間
z
D = cEd = 2.5(51)0.39 = 9 （月）
上級COCOMO
z
z
中級COCOMO同様に，プログラム規模，及び，
開発特性（ソフトウェア，ハードウェア，要因，プロ
ジェクト）をパラメータとするモデル．
15個の開発特性それぞれのランク付けを開発工
程毎に行い，対応表より工程毎の修正係数を求め，
開発特性毎にその加重平均を求め，それらを掛け
合わせる．
特性のランク付けの例
z
信頼性の要求度： 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モデル
z
Putnamが提案した，効果的なマクロ的工数投
入計画のためのモデル．
z
z
z
必要となる開発工数の時間変化を考慮した動的モデル
である．
要求仕様定義以降の工程での工数の時間変化を
Rayleigh曲線で近似する．
工数と開発期間の関係からプロジェクト困難度を評価す
ることが出来る．
Ｒａｙｌｅｉｇｈ曲線
Ｒａｙｌｅｉｇｈ曲線とする直感的理由
z
z
z
z
プロジェクトの計画策定や仕様作成を行う段階（プ
ロジェクトの初期段階）では，ほんの少数の人員し
か必要ない．
プロジェクトが進み詳細な仕事が必要になるにつ
れて，必要となる人員も増加し，やがて頂点に達す
る．
単体テストが終了するころには，必要な人員は減り
始める．
リリース時には，必要な人員は1，2名程度である．
工数一定とすると．．．
工数
不足工数
無駄な
工数
遅れて投入
された工数
遅れを取り
戻すために
必要となっ
た工数
開発の遅れ
時間
マンパワー方程式
z
⎡ t2 ⎤
dE t E
= 2 t ⋅ exp ⎢−
2⎥
dt
td
⎣ 2td ⎦
(E > 0, td > 1)
Eｔ : 開発時刻tまでの累積工数（人月または人年）
E : 総工数（開発工数＋保守工数）（人月または人）
dE t
td : dt が最大となる時刻（開発終了時刻＝開発期間D）
dE t
dt
保守
開発
td
t
累積工数
Et
E
保守
工数
61%
⎛
⎡ t2 ⎤⎞
Et = E ⎜⎜ 1 − exp ⎢− 2 ⎥ ⎟⎟
⎣ 2td ⎦ ⎠
⎝
0.39E
開発
工数
39%
t
td
ソフトウェア方程式
z
1
3
4
3
L = Ck E td
(Ck > 0)
L : 開発規模
Ck : 開発環境等に基づく補正係数
dE t
dt
z
貧弱な開発環境： 2,000
良好な開発環境： 8,000
優秀な開発環境： 11,000
総工数Eと開発期間Dの関係
L3
L3
E= 3 4 = 3 4
Ck td Ck D
プロジェクト困難度
2
d
Et
E
E
z PD =
= 2 =
2
td D
dt 2 t =0
例えば，総工数 E=400（人年）のプロジェクト
を3年で終えるとすると，
PD=400/(3*3)=44.4 （人／年）
半年短縮して2.5年で終えるとすると，
PD=400/(2.5*2.5)=64 （人／年）
となり，困難度が44%増加することになる．
まとめ
z
z
z
z
ソフトウェアの開発コスト≒開発工数
コスト見積りモデルは，ソフトウェアに関する定量的
情報（多くの場合は「規模」）とコストの関係を表す．
コスト見積りモデルにより，開発期間やプロジェクト
困難度も推定することが出来る．
より信頼度の高い見積りを行うためには，いくつか
の見積り手法を併用し，それぞれの見積り結果を
つき合わせて見ることが必要である．
2003年情報化実態調査
z
z
日経コンピュータ2003年11月17日号
特集：プロジェクト成功率は26.7％
z
z
z
z
アンケート調査．
上場企業＆年間売上高100億円以上の企業が対象．
1,746社から回答あり（送付先は12,546社）．
「品質，コスト，進捗のすべてについて計画を遵守でき
た」＝「成功」と定義．
品質，コスト，納期の成功率
品質
z
z
要件定義，テスト，ユーザへの教育が不十分
予算規模が1000万弱のものは遵守率が高い
コスト
z
z
z
z
z
納期や品質よりは遵守率は高い
大規模プロジェクトほど悪い
予算規模が1000万弱のものは遵守率が高い
消費者対象のシステムは遵守率が高い
追加の開発作業の発生が主な原因（外注に投げ
るため）
納期
z
z
z
z
大規模プロジェクトほど納期が遅れる
予算規模が１億円で遵守率に差
消費者対象のシステムは遵守率が高い
要件定義が長引くことが最大の原因
その他
z
ＱＣＤを定量的に管理している企業が少ない
z
z
z
Ｑ: 8.7%, C: 5.1%, D: 12.8%
対処療法が一般的
プロジェクトマネジメント技術の導入(PMBOK)が
必要

Download Report