The V-Model in Software Development

The V-model is a type of Software Development Life Cycle (SDLC) model where process executes in a sequential manner in V-shape. It is also known as Verification and Validation model. It is based on the association of a testing phase for each corresponding development stage.

#book #management

Last update: 2022-05-07

Table of Content

The V-Model#

The V-model is a type of Software Development Life Cycle (SDLC) model where process executes sequentially in V-shape. It is also known as Verification and Validation model, based on the association of a testing phase for each corresponding development stage.

Verification: It involves static analysis technique (review) done without executing code. This is the process of evaluation of the product development phase to find whether specified requirements meet.
Validation: It involves dynamic analysis technique (functional, non-functional), testing done by executing code. Validation is the process to evaluate the software after the completion of the development phase to determine whether software meets the customer expectations and requirements.

Stages#

Each Development stage will have a Verification stage and a Validation stage.

Requirements Analysis

Requirements of the System: are collected by analyzing the needs of the users, through interviews, questionares, document analysis. This step’s output is User Requirements Document.
User Requirements document: will typically describe the system’s functional, interface, performance, data, security as expected by users; used by Business Analysts to communicate their understanding of the system to the users.
Verification: is done by the users who will review UR documents carefully and confirm the Requirements.

User Acceptance Testing

Validation: User Acceptance Test (UAT) Plans are composed by business users, 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.

System design

Software Requirement Specification document

System engineers analyze and understand the business of the proposed system by studying the User Requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. It plans out how the system components will be and how they will interact with each other to run the entire system.

This document contains the general system organization, windows, menu, entity diagrams, and some example business scenarios to help understanding about the system.

Verification

System engineers and Business Analysts work togerther on UR and SRS. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the User Requirement document is edited accordingly.

System testing

Validation: System Test Plans are composed by client’s business team, to ensure that expectations from application developed are met, including functional and non-functional requirements. Load and performance testing, stress testing, regression testing are some type of system testing.

Architecture design

High-level Design document: System design is broken down further into modules taking up different functionalities. The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood.
Verification: System Architec and senior developer in team will review the documents to find out any problem, such as error in estimation, missing corner-cases, exception handler, mis-matched interface.

Integration Testing

Validation: Integration Test Plans verify that units created and tested independently can coexist and communicate among themselves. Test results are shared with customer’s team.

Module Design

Low-level Design document: 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. It contains detailed functional logic, interface, or pseudocode, such as database table; API input, output and step of algorithms.
Verification: Document is reviewed by developer before implementation to make sure the argorithms is kept simple and easy to debug. This step can help to optimize the design.

Component testing

Validation: Module Test Plans is excecuted by developers or by an automated system that checks the functional requirements of the module, including the input, outputs.

Coding

An actual implementation of a code.

Verification: Code Review is held in team to check the implementation. That activity helps to correcty mis-leading function, or any potential problem. Developers must folow rules of conding convention, and design pattents.

Unit testing

Validation: Unit Test Plans is excecuted by developers or by an automated system that only checks the function of the smallest and independent blocks, such as a function.

Application#

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.

The most suitable scenarios:

Requirements are well-defined, clearly documented and fixed
Product definition is stable
Technology is not dynamic and is well understood by the project team
The project is short

Advantages#

Simple and easy to use: The model has defined stages with expected input, output, and action.
Time save: Design and testing plan can be done together in early stage
Proactive defect tracking: Verification can help to find potential issues in early stages

Disadvantages#

Very rigid and least flexible: A next step starts when the previous step is verified. Any change in a top stage may lead to changes in lower stages and whole process can be affected
No prototype guidance: No initial prototypes of the software are produced. If a prototype