Airborne software lifecycle data
DO-178C software lifecycle data evidence review for quality teams
This review reads a DO-178C software lifecycle data set to confirm it satisfies the objectives its assigned software level demands, not the level someone assumed. A certification specialist checks the plans, software standards, verification records, and accomplishment summary against the design assurance level with your quality function, and finds where the data delivered falls short of what the level requires. It runs before submittal, during a finding response, or when a change alters the software level or reopens verified objectives. You receive a gap list, a map from each objective to its evidence, and a closure sequence for quality leadership.
When this review is needed
- A software data set is heading to submittal and quality wants its objectives checked against the assigned level.
- A finding questions whether an objective was satisfied to the rigor the software level requires.
- A change raised or lowered the software level and the data has not caught up to the new objective set.
- The lifecycle data was produced across sub-teams and no one has read it against the level end to end.
The problem
DO-178C data is voluminous and structured, which makes it easy to mistake completeness for compliance. The plans exist, the reviews are logged, the accomplishment summary reads well, but the objective set for the assigned level is not fully covered because a coverage analysis was deferred, an independence requirement was overlooked, or a standard was written but never enforced. Quality holds a well-organized data set that satisfies a lower level than the one the software was assigned.
What gets reviewed
- The objective set for the assigned software level established as the yardstick the data is measured against
- Plans and software standards checked for existence and for actual enforcement in the lifecycle data
- Verification records checked for the coverage and independence the assigned level requires
- The accomplishment summary reconciled against the objectives it claims are satisfied
- Objectives sorted into satisfied, partially satisfied, and unmet for the assigned level
- Objectives affected by a level or design change checked for re-work against the current level
What gets validated
- Every objective the assigned software level requires is addressed by lifecycle data, with none scoped to a lesser level
- Independence requirements for verification at the assigned level are met, not assumed
- Structural coverage analysis appropriate to the level is present and reconciled to the verification results
- The software standards are not only written but demonstrably applied in the design and code data
- The accomplishment summary's claims each resolve to lifecycle data that supports them
Evidence normally required
- The software lifecycle data set: plans, standards, verification records, and accomplishment summary
- The system safety assessment output that assigns the software level
- The certification basis provisions the software compliance supports
- The software configuration index identifying the released data
- Change records for any objective or level altered since the data was compiled
Common discrepancies
- Structural coverage scoped for a lower level than the software was assigned
- A verification activity performed without the independence the assigned level requires
- A software standard written into the plans but not enforced in the code or design data
- An accomplishment summary asserting an objective satisfied by data that addresses only part of it
What is at stake
Data that meets a lower level than assigned fails the moment a reviewer checks objective coverage against the level. They ask for the structural coverage or the independent review the level requires, it was scoped for a lesser level, and the accomplishment summary that read finished has to be reopened. Raising the rigor of software data after the fact is among the most expensive rework in certification, because it can reach back into design and test.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the level and objectives
Confirm the assigned software level from the safety assessment and set its objective list as the yardstick.
Check coverage and independence
Confirm each objective is addressed with the coverage and independence the assigned level requires, not a lesser one.
Reconcile the summary
Match each claim in the accomplishment summary to lifecycle data that actually satisfies the objective.
Sequence the closures
Order the gaps so foundational objectives are closed before the ones whose evidence depends on them.
What the buyer receives
- A gap list naming each objective the data leaves unmet or under-satisfied for the assigned level
- An objective-to-evidence map tying each software level objective to the lifecycle data that meets it
- A closure sequence ordering the gaps so foundational objectives are closed before those that depend on them
Who uses the output
- Quality leadership deciding whether the software data package is ready to submit
- Software and verification engineers who need a concrete list of objectives to close or re-run
- The team preparing finding responses that must show an objective met at the assigned level
How the work fits into the transaction or program
DO-178C data is where the software half of the certification story is proven, and its rigor is fixed by the assigned level rather than by how thorough the data looks. This review runs before submittal, measuring the data against its level while there is still time to lift the rigor rather than after a reviewer finds the data was scoped short.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C as the software development assurance standard, and the objective sets by level are the same under each. The acceptance mechanism differs: FAA delegated findings against a project plan on one side, EASA review items and means-of-compliance acceptance on the other. The review reads the objective coverage against whichever finding path the program is filing under.
Regulatory limits
This review reads your own software lifecycle data and reports where it meets the assigned level and where it falls short. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the software data.
What this review does not cover
- Producing or re-running the software verification the gaps call for
- Authoring the missing lifecycle data or standards
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- A well-organized data set is easy to mistake for a compliant one, because DO-178C compliance is set by objective coverage at the assigned level, not by volume or tidiness.
- Independence requirements are a frequent quiet gap, since verification often gets done by whoever was available rather than by someone independent of the author.
- Structural coverage scoped for a lower level is a common finding, and correcting it can reach back into test and even design.
- A software standard that exists in the plans but is not enforced in the code satisfies the paperwork and fails the objective it was meant to meet.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Our accomplishment summary already states every objective is met. Why review the underlying data?
The accomplishment summary is a claim, not the evidence. This review opens the lifecycle data behind those claims and checks it against the objective set for the assigned level, including coverage and independence. Summaries routinely read complete over data that was scoped for a lower level or done without the required independence, which is exactly what a reviewer checks.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.