Evaluacin de Software

Evaluacin y Auditoria de sistemas de

informacin - MSc. Patricia Romero .
1
Introduccin
Un sistema de software es construido para
satisfacer los requerimientos de un cliente.
Cmo saber si el producto va ha
funcionar correctamente?
Debe haber un proceso de evaluacin o
comprobacin paralelo al del desarrollo.

2
Introduccin
El fin es el de entregar productos de calidad.
La calidad puede descomponerse en 6
atributos:
Funcionalidad.
Fiabilidad.
Eficiencia.
Usabilidad.
Mantenibilidad.
Portabilidad.

3
Tipos de evaluaciones
Verificacin, proceso para determinar si
un producto cumple con los requisitos
pre-establecidos.
Validacin, proceso al final del proceso de
desarrollo para asegurar el cumplimiento
de las necesidades del cliente.

4
Tcnicas de evaluacin
Estticas, estudian los distintos modelos
que componen el sistema de software
buscando posibles fallas en los mismos.
Acompaa a las distintas etapas de
desarrollo del software. (top-down)
Dinmicas (o testing), se pone el sistema a
funcionar buscando defectos entre la
salida esperada y la real. (bottom-up)

5
La evaluacin esttica
Los defectos que se buscan al evaluar son:
Requisitos:
Correccin, correctamente lo que debe hacer.
Completitud, todo lo que tiene que hacer.
Ambigedad, los req. No pueden estar sujetos a
interpretacion.
Claridad, se entiende claramente lo que se esta
especificando.

6
La evaluacin esttica
Diseo:
Correccin, el diseo no debe contener errores.
Complecin, nada falta, nada sobra.
Factibilidad, El diseo debe ser realizable.
Tranzabilidad, desde un requisito hasta el fragmento de diseo
donde ste se encuentre representado.
Cdigo fuente
Correccin, no debe contener errores.
Complecin
Consistencia.
Tranzabilidad.

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
7
La evaluacin esttica
Revisiones.
Informales, intercambio de opiniones entre
participantes.
Formales.
Se genera un informe que refleja el acto de revisin.
Walkthrough (Recorrido), simular la ejecucin
de casos de prueba.
Auditorias, se trata de comprobaciones de
gestin y administracin del proyecto.

8
La evaluacin esttica
Inspecciones
Verificar y validar un producto software
manualmente. Proceso bien definido y
disciplinado donde un equipo de personas
analizan un producto.
El proceso de Inspeccin
1. Inicio, planificacin y lanzamiento.
2. Deteccin de defectos
3. Coleccin, compilacin e inspeccin en grupo.
4. Correccin y seguimiento.

9
La evaluacin esttica
Heursticas:
Encontrar muchas faltas es sospechoso.
Encontrar muy pocas faltas tambin es
sospechoso.
La estimacin mas fiable es la coincidencia de
faltas encontradas entre distintos inspectores.
(Mtodos de estimaciones Captura-
Recaptura)

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
10
La evaluacin esttica
Tcnicas de lectura, son guas que ayuda a
detectar defectos en los productos.
Consiste en una serie de pasos o
procedimientos para adquirir conocimiento
del producto de software que se
inspecciona.

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
11
Tcnicas de lectura
Lectura Ad-hoc.
Lectura basada en listas de comprobacin.
Lectura por abstraccin, revisin activa de
diseo y lectura basada en escenarios.

12
Tcnicas de evaluacin dinmica
Contexto de prueba de software.

Configuracin
del software

Resultados de
Prueba Evaluacin
la prueba

Configuracin
de la prueba Datos de Fallos
Resultados tasa de error
esperados

Modelo de
Depuracion
fiabilidad

Prediccion Correcciones
fiabilidad

13
Pruebas al Software
La prueba es una actividad costosa.
Debemos elevar la calidad de los
programas o sistemas informticos que
estn probando.
La prueba es el proceso de ejecucin de
un programa con el propsito de
encontrar errores.

14
Tcnicas de Prueba de Caja Blanca
Por lo general el programador las hace
como parte de pruebas de unidad (Unit
Test).
Intentan garantizar que:
Se ejecutan al menos una vez todos los
caminos independientes de cada mdulo.
Se utilizan las decisiones en su parte
verdadera y en su parte falsa
Se ejecuten todos los bucles en sus lmites.

15
Tcnica de prueba de caja blanca:
Prueba del Camino Bsico

Complejidad Ciclmatica,V(G) = Nro. de

caminos de ejecucin.
El recorrido de los caminos
independientes, garantiza que se ejecute
cada instruccin del programa por lo
menos una vez durante las pruebas.

16
Prueba del Camino Bsico
(1) Calcular la complejidad ciclomtica

V(G) = A-N+2
V(G)=11-9+2=4

V(G)=Nro Regiones

V(G)=NroNodosLgicos+1

V(G), es el nmero de caminos

Independientes = nro de pruebas

17
 Prueba del Camino Bsico

(2) Determinar el conjunto bsico de

Caminos independientes
C1: 1 9
C2: 1-2-4-8-1-9
C3: 1-2-3-6-7-8-1-9
C4:1-2-3-5-7-8-1-9

(3) Derivar los casos de prueba que fuerzan la ejecucin de

cada camino.

Nro Camino Caso Prueba Resultado Esperado

18
 Pensar en un
algoritmo para la
automatizacin del
conjunto de
caminos
independientes.

19
Ejercicios: Disear casos de prueba
funcion obtener_media: real ;
Var n, suma, conta, suma2, total_num: integer;
Begin
read (n);
repeat
if ( n>= 20 or n <= 50) then begin
suma := suma + n;
conta := conta + 1;
end
else
suma2 := suma2 + n;
total_num := total_num + 1;
read (n);
until n = 0;
obtener_media := suma / conta;
write (total_num, suma2);
End;

20
Tcnicas de evaluacin dinmica
Pruebas de caja negra o funcionales
Se basan en la especificacin del programa (o
componente) para elaborar los casos de prueba.
Se debe seleccionar un conjunto de entradas y salidas
para realizar las pruebas.
Criterios para confeccionar las casos de prueba de
caja negra: Particiones de equivalencia, Anlisis de
valores limite, Mtodos basados en grafo, Pruebas de
comparacin, Anlisis Causa-Efecto.

21
 Tcnicas de Prueba de Caja Negra
Particiones de equivalencia
1. Identificar clases de equivalencia.
Las clases de equivalencia representan conjuntos (estados
validos o no-validos) para condiciones de entrada

Condicin Clases de Clases de

Externa. equivalencia equivalencia no
validas. validas

22
Tcnicas de evaluacin dinmica
Pausas para identificar las clases de equivalencia
correspondientes:
Si una condicin de entrada especifica un rango de
valores, identificar 1 clase de equivalencia valida y 2
no validas.
Si una condicin de entrada especifica un valor o
numero de valores, identificar 1 clase de equivalencia
valida y 2 no validas.
Si una condicin de entrada especifica un conjunto
valores de entrada, identificar 1 clase de equivalencia
valida y 1 no valida.
Si una condicin de entrada especifica una situacion
que debe ocurrir, identificar 1 clase de equivalencia
valida y 1 no valida.

23
Tcnicas de evaluacin dinmica
2. Identificar los casos de prueba
El objetivo es minimizar el numero de casos de prueba.
Seguir los siguientes pasos:
Asignar a cada clase de equivalencia un numero nico.
Hasta que todas las clases de equivalencia hayan sido cubiertas
por los casos de prueba, se tratara de escribir un caso que
cubra tantas clases validas no incorporadas como sea posible.
Hasta que todas las clases de equivalencia no validas hayan
sido cubiertas por casos de prueba, escribir un caso para
cubrir una nica clase no valida no cubierta.

24
Tcnicas de evaluacin dinmica
Anlisis de valores limite
Las condiciones limite son aquellas que se
hallan en los mrgenes de equivalencia.
Elegir casos de prueba en los extremos.
En lugar de centrarse solo en el dominio de
entrada, los casos de prueba se disean
tambin considerando el dominio de salida.

25
Estrategias de Prueba
A la hora de evaluar dinmicamente un
sistema de software se debe permitir
comenzar por los componentes mas
simples y pequeos. Los pasos sig:
Pruebas unitarias (mdulos)
Un modulo es un bloque bsico de construccin de
programas.
Implementa una funcin independiente y simple.
Probado % separado.

26
Estrategias de Prueba
Pruebas de integracin
Integracin no incremental, todo el conjunto.
Integracin incremental, ascendente.

MC

MA
MB

C1 C2 C3

Grupo1 Grupo3
Grupo2

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
27
Estrategias de Prueba
Integracin incremental descendente:

M1

M2
R3

M4 R7 M3

R5 R6
M7

M5 M6

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
28
Estrategias de Prueba
Pruebas del sistema
Comprobar que:
Se cumplen los requisitos funcionales establecidos.
El funcionamiento y rendimiento de las interfaces
hardware, software y de usuario.
La adecuacin de la documentacin de usuarios.
Rendimiento y respuesta en condiciones limite y de
sobrecarga.
Pruebas , en el entorno del desarrollador.
Pruebas , en el entorno del cliente.

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
29
Estrategias de Prueba
Pruebas de aceptacin.
Participacin activa del usuario.
Enfocadas a probar los requerimientos del
usuario.
La fase final del proyecto. Tcnicas de
Caja Negra.
Pruebas de regresin.
Realizar pruebas repetidas en caso de que se
produzcan cambios en el software (durante el
desarrollo o mantenimiento).

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
30
Pruebas Orientadas a Objeto
Prueba de la unidad, la unidad menor ser
la clase u objeto encapsulado. Esta prueba
esta dirigida a las operaciones
encapsuladas y el estado del
comportamiento de la clase.
Prueba de integracin.
Prueba basada en hilos, integra el conjunto de
clases necesarias para responder a una
entrada o evento del sistema.
Evaluacin y Auditoria de sistemas de informacin - Cap 1 -
MSc. Patricia Romero R.
31
Pruebas Orientadas a Objeto
Prueba basada en el uso, empieza integrando
aquellas clases independientes o que usan
muy pocas de otras clases, continua
sucesivamente con las siguientes capas de
clases hasta integrar el sistema por completo.

32
Casos de prueba a partir de un diagrama
de secuencias
Definir el conjunto de secuencia de mensajes.
Analizar sub-secuencias de mensajes a partir de
posibles caminos condicionales en los diagramas
de secuencia.
Identificar los casos de prueba que se han de
introducir al sistema para que se ejecuten las
secuencias de mensajes anteriores, en funcin a
los mtodos y las clases afectadas por la
secuencia.

33
Pruebas Orientadas a Objeto
Prueba del sistema, se centra en las
acciones visibles del usuario y las salidas
del sistema reconocibles por ste.
Prueba de aceptacin, los clientes sern
quienes realicen estas pruebas y
suministren los casos de prueba.

Evaluacin y Auditoria de sistemas de informacin - Cap 1 -

MSc. Patricia Romero R.
34
Enlace visitado
http://www.grise.upm.es/sites/extras/12/p
df/Documentacion_Evaluacion_7.pdf

35