Hispanopedia Wiki
Articulo de referencia

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 consiste en comprobar que un sistema de software cump...

Hispanopedia WikiContenido en espanolLectura gratuita

En la gestión de proyectos de software , las pruebas de software y la ingeniería de software , la verificación y validación consiste en comprobar que un sistema de software cumple con las especificaciones y los requisitos para que cumpla su propósito. También se conoce como 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 sencillos, la verificación del software se plantea como: «Suponiendo que deberíamos construir X, ¿nuestro software alcanza sus objetivos sin errores ni deficiencias?». Por otro lado, la validación del software se plantea como: «¿Era X lo que deberíamos haber construido? ¿Cumple X 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 [ 1 ] :

  • Verificación: ¿Estamos desarrollando el producto correctamente?
  • Validación: ¿Estamos desarrollando el producto adecuado?

«Construir el producto correctamente» verifica que el sistema implemente las especificaciones de forma adecuada, mientras que «construir el producto correcto» se refiere a las necesidades del usuario . En algunos contextos, se requiere contar con requisitos escritos para ambos, así como con 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 correctamente el producto implica usar 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. También implica usar 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 dicho proceso. Este tipo de verificación se denomina "verificación de artefactos o especificaciones".

Verificación de software

Esto implicaría verificar si se cumplen las especificaciones ejecutando el software, pero esto no es posible (por ejemplo, ¿cómo se puede saber si la arquitectura, el diseño, etc., están correctamente implementados ejecutando el software?). Solo revisando los artefactos asociados se puede determinar 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 someterse a verificación al compararlo con su especificación de entrada (véase la definición de CMMI a continuación).

Ejemplos de verificación de artefactos:

  • Comparación de las especificaciones de diseño con las especificaciones 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?
  • En relación con los elementos de construcción y 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 (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 solamente; 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 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 se realiza cuando se lleva a cabo 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 usuarios y 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. Dicha 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 las especificaciones de requisitos, pero eso entra dentro del ámbito de la verificación estática porque el software no está en funcionamiento.

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 exige que estén perfectamente definidos antes de que comience el diseño; pero los procesos de desarrollo iterativos no lo requieren 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 representan fielmente la voluntad y los objetivos de las partes interesadas. Esto puede realizarse mediante entrevistas directas con las partes interesadas (pruebas estáticas) o incluso mediante el lanzamiento de prototipos para que los usuarios y las partes interesadas los evalúen (pruebas dinámicas).
  • Validación de la entrada del usuario: La entrada del usuario (recopilada mediante cualquier periférico, como un teclado, un sensor biométrico, etc.) se valida comprobando 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 el formato).

Validación frente a verificación

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

  • Validación de software: Proceso de evaluación del software durante o al final del proceso de desarrollo para determinar si cumple con los requisitos especificados. [IEEE-STD-610]
  • Verificación de software: Proceso de evaluación de software para determinar si los productos de una fase de desarrollo determinada cumplen las condiciones impuestas al inicio de dicha fase. [IEEE-STD-610]

La validación durante el proceso de desarrollo de software puede considerarse una forma de validación de las especificaciones de requisitos del usuario; y, al final del proceso de desarrollo, equivale a la validación interna y/o externa del software. Desde la perspectiva de CMMI, la verificación es, evidentemente, un tipo de artefacto.

En otras palabras, la verificación de software garantiza que el resultado de cada fase del proceso de desarrollo de software cumpla eficazmente con lo especificado en 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 todos los interesados ​​(es decir, que la especificación de requisitos se haya expresado de forma correcta y precisa desde el principio). La verificación de software garantiza que "se haya construido correctamente" y confirma que el producto, tal como se entrega, cumple con los planes de los desarrolladores. La validación de software garantiza que "se haya construido lo correcto" y confirma que el producto, tal como se entrega, cumple con el uso previsto y los objetivos de los interesados.

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

Desde la perspectiva de las pruebas:

  • Error: función incorrecta o faltante en el código.
  • Fallo: manifestación de una avería durante la ejecución. El software no fue efectivo. No hace lo que se supone que debe hacer.
  • Mal funcionamiento: según sus especificaciones, el sistema no cumple con la funcionalidad prevista. El software consumió recursos excesivos (demasiado tiempo o ciclos de CPU, demasiada memoria, demasiadas operaciones de E/S, etc.); tuvo efectos secundarios (riesgos de calor, voltaje o vibración para los sistemas, riesgos de calor, corriente o fuerza para los usuarios); no era utilizable, no era fiable, etc. No hace algo "como" debería.

Tanto la verificación como la validación están relacionadas con los conceptos de calidad y de aseguramiento de la calidad del software . Sin embargo, 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 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 informático , 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 de modelos y simulaciones 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 o usos previstos. [ 3 ]
  • 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. [ 3 ]

La definición de validación de modelos y simulaciones (M&S) se centra en la precisión con la que el M&S representa el uso previsto en el mundo real. Es necesario determinar el grado de precisión del M&S, ya que todos los M&S son aproximaciones de la realidad, y suele ser fundamental determinar si dicho grado de aproximación es aceptable para el uso previsto. Esto contrasta con la validación de software.

Métodos

Formal

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

Independiente

La Verificación y Validación Independiente de Software (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 útil del software. El objetivo de ISVV es garantizar que el software funcione con el nivel de confianza especificado y dentro de sus parámetros de diseño y requisitos definidos. [ 4 ] [ 5 ]

Las actividades de ISVV son realizadas por equipos de ingeniería independientes, ajenos al proceso de desarrollo de software, para evaluar los procesos y los productos resultantes. La independencia del equipo ISVV se manifiesta en tres niveles: financiero, administrativo y técnico.

ISVV va más allá de las técnicas de verificación y validación "tradicionales" que aplican los equipos de desarrollo. Mientras que estas últimas buscan garantizar que el software funcione correctamente según los requisitos nominales, ISVV se centra en requisitos no funcionales como la robustez y la fiabilidad, y en las condiciones que pueden provocar fallos en el software.

Los resultados y hallazgos de ISVV se transmiten 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 Independientes) al software. Las primeras aplicaciones de ISVV (tal como se conocen 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 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 finales de la década de 1970, la verificación y validación independientes (IV&V) se popularizó rápidamente. El constante aumento de la complejidad, el tamaño y la importancia del software generó una creciente demanda de IV&V aplicada al software.

Mientras tanto, IV&V (y ISVV para sistemas de software) se consolidaron y ahora son ampliamente utilizados por organizaciones como el 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, entre 2004 y 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 la ISVV, denominada "Guía de la ESA para la verificación y validación independientes", con el apoyo de otras organizaciones. [ 10 ] Esta guía abarca las metodologías aplicables a todas las fases de la ingeniería de software en lo que respecta a la ISVV.

En 2008, la Agencia Espacial Europea publicó una segunda versión, tras haber recibido aportaciones de muchos interesados ​​diferentes del ISVV espacial europeo. [ 10 ]

Metodología

El ISVV suele constar de cinco fases principales, que pueden ejecutarse de forma secuencial o como resultado de un proceso de personalización.

Planificación

  • Planificación de las actividades de ISVV
  • Análisis de criticidad del sistema: Identificación de componentes críticos mediante un conjunto de actividades RAMS (Relación calidad-precio).
  • Selección de los métodos y herramientas adecuados

Verificación de requisitos

  • Verificación de: integridad, corrección, verificabilidad

Verificación del diseño

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

Verificación de código

Validación

  • Identificación de componentes/funcionalidades inestables
  • Validación centrada en el manejo de errores: validación complementaria (no concurrente) con respecto a la realizada por el equipo de desarrollo.
  • Cumplimiento de los requisitos de software y sistema
  • Técnicas de prueba de caja negra y 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 legalmente, que suelen estar guiados 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 ]

Véase también

Lecturas adicionales

  • Norma IEEE 1012-2012 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 embebidos confiables . Universidad Carnegie Mellon . Recuperado el 18 de mayo de 2007 .
  • Menzies, T.; Y. Hu (2003). "Minería de datos para personas muy ocupadas". Computer . 36 (1): 22– 29. doi : 10.1109/MC.2003.1244531 .
  • Capítulo sobre calidad del software (incluyendo VnV) Archivado el 8 de diciembre de 2014 en Wayback Machine en SWEBOK

Referencias

  1. ↑ Boehm, Barry W. (enero de 1984). "Verificación y validación de requisitos de software y especificaciones de diseño" . IEEE Software . 1 (1): 75– 88. doi : 10.1109/MS.1984.233702 . Recuperado el 23 de marzo de 2026 .
  2. ↑ "CMMI para ingeniería de software, versión 1.1, representación por etapas (CMMI-SW, V1.1, Staged)" . resources.sei.cmu.edu . 31 de julio de 2002. Consultado el 20 de marzo de 2021 .
  3. 1 2 3 Documentación del Departamento de Defensa sobre Verificación, Validación y Acreditación (VV&A) para Modelos y Simulaciones , Agencia de Defensa Antimisiles, 2008
  4. ↑ Rogers, R. (1981-10-26). "Planificación para la verificación y validación independiente de software" . 3.ª Conferencia sobre Computadoras en la Industria Aeroespacial . Conferencia sobre Computadoras en la Industria Aeroespacial. San Diego, CA, EE. UU.: Instituto Americano de Aeronáutica y Astronáutica. doi : 10.2514/6.1981-2100 .
  5. ↑ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (12 de mayo de 2008). «Un proceso independiente de verificación y validación de software 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.
  6. ↑ Lewis, Robert O. (1992). Verificación y validación independientes : un proceso de ingeniería del ciclo de vida para software de calidad . Nueva York: Wiley. ISBN  0-471-57011-7OCLC 74908695​​ 
  7. 1 2 Asbury, Michael (2015-03-09). "Acerca del programa IV&V de la NASA" . NASA . Recuperado el 2021-03-20 .
  8. ↑ Balci, O. (2010). "Reglas de oro de verificación, validación, pruebas y certificación de aplicaciones de modelado y simulación". S2CID 61476570 . {{cite web}}: Falta o está vacío |url=( ayuda )
  9. ↑ "Sección de Sistemas de Software de Vuelo (TEC-SWF)" . www.esa.int . Consultado el 20 de marzo de 2021 .
  10. 1 2 lavva.pt. "Nueva guía ISVV para Space en desarrollo" . www.criticalsoftware.com . Consultado el 20 de marzo de 2021 .
  11. ↑ "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. Archivado del original (PDF) el 17 de junio de 2009. Consultado el 12 de julio de 2009 .
  12. ↑ "Guía 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. Archivado del original (PDF) el 9 de julio de 2009. Consultado el 12 de julio de 2009 .
  13. ↑ "Guía para la industria: Ciberseguridad para dispositivos médicos en red que contienen software comercial" (PDF) . Administración de Alimentos y Medicamentos . 14 de enero de 2005. Archivado del original (PDF) el 10 de julio de 2009. Consultado el 12 de julio de 2009 .

Notas