Everyone who writes safety critical software should read this

[eles]

On Thursday, 31 October 2013 at 20:32:49 UTC, Marco Leise wrote:
> Am Thu, 31 Oct 2013 17:00:59 +0100
> schrieb "eles" <eles at eles.com>:
> I would discriminate between change requests and bug reports.
> You should be responsible for any bugs and fix them, but
> changes resulting from unclear specifications are entirely
> different. I wouldn't do any more real work on the project
> than is written down in the contract. (Meaning: Be prepared
> for the changes you allowed for, not random feature requests.)

Yeah, maybe is a corporation culture to avoid the term "bug", but 
we always use the term "change request". Maybe it has a better 
image :)

Normally, it is assumed that passing the tests proves that 
specifications are accomplished, so the software is perfect.

This, of course, if the tests themselves would be correct 100% 
and *really* extensive.

Or, some things like race conditions and other heisenbugs occur 
only rarely. So, you still need to conceptualize and so on.

In practice, is not really different to fix a bug or to make an 
evolution of the code, except that for the former the urgency is 
greater. Anyway, in the end, it is the guy with the budget that 
decides.

It is an iterative process, however: you start with some ideas, 
you implement some code, you go back to the architecture 
description and change it a bit, in the meantime you receive a 
request to add some new specification or functionality so back to 
square one and so on.

But this is development. What really ensures the quality is that, 
at the end, before shipping, all the steps are once again 
checked, this time in the normal, forward mode: requirements, 
architecture, code review, tests. *Only then* it is compiled and 
finally passed to... well, not to the production, but to the 
dedicated Validation team.