Four things people believe about DO-178C that cost them a year

We are usually brought into a first DAL-A programme somewhere around month fourteen, when the team has realised something is wrong but not yet what. These four beliefs account for most of it.

1. "We will generate the traceability before the review"

This is the expensive one. Traceability is not a document you produce, it is a property the artefacts either have or do not. Reconstructing it after the fact means going back through code written a year ago and deciding which requirement each part of it was supposed to satisfy — with the code as the only evidence of the intent.

What you find is not a tidy mapping. You find code that satisfies no stated requirement, requirements with no implementing code, and a large middle where the honest answer is "roughly this". Every one of those has to be resolved before anyone reviews it, and resolving them changes the code, which invalidates the verification.

Teams routinely lose nine months here. Maintaining traceability from the start feels slower for about six months and is dramatically faster after that.

2. "Coverage is the objective"

Structural coverage is a check on your requirements-based testing, not a goal in itself. The objective is that every requirement is verified. Coverage analysis exists to catch cases where you thought you had done that and had not.

Teams that chase the coverage number write tests aimed at code rather than at requirements. Those tests pass, coverage rises, and the review finds a body of verification that traces to nothing. The tests are then not evidence of anything, and they have to be rewritten.

If a test case cannot name the requirement it verifies, it is not a verification artefact. It might still be a useful test. It is not evidence.

3. "Independence means a different person"

It means the verification is performed by someone other than the developer, and — crucially — that the reviewer has the authority to reject. A team where verification is nominally independent but reports to the person whose schedule the rejection would break does not have independence. It has an org chart.

Authorities notice this. Not by reading the org chart, but by asking how many findings the independent team has raised and what happened to them. A verification team that has never rejected anything is telling you something.

4. "The plans are paperwork we can finalise later"

The Plan for Software Aspects of Certification is where you and the authority agree what will make this acceptable. Writing it late means designing against a standard you have not yet agreed an interpretation of, and DO-178C has real room for interpretation.

We have watched a team discover at their second review that their understanding of a deactivated-code objective did not match the authority's. Eight months of work rested on the interpretation. Ninety minutes of conversation at month two would have settled it.

The pattern

All four are the same mistake in different clothes: treating certification as something that happens to a finished product rather than a property built into it. The standard is not adversarial and it is not arbitrary. It asks you to be able to show why you believe your software is correct.

If you cannot show that, the problem is usually not the paperwork.