In V- the model, the testing is done in parallel with the development, business planning, and each phase of the Product life cycle. For each phase of development, there is some level of testing involved.
V model is known as Verification and Validation Model.
Verification: It is the process of evaluation at the Product development phase to check whether the requirement meets or not.
Validation: This is the process done after the product development. At this stage, the evaluation is done to check if the product meets the customer’s requirements or not.
Overall, In the custom software development company the V model contains verification on one side and validation on the other side. Verification and validation are joined by the coding phase of the product development in V- shape. That is where the term “V” comes from.
Design Phases:
- Requirement Analysis: In this phase, the information about the requirement and expectations of the customer is gathered. This involves meetings with the customers and then deciding the design of the product.
- System Design: At this stage, the various mediums of communication and hardware requirements of the product are designed.
- Architectural Design: At this stage, the Product functionalities are divided into different modules, which perform different scenarios. Data transfer between the modules and communication with other systems is also decided in this phase.
- Module Design: In this phase, the detailed designing of each module is done, also known as Low- Level Design.
Testing Phases:
- Unit Testing: This testing is done on the Unit (module) level. This is done to eliminate bugs at the Unit/Code level.
- Integration Testing: This type of testing is done in the Architectural Design phase. Here, different modules are integrated, and then the whole system is tested.
- System Testing: This is the Complete Testing of the Application, which involves functionality, communication, and inter-dependency. Here, the functional and non-functional requirements of the developed application are done.
- User Acceptance Testing: This testing is done in an environment that resembles the Actual Production environment. Here, the verification of the delivered system with the system which was required is done. UAT is done to check if the system is ready for customer usage.
Coding Phase:
In the coding phase, the best-suited system and the programming language are decided as the product requirement. The coding then starts and the code is reviewed many times for optimal performance. Then the final code is delivered to the repository.
Principles of V-Model:
- Large to Small: Every large to a small level of testing is done in the hierarchical order. As each phase of the Product development is completed, the product gets more detailed, precise, and refined.
- Data/Process Integrity: This Principle states that a successful design requires the cohesion of both data and processes.
- Scalability: This model has the flexibility to accommodate any project of any size and complexity.
- Cross Referencing: Direct relation between the requirement and their testing, is called cross-referencing.
- Tangible documentation: Every project requires a document. This document is required by both the development and the support team. Documentation is used for the maintenance of the application once it is available to the end-user.
V- Model Advantages and Disadvantages:
Advantages:
- It is a much more disciplined model and each phase is completed at a time.
- Works brilliantly where the product requirements are well understood.
- Easy to understand and simple to the user.
- Each phase of the product design has specific deliverables and a review process.
Disadvantages:
- Not suited for complex projects.
- Not suitable for projects where the risk of requirement changes is high.
- The final product is not delivered during the life cycle.
- It involves high risk and investment.
- Not a good model for long-term projects.
V- Model Application:
Given below are the best scenarios where we can use the V-Model:
- Product requirements are well-defined, documented, and explained.
- The technology used on the product is not dynamic and should be understandable by the team.
- The project is short and not heavy.
- There shouldn’t be any undefined requirements for the product.