1
1
^?!
V
fu.
/
)
\i
I-
S.I<
'^\^
<'0S«'
I
v/
:r:'^
f ^&
4
ZSMf<
\^s
'^
y
" 1*
^
'^^M^
aD2G
.i'A14
NOV 12 1987
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
Toshiba's Fuchu Software Factory:
Strategy, Technology, and Organization
Michael
October
6,
1987
A.
Cusumano
WP //1939-87
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
Toshiba's Fuchu Software Factory:
Strategy, Technology, and Organization
Michael A. Cusumano
October
6,
1987
WP //1939-87
"^OV
]
2 ,987
Michael A. Cusumano
MIT Sloan School of Management
10/6/87
Software Project Paper #4
TOSHIBA'S FUCHU SOFTWARE FACTORY:
STRATEGY. TECHNOLOGY. AND ORGANIZATION
INTRODUCTION
This paper
or
not
such
part of
is
companies
are
considerations
and
choosing
manage
to
a
complex
development with
software
large-scale
as
larger study examining the question of whether
a
organizational
as
well
as
of
job shops,
flexibility
in
technological
of
in
the U.S.
technology
these criteria;
implementation
and Japan
to
strategic
approaches
that
"hard" manufacturing,
The research project
technologies.
and
policy
factory environment for software might look like;
facilities
of
activity
and factories exhibiting various degrees
and
product mixes
proposal
the
includes
batch organizations,
range
a
corresponds to the spectrum usually associated with
i.e.
engineering
a
criteria
survey
what
defining
a
of major software
determine where firms stand
in
relation to
and detailed case studies examining the technology and policy
process
followed
at
firms
identified
as
being
close
to
the
factory model
There are several interrelated conclusions:
"factory"
facilities
in
software as
and
approaches,
is
the U.S. and Japan.
a
structures
more effectively, even with
(3)
(2)
in
There appears
This spectrum, including
the
sample
of
software
to be nothing Inherent in
technology that prevents some firms from creating strategies
organizational
software.
observable
clearly
(1)
a
to
manage product and process development
relatively
new and complex technology such
The basic technological infrastructures
as
to aid software process
management are not significantly different between Japanese and U.S.
(4)
--
But, Japanese firms
by Hitachi and Fujitsu
by the NEC group and Toshiba, and followed
led
are significantly ahead of most U.S.
--
implementing
"flexible
standardized
components
firms.
type
factory"
(modules
and
code)
of
focused
strategies
of
competitors
then
in
reusing
on
end
customizing
products.
This paper extends the survey approach to analyze what
--
most difficult aspect of the software factory
and the benefits or disadvantages
The Toshiba case
One,
personnel
like
and NEC,
Hitachi
software
its
in
his
operation,
Factory
within
a
factory
the
operation.
in
was
who
originally
own
focused
The center
established
the
In
Matsumoto directed the founding
Fuchu Works,
which
reusing
on
developing
for
computer division,
A senior engineer. Dr.
factory,
while the
1977,
software
rationalize
Factory experiment and cited
efforts.'^
company's
to
Toshiba's
not
shortage of skilled
a
organization
programs.
technology
SDC Software
influenced by the
still
of
attempt
to
heavy industrial equipment division.
Matsumoto Yoshihiro,
article to justify
lines
market demands and
semi-customized
engineering
however, but
process
implementation
the
environment might offer
managers
Toshiba
influenced
produce
probably the
significant for several reasons.
is
development alone the
code to
this
is
of
was especially
SDC
in
a
1981
SDC experiment was
a
Software
Toshiba
manufactured
hardware
and software systems for nuclear power plants, electric power plants, factory
automation, as well as elevators and transportation equipment.
Second,
occurred
at
paradigm and
rather than end the effort midway when difficulties arose,
SDC,
or
display
reusability,
as
at
a
reluctance
Hitachi
or
to
overemphasize
Fujitsu,
the
as
factory
Matsumoto continued
to
develop the facility's technological and management systems to support the
objective
producing
of
The Toshiba factory
standardized
1987,
in
largest dedicated software facility
and
remarkably
rationalized
with
components
standardized
a
in
programmers,
2300
was
format.
probably
the
the world, with highly focused products
in
procedures,
factory
especially
in
the areas
of
testing and the generation and reuse of standardized software components.
A third
the
factory
significant
tool
aspect of this case
is
that Toshiba
and development approach
set
the broad applicability of the strategy,
product
software
to
Success
outside of industrial control applications.
has transferred
this
in
areas
transfer reflect
technology, and management systems
Toshiba has devised for large-scale software engineering.
I.
ORIGINS AND ORGANIZATION OF THE FUCHU SOFTWARE FACTORY
Corporate Setting
Toshiba's founding dates back to 1875 and the establishment of
firm that manufactured communications equipment.
affiliated
of
U.S.
the
Toshiba
had
equipment
Both
grown
and
subsidiaries).
mainly
the Mitsui group
with
among
relationships
to
in
Japan and
continued
become Japan's
appliance
manufacturer,
in
into
second
with
1910 with
electronics
largest
70,000
by which time
general
employees
in
and household appliances (31%); heavy
electrical
electrical
(excluding
1986,
and electronic components,
computers and office automation (33%); consumer products,
video,
General Electric
1980s,
Total worldwide sales were about $20 billion
industrial
small
1904 the firm became
In
the
a
divided
including
including audio,
apparatus,
including
power plant systems,
behind
fourth,
Japanese
1978,
in
programmers
and
minicomputers
be
to
a
major
were
designers
microcomputer
and
in
various
throughout the corporation.
the corporate
R&D
level
in
software,
MIS
in
Software
the
at
six
tool
and the Fuchu
the
producer
leading
of
office
of
but withdrew from
software
engineers
and
Fuchu, which alone had 2300
plus
another
1000
software
factories
(see
Factory
smaller
(management-information
Most
was
development partner, NEC.
11,000
These were located
Toshiba.
and
approximately
it
comprehensive manufacturer
a
selling this business to its
there
in
programmers
1),
although
Hitachi,
ranging from small machines to mainframes,
1987,
developing
of
and
The company used
computers,
mainframes
NEC,
Fujitsu,
producer
equipment.
Table
and factory automation systems
equipment,
Among Japan's domestic computer manufacturers, Toshiba ranked
(26%).
In
industrial
systems)
activities
and method development was done
Plant."*
at
Table
1:
TOSHIBA SOFTWARE FACTORIES
Facility
Software Product Area
Fuchu
Real-Time industrial Applications
Ome
Office Automation
Hino
Telecommunications
Komukai
Defense Systems (radar, satellites)
Yanagimachi
Automatic Dispensing Machines (banks, railway tickets)
Nasu
Medical Systems
Isogo
Home Appliances
Source: Matsumoto interview.
The Factory Strategy
The establishment
connected
the
with
Fuchu
the
of
characteristics
Toshiba's
of
Factory
Software
industrial
was
directly
systems
control
business, which dates back to the use of electro-magnetic relays prior to the
use
transistors
of
for
became
development
microprocessor
4004
using
large
a
area
in
of
and
1971
in
microprocessor
a
application
this
from
Fuchu Works's
Major
1974.
the
after
activity
the
mid-1960s.
the
introduction
first
functions
Software
control
system
control
industrial
of
the
of
systems that involve extensive software writing are processing the relevant
data
to
the
control
production
equipment;
serving
an
as
human operators and the machinery; and providing
interface between
sufficient information on
production levels, inventories, plant conditions, etc., to serve as an interface
for management.
According
programmers
to
c
to
was
it
primarily
prompted the idea
of
"off-the-shelf"
of establishing a
Orders
rapidly from 1977.
for
process-control
by the
Corporation's
mid-1970s
on
shortage
software
computers
these
Regarding ways
1975
article
to
AT&T, which used
Programmers'
Toshiba
to rationalize software
in
that
Work
increasing
development using
Matsumoto was also very much
as
Bench
the Unix operating system.
system Matsumoto patterned after the
began
Computer on the System Development
Software Factory experiment,
the
minicomputers
software factory focused on productivity
factory approaches and work bench systems,
influenced
a
meet the demand to Toshiba for customized programs caused
by the popularity
improvement.
Matsumoto,
AT&T
Quality control was secondary but
still
as
by an
system
(PWB)
well
The name
article
the
in
developed
of Toshiba's
at
SWB
system.'
important motivation behind the
Customers were mainly sensitive
establishment of the factory.
and did not directly see the impact
according to Matsumoto,
improvements
decided
along
hardware and
the
with
The cost
development.
software
in
not
On the other hand, Toshiba
projects.
because of the
productivity
impact
this
had on
its
was
software
separated
specifically
internally was
productivity
of
the
of
quality,
to
most
by
affected
directly
capacity
for
handling
for
software orders."
A
example
typical
problem
the
of
Toshiba
faced
was
order to
an
develop the hardware and software for what would be the world's first fully
power generating
automated thermal
software
into
requirements
reliability
were
extremely
Hirano
the
Electric,
several
To achieve safe and untended operation,
code.
of
lines
Tokyo
for
require software running
Not only did this
Plant.
station
millions
of
hardware and
placing
stringent,
tremendous demand's on Toshiba software capabilities.
Hirano presented problems
became typical
As
Matsumoto
in
Toshiba projects as
of
noted
a
in
1981
utilities
rolling
steel
an
build
product
Fuchu
Tokyo
mills,
entire
at a
networks,
price that
Software
Software
the
processing factories,
still
to
maximizing
guaranteed Toshiba
opened
in
1977,
Factory's
main
such as nuclear power plants,
would be "disastrous."
dedicated
Factory
facilities
chemical
failures
facility
since
minicomputers increased.
of
sales
its
article,
products are real-time systems for
electric
and quality assurance that
productivity
prior
air
terminals,
and
Thus, they decided
assurance of the
quality
"a
to
moderate profit."^
the
to
completion
of
The
the
Electric Hirano project. ^^
As
a
strategy to improve productivity, quality, and cost control for the
Fuchu Work's entire software needs, management used the
set
of
tools
and
procedures
standardized
developed
under the
development
areas Fuchu served:
that
the factory
environment
heavy
industrial control systems.
concept
Software
electrical
Factory
the
for
rubric
three
provide
to
primary
applications
equipment, measuring instruments, and
Within a few years, Toshiba managers recognized
should
provide
useful
to
produce other types
software relatively inexpensively and with high quality.
the factory's design activities were extended to
control systems, factory automation,
a
Computer
IEEE
software
.
can
be
seen
broad range
of
process-
and measuring equipment software.''
The notion
"development"
lay
Matsumoto's comments
in
of
in
a
strategic
to
as
aspect
good
its
article
different
and
management"
as
well
in
from
supporting
to achieve this
was
as
technology
eclectic,
Quality, on the
was seen as linked directly to human performance, and
"people
tools
producing software by reusing as
using any type of concepts or tools that furthered this goal.
other hand,
1984
a
commitment,
The way
existing components as possible.
in
production"
"factory
technological and policy infrastructures,
many
of
By the early 1980s,
The philosophy underlying the factory organization, including
and procedures,
a
in
this
management were
considered essential to effective operation of the factory:
Software production is distinct from software development in that
production management is directed toward the use of existing software
and enforces the idea that designers should build new software from
existing codes.
The software life-cycle model and various software
engineering techniques based on the model are therefore worthwhile
However, other
from the viewpoint of production management.
development systems deviate from the life-cycle approach, such as
prototyping and program generating, that are equally important and
vital to the development of new software.
The concept of 'levels of
abstraction' is applied to both early design and manufacturing phases in
order to incorporate these techniques.
In order to manage traces between different abstract levels, modularity
or encapsulation in the requirements and design levels is considered.
Modularity in the early stages of software development aids in the
reuse of existing modules and prototyping.
However, human factors in
8
software management are becoming increasingly important; therefore
human-oriented reviews and inspections are being applied to increase
software reliability. '^
Another central notion
not
be dependent on
factory
approaches
factory
approach
technological
tools
and
production,
to
of
the factory was that product quality
performance.
individual
quality
to
at
to
support
however,
all
was standard
was
aspects
commitment
the
software
using
to
development
software
of
most
in
What distinguished the
control.
Toshiba,
This
should
and
improve quality through compensating for differences
the ability of individual engineers, as Matsumoto noted
1986 paper:
a
in
in
The path from requirements
definition to conceptual design primarily
requires the intellectual ability of the engineer.
Supporting this part is
believed to produce the greatest achievements In quality improvement
by leveling off the engineers' ability [my italics]
Support for this
part, however, was considered technically difficult.
Fortunately, the
recent progress in work stations and knowledge engineering helped to
support elements are added to the
solve this problem. As a result,
SWB system. ^^
.
.
.
.
For example, one of the tools Toshiba developed was
simple command,
which, with
a
"do
for
while"
different
parameters,
editor,"
"lexical
automatically displayed constructions such as
Programmers then
languages.
different
a
without
having
to
study
simply
grammar
the
of
filled
in
different
languages and risk making coding errors. ^^
According
to
Kado Tadao,
in
1982
the
manager
of
the
engineering
administration department at the Fuchu Plant, due to improvements
and
rationalization
of
"asset
has been able to handle
important
to
Kado
in
in
this
management," the volume
of
in
quality
work the factory
1986 was triple that of the original plan.
long-term
productivity
improvement were
Most
(1)
of
selection
good quality software engineers;
and methods;
system.
and
(3)
creation
of
a
development
(2)
of
good
tools
good working environment and training
1 'S
The Factory Structure
Matsumoto defined
allows
install,
attain
a
"software
factory"
"an
software manufacturing organizations to design,
and maintain commercial software products
specified
departmental
quality
divisions,
and
productivity
tool/facility
will
inf rastructural
be elaborated on
elements
in
and
in
a
environment
which
program, test,
ship,
unified
Apart
levels."
management implemented
combination of 14 elements or systems. "
which
as
manner ... [and]
from
the
formal
through
the
These can be broken down
into
its
strategy
management-personnel
systems,
the subsequent sections of this paper (Table
2):
10
Table
2:
ELEMENTS OF THE TOSHIBA SOFTWARE FACTORY
Tool/Facility Infrastructure
Specially designed
work spaces.
Software tools, user interfaces and tool maintenance
facilities.
Existing software library and maintenance support for this.
Technical data library.
Standardized technical methodologies and disciplines.
Documentation support.
Manaqeinent/Personnel Systems
Project progress
management system.
Cost management system.
Productivity management system.
Quality assurance system with standardized quality metrics.
A
standardized,
baseline
management system for design
review,
inspection and configuration management.
Education programs.
Quality circle activities.
Career development system.
Matsumoto
An Overall Approach
Source: Yoshihiro
(Toshiba
Corporation),
"A
Software Factory:
Freeman, ed..
to Software Production," in Peter
Reusability (IEEE Tutorial, 1987), p. 1 (2
Software
manuscript)
December 1986
The Software Factory employees performed some system engineering but
focused on detailed design, programming, testing, quality assurance, project
management,
installation,
plant-site
alignment
11
and
maintenance.
Volume,
by
measured
shipments
software
lines
systems,
of
source
excluding
code),
EASL (about 700,000
software project was 4 million
and the range was
customers
hardware,
utility
included,
usually
the
in
software
application
million
as
operating
size of an application
source code),
of
lines
Projects generally consisted of 150 to 300
and took more than three years
real-time tasks
to
EASL.
to 21
1
such
software
basic
7.2
1986-1987 (about 1.3
in
and language processors. The average
utilities,
about
totaled
(EASL) per month
equivalent assembler source lines
million
customers,
to
addition
and
to
Systems sold
complete.
to
computer and
subsidiary
application
peripherals
packages,
a
subsystem (database management systems, user interfaces, input-output
interfaces), and an operating system.''
The
(Figure
1)
consisted
of
combined floor space
of
facilities
with
a
1987
in
three
17,000 square meters.
two contained the terminals or work stations,
Work Bench (SWB)
individual
facilities,
documentation service center,
third
building
(in
the
a
rear)
file
interconnected
referred
to
as
storage stack room, and
contained
facilities
work area had an SWB terminal and CRT display,
at
U.S.
erect another building
add lap-top computers
a
Space and money constraints
approximately one terminal per four programmers,
programmers
firms
for
a
serve as terminals. "
lounge.
a
The
completed
Each individual
key board, and
a
small
the factory to
limited
compared
such as Hughes Aircraft.
12
first
the Software
testing
to
one each for
Toshiba had plans to
and increase the number of terminals,
to
The
work areas, an SWB service center,
software with hardware manufactured by other departments.
hard-copy printer. ^°
buildings
as
well
as
to
Individual area
I
har
I
So
.
3
Buildint (lest Are
7;
/I
'o/kuav
T-V
^
No.l Buildini:
I
U.»
L.
_
—
.
NO.;
B:
f
/'
/'
!
_>
L
Front side
An overhead view c:
the software factorv
A view of the software factory from front side
f;
Y
'
'
^
/
The
development
initial
beginning
1977.
in
infrastructure
(the
Fuchu Works,
the
actually first called
provide
single
a
six
technological
The SWB system was
^
SPS (Software Production System), and was designed
uniform
by
km apart),
people
software
the
of
the
at
from the Hirano project or even
funds.
corporate
and
interface
programmers
Toshiba factories
different
area (30 to 40
from
not
members
15
to
development
for
SWB system) came
but
10
of
general
located
were
hardware development
all
not
(including
support
centralized
distributed
at
Introduction of the system beginning
single location).
at
Funding
^
development
software
consisted
staff
Fuchu)
in
in
sites
to
for
(not
a
October 1977 was
the Tokyo- Kawasaki
making minicomputers and microcomputers.
The
brought together
the
one
in
since
location
were not centralized and company managers
activities
By
wanted programmers located
in
each factory.
supporting 600 programmers
at
these different sites,
50 on-line workbenches (150 planned by 1979).
1978,
the SPS system was
although handling only
^'^
Since the volume requirements for software were so high at the Fuchu
Plant,
and use
1986,
of the
the
terminals,
software.
to
"target"
test
SWB system occurred
most of the development of the
system was primarily
system was
connected
to
a
to
this
By
centralized layout (Figure 2).
accommodate 750 workbenches
central
facility,
computer which
or
processed
on-line
all
SWB
The data highway transmitted newly assembled or compiled code
computers being shipped to customers and made
the machines
dispersed
able
a
in
at
with
plant
SWB system,
around one minicomputer,
with
or
process
clusters
and the clusters
network. ^^
14
Toshiba also used
simulators.
consisting
all
possible to
it
of
several
connected
to
a
workstations
a
local
area
PLANT SIMULATORS
COMMUNICATION
CONCENTRATOR (CONNECTS BETWEEN
DATA-WAY AND TARGET COMPUTERS)
i
CONTROL
DESIGNERS'
WORKBENCHES
PROGRAMiMERS' WORKBENCHES
SVfE
CENTRAL
COMPUTER
Hardware Configuration of the Centiaiized
SWB
System
PLWa SIMULATORS
COMMUNICATION
CONCEWTRATOR(CONN£CTS BETWEEN
DATA-WAY AND TARGET COMPUTERS)
^
CONTROL
WORKSTATIONS
SWB
CENTRAL
WORKSTATIONS
Hardware Configuration
^V<n^^'^
3^
of the Dispersed
SWB
COMPUTER
Svsteiii
is
It
not.
important to
While
"factory"
note
was
really
structure of the
Fuchu
matrix
a
Plant,
support
environment
to
construction),
and testing.
but
accompanied
product
what the Toshiba Software Factory
well
about 2,300 workers
contained
it
as
organization
providing
software
a
set
design,
in
fixed
a
imposed
over
of
and
tools
systems
the
a
implementation
The software was generally
hardware
location,
not
a
produced
also
is
the
existing
development
(program
stand-alone
at
Fuchu.
Toshiba's conceptualization of the product development cycle was also similar
for
both
the
hardware and
software
developed (Figure 3).
16
components
of
the
systems
Fuchu
v^
I.
C
n
s
g
ul
C
71
c
0)
E
= c^
c
a;
>
IT
o
o
d
T3
O
I-
o.
21
E
^^
O)
>>
C
c
cr
c ^
5 Moi
ZT
1.
Vt
:^>
"TV
1.
If
Given
Software
matrix
the
although
Factory,
The
tools;
the
was
fifth
was
there
Four were
five large sections.
responsible
no
formal
a
organization
major
five
tasks:
SWB
service
promoting
center,
software
storage
room,
assurance
plans
file
quality
the
of
consisting
of
SWB
and
for
SWB
maintaining
the
system;
managing
(1)
developing new tools to be added to the
(2)
manager
single
charge of commercial software production.
in
for
was
there
structure,
SWB
all
the
(3)
facilities;
(4)
factory
and
entire
providing necessary assistance to keep this plans on track; and (5) measuring
and
accumulating
(quality)
reliability
data
metrical
responsible for overall
about 20 engineers;
the
for
productivity
evaluate
to
software factory.
entire
and
1987,
In
software
the
maintenance of the factory environment consisted
tool
development involved about 15 to
were formally part of the Fuchu Work's R&D
The Fuchu Works contained
staff.
several
staff
customer-site installation and customer claims,
as
The
20.
departments,
well
as
such
for overall
line
assurance,
however,
as
well
were located physically
System
engineers
manufacturing,
the
in
tool
set
Software
not
remained
move
in
to
the
different
line
quality
including
testing,
Factory
programmers
from
departments to the Software Factory with each project.
did
for
quality
building,
where
and other systems. -^^
moved with
part of the Software Factory,
as
The software designers and programmers,
and product control.
they made use of the factory's
for
as
latter
departments for
each product area; these departments included sections for design,
software,
of
'^'^
But the key organizations were
assurance and control.
hardware and
group
the
product-line
They then became
although they were considered specialists and
line
departments,
departments
outside
18
and their direct supervisors
the
software
facility.
Each
belonged to departments outside of the factory,
formally
project
project.
.
same
the
.follows
software factory once
it
disciplines
management procedures
and
becomes part of the factory."-^'
the
in
first
software
U.S.
factory
at
much
with
System
the
of
required
This
cooperative "matrix" management system that was attempted,
success,
but "each
a
less
Development
Corporation (SDC).28
To
effective
facilitate
software
the
of
utilization
the
facility,
Fuchu
Works's engineering administration department provided staff-level guidance
to
groups
the
from
manufacturing,
software
electric
factory,
and
preparation,
different
on
departments
applications
power generation,
methods
sewage treatment)
development,
program technique.
(such
Toshiba
steel
using
the
environment
equipment,
managers
as
referred
to
the
vertically-linked staff activities as the "product engineering system," and the
horizontally-linked industrial-sector activities as the "production engineering
system,"
both
management
being
in
"hard"
produced
products
example,
from
"implemented"
the
or
pursued
in
groups as well as
at
wrote
a
what Toshiba
industries
designed
engineering
"manufacturing"
In
of
"engineering
matrix
designs.
They received blueprints,
elsewhere.
organizations,
This
implementation
were places that mass-
traditionally
separation
was
also
and
of
one
then
constructed
design
from
for
or
program
a
software
Hitachi,
and NEC
model
varying degrees within the Fujitsu,
for
Toshiba.
Toshiba's case, system engineers,
the
an
calls
system.''^
Factories
factory,
part
requirements
specification
who interacted with customers and
and
high-level
designs,
remained
formally attached to departments outside the software factory and sometimes
19
outside the Fuchu Works.
Toshiba accomplished this by breaking down the
requirement
process
customer's
specifications
specific objectives
as
into
well
two
parts:
constraints
as
Part
to
was done by system engineers outside the Software Factory.
requirements,
its
operation
document done after analysis
structured
precisely
outlining
to
arrive
at
They
relation with the
customer
different programming
move
in
while
initial
the
projects
Factory
systems development (i.e.,
all
so
of
a
separate resource and moved around
needed;
as
was possible
this
methods and
in
do easily
Toshiba was even able
tools.
other divisions such as nuclear power
in
1987
to
operated
at
in
100%
sales.
For example,
capacity
for
power-
the designers and programmers from this area,
all
the
other areas such as railway systems and factory automation were not
busy,
sometimes
"handed
code.
to the
designs were being
which accounted for about 60% of the factory's revenues, were busy
time),
I
the system was completed. "^^
until
programmers from plants
Software
Part
a
responsibility for the projects and for
manufacturing that were experiencing drops
station
the
of
was
This was done by members of
week when the
a
also retained formal
because of the standardization
to
II
The system engineers, however, usually came
Programmers were considered as
to
Part
some performance parameters that Toshiba would
Software Factory several times
completed.
This
follow.
the overall functions of the program and simulating
then use for negotiating with the customer.
the Software Factory.
the
such as cost and time,
and particular methodologies the customer wanted Toshiba
more
included
i
and provided manpower
did
off"
their
the
addition,
customers
own high-level and even functional design,
and then
to
other areas.
documentation to Toshiba,
How much work the customers
did
20
In
which turned the designs into
depended on how
skilled they
were
in
software,
to
hide
well
as
from
as
Toshiba.
how much
example,
For
thirds of their programs themselves,
of
factory automation
systems
knowledge they wanted
of their propriety
steel
where
companies
wrote
generally
two-
auto manufacturers and users
as
asked Toshiba to do even high-level
usually
design. ^^
II.
THE TOOL SET
The Software Workbench System
Before
the
SWB system went
operation
into
development was largely done on punched cards,
The SWB system evolved
each project.
(requirements
and
definition
(detailed design and coding), testing,
set
of
linked
system
"^
.
support tools for design
programming
program design),
and program maintenance,
databases
reusable
for
To assure consistent operation
called
also
for
development "paradigms"
and
and
software
as well as a
parts
registration,
recording program changes, cost accounting, and other functions
inspection,
(Figure 4)
subsystems
1976,
and methods differed for
into a set of
high-level
in
disciplines
management
in
to
a
general
(defined
facilitate
conceptualizing,
of the factory tools,
development approach
by Matsumoto
rationalization
analyzing,
as
of
"a
the
designing,
set
of
and
the
SWB
specific
methodologies
activities
implementing,
and
the
testing
and maintaining software products") optimized for different applications, such
as steel processing software,
or nuclear power plants software.''"'
21
ti<» «XCriptlon
•Dtiign tptciflcition
description
-
Specif *c*tlon vtrlflC<tion, p«rfon«nci
Project control
iupoort
(SU8-P)
ev«lu«Cion
flC t»»n tit (xi
support (Sy8-t
I
I
i
*00' iCi
-
t
)
ion 9»ritr*tor
Mign-levf) Unquiet
Screen poci^vnt dati
generit ion
K4n-nogr infl pe** IQO
cstinttion
Cost ind schedule
control
support
(swe-ii)
Test
Source oeou99cr
Ouil U)r control
support (SW8-0)
Execution aoni tor
Plant siaulator
Test cover«gt
•u9 estiaecion
•U»nt*n*nce support
(SW8-IV)
'
Figure
Source C3(M mtljrsis
TrcuOle ma )yS)S
'tooile struccure
report
Software Configuration of the
f.
ir^
SWB
System
User inter^*ce iuoport
The
historical
Matsumoto and other
priorities
factory structure
SWB system
evolution of the
gives some indication of the
engineers
Toshiba
set
in
implementing
the
The system was being continually developed,
(Table 3).
increasingly incorporating computer-aided engineering, design, manufacturing,
and testing
The
first
major tools
then
only
capabilities
did
support
to
aspects
all
supported simpler tasks
Toshiba
introduce
design, project management, and
for
tools
software
of
like
development. ^
requirements
consists
and
of
quality assurance.
cross
control
debugging
facility,
facilities
for
types
all
file
under the supervision
library processing operates
(a
high-level
1977),
Fortran,
and PL/7
assemblers
(a
the
command
remote batch mode.
control
real-time
language for Toshiba's
in
of
of
minicomputer series,
to access a structured
control.
libraries
Language and
Cross compilers for TPL
developed
in
high-level system description
similar
to
PL/360),
produce object codes for the target computers.
manages the object codes
computers.
target
language for minicomputers
machine-oriented,
this
language processors,
text editor,
a
Programmers use their on-line terminals (workbenches)
project
of the
To support coding, code generation, and debugging,
command
a
and
specification
SWB-I was developed during 1976-1978 and formed the backbone
factory system. ^
and
coding and testing,
and cross
The
librarian
and adds, deletes, and replaces members
within the object libraries. "^^
23
Table 3:
EVOLUTION OF THE SOFTWARE WORKBENCH SYSTEM
Development
Support Tool
1976-1977
SWB-I
Improvement/Automation Focus
Programming
Environment
(programming,
compiling, debugging in the
source level, project files, program
generation, program reusing and link edit)
assembly,
1978-1980
SWB-II
Test Environment
1980-1985
SWB-P
Project
1980-1985
SWB-Q
Quality Assurance
1981-1983
SWB-III
Management
Design Support (requirements specification,
software
design
description,
and
documentation)
1981-1984*
SWB-IV
Program Maintenance
1986-1988
Various
Document Preparation
Expert System [for Design]
Reusable Software
Integrated Database
Sources:
Note:
p. 12; "Development of SWB for Toshiba Fuchu
Software Factory," received from Y. Matsumoto, 9/4/87.
Matsumoto 1987,
*Author's estimate.
24
Also
as
part
of
SWB-I,
called
tool
a
PROMISS
(Program
Information
Management and Service System), based on the software engineering database
(SDB), maintained
related
a
program library storing registered program materials and
such
information
as
changes
programs were either "standard"
information
the
in
database
and
release
program
covered
target computer name,
status, modification notes,
SYSGEN (System Generator) subsystem
by
serving
specifications
to
a
program and
select
modules database (Figure
registration
documents
data
standardized
language described,
5)."^'
25
facilitated
generator,
module
locations,
list,
and released job or customer names.
the
as
Management
programs or "job-oriented."
system/program module names and configurations,
codes to be performed,
Registered
histories.
In
function
version
addition,
the reuse of software
using
packages
requirements
from
a
reusable
Test specification
Require-
Syster.
^
specification
SADT
DRl
Software
specif
cation
-* *3
PrograiT^
specifi-
CASAD
dr;
cation
Coding
Design
language
Top down
rules
ao
HIPO
SP rules
SWB-I
r
uReuse
proven
J~
Sof tware
genera
tion
1
SYSCEN
Register
proven
programs
prograr.
T
PROmSS
PROMT SS
*5
*1 »-
*')
,
3
•i
»
-»
*-
Test report
Module
test
—r~
XMAS
Object code
Translate
~~f
SWB-1
Load intc
target
computer
System
?
Tes
,
report
test
DLL
Plant
site
SHB-E
DR4 test
—
r
Test
report
-^ release
t
DR5
*5
*Fig-
Software production life cycle, mile-stones
and tools/methodologies
f Y7-r
•
Automated program generation was possible for well-defined applications
like
power-plant software.
requirements
system)
described
definitions
CASAD
the
Factory,
This involved the direct generation of code from
in
a
(computer-aided
system
At
format.
specific
and
analysis
the
Software
documentation
produced applications programs for thermal power plant control
tool
by selecting modules from
reusable parts database and then automatically
a
linking them."^^
SWB-II provided
test
simulate
data,
Software
for
connected
this
resided
tool
in
being
test execution,
and
conditions,
real
computers
to
to control
facilities
the
tested
generate
computer,
customers
and analyze
record
test
test-support
for
collect
through
formats.
which
was
high-speed
on
dataways.*^^
SWB-III supported various approaches (contextual, functional, dynamic)
to
analyzing
user
requirements,
relying
primarily
on
three tools:
CASAD
(Computer-Aided Specification Analysis and Documentation) analyzed different
views
the
of
requirements,
requested
defined
relationships,
specifications.
generated documents matched
FCL/FCD (Functional Connection
Language/Functional Connection Diagram) described functional dependencies,
data
structures,
and
external
interfaces.
PDL
(Program
Description
.^'^
PDL
were
tools
Language) described module structures and internal interdependencies
was
not
used
to
generate code
available that did this.
more widely was
real-time
that
applications
even
though
there
Matsumoto's reason for not using program generators
memory
the
allocation
software were critical,
such code more efficiently
SWB-P supported
directly,
in
and
response
times
for
most
and programmers could design
terms of machine performance.^^
project
management through
27
a
set of carefully defined
procedures
in
combination
progress.
Project
management
activities
met
a
computerized
management followed
planned
particular baseline,
test inspection,
with
this
around
called
a
monitoring
standard
specific
for a
"baselines."
design
milestones
lifecycle
review,
or control of configuration (Figure 6).^^^
28
of
model,
When
a
and
with
project
code inspection,
START
CONT'D
.^
PLAN
DR
2
REQ.
A.
SYS.
D.
—FU NCTIONAL
^rn
BA^
V
LINf
EXT.
DESG.
drH"
PRODUCT BASELINE
ALLOCATED BASE LINE
PROG.
DESG.
T
D
INSP.
OPERATIONAL BASELINE
6
DELIVERY
DES2GN_BASE_UN_E
The target computers consisted
Due
or more types of microcomputers.
decided
to
through
a
is
of
^"^
done
700
computers
a
in
a
batch mode.
host disc,
data
the testing
is
linking
single
processes
interface
to
software
centralized
Program design, editing, and debugging
The source programs are
allowing designers
to
programs
build
The object program being constructed
files.
into
provide these
a
debug
Large-scale data processing, using various compilers or assemblers,
on-line from remote terminals.
by
and
compile,
general-purpose mainframes with
Three ACOS
users.
tools.
group
Toshiba managers
diversity,
to this
assemble,
text-edit,
centralize
minicomputers and five
of four types of
also
in
a
sent
subsystem by instructions
to
the
Fuchu
Plant's
of
layers of working
in
testing
system,
loaded
is
the test computer.
general
done
centrally controlled
the host computer
in
is
Various
thus
fully
hardware
continuous flow software development activities with
development. ''^
Matsumoto conceptualized the operation of the system
layers. ^^
centralized
The
first
served as
a
in
terms of three
centralized program library, the second as
production-management
database,
and
the
second
and
a
third
together as standardized project-development databases:
The SWB system consists of three
general purpose computer (ACOS
layers.
In
the top layer:
a
large
1000) serves as a storage of all
completed software products which are already in operation at each
customer site.
The software products include all documents such as
specifications, manuals, notes, program source lists and operational
instructions.
In the second layer:
several clusters are connected to the ACOS 1000
A cluster consists of a
mentioned above through a local area network.
large minicomputer (GX) with 32-64 MB main memory, a second level
local area network and plural work-stations connected to the second
The GX mentioned above has a storage of
level local area network.
documents/data/program and others which are needed to execute project
management, configuration management and quality management.
The above mentioned second
layer
30
file
connected to the mini-computer
(GX) also stores standardized templates for the specifications, formats,
and illustrations.
Reusable specifications, reusable program
modules and reusable documents are stored in the same file and can be
retrieved through personal work-stations.
texts
A file server is connected to the second level local
Designers can personally store under-developed
network.
documents, programs and data in the memory of each work-station
If
personally.
they want to store any information or software
resources which are commonly usable among project members, they can
store them in the file server.
the third layer:
In
area
Each work station was viewed as
also
provided an
the
bases,
automated
centralized
a
"interface"
production
SWB system
factory work space; the
support tools,
linking
program
base and
data
project
the
metaphor that the space
CRT
of
work space where the individual
Users
can
through
access
CRT
all
facilities
patterns."
through the SWB
are
tools
network due to the
Toshiba's operating
to
like
is
it
possible to develop
then transfer
it
to the
is
based on
space of factory
the
accomplish
workload.
his/her
needed to accomplish
their
work
were also integrated and accessible
UNIX,
use of
system for industrial computers
which makes
software
in
the
developed
has
a
UNIX
by ATE-T.
interface,
UNIX environment and
Toshiba operating system. "
SWB systems were
Similar
visits
which
Many
display
"The
libraries:
personal work-station mentioned above has the interface which
data
in
use
at
other Toshiba
software
facilities.
Most notable was Toshiba's main factory for developing and manufacturing
office automation
(OA) equipment, the Ome Plant.
this facility actually predates the
back
to 1968.
computers,
as
as
in
founding of the Software Factory and goes
Ome produces hardware such
well
Software development
software systems.
Toshiba's information systems division.
31
as personal computers
Organizationally,
Ome
and office
is
The 400 software personnel
part of
at
Ome
in
were divided
1986
into
departments
five
software,
minicomputer
software,
and system administration.
is
responsible
administration
for
done
1000 software engineers) of the
at
at
the
Ome
Ome numbered approximately 400
computers
office
systems
general
applications
The system administration department
and
production
overall
projects
of
software,
applications
covering
process
or
12
so
Plant.
control,
subsidiaries
1986,
In
well
as
as
another
(with
software developers
at this facility.''"
The Ome plant established the system administration department and
adopted
centralized approach to production management,
a
development,
tool
process control, subcontractor administration, and quality assurance,
in
direct
imitation
imported
facility
serve
as
a
Workbench
factory
(SWB)
system
developed
infrastructure
technological
OA needs and
meet
ASTRO
1984
in
introduced
users
include
all
workstation (DP9080).
ASTRO-M
--
evaluation;
project
(2)
management,
ASTRO-V
--
test evaluation,
at
the
cost
and
all
(4)
Plant,
process
ASTRO-D
based on the
software engineers. ^^
32
development
to
five support subsystems:
control,
documentation and project support;
maintainability improvement.
Ome
systems
Three designers are assigned
The system had
quality control and maintenance;
facilities
support
own factory-type system,
its
computer- related
groups, including gate arrays designers.
--
to
Fuchu
(Automated System Technology and Revolutionary Organization).^^
ASTRO
ASTRO
the
at
also
Ome then customized SWB
aspects of program development and management.
to
Ome
the success of the Fuchu Software Factory.
Software
the
to
of
1980,
in
--
(1)
productivity
(3)
ASTRO-Q
requirements definition,
Toshiba was also expanding
ASTRO
one
system,
to
its
support 1800
III.
MANAGEMENT SYSTEMS: PROCESS. QUALITY. PERSONNEL
The SWB
set
tool
would
incomplete
be
without
additional
sets
of
procedures, techniques, or practices to integrate the support technology with
Three
the factory workers.
Factory
will
be discussed
productivity,
cost,
management,
in
and
process
analysis
historical
and personnel management,
development;
project
section:
this
reusability,
especially
key management systems
of the
the Software
management,
(project
of
in
faults
including
progress);
each
at
quality
phases
of
career development and
especially
training.
Process Flow and Management
A
project
typical
code and 3 years
in
at
the
duration.
factory
10
to
15
engineers
programmers would be involved
these people,
Toshiba
nearly
a
million
There would only be about
doing high-level design, who work
Another
was
full
would
in
lines
of
source
4 or 5 engineers
time on one project until completion.
do
detailed
coding. ^^
design,
and
To coordinate the
70
to
80
activities of
managers broke down the development process
into
several distinct phases, each with prescribed procedures to be followed:
Requirements Specifications and Design Phase:
1.
Use
SWB-III
to
define
user
requirements
and
prepare
functional
diagrams and documentation describing module and data structures.
Define requirements for computer hardware and peripherals.
33
Software Manufacturing Phase:
2.
Apply
to the
SWB
service center for an
SWB
file
assignment, which
will
be used to build the actual program.
3.
Input data or program components through SWB-I terminals.
4.
Assemble or compile using SWB-I, correct errors using the workbench
editor.
Software Testing Phase:
5.
Down-load the object codes
the target computer through the
into
SWB
terminal.
6.
Using the simulation language, set up
a
and pseudo
test scenario
real-
world conditions.
7.
Using SWB-II, start test execution.
Deliver system to user.
System
9.
SWB-Q.
Quality assurance procedures executed using
step 3.
8.
Correct errors by moving back to
At
Installation
and Alignment Phase:
customer
the
site,
programs,
modify
if
necessary,
using
portable
workbenches accessing the central SWB system through telephone
lines.
Maintenance Phase:
10.
Maintain customer software,
Toshiba
Matsumoto
followed
referred
to
the
as
using SWB-IV.
levels
software
coding), as well as testing (Fig X;
abstraction
of
used
"manufacturing"
cf.
34
Fig y)
in
(i.e.
design
in
what
programming or
In this figure, binary object codes generated as the result of Trans 4
are linked together with existing codes in step A4.
Product 4 is
assembled with existing software fragments, utility subsystems, and an
operating system in step A3.
Product 3 is the software system that
will be loaded into the final computer system.
Product 2, the final
computer system in which Product 3 has been loaded, is installed at the
customer's site.
Product 1 represents the large system in which
Product 2 has been embedded. ^^^
management involved the following steps:
Project
cost was confirmed at the beginning of
into "unit
accomplish
software configuration
were not determined
The project
(2)
activities
workloads," with each unit defined as "an activity to
were divided
a
project.
a
Target project
(1)
at
all
item
by one person."
once but were defined
Unit
workloads
the beginning of each
at
development phase; target costs for each unit workload were also defined
this time,
derived from the total estimate.
definition
of
each
workload.
unit
for each unit workload,
personnel
on
(4)
who would be responsible
included
specification sheets or source lines should
Also figured into these items were the characteristics of
should be reused.
deadline.
how many
Specific planning followed the
what would the cost or hours needed be, how much software
be completed,
the
This
(3)
at
as
well
as
of
the
software
being
developed,
the
project
The computer analyzed progress status and expenditures, based
information entered daily or weekly through the workbench terminals by
each
person
deviations
in
charge
between
each
of
current
and
Workload Order Sheet or UWOS)
assignment."^
management."
unit
workload.
target
was delivered
Matsumoto characterized
Previously,
A
status.
this
to
then
displayed
printed
output
It
each
approach
individual
as
the
(Unit
with
an
"look-forward
managers attempted corrective actions regarding
35
the project schedule or expenditures only after
made
or weekly
Daily
items.
it
familiar
Toshiba
that
so
programming and testing phases
Brooks
that
This was
late.
developing
in
adding
consumed
people
adding manpower
New types
and
products on
a
enough, then
work flow.
has
demand
If
will
the
found,
also
in
due
to
time
however,
that
later,
it
Frederick
who maintained
system,
made
projects
for the
new department can be created
software development
in
""^
the factory,
such as
are not put through the normal factory
Separate
job-shop basis.
a
people
the experience of
software done for the first time
of
line
to
project
Matsumoto
manufacturing automation programs,
process
add
to
the design level does not reduce lateness.
at
progress. ^
speed up progress on projects that were
software
late
a
able
System 360 operating
communication.
in
to
was
somewhat contrary
IBM's
to
contrast,
in
and procedures were sufficiently standardized and
tools
employees
to
in
still
on specific
in
through the current system,
reports
possible to act while portions of the project were
The factory
running
reports came
in
organized
are
for
new
new product becomes large
the Fuchu Works and the
take place through the normal process.^'
Cost and Productivity Management
In
20%
in
about 60% of the
1986,
intermediate
languages.
and converted
to
and 20%
languages,
Data declaration
numbers
in
lines
to
productivity
Matsumoto,
as
lines
of
as
well
as
in
Fortran,
real-time
problem-oriented
user-specified
executable lines were counted
and "capability-based" measures.'^"
despite
code
in
written
Productivity measurements were then
EASL.
classified according to cost-based
According
software was
numerous
arguments
produced over time,
36
against
the
Fuchu
measuring
Software
Factory has used equivalent assembler source lines (EASL) primarily because
of
its
simplicity,
and
his
desire to focus on
productivity improvement over
time:
Our aim
in measuring productivity is improvement.
What we need are
understandable indices with which we can compare current and
past productivity data in some consistent manner. .Measurements must
be extended to every detail of all software products.
The amount to be
measured is so large that the measuring must be as simple as possible.
Expending significant overhead cost for the measurement should be
avoided.^"
easily
.
Overall, the "gross production rate"
(GPR)
of the software factory
was
measured by instructions generated per programmer per hour and per month,
although there were more specific indices followed (see Figure 7).
program consisted
of efforts for requirements analysis,
An entire
specification,
coding, test, and maintenance up to commercial availability.
design,
Toshiba counted
the number of source lines and object bytes produced from these activities
and divided by the
total
number
of
employees
in
the factory, with separate
measures kept for newly produced code (GPR-0), new code plus reused code
(GPR-1),
imprecise
code
and
total
delivered
code
GPR-0 was considered
(GPR-2).
an
number because programmers did not accurately distinguish new
production
GPR-1 was taken
from
reused
code,
according
as the actual production
37
to
Matsumoto.
rate of the factory.
As
a
result,
Source
lines
;Mj.-Ders
9-iCtganization
of
enployees
per
month
Reuse
syscem or
system
generator
Source
lines
per
nionth
Proven
programs
~H
-^H
GP
GPR,
r^
Fig.
G?R,
C??.
G?R„
^
GPR
in Fig.
3
3
Diagram to explain GPR
are defined as:
(average No. of logical part source
lines newly written for delivery per
3 inor.th in the whole factory
)_
(Numbers of total factory employees)
(average No. of logical part source
lines generated for delivery from reuse
part of Fig. 3 per a aionth in the whole
factory
)_
(Nunbers of total factory employees)
GPR,
CP^
,
h
^
-,.,..
(avtraec object codes in KB delivered
I'er a rior tn in the vnole factory
Cumoers oi total factory er.plovees;
.
^
Object
codes KB
Translator
per
month
^
The
profit
production
of
reach
was
factory
Toshiba
rate.
generate to
the
certain
estimated
considered
and attempted
to
gross
the
of
how much code they would
goals,
profit
function
a
need
deliver this
to
code
without exceeding the budget they simultaneously established for hiring new
programmers.
According
factory to
hiring
limit
of
to
Matsumoto
the previous 4 years.
profit
1981,
new software employees
requiring them to improve GPR-1
year,
in
to
a
forced
goals
maximum
of
the
4% per
productivity about 14% yearly over
The basic strategy developed
at the factory to
meet
profit and productivity goals consisted of four elements:
Promote registration of proven programs and reuse
Develop an efficient system generator
Develop tools and promote better utilization
software
Control
quality
before
strictly
shipment,
and
define
requirements as precisely as possible. °^
Cost-based
development cost.
project's
profit
margin,
Measurements
of
centered
productivity
This
determined
the
financial
factory
"target cost,"
price
cost/person-month,
were made for 6-month
on
estimates
charged
each
a
customer.
and cost/EASL,
profit/person-month,
periods,
for
the factory's desired
plus
Toshiba
of
for the entire factory and for each
fil
project. °
Capability-based productivity was more individualistic or subjective, and
was used for progress management, work assignments,
and
career
whole,
for
development.
The measures were done
each
and
project,
for
each
39
individual.
education planning,
for
the
They
factory
also
took
as
a
into
account the type of function or purpose of the software being developed;
correctness versus speed characteristics of the worker, including the number
and type
identified
of faults
type of product,
in
design review, testing, or by the customer;
terms of EASL as well as specifications and test items;
in
whether the person was an analyst, designer, programmer, or test engineer.
What
Matsumoto called
measured every
months,
6
Toshiba customers.
lines
per month
U.S.
programmers
code
produced
In
beginning
in
gross
productivity"
based on
1977,
EASL accepted by
.""^
per
several
times
At Toshiba,
commonly cited
levels
studies
in
however, over 48% of the 3100
programmer month
1985
in
was
reused
lines
from
productivity gains were erratic,
1976 was
even dropping 12%
improved output 13% between
1972
no higher than the 1973 level.
still
of
of
other
4).
the five years prior to the opening of the Fuchu facility,
engineers
was
Toshiba workers were nominally "producing" about 3100
by 1985,
programs (see Table
"factory-scoped
-^
in
1975;
and 1973,
In
software
Fuchu software
but productivity
in
contrast, output per worker
rose 22% during the first year of factory operations, and productivity was up
70% within
gains
5
between
annually.
Improvements were much slower after 1981,
years.
1981
and
Improvement
the order of 2%
a
1985 totalled
in
merely 8%,
reuse rates between
thus
1977
averaging
however;
about 2%
and 1985 were also on
year.
These annual figures do not correspond precisely
to
annual
software
production because they reflect delivery of code to customers, although they
provide
a
general estimate of output performance.
indicated black box and white box modules;
included reworked code.
The reused code figures
some of the new code, however,
Toshiba studies of reuse rates, number of
40
lines
in
changed when
modules
and overall
reused,
productivity was significantly improved
without changes.
productivity was
If
negative.
impact on productivity.
Table 4:
only
20% was
1000
Pre-Factory:
used
about 80% of
unchanged,
Between 20% and 80%,
a
the
indicated
that
module was reused
impact on
there was
overall
no noticeable
''
GROSS PRODUCTIVITY
Year
if
productivity,
£
REUSE AT FUCHU SOFTWARE FACTORY
EASL Instructions/Proqrammer/Month
and
more
to
productivity
such
labor"
reuse
of
actual
appeared
as
design
to
(Table
be
a
car transport,
proven
code. ^
according to Matsumoto,
The
seems
5).
reduction
Other factors
or
of
"trivial
through the development
of
new
leveling
to
off
of
productivity
Table
5:
°
SOFTWARE FACTORY MAN-POWER ALLOCATIONS
Man- Power Index
=
100
higher
routine
tools;
and
improvements,
have come from the ceiling Toshiba
practical levels of reusability of about 50%.
Stage
to
elimination
hit in
TOTAL
leading
has
components was considered the most important long-term strategy.
survey
asking
employees
individual
productivity
reusability
cited
as
and
in
the
software
quality
the major factor,
targets
followed
factory
reflected
how they met their
this
strategy,
CO
IN
MEETING PRODUCTIVITY AND QUALITY TARGETS
% Impact
Factor
52.
Reusability
Improvement
of
work steps, procedures, environment
Application of new software tools
Application of new software engineering methods
Improvement
Use
of
of functional decomposition
higher level languages
with
by process and environment
improvement. °
FACTORS
A 1985
assembly and construction of new programs, usually for specific applications,
based on reused modules. ^
Central
constructed
of
construction
determined,
the
to
different
of
to
reusability
a
these
large
layers
extent,
the
prototyping,
and
careful
and
interfaces
machines or applications
reusability,
strategy
was
interfaces
and
the
the
notion
(Figures
programs
8
and 9).
they
how reusable or transferable
code
was.
The
factory's
program generating
definition of these interfaces
all
as
The
connected
to
different
implementation
relied
and layers, and the
software
of
heavily
utilization
of
on
of
a
what
E.W. Dijkstra called "layers of abstraction" (requirements level, data/function
level,
program/coding
level).
Toshiba developed prototype systems either
by building them from scratch using simple languages such as Prolog, APL,
or Basic, or by constructing them from existing modules and then modifying
the software to
fit
user requirements.''
44
TOlf f*?^''^'*
i
\ .1
APPLICATION SOFTWARE
SUBSIDIARY APPLICATION
INTERFACE
PACKAGES
UTILITY
INTERFACES
OPERATING SYSTEM
k' INTERFACE 4
HARDWARE
f
\
.
Figura
I
:.,?*,
A
F.^j ?
t
SUBSYSTEM
INTERFACE:
j
,..J
1
•
>!
.)
'
i-
aoftware configuration
iUSERS'
NEEDS,
SgV.^BHS ntVEr Of*
'
'
cnou/
«E0«llrt1»IENTS :i.(«
r
ri: JCCONO
I
LEVELOF
;<
WIROLEVEL-OF
^
ABSTRACTION
FORM
2
FORM
3
PROGRAM
.j3^iitv.-,
XEROGRAM. 1
FIgura
The four levels of abatraclion in the software design process.
In Trans 1, the user's needs (Form 0) are transformed Into requirements
specifications from which the requirements model (Form 1, the first
level of abstraction) is produced. In Trans 2, the requirements model is
transformed Into the system design from which the data/lunctlonal
model (Form 2, second level of abstraction) is produced, in Trans 3, the
data/functional model Is transformed Into the program design from
which the program model (Form 3, third level of abstraction) Is producea. In Trans 4, the program model Is transformed Into software programming, producing the actual program codes (Form 4, fourth iaval of
abstraction).
To implement the
reusability
strategy,
Steering
Committee,
a
Reusing
Parts
Department, and
a
Toshiba
on
relied
Software Reusing
a
Software
Parts
Manufacturing
Software Reusing Parts Center (Figure 10).
The Steering
Committee determined which type of software parts needed to be created as
well as
updated or discarded
already
if
Toshiba termed "authorized needs";
in
the reuse system.
The Manufacturing Department
newly produced software parts to determine which met the
all
necessary criteria; these parts were then deposited
part
identification
Software
separately.
keyword
and
Database,
Item
A
central
and
issue
phrase were
the
to
software
measures
such
parts
as
were
fitness,
quality,
of
the
in
the
Reusable
was
part
keywords,
stored
which
Evaluation criteria to determine
enough
clarity
The
the Parts Center.
reuse were the
effective
good
in
registered
body
actual
represented the functionality of the part.'"^
which
decided what
these needs were then communicated to
the Reusing Parts Manufacturing Department.
next evaluated
It
for
the
focused
database
("definiteness"
of
on
descriptions,
clearness), abstractness, simplicity, coupling level (with other modules), and
completeness.
module
Specific concerns
identification
performance
module (Table
(such
as
and
addressed the "human interface" (such as
algorithm
response
time),
6)
46
descriptions),
and
interna!
software
interface,
configuration
of
the
PROJECT XXX
PARTS MNFG. DEPT.
SOFTWARE PARTS STEERING COMMITTEE
REQUIREMENTS
-m
DESIGNER
PARTS
CENTER
E
L
I
V
TEST,
V 4 V
SECTION
PARTS
iRETRIEVAL
PROGRAMMER*
E
PROGRMR.
ST
,_
'RSI
D.B.
PARTS
DESIGNER
r
S
T
E
PARTS
CERTIFI-
CATION
ALTERATION
\MAINTAIN^
NOTICE
UTILIZATION STATUS
l_
SYSTEM
CERTIFI-
CATION
•REUSABLE SOFTWARE ITEM DATABASE
Figure
T^'VWaJ
Organizations to Promot? Reusabilitv
i^
Characteristics
Huaan interface:
identification (najning)
environment descriptions
algorithm descriptions
requirements description
instruction manual
Software interface:
calling convention
communications
f ittness
quality level
def initeness
quality level
quality level
consistency
simplicity
declaration of public entities
procedures and data
degree of hiding
dependency descriptions:
dependency to CPU, OS, language,
devices, utilities, subsystems
size of global conLiion, cross references
tasl?
Criteria
auid
synchronization
presentation of trace up and do'-Ti
user aids (accessories such as test drivers)
Performance:
response time presentation
efficiency presentation
reliability
accuracy, robustness, default,
exception hemdling, fault tolerance
def initeness
abstractness
quality level
coupling level
complexity
structuredness
frequency
simplicity
def initeness
completeness
def initeness
def initeness
def initeness
Internal view:
Internal configuration:
presentation
dependencies betseen configuration items
functions
number, size
unde r 8 t andab 1 1 i t
interactions between internal functions
clearness
coupling level
appropriateness
complexity
strength
data:
appropriateness
simplicity
number, size
structure level
Characieristics and Criteria for Evaluating Reusable Parts
T^^'^
(^
While some firms (like Hitachi) merely evaluated completed programs for
modules that might be reusable
Steering
Committee
packages
applications
and
management,
in
other
development
the
directed
actually
systems" programs which worked
specific
other projects, the Software Reusing Parts
in
"semi-
between operating systems and industry-
communications,
control
to
These types
subroutines.
utility
generic
of
database
standardized
of
programs cost considerable manpower and expenditures which no individual
manager could authorize; therefore, according
committee was
the development of such
to
critical
committee did not have
reuse
for
reusable
The
software.
permanent membership but members alternated and
a
would vary depending on the types
Objects
Matsumoto, the role of the
to
(called
of
programs being discussed.'^
"parts")
included
documents
modularized
(contracts and manuals), specifications, programs (code), as well as test cases
and
software that
served
as
design-aide tools
Every authorized reusable "part" was registered
and application
in
attached checklist explaining their characteristics
were kept on the factory, phase, and project
the
average factory
reuse
rate
a
central database with an
(see Table 6).
levels.
EASL was 48%
for
generators.
As noted
in
Statistics
the table,
in
For
1985.
design
documents, the reuse rate was 32.5%.''*
Registered
job-oriented
programs were divided
programs.
were registered on disc
oriented
programs
generation
or
The former's
file
mill
source
codes
and function
as
control;
specific
their
systems,
source
of the
such
codes
magnetic tape since they were not accessed frequently.
(55%)
abstracts
within the Software Development Database.
were treated
rolling
standard program modules and
into
"*
as
were
for
Job-
power
stored
More than
on
half
reused parts during 1984-1985 were of 1000 to 10,000 EASL and
49
consisted mainly of "black box modules" -- common functions or subroutines,
recalled from the
--
reusability parts database by parameter or function
and application-oriented
modules contained
white box
About 36%
10,000 to 100,000 EASL;
The
parts."
"skeletal
the content of which
"slots,"
change for different applications."
sized
modules or
box"
"white
names
designers could
the reused parts were
of
these were mainly common utility subsystems,
support systems, or tools.''
Project
design
meeting
review
develop
to
after
Reusable parts were examined and decided
user requirements.
defining
the
managers determined what parts they had
or
functional
the
at
allocated
in
(see
baselines
Figure 6)."^^
Managers
abstraction,
recommended the
working down
interfaces
program
and parameters,
as
stressed
well
data
careful
as
The languages used
library."*^
parts
of
at
high
a
defined lower levels.'^
to explicitly
Toshiba
technology,
design
reuse
at
abstraction,
In
clearly
level
of
terms of
defined
cataloging of modules for the
Toshiba
(mainly Fortran,
PL/1,
intermediate and machine-level languages) were not specifically designed for
data or procedural abstraction (which
useful for reusability), although,
is
in
Toshiba was using Ada to describe program structures, before building
1984,
prototypes using languages such as Prolog,
APL, and Basic, and then
final
PI
programs .'
The inventory
policy
of
of
"promot[ing]
reusable
parts
registration
of
was
continually
proven
expanded due
programs and
reuse."
to
a
The
system enforcing this had four major elements covering promotion, execution,
and control:
productivity
(1)
At the start of each
targets
from
their
project,
superiors
50
that
project
could
managers received
not
be
met
without
reusing
certain
large
Programmers were
components per
fiscal
percentages
required
term
(
a
of
register
to
code
a
and/or
certain
documents.
number
reusable
practice Matsumoto thought would be difficult
to institute in the United States).
"^
(3)
These personnel received awards for
registering particularly valuable or frequently reused modules.
in
of
(2)
(4) Deviations
the performance of each individual from the objectives were monitored by
computer and reported to
all
concerned.
Matsumoto explained:
Factory members are enforced [sic] to register a designated number of
The registration is received by
reusable modules in every fiscal term.
the reusability promotion group which is a permanent organization in
A standardized formalism is enforced for describing
the factory.
specification, logic representation and semantics of each module to be
registered.
The reusability evaluation committee examines the quality
of each registration, and decides if it is acceptable or not.
The accepted
registration is taken by the reusability promotion group
and transformed to the form which is included in the second layer (GX)
Persons who registered valuable reusable
database mentioned above.
modules or frequently reused modules are awarded.
How to promote reusing?
At the beginning of each project, each
project manager is given several objective parameters with which to
steer his/her project.
Project productivity is one of the given
objectives.
Without reusable modules, given objective productivity is
Reusing is autonomously promoted by each project
not attainable.
member to attain the given objective.
How
is
it
done autonomously within each project?
At the end of the requirements definition phase, the semantics of
implementation model is created.
Then existing reusable modules
which seem to fit the model are selected at the design review meeting.
(1)
the
(2)
that
Objective parameters which are given to the project are refined so
each quatum parameter represents an objective for implementing
each workload unit.
(3) An accumulation of personal accomplishment is entered to the SWB
system by each designer or programmer daily or weekly.
The SWB
system is capable to display deviation between accumulated effort and
corresponding objective Quantum.
Each individual corrects activities by
checking the deviation .""^
51
Managers
imposed
classifying them as
contents of
to
a
several
on
criteria
modules
software
reusable and registering them
One, the
the library.
in
before
module (objects, relationships between objects, algorithms) had
be easily understandable to users who did not develop the code.
and requirements
the interfaces
to
Two,
execute the software (other code needed,
language being used, operating system, automatic interrupts, memory needed,
I/O devices, etc.) had to be clearly specified.
(executable on
portable
Three, the software had to be
types of computers).
various
transferable (modifiable to run on different computers,
portable).
Five,
Four,
if
not designed to be
the software had to be retrievable or locatable
library by people
who were
not familiar with
reuse was facilitated by the fact that,
it.°^
It
had to be
it
program
a
in
should be noted that
except for microprocessors,
all
the
software the factory produced was for Toshiba minicomputers, which we^-e
all
compatible on the source-code level. °^
Matsumoto also found
reusing
that
modules
encapsulated
from
the
higher levels of abstraction (requirements level and design level) "increases
extraordinarily the number of reused modules and the reuse frequency of
reused
module."""
Also
to
facility
reusability,
Toshiba
supported
a
a
methodology called "50SM":
number
code
one module to
than 50.
1.
Limit the
2.
Construct programs by combining three types of modules:
of lines of
in
less
processing,
data, and package.
3.
Use
Technical
Description
steps/module design
Formula
description)
for
(a
visual
describing
external
module specifications and inter-module relationships."'
52
language
and
for
50
internal
Quality Measurement and Control
Toshiba
level
reliability
produce defect-free
to
of
sure the software met
frequency
run"
in
The objective
specifications
the
but,
in
product
desired
remaining after testing)
of
testing
was
make
to
under conditions agreed upon
the
in
Software quality was then evaluated by error
the customer.
the tests done at the software factory, and then by "endurance
customer
the
at
all
software
The price included Toshiba's
system.
delivered
the
estimated total cost plus profit. °
contract with
determined
customers,
individual
(estimated number of residual faults
price
the
attempt
not
with
negotiations
given
did
Formal
site.
Quality
Assurance Test plans and
procedures were written and negotiated with each customer for both types of
Customer representatives also witnessed each test.°^
tests.
Software reliability was thus viewed
(2)
the following requirement:
"any fault of Product
deviate from the specified performance
of
method
in
software products
by Matsumoto's
of
Technology.
is
2
which causes Product
the
number
before shipment to customers,
group
Counting faults
1
to
not allowed within 8000 continuous
The factory estimated
.
developed
Institute
in
cooperation
started
with
with
using
the
integrated
of
a
Tokyo
test
and
The cumulative number
of
and the calendar time elapsed during the test period were used
to
continued through
faults
operation "^^
real-time
faults
residual
terms of (1) fault avoidance and
Most of the software the factory developed had to meet
fault tolerance.
hours
in
estimate the
detected
in
the
number
the
of
end
of
the
plant
residual faults
testing
period
at
test.
the end of the tests.
were corrected
subsequent tests.
53
before
All
defects
proceeding
to
During 1977-1986, the average program produced
had
a
improvement during this time;
seven-fold
program had
final
the
Depending
test.
customer's
plant
and 15%
of
completed
averaged
exceeded
a
between
to 25%
was
0.20
quality
20% programming
faults.
finished,
faults
The
and 0.05.
factors
or
residual
final
their
baseline;
by
copies
consisted
of
perspectives
reliability,
these
the
in
By the time testing
-^
per
source
1000
stage
alone
23
of
elements
the
criteria
maintainability,
interoperability, efficiency,
usually
were defined for each baseline
as
they
review meetings.
concerned
producer
lines
"^
checklists
design
faults
20% to 30%
(Toshiba)
testability,
integrity,
with
finished
and
The
11
the
flexibility,
their
list
of
factors,
work
filled
each
out
criteria
combining
reusability,
7):
at
quality
customer:
and usability (Table
54
of
Designers made entries
responses were then compared with the checklists
their
reviewers
of
typical
discovered
errors;
testing
the lifecycle model and monitored using checklists.
on
the
the factory or at
in
the
of
hardware interface
year for large systems.
Specific
and 45%
35%
10% and
between
systems
between
whether the tests were done
sites,
were design errors;
data faults;
of
mid-1970s,
the
in
per 1000 lines of source code discovered during
to 20 faults
7
the software factory
There was, however, about
per 1000 source lines of code.
2 to 3 faults
in
the
correctness,
portability,
Table
7:
TOSHIBA SOFTWARE QUALITY EVALUATION
Criteria
Traceability
Related Factors
Correctness
Completeness
It
Consistency
Correctness, Reliability, Maintainability
Accuracy
Reliability
Error Tolerance
II
Simplicity
Correctness, Maintainability, Testability
Modularity
Maintainability,
Reusability,
Execution Efficiency
Storage Efficiency
Access Control
Access Audit
M
Integrity
ft
Usability
Communicativeness
II
Communications Commonality
Data Commonality
Flexibility,
Interoperability
Efficiency
Operability
Training
Software System Independence
Machine Independence
Testability,
Portability,
Portability,
Reusability
II
II
Interoperability
II
Conciseness
Maintainability
Generality
Flexibility,
Expandability
Flexibility
Instrumentation
Testability
Self- Descriptiven ess
Maintainability,
Reusability,
Source: "Software Quality," Toshiba
Y. Matsumoto, 9/4/87.
Reusability
Testability,
Fuchu Software Factory,
55
Flexibility,
Portability
received from
The system
test
inspections
insure
to
reliability
reviews and
Promoters (engineering section, design section,
(Table 8).
other groups to these sessions as they deemed necessary, but
etc.) invited
in
the
responsible for
section
consisted of eight design
carrying out the
the
different
phase
The independent
review.
was
quality
also
responsible
for
assurance section was
responsible only for the design review session at the end of factory test.^
The software factory
circles
smaller.
subjects
in
1986;
a
common
size
approximately
700
was 10 members each,
voluntary
quality
many were
although
The most common theme discussed was quality improvement (45%
discussed),
improvement
(15%),
presentations
also
by productivity problems
followed
and
the
conferences were held twice
awards
had
also
a
participated
were given
out
for
education
year,
in
system
(20%),
methodology
Factory-wide
(10%).
of
QC
and groups with particularly excellent
company-wide QC conventions.
excellence
activities. ^^
56
in
a
variety
of
Various
quality-related
Table 8:
PR
TOSHIBA SOFTWARE FACTORY DESIGN REVIEW fPR) SYSTEM
Purpose
Review of Specifications
A
Promoter
Engineering
B
Design Section
Review
of Overall
C
"
Review
of Detailed
Design
D
Manufacturing Section
Review
at Start of
Manufacturing
E
"
Review
at
End
of
F
Quality Assurance
Section
Review
at
End
of Factory
G
Plant Engineering
Section
Review
at
End
of Site
H
Engineering Section
Review of Performance
Section
Source: "Design Review System," Toshiba
from v. Matsumoto, 9/4/87.
57
Design
Manufacturing
Test
Test
Fuchu Software Factory,
received
Career Development and Training
One problem
skilled
and
less
that U.S.
firms have had with division of labor into highly
skilled jobs within
software organization was that talented
a
software staff did not want to work at mundane tasks such as coding;
and
people hired only as "technicians" to do coding or simple support tasks had
no career path of advancement. The solution arrived at by firms such as IBM
and
Data
General
has
been to hire the
capable of doing both design and coding,
more operations with
less
but to
skilled
less
and ask these workers
and career development system for
personnel
all
At the end of 1986,
software factory.
to
people
perform
support help.^"
Toshiba has dealt with this potential problem through
the
recruit
hired
formal training
a
work
to
full-time
in
the 2300 factory personnel,
of
20% had doctorates or master or science degrees; 30% had bachelor degrees,
and the
years,
rest
were high-school
however,
about
60%
graduates."
are
The trend away from hiring
the
number
small
college.
of
To increase manpower, Toshiba had
new employees
entire first year.
of
full-time
system
to
separate
rather
draw on
had
attend
to
a
training
full-time
have masters
than
go on
to
larger supply,
classes
for
the
High school graduates were also advised to take two years
in
the
in
factory
the
as
company
part
of
subjects
(Table
9).
This
58
was
The educational
college.
the
career
training program consisted of three course sequences,
22
recent
no
advanced courses
provided
20%
in
directly from high schools was due to
graduates who wanted to work
which was college graduates.
All
and
graduates
college
degrees.
new employees
Of
development
and
containing a total of
administered
jointly
by the
management department,
personnel
engineering
administration
department,
and the Heavy Industrial Engineering Laboratory.
Along
with
investment
this
in
career system that familiarized each
Everyone
specialize.
--
the
individual.
factory
best
that
had
a
and planning,
them.
All
with
fit
their
specific
which
of time this
The next step on the
assignment to do design work.
paths
personnel
factory
was
a
the basic operations of
PhDs and high-school graduates
The length
out doing programming.
on
individual
the
regardless of their educational background, before allowing them
the facility,
to
training
After this,
interests
section
assisted
and
devoted
employees
details of the promotion
in
had to start
assignment lasted depended
latter
was
a
minimum 3-year
individuals chose specific career
skills
to
--
(Figure
career
11).
The software
development consultation
making the choices available
system were publicly available."^
59
to
Table 9:
FUCHU SOFTWARE FACTORY EDUCATION PROGRAM
Basic Course
(1 to 2 months)
(Required Course of Study for
1.
2.
All
New Employees)
Introduction to Computer Control Systems
Computer System Architecture
3.
Programming Languages
4.
6.
Test and Debugging Techniques
Structured Design
Data Structure/Data Bases
7.
Programming Styles
5.
Application Course (2 to 4 weeks)
(For Employees Entering Design)
1.
2.
3.
4.
5.
6.
Requirements Definition
Documentation Techniques
Test and Inspection Techniques
Control Theory
Simulation Techniques
Evaluation Techniques
Advanced Course
(3
months)
(For Employees Entering System Analysis)
1
Contracts/Negotiation
.
2.
System Theory
3.
Quality Control
Project Control
Cost Estimation
4.
5.
6.
Software Engineering
7.
Management Techniques
8.
Human
9.
Relations
Decision Making
Optional Courses:
1.
2.
Industrial Engineering
Operations Research
3.
Patents
4.
Value Analysis
5.
Integrated Circuits
Source:
Matsumoto 1982, "Software Education
60
in
an Industry," pp. 93-94.
system engineering manager
V
specialist
\C
test engineer
\
prog,
7-
V
D
E
system analysis
specialist
support statf
B
C
design
Dr.
graduates
A
master graauates
univ. graduates
high school
graduates
Fig.
programming
-^
-S*
year
Career pattern for software
engineers
]'\y.J
The
letters
new graduates
a
through d
the
into
Figure
in
indicate
11
points
of
entrance for
The average high school graduate,
factory.
for
example, did programming for 6 years, then moved into software design for 3
years
and
system
analysis
for
before
years,
5
reaching
manager or software engineering
software
engineering
patterns,
however, were determined through
a
the
position
of
Career
specialist.
series of steps involving both
the worker and his immediate superiors:
(1)
Managers interviewed new employees and suggested
a
career path
for
each person that seems most appropriate.
(2)
Employees decided what path to follow, based on the recommendation of
the manager and discussion
(3)
Managers drew
employee given
(4)
An
his
a
the interviews.
schedule
accomplishments"
for
the
is
planned to help the employee reach
accomplishments.
During the individual's career,
and
"target
of
chosen career path.
individual education schedule
his target
(5)
up
in
progress
evaluated
each
through
target
accomplishment
interviews.
If
is
checked
necessary,
new
recommendations for modifying the career path or changing targets are
made. 100
CONCLUSIONS
Like other Japanese software factories,
Toshiba represents
a
development through
the Fuchu Software Factory at
long-term strategy to improve the process of software
a
comprehensive
procedures, and management systems,
collection
and
linking
of
tools,
ranging from computer-aided design to
62
Also similar to other Japanese firms,
career development.
Toshiba managers appeared to conceptualize and
with
even more emphasis,
then
manage software development
believe that the process could
to
procedural and
of labor,
outside
factory.
similar
hardware,
to
terms
in
their
of
be broken down into distinct steps amenable
standardization as well as division and specialization
principally into categories for designers, programmers, and testers.
Successful
required
tool
although perhaps
specialization
delicate
a
has
also
"matrix" management of systems engineering departments
programming departments organized within the
and
factory
the
and production operations
design
of
Based on this
separation
customer
of
interaction
and
high-level
to
have truly
product design from the work of the factory, Toshiba appears
"rationalized" program development through standardization of tools, methods,
and core components,
actually,
--
semi-customized
customer and
quality
while maintaining the goal
at
data
improvements
a
cost
indicate
in
products
at
level
a
possible
as
low
as
that
the
factory
to
producing customized--
of
of quality acceptable to the
Toshiba.
structure
has
Productivity
brought
and
significant
performance, even though output per programmer leveled off
once Toshiba reached reusability levels approaching 50%.
Toshiba
factories
in
division
of
appears
several
Toshiba,
to
respects.
led
computer-manufacturing
management and
tool
by
other
from
differ
One,
Dr.
division,
development.
it
Japanese firms
has
and
at
Hitachi
software
and
Fujitsu,
manufacturing
than
rather
led
in
commercial
the
software
engineering
The factory system perfected
has gradually been transferred and experimented with
contrast,
factories
divisions
63
software
been the industrial equipment
has
Matsumoto,
that
with
within
have
in
their
served
at
Fuchu
other divisions.
In
computer hardware
as
the
center
for
developing software engineering technology.
centralized,
the cases of
In
company-wide committees and central
NEC and NT&T,
have headed
laboratories
the effort to develop as well as standardize tools and procedures.
Two, more than the other Japanese firms, the Fuchu Software Factory
has attempted to operate as a true "factory"
the sense of separating high-
in
design and then focusing on the building of new programs primarily by
level
assembling components from an existing inventory of reusable modules.
was done
but
to
some extent
appeared
it
be
to
exclusive
the
management (control) systems
programmers required
to
other Japanese firms studied
at the
register
And no where
else did
modules
were
for
needed
Toshiba.
at
month.
the
focus
a
a
certain
of
most
No where
number
of
else,
of
this project,
in
the
This
and
technical
for example,
were
modules for reuse each
committee decide on what type of generic
reusable
parts
database
and
then
allocate
Other Japanese software factories
resources to develop these components.
simply screened new programs that were written for modules that might be
potentially reusable
No doubt
reuse
strategy
diverse,
Kamata
it
other programs.
in
major
a
so
effectively
appears,
Software
reason
than
Factory
the
or
why Toshiba
has
been
its
has
been able to Implement
focused
range of applications
at
Hitachi's
Omori
Matsumoto and other Toshiba managers clearly did not
let
reusability
Software
either
Factory
Third,
in
happen or not happen,
enforced,
and monitored reuse
other Japanese or U.S.
more
like
like
Works.
sit
Fujitsu
s
back passively and
in
a
less
Nonetheless,
managers
at
at
--
at
fact
level
of
the
SDC
achieved).
discipline
facilities.
hardware manufacturers,
64
lines
products
(where high levels of reuse were not
Toshiba encouraged,
not apparent
product
its
Toshiba explicitly offered
a
tradeoff
in
program
and price.
quality
reliability
Customers could obtain
but only
at
a
particular
a
certain
other
While
cost.
level
of
software
producers delivered systems on contracts calling for quality specifications,
there
seemed
be more of
to
Japanese firms, compared
For example,
historical
rather
productivity,
quality
and reusability
continuously to eliminate
tested
Fujitsu
systems
control
all
focused on
at
at
other
Toshiba.
bugs predicted by
quality
control
and
Since the type of products being made at the Hitachi, NEC, and
facilities
than
preoccupation with
cost,
to
NEC and
data.
inspection.
Fujitsu
Hitachi
a
the
were systems
real-time
emphasis observed
at
and general
control
business
applications
programs made by Fuchu,
Toshiba may be specific to
its
this
product area.
software,
different
Still,
this
attempt to maximize worker productivity and minimize total costs was clearly
a
distinguishing
objective of
its
feature
of
the
technological and
Toshiba
Software
management systems.
65
Factory
and
the
main
REFERENCES
The current version of the main paper from this research project is titled
Michael A. Cusumano, "A Comparison of U.S. and Japanese Software
1.
Technology, and Structure," Sloan
Working Paper #1885-87 Revised 9/25/87.
Another completed case is "A U.S. Software Factory' Experiment: System
Development Corporation." Sloan School of Management 1987 Working Paper
Facilities:
School
of
Implications for Strategy,
Management
1987
,
,
#1887-87.
Yoshihiro Matsumoto (Toshiba), "Management
Production," Computer February 1984, p. 318 fn
9/4/87.
2.
,
3.
Toshiba, Annual Report 1986
4.
See Datamation
5.
Matsumoto interview.
6.
Shimoda, pp. 100-101.
7.
Interview with Matsumoto Yoshihiro, 9/4/87.
8.
Interview with Matsumoto Yoshihiro, 9/4/87.
,
1
.
p.
of
2;
Software
Industrial
Matsumoto interview,
1.
June 1985, pp. 58-120; and 15 June 1987,
p.
31.
Y. Matsumoto et al., "SWB System A Softwaie Factory," in H. Hunke,
ed.. Software Engineering Environments (North-Holland, 1981), pp. 305, 307.
9.
10.
Matsumoto 1987,
11.
Shimoda, pp. 102-103; Matsumoto interview.
12.
Matsumoto 1984a,
13.
Yoshihiro
p.
20.
p.
70.
Matsumoto and
S.
Yamamoto,
"The SWB
System
Supports
Industrial Software Production," Proceedings of the International Workshop
on Software Engineering Environments, August 18-20, 1986, Beijing China,
China Academic Publishers, 1986, p. 74.
14.
Matsumoto interview.
15.
Shimoda, pp. 107-108.
66
16. Yoshihiro Matsumoto (Toshiba Corporation), "A Software Factory:
An
Overall Approach to Software Production," in Peter Freeman, ed
Sof twa re
Reusability. ( E E E Tutorial, 1987), p. 1 (2 December 1986 manuscript).
.
,
I
17.
Matsumoto, "Management of Industrial Software Production," Computer
February 1984, p. 59; Matsumoto 1987, p. 2.
,
IEEE,
18.
Matsumoto 1981, pp. 305, 309.
19.
Matsumoto interview.
20.
Matsumoto 1987,
p.
20.
21.
Matsumoto 1987,
p.
20.
Y. Matsumoto et at., "SPS:
A Software Production System for MiniComputers and Micro-Computers," Proceedings COMPSAC '78, IEEE,
November 1978, p. 396.
22.
23.
Matsumoto 1987,
24.
Matsumoto interview.
25.
Matsumoto interview.
26.
Shimoda, p. 103; Matsumoto interview.
27.
Matsumoto 1987,
12.
p.
p.
2.
SDC project managers disliked giving up control to a centralized facility,
and SDC managers also failed to level the work flow to provide a steady
flow of projects into the factory, leading to SDC's abandoning its centralized
See the SDC paper cited earlier.
factory approach.
28.
29.
Shimoda, pp. 103-104.
30.
Matsumoto interview.
31
Matsumoto interview.
.
32.
Matsumoto 1981,
33.
Matsumoto response to survey questions.
34.
Matsumoto 1986a,
p.
p.
310
78.
See Y. Matsumoto et a!., "SPS: A Software Production System for MiniComputers and Micro-Computers," Proceedings COMPSAC '78, IEEE,
November 1978, pp. 396-401.
35.
36.
Matsumoto 1981, pp. 311-313.
37.
Matsumoto 1981, pp. 313-314.
67
38.
Matsumoto 1986a,
39.
Matsumoto 1981, pp. 314-315; Matsumoto 1987,
40.
Matsumoto 1987, pp.
41.
Matsumoto interview.
42.
Matsumoto 1987,
p.
2.
43.
Matsumoto 1981,
p.
309.
44.
Shimoda,
p.
Matsumoto interview.
77;
p.
12,
p.
14.
14.
107.
Dr. Yoshihiro Matsumoto, "Answers to Professor M, Cusumano's
Questionnaire" ("Large-Scale Applications Software"), February 11, 1987.
45.
46.
Matsumoto 1986/China,
47.
Shimoda, pp. 109-110.
48. Shimoda Hirotsugu,
Keizai Shimposha, 1986,
p.
76.
Sofutouea kojo (Software factories),
p.
110.
49.
Shimoda, pp. 110-111.
50.
Shimoda, pp. 111-112.
51.
Matsumoto interview.
52.
Matsumoto 1981,
53.
Matsumoto 1984a,
54.
Matsumoto 1987,
55.
Matsumoto 1987, pp. 9-10.
56.
Matsumoto interview.
57.
Matsumoto interview.
58.
Matsumoto 1987,
p.
10.
59.
Matsumoto 1987,
p.
2.
60.
Matsumoto 1981, pp. 307-308.
61.
Matsumoto 1987,
62.
Matsumoto 1987, pp. 4-5.
p.
315, and 1984a,
69.
p.
10.
p.
p.
4.
68
p.
60.
Tokyo, Toyo
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 Engineering (Reading, MA,
Addison-Wesley, 1975), pp. 88-94.
63.
64.
Matsumoto interview.
65.
Matsumoto 1981,
66.
Matsumoto interview.
67.
Matsumoto interview and transparency, "Programming Language."
68.
Matsumoto 1987,
69.
Yoshihiro Matsumoto, "Management of Industrial Software Production,"
IEEE, February 1984, p. 59.
Computer
316.
p.
20.
p.
,
70.
Matsumoto 1984a, pp. 60-65.
71.
Matsumoto 1984a,
72.
Matsumoto 1987,
73.
Matsumoto interview.
74.
Matsumoto 1987,
75.
Matsumoto 1981, p. 314.
76.
Matsumoto interview.
77.
Matsumoto 1987,
p.
17.
78.
Matsumoto 1987,
p.
18.
79.
Matsumoto 1987,
p.
18.
80.
Matsumoto (1984),
p.
68.
81.
Matsumoto (1984),
p.
65;
82.
Matsumoto interview.
83.
Matsumoto comments on survey questions.
84.
Matsumoto 1984a,
85.
Matsumoto response to survey question on planning for portability.
86.
Matsumoto 1984a,
65-66.
p.
17.
p.
14,
p.
p.
p.
17.
Matsumoto (1981), p. 308.
68.
68.
69
87.
Matsumoto 1986/China,
88.
Matsumoto 1981,
p.
307.
89.
Matsumoto 1981,
p.
315.
90.
Matsumoto 1984a,
91.
Matsumoto interview.
92.
Matsumoto 1987, pp.
p.
76-77.
70.
p.
6,
8.
Matsumoto response to "Additional Information Questions" in Cusumano
survey, 11 February 1987. Note: Clear the use of this data with Matsumoto.
93.
94.
Matsumoto interview.
95.
Matsumoto 1987,
Interviews with
12/18/86; and John
96.
97.
Matsumoto 1987,
p.
8.
Mark Harris,
Pilat,
p.
18.
an Industry," Proceedings
98.
Matsumoto interview.
99.
Matsumoto 1987,
p.
18.
an Industry," Proceedings
Manager.
Staff Consultant,
IBM Corporation, 12/16 and
Data General, 12/18/86.
Also see Y. Matsumoto, "Software Education
'8 2, November
1982, pp. 167-174.
in
Also see Y. Matsumoto, "Software Education
'82
November 1982, pp. 167-174.
in
COMPSAC
COMPSAC
.
100. Yoshihiro Matsumoto, "Software Education in an Industry," Proceedings
IEEE Computer Software and Applications Conference,
of COMPSAC 82
November 1982, pp. 93.
,
70
k53k 073
Date Due
llfP^K^^
2 1*8
0EC97
w
Lib-26-67
MtT LIBRARIES
3
TOflO D04 flSl
SED