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

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