通过例子说明CMMI各级别不同

由于工作太忙，好久没有写点东西了，今天无意中发现通过例子讲解CMMI不同级别的区别的文章，感觉还不错，贴出来给大家看看。
------------------------------------------------------正文-----------------------------------------------------------

CMMI等级一共分5级，分别是：

Ø   CMMI 1初始级

Ø   CMMI 2管理级

Ø   CMMI 3可定义级

Ø   CMMI 4量化级

Ø   CMMI 5持续改进级

下面就通过例子具体讲下这5个级别的不同。

了解了CMMI的身世，我们再来看一下CMMI的不同级别。严格来讲，CMMI级别有连续式和阶段式两种描述方式。虽然方式不同，但所表达的意思是一样的。我们以最常用的阶段式进行描述。先来看下边这个故事：

1.   CMMI 1初始级

公司刚刚拿到一笔订单，公司让小张主要负责开发这个项目。小张是名牌大学毕业高材生，一个人可以几天几夜不休息写出几千行代码，在公司 属于大侠级人物。

接到上司的任务，小张不敢怠慢，仔细阅读了项目合同，并和用户方通了电话，仔细询问了用户希望实现的需求。经过一番深思熟虑，他的脑海里已经有了大概的构思。于是，小张打开电脑，开始了他非常熟悉的编码工作。

一周过去了，老板过来询问项目的进展，小张说如果不出意外的话，一个月应该差不多能完成。老板很高兴，夸奖小张很能干。

可接下来的事情并不像小张想象的那么顺利，他突然发现：由于一时疏忽，竟然忘掉了一个很重要的功能；如果将其加进去，需要推翻以前编写的大部分代码。想到已经跟老板夸下海口，没有办法的小张只好连续加班好几个晚上，最后终于把代码修改完成了。虽然经过了这样一次挫折，但是小张感觉还是比较庆幸：幸亏自己发现得早，要不然就死定了。

接下来的开发一切顺利，小张还是重复着夜以继日的编码工作。眼看就要大功告成，小张很高兴得把喜讯告诉了老板，于是老板也很高兴得通知了客户，说下周你们就可以过来看产品了。

用户高高兴兴来到公司之后，当小张跟他们介绍产品时，用户却挑出了很多毛病。原来小张当初没有完全理解用户的意图，此后也没有与用户进行太多沟通，他以为自己已经完全理解了用户需求，因此就按照心目中的想像把产品开发完成了。

看到用户提的那么多问题，小张别无选择。于是，他又开始没日没夜地修改起了代码。这次小张吸取上次的教训，跟用户进行了多次沟通，最后终于完成了产品。但是整个开发进度却延迟了一个月。虽然老板没有批评他，但是小张心里的滋味也不好受，可又能怪谁呢？只能怪自己运气不好，在项目中碰到了这么多倒霉的事情。

真的是小张那么倒霉吗？当然不是，而且他运气还算不错了。按照他这样的开发过程，只发生这两件事情已经是非常幸运了。在开发之前没有完全弄清楚用户的需求，也没有备忘录以免发生遗漏，更没有预先估计风险并采取预防措施，而只是碰运气，走一步算一步，你说能不出问题吗？所以，小张的开发过程还停留在CMMI第一级，也就是初始级的水平。

2.   CMMI 2管理级

如果用CMMI 2管理级水平进行改进，小张的这个项目应该怎么做呢？

在真正动手做之前，先别忙着编程序，应该先考虑一下怎么做才能把事情办好，并且尽可能想得周全一些。我们不妨从下边几个方面帮助小张分析一下：

(1) 用户的需求是什么？怎样确保真正理解了用户的需求呢？那就先做个系统的需求调研吧。

(2) 为了避免遗忘某个需求，我还应该把这些需求都记录下来才行。（REQM需求管理）

(3) 对了，这个功能技术难度太大，要不跟老板申请外包吧。（SAM供应协议管理）

(4) 剩下的任务老板让我一个月完成这个任务，我得先计划一下，要是完不成，我得提前跟老板说啊。（PP项目计划）

(5) 计划出来了，还不错，可以完成。不行，还不能高兴的太早，我每周还得跟计划对照一下，看计划完成得怎么样。（PMC项目跟踪）

(6) 要是我的代码下次也能用就好了，而且以后维护也得用啊，我得找个工具把代码管理起来。（CM配置管理）

(7) 老板不太放心，安排了一个人来监督我，呵呵，我做的很好，尽管汇报吧。（PPQA质量保证）

(8) 任务完成了，真累啊，不行，我得算算我在这个项目上花了多长时间，加了几次班，遇到了哪些问题，这些问题是怎么产生的，下次的项目我得提前做好打算。（MA度量）

经过了这样的考虑和计划，小张顺利开发完了第二个项目，产品拿到用户那里正式使用了，小张也因为出色的表现受到了领导的表扬。

可是产品上线不久，就因为负荷压力过大引起死机，给用户造成了很大的影响。这个问题迅速反馈到了公司老板那里。老板找到了小张。呵呵，看来小张真够倒霉的，什么事情都让他碰上了，小张百思不得其解，为什么我这么努力，还是出问题了呢？

原来，小张开发完之后，由于测试人员出差，他就自己测了一下，觉得没问题就交给了用户。用户对产品也很放心，认为应该没什么问题，产品就上线了。但由于用户实际使用环境远比小张的开发环境复杂得多，而这些小张之前并没有意识到，也根本没有进行这方面的考虑和设计。所以才发生了这样的一幕。

3.   CMMI 3可定义级

那么小张应该吸取什么教训呢？我们用CMMI 3 可定义级来帮着分析一下。

(1) 在了解用户需求之后，编码之前其实还要做很多工作。首先，应该把需求分析一下，看看哪些是功能需求，哪些是非功能需求，如何进行模块划分，不同模块之间会有哪些接口需求等等。由于小张缺少这样的分析过程，也没有形成最终的需求规格说明书，所以他最终还是遗漏了非功能需求，以至于产生上边的问题。（RD需求开发）

(2) 需求分析完成之后，小张还应该进行设计，把用户所有的功能需求和非功能需求进行统一考虑，形成设计说明书，然后再进行编码。这样才会保证代码结构合理，并且会全面满足用户的需求。（TS技术解决方案）

(3) 在开始编码之前，小张还应该考虑一下不同模块和组件之间集成的顺序，必要的话，还应该跟用户商量一下，根据用户需求的优先级来决定模块组件开发和集成的顺序。（PI产品整合）

(4) 为了保证设计和编码质量，部门还应该组织一些经验比较丰富的人员来帮助小张发现一些问题，因此，在开发过程中，还应进行设计评审和编码走查方面的工作。小张自己也应该进行一些单元测试，以便及时发现问题，减少影响和损失。开发完成之后，小张必须交给测试人员进行系统测试，因为自己检查自己的代码往往是检查不出什么问题来的。（VER验证）

(5) 测试人员测试完成之后，在产品真正上线之前还应该进行验收和试运行。试运行一段时间，一切都没有问题之后，再将产品正式切换上线。这样即使在这个阶段发现Bug，也不会造成太大影响。为了确保验收效率，小张可以事先准备一份验收大纲。（VAL确认）

在CMMI 3 可定义级中，把以上5项作为工程流程领域，无论做怎样的裁减，这5项都是不能裁减的。它们之间的关系在CMMI 1.2中文版中用下图来表示：

经过这样一番分析之后，小张终于明白：看来自己是少做了很多工作。于是他决定下一个项目一定按照该流程好好做。

小张的项目引起了公司极大重视，为了避免类似问题产生，公司专门进行了以下工作的改进：

(1) 公司过程改进部门分析了问题产生原因，找出了不足，并针对不足制定了相应的改进计划。（OPF组织过程焦点）

(2) 结合成功项目经验，经过认真分析和考虑，公司内部制定了软件开发生命周期规程指南，同时还制定了相应的文档模板。（OPD组织过程定义）

(3) 为了保证各部门相关人员密切配合，团结协作，各负其责，公司专门定义了软件开发不同角色以及角色职责，确保各种角色充分发挥其作用，保证整个团队的协作开发。（IPM集成项目管理）

(4) 为了减少项目风险，组织了有经验的项目经理和开发经理，总结归纳项目风险，建立部门风险知识库，并要求在项目过程中进行风险管理。（RSKM风险管理）

(5) 为避免重大决策失误，成立了专家团，制定决策分析依据，在一些项目的重要决策上，帮助项目进行决策分析，以减少风险。（DAR决策分析与解决方案）

(6) 为了便于大家理解和吸收，公司专门组织了相应培训，同时还进行了需求开发、设计、单元测试方面的培训，这些培训使大家受益匪浅。（OT组织训练）

经过这样的改进之后，公司整体的开发和管理水平都上了一个很高的台阶。项目成功的几率也大大提高了，公司还专门请来了CMMI评估师，并且顺利通过了3级的正式评估，客户的订单也就纷至沓来。从这点来说，公司真的应该感谢小张才对啊！

4.   CMMI 4量化级

过了CMMI 3级，公司各方面工作井然有序，一切都很正常。看上去似乎没有什么需要改进的了。就这样过了一年的时间，年底将至，公司正在加紧统计一年来的利润和成本，统计的结果却让人吃了一惊：虽然公司的合同额非常大，利润却不是很多，这是什么原因呢？原来公司虽然在软件开发上做了很多工作，保证了项目顺利的开发完成并上线，但是每个项目的真正数据并没有进行记录和统计分析。一个项目实际花费了多少工作量，产生了多少费用，到底什么项目利润比较大，可复用性比较强，什么项目个性化需求太多，成本比较大，可复用性较弱。这些都没有相应的数据进行支持。

发现了这个问题之后，公司又召开了一次经理会议，做出了如下改进措施：

(1)  建立公司内部统一的过程管理平台，所有项目和产品的开发都要通过过程管理平台进行管理；

(2) 根据平台的数据积累，公司制定了统一的量化目标以及相应度量活动。（OPP组织过程绩效）

(3) 根据公司的量化目标，每个项目定义自己的量化目标，并且定期进行偏差分析，分析偏差产生的原因，制定相应改进措施.（QPM量化项目管理）

经过一段时间，平台中积累了大量数据。每个项目实际成本、项目进度、风险以及曾经发生过的问题在平台上都能够一目了然。在这些历史数据的帮助下，销售人员对项目的报价充满了信心；开发经理做项目计划的偏差率也越来越小，对项目问题的预测和掌控能力也更加强大。这不，公司正准备进军CMMI 4呢！

5.   CMMI 5持续改进级

虽然小张所在的公司刚准备向CMMI 4级发起进攻，不妨先了解下5级也没有关系，它并没有我们想象的那么可怕。5级只有两个域，分别叫组织创新与发展（OID）、原因分析与解决方案（CAR）。这两个域的主要意思，就是在度量的基础之上，选择循序渐进的创新与改善活动，逐步改善，从而达到企业制定的各项指标；同时对发生的问题以及产生的缺陷进行分析，并采取积极预防措施，避免类似问题再次发生。