软件需求的质量保证ppt课件

1、软件需求的质量保证 北京航空航天大学软件工程研讨所 罗燕京 2006.1 Luo_yanjingsina.软件需求的质量保证软件的质量属性软件需求质量保证.软件的质量属性.软件的质量属性质量属性是很难定义的真正的现实系统中,在决议系统的胜利或失败的要素中,满足非功能需求往往比满足功能需求更为重要。假设开发者知道哪些特性对工程的胜利至关重要,那么他们就能选择软件工程方法来到达特定的质量目的 .质量属性分类根据不同的设计可以把质量属性分类一种属性分类的方法是把在运转时可识别的特性与那些不可识别的特性区分开另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开 .每个工程都要

2、思索软件质量属性 对用户最重要的属性有效性(availability) 高效性(efficiency) 灵敏性(flexibility)完好性(integrity) 互操作性(interoperability)可靠性(reliability)强壮性(robustness)可用性(usability)对开发者最重要的属性可维护性(maintainability)可移植性(portability)可重用性(reusability)可测试性(testability).定义质量属性 必需根据用户对系统的期望来确定质量属性。定量地确定重要属性提供了对用户期望的明晰了解,有助于设计者提出最合理的处理方案

3、.定义质量属性的方法 想出对于不同的用户类能够很重要的属性,并根据每一个属性设计出许多问题。利用这些问题讯问每一个用户类的代表,这些问题的回答有助于分析员决议哪些质量特性用作设计规范是最重要的。可以把每个属性分成一级(不用多加思索的属性)到五级(极其重要的属性)。.定义质量属性的方法 分析员与用户一同为每一属性确定特定的、可丈量的和可验证的需求。假设质量目的不可验证,那么就说不清他能否到达这些目的。在适宜的地方为每一个属性或目的指定级别或丈量单位,以及最大和最小值。假设不能定量地确定某些对他的工程很重要的属性,那么至少应该确定其优先级。 .定义质量属性的方法另一个定义属性的方法是确定任何与质量

4、期望相冲突的系统行为。经过定义一种反向需求,可以设计出强迫系统表现出那些行为的测试用例。假设不能强迫系统,那么他能够到达了他的属性目的。这种方法最适用于要求平安性能很高的运用程序,在这些运用程序中,系统的过失能够会导致致命危险。.1.有效性有效性指的是在预定的启动时间中,系统真正可用并且完全运转时间所占的百分比。更正式地说,有效性等于系统的平均缺点时间(MTTF)除以平均缺点时间与缺点修复时间之和。一个有效性需求能够这样阐明:任务日期间,在当地时间早上6点到24点,系统的有效性至少到达99.5%,在14点到18点,系统的有效性至少可到达99.95%。 .2.效率效率是用来衡量系统如何优化处置器

5、、磁盘空间或通讯带宽的。假设系统用完了一切可用的资源,那么用户遇到的将是性能的下降,这是效率降低的一个表现,拙劣的系统性能能够激怒等待数据库查询结果的用户,或者能够对系统平安性呵斥要挟。就像一个实时处置系统超负荷一样。为了在不可预料的条件下允许平安缓冲,他可以这样定义:在估计的顶峰负载条件下,10%处置器才干和15%系统可用内存必需留出备用。在定义性能、才干和效率目的时,思索硬件的最小配置是很重要的。.3.灵敏性灵敏性就像我们所知道的可扩展性、添加性、可延伸性和可扩展性一样,灵敏性阐明了在产品中添加新功能时所需任务量的大小。灵敏性对于经过一系列延续的发行版本,并采用渐增型和反复型方式开发的产品

6、是很重要的。实例:“一个至少具有6个月产品支持阅历的软件维护程序员可以在4个小时之内为系统添加一个新格式的打印报表。.4.完好性(或平安性)完好性(或平安性)主要涉及:防止非法访问系统功能、防止数据丧失、防止病毒入侵并防止私人数据进入系统。完好性的需求不能犯任何错误,即数据和访问必需经过特定的方法完全维护起来。用明确的术语陈说完好性的需求,如身份验证、用户特权级别、访问约束或者需求维护的准确数据。一个完好性的需求样本可以这样描画:只需拥有查账员访问特权的用户才可以查看客户买卖历史。.5.互操作性互操作性阐明了产品与其它系统交换数据和效力的难易程度。为了评价互操作性能否到达要求的程度,必需知道用

7、户运用其它哪一种运用程序与他的产品相衔接,还要知道他们要交换什么数据。.6.可靠性可靠性是软件无缺点执行一段时间的概率(强壮性和有效性有时可看成是可靠性的一部分)。衡量软件可靠性的方法包括正确执行操作所占的比例,在发现新缺陷之前系统运转的时间长度和缺陷出现的密度。根据假设发生缺点对系统有多大影响和对于最大的可靠性的费用能否合理,来定量地确定可靠性需求。假设软件满足了它的可靠性需求,那么即使该软件还存在缺陷,也可以为到达其可靠性目的。.7.强壮性强壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时,能继续正确运转功能的程度。强壮的软件可以从发生问题的环境

8、中完好地恢复并且可容忍用户的错误。当从用户那里获取强壮性的目的时,讯问系统能够遇到的错误条件并且要了解用户想让系统如何呼应。定义实例：一切的输入参数都要指定一个缺省值,当输入数据丧失或无效时,就运用缺省值数据。 .8.可用性(易用性)可用性也称为易用性,它所描画的是许多组成用户友好的要素。可用性衡量用户预备输入、操作和了解产品输出所破费的努力。可用性的讨论可以得出可丈量的目的,例如“一个培训过2小时的用户应该可以在平均3分钟或最多5分钟时间以内,完成从供应商目录中恳求一种商品的操作。.9.可维护性可维护性阐明了在软件中纠正一个缺陷或做一次更改的简易程度。可维护性取决于了解软件、更改软件和测试软

9、件的简易程度,可维护性与灵敏性亲密相关。高可维护性对于那些阅历周期性更改的产品或快速开发的产品很重要。他可以根据修复一个问题所破费的平均时间和修复正确的百分比来衡量可维护性。 例：对于现有报表的更改操作必需在一周内完成。 .10.可移植性可移植性是度量把一个软件从一种运转环境转移到另一种运转环境中所破费的任务量。软件可移植的设计方法与软件可重用的设计方法类似。可移植性对于工程的胜利是不重要的,对工程的结果也无关紧要。.11.可重用性从软件开发的长久目的上看,可重用性阐明一个软件组件除了在最初开发的系统中运用之外,还可以在其它运用程序中运用的程度。比起创建一个他计划只在一个运用程序中运用的组件,

10、开发可重用软件的费用会更大些。可重用软件必需规范化、资料齐全、不依赖于特定的运用程序和运转环境,并具有普通性。.12.可测试性可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。假设产品中包含复杂的算法和逻辑,或假设具有复杂的功能性的相互关系,那么对于可测试性的设计就很重要。假设经常更改产品,那么可测试性也是很重要的,由于将经常对产品进展回归测试来判别更改能否破坏了现有的功能性。.属性的取舍 有时,不可防止地要对一些特定的属性对进展取舍。用户和开发者必需确定哪些属性比其它属性更为重要,并定出优先级。 质量属性之间一些典型的相互关系单元格中的加号阐明单元格所在行的属性添加了对其所在列的属性

11、的积极影响。单元格中的减号阐明单元格所在行的属性添加了对其所在列的属性的不利影响。 .有效性高效性灵敏性完好性互操作性可维护性可移植性可靠性可重用性强壮性可测试性可用性可用性可测试性强壮性可重用性可靠性可移植性可维护性互操作性完好性灵敏性高效性有效性+-+-+-+质量属性之间典型的相互关系 + 积极影响- 不利影响.属性的取舍为了到达产品特性的最正确平衡,必需在需求获取阶段识别、确定相关的质量属性,并且为之确定优先级。当为工程定义重要的质量属性时,利用质量属性之间一些典型的相互关系图可以防止发生与目的冲突的行为。 .软件需求质量保证.八个需求质量属性正确的需求无歧义完好性一致性可验证可修正可跟

12、踪可了解性.1.正确的需求 一个SRS(需求集)是正确的,当且仅当其中每条需求都代表了要构造系统所要完成的事物。只是简单地在文档中写一些信息是不能保证正确的,任何自动设计工具也不能保证正确。 .需求和需求的全域在一个软件工程中经常发生的是脱漏区域A表示的信息,不测地把C区域表示的信息包括进来。区域C中所代表的信息能够是设计和实现细节,但也能够包含用户没有要求的需求。用户需要的全域 A正确的需求B需求C.正确需求的保证学习软件工程的领域知识由领域专家和用户参与需求任务经常与用户进展沟通掌握一定的需求获取和分析的方法和技术具备阅历证的需求构造框架执行根本的需求过程.2.无歧义的需求 假设工程开发人

13、员、用户以及其他风险承当人对一条需求有不同的解释,那么需求能够是有二义性的。只需需求是用自然言语书写的,二义性就会存在。.无歧义需求的保证无歧义需求保证的独一方法是对每项需求编写验收规范。验收规范是对需求的量化，是需求的度量方式。只需有能够验收规范就运用数字而不是单词来表达需求。验收规范是需求的度量方式，它使测试者可以确定提交的产品能否满足需求，不会引起任何客观的判别。不同类型的验收规范运用不同的度量尺度和度量方法并且包括业务允许的误差范围。.3.需求集的完好性 需求集完好的描画了用户关怀的一切有意义的需求,包括与功能、性能、设计约束、属性或外部接口有关的需求,还必需为需求集中一切的插图、表和

14、图以及一切名词和度量单元的定义提供完好的援用和标志。 .完好性的保证完好性的保证需求有一个需求集框架(模板)，它使得搜集一切的需求组成部分以得到完好的需求集变的比较容易。需求集框架是需求项集合的一个容器，框架确定了需求集和需求项的组成部分，可以运用该框架来协助检查需求集和需求项能否完好。.基于用例的需求集完好性框架 .4.需求集的一致性 需求集是内在一致的当且仅当其中没有单个需求的子集与另一个子集冲突(IEEE8301993)。冲突可以有多种方式而且在多种细节程度上可见。开发人员和非开发人员的手工评审是必要的,可以找到潜在的冲突。 .需求集非一致性的例子例如当X发生时,执行动作P,但需求的另一

15、部分能够说当X发生时,执行动作Q。有时,一个问题是冲突还是歧义性很难区分开。例如,在工资系统的需求的一部分能够会说“一切65岁以上的员工在年末应该得到1000元的奖励,需求的另一部分能够会说“一切有10年以上任务阅历的人在年未应得到500元的奖励。那么对同时满足这两个条件的员工应该怎样办? .保证一致性的方法为了指定只能以一种方式了解需求需求做两件事：在规格阐明书中对运用的术语进展定义，对它们的含义进展阐明(词汇术语表)。检查每项需求运用术语的方式都与它们的定义相符。.5.可验证的需求 需求必需是可验证的或“可测试的。“可验证的或可测试的需求合理的定义良好的无歧义的需求。假设需求是不可验证的,

16、那么阐明需求尚不明确，同时意味着缺乏开发根据,确认缺乏规范。验收规范和验证项有一定的区别,验收规范用于确认提交的软件最终产品,验证项用于确认需求。.可验证需求的保证可验证需求保证的独一方法是对每项需求编写足够的验证项并由用户参与对验证进展评审。.实例系统呼应恣意查询的时间应该小于500毫秒要根据恣意一词的详细含义来定。假设能够查询的范围是有限的,并且假设能确定最复杂的查询,就能验证系统的行为。 .无法验证和测试的需求时间的显示应该把数字显示得美丽一些。系统应该是用户友好的。如何对上述两条需求进展验证? .6.可修正的需求集 需求集的构造和风格可以对其中任一需求的变卦很容易地、完好地、一致地进展

17、,同时坚持己存在的需求集的构造和风格。.可修正需求集的保证开发团队一致的需求开发框架、规范、规范和模板。要求包含需求的包具有最小的冗余并且以恰当的目录、索引以及交叉援用的才干。开发团队一致的需求开发平台和集成工具。.7.可跟踪的需求从最初提出需求到最后需求的实现成为提交的任务产品,要阅历许多阶段，每个阶段都是一种转换。在转换过程中需求做为一种知识和信息,有能够由于开发人员的误解呵斥知识和信息的失真和衰减。可以把最初的需求与最后提交的产品中实现该需求的部分联络起来是很重要的。.可跟踪的需求 假设需求是可跟踪的，那么当更改发生时，找出产品的哪些部分将遭到更改的影响就更容易。确保需求可跟踪性意味着可以设计出最有效的方式来进展更改。.跟踪性的保证为了确认每项需求是可追踪的，必需具备：独一的需求标识需求或限制类型的阐明该需求所属的一切业务事件和用例的援用对其它有冲突需求的援用对该需求有某种更改影响的相关需求的援用一致的运用术语(用援用的方法运用术语).8.可了解的需求 用户和开发人员都能完全了解单个需求和需求集包含的全部功