Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Robert Spooner <rls19@psu.edu>]

Robert I. Eachus wrote:
> ...
> Or it may be impossible.  There have been several times I have thought 
> of creating a bug tracking system that tracks how many bugs are caused 
> by a previous "bug-fix."  The number of such bugs for each earlier bug 
> is a major determinant of when existing software has become too 
> "brittle" and has to be replaced.  But it also allows you to determine 
> when, and in fact if, a new development project is ever going to be 
> complete.
> 
> Obviously, if each bug fix (on average) creates one new bug, you can 
> never win.  The problem is that a bug tracking system only contains bugs 
> that have been found, whether or not they have been fixed.  So from 
> experience when the observed ratio reaches 0.3 on a new development 
> project you are probably already slipping schedule, hit 0.4 and you are 
> in deep kimchee.  For fielded software that is being actively 
> maintained, at about 0.6 it is time to start working on the complete 
> rewrite.  Of course, the reality is that if you are smart you rewrite 
> individual modules where the rate of secondary bugs is high and keep the 
> overall system working until it is replaced or retired.
> 

I saw a hardware situation analogous to this when I worked in industry. 
The digital circuitry was on ten inch square wire wrap boards in rack 
cabinets. The circuitry was designed, then sent out to a wire wrap house 
to be semi automatically wrapped. Fully automatic wrapping was not 
feasible because the Manhattan pattern of the wires would make the 
circuitry too slow. Once a board returned and was populated, it would be 
tested. There were some design errors and some wire wrap errors because 
of chains being broken or tied together, etc. In looking at the defects 
over time, I saw an exponential decay curve. A technician would take one 
of these 10,000 pin boards, and have to add and remove wires. In the 
process, some mistakes would be made, perhaps miscounting pins, perhaps 
having to remove and then forgetting to replace some wires to get to a 
lower level error. Occasionally there were other design errors uncovered 
as well. After testing more changes would have to be done giving rise to 
a percentage of errors again. Assuming that the defect decay rate was a 
function of board size, it was easy to see that we would have been in 
real trouble if the boards had been 12 inches square instead of 10!

The experience drove home to me the truth that you can't just scale up 
what works on a small project and expect it to work just as well on a 
large one. That's why Ada is so useful for programming in the large - it 
gives you the architectural tools you need so that you don't have to 
contend with the software version of a wire wrap board with 14,400 pins. 
The nuclear industry found out that scaling up a 50 megawatt submarine 
propulsion reactor to 500 or 1000 megawatts for power generation didn't 
work so well either.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu