Also known as Verification and Validation model, the V Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage. This means that the V Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. There are Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase joins the two sides of the V Model. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction, respectively. This is a highly-disciplined model and the next phase starts only after completion of the previous phase.
V Model application is almost the same as the waterfall model, as both the models are of sequential type. Requirements have to be very clear before the project starts, because it is usually expensive to go back and make changes.
- Should be used for small to medium sized projects where requirements are clearly defined and fixed.
- High confidence of customer is required. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.
The origin of V Model
One of the major handicaps of waterfall STLC model was that, defects were found at a very later state of the development process, since testing was done at the end of the development cycle. It became very challenging and costly to fix the defects since it were found at a very later stage. To overcome this problem, a new development model was introduced called the “V Model”. The V Model gets its name from the fact that the process is often mapped out as a flowchart that takes the form of the letter V. Introduction of V Model actually proved the implementation of testing right from the requirement phase.
Verification Phases | Validation Phases
There are several Verification & Validation phases in the V Model, each of these are explained in detail below,
- Verification: Business Requirements analysis >> Functional Specifications >> High-level Design >> Detailed Design
- Validation: Acceptance Tests >> System Testing >> Integration Testing >> Unit Testing
- Join: The Coding phase
Business Requirements analysis | Acceptance Tests
In requirements analysis phase, the first step in the verification process, the requirements of the system are collected by analyzing the needs of the user(s). The requirements are collected, analyzed and studied. How the system is implemented is not important here, but what the system is supposed to do, is important. It involves detailed communication with the customer to understand and document his/her expectations and exact requirement in Software Requirements Specification document. This document would serve as the guideline for the system designers in the system design phase. This is a very important activity and needs to be managed well, as most of the customers are not sure about what exactly they need. However it does not determine how the software will be designed or built.
User Acceptance Test (UAT) Plans are developed during this stage as business requirements can be used as an input. It involves testing the product in user environment. UAT is performed in a user environment that resembles the production environment, using realistic data. UAT verifies that delivered system meets user’s requirement and system is ready for use in real time.
Functional Specifications | System Testing
Once you have the clear and detailed product requirements, it is time to design the complete system. Systems design is the phase where system engineers analyze and understand the business requirements and figure out possibilities and techniques by which the user requirements can be implemented. The software specification document which serves as a blueprint for the development phase is generated.
The system test plan is developed based on the functional specifications. System Test ensures that expectations from application developed are met. The whole application is tested for its functionality, inter-dependency and communication. System Testing verifies that functional and non-functional requirements have been met. Load and performance testing, stress testing, regression testing, etc., are subsets of system testing.
High-level Design | Integration Testing
Architectural specifications are understood and designed in this phase. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. The system design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD). It provide overview of solution, platform, system, product and service/process. The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage.
With this information, Integration Test Plans can be designed and documented during this stage. Integration tests are performed to test the coexistence and communication of the internal modules within the system. These tests verify that units created and tested independently can coexist and communicate among themselves.
Detailed Design | Unit Testing
In low-level design (LLD) phase, the detailed internal design for all the system modules is specified. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo-code. It is important that the design is compatible with the other modules in the system architecture and the other external systems.
Unit Test Plans (UTPs) can be designed at this stage based on the internal module designs. A unit is the smallest entity which can independently exist, e.g. a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/units. It helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing. This testing is basically performed by the development team.
The Coding Phase
The actual coding of the system modules is taken up in the Coding phase. The best suitable programming language is decided based on the system and architectural requirements. The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.
Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
The advantages of V Model
The main advantage of V Model is that it is very easy to understand and apply. The simplicity of this model also makes it easier to manage.
- Simple and easy to understand and use.
- Highly-disciplined model and phases are completed one at a time.
- Works well for smaller projects where requirements are very well understood.
- Easy to manage due to the rigidity of the model. Each phase has specific deliverable and a review process.
- Testing activities like planning, test designing happens well before coding so ambiguities are identified from the beginning. This saves a lot of time. Hence higher chance of success over the waterfall model.
- Easy to manage as each phase has well defined objectives and goals.
The disadvantages of V Model
The disadvantage is that the model is not flexible to changes and just in case there is a requirement change, which is very common in today’s dynamic world, it becomes very expensive to make the change.
- High risk and uncertainty.
- Not suitable for the projects where requirements are at a moderate to high risk of changing.
- Once an application is in the testing stage, it is difficult to go back and change a functionality.
- Software is developed during the implementation phase, so no early working prototypes of the software are produced until late during the life cycle.
- If any changes happen in midway, then the test documents along with requirement documents has to be updated.
Criticism & Support
A common practical criticism of the V Model is that it leads to testing being squeezed into tight windows at the end of development when earlier stages have overrun but the implementation date remains fixed. But supporters of the V Model argue that it has evolved over time and supports flexibility and agility throughout the development process. They argue that in addition to being a highly disciplined approach, it promotes meticulous design, development, and documentation necessary to build stable software products.
There are numerous development life cycle models but V Model has gained acceptance because of its simplicity and straightforwardness. The choice for a particular model depends on multiple project factors like customer requirements, cost, budget & timelines.