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 组织采用不断改进过程和缺陷预防技术增加过程有效性和消除费钱的返工，使得开发时间得以缩短。（图中，这点反映在预定目标线在指向原点方向上的水平移动。）
　　图中所表示的在预测项目结果方面的改进基于以下假定，即随着噪声（通常以返工形式出现）从软件过程中消除，软件项目结果更加可以预测。但是，无先例的系统会使情况复杂化，因为新的技术和应用问题增加可变性，从而降低过程能力。即使在无先例系统的情况下，与比较不成熟的组织相比，较成熟的组织管理和工程实践的特征能在开发周期的较早阶段帮助识别和阐述问题。由于较早识别出缺陷，能消除后面阶段的返工，从而提高项目的稳定性和性能。风险管理是成熟过程中项目管理的必不可少部分。在某些情况下，一个成熟过程意味着在软件生命周期的早期识别出“失败”项目，使得在徒劳无功的事情上的投资最小。

三、录制WebTest
1、录制一般的Web站点测试

我们以经常使用到的VS2005自带的Personal Web Site Starter Kit为例，首先创建一个WebSite，

之后在这个Solution上创建一个Test Project，如果安装了VSTS Team Suite版本，在新建项目时有专门的Test Project，确定是否安装有Team Edition For Software Testers，点击VSTS中Help里的About Microsoft Visual Studio，可以查看：

新建一个Test Project：

弹出IE后，在地址栏输入URL后就可以开始录制操作，同时实时的录制到VSTS中


这样就完成了一个录制的过程。

2、录制Web Service测试
录制方法和录制Web 站点相同，创建测试项目后在IE中输入WebService的URL来记录操作。

3、手动添加Web Service测试
可以参考下面2篇文章，对于WebService测试加入了数据驱动，可以一次将测试数据全部加进去一次运行得到结果
http://msdn2.microsoft.com/zh-cn/library/ms182557(VS.80).aspx
http://blog.joycode.com/mango/archive/2007/02/28/94002.aspx
4、查看WebTest
      Web 测试是一个包含一系列 HTTP URL 的 XML 文件。可以通过使用 Web 测试编辑器记录浏览器会话来创建 Web 测试。
A、查询字符串参数和窗体发送参数已被检测出来并会自动生成到测试中。传输方法属性 GET 或 POST。
B、Web 测试记录器会自动检测是否使用了隐藏的窗体字段。
C、不记录图像。 Parse Dependent Links 属性设置默认为 True
D、不记录重定向。只有在运行测试时自动根据请求重定向
 

“思考时间”是用户浏览网页所花费的时间，其中包括查看网页和确定下一步操作。思考时间不包括加载网页所需的时间。

在记录 Web 测试时，会记录每个网页的思考时间。以后，在运行 Web 测试时，会使用或忽略思考时间。在“Web 测试查看器”中使用“思考时间”按钮，可以从使用思考时间切换到不使用思考时间。

思考时间在负载测试过程中非常重要，因为它们决定了测试的节奏。务必要检查所记录的 Web 测试思考时间，以确保它们能够准确地反映真实的等待时间。在记录会话期间，用户非常容易分神，从而导致意外的超长思考时间，这会给负载测试带来负面影响。为了避免此问题，可以暂停记录器。