(UBRARIESI
O
X
^ Of rt^.
CENTER FOR COMPUTATIONAL RESEARCH
IN ECONOMICS AND MANAGEMENT SCIENCE
Factory Concepts and Practices in S oftwa re
Development: An Historical Ove rv ew
i
Michael A.
Cusumano
Mitsubishi Career Development
Assistant Professor of Management
Working Paper #3095-89 BPS
Version: December 5, 1989
SLOAN SCHOOL OF MANAGEMENT
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
CAMBRIDGE, MASSACHUSETTS 02139
ALFRED
P.
Factory Concepts and Practice s in Softwa re
Development: An Historical Ove rview
Michael A.
Cusumano
Mitsubishi Career Development
Assistant Professor of Management
Working Paper #3095-89 BPS
Version: December 5, 1989
Sloan School of Management
Massachusetts Institute of Technology
Cambridge, MA 02139
(617) 253-2574
JAN
1
2
/<iC)o
ABSTRACT
This paper reviews the introduction of factory concepts and practices,
based on tools and methods from the evolving
major software producers,
label to
Hitachi,
in
Corporation
in
control
software
in
Japan, as well as System Development
The other U.S. firm discussed
without adopting the factory label,
and
or approach to software development:
facilities
NEC, and Fujitsu
the U.S.
softwaro engineering, at
particular those that explicitly adopted the factory
describe their software
Toshiba,
field of
development,
in detail is
IBM, which,
introduced numerous measures to organize
especially
basic
software.
The paper
emphasizes that the difficulty of the technology, shor-tsges of skilled engineers,
and large-scale projects have encouraged producers
or
factory-like
in
managing
a
series
of
and more suitable
craft approach to development.
to a loosely
become more systematic
projects,
characteristics of the technology and the industry
difficult to control
to
evm
though
some
havp maHe software seem
structured project-centered or
INTRODUCTION
When analyzing the appearance
new technology and the birth
of a
of a
historical perspective useful to refine
new industry, managers should find an
strategies both for competitive positioning and technology management.
example, what and when might concepts or practices le?)rned
managing
a
particular technology apply
have evolved beyond an
remained
loosely
individuals
in
a
"craft"
or job-shop mode,
modes
of engineering
and manufacturing.
thus
made
variety
a
wide
of
Many industries
settings?
by
condnrted
and
expensive,
structured,
other-
one industry for
where product design and production
phase,
initial
in
in
For
highly
skilled
more --ystematically organized
to
Product and piocess innovations have
sophisticated
goods
consumers by systematically dividing large tasks
inlo
available
to
masses
of
and less-skilled
'^inallei
operations, establishing standard procedures and controh to help de-skill tasks,
among different
individuals,
apportioning
labor
equipment
mechanize or automate aspects
to
of
building
desinn
tools
and
and production,
other
and
creating designs based on reusable or interchangeable components (Woodward
1965;
Chandler 1977; Abernathy 1978; Hounshell 19841.
Some researchers, however, have argued that sfiuctured engineering or
factory processes of this sort have become possible
oiii^'
rate of product innovations or changes decline to
tJT-^
in
industries
when the
where firms can
point
concentrate on process innovations related to cost reductions (Abernathy and
Utterback 1978,
1982).
This
requirement suggests that not
all
products or
development processes are suitable for factory-oriented design and production
systems,
even though managers may have strong incentives to pursue more
efficient
modes
of
operations
compete
to
effect iN'-^^ly,
especially
in
new
industries with complex technologies.
The subject
of
this
article
is
how major producers
1
of
software
have
attempted to push forward the state of
new technology and thereby move
a
software from loosely organized craft or job-shop modes of development to
more
structured
management.
The number
and 1980s,
process
of software
pioneered
introduced
explicitly
automated
enginenring
of
producers
is
and
production
too large to cover
firms
all
This discussion, therefore, focuses on companies that, between the
adequately.
1960s
and
a
factory
development operations:
programming for commercial
large-scale
concepts
in
practices
(IBM)
or
software-
their
into
Business Machines
International
Development Corporation (SDC)
and
sale
and System
the U.S., and Hitpchi, Toshiba, NEC, and
Fujitsu in Japan.
THE SOFTWARE PROBLEM
Writing
computers,
software
first
--
instructions
introduced
required
commercially
to
programmable
operate
during tho
1950s
--
has
plagued
engineers, managers, and customers since the beginning of the computer era.
The development process consists
detailed
requirements analysis,
program design, coding, testing, and
repairs referred to as maintenance.
than
of
sequential,
and
often
system design,
installation, as well as redesign or
Yet these phases atp usually more iterative
unpredictable
in
time
and
because
costs,
the
productivity of individual programmers tends to vary enormously and depend on
elements
difficult
for
management
to
control,
such
as
personal
talent
and
experience with particular applications.
Software producers thus encounter budget and schedule overruns as the
rule
rather
than
the
exception,
especially
when attempting
complex systems with many components for the
of software design
first time.
and programming, exacerbated by
a
to
build
Tho sheer
demand
for
large
difficulty
programs
rising faster than the supply of software engineers,
the "software crisis" as
to as
Despite years of advances
in
ago as 1969 (Hunke 1981,
long
in tools
Ird to a situation referred
Frank 1983).
(specialized programs and databases that aid
the production of other software), design and programming techniques, and
software has
products themselves,
remained
most vexing challenge to
a
concerned, with many problems that plagued pioneers
1980s.
In fact,
continuing difficulties
and practitioners
more
like
alike to
an art or
a
in
still
all
persisting through the
software have IpH academic researchers
argue that writing software
and may forever remain
i<^
craft rather than evolve into a technology suited to the
precise controls of "true" scientific, engineering,
inrinufacturing disciplines
oi-
(Brooks 1975; Shooman 1983; Hauptman 1986; Mahoney 1988).
Indeed,
software appears to have characteristic
that
engineering or factory operations difficult to introduce
make conventional
--
little
product or
process standardization to support economies of scale, wide variations
contents
and
work
cumbersome tasks
flows,
difficult
What
or automate.
counterproductive to divide,
de-skill,
producers have struggled
contend with constant ovolution
to
process technology as well as
in
is
and
in
sometimes
more,
in
project
software
product and
customer requirements, often for programs with
unique or tailored features.
To manage such
a
complex technology
software producers have resorted to
remain
flexible
in
structure and
a
such
in
n
rlynamic industry,
simple solution:
processes,
hiring
as
They have
many
tried to
many experienced or
talented programmers as possible and relying on small, integrated teams -- as
job-shop or craft production
in
other industries.
in
This approach takes advantage
of the greater productivity usually associated with experienced personnel,
and
reduces coordination or communications problems within the project, as well as
the need to divide labor and tasks too rigidly (Borum 1987).
Job-shop or craft practices have worked
essential in the early days of the industry,
well
when
all
in
software and
proved
products seemed new and
changing, and when programs remained small, reflecting hardware limitations.
But the software market continues to exhibit demand exceeding the supply of
programmers and managers, tight budgets and short schedules, customer
skilled
requirements for unique features as well as low prices and high
reliability, long-
term maintenance costs surpassing those of new design work, and increases
in
the length and complexity of programs as hardware improves (U.S. Department
of
Commerce
Schware
1984;
1989).
incentives for managers to reduce
skill
These conditions
requirements
have created
huge
anfl systematically recycle
key factors of production (methods, tools, procedures, engineers, components)
as
many
projects as possible
(Ramamoorthy
et al.
19r>.1;
Jonns 1986;
in
Freeman
Thus, as the industry has evolved, loosely strurhired processes and craft
1987).
organizations have become inadequate to manage softw-ire development, at least
for
many producers.
EARLY FRUSTRATIONS AND FACTORY CONCEPTS
The
tools,
earliest public proposals for the introduction of factory-type methods,
and organizations
to software
development appeared
in
the late 1960s, as
outgrowths of comparisons of programming with established engineering and
manufacturing processes.
An engineer
at
General Electric, R W. Bemer, made
numerous
suggestions
develop
"software factory" to reduce variability
through
a
standardized
that
tools,
culminated
a
in
a
1968
computer-based
paper encouraging GE to
in
programmer productivity
interface,
database useful for financial and management controls.
computer business
in
1970
and
an
historical
GE's exit from the
ended the company's cnmmitment
to
commercial
hardware and software production, although Bemer provided for the industry the
working definition
first
what might constitute
of
[A] software factory should be
upon and controlled by
a
a
software factory:
a
programming etivironment residing
Program construction, checkout
computer.
and usage should be done entirely within
environment, and by
this
environment...
A factory ... has
measures and controls for productivity and quality.
Financial records
using
the
contained
tools
in
the
Thus management
are kept for costing and scheduling.
estimate from previous data...
Among the
able to
is
tools to be available
the
in
environment should be: compilers for machine-independent languages;
simulators,
instrumentation devices, and test cases as accumulated;
documentation tools
--
automatic flow-charters, text editors, indexers;
accounting function devices;
linkage and
(and many others) (Bemer 1969:
filters
code
interface verifiers;
1626-1627).
While Bemer focused on standardized tools and controls. Dr. M.D. Mcllroy
of
AT&T emphasized
another factory-like concept
code when constructing new programs.
In
Conference on
Mcllroy
software programs
into
as
building
blocks
computers (Mcllroy 1969).
seemed too
reliable
for
difficult
all
to
types
argucfl
that
NATO
the
Science
division
of
modules offered opportunities for "mass production"
producing parameterized families
serve
systematic reusability of
an address at a 1968
He then used the term "factory"
methods.
to
engineering,
software
--
for
the context of facilities dedicated
software parts or routines that would
tailored
programs
reusable
across
different
But reception to Mcllroy's ideas was mixed:
create
of
of
in
program modules that would be
systems
and
which
did
not
efficient
constrain
the
It
and
user.
Software was also heavily dependent on the specific characteristics of hardware.
Nor did anyone know how
to catalog
program modules so they could be easily
found and reused (Horowitz and Munson 1984).
the
term
factory
had
arrived
software
in
Nonetheless, by the late 1960s,
and
was
being
associated
with
computer-aided tools, management control systems, as well as modularization and
reusability.
The comments
managers that had
of
to
Bemer and Mcllroy reflected the growing frustrations
of
One
of
oversee the production of large-scale programs.
the most comprehensive discussions on software engineering,
useful
treatment,
was
a
NATO
1968
Science
Managers and academics from several countries
always began with the first step
--
Committee
agree'-!
and
a
still
conference
most
report.
that Hiffjcuities almost
determining system requirements.
Because
customers often did not know exactly what type of software they would need,
designers could not be certain what type of system to build.
led to other difficulties as a project
progressed:
The
initial
This uncertainty
cost and schedule
estimates had to be changed, while programming modifications introduced during
system development usually
led to configuration,
testing,
documentation, and
the
NATO
committee thought
it
problematic to manage large projects,
given
huge variations
programming
maintenance errors.
In
addition,
communication problems within projects,
productivity,
measurement standards, rapid growth
in
demand and
lack
size of
in
of
inherently
tools,
lack of
programs, lack of
standardization, few reusable components, and enormous maintenance costs as
systems required repairs or changes over time (Table
A comparison
of the
NATO
report to numerous
1).
anecdotal accounts and
formal surveys during the 1970s and 1980s confirms the persistance of these
same problems
Ramamoorthy
(Boehm 1976;
et al.
1984;
Thayer 1979;
Brooks 1987).
Arden
1980;
Abdel-Hamid
1984;
But perhaps the most famous account
of
problems
published
in
in
1975 by Frederick P.
of mainframes
that
in
the mid-1960s.
difficulties
Brooks, Jr.
impossible to isolate,
In
system
The Myt hical Man-Month
recounting his experiences
IBM's System/360 family
for-
development
were
and thus inherently systemic. Most vexing
in
to him
Brooks was
the difficulty of achieving
based on "man-months"
projection'^
so inaccurate as to be practically "mythical"
and concpptn^l
"efficiency
He
content.
in
also claimed that
integrity"
many participants could be described by ^n "n-square
where n objects had
were
arguing that poorly developed rstimating techniques and
methods to monitor schedule progress made
project with
nearly
interrelated,
planning, project control, quality management, and maintenance.
particularly eloquent
,
Brooks concluded, as did others before and
software
in
been
has
of the main operating
managing production
after,
development
software
n(_n-l)
Brooks
possible interactions.
left
in
large
a
law" effect,
readers with
frightening imagery, comparing the task of large-scale software development to
prehistoric animals
struggling futilely to escape an
unforgiving tar
pit
sinking deeper with each movement:
No scene from prehistory
struggles of great beasts
in
is
quite
so
vivid
the tar pits.
In
as
that of the mortal
the mind's eye one sees
dinosaurs, mammoths, and sabertoothed tigers struggling against the
grip of the tar.
tar,
and no beast
The
is
fiercer the struggle,
the more entangling the
so strong or so skillful but that he ultimately
sinks.
Large-system programming has over the past decade been such
tar pit, and
in
it.
goals,
many great and powerful beasts have thrashed
Most have emerged with
schedules, and budgets.
running systems
--
a
violently
few have met
Large and small, massive or wiry.
and
team after team has become entangled
seems to cause the difficulty
in
No one thing
the tac.
any particular paw can be pulled
--
away.
But the accumulation of simultaneous and interacting factors
brings
slower and
Everyone seems
slower motion.
surprised by the stickiness of the problem, and
the nature of
solve
it
it
if
we are
to
(Brooks 1975: 4)
WHY SOFTWARE
Why
But we must try to understand
it.
have been
hard to discern
is
it
to
DIFFICULT
IS
software development remained difficult to manage appeared to result
from several interrelated factors, not
Many problems seemed
to
all
stem from
which were technological
of
in
nature.
the inherent complexity of designing,
building, and testing computer code, especially the unpredictability of component
programs become large
interactions as
similar
functions;
interactions
of
in
the different ways of writing
size;
and the near impossibility of
components
and
operating
fully
checking
conditions.
Software
all
possible
producers
employed countermeasures, such as high-level languages, structured programming
and
design
procedures.
estimates
of
techniques,
It
also
and
a
variety
proved possible
human
performance
to
of
support tools
and documentation
reduce variability or the uncertainty of
by
standardizing
skills
through
training
programs, providing everyone with the same tools and methods, keeping detailed
data on the performance of specific individuals
well
in
different types of projects as
as data on the average performance of individuals with certain years of
experience or training.
Reuse
of designs
and code could further lessen both
complexity and variability by cutting the amount of new software developers
had
to write.
8
These
kinds
reusability -- appear frequently
other industries.
will
be
without
systematic
in
some form
control
of
procedures that might not suit
a
all
still
or
enforcement
of
in
and
standards
projects and development personnel.
In this
particular firm or project might be able to structure
depended on the kind and
tools
of
utilization
cannot predict what the process
process for software development was not simply
of
and
engineering and manufacturing operations
But software managers
sense, to what degree
collection
standardized training, tools, and methods; and
performance data;
individual
--
solutions
of
a
its
technological problem.
It
variability of projects as well as the appropriateness
market needs,
and methods given
technological
changes,
preferences of individual managers, engineers, and customers.
and the
These factors
remained difficult to predict and control since they were both external and
internal to the firm.
Diversity in user-requirements and applications presented another problem
that put practical limits on reusability and repeatability of procedures, tools, or
code from project to project, and raised the potential risks of standardizing
designs,
tools,
methods,
training.
or
Variability
appeared
accommodate different user needs and technological innovation.
necessary
to
But when this
reflected a lack of standards, poor planning and control, or insufficient product
and market focus, managers probably could do more
needed
to
manage,
both
external
in
market
tn limit the diversity
requirements
and
they
internal
organizational practices.
At the same time, the still-evolving state of both hardware and software
technology, especially the frequency of product and process innovations, made
difficult
and risky for managers
Especially
in
to focus
it
and standardize operations too much.
segments changing particularly rapidly, such as personal computers
or engineering work stations,
a
prudent strategy might be
to avoid investing in
standardization of methods, tools, or program libraries of reusable code that
might soon become outdated.
Software developers themselves might also contribute to managerial and
They might
organizational constraints.
company standards, or
tools, despite
insist on using their
own methods and
dislike filling out detailed reports
for project control or process and quality analysis.
In
needed
they might
addition,
prefer to build ever more sophisticated and innovative systems,
rather than
reusing specifications, designs, and code to make products similar to previous
ones.
In
fact,
one of the major difficulties cited
proceedings dealt with this
item,
last
i.e.,
the 1968
in
NATO
conference
software developers often
that
preferred to write new programs, and thus they constantly immersed themselves
(and the firm)
in
research and reduced their (and the firm's) ability to benefit
from previous experience:
Instead of trying
year's,
to
write
a
system which
is
in
like
last
only better implemented, one invariably tries to write
an entirely new and more sophisticated system.
are
just
fact
salesmen
continually
disguise
production job....
this
embarking on
to
the
Therefore you
research,
customer
yet
being
as
your
just
a
This practice leads to slipped schedules,
extensive rewriting, much lost effort, large numbers of bugs,
and an inflexible and unwieldy product.
such
a
product can ever be brought
reliability or that
it
It
is
to a satisfactory state of
can be maintained and modified.... [T]his
mixing of research, development, and production
of the
unlikely that
software gap'...
is
a root
(Naur and Randell 1969: 123).
10
case
Nevertheless, since the 1960s, large software producers have learned much
about how and how not to manage software development, even though gains
in
programming productivity and quality have continued
in
computer hardware by wide margins (U.S. Department
companies attempted to become more systematic
in
to
of
trail
advances
Commerce 1984).
software,
As
they also moved
closer to introducing factory-like concepts, tools, and organizational structures
This occurred despite the tendency of software firms not to use
or processes.
the term factory to label their development facilities (except
in
Japan).
THE MARKET LEADER: IBM
For example,
the
in
preferring to use labels such as laboratory or programming center to
world,
described
in
IBM, the largest producer of hardware and software
1960
Its
to
many software
elevate
development) to
it
until
this time
software
basic
a level
Nonetheless, top management first began
programming
more comparable
above the status
raise
facilities.
to
a
not
applications
hardware engineering, or
of a loosely controlled
had been
(though
support activity.
relatively simple matter for
at least to
Programming
IBM and customers
in
terms of personnel requirements and organization, since machines remained small
and
companies
only
needed
a
few
people
discussions focused on the need to organize
to
a
write
tightly
programs.
But
now
managed corporate-wide
system for producing basic programs to run the new machines IBM planned to
introduce and make sure new software did not contain the large number of
quality problems reported
IBM did not
next few years,
in
IBM's earlier programs.^
fully centralize
set
up
a
development operations but rather, over the
world-wide organization to produce the System/360
operating system (OS/360), probably the most difficult and expensive commercial
11
The
software project undertaken up to that time.
basic software included four
different but "upward-compatible" versions of the operating system, each for
OS/360 stood
machines of different sizes.
at
the top of the
Other
line.
less
complex systems, providing basic programming capabilities through management
of
external
and
disk
tape
memory drives,
Support), BOS (Basic Operating System)
DOS
,
BPS
were
Programming
(Basic
(Disk Operating System)
,
and TOS
(Tape Operating System).
IBM completed the smaller operating systems more or
they worked relatively well.
While
however, presented major
OS/360,
IBM announced the System/360 family
shipments
mid-1965,
for
OS/360 was
design,
including as
construction,
many
and
finally delivered a first version of
The organization
programs consisted
IBM used
difficulties.
and planned the
IBM
forcing
to
ship
first
the
After 5,000 man-years expended
a
period
of
three years,
working on the system simultaneously, IBM
OS/360
1966, containing
in
many more man-years
of multiple
1964
documentation over
as 1000 employees
defects that would require
in
ready,
not
hardware with the simpler operating systems.
in
on schedule, and
less
to
huge numbers
to correct (Fisher et al.
of
1983).
produce System/360 software and
later
development laboratories, each with hardware-
engineering, programming, and marketing divisions or centers.
Each laboratory
took responsibility for different sizes of computers aimed at different customer
markets, although each programming center had
development assignment that contributed to
responsible
centers,
for
a
formal mission or product-
a
larger effort.
A vice-president
programming operations oversaw the different programming
and corporate IBM provided whatever financial resources managers
needed for product development,
tool
distributed the development work among
(sort routines)
,
and method
and training.
IBM
New York City (languages), Sweden
Rochester, Minn, (processor control)
12
R&D,
,
San Jose (access methods),
Raleigh, N.C. (communications), Poughkeepsie, N.Y. (largeoperating system)
Endicott, N.Y. (mid-range operating system). Other centers
Kingston, N.Y.,
in
structure reflected
strategy to create centers of
a
experienced software developers around the world, specialized both
such as sorts or communications software, and
as
mid-range versus
necessary
because of the
thousands of programmers.
logistical
IBM,
in
dispersion
this
expense
and
difficulty
functions,
in
machine types or sizes, such
in
Managers considered
machines.
large
and
also aided the effort.
Germany, and additional locations
This organizational
,
centralizing
of
the past, had already distributed hardware
design, and management wanted to locate software personnel nearby hardware
engineering for specific machines.
But dispersion and the independence of each programming
to
organizational
as
well
software and subsequent products.
center,
as
considerable
well
as
project
problems
technical
as
completing
managers
and
Even as
late
as
individual
centralized control allowed the release of
of
defects,
management system.
to
decide
what
correcting
specific
IBM had yet
1970,
retained
tools
to establish
old
as
or
a
and the lack of
many important products with
including OS/360 as well
Simply
System/360
engineers,
coordinated system for quality assurance and maintenance,
numbers
contributed
For example, directors of each programming
autonomy and the authority
methods they would use.
in
site
large
highly popular database
a
problems
consumed enormous
expenses and manpower resources that directly detracted from new-product
development.
IBM also applied what managers
later
organizational structure for software maintenance,
first
patterned
maintenance
after
decided was the wrong
a critical
hardware divisions,
area.
The company
where mechanics
individually went to customer sites and fixed problems as they occurred.
software, where thousands of customers might use
13
a
In
single package such as an
operating system or data-base management program, decentralized or individual
maintenance proved to be far too labor intensive, costly, and unnecessary.
But perhaps the major challenge IBM faced became the growing difficulty
large software projects dispersed around the world and then
of coordinating
expecting groups to complete components on time that would work together
according to technical
OS/360 but
even before
also with
announced along with the hardware
in
in
in
dubbed the
only with
called for adding virtual
memory
and this required major technological
another huge project to produce
in
FS
Future
for
System,
IBM management decided
in
added
because
FS
architectures and
would
not
run
a
successor to System/370,
IBM's
to
costs
and
man-power
1974 to cancel this effort after spending
$5 billion and using approximately half of
project,
not
programming concepts that made new projects even more complex.
Poor planning
shortages.
do this
specifications for OS/370,
addition,
1970,
capabilities to the basic operating system,
changes
to
failed
planned new versions of DOS/360, which IBM cancelled
public announcement.
a
IBM
specifications.
all
basic software personnel on the
programs written for the 360 and 370
seemed unlikely customers would accept the new system
it
(DeLamarter 1986).
In
an attempt to streamline and systematize
several practices,
at
least for basic-software
its
operations,
IBM changed
One move, which
development.
some executives had demanded directly after the OS/360 experience, set up
a
system of strict individual accountability for new products, committing project
manager's to guarantee specific dates when their components would be ready.
IBM
also
established an organization
with specialists
to
customers.
though
in
the
in
In
a
for what
it
called
remote maintenance,
centralized location fixing software before re-releasing
addition,
mid-1970s
IBM began more centralization
there
remained
14
as
many
as
of
eight
it
development,
sites
making
interdependent language compilers, database-management systems, and access
This situation persisted until IBM management decided to concentrate
programs.
these programming activities
the
In
IBM
meantime,
in
one location
had
been
California.
in
accumulating
a
wealth
of
knowledge
regarding the management of software development that helped IBM and other
firms introduce more systematic procedures and some support tools for testing
and coding operations and then for design and process management.
evolution can be seen
begun
in
an analysis of articles
in
the IBM Systems Journal ,
IBM as
1962, which describe both actual practices in
in
As the
and
topical
chronological
research and practice
indicate
listings
This
(Tables
well as research.
2
and 3),
both
the 1960s and 1970s centered on testing, simulation and
in
other forms of product evaluation.
Articles on generic tools
in
the 1980s were
the methods area, most articles
in
the
1960s treated design, coding, and testing, with shifts away from coding
in
the
more varied but now included design.
In
1970s and 1980s toward project management and programming environments, but
still
with considerable attention to design and testing
.
With an extensive and continually growing basis of software-engineering
rising recognition of the importance of software from
knowhow, and
executives,
technological
IBM
in
the late 1970s took
integration
latest tools, techniques,
by creating
a
a
further step
new
software^
in
its
highest
organizational and
facility
combining the
and concepts regarding programming environments: the
Santa Teresa Laboratory.
This facility, opened
in
1977, brought together 2000
software personnel organized along functional product lines (languages, database
systems, access methods) and provided
a
new physical
setting, designed
by the
head of Harvard University's School of Design, Gerald McCue (McCue 1978).
its
name
implies,
Laboratory
as
a
IBM executives did
factory.
In
not
practice,
15
view or
label
however,
they
the
Santa
created
a
As
Teresa
highly
functionally organized facility,
centralized,
programmer performance, comfort, and
layout designed to facilitate
physical
communication.
eliminating
This consolidation,
duplication
many
in
with a standardized process and
saved on overhead costs by
moreover,
and
positions
staff
gave management more
immediate control over product development and testing, of new and existing
products.
IBM
a
in
the 1980s operated other sites with several hundred and even over
thousand software personnel
one location, although management did not
in
appear to duplicate the degree of consolidation
applications facility
in
at
Santa Teresa (except for an
Tokyo with several thousand personnel on one
the one hand, moving over
thousand developers and their families from eight
a
different cities to Santa Teresa became extremely expensive.
decided not to invest
(as
in
Japan,
in
a
similar effort unless
where IBM's competitors
systems
engineers
because
of
and programmers
the sheer size of
operations,
it
seemed
IBM's
in
it
concentrated
also
integrated
large
facilities).
though
numbers
In
of
addition,
hardware development and programming
management would ever try
unlikely
even
Top executives
seemed absolutely necessary
development operations completely and risk losing the
around the world,
On
site).
dispersed
to
centralize
ability to tap expertise
made
operations
it
to
difficult
coordinate and standardize methods, tools, and controls.'^
Equally
integration
important,
IBM
and consolidation
encountered
of
personnel
example, Santa Teresa first attempted
with large departments handling
IBM managers concluded
this
all
a
practical
in
limits
functional
to
large-scale
departments.
For
relatively strict functional organization,
coding or
structure did
all
design.
not
help
Ultimately, however,
them serve individual
customers effectively when products required close coordination between design
and product construction.
Management thus shifted Santa Teresa toward
16
a
mixture of functional and product -centered departments
with
1980s,
oriented
design,
specialized
--
divisions"*
a
and testing groups within product-
coding,
structure
the late 1970s and
in
similar
to
Japanese
software
factories
described below.
addition
In
to
finding
efficiency
organizational
and
a
IBM
flexibility,
toward solving another issue:
compromise
better
increasing
its
provide
uniform interface to make
a
as whole
tools as well
one time, incompatible
meeting
(SAA)
Architecture
Application
it
1980s
late
An example
initiative,
process
or
worked
also
hardware and
of this effort, IBM's
when
completed,
would
easier to reuse portions of systems and
programs across previously incompatible machines.
lines
At
supported an effective marketing strategy aimed
market segments with
different
the
ability to standardize
software internal architectures and interfaces.
Systems
in
between
different
and
products
at
dissuading
competitors from introducing an equally broad range of computers.
IBM
in
the
past also appeared to view applications software as an extension of sales and
did
subject
not
But,
software.
this
to
same discipline and structuring as basic
the
by the mid-1980s,
Equipment
Digital
area
Corporation,
intensified competition
which
offered
from firms such as
compatible
small
and
large
machines that could use the same software and databases, had forced IBM to
reevaluate
its
THE FIRST
One
strategy and attempt tighter controls and integration.
U.S.
SOFTWARE FACTORY: SDC
of the U.S.
Corporation, formerly
division,
1976.
leaders
a
in
the custom software field, System Development
part of the Rand Corporation and
established the first U.S.
17
in
1988 a Unisys
in
1975-
the 1950s to develop the
SAGE
software facility called
SDC had been separated from Rand
in
a
factory
missile control system for the U.S.
other
real-time
programming tasks
but went public
corporation,
software costs and launched
five problems
(1)
Department of Defense.
special
a
later took
process-oriented
SDC programmers continued
R&D
on
government-sponsored
Top management then had
1970.
in
a
as
It
effort in
to control
1972 to tackle
to encounter project after project:
Lack of discipline and repeatability or standardized approaches to the
development process.
(2)
Lack of an effective way to visualize and control the production process,
as
well
as
implemented
(3)
measure before
to
a
a
was
completed
how
well
code
design.
Difficulty in accurately specifying
design and coding,
performance requirements before detailed
and recurrence
certain requirements, or changes
(4)
project
of
disagreements on the meaning of
demanded by the customer.
Lack of standardized design, management, and verification tools, making
it
necessary to reinvent these from project to project.
(5)
capability
Little
to
reuse
components,
despite
the
fact
that
many
application areas used similar logic and managers believed that extensive
use of off-the-shelf software modules would significantly shorten the time
required for software development (Bratman and Court 1975 and 1977).
Ultimately,
consisted
of
the
SDC engineers constructed
three elements:
an
integrated
18
set
a
detailed factory plan that
of
tools
(program library,
project databases, on-line interfaces between tools and databases, and automated
support systems for verification, documentation, etc.); standardized procedures
and management
policies for
program design and implementation; and
a
matrix
organization, separating high-level system design (at customer sites) for program
development
system, which
facility of
final
The
Software Factory).
(at the
SDC copyrighted under
about 200 programmers
in
site to
first
utilize
the factory
the name "The Software Factory," was
a
Santa Monica, California. Determining the
form of the factory, however, required years of effort as well as
trial
and
error.
SDC management and R&D
For example,
factory
more than
being
as
initially
the Software Factory as
a
of
tools
that
they
hoped
SDC
other words, they did not think of
in
physical, centralized facility,
One reason was
other industries.
set
a
around the country might use;
facilities
engineers did not conceive of the
similar to factories in
that the Department of Defense and other
customers frequently required software contractors to locate development teams
at the
computer
impractical,
The
Other factors also had made
sites.
incompatibility of
had made
organize work
many computers
in
it
logical
for
in
the jobs
for which
it
SDC and most
redundancies
in
to
to
keep
its
employees
other software producers to
with integrated teams building their own tools and
projects,
difficult
SDC wrote programs, and
SDC accepted
deciding on practices suitable for each job.
made
centralized facility
although circumstances were changing.
the wide variety of applications
active,
a large,
standardize
This craft or job-shop approach
practices
among
areas such as tool development,
projects
design,
or
eliminate
and coding, but
it
brought customers, systems engineers, and software developers together, and
seemed
to increase the likelihood that the software
requirements.
However,
a
growing shortage of
19
system would meet customer
skilled
programmers made
it
harder for managers to find the proper set of experts on components such as
operating systems,
locations
compilers,
and telecommunications
interfaces,
or to locate engineers willing to move frequently.
shortage of people had prompted
SDC management
different
in
By
1976,
to consider an
this
alternative
organization
After working with the
R&D team
for a year on tools and methodologies,
the new leader of the project. Jack Munson,
single
facility
--
an
actual
factory
--
R&D,
in
in
Engineers
would bring programming jobs to them.
and methods developed
software for SDC's
build
This facility would locate specialists
Division.
tools
to
recommended that SDC create
one
in
a
System
management
site while
the facility would use the
remote-terminal and computer
as well as
technologies that allowed "a single set of personnel to monitor and control a
large
number
of scale
of software projects concurrently, taking
and providing for cross-utilization
advantage
of scarce skills"
economies
of
(Baum
1981:
220-
223).
As
customer
in
the past, the factory structure required program offices at each
site.
Program managers maintained responsibility throughout the
life-
cycle for project management, customer relations, requirements and performance
specifications, systems engineering, and quality control and assurance.
the actual software and test
it,
however, program managers had to transfer
system specifications to what was essentially an assembly
within the factory:
separating
advantage
in
line of
three groups
Computer Program Design, Computer Program Development,
and System Test and Verification. The SDC team,
that
To build
system
design
from
program
at least in
production
1977,
recognized
offered
both
an
maintain closeness between systems engineering and customers as
well as a potential
disadvantage
in
removing the program developers and testers
from the customers and systems engineers.
20
But they
hoped that informal
and
communication
--
standards
methodological
"a
well-understood
normal,
interface procedure" -- could overcome any problems (Bratman and Court 1977:
128).
SDC gave
the name Factory Support System to the "basic structural and
control components" designed to facilitate the factory methodology (Bratman and
Court 1975: 30-36; Bratman and Court 1977: 128-137).
a
language to
high-level
computer and
procedures
(Figure
1).
management
a
used
the
keeping
for
The
ease
activities, maintained
in
IBM 370 mainframe
an
system
automate
to
program development and collecting data
of
supported top-down
tools
on
operating
IBM's
of
facilities
track
ran
portability,
This tool set, written
automated
development,
several
requirements through implementation, provided
library history for programs, allowed for symbolic system-data control,
and
automated aspects of program inspection and qualification.
It
also took
a
year and
a
half
identify standards and procedures
that
might be applied to
process around
activities,
a
general
variety of
events,
and
in
product components
They based the
development covering the major
common
to
projects.
all
The
what SDC called the Softwa r e Deve opment Manual or
l
called for structured design
and program production
rules and specific guidelines--
software projects.
life-cycle model of software
methodology, codified
SDM,
a
--
during 1975-1976 for the R&D team to
libraries.
and coding, top-down program development,
In addition,
SDM
outlined
a
management and
control process, providing guidelines for planning, project control, review and
(Baum
1981:
part borrowed from existing
U.S.
evaluation procedures, and quality assurance
The R&D team
in
22).
military
standards
(Bratman and Court 1977: 120), but established most of the SDM methodology by
examining
previous
projects
SDC had done through
written
interviewing personnel to determine what had worked well
21
records
and
and appeared to
According
represent "best practice" within the company.
key factory
to the
architects, Harvey Bratman and Terry Court, this effort was critical to creating
a
common language and methodology that would make the factory more than
just a building with a large
a
common
number
of
programmers and projects working from
pile of tools:
hold the disparate portions of the Factory together:
The procedures
the standards are the means of making the Factory efficient and easy
to use
and learn.
Without the standards that establish the Software
Factory methodology and the procedures that establish the precise
way
of doing a task, the Factory
development
of software
tools.
and faithfully maintained
improvement,
standards.
.
solutions of
is
to
more than an agglomeration
Standardization,
to reflect
essential
little
is
established
initially
changing conditions and continual
the success of the
.establish a working environment
The
Factory.
...
where the creative design
key technical personnel can be implemented
quality products, on schedule, and within budget.
high-
in
More specifically
they:
--
promote repeatability
in
the software development process;
-- allow rapid transfer of expertise
from one project to another;
-- establish a consistent
framework for cost estimating;
--
people to
make
it
possible
for
common understanding
--
interact
efficiently
and with
a
of goals;
provide the capability to measure project progress
in
a
realistic
manner;
-- enforce technical
-- establish
a
basis
and management techniques;
for
assuring
22
and measuring software quality
(Bratman and Court 1977: 121).
Approximately 10 projects went through the
Four of the largest were TIROS-N,
1976 and 1978.
system completed
in
1978 for the
Range Scoring system for navy
(MADS),
a
SDC
Software Factory between
a $7 million
TIROS-N weather
data-processing
the Mobile Sea
satellite;
battle training; the Morocco Air Defense
System
$12 million contract for systems engineering, software development,
and training, with Westinghouse as the prime contractor, based on SAGE and
a
successor design and described by SDC's company history as "the first airspace
system to use
implemented
a
standard commercial computer (the Burroughs B7700) and to be
in
standard
a
(ALGOL)....";
language
higher-order
Emergency Command Control Communication System (ECCS),
The
project for the Los Angeles Police Department.
in
the company
history
as
control system ever conceived,"
every 4 seconds
at
handled 3 million
peak loads, as well as 1.2
year, linking 850 mobile digital terminals
in
calls
the
$28. 5-million
a
police system,
and most complex
largest
"the
and
police
referred to
command-
per year and one
call
vehicle dispatches per
million
patrol cars as well as 5000 portable
two-way communication devices (Baum 1981).
SDC managers
claim
that
all
the
projects,
system for the L.A. Police Department, came
with
fewer defects and problems than
systems.
The company history
in
SDC
the
with
exception
of
the
on time and within budget, and
usually
experienced with
large
also described the factory projects as, for the
most part, "accurate, timely, and on budget," and models of "optimum software
development" (Baum 1981: 205, 224).
SDC's chief executive,
methodology as
a
In
fact,
George Mueller,
corporate standard and
the factory worked so well that
directed
in
all
divisions
adopt the
1978 promoted the head of the
factory project. Jack Munson, to oversee this transfer."
23
to
Yet Munson's personal advancement contributed to the end of the factory,
which
gradually into disuse as the number of new projects going through
fell
the facility declined.
why SDC's
The general
lack of tool portability provided one reason
top executives began to lose interest
problems with
a
the factory concept.
in
But
particular project led Mueller to end his support and provided
ammunition for program (project) managers who did not want to use the factory
structure to build their software.'
This was the
ECCS system
for the L.A.
police.
According to Court, who headed the software-development effort for this
project,
ECCS broke down
mainly from SDC's lack of experience
engineering for this type of application.
the job of personnel
SDC had
built.
It
terms of writing and testing code,
ECCS resembled other systems
the software factory,
in
was
In
a
command and
real-time
systems
in
control application, with strict
time and space constraints, and numerous communications and data-management
requirements.
anything
in
However,
SDC had done
Court's words,
the
functionality
before:
a
the
of
application
differed
police-department information system.
from
Thus,
"our systems engineering could not dominate the process,
because they knew very
little
about police work and police operations.
police tended to dominate the process,
on expanding and expanding."
and as
a
So the
the requirements kept
result,
This led to an "endless discussion and analysis of
requirements" that consumed nearly two years, throwing off the entire schedule
and budget.
Not surprisingly,
the specifications
SDC
eventually agreed to
turned out to be more complex and took longer to code than managers had
anticipated,
hardware
particularly since they tended to exceed the capabilities of the
(4 Digital
PDP 11/70 minicomputers), making
software to run as efficiently as possible.
on this project since
it
had agreed
SDC thus
initially to a
24
it
necessary to refine the
lost a large
sum
fixed-price contract.
of
money
To complete ECCS, SDC reverted
created
a
to
former job-shop structure and
its
This group
dedicated project team of the best people available.
Future jobs
finished the specifications as well as built and tested the software.
also
went back
to the project system,
The factory methodology, embodied
for program development."
manual, remained, although
SDC
projects and sites.
to use
it
through the
rather than using the factory structure
SDC
also
in
the
SDM
dispersed the factory personnel among different
updated the manual every few years and continued
while concepts from the factory methodology
late 1980s,
also spread to other firms after the U.S.
SDC
in
Department
of
Defense contracted with
1976 to devise guidelines for military-use software procurement.^
Dissolution of the factory had both negative and positive consequences for
On the one hand, dispersing programmers
SDC.
personnel work closely with customers and specialize
Some former factory engineers
also
took
on
different
to
in
staff
sites
helped
particular applications.
roles,
helping
different
projects with proposals, new-business development, customer relations, strategic
planning,
natural
and other tasks.
outcome
development
offer.
in
to
'^
Dissolution
some managers,
the factory tool
of
set
seemed
because of the dynamic nature of
a
tool
software and the incomplete state of what the factory had to
SDC had never completed
all
the tools and expected them to evolve,
with old tools falling into disuse.
On the other hand, ending the factory
did not help
problems that had inspired the factory's inception.
to exist as a corporate standard,
although
it
SDC
solve the five
The methodology continued
became more
difficult to enforce
good practices and use common tools across numerous independent
also
never developed
the
ability
to
reuse
different projects, and gradually declined from
1970s as a leader
in
software
a
position
sites.
systematically
in
SDC
across
the 1960s and early
the software industry, eventually merging with Burroughs
25
in
1981.
ten years after the end of the factory,
addition,
In
were
divisions
environment.
trying
still
the 1980s,
In
build
to
common
a
SDC management
programming
appeared to be moving some
also
back toward centralization, but without separating systems engineering
facilities
from program construction so rigidly and letting
lines
and
set
tool
some SDC
least
at
business.
of
This
seemed
a
better
way
facilities
to
despite the lack of more rationalized structure,
gain
focus on specialized
some scale economies
like the original
factory had
attempted.
In
retrospect,
SDC may have attempted
of standardized tools
to impose a factory infrastructure
and methods, and reusability goals, on
range of projects
a
that were too different and better suited to job-shop production.
software
made
technology
it
difficult
to
transport
tools
matrix-management problems that surfaced and prevented
Nonetheless,
the facility.
even though
a
differed
as Japan's other
in
leading computer producers
some respects,
market focus
of
their
remarkably similar
as effective in
across
in
reflecting variations
software products,
steady work flow
SDC abandoned
factory model influenced similar initiatives already underway
as well
code
state of
Furthermore, architects of the factory failed to solve the
different machines.
into
and
The
in
in
the effort,
Japan
(Table 4).
company
its
at Hitachi
While each
histories and the
the Japanese efforts proved to be
technical emphases, organization, and management, as well
improving levels of project control, productivity, quality, and
reusability.
26
JAPANESE FACTORY EFFORTS
Hitachi
by founding
Hitachi,
its
Software Worl<s
company
1969, was the first
in
the world to apply the term factory (actually,
Japanese equivalent, kojo,
its
translated either as "factory" or "works") to an actual software facility.
history
executives
when
independent factories
of
this
in
each
for
became
a
product
major
the computer division to create
A
prompted
area
separate facility for software
a
The objectives
major activity.
in
Hitachi managers
set for
their factory were to transform software from an unstructured "service" to a
"product" with
guaranteed
a
level
of cost
approach to achieve productivity and
and quality, and use
reliability
centralized
a
improvements through process
standardization and control.
A
particular
factory.
First,
programmers
set
all
administrative
in
deal
a
led
Hitachi
need to offset
numerous
with
establish
to
a
software
severe shortage of skilled
a
customers
from
complaints
the software Hitachi was providing (most of which, along
Hitachi was importing from
Hitachi
factories
standards forced
development process
standards
and
Japan
in
with the hardware,
that
circumstances
management saw
regarding defects
fact
of
in
had
adopt
until
of
accounting
analyze the
to
and experiment with
The independence
Second, the
1970).
corporate
software managers
great detail
and controls.
to
RCA
Hitachi
a
series
factories
and
software
of
within
work
the
corporation also gave factory managers considerable authority over technology
development.
Managers concentrated
productivity and costs
in all
initially
on
determining
standards
for
phases of development, based on standardized data
bases for project management and quality control.
design
factory
around structured programming techniques
27
Hitachi then standardized
in
the early
1970s,
and
standards
with
training
programs for new employees and
reinforced
these
managers.
This reflected an attempt to standardize and improve average skills,
rather than specify every procedure to be performed
The
of development.
year of the Software Works' operations
machine
in
the field
during 1983-1985.
Hitachi
concepts
"•
in
fell
in
as
in
the first
1970 to approximately 7%
subsequent years, while the number
from an index of 100
in
in
full
1974,
per
of defects
1978 to approximately
13
^
managers also underestimated how
such
each project and phase
Late projects dropped from 72%
results:
and remained under 19%
in
and
reusability
process
difficult
implementing factory
standardization
would
be.
Two
First, their attempt in the early 1970s to introduce a
examples illustrate this.
"components control system" for reusability
failed.
As one of the managers
responsible for building the factory systems, Kanji Shibata, recalled: "Around
1970
we believed we had
and
what you find for hardware,
committee to take this up as
soon realized that "software
same as
in
components control system similar
to introduce a
a
is
in
the
special
project."
a
way
to
we established
a
But the committee members
not sufficiently standardized to be treated the
hardware components control."
decided to find
Software Works
to
They changed
their priorities and
standardize product designs, and then worry about
components
A survey
of the
programming
field
suggested that structured design and
programming techniques would help standardize software design and coding.
The committee renamed
itself
the Structured Programming Methods Committee
and spent several years studying these techniques (as they were evolving) and
analyzing programs Hitachi had already written.
move, because
it
This was truly
would be several years before articles
in
a
pioneering
industry journals
began discussing structured design and programming widely and companies such
28
as
IBM adopted these practices for their internal standards.'"'
Hitachi also attempted and failed to introduce one standardized process for
The need
both basic software and custom applications software.
methods and tools for different software types
led
to a
to separate
separate division for
basic software and applications within the Hitachi Software Works, and then to
establishment of
1985.
second software factory, dedicated to applications only,
a
At the start of the factory,
however,
a
took on the task of establishing procedures for
cycle
model
available
Hitachi,
development.
of
on
materials
and completed
software
all
activities,
almost
based on
weekly,
a
life-
studying
development and examining practices within
standards by the end of 1970, referred
a first-cut set of
These covered product planning,
Standards (HSS).
to as the Hitachi Software
committee for work standards
committee met
This
in
design and coding methodology, documentation and manuals, testing, and any
necessary to complete
other activities
a
software product.
Although Hitachi
managers clearly recognized these procedures and standards would have
to
evolve as personnel and technology changed, and they made provisions to revise
some
standards
annually,
drawing
up the standards
helped
managers and
engineers identify best practices within the company and within the industry for
dissemination to
all
projects and departments.
Struggling with work standards also helped the committee recognize the
need to distinguish between basic systems and applications software, rather than
continue trying to impose similar controls and expectations on
software development.
It
all
started developing separate standards for applications
during 1971-1972 and published system-consultation standard times
1975, the Software
HI
PACE
(Hitachi
Engineering),
to
types of
Works had completed an
Phased
Approach
standardize formats
for
for
29
initial
High
set of procedures
Productive
proposals,
in
1973.
By
now termed
Computer System
designs,
and
program
construction, as well as to aid
evolution
came
important juncture
relatively
easy to
*^
when management
at
the
structured design and requiring
in
to follow structured concepts, to facilitate design standardization
as well as maintenance
Somewhat longer programs appear
and portability.
have resulted, but managers considered the benefits
this point, the factory
that Hitachi
it
the 1980s.
in
1973,
in
Software Works began training programmers
new projects
made
and tools then
establish a separate applications software factory
Another
The
developing tools for design automation.
standards
different
of
in
was also able
to institute the
to
At
to be significant.
components-control system
had wanted several years earlier, to standardize procedures for
Furthermore, this system helped simplify
module construction and configuration.
design and maintenance, and increased the potential portability of code, though
reusability was not yet a major goal
By the
around
Hitachi had succeeded
late 1970s,
combination
a
Hitachi
in
manual
of
in
(Hitachi 1979:
organizing
engineering
and
its
117-118).
software factory
techniques--
factory
structured design and coding coordinated with data collection and standard
times for each activity, detailed documentation, design reviews independent of
project personnel,
tools,
Hitachi
management was ready
to
invest
heavily
in
relying on engineers mainly from the Software Works and
Development Laboratory, part
The
At
after spending years studying and standardizing the development
this point,
process,
rigorous defect analysis, and other elements (Table 5).
tools Hitachi
covering
each
software,
during the
and
late
its
new Systems
of the central laboratories structure.
adopted for
function
computer-aided
its
activity
1970s,
software factories were comprehensive,
in
Hitachi
software
development.
introduced
For
basic
CASD (Computer-Aided
Software Development System) to facilitate design, coding, documentation, and
testing, and
CAPS (Computer-Aided
Production Control System for Software) to
30
manage manpower estimation, process flow control, and quality control.
CASD and CAPS were
in
the late 1980s of
a
continually evolving, as seen
new system
in
for project control,
Both
Hitachi's gradual adoption
PDOC
(Project Diagnostic
Check System).
For custom applications,
of tools
the late 1970s, Hitachi began developing
and methodologies under the
Software Engineering System)
1986).
in
label
(Kobayashi
The most important ones consisted
a set
ICAS (Integrated Computer-Aided
Kobayashi and Aoyama
et al.
1983;
of the
SEWB (Software-Engineering
Workbench), which supported both system design and programming on advanced
work stations,
Software
EAGLE
and
Productivity),
Approach
(Effective
which
ran
on
to
Hitachi
mainframes
programmers build software from reusable modules as
designs and code for reuse (Hagi et
al.
1986).
HI
Achieving
as
well
High
and
factories
of
in
1989
(see
Table 4),
PACE continued
operated
Hitachi
the
two
helped
structure new
to serve as
the basic methodology used with these and other tools (Miyazoe et
As
Level
al.
largest
1980).
software
Japan. The original Hitachi Software Works, with approximately 5000
personnel (including approximately 3000 assigned from Hitachi subsidiaries and
subcontractors),
built
a
range of
basic
software
for
Hitachi
mainframes,
including operating systems, language compilers, and database systems.
The
System Design Works (formerly called the Omori Software Works), housed 6000
software
developers
subcontractors)
in
two
(including
4000
personnel
31 -story
towers.
This
from
facility,
subsidiaries
unlike
and
some other
Japanese applications software factories, combined systems engineers (those who
designed the systems) with programmers that built the actual software, and
concentrated on customized business applications systems such as for banking,
inventory, or personnel control.
31
Toshiba
Toshiba created what
is
perhaps the most structured factory, although
it
also had the most focused product lines, using a centralized software facility to
develop
control
process
real-time
decision to establish
a
software for
industrial
applications.
software factory stemmed from rapid increases
in
The
actual
and projected demand, beginning around 1975, for industrial control systems
relying on a
new generation
of relatively
inexpensive minicomputers.
the changing demands Toshiba faced as sales of
were orders from Japanese
power-utility
thermal-power generating stations.
of
software;
the
typical
hundred thousand
lines
in
control minicomputers rose
companies
develop
to
automated
These used enormous and growing amounts
power-generation
of code
its
Typical of
control
system
rose
from
a
few
the mid-1970s to two million by the early
1980s, necessitating years of development and
hundreds
of
new programmers.
1 "i
Furthermore, to achieve safe and untended operation, the hardware and software
for these and
many other
at least highly tolerant of
control systems had to be nearly free of defects or
system faults.
An R&D group responsible
for software development
in
Toshiba, led by Dr.
Yoshihiro Matsumoto, introduced an organization and process
tools,
for
methods, management and personnel systems, as well as
work
stations
(Table 6).
centered around four policies:
variations
The strategy
for
utilizing
1977 integrating
in
a
physical layout
this
infrastructure
standardize the development process, to reduce
among individuals and individual projects; reuse existing designs and
code to build new systems, to reduce redundant work and maximize productivity;
introduction of standardized and integrated tools to raise the performance levels
of
the
average
programmer;
development tracks
for
and
provide
programmers,
engineers.
32
to
extensive
relieve
training
the
and
shortage
of
careerskilled
Perhaps the most delicate feature of the Toshiba Software Factory was
organizational
structure,
a
imposed
matrix
several operating groups and divisions,
all
located
referred to vertically-linked staff activities as
its
and the overall arrangement as
in
the Fuchu Works.
from
Toshiba
"product engineering system,"
industrial-sector activities as
horizontally-linked
system,"
over product departments
its
"production engineering
its
"engineering
matrix
management"
(Shimoda 1986: 103-104).
Established
1940 and
in
Tokyo, the Fuchu Works
areas:
in
on
set
198 acres
in
the western outskirts of
1987 had 7500 employees working primarily
in
four
Information Processing and Control Systems, Energy Systems, Industrial
Equipment, and Semiconductors (Printed Circuit Board Division) (Toshiba 1987:
5).
Operating departments within the divisions corresponded roughly to 19
product
lines
Each department contained sections for hardware and
(Table 7).
software design as well as for manufacturing (in the case of software, detailed
design, coding, and module test)
,
testing, quality assurance, and product control.
Approximately half the Fuchu Works' employees were software developers, with
a
third
working
Factory at any given time,
the Software
in
product departments
for
particular
projects.^"
The
assigned from
recognition
that
some
application areas required specialized systems analysis or engineering and design
skills,
and that
departments could benefit from sharing scarce software
all
development resources, led to the adoption of this organization.
Similarities in the
type of software the Fuchu Works built from project to
project allowed Toshiba to deliver "semi-customized"
programs that combined
reusable designs and code with newly written modules, rather than writing
software from scratch.
Toshiba also relied heavily on
methodology
Software
set,
the
gradually after 1976.
Engineering
This utilized
a
a
standardized
Workbench
(SWB),
tool
all
and
developed
version of the Unix operating system as
33
well
as
a
complement of tools
full
identification,
were the design
reusable
module
reusable
code generation, documentation and maintenance, testing, and
Important features of the Toshiba methodology
project-management (Table 8).
the
reusability,
design-support,
for
new program modules (generally
of
limited
requirement that programmers deposit
modules
library
a
in
each
a
to 50
number
certain
and the factoring
month,
for
lines)
reuse
of
in
of
objectives into project schedules and budgets.
Table 9 shows gross software productivity for the Fuchu Works and the
Software
Toshiba
Factory
from
programming or coding phase as
1972
well as
to
operating systems,
utilities,
reuse
rates
in
the
new code estimates from 1977 (the year
the factory opened). Particularly striking
equivalent assembler source lines or
and
1985,
is
the rise
in
productivity (delivered
EASL per person per month, excluding
and other basic software) and the obvious impact of
Increasing reuse (measured at the code level). Productivity rose from 1390 lines
per person per month
in
1976 to over 3100
1985
in
(the last year for which
Toshiba had made data public), while reuse levels (lines of delivered code taken
from existing software) increased from 13%
lines of
1000
in
1979 to 48%
EASL source code per month per employee
lines
of
Fortran,
the most common
in
The 3130
1985.
translate into approximately
language Toshiba used
in
1985''--
considerably more than the 200 to 300 lines of new code per month cited
in
various sources for U.S. programmers making similar real-time applications.
(defined
the
number
of
major faults
detected
after
18
'°
final
Quality
levels
testing)
also
improved dramatically after the opening of the factory, ranging
7 to 20
per 1000 lines of delivered code converted to EASL (the range
from
depended on the amount
as
of testing
customers contracted for) to
.2 to
.05 in
1985.
Toshiba
data
indicated
that
reusability
34
was
the
major
reason
for
Management pursued reuse
productivity and quality improvements.
accommodate rising demand and insure
despite variations
initially to
high level of productivity and quality,
a
by
individual skills and diverse customer requirements,
in
building products from standardized components reassembled or combined with
new components (Matsumura
and
recycling
This approach
1987)
software parts,
reusable
of
et al.
as
opposed
--
to
systematic creation
development from
scratch or "accidental" reuse -- lay at the heart of Toshiba's concept of factory
But how the factory carried out reuse
production of software.
in
the face of
long-standing organizational as well as technological problems provides
example
of
integrated
management:
of
product
a
superb
development
planning,
techniques, computer-aided tools, and controls and incentives.
On the
generally
organizational side, writing and documenting components for reuse
required
extra
time
time
in
to
individual
unless they see opportunities to save
resent this extra time,
the future.
customers might not want or
Project managers, and project members, also have
should not want to pay for.
good reason
that
On the
technical side,
many
particular project can recycle existing components.
match
in
factors influence whether a
These factors include the
application or function of the existing software compared to the
new
design requirements; the particular language(s) used and the characteristics of
the target computers;
and the program structure and degree
how independent modules are
of other
of modularity--
modules or subsystems
in
the original
program, based on the construction of the interfaces between various layers
a
complete
packages,
system
utilities,
(the
a
application
software,
subsidiary
applications
the operating system, and the hardware).
Toshiba did not solve
factory presented
new
in
all
problems related to reusability.
Rather,
the
system that simplified or restricted problems to manageable
areas, and that provided incentives both for project managers and personnel to
35
write reusable software and reuse
frequently.
it
Table 9 tracks the success of
these efforts, indicating that approximately half the software Toshiba's factory
delivered
in
including some with modifications
1985 consisted of reused code,
(usually no more than 20% of the contents of an individual module).
half
of
delivered
software
consisted
individual plant or application,
new code,
of
mainly
The other
written
an
for
some applications packages product
as well as
departments developed to serve as major components of customized systems.
The organization Toshiba created
term
concerns
Software
project
of
Reusing
Parts
to
managers
Steering
promote reuse and overcome short-
and
development
Committees
and
personnel
Reusing
Software
a
Parts
Manufacturing Department and Software Reusing Parts Center (Figure 2).
factory
formed
steering
a
committee
members, depending on the application)
set of needs suitable for a package,
to
areas
different
for
determine
if
The
different
(with
customers had
on
relied
common
a
and then allocated funds from the Fuchu
Works' budget for these special projects.
Some packages were
utilities
usable
1
in
different departments, although most served specific applications.'^
The Reusing Parts Manufacturing Department and Parts Center evaluated
new software (and documentation)
to
make certain
after certification, engineers registered the software
reuse databases
(libraries).
it
met factory standards;
in
department or factory
Registered items required
represent the functionality of the part or correspond to
well as a brief "Description for
a
a
keyword phrase
to
specific object,
as
Reusers" (DFR) that explained the part's basic
characteristics.
Management
also relied on an integrated set of incentives
encourage project managers and personnel
software parts
and
managers agreed
to
to take the time to write
reuse them frequently.
productivity targets
36
and controls to
that
At the start of each
they could
not
reusable
project,
meet without
reusing a certain percentage of specifications, designs, or code.
meetings held at the end of each phase
how
well
projects met
reuse targets,
in
programmer
At the
requirements.
in
components
in
the development cycle then checked
addition
schedules and customer
to
when building
level,
management required project members
Design review
register
to
new software,
certain
a
number
of
Personnel also received
the reuse databases, for other projects.
awards for registering particularly valuable or frequently reused modules, and
they received formal evaluations from superiors on whether they met their reuse
The SWB system,
targets.
deviations from targets
both
meanwhile,
at
monitored
the project and
reuse
levels
individual
well
as
as
and sent
levels,
regular reports to managers (Matsumoto 1981; Matsumoto 1984; Matsumoto 1987).
NEC
The
first step
toward
a
factory structure for software development at
consisting of founding the Basic Software Development Division at
Works
in
thereby
1974,
separating
development from hardware development.
NEC subsequently
suburbs, for
its
within the
established other
Tokyo metropolis or
other software needs, as well as dispersed programming work
throughout Japan
However,
all
Fuchu
operating-systems
organizationally
organizations at Mita, Tamagawa, and Abiko,
its
NEC
and
satellite
offices.''^
and separate histories of these
facilities
gradually
through
the separation
numerous
subsidiaries
presented greater problems for managers pursuing standardization and common
goals such as quality improvement throughout the
discussion below summarizes the key initiatives
a
NEC group. Table
10
NEC managers adopted
and the
to create
more effective multi-product, multi-process factory network.
The Software Strategy
programming operations on
a
Project,
started
in
1976,
attempted to integrate
group-wide basis (including
37
all
in-house divisions
and subsidiaries, rather than just the computer division). The objective was
introduce standards for tools, procedures, and methodologies for
development and
and error
aspects of management.
all
Yet
to
tailor
phases of
all
took several years of trial
it
projects, and divisions
to accomplish this while allowing individuals,
sufficient flexibility
to
standards to the needs of their products and
customers.
When the Software Strategy
effort,
for
led
Project ended, managers
who worked on the
by Dr. Yukio Mizuno, noticed another weakness
managing software development:
follow through on
NEC's structure
in
the lack of permanent staff to explore and
key issues or technologies. Thus, to insure continuity and
proceed beyond the Software Strategy Project,
Software
Product
software
engineering
Engineering
R&D,
research laboratories.
Laboratory to
making
this
NEC
in
company's
the
lead
organization
The Software Factory Design
1980 established the
part
of the laboratory,
software factories,
from higher-level concepts, such as
in
NEC's central
of
started
Project,
under the auspices
efforts
in
1986
developed guidelines for designing actual
tool
and methodology
standardization, to smaller details, such as how to arrange programmers' work
spaces or recreation areas.
NEC's Software Quality Control (SWQC) Program dates back
a
NEC managers
handful of
Several
specific
software
concluded
reflecting
that
any
indicated
strong
a
the manpower
revolution
correspondingly dramatic improvements
NEC
projects
differences
in
also
supported
programmer
the
skills
correlation
needed to
software
in
in
38
fix
First,
between
research
quality
Hence,
defects.
would
productivity
in
and
they
require
quality-control practices. Surveys of
observation
and
when
software quality-control study group.
a
conclusions came out of their reviews.
development
productivity,
established
to 1978,
that
experience,
"human
seemed
to
factors,"
be
the
i.e.
most
and that NEC had to
important elements influencing individual performance,
address
training
more seriously
if
were
it
to
make major advances
in
productivity or quality (Mizuno 1983).
NEC management
then set up
a
quality-control program that focused on
teamwork methodologies,
motivation,
performance.
individual
Since
'
created
a
NEC imported
formal,
in
groups helped solve quality
small
the concept of quality circles.
company-wide organization covering
all
Next,
Program.
brought major improvements
time,
NEC management
in
NEC
found the
SWQC
(Software
SWQC
practices
productivity through reductions
in
debugging
defects, and specification changes (Mizuno 1983).
The Software Problem Strategy
launched
and
also
1981,
in
aspects of software
production, management, services, sales, and training, under the
Quality Control)
affecting
departments
evidence from manufacturing
indicated that bringing employees together
problems,
and other factors
training,
in
1982,
explore
practices,
various
measures, and establish or formally designate
serve NEC's different product divisions.
in
three-year
attempted to encourage more standardization
quality-control
decided to act
another
Project,
three areas.
mapping" that consisted
First,
a
development
productivity-improvement
series of software factories to
Under
this project,
they carried out
of constructing a logistical
programming operations within
in
effort
NEC by product
a
NEC
executives
"software production
and organizational layout
(basic
software,
of
industrial
systems, business applications, transmission systems, switching software, and
microcomputer software), to determine which software houses divisions were
using to assist
in
development and whether divisions needed more help, such as
new subsidiaries that might serve
as additional software factories.
Second, they
formalized and systematized procedures for managing software subcontractors.
And
third,
they
launched
another
effort
39
to
improve and
link
software
and quality-assurance measures
productivity
by
establishing
Software
a
Productivity Committee to study documentation control, quality control, software
productivity and quality measurements, cost estimation,
support tools, and production environments. ^
project management,
The
personnel education,
R&D
centralized laboratory for software-engineering process
work quite
as well as
NEC managers had hoped.
had become too "academic"
in
did not
Some laboratory researchers
orientation while engineers and
SWQC
teams
in
To
the product divisions seemed to be doing more useful applied studies.
encourage more practical research that better met the needs
without eliminating
researchers
basic
all
NEC's
to
research,
Central
a
of divisions,
but
1987 reorganization moved the basic
Research
This
Laboratories.
no
involved
organizational change, since the Software Product Engineering Laboratory had
been
part of the central
a
labs.
However,
researchers
left
methods
and
Management then
tools.
removing the more
group more concerned with applications
academic
a
physically
expanded
the
number
of
researchers and divided them into four areas under the umbrella of
created
of
new
applied
a
newly
C&C [Computers and Communications] Software Development Group.
The Software Planning
software
quality-control
Laboratory
conducted
"^
Office took charge of running the company-wide
effort.
research
The Software Engineering Development
on
tools
and
integrated
development
environments, as well as software-engineering management, and established
a
consulting department to help transfer technology or assist operating divisions
and subsidiaries.
The C&C Common Software Development Laboratory developed
basic-software packages for microcomputers, while the
CSC Systems
Laboratory worked on compatibility and network technology.
40
Interface
Fujitsu
Fujitsu established a basic software division within
its
hardware factory
the mid-1970s that closely resembled Hitachi's Software Works
in
in
practices and
organization except that Fujitsu kept basic hardware development on the same
site as
An important
basic software development.
characteristic of Fujitsu's
development approach and organization was the gradual integration
for product, process, and quality.
as at
Direction of Fujitsu's efforts
NEC, came from the Quality Assurance Department
in
in
of controls
these areas,
the Numazu Works's
Software Division.
According to
a
chronology the department prepared, these efforts
three main phases:
prior to 1970,
managers allowed programmers
1978,
when
Fujitsu set up
Fujitsu
into
had no set procedures and
to test software at their
first
its
when
fell
own discretion; 1970-
product and process standards and formal
systems for inspection and quality control; and the period after 1978, when
Fujitsu
began placing more emphasis on structured design and programming
techniques and established the procedures that formed the basis of
phase was
practices.
Distinguishing
the
Assurance
Department's
concerns
documentation
conformance,
development process
brought major
itself.
or
example, the number of defects
In
applications,
to
in
not
product evaluation,
quality
in all
to 0.19 in 1977
current
broadening of the Quality
a
include
simply
but
testing
analysis
of
and
the
Toshiba, and NEC, these practices
Like Hitachi,
improvements
by Fujitsu dropping
last
its
as
well
productivity,
as
with,
for
outstanding basic-software code supported
and then
to 0.01
Fujitsu's decision to create a
from the same need Hitachi, Toshiba, and
in
1985.24
software factory stemmed
NEC encountered:
to
produce
a
variety of nominally different programs more efficiently, primarily sold with the
company's own hardware and basic software.
41
Management began cautiously.
First,
experimented with
it
centralized organization by setting up a Software
a
Conversion Factory Department
1977, with approximately 100 personnel.
in
This
modified programs customers wanted to run on new machines, which were not
compatible with Fujitsu's previous architectures, as well as software originally
written
other
for
Managers
believed
machines
companies'
conversion
operation
for
work was
fairly
on
hardware.
Fujitsu
straightforward
and that
centralization of personnel and equipment would foster standardization and thus
dissemination of good methods and tools,
resulting
since,
in
higher productivity and quality.
in
coordination
engineers defined
as
making tasks easier
with
a set of
Development
programming
project
for
Engineering
in
factory
establishment,
management,
Methodology),
Fortran, called
and
team
a
of
Fujitsu
called
introduced
SDEM (Software
support
tools
for
SDSS (Software Development Support System),
which Fujitsu quickly replaced with tools for
al.
This seemed feasible especially
structured design and programming techniques as well
procedures
detailed
the
manage and
to
COBOL programming
(Murakami
et
1981).
The conversion factory worked
include program construction
well
enough
to
expand the
facility
to
by adding another 200 personnel and charging
them with turning requirements specifications received from systems engineers
into code.
Prior to this, Fujitsu had
construction
in
The process
for
like
integrated projects, with no separation of these two functions.
new development did not work smoothly for
SDC had experienced
Fujitsu
managed systems engineering and program
a
all
projects.
Much
few years earlier (but without publicizing this),
managers found that many projects depended on close interactions with
customers and knowledge of very different requirements, or that writing the
application program required access to proprietary information which customers,
for security reasons, preferred not to give Fujitsu personnel unless they
42
worked
own
at the customers'
programming services
at
locations
around Japan,
Fujitsu
again
needed
the factory, less-experienced programmers became better
in
skilled systems engineers
more
provide
departing from the
able to build complete systems on their own, making separation of
of the
to
as Fujitsu improved the tools and reuse
In addition,
centralized factory model.
databases available
On other occasions,
sites.
work and use
unnecessary.
Rather than abandoning the objective of streamlining software development
through
that
a
factory approach, Fujitsu improved
different
consisted of expanding the scope of work
personnel
projects
where
it
do detailed design
difficult or
was
system gradually, recognizing
processes.
had different optimal
projects
factory
its
in
The major change
the factory departments to
--
and eventually systems design
unnecessary
to separate these tasks,
let
for
either
for logistical reasons or because factory engineers had the expertise to design
and build systems on their own (Figure 3).
Fujitsu
introduced other changes.
outside the factory,
design,
and
a
who
initially
One encouraged systems engineers
did surveys and project planning,
systems
program's structural design, to leverage their expertise more
widely not only by letting the factory personnel do more work but by writing
software packages to cover the needs of many users -- with
effort.
Any packages
jobs, as
is
to
spread
single design
or pieces of them that Fujitsu could deploy for custom
reduced the need to write new software.
or modified,
burden
the
a
of
programming more widely,
Fujitsu
In addition,
management
established or engaged more subsidiaries and subcontractors, as well as leased
methods,
tools,
beginning with
and
SDEM
training
in
services
1980 (Table 11).
to
customers
of
Fujitsu
hardware,
Fujitsu also continued to refine the
factory's methods and tools as the technology and customer needs evolved.
As
of 1988,
the Systems Engineering Group consisted of three main areas
43
with several divisions,
institute (Table 12).
departments, and subsidiaries, as well as
One
area, the
Common Technology
research
a
Divisions, included the
SE [Systems-Engineering] Technical Support Center, the Applications Software
The SE
Planning Division, and the Office Computer Systems Support Division.
Support Center
Technical
portion
of
its
Development
Support
housed
1500 programmers,
Engineering
(product
Software
the
as
well
for
Trade and Industry (MIT!)
in
in
1985
and
SIGMA
project (a joint
by Japan's Ministry
through
an attempt to disseminate,
the same type of work
stations,
support tools,
software techniques that factories such as Toshiba relied on).
about 20% of new applications done
as
handled about 75% of
all
a
company
International
of
communications network and standardization around UNIX as
environment,
Information
transfer).
Systems Engineering Support
customers),
Services (tools and methods), and the Japanese
and government effort started
a
other departments for Systems
planning
(technology
information
as
Department and
Factory
a
national
programming
and reusable-
The factory
built
the Systems Engineering Group as well
in
program conversion work (modifying software
to
run on new Fujitsu machines). Most of the remaining jobs, approximately 800
small
projects per year
in
the late 1980s,
went
to approximately three
dozen
subsidiaries as well as subcontractors outside the factory.
A second area consisted
in
of
departments with systems engineers specializing
particular industry applications (finance, insurance, securities, manufacturing,
distribution,
knowledge
NTT,
scientific, technical,
to specify
government), so that they had adequate
customer requirements and accurate system designs. The
third area, functionally specialized departments of systems engineers, designed
management information systems, "value-added networks"
services,
firms (the
for different on-line
personal-computer systems, and software for new telecommunication
new common carriers or NCCs)
44
EVOLUTION TOWARD FACTORY PRACTICE
CONCLUSION:
This review of major software and computer producers
in
Japan demonstrates that, whether or not companies adopted the factory
they
clearly
operations,
reusable
recycling
introducing standardized methods and tools, deskilling
as
well
and thus managing software development systematically across
The
series of similar projects.
effort and
label,
moved beyond craft practices and toward more systematic
engineering and even factory processes or organizations,
components as
and
the U.S.
a
transition to these practices required years of
passage through overlapping phases comparable to what firms
in
other industries encountered as they grew and formalized operations (Robbins
16-19).
1987:
software,
In
however,
the first
step
demanded an unusual
conviction on the part of key engineers, division managers, and top executives
This led to the creation of
that software was not an unmanageable technology.
formal
organizations
software as
facilitate
a
and
systems
control
rather
than
continuing
to
treat
loosely organized service provided free to customers primarily to
hardware
sales.
Imposing greater structure on the development process also demanded
continual
initiatives
to
introduce
and
refine
elements
manufacturing and engineering environments but not
1960s
the
and
"programming,"
early
1970s:
to limit the
a
product
focus
in
common
in
other
software, at least not
narrower than
in
simply
range of problems managers and programmers faced;
standards, at least temporary ones and tailored to specific product families, that
introduced solutions to recurring problems
and
tools, as well as
in
the form of methods, procedures,
provided guidelines on expected worker performance to aid
budgeting and scheduling; training of employees and managers, to standardize
skills
though without specifying
all
tasks for
all
situations; and development of
mechanized or partially automated tools for design, testing, product control,
45
reuse support, personnel and project management, and other functions, as well
as continual refinements of these tools
and methods as
well as
products (Table
13).
To
a
large degree, factory programs signaled commitments to long-term,
integrated efforts -- above the level of individual projects -- to standardize,
and support software development along the
structure,
software-engineering literature since the early 1970s.
to
do this more than others, for example,
personnel and competed
to
special
offset
urgency
to
suggested by
Some firms have needed
they were short of experienced
markets where other firms might offer comparable or
in
better software more quickly and cheaply.
a
if
lines
In
Japan during the 1970s, there was
improve levels of productivity, quality, and process control
shortages
of
particularly for complex
skilled
programmers and
rapid
rises
in
demand,
customized applications programs and lengthy basic
software for their new hardware systems,
introduced to compete with the IBM
System/370.
Every firm
encountered
attempting
to
IBM found
problems.
standardize programming centers
manage large
location.
difficulty
specifying
managers
in
Hitachi
in
general
its
factory
both
difficult
it
and
concepts
to
practices
and
coordinate
dispersed around the world as well as to
thousands
facilities with
SDC disbanded
introduce
of software
personnel centralized
in
one
software factories after systems engineers had
requirements for one unfamiliar application and project
disliked
separating
system
design
from
programming.
the early 1970s failed to reuse components or introduce one standard
methodology for
all
types of software.
methodology development on
a
NEC
relied
too
heavily for tool
and
centralized laboratory that became divorced from
the needs of operating divisions.
Fujitsu
gradually modified
its
applications
factory organization to allow factory personnel to do more design work.
46
Even
which
Toshiba,
focused on
a
located
relatively
practices and needs
process
R&D
narrow range
for
software
of products,
next to
its
factory
and
had to tolerate variations
in
among different departments. But though each Japanese firm
had somewhat different products, emphases, and experiences, Hitachi, Toshiba,
NEC, and
Fujitsu
And compared
to
pursued factory models long after SDC abandoned the
IBM,
they appeared to place more emphasis on creating
specific facilities with thousands of
programmers, many without formal software
or computer-engineering backgrounds, and relying on
among
tools,
Overall,
similar
paths
effort.
a
high level of integration
techniques, training, product designs, and other elements.
IBM and the major Japanese producers followed more or
in
managing software development.
less
Their efforts began with
decisions to create centralized organizations and management-control systems
for specific product families,
standardize around methods and tools tailored to
these products, and then provide partially automated support for development
and project management, before proceeding
more automated and "flexible"
What constituted
tasks.
a
tools,
to various
refinements as well as
capable of handling different languages or
factory was difficult to measure precisely, although
factories clearly seemed different from job-shop or project-centered approaches
in
their degree of focus on relatively routine designs, standardized methods and
tools,
standardized training,
across
a
and controls and integration
series of similar projects.
47
of
these elements
ACKNOWLEDGEMENTS
This article
is
based on research elaborated on
Software Factories
would
like
to
,
in
Michael A. Cusumano, Japan's
New York and London, Oxford University
thank the companies cited
in
the text
study and especially those managers who participated
Finnell,
a
former master's student
System Development Corporation.
at
Sloan,
Press,
who cooperated
in
interviews.
in
I
this
David
provided research assistance on
Many other colleagues and students
also contributed significantly to the ideas presented here.
48
1990.
at
M.I.T.
Table
1:
NATO REPORT ON SOFTWARE-ENGINEERING PROBLEMS
Lack of understanding
and designers.
in
(1968)
system requirements on the part of customers
Large gaps between estimates of costs and time with actual expenditures
to poor estimating techniques, failure to allow time for changes in
requirements, and division of programming tasks into blocks before the
divisions of the system are well-enough understood to do this properly.
due
Large variations, as
productivity levels.
much
as
26:1
Difficulty of dividing labor between design
design-type decisions must
still
one
in
be made
study,
programmers'
in
and production (coding), since
in
coding.
Difficulty in monitoring progress in a software project, since "program
construction is not always a simple progression in which each act of
assembly represents a distinct forward step."
Rapid growth
in
the size of software systems.
Poor communication among groups working on the same project,
exacerbated by too much uncoordinated or unnecessary information, and a
lack of automation to handle necessary information.
Large expense of developing on-line production control tools.
Difficulty of measuring key aspects of
A tradition
among
programmer and system performance.
developers of not writing systems "for
new and better systems, so that they
are always combining research, development, and production in a single
project, which then makes it difficult to predict and manage.
software
practical use," but trying to write
Rapid growth in the need for programmers and insufficient numbers of
adequately trained and skilled programmers.
Difficulty
of
tolerance)
in
achieving sufficient reliability
large software systems.
(reduced errors and error
Dependence of software on hardware, which
software difficult across different machines.
makes
standardization
Lack of inventories of reusable software components to aid
new programs.
in
of
the building
of
Software maintenance costs often exceeding the cost of the original system
development.
Source: Naur and Randell.
49
Table 2: IBM
SYSTEM JOURNAL TOPICAL ANALYSIS,
1962-1986
The list excludes articles
Each year and topic refers to one article.
describing individual products and refers to generic tools and methods.
Note:
SOFTWARE-ENGINEERING TOOLS
Design
1967 modeling programs
1981 software simulation as a tool for usable product design
1982 DB/DC data dictionary for businesssystems planning
1983 abstract design and program translator
Coding
1968
1975
1979
1985
Fortran subroutine package
program generator
automatic programming for energy management
tools for building advanced user interfaces
Testing/ Product Evaluation
1962 general purpose systems simulator
1963 generation of input data
1963 laboratory data-taking system
1964 systems simulation
1965 expanded general purpose simulator
1969 simulating operating systems
1970 automatic generation of test cases
1971 Fortran extended-precision library
1972 management business simulation in APL
1975 performance measurement tools for VM/370
1984 automatic generation of random self-checking tests
1984 design and use of a program execution analyzer
Phase/Project Management
1985 automating the software development process
Documentation
1985 project automated librarian
SOFTWARE-ENGINEERING METHODS:
Design
1963
1963
1963
1969
1972
1974
1974
1976
1976
1982
construction of minimal project networks
requirements generation
programming notation in systems design
three-value design verification system
techniques for developing analytic models
structured design
elements of probability for system design
top-down development using a program design language
HlPO and integrated program design
strategies for information requirements determination
50
1982
1983
1983
1984
1985
1985
technique for assessing external design of software
1965
1968
1969
1969
tables, flow charts, and program logic
system for implementing interactive applications
simple architecture for consistent application program design
software reliability analysis
architecture prototyping in the software engineering environment
a process-integrated approach to defect prevention
strategies for problem prevention
Coding
data management
coding for error control
1971 formal description of programming languages
Testing/Product Evaluation
1965 testing real-time system programs
1965 reliability of polymorphic systems
1969 synthetic job for measuring system performance
1971 time-sharing performance criteria and
1972 scientific computing service evaluation
1972
1973
1973
1974
1975
1975
1976
1982
1983
1983
1985
measurement
perspective on system evaluation
user program performance in virtual storage system
experimental evaluation of system performance
performance analysis of the Skylab terminal system
performance analysis of virtual memory time-sharing systems
testing in a complex systems environment
design and code inspections to reduce errors
cost-benefit analysis and the data-managed system
a
testing of interactive applications
performance/availability measurement for IBM information network
quality emphasis at IBM's Software Engineering Institute
Maintenance
1985 requirements methodology for software system enhancements
Phase/Project Management
1963
1972
1973
1975
1976
1977
1978
1979
1980
1980
1982
1985
1985
1985
1985
1985
1986
project evaluation and selection
chief programmer team
forecasting techniques
productivity of computer-dependant workers
model of large program development
method of programming measurement and estimation
measuring programming quality and productivity
managing VM/CMS systems for user effectiveness
management of software engineering
systems management
use of data flow to improve application development productivity
programming productivity measurement system for system/370
worldwide systems engineering
the system planning grid
programming process architecture
programming process study
software engineering
51
Programming Environment
1978 IBM's Santa Teresa Laboratory
1981 Human Factors Center at San Jose
1982 towards an integrated development environment
study of indices, tables of contents, and actual
My thanks to Wilson Wong, an
undergraduate in Electrical Engineering and Computer Science at M. .T.
for his assistance in reviewing the journal articles for a graduation
thesis project under my supervision.
Source: This
is
articles
based on
in
a
the IBM Systems Journal
.
I
52
,
Table 3: IBM
SYSTEM JOURNAL ARTICLES SUMMARY,
Table 4:
Key: BS
=
App
=
RT
=
Tel
=
Notes:
MAJOR JAPANESE SOFTWARE FACTORIES
Operating Systems, Database Management Systems, Language
Utilities, and Related Basic Software
General Business Applications
Industrial Real-Time Control Applications
Telecommunications Software (Switching, Transmission)
develop software for mainframes or minicomputers.
Employee figures refer to 1988 or 1989 estimates, based on company
interviews and site visits.
All facilities
Est.
Company
Facility /Organization
1969
Hitachi
Hitachi Software
1976
NEC
Software Strategy Project
Works
Fuchu Works
Mita Works
Mita Works
Abiko Works
Tamagawa Works
1977
1988-1989
Products Employees
BS
5000
BS
2500
2500
1500
1500
1500
RT
App
Tel
Tel
Table
5:
SOFTWARE PROCESS CONTROL
HITACHI, 1967-1976
IN
1967
Completion of a system for computing labor and machine hours for
software development (Kanagawa Works).
1969
Establishment of standard times for software development (Software
Works).
1971
Establishment of programmer ability coefficients and amendments of
standard times.
Completion of an estimation and budget system using standard times
a simulation system for resource planning.
and
Completion of a PERT Network System
diagramming system for schedule control.
Implementation of a manual system
processing and quality control.
1972
1973
(PNET),
time-series
for
an
automatic
analysis
of
test
system for budget-vs. -actual expenditure control for
work-hours and machine-hours for each project and department.
Completion of
a
Implementation of
a
manual system for document schedule control.
Implementation of
a
manual system for job process control.
Implementation
of
a
manual
system
productivity
for
analysis
and
project
and
analysis
and
control
1974
Completion of
department.
1975
Implementation
productivity
a
of
a
manual
analysis
system
system for each
for
defect
factor
quality control.
1976
Development
of a time-series statistical
program for forecasting defects
(FRCST).
Establishment of
a
standard scheduling system.
Introduction of structured design methods.
Source: Hitachi Ltd., Software Works, "Table 1.2 Background and Conditions
Affecting CAPS Development," Undated memorandum.
55
Table
ELEMENTS OF THE TOSHIBA SOFTWARE FACTORY
6:
Combined Tool, Methodology, and Management Systems
management system
--
Project progress
--
Cost management system
--
Productivity management system
-- Quality
assurance system with standardized quality metrics
baseline management
inspection and configuration management
system
design
--
A standardized,
--
Software tools, user interfaces and
--
Existing software library and maintenance support for this
--
Technical data library
--
Standardized technical methodologies and disciplines
--
Documentation support system
Personnel Systems
--
Quality circle activities
--
Education programs
--
Career development system
Physical Infrastructure
Specially designed
Source: Matsumoto 1987, p.
work spaces
155.
56
tool
for
maintenance
facilities
review,
Table
7:
MAJOR DIVISIONS AND PRODUCTS AT TOSHIBA FUCHU WORKS
Information Processing and Control Systems Division:
Information Systems for Public Facilities
Industrial Automation Systems
Industrial-Use Computers
Information- Processing and Control Systems Equipment
Energy Systems Division:
Digital Control Systems for Power Generating Stations
Automated Power Supply and Distribution Systems
Computer-Aided Business Operations Systems for Electric Power
Control Equipment for Power Plants
Electronics Equipment for Power Transmission Systems
Protection Equipment for Electric Power Systems
Advanced Technology-Applied Power Systems
Industrial Equipment Division:
Switch gear
Factory Automation Components
Power Electronics Equipment
Mechatronics Equipment
Elevators/ Escalators
Rolling Stock Systems
Transportation/Carrying Systems
Electronic Modules
Printed Wiring Boards Division
Printed Wiring Boards
High-Density Hybrid Functional Circuits
Source: Toshiba Corporation, "Toshiba Fuchu Works," 1987, p.
57
5.
Utilities
Table
8:
TOSHIBA SOFTWARE WORKBENCH EVOLUTION
Initial
Development
Support Tool
1976-1977
SWB-I
Improvement/Automation Focus
Programming
Environment
(programming,
assembly, compiling, debugging
level,
project files, program
program reusing and link edit)
Test Environment
1978-1980
SWB-I
1980-1985
SWB-P
Project
1980-1985
SWB-Q
Quality Assurance
1981-1983
SWB-III
I
the source
generation,
in
Design
Management
Support (requirements specification,
software
design
description,
and
documentation)
1981-1984
SWB-IV
Program Maintenance
1986-1988
Various
Document Preparation
Expert System [for Design]
Reusable Software
Integrated Database
Source: Matsumoto 1987: 12; "Development of SWB for Toshiba Fuchu Software
Factory," transparency copy received from Y. Matsumoto, 9/4/87;
Matsumoto interview, 1988.
58
Table 9:
Notes:
PRODUCTIVITY
&
REUSE AT TOSHIBA SOFTWARE FACTORY
Debugged and Delivered Equivalent Assembler Source
Lines Per Programmer Per Month, Averaging All
EASL
Projects
the Factory and Including
in
All
Phases and
Manpower (Requirements Analysis through Maintenance)
Index
=
Based on 1972 EASL productivity estimate (1230)
Change
=
Percent increase or decrease over previous year
Reuse %
=
Percent of delivered lines of code taken from existing
software with little or no modifications (usually no more
than 20% of a given module)
New Code
=
EASL
Quality
=
X
[
(100
-
Reuse %)/100
]
Defects Per 1000 Lines of Delivered Code Converted to
EASL
Year
Total
EASL
Delivered
Per Person
Per Month
Index/Change
(100) (%)
Reuse New Code Defects
(EASL)
Per 1000
%
EASL
PRE-FACTORY ESTIMATES:
1972
1973
1974
1975
1976
1230
1390
1370
1210
1390
100
113
Data Not Available
+
13
111
-
2
98
113
-12
+ 15
POST-FACTORY ESTIMATES:
1977
1978
1979
1980
1981
1982
1983
1984
1985
Data Not Available
1684
Employees
(All
Phases)
Table 10:
NEC SOFTWARE FACTORY IMPLEMENTATION
YEAR
INITIATIVE
FOCUS/OUTCOMES
1974
Basic Software Development
Division
Organizational separation of
software
from
hardware
development
1976-1979
Software Strategy Project
Standardization of data collection,
and
structured-programming
for basic and
applications software throughout
the NEC group, with the objectives
of raising productivity and quality
tool
methodology
1980
1981
Software Product
Engineering Laboratory
Centralization of process and
tool R&D for dissemination
divisions and subsidiaries
Software Quality Control
Establishment of a group-wide
methodology, training program, and
control measures for improving
software quality, including quality
(SWQC)
to
circle activities
1982-1985
Software Problem Strategy
1)
Project
2)
3)
"Mapping" of software
development activities
Subcontracting management
Software
productivity
improvement
1986
Establishment of Hokuriku Software
Development Center, based on
ergonomic principles and other
software-factory concepts
Software- Factory Design
Project
1987
C&C Software Development
Group
Reorganization of the Software
Product Engineering Laboratory and
expansion of applied research
Source: Fujino and Azuma interviews, 7/28/86; Mizuno interview 8/25/88.
60
Table 11: APPLICATIONS
SOFTWARE DEVELOPMENT AT FUJITSU
1964
Establishment of Systems Department.
1970
Centralization of applications systems development
Processing System Laboratory in Kamata, Tokyo.
1976
at
Information
Establishment of Software Engineering Team within Systems Department
SDEM (Software Development Engineering Methodology).
to develop
1977
Establishment of Software Conversion Factory and SDEM standards.
ERG (Executive Planning Guide) and C-NAP (Customer Needs Analysis
Procedure) commercialized for in-house use and sale.
1978
Introduction of
1979
Establishment of Software Factory Department
1980
SDEM standards
1981
YAC
1982
Commercialization of BAGLES (Banking Application Generator's Library
for Extensive Support).
SDSS ((Software Development Support System).
in
Kamata.
commercialized for sale.
(Yet Another Control chart) developed for design notation.
Commercialization of PARADIGM (methodology and tool for developing
reusable programs).
Commercialization of
ADAM
(Applications Development and Management
System)
1983
SIMPLE
(Logical
tool-set introduced for commercial sales, beginning with LINDA
Information Support Tool of Dataset) and DBSP (Database
Support Program).
YACII and YPS (YAC II Programming System) developed.
SDT (SDEM Design Technique) developed.
SDEM developed.
1984
On-line
1985
ACS-APG (ACS
Application Program Generator) from the SIMPLE series
commercialized.
1987
DRAGON (Driver and Stub Generator for On-line and Batch Test) from
the SIMPLE series commercialized.
SDAS (Systems Development Architecture and Support
Facilities)
commercialized.
EPGII/CNAPII commercialized, adding
and data-analysis capabilities
Source: Fujitsu internal data.
61
to
1977 version design concept
Table 12: FUJITSU
SYSTEMS ENGINEERING GROUP ORGANIZATION
COMMON TECHNOLOGY DEPARTMENTS
SB Technical Support Center
-- Systems Development Engineering Department
-- Software Factory Department
-- Information Support Center Department
-- Systems Engineering Support Services Department
-- SIGMA Project Systems Promotion Office
Office
Computer Systems Support Service Division
Application Software Planning Division
-- Application Software Planning Department
-- Software Distribution Department
INDUSTRY-RELATED DEPARTMENTS
Finance
Insurance/ Securities
Manufacturing/Distribution
Scientific/Technical
NTT
Government/Mass -Communication
FUNCTIONAL DEPARTMENTS
Management Information Systems
VAN (Value-Added
Network) Systems Engineering
Information Network Systems Engineering
Personal Computer Systems Engineering
NCC (New Common Carriers) Systems Engineering
SYSTEMS ENGINEERING SUBSIDIARIES
Industry-Related
Functional
Regional
FUJITSU RESEARCH INSTITUTE FOR ADVANCED
INFORMATION SYSTEMS AND ECONOMICS
Source:
Nikkei Computer
.
13
October 1986,
62
p.
79,
updated to 1989.
Table 13: PHASES
Phase
I:
(Mid-1960s
to Early
1970s)
Phase
IN
SOFTWARE
Formalized Organization and Management Structure
Factory Objectives Established
Product Focus Determined
Process Data Collection and Analysis Begun
Initial Control Systems Introduced
Technology Tailoring and Standardi z ation
Control Systems and Objectives Expanded
Standard Methods Adopted for Design, Coding, Testing,
Documentation, Maintenance
On-Line Development Through Terminals
Program Libraries Introduced
Integrated Methodology and Tool Development Begun
Employee Training Programs to Standardize Skills
II:
(Early
1970s
to Early
1980s)
Phase
OF FACTORY STRUCTURING
III:
(Late
1970s)
Process Mechanization and Support
Introduction of Tools Supporting Project Control
Introduction of Tools to Generate Code, Test Cases,
and Documentation
Integration of Tools with On-line Databases and Engineering Work
Benches Begun
Phase IV:
(Early
1980s)
Process Refinement and Extension
Revisions of Standards
Introduction of New Methods and Tools
Establishment of Quality Control and Quality Circle Programs
Transfer of Methods and Tools to Subsidiaries, Subcontractors,
Hardware Customers
Phase V:
(Mid-1980s)
Phase VI
(Late
1980s)
:
Integrated and Flexible Automation
Increase in Capabilities of Existing Tools
Introduction of Reuse-Support Tools
Introduction of Design-Automation Tools
Introduction of Requirements Analysis Tools
Further Integration of Tools Through Engineering Work Benches
Incremental ProductA^ariety Improvement
Process E- Reliability Control, Followed By:
Better Functionality £ Ease of Use
More Types of Products
63
UJ
ec
h
O
UJ
H
E
o
>
g
<
LL
LU
<
u
3
O
O
(A
U
Q
in
T3
C
TO
C
to
e
4-1
CO
Wi
<u
o
3
o
Figure 2:
TOSHIBA REUSE PROMOTION SYSTEM
PROJECT XXX
PARTS MNFG. DEPT.
1_
SOFTWARE PARTS STEERING COMMITTEE
REQUIREMENTS
DESIGNER
PARTS
CENTER
PARTS
^ETRIEVAU
PROGRAMMER*
PARTS
DESIGNER
PROGRMR
(^
E
L
I
V
TEST.
V i V
•RSI
D.B.
E
NOTICE
L_
SYSTEM
Source:
J
__i
•REUSABLE SOFTWARE ITEM DATABASE
Matsumoto 1987,
p.
173
CATION
UTILIZATION STATUS
CERTIFI-
CATION
CERTIFI-
E
SECTION
..t^I^^^12!L(^Z^^
PARTS
r
s
T
I
00
OS
REFERENCES
"The Dynamics of Software Development Project
Abdel-Hamid, Tarek 1984.
Management: An Integrative Systems Dynamic Perspective," unpublished
Ph.D. dissertation, M.I.T. Sloan School of Management.
Abernathy, William J. 1978. The Productivity Dilemma: Roadblock to Innovation
Baltimore, Johns Hopkins University Press.
in the Automobile Industrv
,
and James M. Utterback 1978. "Patters of Technological
Technology Review 80, June/July, pp. 40-47.
Innovation,"
.
1982. "Patterns of Industrial Innovation," in Michael L. Tushman and
William L. Moore, Readings in the Management of Innovation, New York,
Pitman, pp. 97-108.
Arden, Bruce W. (ed.) 1980. What Can Be Automated?
Cambridge, MA, MIT
,
Press.
Baum, Claude 1981 The System Builders: The Story of SDC
System Development Corporation.
.
Bemer, R.W. 1969. "Position Papers for Panel Discussion
Program Production," Information Processing 68
,
,
Santa Monica, Cal.,
--
The Economics
Amsterdam,
of
North-
Holland.
Boehm, Barry W. 1976. "Software Engineering, IEEE Transactions on Computers
Vol. C-25, No. 12 (December), 1226-1241.
'
.
Borum, Finn 1987. "Beyond Taylorism: The IT-Specialists and the Deskilling
Hypothesis," Copenhagen School of Economics, Computer History (CHIPS)
Working Paper.
Bratman, Harvey, and Terry Court 1975. "The Software Factory," Computer
(May), 28-37.
.
"Elements of the Software Factory: Standards, Procedures, and Tools," in
Infotech
Infotech International Ltd., Software Engineering Technigues
International Ltd., Berkshire, England, pp. 117-143.
,
Brooks, Jr., Frederick P. 1975. The Mythical Man-Month:
Engineering Reading, MA, Addison-Wesley
Essays on Software
,
1987, "No Silver Bullet: Essence and Accidents of Software Engineering,"
IEEE Computer April, 10-19.
,
Chandler, Jr., Alfred D. 1977. The Visible Hand: The Managerial Revolution
American Business Cambridge, M.A., Harvard University Press.
in
.
Conte, S.D. etal. 1986.
Software Engineering Metrics and Models
.
Menio Park,
CA., Benjaman/Cummings.
DeLamarter, Richard Thomas 1986. Big Blue:
New York, Dodd, Mead.
67
IBM's Use and Abuse of Power
.
Fisher, Franklin M., James W. McKie, and Richard B.
Mancke
U.S. Data Processing Industry: An Economic History
Frank, Werner
Sons.
Freeman,
1983.
L.
Peter
ed.
Critical Issues in Software
Software Reusability
1987.
.
.
IBM and the
1983.
New York, Praeger.
,
New York, John
Washington,
Wiley and
D.C.,
IEEE
Computer Society.
Fujino, Kiichi 1984.
"Software Development for
at NEC," Computer (November), 57-62.
Hagi,
Yoichi
et
al.
1986.
"Shisutemu
(Integrated Software Development
Hitachi hyoron 68, 5, 29-34.
Computers and Communications
kaihatsu
and
sofutouea
shien
Maintenance
System
EAGLE"
EAGLE'),
,
Softutouea Kojo 10 nen no ayumi (A 10-year history of the
1979,
Software Works), Yokohama, Hitachi Ltd.
Hitachi Ltd.
Horowitz, Ellis, and John B. Munson 1984. "An Expansive View of Reusable
Software," IEEE Transactions on Software Engineering SE-10, 5, 477-487.
,
Hounschell, David A. 1984. From the American System to Mass Production. 18001932 Baltimore, Johns Hopkins University Press.
.
Hunke, Horst, ed
.
1981. Software Engineering Environments,
Amsterdam, North-
Holland.
Jones, Capers 1986.
Programming Productivity
.
New York, McGraw-Hill.
Kobayashi, M. et al. 1983.
"ICAS:
An integrated Computer Aided Software
Engineering System," IEEE Digest of Papers--Spring '83 COMPCON 238.
244.
Kobayashi, Masakazu and Yoshihiko Aoyama, "Sofutouea seisan gijutsu no saikin
no koko" (Current Topics in Software Engineering), Hitachi hyoron 68, 5,
,
1-6.
Matsumoto, Yoshihiro 1981, "SWB System: A Software Factory," in H. Hunke,
ed.. Software Engineering Environments North-Holland, Amsterdam, pp.
,
305-318.
1984.
"Management
of
Industrial
Software
Production,"
Computer
(February), 59-71.
1987, "A Software Factory: An Overall Approach to Software Production,"
in Peter Freeman,
ed.. Software Reusability
Washington, D.C., IEEE
Computer Society, pp. 155-178.
,
Matsumura, Kazuo et al. 1987, "Trend Toward Reusable Module Component"
Design and Coding Technique 50SM," Tokyo, Proceedings of the Eleventh
Annu al International Computer Software and Applications Conference-COMPSAC. IEEE Computer Society Press, October 7-9.
68
McCue, G.H. 1978. "IBM's Santa Teresa Laboratory: Architectural Design for
Program Development," IBM Systems Journal 17, 1,
,
Mcllroy, M.D. 1969. "Mass Produced Software Components," in Peter Naur and
Report on a Conference
Brian Randell, eds.. Software Engineering:
Sponsored by the NATO Science Committee Scientific Affairs Division,
NATO, Brussels, January 1969, pp. 151-155.
,
"Apurikeshon shisutemu no koritsu-teki sekkei
Miyazoe, Hidehiko et al. 1980.
giho 'HIPACE'" (Software Engineering Methodology for Development of
Application Systems 'HIPACE'), Hitachi hyoron 62, 12, 15-20.
,
Mizuno, Yukio 1983. "Software Quality Improvement," Computer (March), 66-72.
"SDEM and SDSS:
Overall Approach to
Murakami, Noritoshi et al. 1981.
Process,"
in H.
Hunke, ed..
Software
Development
Improvement of the
North-Holland,
Environments
Amsterdam,
Software Engineering
pp. 281,
293.
Nakabayashi, Sen et al. 1986.
Research and Development
,
"C&C
Satellite Office
(April), 8-18.
81
and
Networks,"
NEC
Naur, Peter and Brian Randell, eds. 1969. Software Engineering: Report on a
Conference Sponsored by the NATO Science Committee, Brussels, Scientific
Affairs Division,
NATO.
Problems and
et al. 1984. "Software Engineering:
Perspectives," IEEE Computer (October), 191-209.
Ramamoorthy, C.V.,
Stephen
Robbins,
P.
1987.
Applications, Englewood
Structure.
Organization Theory:
N.J., Prentice-Hall.
Design,
and
Cliffs,
Schware, Robert 1989. The World Software Industry and Software Engineering
Washington, D.C., The World Bank, Technical Paper No. 104.
Shimoda
Hirotsugu 1986.
Keizai Shimposha.
,
,
Sofutouea kojo (Software factories), Tokyo, Toyo
Shooman, Martin 1983. Software Engineering:
Management New York, McGraw-Hill.
Design.
Reliability,
and
.
Thayer, R.H. 1979. "Modeling a Software Engineering
System," unpublished Ph.D. dissertation. University
Project
Management
of California at Santa
Barbara.
Toshiba Corporation 1987, "Toshiba Fuchu Works," Tokyo.
Tsuchiya, Nobuyoshi
C&C
et al.
Satellite Office,"
1986.
"A Control and Management System for the
NEC Research and Development,
81
(April),
19-23.
U.S. Department of Commerce 1984. A Competitive Assessment of the U.S.
Software Industry Washington, D.C., International Trade Administration
,
69
Woodward, Joan 1965. Industrial Organization:
Oxford University Press.
Theory and Practice
,
London,
Yoshida, Tadashi 1985. "Sofutouea no keiryo-ka" (Quantifying software), Joho
shod.,
26,
1,
48-51.
70
NOTES
1.
Interview with James Frame, 10/13/88, formerly manager of IBM programming
centers at Endicott,
N.Y., Raleigh, N.C., and
at Santa
Teresa Laboratory.
2.
Frame interview.
3.
Frame interview.
4.
Interviews with Frederick George, Manager, Network Systems Design,
Corporation,
Raleigh,
Processor Development,
5.
Letter
from Glenn
IBM
N.C., 1/6/87; and Mark Harris, Manager, Intermediate
I
BM
Corporation, Endicott, N.Y., 12/12/86 and 12/16/86.
Bacon,
former director of programming
at
the
Santa
Teresa Laboratory, to Cusumano, 4/25/88.
6.
Interview with John B. Munson, Vice President and General Manager, Unisys
Houston Operations, 10/4/87 and 10/5/1987. Also, Baum 1981: 224.
7.
Interviews with Munson and Terry Court, Manager, Resources Development
Laboratory, GM-Hughes Aircraft,
8.
Court interview.
9.
Interviews with Munson and Court.
10.
Interview
with
Ronald
6/22/89.
Inc.,
Atchley,
Baum
Also,
Director,
1981:
Software
222,
Engineering
Group,
Unisys/System Development Corporation, 3/27/87 and 4/23/87.
11.
Performance data
Shibata, Manager,
12.
is
from Hitachi
1979:
114,
updated to 1985 by
Kanji
Engineering Department, Hitachi Software Works, 7/23/86.
Shibata interview. See also Hitachi 1979:
71
5.
114-115; and interview with Shibata.
13.
Hitachi 1979:
14.
Interview with Kazuyuki Sakata, formerly Deputy General Manager of the
Hitachi Software
Consultant,
15.
Ltd., 9/10/85.
Toshiba Corporation, "Trend of Application Software Size," transparency
copy,
16.
Works and subsequently Managing Director, Nippon Business
received 15 March 1988.
Interviews
Corporation,
Yoshihiro
with
and
and 8/24/88,
9/4/87
former
Matsumoto,
Fellow
currently
Toshiba
Scientist,
Professor
Information
of
Systems, Kyoto University.
17.
This assumes
a
1:3 conversion for the
given that 60% of Toshiba code was
similar
intermediate level
another 20% appeared
18.
Productivity numbers can be found
88-94;
19.
requiring
a
in
assembler or
lower conversion
rate;
and
other languages (Matsumoto 1987).
in
1986: 92-114; Conte et
data, a fair rate for the data
Fortran; about 20% was
in
languages,
EASL
al.
1986: 251, 270;
in
Shooman 1983: 438-445; Brooks
U.S. Department of Commerce 1984:
Interview with Yoshio Ikeda,
numerous sources, including Jones
1975:
11.
Program Manager, Power-Generation Control
Computer Systems Department, Fuchu Works, Toshiba, 7/17/89.
20.
Interview with Yozo Hirai, Manager of the Quality Assurance Department
the Basic Software Division,
and Nakabayashi
et al.
NEC
Corporation, 9/8/87; also, Tsuchiya et
1986.
72
al.
in
1986
21
.
NEC
President,
manager
discussion
next
This
of
Engineering
is
Corporation,
Laboratory,
on
NEC
interviews
7/28/86 and 9/8/87,
Engineering
Software
the
based
with
Fujino,
Vice
and Motoei Azuma, former
Department
Corporation,
Kiichi
10/1/86,
in
the
Software
current
a
Product
Professor of
Engineering, Waseda University.
22.
Interviews with Azuma and Fujino, 7/28/86.
23.
Interview with YukioMizuno, Senior Vice President,
24.
This data
Manager,
is
NEC
Corporation, 8/25/88.
from Yoshida 1985: 49, updated to 1985 by Tadashi Yoshida,
Quality
Assurance
Department,
personal interview, 9/7/87.
2697
U5i4
73
Software
Division,
Fujitsu,
in
a
i6'<^''
3
TDflO
DD57TD53
7