软件过程改进.doc

《软件过程改进.doc》由会员分享，可在线阅读，更多相关《软件过程改进.doc（21页珍藏版）》请在三一办公上搜索。

1、第1章 软件过程改进软件过程是人们建立、维护和演化软件产品整个过程中所有技术活动和管理活动的集合。目前，软件过程技术是一个非常活跃的研究领域，吸引了大批来自学术界和工业界的专家和学者。目前，每个国家几乎都有自己的软件过程改进网络和组织。软件过程技术的研究和实践主要有三个方向：（1）软件过程分析和建模。软件过程建模方法是软件过程技术的起点，其中形式化半形式化建模方法有基于规则的，基于过程程序的等等。过程分析和过程建模对于保证过程定义的质量、建立全面和灵活的过程体系具有重要的作用。对软件过程的建模主要是使用过程建模语言（Process Modeling Languages，PML）。PML最基本的

2、功能是用于描述和定义过程，建立过程模型。PML的能力和表达方式直接影响着过程模型的质量和建模效率。所以，选择合适的PMLs，成为过程分析、过程建模和选择建模工具的关键。（2）软件过程支持。软件过程支持主要是指研究和开发支持软件过程活动的计算机辅助软件工程（Computer-Aided Software Engineering，CASE）工具，过程支撑工具作为一种技术基础设施，能够很好地支持、管理并规范化软件过程。它的使用将使得软件过程的透明度好，为项目的软件过程提供指导，使得开发者和管理者都有据可依，便于更有效地管理软件过程。软件过程支持工具主要包括软件过程流程工具、过程文档工具、评审工具和人

3、员管理工具。（3）软件过程评估和改进。软件过程评估和改进是指根据某种模型对现有软件过程进行考核和评价，找出其中的不足之处，然后加以改进。改进对生产高质量软件产品和提高软件生产率的重要性已被越来越多的软件开发组织所认同。由美国卡耐基梅隆大学软件工程研究所（CMU/SEI）提出的软件能力成熟度模型除了用于软件过程评估外，还向软件组织提供了指导其进行软件过程管理和软件过程改进的框架。软件过程改进的基本原则是采用过去项目中成功的实践经验。因此，理解、记录和重用部分软件过程是软件过程改进研究的一个重要方向。1.1 CMM综述软件能力成熟度模型（Software Capacity Maturity Mod

4、el，SW-CMM）是CMU/SEI为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了SW-CMM 1.0版。希赛教育专家提示：目前，有很多能力成熟度模型，例如，安全能力成熟度模型（SE-CMM）、人力资源能力成熟度模型（P-CMM）等。在不造成混淆的情况下，本书把SW-CMM简称为CMM。也就是说，除非特别说明，否则，CMM就是指SW-CMM。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量组织软件开发和管理水平的重要参考因素，以及软件过程改进事实上的工业标准。1992年4月，CMU/SEI举行了一个CMM的研讨会，CMU

5、/SEI在广泛听取与会专家的意见之后，于1993年推出 CMM1.1版，这也是目前世界上比较流行和通用的CMM版本。按照CMU/SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0的实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求CMU/SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI。有关CMMI的知识，将在1.5节进行介绍。1.1.1 CMM的基本概念为了行文方便，在本节介绍CMM中用到的有关概念和术语。（1）过程（process）：为实现既定目标的一系列操作步骤。（2）软件过程（Software Pr

6、ocess，SP）：指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。其中相关产品是指项目计划、设计文档、编码、测试和用户手册。当一个组织逐步走向成熟，软件过程的定义也会日趋完善，其内部的过程实施将更具有一致性。（3）软件过程能力（Software Process Capability，SPC）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织在承接下一个软件项目时，所能期望得到的最可能的结果。 （4）软件过程性能（Software Process Performance，SPP）：表示遵循一个软件过程后所得到的实际结果。

7、软件过程性能与软件过程能力有区别，软件过程性能关注的是实际得到的结果，而软件过程能力关注的是期望得到的结果。由于项目要求和客观环境的差异，软件过程性能不可能充分反应软件过程整体能力，即软件过程性能受限于它的环境。（5）软件过程成熟度（Software Process Maturity，SPM）：一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。所谓成熟度包含着能力的一种增长潜力，同时也表明了组织实施软件过程的实际水平。随着组织软件过程成熟度能力的不断提高，组织内部通过对过程的规范化和对成员的技术培训，软件过程也将会被它的使用者关注和不断修改完善。从而使软件的质量、生产率和生产周

8、期得到改善。（6）关键过程（区）域（Key Process Area，KPA）：一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时所必须满足的条件。也就是说，关键过程域标识了达到某个成熟程度级别时所必须满足的条件。在CMM模型中，一共有18个关键过程域，分布在第二级至第五级中。（7）关键实践（Key Practices，KP）：关键过程域中的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。一般情况下，关键实践描述了该“做什么”，但没有规定“如何”去达到这些目标。（8）软件过程评估（Software Process Assessme

9、nt，SPA）：用来判断一个组织当前所涉及的软件过程的能力状态，判断组织所面向的下一个更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对软件过程进行有效的改进。（9）软件能力评价（Software Capability Appraisal，SCA）：用来判断有意承担某个软件项目的组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确（或是否正常）。（10）软件工程组（Software Engineering Group，SEG）：负责一个项目的软件开发和维护活动的团体。活动包括需求分析、设计、编码和测试等。（11）软件相关组（Software Related Groups，S

10、RG）：代表一种软件工程项目的团体，它支持但不直接负责软件开发或维护工作，如软件质量保证组、软件配置管理组和软件工程过程组等。在CMM的关键实践中，软件相关组通常应该根据关键过程域和组织的上下文来理解。（12）软件工程过程组（Software Engineering Process Group，SEPG）：由专家组成的组，他们推进组织采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织软件过程活动的组”。（13）系统工程组（System Engineering Group，SEG）：负责下列工作的个人或团体：分析系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、

11、软件和其他成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。（14）系统测试组（System Test Group，STG）：一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了确定软件产品是否满足对它的需求。（15）软件质量保证组（Software Quality Assurance Group，SQAG）：一些计划和实施项目的质量保证的团体，其工作目的是保证软件过程的步骤和标准是否得到遵守。（16）软件配置管理组（Software Configuration Management Group，SCMG）：一些负责策划、协调和实施软件项目的正式配置活动的团体。（17）培训

12、组（Training Group，TG）：一些负责协调和安排组织培训活动的团体。通常这个组织负责准备和讲授大多数培训课程并协调其他培训方式的使用。1.1.2 CMM的基本框架CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准，如图1-1所示。（1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些组织制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的

13、保证时，那么它仍然被视为初始级。图1-1 软件过程成熟度的级别（2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。（3）已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。要求制定组织范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标

14、准，并将这些标准集成到组织软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过组织有关人员的批准。（4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。（5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程

15、改进。如果一个组织达到了这一级，表明该组织能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向上一级别迈进。因为从第二级开始，每一个低级别的实现均是高级别实现的基础，所以CMM体系不主张跨级别的演化。SEI建议，从低一级别向高一级别演化的时间需要在1230个月之间。CMM分级标准有两个方面的用途。一方面，软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。另一方面，该标准也可以作为用户对软件组织的一种评价标

16、准，使之在选择软件开发商时不再是盲目的和无把握的。1.1.3 CMM的主要内容CMM为软件组织的过程能力提供了一个阶梯式的演化框架，它采用分层的方式来解释其组成部分。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念。每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如图1-2所示。图1-2 不断改进的过程（1）初始级的改进方向：建立项目过程管理，实施规范化管理，保障项目的承诺；进行需求管理方面的工作，建立用户与软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目计划，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划等；积极开展

17、软件质量保证活动（Software Quality Assurance，SQA）。（2）可重复级的改进方向：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程，也可以作为软件过程剪裁的基础；建立SEPG，长期承担评估与调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。（3）已定义级的改进方向：着手软件过程的定量分析

18、，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。（4）已管理级的改进方向：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，使有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。 （5）优化级的改进方向：保持持续不断的软件过程改进。1.1.4 CMM的内部结构CMM的5个成熟度等级中，除第一级外，每一级按完全相同的内部结构构成，如图1-3所示。图1-3 CMM的内部结构图成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期

19、结果的程度。在CMM中，每个成熟度等级（第一级除外）规定了不同的KPA，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足KPA所规定的要求，即满足KPA的目标。每个级别对应的KPA如表1-1所示。公共特性是把每个KPA的所有关键实践按照它们的属性进行分组。无论哪个KPA，它们的关键实施都统一按5个公共属性进行组织，分别是执行约定、执行能力、实施活动、度量和分析、验证实施。（1）执行约定（Commitment To Perform，CTP）：也称为实施保证，是组织为了建立和实施相应KPA所必须采取的行动，这些行动主要牵涉到组织范围的政策和高层管理的责任。执行约定一般与组织的方针政策和管理

20、方式有关。表1-1 关键过程域的分类过程分类等级管 理 方 面组 织 方 面工 程 方 面优化级技术改进管理过程改进管理缺陷预防可管理级定量管理过程软件质量管理已定义级集成软件管理组间协调组织过程焦点组织过程定义培训程序软件产品工程同级评审可重复级需求管理软件项目计划软件项目跟踪与监控软件子合同管理软件质量保证软件配置管理（2）执行能力（Ability To Perform，ATP）：也称为实施能力，描述为了使某软件过程得以始终如一地执行，必须在项目或组织中存在的先决条件，是组织实施KPA的前提条件。组织必须采取措施，在满足了这些条件后，才有可能执行KPA的实践活动。执行能力关注于项目计划的实

21、践、资源的配置、责任的布置与授权，以及各种有关的培训等。（3）实施活动（Activities Perform，AP）：描述执行KPA所需的必要行动、任务和步骤。在5个公共属性中，实施活动是唯一与项目执行相关的属性，其余4个属性则涉及组织CMM能力基础设施的建立。实施活动一般包括计划、执行的任务、任务执行的跟踪等。（4）度量和分析（Measurement And Analysis，MAA）：关注KPA的活动需要做的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。度量与分析一般包括一些度量的例子，通过这些例子可以知道如何确定操作活动的状态和效果。（5）实施验证

22、（Verifying Implementation，VI）：实施验证是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。验证实施涉及到管理的评审和审计以及质量保证活动，包括过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。1.1.5 SPA和SCA的比较分析软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，反过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进

23、策略。软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们改进软件过程。CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的步骤，如图1-4所示。图1-4 软件过程评估和软件能力评价的步骤具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据KPA的基本情况列出评估提纲。 尽管SPA和SCA有很多相

24、似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如：（1）SPA和SCA在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。尤其在一些细节规范方面，SPA和SCA的方法有很大差异。 （2）SPA和SCA的结果和结果所起的作用不同。因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。（3）被评估和评价单位的态度对SPA和SCA活动的影响。SPA在某种意义上被 评估单位的态度较积极，而SCA在某种意义上被评价单位的态度可能比较慎重。SPA 是在一个开放的、互相协作的环境中进行的，而SCA往往是在有较大的阻力的

25、环境中进行的。1.2 组织如何实施CMM近年来，随着国民经济持续增长，作为高新技术的软件产业虽然发展很快，但和国外同行业相比仍存在很大的差距。究其原因，投资环境、人才和技术固然是制约因素，但希赛教育专家认为，管理和政策显得更为关键。随着电子信息产业的发展，人们已经逐步认识到，软件是促进我国电子信息产业发展的关键技术。而要发展我国的软件产业，在战略上，必须将软件产业作为我国高新技术产业的龙头和国民经济发展的新增长点，在策略上，必须走软件过程管理专业化的道路。 1提高思想认识实施CMM对软件组织的发展起着至关重要的作用，这种作用并不是取决于CMM评估的结果。CMM过程本身就是对软件组织发展历程的一

26、个完整而准确的描述，组织通过实施CMM，可以更好地规范软件生产和管理流程，使组织的管理更加规范化。而且，只有在国际市场取得成功的产品和组织才具有长久的竞争力和生命力，由于CMM已获得国际组织和用户的广泛认可，因此很有必要在软件组织中实施CMM。2进行CMM培训和咨询工作任何一个组织要想实施先进的管理措施，首先应该做的就是理论基础的建设，作为一个过程式管理方法的CMM，同样也不例外。 根据CMM模型的要求，一个项目的开发一定要有章可循，而且要做到有章必循，这两点都离不开培训。培训工作需要投入很大的人力、物力和财力，只有组织的管理人员和软件开发人员对CMM真正了解和认识了，自觉地按CMM的方法去进

27、行工作，才能真正实施CMM，而不是一时应付，做表面文章。培训的内容需要精心地准备，主要有两个方面，第一，对所有员工包括经理在内的最基本的软件工程和CMM培训知识；第二，对各个工作组的有关人员提供专业领域知识等方面的培训；此外，在每次开发过程中，还要对普通人员进行软件过程方面的培训。培训的方式有很多，可以向有关专业培训咨询机构进行咨询；可以利用互联网资源进行咨询和培训；可以聘请有关CMM专家到组织实地指导CMM的实施。希赛教育专家提示：组织可以在最开始阶段聘请一位经验丰富的CMM专家，但以后一定要培养自己的专家，这样不仅能节约开支，还能使组织自己具有一个对CMM深刻理解的、有实践经验的专家，为组

28、织今后的继续升级打下一个良好的基础。3确定合理的目标CMM模型划分为5个级别，共计18个关键过程域，52个目标，316个关键实践。每一个CMM等级的评估周期（从准备到完成）约需1230个月。无论一个组织的软件过程处于什么样的水平，都可以在CMM框架的5个级别中找到自己的位置。CMM框架的不同级别是针对处于不同管理水平的组织制定的，组织实施CMM，首先必须了解自己的管理现状，对照CMM的级别，找到自己在CMM中所处的位置，然后有针对性采取与自己所处级别相适应的措施，使组织尽早纳入CMM的演化阶段，使软件过程管理早日得到改善，最终达到提高软件质量，获取经济效益的目的。因此，要实施CMM，首先应该对

29、本组织的现状有一个准确的评估。组织目前处于什么水平，组织发展的问题是什么，借助CMM要达到的目的是什么。然后再结合组织的实际情况选择CMM的切入点，确定总体目标。这个目标包括在多长时间之内，需要投入多少人力、物力和财力，要达到哪一级。 由于软件过程的建立和改进是一个渐进的、分轻重缓急的、逐步完善的过程。所以，在总体目标已经确定的前提下，还要制订近期目标和长期目标。4成立工作组组织针对CMM的实施，应成立专门的CMM实施领导小组或专门的机构。CMM的实施需要有强有力的组织保证，领导层必须真正学习理解软件过程管理和改进的重要性，亲自领导和参与，要保证过程管理的人员配备，抽调组织中有管理能力、组织能

30、力和软件开发能力的骨干人员，确实把此项工作当作组织生存和发展的大事来抓。在CMM的实施过程中，工作组的成立是CMM的一个关键步骤。有几个重要的组织是必不可少的，这些组织包括软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。在CMM的实施中组织机构的设置必须完善，但不等于说每一个机构必须是独立的。有些组织很小时，机构可以适当合并，成员可以身兼数职。但对那些关键实践要求独立性时，组织必须十分小心。例如，软件质量保证组的独立性就是必须考虑的，否则在技术上或机构上出现的偏差，会无目的地影响到软件过程、项目质量和风

31、险决策的正确性。在这里还要提到一点，那就是物理组和逻辑组。在CMM中有两种组织，一种叫物理组织，它是客观存在的，例如项目组、技术部等，有众多专职人员；另一种叫逻辑组织，就是说它的人员可以是兼职的，在用不到的时候，成员有自己的工作，而且很多逻辑组只需一两个人就可以了。5制定和完善软件过程CMM模型强调软件过程的改进，如果组织还没有一个文档形式的软件过程，则首要任务是对当前的工作流程进行分析、整理及文档化，从而制定出一个具有本组织风格的软件过程，并用该文档化的过程指导软件项目的开发。 如果已经具备了软件过程，则要对这个过程做内部评估，对照CMM的要求，找出问题，然后对这个过程进行补充修改。在具体实

32、施的过程中，可以选择有一定代表性和完善性的项目组或项目进行试点，跟踪、监督改进后的软件过程的实施情况，执行改进活动的状态。 同时，过程小组的成员还应该维护过程中的数据库，定期统计各个过程中的产品和规模、开发周期、修改次数及评估周期。这些数据库可用来分析项目的效率以及存在的问题，以便今后进一步的改进，同时还可以为项目开发过程提供咨询。 总结这些项目组或项目以前成功的经验，从中规划出一个具有实际意义的软件过程，按照CMM规范评估这个过程，找出其中的优缺点。对不满足CMM要求的地方加以完善，使其成为一个完美的实施CMM的软件过程方案；然后将这个软件过程应用到当前正在承接的或即将承接的项目上，在实际使

33、用过程中进一步发现其中的不足和错误之处，加以改进，最后将试点的结果推广到整个组织。 6内部评审CMM每一级别的评估都由CMU/SEI授权的主任评估师领导一个评审小组进行，相对来说，评审费用比较高。因此，希赛教育专家建议，组织在进行正式评估之前，先进行内部评审或评估。组织自己内部成员，严格、认真地按照CMM规范评估过程，对自己的软件过程进行评审，找出其中的不足点并进行改进。这样，就能确保正式评估时能一次性通过，节约成本。7正式评估CMM正式评估的过程包括员工培训（组织的高层领导也要参加）、问卷调查和统计、文档审查、数据分析、与组织的高层领导讨论和撰写评估报告等，评估结束时由主任评估师签字生效。

34、基于CMM的评估方法主要有两种，一种是CBA-SCE（CMM-Based Appraisal for Software Capability Estimation），它是基于CMM对组织的软件能力进行评价，是由组织外部的评估小组对该组织的软件能力进行的评价。另一种是CBA-IPI（CMM-Based Appraisal for Internal Process Improvement），它是基于CMM对内部的过程改进进行的评估，是由组织内部的小组对软件组织本身进行评估以改进质量，结果归组织所有，目的是引导组织不断改进质量。这两种评估均由CMU/SEI授权的主任评估师领导，参考CMM框架来进行，

35、都要审查正在使用和将来使用的文档，并对不同的员工进行采访。SCE与IPI的评估结果应该一致，评估结果的所有资料都将呈报给CMU/SEI。8根据评估结果改进软件过程根据CMM模型，成熟度的评估只是软件过程改进中的一个环节，如果这个环节与软件过程改进的其他环节不能很好地结合，那么，CMM评估对于软件过程改进所应具有的作用就得不到发挥。一般来说，应该在评估之后很快地作出软件过程改进的计划，因为这时大家对评估结果和存在的问题仍有一个深刻的认识。计划在软件过程改进中是一个非常必要的阶段，只有有效的计划，才能确保软件过程得到有效的改进。CBA评估方法对衡量软件组织的能力成熟度是一个非常有效的手段，评估结果

36、本身就是一个非常坚实的基础，是制定软件过程改进计划的依据。CBA评估客观地指出了组织软件过程存在的问题，帮助组织发现软件过程的不足之处，充分指出了软件过程改进的前景。1.3 CMM存在的问题从CMM评估的实践来看，CMM 1.1版主要存在以下问题。（1）CMM虽然指明了成熟的软件过程的各种关键实践，并提供了一些有效的实践例子，但CMM1.1并不包括对成功的项目来说是必不可少的一些重要问题，包括人才、个人技能和具体的技术等。（2）CMM 1.1 所描述的标准和实践很适宜于与政府签约的大型软件开发组织和大项目，但是对于中小型组织或中小项目来说，必需加以适当剪裁。但是，CMM 1.1却并没有给出操作

37、性好的剪裁指南。（3）CMM 1.1 发布时，关于软件生存周期过程的国际标准（ISO/IEC 12207-1995）尚未发布，国际标准化组织（International Standard Organization，ISO）也刚确定要制定软件过程评估的国际标准。因此，CMM 1.1所涉及的过程与ISO/IEC 12207对于相应的过程的阐述不完全一致；在关于软件过程评估工作的技术文件中，CMM 1.1与ISO的表述也有差异。（4）CMM 1.1关于等级4和等级5的阐述，在实际经验方面的依据还不足，对这类组织的特征了解较少，因此，有关的KPA及所包含的关键实践的定义不像等级2和等级3的KPA的定义

38、那样完善和明晰。（5）CMM 1.1没有指明任一软件开发组织都必须首先建立基本的软件工程过程和管理过程，否则就较难从初始级顺利地提高到可重复级。在我国的实践也表明，从初始级到可重复级的台阶太高，不利于软件开发组织从初始级演化到可重复级。1.4 ISO 9001与CMM的比较表1-2是ISO 9001条款到CMM模型KPA和关键实践映射的概述。“强相关性”列表示相关性较直接的KPA和共同特征；“判断相关性”列表示在确定合理相关性时需要一定程度上的主观理解的KPA和共同特征。表1-2 ISO 9001到CMM的映射ISO 9001条款强 相 关 性推断相关性管理职责履行的承诺软件项目规划软件项目追

39、踪和监督软件质量标准履行的能力实现矫正软件质量管理质量体系实现矫正软件项目规划软件质量标准软件产品工程组织工程定义合同评估需求管理软件项目规划软件子合同管理设计控制软件项目规划软件项目追踪和监督软件配置管理软件产品工程软件质量管理续表ISO 9001条款强 相 关 性推断相关性文档和数据控制软件配置管理软件产品工程采购软件子合同管理客户供货产品的控制软件子合同管理产品确认和追踪软件配置管理软件产品工程工程控制软件项目规划软件质量帮助软件产品工程定量工程管理技术改变管理检查和测试软件产品工程伙伴审查检查控制、度量和测试设备软件产品工程检查和测试状态软件配置管理软件产品工程不合格产品的控制软件配置

40、管理软件产品工程矫正和预防措施软件质量保证软件配置管理缺陷预防处理、储藏、包装、保存和分发软件配置管理软件产品工程质量数据控制软件配置管理软件产品工程、伙伴审查内部质量审计实现检查、软件质量保证培训履行的能力、培训计划服务统计技术度量和分析机构过程定义定量过程管理软件质量管理虽然ISO 9001中的一些问题没有被CMM模型覆盖，二者之间的详细程度也有很大的差异，但二者之间的相关性还是很明显的。CMM与ISO 9001之间最大的不同体现在两方面：第一，CMM模型明确强调持续的过程改进，而ISO 9001只要求质量体系的最小保证（希赛教育专家提示：ISO 9001 2000版也引进了“持续的过程改

41、进”）。第二，CMM模型只关注软件，而ISO 9001适用于更大的范围。ISO 9001的基本假设是：组织应该通过质量控制活动，归档每个重要过程并检查每个重要过程。CMM模型也强调文档化的过程和文档化的设计。“按文档化的程序”和遵循“书面形式的组织政策”是CMM模型KPA的特征。 通过以上分析，可以得到以下结论： （1）ISO 9001和CMM既有区别又相互联系。尽管ISO 9001标准的一些要求在CMM中不存在，而CMM的一些要求在ISO 9001标准中也不存在，但不可否认的是，两者之间的关系非常密切。当然，两者之间的差别也很明显。ISO 9001的一些要素可以在CMM中找到完全对应的部分，

42、另外一些要素则是比较分散的对应。 （2）取得ISO 9001认证并不意味着完全满足CMM某个等级的要求。表面上看，获得ISO 9001认证的组织应该具有CMM第3级至第4级的水平，但事实上，很多CMM第1级的组织也获得了ISO 9001证书，原因是ISO 9001强调以顾客的要求为出发点，不同顾客要求的质量水平也不同，而且各个审核员的水平和解释也有差异。ISO 9001标准只是质量管理体系的最低可接受准则，不能说已满足CMM的大部分要求，但有一点可以肯定：ISO 9001认证合格的组织至少能满足CMM第2级的大部分要求以及第3级的一部分要求。 （3）通过CMM第2级（或第3级）评估并不代表满足

43、ISO 9001的要求。CMM第2级的所有关键过程都涉及ISO 9001的要求，但都低于ISO 9001的要求。另外，一些CMM第1级的组织在满足了第2级和第3级的一些关键过程的要求后，也可以获得ISO 9001认证。一些CMM第2级或第3级的组织可能被认为符合ISO 9001的要求，但是，甚至一些通过了CMM第3级评估的组织也需另外满足ISO 9001的要素，才能符合ISO 9001的要求。 总的来说，CMM是专门针对软件开发组织设计的，因此在针对性上比ISO 9001要好，但需要注意的是，CMM强调的是软件开发过程的管理，对于国内软件组织涉及较多的系统集成并没有考虑，如果单纯按照CMM的要

44、求建立质量体系，则应该注意补充系统集成方面的内容。正因为这个原因，CMU/SEI在CMM模型的基础上，综合考虑了多个模型，开发了CMMI模型。 1.5 CMMI综述能力成熟度模型集成（Capability Maturity Model Integration，CMMI）是CMM模型的最新版本，2001年12月，CMU/SEI正式发布了CMMI 1.1版本。与原有的能力成熟度相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。CMMI可以看作是把各种CMM集成到

45、一个系列的模型中，CMMI的基础源模型包括SW-CMM 2.0版（草稿C），EIA-731系统工程，以及集成化产品和过程开发IPD-CMM 0.98a版。CMMI也描述了5个不同的成熟度级别。1. CMMI模型的表示每一种CMMI模型都有两种表示法，分别是阶段式和连续式。这是因为在CMMI的三个源模型中，SW-CMMM是阶段式模型，EIA-731是连续式模型，而IPD-CMM是一个混合模型，结合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势，都有很多支持者，因此，CMMI产品开发组在集成这三种模型时，为了避免由于淘汰其中任何一种表示法而失去对CMMI支持的风险，并没有选择单一的结

46、构表示法，而是为每一个CMMI都推出了两种不同表示法的版本。不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考察基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考察整个组织的过程成熟度阶段，其关键术语是“成熟度”。 尽管两种表示法的模型在结构上有所不同，但CMMI产品开发组仍然尽最大努力确保了两者在逻辑上的一致性，两者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表示法中都一样，特定实践和共性实践在两种表示法中也不存在根本性的区别。因此，模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进

47、时，可以从实用角度出发选择某一种偏爱的表示法，而不必从哲学角度考虑两种表法之间的差异。阶段式模型也把组织分为5个不同的级别：（1）初始级。以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能。 （2）已管理级。以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和分析。对于已管理级而言，主要的过程焦点在于项目级的活动和实践。（3）严格定义级。以组织内改进项目执行为特征的过程成熟度。强调严格定义级的KPA的前后一致的、项目级的纪律，以建立组织级的活动和实践。（4）定量管理级。以改

48、进组织性能为特征的过程成熟度。定量管理级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预 测的。（5）优化级。以可快速进行重新配置的组织性能，和定量的、持续的过程改进为特征的过程成熟度。2. CMMI的目标和优点CMMI的具体目标如下：（1）改进组织的过程，提高对产品开发和维护的管理能力。（2）给出能支持将来集成其他科目CMM的公共框架。（3）确保所开发的全部有关产品符合软件过程改进的国际标准ISO/IEC15504对软件过程评估的要求。 使用在CMMI框架内开发的模型具有下列优点：（1）过程改进能扩展到整个组织级。 （2）以前各模型之间的不一致和矛盾将得到解决。 （