第 8 章 软件质量保证

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

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

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

4. 8.1质量概念Quality Concepts • 《美国传统字典》（American Heritage Dictionary）中对质量的定义是：“某一事物的特征或属性”。 • 作为一个事物的属性，质量指的是可以度量的特征――那些可以与已知标准进行比较的东西，如长度、颜色、电的性质、可延展性等等。 • 但是软件，很大程度上是一种知识实体，其特征的定义远比物理对象要困难得多。

5. ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。 • M.J. Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。

6. 程序特征的度量的确存在。这样的属性包括循环复杂度、内聚、功能点、代码行数和其他许多属性。在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：设计质量和符合质量。程序特征的度量的确存在。这样的属性包括循环复杂度、内聚、功能点、代码行数和其他许多属性。在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：设计质量和符合质量。 • 设计质量：是指设计者为一件产品规定的特征。材料等级、耐久性、及性能的规约都属于设计质量。 • 当规定使用更高级别的材料、要求达到更强的耐久性和更高层次的性能时，如果产品能够依照规约进行制造，则产品的设计质量便会提高。

7. 符合质量：是指在制造过程中符合设计规格的程度。同样，符合程度越高，符合质量也就越高。符合质量：是指在制造过程中符合设计规格的程度。同样，符合程度越高，符合质量也就越高。 • 在软件开发时，设计质量包括系统的需求、规约和设计。符合质量则主要关注实现问题。如果实现符合设计、得到的系统满足系统需求和性能目标，则符合质量较高。

8. 软件质量特性 • 软件质量特性，反映了软件的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。 • 定义一个软件的质量，就等价于为该软件定义一系列质量特性。 • 人们通常把影响软件质量的特性用软件质量模型来描述。

9. 软件质量模型 • 软件质量特性定义成分层模型。 • 最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。 • 二次特性在必要时又可由它的一些子质量特性定义和度量。

11. Boehm质量模型

12. ISO的软件质量评价模型 • 按照ISO/TC97/SC7/WG3/1985-1-30/N382，软件质量度量模型由三层组成： 　软件质量需求评价准则（SQRC） 　软件质量设计评价准则（SQDC） 　软件质量度量评价准则（SQMC） • 高层和中层建立国际标准，低层可由各使用单位视实际情况制定

14. 1991年 ISO质量特性国际标准 （ISO/IEC9126） • 质量特性：功能性、可靠性、可维护性、效率、可使用性、可移植性 • 推荐21个子特性：适合性 准确性 互用性 依从性 安全性 成熟性 容错性 可恢复性 可理解性 易学习性 操作性 时间特性 资源特性 可分析性 稳定性 可变更性 可测试性 可安装性 可替换性 适应性 一致性

16. 质量控制Quality Control • 差异控制可以等同于质量控制。 • “质量控制”是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。 • 质量控制在创建工作产品的过程中包含一个反馈循环。度量和反馈相结合，使得我们能够在得到的工作产品不能满足其规约时调整开发过程。这种方法将质量控制视为整个制造过程的一部分。

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

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

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

20. 质量成本可以被划分为与预防、鉴定及失败相关的成本。“预防成本”包括：质量成本可以被划分为与预防、鉴定及失败相关的成本。“预防成本”包括： * 质量计划 * 正式技术复审 * 测试设备 * 培训

21. “鉴定成本”包括为深入了解“首次通过”各个过程时产品的状态而开展的那些活动。鉴定成本的例子如下：“鉴定成本”包括为深入了解“首次通过”各个过程时产品的状态而开展的那些活动。鉴定成本的例子如下： * 过程内和过程间审查 * 设备校准和维护 * 测试

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

23. “外部失败成本”是指与产品交付给客户之后所发现的缺陷相关的成本。外部失败成本的例子如下：“外部失败成本”是指与产品交付给客户之后所发现的缺陷相关的成本。外部失败成本的例子如下： * 解决客户的抱怨 * 退换产品 * 求助电话支持 * 保修工作

24. 正如我们所预料的，发现和修改一个缺陷的相对成本将随着我们从预防到检测、到从内部失败及到外部失败的成本而急剧增加。根据Boehm所收集的数据，阐述了这一现象。正如我们所预料的，发现和修改一个缺陷的相对成本将随着我们从预防到检测、到从内部失败及到外部失败的成本而急剧增加。根据Boehm所收集的数据，阐述了这一现象。

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

27. 8.2 质量运动TheQuality Movement • 质量运动始于本世纪40年代W. Edwards Deming的开创性工作，第一次真正的实验则是在日本进行的。以Deming的想法为基础，日本人开发了一种系统化的方法来从根本上消除造成产品缺陷的原因。从70年代到80代，他们的工作被移植到西方，有时被称作“全面质量管理（TQM）”。 • 尽管不同公司和不同作者那里的术语略有不同，但通常采用的都是4个步骤的过程，该过程构成了任何一个好的TQM项目的基础。

28. 第一步是指一个连续的过程改进系统。目标是开发一个可见的、可重复的和可度量的过程（在这里是指软件过程）。第一步是指一个连续的过程改进系统。目标是开发一个可见的、可重复的和可度量的过程（在这里是指软件过程）。 • 第二步将检查影响过程的无形因素，并对这些因素对过程的影响进行优化。 　 例如，软件过程可能受到高层职员流动的影响，而这本身又是由公司内部不断重组而引起的。因此一个稳定的公司组织可能会对软件质量的提高有很大的帮助。可以帮助管理者对公司重组方式提出建议。

29. 第三步：关注产品的用户（这里的产品是指软件）。通过检查用户使用产品的方式，对产品本身及产品的生产过程进行改进。第三步：关注产品的用户（这里的产品是指软件）。通过检查用户使用产品的方式，对产品本身及产品的生产过程进行改进。 • 最后一个步骤将管理者的注意力从当前的产品上拓宽。通过观察产品在市场上的用途，寻找产品在相关领域中的发展机会。

30. 8.3 软件质量保证Software Quality Assurance • 软件质量的定义： 对显式声明的功能和性能需求、显式文档化的开发标准、以及专业人员开发的软件所应具有的所有隐含特征的符合。

31. 上述定义强调了以下三个重要方面： 1. 软件需求是进行“质量”测量的基础。与需求不符就是质量不高。 2. 指定的标准定义了一组指导软件开发的准则。如果不能遵照这些准则，就极有可能导致质量不高。 3. 通常有一组“隐含需求”是不被提及的（如对易维护性的需求）。如果软件符合了显式的需求却没有满足隐含需求，软件质量仍然值得怀疑。

32. SQA活动 • 软件质量保证由各种任务构成，这些任务分别与两种不同的参与者相关――做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。 • 软件工程师通过采用可靠的技术方法和措施、进行正式的技术复审、执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制活动）。

33. SQA小组的职责是辅助软件工程小组得到高质量的最终产品。软件工程研究所SEI推荐了一组有关质量保证中的计划、监督、记录、分析及报告的SQA活动。这些活动将由一个独立的SQA小组执行（或协助）。SQA小组的职责是辅助软件工程小组得到高质量的最终产品。软件工程研究所SEI推荐了一组有关质量保证中的计划、监督、记录、分析及报告的SQA活动。这些活动将由一个独立的SQA小组执行（或协助）。 • 为项目准备SQA计划：该计划在制定项目计划时制定，由所有感兴趣的相关部门复审。该计划将控制由软件工程小组和SQA小组执行的质量保证活动。

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

35. 参与开发该项目的软件过程描述――软件工程小组为要进行的工作选择一个过程。SQA小组将描述复审过程以保证该过程与组织政策、内部软件标准、外界所订标准（如ISO 9001）以及软件项目计划的其他部分相符。 • 复审各项软件工程活动、对其是否符合定义好的软件过程进行核实――SQA小组识别、记录和跟踪与过程的偏差，并对是否已经改正进行核实。 • 审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实――SQA小组对选出的产品进行复审；识别、记录和跟踪出现的偏差、对是否已经改正进行核实、定期将工作结果向项目管理者报告。

36. 确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理――偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理――偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。 • 记录所有不符合的部分并报告给高级管理者――不符合的部分将受到跟踪直至问题得到解决。 除进行上述活动之外，SQA小组还需要协调变化的控制和管理，并帮助收集和分析软件度量信息。

37. 8.4 软件复审Software Reviews • 软件复审是软件工程过程中的“过滤器”。复审被用于软件开发过程中的多个不同的点上，起到发现错误（进而引发排错活动）的作用。软件复审起到的作用是“净化”分析、设计和编码中所产生的软件工作产品。Freedman和Weinberg在中对复审的讨论如下： • 技术工作需要复审的理由就象铅笔需要橡皮――“人非圣贤，孰能无过”。我们需要复审的第二个理由是：尽管人善于发现自己的某些错误，但是犯错误的人自己对许多种错误的发现能力远小于其他的人。

38. 复审（任何复审）均是一种借助一组人的差异性来：复审（任何复审）均是一种借助一组人的差异性来： (1) 指出一个人或小组生产的产品所需进行的改进； (2) 确定产品中不需要或者不希望改进的部分； (3) 得到与没有进行复审相比更加一致、或者至少更可预测的技术工作的质量，从而使得技术工作更易于管理。

39. 在软件工程过程中可以进行的复审有许多种，它们各有用处。在软件工程过程中可以进行的复审有许多种，它们各有用处。 • 在饭桌上讨论技术问题的非正式会议是一种复审； • 将软件设计正式介绍给客户、管理层和技术人员也是一种复审方式。 • 正式的技术复审:有时称为“走查”（Walkthrough）或检查（Inspection）。 从质量保证的角度出发，正式的技术复审是最有效的过滤器。由软件工程师（或其他人）对软件工程师进行的正式技术复审（FTR）是一种提高软件质量的有效方法。

40. 软件缺陷对成本的影响Cost Impact of Software Defects • 在软件过程范围中，术语“缺陷”和“故障”是同义词。它们都表示在软件交付给最终用户之后发现的质量问题。 • 正式技术复审的主要目标是在此过程中发现错误，以便使的它们不会在软件发布之后变成缺陷。正式技术复审的明显优点是较早发现错误，防止错误被传播到软件过程的后续阶段。

41. 产业界的大量研究（TRW、Nippon Electric和Mitre Corp.以及其他公司）表明设计活动引入的错误占软件过程中出现的所有错误（和最终的缺陷）数量的50％到65％。 • 而现有研究表明正式技术复审在发现设计错误方面最高达到75％的有效性。通过检测和排除大量设计错误，复审过程将极大降低后续开发和维护阶段的成本。

42. 为了说明尽早发现错误对成本的影响，我们将根据从大型软件项目中收集的实际数据研究一系列的相对成本。为了说明尽早发现错误对成本的影响，我们将根据从大型软件项目中收集的实际数据研究一系列的相对成本。 • 假定在设计阶段发现的错误的改正成本为1.0个货币单位，在测试开始之前发现一个错误的改正成本为6.5个货币单位，在测试时发现一个错误的改正成本为15个货币单位，而在发布之后发现一个错误的改正成本为60到100个货币单位。

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

44. 在没有复审的软件开发过程中缺陷放大的例子。在没有复审的软件开发过程中缺陷放大的例子。 图8.3 缺陷的放大（无复审）

45. 在设计和编码过程中将复审作为每个软件过程步骤的一部分。在设计和编码过程中将复审作为每个软件过程步骤的一部分。 50% 图8.4 缺陷的放大（有复审）

46. 在每个步骤中发现的错误数量被乘以消除一个错误的成本（对设计是1.5个成本单位，测试前是6.5个成本单位，测试中是15个成本单位，而发布后是67个成本单位），在每个步骤中发现的错误数量被乘以消除一个错误的成本（对设计是1.5个成本单位，测试前是6.5个成本单位，测试中是15个成本单位，而发布后是67个成本单位）， • 使用这些数据，在进行了复审的情况下，开发和维护的总成本是783个成本单位。 • 而在不进行复审的情况下，总成本是2177个成本单位。后者几乎是前者的3倍。

47. 为了进行复审，软件工程师必须花费时间和工作量，开发组织必须投入资金。为了进行复审，软件工程师必须花费时间和工作量，开发组织必须投入资金。 • 但是上述例子的结果证明，我们面临的是一种“现在付出、否则以后付出更多”的情况。 • （设计和其他技术活动中的）正式技术复审提供了显而易见的成本效益。 • 因此，应该进行复审活动。

48. 8.5 正式技术复审Formal technical Reviews 正式技术复审（FTR）是一种由软件工程师进行的软件质量保证活动。FTR的目标是 （1）在软件的任何一种表示形式中发现功能、逻辑或实现的错误； （2）证实经过复审的软件的确满足需求； （3）保证软件的表示符合预定义的标准； （4）得到以一种一致的方式开发的软件； （5）使项目更易于管理。由于FTR的进行使大量人员对软件系统中原本并不熟悉的部分更为了解，因此，FTR还起到了提高项目连续性和培训后备人员的作用。

49. FTR(正式技术复审)实际上是一类复审方式，包括“走查”（Walkthrough）、“审查”（Inspection）、“轮查”（Round-robin Review）以及其他软件小组的技术评估。 • 每次FTR都以会议形式进行，只有经过适当的计划、控制和参与，FTR才能获得成功。

50. 复审会议The Review Meeting • 不论选择何种FTR(正式技术复审)形式，每个复审会议都应该遵守下面的约束： * 复审会议（通常）应该在3到5个人之间进行 * 应该进行提前准备，但是每人占用工作时间应该少于2小时 * 复审会议时间应该不超过2小时