IDEF Una alternativa para modelamiento de negocio con RUP

Resumen

Muchos de los proyectos de desarrollo de software fracasan o el resultado final no es el esperado, para el cliente o usuario final, o para los propios desarrolladores. Para el cliente un proyecto de desarrollo de software puede resultar infructífero porque se demoró más del tiempo esperado o peor aún, porque el software resultado no resuelve los problemas para los cuáles se encargó.

Varios son los factores que pueden conllevar al fracaso de un proyecto de desarrollo de software. El modelamiento del negocio en la etapa de concepción de un proyecto de desarrollo de software es una de las actividades más importantes, y que muchas veces no se lleva a cabo con la profundidad necesaria, provocando esto que no haya una total comprensión de los procesos a informatizar y un falso sentido de entendimiento entre los clientes (o usuarios) y el equipo de desarrollo respecto al trabajo a realizar.

La disciplina Modelamiento del Negocio de RUP (Rational Unified Process) propone un conjunto de artefactos para modelar los procesos de una organización, la elaboración de todos estos artefactos puede resultar lenta y engorrosa, contribuyendo negativamente a un efectivo paso por esta disciplina. El presente trabajo propone una alternativa a los artefactos de la disciplina Modelamiento del Negocio de la metodología RUP: IDEF, es una técnica de modelado de sistemas usando una estructura gráfica específica. Abarca desde la modelación de la información hasta el análisis y diseño orientado a objetos.

Palabras claves

IDEF, Proceso de Negocio, Modelamiento de Negocio, Desarrollo de Software, RUP

Introducción

A pesar de la importancia que tiene el conocimiento de los procesos de negocio que sustentarán un sistema informático, es una práctica común demeritar la etapa en que se captura esta información durante el ciclo de desarrollo de un software. Es usual que los equipos de desarrollo, basados en las exigencias de los clientes respecto a la rapidez con que necesitan tener el producto de software en explotación, dediquen poca atención al total entendimiento del negocio. Si se tiene en cuenta que la gran mayoría de las organizaciones no representan esquemáticamente cómo son sus procesos y que algunas de las metodologías de desarrollo de software más utilizadas, como es el caso del Proceso Unificado de Desarrollo (RUP, por sus siglas en inglés), proponen una gran cantidad de artefactos para esta modelación cuya construcción puede volverse lenta y engorrosa, entonces se crean todas las condiciones para que no se modele el negocio con la rigurosidad que amerita.

El resultado de esta práctica son productos de software enfocados a necesidades o requerimientos planteados por un cliente, que en ocasiones no es capaz de determinar exactamente como puede un sistema de software mejorar su línea de productos o servicios. Además, es común que se obtengan productos de software con costos de implantación extremadamente altos y alejados de la objetiva realidad de la entidad que lo pretende utilizar. Los desarrolladores tienden a ser creativos buscando su realización profesional en la creación de sistemas informáticos ideales, a la vez que se alejan de la realidad del negocio y de los clientes.

La capacidad tecnológica y la situación económica de la organización a automatizar no son el objetivo fundamental del modelamiento de negocio que propone RUP. No obstante, tener en cuenta estos elementos procurando incidir en ellos favorablemente, si debe ser objetivo del producto de software a realizar, de ahí entonces que durante esta etapa inicial se considere extremadamente importante que el equipo de desarrollo se apropie de este conocimiento adicional.

En este artículo se propone la integración de algunas técnicas IDEF (Integrated Definition Methods) con la metodología RUP, con el objetivo de utilizar dichas técnicas como una alternativa a los artefactos que propone la disciplina Modelamiento del Negocio de esta metodología. Es necesario señalar que la información que se presenta sobre las técnicas de modelación IDEF no es suficiente para aplicar las ideas aquí expuestas, posteriormente deberá profundizarse en el estudio de las mismas. Esta propuesta esta basada en la experiencia de los autores durante la producción de un software a la medida para la República Bolivariana de Venezuela, producto de los acuerdos Cuba-Venezuela a la luz del ALBA.

Desarrollo

IDEF

Durante los años 70 las fuerzas áreas de los EEUU desarrollaron un programa para la fabricación integrada asistida por computadora (Integrated Computer Aided Manufacturing, ICAM). El programa ICAM identificaba las necesidades de mejoras en las técnicas y análisis de la comunicación para personal involucrado en la producción. El resultado del proyecto ICAM es una serie de técnicas conocidas como IDEF (Integrated Definition Methods). En la concepción inicial se incluían:

1. IDEF0: Utilizado para la representación de actividades o procesos.
2. IDEF1: Utilizado como modelo de representación y estructuración de la información.
3. IDEF2: Utilizado para representar modelos que varían con el tiempo.

En 1983, las fuerzas aéreas de los Estados Unidos programaron un sistema integrado de ayuda de la información basado en IDEF1, creando el IDEF1X (IDEF1 ampliado) [1].

Con el devenir de los años y la utilización de estas técnicas, IDEF siguió su desarrollo y nuevas versiones aparecieron: IDEF3, IDEF4 e IDEF5. Actualmente existen varias herramientas que facilitan la modelación con estas técnicas.

IDEF0

IDEF0 es una técnica de modelación concebida para representar de manera estructurada y jerárquica las actividades que conforman un sistema o empresa, y los objetos o datos que soportan la interacción de esas actividades. Un modelo IDEF0 se compone de una serie jerárquica de diagramas que permiten mediante niveles de detalle, describir las funciones especificadas en el nivel superior. En las vistas superiores del modelo la interacción entre las actividades representadas permite visualizar los procesos fundamentales que sustentan la organización. Los elementos gráficos utilizados para la construcción de los diagramas IDEF0 son cuadros y flechas.

La semántica de utilización de estos elementos gráficos es la siguiente:

Actividad: se representa con un cuadro, indica una función, proceso o transformación.

Entrada: se representa con una flecha entrando por el lado izquierdo de la actividad, indica los materiales o informaciones que se transformarán en la actividad para obtener la salida.

Salida: se representa con una flecha saliendo del lado derecho de la actividad, indica los objetos o informaciones producidos por la ocurrencia de la actividad.

Control: se representa con una flecha entrando por la parte superior, indica las regulaciones que determinan si una actividad se realiza o no. Ej: normas, guías, reglas, políticas, etc.

Sujeto: se representa con una flecha entrando por la parte inferior, indica los recursos que ejecutan una actividad. Ej: personas, maquinarias, etc.

Ventajas de IDEF0 para modelar procesos de negocio

• Permite representar el proceso cronológicamente. Se describe el flujo orientado al cliente final de ese negocio, cruzando todas las actividades de la organización que dan cumplimiento a la solicitud de producto o servicio que realiza el cliente, representando así la «cadena de valor» de la empresa (se modela un proceso por cada tipo de producto o servicio que brinda la empresa).
• Es una notación simple (basada en cuadros y flechas) que cualquier empleado puede usar para describir qué hace en el negocio [2]. Involucrar a los empleados de la organización en la modelación del negocio permite ahorrar tiempo simultaneando el trabajo en varias áreas, así como obtener un modelo más fiel ya que ha sido elaborado por sus protagonistas. Permite incorporar en el flujo los datos que entran y salen de las actividades, así como las reglas del negocio y los actores, todo en la misma vista.
• Permite descomponer una actividad como un proceso a su vez.
• Permite descubrir problemas de organización en el negocio que deben ser arreglados, para «no informatizar el caos» sino organizar el negocio y luego informatizarlo.

IDEF3

IDEF3 es una técnica de modelación para representar el flujo de trabajo de un proceso, así como sus objetos participantes a partir de la descripción dada por un experto. Permite documentar a nivel de detalle un proceso facilitando su análisis a través de la identificación y captura del conocimiento crítico del mismo [3].

Los componentes fundamentales que emplea IDEF3 en su representación son: unidad de trabajo, ligas, conexiones y referencias.

Unidad de Trabajo: representa una actividad, siempre tiene un identificador único y puede tener una referencia asociada a una actividad IDEF0.

Ligas: representan relaciones restrictivas entre actividades, son unidireccionales, pueden iniciar y terminar en cualquier parte de la actividad (“cuadro”), debe estar etiquetada.

Existen tres tipos de ligas:

Precedencia temporal

El proceso origen debe concluir antes de que el proceso destino pueda comenzar.

Flujo de objeto

Enfatiza la participación de un objeto entre dos procesos, indicando precedencia temporal, el proceso origen debe concluir antes de que el proceso destino pueda terminar.

Relacional

Existencia de una relación entre los procesos ligados. El proceso origen comenzará antes que el proceso destino termine.

Conexiones: sirven para representar:

• Los puntos en los que un proceso se ramifica en múltiples subprocesos.
• Los puntos en los cuales múltiples procesos convergen en un solo proceso. Ÿ
• La temporalidad (sincronía/asincronía) en el flujo de actividades de un proceso.

Tipos de ramificaciones:

Divergencia (Fan-out): Distribuye el flujo del proceso, la terminación de una actividad causa la activación de múltiples actividades.

• Convergencia (Fan-in): La terminación de múltiples actividades consolida el inicio de una actividad.

Referencias: representan símbolos especiales para dirigir la atención del lector a otras partes importantes del modelo.

Algunos de los diferentes tipos de referencias que existen son:

• Object: Describe la participación de un objeto importante en una actividad.
• GOTO: Construye ciclos (repetir secuencia de actividades).
• UOB (UnitOfBehavior): Incluye una actividad ya descrita sin implicar un ciclo.
• Note: Documenta cualquier información general importante de alguna gráfica (actividad, conexión).
• ELAB (Elaboration): Documenta de manera detallada alguna gráfica.

Ventajas de IDEF3

• Permite documentar procesos para estandarización o como guías para nuevos integrantes del proceso y así reducir la curva de aprendizaje.
• Provee un mecanismo para capturar la secuencia temporal de un proceso y la lógica de decisión que lo afecta.
• Sirve como una herramienta para analizar procesos existentes.
• Permite diseñar y probar nuevos procesos antes de iniciar cambios reales que pueden ser muy costosos.

Una simple comparación entre ambas técnicas permite ilustrar como se complementan, incidiendo de manera diferente sobre los mismos aspectos, lo que permite abordarlos en toda su amplitud.

IDEF en la metodología RUP para modelar el negocio

Descripción de las actividades

Modelar Procesos Globales:

• Implicados: Clientes y Equipo de Desarrollo.
• Objetivo: Identificar los procesos de negocio de la organización, sus objetivos, recursos implicados, etc.
• Técnica: IDEF0.
• Descripción: En esta actividad se identifican los procesos de negocio de la organización por medio de encuentros con los directivos y trabajadores implicados. Se le explica a todos los directivos y trabajadores implicados los elementos gráficos que componen la técnica IDEF0 y se elabora de manera conjunta el Modelo de Procesos correspondiente al AS – IS de esta técnica. El AS – IS no es más que la modelación del cómo ocurren de manera global los procesos de la organización en su situación actual.

Identificar Actividades Superfluas:

• Implicados: Equipo de Desarrollo.
• Objetivo: Identificar las actividades superfluas que puedan existir en los procesos de la organización.
• Técnica: Análisis.
• Descripción: En esta actividad se analiza el Modelo de Procesos realizado de la organización, para identificar las actividades que puedan considerarse superfluas. Una actividad superflua es aquella de la que se puede prescindir sin afectar el resultado final del proceso modelado, ya sea porque no genera resultado alguno o porque el resultado obtenido puede formar parte de otra actividad eliminándose así un sujeto del proceso.

Modelar Procesos Globales Mejorados:

• Implicados: Equipo de Desarrollo.
• Objetivo: Actualizar el Modelo de Procesos con las mejoras identificadas.
• Técnica: IDEF0.
• Descripción: En esta actividad se actualiza el Modelo de Procesos realizado de la organización, eliminando las actividades superfluas identificadas. Se añade al modelo una breve descripción del como se realiza cada actividad. En este punto se realizan en el modelo los cambios que impliquen una propuesta de mejora en los procesos. Estos cambios deberían basarse en el estudio del arte realizado previamente a la etapa de modelamiento del negocio, por parte del equipo de desarrollo sobre procesos de negocio similares a nivel nacional e internacional. Este nuevo modelo se corresponde con el Modelo de Procesos TO – BE de IDEF0.

Validar Mejoras Propuestas con el Cliente:

• Implicados: Clientes y Equipo de Desarrollo.
• Objetivo: Establecer un acuerdo entre los clientes y el equipo de desarrollo acerca de cómo deberían ser los procesos de la organización, antes de pasar a su informatización.
• Técnica: Reunión.
• Descripción: En esta actividad el equipo de desarrollo presenta el Modelo de Procesos Globales Mejorados al cliente, para que este indique su conformidad con la propuesta o realice los señalamientos pertinentes.

Detallar Actividades Complejas:

• Implicados: Equipo de Desarrollo.
• Objetivo: Modelar en detalle las actividades de mayor complejidad, necesarias para la automatización de la organización.
• Técnica: IDEF3.
• Descripción: En esta actividad se actualiza el Modelo de Procesos realizado de la organización, eliminando las actividades superfluas identificadas. En este punto se pueden realizar en el modelo otros cambios que impliquen una propuesta de mejora en los procesos del cliente. Estas propuestas de mejoras adicionales deberían basarse en el estudio del arte realizado por el equipo de desarrollo sobre procesos similares a nivel nacional e internacional, previo a la etapa de modelamiento del negocio.

Validar Descripción Detallada con el Cliente:

• Implicados: Clientes y Equipo de Desarrollo.
• Objetivo: Establecer un acuerdo entre los clientes y el equipo de desarrollo acerca de cómo se realizan en detalle las actividades complejas de la organización que se deberán automatizar.
• Técnica: Reunión.
• Descripción: En esta actividad el equipo de desarrollo presenta la descripción detallada de las actividades complejas seleccionadas al cliente, para que este indique su conformidad con la propuesta o realice los señalamientos pertinentes.

Establecer Fronteras del Proyecto:

• Implicados: Clientes y Equipo de Desarrollo.
• Objetivo: Establecer un acuerdo entre los clientes y el equipo de desarrollo acerca de cuáles procesos de la organización se informatizarán.
• Técnica: Reunión.
• Descripción: En esta actividad se define por medio de un debate entre los clientes y el equipo de desarrollo cuales serán los procesos a informatizar. Para esto se toma como base el Modelo de Procesos Globales Mejorados.

Referencias

[1] Álvarez Romero, Eduardo; Pueyo, Daniel. Integration Definition For Funcion Modeling (IDEF0) tomado de

[2] García, Ana M. Modelado de procesos de negocio. Notas del curso.

[3] Modelado de Procesos, Teoría de Sistemas, Universidad de Valparaíso tomado de

Bibliografía

IDEFØ IDEF Family of Methods A Structure Approach to Enterprise Modeling and Analysis http://www.idef.com/