Is Agile programming too... ad hoc for safety-critical systems?

Question

For example, would it be incredibly dangerous to do it for avionics software?

Note, I don't completely understand Agile.

Answer 1

I don't have enough experience in that field (other than a user of aviation systems) to form my own truly independent opinion. However, all the things that I keep reading about the critical systems that have the best track record leads me to believe that waterfall is actually the best way. It's possible because people are willing to allow for the extra waste of freezing requirements in order to promote safety. Trade-offs are a bit different in that case I guess.

Answer 2

You could use the agile approach, but the first pass would have to include your safety and security aspects, or at least provide for them, so that you don't shoot yourself in the foot and end up rewriting the whole thing. But I agree with Brian, you're probably better off using the Waterfall approach for such projects.

Answer 3

Determining the Applicability of Agile Practices to Mission and Life-Critical Systems

Agile Suitability Filters

In short, there is no "Agile" programming. There is a set of practices. Some lend themselves better than others, but in general, any project will benefit from some of the practices.

The biggest area people are typically concerned with is Modeling and Architecture. There are plenty of teams out there using agile practices - for example, I know members of the Fun3d team with NASA - they use agile practices and deal with things like Space Shuttle support.

There are several groups out there devoted to this type of work - so it is possible. You just have to be aware of your risks - like any other methodology.

Answer 4

Agile should be a disciplined process. Whatever your process, safety issues in this case should be tackled up front. I don't see how delivering in iterations, using a continuous build system, calculating programmer burn rates, having stand up meetings, having the customer active engaged, etc would negatively impact safety.

Answer 5

I've worked on Air-Traffic Control systems using an essentially waterfall process, and those projects could definitely have benefited from agile practices. I don't like to think about how much of that code worked "by accident", without any kind of unit-level automated regression testing. And the requirements-up-front thing is something of a red herring. While it's true that aerospace systems are probably as close as you can get to having set-in-stone requirements up front, you still have arguments over the meaning of ambiguous requirements which only turn up when the system is supposed to be in acceptance testing. Or you have throughput issues which no one had considered that show up late in the game because of big-bang integration. Test-first, spike solutions, continuous integration, pair-programming - I think all of these would have improved the projects I worked on.

UPDATE: Not to mention how often the "design documents" were a pack of lies by the end of the project, because the design necessarily evolved in the face of reality. Agile recognizes the fact of emergent design, which is just as real in Waterfall projects as in any other, rather than trying to pretend you can get the design right before ever beginning to write code.

Answer 6

I work in aerospace (satellites specifically), and we use a hybrid approach because we face two different concerns: real-world requirements and business processes requirements.

We use a waterfall-ish approach for spacecraft requirements and critical sections because changes to the satellite are slow and rare, and screwing up there is bad.

But for the ever changing business processes we use an agile-ish approach because how they fly the spacecraft is constantly changing due to customer demands. Screwing up there means in the worst case the user gets not-as-nice results.

Answer 7

I think that depends how the security-demands integrated in the process. If they are a extra set of testing, that's nothing that is in contradiction to agile programming. I think that agile methods can help you to produce more secure software, because agile projects tend to be of higher quality than waterfall-projects. Important will be, that the additional quality-assurance you have installed is also in use for the agile-methods.

But if the security-demands are applied to the building-process, that may be in contradiction to agile methods.

Answer 8

Actually, there is a variation of the waterfall model called the V-model, that is favoured by IEC61508 for example. It is waterfall-sort-of, but with provisions for re-iteration(s) of the basic project cycle. The main purpose of the re-iterations in this case is to deal with issues detected in various stages in the process. The basic idea is that the later down the road you encounter an issue, the further back in your process you have to go to take care of and review the impact of your changes.

So it's not really Agile, but... :-)

Answer 9

There are lots of considerations. The first is what your safety criticality is. If your answer is "A" or "B" (and really "A") then absolutely NOT. You will not get away with doing Agile in anyway shape or form. There are very strict coding standards, documentation standards and process standards required from Level A software (my background of about 15 years). This includes:

• Full up/down traceability.
• Full branch coverage.
• Full multi-conditional coverage.
• Basic documents spelled out by DO-178B include: SRD, SDD, SCI, SCMP, SDP, TQP, SCI...

So not only do you have to certify your code, design and requirements but you also have to certify tool sets, compilers, automated test equipment and so forth.

In short, it is really no small feat and it will not be done with a small team. Likewise, interfaces are really solid and very specific as well as static. Changing interfaces typically requires coordination with 3+ companies (Airframe manufacture, Vender 1 talking to Vender 2).

In all honesty, a 12 line code change can cost upwards to $170,000. Of course, a 500 line code change will be $190,000. In short, there is a huge process overhead associated with Level A code (much less with Level B, even less with C and very little with Level D) making small iterations very costly; ie. it costs lots of money to get a fully fueled and flying 777 to test a small change. Even system test labs of large commercial aircraft will have a burn rate of $10,000/day.

For example: Level A: HUD, Thrust Reversers, Power-Systems, FADEC (Engine control) Level B: Secondary Switching Logic, Vocal Communication systems. Level C: In flight data links. Level D: In flight entertainment systems.

Level D and, perhaps Level C, might be candidates for Agile.

Answer 10

Hey.
On EuroStar 2009 conference Gittie Ottosen spoke about how they do agile at their company. What's impressive is that this company Systematic is creating software for air-crafts, military etc. They do it in compliance with CMMI 5, ISO 9001 and AQAP 150&2110. So I guess agile can be applied to systems with high regulations. Maybe try to look up that presentation, and try to get more info from him.