Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!pdxgate!eecs!warren
From: warren@eecs.cs.pdx.edu (Warren Harrison)
Newsgroups: comp.software-eng
Subject: Re: Identifying high quality software development efforts
Message-ID: <534@pdxgate.UUCP>
Date: 4 Nov 90 20:45:08 GMT
References: <1869@shodha.enet.dec.com> <5728@stpstn.UUCP> <1990Oct30.204626.8783@ico.isc.com>
Sender: news@pdxgate.UUCP
Reply-To: warren@eecs.UUCP (Warren Harrison)
Distribution: na
Organization: Portland State University, Portland, OR
Lines: 24

>> Specific examples: U.S: typical 1 to 3 errors/KSLOC, .01 to .1 for critical
>> software; Japan: some companies report .008 errors/KSLOC. 

When throwing these numbers around, we need to make sure we're not comparing
apples and oranges. I'm not sure where each individual has gotten their
statistics from who mentions such numbers, but the Japanese typically
report their LOC figures in "assembler equivalent lines" which means they
multiple their FORTRAN, C, or whatever lines by some appropriate expansion
constant to get the AELs. I strongly suspect the bug/KLOC figures are
actually bugs/KAEL. Obviously this makes things look much better ... for
example, lets say a 5,000 line FORTRAN project has 15 bugs ... this gives
a bug/KLOC ratio of 3/KLOC, but multiply 5,000 by the magic expansion factor
(let's say 1 to 10) and we get 15/50,000 or .3 bugs per KLOC.

As I said, this is just a guess, but the AEL metric is mentioned many times
in a mongraph entitled Japanese Software Engineering which is a collection
of papers by Japanese Software Engineering figures.

Warren

==========================================================================
Warren Harrison                                          warren@cs.pdx.edu
Department of Computer Science                                503/725-3108
Portland State University