to the approval authority and/or SME. However, only the data shown in Table L.2 are of special  interest for this review. The supporting software data should undergo the configuration control  appropriate for the AL.  Evaluation criteria for this review include all objectives of RTCA DO-278A, Annex A. Additionally, all software-related problem reports, action items, approval issues, etc., should be  addressed before approval.  Note : Although this appendix proposes four types of reviews, the type, number, and extent of  those reviews may not suit every project and applicant. Additional considerations and  alternative approaches may be appropriate.  The purpose of design assurance is to catch errors as early as possible in the design process  and prevent them from being incorporated into the final product. The overall concept is that a  review (or intervention) should be conducted:  When to conduct each review depends upon the developer’s plans. Table L.3 provides a rough  timeline of when to conduct the different reviews.  Table L.3: Data Availability for Software Final Approval Review  Table L.2: Data Availability for Software Final Approval Review  6.3  Intervention Points  L_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  L-9  Software Planning Reviews  Review the draft PSAA as soon as possible. Close out  prior to the Preliminary Design Review.  Software Development Reviews  Start after the development of the first draft of the  software requirements document. Close out prior to the  Critical Design Review.  Software Verification Reviews  Start during software requirements testing. Close out  prior to the first delivery of software.  Final Approval Software Reviews  Start prior to formal system-level testing. Close out prior  to the physical/functional configuration audit.  Software Data  RTCA DO-278A  Software Verification Results  11.14  Software Lifecycle Environment Configuration Index  11.15  SCI  11.16  Problem Reports  11.17  Software CM Records  11.18  SQA Records (including Software Conformity Review Report)  11.19  SAS (must be submitted to the approval authority)  11.20  • Early enough in the design process that corrective action can be taken to ensure  compliance and reduce the repetition of work.  • Late enough to have enough data for a good sample to be used to represent how well  the development is progressing.  • At a point where progress can be halted, if needed, before the completion of a milestone  to resolve issues of non-compliance before they can corrupt the next design stage. 