Chapter 4

Systems Development Process

4.1 Introduction
IT governance, part of an organization’s overall mission, goals, policies,
and procedures, is the process of ensuring that IT is used effectively,
efficiently, and strategically. A comprehensive IT strategy requires
careful systems study and should prioritize the acquisition or
development of various information systems, including operating and
application systems, such as accounting information systems.
The IT systems study includes planning and analysis through
development, implementation, and a feedback loop for each new IT
application. Some systems will be designed in-house, while others may
be purchased. Selecting a system among alternatives is part of the IT
systems study process.
Developing effective, strategic information systems is the job of
systems programmers, analysts, designers, users, and managers.
Accountants, as auditors and general information users, should be
involved with all IT studies, especially accounting information systems.
As you might imagine, studying a large AIS is a large and difficult task.
A systems study (also called systems development work) begins with
a formal investigation of an existing information system..
4.2 Problem Analysis and BPR

Investigating Current Systems

Planning for IT includes constant monitoring of current systems. When
any appear to have problems, the systems study team performs a
preliminary investigation of the system in question and advises the
steering committee of its findings. One important part of this work is to
separate symptoms from causes. The study team may consider
alternatives to the current system; attempt to estimate the costs and
benefits of its proposed solutions, or make recommendations for
desired alternatives. In this phase of the project, the study team ‘‘think
outside the box’’ (i.e., to consider vastly different and innovative
approaches to address current problems).
This phase of the systems study is a preliminary investigation report
describing the problems or objectives the study team identified,
solutions or alternatives it investigated, and further course(s) of action
it recommends.
Systems Analysis
The basic purpose of the systems analysis phase is to examine a
system in depth. The study team will familiarize itself with the
company’s current operating system, identify specific inputs and
outputs, identify system strengths and weaknesses, and eventually
make recommendations for further work.
In performing its work, the study team should strive to avoid
overanalyzing a company’s system. Instead, the team should try to
identify and understand the organization’s goals for the system,
perform a systems survey, and prepare one or more reports that
describe its findings.
For the study team to determine the real problems within a company’s
information system, its members must first understand the system’s
goals.
The study team must determine whether the current information
system helps to achieve general systems goals. For example, if an AIS
has excessive costs associated with using traditional paper documents
(e.g., purchase orders, receiving reports, and vendor invoices), this will
violate goal
number one
(cost awareness), and
the study team
might recommend that
the company use a
web- based system
instead.

Business process reengineering (BPR) is about

redesigning business processes that are no longer efficient or effective.
As an example, consider the order process that begins with inquiries
from a customer about the products available for sale and ends when
the customer pays cash to complete a sale. In many organizations,
several individuals handle the order process. Each person has
responsibility for a particular function: a receptionist or secretary may
handle inquiries, a salesperson follows up on product inquiries,
warehouse personnel assume responsibility for filling the order, an
accounts receivable clerk bills the customer, and so on. This division of
responsibility makes it difficult for some organizations to fill customer
orders quickly. The result: dissatisfied customers.
Reengineering the order process may result in an integration of
functional activities so that one specified individual handles customers
from start to finish. This redesign means a customer knows who to talk
to when an order is late and the customer is not passed around from
one person to another when problems occur

4.3 Systems Development and

Documentation
Four Stages in the Systems Development Life Cycle
Traditionally, we can identify four major steps or phases of a systems
study:
1. Planning and Investigation This step involves performing a
preliminary investigation of the existing system, organizing a systems
study team, and developing strategic plans for the remainder of the
study.
2. Analysis This step involves analyzing the company’s current
system in order to identify the information needs, strengths, and
weaknesses of the existing system.
3. Design In this step, an organization designs changes that eliminate
(or minimize) the current system’s weak points while preserving its
strengths.
4. Implementation, Follow-up, and Maintenance This phase
includes acquiring resources for the new system as well as training
new or existing employees to use it. Companies conduct follow-up
studies to determine whether the new system is successful and, of
course, to identify any new problems with it. Finally, businesses must
maintain the system, meaning correcting minor flaws and updating the
system as required.

Documentation
Documentation explains how AISs operate and is therefore a vital part
of any accounting system. For example, documentation describes the
tasks for recording accounting data, the procedures that users must
perform to operate computer applications, the processing steps that
AISs follow, and the logical and physical flows of accounting data
through the system. Accountants can use many different types of logic
charts to trace the flow of accounting data through an AIS. For
example, document flowcharts describe the physical flow of order
forms, requisition slips, and similar hard-copy documents through an
AIS. These flowcharts pictorially represent data paths in compact
formats and therefore save pages of narrative description. System
flowcharts are similar to document flowcharts, except that system
flowcharts usually focus on the electronic flows of data in computerized
AISs. Other examples of documentation aids include process maps,
data flow diagrams, program flowcharts, and decision tables.
Why Documentation?
Accountants do not need to understand exactly how computers
process the data of a particular accounting application, but it is
important for them to understand the documentation that describes
how this processing takes place. In fact a recent survey of practitioners
found that system documentation has become increasingly important
as organizations seek to better understand their own business
processes and also comply with legislation that requires this
understanding.
Documentation includes all the flowcharts, narratives, and other
written communications that describe the inputs, processing, and
outputs of an AIS. Documentation also describes the logical flow of
data within a computer system and the procedures that employees
must follow to accomplish application tasks. There are many other
tools for documenting AISs namely, document flowcharts, system
flowcharts, process maps, program flowcharts, decision tables and
data flow diagrams.
.

Document Flowcharts
A document flowchart traces the physical flow of documents through
an organization—i.e., from the departments, groups, or individuals who
first create them to their final dispositions. The Figure below illustrates
common document flowcharting symbols, and the examples below
illustrate how to use them to create simple document flowcharts.
Constructing a document flowchart begins by identifying the different
departments or groups that handle the documents of a particular
system. The flow charter then uses the symbols in the Figure to

illustrate the document flows.

Example 1 Your boss asks you to document the paperwork involved in

acquiring office supplies from your company’s Central Supplies
Department. Your administrative assistant explains the process as
follows:
Reordering supplies requires a requisition request. When I need
more stationery, for example, I fill out two copies of a goods
requisition form (GRF). I send the first copy to central supplies
and file the second copy here in the office.
There are two departments involved in this example—your department
(which we shall call the Requesting Department) and the Central
Supplies Department. Thus, you should begin by naming these
departments in headings on your document flowchart. Next, you draw
two copies of the GRF under the heading for the Requesting
Department because this is the department that creates this form. You
number these copies 1 and 2 to indicate two copies. Finally, you
indicate where each document goes: copy 1 to the Central Supplies
Department and copy 2 to a file in the Requesting Department. A
document’s first appearance should be in the department that creates
it. A solid line or the on-page connectors shown here indicates its
physical transmittal from one place to another. You should then redraw
the transmitted document to indicate its arrival at the department that
receives it. The Figure below illustrates the completed flowchart for
this narrative.

System
Flowcharts
Whereas document flowcharts focus on tangible documents, system
flowcharts concentrate on the computerized data flows of AISs. Thus,
a system flowchart typically depicts the electronic flow of data and
processing steps in an AIS. The Figure below illustrates some common
system flowcharting symbols. Most of these symbols are industry
conventions that have been standardized by the National Bureau of
Standards,
Example:- Figure 3-6 refers to only one process—preparing a payroll.
A more detailed system flowchart would describe all the processes
performed by the payroll program and the specific inputs and outputs
of each process. At the lowest, most-detailed level of such
documentation are program flowcharts that describe the processing
logic of each application program.
 4.4
Systems Design, Implementation
Operation and Maintenance
Systems Design: - Once the steering committee approves the
feasibility of a general system plan (project), the design team can
begin work on a detailed systems design. This involves specifying
the outputs, processing procedures, and inputs for the new system.
Just as construction blueprints create the detailed plans for building a
house, the detailed design of a new system becomes the specifications
for creating or acquiring a new information system.
Figure 13-5 provides examples of the detailed requirements that the
design team must create, and these requirements in turn explain
specifically what the proposed system must produce. From an
accounting standpoint, one of the most important elements in a new
system is its control requirements. In this matter, the design team
should have a ‘‘real-time’’ mentality when designing control
procedures for a system. In other words, rather than adding controls
after a system has been developed and installed, the team should
design cost-effective general and application control procedures into
the system as integrated components.
Designing System Outputs, Processes, and Inputs
Once the design team finds a system feasible and creates a general
design, it can focus on developing the system’s input, processing, and
output requirements. When performing design tasks, it is perhaps
curious that the design team first focuses on the outputs—not the
inputs or processing requirements—of the new system. The reason for
this is that the most important objective of an AIS is to satisfy users’
needs. Preparing output specifications first lets these requirements
dictate the inputs and processing tasks required to produce them.
During the analysis phase and general system design, the study team
develops boundaries for the new system. These boundaries define the
project’s scope. However, as the design team works with users, they
are likely to be asked to do additional work. Outside consultants often
handle these requests by drafting proposals showing the additional
costs associated with them. These costs can include delays in meeting
the schedule for delivering the project.
System Outputs The design team will use the data gathered from the
prior systems analysis work to help it decide what kinds of outputs are
needed as well as the formats that these outputs should have.
Although it is possible for the design team to merely copy the outputs
of an older system, this would make little sense—the new system
would be just like the old one. Instead, the team will attempt to create
better outputs—that is, design outputs that will better satisfy their
users’ information needs than did the old system.
Process Design Until now, the system designers have focused on
what the system must provide rather than how the system can provide
it. After designing the outputs, their next step is to identify the
processing procedures required to produce them. This involves
deciding which application programs are necessary and what data
processing tasks each program should perform.
Designing System Inputs Once the design team has specified the
outputs and processing procedures for a new project, its members can
think about what data the system must collect to satisfy these output
and processing requirements. Thus, the team must identify and
describe each data element in the systems design (e.g., ‘‘alphabetic,’’
‘‘maximum number of characters,’’ and ‘‘default value’’) as well as
specify the way data items must be coded. This is no easy task,
because there are usually a large number of data items in even a small
business application.

4.5 Implementation, Follow-Up, and

Maintenance
Systems implementation is often called the ‘‘action phase’’ of a
systems study because the recommended changes from the prior
analysis, design, and development work are now put into operation.
But systems implementation can also be a stressful time. As the time
draws near for installing a new system, end users and clerical
personnel become nervous about their jobs, middle managers wonder
if the new system will deliver the benefits as promised, and top
managers become impatient when installations run longer than
anticipated or go over budget. Even if an organization did a perfect job
of analyzing, designing, and developing a new system, the entire
project can fail if its implementation is poor.
Implementation Activities
Implementing a new accounting information system involves many
activities and tasks that will vary in number and complexity depending
on the scale of the system and the development approach. Some of
the steps that may be involved are:
 Prepare the Physical Site
 Determine Functional Changes.
 Select and Assign Personnel.
 Train Personnel
 Acquire and Install Computer Equipment
  Establish Internal Controls
 Test Computer Software.
 Convert to the New System

Post-Implementation Review
Regardless of which conversion method used, the new system will
eventually become the sole system in operation. This brings us to the
final, follow-up and maintenance phase of our systems
development life cycle. The purpose of this phase is to monitor the new
system and make sure that it continues to satisfy the organizational
goal. When these goals are not adequately satisfied, problems
normally occur and the system requires further modifications.
System Maintenance
In practice, implementation teams do not normally perform follow-up
studies of their company’s new information system. Instead, the team
turns over control of the system to the company’s IT function, which
now shoulders the responsibility for maintaining it. In effect, system
maintenance continues the tasks created by the initial follow-up
study, except that experts from the company’s IT subsystem now
perform the modifications exclusively. For example, when users
complain about errors or anomalies in the new system, it becomes the
IT subsystem’s responsibility to respond to these needs, estimate the
cost of fixing them, and (often) perform the necessary modifications.
The IT departments of even medium-size companies typically have
forms for such requests, policies for prioritizing maintenance tasks, and
formulas for allocating maintenance costs among the various user
departments.