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.
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.

3 de 37

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

V & V debe aplicarse en cada fase del proceso de software. La evaluación de si el sistema es útil o no en una determinada situación operacional. Tiene dos objetivos principales: El descubrimiento de defectos en el sistema. 5 de 37 .El proceso V & V Es un proceso del ciclo de vida .

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

7 de 37 .Seguridad V & V Depende de el objetivo del sistema. Función de software El nivel de confianza depende de cuan crítico es el software en la organización. expectativas del usuario y ambiente de marketing. Ambiente de marketing Conseguir un producto en el mercado tempranamente puede ser más importante que el descubrimiento de defectos en el programa. Expectativas del usuario Los usuarios pueden tener expectativas bajas de ciertas clases de software.

Se refiere al ejercicio y observación del comportamiento del producto (verificación dinámica). • Puede ser suplementado por el documento basado en herramienta análisis de código Pruebas de Software.Verificación dinámica y estática Inspecciones de Software. • El sistema es ejecutado con datos de prueba y su comportamiento operacional es observado. Se refiere al análisis de la representación estática del sistema para descubrir problemas (verificación estática). 8 de 37 .

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

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.Pruebas de programa Puede revelar la presencia de errores. 10 de 37 . NO su ausencia. Una prueba exitosa consiste en descubrir uno o mas errores.

Pruebas diseñadas para descubrir defectos en el sistema. Pruebas de Validación. Una prueba exitosa es una que muestra que los requerimientos han sido correctamente implementados. Propuesto para mostrar que el software cumple con los requerimientos.Tipos de prueba Pruebas de Defecto. Un prueba de defectos exitosa es aquella que revela la presencia de defectos en el sistema. 11 de 37 .

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.Prueba y depuración Las pruebas de defecto y depuración son procesos distintos. 12 de 37 .

El proceso de depuración 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. 14 de 37 . 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. La planificación debería comenzar temprano en el proceso de desarrollo.

El modelo V de desarrollo 15 de 37 .

Procedimientos de registro de pruebas.La estructura de un plan de prueba de software El proceso de pruebas. La trazabilidad de los requerimientos. Requerimientos de hardware y software. Restricciones. Calendario de pruebas. Componentes probados. 16 de 37 .

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

un defecto. 18 de 37 . 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.Inspección exitosa Muchos defectos diferentes pueden ser descubiertos en una sola inspección. puede enmascarar otros en ejecuciones críticas que son requeridas. En pruebas.

etc. 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. Ambas deberían ser usadas durante el proceso V & V. 19 de 37 .Inspecciones y Pruebas Las inspecciones y las pruebas son complementarias y no son técnicas de verificación opuestas.

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. 20 de 37 . Propuesto explícitamente para la detección de defectos (no corrección). Los defectos pueden ser errores lógicos.Inspecciones de Programa Acercamiento formalizado para documentar revisiones.

El Proceso de Inspección 21 de 37 .

Las modificaciones son hechas para reparar los errores descubiertos.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 nueva inspección puede o puede que no sea requerida. La inspección ocurre y los errores descubiertos son anotados. 22 de 37 .

etc.Listas de comprobación de inspección La lista de comprobación de errores comunes debería ser usada para dirigir la inspección. más grande la lista de comprobación. “más débil” la comprobación de tipo. Ejemplos: Inicialización. nombramiento de constantes. 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. terminación de un ciclo. dimensión de arreglos. En general. 23 de 37 .

is a de limiter explicitly assigned? Is there any possibility of buffer overflow? For each co nditional statement. are all possible cases accounted for? If a break is required after each case in case statements. is the condition correct? Is eac h loop certain to terminate? Are compound statements correctly bracketed? 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 .Chequeos de Inspección 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.

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

pero no un reemplazo para las inspecciones. 26 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.son un suplemento. Estos son muy eficaces como una ayuda a las inspecciones .

Chequeo de análisis estático 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 .

28 de 37 . pero nunca usadas. etc. Chequeo para ciclos con salida múltiple o puntos de entrada. Detecta variables no inicializadas. Análisis de uso de datos. Análisis de interfaz. variables que son declaradas. el código descubrimiento de código ilegible. variables escritas dos veces sin una asignación intermedia. etc. Comprueba la consistencia de rutina y declaraciones de procedimiento y su uso.Etapas del análisis estático Análisis de flujo de control.

Identifica los path del programa y dispone las declaraciones ejecutadas en aquel path. Estas últimas dos etapas generan cantidades enormes de información. pero destaca la información para inspección de código o revisión. Análisis de Path. Deben ser usados con cuidado. Otra vez.Etapas del análisis estático Análisis de flujo de información. potencialmente útil en el proceso de revisión. 29 de 37 . Identifica las dependencias de las variables de salida. No descubre anomalías en sí mismo.

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

Pruebas estadísticas para determinar la fiabilidad del programa. Verificación estática usando argumentos de exactitud.Desarrollo de software Cleanroom El nombre es sacado del proceso de “Cleanroom” en la fabricación de semiconductores. 31 de 37 . Especificación formal. Este proceso de desarrollo de software está basado en: Desarrollo incremental. La filosofía es la evasión de defectos más bien que el retiro de defectos.

El proceso Cleanroom 32 de 37 .

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

Los modelos de crecimiento de confiabilidad solían determinar cuando la confiabilidad era aceptable. Responsable del desarrollo y mantención de la especificación del sistema. Responsable de desarrollar un juego de pruebas estadísticas para probar el software después del desarrollo. Equipo de desarrollo. El software NO es ejecutado o hasta compilado durante este proceso. Equipo de certificación. Responsable del desarrollo y verificación del software.Equipos del proceso Cleanroom Equipo de especificación. 34 de 37 .

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.Evaluación del proceso Cleanroom Los resultados de usar el proceso Cleanroom han sido muy impresionantes con pocas faltas descubiertas en sistemas entregados. Había menos errores que en un proceso de desarrollo “tradicional”. La evaluación independiente muestra que el proceso no es más caro que otros acercamientos. 35 de 37 .

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

verificación estática y pruebas estadísticas.Resumen Las inspecciones de programa son muy eficaces en el descubrimiento de errores. El proceso de desarrollo Cleanroom depende del desarrollo incremental. 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 código de programas en inspecciones es sistemáticamente comprobado por un pequeño equipo para localizar faltas de software. 37 de 37 .

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

Sign up to vote on this title
UsefulNot useful