Subject Navigation

• ictWeb Home
• A2 ICT Home
• Audit
• Change management
• Codes of conduct
• Data
• Development and Life cycle of a system
• Disaster recovery
• Flow of Information
• Information
• Information Systems and Organisations
• Legal implications
• Legislation
• Management Information Systems
• Organisational Structure
• Personnel
• The Professional
• Project management
• Success or Failure of a Management Information System
• Systems Strategy
• Training
• User Support

A2 level Information Communication Technology - Unit 4

Development and Life Cycle of a System

Overview

When a new information system is required the development of that system is called the 'System Life Cycle'. The life of a system is limited by such things as changes in requirements, changes in technology, changes in an organisation or the existing system may be inadequate, such as a manual system necessarily being automated.

Whatever the reason or need for a new system the development should follow a 'life cycle' methodology. The stages of the chosen model are clearly defined, having a start and finish and therefore the stages can be 'signed off' by the user as compete. The completion of significant tasks are known as milestones.

The Waterfall Model

The waterfall model, though not perfect, shows the stages of development, and how each stage 'flows' into the next hence the title waterfall.

The stages are:

Note that each 'stage' iterates until completed. This means that at each stage the previous stage is checked that the two match e.g. that Design matches Requirements Analysis.

The Stages of the waterfall model

1 - Problem Identification

Before a system can be developed it is essential that the problem that the proposed new system will solve is clearly identified.

2 - Feasibility Study

This aims to understand the problem and decide whether or not it is worthwhile proceeding to the next stage.

'TELOS' is a mnemonic for the factors used to decide the system's future.

• Technical feasibility (does the technology exist and is it tested?)
• Economic feasibility (do the benefits outweigh the cost?)
• Legal feasibility (is the system legal? e.g. Data Protection Act)
• Operational feasibility (will it be usable and what are the effects on changes?)
• Schedule feasibility (what is the time frame?)

3 - Requirements Analysis

Detailed investigation of the current system, find out how it works and then what is required of the new system.

The investigation of the current system will entail the use of:

• Interviews
• Questionnaires
• Observations
• Detailed study of all documents used
• Data flow diagrams

For the proposed system the following are necessary:

• Cost benefit analysis
• Outline of what the system will do (but not how it will do it)
• Outline the implementation
• Outline the changes necessary
• Identify the end users
• Identify the inputs and the form they will take
• Identify the outputs and the form they will take
• Data flow diagrams
• Alternative options for development ( in-house, consultants, ready made software etc)
• Whether to proceed

4 - Design

This phase specifies:

• Inputs
• Outputs
• Storage
• Interfaces (HCI)
• Procedures (for use as basis of user manual)
• Testing plan (using normal, erroneous and extreme data)
• Implementation plan

5 - Development and Testing

Using all the above information the system is built and thoroughly tested using normal, erroneous and extreme data

6 - Implementation

The new system's hardware and software is installed and the old system converted. Implementation may be achieved by

• Parallel
• Direct
• Phased
• Piloted

7 - Post Implementation Review

The whole of the project is reviewed to discover:

• What went right
• What went wrong
• How could the project be improved
• What would you do differently next time
• What can you learn from this project

8 - Maintenance

This is a continuing process for the life of the system. Maintenance can be classed as:

• Perfective (adding extra features / functions)
• Adaptive (changes to the original specification)
• Corrective (correcting errors / bugs found through using the system)

Problems with the waterfall model

• Does not allow changes as the project proceeds
• Users frequently have problems with understanding what a new system can do for them
• Users have problems explaining their needs
• Analysts have problems understanding those needs
• Missing functions / features not picked up

It is possible to cover these shortfalls by using Prototyping which allows a non operational model of the system to be produced which may have some of the functionality of the proposed system and allows the user to see the way in which the new system will operate.

Copyright © ictWeb.org 2004