Abstract
This paper
presents a recommended information system physical level design
theory and charting methodology for use in System Analysis and
Design training that is designed for student comprehension and rapid
programmer implementation. It also includes a discussion of
Transaction Processing Systems applications (TPS) which make up the
majority of administration oriented multi-million dollar projects,
but are given little attention in systems analysis and design
training perhaps due to their complexity.
1. Introduction
Fifty years of
designing information systems has created a wide variety of charting
methodologies for the logical and physical level design of TPS,
management information systems (MIS), decision support systems
(DSS), executive information systems (ESS), and office automation
systems (AOS). Logical level design of Transaction Processing
Systems (TPS) applications has normally used the same tools as these
other applications; however their physical level design is much more
complex because of their extensive batch processing and manual
systems requirements. This paper will therefore discuss TPS
applications physical design since their complex structure requires
a more flexible and complex physical level design methodology than
other types of business applications.
Prior to the
description of a recommended physical design methodology for
inclusion in our systems analysis & design training, a discussion of
TPS follows that will highlight the importance and complexity of
these systems.
2. Structure
of Transaction Processing Systems
Figure 1 presents
the typical overall scope of an administrative-oriented TPS
application. It shows the interrelationships of core TPS online and
batch processing with its dependant MIS, DSS, ESS, and interfacing
systems. In fact, successful implementation of large scale
multimillion dollar TPS systems requires the integrated logical and
physical level design of all the elements shown. Perhaps its time
for systems analysis and design training to also present the true
scope and complexity of the modern integrated transaction processing
applications shown in Figure 1.
3. Creating a TPS Physical
Design
Most logical design level TPS structured design is data flow diagram (DFD)
based, since typically the data is simple in structure and
independent from the procedural modules because of the need for
sharing of data between applications. Complex entity relationship
diagrams (ERD) based design methods are therefore seldom required
for TPS systems. At the physical design level however, no
predominate structured design approach has appeared.
This paper
proposes a TPS physical design approach that is easily understood by
users, and easily used by programmer analysts during
implementation. For TPS, a physical design is created from a DFD
based logical design, by separating processes and data stores by
time (daily vs. monthly, day vs. night ...), place (client or
server, centralized vs. distributed...), online vs. batch, and
manual vs. automated. None of these design decisions are fully
illustrated in any of the textbook examples shown later in this
paper. Additionally, proper separation of data flow vs. paper
flows, and people's actions vs. computer processes is almost never
maintained.
Figure 2 presents
an overall physical design approach of a country club restaurant
using VISIO available symbols. The application is modularized
across time and should allow programmers to produce a well
structured program. Students presented with this type of chart have
been able to easily create the four detailed program designs needed
to implement the system. This level of physical charting is the
recommended step needed between logical designs and programming.
The type of
charting shown in Figure 2 or its equivalent should be included in
all systems analysis and design training. The texts should
illustrate physical level design to the point where an
implementation team can start program design, and use the picture
type symbols shown since users and managers can read them.
The closest
methodology to that shown in Figure 2 is a "distributed systems
architecture" approach presented in Whitten (page 509) His
approach to modeling the application architecture of an information
system states that
"The use of logical DFD's to model process requirements is
a fairly accepted practice. However, the transition from
analysis-oriented logical DFD's to design oriented physical DFD's
has historically been somewhat mysterious and elusive. We desire a
high-level general design that can serve as application architecture
for the system, and as a general design for the processes that make
up the system. At the same time, we don't want to get caught up in
a counterproductive modeling exercise that slows our progress in
system design and rapid application development. Simply stated, we
want a blueprint to guide us through detailed design and
construction. The blueprint will identify design units for detailed
specification or rapid system development, which ever is most
productive in our project." (Whitten, pages 529-530)
Whitten's
methodology of producing
1) a network
architecture, 2) a data distribution and technology assignment, 3)
process distribution and technology assignments, and 4)
person/machine boundaries is applicable to this paper's methodology
if care is taken to consider time, place, network structure, batch
processing and other physical level requirements.
The key factor in
producing a useful physical design is the ability both for users to
understand the true scope of the system and for the implementation
team to be able to use it for program, data, and interface design.
That level of charting should to be illustrated in systems analysis
and design training. Figure 2 demonstrates that level of physical
design.
Figure 2:
Physical Level Design Example (Restaurant)
4. Comments of current textbook Physical Design Charting examples
This section
includes an example of a high level logical design and an example of
a middle level physical design from two popular systems analysis and
design texts. They illustrate the simplification trend of charting
examples that have made it so difficult for our students to easily
learn to create programmable designs.
Figures 3a and 3b
illustrate this problem. Figure 3a is an illustration of a TPS
application combing online and batch processing from Shelly et al.
It omits the basic concept of differences in time fundamental to the
separation of these processes. Figure 3b inserts this concept as
well as the idea of a trigger. It may actually be easier to
understand than the simplified figure 3a.
Figure 4a and 4b also illustrate this simplification problem.
Figure 4a illustrates an automated teller machine's (ATM) processing
from Langer (page 72). It omits several key functions including the
start and stop steps, as well as not defining the differed manual
and automated activities shown in Figure 4b. It is simply incorrect
in form and function and misleading to our students.
5. Summary
The author has
used several of the system analysis and design textbooks listed in
the following annotated bibliography with mixed results. When using
a fairly complex TPS for say a country club as a design project,
several class sessions are required before the students can start
detailed program and manual procedure design. This is caused by the
lack in the texts of procedures suitable for true TPS applications.
Therefore, the authors have developed the methodology shown in this
paper to supplement the texts approach. The key to its
effectiveness (as illustrated in the Figure 2 example) is the
inclusion in the design of both manual and automated procedures and
the separation of processes by time and place of actions. This type
of charting appears to save several weeks of frustrating student
work, and is therefore recommended.
6. Annotated Bibliography
This section
includes a listing of selected System Analysis and Design books
including comments on their system level (not program logic level)
coverage of transaction processing systems (TPS), logical level
processing design charting, and physical level processing design
charting.
Dennis, A., Wixom,
B. H., and Roth, R. M. (2006). Systems Analysis & Design: Third
Edition. John Wiley & Sons, Inc.
Batch processing is introduced for data input and report
preparation. Combines logical and physical design using DFD and
Structure Charts.
Hoffer, J. A.,
George, J. F., and Valacich, J. S. (2005). Modern Systems
Analysis and Design: Fourth Edition. Pearson Prentice Hall.
No discussion of batch processing. Physical design
consists only of the incorporation of software, processing and
network technologies.
Langer, Arthur M.
(2001). Analysis and Design of Information Systems: Second
Edition. Springer-Verlag, New York.
Only a historic view of transaction and batch processing
systems. Uses DFD and Object charting symbols.
Pressman, Roger S. (2004). Software Engineering: A
Practitioner’s Approach: 6 Edition, McGraw-Hill Companies, Inc.
The leading advanced systems analysis and design textbook’s
illustrations are at the programming level for mechanization type
applications.
Satzinger, J. W.,
Jackson, R. B., and Burd, S. D. (2005). Object-Oriented Analysis
and Design with the Unified Process. Thomson Course Technology,
Boston.
Has a program logic level orientation.
Shelly, G. B.,
Cashman, T. J., and Rosenblatt, H. J. (2006). Systems Analysis
and Design: Sixth Edition. Thomson Course Technology, Boston.
Separates enterprise computing and transaction processing
systems; discusses both online and batch analysis and design;
logical design includes primarily interface and data structures;
physical design covers very limited scope online and batch
processes.
Whitten, J. L., Bentley, L. D., and Dittman, K. C. (2004).
Systems Analysis and Design Methods: Sixth Edition. McGraw-Hill
Irwin.
Presents a detailed online oriented physical design methodology.
The physical data flow diagram method demonstrates 1) network
architecture, 2) data distribution and technology assignment, 3)
process distribution and technology assignment, and 4)
person/machine boundaries. No illustration of batch physical
design.
