软件需求的质量保证--PPT课件要点优秀PPT.ppt

软件需求的质量保证软件需求的质量保证 北京航空航天高校软件工程探讨所北京航空航天高校软件工程探讨所 罗燕京罗燕京 2006.1 2006.1 Luo_yanjingsina Luo_yanjingsina 150软件需求的质量软件需求的质量保证保证软件的质量属性软件的质量属性软件软件需求质量需求质量保证保证250软件的质量属性软件的质量属性350软件的质量属性软件的质量属性质量属性是很难定义的真正的现实系统中,在确定系统的成功或失败的因素中,满足非功能需求往往比满足功能需求更为重要。假如开发者知道哪些特性对项目的成功至关重要,那么他们就能选择软件工程方法来达到特定的质量目标 450质量属性分类质量属性分类依据不同的设计可以把质量属性分类一种属性分类的方法是把在运行时可识别的特性与那些不行识别的特性区分开另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不行见特性区分开 550每个项目都要考虑软件质量属性每个项目都要考虑软件质量属性 对用户最重要的属性对用户最重要的属性有效性有效性(availability)高效性高效性(efficiency)敏捷性敏捷性(flexibility)完整性完整性(integrity)互操作性互操作性(interoperability)牢靠性牢靠性(reliability)健壮性健壮性(robustness)可用性可用性(usability)对开发者最重要的属性对开发者最重要的属性可维护性(maintainability)可移植性(portability)可重用性(reusability)可测试性(testability)650定义质量属性定义质量属性 必需依据用户对系统的期望来确定质量属性。定量地确定重要属性供应了对用户期望的清晰理解,有助于设计者提出最合理的解决方案 750定义质量属性的方法定义质量属性的方法 想出对于不同的用户类可能很重要的属性,并依据每一个属性设计出很多问题。利用这些问题询问每一个用户类的代表,这些问题的回答有助于分析员确定哪些质量特性用作设计标准是最重要的。可以把每个属性分成一级(不必多加考虑的属性)到五级(极其重要的属性)。850定义质量属性的方法定义质量属性的方法 分析员与用户一起为每一属性确定特定的、可测量的和可验证的需求。假如质量目标不行验证,那么就说不清你是否达到这些目标。在合适的地方为每一个属性或目标指定级别或测量单位,以及最大和最小值。假如不能定量地确定某些对你的项目很重要的属性,那么至少应当确定其优先级。950定义质量属性的方法定义质量属性的方法另一个定义属性的方法是确定任何与质量期望相冲突的系统行为。通过定义一种反向需求,可以设计出强制系统表现出那些行为的测试用例。假如不能强制系统,那么你可能达到了你的属性目标。这种方法最适用于要求平安性能很高的应用程序,在这些应用程序中,系统的差错可能会导致致命危急。10501.1.有效性有效性有效性指的是在预定的启动时间中,系统真正可用并且完全运行时间所占的百分比。更正式地说,有效性等于系统的平均故障时间(MTTF)除以平均故障时间与故障修复时间之和。一个有效性需求可能这样说明:工作日期间,在当地时间早上6点到24点,系统的有效性至少达到99.5%,在14点到18点,系统的有效性至少可达到99.95%。11502.2.效率效率效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。假如系统用完了全部可用的资源,那么用户遇到的将是性能的下降,这是效率降低的一个表现,拙劣的系统性能可能激怒等待数据库查询结果的用户,或者可能对系统平安性造成威逼。就像一个实时处理系统超负荷一样。为了在不行预料的条件下允许平安缓冲,你可以这样定义:在预料的高峰负载条件下,10%处理器实力和15%系统可用内存必需留出备用。在定义性能、实力和效率目标时,考虑硬件的最小配置是很重要的。12503.3.敏捷性敏捷性敏捷性就像我们所知道的可扩充性、增加性、可延长性和可扩展性一样,敏捷性表明白在产品中增加新功能时所需工作量的大小。敏捷性对于通过一系列连续的发行版本,并接受渐增型和重复型方式开发的产品是很重要的。实例:“一个至少具有6个月产品支持阅历的软件维护程序员可以在4个小时之内为系统添加一个新格式的打印报表。13504.4.完整性完整性(或平安性或平安性)完整性(或平安性)主要涉及:防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。完整性的需求不能犯任何错误,即数据和访问必需通过特定的方法完全爱护起来。用明确的术语陈述完整性的需求,如身份验证、用户特权级别、访问约束或者须要爱护的精确数据。一个完整性的需求样本可以这样描述:只有拥有查账员访问特权的用户才可以查看客户交易历史。14505.5.互操作性互操作性互操作性表明白产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度,必需知道用户运用其它哪一种应用程序与你的产品相连接,还要知道他们要交换什么数据。15506.6.牢靠性牢靠性牢靠性是软件无故障执行一段时间的概率(健壮性和有效性有时可看成是牢靠性的一部分)。衡量软件牢靠性的方法包括正确执行操作所占的比例,在发觉新缺陷之前系统运行的时间长度和缺陷出现的密度。依据假如发生故障对系统有多大影响和对于最大的牢靠性的费用是否合理,来定量地确定牢靠性需求。假如软件满足了它的牢靠性需求,那么即使该软件还存在缺陷,也可认为达到其牢靠性目标。16507.7.健壮性健壮性健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异样的操作状况时,能接着正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地复原并且可容忍用户的错误。当从用户那里获得健壮性的目标时,询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。定义实例：全部的输入参数都要指定一个缺省值,当输入数据丢失或无效时,就运用缺省值数据。17508.8.可用性可用性(易用性易用性)可用性也称为易用性,它所描述的是很多组成用户友好的因素。可用性衡量用户准备输入、操作和理解产品输出所花费的努力。可用性的探讨可以得出可测量的目标,例如“一个培训过2小时的用户应当可以在平均3分钟或最多5分钟时间以内,完成从供应商书目中恳求一种商品的操作。18509.9.可维护性可维护性可维护性表明白在软件中订正一个缺陷或做一次更改的简易程度。可维护性取决于理解软件、更改软件和测试软件的简易程度,可维护性与敏捷性亲密相关。高可维护性对于那些经验周期性更改的产品或快速开发的产品很重要。你可以依据修复一个问题所花费的平均时间和修复正确的百分比来衡量可维护性。例：对于现有报表的更改操作必需在一周内完成。195010.10.可移植性可移植性可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相像。可移植性对于工程的成功是不重要的,对工程的结果也无关紧要。205011.11.可重用性可重用性从软件开发的长远目标上看,可重用性表明一个软件组件除了在最初开发的系统中运用之外,还可以在其它应用程序中运用的程度。比起创建一个你准备只在一个应用程序中运用的组件,开发可重用软件的费用会更大些。可重用软件必需标准化、资料齐全、不依靠于特定的应用程序和运行环境,并具有一般性。215012.12.可测试性可测试性可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。假如产品中包含困难的算法和逻辑,或假如具有困难的功能性的相互关系,那么对于可测试性的设计就很重要。假如常常更改产品,那么可测试性也是很重要的,因为将常常对产品进行回来测试来推断更改是否破坏了现有的功能性。2250属性的取舍属性的取舍 有时,不行避开地要对一些特定的属性对进行取舍。用户和开发者必需确定哪些属性比其它属性更为重要,并定出优先级。质量属性之间一些典型的相互关系单元格中的加号表明单元格所在行的属性增加了对其所在列的属性的主动影响。单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。2350有效性有效性高效性高效性灵活性灵活性完整性完整性互操作性互操作性可维护性可维护性可移植性可移植性可靠性可靠性可重用性可重用性健壮性健壮性可测试性可测试性可用性可用性可可用用性性可可测测试试性性健健壮壮性性可可重重用用性性可可靠靠性性可可移移植植性性可可维维护护性性互互操操作作性性完完整整性性灵灵活活性性高高效效性性有有效效性性+-+-+-+质质量量属属性性之之间间典典型型的的相相互互关关系系+主动影响主动影响-不利影响不利影响2450属性的取舍属性的取舍为了达到产品特性的最佳平衡,必需在需求获得阶段识别、确定相关的质量属性,并且为之确定优先级。当为项目定义重要的质量属性时,利用质量属性之间一些典型的相互关系图可以防止发生与目标冲突的行为。2550软件软件需求质量需求质量保证保证2650八个需求质量属性八个需求质量属性正确的需求正确的需求无歧义无歧义完整性完整性一样性一样性可验证可验证可修改可修改可跟踪可跟踪可理解性可理解性27501.1.正确的需求正确的需求 一个SRS(需求集)是正确的,当且仅当其中每条需求都代表了要构造系统所要完成的事物。只是简洁地在文档中写一些信息是不能保证正确的,任何自动设计工具也不能保证正确。2850须要和需求的全域须要和需求的全域在一个软件项目中常常发生的是遗漏区域A表示的信息,意外地把C区域表示的信息包括进来。区域C中所代表的信息可能是设计和实现细微环节,但也可能包含用户没有要求的需求。用户需用户需要的全要的全域域 A正确正确的需的需求求B需求需求C2950正确需求的保证正确需求的保证学习软件项目的领域学问由领域专家和用户参与需求工作常常与用户进行沟通驾驭确定的需求获得和分析的方法和技术具备阅历证的需求结构框架执行基本的需求过程30502.2.无歧义的需求无歧义的需求 假如项目开发人员、用户以及其他风险担当人对一条需求有不同的说明,那么需求可能是有二义性的。只要需求是用自然语言书写的,二义性就会存在。3150无歧义需求的保证无歧义需求的保证无歧义需求保证的唯一方法是对每项需求编写验收标准。验收标准是对需求的量化，是需求的度量方式。只要有可能验收标准就运用数字而不是单词来表达需求。验收标准是需求的度量方式，它使测试者能够确定提交的产品是否满足需求，不会引起任何主观的推断。不同类型的验收标准运用不同的度量尺度和度量方法并且包括业务允许的误差范围。32503.3.需求集的完整性需求集的完整性 需求集完整的描述了用户关切的全部有意义的需求,包括与功能、性能、设计约束、属性或外部接口有关的需求,还必需为需求集中全部的插图、表和图以及所出名词和度量单元的定义供应完整的引用和标记。3350完整性的保证完整性的保证完整性的保证须要有一个需求集框架(模板)，它使得收集全部的需求组成部分以得到完整的需求集变的比较简洁。需求集框架是需求项集合的一个容器，框架确定了需求集和需求项的组成部分，可以运用该框架来帮助检查需求集和需求项是否完整。3450基于用例的需求基于用例的需求集集完整性框架完整性框架 35504.4.需求集的一样性需求集的一样性 需求集是内在一样的当且仅当其中没有单个需求的子集与另一个子集冲突(IEEE8301993)。冲突可以有多种形式而且在多种细微环节程度上可见。开发人员和非开发人员的手工评审是必要的,能够找到潜在的冲突。3650需求集非一样性的例子需求集非一样性的例子例如例如 当当X X发生时发生时,执行动作执行动作P,P,但需求的另一部但需求的另一部分可能说分可能说 当当X X发生时发生时,执行动作执行动作QQ。有时有时,一个问题是冲突还是歧义性很难区分开。一个问题是冲突还是歧义性很难区分开。例如例如,在工资系统的需求的一部分可能会说在工资系统的需求的一部分可能会说“全部全部6565岁以上的员工在年末应当得到岁以上的员工在年末应当得到10001000元的元的嘉奖嘉奖”,”,需求的另一部分可能会说需求的另一部分可能会说“全部有全部有1010年以上工作经验的人在年未应得到年以上工作经验的人在年未应得到500500元的嘉元的嘉奖奖。那么对同时满足这两个条件的员工应当。那么对同时满足这两个条件的员工应当怎么办怎么办?3750保证一样性的方法保证一样性的方法为了指定只能以一种方式理解需求须要做两件事：在规格说明书中对运用的术语进行定义，对它们的含义进行说明(词汇术语表)。检查每项需求运用术语的方式都与它们的定义相符。38505.5.可验证的需求可验证的需求 需求必需是可验证的或“可测试的”。“可验证的或可测试的”须要合理的定义良好的无歧义的需求。假如需求是不行验证的,则说明需求尚不明确，同时意味着缺乏开发依据,确认缺乏标准。验收标准和验证项有确定的区分,验收标准用于确认提交的软件最终产品,验证项用于确认需求。3950可验证需求的保证可验证需求的保证可验证需求保证的唯一方法是对每项需求编写足够的验证项并由用户参与对验证进行评审。4050实例实例系统响应随意查询的时间应当小于500毫秒要依据随意一词的具体含义来定。假如可能查询的范围是有限的,并且假如能确定最困难的查询,就能验证系统的行为。4150无法验证和测试的需求无法验证和测试的需求时间的显示应当把数字显示得美丽一些。系统应当是用户友好的。如何对上述两条需求进行验证?42506.6.可修改的需求集可修改的需求集 需求集的结构和风格可以对其中任一需求的变更很简洁地、完整地、一样地进行,同时保持己存在的需求集的结构和风格。4350可修改需求集的保证可修改需求集的保证开发团队统一的需求开发框架、标准、规范和模板。要求包含需求的包具有最小的冗余并且以恰当的书目、索引以及交叉引用的实力。开发团队统一的需求开发平台和集成工具。44507.7.可跟踪的需求可跟踪的需求从最初提出需求到最终需求的实现成为提交的工作产品,要经验很多阶段，每个阶段都是一种转换。在转换过程中需求做为一种学问和信息,有可能因为开发人员的误会造成学问和信息的失真和衰减。能够把最初的需求与最终提交的产品中实现该需求的部分联系起来是很重要的。4550可跟踪的需求可跟踪的需求 假如需求是可跟踪的，那么当更改发生时，找出产品的哪些部分将受到更改的影响就更简洁。确保需求可跟踪性意味着可以设计出最有效的方式来进行更改。4650跟踪性的保证跟踪性的保证为了确认每项需求是可追踪的，必需具备：唯一的需求标识需求或限制类型的说明该需求所属的全部业务事务和用例的引用对其它有冲突需求的引用对该需求有某种更改影响的相关需求的引用一样的运用术语(用引用的方法运用术语)47508.8.可理解的需求可理解的需求 用户和开发人员都能完全理解单个需求和需求集包含的全部功能。当我们细化系统定义即产生具体需求时,各种描述更加明确和具体 写需求的人必需理解全部读者的专业词汇、术语和文化。需求集的用户是否能从整体上理解系统的行为也特别重要。可以通过供应场景或说明性用例展示系统在运行环境的运用来实现。4850可理解性的保证可理解性的保证构造对于不同涉众理解的四种模型：业务模型面对客户和用户的模型(企事业过程模型EPMS)需求模型面对客户和分析人员的模型(用例模型+验证模型)分析模型面对设计人员的模型(静态和动态模型)设计模型面对实现人员的模型(具体设计模型)4950END北京航空航天高校软件工程探讨所北京航空航天高校软件工程探讨所 罗燕京罗燕京 Luo_yanjingsina Luo_yanjingsina 5050