Desarrollo orientado a interfaces

Los que, como yo, estudiamos Ingeniería del Software con temarios anticuados, no llegamos mucho más allá de los modelos clásicos de desarrollo y, por supuesto, nunca oímos hablar de metodologías ágiles.

En el desarrollo de software hay, a mi juicio, dos parámetros relacionados entre sí y que son de vital importancia: El tamaño del proyecto y lo exhaustivo del proceso de ingeniería a desarrollar. La relación entre ambos debe ser una constante, y el valor óptimo de la misma depende de una multitud de factores, tales como el equipo de ingenieros que trabajen en el proyecto, la ventana temporal para el mismo, etc. En cualquier caso siempre se puede establecer un rango para esta relación: No tendría por ejemplo sentido realizar un intenso proceso de ingeniería para construir un "Hello World", del mismo modo que para afrontar la informatización de una entidad bancaria sin que el proyecto se hunda, sería necesario aplicar la Ingeniería del Software de forma estricta.

Se deduce de lo anterior que hay un punto en el tamaño del proyecto en que la Ingeniería del Software parece no ser útil o, al menos, supone un coste mayor que el beneficio que aporta. Sin embargo incluso en pequeños proyectos en los que la aplicación de un proceso de Ingeniería parece tener más costes que beneficios, son necesarios como mínimo una serie de aspectos de la misma, como por ejemplo los relacionados con el trato con el cliente.

En este punto es en el que me he encontrado en varias ocasiones sin saber muy bien como atajar el problema. Finalmente he alcanzado una solución de un modo más o menos intuitivo, es decir, trabajando con el cliente y aprendiendo en cierto modo por prueba y error. Con el tiempo, y sin saber si estas técnicas han sido descritas o usadas anteriormente por otra persona, he optado por llamarlo "desarrollo orientado a interfaces". Este texto no pretende ser una descripción detallada de un modelo de desarrollo, ya que en ningún momento he trabajado para crear dicho modelo. Simplemente pretendo enunciar una idea y dar unas ligeras pinceladas para explicar esta metodología de trabajo.

El desarrollo orientado a interfaces (DOI) no es en realidad más que un conjunto de reglas básicas, un proceso de ingeniería abreviado, con un bajo coste y con una clara intención de extraer el máximo partido de cada fase del proceso. La idea es bien sencilla: empezar la casa por el tejado. En efecto puede parecer un absurdo este modo de proceder, pero si lo miramos desde el punto de vista del software, no se trata más que de desarrollar software empezando por la interfaz de usuario.

El primer paso es, naturalmente, la entrevista con el cliente. Una vez tenemos idea de los requerimientos funcionales del software a desarrollar, podemos comenzar a trabajar sobre la interfaz. En un primer momento no será necesario más que un esbozo en papel de las interfaces de usuario de nuestra aplicación. Este esbozo debe desarrollarse de cara al cliente, esto es, de modo que él lo entienda. En este sentido el resultado se asemejaría bastante a un manual de instrucciones del programa en el que las capturas de pantalla son sustituidas por dibujos. Del tamaño del proyecto y de la relevancia de este primer documento depende el nivel de detalle que se quiera reflejar en el mismo. Así, si el proyecto es pequeño, no se compite con otras empresas o ingenieros para adjudicarse el trabajo, y no es necesario recurrir a este documento como contrato, podemos simplemente dibujar las interfaces explicando al cliente como trabajaría la aplicación y realizando sobre la marcha las modificaciones oportunas.

Con este primer paso logramos una multitud de objetivos, y según lo importante de los mismos dedicaremos más o menos esfuerzo a esta primera fase, en particular en lo que a la elaboración de un documento se refiere. En concreto lograremos, si lo necesitamos, los siguientes objetivos:

• Obtener una lista de requerimientos funcionales, cada uno de ellos especificados detalladamente.
  
• Obtener un documento que puede servir como contrato con el cliente.
• Minimizar el riesgo de una mala interpretación de algún requerimiento funcional, ya que la comunicación con el cliente es más clara y concreta mediante ejemplos gráficos.
• Adelantar trabajo en el diseño de la interfaz de usuario.
  
• Adelantar trabajo sobre el manual de usuario de nuestra aplicación.

Una vez se han esbozado las interfaces, y nuevamente dependiendo del tamaño del proyecto y de sus características concretas, podemos valorar la opción de desarrollar en primer lugar todas las interfaces de usuario (es decir, formularios e informes) sin dotarlas de funcionalidad y completándolas, a lo sumo, con datos ficticios y estáticos de ejemplo. En este caso podremos presentar al cliente en un tiempo excepcional un primer prototipo no funcional de la aplicación, que puede servirnos para detectar posibles errores en el análisis de requerimientos.

Podemos en cualquier caso prescindir de este primer prototipo y abordar directamente el desarrollo de la aplicación. Durante las siguientes fases podremos modelar los datos y sus relaciones. Para ello nos apoyaremos en el diseño de la interfaz con el que contamos, pues la mayoría de los datos deben aparecer en la propia interfaz a modo de campo de entrada o salida y, de no hacerlo, deben quedar reflejados de algún modo en la descripción del funcionamiento de la aplicación. A partir de aquí, y en general, el proceso de desarrollo continuaría de un modo más o menos tradicional, sin existir diferencias fundamentales que merezca la pena detallar, pero manteniendo siempre la idea de realizar solo aquello que aporte un verdadero beneficio e intentar cubrir con cada tarea el máximo número de objetivos posibles.

En conclusión la idea es simple: Aprovechar el diseño de las interfaces como mecanismo de comunicación con el cliente, obtención de requerimientos funcionales, elaboración de un contrato y obtención rápida de un prototipo.

Cabe ahora preguntarse ¿en que casos es conveniente aplicar esta idea?. Naturalmente hay una serie de factores que aumentan las ventajas de la aplicación del DOI:

• La aplicación descansa fundamentalmente sobre las interfaces de usuario y las bases de datos.
• Toda o la mayor parte de la actividad de la aplicación es disparada por el usuario al trabajar con la interfaz.
• El cliente tiene conocimientos de informática a nivel usuario.
• El cliente ha usado aplicaciones similares para las que necesita un reemplazo o una mejora.

En mi experiencia el DOI ha demostrado ser especialmente útil en las aplicaciones web. Esto está motivado probablemente por el hecho de que en este tipo de aplicaciones la ejecución de código en el servidor está normalmente condicionada al disparo de un evento por el usuario.