Avionics Development Transitions – For Avionics Engineers and Managers
Avionics development requires multiple activities, each with entry/exit criteria. Quality Assurance defines and enforces these “transition criteria”. Learn how to define and comply with DO-178C and DO-254 transition criteria.
When safety is critical, safety-critical systems must ensure the orderly, measured conduct of engineering activities and sustain attention to detail. Quite literally every activity has entry and exit criteria which must be defined and documented in advance with a corresponding set of product and process criteria (that will be used by the FAA) to assess and ensure adherence. For example, before implementing software logic (“coding”), critical systems must have various pre-defined, formally reviewed artifacts in place (under formal configuration control) including software requirements, design data, and software coding standards by which the code can be verified. The order of these engineering activities is thus predicated on “transitions” (mini gate reviews) which must be assessed by QA and sometimes approved by the certification agency (FAA, EASA, Military, etc.) before the development team can proceed to the next phase.
These engineering transitions can be defined in a separate document or embedded within the applicable Software Transition Plan (STP) as an optional document which defines the various software engineering lifecycle transition steps that are performed during planning, development, and V&V. While defined transitions are required per DO-178, many companies embed them within the Software Development Plan (SDP) and the Software Verification Plan (SVP) instead of placing them in a separate STP document. Also, since Quality Assurance (QA) is generally tasked with auditing and assessing adherence to transition criteria, the Software Quality Assurance Plan can detail such.
Transition planning is necessary to show that predefined entry and exit (look at ETVX which encourages development of process control and verification/validation of tasks before exit criteria) criteria exist for software engineering transitions, and that those entry/exit criteria are followed and audited. For example, software requirements must be reviewed and base-lined prior to initiating the high-level software design.