Comment Re:'zero defect' development (Score 1) 110
It seems the weak link in this zero-defect cause is the specification. Zero-defect software becomes unattainable without precise specifications.
Zero-defect software should probably be approached from the viewpoint of course-grained systems. Break the problem down into smaller problems and attempt to prove each smaller system is correct. As smaller systems are combined to build bigger systems, the zero-defect approach shifts to proving the integration of smaller systems is correct.
I offer two suggestions for approaching zero-defect software:
- Well-defined API's for each system
- Testing as many permutations of these API's as possible.
The interfaces for each system must be simple for an attempt to prove it's correctness. For example, I once took over an EBPP product's development only to discover 9 API's for paying a bill! Why not just one? Put those 9 API's in the hands of an inexperienced programmer and you have too many chances for incorrect usage. Well defined systems with well defined API's is essential for approaching zero-defect software.
On another project 12 years ago, I had a team of human and automated testers pounding on every reasonable permutation of API usage imaginable, but we still had bugs coming in from the field. We were baffled to say the least, as we could not think of any scenario we did not test. The culprit was our imagination, we did not think many API usage permutations were reasonable, but some of our users did! Testing every permutation was unreasonable for our given project. So how could we test for the dumbest user doing the "dumbest and most unreasonble" things? My answer was to create the dumbest user of all... to build an automated tester which committed random acts. We executed this automated randomized test on a farm of machines over a weekend, and come Monday about half the target applications had produced incorrect results!
The pith of the latter story is testing cannot guarantee a system's correctness, so a stronger emphasis must be placed on defining and integrating software systems. OMG's MDA is a solid approach, as their goal is to integrate and synchronize domain models, system models, and source code models into a single development paradigm. A good system architect can coordinate the demands of both domain experts and programmers to ensure well defined systems and API's. As MDA tools improve, the ability of the system architect to more closely approach zero-defect software also improves.
Randy
Zero-defect software should probably be approached from the viewpoint of course-grained systems. Break the problem down into smaller problems and attempt to prove each smaller system is correct. As smaller systems are combined to build bigger systems, the zero-defect approach shifts to proving the integration of smaller systems is correct.
I offer two suggestions for approaching zero-defect software:
- Well-defined API's for each system
- Testing as many permutations of these API's as possible.
The interfaces for each system must be simple for an attempt to prove it's correctness. For example, I once took over an EBPP product's development only to discover 9 API's for paying a bill! Why not just one? Put those 9 API's in the hands of an inexperienced programmer and you have too many chances for incorrect usage. Well defined systems with well defined API's is essential for approaching zero-defect software.
On another project 12 years ago, I had a team of human and automated testers pounding on every reasonable permutation of API usage imaginable, but we still had bugs coming in from the field. We were baffled to say the least, as we could not think of any scenario we did not test. The culprit was our imagination, we did not think many API usage permutations were reasonable, but some of our users did! Testing every permutation was unreasonable for our given project. So how could we test for the dumbest user doing the "dumbest and most unreasonble" things? My answer was to create the dumbest user of all... to build an automated tester which committed random acts. We executed this automated randomized test on a farm of machines over a weekend, and come Monday about half the target applications had produced incorrect results!
The pith of the latter story is testing cannot guarantee a system's correctness, so a stronger emphasis must be placed on defining and integrating software systems. OMG's MDA is a solid approach, as their goal is to integrate and synchronize domain models, system models, and source code models into a single development paradigm. A good system architect can coordinate the demands of both domain experts and programmers to ensure well defined systems and API's. As MDA tools improve, the ability of the system architect to more closely approach zero-defect software also improves.
Randy
