17 de septiembre de 2009

¿Casos de uso ágiles?

Pues si. Mi última aventura ha involucrado el delicioso asunto de documentar casos de uso que nadie va a leer jamás. O por lo menos no lo suficiente como para justificar el esfuerzo requerido en ello.

No me malinterpreten. En realidad yo no creo que toda la documentación, el levantamiento de requerimientos y la elaboración de casos de uso sea una perdida de tiempo. Pero si lo son cuando se elaboran exclusivamente para "cumplir con el requisito".

But I digress... lo que realmente quiero comentar aquí es la manera en que atacamos el problema de la documentación de requerimientos. Una de las partes más frustrantes del proceso es la casi infinita variabilidad en cuanto a los formatos "oficiales" que manejan las empresas para estos menesteres. Es verdaderamente desmotivante el hecho de tener que hacer un cierto trabajo, querer hacerlo bien (porque por más que nos desagrade, aún tenemos nuestra ética) y descubrir que no puedes avanzar como quisieras por que tienes que estar lidiando con las idiosincrasias del procesador de palabras, en lugar de poder concentrarte en lo que realmente importa de la documentación (aunque muchas personas lo duden): el contenido.

La solución que encontramos es utilizar una tecnología a la que desde hace varios le tengo un especial cariño: XSLT (Transformaciones del Lenguaje Extensible de Hojas de Estilos).

La idea es definir un esquema sencillo XML para el documento principal (el contenido) y utilizar XSLT y CSS para formatear el documento final. Nuestro esquema tenia elementos como <caso>, <flujoPrincipal>, <paso>, etc. Esto nos permitió olvidarnos durante la mayor parte del tiempo del formato del documento y concentrarnos en escribir casos de uso que fueran claros y tan completos como fuera posible. Además, ¿no es eso lo que predican las reglas del buen diseño?

Desacoplar el modelo de las vistas.

O como lo dirían los diseñadores Web:

Separar el contenido y el formato.

Una gran ayuda fue la utilización de Komodo Edit para la edición del documento HTML, ya que este editor permite tener una vista previa del documento final y tiene una función de corrección de ortografía muy útil. Como utiliza los mismos diccionarios que Firefox y Thunderbird, es muy sencillo de utilizar y extender.

Otra herramienta que fue invaluable fue el programa Prince XML, que permite generar un documento en formato PDF a partir de un XML o HTML. Nos dio un gran control sobre el layout de la página con sus extensiones para CSS. Verdaderamente una herramienta fantástica.

Finalmente, el que para mi es la estrella de la película es GNU make. Seguramente que alguien se podrá preguntar "¿Qué? ¿make? ¿Qué eso no es para programadores en C?". Bueno, si lo es. Pero no necesariamente debe tratarse de un proyecto en C para que make sea útil. En realidad, Prince es una herramienta genial, pero cuando tienes que generar un documento PDF de alrededor de 380 páginas, el proceso se vuelve algo lento.

El poder de make para verificar dependencias y generar (o regenerar) partes o artefactos de forma automática, es un lujo que muchos programadores de hoy en día nunca han tenido y muchos programadores con algunos años de experiencia ya no recuerdan. Lo que es más, nos permitió validar nuestros documentos en tiempo de "compilación". Al momento de aplicar la hoja XSL, nuestro makefile hace una llamada a msxls para validar el documento contra el esquema. Eso por sí mismo nos ahorró muchos problemas (en especial cuando el documento comenzó a crecer y tanto Komodo como Stylus Studio se comenzaron a poner lentos). Además antes de pasar el resultado a prince, make lo pasaba primero a través de tidy para verificar el código generado por nuestra hoja XSL.

Un detalle que pasamos completamente por alto y que pudo ser de gran ayuda fue el uso de XSL-FO (XSL Formatting Objects). La primera vez que escuché de esa tecnología todavía estaba muy cerca del "bleeding edge" como para considerarla seriamente, pero parece que hoy en día se encuentra mucho más madura. Tendré que hacer una nota mental para estudiarla seriamente un día de estos

Mientras que sigo dudando que el proceso de documentar casos de uso se vuelva alguna ves una de mis actividades favoritas, con algunas de las cosas que aplicamos en este proyecto, me parece que no debe ser tan oneroso después de todo.

1 comentario:

  1. Buen tip Sr. Me hizo recordar las épocas en las que tenía que lidiar con el Rational-ClearCase. Saludos

    ResponderEliminar