Software Development Life Cycle — The Ultimate Guide [2020]
Software Development Life Cycle — The Ultimate Guide [2020]
The software development life cycle is about producing high-quality software promptly.
The software development life cycle is about producing high-quality software promptly.
And your team needs to follow the software development life cycle steps to achieve that.
It’s also essential that your team adheres to the proper SDLC model.
This guide will be like the ultimate tutorial to SDLC.
We’ll start by “What’s the definition of SDLC” and then transition to the different phases of the software development life cycle and its models.
NOTE: You can check the infographic below if you are short on time. It’ll brief you on the different software development life cycle methodologies.
Without further ado:
Table of contents:
What is the Software Development Life Cycle process?
What are the 7 phases of the Software Development Life Cycle?
What are the advantages and disadvantages of SDLC?
What are the different SDLC Models?
The Waterfall Model
The V Model
The Iterative Model
The Spiral Model
The Agile Model
The Scrum Methodology
The XP Methodology
The Rad Model
The Software Prototype Model
The Big Bang Model
Which SDLC Model is the right for you?
What are SDLC Models other companies using?
What is the Software Development Life Cycle (SDLC)?
The term “Software Development Life Cycle” dates back to the 1950s.
At that time, there weren’t any other methods or frameworks available.
There was only one method described as the Software Development Life Cycle — “develop large-scale functional business systems in an age of large-scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines.”
Today, the definition of the software development life cycle is the following:
Build high-quality software in the least possible time by following the 7 phases of the software development life cycle.
Now, there are various SDLC methodologies, Waterfall being the oldest and most popular one dating back to the 1960s.
Each software development life cycle model differs from the others.
To pick the right one, you need to analyze your development processes thoroughly. You need to see if adhering to a rigid SDLC model or sticking to something more flexible is better for you. And I’ll help you with that.
But first…
What Are The 7 Stages Of The Software Development Life Cycle?
Planning — in this phase, you are conducting thorough research on the product you are planning to develop. You are then discussing your plans with clients and stakeholders.
You are also identifying the pros and cons of the current software methods you are using. Thus, you can double down on the pros and reduce the cons to a minimum.
In order to make this research process as accurate as possible, you should take a look at your customer’s feedback. Feedback should include surveys, interviews, questionnaires, quizzes, and more.
It’s super important to know what your customers want so that you can build it for them. In the end, you are not going to make a profit if you don’t deliver the product your customers truly desire.
But be careful! Sometimes, even your customers don’t know what they really want. As the great Henry Ford put it — “If I had asked people what they wanted, they would have said faster horses.” Therefore, try to understand the real meaning behind the words of your customers.
Requirements Analysis — Once research is completed you can proceed forward to creating an SRS (Software Requirements Specification) document. In this document, you are going to describe all the product’s features. Then you are going to present the SRS doc to the stakeholders so that they can either accept it or reject it. It depends on the time and financial constraints.
Design — Once the SRS doc is completed, your team, specifically the product architects, will create another document — the DDS (Design Document Specification).
In the DDS, you’ll have your features thoroughly described. Inside the document, you’ll also have the budget and time estimates required for the product to be completed successfully. You’ll basically have everything your developers need to start working on the actual product.
But prior to that, the DDS must be approved by the client and the stakeholders. Sometimes, changes are required due to various reasons ranging from time and budget estimates to software robustness.
Implementation / Development — The implementation phase in SDLC typically takes the longest period of time as it involves the actual development of the product.
Your developers will work on creating a product based on the DDS.
Also, depending on DDS’s robustness, developers will either code without much hassle or will have trouble along the way.
They must also select the most appropriate coding language for the type of software you are building.
It’s vital to notice that the communication between your team at this phase must be effective and accurate. That’s because your developers will need to communicate with the QA (quality assurance) testers, the product and project managers. This will help them in developing a product your customers will genuinely enjoy.
Since DevOps is becoming popular lately, developers are starting to broaden their coding skills. This makes them responsible for a large part of the entire software development life cycle process including the testing stage. Here’s a great article by Detectify on scaling up security with DevOps and CI/CD practices.
Testing — Once the product is developed, the software development life cycle testing phase follows. Here, the QA testers have to go through the codebase in order to find bugs and errors. If issues are reported, the product is turned back to the developers for them to rectify the flaws and roll it out again. This phase repeats until the product becomes flawless.
Deployment — Once all the errors are removed, the product is rolled out to the market automatically.
Maintenance and improvement — After deployment, you should observe how the market reacts to your product. Then based on the feedback you receive, you create reports on what needs to be improved.
“Do you need to upgrade the software version? Do you need to add more features? Do you need to make the interface simpler and more intuitive?” And so on.
Now that you know the software development life cycle steps, let’s see what the pros and cons of the SDLC are.
What Are The Advantages And Disadvantages Of The SDLC?
If the stages of the software development life cycle process are taken into serious consideration, chances are you’ll end up with an outstanding product. Your developers will create software that your users will happily talk about and recommend.
That’s because the programmers on your team will have comprehensive documentation to work with (DDS and SRS docs). They’ll also have the feedback of the product managers and stakeholders. Everybody will be on the same page. Thus, you’ll be able to develop a product that will outperform the competition in most cases.
However, if the end-user feedback isn’t conducted properly, don’t expect to get a big bang for your buck.
So make sure that your research process is done properly. If you are able to understand what your users really want, you can:
Save time and money.
Improve communication between your team members.
Make sure there’s transparency in the workplace, so everybody is on the same page. Give people tools to know who’s who, and who does what.
Enhance development speed.
Repeat the process over and over again with future projects.
Also, minimize the risk potential during any given development project.
And develop a high-quality product that your end-users truly love.
However, “by failing to plan, you are planning to fail” — as Benjamin Franklin put it. And your failed planning will result in:
Bad product and unsatisfied customers. Your customers might talk bad about your software, and thus no one will pay for it.
Bad team communication. It can result in utterly disorganized team management.
Overspending. If your product and features aren’t planned well, you’ll probably need to spend more allocated budget on fixing the bugs and issues that occur.
Missed deadlines. By spending more resources on fixing bugs and issues, you might also miss your deadlines which can leave your clients unhappy.
Yet, keep in mind that sometimes, having a lot of documents might leave your team perplexed as well.
Many documents can make the SDLC process cumbersome and slow it down.
So you’ll have to find the balance between a scarce document and a thorough one to enable your team to be as productive as possible.
What Are The Different SDLC Models?
Honestly, there are a lot of software development life cycle methodologies out there.
Based on the project’s needs and preferences, some SDLC methodologies will be better suited for you than others.
Today, we are going to stress on the 10 most popular SDLC methods. And we will also help you to pick the right one for your team. Here are they:
The Waterfall model.
The V model.
The Iterative model.
The Spiral model.
The Agile model.
The Scrum methodology.
The Extreme Programming methodology.
The Rad Model.
The Software Prototype model.
The Big Bang model.
The Waterfall Model
Being the oldest and most popular one, the Waterfall model deserves the first place on our list.
It dates back to the 1960s, and people are still using it today.
The name “Waterfall” stems from the sequential order in which tasks are completed. The output of the first assignment serves as the input for the second one (incremental approach). And this process is repeated until the whole product is completely developed.
What’s cool about the SDLC Waterfall model is that it’s relatively simple to use.
Backed up by a lot of planning and documentation, the Waterfall model allows you to map out every step of the development process.
Team communication is also super effective as there aren’t many hurdles along the way.
The SDLC Waterfall model follows the same 7 software development life cycle phases — planning, requirements, design, implementation, testing, deployment, and maintenance.
With the Waterfall method, there is typically a lot of planning involved as you need to come up with an exact image of the end product.
Developing an SRS and DDS document is pretty much the same. You design all the features that need to be developed, then thoroughly describe them, and present the docs to the stakeholders to get approved.
The implementation phase takes from 3 to 12 months, sometimes even more.
This is actually considered as a downside because the end-user isn’t able to see a working product until the late stages of development.
Think of Windows. They release a new version every couple of years. This means that they are using the Waterfall model.
After the product is developed, it must be tested. If bugs occur, they should be removed. And then you are ready for the deployment.
Once you deploy, you should observe how the market reacts to your product. Then make adjustments in order to improve the software and leave your end-users happy. Thus, you’ll get the word about your product spread easily.
The Waterfall model — Pros
The software development life cycle documentation is really on point here. Thorough planning will definitely set up your development team for success.
Easy to understand and use. Every step of the way is mapped out for your team members to comprehend and follow them. You can put novices on board and have them quickly grasp the idea behind the project and start producing quality code.
The Waterfall method is also quite easy to manage. You don’t have any external resources involved. You can clearly see what’s on the table and come up with the next essential step you need to take in order to move the project towards the goal line. The time your team spends on trivial tasks is minimized as there is a rigid prioritization of your tasks.
Deadlines can be met easily. That’s because you are provided with specific instructions so that you don’t spend time on figuring out everything yourself.
It’s best suited for bigger teams and projects as there is heavy documentation involved. And you probably don’t want to waste your time conducting thorough research on a product that will take you a month to develop.
All in all, with Waterfall, everything’s made to be simple and straightforward.
The Waterfall Model — Cons
The bad thing with the Waterfall methodology is that changes can be extremely costly or even impossible to make. That’s because each step must be completed sequentially. Therefore, if you’ve missed to note down a feature in your backlog, you’ll have a hard and expensive time of reverting the whole process.
Also, it takes a while for working software to appear. Your client will not be able to see the bang for his buck immediately. In most cases, it takes from eight to nine months to produce working software.
It’s also quite risky. If you have a precise budget and your team happens to develop a software that isn’t what the users want, then you are, merely said, screwed. To avoid being screwed, you’ll have to stress on making thorough customer research. That will help you to find out what your users desire. With Waterfall, you either plan well and create a great product, or you don’t plan well and create a product nobody wants.
Sometimes, even the customers don’t know what they want, which can lead you to create a product that nobody desires. You’ll have to dive deep when doing your user’s research and try to understand the real meaning behind the words of your end-users.
It’s not suitable for smaller teams and projects as you’ll waste too much time on researching for a project that might take you less than a month.
It’s also quite difficult to measure the progress your team is making as there is no working software delivered until late in the development cycle.
When To Use The Waterfall Model — Examples
We’ve already mentioned Windows and how they use the Waterfall model.
This methodology is based on long-term projects that can take you over a year, just like Windows 7, 8, 10, etc.
Otherwise, you might want to head to other SDLC models such as Agile, Scrum, and XP that will be discussed below.
The V Model
The SDLC V method is basically an improved version of the Waterfall model. You’re working at one phase at a time. And only when you finish a task, you can move on to the next one.
The name stems from the parallel V structure this model follows.
Software development life cycle testing is included in every stage — and that’s actually the main difference between this method and the Waterfall model.
The V methodology consists of 9 different SDLC phases — Requirement analysis, System design, Architecture design, Module design, Coding, Unit testing, Integration testing, System testing, and Acceptance testing.
It’s worth mentioning that there are two parts of the equation here — Verification (planning & building) and Validation (testing & improving).
The stages from the Requirement analysis to the Module design are located in the Verification stage. Whereas the stages from the Unit testing to the Acceptance testing are put in the Validation phase.
Only the Coding phase is neutral — it’s involved in both.
Let’s start with the…
Verification Stages
The Requirement analysis phase — this is actually the most important one. It’s where the communication between you and your end-users happens. It’s the time and place where you are trying to find out what the user really wants and how to give it to them.
The System design phase — You then create the requirements documentation alongside all the product expectations — budget, deadlines, features, robustness, etc. Once you have every feature and requirement mapped out, you can then create the entire system design of your product. It includes every tiny detail about the hardware and communication setup of your product. The System design basically gives you an overall picture of how your product will look like and what’s it going to do.
The Architecture design phase — Here, you are mapping out the technical approaches your team is going to take to build the product. Typically, there are a couple of technical methods. They are mostly based on financial feasibility. If everything makes sense, you are then breaking down the project into smaller tasks your team needs to follow.
The Module design phase — This is the stage where you should ensure internally that the design of the product is compatible with other modules as well as different external sources.
The Coding Phase
This is where the magic happens.
Your developers must keep regular communication between the product managers and the stakeholders. It will help them to develop an outstanding product.
The perfect coding language is selected by the developers based on the type of product you are building. The developers are constantly reviewing the code and making sure that everything is brought down to a science.
Validation Stages
The Unit Testing phase — in this stage, the code is being tested and optimized. All the bugs and errors that occur along the way are removed. The developers are working hard to ensure that they deliver a flawless code.
The Integration testing phase — We are testing the communication of the internal modules within the system to make sure that everything is well synchronized.
The System testing phase — Here, we are testing the communication of the external systems. This is actually the place where some hardware and software issues might be discovered and therefore fixed.
The Acceptance design phase — Here, you’ve already rolled out the product to the market and observed how it reacts to it. Based on the user feedback you receive, you decide whether to make further improvements or leave it that way.
The V Model — Pros
You have a lot of planning involved which makes grasping the whole process much easier.
You can meet all of your deadlines quite easily as there are specific instructions mapped out for your team. Thus, you can clearly see what’s ahead of you and form precise time and budget estimates.
The whole process is quite easy to manage as there aren’t many hurdles along the way. You are following a step-by-step process. You have to finish each task entirely before moving on to the next one. This keeps you focused at one assignment at a time.
It’s suitable for bigger teams and projects as you’ll have a clear image of how the end product will look like.
The V Model — Cons
Like the Waterfall model, you can’t make changes once a task is finished. This makes it a high-risk model. When planning to use the V method, you have to make sure you have a thorough understanding of the product. And you need every step of the development phase mapped out precisely. All of that ensures that risks are reduced.
Changing is either impossible or very costly. If you happen to miss something important during your planning process, you’ll have a hard time coping with the change.
Also, a lot of software development life cycle documentation can be overwhelming.
Not suitable for smaller projects as it will take you an enormous amount of time to plan the process and do the research.
Your end-users or clients aren’t able to see an actual product until the late stages of development, which typically take 8–9 months.
When To Use The V Model — Examples
The V model is very similar to the Waterfall method. Therefore, the V model is also suitable for larger projects where a lot of planning is involved.
Typically, large projects require a specific picture of the end product and every step of the way must be mapped out precisely. Your developers will be able to work without experiencing a lot of hurdles.
It’s easily graspable by novices in the beginning. However, the inexperienced developers will need to gain a deep understanding of how the development process goes in your company in order to work effectively using the V model.
All in all, if you’d like to get some more testing along the way, then we’d recommend picking the V model over the Waterfall method.
The Iterative Model
Compared to the traditional software development life cycle models — Waterfall and V model — the Iterative approach is a bit different.
There isn’t typically a lot of planning involved in the initial stages of building the product.
With the Iterative approach, you break down the entire project into smaller chunks — product builds, known as iterations.
Each iteration goes through the typical stages of the software development life cycle — planning, design, implement, test, and deploy. And each cycle builds on the others.
The cool thing here is that once the product build is completed, you can deploy it immediately. Therefore, your customers can see working software right off the bat. This keeps them highly engaged throughout the entire development process.
Also, with the Iterative framework, you can work on a couple of iterations at once. However, you have to keep your team organized as this might confuse them and cause you to slow down.
The Iterative method also allows you to make slight changes along the way. Allowing you to adjust the software to fit the market’s needs.
But keep in mind that the Iterative Model isn’t made to embrace change completely. Though the cost of making adjustments is lower compared to the Waterfall model, it still follows a rigid structure whereby your end product is developed.
So, you’ll have to be careful with the changing environment. Gather enough data to get your team well started on the coding phase. But don’t rush it because you might find it very difficult to adapt to bigger changes.
The Iterative Model — Pros
You can make slight changes to the software. Your project can evolve along the way in order to satisfy the customers’ wants.
There’s not as thorough planning involved in the initial stages as it is in the Waterfall method. However, either way, you should still do some planning to get yourself familiar with the requirements of the product. Otherwise, you won’t be able to understand clearly what you are developing.
Working software is released as soon as possible. Thus, the client and the end-user can see the value of your software immediately. This keeps them engaged along the way.
Also, by deploying constantly working software, you can measure the progress you are making. Keeping your team motivated towards reaching the goal line.
You can work on a couple of iterations simultaneously. But you have to be careful. Sometimes, it is a double-edged sword. It might leave your team highly perplexed and slow down the coding phase.
It’s better suited for bigger teams and projects.
The Iterative Model — Cons
Even though the Iterative approach allows you to evolve your software, it’s not very suitable for change as there is a lot of management involved in the process.
You don’t have a clear image of how the end product should look like as there’s a lack of serious documentation. In the end, you might develop quite a different project than what was planned initially.
Typically, software engineers are required to be highly skilled to adopt new technologies. Commitment also is vital. The team must be entirely focused on building the product in order to stay current with the market.
There might be architecture bugs and design issues along the way due to the lack of specific requirements.
When To Use The Iterative Model — Examples
You can use this method if you believe your team is skilled enough to adapt to new technologies.
Keep in mind that the Iterative model is also a bit rigid and follows some strict guidelines. Therefore, you might not be able to resist a strong changing environment.
All in all, it’s better suited for bigger teams and projects.
The Spiral Model
The Spiral approach is a combination of the Iterative model with some controlled aspects of the Waterfall method. It focuses on releasing software constantly through iterations.
The name stems from the spirals that the product typically goes through.
What’s cool about the Spiral model is that, similar to the Iterative method, it enables you to test every step of the process. Thus, you can ensure that you are coming up with flawless product builds.
The four software development life cycle phases of the Spiral model are as follows: Identification, Design, Build, Evaluation.
Identification
This is the stage where planning and creating the documents actually happens. Here, you’ll survey your end-users and collect feedback.
You are also listing the requirements of the software you are about to build — deadlines, budget estimates, features. The more detailed the software development life cycle documentation is, the easier it will be for your developers to build the product.
Design
Similar to the V model, this stage involves the building of the system design, the architecture design, as well as the module design.
You are basically analyzing the whole development process in order to identify potential risks. When the risks are identified, you can start brainstorming risk-mitigation strategies.
Build
This is the phase where the software is being developed.
At the end of this phase, the developers already have an “a-ready-to-deploy” piece of software. Once you roll it out, you can then collect feedback from the market and evolve.
Evaluation
In this stage, monitoring and observing prevail.
Here, you’ll have to assess how the whole spiral went. You can also see how the market reacts to your first functional part of the software.
You’re basically collecting feedback on what you did right and wrong. Then, in the next spiral, you double down on what was right and try to avoid what you did wrong.
The whole product build goes through a couple of spirals until the final product is developed. And hopefully, throughout the spiral builds, you were able to adapt to the market’s needs to build a product that your users actually want.
The Spiral Model — Pros
The main benefit of the Spiral model is that you can add extra features and elements along the way as opposed to the Waterfall model.
Though it’s part of the Waterfall model, it allows slight changes to the product.
It also allows you to receive feedback through the deployment that happens after each spiral. You are continuously improving your software.
Moreover, working software can be deployed early in the software development life cycle stages. Your customers can see that you are actually providing value.
Also, development can be broken down into smaller chunks. You can then prioritize tasks and your team will work on building the features your market wants to see first.
The Spiral Model — Cons
There is strict management involved in the Spiral approach to ensure that the spirals don’t go on indefinitely. If your management is terrible, the development process can be slowed down significantly.
The whole method can be quite complex as there are multiple spirals that the product build needs to go through.
It’s not suitable for smaller projects as it can be expensive due to the constant testing and deployment.
You lack a clear image of the end product. Therefore, you might come up with a different project than what was initially planned.
When To Use The Spiral Model — Examples
Well, if there are some risky budget estimations involved in the project, you can rest assured that the Spiral model will bring the overspending to a minimum. That’s because there is a constant evaluation of the product.
If there isn’t thorough documentation created initially, it might be a good option to stick with the Spiral approach as it allows the product to evolve along the way.
If you’d like to show your customers the immediate value of the product you are building, you can go with the Spiral Model. It enables you to deploy after every spiral and see how the market reacts to the working software.
The Spiral approach is also fantastic for teams looking for constant user feedback. After each deployment, you can collect customer feedback and make adjustments.
If you are expecting new technology adoption, then the Spiral model is a good fit for you too.
However, it can’t resist a strong changing environment which may cause the spirals to go on indefinitely.
The Agile Model
The SDLC Agile model is actually one of the most popular SDLC methods today.
It was originally developed by 17 software engineers in Utah back in 2001.
The Agile principle is more of a philosophy. It consists of 12 major components known as the Agile manifesto:
Customer satisfaction is the most important.
Change is embraced as it is inevitable.
Delivering working software frequently enough to satisfy the customer.
Daily cooperation between the team is essential.
A motivated team is the best as it can handle all the challenges it faces.
Face-to-face communication is highly encouraged.
You can measure your progress by delivering working software.
The workflow and the pace your team is moving with should be maintained constant.
There should be attention to technical details.
It’s not just about doing more work. It’s about doing more in the shortest amount of time.
Teams that can manage themselves are the best.
Your team should regularly receive feedback and adapt to the changing environment.
We can say that the SDLC Agile model is the complete opposite of the Waterfall model.
The Waterfall model isn’t releasing any software until the late stages of development. Whereas the Agile process focuses on releasing working software continuously.
With the Waterfall approach, you have to do in-depth research. Whereas with the SDLC Agile model, you’re not bound to do any of that — you can hop right into the battlefield and adapt as you move along the way.
With Agile, big projects are broken down into smaller chunks — iterations.
Each iteration goes through the typical phases of the Agile SDLC process — plan, design, implement, test, deploy, and maintain.
Also, every iteration takes somewhere between two and four weeks to be finished. After that, it is deployed to the market. And you collect feedback.
The communication between you and your customers is super vital here. You need to know precisely what the end-users are telling you and adjust the product accordingly.
There are a lot of methodologies that fall under the software development life cycle Agile model. Here are some — XP (Extreme programming), Scrum, Kanban, Lean, Crystal Clear, Feature-driven development (FDD), Adaptive System Development, Rational Unified Process (RUP), Agile Modeling, and more.
The Agile Model — Pros
The main thing about the Agile development model is that you are constantly releasing working software and getting feedback from the market. Thus, you can adjust your product to fit the market’s needs.
Moreover, you don’t have to do any laborious documentation. That’s because the philosophy embraces change and even encourages it.
It’s suitable for smaller projects as you can hop right into the battlefield. With Waterfall, you would spend a lot of time on doing your thorough research.
Through face-to-face interaction and daily communication, you can bring everybody on the same page. Your team will be able to move with twice the speed it used to.
The Agile Model — Cons
The thing with the Agile development model is that you don’t have a clear picture of the end product. Therefore, the product you develop in the end can be a whole lot different from what was initially planned.
Also, because there’s constant change, the team must be highly experienced to evolve along with your software. Your team members need to be able to adopt new technologies in order to develop a great product.
Your team must be 100% committed to getting the project completed. Your teammates shouldn’t focus on side tasks as every distraction can be detrimental for the project.
Determining a solid end date can be quite difficult as you lack thorough documentation.
When To Use The Agile Model — Examples
It’s typically more suitable for smaller projects as you don’t have to do a lot of planning. And you are also able to adapt to the changing environment.
However, it’s not preferred for long-term projects where you have to know every tiny detail. For bigger projects, you need to have a precise picture of what you are trying to develop. And with the Agile model, that’s highly unlikely to happen.
But all in all, if you are keen on flexibility and would like to see how the market reacts to the product you are trying to develop, go with the Agile model.
The Scrum Methodology
The software development life cycle Scrum method is actually a subset of the Agile model. This means that Scrum also adheres to the 12 principles of the Agile methodology.
The Scrum framework operates in timeboxes called sprints. Each sprint lasts between two and four weeks. In that time, the team is working on delivering working software. Once the software is finished, it is deployed to the market and feedback is collected.
Usually, there are three leading roles in the Scrum methodology. There is a Product Owner, a Scrum Master, and a Scrum team.
The Product Owner communicates with the stakeholders and the customers to come up with a great product. Then, the Product Owner creates the product backlog. That’s the place where all the features that need to be developed are listed.
The Scrum Master then takes a look at the product backlog and creates the scrum backlog. In the scrum backlog, each feature is broken down into smaller tasks that need to be completed throughout the sprint. Those tasks are called user stories.
User stories typically show you how the product looks through the eyes of the customer. And what steps the customer needs to take in order to complete a particular task.
It’s important to note that the Scrum Master isn’t a manager. Every member of the Scrum team is responsible for its tasks and needs to make sure that he is meeting the product requirements.
The Scrum team is cross-functional. Because everyone is responsible for its own assignments, each member of the team should be highly experienced. Team commitment is also absolutely essential as there will be changes along the way.
The Scrum team also does daily Scrum meetings. It’s the time and place where everybody shares what they did yesterday, what they are going to do today, and if they are facing any challenges. Thus, if someone is falling behind, the others can bring him back on track.
Each scrum meeting lasts between 5–15 minutes.
Once the sprint is over, there is a Scrum Review meeting where the work completed so far is discussed. The Scrum team then looks back at the development process and improves it based on what went right and what went wrong.
The Scrum team also uses burndown charts to track progress.
The Scrum Methodology — Pros
What’s cool about the Scrum method is that it can adapt to change and adhere to a strict process as well. Throughout the sprint, it’s not advisable to make changes to the backlog. However, when the sprint ends, the team can fix stuff that went wrong and add more assignments to the scrum backlog.
Also, accountability is at a very high level. That’s because there is no manager to manage the team. Everybody is responsible for what they are doing and highly experienced as well. If you get such a team, you won’t have problems with delivering great software on time.
The daily scrum meetings are also great for your team to stay on the same page.
The Scrum Methodology — Cons
Because Scrum is a part of Agile, you don’t have a clear image of the end product. The end result might be a whole lot different from what was planned initially.
Also, there must be a very high team commitment. Due to the changing environment, your team must be able to react swiftly and adopt new technologies if needed.
You don’t have a specific time and cost estimates.
When To Use The Scrum Methodology — Examples
This one is perfectly utilized within a smaller team of 10 people or less.
That’s because there is constant team communication and everybody needs to be on the same page.
Also, there is a continuous interaction between the product and the market. Thus, you can make the necessary changes to your software to meet the market’s needs. For that to happen, you’ll need a highly experienced team of mid-sized and senior developers.
All in all, Scrum is the most popular Agile methodology out there. Feel free to try it.
The XP (Extreme Programming) Methodology
The XP methodology is also a subset of Agile.
It consists of 5 major components:
Simplicity
Team communication
Customer feedback
Courage
Respect
Simplicity
Everything should be done in the simplest way possible. There shouldn’t be any more tasks and features than needed.
The XP method encourages the MVP (minimum viable product) framework. It strives to develop a “just-enough” product that serves the market needs well.
Team Communication
The Extreme Programming framework aims for daily face-to-face communication to bring everybody on the same page.
Effective team communication is especially crucial in the beginning stages of developing a product as there is a lack of documentation. And yes, with the XP model you don’t need to do a lot of planning initially to get your team started. But you need to do a lot of team communication.
In XP, the developers are usually the guys that also do the testing part.
Customer Feedback
You are also releasing working software continuously in order to see how the market reacts to it. After release you collect feedback, assess the situation, and make the required changes to satisfy the customer.
Courage
Yes, courage. You and your team need to be courageous. This means that you should have the courage to accept changes when they occur. You should have the courage to adopt new technologies when necessary. And you should have the courage to take feedback constructively to build an outstanding software solution to your market’s problems.
Respect
Your team members should respect each other. They should help each other. Because what makes a successful product most of the time is a strongly bonded team. You have to ensure that the atmosphere within your team is amazing. You need to make sure that everybody can’t wait to get back to work after the weekend (that might be a bit of an exaggeration).
All in all, XP is a typical Agile methodology. You have to embrace the changing environment and adjust your product to fit the market.
You stress on team communication and gathering customer feedback constructively to ensure you are developing a real solution to the market’s problems.
The XP Methodology — Pros
You are delivering working software constantly. Thus, the customer can see the bang for his buck almost immediately. And what’s cooler is that the customer is involved throughout the whole development journey. You can collect feedback and suggestions from him to come up with a better product.
Change is embraced. You can adjust things along the way if something goes wrong.
It focuses on reducing the cost of the entire project as opposed to Waterfall, where the cost of making changes is enormously high.
Team communication is one of the major principles the XP model consists of. Extreme Programming strives for great team communication through face-to-face interactions and daily meetings.
The XP Methodology — Cons
Similar to any Agile method, it requires the team to be highly experienced and committed to making the project successful.
You are missing a precise picture of the end product. You might end up with something completely different than what was planned initially.
Your team needs to attend frequent daily meetings in order to bring everybody on the same page as there is a lack of documentation.
When To Use The XP Methodology — Examples
It’s good for you to use the XP methodology when your team is highly experienced and is made of 10 people or less.
Also, if your client doesn’t provide you with specific requirements, the XP method will be a good pick for you.
If the technology you are currently using allows you to make automated unit and functional tests, the XP model will straighten up the work process.
And finally, if you think that there is high risk involved due to inappropriate time estimates, you can still go with the XP model as it will reduce the risk.
The RAD Model
…or also known as the Rapid Application Development model, is very similar to the Iterative approach.
The RAD methodology consists of iterations, known as prototypes. Each prototype is a functioning part of the overall software.
What’s cool about the RAD process is that it allows you to deploy each prototype separately. Thus you can collect valuable feedback from the market throughout development.
Moreover, every prototype is developed in a way that makes it reusable for future projects. This saves time and money.
Also, with the RAD model, you aren’t required to create laborious documents to get your team started.
The RAD framework embraces change and enables you to adapt to the changing environment.
It consists of five SDLC phases, and each prototype goes through these phases separately.
The first one is the business modeling. It’s the phase where a thorough business analysis takes place to determine the functions of your product.
The second stage is data modeling. Here, all the data that has been gathered in the previous stage is thoroughly analyzed. Further specifications are developed in order to make the development process clearer.
The third phase is the process modeling. In this stage, the information defined in the data modeling phase is broken down further. More product requirements are listed. Thus, the team is able to come up with the exact product objectives that need to be completed. Also, enhancements and improvements can be made in this stage.
The fourth one — coding phase. Here, actual development happens. The team makes an overall assessment of the development process and picks the programming language that is going to be used.
And finally, you have the testing phase. Once the prototype goes through this one and all the flaws removed, it is deployed. After that, you collect valuable feedback for you to use in the next prototype.
The RAD Model — Pros
The main thing about the RAD model is that it stresses on developing reusable prototypes. This is an actual time and money saver when planning your future projects.
It also focuses on delivering working prototypes to the market. Thus, the customer sees the bang for his buck regularly and stays involved in the development process.
You are collecting feedback from the market with your constant prototype releases.
You can measure the progress easily by delivering working prototypes continuously.
It works great when the team is smaller — around eight people.
The RAD Model — Cons
It requires your team members to be highly skilled and committed to the product you are trying to develop. That’s because the RAD method encourages constant iterations. And your team must be able to evolve along with the changing environment and adopt new technologies.
If the software can’t be broken down into smaller chunks — prototypes, you’ll have a hard time utilizing this SDLC methodology.
There’s some management involved which may make the work process more difficult.
It also requires the client to be constantly involved in the development stage. If there is commitment lacking on either side, then you probably won’t build a great product.
The RAD Model — Examples
The RAD method is perfect for projects where you can break down the product into prototypes. And then reuse these prototypes for future software releases.
The RAD model also encourages changes and iterations. Therefore, if you expect your team to adopt new technologies, go with the RAD method.
Otherwise, you don’t want to pick the RAD method for projects where you need well-defined requirements as there is a lack of documentation.
The Software Prototype Model
The Software Prototype method also consists of developing working prototypes (obviously).
However, the difference here is that the Software Prototype framework only develops “just-enough” prototypes. Which means that the prototypes may have limited features.
Yet, with this approach, you can deliver working prototypes quite rapidly and collect the user feedback swiftly.
If team management is poor, chances are you may build prototypes that are very, very different from the initially planned software. Also, the wrong management can cause your prototypes to become unusable for future projects.
So, keep in mind that this is a very delicate model. It can be of enormous help as it builds “just-enough” prototypes promptly. But it can also be detrimental to your project as it can waste you a lot of time and money if you don’t manage your team properly.
A couple of types of software prototyping are available:
The first one is rapid prototyping. This one is used to develop a functional part of the end product very quickly and sparsely. This type of prototyping contains only the main functions and features that the customer desires.
The second type of prototyping is evolutionary. It is based on heavy user feedback. You jump right into the battlefield with a quickly developed prototype and adjust it along the way.
The third one is called extreme prototyping. This one is mainly focused on developing web applications. It consists of three major components. The first one is known as the static prototype. It builds a basic prototype along with all the required HTML pages. In the second stage, a lot of programming happens in a chosen web framework using a simulated services layer. The third and last phase is where the prototype is being deployed.
And finally, you have the incremental prototyping. This stage encourages you to build multiple functional prototypes and then integrate them into the final product.
There are a few major steps to designing a software prototype, no matter the type. Here are they:
Basic Requirement Identification. This is the phase where you collect data about the product you are building. Try to stress on gathering more data about the user interface. It’s the primary component that will determine whether your software prototype is going to be successful or not.
Building. This is where the actual development happens, and it happens swiftly. We have to note that the prototype can be a bit different from the original software as it’ll probably have a lot of limitations.
The Review. In this phase, you’re presenting the initial software prototype to the stakeholders and the customers. You are then discussing if enhancements need to be made and if they are technically and financially feasible.
Enhancing. Here, the developers improve the software based on the stakeholders’ feedback. Then the prototype is presented to the stakeholders again. This process repeats itself until everybody agrees on the working software prototype.
A software prototype can be developed in two ways. The first way demonstrates a broader view of the end product. It stresses on the user interface without going deeper into the internal systems.
The second way in which you can develop a prototype is by focusing on a specific function or system. This way is more technical as it shows what a particular function can do and how exactly it does it.
The Software Prototyping Model — Pros
A working software prototype is developed swiftly. Your users can get an excellent understanding of your end product in the initial software development life cycle stages.
Due to the continuous deployment, you can gather valuable feedback and adjust the development process.
It can reduce expenses as flaws can be detected much earlier compared to traditional software development life cycle methods.
If there’s a function in your software that your users don’t like, you can identify it quickly and remove it from the development process.
The Software Prototyping Model — Cons
This method can be quite hard to manage. It might leave your team a bit confused at some point in the development process.
Some of the existing prototypes might not be eligible to be used again due to bad management.
The developers in your team have to be highly skilled to be able to work using the Software Prototyping method. That’s because they might end up putting a lot of effort into developing a software prototype that doesn’t seem to work right.
When To Use The Software Prototyping Model — Examples
The Software Prototyping model is highly preferred in products where the user interface is one of the main components to keep your customers happy.
However, if there’s terrible management within your team, you might want to skip the Software Prototyping method. That’s because your team will put a lot of effort into developing a prototype that probably won’t work properly.
The Big Bang Model
So, if you have a very small project under your radar and you want to hop right into it without making almost any planning initially, the Big Bang method is the right pick for you.
Of course, this type of development isn’t suitable for large projects where you need to have specific requirements to start developing.
The Big Bang method is great for small teams of 5 people working on small projects lasting no more than a month.
It’s also a good model to use when the client isn’t detailed about the instructions and doesn’t know how the end product should look like.
Here are the pros and cons of the Big Bang Model:
The Big Bang Model — Pros
It is perhaps the simplest method of all the listed above.
It requires close to zero planning as it encourages the “just-do-it” philosophy.
It’s also highly flexible. It allows developers to adapt to the changing environment.
It’s a good model if you have new developers in your team that are trying to adapt to the working environment.
The Big Bang Model — Cons
It’s a high-risk method of approaching your software. The product you develop in the end can turn out to be completely different from what was planned initially. That’s because there is a lack of requirements.
It’s not a good method for complex and big projects.
When To Use The Big Bang Model — Examples
You should stick with this method when working on smaller projects where requirements from your client are scarce.
It’s also good to use this method with your novice developers as it is simple to adopt.
If you don’t have a clear picture of the end product, then you can also go with this model.
The Big Bang method isn’t a good option for long-term and complex projects where a lot of initial planning is required.
Which SDLC Model Is The Right For You?
I guess that this is something that might have crossed your mind.
The “great” answer to this question is… it depends.
It depends on the size of your team, on the size of the project, on the complexity of the project, on the experience of your developers, on the tools you are using, and more importantly, it depends on your preference.
If you believe that you have a skilled team of developers, and you’d like to save time by avoiding documentation as much as possible, then one of the Agile models can be good for you.
They are flexible and allow you to adapt to the changing environment. But they are not easy to get used to.
On the other hand, if you’d like to have everything straight and know every step of the way, then the Waterfall or the V model can be a good fit for you. If you have novice developers on the team, they can adapt easily to the Waterfall model.
But keep in mind that changes with the Waterfall model are either very costly or impossible to make.
In the end, I’d recommend you to just pick the one your gut is telling you to choose. You’ll have to try most of these to see which one suits you the best. You’ll rarely pick the right model from the first time. So take it with a salt of grain, and just pick the one that you think it’ll fit your team well right now.
OK, if you still struggle with making a decision, let’s see the software development life cycle models other companies are using and what they are achieving with them.
“Our SDLC varies based on project and client, but we primarily focus on a hybrid-agile model. We like agile and the ability to change rapidly based on feedback. However, a lot of stakeholders want roadmaps, release dates, and forecasting that don’t align too well with the agile methodology. So to make everyone happy while still being a productive team that focuses on the important and can adapt to changes and feedback, which tend to pick and choose parts of agile along with parts of the waterfall method to build a development life cycle that caters to the team. At the end of the day, if it doesn’t help us deliver value, we won’t do it, regardless if it’s in the definition of agile or not.” — Justin R. Pennington, director of development at Ceetus.
“We normally work with the Agile methodology for software development. We were earlier using the Waterfall model, but it led to a lot of to-for discussions, and mostly at the end, the client expectations had changed. With Agile, we normally go for a 2–4 weeks sprint, and regularly interact with the client to get feedback and iterate on it. The Agile methodology has reduced the error rate and led to increase in productivity for our teams. Also, it keeps the team motivated as there is a quick feedback cycle and opportunities to improve upon the mistakes made. With Agile, we have realised that we focus more on the actual output than the documentation process.” — Saurabh, Founder of Talk Travel.
“I like what is often referred to as the “V” model, only I would more characterize it as a zig-zag model. That is there are many more iterations than what the V model suggests, thus the “W” shape or even more, continuous zig-zag until the product has all of the features intended for this release as well as having accomplished the testing needed for that iteration.” — Jon M Quigley has more than 20 years of experience in developing software products at Value Transform.
“Because we’re a small company, we don’t follow any well known software development processes. Instead, I just give my developers a task, and they work on it at their own but reasonable pace. I don’t micromanage my developers, but once in a short while, I ask them to provide an update. I also ask them to let me know if they’re stuck with something. This means that we don’t have deadlines! As a software developer, I know that software developers hate estimates and deadlines. I don’t want my developers to worry about deadlines. I want them to focus on what they love doing most, i.e. programming, and once their code is tested and ready, we release it.” — Gene, CTO at Static Jobs.
“We transitioned to something we dubbed “organic”. It’s very much agile but we chose a different name to avoid the connotations we now have with capital-A Agile. Every 2 weeks, we plan a new iteration and give the previous 2 a post-mortem. We choose the most valuable feature of a project, hand in hand with a client, and ruthlessly focus on that. It sounds like agile, and it largely is because we trial ideas out of that camp. But the key is that it’s not dogmatic. By giving it a different name, and through fortnightly monitoring, it gives us the opportunity to try new ideas and decide on whether existing ideas work for us. For example, a morning huddle works well. But we found, due to remote working, paid programming doesn’t work for us, so we don’t do it. So our lifecycle constantly evolves, in a truly Darwinian way: the best techniques and tools survive, the rest don’t. And because it’s shaped our culture, there is no hesitation to critically brand even my ideas as useless if they don’t pass the trial.” — James Dunne, Tech Director at The Fresh UK.
“Momentum uses a combination of Kanban and Scrum: Scrumban. We configure boards in Jira to use sprints as they would be used for Scrum development, but these sprints are not scheduled. We manage the sprint backlog using a Kanban-style pull system. Whenever we’re ready to work on something new, we just pull a card from the To-Do column and start to work on the story. We have daily stand ups with bi-weekly product demos.” — Matthew Wardenaar, Head of Product at Momentum.
“In our organization we use Agile SDLC Model, using this approach every member in a group focuses on one task at a time. Agile methodology has a lesser scope of work in comparison to waterfall models. This is because each team member focuses on specific tasks at a time. This is very beneficial in estimating project timeline accurately and meeting short-term deadlines quickly. Short-term goals and deadlines motivate employees to work at their best potential. This methodology helps in increasing productivity of employees, and enhances customer satisfaction.” — Ayushi Sharma, Business Consultant, iFour Technolab Pvt Ltd — “Custom software Development Company.
“The choice of the SDLC model depends a lot on the goal of the project. We use waterfall and agile models, which aren’t binary and mutually-exclusive alternatives, as it might seem. We start with the waterfall to have the chance to estimate the approximate dates and clarify the task in the process. Basically the pattern is: Gather requirements -> Design a Solution -> Implement a Solution -> Test the Solution -> Deploy the Solution. The waterfall method provides a value-creation chain with multiple single-points-of-failure from ideation to distribution.
However, for the actual project implementation, we use Agile. Agile methods have no single point of failure in the value creation chain. The client usually needs flexibility, especially when it is a product development. Tendency more toward the lean and agile principles will more likely bring in a more successful outcome. A pure waterfall or sequential approach can be riskier and have a greater chance of failure. It’s more of a question of how iterative you want to be. In some cases, you want much smaller feedback cycles. In others, it is better to plan bigger chunks of the work and have longer feedback cycles.” — Roman Kolos, Product Manager at LAB325.
“My name is Kean Graham and I’m the CEO of MonetizeMore, an 8-figure ad tech company that is a Google Certified Partner with a 100+ full-time staff based all around the planet.
We have a 20+ team of engineers split into three agile scrum teams. Software development was quite a challenge as our tech development would be delayed over and over again. We then made some major improvements like:
- Get design more involved with spring planning
- Run daily, sprint and monthly KPIs to gauge performance
- Get engineers closer to the users
- Automate testing
- Move to CI / CD
- Improve overall communication
- Make documentation more thorough and consistent
The above has dramatically improved the sprint completion rates which has improved the delivery consistency, tech features have been built faster and the quality of tech has improved as intended user outcomes are more consistently achieved.” — Kean Graham, CEO at MonetizeMore.
So that’s all there is to this guide!
Hope it helps you out. Feel free to share your thoughts on the SDLC methods you’ve used so far in the comments below.
Also, if you are leaning towards Agile, Scrum, and XP — I believe that my company can be of help! We have an agile project management tool for developers to help you out with prioritizing your tasks — Codegiant. Feel free to check it out.