A los colegas que estudiaron Ingeniería o Licenciatura en Sistemas, recordarán la materia de Fundamento de Ingeniería de Software, materia que tomé en mi caso (Ingeniero). Sobre esta materia se plantean temas cómo ciclos de vida del software, métricas de medición, técnicas de modelado, herramientas case y un largo etcétera. Entre toda la información que recibimos en dicha materia recordarán los diagramas de flujo para modelar un algoritmo (Conjunto ordenado de instrucciones sistemáticas que hallar la solución de un tipo de problemas), de los cuales son muy utilizados hasta la fecha, pero desde mi perspectiva son insuficientes, tema del cual quiero compartir mi opinión.
Durante los 14 años que he estado trabajando diseñando y creando software para resolver temas de integración en diferentes productos, he llegado a utilizar estos diagramas (Diagramas de Flujo) y siempre me había quedado con la sensación de que requería algo más para detallar excepciones, eventos asíncronos, interrupciones, y todo esa clase de situaciones que los desarrolladores de hoy en día nos encontramos. Fue entonces cuando me acerque al estándar UML (Unified Modeling Language ), un estándar diseñado por la Object Managment Group (OMG).
UML no solo adaptó a sus estándares la metodología de modelar un algoritmo de los Diagramas de Flujo que nos enseñaron en los años 80's y 90's, sino que también extendió su capacidad de modelado a un entorno de Objetos, llegando a obtener diversos tipo de diagrama de propósito especifico, agrupados en dos principales conjuntos: Estáticos y Dinámicos.
Es con los diagramas Estáticos que UML nos llevó a adentrarnos en las necesidades del cliente con la implementación de los diagramas de Casos de Uso, que no son más que un esfuerzo por hacerle ver al desarrollador que parte del negocio se requiere atender con la implementación con el sistema de información que se está diseñando. Mientras que los diagramas de clases nos permiten ubicar las diferentes entidades que interactuarán en el nuevo sistema de información que se esta modelando.
Por otro lado, los diagramas Dinámicos nos permiten apreciar la interacción con las diversas entidades que se encuentran en el sistema de información, interacción que se lleva a cabo a través del tiempo, es por eso que se conocen como diagramas Dinámicos. Este tipo de característica nos permite ver si nuestro diseño presenta el comportamiento deseado, tomando como referencia el problema que queremos solucionar.
Pero a medida que aumentaba mi interacción con el cliente y su usuario final, empecé a tener las mismas dudas que me surgieron con los Diagramas de Flujo, específicamente al entender el entorno de negocio en el cual se quiere implementar el sistema informático.
Si bien, UML contiene la sección de Casos de Uso, que es un diagrama que describe como interactuarán los diferentes actores con el nuevo sistema de información, es una vista estática y que describe una caso bajo una narrativa, y es ahí donde radica su punto débil. El ser humano es una persona que puede entender de mejor manera una situación o un mensaje si este se representa de manera gráfica, es por eso que los modelos son de gran ayuda. Es por esta razón que me dediqué a la tarea de buscar como modelar un caso de uso bajo un modelo dinámico y gráfico, características que permitirían al desarrollador entender más a fondo y de manera más rápida el entorno del negocio y su problemática a solucionar. El resultado de mi búsqueda terminó en los diagramas BPMN (Business Process Model & Notation), estándar que también ha sido establecido por la OMG.
BPMN fue creado para modelar procesos de negocio, en los cuales se encuentran diversas interacciones. Su principal característica es la de representar un proceso de negocio de manera gráfica evitando crear documentos de narrativas largas y complejas, como se viene realizando en los Casos de Uso (UML) o en los diagramas de Cross Funtional. También es una realidad que ha estado creciendo el número de empresas que han adoptado este estándar para modelar sus procesos internos.
Este tipo de modelado (BPMN) permite a las personas el conocer el negocio y su funcionamiento sin tener que leer un documento, pues solo deben conocer las reglas básicas del BPMN para la interpretación del modelo. Cabe mencionar que aprender a leer un diagrama BPMN es una actividad que no llevaría más de una hora y de la cual no se requiere se experto en BPMN, basta con tener a la mano una hoja de referencia de los símbolos utilizados en BPMN.
Así pues concluyo que, con la ayuda de BPMN es posible tomar en cuenta la etapa que varios desarrolladores no se interesan por considerar, el Análisis del Negocio. Con un análisis del negocio claro y representado en un modelo de fácil lectura, se puede integrar a los desarrolladores en una dinámica en donde todos los involucrados de un proyecto hable el mismo idioma, pues se tiene claro el entorno de negocio y su problemática a solucionar. Mientras que los modelos de UML es la metodología ideal para llevar a cabo el diseño del sistema de información (La solución).
Gerente de Desarrollo de Factor Integración
