Lecturer # 3 Waterfall Model
Lecturer # 3 Waterfall Model
The classical waterfall model is the basic software development life cycle model. It is very
simple but idealistic. Earlier this model was very popular but nowadays it is not used. However,
it is very important because all the other software development life cycle models are based on the
classical waterfall model.
The waterfall model is a software development model used in the context of large, complex
projects, typically in the field of information technology. It is characterized by a structured,
sequential approach to project management and software development.
The waterfall model is useful in situations where the project requirements are well-defined and
the project goals are clear. It is often used for large-scale projects with long timelines, where
there is little room for error and the project stakeholders need to have a high level of confidence
in the outcome.
3. Quality Control: The waterfall model places a high emphasis on quality control and
testing at each phase of the project, to ensure that the final product meets the
requirements and expectations of the stakeholders.
4. Rigorous Planning: The waterfall model involves a rigorous planning process, where the
project scope, timelines, and deliverables are carefully defined and monitored throughout
the project lifecycle.
Overall, the waterfall model is used in situations where there is a need for a highly structured and
systematic approach to software development. It can be effective in ensuring that large, complex
projects are completed on time and within budget, with a high level of quality and customer
satisfaction.
1. Clarity and Simplicity: The linear form of the Waterfall Model offers a simple and
unambiguous foundation for project development.
2. Clearly Defined Phases: The Waterfall Model’s phases each have unique inputs and
outputs, guaranteeing a planned development with obvious checkpoints.
4. Stability in Requirements: Suitable for projects when the requirements are clear and
steady, reducing modifications as the project progresses.
6. Relevance for Small Projects: Economical for modest projects with simple
specifications and minimal complexity.
The Waterfall Model is a classical software development methodology that was first introduced
by Winston W. Royce in 1970. It is a linear and sequential approach to software development
that consists of several phases that must be completed in a specific order.
1. Requirements: The first phase involves gathering requirements from stakeholders and
analyzing them to understand the scope and objectives of the project.
2. Design: Once the requirements are understood, the design phase begins. This involves
creating a detailed design document that outlines the 3 software architecture, user interface, and
system components.
3. Development: The Development phase includes implementation involves coding the software
based on the design specifications. This phase also includes unit testing to ensure that each
component of the software is working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the
requirements and is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the production
environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance, which involves fixing
any issues that arise after the software has been deployed and ensuring that it continues to meet
the requirements over time.
The classical waterfall model divides the life cycle into a set of phases. This model considers that
one phase can be started after the completion of the previous phase. That is the output of one
phase will be the input to the next phase. Thus the development process can be considered as a
sequential flow in the waterfall. Here the phases do not overlap with each other. The different
sequential phases of the classical waterfall model are shown in the below figure.
Let us now learn about each of these phases in detail which include further phases.
1. Feasibility Study:
The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software. The feasibility study involves understanding the problem and
then determining the various possible strategies to solve the problem. These different identified
solutions are analyzed based on their benefits and drawbacks.
The best solution is chosen and all the other phases are carried out as per this solution strategy.
The requirement analysis and specification phase aims to understand the exact requirements of
the customer and document them properly. This phase consists of two different activities.
Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been omitted) and
inconsistencies (an inconsistent requirement is one in which some part of the requirement
contradicts some other part).
3. Design:
The goal of this phase is to convert the requirements acquired in the SRS into a format that can
be coded in a programming language. It includes high-level and detailed design as well as the
overall software architecture. A Software Design Document is used to document all of this effort
(SDD).
In the coding phase software design is translated into source code using any suitable
programming language. Thus each designed module is coded. The unit testing phase aims to
check whether each module is working properly or not.
Integration of different modules is undertaken soon after they have been coded and unit tested.
Integration of various modules is carried out incrementally over several steps. During each
integration step, previously planned modules are added to the partially integrated system and the
resultant system is tested. Finally, after all the modules have been successfully integrated and
tested, the full working system is obtained and system testing is carried out on this.
System testing consists of three different kinds of testing activities as described below.
Alpha testing: Alpha testing is the system testing performed by the development team.
Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
Acceptance testing: After the software has been delivered, the customer performs
acceptance testing to determine whether to accept the delivered software or reject it.
6. Maintenance:
Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop full software. There are three types of
maintenance.
Corrective Maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
The classical waterfall model is an idealistic model for software development. It is very simple,
so it can be considered the basis for other software development life cycle models. Below are
some of the major advantages of this SDLC model.
Easy to Understand: The Classical Waterfall Model is very simple and easy to
understand.
Individual Processing: Phases in the Classical Waterfall model are processed one at a
time.
Properly Defined: In the classical waterfall model, each stage in the model is clearly
defined.
Clear Milestones: The classical Waterfall model has very clear and well-understood
milestones.
Properly Documented: Processes, actions, and results are very well documented.
Reinforces Good Habits: The Classical Waterfall Model reinforces good habits like
define-before-design and design-before-code.
Working: Classical Waterfall Model works well for smaller projects and projects where
requirements are well understood.
The Classical Waterfall Model suffers from various shortcomings we can’t use it in real projects,
but we use other software development lifecycle models which are based on the classical
waterfall model. Below are some major drawbacks of this model.
No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.
Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
the customer’s requirements keep on changing with time. It is difficult to accommodate
any change requests after the requirements specification phase is complete.
No Overlapping of Phases: This model recommends that a new phase can start only
after the completion of the previous phase. But in real projects, this can’t be maintained.
To increase efficiency and reduce cost, phases may overlap.
Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make changes
or go back to a previous phase.
Late Defect Detection: In the Waterfall Model, testing is typically done toward the end
of the development process. This means that defects may not be discovered until late in
the development process, which can be expensive and time-consuming to fix.
Lengthy Development Cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex
projects, as the linear and sequential nature of the model can make it difficult to manage
multiple dependencies and interrelated components.
Here are some cases where the use of the Waterfall Model is best suited:
Small to Medium-Sized Projects: Ideal for more manageable projects with a clear
development path and little complexity.
Predictable: Projects that are predictable, low-risk, and able to be addressed early in the
development life cycle are those that have known controllable risks.
Regulatory Compliance is Critical: Circumstances in which paperwork is of utmost
importance and stringent regulatory compliance is required.
Client Prefers a Linear and Sequential Approach: This situation describes the client’s
preference for a linear and sequential approach to project development.
Limited Resources: Projects with limited resources can benefit from a set-up strategy,
which enables targeted resource allocation.
The Waterfall approach involves little client engagement in the product development process.
The product can only be shown to end consumers when it is ready.
Large-scale Software Development Projects: The Waterfall Model is often used for
large-scale software development projects, where a structured and sequential approach
is necessary to ensure that the project is completed on time and within budget.
Government and Defense Projects: The Waterfall Model is also commonly used in
government and defense projects, where a rigorous and structured approach is necessary
to ensure that the project meets all requirements and is delivered on time.
Projects with well-defined Requirements: The Waterfall Model is best suited for
projects with well-defined requirements, as the sequential nature of the model requires a
clear understanding of the project objectives and scope.
Projects with Stable Requirements: The Waterfall Model is also well-suited for
projects with stable requirements, as the linear nature of the model does not allow for
changes to be made once a phase has been completed.
Conclusion
The Waterfall Model has greatly influenced conventional software development processes. This
methodical, sequential technique provides an easily understood and applied structured
framework. Project teams have a clear roadmap due to the model’s methodical evolution through
the phases of requirements, design, implementation, testing, deployment, and maintenance.