CMM
能力成熟度模型（Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM）
什么是能力成熟度模型 (Capability Maturity Model)CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。
CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
[编辑本段]能力成熟度模型的历史和发展
信息时代，软件质量的重要性越来越为人们所认识。软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。而软件工程领域在1992年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。
软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件管理工程的意义至关重要。
1987年，美国卡内基. 梅隆大学软件研究所（SEI）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型（CMM），随后在全世界推广实施的一种软件评估标准，用于评价软件承包能力并帮助其改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价和改进。它侧重于软件开发过程的管理及工程能力的提高与评估。CMM自1987年开始实施认证，现已成为软件业最权威的评估认证体系。CMM包括5个等级，共计18个过程域，52个目标，300多个关键实践
[编辑本段]CMM的基本思想
CMM的基本思想是，因为问题是由我们管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。
软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。
必须牢记，软件过程的改善不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。
成熟度等级1：初始级(Initial)。处于这个最低级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和一个优秀的软件开发组来做，则这个工程可能是成功的。然而通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。结果，大多数的行动只是应付危机，而非事先计划好的任务。处于成熟度等级1的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员变化了，过程也跟着变化。结果，要精确地预测产品的开发时间和费用之类重要的项目，是不可能的。
成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验，故称为“可重复”。在这一级采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔细地跟踪费用和进度。不像在第一级那样，在危机状态下方行动，管理人员在问题出现时便可发现，并立即采取修正行动，以防它们变成危机。关键的一点是，如没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。
成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE环境来进一步提高质量和产生率。而在第—级过程中，“高技术”只会使这一危机驱动的过程更混乱。
成熟度等级4：已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量)。
成熟度等级5：优化级(Optimizing)。—个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。
整个企业将会把重点放在对过程进行不断的优化，采取主动的措施去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析各有关过程的有效性资料，作出对新技术的成本与效益的分析，并提出对过程进行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。
在表中可以看出，CMM为软件的过程能力提供了一个阶梯式的改进框架，它基于以往软件工程的经验教训，提供了一个基于过程改进的框架图，它指出一个软件组织在软件开发方面需要那些主要工作，这些工作之间的关系，以及开展工作的先后顺序，一步一步的做好这些工作而使软件组织走向成熟。CMM的思想来源于已有多年历史的项目管理和质量管理，自产生以来几经修订，成为软件业具有广泛影响的模型,并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型，但还没有一个象CMM那样在业界确立了权威标准的地位。但PMI于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的标准。
[编辑本段]实施CMM的必要性
软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。
实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SOFTWARE REUSE)，定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。
[编辑本段]ＣＭＭ基本概念
CMM由低至高共分为5个级别：初始级、可重复级、定义级、管理级和优化级
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）
将各种能力成熟度模型，即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM，
整合到同一架构中去，由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成，
以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。
CMMI框架包括软件能力成熟度模型CMM 2.0草案，系统工程能力成熟度模型，软件采购能力成熟度模型，继承产品和过程开发等。
CMMI的:“关键过程域”25个，“目标”105个， “关键实践”485条。
CMMI的评估方式：
自我评估：用于本企业领导层评价公司自身的软件能力。
主任评估：使本企业领导层评价公司自身的软件能力，向外宣布自己企业的软件能力
CMMI的评估类型：
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估（软件能力成熟度等级评估）。
CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
背景介绍： CMM是“软件能力成熟度模型”的英文简写，该模型由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防部委托，于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用CMM模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用，SEI同时建立了主任评估师评估制度，CMM的评估方法为CBA－IPI。
CMMI是SEI于2000年发布的CMM的新版本。CMMI不但包括了软件开发过程改进，还包含系统集成、软硬件采购等方面的过程改进内容。CMMI纠正了CMM存在的一些缺点，使其更加适用企业的过程改进实施。CMMI适用SCAMPI评估方法。需要注意的是，SEI没有废除CMM模型，只是停止了CMM评估方法：CBA－IPI。现在如要进行CMM评估，需使用SCAMPI方法。但CMMI模型最终代替CMM模型的趋势不可避免。
标准特点： CMM/CMMI/SPCA的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey和Ron Radice在IBM公司将全面质量管理的思想应用于软件工程过程，收到了很大的成效。SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想，以不断进化的层次定量控制中项目管理和项目工程的基本原则。CMM/CMMI/SPCA所依据的想法是只要不断地对企业的工程过程的基础结构和实践进行管理和改进，就可以克服软硬件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件产品。
ＣＭＭ简介
CMM(Capability Maturity Model)是能力成熟度模型的缩写,CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM的工作最早开始于86年11月,当时为满足美国政府评估软件供应商能力并帮助其改善软件质量的要求,由美国国防部资助的卡内基—梅隆大学的软件工作研究所(SEI)牵头,在Mitre公司协助下,于87年9月发布了一份能力成熟度框架(Capability Maturity Framework)以及一套成熟度问卷(Maturity Questionnaire)。四年后，SEI在总结自87年以来对成熟度框架和初版成熟度问卷的经验基础上，推出了CMM1.0版。CMM10版在成熟度框架的基础上建立了一个可用的模型，该模型可以更加有效地帮助软件公司建立和实施过程改进计划。两年后，SEI于93年推出了CMM1.1版。近几年，SEI又推出了CMM2.0版，同时进入了ISO体系，称为ISO/IEC15504(软件过程评估)。
CMM共分五级。在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级，即优化级，达到该级的软件公司过程可自发地不断改进，防止同类问题二次出现；四级称为已管理级，达到该级的软件公司已实现过程的定量化；三级为已定义级，即过程实现标准化；二级为可重复级，达到该级的软件公司过程已制度化，有纪律，可重复；一级为初始级，过程无序，进度、预算、功能和质量等方面不可预测。
CMM致力于软件开发过程的管理和工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用，同时越来越多的欧洲和亚洲等国家的软件公司正积极采纳CMM，CMM实际上已成为软件开发过程改进与评估事实上的工业标准。如今，全球通过CMM五级评估的软件公司大约有十几家，三级以上的大约有100余家，通过二级评估的有300家左右。软件大国印度在这方面工作开展的比较广泛，受益匪浅。目前，我国只有清华同方和IBM的合资公司——鼎新信息开发有限公司于99年7月通过CMM二级评估，该公司表示将争取早日通过CMM三级评估。
CMM与ISO9000的主要区别：
1.CMM是专门针对软件产品开发和服务的，而ISO9000涉及的范围则相当宽。
2.CMM强调软件开发过程的成熟度，即过程的不断改进和提高。而ISO9000则强调可接收的质量体系的最低标准。
引进CMM的主要意义
一.对软件公司
1.提高软件公司软件开发的管理能力，因为CMM可提供软件公司自我评估的方法和自我提高的手段。
2.提高软件生产率。
3.提高软件质量。
4.提高软件公司的国内和国际竞争力。
二.对软件项目发包单位和软件用户
提供了对软件开发商开发管理水平的评估手段，有助于软件开发项目的风险识别。
我国CMM工作的开展相对滞后，全面正式开展CMM评估工作还需一定时间，但只是迟早的问题。业内有识之士呼吁我国应结合国情，及早开展CMM有关工作。我公司作为西安地区软件业龙头企业，应学习、消化和借鉴CMM有关管理思想和方法等先进知识，结合公司ISO9000质量管理等具体工作，不断改进和完善我公司的管理体系，推动我公司各项工作全面发展，并为我公司早日正式开展CMM评估工作打下良好的基础。反映了软件过程
[编辑本段]补充：
CMM在空气流量中还可以表示每分钟送出或吸入的空气总体积，如果按立方英尺来计算，单位就是CFM；如果按立方米来算，就是CMM。相当于m3/min。
CMM与RUP的关系:
RUP是过程框架，RUP能达到CMM2-3级的要求,RUP描述了软件开发中的过程,即软件开发中需要遵循的规则,模板,方法等;CMM不是过程，而是检验过程成熟度的标准.
风量的常用单位为：CMM(立方米每分) CMH(立方米每时) CFM(立方英尺每分) LM(升每分钟)
换算：1CMM=60CMH=35.245CFM=1000LM
[编辑本段]关键过程域：
CMM2:可重复阶段
需求管理：requrement management
软件项目计划：software project planning
软件项目跟踪和监督：software project tracking oversight
软件子合同管理：software subcontract management
软件质量保证：software quanlity assurance
软件配置管理：software configuratione management
CMM3:已定义阶段
组织过程焦点：organization process focus
组织过程定义：organization process definition
培训大纲：training program
集成软件管理：intergrated software management
软件产品工程：software product engineering
组间协调：intergroup coordination
同行评审：peer review
CMM4:已管理阶段
定量管理过程：quantitative process management
软件质量管理：software quality management
CMM5:优化阶段
缺陷预防：defect prevention
技术改革管理：technology change management
过程更改管理：process change management
什么是能力成熟度模型 (Capability Maturity Model)CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。
CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
[编辑本段]能力成熟度模型的历史和发展
信息时代，软件质量的重要性越来越为人们所认识。软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。而软件工程领域在1992年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。
软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件管理工程的意义至关重要。
1987年，美国卡内基. 梅隆大学软件研究所（SEI）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型（CMM），随后在全世界推广实施的一种软件评估标准，用于评价软件承包能力并帮助其改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价和改进。它侧重于软件开发过程的管理及工程能力的提高与评估。CMM自1987年开始实施认证，现已成为软件业最权威的评估认证体系。CMM包括5个等级，共计18个过程域，52个目标，300多个关键实践
[编辑本段]CMM的基本思想
CMM的基本思想是，因为问题是由我们管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。
软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。
必须牢记，软件过程的改善不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。
成熟度等级1：初始级(Initial)。处于这个最低级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和一个优秀的软件开发组来做，则这个工程可能是成功的。然而通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。结果，大多数的行动只是应付危机，而非事先计划好的任务。处于成熟度等级1的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员变化了，过程也跟着变化。结果，要精确地预测产品的开发时间和费用之类重要的项目，是不可能的。
成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验，故称为“可重复”。在这一级采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔细地跟踪费用和进度。不像在第一级那样，在危机状态下方行动，管理人员在问题出现时便可发现，并立即采取修正行动，以防它们变成危机。关键的一点是，如没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。
成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE环境来进一步提高质量和产生率。而在第—级过程中，“高技术”只会使这一危机驱动的过程更混乱。
成熟度等级4：已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量)。
成熟度等级5：优化级(Optimizing)。—个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。
整个企业将会把重点放在对过程进行不断的优化，采取主动的措施去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析各有关过程的有效性资料，作出对新技术的成本与效益的分析，并提出对过程进行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。
在表中可以看出，CMM为软件的过程能力提供了一个阶梯式的改进框架，它基于以往软件工程的经验教训，提供了一个基于过程改进的框架图，它指出一个软件组织在软件开发方面需要那些主要工作，这些工作之间的关系，以及开展工作的先后顺序，一步一步的做好这些工作而使软件组织走向成熟。CMM的思想来源于已有多年历史的项目管理和质量管理，自产生以来几经修订，成为软件业具有广泛影响的模型,并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型，但还没有一个象CMM那样在业界确立了权威标准的地位。但PMI于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的标准。
[编辑本段]实施CMM的必要性
软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。
实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SOFTWARE REUSE)，定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。
[编辑本段]ＣＭＭ基本概念
CMM由低至高共分为5个级别：初始级、可重复级、定义级、管理级和优化级
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）
将各种能力成熟度模型，即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM，
整合到同一架构中去，由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成，
以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。
CMMI框架包括软件能力成熟度模型CMM 2.0草案，系统工程能力成熟度模型，软件采购能力成熟度模型，继承产品和过程开发等。
CMMI的:“关键过程域”25个，“目标”105个， “关键实践”485条。
CMMI的评估方式：
自我评估：用于本企业领导层评价公司自身的软件能力。
主任评估：使本企业领导层评价公司自身的软件能力，向外宣布自己企业的软件能力
CMMI的评估类型：
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估（软件能力成熟度等级评估）。
CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
背景介绍： CMM是“软件能力成熟度模型”的英文简写，该模型由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防部委托，于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用CMM模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用，SEI同时建立了主任评估师评估制度，CMM的评估方法为CBA－IPI。
CMMI是SEI于2000年发布的CMM的新版本。CMMI不但包括了软件开发过程改进，还包含系统集成、软硬件采购等方面的过程改进内容。CMMI纠正了CMM存在的一些缺点，使其更加适用企业的过程改进实施。CMMI适用SCAMPI评估方法。需要注意的是，SEI没有废除CMM模型，只是停止了CMM评估方法：CBA－IPI。现在如要进行CMM评估，需使用SCAMPI方法。但CMMI模型最终代替CMM模型的趋势不可避免。
标准特点： CMM/CMMI/SPCA的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey和Ron Radice在IBM公司将全面质量管理的思想应用于软件工程过程，收到了很大的成效。SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想，以不断进化的层次定量控制中项目管理和项目工程的基本原则。CMM/CMMI/SPCA所依据的想法是只要不断地对企业的工程过程的基础结构和实践进行管理和改进，就可以克服软硬件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件产品。
ＣＭＭ简介
CMM(Capability Maturity Model)是能力成熟度模型的缩写,CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM的工作最早开始于86年11月,当时为满足美国政府评估软件供应商能力并帮助其改善软件质量的要求,由美国国防部资助的卡内基—梅隆大学的软件工作研究所(SEI)牵头,在Mitre公司协助下,于87年9月发布了一份能力成熟度框架(Capability Maturity Framework)以及一套成熟度问卷(Maturity Questionnaire)。四年后，SEI在总结自87年以来对成熟度框架和初版成熟度问卷的经验基础上，推出了CMM1.0版。CMM10版在成熟度框架的基础上建立了一个可用的模型，该模型可以更加有效地帮助软件公司建立和实施过程改进计划。两年后，SEI于93年推出了CMM1.1版。近几年，SEI又推出了CMM2.0版，同时进入了ISO体系，称为ISO/IEC15504(软件过程评估)。
CMM共分五级。在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级，即优化级，达到该级的软件公司过程可自发地不断改进，防止同类问题二次出现；四级称为已管理级，达到该级的软件公司已实现过程的定量化；三级为已定义级，即过程实现标准化；二级为可重复级，达到该级的软件公司过程已制度化，有纪律，可重复；一级为初始级，过程无序，进度、预算、功能和质量等方面不可预测。
CMM致力于软件开发过程的管理和工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用，同时越来越多的欧洲和亚洲等国家的软件公司正积极采纳CMM，CMM实际上已成为软件开发过程改进与评估事实上的工业标准。如今，全球通过CMM五级评估的软件公司大约有十几家，三级以上的大约有100余家，通过二级评估的有300家左右。软件大国印度在这方面工作开展的比较广泛，受益匪浅。目前，我国只有清华同方和IBM的合资公司——鼎新信息开发有限公司于99年7月通过CMM二级评估，该公司表示将争取早日通过CMM三级评估。
CMM与ISO9000的主要区别：
1.CMM是专门针对软件产品开发和服务的，而ISO9000涉及的范围则相当宽。
2.CMM强调软件开发过程的成熟度，即过程的不断改进和提高。而ISO9000则强调可接收的质量体系的最低标准。
引进CMM的主要意义
一.对软件公司
1.提高软件公司软件开发的管理能力，因为CMM可提供软件公司自我评估的方法和自我提高的手段。
2.提高软件生产率。
3.提高软件质量。
4.提高软件公司的国内和国际竞争力。
二.对软件项目发包单位和软件用户
提供了对软件开发商开发管理水平的评估手段，有助于软件开发项目的风险识别。
我国CMM工作的开展相对滞后，全面正式开展CMM评估工作还需一定时间，但只是迟早的问题。业内有识之士呼吁我国应结合国情，及早开展CMM有关工作。我公司作为西安地区软件业龙头企业，应学习、消化和借鉴CMM有关管理思想和方法等先进知识，结合公司ISO9000质量管理等具体工作，不断改进和完善我公司的管理体系，推动我公司各项工作全面发展，并为我公司早日正式开展CMM评估工作打下良好的基础。反映了软件过程
[编辑本段]补充：
CMM在空气流量中还可以表示每分钟送出或吸入的空气总体积，如果按立方英尺来计算，单位就是CFM；如果按立方米来算，就是CMM。相当于m3/min。
CMM与RUP的关系:
RUP是过程框架，RUP能达到CMM2-3级的要求,RUP描述了软件开发中的过程,即软件开发中需要遵循的规则,模板,方法等;CMM不是过程，而是检验过程成熟度的标准.
风量的常用单位为：CMM(立方米每分) CMH(立方米每时) CFM(立方英尺每分) LM(升每分钟)
换算：1CMM=60CMH=35.245CFM=1000LM
[编辑本段]关键过程域：
CMM2:可重复阶段
需求管理：requrement management
软件项目计划：software project planning
软件项目跟踪和监督：software project tracking oversight
软件子合同管理：software subcontract management
软件质量保证：software quanlity assurance
软件配置管理：software configuratione management
CMM3:已定义阶段
组织过程焦点：organization process focus
组织过程定义：organization process definition
培训大纲：training program
集成软件管理：intergrated software management
软件产品工程：software product engineering
组间协调：intergroup coordination
同行评审：peer review
CMM4:已管理阶段
定量管理过程：quantitative process management
软件质量管理：software quality management
CMM5:优化阶段
缺陷预防：defect prevention
技术改革管理：technology change management
过程更改管理：process change management