An Overview of the Most Popular Software Development Models

Every new software undergoes through the Software Development Lifecycle which defines the main stages of product creation and states how exactly the process will be carried out. And since every project is unique (at least to a certain extent), there are various SDLC models out there to choose from.   

If you are not sure what model will fit your project best or if you simply want to learn more about the main models in software engineering, our article is exactly what you need. 

What exactly is Software Development Lifecycle and software engineering models?  

The Software Development Lifecycle can be described as a framework that lists all the activities involved in the development process, from start to finish. As for the SDLC model, it is a specific approach to creating software that describes a particular sequence of steps and a particular philosophy behind it. For example, Scrum prioritizes flexibility and speed, while Waterfall focuses on linearity and full completion of every stage.  

In general, software engineering models fall under the linear and iterative categories. As well, every SDLC model will have its own level of familiarity, flexibility, and adoption of changes. Thus, when choosing an SDLC model, you need to consider the following factors: 

• The size of your project and its scalability; 
• Requirements (how clear they are and whether they will be changing); 
• Deadlines and time frames; 
• Main goals to achieve; 
• Priority of testing. 

And many more. Normally, you address a business analyst and/or a project manager and discuss the SDLC model of choice together. 

The main types of models in software engineering

Now, let’s take a look at the most popular types of models in software engineering, their pros and cons and main use cases. 

Waterfall model

The Waterfall model is probably the oldest one and was first introduced back in 1970. This model is very formal and is described as a “linear-sequential lifecycle model”. In simple terms, it consists of several phases, where each phase starts only after the previous one is 100% completed. In this way, the results of the previous phase cascade down to the next one.

There are five main stages in the original Waterfall model, though alterations are possible:

1. Collection of requirements
2. Architecture design
3. Implementation
4. Product verification and testing
5. Support and maintenance

As you can see, testing happens only at a particular stage, and this might be a challenge. Another issue is that this model offers very little flexibility, and you won’t be able to implement any new features at the stage of testing or maintenance. And one more thing to remember: the Waterfall model requires extensive and detailed documentation throughout all stages.

The pros of the Waterfall model:

• Strict and effective control over the project;
• Elimination of scope creep due to pre-defined scope and limitations;
• Easy and understandable task arrangement;
• Clear definition of deadlines and milestones.

The cons of the Waterfall model:

• Lack of flexibility: you can’t implement changes to the completed phase;
• Documentation requires a significant amount of time to be created and maintained;
• Potentially long delivery time;
• Testing is not continuous and thus, certain issues might be missed;
• Requires little feedback from the client.

When to use Waterfall:

• Simple and/or small projects with clear requirements and deadlines;
• Projects that are not expected to change/grow over time;
• Projects that are sensitive to rules and regulations.

V-model

The V-model (Verification & Validation) is another linear model, similar to Waterfall but with one significant difference – each development stage is followed by a testing stage. So for the requirement collection stage, you will need to perform acceptance testing before moving on to system analysis.

The main stages of the V-model are:

• Requirement collection and acceptance testing;
• System analysis and system testing;
• Software design and integration testing;
• Module design and unit testing;
• Coding;
• Testing;
• Deployment;
• Maintenance

If we turn to the model’s name, verification and validation are actually the two main phases, during which various stages take place. Verification implies evaluation of the product with an aim to understand, whether the requirements are met. This phase involves all stages until the coding one (inclusively). Next, the validation phase begins with the testing stage and its main aim is to validate that the designed product meets user expectations.

The pros of the V-model:

• Increases the future accuracy of the product due to ongoing testing activities;
• Has a very structured approach, is easy to use;
• Easy monitoring of changes and requirements;
• Focus on testing;
• Effective progress tracking.

The cons of the V-model:

• Has a high level of risk and uncertainty;
• Is not suitable for projects with many changes and/or unclear requirements;
• Lacks flexibility and does not allow getting back to the previous stage after its completion;
• Requires a lot of time and calls for detailed documentation;
• Does not handle concurrent events well.

When to use the V-model:

• Projects with clear requirements and deadlines;
• Quality-sensitive projects that do not accept failures and/or downtimes;
• Small and/or medium projects.

Spiral model

The Spiral model differs from the abovementioned types of software development models by several important features. First, this model functions by iterations. An iteration consists of several phases and all of them have to be completed before moving on to the next iteration. These phases are:

• Definition of the project objectives
• Risk analysis and resolution
• Development
• Review and planning of the next iteration

With a Spiral model in software engineering, the iteration usually takes about 6 months (though the duration may vary). The number of iterations is defined by the project manager and relies heavily on the project scope and requirements. 

Another important thing to remember about this model is that its main area of focus is risk assessment. Thus, when adopting the Spiral model, the team should include people who are experienced in risk evaluation and management. And due to the model’s flexibility, the client is greatly involved in the development process, so a well-organized communication process has to be established.

The pros of the Spiral model:

• Great risk management and mitigation of errors at early stages;
• Flexibility in requirements and adoption of changes;
• High level of client’s engagement and involvement;
• Great adaptability to the changing requirements.

The cons of the Spiral model:

• Complexity in terms of implementation and maintenance;
• Requires too much time and resources;
• Complex estimation of deadlines due to unclear requirements;
• Too dependent on risk analysis.

When to use the Spiral model:

• Projects with unclear deadlines and/or requirements;
• Large-scale projects;
• Project calls for frequent releases;
• The project is of medium/high risk and needs thorough risk evaluation.

Incremental and iterative model

The Iterative and incremental model also follows the iteration-based approach. Same as Waterfall, it starts with planning and ends with deployment, but in the middle, there are several iterations (aka repeated cycles).

With the incremental approach, new modules are added with every new iteration while no (or little) changes are made to the previous modules. The iterative approach, on the other hand, implies that with every iteration, the software evolves and changes are made to all modules.

The pros of the Incremental and iterative model:

• More flexibility than with Waterfall or V-model;
• Implies the collection of client’s feedback and their active participation;
• Relatively easy change management;
• Development consistency paired with adaptability.

The cons of the Incremental and iterative model:

• Can be hard to manage;
• Takes longer time to detect errors since various sections are built separately;
• Can become costly due to constant expansion of the project scope.

When to use the Incremental and iterative model:

• Large-scale projects;
• Projects based on microservices.

Scrum

Scrum is the most popular Agile framework and, alongside Kanban and Extreme Programming, belongs to the Agile group of SDLC models in software engineering. Before discussing Scrum, let’s first refresh our knowledge on Agile.

Agile is a software development methodology based on flexibility and collaboration. Unlike other methodologies, Agile does not prioritize documentation, but places focus on working software instead. This results in quicker delivery and better software quality but also calls for effective project and team management.

Getting back to Scrum – it is a project management framework that proposes an iterative approach to software development and relies heavily on team collaboration. This software development model model consists of “sprints”, which are short (2-4 weeks) iterations. During these iterations, new functionality is delivered, and many tasks can be performed simultaneously. However, it’s not as chaotic as it might sound: with Scrum, every new sprint starts after assessing the results of the previous one and after meticulous planning. 

The pros of the Scrum model:

• High level of quality due to continuous testing and feedback collection;
• Effective team work and strong client’s engagement;
• A very high level of flexibility;
• Good risk mitigation and effective risk management;
• Short time-to-market;
• Increased ROI.

The cons of the Scrum model:

• Requires lots of training and calls for a Scrum Master to be present on a team;
• Does not work well in large teams;
• Is not suitable for projects that need predictability;
• Is not very scalable;
• Possible misalignment of goals within the team.

When to use the Scrum model:

• Projects with high-priority requests and quick turnarounds;
• Projects with small teams;
• Complex projects that can be broken down into smaller parts;
• Projects that have unclear requirements and/or deadlines;
• MVPs and prototyping.

Kanban

Kanban is another SDLC model belonging to the Agile group. Unlike other models, it prioritizes task visualization and offers full transparency regarding the project and the tasks. In Kanban, the iterations usually come in the form of daily sprints, and the tasks are completed based on their level of priority. 

To keep track of all tasks effectively, the Kanban model proposes using specialized tools (boards) such as Trello or Jira. The tasks are distributed across the board based on their priority and each task has a detailed description, an assignee (a person responsible for its completion), deadline, and other valuable information. In this way, any team member can look into any task and see who is responsible for doing it. Also note that Kanban puts emphasis on effective communication and there is no separate planning stage: meaning, the changes can be implemented at any time.

The pros of the Kanban model:

• High flexibility and effective change management;
• High transparency of tasks;
• Better team efficiency and better focus on tasks;
• Quick delivery of new features.

The cons of the Kanban model:

• Is rarely used independently, so you will probably need to combine Kanban with the other methodology;
• Lack of clear deadlines and deliverables;
• Can grow more complex and confusing over time.

When to use the Kanban model:

• Support and project improvement/enhancement;
• Large-scale projects with unclear requirements and/or deadlines that are broken down into smaller parts.

Extreme Programming

Extreme Programming, also known as XP, is quite an interesting SDLC model that prioritizes technical aspects of development and places great emphasis on testing. First introduced in the 90s, XP has become one of the most popular Agile methodologies and encourages developers to go beyond their limits (hence, extreme programming) during the development process.

Same as the models described above, XP consists of repeating iterations. Each iteration has 5 stages:

1. Planning: collection of requirements from the client;
2. Design: with a focus on simplicity, the design strives to bring logic and solid structure to the product;
3. Coding: the process of writing code with the help of such practices as pair programming, collective code ownership, continuous integration.
4. Testing: includes unit and acceptance testing and is performed continuously throughout the development process;
5. Feedback collection: involves communication with stakeholders to learn about the expected goals and value.

One more interesting thing to say about XP is that it follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles, meaning that you need to keep both the code and functionality as simple and intuitive as possible.

The pros of the XP model:

• High quality of software;
• Regular testing;
• High level of communication and collaboration;
• Simplicity and clarity;
• Fast delivery.

The cons of the XP model:

• Unclear deadlines and requirements;
• May lack focus on design;
• Can be quite stressful;
• Lack of documentation;
• Requires a lot of time and resources.

When to use the XP model:

• Projects with a small team;
• Projects that require high flexibility and adaptability;
• Projects with focus on technical capabilities.

Lean

As an opposite to the Extreme Programming model, the Lean methodology can be described as “caring programming”. This model is aimed at providing developers with sufficient time for decision-making and amplifying learning. As well, the Lean methodology promotes “waste elimination”. That means, after every iteration, the team discusses what can be eliminated. The waste may include excessive code, non-effective processes, quality issues, and even bureaucracy. 

In addition to constant learning and careful resource management, this model also places emphasis on fast delivery, respect towards every team member, and maximal delays of commitments. This is done with an aim to experiment and learn as long as possible instead of rushing the processes.

The pros of the Lean model:

• Enhanced collaboration;
• Continuous improvement of the product;
• Great efficiency and flexibility;
• High quality of the delivered product.

The cons of the Lean model:

• Requires team training;
• Measured metrics may be wrong;
• Lack of clear deadlines and goals.

When to use the Lean model:

• Projects with stretchable deadlines and goals;
• Projects that require constant communication between the stakeholders.

How to choose a perfect SDLC model?

As we already discussed above, the choice of a suitable software development lifecycle model will depend solely on your project, business goals, and available resources. Here is what Alexey Minkevich, SoftTeco’s member of the Board of Directors, has to say on the selection of models in software engineering:

Expert Opinion

The choice of a methodology depends on a specific product, project, environment, and the team that works on it. Normally, companies use a combination of methodologies and tools: something is taken from a classic approach, something from Scrum and Kanban, something from Lean. We do the same at SoftTeco. Then, by performing retrospectives, we receive feedback from the team and perform tailoring of the processes and tools so they better fit current goals. As a result, the tools and processes are in the state of continuous improvement as we adapt them to new and/or changing requirements. We add new processes, optimize existing ones, and get rid of the ones that are not effective anymore.

Hence, I can say that the best plan is not the one that was signed a month ago and remains untouched since, but the one that reflects the current environment and is adjusted accordingly.

 Member of the Board of Directors at SoftTeco

Alexey Minkevich