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