To start with, DO-178C does not impose any particular life cycle or methodology. It talks about objectives and activities that can be done to satisfy those objectives. Moreover, the objectives are quite general, for example: “High-level requirements are developed.”
It may seem that DO-178C leaves a lot of space for life cycle anarchy with such general definitions of single goals. However, a complete set of several dozens interrelated goals drastically reduce the room for maneuver in a life cycle choice. The waterfall or V-model life cycles seem to be the easiest and most straightforward way to fulfill all of the goals at once. Nevertheless, the easiest way is not always the most appropriate.
The goals are arranged into 10 groups represented by tables A1 – A10 in the annex of the standard. Each group corresponds to certain aspect of a life cycle. In addition, the table defines the rigor of the process with respect to software level:
Logically, the higher the level is the more goals must be satisfied. However, look at the distribution of those goals. The number of verification goals outruns the number of development goals several times. Moreover, development goals are exactly the same for level A, level B, and level C software. So DO-178C deems that the reliability of the software bases on the thoroughness of verification. This conclusion can be even strengthened: you cannot say anything about reliability of your safety-critical airborne software until verification is complete!
Unsurprisingly, waterfall and V-model can become costly if an error spreads through the whole life cycle before it uncovered in late verification stages. IIt is not a rare for additional iterations of the whole cycle to be added at the end of a product timeline to correct problems from the beginning of the story. This all results in nasty deadlines, a demoralized and exhausted project team, angry customers, and frenzied top management.
An obvious piece of advice for project managers is to implement as much verification as early as possible. Bingo! This concept is among the outstanding Agile traits.
I do not want to add fuel to the fire of the heavy-weight vs. Agile holy war. I do want to emphasize that Agile is not the equivalent of anarchy. Treat requirements, design, and other required outputs as a valuable part of your product rather than an annoying or exhaustive documentation. With such an attitude Agile methods fit perfectly: break your life cycle into smaller iterations and pull-in verification.
Of course, you need to be very careful implementing Agile in your safety-critical project. Tailoring the spirit of Agile practices to DO-178C environment is not an easy task. I will provide a practical example of such tailoring in my next blogpost.