In this topic, we described about the below sections -
Let us assume there is a project development going on using waterfall model. If any defects found during the later stage of development and those defect requires a major or design change, then its becoming challenging and costly to fix the defects. Because the project almost comes to an end. To resolve this problem, there is a requirement to define new SDLC model. V-model defined as a solution to the above problem.
What is V-Model?
V-Model is an extension of Waterfall model where the model execution process flows in a "V-shape". V-model specifies series of phases that executes in sequential, one at a time until the project completes. This model is also known as "Verification and Validation model".
V-model is now the linear, unique developement model and mostly used model in software development life cycle. Testing phases planned in parallel with development phase that are supposed to be tested against and joined at the bottom by actual coding process.
Each phase of the development has its corresponding testing phase. Both development and testing activities performs together (parallelly). Similar to the waterfall model, the next phase starts only when the current phase is completed.
When V-Model used?
V-model used when -
- Requirements are well defined, clear and documented.
- Client doesn't want last minute surprises in testing.
- Acceptance criteria is well defined.
- Project is short to medium.
- Technology and tools are static.
The development and testing phases ran in parallel in this model for every step. Each step has its corresponding development, testing phases and moves to the next step once the both phases completed. Then only the next step starts.
- Verification - Invloves in static analysis with code execution The evolution procedure carried out during the development to verify all the requirements covers in coding or not.
- Validation - Invloves dynamc analysis (both functional and non-functional) and testing is performed by code execution. The validation can be done once the development completed.
Both verification and validation are combined to make the v-model is fully functional.
Let us discuss about the different phases of Verification and Validation in detail.
There are several Verification phases in the V-Model and each one is explained in detail below -
- Requirement Analysis Phase - Requirement Gathering is the most important and first phase of SDLC. In this phase, business analyst and project manager participate in the meetings with client to gather the requirements.
- Client is the owner of the product and provides the information about what to build, who will use it or purpose of it to all the participants.
- Business analyst is the person who gathers the high level requirements from the client and document them in the form of business requirements
- Project Manager can located at onshore/offshore who is going to handle the project.
Business requirements are generally documented in Business Requirement Document (BRS). Note that the BRS document name may gets changed based on the naming conventions defined in the project and name varies from project to project.
- System Design Phase - Invloves in designing the system with the entire hardware & the setup is constructed for product development.
- Architectural Design Phase - Invloves in designing the system to more detail level with different functionalities. The data transfers between the internal and external modules are also identified in this phase.
- Low-level design or Module Design - Invloves in breaking down the entire product development into smaller modules where each module that requires modifications is specified. This process is also called as Low-Level Design (LLD).
The different phases of validation in V-model are listed below -
- Unit Testing - Involves in performing unit testing for the individual modules modified/developed. Unit testing involves in eliminating the bugs at the independent modules level.
- Integration Testing - Once the unit testing completed, the integration testing performs testing by integrating modules in the system. This testing is done in the architecture design phase.
- System Testing - Invloves in testing performs on the entire product in conjunction with the functionality and merging of different modules into a single unit.
- User Acceptance Testing - Involves in testing that is carried out in front of the user or in a user environment where the product is going to set up. The UAT tests whether the product is ready to work in the real world.
- More systematic model and all the phases are completed at once.
- Development and progress is very organized and systematic.
- Ideal for time management.
- Best suitable for the smaller projects.
- Simple, easy to understand and use.
- Easily managable.
- Avoids more bugs.
- Downward flow of the defects can be avoided.
- Lacks adoptability and flexibility.
- Timeline restrictions.
- Very strict and least flexible.
- Due to its rigidity, it is less flexible.
- Not suitable for big, complex projects.
- Not suitable for the project where the requirements are not clear.
- No need to produce prototype.
- If there are any changes that come in the middle, then all the documents needs to be updated again.
- No software is produced at the intermediate phases and only produces at the end.
- Exceedingly difficult to goback and change the functionality.
- No risk analysis.
- Both test and design documents should be updated when design changes.