基于组织对关键过程域的支持，CMM定义了软件过程成熟度的五个级别。级别1（初始级）描述了不成熟，或者说是未定义的过程的组织。级别2（可重复级），级别3（已定义级），级别4（已管理级）和级别5（优化级）分别描述了软件过程成熟度级别递增的组织。和这些级别相关的KPA是：

　　级别2：需求管理，软件项目计划，软件项目跟踪和监控，软件子合同管理，软件质量保证，软件配置管理。

　　级别3：组织级过程焦点，组织级过程定义，培训大纲，集成软件管理，软件产品工程，组间协调，同行评审。

　　级别4：定量过程管理，软件质量管理

　　级别5：缺陷预防，技术更新管理，过程更改管理

　　多数组织的基本目标是达到成熟度3级。评估组织当前的成熟度级别的手段之一是软件能力评估（SCE）。SCE通过评估软件过程（一般以方针陈述的形式）和项目实践来确定该组织是否言行一致。组织的过程体现了"如实记录所做的工作"，项目实施（对该过程的特定剪裁和解释）应该证明"说到做到"。

CMMI 综述

　　软件成熟度模型（CMM v1.0）最早是软件工程学院开发的，并特别提出软件过程成熟度。1990年，该模型首次发布，在许多领域被成功地采纳和使用。其他学科的CMM也相继开发，例如系统工程、人员、集成产品开发、软件采购等等。

　　CMMI被看做是把各种CMM集成为一个系列的模型中。CMMI的基础源模型包括：软件CMM 2.0版（草稿C）, EIA－731系统工程，以及IPD CMM (IPD) 0.98a版。CMMI也描述了5个不同的成熟度级别。

　　 1. 级别1（初始级）代表了以不可预测结果为特征的过程成熟度。过程包括了一些特别的方法、符号、工作和反应管理，成功主要取决于团队的技能。

　　 2. 级别2（已管理级）代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理、以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。

　　3. 级别3（严格定义级）代表了以组织内改进项目执行为特征的过程成熟度。

　　强调级别2的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。附加的组织级过程域包括：
　　需求开发：多利益相关者的需求发展。
　　技术方案：展开的设计和质量工程。
　　产品集成：持续集成、接口控制、变更控制。
　　验证：保证产品正确建立的评估技术。
　　确认：保证建立正确的产品的评估技术。
　　风险管理：检测、优先级，相关问题和意外的解决方案。
　　组织级培训：建立机制，培养更多熟练人员。
　　组织级过程焦点：为项目过程定义建立组织级框架。
　　决策分析和方案：系统的可选的评估。
　　组织级过程定义：把过程看做组织的持久的发展的资产。
　　集成项目管理：在项目内统一各个组和利益相关者。

　　4. 级别4（定量管理级）代表了以改进组织性能为特征的过程成熟度。3级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。级别4附加的过程域包括：

　　组织级过程执行：为过程执行设定规范和基准。
　　定量的项目管理：以统计质量控制方法为基础实施项目。

　　5. 级别5（优化级）代表了以可快速进行重新配置的组织性能，和定量的、持续的过程改进为特征的过程成熟度。附加的级别5过程域包括：

　　因果分析和解决方案：主动避免错误和强化最佳实践。

　　组织级改革和实施：建立一个能够有机地适应和改进的学习组织。

CMM过时了吗？

　　一些CMM实践的问题也是传统瀑布方法和过度基于过程的管理的症状。CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系（即：先是需求活动，然后是设计活动，编码活动，单位测试活动，集成活动，以及系统接收测试）。这大概可以解释为什么许多组织对CMM的认识停留在瀑布思想上。

　　另外，叠代开发技术、软件产业最佳实践、和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。

　　分析CMM 和 CMMI分别和瀑布模型以及叠代开发之间有什么联系，方法之一就是看每个模型的KPA是否为这两种不同的开发方法激发了合理的软件管理原理。首先，让我们来定义那些软件管理原理。过去10年间，我编译了两套原理：一套用于传统的瀑布方法，另一套用于现代的叠代方法。得承认的是，这"十大原理"没有科学基础，并且只提供了符合它们各自的管理方法的成功模版的粗略的描述。但是它们的确为我的观点提供了一个合适的框架：CMM和瀑布思想相联系，而CMMI和叠代思想联系得更紧密。

　　1. 设计之前冻结需求。这是需求第一过程的本质：项目组努力提供一个准确的需求定义，然后严格按照需求实施。需求变更会严重破坏编码和测试阶段，因此，项目组在其他设计和开发活动中投入主要力量之前，必需完整地、明确地指定需求。

　　2. 详细设计评审前避免编码。编码变更会严重破坏编码和测试阶段，在开始编码前，如果还有很多变更阻力，项目组必需保证整个设计是成熟和完整的。

　　3. 是使用更高指令编程语言。更高指令编程语言避免了一系列主要的错误根源（通过先进的数据录入、接口分离以及打包和编程结构），并允许软件方案可以使用更少的人工合成码进行编程。

　　4. 集成前要结束单元测试。虽然设计是自上向下的，测试过程是自下向上的：在交付进行集成测试之前，最小的单元先进行全面测试。这样的次序限制是为了在集成前多发现一些单元级别上的缺陷，否则它们将造成更多的问题和返工。

　　5. 维护所有产品可跟踪性。为了保证在每个阶段维护项目的完整性和一致性，要跟踪需求产品以及设计和测试产品。当提出变更或开发一线人员识别变更时，这提供了变更对评审的实际影响和潜在影响的完整视图。

　　6. 文档化并维护设计。没有文档化的设计就不是设计了。在以后的阶段，由于代码成为主要的工程产品，必须更新设计产品以保证一致性，并为变更决策提供基础。

　　7. 由一个独立小组评估质量。项目组应指定一个独立小组负责保证产品和过程的全面质量一致性，以维护一个有别于分析人员、设计人员和检测人员的独立的报告渠道。

　　8. 全面检查。通过检查详细设计和代码来发现错误，比通过测试发现错误要好得多。要确保检查覆盖所有需求、设计、代码和测试产品。

　　9. 在项目早期进行全面的精确的计划。对于识别关键路径、管理风险以及评估程序变更来说，一个完整的、精确的、细化的计划是必要的，它应该安排整个进度的详细活动和产品。

　　10. 严格控制源代码基线。一旦产品进入编码阶段，就必须用严格的配置管理维护测试过程的正式发布的基线控制，并把产品转换成适合发布的零缺陷状态。

现代（叠代）软件管理的十大原理

　　1. 首先注重结构过程。这要求在组织承诺全面开发的充足资源之前，平衡操作需求、对结构而言很重要的设计决策、以及生命周期计划。

　　2. 用叠代生命周期在早期防御风险。需要一个叠代过程来更好地理解问题，形成有效的方案和有效的计划，以保证平衡对待所有利益相关者目标。应在早期提出主要的风险以提高可预测性，避免为随后的问题和返工付出大的代价。

　　3. 强调基于构件的开发。为了减少人工合成源代码和习惯开发的数量，项目组必须在现存的结构框架内从代码行思想转移到基于构件的思想。构件是已经存在的代码行的附着部分，有已定义的接口和行为，存在于源代码中或可执行格式中。

　　4. 建立变更管理环境。叠代开发的动力学包括并发的工作流，因为不同的工作组都为共享产品工作。这需要客观控制的基线供所有项目成员参阅。

　　5. 用循环工程工具使变更更自由。循环工程提供了各种不同格式（如：需求说明书、设计模型、源代码和可执行代码）的自动工程和同步工程信息所必需的环境支持。如果不使用实质的自动操作，把叠代周期简化为可管理的，允许并鼓励变更的时间框架是很困难的。叠代过程中产品变更自由是必需的，因为它清除了工程组摩擦的一个主要来源。

　　6. 使用严格的、基于模型的设计符号。基于模型的方法（例如：UML）支持语意丰富的图形和文本的设计符号。相对于传统的人工评审和纸张文档的特定设计表现的检查，带严格符号和正式的、机器处理语言的可视模型允许更客观的评估。

　　7. 提供过程的客观质量控制的手段。过程和所有中间产品的生命周期评估必须紧密集成到产品中去，把从展开的工程产品中直接获得的、定义好的度量集成到所有活动和小组中去。

　　8. 使用中间产品的基于演示的评估。把目前的产品状态的产品（不论是早期原型，基线结构，还是β能力）转换成相关的使用案例的可执行演示，以促进集成转换更早发生，对设计权衡的更切实的理解，以及更早消除产品缺陷。

　　9. 发布细化的、展开的计划。在系统的操作语境中，软件管理过程的早期的持续的演示是至关重要的，也就是它的使用案例。每个项目的增加和演示都应该反应目前需求和结构的详细水平。使用案例是组织需求、定义叠代内容、评估实施和组织接收测试的重要机制。

　　10. 建立一个可升级的、可配置的过程。没有哪个过程是适合所有软件开发项目的。现实的说，一个过程框架必须是可配置的，适合大范围的应用软件。为保证经济级别和投资回报，组织必须灌输一个通用过程"精神"，这样所有项目都能集成一系列通用的最好实践，尤其是项目管理、独立于语境的工作流、检查点、度量和产品的最好实践。还应允许各个项目进行剪裁和指定，以便针对项目特定的语境优化过程实施。

　　CMM和两套管理原则的关系 表1识别出每套原则中各有哪些是直接由 CMM的KPA激发的。这些都是我的判断，结合了Rational公司许多同事的观点，但并没有科学依据。另外，请记住这些原则不仅基于CMM，还基于对默认实践的观察和组织级的惯性。