Verificación y validación de software

En la gestión de proyectos de software , las pruebas de software y la ingeniería de software , la verificación y validación es el proceso de comprobar que un sistema de ingeniería de software cumple con las especificaciones y los requisitos para que cumpla con su propósito previsto. También se puede denominar control de calidad del software . Normalmente es responsabilidad de los evaluadores de software como parte del ciclo de vida del desarrollo del software . En términos simples, la verificación del software es: "Suponiendo que deberíamos construir X, ¿nuestro software logra sus objetivos sin errores ni lagunas?" Por otro lado, la validación del software es: "¿X fue lo que deberíamos haber construido? ¿X cumple con los requisitos de alto nivel?"

La verificación y la validación no son lo mismo, aunque a menudo se las confunde. Boehm expresó sucintamente la diferencia como ^[1]

• Verificación: ¿Estamos construyendo correctamente el producto?
• Validación: ¿Estamos construyendo el producto correcto?

"Construir el producto correctamente" verifica que el sistema implemente correctamente las especificaciones , mientras que "construir el producto correcto" se refiere a las necesidades del usuario . En algunos contextos, se requiere tener requisitos escritos para ambos, así como procedimientos o protocolos formales para determinar el cumplimiento. Idealmente, los métodos formales brindan una garantía matemática de que el software cumple con sus especificaciones.

La creación correcta del producto implica el uso de la Especificación de Requisitos como entrada para la siguiente fase del proceso de desarrollo, el proceso de diseño, cuyo resultado es la Especificación de Diseño. Luego, también implica el uso de la Especificación de Diseño para alimentar el proceso de construcción. Cada vez que el resultado de un proceso implementa correctamente su especificación de entrada, el producto de software está un paso más cerca de la verificación final. Si el resultado de un proceso es incorrecto, los desarrolladores no han implementado correctamente algún componente de ese proceso. Este tipo de verificación se denomina "verificación de artefactos o especificaciones".

Esto implicaría verificar si se cumplen las especificaciones al ejecutar el software, pero esto no es posible (por ejemplo, ¿cómo puede alguien saber si la arquitectura/diseño/etc. se implementan correctamente al ejecutar el software?). Solo al revisar sus artefactos asociados, alguien puede concluir si se cumplen o no las especificaciones.

La salida de cada etapa del proceso de desarrollo de software también puede estar sujeta a verificación cuando se compara con su especificación de entrada (ver la definición de CMMI a continuación).

Ejemplos de verificación de artefactos:

• De la especificación de diseño frente a la especificación de requisitos: ¿Las especificaciones de diseño arquitectónico, diseño detallado y modelo lógico de la base de datos implementan correctamente las especificaciones de requisitos funcionales y no funcionales?
• De los artefactos de construcción frente a la especificación de diseño: ¿El código fuente, las interfaces de usuario y el modelo físico de la base de datos implementan correctamente la especificación de diseño?

La validación de software verifica que el producto de software satisface o se ajusta al uso previsto (verificación de alto nivel), es decir, el software cumple con los requisitos del usuario, no como artefactos de especificación o como necesidades de quienes operarán el software únicamente; sino, como las necesidades de todas las partes interesadas (como usuarios, operadores, administradores, gerentes, inversores, etc.). Hay dos formas de realizar la validación de software: interna y externa. Durante la validación de software interna, se supone que los objetivos de las partes interesadas se entendieron correctamente y que se expresaron en los artefactos de requisitos de manera precisa y completa. Si el software cumple con la especificación de requisitos, ha sido validado internamente. La validación externa ocurre cuando se realiza preguntando a las partes interesadas si el software satisface sus necesidades. Diferentes metodologías de desarrollo de software requieren diferentes niveles de participación y retroalimentación de los usuarios y las partes interesadas; por lo tanto, la validación externa puede ser un evento discreto o continuo. La validación externa final exitosa ocurre cuando todas las partes interesadas aceptan el producto de software y expresan que satisface sus necesidades. Tal validación externa final requiere el uso de una prueba de aceptación que es una prueba dinámica .

Sin embargo, también es posible realizar pruebas estáticas internas para averiguar si el software cumple con la especificación de requisitos, pero eso cae dentro del alcance de la verificación estática porque el software no está en ejecución.

Los requisitos deben validarse antes de que el producto de software en su conjunto esté listo (el proceso de desarrollo en cascada requiere que estén perfectamente definidos antes de comenzar el diseño; pero los procesos de desarrollo iterativos no requieren que esto sea así y permiten su mejora continua).

Ejemplos de validación de artefactos:

• Validación de la especificación de requisitos del usuario: los requisitos del usuario, tal como se establecen en un documento denominado especificación de requisitos del usuario, se validan comprobando si realmente representan la voluntad y los objetivos de las partes interesadas. Esto se puede hacer entrevistando a las partes interesadas y preguntándoles directamente (pruebas estáticas) o incluso lanzando prototipos y haciendo que los usuarios y las partes interesadas los evalúen (pruebas dinámicas).
• Validación de entrada del usuario: la entrada del usuario (recopilada por cualquier periférico como un teclado, un sensor biométrico, etc.) se valida verificando si la entrada proporcionada por los operadores del software o los usuarios cumple con las reglas y restricciones del dominio (como el tipo de datos, el rango y el formato).

De acuerdo con el Modelo de Madurez de Capacidad (CMMI-SW v1.1), ^[2]

• Validación de software: El proceso de evaluar el software durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. [IEEE-STD-610]
• Verificación de software: Proceso de evaluación de software para determinar si los productos de una determinada fase de desarrollo satisfacen las condiciones impuestas al inicio de esa fase. [IEEE-STD-610]

La validación durante el proceso de desarrollo de software puede considerarse como una forma de validación de las especificaciones de requisitos del usuario y, al final del proceso de desarrollo, es equivalente a la validación interna y/o externa del software. La verificación, desde el punto de vista de CMMI, es evidentemente del tipo de artefacto.

En otras palabras, la verificación de software garantiza que el resultado de cada fase del proceso de desarrollo de software lleve a cabo de manera efectiva lo que especifica su artefacto de entrada correspondiente (requisito -> diseño -> producto de software), mientras que la validación de software garantiza que el producto de software satisfaga las necesidades de todas las partes interesadas (por lo tanto, la especificación de requisitos se expresó de manera correcta y precisa en primer lugar). La verificación de software garantiza que "lo construyó correctamente" y confirma que el producto, tal como se proporcionó, cumple con los planes de los desarrolladores. La validación de software garantiza que "construyó lo correcto" y confirma que el producto, tal como se proporcionó, cumple con el uso previsto y los objetivos de las partes interesadas.

En este artículo se ha utilizado la definición estricta o estrecha de verificación.

Desde una perspectiva de prueba:

• Error: función incorrecta o faltante en el código.
• Fallo: manifestación de un error durante la ejecución. El software no es eficaz. No hace "lo que" se supone que debe hacer.
• Mal funcionamiento: según su especificación, el sistema no cumple con su funcionalidad especificada. El software no era eficiente (consumía demasiados recursos, como ciclos de CPU, utilizaba demasiada memoria, realizaba demasiadas operaciones de E/S, etc.), no era utilizable, no era confiable, etc. No hace algo "como" se supone que debería hacerlo.

Tanto la verificación como la validación están relacionadas con los conceptos de calidad y de aseguramiento de la calidad del software . Por sí solas, la verificación y la validación no garantizan la calidad del software; se requieren planificación, trazabilidad , gestión de la configuración y otros aspectos de la ingeniería del software.

Dentro de la comunidad de modelado y simulación (M&S), las definiciones de verificación, validación y acreditación son similares:

• La verificación M&S es el proceso de determinar que un modelo de computadora , una simulación o una federación de modelos e implementaciones de simulación y sus datos asociados representan con precisión la descripción conceptual y las especificaciones del desarrollador. ^[3]
• La validación M&S es el proceso de determinar el grado en el que un modelo, simulación o federación de modelos y simulaciones, y sus datos asociados, son representaciones precisas del mundo real desde la perspectiva de los usos previstos. ^[3]
• La acreditación es la certificación formal de que un modelo o simulación es aceptable para ser utilizado para un propósito específico. ^[3]

La definición de validación de M&S se centra en la precisión con la que la M&S representa el uso previsto en el mundo real. Es necesario determinar el grado de precisión de la M&S porque todas las M&S son aproximaciones de la realidad y, por lo general, es fundamental determinar si el grado de aproximación es aceptable para el uso previsto. Esto contrasta con la validación de software.

En los sistemas de software de misión crítica , se pueden utilizar métodos formales para garantizar el correcto funcionamiento de un sistema. Sin embargo, estos métodos formales pueden resultar costosos y representar hasta el 80 por ciento del costo total del diseño del software.

La verificación y validación de software independiente (ISVV) está dirigida a sistemas de software críticos para la seguridad y tiene como objetivo aumentar la calidad de los productos de software, reduciendo así los riesgos y los costos a lo largo de la vida operativa del software. El objetivo de la ISVV es brindar garantía de que el software funciona según el nivel de confianza especificado y dentro de los parámetros diseñados y los requisitos definidos. ^{[4] [5]}

Las actividades de ISVV son realizadas por equipos de ingeniería independientes, que no participan en el proceso de desarrollo de software, para evaluar los procesos y los productos resultantes. La independencia del equipo ISVV se realiza en tres niveles diferentes: financiero, gerencial y técnico.

La ISVV va más allá de las técnicas de verificación y validación "tradicionales" que aplican los equipos de desarrollo. Mientras que la última tiene como objetivo garantizar que el software funcione bien frente a los requisitos nominales, la ISVV se centra en los requisitos no funcionales, como la solidez y la fiabilidad, y en las condiciones que pueden hacer que el software falle.

Los resultados y hallazgos de ISVV se envían a los equipos de desarrollo para su corrección y mejora.

ISVV se deriva de la aplicación de IV&V (Verificación y Validación Independientes) al software. Las primeras aplicaciones de ISVV (tal como se las conoce hoy en día) se remontan a principios de la década de 1970, cuando el Ejército de los EE. UU. patrocinó el primer programa importante relacionado con IV&V para el Sistema de Misiles Antibalísticos Safeguard . ^[6] Otro ejemplo es el Programa IV&V de la NASA, que se estableció en 1993. ^[7]

A finales de los años 70, el IV&V se estaba volviendo rápidamente popular. El aumento constante de la complejidad, el tamaño y la importancia del software condujo a una creciente demanda de IV&V aplicado al software.

Mientras tanto, IV&V (e ISVV para sistemas de software) se consolidaron y ahora son ampliamente utilizados por organizaciones como el Departamento de Defensa , la FAA , ^[8] la NASA ^[7] y la ESA . ^[9] IV&V se menciona en DO-178B , ISO/IEC 12207 y se formaliza en IEEE 1012 .

Inicialmente en 2004-2005, un consorcio europeo liderado por la Agencia Espacial Europea , y compuesto por DNV , Critical Software SA , Terma y CODA SciSys plc creó la primera versión de una guía dedicada a ISVV, llamada "ESA Guide for Independent Verification and Validation" con el apoyo de otras organizaciones. ^[10] Esta guía cubre las metodologías aplicables a todas las fases de ingeniería de software en lo que respecta a ISVV.

En 2008, la Agencia Espacial Europea publicó una segunda versión, tras recibir aportaciones de muchas partes interesadas en el ISVV espacial europeo. ^[10]

El ISVV normalmente se compone de cinco fases principales, estas fases pueden ejecutarse secuencialmente o como resultado de un proceso de adaptación.

• Planificación de actividades del ISVV
• Análisis de criticidad del sistema: Identificación de componentes críticos a través de un conjunto de actividades RAMS (Value for Money)
• Selección de los métodos y herramientas adecuados

• Verificación de: integridad, corrección, capacidad de prueba

• Adecuación del diseño y conformidad con los requisitos e interfaces del software
• Consistencia interna y externa
• Verificación de viabilidad y mantenimiento

• Verificación de: integridad, exactitud, consistencia
• Análisis de métricas de código
• Verificación del cumplimiento de los estándares de codificación

• Identificación de componentes/funcionalidades inestables
• Validación centrada en el manejo de errores: validación complementaria (no concurrente) respecto a la realizada por el equipo de desarrollo
• Cumplimiento de los requisitos del software y del sistema
• Técnicas de prueba de caja negra y prueba de caja blanca
• Técnicas basadas en la experiencia

El software a menudo debe cumplir con los requisitos de cumplimiento de las industrias reguladas legalmente, lo que suele estar determinado por agencias gubernamentales ^{[11] [12]} o autoridades administrativas industriales. Por ejemplo, la FDA exige que las versiones y los parches del software estén validados. ^[13]

• Corrección del compilador
• Validación cruzada
• Verificación formal
• Especificación funcional
• Instalación independiente de verificación y validación
• Junta Internacional de Calificaciones para Pruebas de Software
• Verificación de software
• Especificación de requisitos de software
• Validación (fabricación de medicamentos)
• Verificación y validación – General
• Verificación y validación de modelos de simulación por ordenador
• Sistemas de verificación independientes
• Pruebas de software
• Ingeniería de software
• Calidad del software
• Análisis de código estático
• Ingeniería de requisitos
• Sistema crítico para la seguridad
• Centro de verificación y validación independiente Katherine Johnson

• Capítulo sobre calidad del software (incluyendo VnV) Archivado el 8 de diciembre de 2014 en Wayback Machine en SWEBOK