CHAPTER 1 : SYSTEM LIFE CYCLE
Introduction
A system is a collection of related components that serve a common purpose. In
the phrase “System Life Cycle”, a system is either a program or a collection of
programs. Therefore, a system life cycle describes how programs are developed
from an idea, to completed programs and then, to revised or discontinued
programs.
In this chapter, we shall study the eight phases in the life cycle of a system. A
logical approach will be employed to describe the stages, starting from when an
idea is conceived, to the stage when the completed system is reviewed.
1.1 What is a System?
We have been using the word “system” quite freely, but before we discuss all the
stages of a system life cycle and the part that a programmer plays, we need to be
clear what a system is. Many definitions exist, and we can also find satisfactory
definitions in the publications of various standard institutions.
1.2 Stages of a System Life Cycle
The environment in which any business system or enterprise function does not
remain static for very long. Because of this, the systems has to change. When
there are changes, the system will eventually need to be replaced, or significantly
altered to become a new system or a new version.
It is appropriate, therefore, to regard the development of a system as a cyclical
process, rather than one which has a definite end point. The iterative nature of
system development may make it necessary to repeat any stage until it is
acceptable. The process of replacing the old system with the new, happens in a
series of stages and the whole process is called the “system life cycle”. The
system life cycle can be divided into eight phases, as shown in Figure 1-1.
Although each phase is presented discretely, it is never accomplished as a
separate step.
1.3 Elements of the System Life Cycle
In each stage, different documents are required as input, different activities take
place with different people involved and different documents are generated.
1
SYSTEM LIFE CYCLE
1.3.1 Initial Study
A system project will not start for no apparent reasons. It must have been
initiated by someone (we will generally call him the user). Based on the user’s
requests, the System Analyst (SA) will check the background of the problems to
see if it is possible to solve them. After the study, the SA will produce a
feasibility report. This report will describe the scope of the new system and
contains estimates of the time, costs and benefits that would result from the
system.
Detailed work will only commence if the project is approved.
Initial Study
8 2
System Analysis
Review and Design
7 3
Live Running and
Maintenance Program Design
6 4
Implementation Development
Testing
5
Figure 1-1 : The stages of a system life cycle
1.3.2 System Analysis and Design
Based on the feasibility report, the SA will carry out a requirement analysis. The
SA will use techniques like interviewing, observation, questionnaires and/or
reading of manuals to find out from the user the new system’s requirements.
What the SA has gathered will be documented using tools like Data Flow
Diagrams and/or Run Charts. There will normally be a presentation by the SA to
the user to verify the findings.
2
SYSTEM LIFE CYCLE
Once the findings have been confirmed to be accurate, the SA will design a
system that will meet the user’s requirements. The SA will produce the system
specification, which includes:
The information flow
The file storage organisation
The program’s requirements
The outline of the user’s operations manual
An acceptance of the system specification by the user will mark the end of this
stage and the authorisation to commence with the next.
1.3.3 Program Design
Based on the system specification, the SA or the Senior Programmer will then
produce the program specification for each of the programs (if there is more than
one program). The SA or the Senior Programmer will have to ensure that all
program specifications adhere to the system specification and standards. They
will also have to ensure that a test schedule is prepared for each program.
Typically, the program specification consists of:
Program/module description and objectives
Input file(s) specification
Output file(s) specification
Processing requirement
The programmer will take the program specification and use a method agreed
upon to design the program before coding it. Common methods are Jackson
Structured Programming, Pseudocode, Flowchart, Structured Chart and Nassi
Shneiderman diagrams.
1.3.4 Development
When the design is completed, the development stage begins, which is to convert
the design into workable solutions (programs).
The development stage can be divided into two main activities:
File creation
Application program creation
3
SYSTEM LIFE CYCLE
Detailed documentation on the files and program used in the system are also
done at this stage. These include:
Input and output specifications
Data dictionary
Operating instruction
1.3.5 Testing
Throughout the development, and as a separate stage after development is
completed, testing and debugging will be necessary. Tests will be carried out
according to the schedule prepared by the SA or Senior Programmer. During the
process of testing, changes can be made in any of the previous stages (refer to
Figure 1-2) to rectify any errors or problems discovered.
At this stage, the documents generated are:
Test log
Test plan
Test data
Test results (both expected and actual)
System Analysis
and Design
Program Design
Development
Testing
Implementation
Figure 1-2 : Testing and debugging
4
SYSTEM LIFE CYCLE
1.3.6 Implementation
After adequate testing, implementation of the system takes place. The stage
includes the installation of the hardware before the system is handed over to the
user. It covers:
User training
Data conversion
Control procedures for the changeover
The System Analyst will be responsible for the implementation plan which
covers in detail the time frame for each of the activities mentioned above, and the
duties and responsibilities of each of the personnel involved.
The 4 implementation methods:
Direct changeover
Parallel changeover
Pilot changeover
Phased/Gradual changeover
1.3.7 Live Running and Maintenance
This is the stage where the system becomes functional in a live environment, and
is expected to be able to cope with any of the situations it is built to handle.
Live usage gives rise to maintenance requests. Errors may be detected which
might have slipped through the testing stage. There may be changes in the user
requirements or discovery of requirements which have not been included in the
first place due to a misunderstanding between the user and the System Analyst.
Sometimes it may be due to external influences like changes in government
policies which require modifications to the program (e.g. GST).
As long as there is some alteration, all documentation related to the change must
be updated.
1.3.8 Review
Once the “dust” has settled, i.e. the system has been used for a sufficient length
of time and emergencies have been coped with, an evaluation review should be
carried out. The review should be carried out by a person who has not been
involved in the design and development stages so as to ensure that the review
will be carried out objectively. The content of the review will include:
Objectives met
Cost
Performance
5
SYSTEM LIFE CYCLE
Standards
Recommendations
After the review, maintenance may be carried out to enhance the system or it
may be decided that part or the whole of the system needs to be re-designed, and
hence re-developed. If redesigning needs to be done, the initial study will come
in again, thus calling into play the entire System Life Cycle once more.
