Post on 24-Jan-2016
Análisis Visual de la Modularidad de Modelos de Procesos de Software
AVIMO - PS
Fredy Alberto Cárdenas B Jhonattan Solarte MartinezDirector: PhD. Julio A. Hurtado
Universidad del CaucaFacultad de Ingeniería Electrónica y Telecomunicaciones
Departamento de Sistemas
Proyecto para la obtención del título de Ingeniero de Sistemas
2013
2Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
1. Introducción2. Marco Conceptual3. Problema4. Trabajos Relacionados5. Objetivos6. Propuesta7. Evaluación8. Conclusiones, Limitaciones y Trabajos Futuros
Agenda
3Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Actualmente, las empresas desarrolladoras de software están mejorando o adoptando procesos adecuados a sus necesidades, con el fin de reducir los costos, mejorar la productividad, la gestión y el manejo del tiempo
Introducción
Introducción Motivación
4Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Introducción
Introducción Motivación
Debido al esfuerzo dedicado al proceso, los modelos cobran una vital importancia. Es a través de ellos cómo el proceso se describe y se presenta a los diferentes participantes involucrados
5Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
La visualización de modelos de proceso, se ha mostrado como una alternativa viable y efectiva para el análisis de modelos de procesos.
Introducción
Introducción Motivación
6
El proceso de software
Un conjunto coherente de reglas, políticas, actividades y procedimientos, componentes de software, metodologías y herramientas usadas o creadas específicamente para concebir, desarrollar, instalar y mantener un producto software (A. Fuggetta and A. L. Wolf, Software process: John Wiley & Sons, Inc., 1996)
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Procesos
7
Calidad de producto y calidad de proceso
La calidad de un producto de software está relacionada con que éste satisfaga las necesidades y expectativas razonables del cliente (Pressman, Roger, 2005)
Para tener un proceso de calidad se requiere que en primera medida, esté bien definido y elaborado, y por otra parte que sirva para lo que se especificó en otros términos, que se pueda verificar que se cumplen y satisfacen los objetivos sobre los cuales fue definido (ISO 9126)
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Calidad
8
Modelos de proceso de software
Un modelo de proceso de software es una representación abstracta de la arquitectura, diseño o definición de un proceso de software (K. S. Devesh, et al., 2011.) [38]
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Rol
Actor
Actividad
Producto
Ejecuta
Ejecuta
Compuesta de
Compuesta de
Salidas
Entradas
Introducción Marco conceptual
9
Modelos de referencia de procesos
Los modelos de referencia de procesos software son aquellos que definen cuáles son las mejores prácticas que una organización debe implementar para el desarrollo de software y las características que deben cumplir para obtener un determinado nivel de madurez
Entre los principales modelos se pueden mencionar: CMMI, ISO/IEC 12207 , ISO 9001:2008 , Moprosoft, entre otros, los cuales causan confusión si son interpretados incorrectamente.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Modelos
10
Modelos de evaluación de la capacidad de los procesos de software
Los métodos de evaluación permiten conocer, por medio de la ejecución de la evaluación, la situación actual de la organización, la capacidad de los procesos y con base en estos implementar un modelo de mejora continua. Entre los principales métodos de evaluación se encuentran: ISO/IEC 15504, SCAMPI , EvalProSoft, entre otros.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Modelos
11
Especificación de procesos computacionales
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Modelos
12
Spem 2.0
SPEM 2.0 es un estándar de la OMG que ofrece un marco para la definición de procesos de desarrollo de sistemas y de software, también provee los conceptos necesarios para la definición, descripción, modelamiento y presentación de todos los elementos que los componen [48].
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Rol Producto de Trabajo
Tarea
es responsable de1 0..*
1
0..*
realiza
0..* 0..*
0..* 0..*
usa produce
+entrada +salida
Marco conceptual Especificación de modelos
13
Metamodelo Spem 2.0
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
MethodPlugin
ProcessWhitMethods
ProcessStructure
ProcessBehavior
MethodContent
ManagedContent
Core
<<merge>><<merge>>
<<merge
>>
<<merge>>
<<merge>>
<<merge>>
<<merge>>
<<merge>>
<<merge>>
<<merge>>
Marco conceptual Especificación de modelos
14
Contenido de Método (Method Content)
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
MethodElement
Constraint Section MethodPackage
ContetPackage
DescribableElement
ContentElement
Role Workproduct Task
ContentDescription
Outcome Artifact Deliverable
Premisa de SPEM: Alguien (rol) hace algo (tarea) para obtener algo (producto de trabajo) basándose o ayudándose en algo (guía).
Marco conceptual Modelos
15
Proyecto Eclipse Process Framework Composer
Eclipse Process Framework Composer (EPF Composer) es una plataforma de software gratuita nacida de la iniciativa EPF generada para ingenieros de procesos, jefes de proyecto y directores de programas
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Marco conceptual Especificación de modelos
16
Métricas asociadas a modularidad de software
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Un diseño con bajo acoplamiento y alta cohesión dan lugar a productos más fiables y más fáciles de mantener(D. Poshyvanyk, 2006).
Otra métrica de calidad que se propone en esta tesis, que está relacionada con el cálculo de acoplamiento eferente (hacia afuera) y el acoplamiento aferente (hacia adentro) de un paquete y la relación entre los mismos, que da a lugar a la métrica de inestabilidad de un paquete de contenido de método (Robert Cecil Martin).
Marco conceptual Métricas
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Métricas de modularidad en los modelos de proceso
Marco conceptual Métricas
Dado que “los procesos de software también pueden ser considerados como software” (Osterweil., 1997 ), la modularidad de un modelo de proceso software puede ser obtenida a partir de métricas más específicas como el acoplamiento y la cohesión.
17
18
Problema
Un modelo de proceso difícil de mantener, es un problema significativo para las organizaciones, porque su evolución requiere de un mayor esfuerzo y además los cambios son propensos al error.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Problema Discusión
19
Problema
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
La modificabilidad, es un atributo de calidad que concierne a la capacidad de un producto para ser cambiado con facilidad (P. O. Bengtsson, et al., 2000).
De forma similar al software, la modificabilidad de un proceso, es la capacidad que tiene para adaptarse en el tiempo (cambio del proceso en su evolución a través de ciclos de mejora) y en el espacio de procesos (adaptaciones a contextos específicos)
Problema Discusión
20
Pregunta de Investigación
¿Cómo identificar visualmente si un modelo de proceso de software ha sido modularmente bien definido para facilitar su cambio y evolución?
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Problema Discusión
21
Trabajos relacionados
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Problema Discusión
Autor Propuesta Aplica a Métricas Enfoque Harrison et. al ., 2000Briand et. al., 2001
Modelos de predicción para las tareas de mantenimiento
Modelos de Predicción
No Medición Simple
Marchesi., 2003 y Saeki., 2003
Métricas para los diagramas de casos de uso
Modelo de Producto
UML
Calidad Medición Simple
Genero et. al., 2003 Métricas para los diagramas de clases
Modelo de Producto
UML
Calidad Medición Simple
Miranda et. al., 2005 Métricas para los diagramas de gráficas de estado
Modelo de Producto
UML
Si Medición Simples y
Global
Canfora et. al.,2005 Métricas para medir de manera global un proceso de software
Modelo de Proceso SPEM
1.4
Si Medición Simples y
Global
22
Trabajos relacionados
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Problema Discusión
Autor Propuesta Aplica a Métricas Enfoque Christov y Avrunin.,2009 Técnica formal de
verificación y validación para identificar y medir las diferencias entre los modelos de procesos y las ejecuciones reales
Modelos de proceso
Si Verificación Formal
H. Abdeen, et al., 2011 Métricas Modelo de Producto
Modularidad Medición simple
J Hurtado et.al. ., 2010 Herramienta que construye Blueprints y resalta los patrones de error
Modelos SPEM 2.0
Correctitud del Modelo de
Proceso
Visual
AVIMO-PSCárdenas et al 213
Herramienta que construye Blueprints y resalta los patrones de error de Modularidad
Modelos SPEM 2.0
Modularidad del Modelo de
Proceso
Visual
23
Objetivos
Objetivo General
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Objetivos AVIMO -PS
1
•Analizar visualmente la modularidad de los modelos de proceso SPEM 2.0 construidos con Eclipse Process Framework - EPF.
24
Objetivos AVIMO -PS
Objetivos
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Objetivo Específicos
1
•Definir y diseñar un modelo de métricas y vistas polimétricas para analizar la modularidad de los modelos de proceso.
2
•Desarrollar un prototipo denominado “AVIMO-PS” (Análisis Visual de la Modularidad de Modelos de Procesos de Software), herramienta que extiende a AVISPA, en la cual se implementan métricas de modularidad definidas.
3
•Implementar en el prototipo software, un conjunto de vistas polimétricas que faciliten la visualización de la modularidad del modelo de proceso basado en el modelo de métricas definido.
4
•Evaluar la propuesta usando dos modelos de proceso industriales y dos de código abierto e identificar al menos un patrón problemático asociado a la modularidad.
25
Propuesta
El análisis de procesos basado en la visualización permite a los ingenieros de procesos detectar y analizar problemas de modularidad utilizando su capacidad humana para interpretar las vistas de los modelos de procesos.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Propuesta AVIMO-PS
26
Enfoque AVIMO - AVISPA
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Propuesta AVIMO-PS
27
Introducción Motivación
MOOSE: Plataforma de análisis visual
Moose es una plataforma de código abierto para la expresión de los análisis de los sistemas de software y de los datos en general, su objetivo principal es ayudar a los ingenieros a comprender grandes cantidades de datos, y los sistemas de software en particular.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
28
Introducción Motivación
PHARO: Entorno de programación.
Pharo es un entono de programación de código abierto para el desarrollo de software profesional, con todas las funciones del lenguaje de programación Smalltalk. Pharo es altamente portátil, incluso su máquina virtual está escrita completamente en Smalltalk, por lo que el código fuente es fácil de depurar, analizar y cambiar.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
29
Prototipo
AVIMO-PS es una herramienta basada en Moose que usa modelos SPEM2.0 de manera similar a AVISPA, en la cual los modelos de proceso son importados desde un archivo XML, generados por la herramienta Eclipse Process Framework Composer - EPFC. Sin embargo, AVIMO extiende la capacidad de análisis de AVISPA recuperando desde EPFC la información necesaria para evaluar aspectos de modularidad en los modelos de proceso.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Propuesta AVIMO-PS
30
Propuesta AVIMO-PS
Extensión al Metamodelo de AVISPA
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Propuesta AVIMO-PS
Métricas de modularidad
Lo ideal en los paquetes de contenido de método, es diseñar el proceso de tal manera que sus elementos trabajen conjuntamente para alcanzar un propósito único y bien definido.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Nivel de cohesión de los paquetes de contenido de método
Donde:PRi es número de elementos que cuentan con más relaciones internas que externas.Pi, número total de los elementos.
32
Propuesta AVIMO-PS
Métricas de modularidad
Nuestra propuesta soporta tres maneras de analizar la cohesión de los paquetes de contenido de método, de acuerdo a la relación entre elementos del mismo tipo así:
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Nivel de cohesión de los paquetes de contenido de método
Propuesta AVIMO-PS
Métricas de modularidad
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Acoplamiento Eferente
Grado de dependencia que tienen los elementos en los paquetes del modelo, el cual se calcula utilizando el Acoplamiento eferente (hacia afuera), consultando los elementos sucesores de un elemento i que se encuentran en otro paquete.
34
Propuesta AVIMO-PS
Métricas de modularidad
En particular, aplicando la formula de la métrica a cada elemento se tiene:
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Nivel de acoplamiento en paquetes de contenido de método
35
Propuesta AVIMO-PS
Métricas de modularidad
Resistencia al cambio sin afectar a otros paquetes del Modelo.Estable: Paquete independiente, responsable y útil para la reutilización. Inestable: Paquete dependiente, con mas libertad.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Inestabilidad en paquetes de contenido de método
A es un Paquete Estable A es un Paquete Inestable
36
Propuesta AVIMO-PS
Métricas de modularidad
Se produce cuando otro paquete hace uso de alguno de sus elementos (tareas, roles y artefactos).
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Acoplamiento Aferente
37
Propuesta AVIMO-PS
Métricas de modularidad
En particular, aplicando la fórmula ( )a cada tipo de elemento de proceso se tiene:
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Acoplamiento Aferente
38
Propuesta AVIMO-PS
Métricas de modularidad
La inestabilidad de un paquete es la métrica que enfrenta al acoplamiento eferente y el acoplamiento aferente a través de la siguiente fórmula:
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Inestabilidad en paquetes de contenido de método
39
Propuesta AVIMO-PS
Blueprints de modelos de proceso
El Blueprint de Acoplamiento y Cohesión, tiene tres enfoques, según el tipo de elemento: Roles: Muestra el proceso enfocado desde los roles que participan en él. Tareas: Permite visualizar el proceso de desarrollo desde la perspectiva de las tareas que se realizan durante su ejecución.Artefactos: Muestra el proceso de desarrollo desde el enfoque de los productos de trabajo que se generan en él.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Blueprint de Acoplamiento y Cohesión
40
Propuesta AVIMO-PS
Blueprints de modelos de proceso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Blueprint de Acoplamiento y Cohesión
Color de los elementos:
Color de los Paquetes:
Color Gris:
41
Visualización en AVIMO
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
El Blueprint de Acoplamiento y Cohesión se puede generar, dependiendo del tipo de elemento: Rol, Tarea y Artefacto. La Figura es un Blueprint de acoplamiento y cohesión, del modelo de proceso de software OpenUp, enfatizando en las tareas.
Propuesta AVIMO-PS
42
Propuesta AVIMO-PS
Blueprints de modelos de proceso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Blueprint de Inestabilidad
Enlaces:
Color de los nodos:
43
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Diseño e implementación de AVIMO-PS
AVIMO-PS es una extensión de la herramienta AVISPA, por lo tanto hereda sus características básicas y arquitectónicas, combinando la meta-modelización y técnicas de visualización.
Propuesta AVIMO-PS
44
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Diseño e implementación de AVIMO-PS
Propuesta AVIMO-PS
45
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Arquitectura AVIMO-PS
Propuesta AVIMO-PS
<<System>>
AVIMO-PS
<<uses>> <<uses>>
<<uses>>
AVIMO-PS UI
AVIMO-PS MODEL
AVIMO-PS IMPORTER
MOOSE
46
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Arquitectura AVIMO-PS
Propuesta AVIMO-PS
47
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Arquitectura AVIMO-PS
Propuesta AVIMO-PS
5: fromXMLDescription(xmlElement)
<<create>>4: PMMethodPackage
8.1: computeMetrics()
7.1: resolveReferences()
10: addModel(pmModel)
9: insall()
8: computeMetrics()
7: resolveReferences()
<<create>>6: PMModel(myMethodPackage)
3: pmModel:= importXMLDocument(document)
2: execute()
1: import()
Ingeniero de Proceso
:ProcessModel ImporterCommand
:ProcessModel Importer pmModel:PMModel myMethodPackage:PMMethodPackage
5: fromXMLDescription(xmlElement)
<<create>>4: PMMethodPackage
8.1: computeMetrics()
7.1: resolveReferences()
10: addModel(pmModel)
9: insall()
8: computeMetrics()
7: resolveReferences()
<<create>>6: PMModel(myMethodPackage)
3: pmModel:= importXMLDocument(document)
2: execute()
1: import()
48
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Arquitectura AVIMO-PS
Propuesta AVIMO-PS
ProcessModelImporter>> importXMLDocument (XML document)1. contentElements := document // #ContentElement.2. methodPackage := document // #MethodPackage.3. tasks := contentElements select: 4. [:el | ((el attributeAt: #xsi:type) = 'uma:Task' ) ].5. pmTasks := tasks collect: 6. [:xmlElement | PMTask fromXMLDescription: xmlElement].7. roles := contentElements select: 8. [:el | ((el attributeAt: #xsi:type) = 'uma:Role' ) ].9. pmRoles := roles collect: 10. [:xmlElement | PMRole fromXMLDescription: xmlElement].11. artifacts := contentElements select: 12. [:el | ((el attributeAt: #xsi:type) ='uma:Artifact' ) ].13. pmArtifacts := artifacts collect: 14. [:xmlElement | PMArtifact fromXMLDescription: xmlElement].15. methodPackages := methodPackage select: 16. [:el | (el attributeAt: #xsi:type) = 'uma:ContentPackage' ].17. pmMethodPackage := methodPackages collect: 18. [:xmlElement | PMMethodPackage 19. fromXMLDescription: xmlElement].
20. pmModel := PMModel new21. tasks: pmTasks; 22. roles: pmRoles;23. artifacts: pmArtifacts;24. methodPackages: pmMethodPackage.
49
Prototipo AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Arquitectura AVIMO-PS
Propuesta AVIMO-PS
4: shape()
3: viewTasksCohesionCouplingOn()
2: <<create>>
6.1: interaction(objMethodPackage)
6*[pos=0;pos<Count;pos++]: objMethodPackage:= myMethodPackages(pos)
5: nodes(myMethodPackages)
6.2: shape()
1: viewTasksCohesionCoupling()
6.3: nodes(objMethodPackage.tasks)
6.6: gridLayout()
7: gridLayout()
6.4: shape()6.5: edges(objMethodPackage)
Ingeniero de Proceso
methodPackageGroup:PMMethodPackageGroup view:MOViewRenderer
<<Colección>>
myMethodPackages:PMMethodPackage
[myMethodPackages]
loop
4: shape()
3: viewTasksCohesionCouplingOn()
2: <<create>>
6.1: interaction(objMethodPackage)
6*[pos=0;pos<Count;pos++]: objMethodPackage:= myMethodPackages(pos)
5: nodes(myMethodPackages)
6.2: shape()
1: viewTasksCohesionCoupling()
6.3: nodes(objMethodPackage.tasks)
6.6: gridLayout()
7: gridLayout()
6.4: shape()6.5: edges(objMethodPackage)
50
Evaluación Estudio de Caso
Objetivo del Estudio de Caso
Objetivo
Evaluar AVIMO-PS a través del análisis cuatro modelos de proceso, estudiando los resultados con cuatro ingenieros de sistemas, y con ello identificar al menos un patrón problemático asociado a la modularidad.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
51
Diseño del Estudio de Caso
Selección del Estudio de Caso
•Disponibilidad de los procesos en EPFC
•Disponibilidad de los ingenieros de procesos
•Revelatorio
•Típico
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
52
Diseño del Estudio de Caso
Contexto del Estudio de Caso
Fuente abierta Fuente cerrada
Sin implementar algún estándar SmallSPL
Basado en CMMI e ISO 9001
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
53
Diseño del Estudio de Caso
Sujeto de Investigación
Modelo de proceso de software
Cantidad de
Paquetes
Cantidad de Elementos
Total Tareas Roles Artefactos
Sujeto 1 Tutelkan 26 264 180 22 62
Sujeto 2 Rhiscom 7 83 36 10 37
Sujeto 3 Small SPL 3 181 100 17 64
Sujeto 4 Amisoft 20 198 198 23 91
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
54
Métricas del Estudio de Caso
Indicadores Mediciones Instrumentos
Efectividad Porcentaje de errores reales respecto los errores detectados.
•AVIMO-PS, EPFC•Reporte de Errores
Complejidad Complejidad percibida por los Ingenieros de Procesos con respecto a AVIMO-PS.
•Encuesta•Protocolo de Observación
Comprensión Nivel de comprensión obtenido por los ingenieros de procesos con respecto a AVIMO-PS.
•Encuesta•Protocolo de Observación
Usabilidad Usabilidad de la herramienta (Blueprints) de acuerdo la experiencia de los Ingenieros de Procesos con otras tecnologías de modelado.
•Test de Usabilidad
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
55
Ejecución del Estudio de Caso
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
56
Mediciones del Estudio de Caso
Complejidad:
Comprensión:
Usabilidad:
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Efectividad:
57
Resultados del Estudio de Caso
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Resultados Cualitativos
•Tener los paquetes de contenido de método de manera gráfica y simplificado, facilita la comprensión y el análisis.
•Si se carga un proceso más complejo, el Blueprint generado sería más pesado visualmente.
•Representar el acoplamiento, cohesión e inestabilidad de una manera gráfica es más fácil de interpretar.
•Con una corta capacitación, los sujetos de investigación tuvieron una buena aceptación de la herramienta.
58
Resultados del Estudio de Caso
Resultados Cuantitativos
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Sujeto 1 (Tutelkan)
Sujeto 2 (Rhiscom)
Sujeto 3 (Small SPL)
Sujeto 4 (Amisoft)
Total
Número de posibles anomalías encontradas
13 5 1 10 29
Numero Anomalías efectivas encontradas
11 4 1 9 25
Efectividad de la herramienta
84,6% 80% 100% 90% 88,65%
59
Resultados del Estudio de Caso
Resultados Cuantitativos
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Sujeto 1 Sujeto 2 Sujeto 3 Sujeto 4 Promedio1
1.5
2
2.5
3
3.5
4
4.5
5
4Usabilidad
Sujeto 1 Sujeto 2 Sujeto 3 Sujeto 4 Promedio1
1.5
2
2.5
3
3.5
4
4.5
5
1,6
Complejidad
Sujeto 1 Sujeto 2 Sujeto 3 Sujeto 4 Promedio1
1.5
2
2.5
3
3.5
4
4.5
5
4.5 Comprensión
60
Resultados del Estudio de Caso
Problemas Identificados
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Blueprint Problema Identificado Cantidad de veces
encontrado
Acoplamiento y Cohesión
Paquetes con baja cohesión, paquetes con alto acoplamiento, paquetes con elementos sin relaciones internas.
16
Inestabilidad Paquetes Inestables, elementos con alto acoplamiento hacia otros paquetes.
9
Paquetes Aislados
Paquetes aislados, sin ningún tipo de interacción con los demás paquetes del modelo de proceso.
4
61
Resultados del Estudio de CasoEvaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
62
Resultados del Estudio de Caso
Identificación del Patrón Baja Cohesión
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Modelo de proceso
Paquete de contenido de método Cohesión Estado
Tutelkan Gestión de Riesgos 0.13 Comprobado Tutelkan Desarrollo de Requerimientos 0.13 Comprobado Amisoft Desarrollo de requerimientos 0.18 Comprobado Tutelkan Análisis y Diseño 0.18 Comprobado Tutelkan Medición y Análisis 0.33 Comprobado Tutelkan Planificación del proyecto 0.38 Comprobado Tutelkan Pruebas 0.43 Comprobado Amisoft Planificación del Proyecto 0.46 Comprobado Amisoft Solución técnica 0.61 Falso positivoRishcom Comercial 0.67 Falso positivoAmisoft Procesos Amisoft 0.7 Falso positivoRishcom Implementación 0.71 Falso positivo
63
Resultados del Estudio de Caso
Patrón Baja Cohesión
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Cohesión Baja, si la cohesión <= 0.46
Cohesión Media, si la cohesión > 0.46 y <= 0.71
Cohesión Alta, si la cohesión > 0.71
Comprobado Falso positivo Sin Problemas
0,13 0,13 0,18 0,18 0,33 0,38 0,43 0,46 0,61 0,67 0,7 0,71 >
64
Resultados del Estudio de Caso
Patrón de error Baja Cohesión
Evaluación Estudio de Caso
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
65
Conclusiones
Conclusión General
AVIMO-PS es un prototipo software que explota el poder de la visualización, ayudando a entender, diseñar, y determinar la inestabilidad, acoplamiento y cohesión de los modelos de proceso de software.
Conclusiones, Limitaciones y Trabajos Futuros Conclusiones
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
66
Conclusiones
•Este proyecto adapta varias métricas de acoplamiento y cohesión de la ingeniería de software al dominio de procesos de software.
•AVIMO-PS ayuda a mejorar los aspectos de modificabilidad, aportando a la compresibilidad, y mantenibilidad, dando soporte para evoluciones futuras de los modelos de procesos de software.
•AVIMO-PS permite a los ingenieros de procesos detectar problemas y lograr analizar datos en modelos de manera temprana.
•La visualización puede aplicarse en un gran dominio, tanto de procesos, como de producto de software. Ayudando a fortalecer la competitividad de la industria.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Conclusiones, Limitaciones y Trabajos Futuros Conclusiones
67
Limitaciones
•El prototipo AVIMO-PS está dirigido solo a los modelos de procesos de software especificados formalmente en SPEM2.0.
•Los modelos de procesos de software deben de estar estructurados en paquetes de contenido de método.
•Solo se logró detectar un patrón de error, por ello falta mas experimentación y recopilación de datos, con mas modelos y mas sujetos de investigación.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Conclusiones, Limitaciones y Trabajos Futuros Conclusiones
68
Trabajos Futuros
•Adaptar nuevas métricas.
•Incluir nuevos elementos de contenido de método, para ser
procesados.
•Continuar validando las métricas con nuevos estudios de caso.
•Definir nuevos patrones de errores.
•Mejorar la herramienta en cuanto a la usabilidad.
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Conclusiones, Limitaciones y Trabajos Futuros Conclusiones
69
Resultados
•Métricas asociadas a la cohesión y acoplamiento de paquetes
de contenido de método.
•Prototipo AVIMO-PS (Análisis Visual de la Modularidad de
Modelos de Procesos de Software).
•Patrón de Baja Cohesión
•Artículo: Análisis Visual de la Modularidad de Modelos de
Procesos de Software, aceptado a 8CCC.
•Evidencia de la evaluación realizada a AVIMO-PS, a través del
estudio de caso.Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Conclusiones, Limitaciones y Trabajos Futuros Conclusiones
70
¿Preguntas?
Análisis Visual de la Modularidad de Modelos de Procesos de Software
AVIMO-PS
Fredy, Jhonattan (Universidad del Cauca) AVIMO-PS Junio 2013
Fredy Alberto Cárdenas Bolaños, Jhonattan Solarte MartínezDirector: PhD. Julio A. Hurtado
Universidad del CaucaFacultad de Ingeniería Electrónica y Telecomunicaciones
Departamento de Sistemas