What are the different stages in the Waterfall Model approach to the Software Development Life Cycle?

Hello everyone. Welcome back to the session. So today in this session we are going to discuss the waterfall model. So let’s go ahead and start with the session. Alright guys, so what is the waterfall model exactly?

Why the waterfall model is called the waterfall model?

So a waterfall model is called a waterfall model because these are the stages of a waterfall model. Right. The first stage is completed successfully and only then you move on to the second stage. Right.

The second stage would be completed successfully, only then you move on to the third stage and there’s no going back. Right.

If you come into the design phase, you cannot go back to the analysis phase again. So each stage has to be completed perfectly and only then you move on. And that’s why it’s called a waterfall model.

The reason is that it follows a linear model of following the stages and you cannot go back. It’s unidirectional, it only goes in one flow, and it cannot come back. Right.

So this was a methodology that was followed in the earlier days in the starting stage of the waterfall model. And waterfall model was basically among the first models which was used to implement the software development lifecycle. So now we understand why the waterfall model is called the waterfall model.

Different stages in the Waterfall Model

Feasibility Checks

Now let’s go ahead and look at the stages of the waterfall model. Right. The first stage is the feasibility check. Now, what is a feasibility check? If you remember, in the software development lifecycle we saw that the first stage was requirements. Correct.

So what happens in a feasibility check is the customer comes in and the architect sits together. The customer tells the architect his requirements and the architect negotiates the requirements with the customer. Now, of course, not every requirement cannot be converted into a software feature.

The reason being it could be because probably of a technology limitation or it could be because of the investments. The kind of investment that we are putting in the project, says a feature, could take probably one more year to complete.

And the investment that the customer is looking out for is that he needs the software out in a year or six months. Right. So therein the architect says that this feature is possible, but this would not be and basically negotiates the requirements and then comes down to a list of requirements that would be possible. And this is all done in the feasibility check.

Analysis Phase

Then we move on to the analysis phase. Now in the analysis phase, what happens is that the architect has the list of requirements that the customer is given which he has negotiated with him, and these are the requirements that now have to be converted.

Now he will look out for ways to architect this particular application. Now, there could be a lot of ways in which you can architect an application. You have a lot of architectures that you can implement, but the architect has to come up with the best architecture that he can follow, and that is done in the analysis space.

He might have to come up with how many functions I need in my program. How many classes should I define for my program? So on and so forth. So all of that analysis is in the research and development done in the analysis phase

Design Phase

And then comes the design phase, wherein he says, okay, so these are the things that I’m going to do. Let me document it inside a particular document, or let me document this inside a specification document, which will be forwarded to a developer to follow, right? So he specifies everything clearly in the documents, and then these documents are forwarded to the developer.

Coding and Unit Testing

Now, the developer would start coding the requirements or the specifications which have been specified by the architect.

They follow the exact architecture, the exact number of functions, and the exact number of classes that the architect has specified, and they code up the project. And each developer, of course, would be doing his bit of the project.

The project would be divided between, say, 100 developers, right? So each developer would be doing his bit. Each developer would be creating his bit of the software.

And then because each component of software is being developed separately, it makes sense to test it separately as well, to see whether that component is functioning as desirable, right?

So when you check one specific component of software, it is called unit testing, right? So coding and unit testing means that you code up a particular software component and then you do the testing on that particular. So that is coding and unit testing. So this is done in this stage.

Integration and System Testing

Once this stage is over, once all the components of the software come in, then comes the integration test phase, wherein all the software is combined and it is now a complete product, which should reflect all the requirements that were specified by the customer.

Right? Now, these requirements are checked against the software in the system testing phase, wherein a system is made up of components of software that were developed by different people.

So now when we have to combine them, it becomes a system. So system testing is done on this whole software suit, and then you see if it’s functioning according to the requirements that were given by the customer, and then you come to the maintenance phase.

Maintenance of Software

As we have discussed before, you have pushed the finished product customer, but now you have to also maintain the software. There could be bug fixes, there could be security patches, and all of them that is done in the maintenance of software.

So basically all these stages are first finished and then we reach here and this goes on. As your time progresses, you frequently release bug fixes, your frequent release patches and the maintenance of software never ends, right?

I mean, it will never end till the customer shuts down the project or tries to pull out of the project. But the maintenance of software goes on. And this is followed sequentially. All these steps are followed sequentially.

Advantages and Disadvantages of Waterfall Model

There are advantages and there are disadvantages to following this approach. Let’s first discuss the advantages.

Advantages of the Waterfall Model

Now when we have clear specifications of a particular project, there are clearly defined objectives that a developer has to do. So there’s no ambiguity as to do we have to add a new feature or does it has to be revised.

Again, I think this is not right. So the room for all these discussions is not there. There are clear objectives that are specified for every developer. There are specific deadlines.

You have thought of everything because you have a set of functions that you have to establish. There are specific deadlines as to when a particular component or project should be finished, right?

Then there are no ambiguous requirements. So like I said, everything is fixed by the architect. There is no room for discussion. So there are no ambiguous requirements.

Everything is clear for everyone. There are well-understood milestones. We exactly know that at three months where our project is going to be, we know where at six months where our project is going to be, we know at which stage how many features are going to be developed.

So there are well-understood milestones. The process and results are well documented now because so much thought and so much effort into documenting everything has gone into it by the architect and by the developers when they are defining every component, everything is well documented, and everything is written.

So it comes out as if there is a fault in any of the software components. It can be easily traced through the documentation. Right? Now there are disadvantages to this as well.

Disadvantages of the Waterfall Model

The working product is available only after the last stage, that is, only after the system integration. You get the product, and then there’s only when you can test the product out fully.

Right now, in the waterfall model guys, a product can take up to six months or a year to complete at the minimum, right? If it’s a full-grown project, it might take six months or one year and six months.

And one year, guys, is a lot of time, right? If you think about it if I am a customer and I give my requirements to a software company today, and if they’re delivering the product after one year and in between, they are not having any communication with me and they are not taking any more requirements for me, my requirements will change after one year, right?

And it could be that I need some more features by the end of the year. When they’re developing, they’re giving me the finished product, I might need some more features, but now those features will again take some more time to come to me.

Also, there could be requirements that are no longer needed, right? There could be some features that no longer require. This happened when the waterfall model was followed and when projects of this scale were being developed.

By the end of the lifecycle, when the product was delivered to the customer, the value of that product diminished for the customer reason being the requirement was no longer there after six months or a year of giving the requirements to the company, right?

So the working product was not available until the lifecycle ended. The poor model. It was a poor model for large and complex projects. Now, the reason being, if it’s say medium-scale project, it took six months or a year, as I said.

But if there are more complexities in the projects, there are more components in the project. It might also take up to two or three years to complete a particular project, right?

And if a project takes this much time to complete, like I said, it diminishes the value to the customer when we are delivering the product. The reason is that his requirements definitely would have changed when as time has passed, that is two or three years.

And because in the waterfall model, you could not go back to the previous stage. Even if after six months, if the customer’s requirement changed and he approached the company at that time, the company would say, right now we cannot implement it.

Let us give you the software that you asked for before and after that, probably we can accommodate these requirements in the maintenance phase.

Right? So because of. This rigidity in the model, Was not suitable for large and complex projects. I said my previous point only stated that you cannot accommodate changing requirements and there was a high risk and uncertainty.

High risk because like I said, if the product is being delivered after one year, it could be that the product is of no use to the customer for whom it was supposed to be. And there is uncertainty as to whether a customer will like the pertinacity of a product or not. So these are the disadvantages.

The bottom line

In the fast-paced world of software development, the Waterfall Model stands out as a reliable option for projects that have clearly defined requirements. Its organized methodology brings clarity and accountability to the development process.

The rigid and linear structure of the cascade Model is what makes it so distinctive; advancement is perceived as descending gradually through various phases, much like a cascade. It is challenging to go back and make adjustments without hurting the process as a whole once a step is finished.