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.

Metrix team 20190524

323 views

Published on

ソフトウェア品質保証責任者の会 Re-born
第1回活動成果報告会 メトリクスチーム発表資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

Metrix team 20190524

  1. 1. ソフトウェア品質保証責任者の会Re-Born 活動報告会 2019年5月24日 メトリクス分科会 1 メトリクスを大いに語ろう ~測る、分かる、そして進化する!~
  2. 2. メトリクス分科会活動報告 ◼ ソフトウェアメトリクスの収集、分析、評価を研究 ◼ 報告内容 1. 事例1(岡本): ◼ メトリクス収集の開発プロセスへの組込み例(社外データとのベンチマーク) 2. 事例2(築山): ◼ メトリクス値の効果的な魅せ方(メトリクス自動収集とリアルタイム可視化の仕組み) 3. 事例3(野村): ◼ 開発者目線のメトリクス収集法(コード品質の改善と慣習化) 4. 事例4(福田): ◼ 定性的情報のメトリクスの活用法(アンケートデータの可視化) 5. 2017年度活動成果物(福田): ◼ メトリクス日めくり(メトリクス収集のアンチパターン) 2
  3. 3. メトリクス収集の 開発プロセスへの組込み例 ~社外データとのベンチマーク~ メトリクスチーム 岡本 泰尚 事例1) 3
  4. 4. 4 組織としての課題・・・ 感覚的 バグ数が多い 品質が悪い 品質改善への気運が上がらない 製品品質の良し悪しが判断できない 品質改善への理解が進まない 解決策 課題 品質の見える化(定量評価)
  5. 5. 5 課題解決への取組 取り組んだこと ソフトウェアメトリクスのベンチマーキング (ご参考)ベンチマーキング ・同じ分野の優れた事例との比較を通じて、改善すべき点を探し出す手法。 ・優れた競合他社やその他の優良企業のパフォーマンスと比較・分析する活動 目的 自社のソフトウェアメトリクスを他社データと比較し、 ギャップを認識することで、品質改善取組への意識向上、 取組強化を促進する。
  6. 6. 現場の状況とメトリクス収集への対策 取組前の現場の状況 メトリクスの基本 = 規模 工数 欠陥 規模= 「かぞえチャオ」で規模測定 測定ルールなどを開発メンバーと相談して決定 欠陥= 開発プロセスを標準化、レビュー徹底、成果物を 規定することにより、各工程の欠陥検出数を取得 結果 取組 1プロジェクト分のメトリクスを取得 6
  7. 7. ベンチマークに使用したデータ比較方法 ベンチマークに使用したデータ比較方法 1標本のt検定(両側検定) 基準データ: 1プロジェクトのメトリクスデータ 標本データ: ソフトウェア開発データ白書2016-2017 ◎検定の使用にあたり以下解釈を加えている 標本 基準有意差 論 じ る 対 象 論じたい対象 7 標本が基準と有意差あり = 基準が標本と有意差あり 標本データが有意に高い = 基準データが有意に低い 標本データが有意に低い = 基準データが有意に高い
  8. 8. 収集したメトリクス 収集メトリクス数: 15 ※「実装」は未計測 静的解析ツールを導入し始めた時期でありそのエビデンスから実装工程の欠陥検出数 を取れないか検討段階であった メトリクス名 単位 S LO C (母体) S LO C 実効S LO C S LO C 工数 人時 工期 月 月当たりの要員数 人 各工程不具合検出数 (要件定義、設計、単体テスト、結合テスト、総合テスト)※ 件 流出不具合数 件 稼働後不具合数 件 各工程テストケース数 (単体テスト、結合テスト、総合テスト) 件 8
  9. 9. 検定対象メトリクス 検定対象メトリクス数: 14 カテゴリ メトリクス名 単位 プロジェクト要素 実効K S LO C K S LO C プロジェクト要素 工数 人時 プロジェクト要素 月あたりの要員数 人 テスト工程別 S LO C テストケース密度(結合テスト) 件/K S LO C テスト工程別 S LO C テストケース密度(総合テスト) 件/K S LO C テスト工程別 S LO C 検出バグ密度(結合テスト) 件/K S LO C テスト工程別 S LO C 検出バグ密度(総合テスト) 件/K S LO C テスト工程別 S LO C 規模あたりのテスト工数(総合テスト) 人時/K S LO C テスト工程別 実績工数 ケース密度(結合テスト) 件/ 1,0 0 0 人時 テスト工程別 実績工数 ケース密度(総合テスト) 件/ 1,0 0 0 人時 テスト工程別 総合テストS LO C 生産性 S LO C /人時 生産性 S LO C 生産性 S LO C /人時 信頼性 S LO C 発生不具合密度(流出) 件/K S LO C 信頼性 S LO C 発生不具合密度(稼働後) 件/K S LO C 9
  10. 10. 1標本t検定結果 10 カテゴリ メトリクス名 単位 有意差 高低 弊社データ (対数) 標本平均 (対数) N (標本数) プロジェクト要素 実効KSLOC KSLOC なし - 2.99 2.71 142 プロジェクト要素 工数 人時 あり 高い 9.71 8.72 947 プロジェクト要素 月あたりの要員数 人 あり 高い 2.69 1.94 664 テスト工程別 SLOCテストケース密度(結合テスト) 件/KSLOC あり 高い 5.50 4.11 75 テスト工程別 SLOCテストケース密度(総合テスト) 件/KSLOC あり 高い 4.31 3.25 81 テスト工程別 SLOC検出バグ密度(結合テスト) 件/KSLOC あり 高い 2.99 -0.16 67 テスト工程別 SLOC検出バグ密度(総合テスト) 件/KSLOC あり 高い 2.06 -1.17 60 テスト工程別 SLOC 規模あたりのテスト工数(総合テスト) 人時/KSLOC あり 高い 3.67 3.08 543 テスト工程別 実績工数 ケース密度(結合テスト) 件/ 1,000 人時 あり 高い 5.69 5.08 986 テスト工程別 実績工数 ケース密度(総合テスト) 件/ 1,000 人時 あり 高い 4.50 3.93 961 テスト工程別 総合テストSLOC生産性 SLOC/人時 あり 低い 3.24 4.22 342 生産性 SLOC生産性 SLOC/人時 あり 低い 0.19 0.99 117 信頼性 SLOC発生不具合密度(流出) 件/KSLOC あり 高い 1.66 -2.95 27 信頼性 SLOC発生不具合密度(稼働後) 件/KSLOC あり 高い 0.93 -2.95 27
  11. 11. 工程別の不具合検出数 ※「実装」は未計測 静的解析ツールを導入し 始めた時期でありそのエビ デンスから実装工程の欠陥 検出数を取れないか検討段 階であった 11
  12. 12. SLOCテストケース密度とSLOC検出バグ密度 弊社プロジェクト 弊社プロジェクト 12
  13. 13. SLOC規模とSLOC発生不具合密度 弊社プロジェクト (流出不具合数) 弊社プロジェクト (稼働後不具合数) 13
  14. 14. 解決策の締めとして 役員クラス及び開発部門向けの報告会を開催 自社製品の品質を把握する きっかけ 開発における弱点がわかり 改善点の明確化 メ ト リ ク ス名 単位 有意差 高低 P値 実効KSLO C KSLO C なし - 0 .0 7 8 3 6 工数 人時 あり 高い 2 .2 0 E-1 6 月あたり の要員数 人 あり 高い 2 .2 0 E-1 6 SLO Cテスト ケース密度( 結合テスト ) 件/KSLO C あり 高い 5 .5 8 E-1 2 SLO Cテスト ケース密度( 総合テスト ) 件/KSLO C あり 高い 1 .4 5 E-0 8 SLO C検出バグ密度( 結合テスト ) 件/KSLO C あり 高い 2 .2 0 E-1 6 SLO C検出バグ密度( 総合テスト ) 件/KSLO C あり 高い 2 .2 0 E-1 6 SLO C 規模あたり のテスト 工数(総合テスト ) 人時/KSLO C あり 高い 2 .2 0 E-1 6 実績工数 ケース密度( 結合テスト ) 件/ 1 ,0 0 0 人時 あり 高い 2 .2 0 E-1 6 実績工数 ケース密度( 総合テスト ) 件/ 1 ,0 0 0 人時 あり 高い 2 .2 0 E-1 6 総合テスト SLO C生産性 SLO C/人時 あり 低い 2 .2 0 E-1 6 SLO C生産性 SLO C/人時 あり 低い 7 .8 2 E-1 1 SLO C発生不具合密度( 流出) 件/KSLO C あり 高い 2 .9 5 E-1 3 SLO C発生不具合密度( 稼働後) 件/KSLO C あり 高い 1 .4 1 E-1 1 検定 結果 各種 グラフ 今後のアクション ・要件定義、設計工程のレビュー 強化 ・単体テストの強化 ・継続したメトリクス収集 14
  15. 15. 事例1のまとめ メトリクスデータが少なくても世にあ るデータと統計手法を駆使することで 品質の見える化は可能。 スモールスタートでもまずアウトプッ トして改善に結び付けることができる ことを見せることが重要。 つづいて事例2の紹介です 15
  16. 16. メトリクス値の効果的な魅せ方 ~メトリクス自動収集とリアルタイム可視化の仕組み~ メトリクスチーム 築山 史郎 事例2) 16
  17. 17. 改善背景 ◼ システムテスト(第三者評価)チームの管理を担当 ◼ メトリクスを軸に業務改善を行った事例発表です ◼ 改善のきっかけは、上司からのミッション – メトリクスを使って業務効率を改善せよ – ただし、現場のテスト担当者の手は煩わさないこと そんな指示をうけて改善検討を始めました。 17
  18. 18. 効率改善のための検討 18 業務効率 = 成果 × 伝達度 投入工数 ◼ 効率改善のためには – 分母:投入工数を小さくする仕掛けを入れるか、 – 分子:伝達度を上げるしかない ◼ 分母:投入工数を下げるには – 不要な作業をなくす ◼ 毎週いろんなところに報告や資料作成を行っている ◼ 必要なデータがあちこちに散らばっている ◼ 分子:伝達度を上げるには – 作成した資料をまとめて見やすく可視化する
  19. 19. 効率改善の実現 19 必要なデータを自動で集めて、まとめて可視化! ◼ 成果物はすべてデータベース&リポジトリに集約 – テスト結果・バグ票・テスター工数 – 品質計画/予算・工数管理/日程計画等・・・ ◼ 自動集計システムを内作 – Django(python)・MySQL・Jenkins・Redmine – スクラム形式で徐々にスケールアップ ◼ 報告資料もシステムで自動生成 – 業務プロセスに合わせて様々なデータをクローリング – 週毎のスナップショットデータをプロジェクトごとに可視化 – EVM/PBチャート・週報・その他をダッシュボード化
  20. 20. 効率改善の実現 20 必要なデータを自動で集めて、まとめて可視化! 計画・報告
  21. 21. 効率改善の実現 21 自動分析されたデータ を見ながら原因・対策 の議論に集中
  22. 22. 効果 22 ◼ 効率化アップの成果 – 進捗報告会議2時間⇒30分。資料作成時間30分⇒1分 – 担当者からの反発は ほぼゼロ – 浮いた時間で実務を充実へ ⇒ 分子:「成果」項のUP! ◼ うまくいった理由 – 自動化できることは全て機械にさせた – 担当者にメトリクスを「報告」させなかった – きれいなデータが見えると、誰も文句を言わない – 周囲の要求を即座に反映させるアジャイル的開発を続けた ◼ 副次的効果(結果オーライ) – データが集約・整理されたことにより新たな分析が可能に – 計画の精度の悪さなど、今まで測れなかったものが見えてきた
  23. 23. 新たに可能になった分析事例 23 様々なデータがメトリクスで語れるようになった!
  24. 24. 事例2のまとめ 現場にデータをまとめさせて報告させ るスタイルは、結果的に組織力を削い でしまっているようです メトリクスデータは自動で取得して、 見やすく整えて、皆で利用できるよう にすべきですね つづいて事例3の紹介です 24
  25. 25. 開発者目線のメトリクス収集法 ~コード品質の改善と慣習化~ メトリクスチーム 野村 真也 事例3) 25
  26. 26. 改善背景 ◼ 開発者が開発者のために行った改善事例 ◼ 改造開発でどのようにメトリクスを活用したかを紹介 26 品質 責任者 開発者 新規開発 改造開発(派生開発) この辺の話
  27. 27. 対象プロジェクトの特徴と課題 27 ◼ そこそこ長いライフサイクルを持つ製品を、 繰り返して機能追加を行っていくプロジェクトが対象 – 特定顧客向けのシステム(アプリ+メカ制御) – 年間数回の改造案件(機能追加)が発生 – 言語:C/C++/C# – ステップ数:約1MStep – 製品ライフサイクル:約10年 ◼ プロジェクト課題は、度重なる改造によるアーキテク チャの崩壊、性能の低下、潜在不具合の表出などなど… 度重なる改造による品質の劣化
  28. 28. ◼ ソースコードベースのメトリクスを中心に採用 ◼ スナップショット と トレンド を組み合わせて効果的に 採用したメトリクス 28 メトリクス 説明 コード規模 全体および関数毎のステップ数を監視 関数の複雑度 関数の循環的複雑度を監視 コーディング規約 コーディング規約の違反数を監視 キーワードチェック コード中のコメントキーワード数を監視 関数の依存関係 アーキテクチャ間の依存ルール違反を監視 静的解析結果 静的解析ツールのチェック結果を監視
  29. 29. フィードバックの方法 29 メトリクス 違反数 今回(m/d h:mm) 前回(m/d h:mm) コード規模 15件 15件 関数の複雑度 0件 3件 コーディング規約 2件 0件 キーワードチェック 21件 21件 関数の依存関係 0件 1件 静的解析結果 14件 12件 プロジェクト ポータル http://reborn/project/index.html ◼ メトリクスはプロジェクトページへ自動的に収集 ◼ トップページだけで状況把握できるように工夫 ※サンプルイメージ それぞれの 詳細ページへ
  30. 30. メトリクス例:コード規模 30 合計ステップ数 時系列(日単位) 関数名 ステップ数 前回 今回 func_A() 32 OK OK func_B() 328 OK NG func_C() 96 OK OK func_D() 1172 NG NG func_E() 241 OK OK ○関数毎の閾値チェック ○合計ステップ数の変遷 ※閾値を 300ステップ に設定 変更が安定してきた まとまった 追加が発生 まとまった 削除が発生 ◼ コード規模のメトリクスは、古典的だが効果的 ◼ 関数~システム全体まで、収集単位毎でコントロール
  31. 31. メトリクス例:関数の依存関係 Driver Application Middle Library Algorithm App Alg Mid Lib Drv Application - - - - Algorithm 75 - - - Middle 23 13 - 5 Library 53 22 19 - Driver 3 - 35 28 ○アーキテクチャルール ○依存関係 背景色グレー:禁止の依存関係 ◼ アーキテクチャルールを監視して依存関係をチェック ◼ DSM分析ツールを利用したスクリプトを作成 31
  32. 32. 何が変わった? 32 改造開発の繰り返し ルールの逸脱 ソフトウェア構造の崩壊 不具合の誘発 スケジュールの逼迫 改善推進力の低下 ルールを常にチェック ソフトウェア構造を維持 不具合要因の排除 面倒くさくない方法 改善を慣習化して定着 負 の 連 鎖 正 の 連 鎖 改造開発の繰り返し ◼ 「負の連鎖」から「正の連鎖」に改善 ◼ 改善を慣習化し、改造開発による品質劣化を防止
  33. 33. 改善の成果 33 ◼ 慣習化は実現! – 実装ルールが守られることで、コード品質の劣化を抑制 – コードレビューも単純な指摘が減少し、より効果的なものに ◼ うまくいった理由 – 開発者目線のわかりやすいメトリクスを選定 – 直観的に修正作業を理解でき、誰もが改善に取り組める – 開発者に手間をかけずにメトリクスを自動収集 – 実装~指摘修正までのリカバリ時間を短くして面倒と思わせない – 品質情報が公開されているために自発的な修正が促される
  34. 34. 今後の課題 34 ◼ 本事例で改善できるのは、コードレベルの品質のみ – “仕様”に関する品質改善には、別の取り組みが必要 ◼ 品質が向上すると、開発チームから人が抜かれる!? – より少ない人員でプロジェクトが回せると判断される – 結果、品質が悪化することも・・・ – リソースの標準化には別途メトリクスが必要 ◼ その他にも、課題はまだまだ山積み・・・
  35. 35. 同じような悩みをお持ちの方 何から改善してよいかわからない方 会社の枠を越えて、解決方法を共に 探求してみませんか? つづいて事例4の紹介です 35
  36. 36. 定性的情報のメトリクスの活用法 ~アンケート情報を定量化する~ メトリクスチーム 福田 秀樹 事例4) 36
  37. 37. 組織の構造 37 全社 事業統括本部 事業本部 事業部 部門 プロジェクト プロジェクト プロジェクト 部門 事業部 事業本部 事業統括本部 部門 プロジェクト 数百~ 千本/年 所属部署 品質担保責任
  38. 38. ◼ 開発プロジェクトが失敗し、大きく赤字化 ◼ 工程移行判定をラインおよび第三者でレビュー ◼ 第三者による逐次状況チェック ◼ マネジメント不全/過少見積/計画不十分… 様々な原因 ◼ 報告上何の問題もなかったプロジェクトが、次のタイミング でいきなり赤字化していることがある ◼ プロジェクトメンバーに直接アンケートを取って、実情を 明らかにしよう プロジェクトの赤字化抑制策 38 どうにかして不芳化プロジェクトを減らさなくては でも。。。 ならば!
  39. 39. PJ状況アンケートの収集 39 プロジェクトの走行 実施 集計 対策 共有 ①アンケート実施 10項目4段階の評価記入 ②アンケート集計 回答者の何割がその項 目について「ヤバい」 と思ってるか度を算出 ④問題把握・対策 上長も入って対策実施 ③現場フィードバック・共有 一定閾値を超過したPJの 情報を還元 一定期間ごとに実施 メンバーの感覚を数値化できる 数値化すれば統計分析手法も使える
  40. 40. 統計分析例 40 ◼ 分析:「イケてるPJ」と「イケテナイPJ」では項目毎の 回答傾向に統計的有意差があるのか? – 回答項目の平均の差のt検定(有意水準5%)で分析してみる 項目1について、0:イケてるPJ、1:イケてないPJ 帰無仮説:平均に差はない、対立仮説:平均に差はある p値=0.001258(高度に有意差あり) ⇒感覚として持っていた、PJの 良し悪しが統計的にも示された。 他にも4項目で有意差が見られた
  41. 41. 更なる改善 41 ◼ 今後さらにやってみたいこと... – 今回は単独回の結果分析だったが、時系列の傾向推移から、ヤバさ 加減の変化が可視化できないか、ベイズ分類を試してみる – 人間では気づかない傾向を機械学習から導いてみる – 主成分分析して、どの項目の寄与度が高いか分析してみる、など まとめ: ◼ 定性情報でも工夫次第で定量化はできる、定量化できたら 統計手法も使えるし、グラフによる可視化もできる ◼ 測って分析してみれば、更に次のテーマが見えてくる ...最後は、昨年度活動成果のご紹介
  42. 42. 2017年度の活動成果 ◼ 「メトリクス日めくり」 – メトリクス収集してもなかなかうまく活用できない – 収集はしているけれど形骸化してしまってる ・・・こんな悩み、ありませんか? 我々にもありました。 ・・・じゃあ、どうすればいいのか。。。 いっそのこと、「こりゃあかん」事例を集めちゃったら、 気を付けるべきことが見えてくるんじゃないか? ⇒ アンチパターン集を作ってみよう! だいたい30個ぐらい集まった、ならば、日めくりにしちゃおう! どうせなら俳句風に標語にしちゃえば! ってことで。。。 42
  43. 43. 2017年度の活動成果 ◼ 2017年度活動成果物:メトリクス日めくり – こんなもの作ってみました! – どうやって公開するか、さらなるブラッシュアップを検討中! 43
  44. 44. メトリクス分科会活動報告 ご清聴ありがとうございました! ぜひ、私たちと一緒に、メトリクスを語ってみませんか? 同志をお待ちしています! 44

×