ARTÍCULOS

DOI: 10.22395/rium.v15n28a5

Modelo de requisitos para la renovación tecnológica de los sistemas de administración del mercado de energía en Colombia

Model of requirements for technological renewal of energy market management systems in Colombia

Miguel Ángel Cañas C.^*; Ángela María Bedoya Ramírez^**; Lilliam Urrego Agudelo^***

^* MSc, Analista Arquitectura Tecnología, Dirección Arquitectura y Operación de Tecnología. XM S. A. ESP, Medellín, Colombia. Email: macanas@xm.com.co

^** Ing., Analista Soluciones, Dirección Soluciones de Información. XM S.A. ESP, Medellín, Colombia. Email: abedoya@xm.com.co

^*** PhD (c), Especialista Estrategia y Riesgos, Vicepresidencia EstrategiaXM S. A. ESP, Medellín, Colombia. Email: liurrego@xm.com.co

Recibido: 02/07/2015

Aceptado: 11/12/2015

RESUMEN

En el marco de la renovación tecnológica de los sistemas que soportan la administración del mercado de electricidad en Colombia, se desarrolla un nuevo modelo de requisitos que aborda en detalle el modelado de los procesos, junto con la especificación de software. El nuevo modelo determina lineamientos para usar los estándares BPMN y UML, y se apoya en la experiencia de la compañía en los procesos de administración del mercado. Este artículo presenta los resultados encontrados al aplicar el nuevo modelo de requisitos, que busca la captura del conocimiento del proceso de administrar mercados, la representación formal de los procesos, mejorar la trazabilidad entre la especificación de los sistemas y el proceso y unificar el entendimiento de los procesos de los diferentes stakeholders involucrados. Este artículo presenta los resultados de la aplicación del modelo enmarcado en la renovación tecnológica dentro del proyecto Colciencias CNBT 833559938649 de investigación tecnológica, sistema para la administración del mercado de energía eléctrica en Colombia, Fase I.

PALABRAS CLAVE

renovación tecnológica, mercados de energía, BPMN, UML, sistemas de administración de mercados.

ABSTRACT

With the purpose of conducting a technological renewal of the systems that support the energy market management in Colombia, a new model of requirements addressing in detail the modeling of processes, together with software specifications, has been developed. The new model provides relevant guidelines to use GMPN and UML standards and is supported by the company's experience in market management processes. This article shows the results found after applying the new model of requirements intended to gain knowledge on market management process, formal representation of processes, improvement of traceability between system specifications and the process, and standardization of the understanding of processes by several stakeholders involved. This article further exhibits the results from the application of the model based on the technological renewal within the COLCIENCIAS technological research project "CNBT 833559938649, a System for Electric Energy Market Management in Colombia, Phase I."

KEY WORDS

Technological renewal; energy markets; BPMN; UML; market management systems.

INTRODUCCIÓN

El proceso de la administración del mercado de electricidad en Colombia atiende las transacciones comerciales de aproximadamente 150 agentes, con servicios que van desde el registro de cada agente y sus contactos, el registro de las fronteras o puntos de medida de consumo de energía, la liquidación y facturación de los intercambios de energía resultantes de las transacciones entre los agentes del mercado mayorista que venden y compran en la bolsa de energía, y la liquidación de los cargos por uso de las redes de transmisión. Adicionalmente, se recauda el dinero producto de las transacciones en bolsa, las transacciones internacionales de electricidad, los servicios por transmisión nacional y regional, y se distribuye entre los agentes participantes en el mercado mayorista y los agentes transmisores y distribuidores por el uso de sus redes.

Los mercados de energía eléctrica en el mundo continúan evolucionando gracias a la incorporación de nuevas tecnologías de información y comunicaciones, lo que se conoce como redes inteligentes (i.e. Smart Grids). Dentro de las tendencias clave a desarrollarse en los mercados de energía eléctrica cabe mencionar: transacciones de energía en tiempo real, generación distribuida, mercados integrados entre países, participación activa de la demanda (usuarios finales), mayor flujo de inversiones en energías renovables, entre otros nuevos productos y servicios en el sector, que benefician al usuario final y dan mayor confiabilidad en el suministro de la energía eléctrica [1, 2, 3, 4].

El proceso de administración del mercado de electricidad se caracteriza por una alta complejidad, la cual se genera por factores tales como: la evolución del mercado y la interacción de los agentes, un alto apalancamiento tecnológico debido a automatización de los procesos y al gran volumen de información generado por las transacciones entre agentes, y a una alta frecuencia de cambios o ajustes en las reglas de negocio debido a la dinámica regulatoria del mercado [5].

Los sistemas y plataformas tecnológicas sobre los que actualmente se gestionan las transacciones del mercado de energía en Colombia se han diseñado y desarrollado en la medida que la regulación ha exigido cambios o ha introducido nuevas reglas de negocio para la operación y administración del mercado. Tras varios años de operación se tiene que algunas de las soluciones se encuentran aisladas entre sí o con integraciones complejas, además de que han sido construidas usando diferentes tecnologías, algunas de las cuales ya no se encuentran vigentes, situación que dificulta su sostenibilidad, encarece el soporte y mantenimiento, y reduce su capacidad de respuesta ante nuevos cambios en los procesos.

El modelo actual de soporte tecnológico de los procesos mediante el cual se ha venido realizando la construcción de aplicaciones a la medida y la manera cómo estas se han evolucionado ha dejado en la organización una serie de experiencias y lecciones aprendidas que han dado la oportunidad para generar una mejora en el modelo de desarrollo y en la manera en la cual se deben realizar las evoluciones de los aplicativos. Debido a la situación anterior, XM como administrador del Mercado de Energía Mayorista (MEM) decide realizar el proyecto Sistema de Administración del Mercado (SAM) para la renovación tecnológica de los sistemas que soportan la administración del mercado.

Dentro de la renovación tecnológica se propone un modelo de requisitos que cumple con tres objetivos: el primero es capturar el conocimiento adquirido por XM durante la administración y evolución del mercado de energía; el segundo es mejorar la comunicación entre los diferentes interesados lo cual se logra a través del uso de lenguajes estándares que permiten el entendimiento del negocio de una manera más eficiente, tanto para las personas que hacen parte de los procesos como para el área de tecnología, quien finalmente es el responsable de realizar los cambios en las plataformas y soluciones que soportan dichos procesos; por último, se pretende lograr una mejora en los procesos de soporte y mantenimiento.

Este artículo presenta los resultados de la aplicación de un nuevo modelo de requisitos para el proceso de negocio de administrar mercados de energía en el marco de una renovación tecnológica. El artículo se divide en las siguientes secciones. En primer lugar se describe el modelo de requisitos y los lineamientos definidos en XM para documentar y modelar los procesos de negocio y las especificaciones de modelado de software. En segundo lugar se plantean los elementos que demuestran el aporte del modelo de requisitos a la renovación tecnológica. En tercer lugar se presentan los resultados de la aplicación del modelo de requisitos para finalmente presentar las conclusiones y el trabajo futuro propuesto.

1. MODELO DE REQUISITOS

El modelo de requisitos de XM [6] es un compendio de las mejores prácticas en cuanto al modelado de procesos, el levantamiento de requisitos, la recolección de información y la definición de los atributos de calidad. Todo esto, adaptado a las necesidades identificadas durante el desarrollo de los sistemas que actualmente soportan los procesos de la organización y teniendo en cuenta la experiencia de los diferentes proyectos ejecutados a la fecha. Basado en lo anterior el modelo de requisitos permite la gestión del conocimiento de los procesos y la actualización permanente de los mismos y se convierte en el artefacto de registro del conocimiento de la organización.

El modelo de requisitos consta de tres secciones (figura 1):

a. Modelo de proceso.

b. Modelo de casos de uso.

c. Atributos de calidad.

Para la primera sección se modela el proceso de negocio que esté dentro del alcance del proyecto. Esta sección del modelo parte de la definición de proceso como un conjunto de actividades que tienen inicio y final, así como el flujo de información que pasa por estas actividades. Se propone esta sección en el modelo porque se consideran los procesos de negocio como un activo intelectual estratégico y crítico que necesita ser entendido y gestionado de forma proactiva [7].

El modelo de proceso construido en esta sección servirá como artefacto que captura el conocimiento del negocio y, además, guiará las acciones que se realizan sobre los procesos tales como: la creación de sistemas de información que soporten de manera adecuada el negocio; la identificación e implementación de mejoras en el negocio actual; experimentación de nuevos conceptos de negocio y la medición de la eficiencia de los procesos que finalmente permitirá identificar aquellos elementos de negocio que no se consideran parte fundamental del mismo y que podrían ser delegados a un proveedor externo.

En cuanto a los lenguajes de notación disponibles, se seleccionó BPMN [8] (Business Process Model and Notation). La selección de BPMN obedece a que esta notación es un estándar diseñado específicamente para modelar procesos de negocio que proveen una notación gráfica y se basa en técnicas de flujos de datos para construir estos modelos. A diferencia de UML, BPMN está diseñado para procesos de negocio específicamente, y tiene como objetivo soportar los procesos de negocio, ya sea por las áreas de tecnología o de negocio o por ambas. BPMN es una notación intuitiva para los usuarios pero que también permite representar modelos complejos que incluyen aspectos dinámicos. BPMN está soportado por un amplio número de herramientas de modelado asistido por computador (i. e. enterprise architect [9]) y es conocido por los aliados actuales de XM que apoyan el proceso de gestión de tecnología y de gestión de procesos.

En la segunda sección del modelo de requisitos, se construye un modelo de casos de uso, propuesto por ser el más usado, pero del cual se pueden desprender modelos que representen información, datos e interacciones entre los diferentes elementos que hacen parte de la especificación de software los cuales pueden ser representados haciendo uso de cualquiera de los diagramas disponibles dentro de la notación UML (Unified modelling language), lenguaje seleccionado por ser el más usado en el entorno de los aliados con los que trabaja XM.

El uso de UML tiene como objetivo principal, proporcionar a los arquitectos de sistemas, ingenieros de software y desarrolladores de software una herramienta para el análisis, diseño e implementación de los sistemas basados en software. Este lenguaje facilita la especificación, visualización y documentación de los modelos de sistemas de software.

Hacer uso de BPMN en la dimensión de negocio y UML en las dimensiones de aplicación y datos (sistemas de información) es reforzada por [10], en donde se plantea que el uso integrado de estos estándares apalanca la obtención de resultados satisfactorios para modelar procesos e implementar nuevos sistemas de software.

Asimismo, al incluir los diagramas de casos de uso propuestos por UML, se busca especificar de manera clara, la interacción de los usuarios con los sistemas de información que vendrán a soportar los procesos de negocio.

Finalmente, a través del uso UML, se logran llenar aquellos vacíos que pueden quedar en cuanto a la especificación y definición de requisitos funcionales de un sistema en el cual su proceso fue modelado con BPMN y a través de este último, se logra construir un modelo del flujo de información, que más adelante podría llamarse una arquitectura de información preliminar que luego se convertirá en el modelo de datos de la solución.

La tercera y última sección del modelo de requisitos contiene los atributos de calidad. Los atributos de calidad son identificados entre las áreas del negocio y el área de tecnología, y son aquellas propiedades que debe cumplir la futura solución o los sistemas de información que darán soporte a los diferentes procesos de negocio.

Un atributo de calidad se define como "La propiedad de un sistema por la cual se juzgará la calidad de este por algún o algunos stakeholders. Atributos de calidad tales como el desempeño, seguridad, confiabilidad y usabilidad tienen una influencia significativa en la arquitectura del sistema" [11]. "Son los mecanismos por los cuales un sistema tiene previsto cumplir con sus objetivos de negocio. Estos requisitos deben ser reconocidos y considerados de forma temprana en el ciclo de vida, y el sistema y las arquitectura de software deben ser diseñados de tal forma que sus atributos de calidad se cumplan" [12]. Estos atributos de calidad son identificados con base en una plantilla previamente construida y son asociados a cada uno de los casos de uso que son construidos durante el modelado de los casos de uso. La construcción de esta plantilla se realizó de acuerdo con las definiciones de los atributos de calidad ofrecidas por Carnegie Mellon University [13].

2. APORTES DEL MODELO DE REQUISITOS A LA RENOVACIÓN TECNOLÓGICA

El modelo de requisitos propuesto hace su aporte a la renovación tecnológica al garantizar el cumplimiento de los tres objetivos del proyecto, los cuales consisten en capturar el conocimiento adquirido durante la evolución del mercado; lograr el entendimiento del modelo, tanto por el proceso de negocio como por las áreas de tecnología responsables de los cambios en las plataformas y soluciones; y por último mejorar los procesos de soporte y mantenimiento. Cada uno de estos puntos se explica a continuación.

La captura del conocimiento que se persigue es la relacionada con los procesos de negocio. Esta captura de conocimiento se logra durante la construcción de la primera sección del modelo de requisitos. Para construir el modelo de proceso que se tiene en XM como resultado de la administración del mercado durante más de 20 años, se han usado entrevistas y diferentes talleres de construcción de modelos. Para la construcción del modelo de procesos los participantes se ven en la necesidad de entender claramente lo que hacen en el día a día para cumplir con los procesos actuales y, para lograr este entendimiento han tenido que consultar la regulación, aclarar procesos con otros analistas y aplicar ingeniería inversa a algunas aplicaciones previamente desarrolladas con el propósito de entender cómo se estaban interpretando algunas reglas anteriormente definidas. Todo este trabajo de preparación y posterior modelado cumple con el objetivo de capturar ese conocimiento que estaba en diferentes fuentes (incluyendo la experiencia de las personas de los procesos) y que ahora queda plasmado en el modelo de proceso construido en BPMN.

La mejora en la comunicación entre los interesados se logra con el uso de la notación BPMN, que permite reducir la distancia entre los diferentes interesados en el proyecto, es decir, se convierte en el lenguaje común usado por los analistas de negocio y los analistas de tecnología. En el modelo se establecen las distintas actividades que deben realizarse durante la ejecución del proceso, así como la secuencia de tareas. Además de lo anterior se hace uso de BPMN para documentar la información que fluye entre los procesos y los distintos participantes, describiendo la lógica de los pasos dentro de un proceso de negocio.

Los resultados de los modelos de procesos de negocio son valorados por los diferentes grupos de interés: los analistas de negocio que describen los procesos que utilizan notaciones y herramientas específicas del negocio, los analistas de tecnología que implementan los sistemas de información que soportarán los procesos y los usuarios de negocio que gestionan y supervisan los procesos y que son finalmente quienes deben entender los resultados del modelado. Todos los interesados mencionados deben saber cómo leer los diagramas de proceso de negocios, pero no tienen que ser expertos en modelar procesos. Dado todo lo anterior, BPMN crea un puente estandarizado entre el diseño de procesos de negocio, la implementación de procesos, el desarrollo y la implementación de las herramientas que lo soportan.

En cuanto a la notación UML, este lenguaje permite crear un plano del sistema esperado y especificar las funcionalidades del sistema, basándose en las necesidades de negocio y en el proceso ya modelado. Para enriquecer este modelo de especificación del sistema el modelo solicita que se detallen los casos de uso. Para realizar este detalle el modelo de requisitos sugiere la reutilización de las actividades, tareas y reglas de negocio, y aumentar su alcance relacionando en ellos características de automatización y funcionales para garantizar la correcta implementación de los sistemas de información. Adicionalmente, no restringe el uso de los demás diagramas, siempre y cuando den mayor claridad en la especificación en temas como, por ejemplo, el manejo de estados de las entidades, tiempo de vida de entidades, manejo de mensajes, colaboración entre participantes y actividades, entre otros.

Finalmente, el uso de lenguajes como BPMN y UML permite que los diferentes stakeholders que participan en el proyecto entiendan, desde antes de la implementación, el proceso, el sistema y su funcionamiento, ayudando a identificar problema antes de llevarse a cabo una implementación; ayuda también a realizar de manera más ágil actualizaciones en el modelo al tratarse de lenguajes con representaciones gráficas.

La mejora esperada en los procesos de soporte y mantenimiento se relaciona directamente con la identificación de los riesgos y los impactos, tanto en los procesos de negocio como en los aplicativos que los soportan, una vez se decide realizar un cambio, ya sea por disposiciones regulatorias, por la aplicación de mejoras a los procesos o por cambios generados por el crecimiento de la compañía.

Por medio del modelo de requisitos propuesto, la identificación de dichos impactos y riesgos se hace sobre un modelo de procesos (BPMN) y sobre un modelo para la especificación del software (UML). Este modelo contiene la especificación del sistema y los procesos que son soportados, los cuales son trazados desde el modelado de procesos hasta la especificación de las funcionalidades. Esta trazabilidad solicitada dentro del modelo permite identificar claramente qué sistema o qué parte de él será impactada al momento de implementar un cambio, y con toda esta información es posible conocer los riesgos asociados a dicho cambio. Estos riesgos se determinan desde el punto de vista del negocio, de los procesos y de la tecnología lo que, a su vez, ayuda a realizar una clasificación de los mismos de acuerdo con niveles de complejidad, grados de dependencias, niveles de servicios y proveedores que podrían atender el desarrollo del cambio.

Por otro lado, al contar con el modelado de procesos, el cual contiene las actividades, tareas, reglas de negocio y los flujos de información necesarios para cumplir con el objetivo del mismo, es posible realizar una identificación más clara de aquellas situaciones que podrían afectar el flujo normal de dicho proceso al momento de implementar un cambio o una mejora. Adicionalmente, se logra determinar los efectos de dicho cambio sobre aquellos procesos con los que tenga relación el proceso impactado, bien sea por integración de actividades entre procesos o por el cambio en las características de la información o en el flujo de ella.

Se espera también una mejora en la estimación del esfuerzo de las actividades relacionadas con el soporte y mantenimiento de sistemas de información de los procesos de negocio. Lo anterior se logra al hacer uso de los diferentes artefactos planteados en el modelo de requisitos y las relaciones que existen entre ellos, las cuales se crean con el objetivo de identificar de manera precisa las funcionalidades de los sistemas de información que deben ser modificados, las reglas de negocio que deben ser cambiadas y las estructuras de información que, dado el caso, podrían ser modificadas. El planteamiento de esta hipótesis se sustenta en que actualmente los procesos de soporte y mantenimiento tienen un esfuerzo adicional en la identificación del impacto de las modificaciones en los procesos sobre los diferentes sistemas que los soportan, dado que la documentación no contiene las relaciones entre los procesos y los sistemas; algunas veces esta información es insuficiente y en otros es necesario hacer revisión del código fuente de los aplicativos.

Finalmente, además de la mejora reflejada en la estimación del impacto y de los riesgos también se pueden hacer ejercicios de validación y verificación de los procesos antes de que estos sean implementados, detectando en los requisitos posibles fallas en la ejecución del proceso. Dado que los modelos son entendidos por los analistas de tecnología, así como por los analistas de los procesos (según se plantea en la mejora en la comunicación) se logra una participación más activa del negocio en la evaluación de los impactos que pueden tener las decisiones que tomen sobre los procesos que actualmente están ejecutando, ayudados por sistemas de información. Esta participación permite brindar soluciones a problemas generados por cambios en los procesos, independientemente de la tecnología que los soporta. Para lograr esta mejora en procesos se genera la responsabilidad de mantener estos modelos actualizados con las mejoras realizadas en los procesos de soporte y mantenimiento; es necesario que los modelos de procesos y la especificación del software se actualicen permanentemente para que el documento de requisitos se sostenga vigente en el tiempo.

3. RESULTADOS DE LA APLICACIÓN DEL MODELO DE REQUISITOS

El proceso final usado para la construcción del modelo de requisitos se muestra en la figura 2.

Como se dijo en la sección 1, el modelo de requisitos consta de tres secciones:

a. Modelo de proceso

b. Modelo de casos de uso

c. Atributos de calidad.

Inicialmente el proceso para construir el documento de requisitos consistía de tres actividades que correspondían exactamente a las tres secciones que este contenía; sin embargo, con el uso de este fue necesario agregar otras actividades hasta llegar a las que se muestran en el proceso para enriquecer los modelos del documento de requisitos y poder cumplir con los objetivos propuestos dentro del proyecto de renovación tecnológica. A continuación se explican las actividades incluidas en el proceso usado para construir el documento de requisitos.

Para la primera sección, modelo de proceso, se tienen las siguientes actividades:

• Identificar stakeholders

• Elaborar diagrama de contexto

• Elaborar modelo de procesos

• Elaborar modelo de dominio

Según UML un stakeholder "Es una persona o una organización que será afectada por un proyecto: Usuario, un cliente que no está directamente usando el sistema, un sponsor, entre otros" [14]. Se define la actividad de identificación de stakeholder ya que estos sirven como base para la identificación de los carriles o contenedores dentro del modelo de BPMN y posteriormente pueden llegar a convertirse en candidatos a actores [15] dentro de UML. Incluir esta actividad asegura que se hace este ejercicio de identificación temprana la cual permite acelerar el trabajo futuro de modelado y la identificación de los roles de quienes deben participar en la construcción del documento de requisitos.

Dentro del desarrollo de este proyecto la identificación de los stakeholders en esta etapa sirvió para determinar los sistemas con los que a futuro se tendrá que integrar el sistema que soporte la automatización de los procesos dentro del alcance de SAM. La identificación de los stakeholders apoya la captura del conocimiento, ya que permite armar el grupo de trabajo que participará en la construcción del documento de requisitos.

El diagrama de contexto "refleja las entidades externas que interactúan con el sistema o proceso y los flujos (datos, información, entre otros) entre las entidades y el sistema o proceso" [16]. Esta actividad está enfocada en enriquecer el entorno del proceso a modelar dentro del alcance de la construcción del documento de requisitos. En el nivel de tecnología permite identificar los sistemas de información y los datos que serán integrados al nuevo sistema de información partiendo de una vista de negocio. Desde el punto de vista de la captura de conocimiento permitió hacer visible información que viaja entre los procesos a través de los sistemas de información. Es importante aclarar que el diagrama de contexto está construido en BPMN y se usan datastores (repositorios de datos o un grupo de objetos de datos [8]) para representar datos que son entradas o salidas del proceso y que al relacionarlos con los diferentes procesos representan el flujo de datos.

El modelo de proceso "Es un conjunto definido de actividades de negocio que representan los pasos requeridos para lograr un objetivo de negocio. Esto incluye el flujo y el uso de la información y los recursos" [17]. Este modelo, como se dijo en la sección 1, está construido usando BPMN con el objetivo de mejorar la comunicación de los stakeholders. Todas las actividades anteriores, así como la construcción del modelo de dominio, buscan enriquecer este modelo para lograr la captura del conocimiento y mejorar la comunicación entre los interesados. Adicionalmente, el proceso de negocio es la base para la identificación de los casos de uso y su posterior detalle.

El modelo de dominio "Es un modelo conceptual de alto nivel, define objetos abstractos o físicos que están en un área de interés para el proyecto. El modelo de dominio es usado para documentar las relaciones y responsabilidades entre clases conceptuales (es decir, clases que representan los conceptos de un grupo de cosas en lugar de las clases que definen un objeto de programación)" [16]. El objetivo de este modelo es el de generar una base para la arquitectura de datos y apoyar la captura de conocimiento y homologación de la información que fluye entre los procesos ya modelados, debido a que está en UML, que es un lenguaje estándar, mejora la comunicación entre participantes de diferentes procesos y entre los analistas de negocio y de tecnología.

Para la segunda sección, modelo de casos de uso, se tienen las siguientes actividades:

• Identificar casos de uso de alto nivel

• Detallar caso de uso

Un caso de uso "Es la especificación de un conjunto de acciones llevadas a cabo por un sistema que produce un resultado observable, que es, por lo general, de valor para uno o más agentes o stakeholders del sistema. Un caso de uso es utilizado por el sistema para generar un resultado significativo y observable (por lo general). La documentación de casos de uso (diagramas o texto) debe delinear una serie de pasos que tienen lugar durante la interacción e incluir diferentes caminos que esa interacción puede tomar" [14].

La primera actividad es la identificación de los casos de uso de alto nivel o de fachada, en el ciclo de vida de los requisitos, es la iteración fachada" [19]. El propósito de esta identificación es el de crear identificadores para cada interacción que se espera que los actores tengan con la aplicación. En esta actividad los casos de uso solo contienen la información necesaria para ser identificados; dicha información incluye un nombre y una breve descripción de la interacción. También se identifican los actores iniciales y otros actores (estos pueden provenir de los stakeholder identificados). Los casos de uso de alto nivel muestran lo básico, esencial, interacciones a alto nivel que esa aplicación deberá soportar. La actividad de detallar los casos de uso debe encontrar las características adicionales que se incorporan al caso de uso detallado; por ejemplo, los mensajes arrojados por el sistema, las validaciones, las excepciones y los requisitos de información adicionales.

Esta sección hace uso de UML como lenguaje para la especificación del sistema de información que se está buscando para la renovación tecnológica.

Para la tercera sección, atributos de calidad, se tiene una sola actividad. Esta actividad consiste en repasar una plantilla previamente construida en la que se tienen diferentes grupos de atributos de calidad para los que se evalúa si aplican o no para el alcance del proyecto.

La figura 3 muestra el diagrama en BPMN de la administración del mercado, resultado de seguir el proceso descrito anteriormente. Este diagrama es un diagrama de alto nivel en el que se pueden observar los stakeholder, los subprocesos de la operación, los subprocesos de la administración del mercado y los flujos de información representados por mensajes que viajan entre los participantes. En este nivel de detalle no se muestra la información que fluye dentro de los procesos de administración en XM; sin embargo, al ingresar a cada uno de los subprocesos se tiene mayor detalle y se puede observar el flujo de información entre los subprocesos y las actividades. Dentro de este modelado de proceso se hace un énfasis fuerte en el modelado de las reglas de negocio, ya que la mayoría de regulaciones que rigen la compañía se convierten en reglas de negocio.

Dentro de las contribuciones importantes en la mejora de la comunicación con el uso del modelo de requisitos se encuentra la mejora en la comunicación de las necesidades, entendiendo las necesidades como un problema de la organización, una oportunidad que no ha sido tomada o un resultado deseado que guiarán la identificación y definición de posibles soluciones [20]. El modelo de requisitos refleja las necesidades del negocio, en diferentes dimensiones: la dimensión de la arquitectura de negocio con los procesos en BPMN, la dimensión arquitectura de aplicación con los casos de uso en UML, la dimensión de arquitectura de datos con el modelo de dominio (UML) y los atributos de calidad que pueden materializarse en diferentes dimensiones (arquitectura de aplicación, arquitectura de datos, arquitectura de tecnología).

La figura 4 muestra cómo el modelo de requisitos permite comunicar necesidades y documentar algunos elementos de las dimensiones de una arquitectura empresarial según lo define TOGAF (The Open Group Architecture Framework) [21].

El hecho de que el modelo de requisitos contribuya con la documentación y la comunicación de la arquitectura empresarial basada en TOGAF no es un hecho fortuito, ya que los modelos planteados dentro de las secciones de este modelo conceptualmente tenían bases en las dimensiones planteadas por este framework. Después de la aplicación el resultado es cuando el modelo encaja muy bien dentro de una arquitectura empresarial basada en TOGAF y puede extenderse a un modelo que está en capacidad de documentar no solo los requisitos sino también la arquitectura de aplicación, de datos y de infraestructura, después de que se tiene un sistema implementado.

La herramienta usada para soportar el modelo de requisitos fue Enterprise Architect de sparx systems [9]; esta herramienta fue seleccionada por la compañía, previo a este modelo; sin embargo, soportó las necesidades de modelado de BPMN, de UML y las relaciones planteadas entre estos dos modelos. Algunas de las ventajas tenidas en cuenta al momento de la selección de esta herramienta fueron: la generación de modelos conformes con el estándar BPMN versión 2.0 y UML versión 2.4, relación costo beneficio (para las funcionalidades de modelado solicitadas), la posibilidad de usar un visor gratuito y, finalmente, la penetración que ha tenido en las empresas con servicios de modelado de procesos y de construcción de software que son aliadas de la compañía.

4. CONCLUSIONES

El modelo de requisitos propuesto es el resultado del uso de diferentes estándares (i.e. BPMN y UML) adoptándolos dentro de las necesidades propias de la compañía y agregando un proceso para asegurar la construcción de un documento de requisitos que contenga lo que se considera suficiente para poder llevar a cabo un proyecto de renovación tecnológica.

El resultado de la construcción del documento de requisitos usando el modelo propuesto fue exitoso, ya que se logró cumplir con los tres objetivos que se buscaban dentro del proyecto de renovación tecnológica, que eran: captura de conocimiento a través del uso de modelos a nivel de proceso y de especificación de sistemas de información, mejora en la comunicación entre los interesados al construir los modelos usando lenguajes de modelado estándar (BPMN y UML) y lograr una mejora en los procesos de soporte y mantenimiento al entregar herramientas que permiten estimar el impacto, los riesgos y el esfuerzo. El documento de requisitos se convierte en una herramienta que permite mejorar la alineación estratégica entre el negocio y la tecnología; esto se logra porque todas las necesidades tecnológicas están relacionadas directamente con las necesidades de negocio a través de sus procesos.

El modelo de procesos construido con BPMN ha permitido hacer simulaciones de la ejecución de algunos procesos para realizar mejoras y ajustes antes de continuar con el modelado en UML; estas simulaciones no han sido asistidas por ningún tipo de herramienta todavía.

Aunque no se consideró dentro del alcance de este artículo la gestión del cambio, es importante destacar que este es un aspecto fundamental para asegurar la correcta implementación del modelo propuesto, ya que se debe tener una formación en BPMN, UML y alguna experiencia en modelado con estos lenguajes. El ejercicio de modelar rompe con muchos paradigmas tradicionales de cómo documentar los procesos o las necesidades del negocio. Por esta razón, parte del trabajo realizado en la gestión del cambio consistió en la preparación de todos los participantes en BPMN y UML. Adicional al conocimiento de los estándares, se trabajó con un aliado de negocio experto en modelado con estas herramientas para que guiara las sesiones de modelado de cada una de las secciones durante las cuales se construyó el documento de requisitos.

Durante la construcción del documento de requisitos se tuvieron algunas dificultades asociadas a la estimación de los tiempos y con el modelado sobre todo de los procesos. La estimación de las fases iniciales fue muy complicada debido a que el equipo nunca había realizado este tipo de ejercicio; se había identificado que modelar en BPMN y en UML era una tarea dispendiosa y minuciosa, pero no se tenían estadísticas de referencia y algunos miembros del equipo eran novatos en el uso de estos lenguajes. Las estimaciones fueron mejorando a medida que se hacia el ejercicio y la recomendación para nuevos ejercicios es llevar un registro detallado del esfuerzo en horas, y los perfiles que deben participar en estos ejercicios de modelado.

Como en todos los ejercicios de construcción de modelos un gran riesgo es el de no llegar a un acuerdo de cuál es el modelo que se ajusta a la situación que se está modelando y a las necesidades, lo que puede generar lo que se llama parálisis por análisis, es decir, seguir mejorando el modelo sin que se construya la versión final. Este riesgo se mitiga teniendo dentro del equipo a expertos de negocio (especialistas) y miembros de equipo con experiencia en modelado que moderen la construcción y que estén en capacidad de llegar a acuerdos sobre esa versión final que se ajuste a las necesidades. En este caso particular, además de lo anterior, se definieron lineamientos que permitían determinar el nivel de detalle al que se debía llegar y los elementos mínimos que debían ser modelados; por ejemplo, los datos siempre se deben modelar, las reglas de negocio tienen mínimo la fórmula usada y una descripción de las variables de esa fórmula. Después de la aplicación del modelo de requisitos dentro del proyecto de renovación tecnología de SAM y dado que el modelo encaja muy bien dentro de una arquitectura empresarial basada en TOGAF (figura 4), como trabajo futuro se plantea la posibilidad de extender este modelo para que esté en capacidad de documentar no solo los requisitos, arquitectura de negocio, sino también la arquitectura de aplicación, la arquitectura de datos y de infraestructura después de que se tenga un sistema implementado. El modelo de requisitos se convierte en la base de la documentación de las dimensiones de la arquitectura empresarial. En este aspecto se han hecho adelantos definiendo las vistas mínimas de la arquitectura que se deben documentar usando BPMN y UML dentro de unas arquitecturas de referencia definidas en la compañía, pero es necesario hacer un trabajo formal para incluir esta documentación de la arquitectura dentro del modelo de requisitos que evolucionaria a un artefacto importante del modelo de arquitectura empresarial. Este artefacto de la arquitectura empresarial se debe mantener en el desarrollo de nuevos proyectos y en soporte y mantenimiento, permitiendo que se continúe con la captura del conocimiento.

Además del trabajo de evolucionar el modelo, también se propone como trabajo futuro usar los modelos ya contenidos en el documento de requisitos para medir la alineación estratégica del negocio con tecnología. El trabajo consistiría en definir los indicadores que puedan medir esta alineación y en buscar una posible herramienta que permita automatizar el cálculo de esta alineación usando los modelos que se tienen en BPMN y UML.

REFERENCIAS

1 Y. ZHANG y e. al, "Experience with East China Power Market IT Development and Operation," de Power System Technology, 2006. PowerCon 2006. International Conference on IEEE, 2006., Chongqing, China, 2006.         [ Links ]

2 Z. Fan, T. Horger y J. Bastian, ""Current and emerging challenges in PJM energy market, de Transmission and Distribution Conference and Exposition, 2010 IEEE PES, New Orleans, LA, USA, 2010.         [ Links ]

3 Z. Fan, T. Horger, J. Bastian y A. Ott, "An overview of PJM energy market design and development, de, Electric Utility Deregulation and Restructuring and Power Technologies, 2008. DRPT 2008. Third International Conference on, Nanjuing China, 2008.         [ Links ]

4 S. Sundhararajan, A. Boecker, J. Dondeti, R. Howard, J. Tamby, S. Grendel y A. Jayantilal, "Experience with ERCOT System's IT development and operation, Power Systems, IEEE Transactions on, vol. 18, n.° 2, pp. 535,540, 2003.         [ Links ]

5 M. Ratnakaran, C. Grossardt y C. Robertson, "Market Management System.," Patent Application Publication, 2007/0112579. USA. 2007.         [ Links ]

6 XM, Modelo de Requisitos en Xm version 6.2, Medellin, 2014.         [ Links ]

7 C. Venera, ""BPMN vs. UML Activity diagram for bussines process modeling Accounting and Management Information Systems, vol. 11, n.° 4, pp. 637–651, 2012.         [ Links ]

8 B. V. 2.0, "www.omg.org," Object Management Group _OMG, 2011. [En línea]. Available: http://www.omg.org/spec/BPMN/2.0/PDF. [Último acceso: 11 2014]         [ Links ].

9 S. Systems, "Enterprise Architect Sparx Systems," Enterprise Architect, 2000. [En línea]. Available: http://www.sparxsystems.com.au/products/ea/index.html. [Último acceso: 11 06 2015]         [ Links ].

10 M. e. a. López, "Modelling using UML and BPMN the integration of open reliability, maintenance and condition monitoring management systems:an application in an electric transformer system.," Computers in industryJournal, vol. 64, n.° 5, pp. 524-542, 2013.         [ Links ]

11 S. E. I. C. Mellon, "Glossary," [En línea]. Available: http://www.sei.cmu.edu/uls/start/glossary/. [Último acceso: 30 05 2015]         [ Links ].

12 M. R. Barbacci, R. Ellison, A. J. Lattanze, J. A. Stafford Y C. B. Y. W. W. G. Weinstock, Quality Attribute Workshops (QAWs),Third Edition, Technical Report CMU/SEI-2003-TR-016 ESC-TR, 2003.         [ Links ]

13 L. O. L. B. P. F. MERSON, Quality Attributes and Service-Oriented Architectures, Carnegie Mellon University, 2005.         [ Links ]

14 H. PODESWA, UML for the it Business Analyst, Second Edition: a practical guide to requirements gathering using the unified modeling language, Boston: Cengage Learning PTR, 2010.         [ Links ]

15 A. Durán Toro, " Escuela técnica superior de ingeniería informática. Documento de requisitos mediante casos de uso". Departamento de Lenguajes y Sistemas Informáticos. Grupo de Ingeniería del Software, 2004.         [ Links ].

16 M. Arjona Torres, Dirección estratégica. Un enfoque práctico, Madrid: Edición Díaz de Santos, 1999.         [ Links ]

17 OMG, Business Process Model and Notation (BPMN). Versión 2.0, OMG Document Number: formal/2011-01-03, 2011, pp. 499.         [ Links ]

18 S. Systems, "Tutorial UML," Systems, SparX.         [ Links ]

19 D. y. G. E. KULAK, Use Case Requirements in context. Second Edition, Boston: Pearson Education,INC, 2008, pp. 63-73.         [ Links ]

20 I. I. o. B. Analysis, A Guide to the Business Analysis Body of Knowledge, Toronto, Ontario. Canada: (BABOK Guide). Versión 2.0, 2009.         [ Links ]

21 T. O. Group, TOGAF Version 9.1. The Open Group Architecture Framework, The Open Group, 2011.         [ Links ]