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

501软件需求的质量保证北京航空航天大学软件工程研究所罗燕京[e-mail]502软件需求的质量保证•软件的质量属性•软件需求质量保证503软件的质量属性504软件的质量属性•质量属性是很难定义的•真正的现实系统中,在决定系统的成功或失败的因素中,满足非功能需求往往比满足功能需求更为重要。•如果开发者知道哪些特性对项目的成功至关重要,那么他们就能选择软件工程方法来达到特定的质量目标505质量属性分类•根据不同的设计可以把质量属性分类•一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开•另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开506每个项目都要考虑软件质量属性•对用户最重要的属性•有效性(availability)•高效性(efficiency)•灵活性(flexibility)•完整性(integrity)•互操作性(interoperability)•可靠性(reliability)•健壮性(robustness)•可用性(usability)•对开发者最重要的属性•可维护性(maintainability)•可移植性(portability)•可重用性(reusability)•可测试性(testability)507定义质量属性•必须根据用户对系统的期望来确定质量属性。•定量地确定重要属性提供了对用户期望的清晰理解,有助于设计者提出最合理的解决方案508定义质量属性的方法•想出对于不同的用户类可能很重要的属性,并根据每一个属性设计出许多问题。利用这些问题询问每一个用户类的代表,这些问题的回答有助于分析员决定哪些质量特性用作设计标准是最重要的。•可以把每个属性分成一级(不必多加考虑的属性)到五级(极其重要的属性)。509定义质量属性的方法•分析员与用户一起为每一属性确定特定的、可测量的和可验证的需求。•如果质量目标不可验证,那么就说不清你是否达到这些目标。•在合适的地方为每一个属性或目标指定级别或测量单位,以及最大和最小值。如果不能定量地确定某些对你的项目很重要的属性,那么至少应该确定其优先级。5010定义质量属性的方法•另一个定义属性的方法是确定任何与质量期望相冲突的系统行为。•通过定义一种反向需求,可以设计出强制系统表现出那些行为的测试用例。•如果不能强制系统,那么你可能达到了你的属性目标。•这种方法最适用于要求安全性能很高的应用程序,在这些应用程序中,系统的差错可能会导致致命危险。50111.有效性•有效性指的是在预定的启动时间中,系统真正可用并且完全运行时间所占的百分比。•更正式地说,有效性等于系统的平均故障时间(MTTF)除以平均故障时间与故障修复时间之和。•一个有效性需求可能这样说明:工作日期间,在当地时间早上6点到24点,系统的有效性至少达到99.5%,在14点到18点,系统的有效性至少可达到99.95%。50122.效率•效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。如果系统用完了所有可用的资源,那么用户遇到的将是性能的下降,这是效率降低的一个表现,拙劣的系统性能可能激怒等待数据库查询结果的用户,或者可能对系统安全性造成威胁。•就像一个实时处理系统超负荷一样。为了在不可预料的条件下允许安全缓冲,你可以这样定义:在预计的高峰负载条件下,10%处理器能力和15%系统可用内存必须留出备用。在定义性能、能力和效率目标时,考虑硬件的最小配置是很重要的。50133.灵活性•灵活性就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样,灵活性表明了在产品中增加新功能时所需工作量的大小。•灵活性对于通过一系列连续的发行版本,并采用渐增型和重复型方式开发的产品是很重要的。•实例:“一个至少具有6个月产品支持经验的软件维护程序员可以在4个小时之内为系统添加一个新格式的打印报表。50144.完整性(或安全性)•完整性(或安全性)主要涉及:防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。•完整性的需求不能犯任何错误,即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述完整性的需求,如身份验证、用户特权级别、访问约束或者需要保护的精确数据。•一个完整性的需求样本可以这样描述:只有拥有查账员访问特权的用户才可以查看客户交易历史。50155.互操作性•互操作性表明了产品与其它系统交换数据和服务的难易程度。•为了评估互操作性是否达到要求的程度,必须知道用户使用其它哪一种应用程序与你的产品相连接,还要知道他们要交换什么数据。50166.可靠性•可靠性是软件无故障执行一段时间的概率(健壮性和有效性有时可看成是可靠性的一部分)。•衡量软件可靠性的方法包括正确执行操作所占的比例,在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。•根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理,来定量地确定可靠性需求。如果软件满足了它的可靠性需求,那么即使该软件还存在缺陷,也可认为达到其可靠性目标。50177.健壮性•健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时,能继续正确运行功能的程度。•健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。•当从用户那里获取健壮性的目标时,询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。•定义实例：所有的输入参数都要指定一个缺省值,当输入数据丢失或无效时,就使用缺省值数据。50188.可用性(易用性)•可用性也称为易用性,它所描述的是许多组成用户友好的因素。•可用性衡量用户准备输入、操作和理解产品输出所花费的努力。•可用性的讨论可以得出可测量的目标,例如“一个培训过2小时的用户应该可以在平均3分钟或最多5分钟时间以内,完成从供应商目录中请求一种商品的操作。50199.可维护性•可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。•可维护性取决于理解软件、更改软件和测试软件的简易程度,可维护性与灵活性密切相关。•高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。你可以根据修复一个问题所花费的平均时间和修复正确的百分比来衡量可维护性。•例：对于现有报表的更改操作必须在一周内完成。502010.可移植性•可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。•软件可移植的设计方法与软件可重用的设计方法相似。•可移植性对于工程的成功是不重要的,对工程的结果也无关紧要。502111.可重用性•从软件开发的长远目标上看,可重用性表明一个软件组件除了在最初开发的系统中使用之外,还可以在其它应用程序中使用的程度。•比起创建一个你打算只在一个应用程序中使用的组件,开发可重用软件的费用会更大些。•可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境,并具有一般性。502212.可测试性•可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。•如果产品中包含复杂的算法和逻辑,或如果具有复杂的功能性的相互关系,那么对于可测试性的设计就很重要。•如果经常更改产品,那么可测试性也是很重要的,因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。5023属性的取舍•有时,不可避免地要对一些特定的属性对进行取舍。用户和开发者必须确定哪些属性比其它属性更为重要,并定出优先级。•质量属性之间一些典型的相互关系•单元格中的加号表明单元格所在行的属性增加了对其所在列的属性的积极影响。•单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。5024有效性高效性灵活性完整性互操作性可维护性可移植性可靠性可重用性健壮性可测试性可用性可用性可测试性健壮性可重用性可靠性可移植性可维护性互操作性完整性灵活性高效性有效性++++--------------------+++++++++++-------+++++++++--++++++++++++质量属性之间典型的相互关系+积极影响-不利影响5025属性的取舍•为了达到产品特性的最佳平衡,必须在需求获取阶段识别、确定相关的质量属性,并且为之确定优先级。•当为项目定义重要的质量属性时,利用质量属性之间一些典型的相互关系图可以防止发生与目标冲突的行为。5026软件需求质量保证5027八个需求质量属性•正确的需求•无歧义•完整性•一致性•可验证•可修改•可跟踪•可理解性50281.正确的需求•一个SRS(需求集)是正确的,当且仅当其中每条需求都代表了要构造系统所要完成的事物。•只是简单地在文档中写一些信息是不能保证正确的,任何自动设计工具也不能保证正确。5029需要和需求的全域•在一个软件项目中经常发生的是遗漏区域A表示的信息,意外地把C区域表示的信息包括进来。•区域C中所代表的信息可能是设计和实现细节,但也可能包含用户没有要求的需求。用户需要的全域A正确的需求B需求C5030正确需求的保证•学习软件项目的领域知识•由领域专家和用户参加需求工作•经常与用户进行沟通•掌握一定的需求获取和分析的方法和技术•具备经验证的需求结构框架•执行基本的需求过程50312.无歧义的需求•如果项目开发人员、用户以及其他风险承担人对一条需求有不同的解释,那么需求可能是有二义性的。•只要需求是用自然语言书写的,二义性就会存在。5032无歧义需求的保证•无歧义需求保证的唯一方法是对每项需求编写验收标准。•验收标准是对需求的量化，是需求的度量方式。只要有可能验收标准就使用数字而不是单词来表达需求。•验收标准是需求的度量方式，它使测试者能够确定提交的产品是否满足需求，不会引起任何主观的判断。•不同类型的验收标准使用不同的度量尺度和度量方法并且包括业务允许的误差范围。50333.需求集的完整性•需求集完整的描述了用户关心的所有有意义的需求,包括与功能、性能、设计约束、属性或外部接口有关的需求,还必须为需求集中所有的插图、表和图以及所有名词和度量单元的定义提供完整的引用和标记。5034完整性的保证•完整性的保证需要有一个需求集框架(模板)，它使得收集所有的需求组成部分以得到完整的需求集变的比较容易。•需求集框架是需求项集合的一个容器，框架确定了需求集和需求项的组成部分，可以使用该框架来帮助检查需求集和需求项是否完整。5035基于用例的需求集完整性框架50364.需求集的一致性•需求集是内在一致的当且仅当其中没有单个需求的子集与另一个子集冲突(IEEE830·1993)。冲突可以有多种形式而且在多种细节程度上可见。•开发人员和非开发人员的手工评审是必要的,能够找到潜在的冲突。5037需求集非一致性的例子•例如当X发生时,执行动作P,但需求的另一部分可能说当X发生时,执行动作Q。•有时,一个问题是冲突还是歧义性很难区分开。•例如,在工资系统的需求的一部分可能会说“所有65岁以上的员工在年末应该得到1000元的奖励”,需求的另一部分可能会说“所有有10年以上工作经历的人在年未应得到500元的奖励。那么对同时满足这两个条件的员工应该怎么办?5038保证一致性的方法•为了指定只能以一种方式理解需求需要做两件事：–在规格说明书中对使用的术语进行定义，对它们的含义进行说明(词汇术语表)。–检查每项需求使用术语的方式都与它们的定义相符。50395.可验证的需求•需求必须是可验证的或“可测试的”。•“可验证的或可测试的”需要合理的定义良好的无歧义的需求。•如果需求是不可验证的,则说明需求尚不明确，同时意味着缺乏开发依据,确认缺乏标准。•验收标准和验证项有一定的区别,验收标准用于确认提交的软件最终产品,验证项用于确认需求。5040可验证需求的保证•可验证需求保证的唯一方法是对每项需求编写足够的验证项并由用户参加对验证进行评审。5041实例•系统响应任意查询的时间应该小于500毫秒–要根据‘任意’一词的具体含义来定。–如果可能查询的范围是有限的,并且如果能确定最复杂的查询,就能验证系统的行为。5042无法验证和测试的需求•时间的显示应该把数字显示得漂亮一些。•系统