软件质量管理实践.doc
《软件质量管理实践.doc》由会员分享,可在线阅读,更多相关《软件质量管理实践.doc(14页珍藏版)》请在咨信网上搜索。
1、-精品word文档 值得下载 值得拥有- 软件质量管理实践软件缺陷预防、清除、管理实用方法第7章 软件度量软件度量是针对软件开发项目、过程及产品进行数据定义、收集以及分析的持续性定量化的过程。有效度量的作用在于能够帮助软件组织认清自身的能力,理解、评价、控制、预测和改进软件工作产品或软件过程。本小节为大家介绍的是软件度量及其方针。随着技术的进步和软件应用领域的拓展,用户需要更大规模、更可靠的软件,此时,软件度量工作显得更为重要了。如果一个组织能够对其生产的产品做出预测和承诺,那么就可以说这个组织是成功的。有效度量的作用在于能够帮助软件组织认清自己的能力,根据对度量数据结果的分析,进一步为他们的
2、生产和服务制订出可行的计划;及时找到变化趋势,预测问题,发现或者采取有效手段预防缺陷;不断改进软件开发过程。需求的变更直接导致规模的变更、进度的延期以及成本的增长,公司要求项目经理定期度量需求变更(包括新增的、修改的和删除的需求数)的数量及需求总数的变化,控制需求变更并采取相应的措施。图7-1图7-1中两条线分别表示需求总数的变更以及每周需求变更的数量。曲线中的数据表明,第二周的需求评审后,第三周需求总数又有了明显的增长,而且第三、第四和第五周需求变更的数量都很大。为了查找具体原因,须继续分析更加详细的数据,如图7-2所示。图7-2中显示,经过了第二周的第1次评审,需求变更还是很大,其中大量的
3、需求处于修改状态。而且第七周第2次评审后,需求在相当长的时间内依旧没有稳定下来。目前,项目已经进入到设计阶段,大量的需求变更是项目失败的一个隐患。图7-2为了控制不断需求的变更,项目可能采取包括重新分配资源,重新估计规模、工作量和进度等具体措施。另外,还可以详细地分析需求变更的具体原因(如误解、不清楚、不完善和不正确等)、需求变更的类型(如功能、性能和接口需求等)以及细化跟踪的粒度到每个模块。通过这些详细的分析,可确定造成需求频繁变更的根本来源,以便有针对性地采取措施。7.6 缺陷度量缺陷度量是软件度量的一部分,其本身并不能发现缺陷、剔除缺陷,但是有助于这些问题的解决。另外,当正确、持续地进行
4、了缺陷度量时,产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。数据的质量等因素,我们在本章7.4节中已经考虑了,这里仍将遵循。7.6.1 什么是缺陷度量软件产品质量度量,主要集中在软件的缺陷度量上。缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化,将分散的缺陷数据统一管理,使其有序而清晰,然后通过采用一系列数学函数,对数据进行处理,分析缺陷密度和趋势等信息,从而提高产品质量和改进开发过程。一般来说,在软件质量保证过程中,需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。如测试相关的缺陷,需要度量包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试
5、结果数据(包括缺陷数据、覆盖率数据)等。(1)组织级缺陷度量,目的是了解组织的整体缺陷情况,了解客户对组织的质量满意度,建立组织基线,确定改进活动。(2)项目级缺陷度量,目的是了解项目实时质量情况(很多项目只在最后度量,包括那些迭代式开发的项目,实际上为时已晚),预测缺陷造成的发布后维护工作量,了解客户对项目的质量满意度。(3)个体缺陷度量,目的是了解个体缺陷产生的详细原因,并实施行动进行改进。前两种度量大家接触较多,但第三种度量常常被忽略。这常常导致:项目反复得到关于自己的质量评价,但很难了解如何去提高;测试组常常能做一些改进(如增加测试覆盖、延长测试周期)来提高缺陷排除效率,但开发组没有降
6、低缺陷产生数量的有效措施;软件开发遵循了编码规范,但似乎对提高质量没有太多帮助。度量得到的缺陷相关数据,分析方法可参见本章稍后的缺陷分析相关内容。7.6.2 缺陷度量元缺陷度量元的选择,也需要从度量目标出发,确定适当的度量元。例如,可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。信息需要可度量概念度量目的度 量 元派生度量元通过模块的各类型缺陷数来评价软件质量模块缺陷分布反映缺陷按类型、严重程度、所属模块分布情况。通过度量可以客观上看出哪个模块的缺陷比较高,这样可加大对这个模块的开发投入每个模块的各类缺陷数目各模块的缺陷个数百分比通过总体的各类型缺陷数来评价软件质量总体缺
7、陷分布反映总体缺陷的分布情况,可看出软件的缺陷主要是哪些方面的缺陷,可帮助项目组找出问题,提高质量每类缺陷的数目每类缺陷占总缺陷的比例通过缺陷密度评价模块稳定性缺陷密度通过按模块的缺陷密度倒序排列,通过二八定理确定缺陷密集模块,确定修复重点每个模块的各类缺陷数目每个模块的各类缺陷密度及比例判断缺陷数量的趋势总体趋势反映新缺陷数、被解决的缺陷数和遗留的缺陷数的趋势,了解缺陷解决是否及时和全面各种状态缺陷的数量各种状态缺陷的数量的比例判断缺陷驻留时间缺陷排除情况判断缺陷产生的原因缺陷数量排行、缺陷发现时间、缺陷清除时间整体缺陷清除率、阶段性缺陷清除率、缺陷的驻留时间确定哪种缺陷发现方式有效缺陷数量
8、和种类选择合适的降低缺陷的方法缺陷种类缺陷密度、同行评审发现错误率、测试发现的缺陷数、PPQA发现的缺陷数除了上边重点描述的度量元外,还可以考虑其他与缺陷度量有关的因素。例如:缺陷分布度量、基于时间的缺陷到达模式、PTR累积模型、测试用例的深度、质量和有效性、测试执行的效率和质量、基于需求的测试覆盖评估、基于代码的测试覆盖评估。再说一下前面的前人栽树、后人乘凉的5个度量元。通过需求变化率、同一需求变化次数、配置项变化率、同一配置项变化次数、同一缺陷变化率这5个度量元的度量数据,查找一下是不是由变化最多的需求引起的,是不是由变化最大的配置项引起的,可以使维护的效率提高40%左右。有效选择缺陷度量
9、元,对缺陷预防、缺陷清除和缺陷管理有着至关重要的意义和作用。7.6.3 缺陷密度的定义对于一个软件工作产品,软件缺陷可以分为通过评审或测试等方法发现的已知缺陷(known defect)和尚未发现的潜在缺陷(1atency defect)两种。Myers有一个关于软件测试的著名反直觉原则:在测试中发现缺陷多的地方,还有更多的潜在缺陷将会被发现。这个原则背后的原因是,发现缺陷越多的地方,漏掉的缺陷可能性也会越大,或者说测试效率没有被显著改善之前,在纠正缺陷时将引入较多的错误。其数学表达就是缺陷密度的度量-每KLOC或每个功能点(或类似的度量-对象点、数据点、特征点等)的缺陷数,缺陷密度越低意味着
10、产品质量越高。缺陷密度的定义如下:缺陷密度=已知缺陷数量/产品规模缺陷密度与缺陷率、整体缺陷清除率、缺陷趋势、预期缺陷发现率等都有一定的关系,相关内容可以参考7.6.4 缺陷密度的用途缺陷密度是软件缺陷的基本度量,可用于设定产品质量目标,支持软件可靠性模型(如Rayleigh模型)预测潜伏的软件缺陷,进而对软件质量进行跟踪和管理,支持基于缺陷计数的软件可靠性增长模型(如Musa-Okumoto模型),对软件质量目标进行跟踪并评判能否结束软件测试。如果缺陷密度跟上一个版本相同或更低,就应该分析当前版本的测试效率是不是降低了?如果不是,意味着质量的前景是乐观的;如果是,那么就需要额外的测试,还需要
11、对开发和测试的过程进行改善。 如果缺陷密度比上一个版本高,那么就应该考虑在此之前是否为显著提高测试效率进行了有效的策划,并在本次测试中得到实施?如果是,虽然需要开发人员更多的努力去修正缺陷,但质量还是得到更好的保证;如果没有,意味着质量恶化,质量很难得到保证。这时,要保证质量,就必须延长开发周期或投入更多的资源。 当软件产品或者项目首次发布,并规定使用LOC计数时,可以比较容易地说出它的计划或者实际的质量等级,如本产品共有83KLOC,在今后的3年时间里,潜在的缺陷率是2.0个缺陷/KLOC。但当进行了修改、增强后进行产品的后续发布时,问题就会越来越复杂。缺陷跟踪:缺陷必须被跟踪到版本源头,其
12、中包含此缺陷的代码段,以及在哪个版本中加入、修改或增强的。当计算整个产品的缺陷率时,要用到所有缺陷;当计算新的和更改代码的缺陷率时,则只需要包含新的和更改代码的版本源头中的缺陷即可。缺陷率度量在每个单位的基础上度量代码质量。从用户的角度来看,缺陷率远没有缺陷总数那么重要,对他们来说,产品应该确保缺陷总数与发布版本大小无关,而随着发布版本下降。如果一个新发布版本的大小比它的前一版本大很多,则需要新的和更改代码的缺陷率应该明显地好于以往版本。我们可以考虑如下假设的例子:产品A最初发布时代码总量为50KLOC,估计残留缺陷总数是100个,平均有2个缺陷/KLOC。发布第二版时,新增代码行为20KLO
13、C,包括修改原来的4KLOC行代码(需要剔除,避免重复计算),可以计算出该版本代码总数为50 20 4 66KLOC,该版本对上一版本的缺陷率有10%的改进,估计当前版本残留缺陷新增总数可以控制在36个以内,则平均残留缺陷数为1.8个/KLOC。此时,由于此次发布版本较小,在缺陷率有10%的改进的同时,用户在缺陷数方面经历了(100 36)/100 64%的明显下降。如果进行第三版的发布时,新增代码行为40KLOC,这比第二次发布大得多,其中包括修改原来的10KLOC行代码,则该版本代码总数为66 40 10 96KLOC,为了使用户的缺陷体验不至于失望,增加的缺陷总数不应该多于上个版本的36
14、个,所以缺陷率目标需要控制在36/40 0.9或者更低,即该版本的缺陷率必须比第二版的好50%。7.6.5 缺陷管理库从缺陷发现、缺陷修复,直到缺陷解决、经验证、关闭缺陷为止,在缺陷管理的整个生命周期中记录了大量相关资料,它们是进行缺陷分析、提高产品质量所需要的宝贵信息。度量这些缺陷的发现成本、修改效益,对缺陷管理及其改进是非常有帮助的。一般地,要求将通过同行评审、测试、管理评审、PPQA发现、项目组内部发现以及客户反馈等几种手段发现的缺陷,都需要统一存放在缺陷跟踪系统(如TD、BUGZILLA等)中,进行统一管理、统计。其中涉及缺陷的基本信息在第1章已经描述过,包括缺陷标识、缺陷描述/主题、
15、发现时间、所处阶段、发现手段、缺陷原因、发生条件、发生缺陷的子系统、所处的模块、发生缺陷的机器、软硬件平台、严重程度、优先级、缺陷状态、缺陷起源、发现人、计划修正时间、修正方法、跟踪验证人等信息项。其中,软件发布前的缺陷原因关键字,可能包括以下几种:(1)需求文档:需求分析文档不明确、不详尽等原因引起。(2)信息交流:信息交流不畅,开发成员间沟通不及时引起。(3)编程:原始编程出错,没有客观原因。(4)修改:由于修改缺陷而引入的新缺陷,并且引发的变更与原变更的错误是相关的。(5)外部问题:涉及软件模块外部问题而引起。(6)培训:项目组新成员培训不充分,或使用新工具不熟练引发。(7)其他:指以上
16、各种原因之外所产生的缺陷。软件发布后缺陷原因的关键字,可以有以下几种实例:(1)需求分析:需求分析不足等原因引起。(2)系统设计:软件系统设计种种原因引起。(3)程序编码:软件开发阶段中编程错误引起。(4)维护:软件发布后程序维护时引起。(5)实施:实施人员做软件初始化设置或系统参数设置不当等所引发。(6)用户:泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。(7)数据异常:运行中不明原因引起的用户数据混乱和异常。(8)升级:软件版本升级过程中发生的问题,包括用户在升级时未按规程操作产生的问题。(9)外部问题:所涉及软件外部问题引起的变更,包括操作系统、数据库软件、第三方软件所引起的
17、问题。(10)其他:指以上各种原因之外的变更,包括变更原因不明。但需要强调,记录缺陷信息的关键是注意信息正确性。不能有人为因素失真,尤其像变更产生根本原因、变更测试情况。只有正确的信息,才能保障正确的分析结果。7.7节缺陷分析。使用缺陷密度时,有一点需要注意:百分比度量表示相对频率,需要给出足够的上下关系信息。通常的描述在使用百分比和比率时不够小心,例如:需求缺陷占总数的15%,设计缺陷占总数的25%,编码缺陷占总数的50%,其他的缺陷占总数的10%。还不能提供更加详细有力的信息,如果按照如下所述,将可以得到更多的信息,即一个包含了8 000行代码的工程,在其开发期间,检测并排除了约200个缺
18、陷,因此缺陷排除率为每千行代码25个缺陷。在这200个缺陷中,需求缺陷占总数的15%,设计缺陷占总数的25%,编码缺陷占总数的50%,其他的缺陷占总数的10%。7.7.1 缺陷种类分析下面以一个项目的系统测试故障为例进行分析,如图7-9所示。图7-9 系统测试缺陷类型分布图从系统测试故障来看,有较多故障是由接口原因造成的,细分有以下几种原因。(1)跨项目间的接口:接口设计文档的更改没有建立互相通知的机制,导致接口问题到系统测试时才暴露出来;(2)部门内部跨子系统的接口:由于本项目设计文档按功能规划编写,而不是按照产品组件编写,一般由主要承接功能工作的组编写该文档,接口内容可能不为其他开发组理解
19、并熟悉,导致因接口问题而出错;(3)系统设计基线化后,更改系统接口:没有走严格的变更流程,进行波及分析,导致该接口变更只在某个子系统中被修改,而使错误遗留下来。根据图7-9,可以制定有针对性的改进建议:(1)对接口文档的评审,一定要识别受影响的相关干系人,使他们了解并参与接口设计的把关;(2)对基线化的接口设计文档的变更一定要提交变更单给CCB决策,并做好充分的波及影响分析,以便同步修改所有关联的下游代码;(3)概要设计文档按子系统规划,详细设计文档按模块规划,通过相关组参加评审的办法来协调接口设计。以上例子的缺陷分类只是为了描述方便,本身描述并不尽合理。实际定义缺陷分类可能有很多个维度,可以
20、将前面所说的6种缺陷发现方法发现的缺陷,按照缺陷严重程度、缺陷来源、缺陷类型、注入阶段、发现阶段、修复阶段、缺陷性质、所属模块等方面进行分类和统计,计算以下各种缺陷的分布情况。(1)缺陷按发现方法的分布;(2)缺陷按生命周期注入阶段的分布;(3)缺陷按生命周期修复阶段的分布;(4)缺陷按严重程度等级的分布;(5)缺陷按系统模块的分布,并按模块缺陷密度排序。7.7.2 缺陷根源分析对于同行评审、测试出来的缺陷进行缺陷分类,按照其类型分布,找出那些关键的缺陷类型,进一步分析其产生的根源,从而制定针对性的改进措施。通过对功能上的分布情况进行分析,可以了解哪些模块处理比较难,哪些模块程序质量比较差,有
21、利于程序质量的改进和提高。缺陷起源分布报告,显示了缺陷产生的根本原因上的分布情况,这种分析会帮助改进程序代码质量。利用鱼骨图、柏拉图等分析缺陷产生的根本原因,根据这些根本原因采取措施,可以改进开发和测试过程,有重点地避免缺陷发生,提高软件产品的质量。7.7.3 缺陷注入-发现矩阵缺陷有注入阶段和发现阶段两个重要指标,注入阶段和发现阶段可以是软件生命周期的各个阶段。根据这两个阶段可以绘制出一个缺陷注入-发现矩阵,从中分析出软件开发各个环节的质量,找到最需要改进的环节(见表7-7)。表7-7 缺陷注入-发现矩阵缺陷注入阶段缺陷发现阶段需 求设 计编 码注入总计需求阶段44设计阶段136275编码、
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 质量管理 实践
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【精****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【精****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。