CMM（软件过程能力成熟度模型）

CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型,以下简称"CMM"),是1987年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。目前，我国已有许多软件企业通过了CMM标准认证 。

企业选择CMM的依据：
1.实施企业的业务特点：如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。
2. 实施企业对过程改进的熟悉程度：如果企业已经实施过ISO9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。
3. 实施企业对过程改进项目的预算：不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。所以，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就会经济很多。

实行CMM认证的必要性：
软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
软件质量是模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。
实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法。
软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。

ISO9000与CMM对系统的集成不同：
ISO 9000族标准是由ISO/TC176（质量管理和质量保证技术委员会）制定的所有国际标准，其中的ISO 9001：2000（或ISO 9001：2008）是质量管理体系的“要求”部分。质量体系评审机构在评审各类企业时，是以企业的质量管理是否满足ISO 9001：2000（或ISO 9001：2008）质量管理体系的要求为依据进行的。
CMM软件能力成熟度模型/CMMI软件能力成熟度集成模型，是美国卡内基梅隆大学软件工程研究所（CMU/SEI）提出的用于评价软件承包商能力的评估模型，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
CMMI是对CMM的升级，其改进不仅完善了CMM本身，而且充分考虑了软件工程与系统工程的集成，使得CMMI不再局限于纯粹软件的范畴。目前的版本为CMMIV1.2，CMMI V1.2模型群中目前具有CMMI DEV 、CMMI DEV+IPPD、CMMI ACQ、CMMI SVC、 CMMI SVC+SSD多个分支。当前软件开发与系统集成企业普遍使用的是基于CMMIV1.2 DEV的评估。
一、ISO9001与CMMI均可用于改进企业过程，但针对性、深入性不同
ISO9001与CMMI两者均可作为企业的过程改善框架，两者是强相关的，两者均强调持续改进。CMMI的过程域与ISO 9001 条款之间的存在着对应关系，类似之处高度重叠，但深入程度与针对性是不同的。ISO9001用于各行各业，没有行业的针对性；CMMI模型针对软件开发企业的软件开发与产品集成需要执行的实践进行了细化，有很强的深入性。
以配置管理为例，软件开发企业要想提供满足用户所需的产品与服务，必须做好配置管理。按照CMMI模型实施企业软件过程控制时，企业可以直接按照CMMI模型要求执行下列实践：
1、确定配置项：确定将纳入配置管理下的配置项、构件及相关的工作产品。
2、建立配置管理系统：建立并维护配置管理和变更管理系统，来控制工作产品。
3、建立或发布基线：建立或发布供内部使用和交付给客户的基线。
4、跟踪变更请求：跟踪配置项的变更请求。
5、控制配置项：控制配置项的变更。
6、建立配置管理记录：建立并维护描述配置项的记录。
7、进行配置审计：进行配置审计以维护配置基线的完整性。
虽然要做好上述实践，还要依据详细定义的具体过程，产出具体的产出物，如：
1、 配置管理相关过程定义：
2、 配置管理计划编写指南
3、 配置管理过程
4、 变更管理流程
5、 配置审计规程 配置管理产出物：
6、 配置管理计划
7、 配置目录结构
8、 配置审计检查单
9、 配置审计报告
10、配置状态报告
11、变更申请表
12、变更评审报告
而对于按照ISO9001体系实施相关过程的企业，在ISO9001条款中是找不到具体需要完成的实践要求的。比如：ISO 9001条款中有对文件控制以及记录控制（4.2.3、4.2.4）的要求，是CMMI中在配置管理CM这个过程域中重点体现的，它定义了必须做的工作实践。同时配置管理CM中对工作实践的描述，也呼应到了ISO 9001 条款中设计和开发（7.3）、生产和服务提供的控制（7.5.1）、标识和可追溯性（7.5.3）、产品防护（7.5.5）、不合格品控制（8.3）、纠正措施（8.5.2）、预防措施（8.5.3）的要求。若想做好配置管理，依然要按照软件工程中配置管理理论建立配置管理体系，定义要执行的过程与具体的产出物，才能满足项目以及企业过程管理控制的要求。
二、ISO9001与CMMI用于改进企业过程的细节不同， CMMI注重提升能力。
ISO9001面向合同环境，站在用户立场对质量体系标准提及地各项要求进行控制，而CMMI是对组织内部过程能力地逐步改善。通过了ISO9000，并不意味着企业软件过程能力达到了一定级别。 作为标准描述细节上差别很大，特别是针对IT企业研发管理问题CMMI有更好的展现。
三、ISO9001与CMMI用于改进企业过程的投入不同。
软件业界普遍关注的是：企业如何以比较低的代价有效地提高软件过程能力。软件过程改进对企业经济效益的贡献是间接的，从投入到产出，时间相对比较长。
 
CMMI为企业带来价值主要体现在以下几个方面：
第一、能保证软件开发的质量与进度，能对“杂乱无章、无序管理”的项目开发过程进行规范。
第二、有利于成本控制。因为质量有所保证，浪费在修改、解决客户的抱怨方面的成本会降低很多。目前绝大多数情况是缺少规范制度，只是求快。项目完成后，要花很多时间修修补补，费用很容易失控。
第三、有助于提高软件开发者的职业素养。每一个具体参与其中的员工，无论是项目经理，还是工程师，甚至一些高层管理人的做事方法逐渐变得标准化、规范化。
第四、能够解决人员流动所带来的问题。公司通过过程改进，建立了财富库以共享经验， 而不是单纯依靠某些人员。
第五、有利于提升公司和员工绩效管理水平，以持续改进效益。通过度量和分析开发过程和产品，建立公司的效率指标。