CMMI为软件产品及软件过程提供了一套定量的表示和分析的模型，即软件度量。因此软件度量分为软件产品度量和软件过程度量两大部分。
先简单介绍一下软件产品的度量（我个人认为，软件产品的度量评估比较EASY，重点放在软件过程度量上），由三部分组成：
1.质量要素：包括 功能性，可靠性，易用性，高效性，可维护性，可移植性 六条。
2.评价标准：包括 精确、健壮、通信有效、处理有效、设备有效、可操作等等共22点。以这22点作为上面六条的评判标准。
3.度量元：指软件的需求分析，概要设计，详细设计，CODING实现，设置测试，确认测试，使用维护七个阶段中的度量元素，比如各阶段的里程碑--文档等。
对于软件过程度量，我们先来讨论，在软件过程中，我们最需要掌握这个过程中的什么。
因为我们需要在通过每一个软件过程后，能交付符合该过程需要的结果，即该过程产品，该产品性能是否达到组织的商业目标。为了让这个目标成功，让它所有过程中的行为在整个管理中可以预测，判断现阶段这个过程设计是否合理，我们不仅仅需要主管和经验丰富的开发人员的经验，还需要定量的数据作为分析、参考。并把每个软件过程记录入库，作为今后的统计分析参考数据，这样科学的辅佐开发人员将软件过程控制住。
如何设定并采集参考数据，这些数据如何使用，可以采用那些数据统计、描述工具。下面我举系列例子：
对于一个开发项目，首先我们将其归入某一项目种类中，然后将开发人员人数、级别（如一个P4,两个P3，5个P2等）记录，统计他们对一功能模块（以代码行为标准，乘以其难度系数）的开发时间，在此类数据积累够多时，我们就可以预测并控制下一次遇到此类的项目（或实现该功能模块）大致需要的时间上、下限，并能查找偏差来进行控制，直方图或正态分布图可以有效的表示出这一点，这是开发进度的控制方式之一。
对于软件过程中遇到的偏差以及问题，我们可以采用头脑风暴法，将这些问题罗列出来，用来探测和展示问题的可能原因，鱼骨图可以很形象的将其描述。问题是罗列出来了，但是本方式存在的弊端也很明显，就是缺陷主次不明，时间、资源都是有限的，如何从问题最大的缺陷下手呢，我们可以采用PARETO图将问题展示出来，根据其二八原则，先将缺陷种类中的20%解决，却就解决了80%的问题，这样缺陷解决的过程得以优先排序。
我们可以通过对整个软件过程中的七个阶段进行离散分析，可以得出各阶段中缺陷的发现及解决比例，从而判断出哪个阶段问题最大，将解决重点放在该阶段。比如，如果在分析阶段缺陷比例最大，而后期依次减小至理想状态，这说明本软件过程是非常成功的，反之，如果在测试阶段甚至使用阶段缺陷比例很大，很可能说明这个软件过程在分析、或者构架时就存在很大的问题。
由于俺也接触CMMI不多，无法做到很深入的剖析，但求能起个抛砖引玉的效果，希望有兴趣的朋友一起来讨论研究，共同进步。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
