9.2 Backing Evidence of Freedom from Interference
To give confidence that the software safety requirements integrity is maintained arguments and backing evidence should be available that demonstrate:
a) The notations used in the analysis of interference are capable of supporting the identification and correction of all relevant interference mechanisms.
b) The analytic methods and techniques used are appropriate for identifying and analysing interference mechanisms.
c) The analysis notations are appropriate to the problem domain and representation and allow an adequate analysis of the design.
d) The analysis techniques have been applied by adequately qualified and experienced staff.
e) Assumptions used in the analysis (e.g. about the environment, hardware, operating system and other interfaces) have been validated.
f) Models or other abstractions used in the analysis are an adequate representation of the software design.
g) Procedures or tools have been used to ensure that interference is detected and corrected.
h) Any tools used to support the detection or correction of interference did not corrupt the results or the operational software.
i) Any tools used to detect or correct interference have been verified and validated to an appropriate level for the impact of the tool on the code and analysis.
10 Guidance on Credible Arguments and Evidence to Demonstrate Configuration Consistency Relating to Objective E
10.1 Direct Evidence of Configuration Consistency
Arguments and evidence should be available that show:
a) All those artefacts, which are offered as a source of direct or backing evidence are produced by the development of, or related to, the known executable version of the software.
NOTE: Evidence that is not created during the development process of the known executable version of the software can be related to it. In this case arguments for the validity of the relationship should be made available.
b) The evidence was collected from the processes and products to which it relates.
c) Evidence has not been altered without the alterations and their justification being made visible.
d) The evidence is unambiguously and consistently identified.
NOTE: Artefacts commonly offered as sources of Direct and Backing Evidence are: i) The object code; ii) The source code; iii) The requirements (System requirements, Software safety requirements, other
Software requirements) iv) Any data that has been used in conjunction with the known version of the
source code; v) All user manuals and other operating instructions for the software; vi) All test specifications, test scripts, test harness programs and test results; vii)Versions of all hardware used in the: generation of test data, stimulation of tests
and recording of test results; viii)Intermediate software design descriptions, either in natural language or formal
or semi-formal notations; ix) The results of hazard analysis undertaken on the system and software; x) Requirements traceability records (where these are kept separately from the
source code); xi) The results of manual inspections and static analyses of various kinds; xii)All safety arguments; xiii)Versions of the compilation system and any other development tools, including
the hardware upon which they operate.
10.2 Backing Evidence of Configuration Consistency
a) Arguments and evidence should be available that show:
i) Any tools used to support configuration consistency did not corrupt the configuration consistency structures.
中國航空網 m.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：CAP 670 Air Traffic Services Safety Requirements 1(80)
