Software Development Models

There exist a wide variety of software development models, that have evolved to address the evolving challenges facing the software industry. In this post, the following models are reviewed:

• Waterfall Model
• V-Model
• Sashimi Model
• Incremental Model
• Unified Process Model
• Spiral Model

We present a summary of their pros and cos, and the cases for which each model is best suited for. Note that the same models apply to other product (or system) development, therefore, we will use software and product interchangeably in this post. It is worth noting also that, in practice, most organizations combine two or more models in their development process.

First, let’s take a look at the software development phases.

Software Development Phases

The Waterfall Model

The conventional way to conduct software development projects consists broadly of the following steps:

• Requirements: they are gathered from the customer/user at the beginning of the project. Requirements are system-level and independent of the technical solution.
• Architecture & Design: architecture deals with the high level design, and the definition of the interfaces and interactions between subsystems. Then detailed design deals with components, functions, subsystems, etc.
• Implementation: the design is now a coded software that is ready to be tested.
• Testing: it includes verification and validation (V&V) of the product. First, the verification means to check that what we designed is working as expected (unit testing for instance). Then the validation is to check that what we designed and implemented actually fulfills the requirements (system testing).
• Release: the software is released and is ready for deployment. Sometimes, deployment and maintenance are considered to be part of the software development phases.

This sequential process is called Waterfall, as it can be illustrated in the figure above. 

The Waterfall Model

This model is simple to apply and easy to understand. It might be very efficient in the following cases:

• if the requirements are well defined and understood, and
• if the teams are skilled and have experience building similar product/software, and
• if no change (in requirements, design, or else) is required or might occur during development.

In other words, this model is well suited for predictive and repeatable (business-as-usual) projects. On the other hands, the waterfall model has major drawbacks that can jeopardize some projects:

• Once the design started, customers are not allowed to introduce any change in the requirements; no flexibility.
• Design errors and requirements misunderstanding are detected late in the process, during the testing phase, when the error cost is higher.
• The first release comes late in the process, and the customer/user needs to wait for the end of the development to see (hopefully) the product they asked for. No feedback loops to ensure that the implemented product is indeed what the user/customer wants.

In contrast with Agile, the waterfall model is more process-centric rather than customer-centric.

The V-Model

The late detection of design defects and requirements misunderstanding issues, during the testing phase, is one major drawback of the Waterfall model. We need to detect the defects earlier in the process. This can be done by emphasizing the validation tests earlier, which requires more upfront work. In this case the tests and their acceptance criteria must be defined during the requirements specification phase and the design phase. This results in the following V-shape process:

By anticipating the testing phase, the upfront work (requirements and design) become more robust, and we are more confident to hit the development target. However, beside this feature, the V-model has the same cons of the Waterfall model: no flexibility nor customer feedback in the course of the process. Thus, it remains more suited for predictive and repeatable projects.

The Sashimi Model

The Waterfall and V models are not adaptive models: they consist of a sequential process, and every phase relies on the previous one. This makes them ill-suited for projects where the schedule needs to be shortened. Furthermore, they might results in poor resource utilization: for instance, during the design phase the implementation team and testing team will be waiting and are not be able to work on the project.

In order to shorten the development time, and involve the teams with different skills in the development without waiting, the Sashimi model was introduced: it is based on the Waterfall model, but a phase can start before the previous phase ends as shown on the figure. The drawback of this process it that it may result in rework, and waste of time.

Incremental Model

Another variation of the waterfall model is the incremental model. In this case, the software/product is divided into several parts that can be built in an incremental way. This may allow overlap between increments (parallel work flow) to improve resource utilization.

Some project are based on previous projects already done (Kaizen or next generation), in this case most of the upfront work and design are already defined. Implementation can be done in an incremental way in order to accelerate the development and deliver value earlier.

Using the incremental model, the organization may profit from early value delivery, and get feedback and make necessary changes between increments if possible. The weakness of this model is that it may results in rework and cost more. Note that since the incremental model allows for some adaptivity in the process, it is used on Agile development practices.

The V, Sashimi and Incremental models can be considered as evolved versions of the Waterfall model. They work best for predictable projects, with skilled and experienced teams. The following two models (Unified Process and Spiral) are more suited for high-risk projects.

The Unified Process

If you are dealing in a bigger and riskier project, where the requirements are not all known early, the chances of success are lower. In this case you may consider the unified process (UP): a framework that can incorporate other methods and models. Using iterative and incremental development, the UP is focused on the risk mitigation, which increases chances of success. It is an adaptive and flexible approach, centered mainly on the architecture and use cases.

The Unified Process divides the project into four phases (with overlap):

• Inception
• Elaboration (milestone)
• Construction (release)
• Transition (final production release)

For more details about these phases check out the Wikipedia Article about UP.

Adopting UP framework, the organization may profit from earlier value delivery. However, it is a rather complicated framework, that consumes more resources. It is ill-suited for smaller projects.

The Spiral Model

For very large projects, with very high risk, the spiral model is recommended. It is a cyclic model that consists of four steps:

• Determine objectives
• Identify and resolve risks
• Develop and test
• Plan the next iteration

The spiral model is very adaptive, iterative and incremental. It is risk-driven, this suitable for high risk projects (such as aerospace big projects). It can incorporate other models.

Further readings

Coursera MOOC, “Software Development Processes and Methodologies“, University of Minnesota.