i^^i3^ii"iry)Jf.,iy
^i'
-^
'^^''^^^T^
\w
-^ Of
Tt^l/^
AUG 181988
HD28
.M414
/Vv.
.
^DEW^y
iRie^
'hoM-Si
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
Fujitsu Software;
Process Control and Automated Customization
by
Michael Cusumano
WP 2044-88
Aug, 1988
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
Fujitsu Software:
Process Control and Automated Customization
by
Michael Cusumano
WP 2044-88
Aug, 1988
N
FUJITSU SOFTAVARE: PRO CESS CONTROL AN D AUTO MATED CU STO MIZAT IO
Contents:
Introduction
The Corporate Setting
Systems Software Development
Applications Software Development
Conclusions
INTRODUCTION
followed
Fujitsu
NEC,
Hitachi,
and
Toshiba
adopting
in
factory-type
approaches and organizations for software development, beginning with extensive
controls over project
during
early
the
management and product inspection
and mid-1970s.
systems software development
and
then
establishing
at Fujitsu's
culminated
Numazu Works
issued
a
set
in
of
Shizuoka prefecture
in
methods
standardized
of
Software Factory Department
a
centralization
the
in
programming
Fujitsu also began centralizing applications
during 1982-1983.
1970,
This
for systems software
and
Kamata, Tokyo,
before
tools
1979,
in
performed detailed design, coding, and testing for specifications done
in
in
which
system
engineering departments outside the factory.
The
company,
its
switching
and
strategy
section
first
in
of this
case discusses the background of Fujitsu as
entrance into the computer business from
electro-mechanical
place by the 1970s.
equipment,
and
a
basis
elements
of
in
the
a
telephone
software
This included product-market objectives such as
IBM-compatibility, and technical goals such as improving software development
and control
technology,
cultivating
specialized
skills
and
subsidiaries,
building tools with mechanization and automation capabilities.
sections
focus
performance
in
on
the
development experiences,
systems
and applications
1
tools,
methods,
and
The next two
products,
software divisions.
and
Systems
Fujitsu
software development resembled Hitachi and NEC, and was characterized by
a
gradual refinement and integration of manual systems and automated support
tools
for
process
product
control,
assurance and testing.
In
the applications area,
Japanese competitors, responding
extensive investment
in
packaged subsystems,
and inspection,
registration
to large
demand
program-automation
to facilitate
tools
Fujitsu
and quality
again resembled
its
programs with
for customized
and software reuse, especially
the efficient production of semi-customized
and new programs.
THE CORPORATE SETTING
Company Outline and Organization
Fujitsu
was established
in
when
1935
F'
ji
Electric,
separate company.
spun
Ltd.,
The new
off
its
telephone equipment division as
a
Japan's first digital calculator
1935 and expanded into switching systems and
in
firm developed
other electric and electro-mechanical equipment, before introducing
non-programmable computer
in
development and marketing for
a
1954.
Fujitsu
gradually
a
primitive
expanded
product
range of telecommunications equipment, office
equipment, computers and computer peripherals, and data processing services.
In
the year ending March 1987,
Fujitsu had over 50,000 employees
parent corporation, with approximately 11,000 personnel involved
operations.
billion,
total
Consolidated sales (including some 70 subsidiaries) totalled over $12
revenues), communications systems
(12°6),
and
Software accounted for
14%
by
the
software
and were divided among computers and data processing systems
components
to
in
in
1990."^
car
audio
at least
Fujitsu
and
(15°o),
other
(67''o
of
semiconductors and electronics
electronics
equipment
(S'o).
10% of these revenues, and was expected to rise
managed
these
2
areas
through
13
operating
or
Fujitsu
marketing
and
service
software development:
Two contained factory-type
groups.
facilities
one for systems software (operating systems,
for
control
programs, network software, data base systems, language processors, Japanese
language and graphics or voice processing software, and automatic translation
and another for customized applications software (Table 7.1).
programs);
Table 7.1:
FUJITSU ORGANIZATION AN D SOFTWA RE FACTORIES
Operating Groups
Software Factories
Numazu Works, Software
Computers
(mainframes, minicomputers)
Printed-Circuit Board Products
Information Equipment (peripherals)
Division
Transmission Systems
Switching Systems
Telecommunications Systems
Semiconductors
Electronic Devices
NT&T
Division
Marketing and Service Groups
Hardware Systems Sales
Office Automation Sales
Hardware Maintenance
Systems Group
Software Factory Department
Systems software was developed
which
separated
Fujitsu
from
in
the computer groups's software division,
other
divisions
for
hardware design
and
manufacturing, integrated systems development, medical systems, and factory
Both systems software and hardware manufacturing operations were
automation.
located
in
Numazu Works,
the
prefecture that
mainframes
Fujitsu
division
in
in
located
1974
in
designed
was iioused
hardware building) constructed
Fujitsu
factory
established
and minicomputers,
The software
a
a
to
to
near Mt.
produce
Fuji
tiie
compete with
separate building
in
Shizuoka
FACOM-M
series
IBM's 370 models.
(connected
to
the
1981.
management did not publicize Numazu
3
as
a
software factory.-^
Fujitsu
°
Nonetheless, centralization of most systems software development at this facility
by 1984 made
clearly
it
possible to institute
a
resembled factory-like organizations
software division
and control that
level of standardization
1987 consisted of two software engineering departments,
in
eight development departments, an inspection department, and
Of the approximately 3000 software personnel, about
Center.
graduates and the rest high-school graduates.
programming,
applications
For
Department
1977
in
the
at
Kamata, Tokyo, continuing
and
a
opened
Fujitsu
laboratory
in
and
companies.
house the Systems
to
Software
a
Factory
Laboratory
in
decade-long effort to centralize system engineering
distribution
1970
Support
were college
GO*?,
Systems
Processing
Information
Field
a
Q
programming for software required by banks,
manufacturing
The
other Japanese firms.
in
consisted of separate departments
securities
Fujitsu
Group,
had
which,
and
established
the
in
system engineering,
for
firms,
the
mid-19B0s,
software package
planning, and applications development.
The implementation
approximately
sections
programmers
1500
the
in
in
subsidiaries and subcontractors working
Software
including
1987,
full
Factory
time
in
Department
some
employees
Nearly
the factory.
had
of
all
were college graduates and performed detailed design, coding, and testing, based
on specifications received from approximately 3000 system engineers and other
staff
in
software
the Systems Group.
employed
subsidiaries
In
addition
nearly
to
these in-house employees,
11,000
programmers,
software houses added several thousand more, bringing
the Systems
Group
adding personnel
Systems Group,
to
at
about 20,000 (Table 7.2).^^
total staff
and
affiliated
resources for
As of 1986, Fujitsu was also
the rate of about 1000 college graduates per year
while
its
subsidiaries
53
were adding 1500
to
in
the
2000 people per
year. 12
Fujitsu
FUJITSU SOFTWARE SUBSIDIARIES AND EMPLOYE E S (1985-1986) 13
Table 7.2:
Com panie s
Employ ees
Maj or
34
7,000
Fujitsu
Basic Software
9
1,800
BIG
Communications
7
1,300
Fujitsu Dai-lchi
Microprocessors and
3
700
53
10,800
Software Area
System Engineering
Comp a nies
AIB
Fujitsu Micon
Personal Computers
TOTAL
Employee figures for 38 subsidiaries are based on Fujitsu data; other
figures are author estimates, based on average company size in each
category.
Note:
Entry into Computers
Fujitsu entered the
machine,
FACOM
the
hardwired,
This was
100.
electro-magnetic
using
switchboards.
computer business
not
in
dedicated accounting
a
programmable computer but was
a
relay
1954 with
adapted
switches
from
telephone
Fujitsu introduced several other relay computers before adopting
parametron circuits
in
1958,
NEC.
following the lead of Hitachi and
Fujitsu's
parametron computers also were primarily dedicated calculating machines. Again
following
computer
1961,
and
Hitachi
the new industry by establishing
firms
(RCA,
its
first
Management
for business applications.
While Hitachi,
began
Fujitsu
and introduced
1958,
in
NEC,
a
working
on
and
also signaled
computer division
General
transistor-based
programmable commercial models
Electric,
a
firm commitment to
relied heavily on U.S.
respectively)
for
hardware and much software technology, Fujitsu management tried
with
IBM.
When
this
initiative
pursue independent development.
already behind Hitachi,
failed,
management had
little
computer
to
link
up
choice
but
to
Prospects for Fujitsu seemed dim, since
NEC, and Toshiba due
5
to a
in
1963.
in
NEC, and Toshiba during the 1960s
Honeywell,
a
late switch
to
it
was
transistors
Fujitsu
and the assistance U.S. firms were providing Japanese competitors
of
new models from the U.S. largely stopped during the
RCA prepared
to
introduced
1965
in
mainframes, using transistors
230
its
series
of
due
universities,
government
to
Due
for the first time,
A
critical
was the
factor
skill of
in
to the popularity of the 230
models, Fujitsu became
SO^o of
NEC.
sales and
became
Fujitsu
in
a
graduate
of the
After
1946.
Tokyo
Institute of
designing
telephone
R&D and computer development, quickly
gaining recognition as perhaps Japan's most talented computer engineer.
1969 Ikeda also met
left
IBM
in
Gene Amdahl, who had designed IBM's 360
1970 to found the Amdahl Corporation,
mainframes. This meeting began
a
managers
for
pursuing
were concerned
Fujitsu
1972 to adopt IBM compatibility for
made
produce IBM-compatible
Amdahl was that Ikeda and other Fujitsu
could
because they were not compatible with IBM.
Fujitsu
family and then
computer development during the 1970s.
in
ties with
that
to
In
relationship with the Amdahl Corporation that
greatly strengthened Fujitsu's efforts
One reason
In
independently
Fujitsu's ability to develop computers
he moved into
of non-
1 "^
Ikeda Toshio (1923-1974),
switching equipment,
The Japanese
1968, surpassing Hitachi and
in
business.
s
who had entered
Technology
the banking industry and
in
computer revenues exceeded
the largest part of Fujitsu
its
and large
by placing restrictions on purchases
Japan's largest computer manufacturer
1970,
medium,
small,
and powerful processors.
low prices
also aided these sales
Japanese computers.
GE and
and integrated circuits (ICs) from 1968.
initially
These attracted many Japanese customers, especially
at
as
This created market opportunities.
product development efforts.
Fujitsu
later IQGOs,
and as Honeywell reduced
the computer business,
exit
But the flow
all
not
export
the
230
machines
This issue prompted Fujitsu
in
mainframes developed during the 1970s.
this decision in conjunction with Hitachi,
6
and both firms agreed
to
Fujitsu
standardize their mainframe architectures, although without jointly developing
The IBM-compatible strategy
hardware or software.
began with
thus
Hitachi
announced
M-series,
the
both
for
1974
in
and
Fujitsu
and designed
to
compete with IBM's 370 family.
To support
operating system.
Amdahl
executives
IBM declined,
After
become the majority
to
Assisted by Amdahl
assistance.
again
Fujitsu
The premature death
1972.
in
move,
this
in
Fujitsu
made
its
investor
in
Amdahl
to
given price ranges.
investment
mainframes
in
managed
and
design
seek
(LSI),
to
in
by the
Fujitsu
performance
Software Strategy:
The
forced
decision
Fujitsu
at
increase exports after the midin
the
Great Britain, based on their specifications, and selling Fujitsu
Siemens for marketing
to
in
persuaded Fujitsu
1970s by manufacturing mainframe central processing units for Amdahl
U.S. and ICL
its
developing IBM-compatible logic circuits,
deliver hardware comparable to IBM
Fujitsu also
license
to
first
of Ikeda in 1974 then
using large-scale semiconductor integration technology
mid-1970s was able
IBM
approached
to
in
in
Europe under the Siemens
label.
Products and Production
the
1960s
not
to
import
American computer technology
develop independently not only hardware designs but also
systems and applications software.
This provided
important challenges and
learning experiences for company engineers, particularly since Amdahl, with the
exception of
its
version of UNIX, did not provide softwai-e to Fujitsu. °
systems software and packages developed
listed in
between 1962 and 1984,
Fujitsu
Table 7.3, indicate that the company was able
of software,
at least after
MONITOR
Fujitsu's
at
first
Major
to
produce
a
wide range
1970.
V, completed
in
1968-1971 for the larger 230 series models, was
modern operating system.
7
Problems
in
finishing this
led
to
a
Fujitsu
revamping
structure to manage systems software development, although
of the
not until the M-series operating system
data
systematic
the type of
in
the mid-197ns did Fujitsu undertake
and integrated
collection
and methodology
tool
development that has characterized Hitachi, Toshiba, and NEC.
improve control
over
released
products,
Fujitsu
inspection and quality assurance procedures
NT&T's
software
procedures
procurement
in
did
introduce
However,
to
series
of
a
the early 1970s, initially to meet
requirements,
and
then
transferred
these
other divisions.
to
Table 7.3: FUJITSU
SYSTEMS SOFTWARE AND PACKAGES.
1962-1984^ ^
1960
ALGOL
1961
ASSEMBLER
FORTRAN compiler
1963
Data communications software
1965
FORTRAN IV
MCP (control program for the FACOM 230-20/30 mainframes
MONITOR
(proto-operating system for the FACOM 230-50)
compiler
II
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)
PL/I
(econometrics modeling and analysis system)
operating system)
(programming language version)
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 /.^f) 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 tool)
8
tool)
Fujitsu
BOS/VS and OS
1974
ll/VS (medium-size operating systems with
function)
control
memory
MONITOR VI/VII (large-scale mainframe operating system)
1975
OS IV/F4 (operating system for largest M-series mainframp)
FEM (finite element analysis program)
1977
AIM (on-line data base system)
FNA (Fujitsu Network Architecture system)
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)
virtnai
FAIRS-I (document search system)
KING (Japanese-language line printer support program)
EPG (executive planning guide)
C-NAP (customer needs analysis program)
1979
JEF (Japanese language text and information processing system)
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
FORTRAN77 (scientific- and technical-use
AOF (computer center operations support
language)
tool)
ARIS (Japanese language information system)
HOPE
SDSS
1981
(hospital administration system)
(software development support tool)
(small-scale operating system for FACOM M-series)
(computer design support system)
ICAD (computer design support system)
HYPER COBOL (high-productivity version of COBOL)
DOCK/FORTRAN77 (FORTRAN debugger for system displays)
ANALYST (statistical data processing package)
PLANNER (planning and control information system)
ESTIMA (business forecasting system)
AXEL (conversational language data analysis system)
OS IV/F2 ESP
CADAM
1982
OS IV/F4 MSP (large-scale operating system
for
FACOM
M-series)
AIM/RDB (relational data base system)
DRESSY/P (simplified graphics system)
ADAMS
(application software development system)
LIMS (books control system)
1983
FOS (Fujitsu Office System Concept)
OS IV/X8 FSP (medium-size operating system
UNICUS (minicomputer operating system)
JEF
II
for
FACOM
M-series)
(Fujitsu Japanese language processing system)
(information analysis and search system)
MACCS/REACCS
9
Fujitsu
ODM
(documents processing system)
file system)
ELF (electronic
OS IV/ESP III (small-scale operating system
IMPRESS (image information system)
1984
for
FACOM
M-series)
IPS (small-scale printing control system)
UPLINK Ill/PS (personal computer network system)
FCAD-11 (personal computer CAD system)
ATLAS (automatic translation system)
A
element shaping the software strategies of Fujitsu and Hitachi
critical
was this commitment
which intended
to
IBM compatibility. This was especially true for Fujitsu,
IBM standards for
to follow
whereas Hitachi allowed the architecture for
IBM compatibility.
slightly from
assumption
that,
IBM's
since
domestic and export mainframes,
its
its
domestic computers
to
depart
Japanese companies proceeded on the
Both-
system
360 operating
had been
in
the
public
domain, they could duplicate the 370 software freely, without provoking legal
action from IBM.
This strategy worked
challenges from IBM
in
in
the 1970s,
but brought on several
the 1980s. 20
After charges from IBM that Japanese firms were stealing IBM code, and
the
arrest
of
several
became imperative for Fujitsu
IBM code.
them
to
engineers
s
mainframe,
prompted Siemens
it
operating system.
the
to stop
marketed
M-780,
IBM
competing with
Europe.
In
1984
original
the
1982,
it
copying
division
designs.
s
focus
to
These efforts
challenged
again
This delayed Fujitsu
purchasing Fujitsu
in
in
s
IBM's
s
the
delivery of
3090 machine,
a
and
operating system for the Fujitsu
response
to
these
management reorganized and expanded software operations
shifted
in
to maintain compatibility without rlirectly
IBM-compatible software,
originality of Fujitsu
mainframes
Electric
While Japanese companies reached agreements with IBM that allowed
market
large-scale
and Mitsubishi
Hitachi
events,
at
FnjitsLi
Numazu,
and
producing new operating systems with more
as
of
10
1988
have avoided expensive patont-
Fujitsu
within
the capability
Fujitsu
applications
the
Japanese
competitors.
area,
In
Fujitsu
the
mid-1960s,
resembled
began
it
led
emphasis on
greater
to
programs
rather
automated
tools.
than
customization,
full
Fujitsu
major
its
large-scale
"semi -customization
(Japanese
This quickly became the market leader
1979.
in
of
Rapid growth
and the introduction
JEF
of
'
developing
was distinctive for achieving
package sales with the introduction
Feature)
and
reusability
1
that
customized programs for industrial and government customers.
demand
7
prove necessary.
this
history
s
have created
to
independently and
design operating systems
to
move away from IBM compatibility, should
In
and appear
IBM,
infringement suits and licensing fees with
of
'
numerous
of
major success
a
in
Extended
Processing
Japanese-language
in
word processing packages, and was followed by an equally popular program
which
JEFII,
1983,
capabilities
added
integrated
image,
and
voice
maximizing
concerns of Fujitsu managers resembled
side, the stated
product
to
improve control over development costs
functionality,
performance,
reliability,
these goals with demand for software rising faster than Fujitsu
programmers,
"
Furthermore,
of
management encouraged
efforts
both individual and organizational,
to
encourage users
programming,
Fujitsu
to
to
in
s
"accumulate
ability to train
and
improve
three main areas (Table 7.4)
.
design their own software and spread the
sold
a
large
number
of
support tools and
buyers
provided instruction
in
software engineering methodologies
hardware
to
subsidiaries and affiliated software houses.
as well as
and
To accomplish
maintainability, and delivering products on time to customers.
burden
processing
7T
those of counterparts elsewhere:
technology,
in
.
On the production
while
text,
in
11
to
of Fujitsu
Fujitsu
Table 7.4:
FUJITSU PRODUCTIVITY IMPROVEMENT STRATFGIES
Development Technology
Specialization
Joint Development
Organization
Mechanization/ Automation
Software Tools and other
Computer- Aided Systems
for Planning, Development,
Testing, Maintenance
Modularization
High-Level Languages
Subsidiaries
Reuse
Review Procedures
Structured Design
Structured Programming
Packages
Support and Control Technology
Project
Management
Standardization
Development Planning and Phase
Completion Reporting System
Quality Control Activities
(High- Reliability Program)
Management Objectives
Training
To improve productivity,
technology
.
the
as
well
these
development
as
what Fujitsu called
joint
components
once
and
them
reused
Joint development
development."
philosophy was to make sure managers
interdependent components.
in
different areas developed
across
different
standardizing system description languages and then requiring
be modularized, designed to be reused, and catalogued.
product complexity,
Fujitsu
to
reuse of designs and
be written,
to
referred to software where there were multiple,
Fujitsu's
was
focus
of
This included more emphasis on higher-level languages and,
reduce the volume of new code that had
code,
area
first
stressed modularization,
In
systems,
tfiat
by
the software
addition, to reduce
structured methods for
design and programming, as well as the use of standardized in-house design and
coding languages.
Careful and quantified review, quality control, and inspection
procedures also served
manpower
maximize
to
improve product
efforts
by
reducing
reliability
time
spent
and marketability, and
on
fixing
or
altering
"^"^
programs 25
.
A second area was
specialization
.
12
This
included
the ostablishment of
Fujitsu
development
organizations
dedicated
functions,
particular the
Numazu Works Software
in
Software Factory, smaller development
as
well
53
as
facilities
subsidiaries specializing
system-engineering
of
software
and
and the Kamata
Division
linked by on-line networks,
areas or providing regional
var-ious
in
throughout
services
types
different
to
Japan
Table
(see
These
7.2).
subsidiaries, supplemented by long-term arrangements with independent software
houses,
provided
Fujitsu
to
add
only
not
regional
specific
temporary
and
expensive
less
service and
capacity
Another strategy building on the concept
operations.
have development
facilities
but allowed
skills,
for
programming
was
of specialization
to
gradually place greater emphasis on writing software
packages, especially for personal and office computers, and integrating these
packages with new software
A third area
the
use
of
emphasis was mechanization and automation, particularly
computer-aided
of
maintenance.
produce semi-customized systems.
to
tools
to
support
design,
coding,
testing,
and
These included automated program generators and reuse-support
which management emphasized to improve productivity and quality
systems,
simultaneously. Supporting
and mechanization
to
all
control
three emphases was the application of automation
technology,
in
form of tools
the
for
planning,
project management, testing, and quality evaluation, integrated with standards,
manual procedures, and practices such as quality circles.
Also
of
long-term
relevance
Fujitsu's
to
subsidiaries and software houses was the
Japan's
Ministry
of
International
involved 128 companies
in
1986,
SIGMA
Trade and
plans
project,
Industry
to
continue
initiated
(MITI1.
in
using
1985 by
The project
including Fujitsu, Hitachi, Toshiba, NEC, and
Mitsubishi, as well as 8 foreign firms, and was attempting to increase the level
of
tool
modified
and
library
version of
support for
the
small
software
producers
by developing
UNIX operating system and an on-line data base
13
a
of
Fujitsu
tools
subroutines
and
Fujitsu
stations.
interested both
in
from specially developed engineering work
accessible
and
major
other
improving
tool
Japanese
software
were
producers
standardization and general r-puse capabilities
at the smaller software houses, as well as in selling software tools,
software engineering work stations.
particularly
•JO
SYSTEMS SOFTWARE DEVELOPMENT
Early Experiences
relay and parametron computers either did not employ software
Fujitsu's
or required only minimal programming.
software
development did
not
really
As
begin
until
FONTAC,
as the
Association of Japan,
delivered
still
in
the
early
with
19605,
the
Yet even these machines, as
introduction of several transistorized computers.
well
Fujitsu's experience with
result,
a
1964 to the Electronics Industry Promotion
did not have
'modern
"
operating systems but only
performed simple batch-processing operations.
The FONTAC project nonetheless
to
develop
a
(introduced
large-scale computer
in
1960),
initiated a
new
e.r^,
roughly equivalent
to
and exposing company engineers
programs and computer languages.
by requiring Fujitsu
IBM's 7090 machine
to
various
MITI subsidized the project
in
types of
an effort to
get Japanese manufacturers to develop domestic computers comparable to IBM's.
Fujitsu designed the main processor and the card
punch equipment, while NEC
and Oki Electric made the sub-processors and input/output devices.
took
charge
of
programming,
several Japanese professors,
with
NEC and
assistance from
Fujitsu also
Oki
engineers,
and several U.S. consultants.
The FONTAC software consisted
of a
programs introduced by IBM and available
14
"monitor,
in
Japan.
"
based on earlier control
The FONTAC
also used
Fujitsu
ALGOL, COBOL,
other software which the monitor program controlled directly:
FORTRAN, and ASSEMBLER
compilers;
executable coded tape editor;
utility
programs.
1965 as
the
MONITOR
FONTAC
an
monitor and introduced this
with the 230-50 mainframe,
II
sort generator;
a
programs; and several object (applications)
later modified the
Fujitsu
library editor;
a
in
Fujitsu's commercial version of
FONTAC. 29
Operating Systems Development
The
to
first serious
challenge Fujitsu engineers faced
systems software was
develop an operating system comparable to the IBM 360.
for the
because
the large-scale 230-60 model,
units.
Fujitsu needed this
upgraded 230-series models, wWch incorporated integrated
had, for the time, extensive processing capabilities.
for
in
started
Fujitsu
planning
the
for
230-60
and
This was particularly true
utilized
it
circuits
in
two central processing
and
1966
established
a
software development department to oversee the 100 employees who worked on
MONITOR
V,
hardware and the operating system,
Fujitsu completed both the
the software.
in
1968.30
The manager who headed the new software department was
president
in
Yamamoto Takuma,
1988,
a
1949 graduate of
Fujitsu
s
Tokyo University
s
department. Like Ikeda Toshio, Yamamoto
electrical engineering
telephone switching equipment design, and
in
first
worked
in
1952-1953 briefly worked on relay
computers. From the mid-1950s through 1966, Yamamoto concentrated mainly on
switching and communications data-processing equipment,
MONITOR V
promotion
in
The success
effort.
1968
as
director
of
of
Yamamoto's
software
group contributed
development
n
applications,
and
According
to a
to
subsequent
several
as
Fujitsu
company president.
engineers,
15
before heading the
for
to
systems
his
and
1
MONITOR V was
extremely
Fujitsu
develop due to the dual-processor architecture, then available only
difficult to
in
U.S. military computers
not yet designed
to
sophisticated operating system even for one processor,
Yamamoto,
alone two.
U.S.
a
Furthermore, as Yamamoto recalled, Fujitsu had
."^"^
and other engineers made several trips
Ikeda,
to
let
the
seek assistance from U.S. software houses and computer manufacturers.
This was typical of Fujitsu, where management encouraged engineers to travel
abroad frequently, especially
U.S.,
to the
to visit consultants,
suppliers, and
competitors."^"^
Fujitsu
ended up using IBM's SGO-series operating system
as a basic model,
with modifications to accommodate two processors, and delivered
of the
to
system
January 1969
in
well as incomplete,
late as
University personnel worked with Fujitsu engineers
and finish the programming.
time producing
a
version
Kyoto University Computer Center.
to the
numerous bugs, the system was
a first
Based on
to
although Kyoto
correct existing problems
this experience,
successor operating system,
Due
MONITOR
Fujitsu had an easier
VII, completed
in
1974
and also patterned on the IBM 360 software."^
The major task
of the 1970s
was
to
develop an operating system for the
M-series, which incorporated large-scale integrated circuits (LSI) and competed
IBM's 370 series.
directly with
comparable
series.
to
The new system thus had
offer features
IBM and remain compatible with IBM and Fujitsu
s
230
earlier
To minimize development, Fujitsu produced three operating systems
cover the small, medium, and large M-series mainframes,
separate operating systems IBM offered for
version of the operating system for
delivered
1977.
to
in
1975,
But
its
its
in
contrast to the five
370 series models.
largest mainframes,
The
OS IV/F4,
first
Fujitsu
and versions for mid-size and small mainframes followed
problems
completing
hardware and convinced management
the
of the
16
software
delayed
to
deliveries
of
in
the
need for another reorganization and
Fujitsu
a
more serious commitment
to
developing procedures and tools
production, testing, and quality control.
One
of
the key managers
'
responsible for M-series systems software,
as for the systematization of process
well
Miyoshi Mamoru,
Group.
in
1988
Miyoshi began
and quality control
in
general,
as
was
Fujitsu executive director and head of the Systems
a
his
career
in
systems software management
taking charge of inspection for operating systems.
a
software
for
1973,
in
Prior to this, he had learned
great deal about programming and quality control by inspecting software for
DIPS (Distributed Information Processing System), telephone switching systems
produced for NT&T.
Not only was
technology into Japan
cooperation
with
make sure
keep
up
and
with
leader
in
introducing software
NEC required
Fujitsu,
as
well
adopt rigorous standards and controls.
Fujitsu's
practices, although
to
to
a
the early 1970s, but developing the DIPS software
Hitachi
Japanese contractors,
later
in
NTC-T
as
the
in
other
Miyoshi would
systems and applications divisions adopted similar
when he
first
demand was
moved
to commercial software,
preventing
Fujitsu
from
simply trying
instituting
tighter
standards for process and product, standardization, control, and documentation:
The DIPS
At the time, NT&T was very advanced in its thinking.
software was really a large system. Since three companies, including
My
us, had to develop the software, standardization was essential.
impression was that NT&T was able to devote more effort to software
phase divisions and carrying out work standardization than we were
able to do in the private sector.
Of course, we influenced that
thinking, too, since there was an interchange among us, an exchange
of information ... This was a period of rapid growth, and demand for
software was increasing rapidly too.
We had to write programs
quickly to meet this demand, and worried about preparing
documentation later. In other words, we gave top priority to writing
programs.
This tended to defeat documentation and program
conformance. In the long run this is self-defeating, and, like NT&T,
it
is
better to review and inspect every phase, and get rid of as
many bugs as possible in each phase. But, in 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.
17
Fujitsu
Systematizing Process and Quality Contro
Direction
efforts
Fujitsu's
of
process and quality control
in
department
programming came from the inspection
software division,
in
switching
inspection
in
An
University,
systems
he joined
Fujitsu
before
inspection
and worked
1965
in
moving
to
had
systems
set
up
system
to test
its
first
inspection
and
introduced
for
software
softwar-e
quality
at their
and
control;
and
quality
control,
and
when
allowed
own discretion; 1970-1978, when Fujitsu
and
programming
established
inspection and quality control
of
inspection
to 1970,
systems for product and process standardization, as well as
structured
standardization,
broadening
in
1969.^^
no
programmers
engineer
electrical
Yoshida divided this history into three main phases: prior
Fujitsu
in
prepared for internal use an historical outline
describing the evolution of these efforts (Table 7.5).
telephone
manager
divisioti
1988 the deputy general manager of the division's
quality assurance department,
educated at Yamagata
systems
in
Numazu Works's
the
in
which Miyoshi headed before becoming
Yoshida Tadashi,
1974.
l
inspection
to
in
the
the
period
techniques,
procedures
from
1979,
which
that
when
assisted
formed
the
in
Fujitsu
design
basis
for
the 1980s. Distinguishing the last phase was
include
not
simply
testing
and
a
documentation
conformance, or product evaluation, but analysis of the development process.
18
Fujitsu
Table 7.5:
SYSTEMS SOFTWARE PRODUCT-PROCESS C O NTROL ^"
1968
Software Engineering Department established,
Testing Section, which assisted in debugging.
1970
"Strengthen Inspection" effort begun (1970-1973). Concept of testing
extended from merely debugging to inspecting software from the user s
perspective, comparing performance to specifications stated in manuals.
including
a
Program
Software Administration Department established.
1971
Product Registration System established, requiring new
software to undergo inspection and receive product numbers before
being released. Product Handling Regulations formalized procedures for
software products, manuals, and documentation.
Required all these
product components to be brought in simultaneously, not one-by-one, to
the inspection department for testing and evaluation.
1972
Planning Department established.
1973
Preliminary version of Development Planning Report System launched.
Software
"Application of QC Techniques" effort begun (1973-1978). First serious
attempt to forecast bugs, reduce them through consistent procedures,
and thereby produce "bug-free" software.
1974
"Product and Process Standardization" effort for begun.
Involved
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.
Development started
Support System)
of
BSMS
(Basic
Software
Project
Management
.
Inspection procedures and forms standardized (Main Factor Analysis).
1975
MTS
(Multi-Terminal Simulator) and
tools
developed for testing.
SWN (Software Normen) Standards
HTS (Hardware Trouble
Simulator)
effort launched.
Process (phase) divisions formalized.
Procedures for bug analysis and data gathering formalized.
OC Data
Accumulation" effort formally begun.
BSMS data base started.
Estimates Handbook drawn up, with actual data on past projects to aid
in estimating project requirements, from BSMS database.
managers
1976
Development
Planning Report System (Version No. I) instituted,
software products delivery procedures formalized, and BSMS required
for in-house use.
19
Fujitsu
1977
"Inspection of Quality and Evaluation Indicators" (1977-1978) program.
1978
Structured programming techniques introduced for
similar types of software.
1979
"Consolidation of Inspection Ideology" -- Concept of software inspection
formally promoted as extending beyond testing, to evaluation of final
products and the development process.
utility
programs and
"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 Report System (Version No. 2) instituted, adding
productivity data and review data reporting.
Campaign started
to increase quality three-fold
and productivity
30"6
by
1982.
Software Division establishes
High- Reliability Program.
QC
circles,
as part of the
company-wide
Software Division Quality Objectives established -- formalization
procedures for establishing project estimates and standard times.
of
of Inspection
Ideology through Horizontal Development"
begun to spread knowledge and "good practices" horizontally, i.e.
beyond one's own department.
"Diffusion
effort
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
under direction
of
the
inspection
department.
Quality Objectives control
Subcommittee established.
system
instituted
and
Software
Six program development departments established at Nuinazu
located in new software building.
1983
1984
New Software Engineering Division established, centralizing
software development in the Numazu Works.
Quality
Works and
all
systems
Software Division extends quality assurance and quality circle activities
software subcontractors, as part of the second company-wide HighReliability Program.
to
20
Fujitsu
.
According
MONITOR V
section,
to
chronology and Yoshida's explanations,
this
experience, Fujitsu decided
1068 to establish
in
Assisting designers
following the lead of IBM.
developing software, and was experiencing
Fujitsu
to
management
program testing
debugging was the
At this time Fujitsu had approximately 800 people
group's primary function.
1971,
in
a
based on the
burden on programmers by trying
also increased the
make them more sensitive
customer responses.
to
During 1969-
growing shortage.
a
This involved expanding
the mission of testing to evaluate software for conformance to documentation
the customer manuals,
to
make sure programs performed
as
in
manuals said they
would
The next step was
opposed
to simple
software
to
go
create specific product-inspection procedures,
as
debugging. The most important measures required completed
through
To manage
customer.
to
a
inspection
formal
established
Fujitsu
this,
process
before
release
software
a
to
the
administration
department and instituted specific procedures for product handling, evaluation,
and registration. The product handling procedures covered the software
as well as
manuals and other documentation, requiring
and brought
to
the inspection department together.
sometimes completed and
all
to
be
in
Previously,
released without proper documentation.
however, no product received
a
itself,
conformance
software was
From 1971,
registration number, which was necessary for
release to customers, without meeting these requirements and gaining the formal
approval of the inspection department.
During 1973-1978, Fujitsu made
its first
software through three interrelated efforts:
standardizing
software
collecting quality
product
and
development
practices,
and
A planning department organized
1972 oversaw these initiatives for the first few years.
21
in
applying quality control techniques,
controls
and performance data.
serious attempts to control bugs
in
This contained sections
Fujitsu
programs, and DIPS, and thus
for operating systems, linear
of controls already required for
In
1975 Fujitsu started
formal work-estimation
a
NT&T
procedures for project managers
,
product objects
to
use
in
estimating
and schedules. Table 7.6
,
the development planning system documentation and groups responsible for
This system was characterized not by divisions of authority or tasks,
checking.
but
commercial software.
development planning report system, which set up
man-power needs, quality objectives
lists
to
facilitated a transfer
by
sharing
responsibility
of
and
quality
for
planning
control
in
all
development and testing phases.
In
addition, to automate part of this system, especially data collection on
quality and budget control,
Management Support System)
in
BSMS
introduced
Fujitsu
1975,
(Basic Software Project
after two years of research and trials.
The new procedures, supported by BSMS, introduced not only standards but
a
development phases and managing
for estimating schedules for different
tool
also
the development process, as well as testing and inspection.
BSMS,
which continued
management system
managers had
this
to
to
be the centerpiece of
for basic software in the 1980s,
submit
a
worked
product number application
was approved, they submitted
The
budget.
a
Fujitsu's
to
production-
as follows.
begin
a
First,
project.
If
control system then centered
on the development plan documents and monthly reports of actual work hours,
computer time, and phase completions, which BSMS tracked and compared
initial
estimates. ^^
Fujitsu had used
but they did not work well.
PERT
The development planning system
use of bar charts for project control,
on-line
BSMS system.
engineering department
to
MONITOR
VII
called for the
which Fujitsu later combined with the
The introduction
"^
charts for developing
to the
of
BSMS
also allowed
the software
begin compiling an 'Estimation handbook" containing
actual data on past projects to aid
managers
22
in
their estimates.
Fujitsu
Table 7.6:
C
T
Key:
X
DEVELOPMENT PLANNING ITEMS AND RESPONSIBILITIES 43
Control, P = Planning,
Integration Testing,
= Major Responsibility
=
=
I
=
E = Engineering, D = Development,
Inspection, o = Included in Activities,
Grou PS Responsible for Checking
C
Check Points
Item s
P
E
D
T
I
QUALITY OBJECTIVES:
Development
Objectives
X
Program positioning.
development results,
marketability
Desired
Functions
User needs and
program functionality
Performance
Objectives, measures,
comparative analyses,
appropriateness of the
X
X
X
X
X
measurements
Compatibility
Reliability
X
Objectives, appropriateness and completeness
of the objectives
Appropriateness
objectives,
X
X
of the
likelihood
of implementation
PLANNING IMPLEMENTATION
Appropriateness of
size given functions,
modularization/ reuse
X
Development
Appropriateness
X
Process
delivery time to user,
Development
Language
Size,
of
X
X
X
X
X
X
o
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
o
for improving quality
and efficiency
Development
Organization, work
Structure
distribution
divided
Fujitsu
development
the
process
seven
into
phases,
following
basic design; structural and functional design;
conventional life-cycle models:
detailed design and coding; unit and combined test; component and system test;
Personnel
product inspection; delivery and maintenance.
responsible for standardized documentation and reports.
the development and planning documents included
basic design
document,
which
listed
as well as estimates of
objectives,
functional,
a
each phase were
in
At the
initial
phases,
market survey report and
and
performance,
manpower and machine
a
reliability
time.
Completion of functional and structural design required documents detailing
the
function
of
each
system
between each module, plus
testing plan.
a
module
component,
required
interfaces
of each module,
and input
At the completion of unit and combined test,
programming
a
and
Detailed design required flow-chart
and tabular documentation on the internal structure
and output structure.
structure,
report,
which
included
the
detailed
Fujitsu
design
review reports, test specifications and results, as well as the
documentation,
source modules.
After system test, the testing report documentation included
the inspection specifications, test specifications and results, and the test set,
while final inspection generated another set of results.
The most important quality measures
component
conformance
reliability
in
detected,
and mean time between failures.
introduced
in
sort through
test,
to
Fujitsu
"^
initially
documentation,
focused on were
number
Main-factor analysis
1974 and influenced by practices at Hitachi,
of
bugs
techniques,
required testers to
intermediate test data to identify sources of bugs,
before final
testing. Standardizing testing and review procedures was particularly important,
because Fujitsu had no consistent approach for predicting and eliminating bugs.
Individual programmers decided which tests to run, without formal planning or
supervision.
Better control
in
this area then allowed Fujitsu in the later 1970s
24
Fujitsu
to track
other measures, such as software functionality and portabihty.
The period from 1979 Yoshida characterized by three themes:
assurance through organization, diffusion
and advancement
development,
of inspection ideas throiigii horizontal
quality
of
quahty
The central notion
concepts.
in
assuring quality through organization was to make quality assurance activities
part of the formal organizational and job structure,
planning, rather than
especially
design and
in
function restricted to the inspection department. Fujitsu
a
implemented this new emphasis by instituting
1979-1980
in
a
"phase completion
reporting system," resembling the design- review systems used at other firms,
and then
new version
a
of
reporting system required,
introduce
previous
in
data
Toshiba
instituting
these
was several
Fujitsu
standard
became
software,
of
a
times
major
as
years
of
incorporating
behind
pr-oject
Other measures
included
institution of practices to
fixing
bugs
in
in
the
quality
assurance
check for bugs introduced
another part;
in
and
programming
and
control
tool
raising productivity 30% by reducing
meet
this
objective,
this
were the
effort
one part of
program
a
and participation of the division
company-wide "High- Reliability Program." Fujitsu managers
not
quality
NEC,
Hitachi,
structured
as
well
feature
and
based on actual
standard times annually.
of revising
did
to
Like other Japanese companies, Fujitsu also adopted the practice
development.
when
types
different
for
Although
techniques,
programmers and managers
1980 standard times for worker performance,
objectives.
in
for the flnst time,
Standardized productivity data then allowed Fujitsu
collect productivity data.
to
development planning report system. The new
its
also set
a
in
the
goal of
bugs one-third; even though the division
established
the
policy
of
connecting
productivity to quality control, and setting specific goals to motivate employees.
To support
this initiative, in 1982-1984, Fujitsu
25
introduced new testing tools and
Fujitsu
and purchased additional equipment
techniques to help select test items,
insure that testing could proceed 24 hours
day,
a
efforts
control
beyond one's
assurance
spread good
to
(QAL)
departments and projects
data.
As part
activities
of this
which
structure,
regarding
up
set
a
quality
formal "quality
meetings
different
for
share information on bugs and other quality- related
to
Fujitsu also established other quality control
initiative,
division also participated
which promoted the teaching
subcontractors.
and practices
thinking
and meetings, including quality
The software
ideas" referred to
This involved institution of
small group.
liaison"
necessary.
of inspection
What Yoshida called "horizontal diffusion
deliberate
if
to
circles,
in
the second High- Reliability Program,
of quality control
"Advancement
techniques
concepts"
quality
of
initiated for software in 1980.
to subsidiaries
centered
on
and
expanding
interpretations of product quality beyond "zero bugs" to other characteristics,
such as product design, function, performance, ease of use, and maintainability,
as
encouraged by U.S. experts
Also
in
like
Barry Boehm.
the early 1980s, Fujitsu began applying to software the term
or "Total Quality Control,"
a
term coined
in
the 1950s
in
"TQC
'
the U.S. and applied
widely by Japanese firms since the 1960s, including Fujitsu, to comprehensive
quality assurance efforts covering product planning, design, manufacturing, and
service,
TQC
rather than simply inspection after production. Software
goals
in
Fujitsu focused on improving control over bugs, delivery dates, and costs, which
management hoped
to
lower-level activities
achieve through
in
planning,
standardization,
field
quality
training,
supported the efforts
committees coordinating
areas affecting software products,
all
through maintenance (Figure 7.1).
process
division-level
of line
and
A series
of
evaluations,
high - reliability
from planning
committees for product and
quality
circles,
promotion
set
technology,
policies
and
and staff departments for planning, development,
26
Fujitsu
software engineering,
and maintenance completed the
TQC
system.
The High- Reliability Program presents an example
division
in
participated
Fujitsu,
like
Japanese
other
conventional
with
factor-ies
improve quality and productivity.
in
a
in
firms
service.
company
Fujitsu started this
as
a
month
to
discuss
work
as
well
1980,
NEC).
division
the
and
group
program
in
factories,
efforts
to
1966, initially
in
an attempt to institute
did
software
of
which met
first
used
also
the
circles
to
new company employees.
not actively
its
of quality circles,
Managers
conditions.
when Numazu organized
By 1985,
software
range of issues related to productivity and
a
supplement formal training required
The software
how the software
system covering research, design, manufacturing, and
The program gradually expanded the use
once or more
quality,
TQC
of
with
hardware development and manufacturing divisions,
comprehensive
Procedures for
work and product standards, product evaluation,
project and budget control,
registration,
and field-support.
inspection,
control,
participate
in
the program
software quality circles
(a
had approximately 300,
division
until
year before
averaging
7
members and meeting once per month. The quality assurance group within the
inspection department oversaw circle activities,
while section chiefs organized
and managed them. The most frequently discussed themes
maintenance problems
and techniques
(301s)
in
and testing
1985 were software
(IS*?,),
followed
by
programming, bug analysis and correction, design, reviews, manuals, planning,
and inspection.
Management
submit suggestions, which
in
also
encouraged the circles and individuals
1985 dealt mainly with maintenance, programming,
control (quality, process, cost), testing, computer usage, and
correction.
Under the influence
software division
to establish
in
similar
to
of the
bug analysis and
second High-Reliability Program, the
1984 also began working with subsidiaries and contractors
TQC
systems, including quality circles.
27
Fujitsu
•s.
-3
<
-J-
Quantifying Control Measures
Similar to other Japanese factories,
Numazu Works attempted
Fujitsu's
quantify and analyze basic measures of performance
and then institute standardized procedures and
individual variability and thus
much
as
tools.
in
a
standardized manner,
One reason was
dependency on high-levels
of
"build
in
"
reduce
to
experience and
conventional factory organizations have attempted.
objective was to
to
skill,
Another, related
quality at each phase of development,
rather than
trying to "inspect in" quality at the end of the process. Yoshida reflected this
thinking
in
a
recent
describing the
article
program for
software division's
quality assurance:
The prevailing opinions that high-quality software products can
produced readily by using certain methods, that quality can
ensured by sufficient testing, and that quality control can
achieved through the diligent work of a single control section
be
be
be
are
mistaken.
Better development methods, appropriate standards, and
various control activities must be applied throughout the entire
software life cycle, and quality can be assured only if all the above
are carried out under an integrated management system throughout
the life cycle. "
To
institute this type of
management system,
and quality assurance worked on four approaches.
activities to quantify
Fujitsu
staff
were
First,
inspection
in
a
series
and analyze information on project progress and quality.
Second, was the introduction of methods for predicting error occurrence
programming phase, and
aimed
Third,
in
the U.S.
a
to
determine test items,
and generally applied only
to
was the use
to as the
of
"Taguchi
Fourth, was an
attempt to evaluate quantitatively the concept of "user friendliness
a
the
product development and
processing of conventional hard products such as automobiles.
through
in
"management by objectives" system
of
"Design of Experiment" techniques, often referred
statistical
method"
institution
error correction.
at
of
"
of
software
variety of tests. ^^
29
Fujitsu
Measuring
common way
number
to evaluate
was
progress
design
problematic
mainly
because
the
most
schedules was to compare actual progress, such as the
of completed modules,
or
completed
Fujitsu's case,
in
and "work items," with estimates made prior
measure thus depended on the accuracy
to starting
work. Accuracy of the
of the prediction,
which managers could
To maximize the accuracy
not fully determine until completion of a project.
"
"design sheets
of
estimates, Hitachi kept extensive data on previous projects and the performance
and
experiences
detailed
data,
but
personnel.
individual
of
used
two
indices
similar
measured quality, based on points received
how
predicted
well
amounts of work
managers define tasks
in small,
The system worked
actual
segments,
followed:
as
such
One
evaluations.
project
for
keep
to
reviews, and another quantity, by
in
fit
realistic
chose not
Fujitsu
data
helped
to minimize estimation errors.
the
In
This
results.
planning
managers
stage,
determined work items and entered these on work item sheets, which then were
entered into the
activities
BSMS
Work items were segments
data base.
that could be done
about two weeks.
in
of design or other
Projects were organized
groups, and each group leader was responsible for one work item
at a
Each member then had to
as
out a "review trust sheet,
fill
reviews from several other people, including
check-list to evaluate work, and
a
'
chief reviewer.
members had
to
as
well
time.
receive
Reviewers used
make changes
until
in
a
the chief
reviewer was satisfied. At weekly progress meetings, managers and group leaders
checked the progress
number
of
quality
quality points,
reviews
of
points
each
work
received
assigned through
received 50 points;
a
item.
The quality index compared the
reviews with
in
simple scheme:
completion
of
all
the
number
of
predicted
Completion of materials for
reviews and changes
required
brought 100 points. Actual quality points were assigned by giving 50 points for
completion of materials for reviews,
and 50 or more points depending on the
30
Fujitsu
review evaluations.
Using these formulae, Fujitsu arrived
for each
member and
quality.
In
addition,
project,
"
part of
as
well
as
at
"comprehensive quantity figures
made an
as
initial
tracking of proriuct
quantitative measurement efforts,
its
Fujitsu
regularly used statistical regressions and factor analysis to identify probable
causes
of
errors,
requirements, and
as
as
well
to test the
depended on the accuracy
from actual values.
estimate
to
numbers
of
accuracy of estimates.
of the predicted values,
bugs and man-power
Progress evaluations
still
which sometimes were far
Overall, however, Fujitsu managers claimed to have solved
the major problems with the system and,
reported significant improvements
in
progress control as well as quality.
Testing Techniques
Fujitsu's
objectives
program by the end
of the
and 99% by the end
of
meeting these goals,
testing were to detect 65% of the bugs
in
coding phase review,
the inspection process.
however,
was that,
as
95''6
"^
in
by the end
system
of
conditions
to
the
significant improvement
as their
Furthermore,
completely.
test
in
design
of
result of these observations,
Fujitsu
a
company
managers decided
to
employ
in
in
of factors
data
in
showed
software
As
leveling off after about six years.
selecting test cases that less experienced could understand,
1987 article by an engineer
test,
any complex
the ability of personnel to detect errors
experience increased, with
new
A problem encountered
product or process, large programs contained too many combinations
and
a
in
a
a
method for
as discussed in
a
the quality assurance department:
In tests involving many inspectors, a means is essential to standardize
the quality of testing conducted by each inspector, but there is a
limit as to the extent to which one can share the knowledge and
skill through training ... The omission of test cases during test factor
31
Fujitsu
associated with problems relating to the scope of
is often
The omission of test
knowledge and insight of the testing personnel.
cases during test case generation is often caused by omissions or
[T]he number of test factors [selected] increases in
careless errors.
proportion to employed years up to 6 years and stays constant after
Therefore, to improve the quality of test factor analysis as a
that.
whole, it is a significant importance [sic] to transfer knowledge to
less experienced testing personnel.
analysis
.
.
.
Two approaches appeared most
useful
much
a
The conventional way
program.
cause-effect graphs,
effectively.
transferring
develop tools that automated
to
but these
methods and conditions,
of
were the source
generating
required
A second approach was
initial
great
a
to create a data
complete with
an
deal
of
most errors
test cases
of
was
knowledge
of
in
to
use
to
use
base on test-factor analysis
editing
support function
personnel utilize the data base to create test cases for new programs.
technique Fujitsu introduced, beginning
of this latter
initial
program's external specifications or input characteristics. Such
tools often could identify critical factors that
a
and
capturing
process as possible, particularly the generation of
of the testing
tests based on
in
One was
knowledge regarding software testing.
as
.
in
to
help
As part
the early 1980s, Design
Experiments methodology.
The Design
of
Experiments techniques relied on educated guesses
problems were likely
then
specific
tests
to exist
r-elying
arrays" (statistically independent groups of factors).
control the
number
of combinations
minimize measurement errors
where
(which could be listed for easy reference), and
and evaluated
selected
of
on
tables
"orthogonal
of
These made
it
possible to
that existed between any two factors and
and other conditions,
and identify correctable
defects more quickly than conventional techniques such as cause-effect graphs.
In
fact,
Fujitsu data indicated that the
10 times or
more the number
with fewer test cases.
DE methods could
of errors usually
actually detect 5 to
found with conventional methods,
'^'^
32
Fujitsu
To quantify "ease
and
inspections,
use
validation
maintainability),
a
,
grouped features relating
(such
major
as
and minor (such as syntax
friendliness,
as
productivity,
targets
ease
speed
flexibility,
its
products
as
opposed
to
minor items,
covered
evaluations
(performance,
all
the
led
to
basic
learning,
of
of
to
efficiency,
operation).
quantified
,
scores.
characteristics
operability,
reliability,
coordination, ease of maintenance, quality of information
well as
through
users
product on various items, using simple "yes" or "no" responses and
claimed
software
surveying
by
that users
(such
intermediate
more points for major
Fujitsu
accuracy
of
three categories:
into
understandability )
Scoring
measures, Fujitsu employed manual reviews and
The surveys indicated
questionnaires.
ease of
of use"
of
compatibility,
price and delivery
design quality and consistency (defined as the "degree
to
and specifications meet user needs," and the "degree
a
)
,
as
which software
which the
to
finished software meets the design targets and specifications'), and sufficiency
and attractiveness ("the extent
to
which products are acceptable
users').
to
r
tr
Fujitsu also claimed to use 113 items merely to evaluate ease of use.
Tool Support
Similar
to
Hitachi,
Toshiba,
and NEC,
in
the mid-197ns
Fujitsu
began
developing numerous support and management tools; major ones (for systems
software primarily)
are listed
in
Table 7.7.
Numazu was the center
development, with Kamata importing tools such as
the
1980s,
Laboratories,
however,
Kamata
and
the
have become more involved
central
in
tool
of
tool
ADAMS and GEM.
During
research
Fujitsu
facility,
development,
such as those
directed at automating system design and construction."^"
33
Fujitsu
MAJOR SYSTEMS SOFTWARE DEVELOPMENT TOOLS
Tablfi 7.7:
f1983) ^^
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).
Linked to PRISM.
Automatically maintains a development history of a program.
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
and assembled code.
Utility)
.
Compacts and prints out compiled
TOOL
2 (1983) Allows on-line search, from time-sharing terminals, of program
source code and lists.
YPS
(YACII
(1987)
Programming System).
Allowed the user to edit YACII
in several languages.
diagrams and then automatically generated code
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)
.
tool for
on-line
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.
Simulates remote
HTS (1977) (Hardware Trouble Simulator).
Simulators
functional test evaluations of software responses.
hardware bugs for
DOCK/FORT77
using
display.
(1981).
Debugging system
for
FORTRAN,
a
"slow video
"
PIC (1984) Program Information Control System. Allows inspection and analysis
memory-dump lists from time-sharing terminals.
Linked to the KamataNumazu Dump Transfer system.
of
ATOS (1982) AIM Test Oriented System. Automatically
data base results from testing and inspection.
34
records on computer
Fujitsu
.
DOCUMENTATION
ODM
(1983) (Office
Japanese language.
Document
Document Manager)
MANUAL COMPILATION AUTOMATION SYSTEM
electronic documentation
EGRET-4
(1983)
ATLAS
(1982).
English
to
(1979).
for
<;ystem
lianrJIing
Automated editing
of
files.
(Easy Graphic Report Generator).
Automatic translation of Japanese documents
Japanese system added in 1986.
English.
into
MAINTENANCE
TDP
II
(1980) (Total System for Difficulties Information Processing). Data base
for software report information.
(Incident
ITS (1981)
customers
Tracking System).
KAMATA-NUMAZU DUMP TRANSFER
reports on bugs.
Linked
PDE (1983) (PTF Document Editor).
corrections, based on TDP II data.
system for questions
On-line
(1982).
PIC testing
to
Control
transfer
from
data
of
and
tool.
Automatically edits documents on program
CONTROL
BSMS
(1976)
and control
NOA
(Basic Software Project Management Support System).
for software project management.
Data base
tool
(1978)
(Numazu Office Automation). Employment data control system.
IN-HOUSE TRAINING DATABASE SYSTEM
(1982). Relational database system for
in-house training administration.
Fujitsu's tools closely resembled those
in
use elsewhere
in
Japan, though
they operated separately and were less integrated than the work-bench systems
at Hitachi
and Toshiba.
ITS, and the
and
There were, however-, data-base
among TDPil,
Dump Transfer system (maintenance), BSMS and TDP
GEM and PRISM (program
Particularly important
GEM
links
(Generalized
construction).^"
among these
Program
(control),
II
Editing
tools
and
35
were BSMS, described
Management
Facilities),
earlier,
a
and
libraryFujitsu
management and data-collection
that
tool
automatically
reports, for groups and individuals, on productivity
progress status (by month and week)
,
f
generated
lines of
graphic
code developed),
and quality (bug levels per module)
.
The
library functions included version control of modules and completed programs.
Tin
as well as
compressed data
Another important
reduce the volume of stor-ed
to
tool set
was YAC-II (Yet Another Control Chart), which
Fujitsu used for functional design, and
the
1970s,
VPS (YACII Programming System), which
The VAC
automatically generated code.
diagr-ams, first introduced by Fujitsu
resembled other flow-chart or problem-analysis diagrams used
Japanese firms since the early 1970s, after
system and requiring
in
1987
files. "^
along
its
enhanced productivity
The YPS system contained an
and documentor, and received inputs
on work stations.
readable YACII
in
developing an internal
One was
two ways.
in
Another was
eliminate the need for detailed documentation.
and debugging time.
in
The current version, introduced
use by subcontractors.
YPS,
with
NT&T began
in
to
to
reduce coding
editor, compiler,
debugger,
structured but conversational Japanese
A host computer then translated the inputs
charts and then executable,
"bug-free" code
Cobol, or SPL (System Programming Language,
a
in
into
machine-
C,
Fortran,
PL/I derivative developed at
Fujitsu). ^0
Performance Improvement
Fujitsu
data
indicated
steady improvements
quality
(reliability),
productivity
control
(lateness).
Available
the decade after
in
(development costs),
data
summarized
software, where the average program ca.
in
in
and project schedule
Table 7.8 cover systems
1986-1987 was about 170,000 lines of
code with comments (125,000 lines without comments), with
800,000 lines. These programs were primarily written
36
1975
in
a
maximum
of about
SPL or C."
Fujitsu
For
code
all
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.
fallen to practically zero (0.01
for which
1985,
showed
bug
similar gains.
new code reported by users (generally about
four-fold between 1980 and 1981 alone.
as
bugs dropped
Table 7.8:
Note:
to
levels for outstanding rode liad
For newly written code (annual data
and below).
confidential), Fujitsu
is
By
Bugs per 1000
10 times the level for
Improvement since
all
lines of
code)
fell
1981 has leveled off,
approximately 0.1 and below.
SYSTEMS SOFTWARE DEVELOPMENT PERFORMANCE MEASURE S^^
All data are estimates based on graphs, and therefore are approximate
figures only. 1983-1985 is based on internal Fujitsu data. Bugs/1000 LOG
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
Bug Detection Method
Test
Source Code
Review
(Estimates)
Design Sheet
Review
Development Costs
per 1000 LOC
(Index)
100
87
1975
61
5
54
1978,
has gradually become the major method for detecting bugs,
this
from 5% to approximately 40%
Fujitsu
1982.
in
measured productivity by
lines of
code (steps) produced per man-
month, number of documents per man-month, and
1000
Two other
lines.
related
indices
Numazu Works
three-fold productivity improvement between 1975
1985,
and then the centralization
1976,
in
Numazu Works
increase
The data on
code."^
lines of
The most dramatic improvements came with the opening
expenses.
1975 and
development costs per
not adjusting for inflation or use of outside contractors to reduce
and 1983,
the
a
total
were machine time divided by man-
months, and pages of documentation per 1000
development costs indicated
r-ising
after 1981.
including
system development
in
Lines-of-code data also suggested that, between
reused code,
output per worker.
in
of
the
of
experienced roughly
Fujitsu
5-fold
a
In-house studies indicated that factors most
strongly affecting productivity on the positive side were programmer ability,
On the negative
followed by product complexity and software tools.
reliability
requirements.
Improvements
progress
40°6
of
in
in
and
quality
scheduling accuracy.
projects
were typically
In
productivity
this
to
frequently came
too often taking
about
in
15%,
a
corresponded
to
significant
the late 1970s, according to Yoshida, about
with
late,
inspection department after the scheduled time.
reduced
side were
level
"late"
defined
as
reaching
the
By the early 1980s, Fujitsu had
comparable
to
Hitachi.
Delays
most
the transition from functional design to coding, with coding
more time than estimated.^
38
Fujitsu
APPLICATIONS SOFTWARE DEVELOPMENT
Factory Origins and Organization
Fujitsu
decision
s
establish
to
programming stemmed from the need
programs for different customers.
much
of
their
its
system orders, however, led Fujitsu
expanded
integrated
a
factory
applications
for
variety of nominally different
the early and mid-1960s, users performed
own applications programming, with assistance from
department Fujitsu set up with
(later
produce
to
In
software
a
computer division
to
organize
hardware and
software
systems department
a
systems,
such
as
in
(beginning
sales of Fujitsu
in
Laboratory was divided into
computer-aided design
all
its
1965) and
Fujitsu to centralize
engineering,
,
in
management
to establish
The
Kamata, Tokyo."
systems development area and an education area.
a
staff of 700 allowed
variety of industrial,
the 1980s,
in
computers brought continued demand
1970 the Information Processing System Laboratory
initial
for
1967). ^7
in
for customized applications software, prompting Fujitsu
An
of
1965), and data processing software for Fujitsu mainframes
in
Rapid increases
in
1964
in
1964 and the
delivered to government customers (such as the Ministry of Labor
NT&T
large
programs
on-line
securities firms and banks (first deli vnr ed to Nikko Securities
Norin Chuo Bank
Several
1963.
These orders consisted mainly
Systems Group).
into the
in
service
a
program development
and scientific applications,
as
well
for a
as
pattern recognition, and computer-aided instruction
Fujitsu was using the Kamata facility to
.
for
By
produce software for nearly
mainframes, minicomputers, and super-computers,
as well
as for office
computers, terminals (banking, postal), and personal computers.
Although
the
U.S.
packages and away from
software market
fully
shifted
gradually
toward
software
customized systems, Japanese customers continued
to prefer tailored software systems.
In
39
response, according
to Fujitsu director
Fujitsu
Fujitsu created a Systems Group,
Yoshiro Nakamura,
facility,
that
departments,
not
only
but
also
offered
engineering
specialized
facilitated
centered on the Kamata
development
the
and
and
programming
reuse
The mission
packages, which could be integrated with new code as necessary.
of the Software Factory
and subsidiaries or software houses connected
Systems Group was primarily to use these packages, as well
methodology and
set,
tool
software
of
to
as a
to the
factory-type
produce semi-customized systems
rather
than
standardized products (packages) or fully customized products.
As
of
1986,
the Systems Group consisted of three major areas,
separate Development Planning Office directing
(Figure
7.2).
Engineering)
The
development"
"joint
Center,
Technical
which
housed
a
and methodology research
tool
area
with
included
the
SE
the
Software
(System
Factory
and
departments such as for standardized technology promotion, office system and
other
system engineering done
in
the
center,
Package Planning and Control Division; and
area was the industry-specific design
engineering for companies
and distribution, as
government
departments,
NT&T,
scientific
for
which performed system
and technical applications, and
The third area consisted
as
A second
research facility.
departments,
the
finance, insurance, securities, and manufacturing
well as for
users.
such
in
a
and the SIGMA project;
management
of
information
functionally
systems,
specialized
"value-added
networks" for offering different on-line services, personal computer systems,
and new telecommunication firms (NCCs).
40
Fujitsu
Figure 7.2:
SYSTEMS GROUP AND SUBSIDIAR IES QRGA NI ZATION
1986
SYSTEMS GROUP
9000 Employees
(ca.
in
'^
2
1988)
Development Planning Office
JOINT DEVELOPMENT AREA
SE Technical Center
-- Software Factory Department
-- Information Center Dept.
-- Standardized Technology Promotion Dept.
-- System Engineering Dept.
-- Office Computer System Engineering Dept.
--
•
SIGMA
Project Office
Package Planning and Control Division
-- Package Planning Dept.
-- Software Distribution Dept.
Fujitsu Systems Research
INDUSTRY-RELATED DEPARTMENTS
--- Finance
Insurance/Securities
Manufacturing/Distribution
Scientific/Technical
---
—
NT&T
Government/Mass -Communication
FUNCTIONAL DEPARTMENTS
Management Information Systems
—
—
VAN (Value-Added
Network) Systems
Information and Communications
Personal Computer Systems
NCC (New Common Carriers) Systems
SYSTEM ENGINEERING SUBSIDIARIES
(ca.
53 firms
and 11,000 Employees)
Industry and Functional
Regional
While Fujitsu
1960s
made
and early 1970s,
efforts
only
in
to
centralize applications
the
later
1970s
did
it
development
adopt
a
in
the
factory-type
organization separating system design from program construction (Table 7.9).
41
Fujitsu
According
Factory
and
Department,
programs
1988
in
a
a
manager
preliminary
Factory
Conversion
of the developers of the
Murakami Noritoshi, one
to
written
was
Department.
Next,
in
1979,
the
Development
Software
1977
Fujitsu
and
Hitachi
for
Fujitsu machines.
step
the
in
Kamata Software
establishment
used
this
IBM computers
applications
terminals
expanded the department
Fujitsu
Software
a
revise
to
and
of
Planning
to
run
on
into a small
software factory, with about 300 programmers charged with turning requirements
specifications received from system engineering into code.
The major reason
for
upgrading the conversion
Murakami, was
to centralize people
objective
accumulating
of
handle about 25% of
all
to
and standardize process technology, with the
knowledge
regarding
commercial
applications
standardization,
tools,
The factory was
programming environments, and development techniques.
to
according
facility,
programming
in
able
Fujitsu.
Most other programming work Fujitsu channeled to subsidiaries and affiliated
software houses.
'^
Prior to establishing the factory,
a
group headed by Yoshiro Nakamura
began compiling the SDEM (Software Development Engineering Methodology)
standards
in
1976,
and introduced
version
a
for
in-house use
in
1977.
As
occurred with operating-system development, the larger programs needed for the
M
series
computers
required
Fujitsu
to
and
standardize
engineering tools, methods, and management procedures.
tool
set,
Fortran.
SDSS
74
SDSS (Software Development Support System),
As more business programs were written
with
new
tools,
later
integrated
Development Architecture and Support
software
Fujitsu also issued
for
COBOL,
under the
Facilities).
42
in
integrate
name
programming
a
in
Fujitsu replaced
SDAS
(Systems
'^
Fujitsu
APPLICATIONS SOFTWARE FACTORY ESTABLISHMENT
Table 7.9:
1964
Establishment of Systems Department, later expanded
1970
Centralization of applications
Processing Systems Laboratory
to
systems development
Kamata
Systems Group
Information
at
in
Establishment of Software Conversion Factory within the Laboratory
convert IBM and Hitachi programs to Fujitsu machines
1977
to
Introduction of
SDEM standards
1978
Introduction of
SDSS
1979
Establishment of the Software Factory Department to perform detailed
design, coding, and integrated test of customized applications programs
specifications received from system engineering departments
tool
set
Since specialized knowledge seemed essential for accurate system design,
Fujitsu
software
maintained
specialized
government systems,
engineering
manufacturing,
covering
factory,
system
and
and
scientific
departments handed designs
distribution,
engineering
to subsidiaries
and
sections
specialized
certain applications or industry areas.
in
The factory
the
software
(and subsidiaries
s
)
factory,
test.
programmers together
System
at the
off
site.
mainly),
a
also
(if
necessary), and continued
in
the same groups as
design documents.
doing coding for 4 or 5 system engineers.
in
or
Prior to the factory organization,
The factory departments were organized
specifications
The SE
where programmers
system designers either did their own coding or worked
programmers, rather than handing
programs.
systems,
was then done by the designers and
test
customer
financial
the
workers took system documentation and
produced detailed designs (flow charts) and code
through integration
outside
affiliated software houses,
programming
in
departments
in
teams of
7
or 8 programmers
The system engineers wrote design
standardized format using conversational language (Japanese
but providing input/output diagrams and mathematical equations as
43
Fujitsu
necessary, to minimize the amount of
skill
Programmers who did not understand part
finished
part of
a
engineer
system
responsible
a
who would check
it
and
discuss
required of the factory personnel.
document would
of a design
system, they would send
back
it
system engineers,
to the
Most problems
with the customer.
When programmers
problem.
the
specifications were
in
thus ironed out during the design and coding process.'
Fujitsu also minimized
the type of "matrix management" problems that had plagued the
Factory by designating
then
the
giving
system
a
chief system engineer and a chief
engineers
main
the
the
call
responsibility
SDC Software
programmer, and
for
dealing
with
customers and producing systems that correctly met customer specifications '°
.
System engineering departments -m4ght send designs
or subsidiaries for implementation,
either- to the
hence there was not
factory
strong distinction
a
between the type of programming these different organizations could handle.
general,
however, the factory provided capacity for systems that subsidiaries
might have
a difficult
time with, such as on-line banking software, which could
reach millions of lines of code.
For these types of large programs, the factory
employed an "on-line" SDEM system that allowed up
work on
a
a
period of one or two years.
packages designed
in
The factory
also did
the system engineering area,
if
the SE departments' new-code development groups.
avoided
thousand people
to
Toshiba.) The largest projects done
at
the factory might use 4 to 6 mainframes, and involve
a
a
(The Kamata factory maintained about one terminal for
single mainframe.
over
in
to
single project simultaneously, with 200 to 300 terminals connected to
every two employees, twice the number
in
In
jobs
that
programmers, such
required
a
great
deal
as artificial intelligence
of
a
thousand personnel
some programming for
there was
In
a
work overflow
addition, the factory
expertise
on
the
programs, which Fujitsu did
part
in
of
R&D
departments 7Q^
'
.
44
Fujitsu
Software
houses
from
long-term
a
when projects were running
particularly valuable
personnel
worked on
that
primarily
these firms,
help
to
generators were gradually eliminating coding).
basis
program
(although
coding
As
were
Fujitsu
Fujitsu would often add
late.
in
with
other Japanese software
at
factories, Fujitsu appeared able to add people without delaying projects further
because
of
the
standardized
subcontractors' personnel.
methods
and
Another advantage
and
tools,
of using subsidiaries
houses was that Fujitsu could meet demand peaks beyond
even
training,
its
of
and software
own capacity and
without adding too many full-time (and higher paid) employees
ranks of
to the
permanent employees.
Training and Career Paths
While
most
employees
Kamata
the
in
Software
graduates, and usually had good backgrounds
in
were college
Factory
Q
employees generally had no computer engineering or software training."
required Fujitsu to invest heavily
in
new
science or mathematics,
training, but allowed the
company
1
This
to
teach
workers, and managers, the factory methods and no others.
For
example,
after
deciding
on
the
instituted a three-day training seminar,
project managers, and
a
SDEM standards,
in
1977
followed with periodic workshops, for
PI
New
year and attended
full-
lengthier education program for new employees.
employees were considered trainees for the entire
time classes for three months,
Fujitsu
first
learning Assembler,
COBOL, machine
I/O,
and
other areas of basic programming and computer architectures. After the classes,
training continued on-the-job,
and
through coding simple programs for commercial
customized
systems,
instruction
every month or two.^
through
another
Until
two or
days
of
additional
they became managers,
employees
continued to receive about eight days of training
45
three
a
year
in
workshops,
in
Fujitsu
addition to self-study materials and quality-circle activities.
Career paths
Fujitsu
at
though they were not
as
resembled
formally
those
defined
as
other
at
software
Hitachi
at
'^
Factories,
and Toshiba.
employees usually did coding for several years, and then moved on
design, and structural design.
might become
Programmers
system engineer (designer).
a
module
After 5 to 10 years, depending on an individual's
determined by managers, rather than formal testing),
ability (as
to
New
in
programmer
a
the factory, like
system engineers, specialized by application or industry area for
at least their
on:
but then might move to other areas.
first 3 years,
There are some reports that
engineers,
again
in
contrast
to
lack of a formal training
Hitachi
and
Toshiba,
program
made
possible
it
Fujitsu's competitors to provide better system-engineering services.
these claims,
1986 Fujitsu established
in
house department for training personnel
customers
Fujitsu
in
department with
30
experienced
for
To counter
Systems Research as an
in-
system consultation and assisting
system planning and problem solving.
in
for system
administrators
and
Fujitsu
70
staffed the
experienced
new
system
engineers °"
.
SDEM
The Factory Methodology:
Fujitsu
introduced
SDEM
(Software Development Engineer's Methodology)
and SDSS (Software Development Support System) during 1977-1978
to
serve as
standardized development and control procedures and automated support tools
aimed
at
improving customer-requirements definition and techniques for design,
programming,
project
control,
and
system
maintenance.
Managers
were
particularly concerned with the constraints on productivity created by design
changes and documentation rewriting (usually 20
to 40°n
by the
final
version)
and test-case generation.
46
Fujitsu
Fujitsu had standards prior to 1977,
and weakly enforced.
Development was very much
programs more the property
Documentation
but they were only vaguely defined
of individuals than the
in
"craft"
a
SDEM and SDSS,
program written by someone
it
with
product of an organization.
and standardization were so lacking that,
engineers who developed
mode,
was
as
difficult
recalled
to
by the
understand
a
else:
We had software development standards before SDEM and SDSS were
developed but the standards had no clear definition of the
This lack of definition resulted in so much
development phases.
freedom that software systems often became the products of
individuals.
It was not easy for a person who had not designed a
program to understand how it worked. To improve on this situation,
we concluded that clear, reasonable definitions of the developing
phases and activities were required.
The kinds of tasks performed
during each activity also needed standardization.
According
Nakamura,
to
standardization
of
they considered two options:
procedures,
techniques,
and
the
improvement and
overall
development
environment; and automatic program generation, relying on standardized formats
for specifying user requirements
and "state-of-the-art"
emerging state of program generation, they focused
and later on program generation.
proceeding
with
automation,
they
It
tools.
initially
Due
to the still-
on standardization,
was also their philosophy that, before
had
to
establish
a
methodology
and
a
production system, and solve problems "rationally and systematically," relying on
feedback from developers:
There are two approaches to software engineering. One approach is
to upgrade current development methods by standardizing development
procedures and by improving both programming techniques and the
development environment.
In the other approach,
programs are
directly generated using formal specifications of user requirements,
and this approach involves the application program generator or
automatic programming.
The latter approach is one way of
accomplishing our ultimate goal of software engineering, and if we
narrow the applied field this approach is feasible.
However, it is
very difficult to realize these latter technologies at the present state
of the art, if we apply them generally.
.Therefore, we addressed the
.
47
.
Fujitsu
following items based on the evolutionary approach: 1) clarification of
software development methods and standardization for development
activities,
activities
2)
utilization
tools
of
computerize
to
development
.
For the second, we
We developed SDEM around the first item.
phases after system
support
the
as
a
set
of
to
SDSS
tools
developed
development
is that it is
basic
software
Our
attitude
toward
design...
more desirable to first clarify software development methods and a
software development system, then to approach these problems and
solutions rationally and systematicallv, depending heavily on feedback
from the actual system developers."^
The SDEM methodology was
Manua
l
set
down
outlined the basic standards
Standards Reference Card
listed
four manuals.
in
and development approach.
specific procedures
l
and work items for each
presented more details of each work item and related documents, with
The SDEM Introduction and Application Manual explained
examples.
management techniques and guidelines
system.
The SDEM
The Detailed SDEM Standards
development phase and project-team member.
Manua
The SDEM Concept
The development process
for
introducing
as defined in these
basic
and using the SDEM
manuals divided the
life
cycle into 6 stages and 12 specific phases, from survey and planning through
maintenance and evaluation.
specific
work steps,
major phases
is
as
shown
shown
in
These included
in
Figure 7.3.
a
series of
work categories and
The documentation
flow for the
The Software Factory Department and
Figure 7.4.
programming subsidiaries covered the bottom
half of this process,
and system
engineering departments the upper portion.
48
Fujitsu
it
u
Q
b
O
w
z
M
H
o
l-J
FIGURE
SDEM DOCUMENTATION AND PROCESS FLOW
^urv
.
A major objective
program
design,
SDEM was
of
facilitate
to
and separate system design from
to clarify
division
labor
of
as
exterior
and
specifications
designs
logical
that
improve
as
did
not
rely
on
specific
machines (computers) or languages, whereas program design consisted
physical program, which was machine and language dependent.
system designs separately created
effort
testing
might have
in
all
phases,
be redone,
requirements
from
misunderstandings and errors.
system engineers and programmers
of
and
not meet
SDEM and factory-support
through coding and
There was
Developing the
finished program did
a
if
of the
the entire implementation
On the other hand, use
customer requirements.
tools
to
that
risk
a
the
System design consisted
"flexibility" (portability or reusability) of the designs.
of
well
test,
minimized
between
also extensive interaction
determining the accuracy and meaning of
in
design documents.
Two
tools
that
grew out
of the
SDEM
Analysis).^'
simplify
EPG (Executive Planning Guide) and
the specification and design process were
C-NAP (Customer-Needs
effort to standardize and
EPGII
formalized
a
set
of
planning
procedures and work sheets for designing corporate information-management
systems,
systems
mapping out
already
a
existing
customer's
in
the
needs
company.
specifications necessary to write software,
against
infoi-mation-management
To define more formally
C-NAPII
the
set forth another series of
procedures and work sheets.
SDEM procedures
for quality control
but called for negotiations with customers
allowable
levels
number
of errors
were similar
in
to those
used
determining targets
per 1000 statements."
If
--
at
Numazu
"maximum
early tests indicated
were above target, procedures called for validating the target
levels
bug
and
then instituting countermeasures such as more intensive debugging or program
J
93
redesign
51
Fujitsu
The Factory
which
SDSS,
From SPSS
Tools:
automated
editing and management,
source
programs,
to
aspects
SPAS
documentation
of
compilation
consisted of three elements:
designs,
data,
test
documentation;
such as
language and analyzer containing information
and
file
a
project library for
a
module description
the
name and module
function, interfaces with other modules, and syntax; and test-support tools for
module
Although
and test-case selection.
module path tracing,
analysis,
results
test,
SDSS was gradually supplanted,
used this
Fujitsu
system
set
to
objectives for tool development.
One
of the first tasks, taken on
extend the system
essential as
handle
to
by Murakami and other engineers, was
FORTRAN;
languages other than
more and more applications programs came
Another was
improve
to
the
module description
language
so
became
this
to be written in
that
to
COBOL.
could
it
describe more complicated data structures and be used from the beginning of
the program design phase, rather than from the module definition stage.
objectives were to develop some automatic or mechanized
as well as reuse capabilities,
capabilities,
Other
program-generation
and generate maintenance documents
from source code, using the module description analyzer.
Numazu
provided
solutions
important were the adoption of
code generation.
imported
GEM
For
from
to
YAC
some
these
of
production-control data base,
to
Particularly
flow-charts and then YPS, for editing and
program development and
Numazu,
problems.
serve
as
and ADAMS,
to
a
management,
program
serve as
library
a
Kamata
also
system
and
project-development
data base, with an interface to other tools, the project library, and management
data bases.
^"^
Because
its
basic mission was to produce customized programs,
52
the most
Fujitsu
significant tool-development efforts
research labs,
coding,
and supporting the reuse
of
designs and code
new
Fujitsu called the
selling to its
computer users
and Support
Facilities).
SDAS continued
to rely
in
1987,
on the
developed after 1980.
example,
Fujitsu's
the form of libr-ary
in
and registered packages, which served as program parts for semi-
customized systems.
tools
assistance fiom
with
focused on automating aspects of program design and
central
routines
Kamata,
at
In
which
set of tools,
it
began
also
SDAS (Systems Development Architecture
SDEM methodology but
incorporated
all
new-program development under SDAS,
and C-NAPII
system engineers used EPGII
to
the
for
define the customer
requirements, and then determined where they could reuse applications packages
from the program libraries,
they were or with changes.
either as
Process
planning then centered on how much new code had to be developed, how much
existing software had to be modified, and
SIA
(Systems
programming
in
different
SDAS
(Figure
7.5).
Integration
Architecture)
COBOL, FORTRAN,
tools on Fujitsu
C,
how much could be reused
created
LISP, and
a
standard
PROLOG, and
as
interface
is.
for
for using the
mainframes, office computers, and work stations
The SDAS methodology and
tool
set,
architecture, also facilitated division of labor by making
along
it
with
the
SIA
easier to break up
large programs into distinct units that could be done on different work stations
and then combined
later.
53
Fujitsu
SDAS; Systems Development
Architecture and Support Facilities
Systems Planning Techniqua
Corporal* Systems Planning Technique
Systems Requirement Analysis Technique
(EPG
(C-NAP
II)
OperaUonal
Application Tool
II)
The emphasis on
productivity,
packages
attempt
improve
to
and cost control simultaneously by reusing design and
quality,
know-how incorporated
coding
Fujitsu's
reflected
and thereby
previously written programs,
in
reducing the amount of new designs and code needed to satisfy new customers.
A major
issue,
tailored to
fit
over time.
in
however,
was how
produce packages that could be easily
to
individual user needs, and easily modified as user needs
Fujitsu
s
changed
package design, and some coding,
solution was to keep
the specialized system engineering departments, to take advantage of specific
application-related
or
systems
reviewed
functional
registered
Engineers
expertise.
program
in
libraries
the
in
departments
when
and,
seemed
it
appropriate, modified some of these for genera! sale as packages or for use
semi-customized systems built by Fujitsu or
registration
systems
helped
in
effort.
this
no
its
subsidiaries.
The
in
Two package
largest catalogued
original
1986 and increasing 40% to 50% per
Fujitsu
packages, totalling about 1000
year.
Another library registered software developed by users or computer
dealers, and
in
in
1986 totalled about 300.^9
Figure 7.6 summarizes Fujitsu data on how well these packages covered
Manufacturing systems extended over the broadest range, with
user needs.
larger ones requiring total customization and some systems containing more than
40% existing code from packages.
entirely
by
packages,
companies ^^^
.
Fujitsu
such
Small systems could often be covered almost
as
estimated
the
in
that
case
of
hospitals
and
newspaper
SDAS-based applications packages,
covering financial, manufacturing, distribution, government,
newspaper, and
medical applications, would account for 40% of applications systems delivered
1988.
to
Packages could not accommodate
require
unique features,
all
although
demand, since many users continued
Fujitsu
estimated
that
the
systematic
combination of packages and new code doubled overall productivity.'^
55
in
'
Fujitsu
FIGURE:
PACKAGE COVERAGE RATIO
100
HosaitalS
Distributiort-^
Newspaper
Finance \ '1
r^^~>v.
\
80
60-
Coverage
Ratio (%)
40
i-
Insurance
20
0,1
l.U
10
System Size (million lines of code)
Automated Customization
Developers of the automated programming tools Fujitsu sold as part of the
SDAS
On the one hand, the
and non-experts.
from
engineers
the
tedious
expert programmers,
were serving two groups:
set maintained that they
were supposed
tools
cumbersome
and
computer programs and turn their talent
job
to "free software
writing
of
run-of-the-mill
more creative work.
to
occur because programmers no longer had to compose
in
This would
"
computer languages but
could focus on business problems and write programs "more finely attuned to
the
requirements
On the other hand, SDAS
the end-user."
of
tools
were
designed to "enable computer users to develop their own application software
Hitachi and
without the help of expert programmers."'^'^
capabilities to their customers with
NEC provided
EAGLE and SEA- 1, although
similar
Fujitsu offered
an even broader range of tools.
The motivation
demand
for selling this technology was simple: the high
for
customized programs continuing to outstrip the ability of Japanese firms to hire
and train enough programmers.
In fact,
customers
a
in
1986
indicated
Fujitsu survey of
a
back-log
approximately 2.7 years per company
--
for
systems
its
large-systems
development
which would have been far longer
without reuse of designs and code, and program-automation tools.
In
its
internal
Fujitsu
literature,
presented
an
programming that placed the company's efforts within
research and practice (Figure 7.7).
programming" consisted
readable object languages.
Fujitsu,
Toshiba,
NT&T
--
as
well
'^"^
overview of automatic
a
broader spectrum of
interpretation, "classical automatic
turned computer code into machine-
The "modern" technology
according to Murakami,
and
In this
of compilers that
as
--
represented by YPS
similar systems
in
to
machine-readable code.
57
in
NEC,
Hitachi,
focused on automating the transformation
program design specification
of
step
from
These "program design
Fujitsu
specification
Hitachi,
SPD
compilers"
thus
NEC, and HCP
at
structured
read
(PAD
designs or diagrams
NT&T), and generated code more or
at
at
less
automatically (module interfaces might have to be written manually), usually
COBOL, FORTRAN,
further back
Two
PL/I, or C.
the development
in
life
system planning and design phases.
additional steps were to
cycle,
to
move autotnation
automate part or
Tools such as
Fujitsu's
all
in
Fujitsu
"partially automatic transformation tool."
a
(and
in
many other
firms)
were
tools
At the
that tried
to
of
Software
attempted this through transformation rules defined by the user, and
the category of
in
fell
R&D
the
CAD
into
level
automate the
transformation process through Al techniques.'^
PARADIGM,
issued around 1980 for in-house use and sold since 1981, was
used for business applications software and supported module design, coding, and
testing, as well as software reuse and
the
same
patterns.
concept
as
NEC's
STEPS
program maintenance.
library
routines
and
This relied on
Hitachi's
EAGLE
Users created program parts or patterns, consisting either of fully
coded modules or design specifications (program outlines, module functions,
detailed
flow
charts),
in
COBOL,
using
methodology, and then registered them
grew with each newly designed piece
then accessible through
The
library
systems,
also
a
in
a
standardized
PARADIGM'S
of software.
structured
design
library data base, which
The parts and patterns were
search program that used conversational language. ^
contained
utility
programs
for
use on
multiple
operating
referred to as "black box" components.
58
Fujitsu
Fujitsu claimed that
quality
several ways.
in
PARADIGM
First,
simultaneously imptoved productivity and
reduced man-hours required
it
development through reuse of designs and code.
due
minimal
to
PARADIGM and
required
testing
of
also boosted productivity
It
components.
reused
the
new program
in
Furthermore,
programmers
similar tools "enabled even inexperienced
to write
high-quality programs," and "eliminated misunderstandings due to individual
differences," by making design documents and code easier to read and maintain
due
to high
levels of standardization.
ACS/APG
Generator)
was
(Application
Control
programs from menus that the
portions
of
moderate data-flow
banking
system,
software
a
traffic.
software,
to rewrite
To
that allowed
users to write new
ACS was
COBOL.
actually
a
data-base and data-communications
although
only
it
handled
low
to
deal with high-traffic programs, such as on-line
developed
Fujitsu
Program
System/Application
tool translated into
package that eliminated the need
(DB/DC)
Support
PARADIGM
refinement of
a
^
another
version
ACS,
of
called
AIM
(Advanced Integrated Manager).'^"
Programming sections
in
the Software Factory used
a similar tool,
(Banking Application Generator Library for Extensive Support),
more complex software needed
to control
automated
teller
after several
1985,
generated
that
tool
it
COBOL
in
1980 and
introduced
years of experimentation.
it
the tool
first
Fujitsu began
in
Fujitsu
in
version automatically
but the design process was so similar to actual programming
had to be done by skilled software personnel.
simplified
use
for general
The
produce the
machines or to move
funds among different bank locations through on-line transfers.
developing this
to
BAGLES
In 1986,
however, Fujitsu
and added computer-aided design capabilities.'^
These
allowed even non-software specialists to design new programs through menus
that contained nearly
all
the operations banks performed.
60
Similar to Hitachi's
Fujitsu
EAGLE, NEC's SEA-I, and Toshiba's
BAGLES
application generators,
the menus into machine- readable design documents, and then into
The
COBOL
code.
required factory-type hardware support, however, by occupying two
tool
million
translated
code and using 10 to 15 giga-bytes of mass storage
lines of
generate
to
software that covered 500 to 1400 terminals and 50,000 to 150,000 transactions
per hour.
another related
Still
tool,
CASET (Computer-Aided
Software Engineering
Tool), supported development of relatively simple business applications programs
written
COBOL,
in
information
lists,
consisting largely of relational data-base subsystems and
such as for inventory or sales control.
specifications
by menu
automatically
coded the designs,
document generator
Tools
in
Japanese, the
while
produced
tool
After the user defined
a
program design and
debugging support subsystem and
a
and maintenance.
facilitated testing
PARADIGM, ACS/APG, CASET, and BAGLES were
like
useful for
well-defined applications that could be served by menu-driven design sheets and
libraries of patterns or subroutines.
new applications required
tools that
To automate development
were not
limited to pre-existing designs,
library routines, menus, or development methods.
advanced
tool of this
engineers
Fujitsu
drawing,
.
CAD
and
Software
segments
use
to
of
CAD
was the most
as
"a
general
activities
tool
for
the
software
of
.independent of any particular methods or development phases.
is
a
general tool that developers can customize to
and introduced the
tool
into
areas,
such
as
Kamata
development
61
fit
.
.
particular
Fujitsu completed development during
business applications programs.
other
CAD
transformation
methods for their own circumstances."
1986-1987,
Software
Fujitsu's Software Factory.''"^
in
described
verification,
development.
Software
type used
of software for
in
1987,
initially
for writing
Fujitsu was gradually extending
of
operating
systems,
its
switching
Fujitsu
systems,
communication
(micro-code embedded
and "firmware"
software,
in
semiconductor chips).
The
1987
version
of
CAD
Software
generalize-purpose
used
notations
combining text, tables, and diagrams, as well as an editor and compilers that
transformed standardized notations into modifiable design documents and then
The
different types of code.
describing program structures:
notation
system used
types of objects for
six
forms (graphic models of the program), tables,
nodes (graphic symbols specifying particular attributes of the program), edges
(symbols
representing
between
connections
nodes),
(symbols
inclusions
representing relationships between nodes and edges), and text fields (inputs of
data into any of the objects).
specifications
written
The NS (Notation
by program developers
CAD
editor
Software
for
modification,
CAD Document
and
in
the
finished
format,
specified
These became inputs
produced machine-readable notations.
Compiler took
Specification)
the Software
to
were deposited
portions
and
in
the
Database.
The Software CAD Editor
allowed
the
user
to
access
the
Document
Database and modify any of the objects, relying on menus or templates, as well
as a "mouse" interface
and
a
"multi-window environment."
Transformer used transformation rules specified by the
the documents stored
in
not
simple,
CAD
few days for
still
a
although
The
notation system,
according
to
Fujitsu,
was
a
few hours for an experienced programmer
new employee.
Describing the transformation rules was
relatively easy to learn,
a
user to transform
the database into either executable code or textual
documentation (Figure 7.8).
and
tool
The Software CAD
requiring
Fujitsu
claimed that programs developed with
came out faster than comparable systems done manually.
62
Software
in
Fujitsu
FIGURE
:
OUTLINE OF SOFTWARE CAD
rs
Developer
Text
source codes, etc.
Softuare CAO Editor
Machine
Readab Is
Form
Transformer
Software CAD
Document Database
Transformation Rule
Notation Specification
Tool Developer
R&D
Ongoing
in
Fujitsu
attempted
CAD
and apply Al
techniques with Software
was
approach
to
use
Al
techniques
to
integrate
to
other support tools.
in
process
"knowledge data base" for specific applications,
and
a
made
"knowledge transformation" algorithm.
in
processing the documentation,
subsequent phase
--
into source code.
Fujitsu's
documents
design
using
a
model of the desired design,
a
For example, based on inferences
would produce documents for
tool
planning inputs would produce
which would be processed into
(compiled)
a
intelligence
artificial
a
detailed system design,
a
program design, which would be transformed
a
were especially interested
Fujitsu engineers
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
verify designs.
Inference-search methods were being applied to identifying
software components for reuse.
Other expected Al applications were
in
testing
support and maintenance, such as problem diagnosis.
Factory
systems.
In
applications
1982,
both
of
Al
consisted
mainly
automatic
of
Kamata and Numazu introduced
ATLAS
translation
to translate
manuals and other technical documents from Japanese to English and vice-versa
(English to Japanese became available
Al
system
developed
software development.
it
in
Fujitsu
This was
a
in
1986)
'^
.
Laboratories
In addition,
supported
switching
"knowledge-based system"
withdrew information from flow charts and deposited
an experimental
in
the sense that
this in a data base,
the form of general and detailed state-transition diagram elements.
then
systems
The
in
tool
used inference rules to produce I/O transformations automatically and
generate computer code.
Other
tools
in
trial
expert system for system-engineering consultation.
64
use
in
Fujitsu
included an
1 1 fi
Fujitsu
:
Performance Improvement
Although productivity and quality were
difficult to
and summaries on unpublished in-house studies,
resulted
the
According
significant improvements.
in
SDEM standards
alone brought roughly
a
20*?,
measure, Fujitsu data,
indicated that these efforts
1981
to a
gain
in
productivity (lines of
code per month) over projects not using the new methodology.
came mainly from the "absence
scheduling,
early
discovery
rework,"
of
problems,
of
achieved
adoption of
article,
These gains
through better work
standardization
of
work
and
documentation, and use of formal planning and reviews to reduce differences
between user requirements and finished programs.'''
With
SDEM
place and tool
in
and methodology development continuing,
productivity, according to Murakami, doubled between 1980 and 1984, and after
1984
has
continued
to
rise
about
^b'h
due
annually,
to
increased
use
of
automated program generation and design, as well as automated testing tools.
ACS
alone
doubled
productivity again.
was
reusability,
productivity,
while
ACS/APG and PARADIGM doubled
Directly connected with nominal measures of productivity
which
these
tools
supported.
According
programming efforts using PARADIGM and related
reuse rate of about 40%,
Specific cases
reported
in
compared
internal
rates between 63% and 86% for
to
about 10%
Fujitsu
in
tools
Murakami,
generally achieved
projects that did
literature on
program parts such
to
ACS/APG
not.
cited
a
°
reuse
as graphics control software
and Japanese language processing access routines.
Manual
ACS-APG/PARADIGM
ACS
Productivity
Index
Estimated
Reuse%:
3-4
40%
10%
65
Fujitsu
On
to
a
2000
factory basis, productivity by the mid-1980s was approximately 1500
lines
COBOL
of
code per month,
comments
including
(about
10%).
These numbers, however, excluded system engineering, and included extensive
overtime.
According to
a
former programmer, male employees often worked 70
or 80 hours per week, although women worked less because of legal restrictions.
addition,
In
managers
did
emphasize
not
writing
the
of
programs, but stressed schedule deadlines and correctness.
"elegant"
short,
As
a
result of these
practices, programs tended to be long and lines-of-code productivity high.
On
the other hand, Fujitsu hardware was so powerful that customers rarely noticed
if
programs ran somewhat slow. ^^
Fujitsu
packages
provided
had on
replaced an old
one
specific
productivity.
For
example of
a
the
effect
SDAS
banking customer,
particular
software system that consisted of 3.6 million
and
tools
lines
Fujitsu
of
code.
Existing packages had covered 30% of the old system, and man-months required
for the complete system was 8000.
450 lines of code per man-month,
new code, including time
Thus, there was
able
to
reuse
79%
to integrate the existing
through
gross productivity rate of
including an aver-age of 315 per month for
system was more than twice as large
was
a
programs.
-- 8.3 million
SDAS packages
The replacement
lines of code.
But Fujitsu
securities
processing,
for
customer control, cost accounting, international transactions, foreign 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 had to be newly developed, programmers used the
BAGLES
tools,
which
automatically
generated
code.
productivity was 902 lines of code per man-month,
YPS and
The resulting gross
although only 190
if
one
only looks at the amount of new code developed (Table 7.10 and Figure 7.9).
66
Fujitsu
It
is
possible that reusing so
many packages resulted
in
total
a
system
longer than would have occurred had the software been written from scratch.
Accordingly,
a
with
project
productivity than
high
reuse might
produce higher lines-of-code
program.
This appeared to account for
fully customized
a
some of the high productivity figures reported
tools
appeared
to
reduce length.
Japanese firms, although some
in
Fujitsu claimed,
for example,
that software
produced through BAGLES was actually much shorter than similar programs
written
without the
because,
in
tool
developing
--
on average,
BAGLES,
merely
engineers
1/14th
identified
the
a
This was
size.
large
number
of
repetitious functions that could be handled through subroutines, which could be
cited repeatedly in the
Table 7.10:
program without being rewritten.
BANKING SYSTEM DEVELOPMENT PRODUCTIVITY 122
New System
Old System
8,300,000
LOC
6,550,000
LOC
1,750,000
LOC
System Length
3,600,000
LOC
Reused Code
1,080,000
LOC
New Code
2,520,000
LOC
Total Productivity
450 LOC/Man-Month
902 LOC/Man-Month
New-Code Productivity
315 LOC/Man-Month
190
67
(301,)
(79%)
LOC/Man-Month
Fujitsu
1I
O
O
M
(U
o
o
o
o
o
o
CO
h-
a;
<
a
o
o
PL,
>-l
H
>
M
H
Q
O
di
PM
S
W
H
en
>-i
0:1
O
z
h-l
z
<c
w
Pi
1=1
o
I—
-n
Fujitsu also discovered, as did Toshiba and Hitachi, that there were Mmits
to
the benefits of reusing designs and code,
component or subsystem had
indicated there was
of a particular
In a
a
to be modified.
clear improvement
depending on
In
much
liow
of the
systems software, Fujitsu data
productivity as long as 70% to 80%
in
module or program part was reused without significant changes.
sample of 47 projects, median productivity, including man-power devoted to
maintenance,
was approximately 60% higher with 20% new code and an 80%
reuse rate.
In
without
projects where there were attempts to reuse code but reuse
productivity
tended
programming confirmed
60% for
a
proved
changes
significant
to
be
this
to
1
negative.
be
less
9T
Studies
tendency, showing
given piece of software;
if
than
a
in
impact
the
70%,
applications
on
system
"break-even" point of about
more than 60% had
be newly written,
to
then the impact on overall productivity of attempting to reuse code was slightly
negative.
^^
Software
recycling
CAD appeared
code or
existing
to
improve
designs,
but
productivity
through
transformation of design specifications into code.
easily used for specific tasks,
were impressive.
job-control
total
For example. Software
CAD
The present
the tool also transformed
(ADD
in
a
tool
in
the
was most
limited trials
cut the time needed to convert a
diagram to job-control language from 6 months
to
necessarily
automating
partially
but results reported by Fujitsu
manpower from 9.3 man-months
language
without
0.5 man-months.
to
1
month,
and
Programmers using
database logic structure diagram into programming
one-sixth the time (8.4 man-months to 0.5 man-months).
Other efforts showed similar improvements,
usually cutting development time
one-fourth or one-third, with even larger gross productivity gains, compared to
conventional design and programming (Table 7.11).^^
69
Fujitsu
Table 7.11:
K-LOC
Key:
=
USE OF SOFTWARE CAD FOR TOO L DEVELOPMENT
^
26
1000 lines of cod
MM Man-Months
MH = Man-Hours
mo.= month
=
Software C AD
Development
Time
Improvement
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
Task
Conventional
Job-Flow Diagram to
Job-Control Language
(7.5 K-LOC in C)
9.3
Database Structure
Diagram to ADL
(6.7 K-LOC in C)
Screen Format to
Definition Language
(100 screens)
Screen Transformation to
Programming Language
(10/screen)
Database Structure
Diagram to ADL
SUMMARY
While Fujitsu did not emphasize software process analysis, standardization,
or factory-type organization as early as Hitachi, NEC, or Toshiba, by the early
1980s
had
it
clearly
adopted
factory-type
practices
applications software development.
Huge demand
led Fujitsu to create Japan's largest
network
to
in
both
systems
and
for customized programs also
of software subsidiaries, as well as
develop an impressive collection of reusable code and automated tools that
facilitated customization.
common
to
Table 7.12 summarizes of Fujitsu's activities
in
areas
other software-factory efforts.
70
Fujitsu
Table 7.12:
FUJITSU SUMMARY
FACTORY CONCEPT
IMPLEMENTATION
Strategic Integration
Direction
in
inspection
systems
software
department
and
from
the
software
engineering departments, and in applications
software from the Development Planning
Office
Product-Process Focus
and
Tool
methodology
development
standardization centered on
systems and applications
Scale and Scope
and
two categories,
Systems software centralized
Works, applications software
in
in
Numazu
Kamata
Software Factory and subsidiaries
Improvement, Not Innovation
Process Analysis/Control
Focus on producing
systems efficiently,
development of common
through tool worker
support, and reuse of
IBM-type operating
and simplifying the
applications programs
specialization,
tool
packages
Systematic data collection, standardization
efforts, development planning report system,
and BSMS data base from mid-1970s
Quality Analysis/Control
Systematic
data collection from the late
quality circle activities; Design of
Experiment techniques
1970s;
Central Tool Support
System software
tool
development centered
Numazu Works and
applications tools
Kamata, with assistance from central labs
Training
Laboratory for training established
training program from 1978
in
in
in
1970;
SDEM
Reusability
Extensive investment in package libraries and
accessing reusable designs and code,
such as PARADIGM, ACS/APG, CASET, and
tools
BAGLES
Automated Customization
Reuse-support tools, as well as new systems
such as Software CAD
71
Fujitsu
REFERENCES
Limited, Annual Report
1.
Fujitsu
2.
Nikkei Computer
3.
Fujitsu,
4.
Nikkei Computer
"Numazu
kojo"
13
.
March 1987.
October 1986,
13
,
.
p.
75.
(Numazu Works), undated brochure.
October 1986, pp.
70,
79.
Shimoda Hirotsugu, Sofutouea kojo (Software factories), Tokyo, Toyo Keizai
Shimposha, 1986, p. 82; interview with Yamaji Katsuro, Deputy General Manager,
Software Division, Fujitsu Ltd., 7/31/86.
5.
6.
Shimoda, pp. 81-82.
Fujitsu, "Kaihatsu taisei:
Densanki Jigyo Honbu, Sofutouea Jigyobu"
(Organizational structure. Computer Group, Software Division), unpublished
7.
company document,
1986.
Interviews with Yoshida Tadashi, Deputy General Manager, Quality Assurance
Department, Software Division (Numazu Works), Fujitsu, 7/31/86 and 9/7/87.
8.
9.
Interviews with Murakami Noritoshi, Manager, Software Development Planning
Fujitsu Limited, 9/1/87 and 3/22/88.
Office,
10.
Nikkei Computer
11.
Murakami interviews.
12.
Nikkei Computer
,
,
13
13
October 1986, pp.
October 1986,
p.
70,
79,
and Sliimoda,
p.
82.
80.
13. Fujitsu Ltd., Nyusha no shiori (Guidebook for company entrance). Education
and Training Department, February 1986, pp. 30-32; and Kiriu Hiroshi, Sofutouea
sanqyo no jitsuzo (The state of the software industry), Tokyo, Nikkan Shobo,
1986,
pp. 78-81.
Major sources for the corporate history are Usui Kenji, "FACOM kaihatsu
(History of FACOM development), Computopia
April and May 1975;
Iwabuchi Akio; Fujitsu Kabushiki Kaisha, Fujitsu Kabushiki Kaisha shashi II
(History of Fujitsu, Ltd.), 1976, reprinted in Nihon Shashi Zenshu Kankokai,
Nihon shashi zenshu: Fujitsu shashi, Tokyo, 1977; "FACOM no ayumi" (FACOM
history), FACOM ianaru. Vol. 11, No. 1 (1985), pp. 20-47.
14.
shi"
,
15. Minamisawa Noburo,
Nihon konpyuta hattatsu-shi (History of the
development of Japanese computers) ,Tokyo, Nihon Keizai Shimbuns ha, 1978, p. 145.
16. Iwabuchi Akio, Fujitsu no chosen (Fujitsu's challenge), Tokyo, Yamate
Shobo, 1984, pp. 34-42, 128-129, 198-202; Ogino Yuji etal., "Fujitsu-Hitachi no
shin-konpyuta M shirizu' no senryaku o tettei kyumei"
(A close look at the
strategy of the new Fujitsu-Hitachi M-series' computers), Comput opia, February
1975,
p.
17-18.
72
Fujitsu
17.
Nikkei Computer
Iwabuchi, p. 93;
Usui, Computopia
1985, p. 10.
18.
,
May
.
13
October 1986,
p.
01.
1975, pp. 17-18; J apan Economic Jo urnal, 29 January
no ayumi" (FACOM development), FACOM ianaru Vol. 11, No. 1
20-47; and Fujitsu Kabushiki Kaisha, "FACOM seino ichiran"
(Overview of FACOM performance) in Ikeda kinen robun shu (Anthology of
articles in memory of Ikeda), Tokyo, 1978, pp. 254-267.
19.
"FACOM
(1985),
20.
.
pp.
Ogino, pp. 30-31.
21.
Datamation 1 June 1985, p. 60; The Wall Street Journa l, 12
7 June 1986, p. 15.
p. 18; Japan Economic Journal
,
November
1985,
,
Interview with Fujitsu Managing Director Miyoshi Mamoru in
bijinesu no mirai" (The future of the software business) Computopia
pp. 85-87.
"Sofutouea
22.
,
23.
Fujitsu Limited,
Annual Report 1983 and Annual Report 1984
,
April 1986,
.
Fujitsu, Information Processing Group, No. 1 Software Division, "Sofutouea
kaihatsu: hinshitsu-seisansei kojo ni tsuite" (Software development: quality and
productivity improvement) unpublished company document, received 9/24/85, p.
24.
,
3.
25.
"Sofutouea kaihatsu," pp. 40-41.
26.
Nihon Keizai Shimbun
5
,
August
1987,
p.
9.
David Lammers, "Sigma: Japan's Effort to Close the Software Productivity
Gap," Electronic Engineering Times 21 July 1986, p. 9.
27.
,
28.
Murakami interviews.
Kawaguchi Izawa, "Shoki no shisutemu sofutouea:
FONTAC 8040 MONITOR
no kaihatsu made o chushin to shite" (Early systems software: focus on period
through the FONTAC 8040 MONITOR development), Jolio shori Vol. 24, No. 3,
March 1983, pp. 225-237; Usui (May 1975), pp. 20-21.
29.
.
Okamoto Akira, "MONITOR-V shisutemu no omoide" (Recollections of the
system), in Kyoto Daigaku Ogata Kensanki Sen t a 10-nen-shi pp.
224-229; Fujitsu shashi II
p. 104; Usui (May 1975), p. 25.
30.
MONITOR-V
,
,
31.
Iwabuchi, pp. 44, 221-222.
32.
Okamoto, pp. 224-229.
33. Yamamoto Takuma, "Opereteingu shisutemu kaihatsu no omoide"
(Recollections on operating system development), in Kyoto Daigaku Ogata
Keisanki Senta, ed., Kyoto Da ig aku Ogata Kensanki Senta 10-nen-shi (A 10-year
history of the Kyoto University Ogata Computer Center), Kyoto, Kyoto
University, 1980, pp. 217-219.
73
Fujitsu
,
34.
Uemura Mitsuo, "Sofutouea kaihatsu no omoide" (Recollections
development),
in
Kyoto Daiqaku Ogata Kensanki Senta 10-nen-shi
,
of software
pp. 230-236.
35.
Ogino, pp. 30-31.
36.
Tabata Akira, "Kihon sofutouea no kaihatsu" (Basic software development),
FACOM
ianaru
.
Vol.
11,
37.
Shimoda, p. 73.
38.
Shimoda, pp. 73-76.
No.
1
(1985),
p.
54.
39. This discussion is based on Yoshida interview, 9/24/85, and "Kensa-bu no
rekishi" (History of the inspection department), internal Fujitsu memo, prepared
by Yoshida.
40. Fujitsu Ltd., "Kensa-bu no rekishi" (History of the inspection department),
internal Fujitsu memo.
41.
"Sofutouea kaihatsu"; and Yoshida interviews.
42.
Yoshida interviews.
Morita Shoken and Kanda Shigeru (Fujitsu, Ltd., No. 1 Software Division,
Inspection Department), "Sofutouea hinshitsu no toraekata" (Ways of looking at
software quality), Hinshitsu Vol. 14, No. 2 (April 1984), p. 91.
43.
.
Tadashi Yoshida, "Attaining Higher Quality in Software
Evaluation in Practice," Fujitsu Scientific and Technical Journal
(July 1985), p. 306.
Development--
44.
45.
"Sofutouea kaihatsu," especially pp. 7-10.
46.
Yoshida interviews.
,
Vol. 21, No. 3
Fujitsu, Computer Group, Software Division, "Sofutouea no hinshitsu kanri"
(Software quality control) unpublished company document, 11 September 1985, p.
6; and "Sofutouea kaihatsu," p. 6.
47.
,
This discussion is based on Nihon Noritsu Kyokai (Japan Management
Association), Fujitsu no ko-shinraisei undo (Fujitsu's High-Reliability Movement)
Tokyo, Nihon Noritsu Kyokai, 1985, especially pp. 144-176.
48.
49.
Yoshida, "Attaining Higher Quality
Practice," p. 305.
in
Software Development
--
Evaluation
in
50.
Yoshida, "Attaining Higher Quality
Practice," p. 305.
in
Software Development
--
Evaluation
in
Yoshida, "Attaining Higher Quality
Practice," pp. 308-309.
in
Software Development
-
Evaluation
in
51.
52.
"Sofutouea kaihatsu," p.
15.
74
Fujitsu
Keizo Tatsumi (Quality Assurance Department, Computer Software
Development Group, Fujitsu Limited), "Test Case Design Support System,"
International Conference on Quality Control, Tokyo, October 1987, pp. 1-2.
53.
Also, citing Taguchi's 1976 book in Japanese, is a more detailed article on
See Sato Shinobu and Shimokawa Haruki,
these methods used in Fujitsu.
"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 in
1983.
software). No. 4, ca
54.
.
Yoshida, "Attaining Higher Quality
Practice," pp. 314-315.
55.
56.
Murakami interviews.
57.
"Sofutouea kaihatsu," pp. 37, 44.
58.
Yoshida interviews.
59.
Fujitsu
in
"FACOM
Kabushiki Kaisha,
Software Development
--
Evaluation
in
M-shirizu OSIV/X8 FSP," pp. 171-173.
"SDAS: Application Software Development Made Easy," Electronics News
from Fujitsu, July 1987, p. 2; Yoshida interviews; and "Sofutouea no hinshitsu
kanri," p. 16; and Yoshida's 2/8/87 written response to 1/20/87 Cusumano
questionnaire on "Large-Scale Systems Software." Yoshida believed that a major
reason U.S. firms have not refined flow chart systems to this extent was
because, for native speakers of English or similar languages, writing in a highlevel computer language is close to their native language.
But, for Japanese
this was not the case, and YACII, PAD, or SPD diagrams could be written in
Japanese, making them easier for Japanese programmers to use.
60.
61.
Yoshida response to questionnaire.
62.
Yoshida Tadashi, "Sofutouea no keiryo-ka" (Software quantification), Joho
Vol 26, No.
(Januar-y 1985) p. 49; and Yoshida
shori (Information Processing)
interviews.
,
63.
"Sofutouea kaihatsu," p. 29.
64.
Yoshida interviews.
65.
"Sofutouea kaihatsu," p. 30.
66.
Yoshida interviews.
67.
"Fujitsu," Computopia
68.
Usui, Computopia
69.
Fujitsu Kabushiki Kaisha shashi
70.
Nikkei Computer
.
,
,
May
13
1
.
June 1975,
1975,
p.
,
92.
pp. 25-26.
II
.
October 1986,
75
pp.
p.
102-103.
82.
Fujitsu
.
71.
Nikkei Computer
13
,
October 1986, pp. 81-82.
for chart, Nikkei Computer
13 October 1986, p. 79; for 1988
Sources:
employee totals, author estimates based on 1986 data and 1988 Murakami interview.
72.
,
73.
Murakami interviews.
74.
Shimoda, p. 74.
75.
Murakami interviews.
76.
Murakami interviews.
Interview with Sakurai Hiromi, former programmer (1981-1983), Distribution
Systems Group, Software Factory Department, Fujitsu Limited, 5/4/88.
77.
78.
Murakami and Sakurai interviews.
79.
Murakami and Sakurai interviews.
80.
Sakurai interview.
81.
Sakurai and Murakami interviews.
Noritoshi Murakami, Isao Miyanari, and Kazuo Yabuta, "SDEM and SDSS:
Overall Approach to Improvement of the Software Development Process," in H
Hunke, ed.. Software Engineering Environments, Amsterdam, North-Holland,
82.
1981,
p.
288.
83.
Sakurai interview.
84.
Murakami interviews.
85.
Murakami and Sakurai interviews.
86.
Nikkei Computer
.
13
October 1986, pp. 80-81.
Yoshiro Nakamura, Ryuzo Miyahara, and Hideshi Takeuchi, "Complementary
to the Effective Software Development," Proceedings of Computer
Software and Applications Conference (COMPSAC78)
New York, Institute of
Electrical and Electronics Engineers (IEEE), November 1978, p. 236.
87.
Approach
,
88.
Nakamura
et a!.,
p.
89.
Nakamura
et al.,
pp. 235-236.
90.
Murakami
et al.,
pp. 284-286.
91.
Murakami interviews.
236.
Nagata Yuzuru, Mori Kuniaki, and Takahashi Tomio, "Shisutemu keikaku giho
EPGII to C-NAPII" (System Planning Methodologies EPGII and NAPII), Fujitsu.
Vol. 39, No. 1 (January 1988), pp. 13-20.
92.
76
Fujitsu
Murakami etal., pp. 286-287; Watanuki Hisaslii, Hatta Makoto, andOkudaira
Hajime, "Apurikeshon puroguramu kaihatsu toki no hinshitsu kanri" (Quality
Control for Application Program Development,
Fujitsu, Vol. 34, No. 6 (1983),
pp. 857-865.
93.
94.
Murakami
pp. 289-293.
et al.,
Noritoshi Murakami and Tomio Takahashi, responses to Cusumano surveys on
"Large-Scale Applications Software" (1/19/87) and "Software Facilities" (9/87).
95.
Akiyama Masayuki and Nishimura Shuji, "SDAS ni okeru pakkeji kaihatsu to
sono tekiyo gijutsu" (SDAS Improving Package Development and Its Application
Methods), Fujitsu, Vol. 39, No. 1 (January 1988), pp. 36-41.
96.
97.
Akiyama and Nishimura.
98.
Murakami interviews.
99.
Nikkei Computer
,
13
October 1986, pp. 81-82.
100.
Akiyama and Nishimura.
101.
"SDAS; Application Software Development Made Easy," Electronics News
from Fujitsu
102.
,
July 1987, p. 3.
"SDAS: Application Software Development Made Easy," pp.
1-2.
Fukuta Zenichi, Yoshihara Tadao, and Maruyama Takeshi, "SDAS sogo
shisutemu no teisho" (SDAS Systems Development Architecture and
Support Facilities), Fujitsu, Vol. 39, No.
(January 1988), p. 3.
103.
kaihatsu
1
104. Murakami and Takahashi survey responses; "SDAS: Application Software
Development Made Easy," p. 2; Murakami interviews.
105.
Murakami interviews.
106.
Fujitsu Kabushiki Kaisha,
107.
"Sofutouea kaihatsu," p. 42.
108.
"FACOM
109.
Murakami interviews.
"FACOM
M-shirizu 0SIV/X8 FSP," pp. 193-194.
M-shirizu 0SIV/X8 FSP," pp.
193-194.
110. Fujitsu Limited, "BAGLES kaihatsu no keiro" (The process of
development), unpublished Fujitsu document, 20 March 1986.
BAGLES
Ueki Sadahiro, Miyauchi Kazuto, and Nakada Haruyoshi, "Koseisansei tsuru
tool CASET), Fujitsu, Vol. 39, No. 1 (January 1988),
pp. 21-28.
111.
CASET" (High-productivity
"Fujitsu Software: Banking
February 1985, pp. 63-64.
112.
to Realtime," Electronic
77
Engineering Times,
11
Fujitsu
:
Kazuo Yabuta, Akihiro Yoshioka, and Noritoshi Murakami "Software CAD'
Environment for Graphical Software Development Techniques,"
Generalized
A
COMPSAC87 pp. 1-8.
113.
,
.
114.
Murakami interviews.
115. Fujitsu, "System for Supporting Software Development (for Switching
Systems Software)," internal document, 1977; Murakami interviews.
116.
Murakami interviews.
117.
Murakami
118.
Murakami interviews.
119.
"Sofutouea kaihatsu," p. 43.
120.
Sakurai interview.
121.
"Fujitsu Software:
et al.,
pp. 287-288.
Banking
to Realtime," pp.
G3-64.
Fukuta Zenichi, Yoshihara Tadao, and Maruyama Takeshi, "SDAS sogo
shisutemu no teisho" (SDAS Systems Development Architecture and
Support Facilities), Fujitsu, Vol. 39, No. 1 (January 1988), p. 11.
122.
kaihatsu
123.
Yoshida, "Sofutouea no keiryo-ka," pp. 48-51.
124.
Akiyama and Nishimura,
125.
Yabuta, Yoshioka, and Murakami, pp.
126.
Yabuta, Yoshioka, and Murakami, p.
C
I
I
7
U 7 8
p.
38.
^s
1-7.
7.
''"''*^"
Date Due
f£B2o
m]
Lib-26-67
Wn
3
LIBHAHIt
^DflQ DDS 351
D33