Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Qua s tom-メトリクスによるソフトウェアの品質把握と改善

3,635 views

Published on

メトリクスによるソフトウェアの品質把握と改善
   -GQM法とメトリクス動向-
◆概要
測定とメトリクスの基本概念、および、GQMによる目標指向の測定の解説と演習。成功や失敗の事例紹介。

◆講師
鷲崎 弘宜 氏
早稲田大学グローバルソフトウェアエンジニアリング研究所所長・准教授

略歴:
2003年早稲田大学大学院博士後期課程修了、博士(情報科学)。
2008年より早稲田大学准教授、国立情報学研究所客員准教授。
再利用と品質保証を中心としたソフトウェア工学の研究と教育に従事。
他の活動に日科技連SQiP研究会運営小委員会委員長、
同研究会演習コース主査、情報処理学会論文誌編集委員など。

本日、QuaSTom高品質ソフトウェア技術交流会 第1回例会にて「メトリクスによるソフトウェアの品質把握と改善-GQM法とメトリクス動向-」と題し、メトリクスの基本概念や落とし穴・コツ、事例、そしてGQM法のコツとワークショップ(+少しだけ GQM+Strategiesの解説)と盛りだくさんの内容を実施しました。ワークショップでは限られた時間の中で各チーム、ゴールからメトリクス、さらには仮定まで練られたものが得られた点はさすがです。議論においても今後の実践に踏み込んだものが多数あり、参加者の皆さんの問題意識の髙さやご経験を踏まえた関心の高さを感じました。ぜひ今後実践や連携いただければ幸いです。

Published in: Software
  • Be the first to comment

Qua s tom-メトリクスによるソフトウェアの品質把握と改善

  1. 1. メトリクスによるソフトウェアの 品質把握と改善 -GQM法とメトリクス動向- 早稲田大学グローバルソフトウェアエンジニアリング研究所 鷲崎 弘宜 Twitter: @Hiro_Washi washizaki@waseda.jp http://www.washi.cs.waseda.ac.jp/ わしざき ひろのり QuaSTom - 高品質ソフトウェア技術交流会 第1回例会 2015年4月24日
  2. 2. • 早稲田大学グローバルソフトウェ アエンジニアリング研究所所長・ 准教授 • 国立情報学研究所客員准教授 • 情報規格調査会ISO/IEC SC7/WG20 主査 • IEEE CS Japan Chapter Chair • SEMAT Japan Chapter Chair • ACM-ICPC 2014 Tokyo Director • IPSJ SamurAI Coding Director • 運営: ASE, SEKE, SPLC, APSEC, AsianPLoP… • プログラム委員: ASE, ICST, … • 論文: ICSE, ASE, CAiSE, ICST, … 2
  3. 3. 早稲田大学グローバルソフトウェア エンジニアリング研究所 • グローバル開発時代 のソフトウェアエンジ ニアリング研究 • 鷲崎(所長) • 東基衞(顧問)、筧、 深澤、岸、本田(所員 ) • 招聘研究員17 名 • 学生25名 (留学生5名 、中国、ノルウェー、メ キシコ、インドネシア) 3 HITACHI YAHOO! Google FUJITSU NEC TOSHIBA OGIS-RI AfrelRECRUIT Florida Atlantic University Benesse 信州大学 東京大学 IPANII KOMATSU QUNIENAIST 学芸大 IISEC
  4. 4. FUJITSU Google FUJITSU 如何にソフトウェアを効率よく効果的に開発できるか? 如何に堅固な理論の上にプラクティスを構築できるか? 4 要求定義 コード解析 単体テスト 受入テスト マネジメント 教育 実装 Abstraction Modulari zation Auto mation Reuse Visuali zation Formali zation Software 基本設計 統合テスト 保守 品質管理 詳細設計 テスト環境と 検証 HITACHI YAHOO! NEC TOSHIBA OGIS-RI Afrel KOMATSU Florida Atlantic University Benesse 信州大学 NII 品質測定とマネジメント アジャイル開発、パターン、教育に おける実証研究 RECRUIT QUNIE 再利用と 開発環境
  5. 5. 測定と品質マネジメント Industrial Experience of GQM-based Product-Focused Project Monitoring (APSEC’14) Predicting Time Range Based on Generalized Software Reliability Model (APSEC’14) Iterative Process to Improve GQM Models with Metrics Thresholds (SANER’15 Doctoral) 再利用と開発環境 Stakeholder relationship analysis to refine GQM+Strategies models (PROFES’14) RefactoringScript: A Script for Composite Refactoring (SEKE’14) A Tool to Suggest Similar Program Element Modifications (APSEC’14) Interactive Recovery of Requirements Traceability Links (CAiSE’15) テスト環境と検証 Bug Localization for Re-engineered Industrial Software (ICST’14) Validating Ajax Applications Using a Delay-Based Mutation Technique (ASE’14) Do open source software projects conduct tests enough? (PROFES’14) Security and Privacy Behavior Definition for BDD (PROFES’14) Verification of Implementing Security Design Patterns (ARES’14) Validating Security Design Pattern Applications (Int. J. Secure Soft. Eng. ‘15)(ICST’15) アジャイル開発、パターン、教育における実証研究 Network Analysis for Software Patterns (AGILE’14) Impacts of Personal Characteristic on Educational Effectiveness (CSEET’14) Programmable Robots as Programming Educational Tools (ACE’15) Relationship between constraints and iteration length (Int J. Comp. App. In Tech. ‘15) 5 直近の研究発表
  6. 6. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 6
  7. 7. 品質とは • 品質: あるものの特性または属性 [American Heritage Dictionary] • ソフトウェア品質: ソフトウェアの使用時に必 要性を満たす能力を決定する属性全体 [ISO9126-1][ISO25000][JIS0129-1] – 属性: ソフトウェアの定性的/定量的に測定可能 な特徴 7
  8. 8. メトリクス(Metric / Metrics) • 測定の方法と尺度 – 方法: 属性(測定可能な特徴)の尺度上の値や分類への 対応付け – 尺度: 値や分類の集合 • 測定できない事柄は、管理できない(T. DeMarco) – ソフトウェア工学 = ソフトウェアの開発、運用、および保 守に対する系統的で規律に基づいた定量的アプローチ [SWEBOK] – Prj成功率 31% → 定量的評価導入Prj 46% [矢口08] …… …… …… 測定方法 測定尺度 測定プロセス メトリクス 測定結果 (値、分類) 8 [SWEBOK] 松本吉弘 監訳: ソフトウェアエンジニアリング基礎知識体系―SWEBOK2004, オーム社, 2005. [矢口08] 矢口竜太郎, 吉田洋平: 成功率は31.1%, 日経コンピュータ12月1日号, 2008.
  9. 9. 測定対象のエンティティ • プロセス – 入力を出力に変換するアクティビティ(活動)の集合 • プロダクト – アクティビティから出力される成果物や文書 • リソース – アクティビティの実施に必要な人、もの、金などの資源 9 N.E. Fenton, and S. L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, PWS Publishing 野中誠 , ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー プロセス 入力 プロダクト 出力 プロダクト リソース
  10. 10. 測定方法 • ソフトウェアの抽象的な特定側面を捉える • 測定方法が異なれば測定結果も変わる 1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ 2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする 3:場合、動作は未定義である。*/ 4:char *strncat(char *dest, const char *src, size_t count) 5:{ 6: char *temp=dest; 7: if (count) { 8: while (*dest) 9: dest++; 10: while ((*dest++=*src++)) { 11: if (--count ==0) { 12: *dest=‘¥0’; break; 13: } 14: } 15: } return temp; 16:} 10
  11. 11. 例:サイクロマティック複雑度 (Cyclomatic Complexity: CC) • テキスト – プログラムの制御フロー上で他とは異なるリンク(エッ ジ)を持つ経路数 • ダイアグラム • アルゴリズム – V(g) = e – n + 2 (ただし e: エッジ数、n: ノード数) – V(g) = bd + 1 (ただし bd: 二分決定数) 出典: 野中誠 , 鷲崎 弘宜,ソフトウェア技術者のためのメトリクス基礎, 2010, TopSEセミナー [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエア の測定と見積もりの正しい作法", 日経BP社 , 2009. = 2 11
  12. 12. メトリクスの使いどころ • 現在: 把握、評価 • 未来: 予測、計画 要求 定義 設計 実装 テスト 機能 仕様書 ファンクション ポイント モジュール 設計 凝集度 結合度 ソース コード 複雑度 コード行数 欠陥票 欠陥密度 テスト ケース 消化数 工数、期間 12
  13. 13. 実態把握や問題絞込み • ヒストグラム – 分布状況の把握 • 管理図 – 平均や範囲のばら つき – 異常の特定 件数 測定値 例: サイクロマティック複雑度 13
  14. 14. 予測や計画 • 散布図 – 関係の把握 • 関係性の分析 – 単回帰分析: 1つの説明変 数、1つの目的変数 – 重回帰分析: 2つ以上の説 明変数 – 2値データのロジスティック 回帰分析: 目的変数が0,1 被使用外部ファイル率 関数 再利 用率 呼出し関数の数 実測値 予測値 重相関係数 =0.941 鷲崎弘宜, 小池利和, 波木理恵子, 田邉浩之, "C言語プログラムソースコード の再利用性測定法とその評価", ソフトウェアテストシンポジウム JaSST'09 14
  15. 15. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 15
  16. 16. 主なメトリクス 名称 定義 用途 コード行数(LOC) コードの行数 規模の把握、他のメトリ クスの正規化 ファンクションポイン ト(FP) 機能量 規模の見積もり サイクロマティック複 雑度(CC) 制御フローグラフの経路 数 複雑さの把握 凝集度 モジュール内の要素のま とまり 複雑さの把握 結合度 モジュール間の結合関係 の多さ 複雑さの把握 欠陥密度(DD) 欠陥数 / 新規・変更LOC 品質の把握、開発プロセ ス全体の有効性把握 欠陥除去率(DRE) 欠陥摘出数 / 当該時点 欠陥数 開発プロセス全体や工 程の有効性把握 消化済みテストケー ス数 当該時点までの消化済 みテストケース数 テストの進捗把握 プロダクト プロセス 16
  17. 17. 規模: コード行数(LOC)の留意点 • 測定モデルの一貫性 – NLOC, LLOC – CMU/SEI チェックリスト • 作成方法、出所 – 25%を超える修正は新規実装と同程度の工数 [Linda09] • 言語の違い – ビジュアル言語、オブジェクト指向: 手続き型ほど役立たない – 言語補正係数表によるファンクションポイントとの関係 [LOC/FP](例: アセンブリ 320, Java 53, C 128, 表計算 6) • コメント比率 = コメント行数 / LOC – 12.6%を超えると、コメントなしコードの2倍欠陥潜在率 [阿萬 12] 17 阿萬, “オープンソースソフトウェアにおけるコメント記述およびコメントアウトと フォールト潜在との関係に 関する定量分析”, 情報処理学会論文誌, 53(2), 2012. CMU/SEI-92-TR-022. ESC-TR-92-022. Software Quality Measurement: Framework for Counting Problems and Defects. http://www.sei.cmu.edu/reports/92tr020.pdf [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエア メトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009.
  18. 18. ユーザ 入力 出力 測定対象アプリケーション データファイル 照会 外部アプリ ケーション インタ フェース 規模: ファンクションポイント法 • 内部の処理や解決策ではなく問題の扱い – システムの入出力、インタフェース、データファイルといった「代理」 (プロキシ)の数え上げ – 複雑さや環境などの難易度係数で調整 • 機能規模測定(Functional Size Measurement) – ファンクションポイント法(FP法): 1979 オールブレクト – IFPUG(International Function Point Users Group http://www.ifpug.org )結成、標準化 – 技術独立・初期段階で利用可 ⇔ 経験の必要性、主観性・属人性 18
  19. 19. 複雑さ: サイクロマティック複雑度など • 欠陥、保守やテストの困難さの検討 – レビュー・テスト必要箇所の特定、工数見積もり • 関数内: サイクロマティック複雑度 – 20が欠陥含まれやすさ閾値 – [鷲崎10] 1 推奨、2~9 許容 • モジュール内: 凝集度 – 単一機能 ← データ中心 ← 機能中心 ← 無関係 – LCOM(Lack of Cohesion in Methods) < 2~5 [Chidamber94]: 参照変数が共通しないメソッド組み合わせ数 - 共通ありの 組み合わせ数 • モジュール間: 結合度 – データ渡し ← 制御フラグ渡し ← グローバルデータ – ファンアウト≦ 7±2 [SESSAME] 19 [鷲崎10]鷲崎弘宜,田邉浩之, 小池利和,”ソースコード解析による品質評価の仕組み“, 日経エレクトロニクス, 2010年1月25日号 [SESSAME07] SESSAME WG2, 組込みソフトウェア開発のためのリバースモデリング, 翔泳社, 2007. [Chidamber94] S.R.Chidamber and C.F.Kemerer, “A Metrics Suite for Object-Oriented Design”, IEEE Trans. Software Eng., vol. 20, no. 6, pp.476-493, June 1994 = 2
  20. 20. 欠陥: DD, DRE • 欠陥数、欠陥発見・摘出数 – 実測、動的・静的予測 – 時間あたりの場合は単位に注意 • 欠陥密度 (Defect Density: DD) = 欠陥数 / 新規・変更LOC – 品質把握、プロセス全体のパフォーマンス把握 – ドメインや稼働時間の相違の考慮が必要 • 欠陥除去率(Defect Removal Efficiency: DRE) = 当該工程欠陥除去数 / 当該工程で存在した欠陥数 – 各欠陥摘出工程の欠陥摘出能力把握、改善 – 各欠陥の作り込み・原因工程の記録必要あり [Linda09] リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエア メトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009. 20 20
  21. 21. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 21
  22. 22. 落とし穴「ホーソン効果」 22
  23. 23. I. 解釈 (評価基準) コツ「ゴール指向のメトリクス定義」 • Goal-Question-Metric(GQM)パラダイム M. メトリクス G. 目標 Q. 質問 測定対象(データ) 達成評価 答え 測定値 23 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994)
  24. 24. コツ「多面的に測り、最後は現物」 24 G.信頼性 G.保守性 G.移植性G.効率性 G.再利用性 G.解析性 G.変更性 G.試験性目標 メトリクス M.コールグラフ 階層の深さ M.サイクロ マティック複雑度 M.関数内の 戻り点の数 G.安定性 ・・・ ・・・ Q.制御構造が 複雑すぎない か? 質問 副質問 Q.処理が複雑 すぎないか? Q.処理が構造 化されているか? Q.複雑な文を記 述していない か? ・・・・・・ ・・・ …… … …… … …… … …… … プログラム ソースコード 鷲崎弘宜,田邉浩之,小池利和,ソースコード解析による品質評価の仕組み,日経エレクトロニクス 2010/1/25 [Adqua] http://www.ogis-ri.co.jp/product/b-08-000001A6.html
  25. 25. 落とし穴「値を信頼できるとは限らない」 25 1:/* strncat()は、文字列srcからcount数の文字を文字列destに付加し、さ 2:らに終端にnull文字を付加する。重なるオブジェクト間でコピーしようとする 3:場合、動作は未定義である。*/ 4:char *strncat(char *dest, const char *src, size_t count) 5:{ 6: char *temp=dest; 7: if (count) { 8: while (*dest) 9: dest++; 10: while ((*dest++=*src++)) { 11: if (--count ==0) { 12: *dest=‘¥0’; break; 13: } 14: } 15: } return temp; 16:} リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
  26. 26. I. 解釈 ダッシュボード コツ「ツールで客観的に、組織で一貫」 26 M. メトリクス G. 目標 Q. 質問 対象(データ) 評価 答え 測定値 モニタ ツール メトリクス システム H. Nakai, et al. Initial Industrial Experience of GQM-based Product-Focused Project Monitoring with Trend Patterns, APSEC'14 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14
  27. 27. 落とし穴「未来が今の延長とは限らない」 27
  28. 28. コツ「不確実性を考慮した測定と予測」 • 予測における幅と種別 28 0 10 20 30 40 50 60 70 80 90 0 5 10 15 • 経験に基づく仮定明示 M. 呼び出し先 モジュール数 G. 変更されやすい 箇所を特定できている Q. モジュールの依存 関係はどの程度か? M. 呼び出し元 モジュール数 A. あちこちと依存するモ ジュールは変更されやすい K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. Basili, V.R., et al. Linking Software Development and Business Strategy Through Measurement, IEEE Computer, 2010.
  29. 29. コツ「メトリクス システムの改善」 29
  30. 30. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 30
  31. 31. 事例1: Yahoo! Japanとの取り組み メトリクスによる保守性・機能性評価・改善 31H. Nakai, et al. Initial Industrial Experience of GQM-based Product-Focused Project Monitoring with Trend Patterns, APSEC'14
  32. 32. 事例1(つづき): 不確実性を考慮した欠陥予測 予測欠陥数の変動欠陥数と予測モデル 不確実性 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14 32
  33. 33. 33 25 0.2 15 0.1 05 0 05 0.1 15 0.2 -15 -10 -5 0 5 10 15 0 0.5 1 -0.5 -0.4 -0.3 -0.2 -0.1 0 0.1 0.2 0.3 K. Honda, et al., Predicting Time Range Based on Generalized Software Reliability Model , APSEC’14
  34. 34. 事例2: 富士通との取り組み 開発主体の移り変わりと変更・欠陥予測 34 O1 O12 O2 O13 O123 O23 O3 O: Origin(由来) Apache Foundation (1) Oracle (2) Sun (3) OpenOfficeの場合 S. Sato, et al., Effects of Organizational Changes on Product Metrics and Defects, APSEC'13
  35. 35. 事例2(つづき): メトリクスや由来から将来予測 35 コードの規模・ 複雑さメトリクス 開発主体 変更回数 変更規模 欠陥 M. ファイル規模 M. 他ファイルとの呼び出し関係 ・・・ S. Sato, et al., Effects of Organizational Changes on Product Metrics and Defects, APSEC'13
  36. 36. 36 人手 レビュー Adqua+ 評価ツール 事例3: コマツとの取り組み 保守性評価メトリクス システム改善 I A Q M G 機械学習+ 人手精査 N. Tsuda, et al. Iterative Process to Improve GQM Models with Metrics Thresholds to Detect High-risk Files, SANER'15 Doctoral M 改善
  37. 37. 事例3(つづき): 責務過多なファイル特定 37 10 25 300 150 M. 関数の数 M.実行行数 OK NG 71 M. 関数の数 M.実行行数 OK NG △ 人手OK, ○ 人手NG N. Tsuda, et al. Iterative Process to Improve GQM Models with Metrics Thresholds to Detect High-risk Files, SANER'15 Doctoral
  38. 38. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 38
  39. 39. Goal-Question-Metric (GQM) パラダイム • 明確に目標を据えて、目標に対して必要なメトリクスを対応 付けるゴール指向(目標指向)な枠組み • 目標(Goal): 測定上の目標 • 質問(Question): 目標の達成を評価するための質問 • メトリクス(Metric): 質問に回答するために必要な定量的デ ータを得るための主観的・客観的メトリクス 測定する事柄 の決定 測定結果の 解釈 M. メトリクス G. 目標 Q. 質問 収集データ 目標達成評価 答え 測定値 R. van Solingen, E. Berghout, “The Goal/Question/Metric Method” McGraw-Hill Education, 1999; ISBN 0-07709-553-7. 39
  40. 40. GQMモデル(グラフ)の例 • 目標 – G. コードクローン含有の観点から保守性の低いコードを 特定できている。 • 質問 – Q1: コードクローンは存在するか? → M1, M2 – Q2: 発見されたコードクローンは保守上有害か? → M3 • メトリクス – M1: ソースコードの全体的な重複度 – M2: モジュール単位のコードクローン含有率 – M3: コードクローンに対するマネージャの主観的評価 40 G Q1 Q2 M1 M2 M3 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994) リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
  41. 41. 目標テンプレートとコンテキスト • 目標の一般性、扱う範囲の明確化 • テンプレート – 例: コードクローン含有の観点から保守性の低いコードを 特定できている。 – 対象 (Analyze) 例: ソースコード – 目的 (Purpose) 例: 保守性の低いコードの特定 – 関心 (Respect to) 例: コードクローン情報 – 視点 (View) 例: プロジェクトマネージャ – 環境 (Context) 例: A社の開発環境 • 環境 – ドメイン、開発者数、経験、開発プロセス・手法、規模・工 数、信頼性要求、・・・ 41 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012. V. Basili, et al.: Goal, Question, Metric Paradigm, Encycloperia of Software Engineering, Vol. 1(1994) リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの", 日経BP社 , 2009.
  42. 42. Question導出の観点 • 測定対象そのものを目的から見て明確にする – 例: ○○はいくらか? • 対象の属性を評価者の視点から見て明確にす る – 例: ○○は(従来と比べて)改善されているか? • 対象の特徴を評価者の視点から見て評価する – 例: ○○は××からみて目に見えて改善されている か? 42 楠本真二, 肥後芳樹, “GQMパラダイムを用いたソフトウェアメトリクスの活用”, コンピュータソフトウェア, 2012.
  43. 43. GQMの拡張 • 上位/ビジネスゴール (参考: GQM+Strategies) – 測定上のGoalの上位ゴール – B. 収益が拡大している -> G. 収益向上を予測できている – B. ツールが開発状況の把握に役立っている -> G. 要求の不安定 さを把握できている • 仮定(Hypothesis, Assumption) – Question導出にあたり仮定している事柄 – A. 要求が不安定であれば設計は頻繁に変更される。 • 解釈(Interpretation) – もし「条件式」ならば「Goalはこのように達成・未達成である」 – I. もしLOCが少なすぎず、かつ、設計変更回数が一定以上ならば 、要求が不安定な可能性がある。 • メカニズム(Mechanism) – データの収集と報告を実施する責任者、収集・報告頻度、必要な インフラ – 例: プロジェクトマネージャが毎週、XXXレポートを参照して・・・ 43 リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と 見積もりの正しい作法", 日経BP社 , 2009. Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012.
  44. 44. GQMの拡張: 仮定と解釈 44Monden, Basili, et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans., 2012. G. 特定プロジェクトにおける要求の不安定さを把握できている Q. ソースファイルの 変更頻度はいくらか? Q. ファイルの変更 規模はいくらか? FCt. 一週間以内の ファイル更新回数 FCd. 一週間以内の削除 を伴うファイル更新回数 FLa. 一週間以 内の追加行数 A. 要求が不安定であれば コードは頻繁に削除を 伴って変更される A. 要求が不安定であれば コードは大きく変更される FLd. 一週間以 内の削除行数 I. FCt が極端に大きくなく、かつ、 FCdが以前よりも大きいのであれ ば、要求が不安定な可能性あり I. FLa が極端に大きくなく、かつ、 FLdが以前よりも大きいのであれ ば、要求が不安定な可能性あり ・・・
  45. 45. 仮定と解釈の明確化と閾値 • 仮定を事実から分けて明確に – 何が確認済みで、何が未確認なのか – 測定評価の繰り返しにおける見直し • 解釈の効用 – 多面的な捉え方 – 閾値の明確化 • 閾値の決定 [Alves10] – ベンチマーク分布: 平均±k・σ、割合によるリスク設定(低 リスク 0-70%、中 70-80%・・・) – 経験ベース、メトリクス毎の特徴づけ、欠陥との照らし合 わせなど – 最初から「正確な」閾値決定は難しい。最初は大まかに、 データ蓄積と現物確認を経て徐々に精密に。 45 Tiago L. Alves, et al., “Deriving Metric Thresholds from Benchmark Data,” ICSM 2010
  46. 46. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 46
  47. 47. ワークショップ 1. Goalのブレーンストーミング、チーム分け – ソースコードの規模や特定品質の把握 – ソースコードの特定品質の改善 – ソースコードの特徴やテスト結果と関係するプロダクトやプロセ スの品質・状況の把握(あるいは改善) – その他 2. チームでGQM適用 – Goal詳細化(必要であればビジネスゴールも) – Question導出(仮説も) – Metric識別(解釈も) 3. チーム内で見直し、修正 – そもそものビジネスゴールに照らした妥当性 – G-Q-M の縦の妥当性 – Q-M の横の広がりの網羅性 4. 講評、振り返り、今後のアクション 47
  48. 48. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 48
  49. 49. M1: 顧客満足度調査 測定データ目標と戦略 ビジネスレベルソフトウェアレベル 目標:顧客満足度 10%向上 戦略:製品品質改善 戦略:製品の使いや すさ改善 目標:顧客からの不 具合指摘を20%削 減 サブレベルの目標が定義されていない  戦略が明確に伝達されていない 戦略:システムテスト 効率の改善 戦略:ソフトウェアの メンテナンス性を改 善 分離した戦略  貢献/価値は何か?  暗黙の目標があるのか? M2: 現場の不具合 データ M3:コード品質指標 (McCabe, カプリング, 凝集) 分離したデータ  データの用途は? (e.g., コード品質の改善など) 49 組織における目標、戦略、測定データの問題 J. Heidrich, A.Trendowicz, “測定を基にした、ソフトウェア戦略とビジネス目標の整合”, http://sec.ipa.go.jp/reports/20130325.html
  50. 50. GQM+Strategies: 組織目標・戦略・測定上の目標 • ポイント – 事実(Context)や仮定( Assumption)を明示して戦 略結びつけ – 組織上位から下位まで連 鎖 – 測定上の目標を掲げた GQMグラフを紐づけ定量評 価 • 取り組みや環境 – ツールあり – 早稲田大学ゴール指向経 営研究会、ITC研究会 ’13~ – 国内事例: JAXA、伊藤忠テ クノソリューションズ、リクル ート住まいカンパニーほか 組織上位の目標 組織上位の戦略 組織中位の目標 組織中位の戦略 組織下位の目標 事実・仮定 ・・・ G Q Q M M GQMグラフ目標ツリー G Q Q M M G Q Q M M G Q Q M M Basili, V.R., et al. “Linking Software Development and Business Strategy Through Measurement,” IEEE Computer, Vol.43, No.4, pp.57-65, 2010. 早稲田大学ゴール指向経営研究会、「残念なシステ ム」のなくしかた、日経ITPro連載、2014年5月14日 ~6月11日 50
  51. 51. 6 パッケージ化と改善 目標と戦略を適合し改善 背景と仮定の是正 学習の記録 0 初期化 コミットメント 人材 & 責任 51 GQM+Strategies® プロセス 5 結果の分析 ・データを分析し、戦略を改定 ・結果のレビューと伝達 ・コスト/メリットの分析 1 特性化(Characterize) ・適用範囲の定義 ・環境/事実の特性化 2 目標設定 ・組織構造を特定(determine) ・ギャップ分析の実施 ※現状の施策、データ等の確認 ・目標の優先順位づけ ・グリッド導出(derivation)プロセスの実施 3 プロセスの選択 ・戦略実施の計画 ・データ収集と分析の仕方の整理 ・フィードバックの仕組みの定義 4 モデルの実行 ・戦略の適用 ・データの収集と検証 ・フィードバックセッションの実施 J. Heidrich, A.Trendowicz, “測定を基にした、ソフトウェア戦略とビジネス目標の整合”, http://sec.ipa.go.jp/reports/20130325.html
  52. 52. 例 目標設定: GQM+Strategies® グリッドの整理(トップレベル) まず最初に、特性化プロセスで得た経営戦略、経営環境、営業戦略等の情報をもとに、トップレベ ルのゴール、戦略をGQM+Strategies® グリッドにしたがって整理してみます。以下に示すように整 理すると、今回の適用範囲である営業部の目標(ゴール)と戦略が見えてきます。 Strategy:S1 商品力強化 (圧倒的に 他社と差別性のあるメ ディカルプロダクトの開 発) 経営戦略 Goal: G3 新商品(差別化商 品)の販売による売 上高 2億 Strategy:S2 既存顧客の深耕 (既存 販路の対応力を強化し た上で、複数販路の相 乗効果によるお客様の ご利用頻度向上) Strategy:S15 新規顧客の獲得 (アジア市場、若年層) Goal: G4 既存販売網におけ る前年度売上高5% 増 Goal: G5 新規販売網におけ る新規顧客獲得に よる売上高 3億 新商品(アンチエージ ング)の対面販売によ る販売強化 Strategy: S4 商品の組み合わせ (セット)販売による顧 客への統合価値の提 供 Strategy: S15 ドラッグストア販路開 拓 Strategy: S6 コンビニ販路開拓 Strategy: S7 中国での新設カウンタ を設置 Strategy: S8 営業部の ゴールと 戦略 測定指標 (後述) 測定指標 測定指標 (後述) 測定指標 測定指標 (後述) 測定指標 年齢別、性別ごとの マーケティング強化 Strategy: S9 "『ゴール指向経営』で的を射たIT投資、利益を生む組織に~「GQM+Strategies」の活用で組織内の整合性確保と定量的管理を実現~", IPA/SECセミナー 52
  53. 53. 例 目標設定: 事実と仮定の整理 戦略 商品の組み合わせ(セット)販売による 顧客への統合価値の提供 事実/仮定 既存販売網における前年度売上高5% 増 目標(ゴール) <事実> ・メディカルコスメ、敏感肌用化粧品に対する需要は 前年度比7%で伸びた。 ・当社の製品の特徴は、肌トラブルにやさしい化粧 品。 ・ユーザは化粧品の組合せによるトラブルを気にし て いる。(アンケートによると70%の人が相性を気に している) ・アンチエージングに関するスキンケア商品市場は 前年度比約4.6%の伸びを示す。 <仮定> ・化粧品の相性によって肌に合わない人も多い。 (アトピーの人など) 事業に関するゴールや戦略(事業施策)は、事業部門にインタビュー等を通して確認していきます が、その際に重要なことは、必ず、ゴールや戦略を決めた「根拠(事実と仮定を分けて整理する)」 を確認しておくことです。なぜならば、事業部門自身が、根拠の薄いゴール、戦略を策定している 可能性もあるからです。もし、事業部門が「根拠」を示せない場合には、聞き出したゴール、戦略が 正しいかどうかわかりませんので、システム部門から、そのことを指摘してあげることで、事業戦略 の誤りを防ぐこともできます。 【戦略の根拠】 "『ゴール指向経営』で的を射たIT投資、利益を生む組織に~「GQM+Strategies」の活用で組織内の整合性確保と定量的管理を実現~", IPA/SECセミナー 53
  54. 54. 例 目標設定: 測定データの定義 目標(ゴール)が決まりましたら、事業部門とともにゴール達成の測定データを定義します。 戦略を実行していったときに、何を持ってゴールを達成できたと判断するのかという定量値は、必 ず存在するはずです。したがって、それを確認して定義します。以下の例で説明しますと、まず① 評価する内容を明らかにして、②次に測定のベースラインを確認します。③そして測定値を明らか にします。④最後に、何をもって達成と判断するのか、判断基準を決めます。 既存販売網における今年度 末売上高は? 測定値 戦略 商品の組み合わせ(セット)販 売による顧客への統合価値の 提供 既存販売網における前年度売 上高5%増 目標(ゴール) 既存販売網における前年度 末売上高は111億 測定のベースライン 既存販売網における前 年度売上高5%増を評価 する 何を評価するか IF M4.2/ M4.1 >=1.05 THEN OK ELSE FAILED 達成の判定基準 事実/仮定 "『ゴール指向経営』で的を射たIT投資、利益を生む組織に~「GQM+Strategies」の活用で組織内の整合性確保と定量的管理を実現~", IPA/SECセミナー 54
  55. 55. 目次 • ソフトウェアの品質とメトリクス • 代表的なメトリクス • メトリクスの落とし穴と「コツ」 • メトリクスの事例 • ゴール指向の測定 GQM • ワークショップ: GQM • 組織における目標・戦略と測定 GQM+Strategies • まとめ 55
  56. 56. まとめ、メッセージ • ソフトウェア開発の厳しさとメトリクスの重要性 – 開発の管理、品質把握と改善 • メトリクスの限界を知り意思決定に役立てる – 測定方法、信頼性、妥当性、負のホーソン効果 • GQMによるゴール指向の測定 – 測定と改善のプロセス – GQM+Strategiesによる組織目標へのひもづけ 56
  57. 57. • メトリクス全般 – リンダ・M・ライルド, M・キャロル・ブレナン著, 野中誠, 鷲崎弘宜 訳 , "演習で学ぶソフトウエア メトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法", 日経BP社 , 2009. • GQM – 鷲崎弘宜、”ゴール指向の測定評価と留意 – GQMパラダイムと拡張 -”、メトリクス公団、Vol.1 、TEF東海メトリクス勉強会、2013. – 楠本真二、肥後芳樹: “GQMパラダイムを用いたソフトウェアメトリクスの活用”、コンピュータ ソフトウェア、29(3)、pp.29-38、2012. – Basili, V., Caldiera, C., and Rombach, D.: “Goal, Question, Metric Paradigm, Encyclopedia of Software Engineering,” Vol.1, pp. 528–532, 1994. • GQM+Strategies – Basili, V.R., Lindvall, M., Regardie, M., Seaman, C., Heidrich, J., Munch, J., Rombach, D., Trendowicz, A.: “Linking Software Development and Business Strategy Through Measurement,” IEEE Computer, Vol.43, No.4, pp.57-65, 2010. – 早稲田大学ゴール指向経営研究会、「残念なシステム」のなくしかた、日経ITPro、連載、2014 年5月14日~6月11日 • 事例 – 鷲崎弘宜, 田邉浩之, 小池利和, “ソースコード解析による品質評価の仕組み”, 日経エレクト ロニクス, 2010年1月25日号, 2010. – 鷲崎弘宜, 阿左美勝, 田邉浩之, “モデル活用の効能: 第1回 モデルを書く意味”~ “モデル活 用の効能: 第4回 参加チームの事例3″,日経エレクトロニクス, 日経BP社, 2011年8月8日号~ 11月号 – Kiyoshi Honda, Hidenori Nakai, Hironori Washizaki, et al., “Predicting Time Range of Development Based on Generalized Software Reliability Model,” 21st Asia-Pacific Software Engineering Conference (APSEC 2014) – Seiji Sato, Hironori Washizaki, et al., “Effects of Organizational Changes on Product Metrics and Defects,” 20th Asia-Pacific Software Engineering Conference (APSEC 2013). – Ryohei Takasawa, Kazunori Sakamoto, Akinori Ihara, Hironori Washizaki, Yoshiaki Fukazawa, “Do open source software projects conduct tests enough?,” 15th International Conference of Product Focused Software Development and Process Improvement (Profes 2014) – Susumu Tokumoto, Kazunori Sakamoto, Kiyofumi Shimojo, Tadahiro Uehara and Hironori Washizaki, “Semi-automatic Incompatibility Localization for Re-engineered Industrial Software,” 7th IEEE International Conference on Software Testing, Verification and Validation (ICST 2014) 57

×