05 Verificacion&Amp Validacion

28-09-15
Verificacin y Validacin
Eduardo Aguilar Torres
Septiembre,2015.
Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I
Eduardo Andrs Aguilar Torres
Agenda
Introduccin
Planificacin de V & V
Inspecciones del software
Anlisis esttico automatizado
Verificacin y metodos formales

Bibliografa
28-09-15
Agenda
Introduccin
Bibliografa
Introduccin
Verificacin
Estamos construyendo el producto correctamente?
Software de acuerdo a su especificacin.
Validacin
Estamos construyendo el producto correcto?
Software debera realizar lo que el cliente necesita.
La V & V deberan conceder confianza en que el software
alcanza su propsito.
28-09-15
Tipo de verificacin y validacin

Esttica
Analizan y comprueban las representaciones estticas del
sistema para describir problemas. (documento de
requerimiento, diagrama de diseo, cdigo fuente del programa)
Dinmicas
Pruebas del software.
Implican ejecutar una implementacin con datos de prueba.
Tipo de verificacin y validacin

La verificacin y validacin debe aplicarse en cada etapa
del proceso de desarrollo de software.
Inspecciones
de software
Especificaciones
de requerimientos
Diseo de
Alto nivel
Especificacin
formal
Prototipo
Diseo
detallado
Programa
Prueba del
software
28-09-15
Prueba del software

Revela la presencia de errores y no su ausencia.
Es la nica tcnica para validacin de requerimientos
no funcionales.
Es recomendable que se utilice en conjunto con la
verificacin esttica.
Tipos de pruebas
Pruebas de validacin
Demostrar que el software cumple con sus
requerimientos.
Pruebas de defectos
Identificar inconsistencias entre el programa y su
especificacin.
28-09-15
Pruebas y depuracin
Las pruebas y la depuracin son distintos procesos.
La verificacin y validacin permiten establecer la
existencia de defectos en un programa.
La depuracin se ocupa de localizar y corregir estos
errores.
La depuracin implica formular una hiptesis sobre el
comportamiento del programa y despus probar esta
hiptesis y encontrar el error del sistema.
Proceso de depuracin
Resultados
de pruebas

Especificacin

Localizar
error

Disear
reparaciones
de errores

Casos
de pruebas

Reparar
errores

Probar de
nuevo el
programa

28-09-15
Agenda
Introduccin
Bibliografa
Planificacin de la verificacin y
validacin
La V & V es un proceso caro.
Se requiere una cuidadosa planificacin para obtener lo
mejor de los procesos de inspeccin y pruebas.
La planificacin debera comenzar al inicio del proceso
de desarrollo.
El plan debera identificar el equilibrio entre la
verificacin esttica y las pruebas.
La planificacin trata de definir estndares para el
proceso de prueba en lugar de describir pruebas de
productos.
28-09-15
Modelo V de desarrollo
Especificacin de
requerimientos

Plan de pruebas
de integracin del
sistema
Diseo
detallado
Plan de pruebas
de aceptacin
Servicio
Diseo del
sistema
Especificacin
del sistema
Cdigo y
prueba de los
mdulos y
unidades
Plan de pruebas
de integracin de
los subsistemas
Prueba de
aceptacin
Prueba de
integracin del
sistema
Prueba de
integracin de los
subsistemas
Estructura de un plan de pruebas

Proceso de pruebas
Descripcin de las principales fases.
Trazabilidad de requerimientos
Evaluar independientemente los requerimientos.
Elementos probados
Especificar los elementos que tienen que ser probados.
Calendario de pruebas
Calendarizar pruebas y asignar recursos.
Procedimientos de registro de las pruebas

Registrar los resultados, para luego poder auditar el proceso.
Requerimientos hardware y software

Restricciones
28-09-15
Agenda
Introduccin
Bibliografa
Inspecciones de software
Implican que las personas examinen la representacin
de la fuente con el propsito de descubrir anomalas y
defectos.
No requieren la ejecucin de un sistema por lo que
debe utilizarse antes de la implementacin.
Pueden ser aplicadas a cualquier representacin del
sistema (requerimientos, diseo, configuracin, datos,
pruebas de datos, etc).
Es una tcnica efectiva para descubrir errores del
programa.
28-09-15
xito de la inspeccin
Pueden descubrirse muchos diferentes defectos en una
sola inspeccin. A diferencia de las pruebas, en las cuales
un defecto puede enmascarar a otro as que se requieren
varias ejecuciones.
Resaltan la reutilizacin y el conocimiento de
programacin, de manera tal que es ms simple identificar
errores que son cometidos comnmente.
Inspecciones y pruebas
Las inspecciones y pruebas son complementarias y no
tcnicas opuestas.
Ambas deben utilizarse durante el proceso V & V.
Las inspecciones pueden comprobar el ajuste con una
especificacin pero no la conformidad con los
requerimientos reales del cliente.
Las inspecciones no pueden comprobar caractersticas
no funcionales como rendimiento, usabilidad, etc.
28-09-15
Inspecciones de programas
Aproximacin formalizada a las revisiones del
documento.
Est pensado explcitamente para la deteccin de
defectos (no su correccin)
Los defectos pueden ser errores lgicos, anomalas en
el cdigo que pueden indicar una condicin errnea o
no conformidad con los estndares.
Precondiciones de la inspeccin
Debe haber una especificacin precisa disponible.
Los miembros del equipo deben estar familiarizados
con los estndares de organizacin.
Debe estar disponible un cdigo sintcticamente
correcto u otras representaciones del sistema.
Debera prepararse una lista de errores.
La gestin debe aceptar que la inspeccin aumentar
los costes pronto en el proceso de software.
La gestin no debera utilizar inspecciones para la
evaluacin del personal, es decir, para encontrar quin
comete errores.
10
28-09-15
El proceso de inspeccin
Planificacin
Seguimiento
Panorama
general
Repeticin
del trabajo
Preparacin
individual
Reunin de
inspeccin
Proceso de inspeccin
Panorama general del sistema presentado al equipo de
inspeccin.
Los cdigos y documentos asociados se distribuyen al
equipo de inspeccin por adelantado.
La inspeccin tiene lugar y se anotan los errores
encontrados.
Se hacen modificaciones para reparar los errores
descubiertos.
Puede requerirse o no una re-inspeccin.
11
28-09-15
Roles en el proceso de inspeccin

Rol
Responsabilidad
Autor o propietario
El programador o diseador responsable de generar el programa o

documento. Responsable de reparar los defectos descubiertos durante el
proceso de inspeccin.
Inspector
Encuentra errores, omisiones e inconsistencias en los programas y

documentos. Tambin puede identificar cuestiones ms generales que
estn fuera del mbito del equipo de inspeccin.
Lector
Presenta el cdigo o documento en una reunin de inspeccin
Secretario
Registra los resultados de la reunin de inspeccin
Presidente o
moderador
Gestiona el proceso y facilita la inspeccin. Realiza un informe de los

resultados del proceso para el moderador jefe.
Moderador jefe
Responsable de las mejoras del proceso de inspeccin, actualizacin de

las listas de comprobacin, estndares de desarrollo, etc.
Listas de inspeccin
Debera utilizarse una lista de errores comunes para
guiar la inspeccin.
Las listas de errores dependen del lenguaje de
programacin y reflejan los errores caractersticos que
es probable que aparezcan en el lenguaje.
En general cuanto ms dbil sea la comprobacin
del tipo, ms grande ser la lista.
Ejemplos: inicializacin, nombramiento de constantes,
terminacin de bucles, lmites de vectores, etc.
12
28-09-15
Comprobaciones de inspeccin
Clase de falta
Chequeo de inspeccin
Defectos de datos
Se inicializan todas las variables antes de que se utilicen sus

valores? Tienen nombre las constantes?
El lmite superior de los vectores es igual al tamao del vector o al
tamao 21?
Si se utilizan cadenas de caracteres, tienen un delimitador
explcitamente asignado?
Existe alguna posibilidad de que el bfer se desborde?
Defectos de control
Para cada sentencia condicional, es correcta la condicin?

Se garantiza que termina cada bucle?
Estn puestas correctamente entre llaves las sentencias
compuestas?
En las sentencias case, se tienen en cuenta todos los posibles
casos?
Si se requiere una sentencia break despus de cada caso en las
sentencias case Se ha incluido?
Defectos de entrada/salida
Se utilizan todas las variables de entrada?

Se les asigna un valor a todas las variables de salida?
Pueden provocar corrupciones de datos las entradas no esperadas?
Comprobaciones de inspeccin
Clase de falta
Chequeo de inspeccin
Defectos de interfaz
Las llamadas a funciones y a mtodos tienen el nmero

correcto de parmetros?
Concuerdan los tipos de parmetros reales y formales?
Estn en el orden correcto los parmetros?
Si los componentes acceden a memoria compartida,
tienen el mismo modelo de estructura de la memoria
compartida?
Defectos de gestin de almacenamiento
Si una estructura enlazada se modifica, se reasignan

correctamente todos los enlaces?
Si se utiliza almacenamiento dinmico se asigna
correctamente el espacio de memoria?
Se desasigna explcitamente el espacio de memoria
cuando ya no se necesita?
Defectos de manejo de excepciones
Se tienen en cuenta todas las condiciones posibles de

error?
13
28-09-15
Cifras de inspeccin
500 sentencias/hora durante el panorama general.
125 sentencias de cdigo fuente/hora durante la
preparacin individual.
Pueden inspeccionarse de 90 a 125 sentencias/hora.
Inspeccionar 500 lneas cuesta el esfuerzo de unas 40
horas/hombre (unas 20 UF).
Por lo tanto la inspeccin es un proceso caro.
Agenda
Introduccin

Bibliografa
14
28-09-15

Los analizadores estticos son herramientas de
software para procesar el cdigo fuente.
Estos analizan sintcticamente el texto del programa y
tratan de descubrir condiciones potencialmente
errneas y llamar la atencin del equipo de V & V.
Son una ayuda muy efectiva en las inspecciones.
Comprobaciones del anlisis

esttico.
Clase de defecto
Comprobacin del anlisis sintctico
Defectos de datos
Variables utilizadas antes de su inicializacin.

Variables declaradas pero nunca utilizadas
Variables asignadas dos veces pero nunca utilizadas entre
asignaciones.
Posibles violaciones de los lmites de los vectores.
Variables no declaradas
Defectos de control
Cdigo no alcanzable.
Saltos incondicionales en bucles.
Defectos de entrada y salida
Las variables salen dos veces sin intervenir ninguna asignacin.
Defectos de interfaz
Inconsistencias en el tipo de parmetros.

Inconsistencias en el nmero de parmetros.
Los resultados de las funciones no se utilizan.
Existen funciones y procedimientos a los que no se les llama
Defectos de gestin de
almacenamiento
Punteros sin asignar.

Aritmtica de punteros.
15
28-09-15
Etapas del anlisis esttico

Anlisis del flujo de control.
Comprueba los bucles con mltiples puntos de entrada o salida,
encuentra cdigos inalcanzables.
Anlisis de uso de los datos.

Detecta variables no inicializadas, variables escritas dos veces
sin que intervenga una asignacin, variables que se declaran
pero nunca se usan, etc.
Anlisis de interfaz.
Comprueba la consistencia de una rutina, las declaraciones del
procedimiento y su uso.
Etapas del anlisis esttico

Anlisis de flujo de informacin.
Identifica las dependencias de las variables de salida. No
detecta anomalas en s pero resalta informacin para la
inspeccin o revisin del cdigo.
Anlisis de caminos.
Identifica los caminos del programa y arregla las sentencias
ejecutadas en el camino. Nuevamente, es potencialmente til
en el proceso de revisin.
Ambas etapas generan grandes cantidades de

informacin. Deben utilizarse con cuidado.
16
28-09-15
Anlisis esttico LINT

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

Es particularmente valioso cuando se utiliza un lenguaje
como C que es dbilmente tipificado y por lo tanto
muchos errores no detectados por el compilador.
Es menos rentable para lenguajes como Java que es
fuertemente tipificado y por lo tanto pueden detectar
muchos errores durante la compilacin.
17
28-09-15
Agenda
Introduccin
Bibliografa
Desarrollo de software de sala

limpia
El nombre se deriva del Sala limpia en la fabricacin

de unidades de semiconductores. La filosofa es evitar
los defectos en lugar de eliminarlos.
Reemplaza las pruebas de unidades por inspeccin del
software.
Este proceso de desarrollo de software se basa en:
Desarrollo incremental
Especificacin formal
Verificacin esttica utilizando argumentos de correccin
Pruebas estticas para determinar la fiabilidad del
programa.
18
28-09-15
El proceso de sala limpia
Especificar
formalmente
el sistema
Revisin de errores
Definir los
incrementos
de software
Desarrollar
el perfil
operacional
Construir el
programa
estructurado
Verificar
formalment
e el cdigo
Disear las
pruebas
estticas
Integrar el
incremento
Probar el
sistema
integrado
Caractersticas del proceso de Sala

limpia
Especificacin formal que utiliza un modelo de
transicin de estados.
Desarrollo incremental en el que el cliente prioriza sus
incrementos.
Programacin estructurada: se utiliza un nmero
limitado de estructuras de control y de abstracciones de
datos.
Verificacin esttica que utiliza inspecciones rigurosas.
Pruebas estadsticas del sistema.
19
28-09-15
Especificacin e inspecciones
formales
El modelo basado en el estado es un sistema de
especificacin y el proceso de inspeccin comprueba el
programa contra este modelo.
La aproximacin a la programacin se define de forma
que la correspondencia entre el modelo y el sistema
sea clara.
Los argumentos matemticos (no pruebas) se utilizan
para incrementar la confianza en el proceso de
inspeccin.
Equipos de proceso de Sala Limpia

Equipo de especificacin.
Responsable del desarrollo y mantenimiento de la
especificacin del sistema.
Equipo de desarrollo.
Responsable de desarrollar y verificar el software. El software
NO se ejecuta ni se compila durante este proceso
Equipo de certificacin.
Es responsable de desarrollar un conjunto de pruebas
estadsticas para ejercitar el software despus de su desarrollo.
Los modelos de crecimiento de fiabilidad se utilizan para
determinar cundo es aceptable la fiabilidad.
20
28-09-15
Evaluacin del proceso de Sala

Limpia
El resultado de usar procesos de Sala Limpia ha sido
realmente impresionante con los pocos fallos
descubiertos en sistemas desarrollados. (IBM)
La valoracin independiente muestra que el proceso no
es ms costoso que otras aproximaciones.
Menores errores que en el proceso de desarrollo
tradicional.
Sin embargo, el proceso generalmente no se utiliza. No
est claro como puede ser transferida esta
aproximacin a un entorno con ingenieros de software
menos motivados o menos capacitados.
Agenda
Introduccin

Bibliografa
21
28-09-15
Bibliografa
Ingeniera de Software, Ian Sommerville, Pearson
Educacin, 2005. (Cap 22)
22

05 Verificacion&Amp Validacion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

05 Verificacion&Amp Validacion

Cargado por

Copyright:

Formatos disponibles

28-09-15

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Verificacin y metodos formales

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Eduardo Andrs Aguilar Torres

Tipo de verificacin y validacin

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Tipo de verificacin y validacin

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Prueba del software

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Estructura de un plan de pruebas

Procedimientos de registro de las pruebas

Requerimientos hardware y software

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Roles en el proceso de inspeccin

El programador o diseador responsable de generar el programa o

Encuentra errores, omisiones e inconsistencias en los programas y

Presenta el cdigo o documento en una reunin de inspeccin

Registra los resultados de la reunin de inspeccin

Gestiona el proceso y facilita la inspeccin. Realiza un informe de los

Responsable de las mejoras del proceso de inspeccin, actualizacin de

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Departamento de Ingeniera de Sistemas y Computacin Ingeniera de Software I

Eduardo Andrs Aguilar Torres

Se inicializan todas las variables antes de que se utilicen sus

Para cada sentencia condicional, es correcta la condicin?