您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 质量控制/管理 > 软件质量管理 第四章
第四章软件质量度量2目录一、产品质量度量二、过程中质量度量三、软件维护的度量四、质量程序的例子五、收集软件工程数据六、小结3一、产品质量度量1.缺陷密度度量2.顾客问题度量3.顾客满意度度量4一、产品质量度量•软件质量的实际定义–平均无失效时间(meantimetofailure,MTTF)–缺陷密度–顾客问题–顾客满意度•应用范围–MTTF—交通管制、航空电子学、武器系统–缺陷密度(率)—商业软件系统51.缺陷密度(率)度量缺陷率-软件大小通常千行源代码数(KLOC)功能点6例子:KLOC•KLOC-物理行计数?指令语句计数?是否加数据定义?注解?首次发布与更新版本后•当更新版本后:•更改标记法–LOC重新计数–缺陷跟踪—使用更改标记法(changeflagging)7例子:功能点•一个应用程序5个主要成分的加权总和–外部输入数(例如,事务类型)3~6–外部输出数(例如,报告类型)4~7–逻辑内部文件数7~15–外部接口文件数5~10–外部查询数(支持的联机查询种类)3~68例子:功能点•第一步Wij是5个成分按复杂性级别的加权因子,Xij是应用程序中每种成分的数目9例子:功能点•14个特征:–数据通信–分布式功能–性能–频繁使用的配置–事务率–联机数据项、–最终用户效率–联机更新–复杂处理–可重用性–易安装性–易操作性–多站点–易更改性10例子:功能点•第二步•将这些特征分值(从0到5)按下列公式加起来,形成价值调整因子(valueadjustmentfactor,VAF)•其中Ci是通用系统特征i的分值11例子:功能点•最后,得到了功能点数–FP=FC*VAF•已成为一个关键的生产率测度•主要应用于应用软件而非系统软件122.顾客问题度量•来自顾客的视角–缺陷性问题(缺陷率度量)–非缺陷性问题(使用性问题、不明确的文档或者信息、有据缺陷的重复出现)•采用PUM(problemsperusermonth)表示PUM=一个时段内的顾客报告的问题总数/在此期间软件许可证月总数许可证月总数=软件的安装许可证数*计算时段中的月数132.顾客问题度量•降低PUM措施–改进开发过程,减少产品缺陷–通过改进产品的所有方面(实用性及文档)、顾客教育和支持减少非缺陷性问题–增加产品销量(安装许可证数)14缺陷率度量和顾客问题度量比较缺陷/KLOCPUM分子有据且不同的产品缺陷数所有顾客问题(缺陷性和非缺陷性,首次的和重复的)分母产品大小(KLOC)产品的顾客使用(用户一月数)测量角度生产者-软件开发机构顾客作用范围内在产品质量内在产品质量加上其他因素153.顾客满意度度量•5级尺度–非常满意–满意–一般–不满意–非常不满意163.顾客满意度度量•5级尺度基础上,构造几种度量–完全满意顾客百分数–满意顾客百分数(满意和完全满意)–不满意顾客百分数(不满意和完全不满意)–非满意顾客百分数(一般、不满意和完全不满意)•通常使用第二个度量,某些时候为降低非满意百分数,也使用第4个度量•也可使用加权指数法17二、过程中质量度量1、机器测试期间的缺陷密度2、机器测试期间的缺陷出现模式3、基于阶段的缺陷排除模式4、缺陷排除有效性181.机器测试期间的缺陷密度•正式机器测试(将代码集成到系统库之后的测试)期间的缺陷率,通常同现场得到的缺陷率正相关•正相关:在测试中发现的缺陷越多,以后发现的缺陷也越多192.机器测试期间的缺陷出现模式•测试期间的总缺陷率是一个简明指示器,而失效间隔则能给出更多信息。•测试期间缺陷出现模式–测试期间按时间间隔出现的缺陷数,原始数据,不一定有效–有效缺陷出现的模式-当报告的问题得到确定时–缺陷超时累积模式:开发机构不能立即审查和修补所有报告的问题。若开发周期结束时缺陷累积仍然大,则需要回归测试才能保证系统稳定性和确保产品质量等级203.基于阶段的缺陷排除模式•除测试外,还需跟踪开发周期所有阶段中的缺陷,包括设计评审、代码审查、测试前的正式验证•IBM开发项目的缺陷排除模式表明将缺陷排除的重点放在前期则质量要好•缺陷排除的各个阶段:高层设计评审(I0),底层设计评审(I1)、代码审查(I2)、单元测试(UT)、部件测试(CT)、系统测试(ST)214.缺陷排除有效性•缺陷排除有效性(DRE)定义:DRE=开发阶段排除的缺陷数/产品中潜伏的缺陷数•分母估计:在现阶段排出的缺陷数+以后发现的缺陷数•该度量值越高,开发过程越有效22三、软件维护的度量•1、修补积累和积累管理指数•2、修补响应时间•3、逾期修补百分数•4、修补质量231.修补积累和积累管理指数•BMI=当月解决问题数/当月出现问题数•BMI100,累积问题减少了•BMI100,累积问题增加242.修补响应时间•修补方针建立在时间限上•按照缺陷可能引起的风险的严重程度分级,越严重越需要昼夜不停的修补问题253.逾期修补百分数•对每个修补而言,如果修补所需时间超过了按严重性的响应时间标准,它就被分类到逾期修补•逾期修补百分数=超过按严重性等级的修补时间标准的修补数/指定时间内交付的修补总数•只针对于已经解决的问题•若某一星期做了重大改进(减少了积累问题),则将产生一个高的逾期指数264.修补质量•一个修补是有缺陷的:没有修补报告的问题或者修补了原有问题同时又注入了新的缺陷•将会严重影响顾客满意度•两种记录方式:发现它的月份或是按交付修补的月份记录•维护过程的质量目标应当为无逾期的、零有缺陷修补。27四、度量程序的例子1、摩托罗拉2、IBMRochester281.摩托罗拉•摩托罗拉的软件开发质量政策(QPSD)–目标1、改进项目计划制定2、提高缺陷遏制能力3、提高软件可靠性4、降低软件缺陷密度5、改进顾客服务6、降低不符合性的费用7、提高软件生产率291.摩托罗拉•摩托罗拉的软件开发质量政策(QPSD)–测量领域•交付缺陷数和按标准大小的交付缺陷数•全过程的总有效性•遵循进度•估计准确性•未解决顾客问题数•问题持续未解决的时间•不符合性的费用•软件可靠性301.摩托罗拉目标1:改进项目计划制定–问题1.1:估计项目进度实际值的准确度是多少?–度量1.1:进度估计准确度(ScheduleEstimationAccuracy,SEA)•SEA=实际项目持续时间/估计项目持续时间–问题1.2:估计项目工作量实际值的准确度是多少?–度量1.2:工作量估计准确度(EffortEstimationAccuracy,EEA)•EEA=实际项目工作量/估计项目工作量311.摩托罗拉目标2:提高缺陷遏制能力–问题2.1:发布前缺陷检测过程的当前已知有效性如何?–度量2.1:全部缺陷遏制有效性(TotalDefectContainmentEffectiveness,TDCE)•TDCE=发布前缺陷数/(发布前缺陷数+发布后缺陷数)–问题2.2:对以具体软件项目而言,在软件开发的每个构造阶段引入故障的当前一直遏制有效性如何?–度量2.2:阶段i的阶段遏制有效性(PhaseContainmentEffectiveness,PCEi)•PCEi=阶段i出错数/(阶段i出错数+阶段i缺陷数)321.摩托罗拉目标3:提高软件可靠性–问题3.1:软件失效率是多少?怎样随时间变化?–度量3.1:失效率(FailureRate,FR)•FR=失效率/执行时间331.摩托罗拉目标4:降低软件缺陷密度–问题4.1:过程中故障的规格化数目是多少?它和过程中缺陷数相比如何?–度量4.1a:过程中故障数(In-processFaults,IPF)•IPF=由增量式软件开发引起的过程中故障数/汇编等价的delta源代码大小–度量4.1b:过程中缺陷数(In-processDefects,IPD)•IPD=由增量式软件开发引起的过程中缺陷数/汇编等价的delta源代码大小341.摩托罗拉目标4:降低软件缺陷密度•问题4.2:交付给顾客软件的当前已知缺陷量是多少?•度量4.2a:总发布缺陷数total(TotalReleasedDefectstotal,TRDtotal)–TRDtotal=发布缺陷数/汇编等价总源代码大小•度量4.2b:总发布缺陷数delta(TRDdelat)–TRDdelat=由增量式软件开发引起的发布缺陷数/汇编等价总源代码大小351.摩托罗拉目标4:降低软件缺陷密度–问题4.3:交付给顾客软件的当前已知顾客发现的缺陷量是多少?–度量4.3a:顾客发现缺陷数total(Customer-FoundDefectstotal,CFDtotal)•CFDtotal=顾客发现缺陷数/汇编等价总源代码大小–度量4.3b:顾客发现缺陷数delta(CFDdelta)•CFDdelta=有增量式软件开发引起的顾客发现缺陷数/汇编等价总源代码大小361、摩托罗拉目标5:改进顾客服务–问题5.1:本月期间还未解决的新问题数是多少?–度量5.1:新未解决问题数(NewOpenProblems,NOP)•NOP=本月未解决的新发布后问题总数–问题5.2:本月末未解决的问题总数是多少?–度量5.2:未解决问题总数(TotalOpenProblems,TOP)•TOP=本月末仍未解决的新发布后问题总数371.摩托罗拉目标5:改进顾客服务–问题5.3:本月末未解决问题的平均寿命是多少?–度量5.3:未解决问题的平均寿命(AgeofOpenProblems,AOP)•AOP=本月末仍未解决的发布后问题持续未解决的总时间/本月末仍未解决的发布后未解决问题数–问题5.4:本月期间已解决问题的平均寿命是多少?–度量5.4:已解决问题的平均寿命(AgeofClosedProblems,ACP)•ACP=本月已解决的发布后问题的持续未解决的总时间/本月解决的发布后未解决问题数381.摩托罗拉目标6:降低不符合性费用–问题6.1:本月期间修补发布后问题的费用是多少?–度量6.1:修补问题费用(CostofFixingProblems,CFP)•CFP=本月期间与修补发布后问题相关的费用391.摩托罗拉目标7:提高软件生产率–问题7.1:软件开发项目的生产率是多少(按软件大小)?–度量7.1a:软件生产率total(SoftwareProductivitytotal,SPtotal)•SPtotal=汇编等价的总源代码大小/软件开发工作量–度量7.1b:软件生产率delta(SPdelta)•SPdelta=汇编等价delta源代码大小/软件开发工作量401.摩托罗拉•有以上目标看到,度量3.1、4.2a、4.2b、4.3a和4.3b是最终产品质量的度量,5.1到5.4是软件维护度量,2.1、2.2、4.1a、4.1b是过程中质量度量,其余的用于进度、估计和生产率。412.IBMRochesterIBM共同软件测量委员会定义了一组标准的5-UP软件质量度量。包括:–整体顾客满意度以及按CUPRIMDS参数的满意度。–三年LOP跟踪的发布后缺陷率:基于报告缺陷的发布版本的TVUA/MSSI.–顾客问题召唤–修补响应时间–有缺陷修补数42五、收集软件工程数据•需要确保收集的数据对项目、过程和质量管理提供有用的数据,且不至于成为开发团队的负担。•收集方法,注意反馈和迭代:–1)建立数据收集的目标–2)开发感兴趣问题的清单–3)建立数据类别–4)设计和检验数据收集形式–5)收集并验证数据–6)分析数据•数据收集系统或开发跟踪系统的验证要素-非常重要43五、收集软件工程数据•收集过程采用的若干基本形式:报告表格、专访和使用计算机系统的自动收集•为使数据收集高效并产生效果,应当把它同配置管理或更改控制系统合并在一起44缺陷类型的分类接口缺陷:两个独立的逻辑片段通信的路线上的缺陷。它们是在下列实体之间的通信中的错误:部件、产品、同一部件的模块和子程序、以及用户界面–高层设计(I0):•使用错误参数•用户界面功能键的不一致使用•使用不正确消息–低层设计(I1):•丢失所需参数,错误参数•模块间接口:没有输入,以错误次序输入•模块内接口:向子
本文标题:软件质量管理 第四章
链接地址:https://www.777doc.com/doc-446580 .html