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

include the waterfall and spiral methodologies. Although different models may carry different lifecycle
emphasis, the adopted model should not affect the safety process 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 the development phase of the Standard is addressed in terms
of the relationship to software safety activities.
J.1 Safety Critical Software Development
A structured development environment and an organization using state-of-the-art methods are prerequisites
to developing dependable safety critical software. The following requirements and guidelines are intended to
carry out the cardinal safety rule and its corollary that no single event or action shall be allowed to initiate a
potentially hazardous event. The system, upon detection of an unsafe condition or command, shall inhibit the
potentially hazardous event sequence and originate procedures/functions to bring the system to a predetermined
“safe” state.
The purpose of this section is to describe the software safety activities that should be incorporated into the
software development phases of project development. The software safety information that should be included
in the documents produced during these phases is also discussed. The term "software components" is used in a
general sense to represent important software development products such as software requirements, software
designs, software code or program sets, software tests, etc.
J.2 Software Concept and Initiation Phase
For most projects this lifecycle phase involves system level requirements and design development. Although
most project work during this phase is concentrated on the subsystem level, software development has
several tasks that must be initiated. These include the creation of important software documents and plans
that will determine how, what, and when important software products will be produced or activities will be
conducted. Each of the following documents should address software safety issues:
Document Software Safety Section
System Safety Plan Include software as a subsystem. Identify tasks.
Software Concepts Document Identify safety critical processes.
Software Management Plan, and Software
Configuration Management Plan
Coordination with systems safety tasks,
flowdown incorporation of safety requirements.
Applicability to safety critical software.
Software Security Plan Security of safety critical software
Software Quality Assurance Plan Support to software safety, verification of
software safety requirements, safety
participation in software reviews and
inspections.
J.3 Software Requirements Phase
The cost of correcting software faults and errors escalates dramatically as the development life cycle
progresses, making it important to correct errors and implement correct software requirements from the very
beginning. Unfortunately, it is generally impossible to eliminate all errors. Software developers must
therefore work toward two goals: developing complete and correct requirements, and correcting code to
develop fault-tolerant designs that will detect and compensate for software faults. The second goal is
required because the first is usually impossible to accomplish.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-3
This section of the handbook describes the software safety team involvement in developing safety
requirements for software. The software safety requirements can be top-down (flowed down from system
requirements) and/or bottom-up (derived from hazard analyses). In some organizations, top-down flow is
the only permitted route for requirements into software, and in those cases, newly derived bottom-up safety
requirements must be flowed back into the system specification.
The requirements of software components are typically expressed as functions with corresponding inputs,
processes, and outputs, plus additional requirements on interfaces, limits, ranges, precision, accuracy, and
performance. There may also be requirements on the data of the program set - its attributes, relationships,
and persistence, among others.
Software safety requirements are derived from the system and subsystem safety requirements developed to
mitigate hazards identified in the Preliminary, System, and Subsystems Hazard Analyses.
Also, the assigned safety engineer flows requirements to systems engineering. The systems engineering
group and the software development group have a responsibility to coordinate and negotiate requirement
flowdown to be consistent with the software safety requirement flowdown.
　
中國航空網(wǎng) m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：System Safety Handbook系統(tǒng)安全手冊下(126)