第2章 软件生命周期质量度量

2.4.1 Halstead度量法
• Halstead的软件科学理论是“最著名的赫研 究最完全的（软件）复杂度的复合度量之 一” • 代码长度N的公式P43 • 代码的体积V公式P43
McCabe度量法
• McCabe是一种基于程序控制流的复杂性度 量方法，又称为环路复杂度，是基于程序 模块的程序图中环路的个数 • V(G)=m-n+2 m是图G中的有向弧个数；n是图G中的节点 个数
难点
• 了解每个阶段度量的原理和主要的度量计 算方法
度量
• 测量在科学领域有悠久的历史[116]。相对 早在1889年就定义好了度量单位～米的长 度测量，温度的度量复杂的多 • Fahrenheit和Celsius分别在1714年和1742 年提出了基于某固定点间隔递增等级的温 度度量方法。Celsius将100度和0度之间分 为100个等份
过程度量
• 用于软件开发、维护过程的优化和改进， 如开发过程中的缺陷移除效率、测试阶段 中的缺陷到达模式以及缺陷修复过程的效 率
三种度量活动的比较
• 过程度量是战略性的 • 项目度量是战术性的 • 产品度量是对产品质量的度量，用于对产 品质量的评估和预测
软件度量的实施过程
• • • • • 度量承诺 度量计划 度量实施 度量评估 度量改善
产品度量
• 主要用来描述软件产品的特征,用于产品评 估和决策 • 包括软件规模大小 • 产品复杂度 • 设计特征 • 性能 • 质量水平
项目度量
• 用来描述项目的特性和执行状态 • 如项目计划的有效性、项目资源使用效率、 成本效益、项目风险进度和生产力 • 评估项目开发过程的质量 • 预测项目的进度、工作量 • 辅助管理者进行质量控制和项目控制
测试阶段主要过程质量度量
• • • • • • 缺陷度量或缺陷分布度量 测试用例的深度、质量、覆盖率和有效性 测试执行的效率和质量 缺陷报告的质量 测试覆盖率 测试环境的稳定性或有效性
测试用例的深度、质量和有效性
• 测试用例的度量包含测试用例的深度、质 量、有效性和自动化程度的度量
测试用例的深度（Test Case Depth)
2.1.1 度量的原则
• 度量应该基于该应用领域正确的理论之上，并在 度量的定义中确定测量的目标 • 每一个技术度量的定义应该具有一致性、客观性、 无二义性，任何度量的第三方对其度量的理解是 相同的。 • 度量在经验和直觉上也应该有说服力 • 度量应该被剪裁使之适应特定的产品和过程，而 且任何时候应该尽可能的使得收集和分析自动化 • 应该使用正确的统计技术来建立内部产品属性和 外部带度量特征的关系 • 度量结果是可靠的
User
Password，sensors System configuration data
• • • • •
用户的输入数 用户输出数 用户查询数 文件数 外部接口书
2.2.2 规约质量的度量
• 需求的功能性有下列的特征 确定性（无二义性），完全性，正确性， 可理解性，可验证性，内部和外部一致性， 可完成性，简洁性，可跟踪性，可修改性， 精确性，可复用性 • 以上的特性看起来都是定性的，无法度量， 但是Davis等人建议每一个质量特性用一个 到多个度量来表示
• 软件度量研究主要分为两个阵营：一部分 认为软件可以度量，一部分认为软件无法 通过度量分析。 • 无论如何，研究主流是关心软件的品质和 认为软件需要定量化度量。 • 目前有超过上千种软件度量方法被软件研 究人员及从业人员提出，并且到今天有超 过5000份论文出版发表。
软件度量的重要性
• 如果没有度量，我们很难想象关于电子、 机械、及普通工程的定律能得到发展。但 事实上现在在软件工程的主流里度量却被 忽略了。
2.5 对测试的度量
• 测试广度：是指在某一个时刻测量提供的 需求有多少已经被测试，它用来度量测试 计划的执行、测试进度等状态 • 测试深度：对被测试覆盖的独立基本路径 占程序中的基本路径的总数的百分比的策 略，可用McCabe环形来计算 • 过程中收集的缺陷数度量，发现的、修正 的和关闭的缺陷数量在过程中的差异、发 展趋势等
2.2 需求分析的度量
• 软件工程的技术性工作开始于需求分析， 所以对这个阶段进行度量是很重要的
2.2.1 基于功能的度量
• 功能点度量可以用来作为预测从分析模型 得到系统大小的手段 • 举例：safahome软件，该功能管理用户交 互，接收一个用户密码来启动和关闭系统， 并且允许对安全区状态和不同安全传感器 进行查询
2.6 对维护的度量
• 在完成一个软件产品的开发并将它发布到 市场上，它就进入了维护阶段 • 在这个阶段，按时间区间的缺陷出现数和 按时间区间的顾客问题召回数都是事实量 • 缺陷数或问题的出现数是由开发过程决定 的 • 在维护阶段对产品质量的改变作用不大
软件系统失效严重性度量
• 目的：如何对顾客经受的麻烦或损害的严 重性使用权重或维护人员所需资源的范围 使用权重
缺陷报告的质量
• 缺陷报告的有效性：所有修正或关闭缺陷 和测试人员所报的所有缺陷的比值，越接 近1，有效性就越高，正常值在0.92~0.96 • 缺陷报告的质量： 处于中间状态的缺陷数/总的缺陷数 中间状态指的是：需要补充信息 一般占总缺陷数的3%~5%为正常 太高说明缺陷报告质量太低 太低说明测试人员缺乏怀疑精神
第2章 软件生命周期质量度量
目录
• • • • • • • 2.1 概述 2.2 需求分析模型的度量 2.3 设计模型的度量 2.4 源代码度量 2.5 对测试的度量 2.6 对维护的度量 2.7 本章小结
重点
• 了解软件生命周期中各个阶段度量的重要 性 • 了解每个阶段度量的原理和主要的度量计 算方法
• 因为有一部分缺陷是通过其他手段和阶段 发现的，比如压力测试，还有软件发布后 还是会发现ห้องสมุดไป่ตู้陷
测试执行的效率和质量
• 测试执行的质量=软件发布后遗留的缺陷/总 的缺陷数 • 一般要求小于0.5% • 测试执行的效率可以用如下的方法来综合 度量 ·每个人日所执行的测试用例数 ·每个人日所发现的缺陷数 ·每修改KLOC所运行的测试用例数
• 可以表示为每千行代码（kloc）的测试用例 数或每个功能点/对象点的测试用例数 • 测试用例的效率可以用每100或1000个测试 用例所发现的缺陷数来衡量 • 不同阶段是不一样的， • 测试用例的质量（Test Case Quality） TCQ=测试用例发现的缺陷数量/总的缺陷数量 问题：为什么测试发现的缺陷数量不等于宗的 缺陷数量？
2.1 概述
• 软件的质量由一系列质量要素组成，每个 质量要素又由一些衡量标准组成，每个衡 量标准又由一些度量标准加以定量刻画 • 质量度量（software measurement）贯穿 于软件工程的全过程以及软件交付前后， • 在软件交付之前的度量主要包括程序复杂 性、模块的有效性、总的程序规模， • 在软件交付之后的度量则主要包括残存的 缺陷数和系统的可维护性方面
软件系统失效的平均严重性
• Average Severity of Software System Failure，ASSSF • 指一年或半年或一个季度内检测到的软件 失效数 ASSSF=WYF/NYF WYF指一年内的危害服务期内检测到的软件 失效的加权数 NYF指一年内的维护服务期内检测到的软件 失效数
2.4 源代码度量
• 最简单的度量程序复杂性的方法就是：统 计源代码的行数 • 前提：程序复杂性随着程序规模的增加不 均衡地增长； 控制程序规模的方法最好是采用分 而治之的方法，将大程序分解成若干个简 单的可理解的程序段
• 出错率：每100行源程序中可能有的错误数 目，如1% • Thayer指出，程序出错率的估算范围是 0.04%~7%之间，并且每行代码的出错率与 源代码行数之间不是简单的线性关系 • 小于100行的程序，出错率为1.3%~1.8%， 是线性的 • 大于100行的大程序，出错率增加到 2.7%~3.2%，出错率以非线性的方式增长
需求的一致性的度量
• • • • Q1=n(ui)/n(r) n(ui)是无二义性的需求总数 n(r)是需求总数 n(r)=n(f)+n(nf) n(f)表示功能性需求的数 目，n(nf)为非功能性需求的数目
需求稳定性的度量
• 软件的需求，肯定是一次无法确定的，变化是必然 的，但是变化又会引起后面的各个阶段的变化，所 以需求稳定性度量是关键的度量之一 • RSI=（所有确定的需求数-累计的需求变化请求数） /所有确定的需求数 N3R=初始需求请求列表数+接受的需求变化请求数 而接受的需求变化请求数是累计的需求变化请求数与 待定的需求变化请求数之差，是动态的，越到后面， 需求越趋于稳定 • RSI越大，需求越稳定，其值越接近于1
现状
• 当我们在设计和开发软件产品的时候，我们并未能制定出 度量的目标。例如：我们保证说我们将使用户界面友好、 可靠、易于维护；而并未使用度量的术语来详细说明它们 的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没 有明确目标的项目将不能明确地达到它的目标。 • 我们未能对构成软件项目实际费用的各个不同的部分进行 有效的度量。譬如：通常我们并不知道，和测试阶段相比， 设计阶段花费时间多大。 • 我们并未试图使我们开发的产品的各种质量合格。因此我 们未能使用术语（如：在一段时间里使用故障的可能性、 把产品安装到新环境中需花费的工作量等）向潜在的用户 说明产品的可靠性很高。 • 我们总是试图说服自己使用另一种新的革新的开发技术和 方法进行软件开发
A开始
B
C输入
D
K输出
E
L结束 J
F G H输入
• 当分支或循环的数目增加时，程序中的环 路也随之增加，因此这种度量值为软件测 试的难易程序提供了一个度量度量的方法， 同时也间接的表示了软件的可靠性
说明
• 环路复杂度与程序中覆盖的路径条数有关 • 环路复杂度是可累加的 • 复杂度超过10的程序，建议分成几个小程 序
SafaHome分析模型的一部分
Sensors Password Zone inquiry SafeHome Sensor inquiry User Interaction Panic button function Activate/deactivate Test sensor Zone setting Messages Sensor status Activate/deactivate Alarm alert Monitoring& response subsystem User
现状
• 事实上，我们在软件度量方面做的工作很少很少， 而且所作的度量方面的工作也与一般科学意义上 的度量相分离。 • 我们经常会看到诸如此类的话：“软件的费用有 80％花费在维护上。”或“软件每一千行程序中 平均有55个Bugs。”。但是这些话并没有告诉我 们这样的结果是怎样产生的、试验是怎样设计、 执行的、度量的是那个实体、及错误的框架是什 么等等。 • 因此，归因于度量不充分的问题的产生是由于缺 乏严格的度量方法造成的
软件质量度量目的
• 软件度量是对软件开发项目、过程及其产 品进行数据定义，收集及分析的持续性定 量化过程 • 目的在于对此加以理解、预测、评估、控 制和改善 • 通过软件度量，可以改进软件开发过程， 促进项目成功，开发高质量的软件产品
• 度量取向是软件开发诸多事项的横断面， 包括顾客满意度度量、质量度量、项目度 量、以及品牌资产度量、知识产权价值度 量 • 度量取向要依靠事实、数据、原理、法则； 其方法是测试、审核、调查；其工具是统 计、图表、数字、模型；其标准是量化的 指标
2.1.2 软件开发生命周期的度量活动
• 一方面要遵守一般度量的标准和原则 • 另一方面软件度量很少借助意见设备和仪 器测量，更多的借助一些软件的方法—— 软件工具、数理统计的方法和自身特定的 方法
• 并不是所有的度量都对软件工程有实际意 义 • 有些度量太复杂 • 有些太深奥 • 被人们经常使用的软件度量并不是很多， 可以分为产品度量、过程度量、项目度量3 大类