一、概述

配置管理（Configuration Management， CM）的目的在于使用配置识别、配置控制、配置状态记录与报告以及配置审计，来建立并维护工作产品的完整性。

1、简介

“配置管理”过程域涉及以下活动：

• 识别所选工作产品的配置，其在给定的时间点上组成基线

• 控制对配置项的变更

• 构建或提供规格说明，以便从配置管理系统构建工作产品

• 维护基线的完整性

• 向开发人员、最终用户与客户提供准确的状态与当前的配置数据

置于配置管理下的工作产品包括向客户交付的产品、指定的内部工作产品、采购的产品、工具以及在创建并描述这些工作产品时使用的其它项。（见术语表中“配置管理”的定义。）

可能置于配置管理下的工作产品的实例有：

• 硬件与设备

• 图纸

• 产品规格说明

• 工具配置

• 代码与库

• 编译器

• 测试工具与测试脚本

• 安装日志

• 产品数据文件

• 产品技术出版物

• 计划

• 用户故事

• 迭代工作清单

• 过程描述

• 需求

• 架构文档与设计数据

• 产品线计划、过程与核心资产

采购的产品可能需要由供方与项目都置于配置管理之下。供方协议中应建立执行配置管理的规定。确保数据完备且一致的方法应得到建立与维护。参阅“供方协议管理”过程域以进一步了解如何建立供方协议。工作产品的配置管理可按多个粒度级别执行。配置项可以分成配置组件与配置单元。在本过程域中只使用术语“配置项”。所以，在这些实践中“配置项”适当时可解释为“配置组件”或“配置单元”。 （见术语表中“配置项”的定义。）基线为配置项的持续演变提供稳定的基础。基线的一个实例是已批准的产品描述，包括内部一致的需求版本、 需求可追溯矩阵、 设计、特定学科条目与最终用户文档。随着基线内容得到开发，基线被纳入配置管理系统。 通过配置管理的配置控制、 变更管理以及配置审计功能， 对基线的变更以及从配置管理系统所构建的工作产品的发布得到系统化地控制与监督。本过程域不仅适用于项目的配置管理，也适用于组织级工作产品，如标准、规程、复用库与其它共享的支持资产等的配置管理。配置管理关注工作产品的管理与技术方面的严格控制，包括交付的产品或服务。本过程域覆盖执行配置管理职能的实践，也适用于置于配置管理之下的所有工作产品。对于产品线，由于产品线下各产品之间以及核心资产与产品的多个版本之间的核心资产共享，配置管理还涉及另外需要考虑的事项。（见术语表中“产品线”的定义。）在敏捷环境中，配置管理是非常重要的，因为需要支持频繁变更、频繁构建（通常每天）、多条基线与多个配置管理支持的工作区（例如，为个人、团队、甚至结对编程）。敏捷团队可能陷入困境，如果这个组织没有：

1）将配置管理自动化（例如，构建脚本、状态记录与报告，完整性检查）并

2）将配置管理作为单独的一套标准服务加以实施。 在敏捷团队启动时，就应该识别负责确保配置管理活动正确实施的人。在每个迭代开始时，重新确定配置管理支持的需要。配置管理被谨慎地集成到各团队的工作节奏中，把焦点集中在尽量减少对团队的干扰，以使工作完成。（见第一部分中的“使用敏捷方法时对 CMMI的解读”。 ）

二、特定目标与特定实践摘要

SG 1 建立基线

SP 1.1 识别配置项

SP 1.2 建立配置管理系统

SP 1.3 创建或发布基线

SG 2 跟踪并控制变更

SP 2.1 跟踪变更请求

SP 2.2 控制配置项

SG 3 建立完整性

SP 3.1 建立配置管理记录

SP 3.2 执行配置审计

按目标排列的特定实践

1、SG 1 建立基线

所识别的工作产品的基线得到建立。

本特定目标包括建立基线的特定实践。“跟踪并控制变更”特定目标下的特定实践则用于维护基线。“建立完整性”特定目标下的特定实践则记录并审计基线的完整性。

SP 1.1 识别配置项

识别将置于配置管理下的配置项、组件与相关的工作产品。

配置识别是下列各项的选择与规格说明：

• 交付给客户的产品

• 指定的内部工作产品

• 采购的产品

• 工具及项目工作环境的其它重要资产

• 用于创建并描述这些工作产品的其它项

配置项可以包括硬件、设备与有形资产，也可以是软件与文档。文档可以包括需求规格说明书与接口文档。其它用于识别产品或服务配置的文档，例如测试结果，也可以包括在其中。“配置项”是为配置管理指定的实体，它可以包含构成基线的多个相关工作产品。这种逻辑分组为有效识别与受控访问提供便利。为配置管理选择工作产品应基于计划期间所建立的准则。

工作产品实例

1. 已识别的配置项

子实践

1. 基于文档化的准则选择配置项与组成配置项的工作产品

在适当工作产品层次上选择配置项的准则的实例有：

• 由两个或多个组使用的工作产品

• 由于错误或需求变更预期会随着时间变更的工作产品

• 相互依赖的工作产品（即：当其中一个改变时，将会导致其它工作产

品的变更）

• 对项目成功至关重要的工作产品

可能作为配置项一部分的工作产品的实例有：

• 设计

• 测试计划与规程

• 测试结果

• 接口描述

• 图纸

• 源代码

• 用户故事或故事卡

• 声明的业务用例、逻辑或数值

• 工具（例如，编译器）

• 过程描述

• 需求

2. 为配置项分派唯一标识。

3. 明确说明每个配置项的重要特征。

配置项的重要特征包括作者、文档或文件类型、软件代码文件的编程语言、最低的适于销售的特征以及配置项服务的目的。

4. 明确说明每个配置项纳入配置管理的时机。

确定何时将工作产品纳入配置管理的准则的实例有：

• 当工作产品准备好进行测试的时候

• 项目生命周期的阶段

• 对工作产品所期望的控制程度

• 成本与进度的限制

• 干系人的需求

5. 识别负责每个配置项的所有者。

6. 明确说明配置项之间的关系。

将配置项之间存在的关系类型（例如，父子、依赖） 纳入配置管理结构（例如，配置管理数据库）中，有助于管理变更的效果与影响。

SP 1.2 建立配置管理系统

建立并维护用于控制工作产品的配置管理与变更管理系统。

配置管理系统包括存储介质、规程与访问系统的工具。配置管理系统可以

包括多个子系统， 它们具有适合每个配置管理环境的不同的实现。

变更管理系统包括存储介质、规程以及记录并访问变更请求的工具。

工作产品实例

1. 具有受控工作产品的配置管理系统

2. 配置管理系统访问控制规程

3. 变更请求数据库

子实践

1. 建立多级控制的管理机制。

控制等级的选择通常基于项目目标、风险与资源。控制等级可能因项目生命周期、开发的系统类型与特定项目需求有所不同。

控制等级的实例有：

• 不受控：任何人可以变更

• 工作进行中：作者控制变更

• 已发布：指定的权限授权并控制变更，当进行变更时，通知相关干系人

控制等级可以从非正式控制到正式的配置控制，前者是对开发期间的配置项更改所作的简单跟踪，后者使用基线，其变更只能作为正式配置管理过程的一部分。

2. 提供访问控制以确保对配置管理系统授权的访问。

3. 在配置管理系统中存储并检索配置项。

4. 在配置管理系统中的控制等级间共享并传递配置项。

5. 存储并恢复配置项的存档版本。

6. 存储、更新并检索配置管理记录。

7. 从配置管理系统中创建配置管理报告。

8. 保存配置管理系统的内容。

配置管理系统保存功能的实例有：

• 备份并还原配置管理文件

• 配置管理文件的存档

• 从配置管理错误中恢复

9. 必要时，修订配置管理结构

SP 1.3 创建或发布基线

创建或发布供内部使用以及交付给客户的基线。基线表示为在一个特定时间点，将一个标识符赋予一个配置项或配置项及其相关实体的集合。随着产品或服务的演进，可以使用多个基线控制开发与测试。 （见术语表中“基线”的定义。）硬件产品同软件与文档一样也应该包含在基础设施相关的配置基线中（例如，软件、硬件），并作为包含软硬件交互的系统测试的准备。一组常见的基线包括系统级需求、系统元素级设计需求以及在开发结束／生产开始的产品定义。 这些基线通常被分别称为“功能基线”，“已分配基线”与“产品基线”。软件基线可以是一组需求、 设计、源代码文件及其相关联的可执行代码、构建文件与用户文档（相关联的实体）， 它们被分派了唯一的标识符。

工作产品实例

1. 基线

2. 基线的描述

子实践

1. 在创建或发布配置项的基线前，从 CCB 获得授权。

2. 仅从配置管理系统中的配置项创建或发布基线。

3. 将基线所包含的配置项集文档化。

4. 使当前的基线集随时可用

SG 2 跟踪并控制变更

置于配置管理下的工作产品的变更得到跟踪与控制。

在“建立基线”特定目标下的特定实践建立基线后， 本特定目标下的特定实践用来维护基线。

SP 2.1 跟踪变更请求

跟踪对配置项的变更请求。

变更请求不仅应对新需求或需求变更，也可应对工作产品的故障与缺陷。

分析变更请求，以确定变更将对工作产品、相关工作产品、预算与进度带

来的影响。

工作产品实例

1. 变更请求

子实践

1. 发起变更请求并记录在变更请求数据库中。

2. 分析变更请求中提议的变更与修复的影响。

通过确保变更与所有技术及项目需求一致的活动来评价变更评价变更对直接的项目或合同需求之外的影响。对在多个产品中使用的配置项的变更可能解决一个直接问题，而在其它应用中又引发一个问题。评价变更对发布计划的影响。

3. 对变更请求分类并划分优先级

识别紧急请求，适当时提交给紧急权限。将变更分配到将来的基线中。

4. 与相关干系人一起评审将要在下个基线中处理的变更请求，并达成一致。与适当的参加者一起进行变更请求的评审。记录每一变更请求的处置与决策理由，包括成功准则、适当时一份简要的行动计划、以及变更满足的或不满足的需要。执行处置中要求的行动并将结果汇报给相关干系人。

5. 跟踪变更请求的状态直到关闭。

要及时有效地处理纳入系统的变更请求。一旦变更请求得到处理，只要切实可行，以适当的经批准的行动尽快关闭此请求非常关键。 让措施长时间处于未关闭状态会让状态列表变得过于庞大，反而会导致附加的成本与混乱。

SP 2.2 控制配置项

控制配置项的变更。

对工作产品基线的配置保持控制。这种控制包括跟踪每个配置项的配置、必要时批准新的配置、以及更新基线。

工作产品实例

1. 配置项的修订历史

2. 基线的存档

子实践

1. 在整个产品或服务的生命期，控制对配置项的变更。

2. 在变更后的配置项进入配置管理系统前，获得适当的授权。例如，授权可来自配置控制委员会、项目经理、产品负责人或客户。

3. 以维护配置项的正确性与完整性的方式， 在配置管理系统中检入并检出配置项以纳入变更。

检入与检出步骤的实例有：

• 确定这些修订得到授权

• 更新配置项

• 将旧基线归档，并检索新基线

• 为该项的变更作备注

• 关联对相关工作产品的变更，例如需求、用户故事与测试

4. 执行评审以确保变更没有对基线造成意外的影响（例如，确保变更没有危及系统的安全性或保密性）

5. 适当时记录配置项的变更与变更的理由。

如果接受对工作产品提议的变更， 则识别将变更纳入工作产品及其它受影响区域的进度。可针对变更类别裁剪配置控制机制。例如， 对于不影响其他组件的组件变更的批准考虑可用较低严格度。已变更的配置项，需经配置变更的评审与批准后才能发布。直到发布后，变更才正式生效。

SG 3 建立完整性

基线的完整性得到建立与维护。

基线通过“建立基线” 特定目标相关的过程得到建立， 通过“跟踪并控制变更”特定目标相关的过程得到维护， 基线的完整性则通过本特定目标下的特定实践进行应对。

SP 3.1 建立配置管理记录

建立并维护描述配置项的记录。

工作产品实例

1. 配置项的修订历史

2. 变更日志

3. 变更请求记录

4. 配置项的状态

5. 基线间的差异

子实践

1. 足够详细地记录配置管理行动，使得每个配置项的内容与状态都可知，且能恢复以前的版本。

2. 确保相关干系人能访问并了解配置项的配置状态。

配置状态沟通的活动实例有：

• 给授权的最终用户提供访问权限

• 使基线副本对授权的最终用户随时可用

• 当配置项检入、检出、变更、或对变更请求做出决定时，自动提醒相关干系人

3. 明确说明基线的最新版本。

4. 识别组成特定基线的配置项的版本。

5. 描述连续的基线间的差异。

6. 必要时，修订每个配置项的状态与历史（即：变更， 其它行动）。

SP 3.2 执行配置审计

执行配置审计，以维护配置基线的完整性。

配置审计确定所产生的基线与文档符合规定的标准或需求。配置项相关的记录可以保存在多个数据库或配置管理系统中。在这种情况下，配置审计应该适当延伸到这些其它的数据库以确保配置项信息的准确性、一致性与完备性。 （见术语表中“配置审计”的定义。 )

审计类型的实例有：

• 功能配置审计（functional configuration audits， FCAs）：这种审计的执行验证配置项的开发已经符合要求地完成，该项已经达到功能基线或已分配基线中规定的功能与质量属性特征，而且操作与支持文档是完备的并符合要求。

• 物理配置审计（physical configuration audits， PCAs）：这种审计的执行验证所构建的配置项符合对其定义并描述的技术文档。

• 配置管理审计： 这种审计的执行确定配置管理记录与配置项是完备的、一致的与准确的。

工作产品实例

1. 配置审计结果

2. 行动项

子实践

1. 评估基线的完整性。

2. 确定配置管理记录正确地识别配置项。

3. 评审配置管理系统中各项的结构与完整性。

4. 确定配置管理系统中各项的完备性、正确性与一致性。

配置管理系统内容的完备性、正确性与一致性基于计划中所述的需求与已批准的变更请求的处置。

5. 确定符合适用的配置管理标准与规程。

6. 跟踪来自审计的行动项直到关闭