CMMI和CMM框架比较

这是以前不太了解CMMI和CMM的时候写的文章。（2006-6-10）

在××公司的四年里正好和公司过程改进的步伐并行前进，这四年里我做过项目经理、配置经理、EPG成员、技术总监，无论哪个角色都和项目管理体系是密不可分的，下面我将对比CMM来阐述CMMI实施中的一些心得和大家分享。

生命周期的变化

也许是CMM实施的不好，当时选用的是以瀑布模型为基础的生命周期，以前我们的项目尽量采用一个基线，即客户签字确认的需求规格说明书和静态原型。在实施CMMI时，把生命周期描述成迭代的瀑布模型，因为这才是公司项目管理的实际，从需求开始把每一部分确认的需求产生一个基线，这样就产生了很多基线，设计、代码、测试用例也如此。项目实施由于进度的压力很难按照瀑布模型按部就班的去做，这种多基线的迭代从实施的角度更加科学和合理，当然管理上也会付出较大的代价，例如配置管理方面要对多基线进行管理，估算和人员投入也需要根据多基线的特点进行安排。

对需求工程的强化

众所周知，项目中需求是整个生命周期的源头，在实施CMM时只强调了需求管理，而需求工程至少要分为需求开发和需求管理两个部分，这正好和CMMI的过程域（PA）相吻合。在很早公司级就有一套需求开发的过程，这是以六边形法则的方法论为基础的一套体系，六边形法则从组织机构、基础设施、业务流程、业务应用、业务数据、业务地点六个方面来和客户一起获取业务需求，所用到的工具包括调查问卷，问题反馈表，用例图，页面原型等。在实施CMM的时候我们还只关注需求规格说明书，而对产生需求的过程没有作什么约束，通过实施CMMI我们把有些问卷按照六边形法则模板化，页面原型也制定了统一的标准。又加上对需求开发过程中产生工作产品的验证，这些手段使我们的需求开发过程更完整，需求结果更准确。需求管理方面和以前的做法类似，通过需求跟踪矩阵来跟踪需求，通过变更过程来控制变更。

验证手段
在实施CMM的时候，会经常对关键工作产品进行测试、同行评审和质量保证等一系列活动，同行评审是一种QC活动，评审过的工作产品缺陷才能降低，在实施CMMI时有很多验证活动，其实也是一种评审，但是被抽象到更高的高度。例如对产品组件的验证，对集成测试环境的验证，关键计算机资源的验证等等，这些虽然是些琐碎的事情，但是做了这些验证工作才能降低项目的风险。