软件能力成熟度模型（CMMI）

转载自：https://blog.csdn.net/yongchaocsdn/article/details/80893195

本章内容提要

CMMI概述
CMMI的成熟度等级及其过程域
CMMI的应用
PSP，TSP与CMMI

第一节 CMMI概述

CMMI( Capability Maturity Model Integration)即能力成熟度模型集成，由CMM (Capability Maturity Model)发展而来，它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展，CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。

1.CMMI的历史

1991年，美国卡耐基梅隆大学软件工程研究所（SEI）推出了能力成熟度模型CMM，CMM的作用主要有两方面：

为软件客户提供评价软件开发商能力的方法。
帮助软件开发商改进其软件过程，提高成熟度。

随着CMM在软件界应用的不断推广，其它相关学科和领域也采用它的模式，开发出了许多类似于CMM的模型。

SE-CMM (System Engineering CMM) 系统工程CMM，应用于系统工程管理。
SA-CMM (Software Acquisition CMM) 软件获取CMM，应用于软件获取（采购）方的能力成熟度模型。
IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发CMM，应用于集成系统产品的开发管理。
P-CMM (People CMM)：人员能力成熟度模型，应用于人力资源管理。

为了以示区别，常把CMM叫做SW-CMM。

同一个组织可能会应用多个过程改进模型，但多个过程改进模型的并存可能会引起冲突和混淆。

CMMI为工业界和政府部门提供了一个集成的能力成熟度模型产品集，消除了不同模型之间的不一致和重复，降低了过程改进的成本。

CMMI覆盖了软件工程、系统工程、集成产品开发和系统采购，以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。

CMMI 1.0版于2000年发布，2002年又发布了1.1版，2006年发布了1.2版，2010年发布了1.3版。

CMMI是目前世界公认的软件产品进入国际市场的通行证。一般来说，通过CMMI认证的级别越高，就越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。

2000年6月，国务院颁发了《鼓励软件产业和集成电路产业发展若干政策》，其中第17条中明确规定“鼓励软件出口型企业通过CMM认证，其费用通过中央外贸发展基金适当予以支持”。随后各省市、高新区、软件园都出台了对通过CMM的企业给予资金奖励的制度。

2.软件过程成熟度

软件过程成熟度指一个具体的软件过程被明确和有效地定义、管理、度量、控制和实施的程度。

软件组织成熟的过程是一个不断改进、循序渐进的过程，而不是通过革命性的革新快速实现的。

不成熟组织与成熟组织的对比

3. CMMI中的成熟度等级

初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

已管理级：建立了基本的项目管理过程来跟踪费用、进度和软件的功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

量化管理级：分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据，能够在定量的范围内预测性能。

优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。有能力识别软件过程中的薄弱环节，并有足够的手段改进它们，防止缺陷的产生。

CMMI是一个引导软件组织不断走向成熟的过程模型。

4.CMMI的关键过程域

每个成熟度等级（除了初始级）包含若干个关键过程域（Key Process Area，KPA）。

KPA表示当软件组织改进软件过程时必须集中精力解决的关键问题。

一个组织要想达到某个成熟度等级，必须满足该等级（以及较低等级）包含的KPA的所有要求，满足每个KPA的所有目标。

5.CMMI的能力等级

能力等级（Capability Level, CL）是指在一个单独的过程域中执行的良好程度。

CMMI包括6个能力等级：

CL0，不完整级：过程域的一个或多个目标没有被满足。
CL1，已执行级：过程通过转换可识别的输入工作产品，产生可识别的输出工作产品。能实现过程域的特定目标。
CL2，已管理级：过程作为已管理的过程被制度化。
CL3，已定义级：过程作为已定义的过程被制度化。
CL4，量化管理级：过程作为量化管理的过程被制度化。
CL5，优化级：过程作为优化的过程被制度化。

有关CMMI的说明

CMMI是什么？

CMMI指明该做什么，但没有指明如何做，它不是方法论，没有给出特定应用领域内的专门技术。

CMMI是从软件过程角度定义了成熟的软件过程的实践活动，但它并没有涉及到软件工程的所有方面，对于成熟的软件组织而言，人的因素和技术的因素也同样重要。

CMMI过程改进需要多长时间？有何效果？

统计数字表明：一般需要2年才能把成熟度提升一级（建议安排1.5年到2年）。

根据CMU-SEI的统计，软件企业在引入CMM后劳动生产率平均增长了35%；错误比率平均减少39%；平均成本回报率为5：1。

第二节 CMMI的成熟度等级及其过程域

2.1 初始级

过程

极少存在或使用稳定的软件过程。（过程无秩序）
各种条例、规章制度互不协调，甚至互相矛盾。（开发无规范）

人员

依赖个人努力和精英人物；
项目组成员的工作方式就是哪里出现危机就去哪儿解决。

技术

引进新技术是很大的风险。

度量

不收集和分析数据。

注意：有些组织制定了一些软件工程规范，但如果这些规范没有覆盖基本的关键过程域，且执行没有政策、资源方面的保证时，那么该组织仍然被视为处于初始级成熟度。

改进方向

建立项目管理过程，实施规范化管理，保障项目的承诺。
进行需求管理，建立客户与软件项目之间的共同理解，使项目真正反映客户的要求。
建立各种软件项目计划。如：软件开发计划、配置管理计划、风险管理计划等。
开展软件质量保证活动。

2.2 CMMI已管理级

特征：

进行较为现实的承诺，按以前在同类项目上的成功经验建立必要的过程准则以确保再一次成功。

逐个项目地建立基本过程管理条例来加强软件过程能力。

建立了基本的项目管理过程来跟踪成本、进度和功能，包括：需求管理、计划和跟踪监控、质量管理、配置管理、子合同管理。通过执行这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

过程

软件开发和维护过程是相对稳定的，但过程建立在项目级别，而非企业级别。

软件工程过程受控于有效的工程管理过程，先前的成功经验可以被重复使用。

问题出现时，有能力识别并纠正，承诺可以兑现。

人员

理解管理的必要性并对管理有承诺。

注意人员的培训。

技术

建立技术支持活动，并有稳定的计划。

度量

有计划地收集、分析有关项目过程和产品的数据。

已管理级的改进方向

不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织机构的标准软件过程。将改进组织机构整体软件过程能力作为软件组织的责任。

建立软件工程过程小组（SEPG），长期承担评估与调整软件过程的任务，以适应未来软件项目的要求。

积累数据：建立组织机构的软件过程库及软件过程相关的文档库。

加强人员培训。

已管理级的关键过程域

需求管理
项目计划
项目监督与控制
供应协议管理
过程与产品质量保证
配置管理
度量与分析

需求管理

需求管理（Requirements Management, ReqM）是指在客户和项目组之间就客户的需求建立一个协议并加以管理。该协议包括技术需求和非技术需求两个方面，它构成了整个产品生命周期中估计、计划、执行和跟踪项目活动的基础。

项目计划

项目计划（Project Planning）的目标是为实施和管理项目制定合理的计划。

要制定合理的计划，就要对需要完成的工作做出比较实际的估计，并为完成这些工作建立一些必要约定。

项目计划过程包括如下步骤：定义项目的生命周期，确定项目的范围，估计项目的规模、成本和所需资源，制定项目的进度计划，确定并评估项目风险。

项目监督与控制

项目监督与控制（Project Monitoring and control）的目标是随时掌握项目的实际开发过程，使得当项目的执行活动与计划相背离时，管理部门能采取有效的措施。

供应协议管理

供应协议管理（Supplier Agreement Management）的目标是选择合适的供应商，并对产品获取过程进行管理。

对软件项目来说，常需要采购一些软件或硬件产品，也有可能把项目的一部分外包给第三方来做，而采购和外包可以认为是风险最大的活动之一。

过程与产品质量保证

过程与产品质量保证（Process and Product Quality Assurance）为项目管理者提供项目过程和相关产品的适当的可见性，从而为交付高质量的产品和服务提供支持。

在该过程域中，产品质量评估的客观性对项目的成功是至关重要的，可以通过设立独立的质量保证组或应用一些标准来达到这种客观性。

质量保证工作应尽早开始，在项目初期就应制定相应的计划、标准和规程。

配置管理

配置管理（Configuration Management）是通过配置标记、配置控制、配置状态审核和配置审计来建立和维护工作产品的一致性。

度量与分析

度量与分析（Measurement and Analysis）过程域的目标是开发和维持度量能力，从而能够支持管理信息需求。

将度量与分析集成到项目过程中，主要有以下几方面的作用：

支持客观的计划和估计。
跟踪实际性能，并与计划和目标对比。
识别和解决与过程相关的问题。

2.3 CMMI已定义级

特征：

软件工程和管理方面的软件过程都已经文档化、标准化，并综合成软件开发组织的标准软件过程。

软件过程标准被应用到所有的项目开发和维护当中，有些项目可能要对这些标准软件过程进行裁剪。

对于任何项目，其生产过程、成本、计划和功能都是可以控制的，从而软件质量也可以控制。

软件工程过程组（SEPG）负责软件过程的定义和改进活动。

在全组织范围内安排培训计划。

过程

软件工程和管理活动是稳定和可重复的，具有连续性。

软件过程起了预见及防范问题的作用，能使风险的影响最小化。

人员

整个组织内部的所有人员对于所定义的软件过程的活动、任务有深入理解，大大增强了软件过程能力。

有计划地对人员角色进行培训。

技术

在定性基础上评估新技术。

度量

在全过程中收集使用数据。

在整个项目中系统性地共享数据。

改进方向

开始着手过程的定量分析，以达到定量控制项目过程的效果。

已定义级的关键过程域

需求开发
技术解决方案
产品集成
验证
确认
组织过程焦点
组织过程定义
组织培训
集成项目管理
风险管理
决策分析与解决
集成供应商管理
组织集成环境
集成团队

需求开发（Requirement Development）的目的是生成并分析客户、产品和产品组件的需求。

技术解决方案（Technical Solution）的目的是开发、设计和实现需求的解决方案。

产品集成（Product Integration）的目的是把产品组件组装成产品，保证产品正常工作，并把产品交付给用户。

验证（Verification）的目的是保证工作产品满足它们的指定需求。

确认（Validation）目的是展示当把产品或产品组件放到目标环境中时，它们可完成预期的用途。

组织过程焦点（Organizational Process Focus）过程域的目的是：在彻底理解一个组织当前过程和过程资产的弱点和优势的基础上，计划、实施和部署组织的过程改进活动。

组织过程定义（Organizational Process Definition）的目的是建立和维护一个组织级过程资产和工作环境标准集。

组织级培训（Organizational Training）的目的是增加开发人员的技能和知识，使他们可以有效地执行任务。

集成项目管理（Integrated Project Management）的目的是根据一个集成化的、已定义的过程来建立和管理项目，并管理利益关系人的参与，这些集成化的、已定义的过程剪裁于组织的标准过程集。

风险管理（Risk Management）的目的是在潜在问题发生之前识别它们，以便在产品整个生命周期中计划风险处理活动，并且必要时采取措施以缓解对目标实现的不利影响。

决策分析与解决（Decision Analysis and Resolution）过程域的目的是使用正式的评价过程来分析可能的决策，该评价过程是根据已制定的标准来评价可选方案。

2.4 CMMI量化管理级

过程

可定量地认识过程。

软件过程性能变化小，一般在可接受的范围内。

可以预见过程和产品的质量趋势，一旦度量得到的指标超出标准或有异常，可以及时采用一些措施纠正。

人员

由于每个人都了解个人的作用与组织的关系，因此能够在每个项目中产生强烈的群体意识。

技术

不断地在定量基础上评估新技术。

度量

在全组织内进行数据收集与检验。

度量标准化。

数据用于定量地理解软件过程并稳定软件过程。

改进方向

缺陷预防。不仅在发现问题时能及时改正，而且应采取特定行动防止将缺陷引入到产品中。

主动进行技术变动管理，标识、选择和评价新技术，使有效的新技术能在开发组织中应用。

进行过程变动管理。定义过程改进的目的，不断地进行过程改进。

量化管理级的关键过程域

量化项目管理（Quantitative Project Management）过程域的目的是定量管理项目的过程，从而完成项目的质量和过程性能目标。

组织过程性能（Organizational Process Performance）的目的是建立和维护一个对组织的标准过程集性能的定量理解，并提供过程性能数据、基线和模型来定量管理组织的项目。

2.5 CMMI优化管理级

过程

不断系统地改进软件过程。

理解并消除产生问题的公共根源，防止缺陷的产生。

人员

整个组织存在自觉的强烈的团队意识。

每个人都致力于过程改进。人们不再以达到里程碑的成就而满足，而要力求减少错误率。

技术

基于定量的控制和管理，事先主动考虑新技术、利用新技术。可以实现开发中的方法和新技术的革新，以防止出现错误，不断提高产品质量和生产率。

度量

利用统计数据来评估和选择过程改进。

改进方向

保持持续不断的软件过程改进。

优化管理级的关键过程域

组织革新与部署（Organizational Innovation and Deployment）的目的是选择并部署增量式和创新的改进活动，以便改进组织的过程和技术。

原因分析与解决（Causal Analysis and Resolution）的目的是识别缺陷和其它问题的原因，并且采取措施来预防将来再发生这些问题。

第三节 CMMI的应用

实施CMMI过程改进的两种方法

阶段表示
连续表示

CMMI评估

实施CMMI过程改进的两种方法

CMMI模型支持两种实施过程改进的方法，一种称为阶段表示，一种称为连续表示。

阶段表示（Staged Representation）为过程改进提供了一个预定义的路线图，即从成熟度等级1到成熟度等级5逐级增加，要达到某一成熟度等级，必须满足该等级（及其以下等级）上所有过程域的目标。

连续表示（Continuous Representation）支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。在每个过程域上从能力等级0到能力等级5逐级增加。

阶段表示和连续表示的对比

阶段表示是从CMM模型继承而来，已经过多年的实践检验。它提供了一个明确的、被证实的过程改进路径，遵循这条路径不需要过多的讨论和争论。而且由于它的明确性和统一性，有助于进行跨组织的比较。

连续表示的优点是提供了灵活性。用户可根据具体的改进目标来选择需要实现的过程域及其实现次序。

CMMI评估

成熟度等级的评估由美国卡内基梅隆大学的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。

评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。

评估结果报告给SEI。

一般有两种类型的评估：软件过程评估和软件能力评价。

软件过程评估用于确定机构当前过程的状态，决定一个机构所面临的与过程相关的问题，并且获得机构对软件过程改进的支持。

软件能力评价用来确定合格的软件项目承包方，或用来监督在目前的软件项目中正在进行的软件过程的状态。

软件过程评估方法

判断一个组织当前的软件过程的状态，并发现过程中的缺陷。

判断并确定一个组织面对的与软件过程相关的改进策略。

软件能力评价方法

判断有意承担某个软件项目的软件组织（投标者）的过程能力。

利用评价结果确定选择某一承包者的风险。

判断已进行的软件过程所处的状态是否正确或是否正常。

推动承包者在工作过程中改进他们的软件过程。

过程评估和能力评价步骤

挑选队伍：成员必须具有专业的软件工程和管理方面的知识，并接受过基本CMM/CMMI概念和特定评估及评价方法的训练。

问卷调查：让来自被评估单位的代表完成软件过程成熟度问卷并回答评估评价组提出的诊断性问题。

响应分析：明确哪些回答与问题的答案相吻合，并确定须进一步调查的领域。

现场调查：从响应分析的结果出发，评估小组进行提问、检查、协商等，以获取专业性的结论，说明软件过程的 KPA是否达到了应有的目标。

评估小组提供一个定义软件过程优缺点的结果清单。对于软件过程评估来说，这些结果将成为过程改进的基础和参考；对于软件能力评价来说，这些结果为决策者提供风险分析的技术基础。

评估小组完成KPA基本概况的描述文件，给出组织已经满足的KPA目标和尚未满足的KPA目标。

软件过程评估和软件能力评价之间的不同

软件过程评估和软件能力评价在出发点和目标上是不同的（导致成熟度问卷调查的内容组织不一样，收集的信息不一样，结论的评价不一样）。

软件过程评估是在一个开放的、互相协作的环境下进行的。而软件能力评价往往是在有较大阻力的环境中进行的。（因为过程评估是为了提高管理者和工程师的工作水平，而能力评价是为了表明一个软件组织的实际软件过程能力，为选择承包者和减少费用服务）。

影响CMMI过程改进成败的因素

过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展。

基层技术人员的参与和支持极端重要。

利用定量的可观察数据尽快使过程改进的成果可见，从而激励参与者的兴趣。

按照软件过程改进对企业文化的要求进行变革，要求软件过程改进为商业利益服务，并与企业其他部分协调。

第四节 PSP，TSP与CMMI

CMM/CMMI只关注“做什么”，而不关注“怎么做”，未提供实现各过程域所需要的知识和方法。
为了解决上述问题，CMU-SEI在CMM1.1基础
上提出了PSP/TSP。

PSP的产生

1995年，CMU-SEI的Watts s. Humphrey领导开发出PSP（Personal Software Processes），即个人软件过程，被认为是由定性软件工程走向定量软件工程的标志。

PSP是一种可用于控制、管理和改进软件工程师个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。

PSP关注点

如何制订计划
如何控制质量
如何与其他人相互协作
如何预防缺陷(PSP重点)

关键是如何提高设计质量

PSP中的个人任务

为每一个项目/模块制订开发计划；
记录开发时间；
跟踪错误；
在工程摘要报表中保留数据；
使用已有的数据计划以后的项目/模块；
分析已有的数据以改进开发过程，不断提高开发水平。

PSP的使用效果

参加PSP培训的104位软件人员在应用了PSP后:

软件中总的差错数减少了58.0％；

在测试阶段发现的差错减少了71.9％；

生产效率提高了20.8％

PSP过程改进

PSP0（个人过程基线）

PSP0是过程基线，目的是为了在个人的工作中引入表格和脚本，以便工程师按照测量和报告格式记录软件过程。

PSP0可以通过增加三个过程而扩展到 PSP0.1：

代码规范
代码规模度量
过程优化计划

PSP1（个人计划过程）

PSP1在PSP0的基础上增加了计划步骤：

规模估计：分为代码规模估算、时间估算、资源估算。
状态报告：对软件工程师的工作进行跟踪，检查规模估计与实际状态之间的差异。

PSP1.1又在PSP1的基础上引入了任务计划和安排。

PSP2（个人质量管理）

PSP2强调提高质量，引入了缺陷管理，包含了代码审查和设计审查。

PSP2.1在PSP2.0基础上增加了设计模板。

PSP3（循环个人过程）

PSP3将个人软件过程的应用拓展到大规模程序开发当中。

将开发大型程序的个体过程细分为可以应用PSP2的片段，遵照PSP2过程循环增量地开发大型程序，从而支持迭代式的开发。在任何时间点，只有一个PSP2级过程是活动的。

TSP

软件开发通常是以团队形式进行的，因此仅有PSP是不够的。CMU-SEI又以PSP为基础，开发了TSP（Team Software Processes），即小组软件过程。

TSP指导项目组中的成员如何有效规划和管理所面临的项目开发任务，并且使软件开发队伍始终以最佳状态来完成工作。

TSP实施集体管理与自我管理相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对小组开发过程进行定义、度量和改进。

小组远不只是一群有才能的个人的集合。为了建立并保持高效率的工作关系，小组需要共同的目标，大家一致同意的行动计划和适当的领导，小组成员要在需要的时候乐于寻求帮助。

TSP实施条件

需要有高层主管和各级经理的支持，以取得必要的资源。

整个软件开发小组至少应在CMMI的第二级（已管理级）。

全体软件开发人员必须经过PSP的培训，并有按TSP工作的愿望和热情。

开发小组成员应在2到20个人之间。经验表明，4~8个人的小组工作效率最高。

TSP的管理原则

TSP遵循集体管理和自己管理自己相结合的原则。

在每一项目阶段开始要作好工作计划。
要有明确定义的目标，努力完成已经接受的委托任务。
应定期追踪项目进展状态并进行定期汇报。
按自己管理自己的原则管理软件过程。
按集体管理的原则进行管理，全体成员都要参加和关心小组工作的规划、进展的追踪和决策的制订等项工作。

TSP的循环开发策略

TSP通过循环开发策略完成产品。先在第一个周期中开发出最小的合理产品，再决定在接下来的每一个周期中要加进去的功能。这样的步骤可以保证得到一系列最终产品的可运行的前期版本。每个周期包括7个步骤：决定策略、进行计划、考虑需求、设计、实现、测试和最终检查。

TSP度量要素

对软件开发小组进行度量的基本要素：

所编文档页数；
所编代码行数；
花费在各个开发阶段或各个开发任务上的时间；
在各个开发阶段中注入和改正的差错数目；
在各个阶段对最终产品增加的价值。

TSP有关质量度量的经验原则：

软件设计时间应大于软件实现时间；
设计评审时间至少应占一半以上的设计时间；
代码评审时间应大于编制代码的时间；
每千行源程序在编译阶段发现的差错不应超过10个；
每千行源程序在测试阶段发现的差错不应超过5个。

PSP、TSP与CMMI之间的关系

PSP、 TSP 和CMMI为软件产业提供了一个集成化的、三维的软件过程改进框架。

PSP注重于个人的技能，能够指导软件工程师保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP的学习和实践，软件工程师们能够在他们参与的项目中更为高效和高质量地完成工作，从而保证了项目整体的进度和质量。

TSP注重团队的高效工作和产品交付能力，结合PSP的工程技能，使软件工程师将个体过程结合进小组软件过程，并通过指导管理层如何支持和授权项目小组，坚持团队的高质量的工作，并且依据数据进行项目管理，以达到生产高质量产品的目的。

CMMI注重于组织能力和成熟度的提高，它提供了评价组织的能力、改进组织过程的管理方式，比TSP具有更高的层次。

CMMI关注“做什么”，PSP和TSP则提供了“怎么做”。

本章小结

理解软件过程和过程管理的概念以及两者的联系。
了解CMMI的发展历史。
理解软件过程成熟度概念和CMMI的各成熟度等级的特征。
了解CMMI各成熟度等级上的关键过程域。
理解CMMI的两种应用方式。
了解PSP，TSP的特征以及它们与CMMI的关系。