配置管理

一、概述
配置管理(Configuration Management, CM)的目的，在使用配置识别、配置控制、配置状态记录及配置审计，来达到建立与维护工作产品的完整性。

配置管理提供了结构化的，有序化的，产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。配置管理是指用于控制系统一系列变化的学科。通过一系列技术，方法和手段来维护产品的历史，标识和定位产品独有的版本，并在产品的开发和发布阶段控制变化。通过有序管理和减少重复性工作，配置管理保证了生产的质量和效率。可以说不懂软件项目的配置管理，就不懂软件开发管理，不对软件项目进行配置管理，就没有进行软件项目开发管理。

二、配置管理的基本概念
1、配置标识
IEEE中的定义：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。
可以理解为：标识软件系统的结构，标识独立部件（工作产品），并使它们是可访问的。配置标识的目的，是在整个生命周期中标识系统各部件并提供对软件过程及其软件产品的跟踪能力。即:怎么命名？版本如何设置？放到哪里？哪些是受控的？受控的级别是什么？读写的权限是什么？

2、配置变更控制
IEEE中的定义：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。可以理解为：
软件生命周期中控制软件产品的发布和变更，目的是建立确保软件产品质量的机制<需求变更控制是配置管理控制的吗？>。即怎么变更？谁控制变更？谁来分析变更的影响范围？变更后如何验证、入库以及恢复？

 

3、配置状态统计
IEEE中的定义：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。
可以理解为：记录和报告变更过程，目标是不间断记录所有基线项的状态和历史，并进行维护。每次基线的生成和变更都能让相关者知道变了什么？为什么变？变化前后的状态是什么？

4、配置审计
IEEE中的定义：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。

可以理解为：验证软件产品的构造是否符合需求、标准、或合同的要求，目的是根据配置管理的过程和程序，验证所有的软件产品已经产生并有正确标识和描述，所有阶段的工作产品都一致并满足系统的需求，并且所有的变更需求都已解决。

三、配置管理计划
《配置管理计划》一般是《项目综合管理计划》的子计划。在项目策划的时候我们就要制定这个计划。

1、配置管理活动的职责分配
a) 配置管理员：识别和标识配置项，建立和维护配置库；配置库管理；执行配置审计
b) 配置控制委员会(CCB)：批准基线库的生成；评估和审核变更请求，并确保批准的更改得到实施.
c)  QA：配置管理活动审查

2、配置管理的资源
a) 配置库的服务器
b) 配置库工具
c)  配置库的访问方式

3、识别配置项
对于配置项，可以给出一个比较简单的定义，即软件过程的输出信息，可以分为4个主要类别：
a) 计算机程序（源代码及可执行程序）
b) 描述计算机程序的文档（针对技术开发者和用户）
c)  数据（包含在程序内部或外部）
d)  项目管理的有关文件、信息记录等

在实际项目中，我们如何识别配置项？
a) 项目过程裁剪定义》中要产出的工作产品
b) 源代码、可执行程序
c)  数据（包含在程序内部或外部）
d)  客户提供的文档、工具
e)  需要提交给客户的其他工作产品。

4、配置项的控制级别
IEEE中基线的定义是这样的：已经正式通过审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。

在项目中我们一般把配置项分为3种控制级别：
a) 数据项：数据项是指对变更不作控制的配置项；
b) 受控项：受控项是指不需要进行基线控制但变更后需要得到相关人员确认或通知到相关人员的配置项。
c)  基线项：基线项是指需要严格执行基线变更流程的配置项。
一般数据项就是我们大部分企业说的工作区。

5、配置项的标识与控制
在配置库中，配置项都应该有一个合适的目录去存放和分类。放入之特定目录下的配置项也必须严格按照“文件命名规则”来命名，并且这些配置项要按照“版本设置规则”来标识版本。

在配置库中各种配置项的操作权限都应严格管理。我们一般是通过目录的访问权限来控制的，所以配置库的目录结构与配置项的访问权限也有着密切的关系，配置项的权限设置的原则如下：
a) 基线配置项：只有配置管理员有写的权限，项目组全员开放读的权限。
b) 受控配置项：PM、CCB读写权限，项目组全员或相关人员开放读的权限。
c) 数据配置项：PM、CCB、配置项的责任人或开发小组开放读写权限，项目组全员开放读的权限。

7、基线计划
在配置管理中基线发布是一个重要活动，基线发布的时间点一般就是项目里程碑时间点。通常会有下列基线：需求基线、设计基线、代码基线、交付基线等。

在计划中我们要依据《项目综合管理计划》的里程碑时间点，结合项目管理的需要，设定项目的基线计划。即项目过程中发布哪些基线，这些基线发布的时间点，发布的责任人。同时我们也要明确定义基线的版本规则，因为基线也是在不断变更的。

8、配置审计计划
配置审计的时机：
a) 一般基线发布前对要进入基线的配置项进行配置审计。
b) 如果2条基线的发布时长超过2个月时，应该在时间2个基线发布中适当安排配置审计，建议是1个月1次。
c)  产品交付前必须要进行配置审计。
我们在计划中要规划好配置审计的概要时间。这样有利于配置审计的及时开展。

9、配置管理计划
定义各类配置项如库、出库的准则和操作流程。
定义基线变更的准则和操作流程。
明确配置库的备份及维护的方法，当出现异常后如何恢复的预案等。
版本发布的准则、发布流程及发布计划，如测试版本、β版本、Release版本等。

四、配置管理的主要活动
1、配置状态报告
配置状态报告是一个配置管理中一个很重要的活动，多个开发组保持开发一致的重要活动。我们的配置状态报告的主要对象是基线库。

配置状态报告要报告的内容有：基线库的基线项的清单、基线项的名称、版本、存放位置。

在每次基线变更后，状态报告还要能说明。哪些基线项变了、为什么变、变化前的版本是什么、变化后的版本是什么。

2、基线变更流程
一般项目管理中，基线变更的控制权限是CCB（配置变更委员会）。基线变更控制一般是由两种变更方式，需求变更、内部变更。下图是基线变更的流程:

 3、配置审计
在CMMI模型中明确将配置审计分为物理审计和功能审计，在定义中与IEEE是没有冲突的。在CMMI模型中对物理审计和功能审计的定义如下：

a) 物理审计：验证已构建出的配置项符合定义和描述它的技术文档的审计行为。
b) 功能审计：验证配置项的开发已经被完全满足的审计行为，即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性，并且其运行和支持文档是完整的和满意的。

配置审计的范围：物理审计的范围是受控项和基线项，功能审计的范围是基线项。
功能审计是验收的前提条件，不同的角色所做的功能审计侧重点不同。

配置审计的步骤：
a) 准备《配置审计检查单》，这个检查单包含所有受控项和基线项的状态，受控项清单包含受控项的命名、控制级别、存放位置、当前版本、控制权限等状态信息。基线项的状态就是最新的《配置状态报告》中配置项的状态。
b) 依据配置审计的计划时间去执行配置审计。
c)  根据《配置审计检查单》对配置库进行物理审计。责任人：CM发起并参与、CCB。
d)  根据《配置审计检查单》对配置库进行功能审计。责任人：CM发起并参与、需求人员、CCB（PM、及各Leader）及相关人员。
e) QA监督配置审计是否按照标准流程来进行，并记录不一致问题。
f)  每次配置审计要将审计结果记录到《配置审计报告》中，记录和跟踪配置审计检查出的问题。

物理审计的方法：
根据《配置审计检查单》去检查，该有的配置项是否都有了？文件命名与计划中的命名规则是否一致？存放位置与计划是否一致？版本设置与计划中的版本设置规则是否一致？控制权限是正确？

功能审计的方法：
a) 检查与需求的一致性、完整性：根据《需求追踪矩阵》对配置库的基线项进行检查，看看所有需求是否都已经不多不少地被实现了？并纳入了基线库？如果物理审计中基线项的审计没有问题，我们也可以通过《需求追踪矩阵》对《配置状态报告》中基线项进行检查，看看所有需求是否都已经不多不少地被实现了？
b) 验证工作产品与需求的符合程度：查看所有基线项评审和测试报告，看看所有的基线项是否都已经通过各级评审及测试？
c) 交付给客户的文档与软件的功能一致性：检查交付客户的文档是否与当前最新的基线中的需求一致？

4、配置管理活动的QA审查
配置管理过程的审查：
确保配置管理的记录和配置项是完整的、一致的和准确的审查行为，客观评价管理过程与其过程描述、标准和规程的符合性并处理不一致问题。

配置管理活动的QA检查时机：
定期检查配置管理工作，依据基线和配置审计计划检查这些基线的建立变更及配置审计活动。

检查内容：
a) 检查配置管理的各种记录、报告等与配置库中的物理的配置项实体是否一致、完整、准确
b) 是否每次新建和变更基线都有完整的申请记录
c) 每次基线新建和变更的审核流程是否执行并有记录
d) 基线库中的产品是否经过了功能审计
e) 每次配置审计的问题是否都被跟踪直到关闭
f)  配置库的权限是否都是正确分配的
g) 配置库的目录结构是否都与《配置管理计划》一致