CMM基本概念

CMM由低至高共分为5个级别：初始级、可重复级、定义级、管理级和优化级

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）

将各种能力成熟度模型（即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM）整合到同一架构中去，由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。

CMMI框架包括软件能力成熟度模型CMM 2.0草案，系统工程能力成熟度模型，软件采购能力成熟度模型，继承产品和过程开发等。

CMMI的:“关键过程域”25个，“目标”105个， “关键实践”485条。

CMMI的评估方式：
自我评估：用于本企业领导层评价公司自身的软件能力。
主任评估：使本企业领导层评价公司自身的软件能力，向外宣布自己企业的软件能力

CMMI的评估类型：
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估（软件能力成熟度等级评估）。

CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益

软件评价与测试的作用

评价是对软件开发过程中产生的各种系统规格和模型进行的验证活动。测试则是一种基于机器的对代码执行、确认的活动。大部分组织对评价和测试的定义都相对狭义，一般是指对代码执行物理测试用例的活动。事实上，很多公司甚至直到编码已经开始时才指定或安排测试人员。更有甚者，他们将这一活动的范围仅仅限于功能测试，也许有时做一下性能测试。这种观点在目前的CMM有关评价与测试的描述中被进一步强调，这就是SPE，软件产品工程KPA。在SPE KPA活动中，活动5、6、7，仅仅用了基于代码的测试作为例子，只明确地提到了功能测试。

CMM只是进一步将评价和测试的部分思想进行融合，用一个特殊的评价技术来代替，这个技术就是CMM中的一个KPA，同行评审。这也意味着，在提交代码之前，唯一可干的评价就是同行评审，且已经足够了。事实上，对于一件事情的评价和测试的步骤包括：(1)定义成功准则；(2)涉及覆盖这些准则的用例；(3)执行用例；(4)验证结果，验证所有的内容都已覆盖。同行评审只是提供了一个基于纸面的测试机制。它既不能从根本上提供成功准则，也不能提供任何正式的机制以支持用例定义以用于同行评审中。同行评审本质是主观的，因此，基于误解使程序员将缺陷引入产品，而到同行评审时，基于同样的误解，也使得人们无法发现这些缺陷。

评价和测试的一个相对坚固的内涵范围必须包括项目在开发周期每一个阶段的每一个交付产品。它也必须考虑每个交付产品的每一个预期特性。而且必须包括每一个评价/测试步骤。下面我们看两个例子：评价需求和对一个设计的评价。