Professional Documents
Culture Documents
Systems Analysis and Design by Elias M Awad
Systems Analysis and Design by Elias M Awad
^
<t..
K
•TTT'.
*.>
Systems Analysis and Design
"USim^
The Irwin Series in Information and Decision Sciences
Consulting Editors: Robert B. Fetter Claude McMillan
Yale University University of Colorado
Systems Analysis and Design
2]los M. Awad
Mclntire School of Commerce
University of Virginia
ISBN 0-256-02824-9
234567890K21098765
Preface
A major contribution of the first edition was to conceptualize and define the
scope and domain of systems analysis and design. The text was well
received by the information systems academic community. Today's fast-
paced technology, however, makes it difficult for most publications to stay
up-to-date. This edition is virtually a new book. It is a major update of the
first edition of Systems Analysis and Design, which focuses on the system
development life cycle using conventional and structured tools. The mate-
rial goes beyond the classroom theory and concepts. It is practice oriented
vu
VIII PREFACE
1. Eleven chapters dealing with topics such as the role of the analyst, the
tools of stnjctured analysis and design, data base design, and hard-
ware/software selection improve the student's understanding of the
systems development life cycle and provide a comprehensive fiame-
work for systems development.
2. "At a Glance" provides a brief preview of the material covered in each
chapter.
3. A summary of the main points, key words, and review questions follow
each chapter.
4. Case studies at the end of each chapter are business situations which
the author has been involved in as a consultant or analyst. Working
through the cases will help you acquii^e the principles and gain experi-
ence in making decisions that can be useful in similar situations in the
future.
PREFACE L\
ACKNOWLEDGMENTS
Manx- individuals ha\ e contributed to the preparation of this text. For their
inxakiable comments and suggestions. I wish to thank my reviewers. Rod
i\eal, Univereitv' of Arkansas; Thomas H. Weaver, Jr., Puixlue Universitv —
Calumet; and Kenneth W. \ eatch, San .Antonio College, and my consulting
editors, Robet B. Fetter, Vale Unixersitv; and Claude McMillan, l'ni\ei^ir\' of
Colorado.
Special thanks to V\ illiam G. Shenkir, Dean, Mclntire School of Commerce,
for providing micixjcomputer support and for his encouragement. I also
recognize the consti-uctive feedback that the MIS students at the Mclntire
School have gi\ en in testing \ arious portions of the manuscript.
Elias M. Awad
;>fv-
Contents
Part One
Overview
Part Two
Systems Analysis 90
Part Three
Systems Design 258
Part Four
System Implementation 356
Index 516
Systems Analysis and Design
Part One
Overview
^r: •
1 SYSTEMS CONCEPTS AND THE INFORMATION
SYSTEMS ENVIRONMENT
2 THE SYSTEM DEVELOPMENT LIFE CYCLE
3 THE ROLE OF THE SYSTEMS ANALYST
Chapter 1
Systems Concepts
and the Information
Systems
Environment
Introduction
Characteristics of a System
ORGANIZATION
INTERACTION
INTERDEPENDENCE
INTEGRATION
CENTRAL OBJECTIVE
Elements of a System
OUTPUTS AND INPUTS
PROCESSOR(S)
CONTROL
FEEDBACK
At a Glance
end user.
3. How physical systems differ from abstract systems.
4. The unique features of formal and informal information systems.
5. The makeup of management information systems.
6. How decision support systems help in decision making.
ENVIRONMENT
BOUNDARIES AND INTERFACE
Types of Systems
PHYSICAL OR ABSTRACT SYSTEMS
Systems Models
Schematic Models
Flow System Models
Static System Models
Dynamic System Models
OPEN OR CLOSED SYSTEMS
MAN-MADE INFORMATION SYSTEMS
Formal Information Systems
Categories of Information
Intormal Information Systems
Computer-Based Intormation Systems
Management Information Systems (MIS)
Decision Support Systems (DSS)
INTRODUCTION
It s a Upical da\ . The car starts OK, but you think with a flash of irritation
that it reall\' shouldn't take that long to get the air conditioner going. Onl\'
an hour to catch the plane, and cars are piled up on the express\va\' as far
as the e\e can see. Vou begin to wonder if there isn't a way to allow airport
traffic to mo\ 8 faster. Vou get to the parking lot and have to walk half a mile
to the plane. Where is the shuttle? \\'h\' so long a wait? \\h\ so mam
obstacles? — the ticket counter, the X-ray machine, the gate attendant, etc.
Each one is a system in itself, \'et they are all part of the transportation
s\'stem.
This book about sxstems anaksis and how it relates to shaping
is
that their xvork no longer "measures up, I2i decreased morale of personnel
'
who were not consulted about the installation, and I3i feeling of intimida-
tion by users xvho haxe limited training in the nexv computer. In assessing
these consequences, the analyst's role of allexiating fears and remoxing
barriers for the user is extremelx' crucial for the sxstem's success.
Systems analx'sis and design focus on sxstems, processes, and tech-
nologx'. Haxing a firm grasp of the makeup of the system in question is a
prei'equisite for selecting the procedure or intixjducing the computer for
implementation. In our airport scenario, knoxxledge of the traffic fiow, the
strategic location of the airport, and hox\' a gixen change will speed up
airport traffic is important in deciding on improxements such as special
shuttles, helicopter senice. or more aiq^ort limousines to solxe the prob-
lem. Thus, a background in sxste?his concepts and a familiarity xxith the
ways organizations function are helpful. This chapter discusses the systems
>\
^'
PC..
-i--, » .
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT
Definition
The term system is derived from the Greek word systema, which means an
organized I'elationship among functioning units or components. A system
'
Ludwig Bertalanffy, General Systems Theory (New York; George Braziller, 1968).
- Norbert Wiener, Cybernetics (New York: John Wiley <& Sons, 19481.
'
Herbert A. Simon, The Shape ofAutomat ion for Men and Management (New York: Harper &.
Row, 19651.
CHARACTERISTICS OF A SYSTEM
Our definition of a system suggests some characteristics that are present in
all systems: organization (order), interaction, interdependence, integration,
and a central objective.
Organization
Organization implies structure and or^der. It is the airangement of compo-
nents that helps to achieve objectives. In the design of a business system, for
example, the hierarchical relationsrfiips starting with the president on top
and leading downward to the blue-collar workers represents the organiza-
tion structur-e. Such an arrangement portrays a system-subsystem rela-
1 / SYSTEMS CONCEPTS AND THE INFORMAnON SYSTEMS ENVIRONMENT
tionship, defines the authority structure, specifies the formal flow of com-
munication, and formalizes the chain of command (see Figure 1-1). Like-
wise, a computer system is designed around an input device, a central
processing unit, an output device, and one or more storage units. When
linked together they work as a whole system for producing information.
Interaction
Interaction refers to the manner in which each component functions with
other components of the system. In an organization, for example, purchas-
ing must interact with production, advertising with sales, and payroll with
personnel. In a computer system, the central processing unit must interact
with the input device to solve a problem. In turn, the main memory holds
programs and data that the arithmetic unit uses for computation. The
interrelationship between these components enables the computer to per-
form.
Interdependence
Interdependence means that parts of the organization or computer system
depend on one another. They are coordinated and linked together accord-
ing to a plan. One subsystem depends on the input of another subsystem
for proper functioning; that is, the output of one subsystem is the required
f 1
Vice President Vice President Vice President
Sales Production Accounting
I
I
Department Head Department Head
Assembly Painting
Workers Workers
10 PAST ONE / OVERVIEW
Major
(Higher-Level)
Subsystem
Minor
(Lower-Level)
Subsystems
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 11
Organization's
systems
Feedback
and control
e
I Operation I—
Skills inventory.
Job positions.
Recruitment.
Remote
terminals
for data
acquisition
and retrieval
Personnel budget
Benefits.
Health,
Training.
Employment record
Feedback
and control
Action
report
Other
Personnel
authorized
staff
users
shown in Figure 1-4, none of these persons can perform properly without
the required input from others in the computer center subsystem.
Integration
Integration refers to the holism of systems. Synthesis follows analysis to
achieve the central objecti\'e of the organization. Integration is concerned
with how a system is tied together. It is moi^ than sharing a physical part or
location. It means that parts of the system work together within the system
even though each part performs a unique function. Successful integration
and greater total impact than if
will tvpically pixjduce a svTiergistic effect
each component works separately.
Central Objective
The last characteristic of a system is its central objective. Objectives may be
real or stated. .Although a stated objecti\'e may be the real objective, it is not
uncommon for an organization to one objectixe and operate to achieve
state
another. The important point is that users must know the central objective
of a computer application eariy in the analysis for a successful design and
conversion. Later in the book, we will show that political as well as organiza-
tional considerations often cloud the real objective. This means that the
must work around such obstacles
analyst to identify the real objective of the
proposed change.
ELEMENTS OF A SYSTEM
In most cases, systems analysts operate in a dxmamic en\ironment where
change is a way of life. The environment may be a business firm, a business
application, or a computer system. To reconstruct a system, the following
key elements must be considered:
5. Environment.
6. Boundaries and interface.
^^eoBG^^ii5^i;2^;i£^^
stockholders
Compare output
against performance
standards
Action Management
(control)
Policy
decisions
t
Human resources
material, en- Transformation
ergy, information
Standard of
performance
Processor(s)
The processor is the element of a system that involves the actual transfor-
mation of input into output. It is the operational component of a system.
Processors may modify the input totally or partially, depending on the
specifications of the output. This means that as the output specifications
change, so does the processing. In some cases, input is also modified to
enable the processor to handle the transfoiTnation.
Control
The control element guides the system. It is the decision-making subsystem
that controls the pattern of acti\ities governing input, processing, and
output. In an organizational context, management as a decision-making
body controls the inflow, handling, and outflow of activities that affect the
welfare of the business. In a computer system, the operating system and
accompanying software influence the behavior of the system. Output speci-
fications determine what and how much input is needed to keep the
system balance (see Figure 1-5).
in
In systems analysis, knowing the attitudes of the individual who con-
trols the area for which a computer is being considered can make a dif-
ference between the success and failure of the installation. Management
support is required for securing control and supporting the objective of the
proposed change.
Feedback
Control in a dynamic system is achieved by feedback. Feedback measures
output against a standard in some form of cybernetic procedure that
includes communication and control. In Figure 1-5, output information is
fed back to the input and/or to management (controller) for deliberation.
After the output is compared against performance standards, changes can
result in the input or processing and, consequently, the output.
Feedback may be positive or negative, routine or informational. Positive
feedback reinforces the performance of the system. It is routine in nature.
Negative feedback generally provides the controller with infoimation foi-
action. In systems analysis, feedback is important in different ways. During
may be told that the problems in a given application verify
analysis, the user
his/her concerns and justify the need for change. Another foiTn of
initial
feedback comes after the system is implemented. The user informs the
analyst about the performance of the new installation. This feedback often
results in enhancements to meet the user's r-equir^ments.
Environment M
The envirxjnment is the "supr^asystem "
within which an organization oper-
ates. It is the sour'ce of exter-nal elements that impinge on the system. In
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 15
TYPES OF SYSTEMS
The frame of reference within which one views a system is related to the use
of the systems approach for analysis. Systems have been classified in differ-
ent ways. Common classifications are: iH physical or abstract, 121 open or
closed, and (3) "man-made" information systems.
Systems Models
In no field are models used more widely and with greater variet\" than in
systems anal\sis. The analyst begins b\ creating a model of the realitv facts
relationships, procedures, etcj with which the s\'stem is concerned. E\er\"
computer system deals with the real world, a problem area, or a realit\
outside itself. For example, a telephone switching system is made up of
subscribers, telephone handsets, dialing, conference calls, and the like. The
anal\st begins b\- modeling this realitv' before considering the functions that
the s\stem is to perf^orm.
Various business s\"stem models are used to show the benefits of ab-
stracting complex s\'stems to model form. The major models discussed
here are schematic, flow, static, and d\Tiamic system models.
Flow System Models. A flow system model shows the flow of the
V material, energ\', and information that hold the system together. There is an
orderly flow of logic in such models. A wideK" known example is PERT
•Program Evaluation and Re\iew Techniques It is used to abstract a real-
world s\stem in model form, manipulate specific \alues to determine the
critical path, interpret the relationships, and rela\' them back as a control.
The probabilit\- of completion within a time period is considered in connec-
tion with time, resources, and performance specifications isee Figure 1-7).
PERT is discussed in detail in Chapter 15.
Stortic System Models. This t\pe of model exhibits one pair of rela-
tionships such as acti\it\ -time or cost-quantit\ . The Gantt chart for exam-
ple. gi\es a static picture of an acti\it\'-time relationship. In Figure 1-8,
planned acti\ities istamping, sanding, etc.i are plotted in relation to time.
The date column has light lines that indicate the amount of time it takes to
complete a gi\en actr\it\'. The hea\y line represents the cumulati\e time
schedule for each acti\it\'. The stamping department for example is sched-
uled to start working on order number 25 Wednesday* morning and com-
plete the job by the same evening. One day is also scheduled for order
number 28, two days for order number 22, and two da\"s Mas 10-11' for
order number 29. The total of six days is represented b\ the hea\y line
opposite the stamping department. The broken line indicates that the
department is two da\s behind schedule. The arrowhead indicates the date
when the chart is to be in eff"ect. The Gantt chart is discussed in more detail
in Chapter 15.
?^ c c
H.2 o
« ra CO
CO p o
9J
c c « c
^
c S
a>
CO t;
CO O ^ o w
nj
E
o
a
(U
O
«0
/I ,
c
w C 0)
0) o
i
3
o
0)
<0 • - OT (0
(jj
c
to ^g ><E o
*-
CJ PS
0)
w ^£
CO <0
i- CO i- TO
0) 3 co"
>
I- </) Q.
E c
• • • • ^^^^
o o o <i>
CO
35
i_
o
o
te
CL~ -c
0) -^ O
a <u
o c
V
ce
S CO (O >- c g
CO 5
CO CO b CO m
ence requ ation ident
• ••
3 s
o CO
<D O) CO j3 o o "C >
C3 T3
-Qo u
<-^>< ro <u
CL
LU I
OS
co"
3 O E E
a o
c CD £ 5 2.
o ^5^ to
•c c
CO 3 o o
CO CO O Q.
COH- I
0) CO
c o t
c:
c
d Se c
n CO
Q. CO Q) ^o 60
c E T3 c:
3 CD
^
i I T3 I
o
-H r
CO
1 0)
"*-
o 5
a c 3
^o
'=
in c (i>
t ^ .2 o o
V
o o o CO
a. IE Q)
*-* ^- ti
k. u. CO (0 CD ec
o 3 Id c '^^ F c
c i3 t- 0) ^. IB
c C - i5 o -S o
c CO 0)
S £ 5 c
o E
D • • • I «
ro
-
<u
CD -o
k_
O o o> i A
o f
CO d) Q.
2 =• < <
Q £ o»o
Q,
o)
1
C .Quj ra
a m lu ^ LU
1
o
w
• • • • a
}~i
c
0)
0) co-g
CO
c E c o u
r CD a.
Si o
I
X u o
:= ^ • • • ^
M III >
11
Pi 0) 3
!=» o
CO
I—
18 PART ONE / OVERVIEW
Gantt Chart
)
Departments
Number of Capacity
workers per week , r May 5 6 12
[
25 28 22 29
Stamping 75 3,000
)
21 25
Sanding 10 400
\
19 20
Assembly 60 2,400 (
13 1 4
Painting 8 320 I
)
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 19
action across its boundaiy; it receixes inputs from and delivers outputs to
the outside. An information sxstem falls into this categorv', since it must
adapt to the changing demands of the user. In contrast, a closed s\'stem is
isolated from enxironmental influences. In realitv', a completely closed
system is rai^. In s\stems analxsis, organizations, applications, and com-
puters ai-e inxariably open, dxTiamic SNStems influenced b\ theii- enxiron-
ment.
A focus on the characteristics of an open system is pai'ticulai'lv timeK' in
the light of present-day business concerns with computer fraud, invasion of
privacy, securitv' controls, and ethics in computing. Whereas the technical
aspects of sxstems anal\'sis deal with internal ixDutines within the user's
application ai^a, sxstems anahsis as an open s\stem tends to expand the
scope of analxsis to relationships between the user area and other users
and to enxironmental factors that must be considei^ed befoi'e a new system
is finalh' approved. Furthermore, being open to suggestions implies that the
analyst has to be flexible and the sxstem being designed has to be respon-
sixe to the changing needs of the user and the enxiixjnment.
Fix e important characteristics of open sxstems can be identified.
1. Input from outside. Open systems are self-adjusting and self- regulating.
3. Process, output, and cycles. Open sxstems produce usefril output and
operate in cycles, folloxxing a continuous floxv path.
5. Equifinality. The term implies that goals are achiexed through diff'ering
courses of action and a x arietx' of paths. In most sxstems. there is more of a
consensus on goals than on paths to reach the goals.
6 J. L. Massie and John Douglas, Managing, 3d ed. lEnglewood Cliffs, NJ.: Prentice-Hall,
1982), p. 270.
PAST ONE OVERVIEW
Management
level Information level System support
Upper 'Strategic
planning
infomnation
* v Operational
Lower
information
^^^^ CO
of
vel
OJ
_l
C*""^
o
mmariza
3
(0
span
me
;— x-
1— O
^^^
summar
tion
TO
N
/ ^^
^^v^^
(U
D
•*>
o
0)
»- C\J
o ^
ra
D
N
D
0)
)-i
O TO
G
a>.g
>
o c
(0
o
m
o CD
F
<> i-
m o
TO c
a r "
Oo
o
i::
l-H
•o
c
d o
,»_,
c
c: </>
o
o a> en
6 o o
TO
d)
CO
D) sz o
O
o
l-H
I
c
M
Pi
OJ
a
Q.
T3 O
CD
c
TO
3
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 25
HGURE 1-11
(^qtAF^!iIll^iX!20NMeft,^
sr^
~
G. A. Gom and M. S. Scott .Morton. A Frameuoi-k for MIS, ' Sloan Management Review 13
(Fall 19711, pp. ^-70.
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 27
* See Peter Keen, and M. S. Scott Morton, Decision Support Systems: An Organizational
Perspective (Reading, Mass.: Addison-Wesley Publishing, 1978).
28 PAST ONE / OVEEVIEW
/^Problem recognitionA
/ gathering information \
/ Develop and \ (Actual selection
I evaluate alternative of a solution
I about a problem, ) j
5
Intelligence
5
Design
5
Choice
I i
Source; Herbert A. Simon, The New Science cf Management Decisions (Englewood Cli&, N.J.: Prentice- Hall,
1960), pp. 54-5.
ment has about the cause of a problem, the better is the likelihood of
designing a good decision. A DSS can provide intelligence through informa-
tion retrieval and statistical packages.
The design phase of decision making focuses on the evaluation of
decision alternatives. During this phase, computer-based deterministic or
stochcistic models may be used for decision design. DSS plays a major role
in decision design under uncertainty. The output of the model(s) is the
basis for the choice phase of decision making.
Geographical (actors /
Goals
Structure
Physical and financial
resources
\ \ Judicial interpretations
Tools and technology Labor-management relations
Value systems o( managers
and workers
Company policies and traditions
\
Actions o( competitors / Work groups and the mtormal
organization Differences in jobs and people
\
Productivity inducing
Individually
based
The Personnel
System Career path planning
Employee motivation
and
Skill training
re-training
Pay and benefits
Incentive programs Need fulfillment
Performance appraisal
Personal growth
Job analysis and evaluation and development
Human resources planning
Recruitment and selection
Job data
Compensation data
Manpower forecasts
Productivity Maintaining
Recruitment data
Skillsdata
Biographical data
Testing data Management development
Performance data Organization development
Health and safety Productivity
Labor relations maintenance
Communications, counseling.
and discipline
Personnel research
Personnel audit
Personnel policy
HRIS
audit
Personnel research
Source: W. Cascio, and E. M. Awad, Human Resources Management: An Information Systems Approach. (Reston, Va.:
Reston Publishing, 1981), p. 63.
channel emloxee talent toward goal attainment. This is done through man-
agement development, health and safet\' regulations, labor relations, com-
munications, counseling, and discipline. Taken as a group, the two
pixDcesses respond to, sustain, and upgrade the performance of the busi-
ness and the indi\iduals within it.
In designing a computer-based personnel system for a firm, the anal\'st
ma\' use the model to give a global picture of the role of personnel in the
organization, the laws and other external ien\ironmentali factors that per-
sonnel faces in making decisions, the tvpes and numbers of acti\ities or
applications that are candidates for computerization, and the prioritv of
each application for design and implementation. B\ following such a pix)-
cedure and knowing how pei^onnel "hangs together' within the framework
of the organization, the analyst can more easil\' plan for change, sell change
to the users, and pro\ide a good fit for the new personnel system in the
organization. This is whatand design are about: awareness, under-
analysis
standing, observation, assessment, justification, design, testing, and imple-
mentation.
Summary
1. A systeman orderly grouping of interdependent components linked
is
2. Systems analysis and design are the application of the systems ap-
proach to pix)blem sohing, generally using computers. To reconstruct a
system, the analyst must consider its elements outputs and inputs, —
processors, control, feedback, and en\ironment.
3. Systems fall into three classifications:
a. models or formulas.
Physical (tangible entities) or abstract, such as
b. Open allowing inputs and pro\iding outputs or closed, which
I i
Key Words
Abstract System Entropy
Closed System Equifinality
Control Equilibrium
Data Base Feedback
Data Base Management System Flow System Model
(DBMS) Gantt Chart
Decision Support System (DSS) General Systems Theory
Differentiation Information
Dynamic System Model Information System
32 PART ONE / OVERVIEW
Input PERT
Integration Physical System
Interdependence Policy
Management Information System Processing
(MIS) Schematic Model
Model Static System Model
Open System Steady State
Orgcinization System
Organization Chart Systems Analysis
Output
Review Questions
1. You have heard people discuss systems. What is a system? What is
systems analysis?
2. From your understanding of this chapter, do you need a computer to
do systems analysis? Discuss.
3. Take an organization with which you are familiar and examine the
following:
a. Primary subsystems.
b. Characteristics.
c. Elements.
d. Purpose.
4. List the parts and functions of the foUovvdng systems:
a. Microcomputer.
b. Stapler.
c. Your business school or department.
5. Consider an automobile and a hospital as two systems. Identify the
following as an input and/or output for each system:
a. Batteries.
b. Cured patients.
c. Doctors.
d. Driver's performance.
e. Drugs.
/ Gasoline.
g. Information.
h. Motion.
/'.
A patient who died.
j. Tires.
k. X-ray machine.
6. What are the elements of a system? Cim you have a viable system with-
out feedback? Explain.
7. Distinguish between:
a. Interaction and interdependence.
t
Application Problems
You have been asked by the firm's president to examine the firm's
stiTicture, market share, and oxerall peifomiance as a basis for discuss-
ing a possible computer system for in\entor\- control. .Vll \ou know
about the company is what is described here. You are to prepare for the
first meeting with the president.
Assignment
a. What questions will \ on ask to do the following?
i. De\elop an organization chart,
ii. Understand the organization structure and the t\pe of system the firm
is.
W Remember
customer's, \endors,
that \oui-
and others.
purpose is to find out whether there is a need for a
system stud\' to install computer-based in\entor^ contixjl.
b. Using the case situation of Touhy Lumber, how important are the following
systems concepts for systems analysis? Explain.
i. Data base,
ii. Feedback,
iii. Interdependence.
i\ Open and closed systems.
V. Organization chart,
vi. Svstem-subsvstem interface.
You are in a coffee shop across the street fixim school ha\ing lunch. A
customer walks up to the counter-. You ohsene the following:
Assignment
a. Kxplain the pattern of this system in action. Specifically discuss the follow-
ing:
i. The organization systen^ characteristics,
ii. the subsystems, infoniialion flow, and interfaces.
1 / SYSTEMS CONCEPTS AND THE INFORMATION SYSTEMS ENVIRONMENT 35
You are waiting in line to register for this semester's courees. A student
ahead of you is talking to a registration counselor. You overhear the
following conversation.
IBM card listing the courses he wants to take for the semester.]
Counselor: [She looks over the class enrollment sheets and finds EDP
320 (systems analysis) closed.] I'm sorry, but the systems class is
closed. I can't add you on. You'll have to take it next term. Check
with your adxdsor for another couree. Management 415 is also
closed. If you have to take it, you need peimission ft'om the instruc-
tor. Accounting 410 is OK, but your ad\isor did not initial it on the
card. The other three coui'ses are OK. I'll put your name down.
Assignment
a. What type of system is it (open versus closed)? Why? Specify the system-
subsystem linkages, interfaces, and interdependence.
fa. In what way is the registration pix)cess a subsystem? Explain.
Selected References
Bertalanffy, Ludwig. General Systems Theory. New York: George Braziller, 1968.
Garry, G. A., and M. S. Scott Morton. "A Framework for MIS." Sloan Management
Review 13 (Fall 1971), pp. 55-70.
36 PAET ONE OVERVIEW
/
Johnson, Richard A.; Fremont E. Kast; and James E. Rozensvveig. The Theory and
Management of Systems. New York: McGraw-Hill, 1973.
Keen, Peter, and M. S. Scott Morton. Decision Support Systems: An Organizational
Perspective. Reading, Mass.: Addison-Wesley Publishing, 1978.
Kerola, P., and A. Jarvinen. "The FSC-Systemeering Model and Its Influence on the
Basic Concept Structure of Data Svstem Development." In Tempere Report
119781: Summan,- Report of the Svstemeering Research Seminar of Tampere 21,
ed. P. Kerola: M. Klemola: H. Kamarainen; and L. L\Atineh. Universit\ of Oulu,
Institute of Data Processing, Tampere, Finland 31.12.1978 (1978).
Luchsinger, \'incent P., and Thomas \'. Dock. The Systenjs .Approach: An Introduc-
tion. 2d ed. Dubuque, Iowa: Kendal Hunt Publishing, 1982.
Massie, J. L., and John Douglas. Managing 3d ed. Englewood ClifiEs, .\.J.: Prentice-
Hall, 1982, p. 270.
Simon, Herbert A. The Shape of Automation for Men and Management. New^ York:
Harper & Row, 1965.
VVelke, R. J., and B. P. Kons\Tiski. Technology, Methodolog\' & Information Sys-
tems: A Tripartite \'iew. Dafa Base, Fall 1982. pp. 41-57.
W'etherbe, James Systems Analysis and Design: Traditional, Structured, and Ad-
C.
vanced Concepts and Techniques. 2d ed. Minneapolis, Minn.: West Publishing,
1984, pp. 21-38.
Wiener, Norbert. Cvbemetics. New York: John WOex' & Sons, 1948.
/• ,
V.
Chapter 2
The System
Development
Life Cycle
^ "
v' .
•
,
^ ^^' 1
--. •:<!
•»
. A
1 i.Al
-J
V
Introduction
FEASIBILITY STUDY
ANALYSIS
DESIGN
IMPLEMENTATION
POST-IMPLEMENTATION AND MAINTENANCE
Project Terminortion
-3«
.
At a Glance
Systems analysts work with users to Identity goals and build systems to achieve
them. System development revolves around a life cycle that begins with the
recognition of user needs. Following a feasibility study, the key stages of the
cycle are evaluation of the present system, information gathering, cost/benefit
analysis, detailed design, and implementation of the candidate system. The
life cycle is not a procedure that deals with hardware and software. It is
Prototyping
40 PAKT ONE / OVERVIEW
INTRODUCTION
In Chapter 1 wediscussed the importance of systems concepts for develop-
ing business information systems. Developing such systems expedites prob-
lem solving and improves the quality of decision making. This is where the
role of systems analysts becomes crucial. They are confronted with the
challenging task of creating new systems and planning major changes in
the organization. Like architects, they work with users to identifv the goal(s),
agree on a procedure and a timetable, and deliver a system that meets the
user's requirements. It is a job that requires much personal contact be-
tween the analyst and members of the organization.
This chapter focuses on the stages of the system development life cycle,
?''-^]
sometimes referred to as a system study. The systems analyst gives a system
development project meaning and direction. A candidate system is ap-
proached after the analyst has a thorough understanding of user needs and
problems, has developed a viable solution to these problems, and then
communicates the solutionis) through the installation of a candidate sys-
tem. Candidate systems often cut across the boundaries of users in the
organization. For example, a billing system may involve users in the sales
order department, the credit department, the warehouse, and the account-
ing department. To make sure that all users' needs are met, a project team
that represents each user works vvath the analyst to carrv' out a system
development project. In complex projects, representatives ftxim other user
areas influenced by the candidate system as well as information systems
specialists may also be included.
l^
Recognition of Need — What Is the Problem?
One must know what the pixiblem is can be solved. The basis for a
before it
1. Recognition of need
Pi-eliminaiy survey/ What is the problem or Statement of scope and
initial investigation opportunity? objectives
Performance criteria
2. Feasibility study
Evaluation of existing What £ire the user's Technical/liehavioral
system and procedures demonstrable needs? feasibility
Analysis of alternative Is the problem worth CostA)enefit analysis
candidate systems solving? System scope and objectives
Cost estimates How can the problem be Statement ofnew scope and
redefined? objectives
3. Analysis
Detailed evaluation of What must be done to solve Logical model of system
present system the problem? e^., data dictionary, data
Data collection What are the facts? flow diagram
Pertinent data
4. Design
General design In general, how must the Design of alternative
specifications problem be solved? solutions
Detailed design Specifically, how must the Final cost/benefit analysis
specifications problem be solved? Htuxlwiire specifications
Output What is the system Cost estimates
Input (processing) flow? Implementation specifica-
Files tions
Procedures Does the user approve the Implementation schedule
system? Approved of systems by user
Program construction Programs
Testing Test plans
Unit testing How well do individual Security, audit, and operating
Combined module programs/modules test out? procedures
testing How ready are programs for Actual hardware use
User acceptance acceptance test? Formal system test
testing
5. Implementation
User training What is the actual operation? Training program
File/system conversion Are user manuals ready? User-ftiendly documentation
Are there delays in loading
files?
6. Post-implementation and
maintenance
Evaluation Is the key system running? User requirements met
Maintenance Should the system be User standards met
Enhancements modified? Satisfied user
42 PART ONE OVERVIEW
/
r.' i-*
the development cost of the project may be reached. However, an accurate
cost of the next phase —
the feasibilitv' studv —
can be produced.
within the organization may feel the need to update existing applications or
impix)ve procedures. Here are some examples:
• An organization acquires another organization.
• A local bank branches into the suburtjs.
• A rc'port reaches a senior vice president and she suspects the figui-es.
2 / THE SYSTEM DEVELOPMENT UFE CYCLE 43
Sources of -*
Organization-based Environment-based
system ideas
Government
Organization rules and
regulations
Top
Consumers
management
Impetus
-^1 for 1^4-
change
User
Feasibility
study
Analysis O
>
O
z
m
Design Q.
o
>
LU
Q
LLI
I-
Imple- w
>-
mentation
w
Post-
implemen-
tation
Main-
tenance
44 PABT ONE / OVEEVIEW
• The company comptroller reads an IRS audit report and starts thinking.
All these factors are crucial for a prompt response to a user request for
change. A ^systems analyst is in a unique position to detect and even
recommend change. Experience and previous involvement in the user's
area of operations make him/her a convenient resource for ideas. The role
and status of the analyst as a professional add credibility to the suggestions
made.
/I
FeasibUitY Study
Depending on the results of the initial investigation, the survey is expanded
to a more detailed feasibility study. As we shall leam in Chapter 7, a
feasibility study is a test of a system proposal according to its workability,
impact on the organization, ability to meet user needs, and effective use of
resources. It focuses on three major questions:
1. What are the user's demonstrable needs and how does a candidate
system meet them?
2. What resources cire available for given candidate systems? Is the prob-
lem worth solving?
3. What are the likely impact of the Ccmdidate system on the organization?
How well does it fit within the organization's master MIS plan?
agreement that paves the way for actual design and implementation. This is
a crucial decision point in the life cycle. Many projects die here, whereas
the more promising ones continue through implementation. Changes in
the proposal are made in vvriting, depending on the complexity, size, and
cost of the project. It is simply common sense to verify changes before
committing the project to design.
Analysis
Analysis is a detailed study of the various operations performed by a system
and their relationships within and outside of the system. A key question is:
^. Design
The most creative and challenging phase of the system life cycle is system
design. The term design describes a final system and the process by which it
is developed. It refers to the technical specifications (analogous to the
engineer's blueprints) that vvdll be applied in implementing the candidate
system. It also includes the construction of pixjgrams and program testing.
The key question here is: How should the problem be solved? The major
steps in design are shown in Figure 2-3.
The first step is to determine how the output is to be produced and in
what format. Samples of the output land input) are also presented. Second,
input data and master files (data base) have to be designed to meet the
requirements of the pixjposed output. The operational (processing) phases
are handled through pixjgram construction and testing, including a list of
the programs needed to meet the system's objectives and complete docu-
mentation. Finally, details related to justification of the system and an
estimate of the impact of the candidate system on the user and the organi-
zation are documented and evaluated by management as a step toward
implementation.
The final report prior to the implementation phase includes procedural
flowcharts, record layouts, report layouts, and a workable plan for imple-
menting the candidate system. Information on pereonnel, money, hard-
ware, facilities, and their estimated cost must also be available. At this point,
projected costs must be close to actual costs of implementation.
In some groups of programmers do the programming,
firms, separate
whereas other firms employ analyst-programmers who do analysis and
design as well as code pix)grams. For this discussion, we assume that
analysis and pixjgramming are carried out by two separate persons. There
are certain fimctions, though, that the analyst must peiform while pro-
grams are being written. Operating procedures and documentation must be
completed. Security and auditing procedures must also be developed. A
detailed discussion of security and audit is presented in Chapter 16.
/• Implementation
The implementation phase is less creative than system design. It is pri-
marily concerned with user training, site pi-eparation, and file convei-sion.
When the candidate system is linked to terminals or i^mote sites, the
telecommunication network anc^ tests of the network along with the system
ai^e also included under implementation.
From
analysis
Detailed
system
documentation
Design
submitted to
management for
approval
Go to implementation
access, update, and retrieve data from new files. Once the programs become
available, test data are read into the computer and processed against the
file(s) provided for testing. If successful, the program(s) is then nan with
point-of-sale (POS) systems for a retail chain. In any case, after the candidate
system proves itself, the old system is phased out.
Project Termination
A system project may be dropped at any time prior to implementation,
although it becomes more difficult (and costly) when it goes past the design
phase. Generally, projects are dropped if, after a review process, it is learned
that:
• The user was not directly involved in the crucial phases of system
development.
• The analyst, programmer, or both were inexperienced.
• The systems analyst (or the project team) had to do the woric under
stringent time constraints. Consequently, not enough thought went into
the feasibility study and system design.
• User training was poor.
• Existing hardware proved deficient to handle the new application.
• The new system left users in other departments out of touch with
information that the old system had provided.
• The new system was not user-fiiendly.
The list can be expanded to include many more causes. The important
point is that although advances in computer systems and software make life
easier for the analyst, the success of a system project depends on the
As produced by the programmefs As installed at Vne user's site What the user wanted
Source: Adapted fiDm the Educational Exploration Center Newsletter, Minneapolis, Minnesota.
50 PART ONE / OVERVIEW
experience, creative ability, and knowledge of the analyst and the support
from the user This suggests that the analyst be skilled in the state of
staff.
the art (hardwai-e and software) as well as in dealing with people. The role of
the analyst is covered in Chapter 3.
Thus, the basic problem match the demands for services v^th the
is to
available resources. How much one project is favored over another depends
on technical, behavioral, and economic factors.
The technical factor involves the system department's ability to handle a
project. Much depends on the availability of qualified analysts, designers,
and software specialists to do the woik. This is especially true in designing
data bases and implementing complex systems for large concerns. The
alternative to abandoning a project because of limited talent on the inside is
ft'ee-lancing it to an outside consulting firm. The cost of developing the
project has to be weighed against the total benefits expected.
The behavioral factor involves (1) the user's past experience with an
existing system, (2) the success record of the analyst, and (3) the infiuence
the user can exert on upper management to finance a candidate system.
Political considerations that subjectively favor one project over another, the
status of the department, and its peifoimance record are additional factore
that bear on funding a candidate system.
a
variables chosen, and the like. System consultants suggest an annual rate of
return of just over 20 percent.
Political Considerations
into support.
I. D Problem definition
II. /I^ Feasibility study
VI. D Evaluation
//
/ /
I I
A. n Economic feasibility
B. D Organizational feasibility
D./Ih'Application feasibility
Z •V
/ I
\
/ I
\
/ I \
/ / \ ^^
1. D Interview secretaries
2. D Summarize findings
(client name)
OVERVIEW OF SYSTEMS MASTER PLAN Page.
Date_
DEFINITION PHASE
A Definition of organizational
responsibilities
B Defi n ition of ndustry /environment
i
FEASIBILITY PHASE
A Economic feasibility
6 Organizatior^l feasibility
C Alternative systems feasibility
D Application feasibility
RESEARCH PHASE
A System Configuration audit
B Hardware audit
C Software audit
SELECTION PHASE
A Requests for Proposals
B Selection Cniena
C Evaluation of Vendors
IMPLEMENTATION PHASE
A. Ptiysicai Site Preparation
B. Training Plan
C Installation of Hardware
D Installation of System Software
E- Custom PrograrrvTiing (optior^l)
F Installation of Application
Software
G Hardware/Software Testing
(vendor data)
H Documentation Plan (optional)
I Systems Development
J. Parallel Testing (user data)
K Conversion Cutover
VI EVALUATION PHASE
A Project Evaluation
B Internal Control Review
C. Documentation Review
D. Recommerxlations
1. Identify the activities in each phase and the tasks within each activity.
2. Calculate the budget for each phase and obtain agreement to proceed.
3. Review, record, and summarize progress on activities periodically.
(client name)
SYSTEMS MASTER PLAN Page_
DEFINITION PHASE
Date_
DEFINITION PHASE
A ORGANIZATIONAL RESPONSIBILITIES
Receive approval from upper management
to perform ttie systems study
Select a qualified person(s) to under-
take and supervise ttie systems study
Decide whettier to use consultants or
vendors in the systems study
Solicit recommendations and cooperation
from all departments
Delegate responsibility to appropriate
department personnel
Orient the staff as to the general
goals, purpose, techniques, and extent
of their involvement in the study
up a time schedule and work
Dravi/
program by phases to control the
completion of tasks
B INDUSTRY/ENVIRONMENT
Document significant national and
local economic conditions
Document the effect of economic con-
ditions on client industryand business
Document the nature and competition of
the client's industry
Document system problems unique to the
client's industry
CURRENT BUSINESS
Prepare a description of the business
Prepare a description of major products
or services
Document the corporate structure
Prepare an organizational chart
Prepare a list of all current and
proposed employees and their functions
Review the most recent financial
statements and budgets
Review the long-term and short-term
financing and budgeting of the current
and proposed facilities
Document any significant or relevant
matters which affect systems planning
PROTOTYPING
As can be deduced from the discussion on system development, there are
two major problems with building information systems: (1) the system
development life cycle takes too long and (2) the light system is rarely
developed the first time. Lengthy development frustrates the user. Analysts
seem to get bogged down with tedious methodologies for developing sys-
tems. The reason they often come up with the wixing system is that they
2 / THE SYSTEM DEVELOPMENT LIFE CYCLE 55
(Client name)
SYSTEMS MASTER PIAN Page.
DEFINITION PHASE
DEFINITION PHASE
D SYSTEM GOALS
• Document the general long-tefm and sNxt-
lemi txjsiness and systems obiectives
• Document areas to improve by department
and^or function
Document the proposed hardware
capabilities' obiectives
• Document the proposed system software
capabilitie&'obiectrves
• Document the proposed data processing
applicatKxi capabilities objectives
• Document the proposed word processing
application capabilities/obiectives
• Document the proposed systems pei^onnel
capabilities/obiectives
' Jeimes C. Wetherbe. Advanced System Dexelopment Techniques A\oid ',Anal\'sis bv Paral-
ysis," Data Management, Februari- 1984, p. 49.
2 J. D. Naumann and M. A. Jenkins. ProtoKping: The New Paradigm for System De\'elop-
ment," MIS Quarterly. September 1982, pp. 15-21.
56 PAKT ONE OVERVIEW
Analyze proto-
Post-
Identify user type Implement Final
implementa-
requirements Input, processing, prototype conversion
tion
output
Revise through
itprflfiup nrorp_<;<; *
"' '
' '
'
..... 1
Maintenance
Source: Adapted from J. C. Wetherbe. ".Ad\'anced System Dexielopment Techniques .Axnid 'Analysis by Paralysis."
Data Management, Febrviaiy 1984, p. 51.
3. Allow the user to use the prototvpe, discuss requested changes, and
implement the most important changes.
4 Repeat the next \ersion of the prototvpe with further changes incorpo-
rated untU the system fully meets user requirements.
Summary
1. Sx'stems anal\'sis and design ai^e kexed to the life cycle. The stages are:
a. Recognition of the need for change.
b. Feasibility study.
c. Analysis of the present system.
d. Design of a candidate system.
e. Testing and implementation of the system.
f. Post-implementation.
2. The idea for change originates in the en\ironment igovemment, con-
sumers, union, etc.i or from within the firm luser, anal\'st, etc.i. Once the
problem is \erified, an initial in\estigation is conducted detemiine
to
whether change is feasible. If the answer is yes, a feasibilitx' study is
authorized.
3. Analysis is a detailed stud\' of the \'aiious operations performed bv a
system. This inxoKes gathering information and using structured tools
for ancilvsis.
5. —
Implementation is concerned with detail the physical creation of the
candidate system. The key point is actual operation and user accept-
ance testing befoi'e the system is released to the user.
6. After implementation, maintenance begins. This includes enhance-
ments, modifications, or any change from the original specifications.
This phase terminates the system development life cycle.
7. In deciding on the project to design, a number of factors are consid-
ered: technical (availability of qualified specialists), operational (user's
experience with similar projects), and economic (cost effectiveness of
the proposed system). Political considerations also play a role in the
final selection.
8. To ensure the success of the system, careful and often extensive plan-
ning is required. This work falls under project management, where a
project is organized into work unit levels involving tasks (lowest level),
activities, phases, and milestones. The overall management process is
crucial to the successful completion of systems.
Key Words
Activity Milestone
Analysis Parallel Run
Candidate System Phase
Design Prototyping
Feasibility Study System Development
Implementation Task
Initial Investigation
Review Gtuestions
1. What is the system development life cycle? How does it relate to
systenns analysis?
2. How would an analysis determine the user's needs for a system? Ex-
plain.
6. What is the difference between analysis and design? Can one begin to
design without analysis? Why?
7. What activities make up system design? How does system design sim-
plify implementation?
8. A number of activities are carried out under implementation. Elaborate.
9. When does an analyst terminate a project? How does it tie in with post-
implementation? Explain.
58 PART ONE / OVERVIEW
11. Explain briefly the levels of structuring work units in system develop-
ment.
Application Problems
The present teller system has electronic terminals that use paper
tape to captur-e deposits, withdrawals, and other transactions. At the
end of the day, the tape goes to data pixjcessing, where the information
is entered on tape for Rngi pixjcessing. If a teller needs an account
Assignment
a. If you were the analyst, what detaUed plan would you lay out to represent
the system life cycle for a possible installation? Explain each step in detail.
b. In this particular case, where would you start the cycle? What step do you
consider most crucial? Explain.
Assignment
a. What questions w^ould you ask?
Selected References
Brooks, Cyril; Phillip Grouse; D. Ross Jeffrey; and Michael Lawrence. Information
System Design. Englewood Cliifs, NJ.: Prentice-Hall, 1982, pp. 86-105.
Naumann, J. D., and M. A. Jenkins. "Prototyping: The New Paradigm for System
Development." MIS Quarterly, September 1982, pp. 49-53.
Senn, James A. Analysis and Design of Information Systems. New York: McGraw-Hill,
1984, pp. 17-23.
Wetherbe, James C. "Advanced System Development Techniques Avoid Analysis by
Paralysis.' " Data Management, Februaiy 1984, pp. 49-52.
Chapter 3
The Role of
the Systems Analyst
•»•/
Introduction
Definition
Historical Perspective
CHANGE AGENT
INVESTIGATOR AND MONITOR
ARCHITECT
PSYCHOLOGIST
SALESPERSON
MOTIVATOR •
POLITICIAN
60
.
At a Glance
CONFLICT RESOLUTION
THE PARAPROFESSIONAL
THE TECHNICAL WRITER
Conclusions
62 PART ONE / OVERVIEW
INTRODUCTION
Designing and implementing systems to suit organizational needs are the
functions of the systems analyst. He/she plays a major role in seeing busi-
ness beneiit from computer technology. The analyst is a person with unique
skills. The job is not confined to data processing as such, because it deals
DEHNITION
The has been emerging uith changing technology. The
role of the analyst
literature suggests several definitions of analyst, but there seems to be a
common thread. A repi^sentati\e definition is the Random House Diction-
ary: "a person who conducts a methodical study and evaluation of an
activity such as a business to identi^/ its desired objectives in order to
determine procedures by which these objectives can be gained."^ A similar
definition is offered by Nicholas: "The task of the systems analyst is to elicit
needs and resource constraints and to translate these into a viable opera-
tion."-
HISTORICAL PERSPECTIVE
Prior to World War I, factories were labor-intensive, but the war brought
about automation because of labor shortages. Automation produced goods
faster, cheaper, and quicker than before. The creation of unions and higher
wages and production costs precipitated a demand for analysts to improve
working conditions and establish time standards and incentive wages."
With the large number of untrained workers, analysts also developed meth-
ods and programs for training and development.
The same picture continued throughout the 1950s, but the 1960s
marked the beginning of a new era in systems analysis and operations
research. The federal government was stockpiling weapons in huge quan-
tities. Analysts performed cost/benefit analyses of military weapon systems
2. —
Understanding identifving problems and assessing their ramifications,
having a grasp of company goals and objectives, and showing sensitivity
to the impact of the system on people at work.
3. —
Teaching educating people in use of computer systems, selling the
system to the user, and giving support when needed.
4. Selling — selling ideas and promoting innovations in problem solving
using computers.
1. Creativity — hel|3ing user's model ideas into concrete plans and develop-
ing candidate systems to match user I'equirements.
2. Problem solving — reducing problems elemental levels for analy-
to their
sis, developing altcM-native solutions to a given problem, and delineating
**
Nicholas, "Transactional Analysis, pp (i-11.
" Uiiira Schai-er, "Sysloms Analyst^Peiiomiance: Criteria and Pi-\or\ties," Journal ofSystems
Mana^emenl, Febiuary 1982, p|) 10-1.').
3 / THE ROLE OF THE SYSTEMS ANALYST 65
5. —
Questioning attitude and inquiring mind knowing the what, when,
why, where, who, and how a system works.
6. Knowledge of the basics of the computer and the business function.
though the necessity' for both skills depends on the stages of system de\'el-
opment. Figure 3-1 illustrates the skills expected across the phases of
system de\'elopment: analysis, design, implementation, and maintenance.
During analysis, there is greater need for inteipereonal skills working with —
the user to detemiine requirements and translate them into design criteria.
During design, the major thrust is to develop a detailed design of the
—
candidate system highly technical procedures and methodologies. E\en
then, there is some emphasis on the interpei'sonal factor the analyst user—
interface and user participation as a step toward training and implementa-
tion. During program construction, coding and testing ai'e carried out with
some user participation.
During sxstem implementation, technical and inteipersonal skills con-
\'erge. The on "pix)\ing" the software and preparing
technical aspects focus
for the fined conxei-sion of files and documentation. The interpersonal
aspects deal with user training and selling the user on the benefits and
potential of the candidate system. During the maintenance stage the role of
the analyst dix)ps off, except when unanticipated problems de\'elop.
CK'erall, it can be seen that a successful analyst blends the realities of
Level of
Skill
Involvement
High
Low
the human factor with the structured techniques and procedures that
pemiit problem solution through the computer. Both skills are required for
a lasting interface.
How does the analyst acquire these skills? The answer is in education,
experience, and personality. Most of today's analysts are college graduates
with majors in accounting, management, or information systems. The latter
major is becoming so popular that more and more universities have pro-
grams that include courses in systems analysis, project management, and
data base design. More than 30 universities offer doctorates in the field.
The background and experience of analysts include:
M. /\wad, "Vocational Needs, Reinforcers, and Job Satisfaction of Analysts and Pro-
'" E.
grammei-s in a Banking En\iix)nment, |p>m the 10th Australian Computer Conference, Mel-
"
Change Agent
The analyst may be viewed as an agent of change. A candidate system is
" William Feeney and Frea Sladek, The System Analyst As a Change Agent," Datamation,
November 1977, p. 85.
'2 Ibid, p. 86
Robb Ware, "From Technician
13 to Problem-solver: Training the Systems Analyst," Data
Management, March 1983, p. 21.
68 PART ONE / OVERVIEW
important. If time "gets away," the project suffers ftx)m increased costs and
wasted human resoui'ces.'"* Implementation delays also mean the system
will not he ready on time, which tHistrates users and customer alike.
Architect
The architect's primary function as liaison between the client's abstract
design i-equii-ements and the contractor's detailed building plan may be
compared to the analyst's role as liaison between the user's logical design
requii^ments and the detailed physical system design. As architect, the
analyst also creates a detailed physical design of candidate systems. He/she
aids users in formalizing abstract ideas and provides details to build the
—
end pix)duct the candidate system. ^^
Psychologist
In systems development, systems are built around people. This is perhaps a
bit exaggerated, but the analyst plays the role of a psychologist in the way
he/she reaches people, interprets their thoughts, assesses their behavior,
and draws conclusions from these interactions. Undei-standing inteifunc-
tional i^lationships is important. Here is an Ulustration of the complexities
that may arise in such relationships:
wife?ie
Salesperson
Selling change can be as crucial as initiating change. As we shall learn in
Chapter 7, the oral pr^esentation of the system proposal has one objecti\e
selling the user on the system. Selling the system actually takes place at
each step in the system life cycle, however. Sciles skills and pereuasixeness,
then, are cnjcial to the success of the system.
Motivator
A candidate system must be well designed and acceptable to the user.
System acceptance is achie\'ed through user participation in its de\'elop-
ment, effective user training, and proper moti\'ation to use the system. The
ancdyst's role as a motixator becomes obxious during the first few weeks
after implementation and during times when turnover results in new peo-
ple being trained to work with the candidate system. The amoimt of dedica-
tion it takes to motivate users often taxes the analyst's abilities to maintain
the pace. What was once \dewed as a challenge can easily become a
frustration if the user's staff continues to resist the system.
Politician
"^~
just go about it methodiccdly. These characteristics point out the
. . .
strengths of analysts: They focus on method and plan, point out details, are * If
'" Robert M. Bramson and Allen F. Harrison, "The Orderly Ways of Analysts," Computer
Decisions, November 1983. p. 112.
70 PART ONE / OVERVIEW
Behavioral Issues
Much research has been done to study users and their relationships with
systems analysts. Increasing reports of system failures that were not caused
by technical problems made necessary to seek a better understanding of
it
User Motivatior\
The motivational approach system development states that the can-
in
didate system should satisfy the usei-s' needs if they are going to use it.
Several models of user behavior attempted to look at the motivation behind
system acceptance. For example, Lucas's descriptive model of user beha\aor
identifies attitudinal, personal, and situational factors that affect system
use. Use depends on both positive attitudes toward the systems's features
and the decision-making style of the user.^-'
The expectancy theory of user motivation stresses two important rela-
tionships that have a bearing on user acceptance. The first relationship is
between effort and performance. The user determines the probability that a
certain level of motivation or effort vvdll improve job perfomiance. So, a user
who perceives a system to be of low qualit\' will put forth limited effoi't to
use it. According to Zmud, the perceived link between effort and perform-
ance is formulated before the system design is completed.^" The second
'* Martin Lasdin, "Games Played Between Users and Providers," Computer Decisions,
Oc-
tober 1980, pp. 72-73.
'' Heniy C Lucas, The Analysis, Desig/H and huplemenlation, op. cil, pp. 35-38.
2" Robert W. Zmud, "The Role of Individual UifYerences in MIS Development, unpublished
paper, Georgia State University, 1980.
3 / THE ROLE OF THE SYSTEMS ANALYST 71
AnalystAJser Differences
On the surface, difterences in education, experience, and language are
quite ob\aous. The analyst's impatience with the user's ignorance about
terminology like chip and CRT and the user's impatience with the analyst's
limited understanding of the business, however, often lead to conflict dur-
ing system development. The user also tends to take for granted the ana-
lyst'sknowledge and expects the computer to solve virtually all problems.
These unrealistic expectations are barriei^ to the interface.-- Much of it is
defensive behavior: The user does not want to seem dumb about the
technology.-^
On the other hand, most systems analysts feel limited i-esponsibility for
the effects of new systems they implement. A study by Bostrom and Heiner
showed that analysts are preoccupied with low costs and technical sophis-
tication. They tend to ignore the trade-offs that are essential to a design that
makes the user comfortable. They also seem to view themselves as creators
rather than participants in the development pix)cess. The result is ignoring
user suggestions and producing analyst-oriented rather than user-oriented
systems.^'*
Beneath the surface lies the fundamental difference in the way analvsts
and users process information. Cognitive styles, for example, produce inter-
esting insights into the pixjblem of designing computer systems. If the
dominant style of the analyst is analytical and that of the user is heuristic,
then the prospect of designing a system that meets the user's expectations
is remote. If the analysis (and therefore the system! is presented in a fomiat
that fits the cognitive style of the user, however, then the candidate system
is expected to be successful.^^
-*
Daniel Robey, "Perspectives of the User Interface," in Proceedings of the 17th Annual
Conference of the SIGCPR, 1980, p. 23.
22 Larry G. Faerber
and Richard L. Ratcliff, "People Problems Behind MIS Failures," Financial
Executive, April 1980, pp. 18-24.
23 Pamela McGhee, "What Do Users Want?" Computenvorld, March 23, 1981, p. 84.
2^ R. P. Bostrom and J. S. Heiner, "MIS Problems and Failures," MIS Quarterlv, December
1977, pp. 48-50.
25 I. Benbasat and R. N. Taylor, "The Impact of Cognitive Styles on Information System
Design," MIS Quarterly, June 1978, pp. 143-48.
72 PART ONE / OVERVIEW
Tvvo implications may be drawn for system design. First, there is a need
for mutual undei'standing between the analyst and the user. Second, once
diiferences are understood and accepted, alleviating them may be possible
through a deeper involvement of the user and support of the analyst.
Conflict Resolution
design a system to meet the user's requiiements, and the user, in turn,
agrees to accept the system based on what has been specified.^" In effect,
DDR forces communication between the analyst and the user and bridges
the knowledge gap by requiring all parties to be explicit.
VVm. Taggart, "Human Infoimation Processing Styles and the Infomiation System Archi-
-''
tect in the PSC Systemeeiing Model," in Proceeding's of the 17th Annual Conference of the
Special Interest Group on Computer Personnel Research, 1980, pp. 62-76.
2" Hillard McLamore, "How to AvoiAHassles and Headat;hes When Systems People and
Users Meet," SAM Advanced Management Journal, Summer 1978, pp. 5-12.
i
There is a direct line of authority' fix)m the director of MIS services to each of
the supervisoi-s in charge of analysis and design, programming, and opera-
Administrative
Director Staff
MIS
Sen/ices
Technical
Staff
Personnel
Methods and
Training
Procedures
and Testing
74 PART ONE / OVERVIEW
a. User liaison which handles the changing needs of the user and
user-systems relationships.
b. Long-range planning, which includes personnel selection, recinjit-
ment, application development, and planning for anticipated
changes in hardware and software.
c. Budget planning and control of the entire MIS division.
d. Personnel administration and training for upgrading employee
skills.
project leader who i-eports dii^ctly to the systems manager. This arrange-
ment is typical of smaller installations that handle limited projects.
In a pool-oriented arrangement, analysts work on any system assign-
ment within the fimi. Once the job is completed, they return to the pool for
another assignment. In Figure 3-4, a system team is on loan to report
Manager
Systems
Analysis
and Design
1 1
1 4 Analysts j 1 Senior Analyst i
1
(on loan) 3 Analysts I
J
! ! (on loan) '
1 J- J - 1
Director
System
Development
4'-
Director
Computer
Services
Programmers
3 / THE ROLE OF THE SYSTEMS ANALYST 77
Supervisor
Operations
The Paraprofessional
The tasks that make up the system development process are changing. With
an increase use of structured tools, there are emerging tasks that are
in the
less technical or ci'eative than the traditional ones. Rather than the analyst
ignoring them or tving up valuable time, they are carried out by less
experienced paraprofessionals.-These tasks are categorized as follows:
80 PAKT ONE / OVERVIEW
3. The general support tasks require limited time for instruction relative to
the time it takes to perform them.-^
1. Communication skills.
for thecandidate system. The writer seeks to uncoxer the hidden logic of
the program and con\ert it into an operational pattern. This is where the
technical writer makes major contributions.
Technical writers are usually brought in when the candidate system
nears completion. Problems often i-esult fixjm the analyst's lack of intei-est in
a system that is already histoiy. When errore are uncovered in a system and
reflect on the analyst, irritation turns into hostilit\'. This makes the job of the
technical writer a real challenge. There is evidence of the emergence of
technical writing as a computer-based specialty in the proliferation of
writing subspecialties and the consulting positions they have spawned.
There are methods analysts who develop standards and pixjcedures man-
uals, indexers, hardware, and operations writers. Experienced writers in
high-tech areas such as expert systems earn more than S75 per hour.-^
CONCLUSIONS
In this chapter, an attempt was made to discuss the ix)le of the analyst and
the importance of the analyst/user interface for successful systems. Al-
though the interface may be \nlnerable because of advancing technology,
the basic foundations of human interaction and organization remain im-
portant for system development. In a speech before the National Associa-
tion of Secondary' Principals, Birnbaum pointed out that "man-made com-
plications that surround the citation of systems are the principal barriers to
our success today. "^'^ This illustrates the need for maintaining a viable
interface throughout the system life cycle.
Communication between the user and the analyst is pix)bably the most
important aspect of the interface. Analysts need to explain and usei's need
to understand the fi-amework surrounding the candidate system before
there is total acceptance. George Bundy, foimer Kennedy administration
aide, once explained the relationship between the White House (analysts)
and the people of the United States (users) as follows:
I think we're a little like the Harlem Globetrotters in the performance they put
on before the game; they pass the ball under their legs and under their amis
and throw it down the field (court). It is all very dazzling, but at some point, the
whistle blows, the game begins, and then what matters is whether you make
baskets. 31
2^ Gene Knauer, "The Rise of the Technical Writer," Computenvorld, January 9, 1984, p. Iff.
3" Joel S.
Birnbaum, "Microelectronics and Education," What the Ne^t Decade Will Bring
Moscone Center, San Francisco, March 19, 1983.
31 Edward A. Tomeski and Harold Lazarus, People-Oriented Computer Systems (New York:
Summary
1. A systems analyst is a person who conducts a study, identifies acti\ities
and objectK'es, and determines a procedure to achieve the objectix'es.
Systems analysis has a history dating back to Ta\lor. Earl\' anal\'sts
worked in factories, specializing in improxing work methods and set-
ting time standards for production. W ith the ad\ent of the computer,
the analvst assumed the role of a problem soher and a specialist in
dexeloping computer applications.
8. Of all the managerijil and administration positions in the MIS area, the
position of the analyst is perhaps the most crucial. The job carries
considerable responsibility, high status, and attractive pay.
.
10. Another new position in systems work is the technical uriter, who is
Key Words
Conflict Resolution Project-Oriented Stioicture
Expectancy Theory Systems Analyst
Functional Structure Team-Oriented Structure
Paraprofessional Technical Writer
Pool-Oriented Structure
Review Q^uestions
1. Trace the histoiy of systems analysis and compare the major changes or
differences in today's role of the analyst.
Discuss.
.
1 1 Explain the makeup of and the acthlties undertaken by the MIS organi-
zation. Where does the anal\"st fit in?
12. Distinguish between the following:
a. Project-oriented and pool-oriented arrangements.
b. Pool approach and team approach in programming.
c. The jobs of the manager iSNStems department and the systems
i
analx'st.
13. \'isit the MIS department of a local firm and ask the manager his her
opinion of the role of the paraprofessional and the technical writer in
system de\elopment.
Application Problems
E^cperience: One year (full-time) with a local accounting firm as Cobol pro-
grammer; two yeai-s with a retail chain as computer operator; 1 .5
years as a keypunch operator at a bank.
Assignment
a. What additional information would you like to gather- during a second
interview?
she handled the coupons. E\er\ thing seemed normal, although there
were occasional errors in ke\ing the amounts or code. The last da\ was
Frida\ and the anal\st had no answers. The president was disap-
pointed with the lack of feedback. \\ hen confronted, the analyst admit-
ted that he had little knowledge of accounting, auditing, or how
accounts are reconciled, but if he had another week, he could leam
enough to computerize the whole operation.
Toward the end of the day. a customer's passbook was posted with
the wTong amount. Upon closer inspection, it was found that the teller
machine alwa\'s printed 9 instead of 0. When the machine was replaced,
the Christmas Club account balanced with no difficultv
Assignment
a. What mistakes did the anal\st make in handling the project.-' Did he use a
correct procedure? Explain.
b. WTiat t\pe of personalitv would it take to deal with a problem like the one
just described? Why?
c. WTiat qualifications do \ ou suggest the anal\ st possess to handle this case?
Why? EAplain.
Selected References
-Anderson. \\m. S. The ELxpectation Gap. Journal of Systems Management. June
1978. pp. 6-10.
.A\vad, E.M. Aocational Needs Reinforcers and Job Satisfaction of .Analysts and
Programmers in a Banking En\1ronment. Tenth Australian Connputer Con-
ference. Melbourne Australia September 26 1983.
Benbasat, I., and R. Taylor I\'. The Impact of Cogruti\e Stales on Information
System Design. MIS Quarterly. June 1978. pp. 143-48.
'
Bimbaum, Joel S. "Microelectronics and Education: What the \e.\t Decade WUl
Bring Moscone Center. San Francisco March 19. 1983.
Bostrom, R. P., and J. S. Heiner. MIS Problems and Failures. .A Sociotechnical
Perspecti\e. Part I: The Causes." MIS Quarterh 1, no. 3 iSeptember 1977>,
pp. 17-32.
Part II: The .Application of Socio-technical Theon . MIS Quarterly 1 no. 4
December 1977 pp. 11-28. .
Bramson. .Albert M., and .Allen F. Harrison. The Orderiy Ways of .-Analysts." Com-
puter Decisions, November 1983, p. llZflf.
Campbell, Robert Braun. .Anal\:zing Systems .Analysis " Journal of Systems Manage-
ment. .\Iai-ch 1983, pp. 22-23.
Cana\ an Edward M. The M\ sterioup Systems Anahst. " Journal of Systems Manage-
,
Cochran, Terry L. "Know Thy User. Datamation, January 1979, pp. 46-49.
"
Scharer, Laura. "Systems Analysts Performance: Criteria and Priorities. " Journal of
Systems Management, Februar\ 1982, pp. 10-15.
Schein, E. Organizational Psycholog}. 2d ed. Englewood Cliffs, \J.. Prentice-Hall,
1970.
Shapin, Paul G. "System Selection Needs Users Invohement for Success." Info-
systems, September 1980. p. 104ff.
Synnot, \\m. R., and W'm. H. Gruber. The Care and Feeding of Users. ' Datamation,
March 1982, pp. 191-204.
Taggart, \Vm. "Human Information Processing Stv'les and the Information System
PSC Systemeering Model." In Proceedings of the 17th Annual
Ai"chitect in the
Conference of the Special Interest Group of Computer Personnel Research
ISIGCPRi, June 1980, pp. 62-76.
Tomeski, Edward A., and Harold Lazarus. People-Oriented Computer Systems. New
York: Van Nostrand Reinhold, 1975, pp. 238-45.
"Too Man\ Pixjfessionals? Editorial, Xewsweek on Campus, University' of X'irginia,
Mai-ch 1984, pp. 8ff.
•'
«' '
s:
;.;a-
;*.
H-\' '
Part Two
Systems Analysis
v -
4 SYSTEMS PLANNING AND THE INITIAL
INVESTIGATION
5 INFORMATION GATHERING
O THE TOOLS OF STRUCTURED ANALYSIS
7 FEASIBILITY STUDY
8 COST/BENEFIT ANALYSIS
91
Chapter 4
Systems Planning
and the Initial
Investigation
Introduction
Initial Investigation
NEEDS IDENTIFICATION
DETERMINING THE USER'S INFORMATION REQUIREMENTS
Strategies tor Determining Information Requirements
Asking
Getting Information from the Existing Information System
Prototyping
CASE SCENARIO *
PROBLEM DEFINITION AND PROJECT INITLATION
92
.
At a Glance
BACKGROUND ANALYSIS
FACT-FINDING
Review of Written Documents
On-Site Observations
Interviews and Questionnaires
FACT ANALYSIS
DETERMINATION OF FEASIBILITY
94 PART TWO SYSTEMS ANALYSTS
/
INTRODUCTION
It is always wise to look ahead, but it is difficult to look further than you can see.
Dimensions of Planning
The following conditions dictate todays business strategies:
1. High interest rates make it more important that business realizes a good
return on investment.
2. Inflation puts pressure on profit when it occurs.
'
Ephraim R. McL^ean and John V. Soden, Strategic Planning for MIS (New York: John Wiley
&. Sons, 1977), p. 6.
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 95
Competitive
advantage
Higher
productivity
t
Record- Time/Experience
keeping
2 Harvey Poppel, Strategic Impact of Information Technology (New York: Deltak, Inc., 19821,
pp. 5, 9.
3 Geoi^e A. Steiner, "Formal Strategic Planning in the United States Today," Long Range
Planning 16, no. 3 (1983), pp. 13-17.
C
o
>
a;
Z
a
<i>
o •o
c o
o J-J
u
0)
C!
-f-H
c
D
CO
o ^ a;
n >
c „
(1)
E Q)
"S
ID
Q a
to Ed
U5 1 ,
•a
Q.
c
B
I Q)
<At
W C
<D
O O "5
< 5
C N
c 3 J.
0)
d.
a
,
1. What MIS objecti\es and strategies can be deri\ed trom the corporate
strategic plan?
* Brent Bowman, Gordon Davis, and James Wetherbe, "Modeling for MIS," Datamation. JuK
1981, pp. 155-64.
98 PART TWO / SYSTEMS ANALYSTS
Phase I I
Top
Management
Data Processing
Executives
C R
O E
N P
T
Data Processing/ O
User Management
R R
O T
I
N
DP Management/ G
DP Staff
End Users
DP Staff
5 Robert E. Uef, Robert D. Dodge, and Ralph L. Ogden, "Adapting DP Strategy to Manage-
ment Style," Computerworld (In Depth), December 5, 1983, pp. 25-32.
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 99
INITIAL INVESTIGATION
As mentioned in Chapter 2, the first step in the system development life
The user request identifies the need for change and authorizes the
initial investigation. It may undergo several modifications before it becomes
a written commitment. Once the request is approved, the following ac-
tivities are carried out: background investigation, fact-finding and analysis,
and presentation of results — called project proposal. The proposal, when
approved, system perform-
initiates a detailed user-oriented specification of
ance and analysis of the feasibility of the candidate system. A feasibility
study focuses on identifying and evaluating alternative candidate systems
with a recommendation of the best system for the job. This chapter deals
wdth the initial investigation. Chapter 7 discusses the feasibility study.
Needs Identification
The success of a system depends largely on how accurately a prx)blem is
later than:
NEW 12/0S/i4 07 103 lis
REVISIONl dv mo yr. dv mo vr
i
Report title ciUitomzfi montklq itaZzm znt Document Title bltZinQ noticzA
Quantity 2-5 No. of pages/report Quantity If^I^^O
^ No. of copies/report
Remarks tzXZzn. quuiLcty pKA-ntx-ng Remarks nujnbzn o^ noticu vaKlzi Muth izoAon.
Ln JanaaALf,iangz may be 200- ,uuu. i
Report' title
Quantity No. of pages/report Document Title
No. of copies/report Quantity
Frequency daily Frequency daily
weekly other ^weekly other
Remarks Remarks
REQUESTER —Please Fill Out
The user or the analyst may identify the need for a candidate system or
for enhancements in the existing system. For example, the cashier (chief
operations officer) of a bank may ||ecome concerned about the long cus-
tomer lines in the lobby or about the number of tellers who are "over" or
"short" they balance their cash. Similarly, an analyst who is familiar
when
with the operation may point out a bottleneck and suggest improvements.
4 / SYSTEMS PLANNING AND THE INPriAL INVESTIGATION 101
What is the objective of a city To impart wisdom of the Majority of books checked
libraiy? ages to the uneducated out are for enjovinent rather
than fact-finding
VVh\' do most people buy fur- To furnish new homes, apart- Mai-keting informs us that
niture? ments; to sit on, eat on, etc. people discard old furniture
not l)ecause it is nonfunc-
tional but because it does
not look good anymoit;
What is the objective of a To store two automobiles Families desire to pai-k one
two-car garage? and protect them from the car only and sa\e i-oom to
elements store more important ecjuip-
ment lor junki
What is the objectixe of an in- To ensure prompt axailability Isn't locating a key factor?
ventory control system? of needed material Ai-en't costs a primary consid-
eration?
30-
Source: Adapted from Jack Caldwell,
1982, p.
The Misunderstanding of Objectives," Journal of Systems Management, June
Often problems come into focus after a joint meeting between the user and
the analyst. In either case, the user initiates an investigation by filling out a
request form for information. The request provides for statements of objec-
and expected benefits.
tives
The objectives of the problem situation must be undei-stood within the
framework of the organization's MIS objective, as discussed earlier under
system planning. If objectives are misundei^tood, it is easy to solve the
wrong problem. In Table 4-1, Caldwell cites examples of "typical versus "
"real "
objectives of decision situations. It illustrates that the successful
design of a system requires a clear knowledge of what the system is
intended to do.
6 George Pitzgorsky, "Analyzing, Defining Systems Needs," MIS Week, August 24, 1983, p. 30.
~ J.D. Couger, "Comparative Analysis of Information Systems Curricula," Computer News-
letter for Schools of Business, vol. XVll, No. 2, (October 19831, p. 1.
102 PABT TWO / SYSTEMS ANALYSTS
information analyst determines the needs of the user and the information
flow that will satisfy those needs. The usual approach is to ask the user
what information is currently available and what other information is re-
quired. Interaction between the analyst and the user usually leads to an
agreement about what information will be provided by the candidate sys-
tem.
There are several reasons why it is difficult to determine user requii^-
ments:**
1. In the kitchen sink strategy the user throws everything into the require-
ment definition — overstatement of needs such as an overabundance of
reports, exception pixjcessing, and the like. This approach usually reflects
the user's lack of experience in the area.'"
2. The smoking strategy sets smoke screen by requesting several
up a
system featui'es when only one or two are needed. The extra inquests are
used as bargaining power. This strategy usually reflects the user's experi-
" Laura Schamr, "Pinpointing Rociuirements," Datamation, April 1981, pp. 139-40.
^ Scharer, "Pinpointing Requirements," p. 140.
•"See Wm. J. Doll and U. Mesbah i^med, "Managing User Expectations," Journal of
Systems Management, June 1983, p. 6.
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 103
Humans
have problems specifying infoiTnation requirements. "Asking"
the user whatis needed of a candidate system does not often yield accurate
2. Human bias in data selection and use. Humans are generally biased in
their selection and use becomes a representation of
of data. Their beha\dor
the bias. For example, users are influenced more by recent events than by
past events. Thus, an information need that was discovered recently tends
to carry greater weight than a need experienced in the distant past. This is
called the recency effect. In another bias, users tend to use only information
that is form in which it is displayed. This means that the
available in the
requirements provided by the user are biased by currently available infor-
mation.
3. Human problem-solving behavior. Humans have a limited capacity for
rational thinking. According to Simon, they must simplify it in order to deal
with it. Coined as the concept of bounded rationality, it means that ra-
tionality for determining information requirements is "bounded" by a sim-
plified model (as well as by limited training, prejudice, and attitude of user)
that may not reflect the real situation. ^^ Bounded rationality is often re-
flected in the behavior of systems analysts. A successful analyst uses a
general model to search for information requirements. It includes the
consideration of organizational and policy issues in arriving at realistic
requirements. The poorly rated analyst does not consider these issues, but
focuses on the immediate (short-term) requirements facing the user.
>* Gordon B. Da\is, "Strategies for Information Requirements Determination," IBM Systems
Journal 21, no. 1 (1982), p. 5.
*2 A. Newell and H. A. Simon, Human Problem Solving (Englewood Cliffs, N J.: Prentice-Hall,
1972).
104 PART TWO SYSTEMS ANALYSTS
/
Olaf Helmer, "Ancilysis of the Future: The Delphi Method," in Technological Forecasting
^*^
for Industry and Government: Methods and Applications, ed. James R. Briglit lEnglewood Cliffs,
NJ.: Prentice-Hall, 19681, pp. 116-122. For cx|pples of its use, see M. A. Linstone and M. Turoff,
eds., The Delphi Method: Techniques and Applications (Reading, Mass.: Addison-Wesley Pub-
lishing, 19751.
I
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 105
hea\ily on the user to articulate information needs. The analyst examines all
reports, discusses with the user each piece of information examined, and
determines unfultilled information needs by interviewing the user. The
analyst is primarily inxoKed in impix)\ing the existing flow of data to the
user. In contrast to this method is decision analysis. This bi^aks down a
pixjblem into parts, which allows the user to focus separateK' on the critical
issues. It also determines polic\ and organizational objectives rele\ant to
the decision ai'eas identified and the specific steps I'equii'ed to complete
each major decision. Then the analyst and the user refine the decision
process and the infomiation I'equii^ments for a final statement of infonna-
tion requirements.
The data analysis method is ideal for making stin.ictui'ed decisions,
although it requires that usei's articulate their information i-equii^ments. A
major drawback is a lack of established rules for obtaining and validating
information needs that are not linked to oi'ganizational objectives.^"
In the decision analysis method, information needs are cleai'ly linked to
decision and organizational objectives. It is useful for unstn.ictured deci-
sions and information tailoi^ed to the user's decision-making st\'le. The
major drawi;:)ack, though, is that information requii-ements may change
when the user is pix^moted or replaced.
Lo w
Information requirements Uncertainty
process uncertainties Strategy
1
^M Stability of a
set of informa- Asking
^M tion requirements
^H
^H User's ability Level of
Getting information
from an existing
^M to articulate
information
uncertainty information
system
^H
Analyst's ability
to elicit informa-
tion requirements Prototyping
and evaluate their
accuracy
i .'•.
i
•,
High
Uncertainty
Source: Adapted fiDm Gordon B. Davis, "Strategies for Information Requirements Determination, IBM Systems
Journal 21, no. 1 (19821, p. 21.
Case Scenarlo^^
To apply the steps undertaken in an initial investigation, we use a case
based on a real system development project that occurred in a medium-size
commercial bank in a large city. For the purposes of this investigation, we
shall call it the First National Bank of South Miami. The city has a popula-
tion of 200,000.
In 1980, the bank had a department that consisted of three
safe deposit
employees and 4,000 boxes of various sizes. They are rented to bank cus-
tomers, jewelers, and retailers in the neighborhood. Late in the year, an
influx of illegal immigrants contributed to a rise in the number of burglaries
and break-ins. This created a demand for safe deposit boxes for storing
personal effects (china, jewelry, caati. coins, etc.). With increased demand,
^ This case will be used to illustrate systems analysis and design throughout the text.
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 107
increase required two additional employees, bringing the total staff to five.
The rental procedure begins when a customer applies for a box of a
certain size and pays a year's rent The customer is issued a key
in advance.
that is used simultaneously with the attendant's key to open or close the
box. As shown in Figure 4-6, the customer takes the box to a cubicle. When
finished, he/she inserts the box in the vault, closes the door, and walks out.
Each new box rental generates a transaction for future billing. Bills are
mailed to approximately 5,300 customers, some of whom have two or more
boxes. BUls are processed manually on a cycle basis: every six days, begin-
ning with the first of each month. A customer receives a renewal notice uath
the amount due about a month before the expiration date of the contract.
You are the ancilyst in the bank's MIS department. Your phone rings one
morning and Sibley, the senior vice president in chaise of operations, says,
"Hi, Jack, we have a problem in safe deposit. Can you spare a minute? Let's
get together over lunch and talk. ..." As you interpret the conversation
during lunch, Sibley has a problem. Bills are prepared by hand and mailed
to all customers — a time-consuming job that keeps a clerk busy all day. You
want to formalize that initial investigation, so you ask him to fill out a user
request fonn. Barbara Betolatti, the supervisor, fills out the details. Sibley
.Safe Deposit
Boxes
Billing office
Counter
Entrance
108 PAKT TWO SYSTEMS ANALYSTS
'
verifies them, signs the form, and hands it to you. The form is showii in
Figure 4-4. Let's follow the initial inxestigation process using our scenario.
The first step in an initial in\'estigation is to define the problem that led to
the user i-equest. The problem must be stated clearly, understood, and
agreed upon by the user and the analyst. It must state the objectixes the
user is tiding to achie\e and the insults the user wants to see. Emphasis
should be on the logical requirements iwhat must be the results! of the
problem rather than the physical requirements. For example, in the user
request form, a job objective is improved customer ser\dce (logical objective;
how the objective should be achieved (physical requirement! is not as
important at this time.
Given user identification of need, the analyst proceeds to verifv the
problem by separating svniptoms ftxjm causes. Long customer lines, for
example, are not the pix^blem per se, but are the sxanptoms of staff shortage,
a manual procedure that does not retrieve customer information (master
cards) for clearance, or both. The latter reason is the problem.
<4
Related to the problem definition is the verification of user requii^-
—
ments in our example, the quick and accurate a\'ailabilit\' of safe deposit
information and shorter lines. As we discussed earlier in the chapter,
requirements may be confirmed by eliciting information through one or
moi'e strategies: (1) asking the clerks and the superxisor what they must
have to run the department (questions, brainstorming, orgixjup consensus);
(2) eliciting infomiation from the existing manucil system —
how data ai'e
stored, how up to date they are, how efficient, and so on; or (3! prototxp-
ing— start improxing the existing system, a step at a time, anchoring real-life
change ft-om which fiirther adjustments can be made.
Of these strategies, asking would be the most suitable, since the safe
deposit department is considered to have low uncertainty. This is attributa-
ble to the department's stable information requii^ments (rai-ely a change),
Betolatti's abUity to articulate the information requirements, and the ana-
lyst's ease in eliciting information about the same requirements and eval-
uating their accurac\'.
It is important to consider the planning phase and how planning a
candidate system for safe deposit fits into the larger iMIS enxironment of the
bank. For example, how congruent is designing a safe deposit billing system
with the existing computer enxironment? Suppose a customer's box re-
newal is due and he wants the rent deducted from the checking account
rather than writing a check or pasing cash. How well would an electixjnic
debit-credit procedure work? Should it be considered.-' What managerial
and operational constraints are inxoKed in introducing an alternative sys-
tem for safe deposit? How would ai^improvement in customer service affect
the activity for access to safe deposit boxes, the demand for more boxes, the
image of the department (and the bank) as an all-service bank? Are satisfied
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 109
safe deposit customer likely to open other accounts with or take loans
ft'om the bank? How would a computer-based safe deposit billing system
affect the morale of users in the trust and pereonnel departments who are
inneed of improxdng their operations? These questions relating the pro-
posed system to the larger system should be cai^fuUy evaluated.
Background Analysis
Once the project is initiated, the analyst begins to learn about the setting,
the existing system, and the physical processes related to the revised
system. For example, it is important to understand the stn.icture of the
bank; who runs it; who reports to whom in the safe deposit ai^a; the
I'elationshipbetween safe deposit and the teller line, accounting and cus-
tomer service; and the nature, frequency, and level of interaction between
the safe deposit staff and these departments. The existing billing system
could be the result of ill-trained staft or inefficient organization, or both. It
could be that reorganization might be a solution. Therefore, the analyst
should prepare an organization chart with a list of the functions and the
people who
perform them. In doing so, he/she would have a better feel for
the work environment in which safe deposit operates, the kinds of custom-
er involved, and the procedure employees follow in conducting business
in safe deposit.
Fact-Flnding
After obtaining this background knowledge, the analyst begins to collect
data on the existing system's outputs, inputs, and costs. The tools used in
data collection are covered in detail in Chapter 5. They are (1) review of
wiitten documents, (2) on-site observations, (3) interviews, and (4) question-
naires.
""
3/a' AVAILABLE
,^7^ J?£>y
WITNESSED
HISTORY CARD
Sc^rr ^Jj!^ OAll
^
'Se
o<i-
IJI^^,
J>^'-
f)^
^<£v^'
r^
r^o^
-fiJ^^ ^*f ",.>'^";"7^.<./^
Advice
of Charge
ACCT NO.
^K2^ ^^/'^^^^^y^
^ -^ K^V-^^jt:^
^^..u^
APPROVED
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 111
On-Site Observations
Another fact-finding method used by the systems analyst is on-site or
direct observation. The analyst's role is that of an information seeker. One
purpose of on-site observation is to get as close as possible to the "real"
system being studied. As an obsener, the analyst follows a set of rules.
While making observations, he/she is more likely to listen than talk, and to
listen with interest when information is passed on. He/she a\'oids gi\ing
ad\ice, does not pass moral judgment on what is observed, does not argue
with the user staff, and does not show undue friendliness toward one but
not others.
On-site observation is the most difficult fact-finding technique. It re-
quires intrusion into the user's area and can cause adverse reaction by the
users staff if not handled properly. The analyst obserxes the physical layout
of the current system, the location and mo\'ement of people, and the work
flow. He/she is alert to the behavior of the user staff and of the people with
whom they come into contact. A change in behavior provides £in experi-
enced analyst with clues that can help put the behavior observed in per-
spective.
The following questions should precede a decision to use on-site
observation:
Fact Analysis
As data are collected, they must be organized and evaluated and conclu-
sions drawn and approval.
for preparing a report to the user for final review
Many tools used for data organization and analysis. As will be discussed
are
in detail in Chapter 6, among the tools used are input/output analysis,
decision tables, and structure charts.
Input/output analysis identifies the elements that are related to the
inputs and outputs of a given system. Flowcharts and data flow diagrams
are excellent tools for input/output analysis. For example, Figure 4-8 is an
information-oriented flowchart of our safe deposit pixjblem. It is a systems
flowchart that displays the relationships among the forms used in the
existing billing system. Figure 4-9 is an input/output analysis sheet that
describes the relationships among inputs, processing functions, and out-
puts for the safe deposit function of the bank.
Data flow diagrams ai-e also used to analyze the safe deposit billing
system. They can be very eff'ective in settings that pose few constraints on
the development or modification of the system under study. Figure 4-10 is a
data flow diagram whose content is equivalent to the infonnation-oriented
flowchart in Figure 4-8. It shows the general steps in the safe deposit billing
system. As an input/output analysis technique, it enables the analyst to
focus on the logic of the system and develop feasible alternatives. The
circles (also called bubbles) represent a processing point within the system.
The open rectangles represent data stores or points where data are stored.
The squai'es are departments or people involved in the billing system. The
major steps in the billing process are extracting the customer account,
applving the renewal cycle, preparing the bill, processing the payment, and
accounting for cash receipts.
Decision tables describe the data flow within a system. They are gener-
ally used as a supplement when complex decision logic cannot be repre-
sented clearly in a flowchart. As a documenting tool, they provide a simpler
form of data analysis than the flowchart. When completed, they are an easy-
to-follow communication device between technical and nontechnical per-
sonnel. They are verbally oriented to managers, easy to learn and update,
—
Customer Extract
Customer
record account to
record
read
1^
Apply new
billing renewed
cycle
Prepare
statement
Customer ^—1"""^
invoice 1
^_^^^'^ Record
File record
balance
\ File /
Payments Payments \/
^^^^ ^^^^ Payment/
credit memo
Payment/credit
memo
^__,^^'^
Aged receiv- -r—-f"^^^
able report t
^ Payment/
credit memo
Account
journal
Aged
receivable
report
>
Cash and
balance
journal
I
list
'^—
^
—*^
L
list
"^
-* Customer
Customer Customer statement
receipt receipt
^ ^ Safe deposit
\ revenue
V
Safe deposit
revenue report
report
114 PAET TWO SYSTEMS ANALYSTS
/
FIGURE 4-10 Simplilied Data Flow Diagram of the Existing Sate Deposit
Billing System
Account
Transaction
Detailed
Transaction
Data
Cash
and Balance ] 5
Journal
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 115
and continue to function once the logic is developed (see Figure 4-11).
Details on the structure and uses of decision tables are covered in Chap-
ter 6.
A structure chart is a working tool and an excellent way to keep track of
the data collected for a system. There are several variations of a structure
chart. Briefly, the analyst starts vvdth a single input/processing/output (IPO)
chart, locates the module associated with the IPO on the hierarchy chart,
and identifies the data elements along the line linking the module to a
higher level (pai^ent).
Determination of Feasibility
After organizingand summarizing the data, the analyst has a thorough
knowledge of the system. The following information should be available:
• Interview and correspondence records.
• Updated system documentation.
• Flowcharts.
• Familiarity with names, positions, and pei-sonalities of user personnel.
• Specification of the good and bad features of the current system.
• Understanding of how well actual problems facing the system are in line
with the problem(s) stated in the user request form.
identify the principal user. In our safe deposit department example, al-
though the supervisor is the person in charge of the operation, it was found
that the senior vice president is the principal user the one who accepts or —
FIGURE 4-11 Decision Table — Safe Deposit Billing Routine
Billing 1 2 3 4 5
rejects the candidate system. He is the one who also issued project direc-
tives and has a final say on what can and cannot be done. When the final
report was turned in, he reviewed it (with the supervisor) for content,
justification, and authorization to implement the online safe deposit billing
system.
The
final decision is the end user's response to a project directive.
When approved, it becomes an authorization document that also reflects
the results of the discussions made during the final review. More and more
organizations have a computer user committee as a final approval authority
for the project undertaken.
A signature on the directive by the end user and its acceptance by the
MIS department make it a formal agreement to proceed with the design and
implementation of the candidate system. So, the directive initiates a feasi-
bility study, which essentially involves the description and evaluation of the
candidate system and the selection of the best system that meets system
performance requirements. These two steps are described in Chapter 7.
Summary
1. Planning information systems has become increasingly important be-
cause information is a vital resource and company asset, more and
more funds are committed to information systems, and system develop-
ment is a serious business for computers that incorporate data bases
and networking.
2. Planning for information systems has a time horizon and a focus di-
mension. The time horizon dimension specifies the time range of the
plan, whereas the focus dimension relates whether the primary con-
cern is strategic, managerial, or operational.
3. The initial investigation has the objective of determining the validity of
the user's request for a candidate system and whether a feasibility study
should be conducted. The objectives of the pi-oblem posed by the user
must be understood within the framework of the organization's MIS
plan.
5. There are three strategies for eliciting information regarding the user's
I'equirements: asking questions, obtaining infonnation from the present
system, and pixjtotyping. The asking strategy assumes a stable system
where the user is well informed about information requirements. In
contrast, the prototyping strategy is appropriate for high-uncertainty
information requirements determination.
6. Fact-finding is the first step in the initial investigation. It includes a
review of uo-itten documents, on-site observations, interviews, and
4 / SYSTEMS PLANNING AND THE INITIAL INVESTIGATION 117
Key Words
Bounded Rationality Planning
Brainstorming Project Directi\'e
Data Flow Diagram Project Pixjposal
Decision Table Prototvping
Delphi Method Recency Effect
Initial Investigation Reliability'
Review Gtuestions
1. Why is it so critical to manage system development? Explain.
9. Discuss and illustrate the key strategies for eliciting information about
the user's requirements. Which strategy would you select? Why?
10. A question may be closed or open-ended. Illustrate the difference.
12. Describe the data analysis method. How does it differ from the decision
analysis method? Elaborate on the pros and cons of each method.
Application Problems
Source
documents
Payments
Customer
inquiries
Encoding
Encodement
reading
computer entry
120 PAKT TWO / SYSTEMS ANALYSTS
Assignment
a. What is the main problem facing Jefferson stores and the credit center? Be
specific.
a. Coupons are classified as $1.00, $2.00, $5.00, and $10.00. For exam-
ple, a club member with 52 $1.00 coupons saves $1.00 per week or
$52 by Christmas.
b. A customer comes in with the coupon book for deposit. The teller
receives the cash, detacheg the coupon, stamps the stub (in the
coupon book) with the date of pavTiient and the amount, and
returns the coupon book to the customer.
4 / SYSTEMS PLANNING AND THE INmAL INVESTIGATION 121
Statement of Problem
Because of the increase in the number of Christmas Club accounts,
ithas become necessary to seek full-timie clerical help to process
the daily coupons. Furthermore, the manual handling of each
coupon has made it more costly to maintain the club.
Assignment
a. Do you agree with the analyst's definition of the problem? If not, how would
you define it? Why? Explain.
b. If you were to do the initial investigation, how would you handle it?
Elaborate.
Assignment
a. Should all user projects that are operationally and technically feasible be
developed as long as the user is paying the price? If so, what should be the
role of the steering committee?
b. What do you think of the makeup of the steering committee? What role
should the analyst, programmer, or data base specialist play in a steering
committee? Elaborate.
$2,100 each. Branch tellers could be well trained in less than four
working days. The softwai-e package costs $18,000.
The existing mortgage loan applications are handled in a l)atch
mode. At the end of the day, each branch sends the mortgage payments
and documents to the computer center, located 18 miles away. When
the documents ai-e received, data entry operatoi-s enter each pavment
and account number directly on disk. V\'hen all transactions are en-
tered, they are processed. All accounts are updated and the resulting
report (1,400 pages long) is^sent to various branches for reference.
Obviously, in a batch environment, all infonnation is based on the
previous day's activities.
4 / SYSTEMS PLANNING AND THE ZNITIAL INVESTIGATION 123
Assignment
a. Based on the information pro\ided, is this proposal feasible? Should it be
pui-sued? Why? Ekiborate.
Selected References
Bariff, M. L. "Information Requirements Analysis: A Methodological Rexiew." Work-
ing Paper 76-08-02, the Wharton School, University of Pennsylvania, Phila-
delphia, 1976.
Bowman, Brent; Gordon Davis; and James C. Wetherbe. "Modeling for MIS."
Datamation, July 1981, pp. 155-64.
Business Systems Planning —
Information Systems Planning Guide. Application Man-
ual, GE 20-0527-3, 3d ed. IBM Coip, July 1981. Available thraugh IBM branch
offices.
Caldwell, Jack. "The Misunderstanding of Objectives." Journal of Systems Manage-
ment. June 1982, p. 30.
Cerullo, Michael J. "MIS: What Can Go Wrong? Management Accounting,
'
April 1979,
pp. 43-49.
Cooper, Roldolpb B., and E. Burton Swanson. "Management Information Require-
ments Assessment: The State of the Art." Data Base, Fall 1979, pp. 5-16.
Couger, J. D. "Comparative Analysis of Infomiation Systems Curricula." Computing
Newsletter for Schools of Business, vol. XVII, no. 2 (October 1983), p. 1.
Davis, Gordon B. "Strategies for Information Requirements Determination." IBM
Systems Journal 21, no. 1 11982), pp. 4-30.
Doll, \Vm. J., and Mesbab U. Ahmed, "Managing User Expectations." Journal of
Systems Management, June 1983, pp. 6-11.
Gore, Marvin, and John Stubbe. Elements of Systems Analysis. 3d ed. Dubuque,
Iowa: Wm. C. Brown, 1983, pp. 178-207.
Haughey, Thomas P., and Robert M. RoUason. "Function Analysis: Refining Informa-
tion Engineering." Computenvorld lln-Depth), August 22, 1983, pp. 24-26flF.
124 PART TWO SYSTEMS ANALYSTS
/
Information Gathering
Introduction
Information-Gathering Tools
REVIEW OF LITERATURE, PROCEDURES, AND FORMS
ON-SITE OBSERVATION
1^
.
At a Glance
INTRODUCTION
Chapters 5 and 7 describe the early phase of system development. Whether
the thrust of the activities is the initial investigation or a feasibilitv' study, the
aim is primarily to develop an understanding of the problem facing the user
and the nature of the operation. Understanding how each activitv operates
requires access to information.
Information gathering is an art and a science. The approach and man-
ner in which information is gathered require persons vvdth sensitivity, com-
mon sense, and a knowledge of what and when to gather and what
channels to use in securing information. Additionally, the methodologv' and
tools for information gathering require training and experience that the
analyst is expected to ha\e. This means that information gathering is nei-
ther easy nor routine. Much preparation, experience, and training are
required.
This chapter addresses the categories and sources of information and
the functions, uses, and relevance of key infoiTnation-gathering tools during
the phases of system analysis. The phases are:
For details on the application of s\stem analysis activities, refer to James VVetherbe,
'
Systems Analysis and Design: Tradilional. S&vctured, and Advanced Concepts and Techniques
(St. Paul, Minn.; West Publishing, 1984), pp. 127-54.
•
Information
Kind of Information Describing
• Polirjps ^«.^
• nnals '•-^
The
• Organization organization
structure
• Authority
relationships "^-..^^^^^
• Job functions ^*''~~'"^-~
User to Information
^^^—"^
• Information
staff gathering
requirements
• Interpersonal
relationships
• Wnrk finw
The work
procedures ^^__,,,,—-— itself
Installment
Installment Officer
Loan
bauni
Loan Loans
vice
ent
Presid
Senior
—
cer
5> io President
Assistant President
Commercial
Vice
KIdd
Loans
Vice
L.
Supervisor
Proof
E
Do ^
'
(ft
c 1
Supervisor
Hookkeopint) 3 Ol
O 2i 1
a:
Ol 5
^ C I
Li-
~\ II
President
E X
II
Second Platform aO
Vice
= Q.
"I coo
moo
c e
5 c
<<
m
Q.
|cn
oSg
OJ>Q.
5 / INFORMATION GATHERING 131
ture are important elements for analysis. Requests for computer ser\ice
must be evaluated in the light of these elements.
documents ftom within the organization and from the organization's en-
vironment. The primary e^iternal sources are:
1. Vendors.
2. Government documents.
3. Newspapers and professioncil journals.
1. Financial reports.
2. Personnel staff.
•A
Verify
time _^ /
/ Data
Dat entry Data entry
cards \ CRT program
Payroll
trans-
actions
© Payroll
program
_^f New \
Year-end
Checks Reports program
INFORMATION-GATHERING TOOLS
No two projects are ever the same. This means that the analyst must decide
on the information gathering tool and how it must be used. Although there
are no standard rules for specifying their use, an important rule is that
information must be acquired accurately, methodically, under the right
conditions, and with minimum interruption to user personnel. For exam-
ple, if the analyst needs only information available in existing manuals, then
134 PART TWO SYSTEMS ANALYSTS
/
Review litera-
ture, procedures,
and forms
On-site
observation
*
Information- Data
gathering Interviews organization
tools
- Questionnaires ^
5 / INFORMATION GATHERING 135
1. Who uses the form(s)? How important are they to the user?
2. Do the forms include all the necessary information? What items should
be added or deleted?
3. How many departments recei\'e the existing form(s)? Why? In Figure
5-6, each department has a reason for receiving a copy of the purchase
oixJer. It would make little sense, for instcmce, if the manager of the
production department required copies of each purchase order e\en
though puchase requisitions were initiated by the department.
4. How readable and easy to follow is the form?
5. How does the informationfoim help other users make better
in the
decisions? What other uses does the form offer the user ai-ea?
On-Site Observation
Another infonnation-gathering tool used in system studies is on-site
observation. It is the process of recognizing and noting people, objects, and
PURCHASE ORDER
A B Dick & Son mc
4117 Waukegan Road
K
Deerlield ill 60015
Inventory
200 Transformers 392K 300 600 00 control
300 Switches 410A 225 67500
Billing
130 Capacitors 17C 4 10 41000
routine
400 2 ft wires 15 35 140 00
60 Reactors 072 10 00 600 00 Purchase
analysis
,
V
(in file)
(copies of
purchase order)
system being observed. This role permits participation with the user staff
openly and freely.
The major objective of on-site obsenation is to get as close as possible
to the "real" system being studied. For this reason it is important that the
analyst is knowledgeable about the general makeup and activities of the
sv'Stem. For example, if the focus of the anahsis is communication, one
needs to know as much as possible about the modes of communication
available thixDugh the organization structure and the aspects of the phvsical
layout that might adversely affect communication. The following questions
can serve as a guide for on-site observations:
3. What is the historv of the system? How did it get to its present stage of
development?
4. Apart from its fomial function, what kind of system is it in comparison
with other systems in the organization? Is it a primary or a secondarv'
contributor to the organization? Is it fast paced or is it a leisurely system
that responds slowly to external crises?
- Haqjer Boyd: Ralph VVestfaU; cind Stanley Stasch, Marketing Research: Tejtt and Cases, 5th
ed. (Homewood. 111.: Hichard D. Irwin, 1981), p. 125.
5 / INFORMATION GATHERING 137
minutes a vehicle was driven faster than 60 miles per hour, the number of
hours an engine was idle in a day, and how much out-of-service time a
vehicle had.^ These and other electronic methods expedite the informa-
tion-gathering process in systems analysis.
On-site observations are not without problems:
1. Intnjding into the user's area often results in adverse reactions by the
staff. Therefore, adequate preparation and training are important.
3 "Electronic: Data for Fleet Management," Fleetowner, 76, no. 6 (June 1981), pp. 76-78.
138 PAKT TWO SYSTEMS ANALYSTS
/
Interviews
The interview is a face-to-face interpersonal role situation in which a
pei'son called the interviewer asks a person being interviewed questions
designed to gather information about a problem area.^ The interview is the
oldest and most often used device for gathering infoiTnation in systems
work. It has qualities that behavioral and on-site observations do not pos-
sess. It can be used for two main purposes: (1) as an exploratoiy device to
identify relations or verify infonnation, and (2) to capture information as it
exists.
Validity no small problem. Special pains are taken to eliminate in-
is
terview bias. We assume that information is more valid, the more freely it is
given. Such an assumption stresses the voluntary character of the interview
as a relationship freely and willingly entered into by the respondent. If the
' Fred N. Kerlinger, Fundamentals of Behavioral Research, 2d ed. (New York: Holt, Rinehart
& Winston, 1973),_p. 481.
5 / INFORMATION GATHERING 139
e. Avoid acting like an expert consultant or confidant. This can reduce the
objecti\ity of the appix)ach and discourage people from freely giving
information.
a. Interviewer: I see what you meain. Could you elaborate further on that?
5. Data recordins. and the notebook. Manv svstem studies fail because of
poor data recording. Care must be taken to record the data, their source,
and the time of collection. If there is no record of a conversation, the analyst
runs the risk of not remembering enough details, attributing them to the
wrong source, or otherwise distorting the data.
The form of the notebook varies according to the tvpe of study, the
amount of data, the number of analysts, and their individual preferences.
The "notebook may be a card file, a set of carefully coded file folders, or a
"
looseleaf binder. It should be bound and the pages numbered. The informa-
tion shown in Figure 5-7 should be included in the notebook.
142 PART TWO SYSTEMS ANALYSTS
/
1. Originals or duplicate copies of all notes taken during investigation are docu-
mented. They are the chief sources of interview and observational data, as well
as background infomiation on the system. Each page of notes should be num-
bered serially, and a running chronological record of them should be kept. The
name of the analyst, the date the notes were taken, and surrounding circum-
stances are all important. Since handwritten notes often are not intelligible to
others, it is good to have them transcribed or typed soon after they are taken.
CLuestionnaires
In contrast to the interview is the questionnaire, which is a term used
for almost any has questions to which individuals respond. It is
tool that
usually associated with self-administered tools with items of the closed or
fixed alternative type. By its nature, a questionnaire offers the following
advantages:
• \o\v that \ou ha\e had the new installation for six months, how would you
evcduate the benefits.^
• Wtiat is your opinion regarding the "no smoking" polic\' in the DP center?
• If you had a choice, how would you ha\e designed the present information
center?
144 PAST TWO / SYSTEMS ANALYSTS
provided for the response. Such questions are more often used in in-
terview's than in questionnaires because scoring takes time.
Closed questions are those in which the responses are presented as a
set of alternatives. There are five major varieties of closed questions:
answered by yes or no; otherudse, an additional choice (e.g., yes, no, I don't
know) should be included. The question sequence and content are also
important.
3. Ranking scales questions ask the respondent to rank a list of items in
order of importance or preference. In Figure 5-11, the first question asks the
respondent to rank five statements on the basis of how they describe his/her
present job.
4. Multiple-choice questions offer respondents specific answer choices
(Figure 5-12). This offers the advantage of faster tabulation and less analyst
bias due to the order in which the answers are given. Respondents have a
favorable bias toward the first alternative item. Alternating the order in
which answer choices are listed may reduce bias but at the expense of
additional time to respond to the questionnaire. In any case, it is important
• Are you personally using a microcomputer in your business? (please circle one)
yes no
• If not, do you plan to be using one in the next 12 months? (please circle one)
yes no ^
• In the performance of your work, are you personally involved in computer
hardware/software purchase decisions? (please circle one)
yes no
5 / INFORMATION GATHERING 145
Please rank the statements in each group on the basis of how well they describe
five
the job mentioned on the front page. Write a "1" by the statement that best describes
the job; write a "2" by the statement that provides the next best description, and
continue ranking all five statements, using a "5" for the statement that describes the
job least well.
Under $15,000
$15,000-$19,999
$20,000-524,999
Over $25,000
• Please check one category that best describes the business of the firm where you
are employed.
Savings bank
Computer service
Industricd company
Outside computer consulting
Other (please describe) .
—
• How satisfied are you udth the following aspects of your present job? Iplease
circle one for each question)
Very Very
Dissat- Dissat- No Sat- Sat-
isfied isfied Opinion isfied isfied
1. Decide what data should be collected; that is, define the pix)blem to be
investigated.
1. Question content.
a. Is the question necessary? Is it a part of other questions?
b. Does the question adequately cover the area intended?
c. Does the subject(s) have pi-oper information to answer the ques-
tion?
d. Is the question biased in a given direction?
e. Is the question likely to generate emotional feelings that might lead
to untrue responses?
2. Question wording.
a. Is the question worded for the subject's background and experi-
ence?
b. Can the question be misinterpreted? What else could it mean to a
respondent?
c. Is the frame of reference uniform for all respondents?
1. If we
administer the same questionnaire to the same subjects, will we
get the same or similar results? This question implies a definition of
reliabUty as stability, dependability, and predictability.
Ibid., p 442.
5 / INFORMATION GATHERING 149
case, the test is unreliable. Figure 5-15 shows the three sets of scores. The
rank orders of the first two sets of scores covary exactly. Even though the
test scores in the two columns are not the same, they are in the same rank
order. To this extent, the test is reliable. The opposite case is shovvoi in
columns (1) and (3). The rank order changed, making the test unreliable.
It can be seen, then, that for an information-gathering instrument to be
92 1 96 1 72 3
81 2 82 2 89 1
70 3 69 3 51 5
59 4 61 4 74 2
40 5 55 5 67 4
"
ing tool is judged by the criteria of validity and reliability. Both depend on
the design of the instrument as well as the way it is administered.
Summary
1. Much of the information that we need to analyze a system relates to the
organization, the user staff, and the work flow. Organization-based
information deals vvdth policies, objectives, goals, and stnjcture. User-
based information focuses on job functions, information requirements,
and interpersonal relationships. Work-based infomiation addresses the
work methods and procedures, and work schedules. We are
flow,
interested in what happens to the data through various points in the
system.
2. Information is gathered ft-om sources within the organization and ft'om
the organization's environment. External sources include vendors, gov-
ernment documents, and professional journals. The primary internal
sources are financial reports, personnel, system documentation, and
users.
in their own
words, wheras the structured approach requires a specific
response to open-ended or closed questions.
8. There are five major xarieties of closed questions:
a. Fill-in-the-blanks questions inquest specific information.
b. Dichotomous questions two-answer choice.
offer a
c. Ranking scales questions ask the respondent to rank a list of items
in oixler of importance or pi-eference.
d. Multiple-choice questions ask for specific answer choices.
e. Rating scales questions ask the respondent to rank \arious items
along a single dimension scale). i
Key Words
Closed Question Open-Ended Question
Contri\ed Obser\ation Questionnaire
Dichotomous Question Ranking Scales Question
Direct Obser\'ation Rating Scales Question
Fill-in-the-Blanks Question Reliabilitv
Indirect Obser\ation Structured Interxiew
Infomiant Structured Obser\ation
Inter\iew L'nobtrusixe Observation
Multiple-Choice Question Unstructured Interview
Natural Obser\ation Unstructured Observation
Obtrusive Obser\ation X'aliditv
On-Site Obserxation
Review QiUestions
1. What categories of information are available for analvsis? How would
one decide on the category for a given project?
6. Visit the computer center of a local firm. Review a user manual and
report your findings.
7. What is considered in evaluating forms? Explain.
8. How would one conduct an on-site observation? Lay out a plan and
specify the pros and cons of this tool.
19. What is rapport? As an analyst, how do you gain and maintain rapport
with the user's stafi? Give an example.
20. What kinds of data should be recorded? Why?
21. Distinguish between validity and reliability. How are they related?
d. Multiple-choice questions.
e. Rating scales questions.
5 / INFORMATION GATHERING 153
Application Problems
Analyst [ignores answer^. What's that girl doing in the room across the
hall? She hasn't done a thing since I walked in here.
Manager: She shipping orders.
verifies It could be that she is waiting for
more orders fiDm purchasing.
Analyst: Why do you need
check these orders to when they have al-
The manager reluctantly agrees. The manager walks udth the ana-
lyst to the clerk's desk. She is idle. He introduces the analyst to her.
Analyst: What woric do you do, Miss Meyer?
Meyer: I verify the goods against shipping orders.
Analyst: How do you know that the shipping orders are correct?
Meyer: guess I don't, but I verify the type, number of units ordered,
I
and shipping address against the units produced before they are
loaded on the truck.
Analyst: Aren't you wasting your time doing this?
The manager, stcmding by, begins to get irritated. The analyst now
talks to the manager while in Meyer's area.
Analyst: That's all I wanted to find out fixjm this area. What are those
other girls doing there?
154 PAKT TWO SYSTEMS ANALYSTS
/
Manager: The\ 're prett\' bus\' right now. Jane o\er on the right is
breaking in a new girl we just hired. If you are after the pre)cedure,
we have it all documented. I'd be glad to gi\e \ou a copy in my
ofiice.
Analyst: I'm not sure how up to date your documentation is. I'd rather
hear it from them.
The manager leads the analyst to the west comer of the warehouse
where four giris are t\ping. He intix)duces the analvst to the senior clerk.
Analyst: How many bills of lading does your average typist prepare per
day?
Senior clerk: Around 60; ma\'be 70.
Analvst: \'ou ha\'e fi\'e t\pists here, including yourself and your total
output yesterda\ w as only 200. What happended?
Senior clerk: First, as \'ou can see, we're training a new person here.
The girls also file, call customers to tell them that the oixJer is on its
Analyst: Don't you think that this i-unning are)und is a waste of time?
Senior clerk: [no answer]
Assignment
a. How do you rate the interview? Elxplain.
/ If you were the analyst, illustrate how \'ou would ha\e conducted the
interview.
5 / INFORMATION GATHERING 155
a. Faculty may gain better insight into student activities when making
recommendations to employer's, graduate schools, or awards com-
mittees, without much effort.
The questionnaire shown here was used to collect data from fourth-
year MIS students at the college of business. After the data were tabu-
lated, the specific format of the NAT was developed and information
was entered into the data base. Since an IBM PC lab was readily
available, a dBASE II package was used to implement the prototype.
Assignment
a. What type of questionnaire was used?
Critique the questionnaire in terms of its length, completeness, organiza-
tion, and sequence. What changes would you make?
c. Since a prototype was selected for determining feasibility, should all univer-
sity actiwties have been included rather than only those that were unique to
business students? Why?
: : ; .
NONACADEMIC TRANSCRIPT
DATA COLLECTION FORM
Instructions After filling out the top portion of this form,
please check each activity on the list below that
you were involved in during your enrollment at the
university.
Name SSN
first m. 1 last
Current Address
Phone : _
School
Year:
Major
Example Years
Activity Level of Involvement Participated
*^ Alpha Epsilon Pi Vice president.
rush chairman
®©©©
Greek Organizations
Years
Activity Level of Involvement Participated
Alpha Epsilon Pi 12 3 4
Alpha Phi Alpha 12 3 4
Alpha Tau Omega 12 3 4
Beta Theta Pi 12 3 4
Chi Phi 12 3 4
Chi Psi 12 3 4
Delta Kappa Epsilon 12 3 4
Delta Sigma Phi 12 3 4
5 / INFORMATION GATHERING 157
Years
Activity Level of Involvement Participated
Delta Tau Delta 12 3 4
Delta Upsilon 12 3 4
Kappa Alpha 12 3 4
Kappa Alpha Psi 12 3 4
Kappa Sigma 12 3 4
Omega Psi Phi 12 3 4
Phi Beta Sigma 12 3 4
Phi Delta Theta 12 3 4
Phi Epsilon Pi of ZBT 12 3 4
Sigma Phi Epsilon 12 3 4
Sigma Pi 12 3 4
Tau Kappa Epsilon 12 3 4
Theta Chi 12 3 4
Theta Delta Chi 12 3 4
Zeta Psi 12 3 4
Inter-Fraternity Council 12 3 4
Years
Activity Level of Involvement Participat ed
Campus Girl Scouts 1 2 3 4
Catholic Fellowship 1 2 3 4
Cavalier Club 1 2 3 4
Chess Club 1 2 3 4
Chinese Student Assoc. 1 2 3 4
Circle K 1 2 3 4
Corks and Curls 1 2 3 4
Country Dance and Song
Society 1 2 3 4
Creator Magazine 1 2 3 4
Croquet Club 1 2 3 4
Cycling Team 1 2 3 4
Dance Club 1 2 3 4
The Declaration 1 2 3 4
Deliverance Crusade for
Christ 1 2 3 4
German Honor Society 1 2 3 4
Ecology Club 1 2 3 4
Economics Club 1 2 3 4
El Limited 1 2 3 4
Engineering Council 1 2 3 4
English Club 1 2 3 4
Environmental Awareness
Assoc 12 3 4
Environmental Forum and
Research 12 3 4
Episcopal Assoc ./Canterbury
Student Fellowship 12 3 4
Fencing Club 12 3 4
Frisbee Club 12 3 4
Gamma Nu Psi Fraternity 12 3 4
Gay Student Union 12 3 4
German Club 12 3 4
Glee Club 12 3 4
Gymnastic Club 12 3 4
Indian Student Assoc 12 3 4
Intercollegiate Policy
Analysis Council 12 3 4
International Business
Society 12 3 4
International Club 12 3 4
International Relations Club, 12 3 4
Irish Cultural Society 12 3 4
Israel. In^terest Group 12 3 4
. . .
Ye(ars
Activity Level of Involvement Partici pat ed
Italian Club 1 2 3 4
Jazz Ensemble 1 2 3 4
Karate and Self-Defense Club 1 2 3 4
Korean Club 1 2 3 4
Latin American Studies Group 1 2 3 4
Libertarian Student Assoc. 1 2 3 4
Loki Science Magazine 1 2 3 4
Mclntire Marketing Assoc 1 2 3 4
Madison House 1 2 3 4
Marantha Christian
Fellowship 12 3 4
John B. Minor Pre-
Legal Society 1 2 3 4
Modulus 1 2 3 4
Musique 1 2 3 4
NAACP 1 2 3 4
NROTC Honor Guard 1 2 3 4
Navigators 1 2 3 4
Okinawam Kempo Karate Club 1 2 3 4
Omega Rho 1 2 3 4
Opportunity Consultants 1 2 3 4
Othermind Magazine 1 2 3 4
Peer Alcohol Educators 1 2 3 4
Peer Sexuality Educators 1 2 3 4
Polo Club 1 2 3 4
Racquetball Club 1 2 3 4
Republican Club 1 2 3 4
Riding Club 1 2 3 4
Rifle and Pistol Club 1 2 3 4
Right to Life Committee 1 2 3 4
Rowing Assoc 1 2 3 4
Rugby Club, UVA Men's 1 2 3 4
Rugby Club, UVA Women's 1 2 3 4
Running Club 1 2 3 4
Sailing Assoc 1 2 3 4
Skiing, Alpine Assoc. 1 2 3 4
Slavic Society 1 2 3 4
Society for Creative
Anachronism 1 2 3 4
Society of Women Engineers 1 2 3 4
Spanish Club 1 2 3 4
Students for Handgun Control 1 2 3 4
Students' International
Meditation Society 12 3 4
.
Years
Activity Level of Involvement Participat ed
Students Together Against
Racial Separation 1 2 3 4
Symphonic Band 1 2 3 4
Tennis Club 1 2 3 4
United Student for America 1 2 3 4
The University Journal 1 2 3 4
University Singers 1 2 3 4
Volleyball Club 1 2 3 4
Volunteer Income Tax
Assistance Program 1 2 3 4
Volunteers for Youth 1 2 3 4
Washington Literary Society
and Debating Union 1 2 3 4
Water Polo Club 1 2 3 4
Weightlifting Club 1 2 3 4
Women' s Chorus 1 2 3 4
Young Americans for Freedom 1 2 3 4
Young Democrats 1 2 3 4
University-Affiliated Organizations
Years
Activity Level of Involvement p articip at ed
Engineering Council 1 2 3 4
Student Nurses Assoc 1 2 3 4
Assoc, of Education Students 1 2 3 4
Assignment
a. How do you assess the analyst's performance on the job? Explain.
b. Evaluate the procedure the analyst used in meeting the manager of the
computer center.
c. How adequately prepared was the analyst for the first interview?
d. If you were the systems analyst, how would you have handled this project?
Elaborate.
5 / INFORMATION GATHERING 163
Selected References
Athey, Thomas H. "Information Gathering Techniques." Journal of Systems Manage-
ment, January 1980, pp. 11-14.
Boyd, Harper; Ralph Westfall; and Stanley Stasch. Marketing Research: Te^t &
Cases. 5th ed. Homewood, 111.: Richard D. Irwin, 1981.
"Electronics: Data for Fleet Management." Fleetowner 76, no. 6 (June 1981),
pp. 76-78.
Kerlinger, Fred N. Fundamentals of Behavioral Research. 2nd ed. New York: Holt,
Rinehart &. Winston, 1973.
Powers, Michael; Davis Adams; and Harlan D. Mills. Computer Information System
Development: Analysis & Design. Cincinnati: South-Western Publishing, 1984,
pp. 83-119.
Renney, Mark, and Everett C. Hughes. 'Of Sociology and the Interview: Editorial
Preface." American Journal of Sociology, vol. LXII (September 1956), pp. 137-42.
Schwartz, Morris S., and Charlotte G. Schwartz. "Problems in Participant
Observation." American Journal of Sociology, vol. LXIX (1955), pp. 343-53.
Senn, James A. Analysis and Design of Information Systems. New York: McGraw-Hill,
1984, pp. 73-86.
Wetherbe, James C. Systems Analysis and Design: Traditional, Structured, and Ad-
vanced Concepts and Techniques. St. Paul, Minn.: West Publishing, 1984, pp.
-
127-54.
Chapter 6
The Tools of
Structured Analysis
Introduction
What Is Structured Analysis?
The Tools of Structured Analysis
164
At a Glance
Chapter 5 discussed the traditional tools used in data gathering. These tools
have drawbacks. An English narrative description of a system is often too
vague. English is inherently difficult to use where precision is needed. Further-
more, system flowcharting based on the data gathered commit to a physical
Implementation of the candidate system before one has a complete under-
standing of the logical requirements of the system. Finally, system specifications
are often redundant. To find information about one part of the system, one has
to search through the entire document.
Because of these drawbacks, the analyst needs on fimctions rather
to focus
than physical implementation. Therefore, structured tools such as the data flow
diagram, data dictionary, and structured English provide alternative ways of
designing a candidate system. In real-life applications, a combination of the
traditional and structured tools is used.
INTRODUCTION
In the preceding chapters, we
discussed the procedures used in building
computer-based systems and the ixDle of the analyst in the system develop-
ment life cycle. The goal of system development is to deliver systems in line
uath the user's requirements. Analysis is the heart of the process. It is the
key component of the first tv^o phases of the cycle. In phase one, we
focused on problem definition and the initial investigation, where analysis
helps us understand the present system. Phase two, the feasibility study,
goes into detail studying the present system and determining potential
solutions. The outcome is system specifications that initiate system design.
The feasibility study is covered in Chapter 7.
In analyzing the present system, the analyst collects a great deal of
relatively unstructured data through interviews, questionnaires, on-site
observations, procedures manuals, and the like. The traditional appixjach is
to organize and convert the data through system flowcharts, which support
future developments of the system and simplify communication with the
user. But the system flowchart represents a physical rather than a logical
system. It makes it difficult to distinguish between what happens and how it
happens in the system.
There are other problems with the traditional approach:
1. The system life cycle provides very little quality contixjl to ensure
accurate communication from user to analyst. They have no language
in common.
The details are needed and must be available, but the analyst does not
have the tools to structui'e and control the details.
3. Present analytical tools have limitations.
a. English narrative descriptions of a system are often too vague and
make it difficult for the user to grasp how the parts fit together.
Furthermore, English is inherently difficult to use where precision
is needed.
The structured tools focus on the tools listed earlier — essentially the
data flow diagram, data dictionary, structured English, decision trees, and
decision tables. The objective is to bufld a new document, called system
specifications. This document provides the basis for design £ind implemen-
tation. The system development life cycle with structured analysis is shoun
in Figure 6-1. The primary steps are:
Process 2.1: Study affected user areas, resulting in a physical DFD. The
logical equivalent of the present system results in a logical DFD.
Process 2.2: Remove and replace them with a
the physical checkpoints
logical equivalent, resulting in the logical DFD. To illustrate, consider
the two DFDs shown in Figure 6-2. Figure 6-2(a) is a physical DFD. It
shows how the opening of a new safe deposit box flows through the
current department. Figure 6-2(b) is the logical equivalent.
168 PAfiT TWO SYSTEMS ANALYSTS
/
Feasibility
User \ Document
Requirements - Survey
User
Requirements
Cost/Benefit
Summary
Structured
Specification
DFD = data (low diagram
DO = data dictionary
Source: Adapted ftDm Tom De Marco, Structured Analysis and System Specifications (New York: Yourdon Press,
1979), p. 26.
Processes 2.5 and Quantify costs and benefits and select hardware.
2.6:
The structured specification consists of the DFDs that show the major
decomposition of system functions and theii- interfaces, the data dictionary
6 / THE TOOLS OF STRUCTURED ANALYSIS 169
FIGURE 6-2 (a) A Physical DFD, and (b) Its Logical Equivalent.
Master Accounts
Card File Receivable Ledger
Safe
Daily
Deposit
Master
* Activity
Summary
Card
Billing
Notice
Master
Card File
Occupancy
Status Report
Safe Deposit
Master Card
Charges
Specified
documenting all interface flows and data on the DFDs, and docu-
stores
mentation of the intervals of DFDs in a rigorous manner through structured
English, decision trees, and decision tables.
In summary, structured analysis has the following attributes:
2. The college book division receives orders from bookstores for books at a
discount which depends on the size of the order. The clerk in charge
verifies the order and authorizes shipment through the warehouse. An
invoice follows the shipment. Accounts receivable are processed through
the accounting department from forms filled out by an accounting clerk.
3. Business is highly seasonal; it peaks about a month before the begin-
ning of each school term. There is an average of 80 invoices per week, each
with an average of 8 book titles and an average value of $5,000.
4. Recently, management decided to improve the availability of textbooks
by holding stocks of new computer and other high-demand texts and
making it possible for all bookstores to order by calling a toll-free number as
well as by the present mail method. This means that an improved inventory
control system must be devised along with a catalog of texts to verify
authors and titles and determine the availability of the books being ordered.
5. The new system of receiving orders is expected to increase the sales
volume by 80 percent within the year. Although fewer average texts per
order are expected due to the use of the toll-free number, books are now
shipped more quickly than before and delivered in time for the start of the
semester.
1 Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques (En-
glewood Cliffs, N.J.: Prentice-Hall, 1979).
6 / THE TOOLS OF STRUCTURED ANALYSIS 171
DFD Symbols
In the DFD, there are four sx-mbols, as shown in Figure 6-4:
Note that a DFD describes what data flow (logical) rather than how they
are processed, so does not depend on hardware, software, data structure,
it
or file organization. The key question that we are trying to answer is: What
major transformations must occur for input to be correctly transformed
into output?
Our example in Figure 6-3 is too general. Let's expand process orders to
BOOK INFORMATION
FILE
' '
Credit
Orders ^^ N^
Check
"'''^
CUSTOMER
^'^1 Process \jf^ CUSTOMER
1. Order INFORMATION FILE
invoice \..,___,/
(with shipment)
172 PAST TWO SYSTEMS ANALYSTS
/
FIGURE 6-4 Data Flow Diagram: (a) Basic Symbols and (b) General Format
Meaning Comments
n Source or destination
of data
May be one customer or a number
of customers with transactions (orders)
Output
Input (destination)
"• (source)
Processes; A-F
Dataflows: 1-8
elaborate on the logical functions of the system. First, incoming orders are
checked for correct book titles, authors' names, and other information and
then batched with other book orders from the same bookstore to determine
how many copies can be shipped through the warehouse. Also, the credit
status of each bookstore is checked before shipment is authorized. Each
shipment has a shipping notice detailing the kind and number of books
shipped. This is compared to the original order received (by mail or phone)
to ascertain its accuracy. The normally available in a
details of the order are
special file or a data store, called "bookstore orders." Figure 6-5 shows the
expanded version of the system with these details.
6 / THE TOOLS OF STRUCTURED ANALYSIS 173
FIGURE 6-5 Expanded DFD, Showing Order Verification and Credit Check
CUSTOMER INFORMATION
FILE
Following order \'erification and credit check, a clerk batches the order
by assembling all the book titles ordered by the bookstore. The batched
order is sent to the warehouse with authorization to pack and ship the
books to the customer. Figure 6-6 shows the steps taken to finalize the
process.
Further expansion of the DFD focuses on the steps taken in billing the
bookstore. Figure 6-7 shows additional functions I'elated to accounts receiv-
able.As you can tell by now, each process summarizes a lot of information
and can be exploded into several lower-level, detailed DFDs. This is often
necessary to make sure that a complete documentation of the data flow is
available for future reference.
Constructing a DFD
Several rules of thumb are used in drawing DFDs:
traditionally flow from the source upper left comer to the destination
I i
(lower right corneri, although they may flow back to a source. One way to
indicate this is to draw a long flow line back to the source. An alternative
way is to repeat the source symbol as a destination. Since it is used more
than once in the DFD, it is marked with a short diagonal in the lower right
corner (see Figure 6-8).
3. When a process is exploded into lower-level details, they are numbered.
For example, in Figure 6-7, process 5 (assemble customer orderi is exploded
into two subprocesses: create invoice and verify' invoice. Since they are
sublevels, they are numbered 5.1 and 52, respectively.
—
Warehouse
Shipping
nformation
Payment
The main problem, however, is the large number of iterations that often are
required to arrive at the most accurate and complete solution.
Data Diciionaiy
In our data flow diagrams, we give names to data flows, processes, and data
stores. Although the names are descriptive of the data, they do not give
details. So following the DFD, our interest is to bufld some structured place
to keep details of the contents of data flows, processes, and data store. A
data dictionary is a structured repository of data about data.^ It is a set of
r
Same
b.
V
rigorous definitions of all DFD data elements and data structures iSee
Figure 6-9).
A data dictionary' has many advantages. The most ob\ious is documen-
tation; it is a valuable reference in an\' organization. .Another advantage is
data base. Most data base management systems have a data dictionary' as a
standard feature.
Data have been described in different ways. For example, in tape and
disk processing, IBM called a file a dala set. In data base technologv', the
term file took on a different meaning. IBM's Information Management
6 / THE TOOLS OF STRUCTURED ANALYSIS 177
System's (IMS) manual defines data as fields divided into segments, which,
in turn, are combined into data bases. ^ The Conference on Data System
Languages (CODASYL) defines data as data items combined into aggregates,
vviiich, in turn, are combined into records.'* A group of related records is
referred to as a set. A summary of these data definitions is given in Figure
6-10.
3 IMS/VS General Information Manual GH20-1260 (White Plains, NY.: IBM Corporation,
1974).
* National Bureau of Standards Handbook 113, CODASYL Data Description Language Jour-
nal of Development (Washington, D.C.: U.S. Government Printing OflRce, 1974).
178 PART TWO SYSTEMS ANALYSTS
/
1. Data element: The smallest unit of data that provides for no further
decomposition. For example, "date" consists of day, month, and year.
They hang together for all practical purposes.
3. Data flows and data stores:^ As defined earlier, data flows are data
structures in motion, whereas data stores are data structures at rest. A
data store is a location where data structures are temporarily located.
The three levels that make up the hierarchy of data are shown in Figure
6-11.
^ For details on the data dictionary, refer to Gane and Sarson, Structured Systems Analysis,
pp. 48-75.
\
6 / THE TOOLS OF STRUCTURED ANALYSIS 179
Mandatory Optional
flows that feed it or are extracted from it. For example, the data store
BOOKSTORE-ORDER is described by the following contents:
Comments
ORDER
ORDER-NUNJBER Data flow data structure feeding data store
CUSTO.MER-DET.AIl^ Content of data store
BOOK-DEr\IL Data flow data Ancture extracted
from data store
6 /THE TOOLS OF STRUCTURED ANALYSIS 181
Describing Processes
This step is the logical description. We want to specify the inputs and
outputs for the process and summarize the logic of the system. In Figure
6-7, process 1, EDIT-ORDER, can be described as shown in Figui-e 6-12.
In constiTJCting a data dictionary, the analyst should consider the
following points:
1. Each unique data flow in the DFD must have one data dictionary entry.
There is also a data dictionary entry for each data store and process.
2. Definitions must be readily accessible by name.
3. There should be no i^edundancy or unnecessary definitions in the data
definition. It must also be simple to make updates.
2. Short Description: Verify and decide whether customer credit is OK for authorizing
shipment, or whether it must be sent COD.
Bookstores get a trade discount of 25°o for orders from libraries and indixiduals,
;
5% allowed on orders of 6-19 copies per book title; 10% on orders for 20-49
copies per book title; 15% on orders for 50 copies or more per book title.
SMALL: 6 to 19 copies
Type of Size of
customer order Discount
6 or more 25%
Bookstore
less than 6 Nil
Discount
policy
15%
Libraries or
10%
individuals
5%
Nil
6 / THE TOOLS OF STRUCTURED ANALYSIS 183
COMPUTE-DISCOUNT
Add up the number of copies per book title
discount is 15%
ELSE IF order is for 20 to 49 copies per book title
discount is 10%
ELSE IF order is for 6 to 19 copies per book title
discount is 5%
ELSE (order is for less than 6 copies per book order)
SO: no discount is allowed
MEDIUM: 20 to 49 copies
LARGE: 50 or more copies
Using these values, the structured English in Figure 6-14 would read as
shown in Figure 6-15.
From these examples we see that when logic is written out in English
sentences using capitalization and multilevel indentation, it is structured
English. In this tool, the logic of processes of the system is expressed by
using the capitalized key words IF, THEN, ELSE, and SO. Stnjctui^s are
indented to reflect the logical hierarchy. Sentences should also be clear,
concise, and precise in wording and meaning.
Decision Tables
A major drawback of a decision tree is the lack of information in format to its
COMPLTE-DISCOUNT
Add up the number of copies per book title
dixided into an upper quadrant called the condition stub and a lower
quadrant called the action stub. The entr\' part is also divided into an upper
quadrant called the condition entry and a lower quadrant called the action
entry-. The four elements and their definitions are summarized in Figure
6-17.
1 2 3 4 5 6
Customer is bookstore? \ \ N N N N
Order-size 6 copies or more? Y i\ N N N N
IF Customer librarian or individual? \ \ Y \
1
condition 1
Order-size 50 copies or more? Y N N N
Order-size 20-49 copies? Y N N
Order-si7^ 6-19 copies? Y N
Condition stub Upper left quadrant Sets forth in question form the condition
that may exist
Action stub Lower left quadrant Outlines in narrative fomi the action to
be taken to meet each condition
Condition entry Upper right quadrant Provides answers to questions asked in
the condition stub quadrant
Action entry Lower right quadrant Indicates the appropriate action resulting
fixjm the answei-s to the conditions in
the condition entry quadrant
So,according to the decision table, we have six decisions and thei efore
six rules. A look at the table provides each decision (answer) immediately
The following rules should be followed in constructing decision tables:
1. A decision should be given a name, shown in the top left of the table.
1. The primary strength of the DFD is its ability to represent data flows. It
may be used high or low levels of analysis and provides good system
at
documentation. However, the tool only weakly shows input and output
detail." The user often finds it confusing initially.
Ibid., p. 62.
186 PART TWO SYSTEMS ANALYSTS
/
2. The data dictionary helps the analyst simplify the structure for meeting
the data requirements of the system. It may be used at high or low levels
of analysis, but it does not provide functional details, and it is not
acceptable to many nontechnical users.
3. Structured English is best used when the problem requires sequences
of actions udth decisions.
4. Decision trees are used to verify logic and in problems that involve a few
complex decisions resulting in a limited number of actions.
5. Decision trees and decision tables are best suited for dealing with
complex branching routines such «is calculating discounts or sales
commissions or inventory control procedures.
Given the pros and cons of structured tools, the analyst should be
trained in the use of various tools for analysis and design. He/she should
use decision tables and structured English to get to the heart of complex
problems. A decision table is perhaps the most useful tool for communicat-
ing problem details to the user.
The major contribution of structured analysis to the system develop-
ment life cycle is producing a definable and measurable document the —
structured specification. Other benefits include increased user involvement,
improved communication between user and designer, reduction of total
personnel time, and fewer "kinks" during detailed design and implementa-
tion. The only drawback is increased analyst and user time in the process.
Overall the benefits outweigh the drawbacks, w^hich make structured analy-
sis tools viable alternatives in system development.
Summary
1. Traditional tools have limitations. An English narrative description is
often vague and difficult for the user to grasp. System flowcharts focus
more on physical than on
implementation of the candidate
logical
system. Because of these drawbacks, structured tools were introduced
They include data flow diagrams, a data
for analysis. dictionary, struc-
tured English, decision trees, and decision tables.
2. The traditionalapproach to analysis focuses on cost/benefit and feasi-
bility analyses, project management, hardware and software selection,
and personnel considerations. In contrast, structured analysis consid-
ers new goals and structured tools for einalysis. Specifically, it uses
graphics wherever possible, differentiates between logical and physical
systems, and builds a logical system to accentuate system charac-
teristics and interrelationships before implementation.
3. The system development life cycle with structured Jinalysis covers six
steps:
a. Study affected user areas, resulting in a physical DFD.
b. Remove the physical checkpoints and replace them with the logical
equivalent, resulting in the logical DFD.
6 / THE TOOLS OF STRUCTURED ANALYSIS 187
are numbered. The names of data stores, sources, and destinations are
written in capital letters.
is easy to construct, read, and update. It shows only the skeletal aspects
of the picture however, and does not lend itself to calculations. The
alternative is structured English.
9. Structured English uses logical constructs and imperative sentences
designed to carry out instructions for action. Decisions are made
through IF, THEN, ELSE, and SO statements. This tool is highly corre-
lated with the decision tree.
condition rules are written, but the action takes place in the order
in which the events occur.
c. Standardized language must be used consistently.
d. Duplication of terms should be eliminated.
11. In comparing the tools covered in the chapter, we find that:
a. The primary strength of the DFD is its ability to represent data
flows, but it only weakly shows input and output details.
b. The data dictionary simplifies the structure for meeting the data
requirements of the system but does not provide functional details.
c. Structured English is best used when the problem requires using
sequences of actions with decisions.
d. Decision trees are used for logic verifications and in problems
involving few complex decisions.
e. Decision trees and decision tables are best suited for dealing with
complex branching routines.
Key Words
Action Entry Data Structure
Action Stub Decision Table
Aggregate Decision Tree
Alias Entry
Bubble Chart Partitioning
Condition Entry Process
Condition Stub Record
Data Dictionary Segment
Data Element Set
Data Flow Structured Analysis
Data Flow Diagram (DFD) Structured English
Data Item System Flowchart
Data Set System Specification
Data Store
Review Q,uestlons
1. Discuss the pros and cons of the traditional approach to systems
analysis.
2. What is structured analysis? Briefly review the tools used. How does it
b. Aggregates.
c. Segments.
d. Data structure.
11. Illustrate how data elements and processes are described.
12. What points should be considered in constructing a data dictionary? Be
specific.
13. In what way(s) is a decision tree and a data flow diagram related? What
about a decision ti^e and structured English?
14. List and illustrate the primary uses and elements of a decision table.
Application Problems
a. PURCHASE-ORDER = Line-Item
b. Line-Item = Catalog-Number -I- Quantity -I- Description
(-l-Size)(-l-Color) + Unit-Price + Total-Price
190 PART TWO SYSTEMS ANALYSTS
/
For the safe deposit case described in Chapter 4 and 7, the data flow
diagram in Exhibit 6-1 A Customer Data Flow Diagram sets up a new
customer account for a safe deposit box.
Bl »>
SAFE
DEPOSIT
attendant
Get
»>i
Infor-
matior
SIGNATURE
CARD FILE
>I CUSTOMER 1
i /
Assignment
a. Are there flaws in the data flow diagram? If so, what are they? List the
corrections.
c. Using the information from the safe deposit case and the data flow diagram,
draw a data flow diagram to close a customer's account.
Passengers who fly more than 100,000 miles per calendar year and, in addition,
pay cash for tickets or have been flWng the airline regularly for more than five
years are to receive a free round-trip ticket around the world. Passengers who
fly lessthan 100,000 miles per calendar year and have been flying the airline
regularly for more than five years also get a fi^e round-trip ticket around the
world.
6 / THE TOOLS OF STRUCTURED ANALYSIS 191
Assignment
a. Draw a decision tree based on the statement.
b. Develop a decision table for pcissenger free ticket.
Generate
invoice
1 1
Extend
Compute Compute
regular special
line-item
mail delivery
Assignment
a. De\elop a decision tree.
e. When the corrected galley and art are received, the production
department "dummies" the book: that is, the galley is divided into
pages that include space for illustrations, photographs, etc. This
step normally takes three v\'eeks.
Assignment
a. Draw a system flowchart to represent the production process.
Assignment
Prepai-e a decision table to indicate the warehouse from which customers can
be accommodated.
Assignment
Assuming that the master personnel file of company employees will be used,
develop a decision table to illustrate the job.
If a member has been with the association for one year or less, he/she is
entitled to tvvo hamburgers, one bottle of beer, and one ice cream bar.
Those with Uvo years of membership are allowed one hamburger and three
bottles of beer. Those with more thcin three years of membership get one
doubleburger and no limit on drinks.
Assignment
Constnict a decision table to help the one in charge handle the orders.
10 A major brokerage firm wishes to have (1) a list (call it "odd lot") of all
indixiduals who hold odd lots iless than 100 shares of Hammermill Ball i
Bearing stocks, and (21 lists of each of the five tvpes of stockholders who
own 100 or more shares of the same issue, as follows:
Assignment
Present the request in a decision table.
Selected References
Colter, M. A. "Comparatixe Elxamination of S\'stems .Analysis Techniques. ' MIS
Quarterly. March 1984, pp 59-67.
Davis, Wm. S. Systems Analysis and Design: A Structured Approach Reading, Mass.:.
Feasibility Study
Introduction
DESCRIPTION OF OUTPUTS
FeasibUlty Study
CONSIDERATIONS
FEASIBILITY
Economic Feasibility
Technical Feasibility
Behavioral Feasibility
196
.
At a Glance
FEASIBILITY REPORT
ORAL PRESENTATION
198 PART TWO SYSTEMS ANALYSTS
/
INTRODUCTION
Chapter 4 discussed the steps that make up the initial investigation. Several
activities have been completed:
to select the best system that meets performance requirements. This entails
identification, description, and evaluation of candidate systems and selec-
tion of the best system for the job. This chapter, then, addresses the system
performance definition and expounds on the feasibility study as a second
major step in the system development life cycle.
\i
1. Statement of constraints.
2. Identification of specific system objectives.
3. Description of outputs.
This phase builds on the previous phase in that much of the work may
already have been done.
j. Statement of Constraints
Constraints are factors that limit the solution of the problem. Some con-
straints are identified during the initial investigation and are discussed with
the user. There are general constraints that might have a bearing on the
required performance of a candidate system. Let's consider our safe deposit
billing system to illustrate these points. We described the current billing
system and how the department handles billing and customer pa3anents.
The result of the fact-finding phase of the initial investigation revealed the
following general constraints:
1. The president views safe deposit billing as a low priority. He has a false
impression that computers are not needed as long as customers can
have access to their boxes.
"
2. The senior vice president worried that a billing system might require
is
5. Safe deposit, while doing better than breaking even, is not projected to
grow as fast asdid in the early 1980s. The community's recent success
it
date, and one more notice is sent within two weeks. It also improves the
accounts receivables payment 'float.
3. To mail customers a reminder two weeks after the initial statement for
box renewal.
4. To speed collections and reduce the "float" by 40 percent.
5. To examine the avciilability of boxes by size, rental fees, and location.
Description of Outputs
A system performance definition is describing the outputs
final step in
required by the user. An actual sketch of the format and contents of the
reports (layout) as well as a specification of the media used, their frequency,
and the and number of copies required ai^ prepared at this point.
size
Specifying exactly what the output will look like leads to an estimate of the
computer storage requirements that form the basis for the file design to be
undertaken in the design phase of the life cycle. The analyst is now ready to
evaluate the feasibility of candidate systems to produce these outputs.
FEASIBILITY STUDY
Many feasibility studies are disillusioning for both users and analysts.
First, the study often presupposes that when the feasibility document is
ment — the constraints and the assumed attitudes. If the feasibility study is
3. What is recommended?
The most successful system projects are not necessarily the biggest or
most visible in a business but rather those that truly meet user expectations.
More projects fail because of inflated expectations than for any other
reason.^
Feasibility Considerations
Economic Feasibility
Economic analysis is method for evaluating
the most frequently used
the effectiveness of a candidate system. More commonly known as cost/
benefit analysis, the procedure is to determine the benefits and savings that
are expected from a candidate system and compare them with costs. If
benefits outweigh costs, then the decision is made to design and implement
the system. Otherwise, further justification or alterations in the proposed
system will have to be made if it is to have a chance of being approved. This
is an ongoing effort that improves in accuracy at each phase of the system
Technical Feasibility
Technical feasibility centers around the existing computer system
(hardware, software, etc. and to what extent it can support the proposed
I
Behavioral Feasibility
People are inherently resistant to change, and computers have been
known to facilitate change. An estimate should be made of how strong a
reaction the user staff is likely to have toward the development of a comput-
erized system. It is common knowledge that computer installations have
' Lois Zells, "A Practical Approach to a Project Expectation Document," Computerworld (In-
Depth), August 29, 1983, p. 1.
202 PACT TWO SYSTEMS ANALYSTS
/
.
1' •
> Feasibility amalysis involves eight steps:
Regarding the safe deposit case, since the whole user area consists of
five employees, the analyst handled most of the woric.
ments. In the safe deposit case, it Weis found that virtually any microcom-
puter system with more than 128K-byte memory an dual disk drive will do
the job. It was also learned that a microcomputer can be designed to
interface with the bank's mainframe. In this design, actual processing is
Memory required
iK b\-tesi 128 64 264
Source language Pascal Basic Basic compiler
Source code
a\aiJable No \es No
Purchase terms Purchase Purchase Purchase
license) license! licensei
Purchase price S995 S800 SI. 095
Number installed
to date 200 30 50
Date of first
installation 1 82 3 81 1980
user. The package was installed in Januar\ 1982. Moi^ than 200 pack-
first
analyst can plot performance criteria and costs for each system to deter-
mine how each fares. Table 7-3 summarize the outcome of the comparison.
7 / FEASIBILITY STUDY 205
Evaluation
Criteria IBM PC HP 100 Apple III
Performance
System accuracy* Excellent Excellent Excellent
Growth potentialt Very good Good Good
Response time Very good Very good Very good
User-friendly Excellent Very good Very good
Costs
System development Good Veiy good Good
User training Excellent Good Good
System operation Very good Fair Very good
Payback! Very good Good Excellent
Costs are moi^ easily determined when the benefits of the system are
tangibleand measurable. An additional factor to consider is the cost of the
study design and development. As shown in Table 7-4, the cost estimate of
each phase of the safe deposit project was determined for the candidate
system (IBM PC). In many respects, the cost of the study phase is a "sunk
cost" (fixed cost). Including it in the project cost estimate is optional.
Performance
System accuracy 99% (rounded) 97% (rounded) 97% (rounded)
Grovvth potential To 500K bytes To 250K bytes To 250K bytes
Response time
less than five
Charges
(per day) Total
$8,470
criterion by appl3dng a rating figure. Then the candidate system vvdth the
highest total score is selected.
The procedure for weighting candidate systems is simple:
Table 7-5 is a weighted candidate evaluation matrix from the four steps
and the data.
Perfoniiance
System accuracy 3 5 15 5 15 5 IS
Growth potential 4 4 16 3 12 3 12
Response time 2 4 8 4 8 4 8
User-friendly 2 5 10 4 8 4 8
Costs
System development 5 3 IS 4 20 4 15
User training 3 5 15 3 9 3 9
System operation 2 4 8 2 4 4 8
Paybaci^ 3 4 12 3 _9 5 15
99 85 90
Feasibility Report
1. Cover letter formally presents the report and briefly indicates to man-
agement the nature, general findings, and recommendations to be
considered.
2. Table of contents specifies the location of the various parts of the report.
Management quickly refers to the sections that concern them.
3. Overview is a narrative explanation of the purpose and scope of the
project, the reason for undertaking the feasibility study, and the depart-
ment (s) involved or affected by the candidate system. Also included are
the names of the persons who conducted the study, when it began, and
other information that explains the circumstances surrounding the
study.
4. Detailed findings outline the methods used in the present system. The
208 PAET TWO SYSTEMS ANALYSTS
/
properly. When a feasibility team has maintained good rapport with the
user and his/her staff it makes the recommendations easier to approve.
'-»J Technically, the report is only a recommendation, but it is an authoritative
one. Management has the final say. Its approval is required before system
design is initiated. Chapter 9 covers in detail the design phase of the system
life cycle.
Oral Presentation
The good written presentation documenting the ac-
feasibility report is a
tivities involving the candidate system. The pivotal step, however, is selling
tem that can be translated into language understandable to the user, and (2)
the ability to answer questions, clarify issues, maintain credibility, and pick
up on any new ideas or suggestions.
The substance and forni of the pi^sentation depend largely on the
purposes sought. Figure 7-1 suggests a general outline. The presentation
may aim at inforaiing, confirming, or persuading.
1. Infiirming. This simply means communicating the decisions already
reached on system recommendations and the resulting action plans to
those who will participate in the implementation. No detailed findings or
conclusions are included.
^
2. Confirming. A presentation with this purpose verifies facts and recom-
mendations already discussed and agreed upon. Unlike the persuading
7 / FEASIBIUnr STUDY 209
I. Intixxduction.
A. Introduce self.
B. Introduce topic.
C. Briefly describe current system.
1. Explain why it is not soMng the problem.
2. Highlight user dissatisfaction with it.
1. Rehearse and test your ideas before the presentation. Show that you are
in command. Appear relaxed.
or excitement. Also, when the analyst or the project leader has a good
reputation and success record from previous projects, the end user may
request only a brief presentation.
Summary
1. A study is conducted to select the best system that meets
feasibility
performance requirements. This entails an identification description,
an evaluation of candidate systems, and the selection of the best system
for the job.
Key Words
Candidate System
Cost/Benefit Analysis
Feasibility Study
Response Time
Source Code
Source Language
Review GLuesfions
1. What makes up a system peiformance definition? Select a situation with
which you are familiar and explain the steps to prepare the definition.
2. "Many feasibility studies produce disillusions to users and analysts."
Do you agree? Why? Explain.
3. What considerations are involved in feasibility analysis? Which consid-
eration do you think is the most crucial? Why?
Application Problems
Corporation. At the close of 1983, the bank had assets totaling S159
million, capital of more than S19 million, deposits of SI 13 million, and a
loan base of S37 million. Rated the 37th safest bank in the United States,
has a highly successful management team and 119 em-
First National
ployees in a single-stor\' building in the heart of downtown South
Miami.
The bank operates two remote automatic teller machine lATM)
locations and a dri\ e-in facility. The original orientation was toward the
community,', ser\1ng the people in the immediate area. Although still
Board
of
Directors
Audit
President
±
Personnel
Guard
Operators
Maintenance
Safe
Vice President Vice President 2nd Vice President
Deposit Vice President
Accounting Bookkeeping Vice President Platform
Department
Data Collection
The data
collection process began by examining the safe deposit
department's Manual of Instructions and Procedures and sample docu-
ments. To gather more information about the department and investi-
gate some questions rfiised, staff members were interviewed at the
bank. Denise provided most of the data. A tour of the facility offered a
firsthand look at the layout of the vault and lobby area where business is
conducted. A systems flowchart of procedures was drawn up based on
the Manual of Instructions and Procedures and the rules and regula-
tions booklet (Exhibit 7-3). This helped to clarify the information and
indicate where changes might be needed. Any further questions were
readily answered by the supervisor or a member of the board of direc-
tors who is quite familiar with the bank's operations. There was a good
deal of communication between the bank —
and the project team by
phone, in person, and in writing. Management's encouragement and
enthusiasm for the project were extremely helpful throughout the feasi-
bility study.
Following data collection, the department's policies and proce-
dures were analyzed by looking at improvements that had already been
implemented and identifying existing problem areas. The department
has recently instituted several improvements in its operations. For
example, a previous problem involved the absence of security measures
when the keys were sent to the locksmith for changing the lock after a
customer discontinued the box rental. These keys were never recorded
and could be missing, causing a potentially large security problem.
Denise established a new procedure that required the constant
monitoring of the whereabouts of all keys.
Another area in which changes have occurred is record-keeping
and documentation. In the past, vital documents such as birth and
death certificates, court orders, and records on customers and pay-
ments were not always readily available. Denise has organized this
information and filed it so that it can be obtained more easily.
EXHIBIT 7-3A Initica Visit
Customer Attendant
216 PART TWO SYSTEMS ANALYSTS
/
Customer Attendant
Guard and
customer
insert own
keys
Customer
conducts
business in
private
,^\ Customer
returns box
to guard or
attendant
, return box i
7 / FEASIBILITY STUDY 217
' '/
.%
7 / FEASIBILITy STUDY 219
The Problem
Despite these recent procedural changes, problems still exist for
safe deposit that indicate the need for further, more dramatic changes
in the current system. The main problems center around the present
labor-intensive memual record-keeping procedures. All filing and rec-
ord-keeping are done manually by several people. Consequently, docu-
ments are easUy lost or misfiled. The enormous volume of paperwoiit
generates inefficiency cmd disorganization. Because the department has
grown so large and the nature of the manual work is so tedious, the
potential for errors is great. As stated by one employee, "the idea of
future growth under this system is frightening."
Problems uath financial record-keeping also attribute to the manual
system, particularly with accuracy in the present billing method. One
person is solely responsible for pulling contracts due for billing and for
typing up the bills. This, along with manually noting payments on
contracts, leaves room for inaccurate reporting and misfiling. One re-
sult, for example, is that delinquent accounts sometimes go unbilled.
Another area of concern with the present system is incomplete and
inaccurate documentation. This is evident in the difficulty of tracing
misplaced documents. Similar documents are not necessarily filed to-
gether and standard forms cire not prenumbered. These all contribute
to filing problems.
Documentation problems were found to stem from the Manual of
Instructions and Procedures. no description of which files
First, there is
exist, how they are organized, what is kept where, and how often each
file is updated. Second, box prices are somewhat arbitrary. Only one of
EXHIBIT 7-4
I. Lease.
A. Necessary identification information to be obtained.
1. Name.
2. Firm.
3. Address.
4. Phone number.
5. Hair color.
6. Eye color.
7. Height.
8. Weight.
B. Lease agreement (contract) is read and signed by the person(s) opening
the account. A key deposit is made and the deposit amount is recorded
on the lease.
C. If additional persons are to have access to the safe desposit box, a deputy
must be appointed. This appointment is noted on the contract and the
signature of the deputy is needed.
D. Contract filed by box number.
I\ . HistoiA card.
A. Inlbmiation to be recorded:
1. Box number.
2. Personisi renting box.
3. Date rented.
4. .Attendants initials.
remo\ed.
I\'. Customer conducts business with box in pri\ate booth.
\ . Customer returns box to attendant.
\1. Attendant key and customer key are used to unlock door; box is returned and
door locked.
BILUNG PROCEDURE
Safe deposit attendant manually determines for which accounts rental fees
are due.
II. Notices mailed.
A. If fee is charged to customer's checking account, an advice of charge is
created in triplicate.
1.Copies to
a. Customer.
b. Accounting department.
c. Contract file.
2. Credit noted on daily balance sheet.
B. If fee is not charged to customer's account, a rental due notice is mailed
must be verified.
V. If rent still not paid, three monthly warning letters are mailed (SD2, SD3, SD4).
VI. If rent is not renewed within three months after expiration of lease term, the
Notary Public.
A. Contents sealed in package.
B. Notary Public executes certificate reciting.
1. Name of renter.
2. Date of box opening.
3. List of contents.
C. Five copies of certificate of opening.
Included in package holding contents.
1.
a. Automated billing.
b. Box tracking.
c. Online safe deposit maintenance.
d. User-friendly documentation and easy training.
e. Loading the software on the IBM PC.
The Package
There were three limitations concerning the proposed safe deposit
package:
a. There was no provision for a history card file to keep track of the
present and previous customers of each box for reference.
b. The package handles a maximum of 8,000 boxes- on the PC and
32,000 boxes on the XT (hard disk) model.
c. Being less than two years old, the package has flaws such as limited
editing capability and poor documentation.
Hardware/software
Hardware
IBM PC with 64K memory $2,630
Three 64K-byte memory chips 490
Monochrome display and printer adapter board 335
Monochrome display (screen) 345
Epson printer — letter qualitj^ 1,100
$4,900
7 / FEASIBILITy STUDY 225
Software
Direct savings
Assignment
a. Evaluate the undertaken by the project team
feasibility study — its
b. If you were doing the study, would you have considered hardware before
software? VVhv? Elaborate.
Problem Definition
As described in the fii^t part of the case (see Chapter 4), the current
problem in the operations of the Jefferson credit center is inefficient
storage and retrieval. In the present file system, both customer inquiries
and payment slips are stored in physical paper files under date indexes.
Consequently, misfiles and the tertiaiy relevance of the account
number and document type make the search process highly inefficient.
This reduces the credit center's ability to properly respond to customer
inquiries.
ment's needs and (2) recommending the system best suited to the
unique needs and limitations of credit center operations.
In the system feasibility study, the following goals were expected to
be achieved by the candidate system:
d. .AffordabUity.
Comparative Analysis
The next step in this project was and cons of
to evaluate the pros
the two candidate systems. The present system used by Jefferson's
credit center is already obsolete. Both systems considered, the Kodak
Reliant and the CARMS/11 are completely compatible wdth the IBM
3031. In the case of the Kodak system, a small software package is all
that is required to integrate the two systems. On the other hand, the
228 PAfiT TWO SYSTEMS ANALYSTS
/
CARAIS/ll system would require extensive data base and file control
software to control indexing, storage, and retrieval of large amounts of
information.
A second consideration is storage requirements. Jefferson's credit
center receives and microfilms between 12 and 25 batches of 250 checks
per day. It also receives 725 customer inquiries per week. The proposed
' «l system must be capable of storing two years of such data. This amounts
to 2 million to 3 million documents. The CARMS/11 system, with a
storage capacity of 100,000 documents per ultrastrip cassette, would
require 20 to 25 cassettes. On the other hand, the Kodak system would
require 150 cassettes to store two years of documentation.
Related to storage requirements is quick retriexal time. The max-
imum time for accessing a document should be 15 seconds; 25 seconds
if a hard copy is required. This criterion fa\'ors the CARMSll system.
Both systems are comparable. FUming and indexing take fi\e to eight
hours per day.
A used in the evaluation is vendor serxice and sup-
final criterion
port. Kodak's vendor is in Lynchburg home of the credit center),
I
Cost Comparison
Most of Kodak's cost is for hardware. Jeff^erson would ha\'e to
purchase a new microfilmer, two intelligent terminals, some peripheral
accessories, and a fairly inexpensi\'e software package isee E.xhibit 7-5).
On the other hand, the CARMS/ll system's cost is mainly the software
package and its two work stations. Compared to Kodak's software
package, which merely pro\ides the interface between the IMT-150 and
the IBM 3031, the CARMS/11 software package proxides data base man-
agement services, but also redundant operating system services (see
Exhibit 7-6).
Development costs present some interesting features. The
CARMS/11 system requires o\'er twice the processing and dexelopment
costs incurred by the Kodak system. This is best shown by Exhibits 7-7
and 7-8, w^hich represent the processing and development costs for the
next two years' business xolume. The increased cost of CARMS/11 can
be attributed solely to the ultrastrip conversion. The ultrastrip 's benefits
seem to outweigh its rather expensive price tag, however.
7 / FEASffirUTY STUDY 229
Item Cost
Description
Costs
1,500,000 checks/year,
20,000 checks/cartridge,
75 cartridges required/year,
two years' worth = 150 cartridges,
$7.00/cartridge $1,050
600 customer inquiries,
24,000/year,
two cartridges required/year,
two years' worth 148
Total $1,198
Assignment
Evaluate the feasibility study. What were the strong points of the study? The
weak points? What additional information is needed to do a complete study?
Elaborate.
Selected References
Andrews, Wm.
"The Business Systems Proposal." Journal of Systems Manage-
C.
ment, February 1978, pp. 39-41.
Gore, Marvin, and John Stubbe. Elements of Systems Analysis. 3rd ed. Dubuque,
Iowa: Wm. C. Brown, 1983, pp. 240-67.
Neuschel, Richard F. "Presenting and Selling Systems Recommendations." Journal
of Systems Management, March 1982, pp. 5-13.
Powers, Michael; Davis Adams; and Harlan D. Mills. Computer Information System
Development: Analysis & Design. Cincinnati. South-Western Publisbing, 1984,
pp. 120-47.
Zells, Lois A. "A Practiciil Approach to a Project Expectation Document." Computer-
world (In-Depth), August 29, 1983, p. 1.
Chapter 8
Cost/Benefit Analysis
Introduction
Data Analysis
Cost/Benefit Analysis
232
At a Glance
Break-even analysis
Cash- Flow Analysis
Interpret Results of the Analysis and Final Action
>-.*?
234 PAKT TWO / SYSTEMS ANALYSTS
INTRODUCTION
In Chapters 5 and we
discussed various tools analysts use for gathering
6,
details about the system under study. Data gathering is only one part of
systems analysis, however. The next steps are to examine the data, assess
the situation, look at the alternatives, and recommend a candidate system.
The costs and benefits of each alternative guide the selection of one alter-
native over the others. Since this aspect of analysis is so important, it vvdll
take up most of the chapter.
This chapter discusses approaches to developing design recommenda-
tions for theend user. Each approach has costs and benefits that are
compared vvdth those of other approaches before a final recommendation is
made. The outcome is a system proposal (also called a project proposal)
that summarizes the findings of the analysis and states the recommenda-
tions for design. By the end of this chatper, you should be able to evaluate
how current operations are pert"ormed, the categories of costs and benefits,
key methods for cost/benefit analysis, and how a system pix)posal is devel-
oped.
DATA ANALYSIS
Data analysis is a prerequisite to cost/benefit analysis. System investigation
and data gathering lead to an assessment of current findings. Our interest is
in determining how performed,
they con-
efficiently certain steps are how
tribute to achieving the intended goals, and the cost of making improve-
ments. Let us return to our safe deposit scenario (from Chapter 4) to
illustrate the point.
The safe deposit department was authorized to double its capacity from
meet increased demand. Consequently,
4,000 to 8,000 boxes in an effort to
the number of employees changed from three to five, with one employee
assigned full-time to bUling. Analysis of the data collected made it obvdous
that customers were frequently billed too late, too often, or not at all. Access
to customer information or status of vacant boxes was a nightmare. Cus-
tomer lines were long, and service was jeopardized.
The representative facts for the safe deposit department are shown in
Figure 8-1 . The system summarizes the operating characteristics of
profile
the safe deposit system, such as the volume of work, nature of processes,
physical facilities, and personnel. From the analysis, the system design
requirements are identified. These features must be incorporated into a
candidate system to produce the necessary improvements. The system
requirements are:
Objectives (System
Analysis Current System Facts Design Requirements)
How is it done? Some 40 boxes ofjened or closed daily Better billing accuracy
(processing Master card file located too far from Lower processing and ofjerating cost
detail) customer inquiiy station Improved staff eflRciency
Heaviest activity on Fridays and before More consistent billing procedures to
holidays eliminate errors
Too many steps taken with new cus-
tomers
Delay in billing — all manual
Some 80 renewal piayment notices pre-
pared daily
Cash received given to head teller at
end of each day
Poorly designed application forms
Accounting gets daily summaiy
Procedure for customer access to
boxes is neither documented nor
consistent
Who does it? One person handles billing (fiill-time) Better trained personnel
(personnel) One (jerson handles security Elxperience in computer use for other
Three persons process customers into applications
and out of safe deposit area
Except for two persons, rest of staff is
jxxjrly trained
Communication among stciff is
adequate
Where is it done? Location allows privacy and security Allocate quiet sp>ace for computer
(physical Billing carried out close to customer Provide security measure for
location/ counter information access
facility)
minutes
15 jjercent of billing is erroneous in
amount, box number, or amount of
rent
28 percent of vacant boxes cannot be
located on existing books
Frequent notices regarding "to be
renewed" boxes cost $8,000 for
mailing
Employee pwyroU is as hi^ as junior
oflBcers in operations area
236 PART TWO SYSTEMS ANALYSTS
/
COST/BENEFIT ANALYSIS
2. Personnel costs include EDP staff salaries and benefits (health insur-
ance, vacation time, sick pay, etc.)' as well as pay for those involved in
developing the system. Costs incurred during the development of a system
8 / COST/BENEFTT ANALYSIS 237
4. Operating costs include all costs associated with the day-to-day opera-
tion of the system; the amount depends on the number of shifts, the nature
of the applications, and the caliber of the operating staff. There are various
ways of covering operating costs. One approach is to treat operating costs as
overhead. Another approach is to charge each authorized user for the
amount of processing they request irom the system. The amount charged is
based on computer time, staff time, and \olume of the output produced. In
any Ccise, some accounting is necessar)' to detemiine how operating costs
should be handled.
5. Supply costs are variable costs that increase with increased use of
paper, ribbons, disks, cind the like. They should be estimated and included
in the overall cost of the system.
5. Take action.
Tangible Tangible
costs benefits
Intangible
costs
Tangible benefits
minus
tangible costs
considered cost effective. On the other hand, if intangible costs and benefits
are included, the total tangible and intangible costs exceed the benefits,
which makes the project an undesirable inxestment. Furthermore, includ-
ing all costs increases the spread of the distribution (compared with the
tangible-only distribution) with respect to the e\entual outcome of the
project.
' A. R. Oxenfeldt, Cost-Benefit Analysis for Executive Decision Making AMACOM, American
Management Association, 19791, p. 51.
2 C. Warren Axelrod, Computer Productivity (New York: John WUey & Sons, 1982), pp. 61-89.
240 PAKT TWO SYSTEMS ANALYSTS
/
Fixed or Variable Costs and Benefits. Some costs and benefits are
constant, regardless of how well a system is used. Fi^ed costs (after the fact)
are sunk costs. They are constant and do not change. Once encountered,
they not recur. Examples are straight-line depreciation of hardware,
vvdll
Summary of Savings
from an Online Teller System
There are savings, however, that do not directly reduce existing costs.
To illustrate, examine the following case:
A systems analyst designed an online teller system that requires 14 new termi-
nals. No reduction in personnel is immediately planned. Renovation of the bank
lobby and the teller cages will be required. The primary benefits are:
incurred for the new installation. There might be potential savings if addi-
tional transactions help another department reduce its personnel. Simi-
larly, management might set a value (in terms of savings) on the improved
6. Cash-flow^ analysis.
J-' Net Benefit Analysis. Net benefit analysis simply involves subtract-
ing toted costs from total benefits. ,It is easy to ceilculate, easy to interpret,
and easy to present. The main di;awback is that it does not account for the
J.^^k^ time value of money and doe^ not discount future cash flow. Figure 8-4
illustrates theuse of net benefit analysis. Cash flow cmiounts are shown for
three time periods: Period is the present period, foUowed by two succeed-
ing periods. The negative numbers repi^sent cash outlays. A cursory look at
the numbers shows that the net benefit is $550.
The time value of money is extremely important in evaluation pro-
cesses. Let us expleiin what it means. If you were faced with an opportunity
that generates $3,000 a yccir, how much would you be wiUing to invest?
Obviously, you'd like to invest less than the $3,000. To earn the same money
five years fixjm now, the amount of investment would be even less. What is
suggested here is that money has a time value. Today's doUar and tomor-
row's doUar are not the same. The time lag accounts for the time value of
money.
The time value of money is usually expressed in the form of interest on
the fijnds invested to realize the future value. Assuming compounded
interest, the formula is:
F = P(l + i)"
where
F Future value of an investment.
P Present value of the investment.
i Interest rate per compounding period.
n Number of vears.
For example, $3,000 invested in Treasury' notes for three years at 10 percent
interest would have a value at maturity of:
F = $3,000(1 + 0.10)3
= 3,000(1.33)
= $3,993
(1 + ir
1,500
P =
(1 + 0.101-*
1,500
= $1,027.39
1.61
Cumulative
Estiinated Discount Present Present Value
Year Future Value Rate* Valuet of Benefits
•
1/[(1 + l)"]
t P = F/[(l + i)" ]
have $1,500 in four years. This calculation can be represented for each year
where a benefit is expected. For a four-yccir summary, see Figure 8-5.
1,758.51
0.55 percent
3,000
Elxample of Calculation
Elements
(A) Capital investment in a new computer $200,000
(B) Investment credit difference 1100% — 8% investment
credit I 92%
(C) Cost investment (site preparation) $ 25,000
(D) Company's income tax bracket difference
(100% - 46%) 54%
(E) State and local taxes 2%
(F) Life of capital (no salvage value) 5 years
(G) Time to install system 1 year
(HI Benefits (include escalation or inflation) $250,000
Calculation
(1) Benefits before depreciation and taxes (H) $250,000
(2) Less depreciation {S200,000(AI/5[LiSe(F)]} $40,000
(3) Less state and local taxes [$200,000 x 0.02(E)] 4,000 44,000
(4) Benefits before FIT $206,000
Less tax difference ($206,000 x 0.461 94,760
(5) Benefits after FIT $111,240
Formula calculation
197,500
($184,000 + 13,5001 or
151,240
$197,500
= 1.3 years plus installation time (G)
151,240
= 2.3 years to recover investment
Total cost
5,000-
candidate system
4,500-
4,000-
Variable costs
(salaries, supplies, etc.)
Total fixed
cost (hardware)
1.500-
J]
1,000-
/
_L _L ± _L ± J
10 20 30 40 50 60 70 80 90 100 110 120 130
Processing volume (1,000s)
Figure 8-6 is a break-even chart comparing the costs of the current and
candidate systems. The attributes are processing cost and processing vol-
ume. Straight lines are used to show the model's relationships in terms of
the variable, fixed, and total costs of the two processing methods and their
economic benefits. Intersection B' indicates the point where the total cost
of processing 65,000 transactions by the current system is equal to the total
cost of using the candidate system. The shaded area beyond that point is
the return period. The shaded area AB'A' is the investment period. Accord-
ing to the chart, then, it would be more economical to process manually
when volume is below 65,000 transactions during a given time period.
Processing volume above B' favors the candidate system.
O "3 O ^
O Si
OSS
— o O O
r- 1/3 L*^
•<J- w t^ ^^ o
E 5 3
o o u: o o
£e o O 35 r- X
Tf — O rt
ir;
t^
s
M s
— o
o
E en rj ic ^ 35
§ « r5
o
2 ^
u o O l« o o
»
£
^
f
o — —
C 35
-<r
t^
=5 — 33 L-; C.
•*
•*
X 2
^
O 6« 4/5
u
SI
^ o O m O
33 — M
1/3 o o
O
•* — O M
10
n
E 33 L-; 3C
a CD
a. i|
X
^^
K o
i-^
c 15 o o =00 X
5=
o
35
3 L'5
< i«
O O
O
w L"
L'3
33 — * S L'i
>> s * — O OC t X
3 05
-^ U) M
se
a O L- - — 1/3
e o — o
O 33
X t
S L*^
c o * X X X ;0 in
3 00 S T 33
'-> ^
«» f/i
o 1/3 in o
X
§•
o
o o 33 5 S
t — a -X
s
3:
iH
X U5
^ M X M
5
««
— o m o L«
s O
o
L'5 SOS in
= T — S
O 3; X 33 X X
-f
tC s r^
a
o
o o
<*
in
t^
— In
— M X t^
£)
c
<
o o
o o in o o o
CS
3 S O T — o
o 33 — o
t^
35
35
33 tC — ri
•r, =^
C!
^ o
o
o s in s s o
o in
o O ^ — — X o
o M — 35 35
rg
X3
e
IS
c
u 35 s CS
0!
a
a;
•? g u X
c :i ic
3 ? t;
I
00
c I
c 5 =
M r ^ w
X-
s; = — ~ 3 _7: S 3 J2
i 5. •= •- ^ - -r^ ~ " —
> -
> p 5 « ^
<
248 PAST TWO SYSTEMS ANALYSTS
'
o 6 £ o E
_3 a ^ c
o 3 CO ™ 2
E "o 2 m 01 c^ .2 «
go
£ £ ^ a;
3
«
01
V «
eo^
o
ciS
00
CS E c >
QJ
s:
*—
O O « 2 c " cljc
r
u
O 5
t3
V c E o
s c
Q.
0)
E .§1 o =
a
o p
%
<£
V '8 a O)
> a > a a £ S il 8 a
c ^^ o CO CO ">
3 c c e8 CO c 01 a « —
a)
o ^ "5o u
O o Q) 5 >
c o u -S
—c Zo
u £ o E £ O E o E —^
u E o
in CO
•s o o aj CO Q_
•o 2 £ 0)
CO
>
o
c 3
3
C8 1
c CO
o 0)
3
C CO
o CO
C & -o
01 S 03
o .a
« 0)
c - >
*^ 2 13 a?
c si en
0) C
C CO o
CO
« > on CO
c C s i « O CO
O E o E o o a g E c n <0 E C .S C P CO
Q fS u < Q 6C
u u
0)
O C
c c c
O CO o
•2 ""
«> i
E E O 01
B 01
E 00
E 8
2"o B-
01 0) £
00 CO c ^ 3 Si
« 3 3 c mO
-a
o 5 13
> CO
l-g 2 i -o C CO "O
^ 0} CO c
03
» C > ^ E 2 E 0)C CQ
lUCO o! -h
o - ^'^
I3 £m £•'- C [. 3 5
<ii
o
^ u
£
V
c o)
=
o « s — O Xi
"3
n ^
to CO
01 •£
-i
^ c2 c
o -
CO
a >1 CO
isr
0)
CO 3
= u 0)
c
o o o o S 1 o t:
CO
'3
X! >,
2> >^ >>
^ 3 « 8 C CO
5 09 CO CO i^ CO
u c °"
cd cQ ^ C8 O" CO CO i
< [d ID U (d U OS < U X u u
T3
O
*^ -O
O C
CO
oc c •a
o
6 C 3 C CO
c
O ? c^ c
6 E u
S o o a
CO OS
en O £
u c
<: i 3 CO 0) a o
»
o C CO
M ^•° CO C
« 0)
•d 3 T3 C a
o C
0)
0> CO O 0)
eS 2
xi
o
c
0) Is
S CO
CO CO
^
T3P s
+ £ + T3 ^ U «i U 0)
£§
(0 01 CO <n CO
c = 2 £ £
o3 c CO V.
o J3
j:;
3 CO CO -5
aa 9}
a c i -^
B u
o o
8 o
(O U
C CO C 10
o " 0)
a, fe, fe. u u
D
>
M o
3
o 1
I
oo
3
c CC 73 e c
o
M o (D > OB
18 O
C
(U
^
*mt
c £
a
u
CO
i aI
I
0)
IS XI a
5 ® « o
nE
£ CS
Z a: 2 0. u
250 PAKT TWO SYSTEMS ANALYSTS
/
II. TABLE OF CONTENTS List various parts, features, and exhibits, showing
page numbers
III. SCOPE Present a brief explanation of the system boundaries
IV. STATEMENT OF PROBLEM Describe current system
Describe proposed system
Indicate how proposed system will solve the
problem(s)
IX. CREDITS Give credit to those who contributed to the project study
X. APPENDIX Include exhibits, correspondence on project, and other
miscellaneous documentation
Summary
1. Data analysis is a prerequisite to cost/benefit analysis. Fi-om the analy-
sis, system design i-equirements ai'e identified and alternative systems
back is not accounting for the time value of money and not
discounting future cash flows.
b. Present value analysis: Calculates the costs and benefits of the
system in terms of today's value of the investment and then com-
pares.
c. Net present value: Discounted benefits minus discounted costs. It is
relatively easy to calculate and accounts for the time value of
money.
d. Payback analysis: A common measure of the relative time value of a
project. It determines the time it takes for the accumulated benefits
to equal the initial investment. It is easy to calculate and allows the
ranking of two or more activities.
e. Break-even analysis: The point at which the cost of the candidate
system and that of the current one are equal.
/ Cash-flow analysis: Keeps track of accumulated costs and revenues
on a regular basis.
Once the complete, actual results are com-
evaluation of the project is
Key Words
Break-even Analysis Net Pay Value
Cash-Flow Analysis Opportunity Cost
Cost/Benefit Analysis Payback Analysis
Direct Cost Present Value
Fixed Cost Return Period
Future Value Savings
Indirect Cost Sunk Cost
Intangible Cost Tangible Cost
Investment Period Variable Cost
Net Benefit Analysis
Review GLuestions
1. What cost elements are considered in cost/benefit analysis? Which
element do you think is the most difficult to estimate? Why?
2. Define and explain the procedure for cost/benefit determination.
3. How easy is it to identify the costs and benefits of a system? Give
examples of costs that are not easily identifiable.
7. How do net present value and present value analyses differ? Illustrate.
8. What are the pros and cons of the foUoudng evaluation methods?
a. Payback method.
b. Cash-flow analysis.
c. Break-even analysis.
9. If the evaluation methods used in cost/benefit analysis are seemingly
quantitative, why are the interpretive phase and the subsequent deci-
sion phase subjective? Explain.
10. Briefly describe the essential elements of a project study report.
)
Application Problems
b. The expected useful life is five years, and the salvage value is
540,000.
d. Cost of capital to the user is 10 percent, and the effective tax rate is
40 percent.
Assignment
Determine the net present \'alue applied to the purchase/lease options. Keep in
mind the following:
d. Proceeds from the s£ile of the old system are reduced by the tax on the gain
from the sale.
e. Tax benefits that result from the deductibility of the service contract, the
lease pavments, and depreciation are taken into account in the analysis.
The effect is a reduction in the cash outflows related to the expenditures.
Proposed Present
System System
Assignment
a. Did the analyst project the correct salary costs for both systems? Explain.
b. Did the analyst provide the vice president with all the costs for the new
system? Did he collect all the aosts relating to the present system?
c. Given the operations costs, can the vice president cost-justify the proposed
system? Explain.
ft
8 / COST/BENEFIT ANALYSIS 255
PROPOSED SYSlTiM
Operating costs
Total $10,831
PRESENT SYSTEM
Operating costs
Overhead
Maintenance $ 5,824
Insurance 675
Utilities 1,008
Total 7,507
Assignment
a. One problem that was pointed out was computing employee wages. What
seems to be inaccurate about the salary section in both system? How would
you correct the problem?
b. With respect to the types of costs incurred in operating either system, did
the analyst include all relevant costs? Show where additional costs should
be included. What other expenses should the report emphasize (if any)?
Selected References
Axelrod, C. Warren. Computer Productivity. New York: John Wiley & Sons, 1982,
pp. 61-89.
Davis, Wm. Systems Analysis and Design: A Structured Approach. Reading, Mass.:
Addison-Wesley Publishing, 1983, pp. 313-24.
Oxenfeldt, A. R. Cost-Benefit Analysis for E^cecutive Decision Making. AMACOM,
American Management Association, New York 1979.
Powers, Michael; Davis Adams; and Harlan D. Mills. Computer Information System
Development: Analysis & Design. Cincinnati: South-Western Publishing, 1984,
pp. 184-213.
Part Three
Systems Design
I. '.'"•a )-•:
-'
9 THE PROCESS AND STAGES OF SYSTEMS DESIGN
1 INPUT/OUTPUT AND FORMS DESIGN
1 1 FILE ORGANIZATION AND DATA BASE DESIGN
259
Chapter 9
Introduction
Design Methodologies
STRUCTURED DESIGN
Functional Decomposition
STRUCTURED WALKTHROUGH
User Involvement
PERSONNEL ALLOCATION
260
.
At a Glance
Audit Considerations
INTRODUCTION
The discussion so far bringsus to a pivotal point in the system development
life cycle. User requirements have been identified. Information has been
gathered to verify the problem and evaluate the existing system. A feasibility
study has been conducted to review alternative solutions and provide cost/
benefit justification. The culmination of the study is a proposal summariz-
ing the findings and recommending a candidate system for the user.
If the figures and the reasoning behind the candidate system make
user's requirements. When analysts prepare the logical system design, they
specify the user needs at a level of detail that virtually determines the
information flow into and out of the system and the required data re-
sources. The design covers the following:
1. Reviews the current physical system — its data flows, file content, vol-
umes, ft^quencies, etc.
2. Prepares output specifications— that is, determines the format, content,
and ft-equency of imports, including teiminal specifications and loca-
tions.
9 / THE PROCESS AND STAGES OF SYSTEMS DESIGN 263
3. —
Prepares input specifications format, content, and most of the input
functions. This includes determining the flow of the document from the
input data source to the actual input location.
4. F*repares edit, security, and control specifications. This includes spec-
ifying the rules for edit correction, backup pixacedures, and the controls
that ensure processing and file integrity.
FIGURE 9-1 Systems Design Goes through Logical and Physical Design
Master
Donnant
264 PART THREE / SYSTEMS DESIGN
from the user, performs the necessciry calculations through the existing file
or data base, produces the report on a hard copy or displays it on a screen,
and maintains an updated data base at all times. Specifically, physical
system design consists of the following steps:
The physical design for our safe deposit illustration is a software pack-
age written in Pascal (a programming language). It consists of program steps
that accept new box rental infonnation; change the number of boxes avail-
able udth every new box rental; print a report by box type, box size, and box
location; and store the information in the data base for reference. The
analyst instructs the software programmer to have the package display a
menu that specifies for the user how to enter a new box rental, produce a
report, or display various information on the screen. These and other
procedure specifications are tested and implemented as a working model of
the candidate system.
DESIGN METHODOLOGIES
During the past decade, there has been a growing move to transform the
"art" of systems analysis and design into an "engineering-type" discipline.
The feeling that there has to be a more clearly defined logical method for
developing a system that meets user requirements has led to new tech-
niques and methodologies that fundamentally attempt to do the following:
FIGURE 9-2 Data Flow Diagrram — Sale Deposit Cxistomer Master File
Update Procedxare
Box Status/Customer
Update
New
Box Record
Box Status/
Customer Master
Record New Box
Status/Customer
Record
Structured Design
Structured design is The approach begins
a data-flow-based methodology.
with a system specification that identifies inputs and outputs and describes
the functional aspects of the system. The system specifications, then are
used as a basis for the graphic representation — data flow diagram(DFD) — of
the data flows and processes and 9-3). From the DFD, the
(see Figures 9-2
next step is the definition of the modules and their relationships to one
another in a form called a structure chart, using a data dictionary and other
structured tools.
Structured design partitions a program into small, independent mod-
ules.The are arranged in a hierarchy that approximates a model of the
business area and is organized in a top-down manner with the details
shown at the bottom. Thus, structured design is an attempt to minimize
structured English
decision tree,
decision table,
^^^^^^^s
System Data Process
specifications
DFD dictionary '
informa
^^W ^^
^B J ^^B ^^^^^^^§
^^^^^^
266 PAET THREE / SYSTEMS DESIGN
Top level
Second level
Functional Decomposition
The documentation tool for structured design is the hierarchy or struc-
ture chart. It is a graphic tool for representing hierarchy, and it has three
elements: ^
——
HGURE 9-5
A Module
B
J ^^ .^v
k
data items mo\ed from one module to another. In Figure 9-7, O, P, and
Q are couples. Module A calls B, passing O downward. Likewise, mod-
ule A calls C, passing P dov\Tiward and receiving Q back. More on
coupling is described next.
lU
liJ^
u-O
<l-
w w,.,
<!-"-
p'^
^05
/
/
% LU
Q
°-B IT ^
^ y^lA
1 m ^
f 1'°^ CD
D O / >^^ z
CD
•D
CD / ujQ
5
> S /i ^&
V/ y ZjW >
LL
oc
LU /^y/
/ j^y^ H
C
o
^ /
/
A tr
LU
>
Aj^i CO
li-O
<H X -o 2 P/
WW,,,
^1- V H
CD
'*-
CO
'^ 1
/ z
0) ID
Q
.
\ Xv,
VT) 2
1- CO
o
a \ ^V"'^ t-
D
M \ ^ LU2 Pi
LJ ^
to-
°Eco
< Valid
Maste
File
QC \ CO c o
1-
I
H-
Y^s Q
LU
D
u
sw
<D »A\d \\
\\
ll^\\
1« rou.
r\
U\ 2
O c \\
2
CO
" \ LU LU o
DSA ERFI
li
00 \ >
SIT
H
2 Q2lu
<<Q-
TVALI DEPO STOMi
iua:<
M QCI-H
uj D
O O
9 / THE PROCESS AND STAGES OF SYSTEMS DESIGN 269
UPDATE SAFE
DEPOSIT CUSTOMER
FILE
* Tom Demarco, Structured Analysis and Design (New York: Yourdon Publishing, 1979), p.
307.
2 See Cyril P. Brosh, Philip J. Grouse, D. Ross Jeflfeiy, £ind Michael J. Lawence, Information
System Design lEnglewood Cliffs, NJ.: Prentice-Hall, 1982), pp. 168-174.
270 PART THREE / SYSTEMS DESIGN
Compute
Pay 10
Compute and
Sum Hours Determine Pay Record Gross Compute Write Check
Worked 21 Rate 2 2 Pay 23 Deductions 3 1 For Net Pay 32
ICDNA
Data
movement
Control flow
Keyed data
arrows
LEGEND
1 I
simple:
1. Begin at the highest level of abstraction and define the inputs to the
system and the ouputs fiDm it in aggregate terms.
2. Identi^' the processing steps by those that convert input into output.
3. Document each element using HIPO diagram notation and the associ-
ated treelike structure.
FIGTOE 9-11 An HIPO Diagram Derived from the Hierarchy Diagram (Figure
9-10)
* us A
p....t«
ta|M
Pavrc;
job recoru
u 1 . Sur: hours worked
-•e 55 J tcr S
1
Extended Dacnpnon Extended Docnption
Payroll job
e 1 . Verify employee nuiaber
before reading the record
Error laessages
record ^^-»,,. 2.2.1
(PJR) /^ \
:> 2. Verify type of work
2.2.2
>
RATETAB^
^ Display special
conditions before
3. Load file and lookup pay
update
C> rate 2.2.3
PJR(updated)
5. Update P.IR with rate
There are two aids available for drawing HIPO diagrams: the HIPO work
sheet, GX20-1970 (see Figure 9-12), and the HIPO template, GX20-1971,
which contains symbols for HIPO diagrams (see Figure 9-13). The template
.
OTHER SYMBOLS 1
I 1 1 M 1 1 1 1 M 1
1 1 1 1 1 1 1 1 1 1 1
1
1 1 1 1 1 1
Ij
IMCMf J - .-.'l*i ^
^^
> < ARROWHEADS ^xw" d»r«tiort o» 1
5^M
'II
LJ 1
1
1
V^l
r^ m\
1
^^J -i
T
^
h
k
^
A 111
1
' L
1 ~
s. _
CONNECTORS
-lC-^~
-
*
-j'-t-
'
-i--
->- - ——
.._</)..
S
O
o -
i
'
X . -
—r
-
'^
_
Z
O
It
-
It
-
-
o
S,
DATA ARROWS
5
=> DATA MOVEMENT ARROWS T>tt data item or 9«ot<>i ol data .
-j-f
z
Items Mrili be moved or mampuUicd by the assoctated procen
> ticplfi or
itcpltJ
wet p'oducad c mad<<icd t>v (he atsooaied process
J
—
i'"
°
1* X '
' ;
"i
..J 1
-"X
1
-• -
3
it
-i--i- ^ ^ X X it
X 1
1
I
1
!
E ait Irom a diagram («ny on* o* the low n 1 :i::|: ^ix.s. i.^
accepiabiei
X I^
"^ I
1
1
Alternate path 1 1
1 1 "5
III t *
1 II 1 1 II M 1
=
1
•ii»«!i«»)
1 1 1
3igi3w
1 1 II 1 1 1
l<,»»i rtt li
jacket describes the symbols. The HIPO package format consists of the
following:
1. Visual table of contents shows the structure of the diagram and the
relationships of the functions in a hierarchical manner. It also has a
legend to show how the symbols are to be used.
:^^' m.
designers can document their thoughts concurrently with the design pro-
cess. Thus, the preparation of HIPO diagrams is a by-product of the thought
process of the design rather than an additionsd chore.
Structured Walkthrough
An activity of all phases of a structured project is the walkthrough. It is an
interchange of ideas among peers who
review a product presented by its
author(s) £ind agree on the validity of a proposed solution to a problem. In a
design walkthrough, the purpose is to anticipate as many problems in the
design as possible while they are stUl "paper tigers." It is cheaper to make
changes now than later during conversion. This is a practical implementa-
tion of "A stitch in time saves nine." The objective is to come up wdth a
maintainable design that is flexible and adaptable and meets the organiza-
tions's standards.
User Involvement
Walkthixjughs may be held system development
at various points in the
life cycle. In addition to system design, they may be held to review the
system test plan, program design, and production acceptance. In each case,
the people who will be i-unning the system should be consulted.
The probability of success improves with the user's interest and involve-
ment in the design of the system. The user can save a system that might
otherwise be of marginal benefit, and likewise he/she can kill a superbly
designed system if it is perceived as making only a small contribution to job
performance. Thus, promoting a user's contribution in the walkthixjugh
and throughout the design phase c*i be crucial for successful implementa-
tion.
9 / THE PROCESS AND STAGES OF SYSTEMS DESIGN 275
1. Data base design. This activity deals with the design of the physical
data base. A key is to determine how the access paths are to be imple-
mented. A physical path is derived from a logical path. It may be imple-
mented by pointers, chains, or other mechanisms, as we discuss in Chapter
11.
AllocatKXi of Program 6 7
functions design
3 4 5
a
Personnel Allocailon
In the past, a medium was handled by a team of program-
or large project
mers uith the goal of speeding up implementation. Unfortunately, there
was more emphasis on numbers than on talent. The structured approach to
design and implementation is useful in facilitating the planning process.
Emphasis is on allocating the right programmers to the task within a
realistic timetable.
A completed structure chart gives the designer a realistic outline of
the programming work to be done. Programmers can be assigned to meet
the workload rather than the other wav around. A team of programmers is
AUDIT CONSIDERATIONS
A well-designed system should have controls to ensure proper operation
and routine auditing. A candidate system's failure often results fixjm a lack
of emphasis on data control. Therefore, standards of accuracy, consis-
tency, and maintainability must be specified to eliminate errors and con-
trol for fraud.
A system design introduces new control elements and changes the
control procedures. New controls in the form of relational comparisons
are designed to detect and check errors that arise from the use of the
system. In a manual system, internal control depends on human judg-
ment, personal care, eind division of labor. In a computer-based system,
the number of persons involved is considerably reduced. A software pack-
age is an effective substitute for human judgment in processing routines
and error checks.
278 PAKT THREE / SYSTEMS DESIGN
In designing a new
system, the designer should specify the location of
error-control points and evaluate them on the basis of error frequency, cost,
and timing By identifying points where potential errors
of error detection.
may occur, designers can create error-control procedures for handling
errors immediately at a reasonable cost.
records are rejected, the batch may be held untU the errors are corrected.
In addition to batch controls, severed other programmed checks can be
used for testing the data:
1. Completeness check ensures that all fields in a record are present and
are read in the proper sequence. In a multiple-record check, the pro-
gram verifies the self-checking number of the record(s) that make up the
transaction. If an error is detected, the entire group of records is
rejected.
includes journals, ledgers, and other documents that the auditor uses to
trace transactions through the system. In a computerized system, record
content and fonnat frequently make it difficult to trace a transaction com-
pletely. Some reasons are the following:
9 / THE PROCESS AND STAGES OF SYSTEMS DESIGN 279
1. Records stored on a magnetic medium itape, disk, etc.) can be read only
by a computer and uith the use of a computer program.
2. Data processing acti\ities are difficult to observe, since they take place
within the computer system.
3. The record sequence is difficult to check without the assistance ol'a
computer system.
4. Direct data entry eliminates the physical documentation for an audit
program.
Summary
1. System design is a transition ftxim a user-oriented document to a
document oriented to programmers or data base personnel. It goes
through logical and physical design with emphasis on the following:
a. Preparing input/output specifications.
b. Preparing securit\' and control specffications.
c. Specifying the implementation plan.
d. Preparing a logical design walkthrough before implementation.
2. Structured design is a data-flow-based methodology' that identifies in-
puts and outputs and describes the functional aspects of the system. It
partitions a program into a hierarchy of modules organized in a top-
down manner with the details at the bottom.
—
with the HIPO chart. It consists of the hierarchy chart plus the input/
process/output (IPO) chart, thus capturing the essence of top-down
decomposition. The aids are the HIPO work sheet and template.
5. A useful phases of a structured project is the walkthrough,
acti\it\' in all
Key Words
Audit Trail Physical Design
Cohesion Structure Chart
Couple Structured Walkthrough
Decomposition System Design
HIPO Top-down Design
IPO Chart
Review €luestions
1. In your own words, describe the process of system design.
2. Distinguish between the following:
a. Logicaland physical design.
b. HIPO and IPO.
c. Coupling and cohesion.
3. What design methodologies are used in system design? Be specific.
10. Ejcplain thecomponents of the HIPO package format. How would one
generate a HIPO chart?
11. How is a structured walkthrough conducted? What is the role of the
user in this activity? Elaborate.
12. What development activities are carried out during structured analysis?
Discuss.
13. How are personnel allocated in system design? Illustrate.
14. What audit considerations are included in system design? Why are they
important?
Application Problems
.Gross- Earnings
Marital - Status
State-
Income- Tax
Tax -Schedule
COMPUTE
STATE
INCOME
TAX
Number
of -[Dependents Gross -Earnings
COMPUTE SELECT
DEDUCTIONS TAX
SCHEDULE
282 PAET THE£E SYSTEMS DESIGN
Assignment
a. How man\ modules connections, and couples are there in the chart? What
do the\ mean?
b. Which module is the calling module? The called module?
c. How man\ couples are passed to the calling module?
d. Whatis the minimum number of call statements inside COMPLTE STATE
INCOME TAX^
e. What is the output of SELECT TAX SCHEDLT£?
Use the data flow diagrams in E.xhibit 9-1 to deri\e a structure chart.
Start with the calling module RANDLE CASH WITHDRAWAL INQUIRY.
Selecled References
Brosh, C\Til PhUip J. Grouse, J. Ross Jeffer\-, and Michael J. Lawrence. Informa-
P.,
tion System Design. Engle\sood Cliffs. .\.J.: Prentice-Hall 1982, pp. 168-74.
Brjce, Milt. Information System Design Methodologies." Computenvorld, Novem-
ber 7, 1983, p. olflf.
Demarco, Tom. Structured .Analysis and Design. New York: Yourdon. 1979. p. 307.
Dimino, Stephen .A. Corporate Politics and the S\stem s Process." Journal of Sys-
tems .Management, September 1983 pp. 6-9.
9 / THE PROCESS AND STAGES OF SYSTEMS DESIGN 283
Customer
Cash
Withdrawal
Request
TELLER
Hershauer, James C. "What's Wrong with Systems Design Methods? It's Our As-
sumption!" Journal of Systems Management, April 1978, pp. 25-28.
Lapointe, Joel R. "Userware: The Merging of System Design and Human Needs."
Data Management, February 1982, pp. 29-33.
Patrick, Rober L. "A Checklist for System Design." Datamation, Januaiy 1980,
pp. 147-48ff.
Peters, Lawrence,and Leonard Tripp. "Comparing Software Design Methodologies."
Datamation, November 1977, pp. 89-94.
Sadek, Konrad E., and Edward Tomeski. "Different Approaches to Information
Systems." Journal of Systems Management, April 1981, pp. 17-27.
Sides, S. R. "Walkthroughs and Reviews." Computerworld (In Depth), August 10, 1981,
p. 15ff.
Tsichritzis, Dionysios. "The Architects of System Design. Datamation, September
"
Input/Output
and Forms Design
Introduction
Input Design
INPUT DATA
Source Documents
Output Design
Forms Design
WHAT IS A FORM?
CLASSmCATION OF FORMS
284
.
At a Glance
The first step in systems design is to design output and input within predefined
guidelines. In input design, user-originated inputs are converted to a com-
puter-based format. It also includes determining the record media, method of
input, speed of capture, and
entry into the system. Online data entry accepts
commands and data through a keyboard. The data (input or output) are
displayed on a cathode-ray tube (CRT) screen for verification. The major
approaches to input design are the menu, the formatted, and the prompt
design. In each altemative, the user's options are predefined.
In output design, the emphasis is on producing a hard copy of the informa-
tion requested or displaying the output on a CRT screen in a predefined
format. Form design elaborates on the way output is presented and the layouts
available for capturing information.
FORMS CONTROL
286 PART THREE / SYSTEMS DESIGN
INTRODUCTION
In Chapter 9, we defined systems design as the process of developing
specifications for a candidate system that meet the criteria established in
systems analysis. A major step in design is the preparation of input and the
design of output reports in a form acceptable to the user. This chapter
reviews input and output design and the basics of forms design. As we shall
see, these steps are necessary for successful implementation.
INPUT DESIGN
Inaccurate input data are the most common cause of errors in data process-
ing. Errors entered by data entry operators can be controlled by input
design. Input design is the process of converting user-originated inputs to a
Input Data
The goal of designing input data is to make data entry as easy, logical, and
ft^e from errors as possible. In entering data, operators need to know the
follouang:
Source Documents
Source data are captured initially on original paper or a source docu-
ment. For example, a check written against an account is a source doc-
ument. When it reaches the bank, it is encoded with special magnetic ink
character recognition (MICR) so that it can be processed by a reader that is
part of the information system of the bank. Therefore, source documents
initiate a processing cycle as soon as they are entered into the system.
Source documents may be entered into the system from punch cards,
ftxjm diskettes, or even directly through the keyboard. A source document
may or may not be retained in the candidate system. Thus, each source
document may be evaluated in terms of (1) its continued use in the candi-
10 / INPDT/OUTPOT AND FORMS DESIGN 287
date system, (2) the extent of modification for the candidate system, and (3)
1. 19 September 1935
2. Sept. 19, 1935
3. 9/19/35
more efficient to direct the person to check the appropriate box than to
enter a character. Figure 10-1 illustrates this point.
3. MICR translates the special fonts printed in magnetic ink on checks into
direct computer input.
Recommended Inefficient
n Small
Q Medium
D Lai^e
DX large
288 PART THEEE / SYSTEMS DESIGN
Modern
Store
742
DEPT
934286
SKU
MED
SIZE
$5«69
fixjm a list of options and types the option letter associated with it. For
example, Figure 10-4 shows a menu for entering, adding, or deleting box
types in our safe deposit billing system. A curser blinking in the space
reserved for YOUR CHOICE requests the user to type the letter that
( )
represents the option wanted. Other menus require the user to position the
curser in front of a menu choice to make a selection.
A menu limits a user's choice of responses but reduces the chances for
error in data entry.
next line, and so on until the form is completed. During this routine, the
user may move the curser up, down, right, or left to various locations for
making changes in the response. Figure 10-5 is a safe deposit customer set-
up form. The system requests information about the customer's name,
address, renewal date, and so on. The user fills out the information on the
dotted lines.
( ) vour choice
/'
OftiCB 1
Box t
(5) Address 1
2
3 .**—*.»..*«
Most systems edit the data entered by the user. For excimple, if the
password exceeds a maximum number of digits or if the passw^ord is illegal,
the system responds with a message like UNAUTHORIZED ENTRY or IL-
LEGAL NUMBER. The user has three chances to enter the correct code, after
which the system "locks up." In banks' automated teller machines (ATMs), if
the customer entered his/her code wrong three times, the system retains
zaz PACT THEEE / SYSTEMS DESIGK
the card and displays a message on the screen that the user should check
with an oflRcer during banking hours.
The prompt method also allows the user to ke\' questions that deter-
mine the next response of the system. In our e.xample LNPLT D.AT.A \0\\7
Y/N, if the response is Y, the system might displa\' a record format for
entering data. Otherv\ise, might automatically go back to the menu for a
it
different set of options. This method along with the menu and template is
designed to improve the efiicienc\' and accuracy' of online data entry.
In each of the alternative approaches to data entrv. the users options
are predefined. ,\n ine.xperienced user is guided through complex functions
by a formatted procedure. The main limitation with many of the axailable
menus or prompts is that the\' require onl\' one item to be entered at a time
rather than a string of data items simultaneously.
Columns
I 2 3 4 S i I I I II
•
( 1 ) LI OUGR UNDER *4 OO .
R
(2) LIQUOR BETWEEN *4.00 AND *10.0O
o (3) LIQUOR BETWEEN *10.01 AND *12.00
w (4) LIQUOR OVER 12. <X)
s
WAITING
Row Column
Screen Design Aid (SDA) package that allows the designer (at the terminal)
to modify the display components (see Figure 10-7).
OUTPUT DESIGN
Computer output is the most important and direct source of information to
the user. Efficient, intelligible output design should improve the system's
relationships with the user and help in decision making. A major form of
output is a hard copy from the printer. Printouts should be designed
.'y-,v>
around the output requirements of the user. The output devices to consider
depend on factors such as compatibility of the device vvdth the system,
response time requirements, expected print quality, and number of copies
needed. The following media devices are avciilable for providing computer-
based output:
1. MICR readers.
. . 1 .
1
. . . 1
. 1 ,
I .... 1 . . 1 . . . 1 . . 1 . . .
.
.... 1 .... 1 . . . 1 . .
irsn
u'ia-j'j.:uj"ijartKi'ncnnonF)nnnDr i(J'l?|3|4hlilTlfM.-hifianno.nr.nuoEoauuJLJnf; mm. la^W'W*
FORMAT . . . . APPLICAT
10 / INPUT/OUTPUT AND FORMS DESIGN 295
6. Audio response.
layout sheet for displayed output is similar to the layout chart used for
designing input. Areas for displaying the information are blocked out,
leaving the rest of the screen blank or for system status information. Allow-
ing the user to re\dew sample screens can be extremely important because
the user is the ultimate judge of the quality of the output and, in turn, the
success (or failure) of the system. For example, the following shows editing
output for a student birthdate:
FORMS DESIGN
We have learned that data provide the basis for information systems.*
Without data there is no system, but data must be provided in the right form
for input and the information produced must be in a format acceptable to
the user. In either case, it is still data —
the basic element of a printed form.
I , •.» , r.
What Is a Form?
People read fixDm forms, write on forms, and spend billions of hours han-
dling forms and filing forms. The data the forms cany come ftx)m people,
The terms data and information are used here interchangeably, since forms design
*
encompasses both input and output forms. Thus, data may be related to input forms design
and information may be used with regard to output forms design.
296 PART THEEE / SYSTEMS DESIGN
and the informational output of the system goes to people. So the form is a
tool with a message; it is the physical carrier of data — of information. It also
can constitute authority for action. For example, a purchase order says BUY,
a customer's order says SHIP, and a paycheck says PAY TO THE ORDER OF.
ii-
Each form is a request for action. It provides infoiTnation for making deci-
.1.
administrative tool.
Classification of Forms
A printed form is what it does in the system. There
generally classified by
are three primary classifications: action, memory, and report forms. An
action form requests the user to do something get action. (Examples are —
purchase orders and shop orders.) A memory form is a record of historical
data that remains in a file, is used for reference, and serves as control on key
details. (lixamples are inventory records, purchase records, and bond regis-
ters.) A report form guides supervisors and other administrators in their
activities. It provides data on a project or a job. (Examples are profit and loss
statements and sales zinalysis reports.) Figure 10-8 is a summary of the
characteristics and examples of these forms.
2. Maximum, readability and The form must be easy to use and fill
use.
out. It should be legible, intelligible, and uncomplicated. Ample writing
space must be proxdded for inserting data. This means analyzing for ade-
quate space and balancing the overall forms layout, administration, and
use.
4. Order of data items. The data requested should reflect a logical se-
quence. Related data should be in adjacent positions. Data copied from
source documents should be in the same sequence on both forms (see
Figure 10-91. Much of this design takes place in the forms analysis phase.
5. Ease of data used for data entry, the form should have field
entry. If
positions indicated under each column of data (see Figure 10-9) and should
have some indication of where decimal points are (use broken vertical
lines).
6. Size and arrangement. The form must be easily stored and filed. It
porting-data. The user requirements for each type often determine the final
form design.
298 PART THEEE / SYSTEMS DESIGN
Types of Forms
Forms are classified into several categories: flat forms, unit-set/snapout
forms, continuous strip fanfold forms, NCR paper, and pi'eprinted forms.
These types are described briefly.
Flat Forms
A flat form is single-copy form pi^pai^d manually or by a machine and
printed on any grade of paper. For additional copies of the original, carbon
paper is inserted between copies. It is the easiest form to design, print, and
reproduce: it has a low-volume use: and it is the least expensive. Often a pad
of the flat forms is printed identical to the original copy of a unit set. (see
Figure 10-11).
Unlt-Set/Snapout Forms
These forms ha\e an original copy and several copies with one-time
carbon paper interlea\ed between them. The set is glued into a unit (thus,
unit setJ for easy handling (see Figure 10-12). The carbon paper is approx-
imately 3/8 inch shorter than the copies. The copies are perforated at the
glue margin for tearing out, although the carbon is not perforated. Because
of the perforation and the shorter carbon, the forms can be easily snapped
out (thus, the name snapout foiTn) after completion.
10 / INPUT/OUTPUT AND FORMS DESIGN 301
:vEN'
r - - .
-
~ '
7 - = ~ ^ z ~
10 5 rt 1 - £" S 3^ ri_AZA
CHicAeo lu bOtiOt,
LEVEL 1 2 3 TOTAL
ADULT 10 00 8 OO b GO
J-TYPE 5 00 4 00 3 00
C-TYPE 9 OO 7 00 b 00
K-TYPE 8 50 6 50 4 50
L-TVPE 8 CO & OO 4 OO
K-TYPE 7 50 5 50 J 30
V-TYPE b OO 5 00 4_ 00
NOTICE PRICES HAVE BEEN CHANGED
TODAY S SALES
OUTLET SALES
AGENCY SALES
BOX OFFICE SALES
SECONOARV BOX OFFICE SALES
^OTAL SALES
- — TOTAL SALES FOR EVENT
OUTLET SALES
ADULT 1 6 OO
TOTAL 1 6 00
AGENCY SALES
3-Y r=T^ICE SALES
ADULT 26 6i • :; = 2E^ 1966 OO
,>-TYPE eL 2 18 00
C-TYPE tL 2 4 32 00
K-TYPE d. 5 38 50
L-TYPE i -J2 OO
M-TYPE I 7 50
V-TYPE 4 IG 14 38 50
TOTAL 42 80 199 — 321 2132 50
SECONDARY BOX OFFICE SALES
TOTAL SALES
ADW.T 26 tA 200 290 1972. 00
J-T.PE 2 2 4 18 00
&-''<=£ 2 2 4 32 00
— -
5 38 50
K--^/PE 2
L-TvpE 4 4 32 00
M-'VPE 1 1 7 50
V-TYPE 4 10 14 38 50
TOTAL 42 SO 200 322 2138 50
XSALES 84 OCX 100 oox lOO OOZ 97 55X 96 35X
UNSOLD TICKETS
OPEN 6 60 00
HOLD 2 20 00
UNSOLD 8 80 00
(^' : SEATING
r- CAP 5C 30 200 330 2218. 50
C-;
Ba <>^''=
scratch. Other disadvantages are difficulty- with erasures and high cost. \CR
paper costs as much as 25 percent more than the carbon-interleaved forms.
Considering the labor savings of the NCR process, hovve\er, cost may be
well justified in the long run.
10 / INPUT/OUTPUT AND FORMS DESIGN 303
Chemical
coat on top
Chemical
coat under
Layout Considerations
When a form is designed, a list is prepared of all the items to be included on
the form and the maximum space to be reserved. The list should be
checked by the form user to make sure it has the required details.
fixjm top to bottom, the upper left comer of the form is an appropriate place
for a title. On forms that go outside the organization, the title is placed in the
center at the top of the form.
Long titles with vague words should be avoided. Good titles often are no
longer thcin two words. Consider the follovvdng form titles:
center in bold type. In other situations where the upper left corner is used,
the lower left corner is an alternative location.
3. When more than one form is involved, the sequence of data in related
forms should follow the same flow.
Move down
Start
and left
^
^--^
^^^ Move down
and left
^-^^
^«— •**
Continue Etc.
"barks" at the form user. As shown in Figure 10-17, the information filled in
rather than the caption should stand out.
Light, single "hairline" rules should be used unless there is a definite
need for separating parts of the form; in that case, heaxder printed rules can
be used. Printed rules and captions are shown in Figure 10-18.
A column heading is a caption used to refer to more than one rule or box
^
NAME (caption too pronounced)
William E. Beatty
306 PART THREE / SYSTEMS DESIGN
Box Design
Whenever possible, it is advisable to design the form using the box-style
rule, with captions in the upper left comer. The box design gets the
.Age
captions up out of the way and reduces the form size by 25 to 40 percent. It
also makes the data entry uninterrupted frxim left to right. Figure 10-21
contrasts the traditional style used on many forms udth the box design. The
traditional design is acceptable for a handwritten form, but it can be triclcy
Spacing Requirements
If you pick 20 printed forms at random, you will find a gi^at variety of
Address Address
Address
3 lines
per inch ^ : 123^5678901 Elite (12 cpi)
)
5 >
vertically V Hand SF>acing for
1 £ 3 4 5 workers (5 cpi)
Hand spacing
for cler1(S (8 cpi)
-
"CI
or both. In either case, there must be sufficient space to allow for data
capture. A standard is needed.
A commonly used standard called 3 5 spacing, is illustrated in Figure
10-22. The 3 refers to the number of lines perxertical inch, while the 5 refere
to the number of characters that one horizontal inch. This approach is
fit in
related to spacing for clerks '8 charactere per inch or cpi workers (5 cpil,
and printers 110/12 cpi).
There are times w hen a certain amount of space must have a minimum
number of lines. One w a\" of determining lines is with the diagonal spacing
method. .As illustrated in Figur^e 10-23 a 4-inch space is di\ided into nine
writing lines b\- diagonalK acix>ss the space so that the 45-
placing a r\iler
inc li mark equaling nine half-inch spaces' spans the 4-inch area. In this
case, 5-inch multiples are used. A one-inch multiple can be obtained simply
b\ making a sharper diagonal slant of the iiiler.
In columnar spacing the column width is determined b\- the amount of
data in the column and how data are recoixled. The 3 5 iTile should be
adequate to detennine the columnar spacing required on most forms.
Column headings should be wiitten hoiizontalK whene\er possible.
Form Instructions
A well-designed foiTn with clearly stated captions should be self-in-
structing. In a recent consulting job, an eight-page procedure included two
pages telling how to fill out the printed forms. A sample of the instructions
is as follows:
The first form had 29 captions. The procedure listed the captions and
explained the information required under each. Much of this work would
have been eliminated if the captions were self-explanatory.
Forms such as application blanks that are filled out once should be self-
instructing. Other forms (e.g., purchase orders) that are processed repeat-
edly by several people should be designed for easy writing, typing, and
sorting. A form becomes by means of clearly stated captions
self-instructing
and but specific,
brief, procedural instructions. The following examples
illustrate these points.
Self-Instructing
Purpose Unclear Caption Caption
Paper Selection
Forms may be printed on paper of different colors, grades, and weights.
Colored paper or colored piinting on white paper is used to distinguish
among copies and facilitate sorting copies. Common color preferences are
listed in the table.
Fii-st White
Second Yellow
Third Pink
Fourth UlU(!
Cost Considerations
Various cost factors go produce a form. Costs
into the final decision to
consist of both one-time and running costs. Flat charges center around
(flat)
the preparation of the system used to create the first copy. Charges such as
the cost of paper, ink, machine, and labor are all running charges. One way
of reducing costs is order "two-up" or side-by-side forms attached by a
to
perforated line. Other cost-reducing alternatives are:
Forms Control
The first step in forms control is to determine whether a form is necessary.
Managing the hundreds of forms in a t\pical organization requires a forms
contix)! program. Forms control is a procedure for ili pro\iding improved
and eflfecti\e forms, i2i reducing printing costs, and i3i securing adequate
stock at all times.
The firet step in a procedure for forms control is to collect, group, index,
stock, and control the forms of the organization. Each form is identified and
classified by the function it performs and whether it is a flat form, a snap-
out form, or something else. Once classified, a form is evaluated by the data
it requires, where it is used, and how much it o\erlaps with other foinis.
The object is to get rid of unnecessaiA' forms and impiT)\ those fomis that t^
are necessar\'.
Before launching a forms control program, the designer needs to con-
sider several questions:
Summary
1. Input design shows how user-originated input converted to a com-
is
This requires a CRT screen for displax- and predefined user's options
that standaixlize data capture and provide visual verification.
Key Words
Ballot Box Design Menu
Caption NCR Paper
Computer Output Microfilm (COM) Prompt
Fanfold Form Rule
Form Snapout Form
Fornis Design 3/5 Space
Magnetic Ink Character Recognition (MICR)
Review GLuestions
1. What is the goal of input design? Output design?
2. Ifyou were asked to adopt a method for tagging merchandise for a retail
store, what input medium would you choose? Why?
314 PART THREE / SYSTEMS DESIGN
3. What is unique about online data entry? What role does a CRT terminal
play for input and output?
4. Explain briefly three approaches for data entry.
5. How would one design data outputs on a CRT screen? Illustrate.
11. How much instruction does a form need? Are written instructions
required on a printed form? Explain.
12. What factors determine paper selection? Explain.
13. you were asked to develop a forms control program foryour firm, how
If
would you proceed? How would \'ou contixDl for unauthorized forms?
Application Problems
Re\iew the form shown in Exhibit 10-1 and complete the following
assignment:
8. List below all colleges you have attended, uath the dates of attendance at each
and degree(s) awarded. (Attach transcript if other than U. Va.)
9. fVofessional goals a brief statement of vour purpose for taking courses at the
Mclntire School of Commercei.
staples.
Accounting Marketing Finance
Organizational Management
Please check to see that this form h^ been filled in completeh .Mail to .Associate .
Dean, .Mclntire School of Commerce. Ill .\!onroe Hall, L'niversit\ of \irginia. Char-
lottes\ille. \ irginia 22903, no later than .March 1 for September admission
10 / INPUT/OUTPUT AND FORMS DESIGN 317
items and their locations. The draft was then shown to employees in
charge of purchase requisition and those in accounting who process
purchase orders.
The analyst was surprised to find that each pereon had a different
view of what should go in the form and how it should be laid out. After
much debate, she had everyone agree on the overall content. Using her
experience and the feedback, she went through a second draft and laid
out the items so that the foiTn was easy to read and fill out. Certain areas
were set in boldface type for emphasis. A boxed design was introduced
to make it easy to find where the answer should be entered. Filing
information was placed close to the top of the fomi.
The form's width and length conformed to standard paper and
cabinet size for filing. The spacing also conformed to the company's
typewi iters, which were pica (12 character per inch). The typewiitere
were standard electric units about nine years old.
The form consisted of an original and three copies attached, with
one-time carbon in between. Since the form carried essentially the same
information, no specific instructions were printed on it. As a final touch,
a border was added to give it an official look.
The analyst produced a final draft and showed it to an experienced
forms sales person and a systems analyst who works for a competing
firm. An order was placed for 10,000 copies of the form. A few weeks
after the form was in use, it turned out to be a disaster. The analyst did a
thorough job, but some things were apparently missing.
Assignment
a. What major steps were overlooked in the overall design of the form? Expain.
b. If you were the analyst, how would you have handled the pi*oject? Elabo-
rate.
Examine the form shown in Exhibit 10-2 on p. 318. List the items that
need to be changed. How would you change them? Why?
»
UNIVERSITY OF VIRGINIA
INTER DEPARTMENTAL TRANSFER INVOICE
Preparation
Date
DATE OF
OCUVERVOfl ARTICLES Of* SERVICES AND DESCRmON UNIT
SEflvlCE
miCE
DEPARTMENTAL
APPROVAL —
1 11 CHARGE CODE sas9 AMOUNT 69 79 CREDIT CODE 8088 1.0 NO 92 99 THIRD REF
Signature of Approving
Officer
While Gfeen & Can«fy VouCh«< fink & GoKlenrod DcoamnenMi us«
Selected References
Filkins, James M. "Forms Analysis More Than Just Design." Information and —
Records Management, August 1978, p. 18ff.
Kirk, Nathan. "I^gai Restraints in Forms Design." Journal of Systems Management,
June 1979, pp. 38-42.
—
Koeneke, W. "Forms Control Fortime or Flop?" Journal of Systems Management,
January 1981, pp. 11-14.
Mathies, Leslie H., and (iibbs Myers. "Good Fomis Design Is Vital to Management."
The Office, September 1981, p. 76ff.
10 / INPUT/OUTPUT AND FORMS DESIGN 319
—
Myers, Gibbs. "Forms Management Part 2: How to Design Business Forms." Jour-
nal of Systems Management, October 1976, pp. 15-19.
Nussbeck, Dan. "Forms Control at Hallmark: A Philosophy as Well as a System."
Information and Records Management, August 1978, pp. 16-17.
Seager, Dave. "The Ten Commandments of Forms Design." Canadian Datasystems,
October 1977, pp. 40-45.
Stubbs, Jack. "Forms Are Main User Connection." Data Management, June 1977, pp.
12-18.
Chapter 11
File Organization
and Data Base Design
Introduction
File Structure
File Organization
SEQUENTIAL ORGANIZATION
INDEXED-SEQUENTIAL ORGANIZATION
Chaining
INVERTED LIST ORGANIZATION
DIRECT-ACCESS ORGANIZATION
32U
At a Glance
After designing the input and output, the designer begins to concentrate on file
design or how data should be organized around user requirements. How data
are organized depends on the data and response requirements that deter-
mine hardware configurations. File organization may be sequential, indexed-
sequential, inverted list, or random. Each method has its pros and cons.
An integrated approach to file design is the data base. The general theme
is to handle information as an integrated whole, with a minimum of redun-
NORMALIZATION
Steps in Normalization
INTRODUCTION
Perhaps the most important aspect of building candidate systems is file
design. After the input, output, and various forms are designed, files and the
data they store must be organized according to user requirements and the
constraints of the hardware and operating system. Some applications are
processed daUy and affect each record in the file. Such records are handled
in sequential order when tape is the appropriate medium. In contrast,
records that are updated, accessed, or retrieved at random are stored on
disks or diskettes. How a file is organized has a lot to do with the nature of
the data and the response requirements that determine hardware configu-
rations. This chapter reviews the ways files are organized and data base
design for implementation success.
nLE STRUCTURE
To learn about we need to understand basic terms used
files, to describe
the file hierarchy. The terms we shall coxer are byte, data item, record, file,
and data base (see Figure 11-1).
Data bases L
Files L -^ V :i
Records
I
^ •^2.
± ^
Data '
items T_ :^
•2._ 3 4
I
Bytes I_J
1 1 / FILE ORGANIZATION AND DATA BASE DESIGN 323
one attribute may be sex, name, age, or social security number. A data item
is sometimes referred to as afield. A field is actually a physical space on tape
nLE ORGANIZATION
A organized to ensure that records are available for processing. As
file is
'"St
Physical record
—
layout disk
format
Logical record
required by
programmer In the
sequence of a
chain
1 1 / FILE ORGANIZATION AND DATA BASE DESIGN 325
Sequential Organization
Sequential organization simply means storing and sorting in physical, con-
tiguous blocks within files on tape or disk. Records are also in sequence
within each block. To access a I'ecord, previous records within the block are
scanned. Thus sequential record design is best suited for "get next" ac-
tivities, reading one record after another without a search delay (see Figure
11-3).
In a sequential organization, records can be added only at the end of
the not possible to insert a record in the middle of the file without
file. It is
rewriting the file. In a data base system, however, a record may be inserted
anywhere in the file, which would automatically resequence the records
following the inserted record. Another approach is to add all new records at
the end of the file and later sort the fileon a key name, number, etc.).
I
Indexed-Sequentlal Organization
Like sequential organization, keyed sequential organization stores data in
physically contiguous blocks. The difference is in the use of indexes to
locate records. To understand this method, we need to distinguish among
three areas in disk storage: prime area, overflow area, and index area. The
prime area contains records stored by key or ID numbers. All records are
file
initially stored in the prime area. The overflow area contains records added
to the file that cannot be placed in logical The
sequence in the prime area.
inde^ area more like a data dictionary. It contains keys of records and
is
their locations on the disk. A pointer associated with each key is an address
that tells the system where to find a record.
Figure 11-5 illustrates an airline reservation file. The index area con-
tains pointers to the Chicago and Houston flights. The Chicago flight points
to the Chicago flight information stored in the prime area. The Houston
flight points to the Houston flight information in the prime area. Lack of
space to store the Huntsville flight in sequential order made it necessary to
load it in the overflow area. The overflow pointer places it logically in
^-Ks-^
ft
B
D
u
c
< \\ a>
\\ o
\ \ °
\ \ O)
o \ T3 C
o c
D
N
•ft 0) (n
S^"
CD £
Q. >.
^ CO
c .p
. O C
1 »> o
h~ i^
''
(1)
w
Ul
a:
cr o/
w;
CO o
I
—
sequential order in the prime area. The same arrangement applies to the
Louisville flight.
Indexed-sequential organization reduces the magnitude of the sequen-
tial search and provides quick access for sequential and direct processing.
The primary drau^aack is the extra storage space required for the index. It
also takes longer to search the index for data access or retrieval.
Chaining
be established among data
File organization requires that relationships
items. It must show how characters irom fields, fields form files, and files
relate to one another. Establishing relationships is done through chaining
or the use of pointers. Figure 11-5 showed how pointers link one record to
another. Figure 11-6 is a list of auto parts —
mufflers, windshields, fenders
stored on disk. The file is a indexed-sequential access file sequenced by key
328 PART THREE / SYSTEMS DESIGN
Index
area
Prime
area
Overflow
area
: Pointers
Key 2:
Keyl: Part
Address Part# Type Pointer
until it finds the key value for the Houston flight. This value has two records
associated with it: R3 and R6. The DBMS essentially teUs the agent that flight
#170 is departing at 10:10 a.m. (R3) and flight #169 is depaiting at 8:15 a.m.
(R6).
330 PART THREE / SYSTEMS DESIGN
R = Relation
(association)
Flight
Location Flight* Flight description departure
flight." It finds R3 and R6. Next it searches the flight departure index for
these values. It finds that the R3 value departs at 10:10, but the R6 value
11 / HLE ORGANIZATION AND DATA BASE DESIGN 331
Direct-Access Organization
In direct-access file organization, records are placed randomly throughout
the Records need not be in sequence because they are updated directly
file.
and revso^itten back in the same location. New records are added at the end
of the file or inserted in specific locations based on software commands.
Records are accessed by addresses that specify their disk locations. An
address is required for locating a record, for linking I'ecords, or for establish-
ing relationships. Addresses are of two types: absolute and relative. An
absolute address represents the physical location of the record. It is usually
stated in the format of sector/track/record number. For example, 3/14/6
means go to sector 3, track 14 of that sector, and the sixth record of the
track. One problem vvath absolute addresses is that they become invalid
when the file that contains the records is relocated on the disk. One way
around use pointers for the updated records.
this is to
A relative
address gives a record location relative to the beginning of the
file. There must be fixed-length records for reference. Another way of
locating a record is by the number of bytes it is from the beginning of the file
(see Figure 11-8). Unlike relative addressing, if the moved, pointers
file is
need not be updated, because the relative location of the record remains
the same regardless of the file location.
Each file organization method has advantages and limitations; a sum-
mary is given in Figure 11-9. Many applications by their nature are best
done sequentially. Payroll is a good example. The system goes through the
employee list, extracts the information, and prepares pay slips. There are no
lengthy random-access seeks. In contrast, real-time applications where
response requirements are measured in seconds are candidates for r£in-
dom-access design. Systems for answering inquiries, booking airlines or
stadium seats, updating checking or savings accounts in a bank, or interact-
ing with a terminal are examples for random-access design.
every size of computer. Before the data base concept became operational,
users had programs that handled their own data independent of other
users. It was a conventional
environment with no data integration or
file
shared authorized users with the data base software managing the data
b\'
as an entit\ .A program now requests data through the data base manage-
.
ment system DBMS which determines data sharing isee Figure 11-10'.
Profit Profit
• Skills data
sharing Profit sharing
• Profit sharing
application sharing application
data
data
• Benefits data
Employee Employee
benefits benefits
Benefits
application application
data
Key Terms
In data base design, be familiar with several terms. Suppose we
we need to
have a sales status system designed to give the sales activities of each
salesperson. Using the basic model in Figure 11-11, we run into four temis:
Sales Report
Salesperson 1
Step (item) 1 40.(»
Step (Item) 2 11450
Total $154 50
Systems
<yj„ Analyst
Salesperson 2
Step (Item) 1 16.00
Step (Item) 2 20100
Step (Item) 3 4100
Total $?58.00
INPUT PROCESSING
1. User's view is a profile that the user expects to see on a report. In our
example, the user's view is a sales report.
In a data base environment, the DBMS is the software that provides the
interface between the data file on disk and the program that requests
processing. As shown in Figure 11-12, the DBMS stores and manages data.
The procedure is as follows:
1. The user requests a sales report through the application program. The
application program uses a data manipulation language (DML) to tell
To summarize,
1. DML manipulates data; it specifies what is required.
(0 o
3
o
eg
til
c 5 «
CO
Q
o 0) ^
a
c
o 1
c o
u oo o
in lo 8888 C
E o
» -^ •^
-^ ID
(D -- >- CO
•.- o •* in
y
(
CM CNJ I
t: (ft V*
o
a.
(A 0)
cr
"(5
O E
S s S E
O E E \
(U (U <u o O <1> /
a CO
(/)
« Q.Q.Q.O Q.aQ.ao y
« OJ *—flj « 031— QJ QJ /
d w 1^55 -^55ww \
D w w
Q
I—
I
U5
—
actual departure and arrival times mav vaiy. The user's view might be a
particular flight ani\ing or departing at a scheduled time. How the flight
actually takes oft' or lands is of little concern to the user. The latter view is of
subschema. It is a programmer's (pilot's) view. Many subschemas can be
derived from one schema, just as different pilots visualize different views of
a landing approach, although all (it is hoped) arrive at the sheduled time
indicated on the CRT screen display (schema).
Different application programmers visualize different subschemas. The
Application Operating
program system
DML IOCS
User
logical
view
Program
logical
view
Overall
logical
view (schema)
— s/
Physical view
(1) (2) (3) (4)
338 PAKT THREE / SYSTEMS DESIGN
Data
model
Data Structure
Data are structured according to the data model. In our example (see Figure
11-12), sales items are linked to the salesperson who sold them. The
salesperson is called an entity and the item sold is also an entity. An entity is
a conceptual repi'esentation of an object. Relationships between entities
make up a data structure. A
data model represents a data structure that is
Types of Relationships
Three types of relationships exist among entities: one-to-one, one-to-
many, and many-to-many relationships. A one-to-one (1:1) relationship is an
association between two entities. For example, in our culture, a husband is
allowed one wife at a timei and \ice versa, and an employee has one social
I
Husband Employee
1 : 1 relationships
Wife SSN
1 1 / FILE ORGANIZATION AND DATA BASE DESIGN 339
Children Skills
Children Students
I I
Toys Courses
mm a
Application Operating
PInysical
program system
data
DML IOCS storage
Customer record
Customer
record
Acount , . Last
No ^(2) deposit
Ford GM
Drive shaft
duplicates
duplicates
342 PART THREE / SYSTEMS DESIGN
Yetirs with
Employee Number Name the Firm
3. Two or more tables can be merged to form one relation. Unlike hier-
archical or network structuring where all relationships are predefined,
a relational DBMS develops new illations on user commands.
To illustrate, suppose a relational DBMS maintains two relations: the
EMPLOYEE relation (Figure 11-22)and the EMPLOYEE EDUCATION rela-
tion (Figure 11-23). A query about employees with more than two years in
the firm and an MBA puts the relational DBMS through the following
routine:
file. This is called a temporary relation and will be deleted after the user
has been satisfied.
Entity Salesperson
key
Attributes ,
Salesperson
of an entity number Name Sex Age Height
Values of
attributes
'
211206801 Arnold, Jim M 34 5 10
344 PAST THEEE SYSTEMS DESIGN
/
211306801 is a unique identifier of Jim .Arnold. Sex, age, and height are not
identifiers, since they are not unique. They are nonke\' identifiers.
Normalization
Data structuring is refined through a process called normalization. Data are
gix)uped in the simplest way possible so that later changes can be made
with a minimum of impact on the data structure. When too mam' attributes
are grouped together to fomi entities, some attributes are found to be
entities themsehes. Further normalization of these entities into attributes
linked by common data elements to foi-m relationships improves the effec-
tiveness of the DBMS.
Steps in Normalization
1. Isolate repeating groups from an entit\' because they are easier to
process separate from the rest of an entit\ Figure 11-25 is an unnormalized
.
file structure. The firet four attributes (employee number, name, branch,
and department! are \irtuallv constant. The remaining three attributes litem
number, item description, and price contain data that change and are
i
Salesperson Sales
Salesperson Sales
Number Name Branch Dept Item no Item description Price
1 1 / FILE ORGANIZATION AND DATA BASE DESIGN 345
=Key
salesperson data uith employee number as the primary key and the
file
salesperson item file with employee number and item number as new
attributes. They are added to relate the I'ecords in the file to the salesperson
data file. The two attributes are used together for accessing data. Two keys
used together are called a concatenated key.
2. After isolating repeating gixjups ftxjm the rest of an entity, try to simplify
the relation further.The second normalization makes sure that each non-
key attribute depends on a key attribute or concatenated key. Nonkey
attributes that do not meet this condition cire split into simpler entities. In
Figure 11-26, each attribute in the salespereon data file depends on the
primaiy key "employee number." In the salesperson item file, the attribute
"scdes price" depends on a concatenated key ("employee number" and
"item number"). The way the file is set up, the Sciles price is strictly related
to the salesperson number and the item number of the sale. Alternatively,
the attribute "item description" tags to "item number," which is part of the
concatenated key. This causes several concerns. Sales information is avail-
abe only by salesperson number, which is unwieldy. Worse yet, an em-
ployee transfer would make it difficult to maintain records because they
would be dropped when the salesperson leaves the department.
To solve the problem, we create new^ independent entities for "item
346 PART THREE / SYSTEMS DESIGN
description" and "sales price." In one file, we create the item description
attribute with item number keys fixjm the salesperson item The remain-
file.
ing attributes (employee number, item number, and sales price) become the
second normalized form (see Figure 11-27.)
The second nomialization offers several benefits. Sales items can be
added without being tagged to a specific salesperson. If the item changes,
we need to change only the item file. If a salesperson leaves the depcirtment,
it would have no direct effect on the status of the items sold.
^
y
/Employee* /item # Sale price
/
/Item # Item description
' '
/
Employee #
^ ltem# Sale price
/
/
ltem# Item description
1. Computes total sales for each salesperson ftx»m the salesperson item
file.
2. Goes to the employee data file to look up the store branch to which the
salesperson is assigned.
3. Accumulates each salesperson's sales in a special field in the store
branch file.
This procedure is repeated for each salesperson in the file. Figure 11-29
illustrates the processing cycle for salesperson 211306801.
A normalized data base must serve the application needs of the organi-
zation. Normalization simplifies the data structure and makes it easy to use
and modify. It also establishes an easy relationship between attributes
based on common attributes. These benefits should be weighed against
redundancies that often result in processing inefiiciency.
common data base, certain diflBculties in sharing are likely to occur. Percep-
tions regarding data ownership, priority of access, and the like become
1
^ Employee # Employee name Store branch ^Store branch Department Total sale
Summary
1. The file hierarchy begins with b34es (the smallest addressable units),
which make up data items. Data items are records that are grouped to
•make up a file. Two or more files are a data base.
350 PAET THREE / SYSTEMS DESIGN
they differ in the way they structure data. The three types of data
structures are hierarchical, netu'ork, and relational. A hierarchical
structure specifies that an entity cannot have more than one parent. A
network structure allows 1:1, 1:M, or M:M relationships and can best be
supported by a network. To simpliK' the structure, the network is
separated into a number of hierarchies with duplicates. A hierarchy,
then, becomes a sub\iew of the network stixicture. A relational stnjcture
is a flat, two-dimensional table representing data and relationships. It
allows the user to update the table's content and prDvides a powerful
inquiry capability. ^
There are four views of data. The first three views a: e logical: user's \iew,
application prc)gram (called subsc/iema), cind ovei^l logical \iew (called
11 / FILE ORGANIZATION AND DATA BASE DESIGN 351
schema). The physical view is what the data actually look like in phys-
ical storage.
Key Words
Attribute Input/Output Control System
Chaining (IOCS)
Concatenated Key Instance of an Entity
Data Aggregate (see Entity) Inverted List Organization
Data Base Key
Data Base Administrator (DBA) Logical Record
Data Base Management System Network Structure
(DBMS) Normalization
Data Definition Language (DDL) Operating System
Data Independence Physical Record
Data Item Pointer
Data Manipulation Langauge (DML) Redundancy
Data Model Relation
Data Structure Relational Structure
Direct-Access Organization Root
Entity Schema
Field (see Data Item) Sequential Organization
Hierarchical Structure Subschema
Indexed-Sequential Organization Tuple
Review GLuestions
1. Illustrate the hierarchy making up a data base.
2. Explain the difference between:
a. Logiccd and physical record.
b. Data item and field.
c. File activity and file volatility.
d. Sequenticil and indexed-sequential.
e. Indexed-sequential and inverted list.
352 PART THREE / SYSTEMS DESIGN
5. Take a look at Figure 11-6 in the chapter. Produce an inverted list with a
brief explanation of its meaning?
6. How does an absolute address differ from a relative address?
7. In your own words, define data base. What is the single most critical
aspect of data base? Why?
8. How does the user's view relate to a data model? Explain.
9. Explain how DDL, DML, and DBMS are related.
Application Problems
Legend
^ 1:1 relationship
( Name J (
Age j ( Type j 1^— 1:M relationship
M:M relationship
Example:
Type of
From To Association
(1:1,1:M, M:M)
/7 ^ . r\ . ^ ^ n f
1 O
Woman
354 PAKT THEEE / SYSTEMS DESIGN
Assignment
a- Elxplainwhat the schema means; that is, what types of associations are
there between the same tw^o data items?
Assignment
a. How many attributes represent a record? List them.
b. How many \alues are there of the attribute SALARY?
c. How many tuples represent the partial Gle?
d. What are the values of the attribute EXTENSION of the following employees:
Crane, Kehoe, York?
Selected References
.Adams, Robert G. The Changing Fabric of Database Technology." ICP Software
Business fievjew, Febnaaiy/March 1983, pp. 38-43.
1 1 / FILE ORGANIZATION AND DATA BASE DESIGN 355
Bradley, James. File and Data Base Techniques. New York: Holt, Rinehart & Winston,
1982.
Bronstein, Philip. "DBMS Comes to Small Computers." Small Systems World, April
1983, pp. 21-27.
Dumas, Ronald L. "Relational Data Base: What Is It, and What Can It Do?" Data
Management, January 1981, pp. 15-17.
Gillin, Paul. "Relational Data Base: Pushing for Acceptance." Computerworld, De-
cember 26, 1983, pp. 66-70.
Holland, Robert H. "The Executive Guide to Data Base Management Systems." ICP
Software Business Review, February/March 1983, pp. 46-50ff.
Horton, Forest Woody Jr. "Tapping External Data Sources." Computerworld, August
15, 1983, pp. l-3ff.
Houston, Velina. "Database Idea 20 Years Old, but Still Growing." Management
Information Systems Week, July 13, 1983, pp. 25-26.
Kent, William. "A Simple Guide to Five Normal Forms in Relational Database The-
ory." Communications of the ACM 26, no. 2 (February 1983), pp. 120-25.
Levering, Robert. "Data Management without Programming." PC World 1, no. 3, pp.
113-17.
Meng, Douglas and Lenore. "What's in a (Data Item) Name?" Computerworld, Sep-
tember 12, 1983, pp. 49-501T.
Pembroke, JUl. "Public Database: Your Electronic Library." Small Systems World,
September 1983, 30-34ff.
Ross, Ron. "Data Base Machines: Still a Question Mark." Computerworld, November
8, 1982, pp. 29-36.
Siwolop, Scina. "Touching All the Data Bases." Discover, March 1983, pp. 68-71.
Walsh, Myles. "Database Management Systems: An Operational Perspective." Jour-
nal of Systems Management, April 1983, pp. 20-23.
Part Four
System
Implementation
-> ^ •
12 SYSTEM TESTING AND GlUALITY ASSURANCE
13 IMPLEMENTATION AND SOFTWARE
MAINTENANCE
14 HARDWARE/SOFTWARE SELECTION AND THE
COMPUTER CONTRACT
1 5 PROJECT SCHEDULING AND SOFTWARE
1 6 SECURITY, DISASTER/RECOVERY, AND ETHICS IN
SYSTEM DEVELOPMENT
357
Chapter 12
System Testing
and €Luality Assurance
Introduction
358
.
At a Glance
SYSTEM TESTING
Types of System Tests
€LualitY Assurance
QUALITY ASSURANCE GOALS IN THE SYSTEMS LIFE CYCLE
Quality Factors Specifications
Software Requirements Specifications
Software Design Specifications
Software Testing and Implementation
Maintenance and Support
LEVELS OF QUALITY ASSURANCE
Trends In Testing
INTRODUCTION
No program or system design is perfect; communication between the user
and the designer is not always complete or clear, and time is usuallv short.
The result is errors and more errors. The number and nature of errors in a
new design depend on several factors:
1. Communications between the user and the designer.
2. The programmer's abilitv' to generate a code that reflects exactly the
system specifications.
3. The time frame for the design.
grams in the candidate system, where the output of one pix)gram will
affect the processing done by another prDgram.
and with the intention of finding errors — making the progr^am fail.
5. Acceptance testing is running the system with li\e data b\ the actual
user.
testing early in the process translates directly into long-term cost savings
fix)m areduced number of errors.
Another reason for system testing is its utility as a user-oriented vehicle
before implementation. The best program is worthless if it does not meet
Test data may be artificial (created solely for test purposes or live (taken
I
&X)m the user's actual files Properly created artificial data should provide
i.
all combinations of values and formats and make it possible to test all logic
and transaction path subroutines. Unlike live data, which are biased toward
typical values, artificial data provide extreme values for testing the limits of
the candidate system.
For large, complex systems, a computer program is used to generate the
necessary test data. Data-generating programs save substantial time for
both the programmer and the test itself. A familiarity' with system files and
parameters, however, is necessary for writing an effective data-generating
program.
derived from the test plan. Others are an agreement on the test schedule,
the test duration, and the persons designated for the test. The start and
termination dates for the test should also be specified in advance.
i •
Prepare Test Data for Program Testing
.As each pixjgram is coded, test data are prepared and documented to
ensure that all aspects of the program ai^ property' tested. After the testing,
the data are filed for future reference.
1. The system group has time a\ailable to spend on training while the
programs are being written.
2. Initiating a user-training program gives the systems group a clearer
image of the user's interest in the new system.
3 -A trained user participates more effectively in system testing.
E
o
Q u
'73
c
<
c
0)
C 0}
^
"=; ai
^5b
V
b 6D
CL C
c 5C sc en t« ;n C (0
c C 02
a;
F
c
B E E 0 JS
g-c c ."^ .^
Q O > a;
0?
0 to »3
4)
to
(U
tn
03
tn
;/l
!t>
P 3S »3
uj; 15C
v V
c w
^W ^v c c
r- Qi QJ a:
O ^ W
"1
^« r~i
JliS
!8
.!«
ca
.:^
« :S
c 03
nS (t a;
o
X •XI 'J: aa X CQ OS X -y;
c
.0
O O m 35 >* O lO -.0 X -r C lO M 3
^J
CV) ^] CVJ ^H M T* fH T-H rH CO rH
^ n
a « o o o o T-* r-l N r^ ^J CVJ N CV] rg CM
E°
o
i-c rH rH <SI r- rH rH rH r^ r^
'^
o o ;o
o CO
'x>
o o o
9 ^, ^ ^ ^
rH rH O O -H
~^ ^^ ^
13
o o o o o o cvj M
cv] eg M ?3 S3
M
u
0)
X!
u «3
a;
0) 01
u
a CB
u
C! a;
c
M S Q
oj E
>- o o S 3
a
ca
a
(1>
c C o
0)
•c
< C t3 E o
a -= ac CO
3
c tn n a. "3 1 l« 03
o c C c
<u g « c c
1 I
«
o
§1 3 -P T3
u ttjD
03
E c
3
tic
c
a1 1 1n
c o 03 |« C
c "^ c o O C Oi -r- 33 c 5 a CO
and department heads who, in turn, train their staff as they see fit. The
reasons are obvious:
(c . Compile/Assemble Programs
programs have to be compiled/assembled for testing. Before this,
All
however, a complete program description should be available. Included is
the purpose of the program, its use, the programmer! s who prepai'ed it, i
and the amount of computer time it takes to run it. Program and system
flowcharts of the project should also be available for reference.
In addition to these activities, desk checking the source code uncovers
programming errors or inconsistencies. Before actual program testing, a run
order schedule and test scheme are finalized. A run order schedule specifies
the transactions to test and the order in which they should be tested. High-
priority transactions that make special demands on the candidate system
are tested first. In contrast, a test scheme specifies how program software
should be debugged. A common approach, called bottom-up programming,
tests small-scale program modules, which are linked to a higher-level mod-
ule, and so on until the program is completed. An alternative is the top-
down approach, where the general program is tested first, followed by the
addition of program modules, one level at a time to the lowest level.
System Testing
The purpose of system testing is to identifv and connect errors in the
candidate system. As important as this phase is, it is one that is frequently
12 / SYSTEM TESTING AND QUALITY ASSURANCE 367
1. Turnaround time is the elapsed time between the receipt of the input
and the availability of the output. In online systems, high-priority process-
ing ishandled during peak hours, while low-priority processing is done
later in the day or during the night shift. The objective is to decide on and
evaluate all the factors that might have a bearing on the turnaround time for
handling all applications.
1. Program(s) testing.
2. String testing.
3. System testing.
4. System documentation.
5. User acceptance testing.
actually the user's show. User motivationand knowledge are critical for the
successful performance of the system. Then a comprehensive test report is
prepared. The report indicates the system's tolerance, performance range,
error rate, and accuracy.
aUALITY ASSURANCE
The amount and complexity produced today stagger the imag-
of software
ination. Software development strategies have not kept pace, however, and
software products fall short of meeting application objectives. Conse-
quently, controls must be developed to ensure a quality product. Basically,
quality assurance defines the objectives of the project and reviews the
overall activities so that errors are corrected early in the development
process. Steps are taken in each phase to ensure that there are no errors in
the final software.
2. Reliability — the degree to which the system performs its intended func-
tions over a time.
tion. —
In systemi testing, the common view is to eliminate program errors. This
isextremely difBcult and time-consuming, since designers cannot prove 100
p>ercent accuracy. Therefore, all that can be done is to put the system
—
through a "fail test cycle determine what will make it fail. A successful
"
12 / SYSTEM TESTING AND QUALITY ASSURANCE 371
test, then, is one that finds errors. The test strategies discussed earlier are
used in system testing.
System validation checks the quality of the software in both simulated
and environments. First the software goes through a phase (often
live
referred to as alpha testing) in vv^hich errors and failures based on simulated
user requirements are verified and studied. The modified software is then
subjected to phase two (called beta testing) in the actual user's site or a live
environment. The system is used regularly with live transactions. After a
scheduled time, failures and errors are documented and final correction
and enhancements are made before the package is released for use.
The third level of quaUty assurance is to certijy that the program or
software package is currect and conforms to standards. With a growing
trend toward purchasing ready-to-use software, certification has become
more important. A package that is certified goes through a team of spe-
cialists who test, review, and determine how well it meets the vendor's
claims. Certification is actually issued after the package passes the test.
Certification,however, does not assure the user that it is the best package to
adopt; it only attests that it will perform what the vendor claims.
In summary, the quaUty of an information system depends on its
design, testing, and implementation. One aspect of system quality is its
reUability or the assurance that it does not produce costly failures. The
strategy of error tolerance (detection and correction) rather than error
avoidance is the basis for successful testing and quality assurance.
TRENDS IN TESTING
In the future, we can
expect unparalleled growth in the development and
use of automated tools and software aids for testing. One such tool is the
functional tester, w^hich determines whether the hardware is operating up
to a minimal standard. It is a computer program that controls the complete
hardware configuration and verifies that it is functional. For example, it can
test computer memory by performing read/write tests, and it tests each
peripheral device individually.
The functional tester is of great value when minute hardware problems
are disguised as softvv^are bugs. For example, hardware faults are usually
repeatable, wheras software bugs are generally erratic. Problems arise when
the deficate interaction betw^een hardw^are and software cause a hardware
problem appear as an erratic software bug. A functional tester determines
to
immediately that the problem is in the hardware. This saves considerable
time during testing.
Another software aid is the debug monitor. It is a computer program
that regulates and modifies the applications software that is being tested. It
can also control the execution of functional tests and automatically patch
or modify the application progrcim being tested.
The use of these tools will increase as systems grow in size and com-
372 PAST FOUB / SYSTEM IMPLEMENTATION
1. Source documents are no longer used by the system after they cire
transcribed onto a machine-readable medium. They are often filed in
areas or ways that makes later access difficult. In direct data entry,
traditional source documents are simply eliminated.
One way maintain a viable audit trail is to keep a detailed file of the
to
transactions as they occur. The file can then be the input for an audit
12 / SYSTEM TESTING AND QUALITY ASSURANCE 373
program that extracts the transactions for selected accounts and prints
them so an account in detail.
that the auditor Ccin trace the status of
Given the important role of the auditor, he/she is expected to be pcirt of
the system development team, which includes the user. As an independent
adviser, the role is to judge the controls and make recommendations to the
team. Three important steps are considered in the evaluations:
Summary
1. Inadequate testing or nontesting leads to errors that may be costly
when they appear months later. Effective testing translates into cost
savings from reduced errors. It also has utility as a user-oriented vehicle
before implementation.
2. A candidate system is subject to a variety of tests: online response,
volume, stress, recovery and security, and usability tests. Each test has a
unique benefit for a successful installation.
3. Test data may be artificial from the user's files). In either
or live (taken
Key Words
Alpha Testing Stress Testing
Audit Trail String Testing
Beta Testing System Testing
Desk Checking Turnaround Time
Ergonomics Unit Testing
Quality Assurance User Acceptance Testing
Sequential Testing Validation
Review Gluestlons
1. Why do we test systems? How important is testing? Elaborate.
2. A variety of tests are used to test systems. Discuss three such tests.
8. There are two ways of debugging program software: bottom-up and top-
down. How do they difier?
9. Specify the purpose of system testing. What performance criteria are
used for system testing? Discuss.
10. Elaborate on the steps taken in system testing that lead to the user's
acceptance of the system.
11. What is a syntax error? How does it differ from a logic error? Give an
example.
12. Define quality assurance. From your understanding of this concept,
u+iy the fuss over it?
13. List and briefly describe the factors that affect the quality of a system.
Application Problems
Assignment
a. What specifically was wrong with the training program? Who was to blame?
Why?
b. If you were the store's manager, what would you do?
c. Outline a training program and a test procedure for this type of conversion.
12 / SYSTEM TESTING AND QUALITT ASSURANCE 377
ACME BOOKSTORES
Acme Bookstores is a ti^tly held bookstore chain. Established in
1947 by Joseph Acme, the company has grown from a small bookstore
to 17 stores serving 17,000 students of a major university. Mr. Acme, Jr. is
president, treasurer, and general manager. He is directly responsible to
the board of trustees. The remaining three officers are an executive vice
president, a vice president, and an assistant treasurer. There are also
five department managers; the corporate comptroller, the director of
purchasing, the manager for college textbooks, the manager for law,
nursing, and graduate business textbooks, and the director of shipping
and receiving (see Elxhibit 12-1).
Tlie study focuses on the accounts payable in the accounting
department. Tlie accounts payable staff consists of an invoice process-
ing clerk and three accounts payable clerks. Each clerk has specific
work; one processes publishers w^ose names begin with A through L,
Board
of
Trustees
President
Manager Manager
Oirectar Fkxx
Law
of Vice Assistant Corporate Mar^ger
Nursir^ Shipping
President Treasurer Comptroller
College Graduate and
""9
Text Busir>ess Receiving
Brarx*
Managers
Corporate
Accountant Accounts Accounts
arv] Receivabte Payable
Bookkeeper
378 PART FOUR / SYSTEM IMPLEMENTATION
The Problem
Acme Bookstores presently operates a manual accounting system
which is preventing the company from expanding or efficiently han-
dling invoices. Because of the volume of transactions that must be
handled monthly by the accounts payable clerks, they iire unable to
locate companies who offer discounts for early payment and, therefore,
are losing approximately $10,000 per year in discounts alone. Since they
do not have time to verify all the billing statement figures, bad pricing
and billing errors are ignored and payments are sent without being
reconciled with the firm's records. Because of the time constraints, the
accounting records ai^ not being baltinced monthly and human errors
are not caught.
In addition, the present system does not provide a breakdoun by
branch of the operating insults. This has resulted in a control problem
for Acme Bookstores. For example, a branch manager was suspected of
embezzling funds, yet by the time the company realized this prx)blem,
the audit trail was lost and he could not be prosecuted. Lack of specific
branch information has made the company unable to detect potential
operating problems relating to that branch. There is also no possible
way for the firm to compile monthly financial statements to summarize
and examine operating results.
Orders and
PROFESSORS Purchases j
AND
CUSTOMERS '1
Hardware/Software Selection
To alleviate the problem, the appropriate hardware for the ideal
system had to be selected and installed. In the selection process, three
decisions were made: the software to do the job, the brand of hardware,
and the physical site. Softwai^ packages for accounts payable are
numerous, depending on the brand of computer. It was found that
most of the software was available on IBM systems. Since emphasis has
been on the microcomputer, an accounts payable package was located
380 PAST FOUB / SYSTEM IMPLEMENTATION
Tangible costs:
Haiti wiire
System XT with one drive $ 2,104
Extra memory 375
Monitor 680
70 megabytes with backup tapes 7,495
Interface board 149
Printer 1,000
Total $11,803
Software
DOS 2.1 operating system 65
Software package (complete) 2,780
Basic interpreter 195
Total 3,040
Maintenance
12 percent of hardware cost —
$l,416/year for three ye^rs 4,249
Total costs $19,092
Cost Savdngs:
up discounts
Ability to pick $10,000
Reduction in employee time 3,840
Check-writing time 2,160
Processing transactions time 927
Closing of the books • 1,344
Total Savings $18,316
d«.^.
12 / SYSTEM TESTING AND QUALITY ASSDEANCE 381
allows the user to select from the severed options: general ledger, ac-
counts payable, accounts receivable, and inventory control. After an
option is selected, the package displays a second menu that contains
the options of the particular processing system or utility function se-
lected (see Exhibit 12-4).
The proposed accounts payable system provides the user instant
cash flow position. It automatically posts debits
accessibility to his/her
and credits to vendor invoices. All account distribution information is
automatically posted to the general ledger system. The system op>er^tes
in an online interactive mode. AU disbursements, debit/credit entries,
and vendor mciintenance are accomplished through the console with
Option
End-of-month Close the A/P system
at the end-of-month and
#9 and end-of-year
the end-of-year.
382 PART FOUE / SYSTEM IMPLEMENTATION
each entry is posted to the accounts payable debit file. Major reports
available are vendor listing, cash requirements, check register, hand
check register, accounts payable detail, and accounts payable aging.
Checks are printed automatically or entered manually, including detail
on the check stub. A complete audit trail is provided via the detail
journal listing feature of the general ledger module. A data flou^ diagram
of the proposed system is shovvTi in Exhibit 12-5.
Test Procedure
To package, a prototype test was conducted on the IBM/XT
test the
system in an attempt to reproduce a typical date in the accounts
payable department. A representative sample of data collected from the
firm included the following:
• Purchase orders.
• Invoices.
• Prepaid request purchase orders.
• Petty cash requests.
• Miscellaneous bills (advertising, rent, etc.).
• Packing lists.
• Receiving reports.
• Credit and debit memos.
• Monthly statements from vendors.
The master vendor list and all account balances were entered prior
to the prototype test. A large number of invoices was also entered into
the system so that each account would start with different amounts
payable.
Results
The average time required manually process each document was
to
determined and then compared with the
fixjm actual observations
amount of time required using the computer, which included deter-
mining the vendor key and waiting for files to be updated. The results
indicated a considerable time savings with the candidate system. Pay-
ing an invoice by computer required approximately two thirds of the
time required manually, mainly by eliminating the time spent filing and
searching.
Automatic computer generation of checks, wliich can be very time-
consuming when handled manually, was about 90 percent more time
eflBcient in the prototype test. Improvement in accuracy could be only
subjectively estimated. The p^kage allows the user to edit any errors
before the files are updated. No manual addition is required by the
clerical staff, which should automatically improve accuracy.
12 / SYSTEM TESTING AND QUALITY ASSUEANCE 383
I
PROFESSORS Orders
AND
CUSTOMERS and Purchases
Assignment
Most of the work performed in this case has been covered in earlier chapters.
Use this background to answer the following questions:
b. What test strategy would you use to test the system? Elxplain in detail.
c. What audit considerations should be looked into? How would one incorpo-
rate an audit traU? Be specific.
Selected References
Brooks, Cyril; Phillip Grouse; D. Ross Jeffery; and Michael J. Lawrence. Information
Systems Design. Englewood Cliffs, NJ.: I>rentice-Hall, 1982, pp. 366-71.
Brown, Foster. "Audit Control and Systems Design." Journal of Systems Manage-
ment, April 1975, pp. 24-31.
CeruDo, Michael J. "Controls for On-Une Recil-Time Computer Systems." (1) CA
Magazine, March 1980, pp. 58-61; (2) CA Magazine, May 1980, pp. 54-58.
Couger, J. Daniel. The Art of Software Testing. New Yoric: John Wiley &. Sons, 1979.
Dolan, Kathleen. Business Computer Systems Design. Santa Cruz, Calif.: Mitchel
Publishing, 1984, pp. 302-305.
Foss, W. B. "A Structured Approach to Computer System Testing." Canadian
Datasystems, September 1977, pp. 28-32.
Harrison, Warren. 'Testing Strategy." Journal of Systems Management, May 1981,
pp. 34-37.
Holley, Charies L., and Frederick Millar. Auditing the On-Line, Real-Time Computer
System." Journal of Systems Management, January 1983, pp. 14-19.
Jeffries, Kenneth R. "Auditing Advanced EDP Systems —
The Problems StUl Exist."
The National Public Accountant, July 1981, pp. 16-21.
Myers, Glenford J. The Art of Software Testing. New York: Wiley Interscience, 1979.
Ogdin, Carole A. "Software Aids for Debugging." Mini-Micro Systems, July 1980,
pp. 115-20.
Smolenski, Robert J. "Test Plan Development." Journal of Systems Management,
Februaiy 1981, pp. 32-37.
-C'
Chapter 13
Implementation and
Software Maintenance
Introduction
Conversion
ACTIVnT NETWORK FOE CONVERSION
File Conversion
Creating Test Files
Data Entry and Audit Control
User Training
Elements User Training
ol
Training Aids
Forms and Displays Conversion
Conversion of Physical Facilities
Conversion of Administrative Procedures
Post-Implementation Review
38^
.
At a Glance
A crucial phase in the systems lite cycle is the successful implementation of the
new system design. Implementation simply means converting a new system
design into operation. This involves creating computer-compatible files, train-
ing the operating staff, and installing hardware, terminals, and telecom-
munications network (where necessary) before the system is up and running. A
critical factor in conversion is not disrupting the functioning of the organization.
In system implementation, user training is crucial for minimizing resistance
to change and giving the new system a chance to prove its worth. Training
aids, such as user-friendly manuals, a data dictionary, job performance aids
that communicate information about the new system, and "help" screens,
provide the user with a good start on the new system.
Following conversion, it is desirable to review the performance of the
system and to evaluate it against established criteria. Software maintenance
follows conversion to the extent that changes are necessary to maintain satis-
factory operation relative to changes in the user's environment. Maintenance
often includes minor enhancements or corrections to problems that surface
late in the system's operation.
Software Maintenance
MAINTENANCE OR ENHANCEMENT?
PRIMARY ACTIVITIES OF A MAINTENANCE PROCEDURE
REDUCING MAINTENANCE COSTS
388 PAST FODS / SYSTEM IMW.KMENTATION
DTTRODUCnOH
An important aspect of a systems analyst's job is to make sure that the new
design is implemented to established standards. The term implementation
has different meanings, ranging bnm the conversion of a basic application
to a complete replacement of a computer system. The procedure, however,
is virtually the same. Implementation is used here to mean the process of
CONVERSION
Conversion means changing bx>m one system to another. The objective is to
put the tested system into operation while holding costs, risks, and person-
nel irritation to a minimum. It involves (1) creating computer-compatible
files, (2) training the operating staff, and (3) installing terminals and hard-
2. The user solicits help fix)m the anafyst, who does an $8,000 study that
leads to a proposal.
3. The proposal has general sjjecifications of software and hardware. A
vendor is selected cind a firm conversion date is set.
4. The vendor or the project team begins to fit its solution to the user's
specification.
7. With a combination of poor training and tight deadlines, the user staff
grows short-tempered at being in an untenable fjosition.
8. Now the user isangry at the project team or the vendor, and the
vendor's staff is getting impatient with the user staff. Everyone is blam-
ing everyone else for this horrible experience.
For many first-time users, this theme is famifiar. What went wrong? Tlie
fundamental concerns lie with the user, who should know in advance what
acti\ities to control through a computer. Users who do not do their home-
woric play right into the hands of vendors who have done theirs. So it is
understandable that conversions are often a fiasco.
1. Conversion begins v\ith a review of the pnaject plan, the system test
documentation, and the implementation plan. The parties involved are
the user, the project team, programmers, and ofjerators.
2. The conversion portion of the implementation plan is finalized and
approved.
3. Files are converted.
4. Parallel processing between the existing and the new systems is initi-
ated.
Results of computer runs and operations for the new system are logged
on a special form.
Project
plan
System test
documentation
Implementation
I plan
Yes Diagnose
<^discrepancies and correct
discrepancies
Conversion portion f No 1
of implementation \ '
plan finalized
Implementation Discontinue
I results
parallel
processing
Perform file
conversion f \
Implementation Complete
documentation conversion
Perform
parallel
processing 1
Log results
of conversion
W
Accompanying the procedures are activities that are unique to conver-
sion (see Figure 13-2). Before we discuss each activity, we need to note that
during the transition, the user should be discouraged ftxjm making changes
or enhancements. To illustrate, a Miami-based commercial bank contracted
to convert to a real-time teller system vvdth neu' terminals linked to a
computer service. Forty-eight days were spent testing the software, termi-
nals, controllers, and other features. TWo weeks before the final conversion,
it was found that when the system u^as dovm, the terminals lost all the
Train personnel
C02
Convert
Coi
files Complete conversion
C06 o END
C04
COS
File Conversion
Fileconversion involves capturing data and creating a computer file
irom existing files. Problems are staff shortages for loading data and the
specialized training necessary to prepare records in accordance with the
new system specifications. In most cases, the vendor's staff or an outside
agency performs this function for a flat fee.
Copying the "old" files intact for the new system is the prime concern
during conversion. The programs that copy the files should pixiduce identi-
cal files to test programs on both systems. At the outset, a decision is made
to determine which files need copying. Personnel files must be kept, of
course, but an accounts receivable file with many activities might not need
copying. Instead, new customer accounts might be put on the new system,
while running out the old accounts on the old system.
Once it is determined that a particular file should be transferred, the
next step is to specify the data to be converted: current files, year-end files,
and so on. The files to be copied must be identified by name, the program-
mer who will do the copying, and the methods by which the accuracy of the
copying will be verified. A file-comparison program is best used for this
purpose.
Creating Test Files. The best method for gaining control of the
conversion is to use well -planned test files for testing cdl new programs.
Before production files are used to test live data, test files must be created
on the old system, copied over to the new system, and used for the initial
test of each program. The test file should offer the following:
1. Predictable results.
2. Previously determined output results to check with a sampling of
different types of records.
Selecting the right records for testing not easy. The user's key staff
is
should get involved in the selection process. The trick is to select a reason-
able number of uncompUcated records and also records that have caused
problems in the past.
What about security? No user wants employee salaries printed for all to
see. Information such as salary, ethnic background, and trade secrets must
be altered so that test file results can be read by the programmer, the
project leader, and other involved in the conversion wdthout compromise.
A good test file should show how the new system handles the most
difBcult tasks. A health insurance test file, for instance, would include an
employee with eveiy possible type of insurance: worker's compensation,
disabifity, dental, cancer, life, and accident insurance. If the new^ system
programs process this file correctly, it is likely to handle the ordinary
employee's insurance.
Data Entry and Audit Control. Many systems are prone to errors
because of insufficient attention given to data entry control or protective
features such as audit control trails. These items must be part of the overall
plan for conversion. Before a data entry cleric begins to enter changes to
items in the files, the count of the number of documents to be keyed in
should be entered. The data entry program should be designed so that
these summary totals are entered first, with the computer keeping a run-
ning count of the items entered.
A good audit control trail is the key to detecting fraud and mistakes that
might indicate problem entries. At a minimum, the user should have a copy
of the additions or deletions to any file. There should be a daily computer-
printed entry list with entries and totals before they are entered and a
second list showing actual changes after they have been made in the file(s).
To detect fi^ud, many system designs do not allow any records on the file to
be deleted easily. Modifications are made by adjustments involving more
than one or two operating personnel or similar routines. Preventing records
from being deleted makes it more difficult to cover up problems or conceal
fi^ud.
User Training
An analysis of user training focuses on user capabilities and
t^vo factors:
the nature of the system being installed. Users range from the naive to the
highly sophisticated. Developmental research provides interesting insights
into how naive computer users think about their first exposure to a new
system. They approach it as concrete learners, learning how to use the
system without trying to understand which abstract principles determine
13 / Il£FLEIiENTAIK»< AND SC»TWASE ICAINTENANCE 393
Phase 1: The initial training period Only one of the four clerks read the
manual. Instead, the clerks took notes on legal paper, listed the key func-
tions, and described how they are used on the PC. The list was referred to
continually. The clerk who read the manual became the resident e^cpert by
bailing every other clerk out of a jam. During the training p>eriod, most of the
questions asked had answers in the manual. The most fiiequently consulted
reference was that sheet of paper with the key functions and the name and
phone number of the analyst.
Phase 2: Two months None of the three clerks had read the manual.
later.
A six-page update of the manual fiDm the software house had not even been
filed. In fact, tw^o of the clerks had misplaced their copies. Fewer questions
w^re not posed to the analyst out of embarrassment. The questions were
answered somehow^ within the group. The list of functions from the initial
training period w^as beginning to show^ age fiDm r^ular use. No one both-
394 PAET FOUK / SYSTEM IMPLEMENTATION
ered to type it or make backup copies in case it is lost. Worse yet, clerks who
did not understcind a function made no effort to look it up in the manual as
long as it did not affect their job.
Phase 3: Sqc months Training \vas by the resident expert word of
later. —
mouth and a quick two-hour "show^ and tell" approach to generating
reports for billing purposes. The imalyst did not get one call. General
functions were deleted or chcmged so that the manual was no longer up to
date.
1. Users are reluctant to read meuiuals, but they will leam from demon-
strations and through visual aids. Users also tend to be natural teachers. For
many mostly informal. There is no question that some
users, training is
must good question. Let me follow up on that and I'U let you
say, "That's a
know tomorrow, you are not ready to handle a demonstration. A rule of
"
ple,one clerk read the manual spent time on her own to practice,
carefully,
—
and ended up being the resident expert a natural teacher. Such a person,
whether a respected supervisor or a peer, c£in relate much better to the user
group, speak the language, and use examples based on common experience
to teach (and sell) the new system. Training in this case is more rapid,
which means a quicker use of the system on a regular basis.
tions available to the user and what each can do, how they are executed,
and how diagnostic messages should be handled. Above all, the manual
should be well organized and indexed for quick reference. Graphics, pic-
tures, and line drawings enhance the teaching \'alue of the material.
selects a "help" option Irom a menu. The system accesses the necessary
description or information for user reference. Then additional "help" infor-
mation may be accessed, or the user returns to the menu for further action.
HELP advantage of virtually unlimited space and, since it
offers the is
separate from the program, it does not interfere with system operation.
3. Data dictionary. As explained in Chapter 9, a data dictionary is a
separate place for describing data elements. It is more like an electronic
"one-page" sheet available to the user to assure that functions are inter-
preted and executed properly.
4. Job aids. A job aid communicates essential information about certain
jobs. It takes a number of forms, for example:
It can be seen, then, that training aids help communicate vital informa-
tion about the new system. To make these aids useful, it is important to
consider to whom, when, and why the user will be communicating this
information.
inventory, and balance the books before she leaves for home. One spring
day, the main door opened. A husky fellow unloaded a personal computer
from the van and set it on Hazel's desk. Hazel first refiased to allow the boxes
in the office. She even refused to sign the delivery notice. Later, when the
computer store representative came to set up the system, she refused to
allow him use the
to bathroom. He had to go to
the Dunkin Donut facilities
next door. Her boss arrived at the scene. All we know is that he left to go
home sick udthin 20 minutes.
This scenario might be somewhat exaggerated, but it exemplifies what
might happen when a new system arrives and the user staff is ill prepared
to meet the challenge. Frequently, behavioral factors are overlooked in
system implementation. Change is accompanied by anxiety and other
stresses, which induce resistance. Any type of change imposes stress on the
people affected by it. According to Holmes and Rahe, after death of a
spouse, which they placed highest at 100, changes in job responsibiUties as
are common in system changes, are located on a scale of 30.^ This implies
that system changes ccin produce stress which increases unless checked
through planning.
Anxiety is produced when a person does not know the outcome of an
induced change:
These are general but there are also specific problems associ-
effects,
ated with resistance to a new installation. For example, the introduction of
the new system has an adverse effect on employee productivity and job
satisfaction. It may create an environment of hostility that lasts a long time
after implementation. Employees may even sabotage the system to seek
relief because they are unable to understand its operation. All these prob-
lems stem from inadequate communication between the user staff and the
project team, attitudinal factors, or perceptions that the new system inade-
quately meets the user's requirements.
Several strategies reduce resistance to system change:
POST-IMPLEMENTATION REVIEW *
Operational systems are quickly taken for granted. Every system requires
periodic evaluation after implementation. A post-implementation review
measures the system's performance against predefined requirements. Un-
likesystem testing, which determines where the system fails so that the
necessary adjustments can be made, a post-implementation review deter-
13 / IMPLEMENTATION AND SOFTWARE MAINTENANCE 399
A Review Plan
The review team prepares a formal review plan around the objective(s) of
the review, the type of evaluation to be carried out, and the time schedule
required. An overall plan covers the following areas (see Figure 13-5):
Review perforrnance
Develop hardware plan ^/'-s^ specifications
R050 R110
Once drafted, the review should be verified and approved by the requester
or the end user.
AdmlnlstrotlTe Plan
The review group probes the effect of the operational system on the
administrative procedures of the user. The following activities are reviewed:
that over time either the system fails to meet the user's initial objectives
or the user objectives change as a reflection of changes in the organiza-
tional objectives. We need to think in terms of problems and of further
opportunities. The results of the evaluation are documented for future
reference.
2. Operating costs and benefits. Under the administrative plan, the cost
structure of the system is closely reviewed. This includes a review of all
costs and savings, a review and update of the noncost benefits of the
system, and a current budget designed to manipulate the costs and
savings of the system.
Hardware Plan
The hardware of the new system is also reviewed, including terminals,
CRT screens, software programs, and the communication network. The
primary tai^et a comparison of current performance specifications with
is
Development
cost
SOFTWARE MAINTENANCE
Maintenance is the enigma of system development.
holds the software
It
7. Programs are often maintained without care for structure and docu-
mentation.
8. There are minimal standards for maintenance.
9. Programmers expect that they uall not be in their current commitment
by the time their programs go into the maintenance cycle.
Most programmers view maintenance as low-level drudgery. After they
develop an application, they spend years locked into maintaining it. Even-
tually, boredom sets in, with subsequent turnover and loss of expertise
necessary to maintain the system. It is obvious that the more carefully a
system is thought out and developed, with attention paid to external influ-
ence over a reasonable lifetime, the less maintenance will be required.
Maintenance or Enhancement?
Maintenance can be classified as corrective, adaptive, or perfective. Correc-
tive maintenance means repairing processing or performance failures or
making changes because of previously uncorrected problems or false cis-
sumptions. Adaptive maintenance means changing the program function.
Perfective maintenance means enhancing the performance or modifying the
pixigramls) to respond to the user's additional or changing needs.^ Of these
types, more time and money are spent on perfective than on corrective and
adaptive mmntenance together.
Request for
systems
service
System and
Request system Submit test
program
and program results for
documentation
documentation user approval
Specify Modification
required requirements
modifications
'
^
'
'
Make required
changes to
programs and
systems
Test
changes
T
\X
Summary
1. Implementation is the process of converting a new system design into
operation. Conversion entails several steps:
a. Review the project plan, test documentation, and implementation
plcin.
b. Convert the files.
2. The prime concern during conversion is copying the old files to the new
system. Once a particular file is selected, the next step is to specify the
data to be converted. A file comparison program is best used for verify-
ing the accuracy of the copying process.
3. Well-planned test files are important for successful conversion. A test
file should contain predictable results, simplified error-finding routines,
and printed results in seconds. It should also show how the new
system handles the most difficult tasks.
4. A good audit trail is the key to detecting errors and fraud in a new
system. To detect fraud, many system designs do not allow the easy
delection of any recorxls on the file. This feature makes it difficult to
cover up problems or conceal fi^aud.
6. During user training, the resident expert emerges. He/she is the one
who probably has the most interest in the system, works the hardest to
learn it, and consequently benefits from the unique r^ole of being an
"expert" in the group.
7. Experience in user training suggests that:
a. Users are reluctant to read manuals but leai'n well fi'om demonstra-
tions and visual aids.
b. Users tend to be natural teachers.
c. The resident expert is a natur'al trainer, since he/she speaks the user
grDup's language and uses samples based on common experience
to teach the new system.
8. The primary teaching aids in user training are the user manual, "help"
screens, data dictionary,and job perfomiance aids. The tools and
procedures are designed to minimize the user's resistance to change
and motivate the user staff to adopt a constructive attitude for full
utilization of the new system.
9. The post-implementation review has the objective of evaluating the
system in terms of how well performance meets stated objectives. The
study begins with the review team, which gather-s requests for evalua-
tion. The team prepares a rx3\iew plan ar-ound the type of evaluation to
be done and the time frame for" its completion. The plan considers
administrative, personnel, and system performance and the changes
that are likely to t£ike place thrxDugh maintenance.
Key Words
Conversion Mean Time between Failure (MTBF)
Enhancement Post-implementation Review
Implementation Resident Expert
Maintenance
Review GLuestions
1. What is implementation? How does it differ from conversion? Elaborate.
2. The chapter suggests that conversion has been chaotic and traumatic
for many firms. Do you agree? Contact a local firm with a computer
faciMty and discuss the extent to which the statement is true.
6. "A good test file should show how the new system handles the most
difiRcult tasks." Do you agree? Discuss.
7. What is the role of the audit control trail in conversion? Who performs
it? Explain.
8. Suppose you were asked to prepare a plan for training the user staff on
a newly acquired microcomputer system.
a. What factorsdo you consider in preparing the plan?
b. How would you design the plan?
c. What objective! s) are considered as a basis for the plan?
9. If new system design is likely to meet user specifications, why do users
resist change? How would one reduce resistance to change? Explain in
detail.
Application Problems
even know that the parent company's warehouse system had a terminal
that used the mainframe to update inventory.
System testing was also a disaster. Only real data were used. The
resulting output was so unwieldy that no one could audit or verify its
accuracy until it was too late. With no interface between the system
being tested and the mainfi^ame, there was no way the files could be
copied. The consultant decided to go ahead with incoming data only
and to worry later about copying the files on the mainfi^ame.
Documentation and audit procedures wei^ virtually nonexistent.
No one seemed to know who changed what. Thei^ was no way of telling
whether errors vv^ere caused by the software or by incorrectly entered
data.
The contract was well written. It simply committed the consultant
to install a computer system and the compciny to pay the consultant
$75 per hour plus out-of-pocket expenses. The consultant never really
knew what the company wanted, and the company had no one to work
with the consultant. The employees stayed out of the ways, since they
had not been consulted and were not knowledgeable about computers.
The programmers, in their opinions, were simply obnoxious. Another
consultcint vvlio came in to evaluate the mess thought the uiiole in-
stallation was primitive and lacked state-of-the-ail software.
The company continued operating after its employees volunteered
hours of their time to maintain accurate records by hand. The outcome
was an out-of-court settlement. The company dreaded costly litigation.
The consultant decided to cut his losses and protect future business.
Assignment
a. What went wnrong in this case? Be specific.
ever, there is a culture gap. Sales personnel know very little about
computers and consider themselves independent of operations. Opera-
tions personnel,' on the other hand, have used first-generation comput-
erized order processing. They consider themselves psychologically
isolated from sales, since they are located in the back room and take
orders by mail.
staff was not eager to partici-
This gap had to be bridged. The sales
pate. The question was: What should management do to implement the
system? Earlier attempts uathin the organization at changing employ-
ees' attitudes have been largely ineffective.
Assignment
Develop a workshop to do the following:
The stock orders of a large appliance store are kept in a card index. We
need to convert them into a magnetic tape file.
Assignment
a. What steps are required in the conversion?
A new online teller system design for a medium-size bank was approved
by the president, signaling the beginning of implementation. The pro-
ject leaderdevised a master plan to specify who is to perform each task
and in what order. New deposit and withdrawal slips were ordered and
delivered three weeks before implementation. In the interim, copies of
the user manned were pi-epai'ed for the lobby and drive-in tellers.
Soon after the terminals were installed, the tellers began to learn
how to enter various transactions. After training sessions were over,
they had a chance to ask questions and inquire about the new system.
13 / IMPLEMENTATION AND SOFTWARE MAINTENANCE 411
system was now in operation and all user requii-ements had been met.
Three weeks later, the analyst was called to the board meeting. The
chairman criticized the analyst for exceeding the budgeted amount
appro\'ed by the board. Furthermore, the authorization the analyst gave
the terminal \'endor to bring in two CRT screens to expedite informa-
tion I'etrieval exceeded his authority to implement the system. The
bank's auditor also estimated it would take 3.8 years rather than the
initial estimate of 2.1 years to break even on the total cost of the
installation. Not knowing what to say, the analyst left the board room
with a feeling of total failure.
Assignment
a. What are the major problems in the case? Who is to blame? Why?
b. Was the board chairman justified in his criticism of the analyst? Explain.
It is now June 1, well into the ofiF-season for tourism. Assume that
hardware and softwtire are available within 60 days. It will take one
week to test and instcill the system and one week to train the stockroom
clerks. Loading the entire invent oiy is estimated to take about 1.5 weeks.
Assignment
a. Use a bar chiirt or a Gcintt chart to show the sequence of activities (by week).
b. When should the firm sign a contract to implement the system? Why?
Discuss.
Conversion Procedure
Ejccept for the installation of hardware, the main problem faced in
the implementation of the accounts payable system w^as the user's staff.
Changes in personnel, orientation to the new system, training, and file
conversions were problems encountered soon after testing. The in-
st2illation of the software package was strai^tforward. At the accounts
payable depjartment, employees were assured that no one would be
replaced by the system. The system eventually would allow the depart-
ment to grow; thus, new^ employees would be needed as the store
expanded.
The orientation of present employees to the new system was impor-
tant. Some employees had a positive attitude and looked forward to the
benefits of the system; others had a negative attitude, fearing loss of job
or intimidation by the computer.
After selling the system, the next step was personnel training. The
computer store worked with the user's staff and trained them in com-
puter operation and use of the piackage. The Guide to Setting Up book
and the Reference Manual were quite informative and user-fiiendly.
The next task was file conversion. This step encompassed transfer
of manual records (invoices, packing lists, and purchase orders) onto
diskettes. The job required extra help on a temporary basis and took
three weeks to complete.
The final component was piaraDel operation, using both systems
simultaneously. The time and effort in this step were enormous, be-
cause everything had to be processed twice, once by the computer and
once by hand. The parallel operation continued until a fiill cycle of the
business was completed six months. —
13 / IMPLEMENTATION AND SOFTWAEE MAINTENANCE 413
Assignment
a. Evaluate the implementation procedure.
Selected References
Agresti, William W. "Managing Program Maintenance." Journal of Systems Manage-
ment, February 1982, pp. 34-37.
Bronsema, Gloria S., and Peter G. W. Keen. "Education before Change in Systems
Ha rd wa re/Soft wa re
Selection
and the Computer
Contract
Introduction
SOFTWARE SUPPLIERS
SERVICE SUPPLIERS
414
At a Glance
SOFTWARE SELECTION
Criteria for Software Selection
CONTRACT CHECKLIST
Responsibilities and Remedies
"-.
W
416 PACT FOUR / SYSTEM IMPLEMENTATION
INTRODUCTION
A major element in building systems is hardware and
selecting compatible
software. The systems analyst has to determine what software package is
best for the candidate system and, where software is not an issue, the kind
of hardware cind peripherals needed for the final conversion. To do the job
well, the analyst must be familiar with the computer industry in general,
what various computers can and cannot do, whether to purchase or lease a
system, the vendors and their outlets, and the selection procedure.
Hardwcire/software selection begins with requirements analysis, fol-
lowed by a request for proposal and vendor evaluation. The final system
selection initiates contract negotiations. It includes purchase price, mainte-
ncince agreements, and the amount of updating or enhancements to be
available by the vendor over the life of the system. Contract negotiations,
seemingly too legal for an analyst, require finesse and strategies designed to
get the best deal for the user and protect the user's interests in the acquired
system. This chapter focuses on these elements and provides background
on the makeup and ramifications of softwcire and hardware selection.
Hardware Suppliers
This group includes mainfi'ame manufacturers, peripheral vendors, sup-
plies vendors, computer leasing firms, and used systems dealers. IBM is the
major supplier of mainlrame computers. In microcomputers, IBM, Apple,
and Tandy Corporations top the list.
Peripheral manufacturers supply tape drives, disk and diskette drives,
printers, and other components. Vendors of supplies provide consumable
supplies such as diskettes and printer forms and nonconsumable supplies
such as disk packs, tape reels, tape library shelves, and fireproof vaults.
Hundreds of independent vendors are in this field. Used computer dealers
purchase secondhand equipment from computer users, rebuild them, and
sell them at attractive prices. Computer leasing firms generally finance
hardware and software acquisition. Leasing companies may also under-
write or insure the development of a computer system. The acquisition of
used computers is discussed later in the chapter.
Software Suppliers
In today's market, 17,000 firms ofier more than 5,000 systems and applica-
tions. In the microcomputer area, over 30,000 softWcire packages £ire avail-
14 / HABDWASE/SOFTWAfiE SELECTION AND THE COMPUTES CONTKACT 417
able. Computer users Ccin acquire programs frx)m either the \endor or the
software house for virtually every application imaginable. Prices from a
\'ar\'
Service Suppliers
Outside computer senices are commonly used by small firms or first-time
users. Also called servicers, they include the following:
The FM
concept has several benefits. The user pays only for the service
rendered. Turnover problems for the user are eliminated when the servicer
manages the center. The main drawbacks, however, are loss of contixjl over
the operation, vulnerability of information, and the high fees charged for the
service.
Types of Software
' Daniel Couger, "Development to Facilitate Managerial Use of the Computer," Computing
Newsletter, no. 8 (April 1983), pp 2-4.
14 / HARDWARE/SOFTWAKE SELECTION AND THE COMPUTER CONTRACT 419
~ Alan M. Hoffbei^, "Getting Hardnosed about Software," Infosystems, July 1981, p. 37ff.
3 Ibid., p. 27.
420 PAKT FOUK / SYSTEM IMPLEMENTATION
2. Specify the magnitude of the problem, that is, clarify whether selection
entails a few peripherals or a major decision concerning the mainframe.
3. Assess the competence of the in-house staff. This involves determining
the expertise needed in areas such as telecommunications and data
base design. Acquiring a computer often results in securing temporary
help for conversion. Planning for this step is extremely important.
4. Consider hcirdware and software as a package. This approach ensures
compatibility. In fact, software should be considered first, because often
the user secures the hardware and then wonders what software is
available for it. Remember that software solves problems and hardware
drives the software to facilitate solutions.
14 / HARDWAKE/SOFTWARE SELECTION AND THE COMPUTER CONTRACT 421
1. Requirements analysis.
2. System specifications.
3. Request for proposal (RFP).
4. Evaluation and validation.
5. Vendor selection.
6. Post-installation review.
// Requirements Analysis
The first step in selection
understanding the user's requirements
is
;i
. System Specifications
Failure to specify system requirements before the final selection almost
always results in a faulty acquisition. The specifications should delineate
the user's requirements and allow room for bids ftx)m various vendors. They
must reflect the actual applications to be handled by the system and
include system objectives, flowcharts, input-output requirements, file struc-
ture, and cost. The specifications must also describe each aspect of the
system clearly, consistently, and completely.
vendors for bidding. Bids submitted are based on discussions with vendors.
At a minimum, the RFP should include the following:
H'
Evaluation and Validation
The evaluation phase ranks vendor proposals and determines the one
best suited to the user's needs. It looks into items such as price, availability,
and technical support. System validation ensures that the vendor can, in
fact, match his her claims, especialh' system performance. True validation is
verified by ha\ing each system demonstrated.
Vendor Selection
This step determines the "winner" — the vendor with the best combina-
tion of reputation, reliability, service record, training, delix'erv' time, lease/
finance terms, and conversion schedule. Initially, a decision is made on
6 , Post-Installation Review
Sometime cifter system evaluation is made to
the package is installed, a
determine how closely the new^ system conforms to plan. System specifica-
tions and user requirements are audited to pinpoint and correct any differ-
ences.
Software Selection
Software selection is a critical aspect of system development. As mentioned
earlier, the search starts wdth the software, followed by the haixiwcire. There
are two ways of acquiring software: custom-made or "off-the-shelf' pack-
ages. Today's trend is toward purchasing packages, which represent
roughly 10 percent of what is costs to develop the same in house. In
addition to reduced cost, there are other advantages:
1. A good package can get the system running in a matter of days rather
than the weeks or months required for 'home-grown" packages.
424 PART FODB / SYSTEM IMPLEMENTATION
7. The user has a chance of seeing how well the package performs before
purchasing it.
specified time period wdthout a failure, weighted by the cost to the user of
each failure encountered. It relates to the ease of recovery and ability to give
consistent results. Reliability is particularly important to the professional
user. For excimple, a pharmacist relies on past files on patients when filling
prescriptions. Information accuracy is crucial.
Hardware may become inoperative because of design errors, manufac-
turing errors, or deterioration caused by heat, humidity, friction, and the
like. In contreist, software does not fail or wear out. Any reliability problems
4. Are there errors a user can make that will bring down the system?
5. What are the recovery capabifities?^
1. Do the input transactions, files, and reports contain the necessary data
elements?
2. Are all the necessciry computations and processing performed accord-
ing to specifications?
Capacity.
Capacity refers to the capability of the software package to
handle the user's requirements for size of files, number of data elements,
volume of transactions and reports, and number of occurrences of data
elements. AU limitations should be checked.
Usability.
This criterion refers to the effort required to operate, pre-
pcire the input, and interpret the output of a progrcmi. Additional points to
be considered are portability and understandabiUty. Portability refers to the
ability of the softwcire to be used on different hardware jmd operating
systems. UnderstandabiUty means that the purpose of the product is clear
to the evaluator and that the package is clearly and simply written, is fi^e of
"•
Jan Snyders, "How to Buy Packages," Computer Decisions, July 1978, p. 52.
5 Craig Johannsen, "Software Selection," Computerworld, Januaiy 1979, p. 33
426 PART FOUR / SYSTEM IMPLEMENTATION
that the source code is inaccessible for modification, except by the vendor.
Many usei-s enter into an escrow arrangement whereby the vendor deposits
the source code with a third-party escrow agent who agrees to release the
code to the user if the vendor goes out of business or is unable to perform
the services specified in the license.
In acquiring software, several questions should be asked:
2. Delivery schedule.
or how much expertise is available for the evaluation phase. The first step is
to look at the criteria listed earlier and rank them in order of importance.
Mandatory and desirable features should be diff"erentiated. Since it is un-
likely that all user requirements can be met, concentration should be on
satisfying the primary requirements. The selection of appropriate software
becomes a matter of making intelligent compromises.
6 Ibid., p. 33.
428 PAKT FODB / SYSTEM IMPLEMENTAnON
The more elaborate the benchmaridng, the more costly is the evalua-
tion. The user's goals must be kept in perspective. Time constraints cdso
limit how thorough the testing process can be. There must be a compro-
mise on how much to test whUe stUl ensuring that the software (or hard-
ware) meets its functional criteria.
Since benchmarks only validate the vendor's claims, other sources of
information are necessary. The ejqyerience of other users with the same
system, software, or service is important. Vendors are generaUy willing to
provide a list of "reference accounts" or people with whom to check.
Elxperience shows that the users on such a list happen to be satisfied
customers and, therefore, are not typical users. Seeking objective users on
one's own can be finstrating, however. Even if the "ideal" user is located, the
information is useful only if the user had the same hardware configuration,
applications, and software.
An important step in the evaluation process is to read product reference
manuals that evaluate system capabiUties. Since such a search is often
laborious, one alternative is to contact organizations that publish reports
based on ongoing research and system testing in various sites. For example,
Auerbach, Inc. (Philadelphia), publishes looseleaf references on information
processing, telecommunications, and computer graphics. The reports elab-
orate on computer products, services, and prices. Considering the benefits
offiered, the cost is relatively low.
Evaluation of Proposals
Vendor bids should be reviewed not only to ensure that the information
is adequate, but also to determine whether it meets the requirements of the
user's RFP. Proposals that fail proposals have
the test are rejected. After all
been verified, the final vendor is selected by various approaches: (1) ad hoc,
(2) scoring or (3) cost-value approach.
''
J. Seaman, "Smart Benchmarking — the Key to Successful Procurement," Computer Deci-
sions, March 1981, pp 74-94.
a^j^'
14 / HARDWARE/SOFTWARE SELECTION AND THE COMPUTER CONTRACT 429
when the user is known to favor a particular vendor from the outset.
In the scoring approach, the characteristics of each system are listed
and given a score in relation to a maximum point rating. Then each pro-
posal is rated according to the characteristics. Figure 14-4 rates three
proposals according to uniform computer and \'endor exaluation factors.
Proposal B has the most points for the total performance score and would
be the user's first choice.
With the cosf value approach, a dollar credit amount is applied to the
proposal that best meets the user's desirable characteristics. This credit is
subtracted from the vendor's quoted price. The proposal with the lowest
price is the one selected. To illustrate, assume that the vendor's response
for repair is a key criterion. The cost value of a quick response is determined
by estimating the cost of hiring additional help to do the required work
manually while the system is waiting for service. This amount depends on
how quickly the vendor responds to senice. Suppose that when the com-
puter is down for a whole day, there is an additional expense of SI, 000.
Three breakdowns in a year would total $3,000. Eliminating downtime
through quick response to service is a credit for the vendor. After appropri-
ate credits (or penalties) are assigned, the total cost of each system is
computed. The system with the lowest cost is selected.
Propo.sals
Elements A B C
CPU
Arithmetic 3 4 1
Communication capabUity 20 15 10
En\'ironmental requirements 1 5 4
Input/output capabilitv' 4 9 2
Mcdn memory capacity 14 10 12
Multiprogramming capability 3 9 2
Secondary storage capacity 16 21 11
Word size 19 20 14
Subtotal 80 93 56
Vendor
Deli\'eiy time 10 5 12
Maintenance chai^ges 18 20 21
Number installed to date 2 11 6
Performance record 6 9 8
Qucdity of service 9 9 5
Training 5 10 /
Subtotal 50 64 59
Performance Evaluation
Evaluating a system includes the hardware and software as a unit.
Hardware selection requires an analysis of several performance categories:
monthly pavment, usually for one year or less. The contract can be termi-
nated without penalty by a 90-day a^ance notice. Rental charges are based
on 176 usage hours (8 hours per day x 22 woi^king days) per month.
Additional usage means higher total charges per month. Computer users
favor renting a system for three reasons:
14 / HARDWARE/SOFTWARE SELECTION AND THE COMPUTER CONTRACT 431
charge.
2. There is financial leverage for the user. With no investment in equip-
ment, user capital is freed for other pixjjects. Futhemiore, rental charges
are tax deductible.
The primary drawback of a rental contract is its high cost because of the
uncertainty of rental revenues to the vendor.
1. Unless there is a purchase option, the lessee (user) loses residual rights
to the system when the lease expires.
support that are available under the lease or rental agreement. Compared
with renting or leasing, the key advantages of purchasing are:
2. Lower continuing cash outlays than those for a leased system due to
cash savings from depreciation and investment tax credit.^ If the equip-
ment is held for five years or more, a credit of 10 percent of the purchase
price is deducted ftx)m the organization's income tax.
3. A lower total cash outflow if the user keeps the system longer than five
years.
Each acquisition method has characteristics that are both common and
unique. A choice based on these facts meets the qualitative test only.
Quantitatively, an effective method is the net present value (NPV) approach.
As discussed in Chapter 8, it allows users to evaluate alternatives while
recognizing that a dollar received today is worth more than tomorrow's
dollar. A problem at the end of the chapter illustrates the usefulness of this
method.
* Therea limit on the amount of investment tax credit claimed that is tied to the tax
is
the year. The maximum is 100 percent of the first $25,000 of tax liability plus 85
liability for
percent of the tax liability that is greater than $25,000. See Wm. Hoffman and Eugene Willis,
1984 Annual Edition West's Federal Taction (St. Paul, Minn.: West Publishing).
" Tom Wolpert, "Why It Pays to Buy Used," Venture, August 1982, p. 12.
14 / HAEDWAEE/SOFTWAEE SELECTION AND THE COMPUTEB CONTEACT 433
Sales in theused computer market are well over $5 billion per year.
Indei>endent vendors have been successful in training operators and pro-
grammers to use the equipment. They generally rebuild used systems after
they have been acquired fixim the second user.
For stand-cilone s3/^tems, used computers are ideal for users with in-
house expertise who cire located in an area where technical support is
adequate, or who are assured of vendor support. Although the biggest
drawback to used computers is maintencince, this is readily available from
the vendor or independent service firms.
Used computers are acquired through dealers or end users. Most deal-
ers cire knowledgeable about the system they sell. The best bargain, how-
ever, is buying directly fixim the end user, provided there is a log that verifies
the maintencince record of the system. Checking the maintenance log will
reveal how reliable the system has been. The buyer must be sure that the
seller has clear title to the system. A qualified consultant can help.
In conclusion, there are savings fiDm acquiring used systems, and more
and more or^cinizations are going that route. Furthermore, it is an excellent
way to extend the useful life of the computer.
the contrary, every contract is negotiable to some extent. Large users often
spend weeks negotiating amenities and terms, using legal counsel or con-
sultants.
The primary law^ governing contracts is the law of contracts, although
contracts can be influenced by other laws, such as the Uniform Commercial
Code (UCC). Under the law^ of contracts, the formation of a contract requires
mutual assent (meeting of the minds) and consideration. Performance of a
contract is the fulfilling of the duties created by it.
Many users enter into contract negotiations at the mercy of the vendor, with
little preparation. Negotiating Timing is critical. Strategies must
is an art.^°
be planned and rehearsed. The leverage enjoyed by either party can change
during the course of the negotiations. Figure 14-5 iUustrates the negotiation
procedure. Part A represents the jxjorly prepared user, outmaneuvered
completely throughout the negotiations. Part B shows a relatively informed
user, but one who has a sense of urgency. The user's negotiating leverage
100%
Lessor (vendor)
A. Deficient
Lessee (user)
100%
B. Fair
Award Conclusion
100% Lessor
C. Good
Lessee
Award Conclusion
1. Use the "good guy" and 'bad guy" approach. The consultant is often
perceived as the bad guy, the user as the good guy. The consultant is
the "shrewd" negotiator, whereas the user is the compromiser.
2. Be prepared with alternatives at all times. It is a give-and-take approach.
3. Use trade-offs. Rank less important objectives high early in the negotia-
tions.
14 / HAKDWAfiE/SOFTWABE SELECTION AND THE COMPUTER CONTRACT 435
Contract Checklist
ble, and the goods are fit for the purposes they are intended. Because
warranties are desirable for customers, vendors include provisions relating
to them in agreements, thus suggesting that some warranty is made.
" David Myers, More Seen to Contracts Than Price, Deliveiy," Computerworld, November
14, 1983, p. 23!
<^r
14 / HAfiDWAKE/SOFTWAEE SELECTION AND THE COMPUTER CONTRACT 437
1. Minimum hours of usable time per day that — is, the amount of time of
computer operation before a shutdown.
2. Mean time between failures (MTBF) — the length of time the system will
run without breaking down.
3. Maximum time to repair — response time to repairing the system.
Negotiations have come a long way during the last decade. One reason
is the growing competition in the industry. one vendor utII not negotiate,
If
the chances are that five other vendors will. Another reason is that usere are
becoming more knowledgeable about computers and are unvvalling to be
taken in by a standard contract. Standard contracts are designed to protect
the vendor. They have been written by knowledgeable legal staff. When a
contract is not negotiated, the user is usually on the losing end. Various
items can and should be negotiated, if negotiations ai-e done properly, with
foresight, planning, and control, the user can not only get a fair contract but
also secure a fruitful relationship that will benefit both the user and the
vendor.
Summary
1. Computer vendors are classified as hardware, software, and service
suppliers. They provide mainframe, operating systems/application pro-
grams, and service, respectively.
2. Software is system software for controlling computer oper-
classified as
ations and application software for solving user-oriented problems. In
general, software allows concurrence of operation, resource and infor-
mation sharing, modularity, and multiplexed operation. It has grown by
leaps and bounds, especially since the birth of the microcomputer.
Programmer shortages, improved software performance, and econo-
mies of scale are other reasons for the growth of softw^are.
3. There are several things to do before selection:
a. Define system capabilities that make sense for the business.
b. Specify the magnitude of the problem.
c. Assess the competence of the in-house staff.
generally requires less time to install than in-house software. The major
drawback is occasional difficulty meeting user requirements.
The criteria for software selection are:
a. Reliability— gives consistent results.
b. Functionality — ftinctions standards.
to
c. Capacity — volume requirements.
satisfies
Flexibility— adapts changing needs.
to
Usability — user-friendly.
is
lower total cash outflow if the system is kept longer than five years. It
b. Remedies for failure to meet the deli\er\' schedule and failure of the
system to pass the user acceptance test.
c. Implied warranties regarding s\'stem or software performance.
d. Guarantee of reliability in terms of uptime, mean time between
failures, cind response time to repairs.
Key Words
Benchmark Portabilit\'
Review €luestions
1. How is the computer industry classified? Summarize.
2. Distinguish between the following:
a. Hardware and service suppliers.
b. Concurrence of operation and multiple.xed operation.
c. RFP and vendor proposal.
d. PortabilitN' and understandability.
3. V\'hat is the FM concept? Search the literature and write a report on the
current demand for FM service.
16. How is the scoring approach different ftxim the cost-value approach in
evaluating proposals? Illustrate.
17. Hardware selection requires the analysis of severed performance catego-
ries. For a first-time user of microcomputers, what category or catego-
18. There are three methods of acquisition. What are they? Elaborate on the
pros and cons of each method.
19 Under what circumstances would one consider buying a used com-
puter? What are the benefits and drawbacks to such an acquisition?
Discuss.
Application Problems
1 A county school system has been processing its payrtjU through a local
bank's computer center for over eight years. One morning in early June,
the school superintendent received a telephone call ftxjm the bank's
vice president with the bad news. The bank could no longer process the
school's payroll. He gave the school until December 31 to look for an
alternative.
The superintendent contacted a computer consultant with a re-
quest for a payroll service or an installation to be in operation by the
end of the year. The school had just acquired a IBM/XT, complete with a
letter-quality printer, color monitor, and operating system. The price
was $6,800. None of the superintendent's staff knew how the system
operates. No software was available either.
The consultant checked with several service bureaus. The charges
—
were virtually the same $0.75 per paycheck. This includes accumulat-
ing payroll data and preparing end-of-year withholding tax forms.
Payr"oll checks are prepared for all employees biweekly.
14 / HARDWARE/SOFTWARE SELECTION AND THE COMPUTER CONTRACT 441
Assignment
a. Should hardware be acquired before software? Why? Explain.
b. What are the unique features of this case? Elaborate.
Assignment
a. Which alternative (service bureau versus in house) would be the most
beneficicil?
b. Suppose the bank decided to go ahead and process its own applications.
Should it purchase or lease? What factors are considered in the choice?
Elaborate.
Selected References
Bigelow, R. P. "Is There Legal Protection for Software?" ICP Infosystems, March 1980,
p. 104ff.
Couger, Daniel. "Development to Facilitate Managerial Use of the Computer." Com-
puting Newsletter, no. 8 (April 1983), pp 2-4.
Dotto, Lydia, and Lawrence Briner. "The Soft Path, a Consumer's Guide." Canadian
Business, January 1983, pp. 49-80.
Gruenberger, Fred. "Making Friends with User-Friendly." Datamation, Januaiy 1981,
p. 108.
Haber, Lynn. "Negotiations Can Spell Out Successfiil Systems", ComputerwoHd,
November 21, 1983, p. 22fiF.
Holmes, Geoffrey. "Choosing the Ri^t Software Supplier." Accounting, April 1981,
pp. 67-68.
Johannsen, Craig. "Software Selection." Computerworld, January 1979, p. 33.
Lord, Ken. "Software Reviews." Desktop Computing, September 1983, pp. 72-76.
Myers, David. "More Seen to Contracts Than Price, Delivery." Coinputerworld,
November 14, 1983, p. 23.
Sanders, G. Larry; Paul Munter; and Donald O. Reed. "Selecting a Software Package."
Financial E^cecutive, September 1982, pp. 39-46.
Seaman, J. "Smart Benchmaridng —The Key to Successful Procurement." Computer
Decisions, March 1981, pp. 74-94.
Snyders, Jan. "How to Buy Packages." Computer Decisions, July 1978, p. 52.
Vargo, Paul M. "How to Minimize the Risk of Buying Inadequate Software." The
Practical Accountant, Miirch 1983, pp. 53-56.
Weidler, Gregory. "Purchase or Lease?" Journal of Systems Management, June 1976,
pp. 28-35.
Wolpert, Tom. "Why It Pays to Buy Used." Venture. August 1982, p. 12.
Chapter 15
Project Scheduling
and Software
Introduction
Project Organization
444
V,
At a Glance
The material covered so far has addressed the concepts, tools, and technology
lor building systems. Developing a system requires planning and coordinating
resources within a given time. More important, elective project management
is needed organize the available resources, schedule the events, establish
to
standards, and meet conversion deadlines.
A manager is expected to have managerial and technical skills
project
along with management support for system success. The tools available for
project planning are Gantt and PERT charts. More recently, project manage-
ment software that runs on the personal computer is making a contribution to
calculating events and determining the critical path of a project.
REPORTING STRUCTURE
MANAGEMENT STYLES
^ J
446 PAST FODE / SYSTEM IMPLEMENTATION
INTRODUCTION
The process of planning, designing, and implementing computer systems is
called a project. It is directed by a project manager who uses available
resources to produce systems for the organization. In large firms, instcilling
a system may tcike years and involve hundreds of people. Planning and
installing smaller projects on schedule also take time and require control
and coordination of resources. It takes an effective manager to organize the
available resources, schedule the events, establish standards, and complete
the project on time, within budget, and with successful results.
We need to take a close look at project management and its role in
system development. In this chapter, we focus on the planning and sched-
uling functions and on project estimating, organization, and control. Project
management is inherently a team The chapter
effort. also shows how
project managers are selected and teams are managed.
many reasons. Most project managers have experienced some of the prob-
lems illustrated in Figure 15-1. Of these problems, the following are es-
pecially critical:
Delays in
implementation
User's
'^^
^'
\&
of
involve
Sources
of
system PooTnotivat/on
Budget failure of
overruns P''°/ect teams
I
User's lack
^^ ^»'^' of
'&e
cooperation
J^ _C x®
""^i.
Included in this is pressure ftxjm users who require the systems depart-
ment to accept impractical tasks or deadlines. The result is rushed, com-
promised projects, contrary to good system development practices. A
further difficulty found in many organizations occurs when indixldual
departments acquire microcomputers without knowing about their re-
quirements or consulting with the centralized computer facility. The result
is often uncoordinated confusion that makes it difficult to plan or control
projects.
crucial during the initial (creative) ^hase of the project, whereas leadership
15 / PROJECT SCHEDULING AND SOFTWARE 449
is required throughout the life cycle of the project. Other job qualifications
include:
Most project managers are selected liDm the system staff. This means
they ha\'e experience in systems analysis and programming and a demon-
strated knowledge of the business at hand. An organization that is eager to
secure full user commitment to the success of the system might assign a
user as a pixjject manager. The advantages of this approach are a commit-
ment to project success through direct responsibility, improved user train-
ing, and a better grasp of legal, financial, and other effects of system
changes. The main drauiiack is possible conflict of the assignment with
existing line reporting relationships. Regardless of the source from which a
project manager is drawn, user commitment is essential for system success.
Planning Tools
Gantt Charts
Basic planning uses bar charts that show and the
project activities
cimount of time they vvdll take. This activity scheduling method was first
introduced in 1914 by Heniy L. Gantt as a redimentary aid to plot individual
tasks against time. The Gantt chart uses horizontal bars to show the dura-
tions of actions or tasks. The left end marks the beginning of the task, the
right end its finish. Earlier tasks appear in the upper left and later ones in
the lower right.
Figure 15-2 is a Gantt chart for a hypothetical boat-building project. The
project is to build a prototype of a new motorboat called Seacraft Yacht. The
heavy horizontal bars are activities, and the light horizontal bars are tasks.
Broken horizontal bars are estimated time delays or slack time. A task is a
specific job that can be assigned to one person to perform in a specific time.
A group of tasks makes up an activity, which ends in a milestone. In our
Gantt chcirt, designing the hull is a task, whereas signing the boat (requiring
three tasks) is an activity. A total of five activities are required for building
the prototype. The completion of each activity is a milestone, indicated by
an arrow.
In planning this project, several steps are undertaken:
1. Identify the activities and tasks in the stage. Each activity must be
identified to plan the completion date and allocate responsibilities among
members of the project team. In our example, there are five activities:
a. Design boat.
b. Purchase/test engine.
c. Make boat.
d. Test boat.
e. Prepare owner's manucil.
2. Determine the tasks for each activity and the estimated completion
times. Each activity is bi-oken «lovvn into severed tasks. In Figure 15-2,
designing the prototype involves three tasks: designing the hull, testing the
15 / PfiOJECT SCHEDULING AND SOFTWABE 451
Activity
1/8 1/15 1/22 1/29 2/5 2/12 2/19 2/26 3/5 3/12 3/19 3/26 4/2 4/9
code Activity/Task I ' I I I I I i I-
1 Design boat
1-1 design hull
1 .3 design interior
2 Purchase/Test ef>gine
2.1 purchase engine
2.2 test engine
3 Malceboat
3.1 assemble moW
3.2 pour fiberglass
4 Test boat
5.2 copyedrt
5 J print
Legend
hull, and designing the interior. They are estimated to take 10, 5, and 18
days, resf>ectively. The total (33) is the estimated time for the "design boat"
activity. In real-life applications, an allowance for contingencies is provided.
This is called slack time. Each project allows beween 5 and 25 f>ercent slack
time for completion.
3. Determine the total estimated time for each activity and obtain an
agreement to proceed. Figure 15-3 shows the number of days budgeted for
each activity and a 20 f>ercent activity contingency toward completion.
4. Plot activities on a Gantt and milestones are
chart. All activities, tasks,
drawn on the Gantt chart, with emphasis on simplicity and accuracy (see
Figure 15-2).
5. Review and record progress periodical^. "Hie actual amount of time
sfjent on each activity is recorded and compiared with the budgeted times.
As shown in Figure 15—4, the actual number of days spent on the three tasks
in designing the boat is 40 as budgeted. This procedure is applied to the
remaining activities of the prototyp>e stage. A summaiy of progress on the
project is sent to management for follow-up.
452 PART FOUE SYSTEM IMPLEMENTATION
'
/
/^
J
/u
Activity total 113 (
Contingency
23
(20°o)
Task/Milestone
Budgeted Actual Finish
days days date
Test hull 5 4
Design interior 18 22
Contingency (20%) 7
Reviewed by: 2
FIGURE 15-5
m I
Event )
Task y J
Activity Tasks
Hull design
Hull test
Design of interior
Engine purchase
Engine test
Mold assembly
Building boat
4 Boat test
5 Draft of manual
Copyediting draft
Printing of manual
depends on have been completed. PERT does not allow "looping back"
because a routine that goes back to a task does not end.
The list of tasks and events is networked in a PERT chart in Figure 15-6.
The arrow length is not significant, but the sequence and interconnections
must give a true picture of the precedence of activities to be completed. The
numbers on the activity lines are the days required between events (see
Figure 15-2).
A PERT chart is valuable when being planned. When the
a project is
networic is finished, the next step is to determine the critical path. It is the
longest path through the network. No task on the critical path can be held
up without delaying the start of the next tasks and, ultimately, the comple-
tion of the project. So the critical path determines the project completion
date. In our example, it is:
Critical path = Start #-1-2 -3-4 -12 -6 -8
Duration (days) 10 + 5 + 18 + 11 + 50 + 10 = 104 days
Ifthe job started on January 1, then the completion date would be April 14.
Any delay in the criticcil path will affect the schedule. A delay in other paths
can be corrected in time for completion of the project on schedule.
In addition to showing the interrelationships among project activities,
PERT charts show the following:
task 3 (design boat interior) cannot begin until after tasks 1 and 2 (design
64 ^^^V?v^
Write10 r( Print
Assemble
mold draft ^-^
86
Copyedit
15 / PKOJECT SCHEDULING AND SOFTWAfiE 455
To calculate the earliest event times (£ ) for each event j, we use the
following algorithm:
2. Set Ej = Max,(£, + f •
), where maximization occurs over all events / that
are immediate predecessors of event j.
Let us use Figure 15-6 to illustrate: In the PERT chart, the values of E
cire shown next toeach event. Event 1 is labeled with time as the stcirting
time. Event 2 is labeled with time + 10 = 10 by summing the time of event
1 and the activity time fixam event 1 to event 2. The values of £ for the critical
path are summarized in Figure 15-7. Note that the value of event 6 (£g) is the
higher value of predecessor events 4-6 and 5-6, wliich is 44. The same logic
applies to event 12. The earliest occurrence time for event 12 is 104. Since it
is the last event in the netw^ork, the eariiest completion time of the project is
104 days.
In network Ccilculations, a backward pass is also made to determine the
latest time each event can begin without delaying the completion of the
project. The algorithm is:
To calculate, we begin with the last event in the network and work
r "N
456 PAST FOUE STSTEM IMPLEMENTATION
E\ent
Number Rule and \'alue
1 £, =
2 £, = £i + t,, = + 10 = 10
3 Eg = £, + ^23 = 10 + 5 = 15
4 £4 = £3 + r„ = 15 - 18 = 33
5 £5 = £3 + r35 = 15 ^ 3 = 18
6 Eg = Max IE4 + 145!. lEg + fggi = Max i33 + 111. 18 + 71
= (441, 1251
= 104
8 Eg = £6 + fgg = 44 + 50 = 94
12 £12 = Max (Eg + fg,,!, £„ + r„i,i = Max (94 + Id, (88 + 10)
= (104. (981
= 104
backward through the network. The latest e\ent is event 12. We let Lj, = £j,
— 104. Then there is one successor for event 8, so:
We label event 3 with a latest time of 15 days, which is the scime as the
forward computation time, meaning there is no slack time.
The information calculated from the forward and backward passes
helps the project manager identic* the critical path, determine the comple-
tion date of the project, and compute slack time. When a project is man-
aged, all activities and e\ ents on the critical path must be closely monitored,
because any shp (extended delays) can mean comparable delays in the
completion date. In most projects, no more than 10 percent of all acti\ities
are on the critical path.
Harvard Project Manager Harvard Software, Inc. Sophisticated on-screen graphics; sup-
Howard, Mass. port Gantt chart and CPM displays;
generates project road map automati-
cally and indicates critical path.
map, others with graphic ability. They run on IBM, Apple, and other per-
sonal computers. Some packages provide graphic network diagrams for a
clear display of a network's criticcil path. The software also offers fully
detailed,time-phased reports and allows the recalculation of project net-
works in graphic form on screens.
To illustrate a microcomputer project management package, let us take
VisiSchedule. This program shows the critical jobs in the project schedule,
explains the relationships between jobs, calculates project and manpower
costs, and generates reports and schedules as needed. Specifically, the
program does the following:
• Determines the jobs that are critical for time and cannot be delayed
without delaying the project.
• Determines the jobs wdth slack time that can be delayed wdthout delay-
ing the project.
• Keeps track of important deadlines and significant milestones through-
out the project.
• Maintains schedules in time units of days or weeks, whichever is pre-
ferred.
r ^x
w
458 PAST FOUS / STSIEM IMFLEMENTAHON
• Builds schedules around the holidays, days off, and nonivorking weeks
that you define.
• Changes any aspects of a job and immediately shows the impact on the
overall project.
HGURE 15-9
007-00 1/P
&WT
-z'-^ -^I'dTr*:^'-'
"LfWi]allirS7ilB('lii!r:Krufe77rflB
display the project schedule and the schedule menu for modification. As
shown in Figure 15-11, the upper part of the screen contains the schedule.
The bottom contains the menu for entering and making changes in the
schedule. The right side of the screen shows the time line schedule. It starts
with a display of the date and week number, followed by the schedule.
PERT is still useful for modeling a project as a network of smaller jobs or
activities, which is useful to predict how long it will take to complete that
project. A PERT network is only a rough guideline for planning a project,
'
Dm
Jtb
Nwnbar .^,
r-- :t scheo'jle Jhn _^
.,.;£='. , . ._ •;-
Ik ^____,^
Job
Mn^ 1
•-rpIP'IJM
^C-'hEE pip
J ; :. . i-'HpT y
1 J
:
.
7 4
5^^^^^^
5 -" -^:
^^=== -~^^^^ *Mk
Nunibar
I- i.
z„ c r.-^C^ 1
'-'
. ii
MM«. .______^
ma" iraM4:
:lT "I -rue- III f |v-cr - -
'
1
iilliiiiitt11
Symbol Description
>_ _ _ _ _ _ _ _ > A critical job. A critical job cannot be delayed
without delaying the entire project.
"^
A non-critical job. There will be slack time
associated with a non-critical job. This symbol is
used for all jobs when you choose not to show the
critical path.
however. It says nothing about who does what or when. Noncritical tasks
are given only the earliest and latest permissible start times. These limita-
tions are corrected when an organization installs project management
software. The features listed earlier give an indication of flexibility that is
available for planning and controlling systems projects. For example, with
almost any package, it is possible to create a hierarchy by breaking the main
network into subnetworks so that each activltv is broken into its own
network of activities. Gi\'en this flexibilitv', a software package designed for
200 activities could handle as many as 600,000, though at the expense of
many hours of nonstop computing.
PROJECT ORGANIZATION
We have explained the major tools used in project planning. After the tasks
have been mapped out and the manpower requirements determined, the
next step is to decide on the best way to organize manpower. We shall begin
by identifying the staffing and appropriate skills for a pixDJect and then
suggesting a management style and approach to manage and control the
staff.
A project team is expected to tap the skills of its members so that one or
more members can address the issues that face the project and suggest
alternative solutions to keep the project moving the completion. These skiUs
may be secured through a plan that identifies team members and specifies
462 PAET FOUR / SYSTEM IMPLEMENTATION
Reporting Structure
Most people associated with major projects are outside the direct control of
the project leader. Ideally, each team member should report directly to the
project leader. In practice, how^ever, most team members report to their
respective supervisors. This means that the project leader has to use special
coordinate a host of persons over whom he/she has no real author-
skills to
ity. For this reason, some authors refer to such a position as project
Management Styles
' Jeffrey Keen, Managing System Development (Reading, Mass.: Addison-Wesley Publishing,
1981), p. 217.
15 / PBOJECT SCHEDULING AND SOFTWAfiE 463
Variable Interpretation
6. Company policy and The company would administer its policies fairly
practices
7. Compensation My pay would compare well with that of other workers
8. Co-workers My co-woricers would be easy to make friends with
9. Creati\it\' I could trv out some of my own ideas
10. Independence I could work alone on the job
11. Moral values I could do work without feeling that it is morally wrong
12. Recognition I could get recognition for the work I do
13. Responsibility Icould make decisions on my outi
14. Securirv The job would pro\ide for steady employment
15. Social service I could do things for other people
16. Social status I could be "somebody" in the community
17. Supervision-human My boss would back up his people (with top management)
relations
18. Supervision-technical My boss would train his people well
19. Variety I could do something different every day
20. Working conditions The job would have good working conditions
Source: Rene \'. Davvis, L. H. Lofquist, and D. J. Weiss. A Theory of Work Adjustment la revision),
Summary
1. System projects fail for many reasons: conflicting objectives, user's lack
of involvement, inexperienced project management, budget overruns,
and changes in user requirements. These problems make it important
that projects are properly planned, managed, and implemented.
Study the problem to evaluate the scope, degree of change, and cost
of late completion.
Specify project responsibilities through a qualified project team.
C. Select a project manager with experience in the functional areas,
ability to recognize problems and communicate ideas, and working
knowledge of the system improvement process.
d. Establish ground rules and standards for handling projects.
e. Select the right project, especially if it is the first project for the firm.
f- Define the tasks to be done and plan accordingly.
4. A project manager plans the life cycle of the project and eliminates
crisis through proper planning. Planning mccms plotting activities
against a time ft ame and developing a network based on an analysis of
the tasks that must be performed to complete the project.
5. TWo planning tools are used in project planning:
a. Gantt chart uses horizontal bars to show the duration of actions or
tasks. Broken bars are estimated time delays or slack time. A task is a
specific job to be performed; a group of tasks make up an activity
that ends in a milestone.
b. Program evaluation and review technique (PERT) uses tasks and
events to represent interrelationships of project activities. Each task
is limited by an identifiable event that has no duration. The list of
Key Words
Activity Program Exaluation and Review Technique
Critical Path I PERT I
Review GLuestions
1. In your own words, why do systems fail? How would one reduce
potential failure Ln system development? Explain.
2. From vv^hat we have learned about system development and the analyst-
user interface, how important is the user's involvement for successful
system implementation? W hat other factors are important? Be specific.
3. Define the following terms:
a. Project management.
b. Task.
c. Milestone.
d. Critical path.
7. What is a Gantt chart? How would you develop one? How does it difiier
12. Review the computer journals cind report two applications for
to class
project management. Explain briefly what each application does and
how they differ.
13. What is the main function of a project team? What skills should team
members provide? Explain.
14. If you were a project manager developing a mailing list for a large retail
store, what management style would you adopt? Why? Justify your
preference.
15. "A project manager must be the kingpin of personnel motivation." Do
you agree? Discuss in detail.
Application Problems
Assignment
Prepare a Gantt chart based on the infoimation provided.
Assignment
a. Draw a PERT chart and schedule the required activities around the follow-
ing conditions:
Week
3/8 3/15 3/22 3/29
1 2 3 4
Bank Live date set Bank personnel Short name and Building contractor
Ad slicks obtained assigned name/address and Diebold
(Ccird and forms printouts received; meet on building
production) maintenance work specs
begun /Maim system
Work started on planned
validation and dis-
closure forms
Phone Co.
Diebold Building specs.
Other
Burroughs
General Data •
Comm.
Ad agency
Week
5/17 5/24 5/31 6/7
11 12 13 14
Bank Credit criteria Second card edit Pin and pan con- Building com-
due due tacts assigned pleted
BCF form due Autodialer question-
naire
Review fined card is-
sue
Data entry training
Servicer Second card edit Card tape to vendor First 10 cards pro-
due Data entry training duced and
Order demo, and tested
special cards
Phone Co.
Diebold Cards tested
Other
Burroughs
General Data
Comm.
Ad agency
—
(i 8 10
Marketing campciign Plan ad cam- GIF training GIF clean-up Gontinue First card edit
meeting paign begun (emphasis GIF DDA mainte-
Artwork pi-oofs on DDA) cleanup nance
appixjved begun
Gircuit due
GRTs
installed
15 16 17 18 19 20
begins employees *
G/L accts. customers
*
opened Uniforms and GIF clean-up
* * * *
Employee activity completed
kickoff
* * * *
*
Demonstrators *
response * * * *
team bal-
* *
ancing
* *
training
* *
ATM circuit *
due Atm installed
* * * *
*
* * *
*
ATM date
* * * *
set due
470 PART FODK / SYSTEM IMPLEMENTATION
The total system takes 1.5 weeks to test, which involves the two program-
mers.
Remember that there are two design activities, four program writing and
testing activities, stock file creation, and a total system test.
What is the critical path duration? Can the project be completed within the
time allotted by the criticfd path? Elxplain.
Selected References
Diamond, Daniel S. "Project Management Via PC." Business Computing, December
1983, p. 30fF.
Hairell, Clayton Jr. "Sure-Handed Project Management, Part I. Reducing the Risks."
Computer Decisions, November 1983, p. 2608".
Harrison, William D. "For Stronger Project Team: Working the Human Side." Com-
puterworld, May 21, 1984, pp. ID15-16ff.
Justice, Karen. "Systems to Keep You on Schedule." ICP Interface Administrative and
Accounting, Winter 1983, pp. 25-27ff.
—
Newldrk, Claire. "Project Estimating What's So Tough about It? ICP Software
Security,
Disaster/Recovery,
and Ethics in
System Development
Introduction
System Security
DEFINITIONS
CONTROL MEASURES
Identitication
Access Controls
Encryption
Audit Controls
System Integrity
Recovery/Restart Requirements
System Failures and Recovery
472
K
At a Glance
Every candidate system must provide built-in features for security and integrity
of data. Without safeguards against unauthorized access, fraud, embezzle-
ment, fire, and natural disasters, a system could be so vulnerable as to threaten
the survival of the organization.
To do an adequate job on security, a systems analyst must analyze the
risks, exposure, and costs and specify measures such as passwords and encryp-
initiated.
d. The meaning and importance of ethics in system development.
Disaster/Recovery Planning
THE PLAN
The Team
Planning Tasks
The Manual
INTRODUCTION
Just when the computer age no longer a question; it is here. Its
will arriv^e is
impact is everywhere, but not without a price. The end user is concerned
about security along with increased dependence on the computer. In
system development, the project manager and the analyst must consider
measures for maintaining data integrity and controlling security at all times.
"Hiis invoK'es built-in hardware features, programs, and procedures to pro-
tect candidate systems from unauthorized access.
In this chapter, we address the issues of data and system security and
suggest some control measures. We also look at ways of planning for and
recovering fix»m disasters so that the organization can continue to operate.
Underlying the entire system development process is the issue of ethics and
ethical standards that govern the beha\ior of analysts, designers, and pro-
ject managers. Ethics is becoming an important topic in systems analysis
and should be addressed at this point.
SYSTEM SECURIT7
Newspapers, journals, and television are rife with stories about computer
criminals embezzling millions of dollars, "hackers," and kids electronically
breaking into computers across the nation. Here are tw^o examples:
1. A Wells Fargo bank employee embazzled $21 million. The employee was
jjerforming the entire reconciliation function of the branch and knew^ ex-
actly the operating procedures of the system.*
' Arnold M. Cohn, Total Information System Security," Journal of System Management,
April 1983, p. 17.
2 Ben Harrison, "Planning for the Worst," Infosystem, June 1982, p. 54.
•
hi ^^1—^ Ol
^^^^fc^ jD
vX o
1 ^Pl ^
"V\/^ 0>
• Q.
tO
can
and to
who
«
>
Is
= n ss
o>
a> n (D
I«= " « S
5 »- « c— «-
o S " «>
-c E a
5
as *-
^B^^H <D
=> a> S j£
o o > O
o a >.-^
_) «x:x»^
ao
eg
3
C
6 I3
M
>• E
cn Q
U
•O "5
O
CO
c
Q
D £
JO
3 ic
E-
2
a «
o Q
u
c
a
l-a
a
E
O r
M <
o (D
a, T3
Q. o
O a
a
•a
i
<
o „
M 3
O
to
I—
476 PART FOUR / SYSTEM IMPLEMENTATION
puter security plan.^ This means that security is critical in system develop-
ment. The analyst has a responsibility to design a workable security system
to protect the system ftxjm damage, error, and unauthorized access. The
level of protection depends on the sensitivity of the data, the reliability of
the user, and the complexity of the system. A well-designed system includes
control procedures to provide physical protection, maintain data integrity,
and system access.
restrict
Tight system security can be costly, but appropriate security is justified
2. Data are a major asset and should be protected. In a data base environ-
ment where computer files are centralized, security becomes critical.
Definitions
The system security problem can be divided into four related issues: se-
curity, integrity, privacy, cmd confidentiality. They determine file structure,
data structure, and access procedures.
System security refers to the technical innovations and procedures
applied to the hardware and operating systems to protect against deliberate
or accidental damage ftxjm a defined threat. In contrast, data security is the
protection of data ftx)m loss, disclosure, modification, and destruction.
System integrity refers to the proper functioning of hardware and pro-
grams, appropriate physical security, and safety against external threats
such as eavesdi-opping and wiretapping. In comparison, data integrity
makes sure that data do not diffei- from their original fonii and have not
been accidentally or intentionally disclosed, altered, or destroyed.
Privacy defines the rights of the users or organizations to deteimine
what information they are vvdiling to shai^ with or accept from others and
how the organization can be protected against unwelcome, unfair, or exces-
sive dissemination of information about it.
The temi confidentiality is a special status given to sensitive information
in a data base to minimize the possible invasion of privacy. It is an attribute
Charies Alexander, "Crackdown on Qpmputer Crime," Time, February 8, 1982, p. 60. See
3
also R C:ook, J D. Kure, M A Johnston, and H J Matfoi-d, "DPMA Chapters Speak Out on DP
J
security or data integrity, research shows that the most damage comes from
errors and omissions —
people making mistakes. The threat of external
attack on a computer system is virtually last. This means that in establishing
a priority sequence, one would probably want to start from within the firm
and work out.'* The list of potential threats is:
4. Natural disasters.
5. Extemcil attack.
'*
A. Richcird Immel, "Data Security," Popular Computing, May 1984, pp. 65-68.
478 PAfiT FOUE SYSTEM IMPLEMEKTATION
/
'-'
\'i^ ^«f- vN^"
Espionage
Sabotage
5 Robert Batt, "White Collar Crime," Computenvorld. December 26, 1983, p. 49flf.
16 / SECURITY, DISASTER / RECOVERY. AND ETfflCS IN SYSTEM DEVELOPMENT 479
Risk Analysis
Given the threats to system security, system designers should assess
each of the system's data aggregations in light of possible threats against
them. The purpose of risk analysis is to determine the probabiUty of prob-
lems occurring, the cost of each possible disaster, the areas of vulnerabiUty,
and the preventive measures to adopt as part of a security plan.^
^ J. p. Curry "Analyzing Computer Security Risks," Canadian Datasystems, Jufy 1981, pp.
69-70.
4«0 PAST FOUE SYSTEM IMPLZMENTATION
Security
Exposures
measures
Unacceptable
exposures
_L
Pre.e'^t .6 MeaSi. es
Recovery Measures
p^ c : es
Figure 16-3 an illustration of risk anahsis. First the designer lists the
is
objectixes of the system and e\aluates them against the existing computer
facility to detemiine the security- requirements. The facility', in turn, is
user aware of the exposures and theii- i-espective costs and contixji mea-
16 / SECURITY, DISASTER / RECOVERY, AND ETHICS IN SYSTEM DEVELOPMENT 481
sures. A special risk analysis matrix that specifies the risks, costs and effects;
and probability of exposure helps the designer determine the actions to be
taken and how quickly they must be taken. Figure 16-4 shows the matrix.
Note that the has the highest cost-probability product and, there-
first risk
fore, is the highest priority for security. Also, the higher the probability for a
given occurrence, the more appropriate are preventive measures. For low-
risk factors, ability to recover is usually an adequate measure. If ability to
recover is difficult and consequential losses are excessive, however, insur-
ance is a must.
The two key elements in risk analysis are the value or impact of a
potential loss and the probability of loss. As shown in Figure 16-4, an
attempt is made to match a potential loss with the probability of its occur-
rence to decide on the action to be taken. The goal is to identify the threat
that results in the greatest monetary loss and provide protection to the
appropriate degree.
Control Measures
After system security risks have been evaluated, the next step is to select the
measures (layers of protection) that are internal and external to the facility.
These measures are generally classified under the following: (1) identifica-
tion, (2) access control, (3) audit controls, and (4) system integrity.
Identification
There are three schemes for identifying persons to the computer:
known), and the knowledge of the hiding place becomes the password.
Another scheme under the "something you know" category is the
picture badge, which identffies people who bring work to the center. Al-
though it positively identffies the carrier of the information, the badge does
not verify that the person is authorized to submit a job or receive reports
from the system.
2. Something you are, such as fingerprints or voice prints. Although fin-
" Sigmund Porter, "A Password Extension for Improved Human Factors," Computers and
Security, (North-Holland Publishuig, Amsterdam, 1982), pp. 54-56.
2
~- ?f
5 -
5 = E i £ =
S . £= g I e
ac E 5 = 5 =
C — = « c
?
e = - ="* = S _
^ _ 5"
—— — «
^1 : = 5 r 5 3 Q.
O
11
5 ^ ^ -3
° = -
G S 3 -?f — —
C.
C 1 IS = B
= -s o o
= = < E
5 5 ^
= - £ ~ i- s-== —
5 5 = = s
= <
,"? S X
ill'? s
Hill 3
=? 5
= 9
u 1^-
c J
£3 ;j £
d Is
a a
a
= i = i-s^ c S
C
a •=- E C.
o :£ §
u lie -c
£
6 S e S 6 S s
x
i = 53 ;i
^£l S 3D
to K
c o
a •o
o 2>
o
I 11
M
S I'
Ei5 O 8-
3 e
»
1. Have a single entrance to the operating eirea monitored around the clock.
2. Install intruder cilarms.
3. Instcdl akey lock, a cipher lock, or a badge-operated lock on the door of the
operating cirea.
4. Employ a guard during operating hours of the computer center.
gerprinting is commonly used in law enforcement, it is ill suited for the MIS
environment. Voice prints, on the other hcind, are making headway as a
reliable method for verifying authorized users. The technique essenticdly
cinalyzes a person's voice against prerecorded voice patterns of the same
person. An exact match allows access to the system.
3. Something you have, such as the credit Ccird, key, or special terminal.
Magnetic stripe credit card readers on terminals identify the operator to the
system. The card along vvdth a password gives added assurance of the
identification of the user.
Access Control
Various steps are taken to control access to a computer facility (see
Figure 16-5). One way is to use an encoded card system with a log-keeping
capability. The card serves as a key to unlock doors, including tape storage
and other classified areas. The card magnetic key and a
is essentially a
"ke3/port" is a lock. Inserting the card into the lockport unlocks the door. A
card that includes a photograph of the bearer may double as an employee
ID badge.
"intruder" from injecting false data into the cheinnel or modifying messages.
The encryption concept is simple. A plaintext (unenciphered) message
is treinsmitted over cin unprotected communications channel. To prevent
* J. Michael Nye, "A Primer on Security," Mini-Micro Systems, Jufy 1981, p. 166ff.
484 PART FOUK / SYSTEM IMPLEMENTATION
/
/
, .
. 1- -- •
w - < ^ - ' V / /•? 1 1 . 1
network security systems. A system that assures that encryption and de-
cryption are done without human intervention is virtually secure from
unauthorized access.^ Encryption devices for pergonal computers are avail-
able at the chip level and in the software. They are designed specifically to
transmit encryptic data; others protect software by making it difficult, if not
impossible, to copy.
For computer personnel fraud and embezzlement, several contiDls may
be instituted. For example, the use of prxjgrams and changes must be
authorized and documented at all times. Other programs and data base
files should be stored in a library and accessed only when needed. Other
Audit Controls
Audit controls protect a system from external security breaches and inter-
nal fraud or embezzlement. The resources invested in audit conti'ols, how-
ever, should balance udth the sensitivity of the data being manipulated. One
problem uith audit controls is that it is difficult to prove theii- worth until
the system has been violated or a company officer imprisoned. For this
reason, auditability must be supported at all management levels and
planned into every system.
One of the most vulnerable places for a system is the MIS department.
Programmers can pirate, modify, and even sell software for pergonal gain.
y Matthew A. Kenny, "Glyptography Comes out of the War Room to Aid in Securing
Computer Systems," Data Management, July 1981, pp. 19-21.
16 / SECUETTY, DISASTEK / RECOVERY. AND ETHICS IN SYSTEM DEVELOPMENT 485
3. Critical forms such as checks should be locked in a safe location and subject to
an inventory system.
4. Control final program assemblies so that only the appropriate program is in-
stalled.
System Integrity
System integrity is a third line of defense that concentrates on the
functioning of hardware, data base and supportive software, physical se-
curity, and operating procedures. The most costly software loss is program
error. It is possible to eliminate such error through proper testing routines.
Parallel runs should be implemented whenever possible. Physical security
provides safeguards against the destruction of hardware, data bases, and
documentation; fire, flood, theft, sabotage, and eavesdropping; and loss of
power through proper backup (see Figure 16-8).
The proper use of the file library is another imporant security feature.
This involves adequate file backup and reliable personnel to handle file
documentation when needed. File backup means keeping duplicate copies
of the master and other key files and storing them in suitable environmental
conditions. For tape files, a common procedure is to save the old master file
486 PAET FOUB / SYSTEM IMPLEMENTATION
FIRE
station.
4. Provide fireproof vaults for critical data, tapes, and other materials.
FLOOD
1. Water pipes should be located away from computer facilities and storage.
2. Building should be located on high ground to avoid rising water tables or heavy
rain damage.
3. Sejil ceiling and walls against water seepage.
aftereach update. The most recently created file is called the son, the
previous one the father, and the one previous to the latter the grandfather.
Since it is a costly procedure, the decision to proceed along these lines has
to be balanced against potential loss if the files are destroyed.
ments.
For a sequential file, the grandfather-father-son approach to a backup is
copied on a transaction log, and combined. On the fourth day, the data base
"crashes," using a prior valid data base and copies of the transaction log.
Reprocessing is initiated to restore the data base.
o
CO
ID CO
tr >.
O o E^. a
a
o \\
cc l/>
enc
c o
tc
1—
c >
o
B CM
c
o
M
>
u
w
D
P
d
(1)
o
U
o
a
U
o
^H
CO
« c
to \ o
Ul >.
a CO
Q
^ 03
H
.;:;
O
c i"
•>>:
16 / SECURITY. DISASTER / RECOVERY, AND ETfflCS IN SYSTEM DEVELOPMENT 489
DISASTER/RECOVERY PLANNING
What happens if your system bums out or if a disgnjntled employee inflicts
serious damage to it? How do you recover? Where do you get your infoiTna-
tion? Studies have shown that a company's very survival is threatened
within 48 hours after the loss of computer operations. Even a limited
disiuption or disaster can result in substantial financial losses and even the
thi-eat of litigation.'" Direct financial losses insult from the loss of sales and
production. Indirect financial losses include long-term loss of customer,
uncollected receivables, and undetected ft'aud. Loss of control over vital
data compromises data integrity and business decisions.
Disaster/recovery planning is a means of addi-essing the concern for
system availability by identifying potential exposure, prioritizing applica-
tions, and designing safeguards that minimize loss if a disaster occurs. It
means no matter what the disaster, you can recover. The business udll
that
survive because a disaster/recovery plan allows quick recovery under the
circumstances.
How^ does one guard against such losses? There are several alternatives.
As summarized in Figure 16-11, they range from having an entire facility in
one location with a complete redundancy of hardware to leasing a site with
no computer but adequate electricity and air conditioning to support a
computer facility on a temporary basis. After an alternative has been deter-
mined, a decision must be made about the applications to be pixjcessed, the
hardware to process the applications, and what would be relocated after a
disaster.
management's primary roll is to accept
In disaster/recovery planning,
the need for contingency planning, select an alternative measure, and
recognize the benefits that can be derived from establishing a disaster/
recovery plan. Top management should establish the disaster/recovery pol-
icy and commit corporate support staff for its implementation. The user's
role is also important. The user's responsibilities include the foUoudng:
*" Richard A. Bernstein, "A Contingency Plan for Recoveiy from a Disaster," Mid-Continental
Banker, December 1983, p. 16.
C
"
2 ^T3 so
(0
H o CO
c
a .2
=0
a
03
3
CO
O CO
3
2 2 -O
a E
c c - O" M O c
T3
O)
v
a £ C 3 CO r-
C
T3 .D CO CO e CO
CO
e ^ t«
x: ^E ^
.]
£ c
0)
CO
O
£
= ^ - so i
3 C u
13
3 I s so
E
a « 2
^cS (0to
*P .SE =" _ 01 O tj a CS O c
u o 3 T! 3
-c a
P
P
u « ts
5
c cr CO o
°
OS 2 I S a 3
3 -^
3 ^ £3 "cS s
C o C8
- c
M o a s *-«
o
1^ S" o
It CO
o a
" E
CO
E 2
« c
o
O C
E &i = It JZ o
so o
Si o
o o
£1
o ^ E
o ^ fl)
ca
eg CO
« .BP
a o
"
*: E
^
Ep
« -
8 I X5
CQ
•c r i >> E
c O
3 , aj
•s 8 U CO
CO
> a
o
'S
CO
8 iS u
s: IS
so ^ 2 3
a «E .j-3 c
ca
IB
c
ca O CO
P
3 c «
<u
T3 2 CO
en CO 2>^ 2 u
3
S 3
O o c-
u o -E
>
1^ 2 S
XJ
.2 E
o 13 5
o as
ID
P o
o £ ^
£
.
.£
2
^
a> > o E
M c C p
"^
o
o c « « o <0
O) P
M *^ -P —eg a t. O)
(0
br
/- a £ CO
>
u
_o " g-l
3
en
3 ^ "n CO 4!
o
u
V 0) o O °<^
^
T3 -S E E « o a:
c .tS
- « CO
D o
CO
eg
eg
j2 c
P.^ I E ^
0) CO CO eg
0) P m « »^ « o
o eg J3 3 X
^ U u 5 a
p x:
M a> .h -^
eg
Si
eg 5"
3 - 3 aj ?•
S ^
P -r
D 0) a W "« tn o
u
i: eg c
3 £ I E 2 2 I U 01 X3 0)
3 O o 3 .22
^ x: N
OB
V c a a (J
g T)
U
i-i
0)
«
u
0)
u E
x:
y a
a
I
eg •o
ce cS ta
*•»
2 a a
a a s
a 3 en
•o
I-H
0)
eg
U u T3 <
es
eg "o «
M "co
CO X} X> U e
2 •a 3
p O
t: 2 3 eg
>
CO
bo
ID "o 3
EH
u
16 / SECUklTY. DKASTEB / KECOVEBT. AND ETHICS IN STSTEM DEVELOPMENT 491
The Plan
When a disaster/recovery procedure is planned, several questions have to
be answered:
1. How long would it take to rebuild the computer center or asjjects of it?
2. What type of accommodation should we look for in a backup instaUa-
tion? How quickly is it available?
When these questions are answered and management gives its support
for a disaster/recovery plan, the next step is to initiate a plan that involves
four phases:
Tlie Team
A team should include a cross section of system
disaster/recovery
designers, users, and computer op)erators. Under the leadership of a coordi-
nator, the team's main functions are to organize the project, monitor pro-
gress on the plan, zind oversee its completion. The team meets periodically
to ensure that the plan is kept up to date, considers new vulnerabilities or
Planning Tasks
Disaster/recovery planning tasks are prepared in a cycle simUar to that
of system development. Briefly, the cycle entails the following:
The Manual
Once the team has completed the assignment, a disaster/recovery man-
ual is prepared and copies are made available to team members and
management. All copies of the manual should be updated as needed. The
number of manuals should be kept to a minimum with a log of holders and
the number of each manual assigned. The more manuals that are printed,
the more likely it is that some will be overlooked during the maintenance
and update procedure. This is especially true in a large corporation.
" For detailed coverage of disaster/recovery planning, see R. P. R. Gaade, "Picking up the
Pieces," Datamation, January 1980, pp. 113-18.
16 / SECURITY. DISASTER / RECOVERY. AND ETHICS EN SYSTEM DEVELOPMENT 493
• A new client competes v\ith a past client for whom the analyst has
already installed a system. The analyst knows what system will give the
new client the competitive edge and offers to instcill it in return for a gift
of company stock.
L>-
16 / SECURITY. DISASTER / RECOVERY, AND ETfflCS IN SYSTEM DEVELOPMENT 495
anyone can buy information about anybody. The likelihood of being pros-
ecuted is remote because the courts do not see such offenses as serious
crimes. How could one be accused of stealing information when it is still in
the corporate data base?*^
An ethical society has worry about. Twenty- three states already
little to
have computer crime laws in force. Some of these laws view stealing or
abusing data bases as a felony or crime. Technology is merely a vehicle; it is
a means. The objective is the betterment of society through ethical stan-
dards and professionalism that supports these standards.
Summary
1. Security is critical in system development. The amount of protection
depends on the and the
sensitivity of the data, the reliability of the user,
complexity of the system. The motives behind security are to keep the
organization running, protect data as an asset, and seek management
support for more installations.
2. There are three categories of controls in data security: physical security
(protection from fire, flood, etc.), data base integrity, and control mea-
sures (passwords, encryption). Potential threats to system security in-
clude errors and omissions, disgruntled and dishonest employees, fire,
and natural disasters. Errors and omissions cause the most damage.
3. Personal computers have been adding security problems to system
installations. Many of today's operating systems have no passwords.
There is tendency
also a to put everything on the microcomputer with
hardly a backup.
4. Risk analysis helps assess the probability and cost of possible disasters,
pinpoint unacceptable exposures, and adopt preventi\'e measures as
part of a security plan. The goal is to identify the threat that results in
the greatest monetary losses and provide protection to the appropriate
degree.
5. After system security risks have been evaluated, the next step is to select
security measures. These measures are classified as follows:
a. Identification, scheme for identifying persons to the system
it is a
based on "something you know" such as a passw^ord or a picture
Key Words
Confidentiality Hacker
Data Integrity Password
Data Security Plaintext
Decryption Rollback
Encryption RoUforward
Ethics System Security
Review GLuestlons
1. In your own words, what is the purpose of this chapter? How is it
5. What ai^ the major threats to system security? Which one(s) is the most
serious? Why?
6. In what way is the personal computer a step backward in system
security? Illustrate.
involved? Explain.
498 PAfiT FODB / SYSTEM IMPLEMENTATION
Application Problems
Assignment
Develop a procedure and security check that can be integrated into the candi-
date system for the control of stock issuing.
Uptovin Savings & Loem Beink has pix)blems with address maintenance.
Customer complaints prompted an investigation of the nature and
source of errors of customers' addresses in the savings application. A
preliminary check discovered the follovidng:
More and more customers have been closing their accounts, adding
tension to an already tense situation.
16 / SECUKITY. DISASTER / RECOVERY. AND ETHICS IN SYSTEM DEVELOPMENT 499
Assignment
a. What can be done to correct the address maintenance problem?
b. What safeguards can be introduced to pre\'ent a recurrence of these prob-
lems?
c. How can the zip code problem be rectified on the records?
d. As a systems analyst, what measures would you take to "clean up" the file?
A credit union woiried about the potential loss of its master files from
is
Assignment
a. Outline a master plan to provide security and backup procedures at the
credit union headquarters.
b. Devise a built-in plan to minimize the possibility of loss of vital records by
sabotage or uiretapping.
c. What tape files should be duplicated? Retained?
d. For how long cind where should sensitive data files be stored? Why?
500 PART FOUR / SYSTEM IMPLEMENTATION
Selected References
Alexander, Charles. "Crackdown on Computer Crime." Time, February 8, 1982, pp.
60-62.
Batt, Robert. "White Collar Crime." Computerworld, December 26, 1983, p. 49ff.
Bernstein, Richard A. "A Contingency Plan for Recovery from a Disaster." Mid-
Continental Banker, December 1983, p. 16.
Campbell, Robert P. "Locking up the Mainframe." Computerworld, October 10, 1983,
pp. IDl-3ff; October 17, 1983, pp. IDl-3ff.
Cohen, Arnold M. "Total Information System Security." Journal of Systems Manage-
ment, April 1983, pp. 14-17.
Cook, J. R.; J. D. Eure; M. A. Johnston; and H. J. Matford. "DPMA Chapters Speak
Out on DP Security." Data Management, May 1, 1982, pp. 42-46.
CuUen, Kathryn M. "Systems for Authorized Access to Information." Administrative
Management, May 1982, pp. 35-38.
Curry, J. P. "Analyzing Computer Security Risks." Canadian Datasystems, July 1981,
pp. 69-70.
Editorial, "DPMA Code of Ethics andStandards of Conduct for Information Process-
ing Professionals." Data Management, October 1981, pp. 58-61.
Editorial, "Roaming High Tech Pirates." Time, Febi-uarv 8, 1982, pp. 60-63.
Emmett, Arielle. "Thwarting the Data Thief." Personal Computing, January 1984,
p. 97.
Freedman, David H. "Ethics." Infosystems, August 1983, pp. 34-36.
Friedman, Stanley. "Contingency and Disaster Planning." Computers S: Security.
North-Holland Publishing, Amsterdam, 1982, pp. 34-40.
Gaade, R. P. R. "Picking up the Pieces." Datamation, January 1980, pp. 113-18.
Gilliam, Les. "Implementing a Disaster Recovery Plan." Computerworld, December 5,
1983, p. 97ff.
Harrison, Ben. "Planning for the Worst." Infosystems, June 1982, pp. 52-62.
Heide, Dorothy, and James K. Highiovver. "Oiganizations, Ethics, and the Comput-
ing Professional." Journal of Systems Management, November 1983, pp. 38-42.
Henkel, Tom, and Peter Bartolite, eds. "Protecting the Corporate Data Resources."
Computerworld, November 28, 1983 Ispeciiil r'eporti, pp. 1-29.
Immel, Popular Computing, May 19, 1984, pp. 65-68.
A. Richard. "Data Security."
Johnson, Deborah G. "Privacy, Power, and Property: Ethical Dilemmas for Computer
Professionals." Small Systems World, June 1983, pp. 17-22.
Kenny, Matthew A. "Cryptography Comes out of the War Room to Aid in Securing
Computer Systems." Data Management, July 1981, pp. 19-21.
Kirchner, Jake. "August Bequai, Fighter for Ethics." Computerworld, May 21, 1984,
pp. IDl-4ff.
Morris, Robert S. "Do-It-Yourself Disaster Recovery Planning." Sma// Systems World,
October 1980, pp. 23-26ff.
Nye, J. Michael. "A Piimer on Security." Mini-Micro Systems, July 1981, p. 166ff.
Patterson, Wm. "Where Is Technology Taking Us?" Industry Week, May 30, 1983,
pp. 34-36.
Porter, Sigmund. "A Password Extension for Improved Human Factors." Computers
& Security. North-Holland Publishing, Amstei-dam, 1982, pp. 54-56.
Rames, David. "Recovering from Disastei-s." Computer Decisions, September 1981,
p. 109ff.
Sherwin, Douglas "The Ethical Roots of the Business System." Harvard Business
S.
Review, November/December 1983, pp. 183-92.
16 / SECURITY. DISASTER / RECOVERY. AND ETHICS IN SYSTEM DEVELOPMENT 501
Spiro, Bruce E. "Ethics —The Next Step Is Crucial." Data Management, November
1983, pp. 32-33.
Weiss, Eric A. "Self-Assessment Procedure IX." Communications of the ACM, Mjirch
1982, pp. 181-94.
Westin, Alan. "New Eyes on Pmacy." Computenvorld, November 28, 1983, pp.
IDll-13ff.
ZJentara, Marguerite. "How to Recover ftx)m a Disaster." Computerworld, September
13, 1982, p. Iff.
/K
i<v:
Glossary of Terms
Abstract system Conceptual or nonphysical entity.
Action entry The lower right quadrant of a decision table; indicates the response
to the question entered in the condition entrv.
Action stub Lower left quadrant of a decision table: outlines in narrati\'e form the
conditions that may exist.
Activity in system development life cycle — a group of logicalK' related tasks that
make it possible to accomplish a specific objective; a group of related tasks.
Alias .An alternati\ e name used to stand for an identified data structure within a
data dictionars' notation.
Alpha testing \eril\ing and studying software errors and failures based on
simulated user requirements.
Audit trail .A feature of data processing systems that allows for the study of data
as processed fiDm step to step; an auditor can then trace all transactions that
affect an account.
Ballot box design A type of form designed so that all the user has to do is check
the applicable box.
Beta testing Subjecting modified software to the actual user site (live) environ-
ment.
Bounded rationality Coined by Herbert Simon — the notion that humans have a
limited capacity' for rational thinking; rationalitv' for determining infomiation
requirements is bounded by limited training, prejudice, cmd the attitude of the
user.
Break-even analysis The point at which the cost of the candidate system and
the present one are equal.
Bubble chart In data base design — a diagram that uses circles to represent the
nature and direction of relationshups between data items.
Candidate system The newly developed system designed to replace the current
system.
50»
V-,«
GLOSSARY OF TERMS 503
Caption a word on a form that specifies what information to write in the space
proxaded.
Closed system A system that is isolated from environmental influences; see Open
system for contrast.
Condition stub Upper left quadrant of a decision table; sets forth in question
form the condition that may exist.
Critical path Events in a PERT network that, if behind schedule, wdll cause the
final event in the network to be late.
Critical path method (CPM) A planning and scheduling method that deter-
mines trade-offs between relative costs and alternative completion dates for a
project.
Data base A store of integrated data capable of being directly addressed for
multiple uses; it is organized so that various files can be accessed through a
single reference based on the relationship among records in the file rather than
the physical location.
Data base administrator (DBA) A specialist whose main tasks are to protect
and manage the data base, resolve user conflict, and maintain and update the
system.
Data base management system (DBMS) The software that determines how
data must be structured to produce the user's view; manages, stores, and
retrieves data and enforces procedures.
Data definition language (DDL) Describes how data are structured in the
data base.
Data dictionary A structured repository of data about data; a list of terms and
their definitions for all data items and data stores of a system.
Data item Represents one or more bytes; describes some attribute of an object
(for example, social security number, sex, or age).
Data manipulation language (DML) in data base — it specifies for the DBMS
what is required; the techniques used to process data.
Data model in data base — a framework or a mental image of how the user's view
looks.
Data store in a data flow diagram — a storage cirea for collecting data input during
processing; the svmbol used in an open rectangle.
Data structure A logically related set of data that can be decomposed into lower-
level data elements; a group of data elements handled as a unit.
Decision table A table of contingencies for defining a problem and the actions to
Tf
u.
GLOSSAKY OF TERMS 505
what action must be taken when a given condition is met or not met.
Ditterentiation In —
open systems a tendency toward increasing the specializa-
tion of functions of system components.
Direct cost Cost that is normally applied directly to the operation in question; for
example, the purchase of a new tape for $40 is a direct cost.
Direct observation A situation where the analyst actually observes the subject
or the system at work.
Entity Also called a data aggregate; something of intei"est to the user about which
to collect or store data; represents a number of data elements.
506 GLOSSAET OF TEBMS
Entropy Loss of energy; a system running down due to loss of enei^', often
leading to a temporary state of disorganization.
Entry In a decision table — the answers to questions or the actions resulting from
the answers to conditions entered in the stub.
formance and performance and rewards: in sxstems work the value the
1 21 —
user places on perceived rewards from a candidate system determines the
motivation to accept and use the system.
Feedback The part of a closed-loop system that automatically brings back infor-
mation about the condition being controlled.
Field A specified area of a record used for a particular category' of data for —
example, a group of card columns used to represent a wage rate or a set of bit
locations in a computer word used to express the address of the operand; see
also Data item.
File Collection of related records organized for a particular purpose; also called a
data set.
File volottility Refers to the proportion of records changed during a time period.
Fixed cost Sunk cost that does not varv with the volume of processing; examples
are rent of a buUding or a computer system and a super\isors salary.
Flow system model A model that shows the flows of material, energy-, and
information that hold the system together.
Force majeure Deals with the suspension of a contract due to exents beyond the
vendor's control such as hurricanes, earthquakes, and acts of war.
Forms control Coordination of forms design and use among users of forms in the
organization.
Future value Time value of money in the form of interest on the funds invested
over a specific time period.
Gantt chart A static system model used for scheduling; portrays output perform-
ance against time.
Hacker A devout user of the computer; usually for "kicks" or the sheer pleasure of
trying to find out how far to push the computer before it i^eaches its limits.
Indirect cost Overhead; results of operations not directly associated with a given
system or activity; examples are insurance, maintenance, heat, and air condi-
tioning.
Information A meaningful set of data that tells something about the data rela-
tionships.
Information system The tools, procedures, and technology that generate user-
initiated information.
Input The data to be processed; the processes of transferring data from external
storage to internal storage.
Inverted list organization A structure in which there are separate lists for each
type of data element in the data base.
Investment period in a candidate system — when initial costs exceed the costs of
running the current system.
Kitchen sink strategy A plan where the user overstates (throws in the sink) his/
her needs from a candidate system.
Logic error Deals with problems such as incorrect data fields, division by zero,
and invalid combinations.
Logical record A record that maintains a logical relationship among all data
items in the record.
Magnetic ink character recognition (MICR) Input method that codes and
identifies checks, deposit slips, and documents preencoded with special mag-
netic ink.
Maintenance Restoring something to its original condition.
Mean time between failure (MTBF) The average time the system is available to
users before breaking down.
Menu A selected list of options that the user chooses from and then types an
option for a computer operation.
NCR paper No carbon i-equired; chemically treated paper that does not require
carbon for carrying impressions fix)m the top form to the copies underneath.
Normalization A process of replacing a given file with its logical equivalent; the
object is to derive simple files with no redundant elements.
Open system A system that performs interactions across its boundary, receives
inputs irom and delivers outputs to the outside.
Organization chart A chart that shows the official structure of the organization
in terms of functional units or in terms of superior-subordinate relationships.
Output Data that have been processed; the end result (product) of the system
under study.
Parallel run Putting the new system into operation in conjunction with the
continued operation of the old system.
Partitioning Dhiding a problem into smaller, separate elements for easier under-
standing or solution; see also Hierarchical structure.
Phase -A set of tasks or acti\1ties that, when competed, brings a project to a critical
milestone.
Physical design .A design that produces the working s\stem b\- defining design
specifications that tell programmers exactly what the candidate system must
do.
Physical record The way data cire physically recorded on a storage medium.
Physical system .A tangible entitv that ma\ be static or dynamic in operation — for
e.xample an office or a bulldozer
Privacy The right of users. indi\iduals, and organizations to decide what informa-
tion they are willing to share with or accept from others.
Process .A procedure that transforms input into useful output; in a data flow
—
diagram indicated by a bubble or a circle.
Project evaluation and review technique (PERT) A flow system model used
to manipulate vaiious values as a basis for determining the critical path, to
interpret these relationships and to relate them back to the real world as a
control technique.
Recency effect A behavior that is altered due to information that was discovered
recently.
Request for proposal (REP) A report by the user requesting selected vendors to
bid on a proposed system.
Resident expert A natural teacher, an employee who takes time to learn a system
and become "expert" in its operation.
512 GLOSSAfiY OF TERMS
Return period A point when a candidate system provides a greater benefit (profit)
than the old system.
Rollback —
procedure updating a prior \alid copy of the data base
hi recovery
with the necessary changes to produce a current version.
Serial access Accessing a record only after the record! s) preceding it has been
scanned.
Slack time Time spent on subsidian' tasks that do not aflect the duration of a
whole project.
written.
Static system model A model that exhibits one pair of relationships like activity-
time or cost-quantity, such as the Gantt chart.
O.
GLOSSARY OF TERMS 513
Stress testing Subjecting the new system to ahigh volume of data over a short
time; the purpose is to ensure that the system does not malfunction under
peak loads.
programs in the system; testing each portion of a system against the entii-e
module before the system as a whole is ready to be tested.
Structured analysis A set of techniques and graphic tools that allow the analyst
to develop a new kind of system specification that is easily understandable to
the user.
Structured English strongly worded formal English statements used for commu-
nicating pixjcessing rules or describing the structui-e of a system.
Structured observation An observation where the observer looks for and re-
cords a specific action such as the number of soup cans a shopper picks up
before choosing one.
Subschema A map of the programmer's view of the data he or she uses; derived
fixjm the schema.
Syntax error A program statement that violates one or more rules of the language
in which it is written.
System development The process of identifying the user's needs and designing
a system that meets those needs through implementation.
\ . V
514 GLOSSARY OF TERMS
System testing Testing the whole system by the user after major programs and
subsystems have been tested.
Tangible cost Costs that are knowii to exist and their financial value is easily
quantified.
Task The smallest unit of work that is assigned to one person and controlled
through a project management routine.
3/5 space In forms spacing, 3 applies to the number of lines per vertical inch; 5
applies to the number of character's that fit in one horizontal inch.
m
Tuple A group of related fields.
Turnaround The elapsed time between the receipt of the input and the availabil-
ity of the output (results).
GLOSSARY OF TERMS 515
Unit set/snapout form A form with an original copy and successive copies uith
carbon sheets interlea\ed between each copy; the set is glued together and
handled as a unit.
maintained.
Validation Checking the qualitj' of software in both simulated and live enxiron-
ments.
Validity in interxdewing — the extent to which the questions asked are worded so
cis to elicit the information the interviewer is after.
Variable cost Cost that \aries with the volume of processing or number of shifts
per day; examples are employee wages and costs of supplies and raw materials.
VisiSchedule A software package used for showing the critical jobs in the project
schedule, explaining the relationships between jobs, calculating project and
manpower costs, and generating reports and schedules as needed.
t^-
Index
B
Backup/recovery, 263
Absolute address, 331
Abstract system, 15, 502 Ballot box design, 308-9, 502
Acceptance testing, 276, 360 Bar code data entiy, 288
ACM; see Association for Computing Benchmark, 428, 502
Machineiy Beta testing, 371, 502
Action entiy, 184, 502 Bond paper, 311
Applications programmer, 76
Association for Computing Machinery,
493-94
Attribute, 322-23, 343, 502
Candidate system, 502
of an entitv',343 Caption, 305-6, 503
values of, 343 Carljon paper
Audit NCR, 299
considerations in design, 277-79 one-time, 299, 313
control, 392, 484-85, 496
types of, 298
software system, 404-5 Cash-flow analysis, 246, 251, 503
Catastrophic failure, 487
trail, 278, 280, 372-73, 406, 502
517
^1 .%
«
518 INDEX
Condition entr\', 184. 503 flow, 171, 178, 180, 187, 262, 504
Condition stub, 184, 503 independence, 333, 504
Confidentiality, 476-77, 503 integrity, 335, 476, 504
Conflict resolution, 72 item, 177, 322, 504
Connection, 267 manipulation language, 335, 350, 504
Consistency check, 278 model, 334-35, 338, 504
Continuous strip forms, 301-2 privacy, 477
Contrived observation, 136, 503 processing system, 21-22
Control, 14, 503 redundancy, 335
Conversion, 388-96, 430 security, 476, 504
activity network for, 389-90, 405 contixjl categories, 495
definition, 388, 503 set, 504
displays, 396 store, 172, 178, 180, 187, 262, 504
file, 390-92 structure, 178-79, 187, 338-44, 350, 504
forms, 396 types of, 339-43
steps preceding, 388-89 validation, 278
Corrective maintenance, 402 views of, 337-38, 350
Cost zoning, 304
direct, 239, 251 Data base, 177, 331
elements, 236-37 advantages, 26
facility, 237 definition, 25, 31, 323, 347, 350, 504
fixed, 240, 251, 506 design, 275, 331-47
hardware, 236 drawbacks, 26
indirect, 239, 251, 507 file environment, 336
i^
INDEX 519
Kitchen sink strategy, 102, 508 Net present value, 244, 251, 432, 509
Leaf,339 Netwoi-k structuring, 340-41, 350, 509
Lease option, 431 Normalization, 344
Ledger paper, 311 steps in, 344-47, 351, 509
Logic error, 36«, 508 Notation diagram; see Hierarchy diagram
Logical design, 262-64 NI*V'; see Net pi-esent value
Logical failui-e, 487
Logical record, 323-24, 508 O
Logical view, 337
Obseivation
contrived, 136, 503
M direct, 136, 505
Mijgnetic ink character recognition, indirect, 136, 507
286-87. 508 methods, 136-37, 150
reader, 289, 293 natuial, 136, 509
Maintainahilitv', 369 obtrusive, 136, 509
Maintenance, 401-6, 430 paiticipant, 136, 510
adapti\e', 331 unohtmsive, 515
c()ri-e!cti\e, 402 Obtixisive obseivation, 136, 509
definition, 403, 508 OCR; see Optical character recognition
management audit, 403 On-site obseivations, 45, 111, 135-38, 509
pt!rtecti\'e, 402 methods, 150
primary activities, 403-4 objective, 150
pix)grammers, 76 pii)blems, 137
system, 41, 57 C)n(!-to-many relationship, 338
Management infomiation, 21, 31 One-to-one relationship, 338
Management information svstem, 21-26 Open-ended questions, 143-44, 509
definition, 508 advantages, 145
managei", 77 drawbacks, 145-46
modeling foi', 97-98 Open rectangle, 171
oiganization, 73-78, 82 Open system, 18-19, 30, 509
planning, 95-98 Operating costs. 237
strategic [ilanning, 95-97 Operating system, 336, 509
Management levels, 22-23 Operational infomiation, 21, 31
Managerial MIS planning, 97 Operations: see Computer, operations
Many-to-manv relationship, 338-39 functions
Mai-k sensing, 288 Optical bar code, 288
Mean time hetvveen failure, 405, 437, 508 Optical (character recognition, 288
Memoiy fonn, 296, 313 Organization, 8-9, 509
Menu, 289, 312, 458, 508 chain, 21, 129-30, 213, 509
MICR; see Magnetic ink character recogni- direct-access, 331, 350, 505
tion indexed sequential, 325-29, 350, 507
Milestone, 52, 450, 508 sequential, 325-26, 350, 512
MIS; see Management infoinialion system structure, 129, 212-13
Model, 16, 508 Output, 19, 509
dy7iamic system, 16, 18, 505 design, 293-95
Modularity, 419, 508-9 Overall logical view; see Schema
Modularization: see Decomposition Overflow area, 325
Module, 267 Overhead, 240, 509
calling, 269 P
cohesion, 269
Parallel processing, 389, 509
coupling, 269
MTBF; see Mean time between failure Paraprofessional
definition, 509
Multiple choice question, 144, 150, 509
Mutual backup approach, 490 task categories, 78, 80
Parent, 339
Participant obsenation, 136, 510
N
Password, 481, 495, 510
Natural observation, 136, 509 Payback analysis, 244-45, 251, 510
NCR fomi, 301, 312, 509 Perfective maintenance, 402
Needs identification, 99-101 PERT; see Program evaluation and review
Net benefit analysis, 242-43, 251, 509 technique
522 INDEX
S-li"
INDEX 523
v^
>
/::,,N
iTSBSa*,^
9
:i.
:'fc
w-
i
a
•4 \
'.r-
-:'-<»'i' *• tk r>''.' ^ -^ -tl JB-f V-W