品質メトリクス　－バグ密度／欠陥密度－

システム構築における品質管理では、品質を定量的に分析・評価することが重要である。そしてシステム構築のなかのソフトウェア開発部分については、テスト密度やバグ密度などの品質メトリクスを使って、それら指標値の計画値と実績値を比較・評価するということが一般的に行われている。
ソフトウェアの品質に関してはJISの規約や経済産業省の資料などがあり、例えば、「バグ」という言葉は使用せず、開発工程における不具合を「欠陥」、本番リリース後の不具合を「障害」と定義するなどの例がみられる。そして品質メトリクスとして、「テスト密度」や「テストカバレッジ」、「欠陥密度」、「欠陥除去率」などが定義されている。
しかし、実際のところはSIベンダー毎に、それぞれメトリクスの定義（方言）があり、過去のプロジェクトの実績値から計画値を導出するというのが一般的である。
従って、ソフトウェア開発の現場では、使用する品質メトリクスとその基準値は各ベンダー毎に異なっているというのが実情だ。
過去のプロジェクトの実績値はそのベンダーの資産であり、品質のみならず見積もりや開発スケジュールを立てるうえでの基準となる。
品質メトリクスの参考図書に、「ソフトウェア開発データ白書 2014-2015」（IPA：独立行政法人情報処理推進機構）がある。これは国内企業29社、3,541件のプロジェクトデータを統計処理したものだから、品質計画を策定する時や品質評価をする際の参考になるだろう。
但し、回帰式から導出した数値などは、それを鵜呑みにせず、自社の数値と比較したり、相関係数で数値の信頼性を確認するなど、数値の取り扱いには注意が必要である（当該図書にもその旨の注意書きがある）。
「ソフトウェア開発データ白書」では、大きく「FP（ファンクションポイント）規模」と「SLOC（コード行数）規模」に分け、それぞれのメトリクスとその数値が掲載されている。例えば、発生不具合密度であれば、「FP発生不具合密度」と「SLOC発生不具合密度」に分けて数値が出ている。
昨今の業務系システムの開発は、新規開発案件よりも改修案件が多いと思われる。本書に収集されているプロジェクト・データを見ても、新規開発42.1%、改修・保守37%、拡張16.2%、再開発4.7%となっている（本書では改修・保守と拡張を合わせて改良開発と称している。改良開発は53.2%になる。）。
そうなると改修案件（本書でいう改良開発案件）の場合の品質指標値が必要になるわけだが、本書では「母体は含まない」と書かれている。
一般に改修案件のバグは、改修部分だけでなく、改修が母体に影響を与える範囲にも関係してくると考えられる。従って、バグ密度は改修規模だけでなく、母体の影響範囲の規模も勘案する必要があるが、残念ながら本書ではそこまでの分析データはない。
改修案件の場合、バグ密度だけでなくテスト範囲が大きな問題になる。改修部分をテストするのは当たり前として、母体のどこまでをテストするのかが問題になるだろう。
母体のうちの影響範囲に限定してテストを行うのか、母体全てに対してテストを行うのか。論理的には影響範囲のみで良さそうだが、影響範囲を見誤ることもあるから、対象システムがミッション・クリティカルなほど、より広い範囲のテストを求められるであろう。
本書から新規案件と改修案件のバグ密度を比較してみる。工程は、結合テストと総合テストである。
改修案件は、母体の影響範囲で発生するバグ（いわゆるデグレ）がある分、新規開発よりもバグ密度が高いと考えられるが、データを見ると必ずしもそうとは言えないようである（ただし、総合テストのバグ密度を平均値で見ると、総じて改修案件の方が新規案件よりも高い数値を示している）。

ソフトウェア開発データ白書には、FP（ファンクションポイント）規模あたりの検出バグ数も出ているので、参考までに引用しておく。FPはIFPUGグループのものであり、FP規模は調整前の機能規模（未調整ファンクションポイント）を使用している。