软件配置管理¶
配置管理(CM)的目的，在使用配置识别、配置控制、配置状态报告及配置审计来达到建立和维护产品(工作成果)的完整性。 涉及到需求变更，代码管理，版本管理，变更管理及配置审计等。
标识所选定的工作产品配置，组成工作产品特定时间点的基线。
控制配置项的变更
建立或提供规格说明书，以便从配置管理系统构造出工作产品
维护基线的完整性
提供正确的状态和当前配置数据给开发人员、最终用户及客户。
建立基线¶
识别配置项¶
配置项为组成基线的实体单元，包含需求，设计，代码，构建脚本，编译工具及版本，测试方案，测试用例及测试结果等。
选择以下作为配置项
1，交付给客户的产品，例如二进制安装文件，帮助手册等。
2，内部的工作产物，例如代码和设计文档。
3，获取的产品，例如购买的数据库或开源的动态库或操作系统。
4，编译工具和其他环境等。编译工具gcc 4.4.3
给配置项赋予一个唯一的标识，识别每一个配置项的重要特征，包括作者，文档类型，编程语言， 最小可销售的市场特性以及配置项的服务目的。
建立配置管理系统¶
建立和维护对工作产品的配置管理和变更管理系统。例如采用subverison, jira等软件组合成为配置管理和变更管理系统。 并且配置管理系统包含变更申请数据。
建立或发布基线¶
定义:一个经过评审和认可的规格说明书或产品， 将来的开发将以此为基础，只有通过正规的变更控制程序才可以改变它。
建立或发布供内部使用和交付给客户的基线。
例如根据项目阶段建立基线，研发过程中每周创建研发基线来协调研发和测试的进度。
工作成果包含基线以及基线描述。
实践上有两种基线方式:
1, 按产出物进行基线化。每个项目有很多产出物，然后有多个产出物的基线，这样就需要有一个基线对照表来识别最新的项目基线。
2, 按项目进行基线，项目进行到某个阶段进行评审认可，然后对整个项目产出建立项目基线。
因为后续开发一般基于基线的需求设计及代码进行修改，第一种方式的基线各种文档冲突或不一致可能性比较大。因此需定期建立整体基线。
追踪并控制变更¶
追踪变更申请¶
需求变更，因缺陷对代码进行变更等等。并记录变更的状态，例如缺陷有Open,Accept,Fixed,Close等状态.
控制配置项的变更¶
控制配置项的变更，例如需求变更需要经过批准，审查是否造成额外的影响，在项目后期，审查变得更为严格
建立并维护基线的完整性¶
用于记录和审计基线的完整性。
实施配置审计¶
例如结项时验证需求，测试用例，以及测试结果是否符合需求等
工作成果包括以下内容:
1，配置审计结果
2，针对不符合要求的行动，例如审计不通过继续跟踪修改等
多个模块开发如接口发生变化需要评审才能修改。项目开发中可以修改接口，如项目以产品形式对外发布，接口只能新增。
关键在于配置审计，项目的配置审计必须定期进行（建议每月），参加人员包括需求人员，开发人员，集成人员，测试人员及SQA。 参加人员必须包括具体功能的开发一线人员，因为项目成果主要有他们来产出。