Presented by:

Aftab Rafique
CMS 28874

Waterfall Model (Elicit and Traditional)

SSGC

M.Phil Research Thesis

Presented to Dr.Naveed Ikram
A Simulation Model for the Waterfall Software Development Life Cycle
(By Youssef Bassil from Lebanese Association for Computational Sciences Beirut, Lebanon)

Problem Solution Proposal

• Significant budget overruns
• Late or suspended deliveries
• Dissatisfied clients
• Project directors are not wisely
assigning the required number of
workers and resources on the
various activities of the SDLC
• This paper proposes a simulation
model for the Waterfall
development process using the
Simphony.NET simulation tool
• Will play role to assist project
managers in determining how to
achieve the maximum productivity
with the minimum number of
expenses, workers, and hours.
 New Idea In Waterfall Model For Real Time Software Development
(By Unnati A. Patel Niky K. Jain.b , ISTAR, Vallabh Vidya Nagar, Gujrat India)

Problem Solution Proposal

• Difficult to survive with change
• Defects are detected too late in the
software development process.
• Another problem is related to
prototype i.e. user can only view the
proposed system after testing
• Modifications to the model, which
correct most of the problems
• Proposed modification can allow
changing the client requirement at
any stage. after each stage there is a
review by user.
• User can view the system model
before development of the actual
system & after each stage, it saves
the cost and time both.
Analysis of the waterfall model for the software development process and
possibilities for its improvement
( By Oleksandr Redkyn Ryerson University Canada)

Problem Solution Proposal

• Unstable - since client requirements have
to be fixed before the development
process begins.
• Impossible to test at early stages -
problems appear only during the system
testing.
• Prone to under capacity - since system
performance cannot be tested until the
system coding is finished.
• Too expensive - since requirement
inconsistencies and missing components
are discovered during design and coding
phases
• Requirements are fixed but they are not
general and consist of the answer to one
question: "What system has to do?"
• All the decision power should be given to
developers, not to customers.
• Developers go through Concept and
Requirement
• Analysis stages. At the Architectural Design
they stop and go back to customers.
However, customers may not change their
answer to the question "What the system
should do?
 The Waterfall Model in Large-Scale Development
(Kai Petersen, Claes Wohlin and Dejan Baca Blekinge Institute of Technology Ronneby, Sweden)

Problem Solution Proposal

• Model does not cope well with change • Model is not suitable for large scale
• Generates a lot of rework development. With the same reason
• Confusion on implementations of version Company shifted to agile modelling in
of the requirements. 2005.
• High effort for maintenance.
• Specialized competence focus and lack of
confidence of people.
• Problems in fault localization due to
communication barriers
The Demise of the Waterfall Model Is Imminent” and Other Urban Myths
( By Phillip A. Laplante and Colin J. Neill, Penn State University )

Problem Solution Proposal

• In software development, change is • Prototyping as a feedback and discovery
unavoidable and must therefore be mechanism so that initial
explicitly accommodated in the life cycle. misunderstandings and omissions could be
• The more we understand something, the identified early.
more we realize the flaws in our initial • Subsequent process models attempted to
assumptions and conceptions. further mitigate such risks by breaking
• If we cannot readily adapt our solutions to down projects into a series of “mini-
these changes, the costs of Waterfalls” and iterating over the tasks
accommodating such requirements • Delivering increments of the entire system
“errors” escalate exponentially. in a sequence of releases
Software Engineering Methodologies: A Review of the Waterfall Model and
Object Oriented Approach
(Adetokunbo A.A. Adenowo, Basirat A. Adenowo)

Problem Solution Proposal

• Inability to evaluate the outcome of one • Waterfall not to be used when compared
stage before moving on to the next with OOA
(intermittent evaluation) • OOA being more efficient and effective,
• Inability to go back to any step to make facilitating better user satisfaction of
changes in the system. information systems than the waterfall.
• Sometimes, the client is not very clear of • OOA thus tends to have an edge over
what he exactly wants from the software, traditional waterfall model.
so mentioning any changes in between
may cause a lot of confusion.
• The entire process is sequential and there
is no opportunity to revisit the previous
phase
 Gist of Problems

Business Technical Miscellaneous

1. More costly 1. People blindly follow 1. You’ll never know what

2. Minimum ROI plans stage you really are on.
3. Can lack behind from 2. End-users do not know 2. High risk and uncertainty
competitors what they want. 3. Can not turn back
3. Testing for quality may
suffer.
4. Sequential process and
changes become costly in
terms of cost and effort
 Requirement Management
(Waterfall Model)

Version Control Change Control Requirement Status tracking Requirement Tracing

1. Necessary for 1. No unnecessary change is 1. Proposed 1. Maintain the

maintenance of record of made 2. In Progress traceability of all
any changes made due to 2. Record of all changes has 3. Drafted requirements from
which version has been been kept 4. Approved capabilities need via
changed 3. Ensures resources are 5. Implemented design and test
2. It allows you to revert used properly 6. Verified 2. Document all
selected files back to a 4. No disruption 7. Deferred changes to those
previous state, revert the 5. Reduces the chances of 8. Deleted requirements, and
entire project back to a unauthorized alterations, 9. Rejected 3. Record the rationale
previous state, compare disruption and errors in for those changes
changes over time the system.