CMMCapability Maturity Model　 是能力，成熟度模型的缩写。CMM的工作最早开始于 1986年11月，当时为了满足美国联邦政府评估软件供应商能力的要求，美国卡内基·梅隆大学的软件工程研究院Sei　牵头，在Mitre公司的协助下，于1987年9月发布了一份能力成熟度框架Capability Maturity fraMework　以及一套成熟度问卷 Maturity QueStionnaire　．很多人认为这套问卷就代表了CMM模型，其实它只是用于探索软件过程成熟度的一个工具，真正的模型出现在四年以后。Sei总结了自1987年以来对成熟度框架和初版成熟度问卷的实战经验，并以此为基础，推出了CMM1．0 版。这个推出于 1991年的 CMM1．0 集中了四年来对软件公司评估的经验以及广泛的用户反馈，在成熟度框架的基础上建立了一个可用的模型，这个模型可以更加有效地帮助软件企业建立和实施过程改进计划。

CMM1．0 版使用两年之后，于1992年四月进行了一个研讨会，参加研讨会的有约两百名富有经验的软件专业人员。在广泛听取了他们的反馈意见之后，Sei于 1993 年推出了CMM1．1 版。近几年来，CMM又推出了2．0 版本，同时进入了iSo 体系，称为 iSo／ieC15504 或 SpiCe． SpiCe从1995年起进入实地测试阶段，可能于2001年发布 。

CMM 致力于软件开发过程的管理及工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用同时正在被越来越多的欧洲和亚洲等国家的大型信息技术企业所采纳，实际上已成为软件开发过程改进与评估的事实上的工业标准。

印度是软件大国，十分重视软件开发过程的管理及与其相关的理论与标准的发展。据统计，在印度的2000多家软件公司中有75家软件公司通过了iSo9000认证，60多家软件公司通过了CMM认证，其中达到CMM5级一家，4级三家，3级4家。

CMM与iSo9000的区别主要有以下几点：CMM是专门针对软件产品开发及服务的，而iSo9000则有宽得多的范围；CMM强调软件开发过程的成熟度，即过程的不断改进和提高，而iSo9000则仅描述可接收的质量体系的最低标准；CMM3级的覆盖范围要大于iSo9000的覆盖范围。

引进CMM的意义有两个方面

1．对软件企业：

提高软件开发的管理能力：CMM提供了软件企业自我评估的方法和自我提高的手段；提高软件生产率；加强软件生产的国际竞争力。

2．对软件项目发包单位和软件用户：

提供了对软件开发商开发管理水平的评估手段，有助于软件开发项目的风险识别。

CMMI（ Capability Maturity Model Integration）的本質是軟件管理工程的一個部分。軟件過程改善是當前軟件管理工程的核心問題， 50多年來計算的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。基於模型的過程改進是指用採用能力模型來指導組織的過程改進，使之過程能力穩定的進行改善，該組織也能變得更加成熟。

然而，軟件組織形成一套完整而成熟的軟件過程不是一蹴而就的事情，需要經歷一系列的成熟度。軟件組織首先要進行差異分析，評定自己比較接近哪一個成熟度，然後再根據自身的情況來決定要採取哪些改進活動，來更有效地改進自己的軟件過程。這就對軟件過程的評定提出了一個客觀的標準。美國卡內基梅隆大學軟件工程學院於1987年研究成功的SW-CMM（Capability Maturity Model for Software）就是這樣的一個理論模型，其目的在於幫助軟件組織改善軟件生產流程，以探索一個保證軟件產品質量、縮短開發週期、提高工作效率的軟件工程模式與標準規範。

CMMI是一個可以改進系統工程和軟件工程的整合模式。1997年10月SEI停止對CMM的研究，改而致力於CMMI，以解決使用多個過程改進模型的問題。SEI同時宣佈CMMI將取代CMM，與2000年8月11日頒布了CMMI-SE/SW 1.0版本，2001年12月頒布了1.1版本，這次發佈標誌著CMMI正式啟用,並準備今年內完成CMM到CMMI的過渡。

CMMI 全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。CMMI可以解决现有不同CMM模型的重复性、复杂性，并减少由此引起的成本、缩短改进过程，它将软件CMM2.0版草案（SW-CWW）、EIA过渡标准731（系统工程CMM）及IPD-CMM集成为一体，同时还与 ISO15504相兼容。 CMMI是有效过程元素的集合，目前有如下模型： 
CMMI是有效过程元素的集合，目前有如下模型：
CMMI-SE/SW/IPPD/SS,V1.1
CMMI-SE/SW/IPPD V1.1
CMMI-SE/SW V1.1
CMMI-SW V1.1 

CMMI自推出以来，在世界各地得到了广泛的推广与接受。在日本、欧洲、台湾、印度等地都有很多企业在推广与应用CMMI模型。尤其在印度CMMI的应用甚至超过了美国。

CMMI阶段式的基本结构从CMM演变而来，但是CMMI的结构更加的形式化和精致，也更加的复杂，尤其为了保证连续式和阶段式的同一性，更加增加了结构的理解难度。

CMMI强调了对需求的管理，有两个过程域说明对需求的控制：需求管理REQM、需求开发RD。而在CMM中只有一个关键过程域需求管理RM以及软件产品工程SPE中的一个实践来说明对需求的管理和控制。

CMMI加强了对工程过程的重视，提供了更加细致的要求和指导，而CMM中却只有一个SPE关键过程来进行要求和指导CMMI强调了度量，并且从项目的早期就已经进行了度量，在阶段式中CMMI二级由一个过程域度量和分析；而在CMM中没有专门的要求和指导。

CMMI对比CMM更加强调了对风险的管理，在CMM中风险只“是项目策划”SPP中的一个活动，而在CMMI中风险管理作为一个单独的过程域。　

CMM：
CMM作为较早推出的软件过程改进标准，目前已在世界范围被广泛地推广和应用。不可否认，CMM在建立有效的开发系统、控制软件产品开发过程式、降低软件企业内外部故障成本、提高企业的经济效益和社会效益等方面，取得了巨大成功。

但CMM也存在着一些不足，如CMM中的一个关键过程域“组间协调”IC在CMMI中地位下降，只是作为“集成化项目管理”IPM中的一个目标。

CMM中的关键过程域“同行评审”PR，在CMMI中得到了更高的抽象；对应CMMI的“验证”VER，说明了对产品进行相应的QC活动。（同行评审本身就是一种QC活动）。

CMMI的公共特性中，没有了测量（ME），这些度量内容被组织起来形成了一个支持过程“度量和分析”。具体理由如下：
度量和分析本身应用的复杂性和它执行的高成本在原来的CMM中每个KPA均有单独的测量要求，容易造成“过度测量”，也没有形成对组织级的、统一的度量体系的指导和要求，造成实施中的困难。例如在CMM中如果一个组织达到了CMM三级，由于各个KPA均要求了测量（ME），实际上已经建立了全组织过程的测量，这和CMM的等级划分思想是有着冲突的。

总结：
CMMI改进了这个方面，要求组织从组织级的统一要求出发建立度量体系。这样的想法也符合过程改进理论的思想；这样组织在实施过程中可以选择必要的过程进行测量，而不是全部过程的测量，从这个意义上，CMMI对比CMM降低了对度量的要求和实施难度，但是更加具有全局性和可实施性。

CMM是作为评估标准出现的，所以是“必要”的才能保证评估的标准。

CMMI是作为改进模型出现的，罗列了较多的最佳实践，利于过程的改进。