目的:变更控制过程确保能够一致、受控制地评估和应用对系统提议的变更。
|
子步骤
|
工具向导
|
更多信息:概念:变更请求管理
|
处理变更请求的典型过程显示在下面的活动图中。(单击图的任意位置,获取概念:变更请求管理的完整说明)
变更请求表单是正式提交的工件,用于跟踪所有请求(包含新特性、改进请求、缺陷、变更需求等)。这应包含整个项目生命周期中的相关状态信息。所有的变更历史记录将与 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
|