（二）CMM的主要内容
CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释起组成部分，如图2示。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念，关于内部结构详细描述将在下面CMM内部结构的一栏中进行。
每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如下。
初始级的改进方向是：建立项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过车改进计划等；积极开展软件质量保证活动（SQA）。
可重复级的改进方向是：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为权组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础；建立软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。
已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。
已管理级的改进方向是：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。
优化级的改进目方向是：保持持续不断的软件过程改进。
（三）CMM的内部结构
CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成，每个成熟度等级有着各自的功能。除第一级外，CMM的每一级按完全相同的内部结构构成的，如图3。成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。
在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键古城域的目标。
（四）软件过程评估和软件能力评价
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于法子按缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。
软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们爱进软件过程。
具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与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的知识，而同时又不能放太多的内容使读者浪费太多的时间在这上面。最后采取了一个折衷的办法，那就是尽量满足考试需求的情况下减少篇幅。在此声明，本文所涉及的内容只是本人的预测，并不是说考试范围不会超过本文的内容。所以有时间的朋友还是尽可能的扩大这方面知识面。希望这篇文章对你有帮助，谢谢。
