变更请求(CR)-
一种正式提交的工作产品,用于在项目的整个生命周期内跟踪所有项目干系人请求,包括新特性、改进请求、缺陷、变更的需求以及相关的状态信息。
所有的变更历史记录将与变更请求一起维护,包括所有的状态变更以及变更的日期和原因。此信息对于任何重复的复审和最终的关闭都可用。
变更(或配置)控制委员会(CCB)-
是监督变更流程的委员会,由所有相关方(包括客户、开发人员和用户)的代表组成。在小项目中,单个团队成员(例如项目经理或软件架构设计师)可以扮演这个角色。在 Rational Unified Process 中,这由变更控制管理员角色表示。
CCB 复审会议 -
该会议的功能是复审提交的变更请求。在会议中进行变更请求内容的初始复审,以确定该请求是否有效。如果有效,就根据优先级、进度安排、资源、工作量级别、风险、严重性和小组确定的任何其他相关的条件来决定该变更是否在当前发行版的范围内。通常,此会议每周举行一次。如果变更请求量大幅增加,或者当一个发行版周期临近结束时,可以每天召开该会议。CCB
复审会议的成员一般是测试经理、开发经理和销售部门的成员。如果成员认为有必要,则可以按需要邀请其他人参加会议。
变更请求提交表单 - 当首次提交变更请求时,显示该表单。表单上仅显示提交者完成提交所必需的字段。
变更请求组合表单 - 当您在复审已经提交的变更请求时,显示该表单。它包含描述变更请求所必需的所有字段。
以下变更请求流程大纲描述了变更请求在整个流程中的状态,以及在变更请求的生命周期中需要通知哪些人员。在任务:建立变更控制流程中描述了与变更请求相关联的一般流程。
以下示例显示了项目在其生命周期内可能为管理变更请求(CR)采用的任务样本(单击图中各项以查看相应描述):
变更请求管理(CRM)流程任务样本描述:
任务
|
描述
|
职责
|
提交 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 模块环境中的变更请求状态。
|