«
LIBKAeES
^
HD28
.M414
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
SOFTWARE
THE "FACTORY" APPROACH TO LARGE-SCALE
STRATEGY,
FOR
IMPLICATIONS
DEVELOPMENT:
TECHNOLOGY, AND STRUCTURE
MICHAEL
September 25, 1987
A.
CUSUMANO
WP#1885-87 (Revised)
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
THE "FACTORY" APPROACH TO LAEGE-SCALE SOFTWARE
DEVELOPMENT:
IMPLICATION'S FOR STRATEGY,
TECHNOLOGY, AND STRUCTURE
MICHAEL
September 25, 1987
A.
CUSLTIANO
WP#1885-87 (Revised)
M.I.T,
LIBRARfES
OCT 2
1987
RECEIVED
Michael A. Cusumano
MIT Sloan School of Management
9/25/87
THE "FACTORY" APPROACH TO LARGE-SCALE SOFTWARE DEVELOPMENT:
IMPLICATIONS FOR STRATEGY. TECHNOLOGY. AND STRUCTURE
The impact
of technology on organizational structure
is
a
concern linking
the fields of business history, strategy research, organizational theory,
production and technology management, and comparative international studies.
These diverse literatures have
from two opposing demands:
all
treated a basic managerial dilemma resulting
the desire of consumers (and perhaps
(1)
marketing strategists) for variety
in
product offerings; and
(2)
the desire of
managers responsible for engineering and production for standardization
tools,
components, and procedures as
a
way
of
reduce complexity and costs
to
product development and manufacturing, as well as
in
in
testing and customer
service.
Laboratory or "job-shop" types of organizational structures have
traditionally been seen as the most flexible
way
to
design and construct
a
variety of products, but at high expense, due to the absence of economies of
scale and scope.
It
has also been assumed
various studies that, as
in
a
technology "matures" over time and firms better understand product-market
characteristics, they can
move toward more
efficient
means
of production.
Mass-production engineering and manufacturing organizations are usually seen as
occupying the upper end of the resulting spectrum
terms of costs per unit, but
little
flexibility in
--
maximum
efficiency
in
terms of introducing new
products or processes quickly.
The basic argument
preparation
is
of this
paper and
a
series of case studies
in
that organizational type and process choices -- such as job shops
1
more
versus
--
procedures
may not be
inherent
characteristics
assumed
level
of
in
This paper treats
Managers even
of
formulate strategies to improve efficiency
processing
operations;
and
implementing
If
a
specific
segment
of a
new technology
products follow different process strategies
one end
on
of
or product areas
The conclusion
hypothetical
a
organizations on the other?
facilities
--
these
large-scale
asks
It
-- for
example, corresponding to job
spectrum
the U.S. and Japan
follows that,
if
of inputs
do producers of similar software
and
more factory-like
The survey evidence presented here
in
specific
a
one tries to measure structure by some simple indicators
and process standardization and control,
shops
is
of
38 software
that they do.
some firms are more intent than others on
way
disciplining a technology and using organizational structure as a
to
compete
more effectively, then competitive strategy and effective implementation are
least
as
important
technology
in
if
not
more important than the nature
shaping the organization.
This
is
of
what extent technology might be
effectiveness or structure.
of criteria
would make
to disciplining
would then
it
It
consistent with Chandler's basic
constraining
was hoped when designing
factor
this
on
is
managerial
study that
a set
possible to identify which firms seem more committed
software technology;
provide
a
at
particular
a
dictum that structure should follow strategy (Chandler 1962); another question
to
in
even for similar
of organizations,
software development for mainframes and minicomputers.
question:
new and
relatively
new industry.
relatively
a
and
or the
very different types
in
inputs
technology or specific product types,
still
and
development
standardizing
by the
industry "maturity."
strategies can result
products
a
environments,
influenced as the literature suggests
as
of
complex technologies might
product
factory
rationalized
some general
and that studying these firms
insights
into
effective
in
strategies
detail
and
organizational structures for managing product and process development for
relatively
a
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 job shops
is
to
mass-production factories.
Most prominent
Chandler, who has described the evolution of factories during the 18th and
19th centuries
in
Britain,
Europe and the United States,
industry
and then
gun-making.
movement
as driven
by managers attempting
This
initially in
view has
historical
to raise
the textile
interpreted
this
worker productivity and
lower unit costs by standardizing and then integrating production processes
large,
centralized
coordinating
mechanizing
the
or
facility;
flow
of
automating
developing
each
interchangeable
process;
and
tasks;
dividing
imposing
components;
and
rigid
closely
labor;
specializing
accounting
in a
controls
(Chandler 1977; Skinner 1985).
In
the area of industrial organization theory,
complementary
to
Chandler has tended
a
school of thought rather
to see the characteristics of a particular
technology, including inputs, processing, and outputs, as determining
part how an organization evolves.
who
in
large
Most important was Woodward (1965, 1970),
identified three basic types of production organizations, ranging from unit
job shops
and small-batch production,
continuous processing operations as
in
to large-batch
and mass production,
chemical manufacturing.
here was that over time operations tended to become larger
complex,
making
it
necessary for organizations
to
in
to
The assumption
scale
and more
become larger and more
complex, too, as they evolved from unit or batch operations to mass producers
or continuous-production operations.
Somewhat
in
contrast, the contingency theory school, led by Lawrence and
Lorsch (1967) as well as Galbraith (1973, 1977), has argued there
way
design
to
the
structure
What structure
technology.
is
an
of
organization
to
manage
is
a
no one best
particular
most effective or appropriate depends on "what
environmental demands or conditions confront the organization" (Scott,
A recent case study
208).
scanner introduction similarly
of medical-imaging
concluded that identical technologies can result
depending "on the specific
historical
1981:
different structural outcomes,
in
process
in
which they are embedded"
(Barley 1986: 107).
Production and operations management specialists such as Abernathy and
Utterback (1975), Hayes and Wheelright (1979 and 1984), and Schmenner (1984)
have also focused on the range of product and process options open to
as product technologies mature in
Woodward,
underlying
the
notion
a
sort of
is
cycle.
life
that
firms
a
firm
As with Chandler and
tend to take advantage of
accumulated experience and innovate to rationalize their process technology.
The tradeoff
in
rigidity as a firm
moved toward continuous production used
to
be extensive, because designs and processes became difficult and expensive to
Indeed, the experience of Ford and
change.
the 1920s demonstrates how
a
Model T production
its
company can drive
pushing such strategic commitments too far
--
itself into
facilities in
near bankruptcy by
for example,
assuming product
technology or consumer tastes were more stable than they were, and making
factory
systems so rigid they took long periods of time to change to new-
product or process technologies (Abernathy and Wayne 1974). Abernathy and
Wayne
cited the Ford example to encourage
assuming
a
managers
to exercise caution before
process technology was mature and then instituting the type of
technological
systems
and procedural standardization commonly needed
to
operate
highly rationalized mode of production.
a
Strategy theory has pointed out that creation of an organization capable
of
combining product differentiation and process efficiency may provide
but powerful combination of competitive
developments
skills
(Porter
design and production techniques have
in
between process
for traditionally accepted tradeoffs
1980,
in fact
1985).
a
rare
Recent
reduced the need
flexibility
and efficiency
and thus created capabilities that help firms rationalize development processes
without simply producing standardized goods or locking an organization into
single
mode
a
of production.
For example, during the 1950s and 1960s, Japanese auto firms pioneered
"small-lot production"
producing
large
workers capable
lots
of
techniques,
of
standardizing methods and inputs but not
standardized
final
products
to
machinery and
quickly changing to perform different operations or jobs
(Schonberger 1982; Monden 1983; Cusumano 1985).
textile
due
Producers of machine
tools,
equipment, and various metal components have also managed to combine
"small-lot" or job-shop flexibility in
and management control
quality,
of
end-product variety with the efficiency,
large factories
Piore and Sabel 1984; Sabel 1987; Palframan 1987).
(Jaikumar 1984 and 1986;
Group technology concepts
(putting together similar parts, problems, or tasks) facilitate scheduling of parts
production or arranging factory layouts as well as rationalizing product design
and engineering (Hyer and Wemmerloc 1984).
their
counterparts
in
older
industries
Producers of semiconductors,
like
automobiles,
routinely
like
use
standardized components and add end-process customization (Harvard Business
School
1986).
Computer-aided design integrated with flexible manufacturing
systems (FMS) transfer digitalized designs automatically to manufacturing tools,
allowing
firms
to
automate this combining of modularized designs with
designs (Skinner 1985; Jaikumar 1986; Meredith 1987).
new
Comparative international studies have added
the tendency of firms
in
certain countries to develop similar sets of strategies
As noted, the small size
and structures.
market apparently persuaded managers
to
of the domestic
Japanese machine
such as
them
There appears
number
large
a
machinery producers, emphasizing
textile
this
A survey
and specialization (Piore and Sabel 1984).
manufacturing
of
a
of 55 U.S.
oriented
organizations,
many
firms,
of
of
combination of efficiency
manufacturing plants also found that the Japanese tended
types
have been
to
industry (Jaikumar 1986). Countries
tool
seem to have produced
also
Italy
Japanese automobile
develop flexible manufacturing systems
during the 1950s and 1960s (Cusumano 1985).
similar trend in the
further observation, noting
a
and
Japanese
51
to establish
toward
more
similar
efficient,
continuous-type processing operations (Lincoln, Hanada, and McBride 1986).
Difficult to separate are the effects of simply being from a certain culture
or nation, from the tendency of managers
similar
environmental
answered
emphasize
technology.
technology
or
similar
It
also
might
is
different
actually
strategies
the
question
have and
for
dealing
must
exercise
with
in
a
kind to
still
options
be
to
particular
not clear to what extent the peculiar characteristics of a
constrain
the
ability
part by seeing
if
of
managers
to
rationalize
product
These questions can be examined
at
firms producing similar software products do so
in
development and production operations.
least in
that country to respond
Nonetheless,
conditions.
what degree managers
to
in
different manners, with strategies and processing organizations ranging from job
shops or laboratories to more factory-like models.
THE CASE OF LARGE-SCALE SOFTWARE DEVELOPMENT
Software production dates back to the 1950s, when computers were
first
designed that could store
memory
internal
in
controlling basic operations and a variety of applications.
refined over time,
come
to
(programs)
sets of instructions
the series of phases followed
in
As
has become
it
software development has
resemble that for "hard" products, consisting of planning,
detailed
design, construction (coding), testing, and servicing (maintenance) phases.
typically takes years and
hundreds
of
It
employees to develop and test programs
such as operating systems for large mainframe computers or real-time control
systems for factories or electric power plants.
designs,
designs
enormous costs on
than
10% for
requiring
software
programs over their
less
and lack or presence
consistency of documentation,
inadequate
lifetimes
Furthermore, the clarity of
future
extensive
modifications
Development
producers.
defects
impose
could
costs
or
software
for
were typically about 10% for planning and design,
about 15% for testing,
coding,
of
and
as
much
70% for
as
maintenance (Frank 1983).
As with hard manufacturing,
it
because there are numerous types
of
and applications.
These
into
fall
difficult to generalize
is
products for
a
about software
wide variety of computers
two basic categories:
"systems' software,
including operating systems, database management systems, telecommunications
and other related programs designed
to
operate the basic functions of the
computer or computer system; and "applications
above and implement specific functions
or word
processing.
Applications
like
'
programs, which operate
a level
production control, payroll analysis,
include
"packaged" software
designed by producers for general sale --and customized software
--
products
--
programs
tailored to meet the unique needs of an individual customer.
Firms,
software
or at
products,
least
facilities,
making
it
tend to specialize
possible,
theoretically,
in
particular
for
them
to
types
of
achieve
economies of scale or scope through standardization of tools, procedures, and
inputs.
other industries, the rigidity imposed by such "rationalization,"
In
resulting
in
a
reduced ability
technologies, or
tradeoff a
in
adapt to changes
in
product or process
market demands, has traditionally been seen as the major
accepts
firm
to
in
moving toward design standardization or factory
Software development may seem to be primarily
mass-production.
design and engineering activities for one-of-a-kind products,
companies make packages,
reproduction involving
appear that
software
environments.
a
systems
software,
programs,
Thus,
simple process of replicating code.
development organizations would
Reinforcing this notion
is
a
tendency
of
of
set
the sense that
in
or customized
a
resemble
with
might
it
job-shop
many programmers,
managers, and academics to view software development as more an art or craft
than an engineering or manufacturing activity suitable for discipline and control
(Brooks 1975; Shooman 1983; Hauptman 1986).
A problem with continuing
to
view
a
technology as
a
mere craft
that
is
such attitudes may impede progress in rationalizing the development process.
software
development,
improving
in
programming output per man-hour had
1960s,
in
about 40b
contrast to improvements
a
productivity
continues
One study concluding around 1980 estimated
agonizingly slow.
in
progress
year
(Horowitz
in
to
In
be
that increases
risen only about 5% annually since the
computer processing capacity averaging
and Munson
1984).
Despite
better
computer
languages, management methods, design techniques, and tools such as program
generators that automatically produce code from high-level designs, demand for
programmers
10%
in
in
the mid-1980s outstripped the supply of programmers by about
Japan and more than 20%
Observers
began
in
referring
the U.S.
to
this
(Zavala 1985;
supply-demand
Aiso 1985).
imbalance
"software crisis" as far back as 1969 (Hunke 1981; Frank 1983).
as
In fact,
the
U.S.
companies desiring to buy fully customized applications programs typically had
8
a
3- to 4-year wait (U.S.
Department
Commerce
of
backlog was 26.4 months (Kamijo 1986).
and small machines, continues
to
1984).
In
Japan, the typical
Further hardware development,
addition,
a
full utilization of
80286 and 80386 (Businessweek 1987).
Intel
serious impediment to improvements
TRW, and GTE
quality problems; data from IBM,
large
expand the demand for lengthy, complicated
programs, even for personal computers, delaying for years the
microprocessors such as the
in
in
In
individual productivity are
indicate that fixing bugs
in a
completed program during operation can cost 100 times that of detecting errors
in
the design stage (Boehm 1976).
In short,
the lack of programmers, rising demand for software, increasing
length of programs needed to utilize improved hardware capacity,
quality problems,
development.
have created
For a
firm
to
a
need to raise efficiency levels for software
build
the
software products of high quality and
simply to maximize
its
at
capability
produce
to
in
a
variety
of
lower costs than other companies, or
manpower and invested resources, should
competitive advantage
as well as
also provide a
the marketplace.
STRATEGIC OPTIONS FOR PRODUCT-PROCESS DEVELOPMENT
Determining
why managers make
the
organizations evolve from deliberate decisions,
and conflicting debate (Scott 1981).
and processes, there are options:
choices
is
a
But, certainly,
they
do,
in
designing new products
Managers can refuse
to
marketable products, which then might be mass-marketed.
to
development costs,
from mass sales, although,
if
they have
9
a
if
whether
complex subject of frequent
worry about parts
and procedures standardization, and encourage their engineers
even be insensitive
or
to design highly
These firms might
they could recoup large profits
shortage of personnel, they may
still
want
On the other hand, companies
maximize individual productivity.
to
that
choose to customize products might have even greater incentives to exploit
similarities in tools,
procedures, or parts across different product
lines.
Firms
pursuing standardization (package) or customizing strategies, but especially the
might thus want to standardize the development process and major
latter,
components
,
to
reduce costs and perhaps improve quality as well.
This can be illustrated as follows.
it
automobile,
an
is
machine
a
If a
tool,
a
program, there are basically three options:
from
a
customer needs
obtain
a
obtain
semi-customized product
department that modifies
a
sell
a
standardized
a fully
3)
(from
customize
a
software
customized product--
a
vendor or an
purchased standardized product).
product;
or
standardized or "packaged"
a
vendors should have three corresponding options:
2)
product, whether
semiconductor chip,
vendor or an in-house department; obtain
product;
a
1) sell a
a
It
in-house
follows that
customized product;
semi-standardized product.
Design managers can adopt one of several strategies to manage product and
process development.
Except for
a
Model-T type
of factory,
where
all
end
products and processes are fully standardized, the analogies appear to apply
both to software and hardware:
'
A
similar
typology
has
recently
Mintzberg 1987.
10
been
suggested
in
Lampel
and
Table
1:
STRATEGIES FOR PRODUCT-PROCESS DEVELOPMENT
FULL CUSTOMIZATION:
IMPLEMENTATION:
Customize inputs and development
process for each product
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
:
:
SEMI -CUSTOMIZATION/BATCH:
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
:
:
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?
:
SEMI-STANDARDIZATION/-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
:
:
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
:
:
11
The
idea
"software
creating
of
factories"
develop
to
standardized
procedures, tools, and program components reusable across different products
appears to have been
first
proposed by
Honeywell engineer
a
the idea
seemed too
difficult
reliable for
seemed
as
all
to
unworkable,
to
program modules that would be
create
One,
three problems:
to
software
write
characteristics of particular machines.
did
that
And
easily
it
specific
method was then available
third, no
program modules so they could be
Two,
depend on
not
it
and
efficient
types of systems and which did not constrain the user.
impossible
to catalog
due
largely
NATO
Conference members
Science Conference on improving software productivity.
criticized
at a 1968
found and reused. (Horowitz
and Munson 1984, citing Mcllroy 1976; McNamara 1987).
These were and remain serious problems, although many large software
design and overall development
producers have made progress
in
efficiency, as well as reusability
(Ramamoorthy 1984; Horowitz and Munson 1984;
Goldberg
1986).
California
(Eliot
factories,
and others
Several
facilitating
companies
and even the University
and Scacchi 1986) even claim
have launched
less
to
of
Southern
have established software
software
elaborate
rationalization
projects
Of particular importance to this research project
occurred
at
System Development Corporation (SDC),
software primarily for government contracts.
encountered
environment
several
would
a
(1)
Lack
of
an experiment that
producer
of
real-time
By the mid-1970s, managers had
common problems they hoped
solve:
is
discipline
a
and
more factory-like
repeatability
standardized approaches to the development process, with the result that
was continually
reinventing
products
and processes,
SDC
and not becoming
proficient at development or project control as managers wanted.
(2)
or
as
Lack of
an effective way to visualize and control the production process, as well as to
12
measure before the project was completed how
3)
well
code implemented
a
design.
Difficulty in accurately specifying performance requirements before detailed
design and coding, and recurrence of disagreements on the meaning of certain
requirements, or changes demanded by the customer.
management, and verification
design,
these from project to project.
the fact that
many
tools,
making
Little capability to
5)
4)
it
Lack of standardized
necessary to reinvent
reuse components, despite
application areas used similar logic and managers believed
that extensive use of off-the-shelf software modules would significantly shorten
Several managers and development
the time required for software development.
engineers decide to integrate a set of tools (program library, project databases,
on-line interfaces between tools and databases, and automated support systems
for
documentation,
verification,
management
system
policies
about 200 programmers
of
facility
The concept and system
California.
procedures
program design and implementation, and
for
centralized
a
in
standardized
with
etc.)
of
in
utilize
and
this
Santa Monica,
and methods SDC copyrighted
tools
under the name "The Software Factory" (Bratman and Court 1975 and 1977).
The SDC experiment was
not particularly successful.
raised at the
NATO
conference surfaced
difficult
reuse
code
to
facility,
leading
like
to
one
SDC;
project
on
for example,
different
This led to other problems.
different applications.
managers did not
from
at
The three problems
was extremely
computers
Most seriously,
giving up control of development efforts to
a
Programmers also tended
decline
to
in
the
flow
of
work
into
a
and
for
project
centralized
the
factory.
complain about unfamiliar, rigid standard, as well as
the difficulty and inelegance of reusing other people's code.
seems that
it
SDC managers attempted
to
In
retrospect,
impose the factory infrastructure
it
of
standardized tools and methods, and reusability goals, on both project managers
and programmers before software technology was refined enough
13
to
do this
Furthermore, architects of the factory failed to prepare managers and
easily.
programmers for the changes and
SDC
work flow
to adapt the
to the
new system.
gradually abandoned the effort during the late 1970s, although
to use
many
of the factory
it
continued
procedures and some of the tools (Cusumano and
Finnell 1987).
Perhaps the most significant outcome of the SDC experiment was that
reports from this company encouraged several Japanese software managers to
pursue software factory organizations or
control and reusability (Iwamoto and
Sakata
1985;
Shibata
concept into Japan,
highly
disciplined
1985
and
however.
Okada
1986).
least
at
1979;
SDC
greater efforts
NT&T
in
in
did
not
introduce the factory
Japanese experimentation with centralized and
programming environments
1969.
process
Matsumoto 1981; Mizuno 1985;
actually
experiment, going back to Hitachi's opening of the world's
software factory
at
NEC, Toshiba, and
1985 (Table 2).
14
predates
the
SDC
first facility ca'led a
Fujitsu followed in 1976-1977, and
Table
Year
Company
1969
Hitachi
2:
MAJOR JAPANESE SOFTWARE FACTORIES
Facility/ Project Name
Hitachi Software Works
Software Product Area
Operating systems and
Business Applications
1976
NEC
Software Strategy Project
Operating Systems,
Telecommunications,
Business Applications
1976
Numazu Factory
Operating Systems
Fuchu Software Factory
Real-Time Applications
Kamata Conversion Factory
Business Applications
Omori Software Works
Business Applications
Software Development Division Telecommunications
Hitachi 1979; Matsumoto 1981, 1984, 1987; Shimoda 1986; Fujino
1984 and 1987; Murakami 1987; Yoshida 1987; Toyosaki 1987.
Various articles and reports from U.S.
sources continue to find
approach to software development
rationalized
in
Japan than
the
in
more
a
U.S.,
other industries, Japanese firms may be again
indicating that,
in
software as
taking the lead
in
the process and organizational rationalizations necessary to
improve software production.
different Japanese
facilities
integrate
to
tools,
Four distinct trends seem to be emerging across
One,
is
construction
this
and processes
methods,
of
factory-like
large,
involved
in
to exploit
Japanese traditions
and individual attention
to quality
by developing software
of
planning or reporting systems that facilitate group programming and
methodology throughout the software
cycle.
life
software
teamwork,
Second are attempts
development.
discipline,
firms.
in
a
teamwork
Third are quality control
techniques designed to catch bugs early, before they become difficult to
And fourth
are national as well as
company
and productivity through reusability
of
and
tools
fix.
efforts to improve software quality
software modules
and automation
of
software production (code generation) (Kim 1983; U.S. Department of Commerce
1984;
Uttal 1984;
Businessweek 1984; Johnson 1985; Haavind 1986).
For example,
one U.S.
group touring Japan concluded that, while the
Japanese were not developing particularly unique or advanced software
tools,
they were using them more systematically then U.S. firms (Zelkowitz 1984).
1984 U.S. Department of
in
A
Commerce report suggested that U.S. firms have lagged
production management because they tend to view software more as
a
"craft"
than the Japanese:
in the development of software
and have encouraged their widespread use within their software
The Japanese have. .made impressive gains
.
tools
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 in its creativity
rather than a disciplined approach to software development as do the
Japanese.
factories to boost productivity ...
16
A 1985 headline
in
more effectively
the Electronic Engineering Times claimed the Japanese were
team or group approaches,
utilizing
unique team-oriented software
tools,
well
developing
as
Americans were becoming overly
while
dependent on small groups and highly
as
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 a
strict teamwork methodology through the complete life cycle of a computer
program -- from planning to design to maintenance, and without coding,
since high-level language-source codes are automatically produced from the
Until now, the Japanese have been hampered in their
design documents.
software development efforts by a lack of team-oriented tools.
The tools
borrowed from the United States simply do not fit the Japanese culture
because they put too much control in too few hands.
.
.
.
America, industrial software development is generally done in groups
are as small as possible to minimize the communication problems
among people. That makes the knowledge of each individual programmer a
critical factor to the success of any software-development project.
But. .that is just not tolerable in the Japanese culture. As a consequence,
the Japanese have had to perform basic research into software tools that
can be wielded by many hands at once. Nobody else was going to develop
group-programming tools for them."
In
that
.
If
national
technology,
differences are emerging
there
must
still
in
Japan,
as
opposed
a
the management of
other
reasons
be
explanation might be historical, such as
("hackers")
in
less
simply
particular
location.
One
prominent software craft culture
the U.S.,
to
than
a
or simply more emphasis of
Japanese companies on disciplined engineering and manufacturing practices.
one clear difference between Japan and the U.S.
is
But
the composition of their
software markets, which should affect managerial strategies and firm structures.
In
the U.S., about 60% of software sales
packages.
In
contrast,
only
about
in
5%
the early 1980s were standardized
of
Japanese
software
sales
were
standardized packages; 95% involved some degree of customization (Table 3).
One reason
for this difference
is
that microcomputers accounted for only about
17
10% of Japanese
Japanese
software
customers
also
sales,
compared
preferred
to
to
about
50%
in
the
U.S.
buy customized systems,
But
placing
tremendous demands on Japanese software producers.
Table 3:
SOFTWARE MARKETS COMPARISON
Japan
Overall Market Characteristics:
Total Market Revenues (Billion $)
Annual Demand Increases (%)
Annual Growth
in
Supply
of
Programmers
(%)
Ai!
All
Systems Software (%)
Applications Software
Sources:
(%)
as Suppliers of:
(%)
U.S. Department of Commerce 1984; Zavala 1985; Aiso 1986; Kamijo
1986;
Note:
26
(%)
Microcomputer Software/Total Market
All Systems Software
All Applications Software
Computer Manufacturers
USA
2.5
Typical Wait for Customized Programs (Months)
Product/Market Breakdown:
Integrated Systems Software
Package Software (%)
Custom Software (%)
(1984-85)
Businessweek 1987.
The figures
by the author from data in the
Systems
software
includes operating systems,
listed sources.
telecommunications
systems, and
management
systems,
database
market is
the
Japanese
software
programs.
The
of
related
size
bundled
software
usually
sold
systems
is
underestimated because
hardware.
with
cited are estimates
U.S. companies, as well as the Japanese, have continued to develop better
1981; Willis 1981;
1986).
This
is
such
use terms
and programming environments (Stucki and Walker
methods,
software tools,
Boehm
Howes 1984; Griffin 1984; Hoffnagie and Beregi
1984;
SDC and
the case even though
as
appear
and
"factories"
other American firms no longer
prefer
to
"laboratory" or "systems development center," or no label at
their software organizations
to identify
which software
(McCue
Hunke
1978;
1981).
and standardization among people, systems, functions,
refer to
to
all,
as
But another question
have truly pursued
facilities
such
designations
is
a
level of integration
tools,
methods, and inputs
sufficient to distinguish their operations from other large facilities with minimal
standardization and integration.
THE SURVEY
The published descriptions and stated objectives
Factory
project
thinking
commonly
about
(Bratman
criteria
thought
to
and
to
Court
compare
exist
manufacturing operations:
1975
at
and
software
for
least
1977)
for the
SDC Software
provided
a
basis
along
a
spectrum
facilities
engineering
large-scale
process standardization and control;
SDC espoused
to store modules, documentation,
a
a
The basic
centralized program library
and completed programs;
track production-management data;
working on different parts of
consisted of
and
and inputs
standardization and control (emphasis on reuse of software modules).
factory infrastructure
for
a
central database to
standardized project databases for groups
program; an interface linking various
tools
and
databases; and a uniform set of procedures for specification, design, coding,
testing,
and
documentation.
It
was
decided
constitute the core of the survey, to see
19
if
that
these
current managers
variables
in
should
the U.S. and
Japan were also emphasizing
a similar
type of infrastructure.
In addition,
since
an objective of the factory strategy was to produce standardized components
for reuse,
several questions were composed about reusability.
Major software producers
literature surveys
and
of
lists
Japan and the U.S. were identified through
in
and sent
software producers,
containing eight core questions plus more than
a
a
questionnaire
dozen others, many
experimental nature, to provide supplementary data.
For the core questions,
management were asked
at their facilities
answer.
each
product area
divisions
in
on
a
rank the emphasis of themselves and other managers
to
scale of
to 4
(see Table 4), as well as to comment on
at
tools to develop,
least
tools
the facility or
since software practices often differed enormously
internal
needs.
The sample was
limited
departments making products that usually require large amounts
at
recent
among
diversified or large firms, and some diversity seemed useful to meet
different market or
and
in a
managers responsible for production
Questionnaires were directed to managers
level,
an
Optional questions also
requested performance measures such as actual rates of reused code
sample year.
of
to
facilities
or
of people, time,
and which might therefore provide incentives for managers
on the facility level to seek similarities and common components or
across
different
operating
projects:
minicomputers ("systems" software)
;
for
mainframes
and real-time applications programs, such
for factory control or reservations systems
were further broken down
systems
("applications" software).
into telecommunications
or
as
These
software (applications and
systems were combined because of the smallness of the sub-sample); commercial
operating systems; industrial operating systems; real-time control applications;
and general business applications.
All
the Japanese firms contacted
firms contacted completed the survey.
filled
out the survey; about 75% of U.S.
To check answers, two managers
20
at
each
firm or facility either responsible for overall software engineering
management
or with sufficient experience to present an overview of practices for the entire
facility
were asked
to
completed surveys for each type of
usually differing by only
About
respond.
a
the
half
facility; the
companies
returned two
answers were extremely
few percentage points, and were averaged.
similar,
Other
answers represent single responses."^
Comments from the respondees,
partial correlation analysis,
not
particularly
useful
revealed that
for
measuring
engineering and manufacturing lines.
emphasis
on
standardization
description, and coding.
It
of
visits
site
many
and interviews,
of the
as
well
as
non-core questions were
"rationalization"
along
large-scale
For example, three questions asked for
languages
for
high-level
design,
module
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
languages for this purpose, which made
it
in
using
unfair to U.S.
English-based
firms to use this
question; and coding languages were often determined by customers.
A question
about top-down
tended to
contrast with
layers.
a
design
was discarded because emphasis on
more factory-type process of combining new and old code
in
Similarly, questions about emphasis on high-level abstraction or layering
were discarded because not everyone knew how
A
this
to interpret these.
factor analysis procedure with varimax rotation confirmed that the eight
process and reuse questions constituted two orthogonal factors, with eigenvalues
^ In
the case of Toshiba,
a
single large facility
(approximately 2500
programmers) had different departments producing both systems and
applications programs using identical procedures and tools, and the manager
responsible for technical development, Dr. Yoshihiro Matsumoto, submitted
one set of answers and asked that they be counted twice, under both
systems and applications facilities.
21
of 3.46
and 0.93; these explained
each factor, the variables with
summed and used
well
as
to
a
88.6% of the variance
if
product type or country origin
Tables 5 and 6 reflect scores for each dimension on
maximum scores
of 4 for
and U.S. responses
For
average Japanese and U.S. scores, as
of
significantly correlated with the process and reuse scores."^
in
the answers.
strong loading (approximately 0.5 to 0.8) were
to test differences in the
test
in
Table
each variable.
7
a
facility
were
The data reported
basis of 100%,
with
compares the average Japanese
and reuse dimensions.
to the process
the
Table 8 summarizes
the results of one-way analysis of variance tests to determine the effects of
product types or country of origin on the scores reported for the process and
reuse dimensions.
Tables 9 through
the Japanese and
U.S.
It
compare actual reuse rates reported by
and analyze correlations with emphasis on
facilities,
reusability, types of products,
11
and country
of origin of the reporting facilities.
should be noted that, while the Japanese sample size seems small, the
surveyed firms account for the vast majority
Japan.
NEC
The top three Japanese firms ranked by software
($507 million),
ranked fourth
($560).
of software written
in
Fujitsu
($389 million),
sales
and Hitachi ($331
and sold
in
1986 were
NEC
million).
the world, behind IBM ($5,514 million), Unisys ($861), and
The Japanese
sales
in
DEC
figures considerably understate actual software
development, because Japanese firms included ("bundled") systems software with
mainframe and minicomputer hardware prices.
The
hardware
sales,
operations
corresponds
roughly
to
size of systems
however.
software
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
^ This procedure is recommended
by Comrey 1973 and Tabachnick and
sellers of
as a simple data reduction technique
1983.
Comrey suggested that
loadings of .55 (explaining 30% of the variance) were "very good," and .63
Fidell
(40% variance) or over "excellent."
22
were Toshiba
minicomputers
Software,
(Kiriu
subsidiaries
and
Consultants
NEC
1986).
Hitachi
of
Software
software
and Mitsubishi
including
Nippon
Engineering
(Hitachi),
as
and
($475)
of software included in this
NEC,
Hitachi
well
Business
as
NEC
Information Systems, and Nippon Electronics Development (NEC)
Since the sample
is
relatively
results of this analysis must be considered
at
($620),
Other large Japanese producers
(Datamation 1987).
survey were
Fujitsu
($766),
facilities
in
in
absolute numbers,
more suggestive
the U.S. and Japan,
23
small
the
of patterns existing
rather than definitive.
AND SAMPLE OUTLINE
SAMPLE:
Table 4: SURVEY
n = 38 (17 Japanese, 21 U.S.)
SURVEY PARTICIPANTS:
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
SURVEY QUESTIONS:
Process Standardization and Control (100% = Score of 201
1)
2)
3)
A centralized program library system to store modules and documentation.
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.
Project data bases standardized for all groups working on the same
product components, to support consistency in building of program
modules,
4)
5)
configuration
management,
documentation,
Components Standardization and Control (100%
6)
7)
8)
maintenance,
and
potential reusability of code.
A system interface providing the capability to link support tools, project
data bases, the centralized production data base and program libraries.
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 to facilitate
standardization of practices and/or division of labor for programming tasks
and related activities.
=
Score of 12)
Formal management promotion (beyond the discretion of individual project
managers) that new code be written in modular form with the intention
that modules (in addition to common subroutines) will then serve as
reusable "units of production" in future projects
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.
Monitoring of how much code is being reused
Additional
:
Actual percentage of reused code
24
in
a
recent sample year
Table
5:
SUMMARY AND RANKING OF PROCESS SCORES
Note: Japanese Facilities indicated by *
COMPANY/FACILITY
Telecommunications Software
32=100%
Table
6:
SUMMARY AND RANKING OF REUSE EMPHASIS SCORES
Note: Japanese Facilities indicated by *
COMPANY/FACILITY
Telecommunications Software
*NEC Switching Systems
*NT&T Applications
AT&T Bell Labs (Applications)
*NT&T Systems
12=100%
100.0
91.7
58.3
50.0
Commercial Operating Systems
*NEC Fuchu Factory
*NEC Software, Ltd.
IBM-Endicott
Hitachi Software Works
Control Data
Fujitsu Numazu Factory
Sperry/Unisys
Data General
IBM-Raleigh
95.8
83.3
66.7
66.7
58.3
58.3
45.8
41
.
7
16.7
Industrial Operating Systems
Toshiba Software Factory
Boeing
100.0
25.0
Real-Time Control Applications
Toshiba Software Factory
SDC/Unisys
TRW
Sperry/Unisys
Hughes Aircraft
Boeing
Honeywell
Draper Laboratories
100.0
91.7
75.0
66.7
45.8
25.0
16.7
8.3
General Applications
Nippon Systemware
NEC
Mita
Nippon Business Consultants
Fujitsu Kamata Software Factory
Martin Marietta/MD
NEC
Information Services
Control Data
Hitachi Omori Works
Hitachi Software Engineering
EDS/GM
Nippon
Electronics Development
Cullinet
DEC (Education Software)
Computervision
Martin Marietta/Denver
91.7
89.6
83.3
79.2
79.2
75.0
75.0
66.7
62.5
50.0
50.0
48.6
25.0
25.0
25.0
26
Table
7:
COMPARISON OF AVERAGE JAPANESE AND U.S. SURVEY SCORES
n = 17
Dimension
Process (Std. Dev.)
Reuse (Std. Dev.)
Table 9:
n = 9
COMPARISON OF AVERAGE JAPANESE AND
U.S.
REUSE RATES
DISCUSSION
The survey
variations
in
reusability
One
appear to support two hypotheses.
is
that
the structures of organizations (as measures by the process and
variables)
reflect
development.
process
largely
results
a craft,
different
Despite
potential
art, or "job-shop"
making similar types
of
strategies
of
managing product and
software
development as
type of operation, some managers
at facilities
products clearly placed more emphasis on control and
standardization of processes and inputs.
as high as 100% (Tables 5
ranking within
views
for
and
6).
It
Scores ranged from as low as 8.3% to
may be
difficult to distinguish facilities
few percentage points; but companies on opposite ends of the
a
spectrums that emerged from the survey rankings --for example, Toshiba versus
Draper Laboratories
different and
in
in
real-time applications software development -- must be
instructive ways.
Moreover,
confirmed that product types as defined
in
this
the analysis of variance tests
paper had no significant impact
on where managers scored on either dimension studied.
rationalizations
strategies
Process and components
corresponding to what Table
1
defined as
"semi-
customizationZ-standardization" or "standardized customization" occurred across
different types of producers.
A second hypothesis supported
in
part by the data
is
that, as indicated in
various sources, there are some significant national differences between the U.S.
and Japan
in
how software engineering
is
being managed.
The
t-tests indicated
that average responses on the process variables -- 75.1% for the Japanese and
69.8% for the U.S.
that tool
sets
--
were not
were basically
statistically different (Table 7).
similar,
as
This confirms
noted by the Kim survey.
It
also
provides evidence against the notion that U.S. managers are less concerned with
process control and standardization than Japanese managers.
On the other hand, the Japanese
did score significantly higher on reuse
29
--
emphasis
79.0% compared to 46.2% for the U.S.
reuse rates were also significantly higher
in
Actual reported
facilities.
Japan
(37% compared to under
14%), as well as significantly correlated with managerial emphasis as reflected
the reuse variables (Tables 9 and 10).
The
analysis of variance tests confirmed
that, while country of origin significantly affected the reuse score
reuse rates,
in
and actual
product type was not significant (Tables 8 and 11).
other
In
words, Japanese applications producers, who clearly are marketing customized
products, as well as Japanese systems producers, who supposedly are selling
unique basic software, both tend to emphasize reusability.
Development Corp. /Unisys, and to
TRW,
But,
also
In
the U.S., System
lesser extent Martin Marietta/Maryland and
a
appeared to be following this reusability or customizing strategy.
suggested earlier, particular features of the market
as
in
Japan, which
almost universally has demanded customized products, perhaps encouraged firms
to
pursue standardization
and
customization
strategies
on
relying
the
construction of reusable components.
Over
time,
if
not
at
spectrum may become able
similar
in
to
the
present,
facilities
at
the
upper end
of
the
produce customized (or semi-customized) products
performance to those products (packaged or customized) made by
firms at the lower end of the spectrum but at
a
lower cost,
due
to savings
from process management or elimination of having to "reinvent" components.
This should provide an important competitive advantage,
as
it
has
industries such as semiconductors, machine tools, and even automobiles.
in
If
other
some
firms deemphasize discipline and cooperation while focusing essentially on the
individual engineer, the individual tool, or the final product, then they
be fully
developing
--
that
is,
compared
to
some
of
their
may not
competitors--
orqanizational capabilities to maximize the performance of their technical people
and invested resources.
30
To an extent,
a
technological and managerial change
in
focus from the
individual and individual tools and techniques, to the organization and process
management
--
reflects
a
movement one might expect with any product and
process as firms accumulate experience
demands become better defined,
industry.
least
design and production, and as market
compared
But the software example suggests
constrained by the nature of
passage of time.
principally
at
in
SDC,
a
it
is
to the earliest
not a
days of an
movement necessarily
technology or product types, or by the simple
Case studies currently
Hitachi, Toshiba,
NEC, and
in
progress of individual firms,
Fujitsu, will examine in detail the
process of strategy formulation and organizational implementation for managing
this
technology more effectively.
31
APPENDIX TABLES
VARIMAX ROTATED FACTOR MATRIX
Variable/Factor
Process
Reuse
library
central database
project database
interface
0.72695
0.60496
0.68368
0.63757
0.46309
0.33476
0.03058
0.37010
-0.00545
0.40151
0.26326
0.35033
0.13917
uniformity
design for reuse
reuse promotion
monitoring of reuse
0.78735
0.81375
0.71125
EIGENVALUES AND PERCENT OF VARIANCE
Variable
"A Software Development Environment
.,
Computer (June 1984), 30-44.
Improving
for
Productivity,"
BRATMAN, Harvey, and Terry COURT (System Development Corporation), "The
Software Factory," Computer (May 1975), 28-37.
"Elements of the Software Factory: Standards, Procedures, and 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.
Essavs
in
Software
to Write 'World-Class' Software," 27
February
,
BUSINESSWEEK, "Japan's Push
1984, 96-98.
BUSINESSWEEK, "The
Free-for-AII Has Begun,"
May
11
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.
,
COMREY,
A. L.,
A
First
Course
in
Factor Analysis
,
in
American Business,
New York, Academic
Press,
1973.
CUSUMANO,
Management
The Japanese Automobile Industry: Technology and
and Toyota, Cambridge, MA, Harvard University Press,
Michael A.,
at Nissan
1985.
CUSUMANO,
Michael A. and David E. FINNELL, "A U.S. "Software Factory"
Experiment:
System Development Corporation" M.I.T Sloan School of
Management Working Paper #1887-87, 1987.
.
DATAMATION,
15
June 1987, 28-32.
Lance B., and Walt SCACCHI, "Towards
Factory," IEEE Expert Winter 1986, pp. 51-58.
ELIOT,
Knowledge-Based System
a
.
FRANK, Werner
L., Critical Issues in Software,
New York, John
Wiley & Sons,
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
GOLDBERG,
,
Reading, MA, Addison-Wesley, 1977.
R., "Software Engineering:
33
An Emerging
Discipline,"
IBM Systems
Journal 25 (1986), 334-353.
GRIFFIN, William G., "Software Engineering
in
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).
HAUPTMAN, Oscar, "Influence
Communication and Performance:
of
Task Type on the Relationship Between
The Case of Software Development," RtrD
Management 16 (1986), 127-139.
HAYES, Robert H. and Steven C. WHEELRIGHT, "Link Manufacturing Process
and Product Life Cycles," 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 (Hitachi Ltd.), Kanagawa koio 15
nen no avum (15-year history of the Kanagawa Works), Hitachi Ltd. Kanagawa,
i
,
1979.
HOFFNAGLE, G.F., and W.E. BEREGI, "Automating
Process," IBM Svstems Journal
HOROWITZ,
Ellis
and John
.
B.
the Software Development
24 (1985).
MUNSON, "An Expansive View
Software," IEEE Transactions on Software Engineering
,
of Reusable
SE-10 (1984), 477-486.
R., "Managing Software Development Projects for Maximum
Productivity," IEEE Transactions on Software Engineering SE-10 (1984), 27-49.
HOWES, Norman
,
HUNKE,
H.
,
ed.
,
Software Engineering Environments Amsterdam, North-Holland,
,
1981.
L. and Urban WEMMERLOC, "Group Technology and Productivity,"
Harvard Business Review (July-August 1984), 140-149.
HYER, Nancy
Kanji and Masashi OKADA (NEC), "Purojekuto kanri no tsuru"
(Project control tools), Joho shori (Information processing), 20 (1979).
IWAMOTO,
JAIKUMAR,
A Managerial
Ramchandran, "Flexible Manufacturing Systems:
Perspective," Harvard Business Schoo Working Paper #1-784-078 (January 1984)
l
,
"Postindustrial Manufacturing,"
Harvard Business Review (November-
December 1986), 301-308.
JOHNSON,
(11
R. Colin, "Tools for Software Factory," Electronic Engineering Times
February 1985), 1, 63.
KAMIJO, Fumihiko, "Information Technology
34
Activities in the
Japanese Software
Industry," Oxford Surveys
in
Information Technolociv. Vol. 3, 1-35 (1986).
KIM, K.H., "A Look at Japan's Development
Technology," Computer (May 1983), 26-37.
KINNUKAN,
of
Software
Paul, "Flexible Systems Invade the Factory." High
Engineering
Technology (July
1983), 32-43.
(The status
Hiroshi, Sofutouea sanvo no jitsuzo
industry), Tokyo, Nikkan Shobo, 1986.
KIRIU,
the
of
software
LAMPEL, Joseph, andHenryMINTZBERG. "Customizing Strategies. .and Strategic
.
Management," McGiil University Working Paper, March 1987.
Paul R., and Jay W. LORSCH, Organization and Environment:
Differentiation
and Integration Boston, Harvard Business School, 1967.
Managing
LAWRENCE,
,
LINCOLN, James
Structures
in
Quarterly, 31
MATSUMOTO
R., Mitsuyo
Japanese and
HANADA, and Kerry MCBRIDE,
U.S.
Manufacturing,"
"Organizational
Administrative Science
(1986): 338-364.
Yoshihiro
(Toshiba),
"Management
of
Software
Industrial
Production," Computer (February 1984), 59-71.
"A Software Factory: An Overall Approach to Software Production"
Peter Freeman, ed.. Software Reusability (IEEE Tutorial, 1987).
in
,
,
et al.,
"SWB System:
Engineering Environments
,
A Software Factory," in H. Hunke, ed.. Software
Amsterdam, North-Holland, 1981.
McCUE,
G.H. "IBM'S Santa Teresa Laboratory:
Architectural
Program Development," IBM Systems Journal 17 (1978),
Design
for
.
MclLROY,M.D., "Mass -Produced Software Components, "inJ.M. Buxton,
and B. Randell, Eds., Software Engineering Technigues: 1968
on Software Eng neering, 1976.
NATO
Naur,
Conference
P.
i
McNAMARA, Donald
(General Electric), "Software Factories."
Institute of Graduate Studies, Lowell, MA, 2 February 1987.
Lecture,
Wang
MEREDITH,
J., "The Strategic Advantages of New Manufacturing Technologies
for Small Firms," Strategic Management Journal 8 (1987), 249-258.
,
MIZUNO, Yukio (Senior Vice-President, NEC Corporation). Interview 9/26/85.
MONDEN,
Yasuhiro, Toyota Production System
Engineering and Management Press, 1983.
,
Norcross,
Ga.,
Industrial
MURAKAMI,
Ltd.
Noritoshi, Manager, Software Development Planning Office, Fujitsu,
Interview, 1 September 1987.
NATIONAL RESEARCH COUNCIL, The U.S. Machine
Defense Industrial Base
,
Tool Industry and the
Washington, D.C., National Academy Press, 1983.
35
PALFRAMAN,
Diane, "FMS:
(March 1987), 34-38.
Too Much, Too Soon," Manufacturing Engineering
Michael J. and Charles F. SABEL, The Second
New York, Basic Books, 1984.
Possibilities for Prosperity
PIORE,
Industrial
Divide:
.
PORTER, Michael E., Competitive Strategy: Technigues for Analyzing Industries
and Competitors, New York, The Free Press, 1980.
Creating and Sustaining Superior PeKormance
Competitive Advantage:
,
New York, The Free
RAMAMOORTHY,
tives,"
Press,
C.V.,
.
1985.
et al.,
"Software Engineering:
Problems and Perspec-
Computer (October 1984), 191-209.
SABEL, Charles, et al., "How to Keep Mature
Technologv Review (April 1987), 27-35.
SAKATA, Kazushi (Former Deputy
Industries
Innovative,"
General Manager, Hitachi Software Works),
Interview 9/10/85.
SCHMENNER, Roger
Situations
Production/Operations Management:
W.
Chicago, Science Research Associates, 1984.
,
SCHONBERGER,
Richard J., Japanese Manufacturing Technigues
Free Press, 1982.
SCOTT, W. Richard, Organizations:
Engiewood
Cliffs,
SHIBATA,
Kanji
Concepts and
,
NJ,
Prentice-Hall,
Rational.
1981.
Natural,
,
New York, The
and Open Systems,
(Manager, Engineering Department, Hitachi Software Works)
Interview 9/19/85.
SHIMODA, Hirotsugu, Sofutouea
kojo (Software factories), Tokyo,
Toyo
Keizai
Shimposha, 1986.
SHOOMAN,
Management
Martin,
,
Software Engineering:
New York, McGraw-Hill,
SKINNER, Wickham, Manufacturing:
York, John Wiley
£,
Design. Reliability, and
1983.
The Formidable Competitive Weapon
,
New
Sons, 1985.
STUCKI, Leon G. and Harry D. WALKER (Boeing Computer Services), "Concepts
and Prototypes of Argus," in HUNKE, H., ed.. Software Engineering Environments Amsterdam, North-Holland, 1981.
,
.
TABACHNICK, Barbara
G., and Linda S. FIDELL, Using Multivariate Statistics
New York, Harper and Row,
.
1983.
TOYOSAKI,
Division,
Kenshiro, Manager, Videotex Department, Software Development
Nippon Telephone t Telegraph, Interview 3 September 1987.
U.S. DEPARTMENT OF COMMERCE, A Competitive Assessment of the U.S.
Software Industry Washington. D.C., International Trade Administration, 1984.
.
36
UTTAL,
Bro, "Japan's Persistent Software Gap,
"
Fortune (15 October 1984)
,
151-
160.
WILLIS, R.R. (Hughes Aircraft), "AIDES: Computer Aided Design of Software
Systems II," in HUNKE, H., ed.. Software Engineering Environments Amsterdam,
North- Holland, 1981.
,
WOODWARD,
Joan,
Industrial
Organization:
Theory and Practice
.
London,
Oxford University Press, 1965.
ed.. Industrial Organization:
University Press, 1970.
,
Behavior and Contro l,
London,
Oxford
YOSHIDA, Tadashi, Deputy Manager, Ouality Assurance Dept., Software Division,
Numazu Factory, Fujitsu, Ltd. Interviews, 9/24/85, 7/31/86, 9/7/87.
ZAVALA, A., "Research on
Development Workers,
"
Factors that Influence the Productivity of Software
SRI International (June 1985).
ZELKOWITZ, Marvin et al., "Software Engineering Practices
Japan," Computer (June 1984),
37
eoi
in
the US
and
/'T
1813
^
109
TD6D ODM
"=13^
107