Systems Development Life Cycle

offbeatnothingSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

65 views

Systems Development Life
Cycle

A simplified introduction


You will need to take notes throughout the
presentation



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