DO-178B was a comprehensive and levelled set of software development activities and objectives. F ive 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 “ a ctivities” 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 wa s well structured and its intent clearly defined.
DO-178B assume d a traditional software development life cycle that progresses linearly from requirements through design and code to integration and test. Its process model resemble d a waterfall or V model in which validated requirements we re a given (DO-178B d id 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, we re an exception to this.
Verification in DO-178B c a me primarily from top-down testing, an approach that often represent ed 60 to 80 percent of the project budget and wa s driven up because “testing” wa s first performed on the integrated software system long after the requirements and design commitments ha d been made.
DO-178B verification focuse d 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 wa s 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 art e facts) had to be established before the software system wa s considered certifiable. These causal links include d 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 include d a verification of traceability called “slice analysis,” which follow ed 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.