软件变更控制规范.docx

1、软件变更控制规范软件变更控制规范1 目的与范围本文件描述软件变更控制管理的规范，向参与变更控制管理活动的人员提供信息和指导，以确保变更经过授权、保证变更后的软件配置项的质量和一致性与完整性、保证变更过程的可跟踪性和可回溯性，防止配置项被随意修改而导致混乱。本规范适用于公司所有研发类项目（定制开发类项目除外）的变更管理。2 定义与缩略语2.1 定义变更请求：一个用于描述来自涉众人员的对工件或过程进行变更的所有请求的通用术语。变更请求中所记录的是关于起源的信息以及当前问题的影响、建议的解决方案。变更请求的来源分为四大类：需求变更、设计变更、代码变更、计划变更。需求变更：指系统出现新特征或系统原特征

2、发生改变。设计变更：指对原设计标准状态的改变和修改。设计变更仅包含由于设计工作本身的漏项、错误或其它原因而修改、补充原设计的技术资料。代码变更：代码变更是由需求变更、设计变更或系统存在的缺陷被发现引起，如果由需求变更、设计变更引起，需要在变更管理单的任务分配栏填写代码变更任务；如果由缺陷引起，参见TD管理办法。计划变更：指因项目资源发生改变而引起的计划改变。变更请求管理：一种用来对所请求的变更对现有产品在成本和调度上的影响进行评估时所需的组织基础结构进行描述的过程。变更请求管理阐述了变更审查组或变更控制委员会的工作方式。变更严重级别：指对变更严重程度的度量。变更级别分为重大和一般，重大必须走常

3、规变更流程，一般可视情况走裁剪流程，参见6裁剪。重大：需求因素：因为需求的增加或删除导致产品版本或补丁项目的需求点列表发生变动，属于重大变更。设计因素：因为在开发中发现技术方面的问题，不得不修改前期的设计、接口等文档，而且项目计划也要做较大调整，属于重大变更。管理因素：因为项目组资源情况导致项目计划需要进行调整，如果对需求点列表发生变动，对本项目组对外交付的时间点发生变动，属于重大变更。一般：规范因素：对需求、设计等文档的排版格式、描述做轻微的修改，对配置项本身的定义不造成影响，属于一般变更。比如增加背景信息、修改语句错别字。管理因素：因为项目组资源情况导致项目计划需要进行调整，仅对本项目组内

4、部人员、任务安排，或仅对本项目组内开发、测试时间点发生变动，属于一般变更。其它因素: 先走一般变更, 在变更的判断过程中决定是否上升到一级。2.2 缩略语缩略语描述SCMSoftware Configuration Management 软件配置管理CCBChange Control Board 变更控制委员会PMProject Manager 项目经理PQAProduct Quality Assurance 产品级质量保证人员SQAQuality Assurance 项目级质量保证人员CMConfiguration Management Engineer 配置管理人员TLTeam Leade

5、r 小组组长3 控制机制本过程的改进由SEPG负责。SEPG负责汇集本过程的改进需求，并完成改进任务。质量管理部门负责审核本过程的执行情况。4 过程描述变更控制是当需要更改已基线化的配置项时所进行的管理和控制活动，即对一个正式的变更请求进行评估、分析并通过严格的流程对变更活动进行控制和记录的过程。对基线的变更活动必须从提交一个正式的变更请求开始，变更控制过程是通过对变更请求的处理与状态控制来实现的。所有的变更请求都有一个从提交、分析、决策、实施、验证直至关闭的过程，这一过程构成了变更请求的生命周期。4.1 角色与职责4.1.1 请求提交角色提交角色是变更请求的发起人，项目或产品中的任何角色都可

6、以通过提交一个变更请求而成为提交角色。填写完整变更管理单中的请求部分并提交4.1.2 CCB组长4.1.2.1 CCB组长接收处理需求类变更和影响产品交付时间的计划类变更（接收和处理产品级基线的变更）；确认变更请求的有效性；指派变更请求的分析角色；接收完成分析后的根据分析结果决策是否接受该变更，对接受变更的每项任务分配变更实施角色；组织与之相关的评审和验证活动；对变更结果进行验证，审批基线申请。4.1.3 配置管理角色4.1.3.1 测试部配置管理员测试部配置管理员承担公司级配置管理职责；控制产品接口类基线及系统测试类基线；具体参见版本/PATCH配置管理操作指导书3.1.3.1角色与职责对与

7、之相关的评审和验证活动进行跟踪并做报告；对通过变更验证的源代码更新基线，关闭该部分的变更。4.1.3.2 产品配置管理员控制需求类基线；具体参见版本/PATCH配置管理操作指导书3.1.3.1角色与职责将变更任务通知变更实施角色；对与之相关的评审和验证活动进行跟踪并做报告；对通过变更验证的需求和计划重新基线，并发布报告；对总的变更管理单进行关闭操作。4.1.4 分析角色对变更请求进行分析，分析的要素参见模板；填写变更请求中以下信息：变更影响，变更范围，变更文档，变更的工作量信息4.1.5 变更实施角色负责更新待变更的配置项；根据CCB指派的变更任务，对配置项实施变更；将变更后的配置项提交验证，

8、并根据验证返回结果重新修改配置项，直到验证通过；将验证通过后的配置项提交新的基线申请。4.1.6 变更验证角色对变更后的配置项进行验证，保证验证变更结果的正确性及变更结果与分析评估结果的一致性。4.1.7 质量保证角色4.1.7.1 PQA对变更过程进行引导；对产品级的变更结果进行审计。确保需求变更活动符合既定的规程。不同的配置项变更，审批、决策变更的CCB角色和处理基线的配置管理角色会有所不同，具体操作参见版本/PATCH配置管理操作指导书3.1.3.基线控制3.1.3.1角色与职责。4.2 入口条件已经基线的配置项出现变更需求4.3 输入变更管理单4.4 活动（流程图）4.4.1 提交阶段

9、提交阶段是变更请求的发起人发现问题并在变更控制系统中提交变更请求的阶段。变更请求的记录一旦被提交，即将进入分析阶段。提交阶段记录的信息包括变更请求的标题、提交人、提交时间、问题的详细描述以及问题的严重性。4.4.1.1 提交请求需要对曾经进行过基线的配置项进行变更时，由请求提交角色填写变更管理单中的请求部分，描述清楚变更类型、严重级及优先级等基本信息，然后提交给CCB组长。CCB组长根据变更严重级别(参见2.1定义)进行判断采用常规流程还是裁减后的流程（参见6裁减）。4.4.1.2 指派分析CCB组长根据变更管理单中的申请指派分析角色。4.4.2 分析阶段4.4.2.1 分析请求分析角色对变更

10、请求进行分析，填写变更管理单中的分析部分。4.4.2.2 提交决策完成请求分析后，由分析角色将变更管理单提交给CCB组长。4.4.3 决策阶段决策阶段将根据分析结果衡量变更将造成的影响，然后确定将对变更请求采取的处理方法。CCB对变更请求有两种处理方法：同意：同意对当前基线中的配置项进行变更，允许进入变更实施阶段拒绝：不实施变更，关闭该变更请求4.4.3.1 CCB决策根据变更的严重级别，由CCB组长选择决策方式：会议方式：对于严重级别为重大的变更，由CCB组长组织召开CCB会议，讨论决策。直接裁决：对于严重级别为一般的变更，可以由CCB组长直接裁决。决策后填写变更管理单中的决策部分，由配置管

11、理员将信息知会到相关人员。4.4.3.2 指派实施如果CCB决策同意该变更请求，CCB需要对同意变更的配置项指派变更实施角色，填写变更管理单任务分配表部分，将该变更管理单发送给配置管理角色归档，由配置管理员将任务通知到变更实施角色。4.4.4 实施阶段实施阶段将由变更实施角色实施所有的变更活动。4.4.4.1 实施变更变更实施角色收到变更任务通知后，Checkout已经基线的配置项，对配置项实施变更操作。4.4.4.2 提交验证如果变更的配置项是文档，变更实施角色完成变更操作后，将变更后的配置项提交给CCB组长组织评审。如果变更的配置项是源代码，变更实施角色完成变更操作后，直接将变更后的配置项

12、提交给变更验证角色。4.4.5 验证阶段4.4.5.1 进行验证如果变更的配置项是文档，采用评审作为验证手段；由CCB组长组织评审活动。评审遵循评审规范。当最终评审结果为通过，即可提交基线申请进入关闭阶段；当最终评审结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交评审，直至验证结果为通过。备注：1)当变更的严重级别为一般，变更的内容较少、影响较小时，可以通过CCB组长或相关责任人邮件确认替代评审。2)评审需知会配置管理员角色，以便对变更的进度进行报告。如果变更的配置项是源代码，采用测试作为验证手段；由测试人员担当变更验证角色，进行测试活动。测试遵循测试过程。当最终测试结果为通过

13、，即可提交基线申请进入关闭阶段；当最终测试结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交测试，直至测试结果为通过。4.4.6 关闭阶段4.4.6.1 申请基线验证结束并通过后，变更实施者checkin通过验证的配置项，填写基线申请/发布电子流中的基线申请内容，提交给CCB。4.4.6.2 审批基线CCB根据验证结果审批是否同意该基线申请。由CCB组长在基线申请/发布电子流中填写审批意见后将基线申请/发布电子流交给配置管理角色。如果审批意见为通过，配置管理角色就可以对变更后的配置项进行基线操作；如果审批意见为不通过，该配置项重新提交验证。4.4.6.3 基线操作配置管理角色对申

14、请基线操作的配置项进行基线操作，填写基线申请/发布电子流中的发布信息内容，并邮件知会所有相关人员。4.5 输出变更管理单基线申请/发布电子流重新基线的配置项4.6 出口条件变更管理单内所有的变更任务已经完成，重新基线并发布。5 度量度量项名称分析阶段处理时长决策阶段处理时长验证阶段处理时长公式(分析阶段实际结束时间-提交阶段实际结束时间) (决策阶段实际结束时间-分析阶段实际结束时间)(验证阶段实际结束时间-决策阶段实际结束时间)目的收集平均处理时长作为参考标准收集平均处理时长作为参考标准收集平均处理时长作为参考标准收集频率每月每月每月何时收集月底月底月底6 裁剪上述常规流程中定义了6个阶段12个活动，适用于所有变更；1.提交请求2.指派分析3.分析请求4.提交决策5.CCB决策6.指派实施7.实施变更8.提交验证9.进行验证10.申请基线11.审批基线12.基线操作仅当提交申请的变更所造成影响的严重级别(对重级别的定义见2.1定义)为一般时，可以由CCB组长决定变更是否采用以下裁减后的简易流程：1.提交请求2.CCB决策3.指派实施4.实施变更5.申请基线6.审批基线7.基线操作7 相关工具/表格/记录变更管理单基线申请/发布电子流附录：引用TD管理办法版本/PATCH配置管理操作指导书评审规范测试过程