Lec_3

Disadvantages of Classical Waterfall

Model
• Doesn't support iteration, so changes can cause confusion
• Difficult to accommodate change requests
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program
doesn't occur until the final phase
• Problems can be somewhat alleviated in the model through the addition of
feedback loops (see the next slide)
2. Iterative Waterfall Model (Feedback)
The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.
Here, we provide feedback paths for error correction as & when detected
later in a phase. Though errors are inevitable, but it is desirable to detect
them in the same phase in which they occur. If so, this can reduce the effort
to correct the bug.
Phase Containment of Errors :
The principle of detecting errors as close to their points of commitment as
possible is known as Phase containment of errors.
Advantages of Iterative Waterfall Model
•Feedback Path –
In the classical waterfall model, there are no feedback paths, so there is no mechanism
for error correction. While in iterative waterfall model, the feedback path for different
phases allow error correction and these changes are reflected in the later phases.
•Simple –
Iterative waterfall model is more simple to understand and use. That’s why it is one of
the most widely used software development models.
•Cost-Effective –
Finding issues at an early stage of development enables to take corrective measures in a
limited budget.
•Well-organized –
In this model, less time is consumed on documenting and the team can spend more time
on development and designing.
Disadvantages of Iterative Waterfall Model
Limited Usage–
It is applicable only to large and bulky software development projects. This is because it is
hard to break a small software system into further small serviceable increments/modules.
Incremental delivery not supported –
In the iterative waterfall model, the software must completely developed and tested before
delivery. There is no scope for any intermediate delivery. So, customers have to wait a long
for getting the software.
Overlapping of phases not supported –
Iterative waterfall model also assumes that one phase can start after completion of the
previous phase.
Risk handling not supported –
Projects may suffer from various types of risks. But, the Iterative waterfall model has no
mechanism for risk handling.
Limited customer interactions –
Customer interaction occurs at the start of the project and at the time of software delivery.
These fewer interactions with the customers may lead to many problems as the finally
developed software may differ from actual requirements.
3. Incremental Model
First, a simple working system implementing only a few basic features is built and then
that is delivered to the customer. Then thereafter many successive iterations/ versions are
implemented and delivered to the customer until the desired system is released.
Description
• Also known as evolutionary model
• Used when requirements are well understood and addition of core feature is
desired
• Multiple independent deliveries are identified (Several Modules)
• Work flow is in a linear (i.e., sequential) fashion within an increment and is
staggered between increments
• Iterative in nature; focuses on an operational product with each increment
(not for long-term plan)
• Provides a needed set of functionality sooner while delivering optional
components later
• Each version of the software has more additional features than the previous
ones.
Phases of the Incremental Model:
Requirement Analysis:
The overall system requirements are gathered at the beginning.
Detailed analysis is performed for each increment at the start of every cycle, focusing on
the specific requirements for that phase.
Design:
The overall architecture of the system is designed first.
For each increment, specific designs are created for the functionality being added in
that cycle.
Implementation:
The system is developed incrementally. In each iteration, only a part of the functionality
is developed.
The code is built, tested, and integrated into the growing system.
Testing:
Each increment undergoes thorough testing to ensure that the new functionality works
as expected and does not break any existing system functions.
Regression testing is essential to check the system's stability.
Integration:
After an increment is fully tested, it is integrated with the previous increments to create a
more complete version of the software.
Delivery and Feedback:
The increment is deployed to the users for review.
Based on user feedback, necessary changes are incorporated into future increments.
Advantages of Incremental Model
• User gets a chance to partially developed system.
• Reduce the error because the core modules get tested thoroughly.
• Changes are easy to implement.
•Risk handling because of iterations.

Disadvantages of Incremental Model

• It is difficult to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented &
delivered.
4. Prototyping Model
Description
• Follows an evolutionary and iterative approach.
• Used when requirements are not well understood (Project is built using
several shortcuts with inaccurate and inefficient functions).
• Serves as a mechanism for identifying software requirements.
• Focuses on those aspects of the software that are visible to the
customer/user.
- A prototyping model can be used when technical solutions are
unclear to the development team. A developed prototype can help
engineers to critically examine the technical issues associated with the
product development.
• Feedback is used to refine the prototype.
Potential Problems
• The customer sees a "working version" of the software, wants to stop all
development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software
running quickly (e.g., language choice, user interface, operating system
choice, inefficient algorithms)
• Lesson learned
– Define the rules up front on the final disposition of the prototype
before it is built
– In most circumstances, plan to discard the prototype and engineer the
actual production software with a goal toward quality
5. Spiral Model
Description
• Follows an evolutionary approach.
• Used when requirements are not well understood and risks are high.
• Inner spirals focus on identifying software requirements and project risks;
may also incorporate prototyping.
• Outer spirals take on a classical waterfall approach after requirements
have been defined, but permit iterative growth of the software.
• Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations.
• Requires considerable expertise in risk assessment.
• Serves as a realistic model for large-scale software development.
Description
Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it looks like
a spiral with many loops. The exact number of loops of the spiral is unknown and can vary
from project to project. Each loop of the spiral is called a Phase of the software
development process. The exact number of phases needed to develop the product can be
varied by the project manager depending upon the project risks. As the project manager
dynamically determines the number of phases, so the project manager has an important
role to develop a product using the spiral model.
The Radius of the spiral at any point represents the expenses(cost) of the project so far,
and the angular dimension represents the progress made so far in the current phase.
Each phase of the Spiral Model is divided into four quadrants as shown in the above figure.
The functions of these four quadrants are discussed below
Objectives determination and identify alternative solutions: Requirements are gathered
from the customers and the objectives are identified, elaborated, and analyzed at the start
of every phase. Then alternative solutions possible for the phase are proposed in this
quadrant.
Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.
Develop next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.
Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the
so far developed version of the software. In the end, planning for the next phase is started.
Risk Handling in Spiral Model
A risk is any adverse situation that might affect the successful completion of a software
project. The most important feature of the spiral model is handling these unknown risks
after the project has started. Such risk resolutions are easier done by developing a
prototype. The spiral model supports coping up with risks by providing the scope to build
a prototype at every phase of the software development.
The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life project
risk may occur after the development work starts, in that case, we cannot use the
Prototyping Model. In each phase of the Spiral Model, the features of the product dated
and analyzed, and the risks at that point in time are identified and are resolved through
prototyping. Thus, this model is much more flexible compared to other SDLC models.
Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it sub-sumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative Waterfall
Model. The spiral model incorporates the stepwise approach of the Classical Waterfall
Model. The spiral model uses the approach of the Prototyping Model by building a
prototype at the start of each phase as a risk-handling technique. Also, the spiral model
can be considered as supporting the Evolutionary model – the iterations along the spiral
can be considered as evolutionary levels through which the complete system is built.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
1.Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.
2.Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
3.Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
4.Customer Satisfaction: Customer can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1.Complex: The Spiral Model is much more complex than other SDLC models.
2.Expensive: Spiral Model is not suitable for small projects as it is expensive.
3.Too much dependability on Risk Analysis: The successful completion of the project is very
much dependent on Risk Analysis. Without very highly experienced experts, it is going to be
a failure to develop a project using this model.
4.Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
General Weaknesses of Evolutionary Process Models
1) Prototyping poses a problem to project planning because of the
uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum speed
of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and
second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in late
delivery 23