何十億円も掛けて、巨大なサイクロトロンを建設し、新しい元素を発見すれば大成功という理学とは異なり、工学では「投入時間、投入工数、投入コストに対し、どれだけの成果を上げられるのか」をとても気にします。そして、エンジニアは面倒なことを嫌い、「サクサクとできること」を好みます。
ソフトウェア開発の現場では、Gompertz曲線自体に説得力があるので用いますが、数式に関してはまず使いません。
摘出バグ数の測定がいいかげん(正確には、単位時間を考慮していない)なので、残存バグ数の予測もいいかげん、あるいは「時間をかけない簡易式」になります。具体的には、図2の「摘出バグ累計の漸近線」が、どのあたりになるかを予測することです。
このグラフを見るとバグ累計の漸近線を予測することは、視覚的で、極めて簡単に見えます。しかし、実際には以下の理由で熟練を要します。
摘出バグ数の基になる情報がいいかげんなので、残存バグ数の予測精度はそれほど高くはありません。しかし、時間をかけずに簡単に予測できる点は大きな魅力です。また、バグの発生傾向やプロジェクトの状態を診断する上で、Gompertz曲線の分析は非常に強力な手法となります(プロジェクトの状況診断は、第16回の「テスト消化曲線とバグ発生曲線の7パターン診断」で詳細に解説しています)。
Gompertz曲線による残存バグ数予測は、日々のバグ数の統計情報を集める延長で実施できます。バグの統計情報がいいかげんなので、それなりの残存バグ数予測法を使うことになり、精度はそれほど高くはありませんが、時間も工数も掛かりません。また、手法としての説得力もありますので、Gompertz曲線による残存バグ数予測は、プロジェクトマネジャーの「必需品」といえます。
なお、ソフトウェアの品質制御の世界では、難解な数式が大量に出てきますが、そんな数式は「正確に表現するとこうなる」程度に考えて斜め読みし、先に進むことを筆者はオススメします。
次回は、サンプリング法を適用した残存バグ数の予測法について解説します。ご期待ください! (次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.