Welcome to part 2 of our 2-part article series – Higher Standards: Best Avionics Software Quality Assurance Practices. If you haven’t read part 1 yet, we encourage you to do so whenever convenient, though we did our best to make sure both parts can fly solo, so to speak. That said, the articles make a phenomenally informative pair for comprehensively explaining the processes, procedures and best practices involved in Software Quality Assurance (SQA) for Avionics and Aerospace.
In part 1, we discussed why SQA is such a crucial part of any avionics software development lifecycle, laid out the phases of the entire process, and offered best-practice outset activities to set the right tone of your project, that being ensuring it and your SQA run their best. We also gave a quick definition of the topic, made quicker here: SQA provides the records necessary to determine if a project has complied with critical legal requirements and key industry standards and guidelines. In this article, we’re discussing the importance of ongoing SQA activities in the latter stages of your project, giving the end-stage, conformity review, some extra attention.
As we regularly mention, a non-negotiable must-have for any task within aerospace is a well-thought out plan. SQA activities are no exception For your project’s SQA ongoing activities to be successful, the Plan should an exhaustive encyclopedia of activities performed (or rather, to-be performed) throughout its lifecycle. Thoughtfully developed SQA plans will, among other positive things, provide the framework for recording and recognizing that your key ongoing activities and tasks both meet DO-178C guidelines and adhere to subsequent mission-critical standards.
These key activities and tasks include:
• Independent assessment – activities where SQA independently assesses various tasks and conditions specified in your plans and/ or the outputs of those tasks. Independent assessment can be applied to, for example, life cycle data, transition criteria, life cycle environment, SCM processes and records. Typical issues discovered through independent assessment activities include identifying software changes without corresponding requirements updates or identifying discrepancies in the versions of tools used by different parts of the engineering organization. It is sensible to build procedures, checklists and tools to support these activities, and consider what training your SQA team may need in independent assessment and auditing.
• Participation – activities in which SQA have a continuous active role. This can include, for example, participation in reviews, change control boards, and problem reporting (see Problem reporting on page 10). Software quality engineers would typically be present at some percentage of these meetings to help identify issues such as process deviations, missed checklist items, or confusing instructions. As well as generating software quality reports to explain attendance and identifying issues and corrective actions applied, another benefit of participation is to correct processes and update supporting materials as early as possible. This can help avoid the need for significant later rework to correct quality problems.
• Witnessing – this involves members of the SQA team witnessing activities such as testing and the build and load process. Witnessing can be in multiple forms, for example witnessing the original activity being performed, witnessing an engineer redo the activity, or independently performing the activity. Using a mix of these techniques will help to give a good spread between the efficiency of the checking process and the independence needed to find inconsistencies.
Lastly, the SQA team in a DO-178C project has the responsibility for conducting a conformity review. This review typically performed as the final step going into SOI#4, which we review in our regular live and online trainings, provides documentation showing that the software life cycle is complete. Your conformity review report will summarize and cross-reference evidence that you collect throughout the software life cycle, showing that:
- Planned processes were followed and generated traceable, controlled life cycle data, with complete and consistent baselines, including any data relating to changes from a previous baseline.
- Deviations and open problem reports were reviewed and approved.
- Software test, build and load activities were performed from repeatable, well-defined instructions.
Like we said in part 1, SQA is an essential and exceptionally helpful part of your avionics software’s journey, and you should always consider the opportunities SQA offers in helping to realize a software project and help it reach the pinnacle of success.