SEC主催セミナー
IPA 独立行政法人情報処理推進機構
SEC 技術本部 ソフトウェア・エンジニアリング・センター
Information-technology Promotion Agency, Japan
Software
Engineering
Center
ソフトウェア開発データ白書と
定量データの活用方法
専門委員 (株)CSK 小椋 隆
(東京)2011年09月26日
SEC
Software Engineering for Mo・No・Zu・Ku・Ri本日の内容
1.定量的マネジメントの必要性
2.定量データの実践的活用方法と事例
2-1.活用その1(品質)
2-2.活用その2(工数・工期)
3.実践的活用をサポートするツール
SEC
Software Engineering for Mo・No・Zu・Ku・Ri市場競争の激化
トラブルの多発
・低コスト、短納期開発
・多機能化、高性能化
安全・安心の
確保要請が増大
・信頼のおけるマネジメント
・トラブル発生未然抑止
人海戦術的な手段による対処
不適切な見積、生産性の見誤り
システムへの
要求が増大
理 想
現 実
KKD(勘、経験、度胸)
ネットワークの普及
ビジネスモデルの転換
リスクの増大
IT産業を取り巻く環境の変化
期
待
・
ニ
ー
ズ
SEC
Software Engineering for Mo・No・Zu・Ku・Riユーザ
ベンダ
ユーザ・ベンダ間の合意形成
【事業計画】
・事業目的
・事業領域/規模
・投資/回収
・事業スケジュール
【プロジェクト計画】
・開発目的
・スコープ/規模
・予算
・開発スケジュール
要件
実現性
整合
「やりたいこと」と「できること」の整合が必要だが・・・
・共有しやすい見積り手法がない
・初期の仕様は固めにくく、早期契約時の適切な見積りが困難
・要件決定の遅れ、プロジェクト途中での仕様変更の発生 など
定量データに裏付けられたマネジメントが必要
SEC
Software Engineering for Mo・No・Zu・Ku・Ri定量データ使っていますか?
プロジェクトデータを
している
プロジェクトデータを
している
76%
53%
SECセミナーのアンケート結果
>
収 集
活 用
SEC
Software Engineering for Mo・No・Zu・Ku・Ri定量データの必要
定量データが十分集まれば ・・・ こんな活用ができる
ユーザ
ベンダ
経営層
業務・情報システム部門
組織長・スタッフ
プロジェクト管理者
・IT投資、概略計画の妥当性、実現性の目安
・予算数値、根拠の制御
・ベンダからの見積の比較と評価、強み/弱みの認識
・計画策定、目標値の制定、QCDの妥当性評価
・予実差異の分析、完了評価、開発能力の評価
経営層
プロジェクトマネージャ
プロジェクトリーダ
・自社の強み・弱み、生産性などの開発力の認識
・規模、工数、工期、品質の見積り、計画策定、制御
・オフショア等、外部委託先評価
PMO
品質保証部門
・定量データベースの構築
・自社プロジェクトのベンチマーキング、モニタリング
ユーザ、ベンダ間の合意形成
SEC
Software Engineering for Mo・No・Zu・Ku・RiSECの取組みとデータ白書の目的
定量的アプローチによる科学的マネジメントの普及拡大
・モノサシとしての
精度を高めていく
・新たなモノサシや課題抽出の
切り口を提案する
「ソフトウェア開発データ白書」として公開
(2010年度は23企業、2584プロジェクトのデータ)
2010年11月
発行
2010-
2011
1774
942
1418
2056
2005
2006
2007
2008
2584
2327
2009
メーカー系、ユーザ系、独立系の複数のベンダからデータを収集
SEC
Software Engineering for Mo・No・Zu・Ku・Riデータ白書2010-2011の構成
プロジェクトの特性
(プロファイル)
開発種別
アーキテクチャ
業 種
開発言語
開発ライフ
サイクルモデル
プラットフォーム
代表的な要素
生産性
信頼性
工 期
規 模
工 数
1章 背景と本書の目的
2章 収集データについて
3章 分析について
4章 収集データのプロファイル
5章 プロジェクトの
主要要素の統計
6章 工数、工期、規模の
関係の分析
7章 信頼性の分析
8章 工程別の分析
9章 生産性の分析
10章 予実分析等
付録A~G
データ項目の定義や
収集データ年別プロファイル 等々
SEC
Software Engineering for Mo・No・Zu・Ku・Ri【参考】データ提供状況
データ提供企業一覧
(23社:50音順 2010年10月1日現在)
TIS株式会社
東芝情報システム株式会社
日本電子計算株式会社
日本ユニシス株式会社
株式会社野村総合研究所
パナソニック株式会社
株式会社日立製作所
株式会社日立ソリューションズ
富士通株式会社
三菱電機
インフォメーションシステムズ株式会社
リコー IT ソリューションズ株式会社
NECソフト株式会社
NTTソフトウェア株式会社
株式会社 NTTデータ
沖ソフトウェア株式会社
沖電気工業株式会社
キヤノンIT ソリューションズ株式会社
クボタシステム開発株式会社
株式会社 構造計画研究所
株式会社 CSK
新日鉄ソリューションズ株式会社
住友電工情報システム株式会社
大同生命保険株式会社
SEC
Software Engineering for Mo・No・Zu・Ku・Ri本日の内容
1.定量的マネジメントの必要性
2.定量データの実践的活用方法と事例
2-1.活用その1(品質)
2-2.活用その2(工数・工期)
3.実践的活用をサポートするツール
SEC
Software Engineering for Mo・No・Zu・Ku・RiITシステムの障害の影響が深刻化し、高品質な情報システムが
求められている
「品質を高める」=品質を測定する物差しが必要
「品質が高い」=開発者から利用者への説明責任
定量的品質予測が必要
定量的品質予測のために
どうやって品質を予測すればいいか
そのためには、何をどのように測定すればいいのか
SEC活動として
2006年~2008年、定量データ分析部会WGにて、参加企業・大学
が実際に取り組んでいる品質予測の手法を整理
2008年から2010年、上流工程に焦点をあてたプロセス
(特に組織的準備)と定量的品質管理の阻害要因を整理
定量的品質管理のススメ
SEC
Software Engineering for Mo・No・Zu・Ku・Ri定量的品質管理の考え方
品質の測定と予測の枠組み
(注)測定、対策はそれぞれの工程で実施される。
蓄積データ
データの受渡し
人の作業
作業の流れ
分析・
モデル化
モデル
【 プロジェクト 】
【 プロジェクト 】
《 プロジェクト生産活動 》
要件
定義
基本
設計
詳細
設計
製作
総合
テスト
結合
テスト
【 プロジェクト 】
データ
計画(P)
対策(A)
《 プロジェクトマネジメント活動 》
モデルの改善・見直し
単体
テスト
データ蓄積
測定(D)
分析・予測(C)
どのようなプロセスで
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 測定単位(例)
測定単位を小さくして品質データ(欠陥数など)を測定することにより、
詳細な品質管理・分析が可能
その測定値を集計することにより当該工程の品質管理・分析が可能
工 程 基本設計 詳細設計
製 作
単体テスト 結合テスト 総合テスト
システム・
サブシステム
◎
◎
◎
◎
◎
◎
●
◎
◎
◎
◎
◎
●
◎
◎
●
●
●
●
分
解
粒
度
測
定
単
位
の
業務機能
プログラム 数100L~1KL
-
想定規模
100KL~1ML
20KL~50KL
数KL~10KL
●
:その工程完了時に最小の測定単位、
◎
:その工程で主に着目する測定単位
測
定
単
位
どれくらいの粒度で
測定単位について
SEC
Software Engineering for Mo・No・Zu・Ku・Ri
対象工程
測 定 量
単 位
測 定 方 法
全工程
規模
FP、LOC
Function Point (FP) では測定方法 、LOCは測定
ルールを明確にする
作業工数
人時
設計工程
レビュー回数
回数
レビュー時間
人時
Σ 各レビューアのレビュー実施時間
レビュー対象規模
ページ数
レビュー対象ドキュメント量(A4換算ページ数)
レビュー指摘件数
件数
レビュー記録票の指摘事項数
テスト工程
欠陥数
件数
障害連絡票の欠陥数
テスト項目数
項目数
テスト仕様書の項目数
基 本 測 定 量
導 出 測 定 量
対象工程
測 定 量
単 位
算 出 方 法
設計工程
レビュー指摘密度
件数÷FP,LOC 件数÷ページ数 レビュー指摘件数÷規模 レビュー指摘件数÷レビュー対象規模レビュー工数密度
人時÷FP,LOC 人時÷ページ数 レビュー時間÷規模 レビュー時間÷レビュー対象規模レビュー指摘効率
人時÷件数 レビュー指摘件数÷レビュー工数テスト工程
欠陥密度
件数÷FP,LOC 欠陥数÷規模テスト密度
項目数÷FP,LOC テスト項目÷規模品質改善の立案には、属性情報も必要
代表的な基本測定量と導出測定量
何を
SEC
Software Engineering for Mo・No・Zu・Ku・Ri分析名称
(モデル名)
概要
管理図分析
(閾値モデル)
データの分布がUCLとLCLに対してどの位置に
プロットされるかを見て、データが正常値である
か外れ値であるかを判断する分析方法
ゾーン分析
(ゾーンモデル)
与えられた分析のテーマを、ある特徴に着目し
た視点によってゾーンに分割し、各ゾーン毎に
分析を行う
曲線近似分析
(回帰モデル)
二つのデータ列の関係を回帰式と呼ぶ近似曲
線で代替することで分析を行う
トレンド分析
(トレンドモデル)
過去のプロジェクトの実績データの時間的なパ
ターンと、現在のプロジェクトの実績データのト
レンドを比較し、過去のプロジェクトの最終品質
と同等な結果となるかを予測する分析である
チェックリスト分析
(チェックリスト)
チェックリストは、与えられたテーマに対して
チェックする項目をリストにしたもの
UCL LCL 品質不良と予測 レビュー指摘密度 ゾーン4 ゾーン3 ゾーン9 ゾーン2 ゾーン1 ゾーン7 ゾーン6 ゾーン5 ゾーン8 尺 度 尺 度 単体テスト 結合テスト 総合テスト 検 出 欠 陥 密 度 UCL CL LCL Xプロジェクト Yプロジェクト 要求分析のレビュー指摘チェックリスト 大分類 小分類 レビュー指摘事項 評価 重み ポイント 備考 全体 網羅性 記載内容の範囲についての記述があり、明確か ○ A 1.2 要求の網羅性について記載があるか ○ B 1.0 要求に漏れがないかの確認をしているか × A 0.0 整合性 内容に矛盾がないか ○ A 1.2 要求の粒度は揃っているか × B 0.0 了解性 主語が明確であるか ○ C 0.8 事実と推測が分離しているか ○ B 1.0 数値表現できるところは数値で表現しているか ○ A 1.2 ※ 評価(○:1、×:0)、重み(A:1.2、B:1.0、C:0.8) 6.4 近似曲線 二つの要因を回帰式で分析 ① ここの値から ②ここの値を 予測するゾーン分析
どうみるか
管理図分析
曲線近似分析
トレンド分析
チェックリスト分析
分析について(分析モデル一覧)
詳細については、SEC BOOKの「品質予測のススメ」及びその続編を参照
SEC
Software Engineering for Mo・No・Zu・Ku・Ri データ白書における「工程別の分析」について
開発5工程全体ではなく、工程別に工数と工期、レビューおよび
テストケースとバグ密度の分析結果を示している。
8.1 工程別の工期、工数
工期や工数の工程別比率に関する分析
8.2 レビュー指摘件数
基本設計、製作工程のレビュー指摘件数に関する分析
8.3 レビュー実績工数
設計工程のレビュー実績工数、各工程のレビュー実績工数比率
に関する分析
8.4 テスト工程別のテストケース数と検出バグ数
結合テスト、総合テスト(ベンダ確認)の2工程を対象に
「規模当りと工数当りのテストケース数」、「検出バグ現象数」、
「検出バグ原因数」を分析
ソフトウェア開発データ白書の工程別分析
品質関連
SEC
Software Engineering for Mo・No・Zu・Ku・Riレビュー指摘件数(1)
「レビュー指摘件数」について
設計工程及び制作工程のレビュー指摘件数に関する分析結果
を示している。
レビュー指摘件数に対する密度として、以下の3つの観点により
分析結果を基本統計量として示している。
規模当り(FP規模当り、SLOC規模当り)の件数
工数当りの件数
ページ当りの件数
[件/ページ]
N
最小
P25
中央
P75
最大
平均
標準偏差
113
0.000
0.093
0.266
0.500
2.178
0.419
0.482
例) ページあたりの基本設計レビュー指摘件数の基本統計量
SEC
Software Engineering for Mo・No・Zu・Ku・Riレビュー指摘件数(2)
「レビュー指摘件数」のデータの活用(1)
ソフトウェアの品質を把握する際、また品質目標を策定する際、
その一つの考え方に閾値モデル(管理図分析)がある。
ある尺度の閾値によって、例えば管理図分析においては、
データの分布がUCLとLCLに対して、どの位置にあるかで、データ
が正常値であるか外れ値であるかを判定する考え方である。
UCL(上部管理限界線 Upper Control Limit)
LCL(下部管理限界線 Lower Control Limit)
例) 要求分析・設計における品質予測の事例(閾値モデル)
UCL
LCL
レビュー
指摘密度
要注意!
SEC
Software Engineering for Mo・No・Zu・Ku・Riレビュー指摘件数(3)
「レビュー指摘件数」のデータの活用(2)
UCLやLCLには、品質データが正規分布する際には、標準偏差
の何倍かを目安に策定する考え方がある。
しかし、ソフトウェア開発のデータ、例えばレビュー指摘件数の
データは正規分布しないこともある。
その場合、基本統計量で示している四分位点のような、外れ値
に引きずられにくい統計量を参照するのも一考である。
留意点:
ただし、P25とP75では、あくまでもその箱の中には50%の
データのみが入るような値なので、品質指標としてUCLやLCL
に直接設定することは早計である。
データ白書では分布や特徴を見る一つの統計量として明示して
いるものではあるので、その点を考慮して参照する必要がある。
SEC
Software Engineering for Mo・No・Zu・Ku・Riレビュー実績工数(1)
「レビュー実績工数」について
データ白書では、基本設計、詳細設計工程について、ページ
あたりの対象工程におけるレビュー実績工数を、基本統計量
として示している。
また、基本設計、詳細設計、制作の3工程について、それぞれ
該当する工数に対するレビュー実績工数を、レビュー実績工数
比率として示している。
プロジェクトのレビューの妥当性確認や、ドキュメントページ数
からのレビュー工数の予測、工程内工数からのレビュー工数
の予測などに利用することが考えられる。
SEC
Software Engineering for Mo・No・Zu・Ku・RiX軸
[人時/ページ]
N
最小
P25
中央
P75
最大
平均
標準偏差
43
0.018
0.065
0.223
1.166
120.267
12.489
30.260
レビュー実績工数(2)
「レビュー実績工数」のデータの見方
設計工程のレビュー実績工数と、工程別レビュー実績工数比率の
基本統計量を以下に示す。
ページあたりの基本設計レビュー実績工数の基本統計量(新規開発)
工程別レビュー実績工数比率の基本統計量
データ白書2010-2011 P209、図表8-3-1[比率]
レビュー実績工数比率
N
最小
P25
中央
P75
最大
平均
標準偏差
基本設計
211
0.003
0.030
0.068
0.136
0.667
0.102
0.106
詳細設計
204
0.002
0.030
0.065
0.110
0.450
0.093
0.095
製作
153
0.001
0.014
0.029
0.055
0.825
0.062
0.117
データ白書2010-2011 P211、図表8-3-6SEC
Software Engineering for Mo・No・Zu・Ku・Riレビュー実績工数(3)
「レビュー実績工数」のデータの活用
ゾーン分析での活用例:
レビュー量とレビュー指摘の適切性の評価
レビュー工数密度とレビュー指摘密度の双方を合わせた視点
から品質を分析し、傾向性を読み取る。
ゾーン分析の目標範囲(目標の上限と下限)の参考
基本統計量の分析結果を参考にする。ただし、
P25、P75を
直接指定するのではなく、策定の際の参考情報とする。
⑧
⑤
⑥
⑦
①
②
⑨
③
④
レビュー指摘密度
(件/ページ)
レビュー工数密度
(人時/ページ)
上限
下限
下限
上限
例)
ページあたりの基本設計
レビュー実績工数の
基本統計量を参考に
策定する。
P25
P75
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 「規模あたりのテストケースと検出バグ数」について
データ白書では以下について示している。
結合テスト及び総合テストにおける規模あたりのテストケース数
(テストケース密度)
規模あたりの検出バグ数(検出バグ密度)
テストケース数や検出バグ数の予測の目安に。
基本統計量にある中央値の利用
P25、P75を上下限値として、妥当性確認に利用
テストケース密度と検出バグ密度を利用した、ゾーン分析に
による品質管理のヒントに。
規模あたりのテストケース数と検出バグ数(1)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri規模あたりのテストケース数と検出バグ数(2)
「規模あたりのテストケースと検出バグ数」のデータの見方
結合テストと総合テストのデータの見方:
結合テストと総合テストを横並びにすることで、双方の関係
として、傾向を見ることができる。
結合テストケース数は総合テストケース数の約4倍弱と見える。
FP 規模あたりの
テストケース数
(全開発種別)
箱ひげ図
データ白書2010-2011 P212、図表8-4-1FP 規模あたりの
検出バグ数
(全開発種別)
箱ひげ図
データ白書2010-2011 P212、図表8-4-2SEC
Software Engineering for Mo・No・Zu・Ku・Ri 「規模あたりのテストケースと検出バグ数」のデータの活用
ゾーン分析によるプロダクト品質予測の活用例
結合テストケース密度の上下限値と、結合テストバグ密度の上下限値
について、基本統計量のP25とP75を参考に策定。
⑧
⑤
⑥
⑦
①
②
⑨
③
④
バグ密度
(件数/KFP)
テスト密度
(ケース数/KFP)
上限
下限
下限
上限
[件/KFP]
N
最小
P25
中央
P75
最大
平均
標準偏差
結合テストケース数/KFP
54
16.8
563.2 1,662.6 2,760.2 13,296.3 2,077.2
2,230.2
総合テストケース数/KFP
51
11.1
196.4
429.3 1,341.1 12,069.9 1,234.8
2,000.9
結合テストバグ現象数/KFP
43
0.0
39.9
79.1
146.1
558.5
128.5
136.6
総合テストバグ現象数/KFP
39
0.0
3.9
22.6
49.7
884.3
67.0
150.7
結合テストバグ原因数/KFP
61
4.3
32.4
66.1
141.1
558.5
114.5
127.6
総合テストバグ原因数/KFP
58
0.0
8.1
20.9
60.6
390.6
54.0
84.0
FP 規模あたりのテストケース数、検出バグ数の基本統計量(新規開発、IFPUG グループ)
データ白書2010-2011 P214、図表8-4-8直接設定するのではなく、
あくまでも上下限値の
策定時に参考と
している例。
規模あたりのテストケース数と検出バグ数(3)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri本日の内容
1.定量的マネジメントの必要性
2.定量データの実践的活用方法と事例
2-1.活用その1(品質)
2-2.活用その2(工数・工期)
3.実践的活用をサポートするツール
SEC
Software Engineering for Mo・No・Zu・Ku・Riソフトウェア開発ライフサイクルから見た活用事例
局面別の定量データ活用ポイントと事例
ソフトウェア開発ライフサイクルを通し、様々な局面について、
定量データの活用ポイントや事例を示す。
基本設計
詳細設計
製作
結合テスト
総合テス
ト
定量的プロジェクト管理・マネジメント
見積り
プロジェクト
評価
計画
①:見積り
②:計画
③:コントロール
④:評価
SEC
Software Engineering for Mo・No・Zu・Ku・Ri①見積り:規模、工数、工期のデータ活用
データ活用のねらい
プロジェクトの規模と工数や、工数と工期との間に定式性や
特性を見出し、適正な工数や工期の範囲を目安にできる
ようにする。
工数
規模
下限50%
上限50%
▲
妥当性
の目安
工期
(月数)
工数
下限95%
上限
95%
▲
工期短縮
限界
①50%の信頼幅の上下限内に
入っていれば妥当性が高い。
入っていなければ、差異理由
を明確にし、見積りの見直しに
繋げる。
②工数・工期短縮の要求に対し、
それが対応可能かどうか、
信頼幅95%の下限値を
限界の目安とする。
SEC
Software Engineering for Mo・No・Zu・Ku・Ri【参考】白書の表記と見方の留意点(1)
対数変換による分析
ソフトウェア開発プロジェクトのデータは正規分布していないこと
が多い。
(例えば規模の分布:規模の大きい方に裾野が長い分布)
・対数に変換するとほぼ正規分布と見なせることが多く、裾野を含めた
全体の状況が見やすい。
・「正規分布」であることを前提としている相関係数の有意性や回帰式の
予測値の信頼区間推定を求めることができる。
FP実績値(調整前) N=211 0 10 20 30 40 ~1 0 0 ~3 0 0 ~5 0 0 ~7 0 0 ~9 0 0 ~1 1 0 0 ~1 3 0 0 ~1 5 0 0 ~1 7 0 0 ~1 9 0 0 ~2 1 0 0 ~2 3 0 0 2401~ FP実績値(調整前) 件数 Log (FP実績値(調整前)) N=211 0 5 10 15 20 25 30 35 40 45 1.11 1.32 1.52 1.72 1.93 2.13 2.33 2.54 2.74 2.94 3.15 3.35 3.55 3.76 3.96 次の級 Log (FP実績値(調整前)) 件数詳細は次の文献を参照のこと
※ 「プロジェクトデータ分析の指針と分析事例」:古山恒夫、SEC journal No3、 pp6~pp13、 2005
対数
スケール
化
正規
分布
裾野の分布が
分かり易い
SEC
Software Engineering for Mo・No・Zu・Ku・Ri【参考】白書の表記と見方の留意点(2)
対数変換後のデータともとのデータの見方
データを対数スケールに変換すると相関が明確になる場合がある。
・散布図の表記において、必要に応じ対数スケール表示を取り入れている。
・元のスケールに戻すと有効範囲(誤差)は右上方向に開く。
・もとのデータに戻し、50%の信頼幅を示すと・・・
規模や工数が大きくなるに伴い
信頼幅が広がる
ため、規模と工数の
関係など、妥当性の検証時は
それを考慮して判断する
必要がある。
FP規模と工数 (新規開発、IFPUGグループ) N=188 0 50,000 100,000 150,000 200,000 250,000 300,000 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 FP実績値(調整前) 実績工数(開発5 工程) [人時] y(50%) y(-50%) 実績値Copyright IPA SEC
FP規模と工数 (新規開発、IFPUGグループ) N=188 0 1 2 3 4 5 6 0 1 2 3 4 5 FP実績値(調整前) 実績工数(開発5 工程) [人時] log(y)(50%) log(y)(-50%) 実績値 10 100 1,000 10,000 100,000 1 1,000,000 100,000 10,000 1,000 100 10 1
Copyright IPA SEC
50%信頼幅
もとのスケールに戻す
SEC
Software Engineering for Mo・No・Zu・Ku・Ri①見積り:「規模と工数」のデータの見方
データの関係性
新規開発、IFPUGグループ
FP規模と工数には正の「相関」が認められる。
例) 新規開発、IFPUGグループ
工数 = A × (FP規模)**B B=1.19 (Aは係数)
(B = 1.19 の場合、FP規模が2倍になると、工数は約2.28倍になる。)
0 50,000 100,000 150,000 200,000 250,000 300,000 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 FP実績値(調整前)[FP] 実績工数 (開発 5 工程 ) [ 人時 ] y(50%) y(-50%)Copyright IPA SEC N=283 1 10 100 1,000 10,000 100,000 1,000,000 10,000,000 1 10 100 1,000 10,000 100,000 FP実績値(調整前)[FP] 実績工数 (開発 5 工程 ) [ 人時 ]
Copyright IPA SEC N=283 データ白書2010-2011 P135、図表6-4-11 データ白書2010-2011 P134、図表6-4-9 FP規模と工数 (新規開発、IFPUGグループ) 信頼幅50%付き FP規模と工数 (新規開発、IFPUGグループ) 対数表示
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 0 50,000 100,000 150,000 200,000 250,000 300,000 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 FP実績値(調整前)[FP] 実績工数 (開発 5 工程 ) [ 人時 ] y(50%) y(-50%)Copyright IPA SEC
N=283
①見積り:工数の見積り(事例)
規模と工数のデータの使い方
例)新規開発、IFPUGグループ
・4,000FPの規模の工数を
50%の信頼幅から読み取る。
⇒
・約40,000人時から110,000人時
(約250人月~690人月)の範囲。
これを、
妥当性の目安
とする。
留意点
規模が大きくなると
規模の増加率以上に工数が増大する。
一般的に規模が大きくなると関係者も多くなり、間接的な工数が
増加する。
40,000 110,000 ▲ FP規模と工数 (新規開発、IFPUGグループ) 信頼幅50%付き データ白書2010-2011 P134、図表6-4-9SEC
Software Engineering for Mo・No・Zu・Ku・Ri①見積り:「工数と工期」のデータの見方
データの関係性
新規開発(開発5工程)
工期(月数)は工数の
3乗根に概ね比例。
例) 工期 = A × (工数)* * 0.31 (Aは係数)
信頼幅95%の下限値より下にはプロジェクトがほとんどない。
⇒ 工数に対する工期の実現可能性を考える目安
0 5 10 15 20 25 30 35 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数 (開発 5 工程 ) [ 月 ] y(50%) y(-50%) y(95%) y(-95%)Copyright IPA SEC
N=493
開発5 工程の工数と工期(新規開発)信頼幅50%、95%付き
データ白書2010-2011 P124、図表6-3-2
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 0 5 10 15 20 25 30 35 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数 (開発 5 工程 ) [ 月 ] y(50%) y(-50%) y(95%) y(-95%)Copyright IPA SEC
N=493
①見積り:工期の見積り(事例)
工数と工期のデータの使い方
例)新規開発、開発5工程
・工数が約60,000人時
(約375人月)の場合、
工期(月数)の中央値は
12~13ヶ月
・信頼幅95%の下限値の
工期(月数)を見てみると
約5ヶ月
留意点
工期短縮には限界がある。
12ヶ月から工期短縮を目指しても、5ヶ月以下にするのは難しい。
また、
50%の下限値は
約9ヶ月であり、
目標の目安の一つ。
12~13
開発5工程の工数と工期 (新規開発) 信頼幅50%、95%付き
(60,000、5.0)
データ白書2010-2011 P124、図表6-3-2 ▲SEC
Software Engineering for Mo・No・Zu・Ku・Ri①見積り:改良開発のテスト見積り(参考)
改良開発の見積りにおけるテスト量について
ソフトウェア改良開発における見積りは、新規開発に比べて、
以下のように改良開発の特質を考慮したテスト量の見積りが
重要である。
既存の母体システムにおける品質面での考慮
(既存システムの品質が思わしくない場合、品質を確保する
作業が必要)
テスト巻き込み規模の把握
(変更の際に影響を受ける部分を表す規模)
ソフトウェア開発データ白書では、改良開発のプロジェクトを
対象にSLOC規模とテストケース数の関係を母体規模別に
示している。
SEC
Software Engineering for Mo・No・Zu・Ku・Ri①見積り:改良開発のテスト見積り(参考)
母体規模別のSLOCとテストケース数
・母体規模を大・中・小の3つに分け、
散布図の中で識別して示している。
大:200以上
中:50~200未満、
小:50未満 (単位 KSLOC)
・母体規模を含まない実効SLOC
実績値が100KSLOC以下で、テスト
ケース数の大きなプロジェクには、
母体規模が大きいものが多い。
留意点
実効値としての規模だけではなく、
母体の規模も考慮し
、テスト
ケース数や、生産性を加味した
見積りや計画策定が必要。
0 5,000 10,000 15,000 20,000 25,000 0 100,000 200,000 300,000 400,000 500,000 600,000 700,000 実効SLOC実績値[SLOC] テ ス ト ケ ー ス 数_総合テ ス ト ( ベ ン ダ確認) a:母体規模小 b:母体規模中 c:母体規模大Copyright IPA SEC
N=107
母体規模別SLOC 規模とテストケース数
(総合テスト(ベンダ確認))(改良開発)
データ白書2010-2011 P227、図表8-4-45
SEC
Software Engineering for Mo・No・Zu・Ku・Ri②計画:開発条件の検討(事例)
赤
▲
:当初案
緑
▲
:計画変更提案
規模と工数の軸反転
工数と工期
利用イメージ・事例
想定シーン:計画局面における開発条件の検討。
定量データの利用目的:システム開発における、規模、工数、工期
からの適切な計画案の策定。
見方・使い方:
SEC
Software Engineering for Mo・No・Zu・Ku・Ri②計画:開発条件の検討(事例)
(1)図表から認識できること
・想定工数に対し工期が信頼幅線下位50%以下と相対的に短くリスクが高い。
・しかし規模は反転した信頼幅線の右50%の近傍で、相対的に工数は多め
(低生産性)である。
(2)利用・想定事例
ケース1:発注側の要件として工期を優先する場合、開発規模を小さくする
ため機能を削減するか、または分割開発により工期をずらし、
機能毎の優先度と必要時期を協議する。
ケース2:発注側が工期に拘らない場合、コストを守ることを前提に、工期を
50%信頼幅の中央部近傍の12~14ヵ月を提案する。
ケース3:開発対象機能(規模)を優先する場合、工期を12~14ヵ月で提案
すると共に、工数を50%信頼幅の中央部近傍の80,000人時を
提案する。
(図中の緑
▲
位置)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri②計画:工数比率と工期比率のデータ活用
要員山積みの妥当性確認
各工程にどの位の工数と期間がかかるか、要員を何人程度投入
するか、工数比率と工期比率のデータから妥当性を確認する。
① 開発すべきシステムの構築に必要な総工数、全体工期を算出
② 工数比率によって、各工程に必要な工数を算出
③ 工期比率によって、各工程に必要な期間を算出
④ 上記②と③から、各工程に必要な要員数を算出
基本設計
詳細設計
製作
結合テスト
総合テスト
工数
工期
要員数
合計
②
④
①
③
SEC
Software Engineering for Mo・No・Zu・Ku・Ri②計画:工数比率のデータの見方
データの関係性
比率が高い工程には「それだけ多くの作業工数がかかる」ということ。
プロジェクト全体の工数の35%弱を製作工程が占めている。
[比率]
工程
N
最小
P25
中央
P75
最大
平均
標準偏差
要件定義
260
0.001
0.045
0.079
0.132
0.672
0.098
0.082
開発5工程
260
0.328
0.868
0.921
0.955
0.999
0.902
0.082
[比率]
工程
N
最小
P25
中央
P75
最大
平均
標準偏差
基本設計
487
0.001
0.095
0.143
0.205
0.589
0.161
0.094
詳細設計
487
0.016
0.117
0.167
0.222
0.613
0.175
0.084
製作
487
0.018
0.275
0.355
0.449
0.847
0.370
0.143
結合テスト
487
0.002
0.110
0.156
0.211
0.938
0.167
0.093
総合テスト(ベンダ確認)
487
0.000
0.061
0.116
0.172
0.564
0.127
0.086
工数比率
・・・各開発工程を実施するのに必要な作業工数の比率
(新規開発)
データ白書2010-2011 P204、図表8-1-8 データ白書2010-2011 P205、図表8-1-9要件定義工程も含めた工程別の
実績工数の比率の基本統計量 (新規開発)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri②計画:工期比率のデータの見方
データの関係性
比率が高い工程には「それだけ長い作業期間を要する」ということ。
プロジェクト期間全体の約30%(1/5~1/3)を製作工程が占める。
工期比率
・・・各開発工程を実施するのに必要とされる期間
要件定義工程も含めた工程別の
実績月数の比率の基本統計量 (新規開発)
[比率]
工程
N
最小
P25
中央
P75
最大
平均
標準偏差
基本設計
131
0.016
0.155
0.227
0.301
0.522
0.232
0.105
詳細設計
131
0.026
0.143
0.191
0.246
0.645
0.200
0.091
製作
131
0.047
0.211
0.263
0.359
0.902
0.285
0.116
結合テスト
131
0.016
0.094
0.143
0.185
0.386
0.145
0.068
総合テスト(ベンダ確認)
131
0.014
0.074
0.121
0.183
0.571
0.138
0.088
(新規開発)
データ白書2010-2011 P202、図表8-1-2 データ白書2010-2011 P202、図表8-1-3[比率]
工程
N
最小
P25
中央
P75
最大
平均
標準偏差
要件定義
82
0.032
0.106
0.146
0.232
0.480
0.178
0.102
開発5工程
82
0.520
0.768
0.854
0.894
0.968
0.822
0.102
SEC
Software Engineering for Mo・No・Zu・Ku・Ri③コントロール:残作業見積りにおけるデータ活用
差異発生時の今後の見通し
予実差異を吸収して計画通りに完了させるため、
何らかの手を打つかどうかを判断し、適切に対応する必要がある。
明確になった情報、条件を利用し、さらに精度の高い
残作業の見積り(残りの工程、工期の予測)を行う。
再度測定した規模、これまでに掛かった期間、
消化した工数、実績からみた生産性などから、
今後の実現性を検証する。
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 工数比率、工期比率からの現在以降の再見積りと評価
例) 基本設計工程が終わった段階で、後工程を見通す際の注意点
読み方:
基本設計工程は全工期の
概ね15-30%を占める。
中央値: 23.0%
使い方:
基本設計工程にかかった工期から、
それ以降の工期は約2.3~5.6倍
かかると予測できる。
中央値で見ると: 約3.3倍
計画値で全工程6ヶ月半のプロジェクトの場合:
基本設計1.5ヶ月の予定が2ヶ月かかった。 ⇒ 2週間遅れ、計画
上残り4ヶ月半。
基本設計以降の工期は(2*3.3=6.6)から、あと
約6ヶ月半はかかる
可能性。
※ 基本設計が2週間遅れただけと安易に考えていると、
実質
2ヶ月も遅れるリスクを見落とすことになる。
データ白書2010-2011 P201、図表8-1-1工程別の工期比率の箱ひげ図
③コントロール:残作業の再見積りと評価(事例)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri・実績工数は中央値で2.9%、超過傾向があり、
-3%~+24%で変動している。(P25~P75幅)
④評価:データ白書に見る予実差異
超過率 ={実績値 - 計画値}÷計画値
0 50 100 150 200 250 300 350 400 450 500 ~ -0 .5 0 ~ -0 .4 5 ~ -0 .4 0 ~ -0 .3 5 ~ -0 .3 0 ~ -0 .2 5 ~ -0 .2 0 ~ -0 .1 5 ~ -0 .1 0 ~ -0 .0 5 ~ 0 .0 0 ~ 0 .0 5 ~ 0 .1 0 ~ 0 .1 5 ~ 0 .2 0 ~ 0 .2 5 ~ 0 .3 0 ~ 0 .3 5 ~ 0 .4 0 ~ 0 .4 5 ~ 0 .5 0 ~ 0 .5 5 ~ 0 .6 0 0 .6 超 ←計画内 工期の計画超過率 超過→ 件数 0 10 20 30 40 50 60 70 80 90 100 ~-0 .6 ~-0 .5 ~-0 .4 ~-0 .3 ~-0 .2 ~-0 .1 ~0 .0 ~0 .1 ~0 .2 ~0 .3 ~0 .4 ~0 .5 ~0 .6 ~0 .7 ~0 .8 ~0 .9 ~1 .0 ~1 .1 ~1 .2 1 .2 超 ←計画内 FP規模の計画超過率 超過→ 件数 0 50,000 100,000 150,000 200,000 250,000 300,000 350,000 0 50,000 100,000 150,000 200,000 250,000 300,000 350,000 計画工数(プロジェクト全体:基本設計開始時点) 実績工数(プ ロ ジ ェ ク ト 全体) a:新規開発 b:改修・保守 c:再開発 d:拡張Copyright IPA SEC N=998 0 50 100 150 200 250 300 350 ~-0 .8 ~-0 .6 ~-0 .4 ~-0 .2 ~0 .0 ~0 .2 ~0 .4 ~0 .6 ~0 .8 ~1 .0 ~1 .2 ~1 .4 ~1 .6 ~1 .8 ~2 .0 ~2 .2 ~2 .4 ~2 .6 ~2 .8 ~3 .0 3 .0 超 ←計画内 工数の計画超過率 超過→ 件数 データ白書2010-2011 P288、図表10-1-4 データ白書2010-2011 P293、図表10-1-13 データ白書2010-2011 P291、図表10-1-10 データ白書2010-2011 P291、図表9-1-8
FP規模の計画と実績の差の比率の分布
工期の計画と実績の差の比率の分布
工数の計画と実績
工数の計画と実績の差の比率の分布
FP規模
中央値0.0%
工期
中央値0%
工数
中央値2.9%
SEC
Software Engineering for Mo・No・Zu・Ku・Ri緑
▲
:計画値
赤
▲
:実績値
赤
+
:実績自己の位置
④評価:プロジェクト完了時の評価(事例)
想定シーン:
PMによるプロジェクト完了時のプロジェクト評価。
定量データの利用目的:
短期開発のため要注意プロジェクトと指定し重点監視したが、計画時
(100,000人時、12ヵ月)の予定が、実績(130,000人時、13ヵ月)となった。
結果から見て開発力が妥当な範囲か評価したい。
見方・使い方:
利用イメージ・事例
SEC
Software Engineering for Mo・No・Zu・Ku・Ri④評価:プロジェクト完了時の評価(事例)
(1)図表から認識できること
・工数と工期の信頼幅線下位50%を下回り、計画段階から工期が
厳しく挑戦的な工期であった。
実績も同様で、工数の割に工期が厳しく、短期での開発力、
管理力が備わっていることが分かる。
・工数が30%増加しているが、工期を守るためのトレードオフと推察
できる。
(2)利用・想定事例
ケース1:平均要員数60人規模のプロジェクトを短期で開発・管理
できる能力がある。
これを強みと捉え、実践した施策、手法をプロセスとして
文書化する。
ケース2:短工期に対応できる工程別工期比を自社の特徴と捉え、
新たなプロジェクトに際しても適用する。
SEC
Software Engineering for Mo・No・Zu・Ku・Ri データの関係性
規模と生産性をPMスキル別に層別して示している。
⇒ 規模の小さいプロジェクトは生産性のばらつきが大きく、
PMスキルの分布もばらついている。
規模の大きいプロジェクトは
生産性が低い傾向と同時に、
PMスキルが高い傾向が見られる。
④評価:規模とPMスキルの関係に見る留意点
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 10,000 11,000 12,000 13,000 FP実績値(調整前)[FP] F P 生産性( F P /開発5工程工数) [F P /人時] a:レベル6、レベル7 b:レベル5 c:レベル4 d:レベル3Copyright IPA SEC
N=117 0 10 20 30 40 50 60 70 80 90 0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 4,000,000 実効SLOC実績値[SLOC] S LO C 生産性 (S LO C / 開発 5 工程工数 ) a:レベル6、レベル7 b:レベル5 c:レベル4 d:レベル3
Copyright IPA SEC
N=84 データ白書2010-2011 P249、図表9-1-31
PMスキル別のFP規模とFP生産性(新規開発)
PMスキル別のSLOC規模とSLOC生産性(新規開発)
データ白書2010-2011 P273、図表9-2-25SEC
Software Engineering for Mo・No・Zu・Ku・Ri④評価:信頼性要求レベルと生産性に見る留意点
データ白書2010-2011 P261、図表9-1-55要求レベル(信頼性)別
FP生産性箱ひげ図
(新規開発、IFPUGグループ)
データ白書2010-2011 P248、図表9-1-29要求レベル(信頼性)別
FP生産性箱ひげ図
(改良開発、IFPUGグループ)
データ白書2010-2011 P272、図表9-2-23 データ白書2010-2011 P285、図表9-2-47信頼性要求レベルが高い方が
生産性は低い傾向がある
データの関係性
要求レベル(信頼性)別
SLOC生産性箱ひげ図
(改良開発、主開発言語グループ)
要求レベル(信頼性)別
SLOC生産性箱ひげ図
(新規開発、主開発言語グループ)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri データ白書における生産性の分析について
生産性データの傾向を把握することで、見積りや計画の妥当性
の確認、実績の評価などに利用することができる。
データ白書では、生産性の傾向などを掴むため、以下の層別
による分析を行い、基本統計量を示している。
規模別、業種別、アーキテクチャ別、主開発言語別
プラットフォーム別、月あたり要員数、外部委託比率
信頼性要求の高さ
規模別・業種別、規模別・チーム規模別
業種別生産性と発生不具合密度
規模とPMスキル
【参考】生産性の分析について(1)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 「生産性の分析」のデータの見方①
規模と生産性の傾向
新規開発、IFPUGグループ:規模と生産性
データの関係性:
規模を1000FP未満と1000FP以上に層別すると、後者のグループの
生産性は前者より低い。小規模では生産性のばらつきが大きく、
大規模では生産性に上限があるように見える。
【参考】生産性の分析について(2)
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,00010,00011,00012,00013,00014,00015,00016,00017,00018,00019,00020,00021,00022,000 FP実績値(調整前)[FP] FP 生産性 (FP / 開発 5 工程工数 )[ FP / 人時] Copyright IPA SEC N=283 データ白書2010-2011 P235、図表9-1-5 データ白書2010-2011 P235、図表9-1-6
FP規模別FP生産性
(新規開発、IFPUGグループ) 箱ひげ図
FP規模とFP生産性(新規開発、IFPUGグループ)
SEC
Software Engineering for Mo・No・Zu・Ku・Ri 「生産性の分析」のデータの見方②
月あたりの要員数と生産性の傾向
新規開発、IFPUGグループ:月あたりの要員数と生産性
データの関係性:
要員数が10人以上の場合、FP生産性は要員数10人未満に比べて
かなり低い。(大人数の開発体制では、生産性に上限があるように見える)
【参考】生産性の分析について(3)
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 月あたりの要員数 [人] F P 生産性(F P / 開発5 工程工数)[ F P / 人時]Copyright IPA SEC
N=155 データ白書2010-2011 P242、図表9-1-20 データ白書2010-2011 P243、図表9-1-21
月あたりの要員数とFP生産性(新規開発、IFPUGグループ)
月あたりの要員数別FP生産性
(新規開発、IFPUGグループ) 箱ひげ図
SEC
Software Engineering for Mo・No・Zu・Ku・Ri本日の内容
1.定量的マネジメントの必要性
2.定量データの実践的活用方法と事例
2-1.活用その1(品質)
2-2.活用その2(工数・工期)
3.実践的活用をサポートするツール
SEC
Software Engineering for Mo・No・Zu・Ku・RiSECが提供するツール群
定量データの投入
収集データの精査
定量データの送付
データ提供企業
IPA/SEC
データ収集サイクル
定量データの収集依頼
■収集ツール
文書化・編集
白書コンテンツ作成
機密室
機密室
SECデータ
ツール化
開発5工程の工数と工期 (新規開発) N=185 0 5 10 15 20 25 30 35 40 45 50 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数(開発5 工程) [月] y(95%) y(50%) y(-50%) y(-95%) 実績値Copyright IPA SEC
プロジェクト診断
■診断支援ツール
(Webサイト)
一般利用者(企業)
■分析ツール
データ登録
データ出力
開発5工程の工数と工期 (新規開発) N=185 0 5 10 15 20 25 30 35 40 45 50 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数(開発5 工程) [月] y(95%) y(50%) y(-50%) y(-95%) 実績値Copyright IPA SEC 開発5工程の工数と工期 (新規開発) N=185 0 5 10 15 20 25 30 35 40 45 50 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数(開発5 工程) [月] y(95%) y(50%) y(-50%) y(-95%) 実績値
Copyright IPA SEC 開発5工程の工数と工期 (新規開発) N=185 0 5 10 15 20 25 30 35 40 45 50 0 50,000 100,000 150,000 200,000 250,000 300,000 実績工数(開発5工程) [人時] 実績月数(開発5 工程) [月] y(95%) y(50%) y(-50%) y(-95%) 実績値
Copyright IPA SEC
簡易分析
自社蓄積
データ
■定量的プロジェクト管理ツール
(開発中)
ソース規模、
WBS,工数
等収集
ソース管理、
障害管理、
工数管理
自社蓄積
データ
0 500 1000 1500 2000 2500 3000 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 ソー ス 規模( 行数) ソースコード規模推移 モジュールA モジュールB モジュールC モジュールD 全体規模 想定到達規模 規模計画値 4W平均生産性(右目盛) 計画値 開発終了 遅れ予測ベンチ
マーク
品質管理
ノウハウ
マネージメント
ノウハウ
■スタンドアロン型
診断支援ツール
SEC
Software Engineering for Mo・No・Zu・Ku・Riプロジェクト診断支援ツール(Web)
Web上で
ソフトウェア開発
データ白書の統計情報
を
活用し、ソフトウェア開発におけるQCDの見える化を
支援するツール
2007年12月25日よりSECのWebサイトで無償公開,稼働中!
データ白書に掲載されている様々な図表が参照可能
他社データとのベンチマーキングが可能
※ 入力したデータはログオフ時にすべて破棄され、
サーバ等には一切残らない
SEC
Software Engineering for Mo・No・Zu・Ku・Riプロジェクト診断支援ツール(Web)
プロット可能図表一覧
利用者が登録したデータが、どの図表にプロットできるのかを一覧で表示する。
信頼幅%指定
信頼幅を引くことができる散布図の場合、その値を任意に指定することができる。
自社プロジェクトデータ
属性表示
散布図にプロットされたデータの番号と名称がマウスオーバーで表示される。
人時/人月切替え
散布図および箱ひげ図の工数をどちらの単位で表示するか選択することができる。
機能
特徴
自社データのプロット
1件または複数件のプロジェクトデータを入力し、統計図表上に自社データの位置をプロットすることができる。
自社データのみの表示も可能。
機密保全のため、入力したプロジェクトデータはログオフ時にすべて破棄され、サーバ等には一切残らない。
図表の拡大と縮小
散布図を拡大、縮小する。プロットが局所に密集している場合、拡大によって、その部分の状況をより詳細に確認
することができる。拡大する際の基点の指定も可能。
データ種別の選択
種別分類した散布図で、特定の種別だけに絞って描画することができる。
XY軸の反転
各社の評価軸に合わせて、散布図のXY軸を反転させることができる。
対数グラフの表示
散布図に通常表示と対数表示がある場合、ボタンひとつで表示を切り替えることができる。通常表示では分かりづ
らい傾向が、両対数変換すると見えてくる可能性がある。
図表のコピー& 印刷
WORDやEXCEL等で作成した文書に統計図表を貼り込んだり、画面を印刷したりすることができる。
機能概要と特徴
SEC
Software Engineering for Mo・No・Zu・Ku・Ri