变更控制规程-Read.DOCVIP

变更控制规程 文档编号：ST_CMMI_CCG_PRS-V1.0 文档信息： 文档名称： 文档类别：CMMI模板 密 级：机密 版本信息：V1.0 建立日期：2004-07-21 创 建 人：Soft Tech CMM事业部 审 核 者：Wilson Tan 批 准 人：解明明 批准日期： 保 管 人： 存放位置：/ 编辑软件：Microsoft Office 2003 英文版 CONFIDENTIAL 文档修订记录 版本编号或者更改记录编号 变化状态 简要说明（变更内容和变更范围） 日期 变更人 批准日期 准人 V1.0 C 初次创建 2004-07-21 CMM事业部 *变化状态：C――创建，A——增加，M——修改，D——删除 文档审批信息 序号 审批人 角色 审批日期 签字 备注 前 言 产品的变更是不可避免的，无论何种原因引起变更，都应当遵循一定的变更流程，保证置于配置管理下的产品的完整性和正确性。变更控制的目的不是为了防止变更，而是管理变更，避免产品混乱，从而达到有效控制产品质量的目的。 目 录 第一章 简介 1 1.1 目的 1 1.2 适用范围 1 1.3 术语表 1 1.4 参考资料 1 第二章 变更控制规程 2 2.1 变更权威 2 2.2 基线变更控制 2 2.3 管理文档变更控制 4 简介 目的 本文档描述了项目管理过程中，对基线变更、管理文档的变更，应遵循的规程。 适用范围 本文档适用于公司的所有软件项目。 术语表 正式基线：需求基线和运行基线。对正式基线的变更，必须由CCB控制。 开发基线：也叫非正式基线，指项目开发过程期间建立的基线，如设计和代码基线、测试基线，由项目经理控制。 管理文档：项目开发过程中，为保证开发过程符合CMMI要求而产生的管理文档。如：《软件项目计划》，《软件质量保证计划》，《软件配置管理计划》等。 过程文档：为保证软件开发过程符合CMMI要求而制定的：过程改进方针、过程、规程以及各种模板。如：《软件需求管理方针》，《软件配置管理过程》等。 参考资料  变更控制规程 变更控制规程是对配置库中的基线、管理文档变更的控制规程。 变更权威 每个项目组需要建立项目级的配置控制委员会（即CCB），正式基线的变更必须由项目组的CCB审查和批准，项目软件过程的变更权威是SEPG。 在为SCM作计划时，SCM人员必须定义变更权威及其责任。对大多数新的开发项目，有两个权威：负责正式基线的CCB和负责开发基线的项目经理。 基线变更控制 一旦建立了基线，或配置项置于了配置控制之下，则对该基线提出的所有变更在实施前，要经过指定变更权威的审查。只有当变更请求经过变更权威的批准才能生效，文档的变更信息要维护到文件变更记录表中，并进行版本控制。 要求的变更控制步骤如图1所示，并描述如下。在整个的变更过程中，变更请求状态的每个变化必须在配置库中做记录，达到维护全部的变更历史的目的。 图表 1 变更控制程序 无论是正式基线还是非正式基线（即开发基线），变更流程相同，只是变更权威不同。 提交变更请求 请求者，即提议改变配置项的人从初始化变更请求表（Configuration Change Request简称CCR）开始变更过程。CCR是记录被提议的变更的机制。 请求者填写CCR 清晰地描述变更 阐明变更理由 尽量估计、描述变更带来的影响 请求者把CCR提交给项目经理 接受CCR，项目经理应该： 在《变更日志》中记录CCR，此时问题的状态为“已建议” 审阅CCR，确保提议的变更和理由阐述清晰 把CCR提交给适当的变更权威 评价提议的变更 变更权威必须评估变更带来的影响，包括： 依据需求功能矩阵，识别出受影响的配置项 技术和功能影响 成本和进度影响 变更权威还必须验证变更原因。 评价结果应该在CCR中做出记录。 审阅和批准变更 变更权威应该对评价进行审查，决定是否批准变更，将审批后的CCR交给项目经理。 拒绝变更：项目经理应该通知请求者，同时更新《变更日志》中问题的状态为“已拒绝”。 批准变更：将变更任务分配给相应的处理人员，同时更新《变更日志》中问题的状态为“已批准”。 实施变更 找出变更对象，项目经理把变更任务分配给相应的技术人员，变更处理人将配置项从基线域检出。 变更处理人在工程域修改完毕配置项，将配置项交给项目经理审批。配置项经过审批后，项目经理将《变更日志》中的问题状态置为“已变更”。 变更处理人将审批后的配置项交给SCM人员，将配置项检入到开发域。 对进入开发域的配置项进行质量检查，如测试、评审