CMMI变更控制管理过程

1 目的与范围    5

2 定义与缩略语    5

2.1 定义    5

2.2 缩略语    6

3 控制机制    6

4 过程描述    6

4.1 角色与职责    7

4.1.1 请求提交角色    7

4.1.2 CCB组长    7

4.1.2.1 CCB组长    7

4.1.3 配置管理角色    7

4.1.3.1 测试部配置管理员    7

4.1.3.3 配置管理员    8

4.1.4 分析角色    8

4.1.5 变更实施角色    8

4.1.6 变更验证角色    8

4.1.7 质量保证角色    8

4.1.7.1 QA    8

4.2 入口条件    9

4.3 输入    9

4.4 活动    9

4.4.1 提交阶段    10

4.4.1.1 提交请求    10

4.4.1.2 指派分析    10

4.4.2 分析阶段    10

4.4.2.1 分析请求    10

4.4.2.2 提交决策    10

4.4.3 决策阶段    10

4.4.3.1 CCB决策    10

4.4.3.2 指派实施    11

4.4.4 实施阶段    11

4.4.4.1 实施变更    11

4.4.4.2 提交验证    11

4.4.5 验证阶段    11

4.4.5.1 进行验证    11

4.4.6 关闭阶段    12

4.4.6.1 申请基线    12

4.4.6.2 审批基线    12

4.4.6.3 基线操作    12

4.5 输出    12

4.6 出口条件    12

5 度量    13

6 裁剪    13

7 相关工具/表格/记录    13

附录：引用    14

1 目的与范围

本文件描述软件变更控制管理的规范，向参与变更控制管理活动的人员提供信息和指导，以确保变更经过授权、保证变更后的软件配置项的质量和一致性与完整性、保证变更过程的可跟踪性和可回溯性，防止配置项被随意修改而导致混乱。

本规范适用于公司所有研发类项目（定制开发类项目除外）的变更管理。

2 定义与缩略语

2.1 定义

变更请求：一个用于描述来自涉众人员的对工件或过程进行变更的所有请求的通用术语。变更请求中所记录的是关于起源的信息以及当前问题的影响、建议的解决方案。

变更请求的来源分为四大类：需求变更、设计变更、代码变更、计划变更。

需求变更：指系统出现新特征或系统原特征发生改变。

设计变更：指对原设计标准状态的改变和修改。设计变更仅包含由于设计工作本身的漏项、错误或其它原因而修改、补充原设计的技术资料。

代码变更：代码变更是由需求变更、设计变更或系统存在的缺陷被发现引起，如果由需求变更、设计变更引起，需要在《变更管理单》的任务分配栏填写代码变更任务；如果由缺陷引起，参见《TD管理办法》。

计划变更：指因项目资源发生改变而引起的计划改变。

变更请求管理：一种用来对所请求的变更对现有产品在成本和调度上的影响进行评估时所需的组织基础结构进行描述的过程。变更请求管理阐述了变更审查组或变更控制委员会的工作方式。

变更严重级别：指对变更严重程度的度量。

变更级别分为重大和一般，重大必须走常规变更流程，一般可视情况走裁剪流程，参见6裁剪。

重大：

需求因素：因为需求的增加或删除导致产品版本或补丁项目的需求点列表发生变动，属于重大变更。

设计因素：因为在开发中发现技术方面的问题，不得不修改前期的设计、接口等文档，而且项目计划也要做较大调整，属于重大变更。

管理因素：因为项目组资源情况导致项目计划需要进行调整，如果对需求点列表发生变动，对本项目组对外交付的时间点发生变动，属于重大变更。

一般：

规范因素：对需求、设计等文档的排版格式、描述做轻微的修改，对配置项本身的定义不造成影响，属于一般变更。比如增加背景信息、修改语句错别字。

管理因素：因为项目组资源情况导致项目计划需要进行调整，仅对本项目组内部人员、任务安排，或仅对本项目组内开发、测试时间点发生变动，属于一般变更。

其它因素: 先走一般变更, 在变更的判断过程中决定是否上升到一级。

2.2 缩略语

本过程的改进由SEPG负责。

SEPG负责汇集本过程的改进需求，并完成改进任务。

质量管理部门负责审核本过程的执行情况。

4 过程描述

变更控制是当需要更改已基线化的配置项时所进行的管理和控制活动，即对一个正式的变更请求进行评估、分析并通过严格的流程对变更活动进行控制和记录的过程。

对基线的变更活动必须从提交一个正式的变更请求开始，变更控制过程是通过对变更请求的处理与状态控制来实现的。所有的变更请求都有一个从提交、分析、决策、实施、验证直至关闭的过程，这一过程构成了变更请求的生命周期。

4.1 角色与职责

4.1.1 请求提交角色

●提交角色是变更请求的发起人，项目或产品中的任何角色都可以通过提交一个变更请求而成为提交角色。

●填写完整《变更管理单》中的请求部分并提交

4.1.2 CCB组长

4.1.2.1 CCB组长

●接收处理需求类变更和影响产品交付时间的计划类变更（接收和处理产品级基线的变更）；

●确认变更请求的有效性；

●指派变更请求的分析角色；

●接收完成分析后的<变更管理单>

●根据分析结果决策是否接受该变更，对接受变更的每项任务分配变更实施角色；

●组织与之相关的评审和验证活动；

●对变更结果进行验证，审批基线申请。

4.1.3 配置管理角色

4.1.3.1 测试部配置管理员

●测试部配置管理员承担公司级配置管理职责；

●控制产品接口类基线及系统测试类基线；具体参见《版本/PATCH配置管理操作指导书》3.1.3.1角色与职责

●对与之相关的评审和验证活动进行跟踪并做报告；

●对通过变更验证的源代码更新基线，关闭该部分的变更。

4.1.3.2 产品配置管理员

●控制需求类基线；具体参见《版本/PATCH配置管理操作指导书》3.1.3.1角色与职责

●将变更任务通知变更实施角色；

●对与之相关的评审和验证活动进行跟踪并做报告；

●对通过变更验证的需求和计划重新基线，并发布报告；对总的变更管理单进行关闭操作。

●

4.1.4 分析角色

对变更请求进行分析，分析的要素参见<变更管理单>模板；

填写变更请求中以下信息：变更影响，变更范围，变更文档，变更的工作量信息

4.1.5 变更实施角色

●负责更新待变更的配置项；

●根据CCB指派的变更任务，对配置项实施变更；

●将变更后的配置项提交验证，并根据验证返回结果重新修改配置项，直到验证通过；

●将验证通过后的配置项提交新的基线申请。

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 提交阶段

提交阶段是变更请求的发起人发现问题并在变更控制系统中提交变更请求的阶段。

变更请求的记录一旦被提交，即将进入分析阶段。

提交阶段记录的信息包括变更请求的标题、提交人、提交时间、问题的详细描述以及问题的严重性。

4.4.1.1 提交请求

需要对曾经进行过基线的配置项进行变更时，由请求提交角色填写《变更管理单》中的请求部分，描述清楚变更类型、严重级及优先级等基本信息，然后提交给CCB组长。CCB组长根据变更严重级别(参见2.1定义))进行判断采用常规流程还是裁减后的流程（参见6裁减）。

4.4.1.2 指派分析

CCB组长根据《变更管理单》中的申请指派分析角色。

4.4.2 分析阶段

4.4.2.1 分析请求

分析角色对变更请求进行分析，填写《变更管理单》中的分析部分。

4.4.2.2 提交决策

完成请求分析后，由分析角色将《变更管理单》提交给CCB组长。

4.4.3 决策阶段

决策阶段将根据分析结果衡量变更将造成的影响，然后确定将对变更请求采取的处理方法。

CCB对变更请求有两种处理方法：

同意：同意对当前基线中的配置项进行变更，允许进入变更实施阶段

拒绝：不实施变更，关闭该变更请求

4.4.3.1 CCB决策

根据变更的严重级别，由CCB组长选择决策方式：

会议方式：对于严重级别为重大的变更，由CCB组长组织召开CCB会议，讨论决策。

直接裁决：对于严重级别为一般的变更，可以由CCB组长直接裁决。

决策后填写《变更管理单》中的决策部分，由配置管理员将信息知会到相关人员。

4.4.3.2 指派实施

如果CCB决策同意该变更请求，CCB需要对同意变更的配置项指派变更实施角色，填写《变更管理单》任务分配表部分，将该《变更管理单》发送给配置管理角色归档，由配置管理员将任务通知到变更实施角色。

4.4.4 实施阶段

实施阶段将由变更实施角色实施所有的变更活动。

4.4.4.1 实施变更

变更实施角色收到变更任务通知后，Checkout已经基线的配置项，对配置项实施变更操作。

4.4.4.2 提交验证

如果变更的配置项是文档，变更实施角色完成变更操作后，将变更后的配置项提交给CCB组长组织评审。

如果变更的配置项是源代码，变更实施角色完成变更操作后，直接将变更后的配置项提交给变更验证角色。

4.4.5 验证阶段

4.4.5.1 进行验证

如果变更的配置项是文档，采用评审作为验证手段；

由CCB组长组织评审活动。评审遵循《评审规范》。

当最终评审结果为通过，即可提交基线申请进入关闭阶段；

当最终评审结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交评审，直至验证结果为通过。

备注：

1)当变更的严重级别为一般，变更的内容较少、影响较小时，可以通过CCB组长或相关责任人邮件确认替代评审。

2)评审需知会配置管理员角色，以便对变更的进度进行报告。

如果变更的配置项是源代码，采用测试作为验证手段；

由测试人员担当变更验证角色，进行测试活动。测试遵循《测试过程》。

当最终测试结果为通过，即可提交基线申请进入关闭阶段；

当最终测试结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交测试，直至测试结果为通过。

4.4.6 关闭阶段

4.4.6.1 申请基线

验证结束并通过后，变更实施者checkin通过验证的配置项，填写《基线申请/发布电子流》中的基线申请内容，提交给CCB。

4.4.6.2 审批基线

CCB根据验证结果审批是否同意该基线申请。由CCB组长在《基线申请/发布电子流》中填写审批意见后将《基线申请/发布电子流》交给配置管理角色。

如果审批意见为通过，配置管理角色就可以对变更后的配置项进行基线操作；

如果审批意见为不通过，该配置项重新提交验证。

4.4.6.3 基线操作

配置管理角色对申请基线操作的配置项进行基线操作，填写《基线申请/发布电子流》中的发布信息内容，并邮件知会所有相关人员。

4.5 输出

《变更管理单》

《基线申请/发布电子流》

重新基线的配置项

4.6 出口条件

《变更管理单》内所有的变更任务已经完成，重新基线并发布。

5 度量

上述常规流程中定义了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配置管理操作指导书》

《评审规范》

《测试过程》