連載
己を知れば、たったの30秒でバグ数が予測できる:山浦恒央の“くみこみ”な話(51)(2/2 ページ)
プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第4回では、たったの30秒で推定できる割に、意外と精度も低くない「バグ率による総バグ数予測」を取り上げる。
3.バグ率を使った残存バグ数の推定
過去の統計情報からバグ率が分かると、いろいろなタイミングで総バグ数を予測できます。
- プロジェクト立ち上げ時
プロジェクト立ち上げ時に、何人のエンジニアが何カ月必要かを予測するため、開発するソフトウェアの規模を推定します。実際には、ソースコード行数かFP(ファンクションポイント)を使う場合がほとんどでしょう(この2つの規模見積もりについては、本コラムの第36、37回を参照してください)。この時、予測したソースコード行数に過去の「プロジェクトとしてのバグ率」を乗ずると、バグ数を計算できます。例えば、ソースコード数を105KLOCと見積もり、前回、同じような製品を開発した時、全部で83KLOCのソースコードを作り、357個のバグを作り込んだとします。ここから以下のように今回、期待されるバグ総数を推測できます。
357 / 83 = 4.3(前回の1KLOC当たりのバグ率)
105 × 4.3 = 451.5(今回のソフトウェア開発で作り込むバグ総数)
この方法を適用すると、ソースコードが存在するはるか以前に、バグ数を推測できます(まだ「モノ」がないのに、欠陥数が分かるのは、少し不思議な気がしますが)。 - コーディング終了時
プロジェクト立ち上げ時は、開発規模の見積もりに誤差がありますが、実際にコーディングが終了した時点であれば、かなり正確なソースコード行数を把握できるはずです。このソースコード行数にバグ率を乗じると、精度の高い「バグ数」見積もりが可能となります。
4.バグ率に影響するもの
プロジェクト全体のバグ率は、「構成人員」と「開発対象となるソフトウェアの分野」に大きく影響されます。
- 構成人員
プロジェクトの人員が同じですと、バグ率の数値も同じような値になります。プロジェクトのメンバーが入れ替わると、バグ率も大きく変わります。もしも、プロジェクト構成員がそっくり入れ替わった場合は、各個人が担当する部分のソースコード行数と、各個人のバグ率を割り出し、その総和を「総バグ数」として計算するとよいでしょう(少し面倒ですが……)。 - ソフトウェアの分野
生産性やバグ数に大きく影響します。ソフトウェア設計の複雑性が上がると、バグ率は増加します。例えば、呼び出されるモジュールの順番がいつも同じである「バッチ系」のプログラミングより、コールされる順番がプロセスの優先度によって異なるリアルタイムOS系のソフトウェア開発の方が、バグ率は圧倒的に高くなります(従って、1000ステップ当たりのテスト項目数も、バッチ系は100件程度ですが、リアルタイムOS系では300〜500件と急激に増加します)。
ソフトウェア開発では、同じプロジェクトメンバーで同じ分野のソフトウェア開発をすることが多いと思われます。この場合は、生産性やバグ率も同じような数値になります。
5.おわりに
プロジェクトマネジャーは、これまで担当してきたプロジェクトがどんなプロジェクトだったか、具体的な数値を使って簡単に説明できます。その具体的な統計データを使用して、これから開発するソフトウェアの品質や総バグ数を推測するのが、今回取り上げた「バグ率による総バグ数予測」です。繰り返しになりますが、簡単に推定できる割に、精度は意外に低くないのでぜひ活用してみてください。
プロジェクト全体のデータと関連しますが、「自分は、個人としてどんなプログラマーなのか、具体的な数値を使って表現する」ことは、それを意識している人には簡単なことですが、意識していないとどうしてよいか分かりません。そんな方は、プログラム開発が工学であることを認識する第一歩として、本コラムを参考に「自分のデータ」を把握してみてはいかがでしょう。
次回は、「サンプリング法」を適用した残存バク数の予測法について解説いたします。お楽しみに! (次回に続く)
【 筆者紹介 】
山浦 恒央(やまうら つねお)
東海大学 大学院 組込み技術研究科 准教授(工学博士)
東海大学 大学院 組込み技術研究科 准教授(工学博士)
1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。
主な著書・訳書は、「Advances in Computers」 (Academic Press社、共著)、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」(以上、日経BP社、共訳)、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」(以上、日経BP社、翻訳)。
関連キーワード
デスマーチ | 組み込み開発 | 組み込み開発プロセス改善 | 組み込み開発の混沌から抜け出そう | 現場の声からプロセス改善を深掘りする | 山浦恒央の“くみこみ”な話 | バグ | 開発プロセス | ソフトウェアテスト | システム開発
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- あなたは「バグ」をどう数えていますか? 組み込みソフトウェアの品質管理を考える
あなたの現場では、ソフトウェアの品質管理の考え方をきちんと生かし切れていますか? MONOist編集部では組み込みソフトウェアの品質管理をテーマにしたゼミナール「組み込みソフトウェア開発で問われる品質力」を開催。組織における品質管理の考え方や、実際の開発現場におけるツールの活用・導入に関する事例などが披露された。 - デスマーチ・プロジェクトでの正しい手の抜き方
高機能・多機能化に加え、「品質向上」「コスト削減」「納期短縮」が強く求められる組み込み業界。小手先の対応では太刀打ちできない。 - 連載記事「山浦恒央の“くみこみ”な話」