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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Es verdad sobre lo que comentas Javier, la tazabilidad siempre a sido un dolor de cabeza cuando se intenta implementar en un ciclo de vida de desarrollo de software, más cuando es en papel.
Claro que es importante, especialmente para la fase de mantenimiento, que realmente es lo gordo. El caso es que mucha gente ni sabe que significa el concepto de trazabilidad.
Ahora bien, tengo una pregunta para los «expertos» en SCRUM y demás.
Si guardas los requisitos como post-it que luego tiras a la basura (o incluso guardas), ¿cómo haces en ese escenario la trazabilidad requisito-diseño-código? Salvo que que esos post-its estuvieran en un sistema de información (como Jira o lo que sea, o las tareas de GitHub con los commits), es decir, no fueran físicos (tarjetitas en una pizarra real), no se me ocurre algo útil y práctico.
El contenido de los post-it siempre deben acabar de una forma u otra en una herramienta o conjunto de herramientas (suite) que garantice la trazabilidad (seguimiento)Requisito – User Story – Pruebas – Bugs
De esa manera se tendría el despliegue detallado de los requisitos en forma de user story. Cada user story despliega las tareas asociadas para su construcción. El diseño de casos de prueba por los que quedan cubiertas las user story, que junto con la gestión de bugs nos permite revisar la estrategia de pruebas. Evidentemente es necesario un framework por ejemplo TFS – Test Manager gestionando los bugs en el TFS como una actividad más asociada a cada user story.
Al menos así lo veo.
Tal vez sea la discusión más urgente en materia de software que aún no se ha dado.