系统分析员备考之CMM篇

引子：

   CMM理论和知识是最近几年的热点，在最近两年的系统分析员上午试卷中都有一题考察CMM知识的，一般有3-5分的样子。估计未来的系统分析员考试还会有这方面的考题。即使不考，我们的系统分析员也应该掌握这方面的知识，因为将来从事的系统分析与设计的工作也离不开CMM理论和知识，因为即使我们所在的公司不去进行CMM评估，CMM理论知识对于我们不断的进行公司的软件过程改进有一定的借鉴意义，从而有助于软件质量的提高，进而提升公司产品的市场竞争力。
摘要：本文是根据这两年试题中涉及CMM知识而特为广大考友搜集整理的关于CMM的基础知识的文章。主要内容是有关CMM的基本概念、CMM的基本框架和对CMM的正确态度等。希望这篇文章对你有所帮助，谢谢。
摘关键词：系统分析员 系分辅导 CMM 软件能力成熟度模型

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

一、 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模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准，如图1示。一方面软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。另一方面，该标准也可以作为用户对软件组织的一种评价标准，使之在选择软件开发商时不再是盲目的和无把握的。 

 

图 1 软件过程成熟度的级别

CMM的分级结构可以描述为：
①、初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。
②、可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
③、已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
④、以管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
⑤、优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地对促进过程进行改进。
除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向下一级别迈进。CMM体系不主张跨级别的进化。因为从第二级开始，每一个低级别的实现均是高级别实现的基础。
（二）CMM的主要内容
CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释起组成部分，如图2示。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念，关于内部结构详细描述将在下面CMM内部结构的一栏中进行。

图 2 CMM的五个成熟等级

每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如下。
初始级的改进方向是：建立项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过车改进计划等；积极开展软件质量保证活动（SQA）。
可重复级的改进方向是：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为权组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础；建立软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。
已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。
已管理级的改进方向是：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。
优化级的改进目方向是：保持持续不断的软件过程改进。
（三）CMM的内部结构
CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成，每个成熟度等级有着各自的功能。除第一级外，CMM的每一级按完全相同的内部结构构成的，如图3。成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。

图3 CMM的内部结构图

在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键古城域的目标。每一级的关键过程域的详细情况见表1。

表1 关键过程域的分类

（四）软件过程评估和软件能力评价
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于法子按缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。
软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们爱进软件过程。
CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的佛农步骤，如图4示。

图 4 软件过程评估和软件能力评价的步骤

具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据关键过程域的基本情况列出评估提纲。以上步骤在软件过程评估和软件能力评价题勾勒很有参考价值的方法，但在具体操作时以下这些特点也值得考虑：
①、在现场访问和考察中，充分运用成熟度问卷和结果分析为依据。
②、以CMM模型作为现场调查的路线图。
③、利用CMM中的关键过程域定义软件过程中的优点和缺陷，从中发现差异。
④、对关键过程域目标是否备满足的实际情况出发，分析满意程度，写出书面报告。
尽管软件过程评估和软件能力评价有很多相似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如：
①、软件过程评估和软件能力评价在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。尤其在一些细节规范方面，评估和评价的方法有很大差异。
②、软件过程评估和软件能力评价的结果和结果所起的作用不同。因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。
③、被评估和评价单位的态度对评估和评价活动的影响。评估在某种意义上被评估单位的态度较积极，而评价在某种意义上被评价单位的态度可能比较慎重。软件过程评估是在一个开放的、互相协作的环境中进行的，而软件能力评价往往是在有较大的阻力的环境中进行的。
（五）CMM的组织保证
当人们面对CMM实施时，首先想到的就是人员的构成和各种小组的划分。它是实施CMM的组织保证，是一切活动的基础。CMM在制定软件过程实施中本着尽量不和具体的组织机构和组织形式相联系的原则，为的是提供一个独立于具体企业而又有广泛指导意义的模型框架。但在实施各种软件关键实践中，不可避免地要涉及到角色和组织结构。所以为了使CMM能够使用域各种级别和各种规模的企业，SEI提出了一个相对抽象的组织结构，它与组织、项目、人员（角色）相关联，具有自己特定的术语，而且可能不同于其他组织所用的名词。例如基本概念中提到的主要的软件工作组的概念。
三、 正确的态度看待CMM
SEI的CMM并不是软件开发的方法学，也不是产品模板，更不是过程法律。CMM是过程改进的途径，是一套指南，帮助你通过持续的重复、测量和提炼，稳步创造与净化开发环境。CMM的假定是：如果你实施一个不断重复、测量和提炼的大纲，作为环境改进的副产物，质量便会自然的提高。不要把CMM设想为一套规则，而应将它理解为一个学科，做事的一般方法。在这套指南下运作，你会发现这里有着广阔的空间，让你剪裁和塑造自己的大纲，以适应组织的特定要求。
CMM不采用“用这种方法做这类事”的风格，它也不对由问题的IT组织提供快速的纠正方案。CMM是一个指南针，指导你如何逃离暴风雪。CMM是一个大纲，要求你对整个IT组织的有关部分，从高层领导到软件生产的第一次线工作者，都做出坚定的、长期的实施承诺。成熟的过程不可能在已也之间实现。
在如何解释CMM建议时，它允许极大的灵活性。CMM意识到，IT组织之间存在着很大的差别。他们的客户不同，使用的工具不同，人员智力和专业背景不同，从事的项目属于不同的类型，规模大小不同，要求也各不相同。因而，他们应当以自己的方式走向成熟。在一处活用的东西，在另一处未必适用。这一点非常重要，中国部分软件公司的前车之鉴也从某种程度上给了我们建议和经验教训，那就是，要灵活应用CMM，不要幻想一夜就有成效。
小结
本文只是根据这两年的试题和自己的预测向广大系分考友提供一些CMM方面的知识。CMM不是重点，但也有可能会考到一些知识，如基本概念等。在搜集资料和整理着篇文章时，遇到了一个矛盾，那就是：我要提供足够的资料以使读者不必花费金钱再去买一本书就可以复习有关CMM的知识，而同时又不能放太多的内容使读者浪费太多的时间在这上面。最后采取了一个折衷的办法，那就是尽量满足考试需求的情况下减少篇幅。在此声明，本文所涉及的内容只是本人的预测，并不是说考试范围不会超过本文的内容。所以有时间的朋友还是尽可能的扩大这方面知识面。希望这篇文章对你有帮助，谢谢。