Your SlideShare is downloading. ×
  • Like
Calidad del software  cap1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Calidad del software cap1

  • 4,820 views
Published

 

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,820
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
181
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. CAPITULO 1 Verificación y ValidaciónAsegurando que un sofware satisface las necesidades del usuario Por Julio C. Alsina Ingeniería de Software
  • 2. Objetivos• Introducción a la verificación y validación del software y discusión acerca de las diferencias entre ambas.• Descripción del proceso de inspección de programa y su rol en la verificación y validación.• Explicación de análisis estático como técnica de verificación• Descripción del proceso de desarrollo del software Cleanroom Ingeniería de Software
  • 3. Tópicos cubiertos• Planificación de la Verificación y Validación• Inspecciones de Software• Análisis estático automatizado• Desarrollo del software Cleanroom Ingeniería de Software
  • 4. Verificación vs validación• Verificación: “Estamos creando el producto correctamente” El software debería ajustarse a su especificación• Validación: " Estamos creando el producto correcto" El software debería realizar lo que el usuario realmente necesita Ingeniería de Software
  • 5. El proceso de V & V• Es un proceso de ciclo de vida – V&V debería aplicarse en cada etapa en el proceso de software (Rev. Req., Diseño, Insp.Codigo, Prueba)• Tiene dos objetivos principales: – El descubrimiento de defectos en un sistema – El asegurar que un sistema es utilizable en una situación operacional Ingeniería de Software
  • 6. V&V Estática y dinámica• Inspecciones de Software: relacionadas con el análisis de una representación estática de un sistema para descubrir problemas (V&V estática) – Puede ser un suplemento de un documento basado en una herramienta y análisis de código• Prueba de Software: relacionadas con pruebas y observaciones del comportamiento del producto (V&V dinámica) – El sistema es ejecutado con datos de prueba y es observado su comportamiento operacional Ingeniería de Software
  • 7. V&V estáticas y dinámicas Static Verificación verification EstáticaRequirementsEspecif. de High-level Diseño de Formal Especificación Detailed Diseño specification Program Programaspecification Requerim. design Alto Nivel Formal design Detallado Dynamic Validación Prototype Prototipo validation Dinámica “Técnicas estáticas solo comprueban correspondencia con las especificaciones” “No demuestran que SW tiene utilidad operacional ni desempeño o fiabilidad” “Para validar un sistema de SW se requieren PRUEBAS” Ingeniería de Software
  • 8. Pruebas de programa “Son prácticas con programas que utilizan datos similares a los reales” “Examinan salidas buscando anomalías” “Pueden realizarse en fase de Implementación o despues de finalizar la misma”• Pueden revelar la presencia de errores, NO su ausencia• Una prueba exitosa es aquella en la que se descubren uno o mas errores• La única técnica de validación para requerimientos no funcionales• Debe ser utilizada conjuntamente con verificación estática para proveer un completo proceso de V&V Ingeniería de Software
  • 9. Tipos de Pruebas• Pruebas de Defectos – Pruebas diseñadas para descubrir defectos en los sistemas – Una prueba de defectos exitosa es aquella que revela la presencia de defectos en un sistema – Controladores obtienen sentimiento intuitivo de la fiabilidad del SW• Pruebas estadísticas – Pruebas diseñadas para reflejar la frecuencia de entradas de usuario. Utilizadas para estimación de fiabilidad (número de caidas del sistema). – Desempeño valora Tiempo Ejec. y Tiempo Respuesta Ingeniería de Software
  • 10. Metas de V& V• La Verificación y Validación deberían conceder confianza en que el software alcanza su propósito.• Esto NO significa que esté libre de defectos• Mas bien debería ser lo suficientemente bueno para su uso y el tipo de uso determinará el grado de confianza que es necesaria Ingeniería de Software
  • 11. Nivel de Confianza V & VDepende del propósito del sistema, expectativas delusuario y del ambiente de marketing – Función del Software • El nivel de confianza depende de cuan crítico es el software para una organización (Ej. sistemas criticos de medicina) – Expectativas del Usuario • Los usuarios pueden tener bajas expectativas de ciertos tipos de software. La tolerancia a fallas de sistema ha decrecido. – Ambiente de Marketing • Poner tempranamente un producto a la venta puede ser mas importante que encontrar defectos en el programa (Ej. Si clientes no estan dispuestos a pagar alto precio SW, son más tolerantes a fallas) Ingeniería de Software
  • 12. Pruebas y Depuración• Pruebas y depuración de defectos son procesos distintos• V&V están relacionados con el establecimiento de la existencia de defectos en un programa• Depuración está relacionada con localizar y reparar estos errores• Depuración considera formular una hipótesis acerca del comportamiento del programa, luego probar estas hipótesis para encontrar el error• Pueden apoyarse en herramientas interactivas integradas con un sistema de interpretación Ingeniería de Software
  • 13. El proceso de Depuración TestResultados Test Casos de results Specification Especificaciónde pruebas cases Pruebas Locate Design Repair Re-test Localizar Diseñar repair error Reparac Reparación de error Volver a error program error error error probar Ingeniería de Software
  • 14. Planeamiento de V & V• V&V es un proceso caro. Puede ocupar la mitad del presupuesto de desarrollo• Se necesita una planificación cuidadosa para obtener lo mejor de los procesos de pruebas e inspección• La planificación debería estar antes que nada en el proceso de desarrollo• El plan debería identificar el balance entre verificación estática y pruebas• La planficación de las pruebas se relaciona con la definición de estándares para el proceso de pruebas, mas que con la descripción de las pruebas de productos• Cuanto más crítico, mayor esfuerzo a verif. estáticas Ingeniería de Software
  • 15. El modelo de desarrollo VRequir ements Especif. de System Especif. de System Diseño del Detailed Diseñospecification specification design design Requerim. Sistema. Sistema. Detallado PlanAcceptance de Prueba System Plan de Prueba PlanSub-system de Prueba Module and Codificación integration integration unit code y prueba de test plan de Aceptación Integración sma. Integr.test plan Sub-sma. test plan and tess unidad y móduloServicio Service Prueba de Acceptance Prueba Integra- System Prueba Integra- Sub-system test Aceptación integration test ción Sistema integration test ción sub-sistema “Derivar planes de prueba a partir de las especificaciones y diseño del sistema” Ingeniería de Software
  • 16. La estructura de un plan de prueba de software• Proceso de pruebas ”Descripcion de fases principales del proceso”• Trazabilidad de requerimientos “Plantear de forma a probar individualmente todos los requerimientos”• Items probados ”Especificar los items de proceso de SW a probar”• Agenda de pruebas ”Calendarizar pruebas y asignar recursos”• Procedimientos de almacenamiento de pruebas ”Almacenar resultados. Debe ser posible auditar los procesos de prueba”• Requerimientos de software y hardware• Limitaciones ”Anticipar restricciones que puedan afectar al proceso” Ingeniería de Software
  • 17. Inspecciones de Software• Involucran al equipo examinando la fuente de representación con el objetivo de descubrir anomalías y defectos• No requieren ejecución de un sistema, de modo que pueden ser utilizadas antes de la implementación• Pueden ser aplicadas a cualquier representación del sistema (requerimientos, diseño, datos de prueba, etc.)• Técnica muy efectiva para descubrir errores Ingeniería de Software
  • 18. Exito de la Inspección• Muchos y diferentes defectos pueden ser descubiertos en una sola inspección. En pruebas, un defecto puede enmascarar otro de modo que son requeridas varias ejecuciones. Cada prueba normalmente conduce a una sola falla o defecto.• Resaltan la reutilización y el conocimiento de programación, de modo que los revisores están preparados para ver aquellos tipos de errores que aparecen comunmente. Ingeniería de Software
  • 19. Inspecciones y Pruebas• Las inspecciones y pruebas son complementarias y no técnicas de verificación opuestas• Ambas deberían ser utilizadas durante el proceso de V&V• Las inspecciones pueden chequear conformidad con una especificación, pero no conformidad con los requerimientos reales del cliente• Las inspecciones no pueden chequear características funcionales, como ser rendimiento, usabilidad, etc.• Las inspecciones sobrecargan el costo inicial pero conducen a ahorros luego que los equipos adquieren experiencia en su utilización. Ingeniería de Software
  • 20. Inspecciones de Programa• Enfoque formalizado a revisiones de documentos• Intento explícito para la DETECCIÓN de defectos (no la corrección)• Los defectos pueden ser errores lógicos, anomalías en el código que pueden indicar una condición errónea (por ej. una variable no inicializada) o el no cumplimiento de estándares. Ingeniería de Software
  • 21. Pre-condiciones para Inspección• Una especificación precisa debe estar disponible• Los miembros del equipo deben estar familiarizados con los estándares de la organización• Debe estar disponible el código sintácticamente correcto• Un checklist de errores debería estar preparado• La gerencia debe aceptar que la inspección incrementará los costos tempranamente en el proceso de software• La gerencia no debe utilizar las inspecciones en las evaluaciones del personal Ingeniería de Software
  • 22. El proceso de inspecciónPlanifica- Planning ción Panorama Overview Follow-up Seguimiento general Individual Preparación Re-elabora- Rework preparation individual ción Inspection Reunión de meeting Inspección Ingeniería de Software
  • 23. Procedimiento de Inspección• Panorama general del sistema presentado al equipo de inspección (autor describe objetivo del codigo)• Código y documentos asociados son distribuídos por adelantado al equipo de inspección• Preparacion individual de los participantes• La inspección se realiza y son descubiertos los errores (< 2hs). Cantidad depende de experiencia• Se realizan las modificaciones para reparar los errores descubiertos• La re-inspección puede o no ser necesaria (seguimiento)• El documento resultante es aprobado por el moderador Ingeniería de Software
  • 24. Equipos de Inspección• Constituídos por al menos 4 miembros: – El autor del código a ser inspeccionado – El inspector que encuentra los errores, omisiones e inconsistencias – El lector que lee el código al equipo – El moderador que dirige la reunión y anota los errores descubiertos (responsable de planificar) – Otros roles son secretario y moderador en jefe. Ingeniería de Software
  • 25. Checklists de Inspección• Un checklist de errores comunes debería utilizarse para dirigir la inspección• Un checklist de errores es dependiente del lenguaje de programación• Cuanto mas „débil‟ el tipo de chequeo, mas largo el checklist• Ejemplos: inicialización, nombrado de constantes, terminación de bucles, límites de arrays, etc. Ingeniería de Software
  • 26. Chequeos de inspección Clase de falta Chequeo de InspecciónFallas de datos -Están todas las variables inicializadas antes de que sus valores sean utilizados? - Han sido nombradas todas las constantes? - El límite inferior de los arrays debería ser 0, 1 u otro? - El límite superior de los arrays debería ser igual al tamño del array o a su tamaño menos 1? - Si se utilizan cadenas de caracteres, existe un delimitador explícitamente asignado?Fallas de control - Para cada sentencia condicional, es correcta la condición? - Cada bucle se termina? - Están correctamente puestos entre paréntesis las sentencias compuestas? - En las sentencias CASE, son posibles todos los casos que se incluyen?Fallas de entrada/salida - Son utilizadas todas las variables? - Todas las variables de salida tienen un valor asignado antes de que ocurra la salida?Fallas de interfase - Todas las llamadas a funciones y procedimientos tienen el número correcto de parámetros? - Coinciden los tipos de parámetros formales y casuales? - Están los parámetros en el orden correcto? - Si los componentes accesan la memoria compartida, tienen el mismo modelo de la estructura de memoria compartida?Fallas de administración - Si una estructura relacionada es modificada, han sido todos los enlaces correctamente reasignados?de almacenamiento - Si se utiliza almacenamiento dinámico, se ha distribuído el espacio correctamente? - Luego de que el espacio ya no sea necesario, es explícitamente desocupado?Fallas de administración - Han sido consideradas todas las posibles condiciones de error?de excepciones Ingeniería de Software
  • 27. Ratio de Inspección• 500 declaraciones/hora durante el panorama general• 125 declaraciones de origen/hora durante la preparación individual• 90-125 declaraciones/hora pueden ser inspeccionadas• Sin embargo, la inspección es un proceso caro• Inspeccionar 500 líneas cuesta acerca de 40 horas hombre (4 personas  1 hs. panorama gral. + 4 hs. Prep.Individual + 4 a 5 hs. Inspección) Ingeniería de Software
  • 28. Análisis estático automatizado• Los analizadores estáticos son herramientas de software para el procesamiento de texto fuente• Analizan el texto del programa e intentan descubrir condiciones potenciales de error y las ponen a disposición del equipo de V&V• Es muy efectivo como soporte para las inspecciones. Es un suplemento pero no puede reemplazar el proceso de inspección Ingeniería de Software
  • 29. Chequeos de análisis estático Clase de falta Chequeo de Análisis estáticoFallas de datos - Variables utilizadas antes de su inicialización - Variables declaradas pero nunca utilizadas - Variables asignadas dos veces pero nunca utilizadas entre asignaciones - Posibles violaciones de límites de arrays - Variables no declaradasFallas de control - Código no encontrado - Segmentos incondicionales dentro de buclesFallas de entrada/salida - Variables de salida doblesFallas de interfase - No coinciden los tipos de parámetros - No coinciden los números de parámetros - Resultados de función sin utilizarse - Funciones y procedimientos que no son llamadosFallas de administración de - Punteros no asignadosalmacenamiento - Punteros aritméticos Ingeniería de Software
  • 30. Etapas del análisis estático• Análisis de Control de Flujo. Chequea los bucles con salidas o entradas múltiples, encuentra código perdido, etc.• Análisis de uso de datos. Detecta variables no inicializadas, variables escritas dos veces sin una intervención asignada, variables que fueron declaradas pero nunca fueron usadas, etc.• Análisis de Interfase. Chequea la consistencia de declaraciones de rutinas y procedimientos y sus usos. Ingeniería de Software
  • 31. Etapas del Análisis Estático• Análisis del flujo de información. Identifica las dependencias de variables de entrada y salida. No detecta anomalías, pero resalta información para la inspección o revisión de código.• Análisis de rutas. Identifica las rutas utilizadas en el programa y analiza las declaraciones ejecutadas en esas rutas. Potencialmente útil en el proceso de revisión.• Estas etapas generan gran cantidad de información, que debe ser usada con cuidado Ingeniería de Software
  • 32. 138% more lint_ex.c  Listar programa#include <stdio.h>  Define función con 1 parametroprintarray (Anarray) int Anarray;{ printf(“%d”,Anarray);}main (){  Se llama función c/3 parametros int Anarray[5]; int i; char c; printarray (Anarray, i, c); Variables i y c declaradas printarray (Anarray) ; no reciben valor y result.no se usa}139% cc lint_ex.c  Compilación sin errores140% lint lint_ex.c  Lint SI DETECTA ERRORESlint_ex.c(10): warning: c may be used before set  Variables usadas sin inicializarlint_ex.c(10): warning: i may be used before setprintarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) #Argum. dif.a los declaradosprintarray, arg. 1 used inconsistently lint_ex.c(4) ::lint_ex.c(10)printarray, arg. 1 used inconsistently lint_ex.c(4) :: Análisis estáticolint_ex.c(11)printf returns value which is always ignored LINT
  • 33. Utilización del análisis estático• Particularmente valioso cuando un lenguaje como por ej. C es utilizado, el cual tiene un tipeo débil y por lo tanto varios errores pueden no ser detectados por el compilador• Menos efectivo en términos de costos para lenguajes como Java, que tienen fuertes controles de tipeo y pueden por lo tanto, detectar varios errores durante la compilación Ingeniería de Software
  • 34. Desarrollo de software de „Sala Limpia‟• El nombre se deriva del proceso de „Sala Limpia‟ en la fabricación de semiconductores. La filosofía es evitar los defectos antes que corregirlos.• Reemplaza a pruebas de unidades de componentes por inspeccion para comprobacion de consistencia con especificaciones• El proceso de desarrollo está basado en: – Especificación formal – Desarrollo incremental – Verificación estática utilizando argumentos de corrección – Pruebas estadísticas para determinar la fiabilidad de los programas Ingeniería de Software
  • 35. El proceso de „Sala Limpia‟ Formally Reparación del Error Error rework Formalizar specify systemEspecificación Define Definir Construct Construir Formally Verificar Integrate Integrar software incrementos de structured programa verify código increment incremento increments software program estructurado code formalmente Develop Desarrollar operational perfil Design Diseñar Test Pruebas profile operacional statistical integrated pruebas sistema tests system estadísticas integrado Ingeniería de Software
  • 36. Características del proceso de Sala Limpia• Especificación formal utilizando un modelo de transición de estados• Desarrollo incremental• Programación estructurada – se utilizan técnicas de control limitado y abstracción• Verificación estática utilizando inspecciones rigurosas• Pruebas estadísticas del sistema (se basa en el perfil operacional) Ingeniería de Software
  • 37. Desarrollo Incremental Especificación Frozen specification congelada Establish Establecer Formal Especificación Develop s/w Desarrollo de Deliver Entrega delrerquirements requerimientos specification Formal increment Incremento de sw software Software Solicitud de ements change request Requir cambio de requerimientos Ingeniería de Software
  • 38. Especificación Formal e Inspecciones• El modelo basado en estados es una especificación del sistema y el proceso de inspección chequea el programa contra este modelo• El enfoque de programación es definido de manera a que la correspondencia entre el modelo y el sistema sea clara• Argumentos matemáticos (no pruebas) son utilizados para elevar la confianza en el proceso de inspección Ingeniería de Software
  • 39. Equipos del proceso de „Sala Limpia‟• Equipo de Especificación.. Responsable del desarrollo y mantenimiento de la especificación del sistema.• Equipo de Desarrollo. Responsable por desarrollar y verificar el software. El software NO es ejecutado o compilado durante este proceso.• Equipo de Certificación. Responsable por el desarrollo de una serie de pruebas estadísticas para ejercitar el software luego del desarrollo. Modelos de crecimiento de la fiabilidad son utilizados para determinar cuando la fiabilidad es aceptable. Ingeniería de Software
  • 40. Evaluación del proceso de „Sala Limpia‟• Los resultados en IBM han sido impresionantes con algunas fallas descubiertas en sistemas entregados• Evaluación independente muestra que el proceso no es mas costoso que otros enfoques• Menos errores que en un proceso de desarrollo „tradicional‟• No está claro como este enfoque puede ser transferido a un ambiente con ingenieros menos capacitados o menos motivados Ingeniería de Software
  • 41. Puntos claves• La verificación y validación no son lo mismo. La verficación muestra conformidad con la especificación; la validación muestra que el programa satisface las necesidades del cliente• Los planes de prueba deberían ser elaborados para guiar el proceso de pruebas• Las técnicas de verificación estática consideran la examinación y el análisis del programa para la detección de errores• Las inspecciones de programa son muy efectivas para descubrir errores Ingeniería de Software
  • 42. Puntos claves• Las inspecciones de código de programa son realizadas por un equipo pequeño para localizar fallas• Las herramientas de análisis estático pueden descubrir anomalías en los programas las cuales pueden ser indicadores de fallas en el código• El proceso de desarrollo de „Sala Limpia‟ depende del desarrollo incremental, verificación estática y pruebas estadísticas Ingeniería de Software