不具合密度という指標

途中でネタ切れになるかもしれませんが、最初くらいは、はかることをテーマにしたいので時事ネタでも何でもありませんが計測の話を書きたいと思います。

ソフトウェア開発中のソフトウェア品質を計測する指標の1つとして、不具合の検出密度（単位ソースコード行数あたりの検出不具合（バグ）の数）を測るのは比較的浸透しているようです。特にウォータフォールモデルのエンタープライズ系開発では一般的なようです。そういうことをするから最初からバグを作りこんでしまう態度ができてしまうからダメだ等いろいろな意見があると思いますが、そのあたりはまた今度の機会に議論することにさせていただくとして、一定行数のソースコードに含まれるバグの数がある一定の範囲にあるという仮定に立つと、不具合の検出密度（不具合密度）は品質の指標となり得ます。

プログラミング言語によりますが、1,000行あたりの密度(検出不具合数/KLOC)を指標とし、機能毎に集計するなどして、指標が一定範囲内に入っていることにより、品質が保たれているかどうかの1つの判断基準にします。私も自分のプロジェクトのソースコードに対して計測していたことがあります。進捗会議等でこの指標を使って、異常値や範囲内に入っていないものがみつかれば、原因を検討し、対処するという使い方をします。もちろん、この値だけで全てを判断するのではなく、あくまで参考値ということですが。

この不具合密度が業種/業態によってかなり受け止められ方が違うようで、その話はまた別途書きたいと思います。