In this lesson, we are going to talk about one of the simplest model you can create by putting all this software development process together. It's called the waterfall method. So, in the waterfall method what we do is we put all of these software engineering processes one after the other in a logical sequence. You do all your requirements first, then you do all your design, then you do implementation testing, then your deployment and then it goes into maintenance or operations. Now, what if something goes wrong, or let's say you are doing the implementation and you found out that, this is not what we need? To fix that problem, you are not going to just continue going down the line, you're going to fix it. So, to fix that problem, we sometimes add this feedback loop from each of the phases to the previous phase, which means that if you find something wrong in the implementation phase, you will go back to the design phase if the problem was in the design phase, or you can go into the requirement phase if the problem was in the requirement phase. And then you can keep coming back. You fix something in the requirement then you come back in the design then you again continue your implementation. Now, one thing you will notice is that the later you find the problem, the more costly it's going to be. So, you may have heard of this cost of change curve, which basically is showing, the later you find the bug later in the stage, how costly it is. So if it is production, it's almost a hundred and fifty times costlier than if you find that earlier. So you want to find the problem early and so one of the key assumptions behind these models, is that we know the requirements very well and they won't change. We just talked about, if the requirements change later in the phase, how costly it will be to go back and then repeat our steps. And so for this model to be successful, we need to make sure that the requirements are solid because we want to make sure that all the other phases go smoothly. The second assumption we make in this model is that team has experience building similar software. Take an example, let's say the team is building a software for an ATM machine and they have never done this before. So they got the requirements, they started designing the software and since they have never done it, they made some design decisions that were not correct. But they will continue to build and then they will realize "we made that decision wrong". Of course they were not aware of it at that time, they haven't built this kind of software before so that's why the mistake was made. But the mistake was made and now they have to do some rework. So again, for this model to be successful, the team has to know what they are building so that they can design the software before they actually build it. And then the third assumption, is that the translation from the requirement to the product is going to be perfect, which means that the designers or the people who are coding understood the requirements really well. So in this case, when the designers or the architects are designing the system, did they really understand what the user wanted? If they understand it correctly, they will design the system correctly. If they didn't understand, the design will be incorrect and then it will be built incorrectly and then will be tested incorrectly and so on. It's really important for this model to be successful that everybody has a share or the correct understanding of what is being looked for. In terms of the predictive and adaptive scale, as you can see this model is pretty much a very predictive model because you don't start until your requirements are done, then your design and so the requirement has to be known very clearly upfront. What are the pros and cons of this model? Well if you think about the pros, it's a very simple and easy to understand model, pretty much anybody will be able to say this makes sense, it's very straightforward and logical. And the second is, if you have the requirements fixed then it's a very predictive model because in the very beginning you know what you need, then you can identify how long is it going to take. Once your design is ready, you know how long it's going to take to implement and so on. And then it also gives you predictability from point of view of how many sources you need and then you also have predictability of what I'm going to get. From a predictability point of view, this is a pretty good model. And then the last but not least, it's a very efficient process since you know all the requirements, you can consider all the aspects of the product and you can design it perfectly. And then during the coding, again since you know what you're building. In all the phases it becomes a very effective and efficient process and you don't have to do much of a rework. From that aspect, it's a very efficient process. In terms of the cons, this model is not very effective in terms of embracing change or not flexible for change. If you change anything, let's say I changed my mind, I want to instead of building this way, I want to build it this way. And if we identify that in the implementation phase, that's a very costly affair. It is not really efficient to make changes during the development phase. And then the product that you get in a waterfall method is just one shot big bang in the end, so you cannot take benefit off early release or getting value during the development process. When to use this software? Well if your, the project or the product that you're working on is very predictable and it's a repeatable work, then waterfall model will be a decent fit for this kind of work.
