En un proyecto de software, cada funcionalidad debería tener una razón de existir. También debería ser posible saber qué necesidad la originó, qué requerimiento la describe, qué parte de la solución la implementa y qué prueba permite verificarla.
A esa capacidad de relacionar elementos del proyecto se la llama trazabilidad. La trazabilidad ayuda a conservar el vínculo entre lo que se necesita, lo que se especifica, lo que se diseña, lo que se construye y lo que se prueba.
Sin trazabilidad, el equipo puede perder contexto: aparecen funcionalidades sin dueño claro, cambios sin análisis de impacto, pruebas desconectadas de requisitos o código que nadie sabe si todavía es necesario.
La trazabilidad es la capacidad de seguir la relación entre distintos elementos del desarrollo de software a lo largo del tiempo. Permite responder de dónde viene una decisión, qué elementos dependen de ella y cómo se verifica que fue cumplida.
Por ejemplo, un requerimiento puede estar relacionado con:
La trazabilidad tiene valor práctico. No se trata de llenar tablas por obligación, sino de poder controlar mejor el sistema y sus cambios.
Sirve para:
La trazabilidad puede relacionar muchos elementos. El nivel de detalle depende del proyecto, su tamaño, criticidad y necesidad de control.
| Elemento | Qué representa | Ejemplo |
|---|---|---|
| Necesidad | Problema u oportunidad que motiva el sistema. | Reducir llamadas telefónicas para consultar turnos. |
| Requerimiento | Condición que el sistema debe cumplir. | El usuario debe poder consultar turnos disponibles en línea. |
| Historia de usuario | Necesidad expresada desde la perspectiva de un actor. | Como paciente, quiero ver horarios disponibles para elegir un turno. |
| Caso de uso | Interacción entre actor y sistema para lograr un objetivo. | Solicitar turno médico. |
| Diseño | Decisiones sobre estructura, datos, pantallas o componentes. | Módulo de agenda y disponibilidad. |
| Implementación | Código, configuración o integración que materializa la solución. | Servicio de consulta de turnos. |
| Prueba | Verificación de comportamiento esperado. | Probar consulta de horarios con disponibilidad y sin disponibilidad. |
La trazabilidad puede mirarse en dos direcciones principales.
| Tipo | Pregunta que responde | Ejemplo |
|---|---|---|
| Hacia adelante | ¿Qué se diseñó, construyó y probó para cubrir este requerimiento? | Desde "consultar turnos" hasta pantalla, API, módulo y pruebas. |
| Hacia atrás | ¿Qué necesidad o requerimiento justifica esta parte de la solución? | Desde una pantalla de turnos hasta la necesidad de reducir llamadas. |
Ambas direcciones son útiles. La primera ayuda a asegurar cobertura. La segunda ayuda a evitar trabajo innecesario o funcionalidades sin propósito claro.
Una matriz de trazabilidad es una tabla que relaciona elementos del proyecto. Puede ser simple o detallada según la necesidad.
Ejemplo básico:
| Necesidad | Requerimiento | Solución | Prueba |
|---|---|---|---|
| Reducir llamadas para consultar disponibilidad. | El paciente debe poder ver turnos disponibles en línea. | Pantalla de búsqueda de turnos y servicio de agenda. | Consulta con turnos disponibles y sin turnos disponibles. |
| Evitar reservas duplicadas. | El sistema debe bloquear un turno cuando ya fue reservado. | Regla de disponibilidad en módulo de reservas. | Intentar reservar dos veces el mismo horario. |
| Informar al usuario sobre su operación. | El sistema debe enviar confirmación al crear una reserva. | Servicio de notificaciones por correo. | Verificar envío de confirmación tras reserva exitosa. |
Uno de los usos más importantes de la trazabilidad es analizar el impacto de un cambio. Cuando un requerimiento cambia, el equipo necesita saber qué se verá afectado.
Por ejemplo, si cambia la regla "una reserva puede cancelarse hasta dos horas antes" y ahora se permite cancelar hasta treinta minutos antes, habría que revisar:
Sin trazabilidad, algunos de estos elementos pueden olvidarse y el sistema quedar inconsistente.
La trazabilidad entre requerimientos y pruebas permite comprobar que lo importante está cubierto. También ayuda a detectar pruebas que ya no tienen sentido porque el requisito cambió o fue eliminado.
Preguntas útiles:
Esta relación es especialmente útil en pruebas de regresión, porque permite seleccionar qué validar cuando se modifica una parte del sistema.
La trazabilidad también relaciona requerimientos con decisiones de diseño. Esto ayuda a entender por qué se eligió una estructura, módulo, interfaz o tecnología.
Ejemplo:
| Requerimiento | Decisión de diseño | Motivo |
|---|---|---|
| Las operaciones administrativas deben quedar auditadas. | Crear un componente centralizado de registro de auditoría. | Evitar que cada módulo registre auditoría de forma distinta. |
| La consulta de disponibilidad debe responder en menos de dos segundos. | Optimizar consultas y agregar índices sobre agenda y especialidad. | Cumplir el atributo de rendimiento esperado. |
Registrar esta relación evita que decisiones importantes parezcan arbitrarias en el futuro.
Durante el mantenimiento, la trazabilidad permite entender el sistema más rápido. Cuando alguien nuevo se incorpora o cuando se modifica una funcionalidad antigua, puede consultar qué necesidad la originó y qué elementos están relacionados.
Esto ayuda a:
La trazabilidad tiene más valor cuanto más largo es el ciclo de vida del software.
No todos los proyectos necesitan el mismo nivel de trazabilidad. Un prototipo pequeño puede requerir una lista simple. Un sistema regulado puede necesitar trazabilidad detallada y auditada.
| Nivel | Características | Uso habitual |
|---|---|---|
| Básico | Relación simple entre requerimientos y pruebas. | Proyectos pequeños o internos. |
| Intermedio | Relaciona necesidades, requerimientos, historias, módulos y pruebas. | Productos medianos con varias entregas. |
| Alto | Incluye aprobaciones, versiones, cambios, evidencia y auditoría. | Sistemas críticos, regulados o de alto riesgo. |
La trazabilidad debe ser proporcional al riesgo y al valor que aporta.
La trazabilidad puede mantenerse con distintas herramientas. Lo importante es que sea fácil de consultar y actualizar.
Una herramienta compleja no garantiza trazabilidad útil. Lo importante es que el equipo mantenga relaciones claras y actualizadas.
Supongamos un sistema de biblioteca.
| Elemento | Contenido |
|---|---|
| Necesidad | Reducir errores en el registro manual de préstamos. |
| Requerimiento | El bibliotecario debe poder registrar un préstamo indicando socio, libro y fecha de vencimiento. |
| Regla | Un socio no puede tener más de tres libros prestados al mismo tiempo. |
| Historia de usuario | Como bibliotecario, quiero registrar préstamos para controlar qué libros están en poder de cada socio. |
| Diseño | Módulo de préstamos con validación de socio, libro y límite de préstamos activos. |
| Implementación | Pantalla de préstamo, servicio de préstamos y actualización de estado del libro. |
| Pruebas | Registrar préstamo válido, intentar prestar libro ya prestado e intentar superar límite de tres libros. |
Esta relación permite entender el camino completo desde el problema hasta la validación.
Al aplicar trazabilidad suelen aparecer errores como:
Para que la trazabilidad sea útil, conviene aplicar algunas prácticas simples:
Una plantilla mínima puede incluir:
| ID | Identificador del requerimiento o historia. |
|---|---|
| Necesidad de origen | Problema, objetivo o actor que justifica el requerimiento. |
| Requerimiento | Condición que el sistema debe cumplir. |
| Solución asociada | Módulo, pantalla, servicio, API o componente relacionado. |
| Criterios de aceptación | Condiciones verificables para considerar cumplido el requerimiento. |
| Pruebas | Casos de prueba o validaciones asociadas. |
| Estado | Propuesto, aprobado, implementado, probado, entregado o modificado. |
La trazabilidad permite conservar el hilo entre lo que se necesita, lo que se especifica, lo que se construye y lo que se prueba. Es una herramienta de control, comunicación y mantenimiento, especialmente valiosa cuando el sistema crece o cambia.
Para quien comienza, la idea principal es esta: si no podemos relacionar una parte de la solución con una necesidad o requerimiento, debemos preguntarnos por qué existe y qué valor aporta.
En el próximo tema veremos una introducción al análisis y modelado del software, donde estudiaremos cómo representar el problema y la solución para comprenderlos mejor antes de construir.