This type of Software Safety Analysis prioritizes the overview of all conditions that must be satisfied by every product while taking into account any pending requests from stakeholders and the like.
This type of Software Safety Analysis prioritizes the overview of all conditions that must be satisfied by every product while taking into account any pending requests from stakeholders and the like.
This Software Safety Analysis is required for judging and checking the top level designs of a software, including any code that may pertain to the said design.
This is a subset of the Software Safety Design Analysis which focuses primarily on the design of the software, but this simply consists of a quick run through of the cods and top levels.
This is a secondary version of the Software Safety Design Analysis wherein the code is inspected thoroughly for any issues regarding design and how it may be expressed in the final product.
This Software Safety Analysis concentrates only on the code and all the possible issues it may present while it is being used or run by the user.
This type of Software Safety Analysis utilizes testing measures to make statistical accounts of observable errors and hazardous aspects of the code and the product itself.
This aspect of the Software Safety Analysis focuses mainly on parts of the product and code which may result in faulty and unreliable output.
The Software Safety Analysis approach concentrates on specific hardware and software components that support Safety Critical Functions. Safety Critical Functions are processes and protective measures that can be placed within a system to either prevent or inhibit the progress of an accident from occurring. Initially, each software-controlled function will be assessed for criticality and a Safety Critical Functions (SCF) list is created.
This process step will ensure that each individual module of code that performs these functions is officially labeled as “safety-critical” and is tracked to ensure that required design, coding and test activities, as appropriate to its assigned safety-criticality level, are accomplished. This means that every possible aspect of the system will be checked and padded with security measures to ensure the integrity of the whole system.
Additional guidance that may be used to perform and document these analyses can be found in the IEEE 1228, MIL-STD-882, RTCA DO-178B and RTCA DO-254. These are all Standard Safety Plans that dictate how to develop, maintain, procure, and retire equipment especially those that may pose unnecessary risks to its users.
Software Safety will participate in software Preliminary Design Reviews (PDRs), detailed design reviews, and Technical Interchange Meetings (TIMs), as needed, to ensure resolution of technical/process issues identified during the software design product evaluation phase. This facet of the process is utilized to minimize all possible errors that have been brought up. In this manner, all design and technical issues will be resolved as soon as possible.
Coordinate the Software Product Evaluations (SPEs) of the Software Data Requirement Lists (SDRLs) (i.e., SRS, IRS, STP, STD, VDD, STR and SPS) with Supplier Software Safety/SQA. This activity will be conducted by using product review checklists. This step will assure that all products are of high quality and are marketable according to any and all standards applied to it, for both safety and hazard requirements as well as any outstanding investor requests.