V-Model In Software Development Life Cycle
Table Of Contents
- 1 Importance of Software Model:
- 2 Role Of Testing Process In SDLC:
- 3 What is Verification?
- 4 What is Validation?
- 5 A small walkthrough of the Waterfall model:
- 6 What is the problem with Waterfall Model?
- 7 So, What is the solution?
- 8 V-model:
- 9 Verification phases of the V-model
- 10 Validation phases of the V-model
- 11 When To Use The V Model?
- 12 What are the Advantages of the V Model?
- 13 What are the Disadvantages of the V Model?
Importance of Software Model:
Plenty of development life cycles are involved in a software project, so selecting the correct one becomes difficult. Software Development Models should be selected wisely by looking at the budget, team size, project criticality, and criticality of the product. Choosing the suitable model will improve the efficiency of your IT projects and manage risks associated with the software development lifecycle.
Looking at the PIC-1 and PIC-2 models, were you able to notice anything? Yes, you are right! PIC-1 shows mistakes in house construction, and the constructed balcony is not helpful as it is practically impossible for one can go there apart from, of course, you are a Spiderman. On the other hand, PIC-2 gives us an idea of practical, well-designed construction. It followed a proper design model before construction, whereas PIC1 has not. Hence, this needs reconstruction to make it correct.
In the case of PIC-1, the reconstruction cost would be more as it is found late in the construction phase. We could have saved/minimized the reconstruction cost and efforts to the optimum level if a correct house model had been followed before construction or if the problem had been detected earlier in the construction phase.
The same rule applies in Software Engineering too. The necessity of correct software testing models in the Software Development Life Cycle (SDLC) is inevitable. Ideally, a Software Development Life Cycle consists of the following essential steps:
5. Testing & Integration
Role Of Testing Process In SDLC:
Testing is an integral part of SDLC and is not a standalone activity. The software model adapted for a project will significantly impact the testing that is carried out. If testing activities do not fit into the correct development lifecycle stages, they will fail to deliver their benefit.
Every development lifecycle’s testing process has two mainly focused parts:
What is Verification?
Verification involves evaluating a work product, component, or system to determine if it meets the development requirements set. The main focus is: “Is the deliverable product built according to the specification and standards?”
What is Validation?
Validation is a process concerned with evaluating a work product, component, or system to determine if it meets the user requirements and needs. The main focus here is: “Is the deliverable product full fill its purpose and provide a solution to the customer’s problem?”
Now that we understand the importance of the testing process let’s now learn about one of the software models that helps improve cost and time efficiency, enhances coordination between a team through defining proper roles for employees, and minimizes risk potential when the project is deployed.
A small walkthrough of the Waterfall model:
Various software models have been developed to achieve the different required objectives. These life cycles range from heavyweight methodologies to lightweight methodologies. In the Waterfall model, the software development process is in a linear sequential flow, which means that any phase in the development process begins only if the previous step is complete. Typically, the outcome of one phase acts as the input for the next phase sequentially; hence, the different SDLC phases don’t overlap.
What is the problem with Waterfall Model?
In the Water Fall model, the testing phase tends to start late in the SDLC lifecycle, i.e. only after implementation is done. Now with this approach, it has been challenging to get feedback passed backwards and very costly if we want to change something that was not well-documented or thought upon in the previous stages.
So, What is the solution?
As they say, “an ounce of prevention is worth a pound of cure!”. In software testing, too, the earlier in the life cycle a defect is detected, the cheaper it is to fix it. The V-model was developed to tackle such problems experienced using the traditional waterfall approach.
Also known as the verification and validation model, the V-model guides where testing needs to begin as early as possible in the SDLC life cycle. Testing is not only an execution-based activity. It also involves various activities that must be covered before the end of the coding phase. V-model corresponds to both testing activities and development activities in parallel.
The following diagram illustrates the different phases in a V-Model of the SDLC.
V- Model of the SDLC ~ Deepti Swain
As shown above, the V-Model contains Verification phases on one side and Validation phases on the other. The implementation/coding phase joins the verification and validation phases in V-shape. Thus it is called a V-Model.
Now let’s deep dive into the V-Model verification and validation phases.
Verification phases of the V-model
1. User Requirements / Requirement Analysis:
Remember the example given at the beginning about house construction; before starting the construction work, an individual needs to gather specific details such as financial options, appropriate location, right contractor for constructing a house, construction and building materials, availability of water and electricity, etc.
Similarly, before starting any software project, the authorities would need to gather certain information, such as having a detailed discussion with customers to know and understand their exact requirements and expectations of the product. Analyses of the gathered requirements need to be done, then refined and come up with accurate, consistent, and unambiguous requirements, mainly in the form of documents called Requirements Specification or Requirements Definition Documents.
This document will capture both the product’s functional and non-functional requirements and the requirement’s priority. The Requirements document is signed-off formally by the stakeholders, which becomes the basis for all further activity. Based on this, the user acceptance criteria test cases are developed. The customers/stockholders, Business Analysts, and Project Managers are the key members of the requirement analysis phase.
2. System Requirements:
Once we have collected the clear and detailed product requirements, the next phase i.e., system requirements begins in earnest. Taking the Requirements Specification inputs in this phase next Functional Requirements Specification or System Requirement Specification begins.
Business Analysts and Developer Leads take the user requirements and turn those into different features that the product should have at the end. During this system requirement phase, teams will revisit and finalize the complete hardware requirements, resources, and communication setup for the product under development.
The system test plan is developed based on the system requirements phase. These requirements are segregated into different features, and features are grouped. Each feature is prioritized in this phase.
i. Global Design / High-Level Design:
The global design phase is also referred to as High-Level Design(HLD) phase. Each feature is again broken down into different modules in this phase. The Architects, Developers, Database designers, and other required members take the elements segregated in the system requirements phase as input and develop an overall high-level technical design.
This high-level design document has all the required technical details, such as hardware, software, Programming language to be used, Database design, applications touch points, etc., clearly defined. They built the HLD so that each module is associated with a specific function. This information allows integration tests to be designed and documented during this stage.
ii. Detailed Design / Low-Level Design:
In the next stage, the Technical Specification i.e. HLD, is taken as the input. Individual developers or the team use it to develop a detailed design of their modules and their interface with other modules. Details about what type of data objects, how the data is to be collected, how the data can be integrated, business rules to be applied, and data storage are all documented in the detailed design Specification. This intricate design specification/document is also referred to as Low-Level Design. In this phase, simultaneously, unit tests can be designed on the internal low-level design of each module.
3. Implementation Phase / Coding Phase:
Programmers or Developers take the Low-Level Design Specification and start the implementation process. The coding of each module designed in the detailed design phase is taken up in the coding/implementation phase.
The coding is performed based on the coding guidelines and standards of the specific language that is being used. The developed code goes through numerous code reviews-feedbacks, and implementation and is optimized for its best performance before the final build is checked into the source repository.
Validation phases of the V-model
As discussed earlier, every development activity will have a corresponding testing activity. And the test phase for a given level begins during the related software development activity. Now let’s discuss different validation phases in detail.
1. Component test Execution/Unit Testing:
The component test execution phase is also referred to as component testing, unit testing, or module and program testing executed during the detailed design phases. This validation testing phase searches for defects in and verifies the functioning of software’s different modules, programs, objects, classes, etc., separately testable.
Most often, component testing stubs and drivers are used to replace the missing software and simulate the interface between the software components to achieve the testing in isolation from the rest of the system. Component testing may include different testing characteristics such as resource behavior, memory leaks, code coverage, robustness testing, etc. The detected defects are typically fixed as soon as they are found without formally recording the incidents.
2. Integration test Execution/Integration Testing:
Primarily integration testing is carried out based on global or high-level design. The development team comes up with the technical specification and a corresponding integration for a test plan. The details are noted of how the modules or programs will be integrated, data that will be passed through the interfaces, and additional integration testing approaches such as Big Bang, Top-Down, Bottom-up, or functional incremental, etc.
Integration testing is performed to expose the defects in the interfaces between components, interactions of different parts or systems such as an Operating System and File system, etc. Here the main focus is on how other modules or components’ interaction works, not the functionality of the individual component.
3. System test Execution/ System Testing:
System testing tests an integrated system/whole system or product to verify that it meets specified requirements. The main goal is to validate that the delivery system meets the design specifications. The testing team performs complete or thorough testing in this phase, including system, functional, and non-functional test cases. Its purpose is to find as many defects as possible and report them.
System tests are generally executed in different development test environments. However, the test environments should correspond to the production environment as much as possible to minimize the risk of environment-specific bugs not being found.
4. Acceptance test Execution/User Acceptance Testing:
Acceptance test execution is associated with the requirements analysis phase. Testers review the Requirement specification and check whether the requirement has enough details to be tested, there is no ambiguity if non-functional requirements are mentioned as well, whether the requirements have been prioritized, and if product risks have been captured. This Test plan is designed focused on conducting tests concerning the user needs, requirements, and business processes.
This determines whether or not the software product/system satisfies the acceptance criteria and enables the users, customers, or other authorized entities to determine whether or not to accept the system.
When To Use The V Model?
V-Model can be used on small- to medium-sized software projects, where the requirements are clearly defined and fixed and not ambiguous. For projects where acceptance criteria are well-defined V-Model, can be preferred. The V-Model is used when ample technical resources are available with technical expertise, and tech stacks and tools are not dynamic.
What are the Advantages of the V Model?
1. As we saw different phases of V-Model, we could conclude that this is a highly-disciplined model, and phases are completed one at a time.
2. Each phase has specific deliverables and a review process, so it is easier to understand, use and manage.
3. Since the testing phases start from the beginning, ambiguities, defects, etc., are identified from the beginning; fixing those becomes more effortless and a cost-effective model.
4. Works well with smaller or medium size software projects.
What are the Disadvantages of the V Model?
1. In Today’s dynamic world, requirements changes may happen very often, whereas the V-model is a very disciplined and non-flexible model; hence, it is not suitable for projects where requirements are at a moderate to high risk of changing.
2. This model is not preferable when projects are larger or complex or have uncertain requirements and high risk.
3. Working software is produced late in the life cycle.
In this article, we have discussed the importance of selecting a correct software model, how V-Model is addressed to solve some of the problems experienced using the traditional waterfall approach, different verification and validation phases of V-Model and where this model is preferable, and where we should avoid this.
There are numerous development life cycles involved in a software project; hence Software Development Models should be selected wisely by looking at the budget, team size, project criticality, the technology used, best practices/lessons learned, tools and techniques, quality of the developer, testers, user requirements, time, and complexity of the project. All these factors play a vital role in the success of any software project.