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.
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.
This is a linear and sequential software development model where project phases follow one another and include:
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.
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
The waterfall model is a nice option if all of these conditions are true:
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.
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”).
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
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.
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.
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
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.
In the incremental and iterative development model, the software is built in small portions through a series of cycles. The workflow is as follows:
|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
Though it’s cheaper to release one module, the overall system costs will increase as new modules are integrated
You may find this model useful in the following:
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.
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:
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.
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
The spiral model is a go-to for the following cases:
Microsoft, IBM, and Tata Consultancy are allegedly using the spiral model.
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:
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:
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.
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
Most modern projects require a certain level of “agility,” especially when:
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.
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:
With these tips in mind, we embrace the change while delivering a high-quality product to our customers.
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.