《CMMI变更控制管理过程》由会员分享，可在线阅读，更多相关《CMMI变更控制管理过程（13页珍藏版）》请在金锄头文库上搜索。
1、变更控制管理过程文档版本号：V0.1文档编号：0001文档密级：归属部门/项目：软件部(*)开发组产品名：子系统名：编写人：班拾红编写日期：2008 年-08-08 日众信上海有限公司 版权所有内部资料 注意保密修订记录：版本号修订人修订日期修订描述V0.1班拾红2008-08-11初始修订版目录1目的与范围 52定义与缩略语 52.1 定义 52.2 缩略语 63 控制机制 64 过程描述 64.1 角色与职责 74.1.1 请求提交角色74.1.2 CCB 组长74.1.2.1 CCB 组长74.1.3 配置管理角色74.1.3.1 测试部配置管理员74.1.3.3配置管理员 错误!未定义
2、书签。4.1.4 分析角色74.1.5 变更实施角色84.1.6 变更验证角色84.1.7 质量保证角色84.1.7.1 QA84.2 入口条件 84.3 输入 84.4 活动 94.4.1 提交阶段94.4.1.1提交请求94.4.1.2 指派分析104.4.2 分析阶段104.4.2.1 分析请求104.4.2.2 提交决策104.4.3 决策阶段104.4.3.1 CCB 决策104.4.3.2 指派实施104.4.4 实施阶段104.4.4.1 实施变更114.4.4.2 提交验证114.4.5 验证阶段114.4.5.1 进行验证114.4.6 关闭阶段124.4.6.1 申请基线1
3、24.4.6.2 审批基线124.4.6.3 基线操作124.5 输出 124.6 出口条件 125 度量 126 裁剪 137 相关工具/表格/记录 13附录：引用 131目的与范围本文件描述软件变更控制管理的规范，向参与变更控制管理活动的人员提供信息和指导 以确保变更经过授权、保证变更后的软件配置项的质量和一致性与完整性、保证变更过程的 可跟踪性和可回溯性，防止配置项被随意修改而导致混乱。本规范适用于公司所有研发类项目（定制开发类项目除外）的变更管理。2 定义与缩略语2.1 定义变更请求：一个用于描述来自涉众人员的对工件或过程进行变更的所有请求的通用术语。变 更请求中所记录的是关于起源的信
4、息以及当前问题的影响、建议的解决方案。变更请求的来源分为四大类：需求变更、设计变更、代码变更、计划变更。需求变更：指系统出现新特征或系统原特征发生改变。设计变更：指对原设计标准状态的改变和修改。设计变更仅包含由于设计工作本身的漏项、 错误或其它原因而修改、补充原设计的技术资料。代码变更：代码变更是由需求变更、设计变更或系统存在的缺陷被发现引起，如果由需求变 更、设计变更引起，需要在变更管理单的任务分配栏填写代码变更任务；如果由缺陷引 起，参见TD管理办法。计划变更：指因项目资源发生改变而引起的计划改变。变更请求管理：一种用来对所请求的变更对现有产品在成本和调度上的影响进行评估时所需 的组织基础
5、结构进行描述的过程。变更请求管理阐述了变更审查组或变更控制委员会的工作 方式。变更严重级别：指对变更严重程度的度量。变更级别分为重大和一般，重大必须走常规变更流程，一般可视情况走裁剪流程，参见6裁剪重大：需求因素：因为需求的增加或删除导致产品版本或补丁项目的需求点列表发生变动，属于重 大变更。设计因素：因为在开发中发现技术方面的问题，不得不修改前期的设计、接口等文档，而且项目计划也要做较大调整，属于重大变更。管理因素：因为项目组资源情况导致项目计划需要进行调整，如果对需求点列表发生变动， 对本项目组对外交付的时间点发生变动，属于重大变更。一般：规范因素：对需求、设计等文档的排版格式、描述做轻微
6、的修改，对配置项本身的定义不造 成影响，属于一般变更。比如增加背景信息、修改语句错别字。管理因素：因为项目组资源情况导致项目计划需要进行调整，仅对本项目组内部人员、任务 安排，或仅对本项目组内开发、测试时间点发生变动，属于一般变更。其它因素: 先走一般变更, 在变更的判断过程中决定是否上升到一级。2.2 缩略语缩略语描述SCMSoftware Configuration Management 软件配置管理PMProject Manager 项目经理PQAProduct Quality Assuranee产品级质量保证人员SQAQuality Assuranee项目级质量保证人员CMConfig
7、uration Management Engineer 配置管理人员TLTeam Leader小组组长3 控制机制本过程的改进由SEPG负责。SEPG负责汇集本过程的改进需求，并完成改进任务。 质量管理部门负责审核本过程的执行情况。4过程描述变更控制是当需要更改已基线化的配置项时所进行的管理和控制活动，即对一个正式的 变更请求进行评估、分析并通过严格的流程对变更活动进行控制和记录的过程。对基线的变更活动必须从提交一个正式的变更请求开始，变更控制过程是通过对变更请 求的处理与状态控制来实现的。所有的变更请求都有一个从提交、分析、决策、实施、验证 直至关闭的过程，这一过程构成了变更请求的生命周期。
8、4.1 角色与职责4.1.1 请求提交角色 提交角色是变更请求的发起人，项目或产品中的任何角色都可以通过提交一个变更 请求而成为提交角色。 填写完整变更管理单中的请求部分并提交4.1.2 CCB 组长4.1.2.1 CCB 组长 接收处理需求类变更和影响产品交付时间的计划类变更（接收和处理产品级基线的 变更）； 确认变更请求的有效性； 指派变更请求的分析角色； 接收完成分析后的变更管理单 根据分析结果决策是否接受该变更，对接受变更的每项任务分配变更实施角色； 组织与之相关的评审和验证活动； 对变更结果进行验证，审批基线申请。4.1.3 配置管理角色4.1.3.1测试部配置管理员 测试部配置管理
9、员承担公司级配置管理职责； 控制产品接口类基线及系统测试类基线；具体参见版本PATCH配置管理操作指导 书3.1.3.1 角色与职责 对与之相关的评审和验证活动进行跟踪并做报告； 对通过变更验证的源代码更新基线，关闭该部分的变更。4.1.3.2 产品配置管理员控制需求类基线；具体参见版本PATCH配置管理操作指导书1.3.1角色与职责 将变更任务通知变更实施角色； 对与之相关的评审和验证活动进行跟踪并做报告； 对通过变更验证的需求和计划重新基线，并发布报告；对总的变更管理单进行关闭 操作。4.1.4 分析角色对变更请求进行分析，分析的要素参见变更管理单模板；填写变更请求中以下信息：变更影响，变
10、更范围，变更文档，变更的工作量信息4.1.5 变更实施角色 负责更新待变更的配置项； 根据CCB指派的变更任务，对配置项实施变更； 将变更后的配置项提交验证，并根据验证返回结果重新修改配置项，直到验证通过 将验证通过后的配置项提交新的基线申请。4.1.6变更验证角色 对变更后的配置项进行验证，保证验证变更结果的正确性及变更结果与分析评估结果的 一致性。4.1.7 质量保证角色4.1.7.1 PQA 对变更过程进行引导； 对产品级的变更结果进行审计。确保需求变更活动符合既定的规程。不同的配置项变更，审批、决策变更的 CCB 角色和处理基线的配置管理角色会有所不同 具体操作参见版本PATCH配置管
11、理操作指导书1.3.基线控制3.1.3.1角色与职责，4.2 入口条件已经基线的配置项出现变更需求4.3 输入变更管理单4.4 活动流程图）4.4.1提交阶段提交阶段是变更请求的发起人发现问题并在变更控制系统中提交变更请求的阶段。 变更请求的记录一旦被提交，即将进入分析阶段。提交阶段记录的信息包括变更请求的标题、提交人、提交时间、问题的详细描述以及问 题的严重性。4.4.1.1 提交请求需要对曾经进行过基线的配置项进行变更时，由请求提交角色填写变更管理单中的请求部分，描述清楚变更类型、严重级及优先级等基本信息，然后提交给CCB组长。CCB组 长根据变更严重级别（参见2.1定义）进行判断采用常规
12、流程还是裁减后的流程（参见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 组长选择决策方式：会议方
13、式：对于严重级别为重大的变更，由CCB组长组织召开CCB会议，讨论决策。 直接裁决：对于严重级别为一般的变更，可以由CCB组长直接裁决。 决策后填写变更管理单中的决策部分，由配置管理员将信息知会到相关人员。4.4.3.2 指派实施如果 CCB 决策同意该变更请求， CCB 需要对同意变更的配置项指派变更实施角色，填写 变更管理单任务分配表部分，将该变更管理单发送给配置管理角色归档，由配置管 理员将任务通知到变更实施角色。4.4.4 实施阶段实施阶段将由变更实施角色实施所有的变更活动。4.4.4.1 实施变更变更实施角色收到变更任务通知后，Checkout已经基线的配置项，对配置项实施变更操 作
14、。4.4.4.2 提交验证如果变更的配置项是文档，变更实施角色完成变更操作后，将变更后的配置项提交给CCB 组长组织评审。如果变更的配置项是源代码，变更实施角色完成变更操作后，直接将变更后的配置项提 交给变更验证角色。4.4.5验证阶段4.4.5.1 进行验证如果变更的配置项是文档，采用评审作为验证手段；由CCB组长组织评审活动。评审遵循评审规范。当最终评审结果为通过，即可提交基线申请进入关闭阶段；当最终评审结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交评 审，直至验证结果为通过。备注：1) 当变更的严重级别为一般，变更的内容较少、影响较小时，可以通过CCB组长或相 关责任人邮件确认替代评审。2) 评审需知会配置管理员角色，以便对变更的进度进行报告。如果变更的配置项是源代码，采用测试作为验证手段；由测试人员担当变更验证角色，进行测试活动。测试遵循测试过程。当最终测试结果为通过，即可提交基线申请进入关闭阶段；当最终测试结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交测 试，直至测试结果为通过。4.4.6关闭阶段4.4.6.1 申请基线验证结束并通过后，变更实施者 checkin 通过验证的配置项，填写基线申请/发布电子流 中
