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

0 redmine.tokyo

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

～メトリクス概要とよく使われるメトリクス～

2016年5月14日

大和田裕 (@yohwada)

第10回勉強会, 2016-05-14

1 redmine.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書籍)

2 redmine.tokyo

ソフトウェアメトリクスとは

第10回勉強会, 2016-05-14

ソフトウェアメトリクス（メトリクス）様々な活動を定量化し、その定量化したデータを管

理（マネジメント）に使えるように加工した指標。

ソフトウェア開発プロセス、資源、成果物の実態がソフトウェアを開発するという点から見て適当であるかどうかを計測し、予測するための手段。

ソフトウェアを対象とした計測方法・（定量的評価）尺度，もしくは，計測・評価の結果。

メトリクス管理加工して作ったメトリクスを使って管理（マネジメ

ント）すること。

3 redmine.tokyo

ちょっと余談

第10回勉強会, 2016-05-14

管理の意味範囲を限定し維持・統制する。（上から下へ統制す

ることが前提）

マネジメントの意味組織や団体、人が存続・発展するための全ての活動。様々な資源や資産・リスクなどを管理し、経営上の

効果を最適化しようとする手法のこと。成果を出せるような環境や状況を作り出すこと。

マネジメント≠管理マネジメントは、”管理”という意味合いの他、”評

価・分析・選択・改善・発展・回避・統合・計画・調整・指揮・統制・組織化”などを含んでいる。

4 redmine.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）ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守

5 redmine.tokyo

メトリクスの枠組み

第10回勉強会, 2016-05-14

基本測定量測定を行って直接結果が得られる要素データ導出測定量要素データを組合せ、計算することによって結果が得られる指標

6 redmine.tokyo

メトリクスの目的

第10回勉強会, 2016-05-14

ソフトウェア開発プロジェクトを成功に導きたいし、ソフトウェアの品質を良くしたい。さらにソフトウェア開発の生産性を一層向上させたい。つまりソフトウェア開発の過程などを制御して、より良いソフトウェアと、そのソフトウェアを開発するより良い方法を手に入れたい。

ソフトウェア工学の領域での重鎮の一人であるトム・デマルコ（Tom Demarco）は、その著書の中で「測定できないものは制御できない」と言った。

デマルコの言葉が正しいとすれば、ソフトウェアそのものと、ソフトウェア開発に関わるいろいろな側面についての計測を行わなければならない。

端的に言えば、これがソフトウェアに関する事項を測定すること、つまりメトリクスの目的。

7 redmine.tokyo

ちょっと余談

第10回勉強会, 2016-05-14

メトリクスとメトリクス管理は「計測による制御」が前提

結果が予測出来ない試行錯誤を伴うまったく新しい概念のプロダクトやプロセスへの適用は、ほとんど意味がない。

• プロジェクトA: 1,000万円のコストを使って 1,100万円の価値を作る。「計測と制御」が有効

• プロジェクトB: 1,000万円のコストを使って5億円以上の価値を作る。「計測と制御」で語れる部分の「外側」が重要

8 redmine.tokyo

メトリクス・タイプ(1/4)

第10回勉強会, 2016-05-14

数値（Number）計測により対象から直接的に得られる数値。

例：ソースコード行数(Lines of Code)，ファンクションポイント数(FP)，バグ数。

属性（Attribute）計測対象の特性。〇〇度，△△性，といった表現が用いられる場合が多い。

例：プログラム複雑度，耐故障性。

モデル（Model）計測対象の構造や具体的な計測手順などを示した，理論やデータに基づくモデル。

例：ソフトウェア信頼度成長モデル。

9 redmine.tokyo


第10回勉強会, 2016-05-14

尺度（Scale）対象を分類するための枠組み・基準。

比例尺度：数値の差と共に数値の比にも意味がある例：身長、体重、金額、絶対温度、工数変化率

体重は50kgから60kgになったときと、100kgから110kgになったときとは、同じ10kgの増加であっても、前者は20％増、後者は10％増です。また、比が定義できるということは絶対零点を持つことと同じことを表します。

10 redmine.tokyo


第10回勉強会, 2016-05-14

間隔尺度：数値の差のみに意味がある例：摂氏温度，速度、バグ数

温度が10℃から15℃になったときに、50％の温度上昇があったとはいいません。温度が10℃から15℃になったときも、100℃から105℃になったときも、ともに５℃の温度上昇です。そして、５℃という数値には意味があります。

順序尺度：値の大小関係だけに意味がある例：階級（ヘビー、ウエルター、ライト）、故障の重要度（軽微、普通、重要）

故障の重要度において、軽微・普通・重要を、それぞれ１・2・3と数値に対応させたもの。平均値は定義できないが中央値は定義できます。

11 redmine.tokyo


第10回勉強会, 2016-05-14

名義尺度：観察される変数と数値を対応させる（分類として記号の意味を持つのみ）例：血液型，発生工程に基づくバグ分類，故障重大度の5段階評価基準。

血液型でＡ型・Ｂ型・Ｏ型・AB型を、それぞれ0・1・２・3と数値に対応させたもの。これらの変数の平均値を求めてもまったく意味がありません。

12 redmine.tokyo

メトリクスの分類

第10回勉強会, 2016-05-14

プロダクト（成果物）メトリクス開発の結果得られたものドキュメント、プログラム、テストデータ等

プロセスメトリクス成果物を作り出すための作業ライフサイクルの全てのフェーズ（要求分析、設計、コード、テスト、品質保証等）

リソース（資源）メトリクス開発作業の入力となったもの

HW、SW、ドキュメント、人的資源、知識等

13 redmine.tokyo


第10回勉強会, 2016-05-14





14 redmine.tokyo

プロダクトメトリクス(1/2)

第10回勉強会, 2016-05-14

プロダクト（成果物）の複雑さモジュール結合度、モジュール凝集度、ファンクションポイント、C&Kメトリクス、Software Science by Halstead、サイクロマチック数

プロダクト（成果物）の量ドキュメント・ページ数、ソースコード行数、ファンクションポイント数、テスト項目数

15 redmine.tokyo

プロダクトメトリクス(2/2)

第10回勉強会, 2016-05-14

プロダクト（成果物）の質故障数、欠陥数（バグ数）、単位時間あたりの故障数（故障率）、ソースコード1,000行あたりの欠陥密度（バグ密度）、テストケース網羅率

16 redmine.tokyo


第10回勉強会, 2016-05-14





17 redmine.tokyo

プロセスメトリクス

第10回勉強会, 2016-05-14

各フェーズにおける活動を測定時間、工数、工期、コスト、生産性、レビュー効率、欠陥除去率、関連イベントの有無、関連イベントの発生回数例：顧客との対話時間やインタビュー回数、仕様書レビューに要した工数

18 redmine.tokyo


第10回勉強会, 2016-05-14





19 redmine.tokyo

リソースメトリクス

第10回勉強会, 2016-05-14

投入・消費される資源を測定開発要員数、作業単価、スキルレベル、開発用マシンスペック、使用ツール

20 redmine.tokyo

メトリクス管理サイクルプロジェクトの進捗，課題・障害の解決状況，工数等の把握を定量データにより行い問題の早期発見と対応を可能にすることにより、迅速かつ効果的なプロジェクトのPDCAサイクルを実現する。

プロジェクト

計画(P) 実施(D)

診断(C) 対策(A)

最適な計画の立案

スケジュール、計画工数、

レビュー計画、品質計画..

進捗実績、工数実績、レビュー実績

障害・課題データ..

動的分析データの提供プロジェクト状況データの

フィードバックと情報共有

プロジェクト課題やリスクの早期発見

問題対応と計画への

フィードバック

プロジェクト状況の把握

第10回勉強会, 2016-05-14

21 redmine.tokyo

メトリクス管理の期待効果(1/4)

第10回勉強会, 2016-05-14

1.可視化ソフトウェア及びプロジェクトの可視化。

代表的な対象：プロダクト（成果物）、プロジェクトの進捗、プロセスの質

プロダクトの主な可視化対象規模、品質、構成要素、構成要素間の関係

プロジェクト進捗の主な可視化対象投入済み工数（コスト）とマイルストーンの達成状況

テスト工程の主な進捗把握対象成功テストケース数、未消化テストケース数、欠陥発見数、修正未了欠陥数などの時系列データ

プロセスの質の主な可視化対象各アクティビティに費やした工数と、当該アクティビティで発生した事象（欠陥の作り込みと除去など）

22 redmine.tokyo


第10回勉強会, 2016-05-14

2.予測ソフトウェアとプロジェクトが可視化できると、データに基づいた予測が可能となる。

代表的な対象：プロジェクトの工数、プロダクトの規模、プロダクトの品質

仕様書からファンクションポイントを測定できれば、最終プロダクトの規模（KLOC）や開発工数を予測できる。

プロジェクトの進捗状況が可視化できれば、プロジェクト終了時期と最終コストを予測できる。

プロダクト品質及びプロセス品質が把握できれば、最終プロダクトに残存する欠陥数を予測できる。

プロダクト及びプロセスのメトリクスを組み合わせて、欠陥が作り込まれる可能性が高いモジュールを特定することもできる。

23 redmine.tokyo


第10回勉強会, 2016-05-14

3.計画定量データが蓄積されれば、過去の実績及び予測に基づいた計画を立案できる。

代表的な対象：プロジェクトに含まれる各アクティビティと、その所要工数及び実施時期。レビューやテストなどの欠陥除去工程において、何件の欠陥を除去目標とするのかといった品質計画

24 redmine.tokyo


第10回勉強会, 2016-05-14

4.改善対象の特定定量的マネジメントの分解能が高くなると、プロセスの弱みやプロジェクトの弱みを定量データにより明確化できるようになる。

設計レビューの欠陥除去能力を詳細に分析すると、設計レビューで除去すべき欠陥をどのくらい見逃しているのか、見逃した欠陥はどのような種類が多いのかを定量データで示すことができ、欠陥見逃し原因の特定に役立てることができる。

テスト工程における欠陥発見数の累積値が一定のパターンにならない場合には、テストケース設計に問題があるのか、テスト実施プロセスに問題があるのか、テスト可能コードが断続的に引き渡されているのかなど、改善すべき原因の特定が期待できる。

25 redmine.tokyo

基本測定項目

第10回勉強会, 2016-05-14

プロジェクトをコントロールするための必要最小限の測定項目（指標）

作業（作業要素）：作業規模の指標スケジュールでは矢印などであらわされている必

要となる作業（タスク）作業成果物：開発規模の指標プロジェクトの活動を通じて作成されるドキュメ

ント、コード等のアウトプット障害・課題：品質の指標開発中に発生した障害や課題

工数：リソースの指標メンバーがどのような作業にどのくらい時間を

使ったのかを測定

26 redmine.tokyo

メトリクス(分析)の種類

第10回勉強会, 2016-05-14

１．リアルタイムメトリクスある時点で得られる、および得られたメトリクスから計算で得られるデータを分析する。

２．ヒストリカルメトリクス時系列にメトリクスを蓄積し、推移を分析する。

３．予測メトリクス上記１．２．より将来予測／将来計画設定・変更を行う。

27 redmine.tokyo

よく使われるメトリクス(分析) (1/3)

第10回勉強会, 2016-05-14

１．進捗タスク／アクティビティ進捗率進捗率推移タスク／アクティビティ実績工数実績工数推移 EVM

２．品質バグ件数（発生、修正）推移バグ発生率（バグ件数／規模）バグ検出率（バグ件数／テスト項目数）バグ収束率（総バグ件数／バグ予測件数）信頼度成長曲線障害原因分類

28 redmine.tokyo


第10回勉強会, 2016-05-14

３．試験テスト項目密度（テスト項目数／規模）テスト項目消化率（実施テスト項目数／予定テスト項目数）テスト項目消化数推移テスト項目網羅率

４．課題未完了課題数課題解決時間

５．レビューレビュー項目密度（レビュー項目数／規模）レビュー項目消化率（実施レビュー項目数／予定レビュー項目

数）レビュー指摘分類

29 redmine.tokyo


第10回勉強会, 2016-05-14

６．アジャイルバーンダウンチャートベロシティサイクルタイム累積フロー図(Cumulative Flow Diagram)

７．チケット未完了チケット件数、件数推移最大放置日数、日数推移平均完了日数、日数推移

30 redmine.tokyo

メトリクス管理の留意点(1/2)

第10回勉強会, 2016-05-14

1.目的と整合性のとれたメトリクスを用いる有益な情報を提供できるメトリクスを定義し、運用する。

GQM (Goal–Question–Metric)手法などを用いて、目的とメトリクスの整合性を確認する。

測定の目的は、測定データの提供者に共有されていること。

組織または個人に対してどのような有益なマネジメント情報が得られたのかを、データ提供者にフィードバックする。

31 redmine.tokyo

メトリクス管理の留意点(2/2)

第10回勉強会, 2016-05-14

2.メトリクス情報は、測定したい概念の一部分実世界の測定によって得られる情報は、測定したい概念のごく一部の情報を表しているに過ぎない。

目的に対する答えを得る際には、複数のメトリクスにより多面的に状況を把握する必要がある。

3.メトリクスは手段であって目的ではないメトリクスの精緻化を図るあまり、「正確に誤って」しまわないよう注意が必要となる。

４.メトリクスを人の評価に使ってはいけない正しい情報を入力しなくなり、情報を捏造するようになる可能性が高くなる

32 redmine.tokyo

ご清聴ありがとうございました

第10回勉強会, 2016-05-14