The systems life cycle

Large systems development projects can take several years to develop and can be extremely costly. It is important that projects
are delivered on time, within budget and meet the required specification. To this end most commercial organisations follow
the systems life cycle approach to developing systems. The systems life cycle consists of a series of well-defined stages, which
when followed, prevent large projects from developing in a haphazard fashion.

The systems life cycle

Problem definition

Feasibility Where does quality fit if ????

Study

Analysis

Design

Programming/development

Installation/implementation

Maintenance

The stages in systems development

1
The waterfall model

The waterfall model is a variation on the systems life cycle model. As the project develops analyst/programmers often find flaws
in the design and so earlier stages have to be redeveloped. The waterflow model reflects this by having arrows that go up and
down the model

Analysis Feasibility Study

Requirements Analysis

Design Design

Implementation Coding and testing

Conversion

Review and Post-

Maintenance Implementation review

2
 The stages in systems development

Problem definition

The problem domain is defined by investigations being made to identify the problems with current system; for example, a manual
system may be in operation in which large volumes of data are being repetitively processed. The investigation begins by
thoroughly understanding the present system. A fact-finding approach is employed. In order to understand the system a number
of techniques can be employed, such as flowcharts , structure charts. When the new requirements are analysed and a new
system is proposed.

The User Request (problem domain) is the first step in the systems development cycle, it will involve Formal/informal
discussions between users/management and the analyst. A Formal document called the Terms of Reference is produced and
consists of :

The Terms of Reference:

1) Objectives what the new system must achieve, these include quantifiable and unquantifable (tangible) benefits e.g cost
reductions, better service to customers, better management information, ability to handle increased volumes of business.
2) Constraints: restrictions on cost, availability of technical expertise, equipment to be used, areas of business, which are to be
left unchanged and so on.
3) Timescales: when each stage should be completed
4) Reports or outputs required
5) Problems that have been identified with current system
6) Suggested solutions considered by management, these may include possible technical solutions to the problem, but equally it
may also include manual alternatives available.

Why is it important that analyst documents the Terms of Reference before analysis begins ?

The problem definition is more properly defined in the feasibility study.

The feasibility study

The aim of the feasibility study is to understand the problem and to determine whether it’s worth, or indeed possible, to
computerise the system.
The scope and objectives of the proposed system must be established and documented.

The feasibility study can be broken down into several factors

Technical Economical Social Legal Operational Schedule

Feasibility Feasibility Feasibility Feasibility Feasibility Feasibility

 Technical Feasibility

Means investigating whether the technology exists to design the proposed system. Nowadays, as there are so many advances in
technology it also involves looking at which software/hardware which will best meet the proposed objectives. It looks at technical
facilities, such as is there a faculty to produce output in time, for example can 3000 envelopes be produced in one week.

 Economic Feasibility

Is concerned with the cost effectiveness of the proposed system. If the benefits do not outweigh the cost then it’s not worth
developing the system. Other considerations involve considering the H/W , S/W costs – can they be met within budget. Technical
personnel can be expensive, again their costs need to be taken into account. Also consider: -
i) development costs

3
 ii) running costs

The benefits may be :-

i) Direct economic benefits
ii) Benefits that are hard to quantify e.g. improved management information or improved customer
service – these are know as Tangible benefits and although are hard to quantify they must be included in the feasibility report.

 Social Feasibility
This is concerned with the effect on employees and customers on the introduction of a new system. Will it result in
redundancies? Will some jobs be deskilled ? Is there a need for re-training ? Will the workforce be able to cope with the new
changes ? Will the workforce have to relocate ? It is imperative that users are being involved and their cooperation is secured
before changes are made. Equally the effect on customer services have to be identified.

 Legal Feasibility
Determines if there are any legal implications/requirements associated with the introduction of the new system e.g violation of the
Data Protection Act.

 Operational Feasibility
Is concerned with human, organisational and political aspects. It deals with issues such as,
Whether the current work procedures are adequate enough to support the new system, or what job changes will the new system
bring, what organisational changes will the new system bring about.

 Schedule Feasibility
Looks at the time it will take to develop the proposed system and whether it will be done with in the proposed time frame.
On completion of this phase the systems analyst produces a FEASIBILITY REPORT, which details all the above considerations.
The report should state whether it’s feasible to go ahead with the project or not. This is then agreed and ‘signed off ‘ by senior
managers and the detailed requirements analysis phase begins

hase a ‘deliverable’ is produced.

DELIVERABLES

Problem definition - Terms of Reference document

- Feasibility report
- Project plan
- Cost/Benefit Analysis

Analysis Phase - Detailed Requirements Report

- Revised project plan
- Cost Benefit Analysis

Design Phase - File Definitions, Program Specifications

-Specifications of operational procedures
-H/W specifications

Construction/ - Documented programs

- Test data & Results
- User Manuals
- Working system

Maintenance - correction of bugs

-Modifications of new requirements