“The beginnings and endings
of all human undertakings are untidy, the building of a house, the
writing of a novel, the demolition of a bridge, and, eminently, the
finish of
a voyage.”
— John Galsworthy
Over the River, 1933
IN THIS CHAPTER, YOU
WILL LEARN:
-
Why systems analysis is interesting;
-
Why
systems analysis is more difficult than programming; and
-
Why it is
important to be familiar with systems analysis.
Chances are that you groaned when you first
picked up this book, seeing how heavy and thick it was. The prospect
of reading such a long, technical book is enough to make anyone gloomy;
fortunately, just as long journeys take place one day at a time, and
ultimately one step at a time, so long books get read one chapter at
a time, and ultimately one sentence at a time.
1.1 WHY IS SYSTEMS ANALYSIS
INTERESTING?
Long books are often
dull; fortunately, the subject matter of this book — systems analysis — is
interesting. In fact, systems analysis is more interesting than anything
I know, with the possible exception of sex and some rare vintages
of Australian wine. Without a doubt, it is more interesting than computer
programming (not that programming is dull) because it involves studying
the interactions of people, and disparate groups of people,
and computers and organizations. As Tom DeMarco said in his delightful
book, Structured Analysis and Systems Specification (DeMarco,
1978),
[systems] analysis
is frustrating, full of complex interpersonal relationships,
indefinite, and difficult. In a word, it is fascinating.
Once you’re hooked, the old easy pleasures of system building
are never again enough to satisfy you.
This
may come as a surprise to you if you have any experience
writing computer programs. [1]
Programming is enormous fun, and it’s enormously
satisfying to see a program execute successfully, especially
after spending several hours debugging it. It’s
hard to imagine that things could be even more rewarding
and exciting when you begin to move away from the computer
and the writing of computer programs to study the overall
system in which the programs play a part. But by the
end of this book, I hope to have convinced you that
the real challenge, and the real joy, of working
with computer systems is that of carrying out systems
analysis. No matter what profession you decide to pursue,
it will be important for you to understand what systems
analysis is all about. If you work in the computer industry
as something other than an electrical engineer or hardware
designer, there is a good chance that your career will
progress from programmer to systems designer to systems
analyst before you finally move on to the ranks of management.
[2]
1.2
WHOM THIS BOOK IS INTENDED FOR This book is intended for two
audiences: first, the person who is new to the field of systems
analysis, and, second, the experienced systems analyst who needs
to acquaint himself with systems modeling tools and techniques that have
evolved over the past decade. Many readers will be university computer
science students who have completed earlier courses on computer programming;
some may be students in a business training program.
However, the book should
be equally readable by people who have finished their university training
and who are now working in industry. Many people in the computer industry
spend their first several years working as a computer programmer, and
then suddenly find themselves promoted to a position of systems analyst,
without ever being told what systems analysis is all about or what
a systems analyst does. If you are in such a position, this book is
for you. You should also find the book useful if you began working
as a systems analyst in the 1970s or 1980s and never had an opportunity
to learn about classical analysis methods such as structured analysis,
or the newer methods such as object-oriented analysis.
More and more often today,
people outside the computer profession are finding it necessary to
become familiar with the field of systems analysis. If you are a business
person or a manager, there is a good chance that you will be involved
in a systems analysis activity. You will have systems analysts working
for you, spending their time trying to understand what kind of automated
system you want them to build. Similarly, if you are an administrator,
a clerk, a scientist, a politician, an engineer, or an accountant —
or virtually any other professional in today’s society — there is
a good chance that you will spend a significant amount of time during
your career interacting with systems analysts who will be designing
and specifying sophisticated computer systems for you. The more you
know about what these people do, and what they expect of you, the better
off you will be.
Even if you have no expectation
of working in a white collar job — that is, even if you expect to
be an artist, a writer, a musician, or an athlete — you should know
what systems analysis is all about. Citizens in every walk of life
are affected by computer systems of all sorts. Even if you never intend
to build a computer system or have one built for you, it is inevitable
that you will be using computer systems for your banking, for your
education, for your interactions with the IRS and Social Security,
and for virtually every aspect of your interactions with modern society.
As John Gall says in Systemantics (Gall, 1977),
No one, these days, can avoid
contact with systems. Systems are everywhere: big systems, little
systems, systems mechanical and electronic, and those special systems
that consist of organized associations of people. In self-defense,
we must learn to live with systems, to control them lest they control
us. As Humpty Dumpty said to Alice (though in another context):
“The question is: which is to be master — that’s all.”
To emphasize this
point even more, keep in mind that the computer industry
represented approximately 8% of the United States
GNP in 1985; by 1990, it was expected to represent
as much as 15% of the GNP. [3]
Almost every product built today by American business
has one or more computers embedded within it, and
almost every service provided to the marketplace by
American business is based on or controlled by a computer
system.
1.3 WHAT THE BOOK WILL DO
FOR YOU
A major purpose of this
book is to teach you about systems analysis: what it is and how one
goes about doing it. But there is more: my real purpose is to excite you,
to make you so eager to begin practicing systems analysis that you
will want to rush through the last pages of the book and begin working
on your first project. Seymour Papert recalls in Mindstorms (Papert,
1980),
I found particular pleasure
in such systems as the differential gear, which does not follow
a simple linear chain of causality since the motion in the transmission
shaft can be distributed in many different ways to the two wheels
depending on what resistance they encounter. I remember quite
vividly my excitement at discovering that a system could be lawful
and completely comprehensible without being rigidly deterministic.
And as Sir Arthur
Stanley Eddington said in Space,
Time and Gravitation: An Outline of the General Theory
(Eddington, 1987),
We have found that where
science has progressed the farthest, the mind has but regained
from nature that which the mind put into nature. We have found
a strange footprint on the shores of the unknown. We have devised
profound theories, one after another, to account for its origin.
At last we have succeeded in reconstructing the creature that
made the footprint. And lo! it is our own.
Another purpose of the book is to make
you understand and appreciate that we live in a world of systems —
and systems within systems, which are part of even larger systems.
Thus, everything we do in our personal and professional lives has an
impact on the various systems of which we are a part. This “systems
thinking” approach is not only vital for professional systems analysts,
but for all members of modern society. Alas, this book cannot make
you an experienced systems analyst, any more than a book on music theory
can make you an experienced pianist. By the end of the book, you will
be armed with a tremendous amount of technical information that will
help you develop accurate models of complex systems, and you
will know the step-by-step techniques for carrying out a systems analysis
effort. But you will still need a great deal of real-world work to
learn the people skills: how to interview a variety of disparate users
to understand the true essence of a system; how to present the results
of your systems analysis work so that everyone can see a credible estimate
of the costs and benefits of developing a new system; and how to distinguish
problems from symptoms. As Barry Boehm pointed out in his classic work, Software
Engineering Economics (Boehm, 1981):
Each of us as individual software
engineers has an opportunity to make a significant positive impact
on society, simply by becoming more sensitive to the long-range
human relations implications of our work, and by incorporating
this sensitivity into our software designs and products.
It takes some practice
to do this well, and to learn how to balance human
relations concerns with programming and quantitative
economic concerns. The big thing to remember in doing
so is to keep our priorities straight between programming,
budgetary, and human considerations.
1.4 THE ORGANIZATION OF THIS
BOOK
This book
is organized in four major parts, followed by a series
of appendixes. Part I serves as an introduction to the
entire book; it begins, in Chapter
2, with an introduction to the concept of systems
and to the nature of systems analysis. In this chapter,
we will see that information systems are usually composed
of people, hardware, software (computer programs), procedures,
data, and information. Chapter
3 describes the people who are typically involved
in the development of a modern information system —
the users, managers, operations personnel, members of
the quality assurance group, and the like — as
well as the special role and responsibilities of the
systems analyst. Chapter
4 introduces two popular modeling approaches that
systems analyst use: structured analysis and object-oriented
modeling approaches. Chapter
5 introduces the procedures (or methodology) that
the systems analyst follows when developing a system.
Even
if you think you know many of these things already,
there are some chapters in Part I that are important
for you to read, for they set the tone for the rest
of the book. Chapter
2, for example, introduces and discusses the fundamental
axioms and principles that we can expect to find in
all systems analysis work: the development of system
models, the notion of iteration, and the notion
of top-down partitioning. And Chapter
6 outlines the major issues facing systems analysts
today: issues of productivity, system quality, maintainability,
and strategic use of information. Finally, Chapter
7 summarizes the major changes that took place in
the field of systems analysis during the tumultuous
decade of the 1990s.
Part
II discusses systems modeling
tools in detail. Individual
chapters cover the topics
of dataflow diagrams (Chapter
9), object-oriented models
(Chapter
10), data dictionaries
(Chapter
11), process specifications
(Chapter
12), and state-transition
diagrams (Chapter
13). Chapters
14 and 15
discuss various other modeling
tools that systems analysts
use when studying a system:
PERT charts, Gantt charts,
flowcharts, HIPO diagrams,
structure charts, and so on.
As we will see, these modeling
tools allow us to selectively
focus on individual aspects
of a system whose characteristics
are important to understand:
the functions that the system
must perform, the data that
it must keep track of, and
its time-dependent behavior.
Even if you never see a computer
after you finish reading this
book, the modeling tools in
Part II will be useful in
whatever you do. You will
find that modeling tools can
be useful to model (or describe
or “picture”)
virtually any kind
of system: biological systems,
business systems, ecosystems,
manufacturing systems, political
systems, material-flow systems,
and so on. We live in a world
of systems, and much of our
daily life is spent trying
to comprehend and work with
the many different systems
with which we come in contact;
modeling tools are enormously
helpful in this respect.
Part III is concerned with
the process of systems analysis — that is, the steps that a
systems analyst goes through when constructing a system model. Here,
too, the information you learn in this part of the book will be useful
regardless of your ultimate profession; but the material is definitely
slanted toward the construction of automated information systems. We
will see that the process, or methodology, for building a system involves
the development of several different types of models, the last of which
is the product or output of systems analysis. In many business organizations,
this product is known by such names as a “functional specification,”
or a “business requirements document,” or a “business systems
design.” Regardless
of its name, it becomes the input to the person (or people) who are
responsible for actually building the system — that is, designing
the overall architecture of computer hardware and software and ultimately
writing and testing the computer programs.
This
leads us to Part IV: life after systems analysis. We
will explore the transition from systems analysis to
systems design and briefly discuss the final details
of programming and testing. Since most automated information
systems have a lifetime of several years (and often
several decades), we will also discuss the subject of
maintenance in Chapter
24; but our concern will not be with maintenance
programming, but rather with the maintenance
of the product of systems analysis. The last chapter
deals with the future: evolutionary changes in the field
of systems analysis that we can expect to see during
the 1990s and on into the next century.
Appendixes
at the end of the book deal with separate issues that
may or may not affect you when you begin working as
a systems analyst. Appendix
A, for example, deals with the subject of automated
tools for developing systems analysis models. Appendix
B discusses estimating formulas and metrics used
to calculate the size, duration, and cost of a project.
Appendix
C discusses the economics of cost-benefit calculations.
Appendix
D covers the subject of walkthroughs and inspections,
which are often used to review the technical products
of systems analysis. Appendix
E discusses interviewing and data-gathering techniques,
particularly those interviews that take place between
user and systems analyst. All of these have been arranged
as appendixes so that experienced systems analysts can
skip them easily; beginning students can turn to the
appendixes whenever convenient to cover topics that
will surely emerge during real-world projects.
Appendices
F and G present
two case studies: one is a business-oriented system,
and one is a real-time system. If you are a first-time
student, at the end of each chapter you should look
at these case studies to see how newly learned principles
can apply in real-world situations. In fact, you should
read the introduction and background of each case study
now so that you will be familiar with the nature of
each application.
Each chapter has a number
of questions and exercises to help you review what you have learned.
Some exercises are labeled “Research Project,” which means that
they address issues that are not covered directly in the chapter but
that
are relevant in the real world of systems analysis. Some of the questions
are intended for classroom discussion; there are no right or wrong
answers, but there are answers that are more easily defended than others!
So much for introductions. Let’s get started! We will begin by talking
about the nature of systems.
REFERENCES
-
Tom
DeMarco, Structured Analysis and Systems Specification.
Englewood Cliffs, N.J.: Prentice-Hall, 1979, page
6.
-
John
Gall, Systemantics. New York: Quadrangle/The
New York Times Book Company, 1977, page xiii.
-
Barry
Boehm, Software Engineering Economics. Englewood
Cliffs, N.J.: Prentice-Hall, 1981.
-
Seymour Papert, Mindstorms. New York: Basic
Books, 1980.
-
Edward Yourdon, Nations at Risk. Englewood
Cliffs, N.J.: YOURDON Press, 1986.
-
Sir Arthur Stanley Eddington, Space, Time and
Gravitation: An Outline of the General Theory.
London: Cambridge University Press, 1987.
QUESTIONS AND EXERCISES
-
Explain
how systems analysis might be useful in your job
or profession even if you are not planning to become
a programmer or systems analyst.
-
Research Project: How many people are employed as
systems analysts in the United States today? What
is their average salary? What is their average level
of education?
-
Research Project: Is there a shortage of programmers
and systems analysts in the United States? Try to
find industry surveys or government surveys (e.g.,
from the U.S. Commerce Department or the National
Science Foundation) that predict the nation’s
requirements for systems analysts over the next
ten years.
-
Give ten examples of systems that you deal with
or interact with in your day-to-day life.
-
Would you be studying the subject of systems analysis
if you didn’t have to? If your answer is “No,”
explain why you think the material won’t be
useful or relevant. Find someone else studying this
same material and engage in a constructive debate
about the general usefulness of systems analysis.
-
Do you think it is important for non-computer people
(people who do not work in the computer field as
a profession) to study systems analysis? How expert
do you think they should be in the subject?
-
Why is systems analysis likely to be more interesting
than programming? Do you agree with this point of
view?
-
What things must a systems analyst learn besides
the technical skills of building system models?
-
How can modeling tools of the kind presented in
this book be useful for studying non-computer systems?
FOOTNOTES
-
[1] If
you are under 30 years of age, it’s hard to imagine that you have not
written a computer program; after all, virtually every school and college
now teaches something about computer programming. But you may not have
written a really complicated computer program. If you haven’t spent at
least a month working on the same program — working 16 hours a day,
dreaming about it during the remaining 8 hours of restless sleep, working
several nights straight through trying to eliminate that “one last bug”
from the program — then you haven’t really written a complicated computer
program. And you may not have the sense that there is something exhilarating
about programming. (By the way, everyone in the industry will tell you
that you should not be building large, complex computer programs — and
that the object of the game is to build simple, comprehensible programs.
This is true: but imagine the mental energy and the sleepless nights
that must have gone into the creation and development of something like
the Macintosh MacPaint program, or the first version of Lotus 1-2-3.)
-
[2]There
are a variety of other career paths that you might follow, too.
You might specialize in the area of telecommunications and network
design;
or you might concentrate on database design, or “data administration.”
While most of this book assumes that you will be concerned with
application systems (payroll, inventory, accounting, or real-time
applications
like missile guidance, telephone switching, and process control),
you might also concentrate on systems programming projects — for
example,
compilers or operating systems. All of this is likely to represent
your second or third job in the computer industry: chances are
that you’ll start in the business as a junior programmer (where
you will
be expected to know how to write relatively simple programs,
or make maintenance changes to existing programs), and then progress
to senior
programmer before finally being promoted to the position of systems
analyst. As a systems analyst, you will be expected to have broader
skills than that of a programmer: in addition to knowledge of
computer
hardware and software, you will be expected to be able to communicate
well with noncomputer people, and you will be expected to be
familiar with their business applications.
-
[3] For
more details on this, as well as other discussions of the impact
of computers on society, see Nations at Risk (Yourdon,
1986).
|
