En la gestión de proyectos de software , las pruebas de software y la 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 con el propósito previsto. 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 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: "¿Era X lo que deberíamos haber construido? ¿Cumple X los requisitos de alto nivel?"
Verificación y validación no son lo mismo, aunque muchas veces se confunden. Boehm expresó sucintamente la diferencia como [1]
"Crear el producto correcto" verifica que el sistema implemente correctamente las especificaciones , mientras que "crear 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".
se lanza el producto de software; [ se necesita aclaración ] sin embargo, no siempre tiene por qué ser así. [a]
Implicaría verificar si se cumplen las especificaciones 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.
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:
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.
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:
Según el Modelo de Madurez de Capacidades (CMMI-SW v1.1), [3]
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 de artefacto.
En otras palabras, la verificación del software asegura que la salida 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 asegura que el producto de software satisface las necesidades de todas las partes interesadas (por lo tanto, la especificación de requisitos se expresó correcta y exactamente 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:
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:
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.
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 representan hasta el 80 por ciento del costo total del diseño de 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 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. [5] [6]
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 las técnicas "tradicionales" de verificación y validación, aplicadas por los equipos de desarrollo. Mientras que estos últimos tienen como objetivo garantizar que el software funcione bien frente a 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.
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 EE. UU. patrocinó el primer programa importante relacionado con IV&V para el Sistema de Misiles Antibalísticos Safeguard . [7] Otro ejemplo es el Programa IV&V de la NASA, que se estableció en 1993. [8]
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 , [9] la NASA [8] y la ESA . [10] IV&V se menciona en DO-178B , ISO/IEC 12207 y está formalizado 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 "Guía de la ESA para la verificación y validación independiente". " con el apoyo de otras organizaciones. [11] 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. [11]
ISVV suele estar compuesto por cinco fases principales, estas fases pueden ejecutarse de forma secuencial o como resultado de un proceso de adaptación.
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 [12] [13] o autoridades administrativas industriales. Por ejemplo, la FDA exige que se validen las versiones y parches de software. [14]
Validación de software. El proceso de garantizar que el software esté realizando el proceso correcto. Verificación de software. El proceso de garantizar que el software esté realizando el proceso correctamente." Del mismo modo y también allí: "En resumen, Boehm (3) expresó la diferencia entre la verificación del software y la validación del 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 )