V Model of SDLC (Explain in Detail)

Problem with the Waterfall Model

The testing phase of the model does not begin until after the implementation is finished. However, if you are working on a large project where the systems are complicated, it is simple to miss out on the essential particulars while working on the requirements phase itself. If this happens, the client will receive an entirely incorrect product, and you will likely have to restart the project from the beginning. Alternatively, if you are able to correctly note the requirements for the software you are developing, but you make serious mistakes in the design or architecture of the software, you will need to redesign the entire software in order to correct the error.

Thousands of projects’ worth of assessments have shown that requirements and design phases are where the majority of defects are introduced, accounting for close to half of the total number of defects. In addition, the costs of correcting a defect rise with each successive stage of the development lifecycle. When a problem is found earlier in a product’s life cycle, it costs less to rectify the situation. “A stitch in time saves nine,” as the old proverb goes.

Solution: The V Model of SDLC

In order to address this issue, the V model of testing was developed. According to this framework, there is a testing phase that corresponds to each stage of the software development life cycle.

What is a V Model?

We use a variety of different applications and software programmes on a daily basis, and we frequently become aware of new features being added to the applications we use. However, we never stop to consider how this application was created in the first place, including any and all of the planning and processing that may have taken place. In this article, we will investigate the V Model of SDLC, which is one of the most well-known software development life cycle models, and we will make an effort to comprehend all of the features that it possesses.

The V model is a type of software development lifecycle model (SDLC) that runs each step in a sequential fashion while simultaneously performing parallel testing for each stage of development. Because the diagram of the model looks quite a bit like the shape of a V, the model is commonly referred to as the V model. The V model is an extension of the Waterfall model, with the enhancement that each stage of development will be followed by a testing stage before moving on to the next stage. As a consequence of this, another name for this model is the Verification and Validation model.

The V model is a stringent model because development cannot proceed to the next step until the step before it has been finished. This is ensured by conducting testing after each activity that contributes to development.

The V-model’s of SDLC origin story

Each and every one of the best software development methodologies and frameworks has its own backstory, just like each and every one of the best superheroes. Tim Weilkiens says in his book Systems Engineering with SysML/UML that the V-model’s is that it was initially developed for the German state as a methodology for planning and implementing public sector system development projects. This information is taken from Tim Weilkiens’s book published in 2007.

The opinionated approach taken by the V-model of SDLC, which systematises the software development life cycle in a manner that is comparable to that taken by traditional systems engineering, bears clear evidence of the German influence. After it was determined that the traditional methodology was not a suitable choice for modern software development projects, the V-model 97 was eventually revised and renamed the V-model XT (Extreme Tailoring) in 2004. This came about as a direct result of the conclusion that was reached.

The V-Model 97 served as the foundation for the current V-Model XT, which was introduced in 2004. After seven years, it was discovered that the previous version of the V-Model did not anymore comply with the current state of the art in projects, which served as the impetus for the model’s revision. It was no longer suitable for assisting in the execution of the most recent strategies and procedures.

The V-Model XT is a toolbox that can be customised to fit the requirements of a particular project. It consists of predefined roles, products, and activities. The tailored approach will continue to be logical and consistent as long as the rules are followed.

Let’s understand this V model of SDLC.

The testing phase is connected to each stage of the development process. In addition, the development and testing processes run concurrently, creating a V-shaped pattern as depicted in the diagram. The Verification phase is depicted on the left half of the V shape, while the Validation phase is depicted on the right half. The two halves of the V are joined together by a coding phase, which is what gives it its distinctive V shape. During the verification phase, the static analysis is carried out. This means that, without actually executing the code, it is determined whether or not the current phase satisfies the requirements that were established for it.

During the validation phase, the dynamic analysis is carried out. This means that the code is being executed in order to determine whether or not the current phase satisfies the desired requirements that customers want the software to fulfill.

The Verification Phases of V Model of SDLC

The V Model begins the process of developing software with the verification phase as the first phase. During the phase known as “verification,” the proposed model is checked for accuracy along every conceivable dimension. During this phase, developers will check to make sure that the model satisfies all of the business’s requirements. The verification is carried out in stages, one after another, in a sequential fashion. The following are the various stages:

Business Requirement Analysis: The development has just begun with this very first stage. In this stage, an understanding of the requirements and needs of customers is achieved. During this phase, topics such as what the customer expects from the finished software, what functionalities the customer wants, and other similar topics are discussed. Because there is frequently uncertainty regarding the final product of the software in the minds of both the customer and the developer during this phase, it is without a doubt an extremely important one. Testing for acceptance is carried out during this phase of the process.
System Design: At this point in the process, decisions are made regarding the system’s physical layout. Following the phase in which the requirements are analysed, the phase in which the requirements are finalised is the one in which the complete design of the system is discussed. It encompasses the requirements for the communicating setup as well as the hardware.

Architectural Design: In some circles, this stage is also known as the High Level Design stage (HLD). Following an investigation into the system design, a conclusion is reached regarding the system’s architecture. It is made up of a variety of modules, as well as database tables, UML diagrams, and so on. At this point, an understanding of all of the communications that take place between the internal modules of the system and the outer system has been achieved.
Module Design: This stage is also referred to as the Low Level Design phase (LLD). Following the examination of the high level design, an in-depth discussion of each component of the high level design follows. It is necessary to check both the compatibility of each internal module and their feasibility. During this phase, the unit testing will be carried out.

Coding Phase

During this phase, both the actual coding and the implementation of the system will take place. At this point in the process, consideration is given to the various requirements in order to select the appropriate programming language. Following the writing of the code, it is subjected to a number of different optimizations in order to produce the highest possible level of functionality.

Validation Phase

The following are the various phases of validation:

Unit Testing: During the phase of designing the module, unit testing is carried out. Here, the testing is carried out on each individual module by running the code that was specifically written for that module. It examines each module to determine whether or not it is able to carry out the functions that are required of it. If this is not the case, the bugs are fixed in order to produce functional modules.
Integration Testing: During the phase devoted to the design of the architecture, integration testing is carried out. During integration testing, we check to see whether or not each module functions appropriately when combined with other modules. When we do integration testing, we test the flow from beginning to end by bringing together all of the modules. During this phase, any issues that arose with regard to the modules’ ability to work together were fixed.

System Testing: Testing of the system happens during the phase of designing the system. At this point, the functionality of the entire system is checked by evaluating how well the hardware and software have been integrated with one another and how well they are coordinating with one another. The testing of the system’s interaction with its environment, both internally and externally, using various hardware and software is performed. We fix any and all bugs that are caused by problems with either the hardware or the software.
User Acceptance Testing: Testing for user acceptance typically occurs during the phase devoted to analysing requirements. This part of the process involves testing the system in a user environment. In this stage, any issues that arise in the user environment, such as problems with compatibility with other software that is used in the user environment or problems with the user environment itself, are resolved.

Principles of V Model in Software Engineering

Scalability: Because of this guiding principle, the V model of SDLC can easily scale up to accommodate larger and more complicated projects. Because of this, the V model is now more adaptable to fluctuating levels of cost and complexity.

Large to Small: In the V model, we begin with requirement analysis, which considers all of the facets of the project, such as the system, cost, and feasibility. Next, we move on to system design, which discusses the entire system, including its hardware and software components. After that, we move on to high level design, which discusses all of the modules and how they interact with one another. Finally, we move on to low level design, which discusses each module’s internal workings.
Therefore, we begin with the most significant component (the requirement analysis), and then we work our way down to the least significant component.
Data and Process Integrity: In accordance with this guiding principle, the project should maintain the integrity of both its data and its processes. At no point during the development process should there be any room for ambiguity or repetition in either the data or the process. In addition, there ought to be consistency between the data and the process at every stage of the development process.

Tangible Documents: The necessity of keeping detailed records is emphasised in this particular principle of the V model. At each stage of the development and testing processes, a documentation of the project needs to be created and kept up to date. This documentation will be utilised in the future by users and developers who will have some sort of interaction with the project.
Cross Referencing: According to this guiding principle, each testing phase should directly reference the corresponding development phase, and each development phase should directly reference the corresponding testing phase. As a result, the cross-referencing is made.

When to use V-Model in Software Testing?

The V model is quite comparable to the waterfall model; the primary distinction lies in the inclusion of parallel testing in the V model, which is absent from the waterfall model. As a result, the V model can be used in place of the waterfall model in any circumstance.

Before deciding to use the V model, some important considerations to keep in mind are as follows:

The requirements of the project ought to be crystal clear and unchangeable.
There ought to be transparency regarding the technologies that are being utilised in the project.

Every member of the team that is working on a project ought to have a solid understanding of the prerequisite technologies and requirements for the project.
Because it is difficult to maintain fixed requirements in large projects, the duration of this project ought to be shortened.

V-model strengths

In comparison to the traditional Waterfall methodology, the V-model places a greater emphasis on testing, which is one of its many benefits. Because of its straightforward structure, the V-model is also easy to comprehend and implement. Iterative and flexible software development methodologies have largely taken the place of linear software development methodologies. The V-model, or something similar to it, may still have a role to play in more straightforward software development projects that have clearly defined requirements but typically have a fixed price.

A model that is highly opinionated and disciplined, in which phases are finished in a linear fashion.
This method is effective for more manageable projects where the requirements are well defined and documented.
Easy to comprehend and straightforward in its application.

Because each phase has clearly defined deliverables and a defined process for reviewing them, it is simple to manage.

V-model weaknesses

The V-model, which is an evolution of the Waterfall technique and suggests that a software system’s requirements are fully determined and defined in the conceptual or preparatory stage of the life cycle, has largely lost favour as a methodology in modern software development for the same reason. This is because the V-model is an evolution of the Waterfall approach. That is typically not the case, particularly with regard to more complicated software systems. Before final integration and acceptance, the requirements, design, and evaluation of a software product will frequently go through a number of iterations, and for many software products, iteration is a continuous cycle. Because of this modern reality, the various frameworks that can be found under the umbrella of agile development methodologies are now the ones that predominate in the field of software development.

The shortcomings of the V-model of SDLC can be summed up as follows:

A model that is not considered to be a good choice for the development of complex object-oriented software.
Not suitable for lengthy iterative software projects or those that continue indefinitely.
Inappropriate for use with software whose requirements frequently undergo evolution.

Once the verification and testing phases have begun, it is difficult to make retroactive changes to the design and functionality of the model because of how it is structured.
It is not until the later stages of the linear life cycle that any working software is produced.

Conclusion

The V model, in a nutshell, enables parallel validation and verification at each step. It works very well for projects that have requirements that have been pre-defined and are fixed. However, it is not appropriate for projects that are large and complex and have requirements that are unclear. Because there is verification at each step, we can be certain that each step is carried out correctly. However, when a bug is discovered, it is necessary for us to check all of the steps that came before it. Therefore, the V model of SDLC is an appropriate option for your project if it is not overly complicated and the requirements from the client are crystal clear. If this describes your situation, you should consider using the V model.

References

What is V Model | V Model in Software Engineering | Scaler Topics

What is the V-model software development methodology? (kruschecompany.com)

V-Model in Software Testing (guru99.com)