Software lifecycle evidence
Airborne software lifecycle evidence review under DO-178C
A software lifecycle evidence review checks whether an article's DO-178C lifecycle data is consistent with its assigned software level and whether the objectives for that level are actually satisfied by the data on hand. It is for avionics and equipment suppliers preparing software evidence or recovering a program that drifted. The review reads the plans, the high- and low-level requirements, the design and code artifacts, the verification results, and the structural-coverage data, then checks each against the objectives DO-178C sets for the level. You receive an objective-by-objective status and a list of objectives with missing, partial, or inconsistent evidence.
When this review is needed
- A stage-of-involvement review is approaching and the lifecycle data needs a read before the authority sees it.
- A software level was raised and the existing data must be checked against the heavier objective set.
- Reused or COTS software is carried into the program and its assurance credit has to be substantiated.
- The development drifted from the plans and the data no longer follows the lifecycle the PSAC promised.
The problem
DO-178C assurance is carried in a chain of artifacts, from plans through requirements, design, code, and verification, and each link has to satisfy specific objectives for the software level. In practice the plans describe one process while the artifacts reflect another, low-level requirements trace upward but not down to the tests, and structural coverage is reported without the analysis that resolves the gaps. The data looks substantial yet leaves objectives unmet.
What gets reviewed
- The PSAC, SDP, SVP, SCMP, and SQAP and whether the artifacts follow them
- High-level and low-level software requirements and their bidirectional trace
- Design data and source code against the requirements they implement
- Verification cases, procedures, and results for the assigned software level
- Coverage analysis at the structural level and the resolution of uncovered code
- Reused, COTS, or previously developed software and its certification credit
What gets validated
- The lifecycle data set matches the objectives DO-178C assigns to the software level
- High-level requirements trace to low-level requirements and on to verification
- Verification results exist for every requirement marked as verified
- Coverage at the structural level matches the level and uncovered code carries an analysis
- Derived requirements are identified and provided to the safety assessment
- The artifacts follow the lifecycle the plans defined, including transition criteria
- Problem reports are tracked and their closure is reflected in the verification status
Evidence normally required
- The software plans (PSAC, SDP, SVP, SCMP, SQAP)
- The software requirements data and the trace data
- Design data, source code, and the verification results
- Structural coverage results and any coverage analysis
- Reuse or COTS substantiation and prior certification credit claimed
Common discrepancies
- Low-level requirements that trace up to high-level requirements but not down to tests
- Lifecycle data assembled for a lower level than the one now assigned
- Coverage at the structural level reported with uncovered code left unresolved
- Derived requirements not passed to the safety assessment
- Test results that postdate code the team has since changed
- Reused software credited without substantiation against the current objectives
What is at stake
An objective left unsatisfied at a stage-of-involvement review turns into an action item that holds the stage open, and the rework lands on the critical path. A coverage gap discovered late can force a new test campaign on frozen code. When the data does not match the assigned level, the team rebuilds evidence under schedule pressure rather than during planned development.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the level and plans
Establish the assigned software level and the objective set, and confirm the plans the artifacts are meant to follow.
Trace the lifecycle
Follow requirements through design, code, and verification, checking the bidirectional trace at each step.
Test the evidence
Check verification results and structural coverage against the objectives and resolve uncovered code.
Report by objective
Produce an objective-by-objective status and a closure list ordered by stage-of-involvement risk.
What the buyer receives
Who uses the output
- Certification leads preparing for a stage-of-involvement review
- Software engineering and verification teams closing objective gaps
- Software quality assurance confirming the lifecycle follows the plans
How the work fits into the transaction or program
The review goes deeper than a compliance matrix into the software discipline of a certification data set. It connects to the safety assessment through derived requirements and to a systems-development review where software requirements originate.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements reviews the applicant's software lifecycle data for objective coverage and consistency. It does not act as the certification authority or its designee, make compliance findings, or guarantee that the software data will be accepted.
What this review does not cover
- Acting as the authority or a designee at a stage-of-involvement review
- Issuing any compliance finding or software approval
- Writing the missing requirements, code, or verification evidence
Specific to this review
- DO-178C states objectives by software level rather than a single fixed checklist, so the same artifact can satisfy a lower level and fall short of a higher one, which is why level alignment is checked first.
- Structural coverage is an objective in its own right at the higher levels, and uncovered code requires an analysis rather than a simple report, a distinction that separates a coverage number from coverage evidence.
- Derived requirements are software requirements with no parent, and DO-178C expects them fed to the safety assessment, so their absence from that assessment is a recurring lifecycle gap.
- Verification results are only valid against the code and requirements baseline they were run on, so results that predate later changes no longer substantiate the current build.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Do you assess reused or COTS software?
Yes. The review checks whether the certification credit claimed for reused or COTS software is substantiated against the objectives for the current software level, rather than assumed from a prior program.
Is this the same as a stage-of-involvement review by the authority?
No. This is an applicant-side read of the lifecycle data so gaps are found before a stage-of-involvement review. The authority and its designees conduct the official reviews.
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.
Walk through your situation with an engineer who has done this work.