软件质量保证

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

2、支持软件组织本章将集中讨论为支持软件组织“在正确的时间、在正确的时间、以正确的方式、做正确的事情以正确的方式、做正确的事情”的相关管理问题的相关管理问题和特定过程活动。和特定过程活动。8.1质量概念质量概念 Quality Conceptsn美国传统字典美国传统字典（American Heritage Dictionary）中对质量的定义是：）中对质量的定义是：“某一事物某一事物的特征或属性的特征或属性”。n作为一个事物的属性，质量指的是可以度量作为一个事物的属性，质量指的是可以度量的特征的特征那些可以与已知标准进行比较的那些可以与已知标准进行比较的东西，如长度、颜色、电的性质、可延展性东西，

3、如长度、颜色、电的性质、可延展性等等。等等。n但是软件，很大程度上是一种但是软件，很大程度上是一种知识实体知识实体，其，其特征的定义远比物理对象要困难得多。特征的定义远比物理对象要困难得多。 n程序特征的度量的确存在程序特征的度量的确存在。这样的属性包括。这样的属性包括循环循环复杂度、内聚、功能点、代码行数复杂度、内聚、功能点、代码行数和其他许多属和其他许多属性。在根据对象的可度量特征考察一个对象时，性。在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：可以有以下两种不同的质量：设计质量和符合质设计质量和符合质量。量。n设计质量设计质量：是指设计者为一件产品规定的特征。：是指设计

4、者为一件产品规定的特征。材料等级、耐久性、及性能的规约都属于设计质材料等级、耐久性、及性能的规约都属于设计质量。量。n当规定使用更高级别的材料、要求达到更强的耐当规定使用更高级别的材料、要求达到更强的耐久性和更高层次的性能时，如果产品能够依照规久性和更高层次的性能时，如果产品能够依照规约进行制造，则产品的设计质量便会提高。约进行制造，则产品的设计质量便会提高。 n符合质量符合质量：是指在制造过程中符合设计规格的：是指在制造过程中符合设计规格的程度。同样，符合程度越高，符合质量也就越程度。同样，符合程度越高，符合质量也就越高。高。n在软件开发时，在软件开发时，设计质量设计质量包括系统的需求、规包

5、括系统的需求、规约和设计。约和设计。符合质量符合质量则主要关注实现问题。如则主要关注实现问题。如果实现符合设计、得到的系统满足系统需求和果实现符合设计、得到的系统满足系统需求和性能目标，则符合质量较高。性能目标，则符合质量较高。 Boehm质量控制质量控制 Quality Controln差异控制可以等同于质量控制差异控制可以等同于质量控制。 n“质量控制质量控制”是为了保证每一件工作产品都满是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。列审查、复审和测试。n质量控制在创建工作产品的过程中包含一个反质量控制在创建

6、工作产品的过程中包含一个反馈循环。度量和反馈相结合，使得我们能够在馈循环。度量和反馈相结合，使得我们能够在得到的工作产品不能满足其规约时调整开发过得到的工作产品不能满足其规约时调整开发过程。这种方法将质量控制视为整个制造过程的程。这种方法将质量控制视为整个制造过程的一部分。一部分。 n质量控制活动可以是全自动的、全人工的，也可质量控制活动可以是全自动的、全人工的，也可以是自动工具与人员交互的结合。质量控制中的以是自动工具与人员交互的结合。质量控制中的关键概念之一是所有工作产品都具有定义好的和关键概念之一是所有工作产品都具有定义好的和可度量的规约，我们可以将每个过程的产品与这可度量的规约，我们可

7、以将每个过程的产品与这一规约进行比较。反馈循环的引入对于最小化产一规约进行比较。反馈循环的引入对于最小化产生的缺陷至关重要。生的缺陷至关重要。 n“质量保证质量保证”由管理层的审计和报告功能构成。由管理层的审计和报告功能构成。质量保证的目标是为管理层提供为获知产品质量质量保证的目标是为管理层提供为获知产品质量信息所需的数据，从而获得产品质量是否符合预信息所需的数据，从而获得产品质量是否符合预定目标的认识和信心。当然如果质量保证所提供定目标的认识和信心。当然如果质量保证所提供的数据发现了问题，则管理层负责解决这一问题的数据发现了问题，则管理层负责解决这一问题并为解决质量问题分配所需的资源。并为解

8、决质量问题分配所需的资源。质量的成本质量的成本 Cost of Qualityn质量成本包括所有由质量工作或者进行与质量有关质量成本包括所有由质量工作或者进行与质量有关的活动所导致的成本。质量成本研究的开展能够为的活动所导致的成本。质量成本研究的开展能够为当前质量成本设定基线，标识降低质量成本的机会，当前质量成本设定基线，标识降低质量成本的机会，并提供一种规范化的比较基础。规范化的基础几乎并提供一种规范化的比较基础。规范化的基础几乎全都以全都以“元元”（钱）计算。一旦我们将质量成本以（钱）计算。一旦我们将质量成本以“元元”为单位进行了规范化，我们就拥有了必要的为单位进行了规范化，我们就拥有了必

9、要的数据以评估能够在何处改进现有过程。而且，还可数据以评估能够在何处改进现有过程。而且，还可以进一步评估那些基于以进一步评估那些基于“元元”的项在改变时所产生的项在改变时所产生的影响。的影响。 n质量成本可以被划分为与预防、鉴定及失败相质量成本可以被划分为与预防、鉴定及失败相关的成本。关的成本。“预防成本预防成本”包括：包括： * 质量计划质量计划 * 正式技术复审正式技术复审 * 测试设备测试设备 * 培训培训 n“鉴定成本鉴定成本”包括为深入了解包括为深入了解“首次通过首次通过”各个过程时产品的状态而开展的那些活动。各个过程时产品的状态而开展的那些活动。鉴定成本的例子如下：鉴定成本的例子如

10、下： * 过程内和过程间审查过程内和过程间审查 * 设备校准和维护设备校准和维护 * 测试测试 n“失败成本失败成本”是指如果在将产品交付给客户之是指如果在将产品交付给客户之前已经消除了缺陷时就不会存在的成本。失败前已经消除了缺陷时就不会存在的成本。失败成本可以进一步划分为内部失败成本和外部失成本可以进一步划分为内部失败成本和外部失败成本。败成本。“内部失败成本内部失败成本”是指在产品交付之是指在产品交付之前发现错误而引发的成本。内部失败成本包前发现错误而引发的成本。内部失败成本包括：括： * 返工返工 * 修复修复 * 失败模式分析失败模式分析 n“外部失败成本外部失败成本”是指与产品交付给

11、客是指与产品交付给客户之后所发现的缺陷相关的成本。外部户之后所发现的缺陷相关的成本。外部失败成本的例子如下：失败成本的例子如下： * 解决客户的抱怨解决客户的抱怨 * 退换产品退换产品 * 求助电话支持求助电话支持 * 保修工作保修工作 n正如我们所预料的，发现和修改一个缺陷的相正如我们所预料的，发现和修改一个缺陷的相对成本将随着我们从预防到检测、到从内部失对成本将随着我们从预防到检测、到从内部失败及到外部失败的成本而急剧增加。根据败及到外部失败的成本而急剧增加。根据Boehm所收集的数据，阐述了这一现象。所收集的数据，阐述了这一现象。 nADVICE：测试是必要的，但是，它也是一种测试是必要

12、的，但是，它也是一种非常昂贵的发现错误的方式非常昂贵的发现错误的方式。在过程的早期。在过程的早期花时间发现错误，你可能能够大量地减少测花时间发现错误，你可能能够大量地减少测试和调试成本。试和调试成本。8.2 质量运动质量运动 The Quality Movementn质量运动始于本世纪质量运动始于本世纪40年代年代W. Edwards Deming的开创性工作，第一次真正的实验则是在日本进的开创性工作，第一次真正的实验则是在日本进行的。以行的。以Deming的想法为基础，日本人开发了一的想法为基础，日本人开发了一种系统化的方法来从根本上消除造成产品缺陷的种系统化的方法来从根本上消除造成产品缺陷

13、的原因。从原因。从70年代到年代到80代，他们的工作被移植到西代，他们的工作被移植到西方，有时被称作方，有时被称作“全面质量管理（全面质量管理（TQM）”。n尽管不同公司和不同作者那里的术语略有不同，尽管不同公司和不同作者那里的术语略有不同，但通常采用的都是但通常采用的都是4个步骤的过程个步骤的过程，该过程构成了，该过程构成了任何一个好的任何一个好的TQM项目的基础。项目的基础。 n第一步第一步是指是指一个连续的过程改进系统一个连续的过程改进系统。目标是开。目标是开发一个可见的、可重复的和可度量的过程（在这发一个可见的、可重复的和可度量的过程（在这里是指软件过程）。里是指软件过程）。n第二步第

14、二步将将检查影响过程的无形因素，并对这些因检查影响过程的无形因素，并对这些因素对过程的影响进行优化素对过程的影响进行优化。 例如例如，软件过程可能受到高层职员流动的影响，软件过程可能受到高层职员流动的影响，而这本身又是由公司内部不断重组而引起的。因而这本身又是由公司内部不断重组而引起的。因此一个稳定的公司组织可能会对软件质量的提高此一个稳定的公司组织可能会对软件质量的提高有很大的帮助。可以帮助管理者对公司重组方式有很大的帮助。可以帮助管理者对公司重组方式提出建议。提出建议。 n第三步第三步：关注：关注产品的用户产品的用户（这里的产品是指软（这里的产品是指软件）。通过检查用户使用产品的方式，对产

15、品本件）。通过检查用户使用产品的方式，对产品本身及产品的生产过程进行改进。身及产品的生产过程进行改进。n最后一个步骤最后一个步骤将管理者的注意力从当前的产品上将管理者的注意力从当前的产品上拓宽。通过观察产品在市场上的用途，寻找产品拓宽。通过观察产品在市场上的用途，寻找产品在相关领域中的发展机会。在相关领域中的发展机会。8.3 软件质量保证软件质量保证 Software Quality Assurancen软件质量软件质量的定义：的定义： 对显式声明的功能和性能需求、显式文档化对显式声明的功能和性能需求、显式文档化的开发标准、以及专业人员开发的软件所应具的开发标准、以及专业人员开发的软件所应具有

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

17、值需求却没有满足隐含需求，软件质量仍然值得怀疑得怀疑。 SQA活动活动 n软件质量保证由各种任务构成，这些任务分别与软件质量保证由各种任务构成，这些任务分别与两种不同的参与者相关两种不同的参与者相关做技术工作的软件工做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析程师和负责质量保证的计划、监督、记录、分析及报告工作的及报告工作的SQA小组。小组。n软件工程师通过采用可靠的技术方法和措施、进软件工程师通过采用可靠的技术方法和措施、进行正式的技术复审、执行计划周密的软件测试来行正式的技术复审、执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制考虑质量问题（并完成软件质量

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

19、程小组和将控制由软件工程小组和SQASQA小组执行的质量保小组执行的质量保证活动。证活动。在计划中要标识以下几点在计划中要标识以下几点：* 需要进行的评价需要进行的评价* 需要进行的审计和复审需要进行的审计和复审* 项目可采用的标准项目可采用的标准* 错误报告和跟踪的规程错误报告和跟踪的规程* 由由SQA小组产生的文档小组产生的文档* 为软件项目组提供的反馈数量为软件项目组提供的反馈数量 n参与开发该项目的软件过程描述参与开发该项目的软件过程描述软件工程小软件工程小组为要进行的工作选择一个过程。组为要进行的工作选择一个过程。SQA小组将描小组将描述复审过程以保证该过程与组织政策、内部软件述复审

20、过程以保证该过程与组织政策、内部软件标准、外界所订标准（如标准、外界所订标准（如ISO 9001）以及软件项）以及软件项目计划的其他部分相符目计划的其他部分相符。n复审各项软件工程活动、对其是否符合定义好的复审各项软件工程活动、对其是否符合定义好的软件过程进行核实软件过程进行核实SQA小组识别、记录和跟小组识别、记录和跟踪与过程的偏差，并对是否已经改正进行核实。踪与过程的偏差，并对是否已经改正进行核实。n审计指定的软件工作产品、对其是否符合定义好审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实的软件过程中的相应部分进行核实SQA小组小组对选出的产品进行复审；识别、记录和

21、跟踪出现对选出的产品进行复审；识别、记录和跟踪出现的偏差、对是否已经改正进行核实、定期将工作的偏差、对是否已经改正进行核实、定期将工作结果向项目管理者报告。结果向项目管理者报告。 n确保软件工作及工作产品中的偏差已被记录在案并根确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理据预定规程进行处理偏差可能出现在项目计划、偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。过程描述、采用的标准或技术工作产品中。n记录所有不符合的部分并报告给高级管理者记录所有不符合的部分并报告给高级管理者不符不符合的部分将受到跟踪直至问题得到解决。合的部分将受到跟踪直至问题得到解决。 除进行

22、上述活动之外，除进行上述活动之外，SQA小组还需要协调变化的控小组还需要协调变化的控制和管理，并帮助收集和分析软件度量信息。制和管理，并帮助收集和分析软件度量信息。 8.4 软件复审软件复审 Software Reviewsn软件复审是软件工程过程中的软件复审是软件工程过程中的“过滤器过滤器”。复审被用于软件开发过程中的多个不同的点复审被用于软件开发过程中的多个不同的点上，起到发现错误（进而引发排错活动）的上，起到发现错误（进而引发排错活动）的作用。软件复审起到的作用是作用。软件复审起到的作用是“净化净化”分析、分析、设计和编码中所产生的软件工作产品。设计和编码中所产生的软件工作产品。Free

23、dman和和Weinberg在中对复审的讨论如在中对复审的讨论如下：下：n技术工作需要复审的理由就象铅笔需要橡皮技术工作需要复审的理由就象铅笔需要橡皮“人非圣贤，孰能无过人非圣贤，孰能无过”。我们需要复。我们需要复审的第二个理由是：尽管人善于发现自己的审的第二个理由是：尽管人善于发现自己的某些错误，但是犯错误的人自己对许多种错某些错误，但是犯错误的人自己对许多种错误的发现能力远小于其他的人。误的发现能力远小于其他的人。 复审复审（任何复审）均是一种借助一组人（任何复审）均是一种借助一组人的差异性来：的差异性来： (1) 指出一个人或小组生产的产品所需进行的改进；指出一个人或小组生产的产品所需进

24、行的改进； (2) 确定产品中不需要或者不希望改进的部分；确定产品中不需要或者不希望改进的部分； (3) 得到与没有进行复审相比更加一致、或者至少更得到与没有进行复审相比更加一致、或者至少更可预测的技术工作的质量，从而使得技术工作更易可预测的技术工作的质量，从而使得技术工作更易于管理。于管理。 在软件工程过程中可以进行的复审有许多种，它们各有用在软件工程过程中可以进行的复审有许多种，它们各有用处。处。n在饭桌上讨论技术问题的非正式会议是一种复审；在饭桌上讨论技术问题的非正式会议是一种复审；n将软件设计正式介绍给客户、管理层和技术人员也是一种将软件设计正式介绍给客户、管理层和技术人员也是一种复审

25、方式。复审方式。n正式的技术复审正式的技术复审:有时称为有时称为“走查走查”（Walkthrough）或）或检查（检查（Inspection）。）。 从质量保证的角度出发，正式的技术复审是最有效的过滤从质量保证的角度出发，正式的技术复审是最有效的过滤器。由软件工程师（或其他人）对软件工程师进行的正式器。由软件工程师（或其他人）对软件工程师进行的正式技术复审（技术复审（FTR）是一种提高软件质量的有效方法。）是一种提高软件质量的有效方法。 软件缺陷对成本的影响软件缺陷对成本的影响Cost Impact of Software Defects n在软件过程范围中，术语在软件过程范围中，术语“缺陷缺

26、陷”和和“故障故障”是是同义词。它们都表示在软件交付给最终用户之后同义词。它们都表示在软件交付给最终用户之后发现的质量问题。发现的质量问题。n正式技术复审的主要目标是在此过程中发现错误，正式技术复审的主要目标是在此过程中发现错误，以便使的它们不会在软件发布之后变成缺陷。正以便使的它们不会在软件发布之后变成缺陷。正式技术复审的明显优点是较早发现错误，防止错式技术复审的明显优点是较早发现错误，防止错误被传播到软件过程的后续阶段。误被传播到软件过程的后续阶段。 n产业界的大量研究（产业界的大量研究（TRW、Nippon Electric和和Mitre Corp.以及其他公司）表明以及其他公司）表明设

27、计活动引入的设计活动引入的错误占软件过程中出现的所有错误（和最终的缺错误占软件过程中出现的所有错误（和最终的缺陷）数量的陷）数量的50到到65。n而现有研究表明而现有研究表明正式技术复审在发现设计错误方正式技术复审在发现设计错误方面最高达到面最高达到75的有效性的有效性。通过检测和排除大量。通过检测和排除大量设计错误，复审过程将极大降低后续开发和维护设计错误，复审过程将极大降低后续开发和维护阶段的成本。阶段的成本。 n为了说明尽早发现错误对成本的影响，我们将根为了说明尽早发现错误对成本的影响，我们将根据从大型软件项目中收集的实际数据研究一系列据从大型软件项目中收集的实际数据研究一系列的相对成本

28、的相对成本。n假定在假定在设计阶段发现的错误的改正成本为设计阶段发现的错误的改正成本为1.0个个货币单位，在货币单位，在测试开始之前发现一个错误的改正测试开始之前发现一个错误的改正成本为成本为6.5个货币单位，在个货币单位，在测试时发现一个错误测试时发现一个错误的改正成本为的改正成本为15个货币单位，而在个货币单位，而在发布之后发现发布之后发现一个错误的改正成本为一个错误的改正成本为60到到100个货币单位。个货币单位。 缺陷的放大和消除缺陷的放大和消除Defect Amplification and Removal n可以用可以用“缺陷放大模型缺陷放大模型”IBM81来说明在软件工程过程中来

29、说明在软件工程过程中的概要设计、详细设计和编码阶段中错误的产生及检测。的概要设计、详细设计和编码阶段中错误的产生及检测。n在没有复审的软件开发过程中缺陷放大的例子。在没有复审的软件开发过程中缺陷放大的例子。图图8.3 缺陷的放大（无复审）缺陷的放大（无复审）n在设计和编码过程中将复审作为每个软件过程步骤在设计和编码过程中将复审作为每个软件过程步骤的一部分。的一部分。图图8.4 缺陷的放大（有复审）缺陷的放大（有复审）50%n在每个步骤中发现的错误数量被乘以消除一个错在每个步骤中发现的错误数量被乘以消除一个错误的成本（对设计是误的成本（对设计是1.5个成本单位，测试前是个成本单位，测试前是6.5

30、个成本单位，测试中是个成本单位，测试中是15个成本单位，而发个成本单位，而发布后是布后是67个成本单位），个成本单位），n使用这些数据，在进行了复审的情况下，开发和使用这些数据，在进行了复审的情况下，开发和维护的总成本是维护的总成本是783个成本单位。个成本单位。n而在不进行复审的情况下，总成本是而在不进行复审的情况下，总成本是2177个成本个成本单位。单位。后者几乎是前者的后者几乎是前者的3倍倍。 n为了进行复审，软件工程师必须花费时间和工为了进行复审，软件工程师必须花费时间和工作量，开发组织必须投入资金。作量，开发组织必须投入资金。n但是上述例子的结果证明，我们面临的是一种但是上述例子的结

31、果证明，我们面临的是一种“现在付出、否则以后付出更多现在付出、否则以后付出更多”的情况。的情况。n（设计和其他技术活动中的）正式技术复审提（设计和其他技术活动中的）正式技术复审提供了显而易见的成本效益。供了显而易见的成本效益。n因此因此，应该进行复审活动。应该进行复审活动。 8.5 正式技术复审正式技术复审Formal technical Reviews 正式技术复审（正式技术复审（FTR）是一种由软件工程师进行）是一种由软件工程师进行的的软件质量保证活动软件质量保证活动。FTR的的目标目标是是（1）在软件的任何一种表示形式中发现功能、逻辑）在软件的任何一种表示形式中发现功能、逻辑或实现的错误

32、；或实现的错误；（2）证实经过复审的软件的确满足需求；）证实经过复审的软件的确满足需求；（3）保证软件的表示符合预定义的标准；）保证软件的表示符合预定义的标准；（4）得到以一种一致的方式开发的软件；）得到以一种一致的方式开发的软件；（5）使项目更易于管理）使项目更易于管理。由于。由于FTR的进行使大量人的进行使大量人员对软件系统中原本并不熟悉的部分更为了解，员对软件系统中原本并不熟悉的部分更为了解，因此，因此，FTR还起到了提高项目连续性和培训后备还起到了提高项目连续性和培训后备人员的作用。人员的作用。nFTR(正式技术复审正式技术复审)实际上是一类复审方式，包括实际上是一类复审方式，包括“走

33、查走查”（Walkthrough）、）、“审查审查”（Inspection）、）、“轮查轮查”（Round-robin Review）以及其他软件小组的技术评估。）以及其他软件小组的技术评估。n每次每次FTR都以会议形式进行，只有经过适当的计划、都以会议形式进行，只有经过适当的计划、控制和参与，控制和参与，FTR才能获得成功。才能获得成功。复审会议复审会议 The Review Meetingn不论选择何种不论选择何种FTR(正式技术复审正式技术复审)形式，每个形式，每个复审会议都应该遵守下面的约束：复审会议都应该遵守下面的约束： * 复审会议（通常）应该在复审会议（通常）应该在3到到5个人之

34、间进行个人之间进行 * 应该进行提前准备，但是每人占用工作时间应该进行提前准备，但是每人占用工作时间应该少于应该少于2小时小时 * 复审会议时间应该不超过复审会议时间应该不超过2小时小时 n在上述约束之下，显然在上述约束之下，显然FTRFTR应该关注的应该关注的是整个软件中的某个特定（且较小）部是整个软件中的某个特定（且较小）部分。分。 例如例如，不要试图复审整个设计，而是对，不要试图复审整个设计，而是对每个模块或者一小组模块进行走查。当每个模块或者一小组模块进行走查。当FTRFTR的关注范围较小时，发现错误的可的关注范围较小时，发现错误的可能性更大。能性更大。 在复审结束时，所有在复审结束时

35、，所有FTR的与会者必须作出以下的与会者必须作出以下决定中的一个：决定中的一个：（1）工作产品可以不经修改而被接受；）工作产品可以不经修改而被接受；（2）由于严重错误而否决工作产品（错误改正后）由于严重错误而否决工作产品（错误改正后必须再次进行复审）；或必须再次进行复审）；或（3）暂时接受工作产品（发现必须改正的微小错）暂时接受工作产品（发现必须改正的微小错误，但是不再需要进一步复审）。作出决定之后，误，但是不再需要进一步复审）。作出决定之后，所有所有FTR与会者需要与会者需要“签名签名”，以表示他们参加，以表示他们参加了此次了此次FTR,并且同意复审小组所作的决定。并且同意复审小组所作的决定

36、。 复审报告和记录保存复审报告和记录保存 Review Reporting and Record Keepingn在在FTRFTR期间，一名复审者（记录员）主动记录所期间，一名复审者（记录员）主动记录所有提出的问题。在复审会议结束时，对这些问有提出的问题。在复审会议结束时，对这些问题进行总结，并生成一份题进行总结，并生成一份“复审问题列表复审问题列表”。此外，还要完成一份简单的此外，还要完成一份简单的“复审总结报告复审总结报告”。复审总结报告将回答以下问题：复审总结报告将回答以下问题：1.1. 复审什么？复审什么？2. 2. 由谁复审？由谁复审？3. 3. 发现和结论是什么？发现和结论是什么？

37、 n复审总结报告通常是一页纸大小（可能还有附件）。复审总结报告通常是一页纸大小（可能还有附件）。它是项目历史记录的一部分，有可能被分发给项目它是项目历史记录的一部分，有可能被分发给项目管理者和其他感兴趣的参与方。管理者和其他感兴趣的参与方。n复审问题列表有两个作用复审问题列表有两个作用：(1) 标识产品中存在问题的区域；标识产品中存在问题的区域；(2) 用作用作“行动条目行动条目”检查表以指导生产者进行改正。检查表以指导生产者进行改正。建立一个跟踪规程以保证问题列表中的每一项建立一个跟踪规程以保证问题列表中的每一项条目都得到适当的改正条目都得到适当的改正。只有做到这一点，才能保。只有做到这一点

38、，才能保证提出的问题真正得到控制。证提出的问题真正得到控制。复审指南复审指南 Review Guidelines进行正式技术复审之前必须建立复审指南，进行正式技术复审之前必须建立复审指南，分发给所有复审者，并得到大家的认可，然后才分发给所有复审者，并得到大家的认可，然后才能依照它进行复审。能依照它进行复审。ADVICE：不要严厉地指出错误。一种温和地方式：不要严厉地指出错误。一种温和地方式是问一个问题，以使得生产者能够发现他自己的是问一个问题，以使得生产者能够发现他自己的错误。错误。 1. 复审产品，而不是复审生产者复审产品，而不是复审生产者。FTR涉及到涉及到别人和自我。如果进行得适当，别人

39、和自我。如果进行得适当，FTR可以使所有可以使所有参与者体会到温暖的成就感。如果进行得不适当，参与者体会到温暖的成就感。如果进行得不适当，则可能陷入一种审问的气氛之中。则可能陷入一种审问的气氛之中。复审主席应该引导复审会议以保证会议始终复审主席应该引导复审会议以保证会议始终处于适当的气氛和态度之中，在讨论失去控制时处于适当的气氛和态度之中，在讨论失去控制时应立即休会。应立即休会。 2. 制定日程并且遵守日程制定日程并且遵守日程。各种类型的会议都具。各种类型的会议都具有一个主要缺点：放任自流。有一个主要缺点：放任自流。FTR必须保证不要必须保证不要离题和按照计划进行。复审主席被赋予维持会议离题和

40、按照计划进行。复审主席被赋予维持会议程序的责任，在有人转移话题时应该提醒他。程序的责任，在有人转移话题时应该提醒他。 3. 限制争论和辩驳限制争论和辩驳。在复审者提出问题时，未必。在复审者提出问题时，未必所有人都认同该问题的严重性。不要花时间争论所有人都认同该问题的严重性。不要花时间争论这一问题，这样的问题应该被记录在案，留到会这一问题，这样的问题应该被记录在案，留到会后进一步讨论。后进一步讨论。 4. 对各个问题都发表见解，但是不要试图解决对各个问题都发表见解，但是不要试图解决所有记录的问题所有记录的问题。复审不是一个问题解决会议。复审不是一个问题解决会议。问题的解决通常由生产者自己，或者在

41、其他人问题的解决通常由生产者自己，或者在其他人的帮助下来完成。问题解决应该放到复审会议的帮助下来完成。问题解决应该放到复审会议之后进行。之后进行。 5. 作书面笔记作书面笔记。 6. 限制参与者人数并坚持事先作准备限制参与者人数并坚持事先作准备。 7. 为每个可能要复审的工作产品建立一个检查表为每个可能要复审的工作产品建立一个检查表。检查表能够帮助复审主席组织检查表能够帮助复审主席组织FTR会议，并帮助会议，并帮助每个复审者将注意力集中在重要问题上。应该为每个复审者将注意力集中在重要问题上。应该为分析、设计、编码、甚至测试文档都建立检查表。分析、设计、编码、甚至测试文档都建立检查表。 8. 为

42、为FTR分配资源和时间分配资源和时间。为了让复审有效，应。为了让复审有效，应该将复审作为软件工程过程中的任务加以调度。该将复审作为软件工程过程中的任务加以调度。而且要为由复审结果而导致的修改活动分配时间。而且要为由复审结果而导致的修改活动分配时间。 9. 对所有复审者进行有意义的培训对所有复审者进行有意义的培训。为了提高效率，所有。为了提高效率，所有复审参与者都应该接受某种正式培训。复审参与者都应该接受某种正式培训。 10. 复审以前所作的复审复审以前所作的复审。听取汇报对发现复审过程本身的。听取汇报对发现复审过程本身的问题十分有益。最早被复审的工作产品应该是复审指南本问题十分有益。最早被复审

43、的工作产品应该是复审指南本身。身。 由于成功的复审涉及到许多变数（由于成功的复审涉及到许多变数（如，参与者数量、工作如，参与者数量、工作产品类型、时间和长度、特定的复审方法等）产品类型、时间和长度、特定的复审方法等），软件组织，软件组织应该在实验中决定何种方法最为适用。应该在实验中决定何种方法最为适用。8.6 SQA的形式化方法的形式化方法Formal Approaches to SQA n在过去的在过去的20年中，在软件界中有一群虽然很少但年中，在软件界中有一群虽然很少但是很坚决的人们，提出软件质量保证应该采用一是很坚决的人们，提出软件质量保证应该采用一种更为种更为形式化的方法形式化的方法。

44、一个计算机程序可以看作。一个计算机程序可以看作一个数学对象一个数学对象。 n对于每一种程序设计语言都能够定义一套严格的对于每一种程序设计语言都能够定义一套严格的语法和语义，且对于软件需求规格说明也出现了语法和语义，且对于软件需求规格说明也出现了一种类似的严格方法。一种类似的严格方法。n一旦需求模型（规约）和程序设计语言以一种一旦需求模型（规约）和程序设计语言以一种严格的方式被表达出来，就可以采用程序正确严格的方式被表达出来，就可以采用程序正确性的数学证明来说明程序是否严格符合它的规性的数学证明来说明程序是否严格符合它的规约。约。n程序正确性证明程序正确性证明不是一个新的思路。不是一个新的思路。

45、Dijkstra和和Linger、Mills及及Witt，以及其他很多人都支，以及其他很多人都支持程序正确性的数学证明，并将它与结构化程持程序正确性的数学证明，并将它与结构化程序设计概念联系在一起。序设计概念联系在一起。 8.7统计软件质量保证统计软件质量保证 Statistical Quality Assurancen统计质量保证反映了一种在产业界不断增长的趋统计质量保证反映了一种在产业界不断增长的趋势：质量的量化。对于软件而言，势：质量的量化。对于软件而言，统计质量保证统计质量保证包括以下步骤：包括以下步骤： 1. 收集和分类软件缺陷信息。收集和分类软件缺陷信息。 2. 尝试对每个缺陷的形

46、成原因（例如，不符合规尝试对每个缺陷的形成原因（例如，不符合规约、设计错误、违背标准、与客户通信不力等）约、设计错误、违背标准、与客户通信不力等）进行追溯。进行追溯。 3. 使用使用Pareto原则（原则（80的缺陷可以追溯到所有的缺陷可以追溯到所有可能原因中的可能原因中的20），将这），将这20（重要的少数）（重要的少数）分离出来。分离出来。4. 一旦标识出重要的少数原因，就可以开始纠正一旦标识出重要的少数原因，就可以开始纠正引起缺陷的问题引起缺陷的问题。所有错误都可以追溯到下述原因中的一个所有错误都可以追溯到下述原因中的一个(或几个或几个):* 规约不完整或规约错误规约不完整或规约错误（i

47、ncomplete or erroneous specifications，IES）* 与客户通信中所产生的误解与客户通信中所产生的误解（misinterpretation of customer communication，MCC）* 故意与规约偏离故意与规约偏离（intentional deviation from specification，IDS）* 违反编程标准违反编程标准（violation of programming standards，VPS）* 数据表示有错数据表示有错（error in data representation，EDR）* 构件接口不一致构件接口不一致（in

48、consistent component interface，ICI） * 设计逻辑有错设计逻辑有错（error in design logic，EDL）* 不完整或错误的测试不完整或错误的测试（incomplete or erroneous testing，IET）* 不准确或不完整的文档不准确或不完整的文档（inaccurate or incomplete documentation，IID）* 将设计翻译成程序设计语言中的错误将设计翻译成程序设计语言中的错误（error in programming language translation of design，PLT）* 不清晰或不一致

49、的人机界面不清晰或不一致的人机界面（ambiguous or inconsistent human/computer interface，HCI）* 杂项杂项（miscellaneous，MIS） 表表8-1n重要的是要注意，纠正性动作主要注重于重要的是要注意，纠正性动作主要注重于“重重要的少数要的少数”。随着少数重要原因的不断改正，。随着少数重要原因的不断改正，新的候选错误原因也将被提到改进日程上来。新的候选错误原因也将被提到改进日程上来。n软件的统计质量保证技术已经被证明提供了实软件的统计质量保证技术已经被证明提供了实质性的质量改善。质性的质量改善。n在某些情形，在应用这些技术后，软件组织

50、已在某些情形，在应用这些技术后，软件组织已经达到了经达到了50%的年缺陷减少。的年缺陷减少。 n当与缺陷信息集合结合使用时，软件开发者可以当与缺陷信息集合结合使用时，软件开发者可以为软件工程过程中的每个步骤计算为软件工程过程中的每个步骤计算“错误指标错误指标”（Error index，EI）。在经过分析、设计、编码、）。在经过分析、设计、编码、测试和发布之后，将收集到以下数据：测试和发布之后，将收集到以下数据：Ei 在软件工程过程中的第在软件工程过程中的第i步中发现的错误总数步中发现的错误总数Si 严重错误数严重错误数Mi 一般错误数一般错误数Ti 微小错误数微小错误数PS 第第i步的产品规模

51、（步的产品规模（LOC、设计陈述、文档页、设计陈述、文档页数）数） nWs、Wm、Wt分别是严重、一般、微小错误的加分别是严重、一般、微小错误的加权因子，其推荐取值为权因子，其推荐取值为 Ws10 Wm3 Wt1。n随着过程的进展，每个阶段的加权因子取值逐渐随着过程的进展，每个阶段的加权因子取值逐渐变大。也就是说，尽早发现错误的组织得益较多。变大。也就是说，尽早发现错误的组织得益较多。n在软件工程过程中的每一步中，分别计算各个阶在软件工程过程中的每一步中，分别计算各个阶段的阶段指标（段的阶段指标（phase index）PIi： PIi = Ws (Si/Ei) + Wm (Mi/Ei) +

52、Wt (Ti/Ei) n错误指标错误指标EI通过计算各个通过计算各个PIi的加权效果得到，在的加权效果得到，在软件工程过程中后面的步骤中遇到的错误的权重要软件工程过程中后面的步骤中遇到的错误的权重要高于在前面阶段遇到的错误权重。高于在前面阶段遇到的错误权重。 EI = (iPIi)/PS = (PI1+2PI2+3PI3+iPIi)/PSn错误指标与表错误指标与表8.1中收集的信息相结合，可以得出中收集的信息相结合，可以得出软件质量的整体改进指标软件质量的整体改进指标。n统计统计SQA的应用及的应用及Pareto规则可以用一句话概括：规则可以用一句话概括：将时间集中用于真正重要的地方，但是首先

53、你必须将时间集中用于真正重要的地方，但是首先你必须知道什么是重要的知道什么是重要的。 8.8软件可靠性软件可靠性 Software Reliability n软件可靠性是软件可靠性是“在特定环境和特定时间内，计在特定环境和特定时间内，计算机程序无故障地运行的概率算机程序无故障地运行的概率”。 举例说明举例说明，程序，程序X在在8个小时处理占用时间中的个小时处理占用时间中的可靠性估计为可靠性估计为0.96；也就是说，如果程序；也就是说，如果程序X执行执行100次，每次运行次，每次运行8个小时的处理占用时间（执个小时的处理占用时间（执行时间），则行时间），则100次中正确运行（不失败）的次次中正确

54、运行（不失败）的次数可能是数可能是96。 可靠性和可用性的测量可靠性和可用性的测量Measures of Reliability and Availability n当我们考虑一个基于计算机的系统时，当我们考虑一个基于计算机的系统时，可靠性的简可靠性的简单度量是单度量是“平均失效间隔时间平均失效间隔时间”（MTBF），其中：，其中： MTBF MTTF MTTR MTTF （Mean-Time-To-Failure）和和MTTR （Mean-Time-To-Repair）分别是分别是“平均失效时间平均失效时间”和和“平均修复时间平均修复时间”。 n许多研究人员认为许多研究人员认为MTBF是一个

55、远比是一个远比“缺陷缺陷数数/KLOC”或或“缺陷数缺陷数/FP”更为有用的度更为有用的度量指标量指标。 简而言之，最终用户关心的是失效，而不是简而言之，最终用户关心的是失效，而不是总缺陷数。总缺陷数。n由于一个程序中包含的每个缺陷所具有的失效率不由于一个程序中包含的每个缺陷所具有的失效率不同，总缺陷数难以表示系统的可靠性。同，总缺陷数难以表示系统的可靠性。比如比如考虑一考虑一个已经投入运行个已经投入运行14个月的程序，程序中的许多缺陷个月的程序，程序中的许多缺陷的暴露需要经过几年的运行时间。这种隐藏缺陷的的暴露需要经过几年的运行时间。这种隐藏缺陷的MTBF可能是可能是50到到100年。年。

56、n还有一些尚未被发现的缺陷的失败率可能是还有一些尚未被发现的缺陷的失败率可能是18或或24个月。即使全部排除第一种缺陷（具有较长个月。即使全部排除第一种缺陷（具有较长MTBF的缺陷），对软件可靠性的影响也微乎其微。的缺陷），对软件可靠性的影响也微乎其微。n除可靠性度量之外，我们必须开发一个除可靠性度量之外，我们必须开发一个“可用性可用性”度量。软件可用性是指在某个给定时间点上程序度量。软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为：能够按照需求执行的概率。其定义为：可用性可用性 MTTF / (MTTF MTTR) 100nMTBF可靠性度量对可靠性度量对MTTF和和MT

57、TR同样敏感。而同样敏感。而可用性度量在某种程度上对可用性度量在某种程度上对MTTR较为敏感，较为敏感，MTTR是软件可维护性的间接度量。是软件可维护性的间接度量。 软件安全性（软件安全性（Software Safety） n“软件安全性软件安全性”是集中于解决潜在危险（是集中于解决潜在危险（这些这些危险将负面影响软件系统并导致整个系统失效危险将负面影响软件系统并导致整个系统失效）的标识和评估问题的软件质量保证活动。的标识和评估问题的软件质量保证活动。n如果能够在软件工程过程的早期标识这些危险，如果能够在软件工程过程的早期标识这些危险，则可以指定软件设计特性以排除或控制潜在的则可以指定软件设计

58、特性以排除或控制潜在的危险。危险。 n建模和分析过程可以视为软件安全性的一部分。建模和分析过程可以视为软件安全性的一部分。开始时，根据关键性和风险来标识和分类危险。开始时，根据关键性和风险来标识和分类危险。例如，与基于计算机的汽车驾驶控制相关的危例如，与基于计算机的汽车驾驶控制相关的危险可能有：险可能有：* 导致不受控制的加速使得不能停止导致不受控制的加速使得不能停止* 当刹车踏板踩下后不能制动当刹车踏板踩下后不能制动* 开关激活后不能启动开关激活后不能启动* 加速或减速缓慢加速或减速缓慢 n一旦这些系统级的危险被标识出来，就可以使用一旦这些系统级的危险被标识出来，就可以使用分析技术指定这些危

59、险发生的严重性和概率。分析技术指定这些危险发生的严重性和概率。n为了真正有效，软件应该被置于整个系统中进行为了真正有效，软件应该被置于整个系统中进行分析。分析。例如例如，一个微小的用户输入错误可能被软，一个微小的用户输入错误可能被软件错误放大成产生将机械设备置于不正确位置的件错误放大成产生将机械设备置于不正确位置的控制数据。如果满足一组外部环境条件（而且仅控制数据。如果满足一组外部环境条件（而且仅当满足这些条件时），机械设备的不正确位置将当满足这些条件时），机械设备的不正确位置将引发灾难性的失败。引发灾难性的失败。n故障树分析、实时逻辑或故障树分析、实时逻辑或Petri网模型等分析技术网模型等

60、分析技术可以用于预测可能引起危险的事件链，以及事件可以用于预测可能引起危险的事件链，以及事件链中的各个事件出现的概率链中的各个事件出现的概率。 n危险标识和分析完成之后，就可以进行软件中与危险标识和分析完成之后，就可以进行软件中与安全性相关的需求进行规格说明了。安全性相关的需求进行规格说明了。n尽管软件可靠性与软件安全性相互之间关系紧密，尽管软件可靠性与软件安全性相互之间关系紧密，但是理解它们之间的微妙差异更为重要。但是理解它们之间的微妙差异更为重要。n软件可靠性使用统计分析方法确定软件失效发生软件可靠性使用统计分析方法确定软件失效发生的可能性的可能性；而失效的发生未必导致危险或灾难。；而失效