|
摘要：本文论述了在工程组织中进行基于CMMI的集成化过程改进的总体策略。文章首先简要介绍了CMMI产品集，然后分别论述了利用CMMI进行集成化过程改进时如何选择合适的规范、模型表示法的选择以及在改进过程中评估的作用及开展。这几方面的问题构成了基于CMMI进行集成化过程改进的主要方面。
关键词：CMMI 集成化过程改进 评估
Abstract: This article expounds the tactic of
CMMI-based integrated process improvement in an engineering organization.
Firstly, the article introduces the CMMI products. Then, the article expounds
how to select the appropriate criterion, how to select the representation of
the model, and the function and operation of the appraisal in the
improvement. All of the three subjects make up of the major aspects of
CMMI-based integrated process improvement.
Key Words: CMMI, integrated process improvement, appraisal
一、引言
在工程领域，组织的质量和生产率依赖于三个主要的因素：过程、人员和技术。在一些大型系统的开发领域，随着技术的不断进步和人们素质的提高，过程因素逐渐成为制约产品质量和生产效率的瓶颈。因此，在开发组织中进行过程改进，进而增强其过程能力成为了开发组织必须要做的一项工作。
由美国卡迈基-梅隆大学的软件工程研究所（SEI）所推出的能力成熟度模型（CMM）的成功，导致了各种模型的衍生，并且每一种模型都探讨了某一特定领域中的过程改进问题。但是，随着系统复杂性的不断增长，工程实践的执行越来越多地依赖于交叉学科群组、并行工程以及其他一些高度自动化的过程。面向不同学科领域的过程改进模型已经不能很好地支持并行工程这种混合式的开发环境。在这种情况下，产生了基于CMMI的集成化过程改进。
二、CMMI简介
CMMI的全称是Capability Maturity Model
Integration，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。现在业界使用的CMMI最新模型是2002年发布的1.1版本系列，如CMMI-SE/SW/IPPD/SS，CMMI-SE/SW/IPPD，CMMI-SE/SW，CMMI-SW等。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或者多个单一学科的模型实现一个组织的集成化过程改进。在CMMI的初步研制中集成了三个特殊的过程改进模型：软件（SW-CMM）、系统工程（EIA/IS 731）以及集成化产品和过程开发（IPD CMM）；从长期考虑，CMMI产品开发群组建立了一个自动的、可扩充的框架，以便于以后将其他一些学科的过程改进模型也逐步添加到CMMI产品集中。
CMMI模型中，最基本的概念是“过程域”。与以前的一些过程改进模型一样，CMMI模型也只是选择对过程改进最重要的一些题目，并将其编组到“域”中。在CMMI以前所推出的每一种单一学科过程改进模型中，都包含了一定数量的过程域（或者其他类似名称，如焦点域）。随着各种学科之间的交叉，过程改进人员发现这些不同模型的过程域之间存在很多重复，在涉及多学科的过程改进中带来一些额外工作量，因此产生了将各种过程改进模型进行集成以减少过程域数量的想法。这种想法的最早实现就是CMMI项目首先在软件和系统工程之间实现了较高的集成性，产生了一个公共的过程域集合。随着研究的深入，过程域在不同学科之间的这种公共性越来越明显，因而在CMMI也就渐渐形成了这样一些非常具有通用性的工程过程域。事实上，过程管理和项目管理可以应用于任何学科，因此，CMMI中的这些工程过程域在对不同学科应用时具有不同的实现。总的来说，集成达到了两个目的：一是提炼出了多学科之间的一些公共过程域，另一方面就是减少了过程域的总数量。下面的表1列出了CMMI及其源模型的过程域数目。
表1：CMMI模型及其源模型中的过程域数量
模型 过程域数量
SW-CMM版本2（c） 19
EIA/IS731 19
IPD-CMM版本0.98 23
CMMI-SE/SW/IPPD版本1.1 25
每一种CMMI模型是一个多达数百页的文档，文档中包含了不同类型的资料，也就是模型构件。CMMI的模型构件主要有三类：需要的（required），期望的（expected），以及提供信息的构件。
需要的构件只有一种，那就是“目标”。目标表示某个过程域想要达到的最终状态，其实现则表示项目和过程控制已经达到了某种规定程度。针对单一过程域的目标，称之为特定目标；可适用于所有过程域的目标则称为共性目标。
期望的构件也只有一种，就是“实践”。实践代表了达到目标所“期望的”手段。CMMI模型中每个实践都恰好映射到一个目标。当然，只要能够实现模型中规定的目标，组织可以采用其他一些经过认证的手段作为“替代的”实践，而不一定非要采用模型中规定的实践。因此，实践只是模型中期望的构件，而不是需要的构件。同样，针对单一过程域的实践，称之为特定实践；可是用于所有过程域的实践则称为共性实践。
提供信息的构件有10种，分别是目的、介绍性说明、引用、名字、实践与目标关系表、注释、典型工作产品、子实践、学科扩充以及共性实践的详尽描述。这些构件为需要构件和期望构件提供了有益的补充。
三、规范的选择
如同上面所说，CMMI是一套产品集合。针对不同的学科有不同的规范和标准。并且，每增加一种CMMI学科规范，组织在改进和评估中就要考虑更多的过程需求。比如，原来的SW-CMM模型中描述了300多个实践或活动，而现在的CMMI-SW/SE版本1.1中却描述了400多个实践或活动，用这两种模型进行过程改进或评估所需要的工作量显然是不同的。因此，一个组织要想利用CMMI进行过程改进，首先必须根据自身的主要业务类型，以及改进的目标等因素，在CMMI产品集合中选择适合于自身组织的规范。
组织在选择适合自身需要的CMMI产品规范时，主要应该考虑一下几方面因素的影响：
组织的核心业务类型
这一点对于规范的选择尤其重要。虽然在一些大型项目中总会涉及到多学科、多领域的问题，但是对于组织中的核心业务来说，总是有一门或几门学科是特别重要的。为了减少过程改进中的工作量，避免在改进中引入一些不必要的过程域，组织应该选择对业务成功至关重要的学科规范。
对于开发产品或服务的组织来说，其业务类型大致包括如下三种：
1、 组织独立承担对某项新产品的全程开发和维护，开发过程不受外部因素影响。
以软件开发为例。如果软件开发组织需要开发的是一个面向某一领域的软件系统，并且是独立开发，则首先考虑的规范就应该是CMMI-SW。该规范中对于软件开发过程中需求的建立、项目计划的制定和实施，以及对软件的测试等过程都有详尽的描述。不过，考虑到软件工程与系统工程两个学科之间的大量重复性，以及两者在全程质量管理上的统一性，一般推荐使用CMMI-SW/SE规范，因为CMMI项目在软件与系统工程之间已经进行了比较完美的集成，对于进行独立开发的软件组织来说，采用CMMI-SW/SE规范进行集成化过程改进，是在集成性和工作量二者之间进行折衷的最佳平衡点。
2、 组织在开发产品或服务中需要集成他人创建的产品，或对产品的开发过程受到某些工程的影响。
实际上，随着系统复杂性的增长，组织所承接的大部分项目都是属于这种业务类型，这就涉及到开发过程中多学科的交叉以及并行工程等问题。CMMI产品集中的CMMI-SE/SW/IPPD对这种类型的项目开发过程进行了详细描述。一般来说，如果组织在项目开发中需要使用交叉学科群组，需要解决对项目群组的使用、计划和组织，需要解决学科或组之间的沟通以及与集成化产品和过程开发相关的一些问题，则可以考虑选择CMMI-SE/SW/IPPD版本1.1规范。
3、 组织在开发过程中需要获取或转包某些关键构件。
这种业务类型主要涉及到对产品的获取和转包，也就是与产品供应商相关的一些问题。CMMI-SE/SW/IPPD/SS版本1.1中对于供应商的选择和监督、集成化供应商管理以及供应商定量管理等方面给出了详尽描述，可以比较成功地解决这些问题。
组织开展项目的业务环境
&nbs |
