(教学课件)软件质量保证.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《(教学课件)软件质量保证.ppt》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 教学课件 教学 课件 软件 质量保证
- 资源描述:
-
1、第16章 软件质量保证 16.1 软件质量与软件质量与SQA 16.2 软件复审软件复审 16.3 正式的技术复审正式的技术复审 16.4 基于统计的质量保证基于统计的质量保证16.5 软件可靠性软件可靠性 16.6 SQA计划计划 16.7 小结小结 第1页,共57页。16.1 软件质量与软件质量与SQA16.1.1 软件质量软件质量 在ANSI/IEEE的729-1983号标准中定义软件质量为:“与软件产品满足规定和隐含需求的能力有关的全体特征(或特性)”。为满足软件的各项规定的或隐含的功能、性能需求,符合文档化开发标准,就需要相应地设计出一些质量特性及其组合质量目标,作为在软件开发与维护
2、中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足,则这个软件产品的质量就是高的。这些被定义出来的特性及其组合就称之为软件的“质量目标”。第2页,共57页。从上述软件质量的定义中,反映出了以下三个方面的问题。(1)软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。(2)软件人员必须遵循软件过程规范,用工程化的方法来开发软件。如果不遵守这些规程,软件质量就没有保证。(3)往往会有一些隐含的需求没有明确地提出来。如果软件只是满足那些规定的需求而不可能满足那些可能存在的隐含需求,软件质量也不能保证。第3页,共57页。软件质量是各种特性的复杂组合,它随着应用的不同而不同,随着用户
3、提出的质量要求不同而不同。在计算机发展的早期(20世纪50和60年代),软件质量保证工作曾经只由程序员来承担。20世纪70年代,美国军方在软件开发合同中首先提出了软件质量保证的标准,提出了软件质量保证活动的定义是为了保证软件质量而必须的“有计划的和系统化的行动模式”这一观点。这一定义的含义是要求在一个组织中应当由多个机构共同协作,承担保证软件质量的责任。包括软件工程师、项目管理者、客户、销售人员和SQA小组的人员。第4页,共57页。SQA小组是软件开发组织中独立于任何项目组的专职品质保证组织。他们以客户的观点来看待软件,通过自己的工作来回答软件是否满足各项质量指标、软件开发是否按照预先设定的标
4、准进行、作为SQA活动一部分的技术规程是否恰当地发挥了作用等问题。换句话说,SQA针对工作过程与标准的符合性、工作产品与标准的符合性进行审核与审查。第5页,共57页。16.1.2 SQA活动活动 软件质量保证活动由各种任务构成。这些任务分别和从事技术工作的软件工程师和负责对质量保证活动进行计划、监督、记录、分析、报告工作的专职SQA小组成员相关。软件工程师通过采用可靠的技术方法和措施,进行正式的技术复审,执行计划周密的软件测试来考虑软件质量问题并保证软件质量;SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SEI推荐了一组有关软件质量保证活动中的计划、监督、记录分析及报告的SQA活动。
5、这些活动由一个独立的SQA小组执行。按照SEI的建议,具体的SQA活动应当包括:第6页,共57页。(1)为项目准备SQA计划:该计划在制定项目开发计划时制订,由所有对质量感兴趣的相关部门复审。该计划将控制由软件工程小组和SQA小组执行的软件质量保证活动。在SQA计划中,应当包含:需要进行的评价;需要进行的审查和复审;项目可以采用的标准;错误报告和跟踪过程;由SQA小组产生的文档目录;为软件项目组提供的反馈数据种类。(2)参与开发该项目的软件过程:软件工程小组为将要进行的工作选择一个工程过程。SQA小组将复审过程说明,以保证该过程与组织政策、内部软件标准、外部标准以及软件开发计划的其他部分相符合
6、。第7页,共57页。(3)复审各项软件工程活动:对工程活动是否符合定义好的软件工程过程进行核实。SQA小组识别、记录和跟踪实际工作与已定义过程之间的偏差,提出报告要求改正的地方并对是否已经改正进行跟踪与核实。(4)审查指定的软件工作产品,对其是否符合定义好的软件工程过程中的相应部分进行核实。SQA小组要对选出的产品进行复审,识别、记录和跟踪产品与过程规定的偏差,并对是否已经改正进行跟踪核实。定期地将工作结果向项目管理者报告。第8页,共57页。(5)确保软件工作及工作产品中的偏差已记录在案,并按照预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。(6)记录所有的不符
7、合部分,并报告给高级管理者,对不符合部分进行跟踪,直到问题得到解决。此外,SQA小组还要协调变更的控制和管理,并协助收集项目度量信息。第9页,共57页。16.2 软软 件件 复复 审审16.2.1 软件复审软件复审 软件复审是软件工程过程中滤除缺陷的“过滤器”。在软件项目开发过程中的多个不同的点上,软件复审活动能够起到及早发现错误进而引发排错活动的作用。软件复审的目的是尽可能多地发现被复审对象中的缺陷,起到“净化”工作产品的作用。由于我们发现别人生产的工作产品中的缺陷比发现自己的缺陷要容易,所以复审应当在不同的工程师之间进行。任何一次复审都是借助人的差异性来达到目标的活动,它的目标包括:第10
8、页,共57页。(1)指出一个人或一个小组生产的产品所需进行的改进。(2)确定被审核产品中不需要或者不希望改进的部分。(3)得到与未复审时相比更加一致,至少更可预测的技术工作的质量,从而使得技术工作更可管理。复审的方式很多,包括非正式的复审、正式的同行评审、管理复审等等。第11页,共57页。16.2.2 软件缺陷对成本的影响软件缺陷对成本的影响 在软件工程活动中,“缺陷”是指在软件交付给最终用户后发现的质量问题;而“错误”描述在软件交付前由软件工程师发现的质量问题。很明显,缺陷带来的危害远大于“错误”带来的影响。因此,正式技术复审的主要目标就是在复审过程中发现错误,以便潜在的缺陷在交付之前变成“
9、错误”并得到纠正。正式技术复审的明显优点就是能够较早发现错误,防止错误传播到软件过程的后继阶段。“尽早”发现错误是我们的追求,因为同样的错误对成本和工期产生的影响与发现错误、改正错误的时间是密切相关的。第12页,共57页。大量的研究表明,设计活动引入的错误占软件过程中出现的所有错误和最终缺陷数量的50%70%。而近期的研究表明,正式的技术复审在发现设计错误方面有最高达到75%的有效性。由于能够通过复审检测和排除大量的设计错误,复审过程将可望极大地降低后继开发和维护阶段的工作成本。根据从多个大型项目中采集的数据表明,假如在设计阶段发现的一个错误的改正成本是1个货币单位,那么在测试之前发现的一个错
10、误的改正成本就是6.5个货币单位,在测试时发现一个错误的改正成本变成15个货币单位,而在发布之后,改进一处缺陷的成本达到60100个货币单位。因此,尽可能早地发现错误,是降低软件错误/缺陷对工程成本影响的有效途径。第13页,共57页。16.2.3 缺陷的放大和消除缺陷的放大和消除 可以用“缺陷放大模型”来说明及时的复审在软件工程中的作用(如图16.1所示)。图中,方块表示一个开发步骤,可能因疏忽而产生错误。复审过程可能没有完全发现来自此步骤之前的和新发生的所有错误。从而可能在本阶段“继承”了一些错误,并将一部分错误引入下一阶段。其中,一部分来自前一阶段的错误可能会误导本阶段的工作,导致在错误的
11、基础上产生更多的错误,形成错误的“放大”效应。第14页,共57页。图16.1 缺陷的放大模型通过的错误放大的错误1:X新产生的错误错误检测有效性百分比缺陷检测开发步骤来自以前步骤的错误传递给下一步骤的错误第15页,共57页。图16.2是一个没有进行技术复审的软件开发过程中缺陷放大的例子。乐观地设想,在每一个测试步骤都能够发现并改正50%的输入错误,而又不引入新的错误。在图中明显地看到,最初在概要设计阶段产生的10个错误,到集成测试之前已经放大成为94个。12个隐藏的缺陷将随着软件的发布扩散到用户处。表16.1是无复审情况下缺陷放大数据及因此增加的成本数据。第16页,共57页。图16.2 缺陷的
12、放大无复审00100%概要设计10646 41.5 X1.5250%详细设计3710 273 X32620%编码/单元测试94到集成0050%集成测试470050%确认测试240050%系统测试12隐藏的错误941027第17页,共57页。表表16.1 无复审情况下软件缺陷对成本的影响无复审情况下软件缺陷对成本的影响错误发现时机缺陷数量成本单位成本总计测试之前226.5143测试期间82151230发布之后1267804缺陷总成本 2177第18页,共57页。从图16.3中可以看到,只要在每个工程阶段都进行复审工作,就能够有效地遏制缺陷放大的势头,从而减少缺陷对成本的影响。在概要设计阶段同样是
13、10个错误,到集成测试时仅扩展为24个,最终输出到用户处的缺陷只有三个。表16.2是有复审情况下缺陷 数据及因此增加的成本数据。从上例中能够清晰地看出,实行复审能够及早地发现大部分错误,极大地减少交付产品中的缺陷数,降低因修正缺陷带来的成本。当然,为了进行复审,开发人员也必须投入工作量,也就是说,组织必须为复审支付成本。但复审增加的成本和因进行了复审而降低的纠正错误和缺陷的成本相比,是相当低的。因此,软件开发组织应当在各个工作阶段上组织进行有效的复审,以便消除缺陷,减少缺陷成本,保证软件质量。第19页,共57页。图16.3 缺陷的放大有复审001070%概要设计3212 11.5 X1.525
14、55%详细设计155 103 X32560%编码/单元测试24到集成0050%集成测试120050%确认测试60050%系统测试3隐藏的错误24510第20页,共57页。表表16.2 有复审情况下软件缺陷对成本的影响有复审情况下软件缺陷对成本的影响错误发现时机缺陷数量成本单位成本总计设计期间221.533测试之前366.5234测试期间1515315发布之后367201缺陷总成本 783第21页,共57页。16.3 正式的技术复审正式的技术复审 正式技术复审(FTR)是一种由技术工程师进行的软件质量保证活动。FTR的目标是:(1)在软件的任何一种表示形式中发现功能、逻辑或实现上的错误。(2)证
15、实经过复审的软件的确满足需求。(3)保证软件的表示符合预定义的标准。(4)得到一种以一致的方式开发的软件。第22页,共57页。(5)使项目更加容易管理。因为FTR的进行使大量人员对软件系统中原本并不熟悉的部分更加了解,因此,FTR还起到了提高项目连续性和培训后备人员的作用。FTR实际上是一类复审方式,包括“走查”(Walkthrough)、“审查”(Inspection)、“轮查”(Round Robin Review)以及其他软件小组的技术评估。每次的FTR都以会议的形式进行,只有经过适当地计划、控制和相关人员的积极参与,FTR才能获得成功。第23页,共57页。16.3.1 复审会议的组织复
16、审会议的组织 从保证会议效果出发,不论进行什么形式的FTR活动,会议的规模都不宜过大,控制在35人较好;每个参会人员都要提前进行准备,但是复审准备工作占用的工作时间应当少于两小时;会议的时间不宜长,控制在两个小时之内。考虑到这样的约束,每次复审的对象显然应当只是整个软件中的某个较小的特定部分。不要试图一次复查整个设计,而要对每个模块或者一小组模块进行复审走查。经验证明,当一次FTR关注的范围较小时,发现错误的可能性更大一些。第24页,共57页。FTR的焦点是某个工作产品,比如一部分需求规约,一个模块的详细设计,一个模块的源代码清单等等。负责生产这个产品的人通知“复审责任人”产品已经完成,需要复
17、审。复审责任人对工作产品的完成情况进行评估,当确认已经具备复审条件后,准备产品副本,发放给预定要参加复审的复审者。复审者花12小时进行准备。通常在第二天召开复审会议。复审会议由复审责任人主持,产品生产者和所有的复审者参加,并安排专门的记录员。产品生产者在会议上要“遍历”工作产品并进行讲解,复审者则根据各自的准备提出问题。当发现错误和问题时,记录员将逐一进行记录。第25页,共57页。在复审结束时,必须做出复审结论。结论只能是下列三种之一:(1)工作产品可以不经修改地被接收。(2)由于存在严重错误,产品被否决(错误改正后必须重新复审)。(3)暂时接收工作产品(发现了轻微错误需要改正,但改正后无需再
18、次评审)。参与复审的所有人员,都必须在结论上签字以表示他们参加了本次FTR,并同意复审小组的结论。第26页,共57页。16.3.2 复审报告和记录保存复审报告和记录保存 在FTR期间,一名复审者(记录员)主动记录所有被提出来的问题。在会议结束时对这些问题进行小结,并形成一份“复审问题列表”。此外还要形成一份简单的“复审总结报告”。复审总结报告中将阐明如下问题:复审对象是什么;有哪些人参与复审;发现了什么,结论是什么。第27页,共57页。复审报告是项目历史记录的一部分,可以分发给项目负责人和其他感兴趣的复审参与方。复审问题列表有两个作用,首先是标识产品中的问题区域,其次将被用作指导生产者对产品进
展开阅读全文