我说CMMI 2.0 之 配置管理

   和CMMI1.3相比，CMMI2.0中配置管理的实践基本没有变化。CMMI DEV 2.0 的20个PA中，CM是唯一一个没有3级实践的PA。

基本概念

这个PA涉及到的基本概念比较多，我们挑选部分基本概念，做通俗解释：

配置管理：通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性。

配置项：配置管理的对象，包括各种文档资料，代码等工作产品。包括：给客户的交付物、公司内部指定的输出、采购来的各种产品、构件以及开发需要的各种工具环境等。

基线：经过正式认可的、作为后续开发基础的一组配置项，其变更需要经过正式的批准。

配置控制委员会：对配置项的变更进行评审认可的一个小组。

配置审计：检查基线中的配置项版本是否正确一致、位置是否正确、是否与其功能说明一致。

实践列表

通俗解释：

CM 2.1 识别置于配置管理之下的配置项。

配置项的包含了交付给客户的、不交付给客户的文档、代码等。不交付给客户的文档是开发公司所需要的资料。这些配置项可能是自己开发的，也可能是采购来的。实践中往往忽略的是生成源代码的编译环境、构件库、类库等也是配置项。有的对日外包公司专门承接这种将几十年前的源代码进行重新编译链接的项目，因为历史的旧的编译环境，函数库没有保存，或者已经升级了。

CM 2.2 建立、保持更新并使用配置和变更管理系统。

这里所说的配置和变更管理系统包含了工具、规程、物理的存储介质、实际的配置项等。

可以是纯手工的管理配置项，并非一定采用工具。但是现在几乎不存在不使用工具管理配置项的组织了。

常用的工具有：SVN，Git, CC, CQ, Jira, confluence, Seafile等。

在配置管理系统中要定义清楚：

    控制级别

    目录结构

    权限分配

    备份机制

CM 2.3 建立或发布内部使用或交付给客户的基线。

交付给客户基线如产品基线，内部使用的基线如设计基线。

基线的命名可以有意义，比如需求基线，设计基线，产品基线等，也可以直接序号，比如基线1.0，基线2.0等。

后建立的基线，逻辑上包含了先建立的基线的内容。

CM 2.4 管理配置项的变更

变更可以分级，有需要经过CCB批准的变更，有需要经过PM的变更等。

发生配置项的变更时，要识别变更影响的范围，包括对技术、对管理、对人员的影响。对技术的影响包括对需求、设计、代码、测试用例的影响，对管理的影响包括对工作量、工期、质量、风险的影响，对人员的影响包括了对项目组各个角色的影响，需要哪些角色参与进来，变更要及时通知到相关人员。

变更影响分析可能会使用到需求跟踪矩阵辅助完备地识别变更的影响分为。

实施变更的步骤通常包括：

    提出变更申请；

    变更评审与审批；

    变更执行；

    变更结果确认；

    更新配置库；

    通知相关人员。

CM 2.5 建立、保持更新并使用描述了配置项的记录

配置项变更记录包含了：

    什么时间；

    变更提出者；

    变更实施者；

    变更了什么；

    为什么变更；

    验证人；

    验证结论；

    入库时间；

    ……

每次向配置库中提交配置项时应该详细记录上述信息，这样可以通过配置管理工具生成配置项状态报告。

CM2.6 执行配置审计以维持配置基线、变更和配置管理系统内容的完整性

所谓的完整性是指：配置库中的配置项不多、不少、版本一致、命名规范、位置正确、内容符合要求、记录完备。根据检查重点的不同，执行检查的人可以是质量保证人员，配置管理人员或者是其他专家。