20年研发管理经验谈（八）

本文继20年研发管理经验谈（七）。

前言
　　CMM（Capability Marurity Model，软件能力成熟度模型）是于1984年美国国会与美国主要的公司和研究中心合做创立的一个由联邦资助的非盈利组织——软件工程研究所（Software Engineering Institute,SEI）的一个早期研究成果。该模型提供了软件工程成果和管理方法的框架，自90年代提出以来，已在北美、欧洲和日本成功地应用。如今该模型已成为事实上的软件过程改进的工业标准。下面咱们来一块儿学习有关CMM的一些基础知识。

1、 CMM基本概念
　　过程（Process）：为实现既定目标的一系列操做步骤[IEEE-STD-610].
　　软件过程（Software Process）：指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新。其中相关产品是指项目计划、设计文档、编码、测试和用户手册。当一个企业逐步走向成熟，软件过程的定义也会日趋完善，其企业内部的过程实施将更具备一致性。
　　软件过程能力（Software Process Capability）：描述了在遵循一个软件过程后可以获得的预期结果的界限范围。该指标是对能力的一种衡量，用它能够预测一个组织（企业）在承接下一个软件项目时，所能指望获得的最可能的结果。

　　软件过程性能（Software Process Performance）：表示遵循一个软件过程后所获得的实际结果。
　　软件过程成熟度（Software Process Maturity）：是指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。所谓成熟度包含着能力的一种增加潜力，同时也代表了组织（企业）实施软件过程的实际水平。随着组织软件过程成熟度能力的不断提升，组织内部经过对过程的规范化和对成员的技术培训，软件过程也将会被他的使用者关注和不断修改完善。从而使软件的质量、生产率和生产周期的到改善。

　　CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了知足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区获得了普遍应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。

　　CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把如今全部的以及将被发展出来的各类能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，创建一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。

　　关键过程（区）域（Key Process Area）是指一系列相互关联的操做活动，这些活动反映了一个软件组织改进软件过程时所必须知足的条件。也就是说，关键过程域标识了达到某个成熟程度级别时所必须知足的条件。在CMM中一共有18个关键过程域，分布在第二至五级中。
　　关键实践（Key Practices）：是指关键过程域中的一些主要实践活动。每一个关键过程域最终由关键实践所组成，经过实现这些关键实践达到关键过程域的目标。

　　软件过程评估（Software Process Assessment）是用来判断一个组织当前所涉及的软件过程的能力状态，判断下一个组织所面向得更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。
　　软件能力评价是（Software Capability Appraisal）用来判断有意承担某个软件项目的软件组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确或是否正常。

　　软件工程组（Software Engineering Group）：负责一个项目的软件开发和维护活动的团体。活动包括需求分析、设计、编码和测试等。
　　软件相关组（Software Related Groups）：表明一种软件工程科目的团体，它支持但不直接负责软件开发或维护工做，如软件质量保证组、软件配置管理组合软件工程过程组等等。在CMM的关键实践中，软件相关组一般应该根据关键过程域和组织的上下文来理解。

　　软件工程过程组（Software Engineering Process Group）：是由专家组成的组，他们推动组织采用的软件过程的定义、维护和改进工做。在关键实践中，这个组织一般指“负责组织软件过程活动的组”。
　　系统工程组（System Engineering Group）：是负责下列工做的我的的团体：分析系统需求；将系统需求分配给硬件、软件和其余成分；规定硬件、软件和其余成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。

　　系统测试组（System Test Group）：是一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了肯定软件产品是否知足对它的需求。

　　软件质量保证组（Software Quality Assurance Group）：是一些计划和实施项目的质量保证的团体，其工做目的是保证软件过程的步骤和标准是否获得遵照。

　　软件配置管理组（Software Configuration Management Group）：是一些负责策划、协调和实施软件项目的正式配置活动的团体。

　　培训组（Training Group）：是一些负责协调和安排组织培训活动的团体。一般这个组织负责准备和讲授大多数培训课程并协调其余培训方式的使用。

CMM 的分级
　　任何一个软件的开发、维护和软件组织的发展离不开软件过程，而软件过程经历了不成熟到成熟、不完善到完善的发展过程。它不是一朝一夕就能成功的，须要持续不断的对软件过程进行改进，才能取得最终的成效。CMM就是根据这一指导思想设计出来的。该模型为了正确和有序地引导软件过程活动的开展，创建一个可以有效地描述和表示的软件过程的改进框架，使其可以对各阶段软件过程的任务和管理起指导做用。该模型以产品质量的概念和软件工程的经验教训为基础，指导企业如何控制开发、维护软件的生产过程和如何制定一套与之相适应的软件过程及管理体系。

（一）、分级标准
　　CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。一方面软件组织利用它能够评估本身当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，经过不断的努力去达到更高的成熟程度。另外一方面，该标准也能够做为用户对软件组织的一种评价标准，使之在选择软件开发商时再也不是盲目的和无把握的。

CMM的分级结构能够描述为：
①、初始级：软件过程的特色是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功每每依赖于极个别人的努力和机遇。
②、可重复级：已创建了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对相似的应用项目，有章可循并能重复以往所取得的成功。
③、已定义级：用于管理的和工程的软件过程均已文档化、标准化，并造成了整个软件组织的标准软件过程。所有项目均采用与实际状况相吻合的、适当修改后的标准软件过程来进行操做。

④、已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量获得了定量的认识和控制。
⑤、优化级：经过对来自过程、新概念和新技术等方面的各类有用信息的定量分析，可以不断地、持续地对促进过程进行改进。
除第一级外，每一级都设定了一组目标，若是达到了这组目标，则代表达到了这个成熟级别，天然能够向下一级别迈进。CMM体系不主张跨级别的进化。由于从第二级开始，每个低级别的实现均是高级别实现的基础。

（二）CMM的主要内容
　　CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释其组成部分，如图示。在第二至第五个成熟等级中，每一个等级包含一个内部结构的概念。 每一级向上一级迈进的过程当中都有其特定的改进计划，具体状况以下。

　　初始级的改进方向是：创建项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工做，创建用户域软件项目之间的沟通，使项目真正反映用户的需求；创建各类软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划等；积极开展软件质量保证活动（SQA）。
　　可重复级的改进方向是：再也不按项目制定软件过程，而是总结各类项目的成功经验，使之规则化，把具体经验概括为权利组织的标准软件过程，把改进软件组织的总体软件过程能力的软件过程活动，做为软件开发组织的责任；肯定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固肯定的软件过程当中，从而能够跨项目改进软件过程效果，也能够做为软件过程剪裁的基础；创建软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应将来软件项目的要求；积累数据，创建组织的软件过程库及软件过程相关的文档；增强培训。

　　已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；经过软件的质量管理达到软件质量的目标。

　　已管理级的改进方向是：防范缺陷，不只在发现了问题能及时改进，并且应采起特定行动防止未来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变动管理，定义过程改进的目的，常常不断地进行过程改进。
　　优化级的改进目标方向是：保持持续不断的软件过程改进。

（三）CMM的内部结构
　　CMM为软件过程能力的提升提供了一条改进的途径。CMM由5个成熟度等级组成，每一个成熟度等级有着各自的功能。除第一级外，CMM的每一级按彻底相同的内部结构构成的。成熟度等级为顶层，不一样的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。 在CMM中，每一个成熟度等级（第一级除外）规定了不一样的关键过程域，一个软件组织若是但愿达到某一个成熟度级别，就必须彻底知足关键过程域所规定的要求，即知足关键过程域的目标。

（四）软件过程评估和软件能力评价
　　软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程当中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一块儿用于肯定组织的软件过程改进策略。
软件能力评价是对接受评价者在必定条件下、规定时间内可否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。经过利用CMM模型肯定评价结果后，就能够利用这些结果肯定选择某一承包商的风险。也能够用来判断承包者的工做进程，推进他们解决软件过程。

　　CMM为评估和评价提供了一个参考框架，指出了在评估和评价中一般采用的步骤。 具体来讲，评估过程是：选择一个工做组；完成问卷调查和取样工做；结果分析；现场访问；与CMM模型对照分析；依据关键过程域的基本状况列出评估提纲。以上步骤在软件过程评估和软件能力评价题勾勒颇有参考价值的方法，但在具体操做时如下这些特色也值得考虑：

①、在现场访问和考察中，充分运用成熟度问卷和结果分析为依据。

②、以CMM模型做为现场调查的路线图。

③、利用CMM中的关键过程域定义软件过程当中的优势和缺陷，从中发现差别。

④、对关键过程域目标是不是知足的实际状况出发，分析满意程度，写出书面报告。 

　　尽管软件过程评估和软件能力评价有不少类似之处，但因为其目的和结果的不一样，它们之间的差别也是必然存在的，如：

①、软件过程评估和软件能力评价在出发点和目标上的不一样，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不一样。尤为在一些细节规范方面，评估和评价的方法有很大差别。

②、软件过程评估和软件能力评价的结果和结果所起的做用不一样。由于二者的侧重点不同，即便是对同一个应用项目，运用相同的方法，也不会得出相同的结果。

③、被评估和评价单位的态度对评估和评价活动的影响。评估在某种意义上被评估单位的态度较积极，而评价在某种意义上被评价单位的态度可能比较慎重。软件过程评估是在一个开放的、互相协做的环境中进行的，而软件能力评价每每是在有较大的阻力的环境中进行的。

 

（五）CMM的组织保证

　　当人们面对CMM实施时，首先想到的就是人员的构成和各类小组的划分。它是实施CMM的组织保证，是一切活动的基础。CMM在制定软件过程实施中本着尽可能不和具体的组织机构和组织形式相联系的原则，为的是提供一个独立于具体企业而又有普遍指导意义的模型框架。但在实施各类软件关键实践中，不可避免地要涉及到角色和组织结构。因此为了使CMM可以适用各类级别和各类规模的企业，SEI提出了一个相对抽象的组织结构，它与组织、项目、人员（角色）相关联，具备本身特定的术语，并且可能不一样于其余组织所用的名词。例如基本概念中提到的主要的软件工做组的概念。

 

3、 正确的态度看待CMM

　　SEI的CMM并非软件开发的方法学，也不是产品模板，更不是过程法律。CMM是过程改进的途径，是一套指南，帮助你经过持续的重复、测量和提炼，稳步创造与净化开发环境。CMM的假定是：若是你实施一个不断重复、测量和提炼的大纲，做为环境改进的副产物，质量便会天然的提升。不要把CMM设想为一套规则，而应将它理解为一个学科，作事的通常方法。在这套指南下运做，你会发现这里有着广阔的空间，让你剪裁和塑造本身的大纲，以适应组织的特定要求。

　　CMM不采用“用这种方法作这类事”的风格，它也不对由问题的IT组织提供快速的纠正方案。CMM是一个指南针，指导你如何逃离暴风雪。CMM是一个大纲，要求你对整个IT组织的有关部分，从高层领导到软件生产的第一次线工做者，都作出坚决的、长期的实施承诺。成熟的过程不可能在它之间实现。
　　在如何解释CMM建议时，它容许极大的灵活性。CMM意识到，IT组织之间存在着很大的差异。他们的客户不一样，使用的工具不一样，人员智力和专业背景不一样，从事的项目属于不一样的类型，规模大小不一样，要求也各不相同。于是，他们应当以本身的方式走向成熟。在一处活用的东西，在另外一处未必适用。这一点很是重要，中国部分软件公司的前车可鉴也从某种程度上给了咱们建议和经验教训，那就是，要灵活应用CMM，不要幻想一晚上就有成效。
从 CMM 到 CMMI 的映射
　　CMM 到 CMMI 的映射是一个复杂的体系，它涉及到 KPA 重构， KP 的再组织。图 1 只是从整体上描述了 CMM 到 CMMI 的映射关系。

映射分析
　　CMMI 虽然是创建在 CMM 基础之上，二者大部分类似，但仍是有很大差别。从整体上讲， CMMI 更加清晰的说明各过程域和类属实践（ generic practice ）如何应用实施，并指出如何将工做产品归入相应等级的配置和数据管理基线，风险管理策略，验证策略等。 CMMI 包含更多工程活动，如需求开发，产品集成，验证等过程域；过程内容的定义更加清晰，较少强调文档化规程。
如图，在 CMMI2 级中增长了测量和分析 KPA （ Measurement and analysis ），将各测量分析实践（ KP ）归结为一个正式的关键过程域，而在 CMM 中测量分析实践是散落在各等级中的。所以在 CMMI 中更增强调了量化管理，管理的透明度和软件开发的透明度获得了升级。

　　CMMI3 级中增长了需求开发（ Requirements Development ）、技术解决方案（ Technical Solution ）、产品集成（ Product Integration ）、验证（ Verification ）、确认（ Validation ）、风险管理（ Risk Management ）、决策分析和决定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的软件产品工程 KPA 被需求开发，技术解决方案，产品集成，验证，确认 KPAs 所取代；同行评审 KPA 被融入到验证 KPA 中； CMM 中集成软件管理 KPA 所阐述的风险管理在 CMMI3 中造成了一个独立风险管理 KPA 。同时集成软件管理和组间协调 KPAs 合并成集成项目管理 KPA 。合成团队、决定分析和解决方案、组织的一体化环境 KPAs 是全新的，其过程内容在 CMM 中没有说起。
CMMI4 中没有新的过程域，只是对原来的定量过程管理，软件质量管理 KPAs 从新构建为定量项目管理和组织过程性能 KPAs 。
CMMI5 中的技术变动管理和过程变动管理 KPAs 合并为组织革新与技术推广 KPA ，缺陷防范 KPA 从新构建为缘由分析和解决方案 KPA 。
CMM 到 CMMI 的升级
升级前的准备工做

（ 1 ） 回顾 CMMI 模型和其余的 CMMI 信息，肯定如何使 CMMI 最好的知足组织须要

（ 2 ）拟订升级策略。

（ 3 ） 在升级过程当中确保之前用于 CMM 改进的投资获得维持和运用

（ 4 ）将升级事项通告客户

（ 5 ）将对现有过程域和新增过程域的改进费用编入预算，并提供有关改进须要的培训。

（ 6 ）肯定组织升级计划的风险表并管理这些风险，关键要识别 CMM 和 CMMI 之间的差别以及这些差别如何获得支持。

升级的方法：

　　一旦作好了升级前的准备工做，弄清了升级可带来的利益和成本，可执行下列活动进行升级，这些活动是迭代的。

（ 1 ） 选择适合组织最好的 CMMI 模型。 CMMI 覆盖各类知识体，包括项目管理，软件工程，系统工程，集成产品，过程开发供应商来源。按组织的商业目标选择模型。

（ 2 ）选择最适合组织的表示法。 CMMI 有阶段式表示法和连续式表示法，因为 CMM 采用的是阶段式的表示法，许多组织都采起 CMMI 阶段式表示法，若组织对连续式表示法较熟悉，也能够采起连续式表示法。

（ 3 ）将选择的 CMMI 模型与 CMM 对比，肯定须要变动的范畴。具体的对比见上文。 变动的主要活动是对 CMMI 中重组的 KPA 及 CMMI 中新增的 KPA 进行更新。

（ 4 ） 肯定升级会带来的影响。

（ 5 ）向 CMMI 升级因该报高级管理层的承认。

（ 6 ）变动组织目前的过程改进计划以支持 CMMI 升级。过程改进计划要反映出工做的优先级、组织所需增长的新部门。将该计划送交评审，获得关键储金保管者（ key stakeholders ）的许诺和承认，计划要说明升级可能带来的管理风险和进度风险，所需的培训，工具，和服务支持。传达这个计划并保持更新。

（ 7 ）确保对工程过程组，技术工做组及其余相关的员工进行 CMMI 的培训。

（ 8 ）获取 SCAMPI 评估支持。

（ 9 ） 修改每一个项目已定义的过程使其与项目改进计划一致。
（ 10 ）给每一个项目制定升级进度表 不一样的项目升级进度表可能不一样，若是有的升级工做已经完成则该工做能够抛弃。

（ 11 ）执行 SCAMPI 评估，看是否全部的目标过程域和目标获得支持。

处于 CMM 不一样成熟等级的组织所作的具体工做

（ 1 ） CMM1 级：
　　若是组织正使用 CMM 模型致力于过程改进而并处于 CMM1 级，那么组织应该继续用 CMM 模型。在改进的同时，组织将 CMM2 与 CMMI2 进行对比和差别确认，分析这些差别中哪些是对组织有价值的。当组织刚达到 CMM2 级时其主要工做时当即从 CMM2 向 CMMI2 升级。
（ 2 ） CMM2 级，
　　组织应该把其当前的过程改进向 CMMI2 级映射，填补二者之间的差距，从 CMM2 升级到 CMMI2 完成后，在下一步的工做中采用 CMMI 模型进行过程改进。主要有一下几方面

(1) 将 CMM 中分散的测量分析活动集中到 CMMI2 级测量分析 KPA 中，造成一个独立的过程域，提升开发的透明度。
(2) 重定位测量分析 KPA （ Measurement and Analysis ）的共同特征（ common feature ）
测量分析 KPA 重组见表 所示。

　　表示符说明： QPM Co 2 Ac1,3,4,5,6 表示定量过程管理（ Quantitative Process Management ）过程域执行的约定（ Commitment to perform ） 2 和执行活动（ Activities to perform ） 1,3,4,5,6 。
Co 表示执行的约定； Ab 表示执行的能力； Ac 表示执行的活动； SG 表示特殊目标（ Special Goal ）； GG 表示通常目标（ Generic Goal ）；其余可类推。

（ 3 ） CMMI3 级
①将 CMM 软件产品工程 KPA 分解为需求开发、技术解决方案、产品集成、认证、确认 KPAs ，并进行扩充。
②了解 CMMI3 级中新增的决定分析和解决方案、合成团队，组织一体化环境 KPAs ，并填补。
③迭代 CMM2 级的工做。
说明
　　卡内基梅隆大学软件工程研究所推出 CMM Version 2.0 draft C 后就中止了在 CMM 的改进。 CMM 被 CMMI 所取代是大势所趋。许多正在运用 CMM 模型进行软件过程改进的组织纷纷向 CMMI 升级。而 CMMI 模型迄今尚未成熟，卡内基梅隆大学软件工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的产品集中没有关于软件采购方面的内容，估计之后还会推出这个科目。并且从 CMM 向 CMMI 升级也只是处于尝试阶段。组织升级的操做过程，运用 CMMI 模型所带来的效益等信息还很匮乏，这些信息也为未能及时反馈到卡内基梅隆大学软件工程研究所，这也给 CMMI 模型的改进及向 CMMI 的升级工做带来了必定的难度。

关于CMM评估的一些背景资料
　　CMM评估包括5个等级，共计18个关键过程域，52个目标，300多个关键实践。每个CMM等级评估周期（从准备到完成）约需12-30个月。每一级别的评估由美国卡内基梅隆大学的软件工程研究所受权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。国外CMM等级评估生效，只须要主任评估师的签字，既没有某主管单位的批准，也没有盖上公章的证书。显然，国外更看重主任评估师及公司的信誉。

　　取得主任评估师的资格的条件： § 首先要有10年以上的软件开发经验； § 其次要在美国卡内基梅隆大学的软件工程研究所接受培训，培训费用每人约需数万美圆，非美国人加倍； § 第三要通过两次以上CMM评估的全过程实习； § 第四要获得已有主任评估师资格的人推荐。主任评估师的资格并不是终身制，如要继续保持，每一年至少要参加两次CMM评估。 目前全世界一共只有313个主任评估师，大部分在美国，而我国大陆尚未一个主任评估师。因为我国在CMM评估中要聘请外籍主任评估师，因此费用较高。据估计，要经过一个级别的CMM评估，费用是经过ISO9001认证的十多倍。

做业
一、请用图表的形式描述CMM的分级结构？
二、软件过程性能和软件过程能力的主要区别是什么？
三、关键实践的主要描述的是什么？
四、CMM和CMMI的主要区别有哪些？
五、假如你是SQA，你应该具备什么样的心态去看待CMM的评定？