主题

定义 回到页首

变更请求CR)- 一种正式提交的工件,用于在项目的整个生命周期内跟踪所有涉众请求(包括新特性、扩展请求、缺陷、变更的需求等等)以及相关的状态信息。所有的变更历史记录将与变更请求一起维护,包括所有的状态变更以及变更的日期和原因。该信息对于任何重复复审和最终的结束都可用。

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

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

变更请求提交表单 - 当首次提交变更请求时,显示该表单。表单上仅显示提交者完成提交所必需的字段。

变更请求组合表单 - 当您在复审已经提交的变更请求时,显示该表单。它包含描述变更请求所必需的所有字段。

以下变更请求流程大纲描述了变更请求在整个流程中的状态,以及在变更请求的生命周期中需要通知哪些人员。

管理变更请求的活动样本 回到页首

以下示例显示项目在其生命周期内可能为管理变更请求(CR)采用的活动样本(单击图中各项以查看相应描述):

CR 已关闭 测试已失败 验证发行工作版本中的变更 CR 已关闭 确认重复或拒绝 已提交 更多信息 更新 CR 已提交 拒绝 重复 已验证 验证测试工作版本中的变更 测试已失败 作出变更 已解决 拒绝 重复 验证测试工作版本中的变更 已分配 分配工作和安排工作进度 提交 CR 分配工作和安排工作进度 已打开 复审 CR 已延期 已提交 变更请求 变更控制委员会 提交 CR 以上图表说明中所述的图。

样本变更请求管理(CRM)流程活动描述:

活动 描述 职责
提交 CR 项目的任何涉众都可以提交变更请求(CR)。变更请求会记录在变更请求跟踪系统(例如 Rational ClearQuest)中,并通过将变更请求状态设置为已提交来放置到 CCB 复审队列中。 提交者
复审 CR 该活动的功能是复审已提交的变更请求。在 CCB 复审会议中进行变更请求内容的初始复审,以确定该请求是否有效。如果有效,就根据优先级、进度安排、资源、工作量级别、风险、严重性和小组确定的任何其它相关的条件来决定该变更是否在当前发行版的范围内。 CCB
确认重复或拒绝 如果怀疑变更请求重复已拒绝,是无效请求(例如:操作员错误、不可重现、工作方式等等),将指定 CCB 的一个代表来确认重复的或已拒绝的变更请求并(如有必要)从提交者那里收集更多信息。 CCB 代表
更新 CR 如果需要更多信息(更多信息才能评估变更请求,或如果在流程中的任意点上拒绝了变更请求(例如:确认为重复拒绝等),提交者会收到通知,并可以用新的信息来更新变更请求。然后更新的变更请求被重新提交给 CCB 复审队列来考虑该新数据。 提交者
分配工作和安排工作进度 一旦打开了某个变更请求,项目经理随后就会将该工作分配给合适的团队成员 - 根据请求的类型(例如:扩展请求、缺陷、文档变更、测试缺陷等等)- 并对项目进度安排进行任何必需的更新。 项目经理
作出变更 指定的团队成员执行流程的相应部分(例如:需求、分析与设计、实施、产生用户支持材料、设计测试等)中所定义的一组活动来作出所请求的变更。这些活动将包含一般开发流程中描述的所有一般的复审和单元测试活动。然后将把变更请求标记为已解决 指定的团队成员
验证测试工作版本中的变更 在指定的团队成员(分析人员、开发人员、测试员、技术编写员等)已解决变更后,这些变更就放到测试队列中,以供分配给测试员并在产品的测试工作版本中进行验证 测试员
验证发行工作版本中的变更 已解决的变更一旦在产品的测试工作版本中得到验证,就将变更请求放到发行队列中等待对照产品的发行工作版本进行验证、生成发行说明等并关闭该变更请求。 CCB 代表(系统集成者)

变更请求的状态和转移样本 回到页首

以下示例图显示了状态样本以及在变更请求(CR)的整个生命周期内应通知哪些人员[单击图中各项以查看相应描述]:

CCB 复审会议 更多信息 更多信息 更新 CR 更新 CR 确认重复或拒绝 验证发行工作版本中的变更 已关闭 更多信息 已验证 重复 拒绝 CCB 复审会议 提交 CR 已提交 测试已失败 验证测试工作版本中的变更 已解决 作出变更 已打开 分配工作和安排工作进度 已分配 已延期 变更请求 在以上图表说明中所述的图。

样本变更请求管理(CRM)状态描述:

状态 定义 访问控制
已提交 该状态是以下操作的结果:1)提交新的变更请求、2)更新现有的变更请求或者 3)在新的发行版周期中考虑某个已延期的变更请求。将变更请求放在 CCB 复审队列中。该操作不会导致分配所有者。 所有用户
已延期 变更请求已确定为有效,但在当前发行版的“范围以外”。处于已延期状态的变更请求将保留,并在以后的发行版中重新考虑。可以指定目标发行版,以表明该变更请求可以提交以重新进入 CCB 复审队列的时间范围。 管理员

项目经理

重复 处于此状态的变更请求被视为与已提交的另一变更请求重复。CCB 复审管理员或分配来解决该问题的团队成员可以将变更请求置于此状态。当变更请求被置于重复状态时,将记录与它重复的变更请求号(在 ClearQuest 中的“附件”选项卡上)。提交者应该在提交变更请求前首先查询变更请求数据库,以查看变更请求是否重复。这将省去复审流程的好几个步骤,从而节省大量的时间。应该将提交了重复变更请求的人员添加到原变更请求的通知列表中,以便将来传达关于解决方案的通知。 管理员

项目经理

QE 经理

开发

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

项目经理

开发经理

测试经理

更多信息 存在的数据不足,无法确认拒绝重复变更请求的有效性。所有者将自动变为被通知要提供更多数据的提交者。 管理员
已打开 处于此状态的变更请求已确定为在当前发行版的“范围以内”,正在等待解决。已安排在即将到来的目标里程碑之前解决该变更请求。已将它定义在“分配队列”中。仅会议成员有权打开变更请求并放入解决队列中。如果发现了优先级为 2 或更高的变更请求,就应立即让 QE 或开发经理注意到该变更请求。此时,他们可能会决定召开紧急 CCB 复审会议或者只须立即打开变更请求并放入解决队列中。 管理员

项目经理

开发经理

QE 部门

已分配 然后项目经理负责根据变更请求的类型对已打开的变更请求分配工作并更新进度安排(如适用)。 项目经理
已解决 表示该变更请求已解决完毕,现在可以进行验证了。如果提交者是 QE 部门的成员,所有者会自动变为进行提交的 QE 成员;否则,变为 QE 经理,以进行手工重新分配。 管理员

项目经理

开发经理

QE 经理

开发部门

测试已失败 在测试工作版本或发行工作版本中测试失败的变更请求将被置于此状态。所有者将自动变为解决该变更请求的团队成员。 管理员

QE 部门

已验证 处于此状态的变更请求在测试工作版本中已验证,可以包含到发行版中了。 管理员

QE 部门

已关闭 不再需要关注该变更请求。这是所能分配给变更请求的最终状态。只有 CCB 复审管理员有权关闭变更请求。变更请求关闭后,提交者将收到包含变更请求最终处置情况的电子邮件通知。可以在以下情况下关闭变更请求:1) 在发行工作版本中确认了它的已验证的解决后;2) 当确认了它的拒绝状态后;或者 3) 当确认它与现有变更请求重复时。如果是最后一种情况,将向提交者通知重复的变更请求,并将该提交者添加到该变更请求,以便将来通知(请参阅“拒绝”和“重复”状态的定义以获取更多详细信息)。如果提交者对关闭有争议,就必须更新该变更请求,并重新提交以进行 CCB 复审。 管理员

“标记”状态为报告变更请求(熟化、分发或趋势)统计信息提供了基础。

在以下图表说明中所述的图。

CM 模块环境中的变更请求状态。



Rational Unified Process   2003.06.15