曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
J.6.3 Code Interface Analysis
Code interface analysis verifies the compatibility of internal and external interfaces of a software component.
A software component is composed of a number of code segments working together to perform required
tasks. These code segments must communicate with each other, with hardware, other software components,
and human operators to accomplish their tasks. Check that parameters are properly passed across interfaces.
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-23
Each of these interfaces is a source of potential problems. Code interface analysis is intended to verify that
the interfaces have been implemented properly. Hardware and human operator interfaces should be made
part of the “Design Constraint Analysis” discussed below.
J.6.4 Measurement of Complexity
As a goal, software complexity should be minimized to reduce likelihood of errors. Complex software also
is more likely to be unstable, or suffer from unpredictable behavior. Modularity is a useful technique to
reduce complexity. Complexity can be measured via McCabe’s metrics and similar techniques.
J.6.5 Update Design Constraint Analysis
The criteria for design constraint analysis applied to the detailed design can be updated using the final code.
At the code phase, real testing can be performed to characterize the actual software behavior and
performance in addition to analysis.
The physical limitations of the processing hardware platform should be addressed. Timing, sizing and
throughput analyses should also be repeated as part of this process to ensure that computing resources and
memory available are adequate for safety critical functions and processes.
Underflows/overflows in certain languages (e.g., ADA) give rise to “exceptions” or error messages generated
by the software. These conditions should be eliminated by design if possible; if they cannot be precluded,
then error handling routines in the application must provide appropriate responses, such as retry, restart, etc.
J.6.6 Code Inspection Checklists (including coding standards)
Coding standards are based on style guides and safe subsets of programming languages. Checklists should
be developed during formal inspections to facilitate inspection of the code to demonstrate conformance to the
coding standards.
Fagan Formal Inspections (FIs)
FIs are one of the best methodologies available to evaluate the quality of code modules and program sets. Many
projects do not schedule any formal project-level software reviews during coding. When software is ready to be
passed on to subsystems for integration, projects may elect to conduct an Integration Readiness Review when
audit or inspection reports and problem reports may be evaluated. Other than these reports, the only formal
documentation usually produced are the source code listings from configuration management.
J.6.7 Formal Methods
Generation of code is the ultimate output of Formal Methods. In a "pure" Formal Methods system, analysis
of code is not required. In practice, however, attempts are often made to "apply" Formal Methods to
existing code after the fact. In this case the analysis techniques of the previous sections (0 through 0) may be
used to "extract" the logic of the code, and then compare the logic to the formal requirements expressions
from the Formal Methods.
J.6.8 Unused Code Analysis
A common real world coding error is generation of code that is logically excluded from execution; that is,
preconditions for the execution of this code will never be satisfied. Such code is undesirable for three
reasons; a) it is potentially symptomatic of a major error in implementing the software design; b) it
introduces unnecessary complexity and occupies memory or mass storage which is often a limited resource;
and c) the unused code might contain routines which would be hazardous if they were inadvertently executed
(e.g., by a hardware failure or by a Single Event Upset. SEU is a state transition caused by a high-speed
subatomic particle passing through a semiconductor - common in nuclear or space environments).
FAA System Safety Handbook, Appendix J: Software Safety
December 30, 2000
J-24
There is no particular technique for identifying unused code; however, unused code is often identified during
the course of performing other types of code analysis. Unused code can be found during unit testing with
COTS coverage analyzer tools.
Care should be taken during logical code analyses to ensure that every part of the code is eventually
exercised at some time during all possible operating modes of the system.
J.7 Test Phase
Two sets of analyses should be performed during the testing phase: analyses before the fact to ensure validity
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
System Safety Handbook系统安全手册下(141)
