2  Calidad del software  Medición del software: necesidad de obtener datos objetivos que ayuden a mejorar la calidad  Creación de modelos de calidad:útiles.

Presentación del tema: "2  Calidad del software  Medición del software: necesidad de obtener datos objetivos que ayuden a mejorar la calidad  Creación de modelos de calidad:útiles."— Transcripción de la presentación:

1

2 2  Calidad del software  Medición del software: necesidad de obtener datos objetivos que ayuden a mejorar la calidad  Creación de modelos de calidad:útiles para discutir, planificar y obtener índices de calidad  Aplicación de estándares de calidad: directrices para el aseguramiento externo e interno de la calidad

3 3  Los siguientes conceptos se han desarrollado tomando como base la experiencia de varias organizaciones  Pradigma para establecer objetivos corporativos y del proyecto y un mecanismo para medir dichos objetivos Paradigma Objetivos/Preguntas/Metricas  Un mecanismo de mejora evolutiva para el software Paradigma Mejora de la Calidad  Un enfoque organizativo para construir competencias de software y suministrarlas a los proyectos Factoría de la experiencia

4 4  Necesitamos “frameworks” de medidas para:  Caracterizar Construir modelos comparativos y líneas base  Entender Analizar modelos  Evaluar Comparar modelos  Predecir Construir modelos predictivos  Motivar Construir modelos prescriptivos

5 5  Modelos de calidad:  Modelo de Boehm [Boehm et al., 1978]  Modelo FCM (Factors/Criteria/Metrics) [McCall et al., 1977]  Marco ISO 9126 [ISO/IEC, 1991]:  Paradigma GQM (Goal-Question-Metric) [Basili y Rombach, 1988]:  Modelo de Gilb [Gilb, 1988]:  Modelo CMM (Capability Maturity Model) [Paulk, 1993]:  Modelo SPICE (Software Process Improvement and Capability determination) [Rout, 1995], [SPICE, 1999]:

6 6  Características de los modelos:  Algunos modelos (FCM, GQM...) incluyen métricas para evaluar diferentes atributos de calidad del producto casi siempre en el nivel del diseño o del código  Los modelos de calidad más recientes (CMM, SPICE) están orientados a la mejora de procesos “Desafortunadamente, organizaciones que cumplen los requisitos CMM o ISO no están produciendo software de calidad” David Cook

7

8 8  Métricas de especificación de requisitos:  Tamaño y funcionalidad: Puntos de función [Albrecht, 1979] Métrica Bang [DeMarco, 1982] Puntos objeto [Boehm et al., 1995]  Calidad Métricas basadas en especificaciones formales [Samson et al., 1990] Calidad de las especificaciones informales en lenguaje natural [Samson y Palmer], [Finkelstein et al.] Métricas de calidad de la documentación [Arthur y Stevens, 1989], [French et al., 1997], [Roth et al., 1994] Listas de comprobación [Brykczynski, 1999] [Farbey, 1990]

9 9  Calidad en sistemas OO  Métricas de diseño: [Chidamber y Kemerer, 1994]  Métricas orientadas a clases [Lorenz y Kidd 1994]  Métricas orientadas a operaciones [Churcher y Shepperd, 1995]  Métricas para pruebas [Binder, 1994]  Métricas de calidad y complejidad en modelos OMT [Genero et al., 1999]  Métricas de calidad de los diagramas de clases en UML [Genero et al., 2000]  Medición de modelos conceptuales basados en eventos [Poels, 2000]

10 10  Calidad en sistemas OO  Características de las métricas: Centradas en el diseño Dirigidas a la medición de la complejidad, reusabilidad, acoplamiento y cohesión Enfocadas en el modelado estructural o estático Las métricas desarrolladas en niveles próximos a la especificación de requisitos del software (ERS) no miden sus atributos de calidad (exceptuando las técnicas formales)

11 11  Atributos de la ERS:  Corrección: validación de requisitos, modelos técnicamente correctos, etc.  Completitud : grado en que los requisitos cumplen las necesidades de los usuarios  Consistencia: ausencia de requisitos contradictorios  Carencia de ambigüedad: un único requisito debe tener una única interpretación (ortogonalidad del lenguaje de especificación)  Trazabilidad: seguimiento de la evolución de los requisitos  Facilidad de comprensión

12 12  Algunas características de la ERS dificultan la aplicación de métricas  Diferentes perspectivas de modelado Es necesario contemplar múltiples notaciones  Evolución Hay que asegurar la consistencia de los cambios  Transformación Se requieren medidas de calidad que valoren la trazabilidad  Abstracción Es difícil medir directamente los atributos de calidad

13 13  Necesidad de Modelos:  Minimizar la complejidad y relatividad inherentes al concepto “calidad del software”  Manejar diferentes perspectivas de modelado  Gestionar la evolución y asegurar la consistencia de los cambios  Crear “Factorías de la experiencia”

14 MPC =  c i M 1, M 2,...,M n P = 1 - (ET/ER)

15 15  El éxito en la medición del software está ligado a la obtención, definición y manipulación conjunta de dos modelos:  Modelos empíricos Contexto empírico del mundo real  Modelos numéricos Formalización de las medidas del contexto empírico

16 16 Modelo empírico Medida Modelo numéricoResultado empírico Interpretación Resultado numérico Matemáticas/ estadística Comprensión/ refinamiento

17 17 ijk Modelo I’J’J’ K’ Modelo’ Metamodelo Meta-metamodelo Modelo de jerarquía genérico que recoge los aspectos evolutivos y/o de transformación de dos modelos

18  GQM (Goal-Question-Metric) es un paradigma para desarrollar y mantener un significativo programa de métricas que ayudan:  Alinear las Métricas con los negocios de la organización y las metas técnicas.  Mejorar el proceso del software  Gerenciar el riesgo  Mejorar la calidad del producto (QIP)

19  Proporciona una manera útil para definir mediciones tanto del proceso como de los resultados de un proyecto. Considera que un programa de medición puede ser mas satisfactorio si es diseñado teniendo en mente las metas (objetivo perseguido).

20  Establecer las Metas: Desarrollar un conjunto de metas corporativas, de la división y del proyecto de negocio que estén asociados a un conjunto de medidas de productividad y calidad.  Generación de Preguntas: Generar las preguntas (basadas en modelos) que definen objetivos de la manera mas completa y cuantificable posible.  Especificación de Medidas: Especificar las medidas necesarias a ser recolectadas para contestar las preguntas y seguir la evolución del proceso y producto con respecto a las metas.  Preparar Recolección de datos: Desarrollar mecanismos para la recolección de datos.  Recolectar, Validar y Analizar los datos para la toma de decisiones: Recoger, validar y analizar los datos en tiempo real, para proporcionar la realimentación de proyectos en una acción correctiva.  Analizar los datos para el logro de los objetivos y el aprendizaje: Analizar los datos una vez alcanzado una meta para determinar el grado de conformidad y hacer las recomendaciones para mejoras futuras.

21  GQM comienza identificando las metas de la medida (nivel conceptual) que están alineadas con las metas del negocio. El equipo (encargados de proyecto, equipo del desarrollo, clientes, Stakeholders) plantea las preguntas (nivel operacional) para clarificar y para refinar más las metas así como captura la variación de la comprensión de las metas que existen entre los Stakeholders con respecto a sus nociones de la calidad y del ambiente que afecten el logro de meta.

22