对配置管理中的一些基本概念的认识

冰封伯爵

        什么是配置管理？CMMI中提到：配置管理过程域使用配置识别、配置控制、配置状态记录，以及配置审核，来达到建立与维护工作产品完整性的目的。
        从上面的解释可以看出，配置管理有四大功能域：配置项识别、变更控制、配置项状态记录(报告)和配置审核。
        下面就配置管理中经常出现的一些概念来谈谈本人的理解和做法，如有理解有误和不到之处，还望大家指正。

        一．配置库
        CMMI上讲到配置管理的三个库：一个是开发者使用的库（动态库）、一个是受到控制的库（受控库）和一个静态的库（静态库）。在我们组织中，也是建立了这么三个库，只不过分别称为开发库、受控库和产品库。同时，在受控库的基础上，我们抽象出一个基线库来（当然，这个基线库也可以是实际独立存在的）。这些是我们公司的做法，我想也是大部分组织的做法。下面分别就三库谈谈个人理解和实际管理方法：
        第一，开发库和受控库是项目级的，产品库是组织级的。也就是说，每个项目都有自己的开发库和受控库，组织公用一个产品库（存放各项目的产品）。
        第二，开发库是供开发人员使用的，配置管理员不必对开发库做太多的关注和管理。开发库中的工作产品，一般是“动态”的，也就是说处于“草稿”状态或“修改”状态。
        第三，关于受控库：我们做配置管理主要关注的就是受控库。而受控库中的内容（配置项）又分为两类，一类是做备份管理的，如里程碑报告、评审报告等；另一类是要关注其变更和版本变化的，如需求文档、代码等与交付紧密相关的。第一类是不对其进行版本管理和变更控制的，也不作为配置状态报告的内容；第二类是我们重点关注的配置项，是我们进行配置识别，配置标识和变更控制的核心内容。第一类配置项在其产生后配置管理员将其纳入受控库中进行备份；第二类配置项是在通过评审之后进入受控库的。
        第四，到了基线建立时机时，把受控库中的基线配置项打上tag，形成一条基线。若干基线就组成了我们的基线库。

        二．配置项
        首先看一下配置项的定义：配置项是为了配置管理所指定的一组工作产品，在配置管理过程中视为单一的实体。
        配置项的管理应该分类看待，我们只对关注的配置项进行管理和控制。那么什么才是需要对其进行管理和控制的配置项呢？我认为是与交付相关的配置项，比如需求文档、设计文档、代码、产品包等等。那么其他的配置项呢？有一些是结项后我们可能还会需要参考的，那么我们就对它们进行备份管理，但是并不对他们进行版本控制，如里程碑报告等。还有一些，它们只是会在项目进行过程中使用到，项目结束后就没有什么意义了，如普通会议纪要等，我们只把他们保存在开发库中，项目结项后甚至可以删除。
        接下来说说配置项的识别。配置项的识别是一个持续的过程，在制定《配置管理计划》时，配置管理员需根据《项目计划》初步识别配置项，同时，在项目进行过程中，配置管理员不断识别新的配置项，如代码配置项等。
        如何识别配置项？我们公司的做法是，只识别与产品交付相关的配置项，并对他们的状态进行跟踪管理。对于其他的配置项，不做识别。这点可能跟很多组织不同，我也正在考虑是否要对备份配置项实施管理，具体的管理方法还请大家多多指教，我目前想的是做个资料管理表。

        三．基线
       首先看一下基线的定义：基线是项目每个配置项版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
       “建立基线的目的是为了给其后的工作活动提供工作依据和基础”，其实基线还有一个重要的作用，就是可以在项目的任何阶段随时回到打基线时的状态。所以基线配置项一般来说就是能够为下一步工作提供依据和基础的配置项，当然也应该包括截止到本阶段的重要工作产品。
        当到达基线建立时机时，我们对基线配置项打tag，形成一个基线。
        建立基线的时机如何确定？很多组织是在里程碑评审之后建立基线，也就是说基线是和里程碑相对应的。我认为并不绝对是这样。基线可以比里程碑少，CMMI中只规定项目至少建立一个基线，基线应该是根据项目的实际情况来决定建立时机，按照基线的作用，如果有需要，那就建立。


下一篇：配置状态报告模板

冰封伯爵

timlq

一般来说，基线应与里程碑相对应。
对里程碑来说，这是PM、QA进行阶段项目总结的一个点，进而来查看相应的工作进展情况，进度成本等。同时根据基线的情况进行项目计划的修订等，调整下一阶段的工作（可能，如变更导致偏差）。
基线同时也可以很好的反应里程碑，比如需求基线、设计基线。

冰封伯爵

xixiaojing666



我们的做法,基线个数应大于或等于里程碑的个数,并且基线和里程碑相对应。。

冰封伯爵

xixiaojing666

我们对第一类的做法有所不同:
受控库中的内容也分为两类，一类是如里程碑报告、评审报告等项目管理及项目支持文件；另一类是如需求文档、代码等与交付紧密相关的工程类文件。第一类是我们也对其进行版本管理的,(项目计划还做变更控制)，但不作为配置状态报告的内容；第一类配置项在通过QA检查后,配置管理员才将其纳入受控库中进行备份；
我觉得项目管理和项目支持的部分文件也是项目的宝贵财产,在项目结项时比如项目风险\项目问题\项目经验等等都需要纳入资产库中进行分类总结!

amandating

对于“基线应该是根据项目的实际情况来决定建立时机，按照基线的作用，如果有需要，那就建立。”这一句，我有些疑问：
基线建立的时机不是应该在配置管理计划中就确定好的吗，而不是随机确定的。
什么情况下才会出现临时确定一条基线啊？

nuptszj

有道理就是有道理。

文风如刀

看了LZ的帖子，我只想说一句很好很强大！

kimi小可爱

看起来不错

暮墨染雨君画夕

顶不错 支持下

老娘照样过

看起来好像不错的样子

不爱我放了我﹌

我也来顶一下..

廉价的友情。

看了LZ的帖子，我只想说一句很好很强大！

绝不放弃。

有空一起交流一下。

整个春夏秋冬

其实，很多情况下都是这样的，习惯就好。

ruggle

very good.