CMM第一级:初始级
特点:项目的成功与否不是靠合理有效的软件流程来保证的,而是靠个人能力来保证的。无论组织内部的管理高层,还是外部的客户,都无法预见其项目的前景和结果,更不要说将结果控制在预算和进度之内。
要求:初始级没有任何KPA,这一点与其他各级不同。在CMM中,只要从事软件生产和维护,该软件组织就自动达到第一级。而再往上就要经过CMM 评估了。
注意:不要把未经CMM 评估与处于初始级两者混淆,有些软件组织虽然没有经过CMM 评估,但以CMM的要求看,也许远远超出初始级的标准。
CMM第二级:可重复级
软件组织能力不再受制于个人,但是也非组织拥有,而是依赖于项目组。项目组从以往的类似项目中归纳成功经验和失败教训,并以此作为指导新项目开展的依据,从而在很大程度上,可以保证类似项目的再次成功。
用一个词来概括,那就是“有纪律的”。项目组在其范围内,实施基本的项目管理,并对进度、预算和产品功能进行计划和跟踪,这样,项目的进展处于一种基本可控的状态。
一个软件项目不再是一个“魔术般”的黑箱子,而是一些连续的黑箱子。
实施CMM2
管理层的表率作用。管理层人员必须首先注重自身流程的纪律化。
有些项目经理或者质量管理人员,往往首先看到的是“程序员”的自由散漫,一要流程改进,就要求“程序员”遵循这个规矩那个条例,就要写文档,开大会;这不仅违背了CMM 的初衷,更败坏了流程改进的名声
缺乏群众基础的流程改进,无法取得实效
CMM2 KPA
需求管理(Requirement Management)
软件项目计划(Software Project Planning)
软件项目跟踪和监控(Software Project Tracking and Oversight)
软件转包合同管理(Software Subcontrack Management)
软件质量保障(Software Quality Assurance)
软件配置管理(Software Configuration Management)。
CMM第三级:已定义级
是在整个组织范围内,开发和维护软件的流程,包括管理的和工程的,以及这些流程的集成,已被明确地书面定义。
各个项目就可以依据这一流程标准进行裁剪,明确其中每一项具体任务和工作的输入、输出、开始和完成的判断标准和条件、操作过程、以及验证措施等等。
已定义级不再是一些连续的黑盒;由于每一项具体任务和工作都是可见的,因此外部人员可以随时深入到“黑盒”中,了解项目内部的进展情况,从而也使项目的及时调整和降低风险成为可能。
CMM3特点
不同项目和历史项目的成功经验和失败教训可以相互比较
已定义级组织的能力是属于组织的,而不是项目团队的,更不是成员个人的。
为了保证整个组织流程的标准和一致性,通常会有一个跨项目的团队,比如SEPG(Software Engineering Process Group)负责整个组织的流程活动。
为了使组织内每一个人明确自己的角色和权责,并能有效实施,整个组织范围内的培训是必不可少的。
要建立起这样的流程,对个人的工作要授权,不要过分刻板。
常有人把CMM 解释为刻板的文档和僵硬的工作规范,这样的理解至少是极端化的。刻板僵硬,以及随之而来的官僚作风,并不是CMM天生使然,而是对CMM的曲解和误用。
CMM3 KPA
组织过程焦点(Organization Process Focus)
组织过程定义(Organization Process Definition)
培训大纲(Training Program)
集成软件管理(Integrated Software Management)
软件产品工程(Software Product Engineering)
组间协调(Intergroup Coordination)
同级评审(Peer Reviews)
CMM第四级:受管理级
定性的比较发展为定量的比较,从而使得人们(无论是内部的,还是外部的)可以更加科学、客观的预测软件项目的进度、预算和质量。
定量是指在一定的概率内使结果误差控制在一定的范围内。如:存在90%的可能,进度误差不超过20%。
处于受管理级的组织能及时采取纠正和弥补措施。
确定要度量些什么。
依靠收集和挖掘自身历史数据进行软件度量。