软件FMEA如何做？ fmea案例 _案例

Fmea案例(如何做软件FMEA？)
FMEA在软件行业的应用其实很少，但是在汽车行业或者硬件方面的应用相对较多。一些质量人员希望将硬件质量管理工具扩展到软件，进而提出FMEA作为质量工具在软件设计中的应用。但是真正的软件从业者或者软件QA人员可能很少听说过但是在企业中实际使用过的。
当前，传统企业的数字化转型和新能源汽车的电子化使得软件的重要作用凸显，也导致人们越来越重视软件研发的质量。但是现实情况是，很多质量经理都是硬件出身，对软件了解不多，所以很多人希望宋老师讲讲软件，那么今天我们就来讲讲软件怎么做。
01
FMEA概况
FMEA:潜在失效模式及后果分析
FMEA是针对产品(系统、子系统和零件)或制造过程的系统性过程活动；分析潜在的失效原因、失效模式和失效后果；确定现有的控制措施；风险评估；根据行动的优先顺序，制定改进措施并完成验证。
我们简单的描述就是一个分析风险的工具，在风险发生之前识别风险，并采取相应的措施在事前消除缺陷，这是预防思想的具体体现。
作为一种技术风险分析工具，FMEA可以帮助组织实现以下期望:
FMEA最早的参数是美军的MIL-P-1629，之后在航空航天空行业成功应用，之后逐渐推广到其他行业，最新版本于2019年推出。下图是FMEA的一个发展过程，可以发现对软件行业的涉足还是比较少的。
最新版FMEA最显著的改进是，一是建立了FMEA公式的流程步骤；另一种是在分析中，更强调系统环境对分析对象的影响。
GJB/Z1391-2006故障模式、影响和危害分析指南定义了软件FMEA:
软件FMECA主要是在软件开发的早期，通过识别软件失效模式，研究分析各种失效模式的原因和后果，寻找消除和降低其危害后果的，以便尽早发现潜在问题并采取相应措施，从而提高软件的可靠性和安全性。
02
软件FMEA和硬件FMEA的主要区别
不同于硬件FMEA，可供参考的案例很多，软件FMEA可供参考的案例很少。它们之间也有重要的区别:
1)分析对象的差异
硬件分析对象可以明确选择到底层物理设备，而软件不容易明确划分模块和层次，软件分解的深度往往受限于工程应用。如果把软件也分解到基本语句层面，如果所有逻辑路径风险都穷尽了，就会面临失效模式无法穷尽，分析工作难以为继的局面。软件运行时的输入数据和外部环境对运行结果也有影响，所以即使个别语句没有错误，运行时仍然可能失败。
2)不同的故障模式
硬件的失效主要是由于物理器件老化或磨损导致的参数漂移。所以硬件的失效模式是比较明确和有限的。但是软件没有磨损，它的故障是设计造成的，也和用户使用软件的方式有关。所以软件的失效模式比较复杂，目前还没有一个全面系统的定义，需要具体应用具体分析。
03
软件FMEA的实现
软件FMEA是一种引导式分析，通常在软件的概要设计完成后进行，并在后续的开发阶段重复进行。以更流行的软件生命周期模型瀑布模型为例，说明软件FMEA实施与软件开发过程的关系。
当设计了软件的原型结构，确定了各个模块的功能需求后，就可以实现系统级软件FMEA了。其目的是识别软件架构的质量属性，重点是从系统角度分析各子模块的输出以及模块间的协调匹配，主要包括软件功能FMEA和软件接口FMEA 。
详细的软件FMEA可以确定模块设计是否满足软件质量要求，识别具体的失败情况，并确定失败的根本原因。
因此，通常FMEA的实施过程主要分为以下几个步骤:
04
FMEA软件公司的案例
系统级FMEA与系统的业务逻辑相关性很高，但相对而言，详细级FMEA与业务逻辑相关性很小。因此，让我们以详情层软件FMEA为例来谈一个案例。
常用工艺设计
趣味主线()
{
任务1()
{
fun1()
fun2()
。。。
funx()
}
任务2()
。。。。
taskn()
}
这种结构，通常表达了设计意图:
Main是主入口函数，它调度以下所有任务级模块。
任务是一个任务模块，专门处理业务功能点或外部负载的控制。可以理解为一个模块。
Fun是最后一个代码实现函数。
我们可以看到，每个功能对应一个main，模块对应一个任务，具体功能对应一个fun 。让我们在模块1中学习FMEA 。
一个软件功能，就一般性抽象而言，也是输入输出，以及功能内部的处理逻辑，所以从以下一般性方面进行分析: