El modelado de una aplicación informática consiste en documentar con precisión el comportamiento que debe tener la aplicación informática. Esto es, escrutar lo que tiene en mente el cliente y plasmarlo en un documento. Es un ejercicio que combina una dosis de Sherlock Holmes y una dosis de imaginación. La imaginación es crucial para imaginarse la aplicación, hacer un simulacro mental de lo que el cliente te describe e ir un paso más allá para hacer esa pregunta oportuna: y si el usuario en vez de hacer esto quiere hacer lo otro, ¿Cómo se debería comportar la aplicación?. Y una dosis de Sherlock Holmes para ir siguiendo pistas hasta llegar a una solución que cumpla con los requerimientos del cliente. En muchos casos se conoce el punto de partida, un conjunto de requisitos. Y se conoce el punto de llegada, el objetivo que se quiere alcanzar. Se intuye el camino pero la mente a veces es rebuscada y se enzarza por las ramas. Hay que tener un punto de clarividencia para ver esa luz entre los árboles y llegar al objetivo. La metodología del inspector Sherlock Holmes es una buena manera para ir obteniendo pistas relevantes e ir descartando aquellos aspectos irrelevantes.

¿Para qué sirve hacer el modelado de una aplicación?

El modelado de una aplicación sirve para reducir la distancia entre lo que tiene en mente el que encarga la aplicación, vamos a llamarle «cliente» para simplificar, y lo que se entrega como versión «decente» de la aplicación (vamos a suponer que la aplicación la desarrolla un proveedor contratado por parte del cliente). Si el ejercicio de modelado de la aplicación no se realiza correctamente y con cariño se corre el riesgo que la aplicación que se entrega se parezca como un huevo a una castaña.

Piensa un momento en la cadena de transmisión de un proyecto de desarrollo de una aplicación: en el proceso suelen intervenir varias personas por ambas partes (cliente/proveedor). Sin documento hay muchas probabilidades que acabe como ese juego que dices algo a la oreja de quien tienes al lado, este a la vez al que tiene a su lado, y cuando el mensaje te llega no tiene nada que ver con lo que has dicho. Generalmente los programadores, esos magos del código, no asisten a la reuniones con el cliente, si más no, no todos suelen asistir. Así que si no se les entrega algo tangible para que empiecen a tirar líneas de código el riesgo de que interpreten a su manera como tiene que comportarse la aplicación es elevado.

Por contra, si se realiza un buen ejercicio de modelado de aplicación, con una buena simbiosis cliente-proveedor durante el proceso, la probabilidad que lo que se entrega sea muy y muy parecido a lo que el cliente tenía en mente es muy alta. Esto es muy bueno porque ahorra dinero, tiempo y hace sentir bien a ambas partes. El cliente porque obtiene lo que deseaba sin sorpresas y se siente partícipe del proceso. Y el proveedor porque entrega lo que se espera de él y con un poco de suerte le felicitan (a parte que no le ponen pegas para pagar la factura).

Por otra parte, a medio-largo plazo es posible que se deban realizar mejoras de la aplicación. Incluso es posible que parte de los participantes del modelado inicial de la aplicación ya no estén. Lo que sí sigue estando es la documentación del modelado de la aplicación, una mina de oro para quién sea que deba continuar la labor de mejora de la aplicación.

¿Cómo se define el comportamiento de una aplicación?

El comportamiento de una aplicación se define principalmente mediante las funciones que la aplicación debe ser capaz de hacerse cargo, esto es, el comportamiento funcional. El planteamiento es muy sencillo: hay una persona que ha pagado para desarrollar una aplicación. Esta persona espera que esta aplicación le ayude para conseguir un objetivo (o varios). Esta persona entrará en la aplicación, realizará una serie de acciones (cuantas menos mejor) y la aplicación tiene que hacer unas cosas para conseguir los objetivos. Definir todo esto es lo que significa modelar la aplicación. Conceptualmente es así de simple.

Por poner un ejemplo, supongamos que el cliente quiere hacer una aplicación para vender billetes de avión por internet. Esta persona espera vender billetes de avión mediante la aplicación informática. Pues bien, ¿cuáles son las funciones que tiene que hacerse cargo la aplicación? ¿Y como será el proceso de compra de un billete? La aplicación mostrará la típica pantalla para que el usuario indique las fechas del vuelo, el destino, etc. Le dará al botón buscar. La aplicación deberá verificar que no falte ningún dato obligatorio y lanzará una consulta interna para ver los vuelos que cumplen con los criterios. Luego los ordenará por precio y los mostrará por pantalla. Y así, tirando del hilo se va describiendo el comportamiento funcional de la aplicación. A todo este proceso de estrujar la mollera se le dice análisis funcional, esto es, analizar qué funciones debe contemplar la aplicación.

Otros comportamientos de la aplicación

A parte de la descripción del comportamiento funcional de una aplicación se puede dar el caso que tenga mucho sentido definir el comportamiento de la aplicación a nivel de rendimiento. Esto es, cómo debe comportase la aplicación a nivel de velocidad, capacidad para «dar el callo» aunque haya muchos usuarios usando la aplicación a la vez,  cuál es el tiempo deseado para llevar a cabo un proceso de negocio vía la aplicación, etc.

Si te imaginas una aplicación de reserva de billetes de avión es fácil pensar que los requerimientos de rendimiento son tan o más importantes que los requerimientos funcionales. De nada sirve que la aplicación haga lo que tiene que hacer (vender billetes) si cuando hay más de 50 personas conectadas a la web de reservas la aplicación se colapsa y no funciona.

Para otras aplicaciones es posible que este aspecto no sea tan crítico y no haga falta poner mucho empeño en definir el comportamiento a nivel de rendimiento.

De nuevo, si no se quieren tener sorpresas hay que documentarlo y tenerlo en cuenta como un requerimiento más, igual que los requerimientos funcionales, a la hora de hacer el diseño: estructurar las tablas de base de dados, de utilizar una tecnología u otra, etc.

¿Por dónde empezar para modelar una aplicación?

Una buena manera de empezar el modelado de una aplicación informática es conocer con detalle el contexto en el que se tiene que modelar la aplicación: conocer el negocio, entender en que consiste, cómo se está haciendo actualmente la operativa que se desea realizar por medio de una nueva aplicación, entender cómo se hace actualmente y si tiene que hacerse igual con la aplicación o mejorarla. Para esto es crucial hablar con las personas apropiadas que pueden aportar esta información.

En esta línea es importante obtener toda aquella documentación que el cliente disponga y pueda ayudar a entender lo que se quiere. Si existe una manual de la aplicación «antigua» siempre va bien ojearlo, con cuidado, porque a la mejor en la nueva aplicación hay que hacer cosas de manera distinta. También es común que en ausencia de una aplicación las empresas se apañen con documentos ofimáticos. Que si un Excel para gestionar el tema A por aquí, que si un Access para gestionar el tema B por allí, etc. Hay que identificar todos estos recursos, con el método de Sherlock Holmes, tirar del hilo e ir haciendo una composición mental de lo que se quiere y cómo se quiere lograr a través de la aplicación que se está diseñando. Cuando empieces a tener una idea consistente empieza a documentar.

¿Y por dónde continuar?

Seguramente para continuar en el proceso tendrás que ir por el camino de las aproximaciones sucesivas. Vas a realizar una primera versión «presentable» de documento que defina el modelado de la aplicación. Lo entregas al cliente. Éste lo estudia y, a ser posible, se revisa y discute conjuntamente. En este proceso vas a corregir cosas que no entendiste bien, vas a ver matizes, van a salir aspectos que el cliente no se había planteado y tendrá que definir. Con todo esto, hay que volver documentar, actualizar lo que convenga, añadir lo nuevo y así hasta que se consiga un documento que defina el comportamiento de la aplicación.

¿Qué lenguaje se utiliza para modelar una aplicación?

El lenguaje a utilizar para modelar una aplicación debería ser una mezcla de «lenguaje humano» y un «lenguaje no tan humano». Los dos hacen falta desde mi punto de vista:

  1. El lenguaje humano: fíjate que para describir cómo tiene que comportarse una aplicación de venta de billetes de avión por internet basta con un lapiz y un papel. Es cuestión de estructurar las ideas en apartados e ir explicando cada aspecto. De todo esto sale un documento de texto (un word, pdf, lo que sea). Este documento es ideal para revisar entre cliente-proveedor, sobretodo si el perfil de los interlocutores en las reuniones no es un perfil programador, que suele ser habitual.
  2. El lenguaje no tan humano: los estándares del desarrollo de software son unánimes, hay que usar el lenguaje UML, siglas en inglés de Unified Modeling Language (UML). Ésto se lo inventaron ya hace unas décadas los gurús de la programación para ponerse de acuerdo en cómo se representaba en gráficos, esquemas, diagramas el comportamiento de una aplicación. Todo lo que se puede decir en lenguaje humano se puede traducir a este lenguaje. Por ejemplo, se puede hacer un diagrama de flujo de actividades para definir el proceso de venta de un billete de avión.  Una cajita «el usuario entra fechas deseadas», una flecha a otra cajita «el sistema verifica no falten datos», un punto de decisión: si faltan datos, flecha para arriba y a volver a introducir datos, si no faltan datos, flecha para la siguiente cajita «buscar vuelos que cumplan con el criterio».  Ya ves que esto sería más fácil verlo con el diagrama y ahí es donde tiene su sentido. Hay varios tipos de diagramas (de secuencia, de estados, casos de uso, etc.). Hay que tener criterio para saber si conviene o no hacer cada uno de estos diagramas. Para personas con perfil programador este lenguaje es mucho más preciso y pensado para programar. Por ejemplo, los casos de uso son terriblemente útiles desde mi punto de vista para programar. Un caso de uso detalla fielmente, si está bien hecho claro, un objetivo que alcanza un usuario. Dentro del caso de uso se definen los pasos a seguir, se define que condiciones previas se tienen que dar y qué condiciones posteriores se dan una vez el objetivo se ha logrado (por ejemplo una vez el billetes se ha vendido correctamente el estado del billete es «válido»). Si esto no se hace bien y no se documenta, el programador pica el código y no programa que se cambie el estado del billete al ser vendido, así que ya te puedes imaginar que habrá follón.

¿Dónde se plasma el resultado de modelar una aplicación?

Cómo derivada de los dos lenguajes anteriores, se puede documentar en:

  1. Documento de texto para la parte más humana.
  2. Proyecto UML, para la parte menos humana. Hay decenas de programas para hacer el modelado con UML. Generalmente vas creando diagramas, casos de uso, etc. Y todo lo pueden «empaquetar» en un proyecto, que idealmente se entrega al cliente.

Si la parte de UML no es muy grande a mi me gusta fusionarlo todo en un único documento de texto. Los diagramas se pueden incrustar en el word como una imagen. Así esta todo en un documento. El handicap es que si tienes que actualizar un diagrama hay que tocar el proyecto UML y luego actualizar el documento. Lo bueno es que tu entregas un documento y está todo, no tiene pérdida. Aunque parezca mentida, la documentación se puede «traspapelar» en los proyectos y si hay múltiples documentos esparcidos a saber qué le llega al programador.

Muy bonita la teoría, pero ¿De verdad todo esto se hace?

No, no siempre se hace. Y ahora piensas, coño, después de darme la chapa con la teoría ahora me dices que en muchos proyectos no se hace. Pues así es. Y también es cierto que muchos sabemos como acaban estos proyectos. El cliente acepta un presupuesto. Espera meses a la entrega. Interviene muy poco en el proceso y sospecha si el proveedor será capaz de implementar todo lo que tiene en la cabeza. Luego le entregan la aplicación y descubre que no hace lo que debería. Se mosquea. El proveedor, que ya tiene pérdidas económicas porque su proceso de hacer el software no es eficiente pide una derrama al cliente para financiar el error. Y ahí ya se lía la cosa. Si el cliente la paga, es probable le pidan una segunda derrama. Si no la paga y amenaza con no pagar la factura, mal vamos también. En fin.

¿Y por qué no se hace? para cada proyecto habrá una explicación pero desde mi experiencia si no se hace suele ser por alguno o varios motivos. Uno muy evidente es que documentar no suele gustar, en general en ningún ámbito, pero en el de ingeniería del software menos. La mayoría de programadores que he conocido les encanta programar, pero no documentar. Por otra parte, los perfiles consultores suelen ser muy buenos en la reuniones, tomando notas, pero de aquí a hacer un documento con cara y ojos va un rato. Finalmente hay un tema de fondo, que es creerse o no creerse este tinglado. Tanto cliente como proveedor deben creer en esto y poner recursos motivados y formados para llevar a cabo esta metodología. Seguramente muchos piensan que dedicar varias reuniones a entender lo que se desea, dedicar varios días a documentarlo y revisarlo es perder tiempo y que hay que ponerse a picar código. Como también habrá constructores que piensen que no hay que perder tiempo en planos y hay que empezar a levantar paredes, aunque luego la reforma no sea como quería el cliente.

Lo que yo sí te puede asegurar es que he visto proyectos realizarse con el planteamiento que aquí expongo y han sido un éxito. Y siendo justo también tengo que decir que he visto proyectos que no se han hecho con este planteamiento y han funcionado también, pero generalmente suele ser por un combinación de factores: que el proyecto es pequeñito y que los profesionales del proveedor son muy buenos (aunque no documenten).