Carlos Santander Vega Jefe de Proyectos Bolsa de Comercio de Santiago. Santiago, Chile

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

Download "Carlos Santander Vega Jefe de Proyectos Bolsa de Comercio de Santiago. Santiago, Chile csantander@bolsadesantiago.com"

Transcripción

1 Combinando enfoques de SOA con el concepto de gestión de variabilidad de SPL, para mejorar la mantenibilidad de sistemas transaccionales de corredoras de bolsa. Carlos Santander Vega Jefe de Proyectos Bolsa de Comercio de Santiago. Santiago, Chile Bernhard Hitpass Heyl Departamento de Informática Universidad Técnica Federico Santa María Santiago, Chile. Resumen El negocio bursátil nacional, depende completamente de las plataformas tecnológicas que permiten operar el negocio. Todos los actores asociados, como las bolsas de comercio, corredoras de bolsa y los inversionistas, utilizan estas plataformas siendo una de las más importantes el sistema de gestión de corredoras, provisto principalmente por la Bolsa de Comercio de Santiago. Actualmente esta plataforma enfrenta diversos problemas en su mantenibilidad debido a su despliegue descentralizado en los corredores y a los constantes controles de cambio y mantenciones que enfrenta. Para resolver este problema, se define un nuevo modelo referencial de arquitectura con enfoque metodológico SOA, combinado con el enfoque de la gestión de la variabilidad propuesto por las Software Product Line. Con el resultado obtenido se hace una revisión de los atributos de calidad para la mantenibilidad definidos en la ISO y se establece una comparación entre la situación actual y el nuevo modelo propuesto. Palabras Claves SOA; BPM; ESB; Software Product Line; COVAMOF. I. INTRODUCCION El negocio bursátil en Chile se encuentra en una etapa de crecimiento y de expansión constante, principalmente con motivo de los avances tecnológicos que han impactado profundamente la manera en como se realizan las operaciones financieras. Todos los actores de este negocio, se han visto obligados a participar del mercado a través de diversas plataformas tecnológicas, las cuales sustituyeron las operaciones físicas que se realizaban en las ruedas de negociación que tienen las bolsas de valores. Particularmente en Chile, existen tres bolsas de valores donde opera el negocio bursátil, la Bolsa Electrónica de Chile, la Bolsa de Valparaíso y la Bolsa de Comercio de Santiago (BCS); siendo esta última, la más importante y la con mayor participación de instituciones financieras y también de inversionistas. Uno de los actores más importantes en este modelo de negocio, son las corredoras de bolsa, las cuales representan el intermediario único y legalmente aceptado para que los inversionistas puedan realizar sus operaciones y con ello lograr la rentabilidad que toda operación bursátil espera. Para poder operar en le mercado, las corredoras de bolsa requieren de las tecnologías necesarias para cubrir 2 aspectos del negocio: la negociación y la gestión interna. La negociación, es atendida por un sistema centralizado que las bolsas de valores y en específico, la Bolsa de Comercio de Santiago (bolsa seleccionada para este trabajo) provee para que las corredoras puedan operar como intermediario de sus clientes o inversionistas. Este sistema, es la representación de la rueda de negociación a nivel tecnológico; es decir, un redondel donde físicamente los corredores se ubicaban y publicaban sus ofertas y sus demandas. Como segundo aspecto, está la gestión interna, lo que se denomina sistema gestión de corredoras de bolsa. Actualmente esto está soportado principalmente por una plataforma que provee la BCS y que da cobertura a todas las aristas de la gestión operativa de una corredora de bolsa, desde el ingreso de operaciones hasta los procesos que materializan las mismas, como facturación, tesorería, custodia de instrumento, entre otras funcionalidades. Desde el punto de vista de sistema de información, esta plataforma es una de las que más se ve afectada por los cambios en el negocio y está constantemente sujeta a ser modificada o a que se agreguen nuevas funcionalidades en ella. Gran parte de estos cambios, son solicitados por las mismas corredoras a través de requerimientos que buscan potenciar los servicios ofrecidos a sus clientes, entregando elementos diferenciadores ante sus competidores (las otras corredoras). A diferencia del sistema de negociación, el sistema de gestión de corredoras no es un sistema centralizado, es un sistema que tiene una versión única de componentes el cual se instancia para cada corredor separadamente. Cada una de estas instancias, tiene configuraciones distintas y además funcionalidades que eventualmente los corredores pueden haber solicitado. Para poder controlar esto, se crean parámetros

2 de configuración que determinan el comportamiento funcional del sistema en cada una de las instancias. La realización de cambios en el sistema bajo las condiciones descritas, representa un problema importante para los equipos de desarrollo, ya que el sistema no tiene una arquitectura idónea para soportar adecuadamente estas necesidades, lo que ha provocado un sobreesfuerzo por parte de los responsables. Cada vez que se modifica un componente, se debe revisa el impacto en las distintas instancias, considerando los parámetros y el funcionamiento que cada corredora puede tener; además no existe un mecanismo de control para esto, por lo que muchas funcionalidades se pierden entre las distintas configuraciones que tienen las corredoras. La situación del sistema de gestión de corredoras, afecta prácticamente el 90% de las corredoras de bolsa que transan en Chile, ya que el principal proveedor de estos sistemas es la BCS. Los cambios que experimenta son constantes y requieren de toda una gerencia responsable, teniendo desde mesas de ayuda, equipo de desarrollo, mantención y de soporte de infraestructura tecnológica (servidores, base de datos, conectividad, etc.). Tomando en cuenta la exigente situación que enfrenta esta plataforma, este trabajo tiene como objetivo realizar la definición de un nuevo modelo referencial para su arquitectura y para el despliegue de sus componentes, considerando una estrategia metodológica para poder gestionar correctamente los cambios que enfrentan sus artefactos y así mejorar su mantenibilidad, una de las principales dificultades que tienen los ingenieros responsables. Para poder validar este nuevo modelo, se realizará una medición del atributo de mantenibilidad que define la ISO 25010, comparando la medición en el modelo actual con el nuevo modelo propuesto. Para poder realizar esto, se tomará un caso de ejemplo de implementación y se medirá en ambos modelos. La estructura de este documento continua de la siguiente manera: la sección II tiene la definición completa del problema con todos sus alcances, en la sección III se define el estado del arte para los problemas detectados, en la sección IV se considera el estado del arte y se define una solución, luego en la sección V se propone un modelo de arquitectura objetivo el cual es validado en la sección número VI. Finalmente, luego de validar la solución, se plantean las conclusiones de este trabajo y se revisan los resultados obtenidos. II. DEFINICIÓN DEL PROBLEMA En el escenario descrito anteriormente, se señaló que existe una deficiencia importante en la capacidad que tiene el sistema para que se puedan realizar mantenciones en él. Esta situación, se debe en gran medida a la desorganización y a la falta de estructura en el despliegue de sus componentes, los cuales se han desarrollado progresivamente durante los últimos 20 años, sin una visión integral de todas las partes y donde aún persisten incluso funcionalidades legadas como programas COBOL. Actualmente este sistema cuenta con cerca de 800 funcionalidades y hay presencia de diversas tecnologías, con notorios problemas en el alto acoplamiento de sus componentes y la baja cohesión de los mismos, lo que ha significado un problema cuando surgen necesidades de integración con otras plataformas y cuando se realizan mantenciones. Esto último ha sido una constante en el trabajo que realizan los equipos responsables del sistema. Asociado a lo anterior, como medida para poder soportar las solicitudes de cambios y mantener el sistema con una versión única de sus piezas, se han incorporado parámetros de control que separan las funcionalidades específicas (solicitadas por corredores específicos) de aquellas que son comunes para todos los corredores, lo que ha provocado un aumento en la complejidad ciclomática de las piezas. Inicialmente esto se consideró como una buena práctica para no generar impacto en el negocio por la solicitud de cambio de alguna corredora que pudiera afectar a las otras; sin embargo, debido a la ausencia de mecanismo de control y a los problemas estructurales, esto se transformó en una de las principales dificultades para los analistas, ya que deben invertir extensas horas de trabajo en revisar todas las variaciones funcionales que puede presentar un componente. Considerando las dificultades descritas, se enfrenta en términos globales un problema fundamental asociado a la mantenibilidad del sistema, lo que afecta directamente a la BCS como proveedor de la plataforma. El esfuerzo necesario para realizar cambios e incorporar nuevas funcionalidades es muy alto, lo que debe ser subsidiado por las corredoras y también por la misma Bolsa, que debe invertir sumas importantes de recursos en poder adaptar el sistema a las necesidades que ya se han comentado. Como consecuencia final del problema en la mantenibilidad, está el impacto más importante y más grave que es la percepción de los clientes y la continuidad del negocio producto de la generación de incidencias. Lamentablemente, el problema anterior ha derivado en la generación de errores por parte de los desarrolladores y la ocurrencia de eventos negativos en la operación del sistema, lo que ha sido altamente cuestionado por sus usuarios y ha desgastado de manera importante a los equipos de mantención y desarrollo. Abordando el problema anterior desde una perspectiva holística, este documento busca proponer un modelo referencial de arquitectura para el sistema de gestión de corredores de bolsa, que entregue mejores condiciones estructurales para soportar de manera más óptima los requerimientos de mantención. Este modelo referencial, debe alinear una definición de arquitectura flexible, integrable y de fácil modificación, con alguna estrategia que mejore el proceso de mantención del sistema en términos integrales; considerando además como principal necesidad el poder desplegar el sistema en múltiples instancias con variaciones funcionales entre ellas. Este problema es el más importante y por eso resolverlo es fundamental para poder alinear la plataforma con la estrategia de negocio que está definiendo la organización en el mediano y largo plazo. Resolver este problema va en directo beneficio del negocio de la organización, de los distintos equipos de desarrollo que modifican la plataformas, las corredoras que van a poder recibir con mayor facilidad sus cambios y finalmente

3 los inversionistas que contarán con un mejor soporte tecnológico para sus operaciones. III. ESTADO DEL ARTE Tomando en cuenta la importancia que tiene resolver el problema de la mantenibilidad del sistema, se plantea enfocar los esfuerzos en atenderlo considerando dos perspectivas: desde la mirada de la arquitectura y el despliegue de los componentes asociados y desde la estrategia y el proceso aplicado para realizar las mantenciones. Es necesario un complemento entre estas dos aristas, ya que mejorando solamente la arquitectura del sistema, no se resuelve el problema de fondo, es necesario también ajustar la forma en como se mantiene el sistema. Además de esto, se deben considerar las características de distribución (instancias distintas) que se tienen. En consideración con la primera arista definida, la tendencia que indica la bibliografía va en dirección a lo que se conoce como Service-oriented architecture (SOA), que representa un paradigma estratégico para organizar, estructurar y desplegar las funcionalidades de un sistema a través de servicios reutilizables que permitan mejorar la eficiencia, agilidad y productividad. El concepto de Servicio en este planteamiento representa la unidad que permite desacoplar las funcionalidades y con ello otorgar mayor flexibilidad, uno de los requisitos actuales para mejorar las condiciones de mantenibilidad [1]. Considerando un arquitectura enfocada en el paradigma SOA, se podría realizar un trabajo de reingeniería con aquellas funcionalidades y componentes que no están en condiciones para ser transformados en servicios naturalmente y con ello distribuir horizontalmente las funcionalidades y extender sus capacidades de integración. Como uno de los principales habilitadores para llevar a cabo una arquitectura de sistemas con un enfoque SOA que responda a las necesidades tecnológicas y de negocio, se indica la utilización como complemento de una herramienta Business Process Managment Suites (BPMS) para la gestión de procesos de negocios que utilicen los servicios desplegados. En específico y en términos más técnicos, las BPMS permiten la gestión y la implementación de procesos de negocios configurables, que pueden ser integrados con servicios, interfaces y con flujos que pueden ser diseñados de acuerdo a las necesidades que se tengan. A través de una herramienta como esta, se pueden modelar dinámicamente ciertos flujos que hoy se controlan a través de parámetros de configuración y que son parte de las lógicas de negocio implementadas en el sistema. Otro complemento importante en este esquema, es utilizar como habilitador para la centralización de los servicios un Enterprise Service Bus, que es uno de los elementos de facto en las arquitecturas con enfoque SOA, donde resulta clave tener un mecanismo para indexar y centralizar los servicios cuando escalan en número. Realizando una definición de arquitectura para el sistema en cuestión con enfoque SOA, utilizando además los complementos señalados y haciendo las debidas tareas de reingeniería que se necesiten, se podría llegar a un modelo de arquitectura que entregue mejores condiciones para abordar los problemas de integración, acoplamiento y flexibilidad, mejorando la situación actual desde la primera perspectiva planteada, la arquitectura. El día de hoy, la tendencia de los sistemas de información está en una etapa de estrecha relación con las utilización de arquitecturas Middleware, donde existan elementos de integración, existan servicios distribuidos y la organización del sistema sea lo más desacoplada posible, habiendo cada vez más niveles de abstracción de alto nivel [2]. Considerando esta tendencia, el paradigma SOA y en particular las generalidades de la arquitectura que acá se plantean, se puede determinar que están en la dirección correcta, con lo que además se podría resolver el problema de tener una plataforma que pueda escalar y mantenerse en el tiempo. Desde esta perspectiva, lo que aquí se plantea sería suficiente para abordar la primera arista del problema. En relación a la segunda perspectiva, existen hoy en día mecanismos que permiten controlar los procesos relacionados con los cambios en las arquitecturas definidas, una de esas alternativas es lo definido por SOA Governance. Esto corresponde a la definición de un conjunto de directrices que buscan guiar la construcción de los servicios y el despliegue de una arquitectura orientada al paradigma SOA. El objetivo principal de SOA Governance, es conseguir el máximo rendimiento de la arquitectura a través de la incorporación de políticas que guíen la construcción. Para lograr esto, se deben tomar medidas como definir las políticas que se desea aplicar, aplicar las políticas en tiempo de diseño y finalmente, supervisar y hacer cumplir las políticas en tiempo de ejecución [3]. A través de un mecanismo como este, se podría eventualmente establecer una definición de todas las reglas necesarias para controlar los desarrollos realizados y además mejorar el seguimiento de los cambios y organizar la forma en como se realizan las mantenciones, lo que permitiría mejorar el proceso en términos generales; sin embargo, los problemas presentados no estarían del todo resueltos, ya que más allá mejorar, controlar y medir lo que se está desarrollando, se necesita una metodología aún más integral, que aborde además temas como facilitar las tareas de análisis y la medición del impacto de las mantenciones, determinar cuáles son las variaciones que presentan los componentes (problema de los parámetros de configuración funcional), determinar cuáles son componentes comunes y cuáles son específicos y además poder potenciar la reutilización como uno de los principales objetivos para mejorar la productividad. A partir de lo anterior, surge la necesidad de incorporar algún tipo estrategia que permita atender el problema en términos integrales y que además considere la situación del sistema, que corresponde a una plataforma única que es utilizada por diversos corredores que solicitan cambios específicos. Como respuesta a esta situación, han comenzado a tomar forma las prácticas y las metodologías descritas por la definición de las Software Product Line (SPL). Se define a SPL, como un conjunto de sistemas de software que comparten un conjunto común de características (features), las cuales satisfacen las necesidades específicas de un dominio o segmento particular de mercado y que se desarrollan a partir de

4 un sistema común de activos base (core-assets) de una manera preestablecida [4]. El enfoque que proponen las SPL, está orientado a la gestión de los elementos comunes y sus complementarios variables. La reutilización en este enfoque no se basa en la oportunidad de reutilizar una funcionalidad, sino que esto se gestiona planificadamente. La incorporación de cambios en el sistema, se realiza sistemática y controladamente; esto no solo agiliza el desarrollo de nuevas funcionalidades, sino que además el mantenimiento se ve directamente beneficiado. Al realizar un desarrollo considerando el enfoque propuesto por SPL, se realizan dos actividades principales: ingeniería de dominio e ingeniería de aplicación. De acuerdo a lo definido por los autores, en la ingeniería de dominio se construyen los activos del núcleo (core-assets), se definen alcances y características dentro del mercado objetivo y se realiza la definición del mecanismo de control de variabilidad; para el caso de la ingeniería de la aplicación o producto, se toman como entrada los activos del núcleo creados en la actividad anterior y se lleva a cabo el desarrollo asociado a requisitos específicos de los clientes. Estas dos actividades se realizan en paralelo y se retroalimenta entre sí. El siguiente diagrama ilustra el flujo anteriormente descrito: Figura. 1. Flujo de desarrollo de proyectos utilizando el enfoque SPL. El proceso de desarrollo de una SPL, involucra la gestión de los puntos de variación entre los distintos miembros de la línea de productos; cuando se realiza esto, se deben identificar los aspectos comunes (commonalities) y los variables (variabilities) del dominio en que se encuentre el producto en cuestión; ambas poseen la misma importancia y deben ser consideradas para lograr los objetivos que se plantean [5]. Para poder modelar lo anterior, existen diversas técnicas muy relacionadas a la utilización de elementos gráficos que permiten representar los aspectos variables de los productos y también la variabilidad que presentan las piezas que los conforman. Un ejemplo de estas técnicas hallada en la literatura, es el framework COVAMOF [6]. Este es un framework que modela la variabilidad en términos de puntos de variación (variation points) y dependencias (depedencies) en diferentes niveles de abstracción. En esta propuesta, la jerarquía de la línea de producto software es modelada en tres niveles de abstracción: características (features), arquitectura (architecture) e implementación (component implementation) Los artefactos gráficos utilizados por este framework, pueden ser vistos en la siguiente imagen: Figura. 2. Artefactos utilizados por COVAMOF IV. PROPUESTA DE SOLUCIÓN En el estado del arte descrito anteriormente, se trataron dos aspectos fundamentales que resuelven de cierta forma los problemas acá representados. Por una parte, una arquitectura de sistema enfocada en el paradigma SOA, resuelve los problemas técnicos que afectan las mantenciones y por otra parte las definiciones de las Software Product Line atienden la problemática de la gestión y administración de la variabilidad, un aspecto relevante que debe estar considerado en el nuevo modelo propuesto. Considerar estos dos aspectos en términos integrales conlleva a ampliar el alcance de la gestión de la variabilidad no solo a nivel de componentes de software; sino que a niveles estructurales y de procesos de negocios, los cuales también se ven afectados por solicitudes de cambios específicas. Como propuesta de solución definitiva al problema aquí descrito, se propone reorganizar y reestructurar el sistema en términos globales enfocando los esfuerzo en lograr una arquitectura orientada al paradigma SOA. Para hacer esto, es necesario fijar una estrategia para abordar la migración gradualmente, partiendo por las funcionalidades más utilizadas y que se ven más sujetas a modificaciones producto de las mantenciones. Como parte del proceso de definición y de reorganización del software, se deberá considerar la utilización metodológica de los planteamiento de las SPL, fijando como parte de los procesos de desarrollo las actividades de ingeniería de dominio y la ingeniería de aplicación. A través de este complemento de una arquitectura que entregue condiciones para mejorar la mantención y además un proceso orientado a la producción de piezas de software donde se considere la variabilidad como un elemento fundamental, donde se pueda determinar con claridad los impactos, las dependencias, las relaciones y la disgregación entre aquellos artefactos comunes de aquellos que son específicos y con ello mejorar el análisis de las piezas que se modifican. Como punto de partida para la propuesta de solución, se define la siguiente distribución de componentes desplegados utilizando los habilitadores indicados en el estado del arte.

5 Figura. 3. Ejemplo de modelo de variabilidad para teléfono móvil. Como se puede ver en el diagrama anterior, la propuesta de este documento para la arquitectura del Sistema de Gestión de Corredoras, se concentra en la centralización y el despliegue horizontal de las funcionalidades del sistema. En este enfoque horizontal, las funcionalidades actuales deben ser transformadas en servicios reutilizables tomando en cuenta la relación existente con los procesos de negocio. El despliegue horizontal de los servicios, considera todas las plataformas, ubicando los servicios que conforman cada una de ellas a un mismo nivel, haciendo una separación entre esta capa de servicios y las aplicaciones que los consumen. Considerando las capas del modelo, la primera de ellas está conformada por los servicios identificados; desplegados, como se indicó anteriormente, de manera horizontal. Sobre dicha capa, se ubica un entorno ESB que tiene como objetivo centralizar la disponibilidad de los servicios, transparentando el origen de cada uno de ellos. Por sobre la capa del ESB, se ubica una capa de orquestación de los servicios a través de una herramienta Business Process Management Suite (BPMS). Estas herramientas son plataformas que permiten la administración, organización, medición y catalogación de procesos de negocio los cuales consumen los servicios a través de un modelo orquestado de workflows. En cada uno de estos workflows, se definen las actividades de negocio que representan, siendo integrados a los servicios que satisfacen su funcionalidad a través del ESB. Finalmente, en la parte superior se encuentra la capa de presentación del sistema, la cual estará de acuerdo a los alcances del sistema actual. Como parte de la propuesta de esta arquitectura y en consideración con el costo que significa cambiar las interfaces, se propone mantener las interfaces actuales y hacer los cambios necesarios manteniendo el funcionamiento en la capa de presentación, la cual puede ser migrada si así se necesita en instancias posteriores. Dada las características del modelo de arquitectura planteado, donde el despliegue horizontal de servicios reutilizables es un eje central en el esquema propuesto, existen las condiciones apropiadas para agregar una nueva dimensión en este modelo, lo que se puede traducir en la incorporación sistemática del control y la gestión de la variabilidad a través del framework considerado en el análisis (COVAMOF), el cual incorpora los artefactos necesarios para modelar gráficamente la variabilidad y además agregar las vistas necesarias para realizar la gestión sobre ella (variación y dependencias). Esta nueva dimensión, tendría como objetivo organizar la variabilidad de los servicios utilizando los principios asociados a las SPL detallados en los puntos anteriores. Uno de los aspectos fundamentales que se ha señalado, es la definición y determinación de los core-assets, lo que puede ser perfectamente aplicable al momento de definir la nueva arquitectura del sistema SGC, considerando además las variabilidades asociadas a las solicitudes que realizan los clientes. Al enfocar los esfuerzos considerando el complemento de ambas estrategias (SOA Y SPL), surge la necesidad de incorporar nuevas prácticas en todo el proceso de desarrollo, no solamente en el diseño de la arquitectura que se ha revisado en este documento. Esta nueva dimensión involucra prácticas a todo nivel, desde el análisis hasta la implementación y puesta en producción y tomando en cuenta las actividades. Para poder lograr lo anterior, se propone la incorporación, como actividad formal para arquitectos e ingenieros de software, la realización de las tareas de ingeniería de dominio e ingeniería de aplicación que ya fueron mencionadas y que se detallan en el estado del arte. La determinación de servicios puede tomar 2 estrategias principales: top-down y bottom-up [7]; en dichas estrategias sería necesario agregar la consideración de los puntos de variación (variation points), lo que eventualmente pueden derivar en la determinación de nuevos servicios u otro tipo de artefacto dentro de la arquitectura. En otras palabras, un punto de variación en un componente asociado a solicitudes específicas de un cliente (el ejemplo ya dado de lógicas condicionadas por parámetros), se puede traducir en uno o más componentes o servicios independientes, gestionados en la arquitectura como un artefacto más. Para que este tipo de separaciones, no sea un problema y sea un beneficio, es necesario que se modelen a través de los artefactos del framework para de este modo instaurar estos modelos como parte de la arquitectura misma y de los procesos asociados. Dicha gestión de variabilidad, no solamente es aplicable a los servicios, sino que además puede ser aplicada a todas las capas de la arquitectura propuesta. Para el caso de la capa de orquestación, es muy beneficioso poder gestionar correctamente los workflows que son solicitados a medida o que se desarrollan como parte de un nuevo producto. De la misma forma en que existen lógicas de negocio condicionadas por parámetros, si no se resuelve la variabilidad existente, esto también estaría presente en los workflows y en la orquestación, ya que también existirían situaciones similares donde un parámetro, creado para una corredora específica o por un producto en particular, incorpore nuevos elementos en el flujo. Al incorporar la gestión de la variabilidad, este tipo de situaciones podría también traducirse en la separación de 2 flujos distintos; lo que es perfectamente factible gracias a herramientas como las BPMS, donde los workflows también son artefactos de software y se pueden gestionar como tal. El siguiente diagrama ilustra el complemento propuesto y la relación de los artefactos del framework COVAMOF y la arquitectura SOA antes definida.

6 Figura. 4. Objetivo final de la arquitectura utilizando SOA apoyado por las vistas propuestas por COVAMOF. Como se puede ver en la imagen, el framework COVAMOF provee las vistas necesarias para considerar la variabilidad y la definición de las características como otro elemento a gestionar, donde los involucrados pueden tener una fuente de información importante para toma de decisiones sobre el diseño de componentes, sobre las nuevas implementaciones y al realizar cualquier tipo de cambio. Estas vistas entregan información que el día de hoy no se tiene y que los desarrolladores son responsables de determinar, con los riesgos que ello implica. La aplicación de lo anterior es conducente, si se aplica en buenos términos, al logro de los objetivos definidos. Cabe mencionar que la implementación de los modelos de variabilidad puede ser automatizada a través de alguna herramienta que permita mantener una trazabilidad entre los artefactos del software y su modelo de variabilidad y de esta forma apoyar todos los procesos asociados, como el desarrollo, la mantención, las pruebas y las actividades del configuration manager, por dar algunos ejemplos. Al contar con esta vista automatizada, podría representar un metamodelo muy potente para efectos de validación y principalmente para controlar impactos de los cambios, reutilización y favorecer directamente la mantenibilidad del sistema. V. PROPUESTA DE VALIDACIÓN La aplicación del modelo propuesto tiene como principal objetivo mejorar la mantenibilidad del sistema. Como ya se mencionó, la realización de cambios y la inclusión de nuevas funcionalidades, es una tarea muy difícil en la situación actual. Considerando la mantenibilidad como principal variable a medir para validar este nuevo modelo, se utilizará la definición realizada por la ISO [8] donde se establecen los distintos atributos de calidad que influyen en la mantenibilidad de la plataforma. Los atributos señalados son la modularidad, que representa el grado en que un sistema o programa se compone de componentes que al ser modificado no generan impacto en otros componentes; la reusabilidad, que representa el grado en que un activo puede ser utilizado en más de un sistema de software; la analizabilidad, que representa la facilidad para analizar el software en busca de deficiencias e identificar sus componentes; la capacidad de cambio, la cual responde a la capacidad y facilidad para realizar cambios en el software; la estabilidad, capacidad para evitar efectos inesperados tras realizar modificaciones en el software y la capacidad de pruebas, que representa la capacidad para validar los cambios de software y finalmente el cumplimiento de mantenibilidad que significa el grado en que el producto de software se adhiere a las normas o convenciones relacionadas con la mantenibilidad. Estos atributos se pueden revisar aplicando mediciones sobre las características internas y externas del sistemas que se retroalimentan entre si. Para poder validar el modelo propuesto, se hizo una simulación de implementación del nuevo modelo utilizando uno de los módulos más importantes del sistema el cual es utilizado para la realización de operaciones de compra y venta de instrumentos de renta variable, como Acciones, CFI, ETF entre otros instrumentos. Este módulo es uno de lo más utilizados y modificados, está conformado principalmente por una plataforma web que permite el ingreso de las operaciones y por un módulo de back-office que se encarga de recibir estas operaciones y realizar todos los procesos que la materializan, como facturación, movimientos de custodia de instrumento, tesorería, centralización contable, entre otras funcionalidades. El despliegue general de la arquitectura actual del sistema para este módulo es el siguiente: Sistema de Gestión de Corredoras (SGC) ALFA (Front-End) Capa de Presentación obtenerordenes cantarorden cambiarestado enviarnego obtenerpalos asignar Base de Datos BETA (Back-End) «interfaz» Visual Basic Servlet (Java) +ingresarorden() +validarorden() +aprobarrechazarorden() Servidor COBOL (1) +generarfactura() +generarabonocargo() RentaVariableService (Java) +ingresarorden() +validarorden() +aprobarrechazarorden() Servidor COBOL (2) +facturarasignación() +ingrettitulo() Capa de Negocio «interfaz» Visual Basic Figura. 5. Arquitectura Actual del Sistema de Gestión de Corredoras para el módulo de Renta Variable. Como se puede ver en la Figura 6, existe un Front-End que representa el sistema Web implementado en JAVA donde existen rutinas para realizar las operaciones, habiendo un método genérico para realizar las operaciones tanto de Acciones como de los otros instrumentos mencionados, como ETF y CFI, que constituyen sub-mercados de renta variable donde hay diferencias de negocio y diferencias al ingreso de la operación. Este sistema utiliza procedimientos almacenados para ingresar los datos a la base de datos donde son consumidos por programas COBOL y visualizados a través de controles Visual Basic que permiten la operación del backoffice. Al igual que en el sistema Web, estos COBOL tienen métodos genéricos que agrupan a todos los sub-mercados. La agrupación señalada es consecuencia de incorporaciones de sub-mercados en distintas instancias del tiempo y para distintos clientes, aplicando la lógica de los parámetros de configuración ya mencionada extensamente en los puntos anteriores del documento. Considerando las definiciones realizadas sobre la manera en que será abordada la integración de la arquitectura SOA complementada por los modelos y vistas definidas por el framework COVAMOF, se define el siguiente modelo como resultado:

7 TABLA I. ATRIBUTOS DE CALIDAD ASOCIADO A LA MANTENIBILIDAD. Figura. 6. Modelo de arquitectura propuesto para el sistema. En el diagrama anterior, se puede apreciar el despliegue de los componentes considerando las nuevas definiciones de distribución de acuerdo a lo propuesto por la nueva arquitectura. Los componentes de negocio fueron ubicados a un mismo nivel horizontal, entregando sus funcionalidades como servicios a través del ESB y por sobre la capa del ESB, la orquestación de procesos de negocio a través de una herramienta BPMS. Para el caso de los COBOL, se realizó la refactorización separando las funcionalidades en componentes distintos que puedan ser reutilizados. Si ocurre un cambio en el sistema, se modificarán componentes distintos, sin afectar las funcionalidades entre sí. Del Front-End y el Back-End, se mantuvo la capa de presentación y todas sus funcionalidades de negocio fueron extraídas y luego transformadas en servicios. Como ya se señaló, este modelo de arquitectura debe ser afectado por cambios realizando las actividades de ingeniería de dominio e ingeniería de aplicación y así lograr mantener las definiciones propuestas por las SPL, donde debe haber un enfoque en las versiones de los componentes y en la variabilidad que presentan. Como un ejemplo, se puede revisar el modelo de variabilidad asociado al framework COVAMOF que se presenta a continuación. Figura. 7. Capas de abstracción COVAMOF para el ingreso de órdenes de RV. Como se puede ver en el diagrama anterior, gracias a este tipo de artefactos gráficos, se puede determinar la variabilidad que puede tener un servicio o un componente en específico y con ello entregar una herramienta adicional para los desarrolladores, quienes pueden revisar esto y tener más información a la hora de realizar mantenciones. Para efectos de la aplicación de las mediciones de validación, se recurrió a expertos dentro de la organización quienes evaluaron la situación actual tomando en cuenta mediciones sobre algunas mantenciones de ejemplo y algunas medidas cuantificadas para los atributos. Atributo Medición Métrica A N Modularidad Cantidad de funcionalidades afectadas al modificar ingresaorden() y generarfactura() Conteo Absoluto 5 4 Reusabilidad Analizabilidad Capacidad de cambio Estabilidad Capacidad de pruebas Cumplimiento de mantenibilidad Cantidad de funcionalidades que pueden ser reutilizadas por otros módulos Tiempo promedio asociado en analizar los componentes cuando se agrega un nuevo submercado Tiempo promedio asociado a la realización de cambios cuando se agrega un nuevo submercado Cantidad de funcionalidades que corren riesgo cuando se modifica ingrettitulo() Tiempo promedio necesario para probar cambios en ingresaorden() y generarfactura() Nivel de cumplimiento de estándares asociados a la mantenibilidad Conteo Absoluto Tiempo en Horas Tiempo en Horas Conteo Absoluto Tiempo en Horas Nota de 1 a Como se puede ver en la tabla anterior, hay una mejora importante de los resultados obtenidos a partir de las medidas en el nuevo modelo (N) frente al modelo antiguo (A). Para la modularidad, se redujo la cantidad de funcionalidades afectadas ya que el componente COBOL que tiene la funcionalidad, fue factorizada en dos componentes distintos, lo que reduce inmediatamente el efecto; para la reusabilidad, se estableció una capa horizontal con todos los servicios desplegados, lo que aumentó prácticamente en un 100% la cantidad de funcionalidades que pueden ser reutilizadas; en el caso de la analizabilidad, el modelo COVAMOF, además de un modelo claro de relaciones y despliegue de componentes, redujo considerablemente el tiempo necesario para analizar el requerimiento solicitado y además se reduce el riesgo al entregar información sobre la variabilidad; para la capacidad de cambio, se reduce el tiempo debido a que el impacto está controlado y con ello la investigación asociada se reduce, lo que beneficia el tiempo de la actividad señalada; en la estabilidad el beneficio es directo cuando las funcionalidades se descomponen y separan, ya que al modificar un componente, solo se afecta la funcionalidad que incluye; para el atributo de la capacidad de pruebas, la modularización y el despliegue de servicios, mejora los tiempos ya que se pueden hacer pruebas específicas y las pruebas de no impacto se reducen debido a que el componente afectado no contempla más funcionalidades. Finalmente, para el cumplimiento de mantenibilidad, los expertos evaluaron el modelo en consideración con su visión y con sus necesidades de mantenibilidad estableciendo las notas que aparecen en la tabla; donde el nuevo modelo obtiene una mejor evaluación. Como conclusión de la validación realizada y proyectando en el modelo global del sistema la experiencia con el módulo considerado, se puede concluir que el nuevo modelo presenta mejores condiciones para enfrentar procesos de mantención.

8 VI. CONCLUSIONES El gran crecimiento que ha experimentado el negocio bursátil en los últimos años, ha traído consigo cambios de diversa índole en todos los niveles; desde las tecnologías, pasando por los procesos, hasta incluso las personas, todos se han visto obligados a enfrentar estos cambios, respondiendo de acuerdo a las exigencias y actuando responsablemente frente a ellas, considerando además que el negocio en cuestión es de una criticidad muy alta para diversos actores, sobre todo para los inversionistas y para el mercado nacional. En este contexto, los esfuerzos realizados deben apuntar en dirección a los inversionistas y deben ser ellos los primeros beneficiados cuando se realicen mejoras internas en las distintas dimensiones del negocio y en particular a los sistemas de información. Todos los esfuerzos que se hagan por mejorar los sistemas, deben beneficiar directa o indirectamente a los inversionistas, ahí está el principal foco de atención a la hora de planificar cambios. En consecuencia de lo anterior, se planteó esta propuesta como una iniciativa que responde a las necesidades del negocio y de los inversionistas y propuso un modelo de mejoramiento de la arquitectura del sistema de gestión de corredoras, uno de los sistemas más importantes en el negocio. Luego de revisar detalladamente el alcance de este sistema y los problemas que se presentan, se generó una propuesta que tiene como principal objetivo entregar un modelo objetivo que sea capaz de interpretar y resolver los problemas. Los alineamientos generales de esta arquitectura, permiten entender las ventajas que se generan y en particular cuales deberían ser los esfuerzos necesarios para poder lograr el cumplimiento de los objetivos. De lograr dichos objetivos, el principal beneficiado será el inversionista, quien va a recibir una mejor atención y además podrá contar con nuevos productos para participar en el mercado a través de los sistemas. En la actualidad, producto de los errores en el sistema y otros problemas descritos, el inversionista se ve muy afectado, incluso más que los mismos corredores, ya que hay negocios que se frenan y procesos que se retrasan cuando la operación del sistema falla, es por esto que las mejoras necesarias para la arquitectura y para el proceso de mantención son tan importantes, les permitirá a los responsables del sistema un nuevo enfoque que facilite su trabajo y que además reduzca la posibilidad de que generen impactos negativos en las aplicaciones. El día de hoy, producto del despliegue de los componentes, ocurre situaciones que generan gran malestar en desarrolladores, jefes de proyectos y diversos actores que mantienen el sistema; ya que la distribución de los componentes no es la más adecuada para el nivel de funcionalidades que hoy existen; gracias a esta nueva arquitectura hay beneficio para gran parte de los actores y sin duda favorecerá el trabajo que cada uno de estos realiza. Además de los aspectos de arquitectura y despliegue de componentes, en este trabajo se incorporó un concepto que no suele aparecer en relación con las arquitecturas orientadas a SOA, en lo que se refiere al enfoque en la generación de líneas Software Product Line, que para el caso del SGC, representa una muy buena manera de poder resolver el problema de variabilidad que presenta el sistema. El impacto que generan los innumerables cambios que solicitan las corredoras de bolsa a medida de su propio negocio, no había sido considerado como tema por resolver. A lo largo del tiempo, las malas prácticas asociadas a la programación de estos cambios, ha generado grandes problemas. El enfoque revisado, considera esta situación y además entrega las herramientas necesarias para que los involucrados puedan hacer mejor su trabajo y también puedan contar con más información que les permita tomar decisiones cuando dichos cambios son solicitados. Otro punto muy importante, es la visión holística que entrega este enfoque, complementa de manera muy correcta la definición de la arquitectura entregando una nueva dimensión, lo que permite ver de mejor manera los elementos del sistema y la relación que tienen entre ellos; gracias a esto, actividades como el análisis de impacto y las pruebas que se realizan, se ven muy beneficiadas incluso reduciendo sus costos, una de las variables que todas las organizaciones buscan reducir. Además de ser una definición acotada a la realidad de este sistema, el modelo planteado es reutilizable en otros contextos de similares características; no son pocas las organizaciones que enfrentan problemas similares con los sistemas que entregan como servicios y sería muy beneficioso para ellos poder agregar esta dimensión que aclara y resuelve el profundo y difícil problema de la variabilidad de artefactos del software. RFERENCIAS [1] Earl, Thomas - SOA: principles of service design. United States: Ediciones Prentice Hall, ISBN: [2] Len Bass, Paul Clements, Rick Kazman - Software Architecture in Practice, Second Edition. Ediciones Addison-Wesley, ISBN: [3] Jos Dirksen - SOA Governance in Action Rest And Ws-* Architectures. United States, Ediciones Manning Shelter Island, ISBN: [4] P. Clements, L. Northrop - Software Product Lines: Practices and Patterns. United States, Ediciones Addison-Wesley Professional; 3rd edition, Agosto, ISBN-10: [5] Frank J. van der Linden, Klaus Schmid, and Eelco Rommes Software Product Lines in Action. The Best Industrial Practice in Product Line Engineering. Ediciones Springer Verlag, ISBN [6] Marco Sinnema, Sybren Deelstra, Jos Nijhuis, and Jan Bosch. - COVAMOF: A framework for modeling variability in software product families. In Proceedings of the Third International Software Product Lines Confe-rence (SPLC 2004), Ediciones Springer Verlag Lecture Notes in Computer Science (LNCS 3154), [7] Philip Wik - Effective Top-Down SOA Management In An Efficient Bottom-Up Agile World. Published: April 8, 2010 SOA Magazine Issue XXXVIII. Consultado: Marzo, Disponible en: [8] ISO , Software engineering-software product Quality. Requirements and Evaluation (SQuaRE)Quality model.

Carlos Santander Vega Jefe de Proyectos Bolsa de Comercio de Santiago. Santiago, Chile csantander@bolsadesantiago.com

Carlos Santander Vega Jefe de Proyectos Bolsa de Comercio de Santiago. Santiago, Chile csantander@bolsadesantiago.com Combinando enfoques de SOA con el concepto de gestión de variabilidad de SPL, para mejorar la mantenibilidad de sistemas transaccionales de corredoras de bolsa. Carlos Santander Vega Jefe de Proyectos

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

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

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

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

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

SOA Governance. (Administración SOA) Luis Alberto Espinoza Bustamante

SOA Governance. (Administración SOA) Luis Alberto Espinoza Bustamante SOA Governance (Administración SOA) Luis Alberto Espinoza Bustamante 1 Agenda SOA Governance Algunas Problemas por Falta de Governance Quien: SOA Office (y Centro Competencia SOA) Que: Plan Inicial Como:

Más detalles

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 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 4 Introducción 4 Qué

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

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

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

Desarrollo de Software con enfoque en el Negocio

Desarrollo de Software con enfoque en el Negocio Desarrollo de Software con enfoque en el Negocio Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 11300, Montevideo, Uruguay adelgado@fing.edu.uy Resumen Las Organizaciones

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

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) Nelson Beltran Galvis Grupo de Investigación de Ingeniería de Software, Universidad Francisco de Paula Santander.

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

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

Diseño de Procesos al Servicio de la Gestión

Diseño de Procesos al Servicio de la Gestión Gestión y servicios Tecnológicos Ltda. Diseño de Procesos al Servicio de la Gestión www.gyst.cl info@gyst.cl Gestión y servicios Tecnológicos Ltda. En Algunas Empresas... En numerosos proyectos de variada

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

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio BPM Business Process Management Gestión de Procesos de Negocio Palabras Clave: BPM, Business Process Management, Workflow, Gestión de Procesos de Negocio, Reingeniería de Procesos, Optimización de Procesos,

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

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

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

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

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

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Trabajo de compilación bibliográfica Auditoria sistemas. Fernando Salazar Soto 1700421335. BPM "Business Process Management"

Trabajo de compilación bibliográfica Auditoria sistemas. Fernando Salazar Soto 1700421335. BPM Business Process Management Trabajo de compilación bibliográfica Auditoria sistemas Fernando Salazar Soto 1700421335 BPM "Business Process Management" Universidad De Caladas Facultad de Ingeniería Ingeniería de sistemas y computación

Más detalles

Estrategia de modernización de aplicaciones Oracle Forms y Reports

Estrategia de modernización de aplicaciones Oracle Forms y Reports Abril 2014 Mariana Contardi Experta en de aplicaciones de Oracle Forms en atsistemas Estrategia de de aplicaciones Muchos clientes se plantean la pregunta de qué hacer con las aplicaciones Forms y que

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

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

Creando Arquitecturas

Creando Arquitecturas Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras

Más detalles

La relación entre Service Oriented Architecture (SOA) y los procesos comerciales. Por Greg Holden, Escritor de Tecnologia

La relación entre Service Oriented Architecture (SOA) y los procesos comerciales. Por Greg Holden, Escritor de Tecnologia La relación entre Service Oriented Architecture (SOA) y los procesos comerciales Por Greg Holden, Escritor de Tecnologia 2 La relación entre SOA y los procesos comerciales Quienes hayan tenido la posibilidad

Más detalles

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM Metodología BPM:RAD - Rapid Analysis & Design Capítulo extraído de El Libro del BPM 2011 Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Más detalles

Medidas a tomar hacia una tramitación electrónica confiable. Asegurando globalmente la Calidad. Dirección General de Tráfico. Ministerio del Interior

Medidas a tomar hacia una tramitación electrónica confiable. Asegurando globalmente la Calidad. Dirección General de Tráfico. Ministerio del Interior Medidas a tomar hacia una tramitación electrónica confiable. Asegurando globalmente la Calidad. Dirección General de Tráfico. Ministerio del Interior DATOS GENERALES Antecedentes del servicio El nivel

Más detalles

Monitoreo automatizado de redes de. cajeros automáticos

Monitoreo automatizado de redes de. cajeros automáticos Monitoreo automatizado de redes de cajeros automáticos Definición Ejecutiva ATMonitor es una solución completa, integrada y flexible de monitoreo visual de una red de cajeros automáticos. Centraliza la

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

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

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

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

Planificación Estratégica de Proyectos BPM

Planificación Estratégica de Proyectos BPM Planificación Estratégica de Proyectos BPM Prof. M. Sc. Bernhard Hitpass Heyl BPM Center, Departamento de Informática Universidad Técnica Federico Santa María (Chile) Resumen Hoy en día no es común en

Más detalles

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

dmnet Arquitectura Empresarial de Procesos

dmnet Arquitectura Empresarial de Procesos dmnet Arquitectura Empresarial de Procesos 23 de mayo 2010 Que los sistemas productivos sean técnica y operacionalmente capaces de generar el valor económico proyectado es sólo una condición necesaria.

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Comparación del entorno IBM Websphere BPM y sus equivalentes funcionales en código fuente abierto.

Comparación del entorno IBM Websphere BPM y sus equivalentes funcionales en código fuente abierto. Comparación del entorno IBM Websphere BPM y sus equivalentes funcionales en código fuente abierto. 2 José Martinez Garro 1 Patricia Bazán 2 Emilio Lorenzón 1 LINTI Facultad de Informática UNLP 2 Facultad

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK 1 LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK Miguel Angel Abellán Juliá Gerente de Soluciones para Administraciones Públicas. Hewlett-Packard Española,

Más detalles

Business Process Management(BPM)

Business Process Management(BPM) Universidad Inca Garcilaso de la Vega CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO Business Process Management(BPM) MSc. Daniel Alejandro Yucra Sotomayor E-mail: daniel@agenciati.com

Más detalles

Consideraciones para implementaciones BPM y EDA

Consideraciones para implementaciones BPM y EDA Consideraciones para implementaciones BPM y EDA Jesús Buriticá IBM Software Group Brand Architect jburitic@ve.ibm.com Agenda Manejando los conceptos sobre BPM y EDA Abordar una iniciativa BPM/EDA Algunos

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

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

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de

Más detalles

Jaime Orlando Moreno, Jorge Humberto Arias Cámara de Comercio de Bogota {jaimem,arquitectodes}@ccb.org.co

Jaime Orlando Moreno, Jorge Humberto Arias Cámara de Comercio de Bogota {jaimem,arquitectodes}@ccb.org.co Caso de Estudio: Proyecto SIREP2 Estructura, rol e importancia de un ESB en un proyecto Empresarial centrado en procesos de negocio (BPM) y soportados en reusabilidad de Servicios (SOA) Jaime Orlando Moreno,

Más detalles

Aproveche todo el potencial de las aplicaciones Java virtualizadas

Aproveche todo el potencial de las aplicaciones Java virtualizadas Documento técnico de Oracle Abril de 2011 Aproveche todo el potencial de las aplicaciones Java virtualizadas Oracle WebLogic Server Virtual Edition Oracle Virtual Assembly Builder Oracle WebLogic Server

Más detalles

VISUAL SALE, EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO

VISUAL SALE, EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO , EL SOFTWARE DE VENTAS MÁS INNOVADOR DEL MERCADO Olvídese de CRM para la fuerza de ventas y utilice una herramienta desarrollada por Vendedores para Vendedores. Visual Sale nace como la respuesta a la

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

Análisis de tecnologías para implementar un marco integrador de SOA y BPM

Análisis de tecnologías para implementar un marco integrador de SOA y BPM Análisis de tecnologías para implementar un marco integrador de SOA y BPM Patricia Bazán 1, Roxana Giandini 2, F.Javier Diaz 1, 1 LINTI Facultad de Informática- UNLP La Plata (1900) Buenos Aires, Argentina

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Introducción a BPM. Programa BPM Business Process Management. Al finalizar el capítulo, el alumno podrá:

Introducción a BPM. Programa BPM Business Process Management. Al finalizar el capítulo, el alumno podrá: Introducción a BPM Al finalizar el capítulo, el alumno podrá: Comprender la importancia de la Gestión de Procesos y la mejora continua de los mismos. Identificar los diferentes procesos existentes en una

Más detalles

LA IMPORTANCIA DE SOA

LA IMPORTANCIA DE SOA LA IMPORTANCIA DE SOA En el mundo de negocios de ahora, la habilidad de adaptar la infraestructura de tecnología de información de manera rápida, es imperativa. Muchos están tomando la decisión de invertir

Más detalles

Anuncio de software ZP10-0336 de IBM Europe, Middle East and Africa con fecha 14 de septiembre de 2010

Anuncio de software ZP10-0336 de IBM Europe, Middle East and Africa con fecha 14 de septiembre de 2010 con fecha 14 de septiembre de 2010 IBM Rational System Architect V11.4: saca partido a las nuevas integraciones con Gestión de activos y Operaciones de TI, y cumple con los estándares DoDAF V2.0 y BPMN

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

Especificación de requisitos para servicios cloud dirigido por valor

Especificación de requisitos para servicios cloud dirigido por valor Escola Tècnica Superior d Enginyeria Informàtica Universitat Politècnica de València Especificación de requisitos para servicios cloud dirigido por valor Trabajo Fin de Grado Grado en Ingeniería Informática

Más detalles

Presentación Comercial IXAYA Crédito

Presentación Comercial IXAYA Crédito Presentación Comercial IXAYA Crédito Versión: 2.0.1 Fecha: 21/04/2014 Elaboró: División Consultoría Contenido 1. Descripción de la solución....3 1.1. Beneficios....4 1.2. Modelo operativo....5 1.3. Arquitectura

Más detalles

Diseño e Implementación de los Procesos de Gestión TI

Diseño e Implementación de los Procesos de Gestión TI Diseño e Implementación de los Procesos de Gestión TI Alumno(s): Año Académico: 2012 Profesor Guía: Contraparte: ALEJANDRO JESUS ARAVENA ORTIZ LORENA ANDREA ALBORNOZ POBLETE DANIEL HORMAZABAL Escuela de

Más detalles

La Intranet Gubernamental como elemento clave de la Interoperabilidad

La Intranet Gubernamental como elemento clave de la Interoperabilidad La Intranet Gubernamental como elemento clave de la Interoperabilidad Créditos Documento elaborado por el Ingeniero Leandro Corte En el marco del proyecto Red Gealc-BID Como parte del Programa de Bienes

Más detalles

Implantación Plataforma SOA. La experiencia del Principado de Asturias

Implantación Plataforma SOA. La experiencia del Principado de Asturias Implantación Plataforma SOA La experiencia del Principado de Asturias I. Situación inicial II. Necesidades III. Búsqueda de soluciones IV. Solución seleccionada V. Implantación I. Situación inicial La

Más detalles

Despliegue de plataforma Q-flow

Despliegue de plataforma Q-flow How to Despliegue de plataforma Q-flow Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-flow 3.0 y Q-flow 3.1 Índice Diagrama de Servicios de Q-flow... 3 Diagramas de Infraestructura de Q-flow

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Productos Oracle para gobierno de SOA. Oracle White Paper Mayo 2009

Productos Oracle para gobierno de SOA. Oracle White Paper Mayo 2009 Productos Oracle para gobierno de SOA Oracle White Paper Mayo 2009 Productos Oracle para gobierno de SOA RESUMEN EJECUTIVO La solución de Oracle SOA Governance es un elemento clave de la estrategia de

Más detalles

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización

BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización BPMS Tecnología para la Integración y Orquestación de Procesos, Sistemas y Organización Renato de Laurentiis Gianni Director IBERICA IT Group Introducción Cada vez más los Sistemas BPMS-Business Process

Más detalles

Desarrollo del enfoque de gestión por procesos en el Sistema de Aseguramiento de la Calidad de la UPCH Versión 1.0

Desarrollo del enfoque de gestión por procesos en el Sistema de Aseguramiento de la Calidad de la UPCH Versión 1.0 Desarrollo del enfoque de gestión por procesos en el Sistema de Aseguramiento de la Calidad de la UPCH Versión 1.0 Preparado por: Ing. Alberto Fernández Bringas Asesor de la DUGEC, Docente UPCH Revisado

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURA SOA Services Oriented Arquitecture SOA como arquitectura para BPM Las organizaciones deben

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO MODELO ARQUITECTURAL PARA UNA LÍNEA DE PRODUCCIÓN DE SOFTWARE QUE INTEGRA LAS INGENIERÍAS DEL DOMINIO Y APLICACIÓN USANDO InDoCaS DEYANIRETH DUARTE MARIN Barquisimeto,

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

UNIVERSIDAD DE SANTANDER UDES

UNIVERSIDAD DE SANTANDER UDES UNIVERSIDAD DE SANTANDER UDES Programa Nombre Código Facultad Administración e Ingenierias Ingenieria de Sistemas Arquitectura Orientada a Servicios (SOA) Problema? Competencia específica Rango de Aplicación

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow?

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow? Qué significa workflow? Es un término en inglés para proceso de negocio. Su uso en ese idioma se extendió para todo lo vinculado a herramientas informáticas que contribuyen a la automatización y al control

Más detalles

MÓDULO 1: FUNDAMENTOS DE BPM, GOBIERNO Y ORGANIZACIÓN POR PROCESOS

MÓDULO 1: FUNDAMENTOS DE BPM, GOBIERNO Y ORGANIZACIÓN POR PROCESOS MÓDULO 1: FUNDAMENTOS DE BPM, GOBIERNO Y ORGANIZACIÓN POR PROCESOS DIA 1 Hacia una gestión eficaz de la Organización Negocio: Funciones Procesos vs. Funciones de Negocio Tipos de Proceso: Principal, Soporte,

Más detalles

CA Automation Suite for Hybrid Clouds

CA Automation Suite for Hybrid Clouds HOJA DEL PRODUCTO: For Hybrid Clouds for Hybrid Clouds for Hybrid Clouds está diseñada para aumentar la agilidad y la eficacia, de forma que pueda hacer lo siguiente: Sobrellevar las ráfagas de demanda

Más detalles

COBIT 5. Niveles de Capacidad Desafío de formalización de procesos Costos y Beneficios. A/P Cristina Borrazás, CISA, CRISC, PMP

COBIT 5. Niveles de Capacidad Desafío de formalización de procesos Costos y Beneficios. A/P Cristina Borrazás, CISA, CRISC, PMP COBIT 5. Niveles de Capacidad Desafío de formalización de procesos Costos y Beneficios A/P Cristina Borrazás, CISA, CRISC, PMP AGENDA Presentación del tema Contextualización Cobit 5 Gestión de la Documentación

Más detalles

SOA: MITOS, VERDADES Y TENDENCIAS CARLOS MARIO CARMONA RAMÍREZ WIDER FARID SÁNCHEZ GARZÓN

SOA: MITOS, VERDADES Y TENDENCIAS CARLOS MARIO CARMONA RAMÍREZ WIDER FARID SÁNCHEZ GARZÓN SOA: MITOS, VERDADES Y TENDENCIAS CARLOS MARIO CARMONA RAMÍREZ WIDER FARID SÁNCHEZ GARZÓN UNIVERSIDAD DE MEDELLÍN FACULTAD DE INGENERÍA ESPECIALIZACIÓN INGENIERÍA DE SOFTWARE MEDELLÍN 2011 1 SOA: MITOS,

Más detalles

TÉRMINOS DE REFERENCIA

TÉRMINOS DE REFERENCIA Programa para la Consolidación de la Gestión Fiscal y Municipal Crédito BID-2032/BL-HO Componente III: CONCLUSIÓN Y SOSTENIBILIDAD DEL SIAFI TÉRMINOS DE REFERENCIA CONTRATACION DE FIRMA CONSULTORA PARA

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Cómo aumentar la agilidad de su

Cómo aumentar la agilidad de su Cómo aumentar la agilidad de su negocio? Alberto Bravo Business Integration Tiger Team abravo@mx1.ibm.com Agenda Retos de las Empresas Iniciativas Recomendadas Plataforma de Agilidad e Integración Bus

Más detalles

Introducción: Qué se entiende por una arquitectura SOA? Bernhard Hitpass

Introducción: Qué se entiende por una arquitectura SOA? Bernhard Hitpass 5to Encuentro 29-10-14 Agenda Charla del 5to Encuentro Introducción: Qué se entiende por una arquitectura SOA? Bernhard Hitpass Charla: Roadmap de un Proyecto BPMN con Arquitectura SOA Aspectos a Considerar

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

Resumen Ejecutivo EMERGYS MÉXICO

Resumen Ejecutivo EMERGYS MÉXICO Resumen Ejecutivo EMERGYS MÉXICO Acerca de Emergys Resumen Ejecutivo EMERGYS México es una empresa líder en soluciones de negocios basadas en tecnologías de información. Inicio de operaciones en 2003 Subsidiaria

Más detalles