Developing an Information System

Steps involved in developing an Information System:

Analysis Feasibility Study System Design

Testing Implementation Documentation

Analysis
Very important part in the development of an Information System
Involves looking at an organization or system and
Finding out how information is being handled at the moment
If there is no computer system then the first task will be to look at existing manual systems.
It is possible to find out about existing systems in a number of ways:
Talking to the people who work with the system.
Questionnaires to existing users.
Observing how people use the system.
Reading existing manuals.
If the aim is to improve an existing computer system the methods of analysis previously mentioned are still
important.
The analysis phase often includes a feasibility study.
At the end of this phase a decision needs to be made as to what software to use.

Feasibility Study
Aim of a feasibility study is to see whether it is possible to develop a system at a reasonable cost.
At the end of the feasibility study a decision is taken whether to proceed or not.
A feasibility study contains the general requirements of the proposed system.
Let us consider the task of setting up an Information System for a nursery and seeing how Information
Technology can help it run more efficiently.
The study might identify the following general requirements for the system:
To be simple and easy to use.
To store all relevant details of the members.
To produce membership lists, membership cards and mailing labels.
To produce posters, flyers and similar material advertising the nursery.

System Design
The areas that need to be considered in the design process are listed below:
1. Outputs 2. Inputs 3. File Design 4. Hardware 5. Software

System Design : OUTPUTS

One output for a system for a nursery might be:
Details of the children looked after within the nursery.
Name Address Telephone No.
Smith, Tony 12 Fields Road 0543 3445545
Jackson, Jake 9 Main Road 0563 9545752
System Design : INPUTS
To work out the inputs required for a system several questions need to be addressed:
What data needs to be entered into the computer system?
How much data needs to be input, and how often?
Where does the data come from?
How will the data be entered into the system?

System Design : FILE DESIGN

How many files are needed and what will their structure be?

System Design : HARDWARE

This section covers the types of computers and printers thought suitable for the system being analyzed.
If the system needs to be on a network, details would be specified here.

System Design : SOFTWARE

A decision will have to be made as to what software to use.
The most common software packages are databases, spreadsheets and word processing packages.

TESTING :
Any new system needs to be thoroughly tested before being introduced.
First of all the system should be tested with normal data to see if it works correctly.
Secondly, the system is tested with data containing known errors to try and make it fail ('crash').
Thirdly, the system is tested with very large amounts of data to see how it can cope.
It is important that processing time and response rates remain acceptable with varying amounts of data.
A test plan should be designed before testing commences.

IMPLEMENTATION :
Implementing or introducing a new system can be done in two ways:
Direct Implementation
Parallel Running

IMPLEMENTATION : DIRECT
 With this method of implementation the users stop using the manual system and start using the computer
system from a given date.
The advantage of this method is that it is less costly in effort and time than any other method of
implementation.
The disadvantage of this method is that if problems occur the users do not have any alternative apart from
returning to a manual system which may prove difficult if it has been discontinued.

IMPLEMENTATION : PARALLEL RUNNING

With parallel running, the new system is introduced alongside the existing system.
With parallel running both systems (manual and computer, or old computer and new computer system) will be
in operation at the same time.
This has the advantage that the results from the new system can be compared with those of the old system.
However, it has the major disadvantage that each job is done twice and therefore it means a lot of extra work
for the users.

DOCUMENTATION :
A number of documents are produced during the development of a new computer application.
Essentially there are two types:
User Guides
Technical Documentation

DOCUMENTATION : USER GUIDES

User guides are written in plain English rather than technical language.
The guide should cover how to run the system, how to enter data, how to modify data and how to save and
print reports.
The guide should include a list of error messages and advice on what to do if something goes wrong.
DOCUMENTATION : TECHNICAL
Technical documentation is used to explain a system to a specialist i.e. an analyst/programmer.
This document will be used if any changes have to be made to the system.
It is a very important document which needs to be fully up-to-date.

Problems in information system development

Though information has become one of the most valuable assets of modern corporations, development of
information systems (IS) faces many problems. Among the most important are low productivity, a large number
of failures, and an inadequate alignment of ISs with business needs. The first problem, low productivity, has
been recognized in the term “software crisis”, as indicated by the development backlog and maintenance
problems (cf. Brooks 1975, Boehm and Papaccio 1988, Jeffrey 1987). Simply, demands for building new or
improved ISs have increased faster than our ability to develop them. Some reasons are: the increasing cost of
software development (especially when compared to the decreasing cost of hardware), the limited supply of
personnel and funding, and only moderate productivity improvements.

Second, IS development (ISD) efforts have resulted in a large number of outright failures (cf. Lyytinen and
Hirschheim 1987, Charette 1989). These failures are sometimes due to economical mismatches, such as budget
and schedule overruns, but surprisingly often due to poor product quality and insufficient user satisfaction. For
example, one survey (Gladden 1982) estimates that 75% of IS developments undertaken are never completed,
or the resulting system is never used. According to the Standish Group (1995) only 16% of all projects are
delivered on time and within their budget. This study, conducted as a survey among 365 information technology
managers, also reveals that 31% of ISD projects were canceled prior to completion and the majority, 53%, are
completed but over budget and offer less functionality than originally specified. Unfortunately this area has not
been studied in enough detail to find general reasons for failures. As a result, we must mostly rely on cases and
reports on ISD failures (e.g. Oz 1994).

Third, from the business point of view, there has been growing criticism of the poor alignment of ISs and
business needs (cf. Earl 1989). While an increasing part of organizations’ resources are spent on recording,
searching, refining and analyzing information, the link between ISs and organizational performance and
strategies has been shown to be dubious (Smith and McKeen 1993). For example, most managers and users are
still facing situations where they cannot get information they need to run their units (Davenport et al. 1992,
Rockart and Hofman 1992). Hence, ISD is continually challenged by the dynamic nature of business together
with the ways that business activities are organized and supported by ISs.

All the above problems are further aggravated by the increasing complexity and size of software products. Each
generation has brought new application areas as well as extended functionality leading to larger systems, which
are harder to design, construct and maintain. Moreover, because of a large number of new technical options and
innovations available - like client/server architectures, object-oriented approaches, and electronic commerce -
novel technical aspects are transforming the practice of ISD. All in all, it seems to be commonly recognized that
ISD is not satisfying organizations’ needs, whether they are technical, economical, or behavioral. Consequently,
companies world-wide are facing challenges in developing new strategies for ISD as well as in finding
supporting tools and ways of working (Rockart and Hofman 1992, Benjamin and Blunt 1992).

Systems Analysis and Design : A traditional term used to describe the process of designing, building, and maintaining
information systems performed by analysts and programmers.

Software Engineering : A newer term given to acknowledge the movement of systems building from art to discipline by
professionals using common methods, techniques, and tools for constructing information systems.

Problem Decomposition : Systems building is a process of decomposing large complex problems to discover and design
solutions to support the organization.
Options for Acquiring System Capabilities

The Systems Development Life Cycle

The System Development Life Cycle (SDLC) is a structured method complete with techniques developed to manage the
life cycle of an information system
System Identification
A process used to identify opportunities
for developing systems projects to solve
problems. This process varies greatly from
organization to organization
Selection
The process of applying evaluation criteria
to possible projects to select those that are
critical to enabling the organization’s
mission, goals, and objectives
Systems Planning
Developing formal plans for creating the information systems project selected. Some organizations call their periodic
process of identification, selection, and planning “Information Systems Planning (ISP)”

Criteria for evaluating and selecting a systems project

System Analysis

Collecting System Requirements (Traditional)

A combination of methods are used:
• Interviews – discussions with
stakeholders (i.e. users)
• Questionnaires – surveys to
assess use and attitudes
• Observations – watch process
and systems use
• Document Analysis –
reviewing current documents

Collecting System Requirements (Alternative)

A combination of traditional methods are
used:
• Critical Success Factors (CSFs)
– a process of interviewing,
recoding, analyzing and merging factors defined as critical by personnel at all levels of an organization
• Joint Application Design (JAD) - a method that brings together users and analysts in a room to define
requirements. This method greatly reduces design time

Systems Analysis - Critical Success Factors

Systems Analysis - Joint Application Design

• JAD is a special type of a group meeting in which all (most) users meet with an analyst at the same time
• Users jointly define and agree upon system requirements or design dramatically reducing the design time