产品质量低下的原因有很多，例如，产品制造粗糙，组件设计不当，架构不佳以及对产品的要求了解不多。

必须设计质量。 您不能测试出足够的错误来交付高质量的产品。的质量保证（QA）的过程 是为了获得满意的系统的输送是至关重要的。在本系列的最后一部分中，我们将专注于方法论的某些部分，这些部分特别旨在提高所得系统的质量。

本系列前面介绍的软件测试技术构成了质量保证的一个组成部分，但是对质量的追求贯穿了整个设计流程。例如，解决适当的要求和规范不能被视为质量的重要决定因素。如果系统设计太困难，则可能很难使其正常工作。

客户可能想要听起来不错的功能，但实际上并没有增加系统的整体实用性。在许多情况下，拥有太多功能只会使设计更加复杂，最终设备更容易损坏。

为了帮助我们理解质量保证的重要性，以下应用示例 描述了一种计算机控制的医疗系统中的严重安全问题。诸如航空电子设备之类的医疗设备是安全性至关重要的应用。不幸的是，在正确理解其设计错误之前，这种医疗设备已导致人员死亡。

此示例还使我们能够使用规范技术来理解软件设计问题。在本节的其余部分，我们着眼于提高质量的几种方法：设计审查，基于度量的质量保证以及调试大型系统的技术。

应用实例。Therac-25医学成像系统。 Therac-25医学成像系统引起了 Leveson和Turner所说的“迄今为止最严重的计算机相关事故（至少是非军事事故和入院事故）”。

在六次已知的事故中，这些机器发出大量的辐射剂量，造成死亡和重伤。Leveson和Turner分析了Therac-25系统以及造成这些事故的原因。

Therac-25由一台PDP-11微型计算机控制。该计算机负责控制辐射枪，该辐射枪向患者输送一定剂量的辐射。它还运行一个呈现主用户界面的终端。该机器的软件是由单个程序员用PDP-11汇编语言开发的，历时数年。该软件包括四个主要组件：存储的数据，调度程序，一组任务和中断服务。系统中的三个主要关键任务如下：

1）治疗监测仪分八个阶段控制和监测治疗的建立和交付。

2）伺服任务控制辐射枪，机器运动等。

3）管家任务负责系统状态联锁和极限检查。（限制检查确定某些系统参数是否已超出预设限制。）

代码是相对粗糙的-该软件允许多个进程访问共享内存，除了共享变量外没有同步机制，并且对共享变量进行测试和设置不是不可分割的操作。让我们检查导致一系列事故的软件问题。Leveson和Turner对相关软件的规范进行了反向工程，如下所示：

Treat 是治疗监控程序任务，分为八个子例程（Reset，Datent 等）。Tphase 是一个变量，它控制这些子例程中的哪个当前正在执行。在执行每个子例程后，Taste会重新安排自己的时间。所述Datent 经由数据输入完成标志，这是一个共享变量的键盘输入任务子例程连通。

Datent查看此标志，以确定何时应退出数据输入模式并进入设置测试模式。该模式/能量偏移 变量是一个共享变量：顶部字节保持偏移由Datent子程序中使用的参数，和低阶字节保持模式和能量偏移量所使用的手 的任务。

机器运行时，操作员被迫进入模式和能量（有一种模式将能量设置为默认值），但是操作员以后可以分别编辑模式和能量。

该软件的行为取决于时间。如果键盘处理程序在操作员更改模式/能量数据之前设置完成变量，则Datent任务将不会检测到更改-一旦Treat离开Datent，在处理过程中它将不会再次输入该子例程。但是，同时运行的手动任务将看到新的模式/能量信息。显然，该软件未包含检查不兼容数据的检查。

设置模式/能量数据后，软件会将参数发送到数字/模拟转换器，然后调用“ 磁铁”子例程 来设置弯曲磁铁。设置磁铁大约需要8秒钟，而称为Ptime的子例程 用于引入时间延迟。

由于写入Datent，Magnet和Ptime的方式，用户对参数所做的更改可能会显示在屏幕上，但Datent不会感知到。当操作员最初进入模式/能量，进入命令行，更改模式/能量并在8秒内返回命令行时，发生了一次事故。

因此，错误取决于操作员的打字速度。由于操作员会随着时间的推移变得更快，更熟练地使用机器，因此有经验的操作员更容易发生此错误。Leveson和Turner强调，以下不良的设计方法和有缺陷的体系结构是导致事故的特定错误的根源：

1）嵌入式开发工程师进行了非常有限的安全性分析。例如，将低概率分配给某些错误，而没有明显的理由。

2）即使在较早的机器型号中使用了机械备份，也没有使用机械备份来检查机器的运行情况（例如测试光束能量）。

3）程序员基于不可靠的编码样式创建了过于复杂的程序。

总之，Therac-25的设计人员依赖于系统测试，而模块测试或形式分析却不足。

质量保证技术

国际标准组织（ISO）创建了一套称为ISO 9000的质量标准，旨在适用于广泛的行业，包括但不限于嵌入式硬件和软件。

为特定产品（例如木制建筑梁）开发的标准可以指定特定于该产品的标准，例如梁必须能够承受的载荷。但是，诸如ISO 9000之类的广泛标准不能为每个行业指定详细标准。

因此，ISO 9000专注于用于创建产品或服务的过程。用来满足ISO 9000要求的过程会影响整个组织以及设计和制造过程中采取的各个步骤。

ISO 9000的详细描述超出了本系列的范围。但是，我可以对基于ISO 9000的质量管理做出以下观察：

过程至关重要。 危害开发会导致危害产品和低质量。知道要遵循什么步骤来创建高质量的产品，对于确保实际上遵循了所有必要步骤至关重要。

文档很重要： 文档具有多个作用：创建描述流程的文档可帮助相关人员理解流程；文档可以帮助内部质量监控小组确保确实遵循了所需的流程；文档还可以帮助外部团体（客户，审计师等）了解流程以及流程的实现方式。

沟通很重要： 质量最终取决于人。好的文档可以帮助人们理解整个质量过程。组织中的人员不仅应该了解他们的特定任务，而且应该了解他们的工作如何影响整体系统质量。

许多类型的技术可用于验证系统设计并确保质量。技术可以是手动的或基于工具的。手工技术在实践中出奇地有效。

稍后，我讨论设计评审，这些评审只是讨论设计的会议，并且在识别错误​​方面非常成功。通过跟踪程序以确定所需的测试，可以手动应用本系列前面所述的许多软件测试技术。

基于工具的验证可极大地帮助管理复杂设计中可能生成的大量信息。测试生成程序可以自动完成为程序创建测试集的工作。跟踪工具可以帮助确保已执行了各个步骤。设计流程工具通过其他工具使运行设计数据的过程自动化。

指标对于质量控制过程很重要。要知道我们是否已达到高质量水平，我们必须能够衡量系统和设计过程的各个方面。

我们可以衡量系统本身的某些方面，例如程序的执行速度或测试模式的覆盖范围。我们还可以衡量设计过程的各个方面，例如发现错误的比率。本文稍后将描述在质量保证过程中使用测量的方法。

工具和手动技术必须适合整个过程。该过程的细节将由几个因素决定，包括要设计的产品类型（例如，视频游戏，激光打印机，空中交通管制系统），要制造的单元数和设计允许的时间，现有的公司必须将任何新流程集成到其中的实践，以及许多其他因素。

ISO 9000的重要作用是帮助组织研究整个过程，而不仅仅是在特定时间可能显得很重要的特定部分。

卡内基梅隆大学软件工程学院开发的能力成熟度模型（CMM）是衡量组织软件开发过程质量的一种众所周知的方法。CMM提供了用于评估组织的模型。它定义了以下五个成熟度级别：

1.初始：组织不完善的流程，很少有明确定义的流程。一个项目的成功取决于个人的努力，而不是组织本身的努力。

2.可重复性： 此级别提供了基本的跟踪机制，使管理层可以了解成本，调度以及正在开发的系统达到其目标的程度。

3.定义：对管理和工程过程进行记录和标准化。所有项目都使用文件化和批准的标准方法。

4.托管： 此阶段对开发过程和产品质量进行详细的度量。

5.优化： 在最高级别上，来自详细度量的反馈用于持续改进组织的流程。

软件工程研究所发现，在世界上任何地方，很少有组织能达到最高水平的持续改进，而有相当多的组织在最初的混乱过程中运作。

但是，CMM提供了一个基准，组织可以据此判断自己并使用该信息进行改进。

验证规格

需求和规格是在设计过程的早期就生成的。验证需求和规范非常重要，原因很简单，因为需求或规范中的错误在以后修复时可能会非常昂贵。

下面的图9.11 显示了在设计过程中修复错误的成本是如何增加的（我们使用瀑布模型作为简单示例，但对于任何设计流程都适用）。

图9.11。长期存在的错误修复成本更高。

错误在系统中生存的时间越长，修复它的成本就越高。除非在系统部署之后才发现编码错误，否则除重新调用现有系统外，还要花费很多钱。但是，在流程的较早阶段引入但直到同一点才发现的错误会产生所有这些成本，并且还会产生更多成本。

需求或规范中引入的错误，直到维护时才存在，可能会迫使产品重新设计，而不仅仅是更换ROM。尽早发现错误至关重要，因为它可以防止将错误发布给客户，最小化设计成本并减少设计时间。

尽管在详细的设计阶段某些需求和规范的错误会变得很明显（例如，随着对某些需求后果的更好理解），但在生成需求和规范的过程中清除许多错误是可能且合乎需要的。

验证需求和规范的目的是确保它们满足我们在本系列早期创建的规范中最初应用的标准，包括正确性，完整性，一致性等。验证实际上是生成需求和规范的工作的一部分。

在创建某些技术时可以应用它们，以帮助您了解需求和规格，而在其他技术中将其应用到草稿上，其结果用于修改规格。

由于需求来自客户并且本质上是非正式的，因此验证需求似乎是一个挑战。但是，可以做很多事情来确保客户和实际编写需求的人进行沟通。

原型是与最终用户打交道时非常有用的工具-与其简单地用广泛的技术术语向他们描述系统，不如说原型可以让他们看到，听到和触摸到系统的某些重要方面。

当然，由于尚未完成设计工作，因此原型将无法完全发挥作用。但是，用户界面特别适合原型设计和用户测试。罐头或随机生成的数据可用于模拟系统的内部操作。

原型可以帮助最终用户批判许多功能和非功能需求，例如数据显示，操作速度，尺寸，重量等。

某些编程语言（有时称为原型语言或规范语言）特别适合于原型设计。非常高级的语言（例如信号处理领域中的Matlab）可能能够执行功能属性（例如要执行的数学功能），但不能执行非功能属性（例如执行速度）。

预先存在的系统也可以用于帮助最终用户明确表达其需求。指定某人对现有机器喜欢什么或不喜欢什么比让他们抽象地谈论新系统要容易得多。在某些情况下，可能有可能从现有系统构建新系统的原型。

特别是在设计使用实时计算机进行物理控制的网络物理系统时，仿真是验证需求的重要技术。对网络物理系统的要求部分取决于受控工厂的物理特性。对物理工厂进行建模的仿真器可以帮助系统设计人员了解系统网络方面的要求。

用于验证需求的技术也可用于验证规格是否正确。与对最终用户一样，构建原型，规范语言以及与现有系统的比较对系统分析和嵌入式开发工程师同样有用。

审核工具在验证一致性，完整性等方面可能很有用。仔细研究使用场景通常可以帮助设计人员填写规范的细节，并确保其完整性和正确性。在某些情况下，形式化技术（即利用数学证明的设计技术）可能会有用。

证明可以手动或自动完成。在某些情况下，根据规范证明特定条件可能会或不会发生很重要。自动证明在某些类型的复杂系统中特别有用，这些系统可以简洁地指定，但是随着时间的推移其行为是复杂的。例如，复杂的协议已被成功地正式验证。

设计评审

设计评审是任何质量检查流程的关键组成部分。设计审查是一种简单，低成本的方法，可以在设计过程的早期阶段发现错误。设计评审只是会议，团队成员在其中讨论设计，并评审系统组件的工作方式。

设计人员被迫仔细考虑设计时，只需为会议做准备就可以发现一些错误。参加会议的人员发现了其他错误，这些错误会注意到单位设计人员可能未发现的问题。

通过尽早发现错误并不允许它们传播到实现中，我们减少了获得工作系统所需的时间。我们还可以使用设计审查来提高实施质量，并使将来的更改更易于实施。

进行设计审查以审查系统的特定组件。设计审核小组具有以下成员：

1）当然，所审查组件的设计者对于设计过程至关重要。他们将其设计提交给团队的其他成员进行审查和分析。

2）审核负责人协调会议前的活动，设计审核本身以及会议后的后续活动。

3）评论员记录会议记录，以便设计人员和其他人员知道需要解决哪些问题。

4）复习对象学习组成部分。受众成员自然会包括为此组件设计的项目的其他成员。来自其他项目的观众成员通常会添加有价值的观点，并且可能会注意到团队成员遗漏的问题。

设计审查过程在会议本身之前开始。设计团队准备了一组文档（代码清单，流程图，规格等），用于描述组件。在会议之前，这些文件已分发给审阅团队的其他成员，因此每个人都有时间熟悉这些材料。审核负责人协调会议时间，讲义的分发等。

在会议期间，组长负责确保会议顺利进行，同时抄写员记下发生的情况。设计人员负责介绍组件设计。

从上至下的演示文稿通常效果很好，首先是需求和接口说明，然后是组件的总体结构，详细信息，然后是测试策略。观众应该在每个细节级别上寻找所有类型的问题，包括下面列出的问题。

1）设计团队对组件规范的看法是否与整个系统规范相一致，还是团队误解了某些内容？

2）接口规格是否正确？

3）组件的内部架构是否运作良好？

4）组件中是否存在编码错误？

5）测试策略是否适当？

抄写员记录的笔记用于会议的跟进。设计团队应纠正错误并解决会议上提出的问题。这样做时，团队应保留记录以说明所做的工作。

设计评审负责人与设计团队进行协调，以确保进行更改并将更改结果分发给观众。如果更改很简单，则书面报告可能就足够了。

如果在审核过程中发现的错误导致组件的重大返工，则对于新实施的新设计审核会议可能会有用，该会议应使用尽可能多的原始团队成员。

结束语

系统设计全面了解了应用程序和正在设计的系统。为了确保我们设计出可接受的系统，我们必须了解应用程序及其要求。诸如面向对象设计之类的多种技术可用于根据系统的原始要求创建有用的体系结构。

在整个过程中，通过衡量我们的设计过程，我们可以更清楚地了解在哪里引入了错误，如何修复错误以及如何避免在将来引入错误。