基于CMM和CMMI的配置管理（转）

本文主要从CMM和CMMI的要求出发，介绍了标准主要涉及的配置管理内容，并对相应内容进行初步地说明，最后提供了一个配置管理在项目实施的指南和一个在组织中部署配置管理的模型。

在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。但是，仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑关系见下图：

1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的

3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要求

1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集合，并进行管理和控制
    2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子产品的正确”
    3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更
    4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项管理”
    5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史
    6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计等
    7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理

在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。
受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项（CSCI）。
现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐，一般推荐使用配置管理工具，减少事务性工作。

在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。

一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。
每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。

基线具有以下属性：
通过正式的评审过程建立
基线存在于基线库中，对基线的变更接受更高权限的控制
基线是进一步开发和修改的基准和出发点
进入基线前，不对变化进行管理或者较少管理
进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基础
不会变化的东西不要纳入基线
变化对其他没有影响的可以不纳入基线

建立基线的好处：
重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。

基线管理的步骤：
1、在开发前确定基线的“配置”
2、基线批准前，根据“配置”检查配置项是否齐备
3、对各个配置项，确认其版本的正确性
4、对每个配置项建立基线标志，
例如上图为：测试基线=（配置项A=1，配置项B=1，配置项C=1）
alpha版=（配置项A=2，配置项B=1，配置项C=1）
beta版=（配置项A=3，配置项B=3，配置项C=2）
产品基线=（配置项A=4，配置项B=4，配置项C=4）
5、基线变更管理
6、基线的各类报告和审计信息

针对某个具体得项目，可以根据基线的内容，建立一个基线信息的跟踪表，例如如下：

[注]：被色块覆盖的表示，此配置项属于对应列的基线
[注]：在色块的栏目填写对应配置项的版本号

在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖有下的变更管理。

缺乏有效的变更请求管理会导致的问题：
软件产品质量低下，对一些缺陷的修正被遗漏
项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力
开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况
可能错误使用和引用已经变更的产品，引起开发工作混乱

变更管理的流程：
（获得）提出变更请求；
由CCB审核并决定是否批准；
为（被接受）修改请求分配人员，提取SCI，进行修改；
提交修改后的SCI，并测试（或者评审）；
重建软件的适当版本；
复审（审计）所有SCI的变化；
发布新版本。

为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》，分别如下：

6 配置库管理

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，必须规划好工作空间的管理。主要的手段是设置配置库（即文件夹设置），和设置版本的分支，来实现对配置项权限管理。

设置版本分支

基本上要为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支。让它们分别对应3类工作空间。

私有分支：
私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。

集成分支：
集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。

公共（主干）分支：
公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

配置库的日常工作

配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：

对配置库的定期备份

清除无用的文件和版本

检测并改进配置库的性能等

7 配置报告

配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。

配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目状态对变更的情况也应当进行报告。有时，对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。

8 配置审计

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。同时配置审计工作应当可以说明如下信息。

配置审计应当说明的信息：
1. 变更要求被完成，并且对附加的修改已经执行了
2. 采用了正确的正式验证手段
3. 遵循了标准的要求
4. 变更的4W信息被完整记录，并和相关配置项关联

9 项目实施指南

一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。

一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。

在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这三个层面是彼此之间既独立又互相联系的有机的整体。

（1）主要由配置人员完成的管理和维护工作；

（2）由系统集成员和开发人员具体执行软件配置管理策略；

（3）变更流程。

软件阶段	活动	活动说明
计划阶段	制定软件计划	一个项目设立之初，项目经理首先需要制定整个项目的计划
	确定配置策略	配置管理委员会（CCB）根据项目的开发计划确定各个里程碑和开发策略
	制定配置计划	配置人员根据CCB的规划，制定详细的配置管理计划，交CCB审核
	批准配置计划	CCB通过配置管理计划后交项目经理批准，发布实施
开发阶段和维护阶段	确定初始基线	CCB设定研发活动的初始基线
	配置库管理	配置人员根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备；并定期进行备份和清理工作
	授权开发	开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作
	集成	系统集成员按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进
	管理基线	CCB根据项目的进展情况，并适时的建立基线，批准基线变更，保证开发和维护工作有序的进行。
	产品发布	系统集成员进行产品集成，由CCB批准，进行发布
其他	配置会议	CCB定期举行例会，根据成员所掌握的情况、配置人员的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。
	配置报告和审计	配置人员定期向项目经理和CCB提交审计报告，并在配置管理例会中报告项目在软件过程中可能存在的问题和改进方案
	变更管理	事件触发执行，由CCB批准、项目组执行，并执行审计

10 配置管理部署模型

基本过程

序号	阶段	活动	备注
1	获得相应管理权
1.1		建立相应负责团队
1.2		获得授权和资源	可召开启动会
2	评估配置管理现状
2.1		绘制和评估当前过程的控制图	可采用CMM标准
2.2		了解员工对配置管理的态度
2.3		了解组织的配置管理技术水平
2.4		了解领导期望
2.5		编制并评审评估报告	获得“现状信息”
3	配置工具选择
3.1		编制、评审《评估评分表》
3.2		评估配置工具和供货商
3.3		收集其他用户的使用经验
4	配置过程定义		制定配置管理过程草案
4.1		利用“现状信息”和收集的经验
4.2		制定新的过程
4.3		评审新过程，并建立新的过程基线
5	试点
5.1		选定试点项目
5.2		确定试点负责小组
5.3		定义试点成功标准和进度
5.4		试点项目人员培训
5.5		试点改进	同时对草案进行改进
5.6		试点总结/推广	完成正式过程的发布
6	全面实施
6.1		组建相应部门和团队
6.2		制定各个项目的实施计划
6.3		配置管理知识、过程、工具的培训
6.4		帮助各个项目向新过程迁移
6.5		日常监督、抽查、沟通
7	结束		总结、奖励

相应操作文件

对应过程：2.2了解员工对配置管理的态度建立一个CHECKLIST，来进行调研，如下

序号	调查内容	调查结果
1	原来是否有过类似尝试，成功或者失败了
2	是否有由于配置管理不好造成的痛苦经历
3	对建立配置管理过程是否支持
4	是否觉得配置管理过程会压抑创造性
5	是否觉得配置管理过程太繁琐
6	对配置管理是否有不合理的期望
7	是否有些急功近利
8	是否对实施配置管理工具感兴趣
9	个人英雄主义和分工协作那个是主流

对应过程：2.3了解组织的配置管理技术水平建立一个CHECKLIST，来进行调研，如下

序号	调查内容	调查结果
1	是否已经有了配置管理过程，运作时间
2	是否使用了配置管理工具，使用时间
3	是否接受了配置管理的专门培训，培训时间
4	对配置管理过程的认识程度
5	对配置管理工具的使用程度
6	企业员工的基本素质和学习能力

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下

序号	调查内容	调查结果
1	工具可以解决当前问题，满足当前需求吗？
2	产品的市场地位
3	产品价格
4	与现有环境的兼容程度
5	运行能力（峰值情况、成熟性、稳定性）
6	是否支持未来需求
7	是否具备：工作空间管理
8	是否具备：版本控制
9	是否具备：配置报告
10	是否具备：过程支持
11	是否具备：安全和保护
12	是否具备：工具集成
13	是否具备：构造支持
14	是否具备：图形界面
15	是否具备：自定义支持
16	是否具备：发行管理
17	是否具备： WEB支持

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下

序号	调查内容	调查结果
1	配置管理服务从业时间
2	成功案例数量和质量
3	培训、技术支持队伍
4	提供的培训和指导，以及其他服务
5	近期关于配置服务的商誉、资产、销售额
6	地理位置、服务及时性

对应过程：4.2制定新的过程1. 配置管理过程至少应当包括的内容：配置标示、配置控制、报告、审计2. 在考虑工具纳入配置过程中应当考虑下表内容

序号	考虑内容
1	从配置过程中分解出那些是事务性、那些是创造性的工作
2	考虑事务性工作的繁重程度和精度要求程度，理出一个“自动化优先级”
3	根据过程，确定工具可以运用的地方
4	根据“自动化优先级”选择那些工具功能进行自动化
5	考虑使用工具功能自动化的前提和结果
6	划分出“自动化”和“人工”的接口，并清晰描述
7	调整过程要素，适应工具，从而形成一个纳入了工具的配置管理过程
8	考虑这个过程的适用性和效益

对应过程：6.1组建相应部门和团队负责配置管理部署和实施的团队必须包括

序号	团队成员	职责和要求
1	组长	负责管理小组，并负责配置管理的部署和实施
2	技术人员	负责考虑将要和配置工具集成的各类工具之间的接口
3	配置专家	配置工具精通、配置管理理论知识熟悉
4	过程专家	负责过程建模和主要的过程分析工作
5	配置管理人员	负责评审新过程，并提供原来配置管理的经验
6	项目经理	负责评审新过程，并提供配置管理适应于项目的参考

对应过程：6.2制定各个项目的实施计划计划应当包括的内容：

序号	计划内容
1	目标和完成标准
2	投资和收益分析
3	阶段划分和进度安排
4	资源投入安排
5	人员分工和组织
6	风险管理