New account
Write to us

SFMEA (SwFMEA) – what is it actually about?

/SFMEA (SwFMEA) – what is it actually about?
  • how to make sfmea

SFMEA (SwFMEA) – what is it actually about?

Why is a software risk analysis done?

SFMEA or failure mode and effect analysis of the software is the younger sister of the familiar commonplace DFMEA and PFMEA. And it is much younger because it is “only” about 40 years old. This is actually no surprise since much of the software’s reliability earlier in the 50s and 60s was insignificant as it was hardly used on a mass widespread basis. Recent decades however have seen a significant increase in the influence of software on our daily lives. “Some” program decides when our car will start emergency braking, “some” program decides when our cooker will stop cooking soup or “some” other program decides whether an alarm will sound in the house in case of a fire. Given this it’s hard not to think that the topic of software reliability should be getting louder and louder.

How to do SFMEA analysis?

Very importantly and this is where we start every training on this method, SFMEA is software (system) analysis not programming (coding). This it’s a method closer to DFMEA than PFMEA.

  1. Specify viewpoint

Undoubtedly, an interesting aspect of working with SFMEA is the need to select one of eight so-called viewpoints at the beginning:

  1. Functional – functionality, implementation of software requirements or system requirements (SRS, SyRS)
  2. Interface – project documentation (IDD, IDS)
  3. Detamiled – design details (DDD) or code
  4. Maintenance – code or design that has changed as a result of corrective action
  5. Usability
  6. Vulnerability to external systems
  7. Serviceability – installation scripts, readme files
  8. Production – software development process, development plan (SDP).

The analysis proceeds differently for each of these viewpoints, such as:

  • Vulnerabilities (resistance to external systems),
  • Functionality (implementation of established tasks),
  • Usability (when the user’s impact on the program is analysed),
  • interface (when individual cooperating “pairs” are analysed),
  • or serviceability (when attention is paid to problems at installation among other things).

Each of these aspects of analysis has a specific form and a specific set of input documents. One can of course also take a “standard” approach to SFMEA and use the typical FMEA form but this can prove to be a very ineffective approach.

  1. Define fauilure, causes, effects

Viewpoint defines what in our SFMEA will be a defect (failure) and on this basis we can already add causes and effects for individual modules of the computer system (local, subsystem, system).

  1. Choose a method to risk assessment

Another important aspect that takes up a lot of time in training is the choice of a method to risk assessment. The range of options here is huge.

Choices include:

  • several types of criticality matrices,
  • three types of RPN indicator (one very, very unusual),
  • ARPN,
  • the recently popular AP.

So you have to think about it carefully and clearly describe it in an internal procedure for SFMEA.

When is it appropriate to do SFMEA?

SFMEA is undoubtedly an extensive and complicated but very valuable method that all companies developing software – from the kind that operates for example sensors that protect machines to those that control the operation of cars and much more complex systems – should be interested in.

As many standards dealing with software reliability show the first risk analysis should be conducted as early as possible. Even after the requirements have been defined and the system architecture designed the first potential problems can begin to be identified. Later, as the project develops the SFMEA should be expanded and updated with new data, including new risks.

Summary

Step-by-step how an SFMEA analysis should be conducted, you need:

  1. Define viewpoint
  2. Based on the selected aspect of the analysis, define the disadvantages of failure
  3. Attribute to defects the cause
  4. Identify the effects on individual computer system modules such as local system, subsystem
  5. Grade S, O, optionally D
  6. Decide on actions based on the chosen method of “pricing” risk.

 

Download a scheme for SFMEA analysis.

 

 

 

 

2023-07-31T13:51:59+02:00 25 November 2022|Categories: articles|0 Comments

Leave A Comment