私の勤務先にソフトウェアを納入している某社でバグの分析に使っている項目表
を見せてもらいました。えぇと、内容そのものは某社ではなくうちの親会社の機
密情報に指定されているので漏らせませんが、どういった項目で管理しているの
かというのなら大丈夫かな。かなり省略等を行っていますが、大体以下のような
ものでした。
【エラー分析】
１．仕様バグ
２．設計バグ
３．製造バグ
４．その他
詳細１
Ａ：仕様もれ
Ｂ：仕様誤り
Ｃ：仕様表現不備
Ｄ：設計もれ
Ｅ：設計誤り
Ｆ：設計表現不備
Ｇ：コーディングもれ
Ｈ：コーディング誤り
Ｉ：修正もれ
Ｊ：修正誤り
Ｋ：コンパイル誤り
Ｌ：その他
詳細２
Ａ：競合条件誤り
Ｂ：インターフェース誤り
Ｃ：データ初期設定誤り
Ｄ：タイミング不正
Ｅ：関数ミス
Ｇ：インターフェース利用ミス
Ｈ：ツール利用ミス
Ｉ：データインデックス誤り
Ｊ：データ設定誤り
Ｋ：分岐誤り
Ｌ：ワード境界誤り
Ｍ：繰り返し誤り
Ｎ：その他
詳細３（インターフェースミス時のみ）
Ａ：ハードウェア間インターフェース
Ｂ：ＯＳインターフェース
Ｃ：モジュール間インターフェース
Ｄ：クラス群間インターフェース
Ｅ：クラス間インターフェース
Ｇ：その他
発見すべき試験工程
Ａ：単体試験
Ｂ：結合試験
Ｃ：総合試験
未発見理由１
Ａ：レビュー未実施
Ｂ：チェック項目もれ
Ｃ：ドキュメント不備
Ｄ：その他
未発見理由２
Ａ：試験項目もれ
Ｂ：環境設定不備
Ｃ：試験方法・手順誤り
Ｄ：試験結果確認ミス
Ｅ：その他
【エラー原因分類】
１．検討不足
ア：ユーザ要求仕様書の検討不足
イ：実現方式の検討不足
ウ：その他
２．確認不足
ア：設計条件の確認不足
Ａ−境界条件、周囲条件、限界処理、テーブル設計の確認不足
Ｂ−設計書の解釈誤り
Ｃ−他プログラム・モジュールへの波及の確認もれ
Ｄ−チェックリストによる確認もれ（チェックリスト不備を含む）
イ：修正確認不足（仕様変更、設計変更、エラー訂正などに伴う修正結果の確認不足）
ウ：連絡不足
Ａ−担当者間の連絡・コミュニケーション不十分
Ｂ−仕様変更、設計変更、エラー訂正の周知不足
３．教育・習熟不足
ア：業務知識の理解不足
イ：設計技術の不足
４．注意不足
ア：先入観による誤判断
イ：見落とし
ウ：その他の凡ミス
個人で趣味のプログラムをするときにここまで管理することが必要か、または適
切かという問題はありますが、試しにやってみると面白いかも。１年とかデータ
を蓄積してみれば１０個やそこらはたまるでしょうから、それで自分の誤りの傾
向が見えたらしめたもの、何に注意すればよいかがわかるだけでも多少の改善は
図れるような気がします。
|