Software Project Management Plan Software Configuration Management Plan Software Assurance Plan Software Requirements Specification Software Design Documentation Verification and Validation Plan Version Description Documentation Safety Analyses and Reports Test Documentation User Documentation and Procedures Operations and Maintenance Plan Risk Plans, Analyses and Reports Retirement/Replacement Plan The provider SMA shall have approval authority over the type and distribution (single or multiple software, system, or facility documents) of documentation which contain provider software safety requirements (process and technical). [SSS-009] This allows smaller projects to combine documentation without losing the benefit of provider SMA approval. SMA is seen as co-approval authority on documents that flow down software safety requirements. The acquirer SMA shall have approval authority over the type and distribution (single or multiple software, system, or facility documents) of documentation which contain acquirer software safety requirements (process and technical). [SSS-010] This allows smaller projects to combine documentation without losing the benefit of acquirer SMA approval. SMA is seen as co-approval authority on documents that flow down software safety requirements. Safety Requirements Traceability Traceability is a link or definable relationship between two or more entities. Requirements are linked from more general form (e.g., the system specification) to their more explicit form (e.g., subsystem specifications). They are also linked forward to the design, source code, and test cases. Because many software safety requirements are derived from the system safety analysis, risk assessments, or organizational, facility, vehicle, system specific generic hazards, these requirements; these will also be linked (traced) from those specific safety data products (examples include safety analysis, reliability analysis, etc.).
The provider SMA ensure that any newly identified software contributions to hazards, event, or conditions found during testing are updated in the system safety data package. [SSS-060] Improper software safety implementation will be entered into the problem reporting system by the provider for resolution and eventual retest. Incomplete or ineffective test procedures can also be managed through the provider problem reporting and resolution process. The provider SMA checks the updated test procedures for completeness and approves the procedures prior to testing. The provider’s software safety test analysis will be available to the acquirer and the acquirer SMA at project formal reviews and system-level safety reviews and upon request. Refer to Section 6.3 of this Standard. Regression testing Regression testing (refer to SSS-051) can vary from a minimal retest of a few units to end-to-end testing. From a safety perspective, it is important that any changes made to the software be regression tested. Changes to the hardware will require hardware and software integration regression testing. From a safety perspective, regression testing needs to assure that any safety controls and mitigations, continue to work as required and that no additional hazard contributions have occurred as a result of the changes. The provider SMA needs to review the proposed regression test coverage and procedures to assure the safety features are adequately covered. Questions to consider: Do transitions between modes and states impact safety? Are changes to parameters, sequence or timing to change hazard controls, computing algorithms, and safety commands? Configuration managed software test suites, created during unit and CSCI testing to test the safety features such as controls, FDIR, and fault and failure recovery, will help make regression testing smoother and better assure safety coverage. SMA focuses on assurance that end-to-end functionality and known hazard controls still work. Software Safety Acceptance Safety critical software is considered accepted when it meets the requirements in this Standard and any additional contract, MOA, or MOU software safety requirements. Waivers and deviations to the safety requirements in this Standard are addressed in section 6.4 of this Standard. Software safety acceptance can be rolled into the system acceptance as long as the software safety features and ability to withstand faults and failures have all been proven at the appropriate level. “Certification” of safety critical software is dependent on the functionality and center implementation. Refer to individual center implementation of “Certification” software processes.