考えられる原因 | 検討すべき処置 |
---|---|
見積りよりも少ない場合 | |
作業成果物が高品質である | ・原因を特定し、プロジェクトやプロセスの手本にするべきことがないかどうか調べる |
テストが不適切 | ・テストに費やされた工数をチェックする。テスト計画をレビューし強化する ・追加テストを計画する |
見積り欠陥数が多すぎる | ・原因を特定して見積りを修正する |
見積りより多い場合 | |
それまでの品質管理活動の実施方法が不適切 | ・レビューとテストの記録をすべて調べる ・テストを続ける前に、重要なモジュールのレビューを計画する |
計画されたレビューとユニットテストが不十分 | ・テスト計画を強化し、追加テストを計画する ・検収の見積りと計画をレビューする |
見積り欠陥数が少なすぎる | ・原因を突き止めて見積りを修正する |
考えられる原因 | 検討すべき処置 |
---|---|
見つかった欠陥が規範より少ない場合 | |
作業成果物が非常に単純である | ・同様な作業成果物のグループレビューは個人レビューに変える ・いくつかのレビューをまとめて1つにする |
レビューが完全ではない可能性がある | ・カバレッジ率をチェックする。値が低すぎる場合には、レビューのスケジュールを立て直す(チームを変えるなどがよい)。 |
レビュー担当者がグループレビューに関して十分なトレーニングを受けていないか、またレビュー対象に関する経験が十分でない | ・グループレビューのトレーニングのスケジュールを立てるか、トレーニングを実施する ・チームを変えて際レビューする |
作業成果物が非常に高品質である | ・カバレッジ率、作成者やレビュー担当者の経験などを元に。品質が優れている事実を確認する。同等の品質の実現がプロジェクトのほかの部分でも可能かどうか検討する。 ・下流の活動における欠陥予測を改定する。プロセス改善の一般的教訓として学ぶことがないかどうか検討する。 |
見つかった欠陥が規範より多い場合 | |
作業成果物の品質が悪い | ・作成者にトレーニングが必要かどうか検討する ・作業成果物の作り直しを指示する ・以後のタスクの割り当てについて再考する (当該作成者には簡単なタスクだけを割り当てる、など) |
作業成果物が非常に複雑である | ・下流でのレビューまたはテストを厳格にする ・システムテストの見積りを多めにする ・作業成果物をいくつかの小さなコンポーネントに分割する |
軽微な欠陥があまりに多い (その一方で重大な欠陥はほとんど見つからない) |
・軽微な欠陥の原因を特定する。チェックリストを強化し、作成者に原因についての注意を喚起することによって、将来の改善につなげる ・レビュー担当者の作業成果物に対する理解が不十分である可能性がある。該当する場合には、概要説明会議を開くか、またはレビュー担当者を変えてもう一度レビューを実施する |
レビューの際に利用した参照文書が不正確で不明瞭である | ・参照文書をレビューして承認を得る |
レビュー対象のモジュールが当該プロジェクトの最初のモジュールである | ・欠陥を分析し、レビューチェックリストを更新して、開発者に通知する。トレーニングのスケジュールを立てる |