El documento describe una propuesta de metodología para ingeniería dirigida por modelos (MDE) utilizando lenguajes de dominio específico (DSL). La metodología incluye cuatro etapas: 1) preparación del proyecto mediante el análisis de dominio y conformación del equipo, 2) diseño del DSL, 3) desarrollo de aplicaciones utilizando los artefactos MDE, y 4) mantenimiento y evolución. El objetivo es definir un proceso formal de desarrollo de software basado en MDE y DSL

1. Descripción de las actividades de una propuesta de Metodología para
Ingeniería Dirigida por Modelos (MDE)
Santiago Jácome
Universidad de las Fuerzas
Armadas ESPE -Ecuador

2. Contenido:
1.
2.
3.
4.
5.
6.
Introducción
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
Conclusiones
Referencias

3. Contenido:
1. Introducción
1.1 Evolución del desarrollo de software
1.2 Los modelos en el desarrollo del software
1.3 Características principales de MDE
1.4 Tendencias de MDE
1.5 Problema abordado
1.6 Objetivo
2.
3.
4.
5.
6.
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
Conclusiones
Referencias

4. 1.1 Evolución del desarrollo de software
2000: MDEIngeniería
Dirigida por
Modelos (modelos)
80: Lenguajes OO: C++. Metodologías
de Desarrollo de Software Orientadas
a Objetos (objeto)
70: Lenguajes Estructurados: Pascal, C.
Metodologías de Desarrollo de Software
Estructuradas u Orientadas a Procesos (proceso)
50-60: Lenguajes de Programación:
Fortran, LISP, Cobol.
40: Primeros ordenadores
Ensamblador
1/33

5. 1.2 Los modelos en el desarrollo del software
 El modelado se remonta a los primeros días del desarrollo de software.
 Proporcionan abstracciones de un sistema.
 Pueden ser desarrollados como un precursor del sistema, para:
 “ Visualizar” el sistema antes de construirlo.
 Realizar variaciones para determinar su comportamiento.
 Comunicar las características clave del sistema a las distintas
partes interesadas.
 Pueden ser mapeados a un Lenguajes de Programación de Propósito
General (GPL) para luego ser compilado en una determinada
plataforma.
 Muchas veces los modelos solamente quedan como “documentación”.
2/33

6. 1.3 Características principales de MDE

MDE conecta más estrechamente el modelo a la aplicación.

El modelo no sólo encapsula el diseño de la aplicación sino que se lo utiliza
para generar código de forma automática.

Eleva el nivel de abstracción al desarrollo de software, asignando a los
modelos y las transformaciones entre ellos el rol principal de todo el
proceso de desarrollo.

El desarrollo de software con enfoque MDE involucra dos etapas:
1. Creación de los artefactos MDE por expertos en informática.
2. Desarrollo de aplicaciones específicas con los artefactos MDE por el
usuario final.

Es aplicable a un dominio específico.

Permite la reutilización. Evita codificar las mismas soluciones una y otra vez.
3/33

7. 1.4 Tendencias de MDE
MDA
 Arquitectura Dirigida por Modelos (MDA).
 Apoyada por el Grupo de Administración de Objetos (OMG).
 Utiliza UML como Lenguaje de Modelado de Propósito General.
 No muy adecuada para para modelar toda la complejidad del software
para dominios especializados.
 Los mecanismos de adaptación de UML (perfiles) son a veces demasiado
"pesados" y van muy ligados a herramientas concretas.
DSL
 Apoyada principalmente por la comunidad investigadora.
 Utilización Lenguajes de Dominio Específico (DSLs).
 Es más productivo utilizar un lenguaje que tenga abstracciones más
orientadas a un dominio.
4/33

8. 1.5 Problema abordado
No existe una proceso formal de desarrollo plenamente
definido con enfoque MDE con DSL.
1.6 Objetivo
Realizar una descripción general de las actividades que
conforman una propuesta de metodología de desarrollo de
software basada en Ingeniería Dirigida por Modelos y
Lenguajes de Dominio Específico.
5/33

9. Contenido:
1.
2.
3.
4.
5.
6.
Introducción
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
Conclusiones
Referencias

10. 2. Impacto de MDE en la empresa
 Existen varios casos de utilización en la empresa.
 Alguno consideran que la tecnología aún no es lo suficientemente madura
para utilizarla masivamente.
 El balance costo/beneficio de emplear MDE sería positivo a largo plazo,
tras el desarrollo de un cierto número de proyectos
 Se debe cambiar la forma de pensar de los desarrolladores. No están
acostumbrados a un "meta pensamiento" [Voel13 ].
 La nueva tecnología debe venir acompañada por el desarrollo de una alta
calidad de la literatura, tutoriales y herramientas adecuadas.
 Las empresas pueden ser reacias a cambiar su estructura o parte de ella.
 Falta de apoyo decidido de las grandes empresas de desarrollo de
software.
6/33

11. Contenido:
1. Introducción
2. Impacto de MDE en la Empresa
3. Aspectos que incluye la Metodología
3.1 Enfoque MDE con DSL
3.2 Metodologías de Desarrollo de Software
3.3 Análisis de Dominio
3.4 Desarrollo por el Usuario Final
4. Metodología propuesta
5. Conclusiones
6. Referencias

12. Aspectos que incluye la propuesta de la Metodología
Metodología
de Desarrollo
de Software
Dirigida por
Modelos
7/33

13. Esquema de la relación entre los elementos del enfoque
MDE con DSL [Garc13].
La sintaxis abstracta del
Lenguaje de Metamodelado es un Metameta-modelo
Lenguaje de Metamodelado
definido con
DSL
Meta-modelo
(Sintaxis abstracta)
Notación
(Sintaxis concreta)
Semántica
conforme
a
Aspecto de
un Sistema
representa a
expresado con
Modelo
M2T
M2M
Código
8/33

14. 3.2 Metodologías de Desarrollo de Software
 Una Metodología de Desarrollo de Software es una marco de trabajo
que permite estructurar, planificar y controlar las actividades de un
proyecto de desarrollo con altas posibilidades de éxito.
 La evolución de la gestión de proyectos de software al igual que otras
áreas del conocimiento, sigue un patrón dialéctico basado en los
conceptos formulados por Platón [Pala12].
 Comienza con una etapa que se llama tesis, seguida de una etapa que
la niega llamada antítesis y por último se llega a la etapa final llamada
síntesis.
 La tesis: Gestión Tradicional o Predictiva (metodologías tradicionales)
 La antítesis: Agilidad
 La síntesis: Métodos ágiles de desarrollo
9/33

15. La tesis: Gestión Tradicional o Predictiva
 La tesis o alternativa tradicional fue la primera corriente que buscó dar
solución a los inconvenientes de la denominada “crisis del software”:
 La Gestión de Proyectos Predictiva es una disciplina formal basada en la
planificación, ejecución y seguimiento de las actividades a través de procesos
sistemáticos y repetibles.
La antítesis: Agilidad
 Las empresas deben adoptar nuevos enfoques de gestión de proyectos.
 Se requieren estrategias orientadas a la entrega temprana de resultados
tangibles sin arriesgar la calidad.
 No hay “productos finales” sino productos en evolución.
 La gestión tradicional puede resultar inapropiada en el nuevo entorno social.
 Surge el manifiesto ágil (2001, iniciativa de Kent Beck )
10/33

16. La síntesis: Métodos ágiles de desarrollo
Se aprende de los aciertos y los errores de los dos enfoques de gestión
anteriores.
Términos fundamentales de esta forma de construir software:
 Agilidad: capacidad para producir partes completas del producto
en períodos breves de tiempo.
 Flexibilidad: capacidad para adaptar el curso del desarrollo a las
características del proyecto y a la evolución de los requisitos.
 Fases del desarrollo solapado: el concepto de “fase” que implica
el trabajo secuencial, se cambia ahora por el de “actividad”. Las
cuales pueden realizarse en cualquier momento “a demanda”.
Modelos inscritos en la Agile Allience: AUP (Agile Unified Process),
Crystal, FDD (Feature Driven Development), Scrum (utiliza ciclos iterativos
llamados sprints), XP (eXtreme Programming).
11/33

17. 3.3 Análisis de Dominio
Diseño del DSL:
 "El objetivo del Análisis de Dominio (AD) es la definición de un
modelo de dominio que represente las características comunes
de los sistemas y sus relaciones en un determinado dominio
[Díez09]".
 Útil cuando en el diseño del DSL se pretende representar las
características comunes de un conjunto de sistemas de un
dominio.
Reutilización del software:
 "La clave para la reutilización de software no se encuentra en la
forma de programar el código sino en la correcta especificación
del dominio de aplicación [Neig87]" .
12/33

18. 3.4 Desarrollo por el Usuario Final
 "El Desarrollo por el Usuario Final es el conjunto de actividades que
permiten al usuario final de sistemas de software actuar como
desarrolladores de software [Lieb06]".
 El desarrollo de aplicaciones se ha convertido en una habilidad
técnica de millones de personas (no necesariamente del área
informática).
 Por lo general desarrollan aplicaciones para apoyar sus actividades
laborales.
 Para garantizar la calidad de las aplicaciones se recomienda utilizar
varias técnicas de ingeniería de software aunque sea con los mínimos
niveles de rigurosidad.
13/33

19. Contenido:
1.
2.
3.
4.
Introducción
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
4.1 Directrices para el diseño
4.2 Descripción
4.3 Proceso de desarrollo de aplicaciones con artefactos MDE
5. Conclusiones
6. Referencias

20. 4.1 Directrices para el diseño
1. Basada en el enfoque MDE con DSL.
2. Para crear artefactos que permitan desarrollar aplicaciones
Ligeras y de una Familia de Aplicaciones de Dominio Específico.
3. Lo más simple posible.
4. Utilización de un proceso iterativo-incremental.
5. Comprometer la participación directa del usuario en la creación
de los artefactos MDE.
6. Incluir mecanismos de reutilización de artefactos.
7. Proponer un mecanismo de desarrollo de aplicaciones ligeras
por el Usuario Final con los artefactos MDE creados.
8. Considerar para el ámbito comercial la creación de herramientas
tipo CASE con tecnología MDE para diferentes áreas
profesionales.
14/33

21. 4.2 Descripción/Metodología Orientada por Modelos (MOM1)
15/33

22. ETAPA 1: Preparación del Proyecto
1. Determinación de la Visión del Producto


Establecimiento del primer contacto entre el interesado en contar con un
conjunto de herramientas MDE y la empresa de desarrollo de software.
Permite conocer de forma general la visión y alcance del proyecto.
2. Conformación del Equipo de Desarrollo
 Se encarga del staffing, es decir de la selección y entrenamiento de
personas para que conformen el equipo de desarrollo.
 El equipo de desarrollo debe contar con ciertas capacidades y
conocimientos del entorno MDE.
3. Determinación de Aspectos de Logística
 La finalidad de esta actividad es dar soporte al proyecto con las adecuadas
herramientas, métodos y procesos.
16/33

23. ETAPA 1: Preparación del Proyecto
4. Análisis de Dominio
 Identificar y representar las características de un dominio de sistemas
para establecer un modelo o patrón común que se expresará mediante
un DSL.
 Se generan tres productos: a) Lista de Requisitos del Dominio, b) Modelo
de Características, c) Diagrama de Clases.
 Se pueden utilizar una adaptación de técnicas de diseño de DSL
existentes. Enfoque "tradicional" y entornos colaborativos en base a
ejemplos [Cáno12], Example-Driven Modeling [Bąk13].
 Estos productos justifican su realización como se verá posteriormente
debido a que:
 Permiten obtener una versión preliminar del me-tamodelo.
 Mejora la estimación de las tareas a realizar.
 Si los productos satisfacen al Equipo de Desarrollo, las tareas de esta
actividad pueden ser omitidas y continuar con las demás.
17/33

24. ETAPA 1: Preparación del Proyecto
4. Análisis de Dominio/Productos
2.Modelo de Características (Feature Model)
PROYECTO:
Desarrollo de una cola de simulación para optimizar el proceso de abordaje de pasajeros a un avión.
OBJETIVO: Optimizar el proceso de atención a los pasajeros en el check-in y abordaje.
USUARIOS:
Supervisores de operaciones del terminal.
Personal de gestión del aeropuerto.
Gestores de terminales de la compañía aérea.
Cliente: Aeropuerto de Barajas - Madrid
Experto de Dominio: Carlos Contreras
Administrador del Proyecto: Marco Andrade
LISTA DE REQUISITOS DEL DOMINIO
Id. Descripción de la funcionalidad
Requisitos Funcionales
Señalar si el operador de check-in está atendiendo o no (pueden habe varias colas de
1
atención)
Representar dinámica y gráficamente la llegada de los pasajeros a la cola para
2
realizar el check-in
3 Representar dinámica y gráficamente la atención del operador de check-in
Representar dinámica y gráficamente la llegada del pasajero al kiosco de atención de
4
check-in
5 Registrar equipaje del pasajero
6 Incluir procesos de seguridad de vuelos
Representar dinámica y gráficamente la llegada de los pasajeros a la cola de
7
abordaje del avión
Especificar si el orden de abordaje es por prioridad o por número de asiento
8
asignado
Especificar si el desplazamiento de los pasajeros al avión es por un corredor o
9
mediante el desplazamiento en bus
10 Se deberá señalar la capacidad de pasajeros del avión
Prioridad
Riesgo
alta
alto
alta
alto
alta
alto
alta
alto
alta
alta
Observaciones
alto
medio
alta
alto
media
bajo
media
bajo
alta
bajo
11 Se deberá señalar el número de pasajeros que han abordado
alta
bajo
12 Se indicará el tiempo total de atención a los pasajeros en la cola de check-in
baja
bajo
13 Se indicará el tiempo promedio de atención a los pasajeros en la cola de chek-in
baja
bajo
14 Se indicará el tiempo total de abordaje de todos los pasajeros en el avión
baja
bajo
15 Se indicará el tiempo promedio de atención a los pasajeros en el abordaje del avión
baja
bajo
alta
medio
alta
alto
Requisitos No Funcionales
El sistema debe residir en el servidor del terminal aéreo, donde los operarios podrán
1
acceder a el a través de portátiles o dispositivos móviles.
El sistema no deberá proporcionar a los operarios información confidencial de los
2
pasajeros.
La capacidad será proporcianada de acuerdo al tipo de
avión
* La prioridad y riesgo de los requisitos está ligada a la prioridad y riesgo en la implementación de la funcionalidad
1.Lista de Requisitos del Dominio
3. Diagrama de Clases(versión
inicial del meta-modelo)
18/33

25. ETAPA 2: Sprint
1. Planificar
 Con los productos del Análisis de Dominio (AD) se procura diseñar y
construir una versión definitiva del meta-modelo.
 Se realiza la Reunión de Planificación del Sprint para planificar las
actividades y tareas del sprint. La reunión consta de dos partes.
Primera parte (1-4 horas):
Participantes: Experto del Domino, Equipo de Desarrollo y Administrador del
Proyecto.
Objetivo: Dar a conocer la versión actualizada de los productos del AD.
Segunda parte (1-4 horas):
Participantes: Equipo de Desarrollo y Administrador del Proyecto.
Objetivo: Descomponer, estimar y asignar trabajo .
 MOM1 utiliza Plantillas de Planificación del Sprint predefinidas para
cada iteración (sprint), debido a que las actividades y tareas presentan
prácticamente un patrón similar de ejecución.
19/33

26. ETAPA 2: Sprint
1. Planificar/Plantilla de Planificación del Sprint
PROYECTO:
Cliente: Aeropuerto de Ba ra ja s - Ma drid
Experto de Dominio: Ca rlos Contrera s
Des a rrollo de una cola de s imula ción pa ra
Administrador del Proyecto: Ma rco Andra de
optimiza r el proces o de a borda je de pa s a jeros a un Inicio: Lun 2, Sep. de 2013
a vión.
Fin: Vie 15, Nov. de 2013
Fecha:
PLANIFICACIÓN DEL SPRINT
Tareas pendientes
Horas pendientes
Sprint No: 1
Inicio:
Categoría
Actividad
Metamodelo
Objetivo del Sprint
Fin:
Estimando
Definición de la s intaxis
a bs tra cta del DSL
Editor
Tra ns forma ción
Genera dor
Tareas
Responsable
( ho r as)
Estado
Proveer de funcionalidad inicial básica a los artefactos MDE
1. Revis ión de documentos del Aná lis is de Dominio
2. Refina miento de documentos de Aná lis is de
Dominio (Lis ta de Requis itos del Dominio, Modelo
de Ca ra cterís tica s y Dia gra ma de Cla s es )
3. Selección de los requis itos de ma yor nivel de
priorida d
4. Cons trucción de la primera vers ión del
metamodelo (tendiente a obtener la vers ión
definitiva )
5. Eva lua ción del metamodelo
Definición de la s intaxis
1. Definición de los elementos textua les /grá ficos del
concreta del DSL
DSL
2. Cons trucción del editor
3. Eva lua ción del editor
Prueba de s emá ntica del DSL 4. Utiliza ción del DSL pa ra dis eña r un modelo rea l
bá s ico
Crea ción de meca nis mos de 1. Definición de regla s de tra ns forma ción
tra ns forma ción
2. Des a rrollo del progra ma de tra ns forma ción
3. Ejecución del progra ma en un motor de
tra ns forma ción
4. Eva lución de la tra ns forma ción
Des a rrollo del genera dor de 1. Determina ción del GPL pa ra el cua l genera r código
código
2. Selección del meca nis mo de genera ción de código
3. Des a rrollo del genera dor de código
4. Prueba s de genera ción de código
TOTAL HORAS PLANIFICADAS:
Reuniones Diarias:
Reunión de Revisión de Incremento:
Reunión de Retrospectiva:
Reunión de Planificación de próximo Sprint:
20/33

27. ETAPA 2: Sprint
2. Hacer
 Abarca la implementación de las actividades y tareas especificadas
en la Planificación del Sprint.
 Para el efecto se debe utilizar la infraestructura hardware y software
que permita construir los diferentes artefactos MDE.
 Cada elemento implementado deberá ser probado para verificar que
su funcionamiento esté acorde con lo detallado en el análisis y
diseño.
 Pueda ser que en la implementación de algunos artefactos se entre
en un ciclo iterativo-incremental (mini-sprint) con la actividad de
verificación para determinar el cumplimiento de las tareas.
 Se deben corregir los defectos encontrados lo más pronto posible.
21/33

28. ETAPA 2: Sprint
3. Verificar
 Se considera la revisión de la ejecución de las tareas planificadas en el
sprint a través de Reuniones Diarias de todo el equipo de desarrollo.
 En la Plantilla de la Planificación del Sprint se registra el avance del
desarrollo de los artefactos MDE.
 La plantilla se convierte en una especie de Cuadro de Mando del Proyecto.
 La Reunión diaria se desarrolla al inicio de cada jornada laboral. Realizada
en no más de 20 minutos.
 Cada miembro expone al resto del equipo tres cuestiones:
 Tareas en las que trabajó ayer.
 Tarea o tareas en las que trabajará hoy.
 Si ha tenido algún inconveniente o tiene una necesitar concreta.
22/33

29. ETAPA 2: Sprint
3. Verificar/Cuadro de Mando del Proyecto
PROYECTO:
Sprint No: 1
Inicio: Lunes 9, Sep.
Actividad
Tareas
Metamodelo
Definición de la s intaxis
a bs tra cta del DSL
1. Revis ión de documentos del Aná lis is de Dominio
2. Refina miento de documentos de Aná lis is de
Domio (Lis ta de Requis itos del Dominio, Modelo de
Ca ra cterís tica s y Dia gra ma de Cla s es )
3. Selección de los requis itos de ma yor nivel de
priorida d
4. Cons trucción de la primera vers ión del
metamodelo (tendiente a obtener la vers ión
definitiva )
5. Eva lua ción del metamodelo
Editor
Definición de la s intaxis
concreta del DSL
Prueba de s emá ntica del DSL
Tra ns forma ción
Genera dor
Crea ción de meca nis mos de
tra ns forma ción
Des a rrollo del genera dor de
código
Responsable
1. Definición de los elementos textua les /grá ficos del
DSL
2. Cons trucción del editor
3. Eva lua ción del editor
4. Utiliza ción del DSL pa ra dis eña r un modelo rea l
bá s ico
1. Definición de regla s de tra ns forma ción
2. Des a rrollo del progra ma de tra ns forma ción
3. Ejecución del progra ma en un motor de
tra ns forma ción
4. Eva lución de la tra ns forma ción
1. Determina ción del GPL pa ra el cua l genera r código
2. Selección del meca nis mo de genera ción de código
3. Des a rrollo del genera dor de código
4. Prueba s de genera ción de código
Estimando Estado
( ho r as)
Mie, 25 Sep.
Mar, 24 Sep.
Vie, 20 Sep
Jue, 19 Sep
Lun, 23 Sep.
Mie, 18 Sep.
Proveer de funcionalidad inicial básica a los artefactos MDE
Jos é y Ma ría
2
Completa
2
Jos é y Ma ría
4
Completa
4
Jos é y Ma ría
2
Completa
2
Jos é y Ma ría
20
Completa
Jos é y Ma ría
6
Retra s a da
Ma ría
4
Completa
Ma ría
20
Pendiente
Ma ría
4
Pendiente
Jos é
4
Pendiente
Xa bier
4
Pendiente
Xa vier
18
Xa bier
4
Pendiente
Xa bier
4
Pendiente
Xa bier y Ma ría
Xa bier y Ma ría
Xa bier y Ma ría
Xa bier y Ma ría
2
Pendiente
Pendiente
Pendiente
Pendiente
6
16
4
8
8
4
4
4
4
124
TOTAL HORAS PLANIFICADAS:
Reuniones Diarias: 9H00
12
Objetivo del Sprint
Fin: Martes, 1 Oct.
Categoría
13
94
Mar, 17 Sep
17 14 14 14
124 116 108 100
Lun, 16 Sep.
Tareas pendientes
Horas pendientes
PLANIFICACIÓN DEL SPRINT
Vie, 13 Sep.
Jue, 12 Sep.
Mie, 12 Sep.
Fecha:
Lun, 9 Sep.
Mar, 10 Sep.
Cliente: Aeropuerto de Ba ra ja s - Ma drid
Experto de Dominio: Ca rlos Contrera s
Des a rrollo de una cola de s imula ción pa ra
Administrador del Proyecto: Ma rco Andra de
optimiza r el proces o de a borda je de pa s a jeros a un Inicio: Lun 2, Sep. de 2013
a vión.
Fin: Vie 15, Nov. de 2013
Reunión de Revisión de Incremento:
Martes 1, Oct. - 9Hh00
Reunión de Retrospectiva:
Martes 1, Oct. - 10Hh00
Reunión de Planificación de próximo Sprint:
Miércoles, 2 Oct. - 15H00
23/33

30. ETAPA 2: Sprint
4. Revisar
 Al finalizar cada sprint se realiza la Reunión de Revisión de Incremento,
con una duración máxima de 1 hora.
 El equipo de desarrollo presenta al propietario del producto el incremento
construido en el sprint.
 Permite al Experto de Domino obtener información objetiva del sistema.
 Permite marcar a intervalos regulares el ritmo de construcción de las
herramientas MDE y la trayectoria que va tomando la visión del producto
(hitos de control).
24/33

31. ETAPA 2: Sprint
5. Retrospectiva
 Se realiza una Reunión de Retrospectiva con una duración de 1 a 2
horas. Puede desarrollarse luego de Reunión de Revisión de
Incremento.
 El objetivo de la Reunión Retrospectiva se centra en “cómo” se está
construyendo, “cómo” se está trabajando, con la finalidad de analizar
problemas y aspectos que se pueden mejorar.
 Se discute lo bueno y lo malo que se ha producido en el sprint.
 Se liman asperezas entre los miembros del equipo de trabajo.
 Se provee retroalimentación a todas las personas.
25/33

32. Repositorio de Activos Reutilizables
 La demanda social actual de software acentúan la necesidad de
aprovechar óptimamente el esfuerzo de desarrollo realizado con
anterioridad.
 La finalidad de esta actividad es mantener la integridad de los
artefactos que se crean en el proceso para conformar un repositorio
de reutilización.
 Para lograrlo se requiere de herramientas que apoyen esta labor.
 El proyecto AMOR (Adaptable Model Versioning) desarrolla un
Sistema de Control de Versiones (VCS) para entornos MDE.
26/33

33. Procesos Transversales/Gestión del Proyecto
1. Planificación del Proyecto
 Lo que se espera de la actividad: Elaboración de un plan del
proyecto.
 Lo que se considera MOM1: Planificación de las actividades y
tareas de la creación de una versión completa del conjunto de
artefactos MDE a través en la Plantilla de Planificación del Sprint.
2. Seguimiento y Control del Proyecto
 Lo que se espera de la actividad: Proporcionar un entendimiento
del progreso del proyecto para que puedan tomarse las acciones
correctivas.
 Lo que se considera MOM1: Seguimiento y control de las
actividades en las cuatro reuniones planteadas en la metodología.
27/33

34. Procesos Transversales/Aseguramiento de la Calidad
La calidad de un producto está determinada en gran medida por la calidad del
proceso utilizado para su desarrollarlo (CMMI).
Calidad del Proceso
 MOM1 incorpora tareas de planificación de tareas (Planificación del Sprint),
seguimiento y control del proyecto (Cuadro de Mando), acuerdos con los
proveedores (Reunión de Planificación del Sprint y Reunión de Revisión del
Incremento), mejora continua (Reuniones de Retrospectiva), gestión de la
configuración (Repositorio de Activos Reutilizables), desarrollo de Software
(metodología propuesta)
 Que acercan al proceso de desarrollo a un nivel 2 de CMMI.
Calidad del Producto
 Para garantizar la calidad de los artefactos MDE se tienen varios métodos y
técnicas que podrían emplearse.
 Por ejemplo en [Ma04] se plantea un método cuantitativo para evaluar la
estabilidad y la calidad del diseño de metamodelos en base a una extensión
de los criterios utilizados en UML.
28/33

35. 4.3 Proceso de desarrollo de aplicaciones con artefactos MDE
Con los artefactos MDE creados por expertos en informática. El usuario
final podrá utilizarlos para desarrollar aplicaciones de su área de
conocimiento a través de la un proceso de desarrollo propuesto en este
trabajo.
29/33

36. 4.3 Proceso de desarrollo de aplicaciones con artefactos MDE

La funcionalidad del proceso de desarrollo por el usuario final debe ser
concebida e implementada como actividades complementarias en los
artefactos MDE.

Los artefactos MDE deben incorporar actividades que “obliguen” al
usuario final a realizar tareas básicas de ingeniería de software.

Se propone utilizar un modelo en base a prototipos evolutivos de software.
30/33

37. Contenido:
1.
2.
3.
4.
5.
6.
Introducción
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
Conclusiones
Referencias

38. 5. Conclusiones

Los mecanismos de desarrollo de software van cambiando
permanentemente.

MDE es una nueva disciplina dentro de la ingeniería de software que se
ocupa de la utilización sistemática de modelos para desarrollar software.

Se debe delimitar el ámbito de aplicación de MDE.

Todavía queda camino que recorrer para que los posibles usuarios de
esta tecnología tengan la suficiente confianza como para comenzar a
utilizarla masivamente.

La presente propuesta metodológica aporta con un grano de arena a esta
nueva iniciativa de desarrollo de software. La misma que fue estructurada
tomando en consideración aportes investigativos de varias personas.

MOM1 puede ser utilizada como una guía de soporte y ayuda para las
personas/empresas interesadas en adoptar este enfoque de desarrollo de
software.
31/33

39. Contenido:
1.
2.
3.
4.
5.
6.
Introducción
Impacto de MDE en la Empresa
Aspectos que incluye la Metodología
Metodología propuesta
Conclusiones
Referencias

40. 6. Referencias (principales)
[Cano12] Cánovas, J.,Cabot, J.,López-Fernández, J., Sánchez, J., Guerra, E., de Lara, J. (2012). Engaging End-Users in the Collaborative
Development of Domain-Specific Modelling Languages.
[Garc13] García, M. García, F., Pelechano, V., Vallecillo, A., Vara, J., Vicente-Chicote, C. (2013). Desarrollo de Software Dirigido por Modelos:
Conceptos, Métodos y Herramientas. Ra-Ma.
[Kang90] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., & Peterson, A. S. (1990). Feature-oriented domain analysis (FODA) feasibility study (No.
CMU/SEI-90-TR-21). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.
[Ko11]
Ko, A. J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., ... & Wiedenbeck, S. (2011). The state of the art in end-user
software engineering.ACM Computing Surveys (CSUR), 43(3), 21.
[Kulk05]
Kulkarni, V., & Reddy, S. (2005). Model-driven development of enterprise applications. In UML Modeling Languages and Applications (pp.
118-128). Springer Berlin Heidelberg.
[Libe06]
Lieberman, Henry, Paterno, Fabio, Klann, Markus and Wulf, Volker (2006): End-user development: An emerging paradigm. End User
Development. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction
Series)". Springerpp. 1-8
[Ma04]
Ma, H., Shao, W., Zhang, L., Ma, Z., & Jiang, Y. (2004). Applying OO metrics to assess UML meta-models. In UML 2004 - The Unified Modeling
Language. Modelling Languages and Applications (pp. 12-26). Springer Berlin Heidelberg.
[Moha08] Mohagheghi, P., Dehlen, V. (2008). Where is the Proof? - A Review of Experiences from Applying MDE in Industry. Springer Berlin
Heidelberg. Volume 5095, 2008, pp 432-443.
[Neig87] Neighbors, J. (1987). Report on the Domain Analysis Working Group Session. In Proceedings of the Workshop on Software Reuse. Rocky
Mountain.Institute of Software Engineering. Boulder. CO.
[Pala12]
Palacio, J., Ruata C., (2012). Gestión de Proyectos con Scrum Manager, <URL: http:// www. Scrum manager.net>
[Prie87]
Prieto-Diaz, R. (1987). Domain Analysis for Reusability. In Proceedings of COMPSAC 87:The Eleventh Annual International Computer
Software & Applications Conference, pages 23-29. IEEE Computer Society, Washington, DC.
[Sanc12] Sánchez, J., Cánovas, J., Garcia, J. (2012). Applying Model-Driven Engineering in Small Software Enterprises.
[Take04] Takeuchi, H., & Nonaka, I. (2004). Hitotsubashi on Knowledge Manegement, ISBN 0470820748, John Wiley & Sons.
[Voel13]
Voelter, M. (2013). DSL Engineering - Designing, Implementing and Using Domain-Specific Languages. CreateSpace.
33/33