Descomposición de árboles de metas a partir de modelos de procesos1

Jose Luis De la Vara González, David Anes Alcolea, Juan Sánchez Díaz Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia Camino de Vera s/n, Valencia, España

{jdelavara, daanes, jsanchez}@dsic.upv.es

1 Este trabajo ha sido desarrollado con el soporte del MEC bajo el proyecto DESTINO TIN2004-03534 y cofinanciado por FEDER

Resumen

Los Sistemas de Información (SI) utilizados dentro de una organización no son algo separado de la organización empresarial a la que le dan soporte, y por tanto la Ingeniería de Requisitos (IR) debe considerar las necesidades de negocio de una organización. Aunque se reconoce que la IR es el puente natural que conecta el mundo empresarial y el mundo de los SI, la mayor parte de la investigación en IR continúa estando orientada a la solución, evitando considerar los problemas reales del mundo empresarial. Las necesidades de negocio pueden ser descritas mediante el alineamiento de los SI con la estrategia del negocio, los procesos de negocio, las infraestructuras organizacionales y las metas organizacionales. Una de las consecuencias del alineamiento entre negocio y los SI es el “mapeado” de las metas organizacionales y los procesos a la especificación del sistema En este trabajo se presenta una aproximación que utiliza una especificación en la forma de modelo de metas, construida mediante heurísticas en base a modelos de procesos en la forma de BPMN. A partir del modelo de metas, mediante un proceso de refinamiento y de etiquetado, se obtiene un modelo de requisitos en la forma de casos de uso. La especificación así obtenida permite reflejar de manera más cercana las necesidades del negocio y asegura el alineamiento de las mismas con el futuro SI. 1. Introducción

El desarrollo de un sistema de información para una organización es un proceso complejo que no sólo conlleva la resolución de los problemas tecnológicos asociados con su arquitectura y componentes, sino que

también debe tener en cuenta los problemas organizacionales y sociales relacionados con su dominio de aplicación. En el contexto organizacional, el dominio de aplicación del sistema lo constituye la organización en la cual se ha de acoplar el futuro sistema. Así, un buen conocimiento del dominio de aplicación es un factor crítico para garantizar el éxito de la actividad de elicitación de requisitos – la primera actividad dentro del proceso de desarrollo de software.

En los últimos años diversos autores [1][2][8][10][20] han reconocido la importancia de modelar la organización antes de elicitar los requisitos de su sistema de información. Un modelo organizacional es una representación que captura la estructura y el comportamiento de la organización en la cual estará inmerso el sistema. Este modelado puede ser muy útil para que los desarrolladores entiendan de un modo apropiado las necesidades de información y los requisitos que el sistema debe satisfacer.

En este trabajo se presenta una propuesta que permite derivar a partir de un modelo organizacional un modelo de requisitos utilizando como pasos intermedios un modelo de procesos y un árbol de metas. La propuesta permite la participación en el proceso de derivación a analistas organizacionales y analistas informáticos o del sistema. Los nexos de unión lo constituyen el lenguaje de modelado de procesos BPMN (Business Process Modelling Notation) [14], que suministra una notación comprensible por los diversos actores interesados en los procesos de negocio, y un árbol de metas derivado de los modelos definidos con esta notación. El árbol de metas se construye a partir de un conjunto de patrones de los procesos de negocio, posteriormente se etiqueta para describir qué metas se automatizan y finalmente se deriva un modelo de casos de uso. El proceso de

construcción garantiza el alineamiento entre los modelos organizacionales y los modelos software resultantes.

En nuestra aproximación (descrita en la sección 2) se utilizan diferentes vistas para los diferentes “stakeholders” que participan en el proceso, conteniendo cada una de ellas la información necesaria y de interés para ellos en su ámbito de trabajo. Nosotros distinguimos los siguientes “stakeholoders”: • Gestores del negocio que toman, entre otras, la decisión de desarrollar o modificar el sistema de información de la organización. Para ellos es relevante la vista de metas estratégicas de la organización (metas organizacionales en lo que sigue) que describen las metas que quiere conseguir la organización a largo plazo. • Analistas organizacionales que modelan la organización y dentro de ésta los procesos de negocio. Además participan, junto a los analistas informáticos, en la tarea de decidir qué metas del árbol de metas deben automatizarse. • Analistas de sistemas de información que se encargan de desarrollar el sistema informático. La vista de procesos es relevante para ellos ya que derivan mediante un conjunto de heurísticas un árbol de metas asociado a cada proceso. También son relevantes el árbol de metas etiquetado y el modelo de requisitos.

El trabajo se encuentra estructurado de la siguiente forma: en la sección 2 se describe la propuesta con las fases que posee; la sección 3 presenta el caso de estudio que será utilizado para ilustrar la aplicabilidad de la aproximación; las secciones 4, 5 y 6 describen los

flujos de trabajo que gobiernan el método; finalmente las secciones 7 y 8 presentan respectivamente los trabajos relacionados y las conclusiones. 2. Descripción de la propuesta

La figura 1 muestra las tres fases de la propuesta que hemos llamado respectivamente: modelado organizacional, de metas y de requisitos. Cada fase contiene un conjunto de actividades y trabajadores que participan en las mismas.

En la primera fase se analiza y modela la organización en la cual estará inmerso el sistema informático que se pretende construir. El propósito de esta fase es capturar y justificar la actividad de la organización, para posteriormente utilizarla como inicio del proceso de derivación del árbol de metas del sistema de información. En esta fase se construye un diagrama de contexto, un modelo de roles, un modelo de procesos (junto a los recursos que utilizan), un modelo de metas organizacionales o estratégicas y la asignación de las metas de la organización a los procesos que les dan soporte.

En la segunda fase, denominada modelado de metas, los procesos de negocio se analizan. De este análisis se extraen las metas actuales que componen los procesos. A continuación se establecen las metas que se desean automatizar (etiquetado del árbol de metas) y que deben estar presentes en el sistema de información, generando distintas alternativas si procediera. Estas alternativas se evalúan y se selecciona la que se considere como mejor opción para

Modelado Recursos

Modelado de Procesos

Modelado Organizacional Modelado de metas

Modelado de requisitos funcionales

Modelo de Roles

Diagrama de Contexto

Metas Organizacionales

Asignar metas a procesos

Analista Organizacional

Árbol metas procesos

Etiquetado árbol metas

Analista OrganizacionalAnalista Sistema

Analista Sistema

Modelo Casos de Uso

Analista Sistema

Trabajadores Actividades Sincronización Estado inicial

Flujo de control

Flujo de trabajo

Leyenda

Gestor del negocio

Figura 1. Fases de la propuesta

la organización. Como resultado se obtiene un conjunto de metas del sistema a desarrollar.

Una vez seleccionada la opción que mejor encaje con las necesidades del sistema, el análisis de las metas del sistema de información finaliza y éstas se traducen en un modelo de requisitos (casos de uso), en la fase 3 de la propuesta. En las siguientes secciones detallaremos cada una de las mismas.

3. Caso de estudio

Como caso de estudio hemos seleccionado una empresa de confección que subcontrata los procesos de manipulación necesarios para confeccionar sus productos. La empresa únicamente compra el hilo o la materia prima a proveedores. En sus instalaciones dispone de maquinaría para cortar los patrones, el resto de los procesos de transformación (tejeduría, tintado, estampado, etc.) son subcontratados a otras empresas. La organización trabaja bajo pedidos de grandes clientes, de manera que al principio de cada temporada los clientes pactan los modelos y las cantidades de prendas que van a solicitar. Los pedidos de grandes clientes deben ser enviados directamente a las tiendas, con la particularidad de que tanto los pedidos iniciales como los de reposición tienen un plazo de entrega estipulado, por lo que las prendas contenidas en un pedido deben estar fabricadas o en proceso inminente de fabricación. La empresa cuenta con un pequeño ordenador para anotar los pedidos, los envíos y la facturación a clientes. La empresa no dispone de un sistema informático propiamente dicho, de forma que los pedidos de los clientes llegan por correo ordinario y mediante una hoja de cálculo se crean los albaranes que componen las expediciones. Las secretarias de la empresa se encargan de formar los albaranes de envío que pasan a la sección de almacén. El jefe de almacén, de acuerdo al stock disponible de artículos, organiza la expedición o el envío que recoge una empresa de transporte. Los albaranes pueden ser modificados en el almacén, si existe menos cantidad de la pedida, y son entregados de vuelta a las secretarias para que procedan a su facturación. Debido al volumen creciente de pedidos la empresa está interesada en informatizar tanto la gestión de pedidos como de albaranes y facturas.

De los diversos procesos de la compañía se utilizará el proceso “selección de pedidos y envío de género a clientes” (“tratamiento de pedidos” en lo que sigue) para ilustrar la aproximación.

4. Modelado de la organización

Para modelar una organización en primer lugar se

deben mantener entrevistas con empleados de las distintas unidades organizacionales de la empresa o con empleados que desempeñen actividades asociadas a distintos roles dentro de la organización. Por otro lado, también es conveniente estudiar toda la documentación disponible relacionada tanto con la actividad de la empresa como con sus políticas de negocio.

Los modelos generados en esta fase son: diagrama de contexto, modelo de roles, metas estratégicas u organizacionales, modelos de procesos (con recursos), y asignación de metas a procesos. Por cuestiones de espacio haremos hincapié en el modelo de procesos/recursos, comentando brevemente el resto de los modelos. El diagrama de contexto del negocio muestra las distintas unidades organizacionales y la relación de éstas (provisión de datos/servicios) con unidades externas (clientes, proveedores, competidores, etc.). El modelo de roles es un modelo estándar que refleja los actores, las unidades organizacionales y los roles que juegan dentro de cada actividad contenida en los proceso que componen la empresa. Las metas estratégicas están asociadas con los tipos de proceso (i.e. gestionar eficientemente el envío de prendas, mantener la satisfacción de los clientes, diversificar los clientes, minimizar el tiempo de fabricación, aumentar las ventas un 20%), justifican la existencia de los procesos dentro de la organización y explican cómo se llevan a cabo. Habitualmente no pueden medirse directamente y al criterio de medida le llamaremos meta operacional. Por ejemplo, la meta estratégica “mantener la satisfacción de los clientes”, con respecto al proceso “Ventas a Clientes”, puede medirse con la siguiente meta operacional: los clientes están satisfechos si un 80% de los mismos aumenta un 5% su volumen anual de pedidos. Es la organización la que tiene que definir las metas operacionales o el procedimiento de medida que se aplica a sus procesos. La asignación de metas a procesos y su operacionalización se realiza como última actividad.

Con respecto al modelo de procesos, en él se definen los procesos de negocio de la organización, que se pueden definir como el conjunto completo y dinámicamente coordinado de actividades colaborativas y transaccionales que proporcionan valor a sus clientes [18]. De entre los distintos lenguajes y notaciones aparecidos para la definición de procesos de negocio destaca BPMN, desarrollada por BPMI e integrada actualmente dentro de OMG. Debido al amplio apoyo que está recibiendo en la industria, BPMN se ha posicionado como el futuro estándar de facto para el modelado de procesos de negocio. La principal meta de BPMN es suministrar una notación que sea fácil de entender por todos los

usuarios de procesos de negocio. Esto incluye a los analistas de procesos organizacionales que crean las versiones iniciales de los modelos de negocio, a los desarrolladores encargados de la implementación que dará cabida a dichos modelos en forma de sistema de información, o a los encargados de dirigir y gestionar los procesos. Por tanto, BPMN crea un estándar que intenta llenar el hueco entre el modelado de negocio y su implementación. La notación consiste básicamente en un diagrama, llamado BPD (Business Process Diagram), que está basado en técnicas de diagramas de flujo para crear modelos gráficos de operaciones de procesos de negocios. Un BPD se crea a partir de un conjunto de elementos gráficos que hacen posible un desarrollo de diagramas que resulten fáciles de comprender tanto a los analistas de negocio como a los de sistema. Este conjunto se divide en objetos de flujo, conexiones, elementos de piscina, y artefactos [14].

La figura 2 muestra el modelo BPMN para el proceso “tratar pedidos” del caso de estudio, cuya descripción informal es la siguiente: la secretaria selecciona los pedidos que deben servirse de forma inminente. Cada pedido contiene habitualmente un conjunto de patrones (prendas) y un conjunto de centros de envío (direcciones físicas de entrega), mientras que el “packing list” muestra el desglose por centro de envío de las prendas que tienen que servirse. Las prendas se envían a cada centro junto con un albarán de envío por cada caja. El jefe de almacén

selecciona aquellos centros que deben servirse primero (priorización de albaranes), ya que los centros pueden servirse en diferentes días. El albarán se entrega a los operarios que realizan la distribución en cajas y, de acuerdo al stock existente, puede que se introduzca menos cantidad de la solicitada. Así, el jefe de almacén decide si las cajas se envían con el contenido actual o bien se espera a que lleguen nuevos productos terminados. A continuación, y manualmente, modifica el “packing list” que recibió de las secretarias y éstas generan el “packing list” definitivo que se sitúa en cada una de las cajas. Con el conjunto de cajas se forma una expedición, la cual recoge una empresa de transporte externa. Por último las secretarias anotan el material que ha sido entregado, para posteriormente generar la factura. Hay que indicar que toda la información se intercambia en papel.

A la vez que se modela el proceso se modelan también los recursos (objetos de datos en la terminología BPMN) consumidos o generados por el mismo y las relaciones existentes entre ellos, en la forma de un diagrama de clases.

Esta información se utiliza (como se explica después) para derivar el árbol de metas del proceso (fase 2 de la propuesta). Así, el modelo de recursos del caso de estudio es el representado en la figura 3.

Figura 2. Proceso de selección de pedido y envío de género

Caja Envío

Albarán Packing List

Pedido1

1

11..*

1..*

1

11..*

Figura 3. Modelo de recursos del caso de

estudio

Es conveniente aclarar que con los recursos nos referimos a aquellos elementos de datos que utilizan los procesos (como entrada o salida) y que se modelan como clases, ya que tienen impacto en el futuro sistema de información. 5. Modelado de metas

Se puede definir una meta como un objetivo o estado que se debe alcanzar. Su definición hace referencia a una serie de propiedades cuyo cumplimiento se quiere garantizar [12]. El modelado de metas se ha empleado ampliamente en dos contextos. Por una parte, dentro del modelado organizacional las metas guían a la empresa y justifican su comportamiento. Por otra parte, dentro de la ingeniería de requisitos las metas establecen el porqué se necesita y cómo se puede cumplir un requisito (frente a la clásica cuestión de qué es necesario), justifican la presencia de un requisito en una especificación, permiten la generación de alternativas, y aseguran un alineamiento entre la estrategia de negocio de una organización y su sistema de información [12].

La definición de un proceso tiene asociadas una serie de metas que deben satisfacerse durante o tras el desarrollo del mismo [9][11]. Así, en el camino a alcanzar la meta “final” de un proceso pueden participar sub-metas que denotan hitos relevantes dentro de él, de manera que las acciones que los participantes llevan a cabo como parte del proceso contribuyen al cumplimiento de dichas metas [16]. Al usar BPMN para modelar los procesos de negocio muchas de estas metas están declaradas explícitamente en la estructura del proceso, pero pueden existir otras que sean implícitas al proceso y para cuya detección haga falta el uso del modelo de recursos que intervienen en el proceso.

La aproximación presentada propone como mecanismo para la definición de metas de un proceso de negocio la construcción de un árbol de metas en el que se usan los conceptos de meta y tarea de la metodología i* [20], pero no sus modelos. Nosotros únicamente utilizamos una relación de descomposición o refinamiento dentro del árbol, de manera que las

metas se pueden descomponer (con relaciones AND y OR) en nuevas metas o en tareas. El árbol será generado en base a una serie de patrones estructurales identificados en BPMN y mediante un conjunto de guías de transformación (véase la siguiente sección). El árbol se usa como estructura de análisis de la organización, para justificar las decisiones tomadas y para justificar también la presencia de los requisitos en el sistema de información. En la figura 4 se muestran los elementos que forman parte de un árbol de metas creado según nuestra propuesta.

Meta Tarea Descomposición Figura 4. Componentes de un árbol de metas

5.1. Guías para derivar el árbol de metas de un proceso de negocio

Las guías utilizadas en nuestra aproximación son heurísticas basadas en el análisis de los elementos de un BPD y en el modelo de recursos asociado. Para ello, se ha definido la correspondencia entre primitivas o patrones estructurales que componen un BPD junto a su modelo de recursos asociado y la estructura de un árbol de metas.

A continuación se detallan los patrones básicos o más comunes que aparecen en BPMN. El conjunto completo de guías puede consultarse en [5]. Además, también se usará el proceso de selección de artículos de un congreso (figura 5) para ejemplificar las guías que no se aplican directamente sobre el caso de estudio.

Guía 1 (BPD completo): un BPD representa una

meta que se corresponde con la raíz del árbol de metas del proceso. El nombre de la meta coincide con el del BPD que representa. Para el proceso del caso de estudio, la raíz del árbol de metas es “Tratar pedido” (figura 7)

Guía 2 (Objetos de flujo): según su clase, cada

objeto de flujo puede representar una tarea o una meta. Las tareas y eventos con un disparador asociado de BPMN se modelan como tareas, mientras que los subprocesos y pasarelas que representen una decisión en un proceso se modelan como una meta. Respecto al nombre de las metas derivadas de objetos de flujos, éste varía según el tipo del objeto de flujo que se trate. En este sentido, el nombre de una meta o tarea derivada de una actividad coincide con el de ésta. El nombre de una tarea que denote un evento con

disparador hará referencia a la clase de disparador que contenga (mensaje, temporizador, excepción,…) y al tipo de evento que se trate (inicial, intermedio o final). Por último, el nombre de una meta que represente una pasarela dependerá del tipo de flujo que origine (bifurcación, bucle, etc.).

Se considera que sólo representan tareas los eventos que tengan asociados un disparador específico ya que si no fuera así sería porque son eventos cuya ejecución es implícita al propio proceso, como suele ocurrir con los eventos iniciales y finales. Por otra parte, la justificación de que un evento representa una tarea es que los eventos con disparadores podrían representarse en el proceso como tareas en cuyo nombre estuviera explícito el tipo de disparador, como por ejemplo la tarea “Esperar a que haya suficiente género” para el evento del caso de estudio. No obstante, el uso de eventos dentro en un BPD le proporciona mayor expresividad respecto a las tareas que podrían representarlos. A su vez, sólo las pasarelas que denotan decisiones representan metas ya que la finalidad de las que no representan decisiones coincide con la meta que se deriva del proceso.

Por ejemplo, para el proceso de realización de las actividades del tratamiento de pedidos de la empresa de confección, la actividad “Seleccionar pedido” se corresponde con una tarea de mismo nombre y el evento “Suficiente producto disponible” lo hace con una tarea cuyo nombre es “Esperar suficiente producto disponible” (figura 7). Para la selección de artículos de

un congreso, el subproceso “Revisar artículo” representa una meta (figura 6).

Guía 3 (Ramas de ejecución): si una rama de

ejecución de un proceso de negocio no pertenece a su flujo principal o es resultado de una bifurcación (ejecución paralela de ramas), entonces representa una meta que se cumple cuando dicha rama se fusiona con el flujo principal del proceso. Al cumplimiento de la meta que representa la rama de ejecución contribuyen (contribución AND) todas aquellas metas y tareas que se deriven de los elementos que la componen. El nombre de la meta dependerá del criterio del analista. Esta regla se ha establecido porque se considera que la presencia de varias ramas de ejecución en un proceso implica que cada una de ellas persigue la realización de una meta distinta dentro de él. Si no fuera así, no existiría dicha distinción entre ramas de ejecución en el proceso.

En el caso de estudio no existen elementos que encajen con este patrón, pero sí en el proceso de selección de artículos para un congreso. Así, un miembro del comité de programa puede revisar un artículo o redirigir la revisión a un revisor. Cada una de las posibles ramas de ejecución, que no pertenecen al flujo principal del proceso, denotarían las metas “Revisar artículo” (que coincide con la única meta que se deriva de los elementos de esa rama) y “Redirigir revisión a un revisor” (figura 6).

Figura 5. Proceso de selección de artículos para un congreso

Guía 4 (Ramificación): cada una de las metas derivadas de las ramas de ejecución de una ramificación (ejecución excluyente de ramas) de un proceso de negocio contribuyen al cumplimiento de la meta que representa la pasarela que da origen a la ramificación (contribución OR). El nombre de esta última meta deberá ser definido por el analista, de manera que haga referencia tanto a la decisión o comprobación que denote la pasarela como al posible resultado de ella.

Este patrón tampoco se encuentra en el caso de estudio, pero coincide con el caso descrito en la guía anterior para la selección de artículos para un congreso. Como muestra la figura 6, las metas establecidas antes contribuirían a la meta “Realizar la revisión de un artículo”.

Realizar la revisiónde un artículo

OR

Revisar artículo Redirigir revisión a un revisor

Asignar artículoa revisor

AND

Revisar artículo

Permitir otra revisiónsi hay conflictos

OR

Decidir que no se necesita otra revisión

Realizarnueva revisión

Figura 6. Fragmentos del árbol de metas del proceso de selección de artículos para un

congreso Guía 5 (Decisiones “si-entonces”): siendo una

decisión “si-entonces” una decisión en la que una de las ramas que origina siempre se ejecuta y la otra no, contribuyen a la meta que se deriva de la pasarela que representa la decisión (contribución OR) la meta correspondiente a la rama que se ejecuta siempre y otra meta que denota la condición que impediría la ejecución de dicha rama. En este caso, el nombre de la meta derivada de la pasarela debe hacer referencia al hecho de que es posible cumplir la meta que se deriva de la rama. Sobre el nombre de la meta relativa a la decisión, se recomienda que se use un verbo que denote el hecho de que la rama opcional puede ejecutarse o no y a su vez haga referencia a la decisión tomada (posibilitar, permitir,… el cumplimiento de la meta).

En el proceso de selección de artículos para un congreso, tras evaluar las revisiones se puede decidir realizar una nueva revisión o pasar a seleccionar los artículos, que también se realizaría después de la nueva revisión. Este patrón dentro del proceso originaría una meta denominada “Permitir otra revisión si hay

conflictos”, que se refinaría en “Realizar nueva revisión” y “Decidir que no se necesita otra revisión” (figura 6).

Guía 6 (Bucles): los bucles (como iteración de un flujo de secuencia) de un proceso representan una meta cuya meta es el cumplimiento de la condición de finalización del mismo. A esta meta contribuyen las metas y tareas que se deriven de los elementos que integren el bucle (contribución AND). Además, la meta del bucle se corresponde con la de la pasarela en la que se comprueba que la condición de finalización se satisface, por lo que su nombre, asignado por el analista, debe hacer referencia a este hecho.

Este patrón se define como consecuencia de que los elementos que componen el bucle podrían integrarse dentro de un subproceso que fuera una actividad que iterase. Además, dentro de él existen refinamientos. Así, se puede dar el caso de que en un bucle existan elementos que no se ejecutan en todas las posibles trazas del proceso y otros elementos que sí. En este caso la meta del bucle se descompone en dos metas (descomposición OR) que distinguen ambos casos, de forma que las metas o tareas derivadas de los elementos que componen el bucle contribuyen (contribución AND) a las dos o sólo una de las nuevas metas introducidas.

Como ejemplo, y coincidiendo con el refinamiento, a partir del proceso de tratamiento de pedidos se deriva la meta “Tener cantidad de producto suficiente” como resultado del bucle presente, que se descompone en “Comprobarlo cuando se cumple” y “Comprobarlo cuando no se cumple”. Al cumplimiento de la primera de las metas contribuyen las tareas “Situar prendas” y “Validar caja”, y al de la segunda estas dos tareas y “Esperar suficiente producto disponible” (figura 7).

Guía 7 (Elementos de datos): las metas y tareas

derivadas de actividades de un proceso que modifican el estado de un mismo elemento de datos contribuyen (descomposición AND) al cumplimiento de una meta que tiene como objetivo que dicho elemento alcance el último de los estados representados (generar, obtener, establecer,… el elemento en ese estado). Si el estado sólo es modificado por una actividad, se considera que dicha modificación está implícita en la meta o tarea correspondiente a la actividad. Sin embargo, se puede dar el caso de que sólo una actividad modifique el estado de un objeto de datos pero que exista otra meta que contribuya a esta modificación (como es explica la siguiente guía), en cuyo caso sí se define la meta que persigue que el elemento logre un estado determinado.

Adicionalmente, en conjunción con la guía anterior, si todas las actividades que componen un bucle

modifican el estado de un mismo elemento de datos, entonces las metas o tareas derivadas de ellas no contribuyen a la meta que hace referencia al estado final de dicho elemento de datos, sino que lo hace la meta correspondiente al bucle.

Por tanto, en el proceso de la empresa de confección se puede derivar la meta “Colocar albarán”, a la que contribuyen “Priorizar albarán” y “Colocar albarán en caja”, y “Tener cantidad de producto suficiente” contribuye a “Completar las cajas” (figura 7).

Guía 8 (Relaciones de agregación inclusiva): si

existe una relación de agregación inclusiva entre dos objetos (del modelo de recursos), en el caso de que existan metas cuyo fin sea que estos objetos alcancen un determinado estado, entonces la meta correspondiente al elemento componente contribuye al cumplimiento de la del elemento compuesto. Es decir,

las metas relacionadas con los componentes de un elemento también son metas de dicho elemento.

Para el tratamiento de pedidos, dado que existe este tipo de relación entre envío y cajas, la meta “Completar cajas” contribuye a “Generar envío” (figura 7).

Guía 9 (Finalización del árbol de metas): una vez

derivadas las metas y tareas de un proceso de negocio modelado con BPMN y las contribuciones entre ellas, el árbol resultante debe ser finalizado. Así, todas las metas y tareas que tras el seguimiento de las heurísticas anteriores no contribuyan al cumplimiento de al menos una meta, entonces lo hacen a la meta raíz del árbol.

Para el proceso de tratamiento de pedidos de una

empresa de confección, a partir de los patrones estructurales descritos se obtiene el árbol de metas de la figura 7.

Tratar pedido

Modificarpacking list

Generar packing list provisional

Colocar albaránen caja

Generar packing list definitivo

Validar caja Situar prendas Esperar suficiente prod. disponible

Seleccionar pedido Formar envío

AND

Obtener packing list definitivo

AND

Generar envío

AND

Servir pedido

AND

Tener cantidad de producto suficiente

OR

Colocar alabrán

AND

Comprobarlo cuando se cumple

AND

Comprobarlo cuando no se cumple

AND

Completar las cajas

AND

Distribuir las cajas

Priorizar albarán

Figura 7. Árbol de metas para el proceso del caso de estudio

5.2. Etiquetado del árbol de metas

Una vez formado el árbol de metas de un proceso

de negocio, el siguiente paso es establecer las metas que la organización desea automatizar. A cada uno de los elementos hoja del árbol se le asigna una etiqueta, representado el efecto que se quiere que la introducción del nuevo sistema tenga sobre ella. Dicha etiqueta puede ser para automatizar (“A”) si se desea que el sistema de información dé soporte a una meta o tarea, cesar (“C”) si se desea que el sistema de información realice autónomamente una meta o tarea que antes requería intervención humana, o mantener (“M”) si se desea que la meta o tarea se satisfaga como hasta ese momento y no se automatice. En el caso de un elemento etiquetado como a cesar, se deben definir las tareas que contribuyen a dicho cese (etiquetadas con “SI”) y que realizará el sistema de información por sí solo.

A continuación se propagan las etiquetas desde los elementos descendientes a las metas de los niveles superiores según la siguiente lógica. Si algún elemento descendiente tiene la etiqueta de automatizar, entonces la meta padre también la tiene. Si todos los descendientes tienen la misma etiqueta de cesar o de mantener, entonces la meta padre tiene la misma

etiqueta que su descendencia. Por último, si las etiquetas de los elementos descendientes son combinación de cesar y mantener, entonces la meta padre se etiqueta como a automatizar, puesto que se satisfará gracias a la contribución de metas o tareas que se mantienen y otras cuyo cumplimiento se debe a la intervención autónoma del sistema de información (las tareas descendientes de las etiquetadas como a cesar).

Durante este proceso de etiquetado pueden surgir distintas alternativas respecto a la selección de cada etiqueta, dependiendo de lo que se quiera de cada una de las metas y tareas, y respecto a las tareas a introducir para cesar otra. Implícitamente, todos los elementos tienen las tres alternativas establecidas (mantener, automatizar, cesar), pero sólo será necesario representar en el árbol las alternativas de las metas o tareas que realmente lo necesiten, por su importancia o efecto en el sistema. En este caso, el elemento del árbol se descompone (descomposición OR) en las etiquetas alternativas que se estimen oportunas. Se escogerá aquella opción que mejor encaje con los deseos y necesidades de la organización, de forma que se elimina del árbol la descomposición en alternativas y se le asigna al elemento la etiqueta correspondiente.

Además, se puede producir una reingeniería en los procesos. Por una parte, las tareas que se etiquetan

Tratar pedido

Modificarpacking list

Generar packing list provisional

Colocar albaránen caja

Generar packing list definitivo

Validar caja Situar prendas Esperar suficiente prod. disponible

Seleccionar pedido Formar envío

AND

Obtener packing list definitivo

AND

Generar envío

AND

Servir pedido

AND

Tener cantidad de producto suficiente

OR

Colocar alabrán

AND

Comprobarlo cuando se cumple

AND

Comprobarlo cuando no se cumple

AND

Completar las cajas

AND

Distribuir las cajas

Priorizar albaránC

Generar p.l. prov.automáticamente

Avisar del albarán a tratar

Ordenar albaranespor prioridad

Avisar de lamodificacción p.l.

Ordenar pedidospor fecha y cliente

Avisar delpedido a tratar

AND

AND

A

A

A A

AAA

A

SI

SISI

SISI

SI

A

A

AA

A

CCC

M M

MImprimir albarán

A

A

M

C

SI

Etiquetas del árbol de metas

Automatizar el elemento

Elemento que satisface autónomamente el SI

Cesar el elemento

Mantener el elemento sin automatizar

Figura 8. Árbol de metas etiquetado para el caso de estudio

para automatizarlas pueden conllevar la introducción de nuevas actividades en el proceso. Este hecho es debido que, al trabajar con un sistema software, pueden aparecer nuevas acciones en el proceso que son necesarias para su uso o que antes no se realizaban porque carecían de significado o no eran posibles. Por ejemplo, en una organización puede aparecer alguna actividad relacionada con el mantenimiento o uso del sistema de información (arranque, finalización, alguna comprobación física, etc.) o alguna actividad que se lleva a cabo porque el sistema de información posibilita su realización (consulta de estadísticas, monitorización de algún elemento, etc.). Por otra parte, los elementos que hayan originado tareas etiquetadas como a cesar desaparecerán del proceso. Como resultado se genera un nuevo árbol de metas del proceso de negocio, del que desaparecen las metas y tareas etiquetadas como a cesar y se reestructura el proceso.

Para el caso de estudio, se obtiene el árbol de metas etiquetado de la figura 8, en el que se ha introducido la tarea “Imprimir albarán”, ya que es necesaria una copia impresa del albarán correspondiente para cumplir la meta “Colocar albarán”.

Una vez determinadas las metas y tareas del proceso de negocio a las que debe dar soporte el sistema de información, se obtiene el árbol de metas de éste (correspondientes a las metas con las etiquetas “A” o “SI”). El árbol de estas metas es el resultado de “podar” las metas y tareas que se mantienen como antes y las que se desean cesar. Las tareas introducidas por el cese de otra y etiquetadas con “SI” pasan a contribuir a la meta antecesora más cercana etiquetada como a automatizar, y se mantienen las etiquetas de las metas que no se eliminan.

6. Modelado de requisitos

El modelo de casos de uso [15] se deriva a partir del árbol de metas obtenido anteriormente. Cada caso de uso denotará un requisito establecido en el árbol de metas del sistema. En primer lugar, los casos de uso se agrupan en paquetes, de manera que cada paquete se corresponde con un BPD y en él estarán aquellos casos de uso que se deriven de su árbol de metas. En segundo lugar, los requisitos se corresponden con las tareas del árbol, las cuales representan servicios que debe ofrecer el sistema. El conjunto de casos de usos que se obtiene en este momento del proceso puede ser modificado si el analista así lo estimase, cambiándoles el nombre para mejorar su expresividad o refinando o abstrayendo los requisitos según el nivel de detalle que considere conveniente. Además, se pueden introducir relaciones de generalización, inclusión o extensión entre los casos de usos.

Por otra parte, el analista tiene que consultar el modelo de recursos en esta fase. Este hecho se debe a que puede considerar necesario la introducción de algún caso de uso relativo a la gestión (alta, baja, modificación o consulta) de los recursos que manipula el sistema. La razón para ello es que sean requisitos necesarios en el sistema, y no estén definidos implícita o explícitamente en ninguno de los casos de uso derivados hasta ahora. El analista también puede definir casos de uso para la gestión del sistema por parte de un administrador o para la distinción entre tipos de usuarios.

Una vez identificados los requisitos, el siguiente paso es asignarlos a un actor (o varios, dependiendo del caso) responsable de él. En el caso de que la tarea correspondiente a un requisito posea la etiqueta “SI”, la realización de éste puede caer bajo la responsabilidad de un actor “Reloj”, si el requisito se

Administrador Usuario

Reloj

Jefe de almacén

Empleado del almacén

Gestión de usuarios

Generar packing list provisional

Ordenar albaranes

Avisar del pedido a tratar Ordenar

pedidos

Avisar del albarán a tratar Identificarse en

el sistema Modificar packing list

Avisar de la modificación del

packing list

Formar envío

Consultar albarán

Imprimir albarán

<<include>>

<<include>>

Figura 9. Modelo de casos de uso asociado al proceso del caso de estudio

ejecuta periódica y autónomamente por el sistema cuando se cumple una condición, o que el requisito se incluya dentro de otro (relación “<<include>>” entre casos de uso) que provoca su activación en el sistema. Si la etiqueta es “A”, el actor responsable será el participante en el proceso que represente la calle en la cual se encuentra el elemento que origina la tarea. También se deben establecer los actores responsables de los posibles casos de uso definidos para la gestión de los recursos, y el analista puede definir nuevos actores y relaciones entre ellos, en este caso de generalización.

Como resultado de estos pasos, se obtiene el diagrama de casos de uso de la figura 9 como modelo de requisitos para el caso de estudio planteado, correspondiente al paquete “Tratamiento de pedidos”. Respecto a los participantes en el proceso, se han introducido los actores “Reloj”, “Administrador”, “Usuario” y “Empleado de almacén”, para realizar funcionalidad automática y periódica en el sistema, de gestión de los usuarios del sistema, de identificación, y común al jefe de almacén y operario, respectivamente. En este último caso, el caso de uso “Consultar albarán” se ha introducido en sustitución de “Validar caja” y “Distribuir las cajas”, tareas que aparecen en el árbol, puesto que ésa es la funcionalidad que realmente se necesita. Además, se han establecido diferentes relaciones de herencia entre actores (tienen funcionalidad común) y de inclusión entre casos de uso (uno provoca la ejecución de otro). 7. Trabajos relacionados

Dentro del área de desarrollo de software existen propuestas que consideran el modelado de negocio como fase inicial del proceso de desarrollo. Algunos de estos métodos que pueden encontrarse en la literatura son: i* [20], KAOS [4], y las propuestas de Ericsson [7] y Marshall [13] basadas en el lenguaje unificado de modelado (UML) [15]. Las características principales de las dos últimas es que elaboran modelos de negocio con constructores cercanos al mundo del desarrollo de software y que algunos aspectos de la organización (como la tecnología que implementará los procesos de negocio o la relación entre las distintas vistas de la misma) no quedan claramente especificados.

El framework i* permite especificar modelos de negocios centrándose en las dependencias que existen entre los actores de la organización. Los modelos del framework i* son considerados estratégicos en el sentido de que cada actor no sólo está interesado en lograr sus metas inmediatas, sino que se interesa también en las relaciones que tiene con otros actores

ya que puede depender de que otros actores le proporcionen servicios o recursos. Pensamos que los modelos de i* son complejos y no escalables cuando se aplican a casos reales de cierta entidad.

KAOS permite construir modelos de requisitos a partir de las metas organizacionales. Esta aproximación está soportada por un marco formal que define cada término de forma rigurosa. La principal contribución de KAOS es la demostración de que los requisitos se corresponden con las metas del futuro sistema. El principal inconveniente es que no proporciona ningún mecanismo para representar la estructura de la organización y como consecuencia de ello no permite efectuar, por ejemplo, un análisis de reingeniería de procesos.

Además, en ediciones previas del WER se han presentado artículos en líneas de investigación similares. Por una parte, en [19] se propone realizar la elicitación de requisitos a partir de procesos de negocio y de sus metas, pero no se operacionaliza la descomposición de las metas. Por otra parte, en [6] y [17] se presentaban propuestas para la generación automática de modelos de casos de uso a partir de modelos de procesos de negocio y para guiar la definición de casos a partir de modelos organizacionales definidos con i*, respectivamente, pero creemos que tienen el inconveniente de que los modelos de casos de uso que generan son demasiados complejos. 8. Conclusiones y trabajos futuros

El artículo presenta una aproximación que enriquece las aproximaciones de desarrollo basadas en metas con un modelo de procesos, proponiendo un conjunto de guías o heurísticas que permiten derivar un modelo de requisitos a partir de un modelo de procesos mediante la utilización de un árbol de metas intermedio. La propuesta permite que los desarrolladores identifiquen de un modo sistemático y participativo (ya que intervienen diversos agentes como los gestores de negocio, analistas organizacionales y analistas de sistemas de información) los requisitos del sistema que dará soporte a la organización.

Además, la propuesta asegura el alineamiento entre la estrategia de negocio de la organización y su sistema de información, gracias a la trazabilidad entre los distintos modelos. Los requisitos de éste son definidos a partir de las metas de los procesos de negocio, los cuales a su vez se basan en las metas estratégicas de la organización.

En la actualidad el trabajo está siendo aplicado a otros casos de estudio para evaluar el alcance del

método y de las heurísticas propuestas. La investigación aquí presentada forma parte de un convenio con la empresa Care Technologies [3] cuyo objetivo principal es la construcción de una herramienta y de un método asociado que permita transformar modelos organizacionales en modelos requisitos utilizables en un entorno de generación automática de código. 9. Referencias [1] Bleistein, S., K. Cox, J. Verner. “Strategic Alignment in Requirements Analysis for Organizational IT: An Integrated Approach”, 20º ACM Symposium on Applied Computing, 2005, Santa Fe, USA [2] Bubenko, J.A. “Experiences from Testing Enterprise Modelling- A Requirements Acquisition Method”, Dagstuhl Seminar System Requirements: Analysis Management, and Exploitation, Dagstuhl, Alemania, 1994 [3] Care Technologies. http://www.care-t.com [4] Dardenne, R., S. Fickas, A. Van Lamsweerde. “Goal-directed Requirements Engineering”, Proc. 4º ACM Symposium on the foundation of Software Engineering, 1996, San Francisco, USA [5] De la Vara, J. L. “Derivación de modelos de requisitos a partir de modelos organizacionales”. Proyecto Fin de Carrera, Facultad de Informática, Universidad Politécnica de Valencia, 2006 [6] Dias, F., et al. “Uma Abordagem para a Transformação Automática do Modelo de Negócio em Modelo de Requisitos”, IX Workshop on Requirements Engineering (WER’06), 2006, Río de Janeiro, Brasil [7] Eriksson, H., M. Penker. Business Modeling with UML: Business Patterns at Work, OMG John Wiley and Sons, 2000. [8] Jackson, M. “The Role of Software Architecture in Requirements Engineering- Position Statement”, RE’1994. IEEE Computer Society Press, pp. 241

[9] Kavakli, E., P. Loucopoulos. “Goal-Driven Business Process Analysis Application in Electricity Derregulation”, Information Systems, 24(3), 1999, pp. 187-207 [10] Kavakli, E., P. Loucopoulos. “Goal Modeling in Requirements Engineering: Analysis and Critique of Current Methods”, Information Modeling Methods and Methodologies, 102-124, 2005 [11] Kueng, P., P. Kawalek. “Goal-based business process models: creation and evaluation”, Business Process Management, 3(1), 1997, pp.17-38 [12] Lamsweerde, A. van. “Goal-Oriented Requirements Engineering: A Guided Tour”, Proc. 5º IEEE International Symposium on Requirements Engineering, 2001, Toronto, Canadá [13] Marshall, C. Enterprise Modeling with UML, Addison-Wesley, 2000. [14] OMG. Business Process Modeling Notation (BPMN) Specification (online), febrero 2006, http://www.omg.org [15] OMG. Unified Modelling Language: Superstructure Version 2.0 (online), julio 2005, http://www.omg.org [16] Ould, M. A. Business Processes: Modelling and Analysis for Re-engineering and Improvement, John Wiley & Sons, 1995 [17] Santander, V., J. Castro. “Desenvolvendo Use Cases a partir de Modelagem Organizacional”, III Workshop on Requirements Engineering (WER’00), 2000, Río de Janeiro, Brasil [18] Smith, H., P. Fingar. Business Process Management: The Third Wave, Meghan-Kiffer Press, 2003 [19] Villanueva, I., J. Sánchez, O. Pastor. “Elicitación de requisitos en sistemas de gestión orientados a procesos”, VIII Workshop on Requirements Engineering (WER’05), 2005, Porto, Portugal [20] Yu, E. “Modeling Strategic Relationships for Process Reengineering”, PhD Thesis, University of Toronto, 1995