The Information Systems Life Cycle

In the early days of computers, the people who used the computers were those who were interested in them i.e. computer enthusiasts who saw programming as a creative art. Too often, they didn’t spend enough time talking to the people for whom they were building the systems. From the field of engineering came the idea of a life cycle of specification, design, testing, etc. This is where the term “software engineering” comes from.

Preliminary Survey

This is to decide whether or not a new system is needed.

• A new system may be needed because:
• The existing system may be obsolete due to technological developments
• The organisation's competitors may have a better system
• The current system may no longer be suitable for its purpose (e.g. because the organisation may have changed)
• The current system may be inflexible
• The current system may be expensive to maintain

If the preliminary survey decides that a new system is needed, the objectives of the new system will be established at this stage.

Feasibility Study

A Feasibility Study is carried out when a new system is considered. This considers the scope and the objectives of the proposed system. The five factors to be looked at are TELOS, which means:

Technological Feasibility - does the technology exist>
Economic Feasibility - Is it affordable, do the benefits outweigh the costs?
Legal Feasibility - is there any legal impediment (e.g. the DPA)
Operational Feasibility - how will the new system affect people's working lives?
Schedule Feasibility - can the new system be implemented in the desired time-frame?

Considering all these factors, the Systems Analyst will write a Feasibility Report that will be sent to management. He will recommend whether or not to proceed. Management make the final decision. If they approve the project, the Requirements Analysis will proceed.

Requirements Analysis

The Requirements Analysis is a detailed investigation into the current system and the requirements of the users.

Staff at all levels in the organisation will be interviewed, business documents will be examined, carefully planned questionnaires will be sent out, a "time and motion" study could be carried out to see where efficiency could be improved.

The Systems Analyst then uses this data to chart the flow if information and data around the organisation. This will establish what the new system will do (but not how it will do it). The Requirements Analysis will show exactly what the new system will do in considerable detail. Decisions will be taken about the hardware/software platform to use and what configurations will be needed. There will be an analysis of the costs and benefits of organisational changes.

Again, the Systems Analyst makes a recommendation either to proceed or to abandon the project. The system needs to be approved by management.

System Design

This specifies:

• Hardware and software to be used
• Inputs (data entry screens, default values, etc.)
• Outputs (report layouts, screen designs etc.)
• The User Interface
• Testing Plan
• Conversion Plan
• Documentation
• HCI (the "look and feel" of the system)
• Data validation
• Security features

A prototype could be developed and piloted by part of an organisation. Doing this familiarises users with the look and feel of the new system and it can help iron out misunderstandings between developers and users. Missing functions can be detected. Alternatively, the prototype can be used for training purposes.

Implementation

This involves coding and testing the new system, installation, training and the conversion process.

Methods of Conversion

Direct Changeover (e.g. done over a weekend) is fast and efficient but there is great disruption if the system turns out to be less than perfect.

Parallel Conversion is where the old system continues to be used alongside the new system for a few weeks. This means staff have double the work to do. However, the great advantage is that results from the old system can be tested against results from the new system.

Pilot Conversion is where part of the organisation pilots the new system and evaluates it.

Post Implementation Review

Often shortcomings are only noticed when the system is being used. System Maintenance will then begin and this completes the systems life-cycle.

Maintenance can be:
" Perfective" e.g. improvements, add-ons, new reports and queries
" Adaptive" i.e. the system changes to meet the changing needs of the users
" Corrective" i.e. to solve problems with the system