Recommandé
Contenu connexe
Similaire à Metrix team 20190524
Similaire à Metrix team 20190524 (20)
Metrix team 20190524
- 2. メトリクス分科会活動報告 ◼ ソフトウェアメトリクスの収集、分析、評価を研究 ◼ 報告内容 1. 事例１(岡本)： ◼ メトリクス収集の開発プロセスへの組込み例（社外データとのベンチマーク） 2. 事例２(築山)： ◼ メトリクス値の効果的な魅せ方（メトリクス自動収集とリアルタイム可視化の仕組み） 3. 事例３(野村)： ◼ 開発者目線のメトリクス収集法（コード品質の改善と慣習化） 4. 事例４(福田)： ◼ 定性的情報のメトリクスの活用法（アンケートデータの可視化） 5. 2017年度活動成果物(福田)： ◼ メトリクス日めくり（メトリクス収集のアンチパターン） 2
- 4. 4 組織としての課題・・・ 感覚的 バグ数が多い 品質が悪い 品質改善への気運が上がらない 製品品質の良し悪しが判断できない 品質改善への理解が進まない 解決策 課題 品質の見える化（定量評価）
- 6. 現場の状況とメトリクス収集への対策 取組前の現場の状況 メトリクスの基本 ＝ 規模 工数 欠陥 規模＝ 「かぞえチャオ」で規模測定 測定ルールなどを開発メンバーと相談して決定 欠陥＝ 開発プロセスを標準化、レビュー徹底、成果物を 規定することにより、各工程の欠陥検出数を取得 結果 取組 1プロジェクト分のメトリクスを取得 6
- 7. ベンチマークに使用したデータ比較方法 ベンチマークに使用したデータ比較方法 1標本のｔ検定（両側検定） 基準データ： １プロジェクトのメトリクスデータ 標本データ： ソフトウェア開発データ白書2016-2017 ◎検定の使用にあたり以下解釈を加えている 標本 基準有意差 論 じ る 対 象 論じたい対象 7 標本が基準と有意差あり ＝ 基準が標本と有意差あり 標本データが有意に高い ＝ 基準データが有意に低い 標本データが有意に低い ＝ 基準データが有意に高い
- 8. 収集したメトリクス 収集メトリクス数： 15 ※「実装」は未計測 静的解析ツールを導入し始めた時期でありそのエビデンスから実装工程の欠陥検出数 を取れないか検討段階であった メトリクス名 単位 S LO C （母体） S LO C 実効S LO C S LO C 工数 人時 工期 月 月当たりの要員数 人 各工程不具合検出数 （要件定義、設計、単体テスト、結合テスト、総合テスト）※ 件 流出不具合数 件 稼働後不具合数 件 各工程テストケース数 （単体テスト、結合テスト、総合テスト） 件 8
- 9. 検定対象メトリクス 検定対象メトリクス数： １４ カテゴリ メトリクス名 単位 プロジェクト要素 実効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. 1標本ｔ検定結果 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
- 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
- 17. 改善背景 ◼ システムテスト（第三者評価）チームの管理を担当 ◼ メトリクスを軸に業務改善を行った事例発表です ◼ 改善のきっかけは、上司からのミッション – メトリクスを使って業務効率を改善せよ – ただし、現場のテスト担当者の手は煩わさないこと そんな指示をうけて改善検討を始めました。 17
- 18. 効率改善のための検討 18 業務効率 = 成果 × 伝達度 投入工数 ◼ 効率改善のためには – 分母：投入工数を小さくする仕掛けを入れるか、 – 分子：伝達度を上げるしかない ◼ 分母：投入工数を下げるには – 不要な作業をなくす ◼ 毎週いろんなところに報告や資料作成を行っている ◼ 必要なデータがあちこちに散らばっている ◼ 分子：伝達度を上げるには – 作成した資料をまとめて見やすく可視化する
- 19. 効率改善の実現 19 必要なデータを自動で集めて、まとめて可視化！ ◼ 成果物はすべてデータベース＆リポジトリに集約 – テスト結果・バグ票・テスター工数 – 品質計画/予算・工数管理/日程計画等・・・ ◼ 自動集計システムを内作 – Django（python）・MySQL・Jenkins・Redmine – スクラム形式で徐々にスケールアップ ◼ 報告資料もシステムで自動生成 – 業務プロセスに合わせて様々なデータをクローリング – 週毎のスナップショットデータをプロジェクトごとに可視化 – EVM/PBチャート・週報・その他をダッシュボード化
- 22. 効果 22 ◼ 効率化アップの成果 – 進捗報告会議２時間⇒３０分。資料作成時間３０分⇒１分 – 担当者からの反発は ほぼゼロ – 浮いた時間で実務を充実へ ⇒ 分子：「成果」項のUP！ ◼ うまくいった理由 – 自動化できることは全て機械にさせた – 担当者にメトリクスを「報告」させなかった – きれいなデータが見えると、誰も文句を言わない – 周囲の要求を即座に反映させるアジャイル的開発を続けた ◼ 副次的効果（結果オーライ） – データが集約・整理されたことにより新たな分析が可能に – 計画の精度の悪さなど、今まで測れなかったものが見えてきた
- 26. 改善背景 ◼ 開発者が開発者のために行った改善事例 ◼ 改造開発でどのようにメトリクスを活用したかを紹介 26 品質 責任者 開発者 新規開発 改造開発(派生開発) この辺の話
- 27. 対象プロジェクトの特徴と課題 27 ◼ そこそこ長いライフサイクルを持つ製品を、 繰り返して機能追加を行っていくプロジェクトが対象 – 特定顧客向けのシステム（アプリ＋メカ制御） – 年間数回の改造案件（機能追加）が発生 – 言語：C/C++/C# – ステップ数：約1MStep – 製品ライフサイクル：約10年 ◼ プロジェクト課題は、度重なる改造によるアーキテク チャの崩壊、性能の低下、潜在不具合の表出などなど… 度重なる改造による品質の劣化
- 28. ◼ ソースコードベースのメトリクスを中心に採用 ◼ スナップショット と トレンド を組み合わせて効果的に 採用したメトリクス 28 メトリクス 説明 コード規模 全体および関数毎のステップ数を監視 関数の複雑度 関数の循環的複雑度を監視 コーディング規約 コーディング規約の違反数を監視 キーワードチェック コード中のコメントキーワード数を監視 関数の依存関係 アーキテクチャ間の依存ルール違反を監視 静的解析結果 静的解析ツールのチェック結果を監視
- 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 合計ステップ数 時系列（日単位） 関数名 ステップ数 前回 今回 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. メトリクス例：関数の依存関係 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
- 33. 改善の成果 33 ◼ 慣習化は実現！ – 実装ルールが守られることで、コード品質の劣化を抑制 – コードレビューも単純な指摘が減少し、より効果的なものに ◼ うまくいった理由 – 開発者目線のわかりやすいメトリクスを選定 – 直観的に修正作業を理解でき、誰もが改善に取り組める – 開発者に手間をかけずにメトリクスを自動収集 – 実装～指摘修正までのリカバリ時間を短くして面倒と思わせない – 品質情報が公開されているために自発的な修正が促される
- 34. 今後の課題 34 ◼ 本事例で改善できるのは、コードレベルの品質のみ – “仕様”に関する品質改善には、別の取り組みが必要 ◼ 品質が向上すると、開発チームから人が抜かれる！？ – より少ない人員でプロジェクトが回せると判断される – 結果、品質が悪化することも・・・ – リソースの標準化には別途メトリクスが必要 ◼ その他にも、課題はまだまだ山積み・・・
- 37. 組織の構造 37 全社 事業統括本部 事業本部 事業部 部門 プロジェクト プロジェクト プロジェクト 部門 事業部 事業本部 事業統括本部 部門 プロジェクト 数百～ 千本/年 所属部署 品質担保責任
- 38. ◼ 開発プロジェクトが失敗し、大きく赤字化 ◼ 工程移行判定をラインおよび第三者でレビュー ◼ 第三者による逐次状況チェック ◼ マネジメント不全/過少見積/計画不十分… 様々な原因 ◼ 報告上何の問題もなかったプロジェクトが、次のタイミング でいきなり赤字化していることがある ◼ プロジェクトメンバーに直接アンケートを取って、実情を 明らかにしよう プロジェクトの赤字化抑制策 38 どうにかして不芳化プロジェクトを減らさなくては でも。。。 ならば！
- 41. 更なる改善 41 ◼ 今後さらにやってみたいこと... – 今回は単独回の結果分析だったが、時系列の傾向推移から、ヤバさ 加減の変化が可視化できないか、ベイズ分類を試してみる – 人間では気づかない傾向を機械学習から導いてみる – 主成分分析して、どの項目の寄与度が高いか分析してみる、など まとめ： ◼ 定性情報でも工夫次第で定量化はできる、定量化できたら 統計手法も使えるし、グラフによる可視化もできる ◼ 測って分析してみれば、更に次のテーマが見えてくる ...最後は、昨年度活動成果のご紹介
- 42. 2017年度の活動成果 ◼ 「メトリクス日めくり」 – メトリクス収集してもなかなかうまく活用できない – 収集はしているけれど形骸化してしまってる ・・・こんな悩み、ありませんか？ 我々にもありました。 ・・・じゃあ、どうすればいいのか。。。 いっそのこと、「こりゃあかん」事例を集めちゃったら、 気を付けるべきことが見えてくるんじゃないか？ ⇒ アンチパターン集を作ってみよう！ だいたい30個ぐらい集まった、ならば、日めくりにしちゃおう！ どうせなら俳句風に標語にしちゃえば！ ってことで。。。 42
- 43. 2017年度の活動成果 ◼ 2017年度活動成果物：メトリクス日めくり – こんなもの作ってみました！ – どうやって公開するか、さらなるブラッシュアップを検討中！ 43