CMM与CMMI的比较之--软件管理

newideaway

CMM与CMMI的比较：从传统的到现代的软件管理内容摘自：CMM与CMMI的比较：从传统的到现代的软件管理
著者：沃克尔·罗伊斯
Rational 软件公司战略服务 副总裁 总经理
      本文总结了从传统软件管理技术过渡到现代软件管理技术的一些思想。我特别要认可软件工程学院SEI在其新方法CMMI（能力成熟度模型集成）中的改进，并促进开发公司正确地应用这个方法。虽然我一直支持原来的能力成熟度模型（CMM）的精神，但实际它经常被错误地理解和应用。从我25年来和许多进行过程改进的世界领先的软件开发组织的合作经验看，我相信大多数应用CMM的组织还局限于默认的瀑布模式思想上。我不认为错在模式本身，因为我知道CMM语境里的一些过程改进是基于一种现代的、叠代的开发方法。不过，我这种启示性的理解并非规范。
CMM综述
    基于组织对关键过程域的支持，CMM定义了软件过程成熟度的五个级别。级别1（初始级）描述了不成熟，或者说是未定义的过程的组织。级别2（可重复级），级别3（已定义级），级别4（已管理级）和级别5（优化级）分别描述了软件过程成熟度级别递增的组织。和这些级别相关的KPA是：
级别2：需求管理，软件项目计划，软件项目跟踪和监控，软件子合同管理，软件质量保证，软件配置管理。
级别3：组织级过程焦点，组织级过程定义，培训大纲，集成软件管理，软件产品工程，组间协调，同行评审。
级别4：定量过程管理，软件质量管理
级别5：缺陷预防，技术更新管理，过程更改管理
多数组织的基本目标是达到成熟度3级。评估组织当前的成熟度级别的手段之一是软件能力评估（SCE）。SCE通过评估软件过程（一般以方针陈述的形式）和项目实践来确定该组织是否言行一致。组织的过程体现了"如实记录所做的工作"，项目实施（对该过程的特定剪裁和解释）应该证明"说到做到。
CMMI 综述
    软件成熟度模型（CMM v1.0）最早是软件工程学院开发的，并特别提出软件过程成熟度。1990年，该模型首次发布，在许多领域被成功地采纳和使用。其他学科的CMM也相继开发，例如系统工程、人员、集成产品开发、软件采购等等。
    CMMI被看做是把各种CMM集成为一个系列的模型中。CMMI的基础源模型包括：软件CMM 2.0版（草稿C）, EIA-731系统工程，以及IPD CMM (IPD) 0.98a版。CMMI也描述了5个不同的成熟度级别。
1. 级别1（初始级）代表了以不可预测结果为特征的过程成熟度。过程包括了一些特别的方法、符号、工作和反应管理，成功主要取决于团队的技能。
2. 级别2（已管理级）代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理、以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。
3. 级别3（严格定义级）代表了以组织内改进项目执行为特征的过程成熟度。
强调级别2的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。附加的组织级过程域包括：
    需求开发：多利益相关者的需求发展。
    技术方案：展开的设计和质量工程。
    产品集成：持续集成、接口控制、变更控制。
    验证：保证产品正确建立的评估技术。
    确认：保证建立正确的产品的评估技术。
    风险管理：检测、优先级，相关问题和意外的解决方案。
    组织级培训：建立机制，培养更多熟练人员。
    组织级过程焦点：为项目过程定义建立组织级框架。
    决策分析和方案：系统的可选的评估。
    组织级过程定义：把过程看做组织的持久的发展的资产。
    集成项目管理：在项目内统一各个组和利益相关者。
4. 级别4（定量管理级）代表了以改进组织性能为特征的过程成熟度。3级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。级别4附加的过程域包括：
组织级过程执行：为过程执行设定规范和基准。
定量的项目管理：以统计质量控制方法为基础实施项目。
5. 级别5（优化级）代表了以可快速进行重新配置的组织性能，和定量的、持续的过程改进为特征的过程成熟度。附加的级别5过程域包括：
因果分析和解决方案：主动避免错误和强化最佳实践。
组织级改革和实施：建立一个能够有机地适应和改进的学习组织。
CMM过时了吗？
    一些CMM实践的问题也是传统瀑布方法和过度基于过程的管理的症状。CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系（即：先是需求活动，然后是设计活动，编码活动，单位测试活动，集成活动，以及系统接收测试）。这大概可以解释为什么许多组织对CMM的认识停留在瀑布思想上。
    另外，叠代开发技术、软件产业最佳实践、和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。
分析CMM 和 CMMI分别和瀑布模型以及叠代开发之间有什么联系，方法之一就是看每个模型的KPA是否为这两种不同的开发方法激发了合理的软件管理原理。首先，让我们来定义那些软件管理原理。过去10年间，我编译了两套原理：一套用于传统的瀑布方法，另一套用于现代的叠代方法。得承认的是，这"十大原理"没有科学基础，并且只提供了符合它们各自的管理方法的成功模版的粗略的描述。但是它们的确为我的观点提供了一个合适的框架：CMM和瀑布思想相联系，而CMMI和叠代思想联系得更紧密。
1. 设计之前冻结需求。这是需求第一过程的本质：项目组努力提供一个准确的需求定义，然后严格按照需求实施。需求变更会严重破坏编码和测试阶段，因此，项目组在其他设计和开发活动中投入主要力量之前，必需完整地、明确地指定需求。
2. 详细设计评审前避免编码。编码变更会严重破坏编码和测试阶段，在开始编码前，如果还有很多变更阻力，项目组必需保证整个设计是成熟和完整的。
3. 是使用更高指令编程语言。更高指令编程语言避免了一系列主要的错误根源（通过先进的数据录入、接口分离以及打包和编程结构），并允许软件方案可以使用更少的人工合成码进行编程。
4. 集成前要结束单元测试。虽然设计是自上向下的，测试过程是自下向上的：在交付进行集成测试之前，最小的单元先进行全面测试。这样的次序限制是为了在集成前多发现一些单元级别上的缺陷，否则它们将造成更多的问题和返工。
5. 维护所有产品可跟踪性。为了保证在每个阶段维护项目的完整性和一致性，要跟踪需求产品以及设计和测试产品。当提出变更或开发一线人员识别变更时，这提供了变更对评审的实际影响和潜在影响的完整视图。
6. 文档化并维护设计。没有文档化的设计就不是设计了。在以后的阶段，由于代码成为主要的工程产品，必须更新设计产品以保证一致性，并为变更决策提供基础。
7. 由一个独立小组评估质量。项目组应指定一个独立小组负责保证产品和过程的全面质量一致性，以维护一个有别于分析人员、设计人员和检测人员的独立的报告渠道。
8. 全面检查。通过检查详细设计和代码来发现错误，比通过测试发现错误要好得多。要确保检查覆盖所有需求、设计、代码和测试产品。
9. 在项目早期进行全面的精确的计划。对于识别关键路径、管理风险以及评估程序变更来说，一个完整的、精确的、细化的计划是必要的，它应该安排整个进度的详细活动和产品。
10. 严格控制源代码基线。一旦产品进入编码阶段，就必须用严格的配置管理维护测试过程的正式发布的基线控制，并把产品转换成适合发布的零缺陷状态。
以技术采用工具推进CMMI实施
对于正从其它过程改进模式或方法向CMMI转移的组织来说，把CMMI的实施理解为技术采用和应用技术采用的概念，能够使过程改进顺利得多，并可提供可应用于其它新技术采用的战略。
作为技术采用的CMMI实施
    什么是技术采用？一般说来，就是指和组织选择、实施、维持技术使用等相关的一系列实践和要素。为什么把CMMI实施看作技术采用？首先，CMMI是一种技术，一种过程技术；另外，它是激进的。"激进的创新就是引进对于组织来说是新鲜的、并要求发展新常规的东西。"这通常会更改组织成员的标准信念和价值体系。把CMMI实施看作技术采用，能使CMMI实施者受益于以下所描述的技术采用的工具和概念。
处理和各种利益相关者的关系
    成功实施了软件CMM的人可能会认为他们仅仅只要把同样的转移战略应用到CMMI实施中就可以了。虽然软件CMM 1.1版和CMMI框架有相似之处，CMMI提供了把CMM概念的应用范围扩大的机会，这并不意味着仅仅把软件组织的经验推广到涉及产品和服务开发的其它部门。这涉及到CMM的新的采用者，和把CMM的有效范围扩展到组织的子系统中去。采用CMMI包括在任何时间和需求不同的各种听众打交道的技巧。解决方法之一就是工程过程组，或者相应的小组，应由CMMI的所有利益相关者的代表组成，而不仅仅是"组织软件部分的有经验的软件工程过程组"成员。
了解受众
组织里是谁要采用CMMI以改变行为、态度、或是价值？执行官、经理、技术人员、还是支持小组？开发采用策略时，要了解关于每个组织级子文化的不同的事实。
在子文化小组内，每个人对技术采用的反应也会不同的。不同的采用者类型的采用速度是不一样的。这些组的不同在于他们对要求变更他们行为的创新，无论是过程还是技术创.
图1.技术采用人数
   采用者类可用于计划谁应该得到该技术，以及哪种采用支持机制可能是成功的。例如：如果试点实践影响到一群主要由落后参与者组成的群体，有一个完全打包的解决方案，新实践是组织授权的，又允许不采用的话，试点就更容易取得成功.
传播与灌输
   在考虑采用一个诸如CMMI的过程技术的时候，需要花些时间考虑组织内不同角色的不同采用目标。以上描述的一些其它概念有助于解决一些目标问题，例如采用的目标是什么样的采用者，组织内的哪些要素需要重新排列。另一个应该考虑到方面是相对来说，重点应放在CMMI的传播（如何推广CMMI的应用）还是CMMI的灌输（CMMI如何深入组织基础结构中）。注重CMMI的传播也许能在组织内使CMMI得到广泛的接受和学习，但可能无法改变组织内的行为，而这更切实地影响业务结果，对改进的帮助也更多。灌输得越多，组织内有关"关键工作流动CMMI程度"也随之提高，同时，组织管理和监控结构内的技术可见度也随之提高，这些通常导致更加永久的行为变更，这样的行为变更对投资回报是有正面影响的。
度量灌输，是可以度量技术的"应用水平"。例如，一个组织内CMMI应用的灌输发展状况大约如下：
1.     在一些项目中采用CMMI，已经改变了规程和过程来反应新的实践。
2.     组织内的一个部门改变了方针，以反应CMMI推荐的实践，并阐述和发表了一系列标准过程资产，作为启动和管理新产品开发项目的基础。
3.     必要时检查和变更CMMI实践的新项目的奖励系统，以鼓励新过程的生产性利用。评估部门内现有的项目，决定标准过程资产的哪些部分可能被应用于项目的生命周期的当前点并获利，对项目进行培训和予以其它支持，以便项目中可以灵活地采用新实践。
4.     由于项目满足客户期望的良好声誉，采用CMMI的部门中的项目成员被选入组织其它部分的项目中。但是，其中的许多成员选择留在原部门，而不愿到组织的其它部门，因为那些部门的管理和工程实践相对来说无纪律。
5.     这些情况都可以认为是对组织采用CMMI 的灌输 "应用水平"的度量。随着应用水平的提升，社会子系统的CMMI的可视程度也随之提升，正如第四种情况所列举的。
度量的传播提供了一个不同的视角。度量的传播是说明关于应用CMMI的信息在组织内的传播范围，而不是度量CMMI的影响深度。在采用CMMI初期进行传播度量，组织的剖面图类似图2所显示的剖面图。随着时间的推移，越来越多的组织成员参与采用CMMI的活动，剖面图就会变成象图3所示的剖面图。度量的用法之一是帮助高层经理理解：需要一定的时间才能看到实施CMMI投资的切实的回报。让他们了解许多人都是需要经历几次事件才能改变他们的行为，并因此改变其行为的结果，这有助于他们容忍开始采用技术和看到业务成效之间的时间是滞后的。
待续...............

newideaway

转移机制
多年来，SEI一直用Patterson-Conner承诺曲线的变化来帮助组织了解所需的交流和实施计划，以保证其完全采用变更（见图4）。这也是一个可用来对转移机制度类别进行分类和理解的框架，转移机制有助于组织内的个人和小组进一步采用新技术。转移机制是指有助于加速从一个承诺里程碑到另一个里程碑的进展的产品、活动、事件和方法（例如：从接触到了解）。
图4：Patterson-Connor承诺曲线
随着新技术的采用，机制从交流和教育向实施支持和激励管理转换。早期使用机制可能包括CMMI 参考卡和其它模型的计划。然后，机制可能包括CMMI为特定的组织语境剪裁的指南。
转移机制的计时是很重要的。在一些人甚至不了解组织的哪个部分受到该模型的影响时，就告诉他们监督CMMI的详细实施所使用的度量，这是一个过早使用转移机制的好例子。反之，等到组织内每个人都进行了CMMI介绍的培训了才把怎样把CMMI 应用于整个组织的战略构想告诉他们，这是太迟使用转移机制而使之无效的一个例子。
实践团体
    一旦应用技术解决了问题，就可能要培养实践团体，包括组织内要继续学习该技术及其实践的成员。他们可能会为其它没有采用该技术的人进行技术的"翻译"，相互进行交流并解决问题，共同提高他们对技术的应用。
    在CMM应用史上，许多软件过程改进网络都显示了实践团队的特征。在组织内部保持人员持续学习和涉及技术以及变更代理的观点，可以加速CMMI的采用，这是由于这种方法可以获得"组织内正常组织结构之外的信息网络"的影响。
小结
    技术采用领域的许多方法有助于CMMI的有效应用，尤其在它日趋成熟时。其中的一些方法在SEI的研究文章中得到了强调。早期的CMMI应用者应该准备"投资建立转移机制"。他们的组织将会获得成功，并应用有创造性的方法获得进展。理解和应用技术采用概念有助于通过为改进的工作量增加已有的工具，以获得最大的投资回报。