Accounting Information System

Chapter Three
The System Development Process
Learning Objectives:
Upon completion of this chapter, students shall be able to:
 Prepare data flow diagrams to understand, evaluate, and design information systems.
 Draw flowcharts to understand, evaluate, and design information systems.
 Explain the five phases of the systems development life cycle
 Discuss roles of the people who involve in system development process
 Explain the importance of systems development planning
 Describe system planning techniques
 Discuss the various types of feasibility analysis, and calculate economic feasibility
 Explain why a system change triggers behavioral reactions.
 Discuss the key issues and steps in systems analysis.
 Discuss the conceptual systems design process and the activities in this phase.
 Discuss the physical systems design process and the activities in this phase.
 Discuss the systems implementation and conversion process and the activities in this phase.
 Discuss the systems operation and maintenance process and the activities in this phase.
 Describe how organizations purchase application software, vendor services, and hardware.
 Explain how information system departments develop custom software.
 Explain how end-users develop, use, and control computer-based information systems.
 Explain why organizations outsource their information systems, and evaluate the benefits and
risks of this strategy.
 Explain the principles and challenges of business process reengineering.
 Describe how prototypes are used to develop AIS
 Explain the role of computer-aided software engineering in developing AIS.

3.1 System Development and Documentation Tools and Technique

Documentation is a vital part of any AIS. Accountants use many different types of diagrams to
trace the flow of accounting data through AIS. A wide variety of soft ware is available for
documenting AISs. Documentation encompasses the narratives, flowcharts, diagrams, and other
written material that explain how the system works. This information covers who, what, when,
where, why, and how of data entry, processing, storage, information output and system controls.
One popular means of documenting a system is to develop diagrams, flowcharts, tables, and
other graphical representations of information. These are then supplemented by a narrative
description of the system, which is a written step-by step explanation of system components and
interactions.
1
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

3.1.1. Importance of Documentation in System Development

The two most common tools of system documentation are dataflow diagrams and flowcharts will
be discussed in this part. These tools save the organization both time and money. Depending on
the job function being performed, documentation tools are important on one or more of the
following levels:
 At minimum, documentation is read to determine how the system works.
 Internal control documentations are evaluated to identify control strengths and
weaknesses and to recommend improvements.
 The greatest amount of skill is needed to prepare documentation.
An understanding of documentation tools is required regardless of the type of accounting career
chosen. For example, auditors are required to understand the client's system of internal controls
before conducting an audit. In general, documentation n is important as in the following
manners:
1. Depicting how the system works: Studying and reviewing written descriptions of the inputs,
processing steps, and outputs of the system make the job easier.
2. Training users: Documentation also includes the user guides, procedure manuals, and other
operating instructions that help people learn how the AIS operate.
3. Designing new systems: Documentation helps system designers develop new systems in
much the same way that blueprints help architects design buildings.
4. Controlling system development and maintenance costs: Good documentation helps system
designers develop object-oriented SW, that is, programs that contain modular, reusable code.
This object-orientation helps programmers avoid writing duplicate programs and facilities
changes when programs must be modified later.
5. Standardizing communications with others: Documentation techniques such as flowcharts
and data flow diagrams are standard industry tools, and they are more likely to be interpreted
the same way by all parties viewing them.
6. Auditing AISs: Documentation helps auditors determine the strengths and weaknesses of a
system’s controls.
7. Documenting business processes: By mapping the business processes, documentation helps
managers better understand the ways in which their businesses operate.
8. Accountability: It is used to establish accountability.

3.1.2. Documenting Business Process

By mapping the business processes, documentation helps managers better understand the ways
in which their businesses operate. The two of the most common and basic documentation tools
are:

2
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

1. Data Flow Diagrams (DFDs): are graphical descriptions of the sources and destinations of
data. They show data flow within an organization i.e. where data comes from and where
it goes, how it flows, the processes performed on it, and how data are stored.
2. Flow Charts: They include three types:
a. Document Flow Chart: is a graphical description of the flow of documents and information
between departments or areas of responsibility within an organization. It traces the
physical flow o f documents through an organization.
b. System Flowchart: is a graphical description of the relationship among the input,
processing, and output in an information system. It shows the electronic flow of data and
processing steps in AIS.
c. Program Flowchart: is a graphical description of the sequence of logical operations that a
computer performs as it executes a program.
These tools are used extensively in the System Development Process. Systems development is
a complex process and these tools are used to create order from chaos and complexity. In
addition, the team members who develop information systems projects often change and
these documentation tools help the new team members get up to speed quickly. Both DFDs
and Flowcharts are easy to prepare and revise when one of the recently developed DFDs or
Flowcharting Software packages is used. They are easier to use than most word processors.
Once a few basic commands are mastered, users can quickly and easily prepare, store, revise,
and print presentation- quality DFDs or Flowcharts.

Tool 1: Data Flow Diagrams (DFDs)

A data flow diagram (DFD) graphically describes the flow of data within an organization. It is used
to document existing systems and plan and design new ones. There is no ideal way to develop a
DFD, because different problems call for different methods. Some general guidelines for
developing DFDs are:
1. Understand the system- involves observing the flow of information through an organization
and interviewing the individuals who use and process the data.
2. Ignore certain aspects of the system- as DFD diagrams the origin, flow, transformation,
storage and destinations of data, all control actions and processes should be ignored.
3. Determine system boundaries- is determining what to include in and exclude form the
system. All relevant data elements shall be included in the DFD because excluded items will
not be considered during systems development. When in doubt about an element's
importance, include it until a definitive decision can be made to discard it.
4. Develop a context diagram- a context diagram is a good way of depicting system
boundaries. In the diagram's center is a circle; inside of it is displayed the system of concern.

3
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

The outside entities, with which the system interacts directly, are in boxes on either side,
connected by data flows depicting the data passed between them. DFDs are prepared, in
successively more detail, to depict data flows in the system.
5. Identify data flows- all data flows shall be identified entering or leaving the system's
boundary, including where the data originate and the final destination. Any significant
movement of information is usually a data flow. All data flows come from and go to either a
transformation process, a data store (file), or a data source or destination. As each of this is
identified, it should be connected to the appropriate data flow. Data flows can move in two
directions, shown as a line with arrows on both ends.
6. Group data flows- a data flow consists of one or more pieces of datum. Data elements that
always flow together should be grouped together and shown as one data flow until they are
separated. If the data elements do not always flow together, then they should be shown as
two separate data flows.
7. Identify transformation processes- this is by placing a circle wherever work is required to
transform one data flow into another. All transformation processes should have one or more
incoming or outgoing data flows.
8. Group transformation processes- transformation processes that are logically related or
occur at the same time and place should be grouped together. Unrelated items shall never
be combined into a single transformation process. If data are not processed together, or are
sometimes processed differently, then, they shall be separate.
9. Identify all files or data stores- data are stored temporarily or permanently in most systems.
Each data repository, and each data flow into and out of it, should be identified.
10. Identify all data sources and destinations- all sources and destinations of data should be
identified and included on the DFD.
11. Name all DFD elements- except for data flows into or out of data stores (data store is
sufficient to identify the data flow), data elements should be given unique and descriptive
names representing what is known about them. This makes DFD easier to read and
understand as it provides the reader with key information. Naming data flows first forces the
developer to concentrate on the all-important data flows, rather than on the processes or
stores. Once data flows have been labeled, naming the process and data stores is usually
easy, because they typically take their names from the data inflows or outflows. Choosing
active and descriptive names such as daily inventory update and validate transaction, rather
than input data or update process. Process names should include action verbs such as
update, edit, prepare, and record.
12. Subdivide the DFD- a cluttered DFD is hard to read and understand. If there are more than
five to seven processes on a single page, then, higher level and lower level DFDs shall be

4
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

used. The context diagram shall be decomposed into high level processes, and then
exploded into successively lower level processes.
13. Give each process a sequential number- in completed DFD, each process is given a
sequential number that helps readers move back and forth between different DFD levels.
Data flows should only go from lower numbered to higher numbered processes.
14. Repeat the process- DFD developers must work through organization data flows several
times. Each subsequent pass helps refine the diagram and identify the fine points. When
refining, the DFD shall be organized to flow from top to bottom and from left to right.
15. Prepare a final copy- the final copy of the DFD shall be drawn. Data flow lines shall be
allowed to cross over each other, if necessary, a data store or destination may be repeated.
The name of the DFD, the data prepared, and the preparer shall be placed on each page.

Elements in a Data Flow Diagram

A DFD is composed of four basic elements: data sources and destinations, data flows,
transformation processes, and data stores. Each will be represented in a DFD by a unique symbol.

Process

Data Stores

Source/Destination
Entity

Data Flow
Demarco & Gane & Sarson
Yourdon Symbols Symbols

These four symbols are combined to show how data are processed. For example, in the diagram
below, the input to Process C is data flow B, which comes from data source A. The outputs of
process C are data flows D and E. Data flow E is sent to data destination J. Process F uses data
flows D and G as input and produces data flows I and G as output. Data flow G comes from and
returns to data store h. Data flow I is sent to data destination K

5
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

i. A data source or data destination symbol on the DFD represents an organization or

individual that sends or receives data that they system uses or produces. An entity can be
both a source and a destination. Data sources or destinations are represented by a square.
ii. A data flow represents the flow of data between processes, data stores and data sources
and destinations. Data that passes between data stores and either a data source or a
destination must go through some form of data processing (transformation process). Data
flow arrows are labeled to indicate the type of data being passed. Thus, the reader knows
exactly what information is flowing; no inferences are required. A data flow can consist of
one or more pieces of datum. In the diagram below data flow B is labeled Customer
Payment; Item D (remittance data); E (deposit); G (unlabeled; represents information
entered into or retrieved from an accounts receivable data file), and I (receivable
information) A data flow can consist of one or more pieces of datum. For example, data
flow B (customer payment) in the diagram below consists of two parts: a payment and
remittance data. Process 1.0 (process payment) splits these two data elements and sends
them in different directions. The remittance data (D) flows to another process, where it is
used to update accounts receivable records, and the payment (E) is sent to the bank with
a deposit slip. Because data flows may consist of more than one data element, the
designer must determine the number of lines to show. The determining factor is if the
data elements always flow together. For example customers may send inquiries about the
processing o f their payments with payments or separately.
iii. A transformation process represents the transformations of data. The diagram below
shows that process payment (C) takes customer payment and splits into the remittance
6
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

data and the deposit (which includes the checks and deposit slip created within process
payment). The updating receivables (F) process takes the remittance data (D) and the
accounts receivables (H) data, producing updated receivables record and sending
receivables information to the credit manager.
iv. A data store is a temporary or permanent repository of data. DFDs do not show the physical
storage medium such as disks, and paper, used to store data. As with other DFD elements,
data store names should be descriptive. Data stores are represented by horizontal lines, with
respective name recorded inside.
v. A data dictionary contains description of all the elements, stores, and flows in a system.
Data flows and data stores are typically collections of data elements. Typically, a master copy
of the data dictionary is maintained to ensure consistency and accuracy throughout the
development process.

Types of DFDs
1. Physical Data Flow Diagrams: A Physical DFD documents the physical structure of an existing
system. It answers questions such as where an entity works, how an entity works, the work
is done by whom, etc. Given the very physical focus of a physical DFD, it changes whenever
the entities, technology used to implement the system, etc. changes. Physical DFDs have no
lower levels. Physical DFD focuses on physical entities as well as the tangible documents,
reports, and similar hard-copy inputs and outputs that flow through the system. Physical DFD
lists the job tit le of one typical employee and it is simple, more readable, and therefore more
easily understood.

7
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

2. Logical Data Flow Diagrams: Logical Data Flow Diagrams document the processes in an
existing or proposed system. It used to document what tasks the system performs. The
logical DFD focuses on the logical flow of data. Because the logic of a system changes
infrequently, relative to its physical nature, a logical DFD will remain relatively constant over
time. Logical Data Flow Diagrams are usually drawn in levels that include increasing amounts
of detail. Logical Data flow diagrams typically have levels below the level-0 diagram.

Decomposing (Subdividing) DFD

Data flow diagrams are subdivided into successively lower levels in order to provide ever-
increasing amounts of detail because few systems can be diagrammed on one sheet of paper.
Users have differing needs, so a variety of levels can better satisfy these requirements. A top level
(High-Level) Logical DFD that provides an overall picture of an application or system is called a
Context Diagram.

8
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

A context diagram provides the reader with a summary level view of the system. It depicts a data
processing system and the external entities that are the sources and destinations of the system's
inputs and outputs. It does focus either on the tasks or the physical entities. It shows the overall
picture of the system. For example, the following can be considered as the context diagram of
payroll processing procedures for a certain company. It shows that the payroll processing system
receives time card data from different departments and employees' data from the human
resource department. When these data are processed, the system produces:
1. Tax reports and payments for governmental agencies
2. Employee payments
3. A deposit in the payroll account at the bank, and
4. Payroll data for management.

9
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

10
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Tool 2: Flowcharts
A flowchart is an analytical technique used to describe some aspect of an information system in a
clear, concise, and logical manner. Flowcharts use a standard set of symbols to pictorially describe
transaction processing procedures. The following are general guidelines for preparing flowcharts
that are readable, clear, concise, consistent, and understandable.
1. Understanding a system before flowcharting it by interviewing users, developers, auditors,
and management or having them complete a questionnaire as well as by reading through a
narrative description of the system, or walking through system transactions.
2. Identifying the entities to be flowcharted such s departments, job functions, or external
parties as well as identifying documents and information flows in the system and the
activities or processes performed on the data, for instance drawing a box around the
entities, a circle around the documents and a line around the activities.
3. Dividing the flowchart into columns when several entities such as departments and
functions need to be shown on the flowchart with a label for each followed by flowcharting
the activities of each entity in its respective columns.
4. Flowcharting only the normal flow of operations, ensuring that all procedures and
processes are in proper order and identifying exception procedures by using an annotation
symbol.
5. Designing the flowchart so that flow proceeds from top to bottom and from left to right.

11
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

6. Giving the flowchart a clear beginning and ending by designing where the document
originated and showing the final disposition of all documents so there are no loose ends
that leave the reader dangling.
7. Using the standard flowcharting symbols and drawing them with a template or a computer
8. Clearing labeling all symbols by writing a description of the input, process, or output inside
the symbol. If description may not fit, annotation symbol shall be used.
9. Placing document numbers in the top right hand corner of the symbol when using multiple
copies of a document. The document numbers should accompany the symbols as it moves
through the system.
10. Having an input and output for each manual processing symbol. Two documents shall not
be connected directly except when moving from one column to another column.
11. Using on page connectors to avoid excess flow lines, which results in a neat looking page as
well as using off-page connectors to move from one flowchart page to another. All
connectors shall be clearly labeled to avoid confusion.
12. Using arrowheads on all flow lines and not assuming that the reader will know the direction
of the flow.
13. Clearly labeling the pages 1 of 3, 2 of 3 etc if a flowchart can not fit into a single page.
14. Showing documents or reports first in the column in which they are created and then
moving to another column for further processing. A manual process is not needed to show
documents being flowcharted.
15. Showing all data entered into or retrieved from a computer file as passing through a
processing operation (a computer program) first.
16. Drawing a line from the document to a file to indicate that it is being filed. A manual process
is not needed to show a document entering a file.
17. Drawing a rough sketch of the flowchart as a first effort. Concern shall be with capturing
content than perfect drawing. Few systems can be flowcharted in a single draft.
18. Redesigning the flowchart to avoid clutter and a large number of crossed lines.
19. Verifying the flowchart's accuracy by reviewing it with the people familiar with the system.
It shall be assured that all uses of flowchart conventions are consistent.
20. Drawing the final copy of the flowchart, placing the name of the flowchart, the date, and
the preparer's name on each page.

Flowchart Symbols
There are various types of symbols used to create flowcharts. Each symbol has a special meaning
that is easily conveyed by its shape. The shape indicates and describes the operation performed
and the input, processing, output, and storage media employed. The symbols are drawn by a
software program or with a flowcharting template.
12
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Flowcharting symbols can be divided into the following four categories:

1. Input/output symbols- represent devices or media that provide input to or record output
from processing operations.
2. Processing symbols- either show what type of device is used to process data or indicate
when processing is completed manually.
3. Storage symbols- represent the device used to store data that the system is not currently
using.
4. Flow and miscellaneous symbols- indicate the flow of data and goods. They also represent
such operations as where flowcharts begin and end, where decisions are made, and when to
add explanatory notes to flowcharts.

13
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

14
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Document Flowcharts
A document flowchart illustrates the flow of documents and information among areas of
responsibility within an organization. They trace a document from its cradle to its grave. They
show where a document originates, its distribution, the purpose for which it is used, its ultimate
disposition, and everything that happens as it flows through the system. A document flowchart is
particularly useful in analyzing the adequacy of control procedures in a system, such as internal
checks and segregation of duties. Flowcharts that describe and evaluate internal controls are
often referred to as internal control flowcharts.

The document flowchart can reveal weaknesses or inefficiencies in a system such as inadequate
communication flows, unnecessary complexity in document flows, or procedures responsible for
15
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

causing wasteful delays. They also can be prepared as part of the system design process and
should be included in the documentation of an information system.

Major flowchart symbols are available from EXCEL. To view the Drawing Toolbar of
MS EXCEL, select the following options from the main menu:
In EXCEL, “View/Toolbar/Drawing”
Or you can also click directly on the Drawing icon in the Standard Toolbar.
After the Drawing Toolbar appears, select “Auto shapes/Flowchart”. You can observe
approximately 28 symbols.

Following is a typical example of how a document flowchart can be designed:

16
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

System Flowcharts
System flowcharts depict the relationship among the input, processing, and output of AIS. A
system flowchart begins by identifying both the inputs that enter the system and their origins. The
input is followed by the processing portion of the flowchart. The input is followed by processing
portion of the flowchart that is the steps performed on the data. The logic the computer uses to
perform the processing task is shown on a program flowchart. The resulting new information is
the output component, which can be stored for later use, displayed on a screen, or printed on
paper. In many instances, the output from one process is an input to another.

System flowcharts are an important systems analysis, design, and evaluation tool. They are
universally employed in systems work and provide an immediate form of communication among
workers. The system flowchart is an excellent vehicle for describing information flows and
procedures within AIS. An illustration of how a system flowchart works is shown below:

Program Flowcharts
A program flowchart illustrates the sequence of logical operations performed by a computer in
executing a program. It describes the specific logic to perform a process shown on a systems
flowchart. A flow line connects the symbols and indicates the sequence of operations. The
processing symbol represents a data movement or arithmetic calculation. Once designed and
approved, the program flowchart serves as the blueprint for coding the computer program.
 The input/output symbol represents either reading of input or writing of output.

17
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 The decision symbol represents a comparison of one or more variables and the transfer of
flow to alternative logic paths.
 All points where the flow begins or ends are represented by the terminal symbol.

Following is another example of a program flowchart for master file updating process.

18
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Differences between DFDs and Flowcharts

 DFDs emphasize the flow of data and what is happening in a system, whereas a flowchart
emphasizes the flow of documents or records containing data.
 A DFD represents the logical flow of data, whereas a flowchart represents the physical flow
of data.
 Flowcharts are used primarily to document existing systems DFDs, in contrast, are primarily
used in the design of new systems and do not concern themselves with the physical devices
used to process, store, and transform data.
 DFDs make use of only four symbols where as Flowcharts use many symbols and thus can
show more detail.

3.2. Systems Development Process

Because the environment is competitive and ever changing, organizations continually face the
need for new, faster, and more reliable ways of obtaining information. To meet this need, an
information system must continually undergo changes, ranging from minor adjustments to major
overhauls. Occasionally, the changes are so drastic that the old system is scrapped and replaces by
an entirely new one. Change is so constant and frequent that most organizations are involved in
some system improvement or change. This due to one of the following reasons:
1. Changes in user or business needs- increased completion, business growth or consolidation,
merger and divestiture, new regulations, or changes in regional and global relationships can
alter an organization's structure and purpose. To remain responsive, the system must
change as well.
2. Technological change- as technology advances and becomes less costly, an organization can
make use of the new capabilities or existing ones that were previously too expensive.
3. Improved business processes- many companies have inefficient business processes that
require updating.
4. Competitive advantage- Increased quality, quantity and speed of information can result in an
improved product or service and may help lower costs.
5. Productivity gains-computers automate clerical and repetitive tasks and significantly
decrease the performance time of other tasks. Expert systems place specialized knowledge
at the disposal of many others.
6. Growth- companies outgrow their systems and must either upgrade or replace them
entirely.
7. Downsizing- companies often move from centralized mainframes to networked PCs or to
Internet-based systems to take advantage of their price/performance ratios. This places

19
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

decision making and its corresponding information as far down the organization chart as
possible.

3.2.1. The key Players in System Development Process

The Players refer to who are the people involved in developing and implementing AIS?
 Management
 Accountants
 Information systems steering committee
 Project development team
 Systems analysts and programmers
 External players
What are top management’s roles?
 providing support and encouragement
 establishing system goals and objectives
 determine information requirements
What are accountants’ roles?
 determine their information needs
 may be members of the project development team
 play an active role in designing system controls
What are the steering committee’s roles?
 set policies that govern the AIS
 ensures top-management participation
 guidance and control
 facilitates coordination and integration of IS activities
What are the project development team’s roles?
 plan each project
 monitor project
 make sure proper consideration is given to the human element
What are the system analyst’s and programmer’s roles?
 study existing systems
 design new systems and prepare specifications
 write computer programs
Important questions in designing a system are:
1. What process must the company go through to obtain and implement a new system?
2. What types of planning are necessary to ensure the system’s success?
3. How will employees react to a new system?
4. How should the new system be justified and sold to top management?
20
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

5. How can expected costs and benefits be quantified to determine whether the new system
will indeed be cost-effective?

3.2.2. The Systems Development Life Cycle

Whether systems changes are major or minor, most companies go through a systems
development life cycle. The systems development life cycle (SDLC) is a conceptual model used in
project management that describes the stages involved in an information system development
project, from an initial feasibility study through maintenance of the completed application. It is a
logical process by which systems analysts, software engineers, programmers and end-users build
information systems and computer applications to solve business problems and needs.
Systems development methodology can be used as a synonym for the life cycle. Systems
development methodology is a very formal and precise system development process that defines
a set of activities, methods, best practices, deliverables, and automated tools that system
developers and project managers are to use to develop and maintain information systems and
software.
Various SDLC methodologies have been developed to guide the processes involved, including:
1. the waterfall model (which was the original SDLC method);
2. rapid application development (RAD);
3. joint application development (JAD);
4. the fountain model;
5. the spiral model;
6. build and fix; and
7. synchronize-and-stabilize
Frequently, several models are combined into some sort of hybrid methodology. Documentation
is crucial regardless of the type of model chosen or devised for any application, and is usually done
in parallel with the development process. Some methods work better for specific types of
projects, but in the final analysis, the most important factor for the success of a project may be
how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated- deficiencies are identified. This can be done by
interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined- in particular, the deficiencies in the existing
system must be addressed with specific proposals for improvement.
3. The proposed system is designed- plans are laid out concerning the physical construction,
hardware, operating systems, programming, communications, and security issues.

21
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

4. The new system is developed- the new components and programs must be obtained and
installed. Users of the system must be trained in its use, and all aspects of performance must
be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use-this can be done in various ways. The new system can phased in,
according to application or location, and the old system gradually replaced. In some cases, it
may be more cost-effective to shut down the old system and implement the new system all
at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated.
Maintenance must be kept up rigorously at all times. Users of the system should be kept up-
to-date concerning the latest modifications and procedures.

Romney and Steinhart identified the following five as the components of SDLC.
1. Systems analysis
2. Conceptual design
3. Physical design
4. Implementation and conversion
5. Operations and maintenance

In the next part, the five steps in the systems development life cycle (SDLC) will be elaborated:

Stage 1: Systems Analysis: Systems analysis is the first step in SDLC where in-depth
understanding about a system starts. At this stage, the information needed to purchase or
develop a new system is gathered. Since analysis is too costly (in terms of time, effort, money,
etc), it is mostly started after the project is approved and green light is obtained from the
management. When a new or improved system is needed, a written request for systems
development is prepared. The request describes the current system’s problems, why the change is
needed, and the proposed system’s goals and objectives. It also describes the anticipated benefits
and costs.
System analysis is the stage of:
 studying the current business system
 understanding how the existing system works
 determining the weakness and strength of the existing system
 defining the business needs and requirements (user requirement determination and
system requirement determination independent of technology issues), etc

22
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

There are five steps in the analysis phase:

1. Initial investigation- is conducted to screen projects. At this stage, the following are essential:
 Gaining a clear picture of the problem or need
 Determining the project's viability and expected costs and payoffs
 Evaluating the project's scope and the nature of the new AIS, and

23
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 Recommending whether the development project should be initiated as proposed,

modified or abandoned.
At this stage the exact nature of the problems under review must be determined. Sometimes,
what is thought to be the cause of the problem is not the real source. If a project is approved, a
proposal to conduct system analysis is prepared. It is assigned a priority and added to the
master plan, and the development team begins the survey of the existing AIS.
2. Systems survey- at this stage, an extensive study of the current AIS is undertaken. It may take
weeks or months depending on the complexity and the scope of the system. The objectives
of a system survey include:
 Gain a thorough understanding of the company operations, policies, and procedures; data
and information flows; AIS strengths and weaknesses; and available hardware, software,
and personnel.
 Make preliminary assessment of current and future processing needs, and determine the
extent and nature of the changes needed.
 Develop working relationships with users and build support for the AIS
 Collect data that identify user needs, conduct a feasibility analysis and make
recommendations to management.
 Finally, the findings are documented, the existing system is modeled and analyzed and a
survey report is prepared.
3. Feasibility study- a more thorough feasibility analysis is conducted to determine the project's
viability. Especially important is economic feasibility. The feasibility analysis is updated as the
project proceeds and costs and benefits become clearer.
4. Information needs and systems requirements- once a project is deemed to be feasible, the
company identifies the information needs of the AIS users and documents system
requirements. the strategies for determining requirements include the following:
 Ask users what they need
 Analyze existing system
 Examine existing system use
 Create a prototype
5. Systems analysis report- is the conclusion of the system analysis phase. It is used to
summarize and document the analysis activities and serve as a repository of data from which
system designers can draw. A go-no-go decision is generally made three times during system
analysis:
 During the initial investigation- to determine whether to conduct a feasibility survey
 At the end of the feasibility study- whether to proceed to the information requirements
phase

24
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 At the completion of the analysis phases- to decide whether to proceed to the next
phase.
Requirements determination tries to collect information on what system should do from many
sources like users, reports, forms, etc. Characteristics for gathering requirements are:
i. Impertinence—question everything
ii. Impartiality—find the best organizational solution and don’t try to justify the
importance of your suggestions at any cost.
iii. Relaxation of constraints--assume that any thing is possible
iv. Attention to detail—due consideration should be given to facts (information)
v. Reframing—analysis is a creative process. Try to address situations in a new way.
Don’t jump to conclusions thinking you have done the same thing before

Deliverables of analysis include:

 Information collected from users
 Interview results
 Questionnaire summaries
 Notes from observations, etc.
 Existing documents and files
 Mission and strategy statements
 Forms and reports
 Procedure manuals
 Job descriptions, etc
 Understanding of organizational components
 Business objectives
 Information needs
 Rules of data processing
 Key events

Tools to collect information are:

1. Traditional Methods
a. Interview
b. Questionnaire
c. Observation
d. Document analysis
2.Modern Methods
a. Joint Application Design (JAD)
 started in late 1970s at IBM

25
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 Brings together key users, managers and systems analysts involved in the analysis
of the current system
 Its structure of roles and its agenda differentiates it from group interview
 Purpose: collect system requirements simultaneously from key people
 Conducted off-site—away from the normal work place for the people involved—to
minimize distraction
b. Prototyping
 Repetitive process involving analysts and users
 Rudimentary version of system is built and rebuilt based on feedbacks
 Replaces or augments SDLC
 Goal: to develop concrete specifications for ultimate system
 Quickly converts requirements to working version of desired system
 Once the user sees requirements converted to physical system, they ask for
modifications or generate additional requests
Used when:
 User requests are not clear
 Few users are involved in the system
 Designs are complex and require concrete form
 History of communication problems between analysts and users
 Tools are readily available to build prototype
Drawbacks:
 Tendency to avoid formal documentation
 Difficult to adapt to more general user audience
 Sharing data with other systems is often not considered
 Systems Development Life Cycle (SDLC) checks are often bypassed

3.Radical Method
a. Business Process Reengineering (BPR)
 Mostly when the traditional methods are used to determine requirements, they
result in automation the existing system with some modification.
 Analysts focus on the problems and opportunities of the current system
 This has a direct impact on the future system
 The work on the identification and implementation of radical change on
business processes to achieve major improvements is Business Process
Reengineering (BPR)
Goals:
 Reorganize complete flow of data in major sections of an organization
26
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 Eliminate unnecessary steps

 Combine steps
 Become more responsive to future change

Stage 2: Conceptual System design: System design is the evaluation of alternative solutions
and the specification and construction of a detailed computer based solution. It is also called
physical design as it deals with implementation issues. Systems analysis depends more on the
logical aspect, implementation-independent aspects of a system /the requirements. Systems
design concentrates on the physical or implementation-dependent aspects of a system (the
systems technical specifications).
In the conceptual systems design phase, a general framework is developed for implementing
user requirements and solving problems identified in the analysis phase. What are the three steps
in conceptual design?

Step 1: Evaluate design alternatives: The design team should identify and evaluate design
alternatives using the following criteria:
 How well it meets organizational and system objectives
 How well it meets users’ needs
 Whether it is economically feasible
 Its advantages and disadvantages
 Prepare design specifications.
 Prepare conceptual systems design report.

Step 2: Prepare design specifications: Once a design alternative has been selected, the team
develops the conceptual design specifications for the following elements:
 Output
 Data storage
 Input
 Processing procedures and operations

Step 3: Prepare conceptual systems design report: At the end of the conceptual design a
conceptual systems design report is developed and submitted.
 To guide physical systems design activities
 To communicate how management and user information needs will be met
 To help assess systems’ feasibility

27
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Stage 3: Physical System Design

A. Output Design: The objective of output design is to determine the characteristics of
reports, documents, and screen displays. Output fits into one of four categories:
 Scheduled reports
 Special-purpose analysis
 Triggered exception reports
 Demand reports
B. File and Database Design: What are some file and database design considerations?
 medium of storage
 organization and access
 processing mode
 maintenance
 size and activity level
C. Input Design: When evaluating input design, the design team must identify the different
types of data input and optimal input method. What are the two principal types of data
input?
 Forms
 Computer screens
D. Procedures Design: it should answer who, what, where, and how questions related to all
AIS activities. What should procedures cover?
 input preparation  database access
 transaction processing  output preparation and
 error detection and corrections distribution
 controls  computer operator
 reconciliation of balances instructions
E. Control Design: What are some control design considerations?

 Validity  Authorization

 Accuracy  Security

 Numerical Control  Availability

 Maintainability  Integrity

 Audit Control
F. Design Report: At the end of the physical design phase the team prepares a physical
systems design report. This report becomes the basis for management’s decision whether
to proceed to the implementation phase.
28
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Stage 4: Implementation and conversion: Systems implementation is the process of

installing hardware and software and getting the AIS up and running. The relationship of the
items in this phase and the conversion process (next phase) will be as shown below in a series of
activities.

1. Implementation Planning: An implementation plan consists of implementation tasks,

expected completion dates, cost estimates, and the person or persons responsible for each
task. Planning should include adjustments to the company’s organizational structure.
2. Develop and test software programs: Seven steps are followed when developing and
testing software programs.
a. Determine user needs.
b. Develop a plan.
c. Write program instructions (code).
d. Test the program.
e. Document the program.
f. Train program users.
g. Install and use the system.
3. Site Preparation: A PC requires little site preparation. A large system may require extensive
changes, such as additional electrical outlets. Site preparation should begin well in advance
of the installation date.
4. Select and train personnel: Employees can be hired from outside the company or
transferred internally. Effective AIS training should include employees’ orientation to new
policies and operations. Training should occur before systems testing and conversion.

29
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

5. Complete documentation: Three types of documentation must be prepared for new

systems.
a. Development documentation
b. Operations documentation
c. User documentation
6. Test the System: There are three common forms of testing.
a. Walk-through
b. Processing of test transactions
c. Acceptance tests
7. Conversion: There are four conversion approaches.
8. Approach 1: Direct conversion

Approach2: Parallel conversion

Approach 3: Phase-in conversion

Approach 4: Pilot conversion

9. Data Conversion: Data files may need to be modified in three ways:

 Files may be moved to a different storage
 Data content may be changed
 File format may be changed

30
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Stage 6: Operations and Maintenance: What are some factors to consider during the post
implementation review? Goals and objectives, Satisfaction, Benefits, Costs, Reliability, Documentation Timeliness,
Controls and security, Errors , Training, Communications, Organizational changes, Accuracy, Compatibility, etc.

3.2.3. Ongoing Activities over System Development Life Cycle

1. System Development Planning: Why is planning an important step in systems development?
Consistency, efficiency, cutting edge, lower costs, adaptability. What types of systems
development plans are needed?
 project development plan
 master plan
Two techniques for scheduling and monitoring systems development activities are:

Approach 1: PERT (Program Evaluation and Review Technique): PERT requires that all activities
and the precedent and subsequent relationships among them be identified.

31
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Approach 2: Gantt chart: A bar chart with project activities listed on the left-hand side and units of
time across the top.

2. Feasibility Analysis: Systems analysis is the first step in the systems development life cycle
(SDLC). A feasibility study (also called a business case) is prepared during systems analysis and
updated as necessary during the remaining steps in the SDLC. The steering committee uses
the study to decide whether to terminate a project, proceed unconditionally, or proceed
conditionally.
What five important aspects need to be considered during a feasibility study?
32
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

a. Technical feasibility
b. Operational feasibility
c. Legal feasibility
d. Scheduling feasibility
e. Economic feasibility: Economic feasibility is the most frequently analyzed of the five
aspects.
What is the basic framework for feasibility analysis?
 capital budgeting model
 What are some capital budgeting techniques?
 payback period
 net present value (NPV)
 internal rate of return (IRR)
3. Behavioral Aspects of Change: Individuals involved in systems development are agents of
change who are continually confronted by people’s reaction and resistance to change. The
best system will fail without the support of the people it serves. Why do behavioral problems
occur?
 personal characteristics and background
 manner in which change is introduced
 experience with prior changes
 communication
 disruptive nature of the change process
 fear
How do people resist AIS changes?
 aggression
 projection
 avoidance
How can behavioral problems be overcome?
 meet needs of the users
 keep communication lines open
 maintain a safe and open atmosphere
 obtain management support
 allay fears
 solicit user participation
 make sure users understand the system
 provide honest feedback
 humanize the system
 describe new challenges and opportunities

33
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 reexamine performance evaluation

 test the system’s integrity
 avoid emotionalism
 present the system in the proper context
 control the users’ expectations
 keep the system simple

3.2.4. Improving System Development Process

Approach 1: Business Processes Reengineering (BPR): It is the thorough analysis and
complete redesign of business process and information systems to achieve performance
improvements.
 It is a process that challenges traditional organizational values and cultures associated with
underperformance.
 BPR reduces a company to its essential business processes and focuses on why they are
done rather than on the details of how they are done.
 It completely reshapes organizational work practices and information flows to take
advantage of technological advancements.
Principles of Reengineering: What are the seven principles of business processing reengineering?
1. Organize around outcomes, not tasks.
2. Require those who use the output to perform the process.
3. Require those who produce information to process it.
4. Centralize and disperse data.
5. Integrate parallel activities
6. Empower workers, use built-in controls, and flatten the organization chart.
7. Capture data once, at its source.
Challenges Faced by Reengineering Efforts: What are some of the obstacles to
reengineering efforts?

 Tradition  Resistance

 Time requirements  Risk

 Lack of management support  Skepticism

 Retraining  Controls

34
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Approach 2: Prototyping: It is an approach to systems design in which a simplified working

model of a system is developed. A prototype, or “first draft,” is quickly and inexpensively built
and provided to users for testing. What four steps are involved in developing a prototype?
i. Identify basic systems requirements.
ii. Develop an initial prototype that meets the agreed-on requirements.
iii. Users identify changes, developers make changes, and the system is turned over to the
user.
iv. Use the system approved by the users.

Advantages of Prototyping
 Better definition of user needs
 Higher user involvement and satisfaction
 Faster development time
 Fewer errors
 More opportunity for changes
 Less costly
Disadvantages of Prototyping
 Significant user time
 Less efficient use of system resources
 Incomplete systems development
 Inadequately tested and documented systems
 Negative behavioral reactions
 Unending development

Approach 3: Computer-Aided Software Engineering (CASE) Tools: It is an integrated

package of computer-based tools that automate important aspects of the software development
process.
 CASE tools are used to plan, analyze, design, program, and maintain an information
system.
 They are also used to enhance the efforts of managers, users, and programmers in
understanding information needs.
Advantages of CASE Technology
 Improved productivity
 Improved program quality
 Cost savings
 Improved control procedures
 Simplified documentation
35
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Disadvantages of CASE Technology Incompatibility

 Cost
 Unmet expectations

3.3. AIS Development Strategies

Traditionally, Accountants have faced the following difficulties in developing AIS:
 Demands for development resources are so numerous that AIS projects are backlogged for
several years.
 A newly designed AIS doesn't always meet users needs

Approach 1: Purchase Software

 Canned software is written by software development companies and is sold on the open
market to a broad range of users with similar requirements.
 Turnkey systems are a combination of software and hardware sold as a package. The
vendor installs the entire system and user needs only to “turn the key”.
The Internet has given companies a new way to acquire software: Application service providers
(ASPs) host Web-based software on their computers and deliver the software to their clients over
the Internet.

Purchasing Software and the SDLC

Companies that buy rather than develop AIS software still go through the systems development
life cycle (SDLC).
1. Systems analysis
2. Conceptual design
3. Physical design
4. Implementation and conversion
5. Operation and maintenance

36
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

Approach 2: Development by In-House IS Department

 Most often, organizations develop their own custom software, because canned software
that fit their specific needs is not available.
 Developing custom software is difficult and error-prone.
 It also consumes a great deal of time and resources.

Custom Software Development by an Outside Company

When contracting with an outside organization, a company should maintain control over the
development process. Some guidelines:
 Carefully select a developer
 Sign a contract
 Plan and monitor each step
 Maintain effective communication
 Control all costs

End-User-Developed Software
 End-user computing (EUC) is the hands-on development, use, and control of computer-
based information systems by users.
 With the advent of inexpensive PCs and powerful, inexpensive software, users began
developing their own systems to create and store data, access and download company
data, and share data and computer resources in networks.
 Examples of end user development uses:

37
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 Retrieving information from company databases to produce simple reports or to answer

one-time queries
 Performing “what if” sensitivity or statistical analyses
 Developing applications using prewritten software (spreadsheet or database system)
 Preparing schedules and lists, such as depreciation schedules, accounts receivable aging,
and loan amortizations

Benefits of End-User Computing

 User creation, control, and implementation
 Systems that meet user needs
 Timeliness
 Freeing up IS resources
 Versatility and ease of use

Risks of End-User Computing

 Logic and development errors
 Inadequately tested applications
 Inefficient systems
 Poorly controlled and documented systems
 Systems incompatibility
 Duplication of systems
 Increased costs

Organizations use several different approaches to manage and control end-user computing. For
example, a help desk can encourage, support, coordinate and control end-user activities. What are
some duties of the help desk?
 Providing hot-line assistance to help resolve problems
 Serving as a clearinghouse for information, coordination, and assistance training end
users, and providing corresponding technical maintenance and support
 Evaluating new end-user hardware and software products
 Assisting with application development
 Developing and implementing standards
 Controlling corporate data

Approach 3: Outsource the System

What is outsourcing? It is hiring an outside company to handle all or part of an organization’s data
processing activities.
38
Addis Ababa University; School of Commerce; Wogayehu W.
 Accounting Information System

 In a mainframe outsourcing agreement, the outsourcers buy their client’s computers

and hire all or most of the client’s employees.
 In a client/server or PC outsourcing agreement, an organization outsources a particular
service, a segment of its business, a particular function, or PC support.
Benefits of Outsourcing
 A business and information solution
 Asset utilization
 Access to greater expertise and more advanced technology
 Lower costs
 Improved development time
 Elimination of peaks and valleys usage
 Facilitation of downsizing
Risks of Outsourcing
 Inflexibility
 Loss of control of system and/or data
 Reduced competitive advantage
 Locked-in system
 Unfulfilled goals
 Possibility of poor service

39
Addis Ababa University; School of Commerce; Wogayehu W.