CMM 软件能力成熟度模型

Capability Maturity Model

3.1 过程改进

质量三角：组织的 Q&P依赖于过程、人和技术三个因素；

过程驱动的两种模式： 目标模式：根据一个预先设定的目标，自顶向下制定过程度量或评价模型，有目的地开展相关改进活动的过程改进模式；

缺陷驱动模式：根据过程实施时所产生的关于过程缺陷的反馈信息，进行有针对性的改进活动；

有效结合。

软件过程成熟度，指一个特定的软件过程被显式定义、管理、度量、控制和执行的程度；

3.2 CMM概述

一个成熟软件组织具有在全组织范围内管理软件、开发过程和维护过程的能力

规定的软件过程被正确无误地通知到所有员工工作活动均按照已规划的过程进行，并通过可控的先导性试验和费效分析使这些过程得到改进

对已定义过程中的所有岗位及其职责都有清楚的描述通过文档与培训使全组织有关人员对已定义的软件过程都有很好的理解，从而使其软件过程所导致的生产率和质量能随时间的推移得到改进。

CMM的诞生

软件管理工程引起广泛注意源于 20世纪 70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现 70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。

到了 20世纪 90年代中期，软件管理工程不善的问题仍然存在，大约只有 10%的项目能够在预定的费用和进度下交付。

软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。

在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。

软件管理工程和其它工程管理相比有其特殊性：

软件是知识产品，进度和质量都难以度量，生产效率也难以保证。

软件系统复杂程度也是超乎想象的。因为软件复杂和难以度量，软件管理工程的发展还很不成熟。

软件管理工程的发展，在经历了从 70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代；

到 90年代中期，以 CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型 CMM、个体软件过程 PSP和群组软件过程 TSP为标志的以过程为中心的时代；

而软件发展第三个时代，及软件工业化生产时代，从 90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，可以实现真正的软件工业化生产。软件生产转向以改善软件过程为中心。

CMM的发展

CMM框架用 5个不断进化的层次来评定软件生产的历史与现状： 初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。

任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这 5个层次中的某一个层次。而在某个层次内部，也有成熟程度的区别。在 CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。

因此，一个软件开发单位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还必须得到保持与发扬。

CMM的一些基本概念（ 1）

软件过程：人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。

软件过程能力：描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。

软件过程性能：表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。

软件过程成熟：一个特定软件过程被明确和有效地定义，管理测量和控制的程度。

CMM的一些基本概念（ 2）

软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。

关键过程域：每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域，是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。　

CMM的一些基本概念（ 3）

关键实践：对关键过程域的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述“做什么”而不强制规定“如何做”。整个软件过程的改进是基于许多小的、渐进的步骤，而不是通过一次革命性的创新来实现的，这些小的渐进步骤就是通过一些着关键实践来实现。

软件能力成熟度模型：随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力也伴随着这些阶段逐步前进，完成对软件组织进化阶段的描述模型。

CMM五级模型 (1)

第一级：初始级 

　　在初始级，企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。 

　　

CMM五级模型 (2)

第二级：可重复级 

　　在这一级，建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。 

CMM五级模型 (3)

　　第三级：定义级 

　　在这一级，有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。 

CMM五级模型 (4)

　　第四级：定量管理级 

　　在这一级，企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案， 要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。 

CMM五级模型 (5)

　第五级：（不断）优化级 

　　在这个等级，整个企业将会把重点放在对过程进行不断的优化。企业会采取，以达到预防缺陷 的目标。同时，分析主动去找出过程的弱点与长处有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。 

CMM等级模型图

CMM的作用：科学地评价软件开发单位的软件能力成熟等级；

帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。 

CMM的意义

迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的软件过程。

为评估软件组织的生产能力提供了标准。

为提高软件组织的生产过程指明了方向。 

CMM 和 ISO9001的比较

CMM专为软件企业定制，而 ISO适用于各行各业

ISO9001确定了一个质量体系的最少要求 CMM明确强调持续的过程改进 既有联系又有区别 最重要的是保证企业产品质量并不断改进和提高

链接 1：解析 CMM和中国软件

有意向中国软件公司发包的外商最关心的是两个事情：一个是对知识产权的保护，另一个则是人力资源上是否具备和甲方进行有效沟通的能力。

关于开发的管理，有外商认为，如果在美国，一个企业如果拿出任何能够证明其公司管理能力的资料，他都不会有任何怀疑，而在中国： "No ， I only believe my eyes!"

所谓软件外包就是一些发达国家的软件公司将他们的一些非核心的软件项目通过外包的形式交给人力资源成本相对较低的国家的公司开发，以达到降低软件开发成本的目的。众所周知，软件开发的成本中 70%是人力资源成本，所以，降低人力资源成本将有效地降低软件开发的成本。 

软件外包已经成为发达国家的软件公司降低成本的一种重要的手段。目前，全球软件的销售额为 6,000亿美元，而其中软件外包的销售额即达到 500 ～ 600亿美元。预期到 2005年软件外包的销售额将达到 1,000亿美元。软件外包的大幅度增长为人力资源成本相对较低的印度和中国带来了新的发展机会。 

中国目前已经有不少的公司开始介入软件外包这一领域。目前软件外包产业较为发达的地区有上海、北京、大连以及深圳等城市。以北京为例，有 40%的软件企业参与外包项目，软件行业 60% ～ 70%的营业额来自外包。在上海和北京，一个软件外包工程师的月薪达到 7,000 ～ 10,000元人民币，而同样能力的软件工程师在武汉只需要三～四千元人民币。资本的特征是向成本更低的地方流动，所以，近一段时间以来已经有大量的东部软件公司准备迁移到中部地区，目前首选的地区主要是武汉和西安。

CMM/CMMI本身是一套非常有价值的过程模型，但简单的将其图腾化却是整个中国软件行业的悲哀，反观CMM/CMMI的发源地——美国，除了和军方有业务往来的软件企业会寻求通过 CMM/CMMI评审外，其他多数的企业并不怎么在乎是通过了 CMM/CMMI的三级还是四级，象是著名的微软、甲骨文等知名企业都没听说过和 CMM/CMMI沾过边，但这也丝毫不影响以他们为代表的美国软件企业在整个行业中独领风骚。

只有有效的而不是最权威的，才是最好的。

链接 2 ： CMM/CMMI不是软件企业唯一的选项

CMM/CMMI来到中国已经变质。只要花钱，只要招待，你就可能拿到一张证书。虽然拿到了这个证书，但是软件企业并没有得到什么实惠。

举例说来，软件企业的效率、过程的能力仍然是跟以前一样，因为CMM/CMMI在做的同时，他们仍然在按照原来的方法在做，原来的体制在运行。

一边按照 CMM/CMMI做各种需要的文档，一边还在按照老传统做什么调研、方案设计、调试，跟 CMM/CMMI并不合拍。

CMM/CMMI是一个评估的依据，也是一个过程改进的框架，并不是一个标准。

链接 3：软件市场的通行证—— CMM

世界上第一家通过 CMM5认证的并非美国公司，而是来自印度的WIPRO。同时，WIPRO还是全球第一个通过人力成熟度模型（ PCMM ） 5级认证的软件及服务公司。

据 SEI统计，目前有大约 300家印度软件公司通过了 CMM认证，其中通过最高质量等级CMM5的有 50余家，占全球的 60%以上。高品质的管理决定了高品质的产品，从而也确立了印度在美国外包市场的垄断地位。

为增强自身实力，积极参与国际竞争，国内软件企业把资质认证也提上了日程。我国政府明确表示鼓励软件出口型企业通过 CMM认证。各地方政府也制定了相应的政策，如上海市就规定对在本市注册并通过 CMM3~5认证的企业可以分别获得 40万、 60万和 80万元人民币资助。

获得了 CMM认证就获得了迈向国际市场的“通行证”。IDG统计数据显示，目前全球软件外包市场规模已达到1000亿美元。中国拥有软件企业近 9000家。

链接 4：微软解决方案框架MSF 与 CMM

微软成功的实践经验：  每天都保持出货状态使用一对一的测试人员建立特性小组使用有缓冲的多个开发周期建立固定的出货日期增量式开发软件分享经验教训

应用MSF 开发观念与原则：并不需要强制执行统一的过程，相反，每个产品组都需要通过吸收学习当前成功的实践经验来发展自己的合理的开发过程。

组成企业结构原则：商业结构，应用结构，技术结构，信息结构应用开发原则：组队模型，开发模型，风险管理组件设计原则：概念设计，逻辑设计，物理设计基础开发原则：组队模型，开发模型，风险管理

MSF组队模型

 

                                                                          

MSF过程模型

MSF内部发布里程碑

链接 5 ： CMM在对日软件开发中的应用

遗留缺陷率

无缺陷比率

无缺陷比率是在给定的阶段内没有缺陷的产品部件所占的百分比。

链接 6 ： CMMI成功案例

每日培训——华微软件的培训制度http://tech.sina.com.cn/it/2006-05-30/1013964757.shtml

链接 7：选择 CMM还是 CMMI

CMMI的全称为： Capability Maturity Model Integration，即能力成熟度模型集成。  主要基于以下几个方面进行考虑：  实施企业的业务特点： 如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件 CMM比较适用。如果企业的规模比较大（开发人员 100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。 

实施企业对过程改进的熟悉程度： 如果企业已经实施过 ISO 9000，并且取得了较好的效果，那么可以考虑实施 CMMI。如果企业虽然没有实施过 CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施 CMMI。如果过去没有接触过类似的工作，那么最好先从软件 CMM 2级开始，首先建立持续过程改进的思路。另外，软件 CMM的要求也比 CMMI要稍低一些。可以适当降低实施的难度。 

实施企业对过程改进项目的预算： 不论怎样，几乎可以肯定地说，实施 CMMI的费用肯定要比实施 CMM高出一些。而就模型本身来看， CMMI 的 2 级 7个过程区域在内容上并不比软件 CMM 的 2 级 6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用 CMM的实施和评估方法，但可以在过程改进的时候参考 CMMI的要求，这样就经济很多。

PSP 个体软件过程

Personal Software Process

PSP概述 1995 年推出，是由定向软件工程走向定量软件工程的标志。 是一种用于控制、管理和改进个人工作方式的自我改善过

程，是一个包括软件开发表格、指南和规程的结构化框架。

为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。

在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。

绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。

PSP保障软件产品质量的一个重要途径是提高设计质量。

PSP 的演化

PSP的内容

PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。 PSP能够：(1) 说明个体软件过程的原则；(2) 帮助软件工程师作出准确的计划；(3) 确定软件工程师为改善产品质量要采取的步骤；(4) 建立度量个体软件过程改善的基准；(5) 确定过程的改变对软件工程师能力的影响。

PSP的作用

使用自底向上的方法来改进过程，向每个软件工程师表明过程改进的原则，使他们能够明白如何有效地生产出高质量的软件。

为基于个体和小型群组软件过程的优化提供了具体而有效的途径。其研究与实践填补了 CMM的空白。

帮助软件工程师在个人的基础上运用过程的原则，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的评估、计划和预测更加准确、更加有效，进而改进个人的工作表现，提高个人的工作质量和产量，积极而有效地参与高级管理人员和过程人员推动的组织范围的软件工程过程改进。

PSP举例

过程缺陷的记录，要求软件工程师按一定方式记录他们注入软件中的缺陷及其可能的改进方法

代码长度估算，要求软件工程师预测所写的模块或算法的可能长度

代码时间估算，例如，时间估算是 5-10-20， 5代表乐观时间， 10代表可能时间，而 20代表悲观时间，使用这三种时间，再用一定的方法计算出平均估算时间

链接 8 ： PSP －塑造世界一流的专业软件工程师

Watts Humphrey 作为 8000个工程师的编码主管，在 IBM长达 27年的工作期间，亲身经历过无数次软件项目开发的成功与失败，总结出一系列宝贵经验。

在 美国国防部的赞助下，他 于  1986年开始研究并于 1991年提出能力成熟度模型 CMM，为软件过程改进制定了基本框架。

Humphrey 在 1994年推出了个体软件过程 (Personal Software Process ， PSP)和群组软件过程（ Team Software Process, TSP）。

虽然 PSP/TSP在国外许多大中型软件企业得到了广泛应用，并取得了令人瞩目的成效，但在我国还属于刚刚起步。

PSP－提倡以人为本 多数软件工程师总喜欢把自己当作精英，崇尚个人主义，以编码速度快而自傲。管理人员进行项目管理时，往往会采用统一死板的模式，将规定强加于工程师身上，效果不佳。  PSP过程改进正是针对这一情况，采用以人为本的方针，以自身为出发点，从本人做起。工程师根据自身的情况，亲自搜集有关本人的开发数据，基于这些来制订最适合自己的改进目标和具体的改进措施，并实行自我监督。自觉地、不断地改进和提高。从理论上讲，这种策略最有实效，易于接受。

PSP－使您成为一名更好的专业软件工程师 培训就是给开发人员补课，让他（她）们掌握软件过程管理和项目管理方面最先进的技能和最佳的实践，包括：精确地估算软件规模大小 ；合理安排自己的项目开发时间；以时间和规模为根据合理地规划项目，准确地预计工期； 减少产品缺陷； 度量和跟踪自己的绩效；使用挣值法跟踪进度；兑现自己所做的承诺；抵制不合理的承诺压力；收集数据来持续地提高自己的生产率、软件质量、以及工期预测能力；客观地发现自己的薄弱环节并及时进行改进提高等。

PSP 不仅帮助开发人员提高编码水准，还指导开发人员更好地进行需求或过程定义、评审、测试、文档编写等。

TSP 群组软件过程

Team Software Process

什么是 TSP

规划和管理小组项目小组中已分配不同角色，每个角色有明确的目标，各司其职。

在整个开发过程中明确每一个步骤应该做什么。

群组是什么？

至少 2 个人，为共同目标和任务而工作 ,每个人都有自己的角色和职责，要通过合作来完成任务。

更高的境界： 自始至终对项目有控制 知道该做什么，怎么做，何时做，何时完成。 整体实力大于个人实力之和。 成员可以从合作中得到合作的乐趣。

TSP的管理团队组合

组长：运行一个有效的团队。 开发经理：生产一个功能强大的高质量的产品，全面发挥小组成员能力和才干。

计划经理：详细计划，每周准确报道小组状况。 质量生产经理：保证生产出没有缺陷的稳定的产品。

技术支持经理：保证整个过程得到适当的支持。

TSP 的 7条原则：

1 提供一个简单的框架，每个人在其中各司其职。

2 把产品的开发分为多个周期。 3 建立标准的评估机制。 4 对小组和组员有准确的评价。 5 采用针对角色和小组的评估。 6 开发过程中强调纪律性。 7 有人提供关于小组协同工作的问题的指导。

链接 9 ： Google小组研发模式分析

GOOGLE和其他大公司采用不同的研发模式，其研发模式是小组开发。这个研发模式可以说是 GOOGLE目前最大的核心竞争力。这种研发模式诱发了不断的创新。但是很明显的一点是：这种研发模式只是适用于现阶段 GOOGLE的模式，最终这种模式会被其他研发模式取代。 

在 Google有个「点子库」，每个人都可以抛出新点子，让大家「用脚」投票，即让认同且愿意加入开发的人很快聚集，并一起落实这个点子。因此一个可行的新点子，从发想到完成只需六个月，而且常常两三人就能完成；反之，不可行的点子，大家也会提供建议，因此不会有无谓的浪费。此外， Google让每人享有 20%的时间，做自己想到的点子，一旦成熟，就可以成为公司的指定任务， 80%的时间就可以用来处理它。

总结：  小组开发模式； 研究和开发一体，都在小组这个级别内完成； 创意共享机制； 组内竞争机制； 内部创业模式（某些受欢迎的项目会获得创始人奖，获得数额不菲的奖金）；

小组研发模式的特点分析 优点： a.小组内人员比较少，沟通成本低，所以能够快速开发产品； b.小组之间形成内部竞争局面，优胜劣汰机制，适者生存；有利于公司内部人员潜力的发挥；

c.内部创业机制，有利于最大的发挥技术人员的积极性，使得优秀人才留在公司而不是选择自行创业；

d.多开发小组导致新的创意多，创新的速度和广度得到保证； e.小组内研究和开发一体，减少了研究和开发两层皮的矛盾；

缺点： a. 对人才素质要求比较高：技术人员既要有研究人员的学术素养又要求有开发人员的动手能力，还要有一定的市场敏感度；

b. 从长期看难以形成专业性人才培养机制；现有培养机制是培养全才型人才，包括市场敏感度，学术素养和快速开发能力；从公司的视角来看，这种人才对于公司创造价值来说，其长期竞争力未必能比专业化分工的人员竞争力强。

将来的趋势  GOOGLE开发模式必将被其他研发模式代替 1 ） GOOGLE小组开发模式对于人员要求高，满足

GOOGLE开发模式的人员在初期能够比较容易从就业市场找到并用优厚的条件吸引进入 GOOGLE,随着GOOGLE的快速扩张和市场竞争的加剧，满足条件的人员会越来越少，但是扩张要求又是势在必行，必须满足的； 所以会有越来越多相对较低素质的人员进入。这种人员构成的变化导致其开发模式会发生转换。

2）随着各大公司都开始进入并争夺搜索市场， GOOGLE为了保持其竞争优势必将业务集中。业务集中后，对于创新的广度要求降低（核心业务关系不大的创新不再得到支持），很多小组开发的优势不复存在，其开发模式将不再适合其发展。这种模式会被新模式取代。

最有可能转换的模式： 研究院 +产品开发 模式  GOOGLE小组模式其实培养的是创业型的人才和团队架构，所以 GOOGLE现有开发人员的期权或者股票兑现之后（或者 GOOGLE股票大跌后），总之就是创业带来的利益大于继续留在GOOGLE的收益这个条件成熟，大量开发小组人员会离开 GOOGLE自己创业，而且可能会寻找 同一开发小组的同事共同创业，这将会出现大量技术型的新创公司，未来的对 GOOGLE形成挑战的很可能就在这些人中出现。

CMM/TSP/PSP体系

软件开发与管理的最佳方式

CMM/TSP/PSP对软件过程的意义

CMM/TSP/PSP的一些建议

必须根据自身的实际制定可行的方案。

以 CMM为框架，先从 PSP做起，在此基础上逐渐过渡到TSP。

有一个循序渐进的过程，是持续改善 。

自顶向下的课程培训，即从高层主管开始普及到下面的工程师。

最终目标是改善软件过程，提高软件质量。

参考网址：

http://www.uml.org.cn/cmm/cmm.asp#4