DO-178B was a comprehensive and levelled set of software development activities and objectives. Five Safety Integrity Levels (SILs) were included in the standard – levels A, B, C, D, and E – with level A being the most safety critical and Level E having no impact on aircraft safety. Obligatory “activities” were to be completed in order to achieve specific “objectives.” A comprehensive cross-referencing of these objectives was provided in the standard against each of the five SILs. In this way, DO-178B was well structured and its intent clearly defined.

DO-178B assumed a traditional software development life cycle that progresses linearly from requirements through design and code to integration and test. Its process model resembled a waterfall or V model in which validated requirements were a given (DO-178B did not mention requirements validation), and there was a de facto partitioning of the requirements engineering and software development processes. “Derived Requirements,” non-functional requirements derived from the design or implementation process, were an exception to this.

Verification in DO-178B came primarily from top-down testing, an approach that often represented 60 to 80 percent of the project budget and was driven up because “testing” was first performed on the integrated software system long after the requirements and design commitments had been made.

DO-178B verification focused on test coverage of functional requirements and software structures via structural coverage analysis, as well as data and program-control structures. The measurement of data and control coverage was typically performed as a manual, ad hoc analytical process, escalating verification costs.

Finally, in DO-178B, traceability (causal links between requirements at different levels and associated software development artefacts) had to be established before the software system was considered certifiable. These causal links included both static links that had to be established and maintained (such as mapping from low-level requirements to source code) and dynamic links (as determined by structural coverage analysis).

Typically, certification readiness included a verification of traceability called “slice analysis,” which followed one high-level software requirement to its low-level requirement(s) and associated test cases through design to source code and then to object code.

DO-178B Overview