More than a half of IT projects never succeed. Misinterpreting business objectives, ignoring the customer, not prioritizing tasks correctly are some of the most common reasons for software project failure. Interestingly, all these reasons have a common root: the wrong software development approach.
In this article, you’ll learn about the key software development life cycle models (SDLCs), their pros, cons, and real-life use cases. Besides, Vadim Kulaga, Software Engineering Manager and EPAM Anywhere's Delivery Manager, will tell you how we approach projects at EPAM Anywhere and what results the approach brings.
The main software development life cycle models
A software development life cycle (SDLC) model stands for a sequence of actions you have to complete to build a solution. Simply put, it’s a way to deliver a software product.
And that’s where the hardest part begins. The problem is that there are tons of SDLC models used for different types of projects. How do you know which is the right one for your project?
Don’t worry. We’ve listed the most popular SDLC models, their use cases, advantages, and disadvantages for your convenience.
The waterfall model
This is a linear and sequential software development model where project phases follow one another and include:
- Discovery. The development team collects project requirements and includes them in the Software Requirements Specifications (SRSs) document.
- Design. They analyze all the requirements and roll out a system prototype.
- Coding. Once the project stakeholders accept the prototype, the coding phase begins.
- Testing. The QA team runs each unit through various testing scenarios and integrates them into the system. As soon as all components are in place, they test the entire system.
- Deployment. The product is delivered to the customer, as bug-free as possible.
- Maintenance. The development team monitors the project and makes updates where necessary.
Waterfall is a highly organized model where you can’t skip phases, change their order, or alter requirements when the project is in full swing. Which brings its advantages and disadvantages.
Pros | Cons |
|---|---|
It’s an easy-to-use model | With this model, it’s too difficult and expensive to adapt to changes in requirements |
Each stage is well-documented | Documenting each project phase is time-consuming |
The project outcome is absolutely predictable | You can’t deliver anything to the customer until you complete the entire project |
Stages and roles are clearly defined from the very beginning | Various teams (design, development, quality assurance, etc.) are isolated, and interaction between them is limited |
Minimal client intervention | With no client feedback, the result risks not living up to the client’s expectations |
Use cases
The waterfall model is a nice option if all of these conditions are true:
- A project is short and zero-risk
- Requirements are fixed
- Technologies are stable
- All the necessary resources are available
Just a decade ago, many companies used the waterfall model to develop enterprise software, including CRM, supply chain management, and Point of Sale systems. But today, the model fails to address the rapidly changing tech needs. That’s why companies are increasingly turning to more recent approaches.
The V-shaped SDLC model
Basically, the V-shaped model is a QA-driven version of the waterfall, with each phase having a corresponding testing procedure.
For example, when the development team gathers project requirements, the QA experts write acceptance tests based on these scenarios. Similarly, during the system design stage, the system testing scenarios are being created. And so on all the way down the left side of the “V." After the coding stage, the QA team validates the product against pre-written tests (the right side of the “V”).
Pros | Cons |
|---|---|
It’s easy to implement | Within the V-shaped model, it’s extremely difficult to make changes in the middle of the project |
Test cases are created early | With so many testing procedures, there’s less time for coding |
Budget and project duration are predictable | Compared to the waterfall, this model requires more experts |
Each stage has its deliverables, and everything is well-documented | The model isn’t suitable for projects with rapidly changing requirements |
It’s a structured approach with roles and functions clearly defined | It doesn’t work well for large, complex projects |
Use cases
The V-shaped model can be extremely useful in cases when bugs might be fatal and projects where precision is crucial.
For example, it’s a go-to for regulation-based solutions, such as tax filing applications. Besides, this model comes in handy in healthcare. For instance, Roche Diagnostics once used it to develop a cancer diagnosis system.
The evolutionary prototyping model
This is another variation of the waterfall. While the project passes through traditional phases, the product prototype is refined incrementally based on customer feedback.
As a rule, the first prototype doesn’t pass this user acceptance test. That’s why the classic prototyping model involves several prototypes. Only when the suggested product design is fully accepted can the development team proceed with the following stages.
Pros | Cons |
|---|---|
Early user feedback | Since prototypes can evolve endlessly, project planning is impossible |
Increased chances for project success | It’s expensive to develop multiple prototypes |
The model makes it easier to adapt to rapidly changing requirements |
Use cases
The evolutionary prototyping model can be useful for various projects that imply user interactions, use new technology, have complex functionality, or rely on quickly-changing requirements that are hard or impossible to predict.
The iterative and incremental model
In the incremental and iterative development model, the software is built in small portions through a series of cycles. The workflow is as follows:
- Planning. You collect all project requirements and divide them into components.
- Implementation of modules. Each iteration is a “mini-waterfall” with module requirements analysis, design, implementation, and unit testing, integration and system testing, version release, and evaluation. The process repeats until all the requirements are fulfilled.
Pros | Cons |
|---|---|
| The incremental and iterative development model enables fast and regular delivery of working software to customers | Architectural issues can occur during module integration |
It’s easier and cheaper to accommodate changes in project requirements | Despite some level of flexibility, the system should be planned from the very beginning; otherwise, it can’t be segmented into modules |
Early customer feedback | Customer involvement can be problematic |
Smaller software portions are easier to test and fix | It’s not always possible to break down a system into segments |
Cost savings | Though it’s cheaper to release one module, the overall system costs will increase as new modules are integrated |
Use cases
You may find this model useful in the following:
- Systems consisting of multiple segments with clear requirements
- Projects with limited resources or time-to-market constraints
- Startups going through investment rounds
- Projects with a big scope
- Projects based on new technologies
- Projects that should be evolved after release
According to Alister Scott, every competitive software project requires some level of incrementing and iterating. Even if you use the waterfall model to develop your solution, the latter will become out-to-date very quickly. That’s why additional iterations are a must.
The spiral method
This is a risk-driven approach that combines features of the waterfall, prototyping, iterative, and incremental models. It looks like a spiral with multiple circles. Each circle is a phase consisting of four elements:
- Requirements gathering. It involves identifying and analyzing stakeholders’ needs and business objectives.
- Risk analysis and prototyping. The team evaluates all the possible ways to address customer needs and chooses the best solution. Then, they identify and resolve risks associated with the solution and create a prototype that evolves with each subsequent circle.
- Engineering. The engineering team proceeds with the development and testing of what was planned during the two previous stages.
- Planning the next phase. The delivered product is sent to the customer for evaluation. Besides, the development team analyzes the entire cycle in terms of scheduling, budget, and other criteria. Then, based on the users’ and stakeholders’ feedback, the next iteration is planned.
As you can see, the product repeatedly passes through these stages, and at the end of each loop, a better product version is created and released. And like in the iterative approach, a product is built in a series of releases.
Pros | Cons |
|---|---|
Risk analysis during each iteration increases chances for project success | Risk management expertise is needed |
This method allows creating stable and reliable systems since they’re tested thoroughly during each cycle | The model involves much documentation |
You can change requirements between cycles | You can’t change requirements when a cycle is in full swing |
Early involvement of developers helps to align business requirements and technical capacities | Each circle in the spiral development is a mini-waterfall, meaning that you can’t skip phases |
Frequent releases enable regular feedback from customers even in the early cycles | Since there are no limitations when it comes to the number of iterations, it’s harder to predict how many circles it will take to create the final product version |
Use cases
The spiral model is a go-to for the following cases:
- Large, complex products with multiple components
- Projects with frequent releases
- Medium and high-risk projects
- Projects with unclear requirements
Microsoft, IBM, and Tata Consultancy are allegedly using the spiral model.
Agile software development models
Contrary to popular belief, Agile is neither a framework nor a methodology. It’s a philosophy with a set of principles focused on accelerating the software development process, ensuring 100% customer satisfaction, and delivering high-quality solutions in a fast-changing environment. In fact, there are 12 principles of Agile development distilled into the following values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile values have given rise to more than 50 methodologies, with Scrum being the most popular one.
Scrum
Scrum projects are segmented into sprints. A sprint is a small amount of work that has to be completed within a fixed period. A part of the project that was completed during a sprint (the increment) is typically delivered to the customer.
Scrum implies a lot of communication and collaboration between everyone involved in the project. Along with daily scrums (15-minute daily meetings for developers to align their efforts), there are also:
- Sprint planning, when project stakeholders and the development team meet to discuss what should be done during the next sprint.
- Sprint review, when the development team demonstrates to the stakeholders what has been done during the sprint and the progress toward the project goal is reviewed.
- Sprint retrospective, when the development team analyzes the sprint and discusses how they can improve the processes during the next sprints.
The “heart” of the Scrum processes is the product backlog, a list of things to be done to complete a project. As the project progresses and the team learns more about it, they refine their product backlog by adding, removing, and reordering its items. Still, you can’t do something if it isn’t in the product backlog.
Is Agile “all roses”? Let’s look at its main use cases, as well as the pros and cons.
Pros | Cons |
|---|---|
You don’t need to wait when the project is finished to roll out the product’s core features | Agile software life cycle models are hard to adopt |
There’s no space for guesswork with cross-functional teams (where specialists with different areas of expertise work together), knowledge sharing practices, and regular communication between project owners and the implementation team | In Agile, project documentation becomes out-of-date very quickly, so you’ll need additional expertise to take care of it |
An ability to adapt to changes at any project stage | It’s almost impossible to make predictions and do budget planning in Agile projects |
Early and constant user feedback, which results in greater customer satisfaction | Collecting user feedback can be challenging |
Use cases
Most modern projects require a certain level of “agility,” especially when:
- Project requirements aren’t clear enough
- Project requirements are constantly changing
- A project involves a lot of user interactions
- A project has a lot of stakeholders
All in all, Agile seems to be exactly what most projects need in times of uncertainty. No wonder more than 70% of companies adopt Agile, including Microsoft, IBM, Procter & Gamble, and beyond. And EPAM is no exception.
EPAM Anywhere experience: Agile development
Let’s face it: none of the SDLC models is a “magic pill.” You can’t just pick a methodology that seems to suit your project needs and follow it blindly. At best, it won’t improve your development process. At worst, you’ll put your entire project at risk. That’s why a smart approach to choosing and implementing a software development model is key to making it work for you.
Let’s take EPAM Anywhere, for example. With a project of such magnitude and complexity, it might seem challenging to satisfy the ever-changing user and stakeholder needs. However, we roll out releases daily (!) while keeping our solution safe, reliable, and highly performant.
How did we manage to achieve a workflow like this? Here are some insights from Vadim Kulaga, software engineering manager at EPAM Anywhere:
- Don’t lock your project inside one methodology. We combine several SDLC approaches based on the current needs and the process type. For development, we use some Scrum practices, while Kanban is well-suited for maintenance.
- Use tech to gather user feedback. Collecting user feedback regularly and using it to make improvements is necessary for a project that implies many user interactions. We use Hotjar to stay updated on how people interact with our product. Besides, we constantly look through the messages coming from our feedback form to gain a better understanding of what kind of bottlenecks people experience when using EPAM Anywhere.
- A user of your product might be someone you know. Some of our developers came to us through EPAM Anywhere, meaning that they experienced this product on their own. This makes them a valuable source of first-hand user feedback.
- Foster collaboration. Scrum planning events, daily scrums, and other meetings are a part of our routine. Besides, we involve our technical leads in business analysis meetings where the early prototype is demonstrated and business features are discussed. This allows us to keep our developers informed on the kinds of tasks they might be dealing with later.
- Share your knowledge. We have a knowledge base accessible to everyone involved in the project. And it’s regularly updated as the project evolves.
- Take care of your remote project contributors. Face-to-face communication is the cornerstone of any Agile project. Given this, never neglect your remote employees. Make sure they understand the project goals and are engaged in all the processes.
- Build small teams. EPAM Anywhere is “powered” by more than 50 employees. To avoid the “hustle and bustle” within the project, we divided them into small teams of 5-7 people. As a result, our sprint planning meetings take no more than 30 minutes.
With these tips in mind, we embrace the change while delivering a high-quality product to our customers.
Conclusion
Software product success depends largely on choosing a suitable SDLC model and implementing it in the right way. Still, every project is unique, and there’s no one-size-fits-all approach to process modeling in software engineering.
Analyzing the main software life cycle models, their advantages, disadvantages, and use cases will bring some clarity. But at the same time, don’t forget that every methodology is limiting in a certain way, and you might end up adapting your project to a model, not the other way round.
That’s why it’s critical to prioritize your project needs over methodologies, which often implies combining several SDLC models or even coming up with one on your own. Sure, it’s not easy, but it works, and our experience proves this fact.
Explore our Editorial Policy to learn more about our standards for content creation.
read more
