Development Assurance process software requirements

As with pharmaceuticals themselves, remember that you can t test quality into the finished software product it must be produced utilizing quality processes throughout. Require evidence of quality assurance and development processes within your firm and during vendor audits. 

The goal of safety assessment is to identify all failures that cause hazardous situations and to demonstrate that their probabilities are sufficiently low. In the application domains of safety-relevant software the safety assurance process is defined by the means of safety standards. The requirements of these standards must be met in order to enable argumentation that the system is safe. To reduce development costs and the time-to-market, one possible approach is to develop a safety assurance process which is applicable to multiple applications domains of embedded systems (e.g. like the lEC 61508 standard [3]). In this paper, we present an approach towards a safety assurance process for software which is applicable across different application domains of embedded systems. This process aims to be applicable with various development methodologies used in different domains and tries to use common safety analysis techniques as far as possible. Hence, it builds the foundation for the future development of methods and tools for safety assurance which can be applied across domains of safetyrelevant software systems. Thus, safety analysis techniques and tools as well as artifacts produced during the safety assurance process may be reused for the safety assessment of different kinds of products. Especially, in areas where embedded systems are highly related to software product-lines or heterogeneous... 

It is almost impossible to test complex software fully - even if it is run many times - as there are an almost infinite number of possible loops, variables and subroutines that may or may not be run in any single program. Program operation is by its very nature non-linear or non-determined and therefore can never be fully tested at box level. For these reasons, reliability calculations are not applied to software, as it has no MTBF. Instead, we make use of development assurance levels (DAL) or safety integrity levels (SIL) (see Table B.6). The main aim or purpose of DALs and SILs is to introduce a number of repeatable life-cycle processes which (if used by the developer) will produce a final product that is capable of meeting not only the original specification requirements, but also producing the correct level of safety both for the developed equipment and the overall aircraft. 

This requirement is usually met by means of the audit conducted by the pharmaceutical or healthcare company. The audit examines the quality assurance attributes of the supplier s process, the firm s general capability maturity, and the suitability of its equipment or service suggested for use on the project. Suppliers in this context may be understood to include equipment vendors, service suppliers, or the pharmaceutical or healthcare company s in-house software development department. Regulators hold pharmaceutical and healthcare companies accountable for the use of suppliers whose capability assessment indicates their inability to deliver validatable, compliant software. ... 

The inspection of the capability of the process in order to gain the required assurance as to the fitness for purpose of the developed software—a measure of its validatabillty—is referred to here as a software quality assurance audit. The software quality assurance audit is occasionally referred to as a Supplier Audit (e.g., in the GAMP Guide). However, a Supplier Audit is also used to audit original equipment manufacturers, hardware suppliers, independent contractors and even an internal department with a pharmaceutical organization. There may be no "software" involved at all. For that reason, the term software quality assurance audit is more preferable than Supplier Audit. 

Whereas pre-developed software will be exeeptional in eategory A, because of the stringent requirements on product, process and their documentation, this type of software will be found more fiequently in category B and C. The proposed relaxations of qualification criteria in category B against category A are mainly the reduced amount of documentation required and a weaker process of product assurance. Table 4 shows the first level qualification criteria for category B. 

At the other end of the spectrum, are standards which address the processes of development and manufacture - non-safety examples range from the very broadly based ISO 9000 series to the more specific ED-78A (Guidelines for the Approval of the Provision and Use of ATS Supported by Data Communications) and ED-109 ( Guidelines for CNS/ATM System Software Integrity Assurance). In none of these cases would it be appropriate to certify a product against them, from a safety viewpoint however, compliance with such standards, especially the more specific ones, could provide excellent Backing Evidence for safety requirements... 

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. 

Abstract. Modern safety-critical systems are increasingly reliant on software. Software safety is an important aspect in developing safety-critical systems, and it must be considered in the context of the system level into which the software wiU be embedded. STPA (System-Theoretic Process Analysis) is a modern safety analysis approach which aims to identify the potential hazardous causes in complex safety-critical systems at the system level. To assure that these hazardous causes of an unsafe software s behaviour cannot happen, safety verification involves demonstrating whether the software fulfills those safety requirements and will not result in a hazardous state. We propose a method for verifying of software safety requirements which are derived at the system level to provide evidence that the hazardous causes cannot occur (or reduce the associated risk to a low acceptable level). We applied the method to a cruise control prototype to show the feasibility of the proposed method. 

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... 

---