Por qué la trazabilidad software importa

La trazabilidad software es una antigua buena práctica, recomendada para medianos o grandes desarrollos software, que trata sobre cómo enlazar o relacionar los requisitos con otros elementos del ciclo de vida, principalmente, casos de prueba y código.
Y es tan antigua como incomprendida.
Digo lo de incomprendida porque creo recordar que en toda mi carrera profesional no más de dos equipos la implementaban bien y sabiendo el porqué, y ya sabes aquello que hablamos en su día de que si no tienes claro “por qué” estás implantando una práctica TI, probablemente metas la pata, y en pocos meses dejes de usarla.
Vamos primero con el porqué de la trazabilidad software y luego algunos consejos sobre el cómo.

¿Por qué es bueno tener trazabilidad software?

Aparte de porque alguien te obligue a tener trazabilidad en tu proyecto, hay otras razones de su importancia, principalmente las siguientes:
– Sabiendo qué código es el que implementa cada requisito puedo estimar con más precisión el esfuerzo que me llevará implementar una petición de cambio sobre un requisito, porque puedo saber cuánto código involucra.
Además, como la trazabilidad debe ser bidireccional, no sólo desde requisitos a código, también desde código a requisitos:
– Si toco el código, por ejemplo, para refactorizarlo (te dejo una breve introducción a la Refactorización), para mejorar rendimiento, para un mantenimiento perfectivo, por temas de seguridad, etc., sabré qué requisitos de usuario pueden verse afectados.
– Podré localizar código muerto que está ahí consumiendo dinero pero no da respuesta a ningún requisito de usuario, o a requisitos que podría eliminar.

¿Cómo implementar la trazabilidad software?

Hace mucho mucho mucho tiempo la gente implementaba la trazabilidad con documentos, con tablas en Word o en Excel. En filas los requisitos, en columnas los casos de test o ficheros fuente, y una x para ver qué se relaciona con que.
Pero con el transcurrir de los años, nos dimos cuenta de que esa manera de llevar la trazabilidad era difícilmente mantenible, las tablas tenían muchos errores, porque siempre a alguien se le olvidaba actualizarlas… y ya nadie se fiaba de ellas y ahí se quedaban solas, en el mas absoluto abandono, esperando por si alguien, o algún auditor, la pedía.
Hoy en día, quien se toma en serio esto de la trazabilidad, quien se ha dado cuenta de que le saca dinero, o se lo ahorra, suele enlazar su herramienta de gestión de requisitos, que muchas veces es un Redmine, Trac o similar, poniendo en cada uno de los requisitos la “revisión”, en terminología subversión, del código que lo implementa. Y cada vez que se sube un fichero a la herramienta de control de versiones, poniendo en los comentarios el identificador del requisito con el qué se relaciona.