软件失效模式数据库的作用

    目前在军用和民用的功能安全领域，都要求开展系统性的安全性工作。而软件FMEA是这个工作中的难点，原因就是软件的灵活性和复杂性，给FMEA工作带来了很大的工作量和分析难度。这就造成了软件的失效一直拖延到测试甚至使用阶段才被发现，显然与功能安全的初衷相距甚远。

软件失效模式最大的特点就是多，可以说人思维错误有多少种，软件的失效就有多少种。好在，人并没有把全部的思维用来设计软件，纷繁复杂的软件失效也呈现出有规律的模式。平时常见的口头禅就是“这个问题怎么又出现了”？那么怎么避免“这个”问题下次重复出现呢，最好的方式就是设计时把它识别出来，然后干掉。

     但下一次设计软件时，吭哧吭哧加班加点赶工干完，这个问题又一次藏在了软件里，等待下一次的爆发。

我们要尽力在设计阶段把它“想起来”，把它控制住，才是软件安全性与可靠性工作的作用所在。

和硬件FMEA一样，利用失效模式数据库，是克服经验主义，提高分析效果的手段。但软件的失效模式数量众多、类型复杂，软件失效模式数据库应该如何建立呢？

      关于构建软件失效模式数据库，这里推荐以下几个原则：

      1.结合软件功能要素

      软件失效与硬件失效不同，软件失效的特点是全部为“功能失效”而没有物理失效。因此软件失效模式数据，不能脱离软件功能而存在；或者说脱离了功能的失效模式，不是好的失效模式。因此在构建失效模式数据时，必须将其描述为作用在功能上的数据。

什么叫软件功能呢？各级规格说明里写得清楚，就是：输入→处理→输出，这三大要素。那么软件失效模式自然也要围绕这三类要素来构建。

简单来说就是：输入有什么失效模式？处理有什么失效模式？输出有什么失效模式？这些失效模式，在设计输入，处理，输出的时候，就要尽可能考虑到。

     2.层次结构化

    软件功能除了上述三大要素，还呈现出复杂的结构。比如，输入的形式有很多种，涉及模拟量、开关量、数字总线、人机操作、文件、数据库等等；每种形式的输入下，又包括数值、时间、顺序、格式、状态等等要素；每个要素下，又包括一系列子要素……这些逐层细化的功能要素，既是功能设计的基本要素，也是引起功能失效的原因，都具有相应的失效模式。因此软件失效模式数据库，与功能要素相对应，应具有层次化的结构。

    将软件失效模式数据库层次结构化的好处是，当在大量的数据中寻找适合某个功能要素的失效模式时，易于获取和管理，就像图书馆一样，数据虽多但井然有序。

    层次结构化的另一个含义是，由于软件失效模式数据是具有逻辑含义，而不是物理现象的描述，理解起来没有硬件容易。因此在对失效模式数据的使用上，只看数据本身未必好用。

    为了更容易理解失效模式数据，在使用前，可以加入失效模式分析要求，用来指导操作，指导如何利用具体的数据开展分析；另一方面，对于每个具体失效模式数据，在其后可以加入对应的失效案例，增加失效模式的可理解性。

这一“前”一“后”，使软件失效模式数据更易于理解和操作。

    3.使用标签化

    在实际工作中使用失效模式数据时，不仅会根据上述功能要素去查询数据，还有可能会根据失效模式相关的时间、项目、人员、单位、位置等等各种五花八门的信息去查询，比如“张三犯过的错误”、“在成都吃火锅那次的错误”等等，这些信息在软件开发和测试的时候经常被我们提起，但这些信息都要用来组织数据的结构吗？显然不可能。

    在数据中加入标签，就成为管理和获取这些复杂信息的有效手段。就像我们往显示器旁贴标签一样，随心所欲，想贴多少就贴多少。纸标签贴多了可能不容易找到有用的信息，但电子标签贴多了交给计算机找就行，这样查询获取某个失效模式数据就更加容易。这些有序或无序的标签如何定义和管理，本身也成为一个软件研发组织的能力和技巧。

    软件失效模式数据库的建设，是一个复杂、漫长、有趣的过程；是在有限的资源下，尽可能地从数据中找规律，与故障作斗争的过程；是把软件失效的识别和预防不断前移的过程。

   值得我们去研究和实践。