If you write software for a living, this might be of interest.
How can software and the systems that rely on it be made dependable in a cost-effective manner, and how can one obtain assurance that dependability has been achieved? Rather than focusing narrowly on the question of software or system certification per se, this report adopts a broader perspective.
The committee thus subscribes to the view that software is “guilty until proven innocent,” and that the burden of proof falls on the developer to convince the certifier or regulator that the software is dependable.
Software, according to a popular view, fails because of bugs; as is well known to software engineers, by far the largest class of problems arises from errors made in the eliciting, recording, and analysis of requirements. A second major class of problems arises from poor human factors design.
The culture of an organization in which software is produced can have a dramatic effect on its quality and dependability.
The focus of this report is a set of fundamental principles that underlie software system dependability and that suggest a different approach to the development and assessment of dependable software. The committee’s proposed approach can be summarized in “the three E’s” -- explicit claims, evidence, and expertise.
