cmmi成熟度レベル別に見たソフトウェア品質の良否に関わ …ml2:ノード3...

CMMI成熟度レベル別に見たソフトウェア品質の良否に関わる要因の複合的分析

2017年11月15日

日本電気（株）柳田礼子

2 © NEC Corporation 2017

狙い

品質の良否に影響する要因について複数の要因の関係を成熟度レベル毎に分析

成熟度レベルに応じた効果的な対策を実行することで出荷後品質を向上させる

背景当社は品質第一を掲げている品質の良し悪しに影響を与える要因は単一ではない場合が多い成熟度レベルを向上させるためには多くの労力と期間を要する


▌対象プロジェクト

特定顧客向けのシステムインテグレーションプロジェクト

2014年度に開発完了

ウォーターフォール（V字）モデルを適用

▌分析対象件数

分析対象データ

成熟度

レベル(ML)

プロジェクト

件数

ML１との

達成率の差※

1 317 -

2 138 +13.3pt.

3 67 +21.8pt

合計 522 -

(※)出荷後バグ密度(件/KL)実績値を、予め定めた所属組織の品質基準と比較してSW品質の良否を判断⇒ プロジェクトを「達成」と「未達」に分類⇒ 各成熟度レベルの「達成率」を「達成」件数/プロジェクト合計件数で算出

表の数値は、成熟度レベル1の達成率(％)を基準としたポイントの差の値

成熟度レベルが上がるにつれて達成率が向上


メトリクス

▌成熟度レベル(ML)別のメトリクスの値

（対応するメトリクス全体の平均値で割った相対値）

メトリクス単位ML1 ML2 ML3

達成未達達成未達達成未達

開発規模 KL .309 .662 .184 .661 .144 .217

上工程バグ摘出率％ 1.071 .996 .986 .950 .983 .942

上工程工数/KL 人時/KL .708 .537 .773 .776 .835 .834

テスト工程工数/KL 人時/KL .446 .344 .778 .968 .650 .845

上工程レビュー工数/KL 人時/KL .757 .620 .647 .737 .631 .477

テスト項目数/KL 件/KL .626 .537 .534 .620 .951 .634

上工程バグ数/KL 件/KL 1.084 .822 .595 .787 .672 1.220

テスト工程バグ数/KL 件/KL .595 1.142 .773 1.142 .744 1.542

開発規模、テスト工程バグ数は、一貫して未達の方が値が大きい上工程バグ摘出率は、一貫して未達の方が値が小さい


分析の流れ

ステップ①

ステップ②

ステップ③

CARTアルゴリズムに基づいて分類木を構築・レベル１と２では分類木が構築された ⇒②・レベル３は分類木が構築されず ⇒③

②-1. 分類木に現れなかった他のメトリクスにおいて順位和検定②-2. 両側検定でｐ値5%未満となったメトリクスを,分類木で選

択されたメトリクスに加えて相関分析

③-1. 全メトリクスについて「達成」と「未達」の有意差を検定③-2. 最もp値の小さかったメトリクスに着目し、テスト工程の

工程別の値を比較


ステップ①：分類木分析

ML１,２では開発規模が大きくなると品質悪化の傾向がある.ただし,ML２はML１と比較すると、約4倍の開発規模のプロジェクトまで品質を制御することが可能.

開発規模

1

0.101 0.101

上工程バグ数.KL

2

0.349 0.349

上工程バグ摘出率

3

0.922 0.922

Node 4 (n = 43)

10

00.2

0.40.60.8

1Node 5 (n = 165)

10

00.2

0.40.60.8

1Node 6 (n = 42)

10

00.2

0.40.60.8

1Node 7 (n = 67)

10

00.2

0.40.60.8

1

開発規模

1

0.463 0.463

テスト工程バグ数.KL

2

0.869 0.869

上工程レビュー工数.KL

3

0.403 0.403

Node 4 (n = 12)

10

00.20.40.60.81

Node 5 (n = 8)

10

00.20.40.60.81

Node 6 (n = 25)

10

00.20.40.60.81

Node 7 (n = 93)

10

00.20.40.60.81

成熟度レベル1の分類木成熟度レベル2の分類木


ステップ②：有意差検定と相関分析（ML１、ML２）

ML1は,設計品質が悪く、レビューでもテストでも適切にバグ摘出できていないPJが多い.ML2では,レビューに十分工数を投入することでテストでの摘出バグを低く抑え,結果的に品質確保できているPJがある.

対象ノード分析結果の考察

ML1:ノード3 上工程でバグが多く摘出されるとテストでも多く摘出

ML1:ノード6 テストの工数は項目数に比例した安定したテストを実施

ML1:ノード4 設計品質が悪く,レビューで摘出が容易なバグが多く混入し,テストでも十分にバグ摘出できていない

ML1:ノード5 設計品質が悪くても,レビューおよびテストで一定水準のバグを摘出

ML2:ノード3 レビューで摘出が容易なバグが多く混入し,テストでも十分にバグ摘出できていない

ML2:ノード6 「達成」では,上工程レビューに十分工数を投入し,テストでのバグ数が減少している

※ML2のノード4とノード5は、データ件数が少ないため分析対象外


ステップ③：工程別データの有意差検定（ML３）

徐々に積み残されたバグがST工程で検出され,工数不足となって十分に品質を確保できないまま出荷している場合に「未達」となる傾向がある.

分類木が構築されないため、全メトリクスについて「達成」と「未達」の中央値を有意差検定

⇒「テスト工程バグ数/KL」が最もp値が小さい(0.087)

⇒テスト工程に着目してさらに工程別に中央値比較

メトリクス p値達成未達

UT工程テスト工数/KL .945 .677 .532

IT工程テスト工数/KL .812 .488 .587

ST工程テスト工数/KL .338 .456 1.271

UT工程テスト項目数/KL .702 .584 .392

IT工程テスト項目数/KL .621 .420 .278

ST工程テスト項目数/KL .888 .400 .372

UT工程テストバグ数/KL .134 .578 1.160

IT工程テストバグ数/KL .494 .583 1.014

ST工程テストバグ数/KL .006 .000 2.357

工程別の中央値

※UT：単体テスト IT：結合テスト ST：システムテスト

工数は工程が進むにつれて「未達」は増加,「達成」は減少

テスト項目数は全工程に亘り「未達」は「達成」より少ない

バグ数は全工程に亘り「未達」は「達成」より多い

（ST工程は有意差有）


まとめ

成熟度レベル

分析結果考察

１中規模以上の開発で品質悪化.

中規模以上の開発で,設計品質が悪く,上工程バグ摘出率が低い場合,上工程でも品質確保されず,テスト工程においても十分なバグを摘出不可.

品質は予測不能である.まずは,基本的な開発管理技術の教育,適用が必要である.

２大規模の開発では品質悪化.(成熟度レベル1の約4倍の規模までは品質を制御可能)

大規模の開発においても,上工程レビューに十分な工数を投入することにより一定の品質を確保し,テストでの検出バグを低く抑え,結果的に品質確保できているPJがある.

プロセスを標準化して展開し,組織内のプロジェクトの品質底上げを図ることが求められる.

３徐々に積み残されたバグがテスト終盤で検出され,工数不足となり十分に品質確保できないまま出荷している場合に「未達」になる傾向がある.

実績値をより高い頻度で把握したタイムリーなマネジメントが重要である.


今後に向けて

【 Future Work 】• 分析結果を基にした管理基準の設定、適用、効果測定• データの欠損、偏りの影響を考慮した分析

品質の良否に影響する要因について複数の要因の関係を成熟度レベル毎に分析

・CMMIの成熟度レベルで述べられていることがデータで実証された・出荷後品質に影響する複数の要因について知見が得られた

cmmi成熟度レベル別に見たソフトウェア品質 の良否に関わ …ml2:ノード3...

Documents

cmmi成熟度レベル別に見たソフトウェア品質の良否に関わ …ml2:ノード3...