Basics of Waterfall/V-model development model
The Waterfall methodology (V-model) is widely accepted as being the first comprehensive design methodology (framework) and has been in use since the 1960’s for large scale projects, most notably by IBM in the early days. Continual refinement of the Waterfall approach by companies like Microsoft has meant that it is still in use today and in many different variations. However fundamental deficiencies in the Waterall approach remain and a lack of process management has resulted in many organisations looking for alternative solutions to become more Agile.
Typically the Waterfall methodology is used to develop large scale projects of multi-year duration and has been used extensively in both the defence and the space industries as well as commercial projects. A pure Waterfall model works well in situations where the original design and requirements are unlikely to change and where engineers need to predict how the different parts of a system might interact; such as in hardware development. Each part of the overall system is developed independently and in parallel with the final integration occurring during the last phase of the project, only after each piece has been tested and debugged by the developing team.
There are a number of different variations of the Waterfall/V-model, however typically the phases of development flow from the initial high level requirements definition down through to the eventual integration and release.
The phases of development with Waterfall/V-model are as follows:
- Requirements Analysis – Critical to delivery of an end product that meets the requirements of the client is the collection of product feature requirements and prioritizing these requirements, transforming them into project demands
- Design – System architectural plans, defining both hardware and software elements, taking into consideration the system capacity
- Implementation – Product build
- Testing – Independently tested
- Installation – Once tested and vetted it is approved to distribute to customer for intallation + testing
- Maintenance – Typically performance related improvements
One of the greatest strengths of the Waterfall methodology is also its Achilles heel: the upfront design can be a big problem. Firstly an upfront design involves the assumption that the design is what the product will be. While it does ensure the development project is well defined and therefore reduces the chance of problems arising later, it completely ignores the fact that most companies don’t know what they want at the beginning of a project. The Waterfall methodology does not manage changing requirements well, which is why it is best suited to projects where requirements are unlikely to change.
Waterfall/V-model, Agile or Agile-Waterfall Hybrid?
It is often a question which methodology to use. Developing with Waterfall/V-model enables us to see the deliverable results at the end of the whole cycle and therefore it is often used by developing hardware components. Agile can greatly shorten the delivery time, and collect feedback in early stages to better fulfill the requirements and therefore Agile is mainly used for software development. If you are not sure what to use, you can start with an Agile-Waterfall Hybrid method. The Agile-Waterfall Hybrid solution can help you to shorten design, analysis and planning, but define project frames – including budget and time of delivery, as well as compliance with standards. Working with Agile-Waterfall Hybrid, your team might need strong collaboration and probably some training to understand the fundamentals of both methodologies.
codeBeamer ALM supports Agile, Waterfall and Agile-Waterfall Hybrid development. Whichever method you choose to use, codeBeamer ALM software is a suitable platform for your development projects.