Verificacin y validacin

Objetivos
Introducir la verificacin y validacin del
software y discutir la diferencia entre ellos (V &
V)
Describir el proceso de inspeccin del programa
y su papel en la V & V
Explicar el anlisis esttico como una tcnica de
verificacin
Describir el proceso de desarrollo de software
de Sala Limpia

Contenidos
Planificacin de verificacin y validacin
inspecciones de software
Anlisis esttico automatizado
Verificacin y mtodos formales
Verificacin:
Estamos construyendo el producto
corrctamente?.
El software debera ajustarse a su
especificacin
Validacin:
estamos construyendo el producto
correcto?.
El software debera hacer lo que el cliente
realmente reclama.
Verificacin y validacin
Es el proceso de todo un ciclo vital: La V &
V debe aplicarse en cada etapa del
software.
Tiene dos objetivos principales
El descubrimiento de defectos en el sistema;
La evaluacn de si el sistema es til y
utilizable en una situacin operacional o no.
El proceso V & V
Metas de la V&V
La verificacin y la validacin deberan
establecer la confianza de que el software
es adecuado al propsito.
Esto NO significa que est completamente
libre de defectos.
Sino que debe ser lo suficientemente
bueno para su uso previsto y el tipo de
uso determinar el grado de confianza
que se necesita.
Confianza de la V&V
Depende del propsito del sistema, las
expectativas del usuario y el entorno de
marketing
Funcin del software
El nivel de confianza depende de lo crtuco que es el sistema
para una organizacin.
Expectativas del usuario
Los usuarios pueden tener bajas expectativas para ciertas
clases de software.
Entorno de marketing
Introducir un producto en el mercado pronto puede ser ms
importante que encontrar defectos en el programa
Inspecciones de software. Se ocupa del
anlisis de representaciones estticas del
sistema para describrir problemas
(verificacin esttica)
Pueden ser complementadas por documentos
basados en herramientas y anlisis del cdigo
Pruebas del software. Se ocupa de la
ejercitacin y la observacin del
comportamiento del producto (verificacin
dinmica)
El sistema se ejecuta con datos de pruebas y se
observa su compotamiento operativo.

Verificacin dinmica y esttica
V & V esttica y dinmica
Especificacin
formal
Diseo de
Alto nivel
Especificaciones
de
requerimientos
Diseo
detallado
Programa
Prototipo
Prueba de
programas
Inspecciones
de software
Puede revelar la presencia de errores NO
su ausencia.
Es la nica tcnica de validacin para
requerimientos no funcionales ya que el
software tiene que ser ejecutado para ver
su comportamiento.
Debera utilizarse en conjuncin con la
verificacin esttica para proporcionar una
covertura de V & V total.

Prueba del programa
Pruebas de defectos
Pruebas diseadas para descubrir defectos en el
sistema.
Una prueba de defectos exitosa es aquella que revela
la presencia de defectos en un sistema.
Pruebas de validacin
Previsto para mostrar que el software cumple sus
requerimientos.
Una prueba con xito es aquella que muestra que un
requerimiento se ha implementado correctamente.

Tipos de pruebas
Las pruebas de defectos y depuracin son
distintos procesos.
La verificacin y validacin se ocupan de
establecer la existencia de defectos en un
programa.
La depuracin se ocupa de ubicar y reparar
estos errores.
La depuracin implica formular una hiptesis
sobre el comportamiento del programa y
despus probar esta hiptesis y encontrar el
error del sistema.
Pruebas y depuracin
El proceso de depuracin
Localizar
error
Disear
reparaciones
de errores
Reparar
errores
Probar de
nuevo el
programa
Resultados
De pruebas
Especificacin
Casos
De pruebas
Se requiere una cuidadosa planificacin
para sacar el mximo de los procesos de
inspeccin y pruebas. La planificacin
debera comenzar pronto en el proceso de
desarrollo.
El plan debera identificar el balance 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.
Planificacin de V &V
El modelo-V de desarrollo
Especificacin
Del sistema
Diseo del sistema
Diseo
detallado
Cdigo y
prueba de los
mdulos y
unidades
Plan de pruebas de
integracin
De los subsistemas
Plan de pruebas
de integracin del
sistema
Plan de pruebas
De aceptacin
Servicio
Prueba de
aceptacin
Prueba de
integracin del
sistema
Prueba de integracin
De los subsistemas
Especificacin
De requerimientos
Estructura de un plan de pruebas
de software
Proceso de pruebas
Trazabilidad de requerimientos.
Elementos probados.
Calendario de pruebas.
Procedimientos de registro de las
pruebas.
Requerimientos hardware y software.
Restricciones.
Plan de pruebas de software

El proceso de prueba
Una descripcin de las principales fases del proceso de prueba. stas
podran describirse como se hizo anteriormente en este captulo.

Trazabilidad de requerimientos
Los usuarios son los ms interesados en que el sistema satisfaga sus
requerimientos y las pruebas deberan planificarse para que todos los
requerimientos se prueben individualmente.

Elementos probados
Deberan especificarse los elementos del proceso de software que
tienen que ser probados.

Calendario de pruebas
Un calendario de todas las pruebas y la asignacin de recursos para
este calendario se enlaza obviamente, con la agenda general del
desarrollo del proyecto.

Procedimiento de registro de las pruebas
No es suficiente ejecutar simplemente las pruebas; los resultados de la
pruebas deben ser registrados sistemticamente. Debe ser posible
auditar el proceso de pruebas para comprobar que se ha llevado a cabo
correctamente

Requerimientos de software y hardware
En esta seccin deberan anticiparse las restricciones que afectan al
proceso de pruebas como la escasez de personal.

Restricciones
En esta seccin deberan anticiparse las restricciones que afectan al
proceso de pruebas como la escasez de personal.
Inspecciones de software
Implican que las personas examinen la
representacin de la fuente con el propsito de
descubrir anomalas y defectos
Las inspecciones no requieren la ejecucin de
un sistema por lo que debe utilizarse antes de la
implementacin.
Pueden estar aplicados a cualquier
representacin del sistema (requerimientos,
diseo, configuracin, datos, pruebas de datos,
etc).
Se ha demostrado que es una tcnica efectiva
para descubrir errores del programa.
xito de la inspeccin
Pueden descubrirse muchos diferentes
defectos en una sola inspeccin. Al
probar, un defecto puede enmascarar a
otro as que se requieren varias
ejecuciones.


Inspecciones y pruebas
Las inspecciones y pruebas son
complementarias y no tcnicas opuestas de
verificacin.
Ambas deben utilizarse durante el proceso V &
V.
Las inspecciones pueden comprobar el ajuste
con una especificacin pero no la conformancia
con los requerimientos reales del cliente.
Las inspecciones no pueden comprobar
caractersticas no funcionales como
rendimiento, usabilidad, etc.
Inspecciones de programas
Es la 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 (p.ej: una
variable no iniciada) 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.
El proceso de inspeccin
Reunin de
inspeccin
Preparacin
individual
Visin de
conjunto
Planificacin
Repeticin de
trabajo
Seguimiento
Proceso de inspeccin
Visin de conjunto 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 reinspeccin.
Roles en el proceso de
inspeccin
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.
Comprobaciones de inspeccin
1
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
2
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
expcepciones
Se tienen en cuenta todas las condiciones posibles de
error?
Cifras de inspeccin
500 sentencias/hora durante la visin de
conjunto.
125 sentencias de cdigo fuente/hora durante la
preparacin individual.
Pueden inspeccionarse de 90 a 125
sentencias/hora.
Por lo anto la inspeccin es un proceso caro.
Inspeccionar 500 lneas cuesta el esfuerzo de
unas 40 horas/hombre (unos 4146 en cifras
espaolas).
Anlisis esttico automatizado
Los analizadores estticos son
herramientas de software para procesar
textos 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 ( son un complemento, no
una sustitucin de 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/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.
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 ltil en el proceso de revisin.
Ambas etapas generan grandes cantidades
de informacin. Deben utilizarse con cuidado.
Anlisis esttico LINT
138% more lint_ex.c
#i nclude <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% l int lint_ex.c
l int_ex.c(10): warning: c may be used before set
l int_ex.c(10): warning: i may be used before set
printarray: variabl e # of args. lint_ex.c(4) :: li nt_ex.c(10)
printarray, arg. 1 used inconsi stentl y l int_ex.c(4) :: l int_ex.c(10)
printarray, arg. 1 used inconsi stentl y l int_ex.c(4) :: l int_ex.c(11)
printf returns value which i s always ignored
Uso del anlisis esttico
Es particularmente valioso cuando se
utiliza un lenguaje como C que tiene un
tipado dbil y por tanto muchos errores no
detectados por el compilador
Es menos rentable para lenguajes como
Java que tienen una fuerte comprobacin
de tipado y por lo tanto pueden detectar
muchos errores durante la compilacin.
Verificacin y mtodos formales
Los mtodos formales pueden utilizarse
cuando se produce una especificacin
formal del sistema
Son la tcnica de verificacin esttica
primordial.
Implican anlisis matemtico detallado de
la especificacin y pueden desarrollar
argumentos formales para que un
programa se ajuste a su especificacin
formal
Argumentos a favor de los
mtodos formales
Producir una especificacin matemtica
requiere un anlisis detallado de los
requerimientos y es probable que
descubra errores.
Pueden detectar errores de
implementacin antes de comprobar
cuando se analiza el programa a lo largo
de la especificacin.
Argumentos en contra de los
mtodos formales
Requieren notaciones especializadas que
no pueden comprenderse por los expertos
del dominio.
Es muy caro desarrollar una
especificacin y an ms caro demostrar
que un programa cumple esa
especificacin.
Puede ser posible alcanzar el mismo nivel
de confianza en un programa ms barato
utilizando otras tcnicas de V & V.
El nombre se deriva del Sala limpia en la
fabricacin de unidades de semiconductores. La
filosofa es evitar los defectos en lugar de
eliminarlos.
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.
Desarrollo de software de sala
limpia
El proceso de Sala limpia
Construir el
programa
estructurad
o
Definir los
incrementos
de software
Verificar
formalment
e el cdigo
Integrar el
incremento
Especificar
formalmente
el sistema
Desarrollar
el perfil
operacional
Disear las
pruebas
estticas
Probar el
sistema
integrado
Revisin de errores
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.
Las pruebas estadsticas del sistema (tratado en
el captulo 24)
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.
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.
Equipos de proceso de Sala
Limpia
El resultado de usar procesos de Sala Limpia ha
sido realmente impresionante con los pocos
fallos descubiertos en sistemas desarrollados.
La valoracin independiente muestra que el
proceso no es ms caro que otras
aproximaciones.
Hubo muy muchos menos 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
expertos.
Evaluacin del proceso de Sala
Limpia
Puntos clave
La verificacin y la validacin no son lo
mismo. La verificacin muestra el ajuste
con la especificacin; La validacin
muestra que el programa cumple las
necesidades del cliente.
Los planes de prueba deberan ser
preparados para guiar el proceso de
prueba.
Las tcnicas de verificacin esttica
implican el anlisis y exmen del
programa para la deteccin de errores.
Puntos clave
Las inspecciones del programa son muy
efectivas para descubrir errores.
El cdigo del programa en las inspecciones es
comprobado sistemticamente por un pequeo
equipo para ubicar los fallos de software.
Las herramientas de anlisis esttico pueden
descubrir anomalas en el programa que pueden
ser una indicacin de defectos en el cdigo.
El proceso de desarrollo de Sala Limpia
depende del desarrollo incremental, la
verificacin esttica y las pruebas estadsticas.