Está en la página 1de 38
Universidad de Tarapacá Verificación y Validación Tecnologías de Desarrollo de Software Ricardo Spencer

Universidad de Tarapacá

Verificación y Validación

Tecnologías de Desarrollo de Software

Ricardo Spencer

Objetivos

Introducir la verificación y validación de software y hablar de la diferencia entre ellos. Describir el proceso de inspección de programa y su papel en la V & V. Explicar el análisis estático como una técnica de verificación. Describir el proceso de desarrollo de software Cleanroom.

estático como una técnica de verificación. Describir el proceso de desarrollo de software Cleanroom. 2 de

2 de 37

Tópicos a cubrir

Planificación de validación y verificación. Inspecciones de software. Análisis estático automatizado. Desarrollo de software Cleanroom.

Inspecciones de software. Análisis estático automatizado. Desarrollo de software Cleanroom. 3 de 37

3 de 37

Verificación vs Validación

Verificación:

"Se esta construyendo adecuadamente el producto"Verificación vs Validación Verificación: El software debe estar conforme a sus especificaciones. Validación:

El software debe estar conforme a sus especificaciones. Validación:

"Se esta construyendo el producto adecuado"debe estar conforme a sus especificaciones. Validación: El software debe hacer lo que el usuario requiere

El software debe hacer lo que el usuario requiere

Validación: "Se esta construyendo el producto adecuado" El software debe hacer lo que el usuario requiere

4 de 37

El proceso V & V

Es un proceso del ciclo de vida - V & V debe aplicarse en cada fase del proceso de software. Tiene dos objetivos principales:

El descubrimiento de defectos en el sistema.del proceso de software. Tiene dos objetivos principales: La evaluación de si el sistema es útil

La evaluación de si el sistema es útil o no en una determinada situación operacional.fase del proceso de software. Tiene dos objetivos principales: El descubrimiento de defectos en el sistema.

defectos en el sistema. La evaluación de si el sistema es útil o no en una

5 de 37

Metas de V & V

La verificación y la validación deberían establecer la seguridad que el software es adecuado para el objetivo. Esto NO significa que este completamente libre de defectos. Mejor dicho, debe estar bastante bien para el uso deseado y el tipo de uso determinará el grado de seguridad que es necesario.

estar bastante bien para el uso deseado y el tipo de uso determinará el grado de

6 de 37

Seguridad V & V

Depende de el objetivo del sistema, expectativas del usuario y ambiente de marketing. Función de software

usuario y ambiente de marketing. Función de software El nivel de confianza depende de cuan crítico

El nivel de confianza depende de cuan crítico es el software en la organización.

Expectativas del usuario

Los usuarios pueden tener expectativas bajas de ciertas clases de software. de software.

Ambiente de marketing

bajas de ciertas clases de software. Ambiente de marketing Conseguir un producto en el me rcado

Conseguir un producto en el mercado tempranamente puede ser más importante que el descubrimiento de defectos en el programa.

7 de 37

Verificación dinámica y estática

Inspecciones de Software.

Se refiere al análisis de la representación estática del sistema para descubrir problemas (verificación estática).Verificación dinámica y estática Inspecciones de Software. • Puede ser suplementado por el documento basado en

• Puede ser suplementado por el documento basado en herramienta análisis de código

Pruebas de Software.

Se refiere al ejercicio y observación del comportamiento del producto (verificación dinámica). del producto (verificación dinámica).

• El sistema es ejecutado con datos de prueba y su comportamiento operacional es observado.

dinámica). • El sistema es ejecutado con datos de prueba y su comportamiento operacional es observado.

8 de 37

V & V dinámica y estática

V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37
V & V dinámica y estática 9 de 37

9 de 37

Pruebas de programa

Puede revelar la presencia de errores, NO su ausencia. Una prueba exitosa consiste en descubrir uno o mas errores. Sólo se considera la técnica de validación para requerimientos no-funcionales. Debe ser usada en conjunto con la verificación estática.

validación para requerimientos no-funcionales. Debe ser usada en conjunto con la verificación estática. 10 de 37

10 de 37

Tipos de prueba

Pruebas de Defecto.

Pruebas diseñadas para descubrir defectos en el sistema. sistema.

Un prueba de defectos exitosa es aquella que revela la presencia de defectos en el sistema. presencia de defectos en el sistema.

Pruebas de Validación.

Propuesto para mostrar que el software cumple con los requerimientos. requerimientos.

Una prueba exitosa es una que muestra que los requerimientos han sido correctamente implementados. requerimientos han sido correctamente implementados.

Una prueba exitosa es una que muestra que los requerimientos han sido correctamente implementados. 11 de

11 de 37

Prueba y depuración

Las pruebas de defecto y depuración son procesos distintos. La verificación y la validación están preocupadas por el establecimiento de la existencia de defectos en un programa. La depuración está preocupada de la localización y reparación de estos errores. La depuración implica la formulación de una hipótesis sobre el comportamiento del programa y la prueba de la hipótesis para encontrar los errores en el sistema.

sobre el comportamiento del programa y la prueba de la hipótesis para encontrar los errores en

12 de 37

El proceso de depuración

El proceso de depuración 13 de 37
El proceso de depuración 13 de 37
El proceso de depuración 13 de 37

13 de 37

Planificación de V & V

Se requiere que la planificación cuidadosa se haga en más procesos de inspección y pruebas. La planificación debería comenzar temprano en el proceso de desarrollo. El plan debería identificar el equilibrio entre verificación estática y pruebas. La planificación de prueba es sobre la definición de estándares para el proceso de pruebas más bien que describir pruebas de producto.

es sobre la definición de estándares para el proceso de pruebas más bien que describir pruebas

14 de 37

El modelo V de desarrollo

El modelo V de desarrollo 15 de 37
El modelo V de desarrollo 15 de 37

15 de 37

La estructura de un plan de prueba de software

El proceso de pruebas. La trazabilidad de los requerimientos. Componentes probados. Calendario de pruebas. Procedimientos de registro de pruebas. Requerimientos de hardware y software. Restricciones.

de pruebas. Procedimientos de registro de pruebas. Requerimientos de hardware y software. Restricciones. 16 de 37

16 de 37

Inspecciones de software

Éstos implican a la gente que examina la representación fuente con el objetivo de descubrir anomalías y defectos. Las inspecciones no requieren la ejecución de un sistema por lo que puede ser usado antes de la implementación. Pueden ser aplicados a cualquier representación del sistema (requerimientos, diseño, datos de configuración, datos de prueba, etc.). Han sido mostrados para ser una técnica eficaz para descubrir errores de programa.

datos de prueba, etc.). Han sido mostrados para ser una técnica eficaz para descubrir errores de

17 de 37

Inspección exitosa

Muchos defectos diferentes pueden ser descubiertos en una sola inspección. En pruebas, un defecto, puede enmascarar otros en ejecuciones críticas que son requeridas. Los revisores del dominio de reutilización y el conocimiento de programación probablemente habrán visto los tipos de error que comúnmente surgen.

y el conocimiento de programación probablemente habrán visto los tipos de error que comúnmente surgen. 18

18 de 37

Inspecciones y Pruebas

Las inspecciones y las pruebas son complementarias y no son técnicas de verificación opuestas. Ambas deberían ser usadas durante el proceso V & V. Las inspecciones pueden comprobar la conformidad con una especificación, pero no la conformidad con los verdaderos requerimientos del cliente. Las inspecciones no pueden comprobar características no funcionales como el rendimiento, usabilidad, etc.

Las inspecciones no pueden comprobar características no funcionales como el rendimiento, usabilidad, etc. 19 de 37

19 de 37

Inspecciones de Programa

Acercamiento formalizado para documentar revisiones. Propuesto explícitamente para la detección de defectos (no corrección). Los defectos pueden ser errores lógicos, anomalías en el código que podrían indicar una condición errónea (por ejemplo: una variable no inicializada) o incumplimiento con los estándares.

una condición errónea (por ejemplo: una variable no inicializada) o incumplimiento con los estándares. 20 de

20 de 37

El Proceso de Inspección

El Proceso de Inspección 21 de 37
El Proceso de Inspección 21 de 37

21 de 37

Procedimiento de Inspección

Descripción del sistema presentada al equipo de inspección. El código y los documentos asociados son distribuidos de antemano al equipo de inspección. La inspección ocurre y los errores descubiertos son anotados. Las modificaciones son hechas para reparar los errores descubiertos. La nueva inspección puede o puede que no sea requerida.

son hechas para reparar los errores descubiertos. La nueva inspección puede o puede que no sea

22 de 37

Listas de comprobación de inspección

La lista de comprobación de errores comunes debería ser usada para dirigir la inspección. Las listas de comprobación de error son dependientes del lenguaje de programación y reflejan los errores característicos que probablemente surgen en el lenguaje. En general, “más débil” la comprobación de tipo, más grande la lista de comprobación. Ejemplos: Inicialización, nombramiento de constantes, terminación de un ciclo, dimensión de arreglos, etc.

Ejemplos: Inicialización, nombramiento de constantes, terminación de un ciclo, dimensión de arreglos, etc. 23 de 37

23 de 37

Chequeos de Inspección

Chequeos de Inspección Data faults Are all program variables initialised before their values are used? Have

Data faults Are all program variables initialised before their values are used? Have all constants been named? Should the upper bound of arrays be equal to the size of the array or Size -1? If character strings are used, is a de limiter explicitly assigned? Is there any possibility of buffer overflow?

Control faults

For each co nditional statement, is the condition correct? Is each loop certain to terminate? Are compound statements correctly bracketed? In case statements, are all possible cases accounted for? If a break is required after each case in case statements, has it been included?

Input/output faults

Are all input variables used? Are all output variables assigned a value before they are output? Can unexpected inputs cause corruption?

24 de 37

Valores de Inspección

500 declaraciones/hora durante la descripción. 125 declaraciones fuente/hora durante la preparación individual. 90-125 declaraciones/hora pueden ser inspeccionadas. La inspección es por lo tanto un proceso caro. La inspección de 500 líneas cuesta aproximadamente 40 hombres/hora de esfuerzo - sobre £2800 en valores del Reino Unido.

de 500 líneas cuesta aproximadamente 40 hombres/hora de esfuerzo - sobre £2800 en valores del Reino

25 de 37

Análisis estático automatizado

Los analizadores estáticos son herramientas software para el procesamiento de texto fuente. Ellos analizan el texto de programa y tratan de descubrir condiciones potencialmente erróneas y traer éstos a la atención del equipo V & V. Estos son muy eficaces como una ayuda a las inspecciones - son un suplemento, pero no un reemplazo para las inspecciones.

muy eficaces como una ayuda a las inspecciones - son un suplemento, pero no un reemplazo

26 de 37

Chequeo de análisis estático

Fault class

Static analysis check

 

Data faults

Variables used before initialisation Variables declared but never used Variables assigned twice but never used between assignments Possible array bound violations Undeclared variables

Control faults

Unreachable code Unconditional branches into loops

 

Input/output faults

Variables

output

twice

with

no

intervening

assignment

output twice with no intervening assignment Interface faults Storage management faults Parameter type

Interface faults

Storage management faults

Parameter type mismatches Parameter number mismatches Non-usage of the results of functions Uncalled functions and procedures

Unassigned pointers Pointer arithmetic

27 de 37

Etapas del análisis estático

Análisis de flujo de control.

Etapas del análisis estático Análisis de flujo de control. Chequeo para ciclos con salida múltiple o

Chequeo para ciclos con salida múltiple o puntos de entrada, el código descubrimiento de código ilegible, etc.

Análisis de uso de datos.

Detecta variables no inicializadas, variables escritas dos veces sin una asignación intermedia, variables que son declaradas, pero nunca , variables escritas dos veces sin una asignación intermedia, variables que son declaradas, pero nunca usadas, etc.

Análisis de interfaz.

declaradas, pero nunca usadas, etc. Análisis de interfaz. Comprueba la consistencia de rutina y declaraciones de

Comprueba la consistencia de rutina y declaraciones de procedimiento y su uso.

28 de 37

Etapas del análisis estático

Análisis de flujo de información.

Identifica las dependencias de las variables de salida. No descubre anomalías en sí mismo, pero destaca la información para inspección de código o revisión. descubre anomalías en sí mismo, pero destaca la información para inspección de código o revisión.

Análisis de Path.

Identifica los path del programa y dispone las declaraciones ejecutadas en aquel path. Otra vez, potencialmente útil en el proceso de revisión. ejecutadas en aquel path. Otra vez, potencialmente útil en el proceso de revisión.

Estas últimas dos etapas generan cantidades enormes de información. Deben ser usados con cuidado.

revisión. Estas últimas dos etapas generan cantidades enormes de información. Deben ser usados con cuidado. 29

29 de 37

Análisis estático LINT

{

{

}

Análisis estático LINT { { } 30 de 37

30 de 37

Desarrollo de software Cleanroom

El nombre es sacado del proceso de “Cleanroom” en la fabricación de semiconductores. La filosofía es la evasión de defectos más bien que el retiro de defectos. Este proceso de desarrollo de software está basado en:

Desarrollo incremental;Este proceso de desarrollo de software está basado en: Especificación formal; Verificación estática usando

Especificación formal;de software está basado en: Desarrollo incremental; Verificación estática usando argumentos de exactitud;

Verificación estática usando argumentos de exactitud;basado en: Desarrollo incremental; Especificación formal; Pruebas estadísticas para determinar la fiabilidad del

Pruebas estadísticas para determinar la fiabilidad del programa.en: Desarrollo incremental; Especificación formal; Verificación estática usando argumentos de exactitud; 31 de 37

estática usando argumentos de exactitud; Pruebas estadísticas para determinar la fiabilidad del programa. 31 de 37

31 de 37

El proceso Cleanroom

El proceso Cleanroom 32 de 37
El proceso Cleanroom 32 de 37

32 de 37

Características del proceso Cleanroom

Especificación formal usando un modelo de transición de estados. Desarrollo incremental donde el cliente prioriza los incrementos. Programación estructurada – el control limitado y los constructores de abstracción son usados en el programa. Verificación estática usando inspecciones rigurosas. Pruebas estadísticas del sistema.

en el programa. Verificación estática usando inspecciones rigurosas. Pruebas estadísticas del sistema. 33 de 37

33 de 37

Equipos del proceso Cleanroom

Equipo de especificación.

Equipos del proceso Cleanroom Equipo de especificación. Responsable del desarrollo y mantención de la especificación

Responsable del desarrollo y mantención de la especificación del sistema.

Equipo de desarrollo.

Responsable del desarrollo y verificación del software. El software NO es ejecutado o hasta compilado durante este proceso. rificación del software. El software NO es ejecutado o hasta compilado durante este proceso.

Equipo de certificación.

compilado durante este proceso. Equipo de certificación. Responsable de desarrollar un juego de pruebas estadísticas

Responsable de desarrollar un juego de pruebas estadísticas para probar el software después del desarrollo. Los modelos de crecimiento de confiabilidad solían determinar cuando la confiabilidad era aceptable.

34 de 37

Evaluación del proceso Cleanroom

Los resultados de usar el proceso Cleanroom han sido muy impresionantes con pocas faltas descubiertas en sistemas entregados. La evaluación independiente muestra que el proceso no es más caro que otros acercamientos. Había menos errores que en un proceso de desarrollo “tradicional”. Sin embargo, el proceso no es extensamente usado. No está claro como este acercamiento puede ser transferido a un ambiente con ingenieros de software menos expertos o menos motivados.

acercamiento puede ser transferido a un ambiente con ingenieros de software menos expertos o menos motivados.

35 de 37

Resumen

La verificación y la validación no son la misma cosa. La verificación muestra la conformidad con la especificación; la validación muestra que el programa satisface las necesidades del cliente. Los planes de prueba deberían ser trazados para guiar el proceso de pruebas. Las técnicas de verificación estática involucran la examinación y el análisis del programa para la detección de errores.

de verificación estática involucran la examinación y el análisis del programa para la detección de errores.

36 de 37

Resumen

Las inspecciones de programa son muy eficaces en el descubrimiento de errores. El código de programas en inspecciones es sistemáticamente comprobado por un pequeño equipo para localizar faltas de software. Las herramientas de análisis estático pueden descubrir anomalías en el programa que pueden ser una indicación de faltas en el código. El proceso de desarrollo Cleanroom depende del desarrollo incremental, verificación estática y pruebas estadísticas.

de desarrollo Cleanroom depende del desarrollo incremental, verificación estática y pruebas estadísticas. 37 de 37

37 de 37

Universidad de Tarapacá Próxima Unidad: Mejora de Procesos Tecnologías de Desarrollo de Software Ricardo Spencer

Universidad de Tarapacá

Próxima Unidad:

Mejora de Procesos

Tecnologías de Desarrollo de Software

Ricardo Spencer