Вы находитесь на странице: 1из 46

Verificacin y validacin en

Software

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

Verificacin dinmica y esttica


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.

V & V esttica y dinmica


Inspecciones
de software

Especificacion
es de
requerimientos

Prototipo

Diseo de
Alto nivel

Especificacin
formal

Diseo
detallado

Programa

Prueba de
programas

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

Resultados
De pruebas

Localizar
error

Casos
De pruebas

Especificacin

Disear
reparacione
s de errores

Reparar
errores

Probar de
nuevo el
programa

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
De requerimientos

Especificacin
Del sistema

Plan de pruebas
De aceptacin

Servicio

Diseo del sistema

Plan de
pruebas de
integracin del
sistema

Prueba de
aceptacin

Diseo
detallado

Plan de pruebas
de integracin
De los
subsistemas

Prueba de
integracin del
sistema

Cdigo y
prueba de los
mdulos y
unidades

Prueba de integracin
De los subsistemas

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

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

Planificacin
Visin de
conjunto

Seguimiento
Preparacin
individual

Reunin de
inspeccin

Repeticin
de trabajo

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

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

Comprobaciones de inspeccin
2

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

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

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.

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

Especificar
formalment
e el
sistema

Revisin de errores

Definir los
incremento
s de
software
Desarrollar
el perfil
operacion
al

Construir
el
programa
estructura
do
Disear
las
pruebas
estticas

Verificar
formalmen
te el
cdigo

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

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.

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.

Вам также может понравиться