More Related Content Similar to 「事実にもとづく管理」によるソフトウェア品質の改善 ｰ ヒンシツ大学 Evening Talk #04 Similar to 「事実にもとづく管理」によるソフトウェア品質の改善 ｰ ヒンシツ大学 Evening Talk #04 (20) 2. • 所属
– 東洋⼤学 経営学部 経営学科 教授
• 背景
– ⼯業経営／経営システム⼯学、ソフトウェア⼯学、品質マネジメント
• 主な学外活動
– ⽇本科学技術連盟 SQiPソフトウェア品質委員会 運営委員⻑
– IPA/SEC ⾼信頼化定量管理部会主査（『ソフトウェア開発データ⽩書』）
– ⽇本SPIコンソーシアム 外部理事
– 国⽴情報学研究所 特任研究員 （トップエスイー講座、ソフトウェアメトリクス）
– 厚⽣労働省職業安定局 ハローワークシステムに係る調達案件審査委員会 委員
• 主な著書
– SQuBOK策定部会編『ソフトウェア品質知識体系ガイド 第2版－SQuBOK Guide V2－』オーム社 (2014)
– 野中・⼩池・⼩室『データ指向のソフトウェア品質マネジメント』⽇科技連出版社 (2012)
（2013年度⽇経品質管理⽂献賞受賞）
– 野中・鷲崎訳『演習で学ぶ ソフトウェアメトリクスの基礎』⽇経BP社 (2009)
– SQuBOK策定部会編『ソフトウェア品質知識体系ガイド－SQuBOK Guide－』オーム社 (2007)
• 研究・教育
– ソフトウェア品質マネジメント（メトリクスを中⼼に）
– 情報システムと経営の関わり
22015/2/13 Makoto Nonaka、 Toyo University
9. ソフトウェア開発組織における品質管理能⼒の⾃⼰評価
上位１０組織 vs 下位９組織
9
⽐較項⽬
上位1/4の組織 下位1/4の組織
実施率
ミッション
認識率
実施率
ミッション
認識率
完了済プロジェクトの実績データの
収集と分析
0.90 0.80 0.33 0.33
定量的な評価基準・判断基準の策定 0.90 0.60 0.56 0.22
進⾏中プロジェクトのモニタリング 0.90 0.60 0.50 0.13
モニタリング結果の分析とアクション 0.90 0.60 0.25 0.13
不具合の収集と原因分析 0.80 0.60 0.50 0.25
⾃⼰評価の⾼い組織においては、定量的品質管理を軸とした活動を
品質部⾨のミッションと位置づけ、ルーチンとして実施している
http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf
2015/2/13
（N=42）
Makoto Nonaka、 Toyo University
10. リリース後の⽋陥状況：⽋陥密度のベンチマークデータ
10
項⽬ インド ⽇本 ⽶国 欧州他 合計・平均
調査対象のプロジェクト数（件） 24 27 31 22 104（合計）
開発規模の中央値（KLOC） 209 469 270 436 374
リリース後⽋陥密度の中央値（KLOC当たり） 0.263 0.020 0.400 0.225 0.150
⽇・⽶・欧・印のパフォーマンス⽐較 （Cusumano et. al., 2003）
Cusumano, M., et. al., “Software Development Worldwide: The State of the Practice,” IEEE Software, Nov/Dec 2003, pp.28-34.
項⽬
新規開発
(N = 520)
改良開発
(N = 349)
リリース後不具合密度の中央値（KLOC当たり） 0.016 0.000
リリース後不具合密度の平均値（KLOC当たり） 0.106 0.123
IPA/SEC 『ソフトウェア開発データ⽩書2012-2013』
• この指標で組織横断的に⽐較するのは眉唾かもしれない
• 測定⽅法が揃った同⼀組織において、製品を提供した後の状況を把握し、
その分布や変化を知ることが品質改善の第⼀歩
2015/2/13 Makoto Nonaka、 Toyo University
11. システムテストにおける⽋陥収束状況を把握する
不具合オープン・クローズチャートと不具合検出率推移グラフ
アクション案
不具合検出率
12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25
不具合検出率 日毎 5日間移動平均
不具合オープン－クローズチャート
12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25
不具合件数 オープン クローズ
検出された不具合の
内容を確認したところ、
序盤としては瑣末な
ものが多かった
• 開発者の不具合修正対応が
追い付いていない
• 不具合検出件数も増加傾向
• 序盤では、重箱の隅をつつ
くような不具合検出よりも、
致命的な不具合検出に注⼒
すべき
• テスト担当者には、
瑣末不具合の検出ではなく、
デグレードの確認に注⼒し
てもらう
• 開発者には、不具合に優先
順位を付けて重⼤なものか
ら確実に対応するよう促す
グラフと不具合内容に
対する所⾒
注）検出された不具合が瑣末なものではなく、
致命的なものが多い場合は異なるアクション
となる
不具合件数／テスト⼯数
2015/2/13 Makoto Nonaka、 Toyo University
11
不具合検出率 ＝ 不具合検出件数／テスト⼯数
①傾きに着⽬
②乖離に着⽬
③内容に着⽬
④移動平均グラフを描いて傾向を把握
野中・⼩池・⼩室著 『データ指向のソフトウェア品質マネジメント』 ⽇科技連出版社 (2012)
12. 参考：不具合検出率のチャートそのものは昔から使われている
2015/2/13 Makoto Nonaka、 Toyo University
12
不具合検出率
12/1 12/8 12/15 12/22 1/5 1/13 1/20 1/27 2/3 2/17 2/24 3/3 3/10 3/17 3/25
不具合検出率 日毎 5日間移動平均
不具合検出率
＝ 不具合検出件数／テスト工数
Defect Rate
= Defects per 1000 Hours
• 現場での様々な⼯夫は、先⼈の誰かがすでに⼿がけていることが多い
• そこで諦めるのではなく、「⼩さな⽯」を積み上げ続けていくことが⼤事
野中誠・小池利和・小室睦（2012）
『データ指向のソフトウェア品質
マネジメント』日科技連出版社
Grady, R.B. and Caswell, D.L. (1987)
Software Metrics: Establishing a
Company-wide Program,
Prentice Hall
13. テスト進捗状況の把握例 テスト進捗管理図
13
オープンチャートに次の要素を追加
• テストケースの消化状況
• 管理限界
0.0
0.2
0.4
0.6
0.8
1.0
0.0
0.2
0.4
0.6
0.8
1.0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
未消化テストケース数の比率
累積欠陥摘出数の比率
テスト経過週数（週）
未消化テストケース数
UCL (Upper Control Limit)
LCL (Lower Control Limit)
累積欠陥摘出数
UCL (Upper Control Limit)
LCL (Lower Control Limit)
複数メトリクスの組み合わせで、
問題となっている状況を検知する
• 累積不具合検出推移が
管理限界を超えている
• テストケースの消化状況が
管理限界を下回っている
2015/2/13 Makoto Nonaka、 Toyo University
15. ⽋陥除去⽐率（DRE: Defect Removal Efficiency）
ある⽋陥除去⼯程の開始時点で残存していた⽋陥を、その⼯程でどれだけ除去できたかを表す
15
Laird, L. M. and Brennan, M. C., Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006 (野中誠・鷲崎弘宜訳：演習で学ぶソフトウェアメトリクスの
基礎, ⽇経BP社, 2009).
Kan, S. H., Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002 (古⼭恒夫・冨野壽監訳, ソフトウェア品質⼯学の尺度とモデル, 共⽴出版, 2004).
混⼊
除去
要求
定義
機能
設計
詳細
設計
ｺｰﾃﾞｨ
ﾝｸﾞ
単体
テスト
結合
テスト
ｼｽﾃﾑ
テスト
運⽤ 合計 DRE
機能設計
ｲﾝｽﾍﾟｸｼｮﾝ
49 681 730 74.4%
詳細設計
ｲﾝｽﾍﾟｸｼｮﾝ
6 42 681 729 61.3%
コード
ｲﾝｽﾍﾟｸｼｮﾝ
12 28 114 941 1095 54.8%
単体テスト 21 43 43 223 2 332 36.7%
結合テスト 20 41 61 261 － 4 387 67.1%
ｼｽﾃﾑテスト 6 8 24 72 － － 1 111 58.1%
運⽤ 8 16 16 40 － － － 1 81
合計 122 859 939 1537 2 4 1 1 3465 97.7%
例：詳細設計ｲﾝｽﾍﾟｸｼｮﾝの DRE
DRE = 729 /
(122+859+939 – 730)
⽋陥除去能⼒の低い⼯程を特定し、重点改善対象の候補とする
プロセス全体
のDRE
2015/2/13 Makoto Nonaka、 Toyo University
17. ⽋陥状況を把握するにあたり、⽋陥分類を標準化するとよい
17
• ⽋陥の定量的管理の前提として、⽋陥の分類を考えておく必要がある
• ⽋陥除去の前倒しについて議論するときは、機能性⽋陥に着⽬した⽅が望ましい
• 将来の機能性⽋陥につながる発展性⽋陥も、その混⼊・摘出状況を把握し、
早期に摘出できていることを確認した⽅が望ましい
• ⽋陥の分類に着⽬して、プロジェクトの状況を把握する
Mäntylä, M. V. and Lassenius, C., “What Types of Defects Are Really Discovered in Code Reviews?,” IEEE Trans. Softw. Eng., vol. 35, no. 3, pp. 430-448, 2009.
⼤規模⽋陥
サポート
タイミング
チェック
リソース
ロジック
インタフェース
構造
視覚的表現
ドキュメンテーション
機能性の⽋如、⼤幅な追加・修正が必要
ライブラリの⽋陥
マルチスレッド環境で⽣じる問題
妥当性確認ミス、不正な値の検出ミス
ライブラリ、デバイス、DB、OS等とのインタフェース不整合
⽐較演算⼦、制御フロー、計算などの誤り
データ、変数、リソース初期化、解放などの誤り
コード構造
コードの読みやすさ
コードの説明
参考：コードインスペクション指摘の
約70%は、発展性⽋陥を検出
(Mäntylä, 2009)
機能性⽋陥
(functional defects)
発展性⽋陥
(evolvability defects)
障害 (fault)に相当
標準との乖離
(anomaly)に相当
2015/2/13 Makoto Nonaka、 Toyo University
19. レビューの終了条件を明確化する
ゾーン分析 〜 レビューメトリクスの組合せによる判断
• レビュー指摘密度：規模当たりのレビュー指摘件数（件／規模）
• レビュー⼯数密度：規模当たりのレビュー⼯数（⼯数／規模）
2015/2/13 Makoto Nonaka、 Toyo University
19
レ
ビ
ュ
ー
指
摘
密
度
レビュー⼯数密度
① ② ③
問題
あり？
？
問題なし
⑧ ⑨
SQiP2012『SQiP品質保証部⻑の会 からの情報発信』
品質良好？
問題あり？
問題なし
品質良好？
問題あり？
判断不能
上⽅管理限界
下⽅管理限界
上⽅管理限界 下⽅管理限界
22. CKメトリクスとfault-proneモジュール予測 (Zhou and Leung 2006)
2015/2/13 Makoto Nonaka、 Toyo University
22
研究 言語 WMC DIT RFC NOC CBO LCOM SLOC 備考
Basili 1996 C++ ++ ++ -- + LR
Briand 1999 C++ + ++ LR
Tang 1999 C++ + 0 + 0 0 LR
Briand 2000 C++ + ++ ++ - ++ ++ LR
Briand 2001 C++ ++ - ++ 0 ++ LR
Yu 2002 Java ++ 0 + + + + + OLS+LDA
El Eman 2003-1 規模未調整 C++ + 0 ++ + ++ LR
El Eman 2003-2 規模調整 C++ 0 0 0 0 ++ LR
Subramanyam 2003-1 C++ + - + + OLS
Subramanyam 2003-2 Java 0 - - ++ OLS
Gyimothy 2005 C++ ++ + ++ 0 ++ ++ LR+ML
Zhou 2006-1 重⼤度⾼ C++ ++ 0 ++ ++ ++ ++ LR+ML
Zhou 2006-2 重⼤度低 C++ ++ 0 ++ -- ++ + ++ LR+ML
++: 強い有意（正）、+: 有意（正）、0: 有意でない、-: 有意（負）、--: 強い有意（負）、空⽩: 未計算または計算⽅法が異なるため未評価
LR: ロジスティック回帰モデル、OLS: 最⼩⼆乗法、LDA: 線形判別法、ML: 機械学習
WMC, RFC, CBOは、クラスのフォールトプローン性に対して、ほぼ⼀貫して統計的有意である
Zhou, Y. and H. Leung (2006). "Empirical Analysis of Object-Oriented Design Metrics for Predicting High and Low Severity Faults." IEEE Trans. Softw. Eng., Vol. 32, No. 10, pp. 771-789.
23. コードの複雑度、結合度、凝集度の⽋如、応答メソッド数
23
1
2
3
5 6
7
8
9
4
R1
R2
R3
R4
WMC ＝ Σ 各メソッドのサイクロマティック複雑度
CC (Cyclomatic Complexity)
• 領域の数
• 辺の数 － ノード数 ＋ 2
CBO ＝ 結合関係にある他クラスの数
Class A
-attrib A
-attrib B
-mthd A
-mthd B
Class Y
-mthd A
-mthd B
Class X
-mthd A
-mthd B
Class Z
-attrib A
-attrib B
-mthd A
-mthd B
LCOM ＝属性に対してクラス内メソッドが
網羅的にアクセスしていない度合い
Class A
-attrib A
-attrib B
-mthd A
-mthd B
LCOM = 1
Class A
-attrib A
-attrib B
-mthd A
-mthd B
LCOM = 0
CBO = 3
CC = 4
RFC ＝ 応答に⽤いるメソッド呼出しの種類の数
Class A
-mthd A
-mthd B
Class Y
-mthd A
-mthd B
呼出元
-mthd A
-mthd B
• メソッドAの RFC = 2
• メソッドBの RFC = 1 → Class Yのmthd Aはメソッド
Aでカウント済、クラス単位で集約するときは数えない
※ 他クラスの属性を直接読み書き
するメソッドは好ましくない
RFC = 3
2015/2/13 Makoto Nonaka、 Toyo University
24. 2015/2/13 Makoto Nonaka、 Toyo University
24参考 http://sonarqube.15.x6.nabble.com/Calculation-of-Response-For-Class-metric-td5000313.html
public class ClassA
{
private ClassB classB = new ClassB();
public void doSomething1(){
System.out.println("doSomething");
}
public void doSomething2(){
System.out.println(classB.toString());
}
}
public class ClassB
{
private ClassA classA = new ClassA();
public void doSomethingBasedOneClassA(){
System.out.println(classA.toString());
}
public String toString(){
return "classB";
}
}
RFCの実際の計測例
クラスAの RFC = 6
• 外部から呼び出されるメソッドも計測する
→ doSomething1, doSomething2
• コンストラクタも計測する
→ ClassA
• 重複するメソッド呼び出しは1つのみ計測する
→ System.out.prinltlnは⼆重カウントしない
25. Twitter4Jでの分析例：クラスファイル単位で測定した結果
25
どこに着⽬しますか？
n = 102
TMLOC
0 100 200
0.90 0.58
0.0 0.4 0.8
0.17
0.92
0.0 0.4 0.8
04001000
0.21
0100200
WMC
0.41 0.18
0.87 0.24
CBO
0.40 0.58
0102030
0.41
0.00.40.8
LCOM
0.24 0.47
RFC
0100200300
0.33
0 400 1000
0.00.40.8
0 10 20 30 0 100 200 300
Modify
参考：
R の psych ライブラリの
pairs.panels関数で作図
pairs.panels(
data,
smooth=FALSE,
density=FALSE,
ellipses=FALSE,
scale=TRUE
)
・規模の⼤きいクラス
・LCOMの分布
修正あり
修正なし
2015/2/13 Makoto Nonaka、 Toyo University
26. Twitter4Jでの分析例：
規模について外れ値を除外し、LCOM > 0 で絞りこんだデータ
26
この散布図⾏列から
何が読み取れますか？
n = 53
TMLOC
20 40 60
0.90 0.63
0.2 0.6 1.0
0.46 0.89
0.0 0.4 0.8
0100200300
0.12
204060
WMC
0.44 0.36 0.86 0.075
CBO
0.50 0.62
01020
0.40
0.20.61.0
LCOM
0.44 0.18
RFC
2060100
0.14
0 100 200 300
0.00.40.8
0 10 20 20 60 100
Modify
・修正有無の⽐率
⇒ 修正率が⾼い
・CBOと修正有無の関係
修正あり
修正なし
2015/2/13 Makoto Nonaka、 Toyo University
27. Twitter4Jでの分析例：LCOM = 0で絞り込んだデータ
27
この散布図⾏列から
何が読み取れますか？
n = 47
TMLOC
0 50 150 250
0.98 0.27
0 50 100 150
0.85
0200400600
0.29
050150250
WMC
0.26
0.82 0.30
CBO
0.28
05101520
0.30
050100150
RFC
0.44
0 200 400 600 0 5 10 15 20 0.0 0.4 0.8
0.00.40.8
Modify
・修正有無の⽐率
⇒ 修正率が低い
正あり
修正なし
2015/2/13 Makoto Nonaka、 Toyo University
29. 参考：Twitter4Jのデータを分類⽊で分析
分類⽊の⽣成・表⽰（Rのコマンド）
library(rpart)
data.ct <- rpart(Modify~., data=data,
method=“class”)
print(data.ct, digit=2)
# 分類⽊をグラフィカルに表⽰
plot(data.ct, branch=0.6, margin=0.05)
text(data.ct, all=T, use.n=T)
実⾏結果
2015/2/13 Makoto Nonaka、 Toyo University
29
node), split, n, loss, yval, (yprob)
* denotes terminal node
1) root 99 42 1 (0.424 0.576)
2) CBO< 5.5 67 27 0 (0.597 0.403)
4) LCOM< 0.1 39 10 0 (0.744 0.256) *
5) LCOM>=0.1 28 11 1 (0.393 0.607)
10) RFC>=26 14 6 0 (0.571 0.429) *
11) RFC< 26 14 3 1 (0.214 0.786) *
3) CBO>=5.5 32 2 1 (0.062 0.938) *
|CBO< 5.5
LCOM< 0.1
RFC>=26.5
1
42/57
0
40/27
0
29/10
1
11/170
8/6
1
3/11
1
2/30
合計件数 修正なし件数 ？（修正なし比率 修正あり比率）
• CBO<5.5 & LCOM < 0.1 → 修正なし29件(74.4%)
• CBO<5.5 & LCOM >= 0.1 & RFC >=26.5 → 8件(57.1%)
• CBO<5.5 & LCOM >-= 0.1 & RFC < 26.5 → 3件(21.4%)
• CBO>=5.5 → 2件( 6.2%)
修正なし件数 / 修正あり件数
結合度、凝集度、応答メソッド数で
修正有無の傾向を説明している
※過学習をしてしまっていないか注意が必要
（データに特化しすぎて汎⽤性が低い状態）
30. “I‘d rather be vaguely right than precisely wrong.”
精密に誤るよりも、漠然と正しくありたい
– John Maynard Keynes
私たちのメトリクス分析は 精密に誤っていないか？（⾃戒の念も込めて）
– 理論モデルの洗練が⽬的になっていないか
– 現場にとって分かりにくい分析結果やモデルになっていないか
– その分析結果やモデルは品質向上に貢献するのか
漠然と正しい 情報が得られているか？
– 意思決定の役に⽴つレベルの精度が得られているか
– 正しい意思決定に役⽴つ、正しい⽅向感の情報を⽣み出しているか
302015/2/13 Makoto Nonaka、 Toyo University
31. 品質データ測定・分析のアクションプラン
• 上位レベルの⽬的を定める
– 顧客満⾜のために、製品・サービスとして重点管理すべき品質特性は何か
例）ISO/IEC 25010:2011 システム／ソフトウェア製品品質モデル
– 事業戦略および製品・サービス戦略の上で重視すべきKPIは何か
• 品質データ測定・分析の直接の⽬的を定める
– 製品・サービスに対する顧客の評価（またはその代替指標）を把握したい
– 開発中のプロジェクトの品質状況を把握したい
– 開発⼯数の⾒積りの妥当性を評価したい など
• ⽬的達成に必要なメトリクスとその可視化・分析⽅法を検討する
– 製品・サービスのリリース後の状況を把握する指標として何を測定するか
– プロセス指標・プロダクト指標として何を測定すればよいか
– どのような統計量／グラフを⽤いれば必要な情報が得られるか
• 可視化・分析によって得られた情報に基づきアクションをとる
– データを通じて把握できた事実に基づき、どのような施策につなげるか
312015/2/13 Makoto Nonaka、 Toyo University
32. ソフトウェアの品質モデル ISO/IEC 25010:2011 (JIS X 25010:2013)
32
システム/ソフトウェア製品品質
機能適合性
機能完全性
機能正確性
機能適切性
移植性
適応性
設置性
置換性
保守性
モジュール性
再利⽤性
解析性
修正性
試験性
性能効率性
時間効率性
資源効率性
容量満⾜性
使⽤性
適切度認識性
習得性
運⽤操作性
ﾕｰｻﾞｴﾗｰ防⽌性
UI快美性
アクセシビリティ
信頼性
成熟性
可⽤性
障害許容性
回復性
互換性
共存性
相互運⽤性
セキュリティ
機密性
インテグリティ
否認防⽌性
責任追跡性
真正性
＜製品品質モデル＞
2015/2/13
• 明⽰／暗黙ニーズを満たして顧客満⾜／顧客歓喜を実現するために、
どのような品質要素／品質特性を重視するのか
• 競争戦略上、どのような品質要素／品質特性を重視するのか
• 戦略的観点も含めて品質要求を定義し、品質要素の達成状況の評価を
プロセスに取り⼊れる
Makoto Nonaka、 Toyo University
34. プロセス改善により失敗コスト⽐率を下げ、総品質コストを抑制する
1. 外部失敗コストの低下
– テストを重視し、テスト状況を把握し、
外部失敗を内部失敗へと振り分ける
2. 内部失敗コストの低下
– レビューを重視し、レビュー状況を把握し、
⽋陥を早期に除去できるようにする
3. ⽋陥除去プロセスの効率向上
– レビューとテストの効率向上に努める
– リスクベースで活動の重点化を図る
– プロセス改善、知識蓄積、教育に投資する
4. 総品質コストの低減・安定化
– リスクベースによるレビューとテストの「間引き」が
機能不全に陥らないように注意
34
• ⼀定の品質コストはつねに必要である
• その効率向上を追求する必要がある
• 安易な品質コストの削減は、取り返しのつかないところまで組織能⼒を衰退させる
品質マネジメント能⼒の成熟度
プロジェクトに占める品質コスト
外部失敗コスト
内部失敗コスト
評価コスト
予防コスト
2015/2/13 Makoto Nonaka、 Toyo University
35. 品質にしっかりと取り組めば、組織は賢く、強く、幸せになれる
• 品質にしっかりと取り組む
– ソフトウェアを通じて顧客に提供する価値を考える
– 価値を提供し続けるために、組織的に必要な活動をデザインする
• 対象とするニーズを定める／新たに掘り起こす
• ニーズを満たす製品・サービスの品質要素を計画する（ねらいの品質）
• 品質要素の実現度合い（できばえの品質）を保証するプロセスを確⽴する
• 品質要素の実現に係る固有技術と、管理や品質保証に係る技術を進化させ、
価値提供のスピードを加速する
• 提供した価値に対する顧客満⾜の度合いを評価する
• 「事実に基づく管理」を主軸にして、プロセスを継続的に改善する
• この過程で得られた知識を、組織的に活⽤する
• 組織が賢く、強く、幸せになる
– 価値提供の結果 ／ ⾃社独⾃の経験 ／ 失敗に学び、組織が賢くなる
– 組織独⾃の知識・技術 ／ 継続的改善能⼒は、競争優位の源泉である
– 賢く強い組織は、幸せになる
352015/2/13 Makoto Nonaka、 Toyo University
