Failure Modes and Effects Analysis (FMEA) for software-intensive systems (called software FMEA in this paper) requires the ingenuity of engineers to set failure modes because software itself never fails as hardware does with physical phenomena. Successful software FMEA allows the experience, knowledge, identification of appropriate items and guide words to be integrated in the engineer's mind. Therefore, software FMEA could be considered a somewhat imaginative activity that largely depends on the engineer's competence. In the space domain, there tends to be less experience on software FMEA as compared to other domains having a shorter development cycle. In addition, the limited concrete knowledge about an unknown system and its environment under operation tends to limit the ideas for analysis when a single engineer performs software FMEA. As a result, we sometimes experienced software FMEA activity that had a negligible effect on the subsequent development phase. To resolve this issue, analysis and review by several engineers are adopted as a solution to cover the lack of experience and competence by an individual. Team reviews are generally useful to expand the idea to lead failure modes. However, a team review may offer a biased result when applying an ad hoc method such as brainstorming. To avoid a biased result, revealing the thinking process and discussion points can help guide proper discussion and also add various ideas from several engineers. Therefore, we proposed a novel method of visualizing the thinking process that led to failure modes by extending Goal Structuring Notation (GSN). Team members will be expected to stimulate ideas by looking at artifacts that visualized the scope of failure mode. Any missing item or possible failure mode can thus be discussed, allowing team members to easily add ideas for the analysis. The team review with the proposed method successfully identified meaningful failure modes in a development project at the Japan Aerospace Exploration Agency (JAXA). Moreover, failure mode and its end effects analysis led by the proposed method contributed not only to software design but also to software testing for setting test cases of adverse conditions.
[1]
Darryl W. Kellner.
Software FMEA: A successful application for a complex service oriented architecture system
,
2017,
2017 Annual Reliability and Maintainability Symposium (RAMS).
[2]
Donald J. Reifer,et al.
Software Failure Modes and Effects Analysis
,
1979,
IEEE Transactions on Reliability.
[3]
Hong Zhang,et al.
Software FMEA approach based on failure modes database
,
2009,
2009 8th International Conference on Reliability, Maintainability and Safety.
[4]
Tim Kelly,et al.
The Goal Structuring Notation – A Safety Argument Notation
,
2004
.
[5]
Hyung-Ho Kim.
SW FMEA for ISO-26262 Software Development
,
2014,
2014 21st Asia-Pacific Software Engineering Conference.
[6]
P Haapanen,et al.
Failure mode and effects analysis of software-based automation systems
,
2002
.
[7]
M Weda,et al.
Consistency of FMEA used in the validation of analytical procedures.
,
2011,
Journal of pharmaceutical and biomedical analysis.
[8]
M. Silverman,et al.
FMEA on FMEA
,
2013,
2013 Proceedings Annual Reliability and Maintainability Symposium (RAMS).