Choosing the right software development life cycle model (SDLC) is crucial to ensuring a project’s quality, timeframes, budget, and ability to meet stakeholders’ expectations.
Today, there are more than 50 recognized SDLC models in use. Each one is not perfect, but each has its advantages and disadvantages depending on the type of software development project or team. To look at their essence and compare their core features, we’ve selected eight of the most popular models based on our 14 years of experience in software development.
The outline of popular SDLC models
There are numerous SDLC models depending on how they approach workflow organization – linearly or iteratively – and how relationships between the development team and the customer are established.
The types in the lower quadrants of the chart are characterized by sequential flow. They are easy to implement, use and manage. As you move forward, the process becomes less rigid and offers more flexibility when it comes to changes in future software requirements.
As you move to the right side of the chart, you find increasingly ‘cooperative’ models that involve customers more closely in different stages of software development life cycle.
Different types of SDLC models and which projects they support
- Incremental model
- Spiral model
- Summing models incharts
Throughout all development stages (analysis, design, coding, testing, deployment), the process moves in a cascade mode. There are concrete deliverables for each stage and they are strictly documented. The next stage cannot begin until the previous is complete. In this case, software requirements cannot be re-evaluated further in development. Testing is often rushed, and errors are costly to fix. Software cannot be seen and tested until the last development stage is completed, which results in high project risks and unpredictable project results.
- Projects with clearly defined, unchanging requirements (small company website development).
- Projects requiring tighter control, predictable budgets, and timelines (e.g., governmental projects).
- Multi-rule and multi-regulatory projects (healthcare projects).
- The use of well-known technology stacks and tools in projects.
V-model (Validation and Verification model)
A linear model, the V-model has corresponding testing activities for each stage. Such a workflow organization implies exceptional quality control, but at the same time, it is one of the most expensive and time-consuming. The changes during development are also expensive and difficult to implement, even though errors in requirements specifications, code, and architecture can be detected early. Waterfall projects gather all requirements at the start and cannot modify them.
- Projects that cannot tolerate failures or downtime (e.g., medical software, aviation fleet management software).
Incremental and Iterative model
As part of the incremental development process, several iterations are conducted (“Lego-style” modular software design is required!). The development process can be sequential or parallel, with no or little change to previously added modules in each iteration. Parallel development speeds up delivery, while sequential development makes a project long and expensive when repeated cycles occur.
Iterative software development involves evolving and growing with each iteration while maintaining consistency.
Software is delivered in parts, so a full specification is not necessary at the beginning of the project, and requirements may change over the course of the development process. In the case of incremental development, however, major requirements must be defined early on. This is especially true for system design, as further integration of the delivered software parts can be problematic.
During the development process, this SDLC model typically involves some customer involvement.
- Large, mission-critical enterprise applications that consist of loosely coupled parts, such as microservices or web services.
Spiral emphasizes the importance of thorough risk assessment, so you’ll need people with experience in risk evaluation to get the full benefit of the model. In a typical Spiral iteration, four important activities are carried out – thorough planning, risk analysis, prototyping, and evaluation of the previously delivered part – which last about 6 months. Project timeframes are significantly extended by repeated spiral cycles.
Customers can be involved in the exploration and review stages of each cycle, but their amendments are not acceptable at the development stage.
- Uncertain business needs or ambitious/novel requirements.
- Large, complicated projects.
- A new service or product that was developed through research and development (R&D).
The Rational Unified Process (RUP)
Rational Unified Process (RUP) is also a combination of linear and iterative frameworks. Inception, elaboration, construction, and transition are the four phases of the software development process. Iterations are usually conducted throughout each phase except for Inception. As part of these 4 RUP phases, all the basic activities of the development process (requirements, design, etc.) take place simultaneously, though at varying intensities.
However, RUP cannot be as quick and adaptable as pure Agile groups (Scrum, Kanban, XP, etc.) in terms of building stable and, at the same time, flexible solutions. Depending on the project’s needs, customer involvement, document intensity, and iteration length may vary.
- The development of large, high-risk projects, especially the development of high-quality, use-case-oriented software at a rapid pace.
The Agile group
Almost 70% of organizations now employ some form of Agile approach in their IT projects. The rest of the SDLC models we chose belong to the Agile category. In general, Agile emphasizes iterative development, intensive communication, and early customer feedback.
The Agile model emphasizes the importance of delivering a functioning part of the application as soon as possible. An Agile iteration usually takes a few weeks and produces a fully functional software version. It is more important for them to conduct software testing activities than detailed software documentation (detailed requirements specification, detailed architecture description). When there is no detailed description of the software, it takes more time to find the problem, prolonging the process of software transfer to the support team as well as making maintenance more complicated.
As an agile team, we work closely with our customers and across the team. In order to increase return on investment (ROI) and align with business goals and user needs, stakeholders review the development progress at the end of each iteration and re-evaluate the priority of tasks for the next iteration.
Agile models are characterized by frequent releases. As a result, they allow for continuous software improvement through easy fixes and changes, quick updates, and addition of new features, and assist in delivering applications that meet the needs of users more effectively. In spite of this, it is difficult to accurately estimate the project’s budget, time and people due to the lack of detailed planning and openness to changes.
- Practically any startup initiatives, when end users’ early feedback is required.
- Most of mid-sized projects in custom software development, where business requirements cannot be confidently translated to detailed software requirements.
- Large projects that are easy to divide into small functional parts and can be developed incrementally over each iteration.
The most common subtypes of Agile today are Scrum, Extreme Programming, and Kanban.
Scrum is probably the most popular Agile model. Sprints are usually 2-4 weeks long, preceded by rigorous planning and previous sprint assessments. After sprint activities are defined, changes are not allowed.
Extreme Programming (XP)
Iterations in Extreme Programming (XP) typically last about 1-2 weeks. If the team hasn’t started working on the relevant software piece yet, changes can be added even after the iteration has launched. The delivery of quality software is significantly complicated by such flexibility. In order to mitigate this problem, XP prescribes pair programming, test-driven development and test automation, continuous integration (CI), small releases, simple software design, and coding standards.
As for Kanban, its key distinguishing feature is the absence of pronounced iterations. If they are used, they are kept extremely short (‘daily sprints’). Instead, the emphasis is placed on plan visualization. As a result, team members use the Kanban Board tool to see all project activities, their numbers, responsible persons, and progress more clearly. As a result, the most urgent tasks can be estimated more accurately. It is also possible to introduce a new change request at any time since the model does not have a separate planning stage. The customer can check the results of the work at any time, and they can even meet with the project team on a daily basis. In software support and evolution projects, the model is frequently used due to its nature.