DO-178B/ED-12B认证指南：验证独立性解读
需积分: 9 109 浏览量
更新于2024-09-09
收藏 143KB PDF 举报
DO-178B CAST-26 验证独立性指南
DO-178B CAST-26 是一份关于软件验证独立性的_position_paper，由Certification Authorities Software Team (CAST)发布。该文档旨在阐述DO-178B/ED-12B指导方针中关于验证独立性的概念和要求。
DO-178B 是一份广泛应用于航空电子系统的软件开发指导方针，旨在确保航空电子系统的安全性和可靠性。其中，验证独立性是DO-178B 中的一个关键概念，指的是在软件开发过程中，验证活动的独立性和客观性。
CAST-26 文档的目的是为了澄清关于验证独立性的概念和要求，避免在实际项目中出现误解和错误。该文档强调，验证独立性是指验证活动的独立性和客观性，而不是指验证结果的独立性。
文档中还强调，验证独立性是DO-178B/ED-12B指导方针的核心要求之一。该要求旨在确保软件开发过程中的验证活动是独立的、客观的和公平的，以确保软件产品的安全性和可靠性。
此外，CAST-26 文档还提出了关于验证独立性的几个关键问题，例如：
* 什么是验证独立性？
* 验证独立性是如何实现的？
* 验证独立性对软件开发过程的影响是什么？
这些问题的答案将有助于软件开发者更好地理解DO-178B/ED-12B指导方针中的验证独立性概念，并正确地实现验证独立性要求。
DO-178B CAST-26 验证独立性指南是一份非常重要的文档，对于软件开发者和航空电子系统的安全性和可靠性具有重要影响。
关键词：DO-178B、CAST-26、验证独立性、软件开发、航空电子系统、安全性、可靠性。
DO-178B CAST-26 验证独立性指南是Certification Authorities Software Team (CAST)发布的一份关于软件验证独立性的_position_paper，旨在澄清关于验证独立性的概念和要求，避免在实际项目中出现误解和错误。
NOTE: This position paper has been coordinated among the software specialists of
certification authorities from North and South America, and Europe. However, it does not
constitute official policy or guidance from any of the authorities. This document is provided
for educational and informational purposes only and should be discussed with the
appropriate certification authority when considering for actual projects.
2
Table Reference Summary Level(s)
6.4.3
A-6 6.4.2.2,
6.4.3
“Executable object code is robust with low-level
requirements.”
A
A-7 6.3.6b
“Test procedures are correct.”
A
A-7 6.3.6c
“Test results are correct and discrepancies explained.”
A
A-7 6.4.4.1
“Test coverage of high-level requirements is achieved.”
A
A-7 6.4.4.1
“Test coverage of low-level requirements is achieved.”
A
A-7 6.4.4.2
“Test coverage of software structure (modified
condition/decision) is achieved.”
A
A-7 6.4.4.2a, b
“Test coverage of software structure (decision) is
achieved.”
A and B
A-7 6.4.4.2a, b
“Test coverage of software structure (statement
coverage) is achieved.”
A and B
A-7 6.4.4.2c
“Test coverage of software structure (data coupling and
control coupling) is achieved.”
A and B
Note: The text for each objective in the DO-178B/ED-12B Annex A tables is a
summarized form of the actual objective’s wording, and the referenced
sections should be read for the full text of each objective.
Furthermore, in Annex B, the DO-178B/ED-12B glossary, a definition of
independence is provided which states:
“Independence – Separation of responsibilities which ensures the
accomplishment of objective evaluation. (1) For software verification process
activities, independence is achieved when the verification activity is
performed by a person(s) other than the developer of the item being verified,
and a tool(s) may be used to achieve an equivalence to the human verification
activity. …”
Typically, compliance with the referenced objectives is achieved with the use of
humans manually reviewing the subject data, using a standard and/or checklist,
and is a very labor intensive activity. The results of these reviews are usually
captured by completing review checklists, keeping review notes of errors or
deficiencies found or questions, marking (red-lining) the data noting corrections
to be made, or other means; and then ensuring that corrections are implemented in
a subsequent version of the data artifact, using either a formal problem reporting
and resolution process, or an informal actions listing. Software quality assurance
(SQA) personnel usually attend at least some of these reviews to ensure that the
engineers are applying the relevant plans, standards, checklists, etc. Other terms
used for review include inspection, evaluation, walkthrough, audit, etc.
More recently, applicants have proposed to use tools to attempt to automate
certain aspects of these reviews or enforce their criteria. Probably the most
common tools proposed are “structural coverage” analysis tools which make
剩余11页未读，继续阅读
2018-12-29 上传
2018-12-27 上传
2018-12-27 上传
2018-12-27 上传
2018-12-29 上传
2018-12-29 上传
2018-12-29 上传
2018-12-27 上传
2018-12-27 上传
