In this chapter, the material highlights a number of concepts of
systems, the workload and reasons behind the workload in a system's life cycle.
In this part, you'll get to know the techniques applied in studying survey
methods, topic discussions, specification of systems' requirement and
analysis skills. After reading this part, you'll gain more experience in
dealing with systems issues which managers, users of different levels, and
technicians, consider through different views.
There are many common types of systems that we come into contact with
every day. It is important to be familiar with different kinds of systems for
at least two reasons:
First, even though your work as a
systems analyst will probably focus on one kind of system – an automated,
computerized information system – it will generally be a part of a larger
system. For example, you may be working on a payroll system, which is part of a
larger “human resources” system, which is, in turn, part of an overall business
organization (which is itself, a system), which is, in turn, part of al larger
economic system, and so on. Thus, to make your system successful, you must
understand the other systems with which it will interact. Many of the computer
systems that we build are replacements, or new implementations of,
non-computerized systems that are already in existence. Also, most computer
systems interact with, or interface with, a variety of existing systems (some
of which may be computerized and some which may not). If our new computer
system is to be successful, we must understand, in reasonable detail, how the
current system behaves.
Second, even though many types of
systems appear to be quite different, they turn out to have many similarities.
There are common principles and philosophies and theories that apply remarkably
well to virtually all kinds of systems. Thus, we can often apply to systems
that we build in the computer field, what we have learned about other systems,
based on our own day-to-day experience, as well as the experience of scientists
and engineers in a variety of fields.
Thus, if we understand something of general systems theory, it can help
us better understand computerized (automated) information systems. Today, this
is more and more important, because we want to build stable, reliable systems
that will function well in our complex society, and of course, there are many
examples of non-computer systems that have survived for thousands of years.
And now, we can consider a definition of the basic term
"system". It provides several definitions:
1. A regularly interacting or interdependent group of items
forming a unified whole.
2. An organized set of doctrines, ideas, or principles,
usually intended to explain the arrangements or working of a systematic whole.
3. An organized or established procedure.
4. Harmonious arrangement or pattern: order.
5. An organized society or social situation regarded as
stultifying establishment.
There are many different types of systems, but indeed, virtually
everything that we come into contact with during our day-to-day life is either
a system or a component of a system (both).
It is useful to organize the many different kinds of systems into useful
categories. Because our ultimate focus is on computer systems, we will divide
all systems into two categories: natural systems and man-made systems.
There are a lot of systems that are not made by people: they exist in
nature and, by and large, serve their own purpose. It is convenient to divide
natural systems into two basic subcategories: physical systems and living
systems.
Physical systems include such diverse example as:
Stellar systems: galaxies, solar
systems, and so on.
Geological systems: rivers, mountain
ranges, and so on.
Molecular systems: complex
organizations of atoms.
Physical systems are interesting to study because we sometimes want to
modify them. We also develop a variety of man-made systems, including computer
systems, which must interact harmoniously with physical systems; so it is often
important to be able to model those systems to ensure that we understand them
as fully as possible.
Living systems encompass all of the myriad animals and plants around us,
as well as our own human race. The properties and characteristics of familiar
living systems can be used to help illustrate and better understand man-made
systems.
The living systems, whether at the level of the cell, the organ, the
organism, the group, the organization, the society, or the supranational
system, all contain the 19 subsystems:
1. The reproducer, which is capable of giving rise to other
systems similar to the one it is in.
2. The boundary, which holds together the components that
make up the system, protects them from environmental stresses, and excludes or
permits entry to various sorts of matter-energy and information.
3. The ingestor, which brings matter-energy across the
system boundary from its environment.
4. The distributor, which carries inputs from outside the
system or outputs from its subsystems around the system to each component.
5. The converter, which changes certain inputs to the system
into forms more useful for the special processes of that particular system.
6. The producer, which forms stable associations that endure
for significant periods among matter-energy inputs to the system or outputs
from its converter, the materials synthesized being or growth, damage repair,
or replacement of components of the system, or for providing energy for moving
or constituting the system’s outputs of products or information markets to its
suprasystem.
7. The matter-energy storage subsystem, which retains in the
system, for different periods of time, deposits of various sorts of
matter-energy.
8. The extruder, which transmits matter-energy out of the
system in the form of products or wastes.
9. The motor, which moves the system or parts of it in relation
to part or all of its environment or moves components of its environment in
relation to each other.
10. The supporter, which maintains the proper spatial relationships
among components of the systems, so that they can interact without weighing
each other down or crowding each other.
11. The input transducer, which brings markers bearing information into
system, changing them to other matter-energy forms suitable for transmission
within it.
12. The internal transducer, which receives, from other subsystems or
components within the system, markers bearing information about significant
alterations in those subsystems or components, changing them to other
matter-energy form of a sort that can be transmitted within it.
13. The channel and net, which are composed of a single route in
physical space, or multiple interconnected routes, by which markers bearing
information are transmitted to all parts of the system.
14. The decoder, who alters the code of information input to it through
the input transducer or internal transducer into a private code that can be
used internally by the system.
15. The associator, which carries out the first stage of the learning
process, forming enduring associations among items of information in the
system.
16. The memory, which carries out the second stage of the learning
process, storing various sorts of information in the system for different
periods of time.
17. The decider, which receives information inputs from all other
subsystems and transmits to them information outputs that control the entire
system.
18. The encoder, who alters the code of information input to it from
other information processing subsystems, from a private code used internally by
the system into a public code that can be interpreted by other systems in its
environment.
19. The output transducer, which puts out markers bearing information
from the system, changing markers within the system into other matter-energy
forms that can be transmitted over channels in the system’s environment.
Keep in mind that many man-made systems (and automated systems) interact
with living systems. In some cases, automated systems are being designed to
replace living systems. And in other cases, researchers are considering living
systems as components of automated systems.
Man-made systems include such things as:
1. Social systems: organizations of laws, doctrines,
customs, and so on.
2. An organized, disciplined collection of ideas.
3. Transportation systems: networks of highways, canals,
airlines and so on.
4 Communication systems: telephone, telex, and so on.
5. Manufacturing systems: factories, assembly lines, and so
on.
6. Financial systems: accounting, inventory, general ledger
and so on.
Most of these systems include computers today. As a systems analyst, you
will naturally assume that every system that you come in contact with should be
computerized. And the customer or user, with whom you interact will generally
assume that you have such a bias. A systems analyst will analyze, or study, the
system to determine its essence: and understand the system's required behavior,
independent of the technology used to implement the system. In most case, we
will be in a position to determine whether it makes sense to use a computer to
carry out the functions of the system only after modeling its essential
behavior.
Some information processing systems may not be automated because of
these common reasons: Cost; Convenience; Security; Maintainability; Politics.
Automated systems are the
man-made systems that interact with or are controlled by one or more computers.
We can distinguish many different kinds of automated systems, but they all tend
to have common components:
1. Computer hardware (CPUs, disks, terminals, and so on).
2. Computer software: system programs such as operating systems,
database systems, and so on.
3. People: those who operate the system, those who provide its inputs
and consume its outputs, and those who provide manual processing activities in
a system.
4. Data: the information that the system remembers over a period of
time.
5. Procedures: formal policies and instructions for operating the
system.
One way of categorizing automated systems is by application. However,
this turns out not to be terribly useful, for the techniques that we will
discuss for analyzing, modeling, designing, and implementing automated systems
are generally the same regardless of the application. A more useful
categorization of automated systems is as follows:
1. Batch system: A batch system is one which in it, the
information is usually retrieved on a sequential basis, which means that the
computer system read through all the records in its database, processing and
updating those records for which there is some activity.
2. On-line systems: An on-line systems is one which accepts
input directly from the area where it is created. It is also a system in which
the outputs, or results of computation, are returned directly to where they are
required.
3. Real-time systems: A real-time system may be defined as
one which controls an environment by receiving data, processing them, and
returning the results sufficiently quickly to affect the environment at that
time.
4. Decision-support systems: These computer systems do not
make decisions on their own, but instead help managers and other professional
“knowledge workers” in an organization make intelligent, informed decisions
about various aspects of the operation. Typically, the decision-support systems
are passive in the sense that they do not operate on a regular basis: instead,
they are used on an ad hoc basis, whenever needed.
5. Knowledge-based systems: The goal of computer scientists
working in the field of artificial intelligence is to produce programs that
imitate human performance in a wide variety of “intelligent” tasks. For some
expert systems, that goal is close to being attained. For others, although we
do not yet know how to construct programs that perform well on their own, we
can begin to build programs that significantly assist people in their
performance of a task.
There are a few general principles that are of particular interest to
people building automated information systems. They include the following:
1. The more specialized a
system is, the less able it is to adapt to different circumstances.
2. The more general-purpose a
system is, the less optimized it is for any particular situation. But the more
the system is optimized for a particular situation, the less adaptable it will
be to new circumstances.
3. The larger a system is, the
more of its resources that must be devoted to its everyday maintenance.
4. Systems are always part of
larger systems, and they can always be partitioned into smaller systems.
5. Systems grow. This
principle could not be true for all systems, but many of the systems with which
we are familiar do grow, because we often fail to take it into account when we
begin developing the system.
In the role of a systems analyst, you will work on systems development
projects with a variety of other people. The cast of characters will change
from project to project, the personalities will differ dramatically, and the
number of people that you interact with will range from as few as one to as
many as several dozen. However, the roles are fairly consistent, and you will
see them over and over again. In a typical systems development project, there
are the following major categories of players:
User
Management
Auditors, quality assurance people, and ‘standards bearers”
Systems analysts
Systems designers
Programmers
Operations personnel
The user, the most important player in the systems game, is the person
(or group of people) for whom the system is being built. He or she is the
person whom will be interviewed, often in great detail, to learn what features
the new system must have to be successful. The user is the “owner” in the sense
that he or she receives, or inherits-and thus owns- the system when it is
finally built. And the user is the “customer” in at least two important
respects:
1. As in so many other professions, “the customer is always
right”, regardless of how demanding, unpleasant, or irrational he or she may
seem.
2. The customer is ultimately the person paying for the
system and usually has the right and/or the ability to refuse to pay if he or
she is unhappy with the product received.
In most cases, it is fairly easy to identify the user: the user is
typically the person who makes a formal request for a system. In a small
organization, this is usually a very informal process. In a large organization,
the initiation of a systems development project is usually much more formalized.
Whenever possible, the systems analyst should try to establish direct
contact with the user. Even if other people are involved as intermediaries, it
is important to have regular, face-to-face meeting with the person who will
ultimately inherit the system.
If it is not possible to communicate directly with the user, then the
documentation produced by the systems analyst becomes even more crucial.
The heterogeneity of
Users
One
mistake often made by computer programmers, and sometimes by systems analysts
is to assume that all users are the same. “User” implies that the systems
analyst will only have to interact with one person, even when it is obvious
that more than one user is involved, there is a tendency to think of them as a
formless, shapeless, homogeneous group of humans. Here are two ways of
categorizing users:
Job category, or level of supervision.
Level of experience with data processing.
Categorizing Users by
Job category
On a typical systems analysis
project, we can usually count on interacting with three main job categories:
(a) Operational users: are the clerical, operational, and
administrative people most likely to have the most day-to-day contact with the
new system. There are three things should be kept in mind when working with
operational-level users:
Operational users are very much concerned with the
functions that the system will perform, but they are likely to be even more
concerned with the human interface issues.
Operational users tend to have a “local” view of the
system, they tend to be knowledgeable about the specific job that they do and
the people with whom they have immediate contact. But they often are unfamiliar
with the “big picture”, that is, they may have trouble describing how their activity
fits into the overall organization or what the overall organization’s charter
really is.
Operational users tend to think of systems in very
physical terms, that is, in terms of the implementation technology currently
used to implement the system or in terms of technology that they imagine could
be used.
(b) Supervisory users are employed in a supervisory capacity: they
usually manage a group of operational users and are responsible for their
performance. The significant things to remember about supervisory users are
these:
Many of them are former operational users who have
been promoted to their current position.
One reason that the supervisory user may be perceived
as out of touch with the operational user is that he or she is often measured
and motivated by performance against a budget.
It is usually the supervisory user who thinks of a
new system as a way of reducing the number of operational users or avoiding
further increases in their numbers as the volume of work increases.
The supervisory user will often act as a middleman
between the systems analyst and the operational user.
The supervisory user often thinks in the same
physical terms as the operational user, and this perspective is often just as
local as that of the operational user.
Finally, the supervisory user will be contacted
day-to-day. He or she is the one who will typically define the requirements and
detailed business policy that the system must implement. He or she may be a
passive member of the team, a full-time member of the team, or even the project
manager.
(c) Executive-level users: are generally not
directly involved in a systems development project, unless the project is so
large and so important that it has a major impact on the organization.
To summarize, there are three different types, or levels, of users. Keep
in mind that they have different perspectives, different interests and
priorities, and different backgrounds. These three types of users can be
characterized as shown below:
Operational: Usually has local
view. Carries out the function of the system. Has a physical view of the
system.
Supervisory user: May or may not
have local view. Generally familiar with operation. Driven by budget
considerations. Often acts as a middleman between users and higher levels of
management.
Executive user: Has a global view.
Provides initiative for the project. No direct operating experience. Has a
strategic concern.
