developmental error. Compliance to a DAL is a safety requirement that must be identified in the SRM document in order for it to be properly tracked and eventually verified and validated. Additionally, software design safety requirements, as well as development and testing processes, must be at an assurance level proportional to the degree to which the software product can contribute to a system hazard. System and hardware DALs are determined using SAE ARP4754 and RTCA DO-254. Appendix J provides more detail on determining the correct DAL. 

## 9.4.1.2 RTCA DO-278A Compliance Gap Analysis 

Many of the non-airborne CNS/ATM systems have been developed and fielded using software development processes other than those in RTCA DO-278A, such as those contained in Institute of Electrical and Electronic Engineers Standard 12207, Systems and Software Engineering – Software Life Cycle , or in the vendor’s best practices. This could potentially result in problems when incorporating RTCA DO-278A software assurance requirements for additions to and/or modifications of non–RTCA DO-278A legacy systems. For these cases, an RTCA DO-278A compliance gap analysis must be used to evaluate how the non–RTCA DO-278A processes adhere to the intent of RTCA DO-278A. 

The PO must conduct an RTCA DO-278A compliance gap analysis for each function within the system/software being evaluated. RTCA DO-278A guidelines ensure a specific software design and development assurance from the system’s safety analysis process, one that is based on software architecture and functions. The RTCA DO-278A compliance gap analysis provides a basis for addressing any shortfalls from the required RTCA DO-278A objectives. The gap analysis compares existing processes with RTCA DO-278A and identifies deficiencies. The process is then improved to resolve the deficiencies. 

The PO must describe the improved process in the PSAA, which is provided to the approval authority along with the RTCA DO-278A compliance gap analysis. This PSAA not only defines the PO’s/vendor’s plan for RTCA DO-278A compliance but also documents the deficiencies found in the gap analysis as well as the plan to resolve these gaps. The PSAA must be summarized or referenced in the PSP. 

Conducting the RTCA DO-278A compliance gap analysis is not a specific safety responsibility. Typically, this effort is led by the PO acquiring the new system or proposing changes to an existing system. This is typically done with help from the prime contractor conducting systems integration and the subcontractor(s) responsible for developing the software. Ideally, it should be performed before the contract award as a way to evaluate different vendors. Other key participants in the process are the approval authority and the RTCA DO-278A SME (someone who has qualified skills and knowledge related to software assurance, specifically related to RTCA DO-278A or RTCA DO-178C, and who is acceptable to the approval authority). Appendix K provides more detail on developing an RTCA DO-278A compliance gap analysis. 

## 9.4.1.3 Software Approval Process 

The software SME within the PO must review the software lifecycle processes and associated data to confirm that a software product complies with the approval basis and RTCA DO-278A. The PO should involve the AJI safety case lead in this review, as appropriate. The software review process assists the applicant, approval authority, and system developer in determining whether a project meets the approval basis and satisfies RTCA DO-278A guidance. The software review process does this by providing: 

