20世纪，我国科学技术迅猛发展，大大小小的软件企业异军突起。随着改革开放的不断深入，软件企业间的竞争日趋激烈，质量成了软件企业立足的关键。有很大一部分软件企业瞄准了国外的市场，所以引进了国外的CMM来规范企业的质量管理，为我国的软件企业走向世界打下基础。

本文所要论述的方面如下：

1． 概述软件能力成熟度模型；

2． 详细介绍CMMⅡ相关知识及在中国软件企业中的实施；

3． 简述CMM中外发展现状，分析CMM中外差异及在国内实施过程中存在的问题；

4． 通过上述描述，得出相关结论。

一、 引言

从20世纪80年代初期开始的个人计算机革命，加剧了IT界的质量问题，导致现在大家熟知的所谓长期危机，并引起了广泛的关注。在1984年，美国国会与一些主要的公司和研究中心合作，创立了一个附属于卡内基-梅隆大学，由联邦资助的非盈利组织——软件工程研究所（Software Engineering Institute, SEI）。该研究所在美国国防部资助下，成功制定了一套用于评价软件开发组织软件过程能力成熟度的模型，称为软件能力成熟度模型（Capability Maturity Model for Software, CMM）。

随着我国经济建设的不断推进，改革开放的不断深入，国内的软件企业队伍也随之不断壮大。企业间的竞争也日趋激烈，它们也很清楚质量才是取胜的关键。曾有人说“缺乏规范的过程正是国内软件企业的软肋。”，而CMM恰恰能弥补这一点。于是，国内的软件企业为了改进自身的软件过程，提高产品质量，提高软件生产率，从而提高企业的核心竞争力，为获得更多的（国际）订单、进军国际市场打下基础，纷纷做起了国外的CMM，都想以此为契机，增强自己企业的国际竞争力。

二、 软件能力成熟度模型概述

目前我国软件企业的发展环境已开始改善，软件企业面临的突出问题往往在于管理，尤其是技术管理。软件企业在管理上存在一些误区，面临不少难题。在软件企业里重技术轻管理的思想往往还根深蒂固，认为有了好的技术就能开发出用户满意的软件。在技术管理主体方面缺乏既懂技术又懂管理的复合型人才和高级系统设计人才。在管理方式方面也较单一，往往是凭个人经验实施“能人管理”，技术文档缺少或不规范又导致可追溯性缺乏，因此造成管理失控。在管理机制上往往不够健全，缺少可以量化的管理机制，因此不能科学评估和考核技术人才，进行有效激励，造成人才队伍不稳。总之，我国软件行业技术管理水平不高的现象还相当严重，而且较为普遍。不少软件企业虽然已感到管理问题严重，但似乎尚未找到有效的管理方法。

CMM的悄然进入，给我国软件企业带来了一股春风，越来越多的软件企业想通过CMM来改变目前软件企业的现状。我国大多数的软件企业还处在初始级，所以CMMⅡ成了目前企业的首选，想以此为跳板，以便日后向更高等级攀登。

我国软件企业原本都用ISO9000来评估软件企业的质量，但ISO9000是对普遍企业适用的，而软件企业具有特殊性，所以CMM更适合来评估软件企业的质量。

2.1 什么是CMM

CMM是Capability Maturity Model for Software的简称，中文叫“软件能力成熟度模型”，是对组织软件过程能力的描述。CMM是由美国卡内基-梅隆大学的软件工程研究所受美国国防部委托研究制定的一套专门针对软件产品的质量管理和质量保证标准，并在美国，随后在全世界推广实施的一种软件评估标准。它描述了软件过程从无序到有序、从特殊到一般、从定性管理到定量管理、最终到达可动态优化的成熟过程，给出了该过程中五个成熟阶段的基本特征和应遵循的原则、 采取的行动，以帮助软件机构改进其软件过程。

2.2 CMM的核心和目的

CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好的实现商业目标，是一种持续的过程改进理念，是一种集策划、实施与评价为一体的螺旋式上升。它侧重于软件过程开发的管理及软件工程能力的改进与评估，因此CMM被用作评价软件承包商能力并帮助组织改善软件过程质量，是目前国际上最流行、最实用的一种软件生产过程标准，成为当今企业从事规模生产不可缺少的一项内容。

CMM是以软件过程改进为目的，它不是用来判断执行而仅是用来改进过程的，它是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发高质量的软件。企业实施CMM模型并评估可给企业带来如下好处：①指导软件组织提高软件开发管理能力；②降低软件承包商和采购者的风险；③评估软件承包商的软件开发管理能力；④帮助软件企业识别开发和维护软件的有效过程和关键实践；⑤帮助软件企业识别为达到CMM更高成熟等级所必须的关键实践；⑥增加软件企业的国际竞争力。

2.3 CMM的结构和内容

CMM分为五个等级，分别是：初始级、可重复级、已定义级、已管理级、优化级。在每个等级上先设定一组一般目标，再定义一组关键过程域（KPA），在这些关键过程域中设定了一些特定的活动，每个关键过程域又由一些关键实践域（kpa）组成。通过持续的重复、测量和提炼，稳步创造与精化开发环境，随着软件能力成熟度的不断提高，可预见性将大大提高，从而降低风险，提高软件开发生产精度，缩短每单位工程的生产周期。

这五个等级的具体内容分别如下：

初始级：企业一般不具备稳定的软件开发与维护的环境，常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

可重复级：根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重级的过程，一个可重级的过程则能逐渐进化和成熟。这一级建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施，基于过往的项目的经验来计划与管理新的项目。

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

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

优化级：第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。

2.4 CMM的建立和评估

软件企业实施CMM的步骤如下：①提高思想认识，了解必要性和迫切性；②确定合理的目标；③进行CMM培训和咨询工作；④成立工作组；⑤制定和完善软件过程；⑥内部评审；⑦初期评估；⑧正式评估；⑨根据评估的结果改进软件过程。

CMM的评估包括5个等级，共计18个关键过程域，52个目标，300多个关键实践域。每一个CMM等级评估周期约需12-30个月，每一级别的评估由主任评估师领导一个评审小组进行。评估过程包括员工培训、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。

目前受到公认的CMM评估方法有两个：一种是CBA-SCE（CMM-Based Appraisal for Software Capability Estimation），它是基于CMM对组织的软件能力进行评估，是由组织外部的评估小组对该组织的软件能力进行的评估，集中关注识别一个特定项目在进度要求和预算限制内构造出高质量软件所面临的风险。另一种是CBA-IPI（CMM-Based Appraisal for Internal Process Improvement），它是基于CMM对内部的过程改进进行的评估，是由组织内部的小组对软件组织本身进行评估以改进质量，集中关注一个组织的软件过程所需改进之处及其轻重缓急。

附图表：（五个等级就质量、循环周期、生产力、成本的比较）

三、 CMMⅡ相关知识介绍及在中国软件企业中的实施

据软件工程研究所（SEI）估计，就行业总体而言（包括每一个人），大约有75%到85%仍处于初试级。所以CMMⅡ将是大多数软件企业过渡的目标，通过它为跳板，向更高的等级攀升。CMM对中国而言也是一个新的事物，正处在刚刚起步阶段，很多企业也正着手尝试CMMⅡ的实施，向更高等级迈进作准备。通过引入CMM的理论，与中国的具体国情和实践相结合，引导中国的软件企业向国际化方向迈进，推动中国软件生产过程的科学性和合理性，使国内的软件质量更上一层楼。

3.1 CMMⅡ概述

CMMⅡ是CMM结构中的第二等级，称为可重复级。CMMⅡ的标志是“可重复”，意味着两件事：一是过程。即必须有某种东西可以重复，另一是学习，即要了解过程在项目中起什么作用，然后选择其中适用的部分，抛弃不适用的部分，并在下一个项目中提炼这一过程。也就是质量的持续改进。CMMⅡ是以项目为核心的，着眼于由项目到项目的过程重复。它的意图是使组织能设计出适用于个别项目的基本过程，要使过程足够精确化，并证明它们一般都能导致成功，然后，在CMMⅢ便可以在全组织范围内将其制度化。CMMⅡ共有6个KPA，分别是：需求管理，软件项目策划，软件项目跟踪与监督，软件配置管理，软件质量保证，软件子合同管理。每一个KPA都由5种关键实践域（kpa）组成，分别是：执行约定，执行能力，执行的活动，测量与分析，验证实施。为保证每个KPA的遵从性，要保证结构、过程、培训、方针四个方面的到位。通过使用这种SPTP（结构-过程-培训-方针）的方法，按照方针、结构、过程和培训需求来考虑每个KPA，便可在组织中经济而有效地建立起一个遵循等级2的大纲。

3.2  创建CMMⅡ结构

为使软件开发团队走向CMMⅡ成熟度，除其他事情之外，要确保有一个合理的团队结构，以支持CMMⅡ的方法学。所谓“合理的结构”是指要具备合适的人和工具，以及必要的工作环境，此环境能够支持过程质量活动。这里的核心因素是责任，使结构能与使命相匹配的责任。这里的精神实质是当评估组织是否真正符合CMMⅡ要求时，应当取得足够的共识。CMMⅡ的组织结构能支持5种基本活动：需求管理，项目策划，项目跟踪与监督，配置管理和软件质量保证。

3.3  创建CMMⅡ过程

过程是在CMMⅡ中开始引入的。在CMMⅡ中，组织不仅视过程为焦点，而且以过程为中心，表现在软件项目策划与管理方面。CMMⅡ的过程不需要包罗万象，也不要求完美无缺，但过程必须文档化，必须具有可遵从性。

CMMⅡ的过程概要如下：

需求管理——该过程将文档化的需求传达给软件工程组，并在整个项目周期内管理需求。

项目策划——这些过程生成软件开发计划（SDP），并对SDP进行评审，予以批准。

估计——这是一组过程，它们引导SEG（软件工程组）去估计项目计划中的变量，包括各成分的规模、工作量和成本，以及所需的资源和时间进度。

项目跟踪——该过程用以指导软件项目管理中有关跟踪与监督的职责。本过程以及上述项目策划过程，可能是等级2的核心过程。所有旨在项目管理的活动，均由这一核心过程加以协调。需求管理、配置管理甚至SQA任务都汇聚到跟踪过程，并在跟踪过程中加以说明。

配置管理——该过程使用某种库管理系统来管理项目的工作产品，对产品进行形式化的版本控制。这些产品都是一些输出，可能包括源程序代码、项目计划和更改申请等等。

更改控制——该过程用来规范更改控制委员会的工作，说明如何管理、评估和批准项目的更改申请。

软件质量保证——SQA分析员使用该过程，以监控与审计项目活动的遵从性。

高层领导者评审——这是一个过程，或一个规程，指导管理人员定期评审CMMⅡ中各KPA的过程与方针。

3.4  创建CMMⅡ培训大纲

在CMMⅡ中，CMM认为组织在过程方法学方面还不够稳定，尚未将角色和职责稳固地确定下来。因而，CMMⅡ的培训多数是非正式的、灵活的。培训的主要目标是：在每一个项目中，让人员做好准备，使自己的运作遵从已经到位的质量过程与规范。但在CMMⅡ中还没有将培训列为一种主要的结构化的约定，在CMMⅢ中培训自成一种关键过程域（培训大纲）。

CMM要求两种培训，即结构化培训与应用领域定向培训。结构化培训是“深层”培训，通常以比较正规的形式进行，使用教员-学员培训方式。分为四个培训区域：直接过程培训，间接过程培训，工具培训和角色培训，这四个培训区域对每一名雇员都要进行一次。应用领域定向培训的深度通常要浅一些，可以是正式的，也可以是非正式的，时间也可长可短。分为业务/运作定向培训和技术/构架定向培训。结构化培训只需进行一次（或在过程发生变化时再进行一次），应用领域定向培训在新项目开始时进行，或新成员加入项目时进行。

需接受培训的人员包括：需求分析员、项目策划人员与项目经理、软件质量保证分析员、配置经理以及配置控制委员会成员、软件工程组等人员。

3.5  创建CMMⅡ方针

一般地说，我们遇到（或创建）的方针都有四个共同的性质。首先，方针必须是书面的。其次，创建一个方针，应当被理解为是对过程的一种正式的承诺。第三，方针文档化之后，就要使任何有关的人员和组织得到它。第四，还要特别予以注意的是，方针应当使用简明、精炼的语言，成为有关行为、态度或立场的概要。即文档化、承诺性、充分发布与简短性。

在CMM大纲中，方针的创建与使用占据重要的地位。不仅在CMMⅡ中引进了方针（CMMⅡ是走出混沌的第一步），实际上，从CMMⅡ到CMMⅥ，方针塑造了CMM大纲的基础。

在CMMⅡ中，对于每一个项目，各关键过程域都要求有一个专门的主管方针到位。CMMⅡ包括5个方针：

需求管理：在项目中指导需求的条件与使用的方针

项目策划：一个方针，它管理着如何创建和批准项目策划材料，以及如何做出与项目有关的正式约定。

项目跟踪：一个指导工作方式的方针，它使项目资源及约定始终与项目进展保持一致。

配置管理：一个方针，它说明各项目的配置管理资源与工具的使用与可得性。

软件质量保证：一个针对SQA使命的方针，它管理着SQA的监督与报告职责。

3.6  子合同管理

子合同管理是项目与监督的实际的外延，是项目范围的延伸。子合同管理的目标是：必须选择有资格的分包商；项目选择了一个分包商之后，在工作开始之前，软件项目管理者与供应商首先要就约定达成协议；在项目进展期间，要与供应商经常交流情况；对照已文档化的、彼此同意的分包约定，跟踪供应商的进展。

为向项目的子合同管理提供足够的支持，需要做好两件事：其一，为项目指定一名子合同经理，由他将一部分工作分割给外部供应商。其二，项目管理人员要为子合同管理分配足够的经费与资源，以便完成子合同管理任务。

3.7  CMMⅡ在中国软件企业中的实施及在实施中存在的技术问题

对大多数国内软件企业来说，CMM的实施还处于起步阶段，准备实施

CMMⅡ的企业占绝大多数，因此，分析CMMⅡ实施过程中的问题，将有助于这些企业尽快找到适合本企业的实施方式。

㈠需求管理与需求工程

需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点：

⑴缺乏良好的需求规格说明编写模板

分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。

⑵较严重地忽略了非功能性需求

非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。

如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。

⑶缺乏对需求文档的配置管理

采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。

⑷需求规格说明缺乏可测性

在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。

⑸缺乏较好的需求规格说明转化规范

需求规格说明转化，从一定意义讲，就是“软件需求规格说明书”的规范化问题。

同时“软件需求规格说明书”的评审过程也是明确“软件需求规格说明书”的科学性。——因为这个过程是评审专家对系统的正确理解的过程。

需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。

需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得好坏对需求管理实施的工作量有很大影响。

㈡配置管理与工作产品的转化

软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。

配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，“较好的可转化性”是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点： ⑴需求规格说明书编写不好或不全；⑵工作产品模板定义不好；⑶工作产品之间转化缺乏规范定义。

㈢项目计划与数据收集和分析

项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。

一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。

㈣质量保证与实践反馈

实践反馈是质量保证体系得以有效运作的驱动力，企业应该为所有项目建立一条从SQA到项目经理以及更高层经理的反馈渠道。实践反馈是SQA组与高层经理相互沟通的过程，SQA组定期向高层经理汇报SQA的活动，并及时与项目组沟通，使项目组能尽早改进工作；当沟通不畅、发现项目组运作不力或发现组间协调困难时，应及时报告高层经理，通过高层经理的协调及时进行修正。

有些项目经理认为自己心里有一套计划，只要按计划进行就可以按时保质完成项目，但事实并非如此，在项目组之间的协调问题上，高层经理的作用是非常明显的。如果仅仅为满足CMM的要求而虚设高层经理，这种做法是不可取的，因为如此一来，实践反馈是不完全的。

SQA组在CMM实践中犹如一个司法机构，但这还不够，它还应该为改进过程管理提供资源。SQA组不一定完全由专职人员组成，也可调配一些擅长软件开发方法和软件过程管理的人员参与主要的SQA活动。

㈤同行评审

从理论上讲，同行评审这个关键域的实施并不难，但实际上大多数企业都掌握得不够好，主要表现在以下方面：

⑴评审时组间争论过多或过少

这一问题在不同企业的表现也不同。调查表明，争论较多的情况是工作产品的输入/输出不清楚，组间缺乏沟通的公共平台，因此组间只有通过较多的讨论甚至争论才能弄清其他组的需求。遗憾的是，事后大家并没有坐下来认真讨论如何改进原工作产品的模板形式或表现形式，因而也就无法从根本上解决问题。另一种较极端的情况是，评审一个组的工作产品时，其他组很少发表意见，尽管有些问题是十分明显的。通过调研发现，这实际上是企业文化的问题。一种普遍的想法是“等我们实际做的时候自然就清楚了”，但实际情况往往事与愿违，这使企业的工作效率大打折扣，但又不易被管理层意识到。无论是哪种情况，最终的原因是：“项目甚至企业缺乏持续改进过程管理的意识。”

⑵缺乏心理训练

做好同行评审的最大挑战是克服心理障碍。简单地说，同行评审就是被别人挑错或挑别人的错。因此，评审会就像是答辩会，必须做好充分的准备。当角色互换，自己成了挑错方时，则应该把被评审的工作产品看成是自己在较早前完成的，现在再做一次修改，且修改完成后，自己要拿它去参加评审答辩。经历几次这种心理角色换位，就会逐渐适应。如果大家都这么做，同行评审就会形成良好的氛围，这对形成健康的企业文化将起促进作用。

⑶竞争与合作意识不充分

从另一个角度看，同行评审又是竞争与合作的最佳表现场所和形式，凡在这种场合讲话有理且意见中肯的人逐渐会成为团队的核心人物。在这种竞争的环境中，合作是基础，同行评审的目的就是在合作的前提下尽早且有效地排除工作产品中的缺陷。把握好竞争与合作的尺度，将有益于企业文化的发展，否则有可能出现恶性循环。如何把握呢？从大量的案例看，多数消化少数是较好的方法，因为文化是不可创造的。

⑷考虑不全面

同行评审存在的另一个问题是评审时仅注意工作产品内容本身，大家面对面地弄清内容后，却忽略了如何改进工作产品的表现形式，使新表现形式下的工作产品可更好地用书面形式表示，进而可减少面对面沟通的需求。当然，面对面的沟通并不是不好，但如果一个工作产品需要太多的口头表达才能被理解，则原因只有两个：书写不清楚或模板定义不好，如果是后者则情况更糟。

㈥缺陷预防与度量

缺陷预防的目的是为了识别产生缺陷的原因并防止其再次发生。一些实施低级别CMM的企业通常都采用一些度量（metrics）来预防缺陷，包括软件大小、软件设计错误、编码错误、测试错误、设计评审覆盖、编码评审覆盖、产生测试覆盖、与过程原因相关的缺陷、与项目原因相关的缺陷等。

个别企业选用了一些难度更大的度量。大多数情况下，这些企业并非要达到更高级别的CMM，而是从产品需求的特性出发，对工作产品进行缺陷分析和预防。其过程通常是：获取数据、数据整理、度量、发现原因并确定过程的改进措施，其典型例子包括设计复杂性与测试覆盖及测试深度、模块复杂性与测试覆盖及测试深度等。这类企业的软件产品一般具有以下特点：软件产品规模较大，通常在软件产品交付给用户后，通过相当长时间的不断维护，稳定性才能达到满意程度。如果在早期对可能产生较多错误的软件模块进行识别，加强对这些模块的早期关注和测试，就可较早地使系统达到稳定。这种方法常常用在大型软件开发中，但真正用好的并不多，主要原因有以下几点：

⑴忽略了使用度量的环境

大多数工作产品的度量都是为某一种特定的设计方法或编程语言设计的，忽略了这个因素，度量就容易失去准确性。此外，软件产品不同的行业特性往往也是造成度量产生偏差的原因。

⑵忽略了对度量参数的修改

一些度量参数是在原来的实践环境下确定的，当在新环境下使用时，其中的参数很可能需要进行修改，才能使度量的准确性得到保证。

⑶忽略了对相关性的研究

使用的度量与缺陷在本地的相关性越高，度量的价值就越大。获取这种相关性的方法一般是对本地的历史数据进行相关性研究，企业只有在确认满意的相关性后才可将度量用于缺陷预防。

3.8  国内实施CMM的四点障碍

㈠制度化理念与既有企业文化的冲突

体系实施是遇到的诸多问题，包括领导重视程度不够，开发人员、项目经理抵触情绪，质保人员和软件工程人员得不到应有的尊重和权威等等，归根结底是文化冲突。ISO9000和CMM体系都是基于法治的体系，而国人普遍习惯于人治的氛围，大到整个国家小到一个企业莫不如此，这种冲突正是很多问题的根源。这种冲突体现在两个层面上，一是社会的文化环境与少数企业制度化要求的冲突，二是企业基础管理的不完全制度化和质量管理的制度化特质的冲突。

㈡ISO9000咨询中的问题对市场的抑制作用

以往企业做ISO9000过程中发生的种种问题，造成了社会上对类似质量管理体系的怀疑态度，也会成为企业实施CMM的障碍。特别是，CMM的实施不是在短时间内可以看到显著成效的，它强调“逐步改进”，而非突变。每升一个级别可能会花费1－2年。这样的情况下，如果企业管理者没有一个坚定的支持态度，很难保证实施不被半途而废。而这样的失败又成了新的打击人们信心的案例，造成恶性循环。从整个企业的层面来看，通过实施质量体系，事实上改造了原有企业文化，使制度化的观念深入人心，为企业引入西方先进的管理思想、推行全面的制度化管理奠定了思想和文化基础。

㈢企业人员的质量和质量管理意识有待提高

任何体系的实施都离不开其主体－人。企业实施质量体系过程中各层次人员进行不同的定向培训。对于开发人员来说加强软件工程的培训和实践应从学校教育就开始，进入企业后再进行有针对性的再教育。有些规模比较大的国外企业入职再教育的时间可能长达1－2个月。国内企业却常常抱怨没有时间和不愿意为此投入资金，造成体系的贯彻没有基础。不仅是对于开发人员，对于项目管理人员的管理培训，对体系的实施起着至关重要的作用。因为项目管理人员处在承上启下的关键位置，体系的落实、组内配置管理、组内质量数据的收集等都离不开这一层管理人员的配合。而实际情况是，项目管理人员往往都是从技术出身，管理意识不足是普遍存在地问题。这层管理人员进行强化的质量意识培训和项目管理培训是非常迫切的。如果通过培训能使大家明白怎样做一个合格“科研管理人员”，真正增强其管理的意识，会发现项目经理会主动配合质量管理工作，因为他们认识到，质量管理其实是项目管理职能中非常重要的部分。

㈣顾问公司水平和服务亟待改善

ISO9000和CMM都只提要求，没有告诉怎么做，具体的实施和应用需要由顾问公司协同企业来做。当前，顾问公司所提供的服务是浅层次咨询，只是把标准的知识引进来，怎么使用基本是企业来琢磨，最后顾问公司再验证要素的覆盖程度。顾问公司不对体系的效率负责，只管要素覆盖，是因为要素覆盖是与拿证书相关的。强调在原模式的基础上建立ISO9000体系，而不能进行流程重组。这其实反映了顾问公司的非专业化，只对质量管理熟悉，对其它管理不了解，对细分的行业特征不了解。这个观念我觉得要转变，一个好的顾问公司应该协同顾客研究其流程，提出重组的建议，流程的建立不仅要考虑要素覆盖还要兼顾流程效率。实施参与深度不够是一方面，参与时间也偏短，我们一般一个咨询周期6－8月，而国外1－2年的周期是很多的。6个月的时间往往只是体系的初步建立，还很粗糙，要运行和完善为一个比较可行的体系，还需要大量的时间，这个过程仍然不能没有咨询公司的参与和指导。

四、CMM中外发展现状

从1986年前后，由W.S.Humphrey等人提出软件能力成熟度框架和成熟度等级等概念，正式形成软件能力成熟度模型CMM，至今已有十多年的历史。CMM已在世界各地得到推广实施和应用，并结合各地的特点使其不断完善，引领世界软件企业向着良性方向发展。

4.1 CMM在美国

1984年美国国防部为降低采购风险，委托卡内基-梅隆大学软件工程研究院（SEI）制定了软件过程改进评估模型，也称为SEI SW-CMM，简称为CMM。该模型于1991年正式推出，迅速得到广大软件企业及其顾客的认可。现在美国10-15%的软件客户都是大公司，如波音公司、洛克希德公司等，他们一般都要求软件供应商通过较高级别的CMM评估。所以CMM是由美国最早提出并实施的。

4.2 CMM在欧洲

欧洲许多国家除独立研究与实践有关软件成熟度的软件工程理论和方法外，也引进了CMM评估。英国著名的路透集团就是其中之一，该集团在CMM评估中对包括经理在内的所有员工都进行了培训，目前已有64名从事CMM评估的全职人员。

4.3 CMM在印度

全球在通过CMM4级和5级评估的软件企业中，印度占了相当大的比重。印度对于软件人员进行软件标准培训非常重视，印度大软件公司对于新员工要进行5-8周的入门培训，以后新员工还要受导师培训。印度每年定期进行CMM培训，现已培训了大批的软件人员，现已成为仅次于美国的软件出口大国。

4.4 CMM在中国

经过多年的发展，中国的软件产业已经初具规模，并展现了广阔前景，中国是21世纪世界软件产业市场容量最大的国家。但是，目前我国的软件业仍处于小、散、软的状况。为了改变这一现状，国内部分省市采取了政府扶持软件企业的政策，鼓励软件企业通过CMM认证并予以不菲的奖励。如：山东省提出要发展成为中国的软件大省，2005年软件产值要达到250亿人民币；已经建成齐鲁软件园、青岛软件园、东方软件园和威海软件园，从事软件开发的企业达到了540家，从业人员3万，2000年产值20亿人民币；目前有浪潮和齐鲁软件等5家企业在做CMM评估。广东省软件产业2000年达到80亿人民币，珠海和深圳对于通过CMM2级的软件企业给予50万奖励；深圳市政府在2002年拿出近千万元巨资，对全市200家软件企业进行CMM培训。上海市建立了软件出口联盟和一个软件园及两个培训中心，对于通过CMM2级的企业奖励30万元，通过CMM3级奖励50万元人民币；2001年上海软件出口产值达到了5亿美元。目前昆明市政府已经投入资金对一些骨干软件企业进行了CMM培训，并逐步对这些企业进行CMM2级评估，为把昆明建成中国未来的“班加罗尔”打下坚实的基础。

4.5 SW-CMM与CSCMM的区别

SW-CMM是美国SEI提出的软件能力成熟度模型，CSCMM是符合我国国情和软件开发水平的软件能力成熟度模型，现对两者作一简单的比较。

CSCMM是参照了SW-CMM和其他的相关技术资料，经过多年的调查、分析和研究，提出并逐步形成的符合我国国情的一个软件能力成熟度模型。所以CSCMM是在SW-CMM的基础上提出的，两者具有很多相似之处。

CSCMM与SW-CMM的主要区别在于，它把软件过程的进化分成6个成熟度等级，比SW-CMM多了1个等级。这6个成熟度等级定义了一个循序渐进的度量标准，用以测量软件开发组织的软件过程成熟度和评价其软件过程能力。它为软件过程的不断改进给出了一个循序渐进的进化途径，帮助软件开发组织对其各项过程改进工作排出优先次序。CSCMM是一个6层模型，在原SW-CMM的过程成熟度等级1和等级2之间插入了一个基本级，使得成熟度等级的划分更加均匀，便于软件开发组织更容易地升级。

CSCMM适当细分成熟度等级的原因主要是：当前我国多数软件开发组织没有适当实施软件工程基本过程，如果等级划得较粗，则一些软件开发组织很可能长期达不到2级而一直停留在1级上。这样做容易使他们失去信心，对软件开发组织过程能力的提高有利。其次，经过分析发现，把原SW-CMM的可重复级适当改造和细分不但十分有利，而且是完全可能的。

五、 小结

目前国内的绝大部分软件企业仍处于CMM的初级阶段，没有基础和经验。在实施CMM的过程中，往往感到迷茫，不知从何处下手。试析，软件企业可从如下做起：

1、 提高思想认识

近年来，随着国民经济持续增长，作为高新技术的软件产业虽然发展很快，但和国外同行业相比仍存在很大的差距。究其原因，投资环境、人才和技术固然是制约因素，但管理和政策显得更为关键。随着电子信息产业的发展，人们已经逐步认识到，软件是促进我国电子信息产业发展的关键技术。而要发展我国的软件产业，在战略上，必须将软件产业作为我国高新技术产业的龙头和国民经济发展的新增长点，在策略上，必须走软件过程管理专业化的道路。

CMM在中国的实施，从整体上看处于起步阶段，很多软件公司对ISO9000了解较多，也有很多公司都通过了ISO9000认证。相对而言，了解CMM的就不多了。具备一定规模的软件企业，对CMM非常感兴趣并表示了极大的关注，有部分公司也在积极实施CMM，但正式推行CMM需要在人力和经费上增加投入，一般的软件中小企业有一定困难。

根据全球软件销售额数字分析，今后几年软件和信息服务的市场规模将有一个巨大的发展。然而中国这样的一个大国，软件销售额还不到世界市场的0.5%。我国软件企业除少数几家在500人以上外，多数是在50人以下的民营、集体和个人的软件公司。以开发技术和规范化程序来衡量，总体上仍是相当落后的，大多数企业仍为手工作坊式制作，产品缺乏市场竞争力。因此，软件过程管理已成为发展我们软件产业的一个关键性问题。

实施CMM对软件企业的发展起着至关重要的作用，CMM过程本身就是对软件企业发展历程的一个完整而准确的描述，企业通过实施CMM，可以更好地规范软件生产和管理流程，使企业组织规范化。而且，只有在国际市场取得成功的产品和企业才具有长久的竞争力和生命力，由于CMM已获得国际企业和用户的广泛认可，因此必须在软件企业实施CMM。

2、 进行CMM培训和咨询工作

任何一个软件企业要想实施一套先进的管理措施，首先应该做的就是理论基础的建设，作为一个过程式管理方法的CMM，同样也不例外。根据CMM模型的要求，一个项目的开发一定要有章可循，而且要做到有章必循，这两点都离不开培训。培训工作需要投入很大的人力、物力和财力，只有企业的管理人员和软件开发人员对CMM真正了解和认识了，自觉地按CMM的方法去进行工作，才能真正实施CMM，而不是一时应付，做表面文章。

培训的内容需要精心地准备，主要有两个方面，第一，对所有员工包括经理在内的最基本的软件工程和CMM培训知识；第二，对各个工作组的有关人员提供专业领域知识等方面的培训；此外，在每次开发过程中，还要对普通人员进行软件过程方面的培训。

培训的方式有很多，第一，向有关专业培训咨询机构进行咨询。这些培训公司为CMM知识的引入起着主导作用，他们来源于各种背景，有国家有关研究所、相关协会、大学、原ISO9000咨询公司、新创办的CMM咨询公司、实施过CMM的企业等，但这些培训咨询公司主要集中在北京、上海，尤其是北京。第二，利用互联网资源进行咨询和培训。第三，聘请有关CMM专家到企业实地指导CMM的实施。企业职工可在被指导过程中逐步掌握CMM的要领和实施过程。值得注意的是，企业可以在最开始阶段聘请一位经验丰富的CMM专家，但以后一定要培养自己的专家，这样不仅能节约开支，还能使企业自己具有一个对CMM深刻理解的、有实践经验的专家，为企业今后的继续升级打下一个良好的基础。

3、 确定合理的目标

CMM模型划分为5个级别，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级的评估周期（从准备到完成）约需12-30个月。无论一个软件企业的软件过程处于什么样的水平，都可以在CMM框架的5个级别中找到自己的位置。CMM框架的不同级别是针对处于不同管理水平的软件企业制定的，一个软件企业实施CMM，首先必须了解自己的管理现状，对照CMM的级别，找到自己在CMM中所处的位置，然后有针对性采取与自己所处级别相适应的措施，使企业迟早纳入CMM的进化阶段，使软件过程管理早日得到改善，最终达到提高软件质量，获取经济效益的目的。

因此，要实施CMM，首先应该对本企业的现状有一个准确的评估。企业目前处于什么水平，企业发展的问题是什么，借助CMM要达到的目的是什么。然后再结合企业的实际情况选择CMM的切入点，确定总体目标。这个目标包括在多长时间之内，需要投入多少人力、物力和财力，要达到哪一级。

由于软件过程的建立和改进是一个渐进的、分轻重缓急的、逐步完善的过程。所以，在总体目标已经确定的前提下，还要制订近期目标和长期目标。

4、 成立工作组

企业针对CMM的实施，应成立专门的CMM实施领导小组或专门的机构。CMM的实施需要有强有力的组织保证，领导层必须真正学习理解软件过程管理和改进的重要性，亲自领导和参与，要保证过程管理的人员配备，抽调企业中有管理能力、组织能力和软件开发能力的骨干人员，确实把此项工作当作企业生存和发展的大事来抓。

在CMM的实施过程中，工作组的成立是CMM的一个关键步骤。有几个重要的组织是必不可少的，这些组织包括软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。

软件工程过程组是由专家组成的组，全心全意推进组织所采用的软件过程的定义、维护和改进工作。软件工程过程组统领CMM实施活动，协调全组织软件过程的开发和改进活动，制定、维护和跟踪与软件过程开发和改进活动有关的计划，定义用于过程的标准和模板，负责对全体人员培训有关软件过程及其相关的活动。

在CMM的实施中组织机构的设置必须完善，但不等于说每一个机构必须是独立的。当有些组织较小时，机构可以适当合并，成员可以身兼数职。但对那些关键实践要求独立性时，组织必须十分小心。在这里还要提到一点，那就是物理组和逻辑组。在CMM中有两种组织，一种叫物理组织，它是客观存在的，例如项目组、技术部等，有众多专职人员；另一种叫逻辑组织，就是说它的人员可以是兼职的，在用不到的时候，成员有自己的工作，而且很多逻辑组只需一两个人就可以了。

5、 制定和完善软件过程

CMM模型强调软件过程的改进，如果企业还没有一个文档形式的软件过程，则首要任务是对当前的工作流程进行分析、整理及文档化，从而制定出一个具有本企业风格的软件过程，并用该文档化的过程指导软件项目的开发。

如果已经具备了软件过程，则要对这个过程做内部评估，对照CMM的要求，找出问题，然后对这个过程进行补充修改。在具体实施的过程中，可以选择有一定代表性和完善性的项目组或项目进行试点，跟踪、监督改进后的软件过程的实施情况，执行改进活动的状态。同时，过程小组的成员还应该维护过程中的数据库，定期统计各个过程中的产品和规模、开发周期、修改次数及评估周期。这些数据库可用来分析项目的效率以及存在的问题，以便今后进一步的改进，同时还可以为项目开发实事求是过程提供咨询。 

总结这些项目组或项目以前成功的经验，从中规划出一个具有实际意义的软件过程，按照CMM规范评估这个过程，找出其中的优缺点。对不满足CMM要求的地方加以完善，使其成为一个完美的实施CMM的软件过程方案；然后将这个软件过程应用到当前正在承接的或即将承接的项目上，在实际使用过程中进一步发现其中的不足和错误之处，加以改进，最后将试点的结果推广到整个企业。

6、 内部评审

CMM每一级别的评估都由美国卡内基梅隆大学的软件工程研究所（CMU/SEI）授权的主任评估师领导一个评审小组进行。目前，全世界一共只有三百多个主任评估师，大部分在美国，而我国大陆还没有一个主任评估师。由于我国在CMM评估中要聘请外籍主任评估师，所以费用较高。据估计，要通过一个级别的CMM评估，费用是通过ISO9000认证的十多倍。

因此，软件企业在进行正式评估之前，可以先进行内部评审或评估。这种内部评审包含两层含义。第一种就是软件企业组织自己内部成员，严格、认真地按照CMM规范评估过程，对自己的软件过程进行评审，找出其中的不足点并进行改进。第二种含义就是在全国范围内，由有关软件工程和CMM专家组成一个专门的“内部评审”机构，负责指导协调实施CMM的活动，推进活动的深入开展，对国内软件企业CMM评估进行“预先评估”。这种预先评估，可降低软件企业通过正式CMM评估的风险，减少软件企业实施CMM的成本，为企业最终获得国际CMM认证打下基础。

7、 正式评估

CMM正式评估由CMU/SEI授权的主任评估师领导一个评审小组进行，评估过程包括员工培训（企业的高层领导也要参加）、问卷调查和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等，评估结束时由主任评估师签字生效。

目前主要有两种基于CMM的评估方法，一种是CBA-SCE(CMM-Based Appraisal for Software Capability Estimation)，另一种是CBA-IPI(CMM-Based Appraisal for Internal Process Improvement)，这两种评估均由CMU/SEI授权的主任评估师领导，参考CMM框架来进行，都要审查正在使用和将来使用的文件/文档，并对不同的组织员工进行采访。SEC与IPI两评估结果应该一致，评估结果的所有资料都将呈报CMU/SEI。

CBA评估过程主要分成两个阶段：准备阶段和评估阶段。准备阶段包括小组人员培训、计划以及其它必要的评估准备工作。在评估的最初几天，小组成员的主要任务是采集数据，回答SEI的CMM提问单，文档审阅以及进行交谈，对整个组织中的应用有一个全面的了解。然后进行数据分析。评估员要对记录进行整理，并检验所观察到的一切信息，然后把这些数据与CMM模型进行比较，最后给出一个评估报告。在每个评估报告中，必须针对CMM 的每个关键过程域，指出这个软件过程在什么地方已经有效地执行了，什么地方还没有有效地执行。只有所有评估人员一致通过的情况下，这个评估报告才有效。在评估报告的基础上，评估小组成员起草一个评估结果。评估和评级的结果应与有关的关键过程域和目标相对应。在评估结果揭晓后，将送交所有有关的人员，然后准备开始评级。要特别注意的是，在评估过程中，如果某一过程并不是CMM的要求，但这一过程与组织的能力成熟度有一定的关系，那么，它也应包含在评估结果中。

8、根据评估结果改进软件过程

一般来说，应该在评估之后很快地做出软件过程改进的计划，因为这时大家对评估结果和存在的问题仍有一个深刻的认识。计划在软件过程改进中是一个非常必要的阶段，只有有效的计划，才能确保软件过程得到有效的改进。

CBA评估方法对衡量软件企业的能力成熟度是一个非常有效的手段，评估结果本身就是一个非常坚实的基础，是制定软件过程改进计划的依据。CBA评估客观地指出了企业软件过程存在的问题，帮助企业发现软件过程的不足之处，充分指出了软件过程改进的前景。

参考文献：

⑴  《CMM实施指南》   机械工业出版社出版    James R.Persse 著

王世锦  蔡愉祖 译  宋松 审校   2003年1月第1版第1次印刷

⑵  《软件能力成熟度模型》   清华大学出版社

何新贵  王纬  王方德  崔宗学  余林生  范如鹰  周伯生  蔡愉祖 编著

2000年11月第1版第1次印刷

⑶  《百合快讯》第十一期  （http://lilydev.nju.edu.cn）

⑷  http://www.e-works.net.cn