V Model

The V Model is an enhanced version of the classic waterfall model whereby each level of the development lifecycle is verified before moving on to the next level. With this model, testing explicitly starts at the very beginning, i.e. as soon as the requirements are written. Here, by testing we mean verification by means of reviews and inspections, i.e. static testing. This helps in identifying errors very early in the lifecycle and minimizes potential future defects appearing in the code later in the lifecycle.

Each level of the development lifecycle has a corresponding test plan. i.e. as each phase is being worked on, a test plan is developed to prepare for the testing of the products of that phase. Be developing the test plans, we can also define the expected results for testing of the products for that level as well as defining the entry and exit criteria for each level. In the V-Model the test activities are spelled out to the same level of detail as the design activities. Software is designed on the left-hand (downhill) part of the model, and built and tested on the right-hand (uphill) part of the model. Note that different organizations may have different names for the development and testing phases. The correspondences between the left and right hand activities are shown by the lines across the middle of the V, showing the test levels from component testing at the bottom, integration and system testing, and acceptance testing at the top level.

Advantages

Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Time concern in comparison with the waterfall model is low or even we can say 50% less. Works well for small projects where requirements are easily understood. Utility of the resources is high.

Disadvantages

Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesnt provide a clear path for problems found during testing phases.

When to use this model

As per my knowledge I personally think / feel where time and cost is the constraints of the project then we can use such models for quick and cost effective delivery. In comparison with waterfall model more or less same but the activity of testing starts very early, which leads to less time, and cost of the project.