Verificación y validación de software.

En la gestión de proyectos de software, pruebas de software e ingeniería de software, la verificación y validación (V&V) es el proceso de comprobar que un sistema de software cumple con las especificaciones y requisitos. para que cumpla su finalidad prevista. También puede denominarse control de calidad del software. Normalmente es responsabilidad de los probadores de software como parte del ciclo de vida del desarrollo de software. En términos simples, la verificación del software es: "Suponiendo que deberíamos crear X, ¿nuestro software logra sus objetivos sin errores ni lagunas?" Por otro lado, la validación del software es: "¿Era X lo que deberíamos haber construido?" ¿X cumple con los requisitos de alto nivel?"

Definiciones

Verificación y validación no son lo mismo, aunque a menudo se confunden. Boehm expresó sucintamente la diferencia como

• Verificación: ¿Estamos construyendo el producto bien?
• Validación: ¿Estamos construyendo el producto adecuado?

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

Construir el producto correctamente 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 constructivo. Cada vez que la salida 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 están creando correctamente el producto que desean las partes interesadas. Este tipo de verificación se denomina "verificación de artefactos o especificaciones".

producto de software es liberado; sin embargo, no necesita siempre ser el caso.

Verificación de software

Implicaría verificar si las especificaciones se cumplen ejecutando el software, pero esto no es posible (por ejemplo, ¿cómo puede alguien saber si la arquitectura/diseño/etc. se implementan correctamente ejecutando el software?). Sólo revisando los artefactos asociados se puede concluir si se cumplen o no las especificaciones.

Verificación de artefactos o especificaciones

El resultado de cada etapa del proceso de desarrollo de software también puede estar sujeto a verificación cuando se compara con su especificación de entrada (consulte la definición de CMMI a continuación).

Ejemplos de verificación de artefactos:

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

Validación de software

La validación del software verifica que el producto de software satisface o se ajusta al uso previsto (verificación de alto nivel), es decir, que 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 todos los stakeholders (como usuarios, operadores, administradores, gestores, inversores, etc.). Hay dos formas de realizar la validación del software: interna y externa. Durante la validación interna del software, 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. Las diferentes metodologías de desarrollo de software requieren diferentes niveles de participación y retroalimentación de los usuarios y partes interesadas; entonces, 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. Esta 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 determinar 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 se está ejecutando.

Validación de artefacto o especificación

Los requisitos deben validarse antes de que el producto 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 así sea y permiten su mejora continua).

Ejemplos de validación de artefactos:

• Requisitos del usuario validación de especificación: Los requisitos de usuario como se indica en un documento llamado Especificaciones de requisitos de usuario se validan comprobando si representan la voluntad y los objetivos de los interesados. Esto se puede hacer entrevistando a los interesados y preguntándoles directamente (pruebas estáticas) o incluso liberando prototipos y teniendo a los usuarios y los interesados para evaluarlos (pruebas dinamicas).
• Validación de entrada de usuario: La entrada de usuario (recogido por cualquier periférico como un teclado, sensor biométrico, etc.) se valida mediante la comprobación si la entrada proporcionada por los operadores de software o usuarios cumple con las reglas y limitaciones de dominio (como tipo de datos, rango y formato).

Validación versus verificación

Según el Modelo de Madurez de Capacidades (CMMI-SW v1.1),

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

La validación durante el proceso de desarrollo de software puede verse como una forma de validación de la especificación de requisitos del usuario; y, que al final del proceso de desarrollo equivale a la validación Interna y/o Externa del Software. La verificación, desde el punto de vista de CMMI, es evidentemente del tipo artefacto.

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

Este artículo ha utilizado la definición estricta o restringida de verificación.

Desde una perspectiva de prueba:

• Fault – función incorrecta o perdida en el código.
• Fallo - la manifestación de una falla durante la ejecución. El software no era eficaz. No hace "qué" 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 (necesitaba demasiados recursos como ciclos de CPU, usaba demasiada memoria, realizaba demasiadas operaciones de I/O, etc.), no era utilizable, no era confiable, etc. No hace algo "cómo" se supone que lo haga.

Conceptos relacionados

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 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 de software.

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

• MENTES La verificación es el proceso de determinar que un modelo informático, simulación o federación de modelos y implementaciones de simulación y sus datos asociados representan con precisión la descripción y especificaciones conceptuales del desarrollador.
• M. La validación es el proceso de determinar el grado en 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 del uso(s).
• La acreditación es la certificación formal de que un modelo o simulación es aceptable para ser utilizado con un propósito específico.

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

Métodos V&V

Formales

En 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 representan hasta el 80 por ciento del costo total del diseño de software.

Independiente

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 costos durante la vida operativa del software. El objetivo de ISVV es brindar garantía de que el software funciona con el nivel de confianza especificado y dentro de sus parámetros diseñados y requisitos definidos.

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.

ISVV va más allá de lo "tradicional" Técnicas de verificación y validación, aplicadas por los equipos de desarrollo. Mientras que este último tiene como objetivo garantizar que el software funcione bien según los requisitos nominales, ISVV se centra en requisitos no funcionales como la robustez y la confiabilidad, y en condiciones que pueden llevar al software a fallar.

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

Historia

ISVV deriva de la aplicación de IV&V (Verificación y Validación Independiente) al software. La aplicación temprana de ISVV (como se la conoce hoy) se remonta 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. Otro ejemplo es el Programa IV&V de la NASA, que se estableció en 1993.

A finales de la década de 1970, IV&V se estaba volviendo popular rápidamente. El constante aumento de la complejidad, el tamaño y la importancia del software llevó 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, la NASA y la ESA. IV&V se menciona en DO-178B, ISO/IEC 12207 y está formalizado en IEEE 1012.

En la ESA

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 Guía para la verificación y validación independientes" con el apoyo de otras organizaciones. Esta guía cubre las metodologías aplicables a todas las fases de la ingeniería de software en lo que respecta a ISVV.

En 2008, la Agencia Espacial Europea lanzó una segunda versión, después de haber recibido aportaciones de muchas partes interesadas del ISVV espacial europeo.

Metodología

ISVV generalmente se compone de cinco fases principales, estas fases se pueden ejecutar de forma secuencial o como resultado de un proceso de personalización.

Planificación

• Planificación de las actividades del ISVV
• Análisis de la crítica del sistema: Identificación de componentes críticos mediante un conjunto de actividades RAMS (valor por dinero)
• Selección de los métodos y herramientas adecuados

Verificación de requisitos

• Verificación para: integridad, corrección, testabilidad

Verificación del diseño

• Diseño adecuado y conforme a los requisitos e interfaces de software
• Congruencia interna y externa
• Verificación de viabilidad y mantenimiento

Verificación de código

• Verificación para: integridad, corrección, consistencia
• Análisis de métricas de código
• Verificación del cumplimiento de las normas de codificación

Validación

• Determinación de componentes/funcionalidades inestables
• Validación centrada en la gestión de errores: validación complementaria (no simultánea) con respecto a la realizada por el equipo de desarrollo
• Cumplimiento de los requisitos de software y sistema
• Pruebas de caja negra y técnicas de prueba de caja blanca
• Técnicas basadas en la experiencia

Entorno regulatorio

El software a menudo debe cumplir con los requisitos de cumplimiento de las industrias legalmente reguladas, que a menudo están guiadas por agencias gubernamentales o autoridades administrativas industriales. Por ejemplo, la FDA exige que se validen las versiones y parches de software.