subscripción
Ideas + Ingeniería del Software
Trazabilidad
Enero 25th, 2009 - [Enlace local]
Podríamos explicar la trazabilidad (bidireccional) en el contexto del desarrollo de software como "dado un requisito llegar a la línea de código que lo implementa, y al contrario, dada una línea, saber con qué requisitos corresponde"(a grandes rasgos, no cortapegéis esto para nada importante ;) ).
Esto tiene muchos matices y complicaciones, tanto teóricas como prácticas. ¿Realmente es importante? ¿Necesitamos bidireccionalidad? La trazabilidad es claramente una función no biyectiva: una misma línea probablemente corresponde con varios requisitos, y un requisito corresponde con muchos fragmentos de código dispersos.
Hasta hace poco siempre había visto esto como algo imposible de conseguir -a un coste razonable-. Los requisitos se registraban en un procesador de textos, las tareas en un diagrama de Gantt, y el código en un repositorio, todo desconectado. Los intentos que ví para solucionar esto eran añadir funcionalidad a estas herramientas para lograr lo que se necesitaba. Por ejemplo, hay (caros) plugins para Word que añaden "orientación a requisitos", permitiendo, por ejemplo, versionarlos. En las tareas del Project habría que meter los códigos de los requisitos. En los commits de código, los códigos de las tareas... Trabajo, trabajo, trabajo. Al final, se abandonaba.
El problema era de planteamiento. Es inutil forzar el uso de herramientas para un fin ajeno a los objetivos del implicado: al programador no le da ningún beneficio el esfuerzo extra de añadir el código de la tarea. Al analista, el uso de herramientas más complejas que el word le supone también más trabajo. El gestor del proyecto probablemente no tiene ni tiempo ni ganas de actualizar o comprobar el diagrama de gantt...
La solución ha venido de forma conjunta a la adopción de técnicas ágiles y el cambio de herramientas integradas. Las tareas se añaden en el gestor de incidencias (Trac en nuestro caso). Esto, de paso, soluciona el problema del versionado. Además, al ser información estructurada, al estar en una base de datos, se pueden generar informes y vistas en función de las necesidades. Al programador se le da el Eclipse con Mylyn, que le da valor añadido. Indicar la tarea en la que está trabajando no sólo no es trabajo (hacer un click en ella), sino que le aporta valor añadido, ya que el entorno recuerda el contexto (la perspectiva, las vistas, los ficheros abiertos...), haciéndole más fácil alternar entre tareas. Al final, en el gestor tenemos los requisitos (con su histórico) y podemos ver el código relacionado.
¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.
