Safety management

8.4 Safety management

The following three major elements are involved in the area of safety management:

1. Previous hazard experience;

2. Hazard analysis;

3. Safety planning.

8.4.1 Experience

Two kinds of experience are applied here: lessons learned and intuition. Lessons learned come from experience with prior or similar systems or software. Each space shuttle mission becomes less hazardous due to the lessons learned on earlier flights. Some of the same hazards still exist, but those hazards and how to manage them are known. The example of the undetected alarm (see Section 8.2) led to a lesson learned regarding better analysis of a situation requiring a software change and better review and regression testing of the change and the affected system prior to operation.

In the case of new systems or software, there is a greater reliance on intuition and asking what could go wrong rather than knowing what did go wrong. The story about the rod lifter (see Section 8.2) is an example of intuition on the part of the quality practitioner. He had no prior experience with such a system but knew that the casual addition of the computer had not received close scrutiny and acted on a hunch that a hazard might exist. Had the hazard not been detected by his action, a serious nuclear incident could have occurred.

8.4.2 Analysis

IEEE Standard 1228 defines the content and format of the software safety plan and includes an entire section on software safety analyses. These analyses reflect the information in Section 8.3 and discuss activities to be conducted during the coding phase.

At each step in the development of safety-critical software, attention must be given to the identification, evaluation, documentation, and amelioration of the following types of hazards:

• Those to be avoided by software;

• Those caused by software;

• Those incorrectly controlled by software;

• Those incompletely responded to by software;

• Those overlooked by software.

Each type of analysis will be determined by the period of the life cycle involved, the type of hazard being considered or expected, the severity and probability of the hazard, and other factors specific to the project. The software safety plan will spell out these issues and their treatment.

8.4.3 Planning

In most, if not all, safety-critical system and software development efforts, planning for special attention to the safety aspect and issues is necessary. If there are only one or two relatively obvious and simple hazards to consider, the project plan itself may provide adequate attention to the issues.

Beyond the simple and obvious, though, specific and detailed attention should be paid to safety. This is best done with a planned approach to addressing safety issues. The preparation of a software safety plan, according to the IEEE standard, is one way to increase the quality and safety of critical and safety-critical software.