ITI Gestión. Programa

Transcripción

1 1 Calidad del Software ITI Gestión Calidad del Software 2 Programa 1. Medición y experimentación en Ingeniería del Software Introducción Teoría representacional de la medición. Recursos y problemas de la experimentación en Ingeniería del software. 2. Medidas del Producto 3. Modelos y métricas del Proceso 4. Calidad del Software 4.1 Introducción 4.2 Control y Aseguramiento de la calidad 4.3 Estándares de calidad 1

2 Control de la calidad 3 Bibliografía Piattini M., García F.O.. Calidad en el desarrollo y mantenimiento del software. Ed RAMA, Camisón C., Cruz S., González T. Gestión de la calidad, Pearson. Prentice Hall. Minguet Melián J.M. y Hernández Ballesteros J.F. La calidad del software y su medida. E. Centro de Estudios RA Martí Casadesús et al, Calidad Práctica. Prentice Hall Algunas referencias web g Calidad del Software Calidad Objetivos del Tema Comprender el concepto de calidad d Conocer modelos de calidad y su aplicación Conocer conceptos básicos: control y aseguramiento de la calidad Ventajas e inconvenientes de los modelos de calidad 2

3 Calidad del Software 4.1 Introducción Introducción 5 Qué es la calidad del software? En 1990 se establecen principios de calidad del software: Calidad del producto, en todos sus estados Calidad del proceso Qué diferencia hay con otros productos? Naturaleza Ciclo de vida Flexibilidad Reutilización 6 Concepto de Calidad (i) Concepto de Calidad: Multidimensional Referida a varias cualidades: Funcionalidad, Oportunidad, Coste, Sujeta a restricciones Presupuesto disponible Ligado a compromisos aceptables Plazos de fabricación No es ni totalmente subjetiva (porque ciertos aspectos pueden medirse) Ni totalmente objetiva (ya que existen cualidades cuya evaluación sólo puede ser subjetiva). 3

4 Calidad del Software Introducción 7 Concepto de Calidad (ii) La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que influyen en su capacidad para satisfacer las necesidades expresadas o implícitas ISO 8402 La capacidad del producto software para satisfacer los requisitos establecidos DoD 2168 La calidad es algo relativo Su evaluación implica una comparación No se puede conseguir buena calidad sin una buena ERS Calidad del Software Introducción 8 Perspectivas de la Calidad TRASCENDENTAL (calidad = excelencia) BASADA EN USUARIO (adecuación al propósito) BASADA EN FABRICANTE (capacidad y madurez de proceso) BASADA EN PRODUCTO (conformidad con requisitos) BASADA EN VALOR (precio asequible) 4

5 Calidad del Software Introducción 9 Perspectivas de la calidad (ii) Niveles de la calidad La que se pretende obtener Programada especificada Necesaria o requerida La que quiere el cliente Realizada La que hemos construido La gestión de la calidad busca conseguir que estos tres círculos coincidan entre sí. Todo lo que no sea coincidencia es gasto superfluo o insatisfacción. Calidad del Software Introducción 10 Definición precisa Modelos de calidad Proceso a seguir Construcción Aseguramiento de la calidad Gestión de la calidad Confirmación Control de la calidad La norma ISO 9000:2000 es la principal referencia internacional sobre conceptos de calidad. versión española: UNE-EN ISO 9000:2000 Sistemas de Gestión de la Calidad. Fundamentos y Vocabulario 5

6 Calidad del Software Introducción 11 Modelos de calidad Jerarquizan el concepto de calidad Facilita las operaciones Estructura clásica para productos (F-C-M) Factores: Punto de vista del usuario. Atributos de calidad externos Criterios: Punto de vista del producto. Atributos de calidad internos Métricas: Medidas cuantitativas Calidad del Software Utilidad de los modelos de calidad (i) Introducción 12 Concretan la calidad, d definiéndola, d midiéndola d y planificando Ayudan a comprender las relaciones entre las características del producto software Facilitan la comunicación entre usuarios, directivos y ténicos Son empíricos, su validez se demuestra observando resultados 6

7 Calidad del Software Utilidad de los modelos de calidad (ii) Introducción 13 En la planificación, establecimiento de los requisitos de calidad Aceptación del Modelo de calidad: F-C-M u otro Aceptación de las relaciones Establecimiento de los requisitos de calidad, dependen de: Tipo de producto Ciclo de vida: duración y tipo Evolución del hardware Calidad del Software Utilidad de los modelos de calidad (iii) Introducción 14 Establecimiento de los requisitos de calidad (sigue): Costes del factor vs. beneficios esperados Repercusiones en el ciclo de vida Interrelaciones con otros factores Ordenar los requisitos por prioridades Obtener F-C-M involucrados. Problemas? Establecer objetivos medibles, y mínimos aceptables (revisar métricas externas) 7

8 Calidad del Software Introducción 15 Calidad 6 σ (i) Calidad: # defectos Métrica: Tasa de defectos Objetivo: 6σ (valores medios 2-60de/KLDC) Justificación: modelos de calidad muy costosos Riesgos de mal uso: Todos los fallos no tienen la misma importancia Todos los defectos no ocurren con la misma probabilidad Introducción 16 Calidad 6 σ (ii) Procesos de desarrollo: distribución normal Probabilidad bilid d (valores fuera de (LI, LS))= probabilidad bilid d de defecto Un proceso poco preciso y sesgado tiene alta probabilidad de defecto. 8

9 Introducción 17 Calidad 6 σ (iii) Control de la calidad 18 Objetivos del 4.2 Control y Aseguramiento de la calidad Diferenciar entre verificación y validación Conocer y saber usar actividades de control de calidad Inspecciones Revisiones Pruebas Conocer que es un Plan de Aseguramiento de Calidad Saber aplicar ciertas fases del PGAC de las Administraciones públicas 9

10 Control de la calidad 19 Definiciones (i) Error Defecto (Fault) Fallo (Default) Incidencia: Situación en la que se produce e informa de un comportamiento no esperado del sistema Control de la calidad 20 Definiciones (ii) Validación (con respecto a ERS) Grado en que el sistema hace lo que el usuario espera Estamos construyendo el producto correcto? Verificación (con respecto a las entradas) Grado en que el producto se construye correctamente El sistema está bien construido? Control de Calidad: Verifica o Valida 10

11 Control de la calidad 21 Auditorías (i) Investigación para: Verificar conformidad con procedimientos, instrucciones, estándares, ER de cualquier tipo Identificar desviaciones Proponer soluciones Evaluar la adecuación de los cambios Control de la calidad 22 Tipos de auditorías Del producto o Funcional o Física Auditorías (ii) Del proceso o Equipo (productividad, eficacia ) o Métodos y herramientas (efectividad) De la gestión o Prácticas de gestión (efectividad) o Organización Del sistema de calidad 11

12 Control de la calidad 23 Procedimiento Auditorías (iii) Planificación o Porqué? para qué? o Entradas, salidas esperadas, destino de las salidas o Quién? Cómo? Cuándo? Investigación o Reunión de apertura o Recogida de datos Control de la calidad 24 Procedimiento Auditorías (iv) Análisis de resultados o Análisis estadístico o Evaluación en paralelo o Comparación de conclusiones o Estudio de causas Sugerencias de soluciones, mejoras Informes con los resultados 12

13 Control de la calidad 25 Revisiones vs. Auditorías Cuándo: primeras fases vs. fases finales Objetivos: detectar defectos vs. certificar conformidad Atributo Revisiones Auditorías Mecanismo Reuniones Reuniones, exámenes, observaciones Responsabilidad Del equipo, usualmente Equipo ajeno a la empresa, con un de la organización auditor responsable Duración Corta: unas horas Media - larga: días o meses Estructura del Reuniones de múltiples Incluye otras auditorías, revisiones desarrollo sesiones o pruebas periódicas Frecuencia Depende de la fase del Periódica ciclo de vida Control de la calidad 26 Revisiones formales (i) Objetivos Ofrecer información fiable y objetiva a los gestores Asignar responsabilidades no sólo a los autores Tipos Por objeto: de gestión o proyecto y técnicas Por formalidad y mecánica o Inspecciones o Recorridos 13

14 Control de la calidad 27 Revisiones formales (ii) De gestión. Recomendaciones para: seguir el plan del proyecto determinar cambios mantener control Técnicas. Evalúan el producto intermedio para comprobar si: Se ajusta a especificaciones El desarrollo sigue planes, estándares y guías Los cambios se hacen bien Control de la calidad 28 Inspecciones (i) Técnica de revisión formal, en la que requisitos de software, diseño o codificación se examinan en detalle por un grupo de personas distintos del autor, para detectar defectos, disconformidades con las normas de desarrollo y otros problemas (IEEE, 1990) Reglas a seguir: Inspeccionar toda clase de problemas Participan personas de todos los niveles Etapas predefinidas Reuniones no superiores a 2h Moderadores y directores expertos Cada miembro tiene funciones detalladas para hacer Listas de comprobación Archivo de estadísticas y defectos 14

15 Inspecciones (ii) Control de la calidad 29 Etapa Objetivo Tarea Participantes Planificación Organizar Aprobar criterios de entrada Establecer tiempos y participantes Moderador Autor Determinar presentación Preparar notificación ió de la I. Distribuir material a los inspectores Visión general Enseñar producto (P) Presentar el producto Todos Preparación Comprender P Estudio individual del P Todos Identificar defectos Reunión Verificar P Introducción Todos Comprobar preparación inspectores Lectura y detección de defectos Revisar lista de defectos Determinar disposición del P Tercera hora (*) Aprovechar posibles Analizar posibles mejoras o Todos soluciones soluciones Corrección Cumplir criterios de salida Resolver todos los defectos Autor Seguimiento Verificar la corrección Comprobar que se resolvieron Moderador Análisis de resultados (*) Analizar para posteriores inspecciones y que no hay nuevos Clasificar defectos (clase, tipo y gravedad Coordinador Listas de comprobación Inspecciones (iii) Uniformidad en el diseño? Control de la calidad 30 Interfaces entre módulos definidas correctamente Interfaces externas definidas correctamente? El diseño cubre todas las funciones de la especificación de requisitos? El diseño cumple todos los requisitos no funcionales? Se ha aplicado la notación de diseño correctamente? La documentación del diseño es ambigua? Diseño suficientemente detallado para implementarlo en el lenguaje elegido? 15

16 Control de la calidad 31 Inspecciones (iv) Documentos generados Notificación de la reunión y detalle de tareas, lugares, tiempos etc Informe resumen de defectos Distribución de defectos Informe final de la inspección Administrativo Esfuerzo realizado Inspecciones (v) Control de la calidad 32 Documentos generados Lista de defectos Registro detallado que incluye: o Localización o Descripción o Clasificación o Gravedad 16

17 Control de la calidad 33 Una clasificación de defectos Tipo de defecto Cumplimiento con estándares Desviación del producto respecto de los estándares Factores humanos (error) Procedimientos operativos incorrectos Documentación Algún componente esta mal descrito Funcionalidad Componente con especificaciones funcionales defectuosas Interfaz Defectos en la comunicación Datos Datos mal especificados Lógico Módulo con lógica de control defectuosa Entrada/Salida Comunicación con dispositivos defectuosa Sintaxis Defectos gramaticales Casos de prueba Condición de prueba mal especificada, o desviada del plan Ejecución Eficiencia menor que la prevista Gravedad del defecto: Depende de las consecuencias. Clase de defecto: Por ausencia, error o añadido Control de la calidad 34 Coste de las inspecciones (i) Cálculo del coste de la recogida de información sobre defectos: Coste = Tamaño x Densidad media de defectos x Tº para registrar 1/12 horas/defecto = 8 1/3 horas 100 KLDC x 1 defecto/kldc x 1/6 horas/defecto = 16 2/3 horas Tamaño 100 KLDC Nº de inspectores 4 ó 5 tº de preparación/ tº de inspección > 1.75 Productividad de la inspección líneas de diseño/hora Efectividad de la inspección 2.5 defectos/hora tasa de defectos/kldc, estimada 8 tasa de defectos producidos en el diseño, estimada 18% tasa de defectos de diseño encontrados en inspecciones 55% 17

18 Control de la calidad 35 Coste de las inspecciones (ii) Estimación de defectos encontrados en insp. de diseño: 100 kldc x 8 def/kldc x 0.18def-dis/def di f x 0.55 def-dis-en/def-dis di f di = 79 def-dis di Estimación de horas de insp. para encontrar los defectos: 79def _ dis _ enc (1,75 + 1) horas 4.5inspec = 392horas. inspec (2.5def _ dis _ enc / hora _ ins) 1hora _ ins Estimación de horas para encontrar defectos en la fase de test t (tasa de coste defectos atrasados = 6,25) 392 horas x 6.25 = 2450 horas Conclusión: = 2058 horas ahorradas Control de la calidad 36 Procedimiento de un recorrido 1. Planificación Sólo hay dos roles: Presentador Participante 2. Preparación individual Sin lista de comprobación 3. Reunión Se pueden sugerir soluciones 36 18

19 Control de la calidad 37 Inspecciones vs. Recorrido Propiedades Inspección Recorrido 1. Entrenamiento formal del moderador SI NO 2. Roles definidos para participantes SI NO 3. Guía de la revisión Moderador Propietario producto 4. Usan listas de comprobación SI NO 5. Errores distribuidos por tipo SI NO 6. Seguimiento para controlar la SI NO corrección 7. Se puede mejorar eficiencia de la revisión (análisis resultados) SI NO Control de la calidad 38 Uso de las actividades de control Objetivos Método principal i Evaluación Verificación Validación Confirmación del cumplimiento Revisión de gestión (del proceso) Revisión técnica Inspección Recorrido (walkthrough) Pruebas (propias del producto) Auditoría 19

20 Control de la calidad 39 Plan de Revisiones &Auditorías (IEEE) Plan de revisiones y auditorías (IEEE) Revisión de requisitos del software, sobre las ERS (con el usuario) Revisión ió del ldiseño preliminar, i corrección técnica del diseño de alto nivel Revisión de diseño crítico sobre diseño detallado, comprobando su ajuste a las ERS Revisión del plan de V&V de software. Comprueban adecuación de métodos. Auditoría funcional: sobre el software justo antes de entregarlo, para verificar que cumple requisitos. Auditoría física: verifican que software y documentación son consistentes y están listos para entregar (junto a pruebas de aceptación) Auditoría durante el desarrollo: verifican consistencia del diseño Revisiones de gestión: periódicas. Comprueban el seguimiento del plan de calidad. Control de la calidad 40 Controles dinámicos: Pruebas Prueba Ejecución de un sistema con el fin de encontrar fallos Diseño de la prueba: Sólo es exitosa si encuentra fallos Depuración Localización del defecto que es la causa del fallo Determinar la forma de corregirlo Evaluar el efecto de la corrección Corrección Coste Detectar cuesta más que corregir 50-60% del esfuerzo en grandes proyectos 20

21 Control de la calidad 41 Modular o Unitaria Tipos de pruebas Objetivo: encontrar errores basándose en la estructura o en las especificaciones De Integración Objetivo: Comprobar las interfaces entre módulos Estrategias: Ascendente o Bottom-up Descendente o Top-down Gran explosión o Big-bang Del Sistema Se satisfacen los requisitos del usuario? De Aceptación Demostración del funcionamiento en su entorno real (pruebas β) Control de la calidad 42 Diseño de pruebas (i) Métodos de caja negra Basadas en las especificaciones de entrada y salida y combinaciones Estrategias Clases de equivalencia Análisis de valores límites Grafos causa-efecto Conjetura de errores 42 21

22 Control de la calidad 43 Diseño de pruebas (ii) Métodos de caja blanca Basadas en cada posible camino en el grafo de flujo de control Estrategias Sentencias Decisiones Condiciones Combinaciones de condiciones Métrica de cobertura del grafo: V(G) Control de la calidad 44 Metodología de las pruebas IEEE std 892 Plan de Pruebas Especificación de diseño de pruebas... Especificación de diseño de pruebas Especificación ió de Especificación ió de casos procedimientos de pruebas de pruebas Ejecución Informes 44 22

23 Calidad del Software 4.3 Objetivos de Estándares de calidad Qué son las ISO Qué aportan a la calidad del software Como ayudan a las organizaciones Qué aportan a los clientes Ventajas e inconvenientes Introducción ISO y

24 47 ISO y