Metodología de Desarrollo de Software en base a MDE con DSL

883 views

Published on

Propuesta de una Metodología de desarrollo de Software rn base a MDE (Ingeniería Dirigida por Modelos) y DSLs (Lenguaje de Domino Específico)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
883
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Metodología de Desarrollo de Software en base a MDE con DSL

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Aspectos que incluye la propuesta de la Metodología Metodología de Desarrollo de Software Dirigida por Modelos 7/33
  13. 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. 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. 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. 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. 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. 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. 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. 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. 21. 4.2 Descripción/Metodología Orientada por Modelos (MOM1) 15/33
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×