CMMI和CMM区别.doc

CMMI和CMM区别CMMI的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在： 不能集中其不同过程改进的能力以取得更大成绩； 要进行一些重复的培训、评估和改进活动，因而增加了许多成本； 不同模型对相同事物说法不一致，或活动不协调，甚至相抵触。于是，希望整合不同CMM模型的需求产生了。1997年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。CMMI与CMM最大的不同点在于： CMMISM-SE/SW/IPPD/SS 1.1版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应地应用SS(Supplier Sourcing)部分。 CMMI有两种表示方法，一种是大家很熟悉的，和软件CMM一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别，帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。 软件CMM 2级共有6个关键过程区域，在CMMI增加了1个：度量和分析。原来的6个关键过程区域的名称和内容在CMMI中作了部分改进，但是主体内容没有大幅调整。软件CMM 4级共有2个关键过程区域，在CMMI中仍是2个，只是名称和内容有所改进。软件CMM 5级共有3个KPA，在CMMI中进行了合并，改为2个，但主要内容未变。变化最显著的在CMMI 3级上，原有的7个KPA变成了14个，其中原来对工程活动进行要求的KPA软件产品工程进行了详细的拆分，并结合常见的软件生命周期模型进行了映射。CMMI中新增的过程区域中还涉及到过去未曾提到的内容，比如决策分析和解决方案、集成团队等。到底是选择CMM还是CMMI主要基于以下几个方面进行考虑： 实施企业的业务特点：如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。 实施企业对过程改进的熟悉程度：如果企业已经实施过ISO 9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。 实施企业对过程改进项目的预算：不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就经济很多。 实施企业是否可以使用阶段式的演进路线： 如果企业只希望单方面的提高自己在项目管理、工程活动、支持活动或者过程管理四个方面中的某些方面的能力，那么就只能应用CMMI的连续表示方法。如果实施企业可以接受成熟度级别的思路（目前看国内大多数企业还是比较习惯于成熟度级别的），那么就不一定必须选择CMMI了。 实施CMM与CMMI可以平滑的转换。一来，CMMI并不要求一家企业必须先做CMMI的2级然后再向更高的成熟级别演进，评估的时候也没有这样的要求。另外， CMMI的评估都会根据被评估的成熟度级别，检查所有不高于该级别的过程区域。换句话说，一个企业在CMM正式评估中达到了2级的成熟度，将来改为基于CMMI进行过程改进。在CMMI 3级的正式评估时，CMMI 2级的内容同样要进行检查。如果我们能够在做CMM 2级的时候就按照CMMI的要求实施，效果没有任何的折扣，但对于实施企业来说，会节省很多在培训和评估方面的“额外”费用。（此处的“额外”费用是指CMMI收费比CMM高出的部分）1CMM/CMMI 的发展 为了保证软件产品的质量，80年代中期，美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。因此，美国卡内基-梅隆大学软件工程研究所 (CMU/SEI) 于1987年研究发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。4年之后，SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM），并发布了最早的SW-CMM 1.0版。经过两年的试用，1993年SEI正式发布了SW-CMM1.1版，这是目前使用最为广泛的版本。 自1991年SW-CMM首次发布后，SEI又开发了其他成熟度模型，包括：系统工程、采购、人力资源管理和集成产品开发等。虽然各个模型针对的专业领域不同，但彼此之间也有一定的重叠，毕竟它们同出一辙；另外，这些模型在表现形式上又有不统一之处：系统工程模型是连续式的，而其他模型采用了分级式。当SEI开始开发新一代成熟度模型的时候，其发起人提出了新的要求：整合不同模型中的最佳实践，建立统一模型，覆盖不同领域，供企业进行整个组织的全面过程改进。所以，SEI于2001年12月正式发布了能力成熟度集成模型（CMMI）1.1版本，这次发布标志着CMMI的正式使用。SEI也正式宣布，将不再维护SW-CMM的CBA-IPI评估方法：在CMMI1.1发布后的两年内，SEI还提供有关SW-CMM和CBA-IPI主任评估员的培训，并接收评估数据，但这一切已于2003年12月底正式停止。 这里需要注意的是，SEI并没有废除CMM模型，而是以CMMI的SCAMPI评估方法取代CMM的CBA-IPI评估方法。当然很多业内人士认为，随着软件行业的发展，CMMI模型将最终取代CMM模型。 CMMI起源于三个模型（源模型），分别是： （1） 软件能力成熟度模型（ SW-CMM）2.0版，C稿 （2） 电子行业协会临时标准（EIA/IS731） （3） 集成产品开发能力成熟度模型（IPD-CMM）v0.98 模型中同时集成了供应管理的内容。另外，在CMMI中除了沿用成熟度等级的方式（即CMMI的分阶段表示形式）外，还吸取TR 15504的特点，增加了与15504类似的CMMI的连续表示形式，以满足ISO15504国际标准对过程改进评估的要求。CMMI模型的组成和适用范围如表1所示。 表1 CMMI模型的组成和适用范围 CMMI模型组件 适用范围 SE/SW 软件工程、系统工程 SE/SW /IPPD 软件工程、系统工程、集成产品和过程开发 SE/SW /IPPD/SS 软件工程、系统工程、集成产品和过程开发、供应采购 培训课程 评估师、过程改进人员等培训 SCMPI 评估方法 在CMMI 模型组件中，SE/SW是核心，SE/SW /IPPD、SE/SW /IPPD/SS是在此基础上扩展而来的。 CMM模型基于众多软件专家的实践经验，是组织进行软件过程改善和软件过程评估的一个有效的指导框架。CMMI项目更为工业界和政府部门提供了一个集成的产品集，其主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。CMM或CMMI不仅是一个模型，一个工具，它更代表了一种管理哲学在软件工业中的应用。 CMM/CMMI的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey和Ron Radice在IBM公司将全面质量管理的思想应用于软件工程过程，收到了很大的成效。SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想，以不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。CMM/CMMI所依据的想法是只要不断地对企业的软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件。 2CMM/CMMI的作用 最近的SEI评估报告显示，从1996年到2003年，全球有2千多个组织进行了CMM/CMMI评估，其中大部分为商业组织，有将近一半的组织规模是在100人以下。这些数据表明，CMM/CMMI评估已经引起软件及IT企业的高度关注，并且这种评估同样适合中小企业。 CMM/CMMI主要应用在两大方面：能力评估和过程改进。 1）能力评估 CMM/CMMI是基于政府评估软件承包商的软件能力发展而来的，有两种通用的评估方法用以评估组织软件过程的成熟度：软件过程评估和软件能力评价。 软件过程评估：用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改善问题，为组织领导层提供报告以获得组织对软件过程改善的支持。软件过程评估集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改善的支持。 软件能力评价：用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要求范围内完成制造出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。 2）过程改进 软件过程改进是一个持续的、全员参与的过程。CMM/CMMI建立了一组有效地描述成熟软件组织特征的准则。该准则清晰地描述了软件过程的关键元素，并包括软件工程和管理方面的优秀实践。企业可以有选择地引用这些关键实践指导软件过程的开发和维护，以不断地改善组织软件过程，实现成本、进度、功能和产品质量等目标。 3CMM/CMMI的主要内容 CMMI中成熟度等级的概念与SW-CMM模型相同，只是某些等级的名称有些变化。1级、3级和5级的名称没有变化，名称还是初始级、已定义和优化中，但是2级和4级分别变为已管理级和定量管理级，这个变化更突出了2级定性管理和4级定量管理的特点。 另外，CMMI能力等级的确定，建立了CMMI和ISO15504之间的有机联系，CMMI连续式模型的3、4级名称虽然与ISO15504有区别，但其含义是基本一样的。 表2列出了CMMI、CMM、ISO15504模型的等级名称的对应关系。 表2 各模型的等级对应 Level CMM CMMI（分级式） CMMI（连续式） ISO15504 5 优化中 优化中 优化中 优化中 4 已管理 定量管理 定量管理 可预测 3 已定义 已定义 已定义 已建立 2 可重复 已管理 已管理 已管理 1 初始级 初始级 已执行 已执行 0 未完成 未完成 CMM/CMMI把软件开发组织的能力成熟度分为56个可能的等级。除了第1级外，其他每一级由几个过程方面组成。每一个过程方面都由公共特性予以表征。CMM/CMMI给每个过程规定了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就能达到，这就表明该关键过程实现了。这种分级的思路在于把一个组织执行软件过程的成熟程度分成循序渐进的几个阶段，这与软件组织提高自身能力的实际推进过程相吻合。这种成熟度分级的优点在于级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。这一点很重要，因为大多数软件组织只能在某一段时间里集中开展少数几项过程改进活动。 CMMI共有分属于4个类别的25个过程域，覆盖了4个不同的领域（相对应，SW-CMM共有18个过程域）。虽然CMMI中的很多过程域与SW-CMM中的基本相同，但有几个过程域的范围和内容发生了重要的变化，另外也有几个新增加的过程域。两个模型的过程域关系比较见表3。 表3 CMMI和CMM过程域关系比较 等级 CMM CMMI 类别 过程域 缩写 过程域 缩写 5 技术更新管理 TCM 组织革新与部署 OID 过程管理 过程更改管理 PCM CAR 缺陷预防 DP 原因分析与决策 支持 4 软件质量管理 SQM 组织过程性能 OPP 过程管理 定量过程管理 QPM 定量项目管理 QPM 项目管理 3 软件产品工程 同行评审 SPE PR 需求制定 RD 工程 技术方案 TS 工程 产品集成 PI 工程 验证 VER 工程 确认 VAL 工程 组织过程聚焦 OPF 组织过程聚焦 OPF 过程管理 组织过程定义 OPD 组织过程定义 OPD 过程管理 培训大纲 TP 组织培训 OT 过程管理 集成软件管理 ISM 集成项目管理 IPM 项目管理 组间协调 风险管理 RSKM 项目管理 决策分析与决定 DAR 支持 集成供应商管理 ISM 项目管理 组织集成环境 OEI 支持 IC 集成组队 IT 项目管理 2 需求管理 RM 需求管理 RM 软件项目策划 SPP 项目策划 PP 项目管理 软件项目监督与控制 SPTO 项目监督与控制 PMC 项目管理 软件分包管理 SAM 供应协议管理 SAM 项目管理 软件质量保证 SQA 过程与产品质量保证 PPQA 支持 软件配置管理 SCM 配置管理 CM 支持 度量与分析 MA 支持 1 4CMM/CMMI的评估 原来的CMM评估须遵循SEI的CAF (CMM Assessment Frame-work) 规范，由CMU/SEI授权的主任评估师(Lead Assessor)领导一个评审小组进行，评估方法采用IPI-CBA，评估过程包括员工培训（企业的高层领导也要参加）、问卷调查和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等，评估结束时由主任评估师签字生效。 随着CMM过渡到CMMI，其CAF评估框架变成评估需求（ARC：Appraisal Requirements for CMMI）；IPI-CBA评估方法被SCAMPI（Standard CNNI Appraisal Method for Process Improvement）方法代替。根据CMMI评估需求（ARC）规定三种评估类型，表4列出了SCAMPI评估方法的适用情况。 表4 可用的评估类型 评估类型 ISO15504兼容 SCAMPI 使用 主任评估师需求 评估组规模 Class A 可能 5-17 Class B - 部分 - 2-7 Class C - 部分 - 2-3 SCAMPI评估组由几方人员共同组成，由主任评估师领导。其中评估小组是由经验丰富的软件专业人员组成，还要经过CMMI和SCAMPI评估方法的培训，使他们了解组织的同时，也懂得如何将CMM/CMMI模型及关键实践与组织的要求建立关联。参与评估的人员包括：公司的管理人员、项目经理，开发人员，培训人员，采购人员等。 评估过程主要分成三个阶段：准备阶段、评估阶段和报告阶段。准备阶段包括小组人员培训、计划以及其它必要的评估准备工作。在评估的最初几十天，小组成员的主要任务是采集数据，回答SEI的CMM/CMMI提问单，文档审阅以及进行交谈，对整个组织中的应用有一个全面的了解。 然后进行数据分析。评估员要对记录进行整理，并检验所观察到的一切信息，然后把这些数据与CMM/CMMI模型进行比较，最后给出一个评估报告。在每个评估报告中，必须针对CMM/CMMI 的每个过程方面，指出这个软件过程在什么地方已经有效地执行了，什么地方还没有有效地执行。只有所有评估人员一致通过的情况下，这个评估报告才有效。 在评估报告的基础上，评估小组产生一个评估结果。评估和评级的结果应与有关的关键过程方面和目标相对应。评估报告和结果将送交所有有关的人员并上报CMU/SEI。 5我国软件能力评估标准的制定与实施 软件已经作为一个新兴高技术产业在我国崛起。但与发达国家相比，无论在开发能力还是管理水平上都还存在一定差距，尤其是落后的软件工程管理制约了开发能力的发挥。某些国家的软件开发能力并不比我国强，但在国际软件市场上的份额却远大于我国，其主要原因之一是我们在软件开发管理方面明显落后。国务院以国发200018号文颁布了鼓励软件产业和集成电路产业发展的若干政策，其中要求通过标准化工作对软件产业发展提供必要的支撑与保障。为了落实国务院18号文的精神，加快我国软件能力模型标准的制定，推动软件产业的发展，信息产业部2000年9月28日主持成立了软件体系评估标准特别工作组，同时提出了 “依据我国软件政策，利用国际先进经验，结合我国国情，制定出有助于指导和促进我国软件企业发展的评估模型标准”的原则，并确定了标准制定的两个主要目标：支持软件企业和企业内的软件组织对自身的软件过程能力实施持续性的内部改进；支持对软件企业的综合软件能力进行第二方和第三方评估。 工作组深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000以及其他有关的资料和文件以及国外企业实施CMM的实际情况，结合国情，确定了以CMMI作为主要参考文件来制定标准。最终形成了SJ/T 11234-2001软件过程能力评估模型和SJ/T 11235-2001软件能力成熟度模型行业正式标准，并于2001年5月1日正式实施。这就是中国的“软件过程及能力成熟度评估”，即SPCA评估。 随着我国经济市场的日益成熟，与信息产业部建立的计算机信息系统集成资质认证体制一样，SPCA评估及其评估结果在市场化运作中将会起到越来越重要的作用。广大用户和企业也越来越接受和认可SJ/T11234和SJ/T11235标准，并将作为企业招投标，选择合作伙伴的一项指标，也是进行第二方评估或评价的依据。这对我国软件企业和产业的提高、发展和壮大也将产生积极的影响。 SPCA依据的评估标准是SJ/T 11234和SJ/T 11235，这两个标准是在深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000、TL 9000以及其他有关的资料和文件以及国外企业实施CMM的实际情况后，结合国内企业的实际情况，以CMMI作为主要参考文件最终形成的，这两个行业标准由信息产业部于2001年5月1日发布实施。 SJ/T 11234软件过程能力评估模型针对软件企业对自身软件过程能力进行内部改进的需要，与C