4(III) Gestión de la calidad

1. 4(III) Gestión de la calidad AUTORES: Carlos López Bénézét Jesús Mata Camacho Julio Fuertes Vázquez Manuel Carlos Camacho Sousa

2. Concepto de calidad Definiciones de calidad: • Propiedad o conjunto de propiedades inherentes a una cosa, que permiten apreciarla como igual, mejor o peor que las restantes de su especie • Totalidad de las características de un producto o servicio que le confieren su aptitud para satisfaces sus necesidades expresadas o implícitas • La consecución de la calidad puede tener tres orígenes: • Calidad realizada • Calidad programada • Calidad necesaria

3. Definición de la calidad del software • Grado con el que un sistema, componente o proceso cumple: • Los requisitos especificados • Las necesidades o expectativas del cliente o usuario • Los requisitos establecidos explícitamente se reflejan en el documento de especificación de requisitos del sistema: • Requisitos funcionales • Requisitos no funcionales o extendidos • Los estándares y las normas de desarrollo permiten que se consiga una calidad técnica • Los requisitos implícitos no aparecen en la ERS

4. Aspectos de las gestión de calidad • Gestión de la calidad del software • Garantía de la calidad del software • Control de calidad del software • Verificación y validación

5. Ámbitos de la gestión de calidad El trabajo para la mejora de la calidad tiene dos ámbitos de actuación: • Nivel de empresa / organización • Nivel de proyecto

6. Calidad a nivel dela organización Para la implantación de una infraestructura de calidad es necesario el apoyo de un sistema de calidad El sistema de calidad se debe adecuar a los objetivos de calidad de la empresa Dicho sistema consta de dos partes: • Documentación • Parte practica

7. Calidad a nivel de proyecto Para marcar las directrices marcadas por los sistemas de calida a cada proyecto particular hay que generar un plan especifico de calidad: Plan de aseguramiento de la calidad, y debe contener: • Objetivos de calidad del proyecto y enfoque para su consecución • Documentación referenciada en el plan • Gestión de aseguramiento de la calidad • Documentación de desarrollo y de control o gestión • Estándares, normas y practicas que hay que cumplir • Actividades de revisión y auditoria • Gestión de la configuración del software • Informes de problemas • Herramientas, técnicas y métodos de apoyo • Control del código, de los equipos y de los suministros • Recogida, mantenimiento y almacenamiento de datos sobre la documentación de las actividades de aseguramiento de la calidad realizadas

8. Estándares ISO 9000 Se pueden dividir en dos grupos: • Normas para el asesoramiento externo de la calidad: • ISO 9001 • ISO 9002 • ISO 9003 • Gestión interna de la calidad: • ISO 9004

9. Estándares ISO 9000:2000 • ISO 9000:2000 : Fundamentos • Define los términos fundamentales de la familia ISO 9000:2000 • ISO 9001:2000 : Requisitos • Permite realizar certificaciones externas de la calidad, mediante cuatro áreas fundamentales, que son responsabilidad en la gestión, gestión de recursos, realización de productos y servicios y medición, análisis y mejora • ISO 9004:2000 : Mejora • Describe como sería un sistema de control de calidad acorde con las normas 9001, y sirve como guía tras la implantación de 9001 • ISO/IEC 90003:2004 • Conjunto de directrices para la aplicación de las normas ISO 9001 a un determinado software, ya sea adquirido o desarrollado internamente

10. Estándares IEEE • Se trata de una serie de estándares orientados al aseguramiento de la calidad a nivel de proyecto

11. Actividades deaseguramiento de calidad • Establecimiento y revisión del mismo por parte de todas las partes involucradas • Revisión de la descripción del proceso (Se ajusta a la política de la empresa y al cumplimiento de estándares internos y externos) • Revisión de las actividades IS y productos (Se hace un seguimiento de las desviaciones y se verifica la realización de correcciones) • Aseguramiento de la documentación de desviaciones • Registrar aquello que no cumpla los requisitos • Control y gestión de cambios (Se establecen una serie de configuraciones de referencia que permiten controlar y gestionar los cambios en el software) • Recopilación y análisis de métricas

12. Modelos de calidad Gilb Iso 9126 BOEHM Factores/Criterios/Métricas CMM

13. BOEHM Divide la calidas en tres características: usos principales, componentes intermedios y componentes primitivos

14. Factores / Criterios / Métricas • Divide la calidad en tres partes: Operación, Revisión y Transición • Divide cada una de las partes en factores • Divide los factores en criterios • Se aplican una serie de métricas a estos criterios

15. ISO 9126 Descompone la calidad en seis factores: • Funcionalidades • Fiabilidad • Usabilidad • Eficiencia • Mantenibilidad • Portabilidad

16. GQM • Basa la mejora en la definición clara de procesos y productos • Proporciona la estructura para obtener los objetivos cruciales del proyecto • Consta de tres etapas: • Determinar los objetivos principales del desarrollo y mantenimiento del proyecto • Obtener las preguntas que se deben contestar para saber si se cumplen los objetivos anteriores • Decidir qué es lo que se debe medir para contestar las preguntas de forma adecuada Paradigma Objetivo-pregunta-métrica

17. GQM OBJETIVO: Evaluar la efectividad del estándar de codificación ¿Quién está usando el estándar? ¿Cuál es la productividad del codificador? ¿Cuál es la calidad del código? PREGUNTAS: Ejemplo Proporción de codificadores usando: El Estándar El Lenguaje Experiencia de codificadores en: El Estándar El Lenguaje El Entorno… Errores… Cantidad de código

18. Consiste en determinar una lista de características que definen la calidad de la aplicación, pudiendo ser de dos tipos: • Originales • De los modelos tradicionales • Asociado con la filosofía QFD (Quality Function Deployment), para la gestión de la calidad industrial • El proyecto COQUAMO (Constructive Quality Model) se apoya en el enfoque de Gilb • Cada característica se medirá según métricas detalladas GILB

19. CMM • Diseñado a finales de los ochenta por el SEI (Software Engineering Institute) • Surgió a petición del Departamento de Defensa Norteamericano • Evalúa la calidad de las empresas suministradoras de software a través de cinco niveles de madurez, en función de: • Procesos empleados en el desarrollo y mantenimiento del software • Grados de capacidad e institucionalización de cada uno • Posee dos finalidades: • Criterio para la evaluación de la madurez de la organización • Guía para la mejora de sus procesos • Hoy es un modelo obsoleto que SEI relevó e integró en el CMMi en 2000 Modelo de Capacidad y Madurez para el desarrollo de Software

20. CMM Nivel 1 Inicial Incremento de calidad Nivel 2 Repetible Niveles de madurez Nivel 3 Definido Nivel 4 Gestionado Nivel 5 Optimizado

21. CMM Áreas Claves de Proceso (KPA)

22. CMM • Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software • Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación • El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal • A menudo se producen fracasos y casi siempre retrasos y sobrecostes • El resultado de los proyectos es impredecible Características del Nivel 1 (Inicial)

23. CMM • Las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos • Existen unas métricas básicas y un razonable seguimiento de la calidad • La relación con subcontratistas y clientes está gestionada sistemáticamente Características del Nivel 2 (Repetible)

24. CMM • Correctos procedimientos de coordinación entre grupos • Buena formación del personal • Técnicas de ingeniería más detalladas • Nivel más avanzado de métricas en los procesos • Se implementan técnicas de revisión por pares Características del Nivel 3 (Definido)

25. CMM • Conjunto de métricas significativas de calidad y productividad, usados de modo sistemático para la toma de decisiones y la gestión de riesgos • Software resultante de alta calidad Características del Nivel 4 (Gestionado) Características del Nivel 5 (Optimizado) • La organización completa está volcada en la mejora continua de los procesos • Uso intensivo de las métricas y gestión del proceso de innovación

26. CMM • 1987 -- SEI-87-TR-24 (cuestionario SW-CMM) • 1989 ----- Managing the Software Process • 1990 --------- SW-CMM v0.2 • 1991 ------------- SW-CMM v1.0 • 1993 ----------------- SW-CMM v1.1 • 1997 --------------------- SW-CMM (Fin de revisiones) • 2000 ------------------------- CMMI v1.02 • 2002 ----------------------------- CMMI v1.1 • 2006 --------------------------------- CMMI v1.2 Evolución Temporal

27. CMMi • Evolución natural de varios modelos de calidad desarrollados por el SEI durante los 90, como eran: CMM-SW, SE-CMM y IPD-CMM • Es posible implementarlo siguiendo una de las dos posibles representaciones: • Continua Al estilo del SE-CMM • Escalonada Al estilo del CMM-SW Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software

28. La fiabilidad es la característica dinámica más importante de casi todos los sistemas software • Una mayor fiabilidad aporta un menor número de fallos en el programa y arrastra un mayor coste de desarrollo en dicha aplicación Fiabilidad del Software Conjunto de entradas Conjunto de salidas Ee Sistema Se

29. Se pueden producir por defectos en el código, en el diseño, en el análisis e incluso también durante el mantenimiento • Tipos de fallos: Los fallos • Se corrigen usando técnicas de pruebas

30. SPICE • Aprobado en 1998, denominándose ISO/IEC TR 15504 • Se utiliza para la mejora de procesos y determinación de la capacidad • Establece un marco para métodos de evaluación, no es un método o modelo en sí • Posee equivalencia y compatibilidad con CMMi • Comprende: • Evaluación de procesos • Mejora de procesos • Determinación de capacidad Software Process Improvement and Capability Determination

31. SPICE (1) PROCESO • Procesos primarios: CUS: Cliente - Proveedor ENG: Ingeniería • Procesos de soporte: SUP: Soporte • Procesos organizacionales: MAN: Gestión ORG: Organización (2) CAPACIDAD DE PROCESO Nivel 0 Incompleto Nivel 1 Realizado Nivel 2 Gestionado Nivel 3 Establecido Nivel 4 Predecible Nivel 5 En optimización Arquitectura en dos dimensiones Identificador Nombre Tipo Propósito Salidas Notas Componentes

32. Revisiones delsoftware Técnicas estáticas que se aplican en varios momentos del desarrollo y que detectan defectos para así eliminarlos Tipos de Revisión (IEEE 1028) • De gestión • Técnicas • Inspecciones • Walkthrough • Auditorias

33. Auditorias • Revisiones dirigidas a evitar el fraude o mal uso de las aplicaciones informáticas • Misión del auditor -> diseñar y promover la inclusión de los controles que ha de llevar el nuevo sistema (garantizando su integridad) • Medidas de control: • Sobre datos • Operatividad • Relativas al plan

34. Métricas de calidad • Basadas en atributos internos: • De Estructuración de un programa • De complejidad • De cobertura de pruebas • De calidad del diseño • Basadas en atributos externos: • De portabilidad • De defectos • De usabilidad • De mantenibilidad • De fiabilidad • Basadas en sistemas orientados a objetos: • Orientadas a clases • Orientadas a operaciones • Orientadas a objetos

35. Métricas de Cobertura de Pruebas • Objetivo -> comprobar el esfuerzo y rigor en la realización de las pruebas • Caso de prueba se define como el par (i,S(i)) siendo i una entrada del programa y S una especificación. • Existen dos categorías: • Pruebas de caja negra: Se derivan de la especificación, sin conocer la estructura interna del programa • Pruebas de caja blanca: Se conoce la estructura interna del programa. Tipos: • De sentencias (cada sentencia se ejecuta al menos una vez) • De ramas (cada rama se ejecuta una vez) • De caminos (todos los caminos al menos una vez) • Prueba del camino simple (todos los caminos simples) • Prueba estructurada (todos los caminos linealmente independientes)

36. EJEMPLO Métricas de Cobertura de Pruebas

37. Métricas asociadas con las estrategias de prueba • Numero mínimo de casos de prueba - Determina el número mínimo de casos que hay que generar para un programa - Número mínimo de caminos de un grafo de flujo que se requieren para satisfacer una estrategia • Índice de efectividad de las pruebas - Medida del grado en que los casos de prueba satisfacen una estrategia particular para un programa - Se expresa mediante el TER - TER = nT/nO - Siendo nT el número de objetos probados alguna vez y nO el número total de objetos