什么是CMM

来源：互联网发布：防御矩阵技能编辑：程序博客网时间：2024/06/07 03:44

CMM综述

CMM(Capability Maturity Model能力成熟度模型)的本质是软件管理工程的一个部分。它是对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。他通过5个不断进化的层次来评定软件生产的历史与现状。

CMM的诞生

信息时代，软件质量的重要性越来越为人们所认识。软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。而软件工程领域在1992年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。

软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件管理工程的意义至关重要。

软件管理工程和其它工程管理相比有其特殊性。首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统复杂程度也是超乎想象的。因为软件复杂和难以度量，软件管理工程的发展还很不成熟。

软件管理工程的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。

软件过程改善是当前软件管理工程的核心问题。50多年来计算事业的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。软件管理工程走过了一条从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试到90年代中期以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心向着软件过程技术的成熟和面向对象技术、构件技术的发展为基础的真正软件工业化生产的道路。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。软件工业已经或正在经历着"软件过程的成熟化"，并向"软件的工业化"渐进过渡。规范的软件过程是软件工业化的必要条件。

软件过程研究的是如何将人员、技术和工具等组织起来，通过有效的管理手段，提高软件生产的效率，保证软件产品的质量。由此诞生了软件过程的三个流派：CMU-SEI的CMM/PSP/TSP；ISO 9000质量标准体系；ISO/IEC 15504（SPICE）。

CMM/PSP/TSP即软件能力成熟度模型/ 个体软件过程/群组软件过程，是1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法"；SO 9000质量标准体系是在70年代由欧洲首先采用的，其后在美国和世界其他地区也迅速地发展起来。目前，欧洲联合会积极促进软件质量的制度化，提出了如下ISO9000软件标准系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年国际标准化组织采纳了一项动议，开展调查研究，按照CMU-SEI的基本思路，产生的技术报告ISO/IEC 15504--信息技术软件过程评估

目前，学术界和工业界公认美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发的软件能力成熟度模型CMM是当前最好的软件过程，已成为业界事实上的软件过程的工业标准。

CMM的发展

1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表了CMM/PSP/TSP 技术，为软件管理工程开辟了一条新的途经。

CMM框架用5个不断进化的层次来评定软件生产的历史与现状：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。而在某个层次内部，也有成熟程度的区别。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还必须得到保持与发扬。

软件产品质量在很大程度上取决于构筑软件时所使用的软件开发和维护过程的质量。软件过程是人员密集和设计密集的作业过程：若缺乏有素训练，就难以建立起支持实现成功是软件过程的基础，改进工作亦将难以取得成效。CMM描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的途径。

CMM包括两部分"软件能力成熟度模型"和"能力成熟度模型的关键惯例"。"软件能力成熟度模型"主要是描述此模型的结构，并且给出该模型的基本构件的定义。"能力成熟度模型的关键惯例"详细描述了每个"关键过程方面"涉及的"关键惯例"。这里"关键过程方面"是指一组相关联的活动；每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。而"关键惯例"是指使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动,对关键过程的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述"做什么"而不强制规定"如何做"。各个关键惯例按每个关键过程方面的5个"公共特性"（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程）归类，逐一详细描述。当作到了某个关键过程的的全部关键惯例就认为实现了该关键过程，实现了某成熟度级及其以低级所含的全部关键过程就认为达到到了了该级。图一 CMM关系描述图
　　
上面提到了CMM把软件开发组织的能力成熟度分为5个的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。图二 CMM等级模型图

对于CMM的作用归纳两个主要方面: 科学地评价软件开发单位的软件能力成熟等级; 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。

由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能，因此，美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发了个体软件过程PSP（Personal software process）和群组软件过程TSP(Team Software Process)，形成CMM/PSP/TSP体系。

PSP 个体软件过程（Personal Software Process）是由美国Carnegie Mellon大学软件工程研究所(CMU/SEI)的Watts s. Humphrey领导开发的，于1995年它的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP是一种可用于控制、管理和改进个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。 PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。PSP保障软件产品质量的一个重要途径是提高设计质量。

PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。

TSP　群组软件过程TSP(Team Software Process)指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

TSP致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。图三 CMM、PSP和TSP框架图

CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训,合理分配项目人员,并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。

PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。

TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与　组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项　目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。

总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。

实施CMM的必要性

软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。

软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。

实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(RE：REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SR：SOFTWARE REUSE)。定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

CMM与ISO 9001的比较

前面提到软件过程的三个流派：CMU-SEI的CMM/PSP/TSP；ISO 9000质量标准体系；ISO/IEC 15504（SPICE）。这里主要比较一下CMM和ISO 9000质量标准体系中的9001的异同。

ISO 9000族国际标准是在总结了英国的国家标准基础之上产生的，因此，欧洲通过ISO 9000认证的企业数量最多，约占全世界的一半以上。受此影响，相当多的欧洲软件企业选择了ISO 9001认证。

在基本原理方面，ISO 9001和CMM都十分关注软件产品质量和过程改进。尤其是ISO 9000:2000版标准增加持续改进、质量目标的量化等方面的要求后，在基本思路上和CMM更加接近。它们之间的主要的差别是状态上的差别。ISO 9001侧重于"机构保证在设计、开发、生产、安装及服务过程中与指定的要求一致"。而CMM侧重于"支持一个机构评估及改进他们的系统的工程能力"及"指出机构选择的模型的不足之处"。

CMM和ISO 9001阐述了一个机构应该将他们如何做的观点写下来，然后去做，最后检查他们是否按照他们说的去做了。ISO 9001所关注意的是确保合格的人员所作的过程记录是有效的，并且开发生产出满足质量要求的产品。CMM在能力层次概念之间切开，作一件事情是第1级层次的概念，写下所做的事情是第2级层次的概念，有一定组织水平的写作是第三级层次的概念，等等。SE-CMM同样衡量管理能力，如第四级层次，连续处理问题的能力，第五级层次的概念。

这两个标准都涉及了产品的开发和产品的质量，但CMM在产品的设计和开发的细节作了较多要求，而ISO 9001在产品的开发过程和产品本身的质量细节作了较多要求。CMM 建立了系统工程能力模型第三级模型，而ISO 9001则无此内容。CMM没有对产品存储设备的测试作出要求，而ISO 9001则有此要求。

ISO 9001要求与质量管理体系相关的所有工作人员的经过授权并签字的质量记录（见条款4.1.2.1）。它还要求足够的资源，包括提供必要的员工培训等（见条款4.1.2.2）。第四节要求对机构的每个过程都要有记录。这是SE-CMM第2级的基本要求。从ISO 9001的角度来看SE-CMM，至少SE-CMM的第二级及以上级别才能和ISO 9001相提并论。

由以上可以得出ISO 9001和CMM既有区别又相互联系，两者不可简单的互相替代;取得ISO 9001认证并不意味着完全满足CMM某个等级的要求 ;取得CMM第2级(或第3级)不能笼统的谈可以满足ISO 9001的要求。　

CMM在中国的现状

中国生产力促进协会、北航SEI、中科院研究SEI等科研机构已于近几年在北京、上海、广州和深圳等地先后举办过多次报告会和研讨会，组织过课程学习和应用实验，开展了软件过程方面的研究与开发工作，并发表了多篇的研究成果和学术论文，在软件质量保障平台支撑环境也取得了一定的成果。

近两年来，CMM在我国获得了各界越来越多关注，业界有过多次关于CMM的讨论，2000年6月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持和推动作用,第17条规定"对软件出口型企业CMM认证费用予以适当支持。"2000年中国村电脑节上还有CMM专题论坛，吸引了众多业内人士。鼎新、东大阿尔派、联想、方正、金蝶、用友、浪潮、创智、华为、东大阿尔派等大型集团或企业等都从1997---2000年起批企业都在进行研究、实验或实施预评估。其中鼎新公司从1997年着手进行CMM认证工作。1999年7月通过第三方认证机构的CMM2认证。东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证。2001年1月，联想软件经过英国路透集团的严格评估，顺利通过CMM2认证。2001年6月26日，沈阳东软软件股份有限公司（原沈阳东大阿尔派软件股份有限公司）正式通过了CMM3级认证，成为中国首家通过CMM3级的软件企业。

总体上讲，国内对软件过程理论的讨论与实践正在展开，目标是使软件的质量管理和控制达到国际先进水平，中国的软件产业获得可持续发展的能力。专家分析，在未来两三年内，国内软件业势必将出现实施CMM的高潮。从这一趋势看，中国的软件企业已经开始走上标准化、规范化、国际化的发展道路，中国软件业已经面临一个整体突破的时代。

但是我们应该看到目前国内对软件管理工程存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。而且软件过程的重大修改也必须由高层管理部门启动，这是软件过程改善能否进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与。

除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。过程改善工作需要循序渐进，不能一蹴而就，需要持续改善，不能停滞不前；需要联系实际，不能照本宣科；需要适应变革，不能凝固不变。一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。

CMM实施的思考

上面重点介绍了CMM,但是提醒注意的是，并不是实施了CMM，软件项目的质量就能有所保障。CMM是一种资质认证，它可以证明一个软件企业对整个软件开发过程的控制能力。按照CMM的思想进行管理与通过CMM认证并不能划等号。CMM认证并不仅仅是在评估软件企业的生产能力，整个评估过程同时还在帮助企业完善已经按照CMM建立的科学工作流程，发现企业在软件质量、生产进度以及成本控制等方面可能存在的问题，并且及时予以纠正。认证的过程是纠正企业偏差的过程，一定不能把CMM认证当作一种考试、一种文凭，而是要看成一项有利于企业今后发展的投资，借此来改变中国软件业长久以来形成的积弊。

实施CMM对软件企业的发展起着至关重要的作用，CMM过程本身就是对软件企业发展历程的一个完整而准确的描述，企业通过实施CMM，可以更好地规范软件生产和管理流程，使企业组织规范化。企业通过CMM不是为了满足其他公司的要求，而是为了让企业更好地发展，为企业进一步扩大规模打下坚实的基础。如果企业只是为了获得一纸证书而通过CMM，那么就已经本末倒置了，对企业的长久发展反而有害。试想如果企业的态度不够端正，即使通过CMM认证，企业又怎么能够保证它在以后的操作过程当中继续坚持CMM规范呢？CMM只是一个让企业更好发展的规范，不应该成为企业炒作自己的工具，企业需要的是优化自己的管理、提高产品的质量，而非一张CMM证书。

CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。在国内要想取得过程改进成功，必须做好以下的几点:软件过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展;中层管理的积极支持;责任分明，过程改进小组的威望高;基层的支持与参与极端重要;利用定量的可观察数据，尽快使过程改进成果可见，从而激励参与者的兴趣;将实施CMM与实施PSP和TSP有机地结合起来;为企业的商业利益服务，并要求同时相符的企业文化变革。

应该看到,过程改善工作必然具有一切过程所具有的固有特征，即需要循序渐进，不能一蹴而就需要持续改善，不能停滞不前；需要联系实际，不能照本宣读需要适应变革，不能凝固不变。将CMM／PSP／TSP引人软件企业最有效的途径首先要对单位主管和主要开发人员进行系统的培训。另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。培训包括最基本的软件工程和CMM培训知识；专业领域知识等方面的培训；软件过程方面的培训。不过强调一点，我们必须根据自身的实际制定可行的方案。不深入研究就照搬别的企业的模式是很难起到提高软件产品质量水平的真正目的的。

CMM模型划分为5个级别，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级的评估周期（从准备到完成）约需12-30个月。此期间应抽调企业中有管理能力、组织能力和软件开发能力的骨干人员,成立专门的CMM实施领导小组或专门的机构。同时设立软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。各个小组完成自己的任务同时协调其他小组的工作。然后制定和完善软件过程, 按照CMM规范评估这个过程。CMM正式评估由CMU/SEI授权的主任评估师领导一个评审小组进行，评估过程包括员工培训、问卷调查和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等，评估结束时由主任评估师签字生效。此后最关键的就是根据评估结果改进软件过程,使CMM评估对于软件过程改进所应具有的作用得到最好的发挥。

现在国内软件产业的发展可以说已经具有一定规模了，但除了北大方正、东大阿尔派、用友等大企业外，做软件工程项目更多的是一些规模在数十人左右的中小企业, 目前处于CMM的初级阶段，没有基础和经验。也许有人会问，像这样一些人力物力资源匮乏的企业，如何进行软件开发项目的管理呢？我建议这些中小企业可以以CMM为框架，先从PSP做起，然后在些基础上逐渐过渡到TSP，以保证CMM/PSP/TSP确实在企业中生根开花。总之，我们必须从软件过程、过程工程的角度来看待CMM的发展，从经济学的观点来分析这个过程的价值。我相信在实施CMM/PSP/TSP的过程中，只要坚持改善软件工程的管理，并在实践中注意总结适合自身的经验，一定能取得很好的效果。

===================================================================================

CMM与质量管理

一、CMM的产生

软件能力成熟度（the Capability Maturity Model for Software, 简称CMM）是美国软件工程研究所（Software Engineering Institute, 缩写为SEI）首先提出的。SEI是美国国防部设立，SEI的任务是提供一系列技术管理方法来提高软件工程水平，保证美国防部能够通过成本、进度和质量的预估和改进获得并且支持其精准的软件系统。

任务包含四个目标：

1、通过对实践和技术（或为未充分应用的技术和实践）的定义、评估和成熟预测，以加快导入和推广高成效的软件工程的实践和技术。

2、在软件工程和技术转型方面维护一个长期有效的资格认证工作

3、使工业和政府组织通过自己的直接努力实现软件工程的有规划的改进

4、促进软件工程持续不断的应用所采纳的优秀标准

二、CMM的管理思想基础

CMM的基本思想是基于已有60多年历史的产品质量原理。休哈特（Walter Shewart）在30年代发表了统计质量控制原理，戴明（W.Edwards）和朱兰（Joseph Juran）的关于质量的著作又进一步发展和论证了该原理。实际上，将质量原理变为成熟度框架的思想是克劳斯比(Philip Crosby)，他在著作《质量免费》（Quality is Free）中首先提出，他的质量管理成熟度网络描绘了采用质量实践时的5个进化阶段，而该框架后来又由IBM的拉迪斯（Rom Radice）和他的同事们在汉弗莱(Watts Humphrey)指导下进一步改进以适应软件过程的需要。1986年，汉弗莱将此成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，形成了当前软件产业界正在使用的框架。

汉弗莱的成熟度框架早期版本发表在1987年的SEI技术报告。该报告中还发表了初步的成熟度提问单，这个提问单作为工具给软件组织提供了软件过程评估的一种方法。1987年又进一步研制了软件过程评估和软件能力评价两种方法，以便估计软件过程成熟度。自1990年以来，SEI基于几年来将框架运用到软件过程改进方面的经验，进一步扩展和精炼了该模型，目前，软件能力成熟度模型2.0版已经修订问世。

然而企业最终目的是把自己的产品或服务提供给顾客，让顾客满意，尽力使这个过程不断反复、且能够不断壮大，才能源源不断创造利润。所以，我们应该明白：

第一、企业的使命是为顾客创造价值，努力地为顾客创造价值就是企业的成功之路。

第二、能为顾客带来价值的是企业的各种作业。而一个作业是由一系列能为顾客创造价值的活动组成的，构成一个作业的各种活动是由员工完成的，但是各种活动本身对顾客来说毫无意义，顾客关心的是这些活动的结果。也就是说，只有各种活动组合在一起构成一个完整的作业才能创造价值，顾客并不关心怎样组合这些活动。因此，出于对顾客利益的考虑，作业的构造要努力做到“复杂其中，简便其表”。

第三、企业事业的成功来自优异的作业绩效。尽管优质的产品或服务、杰出的人才和优秀的战略对企业来说必不可少，但并不能保证企业的成功。因为，产品或服务、人才和战略只有存在于能为顾客带来价值的各种作业之中，才能对企业事业的成功有所贡献。也就是说，只有通过作业把这些高质量的要素结合在一起，它们才具有实质性的意义。这种高绩效的作业，则是企业优势的集中体现。

第四，优异的作业绩效是通过科学的作业设计、适当的人员配置和良好的工作环境的共同作用达到的。因为，科学的作业设计能够灵敏地对顾客的需求变化做出反应，它是作业本身有效性的根本保证；适当的人员组合能获得集体智慧和战斗力；良好的环境则能激发员工的工作热情，促使员工它们不断超越自己。对于软件企业来说，它的成功来自优异的软件开发过程，要想取得优异的软件开发过程，就得按照以上四点要求进行管理和改进软件企业过程。所以，可以认为CMM模型其实质就是一种新兴的管理思想和方法，它蕴涵的是当今欧美乃至日本日趋盛行的“Continuos Improvement”管理哲学，现已渗透到各行各业的具体管理中去，是现代企业管理发展方向之一。

连续改进（Continuos Improvement）的含义是：以超前的视野预见过程执行实施中可能的引起要素（包括特定的设计、作业方式及其与之相联系的成本要素），籍先期规范制约的各种手段作出最大可能效果创出（最优成本/效益比）的预期调整，并以相应的效果计量和评估方法相配合，以确保实际过程以预期的低成本运作的先导式控制。我个人认为，着眼于软件过程的CMM是连续改进的表现，而着重于软件过程评估和软件能力评价与改进相呼应，CMM模型中蕴涵的思想就是防止项目失败的思想，也就是我们所说的连续改进的思想所在。

三、连续改进（Continuos Improvement）

虽然软件工程师和管理人员通常详尽地知道他们的问题所在，但是哪些改进是当前最重要的问题，他们可能彼此有不同的意见。而且缺乏一个组织的改进策略，管理人员和专业人员之间在首先采取什么改进措施上很难达成一致意见。经过深入的调查和研究，终于认识到软件过程的改进不可能一朝一夕就能成功，需要持续不断的进行软件过程改进，软件过程改进是在一系列微小、不断发展的，而不是革命性的创新步骤中实现的。这正是连续改进思想的体现。

当同类事物之间存在着微少差异时就会产生变异性。当一个过程或系统的资源存在着变异性时，相应的系统输出也会有变异性。例如，当原材料或所制造的部件质量有偏差时，最终产品的质量也会发生变化。正所谓“进废品，出废品”。所以，研究连续改进，就需要关注系统所使用资源的变异性及所采用生产过程的变异性。任何系统都会表现出变异性。一定程度的变异是自然的，这种变异并不一定意味着系统不稳定或质量低劣或成本偏高，但是太多的或反常的变异则表明系统不稳定——其输出的质量是不一致或不可预知的。这对于任何一个公司都是一种危险的情况，因为不稳定的质量将会影响顾客的满意度。要保持客户的满意，必须改进产品质量、降低产品的成本、增强产品的营销水平。要改进产品质量、降低产品的成本、增强产品的营销水平，必须减少系统的变异。研究连续改进过程就是明确系统中的变异在哪里发生，为什么发生。一旦了解到引起变异的原因，就可以寻找一些方法去减少这种变异，以稳定企业运行过程，使企业得到改进。

1、连续改进循环

如果只解决一个小问题，只稍微改变一下具体过程，而后就置之不理直到问题出现，这是远远不够的。正如“连续改进”这一名称所暗示的：必须不断进行。连续改进意味着时常对系统进行分析，一丝不苟地收集数据并加以研究，一丝不苟地测试偏差，每位公司员工都把连续改进作为其工作的一部分看待。持续改进应该视为一个循环。参与持续改进的各团队需要长期连续地在这个循环中活动。也就是说，当一个问题看来已经解决之时，而员工的参与并没有终结，仍然有另一个改进要实施，有另一个系统要分析，或有另一个创意要专题研究。

2、强化过程改进

面临的下一步是使实施的变革成为系统的一个标准部分。团队应该着手出一份简单的报告，说明测试过程中的新规则以及所做改进对系统的影响。报告要列出变革后的优点，包括新系统实施和维护的计划，以确定新系统达到新的绩效水平。如果团队的建议被管理者接受并付诸实施，以后，团队需要按照计划监视系统。你将能指出存在的问题，发现在什么地方工作人员又回到了旧的工作方式。这一步的目标是使新过程变成标准的操作规则。切记，在实施变革过程中，认真地培训和支持是必要的。

3、继续连续改进循环

当你确信新的过程得到强化并成为工作过程的一个自然组成部分时，就要准备开始下一个持续改进循环。你将要从分析系统开始，因为上一循环的变革可能已经改变。

4、总结

企业的管理者一定明白企业的生存取决于你比其它企业给顾客提供更好服务的能力。通过更快地响应顾客的需要，提供更高质量的服务就可以达到生存的目标。一旦你和你的员工进入持续改进循环，你将拥有更好的信息、更新鲜的创意、更好的过程和质量控制，你将达到梦想的“意想不到的高水平的绩效”。

============================================================================

CMM简介二

CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。

CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

 CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的，是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。目前，我国已有软件企业通过了CMM标准认证。 

SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型,以下简称"CMM"),是87年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。

CMM目前通用流行的版本是1．1（Version1．1）。《按照软件工程研究所（SEI）的原来计划，CMM的改进版版本2．0（V2．0）是要在1997年的11月完成的。但是，美国国防部办公室要求软件工程研究所（SEI）延迟发放公布CMM版本2．0，直至他们完成另一个更为紧迫的项目-CMMI。

CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美国国防部的一个设想。他们希望把所有现存的与将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架用于解决两个问题：第一，软件获取办法的改革；第二，从集成产品与过程发展的角度出发,建立一种包含健全的系统开发原则的过程改进。

CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。

一、CMM的诞生

二、CMM的发展

　　1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表了CMM/PSP/TSP 技术，为软件管理工程开辟了一条新的途经。

　　
　　上面提到了CMM把软件开发组织的能力成熟度分为5个的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。

能力等级	特点	关键过程
第一级基本级	软件过程是混乱无序的,对过程几乎没有定义,成功依靠的是个人的才能和经验,管理方式属于反应式
第二级重复级	建立了基本的项目管理来跟踪进度.费用和功能特征,制定了必要的项目管理,能够利用以前类似的项目应用取得成功	需求管理,项目计划,项目跟踪和监控,软件子合同管理,软件配置管理,软件质量保障
第三级确定级	已经将软件管理和过程文档化,标准化,同时综合成该组织的标准软件过程,所有的软件开发都使用该标准软件过程	组织过程定义,组织过程焦点,培训大纲,软机集成管理,软件产品工程,组织协调,专家审评
第四级管理级	收集软件过程和产品质量的详细度量,对软件过程和产品质量有定量的理解和控制	定量的软件过程管理和产品质量管理
第五级优化级	软件过程的量化反馈和新的思想和技术促进过程的不断改进	缺陷预防,过程变更管理和技术变更管理

　　TSP致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。

三、实施CMM的必要性

四、CMM在中国的现状

五、CMM体系结构

一个企业软件能力类似于一个人在一个特定领域的能力，是逐步获得和增长的。如果一个人在其领域的发展过程中能得到一个很好的指南，那么他或她就会不断达到一个个设定的目标，并变得成熟起来，否则可能会盲目发展，离自己的目标越来越远，甚至南辕北辙。一个企业的软件能力发展也同样需要一个良好的指南，SW-CMM正是这样一个指南，它以几十年产品质量概念和软件工业的经验及教训为基础，为企业软件能力不断走向成熟提供了有效的步骤和框架。

框架

SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级实际上是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过这个起点向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一个级别迈进。CMM体系不主张跨越级别的进化，因为从第二级起，每一个低的级别实现均是高的级别实现的基础。

1.初始级
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

2.可重复级
根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

3.定义级
在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

4.管理级
第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。

5.优化级
第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

结构

除第一级外，SW-CMM的每一级是按完全相同的结构构成的。每一级包含了实现这一级目标的若干关键过程域(KPA)，每个KPA进一步包含若干关键实施活动(KP)，无论哪个KPA，它们的实施活动都统一按五个公共属性进行组织，即每一个KPA都包含五类KP。

1.目标
每一个KPA都确定了一组目标。若这组目标在每一个项目都能实现，则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求，则表明达到了这个级别所要求的能力。

2.实施保证
实施保证是企业为了建立和实施相应KPA所必须采取的活动，这些活动主要包括制定企业范围的政策和高层管理的责任。

3.实施能力
实施能力是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。

4.执行活动
执行过程描述了执行KPA所需求的必要角色和步骤。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。

5.度量分析
度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。

6.实施验证
实施验证是验证执行活动是否与所建立的过程一致。实施验证涉及到管理方面的评审和审计以及质量保证活动。
在实施CMM时，可以根据企业软件过程存在问题的不同程度确定实现KPA的次序，然后按所确定次序逐步建立、实施相应过程。在执行某一个KPA时，对其目标组也可采用逐步满足的方式。过程进化和逐步走向成熟是CMM体系的宗旨。

六、CMM实施的思考

============================================================================

CMM及其应用

随着我国计算机软件产业的形成和发展，软件产品质量保证这一课题逐渐受到各个软件开发组织和政府有关管理机构的重视。一些规模较大的软件开发组织各自在本单位运用质量管理理论指导开展了软件产品质量保证活动；有些软件开发公司引入了国际通行的质量管理体系质量保证模式——ISO9001（或ISO9002）。鉴于软件产品本身及其开发和生产的特殊性，不少软件开发组织在实施ISO9001的同时亦不同程度地感到ISO9001（加上ISO9000-3）与他们的实际活动不是那么相适应。于是，一种专门针对软件开发组织的软件质量保证模型悄然进入我国一些软件开发组织和有关研究单位的研讨日程，这就是CMM。

　　近几年来，我国一些单位有组织地或自发地开展了对CMM的研究，有的还在本单位内进行了尝试性的CMM实施。特别是自1998年以来，我国计算机软件业界对CMM的研究热迅速升温；“采用ISO9001还是CMM?”的问题也悄然出现。无论是实施ISO9001，还是寻求运用其他软件产品质量保证渠道，这些对保证软件产品质量的热情正是我国软件产业正在走向成熟的标志。恰当地选择软件开发组织的产品质量保证途径不仅将有助于各个软件开发组织提高软件产品开发和生产能力，亦将为加快我国软件产业的成熟作出贡献。鉴于CMM在其“原产国”实际应用中的有效表现，引起包括我国在内的许多国家软件业界的兴趣，国际标准化组织（ISO）也顺应各国的兴趣而开展了与CMM密切相关的标准课题研究。本文将对CMM作简要介绍，并且把CMM与ISO9001加以比较，最后谈谈CMM的应用问题。

一CMM简介

　　我国目前谈及的CMM是指“软件能力成熟度模型”，其英文全称为Capability Maturity Model for Software （英文缩写名是SM-CMM），更确切地说，是指“软件能力成熟度模型.1.1版”和“能力成熟度模型的关键惯例.1.1版”（Capability Maturity Model for software,Version1.1和Key Practices of the Capability Maturity Model,Version1.1简称CMM1.1版}。CMM是美国卡内基—梅隆大学软件工程研究所（以下简称SEI）的研究成果；CMM1.1版发表于1993年。SEI是美国国防部出资于1984年设立。从1986年开始，SEI针对软件组织改善其软件过程，特别是美国国防部对软件承包商的能力评价问题，研究“过程成熟度框架”。1987年9月，SEI发表了关于过程成熟度框架的简要说明和成熟度调查问卷。以这一过程成熟度框架为蓝本，在美国联邦政府促进下，从1987年到1991年在美国的一些大公司的软件组织进行了软件过程能力成熟度模型的评估实践。根据这4年的实践经验，特别是从美国政府和工业界反馈的关于软件过程评估的信息，SEI在原过程成熟度框架的基础上开发出了“软件能力成熟度模型（CMM）0.0版”。在CMM0.0版发表后的两年里，先后产生了30多稿草案，于1993年2月发表了“软件能力成熟度模型1.1版”和“能力成熟度模型的关键惯例1.1版”（统称SM-CMM1.1版，有时干脆简称为CMM）。

　　大家都知道，软件产品的质量在很大程度上取决于构筑软件时所使用的软件开发和维护过程的质量。软件过程是人员密集和设计密集的作业过程；若缺乏有素的训练，就难以建立起支持实现成功改进软件过程的基础，改进工作亦将难以取得成效。CMM描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的途径。

　　迄今为止，CMM既不是政府标准也不是行业协会标准，而是美国卡内基—梅隆大学软件工程研究所（SEI）发表的一份技术报告；不过，它在美国已成为事实上的标准。鉴于CMM的巨大应用前景，SEI已在美国注册了CMM, Capability Maturity Model和Capability Maturity Modeling的专利和商标。与此同时，围绕以CMM为基础的软件过程评估和软件能力评价建立了从审核员培训到提供评估和评价的一整套服务体系。

　　SEI给CMM下的定义是：对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。

　　如前所述CMM1.1版包括两部分：“软件能力成熟度模型”和“能力成熟度模型的关键惯例”。“软件能力成熟度模型”主要是描述这种模型的结构，并且给出该模型的基本构件的定义；为便于读者理解，还进一步对成熟度模型及其构件做了大量解释。“能力成熟度模型的关键惯例”除了重复叙述能力成熟度模型结构及其构件外，以大量篇幅详细描述了每个“关键过程方面”涉及的“关键惯例”。“关键过程方面”是指：一组相关联的活动；通过执行这些活动可以实现既定的过程能力。所谓“关键惯例”是指：使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动。各个关键惯例按每个关键过程方面的5个“公共特性”（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程）归类，逐一详细描述。按CMM的规定，作到了某个关键过程的全部关键惯例就认为实现了该关键过程，实现了某成熟度级及其以低各级所含的全部关键过程就认为达到了该级。

　　CMM把软件开发组织的能力成熟度分为5个可能的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程规定了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种分级的思路在于把一个组织执行软件过程的成熟程度分成循序渐进的几个阶段，这与软件组织提高自身能力的实际推进过程相吻合。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。这一点很重要，因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动。

CMM总体结构图示说明参见图1。
　　图1能力成熟度模型的结构

　　CMM的开发者们结合他们的软件产业环境和软件产品质量保证的需要，在CMM1.1版中把具有最高能力成熟度的组织设定为处于这样一种情况下的组织：整个组织都持续致力于过程改进；这个组织具备足够的手段用于事先发现过程的长处及短处和防止发生缺陷；它拥有丰富的软件过程成功经验的数据并且可用于对新技术进行“费/效”分析和提出对本组织软件过程的更改建议；它能发现那些可能发掘出最佳软件工程惯例的合理化建议并使之在整个组织里实现转化。这种能力成熟度被定义为CMM的第5级，称之为“（持续）优化级”。

　　另一方面，现实的软件业里尚有不少组织还不具备稳定的环境用于软件开发和维护,它们缺乏健全的管理惯例，其软件过程能力无法预计；它们的软件过程是一片混沌；并且它们的软件过程总是随着软件开发工作的推进而处于变更和调整之中。这种情况被CMM定义为第1级能力成熟度，称之为“初始级”。

　　第2级为可重复级。在处于可重复级的组织里，顾客的需求和本组织的工作产物是受控的并且建立起了基本的项目管理惯例。藉以产生软件产品的一系列过程有如一连串“黑盒子”；尽管管理者可能不知道在“黑盒子”里具体发生了什么，但是，他能掌握过程的产物和那些确认过程是否正常的校验点，从而在发生问题时作出反应。这一级有6个关键过程方面，共含121个关键惯例：

——需求管理（12，这是关键惯例数，以下同）
——软件项目策划（25）
——软件项目追踪和监督（24）
——软件分包方管理（22）
——软件质量保证（17）
——软件配置管理。（21）

　　第3级是（明确）定义级。在这一级，对于在整个组织里用于软件开发和维护的标准过程以文件形式被固定下来。针对各个基本过程建立起文件化的“标准软件过程”，这是第3级能力成熟度的突出特点。这些标准软件过程（包括工程过程和管理过程）被集成为一个相关的整体；这些标准软件过程有助于软件经理和技术人员更有效地履行他们的职责。实践表明，对软件过程加以标准化的过程，也就是发掘高效软件工程惯例的过程。而标准软件过程的建立和实施则为本组织软件项目的实施提供了公共的工程环境。较普遍的看法是，只有当达到了第3级能力成熟度时，才表明这个组织的软件能力“成熟”了。因为，在到达这一级后，表明上述的“黑盒子”被打开了。在第2级的基础上，第3级包括7个关键过程方面，共含108个关键惯例：

——组织过程定焦（16）
——组织过程定义（11）
——培训（16）
——集成式软件管理（19）
——软件产品工程（20）
——组间协调（17）
——对等审查。（9）

　　第4级是定量管理级。处于这一级的组织已经能够为软件产品和软件过程设定定量的质量目标，并且能对跨项目的重要软件过程活动的效率和质量予以度量；可以利用本组织的软件过程数据库汇集各项目软件过程产生的数据并加以分析。处于第4级是，该组织的各个软件过程是用各种确切定义并且一致地尺度来说明的；这些尺度是用以评价项目的软件过程和产物的定量基础。在第2，3级的基础上，第4级包括两个关键过程方面，共含32个关键惯例：

——定量过程管理（19）
——软件质量管理。（13）
如前所述，第5级叫持续优化级。在前几级的基础上，第5级包括3个关键过程方面，共含59个关键惯例：
——缺陷预防（18）
——技术变更管理（22）
——过程变更管理。（19）

　　CMM1.1版总计18个关键过程方面，320个关键惯例。

　　这18个关键过程方面可以划分为3大类：管理类，组织类和工程类。其中有的关键过程方面是跨类的，见图2。

　　软件组织的成熟度等级只能逐级递进，不可能越级。成熟度级别的提高也就意味着实现的关键惯例大幅度增加；其间关系见图3。

　　图2关键过程方面分类

　　图3成熟度等级递进与关键惯例含量

二CMM与ISO

　　CMM和ISO9001都涉及质量管理和过程管理，并且都受到类似的厉害关系驱动，两者之间有着相似之处。因此，往往产生这样的问题：

——符合ISO9001的软件组织达到CMM的哪一级？
——达到CMM的第2或3级的软件组织是否符合ISO9001？
——一个组织打算推进质量管理或改进软件过程时是采用ISO9001还是采用CMM？

　　ISO9001被认为是适用于所有各类专业领域的一种质量保证模式；但是，对于软件组织来说，尽管加上了ISO9000-3作为实施指南，ISO9001似乎仍然不够贴切，留给审核员作解释的回旋余地相当大。于是就软件能力评定而言，按ISO9001进行认证时，不确定性很大；换言之，同是通过了ISO9001认证的组织，其间的软件能力可能有很大差别。

　　CMM是专门针对软件组织设计的一种描述软件过程能力的模型。CMM研制的主要目的有二：一是用于帮助事先确定承包商的软件能力；二是用于软件组织的过程改进。考虑到按ISO9001对软件组织进行认证审核时存在的较大不确定性，在设计CMM时，注意了尽量缩小审核员解释的回旋余地，因此，不仅对每个关键过程方面给出了明确的目标和体现这些目标的各个关键惯例，而且对各个关键惯例都给出了明确的定义和详细的说明，以期按CMM进行评估时能有较大的一致性和可靠性。结果，CMM成了一个“庞然大物”——长达500余页。
如上所述，CMM与ISO9001的设计思路不同，并且一个是“专用”，一个是“泛用”，因此，尽管两者都由于涉及质量管理和过程而有着相似之处，但也存在很大差别。下面依次按ISO9001的20个要素对CMM作一些简单比较。

1.管理职责

　　ISO9001要求确定质量方针并且加以文件化，理解，执行和维护；要求确定所有员工在规定，达到和监控质量方面的责任和权限；要求确定自有的验证资源，进行培训和给予财政支持。由一名指定的经理保证质量计划的实现和维护。

　　在CMM中，管理层在质量方针和验证活动方面的责任主要反映在“软件质量保证”中，在“软件项目策划”和“软件项目跟踪和监督”中只是指出履行所有项目角色时的责任。

　　高级管理层和项目管理层的软件项目管理责任是在确认实现中反映。一般，领导问题反映在公共特性的“承诺”方面，组织和资源问题反映在公共特性的“能力”方面。虽然CMM在第4级的“软件质量管理”中也描述了质量方针，不过，第4级的质量方针是定量的。此外，ISO9001中关于度量在质量管理体系中的作用也有点含糊，ISO9001第4.20条要求确定质量目标并且形成文件，而没有要求量化。

2.质量体系

　　ISO9001要求建立文件化的质量体系，包括程序和指导书。ISO9000-3以质量体系作为整个软件生存周期的综合过程。

　　CMM主要在“软件质量保证”中涉及质量体系活动。各项程序分布在“关键过程方面”的各项“要执行的活动”中。
软件项目将用到的特定程序和标准在“软件项目策划”中描述的软件开发计划中规定。通过“软件质量保证”和执行“确认实现”中的审核活动来确保符合这些标准和程序。

　　“软件产品工程”要求确定各项软件工程任务，加以综合并且统一执行；这一点与ISO9000-3关于此条的指南对应。

　　CMM第3级“组织过程定义”这一关键过程方面描述了一组组织一级的软件过程财富，包括标准，程序和过程说明。运用“组织过程定义”肯定有助于达到此条要求，但是在ISO9001的这一条里，标准和程序可能直接在项目级处理。ISO9001讨论供方的质量体系，而不讨论组织支持与项目实现的关系；CMM作了讨论。另一方面，在ISO9000-3中，关于质量策划的指南有两节：4.2.3节讨论跨项目的质量策划；5.5节讨论具体开发工作中的质量策划。

3.合同评审

　　ISO9001要求评审合同，以确定各项要求是否充分规定，是否与标书一致，是否能实现。

　　在CMM中，对顾客软件需求的审查在“需求管理”中叙述。软件组织（供方）确保分配给软件的（系统）要求形成文件并且予以审查，确保那些可能引起误解的或含混的要求得以澄清。因为CMM仅限于软件方面，所以顾客需求作为一个整体归于“需求管理”这个关键过程方面里。

　　CMM中的“软件项目策划”描述了为签定合同而要提出的软件开发计划建议和工作陈述，并且要求软件工程组和高级管理层加以审查。

　　CMM还就软件组织通过分包获得软件的情况作了规定（在“软件分包方管理”中叙述）。合同可以是与某个外部顾客的，也可以是与分包方的；虽然这一点在ISO9001的这一节中没有明确规定，但也可以意识到。

4.设计控制

　　ISO9001要求建立控制和证实设计的程序。这包括策划设计活动，标识输入和输出，证实设计和控制设计变更。ISO9000-3用了几条来详细描述了这一条：购方需求规范（5.3），开发策划（5.4），质量策划（5.5），设计和实现（5.6），测试和验证（5.7）和配置管理（6.1）。

　　CMM中，需求分析，设计，编码和测试等生存周期活动在“软件产品工程”中描述。这些活动的策划是在“软件项目策划”中描述。“软件项目跟踪和监督”描述这些活动的控制，而“软件配置管理”描述的是这些活动产生的软件工作产物的配置管理。

　　ISO9001要求进行诸如记录并且保存设计审查和鉴定测试之类的设计控制手段。ISO9000-3指出，供方应该进行审查，以保证需求得到满足和设计方法得到正确执行。虽然对设计控制手段有要求，但是使用了“shoud”（最好）之类短语则为具体控制手段的使用赋予了灵活性。相反，CMM要求专门的质量控制机制：对等审查。“对等审查”这一关键过程方面支持生存周期从需求分析到测试的各个过程。　　　　
　　“软件质量管理”中描述的定量的设计过程方面更为正规，但ISO9001不一定要求这种正规程度。

5.文件控制

　　ISO9001要求对文件的分发和修改予以控制。
　　在CMM中，反映文件控制的配置管理惯例在“软件配置管理”中描述。在CMM中，可以置于配置管理下的具体程序，标准和其他文件分布在各个关键过程方面的各种“要执行的活动”惯例中。为运行和维护质量体系所要求的文件在“软件产品工程”的“活动8”中作了具体规定。

6.采购

　　ISO9001要求采购的产品符合它们的规定要求。这包括评估潜在的分包方和验证采购的产品。

　　在CMM中，这个要求反映在“软件分包管理”中。分包方的评估在“活动2”中描述，分包软件的验收测试在“活动12”中处理。

7.顾客提供的产品

　　ISO9001要求任何由顾客提供的物资都要经过验证和予以维护。ISO9000-3是在包含软件产品（包括商业现货软件）的条文（6.8）中讨论这一条。

　　在“综合软件管理”中的“活动6.3”是CMM中描述外购软件使用的唯一惯例。它把标示现货软件或可再用软件的条款作为项目策划的一部分。现货软件和可再用软件的综合是CMM中的薄弱方面。这一条在ISO9000-3中专门做了扩展，而CMM考虑得不够。虽然不够，不过，“软件分包管理”的“活动12”中分包软件的验收测试惯例可用之于任何所包含的软件产品，算是一点弥补。

8.产品标识和溯源

　　ISO9001要求在产品生产，交付和安装的所有阶段都要给产品加标识并且可追溯。

　　CMM覆盖这一条的主要是“软件配置管理”，不过“软件产品工程”的“活动10”指出了对软件工作产物之间的一致性和可追溯性的特定要求。

9.过程控制

　　ISO9001要求确定各项生产过程并进行策划。这包括在受控条件下按照文件化的作业指导书进行生产。对于未能充分验证的专用过程要持续监控。ISO9000-3有几条包含了此条内容：设计和实现（5.6）；规则，惯例和约定（6.5）；以及工具和技术（6.6）。
CMM中规定软件生产过程的程序分布在各个关键过程方面的各项“要执行的活动”惯例中。将用到的具体惯例和标准，按“软件项目策划”的“活动7”所述，在软件开发计划中规定。软件生产过程的定义和集成在“软件产品工程”中描述。过程保证在“软件质量保证”的“活动4”中描述（产品保证在“活动5”中规定）。
在CMM中，“定量过程管理”涉及到定量控制，并且要求给出统计过程控制的例证，而按ISO9001的审核中一般不要求满足这一条。
值得注意的是，ISO9000-3第6.6条指出，供方在必要时应改善这些工具和技术，以便把新技术引入本组织（与CMM中“技术变更管理”讨论的内容相近）。

10.检验和测试

　　ISO9001要求对进货在使用前检验或验证，要求进行过程中检验和测试。在成品予以放行前执行最终检验和测试。检验和测试记录予以保存。

　　CMM是在“软件产品工程”中的第5，6和7项活动里描述测试问题。关于软件方面的过程中检验是在“对等审查”中处理。

11.检验，测量和测试设备

　　ISO9001要求对用于证明符合性的设备于以控制，校准和维护。在使用测试硬件和测试软件时，要在使用之前检查并且按预定的时间间隔复检。ISO9000-3在以下几条中对这一条作了澄清：测试和确认（5.7）；规则，惯例和约定（6.5）；以及工具和技术（6.6）。
在CMM中，此条是在“软件产品工程”的测试惯例中做了一般性处理。在“能力1.2”（描述支持测试的工具）中特别提到了测试软件。

12.检验和测试状态

　　ISO9001要求，随着软件项经由各个处理步骤推进时，其检验和测试状态得以维护。

　　在CMM中，用“软件产品工程”的测试惯例和“软件配置管理”中的“活动5”（问题报告）和“活动8”（配置状态）处理这一条的要求。

13.不合格品的控制

　　9000-3把这个概念映射到以下几条：设计和实现（5.6）；测试和确认（5.7）；复制，交货和安装（5.9）以及配置管理（6.1）。
在CMM中，设计，实现，测试和确认是在“软件产品工程”中处理。在“软件配置管理”中，“活动8”涉及软件配置项的状态，包括已知有缺陷（但尚未定位）的软件项的状态。ISO9001第4.15条所述的安装在CMM中未涉及。

　　在制造业里，这一条很重要，因为有时有必要使用未符合全部要求的构件建造产品。在做这种决策后，必须小心控制不合格品。

　　与之类似，在软件业，有时系统可能使用的工具或复用软件没有满足全部相关的标准。例如，如果已在以前的应用中证明FORTRAN码的价值，在Ada程序中复用FORTRAN码也许有良好“费/效”比。然而，这个码可能给Ada系统带来很大风险，必须充分掌握这种风险。
CMM中没有专门谈及不合格品。ISO9000-3中，有关不合格品的要求基本上隐含在软件生存周期的许多有关过程中：设计和实施（5.6）；测试和确认（5.7）；复制，交付和安装（5.9）和配置管理(6.1)。

　　14.纠正措施

　　ISO9001要求找出造成不合格品的原因，消除造成不合格品的潜在原因，根据纠正结果改变程序。

　　这一段的文字隐含着CMM中“缺陷预防”里的许多惯例。这一段中讨论的纠正措施往往是顾客投诉引发的。因此往往是由软件工程组查找现场缺陷，分析其发生原因，并且采取纠正措施。这种情况常常发生在对现场软件的修补或升级过程中。按CMM的思路，是在报告问题之后对基线工作产品的维护加以控制。问题报告是在CMM的“软件配置管理”中描述。

　　从审核角度看，纠正措施是要处理审核中发现的不符合项，无论是内部还是外部审核中发现的。这一点是在CMM的“软件质量保证”中处理。

　　在ISO9001运用于软件领域时，这是个有争论的问题。有的认为软件领域的缺陷预防过程与制造业环境的类似，有的认为只要求涉及用户问题报告即可。在CMM中，此点亦尚无定论——究竟“缺陷预防”中要描述多少过程中因果分析和缺陷预防才能满足ISO9001中这一段的要求，还有争论。

15.搬运，储存，包装和交付

　　ISO9001要求建立并维护关于搬运，储存，包装和交付的程序。

　　ISO9000-3中与这段对应的是接受（5.8）和复制，交付和安装（5.9）。

　　CMM中没有覆盖复制，交付和安装。在“软件产品工程”的”活动7”涉及验收测试，而“软件配置管理”的“活动7”描述了软件产品的创建和释放。不过CMM中没有描述交付和安装产品。

　　从CMM的修订版情况看，可能将在“软件产品工程”这个关键过程方面中增加一个关于软件产品交付和安装的惯例。

16.质量记录

　　ISO9001要求收集，维护和处置质量记录。

　　在CMM中，对需要维护的质量记录加以定义的惯例是以“要执行的活动”的形式分布在各个关键过程方面。在“软件产品工程”中的测试和对等审查惯例，特别是“活动9”中关于缺陷数据的收集和分析反映了这一段的内容。问题报告是在“软件配置管理”的“活动5”中描述，而对等审查数据的收集是“对等审查”的“活动3”中描述。

17.内部质量审核

　　ISO9001要求策划并执行质量审核。审核结果要通知管理层，发现的缺陷要予以纠正。

　　在CMM中，质量审核过程由“软件质量保证”描述；具体的审核要求反映在“确认实现”这一公共特性的审核惯例中。

18.培训

　　ISO9001要求确定并提供必要的培训，因为所选择的任务可能要求有相应资格的人员。培训记录要维护。

　　CMM中，是在“执行能力”这一公共特性的培训和定向惯例中反映具体的培训需要。

　　一般性的培训设施是在“培训大纲”（包括“活动6”中的维护培训记录）中描述。

19.服务

　　ISO9001要求按规定执行服务活动。ISO9000-3把这一段的要求作为维护（5.10）来处理。

　　虽然CMM的意图是既适用于软件开发也适用于维护环境，但CMM中的惯例并不直接处理属于维护环境的独特特性。维护被镶嵌在CMM的各个惯例中，并且必须按开发或维护的前因后果作相应解释。

　　因此，在CMM中，维护不是一个独立的过程。从CMM的修改情况看，有可能在措辞上更明确地涉及维护环境，以便清楚地表达CMM在维护项目方面的应用。

20.统计技术

　　ISO9001指出，适用时，应确定适当的统计技术并且用于验证过程能力和产品特性的可接受性。ISO9000-3简单地在度量（6.4）中表述了这一段的特性。

　　CMM中描述度量的惯例分布在各个关键过程方面。产品度量一般是包含在各个“要执行的活动”惯例中，而过程度量是在“度量和分析”这一公共特性中描述。

　　“组织过程定义”的“活动5”描述了建立组织级数据库，以便本组织用于收集过程和产品数据。这种数据库是在组织一级维护。在CMM中，项目级的统计数据是在第2级里各个项目管理关键过程方面描述。

　　如果说这一条指的是统计过程控制，那么，在CMM中是通过“定量过程管理”和“软件质量管理”予以满足。不过，要注意是在“适用时”使用统计技术。

　　由上述的大致比较可以看出，尽管ISO9001中的一些内容在CMM中没有覆盖，CMM中的一些内容在ISO9001没有涉及，但是，ISO9001与CMM之间有着很强的相关性。不过，细节上的差别很大：ISO9001第4章大约有5页；（ISO9000-3的第5，6和7节大约11页；）而CMM长达500多页。不过，这两分文件间的最大差别在于，CMM强调的是持续的过程改进；而ISO9001涉及的是质量体系的最低可接受标准。此外，CMM专门针对软件领域，而ISO9001适用范围很广（硬件，软件，流程性材料和服务）。

　　CMM和ISO9001这两者的最大相似之点在于它们都是“说你要做的，做你要说的”。ISO9001的基本要求在于，在整个质量控制活动中每个重要过程都应该文件化并且每个交付件都接受质量检查。

　　ISO9001要求编制出指导书或指南之类文件，用以说明应该做什么或应该如何做。在CMM中，同样强调过程和惯例要“文件化”。
　
　　CMM强调要求记录信息以便供该过程以后使用或供改善该过程用。这相当于ISO9001中的质量记录——证明所要求的质量是否达到和质量体系是否有效运行。

　　若仅从上述ISO9001和CMM中的基本概念比较看，似乎可以得出结论：获得ISO9001认证的组织应该处于CMM的第3或第4级。但是，有资料表明，有的组织虽然尚处于第1级，也取得了ISO9001认证。原因之一是由于ISO9001的高度概括性而造成的对文件解释的多样性。

　　那么，一个符合ISO9001的软件组织，如果它完全没有实现ISO9001中未包含的管理或工程惯例，它处于CMM的哪个成熟度等级？这是一个极端情况，不过它给出了一个符合ISO9001的组织的成熟度的下边界。图4示出这个组织的关键过程方面的轮廓。图中，黑影表示ISO9001或ISO9000-3直接谈到的关键惯例；灰影表示按照对ISO9001的解释可能涉及的关键惯例；无阴影表示ISO9001未涉及的关键惯例。因此，就各个关键过程方面而言，根据不同解释，可以得出部分满足或全部满足或不满足的结论。阴影条的长度表示ISO9001或ISO9000-3中涉及到的关键惯例的百分比。

图4一个符合ISO9001的组织的关键过程轮廓

　　由此轮廓可看出，处于CMM第1级的组织的确有可能通过符合ISO9001的认证；同时，该组织又可能具有很强的第2级的过程实力和明显的第3级的过程实力。在美国的有关业界里普遍认为，一个得到并且维持ISO9001认证的组织，它应该是接近第2级的。

　　如果一个组织遵循ISO9001的精神，而不止于符合其书面条款，这个组织有可能接近或超过了第2级。一个软件组织可以得到ISO9001证书但却处于第1级，这种情况反映出ISO9001的精神与字面的差别。

　　是否可以把处于第3级的组织看成是符合ISO9001的呢？不行，因为即使这个组织处于第3级，它还需要确保ISO9001的（4.15）条中描述的交付和安装要求得到满足，并且应该考虑ISO9000-3中（6.8）条描述的“所包含的软件产品的使用”。当然，这些要求对处于第3级的组织来说是微不足道的，即使是处于第2级的组织也不难通过ISO9001认证审核。

　　从上述分析不难得出这一结论：在CMM中，虽然有的问题谈的还不够充分，但大体上包容了ISO9001，ISO9001却不能包容CMM。

　　那么，软件过程改进应该以CMM为基础（也许再补充一些ISO9001的内容），还是致力于ISO9001认证？对于一个软件组织来说，市场可能要求它拥有ISO9001证书。无疑，瞄准CMM的要求进行软件过程改进将有助于本组织通过ISO9001认证审核。就软件过程改进而言，虽然这两份文件都可用，不过CMM给出的指南更详细并且视野更宽阔，因此CMM应该是较好的选择。

　　从本质上说，在构筑竞争优势时应该致力于改进，而不是只为得到ISO9001证书或达到某个CMM成熟度级。

三CMM的应用

　　设计CMM的初衷是为了用以支持美国国防部对软件组织的能力进行评定。因此，从1987年SEI拿出CMM的雏形（“软件成熟度框架”）后，美国国防部便把它用于软件组织评估，以支持选择承包商时的决策。后来，随着CMM研制和试用工作的推进，设计者，参与者和支持者们发现了它的巨大应用潜力，于是，CMM的研制目标扩大为：

——以实践为基础，
——反映最好的实践经验，
——反映那些从事软件过程改进，软件过程评价和软件能力评估的人士的需要，
——形成书面文件，
——供大众使用。

　　由于接受并且通过了CMM评估给公司在合同竞争中带来的好处，使CMM很快在美国和美国以外那些希望得到美国的软件开发项目合同的公司传播开。由于CMM评估需求大大增加，1994年，在美国国防部的支持下，设立了“软件过程改进（SPI）服务部”，明码市价对外提供各种CMM相关服务。现在，美国已有多家咨询或服务机构获得授权开展此项服务业务，以应付日益增多的CMM应用需要。对CMM趋之若骛的现象，一些软件界资深管理人士认为，这是因为“今天，在软件开发中的最大问题不是技术问题，而是管理问题。”

　　正式发表的CMM建立了一套准则，供大众用于描述成熟软件组织的特性。这些准则可以由软件组织用于改进它们的开发和维护软件的过程，也可以由政府或商业组织用来对它们在打算与某公司签定软件项目合同时涉及的风险进行评价。简言之，CMM主要用途有两大类：

——过程改进；
——能力评估。

　　CMM用之于软件过程改进时，是通过按CMM给出的准则对软件过程实施评价，从而为作出改进决策和实施改进提供支持；所以，往往又把CMM在过程改进方面的应用看成是过程评价。于是，上述CMM的两种主要用途又归结为两种评定方法：

　　·软件过程评价；用于确定组织目前的软件过程状态，确定组织面临的突出软件过程问题，从而求得组织的软件过程改进的支持。
　　·软件能力评估。用于识别合格的软件工作承包商，或用于监控现行软件工作项目上用的软件过程的状态。

　　CMM是软件过程评价和软件能力评估的公共基础。不过，两种用法的目的不同，而且具体用法也有很大差异。软件过程评价侧重于确定本组织软件过程改进的轻重缓急；软件能力评估侧重于确定在选择软件项目承包商时可能碰到的风险，或者说是确定软件组织在软件能力方面的置信程度。后面这一点正是许多软件组织看好按CMM评定等级的原因。软件过程评价与软件能力评估在动机，目标，范围以及审核结果所有权等方面都有所不同。

　　按CMM进行软件过程评价或软件能力评估的几个大步骤基本相同，从选定评估组后：

——以成熟度调查问卷作为现场访问的出发点；
——用CMM作为指导现场调查研究的路线图；
——针对CMM中的关键过程方面指出反映该组织软件过程的强，弱之点；
——根据所了解到的该组织达到CMM关键过程方面目标的情况描绘出该组织的软件过程的概貌；
——向被审核者说明评估结果。

参见图5。
图5软件过程评价和软件能力评估的共同步骤

　　CMM仅仅是模型，为了保证可靠且一致地使用它，美国卡内基-梅隆大学软件工程研究所围绕CMM拟制了一系列支持性文件（包括相应的评价框架，方法描述和实施指南）以及各种工具。使用CMM的大致思路是：1）围绕CMM拟制出CMM评估框架（CAF），从CAF中归类出各类要求，（CAF已由SEI拟出并发表）；2）针对各类要求进行相应准备；3）按对象及其需求采用适当的方法进行评定。以CMM为基础实施评定的概念见图6。

图6以CMM为基础实施评定的概念图

（图中CAF=CMM评估框架IPI=综合过程改进SCE=软件能力评估）

　　如前面所述，CMM是由美国国防部斥资启动研究的。原定用途是为了确保所选的承包商确有开发重大软件项目的能力。因此，CMM涉及了软件组织软件能力的方方面面并且详细非常。实施CMM评定将牵涉大量人力，财力和时间。例如，美国的CMM评审机构为进行一次评估（或评价）开出的价码是7~10万美圆。从接受评估申请到完成评估跨时2到3个月；如果涉及过程改进，将可能需时18~24个月。为了适应中，小组织的需要，人们已开始探讨CMM的裁剪和压缩问题。不过，对于软件组织来说，能力的不断增强是根本所在，所以，美国的一些规模不大的软件公司也早已开始寻求CMM评估，而没有等待“小型CMM”出现。

　　CMM这个模型把软件组织的能力成熟度分成5个等级。从1987年发表CMM的最初框架到1993年发布CMM1.1版的这6年试运行，除了一些过去已经通过TQM或其他质量管理活动而达到高成熟度的大型公司外，经过评估并达到的成熟度等级大多数是第2或第3级。原因在于，CMM勾画出的这个分级递进式框架虽然描述了第4和第5级成熟度的特征，但是，究竟应该用什么样的实际表现来定位第4和第5级，尚有争论。就成熟度升级而言，美国CMM评估业界和软件业界认为，从拟订出软件过程改进大纲算起，至少要18~24个月才能真正完成改进，并且随着软件项目开发的启动往往要“冻结”各项相关的软件过程，也就是说，在软件开发过程中一般不会去更改该项目开发涉及的软件过程；此外，所处水平越高升级亦越难——CMM的设计也融入了这种思想。因此，尽管从CMM1.1版发布之日算也已过去了6年，即使在美国本土接受并通过CMM第4或第5级评估的主要还是那些在制定出CMM之前就有很强软件能力的公司（如IBM,波音，洛克希德，休斯，莫托罗拉等）里的软件组织。从1995年，即CMM1.1发布后的第3年起，CMM又进入了另一个修改的高峰期。美国政府和软件业界大力支持和积极参与下，SEI先后发表了CMM2.0版的A版，B版和C版草案；1997年，应美国国防部之请，CMM2.0(C)版草案停止推进。SEI宣布，CMM1.1版和CMM2.0版的C版草案都有效并且SEI及其授权的机构为这两种版本提供相应的服务。与此同时，名为“综合能力成熟度模型”（英文缩写为CMMI）的一个综合性模型投入研制。自CMM1.1发布起，为与之配合，在以后几年里SEI相继研制并发布了“人员能力成熟度模型”（P-CMM），“软件采办能力成熟度模型”（SA-CMM）和“系统工程能力成熟度模型”（SE-CMM）及其支持文件。经过试运行，产生了把SM-CMM, P-CMM, SA-CMM和SE-CMM合并在一起的想法和行动，于是开始了上述的CMMI研制工作。

　　受CMM思路的影响，国际标准化组织（ISO）开始了围绕SPICE（软件过程改进和能力确定）的大题目展开了有关软件过程评估的成套标准制定活动。SPICE包含的过程管理参考模型与SM-CMM类似，不过，SM-CMM着眼于过程能力，SPICE着眼点是组织能力，而且SPICE提出的一套通用惯例适用于任何过程的过程管理，而不仅仅是软件过程。目前，ISO将作为技术报告发布的ISO15504（软件过程评估）包括9个部分：

第1部分概念与导论
第2部分过程和过程能力的参考模型
第3部分评估
第4部分评估指南
第5部分用于评估模型和指针的指南
第6部分审核员资格审定指南
第7部分在过程改进中参考模型使用指南
第8部分在确定供方过程能力中参考模型使用指南
第9部分词汇。

　　CMM虽然已在美国成为事实上的标准，但它毕竟只是美国一个研究所的一份技术报告，而且还一直处于修改和变更的过程中。因此，CMM尽管引起不少国家软件业界的关注，但是，除了因合同需要而寻求CMM评估之外，大多处于分析和研究阶段；相比之下，国际标准化组织的步子更大些。如前所述，由于软件产业发展的需要，CMM所表达的思路也引起了我国一些软件组织和其他机构的兴趣，几年前即已开展了相应的探讨和研究工作。现在有的软件组织开始谈论“是寻求ISO9001认证，还是CMM评估”的现实问题，有的软件组织正在摸索本组织实施CMM的可能性，有的已经在尝试准备按CMM评估。对于这些现象，有人归结为“CMM在我国的应用问题”。笔者认为，除了那些因接受软件出口合同的要求而不得不接受CMM评估的情况之外，在考虑“CMM在我国的应用”这一问题时，特别是在行业或政府一级考虑这个问题时至少要注意以下三点：

　　·CMM和Capability Maturity Model已经由美国卡内基-梅隆大学软件工程研究所在美国注册了专利和商标；

　　·CMM产生于美国的软件产业那个环境；在那个环境里，有的公司的软件组织在CMM产生之前就有相当成熟的软件能力。这种能力不是单靠评估或认证能达得到的，应该说，这主要是得益于大量软件项目实践以及充分尊重，积累和运用实践经验的结果。此环境非彼环境。

　　·从比较ISO9001与CMM中可以看出，ISO9001和CMM的精神是一致的，两者都强调“说的要做到，做的要说到”，都强调“文件化（制度化）”；我国许多软件组织结合ISO9001做了大量实施准备工作或接受并通过了审核认证。在我们引入更好的软件质量保证途径时，应充分利用这些质量保证方面的努力。CMM的思路较好地反映了软件和软件开发工作的特点，围绕CMM而设计和拟制的大量支持文件和工具又为实施一致且可靠的评估提供了保证；但是，CMM至少存在一个不足之处——它只强调“关键过程方面”和“关键惯例”，因此，接受CMM评估的组织往往容易忽视那些“非关键”的过程和（或）惯例，而这些“非关键”的过程和惯例仍是必须执行的。按ISO9001的精神去理解，软件组织倒不一定忽视这些必须执行的“非关键”。此外，正在修订之中的ISO9000系列标准和ISO15504（软件过程评估）亦应关注。

　　当然，对于企业来说，在本组织内利用CMM或其思路进行软件过程改进尝试当属例外。其实，这种摸索尝试将有益于我国软件行业探求推进软件开发能力的最佳途径。希望这些宝贵的实践经验能在我国软件行业或政府有关部门的相应工作中发挥作用，既不要藏之高阁，亦不要置之不理。

　　从CMM本身的发展历程可以看出，并不是一蹴而就，而是边拟制边实践，不厌其烦地发布一版又一版修改稿，不断调整，不断完善。此外，提出CMM者并未止步于这个“标准”文本，同时还拿出了与之配套的文件和工具，并且进一步展开了拓展研究。在我们开展类似工作时，这些经验是值得借鉴的。操之过急或一哄而起是不可取的。

============================================================================

什么是CMM

刚才在网站上看到关于CMM的说法,现整理一些资料,以便更全面的了解CMM,里面不是本人写的.只是整理的.

软件开发能力的成熟度模型(capability manurity model for software,cmm)是软件工程协会sei(software engineering institution)在卡内基.梅隆大学开发完成的对一个组织软件开发能力进行评价的标准,它侧重于对软件开发过程和开发方法论的考察。cmm包括五个成熟等级,开发的能力越强,开发组织的成熟度越高,等级越高。目前,大多数公司处于第一级和第二级,只有很少的公司可以达到第五级。五级的具体定义如下:
    初级(initial)：软件开发过程中偶尔会出现混乱的现象,只有很少的工作过程是经过严格定义的,开发成功往往依靠的是某个人的智慧和努力。
    可重复的(repeatable)：建立了基本的项目管理过程。按部就班地设计功能、跟踪费用 ,根据项目进度表进行开发。对于相似的项目,可以重用以前已经开发成功的部分。
    被定义的(defined.)：软件开发的工程活动和管理活动都是文档化、标准化的,它被集成为一个组织的标准的开发过程。所有项目的开发和维护都在这个标准基础上进行定制。
    被管理的(managed.)：对于软件开发过程和产品质量的测试细节都有很好的归纳, 产品和开发过程都可以定量地分解和控制。
    优化的(optimizing)：通过建立开发过程的定量反馈机制,不断产生新的思想,采用新的技术来优化开发过程。
    除了第一级,其它每一级都有几个特别值得注意的关键过程。第二级的关键之处是建立基本的项目管理控制。他们是需求管理、软件项目计划、软件项目的跟踪和监督、软件转包管理、软件质量保证和软件组态管理。
    第三级的关键之处是既关注项目问题,也关注组织问题,因为组织建立起了使高效率软件工程制度化的基本架构和跨项目的管理过程。它们包括组织过程关注程度、组织过程定义、培训项目、集成化的软件管理、软件产品化机制、项目组的内部协调和对出现错误的复查。
    第四级的关键之处是对软件开发过程和软件产品都有一个定量的理解。它强调的是定量的过程管理和软件质量管理。
    第五级的关键点强调,不论组织还是项目必须追求持续的、可度量的过程改进。包括缺陷预防、技术更新管理和流程改造管理。
     cmm和iso9001的出发点都是通过对生产过程进行管理,来确保产品的质量。虽然它们之间有很多区别,但也有相似之处。比如,通过iso9001认证的组织,可以基本满足cmm二级的标准和很多cmm三级的要求。因为cmm中的很多要求并没有列入iso9000标准之中,所以,cmm一级的组织也可能获得iso9001的登记,defined.同样,有些iso9001规定的内容并没有列入cmm标准。一个cmm三级组织获得iso9001认证几乎没有困难,cmm二级组织申请 iso9001认证也有明显优势。

===========================================================================================

CMM五级标准

第一级：初始级

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

　　第二级：可重复级

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

　　第三级：定义级

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

　　第四级：定量管理级

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

　　第五级：（不断）优化级

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

CMM第一级：初始级

◆ 特征
(1)软件过程的特点是杂乱无章，有时甚至混乱，几乎没有定义过程的规则或步骤。

(2)过分的承诺，常作出良好的承诺：如“按照软件工程方式，有序的工程来工作”；或达到高目标的许诺。但实际上却出现一系列问题。

(3)遇到危机就放弃原计划过程，反复编码和测试。

(4)成功完全依赖个人努力和杰出的专业人才，取决于超常的管理人员和杰出有效的软件开发开发人员。具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验、知识以及他们的进取心和积极程度。

(5)能力只是个人的特性，而不是开发组织的特性。依靠着个人的品质或承受着巨大的压力；或找窍门取得成果。但此类人一旦离去，对组织的稳定作用也消失。

(6)软件过程是不可确定的和不可预见的。软件成熟性程度处于第一级软件组织的软件过程在实际的工作过程中被经常的改变（过程是随意的）。这类组织也在开发产品，但其成果是不稳定的，不可预见的，不可重复的。也就是说，软件的计划、预算、功能和产品的质量都是不可确定和不可预见的。

◆ 过程
(1)极少存在或使用稳定的过程

(2)所谓“过程”，往往是“就这么干”而言。

(3)各种条例，规章制度互不协调，甚至互相矛盾。

◆ 人员
(1)依赖个人努力和杰出人物。一旦优秀人物离去，项目就无法继续。
(2)人们的工作方式如同“救火”，就是在开发过程中不断地出现危机，以及不断的“救火”。

◆ 技术
引进新技术是极大风险。

◆ 度量
不收集数据或分析数据。

◆ 改进方向
(1)建立项目管理过程，实施规范化管理，保障项目的承诺。

(2)首要任务是进行需求管理，建立客户与软件项目之间的共同理解，使项目真正反映客户的要求。

(3)建立各种软件项目计划、如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划。

(4)开展软件质量保证活动（SQA）。

CMM第二级：可重复级

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

(2)主要是逐个项目地建立基本过程管理条例来加强过程能力。

(3)建立了基本的项目管理过程来跟踪成本、进度和功能。

(4)管理工作主要跟踪软件经费支出、进度及功能。识别在承诺方面出现的问题。

(5)采用基线（BASELINE）来标志进展、控制完整性。

(6)定义了软件项目的标准，并相信它，遵循它。

(7)通过子合同建立有效的供求关系。

◆ 过程
(1)软件开发和维护的过程是相对稳定的，但过程建立在项目一级。

(2)有规则的软件过程是在一个有效的工程管理系统的控制之下，先前的成功经验可以被重复。

(3)问题出现时，有能力识别及纠正。承诺是可实现的。

◆ 人员
(1)项目的成功依赖于个人的能力以及管理层的支持。

(2)理解管理的必要性及对管理的承诺。

(3)注意人员的培训问题。

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

◆ 度量
每个项目建立资源计划。主要是关心成本、产品和进度。有相应的管理数据。

◆ 改进方向
(1)不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任。

(2)确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中。从而可以跨项目改进软件过程效果，也可作为软件过程剪裁的基础。

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

(4)积累数据，建立组织的软件过程库及软件过程相关的文档库。

(5)加强培训。

CMM第三级：确定级

◆ 特征
(1)无论管理方面或工程方面的软件过程都已文件化、标准化，并综合成软件开发组织的标准软件过程。

(2)软件过程标准被应用到所有的工程中，用于编制和维护软件。有的项目也可根据实际情况，对软件开发组织的标准软件过程进行剪裁。

(3)在从事一项工程时，产品的生产过程、花费、计划以及功能都是可以控制的，从而软件质量也可以控制。

(4)软件工程过程组（SEPG）负责软件活动。

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

◆ 过程
(1)整个组织全面采用综合性的管理及工程过程来管理。软件工程和管理活动是稳定的和可重复的，具有连续性的。

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

◆ 人员
(1)以项目组的方式进行工作。如同综合产品团队。

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

(3)有计划地按人员的角色进行培训。

◆ 技术
在定性基础上建立新的评估技术。

◆ 度量
(1)在全过程中收集使用数据。

(2)在全项目中系统性地共享数据。

◆ 改进方向
(1)开始着手软件过程的定量分析，以达到定量地控制软件项目过程的效果。

(2)通过软件的质量管理达到软件的质量目标。

CMM第四级：管理级

◆ 特征
(1)制定了软件过程和产品质量的详细而具体的度量标准，软件过程和产品质量都可以被理解和控制。

(2)软件组织的能力是可预见的，原因是软件过程是被明确的度量标准所度量和操作。不言而喻，软件产品的质量就可以预见和得以控制。

(3)组织的度量工程保证所有项目对生产率和质量进行度量、并作为重要的软件过程活动。

(4)具有良好定义及一致的度量标准来指导软件过程，并作为评价软件过程及产品的定量基础。

(5)在开发组织内已建立软件过程数据库，保存收集到的数据，可用于各项目的软件过程。

◆ 过程
(1)开始定量地认识软件过程。

(2)软件过程的变化小，一般在可接受的范围内。 (3)可以预见软件过程中和产品质量方面的一些趋势。一旦质量经度量后超出这些标准或是有所违反，可以采用一些方法去改正，以达到良好的目标。

◆ 人员
每个项目中存在强烈的群体工作意识。因为每人都了解个人的作用与组织的关系，因此能够产生这种群体意识。

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

◆ 度量
(1)在全组织内进行数据收集与确定。

(2)度量标准化。

(3)数据用于定量地理解软件过程及稳定软件过程。

◆ 改进方向
(1)缺陷防范，不仅仅在发现了问题时能及时改进，而且应采取特定行动防止将来出现这类缺陷。

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

(3)进行过程变动管理，定义过程改进的目的，经常不断地进行过程改进。

CMM第五级：优化级

◆ 特征
(1)整个组织特别关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生，不断地提高他们的过程处理能力。

(2)加强定量分析，通过来自过程的质量反馈和吸收新观念，新科技，使软件过程能不断地得到改进。

(3)根据软件过程的效果，进行成本/利润分析，从成功的软件过程中吸取经验，加以总结。把最好的创新成绩迅速向全组织转移，对失败的案例，由软件过程小组进行分析以找出原因。

(4)组织能找出过程的不足并预先改进，把失败的教训告知全体组织以防止重复以前的错误。

(5)对软件过程的评价和对标准软件过程的改进，都在全组织内推广。

◆ 过程
(1)不断地系统地改进软件过程。

(2)理解并消除产生问题的公共根源，在任何一个系统中都可找到：由于随机变化造成重复工作、进而导致时间浪费。为了防止浪费人力可能导致的系统变化。要消除“公共”的无效率根源，防止浪费发生。尽管所有级别都存在这些问题，但这是第五级的焦点。

◆ 人员
(1)整个组织都存在自觉的强烈的团队意识。

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

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

◆ 度量
利用数据来评估，选择过程改进。

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

CMM总结：五层结构图

我们看到，在第五级上，技术和过程的改进像普通商业活动一样有计划、有管理地进行。由于组织不断的致力于改进过程的能力，所以软件开发组织的能力可持续改进。这种改进不仅表现在对存在的软件过程逐步改进，不表现在采用新技术和新方法方面的革新。

画一个图吧：（CMM的五层结构图）
-----------------

/ 优化级 /

/ (5) /

==================================================================================================

软件工程与能力成熟度模型CMM

我们首先讨论软件工程管理的意义。软件工程管理引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。这个结论非常重要。到了20世纪90年代中期，软件工程管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况依然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。在商用软件产业中，这一现象尤为严重。1995年，美国共取消了810亿美元的软件项目，其中31%的项目未做完就取消了，53%的软件项目进度通常要延长50%的时间，通常只有9%的软件项目能够及时交付并且费用也不超支。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件工程管理的意义至关重要。

软件工程管理和其它工程管理相比有其特殊性。首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统复杂程度也是超乎想象的。例如，宇宙飞船的软件系统源程序代码多达2000万行，如果按过去的生产效率一个人一年只能写1万行代码的话，那么需要2000人年的工作量，这是非常惊人的。正因为软件如此复杂和难以度量，软件工程管理的发展还很不成熟。

美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)主持研究与开发的CMM/PSP/TSP 技术，为软件工程管理开辟了一条新的途经。CMM是英文 Capability Maturity Model 的简称，意为能力成熟度模型。CMM的本质是软件管理工程的一个部分。根据软件生产的历史与现状，CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。在某个层次内部，也有成熟程度的区别。在一个较低层次的上沿，很可能与一个较高层次的下沿非常接近，此时由这个较低层次向该较高层次进化也就比较容易。反之，在一个较低层次的下沿向较高层次进化，就比较困难。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单位首先需要了解自己处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化，即软件过程的进化是渐进的，而不能是跳跃的。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还应该得到保持与发扬。

CMM家族包括CMM集成产品集、SA-CMM(软件获取能力成熟度模型)、SE-CMM(系统工程能力成熟度模型)和IDEAL模型。其中CMM集成产品集为工业界和政府部门提供了一系列集成产品，以支持软件过程和产品的改善；SA-CMM用于单位获取和采购基于软件的应用系统的软件过程，美国国防部、陆军、海军和一些商用单位都已采用SA - CMM对他们的获取能力进行评估；SE-CMM是描述一个单位为保证实现一个好的系统工程的主要元素；而IDEAL模型则是一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating(启动)、D代表Diagnosing(诊断)、E代表Establishing(建造)、A代表Acting(措施)、L代表Learning(学习)。

美国曾在1995年做过软件产业成熟程度的调查，发现在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，其特征是软件开发过程不能预测，风险度高；为可重复级的占15%，其特征是软件开发过程需小心谨慎方能避免失败；为定义级的所占比例小于10%，其特征是软件开发过程相当稳定，进展顺利且可以预测；为管理级的所占比例小于5%，其特征是软件过程预测准确、值得信赖；为优化级的所占比例小于1%，其特征是软件过程能持续改善。国内在这方面的起步则要晚一些，据我所知，目前只有清华鼎新公司的CMM成熟度等级达到可重复级。尽管CMM已经是一套发展相当成熟的方法，但国内要想完全掌握并广泛付诸实践，对绝大多数软件企业来说，可能还需要3～5年的时间。

需要注意的是，并不是实施了CMM，软件项目的质量就能有所保障。CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。因此，个体软件过程PSP(Personal Software Process)也就应运而生。PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段，PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。根据对参加培训的104位软件人员的统计数据表明，在应用了PSP后，软件中总的缺陷减少了58.0%，在测试阶段发现的缺陷减少了71.9%，生产效率提高了20.8%。PSP的研究结果还表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。而且根据多年来的软件工程统计数据表明，如果在设计阶段注入一个差错，则这个差错在编码阶段要引发3～5个新的缺陷，要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。PSP的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。

然而实践证明，仅有CMM和PSP还是不够的，因此，CMU/SEI又在此基础上提出了群组软件过程TSP(Team Software Process)的方法。TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍始终以最佳状态来完成工作。TSP实施集体管理与自已管理自己相结合的原则，最终目的在于指导一切人员如何在最少的时间内，以预定的费用生产出高质量的软件产品；所采用的方法是对群组软件开发过程的定义、度量和改进。实施TSP的先决条件有3条：首先，需要有高层主管和各级经理的支持，以取得必要的资源；其次，项目组开发人员需要经过PSP的培训并有按TSP工作的愿望和热情；第三，整个单位在总体上应处于CMM二级以上。在实施TSP的过程中，首先要有明确的目标，开发人员要努力完成已经接受的委托任务。在每一阶段开始，要做好工作计划。如果发现未能按期按质完成计划，应分析原因，以判定问题是由于工作内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起。开发小组一方面应随时追踪项目进展状态并进行定期汇报，另一方面应经常评审自己是否按PSP的原理工作。开发人员应按自己管理自己的原则管理软件过程，如发现过程不合适，应及时改进，以保证用高质量的过程来生产高质量的软件。项目开发小组则按集体管理的原则进行管理，全体成员都要参加和关心小组的规划、进展的追踪和决策的制订等项工作。

总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成，其相互关系可用图1来表示。

目前国内对软件工程管理存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。据国外有些大公司的介绍，他们在软件工程管理方面的投资一般占软件开发费用的10%左右，这些都需要得到高层管理人员的支持。而且软件过程的重大修改也必须由高层管理部门启动，这是软件过程改善能否进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与，否则不仅他本人将失去从软件过程改善中获得提高的机会，甚至还会成为过程改善的阻力。

除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。因此，过程改善工作必然具有一切过程所具有的固有特征，即需要循序渐进，不能一蹴而就，需要持续改善，不能停滞不前；需要联系实际，不能照本宣科；需要适应变革，不能凝固不变。而且我认为，要将CMM/PSP/TSP引入软件企业，最有效的途径是要对单位主管和主要开发人员进行系统的培训。美国 Carnegie Mellon 大学软件工程研究所曾经尝试让软件工程师通过自学的方式来进行，但实际上只有不到20%的人能够坚持到底。另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。现在国内软件产业的发展可以说已经具有一定规模了，但除了北大方正、东大阿尔派、用友等大企业外，做软件工程项目更多的是一些规模在数十人左右的中小企业。也许有人会问，像这样一些人力物力资源匮乏的企业，如何进行软件开发项目的管理呢？我建议这些中小企业可以以CMM为框架，先从PSP做起，然后在些基础上逐渐过渡到TSP，以保证CMM/PSP/TSP确实在企业中生根开花。总之，我们必须从软件过程、过程工程的角度来看待CMM的发展，从经济学的观点来分析这个过程的价值。我相信在实施CMM/PSP/TSP的过程中，只要坚持改善软件工程的管理，并在实践中注意总结适合自身的经验，一定能取得很好的效果。

==============================================================================