软件FMEA如何做? fmea案例( 二 )


1、运行时不符合要求 。
2.输入不符合要求
3.输出不符合要求 。
在相关的IEEE标准和GBJ标准中,有一些关于软件常见故障模式和原因的解释,并摘录了其中的一部分:
这里,以系统时钟系统为例,
截取上一部分如下表所示,因为这只是个例 。选取每个函数的输入、内部处理和输出的异常,分别给出案例 。
你可以根据软件常见的故障模式,分析识别输入、输出、程序处理的每一种可能的故障模式,尽可能充分地识别相应的风险 。
风险识别之后,相应的风险评估和对策的制定就比较简单了,这里就不赘述了 。
05
需要注意的事项
1.软件设计,其实很难说到底哪一个是概要设计,哪一个是详细设计 。因为下一级的设计是上一级的详细设计 。只能说要看系统层面的设计分配或者约定 。所以做软件FMEA,需要对软件系统架构进行设计和分层,否则直接到代码层面很难获得结构化的信息 。
2.在一个软件FMEA的制作中,我们可以发现即使是一个很小的功能也有很多可能失败的原因 。如果一个大型软件完全用FMEA实现,几乎肯定会遇到“逻辑爆炸”的麻烦,在实际商业项目的成本和进度的约束下很难完成 。因此,我们需要做出取舍 。我们可以考虑只分析扇入扇出大于5的新设计、更改的模块,这些模块很可能有风险 。
3.其实在软件设计中比较好的方法是将失效模式设计成编码标准,然后在编码过程中通过自动工具检查和人工同行评审的方式来实现 。


推荐阅读