软件配置管理（Software Configuration Management，SCM）作为CMM 2级的一个关键域（Key Practice Area，KPA），在整个软件的开发活动中占有很重要的位置。正如Pressman所说的：“软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能有兴趣的人员报告变化。” 所以，我们必须为软件配置管理活动设计一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件配置管理过程为框架，来再造组织的软件开发流程。

　　之前介绍了SCM的一些基本知识，我们来分享一下配置管理主要活动及实现方法。

　　【配置管理策划/计划】

　　在项目策划/计划时，CME应当与PM协商确定项目的 《配置管理计划》，《配置管理计划》 需考虑内容如下：

　　● 配置管理工具，如VSS、SVN、ClearCase等，一般应遵从组织标准

　　● 配置库结构和权限，一般应在组织标准的基础上进行裁剪或者定制，典型的配置库结构示例请参加笔者的后续文章《配置管理漫漫谈之典型配置库结构》

　　● CCB的层次、组成、权限，一般应结合项目情况根据组织标准进行定制

　　● 配置项识别及标识，一般应遵从组织标准，常见配置项标识规范请参见笔者的后续文章《配置管理漫漫谈之标识规范》

　　● 配置管理活动，一般应结合项目情况根据组织标准进行裁剪确定项目使用的配置管理活动

　　● 配置管理活动进度安排，应根据项目进度计划确定各项配置管理活动如基准建立、产品发布、配置审计等的进度安排

　　“配置管理计划”完成后，应由PM审核后随项目管理计划一起提交评审，评审后建立基准并指导项目配置管理活动。

　　项目进行过程中，CME应根据项目情况调整《配置管理计划》，调整标准见【基准变更控制】活动中的描述。

　　【配置管理系统建立】

　　CME应根据 《配置管理计划》 建立配置管理系统，如配置管理系统在《配置管理计划》之前建立，则需根据《配置管理计划》进行调整。

　　建立配置管理系统应包括以下内容：

　　● 配置管理服务端环境：指配置管理服务器的安装、配置，配置库结构的实现，需要考虑不同情况下的配置管理服务端环境，异地开发和同地开发的配置管理服务器环境一般是不一致的

　　● 配置管理客户端环境：指导项目成员使用相同版本的配置管理客户端并对客户端使用进行培训

　　● 配置管理环境维护计划：对配置管理环境的维护计划，主要针对服务端，重点在于备份策略

　　一般来说，组织应设立专人处理配置管理系统建立和维护的问题，以便提高效率。

　　【基准建立】

　　CME应根据《配置管理计划》建立基准，基准的建立一般步骤如下：

　　1、相应配置项负责人将经过 评审/测试/核准 的配置项提交给CME

　　2、CME对配置项进行审计

　　3、CME将配置项提交给相应级别的CCB审批

　　4、CME将配置项放入受控库（受控库的概念请参见笔者之前的文章《配置管理漫漫谈之SCM基本知识》，受控库的实例请参见笔者的文章《配置管理漫漫谈之典型配置库结构》）并进行标识

　　5、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）

　　6、CME发布基准建立通知

　　基准建立后的配置项将指导后续的开发/管理工作，并需对这些配置项进行监控以应对变更。

　　【基准变更控制】

　　当需要变更基准时，应由相应配置项负责人提出变更请求，CME负责跟踪和管理变更的执行过程、跟踪变更请求状态直至变更结束，确保变更后的内容只有在经过 评审/测试/核准 后才生效。基准变更的一般步骤如下：

　　1、相应配置项负责人向PM提出变更请求，说明变更原因

　　2、PM指定相关人员对变更影响请求进行分析，分析内容一般为变更对范围、规模、工作量、质量等的影响

　　3、PM将分析结果提交相应级别CCB审批

　　4、如CCB认为可以变更，则由PM指定相关人员实施变更；如CCB认为不可变更，则变更结束

　　5、变更完成后的配置项需进行 评审/测试/审核 通过后提交CME

　　6、CME对配置项进行审计

　　7、CME将配置项放入受控库并进行标识

　　8、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）

　　9、CME发布基准变更通知

　　基准变更后后的配置项将指导后续的开发/管理工作，并需对这些配置项进行监控以应对变更。