| CMM SM是适用于小工程项目和小规模组织的经剪裁的CMM版本。而CMM V1.1是用适宜于那些和政府签约的大型组织的标准实践来表达的，这些实践必须剪裁才能适合不同于这个样板的组织的需要。 摘要：由美国软件工程学会（SEI）开发的软件能力成熟度模型（CMM, Capability Maturity Model），已经成为软件过程及质量改进方面的世界主流。尽管CMM被广泛接受了,但有关如何在商业驱动的软件过程改进中有效地使用它，特别是针对小型组织和小型工程项目，仍存在着许多的误解。有关在小工程或小组织中应用CMM的一些常见问题包括： 什么样的才算做“小”？标准是根据人？时间？项目大小？还是产品的艰难复杂程度？ 什么是CMM的“需求”？是否有不该被应用到小项目/小组织中去的关键过程区域或目标？有好的过程“ 不变量”吗？ 造成CMM被滥用的驱动力和动机是什么？ 这篇论文以小型组织为例讨论了怎样在各种商业环境中正确而有效地使用CMM。从那些对改进其软件过程感兴趣的任何组织得出的结论是：使用为大组织/大项目所开发的发行版来相应地解释用于小项目或小组织中的CMM，可能会存在程度上的差异，但它们决不会是本质上的不同。正确有效地使用CMM，要求具有专业性的判断，并且能够理解CMM是如何针对不同的用途来进行建构的。 1. 介绍 软件工程学会(SEI)是由美国国防部1984年设立的一个联邦资助研发中心，主要通过大范围承包工程的研究来寻求软件工程技术的跃迁——即改进软件工程的实践。在某种意义上, SEI的存在是“软件危机”（即习惯性的拖延，超出预算，达不到预期功能，以及不可靠的质量等[Gibbs94]）的结果。硬性地讲，危机大多是由软件自身造成的，一位首席信息官曾说过：“我宁愿让它有了错，也不想让它出得晚，稍后我们总会去修理它的。”许多组织要完成预期成本和进度目标的关键就在于——经常性地关注质量成本，一再地学习以往20年由美国工业界所推演出的现称为“全面质量管理（Total Quality Management，TQM）”的一门课程。 各种因素综合造成的如下情形并不令人惊奇： “人们总是抱怨我们，因为他们知道在抱怨的时候，我们会努力工作。”“大多数软件评估报告是令人沮丧的……但好在他们还不是对评估过程完全不满。”“正确的进度表是绝对不能达成的，只不过还不那么明显地不能达成。” DeMarco继续观察到我们的工业界正在疲于奔命,而感觉上唯一真切的选择就是降低质量以换取速度。 TQM课程聚焦于在质量管理引导下减少开发周期, 提高生产率，增进客户满意程度并努力取得商业上的成功。挑战，当然被定义成“聚焦质量”的实用手段是什么，随即就要系统地寻求各种质量问题。也许SEI最成功的产品就是软件能力成熟度模型(CMM)，就是说，它给在全世界软件社团中已成为主流的软件过程改进提供了路标。CMM定义了怎样使开发组织的软件过程走向成熟的5个等级的框架结构。这些等级描述了从特别紊乱的混沌过程到成熟的、有纪律的软件过程的进化路径。如图1中的概示，5个等级和18个关键过程区域详细描述了它们。5个成熟度等级指明了对于成功的过程改进（即在许多案例的研究和调查中被文档化记录的有效性）的优先顺序。
尽管CMM的当前发行版本1.1的焦点是在与政府签约的大型组织和大型工程项目上,但CMM是被设计成了为实现对软件工程及项目管理的详细指导及示例而普遍适用并分级细化的抽象模型。CMM的关键过程区域，是以能达成被描述为关键实践、子实践及示例的目标而满足的。CMM用以评估的构件是成熟度等级、关键过程区域和目标。另外的构件则在怎样解释模型上提供了信息和指导。18个关键过程区域共有52个目标和316个关键实践。虽然CMM的“需求”可以被概括成对52个目标的描述，但它的支持材料却包括了将近500页的信息。关键实践和示例描述了好的工程和管理实践是什么样，但是没有说明如何去实现这些过程。 CMM之所以能成为一个指导过程改进的有用工具，是因为它历史性地成为了通过对软件社团已开发软件的广泛评审而形成的全面质量管理(TQM)概念的一个常规应用。它的五个等级是非常简单的，但如能将其巧妙运用，就会找到一个激励人的支点，正如美国国防部的程序经理所坦陈的：“底线是进度表。我的晋升和加薪，就全靠首当其冲地完成进度表了。” 正当CMM由于对指导软件过程改进的重要性而令人鼓舞地在全球变得流行起来的时候，它也正被一些人滥用和误用，并且另外也有人没能有效地使用它。CMM v1.1提供的指导往往是面向大工程和大组织的，在使用过程中小组织发觉到这方面有问题，尽管我们坚信CMM的基本概念对于任何组织规模、任何商业环境、任何应用领域都是适用的。 难道按时完成进度、预算和需求，对于小项目或小组织来讲，真的那么重要吗？在某些环境下，这确实是值得商榷的，就如同商用小塑胶袋，拿它跟那些市场份额总是占先的装船出口的顶好产品相比，其成本是极其微不足道的。如果一个组织的雇员十分满足安于现状，那么CMM所提供的能导致真实变化的东西将会很少；变化只会出现在那些对现状非常不满并且乐于标新求异的经理和员工身上。无论对大组织还是小组织而言，这都是无庸置疑的。 CMM在称心如意地实施管理及工程实践方面，都提供了良好的建议，它强调以人为核心的管理、沟通和协调以及能体现软件开发和维护特性的强化设计的过程。无论如何，把它看成灵活的指南而非生硬的指令吧，还有对于软件工程和管理，以及应用领域和组织的商业环境等方面，CMM用户必须能够在这些方面应用其基于知识和经验的专业判断。因为CMM聚焦于软件，所以TQM的一些重要方面不能直接照搬到模型里，比如系统工程里的“人的问题（people issues）”和“较宽泛的审视（broader perspective）”，这些在商业上可能是至关重要的。CMM应该被看成使用在软件过程改进系统步骤里的一种上下文工具，比如SEI的IDEAL模型，如图2所示。 在对软件过程改进的讨论中，开始的问题总应该是这样的：为什么软件组织会对使用CMM感兴趣？如其愿望是以直接依从商业目标以及心甘情愿投身改革而来改进过程，那么CMM确实是效用非凡、功能强大的工具；如果CMM只被当成单纯的短期时髦，那可真是把一剂糟糕的药方拿到了手。如果驱动力是客户利益，理想情况下客户利益将导致客户和供应商之间协作的改进。有时供应商的利益集中在软件能力评价(Software Capability Evaluations，SCEs)上, 如此则可在那些来源选择及签约监督方面是由政府获取代理的项目上有所表现。国防部在执行软件能力评价(SCEs)标准的政策上是排斥绝大多数小组织和小项目的，但也存在它们可以有所作为的机遇。 很多CMM的滥用都对“其他人”可以做什么的担心置于不顾。如若一个开发组织能在用CMM来导引胜过被需求来牵引上达成共识，那么在模型中要解决问题的很大一部分就化解掉了。有很多这样的案例。尽管如此，那些对于好的工程和管理实践的无知仍将成为问题。对于那些只有很少的管理方面的经验和训练而只是因技术优秀就被提拔到管理层职位的人来讲，问题是显而易见的。由DOD（美国国防部）特种部队确认并提出的问题是： “少数区域在最佳当前实践和平均当前实践之间有着如此巨大的缺口。” “大问题不在技术方面……现今军事软件开发的主要问题不再是技术问题，而是管理问题。” 2. 小组织和小项目 本篇论文的焦点对准了在小组织正确而有效地使用CMM，因为经常有人问我，“CMM是否能被用在小项目(或小组织)？”然而有关“小”的定义却是模糊难解的，如表1所示。 在某段时间里我们致力于为小项目和小组织而开发出剪裁适当的CMM，1995年CMM剪裁工作室的结论是我们甚至不能对什么才算“小”的真正含义达成一致意见！这个结果得出了一篇更注重于“如何剪裁CMM”而不是“已为小组织而裁好的CMM”的报告。1998年SEPG会议关注于CMM及小组织上，“小”被定义成“5个或更少的人为期3至4个月的开发”。Brodman和Johnson则定义“小组织”为少于50个软件开发人员并且“小项目”为少于20个开发人员。 表2.
注意从小到微小的项目是在被Humphrey称为小组软件过程（Team Software Process，TSP）的范围里，而个人的开发努力则在个人软件过程（Personal Software Process，PSP）的范围里。TSP和PSP阐明了CMM的概念是如何应用到小项目中的。“荒唐”变体则描述了一个解释性的问题。在两种场合里，变体都会被论述，问题是“项目”的定义。两种情况下它都是个维护环境，而且组织的“项目”将被描述为CMM的任务；更多关于CMM“项目”的精确解释是一个基线的升级或者维护的发行……但术语的冲突会将其搞乱。 对于那些使用CMM的小组织来说，首要的挑战就是其主要商业目标要能存活下来！甚至在决定之后，现状是不能令人满意的而且过程改进也将有助于发现资源并为过程改进分派职责,接下来通过制定与部署过程所要做的是一项艰难的商务决定。小组织往往相信： 我们全都是胜任的——人们是被雇佣来做工作的，我们可不想负担那些要在雇佣期间进行培训所花的任何时间或金钱 我们全都彼此沟通——因我们是如此紧密地在“渗透式”工作 我们全都是英雄好汉——我们无论做任何需要做的事情，规则都不适用于我们（这些恰恰达成了将工作完成的方式），我们承受住了短周期及高压力。 然而对于小组织，也正象大组织一样，有着非文档化的需求所带来的麻烦，以及无经验的经理人员、资源分配、培训、同行评审和产品文档等方面带来的问题。尽管有着这些挑战，小组织仍能非同寻常地进行创新和提高生产率。尽管有一大把需要人们去解决的大块问题，通常小组织比大组织更具生产效率，他们能更敏锐地成形生产要素并且远远更少见有沟通方面的问题。无论如何，遗留下来的问题是，小组织也需要过程纪律吗？回答这些CMM咒语,我们需要考虑到纪律包括了什么? 而那将引入这篇有关CMM指导性课题论文的核心。 即便如此，评估小组织时运用最新式的评估过程是明智可取的。为期两周的CMM内部过程改进基础评估(CMM IPI)的形式也许是多余的，甚至会由于缺乏监控而导致某些遗漏，而关键是有效地确认重大问题。我建议将注意力集中在建立在企业文化上的制度化实践方面：如规划、培训等等，并确切地将过程改进落实到商业需要上。 3. 解释CMM CMM都适用在什么地方呢？ CMM是按照在任何环境中为任何项目都能提供良好的软件工程和管理实践来塑造的。模型是被分层次描述的： 成熟度等级 (5) ->关键过程区域 (18) ->目标 （52） ->关键实践 （316） ->子实践和例子
(许多) 对于小项目和小组织的解释性指导也同样适用于大项目和大组织。在正确有效地使用CMM的过程中，智慧和常识是必要的。所有（软件）项目都有所不同，但所有（软件）项目也都有所相同——这可全都是真的。我们必须平衡现实：相似与唯一，秩序与混乱。那些成功所缔造出的持久组织是真正有能力的学习型组织；此外在其他地方也必须得益于其成功。 CMM的标准构件是成熟度等级、关键过程区域和目标。CMM的所有实践都是有益处的。既然那些详细的实践都首先支持大型签约的软件组织，也就没必要正好写成是直接适用于小项目和小组织——然而它们同样提供了如何达到目标和可重复地实现已定义的、规范的、不断改进的软件过程。这样就会避免了过程评估方式上的简单武断——诸如“去问老张吧”。 我最通常的指导性建议是开发出一套适用于组织的置于CMM术语和语言间的映射。特别地,组织结构的期限行为、角色、关系以及过程的形式都需要映射到其组织的相应部分，以防止出现无法理喻的事情，诸如“荒诞的一小时项目”。组织结构的例子包括诸如质量保证、测试及配置管理等“独立小组”。应该用术语明确地指定适当的组织角色，诸如项目经理及项目软件经理等。人们可以担当多重角色，例如，一个人可以同时做项目经理、项目软件经理、软件配置管理（SCM）经理等等。明确规划好这些，将生发出对CMM更生动简洁也更协调一致的阐明。 一旦术语问题被理解了，我们就得考虑什么是守纪律过程的“不变量”（invariant，一个必须永远为真的约束）以及哪些实践依赖于上下文关系。除了软件转包合同管理（即若无转包合同的话就可能成为“不可用的”），一般来说我们总是假定关键过程区域及目标关联到任何环境。我想象不出同行评审被等级3的组织适当剪裁掉的情形。尽管所选择出的实践（诸如正式方法）可以替代同行评审，但这还是一个需要足够专业性判断的问题。拥有专业性的判断和训练、经验丰富的评估人员是至关重要的，甚至对小组织也一样！ 我从没见过下列哪个环节是不必要的(尽管实现方式不同)： 当然，一些实践都被处理成了“大项目的实现”。小的项目未必需要软件配置管理组或者变更控制部门……，然而配置管理及变更控制总还是要有的。一个独立的软件质量保证(SQA)组也许不是必要的，但目标的认可始终是需求要被满足。一个独立的测试组也许没必要设立，但测试总是必要的。即使小组织和大组织之间的实现有着根本的不同，但我们看到对于上下文相关的实践，其意旨是建设性的。如果有人读到CMM所定义的“组”，它是被陈述为“一个组可以是被分派兼职的单独个人、从不同部门分派了几个兼职的个人，也可以是全职的几个个人”，这里就有意迎合了环境的变化。 除了这些, 一些特殊的问题再三地出现, 尤其是对于小组织，涉及有： 管理资助 获取高层管理的赞助是构建组织能力的关键成分，这看起来固然很陈腐老套。做为个体，我们可以在我们可操控的范围内磨练自身的专业素养及自制能力。可是若要一个组织作为一个整体来改善其效能，那么其高层管理就必须积极地支持变革。由下至上地改革，无须赞助和协同，却能够导向超过可预期改进的组织能力的胜地，这可真是奇闻了。即便如此，当总裁（或者公司创始人）是主角时，敬重“冠军”往往是具有撼动整个组织的影响力的——包括总裁本人。 对于大多数组织而言，管理实际上是必须基于一个度量基础的范例转换。掌握有用的数据，就是说你必须了解性能数据的含义以及如何有价值地去分析它。从收集简单的有用数据开始，你也不得不敏感于经由度量而导致紊乱行为的潜在因素[Austin96]。度量活动要确认什么是重要的，但一些事情是难于度量的。管理需要确保注意力倾注在项目的所有可评价方面，包括那些难于度量的，而不仅仅是那些易于度量和跟踪的。 在大多数组织中，软件工程过程组(SEPG)或一些类似小组应该成为协调过程定义、改进及部署活动的工作组。把资源奉献给SEPG的原因之一是要确保完成评估调查。许多改进纲要仅仅因为有着不是从评估所导致的行动而失败。小组织可能没有全职的SEPG人员，但改进的职责应该明确地加以指派和监控。 起始于“不保修”（"as is"）过程，而不是“合理”（"should be"）过程——对于有效实施的实践与对指派任务的抵触来说，这相当于两者之间的杠杆，此起彼落。要求自上而下的每个人都遵循的“合理”过程，若其显著地不是由被授权的工人所参与开发的，则将是一个通用的失败处方。“不保修”过程进化的理由是人们从事工作是希望工作任务能被完成（即使那意味着要整天围着系统转）。“合理”过程或可行，或不可行——只有在特定的文化环境中才能成为可行。伴随着过程管理和改进的组织焦点，“不保修”和“合理”过程将聚合在一点——即导致有组织地进行学习。 文档化你的过程。文档化地记录一个过程(或产品)的原因是： 1)沟通——给别人一个当前的交待以及给自己一个今后的备忘； 文档化过程支持有组织地学习以及避免重复地打造解决通用问题的车轮（车轮在任何地方都被置于一个反复重用的过程）。归档是如此重要，但有用的文档最好不要冗长繁杂。我们生活在一个迅速变化的世界里，请保持文档简洁吧。过程也不要冗长繁复。CMM关注做事（doing things），而不是成事（having things）。一个1-2页的过程说明是足够了，子过程和步骤能按需调用就行。运用好的软件设计原则，比如在定义过程中使用内存空间的局域性、信息隐藏以及抽象。另外的实用经验是每周最多跟踪2-3个任务的工作。其顺序应由少量指导性原则或法则所确立，而不是由复杂的控制来确立。 过程需要剪裁到项目所需的程度。 虽然标准过程提供了一个基础，但每一个项目也都将有其独特的要求。剪裁时不切实际的约束可导致执行过程中的重大阻力。正如Hoffman所表述的，“别生造感悟也别强求过程。” 过程所需的形式化程度对大组织和小组织都构成了威胁。对于那些每每提到要“按照文档化步骤”的等级2的25个关键实践中的每一个，应该存有很个别的步骤吗？答案正如在CMM书籍《文档和CMM》(Documentation and the CMM)的4.5.5小节所论述的，是一个响亮的“不！”——文档的包装是组织化的必然结果。 文档化的过程如果没有加以有效地部署，只会具有很小的价值。要想达成文档化的大量买进，过程实现必须成为过程定义和改进的一部分。通过多种机制的培训，对于协调一致和效力非凡的软件工程及管理将是建设性的。培训的动机是发展技能。有很多“培训机制”不同于能有效培养技能的正规课堂培训。其中应该被认真考虑的是正规的顾问制。在此情形下，形式化意谓着寄希望于没有经验的顾问。形式化提示要在如何指导及监督顾问的效力上训练人们。 在过程或技术的最初部署之后，培训仍然是一个问题。当人员变动时，培训所增加的需要可能不会被充分地认识。顾问学徒制能充分地解决这一问题，但是除非能谨慎地加以监督，否则不能设想会有满意的结果。 管理上的培训是特别重要的，因为低下的管理会削弱一个好的团队。那些因其技术技能而被提拔到管理层的人，将不得不重新学习包括人际关系在内的一套新的技能。 软件工程管理的部分论题确实是风险管理。感觉上，CMM就是关于管理风险的。我们致力于确立稳定的需求，以便能有效地实施计划和管理，但商业环境总在迅急而紊乱地变化着。我们尝试在软件那混沌的大海里建造秩序的孤岛，但是秩序和混沌都自有其位置。Wheatley建议，“为了生存，开放系统维持在一非平衡状态，保持系统均衡以便它能改变和成长。尽管我们能确立帮助我们管理混沌世界里的风险的过程，我们也需要变化和成长。 这意味着你应该使用一个增量的或进化的生存周期。如果你想重心集中到风险管理上，螺旋模型将是首选的生存周期模型。如果重心集中在笼络客户上，可能快速原型法或接合应用设计更好一些。少数长期项目对稳定环境的奢求是必要的，对其瀑布生存周期将是首选——可能它仍是最普遍通用的生存周期。 注意，无论如何，对于小项目，瀑布生存周期都会是一个极佳的选择。 成功的过程定义和改进的头号因素是“全程计划（planfulness）”。计划是每一个主要软件过程都需要的，但不外乎绑定合理的判断、由组织决定什么是“主要的”以及怎样包装计划。一个计划可以驻留在几个不同的工件或被植入一个大计划当中。 即使你可以对最好的同行评审有争议，但简单的事实是同行评审带来的好处远远超出了其成本。数据表明一些检测表格应该是惯用的，但任何学院式或严格的评审表格，诸如结构化预排，都附加了重要价值。不幸地，认可同行评审并不意味着我们在系统地做着这件事。我们需要“走在路上”，而不仅仅是“说在嘴上”。这对技术人员来说是很大的挫折，他们不理解CMM所强调的管理，然而糟糕的管理会导致放弃好的工程实践，比如同行评审。 另外还有其他被确定为是小组织和小项目的问题，认定了下面的5个： 评估 我们没有讨论等级2的项目焦点对小组织构成的挑战。软件过程改进包括了那些对小项目而言是过度的开销。一些劝告从组织化观点来攻击恰似混合了等级2和等级3而又的确不失为合理途径的小项目的过程改进。CMM本就是为任何规模的组织或项目而考虑的。尽管无须过程焦点一个组织也能达到等级2，但极其高效的组织化学习的策略将成为减少项目开销的组织资产的一个重点。同时，必须认识到项目等级的改变可能会形成多半是基于正当利害关系的阻力，而且探察阻力时需要考虑组织进行学习过程的那部分。 需求功能是一个问题，因为比起人来可能有更多的CMM功能。这个问题是做为技术或角色的映射来讨论的。成熟度提问单因使用CMM技术而成为关注焦点，它可能在填写的过程中被搞乱。以组织的技术来表达提问单，甚至对于非正式的评估及度量也是很需要的先导。 指明了对于小组织的软件过程改进的6个关键： 高层管理的支持 如果将好的项目管理应用到软件项目中是确保成功的最佳途径，那么应该象对待其他任何项目一样来对待过程改进就同样是正确的。ISO 9001是在大组织里比小组织里使用更频繁的一个评估版本，因而Abbott也有兴趣针对他的小公司指出这一点。 Brodman和Johnson认为针对小组织/小项目的挑战有7种： Brodman和Johnson开发了一个针对小型商业、组织和项目的CMM剪裁版本。尽管如此，大多数CMM的关键实践还是被剪裁到了《LOGOS剪裁版CMM》里，变化体现在：
4. 滥用CMM 正确使用CMM意味着要平衡相互冲突的目标。基于CMM的评估要求运用专业性的判断。尽管如此，CMM在做出这些判断以及消除对一个明确的、反复的、非设计工作特有的过程的主观臆断等方面都提供了大量的指导。CMM有时作为一整套过程需求被提及，但它不能有任何含有“将要”(shall)的语句。这就是在核对（子）实践一致性时造成CMM滥用的原因。 有些是勉强地、无能地去解释、剪裁或应用判断力。这是易于委派到关键实践的，但却愚笨透顶。此种蠢行常常由客户意图及能力的偏执来驱动。我在更多的场合听说某人要做某些傻事，但他们害怕客户无知无能到理解不了不能完全生搬硬套CMM的道理的地步。这对于软件能力评价来说是明显有疑问的。判断可能不一致是对的——并且有时只有如此才合理。曾在某一环境中适用的却可能满足不了一个新项目。那就是我们推荐把过程成熟度包含在风险评估要比使用成熟度等级来过滤报价者更好的原因。小组织应该较少关心这个问题，因为对小组织的软件能力评价未必是划算的。它是从事许多小项目的大组织的一个问题的多个方面。 十分不幸，我没有此问题的解决方案。象这种CMM能帮助组织改进软件过程的“标准”，却是聚焦在达到一个没有从事潜在的、能导致紊乱行为的过程的能力成熟度等级。成熟度应该成为改进的度量，而不是改进的目标。这就是为何我们强调需要依靠改进来达到商业目的。 5. 结论 底线是软件过程改进应该有助于达成商业成就——而不是为其自身理由。无论对大组织还是小组织，这都是真真确确的。最好的忠告来自于Bellcore的总裁Sanjiv
Ahuja：“让常识奏效！” 而失去了所需的纪律观念，也将导致混乱不堪。 CMM描绘了软件过程改进的一个“常识工程化”路径。它的成熟度等级、关键过程区域、目标及关键实践经受了软件社团内部的广泛讨论和评审。同时CMM既非完美无缺也不包容一切，它只是表达了软件社团的一种广泛一致的意见，并且成为指导改进工作的一个有用工具，它也有助于小型软件组织改进它们的过程 [Abbott97, Hadden98b, Hoffman98, Pitterman98, Sanders98]。 小组织应该认真地考虑PSP和 TSP。掌握了PSP课程，我可以高度评价其建立了自我约束的能力。注意看书的效果不能等同于掌握课程及实际操作。CMM所从事的过程改进组织化的一个侧面，就是PSP致力于建造个体从业者的能力。PSP确信个人能够——基于他或她自有的性能数据——遵从纪律尊重价值——以工程化途径来构建软件。 |
