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.

ソフトウェアメトリクス概要 20160514

5,708 views

Published on

redmine.tokyo 第10回勉強会 (2016/05/14開催) 発表資料

Published in: Software
  • Be the first to comment

ソフトウェアメトリクス概要 20160514

  1. 1. 0redmine.tokyo ソフトウェアメトリクス概要 ~ メトリクス概要とよく使われるメトリクス ~ 2016年5月14日 大和田 裕 (@yohwada) 第10回勉強会, 2016-05-14
  2. 2. 1redmine.tokyo 自己紹介 第10回勉強会, 2016-05-14  ハンドルネーム @yohwada  所属  Self-Employed  一般社団法人 実践的プロジェクトマネジメント推進協会 (PPMA) 理事  独立行政法人 情報処理推進機構 ソフトウェア高信頼化センター (IPA/SEC) 連携委員  Redmine歴  約5年 • 定量的プロジェクト管理ツール 「EPM-X」 • 定量的マネジメントプラットフォーム 「EPM Base」  ソフトウェアメトリクス関連  定量的管理基盤メトリクス分類表 (IPA/SEC Report)  プロジェクトの見える化 (IPA/SECセミナー)  共通フレーム2013 (IPA/SEC書籍)
  3. 3. 2redmine.tokyo ソフトウェアメトリクスとは 第10回勉強会, 2016-05-14  ソフトウェアメトリクス(メトリクス)  様々な活動を定量化し、その定量化したデータを管 理(マネジメント)に使えるように加工した指標。  ソフトウェア開発プロセス、資源、成果物の実態が ソフトウェアを開発するという点から見て適当であ るかどうかを計測し、予測するための手段。  ソフトウェアを対象とした計測方法・(定量的評 価)尺度,もしくは,計測・評価の結果。  メトリクス管理  加工して作ったメトリクスを使って管理(マネジメ ント)すること。
  4. 4. 3redmine.tokyo ちょっと余談 第10回勉強会, 2016-05-14  管理の意味  範囲を限定し維持・統制する。(上から下へ統制す ることが前提)  マネジメントの意味  組織や団体、人が存続・発展するための全ての活動。  様々な資源や資産・リスクなどを管理し、経営上の 効果を最適化しようとする手法のこと。  成果を出せるような環境や状況を作り出すこと。  マネジメント≠管理  マネジメントは、”管理”という意味合いの他、”評 価・分析・選択・改善・発展・回避・統合・計画・ 調整・指揮・統制・組織化”などを含んでいる。
  5. 5. 4redmine.tokyo メトリクスに関わる規格 第10回勉強会, 2016-05-14  JIS X 0141:2009 (ISO/IEC 15939:2007) システム及びソフトウェア技術−測定プロセス ISO/IEC 15939:2007には、「ソフトウェア測定プロセ ス」という標題が付いている。  JIS X 0160:2012 (ISO/IEC 12207:2008) ソフトウェアライフサイクルプロセス ISO/IEC 12207:2008には、「測定」というプロセスが定 義されている。  JIS X 0133群(ISO/IEC 14598) ソフトウェア製品の評価  JIS X 0129群 (ISO/IEC 9126) ソフトウェア製品の品質  JIS X 0161:2008 (ISO/IEC 14764:2006) ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守
  6. 6. 5redmine.tokyo メトリクスの枠組み 第10回勉強会, 2016-05-14 基本測定量 測定を行って直接結果 が得られる要素データ 導出測定量 要素データを組合せ、 計算することによって 結果が得られる指標
  7. 7. 6redmine.tokyo メトリクスの目的 第10回勉強会, 2016-05-14  ソフトウェア開発プロジェクトを成功に導きたいし、ソ フトウェアの品質を良くしたい。さらにソフトウェア開 発の生産性を一層向上させたい。つまりソフトウェア開 発の過程などを制御して、より良いソフトウェアと、そ のソフトウェアを開発するより良い方法を手に入れたい。  ソフトウェア工学の領域での重鎮の一人であるトム・デ マルコ(Tom Demarco)は、その著書の中で「測定で きないものは制御できない」と言った。  デマルコの言葉が正しいとすれば、ソフトウェアそのも のと、ソフトウェア開発に関わるいろいろな側面につい ての計測を行わなければならない。  端的に言えば、これがソフトウェアに関する事項を測定 すること、つまりメトリクスの目的。
  8. 8. 7redmine.tokyo ちょっと余談 第10回勉強会, 2016-05-14  メトリクスとメトリクス管理は「計測による制御」が前提  結果が予測出来ない試行錯誤を伴うまったく新しい概 念のプロダクトやプロセスへの適用は、ほとんど意味 がない。 • プロジェクトA: 1,000万円のコストを使って 1,100万円の価値を作る。  「計測と制御」が有効 • プロジェクトB: 1,000万円のコストを使って5億円 以上の価値を作る。  「計測と制御」で語れる部分の「外側」が重要
  9. 9. 8redmine.tokyo メトリクス・タイプ(1/4) 第10回勉強会, 2016-05-14  数値 (Number) 計測により対象から直接的に得られる数値。 例:ソースコード行数(Lines of Code),ファン クションポイント数(FP),バグ数。  属性 (Attribute) 計測対象の特性。〇〇度,△△性,といった表現が用 いられる場合が多い。 例:プログラム複雑度,耐故障性。  モデル (Model) 計測対象の構造や具体的な計測手順などを示した,理 論やデータに基づくモデル。 例:ソフトウェア信頼度成長モデル。
  10. 10. 9redmine.tokyo メトリクス・タイプ(2/4) 第10回勉強会, 2016-05-14  尺度 (Scale) 対象を分類するための枠組み・基準。  比例尺度:数値の差と共に数値の比にも意味がある 例:身長、体重、金額、絶対温度、工数変化率 体重は50kgから60kgになったときと、100kgから 110kgになったときとは、 同じ10kgの増加であっても、 前者は20%増、後者は10%増です。 また、比が定義できるということは絶対零点を持つこと と同じことを表します。
  11. 11. 10redmine.tokyo メトリクス・タイプ(3/4) 第10回勉強会, 2016-05-14  間隔尺度:数値の差のみに意味がある 例:摂氏温度,速度、バグ数 温度が10℃から15℃になったときに、50%の温度上昇 があったとはいいません。温度が10℃から15℃になった ときも、100℃から105℃になったときも、ともに5℃ の温度上昇です。そして、5℃という数値には意味があ ります。  順序尺度:値の大小関係だけに意味がある 例:階級(ヘビー、ウエルター、ライト)、故障の 重要度(軽微、普通、重要) 故障の重要度において、軽微・普通・重要を、それぞれ 1・2・3と数値に対応させたもの。平均値は定義できな いが中央値は定義できます。
  12. 12. 11redmine.tokyo メトリクス・タイプ(4/4) 第10回勉強会, 2016-05-14  名義尺度:観察される変数と数値を対応させる(分 類として記号の意味を持つのみ) 例:血液型,発生工程に基づくバグ分類,故障重大 度の5段階評価基準。 血液型でA型・B型・O型・AB型を、 それぞれ0・1・ 2・3と数値に対応させたもの。これらの変数の平均値を 求めてもまったく意味がありません。
  13. 13. 12redmine.tokyo メトリクスの分類 第10回勉強会, 2016-05-14  プロダクト(成果物)メトリクス  開発の結果得られたもの ドキュメント、プログラム、テストデータ等  プロセスメトリクス  成果物を作り出すための作業 ライフサイクルの全てのフェーズ(要求分析、 設計、コード、テスト、品質保証等)  リソース(資源)メトリクス  開発作業の入力となったもの HW、SW、ドキュメント、人的資源、知識等
  14. 14. 13redmine.tokyo メトリクスの分類 第10回勉強会, 2016-05-14  プロダクト(成果物)メトリクス  開発の結果得られたもの ドキュメント、プログラム、テストデータ等  プロセスメトリクス  成果物を作り出すための作業 ライフサイクルの全てのフェーズ(要求分析、 設計、コード、テスト、品質保証等)  リソース(資源)メトリクス  開発作業の入力となったもの HW、SW、ドキュメント、人的資源、知識等
  15. 15. 14redmine.tokyo プロダクトメトリクス(1/2) 第10回勉強会, 2016-05-14  プロダクト(成果物)の複雑さ  モジュール結合度、モジュール凝集度、 ファンクションポイント、C&Kメトリ クス、Software Science by Halstead、サイクロマチック数  プロダクト(成果物)の量  ドキュメント・ページ数、ソースコード行数、 ファンクションポイント数、テスト項目数
  16. 16. 15redmine.tokyo プロダクトメトリクス(2/2) 第10回勉強会, 2016-05-14  プロダクト(成果物)の質  故障数、欠陥数(バグ数)、単位時間あたり の故障数(故障率)、ソースコード1,000行 あたりの欠陥密度(バグ密度)、テストケー ス網羅率
  17. 17. 16redmine.tokyo メトリクスの分類 第10回勉強会, 2016-05-14  プロダクト(成果物)メトリクス  開発の結果得られたもの ドキュメント、プログラム、テストデータ等  プロセスメトリクス  成果物を作り出すための作業 ライフサイクルの全てのフェーズ(要求分析、 設計、コード、テスト、品質保証等)  リソース(資源)メトリクス  開発作業の入力となったもの HW、SW、ドキュメント、人的資源、知識等
  18. 18. 17redmine.tokyo プロセスメトリクス 第10回勉強会, 2016-05-14  各フェーズにおける活動を測定  時間、工数、工期、コスト、生産性、レ ビュー効率、欠陥除去率、関連イベントの有 無、関連イベントの発生回数 例:顧客との対話時間やインタビュー回数、 仕様書レビューに要した工数
  19. 19. 18redmine.tokyo メトリクスの分類 第10回勉強会, 2016-05-14  プロダクト(成果物)メトリクス  開発の結果得られたもの ドキュメント、プログラム、テストデータ等  プロセスメトリクス  成果物を作り出すための作業 ライフサイクルの全てのフェーズ(要求分析、 設計、コード、テスト、品質保証等)  リソース(資源)メトリクス  開発作業の入力となったもの HW、SW、ドキュメント、人的資源、知識等
  20. 20. 19redmine.tokyo リソースメトリクス 第10回勉強会, 2016-05-14  投入・消費される資源を測定  開発要員数、作業単価、スキルレベル、開発 用マシンスペック、使用ツール
  21. 21. 20redmine.tokyo メトリクス管理サイクル プロジェクトの進捗,課題・障害の解決状況,工数等の把握を定量データにより行 い問題の早期発見と対応を可能にすることにより、迅速かつ効果的なプロジェクト のPDCAサイクルを実現する。 プロジェクト 計画(P) 実施(D) 診断(C)対策(A) 最適な計画の立案 スケジュール、計画工数、 レビュー計画、品質計画.. 進捗実績、工数実績、レビュー実績 障害・課題データ.. 動的分析データの提供 プロジェクト状況データの フィードバックと情報共有 プロジェクト課題やリスクの早期発見 問 題 対 応 と 計 画 へ の フ ィ ー ド バ ッ ク プ ロ ジ ェ ク ト 状 況 の 把 握 第10回勉強会, 2016-05-14
  22. 22. 21redmine.tokyo メトリクス管理の期待効果(1/4) 第10回勉強会, 2016-05-14 1.可視化 ソフトウェア及びプロジェクトの可視化。 代表的な対象:プロダクト(成果物)、プロジェク トの進捗、プロセスの質  プロダクトの主な可視化対象 規模、品質、構成要素、構成要素間の関係  プロジェクト進捗の主な可視化対象 投入済み工数(コスト)とマイルストーンの達成状況  テスト工程の主な進捗把握対象 成功テストケース数、未消化テストケース数、欠陥発見数、 修正未了欠陥数などの時系列データ  プロセスの質の主な可視化対象 各アクティビティに費やした工数と、当該アクティビティで 発生した事象(欠陥の作り込みと除去など)
  23. 23. 22redmine.tokyo メトリクス管理の期待効果(2/4) 第10回勉強会, 2016-05-14 2.予測 ソフトウェアとプロジェクトが可視化できると、デー タに基づいた予測が可能となる。 代表的な対象:プロジェクトの工数、プロダクトの 規模、プロダクトの品質  仕様書からファンクションポイントを測定できれば、最終プロ ダクトの規模(KLOC)や開発工数を予測できる。  プロジェクトの進捗状況が可視化できれば、プロジェクト終了 時期と最終コストを予測できる。  プロダクト品質及びプロセス品質が把握できれば、最終プロダ クトに残存する欠陥数を予測できる。  プロダクト及びプロセスのメトリクスを組み合わせて、欠陥が 作り込まれる可能性が高いモジュールを特定することもできる。
  24. 24. 23redmine.tokyo メトリクス管理の期待効果(3/4) 第10回勉強会, 2016-05-14 3.計画 定量データが蓄積されれば、過去の実績及び予測に基 づいた計画を立案できる。 代表的な対象:プロジェクトに含まれる各アクティ ビティと、その所要工数及び実施時期。レビューや テストなどの欠陥除去工程において、何件の欠陥を 除去目標とするのかといった品質計画
  25. 25. 24redmine.tokyo メトリクス管理の期待効果(4/4) 第10回勉強会, 2016-05-14 4.改善対象の特定 定量的マネジメントの分解能が高くなると、プロセス の弱みやプロジェクトの弱みを定量データにより明確 化できるようになる。  設計レビューの欠陥除去能力を詳細に分析すると、設計レ ビューで除去すべき欠陥をどのくらい見逃しているのか、見逃 した欠陥はどのような種類が多いのかを定量データで示すこと ができ、欠陥見逃し原因の特定に役立てることができる。  テスト工程における欠陥発見数の累積値が一定のパターンにな らない場合には、テストケース設計に問題があるのか、テスト 実施プロセスに問題があるのか、テスト可能コードが断続的に 引き渡されているのかなど、改善すべき原因の特定が期待でき る。
  26. 26. 25redmine.tokyo 基本測定項目 第10回勉強会, 2016-05-14 プロジェクトをコントロールするための必要最小限 の測定項目(指標)  作業(作業要素):作業規模の指標  スケジュールでは矢印などであらわされている必 要となる作業(タスク)  作業成果物:開発規模の指標  プロジェクトの活動を通じて作成されるドキュメ ント、コード等のアウトプット  障害・課題:品質の指標  開発中に発生した障害や課題  工数:リソースの指標  メンバーがどのような作業にどのくらい時間を 使ったのかを測定
  27. 27. 26redmine.tokyo メトリクス(分析)の種類 第10回勉強会, 2016-05-14 1.リアルタイムメトリクス ある時点で得られる、および得られたメトリクスから 計算で得られるデータを分析する。 2.ヒストリカルメトリクス 時系列にメトリクスを蓄積し、推移を分析する。 3.予測メトリクス 上記1.2.より将来予測/将来計画設定・変更を行 う。
  28. 28. 27redmine.tokyo よく使われるメトリクス(分析) (1/3) 第10回勉強会, 2016-05-14 1.進捗  タスク/アクティビティ進捗率  進捗率推移  タスク/アクティビティ実績工数  実績工数推移  EVM 2.品質  バグ件数(発生、修正)推移  バグ発生率(バグ件数/規模)  バグ検出率(バグ件数/テスト項目数)  バグ収束率(総バグ件数/バグ予測件数)  信頼度成長曲線  障害原因分類
  29. 29. 28redmine.tokyo よく使われるメトリクス(分析) (2/3) 第10回勉強会, 2016-05-14 3.試験  テスト項目密度(テスト項目数/規模)  テスト項目消化率(実施テスト項目数/予定テスト項目数)  テスト項目消化数推移  テスト項目網羅率 4.課題  未完了課題数  課題解決時間 5.レビュー  レビュー項目密度(レビュー項目数/規模)  レビュー項目消化率(実施レビュー項目数/予定レビュー項目 数)  レビュー指摘分類
  30. 30. 29redmine.tokyo よく使われるメトリクス(分析) (3/3) 第10回勉強会, 2016-05-14 6.アジャイル  バーンダウンチャート  ベロシティ  サイクルタイム  累積フロー図(Cumulative Flow Diagram) 7.チケット  未完了チケット件数、件数推移  最大放置日数、日数推移  平均完了日数、日数推移
  31. 31. 30redmine.tokyo メトリクス管理の留意点(1/2) 第10回勉強会, 2016-05-14 1.目的と整合性のとれたメトリクスを用いる  有益な情報を提供できるメトリクスを定義し、運用 する。  GQM (Goal–Question–Metric)手法などを用い て、目的とメトリクスの整合性を確認する。  測定の目的は、測定データの提供者に共有されてい ること。  組織または個人に対してどのような有益なマネジメ ント情報が得られたのかを、データ提供者にフィー ドバックする。
  32. 32. 31redmine.tokyo メトリクス管理の留意点(2/2) 第10回勉強会, 2016-05-14 2.メトリクス情報は、測定したい概念の一部分  実世界の測定によって得られる情報は、測定したい 概念のごく一部の情報を表しているに過ぎない。  目的に対する答えを得る際には、複数のメトリクス により多面的に状況を把握する必要がある。 3.メトリクスは手段であって目的ではない  メトリクスの精緻化を図るあまり、「正確に誤っ て」しまわないよう注意が必要となる。 4.メトリクスを人の評価に使ってはいけない  正しい情報を入力しなくなり、情報を捏造するよう になる可能性が高くなる
  33. 33. 32redmine.tokyo ご清聴ありがとうございました 第10回勉強会, 2016-05-14

×