syseng68k,
thank you for your response regarding "certification after initial" for computers and other parts. Will look it up.
I think that if there were bugs (unlikely), they would be found at the level
of subsystem interaction
Do you mean subsystems inside one given computer/unit, inside one PRIM or inside one ADR for example ?
Or could we have interaction between systems (one PRIM talking with one ADR), such interaction being along a multiplexing line shared by many other units ? How is this last one dealt with in "recurrent-next-version-testing" ?
This would be a systems engineering, managing complexity
issue and not one of software as such.
I understand you might wish to distinguish between these two issues, although from the perspective of the "user", this still appears as a "bug" (and not as a feature
). I mean "bug" in the sense that a computerized system acted in ways unexpected
both by its user and its designer. It remains explainable and tracing the lines of code one would understand why it did that. But the main issue is that behaviour of the system is not expected by anyone.
As a native speaker told me : "I know it's not what you
meant, but it's what you
said." This about sums up a workable definition of a "bug" for me, both from the programmer's point of view, and the user's.