MIT LIBRARIES
DUPL
Basement
3
TOaO DD7EflflEM
1
J*h«&,;^^
""-x
omm
I'^'S^-B'^H
>!fe5>i
HD28
.
.M414
n
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
System Development Corporation ;
Defining The Factory Challenge
1
by
Michael Cusumano
WP 1887-87
Revised Dec, 1988
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
.
M?t:M*'-i>£',;^
0^ OB
itO
CASE
1
SYSTEM DEVELOPMENT CORPORATION: DEFINING THE FACTORY CHALLENGE'
'
Contents
Introduction
Origins of SDC and the "Software Factory"
Factory Components: Methodology, Organization, Tools
Initial Problems Revisited
Factory Performance:
New Problems the Factory Created
Managers' Assessments and the Japanese Challenge
Conclusions
INTRODUCTION
System Development Corporation (SDC), established
of the
became
Rand Corporation, became part
a
facilities
Burroughs
in
In
1987,
Unisys/Sperry's
had approximately $2.5
across the U.S.
large-scale,
SDC
billion
The company,
in
in
1986
Burroughs
of
operations, primarily
in
defense
revenues and 6,000 employees
since
in
inception, has specialized
its
in
real-time applications systems, which often take years to develop
management control problems involved
a
and then
merger
and run into hundreds of thousands and often millions of
management
1956 as a subsidiary
1981
division of the Unisys Corporation after the 1986
and Sperry.
systems,
of
in
in
in
such
lines of code.
projects
the mid-1970s to launch the first attempt
in
The
persuaded SDC
the U.S. to create
factory-type organization for software production.
SDC's Software Factory was part of the larger movement among software
researchers
and developers during the early
programming experiences and
programming methods,
and
identify
useful
1970s
to
support
management procedures.
reflect
on
tools,
design
Analyses
various
of
and
IBM's
development of the operating system for the 360 family of mainframes, as well
as
numerous other projects for the U.S. military, NASA, other government
agencies, and private industry, contributed to a body of literature on practical
1
SDC
Software Factory
•5
software engineering that began emerging
problems faced
in
reports on the
SDC Software
Factory published
in
Two
at this time.
1975 and 1977 were
part of
a
and presented convincing arguments promoting engineering or
this literature,
factory-type discipline, planning, and control as
a
model for managing large-
scale software development.
SDC
allowed
factory effort to lapse
its
in
although the experiment
1978,
has had considerable influence on industry practices
The factory procedures became
the U.S. and abroad.
in
model for SDC's corporate practices and for
a
the software standards later adopted by the U.S. Department of Defense. But
perhaps
the
impact
largest
the
of
SDC experiment
NEC
particularly at Hitachi, Toshiba, and
been
has
where managers
--
Japan--
in
iiave
emphasized
the factory approach even more than the U.S. pioneer.
This case
The
organized into four parts.
is
Factory initiative
in
a
company from the
section
analyzes the main
the context of SDC's evolution
mid-1950s through the early
components of the Factory
The second
1970s.
at
inception
its
discusses the Software
first
as
1976 --
in
procedures, tools to support the development process, and
dividing
labor
between
software production
factory.
This
is
--
system design,
detailed
followed
by
design,
an
done
a
matrix organization
customer
at
sites,
and testing
coding,
account of
the
dissolution after less than three years of operation.
standardized
set of
a
--
factory's
The next
and actual
done
opening
and
section compares
accounts of the performance of the factory with the five major problems
staff
the
in
SDC
designed the factory to solve, and identifies three more serious problems
the factory experiment created:
matrix
system,
and
resistance
organizational changes the
assessments from
imbalances
on
the
in
the work flow, breakdown of the
part of
new system required.
SDC managers
of
middle-level
The
final
mangers
section
what the factory achieved and
2
SDC Software
to
the
recounts
failed
to
Factory
achieve.
The most
results for
significant positive
identification of software
development as
a
SDC appear
to
have been the
major management issue deserving
corporate attention and resources, and the standardization of better practices
On the negative
for design, quality assurance, and project management.
the factory represented somewhat of
company and with the
SDC had
a
side,
"mismatch" with SDC's strategy as
state and type of
software technology
dealt with.
it
reputation for producing innovative software systems for
built a
a
a
variety of customers; this strategy required a very flexible, job-shop type of
organization, rather than a factory structure.
the
forsee
degree to which
architectures would make
tools
controls
Finally,
lack
of
computer languages and
portable
difficult to achieve the factory goals of reusable
Management
and code.
reorrenting
it
the
Furthermore, management did not
also failed to
project managers to the
so that the factory would
manage other problems, such
new system, and introducing
have enough work to keep
it
as
sufficient
operating.
rather than focus on the benefits of the factory organization and allow
enough time and
commitment
resources
to the effort
for
when
its
it
succeed,
to
main advocate
executives
top
in
ended their
management moved on
to
another division.
ORIGINS OF SDC AND THE "SOFTWARE FACTORY"
Companv Background
System Development Corporation originated as
a
nonprofit,
government-
sponsored corporation on the model of MIT's Lincoln Laboratories and MITRE
Corporation.
In
the mid-1950s, the U.S. Air Force gave
a
contract to the Rand
Corporation to build what would become the world's first real-time command
3
SDC
Software Factory
and control system for
air
defense,
Rand management then decided
an independent entity,
SAGE (Semi-Automatic Ground Environment)
System Development Division
to spin off its
employees
then
1956 to 3500 by 1959.
in
the late 1950s,
Air
SDC designed
a
program
to build
SAGE by
command-control system for the U.S. Strategic
which ran on an IBM mainframe, exceeded
a
programmers
For example, after completing
Command, SACCS (SAC Command and Control).
length for
of
and expanded from about 450
variety of other projects,
a
as
named System Development Corporation.
The new company required increasing numbers
SAGE and
.
a million lines of
SDC
at that time.
The operating system
alone,
code, an astounding
then went on during the 1960s to
build other complex software systems for the U.S.
government
handle air
to
defense and communications, satellite control, various types of simulations, and
the Apollo space missions.
management systems for
Projects for the private sector included information
hospitals,
the
Science
National
Foundation,
state
governments, airports, libraries, and other customers.
The reputation SDC gained from these
"pioneering.
.
.
projects was as
a
product innovator,
timesharing technology, user- oriented data management and display
systems, and tools and languages enabling programmers to interact readily with
computing machines.'
But the need
to attract
new business and hold talented
employees with higher salaries led SDC's board of directors
nonprofit status
abandon the
to
1969 and become more aggressive at competing for contracts
in
across the U.S. and abroad.
The
transition
procurement for
proved
air
to
defense
be difficult.
systems,
manufacturers such as Boeing and
TRW
Years of decline
vertical
integration
into software
into the software contracts business of about 2000
increased competition for the type of work
4
SDC
in
government
by
hardware
programming, and entrance
new firms after
did.
1960, greatly
Another change after
SDC
Software Factory
SDC
1969 was that the U.S. government no longer guaranteed
of
contracts
suppliers."
one of the Department
as
To survive
in
a
of
Defense's
a
steady stream
special
"non-profit"
more competitive setting, SDC now had to submit
low-priced bids for a wider range of software and hardware systems and for
different types of customers, not only the Department of Defense.
The need
to
write software for a variety of mainframes, minicomputers, and smaller machines
made by DEC, Gould, Burroughs, IBM, Amdahl, Univac, and other computer
vendors complicated SDC's system design and programming tasks.
Under these conditions,
SDC management
employees whenever contract orders
4300
in
1963 to 3200
selected
Dr.
1969 and to merely 2000 by 1971.
George Mueller,
and
reduced
employees thus dropped from
the board of directors launched
financial losses,
1971
in
fell;
retrenched
a
a
its
peak of
After continued
nation-wide search and
who had gained
in
NASA and TRW
in
a
reputation for "cost reductions, technology development, and marketing," as the
new Chief Executive
Officer.
Mueller had
designer for Ramo-Wool ridge Corporation
vice-president for
administrator for
R&D
in
a
his
career as
the 1950s and then worked as
senior vice-president
method of operations management.
in
One issue
General Dynamics.^
product/market strategy and
for the
company was how
more orders from customers not dependent on U.S. defense spending.
to
learn
Procurement
more about integrating
officials in
a
the Gemini and Apollo flights during 1963-1969,
Mueller quickly set out to change SDC's
was
system
a
TRW's Space Technology Laboratory, an associate
NASA during
and most recently as
in
started
hardware products with
to get
Another
software.
the government and private industry had gradually come
to prefer "total systems suppliers" -- companies that could design
computer hardware and communications devices as
hardware vendors, such as Boeing, were developing
5
well
as
and
install
software.
Many
this capability
SDC
by setting up
Software Factory
in-house
software
software
development
and
divisions
to
firms
were
like
no
longer
contracting
A third
SDC.
industry was "maturing" and
it
was
issue
As recounted by the company history, Mueller
advantage.
did not appear to him that
out
much
as
competitive
the software
felt
SDC, plagued with
unpredictable demand for costly, custom job orders, was offering significantly
better product or process technology than other firms:
The problem facing SDC
in 1971 was that we were building custom
software on a one-by-each' basis, in a fast-maturing industry where
SDC's competitive edge had all but eroded, predominantly for a single
customer -- the Department of Defense -- with unpredictable demand
for our services and at a price that covered our labor plus a small
government allowed markup. The answer to growth in revenues and
profits was clearly not in doing more of the same.
Taking advantage of the
streamlining
of
all
crisis
atmosphere, Mueller launched
review and
a
operations -- planning, finance, administration, personnel,
reporting and control systems -- and created profit centers to make managers
He brought
directly responsible for their margins above costs.
managers from Ford,
and
Corporation,
Singer.
personal charge of the
hardware capability,
software.
RCA, Rockwell, Computer Sciences
Dynamics,
General
Of equal or even
greater significance,
R&D program and focused
[and]
methodical
a
professional
in
it
factory'
on creating
approach
a
to
he
"took
"corporate
developing
"
Along with these efforts
in
operations
rationalization
and R&D, Mueller
successfully diversified into non-defense systems such as for air traffic control;
command, control and intelligence for
local
governments and police departments;
custom work stations; communications networks;
systems.
Meanwhile,
By
and management information
1974, defense contracts had fallen to just SO^b of
SDC doubled revenues from
6
$45 million
in
1971
SDC's business.
to
$90 million
SDC Software
in
Factory
1974, and employees to 3900.
Profits recovered, but Mueller
SDC
competitive advantage for
was
still
seeking
a
that would rely on the technical skills within
the company. ^
The Factorv
Initiative
This was the atmosphere which produced the first U.S. software factory:
a
CEO who
too
costly,
factory,
believed that the industry was maturing, job-shop production was
and
as
all
operations
explained
in
in
the company
the company
history,
had to be rationalized.
was an attempt
to
The
"embody
Mueller's concept of a streamlined approach to the manufacturing of software,"
and thereby make SDC "the
scientifically,
first
company
to
economically, and reliably."'*^
develop custom software more
While
"state of the art" in terms of product technology,
fixed-price contracts, which meant
over-budget.
SDC
SDC
projects tended to be
they were also usually on
money every time
lost
a project
went
This was usually the case:
were pushing the state of the art in real-time command-control
information systems. All had fixed prices or cost ceilings. All called
for major software developments to be performed away from SDC's
Santa Monica headquarters, near the customer. And all suffered from
early schedule and, consequently, cost difficulties.'^
All
Careful project control or reuse of code to reduce development time and
costs
were not practices SDC managers commonly followed.
In
fact,
when
Mueller joined the firm there was no "standard policy or engineering procedure
for company-wide software development.
to be so
unique as to defy
a
common
.
.
each programming project was thought
policy.
development was deemed more an art than
a
The
entire domain of software
science by
its
practitioners."
Jim
Skaggs, SDC president after the merger with Burroughs and the manager who
7
SDC
Software Factory
'
headed the Systems Group
SDC
usual state of
a
operations
one-time miracle'
seems
Mueller
at
in
the time of the Software Factory, described the
three places at once.'
have met
to
or
little
a
study
He put Terry Court,
tools.
senior project manager
in
B.A.
a
no
resistance
R&D
in
Division
when
engineering approach
the
in
matiiematics from
SDC trademark.
with a master's degree
in
Mueller asked John B. "Jack" Munson,
transfer
organization
the
tools
mathematics
a divisional
charge
in
in
mathematics
until
Court,
research
in
to
when
1975,
a
task
SDC's
line
'
Knox
from
in
the 1950s,
College.
after graduating with
Initially,
into
he
worked
as
a
a
degree
Texas,
stemming from
a
was over
Munson
need
to
recalled
management during the 1960s.
motivation
his
in
mathematical
Unisys vice president running SDC's space shuttle software services
Houston,
of
Court hand-
vice-president, to form
developed
being
programmer on SAGE and then moved up
a
1972
.
Munson had joined SDC
Now
of
systems management from USC.
Bratman, and others worked on the project for three years
to
fall
a
and called the effort "The
software development,"
to
picked his team, which included Harvey Bratman, another B.A.
force
up
set
UCLA who was
SDC's Government Systems division,
Software Factory," registering the name as an
UCLA
he
Mueller gave him the goal of achieving "a methodical, standardized
the project.
from
creating
in
"'
Software Development Department within the
to
"We were engaged
the early 1970s:
in
to
work on the factory
in
as
improve control over large-scale system development:
the Defense Division
at the time and we [had]... a
were in trouble.
Management wasn't
was spending most of my time on an
airplane and George Mueller, who was then the chief executive of the
company, who had been working in the R&D Division with these guys
on his concepts (I think he was really the one that coined the name
Software Factory, and applied it to the work that they were doing in
the R&D Division on primarily tools), had been investing maybe three
years and several millions of dollars into this R&D project that Terry
I
in
couple of big programs that
getting visibility into them.
I
8
SDC Software
Factory
"
and Harvey were doing over there. And so we got a confluence at
that point in time of, if you guys are doing so well in the R&D
effort, we need to convert it over to something real.
And so, he
tapped me at that time and said, could you at least come in and look
at the R&D effort and tell me how we could turn this into making
money for the company. You know, convert it from being a sandbox
And so
got tapped with this
in R&D into something productive.
project. By that time it was already deemed the Software Factory. '°
I
Bratman and Court notified the world
the journal Computer
studies
software
of
titled
,
of their efforts in a 1975 article in
development had
found
a
poor correlation
programmer productivity and experience, and suggested
of
a
and well
methodological
"-^^
development process.
They discussed how
"The Software Factory."'^
between
this indicated "the lack
founded body of knowledge on
And, despite the continued refinement
the
software
of tools
and
programming concepts, Bratman and Court complained these "are either not used
at
all
in
system development or, when they are used, they are not used
integrated
manner,
programming project
particular that the
and hoped
1)
a
hoc each time
but are put together ad
is
SDC
begun. "^^
There were
a
in
an
system
large
five categories of problems in
researchers had encountered
in
software development
factory approach would ameliorate:
Bratman and Court referred
to the
absence of "standardized approaches to the development process.
Each
Lack of Discipline and Repeatabilitv
time a software system
with
the
process,
is
:
developed, the process
consequence that we
never
is
partially reinvented,
become very proficient
at
this
nor are we able to accurately predict the time and resources
required.
2)
Lack of Development Visibility
:
often used to indicate progress
They complained that code production was
in
9
completing
a
software project, but this
SDC
Software Factory
did not measure "completeness of performance requirements,
or how well the code implements the design.
itself,
testing did
problems
it
at
become clear how
this
stage
phase
phase,
to
and
as
Not until system
"
was progressing; and fixing
exceedingly expensive and time consuming...
"is
Managers have difficulty
well a project
the design
in
a
tracking the progression of the system from
result
have problems
they
in
planning and
controlling the developing system."
3)
Changing
Performance
Requirements
The problem here was
:
"Performance requirements are subjected
to interpretation
that
and change as
soon as the system design and implementation process begin the translation
of requirements to
computer programs."
to specify completely
coding,
Not only was
it
nearly impossible
performance requirements before detailed design and
but there were often disagreements on the meaning
of
certain
requirements, and changes demanded by the customer.
4)
Lack of Design and Verification Tools
level
languages,
debugging
data-management systems,
tools, facilitated
subroutine
coding and debugging.
"There are few widely
ijsed
tools
such as highlibraries,
.and
But Bratman and Court
asserted that these activities accounted for only about
costs.
--
Several tools
:
20*^ of
development
and techniques 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)
Lack of Software Reusability
required similar logic,
:
There were many application areas that
but there was
10
little
capability
SDC
to
reuse software
Software Factory
"Extensive
components,
use of off-the-shelf
software modules
would
significantly lessen the risk and shorten the time required for software
development. "^^
To solve these problems,
Factory,"
which
supports
the
they
defined
concepts
Bratman
1975
in
"The Software
Court offered
integrated
"an
as
structured
of
and
programming,
set
of
tools
top-down
that
program
development, and program production libraries, and incorporates hierarchically
structured program modules as the basic unit of production."
hoped
to attack
through "the careful system component structuring, the specific
relationship with performance requirements,
inherent
in
None
software developed
of
the
"revolutionary."
procedures
in
and the improved documentation
the factory.
and
tools
"^"^
under development were "new or
But Bratman and Court insisted that, when integrated and
applied consistently,
they should
introduce significant improvements
size,
complexity,
application,
result
in
in
process with the potential to
a
developing software systems "regardless of
or programming language."
offered "a disciplined, repeatable process terminating
budgeted costs and on
or
Reusability they
A
predefined schedule."
a
reduce the need to re-tool for each
in
The factory thus
specified results within
specific goal
was
to eliminate
new system, thereby allowing the
organization to get projects underway quickly and improve, through capturing
the benefits of experience,
specific functions
such as program design, code
production, testing, and project management. "^^
Although Bratman and Court complained about the unsystematic use of best
methods as well as
tools,
in
the 1975 article, they proposed a software factory
model consisting primarily of an integrated set of standardized design-support
and project-management
tools.
This can be seen
n
in
their early definition of the
SDC
Software Factory
Software Factory quoted above.
The 1975
article did
not even mention what
Bratman, Court, and Munson later considered the most important part of the
factory,
the Software Development Manual,
But, while
SDC had
also
known
as the
SDM handbook.
tried to introduce a factory infrastructure before having a
factory process, Munson explained that, by the end of 1975, they had decided
this
approach was
a
mistake:
Court and Bratman both came to work for me over in the Defense
And we spent about a year or so, prior to the time we set
Division.
up the factory, thinking through the implications of what they had,
and what the real problems are. One of the major conclusions we
came to at this point in time was that tools can't drive the
Tools have to support the technology.
And that what
technology.
the tools seemed like a great deal but, without a methodology that
the people were using, and that the tools were supporting, it was the
wrong way to go. So what we did was stop the tool development at
that point for a bit and spend about a year working on the
methodology, which was the Software Development Manual
We got
that produced, and then we essentially fitted the tools that they had
to the methodology and then defined some new tools that we
wanted. "^^
.
By
1976, Munson's team
was viewing the factory as
around three discrete elements
management;
of
a
new organization
--
standardized
of the design
had
to
in
and production process; and
tools.
actual
in
well as the
The organizational innovation they introduced consisted
whereby project managers would be responsible
and
a
set
This was ultimately
how they viewed these elements,
support the standardized methodology as
sites while
structured
procedures for design
advanced design-support and project-management
the order of importance
a "facility,"
of
that the tool set
new organization.
a
matrix
system
for system design at customer
other managers would take responsibility for building and testing the
programs
in
the factory.
Munson
recalled the factory components and
their priorities:
12
SDC
Software Factory
When think of the "Software Factory," think
The policy infrastructure -- the procedures
The tools
manual -- is one piece of it.
I
I
of three elements...
development
implement that
engineering practice is a second element.
But the third is
organizational. We included an organizational approach as part of the
factory and that included two pieces, an external and internal piece.
The external piece was a matrix organization, i.e. the work would be
system engineered outside the organization but the work would be
And within the organization we
performed within the organization.
looked at breaking down the work into, if you will, (1) design, (2)
production and (3) test as three independent spaces, with separate
organizational and management responsibilities, although we thought
But we thought of it
some of the people would flow with the work.
in the order that the most important piece was the procedures. The
And then the third
second most important was the organization.
In a priority sense, the tools were
most important was the tools.
meant to support the first two.
So the fact that we didn't have a
tools
available
didn't
really
bother
us that much. We thought
lot of
'^°
there.
we would eventually evolve
.
in
.
This broader view of the Software Factory can be seen
Bratman and Court offered
in
the
to
in
the new definition
their 1977 article:
The Software Factory Concept
[is] a software development facility
consisting of an integrated set of standards, procedures, and tools
that supports a disciplined and repeatable approach to software
development and replaces ad hoc conglomerations of developmental
techniques and tools with standard engineering practices.-^'
METHODOLOGY. ORGANIZATION, TOOLS
FACTORY COMPONENTS:
Element
For
a
1:
Standards and Procedures
year and
a
half
during 1975-1976, Munson's team identified
standards and procedures -- general rules and specific guidelines
be applied to
all
software projects,
based on
a
life
a set of
-- that
could
cycle model of software
development and covering the major activities, events, and product components
common
to
all
projects.
They wrote these down
13
in
an engineering handbook,
SDC
Software Factory
the
Software
Development Manual,
methodology was consistent with, and
standards,
military
" ^°
2ft
libraries.
The
1976.
in
instances borrowed from, existing "U.S.
in
and the better
The required programming practices included
top-down program development, and program
structured design and coding,
production
SDM,
as
Air Force Manual 375 requirements,
U.S.
practices.
commercial
known
also
addition,
In
SDM
outlined
a
management and control
process, providing guidelines for planning, project control, review and evaluation
procedures, and quality assurance.
manual
in
1976, Mueller directed that
After Munson's group finished writing the
all
line
organizations adopt
it
for current
and future projects. ^^
Deciding on the standards and procedures for the factory was essentially
SDC had done,
matter of examining previous projects
a
reviewing records and
interviewing personnel, determining what had worked well, and codifying what
appeared
to
be "best practice."
factory architects, to provide
factory
more than just
working
reasoning
from
a
in
1977:
similar
a
a
This process was necessary, according to the
common language and methodology
building
pile
of
housing
tools.
a
large
Bratman
number
and
Court
of
to
make the
programmers
explained
this
The procedures hold the disparate portions
of the Factory together:
the standards are the means of making the Factory efficient and easy
to use and learn.
Without the standards that establish the Software
Factory methodology and the procedures that establish the precise
way of doing a task, the Factory is little more than an agglomeration
of software development tools.
Standardization, initially established
and faithfully maintained to reflect changing conditions and continual
improvement, is essential to the success of the Factory. The ...
standards. .establish a working environment where the creative design
solutions of key technical personnel can be implemented in
highquality products, on schedule, and within budget. More specifically
they:
.
in the software development process;
of
transfer
expertise from one project to another;
rapid
allow
-- establish a consistent framework for cost estimating;
--
promote repeatability
--
14
SDC Software
Factory
—
—
—
—
make it possible for people to
common understanding of goals;
new
mode
efficiently
and with
a
provide the capability to measure project progress in a realistic
manner;
enforce technical and management techniques;
establish a basis for assuring and measuring software quality. ^
Munson explained the compilation
view:
interact
of the
SDM handbook from
his point of
an exercise to avoid having to "reinvent the basic process" with every
project, as well as to provide a transition vehicle to
of production
move
into the factory
by standardizing around good practices, with more detailed
guidelines than the usual "high-level buzz word[s]" offered:
The reason
for it [SDM] was really one that said we need engineering
handbooks for our people to use. We shouldn't reinvent the basic
process. How do you build a building? You don't reinvent it every
time.
We know these things, and we know what good practices are,
so lets put them in a handbook that we require our engineers to use.
And that was really the reason for the detailed handbook... [I]t
wasn't that it was any big original concept at that point in time. A
lot of people recognized it and were trying to do something", and
were doing good things. ,. [0]nce we got that handbook done, we
worked on the organizational concepts.
That was when we
implemented the Software Factory by collecting up all the software
projects that were being done in Santa Monica at that time. We had
already picked some of the better people around and had them
working with us on the handbook for a year.
We had some of the
best people out of the line engineering organization working with the
R&D people in developing that handbook. We as a team became the
.
.
transition vehicle."^'
The
first
standards
that
SDM
development life-cycle," composed of
performance,
development,
design,
maintenance (Figure 3.1)
outputs,
completion.
functions.
.
.and
.Each phase can,
each of which yields
a
.
."^^
a
set
were for
six phases:
test
and
a
"time-phased
software
planning, requirements and
acceptance,
operations
and
Each phase contained specific "objectives, inputs,
criteria
in
for
corporate
review
of
successful
turn, be broken down into smaller activities,
product; each product requires
a
standard, each activity
procedure."
15
SDC
Software Factory
7*«^jt(«*
'igurt I:
Softwarm ayatsma davalopmmnt lifa^cyala
The Planning Phase required
strategy for program development and a
a
schedule of measures to carry out the plan.
things:
It
set
up
the specific tasks required to deliver the product.
(1) It identified
identified
This activity accomplished three
and allocated resources needed
procedures
for
monitoring
and
And
to complete the tasks.
controlling
Managers were responsible for drawing up
a
detailed
project
(2)
(3)
it
performance.
"master project plan,"
which included the following elements:
Software Development Plan
Project Work Plan
Project Organization and Staffing Plan
Project Budget
Documentation Plan
Configuration Management Plan
Quality Assurance Plan
Project Monitoring and Control Procedures.
In
the Requirements/Performance Phase, managers had to "delineate and
describe the
parameters,
software
and
requirements."
system's
means
the
This
included
functional
for
verifying
deciding on
characteristics
that
and
performance
system meets
the
these
computer languages and design
standards, selecting production tools, and "investigat[ing] available software
modules that could potentially perform the required functions."
The Design Phase
system structure
in
of the higher-level
completion of
also
all
a
called for determination of the details of the software
top-down fashion
--
"continual functional decomposition
modules into more and more detail
the modules decided on
had to decide how
to
in
--
and continued
the requirements phased.
until
Managers
develop the product "by multiple teams without
excessive coordination."
result of the design phase is a system representation which
consists of descriptions of all system components (modules, data
elements, and control logic); their dependencies and relationships,
both to each other and back to the performance specification; and
The end
17
SDC
Software Factory
the accompanying schedules and resource allocatiohs.
In
the Development Phase, programmers completed detailed designs of the
components identified
in
the computer program's design specifications, coded the
modules, and verified their correctness.
tracked
tool
A Program Production Library (PPL)
version of the system as
each
The SDM provided
evolved.
it
extensive examples and guidelines on how to complete and document
top-down, hierarchical manner, culminating
modular design
in
representation
.consisting of operational code."
..
a
The Test and Acceptance Phase began "with delivery
package
to the
PPL
for testing
The basic objective was
by the customer."
worked
well
as
reliably
and ends with acceptance
of the
determine
to
of
in
a
detailed
a
system
program
the
program system
the coded modules
if
conjunction with each other and the system hardware,
in
performed according
requirements.
to the customer's
and Maintenance Phase consisted
of
installing
the system,
as
The Operations
training
support
personnel, correcting errors or inefficiencies, and then adding improvements as
necessary.
SDC updated
it,
the manual every couple of years and
in
1987 was
still
although the company was preparing to adopt new military standards.
not clear to Munson,
It
was
however, that the military handbooks could ever provide
adequately detailed guidelines to manage the development process.
"the Department of Defense military standard
than
using
our Software Devetopment Manual
and
is
at a
you
He believed
level significantly
will
still
need
higher
something
equivalent to the Software Development Manual to implement the Department of
Defense standards.
Element
2:
"^"^
Organization
As noted, Mueller, Munson, and other SDC managers did not conceive
18
SDC
of
Software Factory
the factory
by SDC
initially as
being more than this set of tools and methods for use
they did not
around the country;
facilities
Software Factory as
at
think of the
first
A major reason was
a physical, centralized "facility."
that
the Department of Defense frequently required software contractors to locate
development teams
hardware
at the
large centralized facility
scope were the
Other factors that argued against
sites.
able to take advantage of economies
incompatibility
of
many computers
programs, and the wide variety of applications involved
As
a
hardware
tools
in
SDC wrote
which
for
programming jobs.
result of Department of Defense preferences, as well as market and
realities,
SDC had
and decided on
its
evolved
a tradition
own practices.
where each team
Yet this tradition tolerated expensive
growing shortage of skilled programmers,
it
proper set
systems,
of
experts
telecommunications,
frequently.
It
managers to get
etc.,
operating
on
in
Due
group
a
programming jobs as
was becoming harder
different locations or
seemed more
of
logical
to
specialists
well as the
Mueller,
together
methods and
After studying these problems,
in
compilers,
who were
in
tools to
one
facility
all
large
number
of economies of scale
Atchley
other
tools
and bring the
them:^
in
Santa Monica to
and techniques, as
of personnel
and providing for cross-utilization
a
totally
formalization of the type of organization
19
new way
The
well as remote-terminal
of software projects concurrently, taking
saw the factory not as
SDC
1976 Munson's group recommended that
and computer technologies that allowed "a single set
a
move
the software SDC's System Division contracted for.
would use standardized
and control
interfaces,
and
site
to a
to find the
willing to
Munson,
create a centralized software development organization
build or control
own
built its
redundancies and was often impractical for the software vendors.
SDC
and
scale
of
a
to monitor
advantage
of scarce skills.
to
SDC had used
organize
for
SDC
""^^
but as
a
SAGE and some
Software Factory
other major development projects:
[the Factory] 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 wejust kind
of moved that concept into place and made it more formal."^"
We implemented
As
in
the
past,
the
f-actory
structure
still
required
the
division
to
Program or
established program offices at each customer site (Figure 3.2).
project managers maintained responsibility throughout the life-cycle for program
management and control,
customer relations,
requirements and
performance
specifications, system engineering, and quality control and assurance.
the actual software and test
hand
off
it,
system specifications
three groups within the factory:
To build
however, program managers were supposed
to
what was essentially an "assembly
line"
to
of
Computer Program Design; Computer Program
Bratman and Court expected
this
division of labor to facilitate continuity and pooling of skilled personnel,
the
Development; System Test and Verification."^'
use
of
a
visibility
at
centralized
program library,
familiarity
with
a
set
of
tools,
and
and control over product development through the review procedures
the end of each development phase:
The basic tenet of this philosophy is
over time if essentially the same
that increased benefits accrue
people are responsible for
Software
activities
in
the
Factory.
production
Familiarity and facility
with tools is gained with repeated use; general purpose libraries are
built up which simplify new production efforts and centers of
technological expertise can be maintained which allow the best talent
Within this production
to be applied to multiple activities.
20
SDC
Software Factory
organization several further divisions seem to make practical sense in
accomplishing the management objective of maximum visibility. This
involves organizationaJly separating design, production, and test.
Since the end result of each group's activities is a tangible product,
the requirement for turnover forces top-level visibility and represents
a natural point for review and quality control.^"
21
SDC
Software Factory
Software Factory Organizational Principles
01
><
r
—
3
^
—
t/1
<
12
3
i
o
;3
^
•
u
Ci
a
i
•»
3 1 ^ «*
S 3 r 3
3
5 5 =
i 3
3
wi i.
r
^
:.
••*
=: =!-»
'^
o Q 3 r
^ ^^
•
•
•
;j
•
The SDC authors,
at
least
in
recognized that separating system
1977,
design from program production offered both an advantage
customer, and
potential disadvantage
a
in
—
closeness to the
remoteness from the factory.
hoped that standards and communication
interface procedure"
in
—
normal,
"a
They
well -understood
could overcome any problems:
One
of the major advantages of this .allocation of responsibilities is
that the program office is not tied to the computer location.
In
fact, it is highly desirable for the program office to be co-located
with the customer/user to assure the rapid unambiguous coordination
of program activities. On the other hand, remoteness of the program
office from the development facilities does present a set of potential
advantages and challenges.
The problems of separation must be
mitigated by a normal, well-understood interface procedure. Benefits
include the formalized specificity required for communication between
the project office and production activity which provide management
visibility
and prudent checks and balances. ^^
The Tool Set
Element 3:
"Factory Support System" was the name Bratman and Court gave to the
"basic structural
methodology.^^
and control components" designed
This ran on
a
support the factory
to
host computer (an IBM 370,
initially)
and used
the facilities of the host's operating system to automate or partially automate
many procedures
for keeping track of program development and collecting data
(Figures 3.3 and 3.4). The system, which was written
to facilitate transportability,
higher-level language
in a
had several capabilities:
support of top-down development
automation of management support
maintenance of requirements through implementation
provision of library/history capability
23
SDC
Software Factory
complete symbolic system data control capability
semi-automation of program checkout.
The
tool
set included three main
The Factory Access and
sub-systems:
Control Executive (FACE) performed control and status gathering services for
all
processors,
supported the factory command
language,
system development data
and
processors
with
Production
Library services.
Control
the
milestones,
tasks,
provide schedule,
components
level
Integrated Management,
(IMPACT)
Techniques
base,
resources,
utilized
production
system components,
resource computation,
data
the
integrated
provided
Program
Project Analysis,
base
and
on
information
and their relationships
and status reports
at
tlie
to
individual
or summarized at any module or task hierarchy level.
The
Project Development Data Base established data bases for each project using the
factory and kept track of
test cases,
all
schedules, tasks, specification components, and
along with the copies of each program module and the up-to-date
status of the project.
This
tool
actually consisted of two databases, one for
software development and another for project control.
24
SDC
Software Factory
Software Factory Architecture
IMPACT
Capabilities
J 3
Z2
E
3
5l2
e
o
I
ft*
«
-
•
The
Project Development Data Base facilitated the automation of
development, management
visibility,
configuration control, and documentation.
The Software Development Data Base extended the concept
and kept copies of modules from their
completion
as
object-language
program
of a
program library
first functional definition
The
programs.
Project
through their
Control
Data
Base
maintained the system and program descriptions and supporting management
data,
was oriented toward the software system structure and the
which
activities
performed to develop the software system.
IMPACT was
manager
of
a
the central
software project
factory management tool.
in
This
assisted
the
planning and monitoring the production of
various items, such as specification documents, program modules, user manuals,
etc.
for which his project was responsible.
"It helps
him plan, monitor, and
control the work; define and control the software configuration; and ensure the
observance of quality assurance measures.
management reports.
In
potential
and
difficulties
structured
It
assists him in the preparation of
the evaluation of project progress,
developmental
trends."
and
IMPACT
in
also
spotti-ng
supported
programming and modular design by fostering the creation and
integration of a hierarchical structure of program components.
input data,
IMPACT
also forced a planning discipline on project
requiring them to know and define
relationships
among them.
all
In
preparing
managers by
the elements of the project and the
Elements included:
requirements and deliverable items
requirements and program functions
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
27
SDC
Software Factory
and the resources necessary
activities
impact's project management
support them.
tools fell into three functional areas -- data
and maintenance,
base generation
to
planning and control,
project
generation.
Data bases were built by providing such information
descriptions
of
program items and
Data
activities.
and report
IMPACT
to
and
be inserted
could
as
processed interactively during the development cycle.
Project planning
and control involved three major functional modules--
the Scheduler, which derived and optimized critical path schedules and resource
Trender,
the
allocations;
which
tracked
trends
and
anomalies
in
project
performance; and the Threader, which interpreted the hierarchical structure of
the software system and the organization
of
manager or system architect could direct the Threader
is,
call
For example,
project work.
to "pull a thread,
"
a
that
for a trace on the development status of elements at various levels of
The report generation function
abstraction.
information stored
Configuration
Modification
included the Management Summary,
Index and Status,
a
in
access to the
Reports which
Resource Allocation,
Configuration Summary, Modification
Summary, and the Module Run Summary reports.
not only assisted
"constituted
IMPACT provided
the development and control data bases.
in
could be requested
of
These
Index,
capabilities
project planning; according to Bratman and Court, they also
powerful modeling capability designed to significantly increase the
project manager's efficiency and effectiveness."
Several additional tools provided for
Automatic Documentation Processor
documentation,
programmer.
using
comments
a
variety of other support functions.
(AUTODOC) produced program and system
inserted
into
tlie
program modules
Program Analysis and Test Host (PATH) was
analyzer that analyzed
a
source program and
28
inserted
calls
a
to
by
tlie
program flow
a
recording
SDC Software
Factory
program
at appropriate locations.
Bratman and Court claimed
'
provide information about the structure of the program, to aid
Data Definition Processor
of testing.
defining
data
languages
for
system programs written
assure that
to
well
as
several
the
of
in
thoroughness
means of
central
a
common programming
system
would
have
Test Case Generator (TCG) was an automatic
technique for designing test data.
tool that
in
program modules
all
compatible references to data.
modeling
(DATADEF) provided
this helped to
Top-Down System Developer (TOPS) was
provided the capability to describe and verify
describe much of the control and data interface logic
a
a
design, as
in
the actual
coding language.
Bratman and Court claimed the Factory Support System was "flexible"
the sense that
This
flexibility
it
allowed for
was
new
necessary,
completed their planned
tool
tools to
Engineering
R&D group had
Systems
in
Group,
1977 and
the
staff
in
a
good editor.
Bratman and Court were
yet
1987 was director of the
successor to the Software
"We
Factory, admitted that some of the planned tools never materialized:
don't have
not
development when the factory went into operation.
Ronald Atchley, who joined the factory
Software
be added as they became available.
because the
too,
in
...
We had
to
still
do the traceability by hand..."'*^ Yet
totally confident
they could build
a
fully
automated
software factory and concluded their 1975 and 1977 articles with identical words
of optimism:
Our
long term plan is that the Software Factory will be
augmented by the continued development of more sophisticated
tools and techniques such as application-oriented process design
languages, re-usability technology, correctness verifiers, and
cross compilers and will therefore evolve into a truly
automated software development facility. ^*^
29
SDC
Software Factory
The Factory Opening and
The Software Factory
programmers located
recalled the site:
were
in
a
in
facility
SDC
an
a
building
in
December 1976 with about 200
the center.
in
stands, but we've moved out."
As expected. Jack Munson
Software Engineering Organization established within the
in
to the
SDC Systems
new
Division.
put approximately 10 major projects through the Software Factory
between 1976 and 1978.
came
We
Everyone had an outside window.
served as the first manager of the factory, which formally belonged
SDC
Atchley
Santa Monica, California.
in
block long, two stories high, three long corridors
with cross corridors and patios
still
opened
"That's the only large open office we had at that time.
building about
That building
Dissolution
All,
according
on time and within budget.
SDC adopted
to
Munson and the company
The company history
history,
also asserts that
the factory practices as corporate standards, with Munson and his
chief deputy moving upstairs into higher
management
1978 to oversee this
in
transfer process:
Mueller and Skaggs extended the discipline
Munson was promoted to corporate vice
president responsible for all software development in the corporation,
while Hamer [deputy manager of the Software Factory] performed a
similar function as a division vice president for the Systems Group.
In
the spring of 1978,
throughout the company.
In reality,
the factory had been gradually dissolving as the number of new
projects going through the facility declined, reaching zero shortly after
left.
Munson
whimper."
It
recalls that the
Software Factory ended "not with
a
Munson
bang, but
a
simply "devolved" out of existence:
New stuff didn't come in. They started
just sort of disintegrated.
Software
Factory stayed and eventually it
The
letting stuff go out.
then
it
became a functional staff
became like a one project thing,
And it just kind of disappeared by dissolution,
organization.
It became a resource for staffing other programs and got
evolution.
It
.
.
30
SDC
Software Factory
dissolved that way.
Good people went here to this program, good
people went there to that program.
And, in fact Atchley's title is
still Director of Software Engineering, back in that old division and
so, essentially, he's currently the Software Factory.
It devolved. But,
for all intents and purposes it never was officially stopped.
It just
disappeared. .. Nobody ever really put a bullet in it's head.
You
couldn't point to the day it died.
That was strange. ^^
.
Atchley recalls that, after Munson
facility to
left,
programmers gradually
work with the "plans and programs people"
represented
a
.
left
at customers' sites.
the
This
return to SDC's pre-factory mode of project organization:
[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 interface out of the
program office with the factory.
They are a part of the
organization.
They used to give us the specs and say 'Go produce
this software.'
The plans and programs person would be the
interface, and he would be controlling the budget ... As it is now, we
are a part of the program office; we work in their area, physically.
We moved the people into that physical area; we no longer keep the
people physically separated.^"
According to another
programmers
to different
types of applications.'^^
factory.
Some
of
SDC manager, Clarence
customer
them to specialize
sites allowed
SDC had
This was the strategy
the factory discipline and
Starkey, the assignment of
in
particular
followed prior to the
procedures
remained but the
notions of a standardized tool set, a centralized factory work flow, and a crew
of
permanent factory workers disappeared.
was never complete and they expected
Atchley explained that the
this to evolve,
dismantle this part of the factory; old tools
Division
abandoned the matrix organization,
fell
tool set
so there was no need to
into disuse.
however,
SDC
so that
's
System
"the factory
workers go to the work":
31
SDC
Software Factory
You would
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,
They weren't really dismantled. They were
but it wasn't all there.
in disuse because new ones came along, and we just no longer used
The only thing we re still using, and we won't use it much
them.
longer, is PDL [a Program Development Language SDC developed for
We're still using it, but. .within the next six months,
in-house use]
we're going to be all converted over to BYRON [a commercial
product]
PDL was a Pascal-based system. That's the only thing left
We're moving to ARGUS, we're using a new
that we're still using.
What we're trying to do now is establish a
Times change
editor.
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
The factory workers go to the
does not flow through the factory.
work.^0
Factory.'
not
...
.
.
.
.
.
.
.
.
.
.
.
.
A remnant
tried to focus
remained
of the factory organization
its
facility,
SDC management
But
facility.
Paoli follow the
same matrix organization Munson attempted:
"they are
They are kind
hybrid, they ve got some functional and some matrix organizations.
compromise.
Maybe
But not bad.
that
is
what we
form when the U.S.
a
set
of
Department
of
of
the
Department
of
Laboratories, Mitre Corporation.
Defense
and
an
offshoot
of
''-'
a
broader
in
1976 to
in
standards for military-use software procurement.
in
of a
kind of
tried.
SDC
Defense contracted with
directed this effort and completed the first set of standards
help
It s
have
sliouid
The methodology underlying the Software Factory continued
develop
not
is
as systematically as the smaller Software Factory used to be.
not anywhere near as structured as our Software Factory.
a
does not
it
'Software Factory" and, according to Munson, the facility
managed nearly
Nor did
that
which has about 500 programmers,
adopted the practice of bringing work into one large
use the term
in
larger facilities on specialized lines of business. As Atchley
(Pennsylvania)
the Paoli
noted,
.
Munson
1979,
with the
MIT's
Lincoln
The government subsequently published these
32
SDC Software
Factory
as a 16-volume set of guidebooks. ^
INITIAL PROBLEMS REVISITED
FACTORY PERFORMANCE:
SDC
has not published data from any of the projects which went through
the Software Factory.
It
is
possible, however, to get a sense of
factory performed by comparing some accounts of
its
:
Absence
of
development
a
standardized,
process
predictable
stemming from
a
well the
operations with the five
problems that, according to Bratman and Court, motivated
Problem #1
how
inception.
its
approach
"lack
of
to
the
discipline
and
repeatability."
Did the Factory solution work
On the "yes"
the
and
practice?
Yes, and no.
side, division of the development process into distinct phases,
standardization of the process as outlined
in
the Software Development
,
and the tracking capabilities of the Factory Support System data bases
it
possible to improve predictability and control dramatically for budgets
Manual
made
in
time
According
schedules.
to
Munson and the company
history,
approximately 10 large-scale projects went through the factory and
missed
a
schedule or overran"
a
budget.
One
"never
of the largest, for example,
an air defense system for Morocco that took 30 months to build, which
completed successfully
Additional
in
the factory on
a
SDC
fixed-price $3.5 million contract.^
evidence for the success of the factory as
33
was
SDC
a
mechanism for
Software Factory
Department
2168)
project
or
process
control
Defense modeled
of
in
is,
its
SDM manual and
after the
Munson's
view,
the
the
that
fact
U.S.
standards for military contractors (2167 and
other
SDC
Munson was asked
practices.
to
serve as chairman of the joint business and defense department panel that
recommended creating the
and he claims he based
military standards in 1979,
recommendations on "my experiences and our factory...
I
his
think [the 2167-2168
standards] were actually results of our Software Factory."^
On the negative
to
side,
however, too much of the factory discipline appeared
come from Munson's enthusiasm and leadership, rather than from the new
systems
planning
for
statistics
and
management control.
and used these for control purposes, after Munson
1978, other
managers did not keep up these practices as
even claims that, when he joined the factory
accurate
Although
statistics
completion,
on
reuse
or program quality.
improvements
productivity
rates,
This made
left
if
kept careful
the facility
in
rigorously."'"'
Atchley
no one was
keeping
improvements,
difficult to tell
it
efficiency or productivity, and
in
1977,
in
he
if
schedule
there were
they were directly related
to
the factory or not.^°
Munson describes what happened
as
being
a
matter
of
the
losing
"advocate," the "evangelist" for the process innovations the factory represented.
Once he moved up
SDC proved
into higher levels of administration,
be as strong or as successful
to
in
no other manager
promoting the factory idea.
Furthermore, to learn from the data and make the factory work up to
potential would have required more than the 3 years
to
the
facility.
For
these
reasons
Munson
represented "a great start and what happened
keep
it
going.
.
.we had
a
is
in
SDC management
concludes
that
we lacked the
will
the
and
its
full
allotted
factory
skill to
bright beginning that was never fulfilled":
34
SDC
Software Factory
f
We
did keep statistics but unfortunately, after the organization
ceased to exist, people didn't keep them very clearly,
was the
advocate, if you will, for the factory, and when
moved out of that
specific organization, which was what was intended -was going to
spend a couple of years there setting it up and then the agreement
could move on to something else -- the problems with the
was that
left.
For the couple of years
factory occurred after
was there,
everything was going well and it was on an upswing. And
think
when you take an advocate out of something that is as fragile as this
was conceptually in our organization, then it kind of lost the heart.
And the people just didn't have the will to make it succeed.
[W]hen
passed the baton the advocacy, the evangelism went out of it. It
It needed a
tried to become something routine, and lost something.
And a lot of force, drive, and selling.
lot of effort to make it work.
Did the factory solution work
think it lost some of that...
And
My attitude towards this is one that would summarize
in practice?
by saying that we made a great start and what happened is we lacked
the will and skill to keep it going... One of my problems is that
these kinds of experiments are not 2- to 3-year experiments. They
are 5-, 6-, 7-year experiments, in order to get good data and so we
just didn't go long enough. .We had a bright beginning that was never
i
I
I
I
I
I
I
.
.
I
I
I
.
fulfilled. 5'
Problem #2:
management
Project
difficulties
stemming
from
a
"lack
of
development visibility."
Did the factory solution work
The same
The
in
practice?
Yes.
positive factors discussed under Problem #1 affected this issue.
clear division of product development and other operations into distinct
phases ending with
System,
all
provided
In particular,
design
a
the
reviews,
and the
means for managers
IMPACT
tool
tools
of
the
Factory
Support
to visualize better the process flow.
served as
a
control mechanism for tracking
costs and schedules, completion status, and monitoring lines of authority and
responsibility for a project.
managers used IMPACT data
During the planning and system definition phases,
to allocate
35
resources,
check functional designs
SDC
Software Factory
against performance requirements to assess their completeness and accuracy, and
to
IMPACT
generate reports.
design
completeness,
assessment of
different
and
effectiveness
is
testing
no
TOPS provided
as well as
while
PATH
the
that similar tools soon
tools
a
more
evolved
some
but
versions,
better
provided
These
completeness.
doubt
tool
visible assessments of
became common
quantitative
over
time
indication
in
nearly
all
into
their
of
software
organizations faced with managing large, complex projects.
Problem #3:
Inability
requirements
accurately
define
to
at
a
customer
performance
s
the beginning of development or to deal easily
with changes made during the development process.
Did the factory solution work
Rather than
a
simple "no,"
it
in
No. and yes.
practice?
might be said that the factory worked as
best as could be expected given the type and variety of products
one
the
hand,
SDC accepted
contracts
for
so
many
SDC made. On
different
applications
systems running on so many kinds of computers that accurately defining and
meeting customer needs was no doubt
a
a
herculean challenge.
is
to
large extent intrinsic to any design process, except perhaps for firms making
products with the most stable and standardized features.
help with this issue?
Then there
is
process?
But did the factory
the second element of Question *3:
much did the factory help manage changes
in
This problem
in
requirements made during the
These resemble engineering change orders related
to
product designs
hardware manufacturing, frequently cited by manufacturing managers
bane
of their existence, too.
No design process could be expected
36
How
SDC
as the
to eliminate
Software Factory
—
these completely
The answer
is
but did the factory process help?
yes,
The Software Development
the factory did help.
Manual tried to capture the experience of the better system designers on how
to define
customer requirements.
then codified these "best practices"
It
writing and they became standard procedures,
modifications
over time.
Division
phases with design reviews made
of
it
in
subject to improvements and
the development process
easier to identify
if
into
distinct
detailed design and
coding was actual implementing the customer's requirements, at least as they
were written up
in
the design documents.
Tools such as
IMPACT
also helped
personnel keep track of the interrelationships among system components, and
this should
have
architecture.
more obvious
facilitated analysis of the effects of
changes on the product's
Munson agrees that the factory helped,
if
especially in making
it
discrepancies were appearing between the design requirements
and the actual product being
built:
by breaking it like we
did between the requirements and the implementation, was to create a
very, very visible interface as to what the status was of the
requirements when they were turned over to implementation. In most
One
of the things that
projects,
we were trying
requirements are just
to do,
a flow in
the implementation.
It
is
very easy for that to merge and never be seen by top management.
We didn't do much better in making requirements more thoroughly
determined ahead of time.
But on the other hand, we were clearly
able, because of the interface on the hand-over between the
requirements people and the production people, to make it very, very
And we were able to put into our
visible as to what the status was.
plans, then, the fact that we didn't have yet a good set of
requirements. So, we didn't solve the basic problem.
But we sure
made the characteristics of the problem more visible. And we made
the impacts of the problem more manageable in the production
process, because we at least recognized \t.°
.
37
SDC
.
Software Factory
Lack of tools for design and verification.
Problem #4:
Did the factory solution work
The Software Factory began
team clearly did
work
a lot of
as an effort
development and Court's
tool
in
TOPS and DATADEF improved
in this area.
and verification (tests for
levels of automation
No. and yes.
practice?
in
logical
correctness)
the design
in
process and smoothed the transition between design and program coding.
however,
general,
management;
seems
it
tools that
that
the
the
in
were for project
most effective tools
such as to test
interacted directly with the product,
design correctness, usually had to run on the same hardware and perhaps even
be written
in
of projects
it
the same computer language to work.
accepted,
support and testing
SDC never succeeded
in
As
result of the variety
a
producing standardized design-
tools.
Another difficulty was that SDC management did not continue
corporate money for
Mueller
development once the factory went
tool
wanted Munson
to
projects, which meant that
charge
R&D
costs
tool
of Mueller at the time
was
its
a
shoe-string budget, and told to go make
Yet the difficulties
well-funded effort.
that, in terms of
"ahead of
an
its
elusive
of
specific
inherent
in
tool
spending company money
So,
it.
"Of course
1976:
in
was
we
basically
were put
real.""'
it
development required
a
continual,
Another SDC manager, David Deaver, made the statement
what the factory was trying
time."^^
goal
expenses
opening
to stop
on this thing and get contract money to support
on
into operation.
for general-purpose tools for the factory
funded only during the 3 or 4 years preceding
one of the motives
the
to
to allocate
even
to
do with
tool portability,
it
was
This seemed to be the case; truly portable tools remain
in
the
late
1980s,
38
due
to
machine and
SDC
language
Software Factory
incompatibilities.
Munson
recalls his frustrations:
We never
did solve the problem of heterogeneous hardware, and the
very portable. .They were able to run on one
And many
system [but] were not easily ported to other systems.
times we were working on government supplied equipment, which
meant we had to use their equipment, we couldn't afford to pay for
Because the government was supplying, for
an overhead facility.
instance, PDP's, DEC equipment, and if our tools are running on IBM
equipment, there was no way we could justify the cost of the
overhead for the tools on that equipment. And the technology, in
fact, isn't yet here today, where a common set of tools are really
portable around a whole bunch of different environments. And that
was what SDC was faced with -- a whole bunch of different
fact that tools weren't
.
environments.
Munson believed that the Japanese,
in
contrast,
as
well
as
some U.S.
companies, can develop general-purpose tools because they work primarily on
compatible hardware:
Now you take a Hitachi or a NEC, or even the commercial part of
the Unisys Corporation, where the bulk of the work that they're
doing is done on their own set of equipment, that are constant and
homogenous. They yield a better chance even today, and certainly in
those days, of making a success of these available tools
[A] lot of
people, because they've had slightly different environments, have been
able to be successful, where we weren't, because of things like the
homogenous equipment and the different culture in the organization.
But, in any event,
think we pioneered and, if we failed, it was
because we were ahead of our time...°^
.
.
.
I
Problem #5:
Lack of reusability of code.
Did the factory solution work
SDC
did not design
its
in
practice?
No. and ves.
Software Factory tools and procedures specifically
39
SDC
Software Factory
to
Bratman and Court believed that practices such as
encourage reusability.
careful
structuring
of
programmers reuse code.
improved
and
modules,
would
documentation,
help
Atchley recalled the beliefs of the factory's architects
regarding reusability:
technique (top-down program design)
and if we used modules, that the reusability would fall out of it. .you
would decompose your requirements into functions and come up with
code that was modular and reusable by following the techniques in
And then, as a fallout of that, you could go back [to the
the SDM.
program library] and find it and reuse it. ^
They
felt that
if
we used
this
.
But these practices
in
and successes SDC encountered regarding
difficulties
SDC achieved
code reuse.
when applications and the computers
the code was written were the same.
Reusability
was primarily
in
function of similarity
chance more than
advantage
projects
people
of
similar to
and
deliberate
similarities
in
strategy
across different projects by submitting low bids for
libraries
the
in
In
helped
factory
sense,
this
achieve
there was
surplus of work, and there was not
Because reuse was hard
programmers generally did
iVIodules
for which
Managers could take
and planning.
But managers could not really plan for similarity
library.
the
applications and hardware, and thus of
reusability.
a
in
the Software Factory, then,
what they had done before.
program
tool portability applied to
extensive reuse across different projects
factory and after 1978, but only
a
The same
themselves were not always sufficient.
were also
to do,
not
try
and
exploit
projects, unless
this division.
and because managers did not require
to
reuse components
difficult to find
coding or indexing scheme, which
in
in
centralizing
in
a
SDC apparently
from
the
it,
program
library without an effective
failed to develop.
Atchley
explained:
40
SDC Software
Factory
[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-ll. And then we went to the
Emergency 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 donis 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, 'I 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 good idea, but at
that time we were unable to capture much.
It was easier to do it
than to go find it.
If you
did find it you had to re-code it.
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 classifying system. They
were on four different machines, they had four different sets of
requirements, and it was very hard to find any reusability or savings
among the four of them. We did set up a library, where we collected
all the software produced, filed it, and documented it.
Usage of that
library was very minimal. °^
difficult
I
Even
1987,
in
there was only one
I
programming project
SDC
in
Atchley knew of which was reusing large amounts of existing code.
admitted that, again, this was possible because,
same application.
just do
it.
aren't the same,
it's
not getting any static at
hard."
SDC
is
turning out to be more
very high number. °^
reuse
in
When asked how he
SDC
systems.
it's
taken us so long
ability to
...
Munson confirmed that code
is
we
it
could
Atchley says that
which he
like 50%,
felt
it;
But when the applications
all.
still
considers
a
about the low incidence of code
the early days of the factory, Atchley commented,
and we're now coming up with an
fact that
the same machine and the
"It's
actually bid on this project assuming
reuse 80% of the program code from existing
the real figure
Atchley
That's really simple... no fights, no arguments about
And we're
that
do that
.
.
.
"it's
the idea
been ten years,
is
good but the
kind of sad."^*^
portability across different types of computers
was the major obstacle preventing wide reuse
41
of code,
and that, when hardware
SDC
Software Factory
,
was the same, reuse levels were enormous.
level detailed
Sometimes they reused only higher-
designs, rather than actual code.
For example, Munson tracked
reuse rates and costs for four functionally equivalent air defense systems built
after
SAGE.
Central)
The
first
was SAGE's successor, the BUIC (Back-up Interceptor
the second an air defense system for Spain contracted to
system,
Hughes Aircraft, the third
and the fourth
levels of
system for Morocco (contracted
a
similar system for Thailand.
a
SDC achieved
to
Westinghouse)
increasingly high
code reuse when the hardware was similar, and design reuse when the
applications
alone were
Reuse
similar.
of
any type also helped meet cost
targets:
In [the Moroccan air defense system] we ended up reusing a lot of
design and not code. We had intended to reuse some code out of the
BUIC Air Defense Systems. the second version after SAGE. .. it was too
major a difference in computer systems, but we used a lot of design
and the Morocco system has since been reused almost entirely in the
Royal Thai Air Defense System [RTADS], which SDC bid and won
competitively and is in the process of implementing today... with
almost 100% use of the existing code.
So the first time we didn't
awful
And
use a lot of the code but we used an
lot of the design.
we came in on cost. And then the second time we were able to get
a competitive advantage because we didn't have to create almost any
new code for the Thailand system. Thailand, of course, isn't being
done in the factory as such. But the results, the quality of results
out of the factory gave them the opportunity to make another big,
huge sale, a 100 million dollar sale.
And RTADS is using the
products that we developed in the factory without having to modify
them. .because we had commonality of equipment. They were both on
comnpatible Burroughs computers.
.
.
.
.
.
.
SAGE
cost in excess of TOO million dollars for the computer
programs.
BUIC cost about 30 million dollars for the computer
programs. The Hughes system cost about 12 million dollars. Morocco
And the new one we are building
cost about 3 1/2 million dollars.
today for Thailand is zero million dollars, because we are basically
The reason Morocco was cheapest, for
using all the existing code.
is because we used a lot of design and
our
line
to
BUIC,
in
instance,
have
spend all the time working out what
didn't
to
We
knowledge.
interceptors
and what the equations of motions
for
the dynamics were
were and all the data base functions and structures.
We knew all
[D]esign is about 40% of the cost of a system
those kinds of things.
and the test is about 40% of the cost of the system. So if you reuse
the design you can reuse a lot of your test so it cuts a lot of that
[I]t talks to the fact that. .when
80% of the cost of the system out.
the programmers really do understand the problem they have a much
.
.
.
.
.
.
42
.
SDC Software
Factory
better chance of doing
it
right and cheaper, as opposed to bringing
new pro to do it.
[A]ir defense systems are air defense systems.
There has not been any new
They were -the"/ they are today.
In a
.
.
technology.""
This type of reuse involved redeploying an entire software and hardware
system
in
another location, rather than utilizing modules of code as building
blocks for different types of programs.
Some Japanese software
reuse of large and small chunks of code and designs.
Japanese,
as
he
did
with
tool
portability,
In
factories stress
comparing
--
what they would have
to the
Munson attributed the greater
apparent emphasis of the Japanese on reuse to more commonality
and applications
SDC
liked
to
in
have had more
machines
of
in
the
Software Factory:
At the macro level we are talking about with air defense systems we
really didn't do anything specific other than use the good
programming practices that we had built up for the factory anyway.
And when we reused the total system, we aren't talking about
modular reuse.
Where Japan is getting a lot of their productivity out
of reusability are in things that are multiple uses of common products
And a lot of it is
able to move across homogeneous product lines.
not in the applications software it's in the overhead software.
A Fujitsu, NEC, or
Utilities, operating systems, macro libraries.
Hitachi can do that because they're not programming for IBM, DEC,
or Burroughs.
And their architectures tend to be instruction
.
compatible.
.
."'
.
On the other hand, Munson stressed
that reusability can also be viewed
in
terms of "reuse of people" -- allowing designers and programmers to apply the
learning they acquired on one project to new projects.
the factory
—
while
it
In this
existed -- was far more successful than
where new groups were always formed, with
little
sense of reuse,
a
project system
or no repeated experience
among the members:
43
SDC
Software Factory
[W]e had some results that held some pretty high hopes for this kind
because we were seeing reusability in the people working on
multiple solutions, if not the code itself.
We had people working on
defense
second
implementation
of
an
air
system that had worked
the
first
not
whole
new
of
people
that had to learn the
on the
one,
a
set
If
look
whole applications thing again.
you
at what the academic
world, or the professional scientific world, thinks of reusability, it
really comes in a bunch of different flavors.
Whereas code
reusability, you know library modules, is only one application.
of thing
[W]e are not there yet in the coding phase, even in the Ada world,
which was going to be the solution to reusability.
But, again, the
learning curve aspects of building a system -- which is the one
involved in SAGE being 100 million dollars and Thailand being free
And we were able to
for the software -- it does apply to these.
produce a high tech system called Morocco on a fixed-price, timeAnd we
limited contract -- a 3.5 milion dollar system in 30 months.
sure couldn't have done that for SAGE or BUIC.
.
.
[P]eople reusability is almost as important think as code reusability.
clearly true in our business that the second time the same guy
That goes back to
solves the same problem, he does it better.
Wolverton's studies in the early 1970s that talk about delivering the
second version of your system, and throw away the first version.
You clearly learn something the first time through it so you can
apply productivity and quality on the second time through. .assuming
you use the same people... [W]hat the factory did was keep the
people together in one organ-ization
The same people were there the
second time it came through, as opposed to doing it here one time,
then reconstructing a team somewhere else another time -- which is
what normally happens with projects. So, in that sense [the factory]
creates a focus where all the software resources were in place and
therefore the managers managing at that point in time had the ability
to reapply the people.
They weren't dispersed, off working on
somebody else's contract in some other location.""
I
It's
.
.
NEW PROBLEMS THE FACTORY CREATED
In
addition
to
mixed
improvements on
the
five
problems,
original
the
Software Factory created several new ones that management lacked adequate
commitment or
in
part
These were interrelated among themselves but
ability to solve.
reflected
difficulties that
responses
prevented
The new concerns became
by managers and
full
(1)
programmers
to
solution of Bratman and Court's
imbalances
44
in
some
list
of
the
of issues.
the work flowing into the factory,
SDC Software
Factory
which made
its
sustenance difficult for management to justify; (2) difficulties,
both political and technical
in
nature,
introduced by the matrix management
which greatly exacerbated the work-flow problem;
system,
and
(3)
cultural
resistance on the part of managers as well as workers to the changes inherent
in
the
factory
which
organization,
commitment, as well as
in
contributed
control and cooperation;
than any others, appear to have resulted
Factory
to
lapses
in
management
These three problems, more
the dissolution of the Software
in
1978.
in
Work-Flow Imbalances
SDC employed
the name "Software Factory"
in
much the same way that
producers of hard goods separate product development and production activities
into distinct steps
scope.
and divide labor to take advantage of economies of scale and
There was supposed
more or
less distinct
to
be
groups on
a
a
managed flow
of
programming jobs through
To Bratman and
sort of "assembly line."
Court, the development data base resembled
a
conveyor and control system that
carried the work and materials (documents, code modules) through each phase,
as
workers used various
tools
and techniques
to build the product:
"In the
Factory, the development data base serves as the assembly line -- carrying the
evolving
system through the production phases
techniques
are
used
to
steadily
adcJ
in
which Factory tools and
more and more
detail
to
the
system
framework. "^9
But
a
serious
work-flow
sustain a key part of the factory:
and testing specialists.
imbalance occurred
that
made
it
difficult
to
the permanent group of design, programming,
Part of the reason was the nature of the factory's
business -- customized programs, mainly for the government.
Another factor
was SDC's planning and management practices.
45
SDC
Software Factory
came about on
Because projects
guaranteed
flow
of
work
company,
the
into
programmers for individual projects
contract
a
as
it
needed them.
tried
to be,
in
Munson
generally
hired
words,
"just lean
and
A project would build up and when you got finished you answered
mean.
people and fired them.
And
that
towards us [the Software Factory]
...
to
the same attitude they took
essentially
is
a
the programmers go.
let
s
not
the company did not
If
need them immediately for another project, managers
The organization had always
SDC
and
was
there
basis,
[W]e did not have the work
to sustain it,
and work wasn't coming through and we had our ups and downs. "'^
Clearly, the Systems Division's business was sufficiently cyclical to
make
large factory -- such as the 2300 personnel at Toshiba's Software Factory
1987 -- impractical.
of
SDC employees
This can be seen
(table).
the huge fluctuations
in
According
to
the
in
a
in
number
Munson, the division specialized
in
large-scale projects requiring 2 or 3 years to complete, and there were not that
many
and these were not possible
contracts,
backlog
of
completed by
to
expand
levels
Those that existed were primarily Department
these.
of
them,
a
to
"inventory," that
because the government generally
certain date.
The
is,
wanted
of
to
the
Defense
create
a
projects
result was that military contractors tended
as necessary to meet specific deadlines,
and
dropped, unless top management provided funds
to
to
contract when work
keep programmers on
the payroll.
46
SDC
Software Factory
Table 3.1:
SYSTEM DEVELOPMENT CORPORATION EMPLOYEES.
Year
1956
Number
of Employees
1956-1974
ways. First, we needed a capital investment from the company. The
second was to "charge" more for any given job and have the excess
go into, if you will, a pad, or a cushion. But we could never get the
company to step up and do either. But that is what you have to do.
You have to recognize that, like any factory, there will be times of
But the problem is our factory was
65% capacity and 85% capacity.
basically people and people are very expensive and nobody wanted to
consider people as important tools in the factory as if they were
machine tools. But they are very similar if you think about it in an
analogy sense. When you are not usina them you still need to keep
them there. You don't go sell them. '^
On the other hand,
applications,
there were many more customers and
backlog of work to keep
according to Munson,
chaos."
to
the commercial software area,
in
Munson
permanent group
a
of
it
such as business
was easier
to
programmers employed.
SDC's commercial software area was so busy
it
create
a
In fact,
"was
in
claims he left the Software Factory and the Systems Division
add some discipline
to this
other group:
[Tjhe reason
left this organization was to really concentrate on our
commercial area, which was in chaos, a disaster at that point in time,
and try to bring more discipline to that. And they had big backlogs.
It worked fine.
But those are generally not the job shop kinds of
jobs you get with the military.
DoD [Department of Defense] wants
a weapon system and they want it delivered in 48 months. It is hard
to put a competitive procurement into backlog.
Whereas an MIS
[Management Information Systems] department that has a whole bunch
of changes they want in their MIS system might be willing to put
that kind of stuff in a backlog.
So, there are really apples and
oranges in this kind of situation. What we were talkina about with
the factory was really high technology weapon systems.'^
I
"Matrix" Management
Despite the cyclicality of the Systems Division's business,
have been enough work
in
the division,
and surely enough
approximately 4000 programmers, to sustain
end
of the
a
Software Factory does not appear
48
facility with
to
in
there should
a
company
200 employees.
of
The
be due simply to the "ups and
SDC
Software Factory
clowns"
in
the flow of work.
program managers out
in
The
real
the field
essence of the problem seems to be that
responsible for system design were not
required to use the factory to code and test their programs.
SDC
this writer to believe that
was hard for
It
did not insure the success of
a
facility that
took nearly 4 years to put Into place by requiring managers to use
it.
In
response to an inquiry on this, however, Munson confirmed they did not.
He
blamed the situation on
superiors
a
lack of commitment to the idea,
(except perhaps Mueller),
and
a
especially from his
strong tradition of "projectized"
management, rather than matrix management.
that's back to the management.
In my opinion, they were
hedging their bets, if you will.
They weren't willing to make a
commitment and so it was the 'oiling the squeaky wheel' syndrome.
All these guys out here would just say a factory can't do this, I've
got to do it out here for some reason.
My customer wants me to be
It didn't
in his facility. And management never fought very hard.
say, 'No, there is one way we are going to do it and this is the
way.' That might be overstating it a little bit. But, in essence, that
is really true.
And that goes back to the cultural, the projectized
versus the functional kind of organizational aspects. SDC historically
has built into its genes, even built into the software business genes,
this projectize mentality. .^.The only way you can build a software
Well,
project
is
to projectize it.''*
The Software Factory depended upon
a
type of matrix
whereby there were program or project managers
located
in
responsible for dealing directly with customers; and managers
organization
the field and
in
the factory
responsible for producing the actual software -- detailed design, coding, and
testing.
In principle, this division of responsibilities
and labor was no different
from non-software firms that had separate product development organizations
and then manufacturing operations divided
practice, software firms like
labor
SDC
into functional
departments.
In
usually manage by projects rather than divide
among so many different groups.
49
Sometimes division of labor
SDC
is
not
Software Factory
desirable for technical reasons.
go
smoothly
requires
In
ail
substantial
efforts
communication, and cooperation among
On the
not
all
standardization
in
Because of
implementation
the customer's
and
"application-specific"
practices,
this,
expertise as the program managers
some managers did not want
testing
phases
as
site,
had been SDC's practice
program managers
to
use the factory.
of the matrix
to give
up control
and
organization
the central
to
problem for Munson and other factory
breakdown
work
the relevant groups.
sending work into the Software Factory, preferring
political
of
off of
technical side of this issue, sometimes the factory programmers did
have as much
wanted.
make the handing
cases, to
to build their
the past.
in
staff,
who
resisted
own teams on
This became
a
did not want to force
A serious dilemma resulted
system occurred once Munson
of the
left
as
the
the and program
managers realized they could continue with previous practices unencumbered.
This breakdown,
managers such
Munson
it
seems, was the major source of the work flow problem that
as Atchley complained about.
recalled
the combination of political,
and technological hurdles SDC faced
in
organizational,
managerial,
trying to make the matrix system run
smoothly. Of equal importance to any of the other dimensions, he thought, were
the political and organizational issues, because some people were "dedicated to
seeing that [the factory]
control,
didn't work."
and programmers wanted
Program managers wanted complete
to "flow with
the job":
of the basic problems was, from my point of view, a political
problem. Why it didn't really become as successful as it could have
In our
was a lack of management commitment to make it work.
always
been
a
defined
has
right
there
of
kings
organization,
syndrome
where people want to own the resources that are doing their work.
We have a very strong heritage and management orientation and
obviously management support of projectized versus matrix kinds of
So there was a fair share of the population that was
organizations.
dedicated to seeing that it didn't work, because they wanted to have
control of their own resources, as opposed to having a matrix
One
50
SDC
Software Factory
organization that did the work for them. .Also, we were fighting
There were just a lot of professional people, the
social history.
engineers, that didn't like the concept because they wanted to flow
with the job, rather than work on pieces of the job.
.
The point that programmers probably found
particular types of applications was as
problem.
The accumulation
programmers more
efficient
of
much
experience
it
useful
to
specialize
in
a technological issue as a political
in
seems to make
areas
specific
when designing and coding
familiar
types
of
systems. This reality of software engineering encouraged both programmers and
program managers
initial
to
want people
rather than hand off
to "flow with the job"
designs, as Munson points out:
[The factory] really failed to take into [account] the fact that
experience in understanding the application you are working on is
almost as important as understanding the technology you're applying
to it... For instance, if you're working with a banking system,
understanding intuitively how a bank works is almost as important as
Or, say, with
understanding how to program computer systems.
programming a radar system, you just don't take any programmer and
say program a radar system; .there is no management or technical
substitute for your people understanding the problem. .This really
turns out to be at the lowest level... the guys that are making the
implicit and derived functional requirements implementation. The
intuitive understanding of the problem helps you in the production
process.
.
.
The preference
for
"projectizing"
forming separate projects as needed,
force
in a
in
rather
than
matrix
contrast to having
a
management--
permanent work
factory to do implementation and testing -- led to organizational and
cultural conflicts.
Neither program managers nor programmers ended up liking
the Software Factory.
programmers
Munson
to stay with their
felt this
difficulty also reflected the desire of
programs "from womb to tomb":
Another aspect of the problem was that.
51
.
.of
matrix
SDC
versus
Software Factory
.
There really was a very strong feeling on the part of
projectizing.
the technical people that they liked to work software problems womb
to tomb,' that they didn't like to just be responsible for the design
and pass it on, and so we were faced with two kinds of cultural
problems in that area. One was that the [managers] didn't like the
organizational concept anymore than the [programmers] did. But.
It's
People will start liking it if it's
looking back to the will again.
successful.
And they get bennies and stroking as a result of being
part of a successful organization. And so you begin to change their
Suppose it was still in practice
attitudes about that kind of thing.
today, ten years later, and it had been successful, the people would
love it, because people like being involved with successful things.
And this whole attitude about the womb to tomb would have changed
and they would have seen that different benefits come in the fact
that they could have grown with the organization into different roles
and responsibilities. But in the short term it was a very big start up
The fact that we had on one hand managers who were
problem.
fighting the matrix functional problem and we had people, technical
people in the organization that were fighting that problem.
So we
were kind of getting it from both sides.
.
Atchley admitted the matrix
program managers
activities.
burden
of
realized
.
system created considerable discord when
they were
no
longer
control
in
development
of
He added that people complained about the additional overhead
having
to
pay for two sets of management
For other managers,
and one outside.
however,
--
one inside the factory
was more
it
a
'turfdom"
struggle:
We
what happens is
didn't have the management tools in place
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
have any control over you. And if you overspend, what's he going to
He has to have the job done.
So there was not enough
do?
incentive on the part of the factory to produce at an economical cost
[These] were the complaints of the other managers. It was costing
there were some complaints about the fact that now
them money
they had two managers, that they had doubled the overhead
since
you had the management of the Software Factory but you still had
So there were some complaints
the management of the program.
.
.
.
.
.
.
.
.
.
.
about that.
.
.
.
managers felt they were losing their "turfdom" ... we
took a lot of people who'd been program managers and we
consolidated into three areas. That left some men and women at that
same level who no longer had a direct influence, and they became
Some
of the
52
SDC
Software Factory
'plans and programs' people. .they were in the situation of getting
their projects done by the Software Factory.
That left some of
They wanted their hands on that. They wanted
those people uneasy.
So there was a lot of
to be able to touch their programmer.
resistance from program management to the idea.
There still is.'°
.
.
SDC had
.
earlier tried
and
failed
maximize scarce personnel resources.
all
a
to
introduce
SAGE began
a
matrix organization to
with a project system, where
the necessary personnel, from different functions, were brought together
made responsible
single group and
however,
SDC management
engineering,
to a single
program manager.
In
in
1958,
created functional offices for personnel, production,
and programming,
while
still
maintaining
program management
offices responsible for specific projects but sharing responsibility for functional
activities
such as engineering and programming.
work out.
After conflicts erupted between the program managers and line
managers over budgets,
management decided
managers.
It
to
schedules,
and worker performance,
reorganize and return
full
in
1959
top
authority to the program
''
may be no more than
problem had surfaced
of this
But the matrix format did not
in
historical irony or coincidence that this type of
SDC once
history or remembered
before.
it
But had factory planners been aware
more clearly, they might have anticipated
resistance and better prepared employees -- programmers and program managers
-- for the
changes and cooperation required to make the matrix organization
work.
Cultural and Organizational
Change
Whatever technological hurdles they faced, Deaver believed that only
"drastic change
in
a
culture and philosophy" would have made certain aspects of
the factory organization work as intended.
53
This was no doubt true with regard
SDC
Software Factory
to matrix versus project
management.
Another example related
to reusability.
Programmers required some retraining or rethinking about module design
write reusable code and to reuse
it
consistently; the additional effort required
meant that managers should probably encourage programmers
reuse code
they want this to happen more than
if
to
it
in
some way
would by chance
to
There
is
the additional issue of integrating someone else's previously-written and perhaps
more lengthy code
into a
new program, rather than write new, probably shorter
and more "elegant" code for the specific application
Deaver
was "more
recalls resistance to
borrowing other people's code, and claims
problem of aesthetics than performance.
a
to write their
built with reused
was no noticeable tradeoff
habits
and
managers
this
Programmers preferred
"
own, because this usually made the program "tighter" (performed
the desired function with fewer lines of code).
programs
question.
in
sense
in
the
of
terms of operation, however,
In
code usually ran fine, according to Deaver, so there
in
product performance.
aesthetics
Software
tended
Factory
to
took
Nonetheless, programmers'
discourage
no
reusability,
measures
to
and
overcome
the
this
reluctance. °
Another seemingly cultural issue was use of the word
seemed
to
like
it,
and after 1978 SDC stopped using
word became an "anathema"
to
had
started
their
Atchley claims the
managers and programmers
explains this was because software programmers
generally
it.
"factory." No one
careers
as
alike.
^
Munson
(and project managers, who
programmers)
preferred
to
think of
themselves as professionals, not as factory workers:
Again, it has to do with the culture, the image.
These people that
are computer programmers think they are professionals and the
concept that they'd be associated with a factory kind of grated them
You know, they tended to
instead of seeing it as a great sales tool.
take it as being a slur on their professionalism and that's why it
always thought the factory was a good
really became an anathema...
I
54
SDC
Software Factory
metaphor for what we were trying to do.
It.
They made
a
lot
of fun out of
A
lot of
people didn't like
it.
Munson's comment that he viewed the Software Factory as
suggests
"sales tool"
a
he may have had some ambivalence about the concept.
referred to the term "factory" as a "gimmick," as quoted below.
hand, "Software Factory" was not
the notion of
a disciplined,
a hollow
phrase
to
He
also
On the other
Munson, but represented
engineering-like approach to software development:
[It was] a gimmick, because it has a connotation to the general
population of organized, methodical, chunk it out, make schedules, do
on time.
have always thought, and we of course have a
it
copyright on the expression Software Factory, that was a very
valuable concept to the world that is afraid of software.
That it
would tend to give it a more engineering concept. °^
I
Yet
recollections
of
the
management commitment
to
the concept
himself have the authority to
factory
consistently
in
critical
point
areas.
to
of
Munson did not
make program managers use the
facility or to
insure continued development of the factory tools and methods.
difficult to
lack
a
But
it
is
understand why Mueller, the head of the company and originator
of
the factory concept, did not give
it
more of
a
chance
—
such as by requiring
that program managers use rather than ignore the facility, providing corporate
funds to keep the staff on the payroll, or even getting work for the
from other divisions or other customers
Nor did
staff
if
change aspects
offices
factory,
even though the matrix system,
to
necessary.
managers require programmers or
program
of
their
line
behavior that
managers
in
the
undermined the
or the strategy of
represented significant departures from previous practices.
that managers
facility
reusing code,
Atchley admitted
never required programmers to reuse code from the program
55
SDC
Software Factory
And both he and Munson admitted
library or to write reusable modules.
did
not only
staff
management
fail
require program managers
to
to
that,
use the
they failed to require the line managers to keep consistent track of
factory,
performance data.
managers
to
Because their superiors did not really require program
change, the factory strategy and structure could be avoided.
managers did not
really require
programmers
because
line
factory
system never had the impact or continuity
it
to
And
change, the new
might have enjoyed.
Atchley even suggests that many programmers were not fully aware of what the
factory was or was supposed to do:
They
didn't even know it happened.
It was a term used and a way
doing work, but as far as most of the programmers were
concerned, life went on as usual.
don't think there was any great
culture shock or resistance to it.
They knew the term, they knew
they had been gathered from the various four corners of the company
and put together, but they didn't consider themselves in a factory.
There were lots of cartoons on the wall about the factory and all
don't think the programmers
these kinds of things, but truthfully,
considered themselves factory workers."'
of
I
I
MANAGERS' ASSESSMENTS AND THE JAPANESE CHALLENGE
Atchley's assessment of the factory experiment was generally positive.
doubted that the factory reduced costs but could not
lack
of
detailed
experienced
data)
if
were due
to
the improvements
the factory
in
tell
(probably due
productivity and quality
system or
to
other factors,
hand,
he
believed
engineers of the product
life
the
factory
increased
awareness
among
to a
SDC
such
accumulated experience or just better techniques introduced over time.
other
He
as
On the
software
cycle, and greatly improved quality through a
more
structured approach to design and more formalized testing procedures:
56
SDC
Software Factory
think that, while we may not be organized the way we were, our
people are more aware of the software life cycle now.
seriously
doubt that it [the factory] reduced cost.
Were the people more
efficient?
It's hard to say they were more efficient because of the
factory or that they became more efficient because we became more
presume there was a fallout there on efficiency and
efficient.
think the structured approach helped quality
productivity.
think the fact that we became very formal with the
immensely.
independent test organization improved the quality of the product we
Whether that was the Software Factory or not,
delivered.
don't
I
I
I
I
I
I
know.
Atchley also
felt
the factory concept should have worked and had real
potential for improving reusability
SDC
and productivity.
He regrets, however, that
has not done much with the idea beyond the standardization of procedures
and some centralization of development
at Paoli.
Atchley concluded they were
now "dragging" behind the most advanced ideas coming out
of universities,
rather than being
as the Software-
in
the "forefront" of implementing them,
Factory once was:
good concept.
think discipline can be applied to the
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
If we'd kept
ideas came out of the schools and papers were written.
think we would have been able
the factory concept more prominent,
As it is now, there's a lag.
to put more of those ideas in sooner.
Instead of being at the forefront, we're kind of dragging."^
I
think
it's
software
a
I
development process.
I
I
Munson offered another thoughtful assessment
of the Software
Factory.
While acknowledging that the set of tools was incomplete and those developed
for the factory were nearly
-- a
all
replaced over time, he insisted this was positive
type of change that represented "growth" and "evolution":
57
SDC
Software Factory
[I]f you thought about it in the context of the factory, that's called
growth -- the evolution, the fact that we are not using same the
PDL today as we did ten years ago. We never expected to. We
We were building
weren t building something to last 100 years.
something to grow and the fact that we are moving to a new ARGUS
system, that was the way the factory was going to grow. .it shouldn t
be an indictment of the factory, that was what we were trying to do.
We just wished we could have done it in the context of the factory.
.
A major achievement,
in
Munson's view, was the increased attention the
factory brought to problems and needs of the software development business.
While they were not completely successful
not successful, he insisted.
in
the effort, "pioneers
Instead, they are often "impatient"
to achieve,
and while sometimes receiving "arrows
groundwork
for future development.
Factory did
--
"frontier"
in
it
This, he feels,
may not have done
as well as
it
in
what they try
the back," they lay the
is
what the SDC Software
could liave, but
was
it
at
the
identifying and tackling key problems:
The factory
identified software as a major
visibility for software, got it up
high
in
generally are
"
management would see
We got
it.
a
management
issue.
got
It
to the top level where
lot of synergy out of the
and emphasis... but we were the
pioneers in this, and you know what happens to pioneers. They get
arrows in the back, and eventually some settlers come along later and
build on those ideas that the pioneers had. .We are always impatient.
And was impatient because knew it was the right thing to do and
People are moving
people still think it's the right thing to do.
It was too soon... We
think it was just a little early.
towards it.
may have suffered the fate of General Custer but we were out there
factory,
getting people together,
.
I
I
I
in
the frontier.
Nor did Munson see himself
manage
delicate tradeoffs between,
to raising
to
"noble experiment,
first,
uncontrolled process."
'
trying to
say, maximizing cost reduction as
product functionality or customer satisfaction.
make "better" products;
of an
as involved in a
Munson
claims,
he
felt
opposed
There was no attempt
he had "to get control
Better would come later:
58
SDC Software
Factory
My
first goal was to get control of an uncontrolled process.
In my
mind software development, in general, was out of control.
It was
At that point and time, the
not predictable, it was not manageable.
two terms, software engineering and computer science, were
There was no engineering in software and
contradictions in terms.
considered it survival and more than a
no science in computers.
We were just really, really trying to get some
noble experiment.
terrible problems under control. And we thought this would be a way
to approach it... Some of those other things were second order. We
If we could just
were just trying to do it good. Better was later.
get it controlled and bring in a project on time with some
relationship to the cost we had bid for the job, we would have been
satisfied for that.
At that point, really, it wasn't a productivity
Once we had
Issue, as such, although we saw it as leading to that.
it under control, then we could get to the issue of how can we make
garbage for whatever price
But once it's out of control.
it cheaper.
And that was the situation.
is still garbage.
.
.
I
.
.
With regard to Japanese efforts at developing software factories, Munson
asserts
he became aware of these attempts during the
1980s through Japanese participation
engineering.
others.
On
Munson
a visit to
Japan
in
in
late
1970s and early
international conferences on software
1981,
he saw the Toshiba
facility,
also had to contend with frequent visitors from
wanted to learn about SDC's Software Factory, although
Japanese were more
interested
in
superficial
Japan who
at the time
questions
like
among
he
the
felt
size
the
of
programmers' work spaces, than the issues underlying the factory organization:
Hitachi came over to visit us in Santa
It must have been 1980-81.
Monica to find out about the Software Factory. They were more
interested in measuring the size of our programmers' offices and
looking at whether they had terminals or not, than they were in
what we were trying to accomplish. And they did, they had tape
measures, they went into offices and measured all the offices. It was
strange. .. [W]e had a delegation in from one of the Japan companies
about every 3 months, it seemed like, wanting to hear what we had
to say on the subject.
After reviewing more detailed accounts of Japanese efforts
Munson concluded that these have been very much along the same
59
SDC
in
software,
lines as
what
Software Factory
he wanted to do at SDC,
and
resistance.
cultural
less
with the advantage of more homogeneous hardware
He believed that U.S. companies maintained
present lead over the Japanese counterparts
the Japanese
felt
were sure
to
in
up,
catch
software
as
they
skills,
a
although he also
have done with
other
technologies, particularly because their software factories were not dependent
on projects to exist.
They were permanent organizations:
think [the Japanese] are doing very much what we tried to do.
think they have a little advantage, and that's the homogenous
could make homogenous equipment a spectacular
equipment.
think
think we were trying to fight too many problems all at
success.
the same time -- personnel problems, social problems, cultural
problems, customer problems, work-flow problems. With the Japanese
They are not on contracts.
factories, most of them are on budgets.
And that makes a huge difference, because they have continuity, year
More power to them.
[But] we are still sufficiently
to year to year.
ahead of the Japanese in software and that is because of exactly the
reasons Why a software factory is more possible in Japan than here.
really think
We allow more creativity, make more of the advances.
that it is going to take the Japanese a while yet to catch up to us.
But they will.
They will, but they culturally think differently
towards problems than we do. And
think for software, in this time,
our culture is better than theirs, but they can overcome that...
I
I
I
I
I
.
.
I
I
Withal,
there was
no question
factory effort had failed.
well
as
also
feels
it
To him,
in
it
Munson's mind whether or not SDC's
did not
fail;
it
simply did not perform as
might have with more sustained management commitment.
the effort was
"needlessly abandoned," though
Munson
he admits that he
probably did not do what he should have to convince managers and programmers
to accept the
to
make
it
new system.
Instead, he relied too heavily on strong-arm tactics
work:
We
didn't do as well as we could.
But, we did
anticipate many of the developments that followed and which people
.SDC may have needlessly abandoned
were able to use successfully.
[P]eople like belonging to a successful organization.
it.
We were
[W]e didn't
fail.
.
.
.
.
60
SDC Software
Factory
being successful and we could have carried that momentum, and it
would have solved a lot of these other problems...! tend to be a
typical impatient American as opposed to the Japanese that can look
get a little impatient with some of those
at 20-year plans.
concepts that say you have to change culture. Wasn't it Nixon who's
quoted as saying, "When you got them by the balls, their hearts and
minds will follow?" Maybe that was more my philosophy .°^
I
SUMMARY
SDC
clearly attempted to
move beyond
a
craft-type approach to
a
factory
organization that produced semi-customized or fully customized products
more systematic manner, using standardized procedures and
or designs
if
possible,
as well
as
design and program construction.
tools, reusable
in
a
code
more division of labor between high-level
SDC
failed to solve the five major
problems
which initiated the effort, especially managing performance requirements, tools
support, and reusability better, as well as sustaining the factory discipline.
A
comparison of SDC's Software Factory to the ten elements earlier introduced as
fundamental to successful software factory efforts reinforces the conclusion that
SDC managers
did
factory approach fully.
of
themselves
not allow
what constituted
a
They
also
factory
Perhaps for these reasons,
think
through the
much more
limited vision
enough time
seem to have had
a
to
approach than their counterparts
SDC managers
in
Japan.
did not allocate the time or resources,
including preparation of employees, that would have been needed to make the
factory work, given the technological and organizational obstacles
major issues involved
in
the factory effort are summarized
61
in
SDC
it
faced.
The
Table 3.2.
Software Factory
Table 3.2:
SDC SOFTWARE FACTORY SUMMARY
FACTORY CONCEPT
IMPLEMENTATION
Strategic Integration
Some
planning
in
stage;
almost
implementation, particularly
management, or education
none
work
in
flow
Product- Process Focus
Division focused on real-time programming
applications, mainly defense-related, but wide
variety in types and object computers
Scale and Scope
Factory of 200 programmers was small; other
programming operations dispersed, at SDc
locations
and customer
sites
Improvement, Not Innovation
SDC emphasized product innovations and
customized systems; not traditionally process
and cost oriented, thus some factory goals
were incongruent with competitive strategy
and corporate culture
Process Analysis/Control
No systematic analysis, though factory
methodology imposed some standardized
controls while
Quality Analysis/Control
in
use
No systematic analysis, though factory
methodology imposed some standardized
controls while
in
use
Central Tool Support
The factory began
Training
No
as tool R&D; Factory
Support System provided numerous tools,
though portability was a major problem and
the development effort was not sustained
formal
managers,
training,
though
of
the
programmers or
standardized
methodology was apparently followed.
Lack
understanding or appreciation for the
factory concept contributed to matrix
management problems, as project managers
disliked giving up control of program
of
contruction to the factory
Reusability
No
systematic
effort;
reuse
achieved
was
accidental
Automated Customization
Capability not achieved, except that some
mechanized or automated project-management
and testing tools aided development
62
SDC
Software Factory
REFERENCES
would like to thank David Finnell for his contributions to ideas expressed
chapter through research done under my direction for a structured
master's thesis at the M.I.T. Sloan School of Management, titled "Application of
the Factory Model to Large-Scale Software Engineering," May 1987. The thesis
work included the Interview with Ronald Atchley cited in the text.
1.
I
this
in
2.
Burroughs Corporation, Annual Report
,
1984, p.
15.
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
3.
course Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software
Engineering (Reading, MA, Addison-Wesley, 1975). Two other collections on key
articles dating back to the early 1960s are Edward Yourdon, ed.. Classics in
Software Engineering (New York, Yourdon Press, 1979) and Writings of the
Revolution (New York, Yourdon Press, 1982).
SDC's official company history, written by an SDC employee, details the
development of the firm from 1956 through 1981. See Claude Baum, The System
The Story of SDC Santa Monica, Cal., System Development
Builders:
4.
.
Corporation, 1981.
5.
Baum, pp.
6.
Baum, pp. 53-54.
7.
Baum,
8.
Baum, pp. 158-159, 163.
9.
Baum,
p.
p.
26, 61.
6.
161.
10.
Baum,
11.
Baum, pp. 166-167, 170.
12.
Baum, pp. 190-194, 285.
13.
Baum,
14.
Baum, pp. 219-220.
15.
Baum,
p.
p.
p.
168.
246.
220.
and Harvey Bratman and Terry Court (System Development
Software Factory," Computer May 1975, pp. 28-37.
"The
Corporation),
16.
Baum,
p. 246;
.
17.
Baum,
18.
Interview with John B. Munson, 4 and 5 October 1987.
p.
221.
63
SDC
Software Factory
Harvey Bratman and Terry Court (System Development Corporation), "The
Computer May 1975, pp 28-37. This article describes the
factory tool set. A second article repeats the tool discussion but also describes
the development of standards and procedures, as well as the division of labor
between program offices and the central factory facility. See H. Bratman and
19.
Software Factory,
"
.
Standards, Piocedures, and
T. Court, "Elements of the Software Factory:
Tools," in Infotech International Ltd
Software Engineering Techniques
(Berkshire, England:
Infotech International Ltd., 1977), pp. 117-143.
,
own experiences, Bratman and Court cited a 1974 study
success, to find such a correlation. The citation
attempted,
without
which had
of Developing Large Scale Software," IEEE
"The
Cost
Wolverton,
is to R.W.
Vol.
C-23, No. 6, June 1974, pp. 615-635.
Transactions on Computers
20.
In
addition to their
,
21.
Bratman and Court (1975),
22.
Bratman and Court (1975), pp. 28-29.
23.
Bratman and Court (1975),
p.
36.
24.
Bratman and Court (1977),
p.
119.
25.
Munson interview.
26.
Munson interview.
27.
Bratman and Court (1977),
p.
117.
28.
Bratman and Court (1977),
p.
120.
29.
Baum,
30.
Bratman and Court (1977),
p.
121.
31
Munson interview.
.
32.
p.
p.
29.
222.
This discussion of the
SDM procedures and
quotations are from Bratman and
Court (1977), pp. 121-126.
33.
Munson interview.
34.
Baum, pp. 220-221.
35.
Baum,
36.
Interview with Ronald Atchley, 3/27/87 and 4/23/87.
37.
Bratman and Court (1977),
p.
127.
38.
Bratman and Court (1977),
p.
127.
39.
Bratman and Court (1977),
p.
128.
p.
223.
64
SDC Software
Factory
3-//'>
This section is based on nearly identical descriptions of the tool set in
Bratman and Court (1975), pp. 30-36; and Bratman and Court (1977), pp. 128-
40.
137.
41.
In
"Elements of the Software Factory", this tool
is
called
Program Analysis
and Test Certification Processor.
42.
Atchley interview.
43.
Bratman and Court (1975),
44.
Atchley interview.
45.
Munson interview; Baum,
46.
Baum,
47.
Munson interview.
48.
Atchley interview.
49.
p.
p. 36;
p.
and Bratman and Court (1977),
p.
143.
224.
224.
Interview with Clarence Starkey, 10/3/86.
50.
Atchley interview.
51.
Interviews with Atchley and Munson.
52.
Baum,
53.
Munson interview and Baum,
54.
Munson interview.
55.
Munson interview.
56.
Atchley interview.
57.
Munson interview.
58.
Munson interview.
59.
Munson interview.
60.
Interview with David Deaver, 10/3/1986.
61.
Munson interview.
62.
Atchley interview.
63.
Atchley interview.
64.
Atchley interview.
p.
222.
p.
224.
See also data on reuse rates reported
in
Chapters One
and Two.
65
SDC
Software Factory
65.
Atchley interview.
66.
Munson interview.
67.
Munson interview
68.
Munson interview.
69
Bratman and Court (1977),
70.
Munson interview.
71.
Atchley interview.
72.
Munson interview.
73.
Munson interview
74.
Munson interview
75.
Munson interview.
76.
Atchley interview.
77.
Baum,
78.
Deaver interview.
79.
Atchley interview.
80.
Munson interview.
81
Atchley interview.
.
p.
p.
137.
43.
82.
Atchley interview.
83
Munson interview.
:-07;
66
SDC
Software Factory
Date Due
=\0B0
0072& &24 1