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

第2章软件生命周期质量度量目录2.1概述2.2需求分析模型的度量2.3设计模型的度量2.4源代码度量2.5对测试的度量2.6对维护的度量2.7本章小结重点了解软件生命周期中各个阶段度量的重要性了解每个阶段度量的原理和主要的度量计算方法难点了解每个阶段度量的原理和主要的度量计算方法度量测量在科学领域有悠久的历史[116]。相对早在1889年就定义好了度量单位～米的长度测量，温度的度量复杂的多Fahrenheit和Celsius分别在1714年和1742年提出了基于某固定点间隔递增等级的温度度量方法。Celsius将100度和0度之间分为100个等份2.1概述软件的质量由一系列质量要素组成，每个质量要素又由一些衡量标准组成，每个衡量标准又由一些度量标准加以定量刻画质量度量（softwaremeasurement）贯穿于软件工程的全过程以及软件交付前后，在软件交付之前的度量主要包括程序复杂性、模块的有效性、总的程序规模，在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性方面软件度量研究主要分为两个阵营：一部分认为软件可以度量，一部分认为软件无法通过度量分析。无论如何，研究主流是关心软件的品质和认为软件需要定量化度量。目前有超过上千种软件度量方法被软件研究人员及从业人员提出，并且到今天有超过5000份论文出版发表。软件度量的重要性如果没有度量，我们很难想象关于电子、机械、及普通工程的定律能得到发展。但事实上现在在软件工程的主流里度量却被忽略了。现状当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护；而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语（如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等）向潜在的用户说明产品的可靠性很高。我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发现状事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话：“软件的费用有80％花费在维护上。”或“软件每一千行程序中平均有55个Bugs。”。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。因此，归因于度量不充分的问题的产生是由于缺乏严格的度量方法造成的软件质量度量目的软件度量是对软件开发项目、过程及其产品进行数据定义，收集及分析的持续性定量化过程目的在于对此加以理解、预测、评估、控制和改善通过软件度量，可以改进软件开发过程，促进项目成功，开发高质量的软件产品度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标2.1.1度量的原则度量应该基于该应用领域正确的理论之上，并在度量的定义中确定测量的目标每一个技术度量的定义应该具有一致性、客观性、无二义性，任何度量的第三方对其度量的理解是相同的。度量在经验和直觉上也应该有说服力度量应该被剪裁使之适应特定的产品和过程，而且任何时候应该尽可能的使得收集和分析自动化应该使用正确的统计技术来建立内部产品属性和外部带度量特征的关系度量结果是可靠的2.1.2软件开发生命周期的度量活动一方面要遵守一般度量的标准和原则另一方面软件度量很少借助意见设备和仪器测量，更多的借助一些软件的方法——软件工具、数理统计的方法和自身特定的方法并不是所有的度量都对软件工程有实际意义有些度量太复杂有些太深奥被人们经常使用的软件度量并不是很多，可以分为产品度量、过程度量、项目度量3大类产品度量主要用来描述软件产品的特征,用于产品评估和决策包括软件规模大小产品复杂度设计特征性能质量水平项目度量用来描述项目的特性和执行状态如项目计划的有效性、项目资源使用效率、成本效益、项目风险进度和生产力评估项目开发过程的质量预测项目的进度、工作量辅助管理者进行质量控制和项目控制过程度量用于软件开发、维护过程的优化和改进，如开发过程中的缺陷移除效率、测试阶段中的缺陷到达模式以及缺陷修复过程的效率三种度量活动的比较过程度量是战略性的项目度量是战术性的产品度量是对产品质量的度量，用于对产品质量的评估和预测软件度量的实施过程度量承诺度量计划度量实施度量评估度量改善2.2需求分析的度量软件工程的技术性工作开始于需求分析，所以对这个阶段进行度量是很重要的2.2.1基于功能的度量功能点度量可以用来作为预测从分析模型得到系统大小的手段举例：safahome软件，该功能管理用户交互，接收一个用户密码来启动和关闭系统，并且允许对安全区状态和不同安全传感器进行查询SafaHome分析模型的一部分SafeHomeUserInteractionfunctionUserSensorsUserMonitoring&responsesubsystemSystemconfigurationdataPasswordZoneinquirySensorinquiryPanicbuttonActivate/deactivateTestsensorZonesettingMessagesSensorstatusActivate/deactivateAlarmalertPassword，sensors用户的输入数用户输出数用户查询数文件数外部接口书2.2.2规约质量的度量需求的功能性有下列的特征确定性（无二义性），完全性，正确性，可理解性，可验证性，内部和外部一致性，可完成性，简洁性，可跟踪性，可修改性，精确性，可复用性以上的特性看起来都是定性的，无法度量，但是Davis等人建议每一个质量特性用一个到多个度量来表示需求的一致性的度量Q1=n(ui)/n(r)n(ui)是无二义性的需求总数n(r)是需求总数n(r)=n(f)+n(nf)n(f)表示功能性需求的数目，n(nf)为非功能性需求的数目需求稳定性的度量软件的需求，肯定是一次无法确定的，变化是必然的，但是变化又会引起后面的各个阶段的变化，所以需求稳定性度量是关键的度量之一RSI=（所有确定的需求数-累计的需求变化请求数）/所有确定的需求数

N3R=初始需求请求列表数+接受的需求变化请求数而接受的需求变化请求数是累计的需求变化请求数与待定的需求变化请求数之差，是动态的，越到后面，需求越趋于稳定RSI越大，需求越稳定，其值越接近于12.4源代码度量最简单的度量程序复杂性的方法就是：统计源代码的行数前提：程序复杂性随着程序规模的增加不均衡地增长； 控制程序规模的方法最好是采用分而治之的方法，将大程序分解成若干个简单的可理解的程序段出错率：每100行源程序中可能有的错误数目，如1%Thayer指出，程序出错率的估算范围是0.04%~7%之间，并且每行代码的出错率与源代码行数之间不是简单的线性关系小于100行的程序，出错率为1.3%~1.8%，是线性的大于100行的大程序，出错率增加到2.7%~3.2%，出错率以非线性的方式增长2.4.1Halstead度量法Halstead的软件科学理论是“最著名的赫研究最完全的（软件）复杂度的复合度量之一”代码长度N的公式P43代码的体积V公式P43McCabe度量法McCabe是一种基于程序控制流的复杂性度量方法，又称为环路复杂度，是基于程序模块的程序图中环路的个数V(G)=m-n+2m是图G中的有向弧个数；n是图G中的节点个数A开始BC输入DEFGH输入JK输出L结束当分支或循环的数目增加时，程序中的环路也随之增加，因此这种度量值为软件测试的难易程序提供了一个度量度量的方法，同时也间接的表示了软件的可靠性说明环路复杂度与程序中覆盖的路径条数有关环路复杂度是可累加的复杂度超过10的程序，建议分成几个小程序2.5对测试的度量测试广度：是指在某一个时刻测量提供的需求有多少已经被测试，它用来度量测试计划的执行、测试进度等状态测试深度：对被测试覆盖的独立基本路径占程序中的基本路径的总数的百分比的策略，可用McCabe环形来计算过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等测试阶段主要过程质量度量缺陷度量或缺陷分布度量测试用例的深度、质量、覆盖率和有效性测试执行的效率和质量缺陷报告的质量测试覆盖率测试环境的稳定性或有效性测试用例的深度、质量和有效性测试用例的度量包含测试用例的深度、质量、有效性和自动化程度的度量测试用例的深度（TestCaseDepth)可以表示为每千行代码（kloc）的测试用例数或每个功能点/对象点的测试用例数测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量不同阶段是不一样的，测试用例的质量（TestCaseQuality）TCQ=测试用例发现的缺陷数量/总的缺陷数量问题：为什么测试发现的缺陷数量不等于宗的缺陷数量？因为有一部分缺陷是通过其他手段和阶段发现的，比如压力测试，还有软件发布后还是会发现缺陷测试执行的效率和质量测试执行的质量=软件发布后遗留的缺陷/总的缺陷数一般要求小于0.5%测试执行的效率可以用如下的方法来综合度量

·每个人日所执行的测试用例数

·每个人日所发现的缺陷数

·每修改KLOC所运行的测试用例数缺陷报告的质量缺陷报告的有效性：所有修正或关闭缺陷和测试人员所报的所有缺陷的比值，越接近1，有效性就越高，正常值在0.92~0.96缺陷报告的质量： 处于中间状态的缺陷数/总的缺陷数 中间状态指的是：需要补充信息 一般占总缺陷数的3%~5%为正常太高说明缺陷报告质量太低太低说明测试人员缺乏怀疑精神2.6对维护的度量在完成一个软件产品的开发并将它发布到市场上，它就进入了维护阶段在这个阶段，按时间区间的缺陷出现数和按时间区间的顾客问题召回数都是事实量缺陷数或问题的出现数是由开发过程决定的在维护阶段对产品质量的改变作用不大软件系统失效严重性度量目的：如何对顾客经受的麻烦或损害的严重性使用权重或维护人员所需资源的范围使用权重软件系统失效的平均严重性AverageSeverityofSoftwareSystemFailure，ASSSF指一年或半年或一个季度内检测到的软件失效数ASSSF=WYF/NYFWYF指一年内的危害服务期内检测到的软件失效的加权数NYF指一年内的维护服务期内检测到的软件失效数软件系统失效的密度度量SSFD=NYF/KLMCWSSFD=WYF/KLMCWSSFF=(NYF+WYF)/NMFPKLMC指被维护软件的千行代码数NMFP是指维护软件的功能点数软件系统可用性度量完全可用FA=（NYSerH-NYFH）/NYSerH