首先介绍一下CMM和CMMI。软件能力成熟度模型（Capability Maturity Model, CMM）是美国卡内基梅隆大学软件工程研究生（SEI）汇集了世界各地软件过程管理者的经验和智慧而产生的软件过程改进的指导性模型。该模型经过世界各地软件组织的实际应用，证明其对软件过程改进具有建设性作用。
自1991年起，CMM标准陆续发展应用于许多专业领域，形成了包含系统工程、软件工程、软件采购及整合的产品与流程发展（Integrated Process & Product Development, IPPD）等在内的多个模型。虽然这些模型已经在许多企业被认可，然而使用多个模型本身也是有问题的。许多组织想要将它们的改善成果扩展到组织中的其他模块中去，然而每个模块使用的特定专业领域模型的差异（包含架构、内容与方法），在很大程度上限制了这些组织改进成功的能力。此外，训练、评鉴和改善活动的成本是昂贵的。CMMI的出现就是为了解上述使用多种能力成熟度模型的问题。
之所以需要CMM和CMMI，主要是为了更好的开展软件过程管理。我们需要积累相关活动的经验教训，形成了若干可以参考的模型和方法，这其中最著名的软件过程管理参考模型之一可能就是能力成熟度模型CMM以及其后续的集成模型CMMI。该模型在实践当中被误解和曲解的若干场景有很多。
首先需要注意，CMM/CMMI并不是一种具体的软件过程或者软件开发方法。在不少文献中，CMM/CMMI都被视作一种官僚化和教条主义的重型软件过程，并且与当前软件开发大环境格格不入。事实上，按照CMM/CMMI模型的要求，一个软件组织应当定义适应本软件组织特点的软件过程，并且不断优化该过程，来更好的实现软件组织的商业目标。然而，实践中，软件组织往往为了迎合基于CMM/CMMI模型的“证据验证（verification）”评估方法，可以准备大量文档化证据，导致CMM/CMMI被视作必须在软件项目管理中必须满足的某种标准（这一点类似于几乎所有的ISO系列标准的贯标审核）。显然，这是对CMM/CMMI模型意图和使用方法的曲解。
其次，CMM/CMMI 并不能作为检验软件过程优劣的标准。实践中，很多人会将达到一定成熟度水平视作某个软件组织的研发能力，并且试图进行横向比较，认为成熟度较高的企业，其研发能力应该强于成熟度较低的企业。Leon J. Osterweil 那篇影响极大的论文中也将 CMM/CMMI 视作是检验过程优劣的标准。而事实上，由于企业所处的环境以及要实现的目标等方面的差异，过程改进对于不同企业的含义是不一样的。因此，成熟度等级不适宜脱离企业环境直接横向比较，同处于相同的成熟度等级，也并不能说明这些企业的研发能力也是相同的。
最后，将 CMM/CMMI 与其他软件过程或者软件开发方法的比较是没有任何意义的。很多人习惯于将CMM/CMMI 作为敏捷方法的对立面，试图来解释和说明敏捷方法的优势。事实上，这种语境之下所谓的“CMM/CMMI 方法”其实已经不是一个过程管理的参考模型了，而是某个特定软件组织为了迎合或者满足 CMM/CMMI 评估的需要所定义出来的某个具体软件过程。显然，将这个为了特定目的而定义出来的软件过程的缺点视作 CMM/CMMI 模型的缺点是不合适的。
成功使用CMMI最佳实践也存在挑战。没有发展方法或方法可以有效地解决所有困难的挑战或情况[Elm 2007]。仅仅因为某个组织已经在特定的CMMI成熟度级别进行评估并不能保证组织中的特定项目将成功。但是，组织使用CMMI可能会失败（有些失败！）因为他们滥用模型或追求流程改进以及随后的误导动机或不谨慎的领导评估。
有时，在急于达到成熟度的同时，注重提高组织绩效迷路了。可能会施加错误的标准流程和裁剪指南。例如，标准流程可能过度指定，从而过度约束项目而不利于项目成功。
剪裁指南可能不允许项目具有定制标准所需的灵活性解决项目特定需求和优先事项的过程[Charette 2004]。特别是这些指南可能不允许有效解决困难项目所需的过程灵巧性挑战和风险。找到更有效地解决风险（和机会）的方法之一就是其中之一开发产品开发的迭代和螺旋方法的主要动机 - 和最近的敏捷方法。在当今日益动态的世界中，基于CMMI组织过程改进方法不能完全依赖传统方法项目管理方法，基于瀑布的项目生命周期和重量级分析方法。
相反，标准流程可能未明确规定，并且省略了经过验证的组织和流程项目实践。同样，标准流程的定义可能倾向于处理所有CMMI实践同等（获得成熟度）并且不承认某些特定实践是至关重要的对业务。适当关注这些做法可能会增加直接价值，但这些做法可能会在收费到成熟度等级的噪音中迷失。
许多人太快通过判断，宣布胜利或宣布失败。他们期待即时结果并经常假设这些结果将无限期地持续存在。第一个项目使用敏捷或CMMI必须是成功的，或者新尝试的方法被标记为失败;同样，一个成功就是假设代表组织层面的制度化模式。现实是，两者都不是一般情况下。
“不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程。”CMM/CMMI的周期是螺旋模型；核心是过程改进；范围是需求严格而极少变化的项目；组织是个人（PSP）、团队（TSP）和组织的3个层次，组间协作、培训；技术是传统结构化方法；管理是侧重于过程的定义、度量和改进。一切用数字和文档说话；活动是通过过程域来定义活动；实践是各类级别的关键实践，重视关键基础设施。虽然CMM/CMMI的通用性比较强，但是它非常复杂，成本比较高，而在当前软件开发过程中，更倾向于一些简单、性价比高的软件过程模型。
有句话：所有模型都是错的（它一定是对某些现实世界的抽象，但并不适用于所有现实），但有一些模型是有用的。到20世纪80年代，全球最大的软件开发服务采购商美国国防部无法按时，按预算和正确的规格完成项目。尽管与一些最好的和最知名的软件开发公司合作，它仍然有近50/50的机会让项目正确。担心其表现，它与卡内基梅隆大学，软件工程学院一起资助。该研究所的任务是编制一套软件开发最佳实践，这些实践可以提供衡量当前供应商的基准，以及当前供应商为改进其软件工程实践而应遵循的具体指导。
该计划最终催生了能力成熟度模型集成（CMMI）及其1到5的级别。能力成熟度模型将公司划分为级别，从级别1（在未管理的流程或广告下运营）开始-hoc）到那些达到5级（优化）的人。我们的目的不是要详细了解每个级别的含义，除非指出在第5级公司必须遵守超过16个软件和系统开发过程领域的原则，包括能力（在级别上）;管理他们的软件开发过程（配置管理，项目监控和控制，项目规划，需求管理）;定义他们的软件开发方法（决策分析和解决方案，组织培训，风险管理，验证，验证）;定量管理他们的开发过程（衡量组织过程绩效，可靠地衡量生产率，错误注入和其他关键变量）并优化他们的过程，包括不断审查过程问题的原因并采取措施改进和解决它们。国防部需求的性质影响了CMMI的核心。国防部的软件开发项目往往很大，并且经常与硬件交互。
实质上，在CMMI和RUP下宣称为“最佳实践”的软件开发方法确实在代码质量方面产生了显着的提高。然而，这在以下方面都付出了巨大的代价：
a）时间（时间更可预测，但形式显着增加了软件开发的长度与ad-hoc编程）；
b）功能相关性（严格的流程不允许应用程序轻松适应业务环境的变化，因此随后的应用程序通常是“客户要求的但不是客户需要的”）；
c）成本令人沮丧（随后的申请并不便宜，因为该流程的所有形式都有行政管理费用，而且申请的预计成本仍然与最初的“固定价格”估算不匹配，估计相对于临时估计而言，其数量较少，但仍然显着偏离）。
故我们可以看到，尽管CMM/CMMI是一个比较优秀的软件过程管理参考模型，但是由于其复杂度、时间、功能相关性、成本等方面还有很多不足与欠缺。我们需要的软件开发模型要能清晰、直观地表达软件开发全过程，明确规定要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件开发工具和不同的软件工程环境。
综合考虑，CMM/CMMI的性价比不是非常高，不适用于普遍的软件开发当中。
参考文献：
软件组织与管理方法综述——荣国平, 张贺, 邵栋, 王青
CMMI or Agile: Why Not Embrace Both!——Hillel Glazer, Entinex, Inc.,Jeff Dalton, Broadsword Solutions Corporation,David Anderson, David J. Anderson & Associates, Inc.,Mike Konrad, SEI,Sandy Shrum, SEI
Traditional software engineering, CMMi and its problems——PSL Corp