|
| |
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ó.
Publicación enviada por Ing. Yisel Alonso Riverón
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.

And Asíncrono: todas las actividades que suceden a la conexión iniciarán
And Síncrono: todas las actividades que suceden a la conexión iniciarán al mismo
tiempo.
Or Asíncrono: una o más de las actividades que suceden a la conexión iniciarán.
Or Síncrono: una o más de las actividades que suceden a la conexión iniciarán al
mismo tiempo.
XOR: Solo una de las actividades que suceden a la conexión ocurrirá.
-Convergencia (Fan-in): La terminación de múltiples actividades consolida el
inicio de una actividad.

And Asíncrono: todas las actividades precedentes deben terminar.
And Síncrono: todas las actividades precedentes deben terminar al mismo tiempo.
Or Asíncrono: una o más de las actividades precedentes terminarán.
Or Síncrono: una o más de las actividades precedentes terminarán al mismo
tiempo.
Or: Exactamente una de las actividades precedentes terminará.
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 http://dmi.uib.es/~burguera/download/IDEF0trabajo.doc
[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 http://www.decom-uv.cl/~INF203/docs/11%20-%20TGS%20-%20ModProcesos.ppt
BIBLIOGRAFÍA
· IDEFØ http://www.pdca.es/pruebas/idef.html
· IDEF Family of Methods A Structure Approach to Enterprise Modeling and
Analysis http://www.idef.com/
AUTORES:
Ing. Yisel Alonso Riverón [1]
Ing. Yaneisy Cruz Navarro [2]
Ing. Yordanis Tornés Medina [3]
DATOS DE LOS AUTORES
[1]Ing. Yisel Alonso Riverón
Ingeniero Informático graduado en el año 2004 en el Instituto Superior
Politécnico José Antonio Echeverría (CUJAE). Se ha desempeñado como profesora en
la Universidad de Ciencias Informáticas (UCI) de las asignaturas Ingeniería de
Software I e Ingeniería de Software II desde su graduación en Julio del 2004.
Alcanzó la categoría de profesor instructor en Octubre del 2005.
[2]Ing. Yaneisy Cruz Navarro
Ingeniero Informático graduado en el año 2004 en el Instituto Superior
Politécnico José Antonio Echeverría (CUJAE). Se ha desempeñado durante los
cuatro años de trabajo como profesor en la Universidad de Ciencias Informáticas
(UCI) de las asignaturas de Ingeniería de Software I e Ingeniería de Software II.
[3]Ing. Yordanis Tornes Medina
Ingeniero Informático graduado en el año 2003 por el Instituto Superior
Politécnico José Antonio Echeverría (CUJAE). Durante los cuatro años de vida
laboral que han transcurrido, se ha desempeñado como profesor de programación en
la Universidad de las Ciencias Informáticas (UCI), vinculado siempre a la
producción, primero como especialista de la Dirección de Informatización de la
Universidad, donde trabajo en diversos proyectos para la informatización del
campus universitario y luego como especialista de la Dirección General de
Producción de la Infraestructura Productiva (IP).
Ciudad de la Habana, Cuba. 14 de febrero de 2008.
Compartir 
Publicación enviada por Ing. Yisel Alonso Riverón
Contactar mailto:ytornes@uci.cu
Código ISPN de la Publicación EkpFykypVpwqovrpHa
Publicado Thursday 21 de February de 2008
Ultimas Publicaciones en ilustrados.com
ilustrados.com nace con el fin difundir el conocimiento publicando trabajos de investigación, monografias, tesis, presentaciones powerpoint y afines. Publicar trabajos en ilustrados.com ha alcanzado prestigio y reconocimiento internacional siendo cada vez más el número de académicos, empresas, investigadores, científicos que consultan las publicaciones de nuestro portal.
|