Empirical Project Monitorの紹介
- 2. トヨタ流改善「見える化」 • 見える化は一言で言えば，問題点が常に「見える」 ようにしておく工夫のことである。正常と異常の違い がすぐに分かる仕事場とか，仕事するうえであれこ れ迷わずに済む現場のことを指すと言ってもいいか もしれない。 • IT業界もトヨタ流企業改革から始めてみては？ – http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/200401 23/138653/ TOYOTA 2
- 8. EPMの分析機能 • 履歴分析 – 履歴の可視化(行数、更新/参照数、メール数、障害数/ 滞留時間) – SRGM(信頼度成長モデル) – ロジカルカップリング(同時更新ファイルの検出) – プロジェクト遅延リスク検出モデル出力 (不安定要求/不完全設計/劣悪コード) • 統計分析 – パレート図 – クロス分析 – 散布図(はずれ値の分析) 8
- 9. Empirical Project Monitorのシステム構成 9 構成管理 履歴 メール 履歴 不具合 履歴 標準化エンピリカルデータ(XML形式) PostgreSQL(Repository) CVS, Subversion, popper(メールクライアント), GNATS, 影舞、など その他: - 予定値 - 工程情報 開発者 管理者 開発者 管理者 Rubyスクリプト Java Java 個別分析，関連分析 既存ツール Translater Importer Analyzer
- 10. Empirical Project Monitorの特長 • (プロダクト生成以前に)リアルタイムに開発者 の振る舞いを知ることができる • オープンソース開発にも使われているツール を利用 – データ収集の負荷がない(透過的) • 人為的操作の少ないデータを分析 10
- 11. 機能紹介
- 14. ソースコードの規模 • 開発の進捗に最も関わるメトリクス • 一般に右上がりになり，生産性が高いほど傾 きが急になる • コーディングの工程で規模が増えることは， 開発が順調であると考えられる • テスト工程で規模が増えているなら，仕様や 構造の問題が発生しているかもしれない • テスト終盤で，ソースコードが更新されている なら，詳細情報を確認したほうが良い 14
- 16. メール詳細情報一覧
- 17. メール情報 • プログラムを更新時，障害発生時には，情報 交換のメールの投稿数が増える(ことが多い) • メールデータはソース更新中や障害対応検 討中でもリアルタイムに変化する • ソースや障害に直接関係のない問題であっ ても補えられる可能性がある • サブジェクトや関係者を特定できる 17
- 19. 障害情報 • 累積障害件数 – 傾きが急な場合は短期間に多くの障害が発見されている – テスト工程の終盤で傾きが水平にならない場合は，信頼 性に問題があるかもしれない • 未解決障害件数 – 解決できていない不具合を示す – 未解決の障害が多数残っているなら，試験項目消化後も 多くの作業が必要になるかもしれない • 平均障害滞留時間 – 障害を解決するために要した一件あたりの時間を示す – 解決できない問題があると大きくなる 19
- 20. パレート図 20
- 21. パレート図 • QC７つ道具のひとつ． – パレートの法則(一般に不良全体の80％は，20％の原因 に由来する)に基づく • 左の目盛りと棒グラフは件数，右の目盛りと折れ線 グラフは累積の比率を示す – 件数の多いものから並んでいる • 重要な要因が明確になり，対策をとると効果的な要 因がわかる • CVSやメールから，作業が誰に集中しているかがわ かる • 障害データからは，障害の傾向がわかる 21
- 22. クロス分析 22
- 23. クロス分析 • 2次元の要因ごとに，棒グラフ，折れ線グラフ ， バブルグラフで示す • 要因間の関係がわかるので，対策の検討が 容易になる 23
- 24. サブシステムー本来発見すべき工程 • 青はコーディング工程で発見すべき障害が多い • 黄はコーディングと詳細設計で発見すべき障害が多い • コードレビューまたは詳細設計でレビュー強化すべき 24 青 黄
- 25. 重要度ー本来発見すべき工程 • コーディング/単体テスト工程に重要度大の障害が多い • コードレビューは(青だけでなく)，開発標準とすべき • 詳細設計は重要な問題が少ない 25
- 27. SRGM(信頼度成長モデル) • “Software Reliability Growth Model”の略 • ソフトウェア信頼性を評価するためのモデル の一つ • 総バグ予測数，残存バグ予測数，バグ収束 予測日を算出することができる • 試験項目に対して，障害(バグ)がほぼ均質に 分布することが前提になっている 27
- 28. 28
- 31. ご協力のお願い • IPAではEPMの最新版をご提供するととも に共同検証をお願いしています – 共同検証には以下の2種類があります 1. 実運用し、分析結果をご報告いただく(メール等支援 あり) 2. 評価と感想(コミュニティML提供) – ぜひ、実運用にご協力ください 31
- 32. おわり
- 33. SRGMグラフの凡例 項目 凡例で表示されている文字列 意味 プロジェクト "demo.empirical-unet.ocn.ne.jp: EmpiriPrj"などのプロジェクトID 選択したプロジェクトを識 別するもの モデル ExponentialModelImpl 指数形のモデル ModifiedExponentialModelImpl 修正指数形のモデル DelayedModelImpl 遅延S字形のモデル InflectionModelImpl 習熟S字形のモデル 最大・最小限界値 Max 最大限界値 Min 最小限界値 （空白） 平均値 危険率（有為水準） 5%，2%または1% どの危険率で検定に合格 したか識別するもの 33