VERIFICACION Y VALIDACION

Objetivos:

Introducir la V&V del software usando tcnicas de verificacin estticas.
Diferenciar entre verificacin y validacin.
Inspeccionar programas para descubrir sus defectos.
Comprender que es el anlisis esttico automatizado y su uso en la V&V.
Usar la verificacin esttica en el proceso de desarrollo de Sala Limpia.
Acta sobre los productos intermedios que se generan durante el desarrollo para.
Detectar y corregir cuanto antes sus defectos y las desviaciones respecto al objetivo fijado
Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el calendario o
programa de tiempos del proyecto
Mejorar la calidad y fiabilidad del software
Valorar rpidamente los cambios propuestos y sus consecuencias


Resumen

V&V es un conjunto de procedimientos, actividades, tcnicas y herramientas que se utilizan,
paralelamente al desarrollo de software, para asegurar que un producto software resuelve el
problema inicialmente planteado.

La V&V comienza con revisiones de los requerimientos, diseo e inspecciones de cdigo hasta la
prueba del producto.

Validacin: Estamos construyendo el producto correcto?.
Asegura que el sistema satisface las expectativas del cliente.

Verificacin: Estamos construyendo el producto correctamente?.
Comprobar que el software est de acuerdo con la especificacin y que satisface los FR y NFR.

La V&V del app echo para un propsito, es decir suficientemente bueno para el uso pretendido. Nivel
de confianza depende del propsito del sistema, expectativas del usuario y el entorno del mercado.

1. Funcin del software.- nivel de confianza.
2. Expectativas del usuario.- expectativa sobre su app, tolerancia a fallos.
3. Entorno de mercado.- competencia al app, precio y tiempo de entrega.

Aproximaciones Complementarias

1. Inspecciones de Software.- analizan y comprueban las representaciones del sistema como
esta en el documento de requerimientos. Se usa en todas las etapas. Las inspecciones del
software y los anlisis automticos son tcnicas de V&V ESTTICAS porque no se ejecuta el
software en un computador.
2. Pruebas del software.- ejecutar el app con datos de prueba. Se examina la salida y el entorno
operacional. Las pruebas son una tcnica de V&V DINMICAS.

Tipos de pruebas

1. Validacin.- app satisfaga los requerimientos.
2. Defectos.- hallar inconsistencias entre un programa y su especificacin.

Las pruebas y la depuracin

1. V&V o pruebas establecen la existencia de DEFECTOS en el sistema.
2. La depuracin es un proceso que localiza y corrige los DEFECTOS.

Planificacin de La V&V

Es un proceso caro, mas para sistemas de tiempo real con restricciones no funcionales
complejas.
Deberia comenzar en etapas tempranas del proceso de desarrollo.
Cada etapa comprueba la conformidad del programa con el diseo y especificacion.
Mantener un equilibrio para aproximaciones estticas y dinmicas pensando en estndares y
procedimientos para las inspecciones y pruebas del software.
Regla General.- Cuanto ms critico el sistema, ms esfuerzo a las tcnicas de verificacin
estticas.
Planificacin de pruebas bajo estndares ayuda a los gestores e ingenieros para tener un
mejor panorama.

Inspecciones de software
Son un proceso de V&V esttico, se revisa para encontrar errores, omisiones y anomalas. Se centran
en el cdigo fuente, requerimientos o un modelo de diseo.
Ventajas de la inspeccin sobre las pruebas:
1) Durante las pruebas los errores pueden ocultar a otros errores.
2) Pueden inspeccionarse versiones incompletas de un sistema sin costes adicionales.
3) Busca defectos en el programa, grado de cumplimiento con los estndares, portabilidad y
mantenimiento.

Las inspecciones son ms efectivas para descubrir defectos que las pruebas.
60% de los errores usando inspecciones informales,
90% de los errores usando inspecciones formales.

La revisin esttica de cdigo era ms efectiva y menos costosa. Es difcil introducir las inspecciones
formales en muchas organizaciones de desarrollo. Las inspecciones sobrecargan los costos.

El proceso de inspeccin de programas
La inspeccin de programas son revisiones cuyo objetivo es la deteccin de defectos en el programa.
Actualmente es un mtodo bastante utilizado de verificacin de programas, especialmente en
ingeniera de sistemas crticos.
Los inspectores deben ser seleccionados para reflejar diferentes puntos de vista tales como pruebas,
usuario final, y gestin de calidad.
Las actividades en el proceso de inspeccin son:
Planificacin
Visin de conjunto
Preparacin individual
Reunin de inspeccin
Repeticin de trabajo
Seguimiento
Antes de iniciar la inspeccin del programa es esencial:
1) Tener una especificacin precisa del cdigo a inspeccionar.
2) Los inspectores estn familiarizados con los estndares de la organizacin
3) Distribuir una versin compatible y actualizada del cdigo a todos los miembros del equipo.
El moderador es el responsable de la planificacin de la inspeccin. Organizar una sala de reuniones y
asegurar que el material a inspeccionar y sus especificaciones estn completas durante la etapa de
revisin general.
Una inspeccin debera ser bastante corta (no ms de dos horas) y debera centrarse en la deteccin
de defectos, cumplimiento con los estndares y programacin de baja calidad.
El moderador decide si es necesario o no la re inspeccin del cdigo.
Cada organizacin debera desarrollar su prpia lista de comprobacin de inspecciones basadas en
estndares y practicas locales, estas deberan ser actualizadas regularmente.
Defectos de datos
Defectos de control
Defectos de entrada y salida
Defectos de la interfaz
Defectos de gestin de almacenamiento
Defectos de manejo de excepciones
Las inspecciones son una forma ideal de recopilar datos sobre el tipo de defectos que se producen.
Anlisis esttico automatizado
Las inspecciones son una forma de anlisis estatico, se examina el programa sin ejecutarlo. Los
analizadores estticos escanean el cdigo, detectan posibles defectos y anomalas.
El objetivo es llamar la atencin del inspector sobre las anomalas del programa, pueden ser variables
sin inicializacin o que no se usen o datos cuyo valor puede estar fuera de alcance.
Los analizadores estticos son valiosos cuando se utiliza lenguaje de programacin C.
Verificacin y mtodos formales
Se basan en representaciones matemticas. Se ocupan principalmente del anlisis matemtico de la
especificacin.
Estos mtodos requieren un anlisis muy detallado de la especificacin del sistema y del programa, y
su uso consume a menudo tiempo y resulta caro. Debido a ello su uso esta restringido
principalmente a los procesos de desarrollo de software de seguridad crtico y seguro.
Los mtodos formales pueden utilizarse en diferentes etapas del proceso V&V:
1. Puede desarrollarse una especificacin formal del sistema y analizarse matemticamente para
buscar inconsistencias. Es efectiva para descubrir errores.
2. Puede verificarse formalmente que el cdigo de un sistema software es consistente con su
especificacin, utilizando argumentos matemticos. Es efectiva para detectar errores de diseo
y programacin.
Los mtodos formales juegan un papel importante en el desarrollo de sistema de software crtico.
Desarrollo de software de Sala Limpia
El desarrollo de software de Sala Limpia es una filosofa de desarrollo de software que utiliza dichos
mtodos para soportar inspecciones del software rigurosas. Su objetivo es obtener software con
cero defectos. El desarrollo de sala limpia se debe a que su uso reemplaza las pruebas de unidades
de los componentes del sistema por inspecciones para comprobar la consistencia de estos
componentes con sus especificaciones.
La aproximacin de Sala limpia al desarrollo del software se basa en cinco estrategias clave:
Especificacin formal
Desarrollo incremental
Programacin estructurada
Verificacin esttica
Pruebas estticas del sistema
Existen tres equipos implicados cuando se utiliza el proceso de Sala Limpia para el desarrollo de
grandes sistemas:
El equipo de especificacin
El equipo de desarrollo
El equipo de certificacin

El uso de sala limpia conduce generalmente a software con muy pocos errores.






EJERCICIOS
22.1 Seale las diferencias entre verificacin y validacin y explique porque la validacin es un
proceso particularmente difcil.
La diferencia es que la verificacin implica comprobar que el software est de acuerdo con su
especificacin mientras que la validacin implica asegurar que el sistema software satisface las
expectativas del cliente. Porque las especificaciones del sistema software no siempre reflejan los
deseos o necesidades reales de los usuarios y los propietarios del sistema.
22.2 Explique porque no es necesario que un programa este completamente libre de defectos antes
de que sea entregado a sus clientes. Hasta dnde se pueden utilizar las pruebas para validar que el
programa cumple con su propsito?
No es necesario que est libre de defectos ya que al realizar las pruebas, sobre todo las pruebas de
defectos, algunas de estas son las que nos demostraran que el programa cumple con sus
requerimientos. Aparte no se puede demostrar que el software este en su totalidad libre de defectos
o que se comparte como hayamos especificado en x circunstancia. Siempre es posible que una
prueba que demos por alto descubra ms problemas en el sistema.
22.4 Explique porque las inspecciones de programa son una tcnica efectiva para descubrir errores
en un programa. Qu tipos de errores probablemente no sean descubiertos a travs de las
inspecciones?
Porque la inspeccin es un proceso esttico y no hay que preocuparse de las interacciones entre
errores, adems de buscar los defectos en un programa puede considerar atributos de calidad ms
amplios de un programa tales como grado de cumplimiento con los estndares, portabilidad y
mantenibilidad. Por lo tanto, una nica sesin de inspeccin puede descubrir muchos errores en un
sistema y es menos costosa que realizar pruebas.
22.8 Explique porque puede ser rentable utilizar mtodos formales en el desarrollo de sistemas
software de seguridad tpicos. Por qu piensa usted que algunos desarrolladores de este tipo de
sistemas estn en contra del uso de los mtodos formales?
Debido a que estos mtodos estn diseados exclusivamente para el desarrollo de dichos sistemas
software es decir el programa desarrollado satisface su especificacin, por lo tanto los errores de
implementacin no comprometan la confiabilidad. Y por lo tanto no se incrementan los costos.
Debido a que requieren notaciones especficas, estas solo pueden ser usadas por personal
entrenado especialmente y no pueden ser comprendidas por expertos en el dominio, es decir Los
ingenieros software no pueden reconocer dificultades potenciales con los requerimientos debido a
que no comprenden el dominio; los expertos en el dominio no pueden encontrar este problema
porque no comprenden la especificacin.