DEWEY
HD 28
.M414
OCT 201987
HITACHI: PIONEERING THE "FACTORY" MODEL
FOR LARGE-SCALE SOFTWARE DEVELOPMENT
Michael A Cusumano
Sloan School of Management
M.I.T.
.
May 1987
WP //1886-87
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
HITACHI: PIONEERING THE "FACTORY" MODEL
FOR LARGE-SCALE SOFTWARE DEVELOPMENT
Michael A. Cusumano
Sloan School of Management
M.I.T.
May 1987
WP #1886-87
5/31/87
Software Project Paper #3
Michael A. Cusumano
MIT Sloan School of Management
Working Paper #1886-87
PIONEERING THE "FACTORY" MODEL
FOR LARGE-SCALE SOFTWARE DEVELOPMENT
HI TACHI:
Contents
:
Introduction
Comparison to the Survey Criteria
The Strategic and Structural Setting
Hitachi:
The Factory Model
Software Strategy:
Policy and Management Infrastructure
Computer-Aided Tools and Systems
Technological Infrastructure:
Additional Flexibility through Subsidiaries
I.
II.
III.
IV.
V.
VI.
Conclusion
Appendix
Appendix
I:
II:
Survey Data Tables
Toshiba and NEC
INTRODUCTION
This paper
or
not
such
is
companies
part of
are
large-scale
as
a
larger study examining the question of whether
choosing
software
and organizational
considerations
to
manage
a
complex
development with
well
as
as
engineering
range of
a
activity
strategic
approaches
technological
that
corresponds to the spectrum usually associated with "hard" manufacturing,
i.e.
of
job shops,
flexibility
includes
factory
facilties
batch organizations, and factories exhibiting various degrees
in
product mixes
proposal
the
of
and
technology
and
policy
environment for software might look
in
the U.S.
like;
criteria
a
defining
survey
of
and Japan to determine where firms stand
project
what
a
38 software
in
relation to
and detailed case studies examining the technology and policy
these criteria,
implementation
factory model
The research
technologies.
process
followed
at
firms
'
-
1
identified
as
being
close
to
the
There are several interrelated conclusions:
"factory" approaches,
software facilities
inherent
in
observable
is
the U.S.
software
in
as
a
in
(1)
statistically
a
and Japan.
(2)
technology
that
This spectrum, including
significant sample of 38
There appears
to be nothing
some firms
prevents
managing the development process more effectively than others.
approach
developing
to
development
is
by Hitachi and Fujitsu
applying
management concepts,
quality-control
U.S.
firms
--
disciplined
a
NEC group and Toshiba, and
firms.
followed
are significantly ahead of most U.S. competitors
and
"factory"
flexible
general-use tools,
--
techniques
to
approach
standardized
large-scale
software
--
effective
Other
development.
are
in
production-
procdures,
relatively close to the flexible factory model
lesser extent,
software
aid
to
The
(3)
not significantly different between Japanese and U.S.
But, Japanese firms -- led by the
(4)
infrastructure
technological
a
from
TRW
and,
to
a
Sperry and System Development Corporation (SDC), now both
part of Unisys.
This paper presents the results of Hitachi's responses to the survey and
then
beyond
extends
aspect
of
the
this
software
to
what
analyze
factory
--
the
probably
is
implementation
benefits or disadvantages this environment might offer
is
significant for two reasons:
performing
software
both
factory
extensive
systems
established
historical
and
One,
and
in
its
world,
technical
in
most
process
programming)
and
Hitachi
documentation
difficult
and
operation.
Software Works (originally
applications
the
the
has
for
was
the
Hitachi
a
facility
the
first
made availabe
this
facility's
and
technological
policy
Two,
systems.
extended
has
Hitachi
factory
its
approach to both applications and systems software development.
The organization
introduction,
paper
Continuing
the
the first section presents the survey criteria and results,
and
of
this
follows.
as
is
subsequent sections focus on the motivations behind the founding
Software Works
in
the
development between
controls
and
and
late-1960s,
1969
and
support-systems
System Development Corporation
on development factory standards first, that
factory technological infrastructure.
of
several
theoretical
dissemination
of
productivity
and
good
benefits
product
the
in
technological
institution
of
management and
various
product
and notes the historical focus
before investing heavily
is,
factory
and
approach
practices;
cost/performance;
dysfunctional behavior; improvement
Hitachi
in
a
also reviews the Hitachi case in light
It
technologies
of
implementation process with
Hitachi's
the U.S.
in
the
production
for
and
organizational
including
1986,
The conclusion contrasts
engineering.
The
responses and comments for individual critiera.
examines the Hitachi
might
provide:
enhanced
reduction
focus
on
individual
in
process management and control.
L COMPARISON TO THE SURVEY CRITERIA
In
the survey of 38 software facilities
criteria
extrapolated
Factory
Experiment
in
from
the
System
in
US
the
Development
mid-1970s,
Hitachi
and Japan,
Corporation's
Omori
Works
and
utilizing
Software
Hitachi
Software Works were just above average on
above the sample mean
Software Works
respectively,
Among the
14th
(73%).
15th and 19th;
17
Japanese
ranking 9th and 11th.
leader
in
but
average
In
the
Japanese
for
technology
ranked,
they
area,
the
the policy/methodology area, 13th and 15th.
in
facilities
responding,
they
were about average,
Thus, though Hitachi has been the
historical
world
promoting the factory approach, judged by the survey criteria,
responses
Applications
to
individual
(indicating
criteria
Omori
Software Works). '^
examined
below
Software Works)
Later
sections
will
and
are
The
Systems
elaborate
on
SURVEY ANSWERS KEY:
CAPABILITY OR POLICY
CAPABILITY OR POLICY
2 =
CAPABILITY OR POLICY
=
CAPABILITY OR POLICY
=
CAPABILITY OR POLICY
4 =
3 =
1
n = 38 (Jap.
= 17,
U.S.
IS
IS
IS
IS
IS
TECHNOLOGY/FACILITY INFRASTRUCTURE
ALL COMPANIES/FACILITIES
as
(indicated
the
FULLY USED OR ENFORCED
FREQUENTLY USED OR ENFORCED
SOMETIMES USED OR ENFORCED
SELDOM USED OR ENFORCED
NOT USED
= 21)
it
specific
abbreviated
capabilities described.
I.
"flexible
and
facilities);
was not pursuing this strategy as rigorously as other firms.
Hitachi
the
Overall, Omori ranked 12th (75%,
factory" model (see Appendix data tables).
8%
the scale toward
tools
or
E
.
of labor for
programming tasks and related
Applications:
Systems:
activities.
4
4
These answers were above the sample average, though common
especially systems facilities.
Both Hitachi
used established "factory standardards" for design
documentation, coding methods, testing methods, etc.
for Japanese firms,
facilities
C.
A
centralized
program
library
system
to
store
modules
and
documentation
Applications:
Systems:
3
3
Average responses. Hitachi did not centralize
entire facilities but they did for each project.
D.
these
for
the
production or development data base connecting programming
a single product family to track information on
milestones, task completion, resources, and system components, to
facilitate overall project control and to serve as a data source for
statistics on programmer productivity, costs, scheduling accuracy, etc.
A
central
groups working on
Applications:
3
Systems:
4
Centralized control was provided through the
Above average.
[Use of
Computer-Aided Production Control System (CAPS).
provide
this was not mandatory in Omori, apparently to
development groups with more flexibility in project management
for customized software.]
E.
Project data bases standardized for all groups working on the same
product components, to support consistency in building of program
modules, configuration management, documentation, maintenance, and
potential reusability of code.
Applications:
1
Systems:
2
The low score at Omori reflected the
Below average responses.
wide variety of projects and customers, but was low even for
an applications facility.
F.
A specific group or groups designated to develop and disseminate
methodologies and tools to automate tasks such as requirements
and design, coding, documentation, system testing and
as well as to facilitate standardization of practices and
division of labor, and effective managerial control over all programming
specification
debugging,
activities.
4
4
Applications:
Systems:
Above average, though systems
G.
A system interface providing the capability
project
data
bases,
the centralized
usually scored 4.
In
production engineering
facilities
both Hitachi facilities, there were
groups that performed this function.
to
production data
support tools,
base and program
link
libraries.
Applications:
4
2
Systems:
The Systems response was below average and especially low for
a Japanese firm.
The Applications response was especially high
for an applications facility.
According to the survey
respondent, Omori was more advanced in this area due to the
development of EAGLE (Effective Approach to Achieving High
Level Software Productivity), an integrated program-generating
tool and methodology that provided a standardized interface for
applications software development.
H.
Automated or semi-automated
integration of applicable data from
development data bases with management control
systems (project data bases and the central production data base), for
each phase of program development; and the utilization of this
capability to facilitate budgeting, forecasting, maintenance, and overall
life-cyle cost control on current and future projects.
support tools
and
Applications:
2
2
Systems:
These responses were slightly above average for the sample,
though somewhat low for Japanese facilities.
The Hitachi
managers noted that project progress control, and historical
recording of program corrections or changes, were "mechanized"
functions.
II.
METHODOLOGY
&
POLICY INFRASTRUCTURE
ALL COMPANIES/FACILITIES
D
Applications:
Systems:
3
3
Average for the sample.
F.
Planning for reusability at the module-design level
Applications:
Systems:
3
3
Average for the sample.
G.
Planning for portability at the module-design level
Applications:
Systems:
3
2
Applications was average;
a
H.
systems
Monitoring of how much code
Applications:
Systems:
Softwar Works was somewhat low for
facility.
is
being reused
3
4
These were high for the sample but average responses for
Japanese applications and systems facilities.
Omori used an
automatic
monitoring
tool,
although
it
did
not
place
as
much
emphasis on keeping track of reuse as the Software Works,
which recently initiated an effort to monitor and promote reuse
of code.
"Layering" of reused modules from the program
newly written code, to create new programs
Applications:
3
Systems:
2
library,
along
with
These were average responses for the sample, though Software
Works was somewhat lower than other Japanese systems
facilities.
J.
Cataloging for the program library of common functional modules (e.g.
date verification routine)
Applications:
3
10
a
4
Systems:
Somewhat above average for the sample, especially the Systems
response.
K.
Cataloging for the program library
table or linked-list managers)
Applications:
Systems:
of
data
abstraction
modules
(e.g.
3
3
Above average
for the sample, although the Software Works'
response was average for a Japanese systems facility.
L.
Writing of documentation
library
Applications:
Systems:
to
accompany modules placed
in
the program
2
2
Below average for the sample.
M.
Requirement that, if changes are made in the code of a module
program library, the documentation must also be changed
Applications:
Systems:
N.
in
the
4
4
Slightly
above average for the sample,
Japanese
facilities
though
average for
or systems facilities.
Formal management promotion (beyond the discretion of individual
project managers) that new code be written in modular form with the
intention that modules (in addition to common subroutines) will then
serve as reusable "units of production" in future projects
Applications:
Systems:
2
2
Below average responses.
O.
Formal management promotion (beyond the discretion of individual
project managers) that, if a module designed to perform a specific
function (in addition to common subroutines) is in the program library
system, rather than duplicating such a module, it should be reused
Applications:
3
11
Systems:
2
Somewhat below average responses
12
II.
THE STRATEGIC AND STRUCTURAL SETTING
HITACHI:
A. Corporate Organization and Products
originated
Hitachi
company
the town
in
Tokyo.
1986
In
1908 as the machinery
in
Hitachi,
of
approximately
had
it
neighborhood of $20
Japan,
billion
a
1985 sales),
(21%),
home appliances
and
employees
80,000
major
area
sales
in
business was
of
although the company also sold heavy machinery
industrial
(24%),
exchange equipment and other products
machinery
(10%).
(9%),
and
telephone
computer sales among
In
Japanese companies during 1985, Hitachi ranked fourth, behind Fujitsu,
Japan, and NEC, but was traditionally the market leader
and second
For
to
IBM
most of
belonged to
7
in
IBM
large mainframes
very-large mainframes.'*
in
history,
its
organization
Hitachi's
the company operated
which
of
factories,
the
including computers and software
communications and electronics equipment,
(36% of fiscal
by train north of
couple hours
Hitachi's
dollars.
repair section of a mining
Computers,
groups:
28
Electronic
has
domestically
Devices,
centered
around
These
1986.
in
Consumer Products,
Components and Equipment, Industrial Processes, Power Generation
Industrial
Group headquarters retained
and Transmission, and International Operations.
responsiblity
for
sales,
but
factories
have
been
responsible
for
product
Factories also operate as independent profit
engineering and manufacturing.
management based on
6-month
budgets
each
centers,
with
factory.
Plant managers are thus responsible for engineering and production
costs,
the
financial
setting
company policy
of
has
production
required
amounts,
factory
and any
managers
to
related
for
expenses;
institute
and
standardized
controls and procedures for budgets as well as engineering and manufacturing
13
There have been
management.
This
software.
what
is
led
no
exceptions,
the
to
birth
of
not
the
even
the
in
world's
first
case
of
software
factory.
B.
The Computer Group
Computer exports for Hitachi have been
to domestic sales
flow
path
dollar.
a
IBM
than
It
was
cost-effective
to
IBM's 3081 model,
to
also,
mainframe,
"a
,
a
shorter data-
more expandable and more
expanded performance
with
levels
when compared
computers introduced to compete with
Hitachi
AS/XL
60 and 80, also achieved computing
speeds equivalent to the IBM machines with
half
the
number
of
processors
at a lower price."
The 1982 incident
in
which Hitachi engineers were caught by the FBI
attempting to buy information on the 3081 operating system,
features that IBM had decided to imbed
that
to
and appeared
introduced around 1982
used denser circuitry and
according to Datamatio n
IBM's new 3090 Sierra series, the
and
comparison
provide considerably more computing power for the
IBM system."'
similar
in
as to be fully compatible,
For example, the AS/9000,
be of unique designs.
to compete with
well
small
Mainframes are designed to compete
1985)."
in
IBM models as
specifically with
to
(about 17%
relatively
help
This
has actively
Hitachi
its
in
particularly
new
microcode ("firmware"), suggests
sought information on
IBM machines and software
hardware and software engineers design compatible products.
process
of
information
gathering
have also aided the performance
or
of Hitachi
14
even
"reverse
engineering"
mainframes and software.
may
It
the
also
is
success
technical
however,
case,
underlying
that
hardware and software
in
the mid-1950s and completed their first model
device
used
primarily
at
Ministry
a
Japan
in
business computer
transistorized
developed
in
--
two years
computers
helped
in
1980.'^
this
from
through which
machine was
Industry
research
(ETL), and largely completed during
introduction
transistorized
of
The main ETL designer, Takahashi Sigeru,
technology
Hitachi
to
moved
and
company
the
to
hardware product development
a
it
licensing
agreement with
The production
of
a
until
well
as
1970,
RCA
well as sold
Japan.
before
along
1961,
direct
purchasing
with
the
independent
of
technology
This two-fold approach turned out to be extremely important:
failed
to
introduce
competitive
and then withdrew from computers
to
and
1961
dual strategy within Hitachi:
development of new technology as
RCA
in
computer products
arrangement with RCA, reflected
from abroad.
RCA between
manufactured RCA-designed computers, as
software, for resale under the Hitachi label
expertise
for this
a
Along with in-house research and product development, Hitachi also
benefited
When
and then
1950s),
Trade and
commercial
the
where he headed
1962,
in
before
the United States.
transfer
formally
computer
of
using parametrons (a
1957,
The model
International
of
in
during the
1959.
institute, the Electrotechnical Laboratory
1956
history
long
Hitachi engineers began experimenting with this technology in
development.
solid-state
a
is
apparent
Hitachi's
design
machines
370 and subsequent mainframes.
that
in
new products
1970,
would
Hitachi
eventually
Equally important,
15
in
the
late
1960s
had sufficient internal
compete with
the
IBM
Hitachi engineers had an
opportunity to cultivate independent
and develop
skills
centered approach to software development.
computer group
Hitachi's
in
consisted
which started with 348 employees
in
1969,
separated into two sites during 1985.
mainframes,
systems
for
systems
software
(such
It
language
to
nearly 3000 before being
and office computers;
processors);
hundred thousand.
scale customized
control
software.
applications
^^
related
and on-line data-base
programs. The smallest programs were several thousand
largest several
lines of
code and the
Omori Software Works produces large-
programs such as real-time banking or factory
Research and development on new hardware technologies
as well as
software development tools and design concepts took place
corporate
facilities.'"^
producing
In
addition,
computer- related
products
Hitachi
and
had
services,
numerous
including
companies. 14
HITACHI COMPUTER GRO UP, CA. 1986
LINE FACILITY
Hardware
main
six
has continued to produce operating
mini-computers,
as
grew
of
The Software Works,
two for software and four for hardware.
facilities,
factory-
'
mid-1980s
the
a distinctive,
EMPLOYEES
PRODUCTS
in
two
subsidiaries
23
software
-
Omori Software Works
1,500
Applications Software
1,200
Basic Research
CORPORATE R&D
Central Research Labs
Systems and Applications
Software Technology
350
Systems Development
Laboratory
C. Corpwrate Programs for Engineerin g and Manufacturing Improvement
The Software Works,
wide efforts
at
as
Hitachi
a
takes
factory,
part
in
all
company-
analyzing and improving various aspects of engineering and
manufacturing operations.
Several corporate programs appear to have led to
an increasing refinement and improvement of the factory concept (technology
and procedures) for software, and of engineering performance
For example,
a
The major focus
program.
(Ml)
been to promote the establishment and
has
this area.
company-wide movement among Hitachi factories since 1968
has been the "Management Improvement"
this
in
implementation
of
specific
standardzation, "zero defect," and productivity-improvement objectives.'^
the
Software Works,
during
1969-1971,
this
movement took the form
setting standards for design, programming, and testing activities,
a
document control system and
of
how
a
next
to
a
in
1973
zero-defect program, and launching
managers
asked
all
planning
personnel
suggestions on how to improve productivity; this resulted
some
of
which
were adopted
quickly
techniques and better debugging methods
17
-
such
as
in
At
of
introducing
a
study
reduce personnel costs and increase programmer performance.
step,
of
to
As
submit
1437 proposals,
structured
programming
under the Management
Also
1970s, the Software
through
Promotion Center
wide focus
ways
in
the
in
production;
factory
staff
1 fi
'"
program,
during
of design productivity,
the
later
reliability,
Management formally organized these
such
structure,
as
1975 (headed by the factory manager).
Rationalization
a
'
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: 18
Area
Main Objective
Shorter times
Design technology
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
system-design
called
errors,
Since
the
founding of the
"gleaning,"
analyzing
which
and
them,
formally recommending solutions and making reports to colleagues.
have case reports once
a
month; there are also reports
analysis
identified
in
1977,
procedures
with
that
the
particular
would
by customers, such
as
objective
reduce the
of
at the division
developing
then
Factories
The Software Works adopted
approximately once every other month.
practice
involves
design
recurrence of system
level
this
and
problems
not meeting user specifications or designing
programs that were not "user friendly."'"
18
SOFTWARE STRATEGY:
III.
THE FACTORY MODEL
A. The 1960S: Product Proliferation and Programmer Shortages
The
drums
well
for main
as
simple
computers
Hitachi
first
input/output
it
FORTRAN and
and
1950s
early
and
inclusion
of
became possible
to
to write
a
few
subroutines
core memory and
use
card
higher-level
more sophisticated programs.
for
a
modern operating system for
RCA product
knock-down
required
during
languages
such
Yet the hardware
as
still
first
program
Hitachi computer was a
Fortran
4010
in
1965.-^^
But this was
which Hitachi produced from imported
(model 401),
Hitachi
kits;
a
HITAC
"monitor" system introduced with the
actually an
used
scientific
readers
had no interrupt features, so control programs were small. The
resembling
1960s
Thus, they did not require software except for
programs
the
With
1963-1965,
late
memory, and paper tape for entering programs and data as
receiving output.
calculations.
the
of
little
product
engineering
or
software
knowledge, except to be able to service the machine.^'
An in-house
project, on the other hand,
extensive experience
began
to strain
provided Hitachi engineers with
both hardware and software development,
in
engineering resources.
In
the early 1960s,
laboratory
to
Agency,
build
a
and
Nippon
very-large
dubbed the HITAC 5020.
scale
Telegraph
and
computer capable
the Japanese
Telephone's
of
time
The Central Laboratory completed one
19
as
Hitachi's Central
Research Laboratory took on contracts with Tokyo University,
Meteorological
as well
main
sharing,
unit for
its
own use
in
under the direction
1964 and then,
system
("monitor")
produce an operating
of
that
Shimada Shozo, set out
to
would
to
the
allow
perform input, output, and computation functions simultaneously.
compiler
for
two sources of computer expertise
the Totsuka Works,
led the
between
computers;
parametron
Hitachi's
assigned to work on software for the 5020.
of
Laboratory
had previous experience developing an assembler and
engineers
in
FORTRAN
and
20
5020
were
30
The Central Laboratory was one
Hitachi
at
the other was
the time;
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
introduction of a
Tokyo University professor
time-sharing system, Multics , using
level
Research
system
Center.
made our mouths water."
Laboratory,
his
he
next project,
The
They finished
1965 on
a
the
head of MIT's electrical
their
GE mainframe. Shimada received
a
own
copy
which discussed several new approaches and ideas such as 2-
addresses and virtual memory.
"actually
in
MIT researchers were then developing
engineering department.
of the manual,
to the
visited
In
As soon as he returned
made the development
in
cooperation
first delivery of the 5020
a
the Multics manual
Shimada's words,
in
Japanese version of Multics
Central
comparable operating
a
Tokyo University's Computing
with
was
of
to the
in
1965,
1968,
to
Tokyo
a
University.''"'
couple years before
MIT. 24
The 5020 was
short-handed
as
not
suited
Hitachi
for
businesses
management gave
20
and the project team became
priority
to
developing
system
HITAC 8000
software for the
8000 family was
incentive
create
to
development,
Hitachi
the
strategy
RCA was
because
and
developing
not
decided at first to use the
RCA
RCA
1967-1969,
provided
also
tlie
(which was
Spectra series
The 8000
IBM 360).
formal
a
during
Introduced
Japanese version of the
a
compatible with
partially
series. 25
a
major
mechanism for program
adequate
operating system,
system
software.
TDOS, but
this
required at least two magnetic-tape stations for compilers and the program
library.
contrast,
In
were available on
a
major feature of the IBM 360 was that
faster
a
and
larger
system.
drive
disc
hesitated over whether or not to develop a disc system,
insisted
While
RCA
Japanese customers
prompting Hitachi to start modifying RCA's
on this,
functions
all
TDOS around
1966 and create a new "disc operating system," DOS.-^"
Designing
processing
Hitachi.
to
an
effective
exacerbated
The manager
the
disc
strain
with
capable
software-engineering
on
of the project,
work on the system,
system
operating
Sakata Kazuyuki,
assistance
from
of
on-line
resources
in
found 80 engineers
Hitachi's
Research
Central
Laboratory, the Totsuka Works, two subsidiaries (Hitachi Electronics Service
and
Hitachi
Business
Electronics
Engineering),
(The groups from
Machines.
and
Hitachi
a
Yoshizawa
subcontractor,
Electronics
Engineering
and
Yoshizawa remained together and formed the basis of the company's largest
software
Both
for
subsidiary,
TDOS and DOS
greater
completed
in
Hitachi
Software
established
provided the basic structure of EDOS,
volume on-line and
1969;
Engineering,
this
large-scale
batch
in
1969. )2'
which allowed
processing
and
was
became the foundation for Hitachi's current operating
system for large-scale computers.
2°
21
another
Yet
software
operating system for
a
project
started
in
1968
Software Works
this project,
as
well
the
in
NT&T
Development work
series,
The commercial operating system
batch
large-scale
The
performance goals
which
Nonetheless,
IBM
the
be used for
to
software
the
for
that resulted from
had multi-processor, multi-virtual memory capabilities, as
0S7,
computing. -^^
several
an
HITAC
the
called
was
the 8800,
version,
first
processing,
commercial
and was
introduced
project
the
provided
."^^
nearly
not
while
time
came
as
powerful
hardware architecture design, integrated-circuit
in
extensive
with
1972-1973,
in
The computer
8700/8800 was
Hitachi
and on-line
sharing,
deliveries
primarily to universities and research institutes
of
was
1960s
Kanagawa Works and was then taken over by the
1969.
supported
real-time
very-large scale computer,
processing).
data
at
a
(the
Hitachi
telecommunications
the
in
project sponsored by MITI and Nippon Telegraph and
Telephone (NT&T) to build
8700/8800 within
tackled
Hitachi
fell
as
short
the 370
development.
experience
logic chip design,
in
and large-
scale software engineering.*^^
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
real-time
In
reservations systems for
the Japan National Railways (the first programmable system Hitachi delivered
in
1964,
with
1100 terminals throughout Japan);
on-line currency-exchange
and deposit systems for the Tokai Bank (1965) and Sanwa Bank (1967); and
22
production
real-time
systems
control
Toyo
for
Kogyo
and
(Mazda)
Nissan
(1968). 32
The banking systems were
banks
at the time
beginning
of
processing center
experience,
Nagoya, was
in
a
according to Sakata.
systems.
Developing
"^
in
American
airline
New Jersey and
Tokai
the
a
central
particularly difficult but valuable learning
Before taking on the job,
engineers spent nearly two months
observe several
Savings
more domestic
to
which connected 200 remote terminals around Japan to
software,
Hitachi
because most Japanese
were buying these from IBM; Hitachi's system marked the
shift
a
particularly important,
in
the U.S.
banking
and
Continental
during 1963-1964 to
systems,
Illinois
he and other
They were
Chicago.
in
Howard
including
thoroughly dismayed at how difficult the programming looked and, once they
completed the
Tokai
initial
Due
working properly.
concerned
of
this
about
took
it
a
year to get the software
full
to the contract terms,
extra debugging time and
frustrations
system,
Hitachi was
had to absorb the costs
project
improving
itself.
not paid for this
^^
The
made Sakata and other managers
their
ability
to
control
cost and
particularly
schedules
and
time
estimates, as well as bugs.
B. Evolution of the Factory Strateg y
During the
Sakata,
late
believed that,
1950s,
engineers
at
since computers
Hitachi's
relied on
Totsuka Works,
digital
including
technology similar to
the telephone exchange equipment they were already manufacturing,
would be able to manufacture computers independently."^
23
Hitachi
This factory thus
hardware design
began
and
in
1960 with about 10 engineers and
The
computers,
of "service"
into
two planning
was intimately linked to software since,
had to learn from potential customers what their
Hitachi
was
section
this
group
section started
needs were and then be able to provide adequate programs.
to
first
language processors
(mainly
1963 was divided
in
the
established
government and university business, and another for private
The concept
contracts.
sell
also
programs), the engineering service section.
utility
sections, one for
to
and
software development
responsible for
officially
Hitachi,
in
group
another
which
trained
Closely related
technicians
for
maintenance. ^°
management next decided
Hitachi
division
1962
in
along
with
a
to
new factory
establish
to
a
manufacture
in
make
it
then
led
difficult
to
of
a
scarce
to
resource
But managers worried
offer.
--
of
centralized
--
software engineers
write software for the new 8000 series.
the creation
to
was planning
Hitachi
dispersion
the
a
would
This situation
system program department
Kanagawa plant, headed by Sakata and modeled after
similar
in
department
The new department formally brought together the group
RCA.*^'
the
the new plant took charge of writing or revising software for the
new RCA machines
that
hardware,
The hardware design
Kanagawa Works (separated from the Totsuka Works).
section
computer
separate
in
the
in
the
Central Research Laboratory that had been developing software for the 5020;
the
software
section
at
engineers
the division
already
level
in
the
(although
Kanagawa Works;
physically
located
and
in
Works) that had been studying programs for pre-Spectra series
produced
in
the
program
a
Kanagawa
RCA machines
Japan. The core group consisted of about 60 engineers;
24
Hitachi
hired another 20 personnel, for
°
of 80.
a total
Underlying the establishment of this department, according to the head
section and Sakata's successor as department
of the design
With the 8000 series going on sale and software for
as a factory product."
yet
5020
1969,
in
was also "the anticipation that we would develop software
Fujinaka Satoshi,
the
manager
be
to
noted
delivered,
"Work
Fujinaka,
new structure couldn't catch up with
rapidly that the
was
increasing
so
Every day was
it.
a
struggle with time."*^^
The next
logical
step was
a
software factory.
rapid growth of
fact,
In
the computer division caused acute shortages of space and personnel
in
both
the hardware and software areas. The building housing the Kanagawa Works,
located
Totsuka-cho,
in
As
insufficient.
a
peripherals (Odawara)
or
so
by train
in
August 1968,
Totsuka
(a
computers,
1970s).
In
result,
in
from
(Kanagawa Works).
Yokohama,
was
expanded but
established
Hitachi
a
separate
1966 and purchased another site
Totsuka,
where
it
built
this
most of
the
company's
for
facility
mainfram
The design and production departments moved
leaving
still
Hadano, an hour
in
current
its
was
to
plant
Hadano
departments
software
at
engineering
and
small-scale
remained within the division's staff organization
until
later in the
few others,
for
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
"factory. "40
According
to
the
managers who operated
25
the
new factory,
Komoto
Yukio
(the
successor),
head
first
of
the
Kazuyuki
and Sakata
Software Works),
Nobuo
Nakatani
(his
(who served as deputy general manager
One
during the 1970s), there were two reasons for following this strategy:
was the acute shortage
software development
had considerably
reason
engineering
separate
a
in
single facility
less
was their decision
service
that
it
made the
final
at the
stop
to
treating
went along with
product that could
discussed
and
should
be
to
produced
This was not
establish
the
software
hardware but
a
increase
to
and
in
as
in
still
1969.)
A
simply
an
view
it
as
a
inspected
in
a
casual decision; managers
highest levels of the company.
decision
President Komai
Hitachi
Software Works as an
independent
insisting that they maintain the tradition of factory profit centers.
A debate within
facility;
would bring about an
than their target to staff the new factory
disciplined, factory environment.^'
factory,
and the hope that centralizing
(Despite a nation-wide search for software engineers, they
productivity.
second
of software engineers
Hitachi
some engineers
ensued over the
wanted
to
nature
establish
a
President Komai intervened and ordered that they
was despite the fact that no other company
in
name
and
"Software
"call
it
a
the world
of
new
the
But
Center."
factory."
"^
This
had established
a
factory for software production, and Japanese university professors criticized
Hitachi,
maintaining
that
software
was
not
sufficiently
understood
to
be
produced through engineering and factory methods.'^''
C. The Factory Architects
The key figure
in
the development of the factory's management-control
system was Sakata Kazuyuki, the individual who had served as manager for
26
several key projects as well as for the system program department (currently
he
senior managing director of Nippon
a
is
Sakata had entered
software subsidiary).
high school and gone to work as
a
Business Consultants,
Hitachi
machine operator
from
1941
in
Hitachi
a
technical
a
the Totsuka Works.
in
After additional training at Hitachi's in-house engineering school and
year
army,
he
Totsuka's
joined
production
a
two-
engineering
stint
in
the
department
in
November 1945 and began developing standard
times
for
machining operations as well as studying job tasks, scheduling, and conveyor
systems to improve productivity.
department and got
machine.
computer
1957,
his first glimpse of a
he
1960,
In
In
was
section,
inspection
reassigned
which
had
Sakata moved to the accounting
computer
an
-
IBM 421 tabulating
made the manager
and
of
a
When
about 30 members.
Hitachi
management separated computer development from the Totsuka Works
Kanagawa
and established the
inspection section, which was
The
following
Then,
in
in
manager
as
1962
the
of
located within the engineering department.
year he became head of the computer division's engineering
department,
service
now
continued
Sakata
plant,
new
which
systems
engineering
for
the establishment of the system
with
1965,
did
Hitachi
customers.
program department,
Sakata became responsible for software production and quality control.
Sakata's
receiving
major
from
RCA,
Hitachi
were bugs
in
the
software
and the shortage of programmers,
RCA
divide among the
A dozen
frustrations
which
Hitachi
he
was
had to
machines, the 5020 project, and applications programs.
hardware engineers not working on the 5020 learned how
write software by
studying and translating
ASSEMBLER manuals
for the
RCA's COBOL,
FORTRAN, and
HITAC 3010 and 4010 machines; seven
27
to
or eight
then
continued
RCA amd
programs from
Hitachi customers.
program department
system
the
in
bugs
correcting
This experience,
as well as
production management and inspection, and
convinced Sakata that there had to be
prevent breakdowns due to
software as
for
other
Hitachi
software was
nature of
errors:
such
Sakata recalled, "even though
a
his
software to
the
background
computer engineering service,
in
way
better
to
produce programs and
and
the
rejecting
there would
that
notion
the
"Thus,"
be bugs.
always
was software, we called [the new
it
hardware
in
setting the same quality standards for
products,
that
shipping
before
new
the
reviewing
facility]
a
factory. "^^
The key figure who became responsible
for implementing Sakata's basic
ideas was Shibata Kanji, currently the head of the engineering department
the
He
Software Works.
Hitachi's
computer division
Shinshu University, and
first
in
later
joined
the
engineering
1964 after majoring
moved
to the
in
service
electrical
section
in
of
engineering at
system program department and
then the production administration section of the Software Works.
Shibata
quickly
management soon
training
became the in-house expert on
after
he
joined
Hitachi.
program for new engineers
during their second year to write
and then give
a
presentation.
working on software for the
a
software-engineering
One aspect
of
the
company's
months
required them to take several
paper on
a
theme related
to their
work,
Shibata chose to collect data on programmers
RCA
machines and the 5020
--
how much time
they spent each day on different activities and different types of programs.
Programmers did not
like
being watched closely or keeping records,
28
recalled
i
Shibata, so they stopped doing this
in
the system program department,
in
1966.
But Sakata, Shibata's supervisor
read his paper and decided this data was
Sakata then hired female employees to keep the
too valuable not to collect.
records, which became the basis of the Software Works' production planning
and control system.
IV.
"^
POLICY AND MANAGEMENT INFRASTRUCTUR E
A. Conceptualizing the Development Process
Hitachi
software
engineers,
despite
development process
engineers around the world:
activities
(see figure below).
of workers)
an
per process
at
the
in
as
factory
much the same way
conceived
as
other
primarily composed of design
Data on man-power allocations
Hitachi Software
accurate conceptualization:
environment,
Works
ca.
the
of
software
and testing
(total
number
1985 indicates this
roughly 50 to 55% went into planning and
design, 5% to coding, 30-35% to debugging, and about 10% to inspection.'*^
HITACHI SOFTWARE WORKS
A.
"*^
SYSTEM SOFTWARE PROCESS FLOW
Development Process
Basic Design
Inspection Process
Initial Inspection Planning
Functional Design
Structural Design
Coding
Stand-Alone Debugging
Combinational Debugging
Comprehensive Debugging
Final Product Inspection
B.
is
Documentation Planning
Inspection Program Compilation
CUSTOM APPLICATIONS SOFTWARE PROCESS FLOW
29
System Proposal Compilation
Demonstration
Estimate
System Construction/Consultation
System Design
Program Implementation
Conversion
System Test
Follow-Up Service
But
to
a
distinguishing development at Hitachi was that, with the decision
establish
a
software
managers
factory,
became obligated
to
adopt
company-wide accounting and management procedures and thus innovate
software engineering
by devising systematic controls on the process flow,
and product quality.
costs,
systems
evolved
in
In
centering
Sakata and Shibata believed
on
it
Hitachi's
hardware factories, the management
and
standardization
was possible
to
components
control.
apply the same concepts to
software.
In
particular,
Shibata wanted programmers to design modules that would
hardware parts.
serve as the equivalent of standardized
came
believe
to
similar
to
established
members
what you
a
we had
that
find
for
to
introduce
soon
realized,
and
hardware,
committee to take this up as
however,
a
a
components
in
control
special project."
is
standardize
priorities
product
manufacturing,
committee
then
and
and decided that,
not
sufficiently
design,
then
started
just
as
they had to find
first,
this
had
been
worry about components
establishing
standards
30
for
all
we
The committee
standardized to be treated the same as hardware components control."
changed their
system
Software Works
the
"software
that
"Around 1970 we
done
in
control.
activities,
a
They
way
to
hardware
A
special
while
the
adopted
committee
original
name
the
Programming
"Structured
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,
as
ways
to
well
programs
analyzing
as
improve the design
had
Hitachi
became discussed more widely
was
This
structure.
already
written
structured
before
industry journals
in
find
to
and
programming
adopted
by other
"
companies. 48
In
addition to their central objective of standardization,
of Sakata
them
and other Hitachi managers
to believe that
bugs) were most
In
for
improvements
likely
to
productivity and quality (reductions
in
come from better
long-term maintenance,
better process control.
as
well
Developing
as
a
became an especially important goal,
tools
in
and management systems.
and
then
in
manufacturing:
attempt
visible
charts and documentation
to
"visualized" production control system
because software engineering did
manage,
much the same way
the
overall
including man-power,
inspection.
The controls
involved
support-tools
and
with
process
of
to
software
that provided
process,
quality,
controls
for
and product
including standardization, design, and
controls; and for product engineering,
systems,
not
they saw hardware engineering and
as
They developed factory systems
production management,
for
To pursue these objectives, they decided
involve visible raw materials.
development
hardware production had encouraged
in
they viewed these as higher-level languages and modularization
software,
analyze,
the experience
a
strong
mixture of manual
and
automated
during the
late
1970s
efforts
1980s toward computer-integrated production .^^
31
(See Table)
and
.
motivation
the
Initially,
for
pursuing
factory-type
and
production
product-engineering systems was to be able to inspect software products,
any other product Hitachi manufactured,
But
quality.
turned out
a
to
be the
"minimization
in
of
problems.
productivity,
thus
This
"
guarantee
to
according to Shibata,
side benefit of the system of controls,
improvements
significant
and thereby be able
like
has
indirectly
resulted
addressing
in
the
shortage of skilled programmers. ^
B.
The Factory Organization
The Software Works began with three design departments
types
of
programs:
programs
(basic
to
those
software),
or insitutional
(systems
and on-line programs
programs for the National
applications
industrial
development
system
Railways,
engineering,
accounting,
and general
as
software
technology
computer graphics),
(railways,
banking,
evolved
and
as
affairs,
(such
centralized
industrial)
as
all
development
Software Works (officially separated
system
real-time
(large-scale
and other
banks,
product planning,
these functional areas,
of
engineering),
NT&T,
well
managers did not view the factory organization as
have consolidated some
distinct
Administrative functions were similar
customers).
hardware manufacturing plants:
in
for
in
1985)
32
for
a
training.
as
static;
Hitachi
over time,
they
added design departments
artificial
large-scale
in
inspection,
second
intelligence
custom
and
applications
facility,
the Omori
HITACHI SOFTWARE WORKS:
ORGANIZATION CHART,
1969^^
DESIGN DEPARTMENTS
ADMINISTRATIVE SECTIONS
SYSTEM DEVELOPMENT
Administration
Inspection
Engineering
Design Groups (6)
SYSTEM PROGRAMS
Accounting and Control
General Affairs
Planning Group
Design Groups (2)
COMPUTER TECHNOLOGY SCHOOL
ON-LINE PROGRAMS
National Railways (2 Groups)
NT&T
(4 Groups)
Banking (2 Groups)
Government etc. (1 Group)
H TACHI SOFTWARE WORKS:
I
ORGANIZATION CHART,
1986^^
Product Planning Department
OTHER DEPARTMENTS:
DESIGN DEPARTMENTS:
Engineering
Documentation/Manual Development
NT&T Information Processing Systems
No. 1 Systems Programming
No. 2 Systems Programming
Database Programming
Data Communications Programming
Language Processor
Artificial
Inspection
Computer Center Service
Software Education Center
General Administration
Purchasing
Accounting and Control
Software Technology Center
Intelligence
Computer Graphics
Small-Scale Systems Programming
In
addition
to
overall
organization,
another
aspect
flexible
of
the
factory was the ability of managers to move personnel freely between among
groups within
(Departments
a
problems arose on
department,
such as
if
had
between
500
generally
and
600
people,
given project.
a
the
with
NT&T
department being the largest (around 900); departments were then organized
into
groups
members.)
of
about
Managers
100
could
programmers,
also
appeal
33
to
with
sub-groups
engineering
groups
of
about 30
within
each
department to add
appeal
could
they
manpower
help
Department
Technology Center for problems or develop
wide relevance.
project- related
solve
Engineering
the
to
to
tools
or
difficulties,
and
Software
the
considered to have factory-
*^
PRODUCT PLANNING
The Product Planning Department
in
the Software Works was
in
launched
1970 to centralize planning activities dispersed among the system program
Responsibilities
section.
for
the
Hitachi's
department set
M
in
the U.S.
compatible.
To
These
assist
office
Department
served as an
products
but also for exports.
up promotion conferences
to
in
in
included preparing for
activities
and studying how
Computer Liason Office
Planning
for
(control)
such
as
new
In
1974,
for
determine policy
which Hitachi was designed to compete directly with
series,
the IBM 370 family.
Itel
planning
included
beginning with OS7,
operating systems,
example,
and the administration
the large-scale program area,
department,
this
the
make the Hitachi hardware
to
effort,
Mountain
in
Hitachi
View,
pipeline"
also
established
California,
Software Works
"information
OEM
which
administered
IBM,
on
exports to
fully
in
1970s,
unbundled
the
department became involved
software
from
hardware,
technical contracts. ^^
34
and
in
in
This
RCA, and
product pricing as
administration
of
a
Product
the
1978 was absorbed by the San Francisco office of Hitachi America. ^^
late
1972
directly.
replacing
IBM
In
in
the
Hitachi
overseas
ENGINEERING (PRODUCTION ADMINISTRATION)
department originated
This
section,
of
Works.
It
in
and was moved
Kanagawa Works,
the
engineering
the
department,
software
the
Software
1970
in
to
began with two sections (engineering and administration) and 36
The engineering
members.
computer division,
other
section served largely as a liason
Hitachi
and
factories,
group for the
providing
subcontractors,
explanations and documentation on software-product pricing and progress on
The administration
product development.
management and
production
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
as
well
the System Development Laboratory
Technology Center (established
for out of the factory
department
later
software
from
full
overseas
for
cost
control
helped develop control
as
other tools,
(established
in
1975)
systems to
conjunction
in
and
with
and the Software
198X). General-use tools were always paid
in
Other sections of the original engineering
budget.
became
responsbile
also
It
and inspection,
was
procurement,
departments:
and
Japanese
which
subcontractors;
purchased
and
the
documentation/manuals section. ^°
INSPECTION
This department originated with
the
Software Works
and has followed
the strategy of developing inspection and control techniques based on actual
operating
data.
factory head, as
The manager
in
all
of
this
Hitachi factories.
35
department
In
reports
directly
addition to overseeing
all
to
the
testing
and debugging, an important
bugs while
a
program
has been the "needle probe,"
development and provide data
in
countermeasures
formulate
and
is
tool
department also operated the SST, established
conditions
and
input/output
used
and
in
circuit
revise estimates
to
The inspection
problems.
the
correct
to
1977,
defect
identify
to
which simulated user
generators
to
detect
bugs; organized the design review task forces, which include reviewers from
several different departments, including inspection; evaluated the performance
of
programs
at
locations;
took
charge
bugs and developed methods
information on
and
customer
developed
the
factory's
of
maintenance;
of
compiled
testing for potential
bug forecasting system.
In
defects
addition,
the
department had responsibilities for programmer training and helped develop
support tools.
'
ACCOUNTING AND CONTROL
The members
factory's
how
to
cost
of
this
accounting
treat orders,
department
system.
sales,
set
up
and
A major problem
and income.
have maintained
in
the
beginning was
Management then decided
development expenses for systems software after
then charge these back to the Kanagawa Works.
a
project's
the
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.
calculations were the standard times
for
all
Essential
by the engineering (production administration) department. °
36
the
software development activities,
CO
set
to
SYSTEMS ADMINISTRATION (OMORI SOFTWARE WORKS)
department originated
This
systems
which
department,
consultation
1973,
in
from
developed
divisional
department
centralize
and
introduction
the
to
standardize
the
of
first
Software Works
design
activities,
mainframes
M-series
which
1974,
The
additional personnel to rewrite programs to run on them.
SC (system
consultation)
department
to
responsibilities
for
The department
financial
controls
for
leased
moved the systems administration department
in
1985 made this
a
for
to
the
required
institution of
standard times corresponded to the move of this
Software Works.
the
this
effort
their
preparation
in
in
moved
manager,
part of
as
the head of
Fujimoto,
the deputy general
and Sakata,
applications
large-scale
programs for the government and private customers.
the Software Works,
computer division's
the
systems. ^^
to the Omori,
took
over
Hitachi
then
also
Tokyo
site,
and
separate factory for applications programs.
C. Product Engineering and Production Management
MANPOWER CONTROL
The basic
tool
standard times for
basic design.
Hitachi
all
manpower
control
in
Hitachi's
software factories
phases of the development process,
Since the establishment of the Software Works,
managers
improvements
for
in
has
revised
these
once
programmer productivity.
per
year,
This
attempt
discipline an engineering activity began in the mid-1960s,
in
to
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
required to develop particular programs. Guided by Shibata, Hitachi engineers
37
enough
had
procedures
for
development,
and
data
actual
estimating
both
placing
initially
information
this
made
1969 then
in
hours
on
formal
establish
to
job
program
for
The
tickets.
necessary to adhere
it
company-wide budgeting and cost-accounting procedures, which
Hitachi's
used
1967
machine
and
labor
inauguration of the Software Works
to
by
confidence
standard
times
as
basic
accounting
units
for
all
engineering
and
production activities.
"We were perplexed," recalled Sakata, but they set up
succeeded
each
drawing
in
of
class
up formal
programmers,
standard
times
each
for
a
committee that
and for
activity
The
based on their training and experience.
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
collected the data
in
a
"red book" that became,
the basis for the factory's current cost accounting and
the early 1970s,
planning
They
systems.
Hitachi
these
instituted
controls
for
software
years before IBM began promoting the use of standard times,
several
although the
System Development Corporation had published some materials discussing how
to
1967-1968 and these provided
devise standard times for software during
fin
several suggestions to Shibata."^
Hitachi
required
To
a
managers early on
different
set of
realized
that
1973.
in
tools
and
systems
SC (system consultation) standard
The systems engineering groups
such
as
software development
than customized applications software.
activities
deal with this problem, they established
times
systems
HIPACE
38
(Hitachi
also
Phased
developed separate
Approach
for
High
.
Productive Computer System Engineering) to standardize their proposals and
aid
to
made
in
it
relatively
independent Omori
Planning
easy
different standards
of
and
move the applications departments
to
tools
the
to
site.
and scheduling improved significantly soon after the factory
through the compilation of actual data for each
was established,
the development process,
Accurate
The evolution
design automation.
programmer
and continual
refinement of planning techniques.
were considered
classifications
phase of
essential
to
the
both
planning and budgeting systems, which, for each project, took into account
the
and
experience
classifications
service
in
output
team
of
Programmer
members.
were determined largely but not entirely by their length
company.
the
was
Seniority
markedly with experience.
increased
fairly
a
accurate
indicator
of
of
because actual data showed that coding
according to Sakata,
performance,
speed
potential
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 also tested
classifications.
They were made
the completion
of
each
were tested through
charts
and
code
to
solve
individuals and groups,
managers
to take certain
course.
competion
before
In
in
certain
addition,
contests,
problems.
courses,
all
raised
programmers twice
where they had
The contests
and scheduling."^
39
official
and then tested
and management recorded the results
as a reference for future planning
their
a
year
write flow
to
involved
in
at
a
both
data base
PROCESS CONTROL
Establishing a capability for accurate planning and process control were
his
These were especially important
most enduring problems, claimed Sakata.
because Hitachi's computer division sales department would always announce
new computer products and give out specifications before the Software
Works had developed the systems software.
This placed
Customers also wrote their own
on software managers to meet their targets.
applications programs,
upset
the
if
systems
tremendous burden
a
based on the advance specifications, and became very
software
was
delayed
or
if
changed the
Hitachi
specifications.
The Software Works' process-control system monitors the
project
through
process.
documents
covering
the
first
half
status of each
the
of
development
Large projects include several hundred people, divided into teams of
about thirty
with
parcelled
responsibilities
out
equally
to
team
members.
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
the
general
this will take.
according to Shibata,
a
This
given
project first
functional
is
involves the system
specifications
and
how many
the most difficult part of scheduling,
and thus the most error prone.
Then they
look
to
standard times data for each phase of the development process and calculate
a
standard time objective for the entire project.
40
They next
look at the skill
levels
the
and particular programming experiences
Using the standard times
project.
as
of the
employees available for
they work out
reference,
a
schedule based on required program steps, man-months adjusted for
a
and
skill
experience levels, and computer time.
At the
inception
diagrams and then
(PNET),
the
of
computerized diagramming
a
linked this experimentally with
Computer-Aided
accurate,
letting
program often
have
managers preferred
negotiations.
1973-1974
In
addition,
and which
all
written
introduced
actual
CAPS
progress
an
to
a
be
especially
was that
was
lax,
since
other
work can
during project progress meetings
parts
of
a
continue;
a
month
to
discuss
(formalized
in
and potential
problems
convenient to use arrow diagrams on paper, because
of
specific
thus went back to
planning,
control
modules
completing
Hitachi
process
for
on-line production
debugging and design review.
programmer
to
serious
too
HICAP
these types of problems through personal
with
arrow diagrams
as
prove
Most
the schedule changes they usually made.
manually
the
it
not
before
completed
met once
solutions), they found
of
deal
did
Hitachi
1971,
in
problems.
schedule
the
be
to
to
other
involved
computer control
the
It
arrow
simple
master schedule.
a
planning simulation program
Planning).
and
however,
a
using
PERT Network System
tool,
keep track of projects and draw up
to
(Hitachi
managers began
factory,
and
until
system
in
the
factory
1978 to track
documentation,
and
of
This system involved the assignment of every
terminal
as
well
as
a
central
data
base to
keep
CO
track of the process flow, mainly through the completion of documentation °^
.
41
In
which indicate problems and progress toward solutions,
lists,
1973-1974
a
Hitachi used
and
the basic control mechanism has been check
the debugging process,
system of tickets
PX
tags)
(or
accompany daily control charts during debugging,
tickets to
charts
control
identifying
defects
specific
the
indicated
state
monitoring
of
the
To determine what percentage
of
a
correcting
Overall
defects.
bugs,
or
tickets
while
PW
and coding.
design,
progress
and
work-in-process,
of
PZ
inspection.
tickets designated control charts used during planning,
Other tickets
documents. ^
accompanying
for
PY tickets for daily control charts during
accompanied
including from
debugging process was
in
also
incorporated within CAPS.°^
managers submit reports on completion
to
project
of modules.
If
a
completed,
been
has
program
is
designed
have 100 modules, for example, and 80 are completed, then they consider
One
the project 80% done.°°
the Software Works
people
--
finish
close
not just
that,
if
anyone,
the
to
facilitated rapid
is
of the
results of the control
projects are falling behind,
but the best people available
target.
This
was
systems used at
managers can add
--
and generally
environment
because the factory
understanding of projects.^'
In
contrast,
IBM's experiences
with the 360 operating system development was that adding people tended to
make projects
later,
due
to
the
communication
time
needed
to
familiarize
CO
new personnel.""
QUALITY CONTROL
Hitachi
engineers
defined
quality
42
control
for
software
as,
first,
preventing the creation of bugs
and,
stage,
second,
according to Shibata, are given primary importance.
so,
meeting
These two factors directly impact the customer
performance specifications.
and
the design
in
Other features
of quality that affect the manufacturer are maintainability and portability of
a
To improve quality
program.""
managers decided
factory
methods,
high-level
on
focus
to
and
languages,
maintenance as
well
These
productivity
and other
Shibata,
structured
of
systems
formal
and product engineering.
short-term
adoption
the
process control,
as
Sakata,
control,
for
quality
facilitated
tools
by making
it
design
control,
long-term
possible
to
divide job tasks more easily and to test completed modules and programs.
From
the
1971,
factory
generation of bugs and status of corrections,
developed
technique,
by Sakata,
about 60% was completed,
linked
to
actual
1975,
FORCST. This
different
types
Included
as
At the same time,
of
part
the
In
system,
designate
to
1974, these
simplify
to
the needle probe tool and
of
programs became the
in
provided programmers with examples of bugs
in
software,
of
bugs.
In
program for forecasting bugs instituted
statistical
also
"needle probe"
tickets
ticket
bug generation for different types
basis of a time-series
P
to indicate corrects of
project control and estimating.
data on
a
the
program being developed when
PX-PW-PZ process-control
the
as
well
indicating
and then revise the overall bug estimates.'^
program changes, and B tickets
were
a
as
added another ticket-control system:
Hitachi
1972,
test
to
charts
control
instituted
to
help
quality
them
control
avoid
effort
making
were
similar
also
errors.''
design
review
sessions from around 1974 (particularly used for applications programs where
Hitachi
had
to
meet
customer
specifications).
43
'^
In
addition,
the
system-
focusing
practices,
gleaning
on
system
particular
solutions that seemed instructive to present to
Works, supplemented other quality assurance
employees
all
and
problems
design
in
the Software
activities.
PRODUCT CONTROL
consisted
This
department
in
of
a
formal
system,
Kanagawa Works,
the
for
by
started
both
storing
program source
and accompanying documentation for future reference, either
or to add enhancements.
copies
of
all
programs
in
1976,
In
Hitachi
separate
a
to correct
the practice of
started
location
program
system
the
files
bugs
keeping
guard against destruction
to
from earthquakes or accidents.'*^
STANDARDIZATION
In
addition
to
standard
from the
times,
inception
Works, Hitachi managers made "job standardization"
not
establish
standards,
long-term fixed
were changing continually.
initially
met
almost
weekly
But the
to
of
the
top priority.
a
Software
They
did
because personnel and technology
standards
determine what
establishment
short-term
committee
work standards
should be and codified these as the Hitachi Software Standards (HSS).
This
entire effort involved a deliberate attempt to standardize software as Hitachi
factories
standardized the development and production of material products;
specifically,
managers tried
to
prevent programmers from designing, coding,
and documenting software products
in
different ways.
standardization of the entire process flow was
44
In
Shibata's opinion,
probably the most important
technique
high-level
with
found to
Hitachi
when combined
particularly
productivity,
raise
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
extremely difficult and not very successful
The
factory managers succeeded:
method
structured
design
portability,
despite the
same time,
the
system"
control
and
control
effort
1973
in
instituted
and then
in
1977
The structured programming method
determination of external
specifications
manufacturing (coding); and
logic
structure
interconnections
wrote
represented
the
(input/output)
specifications
in
(5)
natural
in
^
"components
At the
[modules]
registration
standard
published
coding
7fi
the facility.'"
Hitachi
began
adopted
with
determination of user requirements;
(1)
determination of internal specifications
(4)
resulted.
general-use software tools
factory
(the program's
(the program's
logic
structure);
layers
of
between those layers.
language
and
used
a
(2)
(3)
"physical" structure);
inspection (testing and debugging).
functional
of a
program maintenance and
standardized
the
however,
time,
depended on the establishment
manuals for each programming language used
standardized approach to design:
Over
first.
facilitate
a
a
Meanwhile,
system.
to
at
programs that often
lengthier
factory
the standardization effort was
factory history,
an
a
program and
First,
The
the
programmers
in-house
tool,
CEG
(Cause-Effect Graph), and decision tables to identify inconsistencies or flaws
in
the
partial
logic
structure.
functions
to
They then broke down the
develop
algorithms
45
to
object
implement
function
the
into
desired
.
actual modules
The physical structure represented the
specifications.
up the program (their hierarchical arrangement as
interconnections)
as
well
making
and data (data hierarchies, data and module interconnections, and data-point
relationships)
design
major
Hitachi's
were
objectives
match
to
(1)
structure as closely as possible to the logic structure;
(2)
physical
the
to standardize the
physical structure; and (3) to make the elements of the physical structure as
This latter principle required each module to have
independent as possible.
only one input and one output,
and each module
subroutine." Documentation also followed
several
a
to
be
in
effect
standardized format.
In
a
"closed
addition,
support tools relied directly on the standardized design structures.
AGENT (Automated Generator
External
of
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
in
capability
the
developed for both system and applications programs.
did
not
assume
programmers
to
a
scheduling
Potential
reusability
program,
reuse
targets
more easily
was considered
and facilitated through
at
the
structured programming.
46
the
than
by
graphic form.''
to
modules
reuse
Since standard times
software,
meet or surpass standard times,
or
cost
programmer would
structure
physical
doing
this
allowed
and helped managers meet
without
reusing
very beginning
standardization
of
of
modules.
designing
design
a
through
according
The tradeoffs,
to
performance and
involved
Shibata,
enhancements; structured programs designed to contain reusable parts did not
always perform as well as newly written programs.
used was that,
Hitachi
then,
in
if
to start keeping data on
data
in
previous
the
fact,
general rule
a
they had to revise 30% of the code
terms of functional performance,
needed from scratch. Only
In
in
it
was better
in
a
module,
module
to write the
1985 did Hitachi managers require programmers
how much code they were reusing, although survey
ranked
paper
Hitachi
the
in
category for this
high
measure, exceeded only by Toshiba, which was over 50% (See Appendix table
on
Analysis").
"Reusability
reusability
rate
For
In
effort
a
in
computer division
tool
HIPAL
in
for
(Hitachi Translation
in
1977.
Both
for
of
1968
and then
was
transferred
programs
translating
the
reusability,
for
to
set
first
an on-line
up within the
Software Works
the
different
reusability
programs among
(Hitachi Program Application Library),
machines,
in
HiTRAN
Program Library), was separated from the HIPAL system
these were for
Program Library Network) was
it
software,
applications programs.
data base of applications programs and utilities,
A
systems
series of systems to facilitate the transfer of
different machines.
1970.
of
considered as part of the standardization and
addition,
were
releases
The most opportunities
was about 90%.'°
however, Hitachi viewed as being
new
a
in-house
use.
HILINK
separate system launched
in
(Hitachi
Users'
1975 that made
79
possible for Hitachi customers to exchange programs they had written.
47
TRAINING
Training was integral to standardization and the general success of the
Consequently, an education program was set up along with
factory effort.
Hitachi hired both software engineers
the Software Works.
in
who had studied
the U.S., as well as high-school graduates which the company had to train
But the expansion
itself.
over 900
was
1971
in
based
programmers,
on
to
the
severe strain on instructors;
a
make greater use
to
tests
created
Software Works personnel from 348
of
large meetings,
of
Hitachi
judge the
and
use the
results
of
among the
contests
programmers. ^
of
1969 to
temporary solution
a
as
well
Standards
Software
abilities
as
in
Managers
recorded
the results of these tests and contests and used them (along with length-ofservice information) to classify programmers as an aid
in
estimating time and
cost schedules."^
The education and
Hitachi,
after which
system engineer,
applications
employees
scheme extended for
classification
depending on whether they were
During
the
first
were classified as trainees
computer science and
basic
and
programmers or system engineers
years
the factory,
took
from
six
and ten years
of
received middle-level courses.
systems
in
in
in
the
in
remained
second
received
software or
Software Works,
the
courses
They
during which time they
Programmers with between
junior leaders and
year
programming.
"junior"
in
years
received the grade of chief programmer or
individuals
software.
12
introductory
classified
through
additional
as
fifth
courses.
experience were designated
Between their nineth and
tenth years, programmers rose to the status of planners or sub-leaders, while
undergoing advanced training.
Chief programmers continued their education
48
and
subjects
studied
such
as
software
reliability,
use
of
design
review,
semiconductors, and computer network technology .°^
V.
TECHNOLOGICAL INFRASTRUCTURE: COMPUTER-AIDED TOOLS
AND SYSTEMS
The
initial
essence of the
infrastructure
factory
at
Hitachi
was
primarily a combination of policies to promote standardization and the use of
A technological infrastructure
"good" practices such as structured design.
facilitate division of labor
in
defy complete solution
and group programming evolved afterward, largely
problems
response to several
to
software management that
in
through management alone.
A
Hitachi
appeared
to
memorandum
cited six areas of specific concern:
1.
The
2.
Increasing scale, complexity, and diversification of program functions
3.
Pressure for higher
4.
Difficulty of improving production efficiency
5.
Shortage of software designers,
invisible nature of the production process
reliability
especially
experienced designers,
and
managers
6.
Increased work hours for management."''
The response engineers
and
at the
at
Hitachi's
Software Works arrived
at
Systems
during the
Development
late
Laboratory
1970s was to develop
computer-aided systems for functional support (such as design, coding, and
49
group programming
and
testing)
standardization,
factory's
policies
for
and inspection functions for systems software were
design,
through
integrated
The
general.
in
CASD (Computer-Aided
Development System);
Software
and the policies for man-power, process, and quality control through CAPS
(Computer-Aided Production Control System for Software).
CAPS
on
relied
subsystems or support
various
They themselves
methods.
Computer-Aided
(Integrated
Department
in
with
the Software Works
System),
aimed
production-management
and
development of these technologies,
standardized
broader effort labelled ICAS
into a
The System Development
^
and
tools,
Engineering
Software
product-engineering
integrating
activities.
also evolved
CASD and
Both
Laboratory
has
fully
at
tools
and
directed
the
the cooperation of the Engineering
areas related to production and quality
in
control. ^^
A. Computer-Aided Software Development System (CASD)
CASD was
software
mainly
programs
developed
and
during
a
response to the increasing size and complexity of
grew out
1975-1977
of
a
centralize
to
and
design
debugging
controls
for
tool
Hitachi
supporting
standardizing design through the use of structured programming,
and
high-level
languages for system construction, multiple and remote computer sites, and
central
program library. °°
improvement,
which
control
flows,
evolving
standardizes
a
over manpower
After
1979
increasingly
variety
planning
of
in
it
became
parallel
and quality. °'
50
a
and with
technologies
and
also
scheduling
and
as
tool
for
linkages
as
reliability
to
CAPS,
to
improve
cost,
process
activities
well
a
There were two basic assumptions
labor productivity
in
in
underlying
software could be improved by standardizing the tasks
each phase of development and then utilizing support tools.
that
performance could
also
through
improved
be
automating
these
through
only
not
support
was an attempt,
much
as
a
Second was
each
phase of the
This
single system.
the words of the architects of the system, to "modernize"
in
possible of what has usually been considered
manual activity,
a
supported only with tools for discrete parts of the development process.
CASD
Structurally,
for
design,
but
standardization
for
tools
development process and then integrating them into
as
One was that
CASD:
°°
included three interconnected support subsystems,
programming,
The design-support subsystem
and 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
system
the
The testing-support
the
program being
the tests
they
after
were run.
The design-support subsystem
called
Automated
Design
Module
Design
Hitachi's
and
relied
on
Documentation
Language
structured-programming
a
System
MDL made
(MDL).
standardize and formalize design specifications
(ADDS)
at
it
well
as
possible
to
as
the module level; the
system placed this documentation, as well as corrections or changes,
central
database,
and checked for obvious errors,
51
tool
thereby assisting
ADDS
into a
in
the
review
design
the design
"visualize"
ADDS
and terminals provided the capability
Printers
process.
The
documentation.
tables
to
and charts produced by
covered areas such as the functional layered structure of
a
program,
module specifications, the data flow path, module connections, and summaries
and changes. "
of the modules, functions,
The programming-support subsystem
for coding,
design
called
the
supposed
to
HPL's
was
largely
(SCAN)
program bugs as early
to catch
examine the program
this
components were
main
Code Analaysis
Static
logic.
manual
a
Hitachi
a
SCAN system
received
This also facilitated
compiler and
as possible
engineers
in
analyzed the program control structure
way
were frustrated because
data
the coding
in
a
significantly
by the
To address these problems,
static-code analysis
and put out various reports for use
were
reviews
and also provide
and was affected
process,
what Hitachi
Coding
system.
different levels of ability of the programmers.
the
standardized language
a
Programming Language (HPL).
the Hitachi
review.
on
relied
from the HPL compiler
These reports
review.
graphic form, the program's data
structure, and the module control structure and relationship between modules
and data.
SCAN checked
Then,
information from
the
results
of
these analyses with design
ADDS.^^
The testing-support subsystem was intended
quality
and
control
identification
of
bugs and,
devoted to testing.
in
productivity
detail the design
to
simultaneously
correspondingly,
the
specifications,
by
facilitating
reduction
This subsystem had four objectives.
problems
tackle
of
One was
of
the
man-hours
to clarify
on the assumption that the test items had
52
to
determine the conformance of the program to
was
to
was impossible to test
subsystem was
possible,
other
as
tools
automate
to
given program,
recognizing that
as
much
the
of
In
addition,
testing
process
evaluate the comprehensiveness of the tests.
as
Cause and
Effect
Graphs
(CEG),
Automated
it
the
as
Several
Generator of
(AGENT), HPL Test and Debugging system (HPLTD), and
External Test Cases
Test
a
Another
specifications.
operating conditions.
potential
all
designed
well
--
standards for
testing
establish
its
Coverage Manager (TESCO)
perform these objectives.
--
were integrated within the system to
^
B. Computer-Aided Production Control System (CAPS)
CAPS development was
As with CASD,
problems.
CAPS focused on
1.
Collection
by several persistent
managers wanted greater standardization and control of
Hitachi
the process flow,
inspired
delivery times,
quality,
and overall costs.
In
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
7.
Automatic collection of data
8.
Capability
for
a
in
a
non-impact printer
data base for actual data and standard times
on-line
instantaneous
53
utilization
of
the
automated
output. ^^
The manual procedures and computer-aided production-control
introduced
at
Kanagawa Works and then the Software Works between
the
CAPS,
1967 and 1976 provided the foundation for
an
initial
version between 1977 and 1980,
collecting
and analyzing both
productivity
management
and
and
historical
tools
is
a
by establishing
and
current
clearly evident
of major milestones preceding the start of
of
which Hitachi completed
of
a
formal means of
programmer
on
data
The incremental evolution
management.
project
policies
1967 Completion
tools
CAPS
system for computing
in
of
these
the following chronology
development:^*^
labor
and
machine
hours
for
software development (Kanagawa Works)
1969 Establishment
of
standard
times
software
for
development
(Software
Works)
1971
Establishment of
standard times
programmer
ability
coefficients
amendments
and
of
Completion of an estimation and budget system using standard times
and a simulation system for resource planning
Completion of a PERT Network System
diagramming system for schedule control
(PNET),
Implementation of a manual system for time-series
processing and quality control
an
automatic
analysis
of
test
of a system for budget-vs. -actual expenditure control for
man-hours and machine-hours for each project and department
1972 Completion
Implementation of
a
manual system for document schedule control
1973 Implementation of a manual system for job process control
Implementation
of
a
manual
system for
productivity
analysis
and
project
and
control
1974 Completion
of
a
productivity
analysis
department
54
system
for
each
1975 Implementation
quality control
of
manual
a
1976 Development of a time-series
system
defect
for
factor
analysis
and
program for forecasting defects
statistical
(FORCST)
Establishment of
standard scheduling system
a
Implementation of structured design methods
Central
structures;
CAPS was
to
the
the factory accomplished by
this
structured design methods.
features
aided
improvements
of
the
clarification
program
of
programmers
requiring
to
use
But successful implementation of the computer-
depended
system
control
equally
on
several
One was high-performance computing
hardware technology.
in
and
standardization
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
CAPS
M-180 and M-200H.
historical
data
base
also
recording
these with standard times;
(Mass Storage System).
base
systems,
wanted simple visual
process flow;
this
this
filled
ADM
required
efficiently
gap
graphic output,
to
formalize
the
with
make
was achieved through the use
to
and comparing
large-scale data-
a
the
development of
(Adaptable Data Manager).
printers that printed Japanese characters
managers wanted
for the
came through another Hitachi product, MSS
Hitachi
most notably
and present data,
past data
To use MSS
management system;
several
also
this
demanded increased storage capacity
as
well
development
it
easier
Managers
follow
to
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
has been most successful
a
series
of
in
accomplishing this
procedures and tools
such
55
as
in
the applications area, with
EAGLE and HIPACE,
as
well
as
CORAL
(Customer-Oriented
CANDO
(a
prototyping
Application
Program
These are
tool).
Development System),
and
Omori
and
used
primarily
in
applications subsidiaries. ^
An
mixing
example of this
be seen
technology can
Controlling
management policy and computer
of
the incorporation of standard times
in
programmer time and machine time was considered
according to Shibata and Yokoyama,
because,
into
of software production costs.
Sakata had earlier decided
it
was necessary
standard-time estimates for man-days and computer time.
and
contemporaries,
wanted
however,
critical
these accounted for over 90%
establish
his
CAPS.
incorporate
to
to
Shibata
these
into
a
computerized
system that would enable Hitachi to follow the time estimates
more closely
in
the actual
determining job
first,
ability;
production
standards
and,
second,
managers such as Shibata wanted
to be
that standard times be as simple as possible,
as well
To
facilitate
project,
central
to
as to simulate,
the
while
still
accuracy and
Standard times
process.
classifying
required,
programmers by
comprehensive but stressed
so they would be easy to revise
covering most of the appropriate criteria.
utilization
of
the
standard
for
times,
each
estimates and actual data were fed as the project progressed into a
production data base from on-line terminals.
compare progress to estimates and
Under CAPS
1.
type
2.
type of
ca.
1980,
of object
revise
This made
estimates
it
possible
during the project.
data points included the following:
machine (large, medium, small, peripheral)
program
(control
program,
simulator, etc.
56
on-line
user
control,
generator,
3.
process phase (basic design, functional design, etc.)
4.
degree
5.
production volume (number of steps)
6.
language being used (assembler, COBOL,
7.
machine being used
In
(newness)
of difficulty
cost overruns and
addition,
and Yokoyama believed,
correct
problem,
this
late
scheduling and
wrote
engineers
Hitachi
manpower needs and schedules automatically.
consideration:
actual
(1)
working hours
etc.)
deliveries were the
inaccurate daily
of
FORTRAN,
of
an
This
result,
planning.
algorithm
took
Shibata
to
To
calculate
two factors
the committed programmers;
into
(2)
the minimum necessary times required for different phases for each type of
software program and
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 management and
quality;
quality
control
automatically
Therefore,
data.
number
the
of
defects
according to the type of program,
they
likely
number
designed
for
each
of steps,
CAPS
to
estimate
phase of development,
items tested,
and other
factors, based on actual data."**
CAPS
techniques,
programs
relied
completely
and then used
visible.
programs divided
on
the
use
A data base control
ADM
system
designed
ADM
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
into modules,
of
of
a
program was
detailed printout tracking the schedules for
57
design, testing, and inspection, with additional information on documentation
and quality (errors
found
test
in
countermeasures)
in
items
the specifications, design documents, or manuals; bugs
and
coding;
analysis
--
Three subsystems
.
provided additional
printouts
CAPS was more than
provided
just
a tool
a
daily-schedule
CASD
and
control
but was developed
files
were not automatically sent
source
file;
nor did
program modules
CASD, and
between
the
in
it
system,
aniysis.
this
In
and
also analyzed data
the
fully
CASD
For example,
send corrected modules to CAPS.
a
major area of development
between 1980 and 1983,
systems
two
CAPS program
to automatically feed data on
not
CAPS production database
For example,
the
CAPS was
parallel.
however,
and central to the ICAS program."'
links
in
to
automatically
Automating the information flow was,
completed
and
'^
quality
CASD
CAPS
system for production management that
a
output
register
and
bugs
of
also integrated within
information
with
for quality control.
production
integrated with
Hitachi
were
visual capability for process monitoring;
a
served as
As
documentation
for
--
bugging, and inspection progress control
sense,
causes
testing preparations and programming progress control, and testing,
control,
and
the
of
bugs from
making
library
CASD
it
possible
automatically
to
to
from
CAPS.^°
C. Integrated Computer- Aided Software E ngineering System CIC AS)
ICAS
also
represented
a
mixture
methods and procedures), but was aimed
methods and computer-aided
tools.
It
at
of
technology
and
standardized
incorporating even more advanced
contained four main features:
58
(1)
an
.
integrated methodology for the structuring and abstraction of software, using
a
language and graphic notation,
formal
need
requirement
analysis,
operation and maintenance;
cycle;
(3)
an
programmers
"intelligent"
(2)
planning,
programming,
life
workbench,
using
testing,
computer,
personal
a
cycle defined as
phase of the
interactive tools for each
management
of
information
The basic philosophy
database.
a
"methodology-free"
tools,
development methodology
leaving
to
for
approach
this
of
up
it
the
to
but
employ,
phases
all
to
user
present
using
was
to
a
and
relational
develop
decide
to
life-
allowing
use the tools by having dialogues with the computers;
to
complete
(4)
definition,
throughout
on
not
which
computer-aided
tools
with a "fixed development methodology of multi-purpose use," allowing users
to
develop
software
quickly
by using the
having to worry
"without
tools
about which methodology to apply."
Requirements definition involved stepwise refinement
functional,
and
conceptual model,
data
description
logical
Several
Analysis
algorithm
Diagrams).
into
simplified
tools
From the
and defined functional algorithms with only
three control elements -- sequence,
functional
the system being designed.
of
programmers determined the control structure, abstracted
and formed data modules,
PAD (Problem
the procedural,
in
repetition,
ICAS then
statements
needs
written
analysis
and
and selection
--
automatically
in
a
using PDL or
converted
programming
description
(
the
language.
PPDS--Planning
Develop Systems and FRAME-- Formalized Requirements Analysis
Procedure
to
Method),
and
requirements
definition
Language/Analyzer)
59
(RDL/RD (Requirement
Definition
as
Design
Documentation
and
(Module Design Language), already part of CASD, as well
MDL
System) and
ADDS (Automated
included
Design-aid tools
PDL/PAD
PDL/PAD (Problem Design Language/Problem Analysis Diagram).
intended
was
automate
to
and
coding
documentation and source programs.
It
based on structured programming,
tool,
consisted of
and
a
tool
a
to
design
integrate
completely
program
logic design
convert automatically
design documents into high-level language source programs (PL/1), or viceversa.
addition,
In
Test-aid
databases.
A
above.
TESCO,
tool for
a
CEG,
and
(SEWB)
and
designing
discussed
a
Software
Database (SEDB) provided an infrastructure to use these tools
The
relational
database stored
all
data from each
input into the computer.^"
The
being
as
refined
Works,
control
quality
Software Works
of
Most
methodologies
Achieving
to
High
portions
1986
the
at
and Omori
software.
ICAS project,
EAGLE
Systems
important
guide
Level
development;
and
actual
operation
in
the
Other subsystems of ICAS
Laboratory,
were HIPACE,
Software
at
CASD.
in
were already
system design,
factory-type
managers
ICAS were
Development
Software Works
HIPACE provided
a
of
part of
as
development support tool.'^^
and
AGENT,
included
Engineering Workbench
integrated manner.
an
tool
(Database Design System) was
tools
Software
Engineering
in
DBDS
the
EAGLE
Productivity),
in
use
set
of
Hitachi
for
applications
procedures
(Effective
an
Software
Approach
automated
and
to
system-
Even before complete integration within the
a
factory-type methodological infrastructure
technological
Hitachi's
Omori
interface
facility
and
at
Engineering also viewed these tools as factory systems.'^'
60
for
applications
Hitachi
Software
intended
Hitachi
HI
PACE
reduce costs
to
communication
development by facilitating
in
between
engineers and customers and applying well-defined,
to
system development and
simply
sytem planning;
analysis;
construction;
system design;
transfer (to customer);
test;
used
engineers
management.
project
Structured
Data
applications
company's
the
system
standardized procedures
The process flow was
program design;
program
operation and evaluation.
diagrams
Flow
customized
(SDF)
First,
analyze customer
to
needs. Planning Procedure to Develop System (PPDS) and Standard Procedure
to
Systems
Develop
(SPDS)
provided
then
management standards for each phase
worksheets
referred
to
as
of the
long-term
facilitate
engineers
then
used
maintenance
programming,
HIPACE-SA
for
A
reliability
structured
set of
provided the
and testing tasks.
(and
analysis,
reusability),
HIPACE-SD
for
(usually
in
or PL/1).''02
The EAGLE system extended the
computer-aided functions:
design
and
project-
development process.
and HIPACE-SP for structured programming
structured design,
COBOL
and
Work Breakdown Structure (WBS)
format for planning of the actual design,
To
documentation
through testing,
database on
project
defined
design
(1)
HI
PACE methodology by adding
four
conversational language processing from system
using
easily
specifications
and
understandable menus;
program
(2)
implementation,
a
as
central
well
as
management (tracking information from the standardized work sheets
in
maintenance;
the
(3)
SPDS manual)
automated
to
facilitate
construction
of
system
development
new source programs
standardized patterns ("skeletons") and components (sub-routines);
61
and
and
from
(4)
automatic compilation of maintenance documentation.
The process
flow
in
using
EAGLE was
two steps are the analysis of data types
recording
a
in
"data dictionary" database;
central
and
this
new standardized modules are
interrelationships
first
and their
a
in
specifications
database.
and registered
identified
in
a
program parts library, and existing components are identified for the
system being developed,
programs
using
if
This makes
applicable.
new and reused modules.
the
customers,
although
possible to "assemble"
it
(Hitachi
standardized modules available as products with the
to
The
followed by registration of
is
and program documentation
the system design
At this point,
also clearly defined.
also
makes
EAGLE systems
these
it
sells
company engineers have found that "data modules"
are easier to use than processing algorithms, which tend to be more difficult
EAGLE next generates
to standardize.)
detailed
(module-level)
The source program
individual
carried out
users.
in
is
it
appropriate to
use of
then
Finally,
edited
and then produces
to
source program.
commands are automatically generated and
test
(1984-1986)
a
add particular functions wanted by
conversational language (Japanese)
Recent efforts
on making
specifications
an outline of the program from the
to
develop the
^*^
.
EAGLE system have focused
both more flexible for meeting customer needs as well as more
a
factory environment stressing division of labor and maximal
standardized
interface has been
(Customer-Oriented
One the one hand,
components.
the
conversational
improved; and the system now handles PL/1 and
Application
Program
language for writing specifications
in
Development
Japanese),
62
in
System
addition to
--
a
CORAL
Hitachi
COBOL.
New
softwJire
nakps
than use
i.nly
the ones Hitachi provides, to add unique features to programs
The system
being coniitru :ted.
data conmunications
and
own menus, rather
possible for customers to design their
it
now be used
also can
programs,
addition
to
On the other hand, EAGLE has been modified
to
in
data-base
to construct
business-applications
programs.
a
timp-shcirini environment,
system d<:velopment and
The
components.'-'^
programs
designed
a
<jiveri
ti;ne
shifted mere
for
with
have
overall
better
result,
EAGLE
with
this
tesiinc
For
into
a
access
would mean
being
the
to
according
show
by
library
Hitachi
to
a
2.2-fold
lines of
program taking
a
reduction
reduced
from
a
development time
in
4.8
to
1.4
Without
months
With EAGLE^ ^^
EAGLE
100
(12 months)
45 (5.4 months)
20%
(2.4)
38% (2
Implem entatiota
40%
(4.8)
36% (1.9)
Test
40%
(4.8)
26% (1.4)
System
Desig n
1)
Prognim
63
is
that
improvement
in
EAGLE
also
has
necessary
year to develop without
implementation from 4.8 to 1.9 months.
Developme iiit
data,
code per programmer
the table below,
in
reusable
of
system design and substantially reduced
hypothetical
in
people to divide up the tasks of
generally
As indicated
period).
effort
t€!stin<:i.
EAGLE,
allow more
(Hitachi usually measures this
"productivity'
in
to
work more smoothly
to
5.4
and
months,
program
VI.
ADDITIONAL FLEXIBILITY THROUGH SUBSIDIARIES
Where Hitachi has needed more organizational or geographic diversity
to
customer
meet
relied
on
needs
than
its
two
software
approximately 23 subsidiaries.
Consultants
Engineering
(ca.
(ca.
2500
employees),
2400 employees),
Computer Engineering
(ca.
The
largest were
established
established
1500 employees),
provided,
factories
in
in
1959;
1969;
established
it
has
Nippon
Business
Hitachi
Software
and Hitachi Microin
1982.^^^
Hitachi
classified these firms into ten groups, with several overlapping:
(1)
General systems and applications software houses
(Nippon Business Consultants, Hitachi Software Engineering, Hitachi
Information Networks, Hitachi Computer Consultants, Hitachi
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,
Hitachi
Process
Computer
Engineering, 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)
(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)
64
(10)
Personal Computers
(Hitachi Micro-Software Systems)
A
brief discussion of Hitachi Software Engineering
the
that
group
Hitachi
customer needs with
a disciplined
development.
software
factories,
ranked
technology and policy criteria,
Some sections worked
house
software
development for
Software Works
at
these
Overall,
and
facilities,
HIPACE,
as
it
or
the
time
and 99%
estimates.
at
This
in-house
factory
other
groups
scale
an
both
for
primarily
as
a
Software Works,
applying
them
to
In
manpower
sense,
Hitachi
for
Hitachi
facility
did
it
as
developed
modified
in-house
1981
that
actual
compared
it
cost
to
average project size was 50,000
was able
to
between
90%
in
practices
independently.
CAPS,
systems.
110%
of
300%-overruns during the early
lines of code;
Hitachi
project control.
complete 98% of
and
in-
systems
the factory
following
projects
Hitachi's
in
a
the
company:
incorporated Hitachi technology such as CASD,
well
in
software
customized
did
Software Engineering was also remarkably efficient
company reported
serving
in
reflecting the diverse nature of the
while
served
and Omori
however,
on
low
two
Hitachi's
wide variety of Japanese customers.
Engineering
Software
to
part of the permament workforce
as
factories,
a
combine flexibility
to
engineering and manufacturing approach to
contrast
In
subsidiary
this
managed
has
reinforces the notion
The
on
projects
the
original
1970s.
The
the largest were about 500,000
linesJ07
As did the Hitachi factories,
Hitachi
Software Engineering emphasized
extensive programmer training (1-year training periods, including
65
2
months
of
training
off-the-job
implementation
of
when they entered the company),
top-down,
structured
and
design
as
as
well
strict
controls
careful
on
budgets and project management,
including standard times for programmers
(design and coding).
managers
up
setting
a
structured
project
Historically,
at the
subsidiary focused first on
and production auditing system (1969-1975);
programming techniques and software
applying
(1976-1978);
tools
productivity improvement and quality assurance through the standardization
of
and
methodologies
improvement through
patterns"),
their
generation
the
cataloging
writing of new programs.
operating
systems and
message
reception,
in
screen
exercises on
in
a
and
libraries,
related
programs,
as
message format and
line-overflow,
editing,
program
modules
reusable
of
and
productivity
quality
("standard
utilization
in
the
Reusable modules included patterns for mainframe
management system processing,
mapping,
and
(1979-1981);
tools
contents
message editing
error displays,
and table lookup.
for
as
well
functions
data-base
checking,
and
such as
switching,
screen
program-function key code analysis,
Managers
also
assigned
programmers
monthly basis to make them familiar with subroutines stored
TOR
the program library. '"°
Despite the lack of centralization and standardization for the subsidiary
as a whole,
at
Hitachi
an integral and clearly stated component of management strategy
Software
Engineering
was
managers who spearheaded the development
subsidiary,
to
the
with
use
after moving over from Hitachi
cf
extensive
training
discipline.
rigid
of production
fact,
technology
the
two
at this
Software Works, openly admitted
techniques
to
company standards for program design:
66
In
make programmers comply
"To meet our
production
procedures
project
criteria,
employees.
have
been
standardized
any modules deviate from the coding
If
and
imposed
on
they
standard,
are
returned to the production line."'^^
CONCLUSION
The survey revealed that
promoting
factory-type
certain
other firms, notably the
is
significant
an
as
concepts
of
process
this
leader
historical
efforts
firm's
--
innovation
even
or
NEC group, TRW, and
toward the management of what
history
management was not
Hitachi
introducing
large-scale
software
the
technologies
Toshiba.
software
factory
--
in
several
any case, Hitachi
In
a
as
approach
strategic
and the
engineering activity;
largely an
is
in
in
rigorous
as
reveals
was
how
a
conceived
major
and
implemented.
Interviews
documentation
with
managers
indicate
that
and
Hitachi's
a
study
of
technical
and
historical
movement toward the factory model
resulted from three interrelated strategies or decisions:
1)
A company policy
of establishing
independent factories (which included
both product engineering and mass-production functions) for each major
product area.
2)
Belief on
level
the part of managers responsible for corporate- and division-
strategy,
as
well
as
for
software development,
that a centralized
.
and disciplined factory environment, integrating product engineering and
mass-production
offered
activities,
any
for
improving worker productivity and quality,
product the
as well
potential
of
project and cost
as
control
3)
Top management decision
executives and,
especially,
commitment
and
factory,
necessary
The history
between
company-wide,
apply
to
management controls
foundations
to
a
Hitachi
of
technology
programmers
to
technology or
tool
Hitachi
Works
Software
was
policy
since
tool;
support tools.
a
making
it
and
accounting
also
indicates
the
was
it
Somewhere
introduction
of
Structured
necessary
in
structured
a
programming
train
to
the
that
and
is
require
new
involved critical policy decisions and implementation.
This
as
this
standard
because
important
and
--
in
this
use
became the foundation
accounting,
controlled
were primarily policy-oriented.
and
methodological
was especially
be
standardized
programming technique during the mid-1970s.
really
should
software engineering activities.
all
the factory
of
and
any other product the company manufactured
as
divisional
the company president) to treat software as
product whose development could
a
(including
procedure,
structured
the
of
The rather sophisticated
use of
programming
factory's
production-control
general
the
as
defined
standard-times,
systems,
as
well
(computer-aided)
as
by
costspecific
technological
infrastructure evolved after the basic policy infrastructure, but rapidly, from
a
few tools
at
first
to
an
extensive
increasingly being further integrated.
68
set
of
interrelated
systems
that
are
A contrast between implementation
the
experiment
offers
at
Development
System
some suggestions
system containing
SDC
both
the factory model at Hitachi and
Corporation
the
mid-1970s
also
better
attempted to introduce simultaneously
technological
a
in
why one company might succeed
regarding
than another at this approach.
factory
of
infrastructure and
a
policy
a
infrastructure (set of standard procedures covering system-analysis, design,
implementation,
testing,
and
(central
production database,
testing
tools,
standardized
etc.)
was
project-management).
While
technology
the
program library, automated documentation and
programmers
there,
environment and
reusing
seemed
programmers'
other
dislike
to
Perhaps
code.
more important was that project managers disliked giving up control
factory
and work for the
to
different
this
infrastructure through
dismantling of the factory
engineers
dwindled;
facility
sites
divide labor or reuse modules as once envisioned
Hitachi,
policy
on
the
infrastructure
other
over
programmers and managers
like
environment.
hand,
a
period
to
--
several
a
in
the
systems
capability
to
the factory concept.''^
developed
years,
and
imposed
a
thereby training
highly standardized, factory-
in
tools
and large-scale computer-aided
the factory-type technological infrastructure.
in
little
of
to
Hitachi modified these procedures gradually and then from
technology-based
innovating
of
to operate within
the mi-1970s began investing heavily
systems
incrementally
with
to the
eventually
the dispersal
programs,
develop
to
led
the
tools
and
automation
thus
process management by applying
a
both system and applications software development.
69
came
This shift
after
in
focus
successfully
standardized approach
to
One might
for
cited
its
automaker
also
identify
excellence
has
a
consistently
physical productivity
in
demonstrated
the performance of human workers.
managers agreed
its
is
to
as
as flexible tools,
to
extend
Only after these policy innovations have
more automation,
introduce
sufficiently flexible
well
but only
(such as programmable robots) to
if
the
fit
into
manufacturing system and supplement the efforts of human workers.
The comparison with Toyota,
notion
case
software
technology,
suggests
including
a
that,
as
the
SDC
case,
reinforces
in
the
with
the
proper
mixture of
The
Hitachi
policy
and
strategy to assure the compliance of managers and
engineers or other programmers,
advantages
well
productivity as simply better process management.
in
in
as
^'
advances alone do not necessarily bring as many
that technological
benefits
of
computer-based systems, preferring instead to
focus on process control and innovation,
technology
levels
automobile manufacturing by deemphasizing the use
of sophisticated automation or
Toyota
company often
highest
world's
the
a
The largest Japanese
management.
production
in
here with Toyota,
parallel
efficiency.
the factory approach
As suggested
in
should offer several
the first paper from this research
project, these might include the following:
Institutionalization
or
dissemination
of _"good"
technol ogies
and
programming or management practices.
The production engineering departments
70
in
Hitachi's
software factories,
as
well
the factory training programs,
as
and
techniques
management,
engineering
textbooks
in
are
considered
widely
and
collection
design-review
project-management and
and reusability
and
control
program
systems;
of
good
bug-forecasting data
wide use of computer-aided design, coding, and testing
of standardization of practices
fundamentally
be
to
standardization
documentation
models;
programming and
software
on
These include structured design methods;
practices.
formal
that,
tools
were responsible for introducing
systems;
libraries;
and promotion
tools;
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
used
of
System
the
related
centralization
engineering
to
to
departments
Development
programming
software
support
production
at
the
in
the
software
Laboratory
tools
perform
to
and
factories,
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 throug h teamwork and better inter-g roup
communication
.
This can be seen
projects
in
in
two examples.
the Software Works
One,
is
that the percentage of late
dropped dramatically within
71
a
few years of
from over 72%
the founding of the factory,
remarkably low 7%
The figure
1985.
1974 and
in
1986 was
for
with
1979,
1970 to 13%
in
these figures
late
projects
example,
Hitachi
procedures, as well as
made
it
benefits
programmers
added
this
category.
CAPS (Computer-Aided
functions
and support
Hitachi's
is
to
Variations
a
late
But,
general,
in
causing
--
more
for
reporting
Production Control System for
tools.
overturning
project
with
new large new projects
possible to integrate manpower-control,
and quality-control
factory
in
new mainframe operating system.
a
Software),
was completing
a
These numbers placed Hitachi
about 5%.
the level of activity within the factory,
reflect
when
1973 and to
average of 12% during 1974-
an
Software V/orks along with other firms leading
in
in
of
process-control,
Another example
Brook's
projects
to
law
be
about
later.
of
the
more
The
factory environment allowed Hitachi managers to add people (albeit the best
people available and not just anyone) to help finish projects on time.
72
HITACHI SOFTWARE WORKS: PERFORMANCE DATA
Year
focus
Organizational
on
engineering
raising
and product
productivity
quality (defect control).
As indicated
in
sales productivity of Hitachi employees in the
the table,
Software Works doubled within one year of the factory's opening and
increased significantly overtime,
facility
Management
promoted
although direct productivity figures for the
Company-wide and factory programs, such
are proprietary.
Improvement movement and
the
and
analysis
in
system
implementation
The
performance and product quality.
factory started
has
of
gleaning
practice,
measures
to
as the
formally
improve
labor
central production data base for the
the mid-1960s also made
it
possible to track programmer
productivity as well as defect measures, and thereby have precise data to use
in
determining
specific
methods or
throughout the factory.
technological
and
most
new
important,
the
inspection
and energy,
for
--
in
the
area
example,
in
product
of
save
extensive
process,
deciding which
be
used
and
quality,
standardization,
engineering
Individuals
to
administrative
manpower,
--
facilitate
do not have to expend
languages or methods to
use, or whether to develop a particular support tool.
also
tools
the area of production management;
in
performance analysis and improvement.
time
developing
infrastructures of the factory
and product control
design,
Perhaps
in
Systems such as EAGLE
manpower by automating much
of
testing
and
by
recycling program components.
In
quality,
Hitachi employs a
measure
has reduced bugs from an index of 100
estimate
is
that
this
figure
in
represented
74
of
user-reported major bugs and
1978 to 14
in
1985.
approximately 0.01
One
unofficial
defects
per
program package per machine
along with other leaders
low category,
^
the survey.
factors:
a
installation
per year, and placed Hitachi
in
this
the
in
measure that particpated
According to Shibata, the decrease
in
bugs reflected several
in
new System Simulation Tester (SST) completed
1977-1979;
in
CASD
(Computer-Aided Software Development System), another group-programming
tool
to
product
facilitate
reused
functions;
code,
standardization,
design
approximately
reaching
and
support,
90%
in
new
inspection
releases
of
products such as operating systems; and increasing sales of essentially bugfree programs.^ '^
In
addition,
satisfaction,
sold
through
consistently
terms
in
of
price/performance measurements
National
higher
Semiconductor
than
mainframes,
of 3.55.
in
compared
particular,
a
DATAPRO
to 3.19
and
in
and accompanying
the
U.S.
For
software.
user
software
have been
which competed with the
rated
example,
the
IBM 3033 and
survey achieved overall satisfaction ratings
for the
IBM machines.
the Hitachi/NAS products
3.03 for IBM (see table).
(NAS)
IBM machines
Hitachi/NAS AS/5000 and AS/7000,
4341
mainframes
Hitachi-manufactured
and
rated 3.15,
In
terms of software
compared
to
in
approximately
COMPARISON OF IBM AND HITACHI MAINFRAMES AND SOFTWARE^ ^^
HITACHI
System Ratings
Ease of Operation
Reliability of Mainframe
Manufacturer's Software
Operating System
Compilers/ Assemblers
Application Programs
Ease of Programming
Ease of Conversion
OVERALL SATISFACTION
(includes maintenace
& technical support)
as well
as writing code,
that
practices
and lessened the likelihood
are contrary
reusable modules,
or
facilitate reusability,
goals
the organizational
to
of
workers engaging
such
as
to
in
develop
use factory-wide tools and standardized methods that
maintenance, testability, and the
like.
Maintenance of organizational and technical "flexibility."
the
Both
software
and
technological
factories
have
been
infrastructures
policy
evolving
since
1969.
Most
developed for Hitachi Software Works (and then introduced
facilities
or subsidiaries),
of
in
the
of
the
such as CAPS, CASD, HIPACE, and EAGLE, have
like,
non-standardized customer needs.
over
a
decade.
or increased capabilities of adapting to
Structured design has also endured for
High levels of reusability indicate as well that Hitachi
programmers find modules
in
the program
the factory approach might seem to make
to
respond
to
a
such as
the addition of other support tools for
linkages between systems,
documentation, testing, and the
well
tools
other Hitachi
been adaptable enough to incorporate important technical advances,
additional
Hitachi
unique customer
need
library
it
or
difficult for a
a
While
are not obsolete.
specific
particular facility
type of technology,
Hitachi has been addressing these concerns through continued development of
customer-oriented
design
systems
such
as
EAGLE,
as
well
as
the
establishment of numerous subsidiaries and new factory departments such as
for artificial intelligence.
77
APPENDIX
SURVEY RESULTS: DATA SUMMARY T ABLE
Technological Infrastructure
Policy/Methodology Infrastructure
III = Total Factory Model
@ indicates two responses and averaged or
I
II
=
=
COMPANY/FACILITY
1
*NEC@
Toshiba Software Factory
*NEC Information Service
*NT&T Comm. & Info. Proc. Lab.@
*Hitachi Omori Works
Fujitsu Info. Proc. Sys.
Lab.@
Nippon Systemware
Nippon Business Consultant
Hitachi Software Engineering©
Nippon Electronics Development
TRW
Unisys/Sperry©
Unisys/SDC
Control Data©
Martin Marietta/Maryland
Hughes Aircraft
Boeing Aerospace©
AT&T
Bell
Labs
Cullinet
Martin Marietta/Denver
Electronic Data Systems©
Honeywell/Defense Systems©
Draper Laboratories©
Computervision©
Applications Means
Japanese ()
U.S.
(32=100%)
(60=100%)
(92=100%)
joint responses.
89%
*NEC/Switching Systems
*NEC/Operating Systems
Toshiba Software Factory
*NEC Software
*Hitachi Software Works©
Fujitsu Numazu Factory©
*NT£-T Comm. & Info. Proc. Lab.©
Control Data©
IBM Endicott
Data General Westboro & N.
Boeing Aerospace©
Unisys/Sperry©
IBM Raleigh
DEC (VMS)
Systems Means
Japanese (*)
U.S.
OVERALL MEANS
JAPANESE
U.S.
(*)
98%
RANKINGS: TECHNOLOGY/FACILITY INFRASTRUCTURE
8 Questions; 32=100%
RANKINGS: POLICY/METHODOLOGY INFRASTRUCTURE
15 Ql
RANKINGS: TOTAL FACTORY MODEL
23 Qi
APPENDIX
TOSHIBA AND NEC
II:
Toshiba
Toshiba,
since
has
the micl-1970s,
been the other Japanese leader
in
pursuing factory practices, focusing on large, real-time control programs and
Factory
article
software for
systems
related
industrial
Tokyo had about 2300 software personnel
in
written
in
1981
Software
Toshiba's
connected
1985.^^^
in
A major
by the manager primarily responsible for developing
the Toshiba facility also cited the
buildings
The Fuchu Software
applications.
SDC
factory experiment as
contained
Factory
about
200
precedent.
a
terminals
1 1 fi
'"
three
in
One building focused on
by high-speed data buses.
software design, another on software and hardware design, and the third on
systems testing.
The factory infrastructure
software workbench
SADT
tools:
system
(structured
analysis
(computer-aided specification
plus
input-process-output);
system,
to
generator,
facilitate
to
for
analysis
proven
software
in
1977,
comprising
requirements
(program
combining
newly
and
CASD
HlPO (hierarchy
information
programs);
a
main
five
definition);
and documentation);
PROMISS
reuse of
generate
developed
first
revolved around "SWB,"
itself
management
SYSGEN
written
(system
modules
and
standard modules).'"'
The reuse
strategy.
of
software
modules
was
central
To create an environment fostering
83
to
Toshiba's
reusability,
Toshiba
factory
relied
mainly
management,
on
example,
was
it
an
counted
abstraction,
same
defined
cataloging of modules
Toshiba did not
83% of
and
assembler,
None
of
of
design
interfaces
infrastructure.
registration
written
code
technology,
and
Toshiba
parameters,
program library.^
11%
written
a
in
in
proven
'^
productivity
in
as
stressed
1981,
In
and
PL/I,
careful
about
6%
in
these languages were specifically designed for data or procedural
(which
abstraction
useful for reusability),
is
using Ada to describe program structures,
languages such as Prolog, APL, and Basic.
although,
in
Toshiba was
1984,
before building prototypes using
'^'
Based on the extensive reuse of code, Toshiba doubled productivity
Fuchu
the
Software
Factory
after
1976,
with
programmers,
according
to
a
U.S.
'"^^
as
programs.
this
70 to 80%
'^'^
extensive
in
1985,
in
and
some years (such as 1981), was reused from other
Along with the high rates of nominal productivity, moreover,
recirculation
of
debugged modules allowed Toshiba
merely 0.3 bugs per 1000 lines of code.''^^
large
contrast,
At Toshiba, over
50% of the 3100 lines of code produced per programmer month
much
In
Deptartment of Commerce study,
typically produced about 300 lines of code per month.
as
at
programmers producing 3100
assembly-language equivalent instructions per month by 1985.^^^
U.S.
at
language. '^^
system description
machine-oriented
data
The languages used
FORTRAN
real-time
as
well
themselves facilitate reusabiity, however.
in
of
For
programmers and managers, reused
to
newly
factory
"promote
to
as
for the
code was
the
policy
terms
In
clearly
supporting
As an incentive
the
measurements. ^°
a
official
programs and reuse."
code
with
IBM projects showed an average
84
of
3
By comparison,
errors
per
line
a
of
to
report
study of 60
code
--
10
1
9fi
times greater than Toshiba.'''"
PRODUCTIVITY AT TOSHIBA'S FUCHU SOFTWARE FACTORY^ 27
Year
employees and managers
Source:
Fujino,
NEC
design
total
a
formulated
support
the basic plan
in
The
consisting
1980,
for design,
three subsystems:
for
SDMS
of
practical
first
intending
1975,
in
system for the development
modularized systems software.
in-house use
a
SDMS (Software Production and Maintenance
system called
factory-type
NEC developed
software and complex on-line programs,
For systems
System).
58.
p.
and
to
maintenance of
version was released for
software development data base and
a
including
a
standardized design language and
programming methodology; for product management (configuration, updating,
and
retrieval);
project
for
management,
progress
including
control
and
productivity data.'-^^
NEC
reported some resistance to adopting the standardization
by SDMS, but by 1984
it
was installed
in
all
NEC computer
required
Several
centers.
For
experimental projects have also demonstrated significant improvements.
example,
using
in
the design of a comptroller system with
SDMS showed
projects,
including
twice
the
the
productivity
overseas
of
compared
system,
In
engineers
comparable
to
before
errors
more than 90%
which previously were written by hand.
switching
data base,
discovery of 90% of the design
programming phase, and automatic generation
documents,
rates
a
the
of the design
maintenance of an
SDMS helped reduce man-hours
in
producing
upgrades and revisions by 90%.^*^^
For applications
software,
NEC began developing what
86
it
calls
STEPS
(Standardized Technology and Engineering for Programming Support)
completing
version for in-house use
a
basic concepts
considerable input as well
with
year thereafter,
STEPS are
of
the entire software development
life
and then
(2)
documentation,
etc.,
NEC through
within and outside
improvements
in
specification,
NEC:
S
=
NEC
At 800 sites
reported productivity
reported 20% to 50% cost reductions
in
program manufacturing
MD
=
Man-Days
T
=
Compile Time for Debug
in
1*??
phases.'"'-'
1981
PRODUCTIVITY
IMPROVEMENT
NON-STEPS
S
431
286 S/MD 361 S/MD
218 S/MD 416 S/MD
68 S/T
92 S/T
64 S/MD 101 S/MD
Coding
Debugging
TOTAL
Azuma and Mizuno
application
of
(1981),
its
p.
1.26
1.91
1.35
1.53
95.
"traditional"
software can be seen most clearly
is
NEC survey
standard
Source Code Number
Specification
function
"prefabricated
STEPS PRODUCTIVITY SURVEY,
Average Program Size 458 S
NEC's
a
and debugging of between 26 and 91%
coding,
STEPS
Source:
of
new programs J*^^
of
an
analysis-design phases and 50% to 80%
Key:
use
the
1980,
At 1200 sites by 1984,
(Table).
The
standards for methodology,
with
cycle,
facilitate the writing
program library" to
from outside users.
promote integrated standards covering
to
(1)
1971,
revising the system each
1972 and
in
in
in
manufacturing
quality control.
techniques
to
Administration of this
linked directly to computer hardware "zero defect" activities and
extends down to programmers organized, as
into quality circles.
in
hardware production
Since around 1981, these have been meeting
87
2
facilities,
hours per
week, and applying tools such as data sorting, control charts, pareto charts.
133
and cause-effect diagrams to software projects
Some results are
as
follows:
NEC SOFTWARE QUALITY CONTROL RESULTS
GROUP DIVISION
Switching
1
TARGET
RESULTS
Machine time
Down
Bug
Transmission
2
1/3
debug
for
1.37/KS to 0.41/KS
ratio
control
3
Minicomputers
4
Large OS
Large Appli-
5
Bug Ratio
0.35/KS to 0.20/KS
Bug
Source Size
6/Month to 0.9/Month
20KS to 8KS
Object Size
72KB
Spec changes
Down 40%
ratio
to
26KB
cations
Source:
Mizuno (1983),
p.
71.
Along with developing their own technology, NEC engineers extensively
including SDC's estimating model and
studied American software techniques,
then the Software Factory during the 1970s as approaches to cost-estimation
and project control. ^^
factory-type
layout
productivity ^^^
.
Engineering
factory
In
During the mid-1980s, NEC also launched
environments
addition,
Laboratory
realization"
publicly
the
for
manager
stated
engineers
software
in
of
a
NEC's
1984
a
to
Software
article
that
study of
improve
Product
"software
was one of the most important areas "[c]ompanies that
expect to meet future demands must direct their efforts to."'''"
88
REFERENCES
1.
The main paper from
is Michael A. Cusumano, "The
An Approach to the Strategic Management
Management 1987 Working Paper #1885-87.
this research project
'Software Factory' Reconsidered:
of Engineering." Sloan School of
,
Another completed case is "A U.S. 'Software Factory' Experiment: System
Development Corporation." Sloan School of Management 1987 Working Paper
,
#1887-87.
The respondents for Hitachi Software Works were Shibata Kanji,
Engineering Department Manager, and Yokoyama Yoichi, Senior Engineer; for
Omori, Tsuda Michio, Senior Engineer.
2.
3.
Toyo
Keizai,
Kaisha shikiho (March 1986).
Japan Economic Journal 7 June 1986, p. 14; and, for market share data,
"Nihon no konpyuta setchi jokyo," Computer Report (in Japanese), January
4.
,
1985, p. 78.
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.
5.
6.
Japan Economic Journal
,
7
June 1986,
p.
14.
7. Dale F. Farmer, "IBM-Compatible Giants," Datamation
96-97, 104.
8.
"2
p.
D5.
New Computers from IBM
,
December 1981, pp.
The New York Times
Rival,"
,
12
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).
9.
RCA, Control Data, IBM, and NCR
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
10.
in
1958.
"
,
I
January 1985.
11.
Takahashi interviews.
12.
Shibata interview, 9/19/85.
89
,
Hitachi Seisakusho, Yuka shoken hokokusho March 1985, pp. 16-17; Hitachi
Ltd., "Outline of Hitachi. Ltd." (1984); "introduction to Hitachi and Modern
13.
,
Japan,"
14.
12.
p.
These
will
be discussed
in
a
later section.
Ml movement at several Hitachi factories (although
including the Software Works) is Iwai Masakazu, Hitachi-shiki keiei
kakushin: Ml undo no kenkyu (Tokyo, Daiyamondo-sha, 1983.
15.
A recent book on the
not
16. Hitachi Seisakusho,
of the Software Works)
17.
Sofutouea Kojo
,
p.
Sofutouea kojo no 10-nen no ayumi (10-year history
(Kanagawa, 1979), pp. 118, 179-184.
198,
202.
Hitachi no seisan
Nihon Noritsu Kyokai (Japan efficiency association), ed
MST seisan shisutemu no zenbo (Hitachi's production revolution-kakumei
MST
the full story of the MST production system) (Tokyo, 1982), p. 32.
stands for "Minimum Stocks/Minimum Standard Time.
18.
.
,
—
19.
Shibata and Yokoyama interview, 7/23/86.
20.
Sofutouea Kojo
21.
Takahashi interview.
22.
Sakata interview.
23.
Minamisawa Noburo, Nihon konpyuta hattatsu-shi (Nihon Keizai Shimbun1978), chronology.
sha,
,
pp. 51-52.
See also Sofutouea Kojo
,
tables on pp. 49-50.
Shimada Shozo, "Hitachi no gijutsu (2): kaihatsu-ki (HITAC 5020)-20 nen no ayumi (Hitachi Ltd.
sofutouea," in HITAC Yuza Henshu llnkai, ed.
kaihatsu-ki
Also, Murata Kenro, "Hitachi no gijutsu:
1983), pp. 27-29.
(HITAC 5020, 8800) -- hadouea," in HITAC Yuza linkai, p. 22.
24.
,
25.
Usui Kenji,
"HITAC kaihatsu
shi
(2),
p.
37.
Takahashi interview, 1/9/85; Usui Kenji, "HITAC kaihatsu
Computopia July 1975, p. 37; Sofutouea Kojo, p. 53.
26.
shi
(2),"
,
Hitachi Seisakusho, Kanagawa kojo 15- nen no ayumi (1978), p. 40. Since
EDOS continued 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.
27.
28.
Sofutouea Kojo
,
pp. 54-56.
29.
Sofutouea kojo
,
pp. 56, 130.
90
memo
30.
Hitachi
31.
Cite Takahashi,
Cusumano,
to
August
21
documents on
this,
1985.
etc.
32. Hitachi Seisakusho, Hitachi Seisakusho shi Vol. 3, 1971, pp. 55-56, 223224; Usui Kenji, "HITAC kalhatsu shi (2)," pp. 36-38; Kanagawa kojo 15 nen
no ayumi (1978), pp. 45-47.
.
33.
Minamisawa, pp. 154, 163.
34.
Usui,
"HITAC
kaihatsu shi (2)," p. 36; Sakata interview.
35.
Usui,
"HITAC
kaihatsu shi (2), p. 30. Footnote other sources.
36.
Usui (2), p. 31; Sofutouea kojo
37.
Sakata interview, 9/10/85.
38.
Usui (2), pp. 36-37; Sofutouea kojo
39.
Sofutouea kojo
p.
,
,
pp. 50-51; Takahashi interview, 1/9/85.
;
pp.
17,
129.
23.
40. Sofutouea kojo
pp. 21-22; Kanagawa
pp. 18-22, 69. The English
translation Hitachi uses is "Software Works," although the Japanese word for
"works" (kojo) is usually translated as "factory" and has this connotation in
Japanese.
An analysis of the Odawara Works can be found in Hitachi
Seisakusho Odawara Kojo, Odawara Kojo 10 nen shi (Kanagawa-ken, Hitachi
Odawara Kojo, 1977).
,
,
41.
Sofutouea kojo
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; and Sofutouea kojo
47.
Sofutouea kojo
48.
Shibata interview, 9/19/85. See also Sofutouea kojo
49.
Sofutouea kojo
50.
Shibata interview, 9/19/85.
51.
Sofutouea Kojo
,
pp. 4-5, 8.
,
119.
p.
.
,
,
p.
p.
113.
192.
91
,
p.
5.
52.
Hitachi Software Works,
Memo, July 1986.
Shibata interview, 7/23/86; and Sofutouea
contains organization charts from 1969 to 1979.
53.
54.
Sofutouea kojo
kojo
,
pp.
192-202,
which
pp. 127-128.
,
55.
Sofutouea kojo
,
p.
56.
Sofutouea kojo
,
pp.
164-165; Shibata interview, 9/19/85 and 7/23/86.
57.
Sofutouea kojo
,
pp.
160-161;
58.
Sofutouea kojo
,
pp.4-11, 166.
59.
Sofutouea kojo
,
p.
128.
118-119; Shibata interview, 7/23/86.
156.
Sofutouea kojo
pp. 113-114; Hitachi Memo, "Table 1: History of
Production Control at Hitachi's Software Works"; Sakata interview; Shibata
interview, 9/19/85 and 7/23/86.
60.
,
61.
Sofutouea kojo
62.
Sakata interview; Shibata interview, 9/19/85 and 7/23/87.
63.
Interviews with Shibata and Yokoyama
64.
Shibata interview, 9/19/85.
65.
Sofutouea kojo
66.
Shibata interview, 9/19/85.
67.
Sakata interview.
,
,
p.
pp.
114.
114-115.
Frederick P. Brooks, Jr., The Mythical Man-Month:
Engineering (Reading, MA, Addison-Wesley, 1975), pp.
68.
69.
Essays pm Software
16,
31.
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. 284-291, in
Denshi tsushin qakkai ronbun shi (Transaction of the institute of electrical
and communications engineers. May 1974, Vol. 57-D, No. 5.
70.
ni
71.
Shibata interview, 9/19/85.
92
72.
Sofutouea kojo
,
p.
115.
73.
Sofutouea kojo
,
p.
115;
74.
Shibata interview, 9/19/85.
75.
Sakata interview.
76.
Sofutouea kojo
,
pp.
Shibata interview, 9/19/85.
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.
77.
.
Project Reuse Rate = Number of Reused
Definitions of reused code:
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.
78.
I
79.
Sofutouea kojo
,
p.
80.
Sofutouea kojo
,
pp. 7-8,
81.
Shibata interview
82.
Sofutouea kojo
83.
Hitachi
,
p.
117;
Yokoyama interview.
124.
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 Papgers- -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), pp. 1-6.
84.
,
.
85.
Interviews with Shibata and Yokoyama, 7/23/86 and 9/19/85.
Kataoka Masanori, Hagi Yoichi, and Nogi 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
System Development Laboratory.
86.
.
87.
Interviews with Shibata and Yokoyama, 7/23/86.
93
88.
Kataoka Masanori,
Hagi Yoichi, and Nogi Kenroku,
"Sofutouea kaihatsu
(CASD shisutemu)" (Computer Aided Software Development
shien shisuternu
System, CASD), Hitachi hyoron
Vol.
.
62,
No.
12
(December 1980),
p.
33.
pp. 33-34.
89.
Kataoka et
90.
Kataoka, p. 34.
91.
Kataoka et
al.,
pp. 35-36.
al.,
Shibata Kanji and Yokoyama Yoichi, "Sogo sofutouea seisan kanri
shisutemu 'CAPS'" (Computer Aided Production Control System for Software),
Hitachi hyoron Vol. 62, No. 12 (December 1980), p. 37.
92.
.
93.
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'), Hitachi hyoron 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 overal 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
94.
.
effort.
95.
Shibata and Yokoyama, pp. 39-40.
Shibata and Yokoyama, p. 40-42. A version of CAPS was available for
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 system was not
96.
sold commercially.
(Shibata interview, 7/23/86.)
97.
Shibata and Yokoyama, p. 42.
98.
Interviews with Shibata and Yokoyama, 7/23/86.
99.
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"
100.
(Software Engineering Methodology for Development of Application Systems
'HIPACE'), Hitachi hyoron 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
hyoron Vol. 68, No. 5 (May 1986), pp. 34.
.
.
94
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.
101.
102. 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.
.
.
103. Hagi Yoichi (Hitachi Software Works) et al., "Shisutemu kaihatsu shien
sofutouea EAGLE'" (Integrated Software Development and Maintenance System
'EAGLE'), Hitachi hyoron Vol. 66, No. 3 (March 1984), pp. 19-24.
.
"Shisutemu kaihatsu shien sofutouea 'EAGLE'-2'"
(Integrated Software Development and
Maintenance System 'EAGLE'
the Enhanced Version of EAGLE, 'EAGLE 2),
Hitachi hyoron Vol. 68, No. 5 (May 1986), pp. 29-34.
104.
Hagi
Yoichi
et
a!.,
EAGLE kakucho-han 'EAGLE
.
105.
106.
'86
Source for this table
is
Hagi et
al.
(1986),
p.
34.
See Hitachi Seisakusho, '"86 shitemu/sofutouea no Hitachi gurupu" (The
Hitachi group for systems and software)
107. Denji Tajima and Tomoo Matsubara (Hitachi Software Engineering), "The
Computer Software Industry in Japan," Computer May 1981, p. 95.
,
Denji Tajima and Tomoo Matsubara, "Inside
Industry," Computer March 1984, pp. 36-39.
108.
the
Japanese
Software
,
109.
Tajima and Matsubara (1984), p. 40.
Cusumano and David E. Finnell, "A U.S. Software
System Development Corporation " M.I.T. Sloan School
Working Paper #1887-87, 1987.
See Michael A.
Factory' Experiment:
110.
of
Management
,
.
111. For a discussion of Toyota see Michael A, Cusumano, The Japanese
Automobile Industry:
Technology and Ma n agemen t at Nissan and Toyota
(Cambridge, MA: Harvard University Press, 1985). This comparison is also
examined in more detail in "Toward the Strategic Management of
Engineering:
The Software Factory' Reconsidered
"
112.
McNamara estimate.
113.
Shibata interview, 7/23/86.
114.
Abbreviated from Farmer,
p.
97.
95
See Yoshihiro Matsumoto, "A Software Factory: An Overall Approach to
Software Production" (2 December 1986), forthcoming in Peter Freeman, ed..
Software Reusability (IEEE Tutorial, 1987); Y. Matsumoto et al. (Toshiba),
"SWB System: A Software Factory," in H. Hunke, ed.. Software Engineering
Environments (Amsterdam: North-Holland, 1981), pp. 305-318; "New Toshiba
Software Facility Spurs Productivity," Toshiba Newsletter No. 256, November
1983, p. 1; K.H. Kim, "A Look at Japan's Development of Software
Engineering Technology," Computer May 1983, pp.31 -33; and Shimoda, pp.
115.
,
,
99-109.
Yoshiro Matsumoto (Toshiba), "Management of
Production," Computer , February 1984, p. 318 fn 2.
116.
117.
Industrial
Software
Kim, pp. 31-32; Matsumoto (1981), pp. 305-318; and Toshiba Newsletter
118.
Matsumoto (1981),
p.
308.
119.
Matsumoto (1984),
p.
68.
120.
Matsumoto (1981),
p.
308.
121.
Matsumoto (1984),
p.
65.
122.
Kim, p. 33; Matsumoto (1981), p. 308.
.
123. A Competitive Assessment of the U.S. Software Industry p. 11. Other
productivity data for a variety of U.S. projects can be found in Martin
Shooman, Software Engineering: Design, Reliability, and Management (New
York: McGraw-Hill, 1983), pp. 438-445; and Frederick P. Brooks, Jr., The
Mythical Man -Month:
Essays pm Software Enginee ring (Reading, MA,
Addison-Wasley, 1975), pp. 88-94.
,
124.
Calculated from data
125.
Kim,
32;
p.
Technology
,
in
Matsumoto (1981),
p.
308.
Robert Haavind, "Tools for Compatibility," High
August 1986,
p. 41.
126. Cited in Shooman, p. 326.
A Competitive Assessment of the U.S.
Software Industry p. 11, also cites data that Japanese programmers produce
one-tenth the bugs of U.S. programmers.
,
127. Sources: Kim, p. 33; and Yoshihiro Matsumoto, 'A Software Factory: An
Overall Approach to Software Production" (Toshiba Corporation, December 2,
1986), p. 5.
128.
Kiichi Fujino
at
Communication
(NEC), "Software Development for Computers and
NEC," Computer
,
November
1984,
pp.
57-58.
Uenohara Michiyuki (NEC) et al., "Development of Software
Production and Maintenance System," Research and Development in
Japan Awarded the Okochi Memorial Prize (Okochi Memorial
Foundation, 1984), pp. 26-27; and Kanji iwamoto (NEC), et al.,
129.
96
"Early Experiences Regarding SDMS Introduction into Software
Production Sites," NEC Research and Development January 1983, p.
,
51.
130.
Uenohara
et al.,
p.
32.
131. M. Azuma and Y. Mizuno (NEC), "STEPS: Integrated Software
Standards and its Productivity Impact," Proc. Compcon Fall 81
September 1981, p. 83.
(IEEE),
132.
Fujino,
133.
1983,
YukioMizuno, "SoftwareQuality Improvement,
p.
59.
"
Computer March
,
pp. 69-71.
Mizuno interview; and Iwamoto Kanji and Okada Masashi (NEC),
"Purojekuto kanri no tsuru" (Project control tools), Joho shori
Iwamoto was a
(Information processing), Vo. 20, No. 8, p. 721.
Laboratory,
Computer
Systems
Research
part of the
member of the
Central Research Laboratories; he joined the Software Product
Engineering Laboratory when NEC created this in 1980. Okada was
then in the systems engineering department of NEC Software Ltd., a
134.
subsidiary.
135. See K. Honda et al. (NEC), "Research on Work Environment for
Software Productivity Improvement," paper submitted at the Compsac
'85 conference.
136. Interviews with Azuma (NEC), 10/1/86, and Yamaji (Fujitsu),
7/31/86.
See also Kiichi Fujino (NEC), "Software Development for
Computers and Communication at NEC, " Computer November 1984, pp.
61-62.
,
97
tt53H
038
Date Due
^M^Z
^n i^^ m
'I
{S^
Lib-26-67
MIT LIBRARIES
3
TDfiD
DOB 125
52fl