聊聊CM那点事

前一段时间，和几个人聊了关于配置管理，发现了很多细节的问题，例如：三库的建立和权限分配；配置管理系统是个什么东东？配置标识是个什么东东，为了能够保证过级，就命名了一个很长很长的符号；配置管理员执行功能审核，功能审核和物理审核有啥区别，基线是个什么东东，为啥还打个基线？结果呢，干活的人内心犹如待爆发的火山。所以呢，我想聊聊我理解的配置管理，不到位的地方请大家拍砖。

其实，软件过程活动中所有的定义，管理都和制造业是密切相关的，换句话就是和看得见，摸得着的实业是相关的。配置管理说白了，在软件没有出现在我们这个世界上之前，就是库房管理。库房管理，管的是硬件是看得见摸得着的东西，买的东西要进库房，就的有人提交，有人批准，库房管理员看看硬件名字是啥、日期、型号、领导批了，手续全了，然后进库房。

买来的东西是要用的啊，要用的话，用的人那个单子申请，请人批准，去库房管理员那里领，库房管理员看看手续全了没，然后领走，并且让领的人签个字，知道是谁领的。

现在有个问题，就是谁知道买来的东西能不能用哈，现在各个单位设置的检验员的角色。

好了，现在就回到软件上来。软件有啥特点：看不见、摸不着。

为了更好的让软件可控，借鉴了制造业中的“库房管理”，实施的“版本控制”，尽管在CMMI制定当初没有说一级应该怎么样，但是那个时候默认的可能就是对软件实施版本控制。后来随着软件它这位小鲜肉的重要性越来越提高，随着而来的是，变得复杂了，用的行业多了，种类也变得五花八门，最最重要的是：写代码的人的每一次编写的代码，更改很多；可能还存在基础代码上为了实现各个功能，会在基础版本上衍生处实现各种功能的代码版本；甚至可能因为，交付的代码是中间版本，拿到用户那里测试，惨烈的事情发生了：好多功能没有实现。怎么办？必须对软件的代码的更改。

软件的配置管理于是增加了“版本控制、更改控制”，为了使得这些更加有效，匹配的手段：

1）要有个符号（配置标识），为了这个软件和另外一个软件不能给同一个命，所以要求这个符号要独一无二性；

2） 和软件相关的文档啊，得管理起来啊，得进库房管理，为了表达这个库房不是随随便便的一个人就能进来拿东西的，给这个库取了个名“受控库”；

3） 进库房能随便进么，不能啊，得有人批准才能哈，批准了进库房“入库”，批准了才能拿出来“出库”；

4）入库的名字对不对，出库的名字对不对，流程走的对不对，这些物理性的东西都得给管库房的人检查了，才能入库；这个就是“物理审核”！

我觉得这些是配置管理员的事。

现在再看：功能审核。功能是啥，举例来说：手机有啥功能？打电话、拍照、能上网等等？谁能有能力去说这些功能实现了，谁就进行功能审核。现在返回来看，一个库房管理员能不能检查出一个软件能实现这个功能？他是否知道一个软件从头到尾要实现的功能？“不能”，那功能审核显然就不会是配置管理员的事。

  现在大家经常讲三库，这个可能和原来的一些硬性的标准有关。那么是不是就是三库？大家可以想，那些文件具体的是放在什么地方，由谁管理？例如：软件有些文档是放在项目组库房管理员那里，有些可能放在保密室，还有一些可能分布在其他的地方。这样受控库的组成，就是这些文档存放的地方。从这个角度看，可能是好几个库；也可能是好几个存放库组成了受控库。最终只要实现：受控即可！

关于开发库和产品库放什么？在最初的时候，对于开发库的描述，不受控级别。字面上理解，只要不进行控制的都可以放在开发库。产品库，要给用户了的内容才叫“产品”，放在产品库的就是提交给用户的内容。

基线，我们先看基线的定义：“在产品或产品部件的生存周期中一个特定时刻正式指定的配置信息。配置基线加上来自那些基线的经批准的更改构成当前的配置信息。”

一看定义，“不懂，讲啥呢？”，基线说白了就是个基准状态，表明这个阶段的活完成，下个阶段基于这个阶段的基础继续进行。结合软件产品过程，理想完美的“瀑布模型”定义，通常定义了“功能基线、分配基线、产品基线”；大多数对于前两个没啥疑问，而对于“产品基线”到底是放受控库还是产品库会有疑问？我们要去想：产品库放什么，放产品；怎么说明已经形成产品了，要通过产品基线说明已经形成产品了，这个转态的鉴定应该是在受控库中，表明已经形成产品，标上产品基线，然后把要交付给用户的产品的组成部分移交至“产品库”。

以上，是我对配置管理过程的部分理解。