Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software"

Transcripción

1 Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software Orlando Avila-García, Antonio Estévez García, E. Victor Sánchez Rebull José Luis Roda García Open Canarias, S.L. Universidad de La Laguna Santa Cruz de Tenerife Santa Cruz de Tenerife España España Resumen Existen tres modelos de adopción/creación de líneas de producto de software: proactivo, extractivo y reactivo. Mientras los dos primeros pueden implicar costes y tiempo de adopción prohibitivos, el tercero plantea una alternativa con menos costes de adopción, lo que se denomina una transición poco invasica hacia la ingeniería basada en líneas de producto. En este artículo proponemos un método reactivo, basado en la combinación de activos reutilizables y procesos de software. Nuestro método permite la automatización progresiva y distribuida de las tareas de un proceso de software hasta llegar a su completa automatización. 1. Introducción La celebración en 1968 de la conferencia NA- TO sobre Ingeniería del Software marca el nacimiento de dicha disciplina [19]. La principal motivación para su celebración fue la creciente necesidad de producir sistemas de software más grandes, complejos y ables, de una manera más controlada y eciente. Con ello se afrontaba lo que se denominó entonces la crisis del software, la imposibilidad de las tecnologías de software de aquella época para satisfacer las demandas de la industria. En dicha conferencia se trataron temas de diseño, producción, precio, y servicios asociados al software. En el debate abierto sobre la producción de software surgieron dos ideas reveladores: la propuesta por R. W. Bremer, sobre la necesidad de utilizar entornos de producción controlados por maquinaria, lo que fue llamado por primera vez factoría de software [4], y la presentada por M. D. McIlroy, sobre las grandes ventajas que ofrece la creación y ensamblaje de componentes reutilizables [18]. Estas ideas son el exponente de dos importantes principios de factoría: automatización y reutilización, respectivamente. Es importante considerar que desde el principio se tuvo en cuenta que, en el caso del software, no usamos estos principios para producir en masa réplicas exactas de un mismo producto (problema que no existe en el caso del software), sino productos similares o variantes de un mismo producto a bajo coste y en menos tiempo [18]. Numerosas aproximaciones han venido ofreciendo aportaciones sobre estos y otros principios complementarios de factoría aplicados al software [8]. Uno de las aproximaciones más importantes lleva el nombre de Líneas de Producto de Software [7], paradigma enriquecido en los últimos años por la Ingeniería Dirigida por Modelos [24]. Esta aproximación se basa en la idea de producir familias (o variantes similares) de productos de software a partir de un conjunto de activos reutilizables (denomi-

2 nados assets) de una forma prescrita. Desarrollar un producto de la línea es más una cuestión de ensamblaje y conguración de activos que de creación. Para cada línea de producto debe haber una guía predenida o plan de producción que especica el proceso exacto de obtención de cada producto. Esta aproximación ofrece así tecnologías para llevar a cabo reutilización y automatización en los procesos de software. La dicotomía entre ingeniería de dominio e ingeniería de aplicación es esencial en la aproximación de Líneas de Producto de Software [7]; es más, es la base de cualquier intento de reutilización y automatización en procesos de software [10]. Mientras en la ingeniería de dominio creamos un conjunto de activos para reutilizar y automatizar en un dominio de aplicación especíco, en la ingeniería de aplicación los usamos para producir, en dicho dominio, productos de software de mayor calidad, empleando menos coste y tiempo. En 2002, Krueger propuso la distinción entre tres modelos de adopción/creación de líneas de producto de software [6]: proactivo, extractivo y reactivo. El modelo proactivo es el más clásico; propone un gran esfuerzo e inversión iniciales en una ingeniería de dominio exhaustiva, donde se establece el dominio (o ámbito) exacto de los productos que pertenecerán a la línea, para luego crear los activos a partir de los cuales producirlos. Este modelo, aunque más exhaustivo, puede requerir tiempos y costes de adopción prohibitivos para una empresa; es la llamada barrera de adopción [6, 15]. Un modelo de adopción extractivo plantea la utilización, durante la ingeniería de dominio, de ingeniería inversa de los productos ya existentes en el dominio para obtener conocimiento más preciso sobre éste más rápidamente. Esta aproximación resulta en una reducción considerable de coste y tiempo en el desarrollo de activos (ver un ejemplo en [26]). La tercera alternativa es el modelo de adopción reactivo, en el que no establecemos desde un principio el dominio de la línea de producto, sino que iremos ampliando bajo demanda el ámbito de los productos de la misma, creando los correspondientes activos. Bajo demanda signica que incluiremos nuevos productos a medida que aparezca la necesidad de producirlos. La creación de activos es por tanto más incremental y progresiva que con los modelos de adopción anteriores (ver un ejemplo en [5]). Este tipo de modelo de adopción permite una transición poco invasiva desde una ingeniería de software convencional, centrada en un único producto, a una ingeniería basada en líneas de producto, centrada en la producción de variantes de productos. Estas transiciones poco invasivas ofrecen dos ventajas principales [15]: la rápida consecución del ROI (Return-of- Investment); y la posibilidad de seguir con los procesos de desarrollo normales de la empresa. En este artículo proponemos un método reactivo para realizar una transición poco invasiva hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de producto de software. Para ello, ofrecemos una solución basada en un desarrollo iterativo y desacoplado de activos, que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. En otras palabras, este método permite automatizar la toma de decisiones en los procesos de software a medida que se establece la invarianza de las mismas en el dominio de aplicación en cuestión. Nuestro método se basa en la utilización de dos estándares OMG (Object Management Group) 1 : RAS (Reusable Asset Specication) [21], Especicación de Activos Reutilizables, que permite identicar, describir y empaquetar activos de manera estándar; y SPEM (Software Process Engineering Metamodel) [22], Metamodelo de Ingeniería de Procesos de Software, que dene un lenguaje estándar de modelado de procesos de software. Esta línea de investigación tuvo su origen en un estudio que exploraba las sinergias entre Líneas de Producto de Software, Ingeniería 1 OMG es la misma organización que da soporte a MDA (Model-Driven Architecture) [20], su aproximación a la Ingeniería Dirigida por Modelos [24] (ver sección 2.1)

3 Dirigida por Modelos e Ingeniería de Procesos de Software [2]. En aquel estudio, establecimos que las líneas de producto de software aplicadas al mantenimiento de familias de modelos facilitan enormemente la Ingeniería Dirigida por Modelos. El presente estudio muestra cómo esta clase de líneas de producto puede ser encapsulada en activos reutilizables, hasta que consiguen automatizar completamente una tarea de desarrollo. En la Sección 2 explicamos la base conceptual de nuestro método. A continuación presentamos un caso de estudio (Sección 3) del método. Finalizamos con un repaso a trabajos relacionados (Seccion 4) y con las conclusiones (Seccion 5). 2. Antecedentes A continuación ofrecemos un repaso a algunas tecnologías en las que se basa nuestro método, en concreto la especicación de activos reutilizables (RAS) y el metamodelo de procesos de software (SPEM). Sin embargo, antes que nada, ofrecemos una perspectiva histórica de la sinergia entre reutilización y automatización, en la que se basa nuestro método Perspectiva Histórica En esta sección repasamos cómo las ideas de reutilización y automatización en los procesos de softare han ido convergiendo a lo largo de la historia hasta llegar a su sinergia en las líneas de producto de software. Esta descripción no trata de ser exhaustiva; sólo trata de ofrecer una introducción a la combinación de activos reutilizables y procesos de software 2. Desde 1968 [19], el término factoría de software ha sido usado para hacer hincapié en diferentes técnicas de factoría [12]: aspectos organizativos, como división del trabajo en roles y especialización; métricas y procesos de software rigurosos y altamente maduros; reutilización, en diferentes etapas de la producción; entornos y herramientas de automatización; entrenamiento y aprendizaje, a través de 2 Para un estudio más en profundidad sobre el concepto de reutilización referirse a [13, 25]; sobre el concepto de automatización ver [8, 10] la gestión del conocimiento; y exibilidad, para producir variantes de los productos. Todas éstas son facetas de la aplicación de ideas de factoría a la producción de software [8]. Aunque estas técnicas no son mutuamente excluyentes, no fue hasta nales del siglo XX que se desarrollaron sus sinergias y las tecnologías necesarias para combinarlarlas efectivamente. Se realizaron importantes estudios sobre los cambios organizativos necesarios para una ecaz implantación de un programa de reutilización [25]. Se estableció que estos cambios pasan por la creación de un nuevo rol, el analista o ingeniero de dominio, encargado de identicar, capturar, empaquetar y organizar, para su posterior reutilización, conocimiento sobre cómo se llevan a cabo las distintas tareas de producción en dominios de aplicación especícos [23]. Los trabajos en metaprogramación empezaron a ofrecer sus frutos aportando nuevas técnicas para crear generadores de aplicaciones y capturar en ellos los secretos de la producción de software en dominios especícos [10]. Se llega así a reveladores estudios sobre reutilización que concluyen que la identicación, conguración (o especialización) e integración de artefactos reutilizables requiere de herramientas de automatización, como generadores de aplicaciones o sistemas de transformación, y del uso de lenguajes de muy alto nivel de abstracción [13, 12]. A nales del siglo XX aparece el concepto de Líneas de Producto de Software [7], formalizando la sinergia entre las diferentes técnicas de fábrica de software. Este paradigma propone la producción de familias (variantes similares) de productos a partir de un conjunto de activos (assets) siguiendo planes de producción predenidos. Los activos reutilizables son artefactos con puntos de variabilidad así como (meta)información y/o procesos asociados que describen cómo especializarlos para diferentes contextos de uso [17]. Por otro lago, se apunta a la importancia de que los planes de producción o procesos de desarrollo altamente precisos, preferiblemente automáticos, tengan tiempos y costes de ejecución predecibles. Más recientemente, la Ingeniería Dirigida por Modelos (Model-Driven Engineering,

4 MDE) [24] ha venido a ofrecer una prometedora técnica para implementar planes de producción más automáticos y exibles. MDE propone la denición de todo artefacto producido y/o (re)utilizado durante el proceso de desarrollo como un modelo formal, facilitando su manipulación a través de transformaciones. No sólo MDE da soporte a las Líneas de Producto de Software, sino que lo contrario es también cierto. Recientemente han sido presentados estudios sobre las ventajas de utilizar líneas de producto de software para mantener familias de modelos [9, 2, 3] Para nalizar decir que, en la actualidad, de- nimos un activo reutilizable (asset) como la solución a un problema recurrente en el desarrollo de software. Debe tener, preferiblemente, puntos de variabilidad que deben ser con- gurados por el consumidor del activo con el n de congurarlo o especializarlo para un contexto de uso determinado. Para una reutilización efectiva, la (meta)información de conguración del activo debe ser precisa, normalmente en forma de especicación de proceso o secuencia de pasos que pueda ser ejecutada de manera, preferiblemente, automática Modelado de Activos Reutilizables La especicación de activos reutilizables (Reusable Asset Specication, RAS) [21] permite identicar, describir y empaquetar un activo de manera estándar, cumpliendo los requisitos para una reutilización efectiva descritos en la sección anterior. Con RAS, un activo es una colección cohesiva de artefactos; de hecho, se almacena como un chero comprimido que empaqueta un conjunto de cheros, cada uno representando uno de estos artefactos. Un artefacto es cualquier producto de trabajo creado durante un proceso de desarrollo, como casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc., que resuelven problemas recurrentes en el desarrollo de software. Estos artefactos, por lo general, aceptarán cierta variabilidad, por lo que contarán con puntos de variabilidad o extensión que podrán ser congurados para adaptarlos a las características del problema concreto (contexto) donde aplicarlos. Figura 1: Ejemplo de modelo SPEM, donde un rol A ejecuta una tarea, consumiendo (in) el artefacto 1 y produciento (out) el artefacto 2. La tarea tiene asociado un elemento de guía para asistir al rol en su ejecución. La (meta)información que describe el activo es un modelo que conforma con el metamodelo RAS. Este modelo se empaqueta junto al resto de artefactos, dentro del chero comprimido que representa al activo. Este modelo contiene la identicación y clasicación del activo, la descripción de sus artefactos, sus puntos de variabilidad y cómo congurarlos Modelado de Procesos de Software Los procesos de desarrollo de software se han vuelto tan complejos que es necesario el uso de lenguajes formales para modelarlos [11]. SPEM (Software Process Engineering Metamodel) [22] es un lenguaje de modelado estándar que permite describir tales procesos. El metamodelo de SPEM es muy extenso, permitiendo el modelado de muchos aspectos y problemas del proceso de desarrollo. Sin embargo, en este estudio nos centraremos en el modelado de tareas, sin ni siquiera utilizar relaciones de secuencia o prioridad entre las mismas. Las tareas, ejecutadas por roles, consumen artefactos de entrada y producen artefactos de salida (ver Figura 1). Ejemplos de artefactos son modelos de casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc. Una tarea puede tener asociado elementos de guía que ayuden al rol a desempeñarla. Estos elementos pueden ir desde ejemplos y guías hasta plantillas y activos reutilizables [22, p.126].

5 Figura 2: Ejemplo de modelo SPEM que describe la fase de análisis de un proceso de software en una empresa X. El analista A es el encargado de estudiar las actas de reunión con el cliente, y crear el diagrama de casos de uso del sistema que cumple con los requerimientos del mismo. El analista B recibe los casos de uso y, según su experiencia, crea el diagrama de clases del sistema. Figura 3: El proceso stándar de la empresa ha sido mejorado mediante la inclusión de un elemento de guía para que se asista en la tarea de creación de casos de uso. 3. Caso de Estudio Supongamos una empresa X que desarrolla software para la administración electrónica. Supongamos que tiene un proceso desarrollo estándar para todos sus proyectos, un extracto (fase de análisis) del cual vemos en la Figura 2 modelado con SPEM. La empresa desea adoptar una aproximación de líneas de producto de software en sus desarrollos, con el n de potenciar la reutilización y automatización en sus procesos de software. En este caso de estudio mostraremos cómo, haciendo uso de nuestro método, la empresa podrá abordar una transición poco invasiva hacia las líneas de producto de software, es decir, sin perturbar la ejecución de sus proyectos de desarrollo. Para facilitar la comprensión del caso de estudio, mostraremos un ejemplo centrado en la fase de análisis (Figura 2). En este ejemplo, el analista A identica y organiza progresivamente en forma de activo RAS el conocimiento sobre la creación de casos de uso en un dominio especíco, para facilitar su reutilización efectiva, hasta llegar a una completa automatización de la tarea Creación del Activo El proceso de software de la Figura 2 es actualizado para contener un elemento de guía, en concreto un activo, que representa el paquete de conocimiento que el analista A va desarrollando sobre la creación de modelos de casos de uso en un dominio especíco (ver Figura 3). A medida que el analista A va encontrando similitudes entre los modelos de casos de uso que va creando en los diferentes proyectos, deberá ir empaquetándolas en el activo. La familia de modelos (o variantes) será organizada en forma de línea de producto de software 3. Para ello, el creador del activo describirá el proceso de conguración del activo como el plan de producción de una línea de producto de software. Téngase en cuenta que el analista A no estará abordando la creación directa de la línea de productos de software de su empresa, sino la creación de una línea de productos para generar la familia de modelos creados habitualmente al desempeñar esa tarea. El procedimiento será el siguiene. Cuando el analista A deba crear un modelo de casos de uso, inspeccionará el activo en busca de un modelo que cubra sus requerimientos. Para ello hará uso de la línea de productos para modelos contenida en el activo. Si ninguno de los miembros de la línea satisface sus necesidades, deberá crear un modelo por su cuenta, a partir del miembro que más se adecúe a ellas. Cuando termine la tarea de creación del modelo, deberá realizar ingeniería de dominio para incluir la nueva variante en la línea de producto, y capturarla así a partir de entonces dentro del activo. A partir de ese momento, el proceso 3 Para más detalles sobre cómo crear líneas de producto de software para mantener familias de modelos ver [3]; para una descripción más completa sobre la implementación de la línea de producto para modelos de casos de uso ver [1].

6 Figura 4: El ingeniero de dominio, que crea la línea de producto para casos de uso, debe especicar el modelo de cracterísticas de los miembros de la línea, una plantilla de modelos a partir de la cual generarlos, y una transformación de modelos que realice automáticamente tal especialización. de conguración del activo permitirá generar la nueva variante de modelos de casos de uso, para ser aplicada siempre que se repitan las condiciones que originaron su aparición. Es importante tener en cuenta que, como toda línea de productos, ésta que crea el analista debe tener un dominio. En caso contrario, sería muy dicil establecer similitudes entre las variantes de modelos que se desea agrupar, esencial para producirlos a partir de un mismo conjunto de activos. En este caso suponemos que el analista A lleva analizando aplicaciones en el dominio de los sistemas de gestión de solicitudes (en adelante referidos como RMS: Request Management Systems) en la administración electrónica. Ha establecido que muchos de los modelos de casos de uso que sirven para describirlos siguen unos patrones y comparten similitudes. Es por ello que decide automatizar la creación de estos modelos en el dominio RMS. Creación del Proceso de Conguración El analista A deberá ir acomodando las variantes de modelos casos de uso que va creando dentro del activo 4. Para ello deberá llevar 4 No tiene por qué ser el propio creador del produc- Figura 5: Plan de producción de la línea de producto para modelos de casos de uso. El analista tiene que seleccionar una serie de características del modelo de características, en lo que se llama con- guración de características. Esta conguración es la entrada de una transformación de modelos que especializa la plantilla para obtener el modelo de casos de uso. a cabo ingeniería de dominio para crear los activos y plan de producción de la línea de productos para modelos de casos de uso. La Figura 4 muestra en SPEM el proceso a seguir. Por un lado crea el modelo de características que caracteriza la familia de modelos de casos de uso, y una plantilla de modelos a partir de la cual generarlos. Asimismo, crea una transformación de modelos para especializar automáticamente la plantilla cuando queramos obtener un miembro concreto de la línea. La Figura 5 muestra el plan de producción de la línea de producto para modelos de casos de uso en el dominio RMS. Cuando un analista de casos de uso la quiere ejecutar, sólo tiene que seleccionar una serie de características opcionales y alternativas del modelo de características (que dene la familia de modelos), en lo que se llama conguración de características del producto a generar. Esta conguración es la entrada de una transformación de modelos que automáticamente especializa una plantilla de modelos para obtener el modelo de casos de uso concreto deseado. Es preciso notar que este plan de producción será el proceso de conguración del activo de to el que tenga que acomodarlo en el activo. Para ello la organización podría designar un analista de dominio, más experto en la creación de líneas de producto de software [25, 16].

7 Figura 6: Editor de modelos RAS de nuestro plugin de Eclipse para la manipulación de activos RAS. En la sección solución (solution) se encuentra modelada la descripción de los artefactos contenidos en el activo. En la sección uso (usage) se mantiene la información de las actividades o procesos de conguración del activo para diferentes contextos. En este caso, sólo hay modelada una actividad; en concreto, el plan de producción (modelado en SPEM) de la línea de producto para modelos de casos de uso. casos de uso que está siendo desarrollado. Empaquetado del Activo Siguiendo la especicación RAS, para empaquetar el activo necesitamos realizar varias acciones. En primer lugar, deberemos modelar la (meta)información del activo, incluidos los procesos de conguración que un consumidor del mismo debe ejecutar para obtener soluciones para contextos diferentes. La Figura 6 muestra dicho modelo, que conforma con el metamodelo RAS; este modelo es serializado en un chero con el nombre de manifest.rmd y empaquetado junto al resto de - cheros/artefactos del activo. Figura 7: Vista de navegación de proyectos ras de nuestro plugin de Eclipse para la manipulación de activos RAS. El proyecto es un chero comprimido con una serie de cheros que representan artefactos del activo. El primer artefacto es un directorio, que contiene el resto de artefactos necesarios para ejecutar la línea de producto de modelos de casos de uso: tres artefactos de entrada al proceso (rms.cbfm, rmscbfm2uml.atc, rmsuml_template.uml) más la denición en SPEM del proceso en sí (SPLCasosUsoRMS.spem, Figura 5). El activo también contiene el modelo del activo (manifest.rmd), conteniendo su (meta)información, y el metamodelo de RAS (ras.ecore).

8 Figura 8: Ejemplo de modelo SPEM que describe la nueva fase de análisis del proceso de la empresa de desarrollo de software objeto de nuestro estudio. La libertad del analista A ha sido restringida, ya que sólo puede seleccionar un miembro de la línea de producto para modelos de casos de uso. La tarea queda así restringida a la mera selección de características que identican el problema que el analista quiere solucionar. La segunda parte del análisis permanece inalterada, con el analista B recibiendo el modelo de casos de uso producido por el analista A. En segundo lugar debemos empaquetar los tres artefactos creados durante la ingeniería de dominio de la Figura 4, junto con la especicación del proceso de conguración, que en este caso es el modelo SPEM de la Figura 5. Dentro del activo, junto a estos cuatro artefactos, empaquetaremos también el modelo del activo (manifest.rmd) así como el metamodelo RAS (ras.ecore). Este último no es necesario, pero es una buena práctica que aumenta la compatibilidad entre herramentas RAS. La Figura 6 muestra el contenido del activo RAS Automatización de la Tarea Hasta ahora, el proceso de desarrollo de la empresa se ha visto modicado únicamente por la inclusión de un elemento de guía, en este caso un activo reutilizable. Al ser modelado como elemento de guía es opcional, es decir, el rol puede hacer o no uso de él cuando ejecuta la tarea. Esto le da la libertad al primero de decidir si alguna de las variantes del activo satisface sus necesidades, es decir, si alguno de los contextos para los que el activo dispone de conguración se asemeja lo suciente a su problema. La gran ventaja de tener los procesos de con- guración del activo descritos con SPEM es que podemos sacarlos y ensamblarlos con planes de producción más amplio. Por ejemplo, la Figura 8 nos muestra cómo el proceso de conguración del activo, que es en realidad el plan de producción de una línea de producto para modelos de casos de uso, ha sido desempaquetado del mismo e integrado en el proceso de software de la empresa. De esta manera, la etapa de creación de casos de uso ha sido sustituida por un plan de producción automático y obligatorio. En esta situación, hemos eliminado la libertad del analista A de decidir si usar o no alguna de las variantes ofrecidas por el activo reutilizable, sino que le obligamos a utilizar una de ellas. Ahora, el analista no puede crear cualquier modelo de casos de uso, sino que únicamente puede seleccionar una de las variantes de la línea seleccionando las características que lo identican. Fíjese que el rol que crea los casos de uso es ahora denominado Analista RMS (ver Figura 8); esto enfatiza el cambio de responsabilidades del analista. Con ello ganamos dos cosas: obligar a seguir patrones y buenas prácticas de modelado que los analistas realizando esa tarea han ido estableciendo progresivamente (mientras se creaba el activo); y centralizar el conocimiento para ayudar a nuevos analistas a aprender a realizar dicha tarea. 4. Trabajos relacionados Una aproximación poco invasiva a la creación de líneas de producto de software es presentada en [14, 5]. Aunque plantea una incorporación incremental de productos a la línea, no plantea la automatización incremental del proceso de desarrollo, ni abordar la reutilización y automatización de tareas de manera desaco-

9 plada. En esta aproximación, la incorporación de productos a una línea de producto de software es incremental, pero su automatización no lo es; la incorporación de un nuevo producto se aborda creando toda infraestructura necesaria para su generación automática desde el principio. El Desarrollo Basado en Activos (Asset Based Development), en cambio, sí que plantea la creación desacoplada de activos [16]. Sin embargo, hasta la fecha, la combinación de estos activos para automatizar un proceso de software no ha sido aclarada convenientemente. 5. Conclusiones En este artículo proponemos un método reactivo para llevar a cabo transiciones poco invasivas hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de productos de software. El método se basa en un desarrollo iterativo y desacoplado de activos que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. Estos activos van capturando el conocimiento de los roles sobre la resolución de problemas en diferentes etapas del desarrollo. Con ello, a la larga se automatiza la toma de decisiones en los procesos de software, a medida que se establece que las mismas son invariantes en dominios de aplicación especícos. Nuestro método se basa en la combinación de RAS (Reusable Asset Specication) [21], especicación de activos reutilizables y SPEM (Software Process Engineering Metamodel) [22], metamodelo de ingeniería de procesos de software. Mediante un ejemplo hemos mostrado cómo la combinación del empaquetado de activos con RAS y el modelado de procesos con SPEM puede llevar a una automatización progresiva de las tareas en el proceso de desarrollo de la empresa. Referencias [1] O. Avila-García and M. D. D. Fabro. AMW use case: Mapping features to models. Technical Report MST-9, Open Canarias, S.L., Apr [2] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Integrando modelos de procesos y activos reutilizables en una herramienta mda. In JISBD 2006: Proceedings of the XI Jornadas de Ingeniería del Software y Bases de Datos, pages , Barcelona, Spain, Oct CIMNE. [3] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Using software product lines to manage model families in model-driven engineering. In SAC 2007: Proceedings of the 2007 ACM Symposium on Applied Computing, track on Model Transformation, pages ACM Press, Mar [4] R. W. Bremer. Machine-controlled production environment. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages Scientic Aairs Division, NA- TO, [5] R. Buhrdorf, D. Churchett, and C. W. Krueger. Salion's experience with a reactive software product line approach. In PFE 2003: Software Product-Family Engineering, 5th International Workshop, volume 3014 of LNCS, pages Springer, Nov [6] P. Clements and C. W. Krueger. Being proactive pays o / eliminating the adoption barrier. IEEE Software, pages 2831, July/August [7] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison Wesley, Aug 2001.

10 [8] M. A. Cusumano. The software factory: A historical interpretation. IEEE Software, 6(2):2330, [9] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. In Proceedings of GPCE 2005, volume 3676 of LNCS, pages Springer- Verlag, [10] K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, [11] J.-C. Dermiane and F. Oquendo. Key issues and new challenges in software process technology. UPGRADE: The European Journal for the Informatics Professional, V(5):1116, Oct [12] M. L. Griss. Software reuse: from library to factory. IBM Systems Journal, 32(4):548566, [13] C. W. Krueger. Software reuse. ACM Comput. Surv., 24(2):131183, [14] C. W. Krueger. Easing the transition to software mass customization. In PFE '01: Revised Papers from the 4th International Workshop on Software Product- Family Engineering, pages , London, UK, Springer-Verlag. [15] C. W. Krueger. New methods behind a new generation of software product line successes. Technical Report # , BigLever Software, Inc., Feb [16] G. Larsen. Model-driven development, assets and reuse. IBM Systems Journal, 45(3), [17] J. D. McGregor. Product production. Journal of Object Technology, 3(10):89 98, Nov/Dec [18] M. D. McIlroy. Mass produced software components. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NA- TO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages Scientic Aairs Division, NA- TO, [19] P. Naur and B. Randell, editors. Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October Scientic Aairs Division, NATO, [20] OMG. MDA guide version Technical Report omg/ , Jun Available at [21] OMG. Reusable asset specication. Technical Report ptc/ , Jun Available at [22] OMG. Software Process Engineering Meta-model 2.0. Technical Report ad/ , Apr Available at [23] R. Prieto-Díaz. Domain analysis: an introduction. SIGSOFT Softw. Eng. Notes, 15(2):4754, [24] D. C. Schmidt. Model-Driven Engineering. IEEE Computer, 39(2):4147, Feb [25] W. Tracz. Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Addison Wesley, Reading, Massachusetts, USA, [26] S. Trujillo, D. Batory, and O. Díaz. Feature refactoring a multi-representation program into a product line. In GPCE 2006: Proceedings of the 5th International Conference on Generative Programming and Component Engineering, pages , New York, NY, USA, Oct ACM Press.

REUTILIZACIÓN EN EL DOMINIO DEL ANÁLISIS SOFTWARE

REUTILIZACIÓN EN EL DOMINIO DEL ANÁLISIS SOFTWARE REUTILIZACIÓN EN EL DOMINIO DEL ANÁLISIS SOFTWARE Francisco J. Soltero Domingo, Diego J. Bodas Sagi, Valentín Pozo Llorente CES Felipe II (UCM) Ingeniería Técnica de Informática de Sistemas Resumen: Una

Más detalles

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 SPEM 2.0 SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 Metamodelo para modelos de procesos de ingeniería de software y de ingeniería de sistemas. La idea central de SPEM

Más detalles

PROGRAMA DE DOCTORADO

PROGRAMA DE DOCTORADO PROGRAMA DE DOCTORADO Desarrollo de familias de productos de software desde un enfoque generativo DPTO. DE INGENIERÍA DE SOFTWARE Y SISTEMAS INFORMÁTICOS Tema 1 Introducción Autor: Rubén Heradio Gil Índice

Más detalles

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE INFORMACIÓN GENERAL Profesor: Francisca Losavio

Más detalles

Modelado de la variabilidad en arquitecturas multicapa

Modelado de la variabilidad en arquitecturas multicapa Modelado de la variabilidad en arquitecturas multicapa José García-Alonso, Joaquín Guillén, Javier Berrocal, and Juan Manuel Murillo Escuela Politécnica, Universidad de Extremadura, Avd. de la Universidad

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Fabio A. Zorzan 1, Daniel Riesco 2 CONTEXTO La línea de investigación presentada en este trabajo se desarrolla en el marco del

Más detalles

Diseño Basado en Componentes. Curso 2008/09

Diseño Basado en Componentes. Curso 2008/09 Tabla de contenidos Diseño Basado en Componentes Técnicas relacionadas con Reutilización Introducción: por qué reutilizar?, qué reutilizar? Técnicas: Ingeniería de dominios Líneas de productos (Product-lines)

Más detalles

MDA vs Factorías de Software. Javier Muñoz, Vicente Pelechano

MDA vs Factorías de Software. Javier Muñoz, Vicente Pelechano MDA vs Factorías de Software Javier Muñoz, Vicente Pelechano Dept. de Sistemas Informáticos y Computadores Universidad Politécnica de Valencia Campus de Vera 46022 Valencia {jmunoz, pele}@dsic.upv.es Resumen

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

Proceso de Arquitectura de Software. Segunda. Semana. Dr. Cuauhtémoc Lemus Olalde. Noviembre 7, 2002. Informática

Proceso de Arquitectura de Software. Segunda. Semana. Dr. Cuauhtémoc Lemus Olalde. Noviembre 7, 2002. Informática Segunda Semana de Informática Proceso de Arquitectura de Software Dr. Cuauhtémoc Lemus Olalde Noviembre 7, 2002 Desarrollo Tradicional Requerimientos Diseño Codificación e Integración Prueba y Aceptación

Más detalles

Adopción de un esquema de líneas de productos de Software en HBT. Carlos Andrés Parra Leonardo Giral. Heinsohn Business Technology

Adopción de un esquema de líneas de productos de Software en HBT. Carlos Andrés Parra Leonardo Giral. Heinsohn Business Technology Agenda Adopción de un esquema de líneas de productos de Software en HBT Carlos Andrés Parra Leonardo Giral Heinsohn Business Technology Cámara de Comercio de Bogotá Centro Empresarial Chapinero AGENDA

Más detalles

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Ing. Marcela Daniele AC. Daniel Romero Dpto. de Computación. Facultad: Ciencias Exactas,

Más detalles

Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación

Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación Andres Romero y Hugo Arboleda Universidad de Los Andes, Cra. 1 N 18A 10, Bogotá, Colombia {aa.romero354,hf.arboleda34}@uniandes.edu.co

Más detalles

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Fabio A. Zorzan 1, Daniel Riesco 2, Nora Szasz 3 CONTEXTO La línea de investigación

Más detalles

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Rodolfo Villarroel Acevedo 1* 1 Pontificia Universidad Católica de Valparaíso. Avenida Brasil 2241,

Más detalles

BOA, un framework MDA de alta productividad

BOA, un framework MDA de alta productividad BOA, un framework MDA de alta productividad Padrón Lorenzo, J. 1, Estévez García A. 1, Roda García J.L. 2, García López F. 2 1 Open Canarias SL, Santa Cruz Tenerife, España http://www.opencanarias.com

Más detalles

Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales

Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales Santiago Jácome G. Universidad de las Fuerzas Armadas ESPE, Ecuador Universidad Autónoma de Madrid, España psjacome@espe.edu.ec

Más detalles

Estudio Comparativo de Técnicas de Modelado de Negocio

Estudio Comparativo de Técnicas de Modelado de Negocio Estudio Comparativo de Técnicas de Modelado de Negocio Juan José Cadavid 1, Carlos Andrés Ospina 1, Juan Bernardo Quintero 2 1 Avansoft S.A. Medellín, Colombia {jjcadavid, caospina}@avansoft.com 2 ABC-Flex

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

GENERACIÓN DE EDITORES GRÁFICOS DE MODELOS PARA UNA HERRAMIENTA MDA

GENERACIÓN DE EDITORES GRÁFICOS DE MODELOS PARA UNA HERRAMIENTA MDA XV Jornadas de Ingeniería del Software y Bases de Datos JISBD 2006 José Riquelme - Pere Botella (Eds) c CIMNE, Barcelona, 2006 GENERACIÓN DE EDITORES GRÁFICOS DE MODELOS PARA UNA HERRAMIENTA MDA Francisco

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

Tape Mbo e: una Metodología Orientada a Servicios

Tape Mbo e: una Metodología Orientada a Servicios Tape Mbo e: una Metodología Orientada a Servicios Motivación Objetivos Tecnología Estado del Arte Evaluación del Estado del Arte Tape Mb e Ciclo de Vida Roles Disciplinas Ciclo de Vida y Disciplinas Evaluación

Más detalles

ADAPTE Method: Tool Catalog, Measures Definition, and Process Configuration

ADAPTE Method: Tool Catalog, Measures Definition, and Process Configuration ADAPTE Method: Tool Catalog, Measures Definition, and Process Configuration Giovanni Giachetti 1, Pablo Cruz 1, Daniel Fredes 2, Hernán Astudillo 1 1 Universidad Técnica Federico Santa María, Av. España

Más detalles

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA).

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). López, G. 1 ; Jeder, I. 1 ; Echeverría, A. 1 ; Fierro, P. (PhD.) 2 1. Laboratorio de Informática de Gestión

Más detalles

Temas de investigación y desarrollo

Temas de investigación y desarrollo Componentes de Dominio para Sistemas de Información Ambiental Urciuolo Adriana, Iturraspe Rodolfo, Moyano Ezequiel, Rosanigo Beatriz, Parson Ariel, Villarreal Martín urciuolo@tdfuego.com, iturraspe@tdfuego.com,

Más detalles

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert con fecha 30 de noviembre de 2010 IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert Índice 1 Información general 2 Fecha de disponibilidad

Más detalles

Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos

Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos Maximiliano Vanzetti CIDISI, Universidad Tecnológica acional-frsf, Lavaisse

Más detalles

Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda

Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda Miguel Ángel Sánchez Vidales Escuela Universitaria de Informática

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu. Centro de Información y Gestión Tecnológica de Santiago de Cuba.

Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu. Centro de Información y Gestión Tecnológica de Santiago de Cuba. Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu Centro de Información y Gestión Tecnológica de Santiago de Cuba Cuba Leyva Miranda, Enrique José; González Prieto, Mileidys Una adaptación

Más detalles

Creación y evaluación de modelos LSP en un contexto MDA

Creación y evaluación de modelos LSP en un contexto MDA WICC 2012 433 Creación y evaluación de modelos LSP en un contexto MDA Ana Funes 1, Elizabeth Reinoso 2, Marcelo Castro 2, Aristides Dasso 1, 1 Universidad acional de San Luis, Ejército de los Andes 950

Más detalles

Desarrollo de Software Basado en Líneas de Productos de Software

Desarrollo de Software Basado en Líneas de Productos de Software IEEE Computer Society Región n 9 Capítulo Argentina Programa DVP Desarrollo de Software Basado en Líneas de Productos de Software Jonás A. Montilva C., Ph.D. IEEE Member Universidad de Los Andes Facultad

Más detalles

Universidad Politécnica de Madrid. Trabajo de Investigación Tutelada Memoria resumen

Universidad Politécnica de Madrid. Trabajo de Investigación Tutelada Memoria resumen Doctorado Conjunto en Ingeniería Informática UPM ORT Uruguay Trabajo de Investigación Tutelada Memoria resumen Titulo: Doctorando: Tutor: Líneas de Productos Software basadas en Gestión del Conocimiento

Más detalles

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS Autores: Introducción Diego R. López RedIRIS diego.lopez@rediris.es El trabajo necesario para mantener un servidor de información

Más detalles

INGENIAS: Desarrollo dirigido por modelos de SMA

INGENIAS: Desarrollo dirigido por modelos de SMA INGENIAS: Desarrollo dirigido por modelos de SMA Juan Pavón Mestras jpavon@pdi.ucm.es Dep. de Ingeniería del Software e Inteligencia Artificial Universidad Complutense Madrid http://grasia.fdi.ucm.es Objetivo

Más detalles

Ingeniería de Procesos Software Francisco Ruiz

Ingeniería de Procesos Software Francisco Ruiz Ingeniería de Procesos Software Francisco Ruiz Universidad de Cantabria Calidad de Procesos y Productos Software Julio-2010 Objetivos Conocer los principios e importancia de la IPS. Comprender el interés

Más detalles

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Lornel A. Rivas 1,2, María Pérez 2, Luis E. Mendoza 2, y Anna Grimán 2 1 Gerencia de Investigación, Instituto Nacional de

Más detalles

Reutilización de Requisitos Organizados como una Familia de Diagramas

Reutilización de Requisitos Organizados como una Familia de Diagramas Reutilización de Requisitos Organizados como una Familia de Diagramas Oscar López, Miguel A. Laguna, and Francisco J. García Technological Institute of Costa Rica olopez@infor.uva.es University of Valladolid,

Más detalles

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad Dra. María a José Escalona Cuaresma mjescalona@us.es www.iwt2.org Universidad de Sevilla Grupo de Ingeniería Web y Testing

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Una propuesta de implementación para especificaciones de patrones de comportamiento

Una propuesta de implementación para especificaciones de patrones de comportamiento Una propuesta de implementación para especificaciones de patrones de comportamiento Alberto A. Cortez 123, Claudia A. Naveda 12 1 Consejo de Investigaciones -CIUDA, Universidad del Aconcagua, Mendoza,

Más detalles

Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es

Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es Metodología y Técnicas en Proyectos software para la Web II-6 para la Ingeniería Web Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es Programa

Más detalles

Resumen. Introducción

Resumen. Introducción Arquitectura de software para Sistemas de Información Ambiental Urciuolo Adriana, Iturraspe Rodolfo, Parson Ariel, Esteban Natalia Universidad Nacional de la Patagonia San Juan Bosco Sede Ushuaia, Darwin

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Boyeros, La Habana, Cuba, lcabrerag@uci.cu

Boyeros, La Habana, Cuba, lcabrerag@uci.cu EXTENSIÓN DE VISUAL PARADIGM FOR UML PARA EL DESARROLLO DIRIGIDO POR MODELOS DE APLICACIONES DE GESTIÓN DE INFORMACIÓN Visual Paradigm for UML extension for Model-Driven Development of information management

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

CONGRESOS 2012 INTERNACIONALES

CONGRESOS 2012 INTERNACIONALES CONGRESOS 2012 INTERNACIONALES Autores: V. A. Bollati, P. Atzeni, E. Marcos, J.M. Vara Título: Model Management Systems vs. Model Driven Engineering: A Case Study Congreso: Symposium on Applied Computing

Más detalles

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Andrea Delgado 1, Ignacio García-Rodríguez de Guzmán 2, Francisco Ruiz 2, Mario Piattini 2 1 Instituto de Computación,

Más detalles

Perfil UML para el desarrollo de aplicaciones WAP

Perfil UML para el desarrollo de aplicaciones WAP Perfil UML para el desarrollo de aplicaciones WAP Ricardo Soto D., Mauricio Camara J. Escuela de Ingeniería Informática, Pontificia Universidad Católica de Valparaíso, Chile E-mail: ricardo.soto@ucv.cl,

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Cámara de Comercio de Bogotá Centro Empresarial Chapinero

Cámara de Comercio de Bogotá Centro Empresarial Chapinero Desarrollo de software basado en modelos: de la teoría a la práctica Rubby Casallas rcasalla@uniandes.edu.co Departamento de Ingeniería de Sistemas y Computación Grupo de Construcción de Software Universidad

Más detalles

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios Víctor Mario Cardona Medina Universidad Nacional de Colombia Facultad de Ingeniería, Departamento de Ingeniería

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Posgrado en Ciencias y Tecnologías de la Información Marzo del 2012. 1. Responsables Dra. Angelina

Más detalles

CMMI aplicado a entornos de desarrollo software: El caso de MOSKitt4ME

CMMI aplicado a entornos de desarrollo software: El caso de MOSKitt4ME Máster Universitario en Ingeniería del Software, Métodos Formales y Sistemas de Información Universitat Politècnica de València Departamento de Sistemas Informáticos y Computación CMMI aplicado a entornos

Más detalles

Desarrollo y Configuración de una Línea de Producto Software de Comercio Electrónico

Desarrollo y Configuración de una Línea de Producto Software de Comercio Electrónico Universidad de Valladolid E. T. S. DE INGENIERÍA INFORMÁTICA Ingeniería Técnica en Informática de Gestión Desarrollo y Configuración de una Línea de Producto Software de Comercio Electrónico Alumnas: Esther

Más detalles

Curso: El Proceso de Desarrollo de Software

Curso: El Proceso de Desarrollo de Software Curso: El Proceso de Desarrollo de Software EL PROCESO DE DESARROLLO DE SOFTWARE... 1 OBJETIVO...1 CONTENIDO...1 BIBLIOGRAFÍA...4 DOCENTE...4 MODALIDAD DEL DESARROLLO...4 El proceso de Desarrollo de Software

Más detalles

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (67-78) Universidad La Salle Arequipa, Perú Técnica para reusar artefactos de análisis y diseño en el modelamiento de software 1 Percy

Más detalles

Variabilidad, Trazabilidad y Líneas de Productos: una Propuesta basada en UML y Clases Parciales

Variabilidad, Trazabilidad y Líneas de Productos: una Propuesta basada en UML y Clases Parciales Variabilidad, Trazabilidad y Líneas de Productos: una Propuesta basada en UML y Clases Parciales Resumen Miguel A. Laguna Departamento de Informática Universidad de Valladolid mlaguna@infor.uva.es Uno

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

SPEM - Software & Systems Process Engineering Metamodel Specification

SPEM - Software & Systems Process Engineering Metamodel Specification SPEM - Software & Systems Process Engineering Metamodel Specification 1. ALCANCE: El propósito de éste documento es proporcionar una definición comprensible del meta-modelo de ingeniería de procesos de

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Una aproximación a las pruebas de aplicaciones Web basadas en un contexto MDWE

Una aproximación a las pruebas de aplicaciones Web basadas en un contexto MDWE Una aproximación a las pruebas de aplicaciones Web basadas en un contexto MDWE Arturo H. Torres, María J. Escalona, Manuel Mejías, Javier J. Gutiérrez Departamento de Lenguajes y Sistemas Informáticos,

Más detalles

Sistemas ERP (Enterprise Resources Planning)

Sistemas ERP (Enterprise Resources Planning) Sistemas ERP (Enterprise Resources Planning) Apellidos, nombre Departamento Centro Oltra Badenes, Raúl Francisco (rauloltra@doe.upv.es) Departamento de Organización de Empresas Universitat Politècnica

Más detalles

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc).

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc). REVISIÓN CONCEPTOS, METODOLOGÍAS Y HERRAMIENTAS SOPORTE EN INGENIERÍA MARLON MÚJICA Estudiante de Ingeniería de Sistemas Universidad Industrial de Santander mujica@cidlisuis.org COLOMBIA EDWIN LOGREIRA

Más detalles

Estudio de Framework Visual Studio DSL Tools

Estudio de Framework Visual Studio DSL Tools VS. Eclipse Estudio de Framework Melanie Vilaine, Felipe Ramos Collado, Juan Antonio Tejero Fernández, Inmaculada Labrador del Río Ingeniería Informática Universidad de Cádiz 19 de enero de 2012 1 / 57

Más detalles

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo Posgrado en Ciencias y Tecnologías de la Información Marzo del 2014. 1. Responsables Dra. Angelina Espinoza

Más detalles

Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos

Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos Andrés Romero y Fabián Ceballos Universidad de los Andes, Cra. 1 No 18A 10, Bogotá, Colombia {aa.romero354, fl.ceballos40}@uniandes.edu.co

Más detalles

ADM: MÉTODO DE DISEÑO PARA LA GENERACIÓN DE PROTOTIPOS WEB RÁPIDOS A PARTIR DE MODELOS

ADM: MÉTODO DE DISEÑO PARA LA GENERACIÓN DE PROTOTIPOS WEB RÁPIDOS A PARTIR DE MODELOS XV Jornadas de Ingeniería del Software y Bases de Datos JISBD 2006 José Riquelme - Pere Botella (Eds) CIMNE, Barcelona, 2006 ADM: MÉTODO DE DISEÑO PARA LA GENERACIÓN DE PROTOTIPOS WEB RÁPIDOS A PARTIR

Más detalles

Desarrollo de Líneas de Productos de Software

Desarrollo de Líneas de Productos de Software Centro Experimental de Ingeniería de Software Departamento de Ciencias de la Computación Facultad de Ciencias Físicas y Matemáticas Universidad de Chile Desarrollo de Líneas de Productos de Software María

Más detalles

Proceso de Desarrollo de Software: Herramientas de Configuración de Procesos. Elisa Herrmann Ingeniería del Software de Gestión

Proceso de Desarrollo de Software: Herramientas de Configuración de Procesos. Elisa Herrmann Ingeniería del Software de Gestión Proceso de Desarrollo de Software: Herramientas de Configuración de Procesos Elisa Herrmann Ingeniería del Software de Gestión Herramientas Eclipse Process Framework (EPF) Rational Method Composer (RMC)

Más detalles

Arquitectura de Software, mucho más que un diagrama tradicional. Dr. Cuauhtémoc Lemus Olalde. Centro de Investigación en Matemáticas (CIMAT)

Arquitectura de Software, mucho más que un diagrama tradicional. Dr. Cuauhtémoc Lemus Olalde. Centro de Investigación en Matemáticas (CIMAT) Congreso Estatal de Ciencias de la Computación Universidad Autónoma de Aguascalientes Arquitectura de Software, mucho más que un diagrama tradicional Dr. Cuauhtémoc Lemus Olalde Centro de Investigación

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO

MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO XV Jornadas de Ingeniería del Software y Bases de Datos JISBD 2006 José Riquelme - Pere Botella (Eds) CIMNE, Barcelona, 2006 MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

Más detalles

icaria Lean Upgrade Modernización de sistemas y aplicaciones iadm industrialized Application Development and Maintenance (www.netzima.

icaria Lean Upgrade Modernización de sistemas y aplicaciones iadm industrialized Application Development and Maintenance (www.netzima. icaria Lean Upgrade Modernización de sistemas y aplicaciones iadm industrialized Application Development and Maintenance (www.netzima.com/icaria) Sistemas obsoletos E l s i s t e m a d e i n f o r m a

Más detalles

Clasificación de Componentes OTS (Off-The-Shelf) para Sistemas de Información Geográficos

Clasificación de Componentes OTS (Off-The-Shelf) para Sistemas de Información Geográficos Clasificación de Componentes OTS (Off-The-Shelf) para Sistemas de Información Geográficos Proyecto de Investigación Área Ingeniería de Software Unidad Académica Caleta Olivia Universidad Nacional de la

Más detalles

Guía docente de la asignatura

Guía docente de la asignatura Guía docente de la asignatura Asignatura Materia T22: DISEÑO, INTEGRACIÓN Y ADAPTACIÓN DE SOFTWARE TECNOLOGÍAS SOFTWARE Módulo Titulación GRADO EN INGENIERÍA INFORMÁTICA DE SISTEMAS (464) Plan 464 Código

Más detalles

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE SOFTWARE Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP jmonteror@usmp.pe FÁBRICA DE AUTOS Entrada Salida Autos FÁBRICA DE SOFTWARE Entrada Salida Información

Más detalles

HACIA UNA ONTOLOGÍA PARA FÁBRICAS DE SOFTWARE. Kenyer Domínguez 1

HACIA UNA ONTOLOGÍA PARA FÁBRICAS DE SOFTWARE. Kenyer Domínguez 1 HACIA UNA ONTOLOGÍA PARA FÁBRICAS DE SOFTWARE Kenyer Domínguez 1 María A. Pérez 2, Luis E. Mendoza 2 y Anna Grimán 2 RESUMEN Actualmente se está retomando el concepto de Fábricas de Software (FS) donde

Más detalles

Historia de revisiones

Historia de revisiones Binary Rain Glosario Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/08/2012 1.0 Creación del documento Carolina Trias 18/08/2012 1.1 Revisado y corregido por SQA Mercedes Marzoa

Más detalles

270015 - IES - Introducción a la Ingeniería del Software

270015 - IES - Introducción a la Ingeniería del Software Unidad responsable: 270 - FIB - Facultad de Informática de Barcelona Unidad que imparte: 747 - ESSI - Departamento de Ingenieria de Servicios y Sistemas de Información Curso: Titulación: 2015 GRADO EN

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Cecilia Datko 1, Yanela Carllinni 2 Analista de Sistemas en el Depto. Sistemas de la Dirección de Informática

Más detalles

Una propuesta para la reutilización de componentes en el proceso de desarrollo de software educativo

Una propuesta para la reutilización de componentes en el proceso de desarrollo de software educativo 1 Una propuesta para la reutilización de componentes en el proceso de desarrollo de software educativo E. García Roselló, J. González Dacosta,, E. Mandado, V. G. Valdés Pardo, J. Baltasar García,M. Pérez

Más detalles

Análisis de Impacto de Cambios en Requisitos Software

Análisis de Impacto de Cambios en Requisitos Software Análisis de Impacto de Cambios en Requisitos Software Posgrado en Ciencias y Tecnologías de la Información Marzo del 2012. 1. Responsables Dra. Angelina Espinoza Limón Escuela Universitaria de Informática

Más detalles

Gerencia de Proyectos Proceso de Software

Gerencia de Proyectos Proceso de Software Gerencia de Proyectos Proceso de Software Victor Manuel Toro C. VictorToro@cincosoft.com CincoSOFT Ltda. Compañía de Ingenieros Constructures de Software Tel. (+57)(1) 6230180 * Fax (+57)(1) 2566774 Carrera

Más detalles

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática El Proceso de Desarrollo de Software La Ingeniería del Software Ingeniería... La profesión en la que el conocimiento de las ciencias naturales y matemáticas, ganado con estudio, experiencia y práctica,

Más detalles

Documentando Arquitecturas Orientadas a Aspectos para Líneas de Productos de Software

Documentando Arquitecturas Orientadas a Aspectos para Líneas de Productos de Software Documentando Arquitecturas Orientadas a Aspectos para Líneas de Productos de Software Ocharán Hernández, Jorge Octavio 1, Cortes Verdin, Karen 1,2 1 Facultad de Estadística e Informática Universidad Veracruzana

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles