软件变更控制规范

版本更改类型生效日期更改内容XX有限公司版本文件编号生效日期A0XXXX目的：本文件描述软件变更控制管理的规范，向参与变更控制管理活动的人员提供信息和指导，以确保变更经过授权、保证变更后的软件配置项的质量和一致性与完整性、保证变更过程的可跟踪性和可回溯性，防止配置项被随意修改而导致混乱。范围：本规范适用于公司所有研发类项目（定制开发类项目除外）的变更管理。定义：3.1变更请求：一个用于描述来自涉众人员的对工件或过程进行变更的所有请求的通用术语。变更请求中所记录的是关于起源的信息以及当前问题的影响、建议的解决方案。变更请求的来源分为四大类：需求变更、设计变更、代码变更、计划变更。3.2需求变更：指系统出现新特征或系统原特征发生改变。设计变更：指对原设计标准状态的改变和修改。设计变更仅包含由于设计工作本身的漏项、错误或其它原因而修改、补充原设计的技术资料。3.3代码变更：代码变更是由需求变更、设计变更或系统存在的缺陷被发现引起，如果由需求变更、设计变更引起，需要在《变更管理单》的任务分配栏填写代码变更任务；如果由缺陷引起，参见《TD管理办法》。3.4计划变更：指因项目资源发生改变而引起的计划改变。3.5变更请求管理：一种用来对所请求的变更对现有产品在成本和调度上的影响进行评估时所需的组织基础结构进行描述的过程。变更请求管理阐述了变更审查组或变更控制委员会的工作方式。3.6变更严重级别：指对变更严重程度的度量。变更级别分为重大和一般，重大必须走常规变更流程，一般可视情况走裁剪流程，参见裁剪。重大：需求因素：因为需求的增加或删除导致产品版本或补丁项目的需求点列表发生变动，属于重大变更。设计因素：因为在开发中发现技术方面的问题，不得不修改前期的设计、接口等文档，而且项目计划也要做较大调整，属于重大变更。管理因素：因为项目组资源情况导致项目计划需要进行调整，如果对需求点列表发生变动，对本项目组对外交付的时间点发生变动，属于重大变更。一般：规范因素：对需求、设计等文档的排版格式、描述做轻微的修改，对配置项本身的定义不造成影响，属于一般变更比如增加背景信息、修改语句错别字。管理因素：因为项目组资源情况导致项目计划需要进行调整，仅对本项目组内部人员、任务安排，或仅对本项目组内开发、测试时间点发生变动，属于一般变更。其它因素：先走一般变更，在变更的判断过程中决定是否上升到一级。3.7缩略语缩略语描述SCMSoftwareConfigurationManagement软件配置管理CCBChangeControlBoard变更控制委员会PMProjectManager项目经理PQAProductQualityAssurance产品级质量保证人员SQAQualityAssurance项目级质量保证人员CMConfigurationManagementEngineer配置管理人员TLTeamLeader小组组长控制机制本过程的改进由SEPG负责。SEPG负责汇集本过程的改进需求，并完成改进任务。质量管理部门负责审核本过程的执行情况。过程描述变更控制是当需要更改已基线化的配置项时所进行的管理和控制活动，即对一个正式的变更请求进行评估、分析并通过严格的流程对变更活动进行控制和记录的过程。对基线的变更活动必须从提交一个正式的变更请求开始，变更控制过程是通过对变更请求的处理与状态控制来实现的。所有的变更请求都有一个从提交、分析、决策、实施、验证直至关闭的过程，这一过程构成了变更请求的生命周期。5.1角色与职责XX有限公司版本文件编号生效日期A0XXXX5.1.1请求提交角色提交角色是变更请求的发起人，项目或产品中的任何角色都可以通过提交一个变更请求而成为提交角色。填写完整《变更管理单》中的请求部分并提交5.1.2CCB组长接收处理需求类变更和影响产品交付时间的计划类变更（接收和处理产品级基线的变更）确认变更请求的有效性；指派变更请求的分析角色；接收完成分析后的〈变更管理单〉根据分析结果决策是否接受该变更，对接受变更的每项任务分配变更实施角色；组织与之相关的评审和验证活动；对变更结果进行验证，审批基线申请。5.1.3配置管理角色5.1.3.1测试部配置管理员测试部配置管理员承担公司级配置管理职责；控制产品接口类基线及系统测试类基线；具体参见《版本/PATCH配置管理操作指导书》3.1.3.1角色与职责对与之相关的评审和验证活动进行跟踪并做报告；对通过变更验证的源代码更新基线，关闭该部分的变更。5.1.3.2产品配置管理员控制需求类基线；具体参见《版本/PATCH配置管理操作指导书》3.1.3.1角色与职责将变更任务通知变更实施角色；对与之相关的评审和验证活动进行跟踪并做报告；对通过变更验证的需求和计划重新基线，并发布报告；对总的变更管理单进行关闭操作。5.1.4分析角色对变更请求进行分析，分析的要素参见〈变更管理单〉模板；填写变更请求中以下信息：变更影响，变更范围，变更文档，变更的工作量信息5.1.5变更实施角色负责更新待变更的配置项；根据CCB指派的变更任务，对配置项实施变更；将变更后的配置项提交验证，并根据验证返回结果重新修改配置项，直到验证通过；将验证通过后的配置项提交新的基线申请。5.1.6变更验证角色对变更后的配置项进行验证，保证验证变更结果的正确性及变更结果与分析评估结果的一致性。5.1.7质量保证角色PQA对变更过程进行引导；对产品级的变更结果进行审计。确保需求变更活动符合既定的规程。不同的配置项变更，审批、决策变更的CCB角色和处理基线的配置管理角色会有所不同，具体操作参见《版本/PATCH配置管理操作指导书》3.1.3.基线控制3.1.3.1角色与职责。5.2入口条件已经基线的配置项出现变更需求5.3输入《变更管理单》5.4活动XX有限公司版本文件编号生效日期A0XXXX变更控制管理过程请求提出角色变更分析角色CCB角色变更实施角色变更验证角色配置管理角色输入文档输出文档创建变更请

求提交请求.信息不指定分析人指定变更分

析角色初始变更单变更分析提交决策结束分析后变更段阶策+拒绝—变更决策变更任务通知变更单归档分析后变更决策后变更CheckOut配置项—*实施变更提交验证待更新的配置项、变更后的配

创建变更请

求提交请求.信息不指定分析人指定变更分

析角色初始变更单变更分析提交决策结束分析后变更段阶策+拒绝—变更决策变更任务通知变更单归档分析后变更决策后变更CheckOut配置项—*实施变更提交验证待更新的配置项、变更后的配

置项脸证不通过验证活动项提交请求・审批基线n验证通创建基线申请—审批通过Check】n配置”基线变更文档结束阶评审单/缺陷.记录单一、、根据验证结

果更新的配

置项基线申请表一___^/~-配置状态发

布表（流程图）5.4.1提交阶段提交阶段是变更请求的发起人发现问题并在变更控制系统中提交变更请求的阶段。变更请求的记录一旦被提交，即将进入分析阶段。提交阶段记录的信息包括变更请求的标题、提交人、提交时间、问题的详细描述以及问题的严重性。5.4.1.1提交请求需要对曾经进行过基线的配置项进行变更时，由请求提交角色填写《变更管理单》中的请求部分，描述清楚变更类型、严重级及优先级等基本信息，然后提交给CCB组长。CCB组长根据变更严重级别（参见2.1定义））进行判断采用常规流程还是裁减后的流程（参见6裁减）。5.4.1.2指派分析CCB组长根据《变更管理单》中的申请指派分析角色。5.4.2分析阶段5.4.2.1分析请求分析角色对变更请求进行分析，填写《变更管理单》中的分析部分。5.4.2.2提交决策完成请求分析后，由分析角色将《变更管理单》提交给CCB组长。5.4.3决策阶段决策阶段将根据分析结果衡量变更将造成的影响，然后确定将对变更请求采取的处理方法。CCB对变更请求有两种处理方法：XX有限公司版本文件编号生效日期A0XXXX同意：同意对当前基线中的配置项进行变更，允许进入变更实施阶段拒绝：不实施变更，关闭该变更请求5.4.3.1CCB决策根据变更的严重级别，由CCB组长选择决策方式：会议方式：对于严重级别为重大的变更，由CCB组长组织召开CCB会议，讨论决策。直接裁决：对于严重级别为一般的变更，可以由CCB组长直接裁决。决策后填写《变更管理单》中的决策部分，由配置管理员将信息知会到相关人员。5.4.3.2指派实施如果CCB决策同意该变更请求，CCB需要对同意变更的配置项指派变更实施角色，填写《变更管理单》任务分配表部分，将该《变更管理单》发送给配置管理角色归档，由配置管理员将任务通知到变更实施角色。5.4.4实施阶段实施阶段将由变更实施角色实施所有的变更活动。5.4.4.1实施变更变更实施角色收到变更任务通知后，Checkout已经基线的配置项，对配置项实施变更操作。5.4.4.2提交验证如果变更的配置项是文档，变更实施角色完成变更操作后，将变更后的配置项提交给CCB组长组织评审。如果变更的配置项是源代码，变更实施角色完成变更操作后，直接将变更后的配置项提交给变更验证角色。5.4.5验证阶段5.4.5.1进行验证如果变更的配置项是文档，采用评审作为验证手段；由CCB组长组织评审活动。评审遵循《评审规范》。当最终评审结果为通过，即可提交基线申请进入关闭阶段；当最终评审结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交评审，直至验证结果为通过。备注：当变更的严重级别为一般，变更的内容较少、影响较小时，可以通过CCB组长或相关责任人邮件确认替代评审。评审需知会配置管理员角色，以便对变更的进度进行报告。如果变更的配置项是源代码，采用测试作为验证手段；由测试人员担当变更验证角色，进行测试活动。测试遵循《测试过程》。当最终测试结果为通过，即可提交基线申请进入关闭阶段；当最终测试结果为不通过，变更实施角色需要重新对配置项实施变更操作，重新提交测试，直至测试结果为通过。5.4.6关闭阶段5.4.6.1申请基线验证结束并通过后，变更实施者checkin通过验证的配置项，填写《基线申请/发布电子流》中的基线申请内容，提交给CCB。5.4.6.2审批基线CCB根据验证结果审批是否同意该基线申请。由CCB组长在《基线申请/发布电子流》中填写审批意见后将《基线申请/发布电子流》交给配置管理角色。如果审批意见为通过，配置管理角色就可以对变更后的配置项进行基线操作；如果审批意见为不通过，该配置项重新提交验证。5.4.6.3基线操作配置管理角色对申请基线操作的配置项进行基线操作，填写《基线申请/发布电子流》中的发布信息内容，并邮件知会所有相关人员。5.5输出《变更管理单》《基线申请/发布电子流》重新基线的配置项5.6出口条件《变更管理单》内所有的变更任务已经完成，重新基线并发布。度量度量项名称|分析阶段处理时长|决策阶段处理时长|验证阶段处理时长

XX有限公司版本文件编号生效日期A0XXXX公式（分析阶段实际结束时间-提交阶段实际结束时间）（决策阶段实际结束时间-分析阶段实际结束时间）（验证阶段实际结束时间-决策阶段实际结束时间）目的收集平均处理时长作为参考标准收集平均处理时长作为参考标准收集平均处理时长作为参考标准收集频率每月每月每月何时收集月底月底月底&相关工具/表格/记录《变更管理单》《基线申请/发布电子流》9.附录：引用《TD管理办法》《版本/PATCH配置管理操作指导书》《评审规范》7.裁剪上述常规流程中