1、软件质量保证和管理,- Ch.6 软件质量度量,第6章 软件质量度量,6.1 测量基础 6.2 软件度量 6.3 软件质量度量方法 6.4 软件产品的质量度量 6.5 软件过程质量度量 6.6 软件质量度量的执行,6.1 质量基础,3个基本概念 测量（Measurement）是对产品过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示； 度量（Metric）是对软件产品进行范围广泛的测度，它给出一个系统、构件或过 程的某个给定属性的度的定量测量； 指标 (Indicator) 是一个度量或一组度量的组合，采用易于理解的形式,对软件过程、项目或产品质量提供更全面、深入的评价和了解，以利
2、于过程和质量的分析,6.1 质量基础,6.1.1 测量原理 6.1.2 测量标准 6.1.3测量过程和原则,6.1.1 测量原理,测量原理示意图,6.1.1 测量原理-度量尺度,分类尺度（Nomnal scale） 某个指标被分成一系列的类别。如产品质量属性有：功能性、适用性、性能、安全性、可靠性、可维护性等。 序列尺度（Ordinal scale 分类的序列，即在分类的基础上，再加以排序。如用1、2、3、4、5表示用户的满意度，1满意度最低，5满意度最高。也可以用某中线为基准的相对百分比来表示程度。 间隔尺度（Interval scale） 通过数值来表示两个邻近测量点之间的差异，但没有绝对
3、的“零”值。 比值尺度（Ratio Scale） 和间隔尺度相似，但有绝对的“零”值存在。,6.1.2 测量标准,有效性和可靠性是测量标准中最重要的指标 。 有效性指的是测量的结果正是反映了被测试对象的实际状况和程度、或合乎事务的发展、变化的规律我们所需要的测量。可靠性指的是使用同样的测量方法对同样的事物进行多次测量，得到值的一致性。多次测量的值越接近，可靠性就越高；反之则可靠性越低。,可靠但不有效 有效但不可靠 可靠且有效,6.1.3 测量过程和原则,识别目标和度量描述,定义度量过程,搜集数据,数据分析与反馈,过程改进,测量过程,6.1.3 测量过程和原则,基本的测量原则： 测量应该基于该应
4、用领域正确的理论之上，并在测量的定义中确定测度的目标； 每一个技术测量的定义应该具有一致性和客观性、无二义性； 测量在经验和直觉上也应该有说服力； 测量的方法力求简单、可计算性； 测量应该被剪裁以最适应特定的产品和过程，而且任何时候应尽可能使得收集和分析自动化； 应该用正确的统计技术来建立内部产品属性和外部待测量特征的关系； 测量结果应该是可靠的，不会因为一些技术问题导致测量结果很大的偏离。 测量应该建立反馈机制,6.2软件度量,6.2.1 软件开发生命周期的度量活动 6.2.2 软件的项目度量 6.2.3 软件产品的规模度量 6.2.4 代码行度量方法 6.2.5 功能点分析法 6.2.6
5、面向对象软件的对象点方法,6.2.1 软件开发生命周期的度量活动,软件产品度量：主要用来描述软件产品的特征，用于产品评估和决策。产品度量包括软件规模大小、产品复杂度、设计特征、性能以及质量水平。本书主要讨论产品的质量度量，测量产品的各个质量指标并最终对产品整体质量做出合理的评估。软件项目度量：用来描述项目的特性和执行状态，如项目计划的有效性、项目资源使用效率、成本效益、项目风险、进度和生产力等。目的是评估项目开发过程的质量、预测项目进度、工作量等，辅助管理者进行质量控制和项目控制。软件过程度量：用于软件开发、维护过程的优化和改进，如开发过程中的缺陷移除效率、测试阶段中的缺陷到达模式以及缺陷修复
6、过程的效率等。对于软件过程本身的度量，目的是形成适合软件组织应有的各种模型，作为对项目、产品的度量基础；以及对软件开发过程进行持续改进，提高软件生产力。,6.2.1 软件开发生命周期的度量活动,软件开发生命周期中的测量活动,规模度量 (size measurement)：以代码行数、功能点数、对象点或特征点等来衡量。软件规模度量是工作量度量、进度度量的基础，用于估算软件项目工作量、编制成本预算、策划项目进度的基础。复杂度度量(complexity measurement)：确定程序控制流或软件系统结构的复杂程度指标。复杂度度量用于估计或预测软件产品的可测试性、可靠性和可维护性，以便选择最优化、
7、最可靠的程序设计方法，来确定测试策略、维护策略等。缺陷度量(defect measurement)：帮助确定产品缺陷分布的情况、缺陷变化的状态等，从而帮助分析修复缺陷所需的工作量、设计和编程中存在哪些弱点、预测产品发布时间、预测产品的遗留缺陷等。,工作量度量(workload measurement)：任务分解并结合人力资源水平来度量，合理地分配研发资源和人力，获得最高的效率比。工作量度量是在软件规模度量和生产率度量的基础上进行。进度度量(schedule measurement)：通过任务分解、工作量度量、有效资源分配等做出计划，然后将实际结果和计划值进行对比来度量。风险度量(risk me
8、asurement)：一般通过两个参数“风险发生的概率”和“风险发生后所带来的损失”来评估风险。其他的项目度量，如需求稳定性或需求稳定因子（RSI,Requirement Stability Index）、资源利用效率(Resource Utilization)、文档复审水平（Review level）、问题解决能力（Issue-resolving ability）、代码动态增长等。,6.2.2 软件的项目度量,6.2.3 软件产品的规模度量,1.德尔菲法 德尔菲法(Delphi technique)是一种专家评估技术，适用于在没有或没有足够的历史数据情况下，来评定软件采用不同的技术、新技术所
9、带来的差异，但专家的水平及对项目的理解程度是工作中的关键点。 2. COCOMO模型 造性成本模型(COCOMO：constructive cost model)是一种精确、易于使用的基于模型的成本估算方法 。它有分为基本COCOMO模型 ，中间COCOMO模型和详细COCOMO模型 3. 代码行度量方法 4. 功能点分析法 5. 面向对象软件的对象点方法,6.2.4 代码行度量方法,6.2.5 功能点分析法,6.2.6 面向对象软件的对象点方法,6.3 软件质量度量方法,6.3.1软件质量度量的分类 6.3.2 软件质量度量模型 6.3.3基于时间的缺陷到达模式 6.3.4 PTR累积模型
10、6.3.5 Rayleigh模型,6.3.1软件质量度量的分类,6.2.1已经介绍了相关内容 这里是否就不用介绍了？,微软公司的缺陷到达模式,6.3.3基于时间的缺陷到达模式,缺陷达到模式的理想趋势图,在测试阶段初期，缺陷率增长很快。,在达到峰值后，就随时间以较慢的速率下降，降低到最低点零点,6.3.3基于时间的缺陷到达模式,不同的缺陷统计方法：1）一定时间内的总缺陷数； 2）一定时间内的严重程度前两个等级的缺陷数之和； 3）一定时间内的新引进的缺陷及回归的缺陷之和； 4）一定时间内的新引进的缺陷及回归的缺陷，而且严重程度在前两个等级的缺陷之和。,6.3.3 PTR累积模型,PTR累积模型,6
11、.3.5 Rayleigh模型,软件项目过程的Rayleigh模型形状,6.4 软件产品的质量度量,6.4.1 软件复杂性的度量 6.4.2 软件缺陷度量 6.4.3 顾客满意度度量,6.4.1 软件复杂性的度量,McCabe环形计算复杂度 复杂度计算公式为： M = V(G) = e n + 2p 其中： V(G) 路径图的环形数目 e = 边的数目 n = 节点数目 p = 图中没有连接部分的数目,6.4.1 软件复杂性的度量,语法构造方法 基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。语法构造方法可以揭示程序中单独的语
12、法构造和缺陷率之间的关系： 缺陷率= 0.15 + 0.23 DO WHILE + 0.22 SELECT + 0.07 IF-THEN-ELSE,6.4.1 软件复杂性的度量,结构度量方法 Henry给出的复杂性定义： Cp = ( 扇入 扇出)2 其中： 扇入 调用外部模块的模块数 扇出 被外部模块调用的次数,Card/Glass给出的度量模型： Ct = St + Dt其中： St 结构（模块间)复杂性 Dt 数据（模块间)复杂性,6.4.2 软件缺陷度量,缺陷密度软件缺陷在规模上的分布 如：每KLOC或每个功能点（或类似功能点的度量对象点、数据点、特征点等）的缺陷数 缺陷率缺陷在时间上
13、的分布 如：对应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来 。整体缺陷清除率 在软件开发过程中发现的所有缺陷数 /发现的总缺陷数 阶段性缺陷清除率,6.4.3 顾客满意度度量,软件组织的顾客满意度要素及其内容,6.4.3 顾客满意度度量,软件项目的顾客满意度要素及其内容,6.5 软件过程质量度量,6.5.1 软件需求过程的质量度量 6.5.2 软件过程生产率的度量 6.5.3 测试阶段的过程质量度量 6.5.4 维护阶段的过程质量度量,6.5.1 软件需求过程的质量度量,需求一致性度量 Q1 nui /nr nui是所有复审者都有相同解释的需求数目 nr是需求说明书中需求的个
14、数，包含功能和非功能需求需求完整性度量 Q2 nu /(ni ns) nu是唯一功能需求的数目 ni是由需求规格定义或包含的输入的个数 ns是被表示的状态的个数。 需求确认程度度量 Q3nc /(ncnnv) nc 是已经确认为正确的需求的个数 nnv是尚未被确认的需求的个数,6.5.1 软件需求过程的质量度量,需求稳定性度量 需求稳定性度量是通过需求稳定因子RSI 来表示：RSI = （所有确定的需求数 - 累计的需求变化请求数）/所有确定的需求数 所有确定的需求数 = 初始需求请求列表数 + 接受的需求变化请求数,6.5.2 软件过程生产率的度量,软件生产率的三维关系,6.5.2 软件过程
15、生产率的度量,度量量 代码行 功能点 类 测试用例 度量单位 人时（man-hour） 人日（man-day） 人月（man-month） 人年（man-year）,6.5.3 测试阶段的过程质量度量,测试用例的深度（TCD, Test Case Depth） - 每KLOC的测试用例数 - 每个功能点/对象点的测试用例数测试用例的有效性 - 每100或1000个测试用例所发现的缺陷数测试用例的质量（TCQ, Test Case Quality） - 测试用例发现的缺陷数量/总的缺陷数量,6.5.3 测试阶段的过程质量度量,测试执行的效率和质量 - 每个人日所执行的测试用例数 - 每个人日所发
16、现的缺陷数 - 每修改的KLOC所运行的测试用例数 缺陷报告的质量 - 报告的质量不高的缺陷数/报告的总缺陷数 质量不高的缺陷包含： 1）状态为“需要补充信息”的缺陷 2）状态为“不是缺陷”的缺陷,6.5.3 测试阶段的过程质量度量,基于需求的测试覆盖 - 已执行的测试覆盖 TxRft - 成功的测试覆盖 TsRft Tx表示已执行的测试过程数或测试用例数 Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数 Rft是测试需求的总数 基于代码的测试覆盖 - 已执行的测试覆盖 TcTnc Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数 Tnc（Total
17、number of items in the code）是代码中的项目总数,6.5.4 维护阶段的过程质量度量,平均失效时间MTTF (mean time to failure) 基于时间缺陷 (或用户问题数) 的到达率 积压缺陷管理指标 (BMI) 软件成熟度指标 (SMI),6.6 软件质量度量的执行,6.6.1 度量专家的思想和指导 6.6.2 软件度量的应用 6.6.3 选择和确定质量因素 6.6.4 质量度量中的数据采集 6.6.5 质量度量的统计分析,6.6.1 度量专家的思想和指导,关于如何开展度量活动，不少专家给出了非常有价值的指导，如：软件度量专家Van Solingen 提
18、出的“软件度量的十大方针”Scott Goldfarb 提出的“建立并实施有效软件度量体系的关键成功因素”美国卡内基梅隆大学SEI 列出的软件度量的规则Robert E. Park和William A.Florac等提出的软件度量和过程度量原则请参考这些专家的相关论著。,6.6.2 软件度量的应用,1)度量的目的是改进开发过程，提高产品质量 2)塑造度量文化 3)软件度量只针对项目、产品和过程而开展 4)从小规模的简单的度量项目开始 5)度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善 6)根据项目实情加以具体实施 7)通过数据共享增进信任，消除软件度量可能带来的误解 8) 度量
19、应该简单易懂，从而降低沟通和实施成本,6.6.3 选择和确定质量因素,软件质量要素/指标：正确性可靠性效率完整性可用性可维护性,可测试性灵活性可移植性重复性互用性,6.6.4 质量度量中的数据采集,需要遵循的4个标准,真实性,同步性,一致性,有效性,6.6.5 质量度量的统计分析,质量度量的统计方法包含以下步骤：1) 收集和分类软件缺陷信息； 2) 找出导致每个缺陷的原因(例如，不符合规格说明书、设计错误、代码错误、数据处理不对、对客户需求误解、违背标准、界面不友好等)； 3) 使用Pareto规则(80缺陷主要是由20的主要因素造成的，20缺陷是由另外80的次要因素造成的)，要将这20的主要因素分离出来。 4) 一旦标出少数的主要因素，就比较容易纠正引起缺陷的问题。,6.6.5 质量度量的统计分析,错误的根本原因来源于下面几个方面：说明不完整或说明错误(IES) 与客户交流不够所产生的误解(MCC) 故意与说明偏离(IDS) 违反编程标准(VPS) 数据表示有错(EDR) 模块接口不一致(IMI) 设计逻辑有错(EDL) 不完整或错误的测试(IET) 不准确或不完整的文档(IID) 将设计翻译成程序设计语言中的错误(PLT) 不清晰或不一致的人机界面(HCI) 杂项(MIS),6.6.5 质量度量的统计分析,质量度量的统计数据收集,作业,第6章 2、3、7,Q & A,
