Process safety analysis

E.4.2.1 Introduction

E.4.2.1.1 Process safety analysis investigates the ways in which a software development

process could fail and as a result cause a potentially dangerous software fault. The analysis identifies the measures taken to prevent this happening and the defences employed to detect and remove the effects of such failures. Weaknesses, omissions and duplications in the software development process should be exposed by this analysis and these problems addressed through process improvement activities.

E.4.2.1.2 The analysis should look at the ways in which the individual elements (ie the

methods, tools, support software and tasks) of the overall software development project can fail and analyse how these failures could lead to potentially hazardous faults in the SRS. The analysis should consider ways in which these failures might:

(a) introduce faults (specifically dangerous faults) in the delivered software; (b) allow faults to go undetected;

(c) threaten the independence of safety arguments;

(d) threaten the quality of the evidence used to support safety arguments; (e) increase project risks and so threaten safety;

(f) violate the principle of reducing safety risks to As Low As Reasonably Practicable (ALARP).

E.4.2.1.3 Process safety analysis can be used to support the justification for the Software

Safety Case that the software development process is adequate as a means of developing software with the desired safety integrity. The analysis is normally only carried out at the start of the project and its results should be incorporated into the preliminary Software Safety

E.4.2.1.3 (Cont)

software development process during the project.

E.4.2.1.4 The results of the analysis should be confirmed in the interim and operational

Software Safety Cases which should contain evidence of conformity to the proposed process. Problem areas should be highlighted and corrective actions identified. The operational Software Safety Case should also include an assessment of the overall performance of the process, together with a justification of why any changes do not affect the safety goals for the system.

E.4.2.1.5 The process safety analysis procedure described in this document is based on

conventional hazard analysis techniques adapted to meet the needs of analysing the software development process.

E.4.2.2 Concepts

E.4.2.2.1 Before proceeding to describe the process safety analysis procedure, some key

concepts and terminology are introduced.

E.4.2.2.2 The overall software development process is viewed as consisting of a number of

high-level activities (eg produce software specification, prepare module tests). These

activities are typically broken down into more detailed activities (eg perform Z syntax check). At this level, the methods, tools and human tasks which make up the activities are considered in the analysis. Examples of these would be the Z specification language, the Z syntax and type checking tool, and the modelling of requirements in the Z language.

E.4.2.2.3 A process failure is defined to be a failure of any method, tool or human task

which results in the incorporation of a potentially hazardous fault in the SRS. Process failures also include the failures of testing or review activities to detect software faults. Examples of a process failure would be the failure of a development tool, a mistake made by a programmer in implementing a module specification or the use of an inadequate or

inappropriate method.

E.4.2.2.4 A process hazard is defined to be the end effect of some combination of process

failures resulting in a potentially hazardous fault being incorporated into the SRS (for example, "Hazardous timing fault in the operational software"). In other words, a process hazard is a failure of the overall software development process to construct SRS with the required safety attributes.

E.4.2.2.5 Process failures and hazards should be considered at an appropriate level to keep

the analysis to a manageable size.

E.4.2.3 Analysis procedure

Table E.2 : Process Safety Analysis Phases

Phase Description

Process Definition Model the software development processes in a suitable form for analysis.

Process Hazard Analysis

Analyse the software development process to identify the process failures and their effects. Identify the measures to prevent these failures happening and the defences needed to detect the results of any failures.

Review Review the results of the analysis and implement any

changes needed to the proposed software development process.

E.4.2.3.2 These phases are described further in annex F. E.4.3 Previously developed software

E.4.3.1 Part 1 of this Standard requires evidence of the suitability of both previously developed software and Commercial Off-The-Shelf (COTS) Software. Evidence may take the form of:

(a) showing that the software has already been developed to 00-55 standards or some other appropriate standard (eg RTCA DO178B);

(b) third party safety certification of the software;

(c) carrying out a programme of reverse engineering to gather the necessary evidence of the safety integrity of the SRS;

(d) collecting evidence about the safety integrity of the software from its in-service usage.

E.4.3.2 When considering the reuse of previously developed software or COTS software it should be borne in mind that software is prone to unexpected failure when used in a new environment or by a different set of users. For instance, an error in the way position co- ordinates are handled may cause the failure of previously safe equipment if it is moved to a different continent; or a progressive timing error may cause an anti-missile system to become inaccurate if it is operated by a service unit which carries out reinitialisation less frequently than previous users. Therefore, the similarity between the applications used to gather in- service safety integrity data and any proposed new application should be justified.

As a minimum, the following factors should be considered: (a) data rates;

E.4.3.2 (Cont)

(d) size;

(e) complexity; (f) throughput; and (g) accuracy.