Please enable JavaScript.
Coggle requires JavaScript to display documents.
Evaluación de Software : - Coggle Diagram
Evaluación
de Software
:
Construir software es
más difícil de lo que parece
El 52,7% tardan más o hacen menos
El 31% son cancelados
16,3% de tienen éxito
¿Son los errores irremediables?
Complejidad del software
La dificultad de software hace existan errores remanentes
Profesionalidad = Calidad
el ingenieo debe entregar producto de calidad
Criterios de Calidad del Software
Mantenibilidad
Eficiencia
Portabilidad
Funcionalidad
software realiza el trabajo deseado
Seguridad
Fiabilidad
software se mantiene operativo
Usabilidad
Evaluación y Defectos
busca defectos en los
productos
Defecto: Error/Falta/Fallo
Tecnicas
Técnicas Estáticas
Manualmente -> producto
Evaluación estática -> Revisiones
Revisiones -> detectan manualmente
Beneficios
Pronta detección = Menor
coste
Pronta detección =
Estimación de la calidad
Coste Estática
Buscar la falta
Objetivos de la Evaluación
Falta = Algo diferente a
tiene sus propios atributos de cómo debe
ser
Detección de faltas
Atributos de Calidad de los Productos del
Desarrollo
Corrección
Completitud
Ambigüedad / Claridad
Trazabilidad
Requisito Incompleto
¿Qué información deben contener las indicaciones?
Requisito Ambiguo
¿Qué es el garaje más cercano?
Técnicas Dinámicas
Generan casos de prueba
Buscan fallos
Aplicables sólo a código
Tipos de Revisiones
Revisiones informales
Revisiones formales
Auditorias
¿Qué son las Inspecciones?
Proceso bien
definido y disciplinado
Corrección
Recolección
Detección
Inicio
Técnicas de Lectura
Técnicas populares
Otras técnicas:
Mecanismos -> Inspector
Lectura por Abstracción
Revisión Activa de Diseño
ayudan a detectar los defectos
Ad-hoc
basada en listas de comprobación
Lista de Comprobación
para Requisitos
¿Se han especificado todos los recursos?
¿Se han especificado las interfaces externas?
¿Son redundantes o contradictorios?
¿Está especificado el rendimiento?
¿Resulta comprensible la especificación?
¿Existen contradicciones?
Lista de Comprobación para
Código
Interfaces Internas
Lógica del programa:
Lectura Basada en Perspectivas:
Diseñador
¿Se han definido todos los objetos necesarios?
¿Se han especificado todas las condiciones?
¿Hay puntos en los cuales no estás seguro de lo que deberías?
¿Está disponible toda la información?
Lectura Basada en perspectivas:
Probador
¿Hay otro requisito para el que generarías un caso deprueba similar?
¿Puedes estar seguro de cuáles son las soluciones?
¿Puedes generar un caso de prueba para este
requisito?
Lectura por Abstracción Sucesiva
Detección de defectos mediante
comparación entre la especificación
e f e c t o = D i s c r e p a n c i a
Evaluación y Defectos
No confundir defecto
busca defectos en los
productos
ANÁLISIS DINÁMICO DEL
SOFTWARE: PRUEBAS
prueba
evaluación
Depuración
Modelo de Fiabilidad
Papel de las pruebas de sw
Correctivas
(Evaluación de sw)
Análisis estático
Análisis dinámico
(pruebas)
Preventivas
Error, falta y fallo
Problema: Relación no directa
Distinción error/falta/fallo
Falta. Error escrito
Fallo. El sistema software
Error. Los humanos comenten errores
Término genérico defecto
Definición de prueba
Proceso de ejecutar un programa
actividad dirigida a evaluar un atributo
Principios de las pruebas (1/3
Las pruebas son el proceso de ejecutar un programa
Se deben definir las salidas o resultados esperados
Se debe realizar una inspección minuciosa
Principios de las pruebas (2/3)
Un programador debe evitar probar su propio
programa
Un equipo no debe probar sus propios
programas
Problemática
Necesidad de predecir de forma precisa
Seleccionar sobre el universo de entradas
La prueba exhaustiva no es viable
Problema estadístico del muestreo
Principios de las pruebas (3/3)
Una razón para la prueba es prevenir
La prueba está basada en el riesgo
La prueba completa
La prueba es una actividad creativa