Trazabilidad

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.

Posted by Juan Ignacio Sánchez Lara 20:11  

1 Comment:

  1. Joserra said...
    Realmente me has convencido en probar mylyn :)
    Lo único que discrepo es que al programador o analista no le reporte beneficios usar el msg de los commits, o herramientas de versionado... los desarrolladores somos los primeros interesados en la trazabilidad. Tan simple por que responde a preguntas que siempre acaban saliendo como: ¿por qué se hizo esto? ¿qué debía generar estas lineas de código?
    Para un equipo de desarrollo la trazabilidad es muy útil, quizás es complicado de demostrar antes de que la usen, pero vale la pena.

Post a Comment