今回はサイクル・テストのテスト・シナリオのＥＶＭのまとめをします。
４月１０日時点での進捗ですが、ここではＥＶＭの重要な数値であるＡＣ（コスト実績値）を出していません。
このため、ＳＰＩ（スケジュール効率指数）は使いますが、ＣＰＩ（コスト効率指数）は計算できない（分母がＡＣ）ので使いません。
ＥＴＣ（残作業コスト予測）の計算の際も、ＳＰＩだけで割って数値を出しています。
ＢＡＣ（完了までの当初予算）は、表のテスト・シナリオ一覧表の工数を計上基準に従って合算したもので、４０人日になります。
この数値と表の下に記載した計算式に従い、空欄を埋めていけばこの表が出来上がります。
栽培プロジェクト内部からテスト進捗を見る上で、大変分かりやすいので、利用することを強く勧めます。
ＡＣを使わない理由は、テスト・シナリオの実工数を把握することが困難だからです。
テスト・シナリオの工数が増える主要な理由として、検証工数の増加と障害が発生した時の対応が挙げられます。
迅速な対応が求められるシステム・テストでは、とにかく動員できる限りの担当者の協力を得て、事に対処することを迫られます。
それでは、実工数を把握することは難しいのです。
いずれにせよ、カットオーバーを間近に控えたこの時点では、どんなに工数がかかってもやり切るしかないのです。
障害管理
システム・テストで障害が発生すると、テスト・シナリオが中断します。
そのシナリオに後続するテストを再開するには、障害が解決されている必要があります。
先に述べたように、障害は即日解決が大原則だが、できない場合は次回のテスト基準日までに解決します。
こうした管理を行うときに使うのが、障害管理表です。
この表における重要な欄は「対応予定日」で、次のテスト予定日に合わせて障害を解決します。
これに失敗すると、テスト・シナリオが前に進まないという厳しい状況に陥ります。
システム・テスト全体を鳥瞰できる立場にいなければこの管理はできないので、多くの栽培プロジェクトでは専任の管理者を置いているのが現状です。
