4(III) Gestión de la calidad

Presentación del tema: "4(III) Gestión de la calidad"— Transcripción de la presentación:

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 1

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 de la 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 de aseguramiento 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 Factores/Criterios/Métricas
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 Paradigma Objetivo-pregunta-métrica
GQM Paradigma Objetivo-pregunta-métrica 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

17 GQM Ejemplo 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: 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 GILB 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

19 Modelo de Capacidad y Madurez para el desarrollo de Software
CMM Modelo de Capacidad y Madurez para el desarrollo de Software 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

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

21 Áreas Claves de Proceso (KPA)
CMM Áreas Claves de Proceso (KPA) N I V E L 2 Gestión de requisitos Planificación de proyectos Seguimiento y control de proyectos Gestión de proveedores Aseguramiento de la calidad Gestión de la configuración Desarrollo de requisitos Solución Técnica Integración del producto Verificación y validación Desarrollo y mejora de los procesos de la organización Definición de los procesos de la organización Planificación de la formación Gestión de riesgos Análisis y resolución de toma de decisiones 3 N. 4 Gestión cuantitativa de proyectos Mejora de los procesos de la organización Innovación organizacional Análisis y resolución de las causas 5

22 Características del Nivel 1 (Inicial)
CMM Características del Nivel 1 (Inicial) 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

23 Características del Nivel 2 (Repetible)
CMM Características del Nivel 2 (Repetible) 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

24 Características del Nivel 3 (Definido)
CMM Características del Nivel 3 (Definido) 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

25 Características del Nivel 4 (Gestionado)
CMM Características del Nivel 4 (Gestionado) 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 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 Evolución Temporal 1987 -- SEI-87-TR-24 (cuestionario SW-CMM)
Managing the Software Process SW-CMM v0.2 SW-CMM v1.0 SW-CMM v1.1 SW-CMM (Fin de revisiones) CMMI v1.02 CMMI v1.1 CMMI v1.2

27 CMMi Modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software 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

28 Fiabilidad del Software
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 Conjunto de entradas Conjunto de salidas Ee Sistema Se

29 Los fallos 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: Transitorio Ocurre sólo con ciertas entradas Permanente Ocurre con todas las entradas Recuperable El sistema se recupera sin intervención del operador Irrecuperable Se requiere la intervención del operador para recuperar el sistema No corruptor No corrompe el estado del sistema o los datos Corruptor Corrompe el estado del sistema o los datos Se corrigen usando técnicas de pruebas

30 Software Process Improvement and Capability Determination
SPICE Software Process Improvement and Capability Determination 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

31 Arquitectura en dos dimensiones
SPICE Arquitectura en dos dimensiones (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 Incompleto Nivel Realizado Nivel 2 Gestionado Nivel Establecido Nivel Predecible Nivel En optimización Identificador Nombre Tipo Propósito Salidas Notas Componentes

32 Revisiones del software
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