曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
tolerance, etc.)
· Design and implementation is properly incorporated into the software safety requirements.
· Appropriate verification and validation requirements are established to assure proper
implementation of software system safety requirements.
· Test plans and procedures can achieve the intent of the software safety verification
requirements.
5 Reference D.
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
17
· Results of software safety verification efforts are satisfactory.
The Institute of Electrical and Electronic Engineering (IEEE) offers a comprehensive standard (Standard
for Software Safety Plans) focusing solely on planning. The Standard articulates in sufficient detail both
software safety management and supporting analyses. The Standard’s annex describes the kind of
analyses to be performed during the software requirements, design, code, test and change phases of the
traditional life cycle. Similar planning models are provided by the Department of Defense (DOD)
Defense Standard 00-55-Annex B.
Software Safety Organization
Safety oversight consists of a staff function crossing several organizational boundaries. By its nature, it is
meant to interact with other staff and line functions, including program or project management, software
system design, quality assurance, programming, reliability, testing, human factors, and operations.
Accountability-wise, the ultimate responsibility for the development and operation of a safe software
system(s) rests with the CST applicant or licensed operator. Thus, the applicant’s or operator’s top
management should be committed to supporting the software safety process across all these staff and line
functions.
A software safety organization can take one of many shapes, depending on the needs of the applicant or
licensed operator. However, the following requisites are recommended:
· Centralized authority and responsibility dedicated to the safety initiatives
· Safety team independence, and
· High enough safety team status relative to the rest of the organization.
Centralization allows a single organization to focus entirely on hazards and their resolutions during any
life cycle phase, be it design, coding or testing. Independence prevents bias and conflicts of interest
during organizationally sensitive hazard assessment and management. A high status empowers the team
to conduct its mission with sufficient visibility and importance. By endorsing these requisites, CST
applicants and operators will indicate they are attentive to the safety aspects of their project or mission.
Software Safety Team
Safety planning also calls for creating a software safety team. Team size and shape depends
commensurately on mission size and importance. To be effective, the team should consist of analytical
individuals with a sufficient system engineering background. Military Standard (MIL STD) 882C
provides a comprehensive matrix of minimum qualifications for key system safety personnel. It can apply
to software system safety as well, provided professional backgrounds include sufficient experience with
software development (software requirements, design, coding, testing, etc.)
Several typical activities expected of the team range from identifying software-based hazards to tracing
safety requirements and limitations in the actual code, to developing software safety test plans and
reviewing test results for their compliance with safety requirements.
Software Safety During Life Cycle Phases
The SSSP should support a structured program life cycle model that incorporates both the system design
and engineering, and software acquisition process. Prominent software life cycle models include the
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
13 -
18
waterfall and spiral methodologies. Although different models may carry different lifecycle emphasis, the
adopted model should not affect the SSSP itself. For discussion purposes only, this enclosure adopts a
waterfall model (subject to IEEE/IEA Standard for Information Technology-software life cycle processes
No. 12207.) For brevity, only some phases (development, operation, maintenance and support) of the
Standard are addressed in terms of their relationship to software safety activities. This relationship is
summarized in Table 13-2 The table’s contents partly reflect some of the guidance offered by the National
Aeronautics and Space Administration (NASA) Standard 8719.13A and NASA Guidebook GB-1740.13-
96.
FAA System Safety Handbook, Chapter 13: Launch Safety
December 30, 2000
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册上(39)
