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