X.^Kcac,^,^
-IBKAESS
t.f5-=.,0--
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
THE "FACTORY" APPROACH TO LARGE-SCALE SOFTWARE
IMPLICATIONS FOR STRATEGY,
DEVELOPMENT:
TECHNOLOGY, AND STRUCTURE
Michael
Revised
November 12, 1987
A.
Cusumano
WP #1885-87
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
THE "FACTORY" APPROACH TO LARGE-SCALE SOFTWARE
DEVELOPMENT:
IMPLICATIONS FOR STRATEGY,
TECHNOLOGY, AND STRUCTURE
Michael A. Cusumano
Revised
November 12, 1987
WP #1885-87
FEB
5 1988
RECeiVED
Michael A. Cusumano
MIT Sloan School of Management
Sloan WP#1885-87 (Revised)
11/12/87
Software Project Paper
#1
THE "FACTORY" APPROACH TO LARGE-SCALE SOFTWARE DEVELOPMENT:
IMPLICATIONS FOR STRATEGY. TECHNOLOGY. AND STRUCTURE
The impact
linking
the
technology
of
fields
of
on
business
organizational
structure
is
strategy
research,
organizational
history,
a
concern
theory, production and technology management, and comparative international
These diverse
studies.
have
literatures
dilemma resulting from two opposing demands:
variety
in
and
product offerings;
the
treated
all
basic
a
managerial
the desire of consumers for
desire
of
managers
responsible
for
engineering and production for standardization and control over processes,
and components as
tools,
a
way
reduce complexity and costs
to
development and manufacturing, as
well as in testing
new,
due
expense,
been
to
highly
complex,
opportunities
for
firms
but
may eventually emerge
terms of costs per unit,
to
"mature"
move toward more
It
stabilize
at
high
has also
oyer time,
efficient
means of
The factory-type manufacturing organizations
engineering and production.
that
products,
the absence of economies of scale and scope.
asserted that some product technologies
creating
and customer service.
"one-of-a-kind"
or
product
have traditionally been used to
Laboratory or "job-shop" organizations
construct
in
an
in
but with
industry
little
provide maximum
flexibility
to introduce
efficiency
in
new products
or processes quickly.
The basic argument
studies
choices
of
(Cusumano 1987b,
--
this
c,
d)
paper and
is
that
a
series
of
organizational
accompanying case
type
and
process
such as job shops versus more rationalized factory environments.
.
with standardized procedures,
and intermediate components
tools,
by the supposed characteristics
be determined
or by the assumed
product types,
level
accumulate experience or as changes
cost
low
of
basis
product features grow
in
factories
that combine mass-production
As firms
and
less frequent,
compete on
the
Newer factory concepts and
and standardized designs.
computerized technologies also make
may not
technology or specific
a
industry "maturity."
of
may indeed build mass-production
managers
of
--
possible to create "flexible" factories
it
job-shop flexibility
efficiency with
in
product
variety.
Furthermore,
shops,
making,
some firms
example.
for
in
industry may choose to compete as job
an
Royces
Rolls
instead
passage of time may thus be important mainly
maturity" brings with
a
rise
and organizations,
strategies
with
it
varying
levels
of
T
Model
The
cars.
that experience or "industry
the options firms have for their production
in
some moving from job shops
with
A challenge for managers
flexibility.
technologies
new and complex
in
of
seem
that
most
to
factories
relatively
of
approporate for job-shop
production might then be how to use strategy, technology, and organizational
structure
to
improve
efficiency
in
development
product
processing
and
operations
paper
This
treats
large-scale
mainframes and minicomputers
to
mass-produced products,
number
of
interactions
If
one
tries
process
ways
of
is
--
a
segment
relatively
implementing
even
among program components.
to
development
software
of
a
environments
technology that,
The study asks
and
control,
do
producers
to the
and the potential
functions,
a
specific question:
measure structure by some simple indicators
standardization
compared
new and highly complex due
similar
for
of
of
inputs
similar
and
software
products follow different process strategies
job
shops
on
organizations
software
one
on
facilities
end
of
the U.S. and Japan
The conclusions
for example,
spectrum
corresponding to
more factory-like
and
The survey evidence presented here
the other?
in
hypothetical
a
--
follow
that,
is
that they do.
some firms
if
major
of
more factory-like
create
production organizations even for software, then strategy and implementation
are at least as important as the complexity of the technology
and the emergence
organization;
function
industry maturity.
of
factories
of
to
which
identify
this
firms
shaping the
need not be seen as simply
a
Both notions are consistent with Chandler's
basic dictum that structure should follow strategy
hoped when designing
in
study that
a
more
seem
(Chandler 1962).
set of criteria
committed
to
would make
It
was
possible
it
software
disciplining
technology, and that studying these firms through detailed cases would then
provide insights into how to develop and implement strategies for managing
product and process development more effectively, especially for
a
relatively
new and complex technology.
THE PROBLEM FRAMED
Business
IN
DIFFERENT LITERATURES
have long maintained that production organizations
historians
evolved over time and with accumulations of product and process knowledge,
moving
from
craft-like
prominent
is
the
and
18th
initially
has
in
Chandler,
19th
this
shops
to
mass-production
who has described the evolution
centuries
the textile
interpreted
job
in
Britain,
Europe
and
industry and then gun-making.
movement
as
driven
by managers
factories.
Most
of
factories
during
the
United
States,
This
historical
attempting
to
view
raise
.
and
worker productivity
processes
production
integrating
lower
interchangeable components;
and
dividing
large,
standardizing
centralized facility;
coordinating
closely
mechanizing
labor;
specializing
a
in
by
costs
unit
and
developing
process;
the flow of each
automating
or
then
tasks;
and
imposing rigid accounting controls (Chandler 1977; Skinner 1985).
In
area
the
of
organization
industrial
theory,
school
a
of
thought
rather complementary to Chandler has tended to see the characteristics of
particular
determining
Woodward
including
technology,
(1965,
who
1970),
ranging from
organizations,
large-batch and mass
identified
unit
production,
job
to
three
shops
and
basic
tended to become larger
in
scale and
or
batch
operations
mass
to
types
of
production,
to
in
that over time operations
more complex, making
producers
as
production
continuous processing operations as
organizations to become larger and more complex,
unit
outputs,
Most important was
small-batch
The assumption here was
chemical manufacturing.
and
processing,
how an organization evolves.
large part
in
inputs,
a
necessary for
as they evolved from
too,
or
it
continuous-production
operations
Somewhat
Lawrence and
argued there
to
manage
a
in
contrast
Lorsch
is
is
(1967)
the contingency theory school
as
well
as
Galbraith
(1973,
associated with
1977),
which
has
no one best way to design the structure of an organization
particular
appropriate depends on
the organization" (Scott,
technology.
What
structure
is
most
effective
or
"what environmental demands or conditions confront
1981:
208).
A recent case study
of medical-imaging
scanner introduction similarly concluded that identical technologies can result
in
different structural outcomes, depending "on the specific historical process
in
which they are embedded" (Barley 1986: 107).
and
Production
management
operations
such
specialists
Abernathy
as
and Utterback (1975), Hayes and Wheelright (1979 and 1984), and Schmenner
have also focused on the range
(1984)
to
firm
a
product technologies mature
as
Woodward,
and
Chandler
product and process options open
of
in
underlying
the
sort of
a
notion
that,
is
As with
cycle.
life
product
as
innovations descrease over time, firms tend to take advantage of accumulated
and
experience
innovate
process
their
rationalize
to
drastically reduce unit costs while standardizing quality,
modes
shop
production
of
The tradeoff
manufacturing.
used
production
and expensive
difficult
Model T production
drive
far
for
extensive,
to
in
firm
a
moved toward continuous
and
designs
Indeed,
the experience of Ford and
the
processes
demonstrates how
1920s
example,
periods
a
became
its
company can
assuming product technology or consumer tastes were
more stable than they were, and making factory systems so
long
factory
because
change.
facilities
as
and
near bankruptcy by pushing such strategic commitments too
into
itself
--
be
to
rigidity
in
by moving from job-
engineering
large-scale
to
technology and
of
time
to
change
new
to
product
rigid they took
process
or
technologies
(Abernathy and Wayne 1974).
Recent developments
necessary
flexibility
to
or
combine
development
locking
an
design and production technology have made
traditionally
and efficiency, as
Rationalizing
goods
revise
in
accepted
well as divisions
processes
organization
product differentiation
powerful combination of competitive
without
into
with
skills
a
between
tradeoffs
it
process
between design and production.
simply
single
process
producing
mode
of
efficiency
(Porter 1980,
standardized
production
also
--
but
a
rare
1985).
For example, during the 1950s and 1960s, Japanese auto firms pioneered
producing
large
standardizing methods and inputs but not
techniques,
"small-lot production"
standardized
of
lots
workers capable of quickly changing
Monden
(Schonberger 1982;
or job-shop
combine "small-lot"
perform different operations or jobs
Cusumano
Producers of machine
1985).
Piore and
1986;
flexibility
end-product variety with the
in
and management control
quality,
productivity,
1984 and
machinery and
to
equipment, and various metal components have also managed to
textile
tools,
1983;
to
due
products
final
Sabel
Sabel
1984;
Palframan
1987;
(Jaikumar
factories
large
of
Group
1987).
technology concepts (putting together similar parts, problems, or tasks) have
scheduling
facilitated
well
production
product design
rationalizing
as
parts
of
counterparts
older industries
in
arranging
engineering,
factory
layouts
small
for
and
Producers of semiconductors,
(Hyer and Wemmerloc 1984).
firms
and
or
like
automobiles,
as
large
their
like
routinely use standardized
components and add end-process customization, increasing productivity while
maintaining
flexibility
Computer-aided design
(FMS)
transfer
allowing
firms
designs,
with
to
in
design
tools
digitalized
integrated
designs
automate this
little
1985; Jaikumar 1986;
or
variety
(Harvard
with
of
School
to
manufacturing
tools,
modularized designs with
no penalty associated with
low
lot
volumes
Meredith 1987).
of
certain countries to develop similar sets of strategies and structures.
noted,
managers
to
develop
low-automation,
systems during the 1950s and 1960s (Cusumano 1985).
a
firms
As
the small size of the domestic Japanese automobile market apparently
persuaded
been
new
(Skinner
Comparative international studies have observed the tendency
in
1986).
manufacturing systems
flexible
automatically
combining
Business
similar trend
in
flexible
manufacturing
There appears
to
have
the Japanese machine tool industry (Jaikumar 1986).
A survey
and
U.S.
55
of
Japanese tended
51
establish
to
Japanese manufacturing plants found that the
types
similar
more efficient,
continuous-type
oriented
toward
(Lincoln,
Hanada, and McBride 1986).
large
number
many
firms,
of
manufacturing organizations,
of
them
operations
have produced
also seems to
Italy
of
processing
machinery
textile
a
producers,
emphasizing this combination of efficiency and specialization (Piore and Sabel
1984).
Difficult
separate
to
the
are
effects
of
culture or nation from the tendency of managers
in
kind to similar environmental conditions.
the
same time actually
development.
process
characteristics
of
if
firms
also
technology
a
rationalize operations.
seeing
It
not
is
might
options
clear
in
the same industry at
to
manage product and
the
ability
These questions can be examined
producing
similar
software
certain
what extent the peculiar
to
constrain
a
the question must
Nonetheless,
be answered to what degree managers operating
exercise
from
that country to respond
in
still
have and
being
simply
products
managers
of
at least in
do so with
to
part by
similar
or
different strategies and production organizations.
Determining
organizations
why managers make
evolve
from
deliberate
the
decisions,
frequent and conflicting debate (Scott 1981).
new products and processes,
worry about parts
and
there
are
procedures
options:
they could
recoup
of
personnel,
they
from mass sales,
may
still
complex
whether
subject
of
in
designing
Managers can
refuse to
and
encourage their
which then might be mass-
These firms might even be insensitive
shortage
or
do,
certainly,
standardization,
marketed.
profits
a
is
But,
engineers to design highly marketable products,
large
they
choices
want
to
development costs,
although,
to
if
they have
maximize
if
a
individual
On the other hand,
productivity.
companies
that
choose
to
products might have even greater incentives to exploit similarities
procedures,
parts
or
across
product
different
Firms
lines.
customize
in
tools,
pursuing
standardization (package) or customizing strategies, but especially the latter,
might
want
thus
components
This
whether
it
software
standardize
development process and major
the
reduce costs and perhaps improve quality as well.
to
,
to
can
be
illustrated
is
an
automobile,
program,
customized product
there
--
as
a
are
from
a
follows.
machine
tool,
basically
product).
1)
sell
a
It
product,
obtain
a
or
a
fully
semi-customized product (from
a
a
a
a
purchased standardized
follows that vendors should have three corresponding options:
customized product;
2)
sell
standardized product; 3) customize
a
Managers can adopt one
manage product and process development.'
product-process
life
tools
cycle
or
(Figure
even
of several
strategies to
a
different type of
With flexible factory models such as
1).
software,
moreover,
it
becomes
difficult
separate product development from process development.
A similar typology has
Lampel and Mintzberg 1987.
a
Based on the fact that job shops
one can also draw
continue to exist as factories appear,
machine
options:
in-house department that modifies
semi-standardized product.
for
a
semiconductor chip,
a
three
needs
vendor or an in-house department; obtain
standardized or "packaged" product; obtain
vendor or an
customer
a
If
recently
8
been suggested independently by
to
Table
1:
STRATEGIES FOR PRODUCT-PROCESS DEVELOPMFNT
MANUAL FULL CUSTOMIZATION:
Customize inputs and development
process for each product
IMPLEMENTATION:
Maximize the capability of the
organization to produce a unique
product that will capture a high price
from at least one customer
Hardware Analogy Job Shops
Software Analogy Small Laboratory Environment
:
:
M ANUAL SEMI-CUSTOMIZATION:
Customize some inputs and processes
and sell more than one
of each product
IMPLEMENTATION:
Maximize the capability of the
organization to produce a unique
product that will capture a large
share of the market
Hardware Analogy Batch Processing
Software Analogy Large Development Center
:
:
AUTOMATED FULL STANDARDIZATION:
Fully standardize inputs,
and
final
processes
products
IMPLEMENTATION:
Maximize the capability of the
organization to produce a product
with standard features at the lowest
possible price
Hardware Analogy Model-T Factory
Software Analogy Undesirable?
:
:
MANUAL STANDARDIZED SEMI-CUSTOMIZATION:
Standardize inputs and processes
but customize end products,
with large-factory efficiency
IMPLEMENTATION:
Maximize the capability of the
organization to produce semi-custom
products at a low price through
the use of as many standardized
procedures and inputs as possible
Hardware Analogy Small-Lot Production, Group Technology
Software Analogy Software Factory
:
:
AUTOMATED STANDARDIZED CUSTOMIZATION:
Standardize inputs and processes
but customize end products and
automate processing
IMPLEMENTATION
Maximize the capability of the
organization to produce customized
products at a low price through the
use of highly flexible process
techniques and/or automation
Hardware Analogy Automated Flexible Manufacturing Systems
Software Analogy: Program Generators, Used in Factories or Independently
:
FIGURE
1:
REVISED PRODUCT PROCESS LIFE-CYCLE MATRIX
Rate of
Major
Innovation
Process
nnovation
Innovation
Time
Product-Process Development Organization
-^
Batch
->
Automated Factory
Flexible Factory
Flexible Manufacturing System
Job Shop
FACTORY APPROACHES TO LARGE-SCALE SOFTWARE DEVELOPMENT
Software production dates back to the 1950s, when computers were first
designed that could store
in
controlling basic operations and
refined over time,
come
memory
internal
a
As
variety of applications.
the series of phases followed
resemble that for "hard" products,
to
sets of instructions
in
it
(programs)
has become
software development has
consisting of planning,
detailed
design, construction (coding), testing, and servicing (maintenance) phases.
hundreds
and
years
takes
employees
develop
It
and
test
programs such as operating systems for large mainframe computers or
real-
typically
time control
of
to
systems for factories or electric power plants.
Furthermore,
the clarity of designs, consistency of documentation, and lack or presence of
defects or inadequate designs
impose
enormous
costs
on
requiring extensive future modifications could
software
producers.
Development costs
for
software programs over their lifetimes were typically about 10% for planning
and design,
less than
about 15% for testing, and as much as
10% for coding,
70% for maintenance (Frank 1983).
As with hard manufacturing,
because there
are
numerous
computers and applications.
software,
including
types
These
operating
difficult to generalize
is
it
products
of
fall
into
systems,
for
a
about software
wide
variety
of
two basic categories:
"systems"
management
systems,
database
telecommunications and other related programs designed to operate the basic
functions of the computer or computer system;
which operate
a
level
above and implement specific functions
control, payroll analysis, or
software
software
--
--
and "applications" programs,
word processing.
like
production
Applications include "packaged"
products designed by producers for general sale --and customized
programs
tailored
to
meet
11
the
unique
needs
of
an
individual
customer.
or
Firms,
least
at
products,
software
tend to specialize
facilities,
making
possible,
it
in
theoretically,
particular
them
for
types
of
achieve
to
economies of scale or scope through standardization of tools, procedures, and
inputs.
other industries,
In
resulting
or
technologies,
tradeoff
reduced
a
in
ability
in
product or process
moving toward design standardization or factory
in
Software development may seem to be primarily
mass-production.
and engineering
design
adapt to changes
to
market demands, has traditionally been seen as the major
accepts
firm
a
in
the rigidity imposed by such "rationalization,"
that
companies make packages,
with
reproduction
involving
one-of-a-kind products,
for
activities
systems
software,
simple process of
a
or
Reinforcing
notion
this
the sense
customized
programs,
replicating
continuing
a
is
set of
in
code.
might appear that software development organizations should
shops.
a
all
Thus,
resemble job
among many
debate
programmers, managers, and academics over whether software development
more
like
factory-like
an
art
or
discipline
than
craft
and
an
(Brooks
control
suitable
activity
engineering
for
Shocman
1975;
it
1983;
is
or
Hauptman
1986).
A problem with continuing
such
attitudes
production
may
impede
process.
In
to
view
progress
software
technology as
a
rationalizing
in
development,
only
about
5%
annually
computer processing
Munson
1984).
in
since
capacity
Despite
better
mere craft
the
progress
in
is
that
design
and
improving
One study concluding around
productivity continues to be agonizingly slow.
1980 estimated that increases
a
programming output per man-hour had risen
the
1960s,
averaging
computer
12
in
contrast
about
40%
languages,
a
to
improvements
year
(Horowitz
in
and
management methods.
and
design techniques,
such as program generators that automatically
tools
produce code from high-level designs, demand for programmers
1980s outstripped the supply of programmers by about 10%
than 20%
referring
to
supply-demand imbalance
this
back as 1969 (Hunke 1981; Frank 1983).
buy
fully customized
(Kamijo
the
as
"software
as
crisis"
far
3- to 4-year wait
a
Japan, the typical backlog was 26.4
In
Further hardware development,
1986).
began
U.S. companies desiring to
fact,
applications programs typically had
(U.S. Department of Commerce 1984).
months
!n
Japan and more
in
Observers
(Zavala 1985; Aiso 1986).
the U.S.
in
the mid-
in
and small
large
in
machines, continues to expand the demand for lengthy, complicated programs,
even
computers,
personal
for
microprocessors such as the
addition,
Intel
data from IBM,
the
utilization
full
cost
In
individual productivity are
in
TRW, and GTE
can
of
indicate that fixing bugs
100 times
in
that of detecting
the design stage (Boehm 1976).
in
the
short,
In
years
80286 and 80386 (Businessweek 1987).
completed program during operation
errors
for
serious impediment to improvements
a
quality problems;
a
delaying
lack
of
programmers,
rising
demand
software,
for
increasing length of programs needed to utilize improved hardware capacity,
as
well
as
the enormous
productivity,
have
development.
For
high-quality
maximize
created
a
products
its
programs
idea
a
lower
at
manpower and
of
using
need
in
creating
to
increase
firm to
competitive advantage --
The
impact of quality problems or product changes on
raise
its
costs
invested
efficiency
standardized
than
other
resources,
factories"
procedures,
13
for
capability to produce
companies,
should
the software marketplace, as
"software
levels
tools,
to
in
variety of
a
simply
or
provide
a
to
potent
other industries.
produce
and
software
a
variety
components
of
reusable
across different projects appears to have been first proposed by
engineer
at
NATO
1968
a
Conference on
Science
Honeywell
a
improving
software
productivity.
Conference members criticized the idea as unworkable, largely
due
problems:
three
to
modules
which
did
software
that
modules
did
And
not
the
and
method
too
Two,
then
they could be easily found and
so
citing Mcllroy 1976;
impossible
characteristics
specific
was
seemed
it
systems and
types of
all
program
create
to
difficult
for
reliable
user.
depend on
no
third,
seemed
it
be efficient
constrain
not
machines.
1984,
would
that
One,
available
to
particular
of
program
catalog
to
write
(Horowitz and Munson
reused.
McNamara 1987).
These were and remain serious problems, although many large software
producers have made progress
efficiency,
1984;
as
well
Goldberg
1986)
Southern California
software
Several
.
and
factories,
others
and
companies
and Scacchi
(Eliot
Horowitz and Munson
(Ramamoorthy 1984;
reusability
as
design and overall development
facilitating
in
the
University
of
even claim to have established
1986)
have
even
launched
software
elaborate
less
rationalization projects.
Of particular importance
at
software
primarily
encountered
for
research project
several
would
standardized
approaches
common
solve:
to
(1)
the
hoped
they
Lack
discipline
development process,
a
managers
more factory-like
and
with
repeatability
the
result
or
that
continually reinventing products and processes, and not becoming as
proficient at development or project control
of
an experiment that
producer of real-time
a
problems
of
is
By the mid-1970s,
government contracts.
environment
SDC was
this
System Development Corporation (SDC),
occurred
had
to
as
managers wanted.
an effective way to visualize and control the production process,
14
(2)
as
Lack
well
as
a
to
measure before the project was completed how
design.
Difficulty
3)
accurately
in
before detailed design and coding,
meaning
performance
specifying
and recurrence
reuse components,
management,
despite the fact that
managers
would
modules
believed
that
significantly
development.
and verification
shorten
(program
a
interfaces
between tools and databases,
documentation,
verification,
management
system
in
a
tools
for
policies
centralized
facility
of
software
engineers
decide
databases,
project
to
on-line
and automated support systems for
standardized
with
and
procedures
about 200 programmers
of
software
for
program design and implementation, and
The concept and system
California.
development
library,
etc.)
areas used similar
required
time
it
capability to
off-the-shelf
of
4)
making
tools,
Little
5)
application
use
the
and
integrate
of
many
extensive
managers
Several
set
disagreements on the
of
necessary to reinvent these from project to project.
and
requirements
requirements, or changes demanded by the customer.
of certain
Lack of standardized design,
logic
code implemented
well
utilize this
Santa Monica,
in
and methods SDC copyrighted
tools
under the name "The Software Factory" (Bratman and Court 1975 and 1977).
The SDC experiment was
not
particularly
Scheduling and
successful.
budget accuracy improved dramatically, but the three problems raised
NATO
conference surfaced as well.
without
portable
computer
different
computers
problems.
Most
managers
customer
not
like
to
giving
in
a
languages
for
seriously,
create
sites,
and
For example,
different
the
programming
it
reuse
to
code
from
in
groups
that
sort of mobile job-shop
SDC
has
would
mode
one
This
applications.
tradition
been
work
difficult
project
led
the
to
for
on
other
project
at
individual
of production.
They did
up control of development efforts to
15
was extremely
at
a
centralized
facility.
and
were
leading to
not
a
by top management
required
decline
the flow of work
in
company allowed project managers
and
also
it
into
use
the
Software
the facility.
tended
to
complain
the
remove programmers from the factory
to
Programmers
unfamiliar,
rigid
standard,
as
as
the
impose
the
well
and inelegance of reusing other people's code.
retrospect,
In
it
infrastructure
factory
about
Factory,
Ultimately,
faded out of existence after approximately 10 projects.
difficulty
seems
that
SDC managers
standardized
of
tools
attempted
and
methods,
to
and
reusability
on both project managers and programmers before software technology
goals,
was refined enough
failed
solve
to
Furthermore, architects of the factory
do this easily.
to
matrix-management problems
the
SDC
steady work flow into the new system.
by 1978,
some
to
although
software
The SDC model was
standards
(Cusumano and
U.S.
to
also
by the
developed
later
an
important influence on the
U.S.
Department of
the case
Howes
even
Defense
Finnell 1987).
companies
1984;
a
gradually abandoned the effort
actively
continued
to
develop
better
software
methods, and programming environments (Stucki and Walker 1981;
Boehm
maintain
continued to use many of the factory procedures and
it
the tools.
of
necessary
Willis
1981;
Griffin
1984;
Hoffnagle and Beregi 1986).
SDC and
other
American firms no longer use terms
1984;
though
tools,
This
is
such as "factories" and appear to prefer designations such as "laboratory" or
"systems development center," or no
organizations (McCue 1978;
appear
to
buisness,
have been
slow
Hunke
too
label
all,
to
recognize
software as
of attention,
process rationalization as their hardware operations.
16
refer to their software
Some companies, such
1981).
deserving of the same degree
at
a
as
IBM, also
major part of their
strategic planning,
and
But another question
is
whether U.S. or software
of
level
and
methods,
tools,
and
integration
other large
facilities
standardization
inputs
facilities with
other countries have truly pursued
in
sufficient
among people,
distinguish
to
systems,
their
a
functions,
operations
from
minimal standardization and integration.
JAPANESE APPROACHES TO SOFTWARE ENGINEERING
Perhaps the most significant outcome
of
SDC experiment was
the
that
reports from this company encouraged several Japanese software managers to
pursue software factory organizations or
and
control
1985;
Sakata
factory
reusability
1985;
concept
(Iwamoto and
Okada
and
1986).
Shibata
into
least
at
1985
Japan,
however.
greater efforts at process
Matsumoto
1979;
SDC
Japanese
did
not
1981;
Mizuno
introduce
experimentation
the
with
centralized and highly disciplined programming environments actually predates
the
SDC experiment, going back
facility called
in
1976-1977,
a
software factory
NT&T
in
1985,
in
to
Hitachi's
1969.
opening of the world's
NEC, Toshiba, and
and Mitsubishi Electric
17
in
first
Fujitsu followed
1987 (Table 2).
Table
Key: OS
Note:
Est.
=
App
=
Ind
Tel
=
=
2:
1987
MAJOR JAPANESE SOFTWARE FACTORIES
Operating Systems
General Business Applications
Industrial Real-Time Control Applications
Telecommunications Software
facilities develop software for mainframes or minicomputers,
Employee figures are 1987 estimates.
All
software
tools
and
programming and
a
planning
or
reporting
systems
that
teamwork methodology throughout the software
Third are quality control techniques designed
they become difficult
to
fix.
And fourth
catch
to
group
facilitate
life
bugs early,
are extensive efforts
to
cycle.
before
improve
software quality and productivity through reusability of software modules and
automation
of
software
production
(code
Department of Commerce 1984; Uttal 1984;
generation)
(Kim
U.S.
1983;
Businessweek 1984; Johnson 1985;
Haavind 1986).
If
software
followed
the
product-process
historical
Japanese firms were advanced along these curves,
software factories seem to be so popular
facilities
operated
more
countries such as the U.S.
late
1950s and early 1960s,
like
factories
in
Jsnan
than
might explain why
this
--
if
large
indeed the Japanese
software
facilities
But Japanese firms began writing software
several years behind U.S.
and
cycle
life
in
in
the
counterparts, so more
experience does not seem to be the explanation.
One U.S. group touring Japan concluded
not
developing
unique or
more advanced
them more systematically then U.S.
that the Japanese firms
firms
software
tools,
(Zelkowitz
1984).
they
were
This
using
suggests
studied are simply more inclined than others toward
makiing their production operations more efficient.
of
while the Japanese were
that,
Commerce report suggested that U.S.
management because Americans
tend
to
firms
lag
view
this
A 1984 U.S. Department
in
software
technology
production
more
as
a
"craft" than the Japanese:
The Japanese have... made impressive gains
in
the development of
software tools and have encouraged their widespread use within their
software factories to boost productivity ... By contrast, while the United
States is developing software engineering technology, the use of tools
in U.S. firms is quite limited... Many U.S. software companies consider
programming a craft and believe the future strength of the industry lies
19
"
creativity rather than
development as do the Japanese."
its
in
approach
disciplined
a
A 1985 study by the Electronic Engineering Times
explanation.
It
appeared
as
developing
writer
the
in
journal
this
unique team-oriented
software
culture
cited
utilizing their traditional team or
were more effectively
well
to
software
to
as
an
the Japanese
that
group approaches,
as
contrast
to
tools,
in
Americans, who, as usual, were overly dependent on small groups and highly
skilled individuals:
"[T]he approach to software technology taken by major developers in
Japan, such as NEC, Fujitsu Ltd, and Hitachi Ltd., universally strive to
harness that tradition of excellent teamwork... Each of these developers
has automated versions of planning and reporting systems that enforce
strict teamwork methodology through the complete life cycle of a
a
computer program -- from planning to design to maintenance, and
without coding, since high-level language-source codes are automatically
produced from the design documents. ... Until now, the Japanese have
been hampered in their software development efforts by a lack of teamThe tools borrowed from the United States simply do
oriented tools.
not fit the Japanese culture because they put too much control in too
few hands.
America, industrial software development is generally done in groups
that are as small as possible to minimize the communication problems
That makes the knowledge of each individual
among people.
programmer a critical factor to the success of any softwareBut... that is just not tolerable in the Japanese
development project.
culture. As a consequence, the Japanese have had to perform basic
research into software tools that can be wielded by many hands at
Nobody else was going lo develop group-programming tools for
once.
them.
In
If
national
technology,
historical,
Japan,
as
the
such
reasons
as
opposed
companies on
clear
differences
a
to
between
exist
in
the
management
the
U.S.,
engineering
Japan
and
simply
or
and
the
20
more
a
particular
is
("hackers")
emphasis
manufacturing
U.S.
of
One explanation might be
no doubt complex.
prominent software craft culture
less
disciplined
difference
are
do
the
of
Japanese
But
practices.
composition
in
of
a
their
which
might
software
markets,
focus on
process innovations
be
encouraging
Japanese firms
certain
to
necessary to rationalize design and production
operations.
Although the figures are only approximate,
software sales
in
the early 1980s were standardized packages.
only about 5% of Japanese
some degree
involved
difference
is
also had
a
of
software
compared
sales
customization
that microcomputers
software sales,
the U.S.,
in
to
(Table
One reason
3).
Table 3:
contrast,
for
this
accounted for only about 10% of Japanese
about 50%
in
the U.S.
But Japanese customers
demands on Japanese software producers faced with
a
In
were standardized packages; 95%
long history of preferring customized systems,
programmers and
about 60% of
backlog of orders, as indicated
in
SOFTWARE MARKETS COMPARISON
a
placing tremendous
shortage of
Table
skilled
3.
(1984-851
Japan
USA
2.5
25
25
Overall Market Characteristics:
Revenues (Billion $)
Annual Demand Increases (%)
Annual Growth in Supply of Programmers (%)
Typical Wait for Customized Programs (Months)
Total Market
Product/Market Breakdown:
Integrated Systems Software
Package Software (%)
Custom Software (%)
All
All
Systems Software (%)
Applications Software
Sources:
U.S.
13
4
26
40
5
(%)
Microcomputer Software/Total Market
All Systems Software
All Applications Software
Computer Manufacturers
11
(%)
as Suppliers of:
(%)
Department
of
Commerce
21
1984;
Zavala
1985;
Aiso
1986;
Kamijo 1986;
Businessweek 1987.
by the author from data in the
software includes operating systems,
database management systems, telecommunications systems, and
The size of the Japanese software market is
related programs.
underestimated because systems software is usually sold bundled
with hardware.
The figures
Note:
listed
cited are estimates
Systems
sources.
The preceding discussion
software
is
a
and
implemented
managers
their
the
facilities
what markets
in
Japanese trend,
examine why
present
factory-like
A second question
industry?
specific products,
this
and
organizations,
product and process strategies, and of the
have chosen
of
which
is
--
appear
--
firms
The
systems.
survey
a
final
major
of
the
in
producing what
resemble factories?
to
how they have
paper
subject of this
Japanese
If
be needed to
will
and
strategy,
this
do job shops,
is
simultaneously
exist
case studies of individual firms
factory
results
One
raises several questions.
large-scale software industry,
batch
of
and
U.S.
to
is
software
producers.
THE SURVEY
The published descriptions and stated objectives
Factory
drawing
that
project
up
should
operations:
(Bratman
eight
exist
and
criteria
at
process
least
to
Court
and
1975
compare software
for
large-scale
and
standardization
for the
1977)
provided
facilities
engineering
control;
tool
SDC Software
along
and
a
a
for
basis
spectrum
manufacturing
standardization
and
reuse
of
The factory-tool infrastructure the SDC project suggested consisted
of
linkage;
and
inputs
standardization
and
control
(emphasis
on
software modules).
22
a
centralized program library to store modules, documentation, and completed
programs;
set
of
a
central database to track production-management data; a uniform
procedures
documentation;
different
parts
standardized
of
program;
a
in
the
initial
design,
specification,
project
databases
and
interface
These five variables
databases.
questions
for
survey,
an
constituted
addition,
since
an
objective
standardized components for
linking
the
the
of
reuse,
a
working on
tools
and
and
tool
various
core
process
if
and
testing,
groups
for
which attempted to see
U.S. and Japan were currently emphasizing
In
coding,
managers
the
in
similar type of infrastructure.
factory
rather than
was
strategy
to
produce
"reinvent the wheel"
with
every customer order, three questions were included about reusability.
Major software producers
literature surveys and
lists
of
in
Japan and the U.S. were identified through
software producers,
containing eight core questions plus more than
a
and sent
dozen others,
experimental nature, to provide supplementary data.^
requested
performance measures
such
as
actual
a
rates
questionnaire
many
of an
Optional questions also
of
reused code
in
Additional questions were also sent to survey participants, although
comments from the respondees, site visits and interviews, as well as partial
correlation analysis, revealed that many of the non-core questions were not
particularly useful for measuring "rationalization" along large-scale
engineering and manufacturing lines. For example, three questions asked for
emphasis on standardization of languages for high-level design, module
description, and coding.
It turned out that Japanese and
English were
mainly used for high-level design, and many managers did not know how to
answer; Japanese tended to develop specialized languages for module
description because they were less comfortable than U.S. programmers in
using English-based languages for this purpose, which made it unfair to U.S.
firms to use this question; and coding languages were often determined by
customers.
A question about top-down design was discarded because
emphasis on this tended to contrast with a more factory-type process of
combining new and old code in layers. Similarly, questions about emphasis
on high-level abstraction or layering were discarded because not everyone
knew how to interpret these.
23
a
For the core questions, managers either responsible for
recent sample year.
management or with
engineering
software
overall
experience
sufficient
to
present an overview of practices for the entire facility were asked to rank
the emphasis
on
(see Table 4),
to 4
scale of
a
Questionnaires
were directed
diversified
large
or
as
well
managers
to
as
policy
comment on each answer.
to
the
at
their facilities
at
or
facility
product-area
usually differed significantly among divisions
since software practices
level,
in
themselves and general managerial
of
and
firms,
some
diversity
seemed
useful
meet
to
different market or internal needs.
The sample was
limited
to
that usually require large amounts of people,
which
might
facility
level
different
therefore
to
seek
provide
similarities
operating
projects:
time,
incentives
and
for
and tools
managers
for
common
systems
making
departments
or
facilities
components
mainframes
products
to develop,
and
on
the
at
or
or
least
tools
across
minicomputers
("systems" software); and real-time applications programs, such as for factory
These were further
control or reservations systems ("applications" software).
broken down
into telecommunications
combined because
systems;
of
industrial
software (applications and systems were
the smallness of the sub-sample);
operating
systems;
real-time
commercial operating
control
applications;
and
general business applications.
All
the Japanese
firms
contacted
U.S. firms contacted completed the survey.
at
out
filled
About
returned two completed surveys for each type of
similar,
usually
differing
by only
24
survey;
about 75% of
To check answers, two managers
each firm or facility were asked to respond.
extremely
the
a
facility;
half
the companies
the answers were
few percentage points,
and
Other answers represent single responses.
were averaged.
A
factor
questions
eight
procedure with
analysis
three
constituted
varimax
rotation
orthogonal
factors
indicated
with
that
the
eigenvalues
rounding to approximately 1.0 (actual 2.91, 0.88, and 0.67); these explained
96.1% of the variance
a
survey answers.
in
For each factor, the variables with
strong loading (approximately 0.51 to 0.78) were summed and used to test
differences
in
the average Japanese and
product type or country origin of the
U.S.
scores,
facility
as
well
as
to test
if
were significantly correlated
with the process and reuse scores.
The data reported
total
for
eight
each variable.
in
variables
Table
6
Table 5 reflects scores for each dimension and the
on
basis
a
of
100%,
of
Table
7
for
4
to
summarizes the results of
variance tests to determine the effects of product types
or country of origin on the scores reported for the three dimensions.
8
of
compares the average Japanese and U.S. responses
the process, tools, and inputs dimensions.
one-way analysis
maximum scores
with
Tables
through 10 compare actual reuse rates reported by the Japanese and U.S.
facilities,
and analyze correlations with the three survey dimensions as
well
as types of products and country of origin.
Since
results
"^
of
in
the
this
sample
analysis
size
relatively
is
small
must be considered
the case of Toshiba,
a
as
in
absolute
no more than
single large facility
numbers,
suggestive of
(approximately 2500
programmers) had different departments producing both systems and
applications programs using identical procedures and tools, and the manager
responsible for technical development.
one set of answers and
systems and applications
Dr.
asked that they
Yoshihiro Matsumoto, submitted
be counted twice, under both
facilities.
This procedure is recommended
by Comrey 1973 and Tabachnick and
as a simple data reduction technique
1983.
Comrey suggested that
.55 (explaining 30% of the variance) were "very good," and .63
Fidell
loadings of
(40% variance) or over "excellent."
25
the
patterns existing at software facilities
noted,
however,
majority of software written and sold
most
include
applications
have
a
the
of
software,
and Japan.
surveyed Japanese firms
the
that
the U.S.
in
largest
in
It
should be
account for the
vast
Japan, and the surveyed U.S. firms
producers
of
computer operating
systems,
and related services such as data bases, which also
large software component.^
Table
SAMPLE:
n
= 44
4:
SURVEY AND SAMPLE OUTLINE
(23 Japanese,
SURVEY PARTICIPANTS:
21
U.S.)
Software Development Managers
ANSWERS KEY:
4 =
3 =
2 =
=
1
=
Capabil
Capabil
Capabil
Capabil
Capabil
ty
ty
ty
ty
ty
or
or
or
or
or
policy
policy
policy
policy
policy
is
is
is
is
is
FULLY USED OR ENFORCED
FREQUENTLY USED OR ENFORCED
SOMETIMES USED OR ENFORCED
SELDOM USED OR ENFORCED
NOT USED
The top three Japanese
firms ranked by software sales in 1986 were
NEC
($507 million), Fujitsu ($389 million), and Hitachi ($331 million).
ranked fourth in the world, behind IBM ($5,514 million), Unisys ($861), and
The Japanese sales figures considerably understate actual
DEC ($560).
software development, because Japanese firms included ("bundled") systems
software with mainframe and minicomputer hardware prices, although the size
of systems software operations corresponds roughly to hardware sales.
The
largest Japanese producers of mainframes by 1986 sales were Fujitsu ($2,470
million), NEC ($2,275), Hitachi ($1,371), and Mitsubishi ($185); the largest
sellers of minicomputers were Toshiba ($766), Fujitsu ($620), and Mitsubishi
On the U.S. side, IBM was by far the world's largest producer of
($475).
hardware and software; three of its facilities are represented in the survey.
Unisys, which ranked 2nd in world software sales, has two facilities in the
survey. In services, TRW ranked 1st and General Motors/EDS 3rd; Control
Data, Martin Marietta, and NT&T 6th, 7th, and 8th; Boeing and IBM 12th
and 13th (Datamation 1987).
Other large Japanese producers of software
included in this survey were subsidiaries of Hitachi and NEC, including
Nippon Business Consultants and Hitachi Software Engineering (Hitachi), as
well as NEC Software, NEC Information Systems, and Nippon Electronics
Development (NEC) (Kiriu 1986).
NEC
26
.
SURVEY QUESTIONS:
Process Standardization and Control (Score of 12 = 100%)
1)
A
program
centralized
library
system
store
to
modules
and
documentation
2)
A central production or development data base connecting programming
groups working on a single product family to track information on
milestones, task completion, resources, and system components, to
facilitate overall project control and to serve as a data source for
statistics on programmer productivity, costs, scheduling accuracy, etc.
3)
A uniform set of specification, design, coding, testing, and
documentation procedures used among project groups within a
centralized facility or across different sites working on the same
product family
of labor for
to
facilitate
standardization of practices and/or division
programming tasks and related
activities.
Tool Standardization and Interface (Score of 8 = 100%!
4)
Project data bases standardized for all groups working on the same
product components, to support consistency in building of program
modules, configuration management, documentation, maintenance, and
potential reusability of code.
5)
A
interface providing the capability
data bases, the centralized production
system
project
libraries
Formal
support tools,
base and program
link
.
Inputs Standardization and Control (Score of 12 =
6)
to
data
management promotion
(beyond
the
1(X)%)
discretion
of
project managers) that new code be written in modular form
intention that modules (in addition to common subroutines)
serve as reusable "units of production" in future projects
individual
with the
will then
7)
Formal management promotion (beyond the discretion of individual
project managers) that, if a module designed to perform a specific
function (in addition to common subroutines) is in the program library
system, rather than duplicating such a module, it should be reused.
8)
Monitoring of how much code
is
being reused
Total for 8 Variables (Score of 32 = 100%)
27
Table
5:
SUMMARY AND RANKING OF SURVEY SCORES
f%l
Note: Japanese Facilities indicated by *
COMPANY/FACILITY
Process
Tools
Inputs
Total
93.8
100.0
98.4
Telecommunications Software
*NEC Switching Systems
*NT&T Applications
Mitsubishi Electric
AT&T Bell Labs Applications)
*Hitachi Totsuka Works
*NT&T Systems
100.0
75.0
Table 5 Continued
COMPANY/FACILITY
Process
General Applications
*NEC
*NEC
Mita
Information Services
Control Data
*Nippon Systemware
Fujitsu Kamata Software Factory
Hitachi Omori Works
IBM (Office Products)
Martin Marietta/MD
Nippon Business Consultants
Cullinet
EDS/GM
Martin Marietta/Denver
Hitachi Software Engineering
Mitsubishi Electric
Nippon
Electronics Development
Computervision
95.8
Tools
Inputs
Total
Table
6:
COMPARISON OF AVERAGE JAPANESE AND U.S. SURVEY SCORES
n = 23
Dimension
Process (Std. Dev.)
Tools
(Std.
Dev.)
Inputs
(Std.
Dev.)
Total
(Std.
Dev.)
Table
8:
COMPARISON OF REPORTED JAPANESE AND
n = 13
Jaoanese (Std.
33.8% (14.5)
U.S. REUSE
RATES
DISCUSSION
The survey
appear
results
there are clearly variations
to
support two
emphasis among software managers,
in
the strategies and structures of their organizations.
of
software
placed
largely
as
some managers
operation,
clearly
development
One
hypotheses.
at
craft,
a
art,
making
facilities
is
that
regarding
Despite potential views
"job-shop"
or
types
similar
more emphasis on control and standardization
products
of
of
type of
processes,
basic tools, and reusable inputs (modules of code).
Within
same product types,
the
56.3% to 98.4%
in
in
Real-Time
to
Control
87.5%
a
in
It
total
ranged from
scores
54.7% to 93.8%
in
Commercial
Industrial Operating Systems;
and
Applications;
Business Applications (Table 5).
ranking within
example,
Telecommunications Software;
Operating Systems; 56.3%
90.6%
for
may be
few percentage points;
23.4% to
in
General
difficult to distinguish
facilities
28.1%
to
91.4%
but companies on opposite ends of
the spectrums that emerged from the survey rankings must be different and
in
instructive ways.
Moreover, the analysis of variance tests confirmed that
product types as defined
in
this
paper had no significant impact on where
managers scored on either dimension studied.
of
Japanese
some
national
A second hypothesis one might generate from the discussion
approaches
to
engineering
software
differences between the U.S.
far as
for
was measurable
this.
in
and Japan
that
is
in
are
management emphasis,
this limited survey.
Among the three dimensions
there
at
least as
The data provide some support
studied,
the t-tests
indicated
that
only the average responses for the inputs variables -- 74.4% for the Japanese
and 47.8% for the U.S.
63.1% for the
U.S.
--
--
and the
total
scores -- 73.7% for the Japanese and
were significantly different
32
(Table
6).
This
does
suggest that factory-type approaches
and
control
rates
standardization
emphasized
process
the
variables,
although
different at
a
in
complex
U.S.
by themselves
averages
neither
higher
scores
for
the
to
be
tools
were significantly
confidence interval even of 90%.
emphasis
and
processes
and
variables,
The only dimension
was
Japanese scores also tended
(Table 8).
(33.8% to 14.3%)
higher on
rates
process
Reported Japanese reuse rates were also significantly higher than
Japan.
U.S.
on
might be more commonly
reusability
as
well
as
centering
on
tools
phenomenon
has
particular
a
much
facility.
to
reported
with
reuse
That standardization
9).
suggests
significant
not
probably
and
significantly
(Table
reuse
inputs
were
work flowing through
correlated
that
that
reusability
do with
the
Nonetheless,
the
is
of
a
similarity
of
analysis
of
variance tests confirmed that product type was not significant, while country
of origin
rates
significantly
(Tables
producers,
and
7
who
correlated with the inputs scores and
This
10).
clearly
are
marketing
Japanese systems producers, who
reusability.
In
extent Martin
the market
Japanese applications
that
customized
basic software,
sell
products,
as
Marietta/Maryland and TRW,
in
Japan,
as
appeared
to
a
lesser
be following
a
But, as noted earlier, particular features
which almost universally has demanded customized
products, perhaps encouraged firms
pursue standardization
also
well
both tend to emphasize
the U.S., System Development Corp. /Unisys, and to
reusability or customizing strategy.
of
suggests
data
reported reuse
and
in
this
customization
reusable components.
33
country more than
relying
on
the
in
the U.S. to
construction
of
IMPLICATIONS
The survey was
emphases among managers
This
attempt
cut"
major software
at
facilities
upper end and job shops on the lower end, for
The
measure differences
to
a
variety of product types.
is
possible to impose "factory" discipline over engineering and production
operations even for
Over
time,
products similar
made by firms
savings
if
in
not
present,
the
at
to
facilities
produce customized
upper end
the
of
semi-customized)
(or
lower end of the spectrum but at
process
management or
elimination
of
a
lower cost,
having
to
industries such as semiconductors, machine tools,
due
to
"reinvent"
This may provide an important competitive advantage, as
components.
it
has
and even automobiles.
product development and production need to ask themselves
Managers
of
they
doing
are
the
at
performance to those products (packaged or customized)
at the
from
new and complex technology.
relatively
a
may become able
spectrum
in
case
historical
which should show how
studies of firms at the higher end of the spectrum,
it
the U.S. and Japan.
in
value from this research should come from detailed,
real
in
spectrum resembling flexible factories on the
across a
firms
identified
"first
a
all
can
they
to
improve their operations.
If
some firms
deemphasize standardization, integration of tools and processes, and reuse
components,
while
individual tool,
--
that
is,
capabilities
focusing
or the final product,
compared
to
essentially
to
maximize
some
the
of
on
the
engineer,
individual
if
of
the
then they may not be fully developing
their
performance
competitors
of
their
--
orQanizational
people
technical
and
invested resources.
All
at
such "rationalization" of product and process development depends,
least to
some extent, on the nature of the marget segments
34
a
firm wishes
The question then becomes, within those segments,
to serve.
be
more
--
efficient
example,
for
components rather than building
in tool
seem
semi-customizing
is
it
products
possible to
reused
from
programs from scratch, or simply investing
all
and process development and then standardizing around technologies that
degree
The
work best.
to
scale of the facility should be less important than the
of standardization of
although
processes and tools, integration, or reuse rates,
may be important
scale
to
investment process
the financial
justify
development.
For software,
this
technology
improvements
a
lingering issue
ever
can
reduced.
be
Previous
programming environments
programming techniques, expert systems and
graphics
innovations
automated
tools,
programming,
such
artificial
Unix
as
used
and
developed
continually
(Cusumano 1987b, 1987c, 1987d)
effectiveness
in
automation,
testing
,
is
to
work,
new
in
high-powered
All of
these are
software
factories
although these can probably be used with equal
--
if
they are applied consistently.
influence.
A
focus from the individual and individual tools and techniques, to the
management
and
process
expect
with
any
product and
design
and
production,
compared
example
tools
technological change and managerial
organization
least
basic
as
job shops or laboratories
A larger issue
shift in
leading
intelligence-based tools,
workstations, and rapid prototyping techniques (Brooks 1987).
being
of
programming productivity include high-level languages, time
in
integrated
sharing,
what extent the design complexity
to
is
to
suggests
the
this
and
not
reflects
as
firms
market
as
earliest
is
process
--
days
a
of
demands
movement one might
accumulate experience
in
become better defined,
an industry.
movement
35
a
at
But the software
necessarily constrained by the
.
nature of
variables
a
technology
or
by the simple passage
may be managerial strategy and
of
time.
The
efforts at implementation,
further discussion of this topic must await additional
APPENDIX TABLES
VARIMAX ROTATED FACTOR MATRIX
library
central data base
uniformity
project data base
interface
design for reuse
reuse promotion
monitoring reuse
Inputs
-0.20667
0.27622
0.11185
0.17609
0.29765
0.70171
0.74770
0.51412
Process
0.51709
0.65561
0.65900
0.13763
0.23977
0.12273
0.08013
0.49757
EIGENVALUES AND PERCENT OF VARIANCE
Variable
library
central database
project database
interface
uniformity
design for reuse
reuse promotion
monitoring reuse
Factor
although
research on individual
firms
Variable/ Factor
critical
Tools
0.35414
0.11498
0.13972
0.77652
0.62033
0.48046
0.16469
0.05278
BIBLIOGRAPHY
William J. and James UTTERBACK, "Dynamic Model of Process
and Product Innovation," Omega 3 (1975), 639-657.
ABERNATHY,
,
William J. and Kenneth WAYNE, "Limits of the Learning
Curve," Harvard Business Review (September-October 1974), 109-119.
ABERNATHY,
(Keio University), "Overview of Japanese National Projects in
H.
information Technology," International Symposium on Computer Architecture,
Lecture 1, 2 June 1986, Tokyo.
Also,
BARLEY, Stephen R., "Technology as an Occasion for Structuring: Evidence
from Observations of CT Scanners and the Social Order of Radiology
Departments," Administrative Science Quarterly 31 (1986): 78-108.
,
BOEHM, Barry W. "Software Engineering," IEEE Transactions on Computers,
C-25 (1976), 1126-1141.
,
,
Development Environment for Improving Productivity,"
Software
"A
Computer (June 1984), 30-44.
BRATMAN, Harvey, and Terry COURT (System Development Corporation),
"The Software Factory," Computer (May 1975), 28-37.
Standards, Procedures, and
"Elements of the Software Factory:
.,
Tools," in Infotech International Ltd., Software Engineering Techniques,
Berkshire, England, Infotech International Ltd. 1977, 117-143.
BROOKS, Frederick P. Jr., The Mythical Man-Month:
Engineering Reading, Ma., Addison-Wesley, 1975.
Essays
in
Software
,
BROOKS, Frederick
Computer
.
P.
April 1987,
Jr., "Essence and Accidents of Software Engineering,"
10-19.
BUSINESSWEEK, "Japan's Push
to Write
World-Class' Software," 27 February
1984, 96-98.
BUSINESSWEEK, "The
Free-for-AII Has Begun,"
11
May
1987,
148-159.
CHANDLER, Alfred D. Jr., Strategy and Structure: Chapters in the History
of American Industrial Enterprise Cambridge, MA, MIT Press, 1962.
,
The Visible Hand:
The Managerial Revolution
Cambridge, M.A., Harvard University Press, 1977.
in
,
COMREY,
Press,
A.
L.,
A
First
Course
in
Factor Analysis
,
American Business,
New York, Academic
1973.
CUSUMANO,
Management
The Japanese Automobile Industry: Technology and
and Toyota, Cambridge, MA, Harvard University Press,
Michael A.,
at Nissan
1985.
37
Michael A. and David E. FINNELL, "A U.S. "Software Factory"
System Development Corporation" M.I.T Sloan School of
Experiment:
Management Working Paper #1887-87, 1987.
CUSUMANO,
,
CUSUMANO,
Pioneering a
Michael A., "Hitachi:
Structure for Large-Scale Software Development,"
Management Working Paper #1886-87, 1987b.
'Factory'
Strategy
and
M.I.T Sloan School of
,
CUSUMANO,
Strategy,
Michael A., "Toshiba's Fuchu Software Factory:
Management
Working
Technology, and Organization," M.I.T Sloan School of
Paper #1939-87, 1987c.
.
CUSUMANO,
Standardization Strategy for a Distributed
Michael A., "NEC:
M.I.T
Sloan School of Management Working
Software Factory' Structure,"
Paper, 1987d.
.
DATAMATION,
June 1987, 28-32.
15
Lance B., and Walt SCACCHI, "Towards
Factory," IEEE Expert. Winter 1986, pp. 51-58.
ELIOT,
FRANK, Werner
Sons,
L.,
Critical
Issues
in
Software
Knowledge-Based System
a
,
New York, John
Wiley
&
1983.
FUJINO, Kiichi (Vice-President, NEC), "Software Development for Computers
and Communications at NEC," Computer (November 1984,
,
Interviews, 7/28/86 and 9/8/87.
GALBREATH,
Jay,
Designing Complex Organizations
,
Reading, MA, Addison-
Wesley, 1973.
,
Organization Design
,
Reading, MA, Addison-Wesley, 1977.
GOLDBERG,
An
R., "Software Engineering:
Systems Journal 25 (1986), 334-353.
GRIFFIN, William G.,
"Software Engineering
in
Emerging
Discipline,"
IBM
GTE," Computer (November
1984), 66-72.
HAAVIND, Robert,
"Tools for Compatibility,
"
High Technology (August 1986),
34-42.
HARVARD BUSINESS SCHOOL,
"VLSI Technology,
Inc.
(A)," Case Study 0-
686-128 (1986).
Oscar, "Influence of Task Type on the Relationship Between
The Case of Software Development," R&D
Communication and Performance:
HAUPTMAN,
Management
16 (1986),
HAYES, Robert
H.
127-139.
and Steven C. WHEELRIGHT, "Link Manufacturing Process
38
Life Cycles,"
and Product
Harvard Business Review (January-February 1979),
133-140.
Restoring Our Competitive Edge:
Wiley & Sons, 1984.
.,
Competing through Manufacturing.
New York, John
HITACHI SEISAKUSHO KABUSHIKI KAISHA
nen no ayumi (15-year
Kanagawa, 1979.
history
the
of
(Hitachi Ltd.), Kanagawa l<oio 15
Kanagawa Works), Hitachi Ltd.,
HOFFNAGLE, G.F., and W.E. BEREGI, "Automating
Process," IBM Systems Journal
HOROWITZ,
and John
Ellis
,
the Software Development
24 (1985).
MUNSON, "An Expansive View
B.
Software," IEEE Transactions on Software Engineering
.
of Reusable
SE-10 (1984), 477-486.
HOWES, Norman
R., "Managing Software Development Projects for Maximum
Productivity," IEEE Transactions on Software Engineering, SE-10 (1984), 27-
49.
HUNKE,
H.,
Holland,
1981.
HYER,
Nancy
Productivity,
ed..
'
Software Engineering
and
L.
Urban
Environments
WEMMERLOC,
.
Amsterdam,
"Group
North-
Technology
and
Harvard Business Review (July-August 1984), 140-149.
Kanji and Masashi OKADA (NEC), "Purojekuto kanri no tsuru"
(Project control tools), Joho shori (Information processing), 20 (1979).
IWAMOTO,
JAIKUMAR,
Perspective,"
Ramchandran, "Flexible Manufacturing Systems:
A Managerial
Harvard Business School Working Paper #1-784-078 (January
1984).
,
"Postindustrial Manufacturing,"
Harvard Business Review (November-
December 1986), 301-308.
JOHNSON,
R.
Times
February 1985),
(11
Colin,
"Tools
for
1,
Software
Factory,"
Electronic
Engineering
63.
KAMIJO,
Fumihiko, "Information Technology Activities in the Japanese
Software Industry," Oxford Surveys in Information Technology Vol. 3, 1-35
.
(1986).
KIM, K.H., "A Look at Japan's Development
Technology," Computer (May 1983), 26-37.
KINNUKAN,
Paul,
"Flexible
Systems
of
Software
Engineering
Invade the Factory," Hioh Technologv
(July 1983), 32-43.
KIRIU, Hiroshi, Sofutouea sanyo no jitsuzo
industry), Tokyo, Nikkan Shobo, 1986.
39
(The
status
of
the
software
LAMPEL, Joseph, and Henry MINTZBERG. "Customizing Strategies
Strategic Management," McGill University Working Paper, March 1987.
..
.and
LAWRENCE, Paul R., and Jay W. LORSCH, Organization and Environment:
Managing Differentiation and Integration Boston, Harvard Business School,
,
1967.
LINCOLN, James R., Mitsuyo HANADA, and Kerry MCBRIDE, "Organizational
Structures in Japanese and U.S. Manufacturing," Administrative Science
Quarterly, 31 (1986): 338-364.
MATSUMOTO
Yoshihiro (Toshiba), "Management of
Production," Computer (February 1984), 59-71.
Software
Industrial
An Overall Approach to Software Production"
"A Software Factory:
Peter Freeman, ed.. Software Reusability (IEEE Tutorial, 1987).
,
in
A
"SWB System:
et al.,
.,
Software Engineering Environments
Software Factory," in H. Hunke,
Amsterdam, North-Holland, 1981.
,
McCUE,
Architectural
G.H. "IBM'S Santa Teresa Laboratory:
Program Development," IBM Systems Journal 17 (1978),
Design
ed..
for
,
MclLROY, M.D., "Mass-Produced Software Components,"
in J.M.
Buxton, P.
Naur, and B. Randell, Eds., Software Engineering Technigues: 1968 NATO
Conference on Software Engineering 1976.
,
McNAMARA, Donald
(General
Electric),
"Software Factories." Lecture, Wang
Graduate Studies, Lowell, MA,
Institute of
2
February 1987.
J.,
"The Strategic Advantages of New Manufacturing
Technologies for Small Firms," Strategic Management Journal 8 (1987), 249-
MEREDITH,
,
258.
MIZUNO, Yukio (Senior Vice-President, NEC Corporation). Interview 9/26/85.
MONDEN,
Yasuhiro, Toyota Production System
Engineering and Management Press, 1983.
MURAKAMI,
Fujitsu,
Ltd.
Manager, Software
September 1987.
Noritoshi,
Interview,
,
Norcross,
Development
Ga.,
Industrial
Planning
Office,
1
NATIONAL RESEARCH COUNCIL, The U.S. Machine
Defense Industrial Base
.
Tool Industrv and the
Washington, D.C., National Academy Press, 1983.
PALFRAMAN, Diane, "FMS:
Engineering (March 1987), 34-38.
PIORE,
Michael
J.
and
Michael
E.,
Much,
,
Too
Soon,"
F.
SABEL, The Second
New York, Basic Books, 1984.
Charles
Possibilities for Prosperity
PORTER,
Too
Competitive
Strategy:
40
Manufacturing
Industrial
Divide:
Technigues for Analyzing
,
Industries and Competitors
,
New York, The Free
Creating
Competitive Advantage:
Press,
1985.
Free
mance. New York, The
_,
RAMAMOORTHY, C.V.,
tives,"
et al.,
Charles,
et
al.,
Technologv
Problems and Perspec-
191-209.
"How
Review (April 1987),
1980.
and Sustaining Superior Perfor-
"Software Engineering:
Computer (October 1984),
SABEL,
Press,
to
Keep
Mature
Industries
Innovative,"
27-35.
SAKATA, Kazushi (Former Deputy
General Manager, Hitachi Software Works),
Interview 9/10/85.
SCHMENNER, Roger
Situations
Production/Operations Management:
W.
Chicago, Science Research Associates, 1984.
,
,
Concepts and
SCHONBERGER,
Richard J., Japanese Manufacturing Technigues
The Free Press,
1982.
SCOTT, W. Richard, Organizations:
Englewood
Cliffs,
SHIBATA,
Kanji
NJ,
Prentice-Hall,
Rational,
1981.
New York,
.
and Open Systems,
Natural,
(Manager, Engineering Department, Hitachi Software Works)
Interview 9/19/85.
SHIMODA,
Hirotsugu, Sofutouea
Shimposha,
1986.
Keizai
SHOOMAN,
Software Engineering:
Martin,
Management
,
(Software
kojo
New York, McGraw-Hill,
factories),
Tokyo,
Toyo
Design. ReliabilitY. and
1983.
The Formidable Competitive Weapon
SKINNER, Wickham, Manufacturing:
Sons, 1985.
New York, John Wiley
,
£•
Leon G., and Harry D. WALKER (Boeing Computer Services),
"Concepts and Prototypes of Argus," in HUNKE, H., ed
Software Engineer1981.
Amsterdam,
North-Holland,
Environments
ing
STUCK!,
.
,
,
TABACHNICK,
Statistics,
Barbara
G.,
and
Linda
New York, Harper and Row,
S.
FIDELL,
Using
Multivariate
1983.
TOYOSAKI,
Kenshiro, Manager, Videotex Department, Software Development
Nippon
Telephone & Telegraph, Interview 3 September 1987.
Division,
U.S. DEPARTMENT OF COMMERCE, A Competitive Assessment of the U.S.
Washington, D.C., International Trade Administration,
Software Industry
,
1984.
UTTAL,
Bro,
"Japan's Persistent Software Gap," Fortune (15 October 1984),
151-160.
41
WILLIS, R.R. (Hughes Aircraft), "AIDES: Computer Aided Design of Software
Software Engineering Environments
Systems II," in HUNKE, H., ed
Amsterdam, North-Holland, 1981.
.
WOODWARD,
Joan,
,
.
Organization:
Industrial
Theory and
Practice.
London,
Oxford University Press, 1965.
ed.. Industrial Organization:
University Press, 1970.
,
Behavior and Contro l.
London, Oxford
YOSHIDA,
Division,
Tadashi, Deputy Manager, Quality Assurance Dept., Software
Numazu Factory, Fujitsu, Ltd. Interviews, 9/24/85, 7/31/86, 9/7/87.
ZAVALA,
A., "Research on Factors that Influence the Productivity
Software Development Workers," SRI International (June 1985).
ZELKOWITZ, Marvin et al., "Software Engineering Practices
Japan," Computer (June 1984),
V
42
in
the
of
US and
Date Due
MIT LIBRARIES
3
TDflD DDM flSl
MbE