CMM/CMMI是什么？

1. CMM/CMMI是什么？

2. 怎么查询已经通过“cmmi认证”的企业名单？

可以通过官网：https://sas.cmmiinstitute.com/pars/pars.aspx进行查看。
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型），是美国国防部的一个设想。
1994年由美国国防部与卡内基-梅隆大学下的软件工程研究中心以及美国国防工业协会共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
CMMI的成功促使其他学科也相继开发类似的过程改进模型，例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等，从CMM衍生出了一些改善模型，比如：SW－CMM,SE-CMM,IPD-CMM等。
不过，在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。CMMI就是为了解决怎么保持这些模式之间的协调。
CMMI 1.3是2010年11月SEI 发布的CMMI模型的最新版本。CMMI 1.3包括CMMI采购模型1.3版、CMMI开发模型1.3版、CMMI服务模型1.3版。

3. 哪些软件企业通过cmm/cmmi的认证

通过的软件几页太多了，稍微大一点的企业需要去投标的都要去，比如深圳这边的深圳市云迅通科技股份有限公司、深圳市讯方技术股份有限公司、平方科技等

4. cmm3与cmmi3的区别是什么呢 有的公司说自己通过了cmm3 有的是cmmi3

以前各公司过的是CMM等级，现在一般过CMMI的等级；i是集成的意思，数字是等级划分。3就是3级。
    CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software；
    CMMI 是指“能力成熟度模型集成”，全称为：Capability Maturity Model Integration；CMMI认证是由美国软件工程学会(software engineering institue,简称SEI)制定的一套专门针对软件产品的质量管理和质量保证标准。CMMI是CMM模型的最新版本。
建议你多查点相关知识看看。

5. 中国有哪几家企业通过cmm5认证？？

2004年是5家，分别是：   
  华为、东软、大连华信、新宇科技、用友软件   
大连不只三家：   
  CMMI5：东软软件股份有限公司大连分公司     
  CMM5：   东软软件股份有限公司大连分公司     
                  大连海辉科技股份有限公司     
                  大连华信计算机技术有限公司     
                  大连现代高技术发展有限公司     
  总数也不只是5家   
    
  此外的两家应该是：   
  华为和新宇科技

6. CMMI和CMM的关系

CMM和CMMI的联系及区别: 
      联系:

      CMMI即CMM集成，是系统工程和软件工程的集成成熟度模型，CMMI更适合于信息系统集成企业。CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。

      区别:

      从等级划分上看,1,3,5级的名称没有变化,均是初始级,已定义和优化;但是2级和4级分别定义为已管理级和定量管理级,这个变化更突出了CMMI定性管理和定量管理的特点.

      CMMI共有分属于4个类别的25个过程哉,覆盖了4个不同的领域;相对应的CMM共有18个过程域.

    CMM基本活动的度量方法和瀑布过程的有次序的,基本活动的管理规范有非常密切的联系,更适合瀑布型的开发过程;而CMMI相对CMM更一步支持迭代开发过程和经济动机推动组织采用基于结果的方法:开发业务安全,构想和原型方案,细化后纳入基线结构,可用发布,最后确定为现场版本的发布.

      CMMI比CMM进一步强化了对需求的重视.在CMM中,关于需求只有需求管理这一个KPA,也就是说强调对有质量的需求进行管理,而如何获取需求则没有提出明确的要求;在CMMI中,3级有一个独立的KPA叫做需求开发,提出了对如何获取优秀的需求的要求和方法.

    CMMI对工程活动进行了一定的强化.在CMM中只有3级中的软件产品工程和同行评审两个KPA是与工程过程密切相关的;而在CMMI中,则将需求开发,验证,确认,技术解决方案产品集成这些工程过程活动都作为单独的KPA进行了要.

      CMMI3级中单独强调了风险管理,而在CMM中把风险的管理分散在项目计划,项目跟踪与监控中进行要求.

      从评估方法上看,随着CMM过渡到CMMI,其CAF(CMM,Assessment Frame-work)框架变成评估需求(ARC:appraisal requirements for CMMI);IPI-CBA 的评估方法 被 SCAMPI方法替代.

7. cmm与cmmi的区别

1、作用不同
CMM是一种对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述形成的标准。
CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD），SEI在部分国家和地区开始推广和试用。
2、特点不同
CMM是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMMI是由美国卡耐基梅隆大学软件工程研究所组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。

3、功能不同
CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM模型主要用于软件过程的改进，促进软件企业软件能力成熟度的提高，但它对于系统工程、集成化产品和过程开发、供应商管理等领域的过程改进都存在缺陷，因而人们不得不分别开发软件以外其他学科的类似模型。
参考资料来源：百度百科-CMMI
参考资料来源：百度百科-CMM

8. 实施CMM/CMMI时必须解决的认识问题

　　在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显著，CMU SEI提出了软件过程能力成熟度模型（CMM/CMMI）基于过程的角度来解决软件危机。那么是否实施了CMM/CMMI，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。
　　在开始实施CMM/CMMI时，最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMM/CMMI无法解决的。
　　管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心
　　在实施CMM/CMMI时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。
　　任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。
　　坚持活学活用，以我为主
　　机械照搬CMM/CMMI的条文是在实施CMM/CMMI时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过软件工程化阶段，甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMM/CMMI的理解就不可能一下就很深刻，不敢裁剪CMM/CMMI，容易机械照搬CMM/CMMI条文，其实这恰恰违背了CMM/CMMI的精神，CMM/CMMI是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM/CMMI本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMM/CMMI中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。
　　在推行CMM/CMMI时，所以遇到的阻力，很大程度上是由于照搬CMM/CMMI的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMM/CMMI规程标准时，尤其是在制定大家要执行的操作规程、模板和记录表样时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，以导致SPI工作受阻。
　　要改良式不要革命式
　　以革命的方式来实施CMM/CMMI，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMM/CMMI，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMM/CMMI评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM/CMMI几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去。一个企业引入CMM/CMMI之后会从本质上影响企业的文化，改变大家的思想与做事方法。有人曾形象得将过程改进比喻为减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复到原来，我认为这个比喻是十分形象的。
　　革命的方式与改良的方式我都曾经尝试过，效果差异很大。所以我总结一条就是让大家在"小步快跑"中接受变革，这样风险最小，效果最好。
　　CMM/CMMI与企业的创新文化是不矛盾的
　　软件企业的有些管理人员，也包括一些开发人员往往抱怨或认为严格的管理会束缚他们的创新，他们认为在CMM/CMMI中提倡的一种按部就班，什么活动都要做计划、按规程标准来做，对企业的创新文化会起负面作用。在我遇到的开发人员中，越是技术钻研越深的人持这种观点的越多。我想形成这种观点主要有二个原因：一是企业在推行CMM/CMMI时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如说在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果你要求他们一定就要按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能你需要在项目组配备文档支持人员，有他们来做这些完善工作，降低分析与设计人员的这些工作量。二是这类人员缺少真正的软件工程经验，做的大项目太少，经历的失败太少。关于这一点是不要争论的，CMM/CMMI是软件工程经验与教训的集大成，我们无需再去重复那些失败。
　　软件企业必须形成创新的文化，事实CMM/CMMI本身也一种软件工程管理的创新，而技术创新是必须进行管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。
　　要勇于实践，也要允许犯错误
　　CMM/CMMI就是软件工程经验与教训的总结。在实施CMM/CMMI的过程中，肯定会走些弯路，甚至于要犯错误，由此许多人会议论纷纷，一直会反映到高层经理处，这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，现在大家都是"摸着石头过河"，不下水，是没有办法过河的，临渊慕鱼不如退而结网。要少说不，少说难，勇于实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、SEPG等人员有偏见，要提倡这种文化。
　　管理过程改进是组织内所有人的事情，而并非仅仅是SEPG的事情
　　按照CMM/CMMI专家的建议，在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%，根据这一建议，我们企业内一开始就配备专职的软件工程过程组（SEPG），这些员工专职负责企业的软件过程改善工作，另外我们根据需要组织一些技术任务组（TWG），他们会兼职的参与特定过程规程、标准的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题：
　　SEPG成了最忙的人，TWG的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由SEPG的成员替代TWG做工作；