Professional Documents
Culture Documents
Introduction To Information Systems
Introduction To Information Systems
Introduction To Information Systems
We build systems like the Wright brothers built airplanes-- build the whole thing, push it
off a cliff, let it crash, and start over again.
R.M. Graham
If builders built buildings the same way that programmers wrote programs, the first
woodpecker would destroy civilisation.
Gerald Weinberg
Introduction
We shall study the characteristics of a system, its attributes and some basic concepts and
strategies for studying them. Our philosophy is that an accounting information system is
merely a kind of an information system which in turn is a kind of a system. Therefore, the
study of basic principles of systems in general and, information systems in particular, is
important for a thorough understanding of accounting information systems. Our approach
to the study of accounting information systems, as will become clear, is an engineering
one, where one proceeds through a methodical path of specification, design, construction,
testing & evaluation, operation and maintenance. A well engineered system is easy to
understand, build, maintain, and upgrade.
What is a system?
A system is a set of inter-dependent components (some of which may be systems in their
own right) which collectively accomplish certain objectives.
A Contextual view
Any system operates by interacting with its environment. The contextual view describes
graphically the interaction of the system with the various entities in its environment. The
interactions consist of dataflows from and to such entities.The contextual view clarifies
the boundary of the system and its interfaces with the environment in which it operates.
Figure: Contextual View
A Control view
Any system must manipulate certain variables in order to achieve its objectives. It
determines the manipulation needed by processing its outputs/states in relation to certain
control parameters.
Figure: Contextual View
References
Booch, G. (1994) bf Object-Oriented Analysis and Design with Applications, 2nd ed.
Redwood City, California: The Benjamin Cummings Publishing Company, Inc.
Gall, J. (1986) Systemantics: How Systems Really Work and How They Fail, 2nd ed.
Ann Arbor, MI : The General Systemantics Press.
Simon, H. (1982) The Sciences of the Artificial. Cambridge, MA : The MIT Press.
Martin, J. and McClure, C. (1988) Structured Techniques: The Basis for CASE,
Revised ed. Englewood Cliffs, NJ : Prentice Hall.
Shaw, M. (1981) ALPHARD: Form and Content. New York, NY: Springer-Verlag.
Introduction to Systems Development
My experience has shown that many people find it hard to make their design ideas
precise. They are willing to express their ideas in loose, general terms, but are unwilling
to express them with the precision needed to make them into patterns. Above all, they are
unwilling to express them as abstract spatial relations among well-defined spatial parts. I
have also found that people aren't always very good at it; it is hard to do..... If you can't
draw a diagram of it, it isn't a pattern. If you think you have a pattern, you must be able to
draw a diagram of it. This is a crude, but vital rule. A pattern defines a field of spatial
relations, and it must always be possible to draw a diagram for every pattern. In the
diagram, each part will appear as a labeled or colored zone, and the layout of the parts
expresses the relation which the pattern specifies. If you can't draw it, it isn't a pattern.
Introduction
The work of Christopher Alexander, a mathematician-turned architect, has had a subtle
and yet a profound impact on the methodologies for the development of information
systems in business. The main idea in architecture, espoused by Alexander, is that
buildings and cities can be designed from the combination of certain basic patterns. Such
patterns can be documented as diagrams which, in the architectural domain, specify
spatial relationships. In the domain of business (and accounting) information systems
development, the task is to create languages for describing and manipulating patterns to
create systems that meet the needs of business.
In this note, we shall study the types of information systems used in the business, the way
in which information systems are specified, and the various methodologies for the
development of information systems.
The components of accounting systems such as payroll, general ledger are, it should be
obvious, usually batch processing systems, and also transaction processing systems that
are transformational systems. Systems for determination of sample sizes for audit testing,
on the other hand may be decision support systems. Systems aiding provision for
doubtful accounts (or loan loss reserves for financial institutions) may be expert systems.
Why specifications?
Specification of any system before its development is crucial. Specifications perform for
information systems the same function that blue-prints and engineering specifications
perform for physical structures. Specifications serve as benchmarks for evaluating
designs as well as their implementation. They also facilitate quality assurance via
verification (are we building the system right, ie., do the design and implementation meet
the specifications?) and validation ( are we building the right system, ie., does the system
meet the user needs?).
Components of specifications
Specification of an information system is given by their
Most CASE tools co-ordinate information systems projects through a project or system
dictionary. The function of the dictionary is to standardise the use of terms throughout the
organisation and to serve as a repository of all common information in the project. It
enforces consistency as well as (relative) completeness of the specifications, and
facilitates verification & validation of such specifications. It also serves as a means of
communication between the different persons on the information systems building team.
The figure below shows the various components of the specifications and the modeling
techniques utilised. We will be studying some of those techniques in this course.
Figure: Specification of Information Systems
The methodology SDLC is closely linked to what has come to be known as structured
systems analysis & design. It involves a series of steps to be undertaken in the
development of information systems as follows:
The waterfall model has many attractive features: Clearly defined deliverables at the end
of each phase, so that the client can take decisions on continuing the project. Incremental
resource committment. The client does not have to make a full committment on the
project at the beginning. Isolation of the problem early in the process.
Alexander, C. (1979). A Timeless Way of Building. New York, NY: Oxford University
Press.
This has been my experience in Washington when I had money to give away. If I gave a
contract to a designer and said, ``The doorknob to my office doesn't have much
imagination, much design content. Will you design me a new doorknob?" He would say
``Yes," and after we establish a price he goes away. A week later he comes back and says,
``Mr. Eberhard, I have been thinking about that doorknob. First we ought to ask ourselves
whether a doorknob is the best way of opening and closing a door." I say, ``Fine, I believe
in imagination, go to it." He comes back later and says, ``You know, I have been thinking
about your problem, and the only reason you want a doorknob is you presume you want a
door to your office. Are you sure that a door is the best way of controlling egress, exit,
and privacy?" ``No, I'm not sure at all." ``Well, I want to worry about that problem." He
comes back a week later and says, ``The only reason we have to worry about the aperture
problem is that you insist on having four walls around your office. Are you sure that is
the best way of organizing this space for the kind of work you do as a bureaucrat?" I say,
``No, I'm not sure at all." Well, this escalates until (and this has literally happened in two
contracts, although not exactly through this process) our physical designer comes back
with a very serious face. ``Mr. Eberhard, we have to decide whether capitalistic
democracy is the best way to organize our country before I can possibly attack your
problem."
On the other hand is the problem of infinite regression. If this man faced with the design
of the doorknob had said, ``Wait. Before I worry about the doorknob, I want to study the
shape of man's hand and what a man is capable of doing with it," I would say, ``Fine." He
would come back and say, ``The more I thought about it, there's a fit problem. What I
want to study first is how metal is formed, what the technologies are for making things
with metal in order that I can know what the real parameters are for fitting the hand."
``Fine." But then he says, ``You know, I have been looking at metal forming and it all
depends on metallurgical properties. I really want to spend three or four months looking
at metallurgy so that I can understand the problem better." ``Fine." After three months he
will come back and say, ``Mr. Eberhard, the more I look at metallurgy, the more I realize
that it is the atomic structure that's really at the heart of this problem." And so, our
physical designer is in atomic physics from the doorknob. That is one of our anxieties, the
hierarchical nature of complexity.
Eberhard (1970) quoted in Teague & Pidgeon (1985) and Yourdon (1989)
Introduction
The understanding and management of complexity is perhaps the most important task of
the designer of an information system. It is carried out bearing in mind the strategies of
abstraction as well as hierarchical ordering (divide & conquer).
In the real world, an accounting information systems designer (systems designer for
short) is rarely called upon to analyse and design a system from the scratch. Usually, such
a system does exist, but the client (user) is not quite satisfied with it. The systems
designer starts with the documentation of the existing accounting system, if it does not
exist. Often, documentation pertaining to the existing system is contained in the audit
workpapers pertaining to the auditor's study of control risk assessment. However, since
such documentation is not prepared with a view to design a system, it is used only as a
starting point in building the documentation to aid systems design.
In this document, we shall study how abstraction and hierarchical ordering strategies are
used to manage the complexity of analysing and designing the functions of an
information system.
STEP 0: (Defining the scope of the system under study.) This accomplished by
drawing the context diagram for the system.
STEP 1: (Documentation of how the existing system works.) This is accomplished
by drawing the Physical DFDs of the existing system. These DFDs specify the
current implementation of the existing system, and would answer questions such
as:
Who performs the tasks?
How they are performed?
When or how often they are performed?
How the data is stored (media)?
How the dataflows are implemented (media)?
These physical DFDs may be levelled, or, if the system is not very large, prepared
all on a single DFD.
In this step, man-machine boundaries are drawn, and media selected for all dataflows &
datastores
Dataflow Diagrams
The function of any information system can be expressed in terms of transformation
(processing) of certain inputs (which are data) into outputs (which are data too) where
memory (which too consists of data) may need to be consulted (or updated). This
suggests that two crucial elements in a system's description are data and processing of
data. A complete description of an information system demands description of both these
elements. In fact, we can reduce this, in a mundane fashion to the equation:
Datastores & Dataflows: Datastores can not create (or destroy) any data. What
comes out of a datastore therefore must first have got into a datastore through a
process.
Processes: Processes can not create data out of thin air. Processes can only
manipulate data they have received from dataflows. Data outflows from processes
therefore must be derivable from the data inflows into such processes.
Levelling Conventions:
Numbering: The system under study in the context diagram is given number `0'.
The processes in the top level DFD are labelled consecutively by natural numbers
beginning with 1. When a process is exploded in a lower level DFD, the processes
in such lower level DFD are consecutively numbered following the label of such
parent process ending with a period or full-stop (for example 1.2, 1.2.3, etc.).
Balancing: The set of DFDs pertaining to a system must be balanced in the sense
that corresponding to each dataflow beginning or ending at a process there should
be an identical dataflow in the exploded DFD.
Datastores: Datastores may be local to a specific level in the set of DFDs. A
datastore is used only if it is referenced by more than one process.
External entities: Lower level DFDs can not introduce new external entities. The
context diagram must therefore show all external entities with which the system
under study interacts. In order not to clutter higher level DFDs, detailed
interactions of processes with external entities are often shown in lower level
DFDs but not in the higher level ones. In this case, there will be some dataflows at
lower level DFDs that do not appear in the higher level DFDs. In order to
facilitate unambiguous balancing of DFDs, such dataflows are crossed out to
indicate that they are not to be considered in balancing. This convention of
crossing is quite popular, but this text does not follow it. I would rather you
followed this convention.
Context diagram
levelled logical dataflow diagrams
Relation specifications for a Relational Database
Specifications for the dataflows
Process descriptions in raw prolog code. (Prolog is a relational language. The
code is given here, since prolog code is generally easily grasped). The code given
here, with very minor changes, should be executable.
I will not provide the physical DFDs below, since they are implementation dependent,
and I have not based this toy system on any real-world accounting system.
We have yet to discuss the data models and databases. We will not be discussing
programming aspects of systems. Therefore, the database specifications are given as a
prelude to our class discussions on databases later in the semester. The code is given just
for the purpose of appreciation.
We are talking about a very small firm that considers orders from customers for one item.
You should be able to add bells and whistles as you wish. The situation considered is
rather unrealistic, but it makes important points about specifications for an accounting
system and its documentation.
Dataflow Diagrams:
Context Diagram: (Sales Order Entry & Processing System)
Level 0 Logical Dataflow Diagram: (Sales Order Entry & Processing System)
Figure: Level 0 Dataflow Diagram
Dataflow Specifications
sorryBadCredit(CustomerName, CustomerAddress)
Datastore Specifications:
priceList(Item, Price)
inventoryMaster(Item, QuantityOnHand)
customer(CustomerName, CustomerAddress)
Process Specifications:
if
priceList(Item, Price),
if
not priceList(Item, - ).
if
sorryBadCredit(CustomerName, CustomerAddress)
if
if
inventoryMaster(Item, QuantityOnHand),
if
if
if
updateCustomerAccountsForInvoices
if
References
Eberhard, J. (1970) We Ought to Know the Difference, in Engineering Methods in
Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT
Press. pp.364-365.