CMM是一个大家关注已久的话题。然而，知道的人多，懂得的人少。
口头谈论的人多，付诸实施的人少。
认为CMM是用来认证的人多，真正把CMM当成指导“过程开发和改进”的人少。 如果CMM是一个有情绪的人，我想他会深感失落；他也许会说：别仅仅把我当成一个用来认证的标准，请让我在组织的“过程开发和改进”中起到积极的作用。
本文阐述如何从“过程开发和改进”角度，更加积极地理解CMM，并浅谈如何对CMM进行剪裁。本文的基本观点是：CMM是过程开发和改进的需求和测试方案。写作仓促，不妥之处敬请斧正。
一、 软件过程也是软件
软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出：软件过程也是软件。
软件有一个开发的过程，软件过程也有一个开发的过程。
软件开发产出软件产品，软件过程开发产出过程产品。
软件开发可以是一个演进过程，使软件产品不断更新升级，软件过程开发也可以是一个演进过程，使过程不断升级，过程能力成熟度不断提高。
由此看来，从软件过程开发角度理解CMM，是非常自然的。
二、从软件过程开发和改进角度理解CMM
1、 软件过程的概念模型
开发软件，先要分析出该软件的概念模型。要开发软件过程，也要首先分析其概念模型。笔者用UML类图的语法描述之（如下图所示）：
从图中可以看到，
有3个要素：人，活动，工件。
人执行活动，活动产出工件。
人执行某些活动需要使用先前的工件。
活动由人执行，所以活动对人存在依赖关系，制定软件过程时，必须考虑员工的素质，另外，对员工进行培训也是不错的选择。
工件由活动产生（或再加工），所以工件对活动存在依赖关系，活动的具体实施情况，直接影响着工件的质量。
人执行某些活动需要使用先前的工件，以产生新的工件或对原工件进行再加工，所以人对工件存在依赖关系，所需工件没有产生，就会限制下面的其他活动的进行。
由上面所说的依赖关系，演生出了：人对人的依赖，活动对活动的依赖，工件对工件的依赖。
所有这些依赖关系 都是我们制定软件过程时要考虑的，只有合理处理它们，才能使软件过程流畅高效。
好了，上面描述了软件过程的概念模型。不难理解，开发软件过程就是要依据实际情况，定义出诸如“由谁在何时执行何种活动产出何种工件” 的复杂模型。如果再进一步将其文档化，在企业内部标准化，它就成为企业级的软件过程了。
2、 CMM是软件过程开发的需求
应当指出，软件过程有以角色为中心、以活动为中心和以工件为中心3种流派。而以活动为中心的过程是比较流行的，比如RUP就是一种以活动为中心的过程（而且还引入工作流来支持并行活动）。
再看CMM，它最基本的概念是关键实践和关键过程域（如下图所示）：
关键实践，对相关活动和设施的描述，仅描述应当“做什么”，而不是强制规定“如何做”。
关键过程域，为达到一定目标，相互关联的若干软件实践活动和有关基础设施的集合。
那么如何理解CMM是软件过程开发的需求呢？
因为关键实践描述了应当“做什么”，而不是强制规定“如何做”，所以可以认为，关键实践是关键活动的需求描述。
关键实践就是过程开发的需求项。
关键实践被分组，成为一些关键过程域。相当于需求项的分组，便于管理。
关键过程域的实施都是为了达到一定的目的，从需求的层次角度（请参考Wiegers著陆丽娜译《软件需求》一书），可将“目的”理解为“业务需求”，将关键过程域理解为“用户需求”，前者由后者来实现。
CMM通过定义的这些关键实践和关键过程域，覆盖了我们要开发的软件过程的主要目的（比如需求管理、产品工程）。
因此说，CMM是软件过程开发的需求。
3、 CMM是软件过程开发的测试方案
再看软件过程的测试。
从原理上，需求就是测试依据。软件工程中的一条基本原理就是：依据需求进行测试。
从实施上，我们通常依据需求来编写测试用例，然后执行这些测试用例。
Brain Marick更是表述了他的具有革命性的观点：“我并不想写出一套用于捕捉用户愿望的需求，取而代之的是，我要写出一套测试，一旦这些测试能够通过，产品就能使她满意。”尽显大师风范。
CMM提供了大量提问单（如下图所示），和测试用例的概念对应得很完美，我们通过这些提问单就可以轻松测试出每一个关键实践进行得怎么样，进一步测试出每个关键过程域完成得如何，该组织的软件过程的能力成熟度有多高。
因此说，CMM是软件过程开发的测试方案。
其实，“CMM是软件过程标准”的说法，和“CMM是软件过程开发的测试方案”的说法颇有几分神似。
4、 CMM是软件过程改进的框架
软件开发中，为了降低风险，需求项会被分为不同的优先级，高优先级的需求要先完成，进行演进开发。优先级划分的依据是：
需求项之间的依赖关系，被其他需求项依赖的需求项的优先级高。
需求项的重要程度，重要的需求项优先级高。
而软件过程也要根据企业的具体情况，循序渐进地改进，CMM这个过程开发的需求也特别照顾到了这一点：
CMM本身就将作为“需求项分组”的关键过程域，依据重要性和相互依赖关系，划分了优先级。
依据优先级的高低，将所有“需求项分组”进一步划分为4组，分别命名为可重复级、已定义级、已管理级和优化级。
再加上一个过程混乱的初始级，成为CMM的5级成熟度模型（如下图所示）。
5、 CMM的剪裁
需要说明的是，软件过程的改进会涉及到软件过程的度量等一系列活动，并不属于本文的讨论范围。在此仅单纯讨论CMM的剪裁。
框架者，通用的东西也。既然说“CMM是软件过程改进的框架”，那么可以对其进行剪裁应当是“题中应有之义”。
剪裁之前，当然要先进行需求捕获，以明确软件过程的具体需求。比如可以首先明确软件企业的环境，然后向所有涉及人员收集信息。
软件企业环境的例子有：开发人员素质，合作单位素质，待开发软件的类型、规模、重要程度等，这些因素都会影响到将来软件过程的制定。
涉及的人员的例子有：用户，开发人员，合同确定者和投标者等，从他们那里收集对软件过程的要求。
掌握了企业的实际情况之后，就可以对CMM进行剪裁了。笔者认为，至少可以从以下方面对CMM进行剪裁：
既然CMM是依据优先级高低而分组的关键过程域的集合，我们根据实际情况的不同，可能对优先级重新划分。比如学习型企业的理念非常适合以技术为导向公司，将关键过程域“培训活动”提升到更优先的级别，首先加以实施。
顾名思义，有关键过程域，就有非关键过程域，但依据具体情况，会有可能需要这些“非关键过程域”。比如，国内比较重视业绩考核，可以增加一个过程域“业绩考核”。
关键过程域由一组关键实践组成，可以依据具体情况，增加或减少关键实践。比如关键过程域“软件子合同管理”中，可以增加关键实践“律师事务所辅助监督”，以满足重要的跨国合同的执行需要。
三、 总结
笔者认为，流行的“CMM是软件过程标准”的说法稍显被动消极，而从软件过程开发角度去理解CMM，更加积极，更加有利于实践中充分利用CMM：
这种理解角度以“软件过程也是软件”为理论基础，非常自然
有利于广大软件开发人员对CMM的理解和认同
有建设性，利于启发人们将CMM做为实践指导
这种理解角度和“CMM是软件过程标准”的说法是兼容的
总之，目的只有一个——充分发挥CMM的作用。
参考文献
Osterweil 《Software Processes are Software Too》
温昱 《RUP的剪裁原理和剪裁过程》
何新贵等 《软件能力成熟度模型》
Wiegers著 陆丽娜等译 《软件需求》
另外，从上海科技网（http://www.stcsm.gov.cn）获取了一些CMM图片