プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第2回では、前回紹介したトンデモ推定法「キャプチャー・リキャプチャー・モデル(別名:ソフトウェア版『池の中の魚』モデル」の改訂版である、「2チーム制」モデルを取り上げる。
コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入――。このとき、「プログラムの中に隠れているバグの総数を正確に推定できたらなぁ……」と考えたことはありませんか? こう考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。
前回は、ソフトウェア中の残存バグ数の予測法として、「キャプチャー・リキャプチャー・モデル(別名:ソフトウェア版「池の中の魚」モデル)」を取り上げました。この方法は、動物学で用いられる「母体数推定モデル」を応用した面白い発想の「残存バグ数予測モデル」ですが、“人工的にバグを埋め込む”という一種のトンデモ推定法でした。
今回は、キャプチャー・リキャプチャー・モデルの改訂版である「『2チーム制』モデル」を解説します。こちらは、健全であると同時に、極めて実践的な方法といえます。
動物学の世界では、ある地域に生息する動物の個体数を推定するのに、キャプチャー・リキャプチャー・モデルと呼ばれる技法が用いられます。例えば、池の中の魚の数を予測する場合、以下のような手順を踏みます。
これをソフトウェア中の残存バグ数の予測に応用すると、以下のようなステップになります。
この方法は発想として非常にユニークなのですが、人工的なバグを埋め込む行為は、“品質向上”を基本姿勢とするソフトウェア開発技術者にとって、大きな心理的抵抗があります。
今回紹介する2チーム制モデルは、キャプチャー・リキャプチャー・モデルをベースにしていますが、“人工バグを埋め込まない”改訂版モデルです。それでは、その詳細を見ていきましょう。
このモデルは、人工バグを埋め込む代わりに、2つの独立したチームがテストを実施し、摘出されたバグのうち、両チームで共通したバグの数をカウントして、残存バグ数を推定するモデルです。以下に、具体的なステップを示します。
2チーム制モデルは、池の中の魚モデルを応用していますが、人工バグをソースコードに埋め込むようなことはしません。このため、ソフトウェア開発技術者の心理的な抵抗がなく、現在の品質レベルを保持できるため、極めて現実的で、実践的な方法といえます。特に「オフショア開発」と「部分的テスト」において、効果を発揮してくれます。
世界で最もソフトウェア開発技術者の人件費が高いのは、日本とアメリカです。両国では、安くて優秀なソフトウェア開発技術者を求め、インドや中国などの開発会社に発注するオフショア開発を盛んに行っています。
一般的に、オフショア開発を行うには幾つかの事項を検討しなければなりません。例えば、「海外で担当してもらえるように、独立性が高く、分かりやすい作業を切り出す必要がある」「仕様書や設計書を日本語と英語のどちらで記述するか?」「コミュニケーションのミスが発生しないよう、双方の拠点にリエゾンエンジニア(連絡役の技術者)を配置する必要がある」などです。中でも、独立性が高く、分かりやすい作業を切り出すことは、オフショア開発が成功するか否かの大きなカギを握っています。
2チーム制による残存バグ数の推定は、オフショア開発との相性が抜群です。同じプログラムを海外でテストしてもらう作業は、非常に手離れが良く、作業のゴールや目的が明快で、相手国のソフトウェア技術者に細かく指示しなくても理解しやすい作業といえます。日本チームと海外チームではなく、ソフトウェア開発技術者の人件費が日本の半分以下であるインドや中国で、2つのテストチームを編成すれば、日本で行うよりも安価にテストを実施できます。ただし、両チームのテスト品質を保証するため、それぞれのチームが設計したテスト項目の内容を日本でじっくりとチェックする必要があります。
2チーム制モデルは、開発するソフトウェア全体に適用する必要はありません。重要性の高いモジュールやバグの多い機能など、部分的に2チーム制モデルを適用すれば、モジュールごとの残存バグ数を予測できますし、品質の分析が可能となります。
モジュールが十分に小さければ、“1チーム=1人”とし、2人で2チームを組織できますし、短期間での作業が可能になります。この部分的テストは導入を検討すべきでしょう。
繰り返しになりますが、オリジナルの池の中の魚モデルに比べ、改訂版である2チーム制モデルは、人工バグを埋め込む必要がありません。このため、現状の品質を維持したままで、残存バグ数の推測が可能となります。
ただし、前回、池の中の魚モデルの評判が悪い理由として挙げられた「残存バグの推定値が、実際のバグ数よりもかなり小さい」については、2チーム制モデルでも改善されていません。ある研究によると、2チーム制モデルでも、推定値は実際の値の40%前後になるそうです。
しかしながら、独立した2チームが別の視点で同じソフトウェアをテストすることは、品質制御の観点からも非常に有効であり、バグ数推定の他にもいろいろな効果が期待できます(実際、適用・活用している企業もあります)。特に、筆者はオフショア開発で積極的に導入を検討すべきだと考えます。
さて、次回は「Gompertz Curve(ゴンペルツ曲線)」を適用した、残存バク数の予測法について解説します。お楽しみに! (次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.