ソフトウェア開発分析データ集2022を試験密度や不具合密度の目標値を考える

こんにちは。深緑です。

ただいま担当PJでさあ試験するぞ！という段階にあります。
私の周りでは試験密度や不具合密度の目標値を決めてから試験をするようにしています。

参考にするページ

先日、ソフトウェア開発分析データ集2022が発行されましたので今回はこれを参考試験密度や不具合密度の目標値を考えていきます。
私は各種指標値の測定にステップカウントを使っていますので、ズバリ57〜63頁を参考にします。

ちなみにFPから試験密度・不具合密度を算出する方も一時期考えたのですが、
機能ごとのFP算出がいまいち浸透しない・安定しないのでステップカウントを使い続けています。

表の読み方のポイント

資料内ではステップカウントのことをSLOCと記述されています。
ステップ数（プログラムステップ数）とは - IT用語辞典 e-Words
海外ではステップカウントはLOCと呼ばれるらしいですね。
海外で活動したことがないので真偽の程はわかりませんが・・・。

資料の中で、検出バグ数は(現象)と（原因）に分かれています。
これらの違いはこちらに書かれています。
「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答＃バグ数につて

私がバグ表に列挙して行くのは想定と違う事象・現象の方ですので、検出バグ数(現象)の方で考えて行きます。
次に、この表から何が「普通」なのかを読み取りたいのですが、中央値・平均値とそれっぽいものが二つあります。
どちらを「普通」として捉えるかは、データの偏り具合を見てみるしかないようです。
データ白書の見方と 定量データの活用ポイント

採用することにした基準値

以上を踏まえて、表を見てみます。
平均値が妙に高いので一部のデータに引っ張られているのでしょうね。
したがって、中央値を「普通」と捉えることにします。
ここから下限・上限も出したいのですが、表のP25・P75を下限・上限とするのは幅が広過ぎる気がしますね。
一旦中央値の75%・125％を下限・上限とし、試験の試験密度・不具合密度がこの範囲に収まればOKとすることにします。
・・・最後は雰囲気になってしまいました。
データの活用方法は各自に任せると言うスタンスのようなので、致し方ないかなと思います。
皆さんも各々の現場で議論されてみたら良いかと思います。