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

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

入世后，软件企业的国际化进程也随之加快，一些大型软件企业完成CMM认证的同时，也为相当多的中小软件企业带来了希望，但他们在实施CMM的过程中，特别是在向CMM2前进时往往存在很多困惑和疑问。本文特别侧重对处于这一过程的软件企业碰到的各种疑难问题进行答疑解惑。 袁庆平，现担任北京博思美亚科技发展有限公司(Soft Tech北京分公司)CMM高级咨询顾问，曾为北大青鸟天桥股份有限公司、中关村科技软件有限公司、青岛中天科技发展有限公司等多家软件企业提供CMM、项目管理和软件工程相关的培训、咨询服务。曾在北京鼎新信息系统工程公司参与CMM 2级实施工作并担任项目经理。

随着国务院第18号文件明确鼓励软件进出口型企业通过国际质量方面的认证，并在省市政府、科委以及软件园发布鼓励政策的大力配合下，越来越多的企业希望改进软件过程来提高企业的竞争力。虽然很多软件企业得到了ISO 9000质量认证，但ISO 9000不是专门为软件企业设计的，因此有些地方不能真正为软件企业解决问题。最近，越来越多的软件企业希望通过实施基于CMM的软件过程改进提高自身竞争力，原因就是CMM是专门为软件企业设计的。 那么什么是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： ISO 9000质量体系认证定期需要复审，CMM是否也是这样？

A： ISO 9000质量体系认证一般每年都需要复审，但CMM是不需要的。因为CMM的评估主要目的是找出与被评估企业的软件过程相关的问题，从而使该企业针对这些发现的问题进行企业内部的自发的改进。因此SEI强调CMM评估不是一种认证，SEI也从来没有向任何一家组织发过这样的证书。既然不是认证，就不必进行复审，无论评估的结果是好是坏。目前国内企业在评估之后得到的证书格式都不是统一和标准的，但SEI授权的主任评估师会在证书上签字，并把评估结果发送到SEI的数据库中。

有关ISO与CMM的比较

Q：我们已经拿到了ISO9000的质量体系认证，这对实施CMM有什么影响？

A： 国内软件公司采用的ISO 9000系列质量体系认证通常有ISO 9001的1994年版和2000年版。ISO 9001和CMM非常相似的是，两者都共同着眼于质量和过程管理，而且它们都是基于戴明博士的全面质量管理产生的，因此不存在任何矛盾的地方。但是，它们的基础是不同的：ISO9001（ISO9000标准系列中关于软件开发和维护的部分）确定一个质量体系的最少需求，而CMM强调持续过程改进。在1994年版的ISO 9001中，CMM 2级的6个关键过程区域所涉及的部分，基本上都比较明确的做出了要求；而CMM 3级的7个关键过程区域中所涉及的内容大多数都提到了，但做出的要求不是非常详细。很多实施了94版ISO的企业在了解了SW-CMM以后，普遍反映CMM比ISO的要求明确、详细得多。如果94版ISO实施的效果很好的话，实施CMM 2级工作量是可以减少很多的。而2000版的ISO则更多的和CMM有直接对应的关系，甚至是大量CMM 4级和5级的要求。

目前我看到的大多数已经实施了ISO 9000质量体系认证的软件企业，在实施CMM的时候在以下方面会有一定的优势：

★ 都拥有已经形成文档的程序文件。但因为ISO 9001的高度抽象性，有些程序文件定义的

不是很具体，CMM中有些关键实践无法体现，但也有些企业花费了不少精力将ISO 9001的条款和软件工程相关的实践进行了很好的结合，相对来说就能够体现绝大多数的CMM要求的实践。这样的话，按照CMM要求建立过程体系的工作量就可以减少很多了。

★ 对于过程改进的概念已经比较熟悉了。如果ISO实施的比较认真到位的话，过程改进方面的理念应该在企业中比较深入人心，无论是高层经理还是开发人员都会对这方面的工作比较认同和支持。

★ 绝大多数拥有ISO 9001质量体系认证的企业都已经配备了和质量保证相关的工作人员，质量目标、方针和意识都比较明确。

有利就有弊，某些企业如果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的过程中，遇到了一些以软件企业角度去理解相关条款的问题时，可能无法从咨询师和审计员那里获得满意的答案。我曾经看到这样一家企业，他们实施ISO 9000 2000版已经半年多了，此时决定实施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高出的部分）

Q：听说SEI到2003年底将不再继续支持SW-CMM 1.1版，那我们是不是到时候必须要改为使用CMMI？

A：到目前为止了解到的消息确实如此，不过软件CMM并不像大家想象的那样到今年年底就不复存在了。

SEI为了让CMMI有更多的用户，已经宣布到2003年底，不再继续对软件CMM提供支持。这种现象就像是微软公司在推出新版本的Windows后，一段时间后就不再对过去版本的产品提供技术支持是一样的道理。

但为什么可以说CMM并不会到了2003年底就不复存在了呢？这要从SEI对于CMM的支持都包括哪些内容说起，其中主要包括提供CMM相关知识的培训，公开世界上一些软件组织实施CMM后发表的论文，解答来自全球软件组织关于CMM的问题，为主任评估师提供授权证书，管理CMM正式评估相关的信息数据库等等。除此以外，大家还要知道每位主任评估师的资格证书是有2年的有效期的。这样我们就可以作出下面的结论了：如果主任评估师在2003年拿到了资格证书，他们可以在2004年和2005年继续为软件企业提供培训和CMM正式评估的服务，而此时SEI对这样的结果是认可的，只不过SEI不会在进入2004年以后再颁发新的CMM主任评估师的资格证书了。按照这样的思路，我们可以说CMM可以一直使用到2005年12月。在那之后，恐怕大家只能使用CMMI了。不过，现在在主任评估师当中，仍然存在着大量的争论，很多人仍然坚信CMMI不能完全替代CMM。客观地讲，CMMI确实比CMM要先进，质量也高出不少。但CMM已经被应用了10年多了，有些人对它的感情还是很深的，所以有的主任评估师猜想SEI可能会延长对CMM的支持时间。但目前我们还没有收到任何这方面的消息。

Q：听说软件CMM 要出3.0版了，这是真的么？

A：在2002年12月份，我们听说了这样的消息。这似乎和SEI宣布到2003年底就不再支持软件CMM有些矛盾。其实是这样的：CMM 3.0版本的研发并不是SEI宣布要进行的项目，而是卡内基·梅隆大学宣布要研发的。不过有不少坚持支持CMM的主任评估师对此表示极大的

兴趣和欢迎，也有不少主任评估师对此事表示担忧，因为CMMI的研发是得到了美国国防部大力支持的，这样擅自决定开发软件CMM的新版本恐怕很难得到“老东家”的支持。果然不出所料，在我们大家充满好奇期盼新版本的软件CMM的时候，我们在2003年4月上旬接到了这个项目被取消的消息，虽然不是官方宣布的，但消息来源非常可靠。作为实施的企业，大可不必为此担忧。只要认真地实施过程改进，目前的软件CMM 和CMMI都可以帮助我们取得很好的效果。 结束语

以上十八个问题是对实施CMM前，软件企业各级管理人员通常要考虑的几个方面进行的一个简单的概括说明。当然，对实施CMM的探讨决不仅限于此。我希望通过这十八个问题，使将要进行过程改进的企业能对CMM有一个正确的认识，找到一个简单有效的途径来帮助企业实施CMM。本文若有不正之处，希望读者能够通过yuanqingping@263.net提出意见、建议，进行讨论，以便能有进一步的改进和提高。

兴趣和欢迎，也有不少主任评估师对此事表示担忧，因为CMMI的研发是得到了美国国防部大力支持的，这样擅自决定开发软件CMM的新版本恐怕很难得到“老东家”的支持。果然不出所料，在我们大家充满好奇期盼新版本的软件CMM的时候，我们在2003年4月上旬接到了这个项目被取消的消息，虽然不是官方宣布的，但消息来源非常可靠。作为实施的企业，大可不必为此担忧。只要认真地实施过程改进，目前的软件CMM 和CMMI都可以帮助我们取得很好的效果。 结束语

以上十八个问题是对实施CMM前，软件企业各级管理人员通常要考虑的几个方面进行的一个简单的概括说明。当然，对实施CMM的探讨决不仅限于此。我希望通过这十八个问题，使将要进行过程改进的企业能对CMM有一个正确的认识，找到一个简单有效的途径来帮助企业实施CMM。本文若有不正之处，希望读者能够通过yuanqingping@263.net提出意见、建议，进行讨论，以便能有进一步的改进和提高。

本文来源：https://www.bwwdw.com/article/dtw7.html