Confidence in software quality is a rare commodity throughout all industries. Software publishers, users, and system integrators are highly distrustful of anyone else's software. In contrast, hardware is far less feared.

Reasons for this are plentiful, not the least of which is the fact that software is nonphysical, and therefore it is very hard to measure how good a software system is or any of its components are. The key issue are what constitutes trustworthy software? Is it software that was developed or tested a specific way? Is it software that has a particular structural appearance? Or, is it software that will behave as defined in the software specification?

All three of these questions can lead to confidence that the software is, in some way, better. However, if the question is changed to “What constitutes “reliable” software?” there is another perspective. For this perspective, assurance can only be offered by knowing whether the software will behave as defined according to the specification. Knowing whether this is true is highly problematic, since software behavior is unpredictable (as a result of the inability to exhaustively test).

Assurance can be qualitative, like the FAA's (Federal Aviation Administration's) software development guidelines in DO-178B that define levels of assurance (A through E) or the Software Engineering Institute's Capability Maturity Model (CMM) rating. Or assurance can be quantitative, like a probability of failure or a reliability estimate.

Direct software assurance is and examination of software produced. Direct assurance should provide greater confidence. Direct and indirect approaches are discussed.