welcome to my blog!我每天都会纪录我学习的点点滴滴,也希望各位前辈多指教.

试论软件的可靠性及其保证

上一篇 / 下一篇 2007-04-13 09:57:31 / 个人分类：study

软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，在一些关键的应用领域，如航空、航天等，其可靠性要求尤为重要，在银行等服务性行业，其软件系统的可靠性也直接关系到自身的声誉和生存发展竞争能力。
　　特别是软件可靠性比硬件可靠性更难保证，会严重影响整个系统的可靠性。在许多项目开发过程中，对可靠性没有提出明确的要求，开发商(部门)也不在可靠性方面花更多的精力，往往只注重速度、结果的正确性和用户界面的友好性等，而忽略了可靠性。在投入使用后才发现大量可靠性问题，增加了维护困难和工作量，严重时只有束之高阁，无法投入实际使用。
一. 软件可靠性与硬件可靠性的区别
　　软件可靠性与硬件可靠性之间主要存在以下区别:
　　1.最明显的是硬件有老化损耗现象，硬件失效是物理故障，是器件物理变化的必然结果，有浴盆曲线现象；软件不发生变化，没有磨损现象，有陈旧落后的问题，没有浴盆曲线现象。
　　2.硬件可靠性的决定因素是时间，受设计、生产、运用的所有过程影响，软件可靠性的决定因素是与输入数据有关的软件差错，是输入数据和程序内部状态的函数，更多地决定于人。
　　3.硬件的纠错维护可通过修复或更换失效的系统重新恢复功能，软件只有通过重设计。
　　4.对硬件可采用预防性维护技术预防故障，采用断开失效部件的办法诊断故障，而软件则不能采用这些技术。
　　5.事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。
　　6.为提高硬件可靠性可采用冗余技术，而同一软件的冗余不能提高可靠性。
　　7.硬件可靠性检验方法已建立，并已标准化且有一整套完整的理论，而软件可靠性验证方法仍未建立，更没有完整的理论体系。
　　8.硬件可靠性已有成熟的产品市场，而软件产品市场还很新。
　　9.软件错误是永恒的，可重现的，而一些瞬间的硬件错误可能会被误认为是软件错误。
　　总的说来，软件可靠性比硬件可靠性更难保证，即使是美国宇航局的软件系统，其可靠性仍比硬件可靠性低一个数量级。
二. 影响软件可靠性的因素
　　软件可靠性是关于软件能够够满足需求功能的性质，软件不能满足需求是因为软件中的差错引起了软件故障。软件中有哪些可能的差错呢?
　　软件差错是软件开发各阶段潜入的人为错误：
　　1.需求分析定义错误。如用户提出的需求不完整，用户需求的变更未及时消化，软件开发者和用户对需求的理解不同等等。
　　2.设计错误。如处理的结构和算法错误，缺乏对特殊情况和错误处理的考虑等。
　　3.编码错误。如语法错误，变量初始化错误等。
　　4.测试错误。如数据准备错误，测试用例错误等。
　　5.文档错误。如文档不齐全，文档相关内容不一致，文档版本不一致，缺乏完整性等。
　　从上游到下游，错误的影响是发散的，所以要尽量把错误消除在开发前期阶段。
　　错误引入软件的方式可归纳为两种特性：程序代码特性，开发过程特性。
　　程序代码一个最直观的特性是长度，另外还有算法和语句结构等，程序代码越长，结构越复杂，其可靠性越难保证。
　　开发过程特性包括采用的工程技术和使用的工具，也包括开发者个人的业务经历水平等。
　　除了软件可靠性外，影响可靠性的另一个重要因素是健壮性，对非法输入的容错能力。
　　所以提高可靠性从原理上看就是要减少错误和提高健壮性。
三. 提高软件可靠性的方法和技术
　　1.建立以可靠性为核心的质量标准
　　在软件项目规划和需求分析阶段就要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护性、可移植性、安全性、吞吐率等等，虽然还没有一个衡量软件质量的完整体系，但还是可以通过一定的指标来指定标准基线。
　　软件质量从构成因素上可分为产品质量和过程质量。
　　产品质量是软件成品的质量，包括各类文档、编码的可读性、可靠性、正确性，用户需求的满足程度等。
　　过程质量是开发过程环境的质量，与所采用的技术、开发人员的素质、开发的组织交流、开发设备的利用率等因素有关。
　　还可把质量分为动态质量和静态质量。静态质量是通过审查各开发过程的成果来确认的质量，包括模块化程度、简易程度、完整程度等内容。动态质量是考察运行状况来确认的质量，包括平均故障间隔时间(MTBF)、软件故障修复时间(MTRF)、可用资源的利用率。在许多实际工程中，人们一般比较重视动态质量而忽视静态质量。
　　所定的质量标准度量，至少应达到以下两个目的:
　　(1).明确划分各开发过程(需求分析过程，设计过程，测试过程，验收过程)，通过质量检验的反馈作用确保差错及早排除并保证一定的质量。
　　(2).在各开发过程中实施进度管理，产生阶段质量评价报告，对不合要求的产品及早采取对策。
　　确定划分的各开发过程的质量度量：
　　(1).需求分析质量度量
　　需求分析定义是否完整、准确(有无二义性)，开发者和用户间有没有理解不同的情况，文档完成情况等，要有明确的可靠性需求目标、分析设计及可靠性管理措施等。
　　(2).设计结果质量度量
　　设计工时，程序容量和可读性、可理解性，测试情况数，评价结果，文档完成情况等。
　　(3).测试结果质量度量
　　测试工时，差错状况，差错数量，差错检出率及残存差错数，差错影响评价，文档等，以及有关非法输入的处理度量。
　　(4).验收结果质量度量
　　完成的功能数量，各项性能指标，可靠性等。
　　最后选择一种可靠度增长曲线预测模型，如时间测量、个体测量、可用性，在后期开发过程中，用来计算可靠度增长曲线的差错收敛度。
　　在建立质量标准之后，设计质量报告及评价表，在整个开发过程中就要严格实施并及时作出质量评价，填写报告表。
　　2. 选择开发方法
　　软件开发方法对软件的可靠性也有重要影响。
　　目前的软件开发方法主要有Parnas方法、Yourdon方法、面向数据结构的Jackson方法和Warnier方法、PSL/PSA方法、原型化方法、面向对象方法、可视化方法、ICASE方法、瑞理开发方法等，其他还有BSP方法、CSF方法等。这里特别要提一下的是Parnas方法。
　　Parnas方法是最早的软件开发方法，是Parnas 在1972年提出来的，基本思想是在概要设计时预先估计未来可能发生变化，提出了信息隐藏的原则以提高软件的可靠性和可维护性。
　　在设计中要求先列出将来可能要变化的因素，在划分模块时将一些可能发生变化的因素隐含在某个模块的内部，使其他模块与此无关，这样就提高了软件的可维护性，避免了错误的蔓延，也就提高了软件的可靠性。还提出了提高可靠性的措施：
　　(1)考虑到硬件有可能出故障，接近硬件的模块要对硬件行为进行检查，及时发现错误。
　　(2)考虑到操作人员有可能失误，输入模块对输入数据进行合法性检查，是否合法、越权，及时纠错。
　　(3)考虑到软件本身有可能失误，加强模块间检查，防止错误蔓延。
　　对瑞理方法可能许多人还不熟悉，这里简要介绍一下。
瑞理（Rational)模式是美国瑞理软件工程公司发展出来的，其模式是：
　　面向对象；
　　螺旋式上升；
　　管理与控制；
　　高度自动化；
　　以管理观点和技术观点把软件生命周期划分为起始、规划、建构、转移、进化五个阶段，也可把这五个阶段归并为研究时期（起始和规划）和生产时期（建构和转移），最后是维护时期（进化），特别适合对高风险部分及变动需求的处理。
　　在以上的众多方法中，可视化方法主要用于与图形有关的应用，目前的可视化开发工具只能提供用户界面的可视化开发，对一些不需要复杂图形界面的应用不必使用这种方法；ICASE 技术还没有完全成熟，所以可视在方法和ICASE方法最多只能用作辅助方法。面向数据结构的方法、PSL/PSA方法及原型化方法只适合于中小型系统的开发。
　　面向对象的方法便于软件复杂性控制，有利于生产率的提高，符合人类的思维习惯，能自然地表达现实世界的实体和问题，具有一种自然的模型化能力，达到从问题空间到解空间的较为直接自然的映射。
　　在面向对象的方法中，由于大量使用具有高可靠性的库，其可靠性也就有了保证，用面向对象的方法也利于实现软件重用。
　　所以建议采用面向对象的方法，借鉴Parnas和瑞理模式的思想，在开发过程中再结合使用其他方法，吸取其它方法的优点。
　　3.软件重用
　　最大限度地重用现有的成熟软件，不仅能缩短开发周期，提高开发效率，也能提高软件的可维护性和可靠性。因为现有的成熟软件，已经过严格的运行检测，大量的错误已在开发、运行和维护过程中排除，应该是比较可靠的。在项目规划开始阶段就要把软件重用列入工作中不可缺少的一部分，作为提高可靠性的一种必要手段。
　　软件重用不仅仅是指软件本身，也可以是软件的开发思想方法、文档，甚至环境、数据等，包括三个方面内容的重用：
　　(1)开发过程重用，指开发规范、各种开发方法、工具和标准等。
　　(2)软件构件重用，指文档、程序和数据等。
　　(3)知识重用，如相关领域专业知识的重用。
　　一般用的比较多的是软件构件重用。
　　软件重用的过程如下：候选，选择，资格，分类和存储，查找和检索。在选择可重用构件时，一定要有严格的选择标准，可重用的构件必须是经过严格测试的、甚至是经过可靠性和正确性证明的构件，应模块化（实现单一、的完整的功能）、结构清晰（可读、可理解、规模适当），且有高度可适应性。
　　4.使用开发管理工具
开发一个大的软件系统，离不开开发管理工具，作为一个项目管理员，仅仅靠人来管理是不够的，需要有开发管理工具来辅助解决开发过程中遇到的各种各样的问题，以提高开发效率和产品质量。
　　如Intersolv公司的PVCS软件开发管理工具，在美国市场占有率已超过70％，使用PVCS可以带来不少好处：规范开发过程，缩短开发周期，减少开发成本，降低项目投资风险；自动创造完整的文档，便于软件维护；管理软件多重版本；管理和追踪开发过程中危及软件质量和影响开发周期的缺陷和变化，便于软件重用，避免数据丢失，也便于开发人员的交流，对提高软件可靠性，保证质量有很大作用。
　　在我国，开发管理工具并没有得到有效地使用，许多软件公司还停留在人工管理阶段，所开发的软件质量不会很高。
　　人的管理比较困难，在保证开发人员素质的同时，要保持人员的稳定性，尽可能避免人员的经常流动。人员流动影响了软件的质量，工作连续性难保证，继承者不可能对情况了解很清楚等，也可能影响工作进程等。PVCS也提供了适当的人员管理方法。
　　5.加强测试
　　软件开发前期各阶段完成之后，为进一步提高可靠性，只有通过加强测试来实现了。为最大限度地除去软件中的差错，改进软件的可靠性，就要对软件进行完备测试。要对一个大的软件系统进行完备测试是不可能的，所以要确定一个最小测试数和最大测试数，前者是技术性的决策，后者管理性的决策，在实际过程中要确定一个测试数量的下界。总的来说，要在可能的情况下，进行尽可能完备的测试。
　　谁来做测试呢？一般说来，用户不大可能来进行模块测试，模块测试应该由最初编写代码的程序员来进行，要在他们之间交换程序进行模块测试，自己设计的程序自己测试一般都达不到好的效果。
　　测试前要确定测试标准、规范，测试过程中要建立完整的测试文档，把软件置于配置控制下，用形式化的步骤去改变它，保证任何错误及对错误的动作都能及时归档。
　　测试规范包括以下三类文档：
　　(1)测试设计规范：详细描述测试方法，规定该设计及其有关测试所包括的特性。还应规定完成测试所需的测试用例和测试规程，规定特性的通过/失败判定准则。
　　(2)测试用例规范：列出用于输入的具体值及预期输出结果。规定在使用具体测试用例时对测试规程的各种限制。
　　(3)测试规程规范：规定对于运行该系统和执行指定的测试用例来实现有关测试所要求的所有步骤。
　　测试的方法多种多样：
　　(1)走查（Walk-through），即手工执行，由不同的程序员(非该模块设计者)读代码，并进行评论。
　　(2)机器测试，对给定的输入不会产生不合逻辑的输出。
　　(3)程序证明或交替程序表示。
　　(4)模拟测试，模拟硬件、I/O设备等。
　　(5)设计审查，关于设计的所有各方面的小组讨论会，利用所获得的信息，找出缺陷及违反标准的地方等。
　　以上可以交替并行循环执行，在实际测试过程中要使用测试工具提高效率。
　　除正常的测试之外，还要对软件进行可靠性测试，确保软件中没有对可靠性影响较大的故障。制定测试计划方案，按实际使用的概率分布随机选择输入，准确记录运行时间和结果，并对结果进行评价。
　　没有错误的程序同永动机一样是不可能达到的。一般常用排错方法有试探法、追溯法、归纳法、演绎法。还要使用适当的排错工具，如UNIX提供的sdb和dbx编码排错工具，这些排错工具只有浏览功能，没有修改功能，是实际的找错工具。
　　6.容错设计
　　提高可靠性的技术一般可以分为两类，一类是避免故障，在开发过程中，尽可能不让差错和缺陷潜入软件，这类常用的技术有：
　　算法模型化，把可以保证正确实现需求规格的算法模型化。
　　模拟模型化，为了保证在确定的资源条件下的预测性能的发挥，使软件运行时间、内存使用量及控制执行模型化。
　　可靠性模型，使用可靠性模型，从差错发生频度出发，预测可靠性。
　　正确性证明，使用形式符号及数学归纳法等证明算法的正确性。
　　软件危险分析与故障树分析：从设计或编码的结构出发，追踪软件开发过程中潜入系统缺陷的原因。
　　分布接口需求规格说明：在设计的各阶段使用形式的接口需求规格说明，以便验证需求的分布接口实现可能性与完备性。
　　这些技术一般都需要比较深厚的数学理论知识和模型化技术。
　　另一类就是采用冗余思想的容错技术。
　　容错技术的基本思想是使软件内潜在的差错对可靠性的影响缩小控制到最低程度。
　　软件的容错从原理上可分为错误分析、破坏程度断定、错误恢复、错误处理四个阶段。
　　常用的软件容错技术有N-版本技术、恢复块技术、多备份技术等。
　　N-版本程序设计是依据相同规范要求独立设计N个功能相等的程序(即版本)。独立是指使用不同的算法，不同的设计语言，不同的测试技术，甚至不同的指令系统等。
　　恢复块技术是使用自动前向错误恢复的故障处理技术。
　　以上这些技术可参考有关文献，这里要说的是防错性程序设计，在程序中进行错误检查。被动的防错性技术是当到达检查点时，检查一个计算机程序的适当点的信息。主动的防错性技术是周期性地搜查整个程序或数据，或在空闲时间寻找不寻常的条件。采用防错性程序设计，是建立在程序员相信自己设计的软件中肯定有错误这一基础上的，有的程序员可能对此不大习惯，因为他可能太相信自己，相信自己的程序只有很少错误，甚至没有错误，作为一个项目管理员应该能说服他或者强制他采用这种技术，虽然在设计时要花费一定的时间，但这对提高可靠性很有用。

用户菜单

我的栏目

标题搜索

日历

我的存档

数据统计

访问量: 61007
日志数: 76
图片数: 1
建立时间: 2007-03-07
更新时间: 2008-05-31