Modelos de desarrollo de software - Verificación vs. Validación (K2 - entender, explicar , razonar)

Objetivos:

1. Comprender las diferencias entre verificación y validación del software. (K2).
2. Introducirse en las inspeccion de programas como un método para descubrir defectos en los programas.(K2).
3. Comprender qué es el análisis estático automatizado y cómo se utiliza en verificación y validación.(K2).

Términos usados en este artículo: VERIFICACIÓN, VALIDACIÓN, PLANIFICACIÓN, INSPECCIÓN, ESTÁTICO, MÉTODOS.

Antecedente.

Durante y después del proceso de implementación , el programa que se está desarrollando debe ser comprobado para asegurar que satisface su especificación y funcionalidad esperada por las personas que pagan por el software. La verificación y la Validación (V&V) es el nombre dado a estos procesos de análisis y pruebas. La verificación y la validación tienen lugar en cada estapa de proceso del software. V & V comienza con revisiones de los requerimientos y continúa con revisiones del diseño e inspecciones de código hasta la prueba del producto.

La verificación y la validación no son lo mismo, aunque a menudo se confunden. Boehm (Boehm 1979) expresó de forma sucinta la diferencia entre ellas:

• "Validación: ¿Estamos construyendo el producto correcto?"
• "Verificación:¿Estamos construyendo el producto correctamente?"

Según ISO 9000 la diferencias de describen como:

• "Validación: Comprobación de la idoneidad para el uso esperado" ¿Hemos construido el sistema de software correcto?
• "Verificación: Comprobación de la conformidad con los requicitios establecidos ¿Se ha procedido correctamente en la construcción del sistema?"

Estas definiciones nos dicen que el papel de la verificación implica comprobar que el software está de acuerdo con su especificación. Debería comprobarse que satisface sus requerimientos funcionales y no funcionales.

La validación, sin embargo, es un proceso más general. Su objetivo es asegurar que el sistema de software satisface las expectativas del cliente. Va más allá de la comprobación de que el sistema de software satisface  su especificación para demostrar que el software hace lo que el cliente espera que haga. Por qué? porque a veces las especificaciones del sistema de software no siempre reflejan los deseos o necesidades reales de los usuarios y los propietarios del sistema

El objetivo último del proceso de verificación y validación es establecer la seguridad de que el sistema de software está "HECHO PARA UN PROPÓSITO". Esto significa que el sistema debe ser lo suficientemente bueno para su uso pretendido.

Niveles de confianza según las expectativas de los usuarios y el entorno del mercado actual. 

1. Función del software. El nivel de confianza requerido depende de los crítico que sea el software para una organización, por ejemplo, el nivel de confianza crítico es mucho más alto que el requerido para un prototipo de un sistema de software que ha sido desarrollado para demostrar algunas ideas nuevas.
2. Expectativas del usuario. Una reflexión lamentable sobre la industria del software es que muchos usuarios tienen pocas expectativas sobre y no se sorprenden cuando éste falla durante su uso. Están dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son mayores que sus desventajas. Sin embargo, la tolerancia de los usuarios a los fallos de los sistemas está decreciendo desde los años 90. actualmente es menos aceptable entregar sistemas no fiables, por lo que laa compañías de software deben invertir más esfuerzo para verificar y validar. 
3. Entorno del mercado. Cuando un sistema se comercializa , los vendedores del sistema deben tener en cuenta los programas competidores, el precio que sus clientes están dispuesto a pagar por el sistema y la agenda requerida para entregar dicho sistema. Cuando una compañía tiene pocos competidores, puede decidir entregar un programa antes de que haya sido completamente probado y depurado, debido a que quiere ser el primero en el mercado. Cuando los clientes no están dispuestos a pagar precios altos pro el software, pueden estar dispuestos a tolerar más defectos en él. todos estos factores pueden considerarse cuando se decide cuánto esfuerzo debería invertirse en el proceso de V & V.

Aproximaciones complementarias para el análisis y comprobación de los sistemas.

1.    Las inspecciones de software analizan y comprueban las representaciones del sistema tales como el documento de requerimientos, los diagramas de diseño y el código fuentes del programa. Las inspecciones pueden ser complementadas con algún tipo de análisis automático del código fuente de un sistema o de los documentos asociados. Las inspecciones de software y los análisis automáticos son técnicas de V & V estáticas, ya que no se necesita ejecutar el software en una computadora.
2. Las pruebas del software implican ejecutar una implementación del software con datos de prueba. Se examinan las salidas del software y su entorno operacional para comprobar que funciona y como se requiere. Las pruebas son una técnica dinámica de verificación y validación.

En la presente imagen se muestra que las inspecciones del software y las pruebas son actividades complementarias en el proceso del software. Las flechas indican que las etapas en el proceso en las que pueden utilizarse dichas técnicas. Por lo tanto, se pueden utilizar las inspecciones del software en todas las etapas del proceso de desarrollo. Comenzando por los requerimientos, puede inspeccionarse cualquier representación legible del software.

Tipos de Pruebas 

Existen dos tipos distintos de pruebas que pueden utilizarse en diferentes etapas del proceso del software:

1. Las pruebas de validación: intenta demostrar que le software es el que el cliente quiere - que satisface sus requerimientos.
2. Las pruebas de defectos; intentan revelar defectos en el sistema en lugar de simular su uso operacional. Su objetivo es hallar inconsistencia entre un programa y su especificación.