El documento discute las técnicas de evaluación de software, destacando que: 1) Es imposible garantizar un software 100% libre de defectos debido a la inmadurez de la ingeniería de software. 2) Sin embargo, existen técnicas como las revisiones estáticas y las pruebas dinámicas que pueden reducir los defectos remanentes. 3) Las revisiones estáticas, al detectar defectos tempranamente, permiten correcciones más baratas y estimaciones iniciales de la calidad.

1. Técnicas de Evaluación
de Software
Natalia Juristo
Rodrigo Fonseca

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

3. 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é?

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

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

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

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

8. Pero…
¡¡Esta situación no debe ser
una licencia para el
“todo vale”!!

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

10. ¿Qué es la Calidad del Software?
n ¿Qué entienden ustedes por calidad
de un software?
n Un concepto demasiado abstracto
que necesita descomponerse en
atributos más palpables

11. Criterios de Calidad del Software
n Fiabilidad
n Funcionalidad
n Eficiencia
n Usabilidad
n Mantenibilidad
n Portabilidad
n Seguridad

12. Descomposición de la Calidad de
Software por la ISO 9126-1998

13. Criterios de Calidad del Software
n Fiabilidad Se mantiene operativo
n Funcionalidad Realiza el trabajo deseado
n Eficiencia Responde con velocidad apropiada
n Usabilidad El usuario está cómodo con él
n Mantenibilidad Modificable con adecuado costo
n Portabilidad Opera en diferentes entornos
CALIDAD NO FUNCIONAL
CALIDAD FUNCIONAL

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

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

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

17. ¿Entonces?
n Deben evaluarse los productos del
desarrollo según se generan
¡En lugar de esperar a tener código!
n Debe ejercitarse el código adecuadamente
TÉCNICAS ESTÁTICAS
TÉCNICAS DINÁMICAS

18. Evaluación
DURANTE la construcción
Necesidad del Usuario Sistema Aceptado
Código

19. Actividades de desarrollo y
actividades de evaluación
Definición de
Requisitos de
Usuario
Definición de
Requisitos
Software
Diseño de la
Arquitectura
Diseño
Detallado
Codificación
Necesidad del Usuario
Requisitos de
Usuario
Requisitos del Software
Diseño Arquitectóinico
Diseño Detallado
Pruebas de Aceptación
Pruebas de Sistema
Pruebas de Integración
Pruebas de Unidad
Código Aceptado
Código instalado en
Los sistemas del usuario probado
Código con la interacción
entre módulos probada
Código con los
módulos probados
Código
Revisado
Revisión de
Requisitos de
Usuario
Requisitos de Usuario Revisados
Revisión de
Requisitos del
Software
Requisitos del softwareRevisados
Revisión del Diseño
Arquitectónico Diseño Arquitectónico Revisado
Revisión del
Diseño
Detallado
Diseño Detallado Revisado
Revisión del
Código
Código
Código Revisado

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

21. Defecto: Error/Falta/Fallo
n Error
Acción humana que produce una falta
n Falta
Algo que está mal en un producto
n Fallo
Manifestación de una falta
TÉCNICAS ESTÁTICAS
TÉCNICAS DINÁMICAS
Humano
Req, Disñ, Codg, …
Sistema
DEFECTO

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

23. Tecnicas Estáticas

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

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

26. Defectos en los Requisitos
n El 52% de los proyectos software
entregan una media del 42% de las
funciones deseadas

27. 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%
… …

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

29. Coste Dinámica / Coste Estática
n Dinámica
n Generar casos de
prueba
n Detectar el fallo
n Buscar la falta
n Estática
n -------
n -------
n Buscar la falta

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

31. Objetivos de la Evaluación
Estática

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

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

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

35. 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
n Revisiones formales o Inspecciones
Conjunto de participantes elegidos formalmente para determinar
la calidad del producto en la etapa de validación
n Walkthrough
Consiste en simular la ejecución de casos de prueba para el
programa que se está evaluando
n Auditorias
Contrastan los artefactos generados durante el desarrollo con
estándares, generales o de la organización
TÉCNICAS DE LECTURA

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

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

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

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

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

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

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

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

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

45. 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 ……..

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

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

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

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

50. 2) ANÁLISIS DINÁMICO DEL
SOFTWARE: PRUEBAS
Sira Vegas
Rodrigo Fonseca

51. Conceptos Generales de
Evaluación
Análisis dinámico del software: pruebas

52. Papel de las pruebas de sw
Actividades de control y garantía de
calidad del software
Preventivas Correctivas
(Evaluación de sw)
Análisis estático Análisis dinámico
(pruebas)
Buenos hábitos
de construcción
del software
(metodologías,
etc.)
- Examen en
reposo
- Aspectos
estáticos
- Cualquier
producto sw
- Examen resultado
funcionamiento del sw
- Aspectos dinámicos
- Solamente código

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

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

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

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

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

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

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

60. Clasificación de familias (2/2)
Implementación
Enfoque
Caja Blanca Caja Negra
Estructurales
Flujo de control
Flujo de datos
Basadas en faltas Mutación
Basadas en errores
Funcionales
Aleatorias

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

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

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

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

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

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

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

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