One of the things I see and hear is that we can “finish that certification stuff later.” Many people believe that you can add the compliance data items to the project after you “get it working” or you “know you are finished with design and implementation.” This bottom-up approach to Certification compliance under DO-254 and DO-178 is in direct opposition to why these design assurance documents were drafted. Let me be clear: while there is room for a rapid prototyping flow within the constraints of these design assurance documents, this sort of flow is only used as a way to validate and confirm that you have the right set of requirements.
A bottom-up compliance effort does not equal top-down unless you have relatively simple functionally. Design assurance processes described by DO-254 and DO-178C are both in place to acknowledge the complexity of avionics systems and the inherent knowledge that if you wait to perform verification and validation on the final image you will be faced with the inability to show you adequately identified potential errors in the design. This concept is discussed as the Complexity Barrier [Beizer90] principle: Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity. This is why DO-254 design assurance standard was written primarily for “complex” hardware and there is an acknowledgment that for simple systems the majority of DO-254 does not apply. DO-178C section 12.3.2 allows for “exhaustive input testing” of your software if it is truly simple as an alternate means of compliance. Top Down design assurance defined in DO-254 and DO-178C hinges on the concepts of integral processes and transition criteria throughout the development with levels of independence and process assurance that will help to identify design errors earlier and throughout development. In other words, the whole purpose of “design assurance,” be it in software or hardware, is to demonstrate that during the process, you have taken all pertinent steps to ensure you are catching and/or eliminating design errors at every step of the design (i.e., development) process.[Beizer90] Boris Beizer, Software Testing Techniques. Second edition. 1990
If your management or someone on your team is struggling to understand the purpose and/or basic requirements of compliance – whether its at the hardware, software or systems level – Patmos Engineering Services training can help. We offer a class called “Certification Overview” which covers the fundamentals of compliance at all these levels.