曝光臺 注意防騙 網曝天貓店富美金盛家居專營店坑蒙拐騙欺詐消費者

generally ends with the completion of the program and its associated testing; whether it is a single phase of
the development process or continues throughout the development, production, deployment and maintenance
phases. Management efforts end when the last safety deliverable is completed and is accepted by the FAA.
Management efforts may then revert to a “caretaker” status in which the safety manager monitors the use of
Software Safety Team
Software Engineer
Software Quality Assurance
·  Software Test Engineer
·  Domain & Systems Design
System Safety Program Manager
System Safety Engineer
·  Software Safety Lead
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-7
the system in the field and identifies potential safety deficiencies based on user reports and accident/incidents
reports. Even if the developer has no responsibility for the system after deployment, the safety program
manager can develop a valuable database of lessons learned for future systems by identifying these safety
deficiencies.
Establishing a software safety program includes establishing a SwSWG. This is normally a sub-group of the
SSWG and chaired by the safety manager. The SwSWG has overall responsibility for the following:
·  Monitoring and control of the software safety program
·  Identifying and resolving risks with software contributory factors
·  Interfacing with the other IPTs, and
·  Performing final safety assessment of the system (software) design.
10.3.2 Assign Software Criticality
The ability to prioritize and categorize hazards is essential for the allocation of resources to the functional
area possessing the highest risk potential. System safety programs have historically used the Hazard Risk
Index (HRI) to categorize hazards. However, the methodology to accurately categorize hazards using this
traditional HRI matrix for hazards possessing software causal factors is insufficient. The ability to use the
original (hardware oriented) HRI matrix was predicated on the probability of hazard occurrence and the
ability to obtain component reliability information from engineering sources. The current technologies
associated with the ability to accurately predict software error occurrence, and quantify its probability, is still
in its development infancy. This is due to the nature of software as opposed to hardware. Statistical data
may be used for hardware to predict failure probabilities. However, software does not fail in the same
manner as hardware (it does not wear out, break, or have increasing tolerances). Software errors are
generally requirements errors (failure to anticipate a set of conditions that lead to a hazard, or influence of an
external component failure on the software) or implementation errors (coding errors, incorrect interpretation
of design requirements). Therefore, assessing the risk associated with software is somewhat more complex.
Without the ability to accurately predict a software error occurrence, supplemental methods of hazard
categorization must be available when the hazard possesses software causal factors. This section of the
handbook presents a method of categorizing hazards that possess software influence or causal factors.
Risk Severity
Regardless of the contributory factors (hardware, software, human error, and software influenced human
error) the severity of the risk could remain constant. This is to say that the consequence of risk remains the
same regardless of what actually caused the hazard to propagate within the context of the system. As the
severity is the same, the severity tables presented in Chapter 3 remain applicable criteria for the
determination of risk severity for those hazards possessing software causal factors.
Risk Probability
With the difficulty of assigning accurate probabilities to faults or errors within software modules of code, a
supplemental method of determining risk probability is required when software causal factors exist. Figure
10-2 demonstrates that in order to determine a risk probability, software contributory factors must be
assessed in conjunction with the contributors from hardware and human error. The determination of
hardware and human error contributor probabilities remain constant in terms of historical “best” practices.
However, the likelihood of the software aspect of the risk's cumulative causes must be addressed.
FAA System Safety Handbook, Chapter 10: System Software Safety
December 30, 2000
10-8
Contributory
HAZARD
Software Hardware Human
Error
Likelihood
of Occurrence
Base Upon
　
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統安全手冊上(7)