Verification & Validation

Verification and Validation (or V&V in short) is the process of investigating and checking in which degree does software satisfy specifications and standards given because of the necessities of the project, and also makes sure it can successfully complete the tasks it was intended to do.

Verification and Validation are two completely different things

For more information about definitions and diferences you can check this link

Verification (Are we building the product right?): It is the process of making sure the software verified can do the tasks imposed without any bugs. This can be resumed in making sure it has no errors, no weird bugs and functions as it should.

Validation (Are we building the right product?): It is the process of making sure that the software can actually fulfill the requirements imposed to it. It is the process of checking that the software created is actually the software we want or need.

To verify and validate there is a common, pretty general but recommended procedure to follow.  Inside the software life cycle, the Verification has to be followed by the Validation. Meaning we first verify if our software actually works and then we validate that our software is actually useful. If we follow the steps of software creation in the image below we can see where is the verification and the validation taking place.

International standards for V&V of Software

To properly and effectively verify and validate your software there are very helpful global standards you would want to follow in order to reach a global acceptance in your procedures and quality of software. There is a great quantity of standards that will help in the application of V&V to any software (ISO 17029, IEEE 1012 and IEC being the most famous ones) each of them varying in methodologies to standardize the process of V&V.

Planning V&V

Having a chosen standard to have for your verification and verification processes is one thing, but another important aspect of V&V is the planning of implementation you will follow to integrate it to the software.

It is very important to have a plan for V&V at the very start of the development, and so it is recommended that you write down a verification and validation planning document containing the details about what is to be tested and how. This is called a master plan.

 Below there are some steps you can follow to build such document.

  1. Describe and set the objectives: Defining the overall project objectives, milestones and activities for teams to do is a key step in the start of the document.
  2. Define the components you are going to test: Listing the software features you’re going to test in the document will serve as a guide for everyone involved on what needs to be verified and validated. It is also important that you specify tests ranging from a small component to a cluster of them.
  3. Define the components you are NOT going to test: There may be instances of components in which testing is really expensive and not very rewarding, so it may be better to skip extensive testing for the components that seem of this type. Including them in the document will clear misconceptions and set on-point expectations about the process
  4. Define how can the components be verified and validated: Have a clear definition of what makes a test case pass and what makes it fail the verification and validation. What criteria they need to pass or what cases should they be able to manage to handle.
  5. Define procedures in case of failure: Often the components can fail some tests. It is important to settle what happens when we are presented with such condition. Can other tests be executed? Do we need to stop and adjust the component before continuing?

With these steps a solid V&V plan will be created ready to be followed, but executing a plan is always a totally different challenge than creating it. AS the old saying says “No plan survives the contact of with enemy”. Administrating a V&V plan will then be our next step.

Adopting a V&V plan

Adopting V and V on a project requires the development of a team and system to capture project requirements, ensure they are understood, and distributed to all staff. The process must be embedded in design and construction processes. There is little value in establishing a V and V team located separately, producing paperwork that remains unused.  Communication is critical.

The requirements list allows monitoring of progress against specifications and criteria. It provides site engineers with a tool to allow them to check the construction and provides a baseline against which changes are evaluated. Site engineers record the emerging evidence showing compliance with the requirements. This is done through site inspections, test reports, measurements, and photographs.

For more administration tips visit here

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Crea tu sitio web con WordPress.com
Empieza ahora
A %d blogueros les gusta esto: