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.

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

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

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

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

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

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

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

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

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

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

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

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

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

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

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

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

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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

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

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

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

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

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

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

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

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

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

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Arquitectura de desarrollo Fomento.Net

Arquitectura de desarrollo Fomento.Net Casos de éxito everis Arquitectura de desarrollo Fomento.Net Resumen País: España. Sector: Administración. Perfil del Cliente Subdirección General de Tecnologías y Sistemas de la Información (SGTSI) del

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada secció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

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

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción 1.1. Propósito de la Guía BABOK El propósito principal de la Guía BABOK Guide es definir la profesión del Análisis de Negocio y proveer un conjunto de prácticas comúnmente aceptadas.

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

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

Anteproyecto Fin de Carrera

Anteproyecto Fin de Carrera Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:

Más detalles

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Título Área específica de la publicación 2 Implementación de Procesos Business Process Management BPM Services

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

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

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

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

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

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Instalación de Sistemas de Automatización y Datos

Instalación de Sistemas de Automatización y Datos UNIVERSIDADE DE VIGO E. T. S. Ingenieros Industriales 5º Curso Orientación Instalaciones y Construcción Instalación de Sistemas de Automatización y Datos José Ignacio Armesto Quiroga http://www www.disa.uvigo.es/

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

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

Unidades temáticas de Ingeniería del Software. Software e Ingeniería del Software 5ª edición (2008)

Unidades temáticas de Ingeniería del Software. Software e Ingeniería del Software 5ª edición (2008) Unidades temáticas de Ingeniería del Software Software e Ingeniería del Software 5ª edición (2008) la importancia del software El software ha evolucionado durante las últimas cinco décadas aunque no al

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

Curso de Spring Framework

Curso de Spring Framework Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Spring es un proyecto de código abierto (open source), originalmente creado por Rod Johnson y descrito en su

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Tecnologías de componentes y proceso de diseño de aplicaciones basado en componentes

Tecnologías de componentes y proceso de diseño de aplicaciones basado en componentes Tecnologías de y proceso de diseño de aplicaciones basado en Programación orientada a objetos : Lenguajes, Tecnologías y Herramientas Master de Computación Santander, 2009 Patricia López Grupo de Computadores

Más detalles

Software Architecture Assesment. Rosa Virginia Icedo Ojeda Jorge Moisés Trejo Vargas Mayo 2003

Software Architecture Assesment. Rosa Virginia Icedo Ojeda Jorge Moisés Trejo Vargas Mayo 2003 Software Architecture Assesment Rosa Virginia Icedo Ojeda Jorge Moisés Trejo Vargas Mayo 2003 Outline Software Architecture Assesment Arquitectura de Sofwtare (AS) Por qué evaluar una AS? Qué evaluamos

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

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

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR RECURSOS DE INFORMACIÓN Y CONOCIMIENTO EN UN CENTRO I+D+I EN LA PLATAFORMA SURICATA Marrero, S.R; Nelson, J.C; Galán, M; Ocón, A.; Rubio, E. sonia@cicei.com;

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

Int n rod o u d c u c c i c ón ó n Pr P oc o e c s e o s o ISW

Int n rod o u d c u c c i c ón ó n Pr P oc o e c s e o s o ISW Proceso de Ingeniería de Software Introducción Proceso ISW Introducción Proceso ISW INTRODUCCIÓN A LA INGENIERÍA SOFTWARE Producto y Proceso. La crisis del Software. Los mitos del Software. 2 Introducción

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

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

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

El desarrollo de aplicaciones

El desarrollo de aplicaciones e d i t o r i a l Entendiendo el desarrollo de los sistemas SOA María Consuelo Franky R. El desarrollo de aplicaciones orientadas y basadas en servicios, como estilo de arquitectura, emergió sobre la arena

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

PLM Software. La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes

PLM Software. La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes Siemens PLM Software La última tecnología en automatización de programación de control numérico para aumentar la eficiencia de la manufactura de partes www.siemens.com/nx I n f o r m e t é c n i c o La

Más detalles

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS Los clientes compran un servicio basandose en el valor que reciben en comparacion con el coste en el que incurren. Por, lo tanto, el objetivo a largo plazo

Más detalles

UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR

UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR Manuel González y Javier Cuadrado Departamento de Ingeniería Industrial II, Campus de Esteiro, 15403 Ferrol Universidad de

Más detalles

Mejores prácticas para mejorar la salud, la seguridad y el medio ambiente, fiabilidad y calidad

Mejores prácticas para mejorar la salud, la seguridad y el medio ambiente, fiabilidad y calidad Mejores prácticas para mejorar la salud, la seguridad y el medio ambiente, fiabilidad y calidad Integrar los procesos de Salud, Seguridad y Medio Ambiente con la gestión del trabajo y los activos Características

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

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

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

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

El conocimiento de los desarrolladores de sistemas: cómo nutrirlo, sistematizarlo y potenciarlo. Alan Calderón Castro

El conocimiento de los desarrolladores de sistemas: cómo nutrirlo, sistematizarlo y potenciarlo. Alan Calderón Castro El conocimiento de los desarrolladores de sistemas: cómo nutrirlo, sistematizarlo y potenciarlo Alan Calderón Castro Temario Motivación Patrones de análisis de dominio Familias de productos de software

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

Aplicación del BPM al desarrollo de sistemas computacionales

Aplicación del BPM al desarrollo de sistemas computacionales Aplicación del BPM al desarrollo de sistemas computacionales Facultad de Administración Región Veracruz Ismael Esquivel Gámez, iesquivel@uv.mx Emmanuel Contreras Cebada, emmanuel_c10@hotmail.com Línea:

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

Más detalles

RESUMEN 1. INTRODUCCIÓN

RESUMEN 1. INTRODUCCIÓN Análisis de dominio orientado a las características (FODA) para el desarrollo de una metodología para la evaluación personal en la especificación de requerimientos de software Manuel A. Murillo Madera,

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

CA Mainframe Chorus for DB2 Database Management versión 2.0

CA Mainframe Chorus for DB2 Database Management versión 2.0 HOJA DE PRODUCTO CA Mainframe Chorus for DB2 Database Management CA Mainframe Chorus for DB2 Database Management versión 2.0 Simplifique y dinamice su DB2 para tareas de administración de cargas de trabajo

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES

UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES Área de formación: Disciplinaria. Unidad académica: Desarrollo de Sistemas de información. Ubicación: Séptimo semestre. Clave: 2096

Más detalles

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN OBJETIVOS GENERALES 1. Identificar, diseñar, automatizar y habilitar la mejora continua de los procesos relacionados a la necesidad o proyecto

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

Resumen. 1. Introducción. 2. Objetivos

Resumen. 1. Introducción. 2. Objetivos Propuesta para la Asignatura Sistemas Industriales en las Titulaciones de Informática F.A. Pujol, F.J. Ferrández, J.L. Sánchez, J. M. García Chamizo Dept. de Tecnología Informática y Computación Universidad

Más detalles

5 La Gerencia de Proyectos

5 La Gerencia de Proyectos 5 La Gerencia de Proyectos La gran mayoría de las civilizaciones han tenido como factor común la ejecución de grandes hazañas dignas de recordarse, que han quedado plasmadas en los libros de historia y

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

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Pontificia Universidad Católica del Ecuador

Pontificia Universidad Católica del Ecuador 1. DATOS INFORMATIVOS: MATERIA O MÓDULO: INGENIERÍA DE SOFTWARE I CÓDIGO: CARRERA: SISTEMAS NIVEL: QUINTO No. CRÉDITOS: 4 CRÉDITOS TEORÍA: 4 SEMESTRE/AÑO ACADÉMICO: Segundo Semestre 2011-2012 CRÉDITOS

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

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

Plantilla para Casos de Éxito

Plantilla para Casos de Éxito Plantilla para Casos de Éxito Nombre/Actividad de la EMPRESA objeto de estudio: INSIGNA Sector al que pertenece: Presidente o gerente de la empresa: Antonio Gil Moreno Localización: Valencia Facturación

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