Information Technology Reference
In-Depth Information
TABLE 16.2
(Continued)
Year
Reference
Contribution
Software FMEA depends on the domain
knowledge of the analyst.
Stated that a complete list of software failure
modes cannot be developed.
Goddard, P.L., A Combined
Analysis Approach to
Assessing Requirements for
Safety Critical Real-time
Control Systems,
Proceedings Annual
Reliability and
Maintainability Symposium,
pp.110-115, 1996.
Goddard:
(1996) reported that a combination of Petri
nets and FMEA improved the software
requirements analysis process at Hughes
Aircraft.
Moriguti, S., Software
Excellence: A Total Quality
management guide. Portland,
Productivity Press, 1997.
Moriguti:
Provided a thorough examination of total
quality management for software development.
Presented an overview of FMEA. The topic
pointed out that FMEA is a bottom-up analysis
technique for discovering imperfections and
hidden design defects.
Suggested performing the FMEA on
subsystem-level functional blocks.
Noted that when FMEA is performed on an
entire product, the effort often quite large.
Pointed out that using FMEA before the
fundamental design is completed can prevent
extensive rework.
Explained that when prioritization is
emphasized in the FMEA, the model
sometimes is referred to as failure modes,
effects and criticality analysis (FMECA).
1997
Ammar, H.H., Nikzadeh, T.
& Dugan, J.B., A
Methodology for Risk
Assessment of functional
Specification of software
systems using Colored Petri
Nets, Proceedings of Fourth
International Soft-ware
Metrics Symposium, pp.
108-117, 1997.
Ammar, Nikzadeh, and Dugan:
Used severity measures with FMEA for a risk
assessment of a large-scale spacecraft software
system.
Noted that severity considers the worst
potential consequence of a failure whether
degree of injuries or system damages.
Used four severity classifications. Catastrophic
failures are those that may cause death
 
Search WWH ::




Custom Search