集成测试也叫组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统。

    集成测试与系统测试的区别：1.系统测试所测试的对象是整个系统以及与系统交互的硬件和软件平台。系统测试更过程度上是站在用户的角度上对系统作功能性的验证，同时还对系统进行一些非功能性的验证，包括性能测试、压力测试、容量测试、安全测试、恢复性测试等。系统测试的依据来自于用户需求规格说明书和行业的已成文的或事实上的标准。2.集成测试所测试的对象是噢苦熬之间的接口，其目的是要找出在模块接口上面，包括整体体系结构上的问题。其测试的依据来自于系统的高层设计（架构设计）。

   集成测试的关注点：1.在把各个模块连接起来时，穿越模块接口的数据是否会丢失。2.各个子功能组合起来，能否达到预期的要求的父功能。3.一个模块的功能是否会对另一个模块的功能产生不利的影响。4.全局数据结构是否有问题，会不会被异常修改。5.单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

   集成测试可以划分成3个级别：1.模块内即成测试。2.子系统内集成测试。3.子系统间集成测试。

1.如果输入条件规定了值的范围，则应该取正好达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试数据。

2.如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。

3.根据规格说明的每个输出条件，适用前面的第一条原则。

4.根据规格说明的每个输出条件，应用前面的第二条原则。

5.如果程序的规格说明给出的输入域是有序集合，则应选取集合的第一个原色和最后一个元素作为测试用例。

6.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测数用例。

7.分析规格说明，找出其他可能的边界条件。

1.在输入条件规定了取值范围或值个数的情况下，可以确立一个有效等价类和2个无效等价类。

2.在输入条件规定了输入值集合或者规定了“必须如何”的情况下，可确立一个有效等价类和一个无效等价类。

3.在输入条件是一个布尔量的情况下，可确定一个有效等价类个一个无效等价类。

4.在规定了输入数据的一组值（假设N个），并且程序要对每一个值分别处理的情况下，可确立N个有效等价类个一个无效等价类。

5.在规定了输入数据必须要遵守规则的情况下，可确立一个有效等价类（符合规则）和若干无效等价类（从不同角度违反规则）

6.在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。

误区1 调试和测试是一样的
     调试和测试是2个不同的过程，有着根本的区别。调试是一个随机的，不可重负的过程，它用于隔离和确认问题发生的原因，然后修改软件来纠正问题。而测试是一个有计划的，可重复的过程，它的目的是为了发现与预期县定义的规格和标准不符合的问题。

误区2 测试组应当为质量负责
     在一个组织中，测试组通常被安置为产品的最后防卫者角色，它是开发小组和用户之间的一道屏障。这使得测试组具有这样一个特点，即它拥有阻止产品被交付的权利。这个权利从其本身来说是令人沮丧的。测试组不能改进质量。更糟糕的是，权利的行使往往没有想象中那么容易。了解这一点，结合告诉开发质量是别人的事情这样一个不正确的动机，导致测试人员和测试组愤世嫉俗，并且把自己看成是一个受害者。我们已经从Deming和别人那里学到：只有当每个人在产品开发的每个阶段始终为他们的工作产品质量负责时，产品才能变得更好，更便宜。

误区3 过分依赖Bate测试
     Bate测试似乎更能代表用户使用的测试用例--因为他们是用户使用的。同时，用户报告的缺陷通常是用户最在乎的缺陷。但是，存在以下几个问题：
1.用户可能不具有代表性。
2.即时对于那些实际使用产品的用户来说，绝大部分不会很严肃地去使用产品。
3.Bate用户不会及时地报告可使用性方面的问题，他们会私下决定不买这个产品。
4.Bate用户经常不报告缺陷，尤其是在不确定或者认为很明显，别人也会发现时。
5.Bate报告的缺陷经常是很简单，甚至是不可用的，你需要花费很长时间处理一个用户缺陷。

误区4 把测试作为新员工的一个过渡工作
     测试是一个系统型的工作，需要很深的专业背景和知识，否则是无法做好测试工作的。因此把测试当作新手的一个过渡工作队测试本事是一种伤害，最终导致测试越来越薄弱，效果越来越差。

误区五 把不合格的开发人员安排来做测试
     有很多好的测试人员，但他们不失好的程序员。但是一个由某些习惯的差的程序员是不可能成为好的测试人员的。例如，那些经常会制造很多Bug的程序员是因为他们对细节不关注，这种人在测试中同样会漏过很多缺陷。

误区六 关注与测试的执行而忽视测试的设计
     如果不关注测试设计，可能会遗漏很多特殊的用例，而这些用例往往也是开发人员没有考虑到的。因此一个好的测试必然是经过良好计划和良好设计的。不经过计划和设计的测试是不可控的、无序的。

误区七 测试自动化是万能的
     测试自动化可以提高测试的效率，但不能提高测试的质量。由于自动化需要花费成本，因此只有那些经常需要执行的用例其自动化才能有效果。

误区八 测试是可以穷尽的
      穷尽的测试是不可能的。主要有下面几个原因：
1.你不可能测试程序的所有输入。
2.你不可能测试程序所有输入的组合。
3.你不可能测试通过程序的所有路径。
4.你不可能测试所有其他潜在的失败，例如有用户接口设计错误或者不完整需求分析而引起的错误。

误区九 测试是为了证明软件的正确性
      测试无法证明软件是正确的，只能证明软件无法按照既定的规格和标准执行。测试的目的是尽可能地发现错误。

误区十 测试枯燥乏味，缺乏创造力的工作
      这在于你站在什么角度去看测试。一个好的测试需要经过计划、设计到执行。为了设计好的测试用例，你需要充分发挥你的想象力。对于一个缺乏想象力的测试人员来说，你可以胜任测试执行的工作，但是你却无法设计出高质量的测试用例。无论你从事开发还是测试，都应当从工作中去寻找乐趣，不断地改进和完善自己。

   曾经有个大师说过：软件测试的目的在于发现错误；一个好的测试用例在于发现从前未发现的错误；一个成功的测试是发现了从前未发现的错误的测试。

   IEEE的定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

 

         bug遗漏，我想这个是很多公司很多人头痛的一个问题。众所周知，bug是不可能被完全消灭的，当然也就意味着在发布前不能被全部找出来。于是乎当项目发布后，或多或少都会出现bug遗漏的现象，即使发布初期没有发现，随着时间的流逝，一些隐藏的bug也会慢慢浮现出来。那么对于遗漏的bug，我们该怎么去做？

        古时云：亡羊补牢，为时未晚也。对于遗漏的bug，我们应该去透彻的分析它产生的原因，然后吸取教训，防止再次出现。这样遗漏bug的数量就会越来越少，趋于0。那么怎样的分析才是透彻的呢？我发表一下自己的观点。

        根据我的经验，总结下来有以下几点，首先从根源上说，需求的问题。需求是一切的根本，我们所做的一切都是在需求的基础上进行的，那么需求会不会有问题？当然有啦，否则要需求评审干嘛，每次需求评审，或多或少都能发现一些需求的问题，在还没有开始编码之前就把需求的bug找出来，这个是最理想的状态。显然这个不现实，但是能多发现一个不合理的地方，那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug，这个是要求比较高的，需要对业务的熟悉以及对相似产品的认识。需求关把好了，那么就算踏出了成功的第一步。

        其次，要尽早与开发人员进行测试设计评审，统一对需求的认识（开发测试人员都可能存在对需求的认识不正确）。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。

        接下来，就是用例设计了，这方面体现了一个测试人员的真实地能力。考虑的面要广，包括:使用不同的测试方案，不同的测试数据的类型（要齐全），正常流与异常流等来覆盖所有的需求。

        然后就开始执行测试，要全面地执行测试用例，并且在测试过程中不断的添加遗漏的用例。在时间允许下，尽可能的执行。

        回归阶段，除了要回归前面发现的bug，还要重视回归那些bug相关的模块，这个教训是很多的，所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug，继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码，知道改动的地方会被哪些模块调用或者会引起哪些变化，因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下，这种bug的遗漏会减少很多。

        发布前期，应该在保证所有的bug都fixed的前提下，把所有用例都回归一下，以免遗漏。

        最后终于发布了，发布好就可去FB了，^o^。不要在开心的情况下放松神经，所谓行百里，半九十，不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。

        当然最好做自动化脚本，方便以后的回归。这就是我想说的，大家有意见可以跟着，共同进步。

1 CMM及CMMI的全称分别是什么？
CMM是英文Capability Maturity Model 的缩写，中文意思是：软件能力成熟度模型。
CMMI是英文Capability Maturity Model Integration的缩写，中文意思是：软件能力成熟度模型集成。

2 CMM及CMMI的产生背景如何？
为了保证软件产品的质量，80年代中期，美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。因此，美国卡内基-梅隆大学软件工程研究所 (CMU/SEI) 于1987年研究发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。4年之后，SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM），并发布了最早的SW-CMM 1.0版。经过两年的试用，1993年SEI正式发布了SW-CMM1.1版，这是目前使用最为广泛的版本。
　　按照SEI最初的计划，应该在1998年发表SW-CMM的2.0版。由于软件过程评估（SPA）国际标准项目的进展，美国国防部下令暂时停止推进到SW-CMM 的2.0版，以便吸收SPA的长处，于是便产生了CMMI。
　　CMMI-SE/SW 1.0版作为系统工程和软件工程改进的一个集成模型，已于2000年8月11日公布。CMMI-SE/SW 1.0版是为希望改善工程和项目管理过程的产品开发组织而设计的。这一模型由能力成熟度模型集成项目组完成，该项目组是由美国国防部秘书处下属的采办、技术和后勤办公室（OUSD/AT&L）以及国家防御工业协会联合负责的，并由政府、行业和软件工程学会共同参与。该项目的目标是开发一个集成的产品套装，以支持行业和政府的过程和产品改进，该产品套装包括模型、评价方法和培训材料。
　　2000~2001年SEI陆续发表了《系统工程和软件工程综合能力成熟度模型》（CMMI-SE/SW）1.0版和CMMI-SE/SW 1.1版以及《系统工程、软件工程和集成产品与过程开发的综合能力成熟度模型》（CMMI-SE/SW/IPPD）1.1版。在发表CMMI-SE/SW1.0时，SEI宣布大约用两年的时间完成从CMM到CMMI的过渡。

3 CMM及CMMI的主要区别是什么？
SEI认为合并后的模型(CMMI-SE/SW)与以前系统工程(CMM-SE)和软件工程(CMM-SW)分开的模型的主要区别在于：在某些过程域中的推广将有特定的规范关注点。因此，SEI认为发布合并的模型是更好的选择，可以采用一个模型从而使对规范的关注集中在推广上。CMMI在2级新增加了度量和分析过程域；在3级新增加了风险管理、决策分析和决议过程域；CMMI还扩充了软件产品工程的部分；配置管理作为一个公共的实践适用于所有的过程域。
　　借助CMMI-SE/SW，现在使用不同模型对系统工程和软件工程单独进行改进的组织将能够用这样一个集成的模型对过程进行不断改进、培训和评价。由于该模型能够将系统工程和软件工程集成在一起，这一CMMI模型的采用将支持企业级改进。集成后的模型兼具了其源模型（软件能力成熟度模型SW-CMMSM 2.0版草案C和EIA/IS-731系统工程能力模型SECM）的最优特性。同时，该模型还让使用它的组织可以在以前基于SW-CMM或SE-CMM的投资基础上加以改进，并从集成模型的标准化和通用性中受益。使用SE-CMM v1.1的组织应该有能力平稳地过渡到CMMI。

4 基于CMMI的集成化过程改进策略
一、引言
　　在工程领域，组织的质量和生产率依赖于三个主要的因素：过程、人员和技术。在一些大型系统的开发领域，随着技术的不断进步和人们素质的提高，过程因素逐渐成为制约产品质量和生产效率的瓶颈。因此，在开发组织中进行过程改进，进而增强其过程能力成为了开发组织必须要做的一项工作。
　　由美国卡迈基-梅隆大学的软件工程研究所（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模型及其源模型中的过程域数量
==========================
        模型                        过程域数量
==========================
 S W-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中对于供应商的选择和监督、集成化供应商管理以及供应商定量管理等方面给出了详尽描述，可以比较成功地解决这些问题。
　　组织开展项目的业务环境
　　组织开展项目的业务环境也是影响规范选择的一个重要因素。在为过程改进选择规范时，主要应该考虑以下两种业务环境。
　　1、 项目开发周期的时间长短及项目的稳定性。
　　如果组织所承接的是一个长期项目，具有稳定的工作环境和压力，那么可以考虑选择集成了多学科的过程改进规范。因为，当组织面对一个长期、稳定的项目环境时，一般能够支持在一系列业务活动之上的集成化过程改进工作。并且，由于项目的长期性为过程改进提供了充裕的时间，因而组织可以严格贯彻规范中所描述的过程域中的各项实践和活动，同时还可以从数据和经验积累中感觉到过程改进所带来的益处。
　　如果组织所面对的是一个快速发展的环境，所承接的项目是短期的、按进度驱动的工程，那么可以考虑只集中于一个特定的学科进行过程改进，甚至可以只选择某一学科规范中的少数过程域进行改进，这样可以在不影响项目进度的前提下，尽快得到过程改进投资的效益回报。当然，从组织的长远发展来说，这种做法并不可取。但是当一个组织在面对项目进度的压力时，也只能采取这种折衷的做法。
　　2、 项目面对的客户基础。
　　在选择过程改进规范时，组织所面对的客户也是一个不容忽视的因素。如果组织承接的是对复杂系统有一些关键需求的大型项目，例如国防、航天等项目，则客户往往就会要求组织采用有把握的学科规范来匹配系统开发过程。
　　集成化过程改进的范围和目的
　　在选择合适的规范之前，首先应该了解所需改善的过程种类和过程改进的目的。如果组织的目的完全是为了进行内部过程改进，那么在选择规范方面可以有很大的余地。针对组织中涉及的项目种类和业务类型，只要有助于组织开发过程的定义、改进的学科规范都可以选择。但是，如果组织进行过程改进是为了认证或定级，以扩大组织的商业影响力，那么就应该有针对性地选择某一特定学科的规范，在过程改进过程中也就要注意对规范实施的严格性和全面性。
四、选择合适的表示法
　　每一种CMMI模型都有两种表示法：阶段式和连续式。这是因为在CMMI的三个源模型中，CMM是“阶段式”模型，系统工程能力模型是“连续式”模型，而集成产品开发（IPD）CMM是一个混合模型，组合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势，都有很多支持者，因此，CMMI产品开发群组在集成这三种模型时，为了避免由于淘汰其中任何一种表示法而失去对CMMI支持的风险，并没有选择单一的结构表示法，而是为每一个CMMI都推出了两种不同表示法的版本。
　　不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考察基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考察整个组织的过程成熟度阶段，其关键术语是“成熟度”。
　　尽管两种表示法的模型在结构上有所不同，但CMMI产品开发群组仍然尽最大努力确保了两者在逻辑上的一致性，二者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表法中都一样，特定实践和共性实践在两种表示法中也不存在根本区别。因此，模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进时，可以从实用角度出发选择某一种偏爱的表示法，而不必从哲学角度考虑两种表法之间的差异。
　　从实用角度讲，两种表示法各有优点。
　　阶段式表示法
　　软件CMM是一种阶段式模型，该模型经过多年的成功使用已经被证明是有效的，这为选择阶段式表示法模型提供了最强有力的证据。考虑从不成熟组织向成熟组织的发展过程，阶段式表示法具有如下两方面优势：
　　1、 阶段式模型为支持组织的过程改进提供了一个过程平台。
　　对于着眼于改善过程成熟度的组织来说，阶段式模型提供了一种明确的、行之有效的跨越式发展途径。阶段式模型中所描述的组织的5个成熟度等级中，每实现一次等级间的跨越，组织就致力于解决某一方面的问题。例如，组织从成熟度等级1到成熟度等级2，主要致力于有助于改善项目管理的过程域；从成熟度等级2到成熟度等级3，提供了广泛的组织过程定义；从成熟度等级3到成熟度等级4，致力于对过程定量管理的过程域；从等级4到等级5，致力于过程的改进和优化。通过这种方式，阶段式模型确定了组织进行过程改进的最佳次序，如图1。

图1：模型的阶段式表示法
　　2、阶段式模型可以为组织定义一个过程成熟度等级，便于进行跨组织的比较。
　　在阶段式模型中，每一个过程域都被指定归属到一个成熟度等级中，因此，基于阶段式模型为组织所定义的成熟度等级中，过程域的预期范围和应用将变得非常清晰。这样，在对不同的组织进行比较时，只要对比组织所达到的不同的成熟度等级，即可知道不同组织在执行过程域方面所存在的差别。
　　连续式表示法
　　相比之下，连续式模型不如阶段式模型常用，但也不乏支持者，特别是在系统工程师中。采用连续式模型主要有如下两方面的优势：
　　首先，连续式模型为用户进行过程改进提供了比较大的自由度。如同上面所说，阶段式模型确定了组织进行过程改进的最佳次序，但同时也限定了用户在进行过程改进时必须遵循单一的改善路径。而连续式模型则允许用户根据组织的业务目的来选择过程改进活动的次序。在连续式模型中，用户可以选择定义组织的成熟度等级，同时还可以选择定义更适合于自身业务环境的过程域的次序。组织可以在一个自己选择的次序中使过程域达到给定的能力等级，而不必遵循单一的阶段式模型的原则。
　　其次，基于连续式模型对组织的过程进行的评估，其评估结果具有更好的可见性。在连续式模型中，可以为每个过程域定义多个能力等级，从而可以增强对过程改进中强项和弱点的认识。由于连续式模型是对每个个别的过程域进行单独的评定，并给出个别过程域的能力等级特征图，这显然要比只一个单一的成熟度等级图能提供对过程的更仔细的观察。
五、CMMI评估的作用及开展
　　在过程改进中，评估是非常重要的一个环节。对于组织内部来说，开展对过程的评估是为了找出组织目前所处的位置，诊断组织过程中存在的缺陷。这一点对于过程改进的成功开展是必不可少的。因此，在一个组织中进行集成化过程改进之前，首先要对评估的作用及开展有一个清晰的认识。
　　1、正确认识评估的作用
　　目前，我国的软件行业中对开展CMMI评估日益重视，很多公司都已经开始实施CMMI评估，并取得了一定的成果。但是，在开展评估中也暴露出了一些问题。其中最主要的问题是对于评估产生的误解。很多组织仅仅是为了评估而评估，只盯住评估的商业目标，急于求成，在评估过程中弄虚作假；评估结束后，只注重认证结果，对评估结果没有好好利用，不能够真正贯彻评估中所给出的建议，从而也不能真正起到过程改进的目的。
　　在组织的过程改进中，评估的主要作用就是评定组织当前的所处的位置，即评定过程域的能力等级或组织的成熟度等级，并且找出组织的各个过程域中的强项和弱点，为下一步的过程改进提供建议和支持。同时，考虑到组织的商业目标，在组织中开展评估和认证可以扩大组织的市场影响力，从而带来相应的经济效益。在过程改进中，一定要摆正评估的位置。评估是手段，而过程改进才是组织所要达到的最终目的。
　　2、评估的开展
　　根据CMM标准中所提出的IDEAL模型，过程改进的开展可以分为五个阶段：⑴初始化：为成功进行过程改进打下基础；⑵诊断：相对预期目标找出组织当前所处的位置；⑶建立计划：计划如何达到目标；⑷行动：按照计划展开行动；⑸学习和扩充：学习以往的过程改进经验，扩充在将来采用新技术的能力。在组织进行过程改进的过程中，这五个阶段需要多次重复进行，逐步改善组织的过程能力。因此，作为诊断阶段中的一项重要活动，评估也不是一次性的行为，同样也需要循环往复进行。
　　CMMI产品集中的CMMI Appraisal Requirement 版本1.1给出了基于CMMI的评估中40多条需求，提供了一个综合需求集和评估方法的设计限制。根据这些需求集和设计限制可以开发出相应的基于CMMI的评估方法。
　　CMMI产品集中还给出了过程改进的标准方法CMMI评估方法SCAMPI，这一方法是由CMMI产品开发群组开发的，满足全部的CMMI Appraisal Requirement 版本1.1需求。组织在进行过程改进的时候可以参考该方法进行具体实施。
　　但是，对于一个具体的组织来说，仅仅根据CMMI产品中对评估的相应描述来照本宣科是远远不够的。特别是对于一些在过程管理方面还很不成熟的组织，在开展CMMI评估的时候更要发挥自身的创造性，灵活运用CMMI产品集中所提供的评估方法。根据CMMI Appraisal Requirement 版本1.1中的描述，评估可分为三类：
　　A类评估：全面综合的评估方法，要求在评估中全面覆盖评估中所使用的模型，并且在评估结果中提供对组织的成熟度等级的评定结果。
　　B类评估：较少综合，花费也较少。在开始时作部分自我评估，并集中于需要关注的过程域。不评定组织的成熟度等级。
　　C类评估：也称为快估。主要是检查特定的风险域，找出过程中的问题所在。该类评估花费很少，需要的培训工作也不多。
　　对于一个准备全面实施SCAMPI的组织来说，可以将过程改进分成几个层次进行，在不同层次间逐渐引入较高水平的评估：先通过几次C类评估找出过程缺陷，改进之后再导向B类评估；同样，B类评估也可以执行多次，慢慢导向进行全面的SCAMPI基准评估。如图2所示。
 
图2：评估的时间层次性
3、对评估模型的剪裁
　　模型是评估中的一个重要因素。在进行具体的评估之前，需要对选定的模型进行剪裁。这样做一方面可以减少评估的工作量，更主要的是建立起适合组织具体情况的具体模型，将标准模型中的角色、活动等部件映射到组织结构中。
　　对CMMI模型的剪裁可以从两个不同的角度进行：一是将剪裁模型用于过程改进；另一方面，也可以将剪裁模型用于建立评估基线。
　　对于内部过程改进方面的模型剪裁，主要是限制或扩展组织或项目的过程改进范围，是别出支持组织的商业目标和需求的过程域和实践，去掉对组织的业务目标“不适用”的过程域、目标以及实践。当然，由于模型中各组件之间的相互联系，如果将多个过程域、过程域中的多个目标或实践声明为“不适用”，将不可避免地带来评估中的一系列风险，从而削弱了评估的作用。因此，当怀疑某个过程域或目标以及实践不适用时，不应该匆忙做出决定。
　　将剪裁模型用于建立评估基线，主要是为了能够通过评估报告在同行业中或者在几个潜在的供应商中比较评估结果。因此，在这种情况下进行模型的剪裁，必须保证在多次评估中参照剪裁模型所得出的定级结果的一致性。从这种角度出发的模型剪裁受到更多的限制。CMMI-SE/SW/IPPD版本1.1中对其具体剪裁方法给出了详尽的描述，组织在通过剪裁定制自己的CMMI模型时可以作为参考。
　　组织在进行过程剪裁时，应该综合考虑自身的业务目标、业务模型以及过程改进的资源约束等因素，全面衡量剪裁在减少评估工作量与其所带来的风险之间的利害关系，紧密结合组织本身的核心业务过程，参照CMMI产品集中给出的规范和标准，建立起自身评估中可用的CMMI模型。
六、结束语
　　自从CMMI项目启动以来，基于CMMI的集成化过程改进策略已经在很多知名的大型组织中取得了比较成功的实施。这些组织在进行集成化过程改进中，既取得了巨大的效益，也积累了丰富的经验。本文根据这些组织的实施经验，总结了基于CMMI的集成化过程改进中需要注意的几个关键问题。具体实施中的许多关键技术，如组织标准过程的建立，对模型的剪裁技术，评估的开展中的一些重要技术等，都还有待于进一步的研究。

5 CMMI阶段式模型中的详细分级和各级中的KPA
我们在前面介绍了CMMI提供了阶段式和连续式两种表示方法，但是这两种表示法在逻辑上是等价的。我们熟悉的SW-CMM软件能力成熟模型就是阶段式的模型，SE-CMM系统工程模型是连续式模型，而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。下面，我们就阶段式模型，介绍CMMI详细分级和各级中的KPA。
1 CMMI是如何分级的？
　　CMMI阶段式模型当中有5个成熟度等级，分别为：
　　1级为初始级
　　在成熟度等级1时，过程往往是临时的和混乱的。组织通常不提供一个稳定的环境。在这些组织里成功依赖于组织中个人的胜任能力和个人英雄主义，并不依赖于已被证实的过程的使用。不管这种临时和混乱的环境，处于成熟度等级1的组织通常在那种情况下也能生产出他们的产品和提供服务，但他们会经常超出项目的预算和进度。成熟度等级1的组织的特征事先没有恰当的承诺，关键时刻放任的过程，并且不能重复过去的成功。
　　2级为可管理级
　　在成熟度等级2，一个组织已达到二级过程域特定和通用的实践的所有目标。换句话说，组织的项目已确保需求是可管理的，过程是有计划的、可实现的、可度量的和得到控制的。
　　成熟度2级对应的过程规程帮助确保存在的实践在重要的时刻被保留下来。当这些实践放回原位时，项目可以依据文档化的计划执行和管理。
　　2级时，需求、过程、工作产品和服务被管理。工作产品和服务交付的状态在已定义的点上具有管理的透明性（例如，在主要里程碑阶段和主要任务完成时）。
　　相关的相关方之间建立了承诺并且在需要时给予修订。工作产品由相关的stakeholders评审并且被控制。工作产品和服务满足他们具体的需求、标准和目标。
　　3级为已定义级
在3级时，组织已达到2级和3级所有过程域的特定和通用的目标。在3级，过程被很好地刻画和理解，并且在标准、规程、工具和方法等方面都进行了描述。
　　作为3级的基础组织的标准规程得到建立并随时改进。这些标准的过程用来建立整个组织的一致性。项目依据裁减指南通过裁减组织的一系列标准过程建立他们定义的过程。
　　组织的管理者建立基于组织标准过程的过程目标并确保这些目标被适当地表述。
　　2级和3级的关键区别在于标准的范围、过程描述和规程。在2级时，标准、过程描述和规程在每一个具体的过程实例中是完全不同的（例如，对于一个特殊的项目）。在3级时，一个项目的标准、过程描述和规程是从组织的标准过程中裁减以适应一个特殊项目或组织单元的。组织的标准过程包括2级和3级时提到的过程。因此，除了裁减指南上允许的差异外，整个组织执行的过程要保持一致性。
　　另一个关键的区别是在3级时比2级更详细和更严格地对过程进行了具有代表性的描述。在3级时通过对过程活动间相互关系作用的理解，和对过程、工作产品和服务的详细度量使过程得到了更proactively的管理。
　　4级为定量管理级
　　管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。
　　5级为持续优化级
　　优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。
2 KPA是什么？
　　KPA是英文(Key Process Area)的缩写，中文是关键过程域。
3 CMMI模型中各级有哪些KPA？
　　每个成熟度等级由若干关键过程区域组成。每个关键过程区域标识出一串相关的活动，当它们作为群体完成时，就达到一组目标，此组目标对建立该过程成熟度等级是至关重要的。关键过程区域是分别定义在各个成熟度等级并与之相连在一起的。。关键过程区域是一些结构单元，它们指明组织为改进其软件过程应关注的区域。关键过程区域鉴别出为达到某一成熟度等级必须解决的问题。
　　图中列出CMMI 中每个成熟度等级的关键过程区域。

6 CMMI阶段式模型成熟度等级的过程能力和性能预测
现在我们将成熟度5个等级的过程能力和性能预测进行比较，从而看出执行CMMI规范的好处。
　　一个组织的软件过程成熟度能帮助预测一个项目达到其目标的能力。等级1 组织中的不同项目在达到成本、进度、功能和质量等指标的能力上差别很大。正如图中的例子所示，随着组织软件过程成熟，在满足预定目标方面能观察到三个改进之处。
　　　　　　　［软件过程图］
　　首先，随着成熟度增长，所有项目的预定目标结果与实际结果间的差异减小。例如，如果有十个相同规模的项目预定在5 月1 日交付，那么随着组织的成熟，它们交付的平均日期会越来越靠近5 月1 日。等级1 组织经常远迟后于其进度表规定的交付日期，而等级5的组织应该能相当精确地满足预定日期要求。这是因为等级5 上组织采用仔细构造的、在已知参数范围内运行的软件过程，而且确定预定日期是基于他们所具有的有关其过程的大量数据，以及运用数据时的性能。（图中，用预定日期线右边曲线下的面积大小表示这一点。）
　　其次，随着成熟度增长，实际结果相对预定目标结果的偏差范围减小。例如，等级1组织中，对具有类似规模项目的交付日期是不可预测的，其变化很大。而等级5 组织中的类似项目的交付日期在小得多的范围内变化。在最高成熟度等级上变化范围很小的原因是所有的项目实际上均在接近组织的有关成本、进度、功能和质量等过程能力的受控参数的范围内运行。（图中，以集中于预定目标线附近的面积大小说明这点。）
　　第三，随着组织成熟度的增加，预定目标结果得到改善。这就是说，随着软件组织的成熟，成本降低，开发时间缩短、生产率和质量提高。在等级1 上的组织，其开发时间可能十分长，因为必须完成大量的用以纠正错误的返工。相反，等级5 组织采用不断改进过程和缺陷预防技术增加过程有效性和消除费钱的返工，使得开发时间得以缩短。（图中，这点反映在预定目标线在指向原点方向上的水平移动。）
　　图中所表示的在预测项目结果方面的改进基于以下假定，即随着噪声（通常以返工形式出现）从软件过程中消除，软件项目结果更加可以预测。但是，无先例的系统会使情况复杂化，因为新的技术和应用问题增加可变性，从而降低过程能力。即使在无先例系统的情况下，与比较不成熟的组织相比，较成熟的组织管理和工程实践的特征能在开发周期的较早阶段帮助识别和阐述问题。由于较早识别出缺陷，能消除后面阶段的返工，从而提高项目的稳定性和性能。风险管理是成熟过程中项目管理的必不可少部分。在某些情况下，一个成熟过程意味着在软件生命周期的早期识别出“失败”项目，使得在徒劳无功的事情上的投资最小。