Trazabilidad, práctica clave para reducir costes y defectos en el desarrollo de software

En la actualidad, nadie se extraña de encontrar en el envase de cualquier alimento datos con la información sobre el lote o la fecha de su envasado. Hace ya muchos años que la trazabilidad alimentaria es una exigencia legal. En el caso del desarrollo de software, la trazabilidad es una buena práctica que sirve exactamente para lo mismo: disponer de la posibilidad de seguir el rastro a cualquier componente a través de cualquier etapa de su ciclo de vida.

Pero, ¿qué entendemos por componente y a qué nivel queremos trazarlo? Empezando desde el nivel más alto de abstracción hasta el artefacto más indivisible, la trazabilidad es deseable desde la fase de definición de los requisitos de negocio hasta cualquier objeto software que vaya a terminar en un entorno productivo. Adquiriendo este tipo de trazabilidad obtendremos, entre otros beneficios, la posibilidad de:

• Conocer el grado de impacto de una modificación: qué artefactos existen en la cadena de dependencias.
• Delimitar el alcance de cualquier prueba de regresión que haya que efectuar tras el cambio.
• Saber, sin lugar a dudas, qué versiones de cada fuente terminan en qué versión de cada artefacto, y qué requisitos se satisfacen con la versión del aplicativo en la que se incluyen.

Esta información se convierte en sí misma en un resorte inestimable para la reducción de defectos y por lo tanto, de costes, ya que:

• Al conocer el impacto de las modificaciones se mitiga la posibilidad de generar defectos por cambios no previstos.
• Poner mayor foco en las pruebas de los componentes modificados disminuye el esfuerzo, a la vez que garantiza el resultado.

¿Cuánta trazabilidad es deseable?

La respuesta a esa pregunta no es categórica: es deseable un nivel de trazabilidad que genere una cantidad de información de traceo explotable y útil, que no ponga trabas al proceso de desarrollo y que no retuerza herramientas, usándolas para lo que no están concebidas.

En este punto surgen distintos extremos de trazabilidad:

• Trazabilidad cero: aún hoy en día existen organizaciones en las que la acción de pasar una versión a producción presenta un componente importante de aventura. En estos casos, se deja el proceso en manos del gurú del aplicativo. Él sabe exactamente los pasos que hay que dar y las versiones que hay que amalgamar para que el producto funcione en el entorno productivo. Esta técnica se conoce frecuentemente como la del Samurái.
• Trazabilidad máxima: son los casos en los que resulta frecuente encontrar dentro del código fuente comentarios que hacen referencia a un ticket de Redmine, la fecha y la hora de la modificación, además, por supuesto, del responsable del cambio.

Ninguno de los extremos es deseable. En el primer caso, se corre el riesgo claro de encontrar problemas de integración entre componentes en producción. En el segundo, aunque es información útil, al trasladarla al código fuente, este queda menos legible y menos mantenible. Es decir, puede ser interesante disponer de esta información pero, desde luego, el código fuente no es el mejor lugar para verterla.

En estos momentos existen en el mercado herramientas que nos ofrecen la posibilidad de implantar un sistema de trazabilidad, pero a la hora de ponerlo en marcha hay que considerar que se hace necesario introducir un cambio filosófico en la organización. Es decir, cada actor que participe en cualquier fase del ciclo de vida del software tendrá que tener en cuenta la trazabilidad, de igual manera que tiene en cuenta la calidad en su día a día.

Así, desde que se crea un requisito de negocio, hasta que se descompone en requisitos funcionales y características software que finalmente quedan implementadas en código, el responsable de cada uno de los componentes ha de proveer la información necesaria para su trazabilidad.

Herramienta, procedimientos y filosofía: implantar un sistema de trazabilidad presenta, indudablemente, un importante coste asociado, que se amortizará rápidamente en forma de menor esfuerzo en release management, menor número de defectos y mejor conocimiento del catálogo de software. Como afirmaba Edward Young: “sed sabios ahora: cualquier aplazamiento es una locura.”

Por Francisco M. Lozano Sanjuán
Consultor Senior Calidad de Código

Ver más historias