.
Paz Perafán, Pino Correa & Buitrón Ruiz / INGE CUC, vol. 16 no. 2, pp. 238–252. Julio - Diciembre, 2020

Framework para la elicitación de requisitos de interoperabilidad en el contexto de sistemas organizacionales

Framework for elicitation of interoperability requirements in the context of organizational systems

DOI: http://doi.org/10.17981/ingecuc.16.2.2020.19

Artículo de Investigación Científica. Fecha de Recepción: 20/07/2020. Fecha de Aceptación: 25/09/2020

Daniel Eduardo Paz Perafán

Grupo IDIS. Universidad del Cauca. Popayán (Colombia)

danielp@unicauca.edu.co

Francisco José Pino Correa

Grupo IDIS. Universidad del Cauca. Popayán (Colombia)

fjpino@unicauca.edu.co

Sandra Lorena Buitrón Ruiz

Grupo IDIS. Universidad del Cauca. Popayán (Colombia)

sandrabr@unicauca.edu.co

Para citar este artículo:

D. Paz Perafán, F. Pino Correa, S. Buitrón Ruiz, “Framework para la elicitación de requisitos de interoperabilidad en el contexto de sistemas organizacionales”, INGE CUC, vol. 16, no. 2, pp. 238–255, 2020. DOI: http://doi.org/10.17981/ingecuc.16.2.2020.19

Resumen

Introducción— Dentro de la elicitación de requisitos los stakeholders generalmente no logran articular requisitos de interoperabilidad (RI) acordes a las necesidades del negocio, debido a que las organizaciones se enfocan en aspectos técnicos de las soluciones en lugar de realizar sistemáticamente un análisis holístico de la interoperabilidad y su relación con aspectos del negocio. Objetivo: Describir un framework que orienta desde la perspectiva de negocio, la captura y especificación de RI que pueden presentarse entre los sistemas organizacionales que componen los procesos de una organización.

Metodología— Fue utilizado el método de investigación-acción para definir y aplicar cada uno de los componentes del framework propuesto a partir de cuatro ciclos de investigación y tres ciclos de resolución de problemas en los cuales se aplicó la técnica de estudios de caso.

Resultados— El marco está constituido por cuatro componentes, un conjunto de heurísticas que permiten identificar RI, un modelo que describe los atributos que constituyen la interoperabilidad a nivel de negocio, un proceso que orienta la captura de RI, y una guía para especificar los RI. Por otra parte, los RI desde la perspectiva del negocio se plantean como partida para el desarrollo de los aspectos que se deben abordar en los niveles inferiores de interoperabilidad correspondientes a procesos, servicios y datos.

Conclusiones— A través de tres estudios de caso, se describe la experiencia en la aplicación de la propuesta en dos organizaciones. Los resultados iniciales muestran que el framework es útil, práctico y adecuado para abordar la elicitación de RI.

Palabras clave— organización; sistemas organizacionales; elicitación; negocio; interoperabilidad

Abstract

Introduction— Within requirements elicitation, stakeholders generally fail to articulate interoperability requirements (IR) according to business needs, because organizations focus on technical aspects of solutions instead of systematically conducting a holistic analysis of the interoperability and its relationship with aspects of the business. Objective: Describe a framework that guides from the business perspective, the capture and specification of IR that can occur between the systems that make up the processes of an organization.

Methodology— The action research method was used to define and apply each of the components of the proposed framework based on four research cycles and three problem-solving cycles in which the case study technique was applied.

Results— The framework is made up of four components, a set of heuristics to identify IR, a model that describes the attributes that constitute interoperability at the business level, a process that guides the capture of IR, and a guide to specifying IR. On the other hand, IR from a business perspective is proposed as a starting point for the development of the aspects that must be addressed at the lower levels of interoperability corresponding to processes, services and data.

Conclusions— Through three case studies, the experiences in the application of the proposal in two organizations are described. Initial results show that the framework is useful, practical and appropriate for addressing IR elicitation.

Keywords— organization; organizational systems; elicitation; business; interoperability

I. Introducción

Las organizaciones están cambiando de una visión de gestión por áreas funcionales, a una visión de gestión por procesos de negocio transversales a las áreas, en consecuencia, asumen como reto una integración coordinada de sus procesos de negocio, recursos humanos y TIC involucrados en la entrega de un producto o servicio. Al mismo tiempo las organizaciones desean facilitar, optimizar y mejorar las interacciones del trabajo colaborativo en sus procesos de negocio internos y externos [1].

En los proyectos de integración y colaboración obligatoriamente debe existir la inter­operabilidad como atributo de calidad [2], la cual es definida por la ISO/IEC 25010 [3] como la capacidad de 2 o más sistemas de intercambiar información y usar la información intercambiada. Inicialmente la mayoría de las investigaciones enfocaban la interoperabilidad en aspectos técnicos al sugerir normas para presentar, comunicar, procesar y transportar datos, así como tecnologías para la integración de diferentes plataformas, dispositivos de red y protocolos de comunicación [4], no obstante actualmente es necesario analizarla a partir de múltiples perspectivas y bajo un enfoque sistémico para lograr un intercambio efectivo de información [5].

En este sentido, la norma ISO 11354 [6] plantea que la interoperabilidad puede abordarse desde los siguientes 4 niveles: (i) datos, en el cual se detallan los datos a intercambiar y son resueltas sus diferencias sintácticas y semánticas; (ii) servicios, se enfoca en establecer los servicios que un sistema es capaz de ofrecer, y solicitar; (iii) procesos, aborda como las organizacionales son capaces de hacer que sus procesos funcionen juntos y (iv) negocio, se enfoca en describir las relaciones de negocio dentro de la organización y sus socios externos e incluir adecuadamente en los procesos de negocio el resultado del intercambio. Por lo tanto, el desafío de la interoperabilidad no se limita a los problemas técnicos que enfrenta intercambiar datos entre computadoras sino que requiere una mejor comprensión de los factores y problemas del negocio que influyen en su despliegue [7].

Durante el desarrollo, adquisición o mejora de los sistemas que componen los procesos de negocio de una organización, una etapa fundamental son las actividades de captura, análisis y especificación de requisitos de interoperabilidad (RI) [8]-[9], entendiendo un RI como una necesidad de intercambio y uso de información entre sistemas, los cuales dentro de una organización pueden ser: roles organizacionales, grupos de personas, áreas funcionales, software o hardware. Esta etapa es crítica debido a que permite garantizar que los sistemas organizacionales tienen un entendimiento común de la información comunicada y además están alineados a las necesidades de intercambio y uso de información de los diferentes stakeholders (usuarios finales del negocio, usuarios de dirección de la organización, usuarios técnicos, autoridades reguladoras) [8].

En este orden de ideas, dentro de la elicitación (captura y especificación) de requisitos los stakeholders generalmente no logran articular RI acordes a las necesidades del negocio, debido a que las organizaciones se enfocan en aspectos técnicos de las soluciones en lugar de realizar sistemáticamente un análisis holístico de la interoperabilidad y su relación con aspectos del negocio [8]. Esta práctica da como resultado el desarrollo de sistemas aislados, frecuentemente incompatibles con los sistemas de otras áreas funcionales e inconsistentes con las necesidades de intercambio y uso de información de los procesos de negocio [10].

Por la relevancia de los aspectos mencionados, fue desarrollado un framework que orienta a nivel de negocio, la elicitación de RI (que involucra captura y especificación) que pueden presentarse entre los sistemas que componen los procesos de negocio de una organización. El framework está constituido por 4 componentes, un conjunto de heurísticas que permiten identificar RI, un modelo que describe los atributos que constituyen un RI a nivel de negocio, un proceso que orienta la elicitación de RI, y una guía para especificar los RI. Por otra parte, los RI a nivel de negocio se plantean como punto de partida en la determinación y desarrollo de los aspectos que se deben abordar en los niveles inferiores de interoperabilidad correspondientes a procesos, servicios y datos.

Este artículo está organizado de la siguiente forma: la sección 2 presenta los trabajos relacionados, la sección 3 expone el método de investigación utilizado para construir el framework, la sección 4 describe las heurísticas, el modelo, el proceso y la guía que componen el framework y la sección 5 muestra la aplicación del framework en 3 procesos de negocio de diversas organizaciones. Finalmente son presentadas las conclusiones y trabajo futuro.

II. Trabajos Relacionados

Con el fin de analizar propuestas que establecen aspectos que deben ser abordados en la interoperabilidad a nivel de negocio y que definen como elicitar RI, fue realizada una revisión de la literatura siguiendo el enfoque propuesto por Kitchenham [11]. Los principales elementos que componen el protocolo de la revisión son descritos a continuación:

Con respecto a propuestas que abordan aspectos particulares que se presentan a nivel de negocio, en [12] evalúan un conjunto de aspectos con el fin de establecer el grado de interoperabilidad entre empresas, en [13] identifican un conjunto de características que deben ser consideradas en la planificación de la colaboración y en [14] presentan una definición de RI e identifican, describen y clasifican en 7 categorías un conjunto de aspectos a considerar durante los intercambios de información entre empresas, en [15] plantean un método para establecer las características de la interoperabilidad organizacional utilizando el modelado empresarial de acuerdo con los siguientes puntos de vista: funcional, decisional, información y los procesos de negocio y en [16] clasifican la interoperabilidad en 4 niveles: datos, servicios, procesos y negocio, y trasversal a estos niveles plantea que se deben abordar las perspectivas conceptual, tecnológica y organizacional. A partir de la revisión de este tipo de propuestas identificamos que se enfocan en proponer aspectos generales que deben ser abordados en el nivel de negocio, más no establecen los atributos que conforman el nivel, una definición de cada uno de ellos y los posibles valores que le podrían ser asignados. Esto lleva a la conclusión de que actualmente no existe una definición común de la interoperabilidad a nivel de negocio y se carece de un análisis sistemático de los atributos involucrados en este nivel.

Desde la perspectiva de la captura de RI encontramos propuestas como [1], [17] y [18] que establecen una serie de pasos para identificar necesidades de intercambios de información y posteriormente convertirlas en RI. Principalmente plantean: (i) definir un conjunto de principios básicos a fin de evitar problemas de comunicación entre los stakeholders, (ii) establecer y comprender los procesos de negocio, (iii) identificar instancias de casos de negocio en los que es necesaria la interoperabilidad, (iv) identificar actores, aplicaciones y sistemas que están involucrados y (v) analizar cada caso de negocio confrontando la situación actual y un escenario previsto. Otros enfoques utilizados son el propuesto por [13] en el cual a partir de un conjunto de preguntas se determina si un RI debe ser considerado y el de [9] donde plantean un repositorio de RI derivados de un análisis bibliográfico sobre interoperabilidad y una encuesta realizada en la industria, como guía para identificar tempranamente otros RI. Las propuestas analizadas convergen en que el análisis de un RI debe empezar desde el negocio, sin embargo, los enfoques propuestos carecen de una guía clara, completa y sistemática para identificar RI analizando las interacciones e intercambios de información que ocurren en los procesos de negocio, involucrando a las partes interesadas y considerando los atributos de la interoperabilidad a nivel de negocio.

III. Metodología

Fue utilizado el método de investigación-acción para definir, redefinir y aplicar el framework propuesto. De acuerdo con [19], la investigación-acción implica un ciclo de investigación y un ciclo de resolución de problemas en los cuales el conocimiento se aplica y descubre de forma interactiva.

En el primer ciclo de investigación fueron creadas una serie de heurísticas para identificar RI mediante un análisis de los elementos de BPMN asociados al intercambio y uso de información entre sistemas, como resultado se identificaron 3 tipos de comunicación, entre pools, dentro de un pool, o de un subproceso a un proceso y 7 símbolos de BPMN que permiten la comunicación y sus configuraciones. Posteriormente, fueron creadas las heurísticas considerando los tipos de comunicación, símbolos y heurísticas identificadas en el estado del arte.

En el segundo ciclo de investigación fueron seleccionadas de la literatura un conjunto de propuestas que caracterizaran la interoperabilidad desde diferentes niveles, con el fin de identificar los atributos que constituyen un RI. De cada propuesta fueron analizados los aspectos que abordaban a nivel de negocio. Posteriormente, cada aspecto fue analizado con el fin de identificar si está compuesto de varios atributos o si el aspecto en sí mismo es un atributo. Finalmente, los atributos resultantes fueron definidos, clasificados y se establecieron sus posibles opciones como respuesta.

En el tercer ciclo de investigación fueron analizados los atributos planteados en el ciclo anterior con el objetivo identificar actividades que orientaran su captura, y además fue realizado un análisis de la norma ISO/IEC/IEEE 29148 [20] para identificar prácticas complementarias. Todas las actividades identificadas fueron modeladas utilizando la notación de BPMN y descritas utilizando la plantilla de procesos del proyecto COMPETISOFT [21].

Finalmente, en el cuarto ciclo de investigación fueron determinadas las características de calidad que deben ser consideradas durante la especificación de requisitos (por ej. no ambiguo, completo, comprensible, verificable), posteriormente fueron creadas un conjunto de plantillas para registrar la información correspondiente a cada uno de los atributos que conforman un RI intentando satisfacer las características de calidad determinadas.

IV. Resultados

El framework propuesto orienta desde la perspectiva del negocio, la captura y especificación de RI que pueden presentarse entre los sistemas que conforman los procesos de negocio de una organización. El uso del framework tiene como propósito obtener un conjunto de RI para: (i) el desarrollo de un sistema software y/o (ii) aumentar el entendimiento de la información comunicada entre los miembros de las áreas funcionales de una organización. Independientemente del uso de los RI, su elicitación tiene como punto de partida un proceso de negocio.

En este orden de ideas, el framework está conformado por 4 componentes, los cuales se muestran en la Fig. 1. El primer componente es un conjunto de heurísticas que permiten identificar RI a partir del modelado de un proceso de negocio en BPMN, el segundo componente es un modelo que presenta en 4 vistas los atributos que deben ser considerados en un RI; el tercer componente es un proceso (dividido en 3 subprocesos) que establece como elicitar RI; y el cuarto componente es una guía para la especificación de RI, conformada por plantillas donde se registran los valores de los atributos que conforman un RI.

Fig. 1. Componentes del framework para la elicitación y especificación de RI.
Fuente: Autores.

A. Heurísticas para la identificación de requisitos de interoperabilidad

Dentro del framework han sido definidas 7 heurísticas que tienen como propósito la identificación de RI a partir de un modelo de procesos de negocio construido utilizando la notación de BPMN. Fue elegido BPMN debido a que según [22] es actualmente la notación más utilizada en la industria. Cabe aclarar que los otros 3 componentes del framework son independientes de la notación utilizada en el modelo del proceso de negoción a partir del cual se elicitaran los RI. A continuación, se muestra de manera detallada tres heurísticas:

Heurística 1 - Comunicación al interior de un pool

Dentro de un pool existe un RI cuando una actividad ejecutada por un lane envía información hacia una actividad adyacente ejecutada por otro lane. Considerando la Fig. 2 es posible que en el modelado se presente el escenario a) donde el objeto de datos esta explicito, o el escenario b) donde el objeto de datos es implícito. En el RI se deben considerar los siguientes casos: el lane que contiene la actividad que consulta o genera el objeto de datos corresponderá al emisor de la información y el lane que contiene la actividad que recibe el objeto de datos corresponderá al receptor de la información.

Fig. 2. Configuraciones de un RI dentro de un pool.
Fuente: Autores.

Heurística 2 - Comunicación mediante actividades de envío

Al identificar una actividad de envío existe un RI. Considerando la Fig. 3, se deben tener en cuenta los siguientes casos dentro del RI: si la actividad tiene una configuración a), considerar que existe un solo receptor; si tiene una configuración b) o c) considerar que existen varios receptores; si tiene una configuración c) considerar la condición de parada que permite detener el envío de mensajes; y si tiene una configuración d) considerar las excepciones al enviar un mensaje.

Fig. 3. Configuraciones de las actividades de envío y recepción de flujos de mensaje.
Fuente: Autores.

Heurística 3- Comunicación mediante actividades simples con flujos de mensaje

Considerando la Fig. 4, al identificar una actividad con una configuración a) en la cual se presentan dos flujos de mensajes, uno de salida, y otro de entrada, existen dos RI uno por cada flujo, por otra parte, si la configuración es b) existe un RI. Se deben tener en cuenta los siguientes casos: si la actividad tiene una configuración a) considerar que se presenta un envío síncrono ya que el emisor de la actividad se bloquea hasta recibir la respuesta y si la actividad tiene una configuración b) considerar que se presenta un envío asíncrono ya que el emisor puede ejecutar otras actividades hasta recibir la respuesta.

Fig. 4. Configuraciones de la actividad simple con flujos de mensaje.
Fuente: Autores.

El resto de heurísticas planteadas en el framework establecen que existe un RI al identificar: una actividad de recepción, una actividad de servicio, un evento de mensaje o un evento de escalación.

B. Modelo que describe los atributos que conforman un requisito de interoperabilidad

El modelo identifica, define y clasifica un conjunto de atributos que constituyen un RI a nivel de negocio. Cada atributo está clasificado en una vista y representa una característica del flujo de información entre los sistemas que se comunican. En este sentido, los atributos propuestos pueden ser utilizados para establecer qué debe considerar un analista cuando captura y especifica un RI. La descripción completa de los atributos se encuentra en [23]. Por motivos de espacio a continuación se muestra de manera detallada los atributos que conforma la vista de propiedades del flujo de datos, para el resto de vistas se muestra de manera genérica sus atributos.

1) Vista de propiedades del flujo de datos

La vista define 10 atributos que deben considerarse en el flujo de los datos entre los emisores y receptores presentes en un RI. A continuación, se describe cada uno de los atributos y las posibles opciones como respuesta:

2) Vista de emisores y receptores

La vista define 6 atributos que representan los componentes de los emisores y receptores involucrados en un RI. Los atributos definidos son los siguientes: Organización, Área funcional. Recurso (puede ser un software, hardware, rol organizacional u órgano organizacional) que ejecuta la actividad o evento que envía o recibe la información, Actividad o evento ejecutado, Repositorio de datos desde donde se obtiene la información a intercambiar o donde se almacenará la información recibida.

3) Vista de tipos de interacción

La vista define 2 atributos, el primero establece la cantidad de emisores y receptores involucrados en la comunicación y el segundo si la comunicación es dentro o fuera del área emisora.

4) Vista de condiciones para utilizar los datos comunicados

La vista define 3 atributos, cada uno de ellos asociados a casos que deben considerar los emisores y receptores al momento de utilizar la información comunicada. Los atributos que componen esta vista son: elementos obligatorios para aceptar la información recibida, acciones a ejecutar por el receptor cuando la información recibida no es correcta y acciones que debe ejecutar el emisor cuando la respuesta no llega.

C. Proceso que orienta la captura de requisitos de interoperabilidad

El proceso orienta a nivel de negocio la captura de los RI que pueden presentarse entre los sistemas que componen los procesos de negocio de una organización. En este sentido, por cada RI son capturados los atributos planteados en las vistas de emisores y receptores, tipos de interacción, propiedades del flujo de datos, y condiciones para utilizar los datos comunicados. Debido a la complejidad de la captura de los RI, el proceso se ha dividido en 3 subprocesos.

El primer subproceso que se muestra en la Fig. 5, tiene como propósito primero seleccionar un proceso de negocio a partir del cual se capturaran los RI, posteriormente son incorporadas posibles mejoras al proceso; y finalmente son presentados a los usuarios expertos los componentes del marco del marco de trabajo.

Fig. 5. Sub proceso de establecer el alcance de la elicitación de RI.
Fuente: Autores.

El segundo subproceso que se muestra en la Fig. 6, tiene como propósito identificar los RI a partir del proceso de negocio, posteriormente es seleccionado un RI, y sobre el son capturados y especificados los atributos de las vistas de emisores y receptores, tipos de interacción y propiedades del flujo de datos del modelo, finalmente son validados los RI.

Fig. 6. Sub proceso para capturar los atributos de un RI.
Fuente: Autores.

El tercer subproceso que se muestra en la Fig. 7, tiene como propósito seleccionar un RI sobre el cual serán capturados los atributos de la vista de “condiciones para utilizar los datos comunicados”, finalmente son validados, priorizados y socializados los RI.

Fig. 7. Sub proceso para identificar condiciones para utilizar los datos.
Fuente: Autores.

D. Guía para la especificación de requisitos de interoperabilidad a nivel de negocio

La guía orienta como debe realizarse la especificación de RI considerando los atributos del modelo presentado en la sección A. En total la guía está conformada por 3 componentes: (i) 4 plantillas que permiten registrar los atributos de un RI; (ii) reglas de sintaxis que indican como escribir los campos de las plantillas; y (iii) una secuencia de actividades que describen como se deben diligenciar correctamente las plantillas. En la Fig. 8 y Fig. 9 se muestran 2 plantillas que permiten almacenar los atributos de un RI.

Fig. 8. Plantilla para registrar los atributos de las vistas de emisores y receptores y tipos de interacción.
Fuente: Autores.
Fig. 9. Plantilla para registrar los atributos asociados a la vista de propiedades del flujo de datos.
Fuente: Autores.

V. Estudios de Caso

El framework fue evaluado por medio de tres estudios de caso, los cuales se desarrollaron siguiendo el protocolo descrito en [24] y son de tipo holístico-multiple según [25] debido a que el framework fue aplicado en diferentes áreas funcionales (contexto) y por cada área, en uno de sus procesos de negocio (unidad de análisis). A continuación, se describen los estudios de caso en términos de: planeación, análisis, resultados de la intervención y limitaciones.

A. Diseño de los estudios de caso

1) Objetivo, objeto y preguntas de investigación

El objetivo de los estudios fue evaluar la idoneidad del framework en términos de su utilidad, completitud y correctitud y el objeto de los estudios de caso fue el framework para apoyar la elicitación de RI. La pregunta de investigación principal que guío los estudios de caso fue ¿El framework es idóneo para la elicitación de RI a nivel de negocio? y las adicionales fueron: ¿Los componentes del framework permiten identificar RI a partir de un proceso de negocio?, ¿Los RI identificados utilizaron todos los atributos propuestos en el framework? y ¿La información plasmada en cada uno de los RI especificados corresponde a la naturaleza de la información solicitada en cada uno de los atributos?

2) Contexto y unidades de análisis

El primer y segundo estudio de caso fueron aplicados en una institución de educación superior colombiana y el tercer estudio de caso se aplicó en una institución de salud previsional chilena. La unidad de análisis en el primer estudio de caso fue el proceso de radicación de documentos, en el segundo estudio fue el proceso de elaboración del presupuesto institucional y en el tercer estudio fue el proceso de análisis de licencias médicas. En el primer y tercer estudio de caso el objetivo fue elicitar un conjunto de RI para ser utilizados en el desarrollo de un sistema software y el objetivo del segundo estudio de caso fue aumentar el entendimiento de la información comunicada entre las áreas funcionales.

4) Instrumentos de evaluación

Dentro de esta investigación los instrumentos empleados fueron observación de campo, encuesta y RI especificados.

5) Sujetos de investigación

Un analista encargado de guiar a los integrantes de la organización durante la elicitación de los RI, integrantes de la organización y un investigador encargado de observar la elicitación.

B. Intervención

La planeación que rigió las actividades de campo de los estudios de caso esta directa y estrechamente relacionada con las actividades que propone el proceso para la elicitación de los RI (Cuarto componente del marco). A continuación, se describe las actividades que conforman la planeación:

C. Resultados obtenidos

A partir del proceso de elicitación de RI realizado en las 3 unidades de análisis y las experiencias compartidas por los integrantes de las organizaciones y analistas resaltamos los siguientes resultados:

Tabla 1. RI elicitados en el primer estudio de caso.

RI

Emisor

Receptor

Propósito de la comunicación

1

Área de gestión documental.

Talento humano.

Determinar si un funcionario o docente esta activo o inactivo y consultar sus datos.

2

Área de gestión documental.

División de admisiones registro y control académico.

Determinar si un estudiante esta activo o inactivo y consultar sus datos.

3

Área de gestión documental.

Vicerrectoría administrativa.

Determinar si una persona juridica o natural esta vinculado como contratista en la universidad.
Fuente Autores.

El framework permitió elicitar RI tomando como punto de partida procesos de negocio sin documentar ni modelar (estudio de caso 1), procesos de negocio documentados y modelados (estudio de caso 2) y procesos de negocio documentados, pero no modelados (estudio de caso 3) y también con varios propósitos para los RI. Basados en estas consideraciones el framework permite elicitar RI a partir de diferentes escenarios generados por el estado actual de los procesos de negocio y el propósito de la elicitación.

A partir del trabajo realizado e informado por los analistas, los beneficios descritos por los integrantes de las organizaciones, las experiencias y lecciones aprendidas y el esfuerzo involucrado en la elicitación, se considera que los componentes del framework son idóneos y prácticos para ayudar a elicitar RI (respondiendo así a la pregunta de investigación principal).

1) Lecciones aprendidas

Algunas lecciones aprendidas relevantes que se pueden extraer de la aplicación del framework son:

Cuando se elicitan RI donde hay una petición de acceso a información y el propósito es utilizar los RI en el desarrollo de un sistema software, el analista debe considerar los siguientes aspectos: establecer si el área receptora puede brindar la información, si la información a obtener esta digitalizada y almacenada en una base de datos, si existe el sistema software que gestiona la información y si no existe el sistema software, determinar si es posible crearlo del lado del receptor con el fin de automatizar la comunicación.

Los integrantes de las áreas funcionales conocen los intercambios de información entre áreas, perciben que los intercambios están conformados por un conjunto de características, pero no saben qué características identificar, cómo identificarlas y que tan importantes son para generar un entendimiento común. Por otra parte, la identificación de los atributos que componen un RI es necesario realizarla de manera colaborativa entre los integrantes de las áreas emisoras y receptoras debido a que se requiere un acuerdo mutuo entre ellas.

El uso del protocolo para estudios de caso presentados [24] y la lista de chequeo presentada en [26] ha permitido que los estudios de caso sigan una ejecución sistemática y rigurosa. De esta forma, utilizar un protocolo ha permitido a los investigadores de este proyecto: (i) especificar detalladamente como responder las preguntas de investigación planteadas, y (ii) respaldar los resultados obtenidos.

2) Limitaciones de la evaluación y su gestión

Para maximizar los resultados se implementaron las siguientes estrategias: (i) antes de la elicitación fue realizada a los integrantes de las áreas funcionales una exposición sobre interoperabilidad, los componentes del framework y un ejemplo de un RI especificado en las plantillas, (ii) se acordó con los integrantes realizar la elicitación en varias sesiones y (iii) el grupo de investigación observó la elicitación y la especificación de los RI sin intervenir en la aplicación.

VI. Conclusiones

Este artículo describe un framework para la elicitación de RI a nivel de negocio, el cual ha sido desarrollado mediante el método de investigación-acción. El framework lo constituyen los siguientes componentes: un conjunto de heurísticas que permiten identificar RI a partir del modelado de un proceso de negocio en BPMN, un modelo que presenta en 4 vistas los atributos que deben ser considerados en un RI, un proceso que establece como elicitar RI y un conjunto de plantillas donde se registran los valores de los atributos que conforman un RI. Para la aplicación de la propuesta se realizaron 3 estudios de caso, los cuales tuvieron como punto de partida diferentes estados de los procesos de negocio y diferentes propósitos para usar los RI elicitados. De la experiencia adquirida al aplicar el framework, y considerando: la cantidad de RI elicitados, el esfuerzo involucrado en la elicitación y los beneficios descritos por los integrantes de las organizaciones, se considera que los componentes del framework son idóneos y prácticos para orientar la elicitación de RI en el contexto de los sistemas organizacionales.

Como trabajo futuro se plantea la creación de un modelo que describa las dependencias entre los atributos de los diferentes niveles de interoperabilidad y una metodología para elicitar RI que considere todos los niveles. Finalmente, se consideran realizar otros ciclos de resolución de problemas mediante el método de estudio de caso, con el fin de incrementar el rigor de la aplicación del framework propuesto, establecer con mayor profundidad sus alcances y limitaciones, y aumentar la fiabilidad de los resultados obtenidos y las conclusiones extraídas.

Financiamiento

El artículo es resultado de los proyectos de investigación titulados: “Marco de trabajo para apoyar la elicitación de requisitos de interoperabilidad basados en las necesidades de los procesos de negocio de una organización”, financiado por la Vicerrectoría de investigaciones de la Universidad del Cauca con fecha de inicio, 16/05/2019 y fecha de finalización, 15/11/2020; y “Estado actual de la Ingeniería de Requisitos de software en el sur occidente colombiano” financiado por la Vicerrectoría de investigaciones de la Universidad del Cauca con fecha de inicio, 12/04/2019 y fecha de finalización, 12/10/2020.

Referencias

[1] N. Daclin, D. Chen & B. Vallespir, “Developing enterprise collaboration: a methodology to implement and improve interoperability,” Enterp Inf Syst, vol. 10, no. 5, pp. 467–504, 2016. http://doi.org/10.1080/17517575.2014.932013

[2] H. Panetto, M. Zdravkovic, R. Jardim-Goncalves, D. Romero, J. Cecil & I. Mezgár, “New perspectives for the future interoperable enterprise systems,” Comput Ind, vol. 79, pp. 47–63, 2016. https://doi.org/10.1016/j.compind.2015.08.001

[3] BS ISO/IEC 25010, Systems and software engineering. Systems and software quality requirements and evaluation (SQuaRE), BS, British Standards Institution, UK, 2011. https://doi.org/10.3403/30215101u

[4] R. Rezaei, T. K. Chiew, S. P. Lee & Z. Shams Aliee, “Interoperability evaluation models: A systematic review,” Comput Ind, vol. 65, no. 1, pp. 1–23, Jan. 2014. http://doi.org/10.1016/j.compind.2013.09.001

[5] K. Cenci, E. Estevez & P. R. Fillottrani, “Facilitating Data Interoperability in Science and Technology: A Case Study and a Technical Solution,” presented in 18th Annual International Conference on Digital Government Research, dg.o '17, NY, USA, Jun. 2017, pp. 407–415. https://doi.org/10.1145/3085228.3085291

[6] BS EN ISO 11354-1, Advanced automation technologies and their applications. Requirements for establishing manufacturing enterprise process interoperability. Framework for enterprise interoperability, BS, British Standards Institution, UK, 2011. https://doi.org/10.3403/30185800U

[7] R. Motta, K. Marçal & G. Horta, “Rethinking interoperability in contemporary software systems,” presented in VI Brazilian Symposium on Computing Systems Engineering, SBESC, Bs As, Arg, 23-23 May 2017, pp. 9–15. https://doi.org/10.1109/jsos.2017.5

[8] R. Motta, K. Marçal & G. Horta, “Characterizing Interoperability in Context-aware Software Systems,” presented in Computing Systems Engineering, SBESC, João Pessoa, BR, 1-4 Nov. 2016, pp. 203–208. https://doi.org/10.1109/sbesc.2016.039

[9] N. Daclin, S. M. Daclin, V. Chapurlat & B. Vallespir, “Writing and verifying interoperability requirements: Application to collaborative processes,” Comput Ind, vol. 82, pp. 1–18, Oct. 2016. http://doi.org/10.1016/j.compind.2016.04.001

[10] H. Abukwaik & D. Rombach, “Software Interoperability Analysis in Practice: A Survey,” presented in 21st International Conference on Evaluation and Assessment in Software Engineering, EASE, NY, USA, Jun. 2017, pp. 12–20. https://doi.org/10.1145/3084226.3084255

[11] B. Kitchenham, “Procedures for performing systematic reviews,” Keele University, Keele, UK, NICTA Technical Report 0400011T.1, 2004.

[12] A. Grilo, R. Jardim-Goncalves & V. Cruz-Machado, “A framework for measuring value in business interoperability,” 2007 IEEE Int Conf Ind Eng Eng Manag, IEEE, SG, 2-4 Dec. 2007, pp. 520–524. https://doi.org/10.1109/ieem.2007.4419244

[13] M. M. E. Alemany, F. Alarcón, F. C. Lario & R. Poler, “Conceptual Framework for the Interoperability Requirements of Collaborative Planning Process,” in Enterp Interoperability IV, K. Popplewell, J. Harding, R. Poler, R. Chalmeta (eds), LD, UK: Springer, 2010, pp. 25–34. http://doi.org/10.1007/978-1-84996-257-5_3

[14] C. Legner & K. Wende, “Towards an excellence framework for business interoperability,” presented in 19th Bled eConference, eValues, Bled, SL, 5-7 Jun. 2006, pp. 1–16. Available: https://aisel.aisnet.org/bled2006/29

[15] S. Blanc-Serrier, Y. Ducq & B. Vallespir, “Organisational interoperability characterisation and evaluation using enterprise modelling and graph theory,” Comput Ind, vol. 101, pp. 67–80, 2018. https://doi.org/10.1016/j.compind.2018.04.012

[16] D. Chen, “Framework for enterprise interoperability,” in Enterprise Interoperability INTEROP-PGSO Vision, B. Archimède and B. Vallespir, ed. HOB: Wiley-ISTE, 2017, pp. 1–18. https://doi.org/10.1002/9781119407928.ch1

[17] R. Ruggaber, “ATHENA - Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications BT - Interoperability of Enterprise Software and Applications,” in Interoperability of Enterprise Software and Applications, D. Konstantas, J. P. Bourrières, M. Léonard, N. Boudjlida, eds,. LD, UK: Springer, 2006, pp. 459–460. https://doi.org/10.1007/1-84628-152-0_45

[18] N. A. Qureshi, C. D. Nguyen & A. Perini, “Analyzing interoperability requirements for adaptive service-based applications: A goal-oriented approach,” presented at 34 Ann Comp Soft Appl Conf Workshops, IEE, SU, KR, 19-23 July 2010, pp. 239–244. http://doi.org/10.1109/COMPSACW.2010.49

[19] J. McKay & P. Marshall, “The dual imperatives of action research,” Inf Technol People, Vol. 14 No. 1, pp. 46–59, 2001. https://doi.org/10.1108/09593840110384771

[20] ISO/IEC/IEEE 29148:2011, Systems and software engineering — Life cycle processes — Requirements engineering, ISO, International Organization for Standardization, Geneva, Switzerland, 2011. Avalable: https://www.iso.org/standard/45171.html

[21] M. Piattini, H. Oktaba, M. J. Orozco, C. Esquivel & F. J. Pino, Competisoft: Mejora de procesos software para pequeñas y medianas empresas y proyectos. Paracuellos de Jarama: RA-MA, 2009.

[22] R. M. Pillat, R. M. S. Santos & T. C. Oliveira, “Systematic Literature Review on BPMN-based Process Adaptation Approaches,” presented in XV Brazilian Symposium on Information Systems, SBSI; AJU, BR, May. 2019, pp. 1–8. http://dx.doi.org/10.1145/3330204.3330242

[23] D. E. Paz, F. J. Pino & S. L. Buitron, “A model for the elicitation of organizational system interoperability requirement,” Ing Solidar, vol. 16, no. 3, pp. 1–36, 2020. https://doi.org/10.16925/2357-6014.2020.03.01

[24] P. Runeson & M. Höst, “Guidelines for conducting and reporting case study research in software engineering,” Empir Softw Eng, vol. 14, no. 2, pp. 131–164, 2009. https://doi.org/10.1007/s10664-008-9102-8

[25] R. K. Yin, Case study research and applications: Design and methods. TO, USA: SAGE, 2017.

[26] M. Host & P. Runeson, “Checklists for software engineering case study research,” presented in First International Symposium on Empirical Software Engineering and Measurement, ESEM, MD, ES, 20-21 Sept. 2007, pp. 479–481. https://doi.org/10.1109/ESEM.2007.46

Daniel Eduardo Paz Perafán es graduado de Ingeniería de Sistemas con maestría en Computación de la Universidad del Cauca (Cauca, Colombia). Sus áreas de interés incluyen Interoperabilidad empresarial, Mejora de procesos de software y Calidad de software. Docente ocasional de la Universidad del Cauca, adscrito al grupo de investigación IDIS. https://orcid.org/0000-0003-1848-4333

Francisco Jose Pino Correa es graduado en electrónica y telecomunicaciones y especialista en redes y servicios telemáticos de la Universidad del Cauca (Colombia) y doctor en Tecnologías Informáticas Avanzadas de la Universidad Castilla la Mancha (España). Sus áreas de interés incluyen Calidad del software, Mejora de procesos y Metodologias de investigación. Docente de planta de la Universidad del Cauca, adscrito al grupo de investigación IDIS. https://orcid.org/0000-0003-0668-4485

Sandra Lorena Buitrón Ruiz es Ingeniera de sistemas de la Universidad Cooperativa de Colombia (Popayán Colombia), especialista en redes de comunicación de la Universidad del Valle (Cali, Colombia), especialista en sistemas gerenciales de ingeniería con énfasis en gestión de proyectos de la Pontifica Universidad Javeriana (Cali, Colombia), Magister en Computación de la Universidad del Cauca (Popayán, Colombia), y candidata a Doctor en Ciencias de la Electrónica de la Universidad del Cauca. Docente cátedra de la Universidad del Cauca, con 15 años de experiencia en el sector empresarial de la industria del software, desempeñando cargos como gerente de proyectos, líder de pruebas, coordinador de calidad y coordinador de desarrollo. https://orcid.org/0000-0001-6127-1849

.
© The author; licensee Universidad de la Costa - CUC.
INGE CUC vol. 16 no. 2, pp. 238-252. Julio - Diciembre, 2020
Barranquilla. ISSN 0122-6517 Impreso, ISSN 2382-4700 Online
.