Universidad de Tarapac

Verificacin y Validacin

Tecnologas de Desarrollo de Software

Ricardo Spencer

Objetivos
Introducir la verificacin y validacin de software y hablar de la diferencia entre ellos. Describir el proceso de inspeccin de programa y su papel en la V & V. Explicar el anlisis esttico como una tcnica de verificacin. Describir el proceso de desarrollo de software Cleanroom.
2 de 37

Tpicos a cubrir
Planificacin de validacin y verificacin. Inspecciones de software. Anlisis esttico automatizado. Desarrollo de software Cleanroom.

3 de 37

Verificacin vs Validacin
Verificacin:
"Se esta construyendo adecuadamente el producto"

El software debe estar conforme a sus especificaciones. Validacin:

"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. La evaluacin de si el sistema es til o no en una determinada situacin operacional.

5 de 37

Metas de V & V
La verificacin y la validacin deberan 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.
6 de 37

Seguridad V & V
Depende de el objetivo del sistema, expectativas del usuario y ambiente de marketing. Funcin de software
El nivel de confianza depende de cuan crtico es el software en la organizacin.

Expectativas del usuario

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

Ambiente de marketing
Conseguir un producto en el mercado tempranamente puede ser ms importante que el descubrimiento de defectos en el programa.
7 de 37

Verificacin dinmica y esttica

Inspecciones de Software.
Se refiere al anlisis de la representacin esttica del sistema para descubrir problemas (verificacin esttica).
Puede ser suplementado por el documento basado en herramienta anlisis de cdigo

Pruebas de Software.
Se refiere al ejercicio y observacin del comportamiento del producto (verificacin dinmica).
El sistema es ejecutado con datos de prueba y su comportamiento operacional es observado.

8 de 37

V & V dinmica y esttica

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. Slo se considera la tcnica de validacin para requerimientos no-funcionales. Debe ser usada en conjunto con la verificacin esttica.
10 de 37

Tipos de prueba
Pruebas de Defecto.
Pruebas diseadas para descubrir defectos en el sistema. Un prueba de defectos exitosa es aquella que revela la presencia de defectos en el sistema.

Pruebas de Validacin.
Propuesto para mostrar que el software cumple con los requerimientos. Una prueba exitosa es una que muestra que los requerimientos han sido correctamente implementados.
11 de 37

Prueba y depuracin
Las pruebas de defecto y depuracin son procesos distintos. La verificacin y la validacin estn preocupadas por el establecimiento de la existencia de defectos en un programa. La depuracin est preocupada de la localizacin y reparacin de estos errores. La depuracin implica la formulacin de una hiptesis sobre el comportamiento del programa y la prueba de la hiptesis para encontrar los errores en el sistema.
12 de 37

El proceso de depuracin

13 de 37

Planificacin de V & V
Se requiere que la planificacin cuidadosa se haga en ms procesos de inspeccin y pruebas. La planificacin debera comenzar temprano en el proceso de desarrollo. El plan debera identificar el equilibrio entre verificacin esttica y pruebas. La planificacin de prueba es sobre la definicin de estndares para el proceso de pruebas ms bien que describir pruebas de producto.
14 de 37

El modelo V de desarrollo

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.
16 de 37

Inspecciones de software
stos implican a la gente que examina la representacin fuente con el objetivo de descubrir anomalas y defectos. Las inspecciones no requieren la ejecucin de un sistema por lo que puede ser usado antes de la implementacin. Pueden ser aplicados a cualquier representacin del sistema (requerimientos, diseo, datos de configuracin, datos de prueba, etc.). Han sido mostrados para ser una tcnica eficaz para descubrir errores de programa.
17 de 37

Inspeccin exitosa
Muchos defectos diferentes pueden ser descubiertos en una sola inspeccin. En pruebas, un defecto, puede enmascarar otros en ejecuciones crticas que son requeridas. Los revisores del dominio de reutilizacin y el conocimiento de programacin probablemente habrn visto los tipos de error que comnmente surgen.
18 de 37

Inspecciones y Pruebas
Las inspecciones y las pruebas son complementarias y no son tcnicas de verificacin opuestas. Ambas deberan ser usadas durante el proceso V & V. Las inspecciones pueden comprobar la conformidad con una especificacin, pero no la conformidad con los verdaderos requerimientos del cliente. Las inspecciones no pueden comprobar caractersticas no funcionales como el rendimiento, usabilidad, etc.

19 de 37

Inspecciones de Programa
Acercamiento formalizado para documentar revisiones. Propuesto explcitamente para la deteccin de defectos (no correccin). Los defectos pueden ser errores lgicos, anomalas en el cdigo que podran indicar una condicin errnea (por ejemplo: una variable no inicializada) o incumplimiento con los estndares.
20 de 37

El Proceso de Inspeccin

21 de 37

Procedimiento de Inspeccin
Descripcin del sistema presentada al equipo de inspeccin. El cdigo y los documentos asociados son distribuidos de antemano al equipo de inspeccin. La inspeccin ocurre y los errores descubiertos son anotados. Las modificaciones son hechas para reparar los errores descubiertos. La nueva inspeccin puede o puede que no sea requerida.
22 de 37

Listas de comprobacin de inspeccin

La lista de comprobacin de errores comunes debera ser usada para dirigir la inspeccin. Las listas de comprobacin de error son dependientes del lenguaje de programacin y reflejan los errores caractersticos que probablemente surgen en el lenguaje. En general, ms dbil la comprobacin de tipo, ms grande la lista de comprobacin. Ejemplos: Inicializacin, nombramiento de constantes, terminacin de un ciclo, dimensin de arreglos, etc.
23 de 37

Chequeos de Inspeccin
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? For each co nditional statement, is the condition correct? Is eac h 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? Are all input variables used? Are all output variables assigned a value before they are output? Can unexpected inputs cause corruption?
24 de 37

Control faults

Input/output faults

Valores de Inspeccin
500 declaraciones/hora durante la descripcin. 125 declaraciones fuente/hora durante la preparacin individual. 90-125 declaraciones/hora pueden ser inspeccionadas. La inspeccin es por lo tanto un proceso caro. La inspeccin de 500 lneas cuesta aproximadamente 40 hombres/hora de esfuerzo sobre 2800 en valores del Reino Unido.
25 de 37

Anlisis esttico automatizado

Los analizadores estticos son herramientas software para el procesamiento de texto fuente. Ellos analizan el texto de programa y tratan de descubrir condiciones potencialmente errneas y traer stos a la atencin del equipo V & V. Estos son muy eficaces como una ayuda a las inspecciones - son un suplemento, pero no un reemplazo para las inspecciones.
26 de 37

Chequeo de anlisis esttico

Fault class Data faults Static analysis check Variables us ed before initialisation Variables declared but neve r us ed Variables assigned twice but never used between assignments Possible array bound violations Undecl ared v ariables Unreac hable code Unconditional branches into loops Variables output twice with no intervening assignment Parameter type mis matches Parameter number mismatches Non-usage of the results of functions Uncalled functions and procedures Unassigned pointers Pointer arithmetic
27 de 37

Control faults Input/output faults Interface faults

Storage ma nagement faults

Etapas del anlisis esttico

Anlisis de flujo de control.
Chequeo para ciclos con salida mltiple o puntos de entrada, el cdigo descubrimiento de cdigo ilegible, etc.

Anlisis de uso de datos.

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

Anlisis de interfaz.
Comprueba la consistencia de rutina y declaraciones de procedimiento y su uso.
28 de 37

Etapas del anlisis esttico

Anlisis de flujo de informacin.
Identifica las dependencias de las variables de salida. No descubre anomalas en s mismo, pero destaca la informacin para inspeccin de cdigo o revisin.

Anlisis de Path.
Identifica los path del programa y dispone las declaraciones ejecutadas en aquel path. Otra vez, potencialmente til en el proceso de revisin.

Estas ltimas dos etapas generan cantidades enormes de informacin. Deben ser usados con cuidado.
29 de 37

Anlisis esttico LINT

138% more lint_ex.c 138% more lint_ex.c #include <stdio.h> #include <stdio.h> printarray (Anarray) printarray (Anarray) int Anarray; int Anarray; { printf(%d,Anarray); } { printf(%d,Anarray); } main () main () {{ int Anarray[5]; int i; char c; int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray, i, c); printarray (Anarray) printarray (Anarray) ;; } } 139% cc lint_ex.c 139% cc lint_ex.c 140% lint lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: may be used before set lint_ex.c(10): warning: cc may be used before set lint_ex.c(10): warning: may be used before set lint_ex.c(10): warning: ii may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 11 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. used inconsistently lint_ex.c(4) :: lint_ex.c(11) printarray, arg. 11 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored printf returns value which is always ignored

30 de 37

Desarrollo de software Cleanroom

El nombre es sacado del proceso de Cleanroom en la fabricacin de semiconductores. La filosofa es la evasin de defectos ms bien que el retiro de defectos. Este proceso de desarrollo de software est basado en:
Desarrollo incremental; Especificacin formal; Verificacin esttica usando argumentos de exactitud; Pruebas estadsticas para determinar la fiabilidad del programa.

31 de 37

El proceso Cleanroom

32 de 37

Caractersticas del proceso Cleanroom

Especificacin formal usando un modelo de transicin de estados. Desarrollo incremental donde el cliente prioriza los incrementos. Programacin estructurada el control limitado y los constructores de abstraccin son usados en el programa. Verificacin esttica usando inspecciones rigurosas. Pruebas estadsticas del sistema.

33 de 37

Equipos del proceso Cleanroom

Equipo de especificacin.
Responsable del desarrollo y mantencin de la especificacin del sistema.

Equipo de desarrollo.
Responsable del desarrollo y verificacin del software. El software NO es ejecutado o hasta compilado durante este proceso.

Equipo de certificacin.
Responsable de desarrollar un juego de pruebas estadsticas para probar el software despus del desarrollo. Los modelos de crecimiento de confiabilidad solan determinar cuando la confiabilidad era aceptable.

34 de 37

Evaluacin del proceso Cleanroom

Los resultados de usar el proceso Cleanroom han sido muy impresionantes con pocas faltas descubiertas en sistemas entregados. La evaluacin independiente muestra que el proceso no es ms caro que otros acercamientos. Haba 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.

35 de 37

Resumen
La verificacin y la validacin no son la misma cosa. La verificacin muestra la conformidad con la especificacin; la validacin muestra que el programa satisface las necesidades del cliente. Los planes de prueba deberan ser trazados para guiar el proceso de pruebas. Las tcnicas de verificacin esttica involucran la examinacin y el anlisis del programa para la deteccin de errores.
36 de 37

Resumen
Las inspecciones de programa son muy eficaces en el descubrimiento de errores. El cdigo de programas en inspecciones es sistemticamente comprobado por un pequeo equipo para localizar faltas de software. Las herramientas de anlisis esttico pueden descubrir anomalas en el programa que pueden ser una indicacin de faltas en el cdigo. El proceso de desarrollo Cleanroom depende del desarrollo incremental, verificacin esttica y pruebas estadsticas.
37 de 37

Universidad de Tarapac

Prxima Unidad: Mejora de Procesos

Tecnologas de Desarrollo de Software

Ricardo Spencer