Trazabilidad por "generación espontánea"

Hablemos de trazabilidad, uno de los argumentos más usados en los departamentos de calidad para justificar muchas de las normativas impuestas.
Después de mucho tiempo, hay un consenso generalizado y casi todo el mundo tiene claros los beneficios de mantener la trazabilidad entre los requisitos y el resto de artefactos del ciclo de vida del software. Y, sin embargo, existen aun muchas dudas sobre cómo gestionar la trazabilidad de manera eficaz.
Fijémonos en uno de los tipos de trazabilidad más controvertida. La que nos lleva de los requisitos del producto al código fuente que lo implementa. Si nos marcamos como referencia el modelo CMMI, y consideramos el código del producto como un work product, queda claro que hay que mantener esa trazabilidad. La pregunta es cómo, momento en el que CMMI nos deja solos ante el peligro…
Lo primero, y a efectos prácticos, es saber hasta qué nivel de granularidad es necesario definir y mantener la trazabilidad. En lo que respecta al código, y por su propia naturaleza, se establecen relaciones de trazabilidad muy especiales de las que nos podemos aprovechar. Siendo realistas, reconozcamos que es muy difícil mantener la relación entre cada requisito y cada pieza de código que los implementa. El nivel de cambios al que está expuesto el código fuente es altísimo, por tanto consideremos cuidadosamente qué ganamos trazando a muy bajo nivel.
Creo que lo más práctico es identificar las partes del código más abstractas, más relevantes a nivel funcional y a partir de las cuales se pueda navegar fácilmente a componentes de más bajo nivel. Estos puntos de entrada al código dependen de cada tecnología, obviamente, pero en general son componentes de tipo fachada muy habituales en todos los diseños que se precien. Y es ahí exactamente donde deberían apuntar las trazas. Además, estos puntos de entrada tienen otras características realmente interesantes. Su relativa estabilidad ante los cambios, su gran protagonismo en la fase de pruebas de integración y, de cara a realizar análisis de impacto (si nos cambian un requisito), son más que suficientes.
De manera que siendo capaces de identificar esos puntos de entrada al código tendremos mucho ganado. El modelo de trazabilidad sería similar a este:

NECESIDAD
--> ESPECIFICACION REQUISITO(s)
--> CASO(s) DE USO
--> PUNTO(s) de ENTRADA AL CODIGO
--> RESTO DEL CÓDIGO

Lo bueno de esto es que la última flecha, el último nivel de traza, se mantiene solo y de manera natural. Casi por… "generación espontánea".

LUIS REYES