2024年5月3日发(作者：)

第17章 配置管理

配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规

程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成

果的一种有效保护。

☆ 制定配置管理计划 [SPP-PROC-CM-PLANNING]。

☆ 配置库管理[SPP－PROC－CM-LIB]。

☆ 配置项版本控制[SPP-PROC－CM－VERSION]。

☆ 配置项变更控制[SPP－PROC－CM－CHANGE]。

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完

成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实

力等）适当地修改规范，然后推广使用。

17.1 介 绍

项目研发和管理过程中会产生许许多多地工作成果。例如文档、程序和数据等，它们都

应当背保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来

肯定很麻烦。毫无疑问，人们应当将文件分类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主

要有两大类：

 属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。

 项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是

是值得保存。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置

项都被保存再配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。基线中

的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应开发

过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。基线的主要

属性有：名称、标识符、版本、日期等。通常将交付给用户的基线称为一个“Release”，为

内部开发用的基线则称为一个“Build”。

所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配

置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase

等。为提高配置管理的效率和安全性，结构应当有专门的配置管理员（角色）。配置管理员

为每个项目制定《配置管理计划》，创建和维护配置库。

鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration

Control Board，CBB）。CBB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批

计划，审批变更请求等）。对于配置管理管理而言，CBB是决策者，而配置管理员是执行者。

如果机构的各个项目的配置管理拥有决策权。如果机构的各个项目相对独立，那么每个

项目可以设立各自的CBB。CBB的决策采用“少数服从多数”的原则。

配置管理的流程如图17－1所示。

制定配置管理计划

配置库管理

配

置

审

计

版本控制

变更控制

图17－1 配置管理流程图

1.制定配置管理计划

配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、

基线计划、交付计划、备份计划等。CBB审批该计划。

2.配置库管理

配置管理员为项目创建配置库，并给每个项目成员根据自己的权限操作配置库。配置管

理员定期维护配置库，例如清除垃圾文件、备份配置库等。

3.版本控制

在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置

项的任何修改都将产生新的版本。由于我们不能保证新的版本一定比捞的版本“号”，所以

不能抛弃老的版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版

本丢失或混淆现象，并且可以快速准确地查找到配置项地任何版本。

配置项地状态有3种：“草稿”、“正式发布”、和“正在修改”，本规程制定了配置项状态变

迁与版本号地规则。

4.变更控制

在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止

配置项被随意的修改而导致混乱。

修改处于“草稿”状态的配置项不算是“变更”，无CBB的批准，修改者按照版本控

制规则执行即可。

当配置的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必

须依据“申请－审批－执行变更－再评审－结束”的规则执行。

5.配置审计

为了保证所有人员（包括项目成员、配置管理员和CBB）都遵守配置管理规范，质量

保证人员要定期审计配置管理工作。审计配置是一种“过程质量检查”活动，是质量保证人

员的工作职责之一。请参考质量保证规范SPP-PROC-QA,此处不再论述。

 配置管理过程域产生的主要文档有：

☆《配置管理计划》，模板见[SPP－TEMP－CM－PLAN]。

☆《配置库管理报告》，模板见[SPP－TEMP－CM－LIB]。

☆《配置项变更控制报告》，模板见[SPP－TEMP－CM－CHANGE]。

17.2 制定配置管理计划

17.2.1 目的

 制定配置管理计划，以便有计划的开展配置管理工作。

17.2.2 角色与职责

 配置管理员制定《配置管理计划》。

 CCB审批《配置管理计划》。CBB的人数视项目的规模而定。通常CCB有项目经

理、资深项目成员等人组成，项目经理为CCB负责人。CCB的决策采用“少数服

从多数”的原则。

17.2.3 启动准则

 《项目计划》已经制定。

 配置管理员和CCB已经确定。

17.2.4 输入

 《项目计划》

17.2.5 主要步骤

[Step1] 确定配置管理的软硬件资源

 配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、

外存CPU等）。常用得配置管理软件有Micosoft公司的Visual SourcevSafe 和Rational

的ClearCase等。

[Step2]制定配置计划

 配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符

的参考格式为Project－Type－Number。

☆ 可以在Project（或Product）前面加上公司的标识符。

☆ Type表示配置类型，可以采用多级缩写。

☆ Number为数字，范围从001－999，表示一个配置项有若干的文件。若配置项只有

一个文件，则该项可以省略。

 配置项计划的参考格式如表17－1所示。

类型

主要配置项

标识符

预计正式发布时间

[Step3]制定基线计划

 配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。

基线计划的参考格式如表17－2所示。

基线名称 / 标识符

基线所包含的主要配置项

预计建立时间

[Step4]制定配置库备份计划

 配置管理员制定配置库备份计划，指明"何人"在"何时"（频度）将配置库备份在"何处"。

[Step5]审批《配置管理计划》

 CCB审批《配置管理计划》。若该计划被批准，则请CCB负责人签字认可。否则，配

置管理员按照CCB的意见修改配置管理计划，直到该计划被批准为止。

17.2.6 输出

 《配置管理计划》

17.2.7 结束准则

 《配置管理计划》已经制定并被CCB批准。

17.2.8 度量

 配置管理统计工作量以及文档的规模，汇报给项目经理。

17.3 配置库管理

17.3.1 目的

 所有人员依照配置管理规范和《配置管理计划》操作配置库。

17.3.2 角色与职责

 配置管理创建并维护配置库。

 项目成员在权限之内操作配置库。

17.3.3 启动准则

 《配置管理计划》已经制定。

 配置管理的软硬件已经存在。

17.3.4 输入

 《配置管理计划》

17.3.5 主要步骤

[Step1]创建配置库

 配置管理员的创建配置库，并且至少创建库的所以第一级目录。

[Step2]分配权限

 配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add、

Checkin/Checkout、Download等权限，但是不能拥有“删除”权限。配置管理员的权

限最高。具体操作视所采用的配置管理软件而定。

[Step3]配置管理操作与管理

 项目成员根据自己的权限操作配置库。例如 Add、Checkin/Checkout、Download等。

 配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。

 配置管理员定期清除配置库里的垃圾文件。

 配置管理员定期备份配置库。

 交付管理。这里“交付”是指从配置库中提取配置项，交付给客户或项目外的人员。交

付出去的配置项必须有据可查，避免发生混乱。流程如下：

☆ “索取人”向CCB提出交付申请。

☆ CCB审批该申请。如果该申请不合法（合理）。则拒绝交付配置项。如果同意交

付，

CCB应给出详细的交付清单。

☆ 配置管理员依据CCB的批示，从配置库中提取配置项交付给“索取人”。

☆ 索取人验收后签字。

17.3.6 输出

 《配置库管理报告》（由配置管理员撰写）

17.3.7 结束准则

 对配置库的操作与管理将持续到项目结束。

17.3.8 度量

 配置管理员统计工作量以及文档规模。

17.4 版本控制

17.4.1 目的

 按照一定的规则保存配置项的所有的版本，避免发生版本丢失或混淆等现象，并且可以

快速准确地查找到配置项的任何版本。

17.4.2 角色与职责

 所有项目成员都必须遵照版本控制规程操作配置库。

17.4.3 配置项状态变迁规则

配置项的状态有3种：“草稿”（Draft）“、正式发布”（Released）和“正在修改”(Changging).

配置项状态变迁如图17—2所示。配置项刚建立时其状态为“草稿”。配置项通过评审

（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”

执行，其状态变为“正式修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态

又变为“正式发布”，如此循环。

否决

自由修改

评

审

变更控制

或审

正式发布

正在修改

草稿

批

通过

图17－2 配置项状态变迁图

17.4.4 配置项版本号规则

配置项的版本号与配置项的状态紧密相关：

 处于“草稿”状态的配置项的版本号格式为：。

☆ YZ数字范围为01~99。

☆ 随着草稿的不断完善，“YZ”的取值应该递增。“YZ”的初值和增幅由用户自己把握。

 处于“正式发布”状态的配置项的版本号格式为：X.Y。

☆ X为主版本号，取值范围为1~9。Y为次版本号，取值范围为1~9。

☆ 配置项第一次“正式发布”时，版本号1.0。

☆ 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置

项版本升级幅度比较大时，才允许增大X值。

 处于“正在修改”状态的配置项的版本号格式为：。

☆ 配置项正在修改时，一般只增大Z值，X.Y值保持不变。

☆ 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。

17.4.5 配置项版本控制流程

[Step1] 创建配置项

 项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配

置项的状态为“草稿”，其版本号格式为 。

[Step2] 修改处于“草稿”状态的配置项

 项目成员使用配置管理软件的Checkout/Checkin功能，可以自由修改处于“草稿”状

态的配置项（不受变更控制规程约束），版本号格式为。

[Step3] 技术评审或领导审批

 如果配置项是技术文档，则需要接受技术评审（参见技术评审规程[SPP-PROC-TR]）。

如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。

 若配置项通过了技术评审或领导审批，则转向[Step4],否则转向[Step2]。

[Step4]正式发布

 配置项通过了技术评审或领导审批之后，则配置项的状态从“草稿”变迁为“正式发布”，

版本号格式为X.Y。

[Step5] 变更

 修改处于“正式发布”状态的配置项，必须按照“变更控制规程”执行，主要步骤如下

（详见变更控制规程）：

☆ 如果CCB同意变更，则配置项状态从“正式发布”变迁为“正在修改”。

☆ 项目成员使用Checkout/checkin功能，可以修改处于“正在修改”状态的配置项，

版本号格式为。

☆ 修改完毕后，该配置项要重新接受技术评审或领导审批。转向[Step3]。

17.5 配置项变更控制

17.5.1目的

 防止配置项被随意修改而导致混乱。

17.5.2 角色与职责

 CCB对审批变更申请。

17.5.3 启动准则

 待变更的配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被

“冻结”）。

17.5.4 输入

 待变更的配置项

17.5.5 主要步骤

[Step1] 变更申请

 变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。

[Step2] 审批变更申请

 CCB审批该申请，分析此变更对项目造成的影响，如果同意变更，则转向[Step3],否则

终止本规程。

说明

一个配置项的变更可能导致其它配置项也发生变更，CCB在审批变更申请时

一定要考虑这些问题。

[Step3] 安排变更任务

 CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就变更内容达成共识。

说明

变更执行人可能是变更申请人，也可能不是。

[Step4] 执行变更任务

 变更执行人根据CCB安排的任务，修改配置项。

 CCB监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。

[Step5] 对更改后的配置项重新进行技术评审（或审批）

 如果配置项是技术文档，则需要接受技术评审（参见技术评审规程[SPP-PROC-TR]）。

如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。

 若配置项通过了技术评审或领导审批，则转向[Step6],否则转向[Step4]（即重新修改）。

[Step6] 结束变更

 当所有变更后的配置项都通过了技术评审或领导审批后，这些配置项的状态从“正在修

改”变迁为“正式发布”。CCB在《配置项变更控制报告》中签字，结束变更。

17.5.6 输出

 本规程的所有信息都记录在《配置项变更控制报告》中。

17.5.7 结束准则

 CCB签字结束变更。

17.5.8 度量

 CCB统计变更工作量。

17.6 实施建议

 要求所有人员对其工作成果进行配置管理。

 对全员进行配置管理培训。

 由于配置库里保存的是项目的所有工作成果，应当选择“责任心强、可靠”的人员担任

配置管理员。

 选用合适的软件工具，尽量减少配置管理过程的工作量。