CMMI软件度量
© 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
– 对于这个结果，简单的看这组数据，很难分析出过程特征。为便于分析 和理解，我们用指标来表示度量活动的结果，它是对于一个度量结果或 多个度量结果的组合，并采用一些易于理解的形式，使我们对于过程、 系统、项目、产品有更深入的理解。
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）进度度量单位用于衡量软件项目和过程的进展和时间安排。
典型的进度度量单位包括工作量、里程碑完成情况、任务完成率等。
通过对进度的度量，可以及时发现项目进展的偏差，并采取相应措施进行管理和调整。