变更请求
变更请求（CR）用于记录和追踪缺陷、扩展请求和任何其他类型的产品变更请求。变更请求的优点在于，它们提供
变更请求（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）的载体，是需要变更的客户与变更管理经理的信息媒体。它主要有以下几个部分组成。
在变更初始阶段，变更请求表需要记录：
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更描述
· 变更原因
· 不实施变更，可能带来的后果
在变更评估阶段，变更请求表主要需要记录：
· 影响和风险评估：影响可以围绕变更管理质量和变更管理带来的好处等实际情况进行设置，例如，可以进行变更管理对项目总进度，项目质量，项目资源等等多个角度，进行影响和资源评估。
目的 变更的必要性是演进中的软件或现有软件系统所固有的。变更控制经理负责确定变更请求管理的过程，维护变更请求（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）的载体，是需要变更的客户与变更管理经理的信息媒体。它主要有以下几个部分组成。
在变更初始阶段，变更请求表需要记录：
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更请求号，如果与问题管理相关，还需要记录相关的问题号
· 变更描述
· 变更原因
· 不实施变更，可能带来的后果
在变更评估阶段，变更请求表主要需要记录：
· 影响和风险评估：影响可以围绕变更管理质量和变更管理带来的好处等实际情况进行设置，例如，可以进行变更管理对项目总进度，项目质量，项目资源等等多个角度，进行影响和资源评估。