4) The approval authority verifies the PO’s activities.  5) The approval authority approves RTCA DO-278A compliance and related artifacts.  As such, all documentation that is submitted to the approval authority must be reviewed for  compliance by the PO and SQA.  RTCA DO-278A requires that the system developer submit—at a minimum—the PSAA, SCI,  and SAS to the approval authority. These three documents summarize the entire project at its  beginning and at its end. The SRMGSA requires the PO to evaluate all lifecycle data and  provide evidence of compliance to the ATO Chief Safety Engineer. The PO must approve the  system developer’s submittals per the requirements of the  Statement of Work (SOW) and other  contractual language. AJM is the product approval authority, and the ATO Chief Safety  Engineer is the safety approval authority.  Due to their importance, the following sections elaborate on the contents of the PSAA, the SCI,  and the SAS. However, these elements only make up the basic outline of the documents. RTCA DO-278A provides more detail on the contents of the individual sections. The PSAA  discusses how the SDP, SVP, SCMP, and SQAP are going to account for and check all  required activities. The SCI describes the product itself. The SAS highlights what has been  accomplished to verify that all planned activities have been completed. The philosophy behind  these documents is that all activities should be planned for and reviewed. The PSAA demonstrates how the program will comply with AMS, Section 4.12, which requires  the developer to have a development assurance program that meets the requirements of the  latest version of RTCA DO-278A or an equivalent standard. The PSAA serves as the primary  means for communicating the proposed development methods to the approval authority. Per  AMS, Section 4.12, software-intensive systems can establish a development assurance  program in accordance with RTCA DO-278A; this is an acceptable way to demonstrate that a  software product was developed at the appropriate level of rigor. The approval authority uses  the required output to determine whether the system developer is proposing a software lifecycle  that is commensurate with the level of rigor required for the software being developed.  The PSAA provides a summary of the SDP, the SVP, the SCMP, and the SQAP by describing  the overall project and how developmental assurance objectives will be satisfied. If the system  developer subcontracts work to another supplier, the PSAA must also cover how the system  developer will perform supplier oversight. The SRMGSA requires that the system developer submit the PSAA for FAA approval. AJM has  been designated the approval authority. It is critical that the system developer submit the PSAA  to the government in a timely manner so meaningful input can be provided. This will allow the  PSAA to be approved and implemented prior to the critical design review. Ideally, the PSAA  should be incorporated into the system developer’s overall development plan and should be  approved prior to the closeout of the System Specification Review conducted by the system  developer. When using RTCA DO-278A as a means of ensuring compliance with AMS, Section 4.12, the  associated RTCA DO-278A supplements must also be used where applicable. The following  M_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  M-3  3.2  PSAA 