In the age of internet dating and unprecedented restaurant closures, you might need to occasionally lower some standards to make the most of daily life. Generally, however, it’s always good to set standards high for your professional, personal, and yes, cuisine-related interests. One (professional) aspect of life where it’s always important to keep high standards: software quality assurance. A related aspect where the highest standards should be applied, and never lowered: Avionics software quality assurance.

Without the proper quality assurance processes and practices in place, you run the risk of missing errors and flaws in your Avionics software’s design and code, read: you unnecessarily risk significant time and financial setbacks. Quality assurance processes also help ensure the final product is competitive, secure, and smoothly performs its expected functions. Needless to say, avionics software quality assurance is a crucial, substantive and impactful part of the avionics project development process. That’s why we had to split this topic into two parts. In this article, we cover the key focal points of Avionics Software Quality Assurance, and lay out the best practices for initial activities (part 2 covers ongoing activities and review).

Software Quality Assurance (SQA) is an integral process of processes and mission-critical piece of complying to DO-178C standards. SQA acts to provide the evidence that a project complies with processes, standards and guidance throughout the development lifecycle. So to start, we’ve created a handy three-phase list that outlines the primary focus areas of SQA, in relation to DO-178C:

Phase I (project start):

• Checking that the PSAC and the associated plans and standards align with the objectives of DO-178C.
• Creating a Software Quality Assurance Plan (SQAP).
• Checking that software life cycle processes comply with approved plans and standards.
• Establishing supplier oversight.

Phase II (project execution):

• Checking that software activity follows the software lifecycle processes, paying particular attention to any and all transition criteria between lifecycle processes.

Phase III (project review):

• Conducting the conformity review of the software product (more on this in part 2). These activities must be conducted whether software activities are internal to one organization or part of an integrator-supplier relationship. In the latter case, each organization that has further suppliers must coordinate SQA activities so that the integrator’s evidence includes evidence from their supplier’s SQA activities.

Your project’s phase particulars aside, you need to ensure SQA activities are involved at every stage, especially while defining plans and standards so your observables can be easily gathered and alignment with key guidelines, namely, DO-178C. When writing plans and standards, it makes sense to start with the end result you want to and work backwards—the software quality assurance records that you need for final submission—and work backwards to identify how you will generate each item. This will help create checklists and identify supporting tools to collect compliance evidence, as well as inform the plans and standards. Typically, you’ll end up planning to use a mix of tools and techniques and document this in the relevant planning documents.

One critical key best practice in the initial and ongoing phases: when supplier organizations are involved in your program, it is best to coordinate SQA activities with all stakeholders as early as possible. For each SQA-specific item in your own plans, you should coordinate how you will obtain that information from the supplier, in what form, and at which milestones. This can be especially challenging for witnessing and participation activities where you may need to delegate some authority to the supplier organization and then audit the responses that you obtain, but we’ll get into that and the final stages of SQA (conformity review activities) in part 2 of this blog series.

Just remember, SQA is a necessary and helpful piece of your avionics software project puzzle, and should always be looked at as an opportunity to make your projects move quickly and more cost-effectively.