INTRODUCCION A LA MEDICION
2
1. INTRODUCCIÓN 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
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 objetivosParadigma Objetivos/Preguntas/Metricas Un mecanismo de mejora evolutiva para el softwareParadigma Mejora de la Calidad Un enfoque organizativo para construir competencias de
software y suministrarlas a los proyectosFactoría de la experiencia
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
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
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
2. MEDICIÓN DE ESPECIFICACION
ES DE REQUISITOS
8
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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
2. MEDICIÓN DE ESPECIFICACIONES DE REQUISITOS
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”
3. MEDIDAS BASADAS EN MODELOS
MPC = c i
M1, M2, ...,Mn
P = 1 - (ET/ER)
15
3. MEDIDAS BASADAS EN MODELOS
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 realModelos numéricos
Formalización de las medidas del contexto empírico
16
3. MEDIDAS BASADAS EN MODELOS
Modelo empírico
Medida Modelo numérico
Resultado empírico
Interpretación Resultado numérico
Matemáticas/ estadística
Comprensión/ refinamiento
17
3. MEDIDAS BASADAS EN MODELOS
i j kModelo
I’ 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
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)
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).
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.
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.