Systems Life Cycle

New ICT systems are being built all the time in almost every type of organisation, for example:

• Banks - customer records, ATM machines, approving/rejecting mortgage applications.
• Hospitals - pharmacies keeping track of drugs and creating printed prescriptions, appointment for outpatients.
• Government - online tax payment, online census information.
• Supermarkets - stock control, payroll.

A new IT system may be commissioned for a number of reasons:

• Current one is out of date and ineffective.
• Technology has moved on, new things are possible that couldn't be done using the previous system.
• A competitor has developed a new system or process; organisations needs something similar to offer the same quality of service to customers.
• Organisation has grown; current system can't cope with increased demands.
• New part of the company needs IT support.
• Company wants to improve the quality of a repetitive task.

Managing any change that involves IT systems is risky! A survey of over 14,000 organisations showed that, where new IT systems were being developed:

• 80-90% of systems fail to meet performance goals.
• 80% of systems are late and over budget.
• 40% of systems fail or are abandoned.
• Just 10-20% of businesses meet all their success criteria.

Only a small minority of the IT projects in the survey were successful.

As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximise the chances of a successful project.

This method/model is called the SYSTEMS LIFE CYCLE.

The SYSTEM LIFE CYCLE is a process of stages which occur during the development of a new ICT system. If organisations follow the stages of the SLC, they should be able to avoid many of the problems mentioned on the front of this card.

The SLC consists of the following stages (usually in this order, though it is not ALWAYS linear - after the completion of one stage, it may be necessary to backtrack):

• Definition
• Investigation and Analysis
• Design
• Implementation
• Testing
• Installation
• Documentation
• Evaluation
• Maintenance

The very first part of the SLC is to DEFINE the problem.

The system analyst must determine why a new system is required. If there isnt a problem to start with ,why would an organisation incur huge costs to develop a new one?

In the definition stage, the role of the analyst is to scope out the problem.

The analyst has a number of methods available to do this:

• Interviews with management; getting their viewpoint.
• Interviews with staff; understanding limitations of current system.

(along with other methods, which will be discussed later)

Once the system analyst is convinced there is a problem that could be solved with a new IT system, they have to determine whether it is feasible to go ahead and develop the system, answering questions such as:

• Cost - How much would the new system cost to develop?
• Budget - Would there be enough money available in the budget to develop the system?
• Time - How long would it take to make the system from start to finish?
• Skills - Does the company have the skills in-house, or would it need to go to a specialist software development firm?
• Hardware to develop - Does the company have the necessary hardware to develop the system?
• Hardware to run - Would new hardware be needed to run the system and if so how much would that cost?
• Software - Does the company own the software needed to develop the system?
• Training - What would the training implications be once the system is developed?
• Technical Feasibility  - Is it technically possible to create the system?

The system analysis will consider all the answers from the feasibility study, and come up with a number of alternative solutions - these will be shown to the management, and they will consider going ahead with the new projects.

Some possible solutions that might be suggested to management could be:

• Company does not change anything (no disruption, no cost, but process becomes increasingly less efficient & outdated, no improvement)
• Company makes alterations to half the system (best parts of the systems are retained, whilst least efficent aspects are redesigned, moderate cost (inc. training), 30% improvement)
• Complete overhaul (more profitable business, high cost for new equipment/software/training, 70% improvement)

Deciding on the best alternative is often not simple - management have to take many factors into accounts (relationship between cost, performance, and benefit). At this point, you know what the problem is, and are considering options.

Investigation of the System

By this point, management would have listened to the alternative solutions and have decided to either commission a brand new IT system or have changes to their current system.

During the earlier 'definition' phase, the analysis looked at the current system and the potential benefits of a new one.

During this 'investigation and analysis' phase, they will carry out very detailed investigations in order to fully understand the current system and the proposed new system.

The Current System

• How staff/customers interact with the current system.
• How other systems interact with the current system.
• What is good about the current system.
• What causes problems with the current system.
• Which parts of the system are critical to the business.

The Proposed New System

• What the new system is expected to be able to do.
• How the new system is expected to do this.
• What people want from the new system.
• Which working methods from the old system should be incorporated into the new one.

In order to find the answers to the points made on the previous card, the system analyst will do some or all of the following:

•  Face-to-face Interviews - interview selected staff using the current system to get a detailed overview of how things work; they will investigate the main problems and find out if users have any suggestions on how to improve the way things work.
• Observation - observe users actually using the system; follow a complete process and note down all interactions.
• Questionnaires - obtain the views of a large number of staff/users; easier to analyse than interviews, but they don't give as much detail.
• Examination of Business Documents - detailing how the system works and the processes which users should follow, which will be examined in detail.
• Paper Trail - following information from the point it enters the system and observing what outputs are created at each point in the system.

All the information obtained through the aforementioned methods is carefully examined and analysed to determine the requirements for the new ICT system.

The findings are translated into a set of specific diagrams which represent how the system will work and the processes required. The main diagrams are:

• System Diagrams - the relationships between the various systems in the company (or outside it); how they interact, what depends on what and so on.
• Data Flow Diagrams - how the information flows through the system; how does it branch and re-join, what outputs are created, and so on.
• Process Diagrams - how people interact with the system; who, when and why?

Once the diagrams have been completed, a full written analysis of the current system (processes & problems it causes) and a detailed user requirements for the new system are created.

Does not define the hardware or software design, but seeks to capture the essence of what needs to be done. Headings include:

• An Introduction - a board description of the project and its aspirations.
• Context - project background.
• Specific Details Required - specific things that need to be included (all of which are measurable)

The Requirements Specification is the 'contract' between project managers and the client.

It will be used at the testing stage to confirm that the system performs as the client expects.

A key point to the SLC process is that it is the people who are actually going to use the system who get a say in how it is going to work (the user). Many projects are carried out without any regard to what the user actually wants, and that is why so many projects fail.

The User Requirement document's purpose is to try to:

• Eliminate misunderstandings.
• Reduce errors.
• Gain user agreement.

The system analyst tries to understand what the user needs from the system, by setting it out in a non-technical user requirement document, which the users are invited to comment and give feedback on. This process continues until the user agrees that the system will do the job (the sign-off).

Many projects fail because they target the wrong user, or because the user requirement changes within the lifetime of the project (mission creep).

This is the stage where we define how the project is going to be carried out. It is about planning the project in detail so that the system will meet user requirements. The following are tasks that take place during this phase:

• Project Planning - handling people (how many, where and when are they needed), resources needed to carry out jobs. Tools such as Gantt Charts and Critical Path Analysis.
• System Requirements Specification - data capture methods, inputs, outputs, processing, file structure, user interface, how information is accessed and indexed, operating system, hardware to be used.
• Data Dictionary - defines the tables, fields, records and relationships; constants, variables and data structures; validation required in the system; query structures.
• Testing Documentation - a test plan is written to test key parts of the system.
• Prototyping - a representation of the project without the nitty-gritty details - it captures the essential details to confirm that the design will be likely to work.

The software developers can begin to write the code and develop the new system. The system can either be bespoke with every line of code being written by specialists, or can be developed and adapted from an off-the-shelf application, which is then customised.

The developers will then follow the system requirement specification exactly. They should not deviate from the specification in any way without consulting the analyst.

During this stage some of the following are developed:

• the tables and data structures
• validation routines
• data capture forms
• data input forms
• automated processing routines
• queries
• user interface
• printing outputs