CMMI之配置管理
2008-01-11 作者：张瑾来源：希赛网
在笔者进行CMMI咨询时，当问及软件技术人员什么是”配置管理”的时候，很多人的回答就是“版本管理”，而且很多人都会说出各种各样的版本管理工具，例如：VSS、TFS、CVS或SVN等等。
但这样的回答是不正确、不全面的。
版本管理只是软件配置管理的一个小的部分，在CMMI中配置管理分为“配置项和基线的管理”、“变更控制管理”和“基线的完整性”三个部分。
凡是提到软件“配置管理”（Configuration Management），我会先给它下个定义：“它是软件工程的核心部分，是CMMI中最基础的PA”。
为什么它会如此重要呢？首先配置管理的工作就是确保软件项目时时保持条理清晰，随时想要任何工作产品都可以迅速找到，并且工作产品的内容不会出错，这也就是大家常讲的可回溯性、完整性和正确性；其次软件配置管理活动始终贯穿整个软件项目的生命周期。
因此说软件配置管理是最基础、最核心的管理工作一点都不夸张。
(一) 软件配置项
在CMMI的“配置管理”过程域CM中SP1.1首先提到的就是“配置项”的概念，在大家开展配置管理工作前应该先识别哪些是本项目的配置项。
“配置项”就是配置管理的对象，简单来讲它符合以下任意一个特点：
1、它会被两个或两个以上的项目成员共同使用。
2、它会随着项目的开展而发生变化。
3、对项目重要的工作产品。
4、一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。
通过以上定义大家会发现项目中的很多东西都属于配置项，例如：各种需求文档、设计文档等都会经常变更；程序的代码是大家共享的，而且代码文件之间又有较高的相互依赖性。
那大家也许会发现还有一些工作产品不符合以上定义，例如：各种周报、会议记录等。
这些也是配置项
吗？很显然，它们不符合以上特点，那么这些工作产品就不属于配置项的范围，但有时在进行CMMI实施时，项目组也往往会将其一并进行管理。
既然配置项是“配置管理”的基础，那么大家还需要给每一个配置项起一个唯一标识，这样才能够做到清晰不混淆。
举个例子：“今晚大家一起出去聚餐，到中山一路的‘东北人’吃饭”，这里的‘东北人’餐厅是特指中山一路的，因此这唯一确定了就餐的地点；“我们订的包房叫‘靠山屯’”，这里具体的就餐房间也被唯一标识了出来，是‘靠山屯’而不是‘瘦狗岭’；服务员拿来的菜单上每个菜的名字也是唯一的，这样送上来的菜就不会重样，当我们吃完结账的时候就不会算错价钱，这些都是典型的唯一标识配置项的例子。
假如配置项没有被唯一识别出来，那么大家去聚会就会找错地方，点的菜也可能会上错，结账的时候也可能会算错，那么将是一团糟，因此在项目管理中一定要将识别配置项重视起来。
配置项本身的变化可以使用“版本管理”对其进行控制。
通常像大家的程序代码已经被各种版本管理工具进行控制，但大家千万不要忘记对文档也要进行版本管理。
(二)软件的基线
前面提到“配置项”的其中一个定义就是“配置项可能会随着项目的开展而发生变化”，那么单个的配置项是通过版本管理工具进行管理的，每次变化都会产生一个新的版本号。
但是对于一组配置项该如何进行管理呢？根据CMMI配置管理过程域的SP1.3中的要求，这就需要使用基线管理的方法。
简单来讲就是将一组配置项拿“线”穿起来作为一个整体进行统一命名，并将其作为一个新的配置项进行管理。
在上面聚餐的例子中，最后结账时的账单就是一条基线，它将所有菜肴集中起来一起买单。
(三)配置库的划分
配置库就是指各种版本管理工具所创建的用于管理配置项的数据库，也就是大家常用的VSS或CVS等工具创建的数据库或文档库。
笔者在以往进行的CMMI咨询时常常发现项目组对配置库的目录结构没有进行功能的划分，为了确保项目永远不会出现混淆，简单来说按照权限应该将配置库划分为三大类，如图1-1所示：
1、开发库
2、受控库
3、基线库
图1-1 配置库示意图
各种控制库的划分是根据其访问权限来定义的，在没有进行CMMI认证的公司，通常项目组的配置库只起到“开发库”的作用。
以CMMI配置管理SP1.2中的理论为依据，“开发库”对项目组成员具有比较宽松的“CheckIn”和“CheckOut”的权限。
不会给大家的工作带来不便，根据大家的需要随时都可以对其保管的配置项进行各种操作。
“受控库”对项目组成员来说是没有“CheckIn”和“CheckOut”的权限的。
对“受控库”的操作只能由配置管理员来完成。
因为受控库中存放的是等待评审的文档或待测试的程序。
假如有份文档要送去评审，会议的主持人已经将其进行了分发，可是这份文档却保存在“开发库”中，如果这时被别人修改了，那么之前所分发的文档就是旧的，那随后的评审也就没有意义了，这就是“受控库”存在的意义。
“基线库”就是对“受控库”中通过验证的工作产品所形成的基线进行统一管理，并且新的基线将按照要求发送给项目的相关人员并与其分享项目的状态和信息。
大家回想一下以往发布给客户的版本是否可以找到全部的程序和文档，如果找不到那就请从现在开始使用“基线库”进行管理吧：）
(四)软件变更管理
软件开发项目经常出现变更，但大家千万不要对项目中的变更产生恐惧，在项目管理的先进理念中“变化是永恒的，不变是短暂的”，“没有计划就没有变化”。
大家应该正视软件变更的存在，它是软件世界中客观存在的一种现象，就像初一、十五大海的潮汐一样。
在CMMI配置管理的SP2.1中就变更管理的流程和规范进行了定义。
1、软件变更的起因
为什么会出现软件变更呢？这要从软件项目的性质出发进行探讨。
PMP定义的项目特点是“临时性”和“独特性”，大家就算把已经完成的项目重新再做一遍，其过程也不可能是一模一样的。
其实软件开发就是将客户脑子里主观的思想转换为客观的代码行，主观的东西都是虚无缥缈的，根据人的意识会经常改变的；另外软件开发就是将企业的最佳实践转化为客观的产品，接受需求调研的客户一般都是他们行业中的佼佼者，他的思想就是企业的最佳实践，这些最佳实践也许连他的同事都不一定完全理解，何况是我们这些做软件开发的技术人员。
通过以上软件开发项目的特点进行分析，大家应该也理解了为什么软件开发会有那么多的变更了吧。
除了应该理解变更的起因外，还应该让我们的客户对变更的起因有所认识，做到大家互相理解，和谐的项目才是共赢的。
另外大家不要以为变更给项目带来很多麻烦，有时变更也会为项目带来效益，技术的革新就是一种特殊的变更，在我国实现现代化建设的过程中不知道有多少技术革新为国家带来或挽回数以亿计的财富，在我们的软件项目中一些新的技术或架构，也一样会减少项目的开发周期和成本。
2、软件变更的必要性
变更会有其相应的流程，有流程就会有工作量，有人会觉得变更太麻烦没有必要，在笔者进行CMMI 咨询时往往推荐两种级别的变更：“一般变更”和“重大变更”。
“重大变更”常指里程碑的延误、项目组成员的变化、项目成本的变化，具体每种变化有多大才算是重大变更呢？这就要针对不同公司的不同情况来定义。
为什么重大变更没有定义软件范围也就是需求的变更
呢？因为需求的变更可以通过项目里程碑的延误或项目成本的增加来判断。
重大变革要走正规的变更流程，并且要通过“变更控制委员会”CCB的评审通过后才能实施。
除了“重大变更”以外的都属于“一般变更”，例如项目进度虽然有延迟，但是不会影响项目里程碑。
“一般变更”不再需要CCB的评审，项目负责人就可以全权处理。
通过对变更级别的划分，给项目负责人一定的权利，这样项目变更就不会让人觉得繁琐了。
(五)配置管理的审计
配置审计的目的是配置管理员要确保配置库中的配置项和基线的完整性和正确性，这就是CMMI配置管理SP3.2所提到的概念。
在“开发库”中的配置项是不需要进行审计的，一旦带有缺陷的配置项进入“受控库”或“基线库”，那么将会给项目带来不小的负面影响。
配置管理的审计分为“物理审计”和“功能审计”两种。
“物理审计”比较简单，配置管理员只需根据项目组提交的“入库清单”逐一检查文档或程序是否存在，命名规则是否符合规范既可。
“功能审计”的理解会相对比较复杂一点，“功能审计”是对配置项的内容是否正确进行检查。
但配置管理员有可能是不懂技术的，那么他将如何开展功能审计呢？进入“受控库”或“基线库”的文档肯定是经过并通过评审的，代码程序也肯定要经过并通过测试的，因此配置管理员可以利用这些验证的结果来间接对其入库的内容进行检查。
这样配置管理员就可以保证其功能的正确。
(六)总结
通过以上内容的介绍，相信大家应该对CMMI配置管理的概念和重点有所认识了。
配置管理工作是贯穿整个项目生命周期的核心工作之一，只有利用配置管理的理论把项目条理化、清晰化，那么才能开展例如需求、设计、开发、测试等其他工作。
通过本篇文章笔者希望大家知道什么是配置项和基线，配置库是如何划分的，为什么软件项目会有变更，同时我们也要正视和接受变更的存在，以及配置管理员是如何进行功能和物理审计的。
