Chapter 8 • Basic Systems Concepts and Tools 341techniques make the system requirements and designs
clear, precise, and consistent to all parties involved in the
process. Additionally, the techniques could be embodied
within a larger approach called a system development
methodology. A methodology is a framework consisting of
guidelines, processes, tools, and techniques for managing
the application of knowledge and skills to address all or part
of a business issue. In addition to the types of structured
techniques discussed in the sections that follow, these
methodologies prescribe who should participate and their
roles, the development stages and decision points, and
specific formats for system documentation.
This section will provide a conceptual introduction to
the most common structured techniques in a general life-
cycle development framework. Two major approaches to
systems building have emerged: procedural-oriented and
object-oriented. Procedural-oriented systems have historically
been the most common, as they appropriately represent a
large class of business activities. They include data-oriented
as well as sequential, process-oriented activities such as
tabulating time cards and printing paychecks, inventory
handling, and accounts payable. Object-oriented (O-O)
techniques are a newer approach to systems development
which often are used with prototyping-like methodologies.
Considered by some to be revolutionary and by others to be
evolutionary, O-O techniques are better suited to the
development of graphical user interfaces (GUIs) and
multimedia applications, but they require an entirely new
way of thinking for veteran IS professionals.
Procedural-Oriented Techniques
In the past the vast majority of IS development projects have
involved automating an existing paper-oriented business
process or updating and expanding an existing automated or
partially automated business process. This reality is reflected
in the fundamental procedural approach to systems
development: Describe what you have, define what you
want, and describe how you will make it so. This process is
akin to the general problem-solving approach of analysis
(detect problems), design (develop solutions and select the
best), and take action (operationalize the chosen solution).
As shown in Figure 8.9, this approach involves
documenting the existing system (the As-Is model),
creating a model of the desired future system (the Logical
To-Be model), and then interpreting the logical future
model as a physical system design (the Physical To-Be
model). The motivation for following such a process
derives in part from human nature. Most people find it
easier to imagine the future by conceiving of how it is
different from today. A systematic effort to document the
existing system can also yield important insights about its
deficiencies and worker ideas about improvements.
This sequential approach is also effective when a
new business process is being implemented at the same
time that a new system is being implemented; it helps
ensure that the new process will work in concert with the
new IS, not against it. As described previously, business
process redesign became increasingly common during
the 1990s.
Describing the three models in Figure 8.9 requires a
significant amount of effort prior to building the software.
Business managers are often surprised at the demands
placed on them to support this definition phase. The
objective of this process is to have a thorough description
of what the construction phase for the system will entail,
so that the project risks can be assessed and planned for
with some level of confidence or the decision can be made
to abandon the project. In fact, actual software coding
during the construction phase typically represents less than
one-quarter of the entire systems development effort
(Page-Jones, 1988). The As-Is model provides a baseline
for the system: Why build a new one if it will not do more
than the old one, do it faster, or avoid existing problems?
The As-Is model typically includes both logical (what—
functions and processes) and physical (how—technology,
including people, and timing) models.
Although developing the As-Is model can be user
intensive, the majority of the effort is typically involved
with developing the second model: abstracting the As-Is
model into the Logical To-Be. Logical To-Be modeling
involves a critical appraisal of existing work processes in
order to- identify major subprocesses, entities, and their inter-
actions - separate processing from the flow of data
- capture relationships between data elements
- determine those entities and processes within the
project scope, and those that are not
The Logical To-Be model shows what the system will do
(functionality), including improvements possibly only
because of new technology. However, new technology per
se is not shown until the Physical To-Be model. As you can
surmise, these two To-Be models are related, and may be
developed iteratively (i.e., logical without much apprecia-
tion for technology first, then the physical, then revision of
the logical to reflect technology capabilities, and so forth),
but it is highly recommended that you begin with the
Document
As-IsCreate Logical
To-BeTranslate into
Physical To-BeFIGURE 8.9 Three-Step Modeling Approach