软件研发 CMMI 探密
1． 初识 cmmi
2． CMMI 一级—初始级
3． CMMI 二级
4． CMMI 三级
5． CMMI 四级
6． CMMI 五级
7． CMMI 与 ISO 的区别和联系
8． CMMI 在项目中软件研发实际应用
一、初始 CMMI
CMMI 是由卡内基梅隆大学软件工程学院（Software Engineering Institute，简称 SEI）1984 年受美国国防部要求开始研究在软件产业建立一
套工程制度，用来评估和改善软件开发公司的过程和能力，并协助软件开发人员持续改善流程的成熟度以及软件质量，从而提升软件开发项目
及公司的管理能力，最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。
1986 年正式开始研究 CMM 能力成熟度模型（Capability Maturity Model，简称 CMM），于 1991 年正式推出了软件能力成熟度模型（Capability
Maturity Model For Software，简称 SW-CMM）,两年后 1993 年正式推出 。后来又根据 在各个行业领域发展成了 CMMs，
其中包括系统工程能力成熟度模型（Systems Engineering Capability Maturity Model, SE-CMM）、整合产品发展能力成熟度模型（Integrated Product
Development Capability Maturity Model, IPD-CMM）、人力资源管理能力成熟度模式 （People Capability Maturity Model, P-CMM）等应用模型。
由于各行业架构的不同，SEI 于 2000 年 12 月公布了能力成熟度整合模型（Capability Maturity Model - Integrated, CMMI）对此进行整合。后
来经过不断改进，就形成了今天的 , 版本。
CMMI 相关基本概念：CMMI-Capability Maturity Module Integration（软件过程能力成熟度集成模型），是将原来的 CMM-SW/SE 等等整合
为一个模型，目前使用的版本叫 CMMI-DEV（Development）。模型有两种表示方法：连续型与阶段型，国内一般说的几级几级指的是阶段
型表示法。
CMMI 模型包含项目管理类、过程管理类、工程类、支持类四大领域，包含 22 个 PA（Process Area 过程域）。每个 PA 包括有特定目标
（SG）特定实践（SP）及各 PA 所共同包括的通用目标（GG）通用实践（GP）。SEI-Software Engineering Institute（卡耐基梅陇大学软件工程
研究所）
SCAMPI-Standard CMMI Appraisal Method for Process Improvement 是一种评估的方法，一般分为 ClassA/B/C 三种级别。
二．CMMI 一级-初始级
初始级是原始的方式，类似手工作坊式生产。没有项目的相关规则，项目成员工作主要凭个人能力和习惯，一般项目中也极少有关于
过程方面的规定，不论采用什么方法、遵循什么样的开发步骤，最后只要把代码写出来了就可以了，软件开发的主要活动就是编码和调试。很
少有项目计划，顶多有个项目时间表，需求、设计等工程文档也很少有。
三.CMMI 二级-受管理级
二级主要定义了 7 个过程域（PA）来指导软件项目开展：
1、 项目计划(PP- Project Planning):实际上就是建立 PMP 及生命周期模型。
PP 中主要有三个特定目标(SG-Specific Goals)：
1)、SG1 Establish Estimates 项目估算—主要包括对项目的范围、属性、生存周期、工作量和成本四个 SP
2)、SG2 Develop a Project Plan 制定项目计划—主要有编制预算和进度,识别风险，项目数据的管理计划，规划项目资源，知识和
技能的计划，“项目干系人”的介入计划，制定项目计划等 SP。
3)、SG3 Obtain Commitment to the Plan 获得对计划的承诺
主要 SP 有: 审查从属计划, 协调工作与资源配置, 获得计划承诺等
2、 项目计划跟踪与控制(PMC- Project Monitoring and Control):项目 PMP 及变更控制等。
3、需求管理(RM)：需求跟踪及变更控制。
4、供应商协议管理(SAM)：供应商选择标准、评估、评价等。
5、度量(MA),初级的度量，感知级：本身是 CMM L4 及的要求，他应该和 CMMI :L4 中的 QPM 联系起来，这个的 MA 比较简单，在评估
时候，存在写 KPI，有简单的度量就可以了。要求比较低。
6、配置管理(CM)：有一个 CVS 或 VSS 工具即可。
7、 产品与过程质量保证(PPQA)：成立 QA 机构，主要是质量保证、质量控制及评审。
四、CMMI3 级：已定义级
2 级其实有很多问题还没有解决的，细心的人会发现，2 级对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。在 3 级，你
会发现：
1)有指导需求开发的需求开发(Requirements Development)这个 PA；
2)有指导设计、编码工作的技术解决方案(Technical Solution)这个 PA；
3)有指导如何保证工作产品满足要求的确认(Verification)；
4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；
5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(Product Integration)；
2 级的 PP 与 PMC 是直接与项目管理有关的两个 PA，在 3 级，对项目管理的要求进一步提高：
6)集成项目管理(Integrated Project Management)：3 级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的
过程，并用这个过程来管理项目。
7)风险管理(Risk Management)：2 级只有 PP 的 中提到要识别风险，而在 3 级专门有一个 PA 对风险管理提出更高的要求。
大家不知道有没有发现，2 级的 PA 都是直接针对项目提出要求的。3 级的 IPM 和 RSKM，除了对项目级提出要求，另外也对组织级提出了要求，
IPM 要求有组织级的资产库，RSKM 要求要有组织级的风险管理策略等。另外，3 级有几个“O”开头的 PA，这几个 PA 都是直接对组织级的提
出要求。
8)组织过程焦点(Organizational Process Focus)：这个 PA 要求组织成立 SEPG 来推动过程改进的工作，要求识别、计划、实施改进过程，保证组
织过程能持续改进。
9)组织过程定义(Organizational Training)：这个 PA 要求组织级建立财富库，财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。
10)组织培训(Organizational Training)：要求组织根据商业目标要求准备并提供培训。
3 级还有一个很特别的 PA：
11)决策分析及解决方案(Decision Analysis and Resolution)：这个 PA 提供了一个如何做出最佳决策的方法指导。软件行业很多重要的决策，如设
计方案、采购方案等，都可以应用这个 PA 提供的办法，另外也可以在组织过程改进中应用决策分析的办法。
总结一下 3 级的几个重要特点：
1)明确规定了需求开发、设计、编码、测试、集成等软件开发各过程的要求。
2)对项目管理提出了更高的要求，要利用组织级的数据来管理项目。
3)出现了专门针对组织级的 PA，要求有专门的组织来负责过程改进的工作。
4)提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以用于组织级过程改进。
由这些特点大家可以看到，3 级已经对软件开发的各个方面有了详细的要求，2 级很多不明细的地方全部已经明确。一个达到 3 级的企业，肯定
会定义了很多软件开发各个方面的过程，并且会有组织级的财富库。所以 3 级叫“已定义”级。
补充说明：
3 级还有另外 3 个 PA 上文没有提到，分别是
Integrated Teaming、Organizational Environment for Integration：对大型软件团队提出了要求，一般情况下中小型软件企业可以 NA。
Integrated Supplier Management：如果软件企业需要管理大量的供应商，则需要考虑这个 PA。
这 3 个 PA 大部分情况下不需要考虑，将暂时不展开详细的讨论。
五、CMMI4 级：定量管理级
4 级只有两个 PA，就是：
组织过程性能(Organizational Process Performance )
定量项目管理(Quantitative Project Management)
OPP 是对组织级的要求，组织需要统计出组织级的基线；
QPM 是对项目的要求，项目要用组织级的基线来控制项目过程。
六、CMMI5 级：持续优化级
5 级就只有 OID 和 CAR 两个 PA，两个 PA 对 3 个可以提高企业生产力的途径进行了指引，只要把 OID、CAR 做好，企业就可以“持续改进”
了。
其实一个软件企业，要提高生产力，有 3 方面途径：
1)改进过程，使现有的过程更强更有效。
2)引入新技术，提高生产力。
3)对工作出出现的问题进行原因分析，避免以后再次出现。
OID-组织革新与部署(Organizational Innovation and Deployment )这个 PA 给出了明确的指引。
工作中发现的每个问题，其实都是改进的机会，但实际工作中发现的问题可能非常多，需要选择最有价值的问题进行深入分析，并避免
其再次发生。通过不断地修复问题，组织的生产力就会不断提升。
CAR-- 原因分析及解决方案(Causal Analysis and Resolution)这个 PA 给出了明确的指引。
附：常见 PA 下 SG。
PP 项目计划：
SG1 Estimates of project planning parameters are established and maintained.
建立和维护用于项目计划的各类参数的估算。（建立估算）
SG2： A project plan is established and maintained as the basis for managing the project.
建立和维护项目计划，这个计划要作为项目管理的基础。（建立计划）
SG3： Commitments to the project plan are established and maintained.
建立和维护对项目计划的承诺。项目计划要被相关的人评审和认可。（取得承诺）
PMC 项目计划跟踪与控制
SG1: Actual performance and progress of the project are monitored against the project plan.
根据计划，跟踪项目的实际性能和过程。
SG2: Corrective actions are managed to closure when the project 's performance or results deviate significantly from the plan. 项目的性能或者
结果明显偏离计划时，要采取纠正措施保证按计划进行。
RM 需求管理：
SG1 Requirements are managed and inconsistencies with project plans and work products are identified. 管理需求并且识别出需求与项目计划、
工作产品不一致的地方。
这句话有两层意思：
1.需求要被管理，
被管理的意思又有两层：
一是需求要被确认，
二是要控制需求变更
2.需求要用来指导下游的工作产品，如：计划、设计、测试等
MA 度量
SG1: Measurement objectives and activities are aligned with identified information needs and objectives. 这个 SG 主要讲述的是，组织级要明
确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。
SG2: Mesurement results the adreess identified information needs and objectives are provided.
这个 SG 主要讲述的是：根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。
SG1 主要从组织级的角度定义度量的做法，SG2 就是按照已定义的做法，在实际工作中开展度量的工作。
CM 配置管理
SG1: Baselines of identified work products are established.
建立已识别的工作产品的基线。
配置项与基线的区别：
配置项是需要进行配置管理的最小单位，如：一份文档、一片段代码等。
基线是配置项的一种，基线需要进行更加严格的管理。
一般配置项的管理等级是：
权限控制、版本控制。而基线的管理等级除了具备以上管理外，还需要非常严格的变更控制办法。
SG2: Changes to work products under configration management and tracked and controlled.
跟踪和控制置于配置管理系统下的工作产品的变更。
SG3: Integrity of baselines is established and maintained.
建立和维护基线的完整性。
功能审计：指工作产品是否满足一定的功能要求，这个工作一般不由配置管理员负责，
而是通过文档的评审、软件的测试进行。
物理审计：就是检查工作产品是否符合格式、版本号等方面的要求，一般有配置管理元负责。
配置项要进入配置库前，都应该经历审计，保证其符合要求，保证后续工作产品的正确性。
如果是基线级别的工作产品要进入配置库，需要接受更加严格的审计。
PPQA 产品与过程质量保证
SG1: Adherence of the performed process and associated work products and services to applicable
process descriptions,standards,and procedures is objectively evaluated.
依据一定的标准的客观地评估被执行的过程及相应的工作产品。
这里要注意几点：
1)要有一定的标准，这是基础。
2)评估要客观。
3)要对过程、产品都进行评估
SG2: Noncompliance issues are objectively tracked and communicated,and resolution is ensured.
发现的问题要客观地被跟踪、沟通并解决。
RD 需求开发
RD 有三个 SG，SG1 开发客户需求，SG2 开发产品需求，SG3 分析和确认需求。
前两个 SG 讲述的是需求开发由顶而下、由粗到细的过程，SG3 讲述的是需求分析和确认的过程。
SG1: Stakeholder needs,expectations,constraints,and interfaces are collected and translated into
customer requirements. 干系人的需要、期望、约束和接口要求被收集并转化为客户需求。
SG2: Customer requirements are refined and elaborated to develop product and
product-components requirements. 客户需求是精确和详细的，以用来开发产品需求和产品组件需求。
SG3: The requirements are analyzed and validated,and a definition of required functionality is developed. 需求被分析和确认，并定义出具体的功
能性需求。
TS 技术解决方案这个 PA，主要讲述的是设计、开发、实施方面的问题。
在 CMM 中，对设计、开发、实施方面的要求是比较简单的。
SG1: Product or product-component solutions are selected from alternative solutions.
从候选方案中选择产品或者产品组件的解决方案。
SG2: Product or product-components designs are developed.
开发产品或者产品组件设计。
SG3: Product components,and associated support documentation,are implemented from their designs. 实施产品设计并开发相应的支持文档。
PI 产品集成-简单的说就是把组成产品的所有软件组件组装起来，使之运行在目标环境上，
产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。
系统越复杂，集成就显得越发重要。微软的每日构建，极限开发中的持续集成，都是对产品集成的基本原则，
其基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。
SG1 Preparation for product integration is conducted. 准备产品的集成。
SG2 The product-component interfaces,both internal and external,are compatible.
产品组件的接口，包括内部和外部的，都是兼容。
SG1 的 SP 的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1 的主要任务是完成这些文档，
而 SG2 的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。
SG3 Verified product components are assembled and the integrated,verified,and
validated product is delivered. 验证产品组件被装配和集成，经过验证和确认的产品被交付。
SG3 主要讲的是执行集成的过程，并交付产品给客户。
VER 确认
与验证不同，验证强调的是在开发过程中对工作产品进行检查，尽早发现问题。
而确认强调的是，在真实的使用环境中，确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的，为了有效地避免
在开发环境中没有问题，但一到真实环境就出现问题的情况，确认的工作是非常重要的。确认不一定在项目后期才进行，这个 PA 没有对确认
的时间有任何的规定。作为一般的常识，我们应该尽快安排软件的确认工作，如：尽快发出一个小版本，在实际环境中运行起来，尽快发现确
认中的问题。一般来说，调试、试用、验收测试等都是确认的工作。
SG1 Preparation for validation is conducted. 准备确认工作。
SG2 The product or product components are validated to ensure that they suitable
for use in their intended operating environment. 执行确认，确保产品或者产品组建在目标操作环境下满足使用的要求。
VAL 验证
验证就是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法
一般是同行评审或者是软件测试。那什么是同行评审呢？比方说：A 君是做软件设计的，B 君也是做软件设计的，
A 君写了一份设计文档，让 B 君这个同行（因为大家都是做设计的）来给给意见，这样就使同行评审。同行评
审的目的就是让有同样工作经验和技能的人来评审自己的工作产品，发现尽量多的问题。验证这个 PA 其目的是
希望软件企业在软件开发整个过程中，做好相应的检查工作，把尽量问题发现前面，保证了项目的可控性，降低
开发的成本。这个 PA 有 3 个 Specific Goals,SG1 讲述的是做好验证的准备，SG2、SG3 分别讲述的是执行验
证的两种办法，一种是同行评审，一种是执行验证（通常就是测试）。如果测试是在用户实际生产环境下进行的，
例如：验收测试、客户试用系统等，这时这类工作就属于确认(Validation)了，
请参考关于“确认(Validation)”的内容。
SG1 Preparation for verification is conducted. 准备验证的工作。
SG2 Peer reviews are performed on selected work work products. 对指定的工作产品进行同行评审。
SG3 Selected work products are verified against their specified requirements. 根据指定的要求验证工作产品。
这里的验证既包括同行评审也包括测试，但因为 SG2 专门是针对同行评审的，
这个 SG 可以理解成主要针对除了同行评审外的其它验证活动。
IPM
SG1 The project is conducted using a defined process that is tailored from
the organization’s set of standard process.
项目依据项目定义的过程执行，这个项目定义的过程是通过组织的标准过程裁剪出来的。
什么叫“项目定义过程”？什么叫“裁剪”？
3 级的软件企业，会有很多项目开发方面的各个过程，而且根据不同的情况，可能会有不同的过程。
也有可能同一个过程，允许不同类型的项目的做法或者执行的力度等不太一样。组织过程中会有明确的] 指导，告诉使用这个过程的
项目，如何根据项目本身的特点，来选择或者制定自己项目应该执行的过程。 这个指导，就是裁剪指南，根据这个指导定义项目应该执行的
过程，就是“裁剪”，定义出来的项目应该 执行的过程就是“项目定义过程”。
“裁剪”不一定是减少步骤地，增加步骤，修改步骤等都是“裁剪”，注意是“裁剪”而不是“裁减”。
SG2 Coordination and collaboration of the project with relevant stakeholders is conducted.
协调和项目相关的干系人
RSKM 风险管理
RSKM 有 3 个 SG，SG1 主要就是讲述组织级的要求，而 SG2、SG3 重点讲述项目如何进行风险管理活动。
SG1 Preparation for risk management is conducted. 做好风险管理的准备。
SG2 Risks are identified and analyzed to determine their relative importance.
识别风险并分析决定他们的相关重要性。
SG3 Risks are handled and mitigated,where appropriate,to reduce adverse impacts
on achieving objectives. 风险被管理并且缓解，以减少对项目管理目标的影响。
SG2 主要讲的是识别和分析风险，SG3 就是要管理风险及采取缓解措施了。
OPF 组织过程聚焦
要做这个 PA，组织要成立 EPG（Engineer Process Group）专门负责过程改进的工作。
这个组是整个公司过程改进的动力源头、策划中心、执行中心、培训中心。
很多公司的过程改进没有做好，很大部分的原因是 EPG 的成员没有选择好。EPG 成员绝对不能清一色
都是“理论派”，没有具体项目经验的。这是最低要求，如果是我的话，我是一个“理论派”都不会
让进 EPG 的。EPG 的成员加起来应该有项目管理、需求、设计、开发、测试等软件各个方面的经验，
并且要有至少一名超级高手对整个软件生命过程都非常熟悉而且很聪明的一个人。
OPF 的每个 Practice 都不是很困难就可以做到 CMMI 的要求，但要做到有效，大家都感觉到过程是在
改进中，对工作有用，这就比较困难了。很多通过 CMMI3 级评估的企业，虽然通过了评估，
但企业对过程改进的感觉并不是很好，大部分是由于 EPG 成员的功力不够，做出来的过程实际意义不大导致的。
下面我们看看这个 PA 的要求：
SG1 Strengths,weakness,and improvement opportunities for the organization’s processes are
identified periodically and as needed 定期地识别组织过程的不足、改进机会。
SG2 Improvements are planned and implemented,organizational process assets are deployed,and
process-related experiences are incorporated into the organizational process assets.
改进被计划和实施，组织过程财富库被部署，以及过程相关的经验等提交到组织过程财富库。
OPD 组织过程定义
OPF 主要关注要有人来负责过程改进的工作，OPD 关注的是组织级要有财富库作为整个组织的知识库。
什么是财富库，简单的说就是对组织有用的东西都可以纳入到财富库中，
财富库可以包含：过程、生命周期模型、裁剪指南、度量库等。
如果把 OPD 进行扩展，就是一个组织如何进行知识管理的问题了，知识可以包括两类，非技术类和技术类，
非技术类包括：标准过程、规章制度、流程、项目管理经验、度量数据等等，技术类包括：设计、代码库、
重用组件等。组织除了要对知识进行分类外，还需要建立知识的收集、分析、存储、使用的策略
及具体可操作的办法。
SG1 A set of organizational process assets is established and maintained.
建立和维护组织过程财富库。
OT
SG1 A training capability that supports the organization’s management and technical roles
is established and maintained.
建立和维护支持组织管理和技术角色的培训能力。
这个翻译比较拗口难懂，大意就是组织要针对组织的管理能力、各方面的技术需要等
建立一套比较完整的培训体系。
SG2 Training necessary for individuals to perform their roles effectively is provided.
提供必要的培训给相应的个体、小组、部门等，使之能更有效地执行职责。
附录
OPF、OPD，一个叫组织过程聚焦，一个叫组织过程定义，不了解的人肯定会把这两个名字搞晕。我们暂且不看他们的名字，这里先
简单介绍两者的不同。
两个 PA 都对过程改进的提出了最直接要求。首先，过程改进是一个持续的过程，一个组织需要不断的分析组织存在的问题，分析出
可改进的点，然后实施系列的改进活动，提供整个组织的过程能力。OPF 关注的就是这个方面。
我们经常要求项目要写文档，写文档的其中一个作用就是供后人借鉴。另外，我们也经常听到要进行知识管理，知识管理对软件企业是非
常重要的。每个公司都希望能积累经验，这些经验能供以后工作所借鉴。这样就有“财富库”这样的一个概念，财富库简单的说就是组织的知识
库，它包括：组织的过程、各项目的文档、度量的数据等等，所有组织 认为对以后有用的东西，都可以纳入财富库。OPD 关注的就是这个
方面。
七、CMMI 与 ISO 的区别
ISO 是国际标准化组织的简称。ISO 9000 标准是由 ISO/TC176（质量管理和质量保证技术委员会）制定的所有国际标准。ISO 9000 族国际
标准时在总结了英国的国家标准基础之上产生的，因此，欧洲通过 ISO 9000 认证的企业数量最多，约占全世界的一半以上。受此影响，相当多
的欧洲软件企业选择了 ISO 9001 或 TickIT(ISO 9000-3)认证。目前已发行 4 个标准。ISO 9000：2000 质量管理体系 基础和术语；ISO 9001：2000
质量管理体系 要求；ISO 9004：2000 质量管理体系 业绩改进指南；ISO 19011 质量和/或环境管理体系审核指南。这里因为大家都比较熟悉 ISO
9000 标准。本文主要是针对 ISO 9001：2000 版标准。
CMMI 有两种表述方式：阶段表述（Staged Representation）和连续表述(Continuous Representation) ，前者采用成熟度等级模型（共 5 个等
级），后者采用能力等级模型（共 6 个等级），如表 1 所示。这两种表述方式没有先进或落后之分，阶段表述方式与 CMM 兼容，连续表述方
式与 ISO/IEC 15504 相似。
本文参考的是 CMMI-SE/SW 阶段表述方式。
表 1 CMMI 的两种表述方式
阶段表述 连续表述
成熟度与对应名称 能力等级与对应名称
0 Incomplete
1 Initial 1 Performed
2 Managed 2 Managed
3 Defined 3 Defined
4 Quannitiatively Managed 4 Quannitiatively Managed
5 Optimizing 5 Optimizing
CMMI 模型概要
软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好的管理其软件过程，从而使一些好的
开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定在可得到特定人员上的成功不能
为全组织的生产和质量的长期提高大下基础，必须在建立有效的软件工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，
才能持续的成功。
CMMI 提供了一个框架，将软件过程改进的进化步骤组织成 5 个成熟等级，为过程不断改进奠定了循序渐进的基础。表 2 给出了
CMMI-SE/SW Staged Representation 模型概要，表中的 5 个等级各有其不同的行为特征。不同等级组织的行为特征：即一个组织为建立或改
进软件过程所进行的活动，对每个项目所进行的活动和所产生的横跨各项目的过程能力。
表 2 5 个等级各有其不同的行为特征
过程能力等级 特点 PA
初始级（Initial） 软件过程的特点是无次序的，甚至是混乱的。几乎没有什么
过程是经过妥善定义的，成功往往依赖于个人或小组的努力。
可 重 复 级
（Repeatable）
建立了基本的项目管理过程来策划和跟踪项目的成本、进度
和功能实现。制定了必要的过程纪律，能重复以前类似应用项目
取得的成功。
需求管理（RSQM）；项目规划（PP）；项目
监控（PMC）；供应商合约管理（SAM）；度量
与 分 析 （ M&A ） ； 过 程 与 产 品 质 量 保 证
（PPQA）；配置管理（CM）
已 定 义 级
（Defined）
已将管理和工程两方面的软件过程文档化、标准化，并综合
成该组织的标准软件过程。
所有项目均使用经批准的、剪裁的标准软件过程来开发和维
护软件。
需求开发（RD）；技术解决方案（TS）；产
品集成（PI）；验证（VER）；确认（VAL）；机
构过程焦点（OPF）；机构过程定义（OPD）；机
构培训（OT）；集成化项目管理（IPM）；风险
管理（RSKM）；决策分析（DAR）；
已 管 理 级
（Managed）
收集了软件过程和产品质量的度量数据。软件过程和产品质
量均得到定量的了解和控制。软件开发的成本、进度和软件质量
等都可以定量预测。
机 构 过 程 性 能 （ OPP ） ； 量 化 项 目 管 理
（QPM）
优 化 级
(Optimizing)
通过收集来自过程和来自实验创新思想和技术的定量反馈信
息，使得持续的过程改进成为可能。
机构创新及部署（OID）；因果分析（CAR）
2 比较的结果
2．1 ISO 9001 和 CMMI 的对比关系表如表 3 所示。
此比较是基于 ISO 9001：2000 及 CMMI-SE/SW Staged Representation。
表 3 CMMI ISO 9001 与 CMMI 对比关系表
ISO 9001 条款 CMMI 的 PA/Common Features
总要求（）总则（）质量手册（） PPQA;PP; Verification; OPD;
文件控制 ( ) CM;各 PA 的 Directing Implementation
记录控制 ( ) CM;各 PA 的 Directing Implementation
管理职责 (5 ) PPQA;PP; PMC; Verification; Commitment to Perform; Ability to Perform; QPM;
OPD;
资源提供 ()总则 ()基础设施（）工作环 Ability to Perform; PP
境（）
能力、意识和培训（） Ability to Perform; OT
与顾客有关的过程（） RM;RD;PP;SAM;
设计和开发（） PP;PMC;CM;QPM;TS;PI;VER;VAL;RSKM
采购（） SAM
生产和服务提供的控制（） PP;PPQA;OPP;OID;Verification;M&A;CM;RD;TS;PI;VER;VAL
标识和可追溯性（） CM;各 PA 的 Directing Implementation
顾客财产（） IPM;SAM
产品防护（） CM
监测和测量装置的控制（） VAL;VER
内部审核（） PPQA; Verification
过程的监视和测量（） PPQA; Verification; M&A
产品的监视和测量（） SAM;VAL;VER;各 PA 的 Directing Implementation
不合格品控制（） CM;VAL;VER
数据分析（） DI;M&A;OPD;REQM;OPP;QPM;DAR;
纠正措施（）预防措施（） CM;PPQA;CAR;DAR;
2．2 ISO 9001 和 CMMI 既有区别又相互联系，两者不可简单的相互替代。共同点：
(1)两者均可作为软件企业的过程改善框架。
(2)两者是强相关的，类似之处高度重叠。
(3)两者均强调持续改进。在基本原理方面，ISO 9001 和 CMMI 都十分关注软件产品质量和过程改进。尤其是 ISO 9001：2000 版标准增
加持续改进、质量目标的量化等方面的要求后，在基本思路上和 CMMI 更加接近。
(4)两者最大的相似处在于其底线都是“说你要做的，做你要说的”。ISO9001 的基本前提是：每个重要的过程应该文档化，每个可提交产
品的质量应该通过质量控制活动检查。ISO9001 要求编制出指导手册或指南之类的文档，用以说明应该做什么或应该如何做。CMMI 同样强调
过程文档化，并按文档进行实践。CMMI 的 PA 的突出点是以“依据书面规程”或“遵循书面的机构管理策略”这样的用语作为引导。
CMMI 也强调要求记录信息，以便后面的过程使用，并用于改进过程，这相当于 ISO9001 中质量记录是否达到要求的质量和是否有效地
运行质量体系。
不同点：
(1)ISO9001 面向合同环境，站在用户立场对质量体系标准提及地各项要求进行控制，而 CMMI 是对组织内部过程能力地逐步改善。
(2)ISO9001 不覆盖 CMMI，CMMI 也不完全覆盖 ISO9001。
a) 细节上差别很大，ISO9001 的第 4、5、6、7、8 章共 9 页，而 CMMI 超过了 500 页。如果给定不同的抽象层次，在确定准确的对应
关系的过程中包含可某些判断。
b) ISO9001 条款与 CMMI 的 PA 没有很强的联系。CMMI 没有很好涉及的是顾客财产（）、生产和服务提供的控制（）中对于
软件复制、交付和安装的要求。而对于 的服务的内容则是以完全分布的方式存在于 CMMI 中。ISO9001 条款与 CMMI 的确切关系有重要
争议的是纠正和预防措施（、 ）和数据分析（）。
2) 在形式上。CMMI 分 5 个等级，与 ISO9000 审核后只有“通过”和“不通过”两个结论相比， CMMI 是一个动态的过程，企业在取得低
级别证书后，可根据高级别的要求确定下一步改进的方向。
2．3 取得 ISO 9000 认证的组织大约相当于 CMMI 的哪个等级？
表面上看，获得 ISO 9001 认证的企业应该处于 CMMI 第 3 至 4 级的水平，实际上，有些尚处于 CMMI 第 1 级的企业也取得了 ISO 9001
认证，原因是 ISO 9001 强调以顾客的要求为出发点，不同的顾客要求的质量水平也不同，而且各个审核员的水平/解释也有些差异；另一个原因
是达到 CMMI 第 2 级意味着完全实现第 2 级 PA，而 ISO 9001 高度抽象，到底要求细致到何种程度才使评估者满意是无法清楚的。
经过前述的比较，一般而言，通过 9001 认证的企业可以达到 CMMI2 级或略高的程度，通过 CMMI3 级的企业只要稍作补充，就可较
容易的通过 ISO 9001 认证。粗略的说，ISO 9001 近似于 CMMI“ 级”。ISO 9001 约有 80%的文件可以用于 CMMI2 级评估。
取得 CMMI 第 2 级（或第 3 级）不能笼统的谈可以满足 ISO 9001 的要求
CMMI 第 2 级的所有关键过程都涉及 ISO 9001 的要求，但都低于 ISO 9001 的要求。另外，一些 CMMI 第 1 级的组织在满足了第 2 级和
第 3 级的一些 PA 的要求后，也可以获得 ISO 9001 人证证书。
一些 CMMI 第 2 级或第 3 级的企业可能被认为符合 ISO 9001 的要求，但是，甚至一些第 3 级企业也需要另外 ISO 9001 的要素 的
交付和安装要求以及补充对现货软件和可复用软件的控制。
八 CMMI 在软件项目中的应用
主要就是过程控制。
九、其它
为方便初学者理解和整体上认识 CMMI，从网上找到两个例子，一个是从项目开发的角度，另一个是从聚餐的角度还认识 CMMI.
项目开发：
CMMI 1 初始级
了解了 CMMI 的身世，我们再来看一下 CMMI 的不同级别。严格来讲，CMMI 级别有连续式和阶段式两种描述方式。虽然方式不同，但所表
达的意思是一样的。我们以最常用的阶段式进行描述。先来看下边这个故事：
A 公司刚刚拿到一笔订单，公司让小张主要负责开发这个项目。小张是名牌大学毕业高材生，一个人可以几天几夜不休息写出几千行代码，在
公司属于大侠级人物。
接到上司的任务，小张不敢怠慢，仔细阅读了项目合同，并和用户方通了电话，仔细询问了用户希望实现的需求。经过一番深思熟虑，他的脑
海里已经有了大概的构思。于是，小张打开电脑，开始了他非常熟悉的编码工作。
一周过去了，老板过来询问项目的进展，小张说如果不出意外的话，一个月应该差不多能完成。老板很高兴，夸奖小张很能干。
可接下来的事情并不像小张想象的那么顺利，他突然发现：由于一时疏忽，竟然忘掉了一个很重要的功能；如果将其加进去，需要推翻以前编
写的大部分代码。想到已经跟老板夸下海口，没有办法的小张只好连续加班好几个晚上，最后终于把代码修改完成了。虽然经过了这样一次挫折，
但是小张感觉还是比较庆幸：幸亏自己发现得早，要不然就死定了。
接下来的开发一切顺利，小张还是重复着夜以继日的编码工作。眼看就要大功告成，小张很高兴得把喜讯告诉了老板，于是老板也很高兴得通
知了客户，说下周你们就可以过来看产品了。
用户高高兴兴来到公司之后，当小张跟他们介绍产品时，用户却挑出了很多毛病。原来小张当初没有完全理解用户的意图，此后也没有与用户
进行太多沟通，他以为自己已经完全理解了用户需求，因此就按照心目中的想像把产品开发完成了。
看到用户提的那么多问题，小张别无选择。于是，他又开始没日没夜地修改起了代码。这次小张吸取上次的教训，跟用户进行了多次沟通，最
后终于完成了产品。但是整个开发进度却延迟了一个月。虽然老板没有批评他，但是小张心里的滋味也不好受，可又能怪谁呢？只能怪自己运气不
好，在项目中碰到了这么多倒霉的事情。
真的是小张那么倒霉吗？当然不是，而且他运气还算不错了。按照他这样的开发过程，只发生这两件事情已经是非常幸运了。在开发之前没有
完全弄清楚用户的需求，也没有备忘录以免发生遗漏，更没有预先估计风险并采取预防措施，而只是碰运气，走一步算一步，你说能不出问题吗？
所以，小张的开发过程还停留在 CMMI 第一级，也就是初始级的水平。
CMMI 2 管理级
如果用 CMMI 2 管理级水平进行改进，小张的这个项目应该怎么做呢？
在真正动手做之前，先别忙着编程序，应该先考虑一下怎么做才能把事情办好，并且尽可能想得周全一些。我们不妨从下边几个方面帮
助小张分析一下：
1、用户的需求是什么？怎样确保真正理解了用户的需求呢？那就先做个系统的需求调研吧。 2、为了避免遗忘某个需求，我还应该
把这些需求都记录下来才行。（REQM 需求管理）
3、对了，这个功能技术难度太大，要不跟老板申请外包吧。（SAM 供应协议管理）
4、剩下的任务老板让我一个月完成这个任务，我得先计划一下，要是完不成，我得提前跟老板说啊。（PP 项目计划）
5、计划出来了，还不错，可以完成。不行，还不能高兴的太早，我每周还得跟计划对照一下，看计划完成得怎么样。（PMC 项目跟踪）
6、要是我的代码下次也能用就好了，而且以后维护也得用啊，我得找个工具把代码管理起来。（CM 配置管理）
7、老板不太放心，安排了一个人来监督我，呵呵，我做的很好，尽管汇报吧。（PPQA 质量保证）
8、任务完成了，真累啊，不行，我得算算我在这个项目上花了多长时间，加了几次班，遇到了哪些问题，这些问题是怎么产生的，下次的
项目我得提前做好打算。（MA 度量）
经过了这样的考虑和计划，小张顺利开发完了第二个项目，产品拿到用户那里正式使用了，小张也因为出色的表现受到了领导的表扬。
可是产品上线不久，就因为负荷压力过大引起死机，给用户造成了很大的影响。这个问题迅速反馈到了公司老板那里。老板找到了小张。呵
呵，看来小张真够倒霉的，什么事情都让他碰上了，小张百思不得其解，为什么我这么努力，还是出问题了呢？
原来，小张开发完之后，由于测试人员出差，他就自己测了一下，觉得没问题就交给了用户。用户对产品也很放心，认为应该没什么问题，产
品就上线了。但由于用户实际使用环境远比小张的开发环境复杂得多，而这些小张之前并没有意识到，也根本没有进行这方面的考虑和设计。所以
才发生了这样的一幕。
CMMI 3 可定义级
那么小张应该吸取什么教训呢？我们用 CMMI 3 可定义级来帮着分析一下。
1、在了解用户需求之后，编码之前其实还要做很多工作。首先，应该把需求分析一下，看看哪些是功能需求，哪些是非功能需求，如何进
行模块划分，不同模块之间会有哪些接口需求等等。由于小张缺少这样的分析过程，也没有形成最终的需求规格说明书，所以他最终还是遗漏了非
功能需求，以至于产生上边的问题。（RD 需求开发）
2、需求分析完成之后，小张还应该进行设计，把用户所有的功能需求和非功能需求进行统一考虑，形成设计说明书，然后再进行编码。这
样才会保证代码结构合理，并且会全面满足用户的需求。（TS 技术解决方案）
3、在开始编码之前，小张还应该考虑一下不同模块和组件之间集成的顺序，必要的话，还应该跟用户商量一下，根据用户需求的优先级来
决定模块组件开发和集成的顺序。（PI 产品整合）
4、为了保证设计和编码质量，部门还应该组织一些经验比较丰富的人员来帮助小张发现一些问题，因此，在开发过程中，还应进行设计评
审和编码走查方面的工作。小张自己也应该进行一些单元测试，以便及时发现问题，减少影响和损失。开发完成之后，小张必须交给测试人员进行
系统测试，因为自己检查自己的代码往往是检查不出什么问题来的。（VER 验证）
5、测试人员测试完成之后，在产品真正上线之前还应该进行验收和试运行。试运行一段时间，一切都没有问题之后，再将产品正式切换上
线。这样即使在这个阶段发现 Bug，也不会造成太大影响。为了确保验收效率，小张可以事先准备一份验收大纲。（VAL 确认）
在 CMMI 3 可定义级中，把以上 5 项作为工程流程领域，无论做怎样的裁减，这 5 项都是不能裁减的。它们之间的关系在 CMMI 中文版中
用下图来表示：
经过这样一番分析之后，小张终于明白：看来自己是少做了很多工作。于是他决定下一个项目一定按照该流程好好做。
小张的项目引起了公司极大重视，为了避免类似问题产生，公司专门进行了以下工作的改进：
1、公司过程改进部门分析了问题产生原因，找出了不足，并针对不足制定了相应的改进计划。（OPF 组织过程焦点）
2、结合成功项目经验，经过认真分析和考虑，公司内部制定了软件开发生命周期规程指南，同时还制定了相应的文档模板。（OPD 组织过程
定义）
3、为了保证各部门相关人员密切配合，团结协作，各负其责，公司公司专门定义了软件开发不同角色以及角色职责，确保各种角色充分发挥
其作用，保证整个团队的协作开发。（IPM 集成项目管理）
4、为了减少项目风险，组织了有经验的项目经理和开发经理，总结归纳项目风险，建立部门风险知识库，并要求在项目过程中进行风险管理。
（RSKM 风险管理）
5、为避免重大决策失误，成立了专家团，制定决策分析依据，在一些项目的重要决策上，帮助项目进行决策分析，以减少风险。（DAR 决策
分析与解决方案）
6、为了便于大家理解和吸收，公司专门组织了相应培训，同时还进行了需求开发、设计、单元测试方面的培训，这些培训使大家受益匪浅。
（OT 组织训练）
经过这样的改进之后，公司整体的开发和管理水平都上了一个很高的台阶。项目成功的几率也大大提高了，公司还专门请来了 CMMI 评估师，
并且顺利通过了 3 级的正式评估，客户的订单也就纷至沓来。从这点来说，公司真的应该感谢小张才对啊！
CMMI 4 量化级
过了 CMMI 3 级，公司各方面工作井然有序，一切都很正常。看上去似乎没有什么需要改进的了。就这样过了一年的时间，年底将至，公司正
在加紧统计一年来的利润和成本，统计的结果却让人吃了一惊：虽然公司的合同额非常大，利润却不是很多，这是什么原因呢？原来公司虽然在软
件开发上做了很多工作，保证了项目顺利的开发完成并上线，但是每个项目的真正数据并没有进行记录和统计分析。一个项目实际花费了多少工作
量，产生了多少费用，到底什么项目利润比较大，可复用性比较强，什么项目个性化需求太多，成本比较大，可复用性较弱。这些都没有相应的数
据进行支持。
发现了这个问题之后，公司又召开了一次经理会议，做出了如下改进措施：
1、建立公司内部统一的过程管理平台，所有项目和产品的开发都要通过过程管理平台进行管理；
2、根据平台的数据积累，公司制定了统一的量化目标以及相应度量活动。（OPP 组织过程绩效）
3、根据公司的量化目标，每个项目定义自己的量化目标，并且定期进行偏差分析，分析偏差产生的原因，制定相应改进措施.（QPM 量化项
目管理）
经过一段时间，平台中积累了大量数据。每个项目实际成本、项目进度、风险以及曾经发生过的问题在平台上都能够一目了然。在这些历史数
据的帮助下，销售人员对项目的报价充满了信心；开发经理做项目计划的偏差率也越来越小，对项目问题的预测和掌控能力也更加强大。这不，公
司正准备进军 CMMI 4 呢！
CMMI 5 持续改进级
虽然小张所在的公司刚准备向 CMMI 4 级发起进攻，不妨先了解下 5 级也没有关系，它并没有我们想象的那么可怕。5 级只有两个域，分别
叫组织创新与发展（OID）、原因分析与解决方案（CAR）。这两个域的主要意思，就是在度量的基础之上，选择循序渐进的创新与改善活动，逐
步改善，从而达到企业制定的各项指标；同时对发生的问题以及产生的缺陷进行分析，并采取积极预防措施，避免类似问题再次发生。
怎么样，看完这个故事，你是否觉得 CMMI 离我们并不是那么遥远呢？是不是也已经被我“迷惑”，对 CMMI 有些痴迷了呢？呵呵，尽管 CMMI
有如此多好处，企业也有一万个理由应该去实施，但是切不可操之过急。要先考察企业的真正需求和现状，看到底需不需要这些改进，有没有能力
进行改进，改进的过程需要哪些方面的配合等等；否则，改进不但不能产生相应的效果，很可能还会起到相反的作用。要知道：企业的过程改进也
是一个项目，需要做好充分的准备，并且做坚持不懈的努力。
2、聚餐：
通过一个“吃饭”的例子，让大家感受下 CMMI 1 级到 5 级。
某个时间，公司进行聚餐活动。请你组织这次活动，目的是用合理的经费让大家高高兴兴地吃一顿！你会如何组织这个的活动？
用 CMMI1-5 级如何管理？
第 1 级：初始级
第 2 级：受管理级
第 3 级：已定义级
第 4 级：定量管理级
第 5 级：持续优化级
Level 1：初始级
不用做什么计划，提前一点订好座位，当天下班大家一哄而去，现场点菜，然后大吃一顿。
但是这样做会有什么结果？
定不到位？菜不合大家口味？经费超出？大家心情变得很沮丧？有没有可能取得比较好效果呢？
Level2:受管理级
这样做会有什么结果？大家吃得满意？预算控制得好？老板高兴？真的能这样吗？
2 级做法遗留的一些问题
不需要进行风险管理吗？用什么方法调查大家喜欢吃什么菜式呢？有指南就好了？如何组织聚餐活动，是不是应该有个指导？或者有成功经验可供
参考？……
Level 3：已定义级
经过一段时间积累，以下活动都有明确的指导文档：（RD TS VER VAL PI IPM ）
如何写计划
如何组织吃饭现场活动
如何确定餐单
….
对于确定餐单、选定酒水供应商方面采用决策分析的办法。------------------DAR
进行风险管理。---------------------------------------------------RSKM
建立了相应的培训制度。--------------------------------------------OT
另外，为了让组织聚餐活动越做越好，成立了专门的 SEPG 来维护文档。----------OPF OPD
这样做会有什么结果？这次活动成功的几率大大提高了？但谁能拍胸口说：一定能成功？
3 级遗留的问题
感觉成功机会会提高很多，但没有一个底？最好有个数字能说明问题。
Level 4：定量管理级
积累了大量聚餐活动的 CPI、SPI 数据。
积累了大量的聚餐满意度数据。
当前反应聚餐活动能力的数据 CPI、SPI、满意度等在一定范围内波动。
根据当前 CPI、SPI，可预测聚餐活动的最终成本。
通过这些数据对活动进行监控。
Level 4 的特点
根据历史数据，算出了性能基线、性能模型。------组织过程性能(OPP)
聚餐活动进行时，利用性能基线、性能模型进行定量管理。-----定量项目管理(QPM)
这样做会有什么结果？
聚餐活动进展情况了如指掌；比较准确的估计到最后的结果；成功的几率极大提高。
Level 4 的遐想
哇！Level4 已经很厉害了！更厉害的 Level5 会是怎样呢？请猜？
Level 5：持续优化级
如何持续改进？
原因分析
采用新技术
公司定下新的目标
Level 5 之 原因分析
1、通过数据，我们发现由 A 君组织聚餐活动时，满意度总能在基线范围内。但由 B 君组织时，满意度异常的高，超出了基线上限。于是我们进行
原因分析，发现 B 君进行抽奖活动之前，做了一个调查，知道每个人最想要什么。故抽奖活动做得很出色，满意度就高了。
2、抽奖活动前先进行调查这个工作，在过程文档里面并没有规定的，是 B 君的特殊做法。SEPG 异常高兴，把 B 君的做法写入过程中。于是全部
人都按照这个做法去做了，结果满意度性能基线上升了。
3、对一些特殊问题、特殊情况进行分析，可以得到改进过程的机会。对过程进行改进后，我们的性能会提高。
Level 5 之 采用新技术
出现了这样的一些问题：
a、发现难以统计到场的人员，需要经常去问。
b、很多人不知道如何去聚餐地点。
为了解决这个问题，采取以下新技术：
a、每人配一台 PDA 和 GPS，里面有地图
b、活动组织者用笔记本电脑能见到各位位置。
采用新技术后，大家准时出席率提高，并且满意度也提高。
Level 5 之 公司定下新的目标
预算的偏差率当前值是-20%到 20%，老板觉得不满意，要求改进为-10%到 10%。SEPG 就非常紧张了，投入大量人力物力分析如何改进。SEPG 发
现导致预算偏差大的地方主要在于酒水采购方面，供应商的价钱浮动太厉害。
SEPG 定下改进计划，修改了采购方面的过程，对供应商的选择加强了标准。在某次聚餐中试行新的采购过程，结果发现成本偏差果然控制在-10%
到 10%范围内。分析试行结果后，SEPG 把过程正式推行，最终满足了老板的要求。
通过“吃饭”，应该可以大致的体会到 CMMI 1-5 级的大致内容了！
3.社会历史阶段：
CMMI 的五个级别如何理解呢？我来做个类比。大家都学过社会发展简史，人类社会经历了原始社会、奴隶社会、封建社会、资本主义社会，
还有马克思预言的共产主义社会。CMMI 五个级别分别与人类社会的五个形态有类似之处。
CMMI 一级如同原始社会。在原始社会，没有法律、没有制度，部落间发生冲突和相互仇杀是常有的事情。在 CMMI 一级的组织，产品开发
没有规矩，每个人的工作方式全凭喜好和习惯，一般项目中也极少有关于过程方面的规定，不论采用什么方法、遵循什么样的开发步骤，最后只要
把代码写出来了就可以了，软件开发的主要活动就是编码和调试。很少有项目计划，顶多有个项目时间表，需求、设计等工程文档也很少有。
CMMI 二级如同中国的奴隶社会。从奴隶社会开始，人类便有了文字记载的历史，出现了法律法规，人类进入文明时代，夏、商、周、春秋战
国都属于奴隶社会。但中国的奴隶社会国家，实际上是由众多的诸侯国构成，每个诸侯国有自己法律、度量衡、货币、语言、文字等。
处于 CMMI 二级的组织，各个项目（好比诸侯国）有了各自的制度和标准，比如项目 A 规定采用瀑布开发模型，使用 CVS 作为配置管理工具，
要度量项目的进度和成本；而项目 B 规定采用增量开发模型，使用 VSS 作为配置管理工具，度量项目的质量成本和需求稳定度。同 CMMI 一级比，
项目的开发过程已由混乱的开发方式跃迁到了有纪律的开发过程。
公元前 221 年，秦始皇统一全国，从此中国开始步入了封建社会。秦始皇不仅仅统一了领土，更具有长远意义的是他统一了法律、文字、货币
和度量衡。在秦之前的诸侯割据时代，文字的不统一严重影响文化传播和交流，货币制的不统一，也严重阻碍着各地商品的流通及统一国家的财政
收支，其它方面的不统一也同样带来各种各样的问题。文字、货币、度量衡的统一，在中国历史上占有重要地位。孔子之孙子思在《中庸》倡导“今
天下，书同文、车同轨、行同伦”，可见统一的、标准化是多么重要，如同工业上零件规格的统一，或网络协议的统一一样，都有着重要。
CMMI 三级类似封建社会，结束了项目的“各自为政”的状况，整个组织有统一的过程、标准。这样，新启动的项目不必花精力考虑本项目该走什么
样的过程、遵循哪些标准、使用什么模板等等。因为过程的统一，不同项目项目经验教训具有了可参考性，项目数据具有了可比性了，有了这样的
前提，组织可以创建过程财富库，收集历史项目的经验教训、度量数据、文档样例等等，为后续的项目所使用。所以，到了三级项目管理是基于一
个已建立好的平台上进行的，比如项目经理花费心思项目计划要包含哪些方面，组织级的项目管理计划模板提供了答案。也许项目经理经验有限，
不清楚制定一个好计划有哪些注意事项，那么组织级的项目计划检查单可以帮助项目经理注意到制定计划的关键点，从而制定更加全面、完整的计
划。组织级的经验教训库和风险库同样可以帮助项目经理计划和监控项目。
目前，许多组织为了提高生产率、缩短开发周期、降低开发成本，提升产品质量，建立了一些产品重用组件库，当有了新产品开发时，会像搭
积木一样去使用重用组件构建产品，只对产品独特的地方进行重新开发，这样的过程叫做产品重用，或叫技术重用。而 CMMI 三级的组织，其流程
体系（包括流程、模板、指南、规范、检查单等）和所累积过程资产（如经验教训、风险、样例、度量数据等）类似于一个个产品重用组件，为项
目开发管理所用，这样的过程叫做过程重用。大家都知道重用可以大大提升效率、提高质量，产品重用是有形的资产重用，而过程重用是无形的资
产重用。如果能够很好对无形资产进行累积，并且在项目中推广使用，那么会给组织带来的价值会远超于产品重用所带来的价值。
可见，CMMI 三级相对二级有时一个飞跃：二级开发制度是“诸侯割据”的状态，而三级“一统体天下”；二级是项目级的，而三级是组织级的。
CMMI 四级类似资本主义社会。很多读者或许同我一样，未必会多了解资本主义，那么我们就用社会的部分现象做类比，只要能有助于理解 CM
MI 就好了。
资本主义相对封建社会，科技有了巨大的进步，做什么事情都讲究科学，而科学又是通过数据呈现出来的。研究天文的，有天文方面的数据；
研究地理的，有地理方面的数据；研究经济的，也有经济方面的数据……有了数据，才能说明人们对所研究的事物有了认识和理解。在这些数据的
基础上，通过实践与分析，人们在各个的领域建立一些模型，通过这些模型来理解过去、预测未来。比如，天文学家可以精准地告诉我们何时何地
会出现日食；经济学家可以解读金融危机的原因，预测未来经济的走势……
处于 CMMI 四级的组织，通过历史项目数据的累积，可以反映出当前的组织能力状况，如生产率是 30LOC/人天，进度偏差是 20%等等，同时
可以建立预测模型预测未来，建立控制图找出过程中的异常因素。四级的项目管理要依据数据进行管理，而不仅仅凭着感性的经验，因此，也被称
作量化的项目管理。
需要注意避免一个误区：到四级才有数据、才有度量。其实，在二级就有了度量与分析这个过程域，如果没有二级、三级度量方面基础，四级
的量化管理将成为空谈。二级的度量和四级的量化管理是有区别的，用个炒股的类比来解释。
股票的价格起起伏伏，二级要求股民根据目的设定度量项，并要收集和分析数据，基本上每个股民的目的都是想盈利，那么，收集、记录股票
买入价格、买入时间、卖出价格、卖出时间和股票量等数据，从而帮助分析盈利情况。在二级，股民缺乏数据帮助他们理解具体是什么因素导致股
票价格上扬或下挫，也不清楚明天后天的价格会是多是。如果到了四级，某些度量项要进行细化，如股票价格，设为 Y，通过长期的数据累积和假
设验证找出影响 Y 的因子 x1，x2……，从而建立了股票价格预测模型：
Y=f(x1,x2…)
另外要注意的是，SEI 对四级和五级的理解和要求自 2007 年已发生了很大变化，以往四级强调过程的稳定性和控制图的使用，而现在更强调
过程的可预测性，以及对过程偏差的理解。
综上所述，如果用两个词来形容 CMMI 四级，一是量化管理的，二是可预测的。
CMMI 五级就到了人类社会的最高阶段——共产主义社会。在共产主义社会，物质和精神文明极大丰富，因为是共有制，社会资源更够根据全
民的需求进行合理的配置，而不是以资本家的利益为导向的，从而避免了经济危机、金融危机，社会效率非常高。
达到了 CMMI 五级的组织，在四级量化管理的的基础上，通过持续的、系统的改进，其生产率、产品质量等重要指标都有很大提升。
关于五级的理解，同样要避免一个误区，以为只有五级才要持续改进。其实，从一级到二、三、四、五级，这个过程一直是持续的过程，即使
一个处于三级的组织想要维持三级的成熟度依然要持续的改进，因为环境不断地变化，新问题会不断地出现，过程也要随之优化。
那么，五级的持续改进和之前级别的持续改进差别在哪里呢？比如，一个人每天开车上下班，他不断改进以减低油耗，比如改进开车方式，如
不猛踩油门；速度快时关闭车窗以减小阻力；在路况和交规允许的情况下，高档快速行驶；保证车胎气量充足；确保车上没有多余负载等等。这些
改进项一般是比较明显的，改进者凭借着经验、靠着感性进行的，属于五级前的改进。
如果他上下班有两条线路可以选择，A 线路 10 公里，平均速度慢，但红绿灯相对多；B 线路 12 公里，红绿灯少，平均速度快。如果他平时大
都走 A 线路，那么他现在要不要改进走 B 线路呢？这样问题很难回答了，就不能靠感性来选择，一定用数据来说话。我们假设其它条件相同，可以
建立一个汽车耗油模型，耗油量设为 Y，路程、车速和启动次数为影响 Y 的三个因子，设为 x1，x2，x3，则有：
Y=f（x1, x2, x3）
当通过大量数据统计，得出各个因子的实际数值或者数值分布时，就可以计算出 Ya 和 Yb，如果 Ya＞Yb，则他应该选择线路 B 了。则这样
的改进就是五级的改进了。可见，五级的改进是基于数据的、更加理性的改进。
