CMM能力成熟度模型考点
缩写
| 英文缩写 | 中文全称 |
|---|---|
| CMM | 能力成熟度模型 |
| CMMI | 能力成熟度模型集成 |
| TQM | 全面质量管理 |
| SEI | 软件工程研究所 |
| IDEAL | 初始化、诊断、建立、行动、推进 |
| ISO | 国际标准化组织 |
| CMU | 卡耐基•梅隆大学 |
| GAO | 美国总审计局 |
| JTC1 | 联合技术委员会1 |
| MQ | 成熟度问卷 |
| KPA | 关键过程域 |
第一章
软件工程研究所（Software Engineering Institute，SEI），领导改进软件工程实践的当前状况，以提高以软件为主的系统的质量。
由SEI提出的软件能力成熟度模型（CMM）描述了有效的软件过程单元的框架。
Humphrey开发了两种方法（软件过程评估和软件成熟度评价）和一个成熟度问卷，用以估计软件过程成熟度。
CMM的主要特点：
-
基于实际实践
-
最好地反映了实践的情况
-
反映了软件过程改进和软件过程评估执行人员的需求
-
形成文档
-
文档可以公开使用
对软件过程成熟度的深入了解：
-
研究非软件机构
-
执行和考察软件过程评估和软件能力评价
-
征求对模型变更的意见，并加以分析
-
同工业界和政府部门代表一起参加学术会议和研讨会
-
从工业界和政府部门评审人员那里征求反馈意见
软件过程是指软件开发人员开发和维护软件及相关产品的一套行为、方法、实践及变换过程。
软件过程评估是由一组受过训练的专业人员做出的估价，目的在于确定机构现行软件过程的状态，确定面向机构的高优先级的软件过程相关问题，以得到机构对软件过程改进的支持。评估在内部过程改进大纲中是关键性的一步。
软件能力评价是由一组受过训练的专业人员做出的估价，目的在于对实施软件工作的承制方的资格进行鉴别，或对现有软件工作中使用的软件过程状态进行监督。
软件过程能力描述了遵循某软件过程可能达到的预期结果的范围，软件过程能力关注预期结果。
软件过程效能表示遵循一个过程所达到的实际结果的一种度量，软件过程效能关注实际结果。
版本控制软件
-
GIT
第二章
成熟度级别
-
初始级（第一级）
-
行为特征：软件过程的特点是无序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。
-
-
可重复级（第二级）
-
行为特征：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
-
-
已定义级（第三级）
-
行为特征：已将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
-
-
已管理级（第四级）
-
行为特征：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。
-
-
优化级（第五级）
-
行为特征：过程的量化反馈和先进的新思想、新技术促使过程不断改进。
-
处于级别一的机构特征之一是 做出不切实际的承诺。
处于级别二的软件开发机构的过程能力可概括为 有纪律的。
处于级别三的软件开发机构的过程能力可概括为 标准化的和一致的。
处于级别四的软件开发机构的过程能力可概括为 定量的和可预测的。
处于级别五的软件开发机构的过程能力的特点是 过程可以不断得到改进。
处于每个成熟度级别的软件过程可视性
-
在级别一，软件过程是一个不定形的实体（一个黑盒），项目过程的可视性是有局限的。
-
在级别二，客户需求和工作产品受到控制，已建立基本的项目管理实践。
-
在级别三，盒子的内部结构，即项目定义的软件过程中的任务，具有可视性。
-
在级别四，定义的软件过程得到定量使用和控制。
-
在级别五，不断尝试新的技术和改进的软件开发方法，以受控方式提高生产率和软件质量。
影响过程成熟度的因素有
-
人员
-
技术
-
测量
提高CMM级别的含义
| 级别1 | 级别2 | 级别3 | 级别4 | 级别5 | |
|---|---|---|---|---|---|
| 过 | 几乎没有稳定过程存在或被使用过 | 进行文档化，并进行稳定估计和计划，约定过程处于该项目级别 | 整个机构使用综合管理和工程过程 | 定量理解过程并使之保持稳定 | 持续的、系统的改进过程 |
| 程 | “仅仅执行过程” | 当问题出现时确定问题并进行修改 | 预测并预防问题，或将它们的影响降到最低 | 了解单个问题产生的根源并将其排除 | 了解问题的公共源头并将其排除 |
| 人 | 成功取决于个人的杰出表现 | 成功取决于个人素质，管理系统支持 | 项目组一起工作，也可以是集成产品小组 | 每个项目都有着强烈的团队精神 | 整个机构中有着强烈的团队精神 |
| 工作方式是“救火” | 理解和管理约定 | 根据不同的任务计划和提供培训 | 过程改进涉及每个人 | ||
| 员 | 各纪律之间的关系不协调甚至可能是对立的 | 人员得到培训 | |||
| 技术 | 引入新技术有风险 | 已建立技术支持，稳定的活动 | 定量评价新技术 | 定量评价新技术 | 尽早跟踪新技术并推广应用 |
| 测 | 数据收集与分析是混乱的 | 单个项目使用的计划和管理数据 | 在所有定义的过程中收集和使用数据 | 整个组织中将数据的定义和收集标准化 | 使用数据进行评价并选择过程改进 |
| 量 | 在整个项目中系统的共享数据 | 数据被用来定量的理解和稳定过程 |
作为一个成熟的机构，首先期待改进的是可预测性，第二个改进的是可控性，第三个改进是有效性。
第三章
成熟度级别是一个严格定义的、向着达到成熟软件过程目标进发的平台。CMM的顶层结构中包括五个成熟度级别。每个成熟度级别表示了过程能力的水平。
CMM结构
成熟度级别
关键过程域
-
初始级
-
可重复级
-
需求管理
-
目的：
-
-
目标：
-
控制指定给软件的系统需求，为软件工程和管理应用建立基线
-
保持软件计划、产品和活动与指定给软件的系统需求一致
-
-
-
软件项目计划
-
目的：
-
制定实施软件工程与管理软件项目的合理的计划。
-
-
目标：
-
形成软件估计文档，以供计划和跟踪软件项目使用
-
制定软件项目的活动和约定计划，并形成文档
-
相关小组和个人认同与软件项目相关的约定
-
-
-
软件项目跟踪和监督
-
目的：
-
能够随时掌握软件项目的实际开发过程，使得当软件项目的执行活动与软件计划相背离时，管理部门能采取有效的措施。
-
-
目标：
-
依据软件计划对实际结果和过程运行效能进行跟踪
-
当实际结果和过程运行效能与软件计划相差甚远时，采取措施设法关闭
-
软件约定的更改经相关小组和个人同意认可
-
-
-
软件分包合同管理
-
目的：
-
选择高质量的软件分承制方，并进行有效的管理。
-
-
目标：
-
主承制方选择合格的软件分承制方
-
主承制方和软件分承制方就彼此的约定达成一致
-
主承制方和软件分承制方保持工作联系
-
主承制方根据指定的约定跟踪软件分承制方的实际执行结果及其情况
-
-
-
软件质量保证
-
目的：
-
为管理者提供有关软件项目的过程和产品的适度可见性。
-
-
目标：
-
对软件质量保证活动做到有计划
-
客观地验证软件产品及其活动是否遵守应用的标准、规程和需求
-
将软件质量保证活动及其结果及时通知相关小组和个人
-
由上级管理部门及时处理软件项目内部解决不了的不一致性问题
-
-
-
软件配置管理
-
目的：
-
保证软件项目生成的产品在软件生命周期中的完整性。
-
-
目标：
-
软件配置管理活动是有计划的
-
所选择的软件工作产品是经过标识、受到控制并具有可用性的
-
所标识的软件工作产品的更改是受控的
-
让相关小组和个人及时了解软件基线的状态和内容
-
-
-
-
已定义级
-
机构过程焦点
-
目的：
-
为改进机构的整体软件过程能力，建立负责软件过程活动的机制。
-
-
目标：
-
机构内部软件过程的制定和改进活动协调一致
-
相对于过程标准，所使用的软件过程的优势和薄弱环节标识清楚
-
机构级的过程开发和改进活动有计划
-
-
-
机构过程定义
-
目的：
-
开发和维护一组可用的能提高项目软件过程整体效能的软件过程资源集合，并为在定量过程管理中确定有意义的数据提供基础，这些资源提供了一组稳定的准则，并通过诸如培训等机制使其制度化。
-
-
目标：
-
开发和维护一个机构标准软件过程
-
收集、评审供软件项目使用的机构标准软件过程的相关信息，使之可用
-
-
-
培训大纲
-
目的：
-
提高个人的技能和知识，使其能更有效地、更好地完成工作。
-
-
目标：
-
培训活动是有计划的
-
提供完成软件管理和技术任务所需的知识与技能培训
-
软件工程组和软件相关小组中的成员受到所需的培训
-
-
-
综合软件管理
-
目的：
-
将软件工程和管理活动结合成为密切相关、定义完整的软件过程。
-
-
目标：
-
项目定义的软件过程是机构标准软件过程的剪裁版
-
依据项目定义的软件过程对项目进行计划和管理
-
-
-
软件产品工程
-
目的：
-
始终执行经过严格定义，并综合了所有软件工程活动的工程过程，从而高效生产出稳定的软件产品。
-
-
目标：
-
定义和综合各软件工程任务，并在生产软件的过程中始终如一地执行这些任务
-
软件工作产品彼此间保持一致性
-
-
-
组间协调
-
目的：
-
使软件工程组与其他小组能积极协作，从而使项目能更好、更有效地满足客户需求。
-
-
目标：
-
客户需求经所有相关小组通过
-
各工程组之间的约定经相关小组通过
-
各工程组识别、跟踪和解决组间问题
-
-
-
同行评审
-
目的：
-
尽早地、有效地排除软件产品中的缺陷。
-
-
目标：
-
计划同行评审活动
-
识别和排除软件产品中的缺陷
-
-
-
-
已管理级
-
定量过程管理
-
目的：
-
定量地控制软件项目的过程效能。
-
-
目标：
-
定量过程管理活动是有计划的
-
定量地控制项目定义的软件过程的过程运行效能
-
机构标准软件过程的过程能力能定量地区分
-
-
-
软件质量管理
-
目的：
-
定量地评价软件产品的质量，并实现具体的质量目标。
-
-
目标：
-
项目的软件质量管理活动是有计划的
-
软件产品质量的可测目标和目标的优先级被定义
-
实现软件产品质量目标的实际进展过程被量化管理
-
-
-
-
优化级
-
缺陷预防
-
目的：
-
明确产生缺陷的原因并预防它们再次发生。
-
-
目标：
-
缺陷预防活动是有计划的
-
找出并标识缺陷产生的共同原因
-
缺陷产生的共同原因被排序，并被系统地消除
-
-
-
技术更新管理
-
目的：
-
确定新技术，并有序的将这些技术引入机构内。
-
-
目标：
-
有计划地进行技术更新
-
评价新技术，确定他们对质量和生产率的影响
-
将适用的新技术转到机构的正常实践中
-
-
-
过程更改管理
-
目的：
-
不断改进机构中所使用的软件过程，从而提高软件质量和生产率，缩短产品开发生命周期。
-
-
目标：
-
有实施持续的过程改进的计划
-
机构范围内的人员都参与机构的软件过程改进活动
-
持续地改进机构标准软件过程和项目定义的软件过程
-
-
关键实践描述了对关键过程域的有效实施和制度化起最重要的基础设施和活动。
为了方便，用共同特性将描述关键过程域的关键实践组织起来。
共同特性是一些属性，指明一个关键过程域的执行和制度化是否有效、可重复和可持续。共有五个特性
-
执行约定
-
执行约定描述机构为确保过程的建立和持续而必须采取的一些措施。
-
典型内容包括建立机构策略和领导关系
-
-
执行能力
-
执行能力描述了项目或机构完整地实现软件过程所必须有的先决条件。
-
典型内容包括资源、机构结构和培训。
-
-
执行活动
-
执行活动描述了执行一个关键过程域所必须的活动、任务和规程。
-
典型内容包括制定计划和规程、执行和跟踪以及必要时采取纠正措施。
-
-
测量和分析
-
测量和分析描述了为确定与过程有关的状态所需的基本测量实践。这些测量可以用来控制和改进过程。
-
典型内容包括可能采用的测量实例
-
-
验证实现
-
验证实现描述了为确保执行的活动与已建立的过程一致所采取的步骤。
-
典型内容包括管理部门和软件质量保证组实施的评审和审核。
-
第四章
培训包括正规培训和非正规培训
“定向培训”这个术语大致指传授肤浅技能或知识而不是使其成为一个专家。定向培训是指对某个专题进行概述和介绍，培训对象为监督该专题完成情况的人员以及与此相关的人员。
计划分为正规计划和非正规计划，非正规计划可作为正规计划的一部分记入文档或者作为正规计划的补充。
正规计划：
-
软件开发计划
-
软件质量保证计划
-
软件配置管理计划
非正规计划：
-
同行评审计划
-
风险管理计划
-
技术管理计划
任务是指由一个或多个人承担已定义职责的单位。
小组由负责一组任务或活动的部门、负责人和人员组成。
小组包括
-
指定的兼职成员
-
来自不同部门的几个兼职成员
-
几个专职成员
-
专职工作的一个或多个部门
组成小组时考虑的因素包括
-
分派的任务和活动
-
项目规模
-
机构结构和机构文化
软件质量保证组，集中关注项目活动；
软件工程过程组，集中关注机构范围内的活动。
项目软件负责人对一个项目的所有软件活动负完全责任，控制一个项目的所有软件资源，按照软件约定与项目负责人打交道。
项目负责人对整个项目负完全责任，是指导、控制、管理和规范某个软件或硬件系统建设的人，是最终对客户负责的人。
上级负责人是机构中足够高层的负责人，主要关注机构的长期活力，而不是短期计划和契约性质的事务与压力。
负责人在其责任范围内对实施任务和活动的人员提供技术、管理指导与控制，其职能包括职责范围内的计划、组织、指导和控制工作。负责人是最大的。
一线软件负责人在由软件工程师和其他相关人员组成的机构中，一线软件负责人负责完成人事和技术活动的直接管理工作。
软件任务主管负责某项具体任务的技术小组的领导工作，主管技术工作，并负责向该任务的工作人员提供技术指导。
工作人员
软件工程人员就是软件技术人员（如分析员、程序员和工程师），包括软件任务主管，他们执行项目的软件开发和维护活动，但不是负责人。
软件工程组是指负责一个项目的软件开发和维护活动的人员。
软件相关组是指代表一个软件工程科目的一组人员，这类小组支持但不直接负责软件开发和维护工作。
软件工程过程组是协助对机构所使用的软件过程进行定义、维护和改进的一个专家小组。在关键实践中，这个小组通常称为“负责机构的软件过程活动的小组”。
系统工程组是包括有负责人和技术人员的一个小组，负责规格说明系统需求，分配系统需求到硬件、软件和其他部件，规格说明硬件、软件和其他部件之间的接口，并监督这些部件的设计和开发，以确保与所做的规格说明的一致性。
系统测试组是包括有负责人和技术人员的一个小组，负责计划和实施对软件的单独系统测试，以确定其软件产品是否满足其需求。
软件质量保证组是包括有负责人和技术人员的一个小组，负责计划和实施项目的质量保证活动，以确保软件开发活动遵循软件过程规程和标准。
软件配置管理组是包括有负责人和技术人员的一个小组，负责计划、协调和实施项目的正规配置管理活动。
培训组是包括有负责人和技术人员的一个小组，负责协调和安排机构的培训活动。
软件相关组是指代表一个软件工程项目的一组人员，这类小组支持但不直接负责软件开发和维护。包括
-
软件质量保证组
-
软件配置管理组
-
软件工程过程组
具有独立性的实践
-
SQA组（软件质量保证组）
-
测试小组
软件过程资源是一组由机构管理的实体，由项目用于开发、剪裁、管理和实施其软件过程。
”管理和控制“指的是在一定时间内所使用工作产品的版本是明确的，并以受控方式进行修改。
机构建立和维护机构软件过程资源
-
机构标准软件过程
-
认可使用的软件生命周期描述
-
剪裁机构标准软件过程的指南和准则
-
机构的软件过程数据库
-
软件过程相关文档库
所有任务都可以看成是活动，但并不是所有的活动都可以严格定义成任务。
分配给过程类别的关键过程域
第五章
SEI制定的软件改进方法称为IDEAL方法，代表着组成软件过程改进周期的五个阶段。IDEAL是一个整体的框架，描述了成功的过程改进所需经历的阶段、实施的活动和所需的资源。
-
初始化（Initiating）
-
诊断（Diagnosing）
-
建立（Establishing）
-
行动（Acting）
-
推进（Leveraging）
一般有两种类型的评估
-
软件过程评估
-
软件过程评估用于决定机构当前软件过程的状态，决定一个机构所面临的高优先级的过程相关问题，并且获得机构对软件过程改进的支持。
-
-
软件能力评价
-
软件能力评价用来确定合格的软件项目承制方，或用来监督在目前的软件项目中正在进行的软件过程的状态。
-
评估和评价的共同步骤
-
选择估价小组
-
填写成熟度问卷
-
进行响应分析
-
现场访问、会谈和文档评审
-
提出基于CMM的调查结果
-
制作KPA（关键过程域）剖面图
基于CMM的估价方法
-
使用软件过程成熟度问卷开始现场调查
-
使用CMM指导进行现场调查
-
以CMM的关键过程域的概念明确地提出过程的强弱之处，找出问题
-
获得一个基于关键过程域目标的满足分析的剖面图
-
根据调查结果清单和关键过程域剖面图，向合适的部门或单位提出结论意见
导致差异的原因
-
评估范围不同
-
即使在同一个机构中，所选的项目实例也会影响评估范围
基于CMM的软件过程改进是否成功取决于三个因素
-
用常识表示成熟度级别和关键过程域的似是而非的表述
-
从TQM工作中获得的一般数据
-
对已公布的数量有限的案例的研究
第六章
SSOS：航天飞机机载软件
每个操作增量通过下列三个步骤进行开发
-
客户需求定义
-
软件设计、开发和集成
-
独立验证
SSOS项目确定四个主要障碍阻碍了高质量软件的生产
-
落后的项目管理
-
从进度而不是从质量需求驱动项目
-
不能控制需求内容和软件产品基线
-
不能跟踪错误和进行过程更改以消除错误根源
SSOS项目雇佣了大约270人。
SSOS项目的需求管理过程
-
需求构思
-
需求生成
-
需求分析
-
需求审查
-
需求认可
SSOS项目软件缺陷预防过程
-
确定缺陷的原因并改正它
-
确定并改正缺陷的过程原因
-
改正遗漏缺陷检测活动
-
检查产品中别处的类似缺陷
1993年，成立了四个小组以改进SSOS项目的教育问题
-
教育过程组
-
知识库组
-
课程组
-
浙公网安备 33010602011771号