VERIFICACION Y VALIDACION Objetivos: Introducir la V&V del software usando técnicas de verificación estáticas. Diferenciar entre verificación y validación. Inspeccionar programas para descubrir sus defectos. Comprender que es el análisis estático automatizado y su uso en la V&V. Usar la verificación estática en el proceso de des arrollo de Sala Limpia. Actúa 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 cale ndario o programa de tiempos del proyecto Mejorar la calidad y fiabilidad del software Valorar rápidamente los cambios propuestos y sus consecuencias
Resumen V&V es un conjunto de procedimientos, actividades, técnicas 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, diseño e inspecciones de código hasta la prueba del producto.
Validación: Estamos construyendo el producto correcto?. Asegura que el sistema satisface las expectativas del cliente. Verificación: Estamos construyendo el producto correctamente?. Comprobar que el software está de acuerdo con la especificación y que satisface los FR y NFR. La V&V del app echo para un propósito, es decir suficientemente bueno para el uso pretendido. Nivel de confianza depende del propósito del sistema, expectativas del usuario y el entorno del mercado. 1. 2. 3.
Función del software.- nivel de confianza. Expectativas del usuario.- expectativa sobre su app, tolerancia a fallos. Entorno de mercado.- competencia al app, precio y tiempo de entrega.
Aproximaciones Complementarias 1.
2.
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 análisis automáticos son técnicas de V&V ESTÁTICAS porque no se ejecuta el software en un computador. Pruebas del software.- ejecutar el app con datos de prueba. Se examina la salida y el entorno operacional. Las pruebas son una técnica de V&V DINÁMICAS.
Tipos de pruebas 1. 2.
Validación.- app satisfaga los requerimientos. Defectos.- hallar inconsistencias entre un programa y su especificación.
Las pruebas y la depuración 1. 2.
V&V o pruebas establecen la existencia de DEFECTOS en el sistema. La depuración es un proceso que localiza y corrige los DEFECTOS.
Planificación 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 diseño y especificacion. Mantener un equilibrio para aproximaciones estáticas y dinámicas pensando en estándares y procedimientos para las inspecciones y pruebas del software. Regla General.- Cuanto más critico el sistema, más esfuerzo a las técnicas de verificación estáticas. Planificación de pruebas bajo estándares ayuda a los gestores e ingenieros para tener un mejor panorama.
Inspecciones de software Son un proceso de V&V estático, se revisa para encontrar errores, omisiones y anomalías. Se centran en el código fuente, requerimientos o un modelo de diseño.
Ventajas de la inspección 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 estándares, portabilidad y mantenimiento. Las inspecciones son más efectivas para descubrir defectos que las p ruebas. 60% de los errores usando inspecciones informales, 90% de los errores usando inspecciones formales. La revisión estática de código era más efectiva y menos costosa. Es difícil introducir las inspecciones formales en muchas organizaciones de desarrollo. Las inspecciones sobrecargan los costos.
El proceso de inspección de programas La inspección de programas son revisiones cuyo objetivo es la detección de defectos en el programa. Actualmente es un método bastante utilizado de verificación de programas, especialmente en ingeniería de sistemas críticos. Los inspectores deben ser seleccionados para reflejar diferentes puntos de vista tales como pruebas, usuario final, y gestión de calidad. Las actividades en el proceso de inspección son:
Planificación Visión de conjunto Preparación individual Reunión de inspección
Repetición de trabajo Seguimiento
Antes de iniciar la inspección del programa es esencial:
1) Tener una especificación precisa del código a inspeccionar. 2) Los inspectores estén familiarizados con los estándares de la organización 3) Distribuir una versión compatible y actualizada del código a todos los miembros del eq uipo. El moderador es el responsable de la planificación de la inspección. Organizar una sala de reuniones y asegurar que el material a inspeccionar y sus especificaciones estén completas durante la etapa de revisión general. Una inspección debería ser bastante corta (no más de dos horas) y debería centrarse en la detección de defectos, cumplimiento con los estándares y p rogramación de baja calidad. El moderador decide si es necesario o no la re inspección del código. Cada organización debería desarrollar su prpia lista de comprobación de inspecciones basadas en estándares y practicas locales, estas deberían ser actualizadas regularmente.
Defectos de datos Defectos de control Defectos de entrada y salida Defectos de la interfaz Defectos de gestión de almacenamiento Defectos de manejo de excepciones
Las inspecciones son una forma ideal de recopilar datos sobre el tipo de defectos que se producen.
Análisis estático automatizado Las inspecciones son una forma de análisis estatico, se examina el programa sin ejecutarlo. Los analizadores estáticos escanean el código, detectan posibles defectos y anomalías. El objetivo es llamar la atención del inspector sobre las anomalías del programa, pueden ser variables sin inicialización o que no se usen o datos cuyo valor puede estar fuera de alcance. Los analizadores estáticos son valiosos cuando se utiliza lenguaje de programación C.
Verificación y métodos formales Se basan en representaciones matemáticas. Se ocupan principalmente del análisis matemático de la especificación. Estos métodos requieren un análisis muy detallado de la especificación 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 crítico y seguro. Los métodos formales pueden utilizarse en diferentes etapas del proceso V&V:
1. 2.
Puede desarrollarse una especificación formal del sistema y analizarse matemáticamente para buscar inconsistencias. Es efectiva para descubrir errores. Puede verificarse formalmente que el código de un sistema software es consistente con su especificación, utilizando argumentos matemáticos. Es efectiva para detectar errores de diseño y programación.
Los métodos formales juegan un papel importante en el desarrollo de sistema de software crítico.
Desarrollo de software de Sala Limpia El desarrollo de software de Sala Limpia es una filosofía de desarrollo de software que utiliza dichos métodos 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 aproximación de Sala limpia al desarrollo del software se basa en cinco estrategias clave:
Especificación formal Desarrollo incremental Programación estructurada Verificación estática Pruebas estáticas del sistema
Existen tres equipos implicados cuando se utiliza el proceso de Sala Limpia para el desarrollo de grandes sistemas:
El equipo de especificación El equipo de desarrollo El equipo de certificación
El uso de sala limpia conduce generalmente a software con muy pocos errores.
EJERCICIOS 22.1 Señale las diferencias entre verificación y validación y explique porque la validación es un proceso particularmente difícil. La diferencia es que la verificación implica comprobar que el software está de acuerdo con su especificación mientras que la validación 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 dónde se pueden utilizar las pruebas para validar que el programa cumple con su propósito? 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 más problemas en el sistema.
22.4 Explique porque las inspecciones de programa son una técnica efectiva para descubrir errores en un programa. ¿Qué tipos de errores probablemente no sean descubiertos a través de las inspecciones? Porque la inspección es un proceso estático y no hay que preocuparse de las interacciones entre errores, además de buscar los defectos en un programa puede considerar atributos de calidad más amplios de un programa tales como grado de cumplimiento con los estándares, portabilidad y mantenibilidad. Por lo tanto, una única sesión de inspección puede descubrir muchos errores en un sistema y es menos costosa que realizar pruebas.
22.8 Explique porque puede ser rentable utilizar métodos formales en el desarrollo de sistemas software de seguridad típicos. ¿Por qué piensa usted que algunos desarrolladores de este tipo de sistemas están en contra del uso de los métodos formales? Debido a que estos métodos están diseñados exclusivamente para el desarrollo de dichos sistemas software es decir el programa desarrollado satisface su especificación, por lo tanto los errores de implementación no comprometan la confiabilidad. Y por lo tanto n o se incrementan los costos. Debido a que requieren notaciones específicas, 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 especificación.
