SQE-Ch.7 软件质量度量ppt课件_第1页
SQE-Ch.7 软件质量度量ppt课件_第2页
SQE-Ch.7 软件质量度量ppt课件_第3页
SQE-Ch.7 软件质量度量ppt课件_第4页
SQE-Ch.7 软件质量度量ppt课件_第5页
已阅读5页,还剩36页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、12.1 软件开发生命周期的度量活动 2.2 软件的项目度量 2.3 软件产品的规模度量 2.4 代码行度量方法2.5 功能点分析法2.6 面向对象软件的度量2软件产品度量:主要用来描述软件产品的特征,用于产品评估和决策。产品度量包括软件规模大小、产品复杂度、设计特征、性能以及质量水平。本书主要讨论产品的质量度量,测量产品的各个质量指标并最终对产品整体质量做出合理的评估。软件项目度量:用来描述项目的特性和执行状态,如项目计划的有效性、项目资源使用效率、成本效益、项目风险、进度和生产力等。目的是评估项目开发过程的质量、预测项目进度、工作量等,辅助管理者进行质量控制和项目控制。软件过程度量:用于软

2、件开发、维护过程的优化和改进,如开发过程中的缺陷移除效率、测试阶段中的缺陷到达模式以及缺陷修复过程的效率等。对于软件过程本身的度量,目的是形成适合软件组织应有的各种模型,作为对项目、产品的度量基础;以及对软件开发过程进行持续改进,提高软件生产力。3软件开发生命周期中的测量活动软件开发生命周期中的测量活动 4规模度量 (size measurement):以代码行数、功能点数、对象点或特征点等来衡量。软件规模度量是工作量度量、进度度量的基础,用于估算软件项目工作量、编制成本预算、策划项目进度的基础。复杂度度量(complexity measurement):确定程序控制流或软件系统结构的复杂程度

3、指标。复杂度度量用于估计或预测软件产品的可测试性、可靠性和可维护性,以便选择最优化、最可靠的程序设计方法,来确定测试策略、维护策略等。缺陷度量(defect measurement):帮助确定产品缺陷分布的情况、缺陷变化的状态等,从而帮助分析修复缺陷所需的工作量、设计和编程中存在哪些弱点、预测产品发布时间、预测产品的遗留缺陷等。工作量度量工作量度量(workload measurement):任务分解并结合人力资源:任务分解并结合人力资源水平来度量,合理地分配研发资源和人力,获得最高的效率比。水平来度量,合理地分配研发资源和人力,获得最高的效率比。工作量度量是在软件规模度量和生产率度量的基础上

4、进行。工作量度量是在软件规模度量和生产率度量的基础上进行。进度度量进度度量(schedule measurement):通过任务分解、工作量度量、:通过任务分解、工作量度量、有效资源分配等做出计划,然后将实际结果和计划值进行对比来有效资源分配等做出计划,然后将实际结果和计划值进行对比来度量。度量。风险度量风险度量(risk measurement):一般通过两个参数:一般通过两个参数“风险发生的风险发生的概率概率”和和“风险发生后所带来的损失风险发生后所带来的损失”来评估风险。来评估风险。其他的项目度量,如需求稳定性或需求稳定因子其他的项目度量,如需求稳定性或需求稳定因子(RSI,Requir

5、ement Stability Index)、资源利用效率)、资源利用效率(Resource Utilization)、文档复审水平(、文档复审水平(Review level)、问题)、问题解决能力(解决能力(Issue-resolving ability)、代码动态增长等。)、代码动态增长等。51.德尔菲法 德尔菲法(Delphi technique)是一种专家评估技术,适用于在没有或没有足够的历史数据情况下,来评定软件采用不同的技术、新技术所带来的差异,但专家的水平及对项目的理解程度是工作中的关键点。 2. COCOMO模型建造成本模型(COCOMO:constructive cost m

6、odel)是一种精确、易于使用的基于模型的成本估算方法 。它有分为基本COCOMO模型 ,中间COCOMO模型和详细COCOMO模型3. 代码行度量方法4. 功能点分析法5. 面向对象软件的对象点方法67891.1.每个类的加权方法每个类的加权方法(WMC-weighted methods per class)假定对类假定对类C定义了复杂度为定义了复杂度为c1,c2,cn的的n个方法,所选择的特定个方法,所选择的特定的复杂性度量应该规范化,使得对某方法的名义上的复杂性取值的复杂性度量应该规范化,使得对某方法的名义上的复杂性取值1.0。WMC=ci2.继承树的深度继承树的深度(DIT-Depth

7、ofInheritanceTree)3.子女的数量子女的数量(NOC-NumberofimmediateChildrenofaclass)4.对象类之间的耦合对象类之间的耦合(CBO-CouplingBetweenObjects)一个类的CBO是它与别的类有耦合耦合关系的类的数目,属于系统层次级的度量。CBO值越小,表明该类影响到的类越少,独立性越强,修改所涉及的类也越少,维护的代价越小。5.对类的响应对类的响应(RFC-ResponseforaClass):类的RFC越大,该类的测试和调试将越 复杂,复杂度越大6.方法中缺少内聚方法中缺少内聚(LCOM-LackofCohesioninMet

8、hods):10LorenzLorenz和和KiddKidd建议的度量建议的度量11MOODMOOD度量套件度量套件1213耦合因子(耦合因子(CFCF):):CF=CF=i ij jis_clientis_client(C(Ci i,C,Cj j)/(TC)/(TC-TC)-TC) 14多态因子(多态因子(PF):重新定义被继承方法的方法数量,):重新定义被继承方法的方法数量,除以可能的不同多态情形的最大数量除以可能的不同多态情形的最大数量.这样,这样,PF是是对系统中的动态绑定相对数量的间接测量。对系统中的动态绑定相对数量的间接测量。PF=iMo(Ci)/iMn(Ci)*DC(Ci)这里对

9、这里对i从从1到到TC求和。且求和。且Md(Ci)=Mn(Ci)+Mo(Ci)其中,其中,Mn(Ci)为新方法的数量,为新方法的数量,Mo(Ci)为覆写方法的为覆写方法的数量,数量,DC(Ci)为后代计数(某基类的后代类的数量)为后代计数(某基类的后代类的数量)15面向操作的度量面向操作的度量平均操作大小(平均操作大小(OSOSavgavg): :可以用操作发送的消息的数量可以用操作发送的消息的数量作为对操作大小的一种度量。作为对操作大小的一种度量。操作复杂度(操作复杂度(OCOC):可使用针对传统软件提出的任何):可使用针对传统软件提出的任何复杂度度量来计算。应保持复杂度度量来计算。应保持O

10、COC尽可能低。尽可能低。每个操作的平均参数的数量(每个操作的平均参数的数量(NPNPavgavg):操作参数的数):操作参数的数量越大,对象间的协作越复杂。量越大,对象间的协作越复杂。NPNPavgavg应保持尽可能低应保持尽可能低。16封装封装在方法中内聚性的缺乏(在方法中内聚性的缺乏(LCOMLCOM):):LCOMLCOM值越高,必须值越高,必须被被 测试的状态越多,以保证方法不产生副作用。测试的状态越多,以保证方法不产生副作用。公共和保护属性的百分比(公共和保护属性的百分比(PAPPAP):):PAPPAP的高值增加了类的高值增加了类 间副作用的可能性。间副作用的可能性。对数据成员的

11、公共访问(对数据成员的公共访问(PADPAD):):PADPAD的高值导致了类间的高值导致了类间 副作用的潜在可能。副作用的潜在可能。17继承继承根类的数量(根类的数量(NORNOR):):NORNOR增加时,测试工作量也增加;增加时,测试工作量也增加;扇入(扇入(FINFIN):):OOOO语境中,语境中,FINFIN是多继承的指标,是多继承的指标,FIN1FIN1 指明类从多于一个的根类继承属性和操作。指明类从多于一个的根类继承属性和操作。FIN1FIN1应尽应尽 量避免。量避免。子女数子女数(NOC)和继承树的深度和继承树的深度(DIT):超类的方法必须:超类的方法必须针对每个子类被测试

12、。针对每个子类被测试。183.1基于时间的缺陷到达模式- S曲线模型3.2 PTR累积模型19微软公司的缺陷到达模式微软公司的缺陷到达模式 缺陷达到模式的理想趋势图缺陷达到模式的理想趋势图 在测试阶段初期,缺陷率增长很快。在达到峰值后,就随时间以较慢的速率下降,降低到最低点零点 20不同的缺陷统计方法:1)一定时间内的总缺陷数;2)一定时间内的严重程度前两个等级的缺陷数之和;3)一定时间内的新引进的缺陷及回归的缺陷之和;4)一定时间内的新引进的缺陷及回归的缺陷,而且严重程度在前两个等级的缺陷之和。21PTR累积模型累积模型224.1 软件复杂性的度量4.2 软件缺陷度量 4.3 顾客满意度度量

13、 23 语法构造方法 基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大,程序结构就越复杂。 语法构造方法可以揭示程序中单独的语法构造和缺陷率之间的关系:缺陷率= 0.15 + 0.23 DO WHILE + 0.22 SELECT + 0.07 IF-THEN-ELSE24结构度量方法 Henry给出的复杂性定义:Cp = ( 扇入 扇出)2其中:扇入 调用外部模块的模块数扇出 被外部模块调用的次数25 缺陷密度软件缺陷在规模上的分布如:每KLOC或每个功能点(或类似功能点的度量对象点、数据点、特征点等)的缺陷数 缺陷率缺陷在时间上的分布如:从应

14、用软件的角度来说,90%以上的缺陷是在发布后两年内被发现出来 。 整体缺陷清除率在软件开发过程中发现的被清除的所有缺陷数 / /发现的总缺陷数 阶段性缺陷清除率产品中潜伏的缺陷数开发阶段清除的缺陷数10026顾客满意度要素顾客满意度要素顾客满意度要素的内容顾客满意度要素的内容技术解决方案质量、可靠性、有效性、易用性、价格、安装、新技术支持与维护灵活性、易达性、产品知识市场营销解决方案、接触点、信息管理购买流程、请求手续、保证期限、注意事项交付准时、准确、交付后过程企业形象技术领导、财务稳定性、执行印象软件组织的顾客满意度要素及其内容软件组织的顾客满意度要素及其内容 27顾客满意度要素顾客满意度

15、要素顾客满意度度量内容顾客满意度度量内容软件产品功能性、可靠性、易用性、效率性、可维护性、可移植性开发文档文档的构成、质量、外观、图表以及索引、用语项目进度以及交期交期的根据、进度迟延情况下的应对、进展报告技术水平项目组的技术水平、项目组的提案能力、项目组的问题解决能力沟通能力事件记录、格式确认、问题解答运用维护支持、问题发生时的应对速度、问题解决能力软件项目的顾客满意度要素及其内容软件项目的顾客满意度要素及其内容 285.1软件需求过程的质量度量5.2软件过程生产率的度量5.3 测试阶段的过程质量度量5.4 维护阶段的过程质量度量29需求一致性度量Q1 Q1 n nuiui /n /nr r

16、n nuiui是所有复审者都有相同解释的需求数目n nr r是需求说明书中需求的个数,包含功能和非功能需求需求完整性度量Q2 Q2 n nu u /(n/(ni i n ns s) ) n nu u是唯一功能需求的数目n ni i是由需求规格定义或包含的输入的个数n ns s是被表示的状态的个数。 需求确认程度度量Q3Q3n nc c /(n/(nc cnnvnv) ) n nc c是已经确认为正确的需求的个数nnvnv是尚未被确认的需求的个数 30需求稳定性度量需求稳定性度量是通过需求稳定因子RSI 来表示:RSI = (所有确定的需求数 - 累计的需求变化请求数)/所有确定的需求数 所有确

17、定的需求数 = 初始需求请求列表数 + 接受的需求变化请求数 31软件生产率的三维关系软件生产率的三维关系32度量量 代码行 功能点 类 测试用例度量单位 人时(man-hour) 人日(man-day) 人月(man-month) 人年(man-year)33测试用例的深度(TCD, Test Case Depth)- - 每每KLOCKLOC的测试用例数的测试用例数- - 每个功能点每个功能点/ /对象点的测试用例数对象点的测试用例数测试用例的有效性- - 每每100100或或10001000个测试用例所发现的缺陷数个测试用例所发现的缺陷数测试用例的质量(TCQ, Test Case Qu

18、ality) - - 测试用例发现的缺陷数量测试用例发现的缺陷数量/ /总的缺陷数量总的缺陷数量 34测试执行的效率和质量 - - 每个人日所执行的测试用例数每个人日所执行的测试用例数 - - 每个人日所发现的缺陷数每个人日所发现的缺陷数 - - 每修改的每修改的KLOCKLOC所运行的测试用例数所运行的测试用例数 缺陷报告的质量 - - 报告的质量不高的缺陷数报告的质量不高的缺陷数/ /报告的总缺陷数报告的总缺陷数质量不高的缺陷包含:1)状态为“需要补充信息”的缺陷2)状态为“不是缺陷”的缺陷35基于需求的测试覆盖- - 已执行的测试覆盖已执行的测试覆盖 TxTxRft Rft - - 成功

19、的测试覆盖成功的测试覆盖 TsTsRftRft Tx表示已执行的测试过程数或测试用例数 Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数 Rft是测试需求的总数 基于代码的测试覆盖- - 已执行的测试覆盖已执行的测试覆盖 TcTcTncTnc Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数 Tnc(Total number of items in the code)是代码中的项目总数 36平均失效时间MTTF (mean time to failure)基于时间缺陷 (或用户问题数) 的到达率软件成熟度指标 (SMI)37质量度量的统计方法包含以下步

20、骤:1) 收集和分类软件缺陷信息;2) 找出导致每个缺陷的原因(例如,不符合规格说明书、设计错误、代码错误、数据处理不对、对客户需求误解、违背标准、界面不友好等);3) 使用Pareto规则(80缺陷主要是由20的主要因素造成的,20缺陷是由另外80的次要因素造成的),要将这20的主要因素分离出来。4) 一旦标出少数的主要因素,就比较容易纠正引起缺陷的问题。38错误的根本原因来源于下面几个方面:说明不完整或说明错误(IES)与客户交流不够所产生的误解(MCC)故意与说明偏离(IDS)违反编程标准(VPS)数据表示有错(EDR)模块接口不一致(IMI)设计逻辑有错(EDL)不完整或错误的测试(I

21、ET)不准确或不完整的文档(IID)将设计翻译成程序设计语言中的错误(PLT)不清晰或不一致的人机界面(HCI)杂项(MIS)39质量度量的统计数据收集质量度量的统计数据收集总计总计(Ei)严重严重(Si)一般一般(Mi)微小微小(Ti)错误错误数量数量百分比百分比数量数量百分比百分比数量数量百分比百分比数量数量百分比百分比IES29622.3%5528.2%9518.6%14623.4%MCC20415.3%189.2%8717.0%9915.9%IDS644.8%21.0%311%315.0%VPS342.6%10.5%193.7%142.2%EDR18213.7%3819.5%9017.

22、6%548.7%IMI822%147.2%214.1%477.5%EDL644.8%2010.3%173.3%274.3%IET14010.5%178.7%5110.0%7211.6%IID544.1%31.5%285.5%233.7%PLT875%2211.3%265.1%393%HCI423.2%42.1%275.3%111.8%MIS811%10.5%203.9%609.6%总计1330100%195100%512100%623100%40PMDPMDLicense:License:Open SourceCurrent version:Current version:5.0.2 (rel

23、eased 03.02.2013)URL:URL:PMD is a source code analyzer. It finds unused variables, empty catch blocks, unnecessary object creation, and so forth.”PMD is used for detecting bad practices in code, which is intended decrease the number of bugs in your code. The theory is that conforming to good practices in coding leads to better code, which we definitely agree with. With tag

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论