martes, 7 de agosto de 2012

[VVS] 1. La Verificación y Validación de Software

DEFINICIÓN


Conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes.


OBJETIVO


Los objetivos de las actividades de verificación y validación son valorar y mejorar la calidad de los productos del trabajo generados durante el desarrollo y modificación del software. Debemos corregir todo posible fallo y alcanzar cierto grado de perfección, asi mismo, debemos garantizar la consistencia, confiabilidad, utilidad, eficacia y el apego a los estándares del desarrollo de software.
Para ello es necesario encontrar defectos en el sistema que estamos desarrollando y asegurarnos que el sistema será útil para el entorno de trabajo requerido.


VERIFICACIÓN Y VALIDACIÓN


Ambos conceptos suelen tratarse como sinónimos, sin embargo, se refieren a cosas completamente distintas:
  • La verificación se enfoca más al proceso de evaluación del sistema o de los componentes, permite determinar si los productos de una determinada fase del desarrollo satisfacen las condiciones impuestas en el inicio de la misma. Responde la pregunta ¿Estamos construyendo el producto correctamente?, entonces el software debería ajustarse a sus especificaciones iniciales.
  • La validación también es una evaluación del sistema o componentes, pero solo se efectúa en el transcurso o al final del proceso del desarrollo para determinar si cumple con lo especificado. Responde la pregunta ¿Estamos construyendo el producto correcto?, entonces el software debería hacer lo que el cliente realmente quiere que haga.

Es importante resaltar que nunca se va a poder demostrar que el software está completamente libre de defectos, la verificación y validación mas crítica es realizada por los clientes finales.


TÉCNICAS DE VALIDACIÓN Y VERIFICACIÓN


Para aplicar estas técnicas siempre en necesario modelar cierto tipo de pruebas (tests) específicas, las pruebas son actividades en las cuales un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto.
Varias pruebas juntas con un fin especifico constituyen un caso de pruebas donde un conjunto de entradas, condiciones de ejecución y resultados esperados son desarrollados para un objetivo particular.

Las pruebas deben centrarse en dos objetivos:
  • Probar si el software no hace lo que debe hacer.
  • Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios.

Se clasifican en 2 grandes grupos:
  • Inspecciones de Software: analizan y comprueban las representaciones del sistema (los diagramas de diseño, el código fuente del programa). Se aplica a todas las etapas del proceso de desarrollo y se complementan con algún tipo de análisis automático del texto fuente y documentos asociados. Son técnicas de verificación y validación estáticas, no requieren que el sistema se ejecute.
  • Pruebas de Software: consisten en comparar datos teóricos con los resultados del software utilizando series de datos de prueba, se examinan los resultados del software y su comportamiento operacional para comprobar que se desempeñe conforme a lo requerido. Es una técnica dinámica de la verificación y validación ya que requiere disponer de un prototipo ejecutable del sistema.

Lo que buscamos descubrir con ambos tipos de pruebas son:
  • Defectos (bug): un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.
  • Fallos (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

Los errores mas comunes son:
  • División por cero
  • Ciclo infinito
  • Problemas aritméticos como desbordamientos (overflow) o subdesbordamientos (underflow).
  • Exceder el tamaño del array
  • Utilizar una variable no inicializada
  • Acceder a memoria no permitida (access violation)
  • Pérdida de memoria (memory leak)
  • Desbordamiento o subdesbordamiento de la pila (estructura de datos)
  • Desbordamiento de búfer (buffer overflow)
  • Bloqueo mutuo (deadlock)
  • Indizado inadecuado de tablas en bases de datos.

Después de que hemos realizado ambas pruebas y que han sido localizados errores, es necesario especificar un proceso de depuración .
El proceso de depuración localiza y corrige los errores descubiertos durante la verificación y validación. Es un proceso complicado pues no siempre los errores se detectan cerca del punto en que se generaron. Para este paso„ se utilizan herramientas de depuración, que facilitan el proceso. Algunos ejemplos de herramientas de depuración para diferentes plataformas son:
  • GDB (GNU Project Debugger) para C jdb - The Java Debugger
  • JDB (Java Debugger) para JAVA
  • JUnit (Java Unit Testing), suite de pruebas unitarias para JAVA , existen versiones para JavaScript.
  • PDB (Python debugger), suite de pruebas unitarias para JAVA

Después de reparar el error, hay que volver a probar el sistema (pruebas de regresión)pues la solución del primer fallo puede dar lugar a nuevos fallos.


IMPORTANCIA


La importancia de los procesos de validación se puede entender mejor si analizamos las consecuencias de no realizarlos, hay varios ejemplos famosos: : El Cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue. Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria.
  • Desastre: Cohete Mariner 1 
    Descripción: investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue. 
    Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria.

  • Desastre: Mars Climate Orbiter 
    Descripción: El satélite se estrello en la superficie marciana. 
    Causa: error en la programación del sistema de navegación hizo que al entrar en su atmósfera este se desintegrara, esto pasó porque al introducir los cálculos no se hicieron en el Sistema Métrico Internacional lo que provocó un fallo en la medición de la altitud sobre el planeta.

  • Desastre: Ariane 5 
    Descripción: El cohete se desvía se su curso debido a un error en los datos procesados. El intento posterior de enderezar la trayectoria fue demasiado brusco y el cohete finalmente se destruyó a los 37 sg. 
    Causa: el software de control realizó una conversión de un valor flotante de 64 bits en un entero de 16 bits sin comprobar que se produjeran desbordamientos.

Todos los desastres anteriores pudieron haber sido evitados si la causa de los mismos hubiera sido corregida mediante sencillas pruebas y evaluaciones.
Como podemos suponer, este tipo de experimentos tienen un alto costo para las instituciones que los realizan, un error en el sistema puede resultar en la perdida de millones de dolares, aunque en la actualidad son mas serios los errores que tienden a corromper o suprimir la información o datos guardados de los usuarios.

Siempre hay que darle importancia a estas pruebas y destinar los recursos necesarios a las mismas, no solo por las perdidas y el costo de repararlos en una etapa posterior, sino por nuestra propia ética profesional, un error de este tipo puede dejar a un Ingeniero en Software sin trabajo de por vida, entonces, es necesario ver las técnicas de validación y verificación de software como un proceso obligado en el desarrollo de software.

REFERENCIAS



Publicado por en
Etiquetas:

2 comentarios:

Suscribirse a: Enviar comentarios (Atom)