白话CMMI

白话CMMI

文/李红

CMMI的身世

关于CMMI的发展历史,说起来确实非常复杂。早在1984年,美国国防部希望将国防部的软件委派给其他软件公司进行承做。由于没有办法评估软件公司的承接和执行能力,因此委托卡内基梅隆大学软件工程学院(Software Engineering Institute,简称SEI)进行一项研究,希望能够在软件产业建立一套工程制度,用来评估和改善软件开发公司的过程和能力,并协助软件开发人员持续改善流程的成熟度以及软件质量,从而提升软件开发项目及公司的管理能力,最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。

基于此目的,SEI1986年开始研究能力成熟度模型(Capability Maturity Model,简称CMM),于1991年正式推出了软件能力成熟度模型(Capability Maturity Model For Software,简称SW-CMM),并发布了最早的SW-CMM 1.0版。经过两年试用之后,1993SEI正式推出SW-CMM1.1版。

那么CMM又怎么发展成为现在的CMMI了呢?原来,在CMM1.0推出之后,很多单位都先后在不同的应用领域发展了自己的CMMs,其中包括系统工程能力成熟度模型(Systems Engineering Capability Maturity Model, SE-CMM)、整合产品发展能力成熟度模型Integrated Product Development Capability Maturity Model, IPD-CMM)、人力资源管理能力成熟度模式 People Capability Maturity Model, P-CMM等应用模型。

这些不同的模型在自己的应用领域内确实发挥了很多的作用,但是由于架构和内容的限制,他们之间并不能通用。于是SEI200012月公布了能力成熟度整合模型Capability Maturity Model - Integrated, CMMI,主要整合了软件能力成熟度模型(SW-CMM2.0版,系统工程能力模型SECM和整合产品发展能力成熟度模型(IPD-CMM0.98版。在随后的发展过程中,本着不断改进的原则,CMMI产品团队不断评估变更请求并进行相应的变更,逐渐发展到目前的CMMI 1.2 版本。在CMMI文版资料中,用这样的图来描述CMMI的发展历史:

         CMMI的集成达到了两个目的:一是将多学科领域之间的公共过程域进行了提炼;二是减少了过程域的总数量。但是,看到这里,我们会想到另外一个问题:CMMI集成了那么多领域的标准和规范,在实施过程中难道需要全部满足吗?不是的,企业在利用CMMI进行过程改进的时候,首先必须根据自身的主要业务类型和改进目标等,选择适合于自身的规范。例如:从事某个领域软件开发的企业,没有外包和采购业务,那么可以考虑使用在软件开发和系统工程方面进行了集成的CMMI SW/SE。对于需要集成多个产品,或者产品开发受到其他工程影响的企业,可以采用CMMI-SE/SW/IPPD。另外对于涉及到产品的获取和转包方面的企业,可以考虑使用CMMI-SE/SW/IPPD/SS

CMMI 1——初始级

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

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

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

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

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

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

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

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

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

CMMI 2——管理级

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

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

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

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

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

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

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

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

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

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

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

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

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

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级的正式评估,客户的订单也就纷至沓来。从这点来说,公司真的应该感谢小张才对啊!

CMMI 4量化级

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

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

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

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

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

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

CMMI 5——持续改进级

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

怎么样,看完这个故事,你是否觉得CMMI离我们并不是那么遥远呢?是不是也已经被我“迷惑”,对CMMI有些痴迷了呢?呵呵,尽管CMMI有如此多好处,企业也有一万个理由应该去实施,但是切不可操之过急。要先考察企业的真正需求和现状,看到底需不需要这些改进,有没有能力进行改进,改进的过程需要哪些方面的配合等等;否则,改进不但不能产生相应的效果,很可能还会起到相反的作用。要知道:企业的过程改进也是一个项目,需要做好充分的准备,并且做坚持不懈的努力。

posted @ 2008-03-20 13:50  龍的傳人  阅读(958)  评论(1编辑  收藏  举报