怎样进行软件失效风险分析
如今信息化时代，各企业对软件重视程度愈发提高，许多企业也会进行软件失效风险分析报告，虽然各企业对软件加强重视，但由于技术还不过关，同时也缺少足够的技术指导，有很多企业对软件失效风险分析缺失。

那么怎样进行软件失效风险分析呢？现在就来一起探讨一下。

软件失效风险分析基本概念及内容
软件失效风险分析，顾名思义，是对软件开展的失效已经可能导致的风险的分析。

失效是一种功能丧失和功能错误的属性，是软件中的设计错误导致系统发生的外部行为，因此，失效分析宜在软件需求及架构设计等高级需求中开展。

目标是通过需求分析，获取软件的失效防护需求。

（在国军标语系如GJB 102A中，叫做软件安全性需求；在大部分民用语系如DO 178C中，则称之为健壮性需求。

）
这个工作包含以下几个要素
软件功能层面有什么可能的失效（软件的输出，代表失效行为）？
导致失效的原因（软件的输入，代表激活失效的原因）？
失效后果如何（软件失效对系统的影响）？
风险大不大（大的需要控制，小的就要分析，或可暂时不控制）？
是否需要制定“安全性需求”对其进行控制（要产生新的需求）？
安全性需求是否纳入了软件需求规格说明（要迭代至软件需求规格说明）？
从工程审查的角度来看，基本也是以这几个主要角度出发去把控软件失效风险分析工作的质量。

此次审查中各个单位的采用的分析记录格式各不相同，但大部分都具备了以上要素，少数单位上述要素不全，说明应从概念层面予以加强。

软件失效风险分析与系统安全性的关系
软件失效风险分析是站在软件角度自底向上地归纳软件行为对系统的影响，属于系统安全性中一个环节。

系统功能危害性分析，以及故障树分析工作，将为软件失效风险分析提供更清晰和具体的分析目标，从而形成闭环提升效果。

如果系统安全性工作不够规范，那么软件失效风险分析工作的效率和效果也会相应下降。

从这次审查来看，大部分单位都未描述或提及软件失效风险分析工作与系统安全性工作的接口、未引用相关系统安全性文件、未建立两个工作在概念上的关联等等，这需要未来从系统到软件的持续推动来完善。

软件失效风险分析的关键点
既然是自底向上的归纳性分析，那么其中的关键要素自然是失效的各种可能性。

这个各种可能考虑的是否足够“多”，就成为整个工作的关键。

软件的失效分析如何确保足够“多”？这在理论上是无法证明的，也需要巨大的工作成本，所以应该工作中找一平衡点，这就需要制定好失效风险分析的策略。

首先分析软件的特点，从接口、数据、功能、状态等等方面，分析软件功能失效的特点，得到软件失效的机理性描述；然后根据软件特点，描述应从哪些角度、哪些失效模式、哪些异常考虑去展开分析工作？避免陷入工作成本的失控；这些分析策略，形成了此次分析的规则集合；最后，通过这些分析规则在软件功能上的遍历排查，来完成整个分析工作。

对于分析规则，需要考虑到软件的失效特点，即软件的设计错误都是通过异常输入来激活的。

这方面无论是GJB 102A还是DO 178C，都给出了指导性的分析方向。

因此在分析时，非常建议参考标准的指导，通过本地实例化，形成细化的分析规则，这样也能比较有力地阐述分析的相对充分性。

软件具体输入的失效模式空间过于庞大，因此在上述策略制定的分析规则下，去尽可能多的分析相关失效模式，能达到充分性和成本的一个平衡点，也是比较容易让审查方及审定方认可的方式。

此次审查中，绝大部分失效风险分析都存在着失效模式考虑比较简单、随意，缺少顶层分析策略的问题，这样自然难以分析充分，也就难以形成有效的安全性需求。

所以在几乎所有的审查问题列表中，都出现了软件需求规格与失效风险分析报告之间无安全性需求追溯的共性问题，这背后并不是文档描述问题，而是分析的不足导致的安全性需求缺失。

关于失效风险分析报告
覆盖了上述内容的报告，其实都是合格的规范报告，我们来简单梳理一下其中的主要内容。

第一，与系统安全性的接口描述，说明此次软件失效风险分析，与系统安全性工作的信息流接口。

如果暂未开展或暂未获得系统安全性自顶向下的接口，那么也应阐述这个情况，此次软件分析，就成为彻底的单向分析，这在分析策略中应有所体现。

第二，软件失效风险分析的策略。

第三，此次计划实施的软件失效风险分析的规则集合，即都有哪些规则，打算对全部还是部分功能实施。

第四，具体的软件失效风险分析结果，可以用FMEA表格来记录，其中重点是软件输入失效模式的充分性考虑。

第五，通过上述工作，形成了哪些软件安全性需求，这些需求都被迭代至原版软件需求规格的哪些位置？予以描述和追溯。

以上所提到的软件风险分析的相关内容，可能还不足以系统性指导一个规范的软件失效风险分析工作，但列出了建议重点考虑的框架性因素，可以基于此逐步构建一个规范的、可复用的软件失效风险流程。