Application Demo Miyagi – Creating the basic architecture

Este es el primero de una serie de post en el cual mostraremos paso a paso la implementación de la aplicación del proyecto Miyagi.  Esta serie tiene como objeto mostrar a través de un ejemplo práctico el proceso de desarrollo de aplicaciones en Southworks mostrando el avance que día a día fue ocurriendo en la aplicación.

Cabe destacar que esta serie de posts comienza una vez que ya se definió el alcance del proyecto (Capacity, Project Charter, business stories, etc). Las etapas previas del proyecto estarán publicadas en otra serie de post (que se publicará en breve).

Brevemente, Miyagi es un proyecto  de administración de recursos y proyectos. La aplicación provee funcionalidad para asignar tiempos de dedicación de recursos a proyectos, proveer una serie de alertas en casos especiales (sobre-asignación de horas, sub-asignación, etc) y varias funcionalidades para consultar esta información. 

Partimos entonces desde el punto en el que se consensuó que el alcance de la aplicación se reduce al desarrollo de 3 vistas principales que son las mínimas que se necesitan para satisfacer las necesidades del cliente. Las vistas se muestran en la figura 1.

Figura 1: Vistas de Capacidad, Alocación y Proyecto

La idea es crear rápidamente un prototipo de la aplicación que se va a desarrollar con varios objetivos en mente:

Ø  Darle rápidamente algo tangible al cliente

Ø  Mostrarle que entendimos lo que necesita

Ø  Mostrarle cómo la aplicación que desarrollemos va a agregarle valor

Ø  Que sirva para validar o refutar lo que tenemos relevado hasta el momento.

Ø  Bajar a tierra las ideas que estaban en papel para que el mismo equipo de desarrollo empiece a pensar en algo más tangible

La filosofía es simple: Hacer sólo lo necesario, de la forma más sencilla y rápida posible para conseguir lo que queremos. La idea es no perder el foco de lo que queremos conseguir (un prototipo en este caso) y tratar de no buscar la mejor solución sino una que funcione. Cualquier semejanza con TDD no es casualidad.

Para generar el prototipo, el primer paso es crear un primer diseño de la BD. En la figura 2 se muestra el diseño resultante que permite almacenar la información necesaria. La tabla Resource almacena los recursos de la empresa, la tabla Project almacena los proyectos y las tablas HotAllocation y ColdAllocation almacenan las asignaciones a un recurso en un proyecto en un día determinado (la asignación por día es la menor granularidad posible). La división entre hot y cold allocation está pensada a efectos de mejorar la performance de la aplicación (ya se verá más adelante el funcionamiento de estas tablas).

Figura 2: Primer diseño de la BD.

El segundo paso es crear la arquitectura básica de la aplicación que vamos a desarrollar.  En nuestro caso, para este primer prototipo se estipulo crear una aplicación web desarrollada en ASP 2.0. Por lo tanto creamos una solución .Net que más simple que permite cumplir con este requisito:

Ø  Un web site (WebUX)

Ø  Un web service (Host.Asmx)

Ø  Una capa de negocio (Services)

Ø  Una aplicación de test de la capa de negocios (Services.Test)

La figura 3 muestra esta arquitectura.

Figura 3: Arquitecura de la aplicación

Aquí empieza el concepto de desarrollo en TDD.  Tenemos que tener una aplicación que compile siempre y que tenga un código correcto, pero que sea lo más fácil y rápido para implementar. Lo primero que hacemos entonces es compilar la solución que creamos y corregir los bugs que surjan. Luego tenemos que correr el analizador de código estático (FxCop) y corregir los warnings que este nos tira. Una vez que corregimos todo esto, tenemos nuestra primera versión correcta.

Luego tenemos que volver a pensar, cuál es el foco? Qué es lo primero, lo más importante que quiero hacer? Ante esta pregunta, la respuesta que surgió es “quiero mostrarle al cliente, el diseño de las pantallas que me pidió en papel en una aplicación”. Según TDD esta pregunta tiene que trasladarse a un test. El test, en este caso es manual, es un test de diseño: Necesitamos 3 páginas web que cumplan con el diseño gráfico previamente consensuado.

Ahora hay que pensar, “Para lograr esto, cual es la forma más rápida y fácil?”. La respuesta que se presentó es sorprendente y obvia: Exportar las vistas de Excel a HTML y pegarlas en 3 páginas Aspx cumple con este objetivo!!!

Por lo tanto, creamos 3 páginas aspx (ver Figura 4) y exportamos las vistas a html y pegamos el código en estos archivos. Rápidamente concluímos una implementación que cumple con el primer test: Comparando las vistas eran idénticas a las que estaban en Excel. Nuevamente compilamos la aplicación y corrimos el FxCop para asegurarnos que no tenemos problemas. Esto se convirtió en nuestra segunda versión de la aplicación. Fijense que aunque mínimo, esta versión muestra un incremento y que se acerca un poco más al objetivo que buscamos (no perdimos el foco).

Figura 4: Las 3 vistas de la aplicación.

Luego, con un poco de ayuda de expertos, mejoramos el html, en lo que sería un primer refactor de la aplicación (la idea es que en el refactor se elimina código redundante y se mejorar atributos de calidad de la aplicación). En este caso, se limpió el código html generado y se creó un css style que evita repetir código y permite reducir los errores de escritura del html. La figura 5 muestra el diseño final.

Figura 5: Diseño de la vista de capacity luego del refactor.