CMMI软件能力成熟度模型集成认证

　　凡是有软件开发主营业务的企业，我相信都应该听过CMMI(能力成熟度模型集成)，但是很多企业对于这一块，理解的意思只是用来招投标需要的一个认证，而且认为它很贵。

　　是的，以上的两个都是大多数软件开发企业都认同的，如果没有需要招投标，谁又会去做又麻烦，又贵的一个认证呢?

　　就来谈谈什么是CMMI，尽量用最直白的语言来告诉各位什么是“能力成熟度模型集成”

慧捷科技股份通过CMMI3认证评估并获取证书

什么是CMMI能力成熟度模型集成

CMM软件过程改进前常见问题解答

CMM实施中的战略问题

CMM与CMMI的区别

CMMI评估流程

CMMI目标和实践汇总

CMMI V1.3

什么是CMMI能力成熟度模型集成　
CMMI能力成熟度模型集成
  CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型），是美国国防部的一个设想，1994年由美国国防部与卡内基-梅隆大学下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会共同开发和研制的。其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。 。
自从1994年SEI正式发布软件CMM以来，

CMM软件过程改进前常见问题解答
随着国务院第18号文件明确鼓励软件进出口型企业通过国际质量方面的认证，并在省市政府、科委以及软件园发布鼓励政策的大力配合下，越来越多的企业希望改进软件过程来提高企业的竞争力。虽然很多软件企业得到了ISO 9000质量认证，但ISO 9000不是专门为软件企业设计的，因此有些地方不能真正为软件企业解决问题。最近，越来越多的软件企业希望通过实施基于CMM的软件过程改进提高自身竞争力，原因就是CMM是专门为软件企业设计的。软件企业的国际化进程也随之加快，一些大型软件企业完成CMM认证的同时，也为相当多的中小软件企业带来了希望，但他们在实施CMM的过程中，特别是在向CMM2前进时往往存在很多困惑和疑问。
那么什么是CMM呢？
CMM是指“软件能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。CMM的定义是：对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。CMM分成了5个成熟度级别，其中任何软件企业都可以认为是成熟度级别为1级的组织。换句话说，1级的企业在软件过程方面有很多问题。随着成熟度级别的升高，企业的软件过程能力越强。
但是，俗话说：“万事开头难”。对于很多企业的决策层，在启动CMM改进项目以前，特别是向CMM 2级前进的时候，往往会有各种各样的问题和困惑，也会有各式各样的错误理解。比如：在CMM实施前和过程中经常会出现什么问题？这些问题应该怎么面对和解决？在CMM的实施过程中应该有一个什么心态等等。这些问题在下面的文章中您都可以找到答案。我将对一些CMM实施过程中最常见的、决策层最关心的问题给出一些观点、解释和建议，希望能够通过这篇文章使大家对CMM的认识再上一个台阶，对今后想实施CMM的企业有一个初步的指导。
关于实施时间
Q：我们公司已经决定按照CMM 2级的要求实施过程改进，最快需要多久达到2级的水平？
A：这个问题就像一个病人充满希望地向医生询问：“你看我的病什么时候能好？”。虽然这是很多准备实施CMM的企业非常关心的一个问题，但是这个问题让任何人都会感到很难回答。这是因为过程改进所需要的时间与很多因素有密切关系，特别表现在以下方面：
★ 企业决定进行软件过程改进的目标和商业需要（如：改善软件开发管理；提高软件产品质量；降低软件开发工作成本；提高企业在业界的知名度和信誉等）：不同的目标需要不同的工作方向去实现，改进的难度也不同，必然会影响时间进度。
★ 企业当前的过程情况：一个企业如果在软件开发过程方面已经比较规范，很多过程均已得到了良好的定义，并形成了文档，质量保证体系也很完善，则达到CMM 2级的要求应该容易一些，相对来说改进的时间也能够短一些。
★ 企业实施的范围：一个企业的哪些部门实施基于CMM的过程改进，或者说涉及过程改进的人员有多少，会影响时间进度。可以说，实施的范围越小、涉及的人员越少，实施越简单，时间越短。
★ 企业的文化：对于一个存在多年的企业，变化对它来说可能是非常困难的；一个企业是否愿意主动去接受变化，很大程度上将影响过程改进的难度和进度。通常情况下，一个刚成立不久的公司，实施过程改进的阻力要小得多，这就是“船小好掉头”的道理。
★ 将来要作为试点项目的周期：一般情况下，我们建议一个按照CMM 2级实施过程改进的企业选择3~5个生命周期比较完整的软件开发或维护类型的项目作为试点项目并参加CMM的评估。这些项目可以并发进行，但通常我们希望能有2个左右的项目能够在评估的时候达到试运行或正式交付的阶段。如果企业选取的项目周期都在一年以上，这也会影响进入评估的时间。
★ 10个月左右的时间比较常见：根据SEI官方发布的统计报告（截止到2002年8月份），从大多数进行评估的组织情况来看，组织从1级向2级改进通常需要23个月左右，我们可以通过下面这个图表来了解各个向高级别演进所需要的时间。大家不要被这个接近两年的时间吓坏了，这样的平均时间主要是因为大多数国外实施CMM的公司规模都比较大，项目周期也相对比较长。国内大多数软件企业的规模都不大，加上咨询公司的帮助，用10个月左右的时间达到CMM 2级要求还是比较常见的。
★ 实施时间上能不能再短一点呢？任何一个够资格的SEI授权主任评估师都遵从一个原则，一个组织中的过程在定义、形成文档并发布之后，需要一个至少六个月的稳定运行期。因此，可以说一个组织在实施按照CMM 2级要求的过程改进时，至少需要8个月左右的时间（2个月过程以及文档化加上6个月的稳定运行期）。除非有专业人员深入了解企业现状，可能会根据实际情况作少量调整。 （待续）
下期预知：
提示软件企业在资源投入方面应做的准备：人员、岗位及设备工具。 

关于评估范围
Q：我们将来需要什么样的项目参加评估比较合适？
A：这必须慎重，否则可能会对评估结果、实施效果及企业获益影响很大。原则上说，CMM 2级评估没有对试点项目做出什么特别的要求。一般只要是生命周期比较完整，项目组成员人数在5~10人，周期在3~6个月的项目均可，当然这也不是一定的。
对于很多企业来说，通常会有两类项目，即自主研发的产品类项目和基于客户具体需求的工程类项目。究竟使用哪类项目进行试点，是很多企业决策者争论和考虑的地方。这两类项目在作为试点项目方面各自的优势可见表1：
显然，产品类项目风险比较小，可控度比较高；然而，工程类项目往往是最容易管理混乱的。因此，把工程类项目作为试点项目企业收益会更高。有一家公司就曾经怀着尝试的态度在两个金融领域的工程类项目中进行CMM试点，这两个项目的客户都是银行相关业务科室的人员。令他们非常意外的是，当他们告诉客户正在做CMM改进时，客户显示出了非常浓厚的兴趣。对于参加需求规格说明书评审会这样的CMM建议的活动，他们也积极配合；质量保证方面，客户还专门派了一个人配合。到了项目验收的时候，客户在验收单上签字的工作比他们历次任何一个项目都顺利，因为客户在项目开发的整个过程中很清楚地了解项目的进展和问题，并且对于项目的结果有很强的信心。这家公司的高层经理，也因为客户满意度非常高而认识到了过程改进的好处，并决心加大这方面投入的力度。相反，有些公司为了减少过程改进的实施难度，用产品研发类项目作试点，结果现在大家抱怨因为管理产生的工作量太多了而产生抵触情绪，反而影响了实施效果。
我们一般还建议选择生命周期比较完整的项目作试点，这是因为：在CMM 2级的配置管理KPA中，有些要求是关于测试和产品构建的，如果没有一个试点项目在评估的时候能够进入集成测试或者产品发布这样的产品开发后期阶段，就有可能因为找不到评估证据而被主任评估师要求延期评估。所以，如果一家企业选择了多个项目作为试点的话，可以不必所有的项目都能够非常完整的到达后期阶段，有1~2个项目即可。
对于试点项目的规模，特别是人数，应注意这样一个问题：如果一个企业希望在整个公司内实施CMM并进行评估的话，那么每个和软件开发、维护相关的部门都应有半数以上的人参与试点项目。对于不打算在整个公司范围实施的企业，大量实际情况表明，5~10人规模的中小项目在实施效果和难度方面都是值得推荐的。
目前对于大多数国内的软件开发项目来说，还是3~6个月的最多。为期6个月的项目刚好可以满足6个月的过程稳定期，在这个基础上时间长点、短点问题都不大。至于说项目开发地点是否在公司本地，其实影响不大。而项目经理是否能够认同过程改进的价值，高层经理能否真正保证项目组有足够的资源来实施新的过程，也应是此时考虑的一个重点问题。
Q：既然CMM 2级是项目级别的，我们用一个规模很小的项目去实施过程改进，并参加评估，岂不是很容易？
A：选择小规模的项目作为试点在理论上是可以的，因为SEI并没有规定这样做不允许，但我们强烈建议大家不要这样去做。规模小的项目沟通方便、风险小，是否需要按照CMM的要求和建议去管理应该根据具体情况去分析。如果一个1、2个人月工作量的项目要花费大量精力去形成管理文档，会让人觉得是一种罪恶。曾经有一家公司，希望在该公司一个部门实施CMM，但该部门绝大多数项目都是基于一个已经很成熟的核心产品，只需根据客户定制的一部分额外需求进行开发，因此开发工作量很小。而对于该部门来说，在客户现场将老系统切换成为新系统，并保证新系统能够稳定运行倒是非常重要。虽然这方面的工作每次只需要一、二人，二周时间就足够了，而且有关人员因为对这方面业务非常熟悉，项目失败的风险并不大，项目组也不会留下什么文档，但他们希望能够通过过程改进加强这类项目的管理，减少人员流动为该部门带来的损失。但是，这个公司定义出来的过程文档主要是用于开发类型的项目，而他们又没有足够的数据对过程进行分析和裁剪，结果造成几乎管理工作量比工程活动工作量还要多，项目组有关人员均对这套过程表示了怀疑，并开始对过程改进活动产生抵触情绪。
关于试点项目的数量，一般来说1个是不够的。有的主任评估师认为CMM 2级的特点是repeatable，即可重复的，就需要一套成文的过程应该在至少2个项目中使用。如果一个项目规模很大（100人以上），周期很长（2年以上），通常被拆分成若干个子项目进行开发，并且能够充分的体现实施CMM的有关证据，那么可以允许仅有1个项目参加评估。如果是一般规模或规模较小的项目，一定是不允许的。
规模小、数量少确实可减少实施难度，但企业如为了真正实现商业目标，通过改进获益，他们是不会这样做的。
Q：我们可不可以只在公司下面的某一个部门实施CMM，以便减少实施的难度？
A：可以，因为CMM中“组织”一词，它既可以代表一家完整的公司，也可以代表一个或多个部门。因此，即使在评估CMM 5级的时候，也可以只对某一个部门进行。CMM 2级是面向项目级别的，实施的时候这方面灵活性更大。不过主任评估师向SEI提交评估结果时会明确写明评估是在企业的什么范围内进行的（多少部门纳入评估范围，参与的软件开发人员和管理人员的数量等）。现在很多企业宣传时，有意无意掩盖了这一点，只是泛泛说：XX公司已经达到了CMM 2级的要求，久而久之造成了很多错误的认识。不过，如果企业希望通过过程改进真正获益的话，最好还是能够在整个企业中所有与软件活动有关的部门实施。
虽然2级是面向项目级别的，但我们非常欢迎和支持在整个公司的范围内实施CMM 2级。这样，公司积累大量不同项目的宝贵经验，有利于向3级迈进。
我个人认为，如果一家公司希望能够成为CMM 3级的公司的话，如果在2级的阶段投入比较多，实施的效果比较好，那么3级的实施难度会下降很多；反之，3级的实施难度会增加；因此可以说，一个公司在从1级到3级这个过程中所投入的资源总数基本上是一个固定值。既然如此，为什么不早一点把工作做到实处，早一点获得成效呢？
关于评估方法
Q：CMM的评估方法是怎样的？
A：基于CMM的正式评估有一个专用的名称：CBA IPI（CMM Based Appraisal for Internal Process Improvement - 用于内部过程改进的基于CMM的评估）。如果用一句话来介绍这种评估活动的话，可以这样说：它是通过抽取一个组织中的采样数据和信息，通过文档审阅、同组织中各个不同角色的人员以访谈、讨论的形式获取数据和信息，对这些收集到的信息进行整合、分析、确认，形成最终的结果。正式评估之前的一段时间，通常还会组织预评估（Pre-assessment），绝大多数SEI授权的主任评估师都会采用迷你评估（Mini-assessment）的方式。
下面详细一点地介绍这套评估方法。评估过程中的活动可以分成2大类：前现场活动（Pre-On-Site Activities）和现场活动（On-Site Activities）。
☆ 评估小组：每次评估的时候都需要有一个评估小组，人数大约是4~8人。其中组长由SEI授权的主任评估师担任。对于级别高（如4级或5级）的评估，往往需要2个主任评估师。其他的人员多数来自被评估的公司内部，这主要是希望评估结果能够更容易被公司大多数人接受。至于说这些人是否能够在评估中保持客观性是至关重要的，这个方面可以由主任评估师来保证。另外，评估小组成员的知识技能背景会对评估结果产生显著的影响，因此要求评估小组成员熟悉CMM。
☆ 前现场活动：前现场活动实际上也是在现场完成的，只不过更多的是在正式评估开始前要完成的工作，一般是在预评估最后的时候完成，主要包括识别评估范围、制定评估计划、填写成熟度问卷等。其中识别评估范围非常重要，这项工作主要分为2个方面：一是在公司的什么范围进行这次评估，是整个公司还是其中某些部门？二是这次评估评的是CMM几级？要知道，如果是2级的，那么对于3级和更高级别的KPA根本不予考虑。不存在这种可能：我们先在整个公司范围进行评估，如果发现某些部门做得不好，就从评估范围中剔除，退一步可以评几个部门的。在正式评估的时候，评估范围是不允许调整的。成熟度问卷是SEI提供的标准问卷，但它并不被看成是一个重要的工作，因为该问卷基本上就是把模型中的要求用陈述句换成了一般疑问句，几乎所有答卷人都能够判断出来填“是”会比其他的选项要好，于是这份问卷更多地变成了一种形式。唯一被认为有价值的东西是问卷中每个问题后面可能填写的补充或注释。
☆ 现场活动：现场活动遵循SEI要求的标准流程执行，如图2所示：
其中，重点是访谈和评级过程。访谈是整个评估工作中非常重要的一个数据来源。参与访谈的人员一般分为3种类型：项目经理、中（高）层经理以及功能区域代表。中（高）层经理直接听取项目经理汇报项目情况，他们可以在项目组出现无法解决的问题时负责协调和处理。功能区域代表是具体的实践人员的代表，包括系统分析设计人员、编码人员、测试人员、配置管理员以及质量保证人员等。对于项目经理，需要进行单独的访谈，会根据评估要考察KPA一一提出问题，每个人平均约有1~2个小时的时间。中（高）层经理和功能区域代表分成组来参加访谈，回答相应的问题。评估小组的成员在访谈过程中会做笔记，参加访谈的人员基本上就是根据自己亲身经历如实介绍情况即可，因此回答是没有标准答案的。不过很多参加访谈的人员会感到非常紧张，特别是单独接受提问的项目经理们，曾经有的项目经理正在回答一个问题的时候，说着说着突然停下来问：“你刚才问的问题是什么来着？”其实大可不必，因为评估小组会严守保密性的原则，在评估工作结束后还会销毁所有的纪录。每天访谈工作结束之后，评估小组整理和分析，和CMM的每条关键实践分别对应，写出结论（这样的结论性语句称为“观察项”）。
在所有的评估活动中，大家最关心的恐怕就是评估的结果是如何确定的了。其实有了评估时前面数天的成果，最终的结论是很容易做出的。评估小组根据作出的一条条观察项，逐条检查用词是否合理恰当，是否得到了多个数据来源的反复确证，是否有不同观察项之间存在矛盾的情况。如果这些观察项都得到了检查并被确认无误，评估小组会对找到的不足之处（发现的弱点）进行分析，看是否对KPA下面的目标实现有显著的影响。评级的思路可以参见图3： 在CMM中，每个KPA下面都有若干个目标，并有数条关键实践与目标对应。如果一个目标对应的关键实践没有明显的弱点阻碍该目标的实现，则认为该目标得到了满足。如果一个关键过程区域下面的所有目标都满足了，则该KPA也就是满足的。当某个成熟度级别之下所有的KPA都是满足的，则被评估的公司成熟度级别就是此级别。这句话必须要正确的理解：一方面，如果一家公司希望成为CMM 3级的组织，则必须在评估中把2级和3级包含的所有关键过程区域都做到满足才能实现这一目标。另外，即便某家公司已经在正式评估中达到了2级的要求，一段时间后该公司希望进行3级的评估，2级的内容同样要在评估中检查。另一方面，举个极端的例子来说，如果一家公司做3级的评估，评估结果是3级的所有KPA均得到了满足，但2级中如果有不满足的KPA，则该公司的成熟度级别为1级。虽然这情况几乎不可能出现，因为如果该公司2级有做得不好的KPA，3级的KPA几乎不可能全都做得很好。图4是比较常见的一种情况，因为2级中有没有做好的KPA，虽然是做3级的评估，但结果是1级：
◆ 预评估与正式评估的区别：参照上期图2，预评估（即迷你评估）主要的区别在从第六步之后的内容简化成了一步：预评估结果展示。预评估通常作4天左右，检查的样本数据会比正式评估时少一些。还有一点非常重要的区别是：预评估时不评级，结果中不会提及当前组织的CMM成熟度级别的情况，但对于所有KPA下的目标，都会给出一个1-10分之间的分数。不同的分值代表的意思是：
▲1-3分：不满足
▲4-6分：部分满足
▲7分：基本满足，但有少许不足
▲8分：满足
▲9分：非常出色
▲10分：世界级的实践，非常完美
如果所有被评的KPA的目标都是7分或8分的话，可以说正式评估的结果极有可能是比较乐观的。但如果有目标还在3分或4分附近徘徊的话，那可能就需要再经过几个月的时间努力改进，否则正式评估很有可能会得到失败的结果。
Q： ISO9000质量体系认证定期需要复审，CMM是否也是这样？
A： ISO9000质量体系认证一般每年都需要复审，但CMM是不需要的。因为CMM的评估主要目的是找出与被评估企业的软件过程相关的问题，从而使该企业针对这些发现的问题进行企业内部的自发的改进。因此SEI强调CMM评估不是一种认证，SEI也从来没有向任何一家组织发过这样的证书。既然不是认证，就不必进行复审，无论评估的结果是好是坏。目前国内企业在评估之后得到的证书格式都不是统一和标准的，但SEI授权的主任评估师会在证书上签字，并把评估结果发送到SEI的数据库中。

有关ISO与CMM的比较
Q：我们已经拿到了ISO9000的质量体系认证，这对实施CMM有什么影响？
A： 国内软件公司采用的ISO 9000系列质量体系认证通常有ISO9001的1994年版和2000年版。ISO9001和CMM非常相似的是，两者都共同着眼于质量和过程管理，而且它们都是基于戴明博士的全面质量管理产生的，因此不存在任何矛盾的地方。但是，它们的基础是不同的：ISO9001（ISO9000标准系列中关于软件开发和维护的部分）确定一个质量体系的最少需求，而CMM强调持续过程改进。在1994年版的ISO 9001中，CMM 2级的6个关键过程区域所涉及的部分，基本上都比较明确的做出了要求；而CMM 3级的7个关键过程区域中所涉及的内容大多数都提到了，但做出的要求不是非常详细。很多实施了94版ISO的企业在了解了SW-CMM以后，普遍反映CMM比ISO的要求明确、详细得多。如果94版ISO实施的效果很好的话，实施CMM 2级工作量是可以减少很多的。而2008版的ISO则更多的和CMM有直接对应的关系，甚至是大量CMM 4级和5级的要求。
目前我看到的大多数已经实施了ISO9000质量体系认证的软件企业，在实施CMM的时候在以下方面会有一定的优势：
★ 都拥有已经形成文档的程序文件。但因为ISO 9001的高度抽象性，有些程序文件定义的不是很具体，CMM中有些关键实践无法体现，但也有些企业花费了不少精力将ISO 9001的条款和软件工程相关的实践进行了很好的结合，相对来说就能够体现绝大多数的CMM要求的实践。这样的话，按照CMM要求建立过程体系的工作量就可以减少很多了。
★ 对于过程改进的概念已经比较熟悉了。如果ISO实施的比较认真到位的话，过程改进方面的理念应该在企业中比较深入人心，无论是高层经理还是开发人员都会对这方面的工作比较认同和支持。
★ 绝大多数拥有ISO9001质量体系认证的企业都已经配备了和质量保证相关的工作人员，质量目标、方针和意识都比较明确。
有利就有弊，某些企业如果ISO实施的不是很到位的话，在实施CMM的时候也可能遇到这些问题：
★ 通过ISO 9001质量认证的实施过程，企业过分强调认证本身的重要性，证书拿到之后定义的过程就不再全面、认真地实施了，公司的员工发现过程改进工作变成了走形式、走过场。因此在整个企业中弥漫着一种对于过程改进非常抵触和消极的情绪，绝大多数人员普遍对CMM表示怀疑、信心不足。
★ 高层经理对实施CMM难度认识不足，他们通常会觉得：9000的认证不是很简单么？几个人花上几个月的时间不就搞好了，CMM想必也是差不多的，实施以后公司也没有什么特别明显的效果和收益。于是他们觉得CMM这件事情很容易，不需要花很多的心思和人力就可以轻松过关，这样对于SEPG的过程改进工作难度就很大了。
上述情况对于CMM强调的持续过程改进带来的负面影响是非常巨大的。除了企业过分强调证书以外，产生这些问题的原因还有以下几个方面：
★ CMM分成了5个成熟度级别，每个级别都是更高级别的基础。而ISO 9001要求企业把所有的条款一次性做好，其中当然也包括一些CMM高级别中的类似要求。对于任何一家企业，在刚刚开始进行过程改进的时候，想很好地实现这些要求是非常不容易的。
★ ISO 9001中没有明确的制度化方面的要求，尽管定期地对企业进行复审，但很多企业仍然不清楚到底如何去更好地把这些流程制度化。在CMM中，有4类和制度化相关的关键实践。简单说来“制度化”的意思是：把企业中已经定义好的过程在相当长的时间和相对广泛的范围内保持良好、到位的实施。CMM每个KPA都有关于制度化方面的要求，比如：通过组织方针来约束所有人去遵循过程的要求；通过提供充足的资源和资金、培训以及分配明确的职责来保证大家的使用过程；通过收集数据和量化的分析来判断过程是否仍有不足，如何改进、如何提高过程的效率；通过不同级别的管理人员以及质量保证人员的检查和监督确保大家按照要求的流程去做事等。
★ CMM只关注软件，而ISO 9001有更大的范围，对于制造业非常合适，即使是IT领域，也包括了硬件、软件和服务。因为ISO 9001的咨询师和审计员不一定是软件方面的专家，加上ISO 9001的高度抽象性，审计员可以以不同的方式解释实践的合理性，这就使一些拿到认证的企业仍然是CMM 1级的组织。另外，软件企业实施ISO的过程中，遇到了一些以软件企业角度去理解相关条款的问题时，可能无法从咨询师和审计员那里获得满意的答案。我曾经看到这样一家企业，他们实施ISO9000:2008版已经半年多了，此时决定实施CMM。我看了他们的程序文件，感觉定义的非常好，项目计划、配置管理、质量保证方面几乎已经达到了CMM 2级的要求，但通过和部门经理、项目经理以及开发人员代表座谈，发现大家实际的做法和过程要求的完全不一样。究其根源，就在于当项目经理和开发人员对于公司流程要求的做法和实践表示不理解或不明白的时候，负责定义流程的人员无法给出令人信服的解释，久而久之，流程的执行变成了形式化的东西。
有关CMM实施困难
Q：实施过程改进时，最容易忽略的问题是什么？
A：最容易忽略的问题其实就是一个：CMM一直强调的持续的过程改进。
★ 在我看来，CMM 2级的6个关键过程区域的121条关键实践其实在实施的时候并不是真正的难点。相对来说，真正的核心是建立过程改进的基础，也就是说要让企业中所有的相关人员能够建立过程改进的意识，要能够主动发现组织中的各种问题并且对其进行改进。如果真的能够达到这个目标，到了正式评估的时候，即使在2级的关键实践中有一些做得还不是很好，有经验的主任评估师也会认为基本上达到了CMM 2级的要求。
★ 如果想达到CMM强调的过程改进的持续性，就必须要注意：在开始实施过程改进前，一定要以商业目标为基础。也就是说，不要总想着我们只要过了CMM，就可以争取市场上的更大的份额，就可以签下更多的订单；而应该广泛的收集企业中所有人员关于改进软件开发流程的建议和呼声，高层经理根据这些改进的呼声确定企业中存在的问题有哪些，通过过程改进能够解决哪些问题，能够帮助我们的企业实现什么样的商业目标。绝大多数的企业可能会把商业目标确定在以下几个方面：
▲提高软件产品和项目的质量，降低缺陷率
▲提高客户满意度，减少客户投诉
▲降低软件开发成本
▲提高软件开发进度，减少延期交付产品的情况
▲提升企业知名度，增加企业市场竞争力
可以看出，上述商业目标实际上是相互影响的，在实施过程改进开始的时候，不要把目标定得过高过大，只要把过程改进认真落实，并且保持着组织中对于过程改进的焦点和关注，经过一段时间后，势必会在上述这些方面获益。
★ 对于持续的过程改进，可以采取SEI推荐的IDEAL模型为参照。IDEAL是下列5个英文单词的缩写，代表着组成软件过程改进周期的5个阶段：
▲初始化 (Initiating)
▲诊断 (Diagnosing)
▲建立 (Establishing)
▲行动 (Acting)
▲扩充 (Leveraging)
详细内容可参见左图。

 


由图可见，一般企业非常重视的评估工作，只不过是IDEAL模型中的诊断阶段“评估当前实践情况”所对应的内容。每次评估活动，其实是一轮过程改进较早期的活动，因此不少有经验的主任评估师特别强调，如果你不打算继续作过程改进，那你就不要做评估。因为CMM评估的目的就是帮助企业发现过程中的问题，并为新一轮的过程改进提供输入，企业根据评估的结果以及主任评估师给出的建议制定相应的过程改进计划，并且相应实施。因此，请不要过分看重CMM评估，而忽略了更重要的东西。
Q：在实施基于CMM的过程改进时，难度最大的KPA是哪些？
A：根据SEI在2002年8月份发布的统计数据来看，如下图：
上图是根据全球496次正式评估得到的统计图表，其中我们重点关注CMM 2级的6个关键过程区域的情况。图中对于每一个关键过程区域都有2个数据，分别表示在这496次评估中完全达到要求的比例和进行了评估的比例。换句话说，在2级的6个KPA中红色柱最短的应该就是实施难度最大的KPA，这样看来子合同管理似乎是实施难度最大的KPA。但我们发现产生这种情况的原因是：在绝大多数的软件企业中没有需要进行子合同管理的情况，这样，子合同管理这个KPA在60%以上的评估中被定为“不适用”或者“不评级”。除去这个KPA，在90%以上的评估中，二级中的其他5个KPA都进行了评估，而只有10%多一点的评估中SQA（软件质量保证组）能够做到完全达到要求，这足以说明SQA是CMM 2级实施过程中难度最大的KPA，需求管理的实施难度最小。具体分析，原因如下：
★ 和各企业对于不同KPA的重视程度有关系，需求管理几乎是所有软件企业都非常重视的内容，毕竟需求管理不好，需求变更频繁对项目组的工作量、进度和成本等方面影响是巨大的，于是各企业无论是否进行基于CMM的过程改进，都努力在找出使项目组和用户就将来产品的功能、性能等达成一致理解的方法，并尽一切办法减少客户提出需求变更的可能。相对来说，质量保证的工作就不那么引人注意了。
★ SQA的工作带有一定的预防性质。大家都知道，在软件公司里面，评判一个人是不是“高手”的准则是他能不能解决其他人都解决不了的问题，就像给人治病的医生，能够治疗疑难杂症的是“神医”；不知道大家有没有想过，如果有个医生在病人刚刚出现轻微症状的时候就能把别人的病治好，对于病人来说是莫大的幸事，但这样的医生恐怕一般人不会认为他是个好医生，同样，SQA也是如此。
★ 很多国内的软件企业一边在抱怨他们的客户成熟度低，对于软件什么也不懂，每天都在提出一大堆的需求变更，另一方面却在充分的利用客户什么都不懂，在软件产品的质量上睁一只眼闭一支眼，毕竟高质量的产品需要更高的成本来换取，既然用户也没有那么高的质量要求，何必费那么大的力气呢。可是他没有想过，这种做法和一些黑作坊里面生产“三无”食品并没有什么本质上的区别。好在越来越多的软件企业已经加强了质量意识，也使SQA的地位得到了不少的提升。
★ SQA要在组织中得到认同。很多CMM 2级实施不到位的组织经常出现的问题就是无论是高层经理还是项目组有关的人员，大家都认为SQA可有可无，没有必要。如果不是CMM有这样的KPA，才不会安排专人去做这些事情呢。SQA做得好的企业通常有这样的特征，组织中的所有人员能够充分认识到SQA的价值，而项目组中发生的问题都能够在SQA的帮助下友善的解决。
★ 根据CMM的要求可以看出，对SQA沟通能力的要求是比较高的。现在有不少企业的SQA成了“收账的”，根据公司的规定到什么时候项目组应该出什么文档，SQA就冲到项目组那里，大喊：“该交XX文档了！”。项目经理就像老鼠看见猫一样，求饶着说：“项目组现在太紧张了，能不能过几天再说？”到底能不能再说就看SQA的心情了。久而久之，所有的文档都改成了项目结束的时候再统一提交，而到那个时候文档的质量也没有人关心了。CMM要求的SQA可不是这样的，SQA要成为项目组的好朋友，而不是“猫和老鼠”的关系，一方面SQA要执行必要的质量检查和过程检查，这是保证公司的整体利益而必须要做的；另一方面，SQA在执行检查的同时，要通过发现的问题了解项目现在有什么麻烦，在项目组的级别上能不能解决，是否需要向高层经理汇报。要想做好这些事情，要求SQA对上面的高层经理，对下面的项目组反复的沟通，必要的时候还需要请一些技术经验丰富的专家协助执行技术检查，没有相当的沟通技巧是很难做好这些事情的。
对于SQA能否有效的发现问题也是一个不小的考验。如果SQA没有比较丰富的软件开发和项目管理方面的经验，又不具备足够的威望邀请一些有这些经验的人员来协助进行检查的话，项目组就可以随心所欲的“蒙”SQA了。有的公司舍不得让经验丰富的人员来做SQA，结果可想而知；有的公司在实施CMM以后，充分认识到了SQA的价值，将这个岗位采取轮岗制，要求每个项目经理在正式上岗以前都必须先做半年的SQA，以便充分理解这个岗位的难处和重要性，以后可以更好的配合他们的工作，这真是一个很好的想法，值得推荐。
下期预知：
分析不同国籍主任评估师及咨询公司的作用。


有关实施中具体问题
Q：不同国籍的主任评估师资质方面有什么不同？
A：据不完全统计，目前在全球范围内SEI授权的主任评估师有300多位，不过不同的主任评估师在资质上面并不是全都相同。这要从如何成为主任评估师说起：如果要成为主任评估师，除了自身要有相当丰富的软件工程、项目管理等相关知识背景外，还要参加大量的SEI组织的CMM相关知识的官方培训。在正式成为主任评估师以前，必须亲自主持一次正式评估工作，由已经得到授权资格的主任评估师进行考察，如果这次评估工作经过考察没有出现严重的问题和错误，SEI将颁发主任评估师的授权认证。这样的证书在2年内是有效的，有效期内主任评估师可以主持正式评估，其结果SEI认可，也可以监控其他主任评估师候选人主持正式评估的工作。
本来这样的做法可以使成为主任评估师的“门槛”很高，但是还是存在一定的漏洞：如果一个人有个好朋友是主任评估师，他也想成为主任评估师，而他的朋友又不能很好的坚守原则，这样就很容易“混入”主任评估师的队伍。另外，目前很多主任评估师在给客户作评估之前，往往还提供一些相关的咨询服务，这种“既当教练又当裁判”的情况也难免会使一些主任评估师在作评估的时候放松尺度，使得进行过程改进的企业所有的过程改进工作变成了“花钱买认证”，而没有真正从中获益。
基于上述情况，目前国内一些比较有实力的咨询公司为了保证自己的服务质量，也为了能使国内的软件企业在进行基于CMM的过程改进的时候达到真正的效果，在主任评估师的选择上坚持高标准和严要求。他们去请在欧美国家知名度很高、信誉很好的主任评估师来国内主持正式评估工作。这些主任评估师中很多都是SEI首批授权的主任评估师，有些人甚至就是参与制定CMM的人员。这些主任评估师经验丰富，对于CMM的理解非常深刻，而且坚持原则，虽然这对国内的企业来说实施难度也增加了一些，但能够在这样的要求下达到CMM 2级以上的评价才是货真价实的。
还有一点，目前很多国内的软件企业也希望和印度的软件企业一样，通过实施CMM提高自身过程的能力成熟度，以便在海外市场上获得更多的外包订单。这个时候不同的主任评估师也会产生不同的效果。比如，当一家国内的软件企业在和一家美国的企业洽谈外包业务时，告知对方我们已经于某个时间达到了CMM 2级以上的成熟度，对方很可能要了解是由哪位主任评估师来做的评估，如果这位评估师在美国知名度很高，对方可能对这家企业“刮目相看”，后面的洽谈可能就会容易很多。这就像在日常生活中，同样是硕士学位，但知名度高的导师带出来了学生更容易被人接受是一样的道理。
Q：咨询公司对我们实施CMM有什么帮助？
A：目前有不少的软件企业希望通过自身的努力进行过程改进，然后进行正式评估，这是很常见的一种做法。不过，如果希望在实施的过程中困难少一点儿，时间短一点儿的话，最好还是与经验丰富的咨询公司合作。主要的原因在于：
★ CMM作为一个模型，具有高度的抽象性。因此CMM中并没有提出一家软件组织必须如何去做才算是达到了要求，它提出的只是“做什么”。举个日常生活中的例子来说，CMM提出的要求就好像一家公司要求地面要保持清洁，至于是用扫把扫还是用吸尘器吸并不重要。同样对于CMM中的要求，可以有很多种不同的实践来满足。可是，到底什么实践在自己的企业中实施起来既比较有效，还能达到CMM的要求，对于刚开始实施CMM的软件企业来说，这种判断和选择是很难把握的。而经验丰富的咨询公司结合了大量国内软件公司的实践、业内的最佳实践以及主任评估师推荐的实践，帮助企业达到CMM的要求，而且还比较简单易行，实施效果已经经过了很多次的证明，自然能够达到“事半功倍”的效果。
★ 咨询公司对于企业在实施过程中出现的问题经验丰富，可以有效的减少做错事情的可能性。比如高层经理对过程改进不够重视或者有一些误解，特别是资源方面的问题，咨询公司都可以及时发现，并协助参与实施的人员减少随之带来的负面影响。
★ 如果有些企业希望在一个既定的时间目标下达到某个成熟度级别，咨询公司可以帮助实施企业监控进度，对于发现进度落后的情况，根据咨询师的经验也可以及时发现，及时采取纠正措施跟上进度。
★ 如果企业自己实施CMM，还需要自己联系主任评估师，这样在费用上可能会开销很大，咨询公司如果提供评估服务，他们可以根据企业的需求（包括资质和成本等多方面）帮助企业联系到合适的主任评估师，减少企业自己联系的麻烦和额外的成本。
下期预知：
如何公布自己的CMM成熟度级别。

Q：如果我们已经达到了CMM 2级的要求，有什么办法可以公布我们的成熟度级别呢？
A：SEI反复的强调，CMM正式评估的结果不是认证，它只是一种企业内部进行过程改进时的一个步骤，找出自己的问题以便于持续地进行改进。因此，对于正式评估的结果，不论成熟度级别是几级，主任评估师都要把评估结果提交给SEI的数据库，便于SEI统计全球评估活动的情况。但是，有些企业并不希望他们的成熟度级别被公布，一方面可能是认为自己的成熟度级别还不够高，认为公布出去不够光彩；另一方面，有的企业担心自己的竞争对手会了解这方面的市场信息，本来自己希望通过过程改进提高竞争力，竞争对手知道了也可以做过程改进，这样就不能提高自己的优势了。所以，SEI在缺省条件下是不会公开哪家企业当前是什么成熟度级别的，它只会定期公布一些汇总的数字。不过有些企业希望在SEI的官方网站上公开自己的成熟度级别，这也是可以做到的。具体方法如下：进入SEI的信息资源库：http://seir.sei.cmu.edu/pml/，该页面上方的部分主要说明了SEI提供自愿公开成熟度级别的功能的目的和用途，并重点强调了CMM正式评估结果不是一种认证，不要把公开成熟度级别看成是一种“证书”等内容。在该页面的下方，分别是自愿公开成熟度级别要填写的申请表格和察看当前已经公开了成熟度级别的组织名单，如图7。
如果是希望加入此名单，则在点击上图中的链接后进入下一页面，该页面的主要内容就是一份申请表格，用英文填写相关内容即可，如图8所示。
该表格较长，因篇幅关系无法全部列出。当申请成功之后，就可以在列表中看到相关的名单了。如图9所示。
在这里可以查看软件CMM或CMMI两种模型的情况，还可以查看不同的成熟度级别。在软件CMM成熟度级别为2级的组织名单中，我们还可以看到一些来自中国的组织，如图9的中国民航结算中心的信息。



入世后，软件企业的国际化进程也随之加快，一些大型软件企业完成CMM认证的同时，也为相当多的中小软件企业带来了希望，但他们在实施CMM的过程中，特别是在向CMM2前进时往往存在很多困惑和疑问。本文特别侧重对处于这一过程的软件企业碰到的各种疑难问题进行答疑解惑。
有关CMM与CMMI的比较
Q：听说SEI最新推出的CMMI是什么？我们是应该选择CMMI还是CMM？
A：CMMI的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：
不能集中其不同过程改进的能力以取得更大成绩；
要进行一些重复的培训、评估和改进活动，因而增加了许多成本；
不同模型对相同事物说法不一致，或活动不协调，甚至相抵触。
于是，希望整合不同CMM模型的需求产生了。1997年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
CMMI与CMM最大的不同点在于：
CMMISM-SE/SW/IPPD/SS 1.1版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应地应用SS(Supplier Sourcing)部分。
CMMI有两种表示方法，一种是大家很熟悉的，和软件CMM一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别，帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。
软件CMM 2级共有6个关键过程区域，在CMMI增加了1个：度量和分析。原来的6个关键过程区域的名称和内容在CMMI中作了部分改进，但是主体内容没有大幅调整。软件CMM 4级共有2个关键过程区域，在CMMI中仍是2个，只是名称和内容有所改进。软件CMM 5级共有3个KPA，在CMMI中进行了合并，改为2个，但主要内容未变。变化最显著的在CMMI 3级上，原有的7个KPA变成了14个，其中原来对工程活动进行要求的KPA－软件产品工程进行了详细的拆分，并结合常见的软件生命周期模型进行了映射。CMMI中新增的过程区域中还涉及到过去未曾提到的内容，比如决策分析和解决方案、集成团队等。
到底是选择CMM还是CMMI主要基于以下几个方面进行考虑：
实施企业的业务特点：如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。
实施企业对过程改进的熟悉程度：如果企业已经实施过ISO 9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。
实施企业对过程改进项目的预算：不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就经济很多。
实施企业是否可以使用阶段式的演进路线： 如果企业只希望单方面的提高自己在项目管理、工程活动、支持活动或者过程管理四个方面中的某些方面的能力，那么就只能应用CMMI的连续表示方法。如果实施企业可以接受成熟度级别的思路（目前看国内大多数企业还是比较习惯于成熟度级别的），那么就不一定必须选择CMMI了。
实施CMM与CMMI可以平滑的转换。
一来，CMMI并不要求一家企业必须先做CMMI的2级然后再向更高的成熟级别演进，评估的时候也没有这样的要求。
另外，CMMI的评估都会根据被评估的成熟度级别，检查所有不高于该级别的过程区域。换句话说，一个企业在CMM正式评估中达到了2级的成熟度，将来改为基于CMMI进行过程改进。在CMMI 3级的正式评估时，CMMI 2级的内容同样要进行检查。如果我们能够在做CMM 2级的时候就按照CMMI的要求实施，效果没有任何的折扣，但对于实施企业来说，会节省很多在培训和评估方面的“额外”费用。（此处的“额外”费用是指CMMI收费比CMM高出的部分）

CMM实施中的战略问题
   影响CMM成功实施的主要原因并不仅仅是技术问题，更多的是实施战略问题。分析众多企业实施CMM的过程，在其CMM实施战略上存在的问题主要有以下三点。
1. SEPG小组孤立工作
企业在决定实施CMM之前，组织一个小组进行研究探讨是很有必要的，但在决定实施之后，SEPG的组成和工作方式将更为重要。考察国内软件企业实施CMM的过程，我们发现，一些企业在组成SEPG之后就让其潜心制定规范，并在完成之后交给项目组实施，其结果是行不通或效果不好，从而导致CMM实施失败。
那么，问题究竟出在何处？实际上，CMM只陈述了要做什么，但并没有讲清楚怎么做？因此CMM的实施必须由有过程管理经验的人员参与，他们应当对软件生命周期各阶段的过程管理都相当熟悉，并且具备软件生命周期各阶段的实际开发和维护经验。没有这些经验，就无法很好地组织和管理开发与维护过程。其次，在实施CMM之后，过程管理工作应在原来的软件开发维护工作基础上尽量透明，这就要求负责软件开发维护的人员，特别是负责人，必须参与过程管理流程的制定，因为原有的软件开发维护经验并不一定能很好地适应现在的环境。只有软件开发人员和过程管理人员很好地协同工作，才可能使过程管理工作尽可能透明化。此外，制定的规范首先必须是切合实际的，最初的规范不一定是最好的，但必须是可行的，然后在持续的实践中不断完善。
2. 全面展开CMM工作
另一种情况是：SEPG提供了一组看来可行的规范，企业据此全面展开CMM工作。企业的愿望是在尽可能短的时间里完成CMM的实施，但实际情况却可能事与愿违。我们知道，CMM2级所有关键过程域之间都有很多联系，并且贯穿于整个软件生命周期。因此，在实施之初就全面展开CMM工作存在两个弊端：其一，在实施过程中肯定会发现所制定的规范本身有许多地方不适，但因为覆盖面太广而不易确定改进点，结果是欲速则不达；其二，过程管理工作在相当长一段时间内可能会掩盖原来基本软件工程中存在的问题，这将增加发现问题、分析问题和持续改进的难度。因此，CMM的实施应该选择一个着眼点，有计划、分阶段、定程度地进行，这不仅不会延长实施周期，相反还会加快实施的步伐，众多企业的成功实践也说明了这一点。
3. 照搬CMM实施模板
照搬其他企业的CMM实施模板是不可取的。首先，CMM实施模板属于企业的知识产权，除非合法获取，否则就是侵权；其次，其他企业的模板未必适合本企业，因为软件产品的特性、开发方法、开发环境、开发工具以及企业文化的不同都会影响CMM模板的适用性，因此根据自己企业的实际情况草拟一个模板远比直接采用其他企业的模板有意义。

CMMI为企业带来的价值

  第一、能保证软件开发的质量与进度，能对“杂乱无章、无序管理”的项目开发过程进行规范。
  第二、有利于成本控制。因为质量有所保证，浪费在修改、解决客户的抱怨方面的成本会降低很多。绝大多数情况是缺少规范制度，只是求快。项目完成后，要花很多时间修修补补，费用很容易失控。
  第三、有助于提高软件开发者的职业素养。每一个具体参与其中的员工，无论是项目经理，还是工程师，甚至一些高层管理人的做事方法逐渐变得标准化、规范化。
  第四、能够解决人员流动所带来的问题。公司通过过程改进，建立了财富库以共享经验， 而不是单纯依靠某些人员。

CMMI评估流程
　　SEI根据ARC和ISO 15504的要求，以及CMMI的模型给出了A类评估的方法描述SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) 。A类描述是根据CMMI模型，确定组级范围内若干过程域 ( PA，Process Area ) 的CMMI评估，并确定组织的成熟度级别，A类描述必须在SEI授权的主任评估师为组长的领导下完成。就CMMI评估过程而言，其目的是如何能够客观地确定组织所处的工作状态，因此最为重要的是如何采集信息以及据此进行判断。SCAMPI将整个评估分成三个阶段：
阶段1：CMMI评估过程计划和准备
完成CMMI评估过程的准备和设定，其中确定目标(评估等级)、建立责任人(评估组)、工作范围(CMMI评估组织范围和过程域范围)、CMMI评估计划 (时间、进度和资源)等活动。
阶段2：执行CMMI评估
根据第1阶段制定的计划进行数据采集和分析、确定发现的问题以及进行评级。主要是采集覆盖所有过程域、项目生命周期整个阶段，同时能够表征级织的过程能力的数据。在此过程中，需要多次重复采集和分析活动，直至达到相应目标，然后确定相应的发现，确认每一个过程域的初中的评定，这是过程能力级别评定和组织成熟度评定的基础。
阶段3：报告结论
CMMI评估组向评估发起人和被CMMI评估组织递交相应的评估结论。根据组织要求，归档相应评估资料，并按计划要求对部分信息进行保密处理。将CMMI评估结论递交给CMMI标准化组织。

CMMI目标和实践汇总
CMMI通用目标（GG）和通用实践（GP）汇总
GG1Achieve Specific Goals 完成特定目标
GP 1.1Perform Specific Practices 执行特定实践
GG2Institutionalize a Managed Process 使已管理的过程制度化
GP 2.1Establish an Organizational Policy 建立组织政策
GP 2.2Plan the Process 过程计划
GP 2.3Provide Resources 提供资源
GP 2.4Assign Responsibility 分配职责
GP 2.5Train People 人员培训
GP 2.6Manage Configurations 管理配置项
GP 2.7Identify and Involve Relevant Stakeholders 识别并引入相关的利益相关者
GP 2.8Monitor and Control the Process 监督和控制过程
GP 2.9Objectively Evaluate Adherence 坚持客观的评价
GP 2.10Review Status with Higher Level Management 更高层领导审核状态
GG3Institutionalize a Defined Process 使已定义的过程制度化
GP 3.1Establish a Defined Process 建立一个已定义的过程
GP 3.2Collect Improvement Information 收集（经验）改进信息
CMMI特定目标（SG）和特定实践（SP）汇总
CMMI 2：REQM 需求管理
SG1Manage Requirements 管理需求
SP 1.1Obtain an Understanding of Requirements 获得对需求的理解
SP 1.2Obtain Commitment to Requirements 获得对需求的承诺
SP 1.3Manage Requirements Changes 管理需求的变更
SP 1.4Maintain Bidirectional Traceability of Requirements 维护需求的双向可追溯性
SP 1.5Identify Inconsistencies Between Project Work and Requirements 识别项目工作与需求的不一致之处
CMMI 2级过程域：项目规划
SG1Establish Estimates 项目估算
SP 1.1Estimate the Scope of the Project 估算项目的范围
SP 1.2Establish Estimates of Work Product and Task Attributes 估算项目属性
SP 1.3Define Project Lifecycle 定义项目生存周期阶段
SP 1.4Determine Estimates of Effort and Cost 估算工作量和成本
SG2Develop a Project Plan 制定项目计划
SP 2.1Establish the Budget and Schedule 编制预算和进度
SP 2.2Identify Project Risks识别项目风险
SP 2.3Plan for Data Management 项目数据的管理计划
SP 2.4Plan for Project Resources 规划项目资源
SP 2.5Plan for Needed Knowledge and Skills 知识和技能的计划
SP 2.6Plan Stakeholder Involvement “项目干系人”的介入计划
SP 2.7Establish the Project Plan 制定项目计划
SG3Obtain Commitment to the Plan 获得对计划的承诺
SP 3.1Review Plans That Affect the Project 审查从属计划
SP 3.2Reconcile Work and Resource Levels协调工作与资源配置
SP 3.3Obtain Plan Commitment 获得计划承诺
CMMI 2：PMC 项目监控
SG1Monitor Project Against Plan 依据计划监督项目
SP 1.1Monitor Project Planning Parameters 监督项目计划的参数
SP 1.2Monitor Commitments 监督承诺
SP 1.3Monitor Project Risks 监督项目风险
SP 1.4Monitor Data Management 监督数据管理
SP 1.5Monitor Stakeholder Involvement 监督干系人的介入
SP 1.6Conduct Progress Reviews 项目进展审查
SP 1.7Conduct Milestone Reviews 里程碑审查
SG2Manage Corrective Action to Closure 管理纠正措施
SP 2.1Analyze Issues 分析问题
SP 2.2Take Corrective Action 采取纠正措施
SP 2.3Manage Corrective Action 管理纠正措施
CMMI 2：ISM 供应商协议管理
SG1Establish Supplier Agreements 签定供应商协议
SP 1.1Determine Acquisition Type 确定采购方式
SP 1.2Select Suppliers 选择供应商
SP 1.3Establish Supplier Agreements 签定供应商协议
SG2Satisfy Supplier Agreements 满足供应商协议
SP 2.1Execute the Supplier Agreement 执行供应商协议
SP 2.2Monitor Selected Supplier Processes 监督选定的供应过程
SP 2.3Evaluate Selected Supplier Work Products 评价供应商产品
SP 2.4Accept the Acquired Product 验收采购的产品
SP 2.5Transition Products 移交产品
CMMI 2：MA 度量分析
SG1Align Measurement and Analysis Activities 协调度量和分析活动
SP 1.1Establish Measurement Objectives 确定度量目标
SP 1.2Specify Measures 细化度量
SP 1.3Specify Data Collection and Storage Procedures 确定数据收集和存储规程
SP 1.4Specify Analysis Procedures 确定分析规程
SG2Provide Measurement Results 提供度量结果
SP 2.1Collect Measurement Data 收集度量数据
SP 2.2Analyze Measurement Data 分析度量数据
SP 2.3Store Data and Results 存储数据和度量结果
SP 2.4Communicate Results 通报度量结果
CMMI 2：PPQA 过程和产品质量保证
SG1Objectively Evaluate Processes and Work Products 客观地评价过程和工作成果
SP 1.1Objectively Evaluate Processes 客观地评价过程
SP 1.2Objectively Evaluate Work Products and Services 客观地评价工作成果和服务
SG2Provide Objective Insight 提供客观的洞察
SP 2.1Communicate and Ensure Resolution of Noncompliance Issues
通报不符合项，并确保得到解决
SP 2.2Establish Records 建立记录
CMMI 2：SCM 配置管理
SG1Establish Baselines 建立基线
SP 1.1Identify Configuration Items 识别配置项
SP 1.2Establish a Configuration Management System 建立配置管理系统
SP 1.3Create or Release Baselines 创建或发布基线
SG2Track and Control Changes 跟踪并控制变更
SP 2.1Track Change Requests 跟踪变更请求
SP 2.2Control Configuration Items 控制变更
SG3Establish Integrity 建立完整性
SP 3.1Establish Configuration Management Records 建立配置管理记录
SP 3.2Perform Configuration Audits 执行配置审计
CMMI 3：RD 需求开发
SG1Develop Customer Requirements 开发客户需求
SP 1.1Elicit Needs 获取客户的需要
SP 1.2Develop the Customer Requirements 生成客户需求
SG2Develop Product Requirements 开发产品需求
SP 2.1Establish Product and Product Component Requirements
建立产品需求和构件需求
SP 2.2Allocate Product Component Requirements 分配产品构件需求
SP 2.3Identify Interface Requirements 确定接口需求
SG3Analyze and Validate Requirements 分析和确认需求
SP 3.1Establish Operational Concepts and Scenarios 建立操作概念和场景
SP 3.2Establish a Definition of Required Functionality 定义功能需求
SP 3.3Analyze Requirements 分析需求
SP 3.4Analyze Requirements to Achieve Balance 平衡需求
SP 3.5Validate Requirements 确认需求
CMMI 3：TS 技术方案
SG1Select Product Component Solutions 选择产品构件方案
SP 1.1Develop Alternative Solutions and Selection Criteria 开发候选方案和选择准则
SP 1.2Select Product Component Solutions 选择产品构件方案
SG2Develop the Design 设计
SP 2.1Design the Product or Product Component 设计产品或构件
SP 2.2Establish a Technical Data Package 建立技术数据包
SP 2.3Design Interfaces Using Criteria 设计接口
SP 2.4Perform Make, Buy, or Reuse Analyses 分析“制作、购买或重用”
SG3Implement the Product Design 实现产品设计
SP 3.1Implement the Design 实现构件的设计
SP 3.2Develop Product Support Documentation 编写产品支持文档
CMMI 3：PI 产品集成
SG1Prepare for Product Integration 准备产品集成
SP 1.1Determine Integration Sequence 确定集成次序
SP 1.2Establish the Product Integration Environment 建立产品集成环境
SP 1.3Establish Product Integration Procedures and Criteria 建立产品集成规程和准则
SG2Ensure Interface Compatibility 确保接口兼容
SP 2.1Review Interface Descriptions for Completeness 审查接口描述的完备性
SP 2.2Manage Interfaces 管理接口
SG3Assemble Product Components and Deliver the Product 组装产品构件和交付产品
SP 3.1Confirm Readiness of Product Components for Integration
确认产品集成已准备就绪
SP 3.2Assemble Product Components 组装产品构件
SP 3.3Evaluate Assembled Product Components 核查组装的产品构件
SP 3.4Package and Deliver the Product or Product Component 打包并交付产品或构件
CMMI 3：VER 验证
SG1Prepare for Verification 准备验证
SP 1.1Select Work Products for Verification 选择待验证的工作成果
SP 1.2Establish the Verification Environment 建立验证环境
SP 1.3Establish Verification Procedures and Criteria 建立验证规程和准则
SG2Perform Peer Reviews 执行同行评审
SP 2.1Prepare for Peer Reviews 准备同行评审
SP 2.2Conduct Peer Reviews 执行同行评审
SP 2.3Analyze Peer Review Data 分析同行评审数据
SG3Verify Selected Work Products 验证选定的工作成果
SP 3.1Perform Verification 执行验证
SP 3.2Analyze Verification Results 分析验证结果
CMMI 3：VAL 确认
SG1Prepare for Validation 准备确认
SP 1.1Select Products for Validation 选择待确认的产品
SP 1.2Establish the Validation Environment 建立确认环境
SP 1.3Establish Validation Procedures and Criteria 建立确认规程和准则
SG2Validate Product or Product Components 确认产品或构件
SP 2.1Perform Validation 执行确认
SP 2.2Analyze Validation Results 分析确认结果
CMMI 3：OPF 组织过程焦点
SG1Determine Process Improvement Opportunities 确定过程改进机会
SP 1.1Establish Organizational Process Needs 建立组织过程的需要
SP 1.2Appraise the Organization’s Processes 评估组织过程
SP 1.3Identify the Organization's Process Improvements 识别组织的过程改进机会
SG2Plan and Implement Process Improvements 规划和实施过程改进
SP 2.1Establish Process Action Plans 制定过程行动计划
SP 2.2Implement Process Action Plans 实施过程行动计划
SG3Deploy Organizational Process Assets and Incorporate Lessons Learned
部署组织过程财富
SP 3.1Deploy Organizational Process Assets 部署组织过程财富
SP 3.2Deploy Standard Processes 部署标准过程
SP 3.3Monitor Implementation 监督实施
SP 3.4Incorporate Process-Related Experiences into the Organizational Process Assets将过程相关的经验纳入组织过程财富
CMMI 3：OPD 组织过程定义
SG1Establish Organizational Process Assets 创建组织过程财富
SP 1.1Establish Standard Processes 建立标准过程
SP 1.2Establish Lifecycle Model Descriptions 建立生存周期模型描述
SP 1.3Establish Tailoring Criteria and Guidelines 建立裁剪准则和指南
SP 1.4Establish the Organization’s Measurement Repository 建立组织度量库
SP 1.5Establish the Organization’s Process Asset Library 建立组织过程财富库
SP 1.6Establish Work Environment Standards 建立工作环境标准
CMMI 3：OT 组织培训
SG1Establish an Organizational Training Capability 建立组织级培训能力
SP 1.1Establish the Strategic Training Needs 确定战略培训需求
SP 1.2Determine Which Training Needs Are the Responsibility of the Organization
确定由组织负责的培训需求
SP 1.3Establish an Organizational Training Tactical Plan 建立组织培训计划
SP 1.4Establish Training Capability 建立培训能力
SG2Provide Necessary Training 提供必要的培训
SP 2.1Deliver Training 交付培训
SP 2.2Establish Training Records 建立培训记录
SP 2.3Assess Training Effectiveness评价培训效果
CMMI 3：IPM 集成化项目管理
SG1Use the Project’s Defined Process 应用项目定义过程
SP 1.1Establish the Project’s Defined Process 建立项目定义过程
SP 1.2Use Organizational Process Assets for Planning Project Activities
利用组织过程财富规划项目活动
SP 1.3Establish the Project's Work Environment 建立项目工作环境
SP 1.4Integrate Plans 集成计划
SP 1.5Manage the Project Using the Integrated Plans 利用集成计划管理项目
SP 1.6Contribute to the Organizational Process Assets 充实组织过程财富
SG2Coordinate and Collaborate with Relevant Stakeholders 与相关干系人协调和合作
SP 2.1Manage Stakeholder Involvement 管理干系人的介入
SP 2.2Manage Dependencies 管理依存关系
SP 2.3Resolve Coordination Issues 解决协调问题
CMMI 3： RKSM 风险管理
SG1Prepare for Risk Management 风险管理准备
SP 1.1Determine Risk Sources and Categories 确定风险来源和类别
SP 1.2Define Risk Parameters 定义风险参数
SP 1.3Establish a Risk Management Strategy 建立风险管理策略
SG2Identify and Analyze Risks 识别和分析风险
SP 2.1Identify Risks 识别风险
SP 2.2Evaluate, Categorize, and Prioritize Risks 风险评估、分类和确定优先级
SG3Mitigate Risks 缓解风险
SP 3.1Develop Risk Mitigation Plans 制定风险缓解计划
SP 3.2Implement Risk Mitigation Plans 实施风险缓解计划
CMMI 3： DAR 决策分析与解决方案
SG1Evaluate Alternatives 评价候选方案
SP 1.1Establish Guidelines for Decision Analysis 建立决策分析指导原则
SP 1.2Establish Evaluation Criteria 建立评价准则
SP 1.3Identify Alternative Solutions 确定候选解决方案
SP 1.4Select Evaluation Methodsc 选择评价方法
SP 1.5Evaluate Alternatives 评价候选方案
SP 1.6Select Solutions 选择解决方案

CMMI V1.3

2011年是敏捷和CMMI结合的元年，在2010年底发布的CMMI V1.3正式把敏捷的内容写到了CMMI模型中，而之前只是在技术报告中提及。对于CMMI规范这类原先软件工程中作为"重载"的过程规范，和以"轻量级"著称的敏捷方法，终于正式拥抱。

我们的咨询特点就是要有效结合这两者，将敏捷的方法真正地和CMMI模型结合，这种结合不是把两种方法简单的叠加，是有一定的顺序的，并要根据不同的场景来决定的。对于一个不会走路的孩子，如果我们直接教他跑步，那他一定会摔得很惨，所以不同基础的对象，应该有不同的教育方法和顺序。

实际的效果才是最重要的，证书不是我们唯一想要的。