Xref: utzoo comp.edu:2922 comp.object:753 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!snorkelwacker!mit-eddie!rutgers!bellcore!dduck!duncan From: duncan@dduck.ctt.bellcore.com (Scott Duncan) Newsgroups: comp.edu,comp.object Subject: Re: Reasons why you don't prove your programs are correct Message-ID: <19020@bellcore.bellcore.com> Date: 16 Jan 90 19:41:00 GMT References: <16479@joshua.athertn.Atherton.COM> <1455@krafla.rhi.hi.is> <16665@joshua.athertn.Atherton.COM> <10289@microsoft.UUCP> Sender: news@bellcore.bellcore.com Reply-To: duncan@ctt.bellcore.com (Scott Duncan) Organization: Bellcore, Piscataway, NJ Lines: 77 In article <10289@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: > Trying to >'prove' software is correct does nothing to improve the quality of the software >involved. Finding and removing bugs does. The trick is to try to find >and fix as many bugs as cheaply as possible in a reasonable amount of time. Actually, as is pointed out below, the "trick" is to avoid introducing defects in the first place or find them before code gets written. While it is true that the writing of code can introduce defects, most people's investigations in defect analysis suggest that a substantial proportion of defects result from requirements, specification, or design problems rather than coding ones. >Is a new, high quality car free of bugs? NO -- it has hundreds or thousands >of engineering and manufacturing imperfections. Likewise any reasonably >sized piece of software. I would submit that the number of parts/pieces/etc. in many manufactured items relative to the number of critical ones -- ones that can cause malfunction -- is higher than that in software. That is, it is more likely that defects in software will produce malfunction than manufacturing imperfections since soft- ware describes a process more than a product. Each step of the process des- cription is important -- otherwise it shouldn't be there (as is also pointed out below). (I would agree that many defects in manufactured products make them less de- sirable to use, but many affects appearances and looks only rather than the safety issue implied by the example below. In software, even the "looks" of software systems can impair their effective use by the customer. Hence the concern for human factors in software.) > Rather than try to 'prove' your auto is >perfect, better to test that the wheels don't all fall off while driving >down the freeway at 60 miles an hour. I believe that the primary job of testing and quality assurance is to try to "prove" a product or software system is not perfect. And, hence, to point out problems in the process -- manufacturing or development -- which created it. I am somewhat in agreement with the attitude expressed here, therfore, and the implied philosophy of identifying what is critical and making sure that/these part(s) function properly. >Again: 'proving' that software is correct does nothing to improve the >quality of that software. True, but then the thrust, as I understand it, is not to improve the quality through proof, but to verify the quality (or lack of it). > Finding and removing bugs does improve the >quality of software. This approach, however "practical," does seem to suggest some giving-in to the inevitability of defects. Perhaps a better approach, all around, would be to investigate the applicability of statistical quality control methods which, if I read the literature on Japanese development efforts correctly, attempt to determine just how much testing is needed to remove cerrtain levels of defects. > Find and remove the worst bugs as cheaply as >possible in order to create the highest quality of software you can produce. Presumably, the statistical approaches are focused on doing just that. >The cheapest bug to remove is the one that was never introduced. And you >can't introduce bugs in code never written. So only write code for the >most needed features. As noted above, I quite agree. It is unfortunate that most productivity mea- sures applied to spftware (be they lines of code, function points, etc.) seem to emphasize producing more code or more features rather than meauring how little code or how few features can be producedd to accomplish the task. >The proper approach to quality software has more to do with Shewhart >and Deming than Turing. Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (201-699-3910 (w) 609-737-2945 (h))