作者:admin 时间:2022-12-28
软件FMEA它是一种引导式的分析方法,通常是在软件的概要设计完成后展开,并在其后的各开发阶段反复进行。下图以最为普及的软件生命周期模型:瀑布模型,为例,说明实施软件FMEA与软件开发过程之间的关系。
当软件的原型结构设计出来并且确定了每个模块的功能要求之后,就可以进行系统级软件 FMEA。其目的是鉴定软件架构的质量属性,侧重于从系统的角度去分析各个子模块的输出和各模块之间的协调匹配,主要包括软件功能FMEA、软件接口FMEA。
详细级软件FMEA可以确定模块设计是否达到了软件质量要求,识别具体的失效情况,确定失效的根本原因。
因此,通常软件FMEA的实施过程其实主要分为如下步骤:
软件FMEA的案例
从系统级FMEA与系统的业务逻辑相关性比较高,相对来说详细级的FMEA与业务逻辑关联性不大,因此,我们以详细级软件FMEA为例来谈一个案例。
常用的过程式设计
fun main()
{
task1()
{
fun1()
fun2()
。。。
funx()
}
task2()
。。。。
taskn()
}
这种结构,通常表达的设计意图说明:
main 是主入口函数,对下面所有任务级模块进行调度
task 是任务模块,具体处理一个业务功能点或者某个外部负载的控制,可以理解为一个模块;
fun 是最后代码实现函数
我们与软件架构分层对应可以看每个功能由一个main对应,模块由task对应,具体函数由fun来对应。我们对模块1中来进行FMEA
一个软件函数,从通用性抽象而言也是输入与输出,还有函数内部的处理逻辑,所以分析时从下面几个通用的方面展开:
1、运行时不符合要求
2、输入不符合要求
3、输出不符合要求
在相关IEEE标准和GBJ标准中,对软件常见失效模式与原因有些说明,摘取其中部分:
这里以一个系统时钟系统为例,
把前段部分截取下来如下表,因为这里仅仅是个案例,选取各函数的,输入、函数内处理、输出 的异常,分别举了一个案例。
标识 | 子模块名称 | 功能描述 | 失效模式 | 失效原因 | 失效影响 | |
局部影响 | 系统影响 | |||||
1 | f1 | 获取当前时间参数 | 上一级调用函数异常导致传递给函数的返回值是错误值(输入) | 调用函数执行异常 | 无法完成时间修正功能 | 时间系统运行出现较大偏差 |
3 | f2 | 时间初始化 | 数据范围不正确(函数处理) | 字段长度无法满足时间增长的要求 | 运行一段时间后出现计算偏差 | 系统运行一段时间后,突然出现严重偏差。系统出现混乱 |
4 | f2 | 时间初始化 | 数据写入失败(函数处理) | 硬件寄存器出现短暂异常 | 该时钟范围内,计时无响应 | 该秒内,系统计时错误 |
5 | f3 | 时间修正 | 输出异常时间(输出) | 函数执行中异常错误,导致未返回正常计算值 | 导致后一级数据计算错误 | 系统时间报告出现较大偏差 |
大家可以结合软件常见失效模式,针对输入、输出、程序处理 每种可能的失效模式进行分析与识别,尽可能全的识别出对应的风险。
风险识别后,对应的风险评估还有,应对措施的制定,相对比较简单了,所以,这里就不再累述。
版权所有© 国可工软科技有限公司 苏ICP备2025155226号-1