©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verificación y Validación.

Presentación del tema: "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verificación y Validación."— Transcripción de la presentación:

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verificación y Validación

2 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 2 Objetivos l Introducir la verificación y validación de software y para examinar la distinción entre ellos l Describir el proceso de inspección del programa y su papel en la V & V l Explicar el análisis estático como una verificación técnica l Describir el proceso de desarrollo de software

3 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 3 Tópicos expuestos l Planificación de la validación y verificación l Inspecciones de software l Análisis estático automatizado l Verificación y métodos formales

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 4 l Verificación: “¿Estamos construyendo bien el producto?". l El software debe ser conforme a su especificación. l Validación: “¿Lo que estamos construyendo es realmente lo que el cliente quiere?". l El software debe hacer lo que el usuario realmente necesita. Verificación frente a la validación

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 5 l Toda la vida es un ciclo de proceso - V & V debe ser Aplicado en cada etapa del proceso del software. l Tiene dos objetivos principales El descubrimiento de los defectos en un sistema; La evaluación de si el sistema es útil y utilizable en una situación operacional. El proceso de V & V

6 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 6 V & V objetivos l Verificación y validación debe establecer la confianza de que el software es apto para el propósito. l Esto NO quiere decir completamente libre de defectos. l Por el contrario, debe ser lo suficientemente bueno para su uso y el tipo de uso para determinar el grado de confianza que se necesita.

7 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 7 V & V confianza l Depende de la finalidad del sistema, las expectativas de los usuarios y el medio ambiente comercialización Función del software El nivel de confianza depende de la forma en que el software es crítico para una organización. Las expectativas de los usuarios Los usuarios pueden tener bajas expectativas de ciertos tipos de software. Marketing environment Obtención de un producto en el mercado a principios puede ser más importante que encontrar defectos en el programa.

8 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 8 l Inspecciones de software. Preocupada con el análisis de La estática sistema para descubrir los problemas de representación (estática de verificación) Puede ser complemento de la herramienta basada en el documento y análisis de código l Pruebas de software. Preocupado y con el ejercicio Observar el comportamiento del producto (dinámica de verificación) El sistema se ejecuta con los datos de las pruebas de funcionamiento y su comportamiento se observa Estáticas y dinámicas de verificación

9 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 9 Estática y dinámica de V & V

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 10 l Puede revelar la presencia de sus errores no Ausencia. l La única técnica de validación de los requisitos no funcionales como el software tiene que ser ejecutados para ver cómo se comporta. l Debería utilizarse junto con estática Verificación para prestar toda la cobertura de V & V. Programa de pruebas

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 11 l Pruebas de Defecto Pruebas diseñadas para descubrir los defectos del sistema. El éxito de una prueba es un defecto que revela la presencia de defectos en un sistema. Trata en el Capítulo 23 l Pruebas de validación Para poner de manifiesto que el software cumple con sus requisitos. El éxito es una prueba que demuestra que uno los requisitos que ha sido debidamente aplicada. Tipos de pruebas

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 12 l Pruebas de defecto y depuración son distintos Procesos. l Verificación y validación se refiere a establecer la existencia de defectos en un programa. l Depuración se refiere a la localización y la Reparación de estos errores. l Depuración implica la formulación de una hipótesis Sobre el comportamiento del programa entonces estas pruebas Hipótesis para encontrar el error del sistema. Pruebas y depuración

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 13 El proceso de depuración

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 14 l Se necesita una planificación cuidadosa para obtener el máximo rendimiento de pruebas y de control de procesos. l La planificación debe empezar temprano en el proceso de desarrollo. l El plan debe determinar el equilibrio entre la verificación y las pruebas estáticas. l Prueba acerca de la planificación es la definición de normas para el proceso de prueba en vez de describir las pruebas de productos. V & V de planificación

15 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 15 El modelo de desarrollo en V

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 16 La estructura de un plan de prueba de software l El proceso de pruebas. l Requisitos de trazabilidad. l Probado artículos. l Calendario de pruebas. l Prueba de los procedimientos de registro. l Requisitos de hardware y software. l Limitaciones.

17 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 17 El plan de prueba de software

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 18 Software de inspecciones l Se trata de personas el examen de la fuente de representación con el objetivo de descubrir las anomalías y defectos. l Inspecciones no requieren la ejecución de un sistema que puede ser usado antes de su ejecución. l Que pueden aplicarse a cualquier representación del sistema (requisitos, diseño, configuración de datos, los datos de los ensayos, etc.) l Ellos han demostrado ser una técnica eficaz para descubrir los errores del programa.

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 19 Éxito en la inspección l Muchos defectos pueden ser descubiertos en una sola inspección. En las pruebas, un defecto, puede enmascarar la otra a fin de varias de las ejecuciones son obligatorios. l La reutilización de dominio y conocimiento de programación de forma es probable que los encuestados han visto los tipos de errores que comúnmente surgen.

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 20 Inspecciones y ensayos l Inspecciones y pruebas son complementarias y no opuestas técnicas de verificación. l Ambos deben ser utilizados durante el proceso de V & V. l Las inspecciones pueden comprobar la conformidad con una especificación, pero no de conformidad con la necesidades reales del cliente. l Inspecciones no pueden comprobar las características no funcionales, tales como rendimiento, facilidad de uso, etc

21 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 21 Programa de inspecciones l Formalizado de revisión de documentos l Destinados expresamente para detección de defectos (no de corrección). l Defectos pueden ser errores lógicos, anomalías en el código que podría indicar un error (por ejemplo un uninitialised variable) o el incumplimiento de las normas.

22 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 22 Pre-condiciones de la Inspección l Una especificación debe estar disponible. l Los miembros del equipo deben estar familiarizados con el Normas de organización. l Sintácticamente correcto código u otro sistema de representación debe estar disponible. l Una lista de comprobación de errores se deben preparar. l Debemos aceptar que la gestión de la inspección Un aumento de los costes en una fase temprana del proceso del software. l Gestión de las inspecciones no deben utilizar para el personal De evaluación, es decir saber que se equivoca.

23 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 23 El proceso de inspección

24 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 24 Procedimiento de inspección l Vista general del sistema presentado al equipo de inspección. l Código y los documentos asociados son Distribuido a equipo de inspección con antelación. l Se lleva a cabo la inspección y descubrió errores Se señaló. l Se realicen modificaciones al descubierto reparación Errores. l Nueva inspección puede ser o no ser necesaria.

25 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 25 Funciones de inspección

26 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 26 Listas de control de inspección l Lista de comprobación de errores comunes que deben utilizarse Conducir la inspección. l Listas de comprobación de error son el lenguaje de programación Dependientes y reflejan la característica errores que puedan surgir en la lengua. l En general, el «débil» el tipo de control, la más grande la lista de verificación. l Ejemplos: Inicialización, constante de nombres, finalización de bucle, serie de límites, etc

27 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 27 Comprobaciones de inspección 1

28 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 28 Comprobaciones de inspección 2

29 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 29 Tasa de inspección l 500 declaraciones por hora durante la visión de conjunto. l 125 declaración de fuente / hora durante el individuo Preparación. l 90-125 estados / hora pueden ser inspeccionados. l Inspección, por lo tanto, es un proceso muy caro. l La inspección de 500 líneas cuesta alrededor de 40 horas / hombre esfuerzo - alrededor de £ 2800 en el Reino Unido las tasas.

30 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 30 Automatizados de análisis l Los analizadores son herramientas de software para procesamiento de textos fuente. l Que analizar el texto del programa y tratar de descubrir posibles errores y llevar estas condiciones a la atención del equipo de V & V. l Ellos son muy eficaces como ayuda a las inspecciones - son un complemento pero no un sustituto de las inspecciones.

31 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 31 Los controles de análisis

32 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 32 Etapas de análisis l Control de análisis de flujo. Con los controles de bucles múltiples puntos de entrada o salida, se encuentra inaccesible al Código, etc l Uso de datos de análisis. Detecta sin inicializar Variables, variables escritas dos veces sin una Intervenir asignación, variables que son Declarado pero nunca utilizada, etc l Interfaz de análisis. La coherencia de los controles Rutina y el procedimiento y sus declaraciones Uso

33 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 33 Etapas de análisis l Análisis del flujo de información. Identifica el Dependencias de variables de salida. No Detectar anomalías, pero sí pone de manifiesto Información de código de inspección o revisión l Ruta de análisis. Identifica los caminos a través del programa y establece los ejecutados en ese camino. Una vez más, potencialmente útiles en el proceso de examen l Ambas etapas de generar grandes cantidades de información. Deben utilizarse con cuidado.

34 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 34 LINT análisis

35 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 35 El uso de análisis l Especialmente valioso cuando un lenguaje como C es que se ha utilizado poco a escribir y, por tanto, son muchos los errores detectados por el compilador, l Menos rentable para lenguajes como Java que tienen un fuerte tipo de control y por lo tanto pueden detectar muchos errores durante la compilación.

36 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 36 Verificación y métodos formales l Métodos formales pueden ser utilizados cuando una especificación matemática del sistema de producción. l Se trata de la última verificación técnica estática. l Se trata de un análisis matemático detallado de la especificación formal y pueden desarrollar los argumentos de que un programa se ajusta a sus especificaciones matemáticas.

37 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 37 Argumentos a favor de métodos formales l La elaboración de un pliego de matemáticas requiere de un análisis detallado de los requisitos y es probable que descubrir errores. l Que pueden detectar errores de aplicación antes de la prueba cuando el programa se analiza junto con el pliego de condiciones.

38 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 38 Argumentos en contra de métodos formales l Requieren notaciones especializadas que no puede ser entendido por los expertos de dominio. l Muy caro para elaborar un pliego de condiciones y aún más costoso para demostrar que un programa que cumple con la especificación. l Puede ser posible alcanzar el mismo nivel de confianza en un programa más barato utilizar otras técnicas de V & V.

39 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 39 l El nombre se deriva de la «blanca» En proceso de fabricación de semiconductores. El Filosofía es evitar defectos en lugar de Defecto eliminación. l Este proceso de desarrollo de software se basa en: Incremental de desarrollo; Especificación formal; Los argumentos de verificación mediante la corrección; Estadística de prueba para determinar la fiabilidad del programa. Desarrollo de software de Cuarto Limpio

40 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 40 El proceso de cuarto limpio

41 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 41 Las características del proceso de cuarto limpio l Especificación formal utilizando un modelo de estado de transición. l Incremental de desarrollo en la que el cliente da prioridad a los incrementos. l La programación estructurada - un control limitado y abstracción construcciones se utilizan en el programa. l Los rigurosos de verificación mediante inspecciones. l Estadística de prueba del sistema (incluidos en el cap. 24).

42 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 42 Especificación formal e inspecciones l El estado es un modelo basado en la especificación del sistema y el proceso de inspección del programa de controles en contra de este mode.l l El enfoque de programación se define de modo que la correspondencia entre el modelo y el sistema está claro. l Matemáticas argumentos (no las pruebas) se utilizan para aumentar la confianza en el proceso de inspección.

43 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 43 l Especificación de equipo. Responsable del desarrollo Y el mantenimiento de la especificación del sistema. l Equipo de desarrollo. Responsable El desarrollo y verificar el software. El El software no se ejecuta o incluso compilado Durante este proceso. l Equipo de certificación. Responsable del desarrollo Una serie de pruebas estadísticas para ejercer el software Después el desarrollo. Fiabilidad de los modelos de crecimiento Utilizados para determinar cuándo es aceptable fiabilidad. Equipos de proceso de cuarto limpio

44 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 44 l Los resultados de utilizar el proceso de blancas han sido muy impresionante, con algunos fallos descubiertos en los sistemas de entrega. l Independiente de que la evaluación muestra Proceso no es más caro que otros Enfoques. l Hubo menos errores que en una "tradicional" proceso de desarrollo. l Sin embargo, el proceso no es muy utilizada. No está claro cómo este enfoque se pueden transferir A un ambiente con menos calificados o menos Motivados ingenieros de software. Evaluación del proceso de cuarto limpio

45 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 45 Puntos clave l Verificación y validación no son la misma cosa. Muestra de verificación de conformidad con la especificación, validación muestra que el programa responda a las necesidades del cliente. l Prueba deben elaborar planes para guiar el proceso de pruebas. l Los técnicas de verificación incluirá un examen y análisis del programa para la detección de errores.

46 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 46 Puntos clave l Programa de inspecciones son muy eficaces en el descubrimiento de errores. l Código de programa en las inspecciones es sistemáticamente controlados por un pequeño equipo para localizar las fallas de software. l Herramientas de análisis puede descubrir programa anomalías que pueden ser una indicación de fallas en el código. l La blanca proceso de desarrollo depende de incrementales de desarrollo, la verificación estática y pruebas estadísticas.