变更请求(变更请求的四种类型)
变更请求
本文内容来自于互联网，分享变更请求(变更请求的四种类型)
变更请求（CR）用于记录和追踪缺陷、扩展请求和任何其他类型的产品变更请求。变更请求的优点在于，它们提供了决策记录，且其评估的流程还确保了变更的影响可在整个项目范围内得到认同和理解。
目的
变更的必要性是演进中的软件或现有软件系统所固有的。变更控制经理负责确定变更请求管理的过程，维护变更请求（CR），并确保以可控制的方式变更系统，以便预测变更对系统的影响。变更请求可以用于记录和追踪所有类型的系统变更请求，包括扩展请求和缺陷。
系统分析员可以利用扩展请求确定将来要在产品中包含的特性。为了理解涉众需要，在收集涉众请求时，扩展请求将用作输入。
缺陷就是已交付工作产品中的异常情况或瑕疵。缺陷包含诸如在生命周期早期阶段发现的遗漏和缺点，和/或是用于测试或操作的成熟软件中包含的故障症状（瑕疵）。缺陷还包括与预期目的的偏差或任何要加以跟踪并进行解决的问题。
缺陷的目的在于反映问题的细节，以便可以采取纠正措施、解决方法，并跟踪发生的情况。下列人员使用变更请求：
系统分析员，使用确定为扩展请求的变更请求，来确定产品的新特性，
项目经理，使用变更请求分配工作，
测试员，使用变更请求确定和说明在测试过程中发现的缺陷，
实施员，使用变更请求分析缺陷，查找变更请求的故障或起因，
测试设计员，使用变更请求计划核实已解决的变更请求的测试，分析收集的缺陷来评测软件和流程的质量。
管理变更请求工作流程明细
提交变更请求的步骤
完成变更请求表单
变更请求表单是一个正式提交的工件，用于在整个项目周期内跟踪所有的请求（包括新特性、增强请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。进行重复复审和结束项目时都可使用此信息。在工件：变更请求中提供了一个变更请求表单的示例。
提交变更请求
一旦完成 CR 后，它应当通过适当的途径来提交，以确保它符合已建立的变更请求管理流程。项目的任何涉众均可提交变更请求 (CR)。通过将 CR 状态设置为已提交，CR 被记录到 CR 跟踪系统中（例如 ClearQuest）并放置到 CCB 复审队列中。
更新变更请求的步骤
检索变更请求表单
变更请求表单是一个正式提交的工件，用于在整个项目周期内跟踪所有的请求（包括新特性、增强请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。进行重复复审和结束项目时都可使用此信息。在工件：变更请求中提供了一个变更请求表单的示例。
更新并重新提交变更请求
如果评估 CR 需要更多的信息（详细信息），或者如果 CR 在流程中的某个点遭到拒绝（例如，被确认为是重复、拒绝等），那么将通知提交者，并用新的信息来更新 CR。然后将更新过的 CR 重新提交到 CCB 复审队列，以便对其中的新数据进行审议。
提要
在进行与任何已提交的变更请求有关的决策时，以下属性非常实用：
大小
必须要变更的现有工作量是多少？
需要添加的多少新工作量？
备选方案
是否有备选方案？
复杂程度
提议的变更是否容易实现？
变更可能导致哪些连锁反应？
严重性
不实施这个请求的会导致哪些影响？
是否涉及到工作或数据丢失？
是否为扩展请求？
是否为次要的错误？
进度
何时需要进行变更？
是否可行？
影响
进行变更的后果如何？
不进行变更的后果如何？
成本
进行变更的成本或节约的资金是多少？
与其他变更的关系
其他变更是否可以取代此变更或使其无效吗，或者此变更是否依赖于其他变更？
测试
是否存在任何特殊的测试需求？
示例变更请求表
标识信息
项目：
变更请求号：
变更请求类型：（问题或扩展）
标题：
提交日期：
始发人:
变更请求优先级：
当前问题
当前问题的说明：
严重故障：
障碍：
扩展：
新请求：
观察问题的环境：
当前环境：硬件
操作系统
编译器
当前问题的来源：
当前问题的成本影响：
提议的变更（始发人）
提议的变更的说明：
实施提议变更的预计成本：
提议的变更（变更复审团队）
操作：
批准：
不批准：
延期：
提议的变更的说明：
影响的配置项：
类别：
错误修复：
扩展：
新特性：
其他：
解决方案
实施提议变更的预计成本：
实施员：
实施变更的实际时间：
分析：
实施：
测试：
文档：
影响的代码行数：
评估
测试方法：
检查
分析
演示
测试：
测试平台：
测试实例：
变更复审团队的处理
批准的变更和接受的变更：
时机
通常在项目生命周期的初期使 CM 操作制度化或建立 CM 操作。因此，变更请求（CR）作为构成变更流程整体的一部分，可以随时在项目过程中提出。
缺陷的主要来源是运行测试的结果（集成、系统和性能测试）。然而，缺陷可以随时出现在软件开发生命周期过程中，缺陷还可包括缺失的或不完整的用例、测试用例或文档的确认。
职责
有关项目的任何人员都应该可以提出变更请求。然而，变更请求要得到提出变更请求角色上司的复审和批准才能成为合法请求。变更请求的最后仲裁由复审团队或变更控制委员会（CCB）执行。
变更控制经理负责缺陷的完整性，以确保：
所有确定缺陷、说明缺陷和如何发现缺陷的信息都是准确的。
缺陷是唯一的，或不是再次出现的已确定缺陷。
定制
准确确定、说明和追踪缺陷需要的实际字段/数据取决于实施的标准、指南和变更控制系统。
? 1987 - 2001 Rational Software Corporation。版权所有。
变更请求表
在变更管理中，变更请求（CR）是非常重要的。它贯穿变更管理整个过程，不仅是变更管理的输入，同时也是变更管理的输出。同时，变更请求（CR）作为配置管理的配置项内容，是配置管理和变更管理交互和协作的“桥梁”。变更请求（CR）可以由突发事件，服务级别协议等内容的变更需求开始。
变更请求表，是变更请求（CR）的载体，是需要变更的客户与变更管理经理的信息媒体。它主要有以下几个部分组成。
在变更初始阶段，变更请求表需要记录：
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更描述
· 变更原因
· 不实施变更，可能带来的后果
在变更评估阶段，变更请求表主要需要记录：
· 影响和风险评估：影响可以围绕变更管理质量和变更管理带来的好处等实际情况进行设置，例如，可以进行变更管理对项目总进度，项目质量，项目资源等等多个角度，进行影响和资源评估。
· 变更优先权：在进行影响和风险评估后，可以进行变更优先权的设置。
在变更批准阶段，变更请求表主要需要记录：
· 变更咨询委员会的建议和决定。变更咨询委员会是来自于企业的各个部分，有利于综合、客观地评价变更对于企业其他部门的影响。
· 批准签名，也可以使用电子方式。
· 批准的日期
在变更行动计划阶段，变更请求表主要需要记录：
· 变更执行计划，用于详细说明如何进行变更，必要时候，也可以独立于变更请求表。
· 变更负责人
· 变更开始执行时间和完成期限
· 恢复计划（Back-out planning）,一旦变更管理的执行计划没有效果，就需要恢复计划来稳定企业的运作，减少经营风险
在变更执行计划成功一段时间后，变更请求表主要需要记录：
· 变更核查日期（review data）
· 核查结果。
· 企业在连续性等方面影响 如果核查结果显示此次变更是失败的，则将根据现有情况，进行新的变更管理；如果核查结果认为此次变更是成功的，则变更管理结束。
值得大家注意的是，变更管理与配置管理是紧密结合的。变更请求，作为配置项，随着变更管理的开展，配置数据库则不断地进行更新。在数据库中，变更请求还将有一个属性随着变更管理不断变化，那就是变更请求的状态，它可能是“记录的”（logged），“结束的”，“已批准的”等等。 (COSOLU)
