i
:Mliliffi^':
HD28
0CT2O1S87
.M414
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
A U.S. "SOFTWARE FACTORY" EXPERIMENT
SYSTEM DEVELOPMENT CORPORATION
Michael A. Cusumano
David E. Finnell
Sloan School of Management
M.I.T.
May 1987
SP #1887-87
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
A U.S. "SOFTWARE FACTORY" EXPERIMENT:
SYSTEM DEVELOPMENT CORPORATION
Michael A. Cusumano
David E. Finnell
Sloan School of Management
M.I.T.
May 1987
SP #1887-87
M.l.T.
LIBRARIES
OCT 2
1987
RECEIVED
Michael A. Cusumano and David E.
MIT Sloan School of Management
5/31/87
Software Project Paper #2
Finnell
Working Paper #1887-87
A U.S. "SOFTWARE FACTORY" EXPERIWENT:
SYSTEM DEVELOPMENT CORPORATION
Introduction
SDC and
the "Software Factory" Experiment
Components:
Policies and Technologies
Factory
II.
Factory's Performance
Problems
and
the
Initial
III.
Factory
Created
New Problems the
IV.
Factory
Fate of the SDC Software
V.
VI. Subsequent U.S. Developments
Conclusions
Appendix Tables
I.
INTRODUCTION
This paper
or
not
such
is
companies
part of a larger study examining the question of whether
large-scale
as
choosing
are
to
a
development
software
and organizational
consideration?
manage
as
well
as
complex
engineering
with
range of
a
technological
corresponds to the spectrum usually associated with
i.e.
of
job shops,
flexibility
includes
batch organizations,
in
product mixes
proposal
the
factory environment for
facllties
in
tha U.S.
of
approaches
that
"hard" manufacturing,
The research
and technologies.
and
policy
software might look
to
strategic
and factories exhibiting various degrees
technology
and Japan
activity
like;
criteria
a
defining
project
what
a
survey of 38 software
determine where firms stand
in
relation to
these criteria; and detailed case studies examining the technology and policy
Implementation
factory model
process
*
.
followed
at
firms
identified
as
being
close
to
the
There are several interrelated conclusions:
"factory" approaches,
software
facilities
inherent
the U.S.
in
software
in
observable
is
as
a
in
(1)
statistically
a
and Japan.
(2)
technology
that
This spectrum, including
significant sample of 38
There appears
prevents
be nothing
to
some
managing the development process more effectively than others.
approach
development
But,
(4)
developing
to
not
is
by Hitachi and Fujitsu
relatively
lesser extent,
and
flexible
--
firms.
by the NEC group and Toshiba, and followed
general-use
techniques
quality-control
firms
led
are significantly ahead of most U.S.
--
disciplined
a
management concepts,
U.S.
--
software
aid
to
The
(3)
Japanese and U.S.
significantly different between
Japanese firms
applying
infrastructure
technological
a
from
firms
to
"factory"
tools,
approach
standardized
software
large-scale
competitors
--
production-
procdures,
effective
Other
development.
close to the flexible factory model
are
in
TRW
and,
to
a
Sperry and System Development Corporation (SDC), now both
part of Unisys.
This particular paper
Rand Corporation and then
U.S.
"software factory"
case,
for
a
on System Development Corporation, formerly
is
Burroughs subsidiary that attempted the
a
experiment
One
two main reasons:
larger attempt
and early 1970s,
in
to
the U.S.
is
in
mid-197ns.
the
that SDC's
reflect on
improve
the
performance
development of the operating
well
as
is
an
Software Factory
and other countries, beginning
in
first
important
is
part of
the late 1960s
various programming experiences and suggest
how an organization might bring together new
to
It
a
of
software
tools,
methods, and procedures
engineers.
system for the 360 family
numerous other government and
Analyses
of
private-industry
of
IBM's
mainframes,
projects,
as
were
particularly
contributors
important
Two
software engineering.
1975 and 1977 were
in
a
body
SDC Software
reports on the
on
literature
of
Factory published
part of this literature and presented the first well-
publicized
attempt to think
model
software
for
emerging
an
to
of
a
through
Second,
development.
than
rather
factory,
laboratory,
a
as
SDC
publications,
its
a
influenced the strategies and practices of several Japanese firms that have
promoted,
more aggressively
or
explicitly
highly
implicitly,
disciplined
approaches to software engineering; these firms include Hitachi, Toshiba, and
NEC.
The
and
ideas
practices
that
came out
of
the
SDC experiment
provided the basic model for the criteria used to define
in
The survey
the survey described above.
did
not
consider
their
factory
facilities,
behind only
TRW
facilities
software factory
reveals that, while
experiment
Unisys/SDC ranked 11th among 38
a
to
have been
also
a
SDC managers
success,
total
responding, and 3rd among U.S.
and Unisys/Sperry (see Appendix tables).
Thus,
the company has been more successful or determined than most other U.S.
firms
in
"rationalizing"
This paper
background
to
of
the
the
Software
infrastructure,
technological
System.
software-development process.
organized as follows:
is
company and areas
its
Software
Factory,
embodied
in
infrastructure,
Section
The
which
SDC's
first
two sections discuss the
experiment and
Factory
of business.
The
SDC's evolution
as
a
third section analyzes the components
can
be
broken
down
into
a
Software Dev elopment Manual
,
policy
and
a
which took the form of SDC's Factory Support
IV compares the performance of the
Factory
in
operation
with the five major problems
with
project
management and
Factory
the
arrived
created,
responsibilities
conflicting
at:
maintain
the
control,
relating
to solve;
an
insufficient
among managers,
factory
and
reusability
of
discusses two problem areas
section
to
these were concerned
availability,
tool
The next
program components (code).
that
was designed
it
procedures
and
the
and
some
"work
final
flow"
and
solution
SDC
the
of
but
tools,
decentralize the factory workers.
The main conclusions
succeed
as
technological
because
expected
and
this
of
policy
study
are
SDC attempted
on
infrastructure
experiment did
the
that
impose
to
a
not
sophisticated
mananagers and engineers
both
without adequate analysis or anticipation of the work flow and the reactions
of
its
from
personnel,
the
especially
survey
and
in
On the other hand, data
middle management.
comparisons
with
other
suggest that the factory model for software
is
especially
firms,
not
inherently
in
Japan,
impossible to
implement.
I.
SDC AND THE "SOFTWARE FACTORY
"
EXPERIMENT
The Company
System
Development
Corporation
(SDC),
Corporation and then Burroughs and now Unisys,
first
under
has served as
the
a
Rand
strategic
business unit primary responsible for doing software development and systems
engineering
for
the
United
States
Government.
U.S. and approximately 6,000 employees
in
1987,
With
it
was
facilities
a
across
the
major U.S. provider
"
of
hardware,
software,
command,
management;
airspace
and
workstations;
Engineering
and
control
According
networks.*^
Systems Group,
SDC's
in
and system integration for applications focusing on
the
to
Ronald
custom
systems;
intelligence
Director
SDC
Atchley,
Software
of
applications
software programs are "usually real-time systems [for] command and control...
on various pieces of equipment
--
DEC, Gould,
Much
mainframes, Amdahl, Univac 1100."
--
Department of Defense
have built and we would
scale systems
Burroughs, IBM
PC's,
minis,
work has been
of this
for the U.S.
"any large scale system that they would
like to build for
them.
.
.
They're
.
all
to
like
primarily large
where we can leverage our software development
skills
to
get
in
the
the bigger jobs.
SDC
early
has been a key defense contractor ever since the launching
SAGE (Semi-Automatic Ground Environment)
1950s of the
system program, the
to
SAGE "was
Atchley,
contract
to
became "the very
as
first
the
which
System
in
system ever built
spun
turn
Development
[by
defense
According
built.
The Air Force gave the
the beginning of SDC."
Rand Corporation,
Development Group
system ever
first large scale real-time
air
off
Corporation.
SDC];
it
their
System
SAGE thus
was the
air
first
defense system ever built, the first large scale computer system built, and
was the
other
first
stuff,"
company's
system with consoles, and light pens and displays and
recalled
work
requirements
transponder and data
fault
tolerant
Other
Atchley.^
link
and
for the
computer system for
recent
resources:
a
SDC
new
jobs
air
all
this
illustrate
the
traffic
Federal Aviation Administration
this
application
in
a
joint
it
control
(FAA);
a
venture with
Westinghouse; an automated search system for the U.S. Patent and Trademark
Office;
a
Medicaid Management Information System for Massachusetts;
Emergency Command and Control System (ECCS)
for the
Los
and an
Angeles Police
Department.
The Experiment
Initially,
it
seems
and unchanged even
Houston
of division
factory
idea
emerged out
structure for major development projects,
organizational
the
the
that
in
thought
facility)
of
Managers
1987.
labor and
it
led
SDC's
of
instituted
for
SAGE
by Jack Munson (now manager of
was possible
work flowing through
to
incorporate factory notions
lines
in
a
centralized facility,
as Atchley recalled:
We implemented
it
with the idea that we would have three
separate groups of people.
We would have the requirements
analysts, designers, or what now is possibly called system
engineering. We would have the program production, which is now
software engineering.
And we would have the test and evaluation.
Those three would be disciplines whereby the work would be done,
and the work would flow through the factory. ... In the SAGE
environment we had a group called Requirements Design Branch,
and they did the specification.
We had the Programming
Development Branch, and we did the coding and the preliminary
testing; and we had the System Test Group in Phoenix which did
the final testing.
So we just kind of moved that concept into
place and made it more formal.
The
1975,
an
first
public mention of the experiment seems to have come
in
May
when two SDC managers, Harvey Bratman and Terry Court, published
article
described
Monica,
in
an
IEEE
Computer
experimental
California.
,
titled
facility
"The Software
with
The procedures and
about
tools
200
This
Factory."^
programmers
in
Santa
under development were "not
when integrated and consistently applied, the
new or revolutionary" but,
authors believed they had the potential to radically change the way largescale
applications
was
software
explained their project
developed.
being
and
Bratman
Court
highly optimistic terms:
in
The Software Factory
is an integrated set of standards, procedures, and
supports a disciplined and repeatable approach to software
development [through] the concepts of structured programming, topdown program development, and program production libraries, and
incorporates hierarchically structured program modules as the basic unit
of production. ... [It] replaces ad hoc conglomerations of developmental
techniques and tools with standard engineering techniques. ... In brief,
the Software Factory is an excellent vehicle for the configuration
control of a system during operational and maintenance stages.^
tools
that
There seemed
lines
of
little
doubt that programs with hundreds
code would benefit from better systems to
labor and improve,
in
and experience frustrated the SDC managers and suggested
a
methodological
and
development process."'
available
to
deal
complained that,
founded
well
To change
with
body
problems
in
software
time
situation,
large
a
in
its
and
application.""
to
In
them "the lack
knowledge on
all
production,
in
the
software
it
with
the
tools
authors
system development or,
an integrated manner, but are put
Bratman and Court advocated
support
to
system programming project
emphasized "discipline and repeatability."
consistently
of
"they are either not used at
hoc each
this
and
regard to the tools and programming concepts
With
when they are used, they are not used
together ad
of engineers
But the poor correlation between program productivity
other programmers.
of
thousands of
the division of
facilitate
and other ways, the performance
this
of
a
simplify
begun."
methodology that
And they proposed
that will
is
"to
apply
it
and standardize
one bold stroke, SDC thus attempted to institutionalize
:
good
in
tools
and practices
software
problems managers had encounted
to solve the basic
development.
Bratman
and
Court
placed
these
into
five
categories
1)
Bratman and Court referred to
Lack of Discipline and Repeatability
absence of "standardized approaches to the development process.
Each time a software system is developed, the process is partially
reinvented, with the consequence that we never become very proficient
nor are we able to accurately predict the time and
at this process,
resources required."
:
the
2)
They complained that code production
Lack of Development Visibility
was often used to indicate progress in completing a software project,
but this did not measure "completeness of performance requirements,
Not
the design itself, or how well the code implements the design."
until system testing did it become clear how well a project was
progressing; and fixing problems at this stage "is exceedingly expensive
and time consuming... Managers have difficulty in tracking the
progression of the system from phase to phase, and as a result they
have problems in planning and controlling the developing system."
3)
The problem here was that
Requirements
requirements are subjected to interpretation and change
as soon as the system design and implementation process begin the
translation of requirements to computer programs."
Not only was it
nearly impossible to completely specify performance requirements before
detailed design and coding, but there were often disagreements on the
meaning of certain requirements, changes demanded by the customer,
and the like.
:
Changing
Performance
:
"Performance
4)
Several tools -- such as highLack of Design and Verification Tools
subroutine libraries, and
level languages, data-management systems,
debugging.
debugging tools, facilitated coding and
But Bratman and
accounted
for
only
Court asserted that these activies
about 20% of
"There are few widely used tools and techniques
development costs.
which provide significant support to other components of the
development process such as requirement and design specification,
verification and validation, project management and control,
"
documentation etc
:
,
5)
.
There were many application areas that
Lack of Software Reusability
required similar logic, but there was little capability to reuse software
components.
"Extensive use of off-the-shelf software modules would
significantly lessen the risk and shorten the time required for software
development. "^
:
8
The problem with the factory strategy was sustained implementation.
Due, apparently, to the objections of managers and programmers, as well as
to
some technical obstacles, SDC was unable
David
experiment,
concept,
it
Deaver,
to
develop
or
factory beyond the
its
involved
to "force"
better
tools
employees to follow the required
reusablity
facilitate
to
interconnecting of modules, and then encourage their use.
It
Deaver that the software factory was simply another one
to
that was valuable and exciting but "ahead of
SDC
retained
many
of the procedures
decided to decentralize -areas
corresponding
abandoned
and
at
to
programmers.''^
its
customer markets.
to
and
the
thus appeared
of
those ideas
time."''
developed for the factory but
it
divide programmers
SDC and seems
the
in
get software engineers to follow the factory
was necessary either
procedures,
carry
According to one of the managers
stage. '^
prototype
to
different functions
and
The word "factory" was
also
into
have become an anathema
to both
managers
Among other American companies during the
1980s,
despite the existence of several experiments applying computer-aided tools to
large-scale programming projects,
a
"factory" for software production
firms
adopted
the
factory
model
considerably more enthusiasm,
remarkable improvements
But
at
SDC,
questions
a
pioneer
remain:
in
in
none claimed
^"^
.
for
to
have built and maintained
On the other hand, several Japanese
software
and
combining flexibility
implemented
in
with
it
product design with
engineering productivity and quality control.'^
many
the very concept of the software factory,
Did the Factory accomplish what
it
set
out to do?
was there something with the technological or managerial components
Or
of
the
Factory, or the basic philosophy behind this approach for this company?
In
and why?
short, what went right and what went wrong,
II.
FACTORY COMPONENTS:
POLICIES
SDC's Santa Monica, California
Atchley,
who
AND TE CHNOLOGIES
facility
joined the project toward
attempted the Software Factory.
end
its
We were
only large open office we had at that time.
block long,
patios
in
two stories high,
stands, but we've moved out.
and
software systems
any
programming language.
terminating
predefined
retool
schedule.
a
in
'
building about
a
That building
still
"
size,
Factory
complexity,
as
The basic strategy was
specified
results
Their goal
was
the facility for each new system,
vehicle
a
application,
to
methodology that would make software production
process
in
three long corridors with cross corridors and
Court viewed the
of
"That's the
recalled
Everyone had an outside window.
the center.
Bratman
1977,
in
within
for
a
computer,
object
establish
a
or
standardized
'disciplined,
budgeted
developing
costs
repeatable
and
on
a
reduce the need
to
thereby allowing the organization
to
to
eliminate
or
get projects underway quickly and improve, through capturing the benefits of
experience,
aspects
such as program design,
and project management.
Bratman and Court did not, therefore, envision the
Software Factory as simply
a
maintained that the success of
the consistent
code production methodology,
building
a
housing
a
collection
and
on
tools.
They
software development effort depended upon
use of good techniques and practices,
management areas;
of
standardization,
in
both technical and
faithfully
established
maintained to reflect changing conditions and continual improvement.^
10
and
Two
(1)
and control components" comprised the Factory:
"basic structural
standards,
procedures,
and organizational principles,
Software Development Manual, to provide consistency
in
embodied
in
the
approach; and (2) an
integrated set of standard tools (the Factory Support System) to increase the
efficiency
and effectiveness of the software development process.
Support System automated many
Factory
provided
the
total
system development
of
the
framework,
manual
a
procedures,
Court explained,
contract
their
methodology was
requirements but was to stand on
its
consistent
own
and
dynamic management
data base, and tools to help assure cost and schedule integrity.
and
The
as
with
As Bratman
government
part of the Factory
system:
standards and procedures are computerapplication-independent and have been
developed as the foundation and basis for the Software
Factory.
In addition, they are compatible with US military
standards, US Air Force Manual 375 requirements, and the
better commercial practices.
Standards such as the US Air
Force System Command Manual 375 series developed by The
Electronic Systems Division, the Military Standard
380/480/483 series developed for DoD, and similar procedures
developed by the US Army, the Navy, and by the Joint
Technical Support Activity for The World-Wide Military
Command Control System Advanced Data Processing
Equipment were reviewed and incorporated where practical.
However, where the emphasis in these efforts was on
product descriptions. System Development Corporation has
expanded this to include detailed process descriptions,
including both methods and procedures.
In
general,
the
independent and
Software Development Manual (SDM)
SDC produced
the
Software
philosophy and methodology.
In
Development Manual
1987 this was
11
still
used
to
at
formalize
SDC
this
facilities
in
(California),
Paoli
(Pennsylvania),
decade after the Factory experiment,
(Virginia),
a
process
being
of
Camarillo
and
Monica
Santa
replaced
by
a
Department
of
although
Defense
and McLean
it
was
Military
in
the
Standard
(2167):
The SDM describes
of
set
a
standards and procedures for
the development of a software system from both tiftie-phased
and functional organization points of view.
It
recognizes
the close interralationship between software development
tasks and the functional skills necessary to do the job.
The
SDM is organized in sections which follow the phases of a
throughout its entire software development life
Each section provides detailed standards and defines
the objectives, the initiation and inputs, termination and
outputs, applicable reviews, and activities to be performed
for each phase prior to initiation of the next.
The SEM(
also defines and provides guidance for those functions that
are not unique to a specific phase but are applicable
throughout the entire project life cycle.
These functions
project
cycle.
.
.
.
are:
-
-
-
project management
configuration management
quality assurance
contracts administration
program control
Although
the relative emphasis on these functions varies
each phase of the software development life cycle,
they normally all operate to some degree throughout a
project.
The SDM defines each function, outlines its
purpose and goals, provides cautions concerning critical
areas of applications, lists inputs and outputs, specifies
with
mandatory
requirements,
applications
as
well
as
and provides examples of
recommending organizational
principles for control.
The SDM outlined the tasks
detailed
levels
objectives
concepts,
and
of
each
major
phase
of
activities
to
be
performed
the development
involved.
such as structured programming,
12
life
at
successively
cycle,
Recognized
more
discussing the
techniques
and
top-down program development,
and program production libraries were incorporated throughout the discussion
of each
a
development phase.
Overall,
the
SDM was designed
to describe
how
standardized methodology and available Factory tools would work together
to provide a step-wise refinement
approach to software development.
Factory Support System
The Factory Support System was the name given
extensible
facility
software
of
recommended methodology."
-
-
-
It
development
the
capability
assisted automated program checkout
facilities of
the sense that
it
under development
host machine (IBM 370,
the host operating system.
at
in
initially)
The design was
1975-1977, the tools were not
the time
and others never materialized:
all
there;
flexible
some were
Bratman and Court published their
"We
do the traceability [matrix]
that the technical
a
allowed new tools to be added as they became available.
Atchley admitted that,
1977,
supported
supported top-down development
automated management support
maintained requirements through implementation
provided library/history capability
possessed complete symbolic system data control
and used the
to
that
tools
"integrated and
provided these features:
The Factory Support System ran on
in
to an
still
don't have a good editor.
by hand..."
infrastructure of the
...
articles,
We had
Bratman and Court also noted
Factory was
still
evolving
in
1975-
although they were highly optimistic about their ability to completed
an "automated" facility:
Our long term plan is that the Software Factory will be
augumented by the continued development of more
sophisticated
tools
and techniques
13
such
as
application-
oriented process design languages, reusability technology,
correctness verifiers, and cross compilers, and will therefore
evolve into a truly automated software development facility.
The
as
"basic structural and control components" of the Software Factory,
Bratman and Court described them, included three main sub-systems:
Access and Control Executive (FACE): performed
and status gathering services for all processors,
supported the factory command language, integrated the
processors with the system development data base, and
provided program production library (PPL) services.
Factory
control
Integrated
Techniques
Management,
(IMPACT):
Project Analysis, and Control
utilized production data base
on milestones, tasks, resources, system
and their relationships to provide schedule,
resource computation, and status reports at the individual
components level or summarized at any module or task
information
components,
hierarchy level.
Project Development Data Base:
a data base established for
project using the facility and containing all the
schedules, tasks, specification components, test cases, and
their relationships along with the various forms of the
evolving software components and the complete development
status. This actually consisted of two parts:
a
software
development data base and a project control data base.
each
14
Software Factory Architecture
/T^
\L^
IMPACT
Capabilities
J
r
8
2-
S 3
E
i"?
3
e
o
I
—
— O^^
•*
w*
«ai
c
k.
n
I
z
O
C «
^ 3
C
«
2
general,
In
of
the project development data base facilitated the automation
management
program development,
library concept;
The
programs.
this
control,
and
kept copies of program modules from their
through
definition
functional
first
configuration
The software development data base extended the program
documentation.
production
visibility,
completion
their
as
object-language
project control data base maintained the system and program
descriptions and supporting management data, which was oriented toward the
system
software
performed
and the activities
structure
to
develop
the
software system.
IMPACT was
particularly
This assisted the manager of
the production of various
central
a
items,
the
to
management
software project
such
in
the
documents,
modules, user manuals, etc. for which his project was responsible.
him plan,
monitor,
and ensure the observance
configuration;
assists
him
project
and control the work;
in
define and
of quality
the preparation of management
progress,
and
in
spotting
potential
Factory.
planning and monitoring
specification
as
of
control
the
program
"It helps
software
assurance measures.
reports,
in
difficulties
It
the evaluation of
and
developmental
trends."
IMPACT supported the software development process, furthering the
concepts
of
programming and module design
by fostering
the
creation and integration of a hierarchical structure of program modules.
In
structured
preparing input for IMPACT,
upon the project manager,
entities of the project
a
necessary discipline of planning was forced
requiring
him
or
her
to
know and define the
and the relationships between them, such as
requirements and deliverable items,
requirements and program functions,
17
program functions and program modules,
high-level program modules and lower-level program modules,
program modules and equipment,
deliverable items and the activities that produce them, and
and the resources necessary
activities
IMPACT
--
areas
data
tools
generation
and
base
was designed
facility
management
to
maintenance,
be straightforward enough
any computer for the management
were
three
into
functional
and
planning
project
management descriptions.
make IMPACT portable
to
system development.
of
by providing such information
built
activity
were grouped
The data base generation and maintenance
and report generation.
control'",
to
project
support them.
to
to
IMPACT
Data
bases
as item descriptions
and
and
processed
involved three major functional
modules--
Data
could
be
inserted
interactively during the development cycle.
planning and control
Project
the
Scheduler,
resource
which
the
allocations;
and
derived
optimized
Threader,
which
critical
schedules
path
interpreted
the
hierarchical
structure of the software system and the organization of project work
manager or system architect could direct the Threader
trace
development status
the
elements
of
at
various
and the Trender, which output trends and anomolies
"These three
tools
constituted
increase
a
the
powerful
project
project
manager's
modeling
efficiency
the report generation function of
stored
in
his
included
the
in
plans."
capability
of
thread",
a
to
abstraction;
project performance.
Together they
designed
IMPACT provided access
Management
18
to
Summary,
to
also
significantly
Furthermore,
and effectiveness.
the development and control data bases.
requested
levels
a
--
integrated set of capabilities that help the
represent an
manager create and work with
project
to "pull
and
the information
Reports which could be
Resource
Allocation,
Summary, and the Module Run Summary reports.
Modification
several
addition,
In
Configuration Summary, Modification Index,
Index and Status,
Configuration
infrastructure:
technological
processing
were part
tools
(AUTODOC)
using comments
inserted
program flow analyzer that analyzed
a
to
several
thoroughness of testing.
in
provided
a
Data
Definition
common programming languages
(TCG) was an automatic technique
Developer
(TOPS) was
describe and verify
data interface logic
a
in
to
a
to assure that
(DATADEF)
as
tool
well
as
of
Test Case Generator
provided
that
in
Top-Down System
the
capability
to
describe much of the control and
the actual coding language.
AND THE FACTORY'S
evaluate
the
results
of
what were essentially engineering problems
Factory accomplished
program modules
all
for designing test data.
modeling
design,
INITIAL PROBLEMS
One way
Processor
program,
means of defining data for system programs written
central
the system would have compatible references to data.
III.
According to
this helped to provide information about the structure of the
aid
into
source program and
inserted calls to a recording program at appropriate locations.
SDC,
Factory's
Program Analysis and Test Host^'
the program modules by the programmer.
a
the
Automatic Documentation Processor
produced program and system documentation,
(PATH) was
of
in
operation with
inception.
19
P E RFORM ANCE
SDC's factory approach
is
to
to
solve
compare what the Software
the five problems that motivated
its
Probleni #1
Absence
:
of
stemming
process
development
repeatabilty
standardized,
a
solution
On the
and management policy.
"lack
a
of
to
the
discipline
and
"
The SDC
no.
from
approach
.
Did the Factory solution work
Yes and
predictable
in practicg?
involved
a
combination
the historical data on projects
positive side,
tracked through the Factory Support System data bases made
improve the predictability of future projects,
technology
of
possible to
it
long as managers
as
used the
data and engineers and other programmers repeated standardized procedures
outlined
in
the
Software Development Manual
procedures were standardized,
and this seems
that
SDC
to
with
allowances
have worked extremely well.
According
.
for
to
modifications
Testimony
to this
Atchley,
over time,
is
the fact
maintained the procedures developed for the Factory manual for
a
decade.
On the negative
the
data
bases
predictability.
kept
made
it
ensure
it
seems that managers did not effectively use
the
goals
of
discipline,
repeatability,
and
Atchley claimed that during the Factory's earlier days nobody
statistics
completion,
to
side,
on
reuse
rates,
and program quality
difficult
to
were directly related
tell
improvements,
productivity
(inversely
related
whether improvements
to the Factory or not.
20
in
to
defect
efficiency
schedule
rates).
This
or productivity
TO
r^ccp
LIBRARY
ATTENTION ^H-6.-«^lC)
magement
difficulties
work
:tory solution
integrated
i,
in
in
stemming
from
a
"lack
of
practice?
the Factory Support System, tracked
phases of the development process and provided
I
process
the
T
served
tool
its
a
project
control
construction.
In
mechanism for tracking
lines of authority
and responsibility
During the planning and system
development.
CT was
lance
as
and
letion status,
ut
and
flow
a
used to allocate resources,
check functional
requirements to assess their completeness and
IMPACT
te reports.
completeness,
as well as
while the
PATH
TOPS provided
tool
provided
visible
a
more
of testing completeness.
FROM
\j
LIBRARY
S
noted
e
lZ^ejU>-Jty
that
these
as indicated in the
le
DATE
tools
Factory
over
time
into
survey and supporting literature
type of technological
Software
evolved
later
infrastructure
on
Bratman
became common
in
and
large
Lib-ll-65
Problem #3:
Inability
to
define
accurately
a
customer's
performance
requirements at the beginning of development or to deal easily
with changes made during the development process.
21
"
Problem #1
Absence
:
of
standardized,
a
stemming
process
development
predict
from
a
.
repeatabilty
Did the Factory solution work
Yes and
The SDC
no.
solution
On the
and management policy.
practJM
in
involved
a
coi
the
positive side,
hi*
tracked through the Factory Support System data ba
improve the predictability of future projects,
data and engineers and other programmers
outlined
in
the
and
with
allowances
seems to have worked extremely well.
this
that
repeated
Software Development Manual
procedures were standardized,
SDC
lone
as
;
.
for
r
Testii
maintained the procedures developed for th
decade.
On the negative
the
data
bases
predictability.
kept
made
it
it
ensure
seems that managers
goals
the
of
disciplir
Atchley claimed that during the Factor
statistics
completion,
to
side,
on
reuse
rates,
and program quality
difficult
to
were directly related
tell
productivity
(inversely
related
whether improvements
to the
Factory or not.
20
im|
in
t
eff
Project
Problefn #2:
management
difficulties
stemming
from
a
of
"lack
development visibility."
Did the Factory solution work
Factory tools, integrated
Yes.
programmers through
means
all
visualizing
of
practice?
the Factory Support System, tracked
in
phases of the development process and provided
process
the
IMPACT
the
particular,
in
tool
and
flow
served as
a
project
control
construction.
a
In
mechanism for tracking
cost and schedule, completion status, and lines of authority and responsibility
for a project,
definition
designs
throughout
phases,
its
IMPACT was used
against performance
to
allocate
resources,
check functional
requirements to assess their completeness and
IMPACT
accuracy, and to generate reports.
assessments of design
During the planning and system
development.
completeness,
as well as
while the
PATH
TOPS provided
tool
provided
visible
a
more
quantitative assessment of testing completeness.
It
should
different versions,
on
individual
be
also
noted
but, as indicated
firms,
the
these
that
in
tools
over
time
into
the survey and supporting literature
type of technological
Court outlined for the Software
evolved
Factory
later
infrastructure
on
Bratman
became common
in
and
large
software organizations.
Problem #3:
Inability
to
define
accurately
a
customer's
performance
requirements at the beginning of development or to deal easily
with changes
made during the development process.
21
Did the Factory solution work
Yes and no
--
or,
rather,
worked
it
in
as
practice?
best as could be expected for
an engineering organization doing the type of projects
the
Development Manual
Software
capture company experience
down the best procedures
process,
can
be
available
interpreted
customer
defining
in
Portions of
did.
as
attempting
and
requirements
During
writing.
in
SDC
to
setting
development
the
such as IMPACT kept track of the interrelationships between
tools
system components; consequently, the effects
of
requirement changes on the
system architecture were more completely and easily determined.
On the other hand, SDC
starting
however,
is
so
many
different types of systems
the
design
process
doubt continued.
no
This
"problem,"
to a large extent intrinsic to the design process except for firms
making products with the most stable and standardized features.
"factory" solution could have been comprehensive,
Factory
for
and applications that accurately defining customer needs
different machines
before
built
infrastructure
was
designed
to
nor should
the
simplify
it
Thus,
But the
be.
handling
no
of
design
changes, and seems to have performed this function.
The Factory was not
Court,
Design,
pooling
this
appears
to
production,
the
technical
totally
centralized and,
according to Bratman and
have facilitated the requirements definition process.
and
test
resources
activities
of
the
were organizationally
Santa
Monica
facility's
separated,
personnel.
Top-level visibility came through the management of each of these activities,
and provided
at
the time of end-product turnover
22
a
natural point for review
and quality control.
a
was
project
control,
A program
office established for the entire life-cycle of
responsible
primarily
for
program management and
overall
customer (user) interface, requirement and performance specification
generation, system engineering, and quality control and assurance.
of this allocation of
computer location.
customer/user
in
responsibilities,
Rather,
the
Because
the program office was not tied to any
program
order to maintain
office
smooth
a
was
physically
"interface"
with
with
the
development
activities.
Lack of tools for design and verification.
Problem #4:
Did the Factory solution work
The Factory
Yes.
tools
between design
have become common
Problem #5:
in
to the design
and program coding.
other software
to
process and to smooth
These types
of
tools
Lack of reusability of code.
There was no
tool
lack of software reusability.
specifically
in
pra ct ice?
designed to combat the problem of
The possible reuse
of
software was thought to
be sufficiently facilitated by careful system component structuring,
relationships
provide
facilities.
Did the Factory solution work
No.
practice?
TOPS and DATADEF were designed
more automation and better verification
the transition
in
of
software
components
23
to
performance
specific
requirements,
and
not
inherent
documentation
improved
be the case.
out to
turn
in
Factory-developed
Atchley
recalled
the
software.
beliefs
of
This
the
did
Factory
architects regarding reuse of code:
They
if
we used this technique (top-down program
we used modules, that the reusability would fall out
it... you would decompose your requirements into functions and
that
felt
design) and
of
if
come up with code that was modular and reusable by following the
And then, as a fallout of that, you could
techniques in the SDM.
go back [to the software library] and find it and reuse it.
This
did
wrote and
not
work
because of the different types
computers.
of
programs
SDC
languages
and
types
of
object
programming concepts available
in
the mid-1970s probably made this goal of
the
different
extensive reusability and portability too ambitious.
because managers did
not
reuse components
often
to
use.
Atchley explained:
require
it,
Also,
For these reasons,
programmers did not even try very
from the library,
which also seemed difficult
[W]e changed machines from project to project, and it was very
to reuse the code.
We had an electronic funds transfer
program that was done on DEC's PDP-II
And then we went to
Emergency
the
Command and Control System for the Los Angeles
Police Department which was also done on the PDP-ll.
And we
tried to find some of that software that we could reuse, and some
of the modules.
We had not done a good job in EFTS [Electronic
Funds Transfer System] of providing a road map to get it, even
using some of the same programmers.
They would say,
know
did it and
think we saved it; I'll go look for it...
...They
expressed a willingness verbally to do it, and it sounded like a
It
good idea, but at that time we were unable to capture much.
was easier to do it than to go find it.
If you did find it you had
to recode it [a module in the library]
Basically, it offered you a
detailed design.
Not bad, but you had a different database, a
different language, different applications, and it was hard to find
the building blocks that remained the same.
We were at that time
doing the police system, an air defense system, a ground telemetry
system, and an intelligence classified system.
They were on four
different machines, they had four different sets of requirements,
difficult
.
I
I
.
24
and
I
to
it was very hard to find any reusability or savings among the
We did set up a library, where we collected all the
four of them.
Usage of that
software produced, filed it, and documented it.
library was very minimal.
and
David Deaver described the problem as relating to
which programmers did not
like to
have
philosophy that would
been
Programmers required retraining
there was
the
work, and
in
basis
of
programs
running
There was,
with
therefore,
make the Factory work.
to
resistance
reused
no
"more
as
Programmers allegedly did not
therefore was not as tight as
it
culture and
new program, although Deaver
a
programs relying on reused code because
and
in
in
order to write and use reusable code;
programmers'
of
aesthetics than performance."
of
atmosphere
problem of integrating someone else's previously-
additional
the
drastic change
a
necessary
written and perhaps more lengthy code into
described
rigid
a
it
like
the kinds
the code was not their own
all
could be, although performance levels
code were
tradeoff
real
problem of
a
in
in
actuality
efficiency;
not
but
a
problem.
programmers'
happiness and sense of aesthetics could not be ignored.^"
In
SDC
there was only one programming
1987,
was
that
admitted,
reusing
however,
code from
that this
and the same application.
about
it;
we
just do
it.
it
That's
And we're
it's
a
simple... no
really
programs.
"It's
fights,
not getting any static at
hard."
SDC
very high
number.
^^
is
Atchley
no arguments
all.
But when
actually bid on this project
turning out more
like 50%,
When asked how he
25
by
the same machine
could reuse 80% of the program code from existing
Atchley says that the real figure
considers
written
was possible because,
the applications aren't the same,
assuming
previously
being developed
project
felt
SDC
systems.
which he
still
about the low
incidence of program code reuse
"it's
do that
the idea
.
.
Atchley
been ten years, and we're now coming up with an ability to
commented,
.
the early days of the Factory,
in
good but the fact that
is
taken us so long
it's
...
is
kind
of sad."
IV.
NEW PROBLEMS THE FACTORY CREATED
Work-Flow Planning and Management
A serious "work flow" problem occurred that architects
appear
true
This made
have overlooked.
to
and
continuity
or
operations,
economies
it
and
scale
of
difficult
managers
for
scope on
from project to project as
learn
the Factory
of
impose
development
their
systematically
to
had been
as
hoped.
naming
In
envisioned
integrated
an
and
procedures,
tools
produced
manufacturer of
hard
to
stages
completion
of
stations,
be
with
a
flow
a
organization
Software
end
goods
until
organizes
"work
of
it
centralized
in
this
tool
development
to
The data base seems
can
be
found
in
SDC managers
"
development
costly,
to
progress
in
base
through
the production phases,
to
various
of
line
resembling
detail
a
work
conveyor
as
various
the product
have worked well and counterparts
many other
26
large
a
There was
activities.
add more and more
to
and
much the same way that
production
data
standards,
higher quality,
reached the end of the factory's
and techniques were used
framework.
less
process"
that carried an evolving product through
tools
a
product,
Factory,
software
of
which would allow
more efficiently
supposed
"The
approach
their
to
softwa re- development
organizations.
Programmers did not seem
to
mind this type of
managers never required them
to
drastically
example,
Atchley
modules.
suggests
work
flow,
altiiough
change their habits and,
reuse code from the program
routinely
a
library or write
for
reusable
many programmers were not even
that
particularly aware of what was going on:
It was a term used and a
They didn't even know it happened.
way of doing work, but as far as most of the programmers were
don't think there was any
concerned, life went on as usual.
They knew the term, they
great culture shock or resistance to it.
knew they had been gathered from the various four corners of the
company and put together, but they didn't consider themselves in
There were lots of cartoons on the wall about the
a factory.
Factory and all these kinds of things, but truthfully
don't think
the programmers considered themselves factory workers.
I
I
A
far
more serious
concept as intended.
dropped,
that
and management practices made
planning,
was not
problem was
a
it
the
nature of SDC's
difficult to
Because projects came about on
a
constant flow of work to feed the Factory.
SDC
also continued
its
custom of laying
off
business,
implement the "flow"
contract basis, there
When the work
level
even trained people.
Atchley admitted the lack of work undermined the factory concept, although
he also saw this as
a failure of
production planning:
We
If you were going to have a
did not have the work to sustain it.
factory, and the work wasn't coming through all the time, then you had
these ups and downs.
You somehow had to provide the flywheel money,
No one was
some other projects, to keep people between programs.
willing to make the sustaining investment to keep a flywheel going
there was no planning to take care of that.
Every job was totally
different.
It
would work a lot better if we had a specific line of
.
.
27
.
.
.
,
business
"Matrix" Management
type
for
problem was that the Software
Factory
created
A
related
of
matrix management whereby there were project managers responsible
responsible
for
different from
developed
the
the
actual
then
software.
effect
managers
in
principle,
In
a
the
Factory
this
was
no
non-software firms that had product or project managers who
products
manufacturing
created
producing
and
customers
with
directly
dealing
in
take
jointly
care
Factory
management or preparing
of
with
final
without
its
manufacturing
production.
anticipating
managers
But
the
to accept the
28
imput
and
then
SDC appears
difficulties
new structure.
of
to
let
have
matrix
Software Factory Organizational Principles
o
C_3
:
As shown
in
the figure outlining the Factory
the software requirements of
program,
"
the
organizational principles,
s
major project were done "independent of the
a
program being
a
large contracted
when
a
project manager suddenly was
the discord this created
Atchley
project.
recalled
no longer
in
control of development activities:
didn't have the management tools in place
what happens is
that you've got a program manager who's come to you with his
program and he's given you the task to do, but really he doesn't
And if you overspend, what's he
have any control over you.
He has to have the job done.
going to do?
So there was not
enough incentive on the part of the factory to produce at an
We
.
.
.
were the complaints of the other
them money ... there were some
complaints about the fact that now they had two managers, that
they had doubled the overhead
since you had the management
of the Software Factory but you still had the management of the
program.
So there were some complaints about that.
economical
cost
managers.
It
.
.
.
was
[These]
costing
.
.
.
.
Some managers accepted the Factory concept
software
success.
development,
were even
excited
about
But others, according to Atchley, seemed
influence on
their
and
as
.
viable structure for
a
it
with
to feel
hopes
for
its
they were losing
the software development processes over which
they had
control
we took
managers and we consolidated into
That left some men and women at that same level who no
three areas.
longer had a direct influence, and they became plans and programs
people. .. they were in the situation of getting their projects done by the
Software Factory.
That left some of those people uneasy... They
wanted their hands on that.
They wanted to be able to touch their
programmer.
So there was a lot of resistance from program
management to the idea. There still is.
Some
a
of the managers felt they were
lot of people who'd been program
30
losing their
turfdom
"
.
.
.
.
These "plans and programs people"
Factory and the program office,
of the Factory experiment,
to the customer's site to
served
as
the
interface
remaining with the customer.
between
the
After the end
programmers then went with the programs people
do actual development:
[Plans and programs people] chase new programs, help the
proposals, help develop the new business, go out and talk to
customers, help with the strategic planning, determine where we
are going in a particular line of business, become experts in that
line of business, and when we win contracts they become the
They are a
interface out of the program office with the Factory.
They used to give us the specs and say
part of the organization.
The plans and programs person would
'Go produce this software.'
be the interface, and he would be controlling the budget ... As it
Is
now, we [program implementation] are a part of the program
We moved the people
office; we work in their area, physically.
into that physical area; we no longer keep the people physically
separated [from the program office]
THE SDC SOFTWARE FACTORY
V. FATE OF
Decentra ization
I
Because the Factory as attempted
at
SDC
created problems as well as
management gradually dispersed the Santa Monica programmers
solved them,
into
different
sites.
^^
In
functional
general,
this
areas
by
assigning
them
to
different
customer
was the strategy SDC has followed for the past
decade, although, organizationally, management has tried to focus particular
facilities
on specialized lines of business.
Most firms, however, according to
the survey,
were more centralized than SDC.
even SDC's
Paoli
work coming
into
Atchley admitted as well that
(Pennsylvania) facility successfully adopted the concept of
one large
facility
where factory-type productivity
be systematically applied, even though
31
Paoli
tools can
does not use the term "Software
Factory"
(which
remains an
SDC trademark).
simply did not work out as well as intended.
Some
factory
work flow and technological
As Atchley explained, the factory workers now go
You
of the
at
Santa Monica
Factory discipline
remained while the physical centralization and notions of
and procedures
centralized
The attempt
would
a
infrastructure disappeared.
to the
work:
see a sign in this building that said
Software
We've moved on ... All the tools weren't there; some
were, some weren't.
The concepts were there, the ideas were
there, but it wasn't all there. ... They weren't really dismantled.
They were in disuse because new ones came along, and we just no
longer used them.
The only thing we're still using, and we won't
use it much longer, is PDL [a Program Development Language SDC
developed for in-house use].
We're still using it, but we're going
to BYRON [a commercial product], and within the next six months,
we're going to be all converted over to BYRON. ... PDL was a
Pascal-based system.
That's the only thing left that we're still
using.
We're moving to ARGUS, we're using a new editor.
Times
change
What we're trying to do now is establish a common
software environment where we provide tools and the environment
to develop software from the beginning up to the coding stage.
.We provide the cadre of people to do the job as opposed to
In Paoli, they're still running the
taking the job into the factory.
other way.
But in Santa Monica, we've drifted from that quite a
bit.
We still have the disciplines, standards, and concept, but the
work does not flow through the factory.
The Factory workers go
to the work.
Factory.'
.
.
.
.
.
Atchley's
positive.
in
not
...
final
assessment
of
the
factory
experiment was
Aside from the work flow and management problems,
efficiency were not obviously attributable to the Factory,
the system did not focus on productivity and reusability,
approaches, such as
at
Toshiba.
improvements
perhaps because
unlike other factory
On the other hand, he believed the Factory
increased awareness among software engineers of the product
greatly improved quality through
generally
a
life
cycle,
and
structured approach and more formalized
testing procedures.
32
think that while we may not be organized the way we were, our
seriously
people are more aware of the software life cycle now.
Were the people more
doubt that it [the Factory] reduced cost.
hard to say they were more efficient because of
It's
efficient?
the Factory or that they became more efficient because we became
presume there was a fallout there on efficiency
more efficient.
think the structured approach helped quality
and productivity.
think the fact that we became very formal with the
immensely.
independent test organization improved the quality of the product
Whether that was the Software Factory or not,
we delivered.
don't know.
I
I
I
I
I
I
Atchley,
had
as well
potential
however,
has
procedures
Deaver,
as
for
not
real
Factory concept was workable and
also felt the
improvements
factory-type
in
SDC,
productivity.
done much with the idea beyond the standardization
and the greater work-flow centralization
at
of
Atchley
Paoli.
concluded:
think it's a good concept.
think discipline can be applied to
software
the
development process.
think that reusability and
productivity should be the main factors out of it.
We're not doing
as good a job today as we were ten years ago in keeping it alive.
We've made a lot of progress, but we could be better if we had
really actively pursued the concept and grown the concept as new
ideas came out of the schools and papers were written.
If we'd
kept the factory concept more prominent,
think we would have
been able to put more of those ideas in sooner.
As it is now,
there's a lag.
Instead of being at the forefront, we're kind of
dragging.
I
I
I
I
The Survey Response
Another way
experiment on
SDC
to
is
gauge the impact
as
of
1987 of the Software
from the company's "performance"
large-scale software facilities or firms
33
in
the U.S.
in
Factory
the survey of 38
and Japan
(21
U.S.,
17
Japanese).
The SDC/Unisys
1975-77
SDC
Atchley)
(from
general
covered
As noted earlier, these questions were largely based on
company practices.
the
response
articles
describing the Factory's technology,
policies,
and
objectives.
SDC/Unisys did not come out
it
ranked 22nd
of
factory
the
which
the
experiment
model
policy/methodology
overall
2nd
in
studied,
(77%,
13
percent
above the mean).
despite
a
place of 10th
policy and 3rd overall
in
SDC/Unisys
biased.
criteria
(75%, 8 percent
facilities
seem more obvious
is
the
facilities).
Effects
area,
toward
policy
ranked
above the
9th
mean),
in
SURVEY ANSWERS KEY:
CAPABILITY OR POLICY
CAPABILITY OR POLICY
2 =
CAPABILITY OR POLICY
=
CAPABILITY OR POLICY
=
CAPABILITY OR POLICY
1
n =
I.
38 (Jap.
=
17,
U.S.
IS
IS
IS
IS
in
technology,
llth
SDC/Unisys ranked
FULLY USED OR ENFORCED
FREQUENTLY USED OR ENFORCED
SOMETIMES USED OR ENFORCED
SELDOM USED OR ENFORCED
NOT USED
= 21)
TECHNOLOGY/FACILITY INFRASTRUCTURE
ALL
15
Furthermore, among U.S. firms and
(see Appendix tables).
IS
the
and
MEANS AND STANDARD DEVIATIONS FOR SURVEY QUESTIONS
4 =
3 =
where
the 8 technology criteria,
in
one percent above the mean for 38
(72%,
total
well
G
'it's
not used as frequently as
we would
like.
A central production or development data base connecting programming
groups working on a single product family to track information on
task completion, resources, and system components, to
facilitate overall project control and to serve as a data source for
statistics on programmer productivity, costs, scheduling accuracy, etc.
milestones,
SDC:
response was above the mean for the sample,
than thae average U.S. applications
response, although it would have been average for
the Japanese firms.
SDC reported that their central
data base was project or line-of-business (facility)
oriented; this was the usual practice in other firms
This
3
and
higher
as well.
E.
Project data bases standardized for all groups working on the same
product components, to support consistency in building of program
modules, configuration management, documentation, maintenance, and
reusability of code.
potential
SDC:
answer was
considerably above average, and,
seems to reflect the continuing influence of a
factory-type approach to development.
This
4
again,
F.
A specific group or groups designated to develop and disseminate
methodologies and tools to automate tasks such as requirements
specification and design, coding, documentation, system testing and
debugging, as well as to facilitate standardization of practices and
division of labor, and effective managerial control over all programming
activities.
G.
Above average,
SDC:
4
A
interface providing the capability
data bases, the centralized production
especially for U.S.
system
project
to
data
firms.
support tools,
base and program
link
libraries.
SDC:
This
3
answer was
average
for
a
above the sample mean and above
U.S. response but equal to the
Japanese average.
SDC also reported this interface,
which had been described in the Software Factory
experiment, was "still evolving.
"
H.
Automated or
support
systems
semi -automated integration of applicable data from
tools and development data bases with management control
(project data bases and the central production data base), for
36
phase of program development; and the utilization of this
capability to facilitate budgeting, forecasting, maintenance, and overall
llfe-cyle cost control on current and future projects.
each
SDC:
II.
METHODOLOGY
which was low due
commented that "This
dream."
This was above the sample mean,
to the U.S. average.
is the goal -- it might
& POLICY
SDC
be
a
INFRASTRUCTURE
also
A.
Use
standardized design language
of a
SDC:
4
This was double the average response.
SDC used a
it
had developed based on Yourdon and using
the UNIX operating system.
tool
B.
Use of
SDC:
C.
Use
3
This was above the mean, though equal to the
Japanese average.
SDC continued to use PDL, which
it
had developed for the Software Factory, though it
was changing to Byron.
standardized coding language
of a
SDC:
D.
standardized module-specification language
a
2
This was below average.
For most projects, SDC
used C, but new programs used Ada, and others used
Algol, Fortran, Pascal, Jovial, and CMS2.
The range
of languages reflected the diversity of SDC products
and customers.
Emphasis on high-level abstraction (data-type or procedure abstraction;
object rather than variable orientation)
SDC:
E.
Above average.
SDC claimed to place the highest
emphasis on this, along with the ability to test.
3
This was an average
the U.S. averages
although higher than
response,
Planning for portability at the module-design level
SDC:
H.
4
Planning for reusability at the module-design level
SDC:
G.
Above average.
Planning for maintainability at the module-design level
SDC:
F.
3
3
Above average.
Monitoring of how much code
SDC:
3
is
being reused
Above average,
38
and
especial
higher
than
the
U.S.
As noted in the data summary above, the
means for this question was 3.16 for Japanese
responses.
overall
and 1.29 for U.S.
I.
"Layering" of reused modules from the program
newly written code, to create new programs
SDC:
J.
2
library,
with
along
This was an average response.
Layering can be
interpreted as a factory-type approach to program
development in that it is an effective way to
combine existing modules with new code, as well as
develop programs that have distince components and
are thus more easily maintainable or transferred to
different computers (portable).
Cataloging for the program library of common functional modules (e.g.
date verification routine)
SDC:
K.
facilities.
2
Below the sample mean but average for the U.S.
Cataloging for the program library
table or linked-list managers)
SDC:
2
a
data
of
modules
abstraction
Average for the sample; somewhat high for
though still below the Japanese mean.
(e.g.
U.S.
a
facility
L.
Writing of documentation
to
accompany modules placed
in
the program
library
SDC:
M.
Average.
Requirement that, if changes are made
program library, the documentation must
SDC:
N.
3
4
the code of a module
in
in
the
changed
also be
Above average for the sample;
average.
equal to the Japanese
management promotion (beyond the discretion of individual
project managers) that new code be written in modular form with the
intention that modules (in addition to common subroutines) will then
Formal
serve as reusable "units of production"
SDC:
4
Considerably
in
higher
future projects
than
especially high for a U.S.
39
the
facility.
sample
mean
and
Formal management promotion (beyond the discretion of individual
project managers) that, if a module designed to perform a specific
function (in addition to common subroutines) is in the program library
system, rather than duplicating such a module, it should be reused
O.
SDC:
Considerably
4
higher
than
especially high for a U.S.
SUBSEQUENT
VI.
In
his
with
in
essay
now-classic
,
software
on
Frederick
P.
engineering
published
in
.
Based on
-^^
experience
his
Brooks set the tenor for development of software engineering
IBM, and he did so promoting approaches that, with the exception of his
suggestion to
limit
the number of people on one project,
have generally been
incorporated into software factories and improvement efforts
firms:
(1)
independent
Consideration
subtasks
sequential
of
and
25-26),
(pp.
charts or critcal path analysis
use
154-158),
(pp.
and
constraints
variety of
a
in
number
the
concrete milestones,
of
with
to deal
The team approach
31-37)
(pp.
languages (p. 93) to deal with
experienced programmers
formal
definitions,
system
improve communication
"efficiency
and
wide discrepancy
a
(pp.
(3)
of
The use
formal
62-69)
conceptual
tools
in
and the difficulty
(p. 30),
programmer productivity.
and software
of
precise
conferences
such
40
in
a
PERT
16-20).
high-level
as
the performance even of
of
increasing
written
and
large
individual
specifications,
other
techniques
and overcome the difficulty
integrity"
of
poorly developed
estimating techniques and methods to monitor schedule progress (pp.
(2)
1975,
Brooks, Jr., discussed problems very
what Bratman and Court had identified
OS/360,
and
DEVELOPMENTS
U.S.
The Mythical Man-Month
similar to
mean
sample
the
facility.
project
of
to
achieving
with
many
participants
(pp.
31).
Use
(4)
of
pilot
documentation,
and
definition
progress
in
with
deal
to
intermodule
of
design,
interfaces,
extensive
complete
standard calling sequences and table-driven techniques,
the use of very-high-level
117-118),
top-down
using
change through careful modularization
subroutining
systems and systems designed for
and
languages and self-documenting techniques
frequent
alterations
development and testing.
(5)
in
specifications
that
(pp.
delayed
Better testing techniques and tools
such as top-down design and structured programming (pp. 142-144) to reduce
bugs and overcome
(pp.
difficulties in
system debugging and program maintenance
120-121).
A
recent
article
by
R.
Goldberg,
a
consultant
the
at
IBM Software
Engineering Institute, outlined the progress IBM and other firms have made
In
developing or using these tools and techniques.
the late 1960s,
According
to
when OS/360 and other projects prompted the
engineering-type
practices
software,
to
management focus on the individual
the
was
or
in
application
of
to
a
programmer and
a
field
engineer
Goldberg,
limited
focus on techniques such as structured programming.
technological
the
In
next stage, roughly during the 1970s, experimental techniques such as Brooks
recommended became more formal methodologies, such
or structured analysis.
understanding
attention
to
software
life-cycle
maintenance).
technology
Managers,
In
better
development
in
the
(for
turn,
began
processes
example,
as
to
stepwise refinement
direct more of their
involved
from
in
basic
each
design
step
of
through
the most recent stage (the 1980s), companies have pushed
development more toward
improving
managers have shifted their concerns more
41
to
software
environments,
process-management issues.
as
•^'^
The
result
development,
of
and experience,
Bratman and Court, as
structured
design,
psychological
structures,
measurements,
maintenance,
team
cost
software
human factors
or
programming
estimation,
decades
many other authors
as
development,
language
definition,
well
management,
project
two
research,
of
huge literature covering topics discussed
a
is
by Brooks,
requirements
drawing on
evolution,
this
economics,
configuration
data
productivity
software
tools,
control,
life-cycle
the 1970s:
programming,
programming,
and
concepts
engineering
modular
in
in
quality,
management,
large-program management, documentation, flow diagrams, testing, reusability,
prototyping,
and the
software engineering
of
directions U.S.
leader among
tools to software
Boehm
TRW,
of
beyond the scope
is
indicates
and
paper,
trends
although
suggests
a
in
sampling
some
the
of
TRW
was
in
a
leader
in
the entire sample and
applying factory-type discipline and
Much
of this
is
due
to
Barry
who has written extensively on software engineering and
environment offered
environment
of
of this
development (see Appendix).
by
decade.
a
been extremely influential
perhaps
that
respondents
U.S.
economics for more than
learning
review of subsequent developments
full
firms have taken.
The survey
the
A
"^
company experiences,
ideas,
sevel
like.
in
a
His
the U.S.
factory
for
clearly
TRW,
how many people should be involved
42
The type
and abroad
model
Boehm advocated
and experiments
ideas
in
supported
except
for
one project.
in
TRW
of
controlled
have
the
type
the
question
of
In
a
key
1976
helped
that
article
define
to
the
software
of
field
engineering, Boehm discussed integrated approaches to software development,
citing
the objectives of such approaches as "a significant boost
development efficiency and
quality
He cited as examples
approach."
programming standards; the
at the
same time perform
or simply the improvement
participants
using
are
support software. ^
perform
ability to
set of timely,
a
synergism
the
a
unified
a
software update and
consistent project status updates;
software system integration achieved when
in
same development concept,
the
of
complementary development approach and
a
set of
through
software
in
Strategies
Boehm seemed
ground
and
rules,
recommend were
to
all
IBM's
"top-down structured programming with chief programmer teams" concept, as
well
as
SofTech's
structured
integrated
Electronics
and TRW's management-
The System Design Laboratory (SDL)
intensive integrated approach.
Naval
approach
Laboratory
Center was
also
engaged
the
integrated
an
in
at
approach to software development.
In
efforts
a
at
outcome to
1977
TRW
a
article,
to
Boehm described the
define
a
set
of
results
principles
to
of
one
"guarantee"
software development effort:
1.
Manage using
2.
Perform continuous validation
3.
Maintain disciplined product control
4.
Use enhanced top-down structured programming
5.
Maintain clear accountability for results
a
sequential life-cycle plan
43
a
in
a
series
of
successful
In
6.
Use better and fewer people
7.
Maintain
commitment
a
to
improve
the
process^^
contrast to software-factory notions of large scales of people
these
one of
recommended fewer people on
principles
Brooks of IBM,
Frederick
in
one
projects;
site,
so
did
based on the experience of having developed the
although
System 360 operating system,
Japanese software-factory managers
claimed they were able to add people to projects falling behind and get them
done on
As
time.'^°
sufficient
and application
not sufficient to ensure
are
a
now
techniques
programming,
structured
these principles over the entire life-cycles of successive
of
would
projects
top-down
as
that
But he did maintain that the continued learning
themselves.
in
is
Boehm suggested
Neither
effort.
such
universally,
almost
practiced
development
software
well,
as
project personnel alone
reliance on outstanding
successful
found
has
Hitachi
bring
forth
improvements
and
understanding
project
in
gradual overcoming of management complexities.
In
1984
a
software
leading
managers
to
of
more
a
Boehm and
article,
several
substantial
his
co-authors cited the
of
level
technology and productivity improvement.
demand
costs,
for software,
limited
motivating
"corporate
investment
recognition
factors"
software
in
study
productivity
development,
in
or
TRW
did
were
process
These factors included increased
supply of software engineers, reduced hardware
and rising software-engineering support expectations.'^'
productivity
which
by
in
software
prototyping,
1980
identified
development,
of
ways for improving
recommending
requirements
44
several
A software
specifications,
evolutionary
to
facilitate
changing and better understood user needs, and more emphasis on training of
system
users
and
in-house
Preliminary conclusions from the study included better
usage measurement.
integration
of
programmer
these strategies
but,
consulting,
and on such organizational factors as project learning and system
courses,
All
documentation,
improved
through
indeed,
are
not only
have been
with
initiatives
productivity
consistent with
incorporated
tools.
software factory model
a
software factories
actual
in
improvement
such
as
Toshiba. 28
general,
In
Boehm
software engineers and
seek
combination
a
rising
of
development efforts.
1983
a
in
demand
software
cost-productivity
strongly
support
Toshiba,
Hitachi,
estimating
(2)
and NEC:
(1)
with
proper
management,
planning
a
long,
and
conlcusions
efforts
such
their
personal
for
that
as
at
require an
including tools,
methods,
incentives,
and
reflects
five years and factors of four in ten
in
investment.
(3)
Improving
sustained effort and commitment.
Boehm has succeeded
GTE's experience
three
to
in
An integrated software productivity program can produce
productivity involves
Whereas
shortage of
Boehm developed
productivity gains
several areas,
in
the
adaptability
model
came
Significant
education,
a
and
factory-type
integrated
long-term,
productivity gains of factors of two
years,
also
that
programs necessitated that firms
using
studies
integrated program of initiatives
reusability.
for
concluded
affordability,
reliability,
Several
work environments,
article
in
the problems
45
implementing
a
diversified
these
software
"^^
ideas
organization
in
TRW,
faces
in
attempting
development.-^^
several
Its
GTE
the
ideas
met
little
several
of
embodied
According
divisions.
Computer Science Laboratory
consisted
and general-use
standards
tools
general
at
GTE
existing
in
G.
William
to
Laboratories,
objectives
that
software
to
Corporate Software Developwient lltethodoloqv,
incorporated
1980,
in
corporate
apply
to
published
methodologies
director
Griffin,
Inc.,
used
of
in
the
the methodology
represented good
practice
and
opposition:
A specified software architecture
1.
for all systems,
represented as a hierarchy of logical components,
each level of the hierarchy being a decomposition
of the preceding higher level
2.
A
3.
A description of the
configuration management
4.
A
detailed description of the development process
based on the software life-cycle model
list
phase
A
5.
necessary
aspects
of the necessary documentation
of the development process
glossary
terms
and
prescribed
manual
was
one
of
for
of
each
structure
chart symbols
Development
following
of
this
formation
the
of
a
Software
of
Steering
several
steps
Committee,
GTE
took
whose tasks
included studying software engineering and management issues, examining the
and promoting the sharing
diverse software activities within the corporation,
of
experiences and software engineering
cited
from
this
and managers
to
centralized
approach
was
the
communicate through the use
But another attempt
to
standardize
46
The greatest
tools.
not
ability
of
of
benefit Griffin
software
engineers
common terms.
just
terminology
but practices
the
across
firm,
Projects), met with
called
much
"STEP"
Enforce a set of
development
2.
Provide
an
portable
standards
integrated
tool
throughout
set
Engineering
program
around a
for
built
management
data
of
STEP's objectives were much bolder:
less success.
1.
Techniques
(Structured
system
configuration management
3.
Ensure that documentation was current
4.
Provide
relatively
easy
transportation
across
operating systems
Provide management reports on project status
5.
Griffin
GTE
explained
the
as
software
result
of
STEP's failure
several
to
factors:
development activities
gain
widespread acceptance within
the decentralized
and groups;
the
performance problems
nature of GTE's
preference of
software
encountered with
engineers
for
STEP,
comparison to tools integrated with the data management services
of a
in
familiar
tools;
users
STEP's narrow interpretation of the software
specific operating system;
development methodology; the slow transfer of technology from the research
phase
GTE
to its use in
systems development; and the different perceptions among
business units as to what their real economic needs were.
GTE managers continued
to
debate whether
they
should
centralized group to develop software tools and define methods,
investment
productivity.
Griffin
in
R&D
to
expected
a
although, as
Boehm would recommend, the company was apparently committed
long-term
have
to
heavy,
improve software quality and development
high-performance
47
personal
workstations
to
provide
bulk
the
although
he
greatly
complicate
not.
although
Hitachi,
distributed
or
central
also
decentralization
were
fully
Japanese firms
leading
in
Hitachi:
components,
product
strategies
development
of
GTE
in
would
at
was
efforts
laboratories, on
consistent with the type of objectives sought by
model,
the factory
NEC,
including
integrated environments,
accuracy,
specification
environments
factory
the
to
development,
large-scale
for
The four dominant software engineering themes
the other hand,
software
in
management
configuration
Workbenches were
and
improvements
future
decentralized
believed
also
development.
Toshiba
GTE's
of
and the application
reusable software
knowledge-based systems
of
and
Toshiba,
to the
software
development process.
These
to
SDC and
including the factory efforts at
efforts,
have provided firms with significant benefits even
meet
all
their
improving conceptual
integration
using tools to support this,
groups,
technical
due
was
This
goals.
least
at
within
the design
personnel,
achieved greater success than
software
factories
Fujitsu,
as
Notable
well
and
as
at
process,
management.
and
SDC
The terminology used today
software engineering
to
an
emphasis
on
developing and
and improving communication among development
improve software development productivity
aided
seem
Japan,
the programs did not
if
part
in
in
efforts
to
have focused on automation and
system design
for automating
Such
tools
development efforts
software
among design-automation
recent
did.
(CASE).
other
More
tools
48
at
were integral parts
NEC,
producers
sold
by
computer-
is
Toshiba,
in
U.S.
Japan
of
Hitachi,
and
vendors
the
the
and
U.S.
were those
by
developed
Index
Technology,
KnowledgeWare,
Nastec,
Instruments, Cortex, and Tarkenton Software.
was one of the
first
to
A Texas Instruments's product
systems
the entire
tackle
Texas
Cadre,
development
cycle,
including business objective analysis and data base generation.
life
Other tools
which automate the coding process, called application or program generators,
were also central
among U.S.
tool
to
Japanese
as
facilities
developers and users.
well
as
growing
popularity
in
Cortex, for example, has developed
a
system called the Application Factory for the Digital Equipment Corporation
VAX
market that
resembled
miniature,
a
flexible
and automated factory. ^^
This product, which closely resembled systems used internally and marketed
by Hitachi and NEC, automatically generated software from specifications set
by computer professionals,
and
at
Du Pont Company,
70% of the code for a particular project,
actually
contributing to
wrote about
cost savings of
a
about 82%. 32
In
addition to
CASE products
available for sale are those U.S.
TRW
have made primarily for in-house use.
as
designed ARGUS, for example,
an advanced software engineering workbench and integrated approach to
improve quality while reducing the cost of software development.^"^
is
Automated
the
used
at
the
Interactive
Design
The next step
IBM.'^''
CASE
tool
Cortex's
product. ^^
to
and
Hughes Aircraft Company,
manual procedures accompanying
at
firms
in
a
designed to automate many of the
automation many firms are taking
designed
Texas Instruments
System developed and
structured design methodology developed
an application generator.
CorVision,
Evaluation
to
is
AIDES
be
said
49
U.S.
a
to
is
to link a
products of this type include
well -integrated
have developed
version
a
of
the
product which
"thoroughly automates every process even
development,"
Other
U.S.
although
this
is
vendors,
as
well
vaguely associated with software
also
described
as
Japanese
as
exceedingly
firms,
were
incorporating expert systems technology into their products.
Inc.
make
and Tarkenton
a
workbench
Software,
for
for
example,
systems analysts that
focusing
will
on
KnowledgeWare
have combined their efforts
to
automate everything from
the early design work to the generation of computer code.^'
50
unwieldy. °
CONCLUSIONS
The SDC experiment was
clearly part of a
large and ongoing effort
in
the U.S., Japan, and elsewhere since the 1960s, to develop methods, tools,
and entire enviroments to improve software-engineering productivity, product
quality,
well
and management control.
was the variety
"decentralize"
to
lines
suit
and
the
management
factory ideal.
failure
or
need
to
This
facility.
development efforts can also be seen
not perform
did
GTE and numerous
in
and runs counter to the centralization tendency
other firms,
developing
SDC's product
in
manage the work flow
to
inability
One reason the factory
implicit
in
the
This suggests that factory models may be appropriate only for
certain
types
software
of
firms
in
willing
accept
to
a
certain
amount of centralization, discipline, and product/market focus.
On the other hand, the primary
goal
factory aspects of hardware production,
disciplined,
capturing
and
repeatable
approach
to
of
but
the
SDC was
not to mimic
rather to apply
Hence,
SDC
did
completely
not
in
"fail"
in
automate and standardize the software development process.
many developments that followed and
criteria
its
consistent,
performance
in
a
manufacturing
its
attempt
It
some important objectives and
more strategically and
SDC may have
possibilities for
efficiently.
51
to
anticipated
the overall
was above average and among the leaders for U.S. firms.
not pursuing the factory model further,
the
software development process,
some of the efficiencies of production found
environment.
a
all
survey
Yet,
by
needlessly abandoned
managing software engineering
Sustaining Committment to an Innova tion
SDC,
At
introduction
the
Software
the
of
Factory
established methodology for developing software systems.
SDC would
procedures were totally adequate,
problem areas and attempted such
and
disruption
the
difficult
unsuitabiity
the
sustain
to
innovation
encourage acceptance and
and planning.
except for
problem,
into
While
the
1980s,
reluctance
to
supervision
careful
investment
activity;
in
variety
and
it
change
the
of
to
new procedures and
as
skill,
control
company's
the
of
product
of
work
as
well
time
a
development
seemed
engineering
advanced
has
hinder
to
dooming the experiment.
deemphasis on
a
Tool development needs to be
process technology.
managers'
and
flow
experiment was apparently followed by
of the
software
of
made
Factory
the
of
Management
attempt.
effective implementation of the concept,
The end
aspects
reluctance to use the program library that persisted
up
give
On the other hand,
programmer resistance may or may not have been
a
the
have identified so many
not
ensure rapid absorption
to
requires
always
technologies
certain
of
an
the established
If
grand experiement.
a
disrupted
sufficiently
continous
a
that
new
tools
become available frequently and render many existing ones obsolete quickly.
SDC,
it
fact,
in
has
has replaced the tools of the Software Factory far faster than
replaced
Factory
supposed
as
to
the
originally
designed
accommodate new
one key manager admitted that
contrast,
the development
continually
evolving,
both
But
procedures.
Factory
to
systems
in
become obsolete;
as
tools
tool
SDC
they
terms
Toshiba,
of
52
the
fell
but
of
and
the
was
also
at
least
behind other firms.
Hitachi,
policies
much
Factory
became available,
development
at
allowed
In
and NEC have been
technology,
following
long-term plans and sustained Investment. °
Th work flow problem was symptomatic
business at Santa Monica,
as
well
of the
as
of
SDC's
varied
nature of the products
The product technology was not particularly
developing.
NEC, Toshiba, and TRW,
to discipline their
and
technologies
stable and
also with varied product portfolios,
development efforts much more successfully.
thus
policies
were not
it
was
thus
But other companies such as
"mass-production" atmosphere.
suitable for a
contract
necessarily
have managed
The Factory
inappropriate
to
the
product/market requirements of SDC, although SDC's customer base seems to
have made successful process innovation more
difficult.
Managing People as well as Technolociv
The
lack
of
a
consistent,
flow
similar
of
work through the Factory
meant SDC managers could not justify the Factory's continued existence and
development.
commitment
to
But
failure.
asked
Better
maintaining
the
planning
Factory
along
intact
with
might
more management
have prevented
the
basic problems seems to be that SDC's implementation effort
organizational
for
sufficient
a
production
socializing
of
and
process
innovation
Making
the people involved.
but
did
"the
not
provide
factory workers
go to the work" rather than having the work flow through the factory was
an organizational adaptation to an operational situation that appears to have
worked,
but
it
also
undermined much
of
the
Numerous Japanese firms and two U.S. firms or
survey,
are
significantly
ahead of SDC
53
in
initial
innovation's
facilities,
implementing
potential.
as indicated in the
factory-type tools
and
policies.
Whereas
management-policy
infrastructure
organizations,
also
is
it
standardized,
formal,
or constructs
to
do
not
way
SDC's
themselves
lend
1969,
impose
in
a
so
building
of
well
took
nearly
technology
infrastructure
and
(1)
computerized
to
with
was
factory
NEC, Toshiba, and
first
regard
quite
Hitachi.
software factory
collect
data
and quality (defects) before investing
automated
and
With
decade to institute standards and
technological
once,
at
a
productivity,
sophisticated
software
a
which launched the world's
Hitachi,
on project management,
heavily
There are
further.
a
development
but require personal interaction and consideration.
For example,
in
and
and automatable management practices
different from the approaches followed at
effort
technological
software
scale
differentiate
to
a
the management-policy infrastructure; and (2) those areas of
in
distinction,
this
possible
large
in
proceduralized,
managing people which
automation,
between
appropriate to distinguish
is
it
tools.
In
contrast,
infrastructure and
inadequate
planning
SDC
tried
disciplined
a
or
analysis
to
policy
of
its
product portfolio and production operations.
In
examining
software firms,
this
articles
and
practices
several
of
type of contrast becomes even more explicit.
additional case studies are needed,
key elements
in
methods
quality practices,
and
tools,
and
a
standardization
concentration on
54
of
Japanese
Although
the success of Toshiba's
Software Factory appear to be compulsory education for
factory
different
all
software
employees
in
development
the
and
"how to control software people so
as
and follow the plans without losing their morale
observe,
to
expects
Fujitsu
programmers and customers
its
[sic]."^^
understand
to
fully
its
"Software Development Engineering Methodology" standards, and the company
and
leaders
continuous.
administrators
number
the
regard
With
Support System,"
in
campaigns and seminars for project
continuously conducted educational
has
a
to
of
Development
1977.
another
the
tool,
Fujitsu engineer states that,
and
problems
"...
which
needs
various
is
there
is
seen
also
"Software
SDSS and we are planning
of projects applying
light
since
as
Development
an increasing
to
improve
may
arise
further
it
during
its
present application."^^
The founder
in
"...human factors
another article,
increasingly important;
being
applied
to
software
formerly
Engineering
at
its
in
software management are becoming
(HSE),
the company's success,
assert
is
now
and
as
HSE makes
a
at
that
well
"Realizing
employees--an investment that pays off
same vein
Tajima
reliability."^^
Hitachi
depends largely upon individuals:
play
in
therefore human-oriented reviews and inspections are
increase
software managers
Software
Matsumoto Yoshihiro, writes
of Toshiba's Software Factory,
and
Matsubara,
a
subsidiary,
the
software
the critical
role
Hitachi
industry
that
people
major educational investment
in
an observation by Mizuno Yukio,
employee loyalty."^
a
In
...the only difference is the human element" [referring to software
quality differences between Japanese and U. S. companies] ...
Teamwork is the key
the human factor must receive adequate
consideration ... People are at the heart of software work.
Here,
teamwork will be the key.
members
working
together
are,
Team
in their collective wisdom,
more
effective
individuals
far
than
.
.
55
this
vice-president and head of
NEC's software effort:
.
in
group activity motivates the individual and the
working alone.
team ... There are three psychological keys to motivation.
First
the worker should know the significance of what he works on; he
must by himself, recognize his responsibility in his environment.
Second, he needs to be exposed to the actual results of his
work. .. [third] he knows the team goal.'^
.
.
.
,
each
In
these
of
--
interaction
encouragement,
expression of common
vision,
described
aspects
in
of
in
software
human factors
of
personal
instillment
of
purpose and
The management-policy infrastructure
goals.
In
SDC's Software Factory as
well,
have had difficulty understanding the goals and benefits,
to
programmers
was trying
the
team-building,
management function.
the
of
engaged
paper may not separate and capture these non-automatable
this
managers seem
while
seem acutely aware
development
process
managers
Japanese
examples,
were
to accomplish.
not
told
the
of
significance
of
what
management
This approach ignored the need to manage people
as well as technology.
Not
only
did
program
central
SDC programmers never became accustomed
library
for
resistance from managers
was
left
trying
rather than
which
to
who
enforce
not accept the
management
factory
using
a
The Software Factory met with
reusability.
did
to
new system.
using
Thus,
computerized
SDC
tools
adequately applying the non-automatable aspects of management
address
such
issues
as
personality
and
"turfdom."
The
lack
of
acceptance and enthusiasm about the Software Factory by both workers and
the disruption of what could
managers contributed
to
evolution--and
revolution
not a
managing the process
of software
--
to
a
more strategic and
development.
56
have been an orderly
efficient
way
of
APPENDIX
SURVEY RESULTS: DATA SUMMARY TABLE
= Technological
Infrastructure
Policy/Methodology Infrastructure
III = Total Factory Model
@ Indicates two responses and averaged or
I
II
=
COMPANY/FACI LITY
*NEC@
(32=100%)
(60=100%)
(92=100%)
joint responses.
1
89%
*Toshiba Software Factory
*NEC Information Service
*NT&T Comm. & Info. Proc. Lab.@
Hitachi Omori Works
Fujitsu Info. Proc. Sys. Lab.@
Nippon Systemware
Nippon Business Consultant
Hitachi Software Engineering^
Nippon Electronics Development
TRW
Unisys/Sperry@
Unisys/SDC
Control Data©
Martin Marietta/Maryland
Hughes Aircraft
Boeing Aerospace©
Bell Labs
AT&T
Cullinet
Martin Marietta/Denver
Electronic Data Systems©
Honeywell/Defense Systems©
Draper Laboratories©
Computervision©
Applications Means
Japanese ()
U.S.
NEC/Switching Systems
98%
*NEC/Operating Systems
Toshiba Software Factory
*NEC Software
Hitachi Software Works(a
Fujitsu Numazu Factoryta
*NT&T Comm.
C Info.
Proc.
Lab.@
Control Data@
IBM Endicott
Data General Westboro & N.C.
Boeing Aerospace^
Unisys/Sperry@
IBM Raleigh
DEC (VMS)
Systems Means
Japanese (*)
U.S.
OVERALL MEANS
JAPANESE
U.S.
(*)
RANKINGS: TECHNOLOGY/FACILITY INFRASTRUCTURE
8 Questions; 32=100%
Key:
A.J. = Applications Japan
A.U. = Applications U.S.
S.J. = Systems Japan
S.U. = Systems U.S.
= Japanese firms
*
COMPANY/FACILITY
RANKINGS: POLICY/METHODOLOGY INFRASTRUCTURE
15 Questions,
60=100%
COMPANY/FACILITY
%
S.J.
S.J.
*NEC/Switching Systems
*NEC/Operating Systems
A.J.
A.J.
A.J.
*NEC
*NEC Information Service
Toshiba Software Factory
Toshiba Software Factory
*NEC Software
S.J.
S.J.
A.U.
A.U.
A.J.
A.U.
A.J.
A.J.
A.U.
S.J.
A.J.
S.J.
A.J.
A.U.
S.U.
S.U.
A.U.
S.U.
S.U.
A.U.
A.U.
S.U.
A.U.
TRW
Unisys/SDC
*NT&T Comm.
& Info. Proc. Lab.
Martin Marietta/Maryland
Fujitsu Info. Proc. Sys. Lab.
Hitachi Omori Works
Unisys/Sperry
Hitachi Software Works
Nippon Systemware
Fujitsu Numazu Factory
Nippon Business Consultant
Control Data
Control Data
Data General Westboro & N.C.
Hughes Aircraft
IBM Endicott
Unisys/Sperry
Cullinet
AT&T
A.J.
Bell Labs
Boeing Aerospace
Boeing Aerospace
Hitachi Software Engineering
S.J.
NT&T
S.U.
A.J
S.U.
A.U.
DEC (VMS)
Nippon Electronics Development
A.U.
A.U.
A.U.
A.U.
Comm.
& Info.
Proc.
IBM Raleigh
Martin Marietta/Denver
Electronic Data Systems
Honeywell/Defense Systems
Computervision
Draper Laboratories
Lab.
RANKINGS: TOTAL FACTORY MODEL
23 Questions, 92=100%
REFERENCES
paper from this research project is Michael A. Cusumano,
1. The main
An Approach to the Strategic
"The Software Factory' Reconsidered:
Management of Engineering." Sloan School of Ntenaaiiont 1987 Working
,
Paper «1885-87. Another completed case is "Hitachi; Pioneering the Factory
Model for Large-Scale Software Development." Sloan School of WanaganiBnt
1987 Working Paper #1886-87.
,
One of the key documents in this literature, which also contains a wealth of
references to other articles written during the late 1960s and early 1970s, is of
course Frederick P. Brooks, Jr., The Mythical Man-Wonth: Eiiays on Software
Engineering (Reading, MA, Addison-Wesley, 1975). Two other collections on key
articles dating back to the early 1960s are Edward Yourdon, ed., daisies in
Software Engineering (New York, Yourdon Press, 1979) and Writings of the
Revolution (New York, Yourdon Press, 1982).
2.
Burroughs Corporation, Annual Report, 1984, p. 15. Much of the basic
description of SDC's business found in this section of the chapter is taken
from this report, and will not be further cited.
3.
Telephone interviews with Ronald L. Atchley, Director of Software
Engineering, Systems Group, System Development Corporation (SDC), Santa
Monica, California; March 27, 1987 and April 23, 1987.
4.
Harvey Bratman and Terry Court (System Development Corporation), "The
Software Factory," Computer May 1975, pp. 28-37. A more detailed discussion
of this can be found in H. Bratman and T. Court, "Elements of the Software
Factory:
Standards, Procedures, and Tools," in Infotech International Ltd.,
Infotech International
Software Engineering Techniques (Berkshire, England:
Bratman, who had a BA in mathematics from UCLA,
Ltd., 1977), pp. 117-143.
was head of the Software Engineering Branch of SDC's R&D Division. Court,
who also had a BA in mathematics from UCLA as well as an MS in systems
management from USC, was Deputy Manager of SDC's Software Development
5.
,
Department.
Bratman, H. and Court, T., "The Software Factory" (op. cit), p. 36, and
Standards, procedures, and tools", in
of the Software Factory:
Software Engineering Techniques: Invit e d papers (Nicholson House, England:
6.
"Elements
117-118.
"Software
Infotech International Ltd., 1977)
p.
registered trademark of System Development Corporation.
Factory"
In addition to their own experiences, they cited a 1974 study
which had attempted, without success, to find such a correlation.
See R.W. Wolverton, "The Cost of Developing Large Scale Software,
IEEE Transactions on Computers Vol. C-23, No. 6, June 1974, pp.
7.
"
,
615-635.
62
is
a
",
.
8.
Bratman and Court (1975), pp. 29-31.
Bratman and Court (1975), pp. 28-29. There were truly commonly cited
problems. See, for example. Brooks; Barry W. Boehm, "Software Engineering,
IEEE Transactions on Computers , December 1976; Tarek Abdel-Hamid, "The
An Integrative
Dynamics of Software Development Project Management:
Systems Dynamics Perspective" (Unpublished M.I.T Sloan School of Management
Ph.D. Thesis, January 1984, literature survey on pp. 48-93; R. H. Thayer et al.
"Major Issues in Software Engineering Project Management," IEEE Traiwactions
on Software Engineering , Vol. SE-7, No. 4 (July 1981); C.V. Ramamoorthy et al.
"Software Engineering: Problems and Perspectives," Computer , October 1984.
Thayer's thesis for the University of California at Santa Barbara) surveyed 294
software professionals as well as 60 development projects in the aerospace
industry, and identified seven major issues that repeatedly occurred: (1)
requirement specifications that are frequently incomplete, ambiguous,
inconsistent, and/or unreasonable (SDC #3 above); (2) poor project planning
(SDC #1,2); (3) poor ability to estimate accurately project costs (SDC #1,2); (4)
inability to estimate accurately delivery times for software products (SDC #1,2);
(5) unavailability of decision rules to use in selecting the correct software
design techniques and tools (SDC #4); (6) unavailability of decision rules to use
in selecting the correct procedures, strategies, and tools for testing (SDC #4);
(7) lack of standards and techniques for measuring the quality of programmer
performance and the quantity of production that should be expected (SDC #1).
This is cited in Abdel-Hamid, pp. 55-57.
9.
SDC experiment
10.
A
11
Telephone interviews with David Deaverand Clarence Starkey, SDC, 10/3/86.
12.
Interview
detailed discussion of the
4/1/87.
will
be forthcoming.
with and SDC/Unisys director of software engineering,
Name withheld by request of the interview subject. My thanks to
David Finnell for conducting this interview under my direction, as part of
a thesis project.
For descriptions of sample U.S. experimental systems, see R.R. Willis
(Hughes Aircraft), "AIDES: Computer Aided Design of Software Systems II,"
pp. 27-48; and Leon G. Stucki and Harry D. Walker (Boeing Computer Services,
Inc.), "Concepts and Prototypes of Argus," pp. 61-79, in Horst Hunke, ed..
Software Engineering Environments (Amsterdam: North-Holland, 1981); and the
13.
previously cited
TRW
articles.
For reports on the Japanese systems, see Cusumano, "The Software
Factory' Reconsidered," and literature references in the notes. Particularly
well documented is productivity data at Toshiba.
See Yoshihiro Matsumoto
14.
(Toshiba), "A Software Factory:
An Overall Approach to Software
Production" (2 December 1986), forthcoming in Peter Freeman, ed.. Software
Reusability (IEEE Tutorial, 1987); and K.H. Kim, "A Look at Japan's
Development of Software Engineering Technology," Computer May 1983,
pp. 31-33.
,
63
15.
Bratman and Court, "Elements of the Software Factory" pp.
such references come from the two articles by Bratman and
Other information in
chapter, and will not be further cited.
derived from personal telephone interviews between SDC
Cusumano or Finnell.
,
119-121.
Many
Court in this
the chapter is
personnel and
The project planning and control area is referred to as scheduling,
16.
monitoring and control processors, and is included as a part of the data
base generation and ma in ten a nee function in "Elements of the Software Factory"
In "Elements of the Software Factory",
17.
Analysis and Test Certification Processor.
18.
David Deaver,
19.
In
in
this tool
is
called
Program
telephone interview with Cusumano, October 1986.
See
the survey, only a few facilities reported reuse rates of over 50%.
'The Software Factory Reconsidered," Section 2.
20.
Clarence Starkey, SDC,
telephone interview with Cusumano, Oct. 1986.
in
Frederick P. Brooks, Jr., The Myhtical Man-Month: Essays on Software
Engineering Reading, MA, Addison-Wesley Publishing Company, 1975.
21.
,
See R. Goldberg, "Software Engineering: An Emerging Discipline," IBM
Systems Journal Vol. 25, Nos 3/4, 1986, pp. 334-353.
A discussion of
this shift in focus to enviroments can also be found in Horst Hunke, ed
North-Holland, 1981).
Software Engineering Environments (Amsterdam:
22.
,
.
.
,
23. An excellent summary of this field and literature bibliography can be
found in R. Goldberg, "Software Engineering: An Emerging Discipline," IBM
Systems Journal Vol. 25, Nos. 3/4, 1986, pp. 334-335.
See also the
references in The Software Factory' Reconsidered.
,
'
B.W. Boehm, "Software Engineering", in E. N. Yourdon, ed.. Classics
Yourdon Press, 1979) p. 349.
Software Engineering (New York:
24.
in
Boehm, B. W., 'Seven Basic Principles of Software Engineering", in
Software Engineering Technigues — Invited Papers (Nicholson House:
25.
Infotech
International Ltd.,
1977) p.
79.
and "Hitachi:
See Cusumano, "The Software Factory' Reconsidered,
Pioneering the Factory Model for Large-Scale Software Development."
26.
27.
"
Boehm,
et
Productivity",
"A Software Development Environment
IEEE Computer June 1984, pp. 30-42.
al,
in
for
Improving
,
28
See Matsumoto, "A Software Factory.'"
29.
Barry W. Boehm and Thomas A. Standish, "Software Technology in the
Using an Evolutionary Paradigm," lEE Computer November 1983, pp.
1990's:
,
30-37.
64
30. William
G.
Griffin,
"Software Engineering
GTE",
in
IEEE Computer
,
November 1984, pp. 66-72.
31. David H.
p. 12.
Freedman, "In Search of Productivity", Infcuystams
,
Nov. 1986,
David Wessel, "Software Writing is Becoming Automated: New Products
Speed Programmers' Tedious Task", The Wall Street Journal Sept. 24, 1986,
32.
,
p.
6.
Leon G. Stucki, et al., "Concepts and Prototypes of
ed., pp. 61-79.
33.
R.R Willis, "AIDES: Computer Aided Design
Hunke (ed.), pp. 27-48.
Freedman, Infosystems
36.
Freedman, p.
37.
Wessel, p. 6.
in
Hunke,
of Software Systems-ll" in
34.
35.
ARGUS",
Nov. 1986, p. 12.
,
14.
38. Case studies of these firms are presented in other working papers
articles, as cited earlier and "The 'Software Factory' Reconsidered."
See Cusumano, "Hitachi:
Software Development."
Pioneering the 'Factory' Model for Large-Scale
39.
Matsumoto, Y., et
(ed.), pp. 305-318.
40.
and
al,
"SWB System:
A Software Factory",
in
Hunke
Noritoshi Murakami, Isao Miyanari, and Kazuo Yabuta, "SDEM and SDSS:
Overall Approach to Improvement of the Software Development Environment,"
in H. Hunke, ed.. Software Engineering Environments (North-Holland, 1981),
pp. 281-293.
41.
Matsumoto, Yoshihiro,
42.
Production", in IEEE Computer
"Management
,
Feb,
1984,
p.
of
Industrial
Software
70.
Tajima, Denji and Matsubara, Tomoo, "The Computer
Industry in Japan", in IEEE Computer May 1981, p. 96.
43.
Software
,
44.
Mizuno,
Yukio,
March 1983, pp.
68,
"Software Quality
70.
65
Improvement",
IEEE Computer
,
Is
5 3!;
031
,
Date Due
FEB
2.^
db:i
NOV 1 6
Q£
1990
U
'90
f
Lib-26-67
NirT
3
LIBRARIES
TDflD DD4 flSl SD4