In this section we provide further guidance on interpreting the swim-lane diagram. This diagram represents the key decisions which may influence safety during software development. It is not intended to represent a software lifecycle, but rather information flow throughout the contractual interaction between supplier and acquirer.
A.2.1 Initial Phase
This phase includes those activities which occur prior to the technical development of software. They include publishing an invitation to tender, managing the pre-contractual arrangements, selection of a tender and
establishing the necessary contracts. These activities are likely to involve significant managerial input.
There are several Managerial activities which relate to the identification of a need for the development or acquisition of new software. The activities involved in creating an Invitation to Tender (ITT) are not explicitly shown in the diagram, but may include a criticality analysis of the software, requirements elicitation, scoping analyses and so on. At this stage an Invitation to Tender is then sent out and responses accepted. Management personnel are then responsible for selecting a supplier (the first decision box, labelled “This tender is acceptable?”) and requesting that work on the project commence. Annex D contains guidance on making this decision, including a discussion of what must be considered during the selection process.
The request is labelled “Request project commencement” in the swim-lane diagram. It initiates the parallel activities entitled “System build and risk management” (Ensurance), “Hazard Analysis and Risk Management” (Assurance) and “Develop assurance argument” (Assurance). It is likely that at this stage extensive software safety requirements will not be known in full. Consequently, part of the work involved in the “Develop assurance argument” activity will be to begin eliciting more detailed safety requirements.
A.2.2 Development Phase
The development phase, as can be seen from the diagram, is iterative. The main iteration consists of ongoing monitoring of safety management and safety case development. However, it should be noted that all swim-lanes will also have their own iterations within the general Development phase iteration. Some of the major considerations for management personnel at this stage include managing contractual requirements, managing change (including emerging safety requirements), formally accepting risk and overseeing safety case reports. The development phase may be curtailed when assessing a COTS product, as the role of Ensurance is likely to be limited [4].
Management Swimlane
The SoBP of Section 2, which makes use of this diagram, has a managerial focus. Consequently the main iteration of the Development phase is shown as being driven by the Management strand. The first safety-related decision for management personnel is prompted by receipt of a “Report on Safety Management” resulting from the Ensurance / Assurance activities. This should first occur relatively early in the project, as such corresponding to preliminary safety management. Further such reports may reasonably be expected throughout the project, possibly as part of interim safety case reports.
This report prompts the managerial decision “Safety Management Acceptable?”, which is analysed further in Section 2.4.2 and Annex A.4. If management
personnel confirm that safety management is proceeding acceptably so far then a request “Continue with Development” will be sent to personnel undertaking the Ensurance and Assurance activities. As described in Section 2.4.2., this request that development continue may also include further instructions about required remedial actions to address any safety management problems which have been identified. Although not explicitly shown, these instructions may be intended for Ensurance, Assurance or external developers. This “Proceed with Development and remedial action as required” request represents the first opportunity for iteration in the Development phase. This iteration reflects ongoing safety monitoring, and it is expected that the software development and safety management will then continue (and further safety management reports will be made and will reflect further progress). If the safety management is not deemed acceptable by management a transition to the Containment phase is made.
The next activity shown for managerial personnel in the Development phase is to assess the safety argument “Safety Argument Acceptable?”. As before, the first report on the safety argument should be received relatively early in the project, and will correspond to preliminary argument development. Development of the safety argument (Assurance) will be performed in parallel with risk management (Ensurance) and consequently safety case reports will be expected throughout the project, facilitated by the iteration described below. Again, these reports would typically be expected with a frequency which reflects each major project milestone.
Receipt of this report prompts the managerial decision “Safety Argument Acceptable?”, which is analysed further in Section 2.4.2 and Annex A.4. If Management confirms that safety case development is proceeding acceptably so far, and if the development is not yet complete, then the request “Continue with Development and remedial action as required” will be sent to Ensurance and Assurance. Once again, this request may also include further instructions about required remedial actions to address any problems identified so far with the development of the safety case. This request represents the second opportunity for iteration in the Development phase. Further development on the safety argument will then proceed, and will be informed by any recommended remedial action. As progress continues, further safety case reports may be expected and should reflect the further development of the safety argument. If the safety argument is not considered acceptable (Management decision “Safety Argument Acceptable?”), a transition to the Containment phase is made.
A transition to the Acceptance phase will occur once the development is complete and the safety argument considered acceptable, in as far as can be judged from safety case reports. Note that this process flow reflects that it is impossible to transition to the Acceptance phase without the presentation of a safety argument which is considered provisionally acceptable by Management. However, it is possible to enter the Acceptance phase even if no “Report on Safety Management Progress” has been made to Management. This reflects the situation in which there has been no visibility into the safety management process.
As can be seen, there are two separate points at which iteration can be initiated within the Management swim-lane. On receiving – and approving – an interim report on safety management, management personnel can request that the development activities continue (with remedial action if required). Similarly, on receiving and approving a safety case report, management personnel can similarly request that development activities continue (with remedial action if required). We emphasise that Management personnel should expect to receive reports of these two types at regular intervals throughout the project.
Ensurance Swimlane
The major Ensurance activity in the Development phase is “System build and risk management”, which corresponds to the development of the software (note, this activity will in reality consist of several individual activities and checkpoints, with the likelihood of iteration between these). It should be noted that this activity will be undertaken in parallel with the Assurance activities “Hazard analysis and risk management” and “Develop assurance argument”. A continuous safety analysis dialogue is expected between all three of these activities.
Personnel undertaking Ensurance activities are also responsible for delivering regular reports on safety management progress to Management (56-1 6). These reports will provide visibility into the safety processes, and will constitute reviews of the Safety Management Plan (56-1 8). If these reports are acceptable, Management will request that Ensurance development and safety management activities continue (“Proceed with development and remedial action as required”).
Assurance Swimlane
There are two major Assurance activities in the Development phase; these are “Hazard analysis and risk management” and “Develop assurance argument”. These will be undertaken in parallel with the Ensurance “System build and risk management” activity, and a continuous safety analysis dialogue is expected between all three of these activities. We emphasise that the development of the assurance argument and the analysis of hazards, in particular, are inter-related tasks. Although not explicitly shown on the swim-lane diagram, work on these tasks is by its nature iterative. Consequently, interim results from any of these three activities will inform and direct the progress of the others.
An important Assurance activity is to identify any unjustified assurance deficits (“Unjustified assurance deficit?”). It is important that any unjustified assurance deficits are identified as soon as possible and remedial action taken to attempt to address the problems. This can be best achieved by ensuring that personnel undertaking Assurance activities periodically assess all assurance deficits throughout the development of the safety case. If no deficits of this type are identified, the Development phase activities of Assurance and Ensurance may continue. This represents a third point of iteration in the development phase. If
unjustified assurance deficits are identified, however, this prompts a transition to the Containment phase.
In particular, this decision (“Unjustified assurance deficit?”) must be undertaken prior to any safety case report being made to Management (“Communicate assurance argument as required for SCR”). The process flow as shown implies that any safety case report presented to Management as part of the development phase should not contain any assurance deficits which are unlikely to be justified according to the current SMP.
A.2.3 Acceptance Phase
It is important to note that the Acceptance phase can only be entered if Management considers the software development to be complete and the safety argument acceptable. The Acceptance phase consists of a single Management decision as to whether the software poses an acceptable risk; Section 2.4.3 and Annex A.4 provide further guidance on this. It should be noted that if the project is deemed not to be acceptable, a transition to the Containment phase is automatically made.
A.2.4 Containment Phase
The Containment phase is entered only if a significant safety-related problem is encountered. There are four ways in which the Containment phase may be entered:
Unacceptable Safety Management: In this situation, the Containment phase is
entered because a problem has been identified with the way in which safety is being managed. This is represented by the Management decision box labelled “Safety Management Acceptable?” and will typically indicate an issue arising from the way in which the proposed Safety Management Plan is being implemented. The Containment phase is entered only if there are no credible remedial actions for the identified safety management issue. Therefore, if not addressed by the activities in the Containment phase, this issue will result in an unacceptable assurance deficit.
Unacceptable Assurance Development: This transition occurs when
Management identifies a problem with the development of the safety argument, where this problem was not previously identified as a result of Assurance activities. The Containment phase is entered only if there are no credible remedial actions for the identified issue. If not addressed by the activities in the Containment phase, this problem with the safety argument will therefore result in an unacceptable assurance deficit.
Unjustified Assurance Deficit: This transition occurs when the Assurance
typically indicates that the current SMP and safety case structure are insufficient to justify an identified assurance deficits.
Unacceptable Risk Posed: The Containment phase may also be entered from
the Acceptance phase. This will take place if the safety case does not provide sufficient assurance that the risk posed by the software is acceptable (that is, if there are unjustified assurance deficits).
Management Swimlane
The “first” activity undertaken in the Containment phase involves all swim-lanes, and is intended to identify methods to address the relevant assurance deficit. These methods may include performing further analysis of the software, performing remedial hazard analysis, or eliciting further information required to satisfy currently un-met safety requirements. As shown on the swim-lane diagram, external information about the system may also be sought at this point, as well as further input from additional personnel such as the ISA.
Once these possible solutions – if any are found – are identified, Management personnel must then decide whether the solutions and their associated costs are acceptable (decision box labelled “Acceptable mitigation?”). Section 4.5.1 and Annex A.4 provide further guidance for this decision. If Management deems the solutions appropriate, this is communicated to Ensurance and Assurance (“Request implementation of changes”). This prompts a transition to the development phase; development of the proposed remedial actions can now commence. Where information must be communicated to external developers (e.g. if changes in the project Hazard Log are necessary), this communication is also undertaken.
However, if the solutions and their costs are not acceptable, this prompts a transition to the Management activity “Identify possible role and environment changes to negate safety issue”. This activity is intended as a last resort to identify any possible alterations to the project which will permit the software to be accepted. That is, at this stage there is no credible way of addressing the unjustified assurance deficits which are present. As can be seen, this is again a cross-lane activity which involves Management, Assurance, Ensurance and relevant external personnel.
Management personnel must then decide whether the solutions proposed are acceptable (the Management decision “Circumstances can be changed acceptably?”, for which guidance is provided in Annex A.4). If there are no acceptable role or circumstance changes then the software must be rejected – as the development has already reached the containment phase the software is, by definition, unsatisfactory for its proposed purpose. If, however, there is a change in circumstances which would address the safety problems, then Management will request that this change be implemented. This will typically have an effect on the development and safety management. Consequently, this decision is
communicated to the Ensurance and Assurance personnel (“Request implementation of changes”). This prompts a transition back to the development phase as further development can proceed, given these changes. Where relevant, the necessary changes are also communicated to external developers and managerial personnel.
Ensurance Swimlane
In the Containment phase, Ensurance and Assurance activities are similar; these are “Identify methods to address assurance deficit” and “Identify possible role and environment changes to negate safety issue”. The first of these is triggered by a communication from Assurance, prompting a transition to the Containment phase. The second is triggered by a communication from Management.
Assurance Swimlane
Assurance personnel can initiate a transition to the Containment phase by identifying an assurance deficit which is unlikely to be justified given the current SMP. On identifying this, the Assurance personnel will inform both the Management and Ensurance strands (“Communicate assurance deficit to Management and Ensurance”).
This communication triggers the cross-lane activity “Identify methods to address assurance deficit”. This activity is designed to address the assurance deficit, usually by suggesting alterations to the safety case structure or SMP, such as further testing and analysis to be performed on the software. Once completed, any solutions identified are communicated to Management (“Report on methods to address assurance deficit”).
The other activity in the Containment phase with which Assurance may be involved is “Identify possible role and environment changes to negate safety issue”. This is triggered by a request from Management (“Dialogue about changes to circumstances”), and indicates that the only possible way in which the software can now be accepted is to alter the role or environment in which it will be used. This alteration is intended to provide circumstances under which the difficulties in adequately assuring the software will not necessarily prevent its use. For example, it may be possible to deploy the software in a less safety-critical role, or to omit functionality which cannot be demonstrated to be safe. We emphasise that this activity is intended to be undertaken in conjunction with the Ensurance and Management swim-lanes, as well as external developers.