The V-Model is a unique, linear development methodology used during a software development life cycle (SDLC). The V-Model focuses on a fairly typical waterfall-esque method that follows strict, step-by-step stages. While initial stages are broad design stages, progress proceeds down through more and more granular stages, leading into implementation and coding, and finally back through all testing stages prior to completion of the project.
In this article we'll examine just what the V-Model actually entails, and why it may (or may not) be suitable for certain types of projects or organizations.
Some more specific takes on SDLC include:
|Rapid Application Development||Test-Driven Development||Waterfall Model|
|Iterative Model||Extreme Programming||Scaled Agile Framework|
|Agile Model||Scrum||Rational Unified Process|
|Big Bang Model||Software Development Life Cycle||Conceptual Model|
|Kaizen Model||Kanban Model||Spiral Model|
Much like the traditional waterfall model, the V-Model specifies a series of linear stages that should occur across the life cycle, one at a time, until the project is complete. For this reason V-Model is not considered an agile development method, and due to the sheer volume of stages and their integration, understanding the model in detail can be challenging for everyone on the team, let alone clients or users.
To begin, it's best to visualize the rough stages of the V-Model, as seen in the diagram below.
Image courtesy of Wikipedia.org
The V-shape of the V-Model method represents the various stages that will be passed through during the software development life cycle. Beginning at the top-left stage and working, over time, toward the top-right tip, the stages represent a linear progression of development similar to the waterfall model.
Below we'll briefly discuss each of roughly nine stages involved in the typical V-Model and how they all come together to generate a finished product.
During this initial phase, system requirements and analysis are performed to determine the feature set and needs of users. Just as with the same phase from the waterfall model or other similar methods, spending enough time and creating thorough user requirement documentation is critical during this phase, as it only occurs once.
Another component unique to the V-Model is that during each design stage, the corresponding tests are also designed to be implemented later during the testing stages. Thus, during the requirements phase, acceptance tests are designed.
Utilizing feedback and user requirement documents created during the requirements phase, this next stage is used to generate a specification document that will outline all technical components such as the data layers, business logic, and so on.
System Tests are also designed during this stage for later use.
During this stage, specifications are drawn up that detail how the application will link up all its various components, either internally or via outside integrations. Often this is referred to as high-level design.
Integration tests are also developed during this time.
This phase consists of all the low-level design for the system, including detailed specifications for how all functional, coded business logic will be implemented, such as models, components, interfaces, and so forth.
Unit tests should also be created during the module design phase.
At this point, halfway through the stages along the process, the actual coding and implementation occur. This period should allot for as much time as is necessary to convert all previously generated design and specification docs into a coded, functional system. This stage should be fully complete once the testing phases begin.
Now the process moves back up the far side of the V-Model with inverse testing, starting with the unit tests developed during the module design phase. Ideally, this phase should eliminate the vast majority of potential bugs and issues, and thus will be the lengthiest testing phase of the project.
That said, just as when performing unit testing with other development models, unit tests cannot (or should not) cover every possible issue that can occur in the system, so the less granular testing phases to follow should fill in these gaps.
Testing devised during the architecture design phase are executed here, ensuring that the system functions across all components and third-party integrations.
The tests created during system design are next executed, largely focusing on performance and regression testing.
Lastly, acceptance testing is the process of implementing all tests created during the initial requirements phase and should ensure that the system is functional in a live environment with actual data, ready for deployment.