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.  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.  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:  9.4.1.3 Software Approval Process  9.4.1.2 RTCA DO-278A Compliance Gap Analysis  9_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  55