软件配置管理（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基本知识》，受控库的实例请参见笔者的文章《配置管理漫漫谈之典型配置库结构》）并进行标识
TAG: 软件测试管理 配置管理
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发布基准变更通知
基准变更后后的配置项将指导后续的开发/管理工作，并需对这些配置项进行监控以应对变更。
【产品创建】
产品创建的一般步骤如下：
1、CME根据《产品发布计划》从受控库取出相应的配置项版本进行加工（如Build）
2、CME对加工后的配置项进行审计
3、CME将经审计的待发布产品放入静态库（静态库的概念请参见笔者之前的文章《配置管理漫漫谈之SCM基本知识》，静态库的实例请参见笔者的文章《配置管理漫漫谈之典型配置库结构》）并进行标识
4、CME维护配置状态记录（维护内容参见本文的【配置状态记录维护和发布】一节）
5、PM根据《产品发布计划》进行（内部/外部）产品发布
6、CME发布产品发布通知
用于创建产品的配置项必须从受控库取出，以保证正确性。
【配置审计】
配置审计不同于SQA针对配置管理活动进行的配置管理过程审计，由CME执行，审计对象是工作产品/配置项，审计重点为完整性、一致性、正确性。
配置审计的目的是配置管理员要确保配置库中的配置项和基准的完整性、一致性和正确性，这就是CMMI配置管理SP3.2所提到的概念。在开发库中的配置项是不需要进行审计的，一旦带有缺陷的配置项进入受控库，将有可能给项目带来很大的负面影响。
配置审计一般分为功能配置审计（Functional Configuration Audit）和物理配置审计（Physical
Configuration Audit ）。
物理配置审计验证已构建出的配置项符合定义和描述它的技术文档，重点在于配置项的完整性，如配置项包含的工作产品是否存在？配置项的标识是否正确等。
功能配置审计验证配置项的开发已经被完全满足的审计行为，即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性，并且其运行和支持文档是完整的和满意的，重点在于一致性和正确性，主要表现为配置项的对应关系是否正确，如详细设计是否对应了概要设计、相应的变更请求是否全部被执行、待发布版本是否与发布计划内容一致、数据库配置是否与需求一致等等重点还在于工作产品与需求的一致性。
物理配置审计的范围是开发配置项和基准配置项，功能配置审计的范围是基准配置项。
物理配置审计一般由CME独立完成，功能配置审计一般由CME借助评审、测试等活动的结果完成。
物理审计的方法：
根据《配置审计检查单》去检查，该有的配置项是否都有了？文件命名与计划中的命名规则是否一致？存放位置与计划是否一致？版本设置与计划中的版本设置规则是否一致？控制权限是正确？
功能审计的方法：
a） 检查与需求的一致性、完整性：根据《需求追踪矩阵》对配置库的基准项进行检查，看看所有需求是否都已经不多不少地被实现了？并纳入了基准库？如果物理审计中基准项的审计没有问题，我们也可以通过《需求追踪矩阵》对《配置状态报告》中基准项进行检查，看看所有需求是否都已经不多不少地被实现了？
b） 验证工作产品与需求的符合程度：查看所有基准项评审和测试报告，看看所有的基准项是否都已经通过各级评审及测试？
c） 交付给客户的文档与软件的功能一致性：检查交付客户的文档是否与当前最新的基准中的需求一致
【配置状态记录维护和发布】
CME在执行配置管理活动时需进行记录以保证其可追溯性。其内容包括：
● 配置管理记录维护：需要被记录的配置管理活动及内容如下：
● 基准建立情况：记录基准建立时间、基准版本、基准（变更）内容、提交者、配置者、变更请求编号
● 变更请求情况：变更请求编号、变更来源、变更对象（含变更内容、变更前后版本）、变更影响分析、变更实施日期
● 配置审计情况：审计日期、审计时机、审计对象（含版本）、审计不符合项、不符合项类别、不符合项纠正情况
● 配置状态报告发布：CME应每周/月发布配置状态报告，以便高层管理者、SQA、PM、项目成员及其它受影响的组织/个人通过配置状态了解项目状态。报告内容主要为受控库，报告内容应侧重于报告周期内基准建立、变更、产品发布情况及相应的统计分析。
对于基准建立和基准变更都需要记录基准建立情况，基准变更需要额外记录变更请求跟踪情况。基准变更的本质是变更请求流程+基准建立流程，两者通过
变更请求编号 进行关联。
配置管理工作是贯穿整个项目生命周期的核心基础工作之一，只有利用配置管理的理论把项目条理化、清晰化，才能将如需求、设计、开发、测试等其他工作纳入正确的轨道，保证整个项目的顺利进行。配置管理策划/计划是实施其它配置管理活动的前提条件，基准建立和基准变更控制是配置管理的核心工作，配置管理活动提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理活动为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理活动是软件开发的基石！
| 
