Root Cause Analysis as a Guide to SRE Methods.
Timm Grams · ARCS Workshops · 2004
Which Software Reliability Engineering (SRE) methods should be applied during the various phases of the lifecycle of a product? The answer given here centres on learning from errors. The classification and evaluation of methods is strictly based on causal analyses of disasters, accidents and incidents with undesired outcome. The lifecycle model of IEC Standard 61508 has been adopted as a classification scheme. A couple of examples are given. The SRE methods considered here are those of IEC 61508. These methods are dealing with software reliability as well as with the production of highly reliable software. As an example of some more recent proposals Extreme Programming (XP) has been included. Introduction The rules and the timely processing order of Natural Software Engineering (NSE) I discovered by watching my students during a programming course in November 2003: 1. In the very moment you have a faint idea of what your are supposed to do start coding. This is called realisation. 2. Derive an excerpt from your program. This results in your concept and design. 3. Then write down the specification and define all surprising program properties (heartlessly called bugs) to be features. 4. Convince your customer (the instructor’s role) of what you are able to deliver is what he truly wanted. This challenging task is called requirements engineering. Indeed, this is the natural way: The scheme rests on firm psychological and sociological grounds. For, what your are paid for is real work. Coding is to come first. Whereas activities like haggling over requirements, verification and documentation are introducing delays. And they are real pains. In favour of keeping the time schedule and comfort these activities should be skipped or given low priorities. On the other hand, our experience points into another direction: Disasters happen because of a lack of documentation, badly thought-out specifications, superficial tests and left off verifications. Investigating and analysing the disasters of the past makes the strongest case in favour of the not so natural and painful software engineering methods. This paper deals with software reliability engineering (SRE) methods. They are more or less painful, and they are more or less useful. The question to be answered is: When does it pay to use them? The one who has the task of building and maintaining software of automation and safety systems faces a plentiful variety of techniques for software construction and evaluation. Let alone the IEC Standard 61508 lists 66 techniques aiming at software safety integrity not taken into account all the existing variants of the methods [1, part 7, annex B].