任务:确定变更控制流程
此任务定义了如何创建“变更控制流程”。
用途

拥有标准的、已记载的变更控制流程的目的是为了确保一个项目内作出的变更能够保持一致,并确保能够将产品的状态、对产品作出的变更以及这些变更的成本和日程安排影响通知相应的项目干系人。

关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
步骤
建立变更请求流程

处理变更请求的典型过程显示在下面的活动图中。(单击图的任意位置,获取概念:变更请求管理的完整说明)

管理 CR 的样本任务 回到页首

概念:变更请求管理 在提交者、CCB、分配的工作者和测试员之间流动的 CR 流程。

完成变更请求表单 回到页首

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

变更请求可能经过的典型状态显示在以下状态表图中。(单击图的任意位置,获取概念:变更请求管理的完整说明)

CR 的样本状态和转换 回到页首

概念:变更请求管理 新建 CR 的流程。可能的状态包括“已提交”、“已延迟”、“已打开”、“已拒绝”、“已分配”、“已解决”和“已验证”。

分析变更请求 回到页首

变更请求一旦提交就对其进行分析,确保它是真正有效的,并确保相应的技术和管理人员能复审变更请求以评估其有效性。变更请求需要在开发团队内进行多个级别的复审。团队负责人将经常复审和核准任何他的团队成员提交的变更请求。但是,如果变更的范围超出了团队的职责,变更就升级到下一级别的复审。如果变更的影响范围扩展到数个不同的开发团队,该变更就由变更控制委员会复审。在 Rational Unified Process 中,变更控制管理员角色用于代表变更控制委员会(CCB)的角色。

有时,报告的系统故障更有可能是因为系统的用途,而不是与系统实施有关。也有可能是这种情况:已经报告了问题,正在进行处理。

分析步骤的结果是接受变更请求或者,如果请求无效、重复或不在当前的项目远景或管辖范围内,就拒绝请求。

评估变更请求的成本 回到页首

对于有效的变更,下一步骤是根据变更对整个系统的影响以及实现该变更的容易程度,对变更进行评估和成本计算。

成本计算步骤的输入提供给 CCB 用于评估。CCB 从策略、组织以及技术的角度复审变更请求及其影响。CCB 必须确定变更请求从经济的角度而言是否正当合理。

应用变更请求 回到页首

变更请求一旦得到核准就可以应用于软件了。 然后修订后的软件就进行质量保证检查,以确保作出的变更与项目采用的做法相一致,并确保不会对现有软件的其他部分有不利的影响。

一旦作出变更,软件的新版本就在产品的测试工作版本中进行验证,然后合并到整个软件的“发行版”版本并在其中进行验证。

维护变更历史记录 回到页首

对软件作出变更后,必须维护所有变更的记录,这一点很重要。

维护变更历史记录的有效方法是在每个软件组件的开始时、在变更请求内进行。

要在组件头中维护的那类变更数据的示例可以是:

修改历史记录

版本 修改者 日期 变更原因

1.1 Bruce Bogtrotter 98.05.01 测试范围 CR#232

1.2 Maria Mussolini 98.06.02 需求 CR#454

建立变更控制委员会
用途 建立变更控制委员会(CCB),负责核准对基线配置项作出的所有变更。小组的目的是确保所有提议的变更都得到适当的技术分析和复审,并进行记载以用于跟踪和审计。 
子步骤

CCB 举行定期会议,并可以按需要举行会议。

CCB 的基本任务是宣布产品基线、复审对基线的变更以及核准、否决或推迟变更的实施。

选择成员 回到页首

这一步骤的目的是设立一个由“合适的人”组成的 CCB,他们在同事中有真正的权威,他们还要有足够的专业特长来避免不明智的或成本太高的变更提议。CCB 需要由所有受影响的组织或项目干系人的代表组成,如:

  • 用户
  • 开发人员
  • 测试组
  • 项目管理

任命 CCB 主席 回到页首

CCB 的主席必须来自项目管理办公室。主席应该能毫不含糊地解决团队内的冲突,并将团队的决策实施到项目中。

只要有可能,CCB 的决策就应该得到一致同意。小组的动态性反映开发项目的合作本质。主席的角色是增强这种合作远景,并且在必要时采取单方面行动。

开会评估变更建议 回到页首

CCB 必须定期开会,并按需要举行会议以确保变更提议能得到及时的复审和处理。开发团队必须将该小组视为能够解决问题(如果得不到解决,这些问题可能使项目进度陷入死锁状态)的可靠团体。

定义变更复审通知协议
用途 变更复审通知协议的目的是确保提交变更请求时能通知相应的团队成员。
确定应由谁来复审各种工作产品。 
工具向导:  使用 Rational ClearQuest 定义变更和复审通知

这一步骤的输入是在项目过程中要开发的工作产品列表。

团队成员需要复审与产品相关的工作产品,来决定它们是否满足已定义的项目质量标准,只有满足了这些标准才能进入下一个开发阶段。如果产品没有通过复审,就需要重新制作、进行变更并重新复审。

为了让复审“有效”,产品评估人员必须合适而且了解被提议的变更或扩展的范围和影响。而且,复审需要做到“成本有效”,这样关键的实施者和集成者的工作时间就不会浪费在产生“低影响”的缺陷上。

需要参加复审的团队成员是来自“产品”制造者、使用者和管理方面的代表。这是为了确保对产品质量存在即定兴趣的所有项目干系人都可以决定产品是否可以前进到下一级别的开发。

在团队环境中,整个项目分成几个活动。活动分配给责任人进行实施和集成。例如,整个系统分为子系统,然后再分为单个包。负责实施包的团队成员需要确保他们的变更得到子系统内的同事以及其他系统中可能会受变更影响的所有其他人的复审。

复审和变更通知原则是为了与同事和团队负责人以及提议的变更的接收者进行交流,并使他们有机会对提议进行复审和评论。

概念:变更请求管理中提供了有关该主题的进一步指导。


 

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息