|JUN
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
Fujitsu Software:
Process Control to Automated Customization
by
Michael Cusumano
WP 2044-88, Revised
June 1989
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
10
1989
Fujitsu Software:
Process Control to Automated Customization
by
Michael Cusumano
WP 2044-88, Revised
June 1989
JUN
1
1989
RECEIVED
,
CHAPTER
CONTROL TO AUTOMATED CUSTOMIZATION
FUJITSU: PROCESS
The products
made and the processes
Fujitsu
development closely resembled those
not
formally
operations at
establish
a
at Hitachi.
single facility,
it
followed
software
for
basic software, Fujitsu did
In
but centralized most programming
software factory
a
7
Numazu Works, and adopted factory-like
the
standards and controls during the mid-1970s, beginning with project management
and product inspection.
operations
in
1970
In applications,
and then began
establishing a Software Factory
in
began centralizing programming
Fujitsu
standardizing methods and tools
before
1979 to perform detailed design, coding, and
testing, often for specifications done
system engineering departments outside
in
the factory.
What distinguished
Fujitsu
was
most
the
in
network
software subsidiaries throughout Japan.
Toshiba, Fujitsu built upon
equipment
to
depth
computer hardware and software development, including
competence
of
and
breadth
enter
the
computer
industry
in
the
mid-1950s.
it
although
Fujitsu
in
Amdahl
also
proceeded
its
without
adopted
leading
foreign
the early 1970s, and relied on a
in
talented group of in-house engineers and careful study of U.S. technology.
strategy of deliberate,
independent development helped
largest Japanese computer producer
this
position
through
products or services
in
the
all
1980s,
huge
telephone switching and electro-mechanical
skills in
assistance, at least until investing
a
its
NEC, and
Like Hitachi,
transistors and introduced commercial models somewhat later than
Japanese competitors,
of
1968,
in
with
in
Fujitsu
This
become the
terms of sales, and remain
competitive
hardware
and
in
software
segments of the Japanese market.
The Nikkei survey data reinforced
1
this
evaluation of
Fujitsu:
It
was
Fujitsu
Ct^
l-lcurf
Japan's
largest
vendor
computer products for small,
of
systems (Tables 1.3 and 1.4).
was especially competitive
Fujitsu
and government agencies as
institutions
services,
information
Fujitsu first in Japanese-language processing
competing
They
Japan.'
in
Japanese competitors
as
also rated
it
in
sales to
and
machinery,
electrical
software among
in
all
1988 ranked
major firms
ahead of or equal to the best of
basic system software,
in
and large
ranging from
industries
to
Japanese customers
(Table 1.5).
construction to foodstuffs
well
chemicals,
distribution,
medium,
its
hardware price-performance,
applications system-engineering support, and general satisfaction (Table 1.6).
THE CORPORATE SETTING
Company Outline and Organization
Electric,
Fuji
an electrical-machinery producer affiliated with Siemens of
Germany and dating back
its
to 1923,
telephone equipment division
commercialized
Japan's
first
established Fujitsu
as
digital
a
company.
separate
calculator
1935 by incorporating
in
in
1935
and
The new
firm
expanded
into
switching systems and other electric and electro-mechanical equipment, before
introducing
a
primitive non-programmable computer
expanded product development and marketing for
equipment,
office
services.
In
1954.
Fujitsu gradually
range of communications and
computers and computer peripherals,
and data processing
the year ending March 1988, Fujitsu had over 52,000 employees
the parent corporation,
with more than one out of five personnel involved
software production or staff support.
billion
a
in
Fujitsu led
data-processing sales, which accounted for over $10
in
total
revenues.
in
Non-consolidated sales totalled over $13.7
(over $16 billion including some 70 subsidiaries).
firms
in
billion
all
Japanese
(72%) of
its
Other major revenue sectors for Fujitsu were communications
.
2
Fujitsu
systems (16%) and electron (semiconductor) devices (12%).
Fujitsu divided these revenue areas into more than a dozen operating and
marketing groups (Figure 7.1).
Several divisions produced computer programs
for internal or commercial sale, and a corporate Software
Group, established
Development Planning
1982, directed planning for tool and methodology research
in
and technology transfer for Fujitsu, subsidiaries, and subcontractors. The focus
of this chapter
is
the two largest software facilities:
the Computer Group, located near Mt. Fuji
hardware
as
well
as
systems
basic
in
Numazu, the main
site in
Shizuoka prefecture, which made
software
(operating
systems,
control
programs, network software, data base systems, language processors, Japanese
language and graphics or voice processing software, and automatic translation
and the Kamata Software Factory, located
programs) for mainframes,
Information Processing System Laboratory
the main
facility
in
the System
in
The
Kamata, Tokyo.
at the
latter
was
which produced custom
Engineering Group,
applications software and application packages.
Fujitsu
series
mainframes
System/370.
the
established the
and
The Software
department,
in a
constructed
1981,
a
Field
eight
in
development
Support Center.^
FACOM-M
1974 to produce the
Division, housed
departments,
and
in
designed
minicomputers,
hardware building)
engineering
Numazu Works
compete with
to
IBM's
separate building (connected to
consisted
of
departments,
two
an
software
inspection
The approximately 3000 software
personnel working at Numazu included about 1000 programmers from software
Despite the scale of operations at Numazu,
houses and subsidiaries."
management did not
label or publicize the facility as a
software factory, since
groups worked
in
Nonetheless,
in
addition
management,
begun around 1974-1975, and the centralization
integrated
to
teams
scale,
to
produce unique systems
the level of integration
•
3
Fujitsu
in
products.
operations and
of
most basic-
Fujitsu
software programming at this facility by 1984, made Numazu indistinguishable
from counterpart
referred to as software factories at Hitachi and NEC.
facilities
Fujitsu opened the Kamata Software Factory
in
1979 to continue
decade-
a
long effort, beginning with Fujitsu's establishment of the Information Processing
Laboratory
Systems
and
centralize
1970
in
rationalize
house the
to
Systems
Group,
Engineering
custom programming for banks,
securities
firms,
government departments, and manufacturing and distribution companies.
Department
Factory
Software
performed
to
The
programming and module-test
operations,
based on specifications received from approximately 4000 system
engineers
the Systems Engineering Group, and also did increasing amounts of
in
The factory was comparable
system design.
Hitachi
and NEC,
with
exceptional, however,
10 to 30 from its
were employees
size to
approximately 1500 personnel
comparable
facilities at
1987.
Kamata was
in
that merely 200 or so employees were from Fujitsu and
in
subsidiaries.
of
in
The remainder
--
nearly 1300 programmers--
independent software houses, with most remaining
at their
parent firms, linked by networks and terminals to computers and data bases
the Software Factory. °
Fujitsu
to
infrastructure
This extensive use of subcontractor personnel allowed
the
retain
and
still
benefits
of
a
centralized,
accommodate variations
in
standardized
In
addition
and expensive
to
in
the personnel
factory
demand for customized
programming without hiring too many permanent employees,
relatively scarce
in
which
were
Tokyo.
counted as part of the Software Factory
Department, Fujitsu could also draw on 58 software subsidiaries employing over
14,000 programmers for system engineering, applications programming, basic-
software development, and microcomputer programming (Table 7.1).
houses working on
personnel
in
a
Software
regular basis with Fujitsu brought total available software
the Fujitsu group circa 1987-1988 to about 20,000.^
4
Not only did
Fujitsu
these numbers, which exceeded the amount of programmers
and Toshiba groups, attest
affiliates
added from 1000
during the middle and
the NEC, Hitachi,
importance (and managerial complexities) of
to the
So did their rapid expansion, as Fujitsu and
software development to Fujitsu.
its
in
to 3000 software
and related personnel annually
late 1980s.
Entry into Computers
Fujitsu historians
mark the company's entrance
with the 1954 introduction of
This was
not
magnetic
relay
a
into the
computer business
dedicated accounting machine, the
programmable computer but was hardwired,
a
switches
adapted
from
FACOM
using
switchboards.
telephone
100.
electro-
Fujitsu
introduced several other relay computers before adopting parametron circuits
1958,
following the lead of Hitachi
and NEC,
in
although these computers also
functioned as dedicated calculating machines. Again following Hitachi and NEC,
Fujitsu began working on a transistor-based,
and introduced
its
Management then
establishing
a
first commercial
signaled
computer division
Fujitsu approached
this initiative failed
in
a
models
major
in
1961,
commitment
in
1958
for business applications.
to
the
new industry by
1963.^
IBM for assistance
in
computer development, but when
management pursued the business independently, investing
in-house research as well as frequently sending company engineers to the
United
States
to
learn
from
American
Prospects for Fujitsu seemed dim, since
Toshiba due to
a
it
firms
and
university
researchers.
was already behind Hitachi, NEC, and
late switch to transistors
providing Japanese competitors
all
in
programmable computer
and the assistance U.S. firms were
But when the flow of new models from the U.S.
but stopped during the later 1960s, as GE and
computer business, and Honeywell reduced
5
its
RCA prepared
to exit the
product development efforts,
Fujitsu
Fujitsu engineers
Hitachi,
were able
to offer
hardware superior
and large mainframes,
were the 230 series
initially
introduced
in
Japanese customers, especially
their
prices
low
government
and
These models attracted many
the banking industry and at universities, due
in
powerful
also aided these sales
Japanese computers,
processing
The Japanese
capabilities.
by placing restrictions on purchases
models
including
medium,
of small,
1965 with transistors but upgraded
1968 with more advanced integrated circuits.
to
from
NEC, or Toshiba.
Fujitsu's most competitive machines
in
to that available
from Japan
IBM.
of
non-
Nonetheless,
the
popularity of the 230 models made Fujitsu Japan's largest computer manufacturer
in
1968 and helped computer revenues exceed 50% of Fujitsu's sales, for the
first time,
1970.^^
in
Independent development might not have worked so well as
without the contribution of Toshio Ikeda (1923-1974),
Institute
of
Technology who had entered Fujitsu
Japan's
as
System/360 and
the
design
most talented
interests led him in 1969 to meet
designed
graduate of the Tokyo
relationship
between
Fujitsu
Gene Amdahl,
then
left
IBM
engineer.
his
in
and the Amdahl
through the 1980s and assisted Fujitsu
product strategy:
Fujitsu and
and
Fujitsu
Ikeda's
counterpart
1970
to
in
implementing
a
at
fame
and
IBM who had
found the Amdahl
Their meeting began
Corporation
a
that
continued
key change
in
its
adoption of IBM compatibility.
Amdahl were
logical
partners since Amdahl needed financing
managers believed they could expand their market share with
computers that competed directly for IBM customers.
reached
After designing
1946.
Corporation, to produce larger IBM-compatible mainframes.
a
strategy
he moved into computers and quickly gained
telephone switching equipment,
recognition
in
a
a
similar
conclusion,
and,
with
6
MITI's
Hitachi
managers had
encouragement,
Fujitsu
and
Fujitsu
Hitachi agreed to standardize their mainframe architectures and, without jointly
developing hardware or software, introduce models that, together, matched
all
the segments IBM's System/370 family covered.
became Amdahl's largest shareholder after the premature death
Fujitsu also
1974 and the recognition of Fujitsu executives that they could use
of Ikeda in
some assistance
of
UNIX
the
hardware design.
in
operation
1 '^
development.'"')
With
system,
circuits, utilizing the most
at
well
as
ICL
to
given price ranges.
and outside Japan:
cooperate with
Amdahl
to
deliver
logic
to
IBM
in
These machines proved competitive inside
modified to their specifications,
in
Amdahl as
and sold
its
Europe under the Siemens
14
Software Strategy:
Until
offer
software
in
IBM-compatible
hardware comparable
complete mainframes to Siemens for marketing
label.
produce
Fujitsu
Fujitsu manufactured central-processing units for
Great Britain,
in
not
of a version
advanced semiconductor technology available, Fujitsu
by the mid-1970s was able
performance
did
from
help
(Amdahl, with the exception
"^
the
M
products
series,
Products and Process
successful competition
comparable
in
functions
(and
in
Japan required Fujitsu
price-performance)
Japanese or foreign hardware and software available
in
model computer.
But Fujitsu's switch
exported mainframes affected
software
to
in
other
Japan. This involved
studying "state-of-the-art" products as well as attempting some
such as to accommodate two central-processing units
to
to
real
innovations,
the largest 230-series
IBM compatibility for domestic and
product and process
development
in
several ways.
To
a
large
extent,
all
producers
of
IBM-compatible hardware followed
external specifications -- descriptions of what products should do, rather than
7
Fujitsu
how they might operate
internally --
IBM
initially
the System 360.
set with
While IBM eventually challenged the legality of this action as well as modified
its
products to make them more difficult to emulate, compatible producers seem
to
have proceeded on the assumption that,
since OS/360 was
domain, they could follow OS/370 and later standards.
have recounted the details
of suits
by and against
the public
in
While other authors
.IBM, there are several issues
relevant to the subject of software-development management.
Most significant was that compatible producers were able to avoid the
more uncertain aspects
of
new-product development,
functions or creating new standards.
such as defining new
For basic software,
Fujitsu
managers
estimated that designing external specifications took approximately 10% of total
man hours (compared
to 10% for internal specifications, 20% for
program design,
30% for programming or coding, and another 30% for testing).'"
This meant
that relying on IBM's external specifications probably helped firms reduce
man
Commentators on the industry have supported
this
hours for new products.''
notion, claiming that most mainframe basic-software development at Fujitsu (and
some
at
Hitachi
as
well)
between the mid-1970s and early 1980s consisted
of
working backward from IBM manuals, rather than inventing new procedures or
functions.
Indirect evidence of this was the 1988 settlement between
Fujitsu, which called for Fujitsu to
licensing fees plus an annual fee
and
source
code,
primarily
to
if
pay IBM several hundred
it
wanted
understand
to
the
million dollars in
review licensed IBM manuals
interface
specifications
1
facilitate the
by definition,
in
Q
In
First of
all,
IBM,
the IBM-compatible market, was able to set most
standards and decide schedules
introductions.
to
continued production of IBM-compatible hardware.'*^
Yet the advantages of compatibility were not absolute.
as the leader,
IBM and
(and some prices as well)
for
new product
custom applications programming, the bulk of software demand
8
Fujitsu
in
suggestions on how to design
usually different enough
so
IBM or other vendors
that
it
was
rarely
might
provide
But customer needs were
particular system.
a
Because projects generally had
specifications.
sufficient
to
existing
follow
design
to invest the time to
a
external specifications, IBM compatibility probably offered firms such
full set of
as
from
software
existing
Japan,
Fujitsu
little
savings
in
manpower
for
applications
compared
to
basic-
software development.
At the same time, maintaining compatibility with new IBM hardware proved
increasingly difficult after the
functions
hardwired
in
producers committed
to
late
chips
that
1970s,
were
when IBM began
difficult
IBM compatibility had
to
to
to
embed more
duplicate.
Mainframe
devote more time to working
backwards from announced, often incomplete specifications, and would probably
always
lag
introduce
behind
its
new-product introductions
in
systems.
superior "price-performance."
--
they waited for
IBM
to
Japanese firms (and Amdahl) competed by advertising
hardware that, while sometimes
and performance
as
required
later
in
This goal
a
mode
of
delivery than
-- a
IBM products, offered
combination of competitive prices
design
and production management
oriented less toward product innovation and more toward incremental product
improvements following IBM as
well as process efficiency in
all
phases of basic
hardware and software development.
In
both basic and applications software, similar to other Japanese firms,
Fujitsu managemervt In the early 1970s began promoting process rationalizations
aimed at the "accumulation and improvement of technology," both individual and
organizational.
According
to internal training materials, this rationalization for
software production centered on three broad areas:
specialization,
The drive
development technology,
and mechanization/automation (Figure 7.2).
to
improve development technology within Fujitsu
9
in
the 1970s
Fujitsu
and early 1980s consisted
coming
engineering
software
making greater use
of
mainly
from
the
of
fundamental advances
United
and
States
in
Europe:
higher-level languages (though standardized for in-house use), modularization
-Nk
and structured methods for design and programming, quantified controls for
product inspection and process reviews
time spent on
product
reliability
minimizing the volume of new code programmers had to
at
write through what managers called "common development":
designs
in
a
computer language or
into different languages
(2)
and reduce
Another aspect of development
programs.
fixing or altering
technology aimed
to insure
(1) writing
program
flow-chart form that could be compiled
in
and storing the components
in
a
reusable library; and
designing basic programs or components, such as compilers, for use
more
in
than one of Fujitsu's operating systems. ^
Specialization
included
the
establishment
of
development organizations
such as the Numazu
dedicated to different types of software and functions,
Works Software Division and the Kamata Software Factory, smaller
linked by on-line networks, as well as subsidiaries specializing
in
facilities
various areas
or providing regional system-engineering services throughout Japan. ^^
Hitachi and
with
As
at
NEC, these subsidiaries, supplemented by long-term arrangements
independent software houses,
customers and specific applications
provided
skills,
not
only
regional
services
but they allowed Fujitsu to add
expensive and temporary capacity for programming operations.
to
less
Another strategy
related to the concept of specialization was to have development groups with
special
knowledge
of
common
applications
gradually
write
packages, especially for personal and office computers,
packages with new software
to
more
software
and integrate these
produce semi-customized systems.
Mechanization or automation referred to the use of computer-aided tools
to
support design,
coding,
testing,
10
and
maintenance,
including
program
Fujitsu
generators and reuse-support systems, which offered the potential of raising
productivity and quality simultaneously.
Fujitsu
management
also
application of automation and mechanization to control technology,
of
project management,
for planning,
tools
integrated with standards,
circles,
as another
way
to
in
the form
and quality evaluation,
manual procedures, and practices such as quality
support development technology and specialization.
Again, there was nothing unusual
software development,
testing,
viewed the
in
Fujitsu's approach to automating aspects of
except perhaps
in
degree
emphasis, particularly
of
in
applications programming.
BASIC SOFTWARE
Product- Process Development
Fujitsu's decision in the 1960s to develop
computer products independently
challenged company engineers to master not only hardware design but also
software
programming.
A sampling
of
packages
personnel produced between 1962 and 1984, listed
indication of the scope and scale of their efforts:
in
Fujitsu's
basic-software
Table 7.2, provides some
From 1960 onward, Fujitsu
offered an increasingly wide range of compilers, operating systems, and tools,
in
addition to customized programs and integrated hardware-software systems such
as for banks,
government agencies, manufacturing and distribution firms, and
telecommunications systems.
Fujitsu's offerings
seemed comparable
from other Japanese and U.S. firms, and, judging by success
place,
they were possibly superior.
in
to
products
the market
Most important for the subject of this
book, as the discussion below indicates, Fujitsu managers and personnel made
a
series of interrelated efforts to create an integrated, standardized process and
organization for basic-software production as products became more numerous
n
Fujitsu
and complex.
software development began
Fujitsu's experience with
the early 1960s
in
with the introduction of several transistorized computers, since the relay and
parametron computers of the 1950s were either hard-wired or required only
minimal
programming.
Even the
transistorized machines
first
did
have
not
"modern" operating systems but performed simple batch-processing operations
Like other firms
and only required specialized routines and language compilers.
pioneering
in
the computer industry, Fujitsu gradually introduced other software
systems, following IBM's lead conceptually,
An important early product, because
not technologically.
if
it
exposed Fujitsu engineers
FONTAC,
types of programs and computer languages, was the
to
the
Electronics
Industry
Promotion
Association
delivered
Japan.
of
This
to
new
in
1964
was
a
cooperative project among Fujitsu, NEC, and Oki Electric, which MIT! sponsored
to
encourage domestic firms to build
to IBM's 7090 machine,
a
large-scale computer roughly equivalent
which IBM had introduced
NEC and
main processor and the card punch equipment, while
the sub-processors
and input/output devices.
Fujitsu designed the
1960.
in
Oki Electric made
also
Fujitsu
took charge of
programming, with assistance from NEC and Oki engineers, several Japanese
The software
Fujitsu provided consisted
professors, and
a
of a "monitor,"
based on earlier control programs available
few U.S. consultants.
ALGOL, COBOL, FORTRAN, and ASSEMBLER
compilers;
a
in
Japan, as well as
library editor; a sort
generator; an executable coded tape editor; utility programs; and several object
(applications)
programs.
introduced this
in
1965 as
Fujitsu
later
MONITOR
II
modified
with
its
the
FONTAC
monitor
230-50 mainframe,
and
Fujitsu's
21
commercial version of the FONTAC."'
A more serious challenge
Fujitsu
engineers faced
develop an operating system comparable, at least
.
12
in
in
the
1960s
was to
basic functions, to IBM's
Fujitsu
OS/360, which had set new standards for the entire industry.
upgraded 230-series models, especially the dual-processor
this software for the
which
230-60,
Fujitsu needed
incorporated
integrated
The demands
extensive processing capabilities.
and
offered,
of this
for
the
programming
MONITOR
Fujitsu completed this in 1968,
V.
time,
led Fujitsu
department for the TOO or so employees needed
to establish a separate
the operating system,
circuits
to build
after two
years of development and numerous tribulations.
According to
difficult to
in
U.S.
several
engineers,
Fujitsu
MONITOR V was
develop due to the dual-processor architecture, then available only
military
Furthermore,
computers.
had not yet designed
Fujitsu
sophisticated operating system even for one processor,
OS/360
Fujitsu used
as a conceptual model, the 360 architecture
well as the
new software department, Takuma Yamamoto
resident
(Fujits
trips to the U.S. to seek assistance from A
houses and computer manufacturers.
especially
U.S.,
to
visit
assistance
to
complete
the
to
in
can software
This was typical of Fu'
which, rather
than buying technology from the U.S., encouraged perso'
frequently,
was completely
including Ikeda and the head of the project as
Fujitsu engineers,
made several
a
alone two, and while
let
different.
1988),
extremely
to travel abroa'^
consultants,
suppliers,
competitors.
Fujitsu
delivered
in
still
an
required
initial
debug the system,
version to the Kyoto University Computer Center
months behind schedule.
In
retrospect,
MONITOR V and
were major successes commercially and for the lessons
and organization they forced Fujitsu
MONITOR V demonstrated
importance of
effectively
in
1969,
Kyoto University personnel helped correct problems
and finish the programming.
overall
and
to
the 230-series
in
management
to encounter.
top
managing
management,
large-scale
13
for
software
the
first
time,
development.
the
In
Fujitsu
recognition of his success
promoted Yamamoto
1968
producing
in
to
department, Yamamoto,
of
like Ikeda,
V, company executives
in
programming for both systems and
director of
A 1949 graduate
applications.
MONITOR
Tokyo University's
had started
in
engineering
electrical
hardware, designing telephone
switching equipment and then relay computers before moving to data-processing
equipment design and then
corporate director
that
certain
improving
1975
in
V.
As he rose
and company president
in
the executive ranks to
1981,
in
software-development process and organization.
its
MONITOR V was
that
it
helped prepare Fujitsu for the
task
of
the
comparable
to
OS/370 that would serve the M-series
managers
in
1970s:
to
develop
the early 1970s introduced
more advanced operating
a
a
1974.
To minimize the development
also decided to
MONITOR
VII, completed
to
cover the small, medium, and
contrast to the five separate programs IBM offered for
in
The
370-series models.
first version of the operating
mainframes, OS IV/F4, Fujitsu successfully delivered
with versions for mid-size and small mainframes
less
Fujitsu
effort for the M-series software, Fujitsu
produce three operating systems
large mainframes,
hardware.
system
succession of new procedures and
control systems for successor products, beginning with
in
Yamamoto made
provided sufficient direction and resources to continue
Fujitsu
Another benefit of
major
MONITOR
in
system for
its
its
largest
1975, and followed this
in
1977.
These were more-or-
on time and commercial successes, although the scale and complexity of the
M-series programs again convinced Fujitsu management to take another series
of
steps to upgrade and standardize procedures,
phases of software development and control.
Another manager who rose
Mitsugi,
in
Engineering
1988
a
to
methods, and tools for
all
^•^
prominence during
this period
was Mamoru
Senior Executive Director and head of Fujitsu's Systems
Group.
He would
later
14
carry
forward
the
idea
of
process
Fujitsu
to
rationalization
1979.
the establishment of
software factory for applications
a
in
the meantime, Mitsugi headed the effort to develop the M-series basic
In
software and, at the same time, to systematize process and quality control
Like his predecessors, Mitsugi had worked as a hardware
the entire division.
designer, developing telephone exchange systems Fujitsu supplied to NTT.
he was one of the first managers to have an extensive background
inspection,
for
initially
programs
supplied
NTT
to
equipment, before joining the basic-software group
inspection
to
along
software
in
with
But
switching
head operating-systems
1973.
in
While Japanese firms separated commercial software development from
contracts, working for
practices
in
Mitsugi
of
Implementing
NTT
as
in
well
specifications
NTT
the early 1970s clearly shaped the thinking and
as
counterparts
his
NTT
from
received
for
at
NEC and
systems
such
Hitachi.
as
DIPS
(Distributed Information Processing System), and producing the hardware and
software
in
conjunction with other firms,
required
in
commercial departments, because of NTT's exacting standards, managers
who moved from NTT work
management standards.
Mitsugi compared
to
to
contractors to establish
Since these were even more rigorous
and follow product and process standards.
than
all
its
to commercial
systems brought with them higher
For example, after joining the basic-software group,
product and process control operations and decided he had
strengthen the inspection department as well as expand the department's role
improving
products.
'^"^
process
standardization
He also realized Fujitsu had
while meeting
rather
to
than
just
--
an
intractable problem for
commercial divisions during the 1970s due to rapid growth
NTT was
very advanced
15
finished
make these long-term improvements
short-term development targets
At the time,
inspecting
in
its
in
thinking.
demand:
The DIPS
Fujitsu
/
software was really
a large
Since three companies, including
system.
My
had to develop the software, standardization was essential.
us,
NTT
impression was that
was able
devote more effort to software
to
phase divisions and carrying out work standardization than we were
able to do
Of course, we influenced that
the private sector.
in
thinking, too, since there was an interchange among us, an exchange
of information.
software was
quickly
to
.
.
.
This was
increasing
meet
programs.
This
conformance.
In
is
In
period of rapid growth, and demand for
rapidly
We had
too.
demand,
this
documentation later.
a
and
to
worried
programs
write
about
preparing
other words, we gave top priority to writing
tended
documentation
defeat
to
the long run this
is
program
and
self-defeating, and, like
NTT,
better to review and inspect every phase, and get rid of as
bugs
as possible in
each phase.
But,
in
it
many
the private sector, since
software development must have more constraints on time and costs,
even though we were aware of this problem, there was not much we
could
do.'^'*
Product. Process, and Quality Control
An
important
organization
for
characteristic
basic
software was
product, process, and quality.
at
NEC,
in
the
Fujitsu's
the gradual
Department
a
three main phases:
integration
(later
Numazu Works's Software
headed before becoming division manager
According to
development approach
Direction of Fujitsu's efforts
came from the Inspection
Assurance Department)
of
in
in
of
controls
when
16
for
these areas, as
renamed the QualityDivision, which Mitsugi
1974.
chronology the department prepared, these efforts
prior to 1970,
and
Fujitsu
fell
into
had no set procedures and
Fujitsu
managers allowed programmers
1978,
when
Fujitsu set up
its
to test software at their
first
own discretion; 1970-
product and process standards and formal
systems for inspection and quality control; and the period after 1978, when
Fujitsu
began placing more emphasis on structured design and programming
techniques and established the procedures that formed the basis of
Distinguishing the last phase was
practices.
Department's
concerns
include
to
not
a
its
current
broadening of the Inspection
simply
and
testing
documentation
conformance, or product evaluation, but analysis of the development process
itself
(Table 7.3).
While the process rationalization this chronology details closely resembled
process evolution at other Japanese and U.S. firms, Fujitsu managers appeared
to
have some special emphases rather early on.
One was
quality more from the perspective of the customer than
such as zero defects, which Hitachi tended
during the development of
testing section
in
in
MONITOR
to do.
and
to view inspection
in
an absolute sense,
This orientation emerged
V, when Fujitsu established
program
a
1968 to evaluate software by comparing specifications stated
manuals to product performance.
the group's primary function.
Assisting designers
The next step came
in
debugging had been
in
1971, with the creation of
formal product-inspection procedures, such as requiring completed software and
manuals to pass
manage
this,
a
Fujitsu
instituted
evaluation and registration.
source
code,
To
formal inspection process before release to the customer.
manuals,
development groups
systems
for
"product
handling"
as
The product-handling procedures required
well
and
bring
other
documentation
these
product
not
only
components
to
the
that the
but
agree
as
that
inspection
department together. Previously, software was sometimes completed and released
without proper documentation or checking.
received
a
registration
number,
After 1971,
however, no product
necessary for release to customers,
17
without
Fujitsu
meeting these requirements and gaining the formal approval of the Inspection
Department.
After making some progress
more
product control, Fujitsu managers turned
in
During 1973-1978, Fujitsu launched three interrelated
to defect control.
standardizing software development practices, collecting quality and
efforts:
performance data,
divisions
to
and
applying
quality-control
A planning section organized
software.
for the first few years.
initiatives
operations,
In
used
techniques
other
in
1972 oversaw these
in
recognition of the increasing scale of
Fujitsu also elevated basic software to divisional status
in
1974.
Increasing product size and complexity also persuaded Fujitsu managers to
pay
more attention
standardization.
more
project
to
management
During 1973-1975, the division started
as
a
well
as
process
Development Planning
and Report System, which set up formal work-estimation procedures for project
managers
objects,
to
use
in
estimating man-power needs,
quality objectives,
product
and schedules. As an example from 1984 shows, the system did not
simply divide authority or tasks functionally but required different groups to
share responsibility for quality, planning, and control
in
all
development and
testing phases (Table 7.4).
The chronology
also
charts
the application
of
computer-aided
process control and their integration with standardized methods.
in
tools
to
For example,
1975-1976, to automate data collection for quality and budget measurements,
Fujitsu introduced
after
two
years
BSMS
of
(Basic Software Project Management Support System),
research
and
trials.
BSMS supported new
project-
management and development procedures and gradually became more valuable
a tool
as
for estimating schedules and monitoring the development process, as well
as for aiding testing and inspection.
BSMS and the Development Planning and Report System continued
18
to
be
Fujitsu
the centerpieces of Fujitsu's production-management system for basic software
in
The systems worked
the 1980s.
submit
as follows:
product-number application
a
approved, they submitted
a
to
project managers had to
First,
begin
a
project.
If
The development and planning documents
budget.
market survey and basic-design specifications
also required a
their superiors
listing functional,
performance, and reliability objectives, as well as estimates of manpower and
The
machine time.
system then centered on the development and
control
planning documents and monthly reports of actual work hours, computer time,
and
phase completions,
estimates.
which
BSMS tracked and compared
the
initial
^"^
The development process and
basic design,
model:
to
controls followed
conventional life-cycle
a
functional and structural design,
detailed design
and
coding, unit and combined test, component and system test, product inspection,
delivery and maintenance.
phases for
charts
in
MONITOR
had used PERT charts to manage these
Fujitsu
work
VII but found they did not
the mid-1970s,
generated manually
through the on-line BSMS system.
at
first
The introduction
Software Division compile and maintain an
actual data on past projects to guide
well
managers
in
to
bar
and then automatically
of
"estimation
and switched
BSMS
also helped the
handbook" containing
their estimates.
Completion of functional and structural design required documents detailing
the
function
of
each
system
between each module, plus
a
module structure,
component,
testing plan.
and
interfaces
Detailed design required flow-chart
and tabular documentation on the internal structure of each module, and input
and output structure.
required
a
At the completion of unit and combined test,
programming
documentation,
source modules.
report,
which
included
the
detailed
Fujitsu
design
review reports, test specifications and results, as well as the
After system test, the testing report documentation included
19
Fujitsu
the inspection specifications, test specifications and results, and the test set.
Final inspection
generated another set of results.
The most important quality measures
component
test,
conformance
reliability
in
detected,
and mean time between failures.
introduced
in
sort through
used
Fujitsu
in
documentation,
to
1970s
the
number
of
were
bugs
Main-factor analysis techniques,
1974 and influenced by practices at Hitachi, required testers to
intermediate test data to identify sources of bugs,
before final
testing. Standardizing testing and review procedures was particularly important,
because Fujitsu previously had not adopted
and eliminating bugs.
the
in
later
1970s
Better control
track
to
consistent approach for predicting
programmers decided which tests
Individual
without formal planning or supervision.
Fujitsu
a
other
in this
measures,
to
run,
area then allowed
such
software
as
functionality and portability.
In
the
period
Assurance Through
underlying
Quality
assurance activities
in
1979,
Fujitsu
Organization,
Development,
Horizontal
especially
after
emphasized
Diffusion
systems
a
themes:
Inspection
Ideas
and Advancement of Quality Concepts.
Assurance Through
part of
the
Organization
design and planning,
was
organizational
formal
rather than
Inspection Department. Fujitsu implemented this
1979-1980
of
three
a
to
Through
The
notion
make quality
and job
function
Quality
structure,
restricted to the
new emphasis by
instituting in
"phase completion reporting system," resembling the design-review
used at other firms,
and then
a
new version
of
its
Development
Planning and Report System. The new reporting system required, for the first
time,
programmers and managers
to collect
productivity data.
Standardized
productivity data then allowed Fujitsu to introduce standard times for worker
performance
in
1980,
based on actual previous data for different types of
software, and incorporating quality objectives.
20
Although Fujitsu was several
Fujitsu
behind
years
standard
Hitachi,
became the basis
quickly
times
of
project
management.
Diffusion of Inspection Ideas
deliberate efforts
control
spread good thinking and practices
to
beyond one's
small
different
departments
quality-related
and
As
data.
The mechanism
group.
Assurance Liaison"
"Quality
Through Horizontal Development referred
(QAL)
projects
part of
--
shared
this
regarding quality
Fujitsu used was to create a
system
a
to
of
regular meetings where
information
initiative,
bugs
on
Fujitsu
and other
established
other
quality-control measures, including small groups (like quality circles), initiated
for software
Advancement
1980 as part of the company-wide High- Reliability
in
of Quality
Program.
Concepts centered on lectures, workshops, and measures
dealing with interpretations of product quality that extended beyond "zero bugs"
to characteristics
such as product design, function, performance, ease of use,
and maintainability, as U.S. experts
Fujitsu
like
Barry Boehm encouraged.
managers interpreted these efforts as constituting
process control, as
in
the 1970s, to "Total Quality Control" or TQC.
coined during the 1950s
since the 1960s,
TQC
a transition
in
from
A term
but more popular among Japanese firms
the U.S.
represented comprehensive quality-assurance measures that
covered product planning, design, manufacturing, and service, rather than simply
inspection after production.
back
in
to 1966,
The
origins of the
when management launched
its
TQC movement
in
Fujitsu date
High-Reliability Program, primarily
hardware development and manufacturing divisions.
Fujitsu's efforts in basic
software gradually came to include procedures for project and budget control,
work and product standards, product evaluation, registration, and maintenance,
set
by
small
a series of
groups,
discuss
a
committees (Figure 7.3).^^
emphasized since 1980,
range of issues related
which
Another element was the use
met once or more
to productivity
21
a
month
of
to
and quality, as well as work
Fujitsu
conditions.
Managers also used the small groups
required of new company employees.
Program, initiated
with
establish
to
supplement formal training
second High-Reliability
of the
1984, the Software Division also
in
and contractors
subsidiaries
As part
to
began working extensively
TQC
systems similar to what
existed at Numazu.^'
Quantified Managenient System
Fujitsu's
Numazu Works attempted
to
quantify
basic
performance and then introduce standardized procedures and
conventional
attempted.
factory
rather than
approaches.
relying on
information
on
First,
project
and help developers "build
skill,
inspection
achieve these ends, Fujitsu staff
four
institution
correction.
much
as
tools,
in
at
each
the end of the process.^"
To
inspection and quality assurance worked on
were the efforts
progress
and
to
quantify
product quality.
of
a
analyze
was
Second,
the
the programming phase
in
"management by objectives"
and then
system
aimed
error
at
Third, to determine test items, was the use of statistical "Design of
Experiment" techniques, often referred to as the "Taguchi method"
and
have
facilities
in" quality at
introduction of methods to predict error occurrence
and
software
factory-like
of
Major goals were to reduce individual variability and dependency on
high-levels of experience or
phase,
and
organizations
measures
generally
applied
only
to
product
development
conventional hard products such as automobiles.
and
in
the U.S.
processing
of
Fourth, was an attempt to
evaluate quantitatively the concept of "user friendliness" of software.
Measuring
common way
number
design
progress
to evaluate schedules
of completed modules,
or
was
was
in
problematic
to
because
the
most
compare actual progress, such as the
Fujitsu's case,
and "work items," with estimates made prior
22
mainly
completed
to starting
"design sheets"
work. Accuracy of the
Fujitsu
measure thus depended on the accuracy of the prediction, which managers could
To evaluate projects,
not fully determine until completion of a project.
used two indices:
One measured
quality, based on points received in reviews,
and another quantity, examining how well predicted amounts of work
These data
results.
also
Fujitsu
helped managers
define tasks
fit
realistic
small,
in
actual
segments, and minimize estimation errors.
The system worked
followed:
as
In
the
planning
managers
stage,
determined work items, entered these on work item sheets, and entered them
into
BSMS
the
data
Work items were segments
base.
activities that teams could finish
organized projects,
work item
at
in
Division
groups, and each group leader was responsible for one
Each project member had to
time.
a
or other
The Software
about two weeks.
in
design
of
fill
out
a
"review trust
sheet," as well as undergo reviews from several other people, including
reviewer.
Reviewers used
make changes
until
a
a chief
check-list to evaluate work, and members had to
reviewer was
the chief
At weekly progress
satisfied.
meetings, managers and group leaders checked the progress of each work item.
The
quality index compared the
with the
number
Completion
of
number
of quality points
of predicted quality points, assigned
materials
for
reviews
received
50
reviews and changes required brought 100 points.
for completion of materials for reviews, and 50 or
received
through
points;
a
in
reviews
simple scheme:
completion
of
all
Projects received 50 points
more points depending on the
review evaluations.
Using these formulae, Fujitsu quantified measures for each project member
and project,
including product quality.
statistical regressions
and factor analysis
estimate numbers of bugs and
estimates.
In
addition,
to identify
Fujitsu
probable causes of errors,
man-power requirements, and
Progress evaluations
test the accuracy of
depended on the accuracy
still
.
23
regularly used
of the predicted
Fujitsu
,
values, which sometimes were far from actual values.
managers claimed
to
Overall, however, Fujitsu
have solved the major problems
reported significant improvements
with
the
system and
progress control as well as quality (see the
in
discussion on performance below).
To quantify "ease
and
inspections,
questionnaires.
many
as 113 in
use,"
of
validation
employed
Fujitsu
by
accuracy
of
surveying
and
reviews
through
users
Users evaluated products on specific items, which numbered as
some surveys, using simple "yes" or "no" responses and giving
These items evaluated basic
more points for major as opposed to minor items.
(product
product characteristics
compatibility,
manual
performance,
coordination, ease of maintenance,
reliability,
operability,
price
quality of information,
and delivery), design quality and consistency (defined as the "degree
which
to
software targets and specifications meet user needs," and the "degree to which
the
finished
meets
software
design
the
targets
and
specifications"),
and
sufficiency and attractiveness ("the extent to which products are acceptable to
users").
The surveys indicated
(such
major
categories:
as
that users grouped these features into three
friendliness,
understandability)
efficiency,
intermediate (such as productivity, ease of learning, maintainability), and minor
(such as syntax flexibility, speed of operation).
DeskHlinq and Standardization of Testing
Fujitsu's objectives
program by the end
and
as
many
process. ^^
of
testing were to detect 65% of the bugs
of the coding
the
remainder
in
a
phase review, 95% by the end of system
as
A problem encountered
as in the design of
too
in
in
possible
by the end
of
the
new
test,
inspection
meeting these goals, however, was that,
any complex product or process, large programs contained
many combinations
of
factors
and
24
conditions
to
test
completely.
Fujitsu
company data showed
Furthermore,
personnel to detect errors
in
software as their experience increased, with
leveling off after about six years.
managers decided
employ
to
significant improvement in the ability of
a
As
a
result of these observations,
method
for
experienced could understand, as discussed
selecting
in
test
cases
Fujitsu
that
less
1987 article by an engineer
a
a
in
the Quality Assurance Department:
In tests
involving
many
inspectors,
a
means
is
essential to standardize
the quality of testing conducted by each inspector,
as
limit
skill
to
the extent to which one can
through training.
analysis
is
.
.
.
The omission
is
a
share the knowledge and
of test cases
associated with problems
often
but there
during test factor
relating to the scope of
knowledge and insight of the testing personnel.... The omission of
test cases during test case generation
careless errors.
..
.
is
often caused by omissions or
[T]he number of test factors [selected] increases
in
proportion to employed years up to 6 years and stays constant after
Therefore, to improve the quality of test factor analysis as
that.
whole,
less
it
is
a
significant importance
knowledge regarding software testing.
much
knowledge
to
experienced testing personnel. ^^
Two approaches appeared most
as
to transfer
[sic]
a
useful
in
One was
and
capturing
transferring
to develop tools that
automated
of the testing process as possible, particularly the generation of initial
tests based on a program's external specifications or input characteristics.
tools often could identify critical factors that
a
program.
The conventional way
cause-effect graphs,
were the source
of most errors in
of generating initial test cases
but these required
25
a
great deal of
Such
was
knowledge
to
use
to
use
Fujitsu
effectively.
A second approach was
complete with
methods and conditions,
base on test-factor analysis
to create a data
an
editing
support function to help
personnel utilize the data base to create test cases for new programs.
of this latter technique Fujitsu introduced,
As part
beginning around 1980, Design of
Experiments methodology.
The Design
of
Experiments techniques relied on educated guesses of where
problems were likely
then
specific
(which could be listed for easy reference), and
to exist
and evaluated relying on tables
selected
tests
arrays" (statistically independent groups of factors)
it
possible to control the
factors
number
.
of
Fujitsu claimed these
of combinations that existed
cause-effect graphs.
made
between any two
and minimize measurement errors and other conditions,
identify correctable defects
"orthogonal
as
well
as
more quickly than conventional techniques such as
In fact,
Fujitsu data indicated that the
actually detect 5 to 10 times or more the
number
DE methods could
of errors usually
found with
conventional methods, with fewer test cases. ^'
Tool Support
Similar to
introducing
Hitachi,
Toshiba,
and NEC,
numerous computer-aided
production and the management process
center of tool
R&D
until the
facility, Fujitsu Laboratories,
program construction.
plan, as at Toshiba,
in
tools
the mid-1970s,
to
support
(Table 7.5).
the
Fujitsu
began
basic-software
Numazu remained the
mid-1980s, when Kamata and the central research
began studying how
to
automate system design and
Perhaps because management had no specific "factory"
Numazu developed most
of its tools for discrete use rather
than as parts of an integrated on-line system, although standardized methods
accompanied many of the design-related tools, and Numazu had the capability
for
data-base
links
among TDPII,
ITS,
26
and the Dump Transfer system
Fujitsu
BSMS and TDP
(maintenance),
construction)
Two
GEM and PRISM (program
-^
.
BSMS, described
basic systems were
Program Editing and Management
collection
and
(control),
II
tools
Facilities),
earlier,
a
and
GEM
(Generalized
library-management and data-
that automatically generated graphic reports,
individuals, on productivity (lines of code developed)
,
for
groups and
progress status (by month
The library functions included
and week), and quality (bug levels per module).
version control of modules and completed programs, as well as compressed data
to reduce the volume of stored files.
Another important
Control
chart),
which
Programming System),
tool
and methodology set was YACII
Fujitsu
a
tool
used for functional design,
Another
and VPS
(YACII
used
at
the
NTT.
YAC
charts
in
1980,
The current version,
1987 along with YPS, contained an editor, compiler, debugger, and
documenter, and received inputs
work
introduced
Fujitsu
modeling them after similar diagrams
in
(Yet
developed at Kamata that automatically generated
code from the flow charts.
introduced
"^
stations.
in
structured but conversational Japanese on
A host computer translated the inputs
YACII charts and then executable "bug-free" code
(Logic Design Language), a language based on
Fujitsu developed to use with
C
in
machine-readable
into
C, Fortran, Cobol, or
LDL
for basic-software design that
YACII charts. (LDL replaced an
earlier in-house
language, System Programming Language or SPL, which Fujitsu had based on
PL/I). 34
As discussed with reference
code generators) and
enhanced productivity
level design.
to similar tool sets at Hitachi
NEC (SPD and DECA),
in
nearly
They helped
all
(PAD and PAD
the combination of YACII and
YPS
phases of development, at least after high-
eliminate poorly structured programs by supporting
top-down, structured design through graphical and text representations.
27
They
Fujitsu
practically eliminated coding errors, since the designs were executable.
reuse of whole programs,
facilitated
program
at the design-specification
languages or architectures.
They
program parts, or edited portions
level
of a
and thus across different computer
They included executors, test-coverage evaluators,
and debuggers that executed the charts, and helped developers evaluate the
comprehensiveness of test cases, collect and analyze data, and debug programs.
The
also
tools
enhancements,
in
facilitated
first
maintenance,
both
fixing
problems
and
adding
by minimizing coding errors and then by presenting designs
standard formats that were relatively simple for third parties to understand.
A document generator
the design
charts.
also
in
produced detailed specifications automatically from
addition,
YPS and other systems included reverse
generators that produced design charts from source code; developers could then
edit the charts
more easily than source code as
as store the charts in a
well
data base for later retrieval. ^^
Performance Improvement
Fujitsu did not publish or
make available much performance data for basic
software,
although information available indicated steady gains
after 1975
in
schedule
control
in
the decade
quality (reliability), productivity (development costs), and project
(lateness).
The major products
at
Numazu,
mainframe
operating systems and related components, were lengthy and complex, totalling
as
much
as
2
million
lines of code,
excluding data-base software, with major
individual components running from about 100,000 to 800,000 lines of
C and LDL
source code (without comments). ^°
For
all
code
in
the field
(new code plus maintained software), between
1977 and 1979, bugs reported by users dropped by one-third, and then another
one-third
between
1979
and
1982
(Table
28
7.6).
By
1985,
bug
levels
for
Fujitsu
outstanding code had fallen to practically zero (0.01 and below).
not
allow
the publication
similar gains.
data
of
Bugs per TOGO
code)
all
Improvement since 1981 leveled
alone.
and below, although
this level
but this
showed
new code reported by users (generally
lines of
about 10 times the level for
0.1
newly written code,
for
Fujitsu would
four-fold
fell
bugs dropped
as
off,
1980 and
between
to
1981
approximately
was already excellent by most standards and
the averages reported for Japan and the U.S.
(see Appendix B)
.
Fujitsu data also suggested that the review procedures instituted after the
late
1970s
number
helped create these low bug levels and,
of defects in design.
For example,
in
1977,
especially,
cut down the
Numazu personnel detected
approximately 85% of bugs found through testing and 15% through reviews of
source code (coding phase review).
Design-sheet reviews, instituted
in
1978,
found more bugs and gradually became the major method for bug detection,
rising from 5% to approximately 40% as early as 1982.
Productivity was another area where management would not publish data,
in
part
because of
lack
a
standardization,
of
until
the
mid-1980s,
in
how
projects counted these numbers. Current measures of productivity included lines
of
code (steps) produced per man-month, number of documents per man-month,
total
development costs
per
1000
documentation per 1000 lines of code.*^'
appeared
1978,
to
machine
lines,
According
experience major improvements
in
time,
to these
and
pages
of
measures, Numazu
productivity between 1975 and
corresponding to new procedures for project management and control
introduced, and somewhat less dramatic but
the mid-1980s,
following
development efforts
In
addition
emphasis,
dating
to
at
new
in
significant improvements during
quality control
and centralization of
Numazu.
apparent
back
efforts
still
to
rises
the early
in
quality
1970s,
29
on
and
productivity,
Fujitsu's
product and project control
Fujitsu
gradually led to significant progress
came
in
late in
in
scheduling accuracy.
the early days of programming, with "late" defined as reaching
the Inspection Department after the scheduled time.
half of the 1970s, about 40% of projects typically fell
early 1980s, however,
to Hitachi.
Most projects
Numazu had reduced
this to
Most delays that remained came
in
Even during the
behind schedule.
about 15%,
latter
By the
comparable
a level
the transition from functional
design to coding, phases that continued to be difficult to estimate accurately,
due
and product requirements."^"
to variations in people
APPLICATIONS-SOFTWARE DEVELOPMENT
Systems Enaineering Group
Fujitsu's decision to create a large organization for custom
programming,
stemmed from the same need SDC, Hitachi, Toshiba, and NEC encountered
produce
in
their applications areas:
to
more efficiently-- that
with improved levels of productivity, project control,
and quality.
In
is,
a
variety of nominally different programs
the early 1960s, Fujitsu customers performed most of their own
programming, with assistance from
a
the Computer Division
Several
in
1963.
Service Department Fujitsu set up within
large orders
for on-line
securities, and data-processing systems to the creation of a Systems
in
banking,
Department
1964, the forerunner of the Systems Engineering Group, which built programs
for and with customers (Table 7.7).
Continued increases
demand
in sales of
Fujitsu's 230 series computers
for customized applications software, prompting
the Information Processing System Laboratory
The Laboratory,
with
an
initial
staff
of
in
700,
brought more
management
to establish
Kamata, Tokyo, during 1970.
allowed
Fujitsu
to
centralize
training operations as well as customized programming for business, engineering,
30
Fujitsu
and
The M-series computers, however, brought more new
scientific applications.
orders for programs that were themselves growing
prompting management to organize
included
that
1970s
a
Software
a
in
and complexity,
size
Systems Engineering Group
Factory
as
well
the later
in
numerous
as
software
subsidiaries and subcontractors. ^
As
of 1988, the
(Figure
The Common
7.4):
Engineering)
Systems Engineering Group consisted
Technical
Department and
Technology Area
Support Center,
included
SE
the
(System
which housed the Software Factory
1500 programmers as well
its
of three major areas
as
other sections such as for
information support (product information for customers), technology transfer,
office systems engineering,
and the SIGMA project; the Applications Software
Planning Division, which dealt mainly with packages; and
a
research institute.
Industry-related departments performed system engineering for companies
in
finance, insurance, securities, and manufacturing and distribution, as well as for
NTT,
scientific
and technical applications, and government users.
The
third
area consisted of functionally specialized departments, such as for management
systems,
information
"value-added networks" for different on-line services,
personal-computer systems, and new telecommunication firms (NCCs).
Evolution of the Factory Strategy and Structure
Several
factory
was
among managers
initially for
to
reasons
lay
behind the decision
1979 and to structure the facility
a desire
work,
was
in
specific
separate
construction
and
in
to
create
a
the manner Fujitsu did.
First,
to increase the level of centralization of similar
program conversion and then for new development.
high-level
then,
software
third,
design
take
(system
advantage
engineering)
of
progress
from
in
the
Second
product
field
of
software engineering by standardizing work around good methods and tools for
31
Fujitsu
^
all
Fourth was
projects.
a
desire to improve Fujitsu's technical and managerial
infrastructure for controlling large, complex projects, especially those involving
amounts of subcontracting,
large
which
coordination and control to meet budgets,
The
intention was to build a
overall
more programmers and managers
more formal
required
of
schedules, and quality objectives.
permanent organization that would allow
to benefit
from knowledge accumulating within
Fujitsu regarding development tools and methods, standardization,
environments, and product designs.
methods
programming
Managers expected their concept
factory approach to bring improvements
in
productivity,
of the
project management,
quality control, and software reuse.
Fujitsu experienced both successes and disappointments with
Management experimented with
Conversion
Software
personnel.
on
the
Factory
a
organization
centralized
Department
with
1977,
in
its
approach.
by setting up
approximately
a
TOO
This modified the huge number of programs customers wanted to run
new M-series machines,
which
were
not
compatible
with
Fujitsu's
previous architectures, as well as converted IBM and other software to run on
Fujitsu
hardware.
Management believed that conversion
work was
fairly
straightforward and that centralization of personnel and equipment, as well as
methodological
standardization,
result in higher productivity.
after he
would make the tasks easier to manage and
The
idea
worked
well
enough so that Mitsugi,
became head of the System Engineering Group, decided
operations of the factory to include program construction.
to
expand the
He then added
another 200 personnel and charged them with turning requirements specifications
received from system engineers into code.
Fujitsu had
managed
integrated projects,
with no
Prior to this,
system engineering and program construction
in
separation of these two functions.
Mitsugi
admitted,
however,
that
32
his
"original
factory
idea,
due
to
Fujitsu
inexperience, went too far."
many
Much
like
SDC
experienced, managers found that
depended on close interactions with customers and knowledge
projects
Or writing the
very different requirements.
of
applications program sometimes
required access to specialized or proprietary information that some customers,
worked
for security reasons, preferred not to give Fujitsu personnel unless they
own
at the customers'
to
There were other occasions where Fujitsu needed
sites.
provide programming services locally at various locations around Japan, again
departing from
the
and
tools
centralized factory model.
a
reuse
data
bases
programmers became better able
As
a
result of
available
addition, as Fujitsu improved
In
the
in
factory,
less-experienced
to build complete systems.
recognizing that different projects had different optimal
processes for project management,
divided or apportioned work.
Fujitsu
made several changes
One change was
to
how
in
expand the scope
of
it
the
factory departments to do more detailed design for some projects and eventually
to
do
system
unnecessary
design,
to
again,
for
separate functions,
some
projects
either for
where
move was
to
encourage system engineers, who
difficult
or
reasons or because
logistical
factory departments had the necessary expertise to build
strategic
was
it
a
Another
system.
initially
did surveys and
project planning, system design, and program structural design, not merely to
let
factory teams do more of the product construction,
but to leverage their
expertise more widely by writing software packages that would cover
user needs.
Packages that teams could use
the need to write
of
a lot of
code from scratch.
programming more widely,
establish or
range of
custom programs thus eliminated
In addition,
management
in
to
the
spread the burden
1980s
decided
to
work with many more software subsidiaries and software houses
around Japan, as
Table
Fujitsu
in
a
well as sell or lease methodologies
and
tools to
customers (see
7.7).'^'^
33
Fujitsu
The methods and
software factories,
used
tools
in
Fujitsu's factory,
were also continually evolving
software technology and customer needs.
Fujitsu
received
in
other Japanese
in
response to changes
in
An important stimulus were orders
the mid-1980s from Japanese banks for on-line software
To manage these projects,
systems requiring several million lines of code.
Fujitsu
in
like
embarked on another
effort to
upgrade
tools
and techniques for project
control, design notation and support, automatic programming, testing support,
and quality assurance.
techniques
in
Facilities),
replacing
1987 as
Fujitsu
packaged and began leasing these
tools
and
SDAS (Systems Development Architecture and Support
SDSS (Software Development Support System) and SDEM
(Software Development Engineering Methodology), the original factory standards
adopted
in
1977-1978 and leased to customers since 1980.
Process Standardization
SDEM
extending
consisted
from
of
standardized
requirements
development
definition
and
system
to
maintenance
and
management. ^-^ The System Engineering Group had guidelines prior
management defined them vaguely and weakly enforced them.
very much
in
a
"craft" mode, with
procedures
control
project
to 1977,
but
Development was
programs more the property
of individuals
than the product of an organization. Documentation and standardization were so
lacking that, as the engineers
difficult to
who developed SDEM and SDSS
recalled,
it
was
understand programs other personnel wrote:
We had software development standards before SDEM and SDSS were
developed
but
the
development phases.
freedom
that
standards
had
no
clear
This lack of definition
software
systems
34
often
definition
resulted
became the
in
the
of
so
much
products
of
Fujitsu
individuals.
program
to
It
was not easy for
understand how
we concluded that
a
person who had not designed
To improve on
worked.
it
a
this situation,
reasonable definitions of the developing
clear,
The kinds
phases and activities were required.
of tasks
performed
during each activity also needed standardization.^
A software-engineering team
problem
considered
two options
improvement and standardization
that
established
Fujitsu
structure
to
of
the
1976 to
in
study this
development
process:
procedures, techniques, and other elements
made up the programming environment; and automatic program generation,
relying on standardized formats for specifying user requirements and "state-of-
Due
the-art" tools.
to the
still-emerging state of program generation,
they
decided to begin with introducing standards and take up program generation
Before looking more deeply into automation, the team also realized they
later.
had to establish
a
formal methodology:
There are two approaches
to
to software engineering.
One approach
is
upgrade current development methods by standardizing development
procedures and by improving both programming techniques and the
development environment.
In
the other
programs are
approach,
directly generated using formal specifications of user requirements,
and
this
automatic
approach
involves
the
The
programming.
application
latter
program generator or
approach
is
one
accomplishing our ultimate goal of software engineering,
narrow the applied
very
field
this
approach
is
feasible.
if
we apply them generally.
35
.
.
.
and
However,
difficult to realize these latter technologies at the
of the art,
way
if
it
of
we
is
present state
Therefore, we addressed the
Fujitsu
following items based on the evolutionary approach: 1) clarification of
software development methods and standardization for development
activities,
2)
utilization
of
tools
to
computerize
development
activities.
We developed SDEM around the
developed SDSS as
design.
.
.
.
Our
more desirable
For the second, we
first item.
support the phases after system
a set of tools to
basic attitude toward software development
to first clarify
is
that
it is
software development methods and
a
software development system, then to approach these problems and
solutions rationally and systematically, depending heavily on feedback
from the actual system developers. ^^
After studying current practices
four manuals that set down the
software engineering, the team wrote
in
SDEM methodology.
outlined basic standards and the overall
Standards Reference Card
listed
The SDEM Concept Manual
The SDEM
development approach.
specific procedures
development phase and project-team member.
and work items for each
The Detailed SDEM Standards
Manual presented more details of each work item and related documents, with
examples.
The SDEM Introduction and Application Manual explained basic
management techniques and guidelines
for
introducing
and using the SDEM
The development process SDEM defined divided the
system.
cycle into 6
life
stages and 12 specific phases, from survey and planning through maintenance
and evaluation.
steps,
as
These included
displayed
modifications,
in
a
series of
Figure 7.6.
The
work categories and
initial
thus covered software products,
SDEM
standards,
work
and later
development technology, and
management, including procedures for modularization as
36
specific
well as construction of
Fujitsu
packages and reusable design patterns (paradigms)
standards for coding (primarily
specified methods and
how
in
COBOL
For programming,
.
and FORTRAN).
SDEM
to write documentation.
SDEM
set
For design,
it
also provided review
guidelines and checklists, testing procedures, and standards for estimating times
for project
management, although
it
should be noted that management tailored
standards, methods, and tools, and performance expectations, to accommodate
programs
of different types
Just as
and
sizes.
SDEM resembled procedures
set
down
in
manuals
at
other Japanese
and U.S. firms, Fujitsu's engineering team cited benefits of process standards
noted earlier at Hitachi,
would
make
possible
it
Toshiba,
even
to
and NEC:
out
the
They believed standardization
quality
products,
of
facilitate
maintenance, reduce the dependency of the development process on individual
experience, ease tool introduction, and simplify management control. ^^
Fujitsu appeared to experience these benefits,
to facilitate the
another objective of
While
SDEM was
separation of system design from program design as well as
improve the "flexibility" (portability or reusability)
of designs.
As noted earlier,
dividing labor proved more problematic than managers at first realized, although
standardized techniques,
in
combination with management objectives and
support, seemed to enhance design portability and reuse significantly.
also claimed that use of
SDEM and factory-support
tools in
misunderstandings and errors that normally occurred
System designs consisted
in
of exterior specifications
all
tool
Managers
phases minimized
software development.
and
logical
designs that
did not rely on specific machines (computers) or languages, whereas program
designs consisted of the physical program, which was machine and language
dependent. ^^
created
a
risk
Developing system designs separately from the actual program
that
the entire
implementation
effort
finished program did not meet customer requirements.
37
might be wasted
if
a
But while Fujitsu clearly
Fujitsu
encountered problems of this sort, managers found two solutions:
One was
to
promote extensive interaction between system engineers and programmers
in
determining the accuracy and meaning of design documents.
to
expand the
activities of factory personnel
Another was
program construction,
into design,
testing, and maintenance.
Process and Work- Flow Management
Since unique knowledge was often essential for accurate system design,
Fujitsu initially established specialized system-engineering departments outside
the software factory focusing on manufacturing, distribution, financial systems,
government systems,
and
scientific
departments generally handed designs
which
factory,
built
about
20% of
and
to
engineering
programming sections
new applications done
Engineering Group as well as handled about 75% of
to subsidiaries
and
affiliated software
work organized, consisting
manage projects,
all
The SE
programs.
in
in
the software
the
System
program conversion, or
houses, which built most of the remaining
of approximately 800 small
projects per year.
To
Fujitsu designated both a chief system engineer and a chief
programmer, and gave system engineers the main responsibility for dealing with
customers and delivering systems that correctly met customer specifications.'*'
Because system engineers were responsible for code they did not write or
test
at
all
levels
themselves,
program development required cooperation and
trust among project members, as well as standardization practices.
however,
Fujitsu's original approach
system construction
to
-- did not
--
dividing
work smoothly
in
all
all
system development from
cases, prompting managers
change the way they organized product development,
projects.
As noted,
at
least
for
Figure 7.7 describes how Fujitsu expanded these patterns
in
some
the
software factory between 1979 and 1988.
38
Fujitsu
Under the
first pattern, factory
personnel, organized into teams of
programmers, performed module design, coding, and testing for
or 8
system
4 or 5
The system engineers took charge
engineers outside the factory.
7
of planning,
system design, program-structure design, and integration and system testing.
The standard process required them
format
using
conversational
to write design specifications in a particular
language
(Japanese
and
mainly),
provide
to
input/output diagrams and mathematical equations, as necessary, to minimize the
amount
of
required
skill
programmers who did not understand part
finished a part of a system, they would send
who would check
it
with
at the
back
customer
In
the
system engineers,
and programmers then
System engineers
site.
then might perform operation tests with customers.
assistance
call
When programmers
to the
Designers
the customer.
conducted system tests together
it
encouraged
design document to
of a
system engineer and discuss the problem.
responsible
field
Managers
personnel.
factory
the
of
in
the
Fujitsu provided some
maintenance as well, although generally took care of this on their
own. 48
Most projects
medium
size,
the
first
few years of the factory were of small
running from 10,000 to
consuming from
well
in
a
a
few hundred thousand
lines of
to
code and
few months to one year. Where requirements were relatively
understood, dividing labor on these projects worked relatively smoothly.
As programs grew
million lines of
in
complexity,
newness,
and
size,
frequently to about
code and up to years for completion, Fujitsu instituted
pattern around 1982.
a
1
second
This required the project teams within the factory to
complete more work -- system design, program structure design, and integration
and system
As
test,
factory
as well as
module design, coding, and testing.
personnel
became more adept
particularly with the support of a
series
39
of
at
system
computer-aided
development,
tools,
managers
Fujitsu
adopted
a
third pattern circa 1985.
and test complete systems
build,
This called for factory personnel to design,
--
including the
"survey" (customer
initial
consultation) and project planning, as well as operational test, evaluation, and
Some
maintenance.
of
these projects consisted of new banking and value-
added-tax calculation systems that regularly exceeded
million
a
lines of
code
and lasted two or three years. ^^
Another issue for managers
in
the System Engineering Group when they
made project assignments was where
To some extent,
subsidiaries or software houses.
decision.
If
departments
all
in
work elsewhere.
However,
management
to
tried
well
methods were appropriate.
work
in
into the factory that
the
Fujitsu
and
factory
that
this
the factory or to
to
was
a
simple capacity
have some guidelines.
did
as careful
were particularly
--
the factory were busy, management had to send
give the factory big
computer support, as
procedures,
send work
to
projects
where extensive
standardization of methods,
important,
general,
In
and where the factory
or
tool
tools,
and
tools
and
This latter point meant that managers tended to put
was large-scale and similar
could
take
advantage
to
of
previous projects done
existing
development
technology.
Especially for large projects,
called
the "on-line
work on
a
a single
SDEM
station for
This allowed up to
a
thousand people
(The Kamata factory maintained about one terminal or
every 1.5 employees, more than twice the
Some projects done
in
the factory might use as
many
ratio at
as
6
that
ran
development.
off
these mainframes
Toshiba.)
mainframes and
involve a thousand personnel over a period of one or two years.
tools
to
project simultaneously, with 200 to 300 terminals connected to
single mainframe.
work
system.
1984 Fujitsu introduced what management
in
Dedicated
and data bases also simplified product
For products that required special experience
40
in
the application
Fujitsu
even
do coding, such as
to
scientific, space,
and nuclear-plant software, system
engineers generally built the entire programs themselves, without handing off
specifications to the Software Factory.
These types
accounted for 10% to 20% of the orders
Another guideline was
try
to
subsidiary or software house.
worked on
in
a
programs
the System Engineering Group. ^^
in
give
to
of specialized
"one-time"
small
projects
to
a
As noted, these companies, which generally
long-term basis with Fujitsu, provided 1300 of the 1500 personnel
the Software Factory as well as manpower for additional projects.
They
allowed Fujitsu to accommodate different types of work as well as meet demand
peaks without adding too many full-time (and higher paid) employees to the
ranks of
its
permanent work force, although another reason for using outside
personnel originally was
shortage of new recruits.
a
used software houses as sources of personnel
that were
projects
Fujitsu
running
As
late.
managers claimed they were able
to
Fujitsu also sometimes
help
in
coding for large
at
other Japanese software factories,
to
add people without delaying projects
further because of the standardized methods and tools, and training, even of
subcontractors' personnel.
Training and Career Paths
While
most
employees
in
Kamata
the
Software
graduates, and usually had good backgrounds
Hitachi,
Toshiba,
engineering or
heavily
in
and
NEC,
as
in
^^
While
other
cases,
programmers and system engineers how
to
this
required
Fujitsu
41
computer
to
to
invest
teach
use methods, procedures, and tools
System Engineering Group.
began some general education with the establishment
•
no
management was able
certified as standards in the Software Factory or the
Fujitsu
were college
science or mathematics, as at
new employees generally had
software training.
training,
in
Factory
of the
Kamata
Fujitsu
Laboratory
in
1970, though
it
was several years before management determined
standards for applications development and coordinated these with training.
One landmark was the introduction
Fujitsu followed these with periodic
1977.
a
of seminars to teach the
customers.
As an example
in
addition to courses for
and breakdown
of the scale
in
workshops for project managers and
new employees,
lengthier education program for
SDEM standards
of training,
Fujitsu
in
1987 offered courses on computers and software education to over 89,000 people.
The
largest group, approximately 57,000, were employees of Fujitsu's customers.
Of the remaining, 12,000 were Fujitsu employees, 13,000 workers from systemengineering
subsidiaries
or
and 4,000 workers from dealers and
affiliates,
software houses.
Like the other Japanese firms discussed,
Assembler,
coordinated
New employees were
education program with career paths.
entire first
Fujitsu
its
trainees for their
year and attended full-time classes for three months,
COBOL, machine
1/0,
and other areas
of basic
formal
learning
programming and
computer architectures. After the classes, training continued on-the-job through
coding simple programs for commercial customized systems and through another
2 or 3
days of additional instruction every month or two.
managers, employees continued to receive about 8 days
workshops,
in
(Figure 7.5).
system design,
addition
to
self-study
materials
Until they
of training a
became
year
in
and quality-circle activities
This education included topics such as writing and speaking,
project management,
contracts and
law,
network design and
requirements analysis, and product-specific information.
New employees
usually did coding for 2 or 3 years and then moved on to
module design and structural design.
project management,
personnel, from
1
as
to 5,
at
Hitachi,
For education planning, rather than for
Fujitsu
also assigned
skill-level
ranks to
based on self-evaluations as well as some testing with
42
Fujitsu
courses.
After about 3 years of work, depending on an individual's ability,
programmer might become
and support.
a
a
system engineer or move into project management
management and support functions included revising
Project
standard times, carrying out quality assurance measures, proposing means for
quality and productivity improvement, or developing and evaluating
new
tools
and methods.
Fujitsu also granted the rank of senior systems engineer to employees with
from 9 to 13 years experience, depending on whether they were high school or
college graduates.
to factory
These engineers specialized
in
application areas,
programmers (although managers tended
projects similar to what they had done
in
to assign
system engineers as well as ability to provide service
Fujitsu also established the Fujitsu Research Institute for
Systems and Economics.
70
experienced
programmers
To improve
the past).
to
contrast
in
its
to
training of
customers,
in
1986
Advanced Information
This facility, staffed with 30 experienced managers and
system
engineers,
consultation while assisting customers
trained
Fujitsu
personnel
in
system
system planning and problem solving. ^^
in
Quality Control
SDEM procedures
although
the
System
for quality control
Engineering
Management was very slow
were
similar to those used at
Group allowed projects more autonomy.
to separate quality control
from project management
and established an independent inspection department only
primarily to check work done at subcontractors.
formal
process
providing
that
seemed
feedback on
effective
analyzed
Numazu,
data
for
to
1987,
Nonetheless,
checking
designers,
managers, and staff responsible for work standards.
in
work
in
Kamata had
progress
programmers,
The factory,
and then
like
and
project
Numazu,
was also automating more aspects of quality control, such as by devising
43
a
tools
Fujitsu
^
to
check programs against specified coding or design rules, and collect various
quality data for later analysis.
Another difference from Numazu was that, rather than having management
set quality objectives, projects
This
statements."
was common
for
application-s
Fujitsu also required project
Toshiba.
problems.
members
customers to
to negotiate with
"maximum allowable number
--
determine quality targets
managers tended
to
errors per 1000
of
programming,
seen
as
at
propose solutions to quality
early tests indicated bug levels were above target, the developers
If
had to validate the target levels and then describe the countermeasures they
planned
to
use.
For
example,
decrease
to
"building-in"
common
bugs,
countermeasures were to improve standardization controls, reuse program parts
or paradigm designs, generate more code automatically, or make greater use of
data
dictionaries.
To increase "bug detection," projects
on
relied
design
reviews, source code checks, test-coverage tools, and verification tools.
Computer- Aided Tools
Fujitsu was distinctive for extensive investment
support
in
tools for
all
phases of product development but especially automating aspects of program
design and coding and supporting the reuse of designs and code
library routines and registered packages, which served as
semi-customized systems.
was the main
locus
of
in
the form of
program parts for
Kamata, primarily the SE Technical Support Center,
this
although
research,
Fujitsu's
central
research
laboratories also provided assistance and Kamata sometimes imported tools from
Numazu
(as
Numazu sometimes did from Kamata).
Kamata's
first
effort
at
producing
(Software Development Support System)
mechanized
aspects
of
documentation
in
an
integrated
the late 1970s.
compilation,
44
tool
file
set
was
SDSS
This automated or
editing,
and project
Fujitsu
management,
relying
on
designs, test data, documentation;
a
FORTRAN
for
library
project
a
source programs,
module description language and analyzer
containing information such as the name and module function, interfaces with
and syntax; and test-support
other modules,
for module test,
tools
results
analysis, module path tracing, and test-case selection. Although Fujitsu gradually
supplanted SDSS, the
One
languages
COBOL.
it
of
tool
established general objectives for future research.
was
the first tasks
other
than
to
FORTRAN,
Another challenge was
build
since
to
a
system
like
most business
SDSS
that
applications
handled
were
in
improve the module description language so
could describe more complicated data structures and support the beginning of
Other objectives for long-
program design, rather than module definition only.
term
tool
research were to develop program-generation and reuse support, as
well as systems to generate
maintenance documents from source code."*^
Fujitsu accomplished these goals and more.
were the combination
of
YAC
Particularly important tools
flow-charts and YPS,
developed
in
the System
Engineering Group (and imported by Numazu), to facilitate program design,
editing, code generation, and reuse;
from Numazu, which served as
data base; and
operated as
a
ADAMS, one
GEM,
also described earlier
and imported
program library system and production-control
a
of the a series tools Fujitsu called
"SIMPLE" that
project-development data base with an interface to other tools,
the project library, and management data bases. ^^
The management data base
kept track of individual personnel and projects, primarily
in
the form of man-
hours expended per phase or operation, as well as monitored in-house personnel
costs versus those charged to outside contractors.
ADAMS,
first
introduced
through maintenance,
COBOL
in
initially
or the macro-based
of
1982,
provided support from detailed design
programs written
HYPER COBOL.
45
in
a
Functional
Japanese version of
menus
in
Japanese
Fujitsu
need for specialized
the
eliminated
programming commands.
ADAMS' most
important functions were information retrieval, data-base environment definition,
program construction, program
utility
and
utilization,
historical version
Information retrieval referred to the storing of design documentation
control.
in
test,
the form of tables or flow charts that could be retrieved for modification or
reuse.
to
COBOL
Japanese-language
Fujitsu's
first version of
employ Japanese characters, rather than the representation
From 1987,
new applications projects
all
including YACII and YPS,
tools,
SDEM methodology but
the
integrated
new-program development under SDAS,
EPGII
(Executive Planning Guide
Procedures
the
SDEM
II)
to define the
effort
of the tools
management systems,
of
SDAS (Systems
to rely on
developed after 1980.
and C-NAPii (Customer-Needs Analysis
II)
and
the
simplify
These
tools
specification
came out of
and design
EPGII formalized
a set
and work sheets for designing corporate information-
mapping out
a
management systems already existing
another series
set of
a
for example, system engineers used
process, although computer-aided support was minimal.
of planning procedures
COBOL
katakana.^^
SDAS continued
customer requirements.
standardize
to
referred to as
Facilities).
many
in
the factory utilized
in
that Fujitsu
Development Architecture and Support
In
was also the
procedures
customer's
the
in
and work
needs
against
company.
sheet
to
information-
C-NAPII
define
set
forth
more formally the
specifications necessary to write software.^'
Noritoshi
Group,
Murakami,
manager
in
the
Software
Development
Planning
presented an overview of automatic programming that helped placed
Fujitsu's efforts in tool
In this interpretation,
that
a
development within
"classical automatic
turned computer code
"modern" technology
--
into
a
broader spectrum (Figure 7.10).
programming" consisted
machine-readable object
represented by YPS
46
in
of compilers
languages.
The
Fujitsu as well as similar systems
Fujitsu
NEC, Toshiba, and NTT
in Hitachi,
step
program design
from
--
focused on automating the transformation
specification
machine-readable
to
These
code.
"program design specification compilers" read structured designs or diagrams
(PAD
SPD
at Hitachi,
COBOL, FORTRAN,
further back
NEC, and HCP
at
NTT) and generated code more or
(module interfaces might have to be written manually), usually
less automatically
in
at
Two
or C.
the development
in
additional
cycle,
life
system planning and design phases.
steps were to move automation
to
automate part or
Tools such as
all
in
(and
Fujitsu
"partially automatic transformation tool."
a
many other
in
firms)
were
tools
that
At the
tried
to
fell
R&D
the
CAD
Software
Fujitsu's
attempted this through transformation rules defined by the user, and
the category of
of
into
level
automate the
transformation process through Al techniques.
Automated design-support and
experts and non-experts.
their tools would
of
creative work."
in
served two groups:
engineers from the tedious and cumbersome job
'free software
and turn their talent
This would occur because programmers
no
to
more
longer had to
computer languages but could focus on business problems and write
programs "more finely attuned
other hand,
develop
tools
Fujitsu developers, on the one hand, maintained that
run-of-the-mill computer programs
writing
compose
programming
Fujitsu
their
own
to the
requirements of the end-user."
designed the SDAS tools
application
software
to
On the
"enable computer users to
without
the
help
of
expert
programmers. "^° While other firms provided similar capabilities, Fujitsu offered
what seemed
programming
to
be the broadest
tools in the
PARADIGM,
range
of
design-support
and
automated
Japanese software industry.
issued around
1980 for in-house
use and sold since 1981,
supported module design, coding, and testing, as well as software reuse and
program maintenance for two main
types
47
of
applications
software:
batch
Fujitsu
The
processing and transactions processing.
tool relied
on the same concept as
NEC's STEPS library routines and Hitachi's EAGLE patterns.
were available
PARADIGM
the form of complete functions or
in
The
smaller modules.
in
library stored both specifications (program structure, detailed flow
charts, and module function designs, stored
as executable code.
a
Standard patterns
Users of the
tool
would
the form of flow charts) as well
in
first access the specifications
terminal and use the standard patterns to write up
that could be used unchanged, the
design.
a
from
For portions
programmer would access the code library.
Changed designs would be recompiled automatically.
The
functional
stored patterns or program parts
tool
in
a
library according to a
such as "input-out check," that made
name,
it
parts easily and reuse designs across different products.
could create new program parts,
design
specifications
COBOL, using
paradigm's
library
The
software.
(program outlines,
data
library
base,
also
In
users
addition,
consisting either of fully coded modules or
module functions,
structured design methodology,
a
possible to access
causing
contained
it
to
utility
YAC
charts)
in
and then register them
in
grow with each new piece
of
programs for use on multiple
operating systems, referred to as "black box" components. To assist managers,
paradigm and
similar
tools
tracked
how many
lines
programmers reused, and thus supported reuse planning
(although
Fujitsu
did
not
include
budgets or incorporate them
A study
Fujitsu
in
published
reuse objectives
1982
in
Fujitsu
code
the design phase
project schedules and
estimated that,
in
80% of business-
PARADIGM, personnel generated about
source code without new coding.
applications
source
design reviews, as Toshiba did.)^^
applications programs developed with
of the
in
in
of
68%
Since about two-thirds of business-
programs seemed redundant and suitable for reuse technology,
managers
decided
to
invest
•
48
more
heavily
in
integrated
tool
and
Fujitsu
methodology sets
reuse both of source code and design patterns
to facilitate
across different products,
mainly
in
COBOL, where
the logic was
relatively
simple. ^0
ACS PARADIGM
PARADIGM
(Application Control Support System) was a refinement of
for developing on-line systems through modifiable logic tables.
primary objective of the
tool
was
processing structure for input data.
users more functions on
the
simplify
to
design
of
The major improvements were
preset screens as well
describe input/output logic for new applications
as
in
generator read the program logic and then produced
allow
more
COBOL
and the
to offer
flexibility
to
A program
outline form.
work sheets and existing input/output routines.
design
files
The
code from tabular
In
addition,
ACS
generated code from preset designs (indexed by names) for specific applications,
with blank slots to be filled
into the
in
as desired, that users designated for insertion
program. ACS stored the logic tables and subroutines
to facilitate reuse as well as testing
Programming sections
in
in a
parts library
and maintenance.^'
the Software Factory as well as some subsidiaries,
software houses, and customers of Fujitsu hardware used
a similar tool,
(Banking Application Generator Library for Extensive Support),
to
BAGLES
produce the
longer, more complex software needed to control automated teller machines or
to
move funds among different bank
locations
through on-line transfers."'^ The
large size, frequency of demand, and similarities
software led Fujitsu to develop
1980.
a
in
functions for this type of
dedicated support tool for this industry
in
Fujitsu introduced a prototype in 1981 and then versions for in-house use
and commercial leasing.
BAGLES resembled
with a prescribed design format
automatic
COBOL
(Figure 7.11).
in
Hitachi's
Japanese,
a
EAGLE and NEC's SEA-I,
design-document data base,
generation, and support for testing and project management
The
original tool, available only on large computers, contained 2
49
Fujitsu
million
of
lines
code and
required
10
giga-bytes of mass
15
to
storage to
generate programs that covered from 500 to 1400 terminals and from 50,000 to
150,000 transactions per hour.
BAGLES
in
offered simplified logic-design representations
Japanese, few coding errors,
a simplified
tabular form and
in
program-control structure, reusable
program patterns or subroutines for common banking operations and functions,
automatic generation of documentation
The
management control.
to define data
program,
COBOL
types and procedures, specify modules and the logic flow of the
BAGLES
This meant that
code.
in
almost as
much
users had to be skilled
simplify the software-development process further,
in
programming
in
the
knowledge
little
time
experts
also
ran
BAGLES/CAD
Fujitsu introduced
1984, through which, according to both in-house personnel
customers, users with
half
writing
as
detail
banking applications.
BAGLES/CAD
in
original version, however, required users of the tool
and determine other elements
as well as
To
Japanese, and support for testing and
in
on
using
of
just
and
programming could develop programs
COBOL would
normally
require.
computers or work stations attached
personal
to
larger computers and data bases, and provided graphics capabilities as well as
"windows"
that
representations of
of
allowed
a
program
users
in
expand
to
or
contract
order to view the whole system (or
as well as focus on the structure of individual modules.
It)
graphical
the
a
large part
The improved
format, including revised decision tables, helped users define banking operations
and integrate packaged subsystems and reusable patterns with new designs.
with
the
original
executable as
A
COBOL
similar
supported
BAGLES,
tool,
all
the
graphical
design
representations
As
were
code.
CASET (Computer-Aided
development of
relatively
simple
50
Software
business
Engineering
applications
Tool),
programs
Fujitsu
written
COBOL,
in
information
lists,
consisting largely of relational data-base subsystems and
such as for inventory or sales control.
specifications in Japanese, the tool produced a
coded the designs, while
facilitated testing
a
After the user defined
program design and automatically
debugging support subsystem and document generator
and maintenance."^
Advanced Design-Support Tools
PARADIGM, ACS-APG, CASET, and BAGLES were
applications
described
decision
in
new applications required
tools
or menu-driven
tables
libraries of patterns or subroutines.
design
To automate development
sheets and
of software for
extending beyond pre-existing designs, library
routines, menus, tables, or development methods.
experimental,
useful for well-defined
was the most advanced
tool
Software CAD, though
type used
of this
still
Fujitsu as of
in
1988-1988.^
Engineers described Software
CAD
as
"a
general tool for the drawing,
verification, and transformation activities of software development.
of
any particular methods or development phases.
tool
that
developers
can
customize to
fit
.
.
.
Software
particular
.
CAD
independent
is
it
into
1987, initially for writing segments of business applications programs.
were gradually extending
its
a
general
methods for their own
Fujitsu completed a version and introduced
circumstances."
.
Kamata
in
Projects
use to other areas, such as to develop operating
systems, switching systems, communication software, and "firm-ware" (micro-
code embedded
in
semiconductor chips).
The 1987 version
of
Software
CAD
used
generalize-purpose
notations
combining text, tables, and diagrams, as well as an editor and compilers that
transformed standardized notations into modifiable design documents and then
different types of code.
The
notation system contained six types of objects for
51
Fujitsu
describing program structures:
forms (graphic models of the program), tables,
nodes (graphic symbols specifying particular attributes of the program), edges
representing
(symbols
connections
between
nodes),
(symbols
inclusions
representing relationships between nodes and edges), and text fields (inputs of
The NS (Notation
data into any of the objects).
by program developers
written
specifications
which the
editor for modification,
the
in
specified
These became inputs
produced machine-readable notations.
CAD
Specification) Compiler took
deposited
tool
in
format
to the
and
Software
the Software
CAD
Document Database when finished.
The Software CAD Editor
allowed
Database and modify any of the objects,
"mouse"
Transformer
stored
and
interface
in
on
relied
a
user
the
relying on
a
The Software CAD
the user specified to transform the documents
The
notation system, according to Fujitsu, was relatively easy to
learn, requiring a few hours for an experienced
new employee.
Fujitsu
templates as well as
"multi-window environment."
rules
Document
the
the database into either executable code or textual documentation
(Figure 7.12).
a
access
to
claimed
programmer and
a
few days for
Describing the transformation rules was not simple, although
that
programs developed with Software
CAD
still
came out
faster than comparable systems done manually. °^
Ongoing
R&D
in
techniques with Software
approach
attempted
Fujitsu
was to use Al
CAD and
apply Al
techniques
to
integrate
to
a
process
made
"knowledge transformation" algorithm.
in
processing the documentation,
subsequent phase
--
a
tool
a
design
a
documents
Fujitsu's
using
a
model of the desired design,
For example, based on inferences
would produce documents for
planning inputs would produce
which would be processed into
intelligence
other support tools.
in
"knowledge data base" for specific applications,
and
artificial
a
a
detailed system design,
program design, which would be transformed
52
Fujitsu
(compiled)
into source code.
Fujitsu engineers
were especially interested
in
applications to requirement specification and lexical (design-language) editors,
since Al appeared useful to help designers understand constraints
in
hardware,
the operating system, the computer language, or specific applications, and to
One Lisp-based expert system was
verify designs.
available
in
prototype form to
help inexperienced personnel consult with customers and produce customized
systems for
methods
a
variety of applications. °"
to identifying software
Fujitsu also applied inference-search
components for reuse, and was studying testing
support and maintenance applications, such as problem diagnosis.
In
the telecommunications area,
switching-systems development
Language) Support System.
late
writing
1970s,
in
a
employing Al became available for
tool
SDL
1984, the
in
(Specification and Description
Fujitsu Laboratories began working on this in the
SDL resembled NEC's SDMS and contained
UtiLisp.
graphic symbols to represent different states, tasks, or signal input and output;
graphics as well as text editors;
compilation
a
document data base; automatic document
and inspection subsystems;
functions or tasks performed
in a
a
"knowledge data base" of different
switching system; and subsystems to translate
the graphically represuented requirements into state-transition diagrams and then
This was an "intelligent system"
these into executable code.
it
withdrew
information
information
in
a
data base
diagram elements.
from
in
the
graphical
and
designs
the sense that
in
deposited
this
the form of general and detailed state-transition
Subsystems
used
then
inference
rules
to
produce
I/O
transformations automatically and generate computer code."'
Architectural Standardization and Package Utilization
SIA or Systems Integration Architecture, which Fujitsu announced
along
with
the
SDAS
tool
set,
aimed
53
at
creating
a
standard
in
1
interface
Fujitsu
programming
SDAS
tools
in
COBOL, FORTRAN,
expected
Management
The
it
also
interface was not complete
be available for
to
viewed
SIA
the
all
machines
architecture
as
production strategy, since SIA was expected to ma-ke
programs
using the different
and applications packages on Fujitsu mainframes, office computers,
and work stations (Figure 7.8).
Fujitsu
PROLOG and
C, LISP, or
a
few
years.
complementary
to
easier to break up large
°°
Increasing package use, especially across different machines, was
objective at Fujitsu, even
and well-established
at
new
effort
a
such as Toshiba:
Reusing software
in
key
a
The reasons were
custom programming."^
firms
development represented
of
in
its
programmers could develop on different work
into distinct units that
stations and then combine later.
it
within
1989 but
in
clear
custom
reuse of know-how that usually reduced the amount
required for product development.
The exception was when
A
developers had to change too much of the designs or code they reused.
major challenge was thus to produce packages that could
systems
fit
,
or build them so that
it
was relatively easy
individual user needs or changes
Fujitsu
pursued were
to
in
technology.
fit
as
into larger
is
to tailor the software to
Some technical avenues
promote reuse of designs as well as program more
and use object-oriented design.
design, and some coding,
in
in
C
Organizationally, management also kept package
the specialized system-engineering departments, to
take advantage of specific application-related or functional expertise.
The
Fujitsu
group
use of existing software.
totalling
about 1000
in
two package registration systems
relied on
The
packages,
increasing 40% to 50% per year.
Another
library registered software users or computer dealers developed;
totalled about 300.''
covered user needs.
promote
Fujitsu
largest catalogued original
1986 and
to
in
1986 this
Figure 7.9 summarizes data on how well these packages
Manufacturing systems extended over the broadest range,
54
Fujitsu
with larger ones requiring total customization and some systems containing more
than 40% existing code from packages.
Fujitsu found that
meet the needs of small-system users by packages,
hospitals and
newspaper companies.
applications
packages,
government,
newspaper,
covering
and
it
could more often
such as
in
the case of
Overall, data suggested that
SDAS-based
financial,
medical
applications systems Fujitsu delivered
in
manufacturing,
distribution,
accounted
applications,
for
40% of
1988.'^
Performance Improvement
Although some of the data Fujitsu released about projects built
in
the
Software Factory was difficult to interpret and compare to other firms, the
information
available
improvements,
indicated
especially
in
productivity,
comparable to Hitachi, Toshiba, and NEC, as well as other firms using similar
methods and
revising the
gain
in
tools.
For example,
SDEM standards
in
a
1981
article,
a
team that worked on
claimed their introduction brought roughly
a
20%
productivity (delivered lines of code per month, normalized to 170-hour
months) over projects not using the methodology.
These gains came mainly
from the "absence of rework," achieved through better work scheduling, early
discovery of problems, standardization of work and documentation, and use of
formal planning and reviews to reduce differences between user requirements
and
finished
programs.'^
development continuing,
With
Fujitsu
doubled from 1980 to 1984,
annually, due to
(1)
Equipment
a
--
in
managers
place
and
later
asserted
tool
and
methodology
that
productivity
and rose during 1984-1988 between 5% and 15%
combination of factors:
investment
in
and other computer-center
(2)
SDEM
more time-sharing terminals, work stations,
facilities
Specialization -- accumulation of
in
the Software Factory.
programming and development know-how
55
Fujitsu
by system engineers, groups
(3)
in
the Software Factory and software houses.
Standardization -- introduction and enforcement of standards for program
documentation as well as for the development process and linked support
tools.
(4)
Tools -- greater application of computer-aided tools for supporting testing
and design, including reuse support.
(5)
Reviews
-- formalization of
development of automated
(6)
Project
Management
review procedures and checklists, as well as
tools to assist in
-- introduction of
code reviews.
productivity standards and revision
of the quality-control process, including use of quality objectives
and data
collection. '^
Among these elements,
after
Fujitsu data suggested that most productivity gains
came from computer-aided
1985
tools
such
as
PARADIGM and
reuse
technology, including the integration of packages into customized systems.
reason was the reduction
in
man-hours required
in
One
new program development
through recycling of designs, code, and documentation, and minimization of
debugging for reused components.
similar tools
Second, Fujitsu claimed that
PARADIGM and
"enabled even inexperienced programmers to write high-quality
programs" and "eliminated misunderstandings due to individual differences" by
making design documents and code easier
highly structured methodology.'^
The
to
result
read and maintain,
due
to the
was that managers could deploy
their skilled engineers more effectively.
paradigm's exact impact on productivity varied with the
application, the
phase of development, and the number of times that application appeared.
from
1982
showed that use
of
PARADIGM tended
to
cut
in
half
Data
the time
required for program design as well as basic programming activities (coding,
compiling,
and debugging).
Time spent
56
in
other aspects of integrated and
Fujitsu
remained similar.
including test preparations,
system test,
projects using
PARADIGM experienced
Overall,
Fujitsu
doubling of productivity, compared to
a
comparable projects done manually, with more time or man-hours shifted from
design and coding to testing.
up
to 80% of design
man-power by generating
Projects also saved on
documents from standard
YAC
patterns. "
Fujitsu reported similar quality improvements with
average rate of approximately 10 errors per 1000
module tests, programs written with the
and
between
1
tool
PARADIGM.
lines
averaged
2
in
code detected
Most of the
PARADIGM components but
the
in
or 3 per 1000 lines and
for particularly repetitive applications.
introduced, furthermore, were not
of
From an
erro--'
in
newly
written additions.''
Using
ACS
to
develop
a
small-scale conversational-mode data entry system
of approximately 10,000 lines of
term decline
in
productivity
COBOL
source code, Fujitsu reported
a
short-
order to write reusable code but significant
in
improvement over expected standard times, minus the defined paradigms, as
as a larger gain
when producing
one project, users of the ACS
versus 587
tool.
lines
program
a similar
tool
averaged 1219
for the
ACS
the future (Table 7.8).
lines of
In
code per man-month
COBOL programs done
per man-month for similar
The numbers
in
well
without the
project excluded 12 man-months required to
write 1817 lines of code contained modules that became part of the reusable
ACS PARADIGM
for the
ACS
of the
If
added, this work dropped the net-productivity rate
project to 495 -- below the factory standard.
similar project,
some
library.
which consisted of converting and extending
ACS PARADIGM
a
a
larger but
program using
patterns and modules, productivity was 1864 lines
per man-month, and the project was able
from designs, 42% of the source
PARADIGM
In
reuse, or automatically generate
This limited data suggested that
lines.
could reduce time required
to
in
57
all
phases of development,
if
ACS
designs
Fujitsu
'°
were reusable.
COBOL
lines of
million
that
BAGLES (and BAGLES/CAD)
using
In
development
a
COBOL.
in
programs
of
2
to 3
source code, Fujitsu's experience as of 1987 indicated
brought
the tool
for banking
25%
reduction
in
man hours compared
BAGLES achieved
program
by cutting time
primarily
this
to
required for programming (program design, coding, and debugging) through the
use of
in
a
highly structured design format.
There was, however,
a slight
time allocated to system design, compared to programs developed
BAGLES/CAD, on the other hand,
in
increase
COBOL.
drastically reduced design time through the
use of graphics and windows and the reuse of design patterns, and, compared to
COBOL,
7. 9).
cut total development time for similar programs to less than half (Table
79
The combination
least in
of
SDAS
and packages again doubled productivity,
tools
one major case when, for
a
banking customer, Fujitsu replaced an old
software system consisting of 3.6 million lines of code.
covered 30% of the old
system and man-months
Thus, the original system had
system was 8000.
450 lines of code per man-month.
than twice as large
79% of
the
--
Existing packages had
required
a
for
the
complete
gross productivity rate of
The more sophisticated replacement was more
8.3 million lines of code.
code from
at
SDAS packages
for
But Fujitsu was able
securities
processing,
control, cost accounting, international transactions, foreign
to obtain
customer
exchange dealings,
regional information control, and a general data base, as well as for the outside
network, store operations, accounting, and general operations. For the other
21% that employees
generate code.
had to develop anew,
they
used
The resulting gross productivity was 902
YPS and BAGLES
lines of
to
code per man-
month (Table 7.10 and Figure l.U).^^
The length
of the
second system suggests that reusing so much code,
58
Fujitsu
designs, or packaged subsystems might result
lengthy programs
--
high nominal productivity but
in
perhaps longer than necessary.
It
was clear that reuse
aided nominal productivity (see Appendix B), although writing unnecessarily long
programs exaggerated productivity.
system
While
it
in
example appeared
this
was not possible for
While this was possible, the new Fujitsu
offer a
to
much wider range
functions.
of
author to examine and interpret the code,
this
Fujitsu also claimed that reuse did not necessarily add to a program's length.
Another
even asserted that reusing efficient modules, aided by design-
article
support tools, could reduce length.
BAGLES
For example, programs built with
tended to be shorter than software performing similar functions written without
the tool -- as much as l/14th the size.
Fujitsu maintained this was because, in
developing BAGLES, engineers identified
a
large
that could be handled through subroutines,
cite these repeatedly in the
the
and
of repetitious functions
later users of the tool could
program without rewriting the code.°'
On the other hand, along
limits to
number
with Toshiba and Hitachi,
Fujitsu encountered
the benefits of reusing designs and code, depending on how much of
component or subsystem programmers had
development, Fujitsu projects indicated
given piece of software:
impact on overall
negative. °*^
improvement
If
a
to
applications
a
employees had to rewrite more than 60%, then the
productivity of
productivity
In
"break-even" point of about 60% for
reusing the designs or code was slightly
More detailed data from Numazu was
in
modify.
as
long
as
personnel
showing
similar,
reused
a
clear
70% to 80% of a
particular module or program part without significant changes:
In a
sample of
47 projects, median productivity, including man-power devoted to maintenance,
was approximately 60% higher with 20% new code and an 80% reuse
projects
where there were attempts
to
reuse code
but
less
than
rate.
In
70% was
reusable without significant changes, the impact on productivity tended to be
59
Fujitsu
negative. ^*^
Software
recycling
design
only for
tool
CAD
Software
of
appeared
to
improve
code or designs,
existing
transformation
present
CAD
a
but
specifications
few tasks,
productivity
through
results
in
total
manpower from
Programmers
limited
used the
Fujitsu
were impressive.
using
a
Software
standard
9.3
CAD were
normal 6 months to
a
man-months
able
to
to 0.5
to
man-months) usually required for
in
1
month,
man-months.
0.5
transform
structure diagram into programming language (ADL)
man-months
trials
the
cut the time needed to develop a tool to convert a set of job-
control diagrams to job-control language from
and
While
necessarily
automating
partially
code.
into
without
database logic
a
one-sixth the time (8.4
Other efforts
similar jobs.
showed comparable improvements, usually cutting development time one-fourth
or one-third from expected levels, with even larger gross productivity gains,
compared
to conventional design
and programming (Table 7.11).°^
SUMMARY AND EVALUATION
Fujitsu's approach to software development, as
closely
resembled
those
at
Hitachi,
exceptions and different emphases.
on
and
intermingling
establishment of
applications
a
of
process
centralized
NEC,
and
summarized
Toshiba,
quality
laboratory
in
support tools for custom programming,
control
1970
programming; extensive investment
in
and
products.
to sell
Table 7.12,
some minor
early focus
its
basic
in
then
a
software;
factory
for
an assortment of design-
some dedicated
applications and for non-specialized users; and investment
packages not so much
with
Most notable at Fujitsu were
and
in
to
specific
in
industry
building software
but more to integrate into customized applications
Fujitsu also created the largest network
60
in
Japan
of subsidiaries,
Fujitsu
much
as Hitachi
and NEC did, but on
NEC,
larger scale than Hitachi or
of the
manpower
for
its
of
in
eliminating the need to
permanent programming
Another characteristic of Fujitsu was
and adaptability,
a
Fujitsu used software houses to provide most
applications software factory,
numbers
find and hire large
Furthermore, again on
larger scale.
a
a
staff.
healthy combination of continuity
strategy, technology, and organization
Hardware engineers
.
stayed too long with telephone relay circuits but then switched to transistors
when these became the obvious technology
to
Management pursued
use.
foreign source of technology, decided to develop computers independently
it
its
could not find
a
good partner, and sought
key designer.
software,
In
like
SDC,
a
a
when
partner again after the death of
Fujitsu experienced some difficulty
separating system design from product construction
in
the software factory.
Rather than abandoning the goals of centralization and rationalization, however,
management adopted different processes for different projects, bringing more
design operations into the factory where appropriate, and continuing to invest
heavily
in
standardized tools, methods, reuse libraries, and training of in-house
personnel and employees from subsidiaries, subcontractors, and customers.
What the concept
of a
software factory meant
Fujitsu's context thus
in
varied by the type of product, as at other Japanese firms, as well as over time.
Both Numazu and Kamata pursued centralization of personnel, standardization of
practices and tools,
formal
improvement
in
product
management controls and objectives such
Kamata pursued
a
formal
division
labor
of
and productivity, and
reliability
as
reusability.
separating
design
But only
from product
construction, and then gradually relaxed this policy.
In
sum, though somewhat
business
resources
of
establishing
late in
software
entering the computer industry and the
factories,
and management attention
61
it
Fujitsu
needed
to
clearly
develop
allocated
the
system
for
a
Fujitsu
producing
programs
to
support
its
computer products.
Fujitsu's position, since the late 1960s, as Japan's largest
and related products and services, as
broad competence across
a
well
as
its
The outcome was
producer
of
computers
continual demonstration of
range of hardware and software markets.
62
Fujitsu
FUJITSU OPERATING GROUPS n986)
Figure 7.1:
Group
Comments
Computer Systems
(Mainframe and Minicomputer Hardware
and Software, Factory Automation)
Printed-Circuit Board Products
(Office
Equipment
Computers,
Work
and
Personal
Stations,
Terminals,
Printers,
Facsimile
Software)
Information Equipment
(Disk
Drives,
Machines, Other Peripherals)
Transmission Systems
Switching Systems
Telecommunications Systems
Semiconductors
Electronic Devices
Electronic Devices Exports
(Large-Scale
Systems Engineering
Custom Applications,
Applications Packages)
(Hardware Maintenance)
Field Service Engineering
Systems Sales
Office Automation Sales
NTT
Sales
Source: Nikkei Computer
.
13
October 1986, pp.
63
70,
79.
Fujitsu
Figure 7.2:
FUJITSU PRODUCTIVITY IMPROVEMENT STRATFGIFS
Development Technology
Specialization
Mechanization/Automation
Common Development
Organizational
Structure
Software Tools and other
Computer-Aided Systems
for Planning, Development,
Testing, Maintenance
Modularization
High-Level Languages
Reuse
Review Procedures
Subsidiaries
Structured Design
Structured Programming
Software
Packages
Support and Control Technology
Project
Management
Standardization
Development Planning and Phase
Completion Reporting System
Quality Control Activities
(High-Reliability Program)
Management Objectives
Training
Source: "Software Kaihatsu," p.
4.
64
Fujitsu
a
o
•H
U
CO
to
a
CO
00
u
o
u
o*
a
0)
.
>
-3
-•
0)
U.
M
CO
O
CO
n
V
Z
'J
-J
w
V
O
en
C
<0
M
3
00
•rl
4
a.
<-»
5
3
Cr
Figure 7.4:
SYSTEMS ENGINEERING GROUP ORGANIZATION
COMMON TECHNOLOGY DIVISIONS
—
SE Technical Support Center
-- Software Factory Department
-- Information Support Center Department
-- Technology Transfer Department
-- System Engineering Support Services Department
-- Office Computer Systems Support Service Department
--
SIGMA
Project Systems Promotion Office
Application Software Planning Division
-- Application Software Planning Department
-- Software Distribution Department
—
Fujitsu Research Institute for Advanced Information Systems and
Economics
INDUSTRY-RELATED DEPARTMENTS
—
—
—
—
—
---
Finance
Insurance/Securities
Manufacturing/Distribution
Scientific/Technical
NTT
Government/Mass -Communication
FUNCTIONAL DEPARTMENTS
— Management
—
VAN (Value-Added
—
Network
—
Computer
— NCC (New Common
Information Systems Division
Network) Systems Engineering Division
Systems Engineering Division
Systems Engineering Division
Carriers) Systems Engineering Division
Information
Personal
SYSTEM ENGINEERING SUBSIDIARIES
—
—
Industry and Functional
Regional
Source: Murakami Correspondence, received 12/26/88.
Nikkei Computer 13 October 1986, p. 79.
Original
version
in
.
66
Fujitsu
Figure 7.5:
SYSTEM ENGINEERING GROUP TRAINING AND CAREFR PATHS
Education
Assignment to Factory Divisions
Department
Yearl
New Entrant
Education
Training
Content
»»
Training
Divisions
in
>>>>
Project Work
Introduction
»»
«
s
u
Q
cn
O
c
o3
vO
<u
M
3
00
I
in
00
Figure 7.8:
Systems Develo pment Architecture a nd Support
Facilities (SPAS)
SDAS: Systems Development Architecture and Support
Facilities
Systams Planning Technique
Corporal* System* Planning Technlqut
Systems Requirement Analyst* Technique
(EPG
(C-NAP
II)
Planning/
Operational
Application Tool
II)
Industry Application Package
Departmental
(examples)
Application Tool
...4
:aset
.
YPS
.
3AGLES
.
APPS/XI
-
Pnarcs
•
yanu'ac:ur -g POCFiT APCOi
,N*EFIAC'
oAp/BAse
'Barn. ACE.
OiSinoulion
;SM/6PCC
•
='l3:iC
ASTE^ ClSCLEl
SeCXf 'ARiS. ESTIMAI
iC3 APG
\ewsoaoef PRESS- F PPE33. Ci
AOAMS'SiMPl-S
N'eaicai
Tool Work Standard
iHCPE lamOAi,
91c
Package Work Standard
SIA (Systems Integration Architecture)
Source:
Electronics New from Fujitsu
,
July 1987, p.
1
Figure 7.9:
Package Coverage Ratio
DistributioTT"-
Newspaper
Finance \ ''1
V
Coverage
Ratio (%)
Insurance
System Size (million lines of code)
Source:
Fig.
1,
SDAS special issue, p. 37
c
U
00
o
u
to
s
o
4-1
3
<
3
•t-i
>
1-1
01
>
o
01
3
00
BAGLES PROCESS-FLOW OUTLINE
Figure 7.11:
NJz^
Japanese- Language
Japanese-Language Displays
Time-Sharing Terminals or
D
E
S
Graphical Dictionary
Code, Table,
Work Stations
Module Definitions
I
G
(23 types)
Design Data Base
N
3Z
Design Documents
S"
2:
Editor
\^
<
{Design Specifications
Design Review
>
^k.
P
R
Automatic
COBOL Programminq
O
D
-^COBOL
Compiler
Program )?
COBOL ^^ Load
Modules
j
U
7K
C
T
Black Box
(Packages, Subroutines)
I
O
N
-N^:
.
Testing Tool
(Japanese- Language
^Conversational Mode)
T
E
S
T
^
Z-
cTest
Data
Schedule, Q ualityV
Data
Documenter
±.
Test
Execution
Report
\i
Management
Data
Report
Source: Tsubuhari, p. 228.
^
Functional
Additions
&
Changes
:^
|Specifications|i
Inspection
^
Test Review
>
Figure 7.12:
Software CAD
^^
Cavalopar
Text
source codes, etc.
Softuara CAO Editor
Machlna
Raadab la
For«
Transformer
Software CAO
Oocuoent Database
Transforaatlon Rule
Notation Specification
Tool Developer
Source:
Yabuta et al.
0)
o
o
ij-i
o
9
0)
ap
c
o
o
o
o
o
m
CO
0)
-
\
,
u
3 o
\
o\T-i
3\i-N
u\v
•H
U
U V^O
-J5
Vq/V 3s
U
\
to
\
-
-Ji
JJ
iJ
O. C
uV-i
^
O
cn
M
U3
<U
C
•H
hJ
o
o
o
O
o
H
H
U
D
Q
O
Pi
EU
O
O
V
\
en
m
en
-o
0)
d
CJ
CO
00
cn
5
a)
05
•N
c
o
o
o
o
o
z
6
0)
00
3 o
01
0)
(0
a,
\
03
-&-
D
o
u
c
o
4-1
CO
CO
c
o
^ u
S ^ j:
o o
O 3 C
C
-I
O
U
01
Z
CO
)-i
CQ
3
3
•H
tn
J-i
4-1
C!
c
3
O
u
y
4J
CO
M
OJ
&
O
9)
U
3
o
Table 7.1:
FUJITSU SOFTWARE SUBSIDIARIES AND EMPLOYEES f1987)
Software Area
System Engineering
Basic Software
Communications
Microprocessors and
Personal Computers
TOTAL
Companies
Table 7.2: FUJITSU
BASIC-SOFTWARE PACKAGES.
1962-19ft4
1960
ALGOL
1961
ASSEMBLER compiler
FORTRAN compiler
1963
Data communications software
1965
FORTRAN IV compiler
MOP (control program for the FACOM 230-20/30 mainframes)
MONITOR II (proto-operating system for the FACOM 230-50)
1966
KEMPF
1968
MONITOR V (large-scale mainframe
STAT (statistical package)
1969
BOS (medium-size mainframe batch operating system)
ROS (medium-size mainframe real-time processing operating system)
compiler
(econometrics modeling and analysis system)
operating system)
PL/I compiler
EPOCS (medium-size mainframe data control program)
ADSL (continuous simulation system)
1970
RAPID
1971
MONITOR V TSS
(data base system)
(time-sharing function added to
MONITOR V)
BOS II (successor to BOS and ROS operating systems)
OS II (operating system for FACOM 230-45/S and /55 mainframes
ASTRA
1972
UMOS
TIMS
1973
(structural analysis program)
(mini-computer operating system)
(time series analysis program)
MDS (management decision-making support
MPS (mathematical planning
1974
tool)
tool)
BOS/VS and OS ll/VS (medium-size operating systems
with
virtual
memory
control function)
MONITOR VI/VII (large-scale mainframe operating system)
1975
OS IV/F4 (operating system for largest M-series mainframe)
FEM (finite element analysis program)
1977
AIM (on-line data base system)
FNA (Fujitsu Network Architecture)
OS IV/X8 (medium-size operating system for FACOM M series)
OS IV/F2 (small-size operating system for FACOM M series)
PDL/PDA (performance measurement and analysis tool)
1978
OS/UAS (mini-computer
operating system)
FAIRS-I (information retrieval system)
KING (Japanese-language line printer support program)
77
Fujitsu
1979
JEF (Japanese-processing Extended Feature)
INTERACT (end-user support system)
FAIRS-II (management information search system)
FDMS (document control system)
GEM (library control program)
SSOPTRAN (FORTRAN source program optimizer)
1980
FORTRAN?? compiler
AOF (computer center
operations support tool)
ARIS (resident information system)
HOPE
1981
(hospital administration system)
OS IV/F2 ESP (small-scale operating system
ICAD (computer design support system)
for
FACOM
M-series)
HYPER COBOL (high-productivity version of COBOL)
DOCK/FORTRAN?? (FORTRAN debugger for system displays)
ANALYST (statistical data processing package)
PLANNER (planning and control information system)
AXEL (conversational language data analysis system)
1982
OS IV/F4 MSP (large-scale operating system
AIM/RDB (relational data base system)
DRESSY/P (simplified graphics system)
ADAMS
1983
M-series)
(Application Development and Management System)
FOS (Fujitsu Office System Concept)
OS IV/X8 FSP (medium-size operating system
UNICUS (minicomputer operating system)
JEF
FACOM
for
FACOM
for
M-series)
(Japanese-processing Extended Feature II)
(information analysis and search system)
processing system)
ELF (electronic file system)
II
MACCS/REACCS
ODM (documents
1984
OS IV/ESP III (small-scale operating system
IMPRESS (image information system)
for
FACOM
M-series)
IPS (small-scale printing control system)
Ill/PS (personal computer network system)
FCAD-11 (personal computer CAD system)
ATLAS (automatic language translation system)
UPLINK
Source:
"FACOM
no ayumi"
(FACOM development), FACOM
janaru. Vol. 11, No.
Kabushiki Kaisha, "FACOM seine
FACOM performance) in Ikeda kinen robun shu
(Anthology of articles in memory of Ikeda), Tokyo, 1978, pp. 254-267.
(1985), pp. 20-47;
ichiran" (Overview of
1
and
Fujitsu
78
Fujitsu
Table 7.3:
CHRONOLOGY OF BASIC SOFTWARE PROCESS DEVEI OPMENT
1966
Programming (Software Engineering) Department established.
1968
Program Testing Section established.
1970
"Strengthen Inspection" effort begun (1970-1973), extending testing from
debugging to evaluating software from the user's perspective, such as
comparing performance to specifications stated in manuals.
1971
Product Registration System established, requiring new
software to undergo inspection and receive product numbers before
being released. Product Handling Regulations formalized procedures for
Required all product
software products, manuals, and documentation.
components to be brought in simultaneously, not one-by-one, to the
inspection department for testing and evaluation.
1972
Planning Section established.
1973
Preliminary version of Development Planning and Report System.
Software
.
"Application of QC Techniques" effort begun
forecasting and then eliminating bugs.
MTS
1974
(1973-1978),
aimed at
(Multi-Terminal Simulator) tool developed for testing.
Software Division established.
Involved
"Product and Process Standardization" effort for begun.
estimating what the phases would be for the life cycle of individual
software products, and then determining what to design in a given
period of time, as well as what programming techniques to use.
Bar charts instituted for project control, replacing PERT charts.
Inspection procedures and forms standardized (Main Factor Analysis).
HTS (Hardware Trouble
1975
Simulator) tool developed for testing.
Phase divisions formalized and
launched.
BSMS
SWN (Software Normen) Standards
effort
(Basic Software Project Management Support System) started.
Procedures for bug analysis and data gathering formalized."
Accumulation" effort formally begun.
QC
Data
Estimates Handbook drawn up, with actual data on past projects to aid
in estimating project requirements.
managers
1976
Software Administration Department established.
BSMS
data base started for project control and estimation.
79
Fujitsu
Current Development Planning and Report System instituted, software
product delivery procedures formalized, and BSMS required for inhouse use.
1977
"Inspection of Quality and Evaluation Indicators" (1977-1978) begun.
1978
Structured design and programming emphasized.
1979
"Consolidation of Inspection Ideology." Concept of software inspection
formally promoted as extending beyond testing, to evaluation of final
products and the development process.
"Quality Assurance through Organization" effort launched. Formalization
QA as an organizational function not restricted to inspection
but extending to design and planning.
of
Phase Completion Reporting System instituted.
1980
Development Planning and Report System (Version No.
adding productivity data and review data reporting.
Campaign
to increase quality three-fold
2)
instituted,
and productivity 30% by 1982.
Software Division actively promotes small-group activities as part of the
company-wide High-Reliability Program.
Software Division Quality Objectives established -- formalization
procedures for establishing project estimates and standard times.
of
"Diffusion of Inspection ideology through Horizontal Development."
Effort to spread knowledge and "good practices' horizontally, i.e.
beyond one's own department.
1981
1982
"Advancement
of Quality Concepts" movement begun, including ease of
use evaluations (ESP) and QAL (Quality Assurance Liaison) initiated to
facilitate inter-departmental sharing of data on bugs.
"Performance checking" begun directed by Inspection Department.
Quality Objectives control
Subcommittee established.
1983
1984
system
instituted
and
Software
Quality
Six program development departments established at
located in new software building.
Numazu Works and
New Software
in
Division centralizes
all
basic software
Numazu Works.
Software Division extends quality assurance and quality circle activities
as part of the second company-wide High-
to software subcontractors,
Reliability Program.
Source: Fujitsu Ltd., Quality Assurance Department, "Kensa-bu no rekishi"
(History of the Inspection Department), undated internal Fujitsu memo.
80
Fujitsu
Table 7.4:
C
T
Key:
X
DEVELOPMENT PLANNING ITEMS AND RESPONSIBILITIFS
= Control, P = Planning, E = Engineering,
= Integration Testing,
= Inspection, o =
= Major Responsibility
I
D = Development,
included in Activities,
Groups Responsible
Check Points
QUALITY OBJECTIVES:
Program positioning,
Development
Items
Objectives
for
Checking
C
P
E
D
Ji
o
X
o
o
o o
X
o
development results,
marketability
Desired
Functions
User needs and
program functionality
Performance
Objectives, measures,
comparative analyses,
appropriateness of the
X
XX
measurements
Compatibility
Reliability
Objectives, appropriateness and completeness
of the objectives
X
o
Appropriateness of the
o
o
objectives,
o
o
X
o
X
likelihood
of implementation
PLANNING IMPLEMENTATION
Development
Size, Language
Appropriateness of
size given functions,
modularization/ reuse
Development
Appropriateness of
Process
delivery time to user,
o o
X
XX
X
o
feasibility
Man-Power
Machine Time
Review & Test
Plans
Work Objectives
Match of productivity
and budget, man-power
allocations, subcontracting percentage, progress
X
Amount
of reviews & test,
appropriateness of bug
detection (compared to
phase standards)
Sufficiency of measures
X
X
o
for improving quality
and efficiency
Development
Organization, work
Structure
distribution
Source: Morita and Kanda, p. 91
o o
Table 7.5:
MAJOR SYSTEMS SOFTWARE DEVELOPMENT TOOLS
(19831
DESIGN
YAC
Detailed design
(new version 1987) (Yet Another Control Chart).
II
language, combining aspects of conventional flow charts and pseudo code.
PROGRAM EDITING/CODE GENERATION
(1979) (Generalized Program Editing and Management Facilities).
Automatically maintains a development history of a program. Linked to PRISM.
GEM
PRISM (1982) (Problem and Repair interrelated System Management Extended).
Maintains a data base of the program source and automatically tracks
Linked to GEM.
maintenance changes.
COMPACT
(1982) (Compact Print-out Utility).
and assembled code.
TOOL
2
Compacts and prints out compiled
(1983) Allows on-line search, from time-sharing terminals, of
source code and
program
lists.
Allowed the user to edit YACII
code
in several languages.
diagrams and then automatically generated
YPS
(YACII
(1987)
Programming System).
TESTING
SAT/ART
Testing).
(1980) (Systematic and Automatic Testing/Automatic Regression
Automated regression testing tool for operating system development.
TDQS
(1977) (Test Tool for DQS).
display operations.
INDS (1983)
of
NCP
.
(Interactive
Automated regression testing
NCP Debugging System)
.
Allows checking and analysis
test results from time-sharing terminals.
MTS
(1971, 1977)
host load testing.
(Multi-Terminal Simulator).
Simulates remote terminals for
TIOS (1977). (Time-Sharing System Input/Output Simulator)
terminals for host load testing.
HTS
Simulators
(1977) (Hardware Trouble Simulator).
responses.
software
of
evaluations
functional test
DOCK/FORT77
display.
tool for on-line
(1981).
Debugging system
for
FORTRAN,
.
Simulates remote
hardware bugs for
using
a
"slow video
"
PIC (1984) Program Information Control System. Allows inspection and analysis
Linked to the Kamatamemory-dump lists from time-sharing terminals.
Numazu Dump Transfer system.
of
Automatically records on computer
(1982) AIM Test Oriented System.
data base results from testing and inspection.
ATOS
82
Fujitsu
DOCUMENTATION
ODM
(1983)
(Office
Document Manager).
Document handling
system
for
Japanese language.
MANUAL COMPILATION AUTOMATION SYSTEM
(1979).
Automated editing of
electronic documentation files.
EGRET-4
(1983)
(Easy Graphic Report Generator).
ATLAS
Automatic translation of Japanese documents
(1982).
English to Japanese system added in 1986.
into
English.
MAINTENANCE
TDP
II
(1980) (Total System for Difficulties Information Processing). Data base
for software report information.
ITS (1981)
customers.
(Incident Tracking
System).
KAMATA-NUMAZU DUMP TRANSFER
reports on bugs.
(1982).
Linked to PIC testing
PDE (1983) (PTF Document Editor).
corrections, based on TDP II data.
Control
system for questions from
On-line
transfer
of
data
and
tool.
Automatically edits documents on program
CONTROL
BSMS
(1976)
(Basic Software Project Management Support System).
for software project management.
Data base
and control
tool
NOA
(Numazu Office Automation). Employment data control system.
(1978)
IN-HOUSE TRAINING DATABASE SYSTEM
(1982)
.
Relational database system for
in-house training administration.
Source: "Sofutouea kaihatsu," pp. 37, 44.
83
Fujitsu
Table 7.6:
Notes:
SYSTEMS SOFTWARE DEVELOPMENT PERFORMAN CE MFASURFS
AH data are estimates based on graphs, and therefore are approximate
figures only. 1983-1985 is based on internal Fujitsu data. Bugs/1000 LOC
refers to all bugs reported by users per 1000 lines of code over 6month periods (averaged in the table below) in the field, i.e. newly
delivered code plus supported outstanding code.
Bugs/
1000
LOC
1975
Bug
Test
Detection Method (Estimates)
Source Code
Review
Design Sheet
Review
Table 7.7:
CHRONOLOGY OF APPLICATIONS SOFTWARE PROCESS HFy FI OPMENT
1964
Establishment of Systems Department.
1970
Centralization of applications systems development
Processing System Laboratory in Kamata, Tokyo.
1976
Information
at
Establishment of Software Engineering Team within Systems Department
develop SDEM (Software Development Engineering Methodology).
to
SDEM
1977
Establishment of Software Conversion Factory and
1977
ERG (Executive Planning Guide) and C-NAP (Customer Needs Analysis
Procedure) commercialized for in-house use and
sale.
SDSS ((Software Development Support System).
1978
Introduction of
1979
Establishment of Software Factory Department
1980
SDEM standards
1981
YAC
1981
Commercialization of
reusable programs).
1982
standards.
in
Kamata.
commercialized for sale.
(Yet Another Control chart) developed for design notation.
Commercialization of
PARADIGM (methodology and
BAGLES (Banking
tool
for developing
Application Generator's Library
for Extensive Support).
1983
SIMPLE
(Logical
tool-set introduced for commercial sales, beginning with LINDA
Information Support Tool of Dataset) and DBSP (Data Base
Support Program).
1983
YACII and YPS (YAC
1983
SDT (SDEM Design Technique)
1984
On-line
1985
ACS-APG (ACS
II
Programming System) developed.
developed.
SDEM developed.
Application Program Generator) from the SIMPLE series
commercialized.
1987
DRAGON (Driver and Stub Generator for On-line and Batch Test) from
the SIMPLE series commercialized.
SDAS (Systems Development Architecture and Support
Facilities)
commercialized.
EPGII/CNAPII commercialized, adding
and data-analysis capabilities
Source: Noritoshi Murakami,
to
1977 version design concept
Personal Correspondence to Cusumano,
received
12/26/88.
85
Fujitsu
Table 7.8:
ACS PARADIGM PRODUCTIVITY EXAMPLE
Table 7.9:
COBOL. BAGLES. AND BAGLES/CAD PRODUCTIVITY COMPARISON
Design
Programming
Testing
Total
COBOL
30
42
28
100
BAGLES
35
15
25
75
BAGLES/
20
18
22
55
CAD
Source:
Tsubuhari, p. 231
87
Fujitsu
Table 7.10:
BANKING SYSTEM DEVELOPMENT PRODUCTtVITY
New System
Old System
System Length
3,600,000
LOC
Reused Code
1,080,000
LOC
New Code
2,520,000
LOC
Total Productivity
450 LOC/Man-Month
(30%)
8,300,000
LOC
6,550,000
LOC
1,750,000
LOC
902
LOC/Man-Month
Source: Fukuta Zenichi, Yoshihara Tadao, and Maruyama Takeshi,
kaihatsu shisutemu no teisho"
and Support
Facilities),
(79%)
"SDAS sogo
(SDAS Systems Development Architecture
Fujitsu. Vol. 39, No.
88
1
(January 1988), p.
11.
Fujitsu
Table 7.11:
Key:
K-LOC
MM
MH
USE OF SOFTWARE CAD FOR TOOL DEVELOPMFNT
= 1000 lines of
cod
Man-Months
= Man-Hours
mo.= month
=
Task: Tool Development
Tool for Converting
Job-Flow Diagrams to
Job-Control Language
(7.5
K-LOC
in
Software
Conventional
CAD
Development
Time
Improvement
9.3
MM/6 mo.
0.5 MM/1 mo.
6-fold
8.4
MM/6 mo.
0.5 MM/1 mo.
6-fold
2.3
MM
0.6
MM
4-fold
8.0
MM
2.0
MM
4-fold
6.0
MH
2.0
MH
3-fold
C)
Tool for Converting
Database Structure
Diagrams to ADL
(High-level Language)
(6.7
K-LOC
in
C)
Task: Program Development
Software to Convert
Screen Format to
Definition Language
(100 screens)
Software to Implement
Screen Transformation to
Programming Language
(10/screen)
Software to Implement
Database Structure
Diagram to ADL
Source: Yabuta, Yoshioka, and Murakami, p.
89
7.
Fujitsu
Table 7.12:
FUJITSU SUMMARY
CONCEPT
IMPLEMENTATION
Process Improvement
Commitment
Product-Process Focus
& Segmentation
Development sites, tools, methods, and
standards divided among basic software and
applications.
Largest network of specialized,
general, and regional subsidiaries among
Japanese computer producers.
Process/Quality
Analysis & Control
Systematic data collection, document and
product inspection and release procedures,
standardization efforts. Development Planning
and Report System, and BSMS data base from
Similar standards
mid-1970s in basic software.
Systematic
in
applications from late 1970s.
quality data collection from the late 1970s,
integrated with High-Reliability Program. Use of
Taguchi methods in testing basic software.
Tailored/Centralized
Process R&D
Tools and methods distinct to product groups,
with some transfers.
Software tool and method
development first centered in Numazu (basic
Kamata in late
software) during early 1970s.
1970s and 1980s developed methods and tools for
at division-level management in
early and mid-1970s to improve process and
quality control in basic software. Commitment
to structure and standardized custom
applications development from late 1970s and
early 1980s.
applications,
with
assistance
from
central
laboratory.
Skills
Standardization
& Leverage
2 to 3 months standard training for all software personnel. Courses and career paths to
advancement and specialization.
Development of standardized tools and methods
specifically to leverage knowledge of skilled
promote
personnel.
Division of labor in the applications
software factory between system engineering and
program construction, though gradual trend of
doing more program and system design in the
factory.
Dynamic Standardization
Performance
annually.
Continual
tools
standard times revised
evolution of standardized
methods, particularly tools.
and
Fujitsu
Systematic Reusability
In applications, emphasis on reusable designs and
packages that can be incorporated in customized
systems. Wide array of tools to support reuse,
some dedicated to specific applications like
banking. In basic software, emphasis on building
common components for different products.
Computer-Aided Tools
Extensive investment in tools during the 1980s to
the transformation of designs into
executable code or the reuse of designs and
code, such as
PARADIGM, ACS-APG, CASET,
YPS, BAGLES, and Software CAD. Other tools
available since the 1970s, such as ADAMS and
facilitate
BSMS, to support project and
management, maintenance and testing.
Incremental
Emphasis
Product
Improvement
control,
in
library
the 1970s on process and defect
as well as evaluating products from
customers' perspective (comparing performance
with documentation).
Recent emphasis in the
1980s on improving product functionality and
ease of use, with quantified measures. Computeraided tools apparently useful in channeling more
relative effort into design and less into coding.
Overall, strong product positions in basic
software, applications engineering, Japanese
language processing.
ASSESSMENT:
Strategic Management
& Integration
Long-term effort first in basic software to
improve the development process, directed by
the Inspection and Quality Assurance
Similar effort in
Department at Numazu.
applications software directed by groups in
Kamata,
currently
the
SE
Technical
Support
Company-wide and group-wide
Center.
integration and technology transfer through the
Software Development Planning Group.
Scope Economies
Building
of
unique
and
customized
systems
centralized in Numazu and Kamata, as well as in
subsidiaries and software houses working under
the direct control of Numazu and the Kamata
Specific efforts directed at
Software Factory.
building and using common tools, methods, and
software components.
Fujitsu
NOTES TO CHAPTER
7
1.
This reflects the introduction of JEF (Japanese-processing Extended Feature)
in
1979,
leader
in
which,
along with
a
successor version,
Japanese-language word processing packages.
2.
See Table 4.1.
3.
Nikkei Computer
4.
Fujitsu Limited,
5.
Fujitsu Kabushiki Kaisha, "Kaihatsu taisei:
Jigyobu"
quickly became the market
.
13
October 1986,
"Numazu
(Organizational
kojo"
p.
75.
(Numazu Works), undated brochure.
Densanki Jigyo Honbu, Sofutouea
Computer Group,
structure.
Software
Division),
Quality
Assurance
unpublished company document, 1986.
6.
Interviews
with
Tadashi
Yoshida,
General
Department, Software Division (Numazu Works)
,
Manager,
Fujitsu Limited, 7/31/86, 9/7/87,
8/22/89, and written responses to a draft of this chapter,
7.
12/8/88.
Shimoda Hirotsugu, Sofutouea ko}o (Software factories), Tokyo, Toyo Keizai
Shimposha, 1986, p. 82; interview with Katsuro Yamaji, Deputy General Manager,
Software Division, Fujitsu Ltd., 7/31/86; interview with Mamoru Mitsugi, Senior
Executive Director and General Manager, Systems Engineering Group, Fujitsu
Limited, 8/25/88.
8.
Interview
with
Hiroshi
Narafu,
Section
Manager,
Software
Factory
Department, Fujitsu Limited, 8/23/88, and written correspondence, 12/6/88.
9.
Interviews with Noritoshi Murakami, Manager, Software Development Planning
Group, Fujitsu Limited, 9/1/87, 3/22/88, and 8/23/88.
92
Fujitsu
10.
(History
shi"
FACOM
of
Iwabuchi Akio;
Fujitsu
development),
Computopia
Kabushiki Kaisha,
Nihon shashi zenshu:
history),
FACOM
Minamisawa
in
Noburo,
No.
11,
(1985),
1
konpyuta
Nihon
May
and
April
kaihatsu
Kaisha shashi
"FACOM
no ayumi"
Iwabuchi Akio,
Fujitsu
II
(FACOM
pp. 20-47.
hattatsu-shi
(History
of
development of Japanese computers), Tokyo, Nihon Keizai Shimbunsha, 1978,
12.
1975;
Nihon Shashi Zenshu Kankokai,
Fujitsu shashi. Tokyo, 1977;
ianaru. Vol.
.
Fujitsu Kabushiki
(History of Fujitsu, Ltd.), 1976, reprinted
11.
"FACOM
Major sources for the corporate history are Usui Kenji,
no chosen (Fujitsu's challenge),
Tokyo,
the
p. 145.
Yamate
Shobo, 1984, pp. 34-42, 128-129, 198-202; Ogino Yuji etal., "Fujitsu-Hitachi no
shin-konpyuta 'M shirizu' no senryaku o
kyumei"
tettei
(A close look at the
strategy of the new Fujitsu-Hitachi M-series' computers), Computopia. February
1975,
13.
p.
17-18.
Usui, Computopia.
1985, p.
May
1975, pp. 17-18; Japan Economic Journal
29
January
10.
14.
Iwabuchi, p. 93; Nikkei Computer
15.
Ogino, pp. 30-31.
16.
Narafu interview.
17.
Fujitsu, Information Processing
kaihatsu:
.
hinshitsu-seisansel kojo
productivity improvement)
,
.
October 1986,
13
Group, No.
ni tsuite
'
1
p.
81.
Software Division, "Sofutouea
(Software development: quality and
unpublished company document, received 9/24/85, p.
3.
93
Fujitsu
18.
Computerworld
November
1988,
p.
December 1988,
5
.
Businessweek
1;
pp.
19
.
The New York Times
4;
1,
"Sofutouea kaihatsu," pp. 40-41; Yoshida interviews.
20.
Nihon Keizai Shimbun
21.
This
discussion
8040
(Early systems software:
pp.
20-21,
25;
(Recollections of the
1987,
p.
9.
Kawaguchi
MONITOR
Izawa,
.
"Shoki
shisutemu
no
no kaihatsu made o chushin to shite"
focus on period through the
development), Joho shori
1975),
August
based on
is
FONTAC
sofutouea:
5
30
December 1988, pp. 100-102.
19.
,
.
FONTAC
8040
MONITOR
Vol. 24, No. 3, March 1983, pp. 225-237; Usui (May
Okamoto Akira,
MONITOR-V
"MONITOR-V shisutemu
system),
in*
Senta 10-nen-shi. pp. 224-229; Fujitsu shashi
no omoide"
Kyoto Daiqaku Ogata Kensanki
II
p.
,
Yamamoto Takuma,
104;
"Opereteingu shisutemu kaihatsu no omoide" (Recollections on operating system
development),
in
Kyoto Daigaku Ogata Keisanki Senta, ed., Kyoto Daiqaku Ogata
Kensanki Senta 10-nen-shi (A 10-year history of the Kyoto University Ogata
Computer Center), Kyoto, Kyoto University,
221-222;
Uemura Mitsuo,
software development),
in
"Sofutouea
1980, pp. 217-219; iwabuchi,
kaihatsu
no
omoide"
pp.44,
(Recollections
Kyoto Daiqaku Qqata Kensanki Senta 10-nen-shi
,
of
pp.
230-236.
22.
Ogino,
pp.
30-31;
software development),
23.
Tabata Akira,
FACOMjanaru
,
"Kihon
sofutouea
Vol. 11, No.
1
no kaihatsu"
(Basic
(1985), p. 54; Shimoda, p. 73.
Interview with Mamoru Mitsugi, Senior Executive Director, Fujitsu Limited,
8/25/88.
24.
Quoted
in
Shimoda, pp. 73-76.
94
Fujitsu
25.
This discussion
based on
is
"Sofutouea
kaihatsu,"
especially
Yoshida interviews; and Tadashi Yoshida, "Attaining Higher Quality
--
Development
Vol. 21,
26.
Evaluation
in
27.
in
7-10;
Software
Practice," Fujitsu Scientific and Technical Journal.
No. 3 (July 1985), p. 306.
Computer Group, Software Division, "Sofutouea no hinshitsu kanri"
Fujitsu,
(Software quality control), unpublished company document,
6;
pp.
and "Sofutouea kaihatsu,"
This
discussion
Association)
,
September 1985,
p.
6.
p.
based on
is
1 1
Nihon
Fujitsu no ko-shinraisei
undo
Noritsu
Kyokai
(Japan
(Fujitsu's High-Reliability
Management
Movement),
Tokyo, Nihon Noritsu Kyokai, 1985, especially pp. 144-176.
based on Yoshida, pp. 305, 308-309, 314-315.
28.
This discussion
29.
"Sofutouea kaihatsu," p. 15.
30.
Keizo
is
Tatsumi
Development Group,
Assurance Department,
(Quality
Fujitsu
"Test Case Design
Limited),
International Conference on Quality Control,
31.
used
in
Fujitsu.
Support System,"
Tokyo, October 1987, pp. 1-2.
Also, citing Taguchi's 1976 book in Japanese,
these methods
Computer Software
is
a
more detailed
article on
See Sato Shinobu and Shimokawa Haruki,
"Jikken keikau-ho o mochiita sofutouea no tesuto komoku settei-ho" (Software
test-case selection method based on experimental design methodology), Sofutouea
Seisan
ni
okeru Hinshitsu Kanri Shinpojium (Symposium on quality control
software). No. 4, ca.
in
1983.
32.
Murakami and Yoshida interviews.
33.
Fujitsu KabushikI Kaisha,
"FACOM
M-shirizu 0SIV/X8 FSP," pp. 171-173.
95
Fujitsu
"SDAS:
34.
Software Development Made Easy,"
Application
from Fujitsu. July 1987,
kanri,"
questionnaire on "Large-Scale Systems Software."
U.S.
reason
firms
1/20/87 Cusumano
to
Yoshida believed that
have not refined flow chart systems
computer language
is
close to their native language.
Japanese, making them easier for Japanese programmers
The
literature
Japanese firms,
is
on
YACII
and YPS,
IEEE Software
YACII
.
March 1989, pp. 31-37.
Fujitsu
engineers
as
in
Japan:
high-
presented
at
36.
Yoshida response to questionnaire.
37.
"Sofutouea kaihatsu," p. 29.
38.
Yoshida interviews.
39. "Fujitsu,
'
Computopja. June 1975,
pp. 102-103; Nikkei Computer
1975,
.
13
p. 92; Fujitsu
systems
available
in
at
other
English
is
Tree-Structured Charts,"
Japan's
in
in
to use.
Comments here are
Association (Joho Shori Gakkai) annual conventions
40.
in a
But, for Japanese
other
as
well
The best summary
large and growing.
Mikio Aoyama et al., "Design Specification
on
major
was not the case, and YACTl, PAD, or SPD diagrams could be written
this
35.
a
extent was
this
to
because, for native speakers of English or similar languages, writing
level
News
Yoshida interviews; and "Sofutouea no hinshitsu
p. 2;
and Yoshida's 2/8/87 written response
16;
p.
Electronics
also
based on papers
Information
Processing
1983, 1985, 1986, and 1987.
Kabushiki Kaisha shashi
II.
October 1986, p. 82; Usui, Computopia. May
pp. 25-26.
These comments that follow are based mainly on interviews with Hiroshi
Narafu, Section Manager, Software Factory Department, Fujitsu Ltd., 8/23/88,
and
his written
comments
to me,
dated 12/6/88, that reacted to
96
a
draft of this
Fujitsu
chapter;
an
Department;
interview
with
Harukazu Onishi,
and interviews with
Manager,
former programmer
a
in
Software
Factory
the factory
who
worked on distribution systems during 1981-1983, Hiromi Sakurai, 5/4/88. Mr.
Narafu has been employed
factory
in
1979.
in
the factory since 1977;
Also participating
as well as Takashi Sano,
Mr.
Onishi joined the
these sessions were Noritoshi Murakami
in
Deputy Section Manager, Software Factory Department,
and two employees from the factory, Nobuhiko Sugizaki and Yasuhiro Yuma.
41.
Mitsugi interview.
42.
Yoshiro Nakamura, Ryuzo Miyahara, and Hideshi Takeuchi, "Complementary
Approach
to
the Effective Software Development,"
Software and Applications Conference (COMPSAC78)
Electrical
Proceedings of Computer
,
New York,
and Electronics Engineers (IEEE), November 1978,
43.
Nakamura
et al.,
p.
44.
Nakamura
et al.,
pp. 235-236.
45.
Fujitsu Limited,
236.
236.
"An Introduction
System Engineering Group,
p.
to
Software Factory Dept.," July 27, 1988,
11.
46.
Murakami
47.
Narafu and Murakami interviews.
48.
Murakami interviews and "An Introduction
et al.,
p.
Institute of
pp. 284-286.
to
Software Factory Dept.," pp.
5-6.
49.
"An Introduction
to
Software Factory Dept.," pp. 5-6.
97
Fujitsu
50.
al.,
51.
These comments again are based on interviews with Narafu and Murakami
et
and Narafu's written comments.
This section
Narafu,
is
based on interviews and correspondence with Murakami,
and Sakurai;
Fujitsu
Ltd.,
"Kyoiku jigyo no gaiyo"
Education," in-house customer materials, August 1988 (this
statistics on education);
Overall
Development Process,"
in
Approach
53.
Murakami
Hajime,
.
13
to
p.
Improvement
the
Software
.
October 1986, pp. 80-81.
et a!., pp. 286-287;
Watanuki Hisashi, Hatta Makoto, and Okudaira
toki
Control for Application Program Development,
"An introduction
to
no hinshitsu kanri" (Quality
Fujitsu. Vol. 34, No. 6 (1983),
Software Factory Dept.," pp. 9-10.
54.
Murakami
55.
Noritoshi Murakami and Tomio Takahashi, responses to
et al.,
of
288;
"Apurikeshon puroguramu kaihatsu
pp. 857-865;
the source of cited
H. Hunke, ed.. Software Engineering Environments
Amsterdam, North-Holland, 1981,
Nikkei Computer
of
Noritoshi Murakami, Isao Miyanari, and Kazuo Yabuta,
"SDEM and SDSS:
52.
is
(Overview
pp. 289-293.
Cusumano surveys on
"Large-Scale Applications Software" (1/19/87) and 'Software Facilities" (9/87).
56.
Uemura Takaki, "Gekihensuru sofutouea kaihatsu sutairu" (Rapidly-changing
software-development styles), Nikkei Computer
57.
,
20 September 1982, pp. 61-64.
Nagata Yuzuru, Mori Kuniaki, and Takahashi Tomio, "Shisutemu keikaku giho
EPGII to C-NAPII" (System Planning Methodologies EPGII and NAPII), Fuiitsu.
Vol. 39,
58.
No.
1
(January 1988), pp. 13-20.
"SDAS: Application Software Development Made Easy," pp.
98
1-2.
Fujitsu
59.
"FACOM
Fujitsu Kabushiki Kaisha,
M-shirizu 0SIV/X8 FSP/' pp. 193-194;
"Sofutouea kaihatsu," p. 42; Sano and Onishi interviews.
60.
Murakami Noritoshi, Komoda Junichi, and Yabuta Kazuo, "Paradaimu
no seisansei
sofutouea
PARADIGM),
61.
Fujitsu. Vol. 33,
yoru
improvement tlirough the Use
(Productivity
kojo"
ni
of
No. 4 (1982), p. 49.
Kometani Tadatoshi and Arakawa Yoshihiro, "Onrain shisutemu no kokateki
kaihatsu
e
no tameshimi
System Development
--
ACS PARADIGM" (Approach
ACS PARADIGM),
--
for
Fujitsu, Vol. 35,
Efficient Online
No. 4 (1984), pp.
445-453.
62.
This discussion of
Fujisa Minoru,
tsuru
BAGLES),
is
based on Uemura, pp. 56-69; Wada Haruhiko,
and Yanagisawa Minoru, "Kinyu onrain shisutemu kaihatsu shien
BAGLES"
-
BAGLES
(Financial
systems
on-line
development
support
tool-
Fuiitsu. Vol. 34, No. 2 (1983), pp. 271-279; Fujitsu Financial Systems
Engineering Development Department, "Kinyu onrain shisutemu kaihatsu shien
tsuru
-
BAGLES"
(Financial
BAGLES), FACOM Janaru.
Takeshi, Wada Haruhiko,
systems
on-line
Vol.
10,
No.
12
development
pp.
(1984),
support
146-155;
tool-
Yokoyama
and Ema Michiko, "Ronri sekkei gengo BAGLES
okeru bubun-ka gijutsu" (Modularization technology
in
the
BAGLES
ni
logic design
language), Joho Shori Gakkai 'Puruguramu Sekkei-ho no Jitsuyo-ka to Hatten'
Shinpojium, April 1984, pp. 77-86; Omori Noriyuki, "Ginko onrain shisutemu no
koritsu-teki kochiku jitsurei" (An actual example of efficiently constructing an
on-line banking system). Data Management
Yukio, "Tosha no kinyu shisutemu kaihatsu
improvement
Serususha, ed.
Fujitsu
the
in
,
company's
Jitsurei
Limited,
January 1987, pp. 66-73; Tsubuhari
,
ni
financial
okeru seisansei kojo" (Productivity
systems
konpvuta bankinqu. No.
"BAGLES
kaihatsu
no
99
13, 20
keiro"
development),
in
Kindai
January 1987, pp. 226-231;
(The process
of
BAGLES
Fujitsu
development), internal Fujitsu document, 20 March 1986, and "BAGLES no gaiyo"
(Outline of
63.
BAGLES),
internal Fujitsu documents, 8
March 1987 and 3 July 1987.
Ueki Sadahiro, Miyauchi Kazuto, and Nakada Haruyoshi, "Koseisansei tsuru
CASET" (High-productivity
tool
CASET),
Fujitsu. Vol. 39, No.
1
(January 1988),
pp. 21-28.
64.
"Fujitsu Software:
Banking
Engineering Times
to Realtime," Electronic
,
11
February 1985, pp. 63-64.
65.
Kazuo Yabuta, Akihiro Yoshioka, and Noritoshi Murakami, "'Software CAD':
A Generalized Environment
COMPSAC'87
66.
pp.
.
Norio,
Fuji!
for Graphical
Software Development Techniques,"
1-8.
Ginbayashi Jun,
and
Murakami
Noritoshi,
konsarutesohn moderu kochiku tsuru" (Tool for Construction
Models),
67.
Fujitsu. Vol. 39,
"Kaiwa
of
ni
yoru
Consultation
No. 3 (1986), pp. 223-228.
Fujitsu Ltd., "System for Supporting Software Development (for Switching
Systems Software)," internal document, 1977; Murakami interviews; Kato Hideki
et al.,
"Chishiki besu o mochiita
SDL
shien shisutemu" (Intelligence-based
support system), Joho Shori Gakkai, 'Chishiki Kogaku
8
May
68.
1984,
pp.
Computer
69.
.
"SDAS:
22
Jinko chino' Shipojium,
1-8.
Matsuzaki Minoru and Yanagita Toshihiko,
Fujitsu ga kisou"
to
SDL
"SAA
to
SDAS/SIA de IBM
to
(IBM and Fujitsu compete with SAA and SDAS/SIA), Nikkei
June 1987, pp. 83-92.
Application
from Fujitsu. July 1987,
Software Development Made Easy," Electronics News
p.
3.
100
Fujitsu
70.
Akiyama Masayuki and Nishimura Shuji, "SDAS
ni
okeru pakkeji kaihatsu
sono tekiyo gijutsu" (SDAS Improving Package Development and
Needs), Fujitsu. Vol. 39, No.
to
Application
Its
January 1988, pp. 36-41.
1,
71.
Nikkei Computer
72.
Akiyama and Nishimura; and "SDAS: Application Software Development Made
13
.
October
1986-,
Easy," Electronics News from Fujitsu
pp. 81-82.
July 1987, p. 3.
.
73.
Murakami
74.
"An Introduction
75.
"FACOM
76.
Murakami Noritoshi, Komoda Junichi, and Yabuta Kazuo, "Paradaimu
sofutouea
et al.,
pp. 287-288.
to the
M-shirizu 0SIV/X8 FSP," pp.
no seisansei
PARADIGM),
Software Factory Dept.," pp. 7-8.
193-194.
(Productivity
kojo"
Improvement through the Use of
77.
"Paradigm," Facom Janaru
78.
See Kometani and Arakawa, especially pp. 452-453.
79.
Tsubuhari,
80.
Fukuta Zenichi,
kaihatsu
Support
.
Vol. 9,
No. 3 (1983), pp.
136-137.
231.
Yoshihara Tadao,
shisutemu no teisho"
Facilities),
yoru
No. 4 (1982), pp. 53-55.
Fujitsu. Vol. 33,
p.
ni
No.
1
(January 1988).
to Realtime," pp.
81.
"Fujitsu Software:
82.
Akiyama and Nishimura,
83.
Yoshida, "Sofutouea no keiryo-ka," pp. 48-51.
p.
'SDAS sogo
(SDAS Systems Development Architecture and
Fujitsu, Vol. 39,
Banking
and Maruyama Takeshi,
63-64.
38.
101
Fujitsu
84.
Yabuta, Yoshioka, and Murakami, pp. 1-7.
102
484?
Uii3
Fujitsu
Date Due
iKV
2
11993
Lib-26-67
MIT LIBRARIES DUPL
3
1
TOaO a05b73TE
3