8 Software Development Models: Sliced, Diced and Organized in Charts

Software development life cycle (SDLC) models show the ways to navigate through the complex and demanding process of software building. A project’s quality, timeframes, budget, and ability to meet the stakeholders’ expectations largely depend on the chosen model.

Today, there are more than 50 recognized SDLC models in use. None of them is perfect, and each brings its favorable aspects and disadvantages for a specific software development project or a team. According to our 35 years of experience in software development, we’ve chosen 8 most popular models to look into their essence and compare for core features. 

The outline of popular SDLC models

All SDLC models can be structured into several groups depending on how they approach workflow organization – linearly or iteratively – and what kind of relationships are established between the development team and the customer.

The types in the lower quadrants of the chart take the sequential flow. They are easy to implement, use and manage. As you move higher, the process becomes less rigid and offers more flexibility when it comes to changes in the requirements for future software.

The models on the left side of the chart imply low customer involvement; as you move toward the right side, the models grow more ‘cooperative’ and include customers into different stages of software development life cycle more intensively.

Types of SDLC models and what projects each supports best

Waterfall

Through all development stages (analysis, design, coding, testing, deployment), the process moves in a cascade mode. Each stage has concrete deliverables and is strictly documented. The next stage cannot start before the previous one is fully completed. Thus, for example, software requirements cannot be re-evaluated further in development. There is also no ability to see and try software until the last development stage is finished, which results in high project risks and unpredictable project results. Testing is often rushed, and errors are costly to fix.

Use cases:

• Simple small or mid-sized projects with clearly defined and unchanging requirements (small company website development).
• Projects with the need for stricter control, predictable budget and timelines (e.g., governmental projects).
• Projects that must adhere to multiple rules and regulations (healthcare projects).
• Projects where a well-known technology stack and tools are used.

V-model (Validation and Verification model)

The V-model is another linear model with each stage having a corresponding testing activity. Such workflow organization implies exceptional quality control, but at the same time, it makes the V-model one of the most expensive and time-consuming models. Moreover, even though mistakes in requirements specifications, code and architecture errors can be detected early, changes during development are still expensive and difficult to implement. As in the Waterfall case, all requirements are gathered at the start and cannot be changed. 

Use cases:

• Projects where failures and downtimes are unacceptable (e.g., medical software, aviation fleet management software).

Incremental and Iterative model

The development process based on the Incremental model is split into several iterations (“Lego-style” modular software design is required!). New software modules are added in each iteration with no or little change in earlier added modules. The development process can go either sequentially or in parallel. Parallel development adds to the speed of delivery, while many repeated cycles of sequential development can make the project long and costly.

With Iterative development software changes on each iteration, evolves and grows. As each iteration builds on the previous one, software design remains consistent.

As software is delivered in parts, there is no need for a full specification from the project’s start and small changes to requirements are possible in the course of the development process. However, the requirements can’t change radically – major ones must be defined in the beginning, especially those for system design in case of Incremental development as further integration of the delivered software parts can become an issue.

This SDLC model typically entails some customer involvement because of the possible need in small requirements amendments during the development process.

Use cases:

• Large, mission-critical enterprise applications that preferably consist of loosely coupled parts, such as microservices or web services.

Spiral model

The Spiral model puts focus on thorough risk assessment. Thus, to reap the benefits of the model to the fullest, you’ll need to engage people with a strong background in risk evaluation. A typical Spiral iteration lasts around 6 months and starts with 4 important activities - thorough planning, risk analysis, prototypes creation, and evaluation of the previously delivered part. Repeated spiral cycles seriously extend project timeframes.

This is the model where intensive customer involvement appears. They can be involved in the exploration and review stages of each cycle. At the development stage, the customer’s amendments are not acceptable.

Use cases:

• Projects with unclear business needs or too ambitious/innovative requirements.
• Projects that are large and complicated.
• Research and development (R&D) activity or the introduction of a new service or a product.

The Rational Unified Process (RUP)

The Rational Unified Process (RUP) is also a combination of linear and iterative frameworks. The model divides the software development process into 4 phases – inception, elaboration, construction, and transition. Each phase but Inception is usually done in several iterations. All basic activities (requirements, design, etc.) of the development process are done in parallel across these 4 RUP phases, though with different intensity.

RUP helps to build stable and, at the same time, flexible solutions, but still, this model is not as quick and adaptable as the pure Agile group (Scrum, Kanban, XP, etc.). The degree of customer involvement, documentation intensity, and iteration length may vary depending on the project needs.

Use cases:

• Large and high-risk projects, especially, use-case based development and fast development of high-quality software.

The Agile group

The rest of the SDLC models we’ve chosen fall under the umbrella of Agile. Nowadays, more than 70% of organizations employ this or that Agile approach in their IT projects. In general, at the heart of Agile are iterative development, intensive communication, and early customer feedback.

Each Agile iteration usually takes several weeks and delivers a complete working software version. The models of this group put more focus on delivering a functioning part of the application quickly. They pay less attention to detailed software documentation (detailed requirement specification, detailed architecture description), and more to software testing activities. This fosters quick development but considerably prolongs software transfer to the support team as well as makes its maintenance more complicated as more time is spent to find the problem when there's no detailed software description.

Agile is about working in close collaboration both across the team and with the customers. At the end of each iteration, stakeholders review the development progress and re-evaluate the priority of tasks for the future iteration to increase the return on investment (ROI) and ensure alignment with user needs and business goals.

Accordingly, frequent releases are characteristic to the Agile models. They also allow for continuous software improvement with easy fixes and changes, quick updates, and feature addition, and help to deliver applications that satisfy users’ needs better. However, the lack of detailed planning and openness to changes make it difficult to accurately estimate budget, time and people required for the project.

Use cases:

• 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.

Agile comes in different flavors. Today, its most common subtypes are Scrum, Extreme Programming, and Kanban.

Scrum

Scrum is probably the most popular Agile model. The iterations (‘sprints’) are usually 2-4 weeks long, and they are preceded with thorough planning and previous sprint assessment. No changes are allowed after the sprint activities have been defined.

Extreme Programming (XP)

With Extreme Programming (XP), a typical iteration lasts 1-2 weeks. The model allows changes to be introduced even after the iteration’s launch if the team hasn’t started to work with the relevant software piece yet. Such flexibility significantly complicates the delivery of quality software. To mitigate the problem, XP requires the use of pair programming, test-driven development and test automation, continuous integration (CI), small releases, simple software design and prescribes to follow the coding standards.

Kanban

As for Kanban, its key distinguishing feature is the absence of pronounced iterations. If used, they are kept extremely short (‘daily sprints’). Instead, the emphasis is placed on plan visualization. The team uses the Kanban Board tool that provides a clear representation of all project activities, their number, responsible persons, and progress. Such increased transparency helps to estimate the most urgent tasks more accurately. Also, the model has no separate planning stage, so a new change request can be introduced at any time. Communication with the customer is ongoing, they can check the work results whenever they like, and the meetings with the project team can happen even daily. Due to its nature, the model is frequently used in projects on software support and evolution.

Summing models in charts

Using as basis the research data, we’ve compared the models in terms of core features – time, cost and quality – to make them easier to digest and comprehend. All estimates are relevant to small applications with code consisting of 1,000 functions.