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]
"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:
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:
De acuerdo con el Modelo de Madurez de Capacidad (CMMI-SW v1.1), [2]
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:
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 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 garantizar que el software funcione 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 en relación con 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.
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]
Validación de software. El proceso de asegurar que el software está realizando el proceso correcto. Verificación de software. El proceso de asegurar que el software está realizando el proceso correctamente". Asimismo y también allí: "En resumen, Boehm (3) expresó la diferencia entre la verificación de software y la validación de software de la siguiente manera: Verificación: ¿ Estamos construyendo el producto correctamente? Validación: ¿Estamos construyendo el producto correcto? .
{{cite web}}: Falta o está vacío |url=( ayuda )