ソフトウェア欠陥メトリクスの意味と活用方法を考える

東洋大学経営学部 野中 誠
組込みシステム技術に関するサマーワークショップSWEST15
2013年8月23日

自 己 紹 介• 所属– 東洋大学 経営学部 経営学科准教授野 中誠• 背景– 工業経営／経営システム工学，ソフトウェア工学，品質マネジメント• 主な学外活動– 日本科学技術連盟 SQiPソフトウェア品質委員会 委員長– 日本SPIコンソーシアム 外部理事
– （旧）IPA/SEC 定量的管理基盤WG 主査，定量データ分析WG委員（『データ白書2012-2013』）– 組込みシステム技術協会実装品質強化WG メンバー
– 情報サービス産業協会SPES企画WGエキスパート– 国立情報学研究所 特任准教授 （トップエスイー講座，メトリクス講義担当）• 主な著書– 野中誠・小池利和・小室睦著 『データ指向のソフトウェア品質マネジメント』 日科技連出版社 (2012)– 野中誠・鷲崎弘宜訳 『演習で学ぶ ソフトウェアメトリクスの基礎』 日経BP社 (2009)• 研究教育– ソフトウェア品質マネジメント（メトリクス）– 情報システムと経営の関わり• 大学での担当授業– 情報管理論，品質マネジメントなど
2013/8/23

2

データ指向のソフトウェア品質マネジメント（デート本）
メトリクス分析による「事実にもとづく管理」の実践
2012年11月8日号

・品質メトリクス分析の実践的入門書

p.125

・11の分析事例

書評

ソフトウエア品質メトリクスで、日本における気鋭の研究者である野中誠氏による解説書。
ソフトウエアの品質データ（メトリクス）は、その収集自体が目的化してはならないが、その分析は開発現場ではなくてはならないものである。
本書はその収集・分析方法、用いるべきモデルなどを、統計学の初歩的解説とともに述べている良書である。

2012年11月号
p.110

書評

ソフトウエアの品質を高めるには、開発の過程で問題をいち早く把握し、適切な対策を打つことが不可欠である。それには、問題を可視化することが大事だ。
本書は、事例を基に、品質データの測定項目や分析手法を解説している。ソフトウエア品質に関わる多様なデータを測定し、分析を繰り返すことは容易ではないが、分析手順を詳しく説明している。
事例を読者自身の開発に当てはめて実践してみれば、必要な知識やスキルを身に付けやすいだろう。
2013/8/23

・データと分析手順の解説をダウロードできる（同じ分析手順を手元で行える）
主要目次
第１章 品質データ分析の基本
第２章 品質状況の把握
第３章 影響要因の把握
第４章 静的予測モデルの構築
第５章 動的予測モデルの構築
第６章 測定方法
付録
野中 誠（東洋大学）
小池 利和（ヤマハ）
小室 睦（元 日立ソリューションズ、現 富士フイルムソフトウエア）
2012年9月19日発行
定価 3,780円（税込）
ISBN978-4-8171-9447-3

3

品質部門の支援業務に対する、開発部門の評価（開発対象別）

エンタープライズ系（人数 =< 300)

組込み系（人数 =< 300)

・組込み系で、「プロジェクト実績データの収集と定量的分析」の有益度評価が低い
・品質部門が集めた実績データを、開発部門にうまくフィードバックできていないのが原因？
野中・脇谷「SQiPソフトウェア品質管理・品質保証実態調査」SQiPシンポジウム2012講演資料
2013/8/23

4市場流出欠陥のベンチマークデータ

日・米・欧・印のパフォーマンス比較 （Cusumano et. al., 2003）
項目

インド

日本

米国

欧州他

合計 or 平均

調査対象のプロジェクト数（件）24273122104（合計）

新規コード行数（KLOC, 中央値）

209469270

436374

出荷後の欠陥密度（中央値）

0.263

0.020

0.400

0.225

0.150

皆さんの組織での市場流出欠陥は、このデータに比べてどうですか？
そもそも「出荷後の欠陥密度」は、信頼できるメトリクスですか？

2013/8/23

Cusumano, M., et. al., “Software Development Worldwide: The State of the Practice,” IEEE
Software, Nov/Dec 2003, pp.28-34.

5なぜ定量的管理が必要なのか？ Informed decision指向•「必要な情報」を得た上での意思決定のためにソフトウェア／プロジェクトといった抽象的・複雑な対象について、そのマネジメントにおける様々な意思決定に役立つ情報を、一貫した方法で獲得し、論理的な判断を下し、リスクを把握し、そして、前へ前へと進んでいきたい•「必要な情報」の獲得・伝達手段として– 主観的情報も意思決定の際に用いている（説明の論理性を判断）– 主観的情報は、情報収集の一貫性、効率性、説明性に問題がある– メトリクスを定めることで、必要な情報を、効果的に、一貫して収集できる– 組織やメンバーに説明可能な根拠情報として利用できる

定量的管理に取り組まない合理的理由は、限定的である
2013/8/23

6

メトリクスの限界を知り、informed decision に役立てる

測定したい概念

概念の定義

操作上の定義実世界での測定2013/8/23

概念の定義

操作上の定義実世界での測定・実世界で測定できることは、測定したい概念の一部に過ぎない・複数のメトリクスで、測定したい概念を多面的に捉える
7

目的に合った分析手法と適切なメトリクスを用いる
メトリクス

派生メトリクス

分析手法

直接的な目的・品質把握・評価

分析手法

メトリクス

・影響要因の特定・品質計画・予測・数値化・可視化手法
メトリクス

・統計解析手法
派生メトリクス※ 派生メトリクスとは、複数のメトリクスを組み合わせたものをいう。
例）欠陥検出密度（欠陥数／規模）

メトリクス
・測定の信頼性
・測定の妥当性・「品質の把握・評価」には、一見、単純と思えるような数値化や、可視化の工夫で十分なことが多い
・「影響要因の特定」や「予測モデルの構築」には、統計解析手法が適していることが多い
・インプットとなるメトリクスの信頼性と妥当性に大きな問題があると、どのような分析手法を用いてもダメな結果しか得られない

2013/8/23

8上流工程までの累積欠陥除去率の目標値に関して(1)
例：「上流工程までの累積欠陥除去率 75% を目標としましょう」

開発プロセス（V字モデル）

上流工程までの欠陥除去数：
テスト工程での欠陥除去数：
欠陥除去数の総数：

3件
5件
8件

完了したプロジェクトについて、目標の達成状況を把握したい「欠陥除去数の総数」を分母としたときの、上流工程での累積欠陥除去率は 3/8 = 37.5% である・ 正しい「上流工程までの累積欠陥除去率」は、明らかに 3/4 = 75%である
・ 上流工程までの累積欠陥除去率を事後に正しく評価するには、下流工程で除去した欠陥の混入工程を把握しておく必要がある

2013/8/23

9欠陥データマトリクスと欠陥除去率
作込み

要求
定義

機能設計

機能設計
ｲﾝｽﾍﾟｸｼｮﾝ

49681

詳細設計
ｲﾝｽﾍﾟｸｼｮﾝ

642681

コード
ｲﾝｽﾍﾟｸｼｮﾝ

1228

114

941

単体テスト

2143

43

223

2

結合テスト

204161261−

4

ｼｽﾃﾑテスト

68

24

72−−

1

運用

81616

40−−−

181

合計

122859

939

1537

2

41

13465

除去

詳細設計

ｺｰﾃﾞｨ
ﾝｸﾞ

単体
テスト

結合テスト

ｼｽﾃﾑ
テスト

運用

例：詳細設計ｲﾝｽﾍﾟｸｼｮﾝの DRE
DRE = 729 / (122+859+939 – 730)
プロセス全体のDRE

合計

DRE

730

74.4%

72961.3%

1095

54.8%

332

36.7%

387

67.1%

111

58.1%

97.7%

欠陥除去能力の低い工程を特定し、重点改善対象の候補とする
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).

2013/8/23

10上流工程までの累積欠陥除去率の目標値に関して(2)
例：「上流工程までの累積欠陥除去率 75% を目標としましょう」

開発プロセス（V字モデル）

上流工程での欠陥混入数： 3件 （認識できている範囲で）
上流工程での欠陥除去数： 3件
いま、上流から下流工程への移行判定をしようとしている
上流工程での累積欠陥除去率は100% … 目標達成できた？

・ 上流工程が終わった時点では、上流工程で混入した欠陥のうち、上流工程で除去できたものしか把握できない・ 「目標値 75%」を達成できたかどうかは、テストを終えないと （正確には、出荷後の一定期間が経過しないと） 分からない
・ 上流工程が終わった時点で目標値を達成できたと判定するためには、欠陥混入数の予測値を得ておかなければならない

2013/8/23

11

欠陥数の予測例：重回帰分析の適用
分析対象のデータ（N = 29）
区分記号

メトリクス

定量データ

Defects

欠陥検出数

KLOC

ソースコード行数

定性データ（5段階評価）D1

開発メンバーの経験

P5

ステークホルダーの関与度

P6

顧客とのコミュニケーション

欠陥除去数の実績値

欠陥除去数の実績値

相関係数
r = 0.883

2013/8/23

ただし、「精密に誤るよりも…」には留意

重回帰分析：
Defects = f (KLOC, D1, P5, P6)規模と欠陥数の関係

KLOC

適切な統計手法を用いることで、欠陥数を高い精度で予測できるモデルを構築できる

重相関係数
R = 0.957
欠陥除去数の予測値（データの出典）Fenton, N., Neil, M., Marsh, W., Hearty, P. and Radlinski, L.: On the effectiveness of early life cycle defectprediction with Bayes Nets, Empirical Software Engineering, pp. 499‒537, Springer, June 2008.
http://www.springerlink.com/content/kg06211161305k1t/ よりダウンロード可能
野中（2011）「計数データとしてのソフトウェア欠陥の予測」『ウィンターワークショップ2011・イン・修善寺 論文集』pp.111112, 情報処理学会

12上流工程までの累積欠陥除去率の目標値に関して(3)
例：「上流工程までの累積欠陥除去率 75% を目標としましょう」
上流工程での欠陥除去数： 1件予測された欠陥混入数：
4件
累積欠陥除去率の予測値： 1/4 = 25%
いま、上流から下流工程への移行判定をしようとしている
欠陥の粒度は、開発・技術部門に委ねているとする「少なくとも、欠陥をあと2件見つけないと次に進めません」と、開発・技術部門に指示した出荷を急ぐ開発・技術部門が取り得る対応・ 除去済み欠陥を3件にスプリットする （！）
・ 見かけ上の累積欠陥除去率は、3/4 = 75% （！！）
欠陥の粒度のガイドラインを定めておく必要がある

2013/8/23

13

IEEE標準は、欠陥の数え方に関するガイドラインとなるか？
用語定義（筆者訳）

出典のIEEE標準

欠陥 (defect)障害(fault)または故障(failure)のいずれかを言及できる一般的用語。

982.1-2005

障害 (fault)(1) ハードウェアデバイスまたはコンポーネントの欠陥(defect)。
(2) コンピュータープログラム内の，不正確なステップ，プロセス，またはデータ定義。一般には，エラー(error)やバグ(bug)をこの意味に用いる。

610.12-1990(R2002)故障 (failure)

システムまたはコンポーネントが，指定された性能要求の範囲内で要求された機能を果たせないこと。

610.12-1990(R2002)

エラー，誤り (error)(1) 正しい結果と，観測された結果の相違。狭義のerror。
(2) 不正確なステップ，プロセス，またはデータ定義。狭義のfault。
(3) 不正確な結果。狭義のfailure。
(4) 不正確な結果を生み出した人間の行為。狭義のmistake。

610.12-1990(R2002)

不正(anomaly)

要求仕様，設計文書，ユーザ文書，標準，または誰かの認識もしくは体験など，これらに基づく期待から乖離した状態。

1044-1993(R2002)
1028-2008

文書において，またはソフトウェアもしくはシステムの運用において観測された，期待から乖離したものすべて。ただし，期待は，検証済みのソフトウェア製品，リファレンス文書，または指定された振る舞いを記述したその他の情報源に基づく。

829-2008

欠陥1件の粒度について、IEEE標準はとくに言及していない
2013/8/23

14Q1：何件の欠陥と数えるか？
設計レビューで、設計仕様書の誤記を発見した。
当該個所1個所を修正したのち、これに伴って変更を要する2個所（設計仕様書内）を修正した。

設計仕様書……………………
……×……………
……………………
……………………
……………………
……………………
……………………
…………………

2013/8/23

この場合、何件の欠陥としてカウントしますか？
1? 2? 3? それ以上??

15

Q2：何件の欠陥と数えるか？
結合テストで、プログラムの振る舞いの問題を発見し、原因が設計仕様にあることが分かった。
設計仕様書の当該個所1個所を修正したのち、これに伴って変更を要するソースコード2個所を修正した。

ソースコードA
設計仕様書
……………
……×……
……………

………
……………
………
……… ……
………
………

この場合、何件の欠陥としてカウントしますか？

ソースコードB
………
………
…………
……… ……
……
…………
……

1? 2? 3? それ以上??
2013/8/23

16

Q3：何件の欠陥と数えるか？
（続き）その後のシステムテストで、(2)と同じ対応をし忘れたソースコード2個所を発見し、これを修正した。
(2)での対応の範囲
ソースコードA
設計仕様書
……………
……×……
……………

………
……………
………
…… ……
………
………

ソースコードB
………
………
…………
…… … … …
……
…………
……

ソースコードC
………
………
…………
…… ……
……
…………
……

2013/8/23

ソースコードD
………
………
…………
…… … … …
……
…………
……

この場合、全体として何件の欠陥としてカウントしますか？

1? 2? 3? 4? 5? それ以上??
17

参考：SQiPシンポジウム2010メトリクスSIGでのアンケート結果
Q1

Q3

Q2

・数え方は組織によって様々なので、このグラフのように結果がばらつくのは仕方ない
・しかし、あなたの組織内でこれだけばらついていたら、欠陥のデータは意味をなすだろうか？

2013/8/23

野中（2010）「ソフトウェア品質の定量的管理における曖昧さ−ソフトウェア欠陥測定の原則−」『経営論集』pp.99-109，東洋大学経営学部

18

ソフトウェア欠陥1件の数え方の例※ 開発プロセス全体で欠陥の粒度に一貫性を持たせ、欠陥除去工程のパフォーマンスを正しく評価したい場合

原則 ： プロダクトの原因部分で集約して１件と数える


原因部分が1個所のみの場合–



要求仕様書の記述に誤りが1個所あり、要求レビューでこれを除去した原因部分の修正が、ほかの個所に影響する場合
–

→ 1件

→ 1件

仕様の問題個所を修正した後に、関連して修正しなければならない仕様書の記述2個所を修正した … Ｑ１、Ｑ２のパターン

原因が成果物ではなくプロセスにある場合 → 修正個所を別々にカウント–

Ｑ３の例は、デバッグプロセスにおける修正漏れという問題のために、2個の欠陥が新たに入り込んだと解釈する–

Ｑ２で識別した１件と、Ｑ３で新たに識別した２件を合計する

2013/8/23→ ３件

野中（2010）「ソフトウェア品質の定量的管理における曖昧さ−ソフトウェア欠陥測定の原則−」『経営論集』pp.99-109，東洋大学経営学部

19

欠陥の分類：欠陥の数を扱う前に考えなければならないこと
機能性欠陥

発展性欠陥

(functional defects)(evolvability defects)
機能性の欠如、大幅な追加・修正が必要

サポート

ライブラリの欠陥

タイミング

マルチスレッド環境で生じる問題

チェック

妥当性確認ミス、不正な値の検出ミス

リソース

データ、変数、リソース初期化、解放などの誤り

コードインスペクション指摘の約70%は、発展性欠陥を検出ロジック比較演算子、制御フロー、計算などの誤り(Mäntylä, 2009)

インタフェース

構造

コード構造

大規模欠陥

視覚的表現
ドキュメンテーション

コードの読みやすさ
コードの説明ライブラリ、デバイス、DB、OS等とのインタフェース不整合• 欠陥の定量的管理の前提として、欠陥の分類を考えておく必要がある• 欠陥除去のフロントローディングを議論するときは、機能性欠陥に着目する• 将来の機能性欠陥につながる発展性欠陥は、早い段階で芽を摘んでおく• 欠陥の分類に着目して、プロジェクトの状況を把握する

2013/8/23

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.

20

テスト工程の管理

1.0

1.0

0.8

0.8

未消化テストケース数
UCL (Upper Control Limit)
LCL (Lower Control Limit)
累積欠陥摘出数
UCL (Upper Control Limit)
LCL (Lower Control Limit)

0.6

0.4

0.2

0.60.4

未消化テ ストケース数の比率

累積欠陥摘出数の比率

・次のテスト管理図から、どのような状況が読み取れるか？
・その状況を生み出した原因として何が考えられるか？
・その原因特定のために、どのようなドリルダウンをすればよいか？

0.2

0.00123456789

複数メトリクスの組み合わせで、0.010 問題となっている状況を検知する
11 12 13 14 15

テ スト経過週数（週）2013/8/23

21

テストの進捗：テスト管理図のパターン
計画通りに進行

テストケース消化停滞・欠陥摘出不足
・とくに問題なし

テストケース消化停滞・欠陥多発・前工程での欠陥摘出は不足していないか？

2013/8/23

・テスト担当者が不足していないか？
・テスト環境は適切に整備されているか？

テストケース急速消化・欠陥摘出不足
・テストケースの質は適切か？
・テストケースの消化順序は適切か？

22コンポーネント別のテスト進捗（％）

コンポーネント別のテスト進捗

第6週での状況・ コンポーネントCから、多くの欠陥がテスト工程で見つかっている・ コンポーネントCのレビューが適切ではなかったと考えられる
参考：L. M. Laird and M. C. Brennan, Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006.
（野中・鷲崎訳：演習で学ぶソフトウェアメトリクスの基礎、日経BP社（2009））

2013/8/2323

欠陥バックログ
140
新規発見欠陥数120

修正済み欠陥数100

修正未了欠陥数

欠 80
陥数 60
40
20001234567

テ ス ト経過週数

891011

12

第6週での状況

テストで発見した欠陥の修正に手間取り、テスト進捗を停滞させる原因になっていると考えられる（テストとデバッグが同一チームの場合）
参考：L. M. Laird and M. C. Brennan, Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006.
（野中・鷲崎訳：演習で学ぶソフトウェアメトリクスの基礎、日経BP社（2009））

2013/8/2324

ゾーン分析：レビューメトリクスの組合せによる判断•

レビュー指摘密度：規模当たりのレビュー指摘件数（件／規模）•

レビュー工数密度：規模当たりのレビュー工数（工数／規模）

レビュー指摘密度①②③

問題がないと思われるのは？ なぜ？
品質が悪い可能性があるのは？ なぜ？

④⑤⑥

品質が良い可能性があるのは？ なぜ？
品質を判定できないのは？ なぜ？

⑦⑧⑨

問題があるなら、どのような対策が必要？

レビュー工数密度
2013/8/23

25

レビュー
指摘密度

ゾーン分析の判定例

① ② ③
④ ⑤ ⑥
⑦ ⑧ ⑨

レビュー工数密度『続・定量的品質予測のススメ』

SQiP2012『SQiP品質保証部長の会 からの情報発信』

評価⑤

一応、品質は良好

評価⑤
問題は発生していない⑥

レビューの進め方、体制の点検が必要⑥⑧

レビューの進め方、体制、漏れの点検が必要⑧⑨

レビュー効率が悪いため、レビューの進め方、体制、漏れの点検が必要⑨②

設計不良のため、前工程設計不良、検討不足の点検が必要②③

設計不良のため、前工程設計不良、検討不足の点検が必要③

品質が悪い可能性がある①

レビュー不足のため、レビューの進め方、体制、 漏れの点検が必要①→ 成果物を見直して再レビュー④

レビュー不足のため、品質不良、設計・レビュー点検が必要⑦

レビュー不足のため、追加レビューで指摘増となる可能性がある
2013/8/23

品質が良い可能性がある④⑦

品質を判断できる状況にない→ 追加レビューが必要か否かを判断

26

プロダクトメトリクスにも目を向けよう•

スタッフ部門が着目するのは、多くの場合、プロセスメトリクス– 例） レビュー工数、レビュー指摘欠陥数、テスト密度、…
– プロセスに着目すること自体は悪くなく、むしろ推奨すべき→ プロセスを制御してプロダクト品質を制御するのは品質管理の基本– しかし、プロセスだけを見て、プロダクトを見ないのはいけない→ レビュー工数が足りない、レビュー指摘数が足りない、…が足りないと言われても、「どの部分に着目して対処すべきか」の解にならない→ プロセスメトリクスは、分解能に限界がある•

ソフトウェア開発技術の道理を踏まえた改善を推進しよう– 凝集度、結合度、複雑度などは、70年代、80年代から言われ続けている
ソフトウェアエンジニアリングの基本– これらの特性を測定するメトリクスは90年代までに数多く示されていて、ツール化されているものも多い– 保守性を疎かにしていると、後でたいへんな「ツケ」となって回ってくる

2013/8/23

27

fault-proneモジュール予測のイメージ

ソフトウェア開発プロセス（V字モデル）のコーディング／単体テストが終わった時点で、欠陥がありそうな度合いによってモジュールを色分けして、ソースコード等から測定可能なプロダクトメトリクスやプロセスメトリクスを用いて、優先的／重点的にレビューしたり機能テスト／システムテストで欠陥が見つかりそうなモジュールを、 テストしたりすることで、レビューやテストの効率／効果を高めたい
2013/8/23

28例）Twitter４Jのメトリクス分析 （クラスファイル単位で測定）
メトリクス

記号

説明

総メソッド行数

TMLOC

Total Method Lines of Code
各メソッドのソースコード行数の合計

重み付きメソッド数

WMC

Weighted Methods per Class各メソッドのサイクロマチック複雑度の合計

結合度

CBO

Coupling Between Object Classes
結合関係にある他クラスの数

凝集度の欠如LCOMLack of Cohesion in Methods
属性に対してクラス内メソッドが網羅的にアクセスしていない度合い

応答処理の多さ

RFC

Response For a Class応答に用いるメソッド呼出しの種類の数

修正の有無

Modifyリリース後に欠陥修正が生じたか否か（0: なし 1: あり）

注1） これらの無料ツールを用いて測定- Eclipse Metrics plug-in 1.3.6, http://sourceforge.net/projects/metrics/- Chidamber & Kemerer Java Metrics, http://www.spinellis.gr/sw/ckjm/

2013/8/23

注2） LCOMにはさまざまなバリエーションがあるが、ここではHenderson-Sellersの定義を用いた
Henderson-Sellers, B., Object-Oriented Metrics, Prentice-Hall, 1996.

29測定値が得られたすべてのクラスファイルの散布図行列
100 200

0.00.40.8

0.00.4

0.8

0.58

0.17

0.41

0.18

0.92

0.210.87

0.24

0.58

0.41

0.24

0.47

00.90

1000

TMLOC

n = 1024000

詳細な分析の前に、まず何を考えますか？

CBO
0.40

0 10 20 30

0100 200

WMC

R の psych ライブラリのpairs.panels関数で作図

RFC

00.33

100 200 300

0.00.40.8

LCOM

0.00.40.8

Modify

0 400

1000

0 10 20 30

2013/8/23

0100 200 300

pairs.panels(data,smooth=FALSE,
density=FALSE,
ellipses=FALSE,
scale=TRUE)

30

外れ値を除外し、「ある条件」で絞りこんだデータ
0.2

0.6

1.0

0.0

0.4

0.8

TMLOC
0.63

0.46

0.89

0.44

0.36

0.86

0.50

0.62

0.40

0.44

0.18

0.12

00.90

100 200 300

20 40 60n = 53

この散布図行列から何が読み取れますか？

0 .0 75

20CBO

1.001020 40 60

WMC

RFC

200.14

60

100

0.2

0.6

LCOM

0.0

0.4

0.8

Modify0100 200 300

02013/8/23

1020

2060

10031

外れ値を除外し、「ある条件」で絞りこまれなかったデータ
150

250

050 100 150
200 400 600

0 50

TMLOC
0.27

0.85

0.29

0.26

0.82

0.30

0.28

0.30

25000.98

n = 47

この散布図行列から何が読み取れますか？

5 10 15 200 50150

WMC

50 100 1500CBO

RFC0.00.4

Modify0.800.440

200 400 60002013/8/23

510 15 200.00.40.832

分析によって得られた知見 （分析対象のソフトウェアについて）•

TMLOCが380行以上という大きいクラスは3個あり，これらはすべてリリース後に欠陥修正があった（欠陥修正率3/3 = 1.0）。

•

LCOM = 0のクラスは46個あり，このうちリリース後に欠陥修正があったのは15個であった（欠陥修正率15/46 = 0.33）。

•

一方，LCOM > 0のクラスは53個あり，このうちリリース後に欠陥修正があったのは42個であった（欠陥修正率42/53 = 0.79）。

•

LCOM > 0のクラス53個について，CBOの値が中央値の5以下では欠陥修正率が17/28 = 0.61であったのに対して，中央値より大きい場合では欠陥修正率が25/25 = 1.0であった。

•

LCOM = 0 のクラス46個について，RFCの値が中央値の18.5以下では欠陥修正率が6/23 = 0.26であったのに対して，中央値より大きい場合では欠陥修正率が9/23 = 0.39であった。

レビューやテストの重点化を進めるにあたって，このようなデータから得られた客観性の高い知見はプロセス改善の推進力になる
2013/8/23

33

品質データ分析は改善の推進力•

品質マネジメントの基本原則は、ソフトウェアにも適合する– 手法をそのまま導入するのではなく「基本原則」を当てはめることが大事•

ソフトウェア開発において、事実にもとづく管理は容易でない– データの測定・収集プロセスが、人に大きく依存している– 目的と整合性のあるメトリクス分析をし続けることが難しい•

品質データ分析は、品質に効く （長期的に）– 品質向上（または悪化）のメカニズムを解明する– データが示す客観的事実の力を活用し、改善の推進力とする– データを手がかりに原因を特定し、アクションをとり、効果を確認する
そして、– 再発防止のためにプロセスを改善し、失敗プロジェクトを撲滅する– 顧客価値の向上につながる活動に注力し、顧客の満足度を高める

2013/8/23

34

“I‘d rather be vaguely right than precisely wrong.”
精密に誤るよりも、漠然と正しくありたい– John Maynard Keynes

私たちのメトリクス利用は 「精密に誤って」 いないか？（自戒の念も込めて）– 理論モデルの洗練や予測精度の向上が目的になっていないか「漠然と正しい」 情報が得られているか？
– 意思決定に十分役立つ精度の情報が得られているか– 正しい意思決定に役立つ、正しい方向感の情報を生み出しているか

2013/8/23

35