软件可靠性工程学综述(2)

对领域故障数据的分析，有５步：１）数据预处理；２）数据分析；３）模型结构识别和参数估计；４）模型求解；５）模型分析。３．５方法和工具

除了软件可靠性增长建模外，ＳＲＥ还有许多其他方法。接下来给出方法和工具的一些实例。

故障树提供了图形化和逻辑框架，系统地分析故障模式。故障树技术起源于硬件系统，扩展到软件系统，它能够为硬件／软件协同设计提供统一的建模方案。为硬件一软件交互的可靠性建模是目前一个研究热点［３“。

ＳＲＥ仿真技术假设给定的环境代表了影响因素，仿真方法的结果就会代表实际软件环境中的结果［”］。仿真技术通过实验来分析软件故障和其他软件度量之间关系的本质。另一种可靠性模拟方法［１３］产生与可靠性相关的行为和事件的时间轴模拟。

已经开发了不同的ＳＲＥ度量工具来进行数据收集、可靠性分析、参数估计、模型的应用和可靠性估计。改进这些工具，也是对ＳＲＥ的改进。需要提供工具和环境，支持开发人员建立可靠的软件。工具、环境和技术的划分，应该反映目前最好的ＳＲＥ实践的合理应用。３．６测试效果和代码覆盖

软件测试是软件可靠性工程学中排除错误的典型机制，它已成为工业界中确保质量和改善可靠性的广泛实践。有人提出用代码覆盖指示软件测试的充分程度，它也广泛用于表示错误覆盖。

尽管代码覆盖和错误覆盖呈现出同时增长的现象，但这到底能够归结为代码覆盖和错误检测之间的因果依赖，还是

２】

两种度量的累计本质的巧合？在对此问题的研究中，进行了与蒙特卡罗模拟有关的实验，假设在代码覆盖和错误检测之间没有因果依赖［４１｜。发表的数据的测试结果支持在代码覆盖和错误覆盖之间无因果依赖。但许多研究人员将覆盖作为软件测试效果的可靠指标。３．７测试和操作剖面

操作剖面有助于确定测试时问，产生测试用例，选择测试运行。很多工业项目中能够见到采用操作剖面的好处的实例［４２｜。使用操作剖面来指导系统测试，确保了在终止测试和由于时间限制必须发布软件时，使用最多的操作受到的测试最多，可靠性最大。

存在的问题主要有：很难开发某些应用的操作剖面，特别是分布式软件系统，如Ｗｅｂ服务；软件不能复制操作剖面来加速测试；单元测试时可使用操作剖面，而系统测试或回归测试时不适用。处理不正确的操作剖面和操作剖面间的依赖，是操作剖面技术中的两个主要问题。３．８工业实践和关心的内容

管理软件可靠性工程学有一些成功的例子，但并没有得到广泛的应用。工业中对ＳＲＥ缺乏热情的主要原因是它的成本效益不明显。许多公司不愿意花太多精力收集故障数据，更不用说数据共享。因此，不能比较可靠性的结果，得不到基准可靠性，也难以积累过去的经验。大多数软件实践人员采用直接的方法和度量来控制产品可靠性。产品的可靠性属性优先级常常比功能性或创新性要低。产品发布时间很紧时，可靠性常常是第一个被压缩的元素。

系统体系结构框图的可靠性预计和ＦＭＥ（Ｃ）Ａ已成功地用于硬件可靠性工程学技术，而仍不能直接用于软件可靠性工程学。如果软件构件可以被分解，或者能够清楚地识别构件之间的依赖，并正确建模，则这些硬件的普遍技术可以用于软件，并广泛应用于工业中。３．９软件体系结构

过去１０年对软件体系结构的系统化研究非常活跃。在将来的１０年，它将仍然是研究的中心［４…。软件体系结构设计不仅影响软件开发行为，也影响ＳＲＥ的效果。不同软件块之间的依赖减少，这样它们的可靠性不会互相影响。设计软件体系结构主要考虑错误隔离。这些基于构件的软件开发方法需要不同的框架、质量保证模式［４４］和从传统软件开发中得到的可靠性建模方法ｒ４“。

新兴的软件体系结构包括跨平台的技术ｎ引、开放世界软件‘４…、面向服务的体系结构‘鸺３和Ｗｅｂ应用”］。虽然已有一些建模方法用来估计特定Ｗｅｂ系统的可靠性ｒ５…，但对一般Ｗｅｂ服务和其它面向服务体系结构的ＳＲＥ技术还需要做更多研究。

４未来的发展趋势

４．１软件体系结构和现成构件的可靠性

由于现代软件越来越多地开发并使用可重用的构件，软件开发的可靠性工程学主要集中于两点：软件体系结构和基于构件的软件工程学。

软件体系结构是最终软件产品的基础，设计和管理软件体系结构是软件可靠性工程学研究中的支配因素。清晰的、精心组织的体系结构必须事先考虑高内聚、低耦合、模块的分

２２

万　

方数据离、适当的系统终止、简明的接口、避免复杂性等等，这些将最终有助于增加软件可靠性并减少操作和维护成本。

核心问题是设计故障恢复体系结构。设计必须确保软件执行时构件是分离的。构件故障一旦出现，就能被迅速识别并将其完全隔离。如何确保应用之间的分离，分离方法如何混合应用才能得到更好的可靠性结果，是将来研究的一个方向。

在设计故障恢复体系结构时，除了容忍构件故障之外，还常常结合额外的资源和技术，例如错误检测、诊断、隔离和恢复过程的错误处理机制。应避免额外的可靠性增长程序引入不必要的复杂性。执行恢复功能时，它们不应该有干扰性。设计简明、简单而有效的机制来执行错误检测和回复，是活跃的研究主题。

软件体系结构代表了软件系统的产品观点，而基于构件的软件工程学强调了软件工程学的过程观点。需要研究的问题有：怎么识别和设计可靠的、通用的可重用构件？如何修改现存构件，以便于重用？如何为构件提供清楚的接口设计，使得它们的交互完全在控制中？怎样给构件提供防御机制，保护构件，而不引起大的故障？怎样确定构件是否无风险？怎样在没有测试而可预见的操作条件下评价构件的可靠性？如果构件不是独立的，怎样对构件交互建模？基于构件的软件工程学也可以实现基于结构的可靠性，这有利于运行和测试软件前的可靠性设计。主要是需要适当地捕获构件问的依赖并对之建模。

４．２实现设计可靠性

可靠的系统设计需要的容错机制包括错误限制、错误检测、诊断、重新配置、恢复、重启、修理和重组。这些阶段挑战性的研究问题，如下所述：

１）错误限制。实现方式包括自检接受测试、意外处理例程、一致性检查机制和多请求／确认。关键是减少依赖。这已是且将仍然是软件可靠性工程学中的开放问题。

２）错误检测。有离线和在线错误检测。离线技术如诊断程序能够提供全面的错误检测，但系统在测试状态下不能工作。在线技术，如看门狗监控器或冗余配置，与任务并行执行，提供了实时的检测能力。

３）诊断。诊断提供故障位置和／或属性的信息。在线的故障预防诊断是目前的研究趋势。

４）重新配置。成功地重现配置要求健壮灵活的软件体系结构和相关的重新配置计划。

５）恢复。恢复技术基于错误掩盖、重试和回滚。错误掩盖利用冗余来掩盖故障的影响，如Ｎ版本编程。重试。即尝试第二次操作，可用恢复块重试。回滚，从检查点重新开始错误检测和操作，回滚必须足够远。Ｎ版本程序设计和恢复块体现了设计的多样性，这仍然是争论的热点。

６）重启。热启动能够从错误检测点处恢复所有操作。只在系统没有损害时，才可能热启动。暖启动中，只有某些过程能够被无损恢复；而在冷启动中，所有进程被杀死，执行的系统完全重载。

７）修理。有离线和在线修理。在线修理时，构件可以用后备备件立即替换，或没有错误构件（例如掩盖冗余 …… 此处隐藏：2385字，全部文档内容请下载后查看。喜欢就下载吧 ……