Successfully reported this slideshow.
Your SlideShare is downloading. ×

「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
品質基礎知識
品質基礎知識
Loading in …3
×

Check these out next

1 of 35 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to 「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04 (20)

Advertisement

Recently uploaded (20)

「事実にもとづく管理」によるソフトウェア品質の改善 ー ヒンシツ大学 Evening Talk #04

  1. 1. 「事実にもとづく管理」による ソフトウェア品質の改善 東洋⼤学経営学部 野中 誠 2015年2⽉13⽇ ヒンシツ⼤学 Evening Talk #04
  2. 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
  3. 3. 「事実に基づく管理」は改善の推進⼒ ソフトウェアにおける「事実に基づく管理」は難しい – 測定プロセスが⼈に依存していて、データの量と質に問題がある – 多くのメトリクスは⼆⾯性があり、単⼀で良し悪しを判断できない – コード⾏数に対する批判など、古典的な問題が解決されていない これらの課題を踏まえた上で「事実に基づく管理」を推進する ことは、継続的な品質改善に向けた有効な施策である – データが⽰す客観的事実の⼒を活⽤し、実態を把握する – データを⼿がかりに原因を特定し、対策を講じ、効果を確認する そして、 – 再発防⽌・未然防⽌のプロセス改善を⾏い、失敗コスト⽐率を下げる – 顧客満⾜度の向上につながる活動に注⼒し、「品質」の向上を図る 32015/2/13 Makoto Nonaka、 Toyo University
  4. 4. 「データが⽰す客観的事実の⼒」の例: 上流⽋陥摘出と下流⽋陥検出は正・負の相関のどちらか? 4 上流(レビュー)での⽋陥摘出密度(⽋陥/規模) 下流(テスト)での⽋陥検出密度(⽋陥/規模) 2015/2/13 負の相関? • 期待している因果関係と現実の 状況が⼀致しているとは限らない • ⾃組織の状況をデータで把握し、 その結果を組織内で共有する ことが改善への第⼀歩 正の相関? Makoto Nonaka、 Toyo University
  5. 5. 品質部⾨の⽀援業務に対する開発部⾨の評価 5 ・組込み系で、「プロジェクト実績データの収集と定量的分析」の有益度評価が低い ・品質部⾨が集めたデータを、開発部⾨にうまくフィードバックできていないのが原因? エンタープライズ系(人数 =< 300) 組込み系(人数 =< 300) 野中・脇⾕「SQiPソフトウェア品質管理・品質保証実態調査」SQiPシンポジウム2012講演資料 2015/2/13 Makoto Nonaka、 Toyo University
  6. 6. 0 1 2 3 4 5 対開発 対顧客 対経営 品質管 理 信頼性 生産性 0 1 2 3 4 5 対開発 対顧客 対経営 品質管 理 信頼性 生産性 ソフトウェア開発組織における品質管理能⼒の⾃⼰評価 上位3組織 vs. 下位3組織 6 上位 3組織 下位 3組織 ⾃⼰評価の⾼い組織と低い組織では、⾯積に⼤きな開きがある http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf 2015/2/13 信頼性信頼性 ⽣産性⽣産性 品質管理品質管理 開発組織 への貢献 開発組織 への貢献 顧客へ の貢献 顧客へ の貢献 経営へ の貢献 経営へ の貢献 (N=42) Makoto Nonaka、 Toyo University
  7. 7. 2% 22% 31% 38% 7% 生産性は高く、経営課題として挙げら れることはほとんどない 生産性が高いとはいえないが、経営課 題に挙げられるほど低い水準ではない 生産性が高いとはいえないが、少なく とも今の水準を維持することが経営課 題の一つである 生産性が低く、その向上が経営上の重 要課題の一つである 生産性が低く、その向上が経営上の最 優先課題である ソフトウェア開発組織における品質管理能⼒の⾃⼰評価 2015/2/13 Makoto Nonaka、 Toyo University 7 組織の品質管理レベル(N=41) 信頼性レベル (N=42) ⽣産性レベル(N=42) 10% 29% 24% 37% 再発防止に加え、未然防止 策が有効に機能している 是正措置に加え、再発防止 策が有効に機能している 発生不具合に対する是正措 置が有効に機能している 発生不具合に対する是正措 置が不十分である 5% 21% 48% 24% 2% リリース後不具合はほとんど発生しておらず、経 営課題として挙げらることはほとんどない リリース後不具合は発生しているが、経営課題 に挙げられるほどの水準ではない リリース後不具合は発生しているが、少なくとも 今の水準を維持することが経営課題の一つであ る リリース後不具合が多く、その低減が経営上の 重要課題の一つである リリース後不具合が多く、その低減が経営上の 最優先課題である http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf ⾃⼰評価結果は 組織によって様々
  8. 8. 16% 62% 12% 5% 5% 7% 48% 21% 17% 7% 7% 52% 29% 10% 2% 大いに貢献している まあまあ貢献している 貢献しているかどうか何とも いえない あまり貢献できていない まったく貢献できていない ソフトウェア品質部⾨の活動に対する⾃⼰評価 8 開発部⾨に対して (N=42) 顧客/エンドユーザー の満⾜に対して(N=42) 経営に対して(N=42) ⾃⼰評価結果は 組織によって様々 http://www.juse.jp/sqip/symposium/2013/program/files/happyou_shiryou_E2-1.pdf 2015/2/13 Makoto Nonaka、 Toyo University
  9. 9. ソフトウェア開発組織における品質管理能⼒の⾃⼰評価 上位10組織 vs 下位9組織 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. リリース後の⽋陥状況:⽋陥密度のベンチマークデータ 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. 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. 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. テスト進捗状況の把握例 テスト進捗管理図 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
  14. 14. テスト進捗管理図からのドリルダウン例 コンポーネント別テスト進捗状況のモニタリング 14 ・ コンポーネントCから、多くの不具合が検出されている ・ コンポーネントCの詳細設計レビューやコードレビューが⼗分ではなかった 可能性がある ⇒ それぞれのレビュー記録を確認 コンポーネント別のテスト進捗(%) 参考:L. M. Laird and M. C. Brennan, Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006. (野中・鷲崎訳:演習で学ぶソフトウェアメトリクスの基礎、⽇経BP社(2009)) 前スライドの 6週⽬時点 2015/2/13 Makoto Nonaka、 Toyo University
  15. 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
  16. 16. 何を⽋陥として捉えるのか? 16 ⽋陥(defect)(IEEE 982.1:2005の定義) 障害 (fault) 故障 (failure) 誤り (error(4), mistake) 把握すべき 『⽋陥』の範囲 実⾏ される 混⼊ される ・ 故障の原因である 障害(fault)と、 ・ 誤りの誘発要因である 標準との乖離(anomaly) に着⽬ 標準との乖離 (anomaly) 誘発 される • 技術要因 • マネジメント要因 • 組織要因 2015/2/13 Makoto Nonaka、 Toyo University
  17. 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
  18. 18. ⽋陥の数をカウントするにあたり、その⽅法が標準化されているとよい 例:システムテストにおいて、結合テスト時に発⾒した設計仕様ミスの 修正対応をし忘れたソースコード2個所を発⾒し、これを修正した。 2015/2/13 18 この場合、全体として何件の ⽋陥としてカウントしますか? 設計仕様書 … … … … … … … × … … … … … … … ソースコードA … … … … … … … … … … … … … … … … … … … ソースコードB … … … … … … … … … … … … … … … … … … … … ソースコードC … … … … … … … … … … … … … … … … … … … … … … ソースコードD … … … … … … … … … … … … … … … … … … … … … … 結合テストでの修正対応の範囲 Makoto Nonaka、 Toyo University 詳しくは 「ソフトウェアジャパン2014 ソフトウェア品質データ分析を通じた組織的 改善の推進」などをご覧ください。 http://www.youtube.com/ watch?v=IU7cqPHUuEY 考え⽅の⼀例 ・プロセス上の問題は2件 ・構成管理の単位に着⽬した プロダクト上の問題は3件 → プロダクトの原因部分に 集約して⽋陥を数える
  19. 19. レビューの終了条件を明確化する ゾーン分析 〜 レビューメトリクスの組合せによる判断 • レビュー指摘密度:規模当たりのレビュー指摘件数(件/規模) • レビュー⼯数密度:規模当たりのレビュー⼯数(⼯数/規模) 2015/2/13 Makoto Nonaka、 Toyo University 19 レ ビ ュ ー 指 摘 密 度 レビュー⼯数密度 ① ② ③ 問題 あり? ? 問題なし ⑧ ⑨ SQiP2012『SQiP品質保証部⻑の会 からの情報発信』 品質良好? 問題あり? 問題なし 品質良好? 問題あり? 判断不能 上⽅管理限界 下⽅管理限界 上⽅管理限界 下⽅管理限界
  20. 20. 「この⼯程の⽋陥除去能⼒を⾼めましょう」 とだけ⾔って/⾔われて、正しく対処できるだろうか? 20 IPA/SEC「重要インフラ情報システム信頼性研究会」報告書(2009)に⾒る、 再発防⽌のための指⽰ ・重要インフラ情報システムの障害事例の収集(約100事例) ・原因の分析 (ソフトウェア⽋陥 / 運⽤ミス / … ) ・問題構造の分析 (障害事例の当事者ではないが、専⾨家が時間をかけて議論) ・再発防⽌のポイントを分類・整理 例:「複数の経験者によるレビューを徹底し、仕様、プログラムなどを 充分レビューする」 http://sec.ipa.go.jp/reports/20090409.html 重点評価/改善すべき箇所を特定できるソフトウェア品質技術が必要 現場では、「徹底」「充分」とだけ⾔われても困る 2015/2/13 Makoto Nonaka、 Toyo University
  21. 21. ⽋陥のありそうなモジュールを特定する: fault-proneモジュール予測 21 ソフトウェア開発プロセス (V字モデル)のコーディング/ 単体テストが終わった時点で、 機能テスト/システムテストで ⽋陥が⾒つかりそうなモジュールを、 ソースコード等から測定可能な プロダクトメトリクスや プロセスメトリクスを⽤いて、 ⽋陥がありそうな度合いによって モジュールを⾊分けして、 優先的/重点的にレビューしたり テストしたりすることで、 レビューやテストの効率/効果を ⾼めたい 2015/2/13 Makoto Nonaka、 Toyo University
  22. 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. コードの複雑度、結合度、凝集度の⽋如、応答メソッド数 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. 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. 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. 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. 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
  28. 28. Twitter4Jのコードメトリクスと、⽋陥発⽣モジュールの対応分析に よって得られた知⾒ • コード⾏数が380⾏以上という⼤きいクラスは3個あり、これらはすべて リリース後に⽋陥修正があった(⽋陥修正率3/3 = 1.0)。 • 凝集度の⾼いクラスは46個あり、このうちリリース後に⽋陥 修正があったのは15個であった(⽋陥修正率15/46 = 0.33)。 • ⼀⽅、凝集度の低いクラスは53個あり、このうちリリース後に⽋陥 修正があったのは42個であった(⽋陥修正率42/53 = 0.79)。 • 凝集度が⽋如していたクラス53個について、結合度の値が中央値の5以下 では⽋陥修正率が17/28 = 0.61であったのに対して、 中央値より⼤きい場合では⽋陥修正率が25/25 = 1.0であった。 2015/2/13 28 レビューやテストの重点化を進めるにあたって、 このようなデータから得られた客観性の⾼い知⾒は プロセス改善の推進⼒になる Makoto Nonaka、 Toyo University
  29. 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. 30. “I‘d rather be vaguely right than precisely wrong.” 精密に誤るよりも、漠然と正しくありたい – John Maynard Keynes  私たちのメトリクス分析は 精密に誤っていないか?(⾃戒の念も込めて) – 理論モデルの洗練が⽬的になっていないか – 現場にとって分かりにくい分析結果やモデルになっていないか – その分析結果やモデルは品質向上に貢献するのか  漠然と正しい 情報が得られているか? – 意思決定の役に⽴つレベルの精度が得られているか – 正しい意思決定に役⽴つ、正しい⽅向感の情報を⽣み出しているか 302015/2/13 Makoto Nonaka、 Toyo University
  31. 31. 品質データ測定・分析のアクションプラン • 上位レベルの⽬的を定める – 顧客満⾜のために、製品・サービスとして重点管理すべき品質特性は何か 例)ISO/IEC 25010:2011 システム/ソフトウェア製品品質モデル – 事業戦略および製品・サービス戦略の上で重視すべきKPIは何か • 品質データ測定・分析の直接の⽬的を定める – 製品・サービスに対する顧客の評価(またはその代替指標)を把握したい – 開発中のプロジェクトの品質状況を把握したい – 開発⼯数の⾒積りの妥当性を評価したい など • ⽬的達成に必要なメトリクスとその可視化・分析⽅法を検討する – 製品・サービスのリリース後の状況を把握する指標として何を測定するか – プロセス指標・プロダクト指標として何を測定すればよいか – どのような統計量/グラフを⽤いれば必要な情報が得られるか • 可視化・分析によって得られた情報に基づきアクションをとる – データを通じて把握できた事実に基づき、どのような施策につなげるか 312015/2/13 Makoto Nonaka、 Toyo University
  32. 32. ソフトウェアの品質モデル ISO/IEC 25010:2011 (JIS X 25010:2013) 32 システム/ソフトウェア製品品質 機能適合性 機能完全性 機能正確性 機能適切性 移植性 適応性 設置性 置換性 保守性 モジュール性 再利⽤性 解析性 修正性 試験性 性能効率性 時間効率性 資源効率性 容量満⾜性 使⽤性 適切度認識性 習得性 運⽤操作性 ユーザエラー防⽌性 UI快美性 アクセシビリティ 信頼性 成熟性 可⽤性 障害許容性 回復性 互換性 共存性 相互運⽤性 セキュリティ 機密性 インテグリティ 否認防⽌性 責任追跡性 真正性 <製品品質モデル> 2015/2/13 • 明⽰/暗黙ニーズを満たして顧客満⾜/顧客歓喜を実現するために、 どのような品質要素/品質特性を重視するのか • 競争戦略上、どのような品質要素/品質特性を重視するのか • 戦略的観点も含めて品質要求を定義し、品質要素の達成状況の評価を プロセスに取り⼊れる Makoto Nonaka、 Toyo University
  33. 33. 当たり前品質と魅⼒的品質 33 特性値が不充⾜ 特性値が充⾜ ⼼理的に 満⾜ ⼼理的に 不満⾜ 魅⼒的品質 当たり前品質 ⼀元的品質 ある特性が充⾜されることは「当たり前」であり、 ⼼理的な満⾜度の向上には結びつかないが、 それが充⾜されていないと不満を引き起こす ような品質要素 ある特性が充⾜されていなくても不満とは 思わないが、ひとたびそれが充⾜されると ⼼理的な満⾜度が向上するような品質要素 ある特性の充⾜/不充⾜が ⼼理的な満⾜/不満⾜と連動 するような品質要素 2015/2/13 Makoto Nonaka、 Toyo University
  34. 34. プロセス改善により失敗コスト⽐率を下げ、総品質コストを抑制する 1. 外部失敗コストの低下 – テストを重視し、テスト状況を把握し、 外部失敗を内部失敗へと振り分ける 2. 内部失敗コストの低下 – レビューを重視し、レビュー状況を把握し、 ⽋陥を早期に除去できるようにする 3. ⽋陥除去プロセスの効率向上 – レビューとテストの効率向上に努める – リスクベースで活動の重点化を図る – プロセス改善、知識蓄積、教育に投資する 4. 総品質コストの低減・安定化 – リスクベースによるレビューとテストの「間引き」が 機能不全に陥らないように注意 34 • ⼀定の品質コストはつねに必要である • その効率向上を追求する必要がある • 安易な品質コストの削減は、取り返しのつかないところまで組織能⼒を衰退させる 品質マネジメント能⼒の成熟度 プロジェクトに占める品質コスト 外部失敗コスト 内部失敗コスト 評価コスト 予防コスト 2015/2/13 Makoto Nonaka、 Toyo University
  35. 35. 品質にしっかりと取り組めば、組織は賢く、強く、幸せになれる • 品質にしっかりと取り組む – ソフトウェアを通じて顧客に提供する価値を考える – 価値を提供し続けるために、組織的に必要な活動をデザインする • 対象とするニーズを定める/新たに掘り起こす • ニーズを満たす製品・サービスの品質要素を計画する(ねらいの品質) • 品質要素の実現度合い(できばえの品質)を保証するプロセスを確⽴する • 品質要素の実現に係る固有技術と、管理や品質保証に係る技術を進化させ、 価値提供のスピードを加速する • 提供した価値に対する顧客満⾜の度合いを評価する • 「事実に基づく管理」を主軸にして、プロセスを継続的に改善する • この過程で得られた知識を、組織的に活⽤する • 組織が賢く、強く、幸せになる – 価値提供の結果 / ⾃社独⾃の経験 / 失敗に学び、組織が賢くなる – 組織独⾃の知識・技術 / 継続的改善能⼒は、競争優位の源泉である – 賢く強い組織は、幸せになる 352015/2/13 Makoto Nonaka、 Toyo University

×