Rayleighモデルとは何か ─ その2

　第1回の続き。

www.kzsuzuki.com　Rayleighモデルを実際のソフトウェア開発プロジェクトに適用するうえで、わたしの実情では以下の3つの問題がある。

(1)「障害」の定義
　テスト工程では「バグ」と言い換えてもいいだろう（「バグ(bug)」はSQuBOKでは定義されていないが）。しかし、設計工程における障害とは何か。障害に直接結びつくであろう問題点をデザインレビューで摘出できた場合、これを障害と呼べばいいのか。では、直接は結びつかないものの、バグのポテンシャルとなりうる曖昧な記述が指摘されたとき、これは障害としてカウントするのか。
　この辺の定義が不明であるために、どうとでも解釈できるグラフになりかねない。

(2)障害数の管理
　たとえば今関わっているプロジェクトでは、コーディングおよびデバッグ中のバグ件数を、厳密には管理していない。コーディング中に気づいて直した誤りまでカウントするとは思えないが、ここもやはり、何をカウントするかの線引きが難しい。
　Rayleighモデルのグラフの形を決める要素であるTmは通常コーディング工程中に当たるため、その間のバグ件数を正しく管理しない限りは、グラフを決定できない。

(3)工程の重複
　厳格なWaterfallモデルを採用しているプロジェクトに関わったことがないので一般的かどうかはわからないが、プロジェクトの工程は重複するケースが多い。たとえばコーディングが終わった部分から五月雨式に単体テストを始める、など。いわゆるfast trackingである。
　こうなると、Rayleighモデルの横軸の扱いが厄介になる。たとえ重複していたとしても、横軸上は重ならないように描くといった処理をしていいのかが不明である。

　現在のプロジェクトでは、設計工程のデザインレビューにおける指摘件数なども割と管理されているので、テスト工程において摘出された不良の数と合わせ、近似曲線を描いてみるつもりだ。
　次回は、具体的に適用してみたという論文を紹介したい。