SDLC

2.
The Systems
Development Life Cycle
(SDLC)
CSC 2202 Systems Analysis and Design

The System Development Life
Cycle
It was started in the 1960s and 1970s as the first
documented approach to computer systems
development. All the stages of the development
system are thought about, planned, monitored
and Completed. SDLC is the process by which an
Information System comes to life and maintains
its usefulness to a business as it moves from
inception to replacement.

System Development Life
Cycle
Business need - changing business
conditions prompt request for
new/improved computer system
System development - analyse, design
and implement a system to meet the
business need
System installation - move new system
into production
System Development Life
Cycle
System operation - period of active
use
System obsolescence - system no
longer reflects changed business
needs

System Life Cycle - illustration
Need
Obsolete
Develop
Install
Operate

System Development
Challenges
Critical Success Factors for Systems
Development:
 effectively meet the stated business needs
 build a flexible and maintainable system
 build a reliable system
 produce a system on time and within

budget

Terminologies for the SDLC phases
The phases of the SDLC are described

Differently depending on the author:
Kendall & Kendall terminology
Shelly terminology
Powers et al terminology
Etc.

System Development Life Cycle
(Kendall & Kendall terminology)
Investigation
 Identify problems and opportunities
Determine requirements
Analysis
Design
Develop software
System Test
Implement and evaluate
(Kendall & Kendall terminology)

Systems Development Life Cycle
(Shelly terminology)
➠ Systems planning
➠ Preliminary investigation report
➠ Systems analysis
➠ System requirements document
➠ Systems design
➠ System design specification
➠ Systems implementation
➠ Complete functioning information system
➠ Systems operation and support
➠ Operational information system
SDLC – (Shelly terminology)

➠ Systems planning
➠ Purpose – identify problem’s nature/scope
➠ Systems request – begins the process &
describes desired changes/improvements
➠ Systems planning – includes preliminary
investigation or feasibility study
➠ End product – preliminary investigation report

➠ Systems analysis
➠ Purpose is to learn exactly how the current
system operates
➠ Fact-finding or requirements
determination is used to define all
functions of the current system

➠ Options
➠ Develop a system in-house
➠ Purchase a commercial package
➠ Modify an existing system
➠ Stop development
➠ The end product for this phase is the systems
requirements document

➠ Systems design
➠ Purpose is to satisfy all documented
requirements
➠ Identify all outputs, inputs, files, manual
procedures, & application programs
➠ Avoid misunderstanding through manager and
user involvement
➠ End product is system design specification

➠ Systems implementation
➠ Construct/deliver information system
➠ Prepares functioning, documented system
➠ Write, test, document application programs
➠ User and manager approval obtained
➠ File conversion occurs
➠ Users, managers, IS staff trained to operate and
support the system
➠ Post-implementation evaluation performed

➠ Systems operation and support
➠ New system supports business operations
➠ Maintenance changes correct errors or meet
requirements
➠ Enhancements increase system capability
➠ After several years of operation, systems
experience need for extensive changes
➠ Systems development life cycle ends with
system replacement

System Development Life Cycle illustration
1. Investigation - 2. Determine requirements

Identify problems,
opportunities
3. Analysis
7. Implement
and evaluate
4. Design
6. System Test
5. Develop software
Other Terminology for SDLC phases
Many organisations and many authors

use different terminology for the phases
of the SDLC
However essentially the same activities
are performed
Refer to examples of other terminology

(Powers et al terminology)
Investigation phase
Analysis and General Design phase
Detailed Design and Implementation
phase
Installation phase
Review phase

Investigation phase
Initial investigation
Feasibility study
 Financial feasibility
 Technical feasibility
 Operational feasibility
 Legal /ethical feasibility

Analysis and General Design phase
Existing system review
 build model of existing system
New system requirements
 from User’s point of view
New system design
 sufficient information for management to decide
whether to proceed
Implementation and Installation planning
 plan to cover next phases

Detailed Design and Implementation
phase
Technical design
 for programs (pseudo-code), files, records,
reports, screens
Test specifications and Testing
prepare test plans
Programming and Testing
 write and test program code
User Training
System and Acceptance test
 by Users, simulating production conditions

Installation phase
File conversion
 run programs to convert files into new format
System installation
 critical system transition to production
Options for installation are:
 Cutover can be abrupt
 Operate old and new systems in parallel
(for 2 weeks)
 Phase in new system, over time
 Install version of the system

Review phase
Development recap
 team review of project, for benefit of
future projects
Post implementation review
 evaluate how well the system is working
 to what extent are project benefits being
achieved?

S D L C Phases (general)
Business Survey
Feasibility
Systems Analysis
Systems Design
Programming
Testing
Implementation
Post Implementation Review
Maintenance
Why have a System Development Life Cycle?
Management needs to know:

 project is on time
 project is within budget
These project control stages

(checkpoints) are the end of each
phase of the System Development Life
Cycle

1. Business Survey
Initial broad term report
Estimate:
 project cost
 project resources (people)
 project time
Recommend whether go on to
Feasibility

2. Feasibility
Assess feasibility of the project:
 operational feasibility
 technical feasibility
 financial feasibility
Identify possible solutions and options

Recommend most appropriate to
management
Outline of development plan
3. Systems Analysis
Information Gathering
User Requirements refined to
specify the new system
Goal - User Requirements Document
 design for the new system
 just enough technical detail
for the customer
Report contents geared towards
customer

4. Systems Design
Convert User Requirements into
computer terms
Specify
 how system will operate
 what programs are needed
 what the programs will do

5. Programming and Design Aim
Convert specifications into program
code
Prepare test plans
 for unit testing (individual programs)

5. Programming and Design Aim
Design aim must ensure that the
system is:
 Accurate • Implementable
 Maintainable • Acceptable
 Timely • Flexible
 Robust • Economic
 Efficient • Secure
 Compatible • Portable

6. Testing - make system “bullet
proof”
System Testing & Acceptance
Testing
System Testing
 test
program as part of the whole
system e.g. new program in whole
payroll system

6. Testing - make system “bullet
proof”
Acceptance Testing
 Customers / Users now involved
 usually have their own test plans
 sometimes also use programmer

tests
Sign-Off document - signed by
Customer Coordinator

7. Implementation
Implementation Plan or Update Log
Provides project leader with a list of all:
 files
- new / amended
 screen messages - new / amended
 programs (sources) - new / amended
Timing for lodgment in production

environment decided with customer

8. Post Implementation
Review
BUILDING of the system is now complete
Development recap
 team review - what can be learned from the
project
Post Implementation Review (after 3 or 4
months)
 degree to which system meets objectives
 often results in recommended improvements

9. Maintenance
Ensure customer changes to the system:
 retain quality
 adhere to standards and procedures
Now back at the beginning of the SDLC

Size of maintenance change will
determine whether all (or subset of)
phases of the system Development Life
Cycle are required

Life-Cycle Models
• The waterfall model

• The spiral model
• Rapid application development
• Joint application development
• The V model

Each Phase of SDLC has an
“Output”
Phase Output
Requirements analysis Software Requirements
Specification (SRS),
Design Design Document,

Design Classes
Implementation Code
Test Test Report,

Change Requests

“Life-Cycle” Models
Single-Version Models
Incremental Models
 Single-Version with Prototyping
Iterative Models

“Life-Cycle” Models (1)
Single-Version Models
 Waterfall Model
 Waterfall Model with “back flow”
 “V” model: Integrating testing

Incremental vs. Iterative
These sound similar, and sometimes are
equated.
Subtle difference:
 Incremental: add to the product at each phase
 Iterative: re-do the product at each phase
Some of the models could be used either way

The Waterfall model
The waterfall model

 First described by Royce in 1970
There seem to be at least as many
versions as there are authorities -
perhaps more

Waterfall Model
Requirements
Design
Implementation
Each phase “pours over” into

the next phase.
Test

Waterfall Model
Managers love waterfall models:

 Nice milestones
 No need to look back (linear system), one
activity at a time
 Easy to check progress : 90% coded, 20%
tested

Waterfall Model
 Traditional life cycle
 Analysis, design, code, test & maintenance
 Top down rigidity
 No iteration between phases
 Difficult accommodating uncertainty & risk
 Black box approach

Why Not Waterfall?
2. Requirements are not stable/unchanging.
The market changes—constantly.
The technology changes.
The goals of the stakeholders change.

Why Not Waterfall?
3. The design may need to change during
implementation.
Requirements are incomplete and changing.
Too many variables, unknowns, and novelties.
A complete specification must be as detailed as code itself.
Software is very “hard”.

 Discover Magazine, 1999: Software characterized as the most
complex “machine” humankind builds.

V - Model
The V Model Distinguishes

between Development and
Verification Activities

V - Model
Each phase has corresponding test or validation counterpart
Requirements Acceptance
Analysis Test
System Design Integration

Test
Program Design Unit Test
Implementation
V - Model
Client’s Understanding
Level of Detail
Developer’s Understanding
Requirements Acceptance
Low Elicitation Testing
Problem with VModel:
Client’s Perception is the same as the
Developer’s Perception
System
Analysis
Testing
Design Integration Testing
Object Design Unit Testing
High
Project Time
Problems with V - Model
The V model does not model iteration

Boehm Spiral Model
Four major activities
• Determination of objectives, alternatives,
and constraints
• Risk analysis and prototyping
• Waterfall approach to next level product
• Plan for the next phase cycle:

Boehm Spiral Model

Spiral Model Deals with Iteration
Identify risks
Assign priorities to risks
Develop a series of prototypes for the identified risks
starting with the highest risk.
Use a waterfall model for each prototype
development (“cycle”)
If a risk has successfully been resolved, evaluate the
results of the “cycle” and plan the next round
If a certain risk cannot be resolved, terminate the
project immediately

Limitations of the Waterfall
and Spiral Models
Neither of these model deals well with
frequent change
 The Waterfall model assume that once you are
done with a phase, all issues covered in that
phase are closed and cannot be reopened
 The Spiral model can deal with change between
phases, but once inside a phase, no change is
allowed
What do you do if change is happening more
frequently? (“The only constant is the
change”)
Rapid Application
Development
RAD is a methodology for compressing
the analysis, design, build, and test
phases into a series of short, iterative
development cycles.
This has a number of distinct
advantages over the traditional
sequential development model.

Rapid Application Development
Iteration allows for effectiveness and

self-correction.
Iterations results into many small
refinements and improvements.
An important, fundamental principle of
iterative development is that each
iteration delivers a functional version of
the final system

Like prototyping, uses iterative
development
Uses tools to speed up development
 GUI
 reusable code
 code generation
 programming, language testing and debugging

RAD projects are typically staffed with small

integrated teams comprised of developers,
end users, and IT technical resources.
Small teams, combined with short, iterative
development cycles optimizes speed, unity of
vision and purpose, effective informal
communication and simple project
management.

High Speed
High Quality
And Lower Cost
Quality is a primary concept in the RAD
environment. Systems developed using
the RAD development path meet the
needs of their users effectively and
have low maintenance costs.

Prototyping
Preliminary working version of a system (or
one of its parts)
built quickly and inexpensively
using “friendly, powerful” software
reviewed by end users
suggest changes for system improvements.

Prototyping
Iterative process, say 10 versions

Result - evolve to become final system, or
... throw away, but clarified SDLC
requirements

Prototyping Process
Identify Basic User Requirements
Rapidly Develop Prototype

Iterative
enhancement
Users work with Prototype
Throwaway
Prototype
Obtain User Feedback
Modify the Prototype Evolutionary

Prototype
Prototype
Steps followed by a systems
analyst using a prototype during
the systems analysis phase are
shown

Prototype
*

Prototyping
Prototyping can help to obtain complete
and reliable system requirements
Prototyping process:
 iterative
 User works with latest version of prototype

to determine the refined requirements
 prototype quickly amended (by the User
and systems analyst)
Prototyping tools
Interactive software development tools
Allows designer to quickly:
 design screens, create files, data entry
routines,
 basic reporting functions
Tools should be flexible and easy to use

Prototyping and the SDLC
Prototyping goal is to enhance the System
development process. Prototyping focuses
on the Analysis and General Design
phase.
Outcome –
 one extreme is prototype actually becomes the
finished system (after many iterations)
 other extreme is throw away prototype and
build system using conventional methods
 BUT now have very high level of confidence
with accuracy and completeness of User
Requirements
Prototyping
Performing analysis, design, and
implementation phases concurrently,
and repeatedly
Users see system functionality quickly
and provide feedback
Decision maker learns about problem
But can lose gains in repetition

Prototyping
Need
Planning
Analysis
Design
Implementation
Prototype
Prototype Not OK
Prototype OK
System

Uses of Prototyping
● Verifying user needs
● Verifying that design = specifications
● Selecting the “best” design
● Developing a conceptual understanding of novel
situations

Uses of Prototyping
● Testing a design under varying environments
● Demonstrating a new product to upper
management
● Implementing a new system in the user
environment quickly

Prototyping
Proposed Advantages Disadvantages in practice
 Improved user  Prototypes are used “as is”
communication  Integration often
 Users like it difficult

 Design flaws
 Low risk
 Poor performance
 Avoids over-design
 Difficult to manage process
 Experimentation
 Creates unrealistic
and innovation expectations
 Spreads labor to  Documentation is difficult
user department

Advantages of Prototyping
Short development time
Short user reaction time
Improved user understanding
Low cost

Disadvantages of Prototyping
Gains may be lost in
Thorough understanding information
System’s benefits and costs
Detailed description of information needs
Easy to maintain IS design
Well-tested IS
Well-prepared users

Alternative system development
methodologies
Alternative methodologies to SDLC are:
 Structured approaches.
 StructuredSystem Analysis & Design
Methodology
 Yourdon
 Jackson system development
 Merise
 Work flow systems
 Prototyping.

Alternative system development
methodologies
Alternative methodologies to SDLC are:

 Joint Application Development
 Rapid Application Development
 Object oriented analysis and design.
 Soft Systems Methodology.

JAD
Joint application development (JAD)

 Task force of users, managers, and IS staff
 Objectives
 Gather information
 Discuss business needs
 Define the new system requirements
 Methods
 Team usually meets at specific location
 Team has project leader and recorder(s)
 Key users participate in intense development effort
 JAD can be costly, but highly effective
CSC 2202 Systems Analysis and

ClickDesign
to see Figure 3-11
Package
RAD
Rapid application development (RAD)
 Team method similar to JAD, but goes further
 RAD phases resemble a mini-SDLC
 Requirements planning, user design, construction, and
cutover
 RAD involves a continuous design process
 Team can react quickly
 Final objective is a functioning system
 RAD can be faster and less costly, but stresses

system mechanics rather than strategic needs

OOAD
Object-oriented (O-O) systems development

 Object-based model
 Objects and their attributes are abstract entities
 Classes and subclasses

Review Questions
1. List and describe the major stages of the

systems development life cycle.
2. What is prototyping and what
advantages does it offer in the SDLC?
3. Explain why the investigation phase and
the initial analysis and design phases are
perhaps the most critical stages of the
SDLC.
4. Explain the systems life cycle and
describe why this concept is important to
systems developers.

SDLC

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDLC

Uploaded by

Copyright:

Available Formats

2.

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

 build a reliable system

 produce a system on time and within

CSC 2202 Systems Analysis and Design

The phases of the SDLC are described

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

1. Investigation - 2. Determine requirements

Many organisations and many authors

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

 Legal /ethical feasibility

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

Management needs to know:

These project control stages

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

Identify possible solutions and options

CSC 2202 Systems Analysis and Design

 what the programs will do

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

 sometimes also use programmer

CSC 2202 Systems Analysis and Design

 programs (sources) - new / amended

Timing for lodgment in production

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

Now back at the beginning of the SDLC

CSC 2202 Systems Analysis and Design

• The waterfall model

CSC 2202 Systems Analysis and Design

Design Design Document,

Test Test Report,

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

CSC 2202 Systems Analysis and Design

Some of the models could be used either way

CSC 2202 Systems Analysis and Design

The waterfall model

CSC 2202 Systems Analysis and Design

Each phase “pours over” into

CSC 2202 Systems Analysis and Design

Managers love waterfall models:

CSC 2202 Systems Analysis and Design