Verificacin y validacin

Verificacin y validacin
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.
El proceso V & V
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.
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
Funcin del software
El nivel de confianza depende de lo
crtico que es el sistema para una
organizacin.
Expectativas del usuario
Los usuarios pueden tener bajas
expectativas para ciertas clases de
software.
Verificacin dinmica y esttica
Inspecciones de software. Se ocupa del
anlisis de representaciones estticas del
sistema para describir 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 comportamiento operativo.

V & V esttica y dinmica
Especificacin
formal
Diseo de
Alto nivel
Especificaciones
de
requerimientos
Diseo
detallado
Programa
Prototipo
Prueba de
programas
Inspecciones
de software
Prueba del programa
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.

Tipos de pruebas
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.

Pruebas y depuracin
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.
El proceso de depuracin
Localizar
error
Disear
reparaciones
de errores
Reparar
errores
Probar de
nuevo el
programa
Resultados
De pruebas
Especificacin
Casos
De pruebas
Planificacin de V &V
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.
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.
* Es un conjunto de acciones, medidas y procedimientos tcnicos que
permite identificar y registrar cada producto desde su nacimiento
hasta el final
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 tanto 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.
Desarrollo de software de sala
limpia
El nombre se deriva de 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.
El proceso de Sala limpia
Construir el
programa
estructurado
Definir los
incrementos
de software
Verificar
formalmente
el cdigo
Integrar el
incremento
Especificar
formalmente
el sistema
Desarrollar
el perfil
operacional
Disear las
pruebas
estticas
Probar el
sistema
integrado
Revisin de errores
Modelo de Proceso de Sala
Limpia
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.
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.
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.
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 con
Caja Negra
Las pruebas de caja negra son aquellas que se
enfocan directamente en el exterior del mdulo, sin
importar el cdigo, son pruebas funcionales en las
que se trata de encontrar fallas.
Evaluacin del proceso con
Caja de Estado
La caja de estado encapsula los datos de estado y
servicios (operaciones).
Evaluacin del proceso con
Caja Transparente
Una caja transparente contiene el diseo de
procedimiento para la caja de estado.
Ejemplo Caja Transparente
Ejemplo Caja Transparente
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 examen 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.