Rol de Verificación y Validación (V&V) en SDLC

La verificación es el proceso de verificar que un software logre su objetivo sin ningún error. Es el proceso para asegurar si el producto que se desarrolla es correcto o no. Verifica si el producto desarrollado cumple con los requisitos que tenemos. La verificación es una prueba estática. 

La validación es el proceso de verificar si el producto de software está a la altura o, en otras palabras, el producto tiene requisitos de alto nivel. Es el proceso de comprobar la validez del producto, es decir, comprueba que lo que estamos desarrollando es el producto correcto. es una validación de los productos reales y esperados.

Puede encontrar una descripción detallada de Verificación y Validación aquí: https://www.geeksforgeeks.org/differences- between-verification-and-validation/

Los diversos roles de Verificación y Validación (V&V) en SDLC en el proceso de prueba de software se detallan a continuación:

1. Análisis de trazabilidad: 
la trazabilidad se puede definir como una propiedad que describe el grado en que se puede rastrear hasta su punto de origen. También describe la capacidad de establecer una relación predecesor-sucesor entre un producto de trabajo y otro. Nos ayuda a rastrear cada requisito de software hasta sus requisitos originales del sistema establecidos en la actividad de concepto. La cuestión es asegurarse de que cada requisito satisfaga correctamente los requisitos del sistema y que no se incluyan cosas adicionales de requisitos de software. En esta técnica, también determinamos si los requisitos derivados son consistentes con los objetivos originales, las leyes físicas y las tecnologías descritas en el documento del sistema.
 

2. Análisis de la interfaz:
es el análisis detallado de las especificaciones de los requisitos de la interfaz en el ciclo de vida del desarrollo del software. También nos ayuda a identificar las interfaces entre las aplicaciones para determinar los requisitos para garantizar que los componentes interactúen entre sí de manera efectiva. Los criterios de evaluación son los mismos que para la especificación de requisitos, ya que nos ayuda a determinar los requisitos de interoperabilidad. El objetivo principal de este análisis está en las interfaces entre el software, el hardware y el usuario.
 

3. Análisis de criticidad: 
la criticidad se otorga a todos y cada uno de los requisitos de software y cuando los requisitos se combinan en funciones, la criticidad combinada de los requisitos forma la criticidad de la función agregada. El análisis de criticidad se actualiza periódicamente después de que se hayan producido nuevos cambios en los requisitos. Esto se debe a que dichos cambios pueden causar un aumento o una disminución en la criticidad de una función que depende de cómo el requisito revisado impacte la criticidad del sistema.

El análisis de Criticidad tiene los siguientes pasos:
 

• A. El primer paso es construir un diagrama de flujo de control (CFD) del sistema con sus elementos donde cada bloque representará solo una función de software.
• B. Luego, rastreará cada función crítica o su requisito de calidad con la ayuda de un diagrama de flujo de control.
• C. Clasificar todas las funciones de software rastreadas como críticas para la ejecución adecuada de las funciones críticas de software y los requisitos de calidad.
• D. Centrar el análisis adicional en estas funciones de software críticas rastreadas.
• E. Por último, repetirá el análisis de criticidad para cada proceso del ciclo de vida para verificar si los detalles de implementación cambiaron el énfasis de la criticidad.
   

4. Análisis de
peligros y riesgos: el análisis de peligros y riesgos se realiza durante la actividad de definición de requisitos. En este análisis, los peligros o riesgos se identifican refinando los requisitos del sistema en requisitos de software detallados.