Técnicas de Evaluación

de Software
Natalia Juristo
Rodrigo Fonseca
Construir software es más difícil
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
características y funcionalidades especificadas al comienzo del proyecto

n  El 52,7% de los proyectos software cuestan más,

tardan más o hacen menos
El proyecto es completado y operacional, pero con mayor presupuesto que el
presupuestado (189% mas), tardando más del tiempo estimado y ofreciendo
menos características 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 operación
Construir software es más difícil
de lo que parece

De hecho… ¿Quién no ha sufrido

algún fallo misterioso en algún
software?
¿El software falla más 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 líneas de código
puede contener decenas de decisiones, lo que
implica miles de rutas de ejecución alternativas. Es
materialmente imposible el ensayo de todas las
alternativas de ejecución 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 corrección de los programas al estilo
de los otros ingenieros
Los otros ingenieros usan análisis matemáticos para predecir el
comportamiento de sus sistemas. Esa predicción permite descubrir
defectos antes de que el producto esté operativo

n  Las matemáticas tradicionales, aptas para la

descripción de sistemas físicos, no son aplicables al
universo sintético binario del software
Es la matemática discreta, una especialidad mucho menos madura
y casi no estudiada hasta la aparición de las computadoras, la que
gobierna el campo de los sistemas software
¿Son los errores irremediables?
Estado Actual
n  Dada la imposibilidad de aplicar métodos matemáticos
rigurosos, el modo que tenemos para respaldar la
confianza de los programas es la ejercitación
Hacer funcionar los programas, observando directamente su
comportamiento y depurándolos 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
sistemáticamente, la mayoría de los sistemas software
contengan todavía 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 científicos que
predigan los resultados de las técnicas
n  Falta de normas sobre quien o cómo se
puede desarrollar software
n  …
Pero…

¡¡Esta situación 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 técnicas de hoy permitan
¿Qué es la Calidad del Software?

n  ¿Quéentienden ustedes por calidad

de un software?

n  Unconcepto demasiado abstracto

que necesita descomponerse en
atributos más palpables
Criterios de Calidad del Software
n  Fiabilidad
n  Funcionalidad

n  Eficiencia

n  Usabilidad

n  Mantenibilidad

n  Portabilidad

n  Seguridad
Descomposición 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á cómodo 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

¿Cómo se comprueban?
Evaluando la Fiabilidad

n  Si la Fiabilidad es
El sistema software se mantiene operativo

n  La Evaluación se realizará

Buscando defectos que provoquen la mala
operación del sistema (en cualquier contexto)
Evaluando la Funcionalidad
n  Si la Funcionalidad es
El software realiza la tarea deseado por el usuario

n  La Evaluación se realizará

Comparando la tarea que realiza el sistema con la
esperada por el usuario (Especificación 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 según se generan
TÉC¡En lugar de esperar a tener código!

IC A S
IN Á M
IC A SD
Debe ejercitarse el código adecuadamente
N
n 

TÉ C
Evaluación
DURANTE la construcción
Necesidad del Usuario Sistema Aceptado

Código
Actividades de desarrollo y
actividades de evaluación
Necesidad del Usuario

Código Aceptado
Requisitos de
Usuario Definición de
Revisión de Requisitos de Pruebas de Aceptación
Requisitos de Usuario
Usuario
Requisitos de Usuario Revisados Código instalado en
Los sistemas del usuario probado

Requisitos del Software Definición de

Requisitos Pruebas de Sistema
Software
Revisión de
Requisitos del Requisitos del softwareRevisados Código con la interacción
Software entre módulos probada
Diseño de la Pruebas de Integración
Arquitectura
Diseño Arquitectóinico
Código con los
Revisión del Diseño módulos probados
Arquitectónico Diseño Arquitectónico Revisado
Diseño Pruebas de Unidad
Detallado
Diseño Detallado
Código
Revisión del Diseño Detallado Revisado Revisado
Diseño
Detallado
Codificación
Código

Revisión del
Código
Código Revisado
Evaluación y Defectos

n  La
evaluación busca defectos en los
productos (Req. Dsñ. Cdg) del desarrollo
n  Provocan mala operación
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
Acción humana que produce una falta
n  Falta Req, Disñ, Codg, …
Algo que está mal en unESTÁTICA
TÉCNICAS producto S
n  Fallo Sistema
TÉCN ICAS
Manifestación DINÁMICAS
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 técnicas para reducir al mínimo los
defectos remanentes
n  Técnicas Estáticas ( o Revisiones)
n  Buscan faltas
n  Aplicables a cualquier producto
n  Técnicas Dinámicas (o T. de Pruebas)
n  Generan casos de prueba
n  Buscan fallos
n  Aplicables sólo a código
n  Ambas se centran en defectos de fiabilidad y funcionalidad
Tecnicas Estáticas
Técnicas de Evaluación Estática
n  Las técnicas de Evaluación estática de
artefactos del desarrollo -> Revisiones.
n  Revisiones -> detectan manualmente
defectos -> productos del desarrollo.
n  Manualmente -> producto (sea requisito,
diseño, código, etc.) -> impreso -> revisores -
> analizando -> lectura -> sin ejecutarlo.
Beneficios de las
Técnicas Estáticas
n  Los defectos en productos tempranos se
traducen en defectos en el sistema
n  Beneficio 1: Pronta detección = Menor
coste
n  Beneficio 2: Pronta detección =
Estimación de la calidad
n  La cantidad y coincidencia de defectos
encontrados permite una estimación 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 participación 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 Detección =
Corrección más Barata
n  Entre el 30% y el 70% de los defectos de
diseño y código pueden ser detectados
por las técnicas estáticas

n  Esto supone un gran ahorro, pues la

corrección es más fácil y menos costosa
durante la evaluación estática que durante
la dinámica
Coste Dinámica / Coste Estática

n  Dinámica n  Estática

n  Generar casos de n  -------
prueba
n  Detectar el fallo n  -------
n  Buscar la falta n  Buscar la falta
Pronta Detección =
Prevención 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 Evaluación
Estática
Objetivo de
las Técnicas Estáticas

n  Detección 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 cómo debe
ser
Atributos de Calidad de los Productos del
Desarrollo

n  Corrección
Interna y con respecto al producto precedente

n  Completitud
n  Ambigüedad / Claridad
n  Trazabilidad
Ejemplo
Requisito Incompleto y Ambiguo
n  Requisito para un sistema de diagnóstico a
bordo en los autos
El sistema deberá proporcionar al conductor
indicaciones para llegar al garaje mecánico más
cercano

n  Incompleto
¿Qué información deben contener las indicaciones?
n  Ambiguo
¿Qué es el garaje más cercano?
Tipos de Revisiones
n  Revisiones informales o Revisiones
Realizadas por el mismo desarrollador o entre compañeros
como técnica de depuración durante la etapa de construcción
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 validación

C N I
n 
É
Walkthrough
Tprogramaenquesimular
Consiste la ejecución de casos de prueba para el
se está evaluando

n  Auditorias
Contrastan los artefactos generados durante el desarrollo con
estándares, generales o de la organización
¿Qué son las Inspecciones?

Proceso bien definido y disciplinado

donde un equipo de personas cualificadas
analizan un producto software usando una
técnica de lectura con el propósito de
detectar defectos
Proceso de Inspección
1.  Inicio
n  Planificación
n  Lanzamiento

2.  Detección de defectos

3.  Recolección de defectos
n  Compilación
n  Inspección en grupo

4.  Corrección y seguimiento

n  Corrección
n  Seguimiento
n  Gráfico
Estimación de los Defectos
Remanentes
n  El propósito principal de las Inspecciones es
detectar y reducir el número 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 inspección deben utilizarse como control de
la calidad del proceso de desarrollo.
Estimación de los Defectos
Remanentes
n  Hay varios momentos de estimación de
faltas remanentes en una inspección.
n  Se puede tener una idea de las faltas
remanentes en base a:
n  Encontrar muchas faltas es sospechoso
n  Encontrar muy pocas faltas también resulta
sospechoso.
Técnicas de Lectura - Introducción
n  Guías que ayudan a detectar los defectos en los
productos software.
n  Mecanismos -> Inspector adquiere un conocimiento
profundo del producto que inspecciona.
n  Técnicas más populares:
n  Ad-hoc
n  Lectura basada en listas de comprobación
n  Otras técnicas:
n  Lectura por Abstracción
n  Revisión Activa de Diseño
n  Lectura Basada en Escenarios
n  Lectura Basada en Defectos
n  Lectura Basada en Perspectivas
Tipos de Técnicas de Lectura

n  Ad-hoc
n  Con Listas de Comprobación

n  Listas de Comprobación con Perspectivas

n  Abstracción Sucesiva

Lista de Comprobación
para Requisitos
n  ¿Están especificadas todas las entradas al sistema,
incluyendo su origen, precisión, rango de valores y
frecuencia?
n  ¿Están especificadas todas las salidas del sistema,
incluyendo su destino, precisión, rango de valores,
frecuencia y formato?
n  ¿Están todos los formatos de los informes
especificados?
n  ¿Están especificados los interfaces con otros sistemas
software y hardware externos?
n  ...
Lista de Comprobación
para Requisitos
n  ¿Existen contradicciones en la especificación de los
requisitos?
n  ¿Resulta comprensible la especificación?
n  ¿Está especificado el rendimiento?
n  ¿Puede ser eliminado algún 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 aceptación para cada una
de las funciones especificadas?
Lista de Comprobación
para Diseño
Ejemplo de preguntas para diseño:
n  ¿Cubre el diseño todos los requisitos funcionales?

n  ¿Resulta ambigua la documentación del diseño?

n  ¿Se ha aplicado la notación de diseño correctamente?

n  ¿Se han definido correctamente las interfaces entre

elementos del diseño?
n  ¿Es el diseño suficientemente detallado como para
que sea posible implementarlo en el lenguaje de
programación elegido?
Lista de Comprobación para
Código
n  Lógica del programa:
n  ¿Es correcta la lógica del programa?
n  ¿Está completa la lógica del programa?, es decir, ¿está todo
correctamente especificado sin faltar ninguna función?
n  Interfaces Internas:
n  ¿Es igual el número de parámetros recibidos por el módulo a
probar al número de argumentos enviados?, además, ¿el orden
es correcto?
n  ¿Los atributos (por ejemplo, tipo y tamaño) de cada parámetro
recibido por el módulo a probar coinciden con los atributos del
argumento correspondiente?
n  ……..
Lectura Basada en Perspectivas:
Diseñador
n  ¿Está disponible toda la información necesaria para
hacer el diseño?
n  ¿Hay puntos en los cuales no estás seguro de lo que
deberías 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 precisión requerida? 
 Lectura Basada en perspectivas:
Probador

n  ¿Puedes generar un caso de prueba para este

requisito? 
n  ¿Puedes estar seguro de cuáles 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 basándose 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 generarías un caso de
prueba similar pero que te conduciría a un resultado
contradictorio?
Lista de Comprobación para
Sentencias Condicionales
n  Sentencias if-then
n  ¿Se comportan las comprobaciones if-then
correctamente con la igualdad?
n  ¿Está la cláusula else presente o
documentada?
n  ¿Es la cláusula else correcta?

n  ¿Se usan las cláusulas if y else

correctamente, no cambiadas?
n  ¿Sigue el caso normal el if más que el else?
Lectura por Abstracción Sucesiva
n  Detección de defectos mediante
comparación entre la especificación del
programa y lo que hace realmente el
programa

n  Defecto = Discrepancia entre

lo que debería hacer con
lo que hace
2) ANÁLISIS DINÁMICO DEL
SOFTWARE: PRUEBAS

Sira Vegas
Rodrigo Fonseca
 Conceptos Generales de
Evaluación

Análisis dinámico del software: pruebas

Papel de las pruebas de sw
Actividades de control y garantía de
calidad del software

Preventivas Correctivas
(Evaluación de sw)

Buenos hábitos Análisis estático Análisis dinámico

de construcción (pruebas)
del software
(metodologías, - Examen en
etc.) reposo - Examen resultado
- Aspectos funcionamiento del sw
estáticos - Aspectos dinámicos
- Cualquier - Solamente código
producto sw
Error, falta y fallo
n  Distinción error/falta/fallo según IEEE
n  Error. Los humanos comenten errores con
razonamientos no correctos
n  Falta. Error escrito en algún producto software
n  Fallo. El sistema software no se comporta del modo
deseado
n  Término genérico defecto
n  Problema: Relación no directa entre error/falta/
fallo
Definición de prueba
n  Proceso de ejecutar un programa o sistema con
la intención 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 intención 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 inspección minuciosa de cada caso
de prueba
n  Los caos de prueba se escriben para condiciones de
entrada válidas/no válidas 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 encontrarán
defectos
Principios de las pruebas (3/3)
n  La probabilidad de la existencia de más defectos en una
parte del software es proporcional al número de
defectos ya encontrados en dicha parte
n  La prueba completa (exhaustiva) no es posible
n  Una razón 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 difícil
Problemática
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 estadístico del muestreo
n  Necesidad de técnicas que ayuden a la selección
de casos de prueba
Clasificación de familias (1/2)

Conocimiento de - Caja Blanca

la implementación - Caja Negra
Criterios de
adecuación - Estructurales
Enfoque - Basados en faltas
- Basados en errores
Clasificación de familias (2/2)

Implementación Caja Blanca Caja Negra

Enfoque
Flujo de control
Estructurales
Flujo de datos
Basadas en faltas Mutación
Funcionales
Basadas en errores
Aleatorias
Técnicas 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 decisión
n  Cobertura de condición
n  Cobertura de decisión/condición
n  Cobertura de condición múltiple
Técnicas de flujo de control: Prueba
del camino básico (1/4)
n  Camino: Secuencia de sentencias encadenadas
desde la entrada del programa hasta su salida.
n  Diseña 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 ciclomática de
Mc Cabe.
n  Pasos:
n  Representación del programa como grafo de flujo.
n  Cálculo de la complejidad ciclomática.
n  Determinación de un conjunto básico de caminos
linealmente independientes.
n  Derivación de los casos de prueba.
Técnicas de flujo de control: Prueba
del camino básico (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.
Técnicas de flujo de control: Prueba
del camino básico (3/4)

n  Cálculo de la complejidad ciclomática:

n  Métrica software para averiguar la complejidad
lógica de un programa
n  Aquí define el número de caminos independientes
n  Pone límite superior al número de caminos a
recorrer
n  Representando como V(G) la complejidad:
n  V(G) = Número de regiones
n  V(G) = Aristas - Nodos + 2
n  V(G) = Número de nodos predicado + 1
Técnicas de flujo de control: Prueba
del camino básico (4/4)
n  Determinación de un conjunto básico de caminos
linealmente independientes:
n  Elegir un camino inicial.
n  Alterar la primera decisión y conservar el resto.
n  Colocar primera decisión 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  Derivación de los casos de prueba: Cada caso de
prueba se diseñará de tal modo, que corresponda a
cada uno de los caminos elegidos.
n  PROBLEMA: El número ciclomático no da idea acerca
de la complejidad de los datos
Técnicas 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 lógica del programa, únicamente la
funcionalidad que debe tener.
n  Intentan ejecutar casos de prueba relativos a posibles faltas en
el programa
n  División del dominio de entrada en clases válidas y no válidas
n  Pasos
n  Identificar las clases de equivalencia.

n  Identificar los casos de prueba.

n  Variantes:
n  Partición en clases de equivalencia. Todos los elementos de
la clase son equi-probables.
n  Análisis de valores límite. Se seleccionan casos del borde de
la clase
Técnicas funcionales: Identificación
de casos de prueba
n  Para la técnica de partición en clases de equivalencia:
n  Asignar un número único a cada clase de equivalencia.
n  Escribir un caso que cubra tantas clases válidas no
incorporadas como sea posible hasta que se cubran todas
las clases de equivalencia válidas.
n  Escribir un caso que cubra una sola clase no válida no
incorporada hasta que se cubran todas las clases de
equivalencia no válidas
n  Para el análisis de valores límite:
n  Condiciones límite: Aquellas que se hallan en los
márgenes de las clases de equivalencia tanto de entrada
como de salida.
n  Se seleccionan uno o más elementos tal que los márgenes
de la clase se sometan a prueba.
n  Se considerará también el dominio de salida
Técnicas funcionales: Clases de
equivalencia
n  Se examina cada condición de entrada y se divide en
dos o más grupos, identificando dos tipos de clases:
n  Clases de equivalencia válidas
n  Clases de equivalencia no válidas
n  Se suelen representar mediante tablas.
n  Proceso heurístico.
n  Rango de valores: Una clase válida y dos no válidas.
n  Número de valores: Una clase válida y dos no válidas
n  Conjunto de valores de entrada: Tantas clases válidas como
valores y una no válida.
n  Situación que debe ocurrir: Una clase válida y dos no
válidas.
n  Se cree que no todos los elementos de la case se tratan
igual: Dividir en subclases.