Waterfall Methodology is a sequential (non-iterative) design process, used in software development processes. Progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance. Despite the development of new software development process models, the Waterfall method is still the dominant process model with over a third of software developers still using it.
The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Because no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
Plans .vs. Reality
One of the main arguments against the Waterfall approach to Project Management for software development, technology R&D and IT industry projects in general is that there are too many variables and unknowns in the real-world and that theoretical models quickly fall apart as estimates become wildly inaccurate based on small changes or deviations part way through the long project lifecycle.
In theory, phases flow downwards from one to the next smoothly down the "steps/levels" in the waterfall and no re-work or back-stepping is ever done, since we spent such large amounts of time upfront we were able to consider all possible business needs, variations, bugs and issues and thus we anticipated everything that could go wrong and charted a course which avoided it. Thus, while we may be inconvenienced slightly by having a much slower start-time in the Planning phases, we finish the whole project easily and within the time allotted thanks to reaching a form of business consensus amongst inter-dependent teams resulting in efficient yet comprehensive Design, Code which efficiently implements it thanks to its clarity and reliability in Production upon deployment.
In reality though, many unknowns arise through the course of executing the project and it is impossible to predict all variations, problems or issues before they occur. For instance, you budget a certain number of development "man hours" based on having 5 developers. What happens if one or more get sick, killed, or simply get burnt-out and go on stress leave in the process of implementing the project? What if the productivity is really low for 2 developers since they are new to the team, and the other 3 can't pick up enough slack to stay on course? What if the Design was despite all best efforts incomplete in some ways and development reaches a stand-still until it can be clarified, validated and approved by the business. As a result, even while sticking within Waterfall you may need a more flexible approach which can be adapted to many real-world projects. What you end up with is the "cyclical Waterfall" where you allow for deviations by over-budgeting the time required (adding in project management "buffers/contingencies") and allow stalled out work to return to earlier stages in the waterfall when needed, whilst simultaneously pushing ahead on non-stalled work as possible. The danger with this is that when we get stuck in a cycle of re-work your buffer/contingency time may still not be enough and the project will run over budget and/or deliver later than scheduled (if at all). To mitigate against that we can shorten the iterations, but an approach for doing so is needed.
Rational Unified Process (commonly abbreviated RUP) is essentially a type of "accelerated waterfall" described above, where the passengers in the boat traveling down the shorter steps of the waterfall can hop out and walk/climb back up to an earlier step and then grab a new vessel and travel down the remainder of steps as needed. RUP describes the processes by which that deviation becomes acceptable, and also provides some metrics to make sure the project is still staying on course overall, and that prioritization of tasks within the development team is understood and approved by the business side. It also gets closer to Agile methodologies by encouraging collaboration between those doing the Planning/Design work (Project Managers, Business Analysts, Data Analysts, etc) and those doing the Development work (Software Engineers, Developers, Programmers, etc); although does not typically go so far as having the technical team own or run the planning/design thus sometimes maintaining an organizational hierarchy between the "overseer's" and "do-er's". That said, it does encourage developers to push back on requirements when done so in the interest of improving overall project efficiency; for instance; to clarify, remove, or re-prioritize certain requirements.
RUP is a software development process from Rational, a division of IBM. It divides the development process into four distinct phases that each involve business modeling, analysis and design, implementation, testing, and deployment. The four phases are:
- Inception - The idea for the project is stated. The development team determines if the project is worth pursuing and what resources will be needed.
- Elaboration - The project's architecture and required resources are further evaluated. Developers consider possible applications of the software and costs associated with the development.
- Construction - The project is developed and completed. The software is designed, written, and tested.
- Transition - The software is released to the public. Final adjustments or updates are made based on feedback from end users.
The best practices for RUP teams are to:
- Develop software iteratively
- Manage requirements
- Use component-based architectures
- Visually model software
- Verify software quality
- Control changes to software
- Agile Modeling - RUP: http://www.agilemodeling.com/essays/agileModelingRUP.htm
- wikipedia: Rational Unified Process
Software Development LifeCycle (commonly abbreviated SDLC) is the splitting of software development work into distinct phases (or stages) containing activities with the intent of better planning and management. It is often considered a subset of the systems development life cycle. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
A variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One software development methodology framework is not necessarily suitable for use by all projects. Each of the available methodology frameworks are best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.
Methodologies, processes, and frameworks range from specific proscriptive steps that can be used directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a custom set of steps tailored to the needs of a specific project or group. In some cases a "sponsor" or "maintenance" organization distributes an official set of documents that describe the process.
- wikipedia: Software development life cycle (SDLC)
- wikipedia: Systems development life cycle
- How We Reduce Costs And Waste By Aligning Testing With The SDLC: http://www.optimation.co.nz/blog/how-we-reduce-costs-and-waste-by-aligning-testing-with-the-sdlc/
A comprehensive PDLC is even more involved than the SDLC in that it adds several additional phases of Planning, Budgeting, Reporting and additional Project Management tasks.
- SDLC - Waterfall Model: https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
- Waterfall Process (and how it necessitates "predictive planning" compared to Agile which necessitates "business value creation"): https://martinfowler.com/bliki/WaterfallProcess.html
- wikipedia: Waterfall model
- wikipedia: Chaos model
- wikipedia: Spiral model
- wikipedia: Data Analysis
- wikipedia: Business Analysis
- wikipedia: Object-oriented analysis and design (OOAD)
- wikipedia: Systems Analysis
- wikipedia: System context diagram
- wikipedia: Requirements elicitation
- wikipedia: Functional requirement
- wikipedia: Requirements analysis
- wikipedia: Requirements traceability Matrix (or RTM)
- Comparing Traditional Systems Analysis and Design with Agile Methodologies: http://www.umsl.edu/~hugheyd/is6840/waterfall.html
- Agile vs Waterfall -- Comparing project management methods: https://manifesto.co.uk/agile-vs-waterfall-comparing-project-management-methodologies/
- Agile vs. Waterfall - Is There a Real Winner?: http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/
- Agile & Waterfall Methodologies – A Side-By-Side Comparison: http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/
- Waterfall .vs. Agile Methodology: http://www.mccormickpcs.com/images/Waterfall_vs_Agile_Methodology.pdf
- The Risks Of Big-Bang Deployments And Techniques For Step-wise Deployment: https://dzone.com/articles/risks-big-bang-deployments-and
- The Agile Concurrent Software Process (contrasted to cyclical Waterfall approach): https://www.softprayog.in/software-engineering/agile-concurrent-software-process
- Rational Unified Process -- Best Practices for Software Development Teams: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
- Rational Unified Process -- A Best Practices Approach: http://www.eecg.toronto.edu/~jacobsen/courses/ece1770/slides/rup.pdf
- 21 CFR Part 11 and the SDLC: http://lexsheehan.blogspot.ca/2013/09/21-cfr-part-11-and-sdlc.html
- What is Software Development Lifecycle?: http://radugaapps.com/what-is-software-development-lifecycle