5-1 プロジェクト終了状況の確認
511 プロジェクトの目的・目標の達成
512 計画書に記述された成果物の存在
513 成果物が要求仕様を満足する
514 プロジェクト完了基準を満たす
515 推進組織の全チームの作業完了
516 残項目を除く全問題点の解決
517 承認された変更要求の実施
5-2 プロジェクト完了報告書の作成
521 実行要約の明確かつ完全な文書化
522 計画と完了時の差異原因の文書化
523 実施された変更の効果の文書化
524 残項目が明確である
525 残項目が引き継げる状態にある
5-3 ユーザによる成果物検収に対する対応
531 ユーザ検収条件を満たす
532 全成果物の検収・承認
533 利用者・製品管理者への引き渡し
5-4 プロジェクト完了報告と終結
541 評価関係者への完了状況の報告
542 評価関係者による完了の承認
543 評価関係者への終結の通知
544 有効な情報が共有情報として追加
コメント:
ソフトウェアというのは、一般的な工業製品などと異なり、エンドユーザーの目に見えないものである。見えるのは画面や帳票といった入出力部分だけであり、処理機能そのものは通常ブラックボックスになっている。しかし、利用者の目に見えないから設計書は多少の不備があってもいい、ということにはならない。むしろ見えないからこそ可視化、すなわち見えるようにすべきだろう。どのような設計内容に対しどのようなレビューを行い、どのような手法でどのようなテストを行い、どのように品質を保証したのか。それらがわかる成果物を納品することが、プロジェクト終結の必須条件と言える。
Pman注目: 512 計画書に記述された成果物の存在 スキル基準には「プロジェクト計画書に記述されたすべての成果物が存在すること」と書かれている。ただし、計画書に記述するのは、例えば、詳細設計書、ソースプログラム、テスト項目表など成果物の種類だけであり、それぞれの種類について、機能単位あるいはモジュール単位の成果物がなくてはならない。私は以前、あるプロジェクトの結合テスト工程が終わりに近づき、成果物の確認をしたところ、1機能におけるテスト成果物が見つからず、青ざめたことがあった。信じられないことだが、進捗表から漏れていたため、テストされていなかったのである。幸いにして、空き要員を割り当てて集中的にテストできたため事なきを得たが、思わぬところに落とし穴があるものだ。
スキル基準の解説も、次回でいよいよ最終回となる。長かった・・。
次回予定→ 6.プロジェクト完了評価
- 関連記事
-
スポンサーサイト