SYSTEM DEVELOPMENT LIFE CYCLE

This is a sequence of steps to be taken to create and maintain an information system.

There might be 7 steps or up to 58 steps. It depends on what level of understanding of
systems analysis we have and how big or complex the information system is likely to be.

System Analyst – the person responsible for the investigation and development of the
system along with the relevant documentations

Problem
Identification

Maintenance Investigation
and Review

Feasibility
Evaluation Study

Implementation
and Testing Analysis

Design

1. Investigation
-In this phase, the existing system is studied closely to discover the true nature of the
problem which led to the request for an investigation.
-At the same time, gaining a better understanding of the way the system operates.
-Normally the system is first investigated to find whether there are sufficient problems to
warrant a full-scale investigation.

Fact finding Methods/Techniques

Observing the existing system first hand

This involves watching the personnel using the existing system to find out exactly how it
works. There are a number of advantages and disadvantages of using this method to
gather information about the existing system:
Advantages - the analyst obtains reliable data
- it is possible to see exactly what is being done
- this is an inexpensive method compared to other techniques

Disadvantages - people are generally uncomfortable being watched and may work in a
different way
- what they are watching may not be representative of a typical day’s work

1
- if workers perform tasks that violate standard procedures, they may not do this when
being watched!!
Questionnaires
This involves sending out questionnaires to the work force and/or to customers to find
out their views of the existing system and to find out how some of the key tasks are
carried out. As with observation, there are a number of advantages and disadvantages
in using this technique:

Advantages - questions can be answered quickly

- an inexpensive way of gathering data from a large number of people
- allows individuals to remain anonymous
- it is quick to analyse data

Disadvantages - number of people returning questionnaires is often quite low

- questions asked tend to be rather inflexible
- no immediate way to clarify a vague/incomplete answer to a question
- it is difficult to prepare a good questionnaire

Interview
This involves a one to one question and answer session between the analyst and
1employee/customer. A good method if the analyst wants to probe deeply into one
specific aspect of the existing system. As with the previous method, there are a
number of advantages and disadvantages:
Advantages - opportunity to motivate the interviewee to give open and free answers to
the analyst’s questions
- allows the analyst to probe for more feedback from the interviewee (easier to extend a
topic than it is when using questionnaires)
- can ask modified questions or questions specific to the interviewee based on previous
responses

Disadvantages - can be a very time consuming exercise

- can be expensive to carry out
- unable to remain anonymous

Document Study/Looking at existing paperwork

This allows the analyst to see how paper files are kept, look at operating instructions and
training manuals, check accounts, etc. This will give the analyst some idea of the scale
of the problem, memory size requirements, type of input/output devices needed, and so
on. They will often gain information not obtained by any of the other methods described
above. However, it can be a very time consuming exercise.

2 Feasibility Study
In the feasibility study the system analyst will hopefully be able to identify the chance of
creating a system successfully. This involves writing a report (feasibility report) to
convince management of the merits of adopting the proposed new system. The study
will provide a rough estimate of ;

1. how the project will be managed

2. how long it will take and
3. what resources will be required.
4. costs and benefits of proposed system

2
If the feasibility study is accepted then the systems analyst moves to the next stage
which is a full analysis of the system.
3. Analysis
The analysis involves the following stages:
• Identify the user requirements
• Fact finding – this is usually
done in four ways (see page 2) • Interpret the user requirements

• Understanding the current • Agree the objectives with the

system user

• Produce data flow diagrams • Collect data from the current

system

4. Design
Once the analysis has taken place and the systems analyst has some idea of the scale
of the problem and what needs to be done, the next stage is to design the key parts of
the recommended system. The following is a list of tasks that are usually done (this is by
no means an exhaustive list):

• design the data capture • select the most appropriate

forms/input forms data verification method(s)

• design the screen layouts • file structures/tables need to be

designed/agreed
• design output forms and
reports • select/design the hardware
requirements for the new system
• produce systems flowcharts
and/or pseudo code • select/design the software
requirements
• select/design any validation
rules that need to be used • produce any algorithms or
program flowcharts
5. Implementation
Once the “final” system has been designed it is then necessary to put together the
hardware and software and introduce the new system. There are many stages in this
complicated process:
• produce the documentation; there are two basic types here to consider:

User documentation
this usually consists of:
- how to load/run the software - print layouts (output)
- how to save files - hardware requirements
- how to do a search - software requirements
- how to sort data - sample runs (with results and actual
- how to do print outs test data used)
- how to add, delete or amend records - error handling/meaning of errors
-the purpose of the - troubleshooting guide/help lines/FAQs
system/program/software package - how to log in/log out
- screen layouts (input)

3
\

Technical documentation - minimum memory requirements

this usually consists of: - known “bugs” in the system
- program listing/coding - list of variables used (and their
- programming language(s) used meaning/description)
- flowchart/algorithm - file structures
-purposeof the system/program/software - sample runs (with results and actual
- input formats test data used)
- hardware requirements - output formats
- software requirements - validation rules

• install the hardware and, if necessary, the new software

• fully test the new system once installed

It is necessary to develop a proper testing strategy to ensure all possible scenarios are
covered and that all error trapping techniques are fully tested. Data Tests often falls into
3 types:

1. Normal data test

- this is data which is acceptable/valid and has expected outcomes (for example, if a
date is being input the day should be in the range 1 to 31)

2. Abnormal/erroneous data test

- this is data outside the limits of acceptability/validity and should cause an error
message to be generated (for example, if a date is being input the day can’t be -1 or 50
etc.)

3. Extreme/boundary data test

- this is data at the limits of acceptability/validity (for example, if a date is being input, the
two values at the extreme limits of valid days would be 1 and 31)
• train the staff to use the new computer system
• transfer the paper files across to the new system; this may involve the following:

Implementation Strategies/changeover to the new system

change over is usually done in one of four ways; the following notes summarise these
methods and gives advantages and disadvantages of all the techniques:

Direct changeover /The big bang

with this technique, the old system is stopped and the new system is used straight away;
- this method can be disastrous if the new system fails at any point
- however, the benefits are immediate and less time is wasted
- costs are reduced (only one system in use so save on staff costs)
- less likelihood of a malfunction since the new system will have been fully tested

Parallel running
with this technique, the old and new systems are run together for a time
- if the new system goes down for any reason, you still have the old system to fall back
on so a failure wouldn’t be disastrous
- it is possible to gradually train staff/time to get used to the new system
- more expensive than direct since need extra staff to run both systems
- more time consuming since both systems need to be run and evaluated

4
 Pilot running
With this technique, the new system is introduced into one part of the company (e.g. into
one warehouse of a supermarket) and its performance assessed
- if the new system fails only one part is affected; the rest is still functional
- it is possible to fully train staff in one area only which is much quicker and less costly
than parallel
- the costs are also less than parallel since only one system is being used in the pilot
warehouse

Phased implementation
in this technique only part of the new system is introduced and only when it proves to
work satisfactorily is the next part introduced, and so on, until the old system is fully
replaced
- if the latest part fails, only need to go back in the system to the point of failure; hence a
failure isn’t disastrous
- more expansive than direct since it is necessary to evaluate each phase before moving
to the next stage
- can ensure the system works properly before expanding

6. Evaluation and 7.System Maintenance and Review

Once a system is up and running it is necessary to do some evaluation and carry out
maintenance if necessary. This is summarised below:

• compare final solution with the original requirement

• identify any limitations in the system
• identify any necessary improvements that need to be made
Evaluation
• evaluate the user’s responses to using the new system
• compare test results from new system with results from the old system
• compare performance of new system with performance of old system
• update hardware as new items come on the market or the company changes in
Maintenance any way which requires new devices to be added/updated
• update software if necessary if company structure changes or legislation is
introduced which affects how the company operates

The system needs to be reviewed periodically for the following reasons.

i) To deal with unforeseen problems arising in operation, e.g. programs may

need to be modified to deal with unforeseen circumstances.
ii) To confirm that the planning objectives are being met and to take action if
they are not.
iii) To ensure that the system is able to cope with the changing requirements.