Major change program
Airborne software lifecycle data review for a major change
This review checks the DO-178C airborne software lifecycle data supporting a major change, confirming that the plans, standards, verification records, and accomplishment summary hold together at the assigned software level. A certification specialist reads the lifecycle data against the level the software carries, finding the objectives that the level requires but the data does not satisfy. The output separates data that matches the assigned level from data that describes a lower assurance effort than the level demands. You receive a gap assessment, an objective-coverage map, and a closure plan before the data supports the compliance claim.
When this review is needed
- The change raised the software level and the lifecycle data was built to the earlier, lower one.
- Software modified for the change reuses lifecycle data whose objective coverage no one has rechecked.
- Plans, standards, and verification records exist but their alignment to the assigned level is unconfirmed.
- The accomplishment summary claims the level's objectives met and the underlying data has to back that.
The problem
DO-178C objective coverage is keyed to the assigned software level, and a major change can raise that level without the lifecycle data following. Software reused or modified from a prior effort carries plans, standards, and verification depth suited to its original level, and when the change assigns a higher one, those artifacts describe less assurance than the new level requires. The data set looks complete because it is a full set; it is just a full set for a lower level.
What gets reviewed
- The assigned software level confirmed and the objective set it requires established
- Plans and standards checked for alignment to the assigned level, not a lower prior one
- Verification records read against the structural coverage the level demands
- The accomplishment summary reconciled with the objective evidence it claims
- Reused lifecycle data screened for whether its coverage suits the new level
- Problem reports and their disposition checked against the level's expectations
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- The plans and standards reflect the objectives of the assigned software level
- Verification records provide the structural coverage the level requires
- The accomplishment summary's claims resolve to real lifecycle evidence
- Reused artifacts meet the objective set of the new level rather than their original one
- Problem-report disposition is consistent with the assigned level's expectations
Evidence normally required
- The DO-178C plans, standards, and verification records for the software
- The assigned software level and the safety assessment that set it
- The software accomplishment summary
- The problem-report log
- The origin and level of any reused lifecycle data
Common discrepancies
- Verification records that meet a lower level's coverage than the one now assigned
- Reused plans and standards that were written for the software's original, lower level
- An accomplishment summary claim that no verification record supports
- Structural coverage analysis absent where the assigned level requires it
What is at stake
Lifecycle data that falls short of the assigned level leaves objectives unsatisfied, which an authority finds by mapping the data to the level's objective set and which forces additional structural coverage, testing, or reviews late in the program. Reused artifacts that were adequate at their original level become the specific gaps that hold up acceptance of the changed software.
How the work runs
Fix the level and objectives
Confirm the assigned software level from the safety assessment and establish the objective set it requires.
Read the data to the level
Check plans, standards, and verification records against the assigned level's objectives, not a prior one.
Screen the reused data
Identify reused artifacts whose coverage suits an earlier level and mark the shortfalls.
Close to the objectives
List the unsatisfied objectives and sequence the coverage, testing, and analysis to close them.
What the buyer receives
- A gap assessment naming the objectives the data does not satisfy at the assigned level
- An objective-coverage map tying each required objective to its lifecycle evidence
- A closure plan for the coverage and artifact gaps against the level
Who uses the output
- Certification leadership confirming the software data holds at the assigned level
- Engineering leadership sourcing the additional coverage the level requires
- Compliance managers tracking the objectives still short of the assigned level
How the work fits into the transaction or program
The software data review runs once the software level is fixed by the safety assessment and the lifecycle artifacts exist, because objective coverage can only be judged against a settled level. Finding a coverage gap here means adding testing or analysis on plan; finding it at review means a level-related finding against software the program treated as done.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review confirms the software lifecycle data is complete and consistent for the assigned level. It does not assign the software level, approve the software, or make any compliance or airworthiness finding.
What this review does not cover
- Producing the additional verification the assigned level requires
- Assigning or changing the software level
- Any compliance or airworthiness determination on the software
Specific to this review
- DO-178C objective coverage is level-keyed, so a complete data set for a lower level is an incomplete one the moment the change raises the assigned level.
- Reused software artifacts carry the assurance of their original level, which is exactly the assurance the new level renders insufficient.
- Structural coverage analysis is the objective most often missing when data built for a lower level is carried into a higher one.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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.
Frequently asked questions
The software already has a complete DO-178C data set. Why review it for the change?
Completeness is judged against a software level. If the change raised the level, a data set that was complete before now falls short of the objectives the higher level requires, and reused artifacts carry the lower level's assurance. The review maps the data to the level actually assigned.
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.