Sad comparison between waterfall model and spiral model
Comparison Between Waterfall Model and Spiral Model
While developing a software, developers are often confused about the waterfall model vs spiral model.
It is because they are not able to decide, which of these models is better for the software they are
Software development on a broader level includes all the activities, between the manifestation of the
idea for the software to the maintenance of the said software. Sometimes, it may also be referred to
the actual task of writing the software code, and also maintaining it over a period of time. Over a
period of time, there are different software development models, that have been used for the said
purpose. The first of the software model to be used was the waterfall model. The other model, which
is commonly used is the spiral model. Both these models are among the most popular models in the
field of software development. The older of the two models is the waterfall model. There is often the
waterfall model vs spiral model debate, which can be heard in the corridors, when a new software
development process is undertaken. Understanding the difference between the two models will make
it easier to decide, which is the right model to be used for software development. However, it is
equally important to understand each of these models, which will help in better understanding of
difference between both of them.
The waterfall model is often also referred to as the linear and sequential model, for the flow of
activities in this model are rather linear and sequential as the name suggests. In this model, the
software development activities move to the next phase only after the activities in the current phase
are over. However, like is the case with a waterfall, one cannot return to the previous stage. The
phases of this model are:
Requirement Gathering and Analysis Phase
System Integration Phase
Testing and Debugging Phase
The most important advantage of the waterfall model lies in the fact, that there is minimum planning
overhead for the steps that are to follow, since the activities in each of the phase is carried out
upfront, it is feasible that one does not have to plan for the entire phase. There is certain amount of
discipline that is enforced as one has to only look into one phase of the process at any given point of
time. In other models it is often difficult to nail the start and end of the said phase, which is not the
case with the waterfall model. The most important of the advantage is that the project does not slip
on its schedule. The number of resources working on the project does not keep on increasing with
each passing day, as the planning for the same is done at the start of the phase itself.
As there are advantages of the waterfall model, there are also some disadvantages of the said model.
The first and the foremost disadvantage of this model is the inability of making changes to the system,
once the system requirements have been frozen. It is not uncommon to see the requirements
changing in the initial phases. In other words, one cannot go back to the previous stage. This is a
disadvantage, due to which this model was relegated to the back. The same happens to be the case
with the hardware and the software requirement for the software. If the software development
process extends for a longer period of time, there are chances that the hardware and the software
options chosen for the software may become obsolete at the end of the development process.
The spiral model was introduced, due to the shortcomings in the waterfall and prototype models of
software engineering. It is a combination of the said two models of software development. From the
name of the model, it can be derived that the activities of software development are carried out like a
spiral. To explain the model further, the entire software development process is broken down into
small projects. The phases of the spiral model are as follows:
Risk Analysis Phase
Coding and Implementation Phase
The disadvantage of the waterfall model is the advantage of the spiral model. It is a realistic model,
which is often used in the development of large software. There is a systematic approach used in the
spiral model, which is integrated into the iterative framework. This helps in ensuring there is no
problems in the software. Since changes to the software can be made at any point of time in the
software development process.
In the spiral model, it is important to have a member in the team, who is an expert at risk
assessment. Without correct risk assessment, there are chances that the software can utterly be a
failure. The client may have to spend a lot of time with the development team to fix the issues that
have cropped up in the software. This may at times become like a overhead for the both the client as
well as the software development company. This also leads to the over involvement of the customer in
the process of software development, which may cause the customer to ignore certain risks and cause
harm to the project.
Difference Between Waterfall Model and Spiral Model
While in the spiral model, the customer is made aware of all the happenings in the software
development, in the waterfall model the customer is not involved. This often leads to situations, where
the software is not developed according to the needs of the customer. In the spiral model, the
customer is involved in the software development process from the word go. This helps in ensuring
that the software meets the needs of the customer.
In the waterfall model, when the development process shifts to the next stage, there is no going back.
This often leads to roadblocks, especially during the coding phase. Many times it is seen that the
design of the software looks feasible on paper, however, in the implementation phase it may be
difficult to code for the same. However, in the spiral model, since there are different iterations, it is
rather easier to change the design and make the software feasible.
In the spiral model, one can revisit the different phases of software development, as many times as
one wants, during the entire development process. This also helps in back tracking, reversing or
revising the process. However, the same is not possible in the waterfall model, which allows no such
Often people have the waterfall model or spiral model confusion due to the fact, that the spiral model
seems to be a complex model. It can be attributed to the fact that there are many iterations, which go
into the model. At the same time, often there is no documentation involved in the spiral model, which
makes it difficult to keep a track of the entire process. On the other hand, the waterfall model has
sequential progression, along with clear documentation of the entire process. This ensures one has a
better hold over the entire process.
From the above discussion on spiral model vs waterfall model, it is clear that both the models have
their own advantages and shortcomings. While one is stuck between the waterfall model vs spiral
model debate, it is best to evaluate the software that is being developed and then decide the right
approach. The size of the project and the urgency of the software will have to be taken into
consideration for the same. At the same time, the resources available will have an important role to
play in the software development process.
The characters in the fable of the Tortoise and the Hare can easily be used to demonstrate the
similarities and differences between the Waterfall and Prototyping software development models.
This children fable is about a race between a consistently slow moving but steadfast turtle and an
extremely fast but unreliable rabbit.
After closely comparing each character’s attributes in correlation with both software development
models, a trend seems to appear in that the Waterfall closely resembles the Tortoise in that
Waterfall Model is typically a slow moving process that is broken up in to multiple sequential steps
that must be executed in a standard linear pattern. The Tortoise can be quoted several times in the
story saying “Slow and steady wins the race.” This is the perfect mantra for the Waterfall Model in
that this model is seen as a cumbersome and slow moving.
Waterfall Model Phases
Requirement Analysis & Definition
o This phase focuses on defining requirements for a project that is to be developed
and determining if the project is even feasible. Requirements are collected by
analyzing existing systems and functionality in correlation with the needs of the
business and the desires of the end users. The desired output for this phase is a list
of specific requirements from the business that are to be designed and
implemented in the subsequent steps. In addition this phase is used to determine if
any value will be gained by completing the project.
o This phase focuses primarily on the actual architectural design of a system, and how
it will interact within itself and with other existing applications. Projects at this level
should be viewed at a high level so that actual implementation details are decided in
the implementation phase. However major environmental decision like hardware
and platform decision are typically decided in this phase. Furthermore the basic goal
of this phase is to design an application at the system level in those classes,
interfaces, and interactions are defined. Additionally decisions about scalability,
distribution and reliability should also be considered for all decisions. The desired
output for this phase is a functional design document that states all of the
architectural decisions that have been made in regards to the project as well as a
diagrams like a sequence and class diagrams.
o This phase focuses primarily on the refining of the decisions found in the functional
design document. Classes and interfaces are further broken down in to logical
modules based on the interfaces and interactions previously indicated. The output
of this phase is a formal design document.
Implementation / Coding
o This phase focuses primarily on implementing the previously defined modules in to
units of code. These units are developed independently are intergraded as the
system is put together as part of a whole system.
Software Integration & Verification
o This phase primarily focuses on testing each of the units of code developed as well
as testing the system as a whole. There are basic types of testing at this phase and
they include: Unit Test and Integration Test. Unit Test are built to test the
functionality of a code unit to ensure that it preforms its desired task. Integration
testing test the system as a whole because it focuses on results of combining specific
units of code and validating it against expected results. The output of this phase is a
test plan that includes test with expected results and actual results.
o This phase primarily focuses on testing the system as a whole in regards to the list of
project requirements and desired operating environment.
Operation & Maintenance
o his phase primarily focuses on handing off the competed project over to the
customer so that they can verify that all of their requirements have been met based
on their original requirements. This phase will also validate the correctness of their
requirements and if any changed need to be made. In addition, any problems not
resolved in the previous phase will be handled in this section.
The Waterfall Model’s linear and sequential methodology does offer a project certain advantages
Advantages of the Waterfall Model
Simplistic to implement and execute for projects and/or company wide
Limited demand on resources
Large emphasis on documentation
Disadvantages of the Waterfall Model
Completed phases cannot be revisited regardless if issues arise within a project
Accurate requirement are never gather prior to the completion of the requirement phase
due to the lack of clarification in regards to client’s desires.
Small changes or errors that arise in applications may cause additional problems
The client cannot change any requirements once the requirements phase has been
completed leaving them no options for changes as they see their requirements changes as
the customers desires change.
Phases are cumbersome and slow moving
Conversely, the Hare shares similar traits with the prototyping software development model in that
ideas are rapidly converted to basic working examples and subsequent changes are made to quickly
align the project with customers desires as they are formulated and as software strays from the
The basic concept of prototyping is to eliminate the use of well-defined project requirements.
Projects are allowed to grow as the customer needs and request grow. Projects are initially
designed according to basic requirements and are refined as requirement become more refined.
This process allows customer to feel their way around the application to ensure that they are
developing exactly what they want in the application
This model also works well for determining the feasibility of certain approaches in regards to an
application. Prototypes allow for quickly developing examples of implementing specific functionality
based on certain techniques.
Advantages of Prototyping
May provide the proof of concept necessary to attract funding
Early visibility of the prototype gives users an idea of what the final system looks like
Encourages active participation among users and producer
Enables a higher output for user
Cost effective (Development costs reduced).
Increases system development speed
Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding
Helps to refine the potential risks associated with the delivery of the system being developed
Various aspects can be tested and quicker feedback can be gained from the user
Helps to deliver the product in quality easily
User interaction available during development cycle of prototype
Disadvantages of Prototyping
Producer might produce a system inadequate for overall organization needs
User can get too involved whereas the program can not be to a high standard
Structure of system can be damaged since many changes could be made
Producer might get too attached to it (might cause legal involvement)
Not suitable for large applications
Over long periods, can cause loss in consumer interest and subsequent cancellation due to a lack of
a market (for commercial products)
May slow the development process, if there are large number of end users to satisfy.
When companies trying to decide between the Waterfall model and Prototype model they need to
evaluate the benefits and disadvantages for both models. Typically smaller companies or projects
that have major time constraints typically head for more of a Prototype model approach because it
can reduce the time needed to complete the project because there is more of a focus on building a
project and less on defining requirements and scope prior to the start of a project. On the other
hand, Companies with well-defined requirements and time allowed to generate proper
documentation should steer towards more of a waterfall model because they are in a position to
obtain clarified requirements and have to design and optimal solution prior to the start of coding on
Characteristics and limitations of prototypes
Engineers and prototyping specialists seek to understand the limitations of prototypes to exactly simulate
the characteristics of their intended design. A degree of skill and experience is necessary to effectively
use prototyping as a design verification tool.
It is important to realize that by their very definition, prototypes will represent some compromise from the
final production design. Due to differences in materials, processes and design fidelity, it is possible that a
prototype may fail to perform acceptably whereas the production design may have been sound. A
counter-intuitive idea is that prototypes may actually perform acceptably whereas the production design
may be flawed since prototyping materials and processes may occasionally outperform their production
In general, it can be expected that individual prototype costs will be substantially greater than the final
production costs due to inefficiencies in materials and processes. Prototypes are also used to revise the
design for the purposes of reducing costs through optimization and refinement.
It is possible to use prototype testing to reduce the risk that a design may not perform acceptably,
however prototypes generally cannot eliminate all risk. There are pragmatic and practical limitations to the
ability of a prototype to match the intended final performance of the product and some allowances and
engineering judgement are often required before moving forward with a production design.
Building the full design is often expensive and can be time-consuming, especially when repeated several
times—building the full design, figuring out what the problems are and how to solve them, then building
another full design. As an alternative, "rapid-prototyping" or "rapid application development" techniques
are used for the initial prototypes, which implement part, but not all, of the complete design. This allows
designers and manufacturers to rapidly and inexpensively test the parts of the design that are most likely
to have problems, solve those problems, and then build the full design.