Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!ukma!usenet.ins.cwru.edu!abvax!iccgcc!cole
From: cole@iccgcc.decnet.ab.com (Bill Cole, Allen Bradley CIS Div.)
Newsgroups: comp.software-eng
Subject: Re: Software development in Japanese firm
Message-ID: <4112.27fb044e@iccgcc.decnet.ab.com>
Date: 4 Apr 91 15:47:41 GMT
References: <RYUJI.91Mar26142145@tandem.lsa.ncl.omron.co.jp> <519@tivoli.UUCP>
Distribution: comp
Lines: 78


In article <519@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes:

>This is interesting.  We in the American software industry keep hearing
>of the prolific, bug-free Japanese developer/engineer who often completes
>200 - 300 lines of defect-free code per day.  Can you verify this for us?

<Other stuff deleted...>


I think that the last statement above needs refinement.

There has been a lot of talk recently about the Software Factory approach
being used by several Japanese companies.  The dramatic numbers on error 
densities coming from Japan (specifically NEC/Hitachi) should be looked at 
in a larger context, rather than simply number of densities/KLOC.    
 
In Michael Cusamano's series of reports on software factories, some
discussion is given to software production strategies (e.g. strategic
positioning vs. contingency).  Both of these strategies are rooted in
the type of product being developed.  The reasoning he explains is that:

(Loosely paraphrased)

<"successful factory-like approaches targeted middle of the market in 
terms of product price and functionality, stressing reusability and 
economies of scope in designs, methods, tools, and application knowledge,
appealing to customers sensitive to price/performance (e.g. strategic 
postitioning).

Alternately, firms in the high-end/full custom business and those
making standardized packages seem to require loosely-structured, 
project-centered approaches that were different with each product 
and relying mostly on personnel who were highly skilled and
knowledgeable.  Unique projects and high-skill personnel are probably 
more expensive to manage, but this probably does not matter to the 
producer if customers are willing to pay high prices, or a package 
becomes a best-seller (e.g. contingency).">


The point Cusamano is making here is that the techniques used in a software
factory approach are product-dependent to a degree.  Or to put another way:
Software developed for a monolithic embedded system will probably have more
"errors", due to the "custom" nature (read ambiguous requirements) and 
stringent quality criteria applied to it; whereas ROM for a series
of consumer products (e.g. calculators) has much more discrete requirements,
along with potential for reuse across a family of products.  These factors
have a major impact on the ultimate error densities achieved in a 
development effort.

(A question arises here on the *subjective* nature of what is "an error" - 
especially with ambiguous design requirements, but that can be the subject 
of another post.)

In a larger scope, this brings to mind a question on the discussion of 
metrics in this group.  How does the *type* of software being developed 
impact the interpretation of process/design complexity metrics
applied to it?  Having personally done some design metrics work on various
types of software, I learned (the hard way) that McCabe's Cyclomatic 
Complexity measure  has to be interpreted in the context of the
software being scrutinized.  Software for real-time embedded systems can
have much higher complexity measures than normally accepted for non 
real-time graphics software, due to the platform/timing/design constraints 
the developer had to work within.

Any other thoughts on this?
 
[Flame suit on - fire away!]  

________________________________________________________________
| Bill Cole -  Senior SW Design Engineer                        |
| Allen-Bradley CIS Div.                                        |
| 375E Alpha Dr.,                                               |
| Highland Heights, OH  44143                                   |
| (216) 646-3335                                                |
|                                                               |
| * I wish sometimes that my company *did* share my views! ;)   |
|_______________________________________________________________|