什么是配置管理？CMMI中提到：配置管理过程域使用配置识别、配置控制、配置状态记录，以及配置审核，来达到建立与维护工作产品完整性的目的。
从上面的解释可以看出，配置管理有四大功能域：配置项识别、变更控制、配置项状态记录(报告)和配置审核。
下面就配置管理中经常出现的一些概念来谈谈本人的理解和做法，如有理解有误和不到之处，还望大家指正。
一．配置库
CMMI上讲到配置管理的三个库：一个是开发者使用的库（动态库）、一个是受到控制的库（受控库）和一个静态的库（静态库）。在我们组织中，也是建立了这么三个库，只不过分别称为开发库、受控库和产品库。同时，在受控库的基础上，我们抽象出一个基线库来（当然，这个基线库也可以是实际独立存在的）。这些是我们公司的做法，我想也是大部分组织的做法。下面分别就三库谈谈个人理解和实际管理方法：
第一，开发库和受控库是项目级的，产品库是组织级的。也就是说，每个项目都有自己的开发库和受控库，组织公用一个产品库（存放各项目的产品）。
第二，开发库是供开发人员使用的，配置管理员不必对开发库做太多的关注和管理。开发库中的工作产品，一般是“动态”的，也就是说处于“草稿”状态或“修改”状态。
第三，关于受控库：我们做配置管理主要关注的就是受控库。而受控库中的内容（配置项）又分为两类，一类是做备份管理的，如里程碑报告、评审报告等；另一类是要关注其变更和版本变化的，如需求文档、代码等与交付紧密相关的。第一类是不对其进行版本管理和变更控制的，也不作为配置状态报告的内容；第二类是我们重点关注的配置项，是我们进行配置识别，配置标识和变更控制的核心内容。第一类配置项在其产生后配置管理员将其纳入受控库中进行备份；第二类配置项是在通过评审之后进入受控库的。
第四，到了基线建立时机时，把受控库中的基线配置项打上tag，形成一条基线。若干基线就组成了我们的基线库。
二．配置项
首先看一下配置项的定义：配置项是为了配置管理所指定的一组工作产品，在配置管理过程中视为单一的实体。
配置项的管理应该分类看待，我们只对关注的配置项进行管理和控制。那么什么才是需要对其进行管理和控制的配置项呢？我认为是与交付相关的配置项，比如需求文档、设计文档、代码、产品包等等。那么其他的配置项呢？有一些是结项后我们可能还会需要参考的，那么我们就对它们进行备份管理，但是并不对他们进行版本控制，如里程碑报告等。还有一些，它们只是会在项目进行过程中使用到，项目结束后就没有什么意义了，如普通会议纪要等，我们只把他们保存在开发库中，项目结项后甚至可以删除。
接下来说说配置项的识别。配置项的识别是一个持续的过程，在制定《配置管理计划》时，配置管理员需根据《项目计划》初步识别配置项，同时，在项目进行过程中，配置管理员不断识别新的配置项，如代码配置项等。
如何识别配置项？我们公司的做法是，只识别与产品交付相关的配置项，并对他们的状态进行跟踪管理。对于其他的配置项，不做识别。这点可能跟很多组织不同，我也正在考虑是否要对备份配置项实施管理，具体的管理方法还请大家多多指教，我目前想的是做个资料管理表。
三．基线
首先看一下基线的定义：基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
“建立基线的目的是为了给其后的工作活动提供工作依据和基础”，其实基线还有一个重要的作用，就是可以在项目的任何阶段随时回到打基线时的状态。所以基线配置项一般来说就是能够为下一步工作提供依据和基础的配置项，当然也应该包括截止到本阶段的重要工作产品。
当到达基线建立时机时，我们对基线配置项打tag，形成一个基线。
建立基线的时机如何确定？很多组织是在里程碑评审之后建立基线，也就是说基线是和里程碑相对应的。我认为并不绝对是这样。基线可以比里程碑少，CMMI中只规定项目至少建立一个基线，基线应该是根据项目的实际情况来决定建立时机，按照基线的作用，如果有需要，那就建立。
下一篇：配置状态报告模板 |
service@step365.com
0571-87357690
狗仔卡
发表于 2008-4-11 23:06:41
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡