Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 27
CHAPTER 111
Tec 1no Oslo
Cal Considerations
To achieve an effective SSA process in the future, a number of applicable
technologies will need to be exploited. In this chapter the panel con-
siders those technologies. Indeed, the panel's evaluation of computer
technologies has been developed at such length that it has been placed
in the Appendix--though this is not intended to diminish its importance.
While it is obvious that semiconductor technologies and data base and
system software techniques are central to the total system design, it may
be less obvious how important to system design are the considerations of
modeling, Communications, user terminals, applications software, and
human factors. These topics are examined here.
INTERFACING AND MODELING
The panel strongly supports the SSA planning group in its intentions
to (1) emphasize system modularity in the architecture and design of the
future system and (2) employ advanced modeling techniques as a means of
formulating, communicating, testing, and updating the plan for the future
process from the architecture phase through design, implementation,
transition, evolution, and evaluation. The essential role of modularity
in dividing a very large system into subsystems and components of compre-
hensible and manageable proportions was discussed in Chapter II. Here
the panel relates the concept of modularity, including the specification
of definite interfaces among the subsystem and component modules, to the
notion of modeling and provides specific explanation of the use of
modeling.
System Modularity in Relation to Interfacing and Modeling
27
The essential idea of modularity is to subdivide a large and
complex system into parts that interact with one another across
well-defined interfaces. The specifications for the parts should be
functional and relate to the needs of people, as well as be free of
implementation details. The specifications are cast in terms of types
and amounts of information, clearly describable transformations of
information, allowable time delays, and constraints imposed by privacy
and security considerations. If a module must be complex internally
OCR for page 28
2g
in order to realize simple interfacing with other modules, the complex
module can itself be further subdivided. There is no theorem stating
that repeated subdivisions must ultimately result in simple modules with
simple interfaces. But practical experience suggests that such is indeed
the case.
After discussion with the GAS planners, the panel has concluded that
a basic tenet of the future SSA system should be modularity at all levels.
The interfaces among the modules need to be clear and definite. The best
way to determine whether an interface specification is clear is to try to
program it.* If the interfaces can be represented in computer-program
form, as a software system of data plus processing procedures, it is vir-
tually certain that the modules as well as their interconnections can be
modeled. When used for system modeling, interface specifications provide
a description of the system that actually works to design. There is no
guarantee that if the model operates well, the actual process or system
will do equally well. Still, there are two conditions that are construc-
tive: (1) If the model does not operate well, neither wi 1 1 the actual
system;-* and ~ 2 ~ if the model behaves well and the actual system turns
out not to do so, the trouble probably lies in the implementation of the
modeled specifications and not in the specifications themselves.
Modeling Methods and Techniques
The modeling that the panel envisions as a fundamental part of the
development of the future system is not the routine application of some
single, magical technique that is available to solve all the operational
problems of the SSA. Indeed, there are many methods and techniques ~
The future SSA system has a number of prospective subsystems that could
profit from well conceived modeling techniques. Examples of such sub-
systems are the operation of the data base under various conditions; the
flow of clients and workloads at a field office; and the operation of
the nationwide communications network under a range of traffic loads.
It will take expert judgment plus experimentation to select the appro-
priate techniques and adapt them to the situation. All the methods and
techniques start with problem definition, which must be guided by
systemic modularity and must yield good interface specifications.
For modeling the interactions and interrelationships at the upper
levels of the future system--that is, for macroscopic modeling--there
x The specification must also be "sufficiently complete." Because the
specification is abstract, it will not be complete in the full detail
of actual) ty. Programing does not provide a demonstration of
"sufficient completeness, " but it creates a clear and definite
representation with respect to which experts can make good judgments
about completeness.
*^Barring accidental compensations in which design errors are corrected
by implementation errors.
OCR for page 29
29
are two promising approaches: (1) "dynamic modeling" by programming in
a high-level function-application language such as LISP or APL and (2)
'simulating" by programming in a simulation language such as DYNAMO,
GASP, GPSS, SIMSCRIPT, or SIMULA. At lower levels--for microscopic
modeling--those two approaches continue to work. Here, more specialized
techniques enter the picture. Finite state machine methodology, as
applied by IBM on a fairly large scale in the development of its system
network architecture, and Petri Nets, as developed at Applied Data
Research, Inc., the University of Michigan, and M.I.T., seem especially
promising for certain applications.
Applications of Modeling
In the most ambitious application of modeling to a computer-infor-
mation system development program such as the one under consideration,
the model could be used to represent the concept, architecture, design,
schedule, medium of communication, and conditions in which actual
components are first tested. The model also would be the setting in
which prospective users first become acquainted with the new process/
system and trained in its use. The grand model would be updated as
each decision is made to modify the design or refine the developmental
schedule, and as each step of implementation is taken that provides a
more certain measure of performance. From the earliest phases of
planning onward, there would be a running model of the process/system
and something like a dynamic PERT chart of its developmental situation.
The process of development would then be essentially the perfection
of the grand model, and the process of implementation would be essen-
tially its realization.
System developers in the information industries are adopting the
methodology just described. Even so, it would be rather risky just
yet to put all the future eggs into one dynamically modeled basket.
The model might turn out to be harder to develop than the actuality.
The panel, therefore, stops short--but only a little short--of
recommending a switch to a revolutionary new scheme of model-based
development. It supports, in particular, the plans for task and job
modeling that have been developed in connection with the human factors
test and evaluation facility, and it urges that major efforts be made
in all of the following areas of modeling:
0 comparisons of alternative architectures, including various
distributions and centralizations;
· dynamic representation of process and system designs at various
levels;
modeling of human interaction, through terminals and hard copy,
with the computer-communications system;
communications network modeling;
OCR for page 30
30
computer-based scheduling and reporting of progress;
· computer-based cost projections, reporting, and analysis; and
.
use of models in education and training of prospective users.
The idea is to give modeling a real chance to overcome some of the
chaos and confusion that have beset the development of large and complex
information systems in the past. Wherever it is unproductive, the
modeling effort should be examined carefully to make sure that it has
been genuine, but there is no absolute need to press on with it, because
more conventional methods can be employed as back-up.
At the very least, a major modeling effort would put a great deal
of the development work on-line in a large time-shared computer--
an essential prerequisite for the successful prosecution of a large
developmental program like that of the SSA.
COMMON ICAT ION S
SSA Communications Requirements
The SSA's future communications requirements fall basically into
the following four categories:
· High-speed, high-capacity communications facilities between
major computer/data base storage centers.
· Medium or low speed, low capacity communications facilities
between SSA district offices and the major computer facilities
(this may include low capacity facilities to communications
"hubbing points," from which high capacity facilities would be
used to the computer facilities).
Mobile communications (low speed) for field operations.
SSA administrative networks (voice grade communications facili-
ties) between all locations.
Decisions about major system alternatives (regional versus central
data base), as well as about how much information is to be transferred
between SSA facilities, will have a significant impact on the final
communications requirements and network design. For example, if only
one major computer facility (with associated single data base) is
required, the design of the communication network, placement of communi-
cations nodes, interconnection of facilities via high-speed data lines ,
will be different than the design of a communications network to
interconnect several major computer facilities with multiple data bases.
OCR for page 31
31
SSA Future System Communications Solutions
_
In broad terms, the SSA has the following options for meeting the
complex communications needs of the future process:
Build a complete communications system from scratch (construct
a microwave system, launch satellites, and so forth).
Bootstrap the SSA requirements onto another major government-
owned network.
· Procure raw facilities or services from common carriers and
design and develop a configuration of its own communications
network by procuring the appropriate terminal/communications
processors, multiplex equipment, etc. As part of this option,
different types of raw facilities would be considered, including
digital facilities (DDS), analog facilities (private line, WATS,
MTS), bandwidth facilities, and so on.
Procure complete data network capabilities from value-added
type common carriers.
Procure complete integrated system capabilities from a carriers
Some of the alternatives may be eliminated readily. For example,
SSA would be hard-put to justify the cost of pursuing the first alter-
native. Start-up and continuing operational costs of a privately owned
communications network would be prohibitive based on any traffic
projections for the SSA's future system.
Similarly, the second alternative would require a significant amount
of interaction and cooperation WIth another agency. At Ends come, ~c Is
unlikely that this option would merit consideration, except for continued
use of the Federal Telecommunications System (FTS).
The panel recommends that the comunications system design be struc-
tured as a separate and identifiable task and be concerned only with the
last three possible options, except as noted above.
The final approach to the network design will depend to a large
extent on (1) an evaluation of the current network (SSADARS) and (2) how
much of the day-to-day operational responsibility and management the
SSA wants to assume over the network. At the present time, SSA utilizes
the government FTS system for most of its administrative communications.
Although the panel is not suggesting that SSA look toward a separate
administrative network, it is important to note that once a large,
sophisticated data network is put in place, it is possible to incorporate
voice communications into that same network.
Communications-Related Software Requirements
Problems relating to the software and computers associated with the
network design will be dependent, to a large degree, on whether SSA
OCR for page 32
32
decides to procure complete raw facilities and design and implement the
network using an in-house staff or to procure services from a vendor
with an in-place data network (so-called value-added facilities). In
the latter case, most of the infra-network design and software will
already exist.
The most fundamental concern in software design for a communications
network is that of its interfaces and protocols with the future system
and associated applications. Although the level of sophistication in
the terminals (or terminal clusters) of the future system can have some
impact, the panel recommends that the communications network be treated
as a "transparent conduit." In this context, the word conduit is not
meant to imply raw facilities or physical pipes. Rather, the network
would be transparent when viewed from the applications programs perspec-
tive. More specifically, the applications programs and software systems
will perform their functions completely separate from the communications
network. Information to be transmitted will be "handed off" to the
network; the application programs will not be concerned with network
operational functions, such as the particular routing, and data speed.
The concept of separating the network from the applications, as proposed
by the panel, is similar to that utilized within industry.
Impact of Communications Technology
No major technological development in communications is needed to
meet the implementation requirements of SSA's proposed future system.
Although communications breakthroughs will certainly come in the form of
fiber optics, say, and lasers, none are required to meet the SSA require-
ments. Today's communications systems knowledge and hardware capability
are adequate to meet SSA future needs in any desired design concept.
The network design problem and the required technology associated with
the SSA future system are comparable to those of several industrial
organizations that have existing networks.
New developments in the field of communications could, however,
improve the future SSA process. Therefore, the network design by SSA
should remain flexible in the early days of implementation. Further-
more, the system should not be planned around communications systems
or facilities that are so special in nature (whether they exist today
or are proposed for the future) that the communications network design
would dominate the system design. The network should be so structured
conceptually as to allow future changes which may be beneficial.
Other technological considerations include:
.
It is assumed that the "price-per-unit-of-information-trans-
ferred" will decrease in the future. This will happen even
though the price of raw facilities and/or the cost of
communications equipment will probably increase. This implies
that, even though the relative cost of the communications
system is small when compared to the overall cost of the future
OCR for page 33
33
system, the communications cost should decrease as technology
advance s e
o Different communications systems should be considered to meet
different needs . For example, facsimile broadcast and/or video
transmission may suggest that satellite links serve as an effec-
tive communications mode, whereas other transmission facilities
may be considered for other communications needs O Specific
technologies may enhance specific solutions to meet the SSA's
requirements .
@' Security considerations will be an important factor in the
design of the communications system.
Parse 1 Recommends t ion
The future SSA commune cations network should be a widely dispel sea,
sophisticated, highly interactive system that enables hi gh transmission
reliability, minimum cost ~ adaptable lity to terminal and host equipment
types, and flexibility in call set-up and data transport. The data com-
munications network that best satisfies these requirements has the
Following characteristics:
It makes use of a packet-trans~iss~on technology with error
detection/correction protocols to satisfy reliability and cost
considerations.
It is a hybrid switching network supporting both line and
packet switching and permitting an economical choice of the
best mode of communications.
It has features that facilitate communications among a wide
range of incompatible terminals and Computers with differing
protocols, formats, speeds, and codes.
The 'abbe of communications network that the panel believes SSA
should develop is illustrated in figure ~ (page 34~. Terminals and/or
d~s~ribntea p-ocess'ng locations may be connected to the switching node
&i rectly or via multi-party lines, depending on the volumes of traffic
and the economics of the network. The node would adapt to the protocol
and speed or the interacting terminal. The network consists of high
speed lines utilizing ~ packet-type protocol in a full-duplex mode.
Link-by-~nk error detection and correction is inherent. Each node
matches the protocol of ~ he host complex and uses high speed lines to
utilize the hos'_ comer ex' s capability efficiently. The network inher-
ently provi des speed and protocol converse on for connections between
non-co~pacib~'e terminals ~
An attenuate approach which is an extension of this concept, has
been proposed for possible consideration. This approach incorporates
OCR for page 34
34
i)
At\
Q
Cal
in
, . ~
O I ~
by'`
1
~ I
~,1
c
o
._
._
C —
~ .'
Qua
DC O° 1-
_0-
By\
O_
\
\
\
\
\
\
~ Q
i,
o: ~
\ 0
O '~0 I
~ /
,~
\
a, ~
w ·_
CL ·— ~
·= C, O
Q a,
a.= a,
I J Z
\
\
\/
'a ~ O
UJ °
4- A,
~ C.,
To o
LL A
\ ~
J
\ /
~0
I ~ ~
FIGURE 5 Data Oriented Network
OCR for page 35
35
all terminal interaction functions into the basic design of the communi-
cations network. The communications nodes would poll the terminals,
provide terminal screen formats and other terminal entry aids, edit the
data before transmitting to the host, and store and accumulate data for
later delivery, if this is required.
Summary
The panel has the following observations and recommendations in the
area of the future communications subsystem design:
.
.
The design effort for the communications subsystem should be a
separate and identifiable design task. Interface points,
appropriate protocol, etc., should be established and coordina-
ted with the main system design effort. The network design
effort could be structured to have a short term positive impact
on SSA's current communications needs and then evolve to meet
the requirements of the future system.
The communications subsystem should be designed so that it can
be supported by today's communications capabilities rather than
be dependent on communications systems or technologies that may
be developed in the future.
· The communications network should not be the driving factor in
the design of the SSA system, but rather the future system
should be designed with major concern directed toward the data
base, computer facilities, and work force. The communications
system should be designed as a separate effort to serve the rest
of the system. The communications system and network should be
structured as a transparent conduit that transmits the informa-
tion required by the future system. The design should be
compatible with the SSA functional systems and applications
design. A decision, for example, as to whether the future sys-
tem should be structured around regional computer centers and
a regional data base organization should be dictated by the
functional and operational requirements of the future system
and not by the design of the communications network.
· The cost of the communications system is not a dominant factor
in the overall future system design and should not bias any
major considerations, such as regionalized data base storage.
The communications system design can be adapted to any concept
without significant cost variations, particularly as related to
the overall cost of this project.
OCR for page 36
36
TERMINALS
SSA Considerations
A key element in SSA's future system will be the selection of the
actual setting in which the end terminals will be used. The decision
to place a terminal on every desk would provide fingertip access to the
full system. However, because of the expense and the possible adverse
human reaction, this approach should be evaluated against other alterna-
tives, such as shared and off-line use in conjunction with a modified
interviewer interface with the client. Optical character input could
offer a middle-of-the-road approach in which traditional forms are
processed for entry into the system at the conclusion of an interview.
Display quality, function, and price of the terminal are obvious
tradeoffs. Color could be effective for highlighting the information
to be presented. Some limited graphic capability could be useful for
preparation of reports. The choice of printers (thermal, ink jet,
mechanical) and display (storage, refresh) will be influenced by the
terminal's planned location in an office, because noise and lighting must
be considered. Convenience and high volume print capability may dictate
that different types of printers be used for different functions within
the same facility. The degree to which system functions are distributed
will affect the need for storage and programmable intelligence at local
work stations.
In considering terminal specifications, many factors need attention,
including line protocols for network attachment, reliability, alternate
backup procedures to cover power failures, and support programming. In
addition, serious consideration should be given to procuring communica-
tions software and developing only application code.
Data privacy and security must be addressed explicitly. Data access
limitations and data encryption during transmission are sensitive aspects
in overall system design that will have an impact on terminal selection,
use, and features. Terminal placement must provide at least the same
degree of confidentiality as does today's client/interviewer method.
A degree of commonality among work stations is desirable. SSA may
decide to design a minimal configuration for all offices, and to use
standard enhancement features to achieve functional capability in excess
of that provided by the basic work station.
Current Status
Today's available, off the shelf terminals range widely from simple
hard copy typewriter devices to highly interactive cathode-ray tube
displays. Configurations can range from central processor-dependent,
host-connected devices to self-contained, user-programmable clusters
with their own disk, tape, and cassette storage peripherals, capable of
off-line, store-and-forward, or interactive use. Attachable alter-
natives range from plug-compatible units interchangeable among several
suppliers to unique channel or teleprocessing connections. User
programmability can be restricted to a central processor, distributed to
OCR for page 37
37
an intermediate controller or minicomputer separated from the central
host or contained in the terminal work station. Terminal logic can vary
from hardwired to microprocessor control.
Display devices offer a wide range of features, built-in functions,
price ranges, and connection protocols. While monochrome or black and
white displays have been available for many years, some vendors now
offer color capability. Screen sizes vary from the smaller sizes of
100 to 200 characters, through medium sizes capable of displaying
several hundred characters, to larger sizes capable of displaying
several thousand characters. Cathode-ray tubes are most prevalent,
although plasma or gas panel displays are available. Both alphanumeric
and graphic displays are widely available. Channel attachments for high
speed or teleprocessing capability for remote work station use are
geographic and performance choices. Functions such as scrolling, split
screen, formating, multiple character fonts, upper and lower case fonts,
large type fonts, text editing, and field checking can be provided by
the terminal itself or by central host/minicomputer programming.
Associated with the display are various input/output devices. For
hard copy output, this permits the use of matrix, ink jet, thermal, or
line printers which attach to the display, controller, or computer.
Light pens are a popular interactive input medium. Optical scanners are
available for direct input of pre-printed or hand-lettered forms, as
are mark sense and magnetic readers. Keyboard input can be a standard
typewriter or a special purpose unit.
Support programming systems abound. COBOL, RPG, FORTRAN, and PL/1
are readily available, as are many unique, special languages. Data base
and inquiry program products support a wide variety of display terminals.
Access method, communications control, and network management programs
are available so that users can concentrate upon developing application
programs without having to acquire special talent for the specialized
communications tasks. Diagnostic programs are also available to aid in
isolating fault.
Anticipated Trends
Terminal prices are likely to continue to decline, both in terms
of actual dollars and of increased functions for the same or moderately
higher costs.
Intelligent microprocessor-controlled displays will further
obscure the distinction between controller and display as intelligence
shifts increasingly to the display terminal. The trend toward intelli-
gent work stations should also result in suppliers offering additional
terminal functions with increased possibility of user customization.
Color and mixed alphanumeric-graphic features are expected to
become more widespread. Improvements in lines, speeds, and network
support will make large networks practical for more users.
Technology advances will be evolutionary. Plasma technology offers
the potential for more compact, lower-powered display terminals, but
cathode ray tubes should dominate. Electroluminescent, light-emitting
diode, liquid crystal, and deformographic technologies are among those
OCR for page 38
38
that could move from research to development status for specialized
display usage late in this decade or in the next. Increased screen
content, as well as physically larger viewing areas or projection dis-
plays, are anticipated. Image density will improve and image usage
should increase. However, new display devices should remain compatible
with previously obtained computer attachments and programming support.
Use of optical character readers for input and mixed graphic/image
alphanumeric applications should grow in the foreseeable future.
The major commercial thrust will increasingly emphasize broader
system support. Extensive programming support, coupled with functions
customized to the user and created by unique microcode, should further
simplify incorporation of terminal stations into major computer networks.
The most significant advances in display stations should come in color
cathode-ray tube (CRT) displays--both in quality and price as well as
in the peripherals--especially local storage media that can be attached
to a terminal. Bubble technology holds the prospect of non-volatile
electronic memory in terminals to complement mechanical media such as
disk, tape, and cassettes.
APPLICATIONS SOFTWARE
Some 300 years ago the English philosopher John Locke, seeking to
explain the adaptability of human behavior, referred to the human
mind as a tabula rasa, a blank slate on which the impressions received
from daily experience are engraved. Today, to use a metaphor in tech-
nology, this concept can be employed to describe that most malleable of
machines--the computer.
Probably the most significant characteristic of computers is their
programmability--their functional performance can be tailored to specific
information processing tasks. This tailoring is brought about by the
patterns and sequences of instructions known as computer programs. Thus,
the objectives of a data processing system are achieved by way of its
programs and through their integration with each other and with new
data.
In order to realize these objectives, it is necessary to define the
goals of the system and to take the steps that are best calculated to
achieve them. One cannot tell whether a system is successful until one
first translates the concept into functional characteristics for which
standards of success have been defined, and then establishes an
appropriate organization and methodology to ensure that the standards
are applied to the system's development.
Systems that have been designed with every expectation of success
have turned out unsuccessful in operation, or have even had to be dis-
carded before implementation was achieved. Such unfortunate experiences
result from limiting success criteria to (1) those that are most easily
quantifiable--namely, the project cost and duration, (2) the conditions
existing at the time the system was initally conceived, and (3) the
operations of the computer system itself, with the consequent exclusion
of the external and particularly the human environment.
OCR for page 39
39
The existence of these limitations can adversely affect the rele-
vance, efficiency, and maintainability of the system. Some specific
illustrations follow.
System Relevance
The principal prerequisite for program relevance is a realistic
detailed description of the functional requirements the programs are
intended to satisfy. It is imperative that management appreciates its
necessity and that this task be completed before program design is
undertaken.
This is even more important in the development of on-line systems
than it is to those operating in the batch mode. In batch system
development, a reasonable though somewhat artificial interface exists
between the operations of an office and its often physically remote
computer systems. In on-line systems, on the other hand, computer
operations are essentially fused with those of the office. Such matters
as the sequence in which data is entered, the degree to which the
terminal operator looks to the computer for assistance, the degree to
which such assistance is provided by the computer program by prompting
and other techniques are matters of joint and equal concern to the
programmer and to the office personnel. The definition of functional
requirements and the design of the programs that satisfy those require-
ments are much more intimately intertwined than is true in batch systems.
This coupling must be explicitly defined in the initial development phase
when functional requirements are being examined. Only through such
definition can adequate information be made available to the computer
system designers and programmers and the relevance of system operations
be assured.
System designs for on-line systems are likely to be much more
lengthy and detailed than a batch system-oriented management is likely
to expect or appreciate. The added time and cost must be understood and
supported, if the subsequent program products are to achieve the desired
degree of operational success. One must consider the individuals
involved and their everyday operations. They are no longer outside the
computer system, looking in. They are an integral part of it.
It often happens that the performance requirements of a system are
limited to those that exist at the time a study is undertaken. Existing
requirements are necessary, but hardly ever sufficient. Changes in
requirements are not only inevitable, but are likely to occur at an
accelerating rate in the future. A successful system is dynamtc--
constantly compatible with such changes under varying conditions. Yet,
inestimable amounts of money have been spent in modifying systems to
expand a data record by only one position to accommodate an increased
range of data values, because the system designer had not anticipated
that it would ever be needed. The SSA should plan to accommodate as
wide a range of changes as possible. System relevance is not merely a
goal to be achieved, it is to be an essential characteristic of the SSA
system throughout its useful life.
OCR for page 40
40
System Efficiency
-
Overall system efficiency generally has meant the maximum use of
systems resources such as machine cycles, memory, secondary storage, and
communications lines. With the increasing development of interactive
programs, attention must also be given to the more productive use of the
human resources involved. In on-line systems, office operations and
computer operations are so integrated that neither one can be performed
efficiently without the other. Efficient organization of instructions
within a computer program is for naught if the terminal operator does
not understand what is expected. Similarly, office operations cannot be
conducted efficiently if the computer operations with which they are
intertwined are slow or inefficient. Such mutual efficiency is called
the "man-machine interface." It is likely to be achieved only by the
direct introduction of operating personnel into the design process.
Systems must be efficient from the users' points of view as well as
the computer' s. The arbitration of situations where these demands
conflict must be viewed as one of the project management's most impor-
tant responsibilities.
Maintainability
. _
System maintenance may be defined as the attempt to preserve or
improve the accuracy and efficiency of a system in the face of newly
discovered or newly altered circumstances. A rule of systems develop-
ment is that maintenance is unavoidable, but should be minimized. It
-is usually costly and time-consuming to perform.
Maintenance may be minimized in either of two ways: (1) by ensuring
immunity from changes that can be foreseen and avoided initially, and
(2) by ensuring responsiveness to changes that cannot be avoided or
foreseen.
The key to successful software maintenance, in other words, lies
in the original design and concept of the system. Much can be done at
the outset to make the system easy or difficult to maintain. Therefore,
maintenance should be considered as an integral part of the initial
system design. Some of the principal factors to be considered:
o The more flexible a program is to begin with, the less mainte-
nance it will require later. Such flexibility can be attained
only by a clear definition of what each program is to do,
combined with a full test of the program to ensure that its
actual operation conforms with its planned performance.
It is also generally true that the simpler a program is,
the more likely it is to remain relevant. Unfortunately, it
is often the case that the more skillful the programming
personnel are, the less likely they are to content themselves
with writing simple programs. It is important for the system
designer to observe the principle that the simplest of several
possible solutions to a problem is the best. Assurance of
such simplicity requires systematic application of the many
OCR for page 41
41
o
practices that have been developed for the simplification of
program development. These include, the use of "top-down" and
structured design and programming techniques, the use of table-
driven programs, the isolation of highly variable data and
specialized functions in self-contained and easily accessible
and modifiable modules.
The important consideration, however, is that such
principles not only be enunciated, but that their practice be
institutionalized. Programming standards and practices are
often pronounced with great fanfare. Equally necessary, but
often absent, are strong management support and a technique
for rewarding adherence or penalizing indifference to these
principles by programmers and designers.
While it is important to minimize the need to change programs
it is equally important to ensure responsiveness to changes
that need to be made. Even the most perceptive of system
designers will be unable to anticipate all innovations --'
changes that may occur.
It is imperative that appropriate resources be quickly
available for such accommodation. One resource is detailed
system and program documentation. This must be complete and
uniform so that a general familiarity with its character can
be established easily. The structure of programs must reflect
the same general approach so that each program does not become
a new mystery to unravel. One of the very serious problems in
program maintenance is the time it takes the maintenance
programmer to understand what has to be done before he can
correct the problem or make the necessary change. This can be
minimized by making the original code simple and uniform.
Maintainability will be enhanced by other factors as
well:
o
Use of a single commonly employed high level
computer language, such as COBOL. It is essential to
use a language that is commonly known and for which
expert programmers can be acquired easily and
inexpensively. Also, it is important to avoid the
use of different languages for related programs,
lest a programmer be required who knows all of the
languages involved.
Continuity of program operation will be fostered by
the continuity of the personnel associated with the
project. If the people who design a system are per-
mitted to turn it over when implemented to a separate
group of maintenance personnel, a substantial volume
of invariably undocumented knowledge will be lost.
The incentive to implement a program properly will
be increased if the responsibility for its maintenance
. ..,
OCR for page 42
42
is shouldered, at least in part, by the project
developers. The panel recognizes that on a project
of the scale of the SSA process, with much of the
programming possibly being done by contract personnel,
it will be difficult to maintain continuity. However,
continuity should be considered carefully when staff-
ing for key program tasks.
In recent years, the line separating vendor-supplied
system control programs from user-written application
programs has become increasingly blurred. At the
same time, the data processing services used by
applications programs have become increasingly complex.
Programs can be made obsolete not only by changes in
functional requirements but also by changes in the
hardware and system software environment in which the
programs are executed. Maintenance operations can be
greatly facilitated if application program interfaces
with such system software are isolated and standard-
ized.
Summary: System Synthesis and the Role of Project Management
Before a system can achieve success, the criteria for its success
must be defined. In defining these criteria,~it is necessary to include
. .. .. .
standards of success other than those that are easily quantifiable.
Success must be measurable in the external context in which the system
operates and, in particular, in light of the activities performed by
the people who interact with the system. This context, furthermore,
needs to be considered as subject to constant change.
The panel recommends, therefore, that the SSA design the system to
be programmed to anticipate change whenever possible and to be quickly
responsive to change even when it cannot be anticipated. Part of this
can be achieved by ensuring that the system design embraces the entire
operational setting of which the computer system is but a part, includ-
ing people, management, and procedures. Part can also be achieved by
the judicious selection of the facilities and techniques used to
construct the computer system.
Normally, such functions fall under the general rubric of systems
analysis. Successful systems operation demands as well, however, that
systems synthesis be performed--that the multiple objectives and
requirements be considered together so that while all are achieved,
none is addressed at the expense of the others and that full weight is
given to system accuracy, efficiency and maintainability. This task
of systems synthesis is a highly important responsibility of the managers
of data processing systems.
In most cases, it will be found that these desiderata co-exist in
an almost symbiotic relationship. A system that is designed to satisfy
high standards of accuracy and efficiency also will generally be one
OCR for page 43
43
that is easy to maintain. In addition, a system that is easy to maintain
is likely to operate accurately and ef f iciently.
Trade-off situations will occasionally be encountered in which the
achievement at one objective must be subordinated to the achievement of
another. For example, program efficiency may suggest one approach while
considerations of program maintainability will encourage another. Also,
the privacy and security of system data are issues of great public
concern. While emphasis must be given to these concerns, and necessary
measures enacted to regulate strictly the access to the system data'
such measures can affect the efficiency of system operations.
It is critical, therefore, that the managers of system software
development be conscious of the existence of such tradeoffs and that the
manner and reasons for resolving the matters be explicitly documented
Accordingly, management must stipulate the ob jectives of the process and
their interrelationships. It must also employ sampling techniques and
other tools of quality assurance and performance measurement both during
and after the development period to ensure that the objectives are both
understood and realized.
Representative terms from entire chapter:
network design
