Stages in the SDLC

Let’s consider
each stage in
turn…
The Traditional Systems Development
Life Cycle
 STAGE
RECOGNITION OF NEED
TASK:
Preliminary Survey
Initial Investigation
Key Question:
What is the Problem or Opportunity?
Result:
Statement of Scope or Objectives?
Performance Criteria
 Techniques for determining system
requirements

Requireme
nts
Gathering
Techniques

Deriving from an Deriving from

Asking the
Existing System the Analysis of
users
the Business Area

Interviewing Data Analysis Business Systems

Questionnaires Document Analysis Planning
Group Decision- Observation Decision Analysis
Making Processes Participation
Joint application Critical Success
development Factors
 STAGE
FEASIBILITY STUDY
TASK:
Evaluation of Existing Functions
Cost Estimates
Key Question:
Is the problem worth solving?
How the problem can be redefined?
Result:
Technical/Behavioral Feasibility
Cost/ Benefit Analysis
Statement of new Scope and Objectives
 Initiation (Why?)
• Is this project worth doing? System
Users

Planned development project

Steering Committee Unplanned

development
project
Survey Project
Feasibility
Feasibility
Report
(scope defined) Problem/opportunity
Constraints details

ANALYSIS

System Owners
The basic questions to be answered in any kind of feasibility study are:

•Is there a computer solution to the given business problem?

•Is the solution justifiable in business terms, both organisationally and

financially? For example:
•Will benefits outweigh costs?
•Will the proposed solution be politically acceptable?
•Can the solution be developed in time?
•Can the level of change associated with the system be absorbed
at this time?
•Are the skills in place and the people available to develop and
manage the system?
•Is the risk of project failure acceptable to the organisation?
 Technical feasibility (will we be able to build the system?)

• Technical feasibility
– Does the organization have resources to develop/purchase and
operate the system?

• Technical feasibility depends on:

– Technical expertise within the organization
– Availability of necessary equipment
– Hardware and software reliability
– Adequate performance that will meet specifications
– Capacity for future needs/projected growth
 Economic feasibility (how much will it cost to build the system
and how much will it benefit us?)

• Economic feasibility
– Do the projected benefits outweigh the estimated costs of
development, installation, and operation?
• Economic feasibility depends on:
– Costs — one time and continuing costs
– Benefits — tangible and intangible benefits
– Timing of various costs and benefits
– Cost of not developing the system
• Operational feasibility
– Is the system a practical and effective approach?

• Operational feasibility depends on:

– Management and user support
– User involvement in planning
– Impact on performance, customers, and company image
– Reasonable schedules
 STAGE
ANALYSIS
TASK:
Detailed evaluation of the system
Key Question:
What must be done to solve the problem?
What are the facts?
Result:
Logical Model of the system
i.e. DFD, Data Dictionary, Decision trees
 Analysis
• “Don’t try to fix it unless you understand it”
• Study the existing system, to thoroughly
understand the problems and opportunities
• Review findings with clients and revise
scope if necessary
• Clearly define WHAT the new system must
do
• Agree on acceptance criteria for the new
system (signed systems specification)
●
should the system spec. be frozen?
• Assess feasibility again
 Analysis - ‘what is happening’

• Define the clients requirements

(What?) System
INITIATION Feasibility Report Users
Problem/opportunity
details
Analyse the problem
and define
System Requirements requirements
Specification Report

System Requirements
Specification Report
DESIGN

System Owners
 Data Dictionary
• Defines all objects (entities,
attributes, relations, views, and so
on)

• Used in tandem with the

normalization process to help
eliminate data anomalies and
redundancy problems
What is a decision tree?
 Shows conditions and actions graphically
 DESIGN
TASK:
General Design Specification
Detailed Design Specification
Testing
Key Question:
How must the problem be solved?
How well do programs\individual test out?
Result:
Design of alternative solution
Hardware\Software Specification
Test Plan, Formal system test
 Design

• Define how the system will be

implemented
System Requirements Various
Specification Report Sources
ANALYSIS Design ideas/opinions

Select a design
Design Options
strategy and specify
System
Vendors Hardware/Software details
Selected Design
deals Option

Technical Design Design in Progress

Report Report
SystemOwners/
Users
IMPLEMENTATION
17
 The testing process

Component System Acceptance

testing testing testing
 Testing phases
Requirements System System Detailed
specification specification design design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and test

Acceptance System Sub-system

Service
test integration test integration test
 Implement - ‘build’
System
• Build and deliver the system Users

User acceptance
Technical testing
DESIGN Design Report

User Documentation
Build, test, install
and deliver the User Training
System
Vendors new system
Hardware/Software
Production System
System and
Technical
Documentation Project Report System Owner

MAINTENANCE 20
 Implementation
• Three main sub-steps:
– Build
– Test
– Convert
 Implementation – system
building
• take all the detailed design
documents from the design phase
and transform them into an actual
system…
• Build the user interface
• Build the database
• Build the network components
• Write the programmes to process
the data
Implementation - Testing

• Verify that the system works and meets all of

the business requirements defined in the
analysis phase.
• Levels of testing:
– Unit or individual component test
– Group of interacting components
– Full system test
– Acceptance test
• Idea of “beta testing” – let the users discover
the bugs and problems for you!
 Implementation - Installation
• Put the system into operation:
– Install hardware, software, networks
– Data conversion - move data from the old to
the new system
– User documentation - explains how to use the
system in language users understand
– Train users of the system – workshops, CD-
ROMs etc.
– System conversion - start up the new system
and stop using the old system
– Fix any problems that arise (corrective
maintenance)
 Conversion Methods – 4
P’s
Old System
Parallel
operation
New System

“Plunge” Old System

conversion
New System

Phased
Conversion Old System New System
(step-at-a-time)

Conversion Old System New System

with a Pilot
phase
Time
Pilot phase
 Maintenance
• Fix it / Make it better
System
Users

Fixes and Problems/New ideas

enhancements
Maintain
the new
system Additional training and
documentation
Technical problems and
new technology
Modifications
Project staff Escalating
maintenance PRODUCTION SYSTEM

back to INITIATION 26
 Maintenance
• Monitor and support the new system
to ensure it continues to meet the
business goals
 Maintenance
• Ongoing systems maintenance

• Corrective Maintenance - correcting errors

(“bugs”) discovered during operations
• Perfective Maintenance – minor enhancements
and modifications to the system to respond to
changing user requirements
– Re-wallpaper a room
• Extensive Maintenance – major changes
(extensions) to the system to suit new
environments (e.g., changes in business needs,
changes in user needs, changes in organization IT
infrastructure)
– Add a backyard deck
– Extensive systems maintenance often spun off as
separate new development project
• Complete replacement
 Waterfall Model

• Waterfall approach – each phase

falls into next phase
– Freeze planning specifications before
analysis
– Freeze analysis specifications before design
– Once go over the waterfall for each phase,
do not go back
• Overlapping (or concurrent) phases
– Waterfall is not realistic, we are not perfect
– Overlaps can be more efficient than
waterfall
 When to use the Waterfall
Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new
platform.
 V-Shaped SDLC Model

• A variant of the Waterfall that emphasizes the

verification and validation of the product.
• Testing of the product is planned in parallel with
a corresponding phase of development
 V-Shaped Steps
• Project and Requirements
Planning – allocate resources
• Product Requirements and
Specification Analysis –
complete specification of the
software system
• Architecture or High-Level
Design – defines how software
functions fulfill the design
• Detailed Design – develop
algorithms for each
architectural component
• Production, operation and
maintenance – provide for
enhancement and corrections
• System and acceptance
testing – check the entire
software system in its
environment
• Integration and Testing –
check that modules
interconnect correctly
• Unit testing – check that each
module acts as expected
• Coding – transform
algorithms into software
 When to use the V-Shaped
Model
• Excellent choice for systems
requiring high reliability – hospital
patient control applications
• All requirements are known up-front
• When it can be modified to handle
changing requirements beyond
analysis phase
• Solution and technology are known