配置管理的定义
（1）是采用技术手段和行政手段进行管理和监督的一套规范化方法；
（2）对配置项的功能特性和物理特性加以标志，并将其文件化，并控制这些特性的变更；
（3）报告变更进行的情况、变更实施的状态，以及验证与规定要求的一致性。
配置管理的意义
配置管理能够解决的问题：
1）多重维护问题：解决多个用户对同一文件进行修改所引起的版本不一致问题；
2）同时修改问题：解决多个用户对同一文件同时进行修改所引起的资源冲突问题；
3）丢失版本或不知版本问题：即要明确保留哪个版本，销毁哪个版本。
配置管理的主要内容：
制定配置管理计划、配置项识别、建立配置管理系统、基线化、建立配置库、变更控制、配置状态统计、配置审计
1、制定配置管理计划
制订配置管理计划的主要步骤如下：
（1）建立并维护配置管理的组织方针
（2）确定配置管理需使用的资源
（3）分配责任
（4）培训计划
（5）确定“配置管理”的项目干系人，并确定其介入时机
（6）制订识别配置项的准则
（7）制订配置项管理表
（8）确定配置管理软硬件资源
（9）制订基线计划
（10）制订配置库备份计划
（11）制订变更控制流程
（12）制订审批计划
2、配置识别和建立基线
配置识别：
确定需要纳入配置管理的配置项
确定配置项的获取时间和所有者
为识别的配置项分配唯一的标识
基线：指一个配置项在其生存周期的某一特定时间，被正式标明、固定并经正式批准的
版本。
可看做是一个相对稳定的逻辑实体，其组成部分不能被任何人随意修改
对于配置管理，有以下三种基线：分配基线（需求）、功能基线（设计）和产品基线（测试）。
分配基线（Allocated Baseline）
分配基线指在软件需求分析阶段结束时，经过正式评审和批准的软件需求规格说明。分配基线是最初批准的分配配置标识。
功能基线（Functional Baseline）
功能基线指在系统分析与软件定义阶段结束时，在经过正式评审和批准的系统设计规格说明书中对开发系统的规格说明；或是指在经过项目委托单位和项目承办单位双方签字同意的协议书或合同中，所规定的对开发软件系统的规格说明；或是由下级申请并经上级同意或直接由上级下达的项目任务书中所规定的对开发软件系统的规格说明。功能基线是最初批准的功能配置标识。
产品基线（Product Baseline）
产品基线指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。
3、建立配置管理系统（SVN、VSS、CVS、配置库）
配置库：记录配置项有关的所有信息，存放受控的配置项
动态库、开发库、程序员库、工作库
受控库、主库、系统库
静态库、软件仓库、软件产品库
备份库
建库模式：按配置项类型分类建库、按任务建库
配置库权限的定义和设置
R（Read）
C（Check Out/CheckIn）
A（Add/Rename/Delete）
D（Destory）
4、版本管理
配置项状态：草稿、正式（评审后）、修改
配置项版本号规则
配置项的版本号与配置项的状态紧密相关。
处于“草稿”状态的配置项的版本号格式为：0.YZ
随着草稿的不断完善，YZ的取值应递增。YZ的初值和增幅由开发者自己把握。
处于“正式发布”状态的配置项的版本号格式为：X.Y
X为主版本号，取值范围为1~9，Y为此版本号，取值范围为1~9
配置项第一次“正式发布”时，版本号为1.0
如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值
处于“正在修改”状态的配置项的版本号格式为：X.Y.Z
配置项上在修改时，一般只增大Z值，X.Y值保持不变
当配置项修改完毕时，状态重新成为“正式发布”时，将二值设置为0，增加X.Y值
5、变更控制
变更申请：变更申请人
变更评估（CCB）
变更实施：CM工程师、变更实施人
变更验证与确认（CCB）
变更的发布（配置管理员）
基线的变更 ：基线以内的。不用走。基线外要走变更流程
6、配置状态报告：通用CASE工具自动生成
能够及时、准备地给出配置项的当前状况，加强配置管理工作
What：发生了什么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
报告所有配置项以及变更请求的状态
7、配置审计（配置审核）
变更控制的补充手段，来确保某一变更需求已被切实实现
配置项审计包括功能配置审计和物理配置审计。
配置审计内容包括：
（1）评估基线的完整性
（2）检查配置记录是否正确反映了配置项的配置情况
（3）审核配置项的结构完整性
（4）对配置项进行技术评审
（5）验证配置项的完备性和正确性
（6）验证是否符合配置管理标准和规程
配置审核的任务便是验证配置项对配置标识的一致性。配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱现象，如：
（1）防止出现向用户提交不适合的产品，如交付了用户手册的不正确版本。
（2）防止不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
（3）找出各配置项间不匹配或不相容的现象。
（4）确认配置项已在所要求的质量控制审核之后作为基线入库保存。
（5）确认记录和文档保持着可追溯性。
文档种类
按重要性和质量要求：非正式文档、正式文档
按项目周期角度：开发文档、产品文档、管理文档
按14类文档：
1、可行性研究报告、2、项目开发计划、3、软件需求说明书、4、数据要求说明书、5、概要设计说明书、6、详细设计说明书、7、数据库设计说明书、8、用户手册、9、操作手册、10、模块开发卷宗、11、测试计划、12、测试分析报告、13、开发进度月报、14、项目开发总结报告
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
