Development Assurance process software design

Software reliability assessment is different from traditional reliability techniques and requires a different process. The use of development standards is common in current good practice. Software safety standards recommend processes to design and assure the integrity of safety-related software. However the reasoning on the validity of these processes is complex and opaque. 

The cross-domain assurance process for safety-relevant software in embedded systems, outlined in this paper, aims to be applied in various different application domains. Thus, supporting the cost-efficient system development as well as the reuse of techniques and tools for the safety analysis. However, not all of the process steps can be realized in a generic and domain-independent way. But our approach is independent from concrete development methodologies and can be applied along with component-based and model-based design. Moreover, common safety analysis techniques can by applied in most process steps. 

Systemic failures are due to human errors (e.g. mistakes, misconceptions, miscommunications, omissions) in the specification, design, build, operation and/or maintenance of the system. Errors in this case are taken to include both mistakes and omissions. Errors can be introduced during any part of the lifecycle and errors are caused by failures in design, manufacture, installation or maintenance. Systematic failures occur whenever a set of particular conditions is met and are therefore repeatable (i.e. items subjected to the same set of conditions will fail consistently) and thus apply to both hardware and software. It is difficult to quantify the rate at which systemic failures will occur and a qualitative figure based on the robustness of the development/build process is normally used. The probability of systemic failures is often evaluated by means of safety integrity (or development assurance) levels. 

Commensurate levels of assurance are required for each part of the development process. Therefore, whilst verification of code by static analysis, for example, meets a clear need, it does not address systems issues at all. Experience has shown that, particularly with real-time or reactive systems, that the difficult design issues do not arise in the software itself the complexities of synchronisation and interference exist... 

---