目的
  • 初期のソフトウェア開発計画書を承認する。
  • ソフトウェア開発計画書への変更をレビューおよび承認する。
ステップ
入力とする成果物:    結果となる成果物:   
頻度: プロジェクトの開始時とソフトウェア開発計画書の更新ごとに 1 回 
役割:  管理レビュー担当者 
ツール メンター:   

ワークフローの詳細:   

最初のプロジェクト計画のレビューは方向づけフェーズの終了間近に実施します。その時点では、ソフトウェア開発計画書の作成が完了し、プロジェクト チームが確かな自信を持てる高レベルのフェーズ計画を持っています。

それに続くプロジェクト計画のレビューは、ソフトウェア開発計画書の改訂予定時点 (各反復の終了時など) に合わせて実施します。プロジェクトで問題が発生したために計画を変更する必要性が生じた場合は、「予定外」の時点にも実施します。

プロジェクト計画のレビュー会合のスケジュール作成 ページの先頭へ

プロジェクト計画のレビュー会合の出席者には、上級管理職の代表者、ソフトウェア開発計画書により定められた、プロジェクトに投入する必要のあるすべてのグループ (開発 / エンジニアリング、操作、品質保証、テスト、顧客サポートなど) を含める必要があります。一般的に、これらのメンバーは、プロジェクト レビュー委員会のメンバーと、プロジェクト チームのさまざまな機能領域のチーム リーダーで構成されます。

プロジェクト計画のレビュー会合への出席者が決定したら、開催される会合の日時を設定します。参加者が、承認決定の基礎として使用する資料をレビューできるように、十分な準備期間を与えることが重要です。

会合資料の配布 ページの先頭へ

会合に先立って、レビュー担当者にプロジェクトの資料を配布します。レビュー担当者がレビューに十分な時間をかけられるよう、プロジェクト承認レビュー会合まで十分な時間的余裕を持ってこれらの資料を送付します。レビューのために最低限提示すべき成果物のセットを次に挙げます。

  • 開発構想書
  • 開発企画書
  • リスク リスト
  • ソフトウェア開発計画書 (およびそれに包含される計画)

プロジェクト計画のレビュー会合の実施 ページの先頭へ

会合の開催中にレビュー担当者は、提案されたソフトウェア開発計画書を評価し、プロジェクトの目的を達成する作業の 1 つのプログラムを表しているかどうかを判断します。レビュー担当者はさらに、計画の中に誤った仮定または割愛した部分がないかどうかを探します。以下を含めて考慮してください。

  • この計画は開発企画書と開発構想書で定義されているニーズに対処しているか。
  • この計画は開発企画書で概略されているスケジュールと予算内で希望する結果を実現できるか。
  • この計画は十分に詳細なレベルまで作成されており、プロジェクトの結果が現実的に予測可能か。
  • プロジェクトの見積りは信頼できる分析的な方法を使用して準備されたか。
  • レビュー ポイントとマイルストーンが十分に頻繁な間隔でスケジュールされているか。
  • この計画はすべての重大なリスクを軽減 / 回避するように設定されているか。
  • 十分なリソースが計画の中で認識されているか、またそれらのリソースは入手可能 / 取得可能か。
  • 役割と責務は明確に定義されているか。
  • 計画の中で定義された監視と管理のプロセスは受け入れられるか。
  • すべてのサポート計画とガイドラインは受け入れ可能なレベルまで詳細化されているか。

会合の終了時にレビュー担当者は、承認決定を下します。結果は次のいずれかになります。

計画の承認  プロジェクトを計画どおりに進行する。上級管理職がプロジェクトの残りの資金とリソースに責任を持つ。 
プロジェクト中止  プロジェクトは、既知のリスクおよびプロジェクトの予算 / スケジュール内では実行不可能。 
決定の延期  詳細情報が必要であるか、承認決定を下す前に追加調査が必要。 

決定の記録 ページの先頭へ

会合の終了時に、重要なディスカッションやアクション項目を記載し、プロジェクト計画のレビューの結果を記録したレビュー記録を完成させます。結果が「決定の延期」だった場合、フォローアップのプロジェクト計画のレビュー会合を後日にスケジュールします。



Rational Unified Process   2003.06.15