变更请求
出自 MBA智库百科(https://wiki.mbalib.com/)
变更请求(Request for Change,RFC)
目录 |
什么是变更请求[1]
变更请求是指一个用于描述来自涉众的对工件或过程进行变更的所有请求的通用术语。变更请求中所记录的是关于起源的信息，以及当前问题的影响、建议的解决方案及其费用。
变更请求是关于修改任何文件、可交付成果或基准的正式提议。如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理。变更请求源自项目内部或外部，是可选或由法律 (合同)强制的。变更请求可能包括:[2]
- 纠正措施。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
- 预防措施。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
- 缺陷补救。为了修正不一致产品或产品组件的有目的的活动。
- 更新。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。
变更请求的分类[1]
变更请求管理过程经常同公司的内部组织密切相关，在这一领域没有标准术语。但是，变更请求经常被分为两个大类：增强请求(Enhancements)和缺陷(Defects)。(用于管理变更的变更请求类型在公司和公司之间差异较大，甚至同一公司内的项目之间也会不一致。这里描述的类型，即缺陷和增强请求仅是最基本类型的变更请求。)
增强请求是指系统的新增特征或对系统“预定设计”行为的变更。缺陷是指“存在于一个已交付产品中的异常现象或缺陷。这样的例子包括在生命周期的早期阶段发现的疏忽和有缺陷的地方，以及在一个足以成熟的用于测试或操作的软件中包含的错误的症状。缺陷可以是任何您想跟踪并解决的问题”。尽管用于维护增强请求和缺陷的许多数据都十分相似，但这两类变更请求在变更请求管理过程上通常用截然不同的方式来处理。
变更请求的目的[3]
变更的必要性是演进中的软件或现有软件系统所固有的。变更控制经理负责确定变更请求管理的过程，维护变更请求（CR），并确保以可控制的方式变更系统，以便预测变更对系统的影响。变更请求可以用于记录和追踪所有类型的系统变更请求，包括扩展请求和缺陷。
系统分析员可以利用扩展请求确定将来要在产品中包含的特性。为了理解涉众需要，在收集涉众请求时，扩展请求将用作输入。
缺陷就是已交付工作产品中的异常情况或瑕疵。缺陷包含诸如在生命周期早期阶段发现的遗漏和缺点，和/或是用于测试或操作的成熟软件中包含的故障症状（瑕疵）。缺陷还包括与预期目的的偏差或任何要加以跟踪并进行解决的问题。
缺陷的目的在于反映问题的细节，以便可以采取纠正措施、解决方法，并跟踪发生的情况。下列人员使用变更请求：
系统分析员，使用确定为扩展请求的变更请求，来确定产品的新特性，
项目经理，使用变更请求分配工作，
测试员，使用变更请求确定和说明在测试过程中发现的缺陷，
实施员，使用变更请求分析缺陷，查找变更请求的故障或起因，
测试设计员，使用变更请求计划核实已解决的变更请求的测试，分析收集的缺陷来评测软件和流程的质量。
变更请求的提要[3]
在进行与任何已提交的变更请求有关的决策时，以下属性非常实用：
大小
必须要变更的现有工作量是多少？
需要添加的多少新工作量？
是否有备选方案？
复杂程度
提议的变更是否容易实现？
变更可能导致哪些连锁反应？
严重性
不实施这个请求的会导致哪些影响？
是否涉及到工作或数据丢失？
是否为扩展请求？
是否为次要的错误？
进度
何时需要进行变更？
是否可行？
影响
进行变更的后果如何？
不进行变更的后果如何？
进行变更的成本或节约的资金是多少？
与其他变更的关系
其他变更是否可以取代此变更或使其无效吗，或者此变更是否依赖于其他变更？
测试
是否存在任何特殊的测试需求？
示例变更请求表
1.标识信息
项目：
变更请求号：
变更请求类型：（问题或扩展）
标题：
提交日期：
始发人:
变更请求优先级：
2.当前问题
当前问题的说明：
严重故障：
障碍：
扩展：
新请求：
观察问题的环境：
当前环境：硬件
操作系统
当前问题的来源：
当前问题的成本影响：
3.提议的变更（始发人）
提议的变更的说明：
实施提议变更的预计成本：
4.提议的变更（变更复审团队）
操作：
批准：
不批准：
延期：
提议的变更的说明：
影响的配置项：
类别：
错误修复：
扩展：
新特性：
其他：
5.解决方案
实施提议变更的预计成本：
实施员：
实施变更的实际时间：
分析：
实施：
测试：
文档：
影响的代码行数：
6.评估
测试方法：
检查
分析
演示
测试：
测试平台：
测试实例：
7.变更复审团队的处理
批准的变更和接受的变更：
变更请求的时机[3]
通常在项目生命周期的初期使 CM 操作制度化或建立 CM 操作。因此，变更请求（CR）作为构成变更流程整体的一部分，可以随时在项目过程中提出。
缺陷的主要来源是运行测试的结果（集成、系统和性能测试）。然而，缺陷可以随时出现在软件开发生命周期过程中，缺陷还可包括缺失的或不完整的用例、测试用例或文档的确认。
变更请求的职责[3]
有关项目的任何人员都应该可以提出变更请求。 然而，变更请求要得到提出变更请求角色上司的复审和批准才能成为合法请求。变更请求的最后仲裁由复审团队或变更控制委员会（CCB）执行。
变更控制经理负责缺陷的完整性，以确保：
缺陷是唯一的，或不是再次出现的已确定缺陷。
变更请求的定制[3]
准确确定、说明和追踪缺陷需要的实际字段/数据取决于实施的标准、指南和变更控制系统。
变更请求的管理[4]
变更请求管理是使软件开发成本降低的最大因素之一，随着对软件开发的要求越来越高，变更量也越来越多，开发人员必须迅速解决变更问题。变更请求管理就需要建立合理的变更流程。实施变更请求管理流程的基本步骤如下：
(1)确定变更请求管理流程执行的范围，然后制定响应的变更流程。
(2)制定变更管理流程的模型。
(3)决定团队各个角色在流程实施中所起的作用。
(4)确定实施计划及开始实施日程。
(5)部署变更请求管理系统。
(6)不断强化变更管理流程。
为了保证整个项目开发的成功，变更请求管理应明确如下问题：
·哪些需求发生了变化?应可提供具有各种重要特征的变更请求信息，且对各种变更请求在处理完毕之前的内容能及时调整，并保证各种请求的信息绝对不能丢失。
·这些需求变化后，对测试工作会产生哪些影响?包括会不会影响测试用例?会不会影响到测试方案?会不会影响到测试计划?应通过对缺陷及其他各种变更的登记、保管、跟踪、解析，达到团队之间的各种变化信息的共有、安全而可靠地高质量变更信息管理系统。
·需求变化后对工作进度产生多大的影响?有效地跟踪各种变更，对管理人员提出各种变更状况的查询请求，做到快而准地提供信息。
·不同变更请求之间的连接关系。对项目整体发展状况，提供宏观及定量的分析，从而能合理分配项目开发人员的工作、合理制订项目的计划、合理管理项目各种请求实施的优先级。
·统计各种项目指标数据，项目管理人员就可以进行更加科学、量化的管理、规划、调配、监控，保证项目如期的进行。
