[转]CMMI等级说明

CMMI等级一共分5级,分别是:CMMI 1初始级  CMMI 2管理级  CMMI 3可定义级  CMMI 4量化级  CMMI 5持续改进级

下面就具体讲这5个级别,

CMMI 1初始级

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

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

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

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

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

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

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

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

真的是小张那么倒霉吗?当然不是,而且他运气还算不错了。按照他这样的开发过程,只发生这两件事情已经是非常幸运了。在开发之前没有完全弄清楚用户的需求,也没有备忘录以免发生遗漏,更没有预先估计风险并采取预防措施,而只是碰运气,走一步算一步,你说能不出问题吗?所以,小张的开发过程还停留在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中文版中用下图来表示:

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

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

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

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

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

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

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

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

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

CMMI 4量化级

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

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

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

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

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

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

CMMI 5持续改进级

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

以上内容转载自网络,不过来源已不清楚

» 转载保留版权:《[转]CMMI等级说明》
» 本文链接地址:https://www.xidige.com/222

打开支付宝扫一扫,即可进行扫码打赏哦

扫码支持
扫码打赏,你说多少就多少

标签:

分享到:

扫一扫 在手机阅读、分享本文

上一篇: 下一篇:
评论区0人评论151人参与

电子邮件地址不会被公开。 必填项已用*标注

*

loading

赞助商广告