|
|
- 《 品質管理編 》
故障を作りこんだ工程と検出すべき工程
故障というのは、振り返ってみると
作りこんでしまった時（工程）と
本来取り除くべき工程があります。
以前に
大規模プロジェクトの品質管理を主としてプロジェクト管理を行った時に
経験させていただきました。
簡単な図ですが、故障における挿入と削除の関係は、次のようになります。
－作りこんだ工程－ ⇔ －検出すべき工程－
要件定義 ⇔ 運用テスト
基本設計 ⇔ システムテスト
詳細設計 ⇔ 結合テスト
プログラミング ⇔ 単体テスト
このような対比関係にあると定義しています。
つまりプログラミング工程で作りこんだ故障は、
単体テストで検出しておかなければならないのです。
作りこんだ工程と検出すべき工程
それでは、これでどんなことがわかるのでしょうか？
故障の内容を１件ずつ分析することにより、
故障を作りこんだ工程を把握することができます。
そして実際に故障を検出した工程は、どの工程だったのかです。
例えば、
システムテストの工程で、
プログラミング工程で作りこんだ故障が多発している場合、
単体テストでの故障検出が十分できていないと判断できます。
場合によっては、工程を戻って再試験となります。
経験上、単体テストの不十分が一番多くなっています。
故障件数が多くても目標件数に近く、作りこんだ工程と
検出すべき工程が同じであれば問題ないと判断できます。
これに「故障を発見できなかった要因」を組み合わせて、
精度をさらに高めていきます。
・試験項目抽出モレ
・試験そのもののモレ
・環境上の問題で後工程にした。
・結果確認ミス
・設計時における複合要因の問題
・その他
ここから、故障がまだ十分に検出されていない箇所を洗い出します。
この故障の相関関係は、機能・人・期間などに表れてきます。
・特定の機能に故障が集中している
・特定の人に故障が集中している。
・特定の期間に作りこんだ設計やプログラミングに集中している。
ここから、未だ故障が潜んでいる箇所を統計より推測して
強化試験などを実施します。
作りこんだ故障は、
正しく検出すべき工程で検出されていれば問題ないのです。
大抵は、検出すべき工程以降で検出されます。
この件数に着目して潜在故障の検出を行います。
|
