Download presentation
Presentation is loading. Please wait.
1
第 14 章 软件质量评价和保证 14.1 软件质量概述 14.2 质量度量模型 14.3 软件复杂性 14.4 软件可靠性
第 14 章 软件质量评价和保证 14.1 软件质量概述 14.2 质量度量模型 14.3 软件复杂性 14.4 软件可靠性 14.5 软件评审 14.6 软件容错技术 返回主目录
2
第14章 软件质量评价和保证 14.1 软件质量概述 14.1.1 软件质量的定义
14.1 软件质量概述 软件质量的定义 软件质量是贯穿软件生存期的一个极为重要的问题，关于软件质量的定义有多种说法，从实际应用来说，软件质量定义如下： (1) 与所确定的功能和性能需求的一致性。 (2) 与所成文的开发标准的一致性。 (3) 与所有专业开发的软件所期望的隐含特性的一致性。 上述软件质量定义反映了以下 3 个方面的问题：
3
(1) 软件需求是度量软件质量的基础。 不符合需求的软件就不具备质量。
(2) 专门的标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。 (3) 往往会有一些隐含的需求没有明确地提出来。 例如， 软件应具备良好的可维护性。如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求，软件质量也不能保证。 软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。
4
软件质量的度量和评价 一般说， 影响软件质量的因素可以分为如下两大类： (1) 可以直接度量的因素， 如单位时间内千行代码（KLOC）中所产生的错误数。 (2) 只能间接度量的因素， 如可用性或可维护性。 在软件开发和维护过程中，为了定量地评价软件质量， 必须对软件质量特性进行度量，以测定软件具有要求质量特性的程度。1976年，Boehm等人提出了定量评价软件质量的层次模型(见图14.1)；1978年Walters和McCall提出了从软件质量要素、 准则到度量的 3 个层次式的软件质量度量模型(见图14.2)； G.Murine根据上述等人的工作， 提出软件质量度量（SQM）技术(见图14.3)，用来定量评价软件质量。
5
图 Boehm软件质量度量模型
6
图 McCall软件质量度量模型
7
软件质量保证 1. 软件质量保证的含义 软件的质量保证就是向用户及社会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质量活动， 即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括的主要功能有：质量方针的制定；质量保证方针和质量保证标准的制定；质量保证体系的建立和管理； 明确各阶段的质量保证工作；各阶段的质量评审；确保设计质量；重要质量问题的提出与分析； 总结实现阶段的质量保证活动；整理面向用户的文档、说明书等；产品质量鉴定、质量保证系统鉴定；质量信息的收集、分析和使用。
8
2. 质量保证的策略 质量保证策略的发展大致可以分为以下 3 个阶段： (1) 以检测为重。产品制成后才进行检测，这种检测只能判断产品的质量，不能提高产品质量。 (2) 以过程管理为重。 把质量保证工作重点放在过程管理上，对制造过程的每一道工序都进行质量控制。 (3) 以新产品开发为重。许多产品的质量问题源于新产品的开发设计阶段，因此在产品开发设计阶段就应采取有力措施， 以便消灭由于设计原因而产生的质量隐患。 由上可知，软件质量保证应从项目计划和设计开始，直到投入使用和售后服务的软件生存期的每一阶段中的每一步骤。
9
3. 质量保证的主要任务 为了提高软件的质量， 软件质量保证的任务大致可归结为以下几点： (1) 正确定义用户要求: 软件质量保证人员必须正确定义用户所要求的技术。必须十分重视领导全体开发人员收集和积累有关用户业务领域的各种业务资料和技术技能。 (2) 技术方法的应用: 开发新软件的方法，最普遍公认的成功方法就是软件工程学的方法。标准化、设计方法论、工具化等都属此列。 应当在开发新软件的过程中大力使用和推行软件工程学中所介绍的开发方法和工具。 (3) 提高软件开发的工程能力: 只有高水平的软件工程能力才能生产出高质量的软件产品。
10
因此须在软件开发环境或软件工具箱的支持下， 运用先进的开发技术、工具和管理方法提高开发软件的能力。
(4) 软件的复用: 利用已有的软件成果是提高软件质量和软件生产率的重要途径。不要只考虑如何开发新软件，首先应考虑哪些已有软件可以复用，并在开发过程中，随时考虑所生产软件的复用性。 (5) 发挥每个开发者的能力: 软件生产是人的智能生产活动， 它依赖于开发组织团队的能力。开发者必须有学习各专业业务知识、 生产技术和管理技术的能动性。管理者或产品服务者要制定技术培训计划、技术水平标准，以及适用于将来需要的中长期技术培训计划。
11
(6) 组织外部力量协作: 一个软件自始至终由一软件开发单位来开发也许是最理想的, 在现实中难以做到。因此需要改善对外部协作部门的开发管理, 必须明确规定进度管理、质量管理、 交接检查和维护体制等各方面的要求，建立跟踪检查的体制。 (7) 排除无效劳动：最大的无效劳动是因需求说明有误、 设计有误而造成的返工。定量记录返工工作量，收集和分析返工劳动花费的数据非常重要。另一种较大的无效劳动是重复劳动，即相似的软件在几个地方同时开发。 这多是因项目开发计划不当，或者开发信息不流畅造成的。为此，要建立互相交流、信息往来通畅和具有横向交流特征的信息流通网。
12
(8) 提高计划和管理质量：对于大型软件项目来说， 提高工程项目管理能力是极其重要的。必须重视项目开发初期计划阶段的项目计划评价、计划执行过程中及计划完成报告的评价将评价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。 4. 质量保证与检验 软件质量必须在设计和实现过程中加以保证。如果工程能力不够，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。 因此须在软件开发工程的各个阶段实施检验。检验的实施有实际运行检验（即白盒测试和黑盒测试）和鉴定两种形式, 可在各开发阶段中结合起来使用。
13
14.2 质量度量模型 14.2.1 McCall 质量度量模型
14.2 质量度量模型 McCall 质量度量模型 McCall质量度量模型是McCall等人于1979年提出的软件质量模型，如图 14.2 所示。 针对面向软件产品的运行、修正和转移，软件质量概念包括如下11个特性。 1) 面向软件产品运行 面向软件产品运行的定义如下： (1) 正确性： 指软件满足设计说明及用户预期目标的程度。 (2) 可靠性： 指软件按照设计要求， 在规定时间和条件下不出故障，持续运行的程度。
14
(3) 效率： 为了完成预定功能， 软件系统所需的计算机资源和程序代码数量的程度。
(4) 完整性： 对非授权人访问软件或数据行为的控制程度。 (5) 可用性： 用户熟悉、 使用及准备输入和解释输出所需工作量的大小。 2) 面向软件产品修正 面向软件产品修正的定义如下： (1) 可维护性： 指找到并改正程序中的一个错误所需代价的程度。 (2) 可测试性： 指测试软件以确保其能够执行预定功能所需工作量的程度。
15
(3) 适应性： 指修改或改进一个已投入运行的软件所需工作量的程度。
3) 面向软件产品转移 面向软件产品转移的定义如下： (1) 可移植性： 指将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量。 (2) 可重用性： 指一个软件（或软件的部件）能再次用于其他相关应用的程度。 (3) 可互操作性： 指将一个系统耦合到另一个系统所需的工作量。
16
通常，对以上各个质量特性直接进行度量是很困难的， 在有些情况下甚至是不可能的。因此，McCall定义了一些评价准则，使用它们对反映质量特性的软件属性分级，以此来估计软件质量特性的值。软件属性一般分级范围从0（最低）～10（最高）。 主要评价准则定义如下： (1) 可跟踪性: 指跟踪一个设计说明或一个实际程序部件返回到需求的能力（可追溯）。 (2) 完备性： 指所需功能实现的程度。 (3) 一致性： 指在整个软件开发项目中使用统一的设计和文档编制技术的程度。 (4) 安全性： 指防止软件受到意外的或蓄意的存取、 使用、 修改及毁坏，或防止失密的程度。
17
(5) 容错性： 是在系统出错时，能以某种预定方式，做出适当处理，得以继续执行和恢复系统的能力，它又称为健壮性。 (6) 准确性： 指能达到的计算或控制精度， 又称为精确性。 (7) 可审查性： 指检查与标准是否符合的难易程度。 (8) 可操作性： 指软件操作的难易程度。 (9) 可训练性： 指软件使新用户使用该系统的辅助程度。 (10) 简洁性： 在不复杂、 可理解的方式下， 定义和实现软件功能的程度。 (11) 简明性：又称可理解性，指软件易读的程度。 (12) 模块性：指软件系统内部接口达到的高内聚、低耦合的程度。
18
(13) 自描述性：对软件功能进行自身说明的程度。
(14) 通用性：指软件功能覆盖面宽广的程度。 (15) 可扩充性：指软件的体系结构、 数据设计和过程设计的可扩充的程度。 (16) 硬件独立性：指不依赖于某个特定设备及计算机而能工作的程度。 (17) 通信共用性：指使用标准接口、协议和带宽的程度。 (18) 数据共用性：指使用标准数据结构和数据类型的程度。
19
ISO的软件质量评价模型 按照ISO/TC97/SC7/WG3/ /N382， 软件质量度量模型由 3 层组成， 如图14.3所示。 高层是软件质量需求评价准则（SQRC）。 中层是软件质量设计评价准则（SQDC）。 低层是软件质量度量评价准则（SQMC）。 ISO认为， 应对高层和中层建立国际标准，在国际范围内推广软件质量管理（SQM）技术, 而低层可由各使用单位视实际情况制定。ISO的 3 层次模型来自McCall等人的模型。高层、中层和低层分别对应于McCall模型中的特性、 度量准则和度量。 其中SQRC由8个元素组成。
20
图14.3 ISO的3层模型
21
按1991年ISO发布的ISO/IEC9126质量特性国际标准， SQRC已降为6个。在这个标准中，3 层次中的第一层称为质量特性，第二层称为质量子特性，第三层称为度量。
22
14.3 软 件 复 杂 性 软件复杂性的基本概念 软件度量的一个重要分支就是软件复杂性度量。对于软件复杂性，至今尚无一种公认的精确定义。软件复杂性与质量属性有着密切的关系， 从某些方面反映了软件的可维护性、可靠性等质量要素。软件复杂性度量的参数很多，主要有如下几种： (1) 规模： 即总共的指令数， 或源程序行数。 (2) 难度： 通常由程序中出现的操作数的数目所决定的量来表示。 (3) 结构： 通常用与程序结构有关的度量来表示。 (4) 智能度： 即算法的难易程度。
23
软件复杂性主要表现在程序的复杂性。 程序的复杂性主要指模块内程序的复杂性，它直接关联到软件开发费用的多少、 开发周期长短和软件内部潜伏错误的多少，同时它也是软件可理解性的另一种度量。
减少程序复杂性，可提高软件的简单性和可理解性，并使软件开发费用减少，开发周期缩短，软件内部潜藏错误减少。 为了度量程序复杂性， 要求复杂性度量满足以下假设： (1) 它可以用来计算任何一个程序的复杂性。 (2) 对于不合理的程序，例如对于长度动态增长的程序， 或者对于原则上无法排错的程序，不应当使用它进行复杂性计算。
24
(3) 如果程序中指令条数、附加存储量及计算时间增多， 不会减少程序的复杂性。
25
软件复杂性的度量方法 1. 代码行度量法 度量程序的复杂性，最简单的方法就是统计程序的源代码行数。此方法的基本考虑是统计一个程序的源代码行数，并以源代码行数作为程序复杂性的度量。 若设每行代码的出错率为每100行源程序中可能的错误数目， 例如每行代码的出错率为1%，则是指每100行源程序中可能有一个错误。Thayer曾指出，程序出错率的估算范围是从0.04%~7%之间，即每100行源程序中可能存在0.04~7个错误。 他还指出， 每行代码的出错率与源程序行数之间不存在简单的线性关系。 Lipow进一步指出，对小程序，每行代码的出错率为1.3%~1.8%；对于大程序，每行代码的出错率增加到2.7%~3.2%之间。
26
但这只是考虑了程序的可执行部分，没有包括程序中的说明部分。 Lipow及其他研究者得出一个结论: 对于少于100个语句的小程序，源代码行数与出错率是线性相关的； 随着程序的增大，出错率以非线性方式增长。所以，代码行度量法只是一个简单的， 估计得很粗糙的方法。 2. McCabe度量法 McCabe度量法是一种基于程序控制流的复杂性度量方法。 McCabe复杂性度量又称环路度量，它认为程序的复杂性很大程度上取决于控制的复杂性，单一的顺序程序结构最为简单，循环和选择所构成的环路越多，程序就越复杂。这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。
27
程序图是退化的程序流程图，即把程序流程图中每个处理符号都退化成一个结点，原来联结不同处理符号的流线变成连接不同结点的有向弧，得到的有向图就叫做程序图。
程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作以及分支和循环的具体条件。因此，它往往把一个简单的IF语句与循环语句的复杂性看成是一样的，把嵌套的IF语句与CASE语句的复杂性看成是一样的。下面给出计算环路复杂性的方法。 根据图论， 在一个强连通的有向图G中， 环的个数V（G）由以下公式给出： V（G）=m-n+2p
28
其中，V（G）是有向图G中环路数，m是图G中弧数， n是图G中结点数，p是G中的强连通分量个数。 在一个程序中， 从程序图的入口点总能到达图中任何一个结点，因此，程序总是连通的，但不是强连通的。为了使图成为强连通图， 从图的入口点到出口点加一条用虚线表示的有向边，使图成为强连通图。 这样就可以使用上式计算环路复杂性了。 在图14.4所给出的示例中， 结点数n=6， 弧数m=9， p=1， 则有： V（G）=m-n+2p=9-6+2=5
29
即McCabe环路复杂度度量值为5。另一种简单的方法是程序图的拓扑结构把平面划分为封闭区域和开放区域的个数。在图14
即McCabe环路复杂度度量值为5。另一种简单的方法是程序图的拓扑结构把平面划分为封闭区域和开放区域的个数。在图14.4中， 有4个封闭区域和1个开放区域， 共5个区域，则V(G)=5。 当分支或循环的数目增加时，程序中的环路也随之增加， 因此McCabe环路复杂度量值实际上是为软件测试的难易程序提供了一个定量度量的方法， 同时也间接地表示了软件的可靠性。 实验表明，源程序中存在的错误数以及为了诊断和纠正这些错误所需的时间与McCabe环路复杂度度量值有明显的关系。
30
图 程序图的复杂性
31
利用McCabe环路复杂度度量时， 有以下几点说明：
(1) 环路复杂度取决于程序控制结构的复杂度。 当程序的分支数目或循环数目增加时其复杂度也增加。环路复杂度与程序中覆盖的路径条数有关。 (2) 环路复杂度是可加的。例如，模块A的复杂度为3，模块B的复杂度为4， 则模块A与模块B的复杂度是7。 (3) McCabe建议， 对于复杂度超过10的程序， 应分成几个小程序， 以减少程序中的错误。
32
McCabe复杂度度量的缺点有如下几种：
(1) 对于不同种类的控制流的复杂性不能区分。 (2) 简单IF语句与循环语句的复杂性同等看待。 (3) 嵌套IF语句与简单CASE语句的复杂性是一样的。 (4) 模块间接口当成一个简单分支一样处理。 (5) 一个具有1000行的顺序程序与一行语句的复杂性相同。 尽管McCabe复杂度度量法有许多缺点， 但它容易使用， 而且在选择方案和估计排错费用等方面都是很有效的。
33
14.4 软 件 可 靠 性 软件可靠性定义 软件可靠性表明了一个程序按照用户的要求和设计的目标， 执行其功能的正确程度。 一个可靠的程序应要求是正确的、完整的、 一致的和健壮的。现实中，一个程序要达到完全可靠是不实际的，要精确地度量它也不现实。在一般情形下只能通过程序的测试，去度量程序的可靠性。软件可靠性是指在给定的时间内，在规定的环境条件下系统完成所指定功能的概率。
34
软件可靠性指标 软件可靠性与可用性的定量指标，是指能够以数字概念来描述可靠性的数学表达式中所使用的量。人们常借用硬件可靠性的定量度量方法来度量软件的可靠性与可用性。下面主要讨论常用指标平均失效等待时间MTTF与平均失效间隔时间MTBF。 1) MTTF(Mean Time To Failure) 假如对n个相同的系统（硬件或者软件）进行测试， 他们的失效时间分别是t1, t2, …， tn, 则平均失效等待时间MTTF定义为：
35
对于软件系统来说，这相当于同一系统在n个不同的环境（即使用不同的测试用例）下进行测试。因此，MTTF是一个描述失效模型或一组失效特性的指标量。这个指标的目标值应由用户给出，在需求分析阶段纳入可靠性需求， 作为软件规格说明提交给开发部门。在运行阶段，可把失效率函数λ(t)视为常数λ，则平均失效等待时间MTTF是失效率λ的倒数： MTTF=1/λ。
36
软件可靠性模型 对软件可靠性数学理论的研究尝试，已经产生了一些有希望的可靠性模型。软件可靠性模型通常有可靠性增长模型、 基于程序内部特性的模型和植入模型。 1. 可靠性增长模型 可靠性增长模型是由硬件可靠性理论导出的模型，计算机硬件可靠性度量之一是它的稳定可用程度，用其错误出现和纠正的速率来表示。令MTTF是机器的平均无故障时间。 MTTR是错误的平均修复时间，则机器的稳定可用性可定义为： A=MTTF/(MTTF+MTTR) 源于硬件可靠性工作的模型有如下假设：
37
(1) 错误出现之间的调试时间与错误出现率呈指数分布， 而错误出现率和剩余错误数呈正比。
(2) 每个错误一经发现， 立即排除。 (3) 错误之间的故障率为常数。 对软件来说， 每个假设的合法性可能还是个问题。例如， 纠正一个错误的同时可能不当心而引入另一些错误，这样第二个假设显然并不总是成立。 可靠性增长模型的基本思想是一个错误发现并改正后， 它的可靠性有一个定值的增长。
38
2. 基于程序内部特性的模型 基于程序内部特性的可靠性模型计算存在于软件中的错误的预计数。根据软件复杂性度量函数导出的定量关系， 这类模型建立了程序的面向代码的属性（如操作符和操作数的数目）与程序中错误的初始估计数字之间的关系。它以程序结构为基础，分析程序内部结构、分支的数目、嵌套的层数及引用的数据类型，以这些结构的数据作为模型的参数，使用多元线性回归分析，从而预测程序的错误数目。 3. 植入模型 这是由D.Mills提出的模型。它是在软件中“植入”已知的错误，在历经一段时间的测试之后, 可以发现错误，并计算发现的植入错误数与发现的实际错误数之比。
39
设程序中隐含的错误总数为N， 随机将一些已知的带标记的错误植入程序，植入的错误总数为Nt，经测试后，发现隐含的错误总数为n；发现植入错误总数为nt，假定植入错误和程序中的残留错误都可以同等难易地被测试到， 则有： Nt/(N+Nt)=nt/(n+nt) 而Nt, n, nt是已知的， 就可求出程序中隐含的错误总数N： N=(n/nt)·Nt 这种模型依赖于测试技术。但如何判定哪些错误是程序的残留错误, 哪些是植入带记号的错误, 不是件容易的事。 而且植入带标记的错误有可能导致新的错误。
40
还有其他一些软件可靠性模型, 例如外延式。 关于软件可靠性模型的研究工作尚在初始阶段。
41
14.5 软件评审 人的认识不可能100%符合客观实际，因此在软件生存期每个阶段的工作中都可能引入人为的错误。在某一阶段中出现的错误， 如果得不到及时纠正，就会传播到开发的后续阶段中去， 并在后续阶段中引出更多的错误。对软件工程过程来说， 软件评审是一个“过滤器”，在软件开发的各个阶段都要采用评审的方法， 以暴露软件中的缺陷，然后加以改正。 通常，把“质量”理解为“用户满意程度”。 为使得用户满意，有两个必要条件： (1) 设计的规格说明书要符合用户的要求。 (2) 程序要按照设计规格说明所规定的情况正确执行。
42
我们把上述条件（1）称为“设计质量”， 把条件（2）称为“程序质量”。 过去多把程序质量当做设计质量，但优秀的程序质量是构成好的软件质量的必要条件，但不是充分条件。 软件的规格说明分为外部规格说明和内部规格说明。 外部规格说明是从用户角度来看的规格，包括硬件/软件系统设计（在分析阶段进行）、功能设计（在需求分析阶段与概要设计阶段进行）。而内部规格说明是为了实现外部规格的更详细的规格，即软件模块结构与模块处理过程的设计（在概要设计与详细设计阶段进行）。 因此，内部规格说明是从开发者角度来看的规格说明。将上述两个概念联系起来， 设计质量是由外部规格说明决定的，程序质量是由内部规格说明决定的。
43
设计质量的评审内容 设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明，在软件概要设计阶段产生的软件概要设计说明书等。通常需要从以下几个方面进行评审: (1) 评价软件的规格说明是否合乎用户的要求， 即总体设计思想和设计方针是否正确， 需求规格说明是否得到了用户或单位上级机关的批准；需求规格说明与软件的概要设计规格说明是否一致等。 (2) 评审可靠性，即是否能避免输入异常（错误或超载等）、硬件失效及软件失效所产生的失效，一旦发生应能及时采取代替手段或恢复手段。
44
(3) 评审保密措施实现情况， 即是否提供对使用系统资格、 对特定数据的使用资格及特殊功能的使用资格进行检查，在查出有违反使用资格情况后，能否向系统管理人员报告有关信息， 是否提供对系统内重要数据加密的功能。 (4) 评审操作特性实施情况，即操作命令和操作信息的恰当性，输入数据与输入控制语句的恰当性，输出数据的恰当性， 应答时间的恰当性等。 (5) 评审性能实现情况。 (6) 评审软件是否具有可修改性、 可扩充性、 可互换性和可移植性。 (7) 评审软件是否具有可测试性。 (8) 评审软件是否具有复用性。
45
程序质量的评审内容 程序质量评审通常是从开发者的角度进行评审，直接与开发技术有关。它是着眼于软件本身的结构、与运行环境的接口及变更带来的影响而进行的评审活动。 1. 软件的结构 为了使得软件能够满足设计规格说明中的要求，软件结构本身必须是优秀的，应包括功能结构、功能的通用性、模块的层次、 模块结构及处理过程的结构等功能。
46
1) 功能结构 在软件的各种结构中，功能结构是用户惟一能见到的结构。因此，功能结构可以说是联系用户跟开发者的规格说明，它在软件的设计中占有极其重要的地位。 (2) 功能结构：包括功能名和定义，可构成该功能的子功能及功能与子功能之间的关系。 (3) 数据结构和功能结构之间的对应关系： 包括数据元素与功能元素之间的对应关系。 (4) 数据结构与功能结构的一致性。
47
2) 功能的通用性 在软件的功能结构中，某些功能有时可以做为通用功能反复出现多次。从功能便于理解、增强软件的通用性及降低开发的工作量等观点出发，希望尽可能多的使功能通用化。检查功能通用性项目包括：抽象数据结构（包括抽象数据的名称和定义, 抽象数据构成元素的定义)及抽象功能结构。 3) 模块的层次 模块的层次是指程序模块结构。 由于模块是功能的具体体现，所以模块层次应当根据功能层次来设计。
48
4) 模块结构 上述的模块层次结构是模块的静态结构。 现在要检查模块间的动态结构。模块分为处理模块和数据模块两类，模块间的动态结构也与这些模块分类有关。对这样的模块结构进行检查的项目如下所示： (1) 控制流结构： 规定了处理模块与处理模块之间的流程关系。检查处理模块之间的控制转移关系与控制转移形式（调用方式）。 (2) 数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模块与数据模块之间的对应关系； 处理模块与数据模块之间的存取关系, 如建立、删除、查询及修改等。
49
(3) 模块结构与功能结构之间的对应关系： 包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系， 每个模块的定义(包括功能、输入与输出数据)。
5) 处理过程的结构 处理过程是最基本的加工逻辑过程。 对它的检查项目有： 要求模块的功能结构与实现这些功能的处理过程的结构应明确对应；要求控制流应是结构化的； 数据的结构与控制流之间的对应关系应是明确的，并且可依这种对应关系来明确数据流程的关系；用于描述的术语应标准化。
50
2. 与运行环境的接口 运行环境包括硬件、其他软件和用户。与运行环境的接口应设计得较理想，要预见到环境的改变，并且一旦要变更时， 应尽量限定其变更范围和变更所影响的范围。主要检查项目有： (1) 与硬件的接口: 包括与硬件的接口约定， 即根据硬件的使用说明等所做出的规定；硬件故障时的处理和超载时的处理。 (2) 与用户的接口: 包括与用户的接口规定； 输入数据的结构；输出数据的结构；异常输入时的处理；超载输入时的处理； 用户存取资格的检查。 随着软件运行环境的变更，软件的规格也在跟着不断地变更。运行环境变更时的影响范围，需要从以下 3 个方面来分析：
51
(1) 与运行环境的接口， 是变更的重要原因。
(2) 在每项设计工程规格内的影响：即在每个软件结构范围内的影响。例如，若是改变某一功能，则与之相联系的父功能和它的子功能都会受到影响。如果要变更某一模块，则调用该模块的其他模块都会受到影响。 (3) 在设计工程相互间影响：指不同种类的软件结构相互间的影响。例如，当改变某一功能时，就会影响到模块的层次及模块结构，这些多模块的处理过程都将产生影响。
52
14.6 软件容错技术 14.6.1 容错软件定义 归纳容错软件的定义， 有以下 4 种：
14.6 软件容错技术 容错软件定义 归纳容错软件的定义， 有以下 4 种： (1) 规定功能的软件， 在一定程度上对自身错误的作用（软件错误）具有屏蔽能力，则称此软件为具有容错功能的软件， 即容错软件。 (2) 规定功能的软件，在一定程度上能从错误状态自动恢复到正常状态， 则称之为容错软件。 (3) 规定功能的软件， 在因错误而发生错误时， 仍然能在一定程度上完成预期的功能，则把该软件称为容错软件。
53
(4) 规定功能的软件， 在一定程度上具有容错能力， 则称之为容错软件。
54
容错的一般方法 实现容错技术的主要手段是冗余。冗余是指实现系统规定功能是多余的那部分资源，包括硬件、软件、信息和时间。由于加入了这些资源，有可能使系统的可靠性得到较大的提高。 通常冗余技术分为 4 类。 1. 结构冗余 结构冗余是通常用的冗余技术。按其工作方式，它分为静态、动态和混合冗余 3 种。 (1) 静态冗余: 常用的有三模冗余TMR（Triple Moduler Redundancy）和多模冗余。
55
静态冗余通过表决和比较来屏蔽系统中出现的错误。三模冗余是对 3 个功能相同但由不同的人采用不同的方法开发出来的模块的运行结果通过表决，以多数结果作为系统的最终结果。 即如果模块中有一个出错，这个错误能够被其他模块的正确结果“屏蔽”。由于无需对错误进行特别的测试，也不必进行模块的切换就能实现容错， 故称为静态容错。 (2) 动态冗余: 其主要方式是多重模块待机储备，当系统检测到某工作模块出现错误时，就用一个备用的模块来顶替它并重新运行。这里须有检测、切换和恢复过程，故称其为动态冗余。
56
每当一个出错模块被其备用模块顶替后，冗余系统相当于进行了一次重构。 各备用模块在其待机时，可与主模块一样工作， 也可不工作。前者叫做热备份系统，后者叫做冷备份系统。 在热备份系统中，备用模块在待机过程中其失效率为0。 (3) 混合冗余： 兼有静态冗余和动态冗余的长处。 2. 信息冗余 为检测或纠正信息在运算或传输中的错误，须另外加一部分信息，这种现象称为信息冗余。在通信和计算机系统中，信息常以编码的形式出现。 采用奇偶码、定重码及循环码等冗余码制式就可以发现甚至纠正这些错误。为了达到此目的，这些码（统称误差校正码）的码长远远超过不考虑误差校正时的码长，增加了计算量和信道占用的时间。
57
3. 时间冗余 时间冗余是指以重复执行指令（指令复执）或程序（程序复算）来消除瞬时错误带来的影响。对于复执不成功的情况， 通常的处理办法是发出中断， 转入错误处理程序，或对程序进行复算，或重新组合系统，或放弃程序处理。在程序复算中较常用的方法是程序滚回技术。 4. 冗余附加技术 冗余附加技术是指为实现上述冗余技术所需的资源和技术。 包括程序、指令、数据、存放和调动它们的空间和通道等。在没有容错要求的系统中，它们是不需要的；但在容错系统中， 它们是必不可少的。
58
在屏蔽硬件错误的冗错技术中， 冗余附加技术包括：
(1) 关键程序和数据的冗余存储和调用。 (2) 检测、 表决、 切换、 重构、 纠错和复算的实现。 由于硬件出错对软件可能带来破坏作用， 例如导致进程混乱或数据丢失等。因此，对它们做预防性的冗余存储十分必要。 在屏蔽软件错误的冗错系统中， 冗余附加件的构成包括： (1) 冗余备份程序的存储及调用。 (2) 实现错误检测和错误恢复的程序。 (3) 实现容错软件所需的固化程序。 容错消耗了资源， 但换来对系统正确运行的保护。这与那种由于设计不当而造成资源浪费的冗余不同。
59
容错软件的设计过程 容错系统的设计过程包括以下设计步骤: (1) 按设计任务要求进行常规设计， 尽量保证设计的正确。 按常规设计得到非容错结构，它是容错系统构成的基础。 在结构冗余中，不论是主模块还是备用模块的设计和实现，都要在费用许可的条件下，用调试的方法尽可能提高可靠性。 (2) 对可能出现的错误分类， 确定实现容错的范围。 对可能发生的错误进行正确的判断和分类，例如，对于硬件的瞬时错误，可以采用指令复执和程序复算；对于永久错误， 则需要采用备份替换或者系统重构。
60
对于软件来说，只有最大限度地弄清错误发生和暴露的规律，才能正确地判断和分类， 实现成功的容错。
(3) 按照“成本-效率”最优原则，选用某种冗余手段（结构、 信息、 时间）来实现对各类错误的屏蔽。 (4) 分析或验证上述冗余结构的容错效果。如果效果没有达到预期的程度，则应重新进行冗余结构设计。如此反复，直到有一个满意的结果为止。
Similar presentations
