在项目开始时，需根据项目的情况确定CCB成员，建议组成人员为、PM、、QA、CMO。PM为CCB负责人，PM根据变更请求的情况事件驱动地召集CCB会议。CCB也可以批量处理更改请求或采用定期的方式进行处理。这些活动都应该在配置管理计划中体现。
5.4.2
5.4.2.1
当配置项处于创建之初未纳入基线之前，项目组成员可以修改。此时配置项是草稿状态。
5.3.2.3
如在某个阶段中，需要对某个模块单独进行基线化操作，此时基线以下述标签规则建立。
标签命名规范：
BaseLine_版本号_[子系统名称/模块名称]_阶段
例如：
BaseLine _V100R002C02L00106_ CHG_SDV
5.3.3
整体备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+fully
Change Control Board
1、评估和批准对基线的变更
2、评估和批准变更申请
QA
质量保证
QualityAssurance
1、实施配置审计
5.配置管理简介
5.1
配置管理是通过标识配置项，变更控制，配置状态跟踪，配置审计来建立和维护工作产品的精确配置，保证工作产品一致稳定。
5.2
5.2.1
配置管理中最基本的元素是配置项，它是被唯一标识的实体。
配置状态跟踪是对配置库的状态，软件的更新或变更的过程进行记录、监视并通报给项目组和相关成员的活动。
1.责任人：CMO
2.发布对象：项目组所有人员
3.发布周期：例行发布或事件驱动发布
4.发布形式：邮件
5.发布内容：
1)月度例行发布内容：版本发布情况
2)阶段点发布内容：文档归档情况、基线建立情况、变更情况
1)文档
一般将一篇文档可以划分为一个配置项。根据需求一类文档也可作为一个配置项。
2)代码
对于单板软件、模块、开源软件、外购软件或需要单独管理的软件代码可设置为一个配置项。如果没有特别管理需求，所有组成一个Build的代码也可作为一个配置项。
5.3.1.3
每个配置项都必需被唯一地标识，这个唯一的标识被用于与其它配置项进行区分，跟踪和报告该配置项的状态。一般地，每个配置项被赋予一个标识符。
命名规则是：项目名称+“_”+“Design”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
验收&产品基线
在整个项目开发结束以后打的基线，包含CI目录下的所有配置项。
命名规则是：项目名称+“_”+“Final”+“_”+“Baseline XX”(XX为十进制标识符，起始为“01”)
如版本规则不明确，则应采用本版本规则，但必须保证版本号与客户方版本号的对应关系。
1)版本命名
文档的版本标识形式为以下的十进制标识符：
xx.yy
其中xx起始为“1”，yy起始为“0”。
所有数字均是阿拉伯数字，并且单调递增。如果发生了重大的修改，xx递增；如果只有小修改，递增yy。
配置项未经过评审时，版本标注不得早于v1.0。
外部审计：是指客户CMO及QA对项目的所有配置管理活动否和要求相一致的配置审计。外部审计结果作为项目验收报告的输入，用于后续合作评估。
配置项通过评审后，版本可升为V1.0版，达成V1.0版的配置项纳入配置库，正式受控。配置项纳入配置库时，应在修订记录中注明版本号。
2)发布版本标识
一个发布软件由一系列配置项组成，由这些配置项共同构成一个广义的配置项－－版本。对于版本的标识建议采用如下的形式。如客户有该项要求，则按客户要求操作。
软件版本以xx.yy.zz.pp的形式标识，其中xx、yy、zz、pp的意义如下：
1)文档命名规则
项目名称名称+文档名称+文档版本。中间使用“_”下划线连接。
格式：项目名称_文档名称_文档版本
例如：
中信CRM零售管理项目_详细设计_V1.0.xls
如客户方有其他要求，则按客户要求操作。
2)工具命名规则
工具名称+空格+版本号
例如：
Subversion 1.6.17
5.3.1.4
版本命名必须与客户下发的工作任务书所要求的版本命名保持一致。
AR
Allocated Requirements
分配需求
4.角色和职责
表格2角色和职责
缩略语
中文名
英文名
职责
PM
项目经理
Project Manager
1、协助CMO识别配置项
2、申请建立配置库
3、审查配置库变更
组织级CMO
组织级配置管理员
OrganizationalConfiguration Management Operator
维护版本2.1.1.0
补丁版本2.1.1.1
内部版本2.1.1.1
5.3.2
5.3.2.1
标签命名采用以下规则：
Label _版本号_标签名
标签注释规范如下：
【标签人】：描述实际修改该问题的人员信息（格式：中文姓名）
【标签说明】：详细说明标签的内容。
5.3.2.2
1)瀑布模式的项目中，CMO必须在需求分析结束、code&UT结束、ST结束、SDV结束、验收结束时进行基线化操作。
1、建立项目配置库
2、维护组织级配置库
3、提供配置管理培训
4、执行组织级配置审计
CMO
配置管理员
Configuration Management Operator
1、识别、标识配置项
2、管理配置库访问权限
3、制定配置管理计划
4、维护配置项变更记录
5、建立基线
6、配置状态报告
7、版本发布
CCB
变更控制委员会
由供应商提供的源代码，并接受供应商的维护
工具
支持软件开发、建立、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等
用户文档
包括用户手册，安装指南等
运行环境
包含系统运行环境的相关内容，比如系统运行平台，环境设置要求等
5.3.1.2
软件配置项一般可分为两大类：文档与代码。
对于这两种类型，其配置项划分方法不同：
需求基线
该阶段尾所有文档通过评审后打基线，包含立项基线所有配置项及：SDV测试方案、SDV测试用例，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“RD”+“_”+“Baseline”
设计基线
在实现阶段结束以后打基线。除包含“立项基线”与“需求基线”所有包含的配置项以外增加源代码、单元测试计划及用例，系统测试计划及用例。
3.转测试交付件必须包括：基线化的需求、设计、规格、产品配套资料、文档等相关文档
5.6
1.版本验收通过后，由CMO交付版本。
2.每个版本交付验收时CMO都必须对照工作任务书检查确保交付件的完整性，对代码配置库打标签，并对版本回收修改权限。
3.版本交付件必须包括工作任务书的交付件清单所有交付件。
5.7
凡是纳入配置管理范畴的工作产出都是配置项（CI）。
配置项主要有两大类：
1)属于产品组成部分的工作产出；
2)项目管理和机构支撑过程产生的文档。
配置项，指一个产品在生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项。（要和过程中配置项的定义一）
5.4.2.2
配置项自提交审核开始，即处于受控状态。
例如：
1)一个正在进行审核的设计文档。
2)一个已通过审核的配置管理计划。
5.4.2.3
配置项被纳入基线范围，并且此基线已经建立，则称此配置项已基线化。
5.5
1.版本转测试由CMO负责。
2.每个版本转测试时CMO都必须检查确保交付件的完整性，对代码配置库打标签并对版本回收修改权限。
在立项结束时候打基线，包含的配置项有：工作任务书、分配需求、客户提供物、方案建议书、方案选择表、项目估算表、项目计划、WBS、过程裁剪表、需求设计说明书、项目需求表，只需对01.CI目录打基线即可。
命名规则是：项目名称+“_”+“Init”+“_”识符，起始为“01”)
例如：银行项目_back_20130810_fully
增量备份
命名规则是：项目名称+“_”+ back +“_”+“YYYY/MM/DD”+ hourly
例如：银行项目_back_20130810_hourly
5.4
配置控制包括配置项在完成基线化后所产生的变更的评估、批准、驳回以及实现过程。
5.4.1
5.3
5.3.1
配置标识是对配置管理的前提和基础。
配置标识包括了配置项的选择、划分以及功能物理属性进行描述的过程。
配置项是逻辑上组成软件系统的各组成部分。比如一个软件产品包括数个程序模块，每个程序模块及其相关文档和支撑数据就是软件的配置项。它们可以作为一个配置项，也可以根据类型划分为几个配置项。这个过程就是配置项的选择与划分。
配置管理指南
修订历史
版本号
版本发布日期
作者
审核者
批准者
受影响的部分和变更总结
1.目的
为了指导和帮助XX公司项目的配置管理工作，特制定本指南。
2.范围
本过程文件适用于所有的软件开发及测试项目。
读者为项目组中负责配置管理活动的人员。
3.术语和缩写语
表格1术语和缩略语
缩略语
英文全名
中文解释