Systems Development Life Cycle

SDLC: A simplified introduction

Stages of the Cycle

1. Problem definition

2. Feasibility study

3. Analysis

4. Design

5. Implementation

6. Maintenance

Why do we need the SDLC?

The software crisis of the late ‘60s and early ‘70s

Systems were delivered years late

They were over budget

Unreliable

Difficult to maintain

Did not do what was required

What does the SDLC do?

Systems Development Life Cycle was an attempt to

establish a structured approach to systems development.

For management, each stage of the life cycle was a

milestone with an associated date and set of deliverables.

Deliverables

Each stage has an associated set of deliverables

Sets of documents produced at each stage in the life cycle

1. Problem Definition

The problem definition forms the basis of the problems and requirements list (see later)

It records all problems and requirements mentioned by clients in interviews, or which are subsequently discovered during analysis of the system.

Problem Definition Report – the purpose

To provide a written statement of the user's current problems and requirements; to get agreement with the user.

To ensure that the right problem is being tackled

To force the user to become involved

To define the current state of the system and the required end state

Problem Definition Report – the sections

Problem

Objectives

Scope

Preliminary ideas

Recommended action

2. Feasibility Study Feasibility study - is there a practical solution to the problem outlined in

the initial problem definition.

In particular, the feasibility study examines the technical, financial and organisational feasibility of the project:

Can it be done?

Can we afford it?

Will the proposed new system fit in with existing procedures?

Feasibility study report

Presented by the system developer to the user

Decision is made whether or not to proceed.

3. Analysis

Deliverable from the analysis stage is the ‘Specification of requirements’

Logical model of the required system

States WHAT the system is to do

Says nothing about HOW to implement it

Includes

◦ Data flow diagrams

◦ Data dictionary

◦ Process definitions

◦ E/R model

◦ Entity life histories or state diagrams

4. Design

This has two stages:

Provides several different solutions to the problem

Selects one solution and specifies it in detail

Design – Alternative solutions

A very cheap solution which does the job and no more.

A medium price solution which does the job well and is

convenient for the user;

A high cost, all-singing, all dancing solution

How solutions may differ

System boundaries;

Automation boundaries; could remain manual.

Hardware

Software

Design strategies

User interface

Costs

Design – Selecting a solution

Specification may include:

Program design (e.g. structure charts) and specification

Specification of the user man/machine interface

Specification of the layout of reports and other system outputs

File and record specifications

Hardware specifications, including costs

Implementation schedule

5. Implementation

Program listings, test plans and supporting documentation

Manual of operating procedures

Manual of clerical procedures

User manual

Hardware on which the system will run

The system must be installed at the clients' site on their equipment

Changeover from the old to the new system supervised

Often a hand-holding period

6. Maintenance

Starts as soon as the system is handed over

Term maintenance often euphemism for finding and

correcting errors

True maintenance is modifying the system to meet

evolving client requirements

System developer must start again at the beginning of the

cycle

An example, simplified system

The System Requirements

Background

Errors in requirements may account for approximately

50 per cent of the total cost of debugging a software

system.

Many of the traditional system development methods

merely pay lip service to identifying, describing and

validating the client’s requirements for the system.

Today requirements engineering is recognised as a crucial

stage in the development of software.

Requirements – what are they?

No consensus of opinion as to what is meant by

requirements

System requirements - the client’s needs and wishes.

Software requirements - constraints put on the system development, such as hardware, software and design methods.

Requirements Engineering

Covers three phases:

elicitation (identifying requirements)

specification (describing them in an appropriate language

or notation)

validation (checking with the client that the description

accurately records his or her needs and wishes).

Different types of requirements

Functional requirements: what the system has to

do what its inputs and outputs are and how these are

linked.

Non-functional requirements: the attributes of

the system as it performs its job; can be divided into

1. non-functional requirements of the system and

2. non-functional requirements arising from external sources.

Non-functional System Requirements

Usability

Performance

Reliability

Security

Elicitation

This covers several different activities:

Observation of the users at work

Study of relevant documents

User questionnaires

Talking to the people involved in the system

The Requirements Specification

A cornerstone of a system development project

Encapsulates the shared understanding and intentions of all the stakeholders

May be used as a vehicle for communication between developers, users and other stakeholders

The Requirements Specification

May form the basis of a legal contract between developer and client

Guides the programmers in their implementation of the

system

Desirable qualities of a requirements specification can be found in the IEEE Recommended Practice for Software Requirements Specifications from the IEEE Standard 831–1993.

Requirements Validation

Technically feasible to confirm that the requirements

specification document is of the desired quality

Not easy to ascertain whether the requirements

expressed in the specification are really what the client

wants and needs

The client may not know what he or she wants

Requirements Validation

Prototyping allows the client and users to get some

feeling for how their ideas would work once

implemented in a computer system.

Talk through the requirement specification with the client

and users.

Summary

Stage

Content Deliverable

1. Problem Definition What is the problem? Problem Definition Report - statement of

problems, scope and objectives

objectives of new system

2. Feasibility Study Is there a feasible

solution – quick look

ahead to see if you can

do something about the

problem

Feasibility Study Report - rough cost benefit

analysis

- system scope and objectives cost benefit

analysis

3. Analysis What must be done to

solve the problem

Specification of Requirements –logical

model of required system

4. Design How should the problem

be solved

Technical Design Specification –includes

program specifications, hardware

specifications, cost estimates and an

implementation schedule

5. Implementation Do it Working system, includes program listings and

documentation, test plan, hardware, operating

procedures, clerical procedures

6. Maintenance Modify system as

necessary

Working system - Operational system, modified

and documented as required

Tasks

Using one or two A4 sides, list each stage of the SDLC,

using illustrations and diagrams where appropriate

Present your work in a professional manner, using

headers and footers and other advanced formatting

options