如何理解配置管理中所要求的“多级控制”？

有个同学问我这样一个问题：受控库和产品库的配置管理员如果是同一个人，是不是就违背了配置管理“多级控制”的要求？

在回答这个问题之前，我们看看标准当中对“多级控制”是怎么要求的。

GJB5000B配置管理实践域CM2.2中关于“多级控制”有两条活动实例，分别是：

c) 建立多级控制机制。多级访问控制等级宜根据项目生存周期的不同时段，产品的成熟度、系统乐行或配置项的保密程度设置。一般通过建立开发库、受控库和产品库，分配相应的权限，以实现在配置管理系统的不同库中存储、检索、更新以及共享和传递配置项；
d) 多级变更控制等级从非正式控制到正式控制，前者是对开发期间的配置项变更所作的简单跟踪，后者是通过正式的变更控制规程进行的配置管理变更。

其中，c)条说的是“多级控制”的一般要求，d)条只是针对变更下的“多级控制”要求。

c)条中我们可以看出“多级控制”的核心是将不同的产品纳入不同的库中进行管理，而且管理的权限也不相同。

比如：未经验证和确认的工作产品可以存储在开发库，工作产品的生产者拥有读写权限；经过验证和确认的被识别为受控配置项的工作产品存储在受控库，它的入库、出库、变更，都需要具备一定权限的人审批才行。

配置管理提倡“多级控制”，目的就是希望工作产品处于合理的管控当中，不希望工作产品失控，使用时出现版本问题，也不希望管控过于繁琐，流程很难执行，浪费工作量，又延长开发等待时间。

所以，“多级控制”体现在库的不同、权限的不同，与这个库的配置管理员没有什么关系。配置管理员只是执行物理配置审核，完成出入库流程中的操作，不同的库的配置管理员是否为同一个人，并不影响工作产品存放哪个库，不影响谁来存取/审批这个工作产品。

这正是：

多级控制好实践，用好功倍而事半
理解标准何含义，流程顺畅又不乱

作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000培训、内外部评价以及软件过程改进、软件工程能力提升的研究工作。