-«r
J
HD 28
.M414
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
PIONEERING A "FACTORY" STRATEGY AND
HITACHI:
STRUCTURE FOR LARGE-SCALE SOFTWARE DEVELOPMENT
Michael A. Cusumano
September 27, 1987
WP#I886-87 (Revised)
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
PIONEERING A "FACTORY" STRATEGY AND
HITACHI:
STRUCTURE FOR LARGE-SCALE SOFTWARE DEVELOPMENT
Michael
September 27,
1987
A.
Cusumano
WP#1886-87 (Revised)
JfPT LIBRARIES
RECEIVED
Michael A. Cusumano
MIT Sloan School of Management
'^/ll/^l
Software Project Paper #3
Working Paper #1886-87
HITACHI: PIONEERING A "FACTORY" STRATEGY AND STRUCTURE
FOR LARGE-SCALE SOFTWARE DEVELOPMENT
INTRODUCTION
This paper
or
companies
not
such
corresponds
of
and
to
job shops,
flexibility
larger study examining the question of whether
a
choosing
manage
to
well
as
in
product
of
and
mixes
and
technology
and Japan
process
and
policy
like;
criteria
a
survey
of
determine where firms stand
to
what
defining
software
38
in
a
relation to
followed
at
firms
identified
as
being
close
to
the
'
.
approaches,
is
clearly
the U.S. and Japan.
a
structures
more effectively, even with
(3)
(2)
observable
(1)
in
There appears
This spectrum, including
the
to
sample
of
software
be nothing inherent
in
technology that prevents some firms from creating strategies
organizational
software.
that
The research project
technologies.
There are several interrelated conclusions:
software as
approaches
and detailed case studies examining the technology and policy
implementation
facilities in
strategic
batch organizations, and factories exhibiting various degrees
the U.S.
these criteria;
"factory"
range of
a
activity
spectrum usually associated with "hard" manufacturing,
proposal
factory model
engineering
technological
as
environment for software might look
facilities
complex
a
development with
software
organizational
the
in
the
includes
factory
are
large-scale
as
considerations
i.e.
part of
is
The
a
to
manage product and process development
relatively
new and complex technology such
as
basic technological infrastructures to aid software process
management are
Japanese firms
But,
(4)
Hitachi and
by
--
"flexible
standardized
comp^onents
factory"
type
(modules
paper analyzes what
software factory
and
established
of
and
competitors
focused
strategies
code)
of
then
on
in
reusing
customizing
process.
programming)
end
Hitachi
was
a
is
the
significant
for
performing both
facility
the
of
software
first
and Hitachi has made available extensive
documentation
Two,
probably the most difficult aspect
Software Works (originally
its
the world,
technical
is
implementation
the
applications
in
systems.
--
One,
two reasons:
and
US.
.
This
systems
by the NEC group and Toshiba, and followed
led
are significantly ahead of most
--
Fujitsu
implementing
products
between Japanese and U.S. firms.
not significantly different
Hitachi
for
has
this
facility's
extended
its
technological
factory
historical
and
approach
factory
policy
both
to
applications and systems software development.
I.
THE STRATEGIC AND STRUCTURAL SETTI NG
HITACHI:
Corpo rate Organizat io n and Products
originated
Hitachi
company
Tokyo.
in
the town
In
neighborhood
1986
of
it
$20
1908 as
in
of
Hitachi,
had
the machinery
Japan,
approximately
billion
dollars.
a
80,000
Hitachi
communications and electronics equipment,
(36% of fiscal
(21%),
1985 sales),
home appliances
couple
s
repair
section
hours
by train
employees
major
of
area
and
of
a
mining
north
of
in
the
business
was
sales
including computers and software
although the company also sold heavy machinery
(24%),
industrial
exchange equipment and other products
machinery
(10%).
In
(9%),
and telephone
computer sales among
Japanese companies during 1985, Hitachi ranked fourth, behind Fujitsu,
Japan, and NEC, but was traditionally the market leader
and second
IBM
to
most
For
belonged to
history,
its
Computers,
has
organization
Hitachi's
the company operated
groups:
7
large mainframes
in
very-large mainframes.
in
which
of
factories,
of
IBM
28
Electronic
domestically
centered
around
These
1986.
in
Consumer Products,
Devices,
Components and Equipment, Industrial Processes, Power Generation
Industrial
Group headquarters retained
and Transmission, and International Operations.
responsibility
for
sales,
but factories
engineering and manufacturing.
have been
responsible
for
product
Factories also operate as independent profit
management based on 6-month budgets
centers,
with
factory.
Plant managers are thus responsible for engineering and production
costs,
the
financial
setting
production
of
company policy has
required
amounts,
factory
and any
managers
to
for
each
expenses;
related
and
standardized
institute
controls and procedures for budgets as well as engineering and manufacturing
management.
software.
There have been
This
is
what
led
no
to
exceptions,
the
birth
of
not
the
even
the
in
world's
first
case
of
software
factory.
The Computer Group
Computer exports for Hitachi have been
to domestic
sales
specifically with
to be of
to
(about 17%
IBM models
unique designs.
in
1985).^
as well
relatively
small
path
than
IBM
to
comparison
Mainframes are designed to compete
as to be fully compatible,
For example, the AS/9000,
and appeared
introduced around 1982
compete with IBM's 3081 model, used denser circuitry and
flow
in
a
shorter data-
provide considerably more computing power for the
dollar
IBM
speeds equivalent to the
and
at
when compared
levels
computers introduced to compete with
Hitachi
new 3090 Sierra series, the AS/XL 60 and
s
more expandable and more
"a
expanded performance
with
IBM system. "°
similar
a
according to Datamation,
mainframe,
cost-effective
to
also,
v\as
It
IBM machines with
80,
also achieved computing
the
half
number
processors
of
lower price.
a
The 19S2 incident
which
in
engineers were caught by the FBI
Hitachi
attempting to buy information on the 3081 operating system, particularly new
IBM had decided
features that
that
to
help
This
has
Hitachi
actively
sought
hardware and
its
process
of
also
is
information
success
technical
development,
the
in
in
microcode ("firmware),
on
information
software engineers
gathering
have also aided the performance
It
imbed
to
developed
--
two
computers
helped
formally
engineering"
"reverse
may
underlying
that
hardware and software
long
a
is
Hitachis
history
of
apparent
computer
in
using parametrons
(a
used
primarily
business computer
a
Ministry
of
Japan
in
in
1959.
International
in
1957,
during the
The model
Trade
and then
1950s),
for
and
a
machine was
this
Industry
research
the Electrotechnical Laboratory (ETL), and largely completed during
institute,
1956
at
products.
compatible
Hitachi engineers began experimenting with this technology
device
transistorized
design
even
the mid-1950s and completed their first model
solid-state
IBM machines and software
Hitachi mainframes and software.
of
however,
case,
or
suggests
in
years
the
the United States.
transfer
in
before
1962,
this
technology
commercial
introduction
of
transistorized
The main ETL designer, TaUahashi Sigeru,
to
Hitachi
and
moved
to
the
where he headed hardware product development
company
until
1980.^
Along with in-house research and product development, Hitachi also benefited
from
it
RCA between
licensing agreement with
a
manufactured RCA-designed computers, as
resale
under the Hitachi
The production
label
of
in
computer products
RCA
failed
to
before
along
1961,
for
purchasing
direct
as
well
as
with
the
independent
dual strategy within Hitachi:
a
to
introduce
machines
design
new products
competitive
and then withdrew from computers
expertise
software,
technology
of
This two-fold approach turned out to be extremely important:
from abroad.
When
new technology
of
RCA
sold
as
well
which
tlnrougln
Japan.
arrangement with RCA, reflected
development
and 1970,
1961
that
370 and subsequent mainframes.
the
1960s
late
had sufficient internal
Hitachi
1970,
in
in
would eventually compete with
the
IBM
Equally important, Hitachi engineers had an
opportunity to cultivate independent
and develop
skills
a
distinctive, factory-
centered approach to software development.'^
computer group
Hitachi's
in
mid-1980s
the
consisted
which started with 348 employees
in
1969,
separated into two sites during 1985.
systems
for
systems
software
mainframes,
(such
It
grew
language
nearly 3000 before being
has continued to produce operating
mini-computers,
as
to
and
office
processors);
hundred thousand.
scale customized
control
software.
as well
as
corporate
producing
applications
computers;
and
programs. The smallest programs were several thousand
largest several
on-line
lines of
related
data-base
code and the
Omori Software Works produces large-
programs such
as
real-time banking or factory
Research and development on
new hardware technologies
software development tools and design concepts took place
^^
In
addition,
computer-related
products
facilities
.
main
six
The Software Works,
two for software and four for hardware.
facilities,
of
Hitachi
and
had
services,
numerous
including
in
two
subsidiaries
23
software
companies 13
H ITAC H
I
COMPUTER G RO UP. CA.
1986
LLNE FACILITY
Hardware
Kanagavsa Works
EMPL OYEES
PROD UCTS
2,800
Mainframe Computers
Odawara Works
2,400
Peripherals
Asahi Works
1,100
Smail-Scale Computers
80
Semiconductor Devices
Device Development
Center
Software
Software Works
1,400
Systems Software
Omori Software Works
1,500
Applications Software
1,200
Basic Research
C O R P O ATE RDD
Central Research Labs
Systems Development
Laboratory
Systems and Applications
Software Technology
350
Corporate Prog ram s for Eng neering an d Manu f actu ri ng Improvement
i
The software factories
took
part
and improving various aspects
analyzing
in
of
all
company-wide
engineering
refinement
improvement
and
of
the
factory
concept
procedures) for software, and of engineering performance
1968
has
focus
of
specific
at
and manufacturing
Several corporate programs appear to have led to an increasing
operations.
For
efforts
example,
been
this
the
has
a
(technology
in
and
this area.
company-wide movement among Hitachi factories since
"Management
Improvement"
(Ml)
program.
The major
been to promote the establishment and implementation
standardization,
"zero
defect,"
and
of
p roductivity- improvement
objectives. ^
during 1969-1971, this movement took
At the Software Works,
the form of setting standards for design, programming, and testing activities,
introducing
launching
a
and
system
zero-defect
a
program,
As
next step,
a
in
1973 managers asked
all
planning personnel
submit suggestions on how to improve productivity; this resulted
some
proposals,
and
study of how to reduce personnel costs and increase programmer
a
performance.
to
document control
which
of
were adopted
quickly
--
such
as
1437
in
structured
programming techniques and better debugging methods.
under the Management
Also
1970s, the Software
through
Promotion Center
wide focus
ways
in
the
in
production;
factory
staff
"*
program,
during
of design productivity,
the
later
reliability,
Management formally organized these
structure,
such
as
Rationalization
a
1975 (headed by the factory manager).'"
The company-
recent years has centered on three specific areas and potential
integrate
to
Works launched studies
and market share.
profit generation,
efforts
Improvement
Hitachi
and
improve
productivity
in
and
product engineering
has equally applied the concepts and recommendations
hardware and software
in
facilities:
Area
Design technology
Main Objective
Shorter times
Solutions
CAD
Standardization
Production engineering
Labor reduction
Automation
Process improvement
Control technology
Less work-in-process
Inventory control
Another example
company,
picking
Hitachi
out
has
product-
is
quality
followed
or
a
assurance.
practice called
system-design
errors,
Since
the
founding
"gleaning," which
analyzing
them,
of
the
involves
and
then
formally recommending solutions and making reports to colleagues
have case reports once
with
1977,
in
procedures
analysis
the
particular
would
that
at
the division level
The Software Works adopted
once every other month.
approximately
practice
month; there are also reports
a
Factories
objective
reduce the
developing
of
recurrence of
this
and
design
system problems
such as not meeting user specifications or designing
identified by customers,
programs that were not "user friendly."'"
IL
THE FACTORY MODEL
SO FTWARE STR ATEGY:
Product Proliferation and Proqra mme r Shortages
The
drums
well
as
simple
Hitachi
first
for main
computers
input/output
Thus,
programs
the
With
it
became
FORTRAN and
to write
1963-1965,
late
and
1950s
early
"monitor"'
a
and
few
a
inclusion
of
core
possible
to
use
subroutines
higher-level
more sophisticated programs.
modern operating system
knock-down
RCA product
kits;
for
required
knowledge, except to be able
An in-house
in
such
languages
Yet the hardware
first
computer was
Hitachi
a
little
to service the
product
in
1965.'^
a
as
still
program
Fortran
But this was
engineering
or
provided Hitachi engineers with
both hardware and software development,
8
software
machine. ^^
project, on the other hand,
extensive experience
scientific
for
which Hitachi produced from imported
(model 401),
Hitachi
as
memory and card readers during
system introduced with the HITAC 4010
actually an
used
they did not require software except for
had no interrupt features, so control programs were small. The
resembling
1960s
memory, and paper tape for entering programs and data
receiving output.
calculations.
the
of
as
well
as
began to strain engineering resources.
in
the early 19GOs,
Hitachi's Central
Research Laboratory took on contracts with Tokyo University, the Japanese
Agency,
Meteorological
laboratory
build
to
dubbed the HITAC
own use
and
very-large
a
produce an
operating
scale
and
Telegraph
Telephone's
computer capable
under the direction
system
("monitor")
of
that
unit for
had
to
would
to
compiler
experience developing an
previous
parametron
Hitachi's
for
computers;
assigned to work on software for the 5020.
of
two sources of computer expertise
the
Totsuka Works,
led the
in
its
Shimada Shozo, set out
the
allow
perform input, output, and computation functions simultaneously.
engineers
main
sharing,
time
of
The Central Laboratory completed one
5020.
1964 and then,
in
Nippon
Laboratory
FORTRAN
assembler and
between
and
20
5020
were
30
The Central Laboratory was one
Hitachi
at
the time;
the other was
produced telecommunications equipment and had
which
company's entrance into computers during the 1950s.
^'
Shimada's major source of ideas for the operating system software was
MIT,
where he and several other Hitachi engineers visited
introduction of
a
Tokyo University professor
engineering department.
level
a
Research
system
Center.
made our mouths water."
Laboratory,
his
he
next project,
The
They finished
the
the head of MIT's electrical
to
their
GE mainframe. Shimada received
a
own
copy
which discussed several new approaches and ideas such as 2-
addresses and virtual memory.
"actually
1965 on
MIT researchers were then developing
time-sharing system, Multics, using
of the manual,
in
In
As soon as he returned
made the development
in
cooperation
first delivery of the 5020
a
Shimada's words, the Multics manual
Japanese version
of
Multics
the Central
comparable operating
a
Tokyo University's Computing
with
was
of
to
in
in
1965,
1968,
to
a
Tokyo University
.
'^^
couple years before
The 5020 was
short-handed
software
8000 family was
incentive
required
library.
were
at
in
first
at
RCA
use the
contrast,
on
a
on
faster
a
and
a
Designing
processing
Hitachi.
to
Laboratory,
and
Hitachi
Business
an
effective
exacerbated
the
Both
for
of
system,
the
disc
strain
provided
also
adequate
major
a
for
program
system
software.
TDOS, but
this
While
RCA
Japanese customers
disc system,
a
functions
all
system.
drive
disc
start
to
RCA's TDOS around
modifying
Electronics
operating
with
system
subsidiary,
assistance
from
Hitachi
TDOS and DOS
volume
resources
in
s
Research
Central
two subsidiaries (Hitachi Electronics Service
(The groups
from
and
Hitachi
a
Software
and
Electronics
Engineering,
large-scale
10
Yoshizawa
subcontractor,
provided the basic structure
on-line
on-line
of
found 80 engineers
Sakata Kazuyuki,
Engineering),
Hitachi
capable
software-engineering
on
the project,
the Totsuka Works,
Machines.
greater
v,ss
mechanism
Yoshizawa remained together and formed the basis
software
(which
new "disc operating system," DOS.^^
The manager
work on
and
the
series
operating system,
larger
prompting Hitachi
this,
1966 and create
Spectra
system
1967-1969,
major feature of the IBM 360 was that
hesitated over whether or not to develop
insisted
during
The 8000
developing
not
developing
to
two magnetic-tape stations for compilers and the program
least
available
to
RCA
the
of
strategy
RCA was
priority
Introduced
IBM 360).
formal
a
because
decided
the
with
create
to
development,
Hitachi
Japanese version
a
compatible
partially
series. ^4
HITAC 8000
and the project team became
businesses
for
management gave
Hitachi
as
the
for
suited
not
of
Engineering
the company's
established
of
batch
in
and
largest
1969.)
EDOS, which allowed
processing
and
was
completed
in
1969;
became the foundation for Hitachi's current operating
this
system for large-scale computers.
another
Yet
software
operating system for
Telephone (NT&T)
8700/8800 within
started
1968
in
Software Works
this
project,
well
as
in
NT&T
Development work
large-scale
The
performance goals
batch
first
processing,
commercial
project
provided
hardware design,
engineering.
and was
switch
to
Hitachi
Furthermore,
its
with
not
software
the
for
that resulted from
the 8700
logic
in
and on-line
1972-1973,
in
The computer
powerful
experience
and
a
Hitachi
series,
Nonetheless,
IBM-compatible
software
large-scale
successfully targeted
which
in
short
fell
370
the
as
development.
chips,
IBM-compatible machines,
M-series,
came
deliveries
as
extensive
integrated-circuit
domestic market for
to
be used for
to
sharing,
time
research institutes.'^"
which IBM introduced while the 8700/8800 was
the
was
the 8800,
version,
had multi-processor, multi-virtual memory capabilities, as
computing. ^°
several
an
HITAC
the
called
The commercial operating system
primarily to universities and
of
very-large scale computer,
processing).
1969.
0S7,
was
1960s
Kanagawa Works and was then taken over by the
the
at
a
(the
data
supported
real-time
build
Hitachi
telecommunications
the
in
project sponsored by MITI and Nippon Telegraph and
a
to
tackled
Hitachi
project
large
relatively
was
later
able
which competed directly against the IBM-370 and
subsequent series. ^^
Systems programs were not the only software orders
this
period.
manufacturers
Since
had
few
companies
in-house
Japan
in
software
outside
expertise,
to
of
Hitachi
Hitachi
the
and
during
computer
the
other
mainframe producers had to design several large applications programs.
Hitachi's case,
these included
a
series of
n
real-time reservations
In
systems for
(the first programmable system Hitachi delivered
the Japan National Railways
in
throughout Japan);
1100 terminals
with
1964,
on-line currency-exchange
and deposit systems for the Tokai Bank (1965) and Sanwa Bank (1967), and
production
real-time
systems
control
Toyo Kogyo
for
(Mazda)
and
Nissan
(1968). 31
The banking systems were particularly important, because most Japanese
banks
the time were buying these from
at
beginning
of
shift
a
which
software,
connected 200
processing center
in
remote terminals
Nagoya, was
a
several
Savings
in
American
New
completed the
and
Jersey
thoroughly dismayed
how
at
Tokai
initial
Due
working properly.
concerned
estimates,
of
about
had
improving
as well as
in
to
to
a
central
and other
he
They were
Chicago.
in
Howard
including
programming looked and, once they
a
year to get the software
full
Hitachi was not paid for this
absorb the costs
itself."^
The
made Sakata and other managers
their
Tokai
the
during 1963-1954 to
systems,
Illinois
took
it
U.S.
the
banking
difficult the
project
this
and
Continental
system,
around Japan
Before taking on the job,
to the contract terms,
extra debugging time and
frustrations
airline
Developing
'
particularly difficult but valuable learning
engineers spent nearly two months
observe
system miarked the
Hitachi's
systems.
domestic
according to Sakata.
experience,
Hitachi
more
to
IBM;
ability
to
control
cost
and
particularly
schedules
and
time
bugs.
Evolu tion o f the Fa ct ory Strategy
During the
Sakata,
late
believed that,
1950s,
engineers
at
Hitachi's
Totsuka Works,
including
since computers relied on digital technology similar to
the telephone exchange equipment they were already manufacturing,
12
Hitachi
would be able
responsible
officially
in
and
The
computers,
section
this
group
started
section
into
of
two planning
"service" was intimately linked to software since,
had to learn from potential customers what their
Hitachi
needs were and then be able to provide adequate programs.
to
first
language processors
(mainly
1963 was divided
in
the
government and university business, and another for private
The concept
contracts.
This factory thus
established
also
software development
for
about 10 engineers and
1960 with
sell
Hitachi,
in
programs), the engineering service section.
utility
sections, one for
to
manufacture computers independently. ^
hardware design
began
and
to
was
group
another
which
Closely related
technicians
trained
for
maintenance.
management next decided
Hitachi
division
1962
in
along
with
a
to
new factory
establish
to
a
manufacture
in
dispersion
the
make
it
then
led
the
the new plant took charge of writing or revising software for the
new RCA machines Hitachi was planning
that
hardware,
The hardware design
Kanagawa Works (separated from the Totsuka Works).
section
computer
separate
difficult
the
to
to
of
a
scarce
to
resource
But managers worried
offer.
--
write software for the new 8000 series.
creation
of
centralized
system
--
software engineers
This situation
program department
Kanagawa
plant,
RCA."^
The new department formally brought together the group
headed by Sakata and modeled after
a
would
similar
in
department
in
the
in
the
Central Research Laboratory that had been developing software for the 5020;
the
software
section
at
the
engineers
division
already
level
in
the
(although
Kanagawa Works;
physically
located
and
in
Works) that had been studying programs for pre-Spectra series
produced
in
program
a
the
RCA
Kanagawa
machines
Japan. The core group consisted of about 60 engineers;
13
Hitachi
hired another 20 personnel, for
total of 80.
a
Underlying the establishment
of
the design section and Sakata
factory product."
a
5020
the
yet
be
to
department,
according to the head
successor as department manager
s
in
struggle with time.
noted
delivered,
"Work
Fujinaka,
was
increasing
logical
step was
software factory.
a
In
rapid growth of
fact,
As
peripherals (Odawara)
or
so
by
from
train
(Kanagawa Works).
in
August
Totsuka
(a
computers,
1970s).
In
expanded
was
established
Hitachi
result,
a
a
but
Totsuka,
vshere
it
built
its
this
separate
1966 and purchased another site
in
leaving
most
few
others,
for
both
in
current
the
of
company's
was
still
for
facility
Hadano, an hour
mainframe
The design and production departments moved
1968,
in
The building housing the Kanagawa Works,
Yokohama,
Totsuka-cho,
insufficient.
a
"'^
the hardware and software areas.
in
so
Every day was
it.
the computer division caused acute shortages of space and personnel
located
1969,
With the 8000 series going on sale and software for
new structure couldn't catch up with
rapidly that the
The next
this
was also 'the anticipation that we would develop software
Fujinaka Satoshi,
as
of
'
to
plant
Hadano
departments
software
at
engineering
and
small-scale
remained within the division's staff organization
until
later in the
some
systems
February 1969, the Totsuka building was
separate factory -- the first software facility
in
officially
the world
upgraded
to a
referred to as
a
"39
factory. ^^
••/
t.
According
Yukio
(the
successor),
to
first
and
the
head
Sakata
managers
of
the
Kazuyuki
who operated the new
Software
Works),
(who served
as
factory,
Nakatani
Komoto
Nobuo
deputy general manager
during the 1970s), there were two reasons for following this strategy:
14
(his
One
was the acute shortage
software development
productivity.
of
software engineers and the hope that centralizing
in
a
single
Despite
a
nation-wide
would bring about an
facility
search
had considerably less than their target
still
and
The second
major
was
reason
software engineers,
for
to staff the
new factory
decision
corporate
a
increase
to
stop
in
they
1969.
in
treating
software as simply an engineering service that went along with hardware but
to
view
as
it
benefit
of
improved ability
the
to control
believed they were making
RCA,
quality.
fixing
to
bugs.
in
RCA programs,
way
of
guaranteeing quality.
manner;
Hitachi
as
an
executives
Shibata also
and
would
little
not
was
attention
bugs
the
tolerate
to
establish
discussed
the
at
it
software factory made
a
highest
levels
of
in
a
a
casual
company.
the
President Komai gave the final order to organize the Software Works
independent
over the
profit
center,
and
nature
name
of
in
they
company
"call
in
it
a
new
the
establish a "Software Center."
keeping
factory. "^^
not
understood
Hitachi's
traditional
facility;
some engineers wanted
to
But President Komai intervened and ordered
This
the world had established
sufficiently
with
A debate within Hitachi ensued
a
was despite the fact that no other
factory for software production, and
Japanese university professors criticized Hitachi,
was
as
an
forcing Hitachi, according to Shibata, to find
organizational structure and control system.
that
managers such
emphasized
not
Japanese customers
Nor was the decision
was
believed,
conscious departure from the approach used at
a
discovered
better
managers
Hitachi
Hitachi
where software quality was
paid
The
more disciplined environment.
a
in
approach,
factory
and should be produced and
could
that
with guaranteed quality,
inspected,
key
separate product
a
to
be
15
maintaining that
produced through
software
engineering
and
factory methods.
-^
The Factor y Architects
The
figure
central
manager
(currently
department
Consultants,
1941
in
from
technical
a
Totsuka
the
engineering
he
Works.
and
school
a
is
high
senior managing director of Nippon
Business
--
to the
two-year
machining
When
of a
Hitachi
Works
in
manager
Sakata had entered Hitachi
work
as
training
at
to
the
in
army,
a
in
machine operator
in-house
Hitachi's
Totsuka's
he joined
November 1945 and began developing
in
well
as
studying
as
improve productivity.
to
In
new computer inspection
first
In
job
tasks,
1957,
Sakata
glimpse of
a
computer
he was reassigned and made the
I960,
which had about 30 members.
section,
management separated computer development from the Totsuka
and
the
established
inspection
engineering department.
Kanagawa
the
which
section,
customers.
program department,
was
Then,
in
1965,
with
continued
Sakata
plant,
now
located
The following year he became head
division's engineering service department,
Hitachi
the
for
as
accounting department and got his
1962
of
stint
operations
an IBM 421 tabulating machine.
manager
well
additional
and conveyor systems
scheduling,
moved
for
times
as
and gone
school
production engineering department
standard
and
program
After
a
process
factory's
system
projects
software subsidiary).
Hitachi
a
key
several
for
the
of
Sakata Kazuyuki, the individual who had served
quality control systems was
as
development
the
in
within
of the
as
the
computer
which did systems engineering for
the
establishment
of
the
system
Sakata became responsible for software production and
quality control.
Sakata's
major
frustrations
were
16
bugs
in
the
software
Hitachi
was
RCA
divide among the
A dozen
and the shortage of programmers,
RCA,
from
receiving
hardware engineers not working on the 5020 learned how
Hitachi
ASSEMBLER manuals
continued
then
Hitachi customers.
program department
system
the
in
bugs
correcting
This experience,
as well
production management and inspection,
and
convinced Sakata that there had to be
prevent breakdowns due to
software
for
as
nature of
other
Hitachi
software was
Sakata recalled,
errors:
such
"even though
a
it
new
the
hardware
in
computer engineering service,
in
way
better
produce programs and
to
setting the same quality standards for
and
products,
the
rejecting
would always
there
that
or eight
software to
the
background
his
as
reviewing
shipping
before
to
FORTRAN, and
RCA's COBOL,
HITAC 3010 and 4010 machines; seven
for the
RCA and
from
programs
had to
he
machines, the 5020 project, and applications programs.
software by studying and translating
write
which
notion
that
"Thus,"
bugs.
be
was software, we called [the new
the
facility]
a
"44
r
^^
factory.
4.
The key
basic
was
ideas
Shibata
department
in
section
Hitachi's
of
who became responsible
individual
currently
Kanji,
He
the Software Works.
computer division
engineering at Shinshu
University,
first
in
the
implementing
for
head
the
of
Sakata's
engineering
joined the engineering
1964
majoring
after
and later moved
department and then the production administration
to
in
service
electrical
the system program
section
Software
the
of
Works.
Shibata
quickly
management soon
training
became the in-house expert on
after
he
joined
Hitachi.
One aspect
program for new engineers required them
during their second year to write
a
paper on
17
software-engineering
a
to
of
take
theme related
the
company's
several
to their
months
work.
and then give
a
Shibata chose to collect data on programmers
presentation.
RCA machines and
working on software for the
the 5020 --
much
hovs
time
they spent each day on different activities and different types of programs.
Programmers did not
being watched closely or keeping records,
like
Shibata, so they stopped doing this
the system program department,
in
too valuable
But Sakata, Shibata's supervisor
read his paper and decided this data was
Sakata then hired female employees to keep the
not to collect.
which became the basis
records,
196G.
in
recalled
of
the Software Works' production planning
and control system.'^"'
III.
FACTORY ORGANIZATIONAL STRUCTURE AND MANAGEMENT
Control Philosophy
With
the
managers
decision
became
management
establish
to
obligated
procedures
to
and
software
a
innovate
in
software
management by devising systematic controls on the process
There was
product quality.
treat
software as an
management
systems
and
Sakata
control.
"art"
little
evolved
In
centering
on
Shibata
and
engineering
and
costs,
flow,
opportunity, then, for Hitachi managers to
"craft."
or
software
Hitachi
company- wide accounting
adopt
thus
factory,
believed
Hitachi's
and
standardization
was
it
hardware factories, the
possible
components
apply
to
the
same
concepts to software.
In
particular,
equivalent
serve as
the
came
believe
to
similar
to
Shibata wanted programmers to design modules that would
what
that
you
of
standardized
we
had
find
for
to
hardware parts.
introduce
hardware,
18
a
and
"Around 1970 we
components
in
the
control
system
Software Works
we
established a committee to take this up as
members
soon
however,
realized,
a
"software
that
The committee
special project."
not
is
sufficiently
standardized to be treated the same as hardware components control."
changed their
priorities
product
standardize
manufacturing,
committee
then
design,
and
just
first,
had
this
as
they had to find
standards
establishing
adopted
name
the
done
been
worry about components
then
started
committee
original
and decided that,
for
A
activities,
Programming
"Structured
way
to
hardware
in
control.
all
a
They
special
while
the
Methods
Committee," believing that structured programming techniques would provide
a
way
to standardize the software design
Company engineers next
process.
spent several years studying these techniques from available literature,
well
programs
analyzing
as
improve
the
design
had
Hitachi
became discussed more widely
was
This
structure.
already
written
before
structured
industry journals
in
find
to
and
ways
as
to
programming
adopted
by other
companies. 46"
addition to their central objective of standardization,
In
of Sakata
them
to believe that
bugs)
In
for
and other Hitachi managers
were most
improvements
likely
to
in
productivity and quality (reductions
in
come from better
long-term maintenance,
better process control.
as
well
tools
Developing
involve visible
and
in
and management systems.
in
attempt
charts
and documentation for
"visualized" production control system
a
because software engineering did
To pursue these objectives, they decided
raw materials.
then
visible
as
became an especially important goal,
development
hardware production had encouraged
they viewed these as higher-level languages and modularization
software,
analyze,
the experience
to
manage,
much the same way
as
19
the
overall
process
of
not
to
software
they saw hardware engineering and
They developed factory systems
manufacturing:
production management,
including man-pov,er,
controls; and for product engineering,
inspection.
The controls
involved
support-tools
and
with
systems,
process,
motivation
the
a
mixture
strong
for
and product
quality,
including standardization, design, and
automated
during
late
1970s
and
production
and
the
(See Table)
'
pursuing
and
manual
of
efforts
1980s toward computer-integrated production.
Initially,
provided controls for
that
factory-type
product-engineering systems was to be able to inspect software products,
any other product Hitachi manufactured,
But
quality.
turned
out
a
to
side benefit of the system of controls,
be
the
"minimization
improvements
significant
and thereby be able
in
of
problems."
productivity,
thus
like
guarantee
to
according to Shibata,
This
resulted
has
addressing
indirectly
in
the
shortage of skilled programmers. °
Process Flow and Organization
The factory organization contained departments and functions
those
in
hardware manufacturing
engineering,
accounting,
product
plants:
and general
affairs,
managers did not view the factory organization
consolidated
some functional
and
centralized
artificial
much the same way
primarily
conceived
engineers
composed
of
as
other
design
of
and
engineers
testing
20
Hitachi
over time,
departments
as
they
software
(railways,
banking,
the Omori Software Works.
software
the
software
training.
static;
applications
industrial) development in a second facility,
Hitachi
as
inspection,
intelligence and computer graphics),
custom
large-scale
all
as
added design
areas,
technology evolved (such as for
well
as
planning,
similar tc
development
around
activities.
the
Data
on
process
world:
in
as
man-pov\er
allocations
ca.
number
(total
1985 indicates this
workers) per process
of
Hitachi
at
an accurate conceptualization:
is
went into planning and design, 5%
to coding,
Software Works
roughly 50
to
55%
30-35% to debugging, and about
10% to inspection. ^
The organizations and process
flows
somewhat different for
were
systems software as opposed to applications software.
the
of
As seen
the table,
in
Software Works began with three design departments for distinct types
system development (custom applications engineering),
programs:
programs
(basic
and
on-line
programs for the National
applications
or
industrial
software),
Railways,
customers).
institutional
programs
For
(large-scale
NT&T,
systems
system
real-time
and other
banks,
the
software,
design
departments were responsible for design, program construction (coding), and
debugging,
however,
high
specializing
separated
with
in
from
inspection
level
done by
different
department.
separate
At
Omori,
done by systems engineering departments
was
design
a
industries
or
functional
areas,
program construction and system testing.
and
In
this
this
was
clearer
division of labor between design and "manufacturing," according to Shibata,
Omori operated more
like
systems software as well
to
do
coding,
but
program construction
a
in
there
"factory."
There was
a
division
of
labor
for
the sense that younger programmers were asked
was
no
as at Omori.
organizational
^"
21
separation
of
design
and
SOFTWARE PROCESS FLOW AND DIVISION OF LABOR^
A
SYSTEMS SOFTWARE
(Hitachi Software Works)
Pesig n Depa rtments
Basic Design
Functional Design
Structural Design
Coding
Stand-Alone Debugging
Combinational Debugging
Comprehensive Debugging
Final
B.
^
Inspectio n Department
Initial Inspection Planning
Documentation Planning
Inspection Program Compilation
Product Inspection
CUSTOM APPLICATIONS SOFTWARE
(Omori Software Works)
Sy s t m En qinee r nq D ep artments
System Proposal Compilation
Demonstration
Estimate
P n>g ra mm ng Depa rtments
System Construction/Consultation
System Design
Program Implementation
Conversion
System Test
i
Inspect io n an d Quality Assurance
Inspection
Final
Follow-Up Service
22
SOFTWARE FACTORY ORGANIZATIONAL EVOLUTION
A. Hitachi Software Works 1969 Organization Chart ^^
DESIGN DEPARTMENTS
ADMINISTRATIVE SECTIONS
SYSTEM DEVELOPMENT
Administration
Inspection
Engineering
Design Groups
(6)
SYSTEM PROGRAMS
Planning Group
Design Groups (2)
Accounting and Control
General Affairs
COMPUTER TECHNOLOGY SCHOOL
ON-LINE PROGRAMS
National Railways (2 Groups)
NT&T
(4 Groups)
Banking (2 Groups)
Government (1 Group)
B. Hitachi Software
Works 1986 Organization Chart^-^
Product Planning Department
OTHER DEPARTMENTS:
DESIGN DEPARTMENTS:
No. 1 Systems Programming
No. 2 Systems Programming
Database Programming
Data Communications Programming
Language Processor
Artificial
Intelligence
Computer Graphics
Small-Scale Systems Programming
Engineering
Documentation/Manual Development
NT&T Information Processing Systems
Inspection
Computer Center Service
Software Education Center
General Administration
Purchasing
Accounting and Control
Software Technology Center
C. Onrori Software Works 1987 Organizational Structure and Functions
SYSTEM ENGINEERING DEPARTMENTSPROGRAMMING DEPARTMENTS
Banking
Hospitals
Analysis, Planning, Design
Implementation
Inspection & Quality Assurance
Local Government
Industrial
OTHER DEPARTMENTS
Media
Distribution
Program Support
Accounting
Contract Service Program
Technical Support Center
System Design Automation
Computer Center
System Simulation Test
Payroll
Networks
Tool Development
23
^"^
A
aspect
flexible
managers
move
to
personnel
department,
such as
departments
in
arose
Software Works
on
being
groups within each department
or
difficulties,
they
could
the
add manpower
appeal
the
to
ability
groups
within
and 600
500
(around
largest
a
example,
For
between
of
900);
about 100 programmers, with
of
Managers could
to
the
project.
had
generally
NTlT department
about 30 members.
of
given
a
was
among
between
freely
departments were then organized into groups
sub-groups
however,
factories,
problems
if
Hitachi
the
with
people,
both
of
also appeal to engineering
to help solve project- related
Engineering
Department
and the
Software Technology Center for problems or develop tools considered to have
factory-wide relevance.
"^
Dep a rtmcnts and Functions
Staff
PRODUCT PLANNING
The Product Planning Department
in
1970 to centralize planning activities dispersed among the system program
department,
section.
the
Responsibilities
example,
the
Hitachi's
Itel
in
U.S.
the
compatible.
Computer
Planning
To
Liaison
These
assist
Office
in
in
but also for exports
this
the
to
to
effort,
Mountain
such
as
In
1974,
Hitachi
View,
Software
24
Works
also
nev\
for
determine policy
OEM
make the Hitachi hardware
to
(control)
compete directly with
included preparing for
activities
in
products
up promotion conferences
and studying how
Department
for
which Hitachi was designed
series,
the IBM 370 family.
set
and the administration
planning
included
beginning with OS7,
department
M
program area,
large-scale
operating systems,
for
Software Works was launched
the
in
established
California,
which
administered
exports to
fully
in
the
directly.
IBM
1972
a
Product
This
served as an
office
"information
on
pipeline"
IBM,
replacing
RCA, and
1978 was absorbed by the San Francisco office of Hitachi America. "
late
department became involved
the
1970s,
unbundled
software
technical contracts.
from
and
hardware,
product pricing as
in
the
Hitachi
of
overseas
department,
software
the
Software
administration
in
In
in
'
ENGINEERING (PRODUCTION ADMINISTRATION)
department originated
This
section,
of
Works.
It
engineering
the
and was moved
Kanagawa Works,
the
1970
in
to
began with two sections (engineering and administration) and 36
The engineering
members.
in
computer division,
other
section served largely as a liaison group for the
Hitachi
and
factories,
providing
subcontractors,
explanations and documentation on software-product pricing and progress on
product
development.
production
The administration
management and
process
was
section
control
responsible
(scheduling),
as
well
for
as
administration of the computer and software centers attached to the factory.
This
group
standard
set
and
times
studying software productivity.
monitor design
It
and inspection,
for
in
out of the factory budget.
department later became
software
from
full
overseas
also
well
as
the System Development Laboratory
Technology Center (established
was
responsible
cost
helped develop control
as
other tools,
(established
in
in
1975)
control
and
systems to
conjunction
with
and the Software
198X). General-use tools were always paid
Other sections
departments:
and
for
Japanese
CO
documentation/manuals section.''"
25
of
the original
procurement,
which
subcontractors;
engineering
purchased
and
the
INSPECTION
department originated with the SoftvNare Works
This
and
has
followed
the strategy of developing inspection and control techniques based on actual
operating
The manager
data.
factory head,
as
and debugging,
bugs while
and
in
an
all
Hitachi factories.
important tool
program
a
is
has
and
used
input/output
all
to
the
testing
been the "needle probe," to identify
correct
to
directly
addition to overseeing
In
and
to revise estimates
The inspection
problems.
the
department also operated the SST, established
conditions
reports
development and provide data
in
countermeasures
formulate
department
this
of
which simulated user
1977,
in
generators
defect
circuit
to
detect
bugs; organized the design review task forces, which include reviewers from
several different departments, including inspection; evaluated the performance
of
programs
information
and
at
locations;
took
charge
bugs and developed methods
on
developed
department
customer
the
had
factory's
responsibilities
of
maintenance;
testing
bug forecasting
for
of
for
system.
compiled
potential
In
defects
addition,
the
programmer training and helped develop
tools. ^^
support
ACCOUNTING AND CONTROL
The members
factory's
how
to
cost
treat
of
this
accounting
orders,
department
system.
sales,
set
up
A major problem
and income.
have maintained
in
the
Kanagawa Works.
a
project's
the
beginning was
Management then decided
development expenses for systems software after
then charge these back to the
and
to
total
completion and
Payments for applications
programs for customers were included with the hardware; the Software Works
received
payments
by submitting in-house order tickets.
26
Essential
to
the
calculations were the standard times
for
software development activities,
all
by the engineering (production administration) department. ^
set
SYSTEMS ADMINISTRATION (OMORI SOFTWARE WORKS)
department originated
This
systems
department,
consultation
from
1973,
in
which
developed
and Sakata,
Software Works,
department
divisional
and
centralize
introduction
to
the
standardize
the
of
first
department
responsibilities
for
mainframes
programs
to
1985
made
The
run on them.
for
to
the
required
institution of
standard times corresponded to the move of this
The department
financial
controls
for
leased
moved the systems administration department
in
which
1974,
this
effort
their
of
preparation
in
in
moved
manager,
part
as
activities,
Software Works.
the
to
design
M-series
additional personnel to rewrite
SC (system consultation)
Software Works
the head of
Fujimoto,
the deputy general
division's
applications
large-scale
programs for the government and private customers.
the
computer
the
to
systems."'
the Omori,
took
over
Hitachi
then
also
Tokyo
site,
and
programs.
this a separate factory for applications
MANPOWER CONTROL
The
basic
tool
standard
times
for
basic design.
Hitachi
all
manpower control
Hitachi's
software factories
phases of the development process,
in
has
revised
these
once
programmer productivity.
discipline an engineering activity began
in
in
Since the establishment of the Software Works,
managers
improvements
for
in
per
year,
This
to
attempt
the mid-1960s,
is
beginning with
a
committee of
keep
to
up
study
with
and
when programmers
the Kanagawa Works began recording data on computer time and personnel
27
required to develop particular programs. Guided by Shibata, Hitachi engineers
had
enough
procedures
for
development,
and
data
actual
estimating
both
placing
initially
confidence
labor
to
Hitachi
used
and
1967
hours
on
made
1969 then
in
establish
to
machine
information
this
inauguration of the Softv^a^e Works
by
job
formal
program
for
The
tickets.
necessary to adhere
it
company-wide budgeting and cost-accounting procedures, which
s
standard
times
basic
as
accounting
units
for
all
engineering
and
production activities.
"We were perplexed," recalled Sakata, but they set up
succeeded
each
drawing
in
class
up
formal
programmers,
of
standard times
based on
for
committee that
and
activity
for
The
and experience.
training
their
each
a
standard times consisted of debugged program steps per day or month, and
took into account factors such as the type of program being written and the
language being used.
in
the early
planning
years
They
collected the data
a
"red book" that became,
the basis for the factory's current cost accounting and
1S70s,
systems.
these
instituted
Hitachi
IBM began promoting the use
before
in
controls
for
software
standard times,
of
several
although the
System Development Corporation had published some materials discussing how
to
devise standard times
for
1967-1968 and these provided
software during
several suggestions to Shibata. °^
managers early on
Hitachi
required
different
a
To deal with
times
in
tools
and
set
this problem,
1973.
systems
of
realized
that
systems
than customized applications software.
activities
they established SC (system consultation) standard
The systems engineering groups
such
software development
as
HIPACE
(Hitachi
also
Phased
developed separate
Approach
for
High
Productive Computer System Engineering) to standardize their proposals and
28
aid
to
made
design automation.
in
it
relatively
independent Omori
scheduling
the
to
improved significantly soon after the factory
and continual
development process,
Accurate
standards and tools
move the applications departments
to
through the compilation
was established,
different
of
site.
Planning and
the
easy
The evolution
programmer
data
actual
of
each
phase
of
refinement of planning techniques.
were considered
classifications
for
essential
to
both
the
planning and budgeting systems, which, for each project, took into account
the
and
experience
classifications
service
in
speed
output
team
of
Programmer
members.
were determined largely but not entirely by their length
company.
the
performance,
potential
according to Sakata,
increased
was
Seniority
fairly
a
accurate
indicator
of
of
because actual data showed that coding
markedly with experience.
But,
at
any given time,
only
between 20 and 30 percent of programmers actually met standard times, and
it
generally took 2 to 3 years to reach standard times for coding (and longer
for design)
Programmers were
classifications.
the
completion
also
tested
They were made
of
each
course.
were tested through competition
charts
and
code
to
solve
individuals and groups,
as a reference for future
before
managers
to take certain
In
in
certain
addition,
courses,
all
raised
their
official
and then tested
programmers twice
contests,
where they had
problems.
The contests
and management recorded the results
a
year
write flow
to
involved
in
at
a
both
data base
planning and scheduling.^
PROCESS CONTROL
Establishing a capability for accurate planning and process control were
29
his
most enduring problems, claimed Sakata.
because Hitachi
s
These were especially important
computer division sales department would always announce
new computer products
and
give
specifications
out
Works had developed the systems software.
This placed
on softvsare managers to meet their targets.
applications programs,
upset
specifications
tremendous burden
a
Customers also wrote their own
software
was
delayed
or
changed
Hitachi
if
through
documents
covering
the
half
first
status of each
development
the
of
Large projects include several hundred people, divided into teams
process.
about
the
.
The Software Works' process-control system monitors the
project
Software
the
based on the advance specifications, and became very
systems
the
if
before
with
thirty
parcelled
responsibilities
equally
out
to
of
members.
team
Time and manpower estimates rely on actual data for past projects, including
the annually revised standard times.
For example,
architects
scheduling for
determining
program steps
this
the
will
according to Shibata,
general
take.
project
functional
This
the
of
Using the
and
the system
how many
the most difficult part of scheduling,
is
Then they
look
to
the development process and calculate
and particular programming experiences
project.
involves
specifications
They next
standard time objective for the entire project.
levels
first
and thus the most error prone.
standard times data for each phase
a
given
a
standard times
as
of
a
look at the skill
the employees available for
reference,
they work
schedule based on required program steps, man-months adjusted for
out
skill
a
and
experience levels, and computer time.
At
the
inception
diagrams and then
a
of
the
factory,
managers began
computerized diagramming
30
tool,
using
simple
arrow
PERT Network System
(PNET),
keep track of projects and draw up
to
linked this experimentally with
Computer- Aided
(Hitachi
accurate,
however,
program often
have
managers preferred
negotiations.
1973-1974
and which
all
CAPS
introduced
an
as
progress
actual
to
a
since
parts
work can
that
of
a
continue;
these types of problems through personal
with
month
a
diagrams
on-line
of
to
discuss
(formalized
problems
and
in
potential
and
until
system
in
the
factory
1978 to track
and
documentation,
of
This system involved the assignment of every
terminal
specific
planning,
production control
modules
thus went back to
Hitachi
process
for
completing
debugging and design review.
programmer
lax,
was
convenient to use arrow diagrams on paper, because
arrow
written
HICAP
especially
serious
other
before
be
to
Most
too
the schedule changes they usually made.
manually
the
completed
met once
it
problems.
prove
Hitachi
1971,
in
during project progress meetings
addition,
In
solutions), they found
of
deal
to
not
schedule was
the
be
to
did
It
other
involved
computer control
the
letting
planning simulation program
a
Planning).
and
master schedule.
a
well
as
as
a
data
central
base
to
keep
track of the process flow, mainly through the completion of documentation.""'
In
lists,
the debugging process,
which indicate problems and progress toward solutions, including from
1973-1974
a
Hitachi used
and
the basic control mechanism has been check
system of tickets
PX
(or
tags)
for
accompanying
documents. "°
accompany daily control charts during debugging,
tickets to
PY tickets for daily control charts during inspection.
accompanied
control
charts
identifying
specific
defects
tickets designated control charts used during planning,
Other tickets
correcting
indicated
defects.
the
Overall
state
of
monitoring
31
or
of
the
bugs,
design,
work-in-process,
PZ
and
tickets
while
PW
and coding.
progress
debugging process was
in
also
incorporated within CAPS.
To determine what
percentage
managers submit reports on completion
to
the
of
of
modules.
been
has
project
a
program
a
If
completed,
designed
is
have 100 modules, for example, and 80 are completed, then they consider
project
the Softv\are Works
people
--
finish
close
not
One
done.
8Cfc
the
target.
best
people available
This
was
because
of projects."^
systems used
the control
of
the
but
understanding
facilitated rapid
results
the
and generally
--
environment
factory
IBM's experiences
contrast,
In
at
managers can add
projects are falling behind,
if
anyone,
just
to
that,
is
the
of
with the 360 operating system development was that adding people tended to
make projects
later,
due
communication
the
to
needed
time
to
familiarize
^
new personnel
.
QUALITY CONTROL
defined
engineers
Hitachi
preventing the creation of bugs
performance specifications.
and
so,
other
maintainability
measures
Sakata,
of
control,
maintenance
as
high-level
well
of
directly
a
affected
program,
languages,
product
as
second,
and,
stage,
first,
as,
meeting
gave them primary importance.
and other factory managers
and
software
for
so
Hitachi
also
to
tracked these
the
mid-1970s,
adopt
structured
in
and formal systems for quality
engineering.
short-term
decided
These
productivity
by
facilitated
making
it
and
long-term
possible
divide job tasks more easily and to test completed modules and programs.
32
Two
manufacturer were
the
To improve quality control
secondarily.'
Shibata,
the design
Hitachi
that
and portability
design methods,
process
quality
in
control
These two factors directly impact the customer
according to Shibata,
features
quality
to
1971,
In
of
the factory instituted control charts indicating the generation
bugs and status
corrections,
of
developed by Sakata, to test
and then
completed,
added
another
the
to
to
actual
bug generation
time-series
FORCST.
"needle probe"
a
bug estimates.'^
system:
tickets
P
to
indicate corrects of bugs.
PX-PW-PZ process-control
control and estimating.
as
ticket
for different types of
of
1974,
In
system,
quality
bugs
were also design
effort
project
and data on
tool
programs became the basis
program for forecasting
control
these were
simplify
to
instituted
This also provided programmers with examples of bugs
the
program
designate
types of software, to help them avoid making similar errors.'"^
part
Hitachi
1972,
In
At the same time, the needle probe
statistical
technique,
program being developed when about 60% was
the overall
ticket-control
and B tickets
changes,
linked
revise
a
well
as
review
in
of a
1975,
in
different
Included as
sessions
from
around 1974 (particularly used for applications programs where Hitachi had
to
meet customer specifications).
focusing
on
system
particular
instructive to present to
all
addition, the system-leaning practices,
In
problems
design
employees
in
and
that
solutions
the Software Works,
seemed
supplemented
other quality assurance activities.
Following the practices of other Hitachi factories,
with
assistance
formalized
as
of
well
engineers
automated
as
during the mid-1980s,
referring
its
to
quality
its
Development
System
the
control
system as
and
tools
"SQE"
Laboratory,
procedures
(Software Quality
This maximized not subjective measures of quality but program
Evaluation).
"reliability"
from
the Software Works,
(
shinraisei
"support and improve"
,
and consisted of
reliability
a
set
of
procedures and tools
by determining the number
of defects
to
and
the software and providing quick analysis of the causes of errors and then
33
feedbacl-
make corrections and prevent
to
errors
correcting
before products
continual improvement
quality
Previously,
reach
primarily
control
The objective was
customer.
the
the level of "built- in"
in
by predicting and
errors
similar
tsukurikonii
(
involved
the
design quality.
)
evaluations
statistical
of
finished programs, without systematic error analysis, feedback into design, or
control over future design efforts.
Two
basic
should
analysis
information
initial
involve
allow
to
number
broad
a
feedback
useful
through
design
One was
underlay the SQE system.
policies
for
measures
of
phases
all
and
sufficient
development,
of
These measures,
inspection.
the error
that
and
tools,
from
analysis
techniques \^e^e also supposed to be sufficiently flexible to adapt to changes
in
programming environments over
of
and
procedures
development
the software;
of
computers.
personal
should
tools
easy
be
therefore,
should
It
The second was
time.
be
to
use
everyone
for
made the
Hitachi
noted
that the entire set
these
that
tools
two
involved
in
available for
characteristics--
defect analysis and feedback to design to build quality into future products,
and
simplification
widely,
of
insuring
Japanese
at
of
tools
least
quality
and
procedures
some measure
control
to
make
of success
practices
in
they
sure
were
used
were both characteristic
--
other
"hard"
manufacturing
reports
on
7f>
industries '°
.
The
procedure
basic
customers
to
estimate
was
followed
how many
to
latent
(1)
use
defects
information with in-house data on bugs uncovered,
defects
in
new,
similar
products,
errors" through testing.
as
well
as
its
workforce,
and
As long as
did
not
a
(4)
change too much,
from
this
predict the number of
attempt to locate these
product type and
34
(2)combine
existed,
(3)
bugs
its
"built-in
user environment,
Hitachi
engineers
felt
they
confident
could
use
particularly
programs,
data
historical
since
the
predict
to
captured made
data
bugs
latent
possible
it
new
in
revise
to
estimates continually.
simple statistics were considered most
Several
development
analyzing
errors:
program
processing
number
of design
and
content
percent
configuration;
the
of
(number
size
program written
size
of
development
languages;
high-level
in
code);
of
lines
program
program; number
size of the
the program;
estimating and
in
or
steps
of
structure;
man-hours given the
man-hours given the
useful
number
checklist
of
of
test
given
items
comparison of the estimated and actual sizes of the
the size of the program;
program; patterns formed by bugs detected.
The SQE
estimation,
tool
consisted
set
quality
test
estimation,
three
of
and
--
subsystems
design
quality
comprehensive quality estimation--
each covering different phases of the development process.
The design quality estimation subsystem was
design
stage.
For
program
listing
to
designed for.
objectives
bugs,
program
as
size,
a
used
was drawn
table
development progressed.
in
Second,
in
the planning
up for each
Third,
as
a
checklist
reliability
part of the error analysis procedures,
program was written
coefficients
drawn from
to
historical
model
data
new
the software and the
make sure the software performed the basic functions
establishment"
using
first,
the number of bugs expected to be
number detected
was used
reliability,
first
the
on
its
was
"quality
a
occurrence of
factors
processing content and structure, percent written
in
such
as
high-level
languages, number of man-hours spent on design and testing.
The
test quality estimation
the different testing steps.
subsystem was use
A QC graph chart
35
to evaluate quality
actual
during
bugs detected on one
against estimated bugs
axis
likely
possible to monitor visually
occur
to
progress
in
different
in
stages;
error detection,
this
well
as
as
made
it
provide
immediate "feedback" to design and "feedforward" to improve later testing-before
estimates
program
completion
the
at
called
development
each
of
how many bugs were
estimates on
a
To track the data on
product was completed.
a
likely
evaluate
a
and
undetected,
bugs versus
generate
to
Hitachi
used
FRCST.
The comprehensive quality estimation
used
This
inspection.
phase,
remain
to
actual
generated
data
program on the basis
of
subsystem was
by
other
the
used
final
subsystems
two
eight criteria covering
in
to
product design,
product quality, and operating quality.
PRODUCT CONTROL
This
consisted
department
in
of
a
formal
system,
Kanagawa Works,
the
both
for
by
started
storing
the
program source
and accompanying documentation for future reference, either
or
add enhancements.
to
copies
of
all
programs
in
1976,
In
a
to correct
started the practice of
Hitachi
separate
program
system
location
files
bugs
keeping
guard against destruction
to
from earthquakes or accidents.''
STANDARDIZATION
In
addition
to
standard
times,
from
the
inception
Works, Hitachi managers made "job standardization"
not
establish
long-term fixed
initially
met
almost
weekly
But the
to
standards
determine
36
the
top priority.
Software
They
did
because personnel and technology
standards,
were changing continually.
a
of
what
establishment
committee
work
standards
short-term
should be and codified these as the Hitachi Software Standards (HSS).
This
entire effort involved a deliberate attempt to standardize software as Hitachi
standardized the development and production of material products;
factories
specifically,
managers tried
prevent programmers from designing, coding,
to
and documenting software products
standardization
technique
productivity,
raise
to
In
Shibata's opinion,
probably the most important
flow was
the entire process
found
Hitachi
high-level
with
of
different ways.
in
when combined
particularly
languages and group-programming support systems such as
The fewer bugs that resulted was one advantage; another was
CAPS.
that
standardized documentation made inspection easier."
According
to the official
the standardization effort was
factory history,
extremely difficult and not very successful at
The
factory managers succeeded:
structured
design
method
portability,
despite
the
same time,
the
control
and
system"
control
1973
in
instituted
and then
in
to
facilitate
1977
Meanwhile,
the
factory
manuals for each programming language used
The structured programming method
standardized approach to design:
determination of internal specifications
manufacturing (coding); and
logic
structure
interconnections
represented
Hitachi
37
layers
those
registration
coding
began with
adopted
a
user requirements; (2)
(the program's
between
the
the facility."^
(the program's
functional
of a
[modules]
standard
published
logic
structure);
(3)
"physical" structure);
(5) inspection (testing
the
(input/output)
"components
(1) determination of
determination of external specifications
(4)
in
At
resulted.'^
general-use software tools
a
however,
program maintenance and
standardized
a
time,
depended on the establishment
programs that often
lengthier
factory
system.
effort
Over
first.
of
layers.
and debugging).
a
The
program and the
First,
programmers
wrote
language
tool,
CEG
(Cause-Effect Graph), and decision tables to identify inconsistencies or
flavss
in
specifications
the
They then
structure.
logic
functions
partial
natural
in
develop
to
and
used
down the
broke
algorithms
up the program (their hierarchical arrangement
function
object
implement
to
The physical structure represented the
specifications.
in-house
an
as
into
desired
the
actual modules making
well
interconnections)
as
and data (data hierarchies, data and module interconnections, and data-point
relationships)
.
major
Hitachi's
design
were
objectives
structure as closely as possible to the logic structure;
and
physical structure;
(3)
input
subroutine
several
"
(2)
physical
the
to standardize the
of the physical structure as
This latter principle required each module to have
independent as possible.
only one
make the elements
to
match
to
(1)
and one output,
and each module
Documentation also followed
a
to
be
in
effect
standardized format.
a
"closed
addition,
In
support tools relied directly on the standardized design structures.
AGENT (Automated Generator
of
External
Test
Cases),
for
example,
automatically generated test items from the cause-effect diagrams and served
as
a
logic-design
System)
served
support
as
a
tool.
ADDS (Automated
design-support
for
tool
Design and Documentation
the
analyzing design information and generating documents
Related
to
standardization
was
the
physical
in
capability
developed for both system and applications programs.
did
not
assume
programmers
to
a
reuse
scheduling
Potential
reusability
targets
was
more
considered
easily
at
38
the
than
very
by
graphic form.°
to
modules
reuse
Since standard times
software,
meet or surpass standard times,
or
cost
programmer would
structure
doing
this
allowed
and helped managers meet
without
reusing
beginning
of
modules.
designing
a
and
program,
facilitated
through
the
standardization
design
of
through
structured programming.
The tradeoffs,
according
to
involved
Shibata,
enhancements; structured programs designed
to contain
always perform as well as newly written programs.
used was that,
Hitachi
then,
in
if
it
and
reusable parts did not
In
fact,
general rule
a
they had to revise 30% of the code
terms of functional performance,
needed from scratch. Only
performance
was better
module,
a
in
write the module
to
1985 did Hitachi managers require programmers
in
to start
keeping data on how much code they were reusing, although survey
data
the
in
paper
previous
ranked
Hitachi
the
in
category
high
for
this
measure, exceeded only by Toshiba, which was over 50% (See Appendix table
on
Analysis").
"Reusability
reusability
rate
was
effort
considered as
addition,
were
a
series of
part of the
1970.
A
tool
in
for
(Hitachi Translation
in
1977.
Both
of
1968
for
the
reusability,
and
reusability
Program Application Library), an on-line
was
transferred
programs
for
to
set
first
Software Works
the
different
up within the
machines,
in
HITRAN
Program Library), was separated from the HIPAL system
these were for
Program Library Network) was
it
then
translating
software,
the transfer of programs among
facilitate
(Hitachi
and
systems
standardization
data base of applications programs and utilities,
computer division
of
applications programs.
in
systems to
HIPAL
different machines.
releases
The most opportunities
about 90%.°"^
however, Hitachi viewed as being
In
new
For
a
in-house
use.
HILINK
separate system launched
in
(Hitachi
Users'
1975 that made
possible for Hitachi customers to exchange programs they had written.'"
TRAINING
39
Training was integral to standardization and the general success of the
Consequently,
factory effort.
the Softv.are Works.
in
an education program was set up along with
who had studied
hired both software engineers
Hitachi
the U.S., as well as high-school graduates which the company had to tram
But the expansion
itself.
over 900
1971
in
created
Software Works personnel from 348
of
severe strain on instructors;
a
was to make greater use of large meetings,
based
tests
programmers,
on
to
the
judge the
Standards
Software
Hitachi
abilities
well
as
use the
as
and
1959 to
temporary solution
a
results
of
among the
contests
programmers.^
of
in
Managers recorded
the results of these tests and contests and used them (along with length-ofservice information) to classify programmers as an aid
estimating time and
in
cost schedules."^
The education
Hitachi,
after
which
system engineer,
applications
employees
computer
and
depending on whether they were
During
were classified
and
as
the
first
trainees
and
year
programmers
or
years
the
during which time they
factory,
system
Programmers with between
junior
leaders
six
years
engineers
and ten years
from
second
received
of
in
remained
the
software
Software
the
courses
They
"junior"
in
12
systems
in
in
took
programming.
basic
for
in
received the grade of chief programmer or
individuals
software.
science
scheme extended
classification
or
Vvorks,
introductory
classified
through
additional
as
fifth
courses.
experience were designated
Between their ninth and
and received middle-level courses.
tenth years, programmers rose to the status of planners or sub-leaders, while
undergoing advanced training.
Chief programmers continued their education
and
software
studied
subjects
such
as
reliability,
or
semiconductors, and computer network technology.
40
use
of
design
review,
There was
however.
In
separation
between the systems and applications factories,
distinction
a
program design
of
where there was
no organizational
program construction
(implementation),
Software Works,
Hitachi
from
young employees who started out doing coding eventually could
become designers.
implementation
versus
area,
up
to
Omori, however, there were separate career paths for
In
engineers
system
rise
a
specialists
implementation.
in
Within
young employee might move up from doing
the
simple
coding to detailed design and planning, but would not normally switch to the
system
engineering
implementation
and
area.
The reason was that
systems
engineering
and different sets of
specific
although
all
skills,
in
outside
managers
customers
felt
required
which employees should specialize,
systems engineers generally spent about two years working
program implementation before moving over
IV.
for
Hitachi
in
to the high-level design area."'
THE TOOL SET
The
initial
essence
of
the
factory
infrastructure
at
was
Hitachi
primarily a combination of policies to promote standardization and the use of
"good"
practices
division
of
labor
such
and
as
structured
in
set
of
tools
to
facilitate
largely
in
software management that appeared to defy
through management alone.
six areas of specific
A
group programming evolved afterward,
response to several problems
complete solution
design.
A
Hitachi
memorandum
cited
concern:
1.
The
2.
Increasing scale, complexity, and diversification of program functions
invisible nature of the production process
41
3.
Pressure for higher
4.
Difficulty of improving production efficiency
5.
Shortage of software designers,
reliability
especially
experienced designers,
and
managers
Increased work hours for management. °
6.
The
and
engineers
response
the Software Works
at
at
Systems
Hitachi's
arrived
during the
at
Development
late
Laboratory
1970s was to develop
computer-aided systems for functional support (such as design, coding, and
and
testing)
group
and the
CASD (Computer-Aided
through
Software
Development
(Computer-Aided Production Control System for Software).
CAPS
on
relied
(Integrated
act vities °^
The
.
development
Department
of
in
System
into
and
the Software Works
System);
and
areas
CASD and
standardized
broader effort labelled ICAS
System),
Laboratory
the
with
in
tools,
Both
aimed
production-management
Development
these technologies,
a
Engineering
Software
product-engineering
support
or
also evolved
Computer-Aided
integrating
i
subsystems
various
They themselves
methods.
for
policies
man-power, process, and quality control through CAPS
for
policies
The factory's
general.
in
and inspection functions for systems software were
design,
standardization,
integrated
programming
has
at
full">
tools
and
directed
the
cooperation of the
Engineering
related to production and quality
control. 90
Computer-Aided Software Development System (CASD)
CASD was
software
mainly
programs
a
response
and grew out
to
the
of
a
42
increasing
design
and
size
and complexity
debugging
tool
of
Hitachi
developed
during
1975-1977
controls
centralize
to
supporting
for
standardizing design through the use of structured programming,
and
high-level
languages for system construction, multiple and remote computer sites, and
program library.^'
central
evolving
improvement,
standardizes
which
and quality.
flows,
1979
increasingly
a
variety
of
in
and
scheduling
in
well
as
to
improve
cost,
process
underlying
CASD:
One was
each phase of development and then utilizing support tools.
also
through
be
automating
improved
support
these
through
only
not
much
as
possible of what has
supported only with
design,
each
phase
a
single
system.
of
but
the
This
the words of the architects of the system, to "modernize"
in
usually been considered
tools for discrete parts of the
CASD
Structurally,
that
Second was
standardization
for
tools
development process and then integrating them into
was an attempt,
CAPS,
to
software could be improved by standardizing the tasks
performance could
for
linkages
activities
as
reliability
^
that
as
for
tool
a
and with
technologies
There were two basic assumptions
labor productivity
became also
it
parallel
in
manpower planning and
over
control
After
a
manual activity,
a
development process.^''
included three interconnected support subsystems,
programming,
and
The design-support subsystem
testing.
constructed the design documentation and analyzed the design specifications.
The programming-support subsystem made
using
a
high-level language,
subsystem then
helped
tested,
as
as
well
possible
it
and analyzed the results.
devise
the
test
and
items
evaluate the comprehensiveness
run
of
to
write
the
system
The testing-support
the
program being
the tests
after
they
were run.
The design-support subsystem
relied
43
on
a
structured-programming
tool
called
Automated
Design
Module
Design
Hitachi's
and
Language
MDL made
(MDL).
standardize and formalize design specifications
system placed this documentation,
central
database,
design
review
process.
ADDS covered
as
it
well
as
possible
to
as
the module level; the
at
corrections or changes,
Printers
and terminals
The
documentation.
in
provided the capability
tables
the
to
and charts produced by
such as the functional layered structure
areas
ADDS
into a
and checked for obvious errors, thereby assisting
the design
"visualize'
well
as
(ADDS)
System
Documentation
of
program,
a
module specifications, the data flow path, module connections, and summaries
of the
modules, functions, and changes.
The programming-support subsystem
for
coding,
design
called the Static
to
catch
standardized language
a
This also facilitated
and what H'tachi
compiler
Code Analysis (SCAN) system. Coding reviews were supposed
examine the program
a
components were
main
HPL's
program bugs
was largely
a
Programming Language (HPL).
the Hitachi
review.
on
relied
early
as
and
also
provide
a
way
to
engineers were frustrated because this
Hitachi
logic.
possible
as
manual process, and was affected significantly by the different
levels of ability of the
To address these problems, the SCAN
programmers.
system received static-code analysis data from the HPL compiler and put out
reports for use
various
program control structure
the
module
Then,
control
the coding
in
in
the
These reports analyzed the
graphic form, the program's data structure, and
structure
SCAN checked
review.
and
results
relationship
of
between
modules
these analyses with design
and
data.
information
from ADDS. 9^
The testing-support subsystem was
quality
control
and
intended
simultaneously
productivity
44
to
tackle
by
problems
facilitating
of
the
identification
bugs
of
and,
correspondingly,
the
This subsystem had four objectives.
devoted to testing.
detail the
to
determine the conformance of the program to
was to establish testing standards for
was impossible
--
tools
One was
to clarify
potential
to
its
given program,
a
recognizing that
operating conditions.
automate
as
much
of
Another
specifications.
the
In
addition,
testing
process
evaluate the comprehensiveness of the tests.
as
Cause and Effect Graphs
(CEG),
it
the
as
Several
Automated Generator
of
(AGENT), HPL Test and Debugging system (HPLTD), and
External Test Cases
Test
all
designed
well
as
test
to
subsystem was
other
man-hours
of
design specifications, on the assumption that the test items had
in
possible,
reduction
Coverage Manager
(TESCO)
--
were integrated within the system
to
perform these objectives.^"
Computer-Aided Production Control System (CAPS)
As with
problems.
CAPS focused on
Collection
inspired
by several persistent
managers wanted greater standardization and control
Hitachi
the process flow,
1.
CAPS development was
CASD,
delivery times,
quality,
and overall costs.
In
of
particular,
the following areas:
and
analysis
of
management or process-control
accordance with the structure of
a
data
program
2.
Chronological analysis of each type of process-control data
3.
Imposition of controls on the process limits of design documentation
4.
Japanese character and graphic output through
5.
Multifaceted quality analysis
6.
Construction of
a
a
non-impact printer
data base for actual data and standard times
45
in
7.
Automatic collection of data
8.
Capability
for
on-line
instantaneous
utilization
the
of
automated
output. ^^
The manual
introduced
procedures
computer-aided
1967 and 1976 provided the foundation for
an
initial
and
management
analyzing
and
productivity
1969
both
and
1930,
historical
tools
is
clearly
preceding the start
CAPS,
of
tools
which Hitachi completed
by establishing
and
current
a
means
formal
of
evident
in
of
programmer
on
data
The incremental evolution
management.
project
policies
of major milestones
1967
1977 and
version between
collecting
production-control
Kanagawa Works and then the Software Works between
the
at
and
of
these
the following chronology
CAPS development.
°
Completion of a system for computing labor and machine hours for
software development (Kanagawa Works)
Establishment of standard times for
software development
(Software
Works)
1971
Establishment of programmer
standard times
ability
coefficients
and amendments
of
of an estimation and budget system using standard times
simulation system for resource planning
Completion
and
a
Completion of a PERT Network System
diagramming system for schedule control
Implementation of a manual system for
processing and quality control
1972
1973
(PNET),
time-series
an
automatic
analysis
of
test
Completion of a system for budget- vs -actual expenditure control for
man-hours and machine-hours for each project and department
.
Implementation of
a
manual system for document schedule control
Implementation of
a
manual system for job process control
Implementation
of
a
manual
system
46
for
productivity
analysis
and
control
Completion
1974
of
productivity
a
system for each
analysis
project
and
analysis
and
department
Implementation
1975
of
a
manual
system
defect
for
factor
quality control
Development of
1976
a
time-series
program for forecasting
statistical
(FORCST)
defects
Establishment of
standard scheduling system
a
Implementation of structured design methods
Central
structures;
CAPS was
to
features
improvements
of
the
by requiring programmers
to
use
But successful implementation of the computer-
system
control
depended equally on
several
One was high-performance computing
hardware technology.
in
and clarification of program
standardization
the factory accomplished
this
structured design methods.
aided
the
power, so that numerous programmers could be on terminals connected
to the
same data bases; this was done by installing Hitachi's largest mainframes, the
M-180 and
historical
these with
CAPS
M-200I-I.
data
base
recording
standard times;
(Mass Storage System).
base
management
several
also
systems,
also
system;
this
demanded increased storage capacity
past
Hitachi
filled
ADM
this
this
wanted
gap with
to
make
was achieved through the use
to
formalize
the
large-scale data-
a
the
development of
Managers
(Adaptable Data Manager).
printers that printed Japanese characters
managers
required
efficiently
wanted simple visual graphic output,
process flow;
and comparing
present data,
came through another Hitachi product, MSS
To use MSS
most notably
and
data
for the
as
well
development
it
easier
to
follow
the
of
non-impact laser beam
as
English.
process
for
In
addition,
new software
products and then shorten the time needed for program development; Hitachi
47
has been most successful
a
series
CORAL
and
procedures
of
prototyping
(a
An
example
technology can
Controlling
seen
These
EAGLE and HIPACE,
as
Program
Development
used
are
mixing
primarily
the
in
management
of
incorporation
as
Omon
and
in
and
policy
computer
into
Sakata had earlier decided
it
contemporaries,
wanted
computerized
system that would enable
more
in
determining
first,
ability;
production
actual
standards
job
managers such
as
and,
To
well
to
facilitate
project,
central
to
as
the
accuracy
to
the
classifying
Shibata
these
into
a
estimates
time
Standard times
process.
second,
follow
to
required,
programmers
by
Shibata wanted to be comprehensive but stressed
while
simulate,
incorporate
to
Hitachi
that standard times be as simple as possible,
as
critical
was necessary
and
however,
CAPS.
these accounted for over 90%
standard-time estimates for man-days and computer time.
the
as
and
establish
closely
well
programmer time and machine time was considered
software production costs.
his
with
System),
standard times
of
according to Shibata and Yokoyama,
because,
the applications area,
in
^
this
of
be
Application
tool).
applications subsidiaries.
such
tools
(Customer-Oriented
CANDO
of
accomplishing this
in
covering most of the appropriate criteria.
still
and
so they would be easy to re\ise
utilization
of
the
standard times,
for
each
estimates and actual data were fed as the project progressed into
production data base from on-line terminals.
compare progress
Under CAPS
ca
,
to
1980,
estimates
and
revise
This
estimates
made
data points included the following:
type of object machine (large, medium, small, peripheral)
2.
type
program
possible
during the project.
1.
of
it
a
(control
program,
simulator, etc.
48
on-line
user
control,
generator,
3.
process phase (basic design, functional design, etc.)
4.
degree of difficulty (newness)
5.
production volume (number of steps)
6.
language being used (assembler, COBOL,
7.
machine being used
In
cost overruns and
addition,
and Yokoyama believed,
correct
problem,
this
late
engineers
Hitachi
actual
(1)
working hours
wrote an
the minimum necessary times
software program and
of
result,
scheduling and
manpower needs and schedules automatically.
consideration:
etc.)
deliveries were the
inaccurate daily
of
FORTRAN,
This
Shibata
planning.
algorithm
to
calculate
two factors
took
To
the committed programmers;
into
(2)
required for different phases for each type of
standard times.
Another assumption
Hitachi
at
was
that there was a relationship between the progress of a software project and
its
an ideal system would thus integrate production
quality;
quality
control
automatically
Therefore,
data.
number
the
defects
of
they
likely
designed
for
each
according to the type of program, number of steps,
factors,
management and
CAPS
to
estimate
phase of development,
items tested,
and other
based on actual data.'^^
CAPS
techniques,
programs
relied
completely
and then used
visible.
programs divided
on
base
into modules,
use
of
ADM
control
system designed
ADM
design, testing,
then produced
a
for
structured
(Adaptable Data Manager), automatically
checked actual progress versus estimates, as each module
completed.
programming
structured
design technology to make the structure of
this
A data
the
of a
program was
detailed printout tracking the schedules for
and inspection, with additional information on documentation
49
and quality (errors
found
items
test
in
in
countermeasures
)
the specifications, design documents, or manuals; bugs
and
coding;
Three
.
subsystems
--
bugging, and inspection progress control
and
provided
printouts
additional
CAPS was more than
sense,
provided
served as
As
production
a
with
CASD
output
files
were
source
file;
nor
Hitachi
register
not
did
to the
completed
and
just
was
control
developed
automatically
CASD
also
to
analysis.
In
this
also analyzed data and
it
betvseen
the
in
the
a
CASD
CAPS program
to
CAPS.
major area of development
between 19S3 and 19E3,
systems
two
fully
CAPS production database
For example,
the
not
example,
For
parallel.
however,
'^"^
CAPS was
system,
send corrected modules
automatically
ICAS program.
links
in
sent
to automatically feed data
Int eg rated
ICAS
and
system for production management that
a
quality
but
program modules
CASD, and
daily-schedule
were also integrated within CAPS
--
information
v\ith
Automating the information flow was,
and central
and
tool for quality control.
a
integrated
bugs
of
documentation
for
visual capability for process monitoring;
a
causes
the
of
programming progress control, and testing,
testing preparations and
control,
analysis
making
library
on bugs from
CASD
it
possible
automatically
to
to
from
CAPS.
Comp ute r-Aided Softwar e En gineering System (ICAS)
represented
a
mixture
methods and procedures), but was aimed
methods and computer-aided
tools.
It
of
at
technology
and
standardized
incorporating even more advanced
contained four main features:
(1)
an
integrated methodology for the structuring and abstraction of software, using
a
formal
need
language and graphic notation,
analysis,
requirement
definition,
50
throughout
planning,
a
life
cycle defined as
programming,
testing.
operation and maintenance;
cycle;
(3)
an
programmers
"intelligent"
to
information
of
The basic philosophy
database.
"methodology-free"
tools,
methodology
development
using
of the
personal computer,
a
life-
allowing
use the tools by having dialogues with the computers;
management
complete
(4)
workbench,
phase
for each
interactive tools
(2)
leaving
up
it
the
to
but
phases
all
approach
this
of
employ,
to
for
was
user
present
to
using
decide
to
relational
a
develop
to
and
not
which
on
computer-aided
tools
with a "fixed development methodology of multi-purpose use," allowing users
to
develop
software
quickly
by
using
having to worry
"without
the tools
about which methodology to apply."
Requirements definition involved stepwise refinement
functional,
and
logical
conceptual model,
data
description
and defined functional algorithms with only
three control elements -- sequence,
PAD (Problem Analysis Diagrams).
Several
algorithm
into
simplified
tools
From the
system being designed.
programmers determined the control structure, abstracted
and formed data modules,
functional
the
of
the procedural,
in
repetition,
ICAS
statements
needs
then
written
analysis
and selection
and
automatically
in
a
using PDL or
--
converted
programming
description
(
the
language.
PPDS--Planning
Develop Systems and FRAME--FormaIized Requirements Analysis
Procedure
to
Method),
and
requirements
definition
(RDL/RD (Requirement
Definition
Language/Analyzer)
Design-aid tools
System) and
as
MDL
included
ADDS (Automated
(Module Design Language),
intended
to
automate
coding
documentation and source programs.
and
it
51
and Documentation
already part of
PDL/PAD (Problem Design Language/Problem
was
Design
CASD,
Analysis Diagram).
completely
consisted of
a
integrate
program
as well
PDL/PAD
design
logic design
based on structured programming,
tool,
and
a
to
tool
convert automatically
design documents into high-level language source programs (PL/1), or viceFor example, departments writing
versa.
much
System) was
coding
of
30V
as
TESCO,
and
CEG,
(SEWB)
and
a
infrastructure
discussed
use
to
database stored
these
tools
The quality control portions
being
refined
Works,
methodologies
development
generate
system
Level
support
library. '^°
modules
used
provided
type
before
a
reduce
and
Hitachi
costs
communication
in
an
relational
from
complete
the
use
set
of
an
reusable
locate
interface
Software
within
applications
it
retrieving
the
ICAS
development
Engineering ''°
customized
from
modules
to
systemparts
a
possible
exisitng
parts database.'*^'
integration
for
Approach
automated
while
and
procedures
PAD system, making
designs
ICAS
of
applications
for
(Effective
Productivity),
the
in
Software
Hitachi
in
EAGLE
and
high-level
a
Laboratory,
HIFACE,
to
operation
actual
in
project,
EAGLE
factory-type methodological infrastructure and
technological
facility
The
manner.
already
linked to the
also
modules for other functions from
Even
were
design,
Software
tool
EAGLE was
nev\
provided
Other subsystems
Development
were
important
we'-e
CASD.
of
Software Works
guide
to
(SEDB)
integrated
ICAS
of
part
as
Systems
the
at
High
Achieving
1986
of
Most
software.
to
as
Omori
and
AGEKT,
Workbench
Engineering
Database
an
in
Design
data from each tool input into the computer.'^''
all
Software Works
Software
Engineering
Softvsare
(Database
Test-aid tools included
A
above.
able to automate as
DBDS
addition,
In
'^
for designing databases
tool
a
tasks
COBOL were
in
.
applications
between the company's
52
Hitachi
at
system engineers
factory-
Hitachi's
intended
development
a
HIPACE
by
Omori
HIPACE
to
facilitating
and customers
and
applying
management.
project
procedures to system development and
standardized
well-defined,
It
the
set
process
flow
follows:
as
analysis,
system
planning, system design, program design, program construction, test, transfer
(to
customer),
installation
Data Flow diagrams
and evaluation.
engineers used Structured
First,
(SDF) to analyze customer needs.
Planning Procedure to
Develop System (PPDS) and Standard Procedure to Develop Systems (SPDS)
provided
then
and
documentation
project-management
A
phase of the development process.
worksheets referred
set of
Breakdown Structure (WBS) provided the format for planning
and
To
programming, and testing tasks.
design,
(and
reliability
structured analysis,
engineers
reusability),
HIPACE-SD
structured programming (usually
then
COBOL
or
each
to as
Work
of
the actual
long-term maintenance
used
structured design,
for
in
facilitate
for
standards
HIPACE-SA
for
and HIPACE-SP for
PL/1).^^
The EAGLE system extended the HIPACE methodology by adding four
computer-aided functions:
design
through
database
project
on
testing,
design
(1)
conversational language processing from system
using
understandable menus;
easily
specifications
and
program
a
(2)
implementation,
as
central
well
as
management (tracking information from the standardized work sheets
defined
in
SPDS manual)
the
maintenance;
automated
(3)
system
facilitate
to
construction
of
development
new source programs
standardized patterns ("skeletons") and components (sub-routines);
and
and
from
(4)
automatic compilation of maintenance documentation.
The process
two
steps
recording
the
are
in
a
flow
the
in
using
analysis
of
EAGLE was
data
types
"data dictionary" database;
also clearly
and
this
system design and program documentation
53
defined.
interrelationships
is
in
The
first
and their
followed by registration of
a
specifications
database.
At
point,
this
standardized modules are identified and
nevs
central program parts library,
system being developed,
programs
using
the
if
This makes
applicable.
new and
although
customers,
reused
modules.
EAGLE next generates
standardize.
(module-level)
detailed
The source program
users.
individual
carried out
Hitachi
of
to
it
sells
modules"
"data
that
these
be more difficult
an outline of the program from the
and then produces
a
source program.
add particular functions wanted by
to
commands are automatically generated and
test
(1984-1986)
to
develop the
^
'^
.
EAGLE system have focused
both more flexible for meeting customer needs as well as more
it
factory environment stressing division of labor and maximal
a
standardized
interface
edited
makes
also
EAGLE systems
which tend
conversational language (Japanese)
in
appropriate to
use
then
Finally,
Recent efforts
on making
specifications
is
a
possible to "assemble"
it
company engineers have found
are easier to use than processing algorithms,
to
in
and existing components are identified for the
standardized modules available as products with the
to
registered
been improved;
has
(Customer-Oriented
it
hand,
the
conversational
and the system now handles PL/1 and
Application
Program
language for writing specifications
software makes
One the one
components.
in
Development
Japanese),
in
--
System
addition to
a
CORAL
Hitachi
COBOL.
N'ew
own menus, rather
possible for customers to design their
than use only the ones Hitachi provides, to add unique features to programs
being constructed.
and
The system
data-communications
now be used
also can
programs,
in
addition
to
to
construct data-base
business-applications
programs
EAGLE
has also been modified to work more smoothly
environment,
to
allow
more people
54
to
divide
up the
in
a
tasks
time-sharing
of
system
development and have better access
The
result,
overall
EAGLE
generally
usually
measures
As
period).
by
indicated
of
lines
in
the
code
table
per
below,
"productivity"
in
programmer
EAGLE
also
system design and substantially reduced
For
hypothetical
mean
a
program taking
reduction
in
a
components.
^
in
has
(Hitachi
given
time
shifted
more
a
necessary for testing.
year to develop without EAGLE,
development time
'
that programs designed with
is
improvement
2.2-fold
a
this
into
would
according to Hitachi data,
show
effort
a
to the library of reusable
to
5.4
months,
with
this
testing
being reduced from 4.8 to 1.4 months and program implementation from 4.8
to
1.9 months.
system
automation
of
Around 1986-1987, the Omori Works
using
retrieval for
a
design
automate
some
such as documentation construction,
data
intelligence
artificial
the system engineering tasks,
also introduced
techniques
to
hardware and software configurations, and system simulation
Without
EAGLE
With
.'
^^
EAGLE "*^^
Development
100
(12 months)
45 (5.4 months)
System
Design
20%
(2.4)
38% (2.1)
Implementation
40%
(4.8)
36% (1.9)
Test
40%
(4.8)
26% (1.4)
Program
Another system
Products),
that,
if
which
is
save on
to
a
appropriate for
library
a
of
design
basic
in
development,
shorten
the
is
55
(Applicable
Program
Hitachi will use as a basis for
The objective
time
APP
programs for different applications
particular customer,
building semi-customized systems.
costs
time
of this
required,
and
approach was
guarantee
at
to cut
least
"stable
quality
banks
(on-line
operations."
in
banking,
As
of
credit
1957,
APP core programs
evaluation,
broadcasters; hospitals (accounting);
local
customer
existed for
information);
governments (residents information
systems, library information systems); finance (accounting systems); personnel
management and payroll calculation; videotex; computer- room operations and
control.''^''
V.
ADDITIONA L OR GANIZA TIONAL FLEXI BI LITY
Where Hitachi
to
customer
meet
relied
on
needed more organizational or geographic diversity
has
needs
than
approximately 23
Consultants
Engineering
(ca.
(ca.
2500
2400
Computer Engineering
its
two
subsidiaries.
employees),
employees),
(ca.
software
it
has
The largest were Nippon Business
established
established
1500 employees),
classified these firms into ten groups,
provided,
factories
in
in
1959;
1969;
established
and
in
Software
Hitachi
Hitachi
1982
^
MicroHitachi
with several overlapping:
(1)
General systems and applications software houses
(Nippon Business Consultants, Hitachi Software Engineering, Hitachi
Information Networks, Hitachi Computer Consultants, H/tachi
Computer Engineering; and the regional companies Hitachi Chugoku
Software, Hitachi Tohoku Software, Hitachi Chubu Software, Hitachi
Nishibu Software)
(2)
Industrial-use control systems
(Hitachi
Industrial
Engineering,
Engineering,
Hitachi
Process
Computer
Hitachi Control Systems)
(3)
Semiconductor and micro-computer software
(Hitachi VLSI Engineering, Hitachi Micro-Computer Engineering)
(4)
Information-processing and telecommunications systems
(Hitachi Electronic Service, Hitachi Communications)
(5)
Video and audio equipment, and personal-computer systems and software
(Hitachi Video)
56
(6)
Semiconductors and electronic devices
(Hitachi Electronic Devices)
(7)
Precision instruments software
(Hitachi Instruments Engineering)
(8)
Automotive electronics
(Hitachi Automotive Engineering)
(9)
Robotics, control equipment, and business personal computers
(Hitachi Kyoba Engineering)
(10)
Personal Computers
(Hitachi Micro-Software Systems)
other
addition,
In
produced
factories
Most prominent was the Omika Works,
products.
computers and terminals
that
Hitachi
Hitachi's
in
Omika
also
software
factory producing control
power generation and transmission group
had another thousand programmers writing
software.
a
specialized
real-time
control
industrial
used the versions of CAPS and ICAS, although these
had to be modified for the different architecture of the control computers.
There were also several hundred programmers
switching
systems
automation
software
software,
A brief discussion
Hitachi
with
a
tools.
of
group has managed
disciplined
development.
worked as part
factories,
to
Kanagawa Works,
Totsuka and
Both
design
writing
Software Engineering illustrates
combine
flexibility
Kanagawa
of
this
subsidiary
permanent workforce
in
how the
serving customer needs
in
and manufacturing
engineering
the
the Totsuka Works writing
""^^
Hitachi
Some sections
of
the
at
computer hardware.
for
CAPS and CASD
used the
and
at
of
approach
to
software
some 2500 employees
Hitachi's
in-house software
while other groups did customized systems development for
variety of Japanese customers.
57
a
wide
The company was organized around design departments
specific industries or applications,
Unlike the Omori Works,
sections specializing
financial systems or hospital systems.
detailed design
ovs n
and coding,
although
implementation as opposed to systems engineering did
in
Program
department.
each
in
in
there were no separate implementation departments;
departments did their
the design
exist
link
specialized
and
libraries
reusable parts
were also developed for specific industries or applications,
databases
corresponding
to
the departmental organization structure.
There was
the
functional
software
Hitachi
customer
a
had,
division
factories;
relative
where the customer
has
Software
a
Engineering.
expertise,
of
lot
including
how much expertise the
depended on
this
Hitachi
to
the customers,
labor with
of
Hitachi
some
In
cases,
Engineering
Software
would receive only functional specifications and then do the detailed design
and
program construction.
Works,
which
This
considerable
had
was
done on
expertise
in
occasion
system
the
with
engineering;
Omori
Hitachi
Software Engineering would then serve as the "factory" to construct and test
the actual program.
In
the
Engineering's
view
distinguished
Yoshiharu,
RlD department,
manager,
software
Matsumoto
of
a
it
was
"factory
not
and
Matsuzaki
necessarily
approach"
manager
from
a
the
Hitachi
of
Yoshizo,
an
division
of
non-factory
Softv\are
applications
labor
approach.
which
Their
philosophy, and that of managers such as Shibata Kanji and Nokoyama Yoichi
in
Hitachi
quality,
Software Works,
was that the degree
and costs determined whether
organization or not.
In
particular,
a
of
control
product was made
over processes,
in
a
factory-like
;ign
Hitachi managers emphasized their design
j
The
J
review procedures along with extensive (and expensive) bug analyses
58
used
strategy
basic
reviews
design
careful
bugs
eliminate
to
beginning with
design phases to catch bugs early
tasks such as coding,
and then
to
Hitachi
Software
Engineering
test
until
FORCAST program
use of the
(3)
applied
usually
served
as
a
its
CAPS,
HIPACE,
and
methods
and
tools
company reported
and
99%
at
This
estimates.
but
in
an
1981
that
actual
with
lines.) '^°
this
compared
to
between
in
other cases, they
In
from
90%
and
such
Hitachi
systems.
110%
on
original
300%-overruns during the early 1970s.
lines of code;
The
projects
the
of
as
Hitachi
project control.
complete 98% of
to
for
(The
the largest were about 500,000
Control was exercised through separate databases for manpower,
and project management;
was
defects
of
manpower souce
in-house
several
was able
it
cost
average project size was 50,000
bugs,
to
employees followed the
transferred
Software Engineering was also remarkably efficient
time
numbers
the predicted
Software Works or Omori Software Works,
CASD,
detailed
elimination of boring
(2)
factory practices and used the tools at these facilities.
still
and
(1)
'
When
Hitachi
and
levels
are found.
elements:
specification
functional
development;
in
three
of
through automatic code generation from PAD diagrams
or from reusable software modules;
predict bug
consisted
in
these were not yet linked
the planning stage.
As
in
data input procedures were automated,
As did the Hitachi factories,
Hitachi
1987,
in
Software Works,
some
though
of the
and others manual.''^
Hitachi
Software Engineering emphasized
extensive programmer training (1-year training periods, including 2 months of
off-the-job
training
implementation
of
when they entered the company),
top-down,
structured
budgets and project management,
design
and
as
well
careful
as
strict
controls
on
including standard times for programmers
59
(design and coding).
up
setting
at
the subsidiary focused first on
and production auditing system
project
a
managers
Historically,
(1969-1975);
applying
structured
programming techniques
productivity
improvement and quality assurance through the standardization
of
and
methodologies
patterns"),
their
applications,
and
relied
cataloging
utilization
addition
In
on
a
separate
message format
processing,
library
included
programs,
related
in
well
as
and
specialized
libraries
patterns
as
for
parts"
checking,
contents
that
mainframe
such
functions
for
Software
Hitachi
"common
for
message editing and switching,
and
modules
the writing of new programs.
libraries,
(1976-1978);
tools
productivity
reusable
of
program
in
program
to
These
modules.
generation
the
software
and
(1979-1981);
tools
through
improvement
and
data-base
screen
("standard
for
different
^^
Engineering
served
operating
as
quality
reusable
as
systems
message
and
reception,
management
mapping,
also
system
line-overflow,
error displays, program-function key code analysis, screen editing, and table
Some managers assigned programmers exercises on
"look-up."
basis
to
make them
familiar
with
subroutines
stored
in
A Production Engineering Center was responsible
libraries.
new modules recommended by project managers for registration
The company
library.
particularly
actual
reuse
into the
useful
also
modules,
rates).
Through these
to
monthly
program
the
for screening
in
the parts
programmers who registered
based on an analysis of the specifications
programmers were encouraged
(not
In
general,
at
the design stage (between functional specifications
reuse library
and detailed design),
gave out rewards
a
to
policies,
determine
as
well
as
all
if
to
look
there may be parts they could reuse.
the use of tools such as
Software Engineering was able to increase reuse rates from
60
EAGLE,
a
level
Hitachi
of
10 to
20%
in
early
the
1980s
about
to
40%
in
depending
1987,
on
the
department. ^^
the
Since
activites
of
numerous areas and customers,
base for production control.
since
customers,
programs. 1 9T
the
not have
did
it
Engineering
a
rigid
spread
across
company data
centralized
Standards were also frequently determined by
company was dedicated
Nonetheless,
management strategy was
Software
Hitachi
an
and
integral
producing
to
clearly
customized
component
stated
discipline throughout the firm.
In
the
fact,
two managers who spearheaded the development of production technology
subsidiary,
this
admitted
to
the
after
use of
moving over from
Hitachi
Software Works,
of
at
openly
extensive training techniques to make programmers
comply with company standards for program design: "To meet our production
project
criteria,
employees.
procedures
any
If
modules
have
been
deviate
from
and
standardized
the
coding
imposed
standard,
they
on
are
returned to the production line."'^-
CONCLUSION
did
Hitachi
as
much
as
not
impose standardized practices or emphasize
some other firms because
and the diversity of
significant as
and structure
its
customers,
the broadness of
of
even within single
manage the process
of
large-scale
Much can be learned about the patience required
of
a
new and complex
product
and
experience.
61
process
to
product
Yet
facilities.
the first company to introduce successfully
to
its
reusability
a
lines
it
is
factory strategy
software development.
rationalize
technology
management
from
Hitachi's
Intervievss
managers
documentation
v.ith
indicate
that
and
study
a
Hitachi
and
technical
of
historical
movement tov>ard the factory
s
model
resulted from three interrelated strategies:
1)
A company
policy
independent factories
establishing
of
(which included
both product engineering and mass-production functions) for each major
product area.
2)
the part of managers
Belief on
level
strategy,
well
as
responsible for corporate- and division-
software development,
for
as
that
centralized
a
and disciplined factory environment, integrating product engineering and
mass-production
offered
activities,
any
for
improving worker productivity and quality,
product
as
well
the
potential
of
project and cost
as
control
3)
Top management decision
executives and,
a
apply
to
management controls
history
foundations
between
of
and
could
the
company- wide
a
should
be
to
technology
and
Works
Software
were
factory
methodological
primarily
policy
programmers
to
technology or
tool
use
tool;
this
as
di\'isional
controlled
--
in
a
making
it
and
accounting
software engineering activities.
all
Hitachi
of
standardized
,
was
the
since
it
was
standard
also
indicates
introduction
of
Structured
necessary
procedure,
the
that
Somewhere
policy-oriented.
programming technique during the mid-1970s.
really
(including
any other product the company manufactured
as
necessary
The
commitment
the company president) to treat software as
whose development
product
factory,
especially,
and
structured
a
programming
to
train
the
use
in
and
of
is
require
this
new
involved critical policy decisions and implementation. This
62
was
because
important
especially
became the foundation
Hitachi
and
accounting,
support
general
the
of
production-control
systems,
well
as
by
defined
as
standard-times,
factory's
The rather sophisticated
tools.
programming
structured
(computer-aided)
costspecific
as
technological
infrastructure evolved after the basic policy infrastructure, but rapidly, from
a
few
tools
at
first
extensive
an
to
set
systems
interrelated
of
that
are
Hitachi
and
increasingly being further integrated.
A contrast between implementation
the
experiment
offers
at
System
some suggestions
Development
system containing
the factory model
Corporation
SDC attempted
both
a
in
at
mid-1970s
the
why one company might succeed
regarding
than another at this approach.
factory
of
technological
also
better
to introduce simultaneously a
infrastructure
and
a
policy
infrastructure (set of standard procedures covering system-analysis, design,
implementation,
testing,
and
(central
production database,
testing
tools,
etc.)
was
project-management).
technology
the
program library, automated documentation and
there,
environment and
standardized
While
programmers
dislike
to
programmers'
other
reusing
seemed
Perhaps
code.
more important was that project managers disliked giving up control
factory
work for the
and
dismantling
engineers
of
to
this
infrastructure through
the factory
different
dwindled;
facility
sites
to
develop
Hitachi,
policy
on
the
infrastructure
other
over
programmers and managers
like
environment.
hand,
a
incrementaly
period
of
several
to operate within
a
eventually
the dispersal
programs,
divide labor or reuse modules as once envisioned
led
with
in
little
of
to
the
to
the
systems
capability
the factory concept.
developed
years,
the
and
to
imposed
thereby
9S
1'^"^
a
training
highly standardized, factory-
Hitachi modified these procedures gradually and then from
63
the mi-1970s began
systems
to
--
investing heavily
and large-scale computer-aided
tools
in
the factory-type technological infrastructure.
technology-based
innovating
in
process
and
tools
automation
came
thus
management by applying
This shift
successfully
after
standardized
a
focus
in
approach
to
both system and applications softvsare development.
One might
for
cited
physical
identify
excellence
its
automaker
also
has
a
consistently
productivity
in
demonstrated
the performance of human workers.
technology
its
is
world
agreed
sufficiently
to
The comparison with Toyota,
that
benefits
case
in
in
technology,
in
use
to
extend
to
but
only
(such as programmable robots) to
as
well
as
the
if
the
into
fit
human workers.
of
SDC
reinforces
case,
necessarily
bring
many
as
The
the
Hitachi
and
strategy to assure the compliance of managers
and
that,
engineers or other programmers,
advantages
of
policy
suggests
a
Japanese
levels
as flexible tools,
simply better process management.
productivity as
including
highest
more automation,
advances alone do not
technological
software
s
largest
Only after these policy innovations have
introduce
flexible
well
as
manufacturing system and supplement the efforts
notion
The
computer-based systems, preferring instead
focus on process control and innovation,
managers
the
company often
a
automobile manufacturing by deemphasizing the
of sophisticated automation or
Toyota
Toyota,
management.
production
in
here with
parallel
efficiency.
with
the
proper
mixture
the factory approach
As suggested
in
of
should offer several
the first paper from this research
project, these might include the following:
Institutionalization
or
dissemination
64
of
"good"
technologies
and
programming or manaqefnent practices.
The production engineering departments
as
well
and
techniques
formal
that,
in
are
were responsible for introducing
textbooks
considered
widely
models;
documentation
project-management
and
programming
software
on
standardization
design-review
fundamentally
be
to
These include structured design methods;
and
collection
tools
management,
engineering
practices.
programs,
the factory training
as
software factories,
Hitachi's
in
and
good
bug-forecasting data
and
control
program
systems;
systems;
libraries;
wide use of computer-aided design, coding, and testing tools; and promotion
of standardization of practices
and reusability
of
code where possible.
Providing a sufficient scale of people and operations to justify research
and development for improving process technology and techniques.
In
Hitachi
addition
also
activities
to
used
related
centralization
of
engineering
the
to
System
departments
Development
programming
software
support
production
at
the
in
the
software
Laboratory
tools
and
to
factories,
perform
methods.
Software Works
provided an in-house core of 3000 programmers and supporting
and
staff;
R%D
The
Omori
Hitachi
Software Engineering and Nippon Business Consultant added another 5000.
Improving process efficiency through teamwork and better inter-qroup
communication.
65
This can be seen
projects
two examples.
Software Works
the
in
in
The figure
1985.
and 1979,
1974
in
was
19S6
for
is
with
about
1970 to 13%
in
average
an
these figures
late
projects
example,
procedures,
Software),
and
when
as
Hitachi
mainframe
new
a
well
made
it
as
benefits
programmers
added
level
was
in
this
and
within
new
a
late
But,
tools.
overturning
project
1974-
causing
of
with
new projects
general,
in
for
reporting
process-control,
Another example
Brook's
projects
--
more
Control System for
to
factory environment allowed Hitachi managers to add people
law
be
about
later.
(albeit
people available and not just anyone) to help finish projects on time.
66
a
Variations
the factory,
large
system.
support
1973 and to
category.
integrate manpower-control,
Hitachi's
to
completing
in
years of
fevs
12% during
of
CAPS (Computer- Aided Production
functions
is
activity
of
operating
possible to
quality-control
factory
the
reflect
a
These numbers placed Hitachi
5%.
Software VNorks along with other firms leading
in
that the percentage of late
dropped dramatically within
from over 72%
the founding of the factory,
remarkably low 7%
One,
of
the
more
The
the best
HITACHI SOFTWARE WORKS: PERFORMANCE DATA
Year
O rg anization a
on
foc u s
l
enq m ee rinq p rod u c
ra isinq
and product
ivitv
q uality (defect control)
As indicated
Software Works
in
the table,
doubled within one year
promoted
Improvement
movement
and
analysis
the
started
in
and
system
implementation
the
has
gleaning
practice,
measures
of
to
as
the mid-1960s
made
also
it
improve
possible to track
the
form.ally
The central production data base
performance and product quality.
factory
opening and
factory's
Company-wide and factory programs, such
are proprietary.
Management
the
of
in
although direct productivity figures for the
increased significantly overtime,
facility
productivity of Hitachi employees
sales
labor
for the
programmer
productivity as well as defect measures, and thereby have precise data tc use
in
determining
throughout
the
technological
specific
and
or
Perhaps
factory.
infrastructures
and product control
design,
methods
in
most
for
the
in
example,
use, or whether to develop
also
save
extensive
important,
the
--
tools
area
manpower,
product
of
a
in
which
automating
and
quality,
standardization,
--
facilitate
do not ha\e to expend
languages or methods to
particular support tool.
manpower by
used
be
process,
engineering
Individuals
deciding
to
administrative
the area of production management;
in
inspection
and energy,
new
the factory
of
performance analysis and improvement.
time
developing
Systems such
much
of
testing
EAGLE
as
and
by
recycling program components.
In
quality,
Hitachi
employs
a
measure
has reduced bugs from an index of 100
estimate
is
that
this
figure
program package per machine
in
represented
installation
68
of
user- reported major bugs and
1978 to 14
in
1985.
approximately
0.01
One
unofficial
defects
per year, and placed Hitachi
in
per
the
low
along with other leaders
category,
^'
the survey.
factors:
this
in
measure that participated
According to Shibata, the decrease
in
bugs reflected several
new System Simulation Tester (SST) completed
a
in
1977-1979;
in
CASD
(Computer-Aided Software Development System), another group-programming
to
tool
product
facilitate
reused
functions;
code,
standardization,
reaching
design
and
support,
approximately
90%
new
in
inspection
releases
of
products such as operating systems; and increasing sales of essentially bugfree programs. '^°
Reducing waste and
redundancies
due
to
dysfunctional
behavior of
individuals and the lack of an organizational strategy.
High-level factory managers such as Sakata,
from the engineering department such as Shibata,
for
personnel and technological development
initial
focus
has
factory
Later
efforts
infrastructure
possibility of
managers
as middle
have set
a
clear direction
Their
the Software Works.
been on gathering information on software technology and
then standardizing methods and tools,
goals.
in
as well
and setting factory-level performance
have focused on
and
strategy
automation
they
and
have created
individuals duplicating the efforts of others
reusability.
has
in
reduced
tool
The
the
or method
development, as well as writing code, and lessened the likelihood of workers
engaging
to
in
develop
methods that
practices
reusable
that are contrary to the organizational
modules,
or
facilitate reusability,
use
factory-wide
tools
and
goals
standardized
maintenance, testability, and the
69
such as
like.
Maintenance of o r ganizat ion al and technic al "flexibility."
Both
the
factories
softvtare
and
technological
have
been
infrastructures
policy
evolving
since
of
Most
1969.
developed for Hitachi Software Works (and then introduced
such as CAPS,
or subsidiaries),
facilities
the
of
in
the
linkages between
systems,
documentation, testing, and the
CASD, HIPACE, and EAGLE, ha\e
well
over
a
decade.
or increased capabilities of adapting to
Structured design
in
the
to
a
also
endured
program library are not obsolete.
the factory approach might seem to make
respond
has
for
High levels of reusability indicate as well that Hitachi
programmers find modules
to
such as
the addition of other support tools for
like,
non-standardized customer needs.
tools
other Hitachi
been adaptable enough to incorporate important technical advances,
additional
Hitachi
unique
customer
need
it
or
difficult
a
for
specific
a
While
particular facility
type
of
technology,
Hitachi has been addressing these concerns through continued development of
cu stome
r
-
or ien ted
design
systems
such
as
EAGLE,
as
well
as
the
establishment of numerous subsidiaries and new factory departments such as
for artificial intelligence.
70
REFERENCES
1.
The current version of the main paper from this research project is titled
A. Cusumano, "A Comparison of U.S. and Japanese Software
Michael
Implications for Strategy, Technology, and Structure,"
Facilities:
Sloan
1987 Working Paper #1885-87 Revised 9/25/87.
School of Management
Another completed case is "A U.S. 'Software Factory' Experiment: System
Development Corporation." Sloan School of Management 1987 Working Paper
.
.
#1887-87.
2.
Toyo
Kaisha shikiho (March 1986).
Keizai,
Japan Economic Journal, 7 June 1986, p. 14; and, for market share data,
"Nihon no konpyuta setchi jokyo," Coniputer Report (in Japanese), January
3.
p. 78.
1985,
Hitachi Ltd., "Introduction to Hitachi and Modern Japan" (International
Operations Group, 1983); Tadao Kagono et al.. Strategic vs. Evolutionary
Management:
A U.S. -Japan Comparison of Strategy and Organization
(Amsterdam, North-Holland, 1985), pp. 103-105; Takahashi interviews.
4.
5.
Japan Economic Journal
,
7
June 1986,
p.
14.
6. Dale F. Farmer, "IBM-Compatible Giants," Datamation
96-97, 104.
New Computers from IBM
7.
"2
p.
D5.
.
December
The New York Times
Rival,"
.
12
1981, pp.
March 1985,
A useful book in Japanese on the details surrounding this incident is
Nano Piko, Nichi-Bei konpyuta senso: IBM sangyo supai jiken no teiryu (The
Japan-U.S. computer war:
underlying the IBM industrial spying incident)
(Tokyo, Nihon Keizai Shimbunsha, 1982).
8.
9.
RCA, Control Data, IBM, and NCR
in
1958.
all delivered transistorized computers
See Franklin M. Fisher, James W. McKie, and Richard B. Mancke,
IBM and the U.S. Data Processing Industry:
An Economic History (New
York:
Praeger, 1983), pp. 50-51.
For the Japanese story, see Sigeru
Takahashi, " "Early Transistor Computers in Japan," Annals of the History of
Computing Vol. 8, No. 2, April 1986.
have also interviewed Dr. Takahashi
extensively on computer development in Hitachi, beginning on 9 and 21
I
,
January 1985.
10.
Takahashi interviews.
11.
Shibata interview, 9/19/85.
12. Hitachi Seisakusho, Yuka shoken hokokusho
March 1985, pp. 16-17;
Hitachi Ltd., "Outline of Hitachi. Ltd." (1984); "Introduction to Hitachi and
,
Modern Japan,"
13.
These
will
p.
12.
be discussed
in
a
later section.
71
A recent book on the Ml movement at several Hitachi factories
(although not inducting the Software Works) is lv.ai Masa^azu, Hitac hi-shiki
Ml undo no kenkyu (Tokyo, Daiyamondo-sha, 1SS3.
keiei kaku s hin:
14.
15.
Hitachi Seisakusho,
of the
16.
Sofutouea koj o no 10-nen no ayumi (10-year history
Software Works) (Kanagawa, 1979), pp. 118, 179-184.
Sofut o uea Koio
,
p.
198,
202.
17. Nihon N'oritsu Kyokai (Japan efficiency association), ed., Hit ach
no
leisan k akum ei-- MST seis an ^shisutemu n o zenbo (Hitachi's production
revolution -- the full story of the MST production system) (Tokyo, 1982), p.
MST stands for "Minimum Stocks/Minimum Standard Time.
32.
i
18.
Shibata and Nokoyama interview, 7/23/86.
19.
Sofutouea Koio
20.
Takahashi interview.
21.
Sakata interview.
22.
sha,
Minamisawa Noburo, Nihon konpyuta h atta tsu-sh
1978), chronology.
23.
Shimada Shozo,
,
pp. 51-52.
See also Sofutouea Kojo
"Hitachi
no gijutsu
tables on pp.
,
i
(Nihon Keizai Shimbun-
kaihatsu-ki
(2);
49-50.
(HITAC 5020)--
HITAC
N'uza Henshu linkai, ed.,
20 nen n o ayumi (Hitachi
Ltd., 1983), pp. 27-29. Also, Murata Kenro, "Hitachi no gijutsu: kaihatsu-ki
(HITAC 5020, 8500) -- hadouea," in HITAC Yuza linkai, p. 22.
sofutouea,"
in
24.
Usui Kenji,
25.
Takahashi
Computopia
,
"HITAC kaihatsu
interview,
July 1975,
p.
shi
(2),
p.
37.
"HITAC kaihatsu
1/9'85; Usui Kenji,
37; Sofu touea Kojo,
p.
shi
(2),"
53.
Hitachi Seisakusho, Kanagawa koj o 15-ne n no ay umi (1978), p. 40. Since
to build upon the RCA operating system, the mainframes
Hitachi has sold in Japan after 1970 are close to IBM but not compatible,
although machines Hitachi produces for export and overseas sales through
National Semiconductor are modified to be fully IBM compatible.
26.
EDOS continued
54-56.
27.
Sofutouea Kojo
28.
Sofutouea koi o, pp. 56, 130.
29.
Hitachi
memo
,
to
pp.
Cusumano,
30. Takahashi Shigeru
interview, 9/1/87.
21
August 1985.
interviews,
1/9/85,
72
1/21/85,
9/10/85;
Yokoyama
31. Hitachi Seisakusho, Hitachi Seisakusho shi Vol. 3, 1971, pp. 55-56, 223224; Usui Kenji, "HITAC kaihatsu shi (2)," pp. 36-38; Kanaqawa koio 15 nen
.
no avumi (1978), pp. 45-47.
32.
Minamisawa, pp. 154, 163.
33.
Usui,
"HITAC kaihatsu
shi
(2)," p. 36;
34.
Usui,
"HITAC kaihatsu
shi
(2),
35.
Usui (2), p. 31; Sofutouea koio, pp. 50-51; Takahashi interview, 1/9/85.
36.
Sakata interview, 9/10/85.
37.
Usui (2), pp. 36-37; Sofutouea koio
38.
Sofutouea koio
Sofutouea
,
p.
kojo,
30. Footnote other sources.
:
pp.
17,
129.
23.
pp.
translation Hitachi uses is
"works" ( koio) is usually
An analysis
Japanese.
39.
p.
Sakata interview.
21-22;
Kanaqaw a,
pp.
18-22,
69.
The English
"Software Works," although the Japanese word for
translated as "factory" and has this connotation in
of the Odawara Works can be found in Hitachi
Seisakusho Odawara Kojo, Odawara Kojo 10 nen shi (Kanagawa-ken, Hitachi
Odawara Kojo, 1977).
pp. 4-5, 8;
Yokoyama interview, 9/1/87.
40.
Sofutouea kojo
41.
Shibata interview, 9/1/87.
42.
Sakata interview.
43.
Sakata interview, 9/10/85.
44.
Sakata interview, 9/10/85.
45.
Shibata interview, 9/19/85.
46.
Shibata interview, 9/19/85. See also Sofutouea koio
47.
Sofutouea koio
48.
Shibata interview, 9/19/85.
49.
Shibata interview, 9/19/85; and Sofutouea koio
50.
Shibata interview, 9/1/87.
,
,
p.
,
p.
5.
113.
,
p.
119.
Sofutouea kojo Shibata interview, 9/1/87; Hitachi Seisakusho, "Hitachi
Omori Sofutouea Kojo annai" (Introduction to Omori Software Works) (ca.
51.
;
1987).
52.
Sofutouea Koio
53.
Hitachi Software Works,
,
p.
192.
Memo, July 1986.
73
This is a general sketch of the factory's organization based on "Omori
Sofutouea Kojo annai," pp. 6-7, 11, and Sof utoue a koio p. 200.
54.
,
55 Shibata interview, 7/23/86; and Sofutouea
contains organization charts from 1969 to 1979.
57.
Sofutouea koio
58.
Sofut ouea koio
,
59.
Sofutouea koio
,
60.
Sofutouea koio
,
61.
Sofutouea koio
p.
,
192-202,
which
128.
pp.
164-165;
Shibata interview, 9/19/85 and 7/23'86.
pp.
160-161;
118-119;
pp.4-11,
p.
,
pp
,
127-128.
pp
56 Sofutouea koj o,
kojo
Shibata interview, 7/23/86.
165.
156.
Sofu touea kojo
pp. 113-114; Hitachi Memo, "Table 1: History of
Production Control at Hitachi s Softv.are Works"'; Sakata interview; Shibata
interview, 9/19/85 and 7/23/85.
62.
63
,
Sofutouea kojo
.
,
p
.
114.
64.
Sakata interview; Shibata interview, 9/19/85 and 7/23/87.
65.
IntervievNS with Shibata
66.
Shibata interview, 9/19/85.
67.
Sofutouea koio
68.
Shibata interview, 9/19/85.
69.
Sakata interview.
,
pp.
and Yokoyama
114-115.
Frederick P. Brooks, Jr., The Mythical Man-Month
Essays pm
Eng neering (Reading, MA, Addison-Wesley, 1975), pp. 16, 31.
70.
:
Softvsare
i
71.
Shibata interview, 9/19/85.
Sakata interview. Also see Sakata Kazuyuki, "Sofutouea no seisan kanri
okeru yosoku giho no teishiki-ka -- sei-teki na yosoku oyobi koshoritu
suii moderu" (Formulation for Predictive Methods in Software Production
Control -- Static Prediction and Failure Rate Transition Model), pp. 277-283,
and "Sofutouea no seisan kanri ni okeru yosoku giho no teishiki-ka -- doteki
na yosoku: sakidori hyoka giho" (Formulation for Predictive Methods in
Software Production Control -- Dynamic Prediction: Quality Probe), pp. 284291, in Denshi tsushin gakka ronbun shi (Transaction of the institute of
electrical and communications engineers. May 1974, Vol. 57-D, No. 5.
72.
ni
i
73.
Shibata interview, 9/19/85.
74
74.
Sofutouea kojo
115.
based on Hashimoto Yaichiro (Hitachi Software Works)
hinshitsu hyoka shisutemu 'SQE " (Software Quality
SQE ), Hitachi hyoron Vol. 68, No. 5 (May 1986), pp. 55-
75. This discussion
"Sofutouea
et al.,
Estimation System
p.
,
is
.
58.
See Michael A. Cusumano, The Japanese Automobile Industry:
Technology and Management at Nissan and Toyota (Cambridge, MA., Harvard
University Press, 1985), Chapter 6. There are also several other articles and
books on Japanese quality control practices, such as by Robert Cole and
Richard Schonberger, that support this observation as well.
76.
77.
Sofutouea kojo
78.
Shibata interview, 9/19/85.
79.
Sakata interview.
80.
Sofutouea kojo
,
,
p.
115;
Shibata interview, 9/19/85.
pp. 117-118.
For applications software sold outside the
company, the design departments took until 1975 to set their own standards
for both customer estimates and the program-development process.
Kataoka Masanori, Domen Nobuyoshi, and Nogi Kenroku, "Sofutouea kozo
sekkei giho" (Software Structure Specification Method), Hitachi hyoron Vol.
62, No. 12 (December 1980), pp. 7-10.
81.
.
Definitions of reused code:
Project Reuse Rate = Number of Reused
Steps divided by reused steps plus new steps plus revised steps times 100.
Cumulative Reuse Rate = Cumulative Number of Reused Steps from Version
divided by Number of Steps in Current Version times 100. Shibata interview,
7/23/86.
82.
I
Yokoyama interview.
83.
Sofutouea kojo
.
p.
84.
Sofutouea kojo
,
pp. 7-8, 124.
85.
Shibata interview
86.
Sofutouea kojo
87.
Shibata interview, 9/1/87.
88.
Hitachi
,
p.
117;
124.
memorandum, "Table
1.2
Background and Conditions Affecting
CAPS Development."
Regarding ICAS, see M. Kobayashi et al., "ICAS:
An integrated
Computer Aided Software Engineering System," IEEE Digest of Papers-Spring '83 COMPCON (IEEE, 1983), pp. 238-244; and Kobayashi Masakazu and
Aoyama Yoshihiko, "Sofutouea seisan gijutsu no saikin no koko" (Current
Topics in Software Engineering), Hitachi hyoron Vol. 68, No. 5 (May 1986),
89.
.
pp.
1-6.
75
90.
Interviews with Shibata and Yokoyama, 7/23/86 and 9/19/85.
Kataoka Masanori, Hagi Yoichi, and Noqi Kenroku, "Sofutouea kaihatsu
shien shisutemu (CASD shisutemu)" (Computer Aided Software Development
System, CASD), Hitachi hyoron. Vol. 62, No. 12 (December 1980), p. 33.
Kataoka and Hagi were from the Software Works; Nogi was from Hitachi's
91.
System Development Laboratory.
92.
Interviev\s with Shibata
and Yokoyama, 7/23/86.
Kataoka Masanori, Hagi Yoichi, and Nogi Kenroku, "Sofutouea kaihatsu
shien shisutemu (CASD sh'sutemu)" (Computer Aided Software Development
System, CASD), Hitachi hvoron Vol. 62, No. 12 (December 1980), p. 33.
93.
.
pp. 33-34.
94.
Kataoka
95.
Kataoka, p. 34.
96.
Kataoka
al.,
et
pp. 35-36.
al.,
et
Shibata Kanji and Yokoyama Yoichi, "Sogo sofutouea seisan kanri
shisutemu 'CAPS " (Computer Aided Production Control System for Software),
Vol. 62, No. 12 (December 1980). p. 37.
Hita chi hyoron
97.
,
98.
Hitachi
memorandum, "Table
1.2
Background and Conditions Affecting
CAPS Development."
Shibata Kanji and Yokoyama Yoichi, "Sogo sofutouea seisan kanri
shisutemu 'CAPS'" (Integrated computer-aided production control system for
software 'CAPS'), Hitach hvoron Vol. 62, No. 12 (December 1980), p. 37;
Hitachi memorandum, "Table 1.2 Background and Conditions Affecting CAPS
Development"; Shibata interview, 7/23/86. Omori makes greater use of
prototyping, which produces overall specifications of a program before the
actual modules and code are fully written. In systems software, Shibata has
felt that prototyping is not practical, since it requires too much time and
99.
i
.
effort.
100.
Shibata and Yokoyama,
pp. 39-40.
A version of CAPS was availabiefor
101. Shibata and Yokoyama, p. 40-42.
microcomputers and used at Hitachi's Omika factory, which designed systems
software for control computers, as well as at subsidiaries such as Hitachi
Software Engineering and Nippon Business Consultants. The s\ stem was not
sold commercially.
(Shibata interview, 7/23^86.)
102.
Shibata and Yokoyama,
103.
Interviews with Shibata and Yokoyama, 7/23/86.
p.
42.
104. Interview with Matsuzaki Yoshizo,
Hitachi Software Engineering, 9/3/87.
76
Applications
Software
Manager,
105.
Kobayashi et
al.
Interviews with Shibata and Yokoyama, 7/23/86 and 9/19/85. Regarding
HIPACE, see "Apurikeshon shisutemu no koritsu-teki sekkei giho 'HIPACE'"
106.
(Software Engineering Methodology for Development of Application Systems
'HIPACE'), Hitachi hvoron Vol. 62, No. 12 (December 1980), pp. 15-20; for
EAGLE, see Hagi Yoichi et al., "Shisutemu kaihatsu shien sofutouea 'EAGLE'"
(Integrated Software Development and Maintenance System 'EAGLE'), Hitachi
hvoron. Vol. 68, No. 5 (May 1986), pp. 34.
.
107.
Matsuzaki interview, 9/3/87.
Tsuda Michio, Senior Engineer at Omori Software Works, written
response to "Large-Scale Applications Software" survey, 2/20/87; and
Takahashi Tomoo, Department Manager at Hitachi Software Engineering,
written response tot "Large-Scale Applications Software" survey, 3/6/87.
108.
109. Miyazoe Hidehiko (Hitachi Software Works) et al., "Apurikeshon
shisutemu no koritsu-teki sekkei giho 'HIPACE'" (Software Engineering
Methodology for Development of Application Systems 'HIPACE'), Hitachi
hyoron. Vol. 62, No. 12 (December 1980), pp. 15-20. Also see Nakao Kazuo
Hitachi System Development Laboratory) et al., "Shisutemu keikaku no tame
no shisutemu yokyu bunseki shuho 'PPDS' no kaihatsu" (System demand
analysis procedures for system planning PPDS), Hitachi hyoron. Vol. 62, No.
12
(December 1980), pp. 21-24.
110. Hagi Yoichi (Hitachi Software Works) et al., "Shisutemu kaihatsu shien
sofutouea 'EAGLE'" (Integrated Software Development and Maintenance
System EAGLE), Hitachi hvoron Vol. 66, No. 3 (March 1984), pp. 19-24.
.
Hagi
"Shisutemu
kaihatsu shien sofutouea 'EAGLE'-(Integrated Software Development and
Maintenance System 'EAGLE' - the Enhanced Version of EAGLE, EAGLE 2),
Hitachi hvoron Vol. 68, No. 5 (May 1986), pp. 29-34.
111.
Yoichi
et
al.,
EAGLE kakucho-han 'EAGLE 2"
.
112.
"Omori Sofutouea Kojo annai," pp. 14-15.
113.
Source for this table
114.
"Omori Sofutouea Kojo annai," pp.
is
Hagi et
al.
(1986),
p.
34.
10-11.
See Hitachi Seisakusho, "'86 shisutemu/sofutouea no Hitachi gurupu"
(The '86 Hitachi group for systems and software)
115.
116.
Shibata interview, 9/1/87.
117. Interviews with Matsumoto Yoshiharu,
R&D Department Manager;
Matsuzaki Yoshizo, Applications Software Department Manager; and Takahashi
Tomoo, Applications Software Department Deputy Manager, Hitachi Software
Engineering, 9/3/87.
118.
Denji Tajima and
Tomoo Matsubara
Computer Software Industry
in
(Hitachi Software Engineering), "The
Japan," Computer May 1981, p. 95.
.
77
119.
Matsumoto interview,
9.'3/87.
Denji Tajima and Tomoo Matsubara, "Inside
Industry," Computer March 1984, pp. 36-39.
120.
the
Japanese Software
,
and Tomoo Matsubara, "Inside the Japanese Software
Industry," Computer March 1984, pp. 36-39.
121.
Denji
Tajima
,
RE.D Department Manager;
122. Interviev\s with Matsumoto Yoshiharu,
Matsuzaki Yoshizo, Apphcations Softvvare Department Manager; and Takahashi
Tomoo, Applications Software Department Deputy Manager, Hitachi Software
Engineering, 9,'3/87.
123.
Matsuzaki interview, 9/3/87.
124.
Tajima and Matsubara (1984), p. 40.
Cusumano and David E. Finnell, "A U.S 'Software
System Development Corporation." M. .T Sloan School
of Ma nagement. Working Paper «1887-87, 1987.
See Michael A.
Factory' Experiment:
125.
I
.
126. For a discussion of Toyota see Michael A. Cusumano, The Japanese
Tec hnol ogy a nd Management at Nis s an and Toyota
Automobile Indust ry
(Cambridge, MA: Harvard University Press, 1985). This comparison is also
examined in more detail in "Tov.ard the Strategic Management of
Engineering:
The 'Software Factory' Reconsidered."
:
127.
McN'amara estimate.
128.
Shibata interview, 7/23^86.
813 Ids
^^
Date Due
^'^^
FEB 20
J£ o9'«a
:
3
r^^^^h^
;^
s
FEB 26 1^0
DEC
6l99t)
JAN 07
1991
JANli
^^'Y
Lib-26-67
MIT LIBRARIES
3
TDfiO DD4 T3t,
131