目的
  • 核准初始的“软件开发规划”
  • 复审并核准对“软件开发规划”作出的更改
角色:管理复查员  
频率:项目开始时一次,然后在“软件开发规划”每次更新时各一次
步骤
输入工件:   生成的工件:  
工具向导: 

工作流程明细: 

第一次“项目规划复审”在“先启阶段”接近结束时进行,此时“软件开发规划”已经完全制定好了,并且包括了整个项目团队都对其有高度信心的高级阶段规划。

后面的“项目规划复审”在安排了应该修改“软件开发规划”的时间点进行(例如,在每个迭代结束时)。它们还在“未经安排”的时间点进行,是由于项目中的问题造成需要对规划作出更改而引发的。

安排项目规划复审会议 回到页首

参加“项目规划复审”会议的人应该包括来自高级管理层以及“软件开发规划”要求的必须对项目提供资源的所有小组(如开发/工程人员、操作人员、QA、测试人员、客户支持等等)的代表。一般情况下,这些人和项目团队中各个功能领域的团队领导一起组成“项目复审委员会”。

当确定参加“项目规划复审”会议的人员后,接下来确定会议召开的日期/时间。提供足够的前期时间让参与者审阅将用作核准决策的基础的项目材料,这一点很重要。

分发会议材料 回到页首

在开会前将项目材料分发给复审者。确保这些材料在项目核准复审会议之前发到每个人手上,让复审者有足够的时间审阅这些材料。应该提出来进行复审的工件至少应该包括:

  • 远景
  • 业务案例
  • 风险列表
  • 软件开发规划(及其内附的规划)

举行项目规划复审会议 回到页首

在会议期间,复审者评估提议的“软件开发规划”,以确定它是否代表一系列能实现项目目标的活动。复审者还检查规划中的任何错误的假设或遗漏。需要考虑以下等事项:

  • 规划针对“业务案例”和“远景”中确定的需要吗?
  • 规划能够在“业务案例”中列出的日程安排和预算范围内实现理想的结果吗?
  • 规划已经制定得足够详细,从而能够真实地预测项目的结果了吗?
  • 已经用合理的分析方法准备项目评估了吗?
  • 安排的复审点和里程碑的时间间隔够频繁吗?
  • 规划能够缓解/避免所有重大的风险吗?
  • 规划中确定了足够的资源吗?这些资源可以使用/获得吗?
  • 角色和职责有明确的规定吗?
  • 规划中规定的监视和控制流程可以接受吗?
  • 所有支持规划和指南已经完成得足够详细了吗?

在会议结束时,复审者应该作出核准决策。结果可能是下列之一:

规划被核准  项目将按规划进行。高级管理层为项目提供剩下的资金和资源。 
项目被取消  考虑到已知的风险和项目预算/日程安排,项目不再可行。 
决策推后  需要更多信息,或者需要进一步调查才能作出核准决策。 

记录决策 回到页首

会议结束时,完成复审记录,期间记录所有重要的讨论或操作任务,并记录项目规划复审的结果。如果结果是“决策推后”,就应该安排在以后举行后续的项目规划复审会议。



Rational Unified Process   2003.06.15