任务:复审变更请求
此任务定义了如何执行变更请求类选。
规程:配置与变更管理
用途
  • 此任务的目的是确定变更请求(CR)是应该接受还是应该打上拒绝标记。 对于已经接受的 CR,此任务评估其优先级、工时、进度安排等以确定变更是否在当前发行版的范围内。
关系
角色主执行者: 其他执行者:
输入必需: 可选:
输出
流程使用情况
步骤
安排 CCB 复审会议

变更(或配置)控制委员会(CCB)是监督变更流程的委员会,由所有相关方(包括客户、开发人员和用户)的代表组成。在小项目中,个人(如项目经理或软件设计人员)就可以担任这个角色。在 Rational Unified Process 中,这用变更控制管理员角色表示。

该会议的功能是复审提交的变更请求。在会议中进行 CR 内容的初始复审以确定该请求是否有效。如果有效,就根据优先级、进度安排、资源、工时级别、风险、严重性和小组确定的任何其他相关的条件来决定该变更是否在当前发行版的范围内。此会议一般每周进行一次。如果 CR 量大幅增加,或者当一个发行版周期临近结束时,可以每天召开该会议。CCB 复审会议的成员一般是测试经理、开发经理和销售部门的成员。 如果成员认为有必要,则可以按需要邀请其他人参加会议。

检索变更请求用于复审

变更请求表单是正式提交的工作产品,用于跟踪所有请求,包括新特性、扩展请求、缺陷、变更的需求等等。其中还包含项目生命周期中的相关状态信息。所有的变更历史记录将与 CR 一起维护,包括所有的状态变更以及变更的日期和原因。 此信息对于任何重复的复审和最终的关闭都可用。工作产品:变更请求中提供了一个变更请求表单示例。

复审提交的变更请求

此任务的功能是复审已提交的变更请求。该状态是以下操作的结果:1)提交新的 CR、2)更新现有的 CR 或者 3)在新的发行版周期中考虑某个已延期的 CR。将 CR 放在 CCB 复审队列中。该操作不会导致分配所有者。

在 CCB 复审会议中进行 CR 内容的初始复审以确定该请求是否有效。如果有效,就根据优先级、进度安排、资源、工时级别、风险、严重性和小组确定的任何其他相关的条件来决定该变更是否在当前发行版的范围内。

如果确定 CR 有效,但在当前发行版的“范围之外”,它就被置于已延期状态,将保留并在将来的发行版中重新考虑。可以指定目标发行版,以表明该 CR 可以提交以重新进入 CCB 复审队列的时间范围。

如果确定某个 CR 与另一个已经提交的 CR 重复,就应该将它分配给 CCB 复审管理员或指定的团队成员进行解决。当 CR 置于重复状态时,会记录与它重复的 CR 号(在 ClearQuest 中的“附件”选项卡上)。提交者应该在提交 CR 前首先查询 CR 数据库,以查看 CR 是否重复。这将省去复审流程的好几个步骤,从而节省大量的时间。应该将提交了重复 CR 的人员添加到原 CR 的通知列表中,以便将来传达关于解决方案的通知。

有时,CCB 复审会议或指定的团队成员确定 CR 是无效请求还是需要从提交者那里获得更多信息。如果已经指定(已打开),将从解决队列中除去该 CR,并再次进行复审。指定了 CCB 的指定权限进行确认。不需要提交者采取任何操作,除非是必要情况,在这种情况下,CR 状态将更改为更多信息。CCB 复审会议将考虑任何新信息并再次复审该 CR。如果确认为无效,CCB 将关闭该 CR,并通知提交者。

当 CR 已确定为在当前发行版的“范围以内”时,就将其指定为已打开状态,正在等待解决。已安排在即将到来的目标里程碑之前解决该变更请求。已将它定义在“分配队列”中。仅会议成员有权打开 CR 并放入解决队列中。 如果发现了优先级为 2 或更高的 CR,就应立即让 QE 或项目经理注意到该 CR。此时,他们可能会决定召开紧急 CCB 复审会议或者只须立即打开 CR 并放入解决队列中。

然后项目经理负责根据 CR 的类型对已打开的 CR 分配工作并更新进度安排(如适用)。

变更请求可能经历的典型状态在变更请求管理中有说明。



更多信息