SDLC MODELS

1
 1. Software Development Life Cycle (SDLC)

• It is well defined , Structured sequence of stages or phases

in software engineering to develop the intended software
product.
• Software-development life-cycle is used to facilitate the
development of a large software product in a systematic, well-
defined, and cost-effective way.

• An information system goes through a series of phases from

conception to implementation. This process is called the
Software-Development Life-Cycle.

2
 1.1 Stages of SDLC

- Maintainance Communication

Deployment Requirement
gathering

Testing Feasibility
study

Coding
Requirement
Designing analysis
 Contd…Phases or stages of SDLC

• Communication : This is the first step where the user initiates the request for the
desired software product.
• Requirement Gathering and analysis : It involves the discussions with various
stakeholders to understand the exact requirement.
• Feasibility study: - The main aim of feasibility study is to determine whether it
would be financially and technically feasible to develop the product.
• Requirement analysis and Defining Requirement : The aim of this step is to
document gathered requirements properly. This is done through Software
requirement Specification (SRS) .
• Design: - The goal of the design phase is to transform the requirements specified in
the SRS document into a structure that is suitable for implementation in some
programming language . Design specification Document is outcome of this phase.

4
• Coding and unit testing:-The purpose of the coding and unit testing phase (sometimes called
the implementation phase) of software development is to translate the software design into
source code. Each component of the design is implemented as a program module. The end-
product of this phase is a set of program modules that have been individually tested. Code
Listings are generated after this phase.

• Integration and system testing: - Integration of different modules is undertaken once they
have been coded and unit tested During each integration step, the partially integrated system is
tested and a set of previously planned modules are added to it. Finally, when all the modules
have been successfully integrated and tested, system testing is carried out. The goal of system
testing is to ensure that the developed system conforms to its requirements laid out in the SRS
document. Test Reports are generated after this phase.

• Deployment : This leads to the deployment of the product in the market and perform
acceptance testing

• Maintenance: - Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself. Many studies carried out in the past confirm this and
indicate that the relative effort of development of a typical software product to its maintenance
effort is roughly in the 40:60 ratio. This phase continues till the software is in use.
1.3 Effort distribution of all phases
 2. SDLC Paradigm or Model

SDLC Model is a diagrammatic and descriptive representation of SDLC .

It maps the SDLC phases in different ways.

Generic or basic phases of any software Development process model are:

Phase Output

Requirement elicitation , SRS

Analysis and specification

System design SDD

Coding source code

Testing Test Report

 2.1 SDLC Models

Different software life cycle models have been proposed so far. Each of
them has some advantages as well as some disadvantages.
A few important and commonly used life cycle models are as follows:
1. Build and Fixed Model
For small
2.Classical Waterfall Model softwares
3. Iterative Model
4. Prototyping Model
5. Evolutionary Model
6. Spiral Model For
complex
7. Rapid Application Development model (RAD)
softwares
8. Agile

8
 2.2 Need for SDLC Model

Various reasons for using a life-cycle model

include:
– Helps to understand the entire process
– Enforces a structured approach to development
– Enables planning of resources in advance
– Enables subsequent controls of them
– Aids management to track progress of the
system
1 .Build and Fix Model
 Contd…...
• This model is an adhoc approach for developing a
project.
• This model includes the following two phases.
Build: In this phase, the software code is developed
and passed on to the next phase.
Fix: In this phase, the code developed in the build
phase is made error free. Also, in addition to the
corrections to the code, the code is modified
according to the user's requirements.

• This model is completely unsatisfactory and should

not be adopted.
 Advantages of Build and Fix Model
• Requires less experience to execute or manage other
than the ability to program.
• Suitable for smaller software.
• Requires less project planning.
Disadvantages of Build and Fix Model
• No real means is available of assessing the progress,
quality, and risks.
• Cost of using this process model is high as it requires
rework until user's requirements are accomplished.
• Informal design of the software as it involves unplanned
procedure.
• Maintenance of these models is problematic.
 2. Waterfall Model

• First Process Model

• Oldest model for software engineering, hence called as Classical Life
Cycle Model.
• It is very simple to understand and use.
• It is also referred to as a linear-sequential life cycle model, because its
software development process follows a linear sequential flow.
• It is a baseline for other models
Classical waterfall model divides the life cycle into the following phases :
1. Requirements Analysis and Specification
2. Design
3. Coding
4. Testing
5. Deployment
6. Maintenance 1
3
contd……….Phases of Classical Waterfall Model
This model is named “waterfall model” because its diagrammatic
representation resembles a cascade of waterfalls.

1
4
 The sequential phases in Waterfall model are:

• Requirement analysis: All possible requirements of the system to be developed are captured
in this phase and documented in a requirement specification doc.

• System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

• Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.

• Testing: All the units developed in the implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is tested for any faults and failures.

• Deployment of system: Once the functional and non functional testing is done, the product is
deployed in the customer environment or released into the market.

• Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
 contd….Its Pros

• This model is simple and easy to understand and use.

• Being a linear model, it is very simple to implement. The amount of
resources required to implement this model are minimal.
• Waterfall model works well for smaller projects where requirements are
very well understood.
• Documentation is produced at every stage of the software’s
development. This makes understanding the product designing procedure,
simpler.
• Progress of the system is measurable.
• Milestones are well understood.
• After every major stage of software coding, testing is done to check the
correct running of the code.
• Sets requirements stability
 Contd….Its cons

• Assumes that requirements can be specified and frozen early

• Not suitable for the projects where requirements are at a
moderate to high risk of changing.
• It leads to blocking states:
• Follows the “big bang” approach – all or nothing delivery.
• High amounts of risk and uncertainty.
• Very document oriented, requiring documents at the end of
each phase
• You cannot go back a step, if the design phase has gone
wrong, things can get very complicated in the implementation
phase.
• Not a good model for long, complex and object-oriented
projects.
 Contd…Waterfall Application

Some situations where the use of Waterfall model is most appropriate are:

• The project is short.

• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• User participation is limited
• The developers team have less experience
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• Porting an existing product to a new platform.
• Well suited for projects where requirements can be understood easily and
technology decisions are easy i.e. for familiar type of projects it still may be the
most optimum
 Contd…Waterfall Model problems

• It doesn’t scale up well for large projects.

• This model is not suitable for accommodating any change.
• A working model is not available until late in the project time
plan
• Real projects rarely follow the sequential flow since they are
always iterative
• It is difficult to define all requirements at the beginning of the
project.
• Once the product is ready then only it can be demoted to
the end users. Once the product is developed and if any failure
occurs then the cost of fixing such issues are very high, because
we need to update everywhere from document till the logic.
 Modified waterfall model
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
 2. Incremental Model or Iterative Waterfall model

• It combines the elements of waterfall model in an iterative

fashion.
• It Counters the “all or nothing” drawback of the waterfall
model
• Develop and deliver software in increments(small pieces)
• Feedback from one iteration is used in the future iterations
• It does not attempt to start with a full specification of
requirements.
• The basic idea of this model is to start the process with
requirements and iteratively enhance the requirements until
the final software is implemented.
• Incremental Model

Core product
• The Incremental Model Simply combines elements of the linear
sequential model with the iterative philosophy of prototyping. The
first increment is a core product.

• Iterative in nature, like prototyping.

• Focus on the delivery of a operational product with each increment.
• Particular useful when staffing is unavailable for a
complete implementation by the business deadline.
• In this model, the software is broken down into several modules,
which are incrementally developed and delivered. First, the
development team develops the core module of the system and then
it is later refined into increasing levels of capability of adding new
functionality in successive versions.
• Each linear sequence produces a deliverable increment of the
software.
 Its pros
• In iterative model we are building and improving the
product step by step. Hence we can track the defects at
early stages. This avoids the downward flow of the defects.
• For a very little span , at least core product can be
delivered to the customer
• In iterative model less time is spent on documenting and
more time is given for designing.
• Risk of changing requirements is reduced
• The feedback from early increments improve the later stages.
• Smaller sub-projects are easier to control and manage.
• User is highly satisfied and highly involved
 Its cons

• Rework may increase

• Requires good planning and design
• Requires early definition of a complete and
fully functional system to allow for the
definition of increments
• Becomes invalid when there is time
constraint on the project schedule or when the
users cannot accept the phased deliverables.
 When to use Iterative model

• When limited functionality of software is needed quickly.

• When risk of long projects cannot be taken
• Used commonly in businesses who want quick response for software.
• When requirements are reasonably well defined
• Most of the requirements are known up-front but are expected to
evolve over time
• On projects which have lengthy development schedules
• On a project with new technology
• When the project is big.
• Time and lack of skilled personnel are the main hindrances in this pro
ject.
 3. RAD MODEL

 RAD model is Rapid Application Development model.

 It uses generalized approach
 It is very high speed , short development cycle model based
construction approach is adopted then the RAD model is used.
 It involves multiple team work on developing the software system
parallely.

 It is a based on prototyping and iterative development.

 In RAD the Components are developed in parallel Manner.

 It is a faster software development process.

Contd..
 Contd..

1. Requirement planning phase:

Requirement are captured using any group
elicitation technique
2. User description :
Joint teams of developers and users are constituted
to prepare understand and review the
requirements.
The team may use automated tools to capture
information from the other users
 Contd..

3. Construction phase: This phase combines the

detailed design, coding and testing phase of
waterfall model. Hence , we release the
product to customer. It is expected to use code
generators, screen generators and other types
of productivity.
4. Cut over phase: This phase incorporates
acceptance testing by the users, installation of
the system and user training.
 Its advantages
• RAD model enables rapid delivery as it reduces the overall development
time due to reusability of the components and parallel development.

• RAD works well only if high skilled engineers are available and the
customer is also committed to achieve the targeted prototype in the
given time frame. If there is commitment lacking on either side the
model may fail.

• Changing requirements can be accommodated.

• Iteration time can be short with use of powerful RAD tools.
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
 Its disadvantages
• Dependency on technically strong team members for
identifying business requirements.
• Only system that can be modularized can be built
using RAD.
• Requires highly skilled developers/designers.
• Inapplicable to cheaper projects as cost of modeling
and automated code generation is very high.
• Suitable for systems that are component based and
scalable.
 When to use RAD
• RAD should be used only when a system can be
modularized to be delivered in incremental manner.
• It should be used only if the budget permits use of
automated code generating tools.
• RAD SDLC model should be chosen only if domain
experts are available with relevant business knowledge.
• Should be used where the requirements change during
the course of the project and working prototypes are to
be presented to customer in small iterations of 2-3
months.
 5. Evolutionary Model

• Evolutionary process model resembles iterative enhancement model.

• The objective is to work with client and to evolve a final system
from an initial outline specification.
• Should start with well-understood requirements.
• They are characterized in manner that enables the software engineers to
develop increasingly more complete version of a software.
• These models are applied because as the requirements often change
so the end product will be unrealistic, where a complete version is
impossible, so due to tight market deadlines it is better to introduce a
limited version to meet the pressure.
• Thus the software engineers can follow a process model that has been
explicitly designed to accommodate a product that gradually complete
over time.
• The process is iterative as the software engineer
goes through a repetitive process of requirement
until all users and stakeholders are satisfied.
• This model differs from the iterative
enhancement model in the sense that this does
not require a useable product at the end of each
cycle. In evolutionary development, requirements
are implemented by category rather than by
priority.
Evolutionary Model
 Its advantages
• Customer involvement in the process:
– More likely to meet the user requirement.
• Deals constantly with changes
• Provides quickly an initial version of the
system
• Involves all development teams
• In case major problems are foreseen, the
developer can stop the development after some
iterations.
 Its disadvantages
• Not suitable for large applications
• Quick fixes may be involved
• User can get too involved
• Structure of system can be damaged since many changes could be
made
• This model lacks process visibility and offers poor structure to the
project because of the ad-hoc manner of development
• It is difficult to measure progress and produce documentation
reflecting every version of the system as it evolves. This paradigm
usually results in badly structured programs due to continual code
modification.
• Production of good quality software using this method requires highly
skilled and motivated programmers.
 Its application
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
interface)
• This model is useful for projects using new
technology that is not well understood.
• This is also used for complex projects where
all functionality must be delivered at one
time, but the requirements are unstable or
not well understood at the beginning.
 Types of evolutionary model

-Prototyping Model -Spiral Model

PROTOTYPING:
• Prototyping approach, also known as evolutionary approach, came to
picture because of failures that occurred in the waterfall approach and
iterative approach.

• The prototyping model is applied when detailed information related

to input and output requirements of the system is not available

• This model allows the users to interact and experiment with a working
model of the system known as prototype.

• The prototype gives the user an actual feel of the system.

 6. Prototype

• A prototype is the sample implementation of the real system.

• It shows limited and main functional capabilities of the
proposed system.
• A prototype is a model or a program which is not based on
strict planning.
• It helps the customer determine how the feature will
function in the final software.
• It is used to allow the users evaluate developer proposals.
• It is a very useful technique to obtain accurate
requirements of the system.
 Contd..
1. Requirements gathering and analysis: A prototyping model begins with requirements analysis
and the requirements of the system are defined in detail. The user is interviewed in order to
know the requirements of the system.
2. Quick design: When requirements are known, a preliminary design or quick design for the
system is created. It is not a detailed design and includes only the important aspects of the
system, which gives an idea of the system to the user. A quick design helps in developing the
prototype.
3. Build prototype: Information gathered from quick design is modified to form the first
prototype, which represents the working model of the required system.
4. User evaluation: Next, the proposed system is presented to the user for thorough evaluation of
the prototype to recognize its strengths and weaknesses such as what is to be added or
removed. Comments and suggestions are collected from the users and provided to the
developer.
5. Refining prototype: Once the user evaluates the prototype and if he is not satisfied, the current
prototype is refined according to the requirements. That is, a new prototype is developed with
the additional information provided by the user. The new prototype is evaluated just like the
previous prototype. This process continues until all the requirements specified by the user are
met. Once the user is satisfied with the developed prototype, a final system is developed on
the basis of the final prototype.
6. Engineer product: Once the requirements are completely met, the user accepts the final
prototype. The final system is evaluated thoroughly followed by the routine maintenance on
regular basis for preventing large-scale failures and minimizing downtime.
 Types of Prototyping
• Throwaway/Rapid Prototyping

• Evolutionary Prototyping
 Contd..

Throw away Prototype:

• Prototype is constructed with the idea that it will be
discarded , after analysis is complete and the final
system is built from the scratch.
• During Requirement phase, a quick and dirty throw
away prototype can be constructed and given to user
in order to determine feasibility of requirement,
validate that particular requirement is really
necessary, uncovering missing requirement .
 Contd..

• Evolutionary Prototype
--Prototype is built with the idea that it will eventually be
converted into final system
---It will not be built in a dirty fashion
---The evolutionary prototype evolves into the final product,
obtain experience it and then based on that experience go back
and repeat the entire process again.
 Contd…Its Advantages
• Misunderstanding between software developers an customers may be identified as
functions demonstrated.
• It is a very useful technique to obtain accurate requirements of the system and to
speed up the development process
• Errors can be detected much earlier.
• Users are actively involved in the development.
• Missing functionality can be identified easily.
• Confusing user requirements may be identified and refined.
• When prototype is shown to the user he gets a proper clarity and 'feel' of
the functionality of the software and he can suggest changes and modifications.
• This type of approach of developing the software is used for non-IT-literate people.
They usually are not good at specifying their requirements, nor can tell properly
about what they expect from the software.
• When client is not confident about the developer's capabilities, he asks for a
small prototype to be built. Based on this model, he judges capabilities of
developer.
• It reduces risk associated with the software.
 Contd..Its Disadvantages

• In a rush to get it working, overall software quality or long term

maintainability are generally overlooked .
• Excessive development time when throw away prototyping is used.
• It gives client a false impression that a few minor changes to the
prototype will give them the required system.
• If the user is not satisfied by the developed prototype, then a new
prototype is developed. This process goes on until a perfect prototype
is developed. Thus, this model is time consuming and expensive.
• Too much involvement of client, is not always preferred by the
developer.
• The effort invested in building prototypes may be too much if not
monitored properly
 Its application

• Requirements are not well understood and not stable.

• Prototype model should be used when the desired system
needs to have a lot of interaction with the end users.
• E.g : online systems, web interfaces etc.
• Short lived demonstration.
• Prototyping ensures that the end users constantly work with
the system and provide a feedback which is incorporated in the
prototype to result in a useable system.
 7. Spiral Model

• This model of development combines the features of the

prototyping model and the systems development life cycle
(SDLC) with very high emphasis on risk analysis.
• Include new element : Risk element
• It allows for incremental releases of the product, or
incremental refinement through each iteration around the
spiral.
• It is used when all requirements are clear . Here developer
starts developing with some requirements and develop
working model and vendor itself test it and refine it unlike
we do in prototyping model
Spiral Model
 Contd..

• The radial dimension represents the cummulative costs. Each

path around the spiral is indicative of increased costs.
• The angular dimension represents the progress made in
completing each cycle. Each loop of the spiral from X axis
clockwise through 360 represents one phase. One phase is split
roughly into four sectors of major activities:
1. Planning
2. Risk Analysis
3. Development or Engineering Phase
4. Assessment or Evaluation
Steps Involved in spiral
 Contd..

• Planning Phase: Requirements are gathered during the planning phase.

• Risk Analysis: In the risk analysis phase, a process is undertaken to

identify risk and alternate solutions. A prototype is produced at the end
of the risk analysis phase. If any risk is found during the risk analysis
then alternate solutions are suggested and implemented.

• Engineering Phase: In this phase software is developed, along

with testing at the end of the phase. Hence in this phase the development
and testing is done.

• Evaluation phase: This phase allows the customer to evaluate the output
of the project to date before the project continues to the next spiral.
 Advantages
• High amount of risk analysis hence, avoidance of Risk is
enhanced.
• The spiral model is favored for large, expensive, and
complicated projects.
• Additional Functionality can be added at a later date.
• Development can be divided into smaller parts and more risky
parts can be developed earlier which helps better risk
management.
• Development is fast
• Has room for customer feedback and the changes are
implemented faster.
• Better understanding between developer and customer
 Disadvantages

• Can be a costly model to use.

• Risk analysis is important phase, hence requires
expert people.
• Project’s success is highly dependent on the risk
analysis phase.
• Management is more complex.
• Not suitable for small or low risk projects and
could be expensive for small projects.
• Spiral may go indefinitely(infinitely).
 When to use Spiral Model

• When there is a budget constraint and risk evaluation is

important.
• Requirements are complex and need evaluation to get
clarity.
• Significant changes are expected(research and
exploration) in the product during the development cycle.
• When the project is large.
• Where enough time frame is their to get end user
feedback.
• Where releases are required to be frequent.
 Why it is called as meta model

Because it comprises of other models of

SDLC, both waterfall & prototype models are
used in it .
Here we do software development
systematically over the loops & at the same
time we make a prototype & show it to user
after completion of various phase. This way
we are able to reduce risks as well as follow
systematic approach.
 8. Agile Model
• Its Principle : Build short Build often

• Agile model is a combination of iterative and incremental

process models with focus on process adaptability and
customer satisfaction by rapid delivery of working software
product.
• Software is developed in incremental, rapid cycles. This
results in small incremental releases with each release
building on previous functionality
Contd..
 Contd…What is agile?

• Agile model believes that every project needs to be handled

differently and the existing methods need to be tailored to best
suit the project requirements. In Agile, the tasks are divided to
time boxes (small time frames) to deliver specific features for
a release.
• Iterative approach is taken and working software build is
delivered after each iteration. Each build is incremental in
terms of features; the final build holds all the features required
by the customer
Contd…
Following are the Agile Manifesto principles −

• Individuals and interactions − In Agile development, self-

organization and motivation are important, as are interactions
like co-location and pair programming.
• Working software − Demo working software is considered the
best means of communication with the customers to understand
their requirements, instead of just depending on documentation.
• Customer collaboration − As the requirements cannot be
gathered completely in the beginning of the project due to
various factors, continuous customer interaction is very
important to get proper product requirements.
• Responding to change − Agile Development is focused on
quick responses to change and continuous development
 Its Advantages
• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools.
Customers, developers and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months).
• Close, daily cooperation between business people and developers.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
• Is a very realistic approach to software Development.
• Promotes teamwork and cross training.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned
context.
• Little or no planning required.
• Gives flexibility to developers
 Its Disadvantages
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must
without which it will not work.
• Strict delivery management dictates the scope, functionality to be
delivered, and adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear,
team can be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum
documentation generated.
• Transfer of technology to new team members may be quite
challenging due to lack of documentation.
• In case of some software deliverables, especially the large ones, it is
difficult to assess the effort required at the beginning of the software
development life cycle.
When to use Agile Model :

• When new changes are needed to be implemented. The

freedom agile gives to change is very important. New changes
can be implemented at very little cost because of the frequency
of new increments that are produced.
• Unlike the waterfall model in agile model very
limited planning is required to get started with the project.
Agile assumes that the end users’ needs are ever changing in a
dynamic business and IT world. Changes can be discussed and
features can be newly effected or removed based on feedback.
This effectively gives the customer the finished system they
want or need.
 Agile vs Waterfall model
• Agile is based on the adaptive software development methods, whereas
the traditional SDLC models like the waterfall model is based on a
predictive approach. Predictive teams in the traditional SDLC models
usually work with detailed planning and have a complete forecast of the
exact tasks and features to be delivered in the next few months or during
the product life cycle.
• Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle. Any changes to be incorporated
go through a strict change control management and prioritization.
• Agile uses an adaptive approach where there is no detailed planning
and there is clarity on future tasks only in respect of what features need
to be developed. There is feature driven development and the team adapts
to the changing product requirements dynamically. The product is tested
very frequently, through the release iterations, minimizing the risk of any
major failures in future
END