第第 88 章 软件质量保证章 软件质量保证 8.1 8.1 软件质量软件质量 8.2 8.2 质量运动质量运动 8.3 8.3 软件质量保证软件质量保证 8.4 8.4 软件评审软件评审 8.5 8.5 正式技术评审正式技术评审 8.6 SQA8.6 SQA 的形式化方法的形式化方法 8.7 8.7 统计软件质量保证统计软件质量保证 8.8 8.8 软件可靠性软件可靠性 8.9 8.9 软件的错误防范软件的错误防范 8.10 ISO90008.10 ISO9000 质量标准质量标准 8.11 SQA8.11 SQA 计划计划

“ 软件质量保证”（ SQA ）是一种应用于整个软件过程的庇护性活动。

SQA 包含：（ 1 ）一种质量管理方法；（ 2 ）有效的软件工程技术（方法和工具）；（ 3 ）在整个软件过程中采用的正式技术复审；（ 4 ）一种多层次的测试策略；（ 5 ）对软件文档及其修改的控制；（ 6 ）保证软件遵从软件开发标准的规程（在适用时）；（ 7 ）测量和报告机制。

本章将集中讨论为支持软件组织“在正确的时间、以正确的方式、做正确的事情”的相关管理问题和特定过程活动。

8.1 质量概念 Quality Concepts

《美国传统字典》（ American Heritage Dictionary ）中对质量的定义是：“某一事物的特征或属性”。

作为一个事物的属性，质量指的是可以度量的特征――那些可以与已知标准进行比较的东西，如长度、颜色、电的性质、可延展性等等。

但是软件，很大程度上是一种知识实体，其特征的定义远比物理对象要困难得多。

ANSI/IEEE Std 729-1983ANSI/IEEE Std 729-1983 定义软件定义软件质量为“质量为“与软件产品满足规定的和与软件产品满足规定的和隐含的需求的能力有关的特征或特隐含的需求的能力有关的特征或特性的全体性的全体”。”。

M.J. FisherM.J. Fisher 定义软件质量为“定义软件质量为“所所有描述计算机软件优秀程度的特性有描述计算机软件优秀程度的特性的组合的组合”。”。

程序特征的度量的确存在。这样的属性包括循环复杂度、内聚、功能点、代码行数和其他许多属性。在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：设计质量和符合质量。

设计质量：是指设计者为一件产品规定的特征。材料等级、耐久性、及性能的规约都属于设计质量。

当规定使用更高级别的材料、要求达到更强的耐久性和更高层次的性能时，如果产品能够依照规约进行制造，则产品的设计质量便会提高。

符合质量：是指在制造过程中符合设计规格的程度。同样，符合程度越高，符合质量也就越高。

在软件开发时，设计质量包括系统的需求、规约和设计。符合质量则主要关注实现问题。如果实现符合设计、得到的系统满足系统需求和性能目标，则符合质量较高。

软件质量特性软件质量特性 软件质量特性，反映了软件的本质软件质量特性，反映了软件的本质。。讨论一个软件的质量，问题最终要讨论一个软件的质量，问题最终要归结到定义软件的质量特性。归结到定义软件的质量特性。

定义一个软件的质量，就等价于为定义一个软件的质量，就等价于为该软件定义一系列质量特性。该软件定义一系列质量特性。

人们通常把影响软件质量的特性用人们通常把影响软件质量的特性用软件质量模型来描述软件质量模型来描述。。

软件质量模型软件质量模型 软件质量特性定义成软件质量特性定义成分层模型。分层模型。 最基本的叫做最基本的叫做基本质量特性基本质量特性，它可，它可以由一些子质量特性定义和度量。以由一些子质量特性定义和度量。

二次特性二次特性在必要时又可由它的一些在必要时又可由它的一些子质量特性定义和度量。子质量特性定义和度量。

Boehm 质量模型质量模型

ISOISO 的软件质量评价模型的软件质量评价模型 按照按照 ISO/TC97/SC7/WG3/1985-1-30/N382ISO/TC97/SC7/WG3/1985-1-30/N382 ，，

软件质量度量模型由三层组成：软件质量度量模型由三层组成： 　软件质量需求评价准则　软件质量需求评价准则（（ SQRCSQRC ）） 　软件质量设计评价准则　软件质量设计评价准则（（ SQDCSQDC ）） 　软件质量度量评价准则　软件质量度量评价准则（（ SQMCSQMC ）） 高层和中层建立国际标准，低层可由各使用高层和中层建立国际标准，低层可由各使用

单位视实际情况制定单位视实际情况制定

19911991 年 年 ISOISO 质量特性国际标质量特性国际标准准 （ （ ISO/IEC9126ISO/IEC9126 ）） 质量特性：质量特性：功能性功能性、、可靠性可靠性、、可维护性可维护性、、效效

率率、、可使用性可使用性、、可移植性可移植性 推荐推荐 2121 个子特性：适合性 准确性 互用个子特性：适合性 准确性 互用

性 依从性 安全性 成熟性 容错性 性 依从性 安全性 成熟性 容错性 可恢复性 可理解性 易学习性 操 可恢复性 可理解性 易学习性 操作性 时间特性 资源特性 可分作性 时间特性 资源特性 可分析性 稳定性 可变更性 可测试性 析性 稳定性 可变更性 可测试性 可安装性 可替换性 适应性 一致性 可安装性 可替换性 适应性 一致性

质量控制 Quality Control 差异控制可以等同于质量控制。 “ 质量控制”是为了保证每一件工作产品都满

足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。

质量控制在创建工作产品的过程中包含一个反馈循环。度量和反馈相结合，使得我们能够在得到的工作产品不能满足其规约时调整开发过程。这种方法将质量控制视为整个制造过程的一部分。

质量控制活动可以是全自动的、全人工的，也可以是自动工具与人员交互的结合。质量控制中的关键概念之一是所有工作产品都具有定义好的和可度量的规约，我们可以将每个过程的产品与这一规约进行比较。反馈循环的引入对于最小化产生的缺陷至关重要。

“ 质量保证”由管理层的审计和报告功能构成。质量保证的目标是为管理层提供为获知产品质量信息所需的数据，从而获得产品质量是否符合预定目标的认识和信心。当然如果质量保证所提供的数据发现了问题，则管理层负责解决这一问题并为解决质量问题分配所需的资源。

质量的成本 Cost of Quality

质量成本包括所有由质量工作或者进行与质量有关的活动所导致的成本。质量成本研究的开展能够为当前质量成本设定基线，标识降低质量成本的机会，并提供一种规范化的比较基础。规范化的基础几乎全都以“元”（钱）计算。一旦我们将质量成本以“元”为单位进行了规范化，我们就拥有了必要的数据以评估能够在何处改进现有过程。而且，还可以进一步评估那些基于“元”的项在改变时所产生的影响。

质量成本可以被划分为与预防、鉴定及失败相关的成本。“预防成本”包括：

* 质量计划 * 正式技术复审 * 测试设备 * 培训

“鉴定成本”包括为深入了解“首次通过”各个过程时产品的状态而开展的那些活动。鉴定成本的例子如下：

* 过程内和过程间审查 * 设备校准和维护 * 测试

“失败成本”是指如果在将产品交付给客户之前已经消除了缺陷时就不会存在的成本。失败成本可以进一步划分为内部失败成本和外部失败成本。“内部失败成本”是指在产品交付之前发现错误而引发的成本。内部失败成本包括：

* 返工 * 修复 * 失败模式分析

“外部失败成本”是指与产品交付给客户之后所发现的缺陷相关的成本。外部失败成本的例子如下：

* 解决客户的抱怨 * 退换产品 * 求助电话支持 * 保修工作

正如我们所预料的，发现和修改一个缺陷的相对成本将随着我们从预防到检测、到从内部失败及到外部失败的成本而急剧增加。根据 Boe

hm所收集的数据，阐述了这一现象。

ADVICE ：测试是必要的，但是，它也是一种非常昂贵的发现错误的方式。在过程的早期花时间发现错误，你可能能够大量地减少测试和调试成本。

8.2 质量运动 The Quality Movement

质量运动始于本世纪 40年代 W. Edwards Deming 的开创性工作，第一次真正的实验则是在日本进行的。以 Deming 的想法为基础，日本人开发了一种系统化的方法来从根本上消除造成产品缺陷的原因。从 70年代到 80 代，他们的工作被移植到西方，有时被称作“全面质量管理（ TQM ）”。

尽管不同公司和不同作者那里的术语略有不同，但通常采用的都是 4 个步骤的过程，该过程构成了任何一个好的 TQM项目的基础。

第一步是指一个连续的过程改进系统。目标是开发一个可见的、可重复的和可度量的过程（在这里是指软件过程）。

第二步将检查影响过程的无形因素，并对这些因素对过程的影响进行优化。

　 例如，软件过程可能受到高层职员流动的影响，而这本身又是由公司内部不断重组而引起的。因此一个稳定的公司组织可能会对软件质量的提高有很大的帮助。可以帮助管理者对公司重组方式提出建议。

第三步：关注产品的用户（这里的产品是指软件）。通过检查用户使用产品的方式，对产品本身及产品的生产过程进行改进。

最后一个步骤将管理者的注意力从当前的产品上拓宽。通过观察产品在市场上的用途，寻找产品在相关领域中的发展机会。

8.3 软件质量保证 Software Quality Assurance

软件质量的定义：

对显式声明的功能和性能需求、显式文档化的开发标准、以及专业人员开发的软件所应具有的所有隐含特征的符合。

上述定义强调了以下三个重要方面：1. 软件需求是进行“质量”测量的基础。与需求

不符就是质量不高。2. 指定的标准定义了一组指导软件开发的准则。

如果不能遵照这些准则，就极有可能导致质量不高。

3. 通常有一组“隐含需求”是不被提及的（如对易维护性的需求）。如果软件符合了显式的需求却没有满足隐含需求，软件质量仍然值得怀疑。

SQA 活动 软件质量保证由各种任务构成，这些任务分别与

两种不同的参与者相关――做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的 SQA小组。

软件工程师通过采用可靠的技术方法和措施、进行正式的技术复审、执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制活动）。

SQA 小组的职责是辅助软件工程小组得到高质量的最终产品。软件工程研究所 SEI 推荐了一组有关质量保证中的计划、监督、记录、分析及报告的 SQA 活动。这些活动将由一个独立的 SQA 小组执行（或协助）。

为项目准备 SQA 计划：该计划在制定项目计划时制定，由所有感兴趣的相关部门复审。该计划将控制由软件工程小组和 SQA 小组执行的质量保证活动。

在计划中要标识以下几点：

* 需要进行的评价* 需要进行的审计和复审* 项目可采用的标准* 错误报告和跟踪的规程* 由 SQA小组产生的文档* 为软件项目组提供的反馈数量

参与开发该项目的软件过程描述――软件工程小组为要进行的工作选择一个过程。 SQA小组将描述复审过程以保证该过程与组织政策、内部软件标准、外界所订标准（如 ISO 9001 ）以及软件项目计划的其他部分相符。

复审各项软件工程活动、对其是否符合定义好的软件过程进行核实―― SQA小组识别、记录和跟踪与过程的偏差，并对是否已经改正进行核实。

审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实―― SQA小组对选出的产品进行复审；识别、记录和跟踪出现的偏差、对是否已经改正进行核实、定期将工作结果向项目管理者报告。

确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理――偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。

记录所有不符合的部分并报告给高级管理者――不符合的部分将受到跟踪直至问题得到解决。

除进行上述活动之外， SQA小组还需要协调变化的控制和管理，并帮助收集和分析软件度量信息。

8.4 软件复审 Software Reviews 软件复审是软件工程过程中的“过滤器”。复

审被用于软件开发过程中的多个不同的点上，起到发现错误（进而引发排错活动）的作用。软件复审起到的作用是“净化”分析、设计和编码中所产生的软件工作产品。 Freedman和 Weinberg 在中对复审的讨论如下：

技术工作需要复审的理由就象铅笔需要橡皮――“人非圣贤，孰能无过”。我们需要复审的第二个理由是：尽管人善于发现自己的某些错误，但是犯错误的人自己对许多种错误的发现能力远小于其他的人。

　复审（任何复审）均是一种借助一组人的差异性来：

(1) 指出一个人或小组生产的产品所需进行的改进； (2) 确定产品中不需要或者不希望改进的部分； (3) 得到与没有进行复审相比更加一致、或者至少

更可预测的技术工作的质量，从而使得技术工作更易于管理。

在软件工程过程中可以进行的复审有许多种，它们各有用处。

在饭桌上讨论技术问题的非正式会议是一种复审； 将软件设计正式介绍给客户、管理层和技术人员也是一种

复审方式。 正式的技术复审 : 有时称为“走查”（ Walkthrough ）

或检查（ Inspection ）。 从质量保证的角度出发，正式的技术复审是最有效的过滤器。由软件工程师（或其他人）对软件工程师进行的正式技术复审（ FTR ）是一种提高软件质量的有效方法。

软件缺陷对成本的影响Cost Impact of Software Defects 在软件过程范围中，术语“缺陷”和“故障”是同

义词。它们都表示在软件交付给最终用户之后发现的质量问题。

正式技术复审的主要目标是在此过程中发现错误，以便使的它们不会在软件发布之后变成缺陷。正式技术复审的明显优点是较早发现错误，防止错误被传播到软件过程的后续阶段。

产业界的大量研究（ TRW 、 Nippon Electric 和Mitre Corp. 以及其他公司）表明设计活动引入的错误占软件过程中出现的所有错误（和最终的缺陷）数量的 50％到 65％。

而现有研究表明正式技术复审在发现设计错误方面最高达到 75％的有效性。通过检测和排除大量设计错误，复审过程将极大降低后续开发和维护阶段的成本。

为了说明尽早发现错误对成本的影响，我们将根据从大型软件项目中收集的实际数据研究一系列的相对成本。

假定在设计阶段发现的错误的改正成本为 1.0 个货币单位，在测试开始之前发现一个错误的改正成本为 6.5 个货币单位，在测试时发现一个错误的改正成本为 15 个货币单位，而在发布之后发现一个错误的改正成本为 60 到 100 个货币单位。

缺陷的放大和消除Defect Amplification and Removal

可以用“缺陷放大模型” [IBM81]来说明在软件工程过程中的概要设计、详细设计和编码阶段中错误的产生及检测。

在没有复审的软件开发过程中缺陷放大的例子。

图 8.3 缺陷的放大（无复审）

在设计和编码过程中将复审作为每个软件过程步骤的一部分。

图 8.4 缺陷的放大（有复审）

50%

在每个步骤中发现的错误数量被乘以消除一个错误的成本（对设计是 1.5 个成本单位，测试前是6.5 个成本单位，测试中是 15 个成本单位，而发布后是 67 个成本单位），

使用这些数据，在进行了复审的情况下，开发和维护的总成本是 783 个成本单位。

而在不进行复审的情况下，总成本是 2177 个成本单位。后者几乎是前者的 3倍。

为了进行复审，软件工程师必须花费时间和工作量，开发组织必须投入资金。

但是上述例子的结果证明，我们面临的是一种“现在付出、否则以后付出更多”的情况。

（设计和其他技术活动中的）正式技术复审提供了显而易见的成本效益。

因此，应该进行复审活动。

8.5 正式技术复审Formal technical Reviews 正式技术复审（ FTR ）是一种由软件工程师进行

的软件质量保证活动。 FTR 的目标是（ 1 ）在软件的任何一种表示形式中发现功能、逻辑

或实现的错误；（ 2 ）证实经过复审的软件的确满足需求；（ 3 ）保证软件的表示符合预定义的标准；（ 4 ）得到以一种一致的方式开发的软件；（ 5 ）使项目更易于管理。由于 FTR 的进行使大量

人员对软件系统中原本并不熟悉的部分更为了解，因此， FTR还起到了提高项目连续性和培训后备人员的作用。

FTR( 正式技术复审 ) 实际上是一类复审方式，包括“走查”（ Walkthrough ）、“审查”（ Insp

ection ）、“轮查”（ Round-robin Review ）以及其他软件小组的技术评估。

每次 FTR 都以会议形式进行，只有经过适当的计划、控制和参与， FTR才能获得成功。

复审会议 The Review Meeting

不论选择何种 FTR( 正式技术复审 )形式，每个复审会议都应该遵守下面的约束：

* 复审会议（通常）应该在 3 到 5 个人之间进行

* 应该进行提前准备，但是每人占用工作时间应该少于 2小时

* 复审会议时间应该不超过 2小时

在上述约束之下，显然 FTR应该关注的是整个软件中的某个特定（且较小）部分。

例如，不要试图复审整个设计，而是对每个模块或者一小组模块进行走查。当FTR的关注范围较小时，发现错误的可能性更大。

在复审结束时，所有 FTR 的与会者必须作出以下决定中的一个：

（ 1 ）工作产品可以不经修改而被接受；（ 2 ）由于严重错误而否决工作产品（错误改正后必须再次进行复审）；或

（ 3 ）暂时接受工作产品（发现必须改正的微小错误，但是不再需要进一步复审）。作出决定之后，所有 FTR 与会者需要“签名”，以表示他们参加了此次 FTR,并且同意复审小组所作的决定。

复审报告和记录保存 Review Reporting and Record Keeping

在 FTR 期间，一名复审者（记录员）主动记录所有提出的问题。在复审会议结束时，对这些问题进行总结，并生成一份“复审问题列表”。此外，还要完成一份简单的“复审总结报告”。复审总结报告将回答以下问题：

　 1. 复审什么？　 2. 由谁复审？　 3. 发现和结论是什么？

复审总结报告通常是一页纸大小（可能还有附件）。它是项目历史记录的一部分，有可能被分发给项目管理者和其他感兴趣的参与方。

复审问题列表有两个作用：(1) 标识产品中存在问题的区域；(2) 用作“行动条目”检查表以指导生产者进行改正。　　　建立一个跟踪规程以保证问题列表中的每一项条目都得到适当的改正。只有做到这一点，才能保证提出的问题真正得到控制。

复审指南 Review Guidelines

　　　进行正式技术复审之前必须建立复审指南，分发给所有复审者，并得到大家的认可，然后才能依照它进行复审。

　 ADVICE ：不要严厉地指出错误。一种温和地方式是问一个问题，以使得生产者能够发现他自己的错误。

1. 复审产品，而不是复审生产者。 FTR涉及到别人和自我。如果进行得适当， FTR 可以使所有参与者体会到温暖的成就感。如果进行得不适当，则可能陷入一种审问的气氛之中。

　　　复审主席应该引导复审会议以保证会议始终处于适当的气氛和态度之中，在讨论失去控制时应立即休会。

2. 制定日程并且遵守日程。各种类型的会议都具有一个主要缺点：放任自流。 FTR必须保证不要离题和按照计划进行。复审主席被赋予维持会议程序的责任，在有人转移话题时应该提醒他。

3. 限制争论和辩驳。在复审者提出问题时，未必所有人都认同该问题的严重性。不要花时间争论这一问题，这样的问题应该被记录在案，留到会后进一步讨论。

4. 对各个问题都发表见解，但是不要试图解决所有记录的问题。复审不是一个问题解决会议。问题的解决通常由生产者自己，或者在其他人的帮助下来完成。问题解决应该放到复审会议之后进行。

5. 作书面笔记。 6. 限制参与者人数并坚持事先作准备。

7. 为每个可能要复审的工作产品建立一个检查表。检查表能够帮助复审主席组织 FTR 会议，并帮助每个复审者将注意力集中在重要问题上。应该为分析、设计、编码、甚至测试文档都建立检查表。

8. 为 FTR 分配资源和时间。为了让复审有效，应该将复审作为软件工程过程中的任务加以调度。而且要为由复审结果而导致的修改活动分配时间。

9. 对所有复审者进行有意义的培训。为了提高效率，所有复审参与者都应该接受某种正式培训。

10. 复审以前所作的复审。听取汇报对发现复审过程本身的问题十分有益。最早被复审的工作产品应该是复审指南本身。

　 由于成功的复审涉及到许多变数（如，参与者数量、工作产品类型、时间和长度、特定的复审方法等），软件组织应该在实验中决定何种方法最为适用。

8.6 SQA 的形式化方法Formal Approaches to SQA

在过去的 20年中，在软件界中有一群虽然很少但是很坚决的人们，提出软件质量保证应该采用一种更为形式化的方法。一个计算机程序可以看作一个数学对象。

对于每一种程序设计语言都能够定义一套严格的语法和语义，且对于软件需求规格说明也出现了一种类似的严格方法。

一旦需求模型（规约）和程序设计语言以一种严格的方式被表达出来，就可以采用程序正确性的数学证明来说明程序是否严格符合它的规约。

程序正确性证明不是一个新的思路。 Dijkstra

和 Linger 、 Mills 及 Witt ，以及其他很多人都支持程序正确性的数学证明，并将它与结构化程序设计概念联系在一起。

8.7 统计软件质量保证 Statistical Quality Assurance

统计质量保证反映了一种在产业界不断增长的趋势：质量的量化。对于软件而言，统计质量保证包括以下步骤：

1. 收集和分类软件缺陷信息。 2. 尝试对每个缺陷的形成原因（例如，不符合

规约、设计错误、违背标准、与客户通信不力等）进行追溯。

3. 使用 Pareto原则（ 80％的缺陷可以追溯到所有可能原因中的 20％），将这 20％（重要的少数）分离出来。

4. 一旦标识出重要的少数原因，就可以开始纠正引起缺陷的问题。

所有错误都可以追溯到下述原因中的一个 ( 或几个 ):

* 规约不完整或规约错误（ incomplete or erroneous specifications ， IES ）

* 与客户通信中所产生的误解（ misinterpretation of customer communication ， MCC ）

* 故意与规约偏离（ intentional deviation from specification ， IDS ）

* 违反编程标准（ violation of programming standards ，VPS ）

* 数据表示有错（ error in data representation ， EDR ）* 构件接口不一致（ inconsistent component interface ，

ICI ）

* 设计逻辑有错（ error in design logic ， EDL ）* 不完整或错误的测试（ incomplete or erroneous tes

ting ， IET ）* 不准确或不完整的文档（ inaccurate or incomplete

documentation ， IID ）* 将设计翻译成程序设计语言中的错误（ error in pr

ogramming language translation of design ， PLT ）

* 不清晰或不一致的人机界面（ ambiguous or inconsistent human/computer interface ， HCI ）

* 杂项（ miscellaneous ， MIS ）

表 8-1

重要的是要注意，纠正性动作主要注重于“重要的少数”。随着少数重要原因的不断改正，新的候选错误原因也将被提到改进日程上来。

软件的统计质量保证技术已经被证明提供了实质性的质量改善。

在某些情形，在应用这些技术后，软件组织已经达到了 50% 的年缺陷减少。

当与缺陷信息集合结合使用时，软件开发者可以为软件工程过程中的每个步骤计算“错误指标”（ Error index ， EI ）。在经过分析、设计、编码、测试和发布之后，将收集到以下数据：

Ei ＝ 在软件工程过程中的第 i步中发现的错误总数Si ＝ 严重错误数Mi ＝ 一般错误数Ti ＝ 微小错误数PS ＝ 第 i步的产品规模（ LOC 、设计陈述、文档页数）

Ws 、 Wm 、 Wt 分别是严重、一般、微小错误的加权因子，其推荐取值为

Ws＝ 10 Wm＝ 3 Wt＝ 1 。 随着过程的进展，每个阶段的加权因子取值逐渐变大。也就是说，尽早发现错误的组织得益较多。

在软件工程过程中的每一步中，分别计算各个阶段的阶段指标（ phase index ） PIi ：

PIi = Ws (Si/Ei) + Wm (Mi/Ei) + Wt (Ti/Ei)

错误指标 EI通过计算各个 PIi 的加权效果得到，在软件工程过程中后面的步骤中遇到的错误的权重要高于在前面阶段遇到的错误权重。

EI = ∑ (i×PIi)/PS =

(PI1+2PI2+3PI3+…+iPIi)/PS 错误指标与表 8.1 中收集的信息相结合，可以得出

软件质量的整体改进指标。 统计 SQA 的应用及 Pareto 规则可以用一句话概

括：将时间集中用于真正重要的地方，但是首先你必须知道什么是重要的。

8.8 软件可靠性 Software Reliability 软件可靠性是“在特定环境和特定时间内，计算

机程序无故障地运行的概率”。 举例说明，程序 X 在 8 个小时处理占用时间中

的可靠性估计为 0.96 ；也就是说，如果程序 X

执行 100 次，每次运行 8 个小时的处理占用时间（执行时间），则 100 次中正确运行（不失败）的次数可能是 96 。

在软件工程中常用的定义在软件工程中常用的定义 错误错误 (error)(error) ：人类会犯错误。同义词是过错：人类会犯错误。同义词是过错 (mist(mistake),bug(ake),bug( 在编写代码时出现的过错在编写代码时出现的过错 ))，指在软件交，指在软件交付给最终用户之前发现的质量问题。付给最终用户之前发现的质量问题。

缺陷缺陷 (defect):(defect): 指在软件交付给最终用户之后发现的指在软件交付给最终用户之后发现的质量问题 。质量问题 。

故障故障 // 缺陷缺陷 (fault)(fault) ：故障是错误的结果，或错误的：故障是错误的结果，或错误的表现。表现。

失效失效 (failure)(failure) ：当缺陷执行时会发生失效，失效只：当缺陷执行时会发生失效，失效只出现在可执行的表现中，通常是被装载的目标代码。出现在可执行的表现中，通常是被装载的目标代码。

以上定义的故障、错误和失效，分别以上定义的故障、错误和失效，分别代表了代表了广义的“错误”广义的“错误”在不同的条件在不同的条件下下所对应的术语。所对应的术语。

它们可以理解为：设计者的失误─导它们可以理解为：设计者的失误─导致系统中留有错误的设计──缺陷或致系统中留有错误的设计──缺陷或““故障故障”” ((faultfault)) ，这些，这些故障故障导致系统导致系统的错误执行──的错误执行──错误错误 ((errorerror)) ，由于，由于错错误误导致系统的错误输出──导致系统的错误输出──失效失效 ((failurfailuree)) 。。

故障是物理地或静态地存在的故障是物理地或静态地存在的 失误、错误和失效都是系统的一种失误、错误和失效都是系统的一种动态的转瞬即逝的现象动态的转瞬即逝的现象

软件发生失效标志着软件一次使用软件发生失效标志着软件一次使用寿命的结束寿命的结束

发生过失效的软件通常仍然是可用发生过失效的软件通常仍然是可用的。只有当软件频繁失效，或者公的。只有当软件频繁失效，或者公认已经“过时”了的时侯，软件才认已经“过时”了的时侯，软件才被废弃，被废弃，意味着当前这一版本软件意味着当前这一版本软件使用寿命的终结。使用寿命的终结。

可靠性和可用性的测量Measures of Reliability and Availability

当我们考虑一个基于计算机的系统时，可靠性的简单度量是“平均失效间隔时间”（ MTBF ），其中：

MTBF ＝ MTTF ＋MTTR

MTTF （ Mean-Time-To-Failure ）和 MTTR （ M

ean-Time-To-Repair ）分别是“平均失效时间”和“平均修复时间”。

许多研究人员认为 MTBF 是一个远比“缺陷数 /KLOC” 或“缺陷数 /FP” 更为有用的度量指标。

简而言之，最终用户关心的是失效，而不是总缺陷数。

由于一个程序中包含的每个缺陷所具有的失效率不同，总缺陷数难以表示系统的可靠性。比如考虑一个已经投入运行 14 个月的程序，程序中的许多缺陷的暴露需要经过几年的运行时间。这种隐藏缺陷的 MTBF 可能是 50 到 100年。

还有一些尚未被发现的缺陷的失败率可能是 18 或24 个月。即使全部排除第一种缺陷（具有较长 MTBF 的缺陷），对软件可靠性的影响也微乎其微。

除可靠性度量之外，我们必须开发一个“可用性”度量。软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为：

　　可用性 ＝ MTTF / (MTTF ＋ MTTR) × 100％ MTBF 可靠性度量对 MTTF 和 MTTR 同样敏感。

而可用性度量在某种程度上对 MTTR 较为敏感，MTTR 是软件可维护性的间接度量。

软件安全性（ Software Safety ）

“ 软件安全性”是集中于解决潜在危险（这些危险将负面影响软件系统并导致整个系统失效）的标识和评估问题的软件质量保证活动。

如果能够在软件工程过程的早期标识这些危险，则可以指定软件设计特性以排除或控制潜在的危险。

建模和分析过程可以视为软件安全性的一部分。开始时，根据关键性和风险来标识和分类危险。例如，与基于计算机的汽车驾驶控制相关的危险可能有：

* 导致不受控制的加速使得不能停止* 当刹车踏板踩下后不能制动* 开关激活后不能启动* 加速或减速缓慢

一旦这些系统级的危险被标识出来，就可以使用分析技术指定这些危险发生的严重性和概率。

为了真正有效，软件应该被置于整个系统中进行分析。例如，一个微小的用户输入错误可能被软件错误放大成产生将机械设备置于不正确位置的控制数据。如果满足一组外部环境条件（而且仅当满足这些条件时），机械设备的不正确位置将引发灾难性的失败。

故障树分析、实时逻辑或 Petri网模型等分析技术可以用于预测可能引起危险的事件链，以及事件链中的各个事件出现的概率。

危险标识和分析完成之后，就可以进行软件中与安全性相关的需求进行规格说明了。

尽管软件可靠性与软件安全性相互之间关系紧密，但是理解它们之间的微妙差异更为重要。

软件可靠性使用统计分析方法确定软件失效发生的可能性；而失效的发生未必导致危险或灾难。软件安全性则考察失效会导致灾难发生的条件。

8.9 软件的错误防范 在 1960年代，日本的工业工程师 Shigeo

Shingo 在 Toyota （丰田）工作时，开发了一种质量保证技术，用于制造过程中错误的预防和 / 或早期纠正，成为 poka-yoke （错误检验）。 Shingo 的概念使用 poka-yoke 设备， 用于：

（ 1 ）潜在质量问题发生前的预防；（ 2 ）质量问题的快速探测。

在我们的日常生活中总能遇到 poka-yoke 设备（即使我们并不知道这个概念），例如，如果自动变速箱不是位于停车档上，则汽车的启动开关不能工作（预防设备），如果安全带未系上，则汽车的警告声将响起（探测设备）。

一个有效的 poka-yoke 设备展示了一组共同特征：　 * 简单且便宜。如果某设备太复杂或太昂贵，则它

将不是价格有效的。　 * 是过程的一部分。即， poka-yoke 设备被集成

进一个工程活动中。　 * 位于发生错误的过程任务的旁边。这样，它提供快速的反馈和错误纠正。

8.10 ISO 9000 质量标准 The ISO 9000 Quality Standards

“ 质量保证系统”可以被定义成用于实现质量管理的组织结构、责任、规程、过程和资源。

这些系统覆盖了构成产品的完整生命期的大量的活动，包括计划、控制、测量、测试和报告，以及在贯穿开发和制造的过程中改进质量级别。

ISO 9000 标准以一种能够适用于任何行业（不论提供的是何种产品或服务）的一般术语描述了质量保证的元素。

在采用标准以后，一个国家通常只允许 ISO登记的公司向政府部门和公共组织供应产品和服务。电信设备和医疗设备是必须由 ISO登记公司供应的产品类别的例子。反过来，这些产品的制造商经常需要他们的供应商变成 ISO登记的。私有公司，如汽车和计算机制造商经常也需要他们的供应商是 ISO登记的。

为了登记成为 ISO 9000 中包含的质量保证系统模型中的一种，一个公司的质量系统和操作应该由第三方审计者仔细检查，查看其与标准的符合性以及操作的有效性。

成功登记之后，这一公司将收到由审计者所代表的登记实体颁发的证书。此后每半年进行一次的检查性审计将持续保证该公司的质量系统与标准是相符的。

ISO 质量保证系统的方法 ISO 9000 质量保证模型将一个企业视为一个互联

过程的网络。为了使质量系统符合 ISO 标准，这些过程必须针对在标准中给出的区域，并且必须按照标准中所述的予以文档化和实现。

ISO 9000 以一般术语描述了一个质量保证系统的元素。这些元素包括用于实现质量计划、质量控制、质量保证和质量改进所需的组织结构、规程、过程、和资源。

但是 ISO 9000并不描述一个组织应该如何实现这些质量系统元素。因此，真正的挑战在于如何设计和实现一个能够满足标准、并适用于公司的产品、服务和文化的质量保证系统。

KEYPOINT ： ISO 9000描述必须做什么以保证符合，但是，它并没有描述必须如何做。

ISO 9001 标准 ISO 9001 是应用于软件工程的质量保证标准。这

一标准中包含了高效的质量保证系统必须体现的 2

0条需求。 因为 ISO 9001 标准适用于所有的工程行业，因此，

为帮助解释该标准在软件过程中的使用而专门开发了一个 ISO 指南的子集（即 ISO 9000-3 ）。

ISO 9001描述的需求强调了管理责任、质量系统、控制复审、设计控制、文档和数据控制、产品标识和跟踪、过程控制、审查和测试、纠正和预防性动作、控制质量记录、内部质量审计、培训、服务以及统计技术的话题。

软件组织为了通过 ISO 9001 ，就必须针对上面提到的每一条需求（和其他）建立相关政策和规程，并且有能力显示出组织活动的确是按照这些政策和规程进行的。

8.11 SQA 计划 “SQA 计划”为建立软件质量保证提供了一张

行路图。该计划由 SQA小组制定，充当了每个软件项目中的 SQA 活动的模板。

SQA 计划的标准由 IEEE 推荐。开始部分描述目的和文档范围，并指出质量保证所覆盖的软件过程活动。所有在 SQA 计划中提到的文档都被列出来，且所有可应用的标准都专门注明。计划的“管理”部分描述 SQA 在组织结构中的位置；SQA任务和活动、及它们在整个软件过程中的位置；以及与产品质量有关的组织角色和责任。

“ 文档”一节（通过引用）描述的是软件过程各个部分所产生的各种工作产品，包括：

　 * 项目文档（例如项目计划）　 * 模型（例如 ERD模型、类层次模型）　 * 技术文档（例如规约、测试计划）　 * 用户文档（例如帮助文件）

另外，在这一节中还定义了实现高质量所能接受的工作产品的最小集合。

在“标准、实践和约定”中列出了所有在软件过程中采用的合适的标准和实践方法（例如，文档标准、编码标准和复审指南）。此外，还列出了作为软件工程工作的成分而收集的所有项目、过程及（在某些情况下）产品度量信息。

计划中的“复审和审计”一节标识了软件工程小组、 SQA小组和客户进行的审计和复审活动。它给出了各种复审和审计方法的总览。

“ 测试”一节中列出了软件测试计划和过程。它还定义了测试记录保存的需求。“问题报告和改正行动”中定义了错误及缺陷的报告、跟踪和解决规程，这些活动的组织责任也被标识出来。

“SQA 计划”的其他部分标识了支持 SQA 活动与任务的工具和方法；给出了控制变化的软件配置管理过程；定义了一种合同管理方法；建立了组装、保护、维护所有记录的方法；标识了为满足这一计划所需的培训；定义了标识、评估、监控和控制风险的方法。

表 8-3

8.12 小结 Summary

软件质量保证是在软件过程中的每一步都进行的“庇护性活动”。 SQA 包括对方法和工具有效应用的规程、正式技术复审、测试策略和技术、变化控制规程、保证与标准符合的规程、以及度量和报告机制。

软件质量的复杂本质――这是计算机程序的一种属性，其定义是“与明确地和隐含地定义的需求的符合程度”――使 SQA 很复杂。但是当被更为一般地考虑时，软件质量包括了许多不同的产品和过程因素及其相关的度量。

软件复审是最为重要的 SQA 活动之一。复审的作用是作为软件过程的过滤器，在发现及改正错误的成本相对较小时就排除错误。正式技术复审或走查是一种典型的复审会议，在实践中这种形式对于发现错误极其有效。

为了正确的进行软件质量保证，必须收集、评估和发布软件工程过程的数据。统计 SQA有助于改进产品和软件过程本身的质量。软件可靠性模型将度量加以扩展，能够由所收集的缺陷数据推导出项目失败率和进行可靠性估计。

总而言之，让我们借用 Dunn 和 Ullman 的一句话：“软件质量保证就是将质量保证的管理对象和设计原则映射到适用的软件工程管理和技术空间上。”质量保证的能力是成熟的工程学科的量尺。当上述映射成功实现时，其结果就是成熟的软件工程。

Bye!