软件的质量属性

虽然产品特性有很多，但在许多系统中，只有一小部分需要被认真考虑。如果开发者知道哪些特性对项目的成功至关重要，他们就能选择软件工程方法来达到特定的质量目标。根据不同的设计，可以把质量属性分类。一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开。另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。

对用户最重要的属性	对开发者最重要的属性
有效性（availability）	可维护性（maintainability）
高效性（efficiency）	可移植性（portability）
灵活性（flexibility）	可重用性（reusability）
完整性（integrity）	可测试性（testability）
互操作性（interoperability）
可靠性（reliability）
健壮性（robustness）
可用性（usability）

产品的不同部分与所期望的质量特性有着不同的组合。高效性可能对某些部分是很重要的，而可用性对其它部分则很重要。把应用于整个产品的质量特性与特定某些部分、某些用户类或特殊使用环境的质量属性要区分开。把任何全局属性需求记录到软件需求规格说明中，并把特定的目标和软件需求规格说明的特性、使用实例或功能需求相联系起来。

1. 定义质量属性

确定质量属性时，必须基于用户对系统的期望。定量地确定重要属性有助于明确用户期望，帮助设计者提出最合理的解决方案。然而，大多数用户不知道如何回答诸如“互操作性对你的重要性如何？”或者“软件应该具有怎样的可靠性？”等问题。

在一个项目中，分析员想出了对于不同用户类可能很重要的属性，并根据每一个属性设计了许多问题。他们利用这些问题询问每一个用户类的代表，将每个属性分为一到五级（极其重要的属性）。这些问题的回答有助于分析员确定哪些质量特性用作设计标准是最重要的。

然后，分析员与用户一起为每一属性确定特定的、可测量的和可验证的需求。如果质量目标不可验证，那么就说不清是否达到了这些目标。在合适的地方为每一个属性或目标指定级别或测量单位，以及最大和最小值。如果不能定量地确定某些对项目很重要的属性，那么至少应该确定其优先级。IEEE 关于软件质量度量方法的标准提出了一个在综合质量度量基准体系下定义软件质量需求的方法。

另一个定义属性的方法是确定任何与质量期望相冲突的系统行为。

通过定义不希望发生的行为（反向需求），可以设计出强制系统表现出这些行为的测试用例。如果不能强制系统发生这些行为，那么就可能达到了你的属性目标。这种方法最适用于安全性能要求高的应用程序，在这些应用程序中，系统的差错可能会导致生命危险。

2. 对用户重要的属性

1) 有效性。

有效性是指在预定的启动时间内，系统真正可用且完全运行的时间占比。正式地说，有效性等于系统的平均故障时间（MTTF）除以平均故障时间与故障修复时间之和。有些任务对时间的要求比其他任务更严格，如果用户在执行任务时系统不可用，用户会感到很沮丧。因此，需要询问用户对有效性的需求，以及是否在任何时间都需要满足业务或安全目标。

一个有效性需求的说明可能是：“在工作日的当地时间早上 6 点到午夜，系统的有效性至少达到 99.5%，下午 4 点到 6 点，系统的有效性至少达到 99.95%。”

2) 效率。

效率是衡量系统如何充分利用处理器、磁盘空间或通信带宽的指标。如果系统用尽了所有可用的资源，那么用户可能会遇到性能下降的情况，这是效率降低的表现。拙劣的系统性能可能会激怒等待数据库查询结果的用户，或者可能会对系统的安全性造成威胁，就像一个实时处理系统超负荷一样。为了在不可预见的情况下允许安全缓冲，可以这样定义：“在预期的高峰负载条件下，必须留出 10%的处理器能力和 15%的系统可用内存作为备用。”在定义性能、能力和效率目标时，考虑硬件的最小配置非常重要。

3) 灵活性

灵活性和我们所知道的可扩充性、增加性、可延伸性、可扩展性类似，它表示在产品中添加新功能时所需的工作量大小。如果开发者能够预见到系统的扩展性，那么他们可以选择合适的方法来最大限度地提高系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品非常重要。

例如：“一位至少有 6 个月相关工作经验的软件维护工程师，可以在一小时内为系统添加一个新的可支持打印输出的设备。”

4) 完整性。

完整性（或安全性）主要涉及四个方面：防止非法访问系统功能、防止数据丢失、防止病毒入侵以及防止私人数据进入系统。完整性对于通过 WWW 执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息，Web 的浏览者不愿意自己的私人信息或访问记录被非法使用。完整性的需求必须万无一失，即数据和访问必须通过特定的方法受到完全保护。

用准确的术语来陈述完整性的需求，例如身份验证、用户特权级别、访问约束或者需要保护的确切数据。一个完整性需求的示例可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”

5) 互操作性。

互操作性表明了产品与其他系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，你必须知道用户使用哪些其他应用程序与你的产品相连接，以及他们要交换哪些数据。“文字处理系统”的用户习惯于使用一些商业工具绘制组织结构图，所以他们提出了如下的互操作性需求：“文字处理系统应该能够从 Microsoft Visio 和 SmartDraw 工具中导入任何有效组织结构图。”

6) 可靠性。

可靠性是软件在一段时间内无故障执行的概率）。健壮性和有效性有时可视为可靠性的一部分。衡量软件可靠性的方法包括正确执行操作的比例、在发现新缺陷之前系统运行的时间长度以及缺陷出现的密度。根据故障对系统的影响程度以及为实现最大可靠性而付出的成本是否合理，来定量地确定可靠性需求。如果软件满足其可靠性需求，那么即使该软件仍然存在缺陷，也可以认为它达到了其可靠性目标。

7) 健壮性。

健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能够继续正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地恢复，并且可以容忍用户的错误。当从用户那里获取健壮性目标时，需要询问系统可能遇到的错误条件，以及了解用户希望系统如何响应。

8) 可用性。

可用性也称为“易用性”和“人类工程学”，它描述了许多构成“用户友好”的因素。可用性衡量准备输入、操作和理解产品输出所花费的努力。你必须权衡易用性和学习如何操作产品的简易性。“文字处理系统”的分析员向用户询问这样的问题：“你能否快速、简单地创建、编辑和格式化文档，这对你有多重要？”和“你创建一个新文档大概需要多少时间？”对于定义使软件易于使用的许多特性而言，这只是一个简单的起点。对于可用性的讨论可以得出可衡量的目标，例如“一个受过培训的用户应该能够在平均 3 分钟或最多 5 分钟的时间内，完成创建一个新文档的操作。”

3. 对开发者重要的属性

1) 可维护性。

可维护性表明了在软件中纠正一个缺陷或进行一次更改的难易程度。可维护性取决于理解软件、更改软件和测试软件的难易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品非常重要。你可以根据修复一个问题所花费的平均时间和修复正确的百分比来衡量可维护性。

2) 可移植性。

可移植性是衡量将一个软件从一种运行环境转移到另一种运行环境所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似。可移植性对于工程的成功并不重要，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其他环境的那一部分，并确定相应的目标环境。因此，开发者可以选择设计和编码方法，以适当提高产品的可移植性。

3) 可重用性。

从软件开发的长远目标来看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其他应用程序中使用的程度。与创建一个你只打算在一个应用程序中使用的组件相比，开发可重用软件的成本会更高。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有通用性。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。

4) 可测试性。

可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也很重要，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。

4. 属性的取舍

有时，不可避免地要对一些特定的属性进行取舍。用户和开发者必须确定哪些属性比其他属性更为重要，并确定优先级。在他们做决策时，要始终遵照那些优先级。

例如，增强软件可重用性的设计方法也可以使软件变得灵活、更易于与其他软件组件相连接、更易于维护、更易于移植并且更易于测试。一个单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。高效性对其他许多属性具有消极影响。如果你编写最紧凑、最快的代码，并使用一种特殊的预编译器和操作系统，那么这将不易移植到其他环境，而且还难于维护和改进软件。类似地，一些优化操作者易用性的系统或企图具有灵活性、可用性并且可以与其他软硬件相互操作的系统将付出性能方面的代价。

例如，比起使用具有完整的制定图形代码的旧应用系统，使用外部的通用图形引擎工具生成图形规划将大大降低性能。你必须在性能代价和你所提出的解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

为了达到产品特性的最佳平衡，你必须在需求获取阶段识别、确定相关的质量属性，并确定优先级。当你为项目定义重要的质量属性时，防止发生与目标冲突的行为。以下是一些例子：

• 如果软件要在多平台下运行(可移植性),那么就不要对可用性抱有乐观态度。
• 可重用软件能普遍适用于多种环境中,因此,不能达到特定的容错(可靠性)或完整性目标。
• 对于高安全的系统,很难完全测试其完整性需求;可重用的类组件或与其它应用程序的互操作可能会破坏其安全机制。

在软件中，其自身不能实现质量特性的合理平衡。在需求获取的过程中，加入对质量属性期望的讨论，并把你所了解的写入软件需求规格说明中。这样，才有可能提供使所有项目风险承担者满意的产品。

本文同步发表在 软件需求探索的http://www.srs.pub/theory/ruan-jian-de-zhi-liang-shu-xing.html