信息安全资质认证 当前您的位置:智汇源顾问>>信息安全资质认证
CMMI软件过程能力认证评估

★ CMMI软件过程能力认证评估★

 


7.1企业如何选用CMM/CMMI
企业选择CMM还是CMMI,主要基于以下几个方面进行考虑:
• 1.
实施企业的业务特点:如果企业的规模不是很大,业务又集中在软件开发为主,那么还是软件CMM比较适用。如果企业的规模比较大(开发人员100人以上),并且业务不仅仅集中在软件开发,还包括硬件开发哪怕是硬件代理(采购)都可以考虑实施CMMI 
• 2.
实施企业对过程改进的熟悉程度:如果企业已经实施过ISO9000,并且取得了较好的效果,那么可以考虑实施CMMI。如果企业虽然没有实施过CMM,但是对于过程改进一直比较关注,接受过不少相关培训,甚至能够自发的进行一些过程改进,那么也可以考虑实施CMMI。如果过去没有接触过类似的工作,那么最好先从软件CMM 2级开始,首先建立持续过程改进的思路。另外,软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。 
• 3.
实施企业对过程改进项目的预算:不论怎样,几乎可以肯定地说,实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看,CMMI27个过程区域在内容上并不比软件CMM26个关键过程区域多多少。所以,我们完全可以少花钱、多办事,也就是说可以采用CMM的实施和评估方法,但可以在过程改进的时候参考CMMI的要求,这样就会经济很多。

7.2你的CMM认证是的吗
不用看一个企业通过了CMM的几级认证,只先问它都用了哪些自动化开发工具,用到了什么程度,就知道它的CMM认证是
  听软件企业说CMM(Capability Maturity Model,能力成熟度模型)认证听了很久,到现在都已经开始谈CMMI(Capability Maturity Model Integration,能力成熟度模型集成)了。也不断听到国内软件企业通过了CMM2CMM3认证的消息,甚至有少数企业通过了CMM4CMM5级认证。但是却没看到国内软件企业拿到外包项目的数量急剧上升,甚至在某些领域,国内一些获得CMM3资质的企业的外包订单反而远远少于印度一些获得CMM2认证的企业,不少台湾地区的软件企业也比祖国大陆的软件企业做得更好。
  为什么会这样?曾有业界人士自暴内幕:在具体的软件外包项目谈判时,外包方问,你们都采用什么自动化开发平台啊?承包方一听这话就傻眼了。不少通过了CMM认证的企业把最多的精力花在了CMM资质评估上,例如在评估前邀请印度培训师进行内部培训,协助准备一大堆评估需要的资料,然后大张旗鼓地迎接评审,但获得资质之后又继续照旧原来的手动开发流程,根本不会用到任何自动化开发工具。这样的谈判最终往往会以失败告终。精明的外包方知道,如果没有任何自动化开发工具,CMM认证中的很多事情是难以手动完成的,就像一个汽车流水线中不可能所有工序都是手工操作一样。
   为CMMCMM是不少企业在CMM实施中很容易走进的误区,认为拿到一定的CMM资质之后就能够争取到无数的外包业务,以至最终为了达到这一目的而不择手段,甚至一些媒体在谈到CMM的时候也将讨论重点放在了CMM过高的评估费用上,而忘了实施CMM最原始的目的是为了提高对软件开发的管理,最终实现ROI的提升。
  这种本末倒置的做法一直以来就受到业内专家的指责,但解决的办法也只是停留在呼吁软件企业要端正对CMM的态度。呼吁意味着什么?意味着最终寄希望于软件企业自身的观点转变。其实绝大多数企业也都明白要用长远眼光去看问题,但眼看一些虚假繁荣的软件开发企业因为顶着CMM认证的光环而受益,不少心里明白的企业决策者还是抱着侥幸心理试图闯关。
  事实上,很多时候对一件事的态度真的只是一念之差。能否有态度的端正一方面取决于自身的主观因素,另一方面客观环境和客观条件的限制更是帮助软件企业端正CMM态度的良药。笔者希望告诉这些侥幸的企业,当CMM/CMMI认证体系越来越严谨,当软件外包方的要求越来越严格,当软件消费者的消费心理越来越成熟,这种侥幸心理遭遇的将是一败涂地。而且更重要的是,很多能够大大提高软件开发效率、降低软件开发成本的做法,如果没有自动化工具的帮助是完全做不到的。
  例如外包订单中的团队协作开发,异地同步软件开发是不少外包订单常用的手法,美国、欧洲和亚洲相互之间的时差都在8小时左右,如果三地能够利用时差一天实现24小时的不间断开发无疑将大大提高开发效率,但这样的协作开发如果没有自动化的软件配置管理工具、变更管理工具、统一的质量系统流程等的帮助,根本无法完成。
  再例如,版本控制管理工具一般都能帮助软件开发回到任何一个时间点的生产基线,当发现开发思路有所偏差时,可以自动将所有程序恢复到从前一个时间点的状态,这对手工开发来说完全不可想象。
  IBM软件部Rational软件大中华区销售总经理陈致平先生接受记者采访时还提到,在很多外包订单中,上游开发商希望承包方的开发环境能够与自己的自动化开发环境接轨,就像制造产业链的上游厂商可能希望下游供应商能够与自己使用相同的ERPCRMSCM系统一样,从而能够进行无缝的连接。
  除了外包项目,一般的软件开发项目如果使用自动化开发工具,在减少重复开发、管理每个开发者的访问权限、避免软件资产流失等方面也都有很大的帮助。自动化开发工具不是实现CMM的充分条件,但一定是必要条件。
  自动化工具不是装点门面
  自动化开发环境曾经经过多个阶段的演变,从最早的简单CASE工具,到后来的应用开发生命周期(Application Development Life Cycle)、软件开发生命周期(Software Development Life Cycle),再到今天的自动化软件开发平台(Software Development Platform),软件开发的状态也从纯手工进化到片断式的自动化开发,最终进化到完全的自动化开发。
  当软件产品价格越来越便宜,软件产品的功能越来越多样化,软件开发企业就将面临着像制造企业必须上马ERP一样的情形,自己的软件生产线自动化程度越高,自己的核心竞争能力也就越强。
  CMM认证不是用来装点门面的,自动化开发工具和平台更不是用来装点门面的。有限的资金要用在刀刃上,如果资金有限,或许把评估费用放在自动化开发工具的投资上,反而更加务实。当然如果资金状况允许,自然可以鱼与熊掌兼得。

 

7.3CMM实施经验谈
在基于CMM实施软件过程改善时,有些根本的思想认识问题解决不了,往往会使实施的周期比较长,效果不好,甚至导致过程改善的失败或中止。软件企业的高层领导、企业的过程改善主管、销售人员、项目经理及一般的开发人员都需要对这些问题统一认识,在此基础上才能消除各方面的阻力,把握好过程改善的方向,控制好过程改善的进度。笔者在总结了3年的实施CMM的经验教训后,归纳了如下几个思想认识问题,供拟准备进行过程改善或正在进行过程改善的软件企业同行参考:
   CMM不是万能的,只有CMM是不行的,还要技术(开发方法、工具)人员二个要素一起改善
  在软件工程发展的历史进程中,人们为了解决软件危机,尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案,但是效果并不那么显著,CMU SEI提出了软件过程能力成熟度模型(CMM)基于过程的角度来解决软件危机。那么是否实施了CMM,软件企业的开发能力就一定能提高,一定能带来经济效益呢?答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高,才能保证带来经济效益,因为人员、技术和过程是支撑软件开发平台的三条腿,少了那一条都不行。大家也都知道木桶原理,一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子,都需要全面提高,只关注一个方面,而忽略了其他方面,都是有害的。
  在开始实施CMM时,最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善,忽略了开发技术与人员的提高,过分强调管理的作用,实施了半年或一年后,发现企业的生产能力并没有得到明显的改善,这时反对的声音就会成为主流,过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发,但是企业内并没有对面向对象技术真正了解的专家,虽然也采用RUP过程、也采用ROSE等开发工具,但是仅仅是形似,没有做到真正的OO方法,没有得到OO方法的精髓,这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差,工作热情很低,企业的激励机制没有起到很好的作用,这种问题也是依靠CMM无法解决的。
  
管理就是预防,管理的作用是隐性的,不都是立竿见影的,大家要有耐心
  在实施CMM时,企业的管理层在开始时往往会对过程改善期望值太高,希望短时间内效果显著,上面我们谈到了,效果显著与否不是由一个方面的要素决定的,需要多个因素共同改善。而管理的最大作用是预防,防患于未然。任何的管理的改善都是符合J曲线的,即在改善的初期企业的运行效率可能会下降,甚至可能会出现一些混乱的局面,不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备,要有耐心。
   
坚持活学活用,以我为主
  机械照搬CMM的条文是在实施CMM时常犯的错误。在国内的软件企业中,都是从作坊式的软件组织逐步发展过来的,也没有经过软件工程化阶段,甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的,加上大家不愿从事管理,因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的,又没有真正的有实践经验的专家进行指导,所以对CMM的理解就不可能一下就很深刻,不敢裁剪CMM,容易机械照搬CMM条文,其实这恰恰违背了CMM的精神,CMM是软件工程经验的集大成,是从实践中总结出来,用以指导实践的,CMM本身也在更新版本,不断完善。每个企业都有自己的特点,就象微软的MSF,那是微软自己内部的管理过程标准,是微软的产品开发经验总结,有些内容是CMM中没有的,完全可以借鉴过来使用,所以只要可以提高企业自己的软件管理水平,就应该大胆地来尝试。

 

在推行CMM时,所以遇到的阻力,很大程度上是由于照搬CMM的条文,不切合项目组的实际,没有具体情况具体分析。实际上,一线的管理人员、开发人员最了解实际。谁了解实际,谁有发言权。所以在制定CMM规程标准时,尤其是在制定大家要执行的操作规程、模板和记录表样时,一定要得到执行者的认同,否则就容易造成执行和沟通的障碍,你硬要推,表面上看来似乎大伙也照规程做了,其实是表面文章,对改善没有实际帮助,以导致SPI工作受阻。
   
要改良式不要革命式
  以革命的方式来实施CMM,期望通过一场运动来解决过程能力的问题,一种可能是不懂CMM,不晓得管理的改进是循序渐进的,一种可能是明知故犯,期望在短期内通过CMM评估,单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM几级评估,我想恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去。一个企业引入CMM之后会从本质上影响企业的文化,改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥,你是可以依靠减肥药在短时间内减轻体重,但如果不从根本上改善饮食、生活、运动的习惯,那么体重将会在短时间内恢复到原来,我认为这个比喻是十分形象的。革命的方式与改良的方式我都曾经尝试过,效果差异很大。所以我总结一条就是让大家在"小步快跑"中接受变革,这样风险最小,效果最好。

CMM与企业的创新文化是不矛盾的
  软件企业的有些管理人员,也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新,他们认为在CMM中提倡的一种按部就班,什么活动都要做计划、按规程标准来做,对企业的创新文化会起负面作用。在我遇到的开发人员中,越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因:一是企业在推行CMM时,过分机械,没有从实际出发,不能与实践紧密结合,挫伤了开发人员的积极性。比如说在分析与设计阶段,需要开发人员能够发挥创意的成分更大一些,如果你要求他们一定就要按统一的文档标准来写文档,甚至字号大小、缩进格式一点也不能差,这的确很难做到,可能你需要在项目组配备文档支持人员,有他们来做这些完善工作,降低分析与设计人员的这些工作量。二是这类人员缺少真正的软件工程经验,做的大项目太少,经历的失败太少。关于这一点是不要争论的,CMM是软件工程经验与教训的集大成,我们无需再去重复那些失败。
  软件企业必须形成创新的文化,事实CMM本身也一种软件工程管理的创新,而技术创新是必须进行管理才能使其有效地转化为生产力,转化为企业的实际效益,达到效益最大化,这是最根本的。要勇于实践,也要允许犯错误CMM就是软件工程经验与教训的总结。在实施CMM的过程中,肯定会走些弯路,甚至于要犯错误,由此许多人会议论纷纷,一直会反映到高层经理处,这时不要犹豫,要敢于尝试,更不能因为有困难就打退堂鼓,现在大家都是"摸着石头过河",不下水,是没有办法过河的,临渊慕鱼不如退而结网。要少说不,少说难,勇于实践,有错就改。对于软件企业的领导尤其要注意这一点,不要因为在过程中的一些实践失败,就对项目经理、SEPG等人员有偏见,要提倡这种文化。
   
管理过程改进是组织内所有人的事情,而并非仅仅是SEPG的事情
  按照CMM专家的建议,在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%,根据这一建议,我们企业内一开始就配备专职的软件工程过程组(SEPG),这些员工专职负责企业的软件过程改善工作,另外我们根据需要组织一些技术任务组(TWG),他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况,可能会出现如下的问题:
  SEPG成了最忙的人,TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖,最后还是由SEPG的成员替代TWG做工作;
  企业的非开发人员对管理过程改进的效果一下没有明确地感受到,甚至看到由于加了些新的活动可能使项目拖期可能会更严重,于是他们可能就会将这些抱怨反馈到企业的高层经理,在推行过程中经常会听到:我这个项目时间太紧,当前不适合使用CMM
  高层经理迫于市场的压力,甚至可能会提出不合实际的项目工期等等。
  推行CMM不仅仅是管理人员的事情,每个人都要积极参与。要改变原来的一些做法:即SEPG是在使劲的推进CMM的工作,而不是大家自觉自愿的来实施CMM。从SEPG的角度来看,要做好培训的工作,首先要解决的大家的思想认识问题,这还是比较难的,有些人的思想还是比较顽固的。
  以上是我对前几年推行CMM的过程遇到的思想认识问题的总结,不一定准确,希望各位同行指正。当然管理首先要解决的是思想认识上的问题,不但在主观上要解决,在客观上也要有措施,光说不练是不行的,光练不说也是要否定的。我曾经遇到过类似的问题,有的开发人员或者项目经理在口头上是可以接受变革的,会配合工作的,但是在具体操作,很可能又会遇到事实上的否定,这时作为CMM的推广人员要尽快提出实施的具体措施,尽快落实。任何变革都要涉及到企业内的权利的再分配,不要忽视企业政治,这是客观存在的,所以一定要预防那些光说不练者。

7.4ISO9000CMM的比较
ISO9000CMMI的比较
 本文试图从大家所熟悉的ISO 9001标准入手,对ISO 9001ISO 900-3CMM之间的区别和联系做个简单的分析,探讨一些大家感到困惑的问题,包括:
1)
取得ISO 9000认证的组织大约相当于CMM的哪个等级?

2)取得CMM2(或第3)的组织是否可以认为满足ISO 9001要求?
3)取得ISO 9001证书与取得CMM相应等级证书的企业,谁的质量管理/质量保证水平/能力更高?
一、背景
ISO 9000族国际标准是在总结了英国的国家标准基础之上产生的,因此,欧洲通过ISO 9000认证的企业数量最多,约占全世界的一半以上。受此影响,相当多的欧洲软件企业选择了ISO 9001TickIT****ISO 9001)认证。CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)开发的软件成熟度模型,美国的软件企业更多的选择取得CMM等级证书。在形式上,CMM分为5个等级(第1级级别最低,第5级级别最高),与ISO 9000审核后只有通过不通过两个结论相比,CMM是一个动态的过程,企业在取得低级别证书后,可根据高级别的要求确定下一步改进的方向。在基本原理方面,ISO 9001CMM都十分关注软件产品质量和过程改进。尤其是ISO 9000:2000版标准增加持续改进、质量目标的量化等方面的要求后,在基本思路上和CMM更加接近。
 本文参考了Mark C. Paulk先生的 HOW ISO 9001 COMPARES WITH THE CMM,但观点不尽相同。
 ISO 9001是软件企业开展质量体系认证依据的标准;
 ISO 9000-3是国际标准化组织(ISO)制定的软件开发企业实施ISO 9001指南;
④ TickIT认证是一个基于ISO 9001的、专门针对软件开发企业的认证制度,与取得非TiclITISO 9001)认证相比,TickIT对审核员的专业要求更高, TickITISO 9001)证书在业界更有权威性

★CMMI认证★CCRC认证★ITSS认证★CS认证★DCMM认证★DSMM认证★两化融合认证★重庆CMMI认证★重庆CCRC认证★重庆ISO27001认证★重庆ITSS认证★重庆CS认证★重庆GJB5000A认证★重庆两化融合认证★

公司地址:成都市高新区天府三街218号1-10-8  备案号:渝ICP备19005035号