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

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.