软件配置管理是关于软件资产的管理。源代码、设计文档等文档、可运行的程序、自动测试脚本、编译器等工具和环境……所有在软件研发过程中使用或产生的，有价值的值得保存的东西，都是软件资产。软件配置管理就是对这些内容的管理。
1、配置管理包括6个主要活动：
（1）制定配置管理计划。定义如何做好配置管理。
（2）配置标识。识别出需要把哪些东西作为配置项来管理。
（3）配置控制。配置项有一些变更，需要做好配置变更的控制。
（4）配置状态报告。需要执行配置项的状态是什么样。
（5）配置审计。对配置效果进行审计，经验和教训总结。
（6）发布管理和交付。对正式发布的版本进行控制，妥善保存好代码和文档的母拷贝。
2、典型的配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，他们经评审和检查通过后进入配置管理。配置项是可以修改的。有些文档生成后是不可修改的（如测量报告、会议纪要、工作报告），所以不能被当作配置项。配置管理参考的国标：GB/T11457-2006
3、配置项分为基线配置项（有版本号）和非基线配置项。基线配置包括所有设计文档和源程序等开发过程的配置项；非基线配置项包括项目的各类计划和报告等管理过程的配置项。
4、所有配置项的操作权限应由CMO（配置管理员）严格管理。基本原则是：基线配置项向开发人员开放读取的权限，非基线配置项向PM、CCB及相关人员开放。
5、配置项版本号和状态（版本增量由用户自己把握，但基本遵循以下命名规范）：
0.YZ -> 草稿。配置项刚建立时的状态。1.0版之前的，均为草稿，例如0.1、0.5、0.99。
X.Y -> 正式。配置项经过评审的状态。1.0版及以后的主+次版本，均为正式。如1.2、2.3。
X.YZ -> 修改。配置项修改时的状态。两个正式版中间的版本，均为修改。如1.21。
6、配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大多数配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本好，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
7、配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项不能再被任何人随意修改，对基线的变更必须遵循正式的变更控制程序。一组拥有唯一标识号的需求、设计、源代码和相应的可执行代码、构造文卷和用户文档构成一个基线。产品的一个测试版本就是一个基线。基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可能只有一个基线。交付给外部顾客的基线一般称为发行基线（Release）；内部开发使用的基线一般称为构造基线（Build）。
对于每一个基线，要定义下列内容：建立基线的事件条件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
8、配置库类型：
（1）开发库（动态库，程序员库，工作库）：开发人员正在开发的配置实体，可以任意频繁修改。
（2）受控库（主库）：将某个阶段结束时的开发库提交到受控库。当前的基线加上对基线的变更。存放阶段性产物，可以修改，但要走变更流程。
（3）产品库（静态库，发行库，软件仓库）：将受控库中测试没问题的版本提交发行，即为产品库。已发布使用的各种基线的存档。存放最终产品，一般不再修改，真的要修改需要走变更流程。
9、配置库的建库模式：
（1）按配置项的类型分类建库，通常用于通用软件的开发组织。
（2）按开发任务建立相应的配置库，适用于专业软件的开发组织。
10、配置管理员为每个项目成员分配对配置库的操作权限：
Read：读取，但不可变更
Check：对文件内容进行变更
Add：追加，重命名，删除等
Destroy：不可逆毁坏，清除，rollback等
针对开发库、受控库和产品库，会对每个成员设置不同的权限。
11、CCB：配置控制委员会（也叫变更控制委员会）：负责对变更作出评价，审批以及监督已批准变更的实施。
（1）其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。
（2）CCB不是常设机构，小的项目CCB可以只有一人，甚至只是兼职人员。
（3）CCB还负责：配置管理计划审批、基线设立审批、产品发布审批等。CCB是决策机构，不是执行机构。
12、软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。配置管理员（CMO）负责在整个项目生命周期中进行配置管理活动。这些活动主要有：
（1）编写配置管理计划，并提交配置管理委员会审批
（2）建立和维护配置管理系统
（3）建立和维护配置库
（4）配置项识别
（5）建立和管理基线
（6）版本管理和配置控制
（7）配置状态报告
（8）配置审计
（9）发布管理和交付
（10）对项目成员进行配置管理培训
13、配置管理计划的主要内容有：
（1）配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
（2）实施这些活动的规范和流程。
（3）实施这些活动的进度安排。
（4）负责实施这些活动的人员或组织，以及他们和其他组织的关系。
14、配置标识是配置管理员的职能，基本步骤如下：
（1）识别需要受控的配置项
（2）为每个配置项指定唯一性的标识号
（3）定义每个配置项的重要特征
（4）确定每个配置项的所有者及其责任
（5）确定配置项进入配置管理的时间和条件
（6）建立和控制基线
（7）维护文档和组件的修订与产品版本之间的关系
15、配置控制即配置项和基线的变更控制，包括这些任务：标识和记录变更申请；分析和评价变更；批准或否决申请；实现、验证和发布已修改的配置项。配置变更流程如下：
（1）变更申请
（2）变更评估（CCB）
（3）通告评估结果（变更工作量估计是否合理）
（4）变更实施
（5）变更验证与确认
（6）变更的发布
（7）基于配置库的变更控制，流程如下：
以下是各角色在配置管理活动中的权限总结：
16、配置状态报告应着重反映当前基线配置项的状态，供相关人员了解。报告的内容包括：
（1）每个受控配置项的标识和状态
（2）每个变更申请的状态和已批准修改的实施状态
（3）每个基线的当前和过去版本状态
（4）其他配置管理活动的记录
17、配置审计也称为配置审核或配置评价，配置审计分功能配置审计和物理配置审计，前者审计配置项的一致性（功效和需求是否一致），后者审计配置项的完整性（物理存在是否与预期一致）。配置审计的作用是为了确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象，如：
（1）防止向用户提交不适合的产品
（2）发现不完善的实现
（3）找出各配置项间不匹配或不相容的现象
（4）确认配置项已在所要求的质量控制审核之后纳入基线并入库保存
（5）确认记录和文档保持着可追溯性
18、发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。
（1）存储：确保存储的配置项的完整性
（2）复制：用拷贝的方式制造软件
（3）打包：确保按批准的规程制备交付的介质
（4）交付：按合同中的规定交付产品或服务
（5）重建：应能重建软件环境
19、三种常用的配置管理工具对比：
（1）SVN：集中式版本控制之王，简单，功能强，体积小，必须联网使用
（2）ClearCase（CC）：集中式版本控制，功能强大，过于庞大，运行慢，世界500强使用
（3）GIT：开源的分布式版本控制工具，速度快，支持本地版本控制，分支功能强
软件配置管理关心的是，文件的各个历史版本是否记录了下来，以便今后翻阅；各次修改的修改者、修改的原因是否记录了下来，以便将来可以理解当时的情形，理解为什么做出这样的改动。
官网：http://www.lenbor.com