Medición de la calidad del software en el ámbito de la especificación de requisitos (página 2)

13 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

14 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 = ? ci M1, M2, …,Mn P = 1 – (ET/ER)

16 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 real Modelos numéricos Formalización de las medidas del contexto empírico

17 3. Medidas basadas en modelos (Gp:) Modelo empírico

Medida (Gp:) Modelo numérico

(Gp:) Resultado empírico

Interpretación (Gp:) Resultado numérico

Matemáticas/ estadística Comprensión/ refinamiento

18 3. Medidas basadas en modelos (Gp:) i (Gp:) j (Gp:) k (Gp:) Modelo (Gp:) I’ (Gp:) J’ (Gp:) K’ (Gp:) Modelo’ (Gp:) Metamodelo (Gp:) Meta-metamodelo

Modelo de jerarquía genérico que recoge los aspectos evolutivos y/o de transformación de dos modelos

4. Arquitectura de gestión de calidad de ERS

20 4. Arquitectura de gestión de calidad de ERS Objetivos: Gestionar conjuntamente la calidad de diferentes perspectivas de modelado Formular directamente objetivos de calidad y planes de medida Proporcionar una base para la automatización de las medidas Mantener registros de información histórica Proporcionar soporte para estudios empíricos y construcción de modelos predictivos

21 Modelos en el ámbito de los requisitos Entorno de aplicación 2 Entorno de aplicación 1 Entorno de desarrollo Meta metamodelo Lenguaje de modelado Modelos Instancias y escenarios Ingeniería de métodos Modelado conceptual Uso Estructura de referencia ISO IRDS (Information Resource Dictionary System) 4. Arquitectura de gestión de calidad de ERS

22 4. Arquitectura de gestión de calidad de ERS Basada en la arquitectura IRDS de cuatro capas : Escenarios e instancias: contiene objetos no instanciables (datos, estados…) Modelos: representa las clases Metamodelos: nivel de lenguajes de modelado que define la estructura de las clases Meta metamodelo: Definición de múltiples lenguajes de modelado

23 4. Arquitectura de gestión de calidad de ERS (Gp:) UML (Gp:) Nombre: UML (Gp:) tipo: gráfico (Gp:) nº de notaciones: 9

(Gp:) CU-0 (Gp:) Aplicación: contabilidad (Gp:) Nivel: contextual

Modelo M2 Metamodelo (Gp:) Casos de uso (Gp:) Diagrama: casos de uso (Gp:) Clasificadores: 2

Modelo Escenario

24 Implementación en un repositorio Construcción de modelos empíricos de entidades medibles Recuperación de modelos y datos para realizar medidas Realización de análisis de datos, presentación e interpretación de resultados Almacenamiento de modelos y resultados para uso futuro Automatización de la recolección de datos y aplicación de métricas 4. Arquitectura de gestión de calidad de ERS

25 4. Arquitectura de gestión de calidad de ERS (Gp:) SGBD (Gp:) ME (Gp:) Aplicación 1 (Gp:) Aplicación n (Gp:) Repositorio CASE (Gp:) Repositorio de gestión de Calidad

5. Conclusiones

27 5. Conclusiones Construir modelos para: ayudar a entender qué estamos haciendo proporcionar una base para definir objetivos proporcionar una base para la medición Construir modelos de: gente, procesos, productos y estudiar sus interrelaciones

28 5. Conclusiones Usar modelos para clasificar el proyecto en curso distinguir los entornos pertinentes del proyecto encontrar tipos de proyectos con características y objetivos similares Los modelos proporcionan un contexto para: Definición de objetivos Objetos/experiencias reutilizables Selección de procesos Evaluación/comparación Prediccion

29 5. Conclusiones El enfoque propuesto proporciona: Un marco para definir modelos de calidad y objetivos específicos del proyecto Un mecanismo para evaluar la calidad en las primeras fases del ciclo de vida Soporte para el registro y uso provechoso de experiencias pasadas Un medio para gestionar la evolución y la consistencia de los cambios

6. referencias

31 6. Referencias Albrecht, A.J., “Measuring application development”, Proc. of IBM Applications DevelopmentJoint SHARE/GUIDE Symposium, Monterey, CA, pp 83-92, 1979. Arthur, J.D. y Stevens, K.T. , “Assessing the adequacy of documentation through document quality indicators”, Proceedings of the IEEE Conference of Software Maintenance, pp. 40-49, 1989. Basili, V.R. y Rombach, H.D., “The TAME Project: Towards Improvement-Oriented Software Environments”, IEEE Transaction on Software Engineering,14(6), 758-73 1988. Basili, V.R. y Weiss, D., “A Methodology for Collecting Valid Software Engineering data”, IEEE Transaction on Software Engineering, 10 (6), 728-38 1984. Binder, R., “Testing Object-Oriented Systems”, American Programmer, 7(4), 22-29, 1994. Boehm, B.W., Kaspar, J.R. y otros “Characteristics of Software Quality”, TRW Series of Software Technology, 1978. Boehm, B.W., Clark, B., Horowitz, E. et al., “Cost Models for future life cycle processes: COCOMO 2.0”, Annals of Software Engineering 1(1), pp 1-24, 1995. Brykczynskki, B., “A survey of software inspection checklist”, ACM Software Engineering Notes, 24(1), pp 82-89, 1999. Chidamber, S.R. y Kemerer, C.F., “A Metrics Suite for Object-Oriented Design” ,IEEE Transactions of Software Engineering, 20(6), 476-493, 1994. Churcher, N.I. and Shepperd, M.J., “Towards Conceptual Framework for Object-Oriented Metrics”, ACM Software Engineering Notes, 20 (2), 67-76, 1995.