目指す姿
- 発生しうる誤りや欠陥の種類を特定する
- 欠陥がどこに、とかどれくらいあるのか分かるの?という訳ではない
- 欠陥予測を使い、脱炎上プロジェクト、市場バグゼロへ
欠陥予測のイメージ
- カレーうどん
- 白いシャツ
すする
- 汁が付着する
- 紙エプロンを着用する
カレーうどん以外にも、ミートソーススパゲティでも同じ
メカニズムが分かれば予測もでき、対策も打てる
欠陥予測に必要なこと
前提
- 過失・欠陥は同じメカニズムで繰り返し発生
欠陥の予測に必要なこと
- 欠陥混入に至るメカニズムが表現されていること
現状の問題点
- 欠陥混入メカニズムが理解できない
- 不具合DBが欠陥混入予測のために利用しにくい
- 不具合・欠陥とその要因を区別して表現していない
- 不具合DBから欠陥を予測する手順が確立されていない
研究課題
- 手法確立
- 表現手法
- 蓄積手法
- 予測手法
- 評価手法
- 今回は対象外
解決のアイディア
- 欠陥モデリング
特性要因図と5M1E
表現するのは欠陥と人の過失とその誘発因子
提案手法:ソフトウェア欠陥予測アルゴリズム
人は誤ることを前提に欠陥をモデリングする
混入要因と流出要因を区別する
- 混入要因のみして、そこから予測に必要な要素のみとする
質問
Q.過去のプロジェクトの洗い出しから行うことは難しいと思うが、コツなどはあるか?
- A.コツはない。記録がないと分析もできない。
- ただ、お客さんへの不具合報告については細かな要因まで書かれていることが多い
- その部分から行っていくのもひとつの手では?
Q.なぜなぜ分析に近い形だが、実際にやる際に、各因子を結びつけて行わないのか?
- A.なぜなぜ分析は終わった後の整理だと思っている
- なぜなぜ分析はリスク予測をしていると思うが
- 前段で使うことの想定まではしていなかった
Q.情報が丸め込まれることで、各プロジェクトで違う切り口で独自のモデルを作っていく活動が必要なのでは?
- A.そういった部分に対するアドバイスがあれば意見をください
- 具体化しないと、自分の経験と結びつかないからという理由で取り入れてくれない
- 業界全体としての抽象的なモデルと会社固有の具体的なモデルを持つべきなのかもしれない
Q.これのポイントはどれだけ誘発因子を取るのが大事だと思うが、実際に行う場合はブラッシュアップが必要なのではないかと考えている
- 誘発因子のリストを公開していただくことは可能か?
- A.昨年のSQiP論文に誘発因子リストが載っている
- ブログから追えるはず