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 verificar que un sistema de software cumple con las especificaciones y requisitos para que cumpla con su 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 de 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? ¿X cumple con los requisitos de alto nivel?"
Definiciones
La verificación y la validación no son lo mismo, aunque a menudo se confunden. Boehm expresó sucintamente la diferencia como [1]
- Verificación: ¿Estamos construyendo el producto correctamente?
- Validación: ¿Estamos construyendo el producto adecuado?
"Construir el producto correcto" 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.
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 de construcción. 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 construyendo el producto que las partes interesadas quieren correctamente. Este tipo de verificación se denomina "verificación de artefactos o especificaciones".
La construcción del producto correcto implica la creación de una especificación de requisitos que contenga las necesidades y los objetivos de las partes interesadas del producto de software. Si tal artefacto está incompleto o es incorrecto, los desarrolladores no podrán construir el producto que desean las partes interesadas. Esta es una forma de "validación de artefactos o especificaciones".
Nota: La verificación comienza antes de la validación y luego se ejecutan en paralelo hasta que se lanza el producto de software. [ aclaración necesaria ]
Verificación de software
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.están implementados correctamente ejecutando el software?). Solo al revisar sus artefactos asociados, alguien puede concluir si se cumplen las especificaciones.
Verificación de artefactos o 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 (consulte la definición de CMMI a continuación).
Ejemplos de verificación de artefactos:
- De la especificación de diseño contra la especificación de requisitos: ¿El diseño arquitectónico, el diseño detallado y las especificaciones del modelo lógico de la base de datos implementan correctamente las especificaciones de requisitos funcionales y no funcionales?
- 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 la base de datos implementan correctamente la especificación de diseño?
Validación de software
La validación de software comprueba que el producto de software satisface o se ajusta al uso previsto (comprobació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 grupos de interés (como usuarios, operadores, administradores, gestores, inversores, etc.). Hay dos formas de realizar la validación de software: interna y externa. Durante la validación interna del software, se asume 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 usuarios y partes interesadas; por 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 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 artefactos o especificaciones
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 que comience el diseño; pero los procesos de desarrollo iterativo 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 entrevistándolos 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 de usuario: la entrada de usuario (recopilada por cualquier periférico como teclado, sensor biométrico, etc.) se valida al verificar si la entrada proporcionada por los operadores de software o los usuarios cumple con las reglas y restricciones del dominio (como el tipo de datos, el rango y formato).
Validación vs verificación
Según el modelo de madurez de capacidad (CMMI-SW v1.1), [2]
- Validación de software: El proceso de evaluación de 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 verse como una forma de validación de la Especificación de Requisitos del Usuario; y, que al final del proceso de desarrollo sea equivalente a la validación del Software Interno y / o Externo. La verificación, desde el punto de vista de CMMI, es evidentemente del tipo de artefactos.
En otras palabras, la verificación de software asegura que la salida de cada fase del proceso de desarrollo de software lleve a cabo efectivamente lo que especifica su artefacto de entrada correspondiente (requisito -> diseño -> producto de software), mientras que la validación de software asegura que el producto de software cumple con 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 del software asegura que "lo construyó correctamente" y confirma que el producto, tal como se proporciona, cumple con los planes de los desarrolladores. La validación del software asegura que "usted construyó 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:
- Fallo: función incorrecta o faltante en el código.
- Falla: la manifestación de una falla durante la ejecución. El software no fue efectivo. No hace "lo" que se supone que debe hacer.
- Mal funcionamiento: de acuerdo con su especificación, el sistema no cumple con su funcionalidad especificada. El software no fue eficiente (tomó demasiados recursos como ciclos de CPU, usó demasiada memoria, realizó demasiadas operaciones de E / S, etc.), no fue utilizable, no fue confiable, etc. algo "cómo" se supone que debe hacerlo.
Conceptos relacionados
Tanto la verificación como la validación están relacionadas con los conceptos de calidad y aseguramiento de la calidad del software . Por sí mismos, 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 Verificación de M&S es el proceso de determinar que un modelo de computadora , simulación o federación de modelos e implementaciones de simulaciones y sus datos asociados representan con precisión la descripción conceptual y las especificaciones del desarrollador. [3]
- La validación de M&S 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 de los usos previstos. [3]
- La acreditación es la certificación formal de que un modelo o simulación es aceptable para usarse con un propósito específico. [3]
La definición de validación de M&S se centra en la precisión con la que M&S representa los usos previstos en el mundo real. Es necesario determinar el grado de precisión de 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 del software.
Métodos V&V
Formal
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 del software.
Independiente
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 a lo largo de la vida operativa del software. El objetivo de ISVV es garantizar que el software funcione con el nivel de confianza especificado y dentro de sus parámetros diseñados y requisitos definidos. [4] [5]
Las actividades de ISVV son realizadas por equipos de ingeniería independientes, no involucrados en el proceso de desarrollo de software, para evaluar los procesos y los productos resultantes. La independencia del equipo de ISVV se realiza en tres niveles diferentes: financiero, gerencial y técnico.
ISVV va más allá de las técnicas de verificación y validación "tradicionales", aplicadas por equipos de desarrollo. Mientras que este último tiene como objetivo garantizar que el software funcione bien frente a los requisitos nominales, ISVV se centra en requisitos no funcionales, como robustez y confiabilidad, y en 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.
Historia
ISVV se deriva de la aplicación de IV&V (Verificación y Validación Independiente) al software. La aplicación inicial de ISVV (como se conoce hoy en día) se remonta a principios de la década de 1970 cuando el Ejército de los EE. UU. Patrocinó el primer programa significativo 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 fines 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 conduce a una creciente demanda de IV&V aplicado al software.
Mientras tanto, IV&V (e ISVV para sistemas de software) se consolida y ahora es ampliamente utilizado por organizaciones como DoD , FAA , [8] NASA [7] y ESA . [9] IV&V se menciona en DO-178B , ISO / IEC 12207 y se formaliza 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 "Guía de la ESA para la verificación y validación independientes "con el apoyo de otras organizaciones. [10] 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, habiendo recibido aportaciones de muchas partes interesadas de ISVV espaciales europeas diferentes. [10]
Metodología
ISVV generalmente se compone de cinco fases principales, estas fases se pueden ejecutar secuencialmente o como resultado de un proceso de adaptación.
Planificación
- Planificación de las actividades de 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 requisitos
- Verificación de: integridad, corrección, capacidad de prueba
Verificación de diseño
- Diseñar la adecuación y conformidad con los requisitos e interfaces del software.
- Consistencia interna y externa
- Verificación de viabilidad y mantenimiento
Verificación de código
- Verificación de: integridad, corrección, coherencia
- Análisis de métricas de código
- Verificación del cumplimiento de los estándares de codificación
Validación
- Identificación de componentes / funcionalidades inestables
- Validación enfocada al manejo de errores: validación complementaria (no concurrente) 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 reguladas por ley, que a menudo se rigen por agencias gubernamentales [11] [12] o autoridades administrativas industriales. Por ejemplo, la FDA exige que se validen las versiones de software y los parches . [13]
Ver también
- Corrección del compilador
- Validación cruzada
- Verificación formal
- Especificacion funcional
- Instalación independiente de verificación y validación
- Junta Internacional de Cualificaciones de Pruebas de Software
- Verificación de software
- Especificación de Requerimientos de Software
- Validación (fabricación de fármacos)
- Verificación y validación - General
- Verificación y validación de modelos de simulación por computadora
- 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 de seguridad crítica
- Instalación independiente de verificación y validación de Katherine Johnson
Otras lecturas
- 1012-2012 Estándar IEEE para la verificación y validación de sistemas y software . 2012. doi : 10.1109 / IEEESTD.2012.6204026 . ISBN 978-0-7381-7268-2.
- Tran, E. (1999). "Verificación / Validación / Certificación" . En Koopman, P. (ed.). Temas en sistemas integrados confiables . Universidad Carnegie Mellon . Consultado el 18 de mayo de 2007 .
- Menzies, T .; Y. Hu (2003). "Minería de datos para gente muy ocupada". Computadora . 36 (1): 22-29. doi : 10.1109 / MC.2003.1244531 .
enlaces externos
- Capítulo sobre la calidad del software (incluido VnV) en SWEBOK
Referencias
- ^ Pham, H. (1999). Fiabilidad del software . John Wiley & Sons, Inc. pág. 567. ISBN 9813083840.
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 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? ''.
- ^ "CMMI para ingeniería de software, versión 1.1, representación por etapas (CMMI-SW, V1.1, por etapas)" . resources.sei.cmu.edu . Consultado el 20 de marzo de 2021 .
- ^ a b c "Documentación del Departamento de Defensa de Verificación, Validación y Acreditación (VV&A) para modelos y simulaciones". Agencia de Defensa de Misiles. 2008. Cite journal requiere
|journal=
( ayuda ) - ^ Rogers, R. (26 de octubre de 1981). "Planificación para la verificación y validación de software independiente" . 3ª Conferencia de Computadoras en Aeroespacial . San Diego, CA, EE.UU .: Instituto Americano de Aeronáutica y Astronáutica. doi : 10.2514 / 6.1981-2100 .
- ^ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (12 de mayo de 2008). "Un proceso de validación y verificación de software independiente para aplicaciones espaciales" . Conferencia SpaceOps 2008 . Heidelberg, Alemania: Instituto Americano de Aeronáutica y Astronáutica. doi : 10.2514 / 6.2008-3517 . ISBN 978-1-62410-167-0.
- ^ Lewis, Robert O. (1992). Verificación y validación independientes: un proceso de ingeniería de ciclo de vida para software de calidad . Nueva York: Wiley. ISBN 0-471-57011-7. OCLC 74908695 .
- ^ a b Asbury, Michael (9 de marzo de 2015). "Sobre el programa IV&V de la NASA" . NASA . Consultado el 20 de marzo de 2021 .
- ^ Balci, O. (2010). "Reglas de oro de verificación, validación, pruebas y certificación de aplicaciones de modelado y simulación" . indefinido . Consultado el 20 de marzo de 2021 .
- ^ "Sección de sistemas de software de vuelo (TEC-SWF)" . www.esa.int . Consultado el 20 de marzo de 2021 .
- ^ a b lavva.pt. "Nueva guía ISVV para Space in the Works" . www.criticalsoftware.com . Consultado el 20 de marzo de 2021 .
- ^ "Principios generales de validación de software; Guía final para la industria y el personal de la FDA" (PDF) . Administración de Alimentos y Medicamentos . 11 de enero de 2002 . Consultado el 12 de julio de 2009 .
- ^ "Orientación para la industria: Parte 11, Registros electrónicos; Firmas electrónicas: alcance y aplicación" (PDF) . Administración de Alimentos y Medicamentos . Agosto de 2003 . Consultado el 12 de julio de 2009 .
- ^ "Orientación para la industria: ciberseguridad para dispositivos médicos en red que contienen software comercial (OTS)" (PDF) . Administración de Alimentos y Medicamentos . 14 de enero de 2005 . Consultado el 12 de julio de 2009 .