软件需求的质量保证

《软件需求的质量保证》由会员分享，可在线阅读，更多相关《软件需求的质量保证（50页珍藏版）》请在金锄头文库上搜索。

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

2、分开 550每个项目都要考虑软件质量属性 对用户最重要的属性 有效性(availability) 高效性(efficiency) 灵活性(flexibility) 完整性(integrity) 互操作性 (interoperability) 可靠性(reliability) 健壮性(robustness) 可用性(usability) 对开发者最重要的属性 可维护性(maintainability) 可移植性(portability) 可重用性(reusability) 可测试性(testability)650定义质量属性 必须根据用户对系统的期望来确定质量 属性。 定量地确定重要属性提供了对

3、用户期望 的清晰理解,有助于设计者提出最合理的 解决方案 750定义质量属性的方法 想出对于不同的用户类可能很重要的属 性,并根据每一个属性设计出许多问题。 利用这些问题询问每一个用户类的代表, 这些问题的回答有助于分析员决定哪些 质量特性用作设计标准是最重要的。 可以把每个属性分成一级(不必多加考虑 的属性)到五级(极其重要的属性)。850定义质量属性的方法 分析员与用户一起为每一属性确定特定 的、可测量的和可验证的需求。 如果质量目标不可验证,那么就说不清你 是否达到这些目标。 在合适的地方为每一个属性或目标指定 级别或测量单位,以及最大和最小值。如 果不能定量地确定某些对你的项目很重 要

4、的属性,那么至少应该确定其优先级。 950定义质量属性的方法 另一个定义属性的方法是确定任何与质量期望 相冲突的系统行为。 通过定义一种反向需求,可以设计出强制系统表 现出那些行为的测试用例。 如果不能强制系统,那么你可能达到了你的属性 目标。 这种方法最适用于要求安全性能很高的应用程 序,在这些应用程序中,系统的差错可能会导致 致命危险。10501.有效性 有效性指的是在预定的启动时间中,系统真正可 用并且完全运行时间所占的百分比。 更正式地说,有效性等于系统的平均故障时间 (MTTF)除以平均故障时间与故障修复时间之和 。 一个有效性需求可能这样说明:“工作日期间,在 当地时间早上6点到2

5、4点,系统的有效性至少达 到99.5%,在14点到18点,系统的有效性至少可达 到99.95%。 11502.效率 效率是用来衡量系统如何优化处理器、磁盘空间或通 信带宽的。如果系统用完了所有可用的资源,那么用户 遇到的将是性能的下降,这是效率降低的一个表现,拙劣 的系统性能可能激怒等待数据库查询结果的用户,或者 可能对系统安全性造成威胁。 就像一个实时处理系统超负荷一样。为了在不可预料 的条件下允许安全缓冲,你可以这样定义:“在预计的高 峰负载条件下,10%处理器能力和15%系统可用内存必 须留出备用。“在定义性能、能力和效率目标时,考虑硬 件的最小配置是很重要的。12503.灵活性 灵活性

6、就像我们所知道的可扩充性、增加性、 可延伸性和可扩展性一样,灵活性表明了在产品 中增加新功能时所需工作量的大小。 灵活性对于通过一系列连续的发行版本,并采用 渐增型和重复型方式开发的产品是很重要的。 实例:“一个至少具有6个月产品支持经验的软件 维护程序员可以在4个小时之内为系统添加一 个新格式的打印报表。“13504.完整性(或安全性) 完整性(或安全性)主要涉及:防止非法访问系统 功能、防止数据丢失、防止病毒入侵并防止私 人数据进入系统。 完整性的需求不能犯任何错误,即数据和访问必 须通过特定的方法完全保护起来。用明确的术 语陈述完整性的需求,如身份验证、用户特权级 别、访问约束或者需要保

7、护的精确数据。 一个完整性的需求样本可以这样描述:“只有拥 有查账员访问特权的用户才可以查看客户交易 历史。“14505.互操作性 互操作性表明了产品与其它系统交换数 据和服务的难易程度。 为了评估互操作性是否达到要求的程度, 必须知道用户使用其它哪一种应用程序 与你的产品相连接,还要知道他们要交换 什么数据。15506.可靠性 可靠性是软件无故障执行一段时间的概率(健壮 性和有效性有时可看成是可靠性的一部分)。 衡量软件可靠性的方法包括正确执行操作所占 的比例,在发现新缺陷之前系统运行的时间长度 和缺陷出现的密度。 根据如果发生故障对系统有多大影响和对于最 大的可靠性的费用是否合理,来定量地

8、确定可靠 性需求。如果软件满足了它的可靠性需求,那么 即使该软件还存在缺陷,也可认为达到其可靠性 目标。16507.健壮性 健壮性指的是当系统或其组成部分遇到非法输 入数据、相关软件或硬件组成部分的缺陷或异 常的操作情况时,能继续正确运行功能的程度。 健壮的软件可以从发生问题的环境中完好地恢 复并且可容忍用户的错误。 当从用户那里获取健壮性的目标时,询问系统可 能遇到的错误条件并且要了解用户想让系统如 何响应。 定义实例：所有的输入参数都要指定一个缺省 值,当输入数据丢失或无效时,就使用缺省值数 据。 17508.可用性(易用性) 可用性也称为易用性,它所描述的是许多 组成用户友好的因素。 可

9、用性衡量用户准备输入、操作和理解 产品输出所花费的努力。 可用性的讨论可以得出可测量的目标,例 如“一个培训过2小时的用户应该可以在 平均3分钟或最多5分钟时间以内,完成从 供应商目录中请求一种商品的操作。“18509.可维护性 可维护性表明了在软件中纠正一个缺陷或做一 次更改的简易程度。 可维护性取决于理解软件、更改软件和测试软 件的简易程度,可维护性与灵活性密切相关。 高可维护性对于那些经历周期性更改的产品或 快速开发的产品很重要。你可以根据修复一个 问题所花费的平均时间和修复正确的百分比来 衡量可维护性。 例：对于现有报表的更改操作必须在一周内完 成。 195010.可移植性 可移植性是

10、度量把一个软件从一种运行 环境转移到另一种运行环境中所花费的 工作量。 软件可移植的设计方法与软件可重用的 设计方法相似。 可移植性对于工程的成功是不重要的,对 工程的结果也无关紧要。205011.可重用性 从软件开发的长远目标上看,可重用性表明一个 软件组件除了在最初开发的系统中使用之外,还 可以在其它应用程序中使用的程度。 比起创建一个你打算只在一个应用程序中使用 的组件,开发可重用软件的费用会更大些。 可重用软件必须标准化、资料齐全、不依赖于 特定的应用程序和运行环境,并具有一般性。215012.可测试性 可测试性指的是测试软件组件或集成产 品时查找缺陷的简易程度。 如果产品中包含复杂的

11、算法和逻辑,或如 果具有复杂的功能性的相互关系,那么对 于可测试性的设计就很重要。 如果经常更改产品,那么可测试性也是很 重要的,因为将经常对产品进行回归测试 来判断更改是否破坏了现有的功能性。2250属性的取舍 有时,不可避免地要对一些特定的属性对进行取 舍。用户和开发者必须确定哪些属性比其它属 性更为重要,并定出优先级。 质量属性之间一些典型的相互关系 单元格中的加号表明单元格所在行的属性增加 了对其所在列的属性的积极影响。 单元格中的减号表明单元格所在行的属性增加 了对其所在列的属性的不利影响。 2350有效性 高效性 灵活性 完整性 互操作性 可维护性 可移植性 可靠性 可重用性 健壮

12、性 可测试性 可用性可用性 可测试性 健壮性 可重用性 可靠性 可移植性 可维护性 互操作性 完整性 灵活性 高效性 有效性+ +- - - - -+ -+ + +-+质量属性之间典型的相互关系 + 积极影响 - 不利影响2450属性的取舍 为了达到产品特性的最佳平衡,必须在需 求获取阶段识别、确定相关的质量属性, 并且为之确定优先级。 当为项目定义重要的质量属性时,利用质 量属性之间一些典型的相互关系图可以 防止发生与目标冲突的行为。 2550软件需求质量保证2650八个需求质量属性 正确的需求 无歧义 完整性 一致性 可验证 可修改 可跟踪 可理解性27501.正确的需求 一个SRS(需求

13、集)是正确的,当且仅当其 中每条需求都代表了要构造系统所要完 成的事物。 只是简单地在文档中写一些信息是不能 保证正确的,任何自动设计工具也不能保 证正确。 2850需要和需求的全域 在一个软件项目中经 常发生的是遗漏区域A 表示的信息,意外地把 C区域表示的信息包括 进来。 区域C中所代表的信息 可能是设计和实现细 节,但也可能包含用户 没有要求的需求。用户需 要的全 域 A正确 的需 求B需求 C2950正确需求的保证 学习软件项目的领域知识 由领域专家和用户参加需求工作 经常与用户进行沟通 掌握一定的需求获取和分析的方法和技 术 具备经验证的需求结构框架 执行基本的需求过程30502.无

14、歧义的需求 如果项目开发人员、用户以及其他风险 承担人对一条需求有不同的解释,那么需 求可能是有二义性的。 只要需求是用自然语言书写的,二义性就 会存在。3150无歧义需求的保证 无歧义需求保证的唯一方法是对每项需求编写 验收标准。 验收标准是对需求的量化，是需求的度量方式 。只要有可能验收标准就使用数字而不是单词 来表达需求。 验收标准是需求的度量方式，它使测试者能够 确定提交的产品是否满足需求，不会引起任何 主观的判断。 不同类型的验收标准使用不同的度量尺度和度 量方法并且包括业务允许的误差范围。32503.需求集的完整性 需求集完整的描述了用户关心的所有有 意义的需求,包括与功能、性能、

15、设计约 束、属性或外部接口有关的需求,还必须 为需求集中所有的插图、表和图以及所 有名词和度量单元的定义提供完整的引 用和标记。 3350完整性的保证 完整性的保证需要有一个需求集框架(模 板)，它使得收集所有的需求组成部分以 得到完整的需求集变的比较容易。 需求集框架是需求项集合的一个容器， 框架确定了需求集和需求项的组成部分 ，可以使用该框架来帮助检查需求集和 需求项是否完整。3450基于用例的需求集完整性框架35504.需求集的一致性 需求集是内在一致的当且仅当其中没有 单个需求的子集与另一个子集冲突 (IEEE8301993)。冲突可以有多种形式 而且在多种细节程度上可见。 开发人员和非开发人员的手工评审是必 要的,能够找到潜在的冲突。 3650需求集非一致性的例子 例如“当X发生时,执行动作P“,但需求的另一部 分可能说“当X发生时,执行动作Q“。 有时,一个问题是冲突还是歧义性很难区分开 。 例如,在工资系统的需求的一部分可能会说“ 所有65岁以上的员工在年末应该得到1000元的 奖励”,需求的另一部分可能会说“所有有10 年以上工作经历的人在年未应得到500元的奖 励“。那么对同时满足这两个条件的员工应该 怎么办? 3750保证一致性