SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第12回
ITプロジェクトのベンチマーキング
～ソフトウェア開発定量データとその活用～
を聞いてきたのでメモメモ
■１．定量データとベンチマーキングの必要性
定量データの必要性
・定量データが集まれば、こんな活用ができる
ユーザー
経営層：ＩＴ投資
業務・情報システム部門
プロジェクト管理者
ベンダー
経営層
ＰＭＯ・品詞保証部門
ＰＭ，ＰＬ
プロジェクト活動における定量データの活用
・データ収集からプロジェクトへのフィードバックの流れ
組織活動
プロジェクト活動
→ベンチマーク作成：データ白書のようなもの
ＳＥＣの取り組みとデータ白書の目的
・定量的アプローチによる科学的マネジメントの普及拡大
物差しとしての精度を高めていく
データ白書２０１０－２０１１の構成
・代表的な要素
規模、工数、後期、生産性、信頼性
・プロジェクトの特性（プロファイル）
開発種別、開発言語、アーキテクチャ、業種、
開発ライフサイクルモデル、プラットフォーム
→値ごろ感がわかりたい
ＳＥＣセミナーのアンケート結果
・プロジェクトデータを収集している：７６％
・プロジェクトデータを活用している：５３％
→ちゃんと活用できていない
収集した定量データ活用の期待とギャップ
・期待感（ひとつの例）
・収集したプロジェクトデータについて、
代表的な要素間には相関関係がある
・２つの要素の関係が、回帰分析により定式化される
↓
・現実とのギャップ
相関は低い
ばらつきが大きく、型よりもある
プロジェクトの特性に合わない
→そもそもデータを集めてもムダ？
統計分析をしても、赤字になる（ぶれ幅おおきい）
今回のポイント
・ＳＥＣ「ソフトウェア開発データ白書」を例にして
ベンチマーキング
【参考】ＩＴプロジェクト性能ベンチマーキング
→なにをするのか、まとめられている
→経済産業省ソフトウェアメトリクス高度化プロジェクト
■２．データ白書の見方とポイント
白書の表記と見方の留意点
・データの分布を視覚的に捕らえることができるグラフ
→箱ひげ図
９９．７％入っていれば良い・・・標準偏差
５つのＭ（品質工学）
ソフト→正規分布しない→箱ひげ図
変なはずれ値があっても、影響を受けない
・対数変換による分析
→対数変換すると、正規分布になるらしい・・・
→線形性が見えてくる
・基本統計量、プロファイルデータの見方と留意点
中央値と平均値をとっている
→平均値ははずれ値に左右される
収集したプロジェクトデータの分布について
・ＦＰ規模：１０００ＦＰ以下が７割弱
・ＳＬＯＣ：５０ＫＳＬＯＣ以下が多い
・工期：１４ヶ月以下
：
：
工程別の分析について（８章）
工数比率
・開発工程を実施するのに必要な作業工数の比率
工期比率
・各開発工程を実施するのに必要とされる期間
→お客さんが言われたとき、目安になる
テスト工程別のテストケース数と検出バグ数
結合テストケース数は総合テストケース数の約４倍
テスト工程別のテストケース数と検出バグ数
「規模あたりのテストケース数と検出バグ数」のデータ活用
ゾーン分析
生産性の分析について（９章）
層別による分析
月あたりの要員数
信頼性要求レベルが高いほうが生産性は低い傾向にある
予実分析
計画と終わった段階
工期：中央値０（＝納期は守る）
工数：中央値２．９、－３～＋２４％で変動
ただし、3倍越えのはずれ値も！
■３．定量データの活用事例
ソフトウェア開発ライフサイクルからみた活用事例
見積もり：規模、工数、工期のデータ活用
・データ活用の狙い
５０％信頼幅、９５％の下限値
・いきなり機能分割→類推見積もり
・見積もり：ボトムアップ見積もり
パラメトリック見積もり
１０００ＦＰ→４０人月
じゃあ、４０００ＦＰだったら４倍？
ちがいます。
工数＝ＡＸ（ＦＰ規模）＊＊Ｂ Ｂ＝１．１９
指数的に上がる！！
工数の見積もり
・留意点
規模が大きくなると、「規模の増加率以上に工数が増大する」
・見積もりがでたら
→妥当性を確認：ベンチマーキング
「工数と工期」
・工期は工数の３乗根におおむね比例
工期＝ＡＸ(工数）＊＊０．３１
ＪＵＡＳだとＡ＝２．５４ １２５人月で１年
でも、これでは受注できない
・留意点
工期短縮には限界がある
１２ヶ月を工数短縮しても５ヶ月
→失敗しても、５ヶ月
・分析の切りくち
→Ｊａｖａのほうが.Netより生産性悪い
・規模、工数、工期からの適切な計画案の策定の事例
コントロール「残作業の見積もり」
基本設計工程は全工程の１５－３０％、中央値は２３％
基本設計で、１．５ヶ月が２ヶ月かかったとする
→全体の比率は？
ベンチマーキングとして使う
評価
・規模の小さいプロジェクトは生産性のばらつきが大きく
ＰＭスキルの分布もばらついている
・規模の大きいプロジェクトは、生産性が低い傾向と同時に
ＰＭスキルが高い傾向が見られる
■４．実践的活用をサポートするツール
プロジェクト診断支援ツール
Ｗｅｂサイトにデータ白書がそのまま載っている
スタンドアロン型プロジェクト診断ツール
自社のデータをいれる
（Ｗｅｂの）プロジェクト診断支援ツールに渡せる
ＰｏｗｅｒＰｏｉｎｔもある
＜＜おまけ＞＞
・最近のデータ白書
中小企業を考慮
小規模
工程別の生産性分析
特定分野の経験：要員配置
信頼性
信頼性向上
開発手法
の第12回
ITプロジェクトのベンチマーキング
～ソフトウェア開発定量データとその活用～
を聞いてきたのでメモメモ
■１．定量データとベンチマーキングの必要性
定量データの必要性
・定量データが集まれば、こんな活用ができる
ユーザー
経営層：ＩＴ投資
業務・情報システム部門
プロジェクト管理者
ベンダー
経営層
ＰＭＯ・品詞保証部門
ＰＭ，ＰＬ
プロジェクト活動における定量データの活用
・データ収集からプロジェクトへのフィードバックの流れ
組織活動
プロジェクト活動
→ベンチマーク作成：データ白書のようなもの
ＳＥＣの取り組みとデータ白書の目的
・定量的アプローチによる科学的マネジメントの普及拡大
物差しとしての精度を高めていく
データ白書２０１０－２０１１の構成
・代表的な要素
規模、工数、後期、生産性、信頼性
・プロジェクトの特性（プロファイル）
開発種別、開発言語、アーキテクチャ、業種、
開発ライフサイクルモデル、プラットフォーム
→値ごろ感がわかりたい
ＳＥＣセミナーのアンケート結果
・プロジェクトデータを収集している：７６％
・プロジェクトデータを活用している：５３％
→ちゃんと活用できていない
収集した定量データ活用の期待とギャップ
・期待感（ひとつの例）
・収集したプロジェクトデータについて、
代表的な要素間には相関関係がある
・２つの要素の関係が、回帰分析により定式化される
↓
・現実とのギャップ
相関は低い
ばらつきが大きく、型よりもある
プロジェクトの特性に合わない
→そもそもデータを集めてもムダ？
統計分析をしても、赤字になる（ぶれ幅おおきい）
今回のポイント
・ＳＥＣ「ソフトウェア開発データ白書」を例にして
ベンチマーキング
【参考】ＩＴプロジェクト性能ベンチマーキング
→なにをするのか、まとめられている
→経済産業省ソフトウェアメトリクス高度化プロジェクト
■２．データ白書の見方とポイント
白書の表記と見方の留意点
・データの分布を視覚的に捕らえることができるグラフ
→箱ひげ図
９９．７％入っていれば良い・・・標準偏差
５つのＭ（品質工学）
ソフト→正規分布しない→箱ひげ図
変なはずれ値があっても、影響を受けない
・対数変換による分析
→対数変換すると、正規分布になるらしい・・・
→線形性が見えてくる
・基本統計量、プロファイルデータの見方と留意点
中央値と平均値をとっている
→平均値ははずれ値に左右される
収集したプロジェクトデータの分布について
・ＦＰ規模：１０００ＦＰ以下が７割弱
・ＳＬＯＣ：５０ＫＳＬＯＣ以下が多い
・工期：１４ヶ月以下
：
：
工程別の分析について（８章）
工数比率
・開発工程を実施するのに必要な作業工数の比率
工期比率
・各開発工程を実施するのに必要とされる期間
→お客さんが言われたとき、目安になる
テスト工程別のテストケース数と検出バグ数
結合テストケース数は総合テストケース数の約４倍
テスト工程別のテストケース数と検出バグ数
「規模あたりのテストケース数と検出バグ数」のデータ活用
ゾーン分析
生産性の分析について（９章）
層別による分析
月あたりの要員数
信頼性要求レベルが高いほうが生産性は低い傾向にある
予実分析
計画と終わった段階
工期：中央値０（＝納期は守る）
工数：中央値２．９、－３～＋２４％で変動
ただし、3倍越えのはずれ値も！
■３．定量データの活用事例
ソフトウェア開発ライフサイクルからみた活用事例
見積もり：規模、工数、工期のデータ活用
・データ活用の狙い
５０％信頼幅、９５％の下限値
・いきなり機能分割→類推見積もり
・見積もり：ボトムアップ見積もり
パラメトリック見積もり
１０００ＦＰ→４０人月
じゃあ、４０００ＦＰだったら４倍？
ちがいます。
工数＝ＡＸ（ＦＰ規模）＊＊Ｂ Ｂ＝１．１９
指数的に上がる！！
工数の見積もり
・留意点
規模が大きくなると、「規模の増加率以上に工数が増大する」
・見積もりがでたら
→妥当性を確認：ベンチマーキング
「工数と工期」
・工期は工数の３乗根におおむね比例
工期＝ＡＸ(工数）＊＊０．３１
ＪＵＡＳだとＡ＝２．５４ １２５人月で１年
でも、これでは受注できない
・留意点
工期短縮には限界がある
１２ヶ月を工数短縮しても５ヶ月
→失敗しても、５ヶ月
・分析の切りくち
→Ｊａｖａのほうが.Netより生産性悪い
・規模、工数、工期からの適切な計画案の策定の事例
コントロール「残作業の見積もり」
基本設計工程は全工程の１５－３０％、中央値は２３％
基本設計で、１．５ヶ月が２ヶ月かかったとする
→全体の比率は？
ベンチマーキングとして使う
評価
・規模の小さいプロジェクトは生産性のばらつきが大きく
ＰＭスキルの分布もばらついている
・規模の大きいプロジェクトは、生産性が低い傾向と同時に
ＰＭスキルが高い傾向が見られる
■４．実践的活用をサポートするツール
プロジェクト診断支援ツール
Ｗｅｂサイトにデータ白書がそのまま載っている
スタンドアロン型プロジェクト診断ツール
自社のデータをいれる
（Ｗｅｂの）プロジェクト診断支援ツールに渡せる
ＰｏｗｅｒＰｏｉｎｔもある
＜＜おまけ＞＞
・最近のデータ白書
中小企業を考慮
小規模
工程別の生産性分析
特定分野の経験：要員配置
信頼性
信頼性向上
開発手法
今日は線分！
以下のように、青とオレンジの２つの線が交わっている。
このとき、
青の線から距離r1,
オレンジの線から距離r2
離れている線分の交点を求めよ。
■設定
交点を原点になるように平行移動した後、
青い線をＸ軸になるように回転すると、以下のような感じ。
で、青い線からr1(距離分）はなれたところに線を引き、
オレンジのところと、r2離れたところに線を引く
この２つの線分との交点を求めればよい
ｒ１はなれた線上における、
オレンジ線の延長線との交点（ｃ）と、
オレンジからｒ２はなれた線との交点(頂点）
の距離（＝頂点～Ｃ）をｋ、
オレンジの延長線上との交点(c)と、
原点から、ｒ１はなれた線に垂線を下ろした点（Ｄ）
までの距離（＝ＣＤ）をｍとおくと、
平行移動＆回転された状態で、求める交点は
（－（ｋ＋ｍ）,-r１）となる。
つまり、k+mを求めればよい
Ｋについては、茶色い図形で考える。つまり、
O:原点と
A:ｙ＝０の線と、オレンジ線からｒ２はなれた線の交点
B:原点からオレンジ線からｒ２はなれた線に垂線との交点
の三角形ＯＡＢを考え、
ｍについては、緑色の三角形
O:原点と
C:オレンジ線からｒ１はなれた線の交点
D:原点と青線からｒ１はなれた線に対して垂線をひいたときの交点
の三角形OCDを考える
■Ｋについて
オレンジと青の交点のなす各をθとすると、
茶色の図形において
OB/OA=sinθ ここで、OB=r2, OA=kより
r2/k=sinθ k=r2/sinθ
■ｍについて
OD/OC=sinθ ここで OD=r1, また OCをlとおくと、
r1/l=sinθ なので、 l=r1/sinθ ※
また、m/l=cosθよって、m=lcosθ
これを※の式に入れる
m=(r1*cosθ）/sinθ
■k+mは
k=r2/sinθ
m=(r1*cosθ）/sinθ
k+m=r2/sinθ+(r1*cosθ）/sinθ
=(r2+r1*cosθ)/sinθ
あとは、もとのように回転移動をして、平行移動して、交点の座標を変換する。
うーん、文字で書くと判りにくい。
この式、おもしろくて、９０度を超ええると、ぜんぜん違う図になるんだけど、
最終的に出てくる式を変形すると、こうなるんですよ。。。
以下のように、青とオレンジの２つの線が交わっている。
このとき、
青の線から距離r1,
オレンジの線から距離r2
離れている線分の交点を求めよ。
■設定
交点を原点になるように平行移動した後、
青い線をＸ軸になるように回転すると、以下のような感じ。
で、青い線からr1(距離分）はなれたところに線を引き、
オレンジのところと、r2離れたところに線を引く
この２つの線分との交点を求めればよい
ｒ１はなれた線上における、
オレンジ線の延長線との交点（ｃ）と、
オレンジからｒ２はなれた線との交点(頂点）
の距離（＝頂点～Ｃ）をｋ、
オレンジの延長線上との交点(c)と、
原点から、ｒ１はなれた線に垂線を下ろした点（Ｄ）
までの距離（＝ＣＤ）をｍとおくと、
平行移動＆回転された状態で、求める交点は
（－（ｋ＋ｍ）,-r１）となる。
つまり、k+mを求めればよい
Ｋについては、茶色い図形で考える。つまり、
O:原点と
A:ｙ＝０の線と、オレンジ線からｒ２はなれた線の交点
B:原点からオレンジ線からｒ２はなれた線に垂線との交点
の三角形ＯＡＢを考え、
ｍについては、緑色の三角形
O:原点と
C:オレンジ線からｒ１はなれた線の交点
D:原点と青線からｒ１はなれた線に対して垂線をひいたときの交点
の三角形OCDを考える
■Ｋについて
オレンジと青の交点のなす各をθとすると、
茶色の図形において
OB/OA=sinθ ここで、OB=r2, OA=kより
r2/k=sinθ k=r2/sinθ
■ｍについて
OD/OC=sinθ ここで OD=r1, また OCをlとおくと、
r1/l=sinθ なので、 l=r1/sinθ ※
また、m/l=cosθよって、m=lcosθ
これを※の式に入れる
m=(r1*cosθ）/sinθ
■k+mは
k=r2/sinθ
m=(r1*cosθ）/sinθ
k+m=r2/sinθ+(r1*cosθ）/sinθ
=(r2+r1*cosθ)/sinθ
あとは、もとのように回転移動をして、平行移動して、交点の座標を変換する。
うーん、文字で書くと判りにくい。
この式、おもしろくて、９０度を超ええると、ぜんぜん違う図になるんだけど、
最終的に出てくる式を変形すると、こうなるんですよ。。。
書いている人は、
「リーンソフトウェア開発と組織改革」とかを書いている、Poppendieckさんと、
「ソフトウエア企業の競争戦略」とかを書いている（日本はバグが少ないことを調査した）クスマノさん。
Twitter（@computingnow)で流れてきたんだけど、
ＩＥＥＥのＣＳの論文？ドキュメントなんで、
いま、ここの環境だと、タダで手に入らないので
（大学院のリモートデスクトップでアクセスすると、ただになるかも・・・）
めもめも。
Lean Software Development: A Tutorial
Mary Poppendieck, Michael A. Cusumano,
http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2012.107
「リーンソフトウェア開発と組織改革」とかを書いている、Poppendieckさんと、
「ソフトウエア企業の競争戦略」とかを書いている（日本はバグが少ないことを調査した）クスマノさん。
Twitter（@computingnow)で流れてきたんだけど、
ＩＥＥＥのＣＳの論文？ドキュメントなんで、
いま、ここの環境だと、タダで手に入らないので
（大学院のリモートデスクトップでアクセスすると、ただになるかも・・・）
めもめも。
Lean Software Development: A Tutorial
Mary Poppendieck, Michael A. Cusumano,
http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2012.107
今、下の図のように、赤い円と青い円があって、その交点
（緑の点）を求めたいとする
つまり、
赤い円の中心を(x1,y1)半径をr1
青い円の中心を(x2,y2)半径をr2
とする。
このとき、緑色の交点(2つ現れる）(cx1,cy1),(cx2,cy2)を求めよという問題。
この問題をネットで検索する、つまり「円の交点を求める」を調べると
Ｂ１７．円と円の交点を求める
http://www.hptown.com/ucad/Ufb00017.htm
は美しいものの・・・
ほかは、ぎゃあ・・・式は解きたくない（－＿－；）
ってことで、自分で考えてみた。
まず、図のように赤い円の中心をＡ，青い円の中心をＢ，円の交点のひとつをＣとおく
そして、ＡＢ，ＡＣ，ＢＣ間に線を引き
Ａが原点になるように平行移動
ＡＢの線をＸ軸になるように、回転すると、下の図となる。
あとあとにために、頂点ＣからＡＢに対して垂線を引き、その交点をＤとします。
■交点までの高さ（Ｙ）を求める
ここで、唐突だけど、この三角形ＡＢＣの面積を求めることを考える。
・ひとつはヘロンの公式で求まる
・もうひとつは、1/2*底辺*高さで求まる
ことがわかる
つまり、交点の高さ（＝Ｙ座標＝高さＣＤは）
１．ヘロンの公式で、ＡＢＣの三角形を求め、
２．三角形の面積＝1/2*底辺ＡＢ*高さＣＤ
高さＣＤ＝２＊三角形の面積／底辺ＡＢ
で求まる。
ヘロンの公式は、ｓ＝１／２（線分ＡＢ＋線分ＢＣ＋線分ＣＡ）
（線分というのは、線分の長さのこと）としたとき
面積＝√（ｓ＊(ｓ－線分ＡＢ）＊（ｓ－線分ＢＣ）＊（ｓ－線分ＣＡ））
で求まる。ここで、
線分ＡＢは、Ａ点とＢ点の距離
線分ＢＣは、円Ｂの半径
線分ＡＣは、円Ａの半径
なので、ｓも面積も、求めることができる。これを、２のほうに代入すれば、高さがもとまる
以上により、交点までの高さは求まる
■Ｘをもとめる
ではつぎに、Ｘをもとめる。交点からＸ軸に対して、垂線をおろす。
交点をＤとする。Ａが原点なので、ＡＤの長さが、Ｘの値となる。
ここで、 三角形ＡＤＣを考える。
線分ＡＣは半径、線分ＣＤは、今求めたＹであり、線分ＣＤ／線分ＡＣは、sinの関係にある。
このとき、cosは、求めたい線分ＡＤ，つまりＸの値になる。
そこで、線分ＣＤ／線分ＡＤの値をsinとすると、求めたいＸ（cosは）
Ｘ＊Ｘ+sin*sin=1、Ｘ＝±√（１－sin*sin)
でもとまる。Ｘがプラスマイナス２つでる＝交点は２つ
これで、Ｘ，Ｙがでた
あとは、元通りに回転移動、原点をＡにしたので、元に戻す平行移動をすればいい
うん、ことばでかくと、ぐちゃぐちゃだな。
プログラムだと、かんたんなのに・・・
（緑の点）を求めたいとする
つまり、
赤い円の中心を(x1,y1)半径をr1
青い円の中心を(x2,y2)半径をr2
とする。
このとき、緑色の交点(2つ現れる）(cx1,cy1),(cx2,cy2)を求めよという問題。
この問題をネットで検索する、つまり「円の交点を求める」を調べると
Ｂ１７．円と円の交点を求める
http://www.hptown.com/ucad/Ufb00017.htm
は美しいものの・・・
ほかは、ぎゃあ・・・式は解きたくない（－＿－；）
ってことで、自分で考えてみた。
まず、図のように赤い円の中心をＡ，青い円の中心をＢ，円の交点のひとつをＣとおく
そして、ＡＢ，ＡＣ，ＢＣ間に線を引き
Ａが原点になるように平行移動
ＡＢの線をＸ軸になるように、回転すると、下の図となる。
あとあとにために、頂点ＣからＡＢに対して垂線を引き、その交点をＤとします。
■交点までの高さ（Ｙ）を求める
ここで、唐突だけど、この三角形ＡＢＣの面積を求めることを考える。
・ひとつはヘロンの公式で求まる
・もうひとつは、1/2*底辺*高さで求まる
ことがわかる
つまり、交点の高さ（＝Ｙ座標＝高さＣＤは）
１．ヘロンの公式で、ＡＢＣの三角形を求め、
２．三角形の面積＝1/2*底辺ＡＢ*高さＣＤ
高さＣＤ＝２＊三角形の面積／底辺ＡＢ
で求まる。
ヘロンの公式は、ｓ＝１／２（線分ＡＢ＋線分ＢＣ＋線分ＣＡ）
（線分というのは、線分の長さのこと）としたとき
面積＝√（ｓ＊(ｓ－線分ＡＢ）＊（ｓ－線分ＢＣ）＊（ｓ－線分ＣＡ））
で求まる。ここで、
線分ＡＢは、Ａ点とＢ点の距離
線分ＢＣは、円Ｂの半径
線分ＡＣは、円Ａの半径
なので、ｓも面積も、求めることができる。これを、２のほうに代入すれば、高さがもとまる
以上により、交点までの高さは求まる
■Ｘをもとめる
ではつぎに、Ｘをもとめる。交点からＸ軸に対して、垂線をおろす。
交点をＤとする。Ａが原点なので、ＡＤの長さが、Ｘの値となる。
ここで、 三角形ＡＤＣを考える。
線分ＡＣは半径、線分ＣＤは、今求めたＹであり、線分ＣＤ／線分ＡＣは、sinの関係にある。
このとき、cosは、求めたい線分ＡＤ，つまりＸの値になる。
そこで、線分ＣＤ／線分ＡＤの値をsinとすると、求めたいＸ（cosは）
Ｘ＊Ｘ+sin*sin=1、Ｘ＝±√（１－sin*sin)
でもとまる。Ｘがプラスマイナス２つでる＝交点は２つ
これで、Ｘ，Ｙがでた
あとは、元通りに回転移動、原点をＡにしたので、元に戻す平行移動をすればいい
うん、ことばでかくと、ぐちゃぐちゃだな。
プログラムだと、かんたんなのに・・・
くわしくは、
Mac OS X 10.8 Mountain Lionで弊社エンドポイント製品を利用する際の注意事項
http://www.trendmicro.co.jp/support/news.asp?id=1800
を参照。
対応が必要な製品は(以下太字は、上記サイトより引用）
ウイルスバスター for Mac ver. 1.6 (※月額版を含む)
ウイルスバスターコーポレートエディション用プラグイン製品 Trend Micro Security (for Mac) ver. 1.5 SP1/SP2/SP3
(Corp Plus及び C/SS Premiumに同梱)
ウイルスバスタービジネスセキュリティ用プラグイン製品 Trend Micro Security for Mac ver. 1.6
(ウイルスバスタービジネスセキュリティ 7.0に同梱)
だって。
Mac OS X 10.8 Mountain Lionで弊社エンドポイント製品を利用する際の注意事項
http://www.trendmicro.co.jp/support/news.asp?id=1800
を参照。
対応が必要な製品は(以下太字は、上記サイトより引用）
ウイルスバスター for Mac ver. 1.6 (※月額版を含む)
ウイルスバスターコーポレートエディション用プラグイン製品 Trend Micro Security (for Mac) ver. 1.5 SP1/SP2/SP3
(Corp Plus及び C/SS Premiumに同梱)
ウイルスバスタービジネスセキュリティ用プラグイン製品 Trend Micro Security for Mac ver. 1.6
(ウイルスバスタービジネスセキュリティ 7.0に同梱)
だって。
SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第11回
ITプロジェクトの見える化
を聞いてきたのでメモメモ
ＩＴ産業を取り巻く環境の変化
・ネットワーク・ビジネスモデルの変化
・リスク、トラブル
・低コスト、短納期
・ＫＫＤ
ＩＴプロジェクトの実状
・レポーティング
・品質管理
・進捗管理・・・
見える化
わかるか、はかるか
ＩＴプロジェクトと見える化
・ＫＫＤだけでなく、定性的、定量的アプローチ
→形式知化
見える化が対象とする工程
上流工程の課題
要件定義システム仕様
見えない→見切り発車→リスク
どのように見える化？
問題を早期に、不確定な要素をどこまで
中流
ソフトウェア仕様・プログラミング・ソフトウェアテスト
トラブル発生
個人への依存
あいまいさを減らす、ソフトウェア品質のばらつき
機能の見える化
下流
システムテスト、運用
問題顕在化
失敗しそうなプロジェクトを救う活動
予防策も大切、下流肯定で早期に発見し、迅速に処置する
３つの見える化アプローチ
定性的見える化アプローチ
俯瞰図、チェックシート、事例集
定量的見える化アプローチ
測定項目リスト
統合的アプローチ
リスク分類表
定性的見える化
俯瞰図
ドミナントアイテム＊を継続的システム横断的に把握
＊プロジェクトの成否を左右する支配的要因
ステークホルダー俯瞰図
プロジェクト推進体制俯瞰図など
チェックシート
プロジェクトマネジメントの要点を再確認
リスクの明確化
自己評価シート
ヒアリングシート
自己評価と専門家の診断の差、専門家からの対策案を提示
→差をみていく
ＰＭＢＯＫの９エリア＋拡張知識エリア＝１５エリア
失敗事例集
同じ失敗はなかなかない
→事例は参考。そのままは当てはまらない
気が重たくなるかも・・
定量的見える化
測定項目リスト
測定分析データ一覧表
ベース尺度一覧表
統合的見える化
リスク分析表
ヒアリングシート→事例集
測定分析データ・ベース尺度一覧
事例からヒアリングへ
事例集からヒアリング
定量データの必要性
・ソフトウェア開発データ白書
・物差しとしての精度お高めていく
・新たな物差しや課題抽出の切り口を提案する
ユーザー・ベンダ間の合意形成
やりたいこととできることの整合が必要
定量データに裏付けられたマネジメントが必要
定量データの必要性・効用
定量データが集まれば
ユーザ・ベンダの合意形成
組織的な取り組みが必要
定量化に取り組む際のポイント
問題意識と改善の必要性
何が得られるのかを具体的に
強い意志を持って推進すること
コアな問題・課題の解決に絞り込んで
定量的プロジェクト管理ツール
品質の予測
ベンチマーキング
定量的プロジェクト管理ツールとして公開４月２７日
ツール
ＩＳＯ／ＩＥＣ２９１５５を基にしたツールの位置づけ
開発の多様化・短納期化・低コスト化
・開発フレームワーク・開発ツール
・既存アプリケーションの再利用
・機能・アプリケーションの分割開発
外部発注開発、オフショア
・プロジェクトに状況把握が困難
・品質がばらつき全体品質管理困難
・問題解決の判断遅延
・定量的なデータに裏付けられた
定量的管理の課題
・定量データの収集に工数がかかるため、
進行中プロジェクトの定量的診断が行えない
→定量データの自動収集
・定量データ分析のノウハウが乏しく手間
→統計グラフ描画による、視覚的・直感的な分析・診断
・管理するツールの環境がそろっていない
→いったいで提供。Ｅｘｃｅｌ等のデータインポート
・基準値をもっていない
→社内基準の作成
定量的プロジェクト管理の業務
定量的プロジェクト管理ツール
→ＫＫＤからツールによる定量データに
基づいたプロジェクト管理へ
定量的プロジェクト管理ツールとは
品質・信頼性・生産性の継続的向上をさぽ0とするツール
→収集・集計・可視化
定量的プロジェクト管理ツール
・グラフ表示による視覚的・直感的な分析・診断機能の提供
・定量的データの自動収集
・既存ツールを活用
RedMine Trac Subversion GIT BIRT Pentaho
・ツールが簡単に利用できることを重視
定量的プロジェクト管理ツールの概要図
・プロジェクト管理機能
・データ収集機能
・分析レポーティング機能
稼働環境
サーバー、Ｌｉｎｕｘ、Windows
クライアント
チケット駆動型の管理ツール
チケットによるプロジェクト管理
業務報告の省力化、業務の共有化をサポート
チケットとは
作業指示書
チケットの利点
チケットだけ見ればよい
ＷＢＳチケット
チケット入力
障害、課題チケット
チケットの一覧
チケットのガントチャート表示
表示グラフ一覧
ＷＢＳ・品質管理
試験計画項目密度
試験進捗
ＷＢＳ進捗・進捗変化
ＥＶＭ評価
ソフトウェア規模推移
工数予実
遅延重要タスク抽出
障害課題管理
障害件数
障害解決予測
障害原因分析
障害発生密度
障害滞留状況
長期未解決課題抽出
負荷管理
負荷状況
プロジェクトを俯瞰する
定量管理ダッシュボード
複数プロジェクトを俯瞰する
複数プロジェクトの進捗確認
複数プロジェクトの健全性確認
画面レイアウト
共通機能
パンくずリスト表示
操作バー
ダウンロードして使える
【感想】
これ、チケット発行しないと、使えないと思うけど・・・
つまり、ＩＰＡは、チケット駆動開発が当たり前と思ってるってこと？
の第11回
ITプロジェクトの見える化
を聞いてきたのでメモメモ
ＩＴ産業を取り巻く環境の変化
・ネットワーク・ビジネスモデルの変化
・リスク、トラブル
・低コスト、短納期
・ＫＫＤ
ＩＴプロジェクトの実状
・レポーティング
・品質管理
・進捗管理・・・
見える化
わかるか、はかるか
ＩＴプロジェクトと見える化
・ＫＫＤだけでなく、定性的、定量的アプローチ
→形式知化
見える化が対象とする工程
上流工程の課題
要件定義システム仕様
見えない→見切り発車→リスク
どのように見える化？
問題を早期に、不確定な要素をどこまで
中流
ソフトウェア仕様・プログラミング・ソフトウェアテスト
トラブル発生
個人への依存
あいまいさを減らす、ソフトウェア品質のばらつき
機能の見える化
下流
システムテスト、運用
問題顕在化
失敗しそうなプロジェクトを救う活動
予防策も大切、下流肯定で早期に発見し、迅速に処置する
３つの見える化アプローチ
定性的見える化アプローチ
俯瞰図、チェックシート、事例集
定量的見える化アプローチ
測定項目リスト
統合的アプローチ
リスク分類表
定性的見える化
俯瞰図
ドミナントアイテム＊を継続的システム横断的に把握
＊プロジェクトの成否を左右する支配的要因
ステークホルダー俯瞰図
プロジェクト推進体制俯瞰図など
チェックシート
プロジェクトマネジメントの要点を再確認
リスクの明確化
自己評価シート
ヒアリングシート
自己評価と専門家の診断の差、専門家からの対策案を提示
→差をみていく
ＰＭＢＯＫの９エリア＋拡張知識エリア＝１５エリア
失敗事例集
同じ失敗はなかなかない
→事例は参考。そのままは当てはまらない
気が重たくなるかも・・
定量的見える化
測定項目リスト
測定分析データ一覧表
ベース尺度一覧表
統合的見える化
リスク分析表
ヒアリングシート→事例集
測定分析データ・ベース尺度一覧
事例からヒアリングへ
事例集からヒアリング
定量データの必要性
・ソフトウェア開発データ白書
・物差しとしての精度お高めていく
・新たな物差しや課題抽出の切り口を提案する
ユーザー・ベンダ間の合意形成
やりたいこととできることの整合が必要
定量データに裏付けられたマネジメントが必要
定量データの必要性・効用
定量データが集まれば
ユーザ・ベンダの合意形成
組織的な取り組みが必要
定量化に取り組む際のポイント
問題意識と改善の必要性
何が得られるのかを具体的に
強い意志を持って推進すること
コアな問題・課題の解決に絞り込んで
定量的プロジェクト管理ツール
品質の予測
ベンチマーキング
定量的プロジェクト管理ツールとして公開４月２７日
ツール
ＩＳＯ／ＩＥＣ２９１５５を基にしたツールの位置づけ
開発の多様化・短納期化・低コスト化
・開発フレームワーク・開発ツール
・既存アプリケーションの再利用
・機能・アプリケーションの分割開発
外部発注開発、オフショア
・プロジェクトに状況把握が困難
・品質がばらつき全体品質管理困難
・問題解決の判断遅延
・定量的なデータに裏付けられた
定量的管理の課題
・定量データの収集に工数がかかるため、
進行中プロジェクトの定量的診断が行えない
→定量データの自動収集
・定量データ分析のノウハウが乏しく手間
→統計グラフ描画による、視覚的・直感的な分析・診断
・管理するツールの環境がそろっていない
→いったいで提供。Ｅｘｃｅｌ等のデータインポート
・基準値をもっていない
→社内基準の作成
定量的プロジェクト管理の業務
定量的プロジェクト管理ツール
→ＫＫＤからツールによる定量データに
基づいたプロジェクト管理へ
定量的プロジェクト管理ツールとは
品質・信頼性・生産性の継続的向上をさぽ0とするツール
→収集・集計・可視化
定量的プロジェクト管理ツール
・グラフ表示による視覚的・直感的な分析・診断機能の提供
・定量的データの自動収集
・既存ツールを活用
RedMine Trac Subversion GIT BIRT Pentaho
・ツールが簡単に利用できることを重視
定量的プロジェクト管理ツールの概要図
・プロジェクト管理機能
・データ収集機能
・分析レポーティング機能
稼働環境
サーバー、Ｌｉｎｕｘ、Windows
クライアント
チケット駆動型の管理ツール
チケットによるプロジェクト管理
業務報告の省力化、業務の共有化をサポート
チケットとは
作業指示書
チケットの利点
チケットだけ見ればよい
ＷＢＳチケット
チケット入力
障害、課題チケット
チケットの一覧
チケットのガントチャート表示
表示グラフ一覧
ＷＢＳ・品質管理
試験計画項目密度
試験進捗
ＷＢＳ進捗・進捗変化
ＥＶＭ評価
ソフトウェア規模推移
工数予実
遅延重要タスク抽出
障害課題管理
障害件数
障害解決予測
障害原因分析
障害発生密度
障害滞留状況
長期未解決課題抽出
負荷管理
負荷状況
プロジェクトを俯瞰する
定量管理ダッシュボード
複数プロジェクトを俯瞰する
複数プロジェクトの進捗確認
複数プロジェクトの健全性確認
画面レイアウト
共通機能
パンくずリスト表示
操作バー
ダウンロードして使える
【感想】
これ、チケット発行しないと、使えないと思うけど・・・
つまり、ＩＰＡは、チケット駆動開発が当たり前と思ってるってこと？
先週の
見積もり手法の歴史とCoBRA法
http://blog.goo.ne.jp/xmldtp/e/1c9209ebd5948764174f9bcf90185dc4
の話の続き。というか、このとき、感想欄に書いてきた話をちょっと説明してみる。
大規模な見積もりの場合、２通りの考え方がある。
１つは、えいや！と大規模のまま、見積もってしまう方法
もうひとつは、部分部分に分割して見積もり、それを足し合わせる方法
ここで、足し合わせる場合、単純に平均値を足してはいけない。
そうすると、見積もりは短くなる。
一般には、平均にあうのではなく、遅いものにあわせる。
とはいえ、一番遅いものを足していったら、さすがにそこまでは、遅くならない・・・
ということで、部分部分に分割して見積もると、不正確になってしまう。
この問題を解決するには、
１．各部分部分の見積もりを
平均 何日 分散 何日 何とか分布
のような、確率的な見積もりを出して
２．その見積もりをモンテカルロシミュレーションを使ってシミュレーションする
という方法にすれば、ただしそうな見積もりになる。
ＩＰＡのＣｏＢＲＡの場合、出てくる結果が確率的な分布なので、これができる。
ということで、これによって、
えいや！と大規模のまま見積もることも
部分部分を見積もって、モンテカルロシミュレーションによって解くことも
できるわけなんだけど、どっちがいいんでしょうね・・・
見積もり手法の歴史とCoBRA法
http://blog.goo.ne.jp/xmldtp/e/1c9209ebd5948764174f9bcf90185dc4
の話の続き。というか、このとき、感想欄に書いてきた話をちょっと説明してみる。
大規模な見積もりの場合、２通りの考え方がある。
１つは、えいや！と大規模のまま、見積もってしまう方法
もうひとつは、部分部分に分割して見積もり、それを足し合わせる方法
ここで、足し合わせる場合、単純に平均値を足してはいけない。
そうすると、見積もりは短くなる。
一般には、平均にあうのではなく、遅いものにあわせる。
とはいえ、一番遅いものを足していったら、さすがにそこまでは、遅くならない・・・
ということで、部分部分に分割して見積もると、不正確になってしまう。
この問題を解決するには、
１．各部分部分の見積もりを
平均 何日 分散 何日 何とか分布
のような、確率的な見積もりを出して
２．その見積もりをモンテカルロシミュレーションを使ってシミュレーションする
という方法にすれば、ただしそうな見積もりになる。
ＩＰＡのＣｏＢＲＡの場合、出てくる結果が確率的な分布なので、これができる。
ということで、これによって、
えいや！と大規模のまま見積もることも
部分部分を見積もって、モンテカルロシミュレーションによって解くことも
できるわけなんだけど、どっちがいいんでしょうね・・・
こんな感じかなあ・・・
（１）客先で、ＨＴＭＬで画面を作成し、画面の合意を取る
（２）ＨＴＭＬの入出力項目をセットする形にして、
ＣａｋｅＰＨＰで、Ｖｉｅｗのテンプレートと、コントローラーを作る
この時点では、コントローラーは、モデルを使わないことにして
画面にデータをsetで送る（ダミーデータを送る）
ここで、画面表示、画面遷移を確認する
（３）上記（２）で出てきた項目をもとに、データベースを作成する
項目は、データベースにあるべき項目（永続性必要？）
だとしたら、どのデータベースにいれるべき？
（４）上記（３）できまったデータベースを作成する
→phpMyAdminで
（５）上記（４）のテーブルを元にモデルを作る
（６）上記（５）のモデルを、（２）のコントローラーに埋め込む
必要なら編集やＳＱＬを発行する
画面はＨＴＭＬで作成してしまうし、テーブルはphpMyAdminで直接編集するので、
ドキュメントは残らない。
そこで、必要なら、自動生成する。
データベースのテーブル定義から、テーブル定義書やＥＲ図を作る
画面のＨＴＭＬを読み込み、Domのエレメントから、画面定義書を自動的に作る
って感じですかね・・・
（１）客先で、ＨＴＭＬで画面を作成し、画面の合意を取る
（２）ＨＴＭＬの入出力項目をセットする形にして、
ＣａｋｅＰＨＰで、Ｖｉｅｗのテンプレートと、コントローラーを作る
この時点では、コントローラーは、モデルを使わないことにして
画面にデータをsetで送る（ダミーデータを送る）
ここで、画面表示、画面遷移を確認する
（３）上記（２）で出てきた項目をもとに、データベースを作成する
項目は、データベースにあるべき項目（永続性必要？）
だとしたら、どのデータベースにいれるべき？
（４）上記（３）できまったデータベースを作成する
→phpMyAdminで
（５）上記（４）のテーブルを元にモデルを作る
（６）上記（５）のモデルを、（２）のコントローラーに埋め込む
必要なら編集やＳＱＬを発行する
画面はＨＴＭＬで作成してしまうし、テーブルはphpMyAdminで直接編集するので、
ドキュメントは残らない。
そこで、必要なら、自動生成する。
データベースのテーブル定義から、テーブル定義書やＥＲ図を作る
画面のＨＴＭＬを読み込み、Domのエレメントから、画面定義書を自動的に作る
って感じですかね・・・
SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第10回
ソフトウェア開発見積もりの課題と解決方法
～見積もり手法の歴史とCoBRA法～
を聞いてきたのでメモメモ
１．見積もりにおける課題
・プロジェクトマネジメントにおける見積もりの位置づけ
みつもり→プロジェクトマネジメントの中核
・プロジェクトにおける大きな課題のひとつ
プロジェクトを大失敗させる原因は２つある
ひとつ波つもりミスだ
楽観的な見積もり
早期の見積もり
目標と見積もりの混同
一度決まったら修正されない
時間の余裕がないことが多い
もうひとつは仕様未凍結
見積もりミスにつながる
→無理なプロジェクト
ロバートグラス
「ソフトウェア開発５５の真実と１０のうそ」
・見積もりもスを引き起こす原因
ケーパージョーンズ
１．要求が完全に決定される前に正式な見積もりが求められる
２．見積もり修正されない
３．ツール使われない
４．きゃリブレーションできない
５．保守的→挑戦的に
・見積もりの国内の実践状況
ベンダ企業
属人的な方法が減少している一方、類推的な方法が残る
ユーザー企業
相見積もり→ベンダの見積もりに依存
・見積もりにおける課題（１）
見積もり根拠が明確になっていない（規模、工数、工期）
→ＫＫＤできまる
見積もりに必要な情報がはっきりしない
見積もり方法もその場限り
生産性に影響を及ぼす要因が多種多様（工数）
→プロジェクト状況の影響
→影響要員がわかっていても、定量化が難しい
・実績プロジェクトデータ
ばらついている
・見積もりにおける課題（２）
過去データの欠落、制度の確保
分析が難しい
見積もり実施者の傾向
ほとんどのコスト見積もりは低すぎる傾向がある（ＤｅＭａｒｃｏ－Ｇｌａｓｓの法則）
・見積もりにおける課題（３）
部分的な情報からの見積もり（規模）
→細部が決まっていない状況で見積もりを行う場合が多い
(予算決めなど早い段階）
→部分的な情報から推論するしかない
実際とブレが出ることは避けられない
４倍から４分の１
・見積もりにおける課題（４）
決めたことが変わっていく（規模）
開発当初の想定機能は、一般に肯定が進むに従って膨張する
→見えていなかった要件が見えてくる
→最初の要件とぶれる
２．見積もり手法の歴史と蓄積
・見積もり手法に関する大きな流れ
６０年代 ソフトウェア開発の黎明期
７０年代 見積もりも出る提案の時期
８０年代 見積もりモデルの成熟期
９０年代 ツールの成熟、機械学習の応用
２０００年代 熟練者の知識活用の再確認
・ソフトウェアにおける見積もりに関する歴史と蓄積
１９５８ノードン(Curve Fitting for a Model of Applied Resarch and development scheduling"
ネルソン １９６６
６つの工程に分類
nelson-jonesの法則
多くの要素が開発生産性に影響
・その２
１９７０年代は見積もりモデル提案の時期
工数の期間の関係
プットナム ＳＬＩＭモデル→演繹的に導く
ファンクションポイント
１９７０年代のモデルにおける課題
重視する要素に違い
・その３
８０年代ＣＯＣＯＭＯモデル ベームによって開発
（ＴＲＷにいたとき）
パラメトリック手法→バジル メタモデルの数値化
一方、主要な結論として、ある環境で構築されたモデルは
そのままでは他の環境での精度はよくない
→キャリブレーションを行う必要がある
・その４
９０年代における機械学習方法の適用（データマイニング）
データに語らせる
機械学習アルゴリズム
ニューラルネットワーク
ＣＡＲＴ
基本的にパターンに分類して見積もりを行う
９０年代後半から２０００年代：熟練者の判断
主観的な見積もり
熟練者の治験を活用した定量化（ＣｏＢＲＡ Braiandら1998)
３．見積もり根拠の見える化
・見積もりの見える化とモニタリングとコントロール（解決方法）
対策１：見積もりモデルの確立
→再現性の確保
対策２：見積もりの妥当性の確保
→想定したものをインプット
前提を変えたシミュレーション
対策３：モニタリングとコントロールと再見積もり
対策４：目標と見積もりの峻別
→すべての出発点は見積もりモデル
・見積もり根拠の見える化の重要性
見積もり根拠の見える化＝コスト構造の見える化が重要
・見える化の課題
工数のぶれをどう説明するか
・具体的な解決策ＣｏＢＲＡ
・５つの特徴
１．組織固有のコスト変動要因をモデル化
２．コスト変動要因に、熟練者の優れた「かんと経験」
３．工数のコンとルールを実現
４．予算超過リスクの定量評価を実現
５．プロセス改善のポイントを把握
４．ＣｏＢＲＡ法の概要
・ＣｏＢＲＡ法のコンセプト「勘」と「経験」を見える化する
「勘」と「経験」は問題→「形式知化」
・ＣｏＢＲＡ法における工数見積もりの考えから
規模が同じでもかかる工数に違い
ベースの生産性αとそこからのオーバーヘッド（ＣＯ：コストオーバーヘッド）
熟練者の考え方：オーバーヘッドに使う
→実績データに照らし合わせてαを計算
見積もり手法
経験ベース型
データ駆動
ハイブリッド＝ＣｏＢＲＡ法
・工数見積もりの手順
１．機微の推定
２．変動要因の影響度を評価→レベル
３．見積もりの実行→ツールを使用
・ツールでの見積もり手法
想定規模の入力
変動要因の入力
見積もりの実行と結果の確認
見積もり結果と感度分析
・ＣｏＢＲＡツール
ＩＰＡ／ＳＥＣから
簡易ツール
統合ツール
・利用シーン
コストマネジメント
リスクマネジメント
プロセス改善
・ＩＥＳＥ（いえぜ）でできた
ＩＰＡ
本が出た
ＣｏＢＲＡ法入門
５．ＣｏＢＲＡモデルの構築方法
・構築手順
（１）変動要因の抽出、定義
変動要因を聞き出す／確認
（２）実績データの収集
（３）モデルの構築
→誤差が出てくる
（４）見積もり精度の改善
・【手順１】変動要因の洗い出し
アンケートで吸い上げて、ブレスト
関係者の協力度合い・・・
いっぱい要員が出てくるので、こまる
→しぼりこみ
要因が独立していることが重要
４段階の定義
まずレベル０とレベル３をきめ、間を決める
どの組織でも似たようなものが出てくる
定量化
レベル０、レベル３のとき、どれだけ工数がかかりますか？
→三角分布
・【手順２】実測データの収集
書く変動要因の工数への影響度を４段階で評価
・【手順３】計算：ツールがやってくれる
→さんかく分布のところ
→αのところ
・【手順４】見積もり制度の改善
ＭＭＲＥ 見積もり誤差率の平均値
Ｐｒｅｄ２５：見積もり誤差率が２５％以内のプロジェクトの割合
→分散を見ている
・初期モデルの見積もり制度：ＭＭＲＥが３０～４０％
見積もり誤差の原因を探る
６．ＣｏＢＲＡモデルの応用
・工数のコントロール
→影響度のコントロール
・ＣＯが高いものを重点的に
・いつも高い要員をチェック
７．事例紹介
・ＩＰＡ／ＳＥＣとＩＥＳＥの共同研究 沖電気
・「ＣｏＢＲＡ法入門」の本にかかれている事例
・ＩＰＡジャーナルで日本ＩＢＭ（Ｎｏ２６）
・三菱電機など（ＳＥＣセミナー）
の第10回
ソフトウェア開発見積もりの課題と解決方法
～見積もり手法の歴史とCoBRA法～
を聞いてきたのでメモメモ
１．見積もりにおける課題
・プロジェクトマネジメントにおける見積もりの位置づけ
みつもり→プロジェクトマネジメントの中核
・プロジェクトにおける大きな課題のひとつ
プロジェクトを大失敗させる原因は２つある
ひとつ波つもりミスだ
楽観的な見積もり
早期の見積もり
目標と見積もりの混同
一度決まったら修正されない
時間の余裕がないことが多い
もうひとつは仕様未凍結
見積もりミスにつながる
→無理なプロジェクト
ロバートグラス
「ソフトウェア開発５５の真実と１０のうそ」
・見積もりもスを引き起こす原因
ケーパージョーンズ
１．要求が完全に決定される前に正式な見積もりが求められる
２．見積もり修正されない
３．ツール使われない
４．きゃリブレーションできない
５．保守的→挑戦的に
・見積もりの国内の実践状況
ベンダ企業
属人的な方法が減少している一方、類推的な方法が残る
ユーザー企業
相見積もり→ベンダの見積もりに依存
・見積もりにおける課題（１）
見積もり根拠が明確になっていない（規模、工数、工期）
→ＫＫＤできまる
見積もりに必要な情報がはっきりしない
見積もり方法もその場限り
生産性に影響を及ぼす要因が多種多様（工数）
→プロジェクト状況の影響
→影響要員がわかっていても、定量化が難しい
・実績プロジェクトデータ
ばらついている
・見積もりにおける課題（２）
過去データの欠落、制度の確保
分析が難しい
見積もり実施者の傾向
ほとんどのコスト見積もりは低すぎる傾向がある（ＤｅＭａｒｃｏ－Ｇｌａｓｓの法則）
・見積もりにおける課題（３）
部分的な情報からの見積もり（規模）
→細部が決まっていない状況で見積もりを行う場合が多い
(予算決めなど早い段階）
→部分的な情報から推論するしかない
実際とブレが出ることは避けられない
４倍から４分の１
・見積もりにおける課題（４）
決めたことが変わっていく（規模）
開発当初の想定機能は、一般に肯定が進むに従って膨張する
→見えていなかった要件が見えてくる
→最初の要件とぶれる
２．見積もり手法の歴史と蓄積
・見積もり手法に関する大きな流れ
６０年代 ソフトウェア開発の黎明期
７０年代 見積もりも出る提案の時期
８０年代 見積もりモデルの成熟期
９０年代 ツールの成熟、機械学習の応用
２０００年代 熟練者の知識活用の再確認
・ソフトウェアにおける見積もりに関する歴史と蓄積
１９５８ノードン(Curve Fitting for a Model of Applied Resarch and development scheduling"
ネルソン １９６６
６つの工程に分類
nelson-jonesの法則
多くの要素が開発生産性に影響
・その２
１９７０年代は見積もりモデル提案の時期
工数の期間の関係
プットナム ＳＬＩＭモデル→演繹的に導く
ファンクションポイント
１９７０年代のモデルにおける課題
重視する要素に違い
・その３
８０年代ＣＯＣＯＭＯモデル ベームによって開発
（ＴＲＷにいたとき）
パラメトリック手法→バジル メタモデルの数値化
一方、主要な結論として、ある環境で構築されたモデルは
そのままでは他の環境での精度はよくない
→キャリブレーションを行う必要がある
・その４
９０年代における機械学習方法の適用（データマイニング）
データに語らせる
機械学習アルゴリズム
ニューラルネットワーク
ＣＡＲＴ
基本的にパターンに分類して見積もりを行う
９０年代後半から２０００年代：熟練者の判断
主観的な見積もり
熟練者の治験を活用した定量化（ＣｏＢＲＡ Braiandら1998)
３．見積もり根拠の見える化
・見積もりの見える化とモニタリングとコントロール（解決方法）
対策１：見積もりモデルの確立
→再現性の確保
対策２：見積もりの妥当性の確保
→想定したものをインプット
前提を変えたシミュレーション
対策３：モニタリングとコントロールと再見積もり
対策４：目標と見積もりの峻別
→すべての出発点は見積もりモデル
・見積もり根拠の見える化の重要性
見積もり根拠の見える化＝コスト構造の見える化が重要
・見える化の課題
工数のぶれをどう説明するか
・具体的な解決策ＣｏＢＲＡ
・５つの特徴
１．組織固有のコスト変動要因をモデル化
２．コスト変動要因に、熟練者の優れた「かんと経験」
３．工数のコンとルールを実現
４．予算超過リスクの定量評価を実現
５．プロセス改善のポイントを把握
４．ＣｏＢＲＡ法の概要
・ＣｏＢＲＡ法のコンセプト「勘」と「経験」を見える化する
「勘」と「経験」は問題→「形式知化」
・ＣｏＢＲＡ法における工数見積もりの考えから
規模が同じでもかかる工数に違い
ベースの生産性αとそこからのオーバーヘッド（ＣＯ：コストオーバーヘッド）
熟練者の考え方：オーバーヘッドに使う
→実績データに照らし合わせてαを計算
見積もり手法
経験ベース型
データ駆動
ハイブリッド＝ＣｏＢＲＡ法
・工数見積もりの手順
１．機微の推定
２．変動要因の影響度を評価→レベル
３．見積もりの実行→ツールを使用
・ツールでの見積もり手法
想定規模の入力
変動要因の入力
見積もりの実行と結果の確認
見積もり結果と感度分析
・ＣｏＢＲＡツール
ＩＰＡ／ＳＥＣから
簡易ツール
統合ツール
・利用シーン
コストマネジメント
リスクマネジメント
プロセス改善
・ＩＥＳＥ（いえぜ）でできた
ＩＰＡ
本が出た
ＣｏＢＲＡ法入門
５．ＣｏＢＲＡモデルの構築方法
・構築手順
（１）変動要因の抽出、定義
変動要因を聞き出す／確認
（２）実績データの収集
（３）モデルの構築
→誤差が出てくる
（４）見積もり精度の改善
・【手順１】変動要因の洗い出し
アンケートで吸い上げて、ブレスト
関係者の協力度合い・・・
いっぱい要員が出てくるので、こまる
→しぼりこみ
要因が独立していることが重要
４段階の定義
まずレベル０とレベル３をきめ、間を決める
どの組織でも似たようなものが出てくる
定量化
レベル０、レベル３のとき、どれだけ工数がかかりますか？
→三角分布
・【手順２】実測データの収集
書く変動要因の工数への影響度を４段階で評価
・【手順３】計算：ツールがやってくれる
→さんかく分布のところ
→αのところ
・【手順４】見積もり制度の改善
ＭＭＲＥ 見積もり誤差率の平均値
Ｐｒｅｄ２５：見積もり誤差率が２５％以内のプロジェクトの割合
→分散を見ている
・初期モデルの見積もり制度：ＭＭＲＥが３０～４０％
見積もり誤差の原因を探る
６．ＣｏＢＲＡモデルの応用
・工数のコントロール
→影響度のコントロール
・ＣＯが高いものを重点的に
・いつも高い要員をチェック
７．事例紹介
・ＩＰＡ／ＳＥＣとＩＥＳＥの共同研究 沖電気
・「ＣｏＢＲＡ法入門」の本にかかれている事例
・ＩＰＡジャーナルで日本ＩＢＭ（Ｎｏ２６）
・三菱電機など（ＳＥＣセミナー）
アジャイルのＸＰなどでは、ペアプログラミングとしてペアを作って開発するわけだけど、
このペアの組み方、２通りが考えられる。
・レベル差がある場合
・レベル差がない場合
レベル差がある場合は、主に教育的な意図で組まれると思う。必ずしも、スピードアップは望めないが、
組織としては意義が大きい。
後者は、「レベルの差はないが、見方が違う」場合に効果がある。
とくに、開発エンジニアとテストエンジニアが組んだ場合、開発と同時にテストするようなものなので、
手戻りが最小になり、モノができたとき、バグが減っていることが期待できる。
このバグ修正期間の短縮により、ペアプログラミング（は２人で開発するから）のプログラム期間における工数が、２倍になることが解消できる（ようになると、アジャイルの意味は大きい）
このペアの組み方、２通りが考えられる。
・レベル差がある場合
・レベル差がない場合
レベル差がある場合は、主に教育的な意図で組まれると思う。必ずしも、スピードアップは望めないが、
組織としては意義が大きい。
後者は、「レベルの差はないが、見方が違う」場合に効果がある。
とくに、開発エンジニアとテストエンジニアが組んだ場合、開発と同時にテストするようなものなので、
手戻りが最小になり、モノができたとき、バグが減っていることが期待できる。
このバグ修正期間の短縮により、ペアプログラミング（は２人で開発するから）のプログラム期間における工数が、２倍になることが解消できる（ようになると、アジャイルの意味は大きい）
例えばＭｙＳＱＬで、
東京にあるマシンのデータベース名kaikei
に会計関連のテーブルがいっぱいあったとする（toriki_TBL,URIAGE_TBLなど）。
で、大阪に営業支社があり、
大阪にあるマシンのデータベース名eikyo_o
に営業関連のテーブルがいっぱいあったとする。
東京にあるマシンのデータベース名kaikeiにあるテーブルと
大阪にあるマシンのデータベース名eigyo_oにあるテーブルを
ＪＯＩＮしてみたいという場合。
物理的に離れた、ほかのデータベースでも、ＭｙＳＱＬなら、
インターネットでつながって、権限があるのなら、ＯＫらしい。
Federatedeエンジンというのがあって、これを使うと、リモートのテーブルが
あたかもローカルのテーブルのように仮想的に扱えるらしい。
詳しくは
Federatedエンジンとは
http://thinkit.co.jp/free/article/0608/1/5/
具体的には
１．my.iniにあるskip-federetedをコメントにして
federeted
に書き換える
２．テーブルを作る際、CREATE TABLEで、
ENGINE=FEDERATED
CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
のように、Federatedエンジンを指定して、CONNECTIONにコネクション先を書く。
コネクション先の詳しい書き方は
13.9.2.1. CONNECTIONを利用して FEDERATED テーブルを作成する
http://dev.mysql.com/doc/refman/5.1/ja/federated-create-connection.html
を参照。
東京にあるマシンのデータベース名kaikei
に会計関連のテーブルがいっぱいあったとする（toriki_TBL,URIAGE_TBLなど）。
で、大阪に営業支社があり、
大阪にあるマシンのデータベース名eikyo_o
に営業関連のテーブルがいっぱいあったとする。
東京にあるマシンのデータベース名kaikeiにあるテーブルと
大阪にあるマシンのデータベース名eigyo_oにあるテーブルを
ＪＯＩＮしてみたいという場合。
物理的に離れた、ほかのデータベースでも、ＭｙＳＱＬなら、
インターネットでつながって、権限があるのなら、ＯＫらしい。
Federatedeエンジンというのがあって、これを使うと、リモートのテーブルが
あたかもローカルのテーブルのように仮想的に扱えるらしい。
詳しくは
Federatedエンジンとは
http://thinkit.co.jp/free/article/0608/1/5/
具体的には
１．my.iniにあるskip-federetedをコメントにして
federeted
に書き換える
２．テーブルを作る際、CREATE TABLEで、
ENGINE=FEDERATED
CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
のように、Federatedエンジンを指定して、CONNECTIONにコネクション先を書く。
コネクション先の詳しい書き方は
13.9.2.1. CONNECTIONを利用して FEDERATED テーブルを作成する
http://dev.mysql.com/doc/refman/5.1/ja/federated-create-connection.html
を参照。
え～、よくわかってない。よくわかっていないのだが、
どうやら、今日、世間では
サービスコンピューティング研究専門委員会 2012年度第1回研究会
http://sig-sc.org/
というのがあったらしく、２回目研究会は、
上記表題の内容らしい。
具体的には、こんなかんじらしいよ(以下太字は上記サイトより引用）
テーマ: 「サービス・クラウドにおけるAI応用」および一般
日程：2012年8月20日 (月)
場所：国立情報学研究所(NII) 12F会議室
電子情報通信学会 人工知能と知識処理研究会，およびサービスコンピューティング研究会では「サービス・クラウドにおけるAI応用」および一般と題して，サービスコンピューティングへの知的アプローチに関する研究会を開催致します．
本研究会では，以下のようなテーマに沿ったご発表を募集致します（但し，これらに限定するものではありません）．
■クラウドサービス検索・マッシュアップ
■サービスの自動合成・自動選択・推薦
■ポリシー管理，相互運用性，信頼性，セキュリティ，品質保証
■ストリームデータ処理，ストリームデータマイニング
■ビッグデータ分析，ビッグデータ活用サービス
■Linked Dataサービス
■Webサービスやクラウド運営，連携における経済モデル，ゲーム理論
■サイバー・フィジカルシステム
■実適用事例
また，研究者間の交流を意図し，テーマとは別にサービスコンピューティング，AI一般のご発表も歓迎致します．
以上、報告終わり！
どうやら、今日、世間では
サービスコンピューティング研究専門委員会 2012年度第1回研究会
http://sig-sc.org/
というのがあったらしく、２回目研究会は、
上記表題の内容らしい。
具体的には、こんなかんじらしいよ(以下太字は上記サイトより引用）
テーマ: 「サービス・クラウドにおけるAI応用」および一般
日程：2012年8月20日 (月)
場所：国立情報学研究所(NII) 12F会議室
電子情報通信学会 人工知能と知識処理研究会，およびサービスコンピューティング研究会では「サービス・クラウドにおけるAI応用」および一般と題して，サービスコンピューティングへの知的アプローチに関する研究会を開催致します．
本研究会では，以下のようなテーマに沿ったご発表を募集致します（但し，これらに限定するものではありません）．
■クラウドサービス検索・マッシュアップ
■サービスの自動合成・自動選択・推薦
■ポリシー管理，相互運用性，信頼性，セキュリティ，品質保証
■ストリームデータ処理，ストリームデータマイニング
■ビッグデータ分析，ビッグデータ活用サービス
■Linked Dataサービス
■Webサービスやクラウド運営，連携における経済モデル，ゲーム理論
■サイバー・フィジカルシステム
■実適用事例
また，研究者間の交流を意図し，テーマとは別にサービスコンピューティング，AI一般のご発表も歓迎致します．
以上、報告終わり！
SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第９回
組込みソフトウェアのプロジェクト計画書を作成する
～『組込みソフトウェア向けプロジェクトマネジメントガイド』の解説～
を聞いてきたのでメモメモ
組み込みソフトウェアのプロジェクト計画書を作成する
SEC組み込み系プロジェクト「開発管理技術部会」活動性か
組み込みソフトウェア向けプロジェクトマネジメントガイド
IEEE １０５８に委員会の知見
組み込みソフトウェア向けプロジェクト計画立案トレーニングガイド
ESMRの実践編
１組み込みソフトウェア開発を取り巻く環境
ソフトウェア開発規模
ソフトウェア開発期間の短縮
サイズは大きく、期間は短く
組み込みとエンタプライズの比較
開発費、全行数、開発プロジェクトの中身
組み込みとエンタプライズの差はない
組み込みプロジェクト計画の達成状況
達成できなかったのが２割
いままでは、納期、コストはもっとひどかった
背反する問題
短納期、低コスト
プロジェクトマネジメントの重要性
ソフトウェア規模の増大
QCDの制約増大
↓
プロジェクトの運営がより難しくなってきている
良いプロジェクトVS悪いプロジェクト
悪い
そもそもの計画に無理
良い
適正なスケジュール
無理ムダ矛盾の排除
→現実的な計画書を作ることが大事
プロジェクト計画書の作成方法
７割が会社に共通の規定
プロジェクト計画書作成上の問題点
計画書にどのような項目を書いていいかわからない
計画書に書くべき項目はわからなかったとしても、具体的にどのように項目を埋めていくかわからない
部門として共通化された計画書のフォーマットなどが整備されていない
複数部門との協業でプロジェクトを進める場合に部門や組織によって計画書の書き方が異なっている
そもそも計画書をいつ、誰が書くのか決まっていない
２．プロジェクト計画書とは何か
プロジェクト計画書の目的
実現可能性の判断材料
共通理解としてのべース
プロジェクトをコントロール
予実の差分の把握
誰にために作成する
経営者
管理者
PJマネージャー
PJメンバー
関係他部署
プロジェクト計画書に書く内容
・PJの概要情報
・PJ体制
・Costの計画
・デリバリーの計画
・クオリティーの計画
プロジェクト計画書のフォーマット例
SEC HPからダウンロード可
誰がいつ書くか
プロジェクトに責任を持つ人
キックオフさせるために
プロジェクトマネージャー
詳細は理解しているメンバー：段階的に
ある時点で確定させる
３．プロジェクト計画を立案する手順
検討テーマ
プロジェクト条件を洗い出す
目的、目標、修了条件
特徴、課題を把握
品質計画
実施する作業を決める
工数計画を行う
要員計画を立てる
コスト計画
リスクマネジメント
体制、運営の仕組み
日程計画表を作成
（１） プロジェクト条件を洗い出す
条件を洗い出す視点３つ
ソフトウェア（要求の把握）
ハードウェア装置
作業範囲、引き渡し
与えられる条件
メンバー、請負会社
ツール、場所
プロジェクト内部で検討できる要件
もれなく洗い出す
（２）プロジェクトの目的、目標、終了条件を明確に
→メンバーで共有
→コスト、品質
（３）プロジェクトの特徴や課題を把握する
→要員とスキル、開発規模、リスク（候補）
（４）品質計画をたてる
品質方針
品質作りこみ手順
テーマ２、ISO9126、ESQR
（５）実施する作業を決める
開発プロセスを明確
開発対象を機能分割する
→アーキテクチャ設計しなければ、機能ユニットは抽出されない
扱いやすい作業単位
実施する作業内容を明確にする
（６）工程設計を行う
日程計画表のラフデッサン
工数見積もり、要員割付のために全体イメージを把握
重要イベント
工程の期間配分
作業の実施順序を決めて、時間軸上に割付
ウォーターフォールで作業見積もりがたたない場合
→スパイラル
（７）要員計画を立てる
ソフトウェア規模と工数
生産性の定義
個々の作業に必要な人数とスキルを検討する
要員を割り付けながら期間・人数調整
キーパーソンの配置
（８）コスト計画を立てる
要員コストを見込む
設備、機器、ツール類を洗い出し、コストを見込む
→ケータイの費用も
要員研修計画をたて、コストを見込む
コスト目標：予算
（９）リスクマネジメント
テーマ（１）～（８）のリスクを整理
イニシャルリスクを洗い出す
リスクを分析し、評価する
リスクのモニター
（１０）プロジェクトの体制と運用の仕組みを明確にする
プロジェクト体制を明確に
会議体や情報共有など、プロジェクト運営の仕組みを明確にする
（１１）日程計画表を作成する
４．最後に
ESMGの読み方
事例：自動改札機
ESMGトレーニング
自習書
テーマ、項目、ステップ、チェック
手順
１．テーマの説明
２．項目
３．ステップ、チェック
５．まとめ
・規模が大きくなってくると
プロジェクトの進むべき方向を共有することが大切
しかし、共有することが難しい
・計画立案はなぜ難しいか
教わる人がいない
まる請け→スキル不足
・プロジェクトマネージャーの板ばさみ
経営者：あるべき姿で計画せよ
現場：無理のない現実的な計画を立てるべき
の第９回
組込みソフトウェアのプロジェクト計画書を作成する
～『組込みソフトウェア向けプロジェクトマネジメントガイド』の解説～
を聞いてきたのでメモメモ
組み込みソフトウェアのプロジェクト計画書を作成する
SEC組み込み系プロジェクト「開発管理技術部会」活動性か
組み込みソフトウェア向けプロジェクトマネジメントガイド
IEEE １０５８に委員会の知見
組み込みソフトウェア向けプロジェクト計画立案トレーニングガイド
ESMRの実践編
１組み込みソフトウェア開発を取り巻く環境
ソフトウェア開発規模
ソフトウェア開発期間の短縮
サイズは大きく、期間は短く
組み込みとエンタプライズの比較
開発費、全行数、開発プロジェクトの中身
組み込みとエンタプライズの差はない
組み込みプロジェクト計画の達成状況
達成できなかったのが２割
いままでは、納期、コストはもっとひどかった
背反する問題
短納期、低コスト
プロジェクトマネジメントの重要性
ソフトウェア規模の増大
QCDの制約増大
↓
プロジェクトの運営がより難しくなってきている
良いプロジェクトVS悪いプロジェクト
悪い
そもそもの計画に無理
良い
適正なスケジュール
無理ムダ矛盾の排除
→現実的な計画書を作ることが大事
プロジェクト計画書の作成方法
７割が会社に共通の規定
プロジェクト計画書作成上の問題点
計画書にどのような項目を書いていいかわからない
計画書に書くべき項目はわからなかったとしても、具体的にどのように項目を埋めていくかわからない
部門として共通化された計画書のフォーマットなどが整備されていない
複数部門との協業でプロジェクトを進める場合に部門や組織によって計画書の書き方が異なっている
そもそも計画書をいつ、誰が書くのか決まっていない
２．プロジェクト計画書とは何か
プロジェクト計画書の目的
実現可能性の判断材料
共通理解としてのべース
プロジェクトをコントロール
予実の差分の把握
誰にために作成する
経営者
管理者
PJマネージャー
PJメンバー
関係他部署
プロジェクト計画書に書く内容
・PJの概要情報
・PJ体制
・Costの計画
・デリバリーの計画
・クオリティーの計画
プロジェクト計画書のフォーマット例
SEC HPからダウンロード可
誰がいつ書くか
プロジェクトに責任を持つ人
キックオフさせるために
プロジェクトマネージャー
詳細は理解しているメンバー：段階的に
ある時点で確定させる
３．プロジェクト計画を立案する手順
検討テーマ
プロジェクト条件を洗い出す
目的、目標、修了条件
特徴、課題を把握
品質計画
実施する作業を決める
工数計画を行う
要員計画を立てる
コスト計画
リスクマネジメント
体制、運営の仕組み
日程計画表を作成
（１） プロジェクト条件を洗い出す
条件を洗い出す視点３つ
ソフトウェア（要求の把握）
ハードウェア装置
作業範囲、引き渡し
与えられる条件
メンバー、請負会社
ツール、場所
プロジェクト内部で検討できる要件
もれなく洗い出す
（２）プロジェクトの目的、目標、終了条件を明確に
→メンバーで共有
→コスト、品質
（３）プロジェクトの特徴や課題を把握する
→要員とスキル、開発規模、リスク（候補）
（４）品質計画をたてる
品質方針
品質作りこみ手順
テーマ２、ISO9126、ESQR
（５）実施する作業を決める
開発プロセスを明確
開発対象を機能分割する
→アーキテクチャ設計しなければ、機能ユニットは抽出されない
扱いやすい作業単位
実施する作業内容を明確にする
（６）工程設計を行う
日程計画表のラフデッサン
工数見積もり、要員割付のために全体イメージを把握
重要イベント
工程の期間配分
作業の実施順序を決めて、時間軸上に割付
ウォーターフォールで作業見積もりがたたない場合
→スパイラル
（７）要員計画を立てる
ソフトウェア規模と工数
生産性の定義
個々の作業に必要な人数とスキルを検討する
要員を割り付けながら期間・人数調整
キーパーソンの配置
（８）コスト計画を立てる
要員コストを見込む
設備、機器、ツール類を洗い出し、コストを見込む
→ケータイの費用も
要員研修計画をたて、コストを見込む
コスト目標：予算
（９）リスクマネジメント
テーマ（１）～（８）のリスクを整理
イニシャルリスクを洗い出す
リスクを分析し、評価する
リスクのモニター
（１０）プロジェクトの体制と運用の仕組みを明確にする
プロジェクト体制を明確に
会議体や情報共有など、プロジェクト運営の仕組みを明確にする
（１１）日程計画表を作成する
４．最後に
ESMGの読み方
事例：自動改札機
ESMGトレーニング
自習書
テーマ、項目、ステップ、チェック
手順
１．テーマの説明
２．項目
３．ステップ、チェック
５．まとめ
・規模が大きくなってくると
プロジェクトの進むべき方向を共有することが大切
しかし、共有することが難しい
・計画立案はなぜ難しいか
教わる人がいない
まる請け→スキル不足
・プロジェクトマネージャーの板ばさみ
経営者：あるべき姿で計画せよ
現場：無理のない現実的な計画を立てるべき
ということがおこった。理由は
＜？＝
を認めているかどうかだった。apacheのデフォルトは
＜？ｐｈｐ
で始めないと許さない（ＸＭＬの指定も＜？だから）
このとき、＜？でもＯＫなようにするには、
php.iniの
short_open_tag = Off
を
short_open_tag = On
にして、apacheを再起動する。
参考
http://blogs.yahoo.co.jp/nob_ll/49184402.html
＜？＝
を認めているかどうかだった。apacheのデフォルトは
＜？ｐｈｐ
で始めないと許さない（ＸＭＬの指定も＜？だから）
このとき、＜？でもＯＫなようにするには、
php.iniの
short_open_tag = Off
を
short_open_tag = On
にして、apacheを再起動する。
参考
http://blogs.yahoo.co.jp/nob_ll/49184402.html
アクセス
トータル
ランキング
