técnicas de evaluación de software -...
TRANSCRIPT
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 Un concepto 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
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
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?
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
Evaluación DURANTE la construcción
Necesidad del Usuario Sistema Aceptado
Código
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
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 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
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 Generar casos de
prueba n Detectar el fallo n Buscar la falta
n Estática n -------
n ------- 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
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
¿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 Defec to = D i sc repanc ia en t re
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)
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
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 la implementación
- Caja Blanca - Caja Negra
Criterios de adecuación
Enfoque - Estructurales - Basados en faltas - Basados en errores
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
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.