Software lifecycle data
DO-178C software data evidence review for qualification test teams
A DO-178C software lifecycle data review checks that the plans, standards, verification records, and accomplishment summary a program delivers match the software level assigned to the function. It is run for a qualification test team before submittal, a finding response, or a change that touches the software argument. The reviewer confirms the objectives that apply at the assigned level are addressed by real records, and finds where the data claims a level the evidence does not support. You receive a gap list against the objective set, a data-to-objective map, and an order for closing what is short.
When this review is needed
- The software lifecycle data is about to be submitted and the objective set has not been checked against the level.
- A finding challenged whether the verification depth matches the assigned software level.
- The software level was raised after the plans were written and the data has to catch up.
- A change modified software already thought closed and the affected objectives have to be reworked.
The problem
The software argument is graded by level, and the level sets which objectives apply and how much independence they demand. Data assembled early against one level, then carried forward when the level changed, can present a complete-looking package that quietly under-serves the objectives now in force. The plans read fine, the records exist, and nothing announces that the verification depth or the structural coverage owed at the current level was never actually produced.
What gets reviewed
- The applicable objective set confirmed against the assigned software level
- Plans and standards checked for consistency with the level and with each other
- Verification records mapped to the objectives they are meant to satisfy
- Independence confirmed where the level requires it
- Structural coverage evidence checked against the level's expectation
- The accomplishment summary reconciled with the underlying lifecycle data
What gets validated
- The objective set addressed matches the objectives that apply at the assigned level
- Plans and software standards are consistent with the level and with the delivered data
- Verification records exist for each applicable objective, beyond the ones planned early
- Independence is demonstrated wherever the level requires it
- Structural coverage matches what the level expects, with justified gaps documented
Evidence normally required
- The plans, standards, and the software accomplishment summary
- Verification and review records for the software lifecycle
- The assigned software level and its basis
- The requirements and trace data the software is verified against
- The change record for software reopened since the last baseline
Common discrepancies
- An objective that applies at the assigned level with no record addressing it
- Verification performed without the independence the level requires
- Structural coverage short of the level's expectation with no justified gap
- An accomplishment summary that overstates what the lifecycle data shows
What is at stake
Objectives that are unmet at the assigned level are findings that can force additional verification, structural coverage analysis, or independence that was never planned, all late and all expensive. If the level was raised mid-program and the data never caught up, the gap can span the whole lifecycle rather than a single record. Reworking software evidence under submittal pressure is among the least forgiving corrections a program can face.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the objective set
Confirm which DO-178C objectives apply at the assigned level and require independence.
Map data to objectives
Trace each applicable objective to the plans, standards, and verification records meant to satisfy it.
Check depth and independence
Confirm structural coverage and independence match the level rather than the plan the data was started under.
Order the rework
Rank the unmet objectives by the verification effort each requires.
What the buyer receives
- A gap list against the objective set for the assigned level
- A data-to-objective map showing where evidence exists and where it is short
- A closure order ranking gaps by the rework each would trigger
Who uses the output
- Test leadership sizing the software verification still owed
- Certification leadership defending the objective set to an authority
- Engineering leads producing the coverage and independence evidence that is short
How the work fits into the transaction or program
The software argument is one of the deepest evidence stacks in the package, and it is graded entirely against the assigned level. This review confirms the data actually serves that level before the accomplishment summary is submitted, so an objective gap is found before the authority reads it. Its findings feed the compliance matrix line that credits the software function as closed.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
The FAA and EASA both recognize DO-178C, and its objective tables are common ground, but the two can differ on how they expect tool qualification and additional considerations to be substantiated. The review notes where software data acceptable to one authority would need extra substantiation for the other on a dual-validation program.
Regulatory limits
The review checks that the lifecycle data addresses the objectives for the assigned level and is internally consistent. It does not perform software verification, judge the correctness of a test, or determine that the software complies. Acceptance of the software argument rests with the authority.
What this review does not cover
- Performing software verification or coverage analysis
- Assigning or changing the software level
- Any compliance determination on the software
Specific to this review
- A software level raised mid-program is the classic trap: the data was built to a lower objective set and the plans rarely announce the shortfall.
- Independence and structural coverage are the objectives most often quietly unmet, because they are effort-heavy and easy to defer.
- The accomplishment summary can read complete while the lifecycle data beneath it does not support every objective it claims.
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
The accomplishment summary says every objective is satisfied. Isn't that enough?
The summary is a claim; this review checks it against the lifecycle data underneath. An objective can be listed as satisfied while the independence or structural coverage the level requires was never produced. Catching that before submittal is far cheaper than answering it as a finding.
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.