Waterfall model: Brief overview

- [Instructor] The Waterfall approach appears most intuitive to us at the first sight. You gather requirements for a project. Once the requirements are complete, you complete the design. When the design in complete, you write code and complete development and so on. The Waterfall model owes it's origin to manufacturing. When we think of manufacturing industry, we often think about a production plant that produces identical products in a consistent manner. All planning is done up front with detailed planning documentation and the scope of work is generally fixed. The process of manufacturing products is largely automated and includes well-defined checklists, processes, and tools. The general pattern here is that the output of a phase becomes input of the next phase. If you introduce an error in one phase, that error will propagate to all other phases. For example, if you have incorrect or incomplete requirements, those requirements will lead to incorrect design and that design will make it to an incorrectly developed or missing software feature. Many traditional Waterfall projects have fixed scope because you tend to freeze the scope of one phase before starting the next. Processes and final product are generally very well documented in a Waterfall project. This is how the Waterfall lifecycle looks like. You start with what is called Requirement Analysis phase where you capture requirements. This is followed by Analysis and Design phase where you produce high level design and test specifications. This is followed by the Development phase where you build the software system. The next phase is the Test phase where you match the output of the system with the expected outputs defined in the test specifications. And the last phase in the Waterfall model is the Deployment and Maintenance phase where the application is deployed to production and ongoing maintenance continues. In each phase, the output of the previous phase is the input to the next. The input to Analysis and Design phase is the output of the Requirements phase. So, what's wrong with the Waterfall model? The first problem is that the customer does not get to see the product before the early testing phase which is usually two thirds the way through the product time line. You could be in the Deployment and Maintenance phase when you could realize that the product you are building was no longer viable due to change in market conditions, or organizational direction, or changed computer landscape. Or you could realize that the product had a major architectural flaw that prevented it from being deployed. In other words, your product development initiative could completely fail after a lot of money and time had been spent on it. In software development, everything changes. Requirements, skills, people, environment, business rules, et cetera. As time progresses, you learn better techniques of doing things. Your stakeholders need to change requirements to match changing organizational strategy or changing market conditions. In other words, the only guaranteed thing is change and the shown process to refine our work. Software development is inherently an iterative process and does not work like a Waterfall cycle. Over emphasis on checklists and controls does not help because software development is human centric and is heavily dependent on judgment and creativity. Software is not a product designed to be built by assembly lines.