¿C uál es la diferencia entre la manufactura de software y la consultoría de software? En mi opinión la consultoría le ofrece un valor extra al cliente más allá de la construcción del software. Para hacer consultoría debemos de ponernos en los zapatos del cliente para comprender su problema y necesidades, y de esta forma ser capaces de ayudarle a definir el sistema adecuado para su negocio.
En la manufactura la responsabilidad sobre la definición de la solución podría ser de menor proactividad que la de un consultor. En este caso el cliente nos especifica cuál es el software que necesita y nosotros lo fabricamos según sus instrucciones, con poco o nulo cuestionamiento de nuestra parte respecto a la relevancia de cada función a implementar en dicho sistema. El problema en este último escenario consiste en que el cliente NO suele ser un experto en sistemas de forma que pueda proponer el sistema ideal. El cliente es experto en su negocio y nosotros somos expertos en el nuestro: en el desarrollo de sistemas. Por lo tanto habría que tener clara la responsabilidad de cada quien dentro de un proyecto.
IQ, Experiencia o Simplemente Técnicas
Lo fascinante del modelado de negocio se puede ver en situaciones como la siguiente: no es raro notar la sorpresa en la cara de nuestros alumnos cuando descubren que su instructor de UML pareciera comprender mejor que ellos las reglas de negocio y requerimientos de sus propios sistemas, tan sólo con haber realizado un par de diagramas de UML durante un curso.
Pero sería muy presuntuoso pensar que un consultor o un instructor puede dominar las reglas de un negocio simplemente por su capacidad o coeficiente intelectual. En todo caso, es el dominio de UML el que permite lograr comprender las cosas de una forma más sencilla. La mejor forma de transmitir esta habilidad es a través de capacitación que involucre simulacros de proyectos reales, en lugar de únicamente explicar los “dibujos” que conforman los diagramas de UML.
La Magia de Armar Rompecabezas
La “magia” para ayudarle a los usuarios a entender su negocio por medio de UML consiste en saber pegar las piezas aisladas que nos proporciona en un rompecabezas completo y coherente que sea mucho más claro que la explicación original. Incluso el usuario ve las cosas con más claridad cuando le mostramos eso que él mismo explicó, por medio de los modelos. Al respecto, mis alumnos suelen preguntarme qué artefactos de UML son los más apropiados para ser utilizados en la comunicación directa con el cliente. Es decir, cuáles le pueden entregar con la seguridad de que el cliente los va a entender.
Entre los artefactos básicos que yo sugiero para esto, están:
a) Para definir la funcionalidad del sistema, los casos de uso.
b) Para comprender la jerga del cliente, el modelo conceptual.
c) Para validar con el cliente si comprendemos el trabajo (procesos/procedimientos) que realiza su empresa y que desea automatizar; posiblemente no haya nada como el diagrama de actividades.
¿Alguien Sabe Cómo Funciona Este Negocio?
Y es que suele ser la regla, más que la excepción, encontrarse con usuarios que no comprenden del todo los procesos dentro de los cuales participan. Por lo que nosotros, como analistas, terminamos recogiendo todas las piezas del rompecabezas para después pegarlas y así comprender los procesos del negocio que serán automatizados.
Responsable del Negocio
Hace poco un alumno me preguntaba si el trabajo de modelar los procesos de negocio le correspondían a la gente de sistemas. La respuesta no es tan simple, pues en el mundo ideal habría un rol que se encargara de eso y el equipo de desarrollo sólo tendría que preocuparse por definir y construir el sistema adecuado. Pero todos sabemos que el mundo no es color de rosa, así que no es raro que tengamos que ocupar dicho rol ante la ausencia de alguien más que asuma esta responsabilidad. Con esto no quiero decir que recomiendo que la gente de sistemas se encargue de esta tarea, sin embargo, no podemos tapar el sol con un dedo, pues esto ocurre con bastante frecuencia ante la ausencia de un rol asignado para realizar dichas tareas entre los usuarios.
El Artefacto
El diagrama de actividades es un artefacto muy útil y simple para comunicarse con el cliente porque en esencia es un diagrama de flujo, y ¿quién no ha visto o elaborado un diagrama de este tipo? La mayoría de los usuarios no tienen problema en entender este diagrama sin tanta explicación. La esencia del diagrama de actividades consiste en mostrar una secuencia de acciones o actividades, ya sea un proceso, un procedimiento, un conjunto de eventos de un caso de uso o los de un algoritmo.
Para mostrar los flujos más básicos sería suficiente utilizar dos elementos del diagrama: las actividades o acciones y las transiciones. En otras palabras, los pasos del proceso y el orden en que estos ocurren. De ahí podemos agregar más elementos para modelar flujos cada vez más complejos. Por ejemplo, un elemento básico a representar nos indicaría explícitamente cuál es el inicio y fin del flujo.
Condiciones, Carriles y Flujos Paralelos
Qué felices seríamos si los procesos siguieran una ruta simple para cumplir con su objetivo. Desafortunadamente existen situaciones alternativas que hay que considerar y que complican su modelado. Estos flujos alternativos se pueden representar utilizando las condiciones que nos indican que tenemos que irnos por uno u otro camino, como cuando vamos a pagar una compra en el súper mercado y nos pregunta el cajero si queremos pagar en efectivo o con tarjeta. Cada opción requiere pasos alternativos a modelar a partir del símbolo de decisión.
En muchas situaciones querrás saber a quién le corresponde cada tarea del proceso modelado, ¿al vendedor?, ¿al cliente?, ¿al encargado del almacén? Podemos representar en este diagrama de una forma simple, mediante carriles, quién es el responsable de cada actividad dentro del proceso.
Los procesos se pueden complicar aún más al requerir actividades que se lleven a cabo en paralelo. Tampoco hay mayor problema, pues las barras de sincronización nos muestran claramente esta característica del flujo que estamos modelando.
Uso y Generación de Productos
¿Y qué hay de los productos o documentos que se utilizan o generan durante una actividad del proceso? Por ejemplo, para fabricar un carro, necesitas un motor y un chasis; estos son productos de entrada para generar un producto de salida. Para entregar cierta mercancía necesitas una orden de entrega. Este tipo de diagramas permiten representar los productos de entrada y de salida para cada actividad, por medio de objetos y flujos de objetos.
Apto para Todo Mundo
Lo mejor de todo es que estos diagramas no requieren mayor ciencia para ser entendidos. Al menos así ocurre con los procesos que no requieran demasiados tipos de elementos de este artefacto. Después de haber asesorado a todos esos proyectos durante estos años en las tareas de modelado, puedo asegurar que a los clientes les fascina este diagrama, pues de una forma simple definen su trabajo y muchas veces lo ven por primera vez de una forma ordenada.
Figura 1. Diagrama de Actividades para la impresión de una esquela en un periódico.
La Transición al Software
Otra gran ventaja de este tipo de diagramas consiste en la transición del análisis del negocio a los requerimientos del sistema de una manera más transparente. Nos ofrece la formidable ventaja de facilitarnos la identificación de los principales casos de uso del sistema, pues algunas de las actividades mostradas en el diagrama se convierten directamente en casos de uso. De esta forma, comienza a aparecer mucha de la funcionalidad principal para el cliente; claro que no es toda la funcionalidad, pero por lo menos la que posiblemente sea más relevante para el negocio.
Acerca del autor
- Log in to post comments