北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第十一讲
软件能力成熟度模型（ SW-CMM）
集成能力成熟度模型（ CMMI）
介绍
内容
? SW-CMM的提出
? SW-CMM的结构
? SW-CMM的关键过程区域
? CMMI的提出
? CMMI的结构
? CMMI的过程区域
SW-CMM和 CMMI的提出
质量的杠杆作用点
每个人都体会到主动积极的优质劳动力的
重要性, 但是 ……
…… 如果不理解过程，或者过
程不是在“最佳实践”下运
行，即使我们的精英也无法
使工作达到最佳的状态
人员
过程 技术
过程是产品成本、进度和质量的主要
决定因素
项目成功的支柱
过程管理 技术资产 人力资源 客户 — 供应商关系
什么是过程
? 如何定义过程？
过程的一般定义
过程 是指为了达到给定目的而执行的实践的集合；
它可能包括工具、方法、资料和 /或人
过程 是指为了达到给定目的而执行的一系列活动
的有序集
经常将过程描述成是三元组“过程 —人员 —技术”
中的一个元素，也可以认为它是联合其它元素
的,粘合剂” 人员
技术 过程
过程是三个杠杆作用点之一
工具
- 项目管理工具
- 软件开发工具
人
- 管理者
- 工程师
过程
- 标准软件过程
- 持续过程改进
过程改进的基本前提
“产品质量主要取决于用于
开发和维护该产品的过程
的质量”。
基于 Shewhart,Juran,Deming 和 Humphrey 倡导的
TQM原理
早期的过程改进
? 过程管理理论是 Deming,Crosby,Juran以及其
他一些人的概念的综合
? 在过去的 30年里, 这些理论已经用于解决许多
组织的共同问题
? 虽然已经有了解决方案, 但是现有的实践水平
与技术发展水平之间仍有一定的差距
? 其中的许多概念已经用于建立过程改进模型
软件过程 —外行的观点
客户 程序员
“为我的产品
开发一个软件”
然后奇迹发生 完成。
该过程的潜在问题
? 开发队伍角色未定义，不协调
? 团队工作和过程绩效由于执行的间隙和冲突而
削弱
? 对过程和产品质量的洞察有限
? 对产品配置的控制有限
? 发行比原始进度推迟
? 成本比估计的大得多
? 软件不是客户所需要得
软件过程 —内行的初步观点
描述
编码
观察
能否工作
因素 特征
管理相关 没有觉察，太忙
项目成员 差的培训，缺乏经验，没有组织
开发过程 未定义，任意
管理类型 危机管理
产品质量 没有度量
产品配置 没有控制
项目成功 依赖于英雄
不成熟组织的共同特征
不成熟组织产生的共同结果
因素 结果
需求 缺乏控制，需求“不断懦动”
产品性能 不可预估，不能满足用户需要
产品配置 没有管理
产品质量 不可知，充满缺陷
成本 缺乏追踪，经常超越
进度 经常延迟
早期的过程改进
? 过程管理理论是 Deming,Crosby,Juran以及其
他一些人的概念的综合
? 在过去的 30年里, 这些理论已经用于解决许多
组织的共同问题
? 虽然已经有了解决方案, 但是现有的实践水平
与技术发展水平之间仍有一定的差距
? 其中的许多概念已经用于建立过程改进模型
什么是过程模型？
? 模型是描述有效过程特征的元素的结构
化集合
? 这里所涵盖的过程是指那些通过经验证
明为有效的过程
如何使用模型？
? 模型是用来,
? 帮助建立过程改进的目标和优先次序, 协助
改进过程, 并为确保建立一个稳定的, 有能
力的以及成熟的过程提供指南
? 作为组织过程改进的指南
模型为什么重要？
? 模型提供了
? 过程改进的出发点
? 社团过去经验的结晶
? 共同的语言和共享的构想
? 活动优先次序的框架
模型
“所有的模型都是错误的，但有些是有用
的。,
“All models are wrong,but some are
useful.”
? George Box
? 提供对真实世界认识的简单近似
使用什么模型？
? 从历史的角度讲, 是以学科建立模型,
如,
? 软件工程
? 系统工程
? 软件获取
? 系统安全, 等等
CMM的产生背景
? 美国国防部在向承包商发包军用软件项目时，
希望了解承包商的开发能力，以保证项目的成
功和产品质量
? 美国国防部委托美国卡内基 -梅隆大学的软件工
程研究所（ CMU-SEI） 进行研究
? SEI基于项目成功很大程度依赖于其开发过程
的经验，提出包含 5级的软件能力成熟度模型
（ SW-CMM）
? 美国国防部要求其承包商的能力成熟度至少为
3级
CMM的产生历程
? 1987年美国软件工程研究所 (SEI） 以
W.S.Humphrey为首的研究组发表的“承
包商软件工程能力的评估方法”
? 1991年发展为 SEI CMM1.0（ 能力成熟度
模型 1.0版）
? 1993年该模型发展为 SEI CMM 1.1（ 现
行有效）
CMM的基础
? 阶段化结构：基于过去 60年来的产品质
量原则。
? Walter Shewart在三十年代发表了统计质量
控制原理。 W.Edwards Deming 和 Joseph
Juran 又进一步发展和论证了该原理。
成熟度框架,Philip Crosby在,Quality is
Free”中描述了质量管理成熟度框架的五
个进化阶段。
? IBM等的工程实践。
什么是 CMM？
?能力成熟度模型
? 一个在特定学科中的成熟实践的参考模型, 用于评估一个
组履行该学科任务的能力
?CMM有不同模型, 从以下不同的方面来区分,
? 学科 （ 软件, 系统, 获取等 ）
? 结构 （ 阶段和连续式 ）
? 成熟度的程度 （ 过程改进的路线 ）
? 能力的程度 （ 制度化 ）
?软件工程研究所 （ SEI） 的, 能力成熟度模型 ?” 和 CMM?是
一种成熟度模型 。
?能力成熟度模型 ?,CMM?,CMM Integration和 CMMI是卡
内基梅隆大学的服务标志和注册商标
IDEALSM 模型
启 动
诊 断
建 立
行 动
学 习
修改
组织级方法
文档化教训
和分析教训
定义过程
和度量
计划和执行
试验过程
计划、执行
和跟踪装置
建立过程
行动组
计划行动项 设置优先级
和策略
提出建议并将
结果文档化
评估和刻画
当前的状态
建立
基础设施
设置语境和
建立出资方
改进的促进
因素
SM IDEAL 是 CMU的服务标志 。
SW-CMM的结构
软件过程 ——术语
? 人们用于开发和维护软件及其相关产品
(例如，项目计划、设计文档、代码、测
试用例、用户手册等等 )的一系列活动、
包括软件工程活动和软件管理活动。
软件过程能力 ——术语
? 描述（开发组织或项目组）通过遵循其软件过
程能够实现预期结果的程度 。
一个软件开发组织或项目组的软件过程能力提供
一种预测该组织承担下一个软件项目时最可能
的预期结果的方法。软件过程能力既可对整个
软件开发组织而言，也可对一个软件项目组而
言。
? 软件过程性能, 表示（开发组织或项目组）遵
循其软件过程所得到的实际结果。
软件过程成熟度 ——术语
? 一个特定软件过程被明确和有效地定义、管理、
测量和控制的程度 。
? 成熟度可指明一个软件开发组织软件过程能力
的增长潜力。随着软件组织的软件过程成熟度
的提高，开发组织通过其方针、标准和组织机
构等将其软件过程规范化和具体化。从而使得
开发组织明确定义的有关管理和工程的方法、
实践和规程等在现有人员离去后仍能继续下去。
软件过程能力成熟度等级 ——术语
? 软件开发组织在走向成熟的途中几个具有明确
定义的表征软件过程能力成熟度的平台 。
? 每一个成熟度等级为过程继续改进达到下一个
等级提供一个基础。每一等级包含一组过程目
标，当其中一个目标被达到时，就表明软件过
程的一个（或几个）重要成分得到了实现，导
致组织的软件过程能力增长。
软件能力成熟度模型 ——术语
? 对软件组织进化阶段的描述，随着软件组织定
义、实施、测量、控制和改进其软件过程，软
件组织的能力经过这些阶段逐步前进。
? 这个模型使软件组织能够较容易地确定其当前
过程的成熟度并识别出其软件过程执行中的薄
弱环节，确定对软件质量和过程改进最为关键
的几个问题，从而形成对其过程的改进策略；
软件组织只要关注并认真实施一组有限的关键
实践活动，就能稳步地改善其全组织的软件过
程。
CMM软件过程能力成熟度的 5个等级
1 软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没
有什么过程是经过定义的，成功依赖于个人的努力。
2 已建立基本的项目管理过程去跟踪成本、进度和功能性。
必要的过程纪律已经到位，使类似得应用项目，能重复以
前的成功。
3 管理活动和工程活动两方面的软件过程均已文档化、标准
化、并集成到组织的标准软件过程。全部项目均采用供开
发和维护软件用的组织标准软件过程的一个经批准的剪裁
版本。
4 已采集详细的有关软件过程和产品质量的度量数据。 无论
软件过程还是产品均得到了定量了解和控制。
5 利用来自过程和来自新思想、新技术的先导性试验的定量
反馈信息，使持续的过程改进成为可能。
CMM软件过程能力成熟度的
5个等级（图示）
2,可重复
1,初始
3,已定义
4,已管理
严格执行
的过程
标准、一致的
过程
可预估的过程
连续改进过程
不可预估和缺乏控
制
可以重复以前熟练
的任务
过程特征化，容易
理解
过程被度量和控制
集中于过程改进
5.优化
项目管理
集成工程过程
产品和过程质量
管理更改
结果 关键过程区域
级别 特征
优化 Continuous process Process change management
(5) capability improvement Technology change management
Defect prevention
已管理
(4)
已定义 Software process defined
(3) and institutionalized to
provide product quality
control
可重复
(2)
初始 l
(1)
Product quality planning; Software quality management
tracking of measured Quantitative process management
software process
Management oversight
and tracking of project;
stable planning and
product baselines
关键过程区域
定制 (成功依赖于英雄 ),人员 " 风险
生产率
& 质量
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking & oversight
Software project planning
Requirements management
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
SEI 能力成熟度模型
管理 机构 工程 5 优化级 技术更新管理
过程更新管理 缺陷预防
4 已管理级 定量软件管理 软件质量管理
3 已定义级 集成软件管理 组织过程焦点 软件产品工程
组间合作 组织过程定义 同行评审
培训大纲
2 可重复级 需求管理
软件项目策划
软件项目
追踪与监督
软件子合同管理
软件质量保证
软件配置管理
1 初始级 定制的过程
管理可视性 过程能力
Out In 1
2
3
4
5
概率
Time/$/..,
Target
N
N+a
N-x
N-y
N-z
级别
初始级 ——图示
Level 1,
Just do it,Activity Results to produce
初始级 ——行为特征（ 1）
在初始级上组织一般不提供开发和维护软
件的稳定环境 。 当组织中缺乏健全的管
理实践时, 不适当的规划和反应驱动体
系会降低由良好的软件工程实践所带来
的效益 。
初始级 ——行为特征（ 2）
在危机时刻, 项目一般抛弃预定的规程, 回复到
仅作编码和测试 。 成功完全依赖于有一个杰出
的经理及一支有经验的, 战斗力强的软件队伍 。
偶尔, 有能力的, 坚强的软件经理能经受住要
他们在软件过程中走捷径的压力, 但是当他们
离开项目后, 他们能使过程稳定的影响也随之
消失 。 甚至一个强的工作过程也不能克服由于
缺乏健全的管理实践所造成的不稳定 。
初始级 ——行为特征（ 3）
等级 1的组织的过程能力是不可预测的, 因
为随着工作进展软件过程经常被改变或
修定 （ 即过程是无秩序的 ） 。 进度, 预
算, 功能性和产品质量一般是不可预测
的 。 等级 1组织几乎没有明显的稳定的软
件过程, 只能通过个人的能力而不是组
织的能力去预测性能 。
可重复级 ——图示
Activity Results
to produce
Level 2,
Think before
you act,
and think after
you act,just to
make sure you
did it right,
Planning
Evaluation
input to
to improve
可重复级 ——行为特征（ 1）
在可重复级上, 已建立管理软件项目的方针和实
施这些方针的规程 。 基于在类似项目上的经验
对新项目进行规划和管理 。 达到 2 级的目的是
使软件项目的有效管理过程制度化, 这使得组
织能重复在以前项目上所开发的成功实践, 尽
管项目所实施的具体过程可能不同 。 一个有效
过程可特征化为实用的, 已文档化的, 已实施
的, 已培训的, 已测量的和已改进的 。
可重复级 ——行为特征（ 2）
等级 2组织中的项目已经设置基本的软件管理控
制 。 实际可行的项目约定是基于对以前项目的
观察结果和当前项目的需求 。 项目的软件经理
跟踪软件成本, 进度和功能性；在满足约定方
面的问题, 一旦出现就被识别 。 对软件需求和
为实现需求所开发的工作产品建立基线, 并控
制其完整性 。 软件项目标准均已确定, 并且组
织能保证准确地执行这些标准 。 如果有子承包
商的话, 软件项目与他们一起努力建立一种强
有力的顾客 ——供应商关系 。
可重复级 ——行为特征（ 3）
等级 2组织的过程能力可概括为有纪律的,
因为软件项目的规划和跟踪是稳定的,
能重复以前的成功 。 由于遵循基于以前
项目性能所制定的切实可行的计划, 项
目过程处在项目管理系统的有效控制之
下 。
已定义级 ——图示
Standards Activity Results
to produce
Level 3
Planning
Evaluation
input to
to improve
input to
input to
Use your lessons learned,
已定义级 ——行为特征（ 1）
在已定义级上, 全组织的开发和维护软件的标准
过程已文档化, 包括软件工程过程和软件管理
过程, 而且这些过程被集成为一有机的整体
（ 组织的标准软件过程 ） 。 等级 3上所建立
（ 适当时, 经更改 ） 的过程, 被用来帮助软件
经理和技术人员工作得更有效 。 组织在使其软
件过程标准化时, 利用有效的软件工程实践 。
存在一个负责组织的软件过程活动的组, 例如
软件工程过程组 。 实施全组织的培训计划以保
证职员和经理具有履行其职责所必须的知识和
技能 。
已定义级 ——行为特征（ 2）
项目通过剪裁组织的标准软件过程去建立他们自
己定义的软件过程, 它说明项目独有的特征
（ 项目定义软件过程 ） 。 一个已定义软件过程
包含一组协调的, 集成的, 妥善定义的软件工
程过程和管理过程 。 妥善定义的过程可特征化
为具有准备就绪判据, 输入, 标准, 进行工作
的规程, 验证机制 （ 例如同行评审 ）, 输出,
以及完成判据 。 因为软件过程已妥善定义, 管
理者就能洞察所有项目的技术进展 。
已定义级 ——行为特征（ 3）
等级 3组织的软件过程能力可概括为标准的
和一致的, 因为无论软件工程活动还是
管理活动, 过程都是稳定的和可重复的 。
在所建立的产品基线内, 成本, 进度和
功能性均受控制, 对软件质量也进行跟
踪 。 这种过程能力建立在整个组织范围
内对已定义过程中的活动, 角色和职责
的共同理解之上 。
已管理级 ——图示
Standards Activity Results
to produce
Level 4
Planning
Evaluation
input to
to improve
input to
input to to forecast
Predict the results you need and expect and then
create opportunities to get those results
已管理级 ——行为特征（ 1）
在已管理级上, 组织对软件产品和过程都
设置定量的质量目标 。 作为组织测量大
纲的一部分, 对所有的项目都测量其重
要的软件过程活动的生产率和质量 。 利
用一个全组织的软件过程数据库收集和
分析从项目定义软件过程中得到的数据 。
等级 4 上的软件过程均已配备有妥善定义
的和一致的度量 。 这些度量为定量地评
价项目的软件过程和产品打下基础 。
已管理级 ——行为特征（ 2）
项目通过将其过程性能的变化限制在定量
的可接受的范围之内, 实现对其产品和
过程的控制 。 可以将过程性能方面有意
义的变化与随机变化 （ 噪声 ） 区别开来,
特别在所建立的产品线内 。 开发新应用
领域的软件所带来的风险是已知的, 并
得到精心的管理 。
已管理级 ——行为特征（ 3）
等级 4组织的软件过程能力可概括为可预测
的, 因为过程是已测量的并在可测的范
围内运行 。 该等级的过程能力使得组织
能在定量限制的范围内预测过程和产品
质量方面的趋势 。 当超过限制范围时,
采取措施予以纠正 。 软件产品具有可预
测的高质量 。
Standards Activity Results
to produce
Level 5 Planning
Evaluation
input to
to improve
input to
input to to forecast
to improve
Create lessons learned,
and use lessons learned to create more lessons learned,
and use more lessons learned
to create even more lessons learned,
and use even more lessons learned to create..,
etc,
优化级 ——图示
优化级 ——行为特征（ 1）
在优化级, 整个组织集中精力进行不断的
过程改进 。 为了预防缺陷出现, 组织有
办法识别出弱点并预先针对性地加强过
程 。 在对新技术和所建议的组织软件过
程的更改进行费效分析时利用有关软件
过程有效性的数据 。 识别出采用最好软
件工程实践的技术创新并推广到整个组
织 。
优化级 ——行为特征（ 2）
等级 5组织的软件项目群组分析缺陷以确定
其发生的原因 。 为了防止已知类型的缺
陷再次出现, 他们认真评价软件过程,
同时将经验教训告知其它项目 。
优化级 ——行为特征（ 3）
等级 5组织的软件过程能力可特征化为不断
改进, 因为这些组织为扩大其过程能力
的范围进行着不懈的努力, 因而不断改
善其项目的过程性能 。 既通过在现有过
程中增量式前进的办法, 也通过采用新
技术, 新方法的革新办法, 使改进不断
出现 。
CMM结构 成熟度等级
关键过程区域
关键实践
共同特点
过程能力
目标
实施或规范化
基础设施或活动
按,..组织
到达
阐述
包含
描述
指示 包含
关键过程区域 ——术语
? 互相关联的若干软件实践活动和有关基
础设施的一个集合 。
? 每个软件能力成熟度等级包含若干个对
该成熟度等级至关重要的过程区域, 它
们的实施对达到该成熟度等级的目标起
保证作用, 这些过程区域就称为该成熟
度等级的关键过程区域 。
共同特点 ——术语
? 共同特点是表明一个关键过程区域的实
施和规范化是否有效、可重复且持久的
一些属性。
? 关键过程区域按照共同特点进行组织。
? 共有 5个共同特点：执行约定、执行能力、
执行的活动、测量和分析、验证实施。
关键实践 ——术语
? 对关键过程区域的实施起关键作用的方
针, 规程, 措施, 活动以及相关基础设
施的建立 。
? 关键实践一般只描述, 做什么,, 而不
强制规定, 如何做, 。 关键过程区域的
目标是通过其包含的关键实践的实施来
达到的 。
成熟度级别
关键过程
区域
目标
共同特点
关键实践
2 3 4
5
CMM结构
RM PP PT SM CM QA
执行能力 执行的活动 执行约定 测量和分析 验证实施
关键过程区域的过程分类
过程分类
等级
管理
（软件项目策划等）
组织 （高级管理者评
审等）
工程 （需求分析、设
计、编码、测试等）
技术改进管理5 优化级
过程改进管理 缺陷预防
4 定量管理级 定量过程管理 软件质量管理
3 已定义级 集成软件管理
组间协调
组织过程焦点
组织过程定义
培训大纲
软件产品工程
同行专家评审
2 可重复级 需求管理
软件项目策划
软件项目追踪和监督
软件子合同管理
软件质量保证
软件配置管理
1 初始级 无序过程
CMM的关键过程区域
需求管理（ L2）
? 需求管理的目的是在顾客和软件项目之
间建立对顾客需求的共同理解，顾客需
求将由软件项目处理。
? 与顾客的协议是策划和管理软件项目的
基础。
? 对与顾客关系的控制依靠遵循有效的更
改控制过程。
需求管理
软件需求
评审和纳入更改
描绘
编码
观察能否
工作
文档化
软件需求 使用软件需求指导计划、活动
和工作产品。
系统需求
软件项目策划（ L2）
? 软件项目策划的目的是制定进行软件工
程和管理软件项目的合理的计划。
? 这些计划是管理软件项目的必要基础。
? 没有切合实际的计划不可能实施有效的
项目管理。
软件项目策划
定义软件生存周期
文档记录软件
开发计划
确定软件工作产品
估计规模，成本
，工作量
制定活动进度
设计 编码
测试
(摆脱那些模糊的过程 )
软件项目追踪与监督（ L2）
? 软件项目追踪与监督的目的是建立适当
的对实际进展的可视性，使管理者在软
件项目性能显著偏离软件计划时能采取
有效的措施。
软件项目追踪与监督
追踪相对于估计的确
切规模，成本，工作
量
追踪相对于进度的确切进
展
使用软件开发计划（
SDP） 来追踪活动
设计 编码
测试
在必要时采取及时的修
正行动
软件子合同管理（ L2）
? 软件子合同管理的目的是选择合格的软
件子承包商，并有效地管理它们。
? 它把用于基本管理控制的需求管理、软
件项目策划、以及软件项目跟踪与监督
等关键过程区域所关注的事情与软件质
量保证和软件配置管理等过程区域中的
必不可少的协调结合在一起，并且当合
适时对子承包商实施这项管理。
软件子合同管理
设计
编码 测试
批准承包商的软件开发计划
（ SDP） 来追踪活动
指定人员管理合同
SOW
定义工作陈述（ SOW）；
选择有资格的承包商
评审承包商的完成
量和产品
软件质量保证（ L2）
? 软件质量保证的目的是给管理者提供对
于软件项目正采用的过程和正在构成的
产品的恰当的可视性。
? 软件质量保证是绝大多数软件工程过程
和管理过程的不可缺少的部分。
软件质量保证
审计工作 产品 的符合一致性
评审然后过程活动 (过程 )来验证符合一致
设计
编码
测试
确定偏离的活动和工
作产品
软件配置管理（ L2）
? 软件配置管理的目的是在项目的整个软
件生存周期中建立和维护软件产品的完
整性。
? 软件配置管理是绝大多数软件工程过程
和管理过程的不可缺少的部分。
软件配置管理
置工作产品于配置
管理之下
记录，评审，批准，和
追踪更改和问题
控制对基线的更
改
控制从基线的发布
基线库
设计 编码
测试
软件配置管理
等级 2(可重复的 )的一个关键过程
区域
（根据蔡愉祖译稿整理）
概述
软件配置管理的目的是建立和维护在项目的整个软件生存周期中软
件项目产品的完整性 。
软件配置管理包括标识在给定时间点上软件的配置 （ 即选定的软件
工作产品及其描述 ）,系统地控制对配置的更改, 并维护在整个软
件生存周期中配置的完整性和可跟踪性 。 置于软件配置管理之下
的工作产品包括交付给顾客的软件产品 （ 例如软件需求文档和代
码 ）, 以及与这些软件 等同的产品项或生成这些软件产品所要求
的产品项 （ 例如编译程序 ） 。
建立一个软件基线库, 当软件基线形成时就将它们纳入该库 。 通过
软件配置管理的更改控制和配置审计功能, 系统地控制基线的更
改和那些利用软件基线库构造成的软件产品的发行 。
这个关键过程区域仅包括实施软件配置管理功能的实践 。 而标识具
体的配置项或单元的实践则包含在描述每个配置项或单元的开发
和维护的关键过程区域中 。
目标
目标 1 软件配置管理活动是有计划的 。
目标 2 所选定的软件工作产品是已标识的,
受控的和适用的 。
目标 3 对已标识的软件工作产品的更改是
受控的 。
目标 4 受影响的组和个人得到软件基线的
状态和内容的通知 。
执行约定
（ 1项）
约定 1 项目遵循书面的用以实施
软件配置管理 (SCM)的组织方针。
该方针一般规定,
1,明确指派每个项目的 SCM职责。
2,在项目的整个生存周期内实
行 SCM。
3,对于对外可交付的软件产
品,指定的内部软件工作产
品和指定在项目内部使用的
支持工具（例如编译器）都
实行 SCM。
4,项目建立或可以利用一个仓
库，用来存储配置项 /单元和
相关联的 SCM记录。
在这些实践中这个仓库的内容称
为, 软件基线库, 。
存取该仓库的工具和规程在这些
实践中称为, 配置管理库系
统, 。
置于配置管理上并作为单个实体
予以处理的工作产品称为配
置项。配置项一般分解为配
置部件，而配置部件一般分
解为单元。在一个硬件 /软件
系统中,所有的软件可看成
一个单个配置项，或者可将
该软件分解为多个配置项。
在这些实践中术语, 配置项 /
单元, 用于指示在配置管理
下的元素。
5,定期审计软件基线和 SCM
活动。
执行能力
（ 5项）
能力 1 存在或者建立一个有权力管理项目软件基
线的委员会（即软件配置控制委员会 —SCCB）。
该 SCCB,
1,审定软件基线的建立和配置
项 /单元的标识。
2,代表项目经理和所有可能受
到软件基线更改影响的组的
利益。
受影响的组的例子有,
—硬件质量保证组,
—硬件技术状态（配置）管理组,
—硬件工程组,
—制造工程组,
—软件工程组（包括所有的小组，
例如软件设计小组）,
—系统工程组,
—系统测试组,
—软件质量保证组,
—软件配置管理组,
—合同管理组，和
—文档支持组。
3,评审和审定对软件基线的更
改。
4,审定由软件基线库制造的产
品的生成。
能力 2 存在负责协调和实施项
目的 SCM的组 (即 SCM组 )。
一个组是负责一组作业或活动的部
门, 经理, 和个人的集合 。 组的
规模可以变化：从一个受指派的
非全日制的单个个人, 到几个从
不同部门指派来的非全日制的个
人, 到几个全日制的个人 。 建立
一个组时应考虑的问题有：指派
的作业和活动, 项目的规模, 组
织机构和组织文化 。 某些 组, 例
如软件质量保证组, 集中注意力
于项目的活动, 而其它组, 例如
软件工程过程组, 集中关注全组
织的活动 。
SCM组协调或实现,
1,项目的软件基线库的生成和管理 。
2,SCM计划、标准和规程的制定、
维护和散发。
3,将置于 SCM之下的软件工作产
品集合的标识 。
一个工作产品是由定义, 维护,
或使用一个软件过程所生成
的任何人工制品 。
4,对存取软件基线库的管理 。
5,软件基线的更新 。
6,由软件基线库制造的产品的
生成 。
7,SCM行动的记录 。
8,SCM报告的生成和散发 。
能力 3 为进行 SCM活动提供足
够的资源和投资。
1,安排一个经理专门负责 SCM。
2,使得支持 SCM活动的工具合用 。
支持工具的例子有,
—工作站,
—数据库程序, 和
—配置管理工具。
能力 4 SCM组的成员在有关进行其 SCM
活动的对象、规程和方法方面受到培训。
培训的例子包括,
—SCM标准, 规程和方法；和
—SCM工具。
能力 5 软件工程组和其它软件一有关
组的成员受到培训以便完成其 SCM活动。
其它软件一有关组的例子有,
—软件质量保证组, 和
—文档支持组 。
培训的例子有,
—在软件工程组和其它软件一有关组的内部
进行 SCM活动要遵循的标准, 规程和方法,
和
—SCM组的角色、职责和权力。
执行的活动
（ 10项）
活动 1 按照已文档化的规程对每
个软件项目准备一份 SCM计划。
这个规程一般规定,
1,SCM计划的制定是在
整个项目策划的早期
阶段, 并平行于整个
项目策划 。
2,受影响的组评审 SCM
计划 。
3,对 SCM计划进行管
理和控制 。
,进行管理和控制, 意味
着在给定时间 （ 过去或
现在 ） 使用的工作产品
的版本是已知的 （ 即版
本控制 ）, 而且以受控
的方式引进更改 （ 即更
改控制 ） 。
如果希望有比, 进行管理
和控制, 所蕴含的更高
程度的控制, 则工作产
品可置于配置管理的完
备的纪律之下, 正如在
本关键过程区域中所描
述的 。
活动 2 用已文档化的经批准的 SCM
计划作为进行 SCM活动的基础。
该计划包括,
1,将进行的 SCM活动, 活动的日程表, 指
派的职责和所要求的资源 （ 包括职员,
工具和计算机设施 ） 。
2,SCM需求和将由软件工程组及其它软件
一有关组进行的 SCM活动 。
活动 3 建立一个配置管理库系
统作为软件基线的仓库。
该库系统,
1,支持 SCM的多个控制层次 。
导致多个控制层次的情况例如,
—在生存周期的不同时间所需要的控
制层次不同 （ 例如, 随着产品成
熟要更加严密地控制 ）,
—纯软件系统和既包括硬件又包括软
件的系统所需要的控制层次不同 。
2,提供对配置项 /单元的存储和检
索功能 。
3,在受影响的组之间和在库内部的
控制层次之间提供配置项 /单元
的共享和传送 。
4,帮助使用配置项 /单元的产品标
准。
5,对配置项 /单元的归档版本提供
存储和恢复功能 。
6,帮助保证由软件基线库制造的产
品的正确生成 。
7,对 SCM记录提供存储, 更新的检
索功能 。
8,支持 SCM报告的编制 。
9,提供对库结构和内容的维护 。
库维护功能的例子有,
—库文件的备份 /重建, 和
—从库的错误中恢复 。
活动 4 标识将置于配置管理之
下的软件工作产品。
1,基于已文档化的准则选择配
置项 /单元 。
可标识为配置项 /单元的软件工
作产品的例子有,
—过程一有关文档 （ 例如：计划,
标准或规程 ）,
—软件需求,
—软件设计,
—软件代码单元,
—软件测试规程,
—为软件测试活动所构造的软件
系统,
—为交付给顾客或最终用户所构
造的软件系统,
—编译程序，和
—其它支持工具。
2,安排给每个配置项 /单元唯一
的标志符。
3,详细说明每个配置项 /单元的
特征 。
4,详细说明每个配置项 /单元所
属于的软件基线 。
5,详细说明在开发中将每个配
置项 /单元置于配置管理之下
的时间点 。
6,标识每个配置项 /单元的负责
人 (即从配置管理的角度来说
的所有者 )。
活动 5 按照已文档化的规程，
起动、记录、评审、批准和
跟踪对所有配置项或单元的
更改请求和问题报告。
活动 6 按照已文档化的规程控
制对基线的更改。
该规程一般规定,
1,进行评审和 (或 )回归测
试以保证更改不会造成
对基线的未料到的影响 。
2,仅仅那些经 SCCB批准的
配置项 /单元才能进入软
件基线库 。
3,以能保持软件基线库的
正确性和完整性的方式
进行配置项或单元的登
入和退出 。
登入或退出步骤的例子
有,
—验证修改是经审定的,
—建立更改日志,
—保持一份更改拷贝,
—更新软件基线库, 和
—建立被取代的软件基
线的档案 。
活动 7 按照已文档化的规程生成由软
件基线库制造的产品并控制它们的发行。
该规程一般规定,
1,SCCB审定由软件基线库制造的产品的
生成。
2,不论为内部使用或外部使用，由软件
基线库制造的产品仅仅由软件基线库中
的配置项或单元组成。
活动 8 按照已文档化的规程记
录配置项或单元的状态 。
该规程一般规定,
1,足够详细地记录配置管理行动, 使每个
配置项 /单元的内容和状态, 都是清楚的
并且能恢复以前的版本 。
2,对每个配置项 /单元维护其当前状态并
保留其历史 (即更改和其它行动 )。
活动 9 编制用文档记载 SCM活动和软件基线内容
的标准报告，并使受影响的组和个人可以使用它。
报告的例子包括,
—SCCB会议记录,
—更改申请的摘要和状态,
—问题报告的摘要和状态 （ 包括解决情况 ）,
—软件基线更改的摘要,
—配置项 /单元的修改历史,
—软件基线状态, 和
—软件基线审计结果。
活动 10 按照已文档化的规程
进行软件基线审计 。
该规程一般规定,
1,为审计作好充分准备 。
2,评估软件基线的完整性 。
3,评审配置管理库系统的结构和设施 。
4,验证软件基线库内容的完备性和正确性 。
5,验证与适用的 SCM标准和规程的符合性 。
6,向项目软件经理报告审计结果 。
7,跟踪得自审计的措施条款直至结束。
测量和分析
（ 1项）
测量 1 进行测量并将测量结果
用于确定 SCM活动的状态。
测量的例子有,
—每单位时间处理的更改申请数；
—SCM活动的里程碑的完成情况与计划相比
较；和
—在 SCM活动中所完成的工作、花费的工作
量和消耗的资金。
验证实施
(4项）
验证 1 高级管理者定期参与评
审 SCM活动 。
高级管理者定期评审的主要目的是在合适
的抽象层次上并以及时的方式了解和洞
察软件过程活动 。 评审间隔应该满足组
织的需要, 只要已存在报告例外情况的
合崐机制, 间隔可以长 。
参考软件项目跟踪和监督关键过程区域的
验证 1以便找到包括高级管理者监督评审
的典型内容的实践 。
验证 2 项目经理既定期地也事
件驱动地参加评审 SCM活动。
参考软件项目跟踪和监督关键过程区域的
验证 2以便找到包括项目管理者监督评审
的典型内容的实践。
验证 3 SCM组定期审计软件基
线以验证它们符合定义它们
的文档。
验证 4 软件质量保证组评审和审计有关
SCM的活动和工作产品，并报告其结果。
参考软件质量保证关键过程区域 。
至少, 评审和审计要验证,
1,以下各组对 SCM标准和规程的依照情况,
□ SCM组,
□ SCCB,
□ 软件工程组, 和
□ 其它软件一有关组 。
2,定期进行软件基线审计的情况 。
组织过程焦点（ L3）
? 组织过程焦点的目的是规定组织在改进
其整体软件过程能力的软件过程活动方
面的职责。
? 组织过程焦点活动的主要结果是一组软
件过程财富，它们在组织过程定义中加
以描述。
? 正如集成软件管理中所描述的，这些财
富供软件项目使用。
组织过程定义（ L3）
? 组织过程定义的目的是开发和保持一组
便于使用的软件过程财富，它们能改进
横跨项目的过程性能，并且为组织能获
得积累性的、长期的得益奠定基础。
? 这些财富提供一组稳定的基本原则，通
过诸如培训等机制就能使其成为制度。
? 培训在培训大纲中加以描述。
培训大纲（ L3）
? 培训大纲的目的是培育个人的技能和知
识，使他们能有效地和效率高地执行其
任务。
? 尽管培训是组织的责任，但是软件项目
应该识别出他们所需要的技能，当项目
需求独特时，该项目应提供所需要的培
训。
集成软件管理（ L3）
? 集成软件管理的目的是将软件工程活动和管理
活动集成为一个协调的、已定义的软件过程，
该过程是剪裁组织的标准软件过程和组织过程
定义中所描述的相关的过程财富而得到的。
? 剪裁基于项目的经营环境和技术需要，正如在
软件产品工程中所描述的那样。
? 集成软件管理是从等级 2 的软件项目策划与软
件项目跟踪与监督进化而得到的。
软件产品工程（ L3）
? 软件产品工程的目的是一致地执行一个
妥善定义的工程过程。
? 为了能有效地和效率高地生产正确的、
一致的软件产品，该工程过程集成全部
软件工程活动。
? 软件产品工程描述项目的技术活动，例
如，需求分析、设计、编码和测试。
组间协调（ L3）
? 组间协调的目的是为软件工程组积极参与其它
工程组工作制定一种方法，使得项目能更有效
地和效率高地满足顾客的需求。
? 组间协调是集成软件管理的一个涉及多科目的
方面，它延伸到软件工程之外。不仅应该集成
软件过程，而且软件工程组和其它组之间的相
互作用也必须加以协调和控制。
同行评审（ L3）
? 同行评审的目的是及早和高效地除去软
件工作产品中的缺陷。
? 一个重要的必然结果是增强对软件工作
产品和可预防的缺陷的了解。
? 同行评审是一种重要而又有效的工程方
法，在软件产品工程中采用此方法，可
通过法根（ Fagan） 式审查,结构化走查、
或者其它评审方法加以实施。
定量过程管理（ L4）
? 定量过程管理的目的是定量地控制软件过程的
过程性能。
? 软件过程性能表示遵循一个软件过程所得到的
实际结果。
? 焦点是在一个可测的稳定的过程范围内鉴别出
变化的特殊原因，并且适当时改正那些促使瞬
时变化出现的环境。
? 定量过程管理给组织过程定义、集成软件管理、
组间协调、和同行评审的实践附加了一个内容
丰富的测量计划。
软件质量管理（ L4）
? 软件质量管理的目的是建立对项目的软
件产品质量的定量了解和实现特定的质
量目标。
? 软件质量管理对软件产品工程中所描述
的软件工作产品，实施内容丰富的测量
计划。
缺陷预防（ L5）
? 缺陷预防的目的是鉴别缺陷的原因并防
止它们再次出现。
? 正如在集成软件管理中所描述的，软件
项目分析缺陷、鉴别其原因并更改项目
定义软件过程。
? 正如在过程更改管理中所描述的，应将
具有普遍价值的过程更改通知给其它软
件项目。
技术改进管理（ L5）
? 技术改进管理的目的是识别出能获利的
新技术（即工具、方法和过程），并以
有序的方式将它引进到组织中去，正如
在过程改进管理中所描述的那样。
? 技术改进管理的关注焦点是在不断变化
的环境里高效率地创新。
过程改进管理（ L5）
? 过程改进管理的目的是出于改进软件质
量、提高生产率和缩短产品开发周期的
目的，持续不断地改进组织中所采用的
软件过程。
? 过程改进管理既采用缺陷预防的增量式
改进，又采用技术改进管理的创新式改
进，并使得整个组织可以享用这些改进。
CMM评估
CMM评估方法
软件过程评估（ CBA-IPI）, 目的是确定一个组
织的当前软件过程的状态，找出组织所面临的
急需解决的软件过程有关问题，进而有步骤地
实施软件过程改进，使组织的软件过程能力不
断提高。
软件能力评价（ SCE）, 目的是识别合格的能完
成软件工作的承制方，或者监控承制方现有软
件工作中软件过程的状态，进而提出承制方应
改进之处。
CBA-IPI
软件过程评估 是在开放、合作的环境中进行的，
评估目的在于暴露问题和帮助经理和工程师们
改进他们的软件过程，一般都能得到较好的支
持。评估过程中虽然提问单是个重要工具，但
更重要的是通过各种会谈了解组织的软件过程。
评估的结果除了识别组织所面临的软件过程问
题外，最有价值的还是：明确软件过程的改进
途径，促进制订进一步的行动计划，使全组织
关注改进过程，增强执行改进行动计划的动力
和热情。
SCE
? 软件能力评价 是在更象审计的环境中进
行。评价的目的与金钱密切相关，评价
组的推荐性意见将影响挑选承制方或设
置资金。评价过程的重点放在复审已文
档化的审计记录上，这些记录能揭示组
织实际执行的软件过程。
评估方法特点
? 采用成熟度提问单作为现场访问的出发点；采
用 CMM作为指导现场调查研究的导引图；
? 利用 CMM中的关键过程域生成明确地指出软件
过程强项和弱项的调查发现清单；
? 在对关键过程域目标满足情况进行分析的基础
上，衍生出一个剖面；
? 根据调查发现清单和关键过程域剖面，向合适
的对象提出结论意见。
CMMI的提出
广泛使用的各种 CMM模型
?软件 CMM 阶段式 软件开发
?系统工程 CMM 连续式 系统工程
?系统工程能力模型 连续式 系统工程
?软件获取 CMM 阶段式 软件获取
?系统安全性工程 CMM 连续式 安全性工程
?个体软件过程 阶段式 个体软件开发
?FAA-iCMM 连续式 软件工程, 系统工程和获取
?IPD-CMM 混合式 集成产品开发
?人员 CMM 阶段式 劳动力
?SPICE模型 连续式 软件开发
问题
? 系统学科与软件学科在传统
上没有很好地集成在一起
? 软件在系统中的重要性引人
注目地增长
? 例如：分配给软件的需求
百分比 *
? B-2 -- 65%
? F-22 -- 80%
? 美国国防部强调，要使系统 /
软件的接口更好地做到无缝
联接
Systems Software
* Source,Standish Group Chaos Report
模型太多，时间太少
软件
CMM
系统安全性
工程
CMM
系统工程
Engr
CMM 人员
CMM
ZZZ
CMM
FAA
iCMM
IPD
CMM 软件获取 CMM
EIA 731 ? 不同的结构, 格式, 术
语, 度量方法
? 尤其是使用一个以上的
模型时, 容易混淆
? 在一个联合改进程序中
难于集成这些模型
? 在供应商的选择中难于
使用多个模型
CMMI 来解决问题 !
? 在一个过程改进框架内集成系统和
软件学科
? 提供一个在需要时可以引入新学科
的框架
CMMI为分离构筑了“桥梁”
? 将系统工程和软件
工程集成在一起
? 将系统学科和软件
学科集成为一个过
程改进框架
? 当出现需求时, 为
引进新学科提供框
架
但是 CMMI不做,.,
? 一些组织将他们视为仅有一个学科
? 软件
? 系统
? 获取
? 但是 …
? 软件始终必然是某种系统的组成部分
? 没有系统的软件是罕见的
? 获取的可能两者都包括
? 与其它学科的沟通与合作，即使它们在我们组
织的外部，也是至关重要的
CMMI项目
? 由 DoD赞助的工业界、政府和 SEI之间的协作体
? 有 100多人参与
? 美国陆军、海军、空军
? 联邦航空局
? 国家安全部
? 软件工程研究所
? ADP,Inc,
? AT&T 实验室
? BAE
? 波音公司
? 计算机科学有限公司
? EER 系统
? 加拿大爱立信公司
? Ernst和 Young
? 通用动力公司
? Harris 有限公司
? Honeywell公司
? KPMG公司
? Lockheed Martin公司
? 摩托罗拉公司
? Northrop Grumman
? Pacific Bell
? Q-Labs
? Raytheon公司
? 路透社
? Rockwell Collins公司
? SAIC公司
? 软件生产率联盟
? Sverdrup 有限公司,
? TeraQuest公司
? Thomson CSF公司
? TRW公司
CMMI 模型
源 Models
?将系统工程和软件工程相结合
?可以应用于,
?一个组织中的软件工程项目
?一个组织中的系统工程项目
?应用于上述两者
?IPPD 可以用于其中一种情况
或者包括其两者
? 软件能力成熟度模型 V2,
草案 C (SW-CMM V2C)
? EIA过渡标准 731,系统工
程能力模型 (SECM)
? 集成产品开发能力成熟度
模型,草案 V0.98 (IPD-
CMM)
CMMI成套产品
? 模型
? 学科
? 系统工程 SE
? 软件工程 SW
? 集成产品和过程开
发 (IPPD)
? 供应商来源 (SS)
? 表示法
? 阶段式
? 连续式
? 培训
? 模型
? CMMI介绍
? 中间概念
? 教师培训
? 主任评估师
? 评估方法
? CMMI 评估需求 (ARC)
? SCAMPI 方法描述文
档 (MDD)
CMMI 简要说明
? CMMI模型提供了组织过程改进的一
个结构化视角
? CMMI能够帮助
? 设定过程改进目标和优先级
? 提供优质过程的指南
? 提供评价当前实践的准绳
铭记
? 模型 不是 过程
? 模型说明做什么, 不是 说明如何去做或
者谁去做
CMMI结构
CMMI成套产品
? 模型
? 学科
? 系统工程 SE
? 软件工程 SW
? 集成产品和过程开发
(IPPD)
? 供应商来源 (SS)
? 表示法
? 阶段式
? 连续式
? 培训
? 模型
? CMMI介绍
? 中间概念
? 教师培训
? 主任评估师
? 评估方法
? CMMI 评估需求 (ARC)
? SCAMPI 方法描述文
档 (MDD)
CMMI 模型集
? CMMI-SW,V1.1,阶段式
? CMMI-SW,V1.1,连续式
? CMMI-SE/SW,V1.1,阶段式
? CMMI-SE/SW,V1.1,连续式
? CMMI-SE/SW/IPPD,V1.1,阶段式
? CMMI-SE/SW/IPPD,V1.1,连续式
? CMMI-SE/SW/IPPD/SS,V1.1,阶段
式
? CMMI-SE/SW/IPPD/SS,V1.1,连续
式
? SE 系统工程
? Systems Engineering
? SW 软件工程
? Software Engineering
? IPPD 集成产品和过程开发
? Integrated Product and
Process Development
? SS 供应商来源
? Supplier Sourcing
ML 1
ML2
ML3
ML4
ML5
.,,作为整个组织已建立
的一个过程域集合
连续 式
.,,作为单一过程域
或者过程域集合
过程域能力
PA PA PA
模型表示法的比较 阶段 式
过程域能力与组织成熟度
?过程域能力和组织成熟度是相似的概念
?它们之间的区别是
?过程域能力 将一组过程与 单个过程域 或特定实
践相联系
?组织成熟度 适用于跨越组织的一组过程域
?通常，如果组织过程集被评估达到一定的
成熟度等级，评估的过程可以证明达到相
应的过程能力级别
为什么有两种表示法？
? 源模型遗产
? 软件 CMM— 阶段式
? 系统工程 CMM— 连续式
? IPD CMM— 混合式
? 每种表示法的支持者都是 CMM产品开发组的
一部分
? 选择单一表示法变得, 太难,
? 首先支持等量内容的模型的两种表示法是采用
了折衷方法
阶段式表示法的优点
? 提供一个预定义的组织级改进的路线图,
基于一组过程, 其组成和顺序及相关的
组织关系已证明
? 过程域组成
? 实现的先后顺序
? 从 SW-CMM转移过来的常见结构
连续式表示法的优点
? 根据商业目标及目的, 选择所关注的特
定过程域, 为过程改进提供最大的灵活
性
? 从系统工程社团转移过来的常见结构
CMMI结构,一个模型,两种表示法
成熟度等级 5
OID,CAR
成熟度等级 4
OPP,QPM
成熟度等级 3
REQD,TS,PI,VER,
VAL,OPF,OPD,OT,
IPM,RSKM,DAR
综述
引言
模型结构
模型术语
成熟度等级、公共特性、共性实践
理解模型
应用模型
成熟度等级 2
REQM,PP,PMC,
SAM,MA,PPQA,CM
附录
CMMI-SE/SW
阶段的
工程
REQM,REQD,TS,
PI,VER,VAL
项目管理
PP,PMC,SAM
IPM,RSKM,QPM
过程管理
OPF,OPD,OT,
OPP,OID
Process Management
PAs
- Goals
- Practices
支持
CM,PPQA,MA,
CAR,DAR
附录
综述
引言
模型结构
模型术语
能力等级、共性模型构件
理解模型
应用模型
CMMI-SE/SW
连续的
CMMI结构
CMMI 连续式描述的结构
CMMI连续式描述结构
Generic Goals
Process Area 2 Process Area 1 Process Area n
Specific Goals
能力等级 共性实践
共性目标
过程域 2 过程域 1 过程域 n
特定目标
特定实践
过程域能力剖面
过程域能力剖面可以表示为两维平面上的一组点
? 过程维
? 你都做了, 什么,
? 能力维
? 你做的有, 多好,
能力
(多好
)
过程域 (你做了什么 )
过程维
? 这条轴上的值代表你执行的过程
（用 过程域 描述）
过程
过程域 1 过程域 n 过程域 2 过程域 3
能力
过程域
? 过程域 (PAs)是一族相关实践
? 它们是建立过程能力的主要建筑石
块
? 过程域示例：, 需求管理,
连续的过程域组织
需求管理
需求开发
技术解决方案
项目集成
验证
确认
工程 （ 6）
项目管理 （ 8） 项目计划
项目监督和控制
供应商协议管理
集成项目管理 (IPPD)
集成供应商管理 (Supplier Sourcing,SS)
集成组队 (IPPD)
风险管理
定量项目管理
组织级过程焦点
组织级过程定义
组织级培训
组织级过程性能
组织级创新和施展应用
过程管理 （ 5）
配置管理
过程和产品质量保证
度量和分析
因果分析和解决方案
决策分析和解决方案
集成的组织环境 (IPPD)
支持 （ 6）
分 类 过程域
能力维 -1
? 这条轴上的值代表你执行的一个过程
有多好（称作 能力等级 ）
过程没有执行
能力
过程
过程域 1 过程域 n 过程域 2 过程域 3
能力维 -2
? 这条轴上的值代表你执行的一个过程
有多好（称作 能力等级 ）
过程没有执行
能力
过程
过程域 1 过程域 n 过程域 2 过程域 3
过程执行得很好
并且被持续改进
能力等级
? 能力等级是描述过程域能力的明确定义
进化平台的
? 有 6个能力等级
? 每个等级都是连续过程改进的基础层次
? 因此，能力等级是积累的，即，高的能
力等级包括低等级的属性
能力等级
5 Optimizing 优化
4 Quantitatively Managed 已定量管理的
3 Defined 已定义的
2 Managed 已管理的
1 Performed 已执行的
0 Incomplete 不完善的
能力等级是积累的
? 由于能力等级建立在低等级的基础
上，因此它们之间不能够有缝隙
表示过程能力
? 已实现的过程的能力可以用一根棒
来表示
过程
能力
该点表示
在特定过
程域比下
点更高的
能力等级
3
2
1
0
过程域 n
过程域能力剖图举例
过程域
REQM PP PMC etc
5
4
3
2
1
0
能力
清晰在 CMMI连续模型中的概念
? 目标 和 实践 是用来清晰能力和过程
维的取值的模型元素
? 目标
? 通过有效地实现一组实践而达到的
结果的高层次描述
? 实践
? 对对实施一个过程域的关键元素所
必须的行动的描述
有两种类型的目标和实践
? 特定目标 和 特定实践
? 实现过程维数
? 所以, 应用于特别的过程域
? 共同目标和共性实践
? 实现能力维数
? 所以, 应用于全部所有过程域 。
示例：特定目标和特定实践
? 特定目标（需求管理过程域）
? 管理被需求，并且与项目计划和工作
产品之间的不一致被识别。
? 特定实践（需求管理过程域）
? 在需求和项目计划及工作产品之间维
护双向的可追踪性。
示例：共性目标和共性实践
? 共性目标（能力等级 1）
? 过程通过将可以确认的输入工作产品转换为
可以确认的输出工作产品，支持和使得本过
程域的特定目标达到
? 共性实践（能力等级 1）
? 执行过程域的基础活动去开发工作产品和
提供服务，以达到本过程域的特定目标
CMMI连续表示的结构
共性目标
&
共性实践
共性目标
&
共性实践
特定目标
&
实践
特定目标
&
实践
关键区别
已执行 对比 已管理
过程被策划、绩效被参照计划管理、需要时纠正行动被
采取的程度
已管理 对比 已定义
应用过程描述、标准和过程的范围（即项目与组织）
已定义 对比 已定量管理
过程绩效的可预告
已定量管理 对比 优化
通过处理过程偏差的共同原因，过程被连续地改进
改进过程域
CL0 没有执行，不完善 没有 GPs或 SPs存在
GP1.1
CL1 (基础 ) SPs
GP1.1 到 GP2.10
CL1 + CL2* SPs
GP1.1 到 GP3.2
CL1+CL2*+CL3* SPs
GP1.1 到 GP4.2
CL1+CL2*+CL3* SPs
GP1.1 到 GP5.2
CL1+CL2*+CL3* SPs
CL1
已执行 执行工作
CL2
已管理
坚持方针，遵照文档记录的计划和过程，应用适当的资源,
分配责任和权力，培训人员，应用配置管理，监督，控制,
评价过程，识别和包含利益相关者，带有评审的管理
CL3
已定义
项目的过程裁剪于组织标准过程,
定性了解过程,
过程对组织资产作贡献
CL4
已定量管理
度量过程绩效
稳定过程，控制图,
处理特定偏差的原因
CL5
优化
缺陷预防，主动抢先改进,
创新技术引入和运用
* 高级实践只在工程过程域中存在
共性目标和实践 GG1（ CL1）
GG1,达到特定目标
GP1.1,执行基础实践
共性目标和实践 GG2（ CL2）
GG2,制度化已管理过程
所有 CL1 共性实践（ +）
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
共性目标和实践 GG3（ CL3）
GG3：制度化已定义过程
所有 CL1 & CL2 共性实践（ +）
GP3.1,建立已定义的过程
GP3.2,采集改进信息
共性目标和实践 GG4（ CL4）
GG4,制度化已定量管理过程
所有 CL1 & CL2 & CL3 共性实践（ +）
GP4.1,对过程建立定量目标
GP4.2,稳定子过程绩效
共性目标和实践 GG5（ CL5）
GG5,制度化优化过程
所有 CL1 & CL2 & CL3 & CL4 共性实践（ +）
GP5.1,确保连续过程改进
GP5.2,纠正问题的根本原因
需求管理：能力等级 1 & 2
需求管理
特定实践（ CL1 –,基础”）
SP1.1-1,获得需求理解
SP1.3-1,管理需求变更
SP1.5-1,识别项目工作与需求的不一致性
共性实践（ CL1）
GP1.1,执行基础实践
特定实践（ CL2 -,高级” ）
SP1.2-2,获得需求承诺
SP1.4-2,维护需求的双向可追踪性
共性实践（ CL2）
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
需求管理：能力等级 3
需求管理
特定实践（ CL1 & CL2）
SP1.1-1,获得需求理解
SP1.2-2,获得需求承诺
SP1.3-1,管理需求变更
SP1.4-2,维护需求的双向可追踪性
SP1.5-1,识别项目工作与需求的不一致性
共性实践（ CL1 & CL2）
GP1.1,执行基础实践
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
特定实践（ CL3）
全部 CL1 & CL2 特定实践
共性实践（ CL3）
所有 CL1 & CL2 共性实践，再加上（ +）,
GP3.1,建立已定义的过程
GP3.2,采集改进信息
需求管理：能力等级 4 & 5
需求管理
特定实践 （ CL4）
所有 CL1 & CL2 特定实践
共性实践（ CL4）
所有 CL1 & CL2 & CL3 共性实践，再加上（ +）,
GP4.1,对过程建立定量目标
GP4.2,稳定子过程绩效
特定实践 （ CL5）
所有 CL1 & CL2 特定实践
共性实践（ CL5）
所有 CL1 & CL2 & CL3 & CL4 共性实践，再加上（ +）,
GP5.1,确保连续过程改进
GP5.2,纠正问题的根本原因
小结
? CMMI 模型的产生得到了广泛的参与和评
审
? 过程域确定, 你做什么,
? 能力等级确定, 你做得有多好,
CMMI结构
CMMI 阶段式描述的结构
CMMI阶段表示法的结构
成熟度等级
过程域 过程域 过程域
共性目标 特定目标
执行承诺 执行能力 定向实现 验证实现
公共特性
执行承诺,建立方针，并担保资助者承诺的过程改进工作
执行能力,确保项目和 /或组织为继续过程改进拥有所需资源
定向实现, 收集、度量、分析与过程相关的数据
验证实现,验证项目和 /或组织的活动与需求、过程和规程相符合
共性实践 特定实践
成熟度等级
? 成熟度等级对成为成熟的组织的途
径的明确定义的进化平台
? 有五个成熟度等级
? 每个等级是连续过程改进的基础层
次
成熟度等级
过程不可预测，缺乏
控制，反应式的
项目描绘过程, 而且经
常是反应式的
组织刻画过程，并且是
预测式的
过程经过了度量和控制
关注点在过程改进
定量管理的
已定义的
执行的
已管理的
优化的
1
2
3
4
5
CMM 成熟度等级
初始级 (1)
已定义级 (3)
可重复级 (2)
优化级 (5)
已管理级 (4)
规范的过程
标准一致的过程
可预测的过程
持续改进的过程
组织级的成熟度
? 组织级的成熟度是靠一组过程的能力结
合起来表现的
? 在这组过程中, 选出了一套适合组织过
程改进需要的过程
成熟度 1级：初始级
? 过程在执行, 但常常是即兴管理的
? 性能取决于精英的努力
? 高质量和期望的性能是可能的, 只要指
派最好的人来执行任务
? 性能很难预测
? 管理层实践可能是无效的
性能不可预测
? 需求流入
? 产品有时通过一些无形的过程生产出来
? 产品流出及运行 （ 希望可工作 ）
输出 输入
成熟度 2级：已管理级
? 项目管理更规范化了
? 组织方针建立且遵循了
? 项目计划和过程描述文档化了且遵循了
? 提供了适当的资源
? 全生命周期指派责任和授权重点需要建立有效的软件
项目管理
? 小项目可预测成功基于过去的经验
? 规范有助于确保现有的实践在时间压力下保留下来
? 对管理人员来说, 活动和工作产品的状态在预定义的
点上是可见的
过程被管理
? 需求流入
? 按照方针开发项目计划
? 活动按照计划执行
? 在定义的点度量和评审
? 产品流出及运行 （ 通常 ）
CMMI的已管理级
?需求管理：管理项目的产品和产品构件的需求, 并标识那些
需求与项目的计划和工作产品的不一致
?项目计划：建立和维护定义项目活动的计划
?项目监督和控制：提供对项目进展的了解, 以便在项目性能
与计划有重大偏离时采取适当的纠正行动
?供应商合同管理：通过正式的协议, 管理从供应商获取的产
品
?度量和分析：开发和维持用于支持管理信息所需要的度量能
力
?过程和产品的质量保证：将对过程及其相关工作产品的客观
评价提供给项目成员和管理部门
?配置管理：使用配置标识, 配置控制, 配置状态报告和配置
审计, 建立和维护工作产品的完整性
成熟度 3级：已定义级
? 建立在已管理级 L2——项目管理基础之上
? 工程过程更有效的实施
? 组织有预测式活动
? 已计划了培训
? 组织有了标准的过程, 项目可根据自己的需要裁减过
程
按照已定义过程管理
? 在过程中, 角色和职责分明 。
? 软件产品的生产在整个软件过程是可见
的 。
CMMI的已定义级 -1
? 需求开发：产生和分析客户, 产品和产品构件的需求
? 技术解决方案：设计, 开发和实现对需求的解决方案 。
解决方案, 设计和实现包括产品, 产品构件以及与单
一的或适当组合的生命周期过程相关的产品
? 产品集成：把产品构件组装成产品, 确保该集成产品
的功能正确并并付该产品
? 验证：确保所选择的工作产品满足规定的需求, 即满
足该产品的需求规格说明
? 确认：证实产品和产品构件置于预期的环境时, 满足
预期的用途, 即满足其可操作性要求
CMMI的已定义级 -2
?组织级过程焦点：基于对组织的过程和过程资产的当前
的强项和弱项的透彻理解, 计划和实现组织级过程改进
?组织级过程定义：建立和维护一个有用的组织级过程资
产集
?组织级培训：开发人员的技能和知识, 使他们能有效地
和高效地执行其任务
?集成化项目管理：根据从组织级标准过程集裁剪而来的
一个集成的和已定义的过程, 建立和管理该项目以及该
项目相关人员的参与
?集成供应商管理：主动地识别可以满足项目需求的产品
来源, 主动地管理所选择的供应商的产品以及维护项目
与供应商的合作关系的过程
CMMI的已定义级 -3
? 风险管理：在问题出现之前标识潜在的问题, 以便在
需要时可以计划产品或项目的全生命周期的风险处理
活动, 以缓解对达到目标的负面影响
? 决策分析和解决方案：使用一个正式的评价过程, 按
照已经制定的准则, 评价已标识的各种不同方案, 分
析各种可能的决策
? 组织级集成环境：提供一个产品和过程集成化开发
（ IPPD） 的基础设施 （ 包括方法和环境 ）, 并管理与
集成相关的人员
? 集成组队：为工作产品的开发组成和保持一个集成化
群组
成熟度 4级：定量管理级
? 在组织和项目级使用统计的及其他定量的方法
? 了解过去过程的性能
? 预测将来过程性能
? 预测将来项目质量和服务质量
? 项目使用要度量的目标来满足客户, 最终用户
和组织的需要
? 管理者和工程师在管理过程和结果中使用统计
的和其他量化技术的数据
定量的管理产品和过程
? 过程的行为是可预测的和量化的理解的
? 为达到建立的产品质量, 服务质量和过
程性能目标, 存在一个作出结论的量化
依据
CMMI的定量管理级
? 组织级过程性能：建立和维护对组织的
标准过程集的性能的定量理解, 以支持
质量和过程性能目的；并提供过程性能
数据, 基线和模型, 以定量地管理组织
的项目
? 项目定量管理：定量地管理项目的已定
义过程, 已达到项目所建立的质量和过
程性能目标
理解定量管理级
? 应用统计过程控制理论
? 处理过程变化的特殊原因
? 标识在过程中的问题
? 特殊原因控制图
成熟度 5级：优化级
? 经过分析解决过程偏离的公共原因
? 度量用于
? 选择过程改进和革新
? 估计过程改进和革新的效益和费用
? 度量过程改进和革新的实际的费用和效益
理解优化级
? 标识和消除不佳性能的原因
? 持续改进软件过程 。
重点在持续过程改进
CMMI的优化级
? 组织级改革和实施：根据组织的业务目
的, 选择和实施增量式和改革式的改进,
以便可度量地改进组织的过程和技术,
以支持组织的质量和过程性能目的
? 因果分析与解决方案：标识缺陷和其它
问题的原因, 并采取措施以预防它们将
来再次发生
不能跨越成熟度等级
? 成熟度等级提供了在更高层次有效实现
过程的必要基础
? 更高层次过程没有低层次提供的纪律是很容
易被牺牲的
? 在一个嘈杂的过程中创新的努力是暗淡的
? 更高成熟度等级的过程可以被组织在更
低成熟度等级执行，风险是在出现危机
时不能一致地应用
不能跨越成熟度等级
? 过程的能力以阶梯式建立的, 当其它过程不稳
定时, 一些过程是无效的 。
? 每一级为下一级改进提供了必要的基础 。
? 任何软件开发单位在致力于软件过程改善时,
只能由所处的层次向其紧邻的上一层次进化,
即过程的进化是渐进的, 不能是跳跃的 。 事实
上, 在由某一个成熟层次向上一更成熟的层次
进化时, 在原有层次中的那些已经具备的能力
应该得到保持与发扬 。
过程域
? 过程域 （ PAs） 是为达到一个目标集
所共同执行的相关实践集
? 在建立组织过程能力时, 这些过程
域是主要的建造块
? 每个过程域都定义在特定的成熟度
等级上
成熟度等级上的过程域
组织级创新和发展
因果分析与解决方案 5 优化的
4 定量管理的
3 已定义的
2 已管理的
连续的过程改进 （ 2）
定量管理 （ 2）
过程标准化 （ 14）
基本项目管理 （ 7）
组织级过程性能
定量项目管理
需求开发
技术解决方案
产品集成
验证
确认
组织级过程焦点
组织级过程定义
组织级培训
集成项目管理
集成供应商管理
风险管理
决策分析和解决方案
集成的组织环境
集成组队
需求管理
项目计划
项目监督和控制
供应商协议管理
度量和分析
过程和产品质量保证
配置管理
1 执行的
过程域 级 别 焦 点
(IPPD)
(IPPD)
(Supplier Sourcing,SS)
示例：特定目标和特定实践
? 特定目标（需求管理过程域）
? 管理被需求，并且与项目计划和工作
产品之间的不一致被识别。
特定实践（需求管理过程域）
– 在需求和项目计划及工作产品之间维
护双向的可追踪性。
示例：共性目标和共性实践
? 共性目标（成熟度等级 2）
? 制度化已管理过程
? 共性实践（成熟度等级 2）
? 建立组织方针
共同特征
共同特征是对共性实践的一种分类,
? 执行承诺,
建立管理方针
? 执行能力,
建立和维护计划，资源，分配的责任和权力，培训
? 定向实现,
度量，控制，执行实践
? 验证实现,
确保落实和一致
从另一个方向观察共同特征的
? 共同特征分类对所有过程域是非常类似
的
? 它们被作为制度化共同特征所提及，因
为它们,
? 确保过程域是有效的，可重复的和持久的
? 提供需要的基础支持
共同特征示例 —1（需求管理）
? 执行承诺,
? 为了计划和执行需求管理过程建立和
维护一个组织方针
? 执行能力,
? 对执行或者支持需求管理过程的人员
进行必要的培训
共同特征示例 —2（需求管理）
? 定向实现,
? 将需求管理过程指定的工作产品置于
适当的配置管理级别下
? 验证实现,
? 与高层管理人员一起评审需求管理过
程的活动、状态和结果并解决问题
GG2 制度化已管理过程
执行承诺
GP 2.1 (CO 1) 建立组织方针
执行能力
GP 2.2 (AB 1) 策划过程
GP 2.3 (AB 2) 提供资源
GP 2.4 (AB 3) 分配责任
GP 2.5 (AB 4) 培训人员
定向实现
GP 2.6 (DI 1) 管理配置
GP 2.7 (DI 2) 识别和包含利益相关者
GP 2.8 (DI 3) 监督与控制过程
验证实现
GP 2.9 (VE 1) 客观评价遵从性
GP 2.10 (VE 2) 与高层管理人员评审状态
GG3 制度化已定义管理过程
执行承诺
GP 2.1 (CO 1) 建立组织方针
执行能力
GP 3.1 (AB 1) 建立已定义的过程
GP 2.2 (AB 2) 策划过程
GP 2.3 (AB 3) 提供资源
GP 2.4 (AB 4) 分配责任
GP 2.5 (AB 5) 培训人员
定向实现
GP 2.6 (DI 1) 管理配置
GP 2.7 (DI 2) 识别和包含利益相关者
GP 2.8 (DI 3) 监督与控制过程
GP 3.2 (DI4) 采集改进信息
验证实现
GP 2.9 (VE 1) 客观评价遵从性
GP 2.10 (VE 2) 与高层管理人员评审状态
CMMI结构
阶段式描述与连续式描述的等
价关系
级别等价的一般准则
? 要达到成熟度等级 2，所有分配给成熟度等级 2
的过程域都必须达到能力级别 2或以上
? 要达到成熟度等级 3，所有分配给成熟度等级 2
和 3的过程域都必须达到能力级别 3或以上
? 要达到成熟度等级 4，所有分配给成熟度等级 2、
3和 4的过程域都必须达到能力级别 3或以上
? 要达到成熟度等级 5，所有的过程域都必须达
到能力级别 3或以上
成熟度等级 2对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 3对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 3对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程域
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 5对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程域
成熟度等级 4
过程域
成熟度等级 5
过程域
小结
? 1个 CMMI模型 2种表示方式，阶段式和连续式
? 两种表示方式的实质内容相同，只是内容组织不同
? 每种表示方式提供不同的实现过程的途径
? 应用 CMMI模型应当使用智慧、普遍的见识和专业的判
断
? 连续式
? 使用灵活，组织可以选择看重的领域
? 提供与阶段表示等价的等级划分
? 阶段式
? 按照基于证实的过程分组和顺序去实现的方式构建
谢谢！
汤铭端
68389085（ O） 68215365（ FAX）
mdtang@btamail.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第十一讲
软件能力成熟度模型（ SW-CMM）
集成能力成熟度模型（ CMMI）
介绍
内容
? SW-CMM的提出
? SW-CMM的结构
? SW-CMM的关键过程区域
? CMMI的提出
? CMMI的结构
? CMMI的过程区域
SW-CMM和 CMMI的提出
质量的杠杆作用点
每个人都体会到主动积极的优质劳动力的
重要性, 但是 ……
…… 如果不理解过程，或者过
程不是在“最佳实践”下运
行，即使我们的精英也无法
使工作达到最佳的状态
人员
过程 技术
过程是产品成本、进度和质量的主要
决定因素
项目成功的支柱
过程管理 技术资产 人力资源 客户 — 供应商关系
什么是过程
? 如何定义过程？
过程的一般定义
过程 是指为了达到给定目的而执行的实践的集合；
它可能包括工具、方法、资料和 /或人
过程 是指为了达到给定目的而执行的一系列活动
的有序集
经常将过程描述成是三元组“过程 —人员 —技术”
中的一个元素，也可以认为它是联合其它元素
的,粘合剂” 人员
技术 过程
过程是三个杠杆作用点之一
工具
- 项目管理工具
- 软件开发工具
人
- 管理者
- 工程师
过程
- 标准软件过程
- 持续过程改进
过程改进的基本前提
“产品质量主要取决于用于
开发和维护该产品的过程
的质量”。
基于 Shewhart,Juran,Deming 和 Humphrey 倡导的
TQM原理
早期的过程改进
? 过程管理理论是 Deming,Crosby,Juran以及其
他一些人的概念的综合
? 在过去的 30年里, 这些理论已经用于解决许多
组织的共同问题
? 虽然已经有了解决方案, 但是现有的实践水平
与技术发展水平之间仍有一定的差距
? 其中的许多概念已经用于建立过程改进模型
软件过程 —外行的观点
客户 程序员
“为我的产品
开发一个软件”
然后奇迹发生 完成。
该过程的潜在问题
? 开发队伍角色未定义，不协调
? 团队工作和过程绩效由于执行的间隙和冲突而
削弱
? 对过程和产品质量的洞察有限
? 对产品配置的控制有限
? 发行比原始进度推迟
? 成本比估计的大得多
? 软件不是客户所需要得
软件过程 —内行的初步观点
描述
编码
观察
能否工作
因素 特征
管理相关 没有觉察，太忙
项目成员 差的培训，缺乏经验，没有组织
开发过程 未定义，任意
管理类型 危机管理
产品质量 没有度量
产品配置 没有控制
项目成功 依赖于英雄
不成熟组织的共同特征
不成熟组织产生的共同结果
因素 结果
需求 缺乏控制，需求“不断懦动”
产品性能 不可预估，不能满足用户需要
产品配置 没有管理
产品质量 不可知，充满缺陷
成本 缺乏追踪，经常超越
进度 经常延迟
早期的过程改进
? 过程管理理论是 Deming,Crosby,Juran以及其
他一些人的概念的综合
? 在过去的 30年里, 这些理论已经用于解决许多
组织的共同问题
? 虽然已经有了解决方案, 但是现有的实践水平
与技术发展水平之间仍有一定的差距
? 其中的许多概念已经用于建立过程改进模型
什么是过程模型？
? 模型是描述有效过程特征的元素的结构
化集合
? 这里所涵盖的过程是指那些通过经验证
明为有效的过程
如何使用模型？
? 模型是用来,
? 帮助建立过程改进的目标和优先次序, 协助
改进过程, 并为确保建立一个稳定的, 有能
力的以及成熟的过程提供指南
? 作为组织过程改进的指南
模型为什么重要？
? 模型提供了
? 过程改进的出发点
? 社团过去经验的结晶
? 共同的语言和共享的构想
? 活动优先次序的框架
模型
“所有的模型都是错误的，但有些是有用
的。,
“All models are wrong,but some are
useful.”
? George Box
? 提供对真实世界认识的简单近似
使用什么模型？
? 从历史的角度讲, 是以学科建立模型,
如,
? 软件工程
? 系统工程
? 软件获取
? 系统安全, 等等
CMM的产生背景
? 美国国防部在向承包商发包军用软件项目时，
希望了解承包商的开发能力，以保证项目的成
功和产品质量
? 美国国防部委托美国卡内基 -梅隆大学的软件工
程研究所（ CMU-SEI） 进行研究
? SEI基于项目成功很大程度依赖于其开发过程
的经验，提出包含 5级的软件能力成熟度模型
（ SW-CMM）
? 美国国防部要求其承包商的能力成熟度至少为
3级
CMM的产生历程
? 1987年美国软件工程研究所 (SEI） 以
W.S.Humphrey为首的研究组发表的“承
包商软件工程能力的评估方法”
? 1991年发展为 SEI CMM1.0（ 能力成熟度
模型 1.0版）
? 1993年该模型发展为 SEI CMM 1.1（ 现
行有效）
CMM的基础
? 阶段化结构：基于过去 60年来的产品质
量原则。
? Walter Shewart在三十年代发表了统计质量
控制原理。 W.Edwards Deming 和 Joseph
Juran 又进一步发展和论证了该原理。
成熟度框架,Philip Crosby在,Quality is
Free”中描述了质量管理成熟度框架的五
个进化阶段。
? IBM等的工程实践。
什么是 CMM？
?能力成熟度模型
? 一个在特定学科中的成熟实践的参考模型, 用于评估一个
组履行该学科任务的能力
?CMM有不同模型, 从以下不同的方面来区分,
? 学科 （ 软件, 系统, 获取等 ）
? 结构 （ 阶段和连续式 ）
? 成熟度的程度 （ 过程改进的路线 ）
? 能力的程度 （ 制度化 ）
?软件工程研究所 （ SEI） 的, 能力成熟度模型 ?” 和 CMM?是
一种成熟度模型 。
?能力成熟度模型 ?,CMM?,CMM Integration和 CMMI是卡
内基梅隆大学的服务标志和注册商标
IDEALSM 模型
启 动
诊 断
建 立
行 动
学 习
修改
组织级方法
文档化教训
和分析教训
定义过程
和度量
计划和执行
试验过程
计划、执行
和跟踪装置
建立过程
行动组
计划行动项 设置优先级
和策略
提出建议并将
结果文档化
评估和刻画
当前的状态
建立
基础设施
设置语境和
建立出资方
改进的促进
因素
SM IDEAL 是 CMU的服务标志 。
SW-CMM的结构
软件过程 ——术语
? 人们用于开发和维护软件及其相关产品
(例如，项目计划、设计文档、代码、测
试用例、用户手册等等 )的一系列活动、
包括软件工程活动和软件管理活动。
软件过程能力 ——术语
? 描述（开发组织或项目组）通过遵循其软件过
程能够实现预期结果的程度 。
一个软件开发组织或项目组的软件过程能力提供
一种预测该组织承担下一个软件项目时最可能
的预期结果的方法。软件过程能力既可对整个
软件开发组织而言，也可对一个软件项目组而
言。
? 软件过程性能, 表示（开发组织或项目组）遵
循其软件过程所得到的实际结果。
软件过程成熟度 ——术语
? 一个特定软件过程被明确和有效地定义、管理、
测量和控制的程度 。
? 成熟度可指明一个软件开发组织软件过程能力
的增长潜力。随着软件组织的软件过程成熟度
的提高，开发组织通过其方针、标准和组织机
构等将其软件过程规范化和具体化。从而使得
开发组织明确定义的有关管理和工程的方法、
实践和规程等在现有人员离去后仍能继续下去。
软件过程能力成熟度等级 ——术语
? 软件开发组织在走向成熟的途中几个具有明确
定义的表征软件过程能力成熟度的平台 。
? 每一个成熟度等级为过程继续改进达到下一个
等级提供一个基础。每一等级包含一组过程目
标，当其中一个目标被达到时，就表明软件过
程的一个（或几个）重要成分得到了实现，导
致组织的软件过程能力增长。
软件能力成熟度模型 ——术语
? 对软件组织进化阶段的描述，随着软件组织定
义、实施、测量、控制和改进其软件过程，软
件组织的能力经过这些阶段逐步前进。
? 这个模型使软件组织能够较容易地确定其当前
过程的成熟度并识别出其软件过程执行中的薄
弱环节，确定对软件质量和过程改进最为关键
的几个问题，从而形成对其过程的改进策略；
软件组织只要关注并认真实施一组有限的关键
实践活动，就能稳步地改善其全组织的软件过
程。
CMM软件过程能力成熟度的 5个等级
1 软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没
有什么过程是经过定义的，成功依赖于个人的努力。
2 已建立基本的项目管理过程去跟踪成本、进度和功能性。
必要的过程纪律已经到位，使类似得应用项目，能重复以
前的成功。
3 管理活动和工程活动两方面的软件过程均已文档化、标准
化、并集成到组织的标准软件过程。全部项目均采用供开
发和维护软件用的组织标准软件过程的一个经批准的剪裁
版本。
4 已采集详细的有关软件过程和产品质量的度量数据。 无论
软件过程还是产品均得到了定量了解和控制。
5 利用来自过程和来自新思想、新技术的先导性试验的定量
反馈信息，使持续的过程改进成为可能。
CMM软件过程能力成熟度的
5个等级（图示）
2,可重复
1,初始
3,已定义
4,已管理
严格执行
的过程
标准、一致的
过程
可预估的过程
连续改进过程
不可预估和缺乏控
制
可以重复以前熟练
的任务
过程特征化，容易
理解
过程被度量和控制
集中于过程改进
5.优化
项目管理
集成工程过程
产品和过程质量
管理更改
结果 关键过程区域
级别 特征
优化 Continuous process Process change management
(5) capability improvement Technology change management
Defect prevention
已管理
(4)
已定义 Software process defined
(3) and institutionalized to
provide product quality
control
可重复
(2)
初始 l
(1)
Product quality planning; Software quality management
tracking of measured Quantitative process management
software process
Management oversight
and tracking of project;
stable planning and
product baselines
关键过程区域
定制 (成功依赖于英雄 ),人员 " 风险
生产率
& 质量
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking & oversight
Software project planning
Requirements management
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
SEI 能力成熟度模型
管理 机构 工程 5 优化级 技术更新管理
过程更新管理 缺陷预防
4 已管理级 定量软件管理 软件质量管理
3 已定义级 集成软件管理 组织过程焦点 软件产品工程
组间合作 组织过程定义 同行评审
培训大纲
2 可重复级 需求管理
软件项目策划
软件项目
追踪与监督
软件子合同管理
软件质量保证
软件配置管理
1 初始级 定制的过程
管理可视性 过程能力
Out In 1
2
3
4
5
概率
Time/$/..,
Target
N
N+a
N-x
N-y
N-z
级别
初始级 ——图示
Level 1,
Just do it,Activity Results to produce
初始级 ——行为特征（ 1）
在初始级上组织一般不提供开发和维护软
件的稳定环境 。 当组织中缺乏健全的管
理实践时, 不适当的规划和反应驱动体
系会降低由良好的软件工程实践所带来
的效益 。
初始级 ——行为特征（ 2）
在危机时刻, 项目一般抛弃预定的规程, 回复到
仅作编码和测试 。 成功完全依赖于有一个杰出
的经理及一支有经验的, 战斗力强的软件队伍 。
偶尔, 有能力的, 坚强的软件经理能经受住要
他们在软件过程中走捷径的压力, 但是当他们
离开项目后, 他们能使过程稳定的影响也随之
消失 。 甚至一个强的工作过程也不能克服由于
缺乏健全的管理实践所造成的不稳定 。
初始级 ——行为特征（ 3）
等级 1的组织的过程能力是不可预测的, 因
为随着工作进展软件过程经常被改变或
修定 （ 即过程是无秩序的 ） 。 进度, 预
算, 功能性和产品质量一般是不可预测
的 。 等级 1组织几乎没有明显的稳定的软
件过程, 只能通过个人的能力而不是组
织的能力去预测性能 。
可重复级 ——图示
Activity Results
to produce
Level 2,
Think before
you act,
and think after
you act,just to
make sure you
did it right,
Planning
Evaluation
input to
to improve
可重复级 ——行为特征（ 1）
在可重复级上, 已建立管理软件项目的方针和实
施这些方针的规程 。 基于在类似项目上的经验
对新项目进行规划和管理 。 达到 2 级的目的是
使软件项目的有效管理过程制度化, 这使得组
织能重复在以前项目上所开发的成功实践, 尽
管项目所实施的具体过程可能不同 。 一个有效
过程可特征化为实用的, 已文档化的, 已实施
的, 已培训的, 已测量的和已改进的 。
可重复级 ——行为特征（ 2）
等级 2组织中的项目已经设置基本的软件管理控
制 。 实际可行的项目约定是基于对以前项目的
观察结果和当前项目的需求 。 项目的软件经理
跟踪软件成本, 进度和功能性；在满足约定方
面的问题, 一旦出现就被识别 。 对软件需求和
为实现需求所开发的工作产品建立基线, 并控
制其完整性 。 软件项目标准均已确定, 并且组
织能保证准确地执行这些标准 。 如果有子承包
商的话, 软件项目与他们一起努力建立一种强
有力的顾客 ——供应商关系 。
可重复级 ——行为特征（ 3）
等级 2组织的过程能力可概括为有纪律的,
因为软件项目的规划和跟踪是稳定的,
能重复以前的成功 。 由于遵循基于以前
项目性能所制定的切实可行的计划, 项
目过程处在项目管理系统的有效控制之
下 。
已定义级 ——图示
Standards Activity Results
to produce
Level 3
Planning
Evaluation
input to
to improve
input to
input to
Use your lessons learned,
已定义级 ——行为特征（ 1）
在已定义级上, 全组织的开发和维护软件的标准
过程已文档化, 包括软件工程过程和软件管理
过程, 而且这些过程被集成为一有机的整体
（ 组织的标准软件过程 ） 。 等级 3上所建立
（ 适当时, 经更改 ） 的过程, 被用来帮助软件
经理和技术人员工作得更有效 。 组织在使其软
件过程标准化时, 利用有效的软件工程实践 。
存在一个负责组织的软件过程活动的组, 例如
软件工程过程组 。 实施全组织的培训计划以保
证职员和经理具有履行其职责所必须的知识和
技能 。
已定义级 ——行为特征（ 2）
项目通过剪裁组织的标准软件过程去建立他们自
己定义的软件过程, 它说明项目独有的特征
（ 项目定义软件过程 ） 。 一个已定义软件过程
包含一组协调的, 集成的, 妥善定义的软件工
程过程和管理过程 。 妥善定义的过程可特征化
为具有准备就绪判据, 输入, 标准, 进行工作
的规程, 验证机制 （ 例如同行评审 ）, 输出,
以及完成判据 。 因为软件过程已妥善定义, 管
理者就能洞察所有项目的技术进展 。
已定义级 ——行为特征（ 3）
等级 3组织的软件过程能力可概括为标准的
和一致的, 因为无论软件工程活动还是
管理活动, 过程都是稳定的和可重复的 。
在所建立的产品基线内, 成本, 进度和
功能性均受控制, 对软件质量也进行跟
踪 。 这种过程能力建立在整个组织范围
内对已定义过程中的活动, 角色和职责
的共同理解之上 。
已管理级 ——图示
Standards Activity Results
to produce
Level 4
Planning
Evaluation
input to
to improve
input to
input to to forecast
Predict the results you need and expect and then
create opportunities to get those results
已管理级 ——行为特征（ 1）
在已管理级上, 组织对软件产品和过程都
设置定量的质量目标 。 作为组织测量大
纲的一部分, 对所有的项目都测量其重
要的软件过程活动的生产率和质量 。 利
用一个全组织的软件过程数据库收集和
分析从项目定义软件过程中得到的数据 。
等级 4 上的软件过程均已配备有妥善定义
的和一致的度量 。 这些度量为定量地评
价项目的软件过程和产品打下基础 。
已管理级 ——行为特征（ 2）
项目通过将其过程性能的变化限制在定量
的可接受的范围之内, 实现对其产品和
过程的控制 。 可以将过程性能方面有意
义的变化与随机变化 （ 噪声 ） 区别开来,
特别在所建立的产品线内 。 开发新应用
领域的软件所带来的风险是已知的, 并
得到精心的管理 。
已管理级 ——行为特征（ 3）
等级 4组织的软件过程能力可概括为可预测
的, 因为过程是已测量的并在可测的范
围内运行 。 该等级的过程能力使得组织
能在定量限制的范围内预测过程和产品
质量方面的趋势 。 当超过限制范围时,
采取措施予以纠正 。 软件产品具有可预
测的高质量 。
Standards Activity Results
to produce
Level 5 Planning
Evaluation
input to
to improve
input to
input to to forecast
to improve
Create lessons learned,
and use lessons learned to create more lessons learned,
and use more lessons learned
to create even more lessons learned,
and use even more lessons learned to create..,
etc,
优化级 ——图示
优化级 ——行为特征（ 1）
在优化级, 整个组织集中精力进行不断的
过程改进 。 为了预防缺陷出现, 组织有
办法识别出弱点并预先针对性地加强过
程 。 在对新技术和所建议的组织软件过
程的更改进行费效分析时利用有关软件
过程有效性的数据 。 识别出采用最好软
件工程实践的技术创新并推广到整个组
织 。
优化级 ——行为特征（ 2）
等级 5组织的软件项目群组分析缺陷以确定
其发生的原因 。 为了防止已知类型的缺
陷再次出现, 他们认真评价软件过程,
同时将经验教训告知其它项目 。
优化级 ——行为特征（ 3）
等级 5组织的软件过程能力可特征化为不断
改进, 因为这些组织为扩大其过程能力
的范围进行着不懈的努力, 因而不断改
善其项目的过程性能 。 既通过在现有过
程中增量式前进的办法, 也通过采用新
技术, 新方法的革新办法, 使改进不断
出现 。
CMM结构 成熟度等级
关键过程区域
关键实践
共同特点
过程能力
目标
实施或规范化
基础设施或活动
按,..组织
到达
阐述
包含
描述
指示 包含
关键过程区域 ——术语
? 互相关联的若干软件实践活动和有关基
础设施的一个集合 。
? 每个软件能力成熟度等级包含若干个对
该成熟度等级至关重要的过程区域, 它
们的实施对达到该成熟度等级的目标起
保证作用, 这些过程区域就称为该成熟
度等级的关键过程区域 。
共同特点 ——术语
? 共同特点是表明一个关键过程区域的实
施和规范化是否有效、可重复且持久的
一些属性。
? 关键过程区域按照共同特点进行组织。
? 共有 5个共同特点：执行约定、执行能力、
执行的活动、测量和分析、验证实施。
关键实践 ——术语
? 对关键过程区域的实施起关键作用的方
针, 规程, 措施, 活动以及相关基础设
施的建立 。
? 关键实践一般只描述, 做什么,, 而不
强制规定, 如何做, 。 关键过程区域的
目标是通过其包含的关键实践的实施来
达到的 。
成熟度级别
关键过程
区域
目标
共同特点
关键实践
2 3 4
5
CMM结构
RM PP PT SM CM QA
执行能力 执行的活动 执行约定 测量和分析 验证实施
关键过程区域的过程分类
过程分类
等级
管理
（软件项目策划等）
组织 （高级管理者评
审等）
工程 （需求分析、设
计、编码、测试等）
技术改进管理5 优化级
过程改进管理 缺陷预防
4 定量管理级 定量过程管理 软件质量管理
3 已定义级 集成软件管理
组间协调
组织过程焦点
组织过程定义
培训大纲
软件产品工程
同行专家评审
2 可重复级 需求管理
软件项目策划
软件项目追踪和监督
软件子合同管理
软件质量保证
软件配置管理
1 初始级 无序过程
CMM的关键过程区域
需求管理（ L2）
? 需求管理的目的是在顾客和软件项目之
间建立对顾客需求的共同理解，顾客需
求将由软件项目处理。
? 与顾客的协议是策划和管理软件项目的
基础。
? 对与顾客关系的控制依靠遵循有效的更
改控制过程。
需求管理
软件需求
评审和纳入更改
描绘
编码
观察能否
工作
文档化
软件需求 使用软件需求指导计划、活动
和工作产品。
系统需求
软件项目策划（ L2）
? 软件项目策划的目的是制定进行软件工
程和管理软件项目的合理的计划。
? 这些计划是管理软件项目的必要基础。
? 没有切合实际的计划不可能实施有效的
项目管理。
软件项目策划
定义软件生存周期
文档记录软件
开发计划
确定软件工作产品
估计规模，成本
，工作量
制定活动进度
设计 编码
测试
(摆脱那些模糊的过程 )
软件项目追踪与监督（ L2）
? 软件项目追踪与监督的目的是建立适当
的对实际进展的可视性，使管理者在软
件项目性能显著偏离软件计划时能采取
有效的措施。
软件项目追踪与监督
追踪相对于估计的确
切规模，成本，工作
量
追踪相对于进度的确切进
展
使用软件开发计划（
SDP） 来追踪活动
设计 编码
测试
在必要时采取及时的修
正行动
软件子合同管理（ L2）
? 软件子合同管理的目的是选择合格的软
件子承包商，并有效地管理它们。
? 它把用于基本管理控制的需求管理、软
件项目策划、以及软件项目跟踪与监督
等关键过程区域所关注的事情与软件质
量保证和软件配置管理等过程区域中的
必不可少的协调结合在一起，并且当合
适时对子承包商实施这项管理。
软件子合同管理
设计
编码 测试
批准承包商的软件开发计划
（ SDP） 来追踪活动
指定人员管理合同
SOW
定义工作陈述（ SOW）；
选择有资格的承包商
评审承包商的完成
量和产品
软件质量保证（ L2）
? 软件质量保证的目的是给管理者提供对
于软件项目正采用的过程和正在构成的
产品的恰当的可视性。
? 软件质量保证是绝大多数软件工程过程
和管理过程的不可缺少的部分。
软件质量保证
审计工作 产品 的符合一致性
评审然后过程活动 (过程 )来验证符合一致
设计
编码
测试
确定偏离的活动和工
作产品
软件配置管理（ L2）
? 软件配置管理的目的是在项目的整个软
件生存周期中建立和维护软件产品的完
整性。
? 软件配置管理是绝大多数软件工程过程
和管理过程的不可缺少的部分。
软件配置管理
置工作产品于配置
管理之下
记录，评审，批准，和
追踪更改和问题
控制对基线的更
改
控制从基线的发布
基线库
设计 编码
测试
软件配置管理
等级 2(可重复的 )的一个关键过程
区域
（根据蔡愉祖译稿整理）
概述
软件配置管理的目的是建立和维护在项目的整个软件生存周期中软
件项目产品的完整性 。
软件配置管理包括标识在给定时间点上软件的配置 （ 即选定的软件
工作产品及其描述 ）,系统地控制对配置的更改, 并维护在整个软
件生存周期中配置的完整性和可跟踪性 。 置于软件配置管理之下
的工作产品包括交付给顾客的软件产品 （ 例如软件需求文档和代
码 ）, 以及与这些软件 等同的产品项或生成这些软件产品所要求
的产品项 （ 例如编译程序 ） 。
建立一个软件基线库, 当软件基线形成时就将它们纳入该库 。 通过
软件配置管理的更改控制和配置审计功能, 系统地控制基线的更
改和那些利用软件基线库构造成的软件产品的发行 。
这个关键过程区域仅包括实施软件配置管理功能的实践 。 而标识具
体的配置项或单元的实践则包含在描述每个配置项或单元的开发
和维护的关键过程区域中 。
目标
目标 1 软件配置管理活动是有计划的 。
目标 2 所选定的软件工作产品是已标识的,
受控的和适用的 。
目标 3 对已标识的软件工作产品的更改是
受控的 。
目标 4 受影响的组和个人得到软件基线的
状态和内容的通知 。
执行约定
（ 1项）
约定 1 项目遵循书面的用以实施
软件配置管理 (SCM)的组织方针。
该方针一般规定,
1,明确指派每个项目的 SCM职责。
2,在项目的整个生存周期内实
行 SCM。
3,对于对外可交付的软件产
品,指定的内部软件工作产
品和指定在项目内部使用的
支持工具（例如编译器）都
实行 SCM。
4,项目建立或可以利用一个仓
库，用来存储配置项 /单元和
相关联的 SCM记录。
在这些实践中这个仓库的内容称
为, 软件基线库, 。
存取该仓库的工具和规程在这些
实践中称为, 配置管理库系
统, 。
置于配置管理上并作为单个实体
予以处理的工作产品称为配
置项。配置项一般分解为配
置部件，而配置部件一般分
解为单元。在一个硬件 /软件
系统中,所有的软件可看成
一个单个配置项，或者可将
该软件分解为多个配置项。
在这些实践中术语, 配置项 /
单元, 用于指示在配置管理
下的元素。
5,定期审计软件基线和 SCM
活动。
执行能力
（ 5项）
能力 1 存在或者建立一个有权力管理项目软件基
线的委员会（即软件配置控制委员会 —SCCB）。
该 SCCB,
1,审定软件基线的建立和配置
项 /单元的标识。
2,代表项目经理和所有可能受
到软件基线更改影响的组的
利益。
受影响的组的例子有,
—硬件质量保证组,
—硬件技术状态（配置）管理组,
—硬件工程组,
—制造工程组,
—软件工程组（包括所有的小组，
例如软件设计小组）,
—系统工程组,
—系统测试组,
—软件质量保证组,
—软件配置管理组,
—合同管理组，和
—文档支持组。
3,评审和审定对软件基线的更
改。
4,审定由软件基线库制造的产
品的生成。
能力 2 存在负责协调和实施项
目的 SCM的组 (即 SCM组 )。
一个组是负责一组作业或活动的部
门, 经理, 和个人的集合 。 组的
规模可以变化：从一个受指派的
非全日制的单个个人, 到几个从
不同部门指派来的非全日制的个
人, 到几个全日制的个人 。 建立
一个组时应考虑的问题有：指派
的作业和活动, 项目的规模, 组
织机构和组织文化 。 某些 组, 例
如软件质量保证组, 集中注意力
于项目的活动, 而其它组, 例如
软件工程过程组, 集中关注全组
织的活动 。
SCM组协调或实现,
1,项目的软件基线库的生成和管理 。
2,SCM计划、标准和规程的制定、
维护和散发。
3,将置于 SCM之下的软件工作产
品集合的标识 。
一个工作产品是由定义, 维护,
或使用一个软件过程所生成
的任何人工制品 。
4,对存取软件基线库的管理 。
5,软件基线的更新 。
6,由软件基线库制造的产品的
生成 。
7,SCM行动的记录 。
8,SCM报告的生成和散发 。
能力 3 为进行 SCM活动提供足
够的资源和投资。
1,安排一个经理专门负责 SCM。
2,使得支持 SCM活动的工具合用 。
支持工具的例子有,
—工作站,
—数据库程序, 和
—配置管理工具。
能力 4 SCM组的成员在有关进行其 SCM
活动的对象、规程和方法方面受到培训。
培训的例子包括,
—SCM标准, 规程和方法；和
—SCM工具。
能力 5 软件工程组和其它软件一有关
组的成员受到培训以便完成其 SCM活动。
其它软件一有关组的例子有,
—软件质量保证组, 和
—文档支持组 。
培训的例子有,
—在软件工程组和其它软件一有关组的内部
进行 SCM活动要遵循的标准, 规程和方法,
和
—SCM组的角色、职责和权力。
执行的活动
（ 10项）
活动 1 按照已文档化的规程对每
个软件项目准备一份 SCM计划。
这个规程一般规定,
1,SCM计划的制定是在
整个项目策划的早期
阶段, 并平行于整个
项目策划 。
2,受影响的组评审 SCM
计划 。
3,对 SCM计划进行管
理和控制 。
,进行管理和控制, 意味
着在给定时间 （ 过去或
现在 ） 使用的工作产品
的版本是已知的 （ 即版
本控制 ）, 而且以受控
的方式引进更改 （ 即更
改控制 ） 。
如果希望有比, 进行管理
和控制, 所蕴含的更高
程度的控制, 则工作产
品可置于配置管理的完
备的纪律之下, 正如在
本关键过程区域中所描
述的 。
活动 2 用已文档化的经批准的 SCM
计划作为进行 SCM活动的基础。
该计划包括,
1,将进行的 SCM活动, 活动的日程表, 指
派的职责和所要求的资源 （ 包括职员,
工具和计算机设施 ） 。
2,SCM需求和将由软件工程组及其它软件
一有关组进行的 SCM活动 。
活动 3 建立一个配置管理库系
统作为软件基线的仓库。
该库系统,
1,支持 SCM的多个控制层次 。
导致多个控制层次的情况例如,
—在生存周期的不同时间所需要的控
制层次不同 （ 例如, 随着产品成
熟要更加严密地控制 ）,
—纯软件系统和既包括硬件又包括软
件的系统所需要的控制层次不同 。
2,提供对配置项 /单元的存储和检
索功能 。
3,在受影响的组之间和在库内部的
控制层次之间提供配置项 /单元
的共享和传送 。
4,帮助使用配置项 /单元的产品标
准。
5,对配置项 /单元的归档版本提供
存储和恢复功能 。
6,帮助保证由软件基线库制造的产
品的正确生成 。
7,对 SCM记录提供存储, 更新的检
索功能 。
8,支持 SCM报告的编制 。
9,提供对库结构和内容的维护 。
库维护功能的例子有,
—库文件的备份 /重建, 和
—从库的错误中恢复 。
活动 4 标识将置于配置管理之
下的软件工作产品。
1,基于已文档化的准则选择配
置项 /单元 。
可标识为配置项 /单元的软件工
作产品的例子有,
—过程一有关文档 （ 例如：计划,
标准或规程 ）,
—软件需求,
—软件设计,
—软件代码单元,
—软件测试规程,
—为软件测试活动所构造的软件
系统,
—为交付给顾客或最终用户所构
造的软件系统,
—编译程序，和
—其它支持工具。
2,安排给每个配置项 /单元唯一
的标志符。
3,详细说明每个配置项 /单元的
特征 。
4,详细说明每个配置项 /单元所
属于的软件基线 。
5,详细说明在开发中将每个配
置项 /单元置于配置管理之下
的时间点 。
6,标识每个配置项 /单元的负责
人 (即从配置管理的角度来说
的所有者 )。
活动 5 按照已文档化的规程，
起动、记录、评审、批准和
跟踪对所有配置项或单元的
更改请求和问题报告。
活动 6 按照已文档化的规程控
制对基线的更改。
该规程一般规定,
1,进行评审和 (或 )回归测
试以保证更改不会造成
对基线的未料到的影响 。
2,仅仅那些经 SCCB批准的
配置项 /单元才能进入软
件基线库 。
3,以能保持软件基线库的
正确性和完整性的方式
进行配置项或单元的登
入和退出 。
登入或退出步骤的例子
有,
—验证修改是经审定的,
—建立更改日志,
—保持一份更改拷贝,
—更新软件基线库, 和
—建立被取代的软件基
线的档案 。
活动 7 按照已文档化的规程生成由软
件基线库制造的产品并控制它们的发行。
该规程一般规定,
1,SCCB审定由软件基线库制造的产品的
生成。
2,不论为内部使用或外部使用，由软件
基线库制造的产品仅仅由软件基线库中
的配置项或单元组成。
活动 8 按照已文档化的规程记
录配置项或单元的状态 。
该规程一般规定,
1,足够详细地记录配置管理行动, 使每个
配置项 /单元的内容和状态, 都是清楚的
并且能恢复以前的版本 。
2,对每个配置项 /单元维护其当前状态并
保留其历史 (即更改和其它行动 )。
活动 9 编制用文档记载 SCM活动和软件基线内容
的标准报告，并使受影响的组和个人可以使用它。
报告的例子包括,
—SCCB会议记录,
—更改申请的摘要和状态,
—问题报告的摘要和状态 （ 包括解决情况 ）,
—软件基线更改的摘要,
—配置项 /单元的修改历史,
—软件基线状态, 和
—软件基线审计结果。
活动 10 按照已文档化的规程
进行软件基线审计 。
该规程一般规定,
1,为审计作好充分准备 。
2,评估软件基线的完整性 。
3,评审配置管理库系统的结构和设施 。
4,验证软件基线库内容的完备性和正确性 。
5,验证与适用的 SCM标准和规程的符合性 。
6,向项目软件经理报告审计结果 。
7,跟踪得自审计的措施条款直至结束。
测量和分析
（ 1项）
测量 1 进行测量并将测量结果
用于确定 SCM活动的状态。
测量的例子有,
—每单位时间处理的更改申请数；
—SCM活动的里程碑的完成情况与计划相比
较；和
—在 SCM活动中所完成的工作、花费的工作
量和消耗的资金。
验证实施
(4项）
验证 1 高级管理者定期参与评
审 SCM活动 。
高级管理者定期评审的主要目的是在合适
的抽象层次上并以及时的方式了解和洞
察软件过程活动 。 评审间隔应该满足组
织的需要, 只要已存在报告例外情况的
合崐机制, 间隔可以长 。
参考软件项目跟踪和监督关键过程区域的
验证 1以便找到包括高级管理者监督评审
的典型内容的实践 。
验证 2 项目经理既定期地也事
件驱动地参加评审 SCM活动。
参考软件项目跟踪和监督关键过程区域的
验证 2以便找到包括项目管理者监督评审
的典型内容的实践。
验证 3 SCM组定期审计软件基
线以验证它们符合定义它们
的文档。
验证 4 软件质量保证组评审和审计有关
SCM的活动和工作产品，并报告其结果。
参考软件质量保证关键过程区域 。
至少, 评审和审计要验证,
1,以下各组对 SCM标准和规程的依照情况,
□ SCM组,
□ SCCB,
□ 软件工程组, 和
□ 其它软件一有关组 。
2,定期进行软件基线审计的情况 。
组织过程焦点（ L3）
? 组织过程焦点的目的是规定组织在改进
其整体软件过程能力的软件过程活动方
面的职责。
? 组织过程焦点活动的主要结果是一组软
件过程财富，它们在组织过程定义中加
以描述。
? 正如集成软件管理中所描述的，这些财
富供软件项目使用。
组织过程定义（ L3）
? 组织过程定义的目的是开发和保持一组
便于使用的软件过程财富，它们能改进
横跨项目的过程性能，并且为组织能获
得积累性的、长期的得益奠定基础。
? 这些财富提供一组稳定的基本原则，通
过诸如培训等机制就能使其成为制度。
? 培训在培训大纲中加以描述。
培训大纲（ L3）
? 培训大纲的目的是培育个人的技能和知
识，使他们能有效地和效率高地执行其
任务。
? 尽管培训是组织的责任，但是软件项目
应该识别出他们所需要的技能，当项目
需求独特时，该项目应提供所需要的培
训。
集成软件管理（ L3）
? 集成软件管理的目的是将软件工程活动和管理
活动集成为一个协调的、已定义的软件过程，
该过程是剪裁组织的标准软件过程和组织过程
定义中所描述的相关的过程财富而得到的。
? 剪裁基于项目的经营环境和技术需要，正如在
软件产品工程中所描述的那样。
? 集成软件管理是从等级 2 的软件项目策划与软
件项目跟踪与监督进化而得到的。
软件产品工程（ L3）
? 软件产品工程的目的是一致地执行一个
妥善定义的工程过程。
? 为了能有效地和效率高地生产正确的、
一致的软件产品，该工程过程集成全部
软件工程活动。
? 软件产品工程描述项目的技术活动，例
如，需求分析、设计、编码和测试。
组间协调（ L3）
? 组间协调的目的是为软件工程组积极参与其它
工程组工作制定一种方法，使得项目能更有效
地和效率高地满足顾客的需求。
? 组间协调是集成软件管理的一个涉及多科目的
方面，它延伸到软件工程之外。不仅应该集成
软件过程，而且软件工程组和其它组之间的相
互作用也必须加以协调和控制。
同行评审（ L3）
? 同行评审的目的是及早和高效地除去软
件工作产品中的缺陷。
? 一个重要的必然结果是增强对软件工作
产品和可预防的缺陷的了解。
? 同行评审是一种重要而又有效的工程方
法，在软件产品工程中采用此方法，可
通过法根（ Fagan） 式审查,结构化走查、
或者其它评审方法加以实施。
定量过程管理（ L4）
? 定量过程管理的目的是定量地控制软件过程的
过程性能。
? 软件过程性能表示遵循一个软件过程所得到的
实际结果。
? 焦点是在一个可测的稳定的过程范围内鉴别出
变化的特殊原因，并且适当时改正那些促使瞬
时变化出现的环境。
? 定量过程管理给组织过程定义、集成软件管理、
组间协调、和同行评审的实践附加了一个内容
丰富的测量计划。
软件质量管理（ L4）
? 软件质量管理的目的是建立对项目的软
件产品质量的定量了解和实现特定的质
量目标。
? 软件质量管理对软件产品工程中所描述
的软件工作产品，实施内容丰富的测量
计划。
缺陷预防（ L5）
? 缺陷预防的目的是鉴别缺陷的原因并防
止它们再次出现。
? 正如在集成软件管理中所描述的，软件
项目分析缺陷、鉴别其原因并更改项目
定义软件过程。
? 正如在过程更改管理中所描述的，应将
具有普遍价值的过程更改通知给其它软
件项目。
技术改进管理（ L5）
? 技术改进管理的目的是识别出能获利的
新技术（即工具、方法和过程），并以
有序的方式将它引进到组织中去，正如
在过程改进管理中所描述的那样。
? 技术改进管理的关注焦点是在不断变化
的环境里高效率地创新。
过程改进管理（ L5）
? 过程改进管理的目的是出于改进软件质
量、提高生产率和缩短产品开发周期的
目的，持续不断地改进组织中所采用的
软件过程。
? 过程改进管理既采用缺陷预防的增量式
改进，又采用技术改进管理的创新式改
进，并使得整个组织可以享用这些改进。
CMM评估
CMM评估方法
软件过程评估（ CBA-IPI）, 目的是确定一个组
织的当前软件过程的状态，找出组织所面临的
急需解决的软件过程有关问题，进而有步骤地
实施软件过程改进，使组织的软件过程能力不
断提高。
软件能力评价（ SCE）, 目的是识别合格的能完
成软件工作的承制方，或者监控承制方现有软
件工作中软件过程的状态，进而提出承制方应
改进之处。
CBA-IPI
软件过程评估 是在开放、合作的环境中进行的，
评估目的在于暴露问题和帮助经理和工程师们
改进他们的软件过程，一般都能得到较好的支
持。评估过程中虽然提问单是个重要工具，但
更重要的是通过各种会谈了解组织的软件过程。
评估的结果除了识别组织所面临的软件过程问
题外，最有价值的还是：明确软件过程的改进
途径，促进制订进一步的行动计划，使全组织
关注改进过程，增强执行改进行动计划的动力
和热情。
SCE
? 软件能力评价 是在更象审计的环境中进
行。评价的目的与金钱密切相关，评价
组的推荐性意见将影响挑选承制方或设
置资金。评价过程的重点放在复审已文
档化的审计记录上，这些记录能揭示组
织实际执行的软件过程。
评估方法特点
? 采用成熟度提问单作为现场访问的出发点；采
用 CMM作为指导现场调查研究的导引图；
? 利用 CMM中的关键过程域生成明确地指出软件
过程强项和弱项的调查发现清单；
? 在对关键过程域目标满足情况进行分析的基础
上，衍生出一个剖面；
? 根据调查发现清单和关键过程域剖面，向合适
的对象提出结论意见。
CMMI的提出
广泛使用的各种 CMM模型
?软件 CMM 阶段式 软件开发
?系统工程 CMM 连续式 系统工程
?系统工程能力模型 连续式 系统工程
?软件获取 CMM 阶段式 软件获取
?系统安全性工程 CMM 连续式 安全性工程
?个体软件过程 阶段式 个体软件开发
?FAA-iCMM 连续式 软件工程, 系统工程和获取
?IPD-CMM 混合式 集成产品开发
?人员 CMM 阶段式 劳动力
?SPICE模型 连续式 软件开发
问题
? 系统学科与软件学科在传统
上没有很好地集成在一起
? 软件在系统中的重要性引人
注目地增长
? 例如：分配给软件的需求
百分比 *
? B-2 -- 65%
? F-22 -- 80%
? 美国国防部强调，要使系统 /
软件的接口更好地做到无缝
联接
Systems Software
* Source,Standish Group Chaos Report
模型太多，时间太少
软件
CMM
系统安全性
工程
CMM
系统工程
Engr
CMM 人员
CMM
ZZZ
CMM
FAA
iCMM
IPD
CMM 软件获取 CMM
EIA 731 ? 不同的结构, 格式, 术
语, 度量方法
? 尤其是使用一个以上的
模型时, 容易混淆
? 在一个联合改进程序中
难于集成这些模型
? 在供应商的选择中难于
使用多个模型
CMMI 来解决问题 !
? 在一个过程改进框架内集成系统和
软件学科
? 提供一个在需要时可以引入新学科
的框架
CMMI为分离构筑了“桥梁”
? 将系统工程和软件
工程集成在一起
? 将系统学科和软件
学科集成为一个过
程改进框架
? 当出现需求时, 为
引进新学科提供框
架
但是 CMMI不做,.,
? 一些组织将他们视为仅有一个学科
? 软件
? 系统
? 获取
? 但是 …
? 软件始终必然是某种系统的组成部分
? 没有系统的软件是罕见的
? 获取的可能两者都包括
? 与其它学科的沟通与合作，即使它们在我们组
织的外部，也是至关重要的
CMMI项目
? 由 DoD赞助的工业界、政府和 SEI之间的协作体
? 有 100多人参与
? 美国陆军、海军、空军
? 联邦航空局
? 国家安全部
? 软件工程研究所
? ADP,Inc,
? AT&T 实验室
? BAE
? 波音公司
? 计算机科学有限公司
? EER 系统
? 加拿大爱立信公司
? Ernst和 Young
? 通用动力公司
? Harris 有限公司
? Honeywell公司
? KPMG公司
? Lockheed Martin公司
? 摩托罗拉公司
? Northrop Grumman
? Pacific Bell
? Q-Labs
? Raytheon公司
? 路透社
? Rockwell Collins公司
? SAIC公司
? 软件生产率联盟
? Sverdrup 有限公司,
? TeraQuest公司
? Thomson CSF公司
? TRW公司
CMMI 模型
源 Models
?将系统工程和软件工程相结合
?可以应用于,
?一个组织中的软件工程项目
?一个组织中的系统工程项目
?应用于上述两者
?IPPD 可以用于其中一种情况
或者包括其两者
? 软件能力成熟度模型 V2,
草案 C (SW-CMM V2C)
? EIA过渡标准 731,系统工
程能力模型 (SECM)
? 集成产品开发能力成熟度
模型,草案 V0.98 (IPD-
CMM)
CMMI成套产品
? 模型
? 学科
? 系统工程 SE
? 软件工程 SW
? 集成产品和过程开
发 (IPPD)
? 供应商来源 (SS)
? 表示法
? 阶段式
? 连续式
? 培训
? 模型
? CMMI介绍
? 中间概念
? 教师培训
? 主任评估师
? 评估方法
? CMMI 评估需求 (ARC)
? SCAMPI 方法描述文
档 (MDD)
CMMI 简要说明
? CMMI模型提供了组织过程改进的一
个结构化视角
? CMMI能够帮助
? 设定过程改进目标和优先级
? 提供优质过程的指南
? 提供评价当前实践的准绳
铭记
? 模型 不是 过程
? 模型说明做什么, 不是 说明如何去做或
者谁去做
CMMI结构
CMMI成套产品
? 模型
? 学科
? 系统工程 SE
? 软件工程 SW
? 集成产品和过程开发
(IPPD)
? 供应商来源 (SS)
? 表示法
? 阶段式
? 连续式
? 培训
? 模型
? CMMI介绍
? 中间概念
? 教师培训
? 主任评估师
? 评估方法
? CMMI 评估需求 (ARC)
? SCAMPI 方法描述文
档 (MDD)
CMMI 模型集
? CMMI-SW,V1.1,阶段式
? CMMI-SW,V1.1,连续式
? CMMI-SE/SW,V1.1,阶段式
? CMMI-SE/SW,V1.1,连续式
? CMMI-SE/SW/IPPD,V1.1,阶段式
? CMMI-SE/SW/IPPD,V1.1,连续式
? CMMI-SE/SW/IPPD/SS,V1.1,阶段
式
? CMMI-SE/SW/IPPD/SS,V1.1,连续
式
? SE 系统工程
? Systems Engineering
? SW 软件工程
? Software Engineering
? IPPD 集成产品和过程开发
? Integrated Product and
Process Development
? SS 供应商来源
? Supplier Sourcing
ML 1
ML2
ML3
ML4
ML5
.,,作为整个组织已建立
的一个过程域集合
连续 式
.,,作为单一过程域
或者过程域集合
过程域能力
PA PA PA
模型表示法的比较 阶段 式
过程域能力与组织成熟度
?过程域能力和组织成熟度是相似的概念
?它们之间的区别是
?过程域能力 将一组过程与 单个过程域 或特定实
践相联系
?组织成熟度 适用于跨越组织的一组过程域
?通常，如果组织过程集被评估达到一定的
成熟度等级，评估的过程可以证明达到相
应的过程能力级别
为什么有两种表示法？
? 源模型遗产
? 软件 CMM— 阶段式
? 系统工程 CMM— 连续式
? IPD CMM— 混合式
? 每种表示法的支持者都是 CMM产品开发组的
一部分
? 选择单一表示法变得, 太难,
? 首先支持等量内容的模型的两种表示法是采用
了折衷方法
阶段式表示法的优点
? 提供一个预定义的组织级改进的路线图,
基于一组过程, 其组成和顺序及相关的
组织关系已证明
? 过程域组成
? 实现的先后顺序
? 从 SW-CMM转移过来的常见结构
连续式表示法的优点
? 根据商业目标及目的, 选择所关注的特
定过程域, 为过程改进提供最大的灵活
性
? 从系统工程社团转移过来的常见结构
CMMI结构,一个模型,两种表示法
成熟度等级 5
OID,CAR
成熟度等级 4
OPP,QPM
成熟度等级 3
REQD,TS,PI,VER,
VAL,OPF,OPD,OT,
IPM,RSKM,DAR
综述
引言
模型结构
模型术语
成熟度等级、公共特性、共性实践
理解模型
应用模型
成熟度等级 2
REQM,PP,PMC,
SAM,MA,PPQA,CM
附录
CMMI-SE/SW
阶段的
工程
REQM,REQD,TS,
PI,VER,VAL
项目管理
PP,PMC,SAM
IPM,RSKM,QPM
过程管理
OPF,OPD,OT,
OPP,OID
Process Management
PAs
- Goals
- Practices
支持
CM,PPQA,MA,
CAR,DAR
附录
综述
引言
模型结构
模型术语
能力等级、共性模型构件
理解模型
应用模型
CMMI-SE/SW
连续的
CMMI结构
CMMI 连续式描述的结构
CMMI连续式描述结构
Generic Goals
Process Area 2 Process Area 1 Process Area n
Specific Goals
能力等级 共性实践
共性目标
过程域 2 过程域 1 过程域 n
特定目标
特定实践
过程域能力剖面
过程域能力剖面可以表示为两维平面上的一组点
? 过程维
? 你都做了, 什么,
? 能力维
? 你做的有, 多好,
能力
(多好
)
过程域 (你做了什么 )
过程维
? 这条轴上的值代表你执行的过程
（用 过程域 描述）
过程
过程域 1 过程域 n 过程域 2 过程域 3
能力
过程域
? 过程域 (PAs)是一族相关实践
? 它们是建立过程能力的主要建筑石
块
? 过程域示例：, 需求管理,
连续的过程域组织
需求管理
需求开发
技术解决方案
项目集成
验证
确认
工程 （ 6）
项目管理 （ 8） 项目计划
项目监督和控制
供应商协议管理
集成项目管理 (IPPD)
集成供应商管理 (Supplier Sourcing,SS)
集成组队 (IPPD)
风险管理
定量项目管理
组织级过程焦点
组织级过程定义
组织级培训
组织级过程性能
组织级创新和施展应用
过程管理 （ 5）
配置管理
过程和产品质量保证
度量和分析
因果分析和解决方案
决策分析和解决方案
集成的组织环境 (IPPD)
支持 （ 6）
分 类 过程域
能力维 -1
? 这条轴上的值代表你执行的一个过程
有多好（称作 能力等级 ）
过程没有执行
能力
过程
过程域 1 过程域 n 过程域 2 过程域 3
能力维 -2
? 这条轴上的值代表你执行的一个过程
有多好（称作 能力等级 ）
过程没有执行
能力
过程
过程域 1 过程域 n 过程域 2 过程域 3
过程执行得很好
并且被持续改进
能力等级
? 能力等级是描述过程域能力的明确定义
进化平台的
? 有 6个能力等级
? 每个等级都是连续过程改进的基础层次
? 因此，能力等级是积累的，即，高的能
力等级包括低等级的属性
能力等级
5 Optimizing 优化
4 Quantitatively Managed 已定量管理的
3 Defined 已定义的
2 Managed 已管理的
1 Performed 已执行的
0 Incomplete 不完善的
能力等级是积累的
? 由于能力等级建立在低等级的基础
上，因此它们之间不能够有缝隙
表示过程能力
? 已实现的过程的能力可以用一根棒
来表示
过程
能力
该点表示
在特定过
程域比下
点更高的
能力等级
3
2
1
0
过程域 n
过程域能力剖图举例
过程域
REQM PP PMC etc
5
4
3
2
1
0
能力
清晰在 CMMI连续模型中的概念
? 目标 和 实践 是用来清晰能力和过程
维的取值的模型元素
? 目标
? 通过有效地实现一组实践而达到的
结果的高层次描述
? 实践
? 对对实施一个过程域的关键元素所
必须的行动的描述
有两种类型的目标和实践
? 特定目标 和 特定实践
? 实现过程维数
? 所以, 应用于特别的过程域
? 共同目标和共性实践
? 实现能力维数
? 所以, 应用于全部所有过程域 。
示例：特定目标和特定实践
? 特定目标（需求管理过程域）
? 管理被需求，并且与项目计划和工作
产品之间的不一致被识别。
? 特定实践（需求管理过程域）
? 在需求和项目计划及工作产品之间维
护双向的可追踪性。
示例：共性目标和共性实践
? 共性目标（能力等级 1）
? 过程通过将可以确认的输入工作产品转换为
可以确认的输出工作产品，支持和使得本过
程域的特定目标达到
? 共性实践（能力等级 1）
? 执行过程域的基础活动去开发工作产品和
提供服务，以达到本过程域的特定目标
CMMI连续表示的结构
共性目标
&
共性实践
共性目标
&
共性实践
特定目标
&
实践
特定目标
&
实践
关键区别
已执行 对比 已管理
过程被策划、绩效被参照计划管理、需要时纠正行动被
采取的程度
已管理 对比 已定义
应用过程描述、标准和过程的范围（即项目与组织）
已定义 对比 已定量管理
过程绩效的可预告
已定量管理 对比 优化
通过处理过程偏差的共同原因，过程被连续地改进
改进过程域
CL0 没有执行，不完善 没有 GPs或 SPs存在
GP1.1
CL1 (基础 ) SPs
GP1.1 到 GP2.10
CL1 + CL2* SPs
GP1.1 到 GP3.2
CL1+CL2*+CL3* SPs
GP1.1 到 GP4.2
CL1+CL2*+CL3* SPs
GP1.1 到 GP5.2
CL1+CL2*+CL3* SPs
CL1
已执行 执行工作
CL2
已管理
坚持方针，遵照文档记录的计划和过程，应用适当的资源,
分配责任和权力，培训人员，应用配置管理，监督，控制,
评价过程，识别和包含利益相关者，带有评审的管理
CL3
已定义
项目的过程裁剪于组织标准过程,
定性了解过程,
过程对组织资产作贡献
CL4
已定量管理
度量过程绩效
稳定过程，控制图,
处理特定偏差的原因
CL5
优化
缺陷预防，主动抢先改进,
创新技术引入和运用
* 高级实践只在工程过程域中存在
共性目标和实践 GG1（ CL1）
GG1,达到特定目标
GP1.1,执行基础实践
共性目标和实践 GG2（ CL2）
GG2,制度化已管理过程
所有 CL1 共性实践（ +）
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
共性目标和实践 GG3（ CL3）
GG3：制度化已定义过程
所有 CL1 & CL2 共性实践（ +）
GP3.1,建立已定义的过程
GP3.2,采集改进信息
共性目标和实践 GG4（ CL4）
GG4,制度化已定量管理过程
所有 CL1 & CL2 & CL3 共性实践（ +）
GP4.1,对过程建立定量目标
GP4.2,稳定子过程绩效
共性目标和实践 GG5（ CL5）
GG5,制度化优化过程
所有 CL1 & CL2 & CL3 & CL4 共性实践（ +）
GP5.1,确保连续过程改进
GP5.2,纠正问题的根本原因
需求管理：能力等级 1 & 2
需求管理
特定实践（ CL1 –,基础”）
SP1.1-1,获得需求理解
SP1.3-1,管理需求变更
SP1.5-1,识别项目工作与需求的不一致性
共性实践（ CL1）
GP1.1,执行基础实践
特定实践（ CL2 -,高级” ）
SP1.2-2,获得需求承诺
SP1.4-2,维护需求的双向可追踪性
共性实践（ CL2）
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
需求管理：能力等级 3
需求管理
特定实践（ CL1 & CL2）
SP1.1-1,获得需求理解
SP1.2-2,获得需求承诺
SP1.3-1,管理需求变更
SP1.4-2,维护需求的双向可追踪性
SP1.5-1,识别项目工作与需求的不一致性
共性实践（ CL1 & CL2）
GP1.1,执行基础实践
GP2.1,建立组织方针
GP2.2,策划过程
GP2.3,提供资源
GP2.4,分配责任
GP2.5,培训人员
GP2.6,管理配置
GP2.7,识别和包含利益相关者
GP2.8,监督与控制过程
GP2.9,客观评价遵从性
GP2.10,与高层管理人员评审状态
特定实践（ CL3）
全部 CL1 & CL2 特定实践
共性实践（ CL3）
所有 CL1 & CL2 共性实践，再加上（ +）,
GP3.1,建立已定义的过程
GP3.2,采集改进信息
需求管理：能力等级 4 & 5
需求管理
特定实践 （ CL4）
所有 CL1 & CL2 特定实践
共性实践（ CL4）
所有 CL1 & CL2 & CL3 共性实践，再加上（ +）,
GP4.1,对过程建立定量目标
GP4.2,稳定子过程绩效
特定实践 （ CL5）
所有 CL1 & CL2 特定实践
共性实践（ CL5）
所有 CL1 & CL2 & CL3 & CL4 共性实践，再加上（ +）,
GP5.1,确保连续过程改进
GP5.2,纠正问题的根本原因
小结
? CMMI 模型的产生得到了广泛的参与和评
审
? 过程域确定, 你做什么,
? 能力等级确定, 你做得有多好,
CMMI结构
CMMI 阶段式描述的结构
CMMI阶段表示法的结构
成熟度等级
过程域 过程域 过程域
共性目标 特定目标
执行承诺 执行能力 定向实现 验证实现
公共特性
执行承诺,建立方针，并担保资助者承诺的过程改进工作
执行能力,确保项目和 /或组织为继续过程改进拥有所需资源
定向实现, 收集、度量、分析与过程相关的数据
验证实现,验证项目和 /或组织的活动与需求、过程和规程相符合
共性实践 特定实践
成熟度等级
? 成熟度等级对成为成熟的组织的途
径的明确定义的进化平台
? 有五个成熟度等级
? 每个等级是连续过程改进的基础层
次
成熟度等级
过程不可预测，缺乏
控制，反应式的
项目描绘过程, 而且经
常是反应式的
组织刻画过程，并且是
预测式的
过程经过了度量和控制
关注点在过程改进
定量管理的
已定义的
执行的
已管理的
优化的
1
2
3
4
5
CMM 成熟度等级
初始级 (1)
已定义级 (3)
可重复级 (2)
优化级 (5)
已管理级 (4)
规范的过程
标准一致的过程
可预测的过程
持续改进的过程
组织级的成熟度
? 组织级的成熟度是靠一组过程的能力结
合起来表现的
? 在这组过程中, 选出了一套适合组织过
程改进需要的过程
成熟度 1级：初始级
? 过程在执行, 但常常是即兴管理的
? 性能取决于精英的努力
? 高质量和期望的性能是可能的, 只要指
派最好的人来执行任务
? 性能很难预测
? 管理层实践可能是无效的
性能不可预测
? 需求流入
? 产品有时通过一些无形的过程生产出来
? 产品流出及运行 （ 希望可工作 ）
输出 输入
成熟度 2级：已管理级
? 项目管理更规范化了
? 组织方针建立且遵循了
? 项目计划和过程描述文档化了且遵循了
? 提供了适当的资源
? 全生命周期指派责任和授权重点需要建立有效的软件
项目管理
? 小项目可预测成功基于过去的经验
? 规范有助于确保现有的实践在时间压力下保留下来
? 对管理人员来说, 活动和工作产品的状态在预定义的
点上是可见的
过程被管理
? 需求流入
? 按照方针开发项目计划
? 活动按照计划执行
? 在定义的点度量和评审
? 产品流出及运行 （ 通常 ）
CMMI的已管理级
?需求管理：管理项目的产品和产品构件的需求, 并标识那些
需求与项目的计划和工作产品的不一致
?项目计划：建立和维护定义项目活动的计划
?项目监督和控制：提供对项目进展的了解, 以便在项目性能
与计划有重大偏离时采取适当的纠正行动
?供应商合同管理：通过正式的协议, 管理从供应商获取的产
品
?度量和分析：开发和维持用于支持管理信息所需要的度量能
力
?过程和产品的质量保证：将对过程及其相关工作产品的客观
评价提供给项目成员和管理部门
?配置管理：使用配置标识, 配置控制, 配置状态报告和配置
审计, 建立和维护工作产品的完整性
成熟度 3级：已定义级
? 建立在已管理级 L2——项目管理基础之上
? 工程过程更有效的实施
? 组织有预测式活动
? 已计划了培训
? 组织有了标准的过程, 项目可根据自己的需要裁减过
程
按照已定义过程管理
? 在过程中, 角色和职责分明 。
? 软件产品的生产在整个软件过程是可见
的 。
CMMI的已定义级 -1
? 需求开发：产生和分析客户, 产品和产品构件的需求
? 技术解决方案：设计, 开发和实现对需求的解决方案 。
解决方案, 设计和实现包括产品, 产品构件以及与单
一的或适当组合的生命周期过程相关的产品
? 产品集成：把产品构件组装成产品, 确保该集成产品
的功能正确并并付该产品
? 验证：确保所选择的工作产品满足规定的需求, 即满
足该产品的需求规格说明
? 确认：证实产品和产品构件置于预期的环境时, 满足
预期的用途, 即满足其可操作性要求
CMMI的已定义级 -2
?组织级过程焦点：基于对组织的过程和过程资产的当前
的强项和弱项的透彻理解, 计划和实现组织级过程改进
?组织级过程定义：建立和维护一个有用的组织级过程资
产集
?组织级培训：开发人员的技能和知识, 使他们能有效地
和高效地执行其任务
?集成化项目管理：根据从组织级标准过程集裁剪而来的
一个集成的和已定义的过程, 建立和管理该项目以及该
项目相关人员的参与
?集成供应商管理：主动地识别可以满足项目需求的产品
来源, 主动地管理所选择的供应商的产品以及维护项目
与供应商的合作关系的过程
CMMI的已定义级 -3
? 风险管理：在问题出现之前标识潜在的问题, 以便在
需要时可以计划产品或项目的全生命周期的风险处理
活动, 以缓解对达到目标的负面影响
? 决策分析和解决方案：使用一个正式的评价过程, 按
照已经制定的准则, 评价已标识的各种不同方案, 分
析各种可能的决策
? 组织级集成环境：提供一个产品和过程集成化开发
（ IPPD） 的基础设施 （ 包括方法和环境 ）, 并管理与
集成相关的人员
? 集成组队：为工作产品的开发组成和保持一个集成化
群组
成熟度 4级：定量管理级
? 在组织和项目级使用统计的及其他定量的方法
? 了解过去过程的性能
? 预测将来过程性能
? 预测将来项目质量和服务质量
? 项目使用要度量的目标来满足客户, 最终用户
和组织的需要
? 管理者和工程师在管理过程和结果中使用统计
的和其他量化技术的数据
定量的管理产品和过程
? 过程的行为是可预测的和量化的理解的
? 为达到建立的产品质量, 服务质量和过
程性能目标, 存在一个作出结论的量化
依据
CMMI的定量管理级
? 组织级过程性能：建立和维护对组织的
标准过程集的性能的定量理解, 以支持
质量和过程性能目的；并提供过程性能
数据, 基线和模型, 以定量地管理组织
的项目
? 项目定量管理：定量地管理项目的已定
义过程, 已达到项目所建立的质量和过
程性能目标
理解定量管理级
? 应用统计过程控制理论
? 处理过程变化的特殊原因
? 标识在过程中的问题
? 特殊原因控制图
成熟度 5级：优化级
? 经过分析解决过程偏离的公共原因
? 度量用于
? 选择过程改进和革新
? 估计过程改进和革新的效益和费用
? 度量过程改进和革新的实际的费用和效益
理解优化级
? 标识和消除不佳性能的原因
? 持续改进软件过程 。
重点在持续过程改进
CMMI的优化级
? 组织级改革和实施：根据组织的业务目
的, 选择和实施增量式和改革式的改进,
以便可度量地改进组织的过程和技术,
以支持组织的质量和过程性能目的
? 因果分析与解决方案：标识缺陷和其它
问题的原因, 并采取措施以预防它们将
来再次发生
不能跨越成熟度等级
? 成熟度等级提供了在更高层次有效实现
过程的必要基础
? 更高层次过程没有低层次提供的纪律是很容
易被牺牲的
? 在一个嘈杂的过程中创新的努力是暗淡的
? 更高成熟度等级的过程可以被组织在更
低成熟度等级执行，风险是在出现危机
时不能一致地应用
不能跨越成熟度等级
? 过程的能力以阶梯式建立的, 当其它过程不稳
定时, 一些过程是无效的 。
? 每一级为下一级改进提供了必要的基础 。
? 任何软件开发单位在致力于软件过程改善时,
只能由所处的层次向其紧邻的上一层次进化,
即过程的进化是渐进的, 不能是跳跃的 。 事实
上, 在由某一个成熟层次向上一更成熟的层次
进化时, 在原有层次中的那些已经具备的能力
应该得到保持与发扬 。
过程域
? 过程域 （ PAs） 是为达到一个目标集
所共同执行的相关实践集
? 在建立组织过程能力时, 这些过程
域是主要的建造块
? 每个过程域都定义在特定的成熟度
等级上
成熟度等级上的过程域
组织级创新和发展
因果分析与解决方案 5 优化的
4 定量管理的
3 已定义的
2 已管理的
连续的过程改进 （ 2）
定量管理 （ 2）
过程标准化 （ 14）
基本项目管理 （ 7）
组织级过程性能
定量项目管理
需求开发
技术解决方案
产品集成
验证
确认
组织级过程焦点
组织级过程定义
组织级培训
集成项目管理
集成供应商管理
风险管理
决策分析和解决方案
集成的组织环境
集成组队
需求管理
项目计划
项目监督和控制
供应商协议管理
度量和分析
过程和产品质量保证
配置管理
1 执行的
过程域 级 别 焦 点
(IPPD)
(IPPD)
(Supplier Sourcing,SS)
示例：特定目标和特定实践
? 特定目标（需求管理过程域）
? 管理被需求，并且与项目计划和工作
产品之间的不一致被识别。
特定实践（需求管理过程域）
– 在需求和项目计划及工作产品之间维
护双向的可追踪性。
示例：共性目标和共性实践
? 共性目标（成熟度等级 2）
? 制度化已管理过程
? 共性实践（成熟度等级 2）
? 建立组织方针
共同特征
共同特征是对共性实践的一种分类,
? 执行承诺,
建立管理方针
? 执行能力,
建立和维护计划，资源，分配的责任和权力，培训
? 定向实现,
度量，控制，执行实践
? 验证实现,
确保落实和一致
从另一个方向观察共同特征的
? 共同特征分类对所有过程域是非常类似
的
? 它们被作为制度化共同特征所提及，因
为它们,
? 确保过程域是有效的，可重复的和持久的
? 提供需要的基础支持
共同特征示例 —1（需求管理）
? 执行承诺,
? 为了计划和执行需求管理过程建立和
维护一个组织方针
? 执行能力,
? 对执行或者支持需求管理过程的人员
进行必要的培训
共同特征示例 —2（需求管理）
? 定向实现,
? 将需求管理过程指定的工作产品置于
适当的配置管理级别下
? 验证实现,
? 与高层管理人员一起评审需求管理过
程的活动、状态和结果并解决问题
GG2 制度化已管理过程
执行承诺
GP 2.1 (CO 1) 建立组织方针
执行能力
GP 2.2 (AB 1) 策划过程
GP 2.3 (AB 2) 提供资源
GP 2.4 (AB 3) 分配责任
GP 2.5 (AB 4) 培训人员
定向实现
GP 2.6 (DI 1) 管理配置
GP 2.7 (DI 2) 识别和包含利益相关者
GP 2.8 (DI 3) 监督与控制过程
验证实现
GP 2.9 (VE 1) 客观评价遵从性
GP 2.10 (VE 2) 与高层管理人员评审状态
GG3 制度化已定义管理过程
执行承诺
GP 2.1 (CO 1) 建立组织方针
执行能力
GP 3.1 (AB 1) 建立已定义的过程
GP 2.2 (AB 2) 策划过程
GP 2.3 (AB 3) 提供资源
GP 2.4 (AB 4) 分配责任
GP 2.5 (AB 5) 培训人员
定向实现
GP 2.6 (DI 1) 管理配置
GP 2.7 (DI 2) 识别和包含利益相关者
GP 2.8 (DI 3) 监督与控制过程
GP 3.2 (DI4) 采集改进信息
验证实现
GP 2.9 (VE 1) 客观评价遵从性
GP 2.10 (VE 2) 与高层管理人员评审状态
CMMI结构
阶段式描述与连续式描述的等
价关系
级别等价的一般准则
? 要达到成熟度等级 2，所有分配给成熟度等级 2
的过程域都必须达到能力级别 2或以上
? 要达到成熟度等级 3，所有分配给成熟度等级 2
和 3的过程域都必须达到能力级别 3或以上
? 要达到成熟度等级 4，所有分配给成熟度等级 2、
3和 4的过程域都必须达到能力级别 3或以上
? 要达到成熟度等级 5，所有的过程域都必须达
到能力级别 3或以上
成熟度等级 2对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 3对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 3对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程域
成熟度等级 4
过程域
成熟度等级 5
过程域
成熟度等级 5对应的过程能力
CL1 CL2 CL3 CL4 CL5
成熟度等级 2
过程域
成熟度等级 3
过程域
成熟度等级 4
过程域
成熟度等级 5
过程域
小结
? 1个 CMMI模型 2种表示方式，阶段式和连续式
? 两种表示方式的实质内容相同，只是内容组织不同
? 每种表示方式提供不同的实现过程的途径
? 应用 CMMI模型应当使用智慧、普遍的见识和专业的判
断
? 连续式
? 使用灵活，组织可以选择看重的领域
? 提供与阶段表示等价的等级划分
? 阶段式
? 按照基于证实的过程分组和顺序去实现的方式构建
谢谢！
汤铭端
68389085（ O） 68215365（ FAX）
mdtang@btamail.net.cn
