 In this video, I will talk about the so-called traditional waterfall model. The waterfall is a classic example of a linear sequential model. Like a real waterfall that fills a lower level pool before flowing further, each phase must be completed before starting another. The model is rarely used nowadays. But it is called a father of all models and it is necessary to understand the simple model before studying other models. The model was formally presented in the IEEE paper management the development of large system by Winston Royce. The idea of the article was to present an iterative model that relies on the prototyping and waterfall served as an example of a flawed non-working model. Two things facilitated the spread of a model. First, at that time there was a lack of easily understandable methodologies to govern software development. And second, the Department of Defense included the simplistic model from paper into standard. Soon, Department of Defense updated the recommendations, but the waterfall model already has gone viral. Each activity in the waterfall model should finish completely before starting another. In the beginning, the requirements are specified and the requirements specification document are provided for design phase. In the design phase, the architect creates the complete software system design. In a way, the architect creates a design for a building. Therefore, it relates to a big upfront design term. The created design is provided into implementation phase. The outcome is a software which is tested in verification phase. After the product is verified and accepted, it is deployed and the maintenance phase starts. Such a model is hard to use practically, therefore a slight modification is proposed for that model. The modification includes feedback loops. From one phase, one can return one phase. For example, if during a design phase it becomes apparent that some functional or non-functional requirements are not realistic, when these requirements are negotiated with the customer and updated. If during the implementation phase a design mistake comes up, then the software design is tweaked and implementation continues. In such a way, a design stays correct. There are several preconditions that need to be met so that the model could be implemented. The requirements should be now at the start of a project to do a big upfront design. The requirements should be stable to avoid changes in the latest stages. For that purpose, the software application domain must be well known. The technologies must be well understood to design everything upfront and avoid changes in later phases. These preconditions make it challenging to implement the waterfall model. Stil, some researchers and practitioners discussed that this model is good for a large system engineering projects, where a system is developed at several sites. In those circumstances the plan-driven nature of a waterfall model helps to coordinate the work. As mentioned before, it is hard to implement such a process model because of the real world conditions. First of all, the requirements should be entirely known before designing the system, which is possible only in rare cases, and only few business systems have stable requirements. For the requirements to be known, the software application domain must be well known for the developers. This can be true if developers are working for several years in the same domain. The technologies are normally evolving very fast. Therefore, the technologies that are well understood might be already outdated. Also, there is a criticism regarding customer involvement. Because of a waterfall nature, the workable software can be demonstrated only in the latest stages of development. There is a risk that critical issues might be noticed by the customer only in the latest stages. To conclude, the model is rarely used nowadays but is called a father of all models and it is necessary to understand this simple model before studying others. The waterfall is a classic example of a linear sequential model. Each phase must be finished before another starts. The model is mostly impractical. Domain technologies and requirements must be well known before the project starts. It is not flexible and lacks customer involvement. Some researchers and practitioners discuss that this model, at least partially, can be used for large system engineering projects, where a system is developed at several sites. In those circumstances, the plant-driven nature of the waterfall helps coordinate the work. Thank you for attention.