<img height="1" width="1" src="https://www.facebook.com/tr?id=1599948400306155&amp;ev=PageView &amp;noscript=1">
(EU) +49-711-2195-420

(US) 1-866-468-5210

Blog

Software Development with Waterfall/V-model

How to develop hardware with Waterfall / V-ModelIn software development, the Agile method is gaining more and more traction, with even safety-critical product developers transitioning to this iterative and incremental framework. Hardware, on the other hand, is still mostly developed using the tried and tested Waterfall or V-model method.

Basics of the Waterfall/V-model development model

The Waterfall methodology (V-model) was the first comprehensive design methodology (framework) and has been in use since the 1960s for large scale projects. IBM was among its first users in the early days. Due to continued refinement by companies like Microsoft, it is still in use today and many different variations of it exist.

However, fundamental deficiencies or limitations in the Waterall approach remain. Namely, Waterfall's rigid structure of linear development means that it is difficult to address changes, and adapt to changing requirements using this sequential method. That's exactly what prompted the inception of Agile for software development, as software requirements are likely to change during the multi-year process of product development.

Today, the Waterfall methodology is typically used in large-scale projects that go on for years. Waterfall has been used extensively in safety-critical sectors such as defense, aviation, and railway.

A pure Waterfall model works well in situations where the original design and requirements are unlikely to change and where there is an increased need for predictability. It's a good approach when there is a need to predict how different parts of a system (that are not expected to change during the course of the project) might interact, such as in the development of hardware products.

We often see in HW development that each part of the overall system is developed independently and in parallel. Final integration only occurs during the last phase of the project, once each component has been tested and debugged by their respective development team.

There are a number of different variations of the Waterfall/V-model, however they typically follow the same sequence of steps from planning (initial high level requirements definition) through development (of each component) through to the eventual testing, integration, and release phase.

waterfall-v-model.png

Phases of development with Waterfall/V-model

  1. Requirements analysis & planning – The collection, analysis, and prioritization of product feature requirements is critical to the delivery of an end product that meets customer needs.
  2. Design – System architectural plans that define both hardware and software elements
  3. Implementation – Once requirements & design plans are locked down, the product is being built (bear in mind that requirements should not be changed during or after this phase!)
  4. Testing – After the product that fits requirements is completed, it is tested thoroughly
  5. Integration or distribution – Once tested and vetted, the component is integrated into the final product, or the final product is approved for distribution to the customer
  6. Maintenance – Typically performance-related operations & improvement tasks.

One of the greatest strengths of the Waterfall methodology is also its Achilles heel: upfront design can be a big problem. Upfront design doesn't allow room for changing requirements, and involves an assumption that the design perfectly suits requirements.

While this does ensure that the development project is well defined and therefore reduces the chance of problems arising later, it completely ignores the fact that most companies really don’t know what they want at the beginning of a project. And even if they do, the development phase might take very long and their requirements may well change during the course of delivering the product. The Waterfall methodology does not manage changing requirements well, which is why it is best suited to hardware projects.

Waterfall/V-model, Agile or Agile-Waterfall Hybrid?

Choosing the right methodology for a development project is always a crucial (and complex) challenge. Developing with the Waterfall/V-model method enables you to see the deliverable results right after the planning phase, making it a very predictable approach.

It is way different to Agile, which takes an iterative and incremental approach to make sure changing requirements are accommodated during the course of development. It can can greatly shorten delivery time and has the potential to better fulfill requirements (even those that are unkown in the beginning, as the product is being planned) – but that also means things could get out of hand with the addition of multiple features, significantly changing product requirements, etc. 

Often, developers of products with hardware and software  components choose the Agile-Waterfall Hybrid method. Agile-Waterfall Hybrid can help you shorten the development cycle while keeping well-defined project frames – including budget and time of delivery.

Related reading: When, Why, and How to use the Agile-Waterfall Hybrid Model

To be able to work with the Agile-Waterfall Hybrid method, your team will need strong collaboration and probably some training to understand the fundamentals of both methodologies.

codeBeamer ALM supports Agile, Waterfall and Agile-Waterfall Hybrid development, so it's a suitable development platform for any software, or software-heavy hardware project.