Giles Brown wrote: > Michael Sparks wrote: >> The problem that these sorts of approaches don't address is the simple >> fact that simple creating a formal spec and implementing it, even if >> you manage to create a way of automating the test suite from the spec >> *doesn't guarantee that it will do the right thing*. > <snip> >> As a result I'd say that the subject "Software bugs aren't inevitable" >> is not true. > > I think you can argue (I would) that any behaviour that is in the > specification this "isn't right" is not a software bug, but a > specification error.
To a user there is no difference. If the software doesn't do what they wanted it to do/asked for, then to *them* the person who is accepting the software it's a bug. It doesn't matter to them what caused it - be it a buffer overflow, a misunderstanding of a language feature or an incorrectly written formal spec, it's still a bug to them. I'm actually a big fan of formal specification (specifically VDM), but that doesn't stop me realising that it's not a cure-all, and it's also not an excuse - if code doesn't do what it was asked to do, it's bust. Regards, MIchael. -- http://mail.python.org/mailman/listinfo/python-list
