Out of Pod Experience

Was it: A boys room becomes progressively messy until acted upon by an external force (mum) to clean it?

System Entropy - 3rd Edition.txt

Page 96.

Part One / Systems Development Fundamentals
Chapter 3 / A System Development Life Cycle

FIGURE 3.2 Systems En-
tropy Occurs Sometime
During the Systems Sup-
port Phase - - This flow
diagram of the life cycle
demonstrate what hap-
pens when a system is
placed into operation -- it
enters the support phase
of the life cycle. From that
point on, it is subject to
modification and en-
hancement, until such a
time as the system en-
tropy sets in and the sys-
tem has become obsolete
or too costly to maintain.


1.
Systems
planning

2.
Systems
analysis

3.
Systems
design

4.
Systems
implementation

5.
[Systems] blue to 2. New, related problem or requirement
[support] blue to 3. New implementation or alternative or requirement
- - - blue to 4. Implementation error (bug)
- - - red to 1. Obsolete system

Entropy is the term systems experts use to describe the natural and inevita-
ble decay of all systems. Entropy is illustrated in Figure 3.2. Notice that, after a
system is implemented, it enters the support phase of the life cycle. during the
support phase, the analyst encounters the need for changes that range from
correcting simple mistakes, to redesigning the system to accomodate chang-
ing technology, to making modifications to support changing user require-
ments. As indicated by the blue arrows, many of these changes direct the analyst
and programmer to rework former phases of the life cycle. Eventually, the cost
of maintenance exceeds the costs of starting over -- the system has become
obsolete. This is indicated by the red arrow in the figure.
Unfortunately, systems that are designed to meet only current requirements
are usually difficult to modify in response to new requirements. The systems
analyst is frequently forced to duplicate files and "patch" programs in ways that
make the system very costly to support over the long run. As a result, many
systems analysts become frustrated with how much time must be dedicated to
supporting existing, patchworked systems and how little time is left to work on
important, new systems development.
Even if you design the system to easily adapt to change (our last pinciple), at
some point in time, it will become too costly to simply support the existing
system. Why? Perhaps the organization itself has changed too dramatically to be
supported by the system. Or perhaps the requirements have become too com-
plex to be patched into the existing system. In either case it is time to start over!
This situation puts the term "cycle" into the term "systems development life cycle".
No system lasts forever (although many do last a decade or longer).
It doesn't have to be that way! Today's tools and techniques make it possible
to design systems that can grow and change as requirements grow and change.
This book will teach you many of those tools and techniques. For now, it's more
important to simply recognize that flexibility and adaptability do not happen by
accident -- they must be "built" into a system.

(Scans done, but not properly transferred yet.)