Hello folks, today in this topic we will cover all the concepts and the methodology related to the software development life cycle (SDLC). In our day-to-day life, without knowing the patterns of lifestyle. We follow thousands of lifecycle programs from initial to final levels. As part of our lifeline journey, usually, we take so many processes or phases for software development. In the favor of the software development process, we cross from simultaneously different paths like planning, analysis, designing, implementation, testing, acceptance, and maintenance. Now, we know these seven steps involved in SDLC. Now, we play around with these steps a bit. The professions around the world experimented by tweaking these life cycles a bit here a bit there. They change the order of these steps the frequency of these steps. The duration of each of these steps and guess what the results will be amazing. So, what are the proven and improved methods available in the market? Today, that is up for grabs by the IT industry. Among several methods available, the most popular ones are waterfall, agile, and DevOps and these are the three methodologies that we will be focusing on in today’s article.
Waterfall method
Waterfall methodologies, this is pretty much similar to the SDLC diagram. We have mentioned above. The waterfall model was built in one step at a time that is the project team that religiously follows. Each step and the order of execution and only when a step is thoroughly completed that they would go on to the next step here a thorough approach was followed which made this methodology sequential in nature that would mean a project team would start with requirement analysis, which was nothing but the planning phase of an SDLC. After the requirement analysis is done. The scope is determined by what needs to be built is decided it enters into the design phase. From the designing phase only when design the technical document is completed goes into the implementation phase. So, in forwarding the developers complete the entire design implementation and when they are ready it goes into the testing. So, the testers sit individually and test the whole application that was developed, and only when they become satisfied so, it goes into the maintenance phase. So, here we can see a sequential approach being followed in waterfall methodology.
Agile method
In this approach, you can see we have multiple cycles which are kind similar to the steps in the SDLC life cycle and each cycle is doing the same steps again and again. It is agile where they do not believe in developing a software sequential. That is why we saw for waterfall model, but they feel developing small portions of the application through several iterations. When with more frequent demos to the stakeholder, they are better chances of building high-quality software. So, in a typical agile world, a business analyst and a stakeholder identify one or more features that are required for the application as part of the discovery step. Then this feature is designed alone by the technical teams and developed and then tested this power portion. That is a discovery design development and the test is a life cycle followed in an agile environment which is in nutshell similar to the basic SDLC what they have customized it to their convenience this feature that is developed is then showcased to the stakeholders for their approval if they like what you built you enter into the next cycle. The next cycle is not essential but pretty much a similar one. But this time you are exploring another new feature. So, in every cycle, you are incrementally building small chunks of the software and at every stage, you’re validating the correctness of the software built from the stakeholders. Thus, minimizing the chances of going false.
Let’s see the comparison waterfall and agile methodology with a very childish example. If you take a project, to build a website say a search engine. One number team builds the search engine using the waterfall model going back to the above part and following the steps as it is. You can also see them for the building search engine. After the team would follow requirement analysis then they would sit and design they would implement it. They would test it in all of these phases. They are going back over the stakeholders to validate what they’re doing is right or not. They are focusing on the delivery and on the requirements. They have received at the tail end of the waterfall and the testing phase finally when they deliver the product. Maybe it’s a surprise or maybe it’s a shock for the client. We never know. If you say this was developed by a 19-year-old girl for her client. Everything is happy-go-lucky, she thinks the search engine would look really pretty if we had some pink and purple on it and maybe some balloons and butterflies on it, but the clients may not approve of that. But what do you see in the waterfall model Louis? The client feedback was not taken until all of this lifecycle was finished which could have taken say 6 months, 7 months, or maybe a year so yearlong hard work is wasted because a client didn’t approve of it. Now, let’s go and take the example of agile methodology the same project was given to an agile team would go and just pick one feature from this entire search engine. For example, let’s take B, they took the design of the U ice cream first in the first cycle. They are building the UI the same 19 year old happy go lucky decided to put purples, and pinks, and balloons and butterflies. But at the end of the cycle. This was a demo to the customer and the customer gets a shock right at the beginning and they say oh no. this is not what I want. But what is wasted here is just one cycle, what is wasted is the team’s effort spent in that one single cycle? Which is not more than two weeks three weeks or maybe four weeks compared to the one-year lifecycle that was wasted in a waterfall methodology. So, here the client could give them immediate feedback that you don’t want such bright colors. You prefer something more light and subtle. This feedback is collected by the team members and they go into the next cycle. And in the next cycle, they involve this client feedback. This is the strength of agile methodology over the waterfall cycle.
DevOps methods
Now, let’s move on to a hybrid of this agile methodology, which is called DevOps. Usually the project’s themes, they build a set of features, and when they see that an ideal quality amount of software is ready for deployment. That is when they go to the production and release the software for use. It’s not that at the end of every sprint in the agile cycle a software gets released so, it’s only after a couple of sprints when an ideal size of project is ready that we deliver but DevOps does not believe in that because they believe in time to market. This is the approach that does not believe in waiting for the end product to be ready to be deployed. So, if you may also see the DevOps diagram here. It’s again very similar to the basic SDLC or the agile methodology where there is planning involved coding testing building? But what happens at the end of testing, they immediately decide to package the software whole process and release it into the environment. And start operating and monitoring. This is usually seen in a very competitive environment. For example, there are tableau or power bi, these are the two reporting tools available. They are always in the competition on who delivers or who brings in the next feature into the market first so, they have no time to waste and wait. DevOps is similar to agile except for the difference being they release at the end of every cycle through a strategy called continuous integration and delivery so, in a nutshell after learning about all methodology, agile methodology, and DevOps. You could see here that we are not trying to prove one methodology is better than the other or the other one is lesser than the other because that is not the criteria of comparison here it all. All these methodologies are useful based on what industry you are building the software for what is the behavior of your application? Etc. In the agile methodology, you can see there is a huge picture of what the end application should look like. But it is not a definitive huge picture, it is kind of experimenting, rethinking, refactoring, and continuously improving as the team goes through each cycle of the agile. Because in the agile world, the importance is given more to flexibility than the stakeholders. So, this way of concept is suitable for any software that does not pose any risk to life. If you ok to experiment but you cannot or rather may not use agile for a highly sensitive medical tool for example that can pose a risk to human life. Those gems built has to be built after thorough analysis research and understanding of each of the feature. So, here thoroughness at each stage is very important so, in such industries, waterfall methodology would be a better fit than agile having said that this proves that what methodology you choose for your software development is based on the nature of the application being built and on the convenience of the team involved in it. Hope you would find this article informative or interesting.