Why DO-178C Costs More When Compliance Starts Late

DO-178C compliance is most efficient when assurance activities and evidence are built into software development—not reconstructed after the software is complete. When teams write code first and assemble certification data later, they may have to recover requirements, rebuild traceability, repeat verification under controlled conditions, and revisit design decisions. Under schedule pressure, that avoidable rework can become one of the program’s largest costs.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed July 2026.

There is a story that plays out repeatedly at small aerospace companies, and it usually begins with good news.

The prototype works. The demonstration went well. A customer—perhaps an airframer or systems integrator—is interested. Then comes the question that changes everything:

“What is your certification plan?”

For many teams, that is when DO-178C first becomes real—after key architecture, code, and test decisions have already been made.

What DO-178C Actually Requires

DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, is an industry consensus standard recognized by the FAA and other civil aviation authorities as an acceptable means of compliance for airborne software.

Its purpose is not to prescribe a programming language, coding style, or development methodology. Instead, DO-178C defines objectives for planning, software development, verification, configuration management, quality assurance, and certification liaison. The applicable objectives and level of rigor depend in part on the software level derived from the system safety assessment.

A Designated Engineering Representative (DER)—an individual authorized by the FAA to make certain findings of compliance on its behalf—may be among those reviewing the resulting life-cycle data.

Here is what often surprises newcomers: DO-178C says relatively little about how to write code. It focuses on what a program must be able to demonstrate about the way its software was planned, developed, verified, controlled, and documented.

The objectives are published. The process is not a secret.

But the framework works best when the software and its compliance evidence are developed together:

• Planning defines how the work will be performed and how compliance will be shown.
• Requirements are defined, reviewed, controlled, and linked to the software that implements them.
• Reviews and tests are traced to the requirements they verify.
• Results, baselines, problem reports, and approvals are retained under configuration control.

DO-178C does not require a waterfall development model. It does, however, require a disciplined and documented life cycle in which the required evidence can be reproduced and reviewed.

That is where a “move fast” prototype often diverges from certifiable software development.

Why Retrofitting Compliance Costs So Much

When the software already exists but the supporting life-cycle data does not, activities that should have occurred naturally during development may have to be performed in reverse.

Requirements must be recovered and validated

Instead of implementing approved requirements, the team must inspect the existing code and attempt to describe what it does.

That creates an immediate risk: a reverse-engineered requirement may merely restate the implementation rather than define the intended behavior, constraints, interfaces, and safety-related expectations. Each undocumented assumption becomes a decision that must be identified, evaluated, and justified.

Traceability must be rebuilt

The relationships among system requirements, software requirements, design, source code, verification cases, and verification results must be established.

Those relationships are relatively inexpensive to maintain while the work is being performed. Reconstructing them months or years later can require interviews, code analysis, document reviews, test analysis, and engineering judgment—often involving people who no longer remember why a decision was made or who are no longer with the company.

Verification may have to be repeated or expanded

Informal testing may have significant engineering value, but it may not be usable as certification evidence if the program cannot establish:

• The software version that was tested
• The test environment and configuration
• The test procedure and expected results
• The actual results and pass/fail criteria
• The review and approval status of the test data
• The relationship between each test and the requirement it verifies

In those cases, tests may need to be rewritten, reviewed, repeated, and documented against a controlled software baseline. Additional verification may also be necessary to satisfy requirements-based testing, robustness testing, structural coverage, independence, or other applicable objectives.

Design and implementation assumptions must be revisited

Decisions that were reasonable for a prototype may require additional controls, analysis, verification, or redesign before they are suitable for airborne software.

Examples include shared global data, undocumented timing assumptions, platform-specific behavior, implicit interface dependencies, incomplete error handling, or reliance on tools and libraries that were never evaluated in the certification context.

Late changes rarely remain isolated. A design change can affect requirements, source code, tests, traceability, coverage analysis, configuration records, and certification data.

Retrospective compliance work can uncover genuine defects and improve safety; it is not merely paperwork. But when the required evidence was not produced as part of the original life cycle, a substantial portion of the effort becomes avoidable rework.

That rework occurs on a product the team believed was nearly finished—often under schedule pressure, with a customer waiting. This is why “we will address compliance later” can become one of the most expensive decisions in the program.

Discipline Early Prevents Delay Later

Teams that reach certification with fewer surprises are not necessarily the teams with the largest budgets. They are usually the teams that treat assurance objectives as part of engineering from the beginning.

Understand the objectives before committing to flight software

The team does not need every answer before development begins. It does need to understand the likely software level, applicable objectives, expected life-cycle data, certification interfaces, and areas that could drive architecture or tool decisions.

Early coordination with the responsible certification authority or authorized representative can prevent major differences in interpretation later.

Create the plans early—and keep them aligned with the work

The Plan for Software Aspects of Certification, or PSAC, and its companion software plans describe how the program intends to satisfy the applicable objectives.

These plans should not become shelfware. The team must perform the work consistently with them. When the development or verification approach changes, the plans should be revised through a controlled process and coordinated as appropriate.

A mismatch between documented plans and actual practices can result in findings even when the underlying engineering approach is otherwise reasonable.

Maintain requirements and traceability continuously

Requirements should be reviewed, controlled, and linked to the design, code, and verification evidence throughout development.

Prototypes may help a team discover requirements, but certifiable software should not depend on undocumented behavior that can only be understood by reading the source code.

Capture evidence when the work is performed

Review records, analyses, test procedures, test results, traceability data, problem reports, and approvals are far less expensive to capture during the activity than to reconstruct later.

Contemporaneous evidence is also more reliable. It records what was reviewed, by whom, against which baseline, and with what result.

Establish configuration management early

The program should always be able to answer fundamental questions:

• Which version was reviewed?
• Which version was tested?
• Which requirements and test procedures applied to that version?
• Which problems were open or closed at the time?
• What changed between baselines?

Configuration management provides those answers. It also prevents teams from building certification conclusions on uncontrolled or mismatched data.

This discipline does not mean every artifact must be perfect before coding begins. Nor does it prohibit iterative or agile development. It means each iteration occurs within a defined, controlled, and reviewable life cycle.

Discipline beats heroics. When compliance activities are integrated into engineering, certification is no longer a wall at the end of the program. It becomes part of how the product was developed.

See What the Process Entails—Free

AeroCert publishes the Open Compliance Library: seven plain-language DO-178B/C checklists containing 88 checkpoints across:

• Software planning
• Requirements
• Design and source code
• Verification
• Configuration management
• Tool qualification
• The life cycle from the PSAC through the Software Accomplishment Summary, or SAS

The checklists provide a practical, high-level assessment of certification readiness. Teams can use them to identify questions and potential gaps before flight-software architecture, development processes, and delivery schedules are locked in.

They are free to use and share under the Creative Commons Attribution 4.0 license as part of AeroCert’s nonprofit mission to advance aviation safety for the public benefit.

Get the checklists at aerocert.org or access the library directly on GitHub.

Important Notice

AeroCert’s checklists are educational and compliance-support resources. They are not FAA-approved compliance data, do not replace DO-178C or applicable regulatory guidance, and do not guarantee a certification outcome.

The FAA does not issue a stand-alone DO-178C certificate for software. Software life-cycle data is evaluated as part of the applicable aircraft, product, or installation approval. Program-specific expectations depend on the certification basis, system safety assessment, software level, proposed means of compliance, approved plans, and coordination with the responsible certification authority or designee.