CMMI软件度量
CMMI认证资料之度量分析流程模板
项目度量员辅助项目经理完成项目阶段数据分析。
AC14 项目结项参见《项目管理流程》3.4项目结项，项目结项标志着项目的度量工作结束。
AC15 组织级项目健康状态跟踪组织级QA负责对公司已结项的项目的健康状态进行收集分析：对项目的进度偏差、缺陷密度等数据进行搜集和验证（来源：项目周报，里程碑中高层了解项目状态、作出项目决策提供依据。
AC16 组织级项目度量分析每年第一季度，组织级QA负责依据组织级度量表的定义和要求，对公司本年度所有项目（含当年结项的项目）的度量项数据进行搜集、验证和给出改进建议，并在下年度的第一个工作日发送给相关部门的负责人、公司高层管理者，为中高层识别差距、进行改进提供依据。
7.工作指南原因分析指南8.过程模板编号活动模板名称AC01制定、更新研发商业目标、质量目标和能力基线组织度量数据表AC02制定项目质量目标（QPPO）和度量计划项目综合管理表，项目里程碑报告AC03实际工作量录入项目周报AC04实际规模和进度跟踪项目综合管理表、项目度量数据表AC05项目规模、工作量、进度每周分析项目度量数据表AC06需求数据录入和统计需求跟踪矩阵AC07评审数据录入和统计评审处理表，BUG管理表AC08测试数据录入和统计BUG管理表AC09验收数据录入和统计BUG管理表AC10QA审计QA检查记录表AC11项目度量数据分析项目度量数据表AC12项目阶段数据分析项目里程碑报告AC13项目结项AC14组织级项目健康状态跟踪组织项目健康状态跟踪表AC15组织级项目度量分析组织度量数据表理表，项目里程碑报告理表、项目度量数据表里程碑报告，项目度量数据表等），对组织的效益状况、质量状况等进行跟踪分析，给出各项目的健康状况描述，并发送给相关部门的负责人、公司高层管理者，为验证和汇总（来源：项目周报，里程碑报告，项目健康状态跟踪表，项目度量数据表等），识别和度量目标的差距，对影响目标达成的关联的基线和模型进行分析，提供依据。
CMMI度量的一些关键指标
CMMI度量的一些关键指标
CMMI度量的一些关键指标
1.进度方面
实际进度的计划进度的偏差情况
返工时间占项目总时间的比例情况
2.工作量
实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工，评审，测试和处理变更工作量的分别度量
3.成本
计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
4.软件质量保证
不合格项的信息
SQA具体的审核信息
5.Review的结果
Review的活动项的状态
6.问题报告
问题项的具体状态(打开,处理,关闭)
问题的原因的分析，对问题的分类的统计
问题的平均处理周期度量
7.同行评审和缺陷
同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率，评审速率的度量
同行评审的覆盖率
8.需求的度量
需求的规模的情况
需求的稳定度或需求的变更率
需求变更的不同类型的分布情况
需求变更处理的效率和周期度量
9.测试过程
测试的生产率的度量
测试规模的度量
生命周期不同阶段发现缺陷的数量分布，泄漏情况测试BUG的密度
缺陷率
10.产生的文档
文档的分类
文档的页数
各阶段产生的文档数。
软件过程能力评估师考试内容
软件过程能力评估师考试内容
软件过程能力评估师是指通过对软件开发组织的软件过程进行评估，从而提供改进建议和指导的专业人员。
软件过程能力评估师考试内容主要包括以下几个方面：
1. 软件过程基础知识：考察考生对软件过程概念、目标、原则等基本知识的掌握程度。
包括软件生命周期、软件过程模型、软件度量和评估等内容。
2. 软件过程改进方法与工具：考察考生对软件过程改进方法和工具的了解和应用能力。
包括CMMI（Capability Maturity Model Integration）、SPICE（Software Process Improvement and Capability Determination）等常用的软件过程改进模型。
3. 软件度量与度量分析：考察考生对软件度量的理解和应用能力。
包括软件度量的分类、指标的选择和使用、度量结果的分析和解读等内容。
4. 软件过程评估与评价：考察考生对软件过程评估方法和技术的熟悉程度。
包括过程评估的步骤、评估模型的选择、评估结果的分析和报告撰写等内容。
5. 软件过程能力提升实践：考察考生对软件过程能力提升实践的了解和应用能力。
包括软件过程改进的步骤、实施策略、团队协作与管理等内容。
需要注意的是，不同地区或组织的软件过程能力评估师考试内容可能有所不同，以上内容仅为一般性参考。
想要顺利通过考试，考生
需要充分准备，并熟悉相关知识和技术。
基于CMMI的中小型软件企业软件度量研究
量 的表 征参 数 ． 置合 适 的度 量方 法 ， 设 更重 要 的是 能对 为 ： 目标 的设 立 ， 规程 的制定 ， 数据 的收 集分 析 。 果 的 结 分 析利 用［ ３ １ 中每 个关键 步 骤都包 含 若 干子步 骤 。 。其 它 这 些采 集 的度量 数据 进行 分 析 ．度量 和分 析活 动 是用
．． 某种 计 算 而得 到 ． 进 度 性 能指 数 、 陷密 度 、 如 缺 测试 或 ２２１ 目标 的设 立 （） １ 确定 度量 目标 验证覆 盖 率 、 可靠 性度 量 值 等 。该 实 践 的产 出物有 ： 基
制定规程 收集分析数据
确 定 度 量 目标
获得分析结果
确定成功 因素
解该 实体 及其属 性 即度量 就 是对事 物 属性 的量 化表 物 有 ： 数据 采集 和存 储规 程 。
示 软件 度量 是针对 计算 机 软件 的度量 。 是对 一个 软件
ｆ１ 定分 析规 程 ： 定如 何 分析 数据 ， ４确 确 同时 也再 次
系统 、组 件或过 程具 有 的某 个 给定 属性 的度 的一 个定 检 查 是否 采集 了必 需 的数 据 。 实践 的产 出物有 ： 该 分析
所 需 要 的 目标相 一致 。所 以 。在 进 行度量 定义 和 实施 前 ． 先要 明确组 织或项 目的 目标 ， 对其 含义 和要 求 首 并
ｆ ） 储分 析数据 ２存 ‘ Ｃ ＭＭＩ 中要求组 织 和项 目级都 要建立 度 量数据 库 。
达 成一 致 的理解 ．以便 将它们 作 为确 定度 量 目标 的基 度 量数据 库可 以根据 度 量元操 作定 义建 立 。支 持对 数 础。 例如 。 组织 目标是 “ 打造优 质产 品 ”那 么 ， ， 就需要 对 据 的各种 检索 。度量 数 据库 的建立 为组 织数据 的统 一 “ 优质 产 品” 内容 进行 详细 的定 义 。通 过 编写 《 的 组织／ 存储 、 管理 和利 用提供 了方便 。 并为 数据 的利用 提供 了 项 目目标详解 》 保 证所有 人员 对 目标有 清 楚一 致 的认 唯一 的出 口。 进 入组织 度量库 之前 。 有数据 必须 经 ， 在 所
CMMI4体系的测试过程中定义的四个度量指标测试覆
CMMI4体系的测试过程中定义的四个度量指标测试覆在CMMI4体系的测试过程中定义了四个度量指标：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。
为了使专/兼职测试人员理解这四个度量指标，了解如何利用现有资源收集度量数据，本文介绍这四个指标的含义及数据收集方法。
在CMMI4体系的测试过程中定义了四个度量指标：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。
为了使专/兼职测试人员理解这四个度量指标，了解如何利用现有资源收集度量数据，本文介绍这四个指标的含义及数据收集方法。
1测试覆盖率测试覆盖率是指测试用例对需求的覆盖情况。
计算公式：已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
首先说广度，是否需求规格说明书中的每个需求项都在测试用例中得到设计。
其次说深度，通俗的说，是不使我们的测试设计流于表面，是否能够透过客户需求文档，挖掘出可能存在问题的地方。
例如：重复点击某个按钮10次，或者依次执行新增、删除、新增同一数据的记录、再次删除该记录操作。
在笔者的实际工作中碰到过这么一个例子，一个使用PL/SQL编写的系统，在某个查询界面，重复点击《查询》按钮6次后，系统就会出现查询功能失效的问题。
经调试，开发人员发现是由于gdi资源未完全释放的缘故。
在设计测试用例时，我们很少单独设计广度或深度方面的测试用例，而一般是结合在一起设计。
为了从广度和深度上覆盖测试用例，我们需要考虑设计各种测试用例，如：用户场景(识别最常用的20%的操作)、功能点、功能组合、系统场景、性能、语句、分支等。
在执行时，需要根据测试时间的充裕程度按照一定的顺序执行。
通常是先执行用户场景的测试用例，然后再执行具体功能点、功能组合的测试。
测试覆盖率数据的收集，我们可以通过需求跟踪矩阵RTM来实现。
在需求跟踪矩阵，测试人员填写的"系统测试用例"列的数据。
CMMI5文档之度量指标与度量项参考列表
组织培训工作量
组织培训课程执行情况统 计
培训
组织培训人员统计
组织培训费用统计
组织培训效果统计
评审
过程改进评审工作量
组织级 组织过程定义计划、实际成本
组织度量数据表
组织级 SPI的计划工作量
SPI计划
组织级 SPI的实际工作量
组织度量数据表
组织级 定义修改的过程文档页数
组织度量数据表
组织级 过程改进的提案数量、完成数量
从需求模块功能矩阵中采集
项目级 需求原始定义个数
从需求模块功能矩阵中采集
项目级 各阶段完成时度量累计增加需求数
从需求模块功能矩阵中采集
度量类别
度量项
级别
度量数据选用表
描述
采集途径
二、面向过程改进与组织内培训
成本
过程定义成本
工作量
过程改进计划工作量 过程改进实际工作量
规模
过程定义规模 过程改进提案数量
次
中采集
QA Me1
项目级
从项目计划变更记录中收集
TO Me1
项目级 计划变更提出到计划批准的历时
从变更申请和计划批准单中采集
TO Me1
项目级 SCM人员
项目状态报告、项目总结报告
项目级 SQA人员
项目状态报告、项目总结报告
项目级 测试组成员
项目状态报告、项目总结报告
项目级 度量数据报告日期
项目状态报告、项目总结报告
项目级 项目名称
项目状态报告、项目总结报告
项目级 如V字模型、螺旋型等
项目状态报告、项目总结报告
项目级 如金融、电力、电信等
项目状态报告、项目总结报告
项目级 各阶段完成时度量累计删除需求数
基于CMMI的软件过程度量
然 而 ，ＣＭＭ、ＣＭＭＩ等 模 型 都 没 有精 确定 义实 施 软 件 过 程 度量 以及 收集 并 分 析 软 件过 程 数 据 的 方 法 ，也 没 有 指 明应 该 使 用 何 种 工具 及 方 法 完 成 相关 的度 量 操 作 。因此 到 目前 为 止 ，各 企 业 只是 按 照 自 己的 理解 来 进 行 软 件 过 程度 量 ，仍 未 有 一 种 操 作标 准 和指 南 来 帮助 企 业 有 效 地 实施 相 关 的度 量 活 动 。
Ｋ ｅｙ ｗｏｒｄｓ：ｓｏｆｔｗ ａｒｅ ｐｒｏｃｅｓｓ；ｍ ｅａｓｕｒｅｍ ｅｎｔ；ＣＭ Ｍ Ｉ
１介 绍 过 程 管 理 已经 逐 渐 成 为 了现 代 软 件 质 量 管 理 的核 心 ，从 二 十 世 纪 七 十 年 代 开 始 ，就 不 断 涌 现 出 了各 种 软 件 过 程 质 量 模 型 和 软
件 质量 标 准 ｌ１＿，包 括 ＣＭＭｌ引、ＣＭＭＩＮ、ＩＳ０９００１［ Ｉ、Ｓ ＰｌＣＥＩ 等 。虽 然 ，上 述 各 大模 型 和标 准 都 不 尽 相 同 ，但 它们 都不 约而 同地 把 关 注 点 放 在 了 基于 度 量 的 软 件 过程 改 进 之 上 。也 正 因 为如 此 ，目前 ，过 程 度量 已经 成 为 了软 件 过程 能力 度 评 估 和 管理 的重 要 组 成部 分 。
cmmi的五个级别及标准 量化
CMMI的五个级别分别是：初始级、可管理级、已定义级、量化管理级和优化管理级。
以下是每个级别的标准和特点：
1.初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，
成功取决于个人努力。
管理是反应式的。
2.可管理级：建立了基本的项目管理过程来跟踪费用、进度和功能特性。
制
定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3.已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成
该组织的标准软件过程。
所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4.量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和
产品都有定量的理解与控制。
管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5.优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断
改进。
以上信息仅供参考，如有需要，建议查阅官方网站。
CMM(CMMI)基础知识介绍
第5级
◆ 特征 （1） 整个组织特别关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生，不 断地提高他们的过程处理能力。 （2） 加强定量分析，通过来自过程的质量反馈和吸收新观念，新科技，使软件过程不断地得到 改进。 （3） 根据软件过程的效果，进行成本 / 利润分析，从成功的软件过程中吸取经验，加以总结。 把最好的创新成绩迅速向全组织转移，对失败的案例，由软件过程小组进行分析以找出原因。 （4） 组织能找出过程的不足并预先改进，把失败的教训告知全组织以防止重复以前的错误。 （5） 对软件过程的评价和对标准软件过程的改进，都在全组织推广。 过程 不断地系统地改进软件过程。 理解并消除产生问题的公共根源，在任何一个系统中都可找到：由于随机变化造成重复工作、 进而导致时间浪费。为了防止浪费人力可能导致的系统变化，要消除“公共”的无效率根源”， 防止浪费发生。尽管所有级别都存在这些问题，但这是第5级的焦点。 ◆ 人员 整个组织都存在自觉的强烈的团队意识。 （2） 每个人都致力于过程改进，人们不再以达到里程碑式的成就而满足，而力求减少错误率。 ◆ 技术
CMM2级的关键过程域是8个，目标20个， 承诺9个，能力25个，活动62个，度量6个， 验证19个。
CMM等级及特点
12
CMM过程的可视性
5 输入
输出
4 输入
3 输入
2 输入 1 输入
13
输出 输出 输出 输出
1．6 CMM1．1的等级及其特征
第1级 ◆ 特征
（1） 软件过程的特点是杂乱无章，有时甚至是混乱，几乎没有定义过程 的规则或步骤。 （2） 过分的承诺。常作出良好的承诺：如“按照软件工程方式，有序的 工程步骤来做”；或达到高目标的许诺。实际上却出现一系列问题。 （3） 遇到危机就放弃院计划过程，反复编码和测试。 （4） 成功完全依赖个人努力和杰出的专业人才，取决于超常的管理人员 和杰出有效的软件开发人员。具体的表现和成果都源自于或者说决定于个 人的能力和他们先前的经验、知识以及他们的进取心和积极程度。 （5） 能力只是个人的特性，而不是开发组织的特性。依靠着个人的品质 或承受着巨大压力；或找窍门取得成果。但此类人一旦离去，组织的稳定 作用也随之消失。 （6） 软件过程是不可确定的和不可预见的。软件能力成熟度处于一级的 软件组织其软件过程在实际工作过程中经常被改变（过程是随意的）。这 类组织也在开发产品，但其成果是步稳定的，不可预见的不可重复的。也 就是说，软件的计划、预算、功能和产品的质量都是不可确定的和不可预 见的。
cmmi中系统计量单位
CMMI中系统计量单位引言软件项目管理中，确保项目能按时交付、符合客户需求并满足质量要求是至关重要的。
为了达到这些目标，需要对项目进行有效的测量和评估，以便获得准确的数据和指标。
CMMI（软件能力成熟度模型集成）是一种被广泛接受的软件过程改进框架，它为组织提供了定义、实施和评估项目和过程的方法。
在 CMMI 中，系统计量单位起着至关重要的作用。
系统计量单位是一种衡量软件过程质量、进展和绩效的手段，通过收集和分析数据来指导项目的决策和改进。
本文将详细介绍 CMMI 中系统计量单位的意义、使用方法以及相关注意事项。
什么是系统计量单位？系统计量单位（Software Measurement Units，SMU）是 CMMI 提供的一种术语，用于度量和评估软件项目和过程的关键指标。
系统计量单位是确定进展和绩效的基础，并为决策者提供了直观的数据支持。
正确认识和使用系统计量单位对于提高软件项目管理的效率和可靠性至关重要。
系统计量单位的种类根据 CMMI，系统计量单位可以分为以下几个类别：1. 规模度量单位（Scale Measurement Units）规模度量单位用于衡量软件项目和过程的规模大小。
典型的规模度量单位包括代码行数、功能点数、用例数量等。
规模度量单位可以帮助评估项目的复杂性和规模，以便做出相应的资源和进度安排。
2. 成本度量单位（Cost Measurement Units）成本度量单位用于衡量软件项目和过程涉及的成本。
这些成本包括软件开发、测试、部署以及维护所需的人员和资源成本。
通过对成本的度量，可以帮助项目管理人员合理安排资源，并对项目的经济效益进行评估。
3. 进度度量单位（Schedule Measurement Units）进度度量单位用于衡量软件项目和过程的进展和时间安排。
典型的进度度量单位包括工作量、里程碑完成情况、任务完成率等。
通过对进度的度量，可以及时发现项目进展的偏差，并采取相应措施进行管理和调整。
cmmi五个成熟度级别
CMMI 等级的含义五个成熟度级别之间的比较如下:1,初始级特征:(1)软件过程的特点是杂乱无章,有时甚至混乱.几乎没有定义过程的规则或步骤.(2)过分的尽诺.常做出良好的承诺:如"按照软件工程方式,有序的工程过程来工作";或达到高目标的许诺.但实际上却出现一系列危机.(3)遇到危机就放弃原计划过程,反复编码和测试.(4)成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员和杰出有效的软件开发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验,知识以及他们的进取心和积极程度.(5)能力只是个人的特性,而不是开发组织的持性.依靠着个人的品质或承受着巨大压力,或找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失.(6)软件过程是不可确定的和不可预见的.软件成熟性程度处于第一级的软件组织的软件过程在实际的工作过程中被经常的改变(过程是随意的).这类组织也在开发产品,但其成果是不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预算,功能和产品的质量都是不可确定和不可预见的.过程:(1)极少存在或使用稳定的过程.(2)所谓"过程",往往是"就这么干"而言. (3)各种条例,规章制度互不协调,甚至互相矛盾人员:(1)依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续(2)人们的工作方式如同"救火".就是在开发过程中不断地出现危机,以及不断的"救火".技术: 引进新技术是极大风险度量: 不收集数据或分析数据改进方向:(1)建立项日管理过程.实施规范化管理.保障项目的承诺.(2)首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正反映客户的要求.(3)建立各种软件项目计划.如软件开发计划,软件质量保证计划,软件配置管理计划,软件测试计划,风险管理计划及过程改进计划.(4)开展软件质量保证活动(SQA).2,可重复级特征(1)进行较为现实的求诺,可按以前在同类项目上的成功经验建立的必要过程准则来确保再一次的成功.(2)主要是逐个项目地建立基本过程管理条例来加强过程能力.(3)建立了基本的项目管理过程来跟踪成本,进度和功能.(4)管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题.(5)采用基线(BASELINE)来标志进展,控制完整性.(6)定义了软件项目的标准,并相信它,遵循它.(7)通过于合同建立有效的供求关系.过程(1)软件开发和维护的过程是相对稳定的,但过程建立在项目一级.(2)有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验可以被重复.(3)问题出现时.有能力识别及纠正.其承诺是可实现的.人员(1)项目的成功依赖于个人的能力以及管理层的支持.(2)理解管理的必要性及对管理的承诺.(3)注意人员的培训问题, 技术建立技术支持活动,并有稳定的计划. 度量每个项目建立资源计划.主要是关心成本,产品和进度.有相应的管理数据.改进方向(1)不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具体经验归纳为全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活动,作为软件开发组织的责任.(2)确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软件过程中.从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础.(3)建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务,以适应未来软件项目的要求.(4)积累数据:建立组织的软件过程库及软件过程相关的文档库(5)加强培训.3,确定级特征：(1)无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发组织的标准软件过程.(2)软件过程标准被应用到所有的工程中,用于编制和维护软件.有的项目也可根据实际情况,对软件开发组织的标准软件过程进行剪裁.(3)在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以完全控制的,从而软件质量也可以控制.(4)软件工程过程组(SEPG)负责软件过程活动.(5)在全组织范围内安排培训计划.过程：(1)整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳定的和可重复的,具有连续性的.(2)软件过程起了预见及防范问题的作用,能使风险的影响最小化人员：(1)以项目组的方式进行工作.如同综合产品团队.(2)在整个组织内部的所有人对于所定义的软件过程的活动,任务有深入理解.大大加强了过程能力.(3)有计划地按人员的角色进行培训技术在定性基础上建立新的评估技术.度量：(1)在全过程中收集使用数据.(2)在全项目中系统性地共享数据改进方向(1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果.(2)通过软件的质量管理达到软件的质量目标.4,管理级特征：(1)制定了软件过程和产品质量的详细而具体的度量标准.软件过程和产品的质量都可以被理解和控制.(2)软件组织的能力是可预见的.原因是软件过程是被明确的度量标准所度量和操作.不言而喻.软件产品的质量就可以预见和得以控制.(3)组织的度量工程保证所有项目对生产率和质量进行度量,并作为重要的软件过程活功.(4)具有良好定义及一致的度量标服来指导软件过程,并作为评价软件过程及产品的定量基础.(5)在开发组织内已建立软件过程数据库,保存收集到的数据,可用于各项目的软件过程. 过程：(1)开始定量地认识软件过程.(2)软件过程的变化小.一般在可接受的范围内.(3)可以预见软件过程中和产品质量方面的一些趋势.一旦质量经度量后超出这些标准或是有所违反.可以采用一些方法去改正,以达到良好的日标.人员：每个项目中存在强烈的群体工作意识,因为每人都了解个人的作用与组织的关系,因此能够产生这种群体意识. 技术不断的在定量基础上评估新技术.度量：(1)在全组织内进行数据收集与确定.(2)度量标准化.(3)数据用于定量地理解软件过程及稳定软件过程.改进方向：(1)缺陷防范.不仅仅在发现了问题时能及时改进,而且应采取特定行动防止将来出现这类缺陷.(2)主动进行技术变动管理,标识,选择和评价新技术.使有效的新技术能在开发组织中施行,(3)进行过程变动管理.定义过程改进的目的,经常不断地进行过程改进.5,优化级特征：(1)整个组织特别关注软件过程改进的持续性,顶见及增强自身.防止缺陷及问题的发生.不断地提高他们的过程能力.(2)加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程能不断地得到改进,(3)根据软件过程的效果,进行成本/利润分析,从成功的软件过程实践中吸取经验,加以总结.把最好的创新成绩迅速向全组织转移.对失败的案例,由软件过程小组近行分析以找出原因.(4)组织能找出过程的不足并预先改进.把失败的教训告知全体组织以防止重复以前的错误.(5)对软件过程的评价相对标准软件过程的改进,都在全组织内推广.过程：(1)不断地系统地改进软件过程(2)理解并消除产生问题的公共根源.在任何一个系统中都可找到:由于随机变化造成重复工作,进而导致时间浪费.为了防止浪费人力可能导致的系统变化.要消除"公共"的无效根源,防止浪费发生.尽管所有级别都存在这些问题,但这是第五级的焦点.人员：(1)整个组织都存在自觉的强烈的团队意识.(2)每个人都致力于过程改进.人们不再以达到里程碑的成就而满足,而要力求减少错误率. 技术基于定量的控制和管理,事先主动考虑新技术,追求新技术,利用新技术.可以实现软件开发中的方法和新技术的革新,以防止出现错误,不断提高产品的质量和生产率.度量：利用数据来评估,选择过程改进. 改进方向保持持续不断的软件过程改进.二,敏捷开发和高级别CMMI 关键字:高级别CMMI 敏捷开发我经常和别人一起讨论敏捷开发过程的知识,并且我们也会经常争论结合使用敏捷开发过程和CMMI 高级别的话题.他们两个是否能够结合使用?或者他们两个只是向相反的方向发展?带着这个疑问,下面我们一起来探讨. "这个问题可以说是老生常谈,但是我对第 5 级别中的那个基本差异有一个疑问,这个疑问会使人产生不安的情绪.CMMI1.2 强调了想在组织中控制结果的变更, 进而将其重心转移到了个人的身上.敏捷开发在意义上说不单单是为了让每个项目能在应对各种各样的环境中都拥有灵活的能力,并且可以让他们在这个环境中尽其所能表现的最好.我们并没有特别关注在所有项目中要规范行为以便可以预知结果是"可靠的". 但是,我并不清楚我现在尽力想说明的这种区别,是否确实是敏捷开发和CMMI 的基本概念中的一个基础的区别,还是只是组织如何解释和执行CMMI 第 5 级别的一个结果.当然,敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比CMMI 团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的,但是没有假设说明这就是组织要走的路.事实上,敏捷开发支持者偏向于这样的想法, 在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果.是否这就是等同说敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍,以至在组织中试图建立预见性的模型是无用的?" CMMI 第4 级别: QPM(量化项目管理):主要关注懂得过程行为变更的个别项目,他们认为这些变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目标.组织单位(EPG)必须要监控成果. OPP(组织过程实践):主要关注集成模型,项目可以使用模型来规范他们想要达到成功的方面,比如说质量,进度表,预算,维护以及其他任何事情.诀窍就是项目在过程执行中以这些模型为基础,控制QPM 中的行为.比较典型的是,这些模型可能是基于相似的项目中的重复的结果不断建立起来的,虽然可能并没有这样的需求. 在个别项目级别中模型应该先被改进以便使用,所以在CMMI 模型中使用基于一个项目的历史数据(比如说,增量)或者20 个项目的历史数据是没有区别的,虽然这可能对使用者来说是有区别的. CMMI 第5 级别: CAR(原因分析与解决方法):主要关注引起问题的主要原因,过失,管理问题或者其他一切需要解决的问题.项目,EPG 或者其他任何人是否可以应用,是作为解决问题的方法.EPG 在OPP 中监控结果,或者得到别的经验.(敏捷开发是否在增量开始点或者结束点不建议进行类似的行为?我不清楚我所知道的术语是否正确) OID(组织创新与推展):完全非项目特点.关注基于个体,CAR,模型使用,外界因素等的组织改进.你是否会收集并且使用所有这些学到的经验?你进入企业后是否会寻求新的或者更好的做生意的方法(其中敏捷开发可能只是一个例子)?在组织中又该如何处理证明,分析(职业),和使用(结构请参照第 4 级别中的模型和过程控制)这些改进. 我个人认为CMMI 高级别和敏捷开发应该结合起来工作.敏捷可以帮助CMMI 高级别更容易实现短期的转变,并且它在处理事情的发展上起了很重要的作用.我的经验基本是从第5 级别得来的,有部分来自第4 级别.许多组织怀着"每个人都必须如此做"的想法而通过了第3 级别,但是他们却反对在第4,5 级别中有着同样的想法.就像我曾经提到的,敏捷开发是使用CMMI 第4,5 级别来改进如何发展产品的完美例子. CMMI 是Capability Maturity Model Integration(能力成熟度模型集成)的缩写, 是在CMM(Capability Maturity Model 能力成熟度模型)的基础上发展而来三,CMMI 实施现在很多企业因某种原因想做CMMI 了,大体做法1,决定实施CMMI 2,EPG 接受培训,理解CMMI 3,EPG 根据自己理解的CMMI 和实际情况开发一大堆漂漂亮亮的过程文档,流程图,表格,模板,检查单,作业指南. 4,大家边听着EPG 的解释(包括培训,答疑),边执行这些过程标准,然后审计(内,外) 将目前的最佳实践记录下来,写下来,文档化下来. 很多新的EPG 在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员,甚至文档管理员.自己工作大部分时间是面对文档,或者督促别人写文档我到觉得EPG 最主要的工作应该深入到研发第一线,帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度,而不应是单个问题或个人),甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上.总体说来就是掌握项目进展中的任何细微的技术难点要点,并主动记录下来. 为什么这么说呢?CMMI 实施的主要宗旨就是以每个项目为采集数据的源头,达到企业整体效益提升和资源重用.真正有价值的东西,是需要一线人员在实际工作中遇到问题,解决问题,并总结问题,不是一个一线工作的流水帐.就象一份研发人员的日报.写了上午做什么,下午做什么.这对企业的积累有什么用处呢?他工作过程中, 遇到什么问题,他是怎么解决的,走过什么弯路,实验过几种方法,失败了,失败的原因是什么,最后选择了什么方法,可能不是最好的,但完成了任务,达到了效率和资源分配的平衡.这些东西才可能是未来类似项目中,遇到类似问题时,可能有参考价值的.通常也是EPG 个人职业生涯的技术积累.只有公司里每个员工,把自己认为最有价值的积累贡献出来.才可能达到公司有价值的积累.而决不是形式上写的上午下午每个小时的流水帐. 明白了上面的说的CMMI 的目的,做为一个合格的EPG,就应该具备以下的素质: 1,明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做了积累. 2,深入一线,发现她们并忠实地记录她们.CMMI 里的SP,GP,只是帮助你,提醒你在哪个环节,哪些东西可能是有价值了.你去收集一下,别视而不见了.因为还有一个企业和你个人的角度不同,立场不同的问题.例如,REQM 里收集需求,对个人技术方面的积累虽然不多,但对企业是至关重要的,一次需求变更,没详细写清楚, 忘记了到客户那里去签字落实,可能就会给企业造成很大的损失.做为一个合格的EPG,是需要有这份责任和义务把每个环节都做到最好,这是职业道德所在.同时也是对自我延伸的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方式表达.这些也都算是EPG 额外的收获. 通常情况下,为了按时按量完成项目,一线的骨干,对写日报,周报,文档都很不屑.EPG 也很迁就,事后再补,这也不失为一个提高效率的好办法.但过去一个月半年了,我们正常人的记忆都能想象,很难记住细节.无非就是敷衍.这也在情理之中.你总不能让一个明天就要交东西的小组,今天晚上在通宵努力解决BUG 的同时, 还写什么报告,这也不尽人情.但作为EPG 不能只把眼光集中在这妇人之心上.要想的更远.为什么会把项目推到这么晚,BUG 还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素,甚至是开发人员常说的"手气问题","人品问题".但这些是需要控制的,也是通过经验可以控制的,所谓艺高人胆大.艺的高低,就是经验的积累决定的. 那怎么解决这种两难的问题呢?逼着技术骨干写心水,人家没时间也的确压力很大.不写,公司又得不到有效积累,积累的都是垃圾流水.有个公司的办法和经验到可以借鉴一下: 公司内部搞了个BBS,把不同类型的工作分成不同的组,有纯技术的,JAVA 组, C++组等,也有PPT 组,甚至动画组,界面组.大家把自己平时的工作积累FTP 上去,甚至制作方法,遇到问题和解决方法的文档都丢上去,开始怎么想,用了多少套方案,最后选择了什么.自我感觉如何.把这些心路历程都写成文档.丢到阳光下, 大家评论.用点击率和"顶"的人数来说明谁写的是心水,谁在写垃圾.大家都是一个公司的,很容易实名.直接纳入考核机制中.做为一线人员,大家也有动力来写,自己的聪明才智有了展现的平台,虚荣心和荷包都得到了相应的满足.何乐而不为呢? EPG 适时的评估大家的成果,并把他们分到项目里.帮助项目总结,甚至在平时遇到问题时,直接帮助技术人员做必要记录.项目进度松时,再督促项目人员完善内容.以达到对个人和公司积累的最大化. EPG 应该明白学习和积累是个终身的过程,对公司如此,对个人也是如此.CMMI 是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积累.公司需要逐步走向更高的管理水平,发展平台. 四,CMMI 实施之核心关键字:CMMI,SCAMPI,过程改进,能力成熟度,EPG,PA,过程域在上一章节中,我们谈到了关于过程改进团队的组建方法及在组建过程中需要注意的问题,在本节中我们将继续探讨EPG 过程改进的另一个更为重要的一环——定义过程文档. 曾经有一位评估师开玩笑说,三级是写文档,四级是写文档的文档,五级是写文档的文档的文档.由此可见,文档贯穿于整个CMMI,在过程改进中起着举足轻重的作用.那么如何才能写出既符合CMMI 又立足于企业本身实际情况的文档呢?这就是本文将要探讨的问题——定义过程文档. 在定义过程文档时,首先,应该进行企业的习惯表述与CMMI 术语和语言间的映射.特别是组织结构中的一些术语,角色,组织内部之间关系以及过程活动的表述方式都需要映射到其组织的相应部分,以防止别人无法理解. 定义过程文档的一般步骤是: (1)先确定并描述产品的生命周期. 一般来说,产品生命周期可以划分为 6 个阶段,即产品概念阶段,产品定义阶段, 产品开发阶段, 产品测试阶段,用户验收阶段,产品维护阶段. (2)根据产品生命周期的各个阶段确定需要改进的过程域(PA)活动. "过程域"用于描述CMMI 标准定义的软件过程能力评估模型中的一种部件.在该模型中,"过程域"是最大的的构造块,每个"过程域"由一组目标构成,每个目标得到一组实践支持.模型中描述的过程是参考模板,用"过程域"来表示.不能与实际过程混淆."过程域"不是实际的过程,它是模型中的模板. (3)针对某一个PA 过程活动,完成PA 的数据流程图. (4)准备相应的模板,检查表或者方法附件定义过程文档.再在EPG 内部讨论修改,然后拿给评审人员阅读,最后是进行正式评审.进一步修订,再评审直到大家认可为止,再进入下一个PA 过程.(或者也可以评审通过后进行试点,试点成功再进入下有个PA 过程.) 根据自己多年的咨询经验,总结了在定义过程文档时一般容易出现的问题. 1,"本地化做得不够" 咨询顾问常常在项目进行中发现这样的问题:在定义某个PA 过程时,客户会过于依赖咨询公司提供的其他一些企业的过程文档,并将这些文档梢作调整成为其自己的过程文件.由于每个软件企业的情况是不一样,流程,规范,记录应该根据公司实际情况来制定,参照CMMI 框架,制定适合公司本身情况的"本地化"过程体系,这样的效果会更好. (2)总体把握,逐步细化在定义第一个PA 过程时,如果没有考虑它跟其它PA 之间的关系就直接参照CMMI 的此PA 的目标和实践完成了过程文件,可能发生的结果要么是无法通过评审, 要么就是通过了之后再返回进行修改.由于各PA 间关系密切,息息相关,因此在实际的定义过程中,先要从总体上把握住各PA 间关系,完成整个过程的数据流程图的基础上再进行逐步细分,否则即是"只见树木不见森林". (3)多交流,多总结由于在项目初期,EPG 小组对于CMMI 的理解不够透彻,大家也没什么经验,这就需要EPG 成员,QA,管理人员,开发人员之间多多交流,在定义过程文档时多讨论,集众人之智慧,随着过程定义的进展,EPG 小组对CMMI 的理解加深,就需要总结经验,避免将来在遇到类似问题的时候多走弯路.。
基于CMMI的软件质量度量研究
基于CMMI的软件质量度量研究
吴颖
【期刊名称】《现代信息科技》
【年(卷),期】2018(002)006
【摘要】改革开放以来,我国经济水平与科技水平不断提高,计算机及网络技术等现代化信息技术快速发展,为软件的开发利用奠定了坚实基础,在这一背景下,加强软件质量度量研究有助于提高软件产品的质量,开发出更多复杂的软件,具有十分重要的现实价值与参考价值.本文从CMMI理论出发,详细论述了软件度量的基本理论,并论述了C-G模型及其具体应用,希望能以此改进软件过程,提高软件质量的可控性与可测性,进而为软件行业的可持续发展奠定坚实基础.
【总页数】3页(P21-23)
【作者】吴颖
【作者单位】中国移动设计院有限公司重庆分公司,重庆 400023
【正文语种】中文
【中图分类】TP311.52
【相关文献】
1.基于CMMI软件质量管理方法研究 [J], 叶国伟
2.基于CMMI4的软件质量控制活动过程管理研究 [J], 罗毅洁
3.基于DO-178C及CMMI的民用航空发动机控制软件质量保证研究 [J], 阎迪
4.基于CMMI的轻型软件质量保证框架研究 [J], 张建国;董丽丽;曹阳
5.基于CMMI的软件质量度量研究 [J], 吴颖;
因版权原因，仅展示原文概要，查看原文内容请购买。
CMMI的5个级别和25个过程域
CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法，用于评估和提升组织的软件工程能力。
CMMI分为五个不同的成熟度级别，每个级别都有一组相关的过程域。
本文将详细介绍CMMI的五个级别和25个过程域。
1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。
在这个级别上，软件开发过程通常是不可控制的，且无法重复使用。
这意味着项目结果无法预测和控制，导致成本和进度的不确定性。
2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。
在这个级别上，组织已经建立了一些基本的软件开发过程，并能够在不同的项目中重复使用这些过程。
然而，这些过程还没有得到完全的规范和标准化。
2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。
它涉及定义、确认和维护需求，以确保项目能够满足用户的期望。
2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。
它确保项目能够按计划进行，并能够做出合适的调整以达到预期的目标。
2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。
它确保与供应商的交付和管理能够满足项目的需求。
2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。
它涉及质量计划、质量审查和质量度量等活动。
2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项（包括软件、硬件和文档等）的过程。
CMMI软件度量
CMM/CMMI/SPCA-14
产品度量的内容
• 一般常用的软件产品质量度量有：
– – – – 软件可靠性度量 软件复杂度度量 软件缺陷度量 软件规模度量
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-15
度量的范围
• 在进行软件度量活动的项目中，软件度量会涉及 到每个人的工作：
软件度量
2005年4月第2版
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-1
自我介绍
王振宇
• 计算机及应用专业，工商管理硕士 • 研究方向是软件工程、软件过程管理和质量流程控制 • 十年的IT管理和软硬件系统开发的工作经验
• CMMI/SPCA咨询顾问、评估师
– 从需求分析到设计、实现、测试、维护 – 从项目管理者到开发者、测试者、技术支持者、用户 – 从代码实现到各种评审
• 每一个阶段、每一个角色的各种软件活动都会纳 入软件度量活动的范围内
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-16
可以度量个人吗？
指标图分析
• 我们可以观察到第七个点时引入引入的缺陷超过控制上限 ，而其他时间里引入的缺陷保持稳定。通过对该时间活动 的分析，发现这是因为一个未作计划的版本合并，造成引 入缺陷的意外增加。 • 通过研究和对比，我们发现这次开发活动并不令人满意， 其原因是无计划的更改，而不是开发质量的异常波动。
© 2005 CEPREI Certification Body
• 改进－根据得到的量化信息，可以帮助我们识别障碍物、查找问题
的根源，以及能提高产品质量和过程效率的其他方法。与以前的量化 信息比较。可以证实这些方法是否有效。
CMMI-度量数据收集、存储、分析及报告规程
CMMI-度量数据收集、存储、分析及报告规程引言本文档旨在定义并规范组织中度量数据的收集、存储、分析及报告流程，以确保有效的数据管理和决策支持。
通过建立一个良好的数据管理规程，可以提高组织的过程能力和项目管理的效率。
数据收集数据收集目标数据收集的目标是收集项目过程和产品质量方面的数据，以便通过数据分析和报告来提供决策支持和过程改进。
数据收集方法数据可以通过以下方法进行收集：1.自动化系统收集：使用项目管理工具和其他自动化系统，例如版本控制系统、问题跟踪系统等，自动记录项目过程和产品质量相关的数据。
2.人工收集：通过面谈、调查问卷等方式，收集项目参与者和相关利益相关者的意见和反馈。
3.监测和度量：通过监视项目执行过程中的关键指标和度量，收集相应的数据。
数据收集频率数据的收集频率应根据项目的需求和规模进行确定。
对于较大规模的项目，建议进行定期的数据收集，以确保数据的及时性和准确性。
数据收集记录所有收集到的数据都应被记录下来，并进行适当的分类和标识，以便进行后续的分析和报告。
数据存储数据存储目标数据存储的目标是确保收集到的数据可以被安全地保管和管理，并能够方便地被访问和检索。
数据存储方法数据可以通过以下方法进行存储：1.数据库：将数据存储在关系数据库或其他适当的数据库管理系统中，以确保数据的安全和完整性。
2.文件系统：将数据存储在文件系统中，以便进行备份和恢复。
数据存储结构数据存储应根据数据的性质和用途进行合理的划分和组织，以便进行检索和分析。
数据分析数据分析目标数据分析的目标是通过对收集到的数据进行统计和分析，找出数据背后的规律和趋势，并提供有关项目和过程的洞察。
数据分析方法数据可以通过以下方法进行分析：1.统计分析：使用统计方法，例如均值、方差、频率分布等，对数据进行整体和细节的分析。
2.数据可视化：使用图表、图形等可视化方法，将数据以直观、易懂的形式展现。
3.趋势分析：通过对历史数据的分析，预测未来的趋势和发展。
基于CMMI的软件缺陷度量
量化软件缺 陷的管理 ，是把握软件质量 的有效途径之
２ ＣＭＭ Ｉ
２ １Ｃ ． ＭＭＩ 概述
Ｃ ＭＭＩ 与之前提 出的 ＣＭＭ 的明显 区别就是 ，在
Ｃ ＭＭＪ 模型 中 “ 度量和分析（ ） ＭＡ ”己经成为一个独立 的过程域 ， 并且 ＣＭＭＩ 四级的名称改为定量管理级。 第 可见在 ＣＭＭＩ中， 非常强调对软件开发过程的量化管
理。某种程 度上说 ，软件过程度量 的结果是 软件过 程 改进的依据。 度量与分析过程域有两个特定 目标 ，一个是按信
能 力成熟 度模型集成 ＣＭＭＩ 由美国卡 内基． 是 梅
隆大学软件 工程研究所 （Ｅ） ＳＩ 在美 国国防部 的支 持下 ，
于 １９ ８年 开始研究 的项 目。Ｓ Ｉ ２ ０ ９ Ｅ 在 ０ ２年 １月正 式 发布 了 Ｃ ＭＭｌ ． 本。同时宣布 ２ ０ １１版 ０ ３年后停 止 能 力成 熟度模 型 ＣＭＭ 体 系的维 护工作 ，转 为维 护
Ｋ ｅ ｗｏ ｄ ： ｓ ｆｗａ ｅｄ ｆ ｃ ； ｏ ｔ ａ ｅｄ ｆ Ｃ ｅ ｓ ｅ ｅ ｔ ＣＭ Ｍ Ｉ ｍｅ ｓ ｒ ｍ ｅ ｔ ｄａ ａｙ ｉ ｙ ｒ ｓ ｏ ｔ ｒ ｅｅ ｔ ｓ ｆｗ ｒ ｅ ｅ ｔ ｍ ａｕ ｍ ｎ； ｒ ； ａ ｕ ｅ ｎ ｎ ｌ ｓｓ ｎ ａ
１ 引言
Ｓｏ ｔ ｒ ￣ｃ ｓＭ ｅ ｓ ｅ ｅ ｔＢａ ｅ ｎ ｆｗａ ｅＤｅ ｔ ａ ｕｒ ｍ ｎ ｓ ｄ ｏ ＣＭ Ｍ Ｉ
ＱＩ ａ — ｉｇ ＹＥＦ ｎ Ｕ Ｗ ｎＱ ｎ ， ｅ ｇ
（ ｏｌｇ ｆ ｕｉｅｓ ｄ ｎｓ ａｉｎ Ｚ ｅｉ ｇＵ ｉｅｓ ｙｏ ｅ ｈ ｏｏ ｙ Ｈ ｎ ｚ ｏ ０ ３ Ｃ ｉａ Ｃ ｌ ｅ ｓ ｓ ｍｉｉ ｒｔ ， ｈｊ ｎ ｎｖｒｉ ｆ ｃ ｎ ｌｇ ， ａ ｇ ｈ ｕ３ ０ ２ ， ｈｎ ） ｅ ｏＢ ｎ Ｋ ｔ ｏ ａ ｔ Ｔ １
CMMI5文档之度量与分析过程
度量与分析过程文档编号：FHI_CMMI_MA_PRS文档信息：度量与分析过程文档名称：度量与分析过程文档类别：CMMI过程密级：内部秘密版本信息：1.1建立日期：2016-1-19创建人：EPG批准人：李庆林批准日期：2016-2-25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录目录1.简介 (4)1.1.目的 (4)1.2.适用范围 (4)1.3.引用文件 (4)1.4.术语表 (4)1.5.角色与职责 (4)1.6.参考资料 (4)2.工作过程概述 (4)2.1.过程概述 (4)2.2.过程结构描述 (5)3.工作过程描述 (5)3.1.定义度量与分析规格说明 (5)3.2.实施项目度量与分析活动，并提供相应的结果 (7)3.3.实施公司度量与分析活动，并提供相应的结果 (7)4.支持文件 (10)1.简介1.1.目的开发和维持软件过程的度量能力，以便支持商业目标和管理信息的需要。
1.2.适用范围项目和公司度量与分析工作。
1.3.引用文件●《项目策划过程》1.4.术语表测量（Measure）：是对一个项目或过程的某个特性（例如：规模、工作量、复杂性和缺陷）采度量（Measurement）：是对一个项目或过程具有的某个特性的度的一个测量。
例如：对产品规分析（Analysis）：是整理、比较和解析度量结果并形成报告的行为。
例如：对产品规模与工作1.5.角色与职责●Goal-Driven Software Measurement–A Guidebook [SEI-HB02]2.工作过程概述2.1.过程概述度量与分析过程的功能是从各种工程和管理过程中收集和分析度量数据并为相关的干系人报告度量结果，提供用于监控和改进项目过程和产品质量的管理信息。
度量与分析过程包括下列活动：●定义度量与分析规格说明；●实施项目度量与分析活动，并提供相应的结果；●实施公司度量与分析活动，并提供相应的结果；2.2.过程结构描述3.工作过程描述3.1.定义度量与分析规格说明3.1.1.概述度量分析人员采用“目标-问题-度量（Goal-Question-Metric，GQM）”的软件度量方法，建立和维护项目和公司的度量数据收集、分析、存储和报告方法。
CMMI与软件质量管理
CMMI与软件质量管理概述CMMI（能力成熟度模型集成）是一种用于评估和改进软件开发过程的国际标准。
软件质量管理是一种通过实施标准化过程来确保软件产品质量的方法。
本文将探讨CMMI与软件质量管理之间的关系，以及它们在软件开发项目中的应用。
CMMI简介CMMI是一种用于评估和改进软件开发过程的模型。
它由Carnegie Mellon大学的软件工程研究所开发，并于2002年发布。
CMMI使用了一种成熟度模型的方法，用于评估组织的软件开发能力，并提出了一套指导原则和最佳实践，以改进组织的软件开发过程。
CMMI模型定义了5个不同的成熟度级别，从初级（级别1）到最高级别（级别5）。
每个级别都有一系列的指导原则和最佳实践，用于帮助组织实现更高水平的成熟度。
通过实施CMMI模型，组织可以提高软件开发过程的效率和质量，减少成本和风险。
软件质量管理软件质量管理是通过实施标准化的过程和活动，确保软件产品的质量和符合客户要求的方法。
它涵盖了整个软件开发生命周期，包括需求分析、设计、编码、测试和维护等阶段。
软件质量管理的目标是确保软件产品的可靠性、可用性、易用性和安全性等方面的质量，以满足客户的需求和期望。
软件质量管理包括以下主要方面：质量计划质量计划是指确定实施软件质量管理活动的计划和策略。
它包括确定质量目标、质量度量指标、质量评估方法等内容。
质量计划可以帮助组织确保软件产品在项目的每个阶段都符合预定的质量标准。
质量控制质量控制是指通过监控和评估软件开发过程中的活动和工件，确保产品质量符合预期的过程。
它包括编码规范的制定、代码审查、单元测试、集成测试等控制措施。
质量控制可以及早发现和纠正潜在的质量问题，从而确保软件产品的质量。
质量保证质量保证是指通过实施预防性和检测性的活动，确保软件产品质量符合预期的过程。
它包括需求审查、设计审查、测试计划制定和执行等活动。
质量保证可以帮助组织确保软件产品符合质量标准，预防质量问题的发生。
cmmi中的度量项
CMMI中的度量项是指用于度量和评估组织软件工程过程的特定指标或测量，可以帮助组织了解和改进其软件工程过程，并提供有关项目和组织绩效的定量数据。
度量项的名称、目的、度量标准和度量方法在定义时需要明确，以便在组织内共享和理解。
例如，对于度量软件项目的进度，可以使用“项目进度度量”作为度量项的名称。
在CMMI模型中，可以包括以下方面的度量项：产品质量度量目标：衡量项目开发的产品质量，包括关键质量特性、缺陷率、可靠性等。
进度度量目标：衡量项目的进度，包括计划进度、实际进度、延期等。
成本度量目标：衡量项目的成本，包括预算、实际成本、投入资源等。
风险度量目标：衡量项目的风险管理。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-2
学员自我介绍
• • • • • • 姓名 职务 从事的工作 对度量和CMM/CMMI的了解 期望 3分钟之内
© 2005 CEPREI Certification Body
0.831
CMM/CMMI/SPCA-23
理解
• 没有通用的组织模型，对于不同的组织和软件类型，过程模 型不一样。 • 如BOEHN对NASA的一个实验室的项目进行度量，得到嵌 入式软件工作量和持续时间与代码规模的关系为：
– 工作量（人月） ＝ 2.8× KSLOC 0.33 – 开发周期（月） ＝ 2.5 × KSLOC
0.31
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-24
预测
• 通过理解过程、产品各要素之间的关系建立模型，由已知的 要素推算、估计其他要素，以便合理分配资源、合理制定计 划。 • 以上面的项目为例，在对一个项目的规模度量中预测综合代 码量为102K，则可以预测：
度量的重要性
• 度量活动可以对我们的软件开发项目状态和产品 质量给予量化的表示，为加强和改进研发工作提 供详细的指导 • CMM将度量作为公共特性，是过程改进制度化的 基础 • CMMI更加强调了度量，二级有一个过程域度量和 分析
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-21
• 改进－根据得到的量化信息，可以帮助我们识别障碍物、查找问题
的根源，以及能提高产品质量和过程效率的其他方法。与以前的量化 信息比较。可以证实这些方法是否有效。
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-22
理解
• 获得对过程、产品、资源、环境的理解，确定以后预测的机 箱和模型。这是评估、预测、改进活动的基础。 • 例如：代码规模、工作量、开发周期、文档页数、平均团队 大小、产品缺陷总数、遗留缺陷数存在一定关系，NASA某 项目统计如下：
CMM/CMMI/SPCA-26
改进
• 根据得到的量化信息，可以帮助我们识别障碍物、查找问题的根源，以及能提 高产品质量和过程效率的其他方法。 • 与以前的量化信息比较，可以证实这些方法是否有效。 ： • 上面所举的NASA的CLEANROOM方法是一个例子；同样，以NASA项目中独 立测试组织对改进产品质量的有效性的度量结果为例： 版本发布后遗留缺陷率 20％ 16% 测试成本 每千行1.4人月 每千行2.5人月
产品度量
• 是对项目开发成果－最终产品的度量。一般来说 ，我们提到产品度量，指的是对产品的质量度量 。
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-12
过程度量与项目度量
• 过程度量与项目度量的区别是： • 过程度量是战略性的，针对组织范围内进行，是 组织内大量项目实践的总结和模型化，对于项目 度量提供指导意义； • 而项目度量是战术性的，针对具体的项目进行， 预测、评估、改进项目工作，产品度量是对产品 质量的度量，用于对产品质量的评估和预测。
软件度量
2005年4月第2版
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-1
自我介绍
王振宇
• 计算机及应用专业，工商管理硕士 • 研究方向是软件工程、软件过程管理和质量流程控制 • 十年的IT管理和软硬件系统开发的工作经验
• CMMI/SPCA咨询顾问、评估师
CMM/CMMI/SPCA-25
评估
• • • • • 分析活动与计划的符合程度，确定是否有偏差，以便控制其执行； 评估最终产品的质量； 评估新技术的影响； 评估过程改进对过程和产品的影响。 如NASA研究改进软件开发方法，准备引入CLEANROOM方法，以求提 高生产力，提高产品质量。在对该方法进行了三个项目的试点，发现与 传统方法的对比是：
– – – – – 工作量（人月） ＝ 1.48× 102 = 138人月 0.33 开发周期（月） ＝ 4.6 × 102 = 15月 0.75 平均团队大小 = 0.24 × 工作量 = 9人 产品缺陷总数＝ 7.5× 102 = 765个 遗留缺陷数＝ 0.5× 102 ＝ 51个
0.831
© 2005 CEPREI Certification Body
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-18
度量的关键成功因素
• • • • • • • • • 确定度量目标和计划； 获得高层管理者的支持； 拥有专属资源； 面向员工的培训、教育和营销推广； 日常工作中的度量一体化； 聚焦于项目团队的结果； 度量不要针对个人； 有效定义数据以及实情报告制度； 推动度量自动化。
什么是度量
• 度量：
– 根据一定的规则，将数字或符号赋与系统、构件、过 程等实体的特定属性，从而使我们能够清晰地理解该 实体及其属性，简而言之，度量就是对事物属性地量 化表示。
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-5
指标
• 指标：
– 软件度量活动地结果不一定能够直接应用。 – 举例：对引入的缺陷数据按时间进行收集，得到一个数字系列，如：
– 工作量（人月） ＝ 1.48× KSLOC 0.33 – 开发周期（月） ＝ 4.6 × KSLOC 0.505 – 文档页数 = 34.7 × KSLOC 0.75 – 平均团队大小 = 0.24 × 工作量 – 产品缺陷总数＝ 7.5× KSLOC – 遗留缺陷数＝ 0.5× KSLOC 其中KSLOC ： 千行源程序
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-10
项目度量
• 对于软件开发项目的特定度量，目的是评估项目 开发过程的质量，预测项目进度、工作量等，辅 助管理者进行质量控制和项目控制
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-11
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-13
项目度量的内容
• 一般常用的项目度量有：
– – – – – – 规模度量 工作量度量 进度度量 生产力度量 风险度量 项目动态度量（如：需求变更、代码动态增长等）
© 2005 CEPREI Certification Body
• “正好用这个度量结果来评价下属的工作绩效。 ”
• “软件度量会评价我的绩效吗？”
• “我提供的数据会不会用来作为评价我的依据？ ”
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-17
度量从不用于评价个人
• 度量从不用于评价个人。度量既不用于评价个人的能力， 也不用于评价个人的绩效。度量只用于对过程、项目、产 品的理解、分析、评估、预测和改进工作。 • 原因：为了保持数据的可靠性、客观性和准确性我们必须 保证度量结果不用于评价数据提供者个人的工作绩效和质 量。 • 在度量活动中将使用特别的步骤保证分析报告不被用于评 价个人绩效和质量
CMM/CMMI/SPCA-14
产品度量的内容
• 一般常用的软件产品质量度量有：
– – – – 软件可靠性度量 软件复杂度度量 软件缺陷度量 软件规模度量
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-15
度量的范围
• 在进行软件度量活动的项目中，软件度量会涉及 到每个人的工作：
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-3
课程目的
• • • • • 了解度量的含义 掌握度量的必要性 度量对工作的影响 度量活动的步骤和指南 度量的陷阱
© 2005 CEPREI Certification Body
CMM/CMMI/SPCA-4
生产力
传统方法 CLEANROOM 每天26行综合代码
质量
每千行综合代码5.3个错误
每天40行综合代码 每千行综合代码4.3个错误 • 对CLEANROOM方法进行评估，则可以得出结论：
– 如果不考虑其他因素，CLEANROOM开发方法确实可以提高生产力，降低错误率。
© 2005 CEPREI Certification Body
指标图分析
• 我们可以观察到第七个点时引入引入的缺陷超过控制上限 ，而其他时间里引入的缺陷保持稳定。通过对该时间活动 的分析，发现这是因为一个未作计划的版本合并，造成引 入缺陷的意外增加。 • 通过研究和对比，我们发现这次开发活动并不令人满意， 其原因是无计划的更改，而不是开发质量的异常波动。
© 2005 Байду номын сангаасEPREI Certification Body
日期 缺陷
1 0 2 1 3 3 4 4 5 2 6 3 7 9 8 2 9 1 10 5 11 4 12 5 13 2 14 4 15 3 16 3 17 2 18 1 19 4 20 2 21 3 22 4 23 5 24 1
– 对于这个结果，简单的看这组数据，很难分析出过程特征。为便于分析 和理解，我们用指标来表示度量活动的结果，它是对于一个度量结果或 多个度量结果的组合，并采用一些易于理解的形式，使我们对于过程、 系统、项目、产品有更深入的理解。