CMM简介

 1   CMM问答
 2   CMM2级实施技术问题分析
 3   怎样进行软件过程改进 
 4   持续改进------CMM的精髓 
 5   理解 CMM 需要注意以下问题
 6   CMM简介
 7   CMM应用 
 8   软件企业如何实施CMM 
 9   商业软件企业如何借鉴CMM管理

CMM问答

Q：哪些部门是CMM二级要求必须建立的？ A：一般要求软件测试部具有独立性；同时，在6个KPA中，SQA部门必须是建立的。 Q：哪些部门是CMM三级要求必须建立的？ A：必须建立SEPG部门 Q：SEPG的含义和作用是什么？ A：SEPG是软件过程组，是CMM三级所要求的。但是，为了保证CMM二级顺利进行到CMM三级，往往在实施CMM二级时，就同步考虑了SEPG的建立。 Q：SEPG的主要工作有哪些？ A：主要有：过程标准开发、项目咨询、过程训练、协助团队改变、过程资产维护、过程数据归档、过程评估、技术采用。 Q：在CMM2级中，SQA的地位有多大？ A：SQA组将审查RM、SPP、SPTO、SSM、SCM的工作，它本身则由外部专家进行审查。 Q：咨询和评估这个过程分为几个阶段？ A：五个阶段：分别是：启动阶段、培训阶段、自我改造阶段、预评估阶段和正式评估阶段。 Q：正式评估阶段又如何划分？ A：可简单分为计划、现场和总结三个环节。 Q：评估项目是否按照抽签方式选择？ A：若同类项目较多，往往抽4个项目。而若只有一个，那就评估一个。 Q：系统集成项目如何考虑CMM评估？ A：CMM针对软件，所以进行系统集成项目时，仅考虑其中的软件部分，实施CBA- Q：一个大系统往往有硬件和软件两个部分，如何考虑其完整的评估？ A：有两种选择：一是采用ISO9000质量管理体系；二是选择CMMI评估方式，按照SCAMPI方式进行。 Q：CMM各等级有什么区别？ A：简单的说，一级是初始级，二级是项目级，而三级是组织级；四级需要考虑软件度量，五级要做缺陷管理和改进。 Q：CMM是否存在删减？ A：有，称为过程剪裁，比如删减某KPA或KP。 Q：实施CMM2级中，6个KPA的开展是必须同步进行吗？ A：可以同时进行，也可以分步进行。 Q：同行评审是CMM3级的KPA，能否考虑提前到CMM2级？ A：为了需要，可以提前到CMM2级。 Q：在CMM2级中，如何实现剪裁？即一个项目软件过程定义的设计指南是哪些？ A：这些指南主要表现在：按组织标准软件过程的定义进行选择、选择方法以完成软件作业、进行调整使过程适用于不同的项目、开发和表达工作产品的选择、选择软件生命周期模型。 Q：一个公司声称通过了CMM2级，是指该公司所有的项目都具有了能力了吗？ A：否。CMM2级只针对项目级，某项目经过评估通过后，并不表现其他项目通过了CMM2级。也就是说，CMM2级并不能代表该公司所有的项目。只有CMM3级才是针对公司级的。 Q：CMM实施过程中，主要的困难是什么？ A：困难比较多，主要表现在：一是领导不重视，二是CMM实施项目的管理混乱。 Q：CMM1.1版本是否是最终版本？ A：否。有消息称，CMM3.0将要出台。 Q：CMM二级的整个咨询和评估需要多长时间？在正式评估阶段，面试时间是几天？ A：一般为12个月。若已成功实施ISO9000认证的，可能缩短。此外，在正式评估阶段，面试时间与为L2为5天，L3为8天，L4和L5为10天左右。 Q：ISO9000与CMM有哪些不同点？ A：ISO9000有采购管理，而CMM没有。ISO9000对人力资源管理描述全面，而CMM只针对培训方面做了详细要求。对应ISO9000的其它条款，CMM不是在一个等级就要求做到，而是分布到2、3、4、5个等级中。与此同时，CMM明确了配置管理、产品工程，更加重视SQA的作用。 Q：成功通过了ISO9000后 ，产品质量的提供能力相当于CMM的哪个等级？ A：接近CMM3级。但这种接近的前提是，制定的质量管理体系一定要有丰富的软件工程专家给予指导。 Q：如果打算同时实施ISO9000和CMM2级或3级，而且希望让大家只填写一套文档，而不是两套材料，应该怎么做？ A：在文件体系结构上保持一致，在过程定义上可以统一，而在记录模板方面可以由两者构成一个大的集合。

CMM2级实施技术问题分析

对大多数国内软件企业来说，CMM的实施还处于起步阶段，准备实施CMM2级的企业占绝大多数，因此，分析CMM2级实施过程中的问题，将有助于这些企业尽快找到适合本企业的实施方式。 一些正在实施CMM2级的企业发现有大量的重复性工作要做，原因何在？没有做好需求开发是产生这一问题的主要原因！ 1. 需求管理与需求工程 需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点： 缺乏良好的需求规格说明编写模板 分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。 缺乏良好的需求规格说明编写模板 分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。 比较严重地忽略了非功能性需求 目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。 如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。 缺乏对需求文档的配置管理 采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。 需求规格说明缺乏可测性 在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。 缺乏较好的需求规格说明转化规范 需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。 需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得的好坏，对需求管理实施的工作量有很大影响。 2. 配置管理与工作产品的转化 软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。 配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，较好的可转化性摻虾玫目勺詳是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点： 需求规格说明书编写不好或不全； 工作产品模板定义不好； 工作产品之间转化缺乏规范定义。 3. 项目计划与数据收集和分析 项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他其它资源计划。在其他它关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。 一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。 4. 质量保证与实践反馈 实践反馈是质量保证体系得以有效运作的驱动力，企业应该为所有项目建立一条从SQA到项目经理以及更高层经理的反馈渠道。实践反馈是SQA组与高层经理相互沟通的过程，SQA组定期向高层经理汇报SQA的活动，并及时与项目组沟通，使项目组能尽早改进工作；当沟通不畅、发现项目组运作不力或发现组间协调困难时，应及时报告高层经理，通过高层经理的协调及时进行修正。 有些项目经理认为自己心里有一套计划，只要按计划进行就可以按时保质完成项目，但事实并非如此，在项目组之间的协调问题上，高层经理的作用是非常明显的。如果仅仅为满足CMM的要求而虚设高层经理，这种做法是不可取的，因为如此一来，实践反馈是不完全的。 SQA组在CMM实践中犹如一个司法机构，但这还不够，它还应该为改进过程管理提供资源。SQA组不一定完全由专职人员组成，也可调配一些擅长软件开发方法和软件过程管理的人员参与主要的SQA活动。 5 .同行评审 从理论上讲，同行评审这个关键域的实施并不难，但实际上大多数企业都掌握得不够好，主要表现在以下方面： 评审时组间争论过多或过少 这一问题在不同企业的表现也不同。调查表明，争论较多的情况是工作产品的输入/输出不清楚，组间缺乏沟通的公共平台，因此组间只有通过较多的讨论甚至争论才能弄清其他组的需求。遗憾的是，事后大家并没有坐下来认真讨论如何改进原工作产品的模板形式或表现形式，因而也就无法从根本上解决问题。另一种较极端的情况是，评审一个组的工作产品时，其他组很少发表意见，尽管有些问题是十分明显的。通过调研发现，这实际上是企业文化的问题。一种普遍的想法是“等我们实际做的时侯自然就清楚了”，但实际情况往往事与愿违，这使企业的工作效率大打折扣，但又不易被管理层意识到。无论是哪种情况，最终的原因是：“项目甚至企业缺乏持续改进过程管理的意识。” 缺乏心理训练 做好同行评审的最大挑战是克服心理障碍。简单地说，同行评审就是被别人挑错或挑别人的错。因此，评审会就像是答辩会，必须做好充分的准备。当角色互换，自己成了挑错方时，则应该把被评审的工作产品看成是自己在较早前完成的，现在再做一次修改，且修改完成后，自己要拿它去参加评审答辩。经历几次这种心理角色换位，就会逐渐适应。如果大家都这么做，同行评审就会形成良好的氛围，这对形成健康的企业文化将起促进作用。 竞争与合作意识不充分 从另一个角度看，同行评审又是竞争与合作的最佳表现场所和形式，凡在这种场合讲话有理且意见中肯的人逐渐会成为团队的核心人物。在这种竞争的环境中，合作是基础，同行评审的目的就是在合作的前提下尽早且有效地排除工作产品中的缺陷。把握好竞争与合作的尺度，将有益于企业文化的发展，否则有可能出现恶性循环。如何把握呢？从大量的案例看，多数消化少数是较好的方法，因为文化是不可创造的。 考虑不全面 同行评审存在的另一个问题是评审时仅注意工作产品内容本身，大家面对面地弄清内容后，却忽略了如何改进工作产品的表现形式，使新表现形式下的工作产品可更好地用书面形式表示，进而可减少面对面沟通的需求。当然，面对面的沟通并不是不好，但如果一个工作产品需要太多的口头表达才能被理解，则原因只有两个：书写不清楚或模板定义不好，如果是后者则情况更糟。 6. 缺陷预防与度量 缺陷预防的目的是为了识别产生缺陷的原因并防止其再次发生。一些实施低级别CMM的企业通常都采用一些度量（metrics）来预防缺陷，包括软件大小、软件设计错误、编码错误、测试错误、设计评审覆盖、编码评审覆盖、产生测试覆盖、与过程原因相关的缺陷、与项目原因相关的缺陷等。 个别企业选用了一些难度更大的度量。大多数情况下，这些企业并非要达到更高级别的CMM，而是从产品需求的特性出发，对工作产品进行缺陷分析和预防。其过程通常是：获取数据、数据整理、度量、发现原因并确定过程的改进措施，其典型例子包括设计复杂性与测试覆盖及测试深度、模块复杂性与测试覆盖及测试深度等。这类企业的软件产品一般具有以下特点：软件产品规模较大，通常在软件产品交付给用户后，通过相当长时间的不断维护，稳定性才能达到满意程度。如果在早期对可能产生较多错误的软件模块进行识别，加强对这些模块的早期关注和测试，就可较早地使系统达到稳定。这种方法常常用在大型软件开发中，但真正用好的并不多，主要原因有以下几点： 忽略了使用度量的环境 大多数工作产品的度量都是为某一种特定的设计方法或编程语言设计的，忽略了这个因素，度量就容易失去准确性。此外，软件产品不同的行业特性往往也是造成度量产生偏差的原因。 忽略了对度量参数的修改 一些度量参数是在原来的实践环境下确定的，当在新环境下使用时，其中的参数很可能需要进行修改，才能使度量的准确性得到保证。 忽略了对相关性的研究 使用的度量与缺陷在本地的相关性越高，度量的价值就越大。获取这种相关性的方法一般是对本地的历史数据进行相关性研究，企业只有在确认满意的相关性后才可将度量用于缺陷预防。

怎样进行软件过程改进

有人认为，如果一个软件机构在五个开发人员以下，以及开发周期短于六个月，进行基于SW-CMM的软件过程改进是不划算的。写这篇文章的一个目的，就是帮助人力财力不那么雄厚的中小型企业进行软件过程改进，让他们能少花钱，少花时间，并且显著得益。无论人数多少，开发周期多短，改进必得益！ 　　笔者在“SW-CMM与中国”一文中己提出了对在中国软件产业中应用CMM的一些建议。 　　只要一个软件企业在开发产品，它就一定有一个软件过程（可能只是没有写下来）。如果这个过程不能很好地适应开发工作的要求，就需要进行软件过程改进。 　 　　软件过程改进并不是一件很困难的事。并没有写一个操作系统，或设计一个微处理器那样的纯技术上的难度。但它面对的是一种含有大量管理成分的工程技术。这也就是为什么不容易把它做好的原因。 　　什么是“改进”？改进所涉及的几个步骤是： 　 　 1.把要想达到的状态与目前的状态作比较，找出所有差距； 　 2.决定要改变哪一些（注意，不一定是全部）差距，要改变到什么程度（可分阶段改）； 　 3.制定具体的行动计划； 　 4.执行计划，同时在执行过程中对行动计划按情况进行调整（以最佳效果为目标）； 　 5.总结这一轮改进的经验，开始下一轮改进。 　　下面讨论，在进行软件过程改进时，上述五个步骤中的关键内容。 　 “要想达到的状态”（目标状态）：具体是指软件过程的状态。如果一个机构决定采用SW-CMM来作参考篮本的话，就可以基于它的各个关键过程域（KPA ），制定出符合自己机构及产品特点的目标状态。（在这里，笔者强调“基于”及“符合自己特点”，意思就是不能照抄。） 　 “目前的状态”：要找出什么是目前的状态，就.要进行对目前软件过程的评估。评估的方法很多，最简单的就是一组熟悉本机构的日常开发运作的人员在一起讨论，把它列出来。在这里，可借助SW-CMM的评估问卷办法。实质上，评估问卷中的问题，就是把各关键过程域的各细则内容，加上“有没有做到”、“有没有建立”、“有没有执行”等语句而构成的，并没有什么神秘之处。 　 “决定要改变哪一些差距”：要从多个方面进行考虑决定。例如：“最薄弱的环节”、“最需要改进的环节”，“最易做到而又有显著收效的改进”，“有人力，财力和时间，即有条件进行”。各机构要按自己的情况作决定。 　 “要改变到什么程度”：由于条件的限制，我们不可能做一切希望要做的事，或者不可能百分之百地一步实现目标。许多时候，欲速则不达，反而误了事。目标与能力，要有个平衡。 　 “具体的行动计划”：“具体的”就是： 　　 a. 要有明确的，可以检验的目标； 　　 b. 要定出检验成功与否的标准； 　　 c. 要有具体的实施行动办法； 　　 d. 要指定具体执行计划的人，每人的具体责任与任务； 　　 e. 要指明计划的主要领导或协调者，以负责解决一切在执行中出现的问题； 　　 f. 要列出所采用的新技术与新工具，怎样获得它们； 　　 g. 要定出对新技术和新工具进行对本机构适用性改造的目标； 　　 h. 要有对新技术和新工具的使用进行培训的计划； 　　 i. 要列出每一改进对过程的其他部分的关系、影响、和协调的办法； 　　 j. 要建立与项目相关联的时间表； 　　 k. 要指出相关的人力、资金与时间的来源； 　　 l. 要定出在整个执行过程中，必须在什么时候提供什么数据； 　　 m. 要有对执行情况进行监察考核的具体办法及计划； 　　 n. 要准备很可能发生的，在执行过程中对行动计划按情况进行调整的行动。 　　 o. 要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。 　　 p. 必须要有高层领导、管理人员作为推动整个行动计划的动力。 　 “在执行过程中对行动计划按情况进行调整”：一旦发现需要对行动计划进行调整，以期达到最佳的效果，而实际情况也允许在中途进行调整的话，可以进行经过计划的、严加控制的调整。所有的改变必须预先取得所有有关人员的同意。 　 “总结这一轮改进的经验”：过程改进是一个永不停止的工作。总结经验使我们能越做越好，越做越有信心。光有未经实践的知识，还不能有信心。信心是经过运用知识解决了问题之后建立起来的。 　 SEI 建议的做法： 　　 运用SW-CMM进行软件过程改进，按照SEI 的建议是使用他们制定的IDEAL 模式的做法。 　　 IDEAL 是个组合字，实际代表： 　　 I Initiating（创始）为成功地进行过程改进而打好基础。 　　 D Diagnosing（诊断）找出相对于你要达到的位置，你现在在何处。 　　 E Establishing（建立）计划你如何达到你的目的地。 　　 A Acting（行动）按计划进行工作。 　　 L Learning （学习）从经验中学习和改进你在将来采用新技术的能力。 　　读者可详细学习SEI 的出版物：（编号 SEI-96-HB-001，共263 页，可从SEI 网页上找到） 　　 “软件过程改进用户指南”（IDEAL：A User`s Guide for Software Process Improvement ） 　　笔者认为，正规地使用IDEAL 模式，可能比较适合于大型企业。 　　下面，就一些问题提出笔者的看法： 　　 是否一定需要外来的咨询？ 　　企业进行软件过程改进，是否一定需要外来的咨询呢？笔者认为，好的咨询确实能带来帮助，如果财力上付得起，同时又了解对方是有商业道德和有能力的顾问，则不妨进行一点初步的接触，然后逐步判断他的观点和建议是否符合你们机构的需要，千万不要被对方说服去投入一个你们的机构现在不需要的，或在人力、财力、时间上条件不具备的努力。（咨询服务也是一种商品。不道德的商人会向你推销你并不需要的商品。）你们要进一步判断，究竟在哪一些方面，在多大的程度上需要多少外来的帮助，因为过程改进的一个目的是培养本机构的人才，过份地依赖外来咨询，会削弱这个努力。 　　俗语说得好“三个臭皮匠，顶个诸葛亮”。在机构内部组织一个小组，多讨论，通过各种渠道多学习别人的经验，破除教条迷信，灵活运用自己的专业判断力，就有能力领导整个过程改进，并且在实践中成长起来。（至于运用专业判断力，实际上更多时候是运用常识。一种讲法，无论来自什么权威，如果你觉得不合常理的话，就要弄清究竟。） 　 知道了要做什么，如何知道怎样做？ 　　 SW-CMM只提出了要做些什么（关键过程域中的关键实践），但并没有介绍要怎样做。解决这个问题的方法很多，比如到软件工程的书中去找、向有经验的人请教、或者就自己讨论出一个可行的办法，从来都不要小看自己经过认真思考而想出来的办法。凡是从书中或别人处学得的办法，都要经过适当的改变，以适应自己的机构的条件及目前项目的特点。世界上没有适合一切人穿的鞋。 　　 怎样知道过程改进带来了什么效果呢？ 　　一般来说，你知道了目前的缺点是什么，就应当知道怎样去判断过程改进的效果。当然，效果可以分别从质和量的角度去量度。对于不同的改进，效果的检验方法就不同，比如对于项目的计划中的软件规模大小的估算，就可以从最终产品的大小中得知估算的准确度；比如进行早期缺陷预防，就可以看看在开发的各个阶段所发现的缺陷数目的分布（记得在行动计划中要有记录统计的一项）；又比如进行软件配置的版本控制改进，就可以看看是否对不同的版本有了完全及方便的控制。因此，可以看出，这些都是按常理进行的事。 　　 找差距时，应对照哪些关键过程域？ 　　 SW-CMM的能力成熟度分等级，是人为的。它是基于SEI 对成熟度的由底到高的理解来划分的。有人就觉得划分得不大合理，然而，使用者是活着的人，可以按自己需要作改变。 　　笔者认为，对于初开始软件过程改进的机构，不妨对照全部或部分的SW-CMM第二级的各个关键过程域，外加第三级的“交换审核”，及第五级的“缺陷预防”。（有点象从菜单上点菜） 　　为什么要把“交换审核”及“缺陷预防”从高的成熟度等级中“往下拉”呢？原因是，按笔者的实际经验，“交换审核”是一个简单易行而且非常有效的找出缺陷的方法，也是一种促进开发人员注重预防缺陷的好方法。至于“缺陷预防”，这是整个软件过程的核心与灵魂，从一开始就必须全力以赴。 　　 在每个对照的关键过程域中，原原本本地对照每一项关键实践吗？ 　　绝对不是。这里就牵涉到对SW-CMM进行裁剪及解释的间题。“裁剪”是指对范围及程度的改变；“解释”是指把实际软件项目中的实践工作，解释理解为（等同为）某个关键实践。基本上，不要去裁剪那些属于目标（Goals ）的关键实践。裁剪及解释，是中小企业能否成功地应用SW-CMM的一个关键。在不影响效果的前提下，剪裁到越简单越好。要慢慢地把自己培养成裁剪高手。 　　（SEI 有专门讨论裁剪（Tailoring ）的技术报告，文件编号是94-TR-024 。） 　　 把机构目前的一切推倒，按SW-CMM重建，是否会更好？ 　　千万不要这样做。基于目前的过程进行改进，证明是最有成效的方法。 　　 是否起码要满足SW-CMM第二级的所有关键过程域呢？ 　　笔者认为不必。任何方面，任何程度的改进都是有益的。要按照你机构的担负能力及要求来决定进行软件过程改进的广度与深度。 　　 软件过程改进中，应注意些什么呢？ 　　应该注意的事情很多，但笔者认为最重要的一点是要注重执行、做实事，千万不要定出了行动计划之后就丢进抽屉中，束之高阁。另外一个要注意的问题是，要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。

持续改进——CMM的精髓

CMM（Capability Maturity Model for Software，软件过程能力成熟度模型）的基本思想是基于已有60多年历史的产品质量原理。但Philip Crosby将质量原理转变为能力成熟度框架，他在著作《Quality is Free》中提出了“质量管理成熟度网络”，描绘了进行质量实践时的5个进化阶段。随后，IBM公司的Rom Radice及其同事在Watts Humphrey指导下对该框架进行了改进以适应软件过程的需要。1986年，Watts Humphrey将此成熟框架带到了SEI并增加了成熟度等级的概念，后来又将这些原理应用于软件开发，发展成为软件过程能力成熟度框架，形成了当前软件产业界正在使用的CMM框架。 CMM与“持续改进” 企业最终目的是把自己的产品或服务提供给客户，让客户满意，所以只有尽力使这个过程不断反复且能够不断壮大，才能源源不断地创造利润。因此，我们应该明白以下几点： ● 企业的使命是为客户创造价值，因而只有努力地为客户创造价值,企业才能获得成功。 ● 能为客户带来价值的是企业的各种作业，而作业是由一系列能为客户创造价值的活动组成，每项活动都由员工完成。但是,各种活动本身对客户毫无意义，客户关心的是这些活动的结果。因此，出于对客户利益的考虑，作业的构造要努力做到“复杂其中，简便其表”。 ● 优质的产品或服务、杰出的人才和优秀的战略对企业来说必不可少，但并不能保证企业的成功，因为产品或服务、人才和战略只有存在于能为客户带来价值的各种作业之中，才能对企业的成功有所贡献。 ● 优异的作业绩效是通过科学的作业设计、适当的人员配置和良好的工作环境的共同作用实现的。科学的作业设计能够快速应对客户的需求变化;适当的人员组合能获得集体智慧和战斗力;良好的环境则能激发员工的工作热情，促使员工不断超越自我。 由上面四点可以看出，软件企业的成功来自优异的软件开发过程，而优异的软件开发过程需要按以上要求进行管理。因此，我们可以认为，CMM模型实质上是一种新兴的管理思想和方法，它蕴涵了当今欧美和日本日趋盛行的“持续改进（Continuos Improvement）”管理思想。 “持续改进”的含义是：以超前的视野预见过程实施中可能遇到的要素（包括特定的设计、作业方式以及与之相关联的成本要素），并借助先期规范制约的各种手段进行预期调整，同时结合相应的效果计量和评估方法，确保实际过程以预期的低成本运作。着眼于软件过程的CMM模型是持续改进的表现，模型中蕴涵的思想就是防止项目失败的思想，也就是我们所说的“持续改进”。 如何改进？ 虽然软件工程师和管理人员通常都非常详尽地知道问题的症结，但是，究竟哪些改进是当前最需要的？他们可能各有看法。另一方面，如果缺乏既定的改进策略，管理人员和软件工程师们在首先采取哪些改进措施的问题上将很难达成一致。人们经过深入的调查和研究，终于认识到，软件过程的改进不可能一朝一夕就获得成功，而是需要持续不断地进行改进。软件过程改进是在一系列微小、不断发展的过程而不是革命性的创新步骤中实现的。这正是持续改进思想的体现。 为什么要进行持续改进？因为当同类事物之间存在着微小的差异时就会产生变异。当一个过程或系统的资源存在着变异时，相应的系统输出也会有变异。例如，当原材料或所制造的部件质量有偏差时，最终产品的质量也会发生变化。正所谓“进废品，出废品”。所以，研究持续改进，就需要关注系统所使用资源的变异性以及所采用生产过程的变异性。 一般来说，任何系统都会表现出变异性，虽然这种变异并不一定意味着系统不稳定、质量低劣或成本偏高，但是太多或反常的变异则表明系统不稳定——其输出的质量是不一致或不可预知的。对任何一家公司来说，这种现象都是一种危险的信号，因为不稳定的质量将会影响客户的满意度。要保持客户的满意，必须改进产品质量、降低产品的成本、增强产品的营销水平；而要改进质量、降低成本、增强营销水平，又必须减少系统的变异。研究持续改进过程就是明确系统中的变异在哪里发生以及为什么发生。一旦了解到引起变异的原因，就可以寻找一些方法去减少这种变异，以稳定企业的运行过程，使企业得到持续发展。 通常，进行持续改进需要遵循以下步骤： 1．持续改进循环 如果只解决一个小问题或稍微改变一下具体过程，而后就置之不理直到问题出现，这是远远不够的。正如“持续改进”这一名称所暗示的：必须不断地进行改进。持续改进意味着时常对系统进行分析，一丝不苟地收集数据并加以研究；一丝不苟地测试偏差，每位公司员工都把持续改进作为其工作的一部分看待。持续改进应该被视为一个循环，参与持续改进的各团队需要长期连续地在这个循环中活动。也就是说，当一个问题看来已经解决时，员工的参与也不能终止，还有新的改进要实施、新的系统要分析、新的创意需要研究。整个持续改进循环如下图所示。 2．强化过程改进 接下来的步骤是使实施的变革成为系统的一个标准组成部分。团队应该制定出一份简单报告，说明测试过程中的新规则以及所做改进对系统的影响。报告要列出变革后的优点，包括新系统的实施和维护计划，以确定新系统是否能达到新的绩效水平。如果团队的建议被管理者接受并付诸实施，则团队需要按照计划监视系统的运作。 3．持续改进循环 当你确信新的过程得到强化并成为工作过程的一个自然组成部分后，就要准备开始下一个持续改进循环。你应该从分析系统开始，因为上一循环的变革可能已经改变。 4．总结经验 企业的生存取决于它是否具有给客户提供良好服务的能力，并且应该超越同行业的其他企业。通过更快地响应客户需求、提供更高质量的服务，企业就能够持续地生存下去。一旦企业进入持续改进循环，就将拥有更好的信息、更新鲜的创意、更好的过程和质量控制，企业将达到梦想的“意想不到的高水平绩效”。 结束语 “持续改进”这一新兴的管理思想和方法目前在国内基本上还没有专门的研究和应用，但在国外，自20世纪90年代以来，已经有许多学者开始深入地研究它，特别是哈佛大学的青年学者Cooper和Kaplan对“持续改进”进行了系统的研究和完善。事实上，“持续改进”与JIT(just-in-time)、企业再造（business re-engineer）和目标成本管理等管理思想类似，强调用数据或函数来衡量和监测企业的整个过程，让企业的管理者清澈见底地知道企业的业务运作过程，从而有效地管理企业。 尽管CMM模型纯粹来自软件工程领域，并为软件机构服务，但CMM模型所体现的思想实际上就是“持续改进”。例如，CMM模型中的最高级——优化级，就是要求要清楚地看到软件过程、连续不断地改进过程，并定量地跟踪变化所带来的影响和效果。因此，如果我们能超越CMM模型，不仅仅把CMM模型看成是为软件工程服务，那么我们就可以把CMM模型的思想运用到软件机构的供应、生产、销售等其他非研发过程中去。

理解CMM需要注意以下问题

1.它仅指明该做什么，而没有指明如何做，它不是方法论，但我们在学习CMM时，可以从中学到分析问题的方法。 　　2.它仅指明该做的关键内容，仅描述软件过程的本质属性，而并非面面俱到。抓问题的主要方面的思想贯穿在整个CMM模型中。 　　3.软件过程是指软件工程过程、软件管理过程和软件组织的过程三者的有机结合。软件工程过程是我们理解的常规的软件的需求分析、设计、编码、测试等过程;软件管理过程是指为使软件工程过程顺利进行而实施的管理活动的集合。上述两个过程是以软件工程组为主的活动。软件组织的过程是企业级的对软件的组织活动,是以企业为主的活动。 　　4.它是从软件过程的角度考虑问题，而并非关注软件开发工具,与框架软件生存周期无关，也与所采用的开发技术无关。 　　5.CMM为改善整个企业的软件过程提供了指南，而并非针对某个具体项目。CMM并不能保证在这个过程框架下，产品开发百分之百的成功。产品的成功是多种因素的组合，例如市场等因素。 　　6.CMM1.1是针对大型软件企业(500人以上)的，对小型的软件企业(50人以下)需要裁减。 　　7.CMM认为过程的不断改进基于许多小的、步骤的进化而不是革命性的创新。　 　　8.基于CMM的过程改善投资力度大、周期长，而技术投资则可能在短期内有较快回报。单独依靠技术改进可能在短期内取得较快回报，但最终可能一无所获。

CMM简介

CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应 商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。据了解，美国、印度、日本等国家已有数十家公司通过了CMM不同等级的认证。 　　1986年11月，SEI应美国联邦政府的要求，在Mitre公司的协助下，于1987年9月开发了一套软件能力成熟度框架和一套软件成熟度问卷，用来评估软件供应商的能力。这就是最早用于探索软件过程成熟度的一个工具。 　　四年以后，也就是1991年，SEI自己总结了CMM成熟度框架和初版成熟度问卷的实践经验，并以此为基础推出民用CMM1.0版。 　　CMM1.0版合用两年之后，1992年4月，SEI举行了CMM一个的研讨会，参加研讨会的有大约200名富有经验的软件专家。SEI在广泛听取他们的意见之后，又于1993年推出 CMM1.1版。这也是目前世界上比较流行和通用的CMM版本。 　　十几年来，此项工作一直在不断进行。按照SEI原来的计划，CMM的改进版本2.0应该在1997年11月完成，然后在取得版本2.0得实践反馈意见之后，在1999年完成准CMM2.0版本。但是，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫得项目CMMI。 　　CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。 　　随着人们对CMM研究的不断深入，其他学科也结合本系统的特点，陆续推出了自己的CMM模型。例如，人力资源能力成熟度模型、系统工程能力成熟度模型等等。为了以示区别，国内外很多资料把CMM叫做SW-CMM。 　　软件过程成熟度的提高是一个渐进的过程，需要一个长远的、可持续发展的过程作为保证。为建立一个面向过程持续提高的基础和文化，有些软件企业可能要花费很大的精力和时间。但是这种努力对任何一个软件企业来说都是非常必要的。 　　CMM目前代表着软件发展的一种思路，一种提高软件过程能力的途径。尽管它存在着某些不足。例如，成熟级别、关键过程域、公共属性和关键实践还需要在软件行业进一步深入地讨论和修订，但它确实为软件行业的发展提供了一个良好的框架，而且是浓度软件过程能力提高的有用工具。 　　增强我国软件企业的竞争力，提高国产软件的水平是国人的共同愿望，但目前我国软件水平，尤其是软件开发能力和软件生产能力还很差，这也是不争的事实。那么，如何提高我国软件的开发和生产能力，从而提高软件整体水平？软件企业实施CMM也许不失为一条有效的途径。 　　一个企业的软件能力更取决于该企业的过程能力，特别是在软件开发和生产中的成熟度。其过程能力越是成熟，该企业的软件生产能力 就越有保证。目前，我国已有一些软件企业正在尝试实施CMM。 　　当然，CMM不是万能的，并不一定对所有的软件企业都适合，实施CMM的企业也有失败的例子。我们希望通过本专栏能使更多的企业了解CMM，尽快找到适合本企业的发展之路，从而提高中国软件企业的竞争力。

CMM应用

基于CMM成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施CMM的标准成为人们关注的重点。CMM的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，（如编码，操作系统等等），也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。 　　由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问题，将其作为过程实施开端的要领加以掌握： 　　1．不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以CMM工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。 　　 2．必须懂得CMM作为一套标准，它指明的是该作什么（What）而非怎样去做（How），同时CMM也代表了一种对软件生产过程进行理解和分析的独到观点（Philosophy）。CMM着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发100%成功，CMM所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。 　　 3．CMM1.1版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于20人以下的小型企业，1.1版中的一些环节可能并不适用。 　　 4．企业在采纳CMM过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。 　　 5．"知己知彼，百战不殆"。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域（KPA）。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。 　　 6．如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括： 　　 <1>目标明确并可检验,有助于切实的检验标准； 　　 <2>有详细的实施步骤,有专人负责每一环节的落实,有协调方解决各环节之间的冲突； 　　 <3>如需采纳新技术和工具，应详细分析他们的作用及获取方式并准备对新技术和工具进 行改造，对员工进行培训以适应项目所需。 　　 <4>制定项目开发时间表，将每个过程环节的实施与此时间表挂钩。 　　 <5>对项目开发的投入工期进行预测并据此规划开发工作。 　　 <6>预先规划开发过程中相关数据的采集，分析和提供方式与时段； 　　 <7>所有过程，包括：需求分析、项目计划、项目验收和交付，都必须编档并保留，应有具体的监控和考核计划来监督过程的实施。这一计划应考虑到偏差的可能性及应对方案。 　　 <8>企业的高层和相关管理人员应参与过程的制定与实施并形成制度。领导层应负责对每一阶段改进的总结并制定出相应的后继方案，另外，凡涉及对已定计划和过程的调整必须事先申请备案并经领导层同意。 　　 <9>需强调的最重要的一条原则是，过程改进不可流于书面形式，所有员工都应理解并参与其中。 　　CMM模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施CMM的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。 　　作为一种模型，CMM实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。 　　目前，世界范围内已采纳CMM标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳CMM体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。 　　卡莱基·梅隆大学软件研究所提出了一套实施CMM标准的方法，按照他们的建议，IDEAL是企业开始引入CMM体系的良好参照模式，它包括： 　　 I--启动（Initiating）,表示开发机构应为CMM的引入准备好前期基础设施和程序。 　　 D--诊断（Diagnosing）,明确机构目前所处的能力水平及目标等级所在。 　　 E--建构（Establishing）,制定如何实现目标等级的计划。 　　 A--行动（Acting）,具体实施该计划。 　　 L--学习（Learning）,积累以往经验并将其用于持续的改进过程之中，同时注意新技术和工具的引入以协助过程实施。 　　如有可能，企业在咨询机构或咨询师的协助下可以加快CMM体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成CMM研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施CMM的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。CMM体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。 　　根据SEI的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则： 　　 a,将软件生命周期划分为若干阶段并进行严格的计划，包括项目计划，里程碑计划，质量检测计划，维护计划等。 　　 b,在开发过程中，分阶段进行复审和评估，以便尽早发现错误所在。 　　 c,项目组成员应注重包括技术和流程在内的培训，提高人员素质。 　　 d,软件过程的改进应是持续性的，不断调整的进程。 　　 e,尽可能采用度量数据来描述过程中的每一环节，从而提高可预测性和可控制性。 　　 f,对以往所有开发工作必须进行文档工作，积累经验以用于未来的开发之中。 　　 g,如果项目允许，尽可能采纳较为先进的技术与工具，例如，面向对象的编程方式(OOP)

软件企业如何实施CMM

国内的绝大部分软件企业目前处于CMM的初级阶段，没有基础和经验。虽然CMM的主要思想很清楚，标准的条例也很明确，但如何达到这种标准的可操作性比较差。所以许多企业在实施CMM的过程中，往往感到迷茫，不知从何处下手。本文讨论软件企业实施CMM或通过CMM评估所必须经历的步骤，希望能起到一个抛砖引玉的作用，软件企业实际实施CMM时，可以根据自身的实际情况和具体要求加以应用。 提高思想认识 　　CMM在中国的实施，从整体上看处于起步阶段，很多软件公司对ＩＳＯ９０００了解较多，也有较多通过了ＩＳＯ９０００认证。相对而言，了解CMM的就不多了。具备一定规模的软件企业，对CMM非常感兴趣并表示了极大的关注，有部分公司也在积极实施CMM，但正式推行CMM需要在人力和经费上增加投入，一般的软件中小企业有一定困难。 　　根据全球软件销售额数字分析，今后几年软件和信息服务的市场规模将有一个巨大的发展。然而中国这样的一个大国，软件销售额还不到世界市场的０．５％。我国软件企业除少数几家在５００人以上外，多数是在５０人以下的民营、集体和个人的软件公司。以开发技术和规范化程序来衡量，总体上仍是相当落后的，大多数企业仍为手工作坊式制作，产品缺乏市场竞争力。因此，软件过程管理已成为发展我们软件产业的一个关键性问题。实施CMM对软件企业的发展起着至关重要的作用，CMM过程本身就是对软件企业发展历程的一个完整而准确的描述，企业通过实施CMM，可以更好地规范软件生产和管理流程，使企业组织规范化。而且，只有在国际市场取得成功的产品和企业才具有长久的竞争力和生命力，由于CMM已获得国际企业和用户的广泛认可，因此必须在软件企业实施CMM。 进行CMM培训和咨询工作 　　任何一个软件企业要想实施一先进的管理措施，首先应该做的就是理论基础的建设，作为一个过程式管理方法的CMM，同样也不例外。 　　根据CMM模型的要求，一个项目的开发一定要有章可循，而且要做到有章必循，这两点都离不开培训。培训的内容主要有两个方面，第一，对所有员工包括经理在内的最基本的软件工程和CMM培训知识；第二，对各个工作组的有关人员提供专业领域知识等方面的培训；此外，在每次开发过程中，还要对普通人员进行软件过程方面的培训。 　　培训的方式有很多，第一，向有关专业培训咨询机构进行咨询。这些培训公司为CMM知识的导入起着主导作用，他们来源于各种背景，有国家有关研究所、相关协会、大学、原ＩＳＯ９０００咨询公司、新创办的CMM咨询公司、实施过CMM的企业等，但这些培训咨询公司主要集中在北京、上海，尤其是北京。所以也希望其他省市，特别是被批准为“国家软件基地”的城市，应加大力度，竭力扶植有关咨询培训机构。第二，利用互联网资源进行咨询和培训。可以报名参加CMM网校等网站进行系统的学习。第三，聘请有关CMM专家到企业实地指导CMM的实施。企业可在被指导过程中逐步掌握CMM的要领和实施过程。值得注意的是，企业最开始阶段必须聘请一位经验丰富的CMM专家，但以后一定要培养自己的专家，这样不仅能节约开支，还能使企业自己具有一个对CMM深刻理解的、有实践经验的专家，为企业今后的继续升级打下一个良好的基础。 确定合理的目标 　　CMM模型划分为５个级别，共计１８个关键过程域，５２个目标，３００多个关键实践。每一个CMM等级的评估周期（从准备到完成）约需１２－３０个月。无论一个软件企业的软件过程处于什么样的水平，都可以在CMM框架的５个级别中找到自己的位置。然后有针对性采取与自己所处级别相适应的措施，使企业能纳入CMM的进化阶段，使软件过程管理早日得到改善。 　　因此，要实施CMM，首先应该对本企业的现状有一个准确的评估。企业目前处于什么水平，企业发展的问题是什么，借助CMM要达到的目的是什么。然后再结合企业的实际情况选择CMM的切入点，确定总体目标。这个目标包括在多长时间之内，需要投入多少人力、物力和财力，要达到哪一级。在总体目标已经确定的前提下，还要制订近期目标和长期目标。 成立工作组 　　企业针对CMM的实施，应成立专门的CMM实施领导小组或专门的机构。领导层必须真正学习理解软件过程管理和改进的重要性，亲自领导和参与，要保证过程管理的人员配备，抽调企业中有管理能力、组织能力和软件开发能力的骨干人员。 　　在CMM的实施过程中，工作组的成立是CMM的一个关键步骤。有几个重要的组织是必不可少的，这些组织包括软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。 　　在CMM的实施中组织机构的设置必须完善，但不等于说每一个机构必须是独立的。有些组织很小时，机构可以适当合并，成员可以身兼数职。但对那些关键实践要求独立性时，组织必须十分小心。例如，软件质量保证组的独立性就是必须考虑的，否则在技术上或机构上出现的偏差，会无目的地影响到软件过程、项目质量和风险决策的正确性。 　　在这里还要提到一点，那就是物理组和逻辑组。在CMM中有两种组织，一种叫物理组织，它是客观存在的，例如项目组、技术部等，有众多专职人员；另一种叫逻辑组织，就是说它的人员可以是兼职的，很多逻辑组只需一两个人就可以了。 制定和完善软件过程 　　CMM模型强调软件过程的改进，如果企业还没有一个文档形式的软件过程，则首要任务是对当前的工作流程进行分析、整理及文档化，从而制定出一个具有本企业风格的软件过程，并用该文档化的过程指导软件项目的开发。如果已经具备了软件过程，则要对这个过程做内部评估，对照CMM的要求，找出问题，然后对这个过程进行补充修改。在具体实施的过程中，可以选择有一定代表性和完善性的项目组或项目进行试点，跟踪、监督改进后的软件过程的实施情况，执行改进活动的状态。 　　同时，过程小组的成员还应该维护过程中的数据库，定期统计各个过程中的产品和规模、开发周期、修改次数及评估周期。这些数据库可用来分析项目的效率以及存在的问题，以便今后进一步的改进，同时还可以为项目开发实事求是过程提供咨询。 　　总结这些项目组或项目以前成功的经验，从中规划出一个具有实际意义的软件过程，按照CMM规范评估这个过程，找出其中的优缺点。对不满足CMM要求的地方加以完善，使其成为一个完美的实施CMM的软件过程方案；然后将这个软件过程应用到当前正在承接的或即将承接的项目上，在实际使用过程中进一步发现其中的不足和错误之处，加以改进，最后将试点的结果推广到整个企业。 内部评审 　　由于我国在CMM评估中要聘请外籍主任评估师，费用较高。据估计，要通过一个级别的CMM评估，费用是通过ＩＳＯ９０００认证的十多倍。因此，建议软件企业在进行正式评估之前，先进行内部评审或评估。这种内部评审包含两层含义。第一种就是软件企业组织自己内部成员，严格、认真地按照CMM规范评估过程，对自己的软件过程进行评审，找出其中的不足点并进行改进。第二种含义就是在全国范围内，由有关软件工程和CMM专家组成一个专门的“内部评审”机构，负责指导协调实施CMM的活动，推进活动的深入开展，对国内软件企业CMM评估进行“预先评估”。这种预先评估，可降低软件企业通过正式CMM评估的风险，减少软件企业实施CMM的成本，为企业最终获得国际CMM认证打下基础。 正式评估 　　目前主要有两种基于CMM的评估方法，一种是ＣＢＡ－ＳＣＥ（ＣＭＭ－Ｂａｓｅｄ Ａｐｐｒａｉｓａｌ ｆｏｒ Ｓｏｆｔｗａｒｅ Ｃａｐａｂｉｌｉｔｙ Ｅｓｔｉｍａｔｉｏｎ），它是基于CMM对组织的软件能力进行评估，是由组织外部的评估小组对该组织的软件能力进行的评估。另一种是ＣＢＡ－ＩＰＩ（ＣＭＭ－Ｂａｓｅｄ Ａｐｐｒａｉｓａｌ ｆｏｒ Ｉｎｔｅｒｎａｌ Ｐｒｏｃｅｓｓ Ｉｍｐｒｏｖｅｍｅｎｔ），它是基于CMM对内部的过程改进进行的评估，是由组织内部的小组对软件组织本身进行评估以改进质量，结果归组织所有，目的是引导组织不断改进质量。这两种评估均由ＣＭＵ／ＳＥＩ授权的主任评估师领导，参考ＣＭＭ框架来进行，都要审查正在使用和将来使用的文件／文档，并对不同的组织员工进行采访。ＳＥＣ与ＩＰＩ两评估结果应该一致，评估结果的所有资料都将呈报ＣＭＵ／ＳＥＩ。 　　针对企业实施CMM的需要，这里主要讲述ＣＢＡ－ＩＰＩ的评估方式，以便企业为提高软件过程进行内部评审。ＣＢＡ－ＩＰＩ的评估由几方共同组成：评估小组、公司的管理人员、具体项目的执行人员以及主任评估师。其中评估小组是由经验丰富的软件专业人员组成，还要经过ＣＭＭ和ＣＢＡ评估的培训，使他们了解组织的同时，也懂得如何将ＣＭＭ模型及关键实践与组织的要求建立关联。ＣＢＡ评估过程主要分成两个阶段：准备阶段和评估阶段。准备阶段包括小组人员培训、计划以及其它必要的评估准备工作。在评估的最初几天，小组成员的主要任务是采集数据，回答ＳＥＩ的ＣＭＭ提问单，文档审阅以及进行交谈，对整个组织中的应用有一个全面的了解。然后进行数据分析。评估员要对记录进行整理，并检验所观察到的一切信息，然后把这些数据与ＣＭＭ模型进行比较，最后给出一个评估报告。在每个评估报告中，必须针对ＣＭＭ 的每个关键过程域，指出这个软件过程在什么地方已经有效地执行了，什么地方还没有有效地执行。只有所有评估人员一致通过的情况下，这个评估报告才有效。 根据评估结果改进软件过程 　　根据Ｉｄｅａｌ模型，成熟度的评估只是软件过程改进中的一个环节，如果这个环节与软件过程改进的其他环节不能很好地结合，那么，CMM评估对于软件过程改进所应具有的作用就得不到发挥。 　　一般来说，应该在评估之后很快地做出软件过程改进的计划，因为这时大家对评估结果和存在的问题仍有一个深刻的认识。计划在软件过程改进中是一个非常必要的阶段，只有有效的计划，才能确保软件过程得到有效的改进。 　　ＣＢＡ评估方法对衡量软件企业的能力成熟度是一个非常有效的手段，评估结果本身就是一个非常坚实的基础，是制定软件过程改进计划的依据。ＣＢＡ评估客观地指出了企业软件过程存在的问题，帮助企业发现软件过程的不足之处，充分指出了软件过程改进的前景。 结束语 　　因为软件过程成熟度的升级本身就是一个过程，全面引进应用CMM所涉及的范围非常广，要求人力、财力与设备资源的投入相当大。所以在实施CMM时，千万不要一开始就把目标定位过高，不必一下子去满足某一能力成熟度等级的所有目标。而要根据企业自身的情况，试行某些关键过程域的一部分关键实践活动，逐步完善软件过程和成熟度的升级。而且在实施CMM的过程中，应当处理好CMM实施和认证的关系。实施是基础，认证是结果。只有认真扎实的实施，才可能有认证的通过。由于我国大部分软件企业距离CMM的认证有相当大的距离，最好先按照CMM严格的软件工程方法，致力于改进企业的管理，提高软件开发能力，而先不要搞软件能力评鉴，追求认证、评级等。等到能力成熟后，再进行认证。这样可以避免和杜绝华而不实、弄虚作假的现象。应该把实施CMM作为提高软件企业管理水平和提高软件质量的突破口，追求真正的软件能力和水平的提高，而不是把单纯的CMM软件认证作为一个唯一的目标。

商业软件企业如何借鉴CMM管理？

虽然近年来，商业信息化推动了我国商业企业的管理进步，提高了全行业的科技素质，然而，由于种种原因，商业信息化的成功项目所占比例并不太高，一个突 出的问题是软件系统/产品的研发周期长、质量低、成本高、开发进度难以控制、系统修改与维护困难等。 　　实践表明：要低投入、高效率、高质量地开发软件，仅仅依靠运用新的软件开发方法与技术所达到的效果是十分有限的，必须以改进并加强管理软件的生产过程为中心，实施科学的、规范的软件工程管理，才是解决问题的根本所在。关于软件过程的改进和管理，目前国际上以卡内基·梅隆大学软件工程研究所CMU/SEI主持研究开发的软件能力成熟度模型（CMM，the Capability Maturity Model forSoftware）研究得最为深入，虽然目前还不是软件过程改进的工业标准，但用得较广。它为软件工程管理开辟了一条新的途径，能帮助软件企业改进和优化自身的管理，在提高软件开发水平和效率的同时提高产品的质量和可靠性，实现软件生产工程化。 CMM模型是什么 　　如同一个人在某个特定领域的能力是积累起来的一样，一个企业的软件能力也是逐步获得和增长的。如果在其发展过程中能得到一个很好的指南，那么就能不断达到一个个设定的目标，变得越来越成熟；否则可能会盲目发展，离自己的目标越来越远，甚至南辕北辙。CMM正是这样一个指南，它以几十年产品质量概念和软件工业的经验及教训作为基础，为企业的软件能力不断走向成熟提供了有效的步骤和框架。 1、CMM框架 　　CMM侧重于各项管理过程，将质量管理原理应用于软件成熟度框架的建立，指明了改进的目标，提供了循序渐进的步骤。根据软件生产的历史和现状，CMM框架可用5个不断进化的层次来表达，每个层次的主要特征为： （1）初始级是混沌的过程。软件生产过程的特点是杂乱无章，有时甚至混乱，几 乎没有明确定义的步骤，项目软件的成功完全依赖核心人物，而没有相关组织、标准、规程的保证。 （2）可重复级是经过训练的软件过程。建立了基本的项目管理过程来跟踪成本、进度和机能，有必要的过程准则来运用以前同类项目的成功经验。 （3）已定义级是标准一致的软件过程。管理和工程的软件过程已文件化、标准化，并综合成整个软件开发组织的标准软件过程。所有的项目都采用根据实际情况 修改后得到的标准软件过程来发展和维护软件。 （4）已管理级是可预测的软件过程。制定了软件过程和产品质量的详细的度量标准。软件过程和产品的质量都被开发组织的成员所理解和控制。 （5）优化级是能持续改善的软件过程。加强了定量分析，通过来自过程质量反馈和来自新观念、新科技的反馈使过程能持续不断地改进。 　　基于这种级别的划分，既可以标识软件企业的过程能力，又可以方便地、有所遵循地实现持续不断的软件过程改进。因为，每种级别都提供了一个软件过程改进层次，每一个层次是通过实现软件过程中的一些关键过程区域来实现达到软件成熟度结构的。例如，软件企业达到CMM的第二级，则它要实现可重复级的全部关键过程区域，这包括6个关键过程区域：需求管理、软件项目计划、软件项目跟踪和监督、软件子合同管理、软件质量保证和软件配置管理。这样便可真正地推动软件企业的能力提高。 2、基于CMM的软件过程管理 　　CMM模型的成熟度理论主要涉及对软件组织和各类资源的管理，以及对软件工程过程的定义管理和如何度量、管理、改进这些过程，同时还包含对软件工程过程中使用的开发工具和技术的管理。因此，CMM模型实质上是一个管理标准，其软件过程成熟度级别的高低实质上就是管理水平的高低。 　　在工程实践中，可视化是实用化的一种形式，是管理人员和不同人员之间进行交流的最重要手段。在CMM模型中，不同层次表现了不同的过程可见度，层次越高，过程的可见度越强，对过程的控制能力也越强。图1描述了不同成熟度级别下软件项目的可视状况以及不同成熟度级别所能采用的不同管理方式。 （1）初始级的可见度最低，整个软件过程像一个黑箱，处于一种不可控状态。对管理者或用户而言，只能看到项目的需求和项目的结果，无法看到项目的软件过程，无法对软件开发进行监督。管理者和决策者不可能根据开发过程状态及时作出合理决策，项目组经常处于“救火”状态。 （2）可重复级具有阶段可见度，可对软件过程实施阶段控制。开发过程好像一系列的黑盒子，可以按阶段来进行软件开发的控制和管理。但黑盒的内部结构仍不可见。这时已经建立了基本的项目管理活动，并在过程的检查点上对产品进行检查，以考察过程是否正常进行，或对发生的问题作出反应。用户也可在检查点上了解项目的进展。 （3）已定义级具有了企业自己的标准软件过程。其软件过程中任意两个控制点之间的过程内部结构是可见的，每一个管理者和工程师都明确自己的位置和责任以及相互之间的关系，这些内部结构实际上是企业已定义好的标准软件过程在具体项目中的应用。同时，管理者能预见可能发生的风险，并为此做好准备。用户也能得到较为准确而快速的状况报告。 （4）已管理级在已定义的软件过程基础上进行过程量化管理。管理者可以根据客观的度量，预见过程中的经费支出和其他情况，并定量地、有目标地做出决定。用户也能定量地理解过程的能力及存在的风险。 （5）优化级的过程具有动态优化能力和自适应能力，可以很清楚地看到软件过程。为了提高生产率和质量，企业不断尝试新的软件开发方法和技术来优化过程。该层的软件过程不仅具有对存在过程的可见性，而且对过程潜在的改变、影响因素也具有预见性。管理者有能力估计及定量跟踪变化的影响和效果。用户和开发组织合作关系良性发展。 3、基于CMM的软件过程改进 　　任何软件过程必然属于这五个层次中的某一个层次。在不同层次中，需要实现带有不同层次特征的关键过程区域。在致力于软件过程改进时，只能由所处的层次向其紧邻的上一个层次进化，而不能是跳跃式的。并且，改进过程本身也是一个规范的、循环的、永不停止的过程。一个软件企业首先要通过过程评估、能力评估等手段诊断自己处于哪一个层次、还存在什么问题，然后根据诊断结果列出改进计划，经过相关的培训、实施，最后作出总结。一个过程的改善结束紧跟着下一个更高层次过程的开始，从而进入“评估—诊断—计划—培训—实施—总结”的又一循环。CMM模型使过程的改进成为有序。 CMM的应用及其局限 　　CMM可以应用到许多方面，但CMM研究的初衷是实现： ·软件过程评估：用来评估一个软件组织在过程方面的优点和弱点。 ·软件能力评估：用来评估软件开发承包商的开发及管理能力。 　　在CMM的广泛应用中，通过CMM认证的软件企业都不同程度地增强了竞争力，争取到了以前不能得到的合同。例如，Raytheon公司现有近400名软件开发人员，公司用了近五年的时间，将其成熟度从第一级提升到第三级，已经收到了明显的效果。在提升到较高级别的过程中，公司所花费的投资与五年来因成本降低所收到的效益之比为1：8，直接生产效率提高了大约14倍。该公司所开发的产品在成熟度提升前每千条指令出错率约为0.31条，提升后仅为0.03条。 　　但CMM也不是万能的，并不一定对所有的软件企业都适合，实施CMM的企业有成功也有失败。这是因为，在运用CMM中还存在着一些局限性。主要包括： 1、CMM提供了一种有步骤且目标一致地改进软件产品的管理过程和工程过程的方案，但是它并不保证软件产品将成功地构造出来，或者保证恰当地解决全部软件 工程中的问题。 2、CMM最初是以承接政府大型软件合同的企业为对象而制订出来的。因此，中小型软件开发企业在采用CMM的时候，必须运用自己的专业知识和判断力去进行剪裁，按照企业本身的特点和需要去解释它的条文。 3、CMM的实现依赖于有关人员的积极参加和进行创造性活动。 4、正式推行CMM需要在人力和经费上增加投入，这对中小企业有一定困难。 5、实施CMM，通常要经过较长的一段时间之后（两年、三年或者更长）才能看到成效。据最新报告，CMU/SEI推荐了从CMM的一个层次提高到另一个层次所要花费的时间，其中最短也需要14个月，可见是一个漫长的历程。 正确实施CMM的策略 　　从去年开始，CMM已受到我国软件业的广泛关注，国家有关部门已出台了相关政策。目前鼎新、东大阿尔派、联想软件已通过了CMM2级认证，摩托罗拉中国软件中心通过了CMM5级认证，还有不少软件企业正在尝试实施CMM，如富基旋风公司正在积极准备2003年通过CMM3级认证。然而针对我国软件企业的现状和CMM应用的局限性，为了使其得到很好的实施，我们必须注意以下几个关键问题： 1、在引进、消化、吸收的基础上需要自己创新，让CMM更实用化：我国的软件产业引进国外先进管理方法是势在必行的。但国情不同，文化背景不同，因此在引进、消化、吸收CMM的基础上，需要自己创新，有些东西不能照搬照抄。例如，对于成熟度调查表等需要改进。因为管理是与文化有关的，中国文化与欧美文化是不完全相同的，甚至视角都不同，改进是必须的。最近，美国软件工程研究所对原来的CMM模型也作了改进。外国人自己也在改进，对于国人来讲，更应形成自己的管理模式，不断总结、改进、提高。 2、加强培训和咨询服务：目前我国推广CMM的工作重点应该是举办相关的技术培训、管理培训和咨询服务，让国内软件企业更深入地了解、掌握CMM，并指导和协助软件企业参照CMM模型，迅速地建立一个起始的软件过程，分步骤地改进自己的软件过程。对于其中有条件的、特别是出口型软件企业，应全面实施CMM，逐步通过CMM等级评估，以提高在国际市场上的竞争力。另外，我们还应重视培养自己的CMM主任评估师以及相关的高层次人才。 3、高层领导要重视并领导实施CMM：企业上层领导要首先理解建立软件过程管理和改进的重要性，并亲自领导这件工作，要保证过程管理的人员配备。 4、建立过程改进小组，明确责任：在实施CMM的过程中，成立过程改进小组是非常必要的。过程改进小组是过程改进的主要执行者，一方面要赋予成员相应的权力，另一方面要明确规定成员的责任。 5、借助软件过程评估，专注于软件过程改进：对于我国的软件企业，最好先按照CMM严格的软件工程方法，致力于改进企业的管理，提高软件开发能力，而先不要搞软件能力评鉴以及追求认证、评级。等到能力成熟后，再进行认证。这样可以避免有些企业将追求的目标定为“能力等级评鉴”，取代了实际的产品质量改进，造成华而不实、甚至弄虚作假的现象。 6、明确软件过程管理与改进的唯一目的是：按时、按预算开发制造出高质量的软件产品。 7、针对企业自身的特点，对CMM进行适当裁剪：对于CMM和其他的模型与标准，我们不能生搬硬套，而应将其作为参考，必须运用自己的专业判断力，按照企业自身的特点、要求与现实条件，制订软件过程和选择实行改进的部分。 8、充分认识改进过程本身就是一个规范的过程，需要循序渐进、逐步改进：因为软件过程成熟度的升级本身就是一个有生命周期的过程，而且全面引进CMM所涉及的范围非常广，要求人力、财力与设备资源的投入跟得上。所以在实施CMM时，企业千万不要一开始就把目标定得过高，不必一下子去满足某一能力成熟度等级的所有目标，可以试行某些关键过程域的一部分关键实践活动。另一方面，企业还应该规划出软件过程建立与改进的短、中、长期目标，分清轻重缓急，逐步取得经验，不要一下子动大手术，一下子什么都想得到，也不要作赌博式的全盘投入。企业应在对CMM有透彻的理解之后，才去考虑是否全面引进的问题。 9、专业开发人员要全力支持，并参与过程管理和改进：CMM的实现依赖于全体有关人员的积极参加和他们的创造性活动，否则不仅他们本人会失去从软件过程改善中获得提高的机会，甚至还会成为过程改进的阻力。 　　无论对软件企业自身，还是对我国软件业整体，推行CMM是势在必行的。通过实施CMM，可以促进软件企业规范化管理、工程化生产，提高软件企业的能力成熟度，改进软件的开发、维护过程，按时、按预算为用户提供高质量的软件，提高产品和企业的竞争力。在商业信息化建设、电子商务建设以及商用软件产品与商业应用系统的开发过程中，软件企业借鉴并应用CMM管理方法是非常必要的，对提高商业软件的水平，将会起到很大的推动作用。