análisis visual de la modularidad de modelos de procesos de software avimo - ps análisis visual de...

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


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


Introducció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


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


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)


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]


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.


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.



11

Especificación de procesos computacionales



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].


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


MethodPlugin

ProcessWhitMethods

ProcessStructure

ProcessBehavior

MethodContent

ManagedContent

Core

<<merge>><<merge>>

<<merge

>>

<<merge>>

<<merge>>

<<merge>>

<<merge>>

<<merge>>

<<merge>>

<<merge>>


14

Contenido de Método (Method Content)


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).


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



16

Métricas asociadas a modularidad de software


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


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.


Problema Discusión

19

Problema


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?


Problema Discusión

21

Trabajos relacionados


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


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


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


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.


Propuesta AVIMO-PS

26

Enfoque AVIMO - AVISPA


Propuesta AVIMO-PS

27


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.


28


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.


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.


Propuesta AVIMO-PS

30

Propuesta AVIMO-PS

Extensión al Metamodelo de AVISPA


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.


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


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í:


Nivel de cohesión de los paquetes de contenido de método

Propuesta AVIMO-PS



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


En particular, aplicando la formula de la métrica a cada elemento se tiene:


Nivel de acoplamiento en paquetes de contenido de método

35

Propuesta AVIMO-PS


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.


Inestabilidad en paquetes de contenido de método

A es un Paquete Estable A es un Paquete Inestable

36

Propuesta AVIMO-PS


Se produce cuando otro paquete hace uso de alguno de sus elementos (tareas, roles y artefactos).


Acoplamiento Aferente

37

Propuesta AVIMO-PS


En particular, aplicando la fórmula ( )a cada tipo de elemento de proceso se tiene:


Acoplamiento Aferente

38

Propuesta AVIMO-PS


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:


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.


Blueprint de Acoplamiento y Cohesión

40

Propuesta AVIMO-PS



Blueprint de Acoplamiento y Cohesión

Color de los elementos:

Color de los Paquetes:

Color Gris:

41

Visualización en AVIMO


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



Blueprint de Inestabilidad

Enlaces:

Color de los nodos:

43

Prototipo AVIMO-PS


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


Diseño e implementación de AVIMO-PS

Propuesta AVIMO-PS

45

Prototipo AVIMO-PS


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



Propuesta AVIMO-PS

47

Prototipo 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



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



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.


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



52


Contexto del Estudio de Caso

Fuente abierta Fuente cerrada

Sin implementar algún estándar SmallSPL

Basado en CMMI e ISO 9001



53


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



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



55

Ejecución del Estudio de Caso



56

Mediciones del Estudio de Caso

Complejidad:

Comprensión:

Usabilidad:



Efectividad:

57

Resultados del Estudio de Caso



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 Cuantitativos



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 Cuantitativos



Sujeto 1 Sujeto 2 Sujeto 3 Sujeto 4 Promedio1

1.5

2

2.5

3

3.5

4

4.5

5

4Usabilidad


1.5

2

2.5

3

3.5

4

4.5

5

1,6

Complejidad


1.5

2

2.5

3

3.5

4

4.5

5

4.5 Comprensión

60


Problemas Identificados



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


62


Identificación del Patrón Baja Cohesión



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


Patrón Baja Cohesión



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


Patrón de error Baja Cohesión



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


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.



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.



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.



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


70

¿Preguntas?

Análisis Visual de la Modularidad de Modelos de Procesos de Software

AVIMO-PS


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

análisis visual de la modularidad de modelos de procesos de software avimo - ps análisis visual de...

Documents