• Software Lifecycle:  Summarize how the software lifecycle has unfolded, and explain  the differences between the actual software lifecycle and the software lifecycle  processes originally proposed in the PSAA.  • Software Lifecycle Data:  Describe any differences between the collected software  lifecycle data and the lifecycle data proposed for collection in the PSAA. Also describe  the relationship between lifecycle datasets as well as their relationships to other data  defining the system; and describe how the data were made available to the approval  authority. This section explicitly references, with configuration and version identifiers,  the applicable SCI and SECI. Detailed information regarding configuration identifiers  and specific versions of software lifecycle data are provided in the SCI.  • Additional Considerations:  Summarize any specific considerations that may warrant  the attention of the approval authority. Explain any differences from the proposals  contained in the PSAA regarding such considerations. References should be made to  data items applicable to these matters, such as contractual agreements or special  conditions.  • Supplier Oversight:  Describe how supplier processes and outputs comply with system  plans and standards.  • Software Identification:  Identify the software configuration by part number and version.  • Software Characteristics:  State the EOC size, timing margins (including worst-case  execution time), memory margins, resource limitations, and the means used for  measuring each characteristic.  • Change History:  If applicable, include a summary of software changes with attention to  changes made due to failures affecting safety, and identify any changes in /  improvements to the software lifecycle processes since the previous approval.  • Software Status:  Summarize any PRs unresolved at the time of approval. The PR  summary includes a description of each unresolved problem and any associated errors,  functional limitations, operational restrictions, potential adverse effects on safety,  justification for allowing the PR to remain open, and details of any mitigating action that  has been or needs to be taken.  • Compliance Statement:  Include a statement of compliance and a summary of the  methods used to demonstrate compliance with criteria specified in the software plans. Address additional rulings made by the approval authority and any deviations from the  software plans, standards, and the PSAA not covered elsewhere in the SAS.  The results of the SAS must be summarized in the System Safety Assessment Report.  The PO must establish the contractual requirements in the SOW to ensure that they have  access to all the lifecycle data as well as a schedule to ensure the necessary documents are  delivered in a timely manner. The SOW should also account for the review of the documents by  all the approval organizations and consider that multiple revisions may be required before a  document can be finally approved. RTCA DO-278A requires that all documentation be correct. Changes to the project may require updates to all impacted documents. The Data Item  Descriptions (DIDs) for a PSAA, SCI, and SAS  are available in the DID Library. The PO may  tailor the DIDs as necessary.  4  Establishing the Contractual Requirement  M_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  M-7 