Software lifecycle data
DO-178C software lifecycle data evidence review
A DO-178C data evidence review confirms that a software lifecycle data package delivers the objectives its assigned software level requires and that the records support what the accomplishment summary claims. It is run by a hardware assurance team before submittal, a finding response, or a change that affects the software. The review checks the plans, standards, and verification records against the software level, then compares the accomplishment summary to the evidence actually on hand. You receive a gap list keyed to the objectives, an evidence map from objective to record, and a closure sequence for the assurance lead.
When this review is needed
- A software data package is heading to submittal and the objectives have to be shown as met for the assigned level.
- The software level was raised after a safety assessment and the existing data may not reach the new objectives.
- An authority finding questioned whether specific verification objectives were satisfied by the records on file.
- A software change reopened lifecycle data and the affected objectives need to be re-evidenced.
The problem
A DO-178C package can look complete because every expected document is present, while the objectives behind those documents are only partly met. Structural coverage falls short at the assigned level, a plan commits to an activity the records do not show, or the accomplishment summary asserts closure the verification results do not back. These gaps hide behind a full table of contents and surface when an authority reads to the objective rather than the document title.
What gets reviewed
- Plans and standards checked against the objectives the assigned software level requires
- Verification records reconciled to the review, analysis, and test objectives they are meant to satisfy
- Structural coverage evidence checked against the coverage the software level demands
- The accomplishment summary compared line by line to the evidence on hand
- Traceability from requirements through design and code to verification confirmed
- Parameter data and configuration items checked for the data the level requires
What gets validated
- The objectives for the assigned software level are each addressed by a record, not just a plan commitment
- Structural coverage results meet the coverage the software level requires with justified exceptions where allowed
- The accomplishment summary's closure claims are each backed by a retrievable verification result
- Traceability holds from requirements through design and code to the verifying record
- Deactivated or dead code is identified and handled as the objectives require
Evidence normally required
- The software plans, standards, and the assigned software level
- Verification records including review, analysis, and test results
- Structural coverage analysis results
- The software accomplishment summary and configuration index
- The safety assessment output that sets the software level
Common discrepancies
- Structural coverage that falls short of the assigned level with no justified exception
- A plan that commits to an activity the verification records do not show as done
- An accomplishment summary closure claim the evidence does not support
- A trace break between design and the code that implements it
What is at stake
Objectives that are not actually met invite a finding that reopens the software data late in the program, when rework is most expensive. If the accomplishment summary overstates what the evidence supports, the credibility of the package drops and the review widens beyond the single objective that was questioned.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the objective set
Establish the DO-178C objectives the assigned software level requires for this package.
Map records to objectives
Tie each verification and analysis record to the objective it is meant to satisfy.
Test the summary
Compare the accomplishment summary's closure claims against the evidence actually on hand.
Sequence the gaps
List the unmet objectives and order the work to close them before submittal.
What the buyer receives
- A gap list keyed to the objectives not yet met for the software level
- An evidence map linking each objective to the record that satisfies it
- A closure sequence ordering the open objectives by dependency and effort
Who uses the output
- Assurance leads confirming the objectives are met before they sign the summary
- Certification leads answering a finding on a specific verification objective
- Engineering owners re-evidencing objectives a software change reopened
How the work fits into the transaction or program
The review takes the lifecycle data after the team believes it is complete and checks it against the objectives before the accomplishment summary is relied on. Its gap list drives the verification that still has to finish, and its evidence map becomes the reference the summary and any finding response cite.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-178C, and the objectives are common, but each authority can attach its own expectations to how certain objectives are evidenced and how the summary is presented. The review notes where a package meets one authority's presentation expectation and where the other would ask for the evidence to be laid out differently.
Regulatory limits
The review checks the lifecycle data against the objectives for its assigned level. It does not perform software verification, assign or approve the software level, or make a compliance determination on the authority's behalf.
What this review does not cover
- Performing software verification, analysis, or coverage runs
- Assigning or approving the software level
- Determining that the software complies for certification
Specific to this review
- A complete document set is not the same as met objectives, and the gap between them is exactly what an objective-level read exposes.
- Structural coverage is the objective most often short of the assigned level, because the last percent of coverage is the hardest to close.
- When the software level is raised after a safety assessment, existing data almost never reaches the new objectives without added verification.
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
Do you check the code, or only the data package?
The review works from the lifecycle data, the verification records, and the coverage results the team produced. It confirms those objects satisfy the objectives for the assigned level; it does not re-verify the source code itself.
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.