Software is ubiquitous in safety-critical systems and the size of the software can be enormous—tens of millions of lines of code is not unusual today. How can the safety of such systems be assured? While government certification is only required for a few systems (such as aircraft, nuclear power plants, and some types of medical devices), other commercial products are potentially subject to lawsuits and other liability issues that force companies to have an effective strategy for dealing with safety. At the extreme, highly publicized accidents can lead to a company going out of business. Some military systems, which are often out of the public eye, can have potentially catastrophic consequences if they go wrong.
Almost all current approaches to certifying critical systems or assuring the safety of such systems were created when our engineered products were electromechanical. Meanwhile, enormously complex software has been introduced into these safety-critical systems with relatively few significant changes to the way systems are certified or assured. Software-related accidents in every industry are occurring in exactly the ways assurance approaches determined were implausible or impossible or in ways that were overlooked entirely during certification and safety assessment. Creating effective approaches will require changes in the way software is engineered today.
In my humble opinion, writing, reviewing (by all concerned stakeholders) and validating software requirements not only for the functional suitability, but also for other software qualities: namely, (i) performance efficiency; (ii) compatibility; (iii) usability; (iv) reliability; (v) security; (vi) maintainability; and (vii) portability and their defined sub-characteristics (vide ISO/IEC SQuaRE Standard 25010:2017), each expanded to a level of detail that is possible upfront (and kept updated as the development progresses); concentrating on safety aspects; are to be made mandatory for safety-critical software.
Displaying 1 comment