Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 55

SDLC and Related

Methodologies
Contemplative Questions

 What are the various approaches to


developing Information Systems?
 Is there one best way?
 What is the difference between
techniques, methodologies and tools?
 What does the popular term “SDLC”
actually mean?
SDLC

 SDLC stands for


– Systems
– Development
– Life
– Cycle
 What does it mean?
SDLC
 SDLC stands for
– Systems Development Life Cycle
– First, SDLC is a Life Cycle.
– All systems have a life cycle or a series of stages they
naturally undergo. 
 The number and name of the stages varies, but the primary
stages are conception, development, maturity and decline.
 The systems development life cycle (SDLC) therefore,
refers to the development stage of the system’s life cycle.

Why are we so interested in the development stage?


What about conception, maturity and decline?
Methodologies
 Is there a difference between the term SDLC and
the term ‘methodology’?
 Whereas the SDLC refers to a stage all systems
naturally undergo, a methodology refers to an
approach invented by humans to manage the
events naturally occurring in the SDLC. 
 A methodology is, in simple terms, a set of steps,
guidelines, activities and/or principles to follow in a
particular situation.
– Most methodologies are comprehensive, multi-step
approaches to systems development
– There are many methodologies out there. See
www.methodology.org .
SDLC vs. Methodology
 It is confusing, but unfortunately, the term
SDLC is frequently used synonymously with
the waterfall or traditional approach for
developing information systems.
– “The Waterfall approach”
 This approach essentially refers to a linear sequence of
stages to develop a system from planning to analysis
to design to implementation. 
 Stages are followed from beginning to end. 
 Revisiting prior stages is not permitted. 
Approaches to Systems
Development
 Process-Oriented Approach
– Focus is on flow, use and transformation of data
in an information system
– Involves creating graphical representations such
as data flow diagrams and charts
– Data are tracked from sources, through
intermediate steps and to final destinations
– Natural structure of data is not specified
Approaches to Systems
Development
 Data-Oriented Approach
– Depicts ideal organization of data,
independent of where and how data are
used
– Data model describes kinds of data and
business relationships among the data
– Business rules depict how organization
captures and processes the data
Approaches to Systems Development

Which is better, the Process Approach or the Data Approach?

Process Approach:
“Let’s look at all of our
processes. Processes take
precedence over data. Get the
processes correct first. Then
we’ll address what data is
important.”

Data Approach:
“Forget the processes, let’s
look at the data. Data comes
first. Get the data correct, then
see how the processes actually
use the data.”
Databases and
Application Independence
 Database
– Shared collection of logically related data
– Organized to facilitate capture, storage and
retrieval by multiple users
– Centrally managed
– Designed around subjects such as Customers or
Suppliers
 Application Independence
– Separation of data from the applications, e.g.
 Payroll data is part of the enterprise-wide data model and
can be used by many systems, not just the Payroll System
Systems Development
Life Cycle
 Every textbook has different names for
the stages of the SDLC
– Usually they stages are
 Planning (just after Conception)
 Analysis

 Design

 Implementation

 Maintenance (starting Maturity)

1.11
Systems Development
Life Cycle
 This text highlights 6 distinct phases:
– Project Identification and Selection
– Project Initiation and Planning
– Analysis
– Design
– Implementation
– Maintenance
Stages of the SDLC

Sy
Sy st IS 4
st IS em 2
em 42 sD 2
sA 1 es
na ig
lys n
is
Phases of the Systems
Development Life Cycle
1. Project Identification and Selection
– Two Main Activities
 Identification of need
 Prioritization and translation of need into a development
schedule
– Helps organization to determine whether or not
resources should be dedicated to a project.
2. Project Initiation and Planning
– Two Activities
 Formal preliminary investigation of the problem at hand
 Presentation of reasons why system should or should not
be developed by the organization
Systems Development
Life Cycle
 Analysis
– Study of current procedures and
information systems
 Determine requirements
– Study current system
– Structure requirements and eliminate redundancies
 Generate alternative designs
 Compare alternatives

 Recommend best alternative


Systems Development
Life Cycle
 Design
– Logical Design
 Concentrates on business aspects of the system
– Physical Design
 Technical specifications
 Implementation
– Implementation
 Hardware and software installation
 Programming
 User Training
 Documentation
Systems Development
Life Cycle
 Maintenance
 System changed to reflect changing
conditions
 System obsolescence

A good way to learn the stages of the


SDLC is to create deliverables (output)
of each stage in the process.
SDLC

A framework that
describes the activities
performed at each stage
of a software
development project.
SDLC PHASES
 Requirements Gathering and Analysis
 
 Design

 Development

 Testing

 Implementation

 Maintenance
Requirement gathering and
analysis
 Business Analyst is the key person
 Identify stake holders- Meet and Elicit
Requirements
 After requirement gathering –analyze,
validate, modify and finalize Requirement
Specification document
Design
 Technical Architect is the key person
 Capture structure and behavior of the
software through
– HLD-High Level Design
– LLD-Low Level Design
 UML diagrams-class, deployment,
sequence
 Data structure details, User Interface
details, algorithmic details
Development
 Project manager is the key person
 Development team will
– Develop the software

– Release the versions or build as per plan

– Rectify defects or bugs when reported

– Support Testers, Implementers, Business analyst when


required
Testing

 Test manager is the key person


 Functionality Testing
 Non Functional Requirements Testing
 Load Testing
 Can use-Black box, White box testing
methods
 Can deploy- Automated Testing Tools
Implementation

 Implementer is the key person, he will

Install-Configure-demonstrate

Train-Hand hold-Test Run

Parallel Run-and finally- Live Run


Maintenance

 Support/Maintenance specialist is the key


person
 Ensure business continuity and software
availability
 Service level parameters, End user Support,
Issue escalation
 Routine procedures- Backups etc
Alternative Approaches
 Prototyping
– Building a scaled-down working version of the
system
– Advantages:
 Users are involved in design
 Captures requirements in concrete form
 Rapid Application Development (RAD)
– Utilizes prototyping to delay producing system
design until after user requirements are clear
Prototyping
Fig. 1-6
Alternative Approaches

 Joint Application Design (JAD)


– Users, Managers and Analysts work
together for several days
– System requirements are reviewed
– Structured meetings
Alternative Approaches
 Evolutionary or spiral methodology
The *** never gets done! Different versions, always in
different stages.
Agile Methods
What makes it Different?
Three Processes
Time Scales
SDLC MODELS

To help understand and


implement the SDLC phases
various SDLC models have been
created by software development
experts, universities, and
standards organizations.
Reasons for using SDLC
Models
 Provides basis for project planning, estimating &
scheduling
 
 Provides framework for standard set of
terminologies, activities & deliverables

 Provides mechanism for project tracking & control

 Increases visibility of project progress to all


stakeholders
Advantages of using an
appropriate SDLC
 Increased development speed

 Increased product quality

 Improved tracking & control

 Improved client relations


 
 Decreased project risk
 
 Decreased project management overhead
Common Life Cycle
Models
 Waterfall

 Spiral/Iterative

 Agile
Waterfall Model
Waterfall Model
 Oldest and most well-known SDLC model

 Follows a sequential step-by-step process


from requirements analysis to maintenance.

 Systems that have well-defined and


understood requirements are a good fit for
the Waterfall Model
Waterfall Model
Strengths
 Easy to understand, easy to use

 Provides structure to inexperienced staff


 
 Milestones are well understood

 Sets requirements stability

 Good for management control (plan, staff, track)

 Works well when quality is more important than cost or


schedule
Waterfall Model
Weaknesses
 All requirements must be fully specified upfront
 Deliverables created for each phase are considered frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software development – iterations of
phases
 Integration is one big bang at the end
 Difficult to adapt evolving technologies
 Need to wait the entire process to get feedback from customers,ie, lack of instant
feedback
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.


Spiral/Iterative Model
Spiral Model
 Spiral Model is a “risk-driven” iterative model
 
 Divides a project into iterations

 Each iteration deals with 1 or more risks

 Each iteration starts with small set of requirements and


goes through development phase (except Installation
and Maintenance) for those set of requirements.
Spiral Model
 Iterate until all major risks addressed and
the application is ready for the Installation
and Maintenance phase (production)

 Each of the iterations prior to the production


 version is a prototype of the application.

 Last iteration is a waterfall process


SPIRAL Model Strength
 Provides early indication of insurmountable risks,
without much cost 

 Critical high-risk functions are developed first

 The design does not have to be perfect

 Users see the system early because of rapid prototyping


tools

 Users can be closely tied to all lifecycle steps Early and


frequent feedback from users
SPIRAL Model
Weaknesses
 Time spent for evaluating risks too large for small or low-risk
projects

 Time spent planning, resetting objectives, doing risk analysis


and prototyping may be excessive

 The model is complex

 Risk assessment expertise is required

 Spiral may continue indefinitely

 May be hard to define objective, verifiable milestones that


indicate readiness to proceed through the next iteration
When To Use SPIRAL
Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 New product line 
 Significant changes are expected (research
and exploration)
AGILE Model
AGILE Model
 Speed up or bypass one or more life cycle phases

 Usually less formal and reduced scope

 Used for time-critical applications

 Used in organizations that employ disciplined


methods
Some AGILE Methods

 Scrum

 Rapid Application Development (RAD)

 Extreme Programming (XP)

 Adaptive Software Development (ASD)

 Feature Driven Development (FDD)

 Crystal Clear

 Dynamic Software Development Method (DSDM)

 Rational Unify Process (RUP)


AGILE Model Strengths
 Deliver a working product faster than conventional
linear development model

 Customer feedback at every stage ensures that the


end deliverable satisfies their expectations

 No guesswork between the development team and


the customer, as there is face to face
communication and continuous inputs from the
client
AGILE Model Weaknesses
 For larger projects, it is difficult to judge the
efforts and the time required for the project
in the SDLC.

 Since the requirements are ever changing,


there is hardly any emphasis, which is laid
on designing and documentation. Therefore,
chances of the project going off the track
easily are much more
SCRUM

You might also like