软件能力成熟度模型

领测软件测试网 软件能力成熟度模型
1 过程成熟度框架
关于通过运用新的软件方法和技术提高生产率和质量的期待经过了20 年仍未实现
工业和政府组织终于意识到他们的基本问题在于对管理其软件过程无能为力[DOD87] 在无纪律的混乱的项目状态下即使有较好的方法和工具也难以从中获益在许多组织中
项目往往一延再延而经费预算则一增再增[Sisgel90] 在这类情况下组织常常是拿不出
帮助项目避免这些问题所需要的基础设施和支持办法
不过即使在无纪律的组织中个别软件项目仍能生产出优秀产品这些项目的成功一
般是通过专设的工作组的杰出努力而不是通过重复使用这个组织的具有成熟软件过程的经
验的方法在缺乏全组织范围的软件过程的情况下能否取得重复结果完全取决于能否是同
样人员去做下一个项目单纯建立在可得到特定人员上的成功不能为整个组织生产率和质量
的长期提高打下基础只有通过在不断为有效软件工程和管理惯例建立过程基础设施中所作
的坚持不懈的努力才能不断改进
1.1 不成熟和成熟软件组织的比较
在确定合理的过程改进目标时需要了解不成熟软件组织和成熟软件族之间的区别
在不成熟软件组织中软件过程一般由实践者及其管理者在项目进程中临时拼凑即使已规
定了某软件过程它业的不到严格遵守和贯彻不成熟的软件组织是反应式的通常经理们
致力于解决眼前危机称为消防由于进度和预算不是基于切实可行的估计因而拖进度
和超预算已成惯例当硬性规定时限时为满足进度要求常在产品功能和质量上作出让步
在不成熟组织中不存在判断产品质量或者解决产品或过程问题的客观基础因此产
品质量难以预测当项目进度滞延时常压缩或取消诸如审查和测试之类旨在提高质量的活
动
一个成熟如软件组织具有全组织范围的管理软件开发和维护过程的能力软件过程备准
确地传达到现有职员和新雇员工作活动均按照安排的过程进行强制性的过程是适用的
[Humphrey 91b] 而且和实际工作的方式相一致必要时对这些已定义的过程进行更新并
且通过可控的先导性试验和或费效分析进行改进在已定义的过程中整个项目和组织
的所有的岗位及其责任都是清楚的
成熟组织中经理监控软件产品的质量和顾客的满意程度在判断产品质量和分析产品
及过程问题方面有可观的定量的基础进度和预算是基于以前的表现因而是切实可行的
通常能达到产品的成本进度功能和质量的预期结果一般之所以一个规范的过程得到
一致遵循是因为所有的参加者都了解这样做的价值而且有着支持该过程的必要基础设施
要想利用这些有关不成熟和成熟软件组织的观察结果需要构造一种软件过程成熟度框
架该框架描述一条从无序的混乱的过程到成熟的规范的软件过程的演进途径若无此
框架改进大纲可能显得无效因为尚未建立起支持连续改进的必要基础软件过程软件
过程性能和软件过程成熟度等概念集成一体就形成了软件过程成熟度框架在下面几段定
义中所有这些概念
1. 2 构成过程成熟度基础的基本概念
根据Webster 韦柏字典过程process 是指生产某物时的操作体系能达到终点
或得到结果的一系列的活动变更或功能IEEE 把过程定义为针对给定目标所执行
的一连串步骤[IEEE-STD-610] 所以软件过程可以定义为人们用已开发和维护软件及
其相关产品例如项目计划设计文件代码测试用例用户手册等等的一组活动
方法惯例和变换随着一组织走向成熟其软件过程得到更好的定义并在整个组织内得
到更一致的实施
软件过程能力描述通过遵循软件过程能够实现预期结果的程度一个组织的软件过程能力提供一种预测该组织承担下一个软件项目时最终可能的预期结果的方法
软件过程性能表示遵循软件过程所达到的实际结果所以软件过程性能侧重于达到的
结果而软件过程能力则侧重于预期结果由于特定项目的属性和执行该项目的背景所限
该项目的实际性能不可能充分反映组织的整个过程能力即项目的能力受限于它的环境例
如在应用领域所采用的技术上的重大改变可能造成该项目成员因知识所限使得他们的项目
能力和性能达不到该组织的整个过程能力
软件过程成熟度是特定过程得以明确地定义管理测量控制和生效的程度成熟度
意味着能力上的增长潜力并且表明组织的软件过程的丰富程度和它在整个组织的项目中运
用时的一致性在成熟组织中通常通过形成文件和进行培训是全组织有关人员对软件过程
都能很好了解并且使该过程得到其使用者不断监控和改进成熟软件过程的能力是已知的
软件过程成熟度意味着由于运用组织的软件过程使过程规范性协调地增强从而是组织的
软件过程所导致的生产率和质量能随时间的推移得到改进
随着软件组织的软件过程成熟度的提高组织通过方针标准和组织机构将其软件过程
制度化制度化需要建立一种支持业务活动的方法惯例和规程的基础设施及社团文化使
得在最初规定方法惯例和规程的人员离去后这些方法惯例和规程仍能继续下去
1. 3 能力成熟度模型概述
尽管软件工程适和经理通常都非常清楚存在的问题但他们对哪项改进最为重要可能
意见不一致如果对改进工作没有一项有组织的改进策略,要在管理者和专业人员间就首先
需进行哪些改进活动形成一致意见是很困难的为了使过程改进工作能不断取得成效必须
设计一条发展路径使组织的软件过程成熟度按阶段逐步提高软件过程成熟度框架
[Humphrey 87a]将这些阶段排序使每个阶段上的改进能为下一阶段的改进打下基础于是
根据软件过程成熟度框架描绘出的改进策略给过程不断改进的历程提供了一份导引图它
指导组织前进并标示出其缺陷它的目的不在于对有麻烦的项目提供快速解决措施
软件能力成熟度模型为软件组织提供指导指导软件组织如何加强对期开发和维护软件
的过程的控制以及如何逐渐形成一种软件工程和软件管理的优秀文化CMM 的设计是为了指
导软件组织通过确定当前的过程成熟度以及识别软件质量和过程改进方面的少数几个关键
问题来选定过程改进战略通过致力于一些有限的活动和进取性工作去实现改进战略一个
组织就可以稳步地改进其组织范围的软件过程从而使其软件过程能力不断持续提高
CMM 的分阶段结构的基础是已经存在了60 年的产品质量的原理1930 年Walter
Shewart 提出了统计质量学说他的学说得到W.Edards Deming[Deming86]和Joseph
Juran[Juran88,Juran89]进一步发展和成功验证SEI把这些原理运用于成熟度框架这种
框架为软件过程的定量控制奠定了项目管理和工程化基础这也正是过程持续改进的基础
运用了这些质量原理的成熟度框架首先见诸于Philip Crosby的著作Quality is Free
质量是免费的[Crosby79] Crosby 的质量管理成熟度粗框架采用质量惯例描述了5 个
渐进的阶段在IBM的Watts Humphrey 指导下Ron Radice和他的同事把这种成熟度框架
运用到软件中[Radice85] 1986年Humphrey 把这种成熟度框架带到软件工程研究所补充
了成熟度等级的概念为成熟度框架目前在整个软件业界的使用奠定了基础
在SEI的技术报告[Humphrey87a Hamphrey87b] 论文[Humphrey88]和Humphry 的著作
Managing the software Process 管理软件过程中描述了Humphry的成熟度框架的早
期版本最早的成熟度问卷于1987 年发表作为一种工具向软件组织提供表征其软件过
程成熟度的特性的方法1987 年提出了两种方法即软件过程评估和软件能力评价用
于评定软件过程成熟度1990 年以来SEI 在政府和工业界众多人员的帮助下根据在软件过程改进中应用此模型的多年经验进一步扩充和细化了它
2 软件过程成熟度的五个等级
过程的不断改进基于许多小的渐进的步骤而不是革命性的创新[Imail86] CMM 提
供了一个框架将这些渐进步骤组织成五个成熟度等级作为过程不断改进的递进基础这
五个成熟度等级定义了一个顺序尺度用以度量组织软件过程成熟度和评价其软件过程能
力这些等级还能帮助对其改进工作排出优先次序
成熟度等级是妥善定义的通向成熟软件过程的渐进平台每一个成熟度等级为过程继续
改进提供一个台基每一等级包含一组过程目标当目标得到满足时软件过程的一个重要
构件也就稳定下来每达到成熟度框架的一个等级就建立起软件过程的不同的构件导致
组织过程能力的增长
将CMM组织成如图2.1 所示的五个等级对旨在增加软件过程成熟度的改进行动排出了
先后次序图2.1 中带有标注的箭头指出在成熟度框架的每一步骤上组织将加以制度化的
过程能力的类型
下列的五个成熟等级的特性突出说明在每个等级上的主要过程变化
1 初始级 软件过程的特点是特设的偶尔甚至是混乱的几乎没有什么过程是经过
定义的项目的成功依赖于个人的努力
2 可重复级 建立了基本的项目管理过程以便跟踪成本进度和功能读必要的过
程纪律已经就位使具有类似应用的项目能重复以前的成功经验
3 妥善定义级 管理活动和工程活动两方面的软件过程均已形成文件加以标准化并
集成到组织的标准软件过程中全部项目均采用供开发和维护软件用的组织的标准软件过程
的经批准的剪裁版本
4 定量管理级 有关软件过程和产品质量的详细度量资料得到采集无论软件过程还
是产品均得到定量了解和控制
5 持续优化级 能利用来自过程的以及来自先导性创新思想和新技术的定量反馈信息
持续改进过程
2. 1 成熟度等级的行为特征
等级2 到等级5 成熟读的特征可以通过以下几方面表述组织为建立活改进软件过程
而进行的活动围绕每个项目所进行的活动和所形成的跨各项目的过程能力这里之所以列
出等级1 的行为特性是为了给较高成熟度等级提供过程改进比较的基础
2.1.2 等级1 初始级
在初始级上组织一般不提供开发和维护软件的稳定环境一个组织在缺乏健全的管理惯
例时会由于无效的策划和反应一驱动式承若体系而降低由良好的软件工程惯例带来的效
益
情况紧急时项目一般会抛弃预定的规程并且转到编码和测试上去项目的成功完全依
赖于有一个杰出的经理及一支有经验且能力强的软件队伍偶尔有能力和权威的软件经理
能经受住他们在软件过程中走捷径的压力但是当他们离开项目后他们能是过程稳定的影
响也随之消失甚至一个强的工程过程也不能克服由于缺乏健全的管理惯例所造成的不稳
定等级1组织的软件过程能力是不可预测的因为软件过程随着工作推进经常被改变或修
订即过程是特设的进度预算功能度和产品质量一般是不可预测的过程性能依赖
于个人的能力且随个人内在的技能知识和动机的不同而变化等级1 组织几乎没有明显
的稳定的软件过程只能通过个人的能力而不是组织的能力去预测性能
2.1. 2 等级2 可重复级
在可重复级上建立起了管理软件项目的方针和实施这些方针的规程对新项目的策
划和管理是以类似项目上的经验为基础在通向等级2 的过程中一个目标是使软件项目的
有效管理过程制度化这使得组织能重复在以前项目上所开发的成功惯例文件化的已实
施的经过训练的度量过的和能改进的
在第2级组织中项目设置了基本的软件管理控制切实可行的项目承若是基于对以前
项目的观察结果和当前项目的需求项目的软件经理跟踪软件成本进度和功能度假如在
满足承诺方面有问题一旦出现就可识别软件需求和为实现需求而开发的工作产品形成了
基线并且其完整性受控软件项目标准均已确定并且组织确保准切地执行这些标准如
果有分保商软件项目与他们共同努力建立一种强有力的顾客供方关系
等级2组织的软件过程能力可概括为有纪律的因为软件项目的策划和跟踪是稳定的并
且能重复以前的成功经验由于遵循了以前项目的表现为基础的切实可行的计划项目过程
处在项目管理体系的有效控制之下
2.1.3 等级3 妥善定义级
在妥善定义级上全组织的开发和维护软件的标准过程包括软件工程过程和软件管理
过程已形成文件而且这些过程被集成为一协调的整体在整个CMM中均称此标准过程为
组织的标准软件过程等级3 上所建立的过程被用来适当时经更改帮助软件经理和技
术人员更有效地工作组织通过使其软件过程标准化可以有效利用软件工程惯例在等级3
的组织里有一个负责本组织的软件过程活动的组例如软件工程过程组SEPG [Fowler90]
实施全组织的培训大纲以保证职员和经理具有履行其职责所必须的知识和技能
项目通过剪裁组织的标准软件过程建立他们自己的已定义的软件过程以说明项目独有
的特征在CMM 中这种剪裁后的过程称作项目定义软件过程一个已定义的软件过程包含
一组协调的集成的妥善定义的软件工程过程和管理过程妥善定义的过程可表征为具有
已准备就绪的用以开展工作的判据输入标准和规程验证机制例如同行审查输出
以及完成判据因为软件过程已妥善定义管理者就能洞察所有项目的技术进展
第3 级组织的软件过程能力可概括为标准和一致的因为无论软件工程活动还是管理活
动过程都是稳定的和可重复的在所建立的产品线内成本进度和功能度均受控制并且
软件质量受到跟踪这种过程能力建立在整个组织范围内对规定的软件过程中的活动岗位
和责任的共同理解之上
2.1.4 等级4 定量管理级
在定量管理级组织对软件产品和过程都设置定量的质量目标作为组织度量大纲的一
部分针对跨所有项目的软件过程活动测量生产率和质量利用一个全组织的软件过程数据
库收集和分析从项目定义软件过程得到的数据在等级4上软件过程配备有妥善定义的和
一致的度量这些度量为定量地评价项目的软件过程和产品打下基础,项目通过降旗过程性能的变化限制在定量的可接受的范围之内实现对其产品和过程的
控制可以将过程性能方面有意义的变化与随机变化噪声区别开来特别是在所建立的
产品线内为提升到新应用领域的知识层次而带来的风险是已知的并得到精心的管理
第4 级组织的软件过程能力可概括为可预测的因为过程得到测量并在可度量的范围内
运行该等级的过程能力使得组织能在度量的限制范围内预测过程和产品质量的趋势当超
过限制范围时采取措施予以纠正软件产品具有可预测的高质量
2.1.5 等级5 持续优化级
在持续优化级整个组织致力于不断的过程改进为了预防缺陷出现组织有办法是别
出弱点并预先加强过程利用软件过程有效性方面的数据对新技术和组织软件过程的更改建
议进行费效分析识别出采用最佳软件工程惯例的技术创新并在整个组织推广
在第5级组织中软件项目组将分析缺陷以确定其发生的原因为了防止已知类型的缺
陷再次出现他们会评价软件过程并且把经验教训告知其它项目
等级5组织的软件过程能力可表征为不断改进因为这些组织为该近期过程能力而不断
进取从而不断改善期项目的过程性能为了实现改进即通过现有过程的第金也通过那
些采取新技术和新方法的革新
2.2 理解成熟度等级
CMM 是一种叙述性模型在此意义下它描述那些预期用于表征某具体成熟度等级组织
的本质或关键属性CMM 使一个规范模型在此意义下它的详细惯例描述组织在政府
合同环境中从事大规模项目时预期具有的行为规范模型的特征这样一来CMM就处在足够
的抽象层次上使它不会不适当地限制一个组织如何是使软件过程CMM仅描述那些通常预
期的软件过程的本质属性
在任何运用CMM的环境中均应该注意对于惯例的合理解释当组织的业务环境明显地
不同于大型合同组织的业务环境时必须运用所掌握的专业判断力合理地解释CMM
CMM 不是处方它并不告诉组织如何进行改进CMM 描述在每个成熟度等级上的组织特
征而没有给出达到那个成熟度等级的具体方法从等级1 到等级2 可能需用几年的时间
而在其它等级见得升迁通常花费约2 年时间
软件过程改进发生在以下背景中组织的战略计划和经营目标它的组织机构所使用
的技术它的社会文化和它的管理体系CMM侧重于全面质量管理工作的过程方面成功的
过程改进意味着涉及软件过程之外的其它方面例如与改变组织文化有关的人员问题改
变组织文化使过程改进得以实现并且制度化
2.2. 1 理解初始级
尽管等级1 组织的特征常常表现为其过程是特定的,甚至是混乱的但他们也常常开发
出能工作的产品只不过它们可能会超过预算和拖延进度等级1组织的成功依赖于组织中
人员的能力和奋斗当然对所有成熟度等级的组织来说选择雇用培养和或留住
有能力的人都是重要议题但它们已大大超出了CMM 的考虑范围
2.2. 2.2.2 理解可重复级和明确定义级
随着项目规模和复杂性的增长注意力从技术问题转向组织问题和管理问题过程
成熟度的焦点问题[Siegel 90 DOD87 GAO-92-48] 通过将最优秀的员工的经验教训纳入
文件化的过程通过培育为有效执行这些过程所需的技能通常以培训的方式以及通过
不断向从事该作业的人们学习而进行的持续改进过程能使人们工作得更为有效
为达到等级2 管理者必须致力于他们自己的过程使之成为有纪律的软件过程等级2
是等级3 的基础因为在处理等级3上的技术和组织问题之前侧重点放在忙于改进其过程
的管理者上在实现等级2 的过程中通过将项目管理过程编制成问兼并遵照执行管理者
建立起领导地位
在等级2 组织中不同项目的过程可能不同为了达到等级2 对组织方面的要求是拿
出方针在建立合适的管理过程中指导项目文件化的规程是协调的过程的基础在培训和
软件质量保证工作的帮助下能在全组织范围内使这些过程制度化
通过对完整的软件过程加以定义集成和文件化使等级3建立在这种项目管理基础之
上在此情况下集成意味着一个作业的输出顺利地成为下一个作业的输入当作业存在不
匹配现象时在软件过程的策划阶段它们就得到识别和处理而不是等到实施过程中遇到它
们时等级3 的一个挑战是如何做到构造的过程使软件人员能在一定的自由度下工作
[Humphrey 91b]
2.2.3 理解定量管理级和持续优化级
成熟度等级4 和等级5 对软件业来说还是一个相对未知的领域仅有少数几个等级4
和等级5 的软件项目和组织[Humphrey 91a Kitson902] 由于现有的实例太少还不能得出
等级4和等级5组织特征的普遍性结论通过与其它行业类比和利用软件业界中显示出这些
等级过程能力的少数例子给这些等级的特征作了规定
等级4和等级5的许多特征建立在图2.2说明的统计过程控制概念的基础上朱兰三部
曲图[Juran 88]显示过程管理的主要目标
Juran将质量管理分成三个基本管理过程[Juran 88] 质量策划的目的是向操作队伍
即软件生产者提供生产出能满足顾客需求的产品的方法操作队伍生产产品但由于质量
缺陷不得不做某些返工这种浪费是经常性的因为过程就是那样安排的执行质量控制
只是为了防止事情恶化过程中的偶发尖峰如图2.2所示代表消防活动经常性的浪费
提供了改进的机会抓住这个机会进行工作就叫质量改进
质量改进的首要责任也是等级4 的关注焦点是过程控制管理软件过程使之在质量
控制带内稳定运行虽然必定还有一些经常性的浪费测量结果中可能还有偶发性尖峰需要
控制但是系统在整体上是稳定的在这种场合控制特殊变因的概念发挥作用因为过程
即稳定又可测所以当出现某些例外情况时能够识别并处理特殊变因
质量改进的第二个责任也是等级5的关注焦点是过程的不断改进变更软件过程已
提高质量质量控制区随之移动建立新的减少经常性浪费的性能基线在改进这个过程中
所得到的经验教训被运用到策划未来的过程中去在这种场合处理共性编印的概念有了用
武之地仅仅由于随机变化在任何体系中均存在返工形式的经常性的浪费浪费是不能容
忍的有组织的消除浪费的工作导致更改体系也就是通过克服造成低效的共性原因来
改善过程以防止出现浪费
我们期望达到CMM最高成熟度等级的组织具有能在可预计的成本和进度的限度内生
产出级可靠的软件的过程随着对较高成熟度等级理解的加深将对已有的关键过程方面加
以提炼也可能给模型添加些内容CMM是从制造业中产生的过程思想演变而来的但是软
件过程不像制造业过程那样以复现问题占主导地位软件过程以设计问题占主导地位而且是知识密集型的活动[Crutis 88]
2.3 软件过程的可视性
软件工程师们对项目状态有详细而深入的了解因为他们掌握有关项目状态和表现的第
一手材料可是对于大项目他们的洞察力通常仅来源于在其中职责范围内的个人经验
项目以外的不掌握第一手材料的人例如高级经理对项目过程缺乏可视性为得到他们监
视项目进程所需要的信息只得依靠定期的审查图2.3示出在过程成熟度的每个等级上显示
给管理者的项目状态和表现的可视性程度随成熟度等递增软件过程可视性亦提高
等级1的软件过程是一种混浊体一个黑盒项目过程的可视性受到限制由于活动
阶段的划分做的差经理们极难确定项目进程和活动状态
需求以不受控的方式进入软件过程然后出产品软件开发常被看作为不可知的魔术
特别对不熟悉软件的经理而言更是如此
等级2上顾客需求和工作产品受到控制已经建立其基本的项目管理惯例这些管理
控制使得项目在规定点可视构造软件的过程可看作一连串黑盒子随着活动在盒子间流动
在各过渡点项目里程碑上具有管理可视性尽管管理者可能不知道盒子内发生事情的细
节但是过程的产品和用以证实过程正在运行的检验点都是确定和已知的当问题出现时
管理者能对它们作出反应
等级3上盒子的内部结构即项目规定的软件过程中的作业是可视的该内部结构
反应处在具体项目上运用组织的标准软件过程的方式经理们和工程师们都了解他们在过程
中的岗位和责任知道他们的活动如何在相当的细节层次上相互影响管理者对可能发生的
风险预先有准备由于已定义的过程提供对项目活动很好的可视性所以项目外的人能准确
而及时地得到状态更新信息
等级4上已定义的软件过程具备定量特性并受到定量控制经理们能够度量进度和问
题他们作决策时有一个客观的定量的基础随着过程的变异性越来越小他们预测结果
的能力稳定增长变得越来越准确
等级5上为了提高生产率和质量以受控的方式不断尝试新的和改进的构造软件的方
法随着无效的或者以出错的活动得到标识和替代或修改有纪律的更改成为一种生活方式
洞察立延展到现行过程以外并且能深入了解潜在变更的作用经理们能定量的估计更改的
影响和有效性然后跟踪它们
2.4 过程能力和性能预测
一个组织的软件过程成熟度有助于预测项目达到其目标的能力在等级1 组织中各个
项目在达到成本进度功能度和质量目标方面差别很大如图2.4 中的例子所示随着组
织的软件过程愈趋成熟可看出在满足预定目标方面有三个改进之处
首先随着成熟度增长所有项目的预定结果与实际结果间的差异减小例如如果有
十个相同规模的项目预定在5月1 日交付那么随着组织的成熟它们交付的平均日期会越
来越靠近5月1日等级1 组织常常会大大拖延其最初安排的交付日期而等级5的组织应
该能相当准确地满足预定日期要求这是因为等级5 组织采用仔细构造在已知参数内运行
的软件过程而且确定目标日期是基于它们拥有的有关其过程的大量数据以及它们在运用其
过程时的表现此段含义在图2.4 中用目标日期线右边曲线下的面积大小表示
其次随着成熟度增长实际结果相对预定结果的偏差减小例如等级1组织中规
模类似的项目的交付日期不可预测其变化很大而等级5组织中的类似项目的交付日期的变化范围小得多之所以在最高成熟度等级上变化范围很小原因在于所有的项目实际上
均是针对成本进度功能度和度量等在那些引导本组织过程能力的受控参数内运行此
层含意在图2.4 中以曲线下方集中于目标线附近的面积大小表示
第三随着组织成熟度的增长预定结果得到改善这就是说随着软件组织的成熟
成本降低开发时间缩短生产率和质量提高在等级1 上的组织其开发时间可能十分长
因为必须大量纠错返工相反等级5 组织采用持续的改进过程和缺陷预防技术增加过程有
效性和消除费钱的返工使开发时间缩短这层含意在图2.4 中反映在目标线距原点的水
平距离上
图2.4中表示的在预测项目结果方面的改进基于以下假定即随着噪声通常以返工
形式出现从软件过程中消除软件项目结果也就更可预测无先例的系统会使情况变得复
杂因为新的技术和应用将增加可变性从而降低过程能力不过即使在无先例系统的情
况下与比较不成熟的组织相比较成熟组织的管理和工程惯例的特性有助于在卡发周期的
较早阶段识别和处理问题较早查出缺陷能消除后面阶段的返工从而提高项目的稳定性
和性能在成熟的过程中风险管理是项目管理的必不可少的部分在某些情况下一个成
熟的过程意味着在软件生存周期的早期识别处失败项目使得在无望的事情上的投资最
小
2.5 跳越成熟度等级
CMM 中的成熟度等级描述处于某个成熟度等级的组织的特征前面的等级为后续等级奠
定基础为有效地实施过程提供支持不过如果有益组织也可以使用比它们所在等级高
的那些成熟度等级中所描述的过程例如虽然CMM中在等级3以前不论工程过程诸如
需求分析设计编码和测试但是甚至等级1 组织都必须进行这些活动在有利时等级
1 或等级2组织可以进行同行审查等级3 的巴罗特Pareto 分析等级4 的或者
引入新技术等级5 的在说明一个组织为了从等级1 提高到等级2 应采取哪些步骤时
一个常有的建议是建立软件工程过程小组二者是等级3 组织的属性虽然度量是等级4
的关注焦点但它也是较低成熟度等级的必备部分
这些过程只有在适当基础上才能发挥其潜力例如同行审查只有在统一实施的情况下
才能充分发挥作用即使燃眉之急的项目也是如此成熟度等级之描述某个等级上占主导地
位的问题等级1 组织的占主导地位的问题等级1 组织的占主导地位的问题是管理因为
难以策划和管理软件项目而掩盖了其它问题
因为每个等级时到达一级的必要的基础因此跳越等级将适得其反CMM确定的几个
等级一个组织必须逐步经历才能建立优秀的软件工程文化没有合适基础的过程会迫于压
力而在最需要它们的时刻失去作用它们也不给未来改进提供基础
等级1组织若在建立可重复过程等级2 之前试图去实施已定义的过程通常不会
成功因为项目经理会被进度和成本的压力压垮这是在关注工程过程之前应首先集中注意
力于管理过程的基本原因乍看起来定义和实践工程过程似乎要比定义和实施管理过程容易
特别在技术人员眼中但是如果没有管理纪律工程过程会成为进度和成本等压力的牺
牲品[Humphrey 88]
一个尚无已定义过程作为基础就试图实施定量管理过程等级4 的组织通常是不成功
的因为没有已定义的过程就没有解释度量的共同基础虽然可以采集各个项目的数据但
几乎没有什么度量对其它项目有重大意义也不能显著地增加组织对软件过程的理解缺少
已定义过程时由于接受度量的过程自身的变化要件别处有意义的度量时困难的
一个尚无定量管理过程等级4 作为基础就试图实施持续优化过程等级5 的组织
由于缺乏对过程更改所产生的后果的了解多半会失败若不能把过程控制在统计意义上狭
窄的范围内即过程度量变化的情况下数据中噪声太多以致不能客观地确定某具体的过
程改进是否有效因为几乎没有定量基础用于作出理性的有根据的决策决策可能退化为
听天由命
过程改进工作应该关注本组织在其业务环境的背景中的需要那种实施较高成熟度等级
的过程的能力并不意味着可以跳越成熟度等级
3 CMM 的操作定义
CMM 是一个框架对那些希望提高其软件过程能力的组织来说它展示一条推荐的改
进路径为了支持使用CMM 的多种方法设计了CMM的操作细节至少有四中CMM 的用法受
到支持
评估组运用CMM 去识别组织中的强项和弱项
评价组运用CMM 确定在各个承包商中选择授予业务时的风险和监控合同
经理和技术人员运用CMM去理解那些对于策划和实施其组织的软件过程改进大纲来说必
不可少的活动
过程改进组例如SEPG 软件工程过程小组运用CMM 作为指南帮助他们定义和改
进其组织的软件过程
因为CMM 有多种用法所以必须将它分解得足够细以便能从成熟度等级的结构推
导出对实际过程的建议这种分解也指出那些能反映软件过程能力的特征的过程及其结构
3.1 成熟度等级的内部结构
每个成熟度等级能分解为若干构件除第一级外每个成熟度等级均从等级的抽象概
要向下分解至它们得以关键惯例形式出现的可操作定义如图3.1所示每个成熟度等级有
几个关键过程方面组成每个关键过程方面又按五个称为公共特性的部分加以组织公共特
性规定关键惯例当这些关键惯例均得到实施时就能实现关键过程方面的目标
3.2 成熟度等级
成熟度等级时妥善定义的通往成熟软件过程的前进平台正如图2.1 所示每个成
熟度等级指示过程能力的一个等级例如在等级2 上通过建立健全的项目管理控制组
织的过程能力已经从无序状态提高到有纪律的状态
3.3 关键过程方面
除等级1 外每个成熟度等级被分解成几个关键过程方面指明为了改进其软件过程
组织应关注的方面关键过程方面标识出为了达到某个成熟度等级所必须着手解决的问题
每个关键过程方面标识出一串相关的活动当这些活动全部完成时能达到一组对增强
过程能力来说相当重要的目标如图3.2所示这些关键过程方面已被规定驻留在各个成熟
度等级上 达到关键过程方面目标的途径可能因项目而异这是因为在应用领域或环境上
有差异不过为了使得组织实现某个关键过程方面必须达到该关键过程方面的全部目标
当持续跨项目实现了某个关键过程方面的目标时可以说该组织便已经使以此关键过程方
面为特征的过程能力制度化了形容词关键意味着存在对于实现某个成熟度等级来说非关键的过程方面和若干过
程CMM 并不细述所有与开发和维护软件有关的过程方面已经确定出某些过程方面为过
程能力的关键CMM 中描述的正是这些过程方面
尽管其它问题也影响过程性能但我们只确定关键过程方面这是因为它们对改进组织
软件过程能力很有效可以认为它们时达到某成熟度等级的必要条件图3.2 显示每个成熟
度等级的关键过程方面为了实现一个关键过程方面必须达到该关键方面的每一个目标
目标概括一个关键过程方面的关键惯例并且可用来确定一个组织或一个项目是否以有效的
实现该关键过程方面目标表明每个关键过程方面的范围边界和意图
随着组织达到过程成熟度的更高等级每个关键过程方面上将执行的具体惯例将有所发
展例如等级2 上软件项目策划关键过程方面所描述的项目估计能力中由许多项必须
发展才能处理在等级3 4 5 上附加的项目数据可用性当采用已定义软件过程来管理项
目时等级2 的软件项目策划及软件项目跟踪和监督进化为等级3上的集成软件
管理
CMM 的关键过程方面反应一种描述组织如何成熟的方法这些关键过程方面是在软件工
程和软件管理方面多年的经验和五年多软件过程评估和软件能力评价方面的经验的基础上
确定下来的
等级2 上的关键过程方面集中关注软件项目所关心的与建立基本项目管理控制有关的
事情下面是等级2 上每个关键过程方面的描述
!" 需求管理的目的是在顾客和软件项目之间建立对将由该软件项目处理的顾客需求
的共同理解与顾客的协定是策划如软件项目策划中所描述的和管理如软件项目跟踪
和监督中所描述的软件项目的基础对与顾客关系的控制依靠遵循有效的更改控制过程如
配置管理中所描述的
!"软件项目策划的目的是制定出按之进行软件工程和管理软件项目的切实可行的计划这
些计划是管理软件项目的必要基础如软件项目跟踪和监督中所描述的没有切合实
际的计划不可能实施有效的项目管理
!"软件项目跟踪和监督的目的是建立适当的对实际进展的可视性使管理者在软件项目性
能显著偏离软件计划时能采取有效的措施
!"软件子合同管理的目的是选择合格的软件分包商并有效地管理它们它把用于基本管
理控制的需求管理软件项目策划以及软件项目跟踪和监督的关键过程方面所关注的事
情与软件质量保证和软件配置管理等过程方面中的必不可少的协调结合在一起并且当
合适时对分包商运用这种基本管理控制
!"软件质量保证的目的时给管理者提供对于软件项目正在采用的过程和正在构造的产品
的适当的可视性软件质量保证是绝大多数软件工程过程和管理过程的不可缺少的部
分
!"软件配置管理的目的是在项目整个软件生存周期中建立和维护软件产品的完整性软件
配置管理是绝大多数软件工程过程和管理过程的不可缺少的部分
等级3 的关键过程方面既涉及项目问题又涉及组织的问题这是因为组织建立起使
跨项目的有效的软件工程和管理过程制度化的基础设施下面是等级3 上每个关键过程方面
的描述
!"组织过程聚焦的目的是针对哪些旨在改进本组织整体软件过程能力的各项软件过程活
动确定组织责任组织过程焦点活动的主要结果使一组软件过程财富它们的组织过程
定义中描述这些财富按集成软件管理中所述供软件项目使用
!"组织过程定义的目的是开发和保持一组便于使用的软件过程财富用以改进跨项目的过
程性能并且为组织的长期累积性得益奠定基础这些财富提供一组稳定的基本原则通过诸如培训等机制能使其制度化培训在培训大纲中加以描述
!"培训大纲的目的是培育个人的技能和知识使得他们能有效地和高效率地履行其职责
尽管培训是组织的责任但是软件项目应该是别出它们所需要的技能并且当项目有独
特需要时该项目应提供必要的培训
!"集成软件管理的目的是将软件工程活动和管理活动集成为一个协调的已定义的软件过
程该过程通过剪裁组织的标准软件过程和组织过程定义中所描述的相关的过程财富而
得到剪裁应以项目的业务环境和技术需要为基础如软件产品工程中所述集成软件
管理是从等级2的软件项目策划和软件项目跟踪和监督进化而来
!"软件产品工程的目的是一致地执行一个妥善定义的工程过程该工程过程集成全部软件
工程活动以便能有效地和高效率地生产正确的一致的软件产品软件产品工程描述
项目的技术活动例如需求分析设计编码和测试
!"组间协调的目的是确定软件工程组织积极参与其它工程组工作的方法以便更有效地和
高效率地满足顾客的需求组间协调是集成软件管理在软件工程之外的跨学科方面的延
伸不仅应该集成软件过程而且软件工程组和其它组之间的相互作用也必须加以协调
和控制
!"同行审查的目的是及早和高效地除去软件工作产品中的缺陷一个重要的必然作用是增
强对软件工作产品和可预防的缺陷的了解同行审查是软件产品工程中使用的一种重要
而又有效的工程方法可运用法根式检查Fagan-style检查[Fagan 86] 结构式走
查或者一些其它的学院式的审查方法[Freedman 90]实施
等级4 上的关键过程方面的关注焦点是建立起对软件过程和正在构造的软件工作产品
的定量了解该等级上的两个关键过程方面定量过程管理和软件质量管理是相互紧
密依赖的说明如下
!"定量过程管理的目的是定量地控制软件项目的过程性能软件过程性能表示遵循某个软
件过程所得到的实际结果焦点是在可测的稳定的过程范围内找出变化的具体原因并
且是当时改正那些促成发生瞬时变化的环境定量过程管理给组织过程定义集成软件
国力组间协调和同行审查的各项惯例附加一个综合测量计划
!"软件质量管理的目的是建立对项目的软件产品质量的定量了解和实现特定的质量目标
软件质量管理对软件产品工程中所描述的软件工作产品实施综合测量计划
等级5 上的关键过程方面覆盖的问题包括那些为了实现持续的和可度量的软件过程改
进而必须由组织和项目处理的问题下面是等级5 的每个关键过程方面的描述
!"缺陷预防的目的是识别缺陷的原因并防治它们再次出现如集成软件管理中所述软件
项目分析缺陷识别其原因并更改项目定义软件过程如过程变更管理中所述应将具
有普遍价值的过程更改传播到其它软件项目
!"技术变革管理的目的是识别出能获益的新技术即工具方法和过程并以有序的方式
将它引进到组织中如过程变更管理中所述技术变更管理的关注焦点是在不断变化的
环境里高效率地革新
!"过程变更管理的目的是持续地改进组织中所采用的软件过程以便改进软件质量提高
生产率和缩短产品开发周期过程变更管理即采用缺陷预防的增量式改进又采用技术变
更管理的创新式改进并使得整个组织可以享用这些改进
3.4 公共特性
为方便起见各个关键过程方面按公共特性加以组织公共特性使那些表明某个关键
过程方面的实施和制度化是否有效可重复且持久的属性五个公共特性如下
执行承诺 执行承诺描述组织为确保过程得以建立和持续起作用所必须采取的措施
执行承诺一般包含确定组织的方针和高级管理者的支持
执行能力 执行能力描述为了能完满实施软件过程项目或组织必须具备的先决条件
执行的活动一般包括资源组织结构和培训
执行的活动 执行的活动描述的是为实现某个关键过程方面所必需的岗位和程序
执行的活动一般包括制定计划和规程进行工作跟踪它并在需要时采取纠正措施
测量和分析 测量和分析描述对过程进行测量和对测量结果进行分析的需要测量和
分析一般包括一些了确定执行的活动的状态和有效性所能在用的测量的例子
验证实现 验证实现描述那些用以确保各项活动遵照已建立的过程进行的步骤验证
一般包括管理者和软件质量保证部门所作的评价和审核
在执行的活动这一公共特性中的各项惯例描述为了建立过程能力必须作些什么其它的
各项惯例作为一个整体形成一个使组织能将执行的活动中所描述的各项惯例制度化的基础
3.5 关键惯例
每个关键过程方面用一些可对实现其目标作出贡献的关键惯例加以描述关键管理描
述对关键过程方面的有效实施和制度化贡献最大的基础设施和活动
每个关键惯例由一句话组成往往再加上较为详细的描述可能还包括例子和详细细节
这些关键惯例又称为顶层关键惯例说明关键过程方面的基本方针规程和活动进行详
细描述的部分常称作子惯例图3.3 给出软件项目策划关键过程方面中一个关键惯例的内部
结构的例子
如图3.3 所示为了确保一致地实现使那些用于策划和跟踪项目的计划文件化这一目
标组织必须建立一个文件化的规程用以指导对软件规模的估计由于看不出在估计规模使
各种假设之间的差别如果不根据文件化的规程导出这些估计那么估计值可能会在很大范
围内变化这类规程应该包括使用以前的规模数据要求各种假设形成文件和对估计进行审
查这些准则对于在判断是否遵循合理的规模估计规程时提供指导
关键惯例描述要做什么而不应解释为强制性的应该如何实现目标换用别的
惯例也可能实现该关键过程方面的目标应该合理地解释关键惯例以便判断关键过程方面的
目标是否已被有效地实现尽管实现目标的方式可能不同能力成熟度模型的关键惯例
1.1 版[Paulk 93b]中包含各项关键惯例极其解释指南
4 运用CMM
CMM 建立一组公众可用的描述成熟软件组织特征的准则组织能运用这些准则去该近
期开发和维护软件的过程政府或商业组织能用他们去评价与某具体公司签订软件项目合同
时的风险
本章集中于SEI研制的用以评价一个组织执行的软件过程的成熟度的两种方法软件过
程评估和软件能力评价
!"软件过程评估 用于确定一个组织的现行软件过程的状态确定组织所面临的具有搞
优先级的与软件过程有关的问题和获得组织对软件过程改进的支持
!"软件能力评价 用于识别有资格完成软件工作的承包商或者监控现有软件工作中所运
用的软件过程的状态
此概述本身不足以指导读者进行评估或评价任何希望通过这两各方法去运用CMM
的人应该请求得到有关评估和评价培训的进一步的信息
CMM 是软件过程评估和软件能力评价的共同基础可是这两种方法的目的十分不同因
此具体用法存在重大差异但是两者又都基于CMM 模型及从它导出的产品CMM加上基于CMM
的产品能使这些方法得到可靠且一致的运用
4.1 软件过程评估和软件能力评价方法
软件过程评估致力于找出组织自己的软件过程的优先改进之处评估组用CMM 指导
他们找出值得改进之出并进行优先级排序这些调查发现与CMM中的关键惯例所提供的指导
一起被例如软件工程过程小组用来策划组织的改进策略
软件能力评价致力于识别与某项要求在规定的进度和预算内构造出高质量软件的特定
项目或合同相联系的风险在采办过程中可以对投标者进行软件能力评价评价的发现如
CMM 所设计的那样可以用于确定在挑选特定承包商时的风险也可对现行的合同进行评价
以便监控它们的过程性能其目的是在承包商的软件过程中识别出潜在的可改进之处
CMM 为进行软件过程评估各软件能力评价建立一个共同的参考框架虽然这两种方法的
目的不同但均采用CMM作为评定软件过程成熟度的根据图4.1概要描述评估和平加重的
共同步骤
第一步是选择工作组对该组进行CMM 基本要领和评估或评价方法细节的培训改组的
成员应具有丰富的软件工程和管理方面知识
第二步是让待评估或待评价单位的代表填写成熟度问卷和按其它诊断工具的要求做一
旦完成此项活动评估或评价组就对回复的情况进行分析第三步即对问卷响应计分
并确定必须作进一步探究的方面待探究的方面与CMM 的关键过程方面相对应
现在该组已准备好访问被评估或评价单位的现场第四步从响应分析的结果着手
该组进行采访和审查文件以便了解该现场所遵循的软件过程CMM 中的关键过程方面和关键
惯例指导改组成员进行提问倾听并且审查和综合得自采访和文件中的信息在确定现场的
关键过程方面的实施是否满足相关的关键过程方面的目标时该组需要运用专业性的判断
当CMM的关键惯例与现场的惯例间存在明显差异时该组必须把它用于判断此关键过程方面
的理论依据形成文件
在现场工作阶段结束时该组写出调查发现清单第五步标识出该组织软件过程的
强项和弱项在软件过程评价中这些调查发现成为提出过程改进建议的基础在软件能力
评价中调查发现成为采办单位所作的风险分析的一部分
最后该组给出一份关键过程方面概貌第六步显示出该组织已满足和尚未满足关
键过程方面目标的那些地方某个关键过程方面可能已得到满足但仍有一些相关的调查发
现前提是这些调查发现并未反应储存在有障碍于实现该关键过程方面的任何一个目标的重
大问题
归纳起来软件过程评估和软件能力评价方法两者均
!" 采用成熟度问卷作为现场访问的出发点
!" 采用CMM 作为指导现场调查研究的路线图
!" 按CMM 中的关键过程方面书写那些标识软件过程强项和弱项的调查发现
!" 在对关键过程方面目标满足情况进行分析的基础上进一步得出该关键过程方面
的概貌
!" 用调查发现和关键过程方面概貌向相应的被审核对象提出结论意见
4.2 软件过程评估和软件能力评价之间的差异
尽管由这些相似之处但软件过程评估或软件能力评价的结果可能不同甚至在相继运用相同的方法的情况下也是如此一个原因是评估或评价的范围可能变化首先必须确
定受调查的组织对大公司而言可能对组织有几种不同的定义组织的范围可能基于
有共同的高级管理者共同的地位位置指定的盈亏中心共同的应用领域或者其它考虑
其它甚至在似乎是相同的组织中所选项目的样本也可能影响范围评估可能对公司中的
一个部门进行评估组是在全部门的范围的出其调查发现后来可能对该部门中的一条产
品线进行评价评价组的调查发现得自一个窄得多的范围不了解背景而对结果作比较是成
问题的
软件过程评估和软件能力评价在动机目的输出和结果的所有权上均不同这些因素
导致在采访的动因询问的范围所采集的信息和结果的表示方式上有本质的不同验看所
采用的详细规程可发现评估和评价的方法大小不相同经过评估培训的小组做不了评价
反之亦然
软件过程评估是在开放合作的环境中进行的评估的成功靠的是管理者和专业人员两
方面关于要改进本组织的承诺评价目的在于暴露问题和帮助经理和工程师改进他们的组
织尽管问卷有助于使评估组关注成熟度等级问题但是终点仍应放在预先安排的和随意的
采访上把它作为了解组织软件过程的工具除了识别组织所面临的软件过程问题外评估
的最有价值的结果是为改进赢得支持全组织范围关注过程以及在执行改进行动计划上的
动力和热情
另一方面软件能力评价在更为面向审核的环境中进行评价目的与金钱密切相关因
为评价组的推荐将帮助挑选承包商或设置奖金重点放在形成文件的审核记录上它们揭示
组织实行执行的软件过程
4.3 CMM 在过程改进方面的其它用法
对软件工程过程组SEPG 或试图改进其软件过程的其它组来说CMM 在改进措施
的策划上行动计划实施上和过程定义上有着特殊的价值在策划改进措施期间具有有关
其软件过程问题和业务环境得知使得软件工程过程组的成员可将CMM 中关键过程方面的目
标与其现行的惯例相比较对于各个关键惯例应该结合公司目标管理优先级该惯例的性
能水平实施每个惯例对组织的价值以及该组织在其文化背景下实施某惯例的能力等加以审
视
接下来软件工程过程组必须确定需要做那些过程改进如何实现更改以及如何获得必要
的支持CMM通过给有关过程改进的讨论提供起始点和帮助揭示关于普遍接受的软件工程惯
例的那些面目全非的假定从而对这项活动提供帮助在实施行动计划时该过程组可用
CMM 和关键惯例来拟制部分可操作的行动计划和定义软件过程
5 CMM 的未来发展方向
向软件过程成熟度的更高等级攀登是渐进的过程要求对不断改进过程又长期的支持
软件组织可能用十年或更长的时间为持续的过程改进奠定基础和建立前瞻性文化虽然对绝
大多数美国公司来说长达十年的过程改进计划是陌生的但是为了成为成熟软件组织这
种层次的努力是必要的这个时间框架与其它行业例如美国的汽车制造业的经验相一致
它们在过程成熟度上已取得重大的进展[Gabor 90]
5.1 CMM 不覆盖什么
CMM 不是无所不包的[Brooks 87] 它并不涉及对成功项目来说是重要的所有问题例
如CMM目前并未涉及特定应用领域内的专门知识也未提倡具体的软件技术或者就如何选
择雇用激励和留住有能力的人提出建议虽然这些问题对项目的成功至关重要其中一
些已在其它背景中进行了分析[Curtis 90] 可是尚未将这些问题综合到CMM 中CMM是为
了提供一个条理分明有条不紊的框架以便在此框架内阐述软件管理过程和工程过程的问
题而专门研制的
5.2 近期活动
在遍及美国的主要会议和研讨会上经常举办CMM 短训班及讲座以确保软件业界对
CMM 及其相关联的产品有足够的了解正在开发和或修改基于CMM的工具例如成熟
度问卷软件过程评估培训和软件能力评价培训以便纳入到CMM 中去
CMM 开发活动的近期关注焦点是那些经剪裁的CMM版本例如适用于小项目和或小
规模组织的CMM CMM1.1版是用那些与政府签订大型合同的组织的标准惯例表达的这些惯
例必须加以剪裁才适合不同于这个样板的组织的需要
5.3 长期活动
在以后的几年内通过在软件过程评估和软件能力评价中不断使用CMM CMM 将继
续经受广泛的检验适当时将研制和修定基于CMM 的产品和培训资料CMM是一份将得到
改进的文件但是与其至少直到1996 年CMM1.1 版将仍然是基线这样救灾对稳定性和不断
改进的需要之间提供合适的和切合实际的平衡
对于CMM 的下一个版本版本2.0SEI将其注意力转向改进整个模型虽然模型的所有
等级都可能被修改但重点放在等级4 和等级5 上目前已非常完备地规定了等级2 和等级
3 的关键过程方面由于没有几个组织经评估是处在等级4 或等级5 上的[Humphrey 91a
Kitson 92] 所以对这类组织的特征知之甚少SEI 正与力求了解和达到等级4 和等级5 的
组织密切合作将对这两个等级的惯例进行推敲CMM也可能成为多维的以便处理技术和
人力资源的问题
5.4 结论
正如持续改进之于软件过程那样持续改进也适用于成熟度模型和惯例必须考虑到
CMM 的更改对软件界的潜在影响但是CMM 成熟度问卷和软件过程评估及软件能力评价方
法等将随着有关软件过程改进方面经验的不断积累而不断地进化SEI 打算在推进此项进化
上继续与工业界政府和学术界紧密合作
CMM提供了一种以有条不紊的和一致的方式改进软件产品的管理和开发的概念性结构
但是它并不能保证软件产品将成功地构造出来或者保证恰当地解决全部软件工程中的问
题虽然CMM确定了成熟软件过程的管理和提供某些当前惯例水平并且在某种情况下是
当前技术水平的例子但是这并不意味着它是详尽无漏的或是可以强制执行的CMM只标
识出有效软件过程的特征但是成熟组织必须致力于对成功项目来说是必不可少的全部问
题包括人技术和过程

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/