2. Today’s focus is on
Classical Waterfall Model
Iterative Waterfall Model
Prototyping Model
1/29/202
3
3. Life Cycle Models
A software life cycle is a series of identifiable stages that a software product
undergoes during its lifetime.
In general terms, A process model specifies a general process, usually
- as a set of stages in which a project should be divided,
- the order in which the stages should be executed,
- and any other constraints and conditions on the execution of stages.
A life cycle model explains the different activities that needed to be carried out
to develop a software product and the sequencing of these activities.
Why use a life cycle model ?
The primary advantage of adhering to life cycle model is that it encourages
development of software in a systematic and disciplined manner.
3
4. Life Cycle Models
1. Classical Waterfall Model
2. Iterative Model
3. Prototyping Model
4. Spiral Model
5. Agile Process
4
5. 1/29/202
3
• Classical waterfall model is the basic SDLC model.
• This model divides the life cycle into a set of phases as shown in the
figure below.:
1. Classical Waterfall Model
6. The simplest process model is the waterfall model, It is very simple but
idealistic.
In this model, the phases are organized in a linear order.
The idea behind the phases is separation of tasks- each phase deals
with a distinct and separate set of tasks.
The large and complex task of building the software is broken into
smaller tasks from specifying requirements upto the maintenance of the
software.
Separating the tasks and focusing on a few tasks in a phase gives a
better handle to the engineers and managers in dealing with the
complexity of the problem.
6
1. Classical Waterfall Model
7. A project begins with feasibility analysis.
Upon successfully demonstrating the feasibility of a project,
requirements analysis and project planning begins.
The design starts after the requirements analysis is complete.
Coding begins after completion of design. Unit testing is done on
completion of each module.
On completion of coding, the unit tested modules are integrated and
integration testing is done; finally the whole system undergoes
system testing and acceptance testing.
After successful completion of testing, the system is installed.
After this, the operation and maintenance of the system takes
place.
7
1. Classical Waterfall Model
8. The requirements analysis phase is mentioned as “analysis
and planning.”
Planning is a critical activity in software development.
A good plan is based on the requirements of the system and
should be done before later phases begin.
To clearly identify the end of a phase and the beginning of the
next, some certification mechanism has to be employed at the end
of each phase.
This is done by some verification and validation means, that will
ensure that the output of a phase is consistent with its input.
8
1. Classical Waterfall Model
10. The outputs of the earlier phases are often called work products
and are usually in the form of documents like the requirements
document or design document.
For the coding phase, the output is the code.
The following documents generally produced in each project:
Requirements document
Project plan
Design documents (architecture, system, detailed)
Test plan and test reports
Final code
Software manuals (e.g., user, installation, etc.)
10
1. Classical Waterfall Model
11. Advantages
Classical waterfall model is a simple and idealistic model for software
development. So it can be considered as the basis for other software
development life cycle models. The major advantages of this SDLC
model is given below:
This model is very simple and is easy to understand.
Phases in this model are processed one at a time and each phase is
clearly defined.
This model has very clear and well understood milestones.
Process, actions and results are very well documented.
Reinforces good habits:
define-before- design, design-before-code.
This model works well for smaller projects and projects where
requirements are well understood.
11
1. Classical Waterfall Model
12. Disadvantages
Classical waterfall model suffers from various shortcomings, basically we
can’t use it in real projects, but we use other SDLC models which are
based on the classical waterfall model.
Below are some major drawbacks of this model:
No feedback path: In classical waterfall model evolution of a
software from one phase to another phase is like a waterfall. It
assumes that no error is ever committed by developers during any
phases. 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, so it is difficult
to accommodate any change requests after the requirements
specification phase is complete. But actually customer’s
requirements keep on changing with time.
No overlapping of phases: This model recommends that new
phase can start only after the completion of the previous phase.
But in real projects, this can’t be maintained. To be costeffective,
12
1. Classical Waterfall Model
13. Disadvantages
The requirements of a system can be frozen before the design
begins, which encourages “requirements bloating”. i.e - all
requirements must be specified at the start and only what is
specified will be delivered.
Determining the requirements is difficult as the user does not
even know their correct requirements in the initial stage .
Freezing the requirements usually requires choosing the
hardware (a part of the requirements specification). If the hardware
is selected early, the final software will use a hardware technology
on the limit of becoming outdated.
It follows the “big bang” approach - the entire software is delivered
in one shot at the end. This imposes heavy risks, as the user does
not know until the very end what they are getting.
It is a document-driven process that requires formal documents at
the end of each phase.
13
1. Classical Waterfall Model
14. 2. Iterative Waterfall Model
14
In a practical software development project, the classical
waterfall model is hard to use.
• Iterative waterfall model can be thought of as
incorporating the necessary changes to the classical
waterfall model to make it usable in practical software
development projects.
• The iterative model provides feedback paths from every
phase to its preceding phases(except feasibility analysis),
which is the main difference from the classical waterfall
model.
15. 2. Iterative Waterfall Model
15
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
Feedback paths introduced by the iterative waterfall model are
shown in the figure below.
16. 2. Iterative Waterfall Model
16
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
Advantages
Feedback Path: In the classical waterfall model, there are no
feedback paths, so there is no mechanism for error correction.
But in iterative waterfall model feedback path from one phase
to its preceding phase allows correcting the errors that are
committed and these changes are reflected in the later phases.
Simple: Iterative waterfall model is very simple to understand
and use. That’s why it is one of the most widely used software
development models.
17. 2. Iterative Waterfall Model
17
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
Disadvantages
Difficult to incorporate change requests: The major
drawback is that all the requirements must be clearly stated
before starting of the development phase. Customer may change
requirements after some time but the iterative waterfall model
does not leave any scope to incorporate change requests that are
made after development phase starts.
Incremental delivery not supported: In the iterative waterfall
model, the full software is completely developed and tested
before delivery to the customer. There is no scope for any
intermediate delivery. So, customers have to wait long for getting
the software.
Overlapping of phases not supported: Iterative waterfall
model assumes that one phase can start after completion of the
previous phase, But in real projects, phases may overlap to
reduce the effort and time needed to complete the project.
18. 2. Iterative Waterfall Model
18
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
Disadvantages
Risk handling not supported: Projects may suffer from various
types of risks. But, Iterative waterfall model has no mechanism for
risk handling.
Limited customer interactions: Customer interaction occurs at
the start of the project at the time of requirement gathering and at
project completion 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 the
customers’ actual requirements.
19. 3. Prototyping Model
The goal of a prototyping-based development process is to counter
the first limitation of the waterfall model.
In this, instead of freezing the requirements before design or coding,
a throwaway prototype is built to help understand the requirements.
A prototype is a toy implementation of the system.
This prototype is developed based on the currently known
requirements. Prototype starts when the preliminary version of the
requirements specification document has been released.
Development of the prototype undergoes design, coding, and
testing phases.
After the prototype has been developed, the end users and clients
are given an opportunity to use the prototype.
19
20. They provide feedback to the developers regarding the prototype:
what is correct, what needs to be modified, what is missing, what is
not needed, etc.
Based on the feedback, the prototype is modified, and the users
and the clients are again allowed to use the system.
This cycle repeats.
By using this prototype, the client can better understand the
requirements of the desired system.
This results in more stable requirements that change less
frequently.
20
3. Prototyping Model
23. 23
3. Prototyping Model
Advantages –
The customers get to see the partial product early in the life cycle.
This ensures a greater level of customer satisfaction and comfort.
New requirements can be easily accommodated as there is scope
for refinement.
Missing functionalities can be easily figured out.
Errors can be detected much earlier thereby saving a lot of effort
and cost, besides enhancing the quality of the software.
The developed prototype can be reused by the developer for more
complicated projects in the future.
Flexibility in design.
24. 24
3. Prototyping Model
Disadvantages –
Costly with respect to time as well as money.
There may be too much variation in requirements each time the
prototype is evaluated by the customer.
Poor Documentation due to continuously changing customer
requirements.
It is very difficult for the developers to accommodate all the changes
demanded by the customer.
25. 25
3. Prototyping Model
Disadvantages –
There is uncertainty in determining the number of iterations that
would be required before the prototype is finally accepted by the
customer.
After seeing an early prototype, the customers sometimes demand
the actual product to be delivered soon.
Developers in a hurry to build prototypes may end up with sub-
optimal solutions.
The customer might lose interest in the product if he/she is not
satisfied with the initial prototype.
