DO-178C Guide: Introduction to RTCA DO-178 Certification
Glossary
Table of Contents
|
Acronyms
|
Terms
|
Definition
|
|---|---|---|
|
CC
|
Code Coverage
|
A measure of the extent to which the source code of a software system has been tested through the execution of specific test cases.
|
|
CSCI
|
Computer Software Configuration Item
|
A collection of software items that are designed to be developed, tested, and delivered as a single entity.
|
|
DAL
|
Design Assurance Level
|
A classification used in DO-178C to categorize software items based on their criticality to the overall system safety.
|
|
DCL
|
Data Coupling Level
|
A measure of the degree of interdependence between two software modules or components based on the data exchanged between them.
|
|
DO-178C
|
Software Considerations in Airborne Systems and Equipment Certification
|
A standard published by RTCA, Inc. provides guidance for the development and certification of software in airborne systems.
|
|
FAA
|
Federal Aviation Administration
|
A regulatory body in the United States is responsible for the regulation and oversight of civil aviation within the country.
|
|
FMEA
|
Failure Modes and Effects Analysis
|
A systematic technique used to identify and analyze potential failure modes of a system, component, or process, and their effects.
|
|
HLR
|
High-Level Requirements
|
Broad statements of what the software system is expected to accomplish, typically specified at the beginning of the development process.
|
|
IMA
|
Integrated Modular Avionics
|
A system architecture approach that integrates multiple avionics functions into a common hardware platform to reduce weight, size, and power requirements.
|
|
LP
|
Low-Level Requirements
|
Detailed statements that specify the behavior and functionality of individual software components, derived from high-level requirements.
|
|
MCDC
|
Modified Condition/Decision Coverage
|
A structural testing criterion that requires each condition in a decision statement to be tested independently, resulting in the evaluation of all possible outcomes.
|
|
MTTR
|
Mean Time To Repair
|
The average time required to repair a failed software system or component and restore it to its normal operating state.
|
|
OOT
|
Object-Oriented Technology
|
A software development approach that emphasizes the use of objects, classes, and inheritance to design and implement software systems.
|
|
PDR
|
Preliminary Design Review
|
A formal review conducted to evaluate the initial design of a software system or component, typically performed before the detailed design phase.
|
|
PPS
|
Process Performance Standard
|
A predefined set of metrics and criteria used to assess the performance and effectiveness of software development processes.
|
|
QA
|
Quality Assurance
|
A set of activities and processes aimed at ensuring that software products and systems meet specified requirements and quality standards.
|
|
RCS
|
Requirements Change Summary
|
A document that captures and tracks changes made to the software system requirements throughout the development process.
|
|
RTCA
|
Radio Technical Commission for Aeronautics
|
An organization that develops consensus-based recommendations and standards for the aviation industry.
|
|
SCMP
|
Software Configuration Management Plan
|
A document that defines the procedures and tools to be used for managing and controlling the software configuration items throughout the development lifecycle.
|
|
SCSC
|
Software Criticality and Safety Classification
|
The process of assigning design assurance levels (DALs) and safety classifications to software items based on their impact on system safety.
|
|
SQA
|
Software Quality Assurance
|
The systematic monitoring and evaluation of the various software development processes to ensure compliance with predefined quality standards.
|
|
SSD
|
Software Safety Data
|
A collection of artifacts and evidence used to demonstrate compliance with the software safety objectives and requirements.
|
|
SSC
|
Software Safety Case
|
A document that presents a structured argument supported by evidence to demonstrate that the software system meets the specified safety objectives.
|
|
STP
|
Software Test Plan
|
A document that outlines the approach, scope, objectives, and schedule for testing the software system or components.
|
|
SV
|
Structural Coverage
|
A measure of the extent to which the structure of a software system, such as statements, decisions, and conditions, has been exercised during testing.
|
|
TLD
|
Top-Level Design
|
A high-level architectural design of a software system that provides an overview of its structure, components, and interfaces.
|
|
TTCN-3
|
Testing and Test Control Notation Version 3
|
A standardized testing language used for defining and executing test cases for software systems.
|
|
V&V
|
Verification and Validation
|
The process of evaluating and verifying that a software system or component meets the specified requirements and performs as intended.
|
|
VSCS
|
Version and Source Control System
|
A software tool or system used for managing and controlling versions of software source code and related artifacts.
|
Don’t forget to share this post!
