锐客网

  1. 首页 > 睿知 > >

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

    推荐阅读


    上一篇：昆虫记读书笔记1000字

    下一篇：致少先队员接班人寄语