\
*\
ifT'Tvi
n ^1*5
1S88
•FB 5
L!'r>p
ALFRED
NEC:
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
Standardization Strategy for a Distributed
"Software Factory" Structure
Michael
November 1987
A.
Cusumano
WP //1954-87
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
f^rr
\
^
NEC:
Standardization Strategy for a Distributed
"Software Factory" Structure
Michael A. Cusumano
November 1987
WP //1954-87
ir'EB
5 1988
RECEiVEO
Michael A. Cusumano
Sloan School of Management
8
November 1987
Software Project Paper #5
NEC: STANDARDIZATION STRATEGY FOR A DISTRIBUTED
"SOFTWARE FACTORY" STRUCTURE
INTRODUCTION
This paper
is
part of
a
larger study examining the question of whether or
not companies are choosing to
manage
large-scale software development with
organizational
as
as
well
a
complex engineering activity such as
a
range of strategic considerations and
approaches that corresponds
technological
spectrum usually associated with "hard" manufacturing,
i.e.
job shops,
organizations, and factories exhibiting various degrees of flexibility
mixes
The research
and technologies.
project
technology and policy criteria defining what
might look
like;
a
survey
the
includes
a factory
in
relation
in
the
batch
product
proposal
of
environment for software
of major software facilities in the U.S.
determine where firms stand
to
to these criteria;
and Japan to
and detailed case
studies examining the technology and policy implementation process followed at
firms identified as being close to the factory model.'
There are several interrelated conclusions:
"factory" approaches,
the U.S. and Japan.
is
(2)
(1)
This spectrum, including
clearly observable in the sample of software facilities
There appears
to
be nothing inherent
in
software as
in
a
technology that prevents some firms from creating strategies and organizational
structures to manage product and process development more effectively, even
with a relatively new and complex technology such as software.
technological
infrastructures
to
aid
software
process
(3)
The
basic
management are not
significantly different between Japanese and U.S. firms. (4) But, Japanese firms
-- led
by the NEC group and Toshiba, and followed by Hitachi and Fujitsu--
1
significantly
are
ahead of most
U.S.
competitors
implementing
in
"flexible
factory" type of strategies focused on reusing standardized components (modules
of code)
and then customizing end products.
This paper extends the survey approach to analyze what
--
most difficult aspect of the software factory
is
probably the
the implementation process and
the benefits or disadvantages this environment might offer
in
NEC
adopted
case
significant for the following reasons.
is
One,
it
operation.
The
software
a
factory strategy around 1976, but, unlike Hitachi or Toshiba, did not attempt to
construct
single major facility and use this as the main site for developing
a
Rather, top management at
factory tools and methods.
committee
and then
laboratory
organization
to
NEC used
the
direct
a
centralized
development
and
dissemination of factory-like software tools, standards, procedures, and control
methods among
all
the divisions and subsidiaries writing programs.
This approach appears to have reflected NEC's organization around product
divisions rather than factories, as
Toshiba.
It
has also led to a
in
the case of Hitachi and, to some extent,
remarkably high
level
of
standardization and
consensus regarding software development despite NEC's production
types of software,
of various
including telephone switching and transmissions systems,
computer operating systems, and business applications programs.
The organization
of
NEC and
detail
top
its
of this
is
as follows:
Part
I
presents an overview
development of the computer business, and then discusses
management's
organization
paper
factory
implementation
in
strategy
terms
of
for
software
divisional
development
structures,
in
and
committee
programs, R&D organization, corporate-wide programs, and subsidiaries
.
Part
II
focuses on the tools, methodologies, and management-control systems developed
to
support the factory
comparisons of
NEC
strategy.
to other
The conclusion makes some preliminary
Japanese and U.S. firms, as
well as offers several
suggestions about the general lessons regarding technology management that can
be drawn from this study.
I.
SOFTWARE-DEVELOPMENT STRATEGY AND ORGANIZATION
Corporate History
NEC was founded
1899 as
in
a
venture between two independent
joint
Japanese businessmen and AT&T's Western Electric subsidiary,
and import telephone equipment.
It
later
of electronic
and electric components and products.
multinational
corporation
organized
electronic
within
a
nine
systems
in
(including
1987
groups
(41%
of
1986
covering
sales),
As
a
consolidated
range of product divisions.
operating
manufacture
became an independent company
Sumitomo group and, over time, expanded
affiliated with Japan's
revenues came from
to
into a variety
$16.8 billion dollar
subsidiaries),
Each was
computers
communications
a
NEC
profit center
and
industrial
(switching
and
transmission systems as well as radio and microwave) products and services
(29%),
semiconductors and other electron devices (17%), and home electronics
(8%). 2
NEC OPERATING AND MARKETING GROUPS.
Operating Groups
Research and Development
Production Engineering Development
Switching
Transmission and Terminals
Radio
Information Processing
Marketing Groups
NT&T
Sales
Government Sales
Domestic Sales
International Operations
Advertising
Electron Devices
Home Electronics
Special Projects
Source:
NEC
Corporation, "This
is
1986
NEC, 1986,"
p.
9.
Toshiba, and Fujitsu,
Like Hitachi,
and software development,
earliest
producers
scientific-use model
of
computer technology, NEC entered
in
1962, through which
NEC
cooperate
1970s as
By
1986,
NEC
in
a
long history of computer
NEC was one
in
the world,
into a licensing
its
of
completing
sale
under the
hardware and software design technology.
relationship continued
1979 and the two companies
until
started supplying mainframe hardware to
manufacturers, ranking, among Japanese firms,
sales,
and second
its
in
the
American partner."^
largest computer and software
clearly one of the world's
and data communications
a
arrangement with Honeywell
marketing, the technology transfer situation reversed
NEC was
the
to the United States in commercial
manufactured Honeywell computers for
Japan and upgraded
label in
While this technical
still
it
computer
To catch up
1958.
in
has
dating back to the 1950s.
transistorized
a
NEC
first in software,
microcomputer,
mainframe sales, behind Fujitsu.
in
Early Learning and Technology Transfer
NEC's history
of
computer development
in-house efforts, beginning
in
is
a
combination of independent,
the mid-1950s, with hardware design and some
software technology acquired from Honeywell
in
The key figure
the 1960s.
in
software development from NEC's very earliest efforts has been Mizuno Yukio,
who entered the company
in
1953 after graduating from the
Tokyo
Technology, where he also received an engineering doctorate
Mizuno was
The
1956,
a
first
senior vice-president
programming efforts
in
in
charge
message and accounting data sorter for
to Mizuno,
built an analog
a
1960.
In
1987
of software strategy.
NEC, according
when he and several other engineers
in
Institute of
were
in
1955-
computer and then
non-stored program machine
--
a
a
.
computer that was,
programs for storage
NEC completed
commercial sale
in
memory
NEAC
the
The NEAC
1959.
in
--
and the 2203,
1958,
in
an
2201,
a
required
transistorized computer
enlarged version
2201 and 2203 prompted
establish a programming section in 1959,
and
Their next project
"hard-wired."
essentially
introduced for
NEC managers
including Mizuno
with 26 engineers,
who had
leading Japanese computer experts at that time, Okazaki Bunji,
a
joined
NEC
after
Film.
One
of their first
to
building one of Japan's first electronic computers for Fuji
accomplishments was the completion of Japan's first
compiler."'
Honeywell machines supplanted the
Several
These gave way after 1965
repackaged versions
to
NEAC
the
of three small
NEAC
2200
models
in
which
series,
1962-1963.
contained
and medium-size mainframes Honeywell had
designed to compete with the IBM 1400, as well as several larger machines NEC
designed independently to compete more directly with the IBM 360 family.
ACOS
beginning
series
mainframes
NEC's basic product
remained as
2200 series
in
1974,
to
line
compete
NEC introduced
until
with
IBM's
a
decision
of
led
NEC
in
1965 to
dubbed the NEAC
build a large-scale computer for the Japanese market -- later
--
family
the
c
Despite the technical arrangement with Honeywell,
2200-500
370
The
not only to use integrated circuits (ICs), printed circuit
boards, and large-capacity core memory for the first time, but also to develop
independently an advanced operating system capable of on-line processing and
time
sharing
similar
to
Institute of Technology.'
technical
and
the
Multics
system developed
at
the Massachusetts
The hardware and software tasks presented major
organizational
challenges
to
NEC
engineers,
who had never
tackled such extensive projects, and did much to advance the technical skills of
company personnel
in
both areas.
°
^
The 2200-500 machine was based on
1964
in
NEC's
at
research
central
a
computer factory
Fuchu,
at
laboratories.
commercial model,
processing unit into
in
hardware design project completed
a
in
To develop the central
NEC management
1964
the outskirts of Tokyo, and
established
1965
in
a
computer
development group with about 30 engineers, including Mizuno as head
arguing that
its
models were adequate and that the software for
the proposed 500 would be too difficult to write.
Honeywell executives,
in
of the
Honeywell managers tried to dissuade NEC from taking on
programming section.
this project,
a
NEC completed
Much
the surprise of
to
the machine and operating system on time
1968 -- delivering the 2200-500 to Osaka University and receiving an award
from the Nikkan Kogyo Newspaper for having developed Japan's
system and entered into
machines.
NEC
Honeywell thereafter brought
computer.
a
formally into
its
first
IC-based
product planning
NEC
cooperative development program with
for future
Q
The operating system
for the 2200-500,
named MODE
NEC provided about
directly after the IBM 360.
NEC patterned
IV,
90% of the engineers working
on the system; Honeywell contributed some 10%, who came to Japan and worked
under Mizuno
how
Tokyo.
in
to plan for
Honeywell was quite helpful
and control such
a
in
teaching
NEC managers
large software project, although Mizuno was
disappointed to find that the Americans' level of technology regarding bug,
and productivity estimation was
cost,
forecasting led
models
during
control at
NEC
NEC managers
the
in
A major step
1970s,
low.
to collect their
which
1971
for
improvement
in
own data and devise new planning
became the basis for software production
the 1980s.
in
standardization of control methods as well as of tools and
development procedures was the creation of
in
The need
and then the decision
to build a
a
new computer development group
new operating system
for the
ACOS
This decision led to the separation of basic software (operating systems
series.
and related programs)
Fuchu
into an
From
plant.
1974,
independent division
Fuchu
the
plant,
hardware and operating systems, was referred
1974,
in
centered
at
the
produced mainframe
which
NEC
to within
"software
as a
factory," and became the center of software technology development until the
establishment of
a
separate laboratory for this purpose
At this point
1980.
in
the information processing group contained separate divisions for basic software
centered
at
Fuchu, and,
the Mita section of Tokyo, near
in
large-scale customized
for
software
NEC headquarters,
and user
(system engineering projects)
(business) applications software.
Unlike
Hitachi
and Fujitsu,
NEC's software development tasks did not
NEC thus continued
include trying to be compatible with IBM.
Mizuno
IBM compatible Honeywell operating system.
in
and Unidata
the U.S.
machines and then failed
NEC
to
still
customers.
a
limit to
Thus, even though he was head
of
IBM-compatible
of
its
machines to attract
product planning,
NEC headquarters
in
1974 Mizuno
Fuchu plant and spent
to the
three years directing the new operating system development effort.
IBM's 370 operating system did not have
was not well set up
to handle data bases,
add these functions
machine capability.
to
It
their
language, HPL,
was
still
a
the
new system,
difficult,
as
NEC managers decided
as
well
^"^
a
a
in
to try to
"task-level"
virtual
sophisticated operating
although they succeeded, using
PL/I subset, to write the system,
using assembler.
Because
strong time-sharing capability and
a
turned out that developing such
system was extraordinarily
RCA
the compatible" approach.
had to offer competitive performance with
moved from the comforts
build
to
because
match IBM's subsequent 370 models, he and other
executives decided "there had to be
But NEC
recalls that
Europe had both tried
in
with the non-
a
high-level
contrast to IBM, which
For
future
product development,
One was the
significance.
programming methods and
two events
decision
to
to
and
tools
methodology for newly written application and system programs.
the
decision
to
create
NEC
beginning with
President
of
NEC's
Mizuno),
centered
Software
in
Parts
addition
in
to
Company
being
each division.^''
thus became the basis of
"software factory"
technology,
that
structured
in
based
on
this
Another was
"^
development,
software
in
long-term
Software, Ltd., and to recruit software houses to serve as
procurement departments
NEC Software
specialized
Subsidiaries and affiliated
subcontractors.
members
subsidiaries
had
programmers
train
standards
design
1975
in
scheme,
Mizuno and
Association
subject
to
(headed
controls
by Vice-
imposed
by
The Fuchu Software Factory and
geographically distributed, product-
a
based around structured programming
NEC manager,
another
promoting more aggressively from 1976.
software houses also became
1
c
"
Fujino
Kiichi,
began
NEC SOFTWARE ORGANIZATION AND SUBSIDIARIES,
Information Processing
Basic Software
Group
Main Factories
Fuchu
System Engineering
Mita
Other Divisions
Transmission
Tamagawa
Switching
Abiko
Domestic Software Subsidiaries
NEC Software
NEC Information Service
Nippon Electronics Development
Nihon Computer Systems
NEC Communication Systems
NEC Engineering Information Systems
Kansai NEC Software
Chubu NEC Software
Kyushu NEC Software
Tohoku NEC Software
Hokuriku NEC Software
Chugoku NEC Software
Hokkaido NEC Software
Shikoku NEC Software
NEC Security Systems
Shizuoka NEC Software
Okinawa NEC Software
NEC Microcomputer Technology
NEC Engineering
NEC
NEC
NEC
NEC
NEC
IC-MicroComputer Systems
Telecom Systems
Koku-Uchu (Aerospace) Systems
Robot Engineering
Ocean Engineering
Note:
ca.
1986-87
Software Employees
2,000
2,500
1,500
1,500
2,100
900
1,000
800
800
150
500
300
200
100
na
na
na
na
na
na
na
na
na
na
na
na
na
na
employee figures are estimates by the author. An approximate
for the number of software engineers and programmers in
the NEC facilities and subsidiaries noted above is 16,000.
All
total
Sources:
NEC, Konpyuta sangyo no qeniyo to NEC (1985); Joho shori:
sofutouea kaisha roku (1985); Kiriu Hiroshi, Sofutouea sanqvo no
iitsuzo (1986); Nikkei konpyuta, 13 October 1986, p. 89; company
data; author estimates.
Software Factory Strategy
Mizuno began discussing
NEC's software strategy evolved gradually.
publicly his view of the software factory as early as an October 1975 article
in
Then the manager
of
a
leading Japanese journal on information processing.
NEC's
Software
Basic
had
industry
therefore,
he
evolved
felt
Development Division,
to
he
stressed
where cost and quality mattered
producers
had
move beyond
to
the
that
to
"individual
"
software
customers,
or
"craft"
approaches to production, and develop "modern" engineering and manufacturing
practices and tools:
As the use of computers has become more diverse and at higher levels,
software -- quantitatively and qualitatively -- has become increasingly
Thus, software is no longer the individualistic, craft-like
important.
once
was; there is evidence that it has become a modern
product it
Accordingly, we
product with a market value and market distribution.
have reached the point where the development process for software must
move beyond the individual or craft stage to a more rational, modern
Namely, we have reached the age where there is a
production system.
.
.
strong demand for high quality, maintainable software as
software cost reduction and productivity improvement...
well
as
for
consciousness of software as a highly modern and major
extremely low among both software producers and users.
The result is a tendency to pay too little attention to software inspection
or quality assurance, and not to invest enough time and resources in the
software development and production process...
In
general,
product
is
still
It seems we have reached the stage where current methods for software
production, which resemble a cottage industry, may be moving toward
'manufacture' (factory-method industry)... [But] the tools used at the
present for software development -- paper, pencils, machines, basic
language processors -- are extremely primitive.
To improve productivity in
software development, to produce software of higher quality, it is
necessary to go beyond cottage-industry type production methods. This
higher level of technology for the software production process can be
referred to by the term 'software engineering.' ''
.
This 1975 article, published only
Corporation
in
a
.
few months after System Development
the U.S. released information describing
its
"Software Factory"
project, elaborated on the concept of a physically distributed software factory
system using standardized procedures, tools, and components, with time-sharing
10
capabilities
link several
such as Fuchu, Tamachi/Mita, and Shinjuku
sites,
in
Mizuno estimated that, with factory-type standardized methods and
Tokyo.
productivity should rise from 2 to 5 times.
tools,
Several
basic
and
concepts,
tools,
systems,
necessary to support successful implementation of
First,
was the development
of
a
Mizuno's
in
view,
were
software factory system.
expandable, versatile high-level languages suitable
for system description using structured
programming methods.
Second, was the
use of structured programming techniques such as the top-down approach,
abstraction
reduction
of
techniques,
GO TO
standardization
standardization
statements
the
of
segmented
coding,
in
subroutine
of
of
introduction
listing
input/output
production
process,
industries, to improve productivity and quality:
process,
increases
through Taylor's methods,
in
productivity.
structures,
program modules,
Third,
been
achieved
in
or
was
other
"In the average production
standardization of tasks led to dramatic
the same way,
In
of
layers
interfaces.
had
as
and
standardization
in
the software
development process of the construction flow and documentation should make
possible to improve productivity.
development-process control.
claimed
checkpoints
table).
add
would
and
Fifth,
system for
some
reviews
Mizuno
quality
felt
Fourth, was
Mizuno offered
visibility
of
standardization should help reduce
In addition,
careless mistakes and increase reliability."
to
the
a
system for software
"phase-plan" system, which he
a
development
standardized documentation
In
addition,
he
process
each
for
the software factory should have
assurance.
it
a
identified
through
step
(see
comprehensive
nine
elements
fundamental to the technological infrastructure of an effective software factory
(see tables).
""S
11
MIZUNO'S INITIAL SOFTWARE FACTORY CONCEPT
METHODOLOGY AND MANAGEMENT
1.
High-level structured programming language for system description
2.
Disciplined structured programming and top-down modularization techniques
3.
Standardization of the development process
4.
System for process control
5.
System for quality assurance
TECHNOLOGY
1.
(High-Level) Language processing
2.
Program and data commonality
3.
On-line memory and control of program components and information units
4.
Simple system for integrating parts of programs being developed separately
5.
High-reliability
6.
High-level virtual
7.
Suitable development language and program control function
8.
"Boot-strap" function (capability of testing software developed in the
factory in the actual mode or o.i the actual machine it will run on, to
ease transfer)
9.
Tools for debugging,
continuous operation.
file
system
memory
dynamic
link
Source: Mizuno 1975, pp. 837-838.
12
functions,
project
control,
and
PHASE-PLAN SYSTEM
Phase
0:
PLANNING
Determination of product based on market
development costs, and technical capabilities
Definition:
Documentation
:
I:
BASIC DESIGN
Analysis of the objective of the planned project and
establishment of programming objectives
Definition:
Documentation
:
II:
Basic Design Specifications
Performance, Cost
Review:
Phase
Planning Specifications
Schedule, Cost
Review:
Phase
needs,
DETAILED DESIGN
Design of detailed functions and structure based on the
Definition:
programming objectives
Documentation
:
Cost,
Review:
Phase
III:
Functional Specifications (Language Specifications)
Logic Specifications
Manual Draft
Functions
IMPLEMENTATION
Coding and debugging
Definition:
of each
component based on the
detailed design
Documentation:
Programming Completion Document
User Manual
Review:
Schedule, Cost, Functions
Phase IV:
SYSTEM INTEGRATION
Test of debugged modules
Definition:
Documentation
combination
System Integration Test Document
Performance
Review:
Phase V:
:
in
INSPECTION
Definition:
Examination of whether the completed system meets the
planned specifications
13
:
Inspection Completion Document
Release Announcement
Documentation
MAINTENANCE
Phase VI:
Definition:
Support and Improvement
Documentation:
Program
Lists
Internal
Documents
of
completed system
Source: Mizuno 1975, p. 838.
As they made progress
changed emphasis
to quality
NEC managers
process standardization,
in
and reusability
control
improve overall productivity.
This shift
code as key ways to
of
thinking can be seen
in
where Mizuno discussed the two components
interview,
achieving continuous increases
in
productivity:
gradually
of
his
in
a
1986
strategy for
(1) a rigorous quality control
program
to
prevent errors, which become
program
is
released to the customer; and (2) "accumulation of knowledge" about
software
and
engineering
passing
this
difficult
on
to
and expensive
others
through
to fix after a
reusable
(a)
software modules, (b) reusable program patterns, and (c) bug or failure analysis
and the development of better test rules and check points.
known
as "Software Engineer's
Mizuno considered
programming
tool
a
"first
SEA/I (alternately
Arms" and "System Engineering Architecture")
step"
in
the
development
of
an
Mizuno
Thus,
using this "accumulation of knowledge" concept.
building upon process standardization and control as the foundation of
approach,
automatic
now explained the software factory
as
a
a
factory
"concept"
for
maximizing the "accumulation of experience" and capturing this experience
in
control systems, tools, and process inputs (reusable code or designs):
The term
'software factory' does not indicate a physical building.
method of producing software, or the tools used in
example a control system. The software factory refers
14
It
is
a
this method, for
to the integration
of these types of things.
It
must be understood as
concept.
a
Another point that should be emphasized is that it is important for a
software factory to be a place where systems are introduced that
incorporate the experience of people who have made software in the past
with new methods or particularly effective techniques.
It
is
an
Even if it doesn't go as far as a knowledge
accumulation of knowledge.
data base, it should be something where there is an accumulation of
knowledge.
For example, in coding inspection, a particular group keeps making
mistakes in register manipulation. Or they forget to close a table.
In a
software factory, it would be important to have a system for developmentprocess control that, reiving on a history of these mistakes, would prevent
them from reoccurring ^^
.
During the 1980s, the manager most responsible for implementing NEC's
software factory strategy has been Fujino Kiichi,
a vice
president under Mizuno
who headed the Software Product Engineering Laboratory
NEC
entered
1968
in
after
working
years
eleven
for
the
in
Fujino
1987.
in
Production
Engineering Laboratory of Waseda University, and had been one of Waseda's
first
graduates
degree
later
in
computer science, receiving
in
addition to a doctorate
in
a
B.S. degree
1973. ^'
In
in
1955 and
NEC
a
M.S.
he joined and
headed the Computer Science Research Laboratory, founded under the
R&D
central
Basic
1957,
in
labs to
Software
study software engineering, and subsequently managed the
Development
established
Division
in
1974.
^•^
He became
a
particularly avid proponent of the distributed, product-centered factory concept.
In
a
1984
article,
for
example,
Fujino
noted
that,
communications and computer businesses, NEC managers
in
in
programs were "fundamental"
needs of their customers:
software for
systems
application
software;
on-line
real-time
host
to serve the
computers;
control
distributed
software;
industry-
oriented application software; and built-in microcomputer software."'^
also concluded that,
"NEC must meet
different customer needs, so
15
its
the mid-1970s came
to the conclusion that five types of
"basic
reviewing
it
is
They
difficult
really desirable to standardize completely
and not
NEC managers
Fujino and other
"to
view
the
strategy
factory
The
production environments.""^
computers."
of
terms
in
At
the
same time,
factory-type rationalization was essential
felt
accommodate the expanding use
"-^^
.
This led to the decision to
and
"global
of
distributed
software
"modern software factory" system Fujino
attempted to implement consisted of five elements, with
a
centralized laboratory
directing tool and method development for closely linked operating divisions and
including subsidiaries. °
"satellite offices,"
SOFTWARE FACTORY CONCEPT
FUJINO'S
Central
Laboratory
for
Development
Standardized
of
Tools
and
Methodologies
Software Work Stations
Communications
Utilities
Appropriate Physical Environment
Management Engineering Techniques
Productivity Metrics
b) Quality Metrics
a)
c)
Cost Control System
d)
Management
Visibility
A key manager responsible
Motoei,
who
joined
NEC
engineering department
joining
Waseda University
software
as
an
Azuma
1963 and was manager of the software management
in
in
for developing tools and methods was
the Software Product Engineering Laboratory before
in
R&D-type
1987.
of
Azuma supported the view
only
activity
would
not
lead
to
substantial
NEC managers
improvements
in
have tried
develop "factory-like" systems, while recognizing that aspects of
software
to
productivity or quality.
development
which
are
Therefore, he and other
that treating
unique
16
make
it
inappropriate
to
transfer
manufacturing practices too directly from hardware plants.
Azuma's
environments
work focused on devising standards,
--
types of software
in
essence,
different factory structures
NEC produced.
relatively flexible environments.
closely resembled
be controlled more precisely.
--
tools,
and
for the different
For example, he believed that development of
large operating systems was more like
PBX software
methods,
R&D than manufacturing and
But smaller software products
required
like facsimile or
hardware design projects and, he thought, could
Business applications programs were often very
similar across different projects and, therefore, contained modules that could be
reused and offered possibilities for an automated production process.
Following
the standardization and structured methodology efforts of the 1970s, and the
quality control program of the early 1980s, process development at the Software
Product Engineering Laboratory during the mid-1980s thus pursued the dual
goals of automation
tools such as
and reusability,
leading to automated program-generator
SEA/I for applications software and
DECA
(Detailed Design and
Coding Assistant) for systems software.^'
Implementation of the Factory Strategy
Implementation of
factory strategy to meet diverse product needs began
a
with the founding of the Basic Software Development Division
centralization of operating systems development in the
efforts centered not on
any single
facility
Fuchu
in
Plant.
1974 and the
Subsequent
but were company- and even group-
wide, with the participation of corporate staff, operating-group line personnel,
and subsidiaries personnel.
system developed located
Tamagawa, and switching
lack of physical space
There was centralization, with most operating-
at Fi'chu, applications at Mita,
at
transmission systems at
the Abiko plant northwest of Tokyo.
and other factors, some groups as
17
But, due to
well as the
work
of
subsidiaries and software houses continued to be distributed
What was perhaps most important, however,
is
that,
in
in
different areas.
contrast to the System
Development Corporation's Software Factory, NEC created permanent centers
development managed by departments and not projects.
steadily through the
new
facilities,
of
Work, therefore, flowed
and provided managers with
a
rationale for
continued development of the factory's technological and management systems.
NEC implemented
the concept of standardized but distributed development
through the use of several sets
of
common techniques and
tools,
as well as
linking physically separated sites through communication networks,
under continual development.
File
in
process
transfers among different sites even made
no
reuse of the same code possible
a
by
more than one
facility.-^"
The
following
table presents an overview of key projects and dates in the factory-strategy
effort:
18
IMPLEMENTATION OF NEC'S SOFTWARE FACTORY STRATEGY
Year
Project/ Designation
Focus
1974
Basic Software Development
Division
Organizational separation of
software
from
hardware
development
1976-1979
Software Strategy Project
Standardization of data collection,
and
structured-programming
for basic and
applications software throughout
the NEC group, with the objectives
of raising productivity and quality
tool
methodology
1980
1981
Software Product
Engineering Laboratory
Centralization of process and
tool
R&D for dissemination
divisions and subsidiaries
Software Quality Control
Establishment of a group-wide
methodology, training program, and
control measures for improving
software quality, including quality
(SWQC)
to
circle activities
1982-1985
Software Problem Strategy
1)
Project
2)
3)
"Mapping" of software
development activities
Subcontracting management
Software
productivity
improvement
Source:
Interviews with Fujino Kiichi and
19
Azuma
Motoei, 7/28/86
SOFTWARE STRATEGY PROJECT,
The Software Strategy
1976-1979
Project was organized
in
1976 on
group-wide
a
basis (including in-house divisions and subsidiaries) rather than in the computer
group because NEC had large numbers
of
programmers
as switching systems, as well as In subsidiaries.
overseeing
applications
the
3-year project.
in
other divisions, such
Mizuno headed the committee
There were two sub-projects
software and one for systems
software,
the
latter
--
one for
by
directed
Fujino.
The
project resembled manufacturing initiatives taken at nearly
Japanese companies after the 1950s
"eliminating
waste."
In
in
practice,
the explicit focus on,
this
meant
all
phases of software production
--
tools,
large
Fujino's words,
and
collecting
performance data, and then developing standardized
methodologies for
in
all
analyzing
procedures, and
dealing with customers
(requirements analysis), as well as design, programming, documentation, testing,
installation,
maintenance, and user service and support.
The major thrust
of
the project turned out to be standardization and tool development to support
structured programming techniques. Among the systems developed,
opinion, most important
in
facilitating division of labor
large numbers of programmers has been
Engineering
for
follow in a
Fujino's
and cooperation among
STEPS (Standardized Technology and
Programming Support) for applications software. •^^
detailed discussion of
will
in
STEPS and other
tool
and methodology systems
(More
at
NEC
subsequent section.)
SOFTWARE PRODUCT ENGINEERING LABORATORY, EST.
1980
A problem that Azuma identified with the Software Strategy Project was
20
:
the lack of permanent manpower staff.
when they had
Mizuno
a
chance, but meetings were infrequent and progress was slow.
at the
felt
end
of the project that
productivity and
raise
reasons,
Members worked on the tasks assigned
quality
as
NEC managers decided
well
in
as
"we had to be more systematic" to
to
improve control. "^^
1980 to establish
the
For these
Software
Product
Engineering Laboratory to head the software development effort, organizing this
as part of NEC's central research laboratories.
Mizuno launched the new laboratory then delegated the post of director
Fujino
in
1981.
researchers
and
to
This made Fujino responsible for managing about 30 full-time
another 30
By
members.
affiliated
1986,
the
number
of
researchers had grown to about 170 full-time members (out of about 900 total
assigned to the central research labs),
including those
laboratory for microcomputer software development.
Fujino
interpretation,
management techniques.
was
to
link
software
To accomplish
this
in
newly-separated
The mission
production
they
a
of the lab,
technology
organized
it
into
in
with
three
departments covering software technology, management methods, and interface
architectures
NEC SOFTWARE PRODUCT ENGINEERING LABORATORY
Departments
Areas of Research
Software Engineering
methodologies and tools for
production, and maintenance
Software Management
Engineering
methodologies and tools for software production
and products management
Interface Architecture
network architecture, information portability
Source:
Fujino and
Azuma interview, 7/28/87.
21
software
design,
Funding
R&D funds
projects,
of tool
well
as
and method development
as
was often
as
NEC
from internal
the
in
rather than from specific
users,
software
case for
the lab came from corporate
tool
Management policy considered research on
companies.
development
tools that could
with computer hardware as part of product development,
funds assigned
to the lab
covered their expenses.
U.S.
in
be sold
and corporate R&D
Tools that would not be sold
outside the company as products but had specific in-house applications
funded partially by R&D expenses and partially by costs charged
NEC
to in-house
divisions that eventually used the tools. "^^
Transferring technology developed
One was
ways.
engineers from
to
plan
and develop
line divisions.
in
tools
and methods
Another was for
and then teach division employees how
lectures
at the lab to divisions
to use them.*^-^
in
two
conjunction with
lab researchers to
large groups and through quality circles.
Education Department assisted the lab
in
was done
develop tools
This was done through
A
staff-level Software
education planning and implementation,
in
•JO
especially
In
areas such as quality control. "^"^
in
addition to tools and methods,
identifying
optimal
studies done
in
laboratory researchers also worked on
"software factory environments."
hardware factories, but took
This effort
resembled
into account the greater "mental
effort" required in software development:
The work environment has been considered
to be an important factor for
productivity and quality improvement in hardware production. This field of
research is called Industrial Engineering or Plant Engineering... The same
approach is expected to increase software productivity. However, the
mental work utilization rate in software work is greater than in hardware
work because of the difficulty of machine utilization in software work.
Therefore, not only is the same approach taken, but the effects on
programmer mentality must be taken into account."^
Particularly
important
were motion factors,
22
such
as
the
layout
of
equipment (desks, chairs,
movements;
physical
contributed
motivation,
filing cabinets, terminals),
and
fatigue;
to
such
noise
as
furniture
including
factors,
mental
in
worked on separate parts
might desire partitioned spaces.
software
common
factories,"
in
NEC
concentration
color
coordination
a
although
of a
program independently, and therefore
Both were considered "work environments for
team-oriented
the
approach
NEC's
of
SWQC program
much QC training
in
date
back
software and Japanese firms,
study of software QC, and enlisted as
Professor Moriguchi
from Tokyo University,
knowledgeable about software.
Fujino the sub-leader,
to
in
an
a
related
staff.
a
at this
Azuma's estimation,
of this
study group,
The group remained
As with the original
full-time activity for the committee
Meetings lasted
although they managed to cover
problems,
NEC
expert on quality who was
and Azuma the chief secretary.
Software Strategy Project, this was not
month,
when
consultant the help of
active for 3 years, and included hardware people as well.
a
1978,
There was not
Mizuno was the leader
members and there was no regular
1981
NEC Chairman Kobayashi proposed they
were considerably behind the U.S.
twice
proved most
has
facilities. "^^
origins
initiate a formal
surroundings.
"individual oriented work style," where
established a software quality control (QC) study group.
time
of
and
"team oriented work style,"
SOFTWARE QUALITY CONTROL (SWQC) PROGRAM, EST.
The
which
lighting,
team are constrained to develop software through
a
close mutual communication," and an
individuals
or
affecting
Researchers designed work environments both for
where "programmers
layout
factors
or
levels
which required unnecessary
a
a
few hours once or
wide variety of quality-
and began drawing up better guidelines for procedures
,
23
required
in
software development, for example, on how to write documentation
properly.
Several conclusions came out of this study.
that there appeared to be a
close connection
One, according to Fujino, was
between software quality and
software productivity, and that any "revolution"
require equally revolutionary improvements
While similar observations had come
productivity,
this
software productivity would
software quality control practices.
other studies of software quality and
in
type of thinking
in
in
had
pervaded
NEC's
QC
activities
hardware, which dated back to 1945 (under U.S. Army guidance).
strategy as
Fujino
productivity
will
Second,
hardware
in
interpreted
was
it
to
"pursue quality
in
The best
and
software,
follow."
group concluded that software was
the
that
it
quite
different
required more intellectual activity and "desk work."
led to a decision not to rely on
hardware QC experts but
quality evaluation and design review.
Third, they
felt
it
from
This
work with several
to
U.S. software quality experts such as Gerald Weinberg to develop
to "inspect out
in
a
system for
was impossible simply
bugs," and that quality had to be "built
in
development," with department-level managers fully involved
at
in
each phase of
any
QC
effort,
as well as lower-level employees."^'
was the observation that "human factors"
Fourth,
important
in
achieving Innovations
in
software development, determined through
surveys of in-house software projects (see table).
to develop automation
techniques,
it
before
automation,"
clearly was
they
decided
the
development groups should develop automation
program focused on motivation,
While they believed
NEC had
not possible to automate
all
Therefore, since human "motivation [should
phases of software development.
come]
seemed to be most
laboratory
tools,
tool-
while a quality control
teamwork methodologies,
24
and other
and other "human
philosophy was clearly
factors."^"
This
published
Computer
in
reflected
in
a
1983
article
Mizuno
:
Software projects tend to overemphasize technical aspects.
After all,
For projects to proceed
people organized into teams do the work.
smoothly, the human factor must receive adequate consideration.
The
capability of those involved in software work varies remarkably.
Many
claim that the relative abilities of programmers can vary by as much as 30
become ever more vital to structure projects so that
It will
to one.
software quality and productivity do not directly reflect these differences.
Training can develop skills, and we can produce tools that yield quality
and productivity within given ranges regardless of the worker. We can
also assemble teams and assign work in ways that compensate for
.
.
individual differences.
We need
to develop better techniques for software production, but we must
carefully study our organizational frameworks for software
development and maintenance. We must devise control methods that match
the frameworks.
also
People are at the heart of software work; obviously, human error cannot
be allowed to lead to major bugs or malfunctions. Here, teamwork will be
the key. Team members working together are, in their collective wisdom,
far more effective than individuals working alone. "^^
PRODUCTIVITY FACTORS (NEC APPLICATIONS SOFTWARE)
Key: Scale of
to 2,
with 2 indicating highest impact
SCALE
Human Factor [Programmer
1.80
1.48
1.42
1.28
1.23
1.22
1.13
Quality
Generality
Hardware
Contract [with Customer]
l.n
Specification Volatility
0.98
Development Methods
Source:
Mizuno 1983,
Fifth, since
how
Capability]
User [Program] Complexity
Development Tools
it
p.
69.
seemed that getting
to solve quality problems
all
workers
was the best way
25
to think together in
to try to
groups
make progress
in
software quality control, they decided to adopt the manufacturing practice of
quality circles. ^
In
a
6-month
trial
applying other techniques used
control and studies of
Finally,
needed
a
in
during 1980, NEC also experimented with
hardware QC, including
1981
quality
worker behavior. ^^
the study group determined that to continue their efforts they
formal,
company-wide program covering
all
production, management, services, sales, and training.
in
statistical
as the
"SWQC" (Software
aspects
of
The program took form
SWQC Group
Fujino the Administration Committee.
the educational
programs.
This was
Quality Control) organization.^^
incorporated into NEC's zero-defect (ZD) structure, as indicated
below, with Mizuno heading the
software
in
the table
Activity Steering Committee and
The SWQC Information Center directed
Quality circles,
meeting once per week for two
hours, were the chief vehicles used to carry out
QC
training and functions. ^^
(More detailed discussion of the quality control system
at
NEC
follow
will
in
a
subsequent section.)
NEC'S SWQC ORGANIZATIONAL STRUCTURE. 1986
Focus
General
Structure
Zero-Defect Steering Committee
Quality
Hardware and Software
Policy Formation,
Corporate-Director Level
Software QC Policy Formation,
Division-Manager Level
Company-Wide SWQC Group Activity
Steering Committee
Administration Committee
Planning for Training and Education
SWQC
Training and Education
Information Center
Study Group
SWQC Group
Activity
Research and Recommendations
Management
Policy and Implementation,
Department- Level and Suppliers
Committee
SWQC Groups
Quality Circle
Employees
26
Activities,
All
Source: Mizuno 1983, p. 71;
Fujino interview, 7/28/86.
SOFTWARE PROBLEM STRATEGY PROJECT,
Unlike the
NEC,
within
SWQC program, which
but
similar
to
the
1982-1985
has remained a permanent organization
1976-1979
Software
Software Problem Strategy Project (SPSP) launched
The
effort.
on
heavily
programming techniques,
structured
standardization.
The follow-up attempted
on
involved
divisions
all
quality
formally
control,
and
designate
product divisions.
to impose
productivity-improvement
NEC
and
1982 was
a
of
software
began
enforce
relying
process
of
to
standardization,
and
measures,
factories
three-year
tools,
the
the
more top-down organization
software development,
in
series
a
Project,
had developed new methods and
project
earlier
in
Strategy
serve
establish
or
NEC's different
President Sekimoto was the formal head of the project,
with Mizuno as the sub-leader.^''
The 1982-1985
NEC
called
organizational
project focused on three major activities.
"software
layout of
production
mapping."
information
processing
This
involved
activities
First,
a
was what
logical
and
by product (basic
software, system engineering programs, user applications, transmission, switching
systems, microcomputers) to determine which software houses divisions were
using, or which subsidiaries
to assist divisions in
NEC should
create to serve as "software factories"
program development.
to systematize procedures for
Second, was
a
more formal attempt
managing software subcontractors.
Third, was
another effort to improve and link software productivity and quality assurance
measures.
The
last
element
included
the
establishment
of
a
Software
Productivity Committee, which worked on documentation control, quality control,
27
software productivity and quality measurements,
and software production environments.
project management, tools,
the results from these efforts
The project
that Mizuno,
be discussed
education,
(Some
^
two specific trends
development and
--
of.
subsequent sections.)
in
software development
in
Azuma, and other NEC managers believed they had
"decentralization"
confront:
will
also dealt with
Fujino,
cost estimation,
support of
programs
to
by
geographically distributed groups; and "asynchronism" -- development of parts of
programs
at different times.
"
For example, due to the cost of physical space,
the shortage of programmers living or willing to live
to service
became
customers from
increasingly
all
spread
the city, and the need
NEC's software operations
parts of the country,
around Japan
in
after
rather
1980,
than
being
centralized.
NEC
did
implementation
Software
not
emphasize the
(detailed
Factory),
Software Factory).
Hitachi
and coding)
(Omori
Nonetheless,
divide up work between
houses. ^°
design
NEC
separation
it
was
design
formally
as
Software
of
Factory),
a
still
program
from
as
Fujitsu
(Kamata
or
Toshiba
(Fuchu
common practice
in
NEC
to
divisions and subsidiaries or affiliated software
Implementation of this type of factory concept whereby design was
performed
one location and programming
in
programs were developed
at different times
another,
in
and
in
or where parts of
different places, depending
on manpower availability and expertise, clearly required methods of ensuring
that groups
tools.
in
different places followed the same procedures and used the same
Tools used throughout the
NEC group, such
as
STEPS, SEA/I, and SPD
(Structured Program Diagram) for applications software, and
Engineering
for
Advanced
Reliability
Engineering)
and
HEART
(Hopeful
SDMS (Software
Development and Maintenance System) for systems software, were designed
support
a
distributed but standardized approach to development.
28
to
II.
TOOLS. METHODS. AND MANAGEMENT SYSTEMS
Product Technology and Process Choice
Characteristic of
all
the software factory approaches
development of specific process techniques and tools
factories
--
established
initially
for different types of software.
software factory
a
done
the
in
same
in
case,
although
facility,
it
separate
tools,
product
technology they
Two
a single set
types
felt
which
and
methods,
relatively easy to divide the factory
one for systems software and another for applications.
standardize around
specific
effect,
in
the case of Hitachi,
managers did not centralize software development
different
Japan was the
1969, systems and applications programs were
standards evolved gradually and made
into two,
In
--
in
in
a
In
single
NEC's
site
or
or tools or procedures, but tended to emphasize
and the constraints or opportunities
in
process
these different products (and markets) offered.
main kinds of programs are general purpose systems software, and
user software.
Azuma and Mizuno adopted the
systems software,
compact, use
Therefore,
little
it
like control
programs for operating systems, usually had
memory, and offer
seemed
to
position that general purpose
a
to be
variety of functions for different users.
them that programmers writing
tliis
type of software
"are required to have a high degree of skill," and that reuse of standardized
modules or patterns was not an appropriate process choice, although they
emphasized
factory-type
techniques
assurance, and project control.
processors
and applications
for
process
standardization,
On the other hand, they noted
software
contained
more
still
quality
that language
similarities
and
less
functional constraints, and thus offered more opportunities for using software
29
engineering methods such as modularization and structured programming, and
even manufacturing-type techniques such as assembly of standardized program
i
49^
components.
Azuma and Mizuno provided several examples
how process R&D
in
NEC
has taken into account the characteristics of different types of programs.
For
of
example, one application area they called "Large-Scale and/or Complex Software
Used Repeatedly," including train seat reservation systems, process control
programs
for
steel
These had
banking programs.
operate
a
systems,
control
common primary requirement,
NEC
But
accurately."
production
factory
mills,
did
on
focus
not
tools
and on-line
i.e.
that "they
verify
to
logical
correctness or to reuse code, but concentrated on "techniques, documentation,
nomenclature,
[which
etc.
are]
important
for
harmonizing
work
by many
programmers."
complex applications software such as for scientific and
Medium-scale,
engineering calculations required accuracy and
implemented by the code were complex,
area of
a
NEC
felt
Used Only Once,"
engineering
application
of
such
calculations.
as
Unlike
is
not
a
significant factor."
program was "Small-Scale,
management
complex
was the main
that "Programs of this type have
character close to the arts, and standardization
A third type
Since the algorithms
verification technology
Azuma and Mizuno
research.
reliability.
reports
from
applications,
Simple Software
databases
or
simple
Azuma and Mizuno
considered these easy and inexpensive to write and, therefore, not
in
need of
factory-type tools or standards.
A fourth type
Used Repeatedly"
applied
STEPS
--
of
applications software --
"Small-Scale,
Simple Software
was the focus of the STEPS system, although NEC also
to other applications
programs.
Small-scale software of this
fourth type included batch processing programs such as for inventory updates
30
and common business applications generally averaging about 500
steps
COBOL, ranging
in
to as high as 3000.
"When these program are
classified
lines of
code or
Azuma and Mizuno noted
according to process
patterns
that,
such
as
updating and inquiries, about 90% of them belong to any one of about 20 types
of patterns.
Programs involving entirely new patterns are few."
was so much
similarity,
the
NEC managers found
it
Since there
relatively easy to develop
standardized techniques, nomenclature, and documents, as well as standardized
components
For
.
types of software, since 1980 or so
all
NEC
has followed a relatively
consistent strategy for process development, according to Fujino, by focusing on
computer-aided design and manufacturing techniques
existing software to build
(CAD/CAM);
reuse of
new programs; cross-product planning, and better
requirement definition techniques, to reduce duplication and wasted effort; as
well as standardization, quality assurance,
and education programs directed
at
raising both quality and productivity:
THE NEC APPROACH TO SOFTWARE PRODUCTIVITY AND QUALITY
METHOD
GOAL
improvement
Reuse
in
development
of existing software
CAD/CAM,
Standardization
Reuse technology
Waste prevention
Cross-product planning
Elimination of excess
Methodology and tools for
requirement definition
functions
Product quality improvement
Software
quality
metrics,
tools
for
new and
old
quality assurance
Personnel quality improvement
Source:
Education programs for
employees and managers
Fujino 1984, p. 58.
31
Applications Software Standardization and Reuse
Most important for standardizing work procedures and documentation
in
order to promote division of labor for general applications software written
in
COBOL
Azuma and Mizuno,
Support).
stemmed from
to develop this
can
STEPS (Standard Technology and Engineering
has been
in a 1981
Programming
paper, described how their motivation
desire to standardize practices so that people
a
work together effectively
incompatible
for
teams,
in
software-engineering tools
communication among engineers:
with
or
methods,
as
due
problems
minimal
well
as
to
restricted
"Regardless of how excellent these [software
engineering] technologies are, the desired objective cannot be accomplished
each member of
his
own
will.
a
team or an organization developing software adopts them
at
This problem occurs because some technologies conflict with each
communication
other and
if
between
engineers
is
Hence there
restricted.
is
necessity for standardization of software."'''
After development began
for in-house use
in
1972.
in
1971,
NEC
released an
Azuma and Mizuno
recall,
version of
initial
STEPS
however, that "The
version was intended to be comprehensive, fool proof and was compiled
form of
led
to
a
manual 30 cm thick.
Therefore
another effort to produce
completed
in
1974.
Revision
was never used."
system easier to use,
a
of
it
the
sites using
STEPS by
STEPS was due
component
of
to
1984.
their
standardized
^'^
NEC engineers
tools,
procedures,
program" modules accessible through
a
32
the
which
NEC
tools
staff
has
NEC and NEC-customer
claim that the recent success of
approach:
two-fold
in
This experience
STEPS methodologies and
continued every year since, with approximately 1200
first
offering
and
of
a
technological
"prefabricated
standard
program library; and emphasis on
a
.
philosophy outlining how programs should be developed through each stage of
the software
cycle.
life
The philosophy underlying STEPS, according
on the historical experience of companies
in
to
Azuma and Mizuno, drew
"hardware" manufacturing industries
which had found ways to improve productivity through standardization and
division of labor,
materials,"
as
well
as process
"intermediate products,"
"product utilization."
counterparts
in
All of
through analysis of "raw
rationalization
final
"products,"
"work methods," and
these process inputs, they insisted, had conceptual
software:
The productivity
Revolution. The
of industry has greatly increased after the Industrial
basic concept of the Industrial Revolution was to achieve
.drastically reducing the
high volume production of standardized products
manufacturing cost ... by thoroughly incorporating standardization not only
of the final products but also their parts...
.
.
In spite of essential differences between software and hardware, a
of similarities can be found where standardization is concerned.
(1)
Program language, macros, subroutines,
in producing software...
etc.
number
which correspond to raw
materials
(2) Documents and specification documents corresponding
Their standardization facilitates division
products.
to intermediate
of labor and
automation.
Mass production of
(3) Programs and documents correspond to products.
standard products are [sic] similar to general purpose applications of
computer manufacturers and software houses. The needs and circumstances
of users are identical to other examples were production of orders are
tailored to the customer.
Products should perfectly be made with parts in
units which are as large as possible, that is, by combining standard
modules
(4) Tools correspond to the software used for software production.
Compilers, test data generators, etc. are examples of these.
(5) Work methods represent standardization of methods such as application
system designs, software designs, and coding.
(6) The product utilization method concerns which data is processed by the
software.
To efficiently design individual items of software and to
eliminate contradictions among them, standardization of data will be
important. In other words, this concerns standards of languages, modules,
program structures, tools, methods, documentation, and data, and
standardization must be conducted systematically under a consistent
33
philosophy.^"'
The STEPS procedures required program development
five distinct "phases," with subsets of "activities" and then
activity,
to be divided into
"work sets" for each
consisting of specific procedures and "basic work elements,"
which managers monitor as part of scheduling and progress control.
standardization
came from
standardizing
each
work
set
and
documents, using form sheets or simple headings for "work of
type."
NEC managers considered
degree essential for communication
maintenance
separation
in
of
particular
design
of
Process
accompanying
more creative
standardization and documentation of this
in
general and division of labor and program
(see table)."*''
from
a
all
production
Division of labor also included the
to
the
extent
that
NEC
divisions
sometimes "handed off" high-level design documents to subsidiaries, which then
did detailed design,
coding, and testing. ^^
34
P^ojer^ file
.-cr-3
shec:
Wcrxset
.-ora
sheet
>crR
Wcrhse;
/
sheet
/
Worxse:
doc-jmer.l
Dc-^t-.tjt^=" vrrx
STEPS PROGRAMMING STANDARDS
Programming Standards
Work
Outputs
Standard Patterns
General System
Design
Processing Flow
Standard Specifications
(Structured Program
Diagrams)
Detailed System
Program
Design
Specifications
Program Standards
(Structured Program
Coding)
Manufacture
COBOL
Source:
Source
Coding
Azuma and Mizuno
1984,
p.
88.
Reusability stemmed from the similarity of business applications; the ability
code to suit new users
to modify existing
possible
by
modularization,
standardization
programming language (COBOL),
Mizuno also
program
should
felt
--
semi-customization -- was made
of
design
techniques
confident they could construct almost any type of business
easily from standard patterns modified for individual customers:
be
able
possible
apply
to
Modifications
of
the
Azuma and
and extensive documentation.
to
modify
standard
patterns
to
suit
every
modification of standard divisions for every program should be easy
be
and
standard
standard
patterns
divisions
to
for
a
larger
every
number
of
program should
user,
in
"It
and
order to
programs.
be
easy."
Accomplishing this required several techniques and procedures:
1)
clear
classification
of
standard
source codings
patterns
2)
easily understandable lists of
program patterns
36
intrinsic
to
common
3)
short documentation accompanying
4)
clear
5)
COBOL
6)
structured programming techniques sufficiently versatile to handle complex
lists
program structures designed for easy maintenance and modification
as the standard coding language
programs
as well as simple
standards for design, documentation, coding, module nomenclature, work
7)
"
(see figure).
areas, etc.
There were various ways
One was
considered.
strategy for
to locate
STEPS because
were time consuming and
and
code that Azuma
reuse
to
utilize similar
and Mizuno had
programs; they rejected this
was not versatile, and modifications
it
led
Another was for programmers
errors.
to
programs
of
memorize recurring, specific patterns; experienced personnel seemed
as
a
matter of course,
although
engineering techniques.
was not
it
A third way was
applications, with parameters entered
useful for simple patterns such as
for
more complex
parameters
however,
COBOL.
A
from
or
the
all
approach was
into
do this
a
set of
programs for common
place of specific data.
A fourth
was
to
descriptions;
to place frequently
This they found
generate
for
programs
from
programs,
complex
near to the complexity of
used modules
in
macros; this
types of coding divisions, however.
The technique STEPS promoted was
program patterns," written
in
and maintenance (see figure).
customer involved writing
pattern,
fit
to
medium conversion and extraction, but not
language
simple
to prefabricate
language needed to do this came
fifth
did not cover
functions.
in
practice that
a
to
examining
the
a
structured
to create
COBOL
Development of
a
what NEC called "standard
for relatively easy modification
"new" product for
general outline that corresponded to
more detailed program specifications,
37
a
a
particular
standard
and then
identifying
eliminations
or additions as
needed
in
the detailed design
phase
before coding:
A program developer
first writes a process flow to match a standard
general system design phase.
There is a standard program
specification corresponding to each standard pattern.
Program Designer
compares it with a requirement specification in detailed system design
This eliminates unnecessary functions, and defines processing
phase.
intrinsic to business that is to be added and inserted.
Next, in the
programming phase, standard programs are modified if necessary, and
additions aJid insertions of processes intrinsic to application are
pattern
in
performed.
^'
38
.
t^wmmt
BaccA ^rvc» M.n^
fo»
c^
Mvca
C<y»*'^Oi
u
CZj
Oa.,.t,jn
HP
I
I
Q
c5^
\
CollAtiO^
u
Lacai.n*
;
-u
c=i
IP;
'^
k—
[13
^^
'
®
f
^
en
ru
c:^
.^^^^
p-
I
,
LJ
('irr»r»n for
[:::j
uc^ u
c^
6
=
CP
Om"'««
Qill
Q
t
s
U
:-<:i
1^6 U
Fig. 7
S"PS Stancard Patterns
Unlike
Toshiba's
requirements on designers to register
month.
The STEPS system
such as SEA/I and DECA.
itself
NEC
certain
a
facilitate the
to
PAD,
Hitachi's
of reusable
to
SWQC program,
°
YAC-II,
flow of control, with diagrams written
its
first
version
--
who preferred
The
programs."
notations,
earlier
This
in
called
STEPS, NEC
SPD
(similar
HCP diagrams).
NT&T's
and
of
diagramming
this
SPD
of
technique
-- usually,
to write sophisticated
versions
SPD
in
Japanese or any other language.
in
considerable resistance from software personnel
engineers
who
'^^
represented program modules hierarchically and showed interrelationships
introduced
tools
which also gave out awards
programming diagram technique
Fujitsu's
modules per
be frequently used.
design and production process outlined
also developed a structured
impose formal
not
did, however, provide bonuses to designers
procedure was formally part of the
for quality and productivity.
number
did
promoted reuse, as did program-generator
produced software modules that turned out
To
NEC
Fuchu Software Factory,
also
in
1974,
the
NEC
with
the more experienced
but unstructured "spaghetti
had only
simple
lines
and
and thus lacked representations such as symbols for node control
(input/output paths) and module names.
Additions to the system, as well as the
use of "logic tables" to describe process specifications, significantly increased
acceptance of
STEPS,
according
to
Azuma and other NEC engineers
figures). 60
40
(see
S*Cw»r«»|
Oi*gr»^ Sv^boJ
N*
Fl0w Chjri Synbo^
Pr«c»u funnoni of tU
^McnCwd
1
at
V<« rigM
Prow* 3
H
-^
"=
rrvijNi
ttVIEl
<r>
CASc
lC« Co^^•^<»<
II
—
•^1
©i
If
Ca
&
UNTIL NCT 3v<faan
r-'fH'LE)
CCSCL
CamanoM
of
ll.N.UNS)
WtTH TeST APTErt UNTIL
CtfW^noAolCCSOL tl^M.iNe1
(O^mu
Fig.
9
Symbols Used in SPD
I
U"I003
I
1\
Co'iAoon %r S(Mor>of*on
V
to
J.
1
OfvtPd- G'EUOI
L^«4
3
ClSUOt
— Cp«n .npwi
C13C2
r.i*
ClSSOJ
1
n v*d eouMt
ctf Uiion
CISS04M
—
nart
CISS04
fiiu inoMt
ft"« 2.
— S«( owa>u(
>>•
— S«( Ot^CPwI
M«
— C?^ (Xir>ji
— S«t Output
1
2
M«
r<i«
in
2
3
CISU13
-crcsoi(Input
k»T
fit«
fil«
1
-
S*l i««pwl Rl« 2 ruo. ariUtMvt k»r
IT
uxlat'on
^
fro**! w'^Dl iMput
2 oc'^i-on krrt
"
<^x
c;».
^^•
1
\cj\ and rr**1 h«aOi
b
<
.
cinoi
r<i«
I
e9iii«>n
ni« }
C2r*02—
pnomm
0>«ou(
o.exi
b^ ^
.
cirsoa.
-ten
"!• 3
ClE'.Ol
f^'
Com
nouf
an
ru
2
tot* '^jf»«iw
OLSoa
Fig.
10
Example of Collation 2? Specification
(ii.i
flv>««fTtai»
LOGIC TA2LE
„
Carv
T« «i iwnd
(M9U1
i>t«
«tfkia
•!
N%
otf
''/v
w«a«^
pa^ eoi^Mr
2
Inpwi 9 'Km
I
0«T»
•CuMv*«« Cm
Cm*
Inpvi f •* 2
f»«i»^
To *a«c\«a
C7AC«
To
••!
•
ua'B^a
<
C9'«r*an
i
*T
UQM*
~~M«flOa/^
cO-nM^ ^IWtH^
'MfO't «««jum aO-C
rvulw EDIT —
.
1
standard program codings or procedures corresponded to SPD and were
divided into 5 levels.
The
first
three treated
as
"black boxes" processing
divisions, conditions for selecting the primary processing functions (modules),
and
processing
specific
The
subroutines.
Another
functions.
fifth
was the
procedures unique to their needs.
"users
level
level,"
consisted
of
common
where customers defined
Programmers using the STEPS methodology
only had to write specifications and code for this fifth level."'
STEPS STANDARD CODINGS
Identification Division
Environment Division
Data Division
File Selection
Working Storage
Section
Procedure Division
Level
1
(Process Division)
Level 2 (Primary Process Function)
Level 3 (Specific Processing of the Primary Process Function)
Subroutines
Users Level
Source:
Azuma and Mizuno
1984, p.
Despite some resistance
introduction of
STEPS
in
91.
the mid-1970s,
as a major success.
in-house and customer sites
in
NEC managers considered
Among programmers surveyed
1981, according to
43
the
at 88
Azuma and Mizuno, about 88%
found STEPS "very easy" or "easy"
debugging "very easy"; and 81%
felt
to
it
55% found
learn;
had
it
made coding and
"considerable" or "big" effect on
a
Productivity improvements measured by man-days required for
productivity.
programs developed with and without STEPS ranged from 26%
similar
in
the
specification phase, 91% in coding, 35% in compile time for debugging, and 53%
for man-days.
overall
longer than average
was generally
phases, and
non-STEPS programs by about 6% more
Offsetting this, according to 1984 data on
(see table).
sites,
The average STEPS program, however, was
a
a
20 to 50 percent cost reduction
50 to 80 percent reduction
in
Key:
s
PHASE:
=
source code lines;
md
STEPS user
=
man-days;
source code
STEPS users
phases.'''^
(1981)
sites
t
=
at 1200
analysis and design
program manufacturing
STEPS PRODUCTIVITY COMPARISON
Sample: Project data from 1200
in
lines of
slightly
compile time for debug
Automated Production of Business Applications Programs
The most important automation
programs
COBOL was
in
used
business
applications
SEA/I (System Engineering Architecture).
Development
tool
for
began around 1980, when NEC established the Software Product Engineering
and
Laboratory,
$10,000 and
1984
in
The
Base (EIB),
a "tool
tool consists of
testing,
and
programming experience by providing
system definitions,
a
tool
from
proposal
formation
set formats
at
support for up to 10
an Empirical Information
prototyping
and ready access
to
capture
to previously
system and program structures,
layout designs,
and
product priced
EIB attempted
installation.
programs, and test data.
of tested
provided specific software to aid
set
with
a
work methodology, covering proposal,
program modules ("source parts"), number
The
SEA/I as
three subsystems:
machine" set, and
implementation,
written
offering
NEC minicomputer,
running on an
engineers.
design,
NEC began
in
through
all
phases of development,
The work
maintenance.
methodology was based on STEPS.
SEA/I
served as
a
program generator
called
"auto synthesizing."
COBOL
through
parts" from
a
a
One method NEC
This produced complete programs
in
structured
Source Parts Library and put the parts together automatically.
called "interactive synthesizing."
of the tool to specify parts to be
they were to be located
in
two ways.
menu system which pulled out software modules or "assembly
The second method NEC
anywhere
in
between.
In
in
This allowed the user
recalled from the parts
the program,
library and
where
and to insert newly written code
both cases, the synthesizer function of SEA/i checked
syntax validity, data-name consistency, and attribute consistency, to make sure
the modules would work together. °^
45
PtOOOCTKX
&
StSICm SuF^OtT ToOllOIH
Svii«m PrepoKM
Mo
Dolo Flow C'oonn
R«CO/d Dci'ffn
jporii
Mo
l.b(Om« 0«f /Proc)
Co'^o'otvd T*^ Do'o
r«il Molr.i
|C|ftmorioA
i«M*inM
S'oro^a Sooca Ewimotot
An example
included
storage
in
file
SEA/I
is
shown
in
(Item Master File)
enters data.
too!
developing
of
data entry program with the various tools
the figure below.
This example requires one
and one screen form through which the user
The program designer uses the Data Record Design Aid (DDA/1)
to create a
hand corner.
a
record structure and screen format shown
The Data
which
"implementor"
are
tool
put
called
extract test data, while
is
the upper
left-
Definition Source Parts Generator (IMA/2) analyzes the
design and then generates two sets of source codings
format),
in
a
together
IMA/3.
into
a
single
A testing
tool
(file
structure and screen
COBOL program
analyzes
the
by
program
an
to
configuration tool calculates how much storage space
needed and generates job control commands
other types of business applications,
a
to allocate the file space.
menu-based
Tool (PDA/1) performs similar functions.
47
tool called
For
Program Design
s
a
Q)
C
>.
w
E
o
t
:
r-
.z-itt
a
o
•
i •
.
1-
c c
oc
» 1
:
-f t£.:::.iii:
£ft==t5^f5;
il?:£?;S
c
cr
<^
.
I.
a.
<
1
«
c
o
w
<
r
m
Of particular significance,
and Masao Matsumoto (the
tool),
is
that SEA/I
the view of
in
latter has
"learns"
NEC managers such
been directly involved
in
as
developing the
the sense that the number of elements
in
Fujino
in
its
Empirical Information Base -- system designs, documentation, code -- increase
every time
a
new program
importantly,
become accessible automatically
thus
documentation
designed on the system.
is
and
procedures
the
standardized, making
it
Improved designs and
future
to
accompanying
tools
users.
More
SEA are completely
possible to divide labor among the different development
stages or have different individuals up-date programs
in
the future without,
according to Fujino, the usual problems that come with changes
Users have reported as much as
a
in
personnel.
7-foId increase in productivity due to the
fi7
automated functions."'
Another
automation
tool
used
primarily
requirements definition and documentation was
Software Product Engineering Laboratory.
diagramming functions linked
design
programs
through
to a
SPECDOQ,
software
also developed at the
This provides graphics, menus, and
relational
standardized
applications
for
database that allow engineers to
documents,
and then
change these
documents easily for different applications.
The
tool
the Unix operating system and, according to
NEC
developers, was also able to
was designed
to run on
CO
process the STEPS documentation.""
Systems Software Development and Process Control
A major issue
in
NEC's basic software development was standardization.
Because the company supported 4 incompatible operating systems, including one
inherited
from
Toshiba
in
the
late
1970s,
managers
had to think
about
standardization even more deliberately than other divisions to get any economies
49
of
these different
across
scale
merged gradually), planning and standardization allowed
different (despite being
NEC
to reuse
code across the different systems, especially for language
and data base programs.
the
Even though the architectures were
lines.
CO
But the incompatibility of different machines and
^
software
presence of old
utilities
and documentation made
it
necessary
to
(1)
formally recognize and try to improve existing tools and procedures; and (2)
delay the introduction of more advanced design-support and process control
tools.
All of
NEC's systems software divisions, subsidiaries, and
developed along with different operating systems. Most important
relied on tools
was
HEART
(Hopeful Engineering for Advanced Reliability Engineering), used for
The procedures, standards, concepts, and
operating systems development.
associated with
the
SWQC
compile
a
affiliated firms
HEART
activities
formal
had been used for several years
at
Fuchu
the
manual
and
The
subsidiaries
and
has
as
a
NEC
until, as part of
managers decided
Factory,
HEART
promote
production and quality control.
software facility
Software
in
to
system for
"scientific"
quality assurance department at the Fuchu
been the formal promoter and continues
affiliated
tools
software
houses
in
adopting
assist
to
the
NEC
recommended
techniques and standards.'^
The philosophy behind HEART was
collection
This
was
and analysis to
based
productivity.
on
the
efforts
link
notion
To implement
that
in
that
was
it
possible
to
data
process control to quality control.
improving
this concept,
quality
HEART
will
lead
to
higher
relied on 5 basic elements:
1.
Process Control System (Standardization, Team Methodologies)
2.
Design Techniques and Tools (SPD, DECA)
3.
Program Analysis System
4.
Modularization Methodology for Reuse
50
use
5.
Testing Technology.'-^
HEART
collection
defined 7 phases of development and testing, and required data
during each:
detailed design,
requirement analysis and definition; functional design;
which used the SPD charts; coding, mainly done
subset, HPL, with some also
integration;
from
and system
requirement
in
test.
analysis
C and assembler;
through
coding;
accounting
quality
The kinds
of
data
sheets
required
all
of
the data went
managers through
for
concentrated on scheduling and productivity (man power) (table).
51
were
NEC automated some
into a central process/quality control data base accessible to
(figure).
PL/I
Development item history sheets were required
the data input; other data entry was done manually, although
terminals
a
unit and function test; system
required from unit/function test through system test.
on-line
in
each
'"^
phase
PROCESS-CONTROL DATA COLLECTION
1.
ReQuirements Analysis/Definition Process
estimated date of completion of each process
estimated program size
estimated man power
person in charge of development and years of experience
language in use
development form (new development/modification/division transplant)
difficulty level of development [type of program]
2.
Functional Design Process
completion date
actual
man power used and break-down by persons
in
charge
difference between the standard times and the man power used
quantity of functional specifications and revision history
scale of design review (number of workers/times) and the number of
corrections
3.
Detailed Design Process
completion data
actual man power used and break-down by persons in charge
difference between the standard times and the man power used
quantity of design specifications and revision history
scale of logic inspection (number of workers/times) and the number of
corrections
4.
Coding Process
completion data
actual
man power used and break-down by persons
in
charge
difference between the standard times and the man power used
the development size
detailed information for each program to realize functions
scale of code inspection (number of workers/times) and the number of
corrections
5.
Unit Test/Function Test Process
number of test cases to be executed
target bugs to be detected
required man power
number of test cases executed previously in a certain period of time
number of bugs detected previously in a certain period of time
man power used in the past
6.
System Test Process
number of test cases to be executed
target bugs to be detected
required man power
number of test cases executed previously in a certain period of time
number of bugs detected previously in a certain period of time
man power used in the past
52
c
O
U
H
tH
O
CT3
CO
CO
o
u
o
u
C14
iJ
c
E
c
>
QJ
to
An SPD translator
SPD diagrams
translated
This
diagrams.
coding
and
in
tool called
DECA
(Detailed Design and Coding Assistant)
program source codes, or program codes
into
eliminated
much
the tedium
of
(and
COBOL
(for
applications
automated" (compared to SEA-I)
interfaces between different
in
that users
modules.^ By
still
had
NEC
all
software
producing systems software as well as applications programs
of
SPD and DECA
--
used versions
management meetings"
called for "process
to be held
adherence to the promised delivery
(release) date; and quality of the final product.
Analysis for this included data
from several "process management models," primarily
12-factor cost model.
a
Differences between estimated and actual man-power figures required
managers
in
charge.''
Assurance Department
NEC
NEC was
generally able
the Basic Software Division,,
a
month
of
planned release dates;
included some "buffer time" to allow for slippage of schedules, this
over the past five years.
the
review
of the Quality
represented an improvement of approximately 20 to 30%
with
a
According to Hirai Yozo, Manager
system software products within
to deliver
while
in
facilities
designs and code. "
periodically to discuss primarily two issues:
of the
"semi-
code to create
to write
--
HEART procedures
only
1987, with the exception of specific
programs following different customer specifications,
to write detailed
of
(similar to PL/I),
DECA was
although
software),
SPD
errors)
potential
HPL
variety of languages, including C, Fortran,
a
into
different
phases
in
planning accuracy
There was no organizational division
of
development,
as
might
occur
of labor along
in
applications
software development, although less-experienced programmers did detailed design
and coding,
and the more experienced personnel focused on
requirements
analysis. '°
With regard to project control,
follow
the advice of
Frederick
it
is
Brooks
54
interesting to note that
at
IBM,
who had found
NEC
did not
that adding
people to an already late project made
NEC was
Hirai claims that
required.
it
to
communication time
although managers tried not to add
meant they were
because this
testing,
to the
able to add people to any stage of the
process and effectively reduce lateness,
people
due
later,
not
catching
bugs and
development.^
eliminating them during
SDMS (Software Development and Maintenance System) was
advanced and integrated
set of tools
and techniques originally intended
as a software factory infrastructure for
NEC
problems,
has limited
its
all
basic software.
Due
a
more
to
serve
to introduction
use to new switching systems and communications
on
portions of operating systems. ^
planning
Basic
SDMS
for
started
1975,
in
at
about
the
same time
information was becoming available on SDC's Software Factory experiment.
many ways, NEC managers intended
to use
SDMS
system for the development and maintenance
In
fact,
1979
a
processing compared
tools
developed
published
article
SDMS
at Mitre
to the
in
of
Japan's
as a total,
In
factory support
modularized systems software.
leading journal
SDC Software
on
information
Factory, as well as to other
(Simon), Softech (Software Engineering Facility),
TRW
According to the NEC authors,
(SREP), Fujitsu (SDSS), and Toshiba (SWB).
these other tools concentrated either on design support or project management.
SDMS was
The
NEC
superior
in
its
attempt to integrate both functions. °^
first practical version of
SDMS was
released for in-house use
in
1980;
has continued to introduce improved versions every year or two.
The
basic system remains the same, consisting of
and three subsystems:
(SDL) and
a
a
software development data base
(1) for design, including a
standardized design language
methodology emphasizing modularization and sophisticated data flow
and abstraction techniques, with
error checking,
facilities for
design modifications, automated
and automatic design document generation;
55
(2)
for product
management (configuration, updating,
retrieval)
;
and
including progress control and productivity data.
considered the most important part of SDMS.
56
-^
(3) for project
management,
The design subsystem
is
SDMS
Several experimental projects have reported significant improvements
productivity and quality.
with
a
data
base,
For example,
engineers
in
the design of
SDMS showed
using
in
comptroller system
a
twice the output
rates
of
comparable projects, including the discovery of 90% of the design errors before
programming phase,
the
and automatic generation
more than 90%
of
design documents, which previously were written by hand.
an overseas switching system,
of
the
maintenance of
In
SDMS helped reduce man-hours
producing
in
upgrades and revisions by 90%.°^
Despite these results,
or problems
Therefore,
in
adopting the standardization and tools
in
NEC
has restricted
the switching division.
development
Laboratory."'^
NEC developers have acknowledged
projects
its
SDMS
done
serious resistance
required by SDMS.
use to new selected new programs, especially
also the
is
within
the
for
new software
Product
Engineering
tool
Software
SDMS
But examination of why
required
has not quite fulfilled the early
goal of serving as a comprehensive "software factory" infrastructure provides
several lessons regarding the introduction of
new standards and
tools into
any
existing development and production system.
One problem has been the time required
methodology.
This
learning
projects, as well as slow
familiar with the
tended to delay the start
of
the
new design
actual
work on
down design progress because programmers were
new methodology.
to the suspension of
learn
to
SDMS
In
some cases,
introduction plans.
new design techniques did not work
not
type of experience led
this
A second problem was that the
well with existing
code written using
emphasis on concepts such as data-flow and abstraction.
The need
to
less
upgrade
previous systems and the difficulty of replacing existing software entirely has
also
to
reduced the successful transfer to SDMS even
adopt the system.
A
third,
related
58
difficulty
in
divisions that would like
has
been that SDMS was
developed to run on NEC's large-scale ACOS-6 operating system.
writing software for different computers found
machine.
their
own
HEART].
it
Fourth, was the general problem that
tools
difficult to mix
NEC
Programmers
more than one
divisions had developed
and standards over the years [such as those now included
Getting them to change over to
particularly difficult
SDMS standards
divisions were engaged
if
in joint
in
took time and was
development efforts with
other firms. ^^
Process. Cost, and Quality Control
Because Honeywell had been particularly successful developing software for
its
in
MODE
200-model computer series, for the
IV project NEC's control section
the computer division decided to copy Honeywell's process-control system,
which consisted
of
PERT network
a
"We were very influenced by
model.
Honeywell," Mizuno admits, but they soon realized that the PERT charts were
almost useless.
The
initial
planning parameters were so inaccurate that none of
the schedules came out close to estimates.
This prompted
adopt another planning and forecasting model used
Corporation (SDC)
in
a
System Development
model for the U.S. Navy during the 1960s that broke
down the development process
into phases such as specifications design, detailed
design, coding, and component test.
but, according to Mizuno, the
It
was superior to Honeywell's technique,
SDC system
SDC had
also had serious deficiencies.
its
NEC managers decided they needed
59
a
in
engineers; users
to take into account different experience levels of
changes over time.
The
fixed the parameters and coefficients used
the model, basing them on the average performance level of
were unable
to
Santa Monica, California.
SDC had designed
main problem was that
at the
NEC managers
programmers or
more dynamic model
that could accommodate different experience levels, as well as additional factors
they
had an impact on software costs and personnel performance.
felt
was
It
data
begin
to
NEC had enough
point -- around 1967 -- that
at this
calculating
rough
standard
times
for
development activities and different types of programs.
MODE
IV
completed
programming experience,
Mizuno's view,
and did
came
this
because they lacked
we had
software productivity," he recalls,
precise distinctions
in
led
to
a
software
a
planning model
still
primitive,
in
good metric for measuring productivity
in
to introduce
and
a
given period of time.
more
scientific
this conviction
"We
measures for
gradually led to more
the productivity data collected between different types of
programs and languages used, as
This work
a
own
This data, based on the
used were
times
simply by lines of code (steps)
to the conclusion that
different
became the basis for
The standard
1969-1970.
in
of its
totally
new
well as the
cost
amount
estimation
of
documentation required.
system
in
1977,
based on
a
multi-factor regression model derived from the "meta model" developed at the
University of Maryland by J.W. Bailey and V.R. Basili, which consists of several
standard model expressions that allow users to select from their own data
different factors that appear to impact cost.
Users can also make adjustments
for productivity improvements. °° Accordingly,
NEC
revises standard-times data
annually and has used comparisons of estimates and actual data for projects to
improve the model continuously."'
the
NEC model
and
his staff at
follows the popular
To make
COCOMO
it
easier to use, the expression of
format proposed by Barry Boehm
TRW.^^
NEC COST ESTIMATION FACTORS AND MEASUREMENT SCALES
Man Power (man-hours)
Program Size (1000 lines
of code,
excluding comments and macros)
Development Tools (%)
Development Technologies/Methodologies
60
(%)
OS/Hardware Interface (%)
Member Experience (years)
Outside-Order Dependency (%)
Specifications Change Frequency
(scale of -2
"
+2)
User Characteristics (-2 " *2)
Product Flexibility (-2 ~ *2)
Novelty/Complexity (-2 ~ +2)
Quality Requirements (-2 ' *2)
Team
"
Ability (-2
*2)
Mizuno 1985,
Source:
NEC used
productivity
its
5.
p.
regression
multiple
model
By establishing
analysis.
a
productivity coefficient value for each factor,
effect
of
each
factor
on
improvement was possible
that
with
factors
the
productivity
each area.
in
"most
both
for
productivity
it
was possible
and,
therefore,
For example,
estimation
range
and
and
mean
to determine the
to
what extent
recent data suggested
room for improvement" were development
tools
dependency (procurement)
(52.6%), quality requirements (43.7%), outside-order
(36.1%),
cost
product flexibility (25.0%), and frequency
of
specifications changes
(22.3%).S9
In
a
the early 1980s, the Software Product Engineering Laboratory developed
version of the cost model to be used on
10 to 20 programmers. This system, called
Tool), used
a
a
personal computer, for groups of
TOMATO
(Table-Oriented Manager's
LOTUS
1-2-3 to allow managers to
relational database format like
track schedule progress, compare actual times to estimates, and do some simple
productivity factor analysis. ^^
NEC used
in
conjunction with these cost and planning tools
a
"quality
accounting system," developed by the Quality Assurance Department at the
Fuchu software factory.
Depsrtment literature explained
which bugs generated into
a
through bugs detected with
program are regarded
a test
as a debt, this debt
and the shipment
61
this as a "system in
Is
Is
repaid
performed when the debt
becomes 0.""'
number
predictions of the
procedures called for
the accounting
More specifically,
of potential
bugs;
(2)
establishment of
a
(1)
bug control
curve; and (3) execution of tests and quality evaluations.
the number of bugs likely to be
data on
This estimated
utilized a simple "reliability prediction model."
Bug control
the number of bugs
factors: (1)
program
corrections
in
size;
(2)
in
a
certain type of software based on past
generated
degree
in
similar
of inspection
programs,
adjusted for 8
and design review (number
of
functional specification, detailed design, and coding, divided by
the number of documentation
pages or program size);
(3)
development form
(new, modified, or transplanted code); (4) language of development and degree
of difficulty;
type of operating system/hardware interface;
(5)
experience of development team members;
and
(8)
sufficiency of
man power.
program, NEC substituted these
in
(7)
frequency
(6)
years of
of specification
changes;
As test data accumulated for
a
the model for the estimated figures.
current
A bug
control curve determined whether or not the detection of bugs through testing
was going according
growth model.
levels,
If
to predicted levels,
test results
based on
a
Gompertz curve
were significantly different from predicted bug
causes of the discrepancy had to be analyzed.
only "[w]hen
all
reliability
predicted bugs are detected."
62
Testing was completed
O
:^
o
M
M
Q
i::q
CM
II
>^
H
M
M.
H
Cd
cd
o
M
<d
pq
o
While the Quality Assurance Department
Division tended to direct
NEC group, much
of
QC
in
the Basic Software Development
activities for software
development throughout the
directives were channelled through the
its
Quality Control) program and quality circles established
in
1981
SWQC
(Software
(see discussion
above) .^^
NEC
gradually extended the
First, the
SWQC
Higher
Once formed, groups
usually once
conducted
in
"^
in
were
development,
in
addition
allow
to
week for two hours,
the
to this
and analyzed data, reported
the establishment of measures to prevent
in
similar errors from recurring (see table).
reviews of programs
a
set targets, collected
on their results, and participated
reviews
series of steps.
managers were then asked
level
employees to devote some time,
these
a
Information Center staff determined which low-level managers
should form groups.
activity.
SWQC program through
in
SWQC
order to catch mistakes early., although
formal
to
teams even performed internal
later stages of development.
"third-party"
To guide group
technical
reviews
activities, the
SWQC
Information Center held training workshops for group leaders and published
various handbooks and manuals, such as "The Seven Tools of
based on convention
QC
techniques used
to use data sorting,
control charts,
then brainstorming,
cause-effect
in
SWQC." This was
other industries, and outlined how
and Pareto charts for data analysis, and
diagrams,
solutions.
SWQC PROGRAM
1)
SWQC grouping
2)
Target setting
3)
4)
5)
6)
7)
8)
Orientation
Data collection
Cause analysis
Consideration of radical measures
Filling in the SWQC report
Proposal and implementation
64
and other methods
to
implement
Reporting
9)
10)
11)
12)
Publication of excellent results
Management evaluation and awards
Repetitive enforcement
Mizuno 1983,
Source:
70.
p.
NEC programmers
According to Mizuno,
control was
a
blue-collar problem."
differences
skills
in
weaker members.
minimize
to
of
Eventually,
idea
in
of
a
however, he and other NEC
NEC's software developers
of
NEC managers, such
teams
the
"They're white-collar workers and they protested that quality
managers persuaded 95%
essentially
resisted
first
"Every programmer was against me," he recalled
joining quality circles.
recent interview.
at
Azuma,
as
people
studying
to join the
promoted the use
together
--
as
a
groups.^
quality
of
means
circles--
reducing
of
among programmers and improving the performance
The groups were only part
differences
among
of this effort, however.
of
Also used
programmers were extensive training
in
structured programming techniques, encouragement of proofreading, program
standardization, and use of software tools. ^^
Mizuno devoted
circles
also
so
much
attention
the
to
SWQC program and
quality
because he considered them essential not only for quality control but
for
individual
communicate and
and team motivation.
cooperate
in
teams,
recognition for achievement through
In
the
well as
SWQC
improving quality and productivity
activities in
through
a
people
considerable
a
year
series of prizes
Mizuno reported significant results from
In
1983 article,
helping
conferences held twice
given to teams.
a
to
program provided
SWQC group
and an awards conference held annually, as
addition
developing software:
65
in
each of NEC's divisions
SWQC PROGRAM RESULTS
GROUP DIVISION
Switching
1
TARGET
RESULTS
Machine time
Down
Transmission
2
1/3
debug
for
Bug
ratio
1.37/KS to 0.41/KS
Bug
Ratio
0.35/KS
Bug
ratio
Source Size
6/Month to 0.9/Month
20KS to 8KS
Object Size
72KB
Spec changes
Down 40%
control
3
Minicomputers
4
Large OS
Large Appli-
to
to
0.20/KS
26KB
cations
Source:
Mizuno 1983,
p.
71
QC
Along with conventional
techniques,
NEC
trained
its
programmers
in a
standardized set of metrics, methods, and tools for quantitative software quality
control
it
called
Technology).
SQMAT
(Software
Quality
This was based on the
developed by Gerald Murine,
a
SQM
Measurement and Assessment
(Software Quality Metrics) system
U.S. consultant.
Developing
SQMAT was
the responsibility of the Quality Assurance Task Group organized
in
formally
1982, which
worked under the previously established Software Productivity Committee.
SQMAT
phase
for
of
procedures called for the determination of quality targets before each
development; planning meetings to discuss quality criteria; checkpoints
measuring
quality;
and
action
proceeding on to the next phase.
of
"Software Quality
Design
plans
for
corrective
measures
before
Factors analyze included an interrelated set
Criteria"
(SQDC)
Requirements Criteria" (SQRC), as noted below.
and
SQRC
"Software
Quality
factors were ranked
order of importance, and measured through several quantitative methods. 97
66
in
RELATIONSHIP BETWEEN SOFTWARE QUALITY REQUIREMENTS CRITERIA
AND SOFTWARE QUALITY DESIGN CRITERIA
M = Maintainability; F = Flexibility;
= Interdependability
S = Security;
Key: C = Correctness; R = Reliability;
U
= Usability;
E =
Efficiency;
SQRC:
C
R
I
M
F
U
SQDC:
Traceability
Completeness
Consistency
Simplicity
Accuracy
Error Tolerance
Modularity
Self-Descriptiveness
Conciseness
Instrumentation
Generality
Expandability
Training
Communicativeness
Operability
Machine Independence
Software System Independence
Execution Efficiency
Storage Efficiency
Access Control
Access Audit
Data Commonality
Communication Commonality
Source: Sunazuka, Azuma, and Yamagishi 1985, p.
67
5.
CONCLUSION
Despite
as
its
early reliance on U.S. computer and software producers, such
NEC managers
and SDC,
Honeywell
insisted
traditional factory models
was strong, seen
automation,
of
productivity.
developing
components,
in
and
Mizuno and other managers also
or art-like approaches often followed
evolution of software engineering
distinctive
in
and
the emphasis on standardization,
linking
felt
of
quality
in
control
to
there were better process-
management and control techniques possible for software,
craft-
a
Influence from hardware production
approach to software production.
reusability
on
in
contrast to the
the industry.
NEC proceeded roughly
The
historical
as follows:
data collection and process analysis
formulation of standard times to improve estimation and cost control
centralization of development for different product groups
factories,
in
permanent
rather than management by projects
processes (procedures and tools) optimized for different product groups
standardization of factory procedures and tools
training of workers
gradual
in
standardized procedures and tools
decentralization
of
development through
establishment
subsidiaries, satellite offices, and subcontracting
formalization and centralization of process
R&D
formal quality assurance training and control program
development of automated tools
promotion of reuse of standardized components
flexible customization
continual evolution of tools,
procedures, management systems
continual improvement of quality and productivity.
68
of
NEC
try
not
did
model
to
software
development
around
hardware
engineering and manufacturing processes as closely as firms such as Hitachi and
Rather, the company developed different factory strategies and
Toshiba did.
structures for different types of software produced
result
was several factory-like systems for
for applications
programs,
in
HEART
STEPS
general,
for operating
in
numerous
STEPS
main product groups --
its
The
locations.
SEA-I for well-understood business
with
systems,
and SDMS for switching systems.
Distinctive about NEC's approach was also top-down direction from executive
committees,
a
central laboratory, and the quality assurance department
basic software development division.
distribution
of
development
in
the
Progress occurred steadily even though
across
activities
so
many
different
sites
and
subsidiaries, as well as the tendency of departments to prefer established tools
and methods, made
it
difficult for the central
committee and Software Product
Engineering Laboratory to impose new systems such as SDMS.
The pattern
of process
development
in
NEC
also occurred,
other Japanese firms that built software factories.
distributed
management preceding advances such
development,
automation,
components, and flexible customization
quality
--
is
assurance,
still
centralization,
"
standardization
to
of
any firm that
the engineering and
retain flexibility in product development.
69
and
as standardization,
perhaps applicable
wants to move beyond job-shop approaches and "rationalize
production process, but
less, at
Furthermore, this type of
strategic and organizational evolution -- process analysis,
elimination of project
more or
REFERENCES
The current version
A. Cusumano,
paper from this research project is titled
Factory Approach to Large-Scale Software
Development: Implications for Strategy, Technology, and Structure," Sloan
1987 Working Paper #1885-87 Revised.
School of Management
Other
completed papers are "A U.S. 'Software Factory' Experiment: System
Development Corporation," Sloan School of Management 1987 Working Paper
#1887-87 Revised; "Hitachi:
Pioneering a 'Factory' Strategy and Structure
1987
for Large-Scale Software Development," Sloan School of Management
Working Paper #1886-87 Revised; and "Toshiba's Fuchu Software Factory:
Strategy, Technology, and Organization, " Sloan School of Management 1987
Working Paper #1939-87.
1.
of the main
"The
Michael
,
.
.
,
2.
NEC
Corporation Annual Report 1987.
Japan Economic Journal, 13 December 1986, p. 22; interview with Kaneda
Hiromu, former NEC managing director and current corporate advisor,
3.
9/26/85.
June 1987, pp. 30-32.
4.
Datamation
5.
Interview with Mizuno Yukio, 9/26/85; and Usui Kenji, "NEAC kaihatsu
(2)" (History of the development of the NEAC), Computopia September
shi
.
15
,
1975,
p.
17.
Usui, p. 21; Nippon Denki Kabushiki Kaisha, "Konpyuta sangyo no genjyo
NEC" (The current state of the computer industry and NEC), NEC
Information Processing Planning Office, July 1985. The initial ACOS models
were designed in cooperation with Toshiba.
6.
to
7.
Usui, pp. 22-23.
Usui, pp. 22-23; Nippon Denki Kabushiki Kaisha, Nippon Denshi saikin 10
nen shi (A history of the last 10 years of Nippon Denki), NE$C, 1980, p. 86.
8.
9.
Mizuno interview, 9/26/85.
10.
Kaneda interview, 9/26/85.
11.
Fujino interview, 9/8/87.
12. Mizuno Yukio and Mitsugu Mamoru, "Sofutouea bijinesu no mirai" (Future
of the software business), Konpyuta
April 1986, pp. 85-86.
.
70
13.
Mizuno interview, 9/26/85.
14.
Nippon Denshi saikin 10 nen shi
15.
Fujino interview, 9/8/87.
16.
Fujino interview, 7/28/86.
pp. 230-231; annual report, 1976.
,
"Sofutouea enjiniaringu no hitsuyosei" (The need for
17. Mizuno Yukio,
software engineering", Joho shori Vol. 16, No. 10 (October 1975), pp. 836.
837.
18.
Mizuno 1975, pp. 838-839.
19.
Mizuno 1986, p. 91.
20.
Mizuno 1986, p. 92.
21.
at
Kiichi Fujino,
"Software Development for Computers and Communications
NEC," Computer
November
.
22.
Fujino interview, 7/28/86.
23.
Fujino 1984,
24.
Fujino interview, 9/8/87.
25.
Fujino,
26.
Fujino interview, 7/28/86.
27.
Azuma interview, 10/1/86.
28.
Hirai
p.
1984,
62.
57.
pp. 57, 62.
interview;
also,
NobuyoshI
Management System for the C&C
Development
"C&C
p.
No. 81
Satellite Office
,
(April 1986),
(April 1986), pp.
and Networks,"
Tsuchiya
Satellite
et
al.,
Office,"
"A
Control
and
NEC Research and
19-23; and Sen Nakabayashi et al.,
No. 81
NEC Research and Development
,
pp. 8-18.
7/28/86; Mizuno interview, 9/26/85.
29.
Fujino interview,
30.
Azuma interview, 7/28/86; Mizuno interview, 9/26/85.
31.
Azuma interview, 9/26/85.
32.
Fujino interview, 7/28/86.
Motoei Azuma interview, V/28/87.
Azuma at the time was manager of
the Software Management Engineering Department in the Software Product
Engineering Laboratory.
33.
71
(NEC Software Product Engineering Laboratory),
K. Honda et al.
"Research on Work Environment for Software Productivity Improvement,"
34.
COMPSAC'85
.
1985.
pp.
1-2.
35.
Honda 1985, pp. 3-8.
36.
Azuma interview, 7/28/86.
37.
Fujino interview, 7/28/86; Mizuno 1983,
38.
Fujino interview, 7/28/86.
39.
68.
Yukio Mizuno, "Software Quality Improvement." Computer March 1983,
40.
Fujino interview, 7/28/86.
41.
Azuma interview, 7/28/87.
42.
Azuma interview, 7/28/86.
43.
Mizuno 1983,
44.
Interviews with Fujino and Azuma, 7/28/86.
45.
Interviews with
46.
Fujino interview, 7/29/86.
p.
69.
.
p.
p.
69.
Azuma and
Fujino,
7/28/86.
Interviews with Horie Susumu, Engineering Section Manager, Basic
Software Division, NEC Software Ltd., and Yamaguchi Hiroshi, General
Manager, Basic Software and Application Software Development Division, NEC
Software Ltd., 9/2/87.
47.
Interviews with Horie and Yamaguchi (NEC Software) and Akira Yamada,
Manager, Software Education Dept., NEC, 9/2/87.
48.
49.
Azuma and Mizuno
1984,
p.
50.
Azuma and Mizuno
1984,
pp. 88-89.
51.
Its
M. Azuma and Y. Mizuno, "STEPS:
Integrated Software Standards and
Productivity Impact," Proceedings of COMPCON 1981
IEEE, p. 83.
52.
Fujino 1984, p. 59.
53.
Azuma and Mizuno
1981,
pp. 85-86.
54.
Azuma and Mizuno
1984,
p.
86.
55.
Fujino interview, 9/8/87.
56.
Azuma and Mizuno
p.
87-88.
88.
.
1984,
72
57.
Azuma and Mizuno
1984,
91.
p.
Interviews with Hirai Yozo, Manager. Quality Assurance Dept.,
Software Development Division, NEC, 9/8/87.
58.
59.
Basic
Hirai interview.
A Humanized Documentation Technology,"
M. Azuma et al., "SPD:
IEEE
Computer
Society's International Computer Software
of
the
Proceedings
and Applications Conference (COMPSAC) November 7-11, 1983, p. 308.
60.
.
61.
Azuma and Mizuno
62.
Fujino 1984,
"NE Probes
February 1985,
63.
1984,
91.
p.
59.
p.
AD System
for Software," Electronic Engineering Times
Masao Matsumoto, "SEA/I
IEEE SoftFair '83 Proceedings
64.
,
Application
p. 378.
65.
Masao Matsumoto, pp. 376-377.
66.
M. Matsumoto, pp. 378-379.
"NE Probes
February 1985,
67.
.
11
66.
p.
AD System
Software Productivity System,"
for Software," Electronic Engineering Times
.
11
66.
p.
68. Hiroyuki Kitagawa et al., "Form Document Management System SPEDOQ
-- Its Architecture and
Implementation," Proceedings 2nd ACM-SIGOA
Conference on Office Information Systems
.
June 1984 (Toronto).
69.
Hirai interview.
70.
Interviews with Hirai and Fujino, 9/8/87.
71.
Fujino interview, 9/8/87.
72.
Hirai
Interview.
NEC Corporation, "QA System in NEC: Scientific Control of Production
and Quality in NEC -- Basic Software," unpublished internal document,
September 8, 1987, pp. 3-9.
73.
NEC Corporation, Software Product Engineering Laboratory,
(Structured Programming Diagram)," undated manuscript.
74.
75.
Hirai interview.
76.
Fujino interview, 9/8/87.
77.
78.
"QA System
in
NEC," pp. 10-12.
Hirai interview.
73
"SPD
.
79.
Hirai interview.
80.
Hirai interview.
Kanji and
(Project control tools),"
724.
Iwamoto
81.
Okada Tadashi (NEC), "Purojekuto kanri tsuru"
Joho shori Vol. 20, No. 8 (August 1979), pp. 719.
Uenohara Michiyuki (NEC) et al., "Development of Software Production
and Maintenance System," Research and Development in Japan Awarded the
Okochi Memorial Prize (Okochi Memorial Foundation, 1984), pp. 26-32.
82.
Uenohara
83.
et al.,
p.
32.
Hirai interview; Fujino interview, 9/8/87; Kanji Iwamoto (NEC), et al.,
"Early Experiences Regarding SDMS Introduction into Software Production
Sites," NEC Research and Development January 1983, p. 54.
84.
.
Iwamoto 1983, pp. 54-59.
85.
SeeJ.W. Bailey and V. R Basili, "A Meta Model for Software Development
Resource Expenditures, " Proceedings ICSE, Vol 5, pp. 107-1 16 (March 1981 )
86.
.
.
87.
Mizuno interview, 9/26/85.
Yukio Mizuno, "A Quantitative Approach to Software Quality and
Productivity Improvement," NEC Corporation, ca. 1985, pp. 2-3. See also B.
W. Boehm. Software Engineering Economics Englewood Cliffs, N.J., Prentice88.
.
Hall,
89.
1981.
Mizuno 1985,
p.
6.
Mizuno interview, 9/26/85; Software Product Engineering Laboratory,
"Sofutouea kanrisha shien tsuru TOMATO" (Software managers' support tool,
TOMATO), undated manuscript.
90.
based on "QA System
91.
This section
92.
Fujino interview, 9/8/87.
93. This section
is
is
in
NEC," pp.
14-25.
based on Mizuno 1983, pp. 69-71.
94. Bro Uttal, "Japan's Persistent Software
p. 154.
95.
Azuma interview, 9/26/85.
96.
Fujino interview, 9/8/87.
Gap," Fortune
,
15 October 1984,
Toshihiko Sunazuka, Motoei Azuma, and Noriko Yamagishi, "Software
Quality Assessment Technology," Proceedings ICSE 1985, pp. 1-7.
97.
.
k53k 062
74
Date Due
^^i^
r^5
.9^
%\w
HB2
DEC 2?
DEC 23
JAM.
^'^li^
1991
8 iBm
Lib-26-(57
MIT LTBRflRTFS
3
TDSD DDS 13D
fibb