软件质量度量.ppt

《软件质量度量.ppt》由会员分享，可在线阅读，更多相关《软件质量度量.ppt（46页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件质量度量一、产品质量度量n1、缺陷密度度量n2、顾客问题度量n3、顾客满意度度量产品质量度量n软件质量的实际定义n平均无失效时间（mean time to failure,MTTF）n缺陷密度n顾客问题n顾客满意度n应用范围nMTTF交通管制、航空电子学、武器系统n缺陷密度（率）商业软件系统1.缺陷密度（率）度量n缺陷率-软件大小n通常千行源代码数（KLOC）n功能点例子：KLOCnKLOC-物理行计数？指令语句计数？是否加数据定义？注解？首次发布与更新版本后n当更新版本后：n更改标记法nLOC重新计数n缺陷跟踪使用更改标记法（change flagging）例子：功能点n一个应用程序5个

2、主要成分的加权总和n外部输入数（例如，事务类型）36n外部输出数（例如，报告类型）47n逻辑内部文件数 715n外部接口文件数 510n外部查询数（支持的联机查询种类）36例子：功能点n第一步nWij是5个成分按复杂性级别的加权因子，Xij是应用程序中每种成分的数目例子：功能点n14个特征：n数据通信n分布式功能n性能n频繁使用的配置n事务率n联机数据项、n最终用户效率n联机更新n复杂处理n可重用性n易安装性n易操作性n多站点n易更改性例子：功能点n第二步n将这些特征分值（从0到5）按下列公式加起来，形成价值调整因子（value adjustment factor,VAF）n其中Ci是通用系统

3、特征i的分值例子：功能点n最后，得到了功能点数nFP=FC*VAFn已成为一个关键的生产率测度n主要应用于应用软件而非系统软件2、顾客问题度量n来自顾客的视角n缺陷性问题（缺陷率度量）n非缺陷性问题（使用性问题、不明确的文档或者信息、有据缺陷的重复出现）n采用PUM(problems per user month)表示PUM=一个时段内的顾客报告的问题总数/在此期间软件许可证月总数许可证月总数=软件的安装许可证数*计算时段中的月数2、顾客问题度量n降低PUM措施n改进开发过程，减少产品缺陷n通过改进产品的所有方面（实用性及文档）、顾客教育和支持减少非缺陷性问题n增加产品销量（安装许可证数）缺陷

4、率度量和顾客问题度量比较缺陷/KLOCPUM分子有据且不同的产品缺陷数所有顾客问题（缺陷性和非缺陷性，首次的和重复的）分母产品大小（KLOC）产品的顾客使用（用户一月数）测量角度生产者-软件开发机构顾客作用范围内在产品质量内在产品质量加上其他因素3.顾客满意度度量n5级尺度n非常满意n满意n一般n不满意n非常不满意3.顾客满意度度量n5级尺度基础上，构造几种度量n完全满意顾客百分数n满意顾客百分数（满意和完全满意）n不满意顾客百分数（不满意和完全不满意）n非满意顾客百分数（一般、不满意和完全不满意）n通常使用第二个度量，某些时候为降低非满意百分数，也使用第4个度量n也可使用加权指数法二、过程中

5、质量度量n1、机器测试期间的缺陷密度n2、机器测试期间的缺陷出现模式n3、基于阶段的缺陷排除模式n4、缺陷排除有效性1、机器测试期间的缺陷密度n正式机器测试（将代码集成到系统库之后的测试）期间的缺陷率，通常同现场得到的缺陷率正相关n正相关：在测试中发现的缺陷越多，以后发现的缺陷也越多2、机器测试期间的缺陷出现模式n测试期间的总缺陷率是一个简明指示器，而失效间隔则能给出更多信息。n测试期间缺陷出现模式n测试期间按时间间隔出现的缺陷数，原始数据，不一定有效n有效缺陷出现的模式-当报告的问题得到确定时n缺陷超时累积模式：开发机构不能立即审查和修补所有报告的问题。若开发周期结束时缺陷累积仍然大，则需要

6、回归测试才能保证系统稳定性和确保产品质量等级3、基于阶段的缺陷排除模式n除测试外，还需跟踪开发周期所有阶段中的缺陷，包括设计评审、代码审查、测试前的正式验证nIBM开发项目的缺陷排除模式表明将缺陷排除的重点放在前期则质量要好n缺陷排除的各个阶段：高层设计评审（I0）,底层设计评审(I1)、代码审查(I2)、单元测试(UT)、部件测试(CT)、系统测试(ST)4、缺陷排除有效性n缺陷排除有效性（DRE）定义：DRE=开发阶段排除的缺陷数/产品中潜伏的缺陷数n分母估计：在现阶段排出的缺陷数+以后发现的缺陷数n该度量值越高，开发过程越有效三、软件维护的度量n1、修补积累和积累管理指数n2、修补响应时

7、间n3、逾期修补百分数n4、修补质量1、修补积累和积累管理指数nBMI=当月解决问题数/当月出现问题数nBMI100，累积问题减少了nBMI100，累积问题增加2、修补响应时间n修补方针建立在时间限上n按照缺陷可能引起的风险的严重程度分级，越严重越需要昼夜不停的修补问题3、逾期修补百分数n对每个修补而言，如果修补所需时间超过了按严重性的响应时间标准，它就被分类到逾期修补n逾期修补百分数=超过按严重性等级的修补时间标准的修补数/指定时间内交付的修补总数n只针对于已经解决的问题n若某一星期做了重大改进（减少了积累问题），则将产生一个高的逾期指数4、修补质量n一个修补是有缺陷的：没有修补报告的问题或

8、者修补了原有问题同时又注入了新的缺陷n将会严重影响顾客满意度n两种记录方式：发现它的月份或是按交付修补的月份记录n维护过程的质量目标应当为无逾期的、零有缺陷修补。四、度量程序的例子n1、摩托罗拉n2、IBM Rochester1、摩托罗拉n摩托罗拉的软件开发质量政策（QPSD）n目标n1、改进项目计划制定n2、提高缺陷遏制能力n3、提高软件可靠性n4、降低软件缺陷密度n5、改进顾客服务n6、降低不符合性的费用n7、提高软件生产率1、摩托罗拉n摩托罗拉的软件开发质量政策（QPSD）n测量领域n交付缺陷数和按标准大小的交付缺陷数n全过程的总有效性n遵循进度n估计准确性n未解决顾客问题数n问题持续未

9、解决的时间n不符合性的费用n软件可靠性1、摩托罗拉n目标1：改进项目计划制定n问题1.1：估计项目进度实际值的准确度是多少？n度量1.1：进度估计准确度（Schedule Estimation Accuracy,SEA）nSEA=实际项目持续时间/估计项目持续时间n问题1.2：估计项目工作量实际值的准确度是多少？n度量1.2：工作量估计准确度（Effort Estimation Accuracy,EEA）nEEA=实际项目工作量/估计项目工作量1、摩托罗拉n目标2：提高缺陷遏制能力n问题2.1：发布前缺陷检测过程的当前已知有效性如何？n度量2.1：全部缺陷遏制有效性（Total Defect

10、Containment Effectiveness,TDCE）nTDCE=发布前缺陷数/（发布前缺陷数+发布后缺陷数）n问题2.2：对以具体软件项目而言，在软件开发的每个构造阶段引入故障的当前一直遏制有效性如何？n度量2.2：阶段i的阶段遏制有效性（Phase Containment Effectiveness,PCEi）nPCEi=阶段i出错数/（阶段i出错数+阶段i缺陷数）1、摩托罗拉n目标3：提高软件可靠性n问题3.1：软件失效率是多少？怎样随时间变化？n度量3.1：失效率（Failure Rate,FR）nFR=失效率/执行时间1、摩托罗拉n目标4：降低软件缺陷密度n问题4.1:过程中

11、故障的规格化数目是多少？它和过程中缺陷数相比如何？n度量4.1a:过程中故障数（In-process Faults,IPF）nIPF=由增量式软件开发引起的过程中故障数/汇编等价的delta源代码大小n度量4.1b:过程中缺陷数（In-process Defects,IPD）nIPD=由增量式软件开发引起的过程中缺陷数/汇编等价的delta源代码大小1、摩托罗拉n目标4：降低软件缺陷密度n问题4.2：交付给顾客软件的当前已知缺陷量是多少？n度量4.2a:总发布缺陷数total(Total Released Defects total,TRD total)nTRD total=发布缺陷数/汇编等

12、价总源代码大小n度量4.2b:总发布缺陷数delta(TRD delat)nTRD delat=由增量式软件开发引起的发布缺陷数/汇编等价总源代码大小1、摩托罗拉n目标4：降低软件缺陷密度n问题4.3：交付给顾客软件的当前已知顾客发现的缺陷量是多少？n度量4.3a:顾客发现缺陷数total(Customer-Found Defects total,CFD total)nCFD total=顾客发现缺陷数/汇编等价总源代码大小n度量4.3b:顾客发现缺陷数delta(CFD delta)nCFD delta=有增量式软件开发引起的顾客发现缺陷数/汇编等价总源代码大小1、摩托罗拉n目标5：改进顾客

13、服务n问题5.1：本月期间还未解决的新问题数是多少？n度量5.1：新未解决问题数（New Open Problems,NOP）nNOP=本月未解决的新发布后问题总数n问题5.2：本月末未解决的问题总数是多少？n度量5.2：未解决问题总数（Total Open Problems,TOP）nTOP=本月末仍未解决的新发布后问题总数1、摩托罗拉n目标5：改进顾客服务n问题5.3：本月末未解决问题的平均寿命是多少？n度量5.3：未解决问题的平均寿命（Age of Open Problems,AOP）nAOP=本月末仍未解决的发布后问题持续未解决的总时间/本月末仍未解决的发布后未解决问题数n问题5.4：

14、本月期间已解决问题的平均寿命是多少？n度量5.4：已解决问题的平均寿命（Age of Closed Problems,ACP）nACP=本月已解决的发布后问题的持续未解决的总时间/本月解决的发布后未解决问题数1、摩托罗拉n目标6：降低不符合性费用n问题6.1：本月期间修补发布后问题的费用是多少？n度量6.1：修补问题费用（Cost of Fixing Problems,CFP）nCFP=本月期间与修补发布后问题相关的费用1、摩托罗拉n目标7：提高软件生产率n问题7.1：软件开发项目的生产率是多少（按软件大小）？n度量7.1a:软件生产率total(Software Productivity t

15、otal,SP total)nSPtotal=汇编等价的总源代码大小/软件开发工作量n度量7.1b:软件生产率delta(SP delta)nSPdelta=汇编等价delta源代码大小/软件开发工作量1、摩托罗拉n有以上目标看到，度量3.1、4.2a、4.2b、4.3a和4.3b是最终产品质量的度量，5.1到5.4是软件维护度量，2.1、2.2、4.1a、4.1b是过程中质量度量，其余的用于进度、估计和生产率。2、IBM RochesternIBM共同软件测量委员会定义了一组标准的5-UP软件质量度量。包括：n整体顾客满意度以及按CUPRIMDS参数的满意度。n三年LOP跟踪的发布后缺陷率：

16、基于报告缺陷的发布版本的TVUA/MSSI.n顾客问题召唤n修补响应时间n有缺陷修补数五、收集软件工程数据n需要确保收集的数据对项目、过程和质量管理提供有用的数据，且不至于成为开发团队的负担。n收集方法，注意反馈和迭代：n1）建立数据收集的目标n2）开发感兴趣问题的清单n3）建立数据类别n4）设计和检验数据收集形式n5）收集并验证数据n6）分析数据n数据收集系统或开发跟踪系统的验证要素-非常重要五、收集软件工程数据n收集过程采用的若干基本形式：报告表格、专访和使用计算机系统的自动收集n为使数据收集高效并产生效果，应当把它同配置管理或更改控制系统合并在一起缺陷类型的分类n接口缺陷：两个独立的逻辑

17、片段通信的路线上的缺陷。它们是在下列实体之间的通信中的错误：部件、产品、同一部件的模块和子程序、以及用户界面n高层设计（I0）：n使用错误参数n用户界面功能键的不一致使用n使用不正确消息n低层设计（I1）：n丢失所需参数，错误参数n模块间接口：没有输入，以错误次序输入n模块内接口:向子系统例程传送值/数据n公共数据结构的不正确使用，向代码传送误用的数据n编码（I2）：n向宏、应用程序接口（API）、模块的参数传送错误值n不正确建立由另一段代码使用的公共控制块n未向代码调用者发出正确异常缺陷类型的分类n逻辑缺陷：逻辑要完成的功能中引起不正确结果的缺陷n高层设计（I0）：n无效或不正确的屏幕流n评

18、审包中通过部件的高层流丢失或不正确n低层设计(I1)：n逻辑未实现I0设计n功能丢失或者过量n编码（I2）：n缺初始化n变量初始化不正确缺陷类型的分类n文档缺陷：功能描述的缺陷，可能引起一些人按此信息做错事情。例如，一个宏前沿包含有参数的不正确描述，引起这个宏的用户不正确的使用该参数，这就为针对这个宏的文档缺陷六、小结n软件质量度量关注产品、过程和项目的质量方面。按照软件生命周期分成三类：最终产品质量度量、过程中质量度量和维护质量度量。n产品质量度量：平均无失效时间、缺陷密度、顾客报告的问题、顾客满意度n过程中质量度量：基于阶段的缺陷排除模式、缺陷排除的有效性、正式机器测试期间的缺陷密度、正式机器测试期间的缺陷出现模式n维护质量度量：修补积累、积累管理指数、修补响应时间、逾期修补百分数、有缺陷修补