Tcnicas de Evaluacin

de Software
Natalia Juristo
Rodrigo Fonseca
Construir software es ms difcil
de lo que parece

n El 16,3% de los proyectos software tienen xito

El proyecto es completado en tiempo y en presupuesto, con todas las
caractersticas y funcionalidades especificadas al comienzo del proyecto

n El 52,7% de los proyectos software cuestan ms,

tardan ms o hacen menos
El proyecto es completado y operacional, pero con mayor presupuesto que el
presupuestado (189% mas), tardando ms del tiempo estimado y ofreciendo
menos caractersticas y funcionalidades de las especificadas inicialmente (42%)

n El 31% son cancelados

El proyecto es cancelado en cierto momento del desarrollo antes de poner el
sistema en operacin
Construir software es ms difcil
de lo que parece

De hecho Quin no ha sufrido

algn fallo misterioso en algn
software?
El software falla ms a menudo que
otros productos ingenieriles?
Por qu?
Son los errores irremediables?
Complejidad del software

n La extrema dificultad de los sistemas software

favorece a que existan errores remanentes en
los sistemas finalizados
n Un programa de unos centenares de lneas de cdigo
puede contener decenas de decisiones, lo que
implica miles de rutas de ejecucin alternativas. Es
materialmente imposible el ensayo de todas las
alternativas de ejecucin posibles

n Las alternativas posible de la realidad a la que el

software responde son cuasi-infinitas
Son los errores irremediables?
Falta de conocimiento
n Nuestra capacidad para garantizar la fiabilidad del
software es muy inferior a lo necesario. No podemos
demostrar la correccin de los programas al estilo
de los otros ingenieros
Los otros ingenieros usan anlisis matemticos para predecir el
comportamiento de sus sistemas. Esa prediccin permite descubrir
defectos antes de que el producto est operativo

n Las matemticas tradicionales, aptas para la

descripcin de sistemas fsicos, no son aplicables al
universo sinttico binario del software
Es la matemtica discreta, una especialidad mucho menos madura
y casi no estudiada hasta la aparicin de las computadoras, la que
gobierna el campo de los sistemas software
Son los errores irremediables?
Estado Actual
n Dada la imposibilidad de aplicar mtodos matemticos
rigurosos, el modo que tenemos para respaldar la
confianza de los programas es la ejercitacin
Hacer funcionar los programas, observando directamente su
comportamiento y depurndolos cada vez que aparece una
deficiencia. La fiabilidad de los programas crecer a lo largo de
este proceso

n La calidad que se puede obtener mediante este

procedimiento artesanal es bastante baja. De
ah que, a pesar de haber sido ensayados rigurosa y
sistemticamente, la mayora de los sistemas software
contengan todava defectos cuando son
entregados
Resumiendo
n Es imposible garantizar un producto
desarrollado 100% libre de defectos debido a
la inmadurez de la IS
n Falta de conocimientos cientficos que
predigan los resultados de las tcnicas
n Falta de normas sobre quien o cmo se
puede desarrollar software
n
Pero

Esta situacin no debe ser

una licencia para el
todo vale!!
Profesionalidad = Calidad

El objetivo de un
Ingeniero Software
debe ser
entregar un producto con el nivel de
Calidad
que las tcnicas de hoy permitan
Qu es la Calidad del Software?

n Quentienden ustedes por calidad

de un software?

n Unconcepto demasiado abstracto

que necesita descomponerse en
atributos ms palpables
Criterios de Calidad del Software
n Fiabilidad
n Funcionalidad

n Eficiencia

n Usabilidad

n Mantenibilidad

n Portabilidad

n Seguridad
Descomposicin de la Calidad de
Software por la ISO 9126-1998
Criterios de Calidad del Software
n Fiabilidad Se mantiene operativo
CALIDAD FUNCIONAL
n Funcionalidad Realiza el trabajo deseado

n Eficiencia Responde con velocidad apropiada

n Usabilidad El usuario est cmodo con l
CALIDAD NO FUNCIONAL
n Mantenibilidad Modificable con adecuado costo

n Portabilidad Opera en diferentes entornos

Funcionalidad y Fiabilidad
n Fiabilidad
El sistema software se mantiene operativo

n Funcionalidad
El sistema software realiza el trabajo deseado
por el usuario

Cmo se comprueban?
Evaluando la Fiabilidad

n Si la Fiabilidad es
El sistema software se mantiene operativo

n La Evaluacin se realizar
Buscando defectos que provoquen la mala
operacin del sistema (en cualquier contexto)
Evaluando la Funcionalidad
n Si la Funcionalidad es
El software realiza la tarea deseado por el usuario

n La Evaluacin se realizar
Comparando la tarea que realiza el sistema con la
esperada por el usuario (Especificacin de Requisitos)

n Realiza las tareas encomendadas

n Tiene los efectos o las respuestas correctas o acordadas
Entonces?
A S
T TIC
n
A S ES
Deben evaluarse los productos del

NIC
desarrollo segn se generan
TCEn lugar de esperar a tener cdigo!

IC A S
IN M
IC A SD
Debe ejercitarse el cdigo adecuadamente
N
n

T C
Evaluacin
DURANTE la construccin
Necesidad del Usuario Sistema Aceptado

Cdigo
Actividades de desarrollo y
actividades de evaluacin
Necesidad del Usuario

Cdigo Aceptado
Requisitos de
Usuario Definicin de
Revisin de Requisitos de Pruebas de Aceptacin
Requisitos de Usuario
Usuario
Requisitos de Usuario Revisados Cdigo instalado en
Los sistemas del usuario probado

Requisitos del Software Definicin de

Requisitos Pruebas de Sistema
Software
Revisin de
Requisitos del Requisitos del softwareRevisados Cdigo con la interaccin
Software entre mdulos probada
Diseo de la Pruebas de Integracin
Arquitectura
Diseo Arquitectinico
Cdigo con los
Revisin del Diseo mdulos probados
Arquitectnico Diseo Arquitectnico Revisado
Diseo Pruebas de Unidad
Detallado
Diseo Detallado
Cdigo
Revisin del Diseo Detallado Revisado Revisado
Diseo
Detallado
Codificacin
Cdigo

Revisin del
Cdigo
Cdigo Revisado
Evaluacin y Defectos

n La
evaluacin busca defectos en los
productos (Req. Ds. Cdg) del desarrollo
n Provocan mala operacin
n No se reflejan las tareas deseadas

n Se producen respuestas/efectos incorrectos

n No confundir defecto con fallo

Defecto: Error/Falta/Fallo
n Error Humano
Accin humana que produce una falta
n Falta Req, Dis, Codg,
Algo que est mal en unESTTICA
TCNICAS producto S
n Fallo Sistema
TCN ICAS
Manifestacin DINMICAS
de una falta

DEFECTO
Resumiendo lo aprendido hasta
aqu
n Es imposible garantizar un software 100% libre de
defectos debido a la inmadurez de la IS
n Pero existen tcnicas para reducir al mnimo los
defectos remanentes
n Tcnicas Estticas ( o Revisiones)
n Buscan faltas
n Aplicables a cualquier producto
n Tcnicas Dinmicas (o T. de Pruebas)
n Generan casos de prueba
n Buscan fallos
n Aplicables slo a cdigo
n Ambas se centran en defectos de fiabilidad y funcionalidad
Tecnicas Estticas
Tcnicas de Evaluacin Esttica
n Las tcnicas de Evaluacin esttica de
artefactos del desarrollo -> Revisiones.
n Revisiones -> detectan manualmente
defectos -> productos del desarrollo.
n Manualmente -> producto (sea requisito,
diseo, cdigo, etc.) -> impreso -> revisores -
> analizando -> lectura -> sin ejecutarlo.
Beneficios de las
Tcnicas Estticas
n Los defectos en productos tempranos se
traducen en defectos en el sistema
n Beneficio 1: Pronta deteccin = Menor
coste
n Beneficio 2: Pronta deteccin =
Estimacin de la calidad
n La cantidad y coincidencia de defectos
encontrados permite una estimacin de
los defectos remanentes
Defectos en los Requisitos

n El 52% de los proyectos software

entregan una media del 42% de las
funciones deseadas
Requisitos: Fuente de problemas
CAUSAS DE PROBLEMAS % RESPUESTAS
Requisitos incompletos 13,1%
Falta de participacin del usuario 12,4%
Falta de recursos 10,6%
Expectativas no realistas 9,9%
Falta de apoyo del nivel ejecutivo 9,3%
Cambio en los requisitos 8,7%

Pronta Deteccin =
Correccin ms Barata
n Entre el 30% y el 70% de los defectos de
diseo y cdigo pueden ser detectados
por las tcnicas estticas

n Esto supone un gran ahorro, pues la

correccin es ms fcil y menos costosa
durante la evaluacin esttica que durante
la dinmica
Coste Dinmica / Coste Esttica

n Dinmica n Esttica
n Generar casos de n -------
prueba
n Detectar el fallo n -------
n Buscar la falta n Buscar la falta
Pronta Deteccin =
Prevencin y Control
n La cantidad de faltas encontradas en un
producto dan una idea de la calidad del
trabajo de desarrollo de dicho producto

n Esto permite tomar medidas correctivas si

las mediciones indican que se est
llevando a cabo un trabajo pobre
Objetivos de la Evaluacin
Esttica
Objetivo de
las Tcnicas Estticas

n Deteccin de faltas

n Falta = Algo diferente a lo que debe ser;

algo que est fuera de lugar

n Cada producto tiene su tipo de falta, pues

tiene sus propios atributos de cmo debe
ser
Atributos de Calidad de los Productos del
Desarrollo

n Correccin
Interna y con respecto al producto precedente

n Completitud
n Ambigedad / Claridad
n Trazabilidad
Ejemplo
Requisito Incompleto y Ambiguo
n Requisito para un sistema de diagnstico a
bordo en los autos
El sistema deber proporcionar al conductor
indicaciones para llegar al garaje mecnico ms
cercano

n Incompleto
Qu informacin deben contener las indicaciones?
n Ambiguo
Qu es el garaje ms cercano?
Tipos de Revisiones
n Revisiones informales o Revisiones
Realizadas por el mismo desarrollador o entre compaeros
como tcnica de depuracin durante la etapa de construccin
del producto
R A
E C TU
n
E
Revisiones formales o InspeccionesL
S D
Conjunto de participantes elegidos formalmente para determinar

CA
la calidad del producto en la etapa de validacin

C N I
n

Walkthrough
Tprogramaenquesimular
Consiste la ejecucin de casos de prueba para el
se est evaluando

n Auditorias
Contrastan los artefactos generados durante el desarrollo con
estndares, generales o de la organizacin
Qu son las Inspecciones?

Proceso bien definido y disciplinado

donde un equipo de personas cualificadas
analizan un producto software usando una
tcnica de lectura con el propsito de
detectar defectos
Proceso de Inspeccin
1. Inicio
n Planificacin
n Lanzamiento

2. Deteccin de defectos
3. Recoleccin de defectos
n Compilacin
n Inspeccin en grupo

4. Correccin y seguimiento
n Correccin
n Seguimiento
n Grfico
Estimacin de los Defectos
Remanentes
n El propsito principal de las Inspecciones es
detectar y reducir el nmero de defectos
n Sin embargo un efecto colateral pero importante
es que permiten realizar desde momentos muy
iniciales del desarrollo predicciones de la
calidad del producto.
n Las estimaciones de las faltas remanentes tras
una inspeccin deben utilizarse como control de
la calidad del proceso de desarrollo.
Estimacin de los Defectos
Remanentes
n Hay varios momentos de estimacin de
faltas remanentes en una inspeccin.
n Se puede tener una idea de las faltas
remanentes en base a:
n Encontrar muchas faltas es sospechoso
n Encontrar muy pocas faltas tambin resulta
sospechoso.
Tcnicas de Lectura - Introduccin
n Guas que ayudan a detectar los defectos en los
productos software.
n Mecanismos -> Inspector adquiere un conocimiento
profundo del producto que inspecciona.
n Tcnicas ms populares:
n Ad-hoc
n Lectura basada en listas de comprobacin
n Otras tcnicas:
n Lectura por Abstraccin
n Revisin Activa de Diseo
n Lectura Basada en Escenarios
n Lectura Basada en Defectos
n Lectura Basada en Perspectivas
Tipos de Tcnicas de Lectura

n Ad-hoc
n Con Listas de Comprobacin

n Listas de Comprobacin con Perspectivas

n Abstraccin Sucesiva
Lista de Comprobacin
para Requisitos
n Estn especificadas todas las entradas al sistema,
incluyendo su origen, precisin, rango de valores y
frecuencia?
n Estn especificadas todas las salidas del sistema,
incluyendo su destino, precisin, rango de valores,
frecuencia y formato?
n Estn todos los formatos de los informes
especificados?
n Estn especificados los interfaces con otros sistemas
software y hardware externos?
n ...
Lista de Comprobacin
para Requisitos
n Existen contradicciones en la especificacin de los
requisitos?
n Resulta comprensible la especificacin?
n Est especificado el rendimiento?
n Puede ser eliminado algn requisito? Pueden juntarse
dos requisitos?
n Son redundantes o contradictorios?
n Se han especificado todos los recursos hardware
necesarios?
n Se han especificado las interfaces externas necesarias?
n Se han definido los criterios de aceptacin para cada una
de las funciones especificadas?
Lista de Comprobacin
para Diseo
Ejemplo de preguntas para diseo:
n Cubre el diseo todos los requisitos funcionales?

n Resulta ambigua la documentacin del diseo?

n Se ha aplicado la notacin de diseo correctamente?

n Se han definido correctamente las interfaces entre

elementos del diseo?
n Es el diseo suficientemente detallado como para
que sea posible implementarlo en el lenguaje de
programacin elegido?
Lista de Comprobacin para
Cdigo
n Lgica del programa:
n Es correcta la lgica del programa?
n Est completa la lgica del programa?, es decir, est todo
correctamente especificado sin faltar ninguna funcin?
n Interfaces Internas:
n Es igual el nmero de parmetros recibidos por el mdulo a
probar al nmero de argumentos enviados?, adems, el orden
es correcto?
n Los atributos (por ejemplo, tipo y tamao) de cada parmetro
recibido por el mdulo a probar coinciden con los atributos del
argumento correspondiente?
n ..
Lectura Basada en Perspectivas:
Diseador
n Est disponible toda la informacin necesaria para
hacer el diseo?
n Hay puntos en los cuales no ests seguro de lo que
deberas hacer porque el requisito no est claro o no
es consistente?
n Se han definido todos los objetos necesarios? (datos,
estructuras de datos y funciones)
n Se han especificado todas las condiciones para todos
los objetos?
n Se pueden definir todos los tipos de datos? (es decir,
se han especificado las unidades correspondientes as
como la precisin requerida?
 Lectura Basada en perspectivas:
Probador

n Puedes generar un caso de prueba para este

requisito?
n Puedes estar seguro de cules son las soluciones
correctas para los casos de prueba que generes para
este requisito?
n Hay otras interpretaciones de este requisito que el
implementador pueda hacer basndose en la forma en
que est definido el requisito? Afectar esto a los
casos de prueba que t generes?
n Hay otro requisito para el que generaras un caso de
prueba similar pero que te conducira a un resultado
contradictorio?
Lista de Comprobacin para
Sentencias Condicionales
n Sentencias if-then
n Se comportan las comprobaciones if-then
correctamente con la igualdad?
n Est la clusula else presente o
documentada?
n Es la clusula else correcta?

n Se usan las clusulas if y else

correctamente, no cambiadas?
n Sigue el caso normal el if ms que el else?
Lectura por Abstraccin Sucesiva
n Deteccin de defectos mediante
comparacin entre la especificacin del
programa y lo que hace realmente el
programa

n Defecto = Discrepancia entre

lo que debera hacer con
lo que hace
2) ANLISIS DINMICO DEL
SOFTWARE: PRUEBAS

Sira Vegas
Rodrigo Fonseca
 Conceptos Generales de
Evaluacin

Anlisis dinmico del software: pruebas

Papel de las pruebas de sw
Actividades de control y garanta de
calidad del software

Preventivas Correctivas
(Evaluacin de sw)

Buenos hbitos Anlisis esttico Anlisis dinmico

de construccin (pruebas)
del software
(metodologas, - Examen en
etc.) reposo - Examen resultado
- Aspectos funcionamiento del sw
estticos - Aspectos dinmicos
- Cualquier - Solamente cdigo
producto sw
Error, falta y fallo
n Distincin error/falta/fallo segn IEEE
n Error. Los humanos comenten errores con
razonamientos no correctos
n Falta. Error escrito en algn producto software
n Fallo. El sistema software no se comporta del modo
deseado
n Trmino genrico defecto
n Problema: Relacin no directa entre error/falta/
fallo
Definicin de prueba
n Proceso de ejecutar un programa o sistema con
la intencin de encontrar defectos
n Cualquier actividad dirigida a evaluar un atributo
o capacidad de un programa o sistema y
determinar que alcanza los resultados
requeridos
Principios de las pruebas (1/3)
n Las pruebas son el proceso de ejecutar un programa/
sistema con la intencin de descubrir defectos en el
software
n Un buen caso de prueba es aquel que tiene una alta
probabilidad de descubrir un defecto no encontrado
n Se deben definir las salidas o resultados esperados de
los casos de prueba
n Se debe realizar una inspeccin minuciosa de cada caso
de prueba
n Los caos de prueba se escriben para condiciones de
entrada vlidas/no vlidas y esperadas/inesperadas
Principios de las pruebas (2/3)
n La prueba del software se hace tanto para ver
si no hace lo que se supone que debe hacer,
como para ver si hace lo que se supone que no
debe hacer
n Un programador debe evitar probar su propio
programa
n Un equipo no debe probar sus propios
programas
n Se debe evitar tirar/perder los casos de prueba
n No se debe planificar el esfuerzo de la prueba
bajo la creencia de que no se encontrarn
defectos
Principios de las pruebas (3/3)
n La probabilidad de la existencia de ms defectos en una
parte del software es proporcional al nmero de
defectos ya encontrados en dicha parte
n La prueba completa (exhaustiva) no es posible
n Una razn para la prueba es prevenir deficiencias antes
de que ocurran
n La prueba est basada en el riesgo
n La prueba es una actividad extremadamente creativa,
intelectual y difcil
Problemtica
n La prueba exhaustiva no es viable
n Necesidad de predecir de forma precisa la
calidad del sistema software
n Seleccionar sobre el universo de entradas al
sistema aquellas que ayuden a predecir la
calidad del software con mayor exactitud
n Problema estadstico del muestreo
n Necesidad de tcnicas que ayuden a la seleccin
de casos de prueba
Clasificacin de familias (1/2)

Conocimiento de - Caja Blanca

la implementacin - Caja Negra
Criterios de
adecuacin - Estructurales
Enfoque - Basados en faltas
- Basados en errores
Clasificacin de familias (2/2)

Implementacin Caja Blanca Caja Negra

Enfoque
Flujo de control
Estructurales
Flujo de datos
Basadas en faltas Mutacin
Funcionales
Basadas en errores
Aleatorias
Tcnicas de flujo de control
n El programa se ve como una caja blanca
n Se generan casos atendiendo a la estructura de
control del programa
n Variantes:
n Cobertura de sentencias
n Cobertura de decisin
n Cobertura de condicin
n Cobertura de decisin/condicin
n Cobertura de condicin mltiple
Tcnicas de flujo de control: Prueba
del camino bsico (1/4)
n Camino: Secuencia de sentencias encadenadas
desde la entrada del programa hasta su salida.
n Disea casos para caminos independientes:
n Todas las sentencias se ejecutan al menos una vez.
n Las condiciones son probadas para valores verdadero y
falso.
n Se basa en la medida de complejidad ciclomtica de
Mc Cabe.
n Pasos:
n Representacin del programa como grafo de flujo.
n Clculo de la complejidad ciclomtica.
n Determinacin de un conjunto bsico de caminos
linealmente independientes.
n Derivacin de los casos de prueba.
Tcnicas de flujo de control: Prueba
del camino bsico (2/4)

n Elementos para representar el programa

como grafo de flujo
n Nodos. Representan cero, una o varias
sentencias.
n Aristas: Unen dos nodos.
n Regiones: reas delimitadas por aristas y nodos.
Para contarlas, se incluir la externa.
n Nodos Predicado: Surgen al descomponer las
sentencias compuestas en simples.
Tcnicas de flujo de control: Prueba
del camino bsico (3/4)

n Clculo de la complejidad ciclomtica:

n Mtrica software para averiguar la complejidad
lgica de un programa
n Aqu define el nmero de caminos independientes
n Pone lmite superior al nmero de caminos a
recorrer
n Representando como V(G) la complejidad:
n V(G) = Nmero de regiones
n V(G) = Aristas - Nodos + 2
n V(G) = Nmero de nodos predicado + 1
Tcnicas de flujo de control: Prueba
del camino bsico (4/4)
n Determinacin de un conjunto bsico de caminos
linealmente independientes:
n Elegir un camino inicial.
n Alterar la primera decisin y conservar el resto.
n Colocar primera decisin en su lugar y alterar la segunda,
intentando conservar el resto.
n Continuar el proceso hasta haber tratado todas las
decisiones, intentando conservar el resto
n Derivacin de los casos de prueba: Cada caso de
prueba se disear de tal modo, que corresponda a
cada uno de los caminos elegidos.
n PROBLEMA: El nmero ciclomtico no da idea acerca
de la complejidad de los datos
Tcnicas funcionales
n El programa se ve como una caja negra
n Se realizan pruebas sobre la interfaz del programa
n No es necesario conocer la lgica del programa, nicamente la
funcionalidad que debe tener.
n Intentan ejecutar casos de prueba relativos a posibles faltas en
el programa
n Divisin del dominio de entrada en clases vlidas y no vlidas
n Pasos
n Identificar las clases de equivalencia.

n Identificar los casos de prueba.

n Variantes:
n Particin en clases de equivalencia. Todos los elementos de
la clase son equi-probables.
n Anlisis de valores lmite. Se seleccionan casos del borde de
la clase
Tcnicas funcionales: Identificacin
de casos de prueba
n Para la tcnica de particin en clases de equivalencia:
n Asignar un nmero nico a cada clase de equivalencia.
n Escribir un caso que cubra tantas clases vlidas no
incorporadas como sea posible hasta que se cubran todas
las clases de equivalencia vlidas.
n Escribir un caso que cubra una sola clase no vlida no
incorporada hasta que se cubran todas las clases de
equivalencia no vlidas
n Para el anlisis de valores lmite:
n Condiciones lmite: Aquellas que se hallan en los
mrgenes de las clases de equivalencia tanto de entrada
como de salida.
n Se seleccionan uno o ms elementos tal que los mrgenes
de la clase se sometan a prueba.
n Se considerar tambin el dominio de salida
Tcnicas funcionales: Clases de
equivalencia
n Se examina cada condicin de entrada y se divide en
dos o ms grupos, identificando dos tipos de clases:
n Clases de equivalencia vlidas
n Clases de equivalencia no vlidas
n Se suelen representar mediante tablas.
n Proceso heurstico.
n Rango de valores: Una clase vlida y dos no vlidas.
n Nmero de valores: Una clase vlida y dos no vlidas
n Conjunto de valores de entrada: Tantas clases vlidas como
valores y una no vlida.
n Situacin que debe ocurrir: Una clase vlida y dos no
vlidas.
n Se cree que no todos los elementos de la case se tratan
igual: Dividir en subclases.