[adrianN]

I write safety critical software. We also have unclear requirements and unreasonable deadlines. Communicating with the relevant stakeholders until the requirements are clear and the deadlines are manageable is a very important part of the process. The main difference to normal software development is that we document everything. Every change to the software needs a new or changed requirement, tests and reviews, all documented. It's not done until C2 coverage is reached and each requirement has a test to verify it. Then we had the software off to other people who do even more tests, on real systems. They also document everything.

[maxxxxx]

I don't do safety critical software myself but I work at a medical device company so I see the teams that work on patient facing products. Their cycles are much longer, management doesn't force new enterprise systems on them, they are very deliberate with changes. It's just a different paradigm. I didn't want to belittle the NASA guys but I just don't see much to learn from there. Their approach has the benefit of high quality with the trade off of slow pace of change.

[adrianN]

I agree. You get 90% of the quality for 10% of the cost by writing your requirements down, doing code reviews, and testing your programs thoroughly.

In fact, if quality is your main goal and you don't have to prove process compliance you can probably have a much safer product than the compliant competition by just investing the time spent on documenting every process step on writing better requirements, more tests, and refactoring your code to make testing easier. The last point is especially difficult in an environment where every software change needs a requirement.

[omouse]

Hah, the only thing that most people end up doing is code reviews and much of those are very relaxed and bare-bones.

[maxxxxx]

A real thorough code review is a big deal. It probably takes as much time as writing it.