Achieving quality, safety, security and reliability in software systems

Nowhere is it more important today to focus on the improvement of software quality, than in the case of systems with requirements in the areas of safety, security and reliab i l i ty-especia l ly for distributed, real-time and embedded systems. Thus, much research work is currently under progress in these fields, since software process improvement impinges directly on achieved levels of quality, and many application experiments aim to show quantitative results demonstrating the efficacy of particular approaches. Requirements for safety, security and reliability--like other so-called non-functional requirements for automated information systems--are often stated in imprecise and ambiguous terms, or not at all. Specification focuses on functional and technical aspects, with issues like safety covered only implicitly or not addressed directly, because they are felt to be obvious; however, what is obvious to an end user or system user is progressively less so to others, to the extent that a software developer may not even be aware that safety or security is an issue. Therefore, there is growing evidence for encouraging greater understanding of safety, security and reliability requirements issues, right across the spectrum from the end user to the software developer, not just in traditional safety-critical areas (e.g. nuclear, aerospace, etc.) but also acknowledging the need for such things as heart pacemakers and other medical and robotic systems to be highly dependable. Furthermore, there is also enough evidence that highly dependable software-intensive systems can be built. For example, a number of telecommunication, railway and aerospace systems have existed for sufficiently long that their performance could be measured. Moreover, none of the software-intensive airborne systems in use have been demonstrated to be the cause of an accident. Finally, there is growing evidence concerning the efficacy of particular methods and approaches for building dependable systems. However, it is not enough to build reliable software systems; users, in particular, need to have some justification for