Transcript Systems Development Life Cycle - Ivailo Chakarov

Systems Development Life Cycle
SDLC: A simplified introduction
Stages of the Cycle
1.
2.
3.
4.
5.
6.
Problem definition
Feasibility study
Analysis
Design
Implementation
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