Comparison between various SDLC Model

SDLC

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to
develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the
quality of software and the overall development process.

Types of SDLC Model

Waterfall Model

The Waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of software implementation. This means that any phase in the development process begins only if the
previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle
changes in requirement. The waterfall approach is the earliest approach and most widely known that was used for software
development.

V-Shaped Model

It is an extension of the waterfall model, Instead of moving down in a linear way, the process steps are bent upwards after the
implementation and coding phase, to form the typical V shape. The major difference between the V-shaped model and
waterfall model is the early test planning in the V-shaped model.

Spiral Model

It is combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and
bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The
spiral model is favored for large, expensive, and complicated projects. This model uses many of the same phases as the
waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and
simulations.

Iterative and Incremental Model

It is developed to overcome the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment
with the cyclic interactions in between. The basic idea behind this method is to develop a system through repeated cycles
(iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned
during the development of earlier parts or versions of the system. It can consist of mini waterfalls or mini V-Shaped model.

Prototyping Model

It refers to the activity of creating prototypes of software applications, for example, incomplete versions of the software
program being developed. It is an activity that can occur in software development and It used to visualize some component of
the software to limit the gap of misunderstanding the customer requirements by the development team. This also will reduce
the iterations may occur in the waterfall approach and hard to be implemented due to the inflexibility of the waterfall
approach. So, when the final prototype is developed, the requirement is considered to be frozen.

Rapid application development

Rapid application development is a software development methodology that uses minimal planning in favor of rapid
prototyping. A prototype is a working model that is functionally equivalent to a component of the product.

In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to make the complete
product for faster product delivery. Since there is no detailed preplanning, it makes it easier to incorporate the changes within
the development process.
Model/Feature Waterfall Prototype RAD Incremental Spiral V-Model
Well Defined Yes No Yes No No Yes
Requirement
User Involvement Only at the High Only at beginning Yes(Intermed High No
in all phase beginning iate)
Risk Analysis Only at the No Risk Low No Risk Yes Only at
beginning Analysis analysis beginning
Overlapping No Yes No No Yes No
Phases
Implementation Long Quick Quick Long Long Long
Time
Cost Low High Low Low Expensive Expensive
Incorporation of Difficult Easy Easy Easy Easy Difficult
Changes
Simplicity Simple Simple Simple Intermediate Intermediat Intermediate
e
Flexibility Rigid Little Flexible High Less Flexible Flexible Less Flexible
Advantages -Easy to explain -Reduced time -Changing -Produces -Estimates -Simple and
to the users. and costs, but requirements can be business become easy to use
-Structures this can be a accommodated. value early in more -Each phase
approach. disadvantage if -Progress can be the realistic as has specific
-Stages and the developer measured. development work deliverables.
activities are loses time in -Iteration time can lifecycle. progressed -Higher
well defined. developing the be short with use of -Better use of because chance of
-Helps to plan prototypes. powerful RAD tools. scarce important success over
and schedule -Improved and -Productivity with resources. issues are the waterfall
the project. increased user fewer people in a -Can discovered model.
-Verification at involvement. short time. accommodat earlier. - Verification
each stage -Reduced e some -Early and
ensures early development time. change involvemen validation of
detection of -Increases requests t of the product
errors/misunder reusability of between developers. in the early
standing. components. increments. -Manages stages
-Each phase has -More focus risks.
specific on customer
deliverables. value.
Disadvantages -Assumes that -Insufficient -Dependency on -Requires -High cost -Very
the analysis. User technically strong heavy and time to inflexible.
requirements of confusion of team members for documentati reach the -Adjusting
a system can be prototype and identifying business on. final scope is
frozen. finished requirements. -Follows a product. difficult and
-Very difficult to system. -Requires highly defined set -Needs expensive.
go back to any -Developer skilled developers. of process. special skills -No early
stage after it misunderstandi -High dependency -Defines to evaluate prototypes
finished. ng of user on modeling skills. increments the risks of the
-A little objectives. -Management based on and software are
flexibility and -Excessive complexity is more. function assumption produced.
adjusting scope development -Suitable for dependencie s. -Costly and
is difficult and time of the systems that are s. -Highly required
expensive. prototype. component based -Requires customized more time.
-Costly and - It is costly to and scalable. more limiting re-
required more implement the -Requires user customer usability.
time, in addition prototypes involvement involvement.
to the detailed throughout the life
plan. cycle.
Applications
MODEL DETAIL
Waterfall  Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Prototype  Software that involves too much of data processing and most of the functionality is internal with very
little user interface does not usually benefit from prototyping.
 Useful in development of systems having high level of user interactions such as online systems.

RAD  RAD should be used only when a system can be modularized to be delivered in an incremental
manner.
 It should be used if there is a high availability of designers for modeling.
 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 project and working prototypes are to be
presented to customer in small iterations of 2-3 months.
Incremental  Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested enhancements may
evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while working on the
project.
 Resources with needed skill sets are not available and are planned to be used on contract basis for
specific iterations.
 There are some high-risk features and goals which may change in the future.
Spiral  When there is a budget constraint and risk evaluation is important.
 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic priorities as the
requirements change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer feedback.
 Significant changes are expected in the product during the development cycle.
V-Model  Requirements are well defined, clearly documented and fixed.
 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 There are no ambiguous or undefined requirements.
 The project is short.