Identifying high quality software development efforts
Warren Harrison
>> 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 war...@cs.pdx.edu
Department of Computer Science 503/725-3108
Portland State University
Randy Marks
In article <5...@pdxgate.UUCP>, war...@eecs.cs.pdx.edu (Warren Harrison) writes...
>>> Specific examples: U.S: typical 1 to 3 errors/KSLOC, .01 to .1 for critical
>>> software; Japan: some companies report .008 errors/KSLOC.
>
>
>in a mongraph entitled Japanese Software Engineering which is a collection
>of papers by Japanese Software Engineering figures.
Are these papers in Japanese or English? Can somebody provide additional
info. so that I might have our library obtain copies for me?
Randy Marks
P.S. I have acess to a translator, so even if they are in Japanese, I'm
interested.
(UUCP) {decvax,ucbvax,allegra}!decwrl!ssdevo.enet!marks
(INTERNET) ma...@ssdevo.enet.dec.com
(domain-based INTERNET) marks%ssdev...@decwrl.dec.com
..........................................................................
From rare places come rare experiences.
..........................................................................
Stan Kalinowski
>>> 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
Indeed. In addition to the units of measure, we need to be sure that
we are comparing similar types of software. The design approach and
Q/A method used in an embedded system for a consumer product is quite
different from the techniques used for applications on a general
purpose computer. I know there should be no difference, quality is
quality, but in practice some markets are more tollerant to bugs and
actually prefer large gains in performance/functionality while
accepting marginally higher error rates. A good example of this
tradeoff is the X Window System, in it's early releases it was buggy,
but as time goes on it gets better. It could have been delayed until
all the bugs were worked out, but then the X consortium wouldn't have
gotten the user feedback that allowed them to better tune the product
to the user's needs.
Of course, here at Tek, we achieve high performance/functionality
without the bugs. :-)
stank
US Mail: Stan Kalinowski, Tektronix, Inc., Network Displays Division
PO Box 1000, MS 60-850, Wilsonville OR 97070 Phone:(503)-685-2458
e-mail: {ucbvax,decvax,allegra,uw-beaver}!tektronix!orca!stank
or st...@orca.WV.TEK.COM
Warren Harrison
>
>In article <5...@pdxgate.UUCP>, war...@eecs.cs.pdx.edu (Warren Harrison) writes...
>>in a mongraph entitled Japanese Software Engineering which is a collection
>>of papers by Japanese Software Engineering figures.
>
>Are these papers in Japanese or English? Can somebody provide additional
>info. so that I might have our library obtain copies for me?
The papers are in a collection entitled "Japanese Perspectives in Software
Engineering", edited by Yoshihiro Matsumoto and Yutaka Ohno, published by
Addison Wesley, ISBN 0 201 41629 8.
After checking, I find my acronym was incorrect - it's EASL (equivalent
assembler source lines). Specific numbers mentioned in the papers was (for
1985) 1.6K EASL/month, not including reused code, 3.1K if you include
reused code. The SOftware Engineering text by Schach (ISBN 0 256 08515 3,
Irwin Publishers) cites an expansion factor of 4 for EASL which translates
into about 400 lines of new "high level" code a month.
As I said in my earlier posting, I'm not sure if the other numbers from Japan
we always hear are EASL or actual high level lines of code, but in the
Addison Wesley collection, manyof the authors specify their data in terms
of EASL.
Albert Zhou
the subtitle is "--How to live with bad software". This book will increase
users' tolerance on software bugs, ideal for free distribution with any
bug-haunted software.