39. Versionado, línea base y control de requerimientos
El versionado, la línea base y el control de requerimientos permiten saber qué contenido está vigente, qué cambió, cuándo cambió y quién aprobó cada modificación. Son prácticas fundamentales para mantener orden cuando el alcance evoluciona.
Sin control, distintas personas pueden trabajar con versiones diferentes de los requerimientos. Esto genera decisiones inconsistentes, retrabajo, pruebas equivocadas y desacuerdos sobre lo que realmente fue aprobado.
39.1 Introducción
En el tema anterior vimos la gestión de cambios en los requerimientos. En este tema veremos cómo el versionado y las líneas base permiten controlar qué versión del alcance se usa en cada momento del proyecto.
Estas prácticas no son exclusivas de proyectos grandes. Incluso un proyecto pequeño necesita distinguir entre borradores, versiones revisadas, versiones aprobadas y cambios posteriores.
39.2 Qué es versionar requerimientos
Versionar requerimientos significa asignar una identificación a cada estado relevante del contenido. Una versión permite saber qué información estaba disponible en un momento determinado.
El versionado puede aplicarse a un documento completo, a un conjunto de requerimientos o a cada requerimiento individual, según la herramienta y el nivel de control necesario.
39.3 Por qué es necesario el versionado
El versionado evita confusiones cuando un requerimiento cambia. Permite comparar versiones, revisar decisiones anteriores, reconstruir el historial y saber qué contenido se usó para diseñar, desarrollar o probar.
También facilita auditorías, aprobaciones, control de cambios y comunicación entre equipos.
39.4 Qué es una línea base
Una línea base es una versión aprobada de los requerimientos que se toma como referencia oficial para continuar el trabajo. A partir de ella, los cambios deben gestionarse de forma controlada.
La línea base no significa que los requerimientos nunca cambiarán. Significa que existe un punto acordado desde el cual se miden y administran los cambios.
39.5 Diferencia entre versión y línea base
Una versión es cualquier estado identificado del contenido. Una línea base es una versión especial que fue revisada y aprobada para servir como referencia.
Puede haber muchas versiones de trabajo, pero solo algunas se convierten en líneas base.
39.6 Cuándo establecer una línea base
Una línea base puede establecerse al cerrar una etapa de análisis, antes de iniciar desarrollo, antes de una iteración, antes de una entrega o después de una aprobación formal.
El momento depende del proyecto. Lo importante es que la línea base represente un acuerdo claro y suficientemente estable para avanzar.
39.7 Contenido de una línea base
Una línea base puede incluir requerimientos funcionales, requerimientos no funcionales, reglas de negocio, restricciones, criterios de aceptación, prioridades, trazabilidad y decisiones relevantes.
También puede incluir anexos como prototipos, diagramas, modelos de datos o documentos regulatorios si forman parte del alcance aprobado.
39.8 Identificación de versiones
Las versiones deben identificarse de manera clara. Pueden usarse números, fechas, etiquetas o combinaciones como v1.0, v1.1, borrador 3, línea base de mayo o release 2.
La convención debe ser simple y entendible para todos los participantes.
39.9 Historial de cambios
El historial de cambios registra qué se modificó, por qué, cuándo, quién lo solicitó, quién lo aprobó y qué versión resultó afectada.
Este historial permite reconstruir decisiones y evitar discusiones basadas en memoria o interpretaciones incompletas.
39.10 Estados de requerimientos
Un requerimiento puede pasar por estados como propuesto, en análisis, revisado, aprobado, implementado, verificado, rechazado, diferido o retirado.
Los estados ayudan a distinguir contenido preliminar de contenido vigente y permiten saber qué acciones faltan para cada requerimiento.
39.11 Control de requerimientos
El control de requerimientos consiste en administrar qué requerimientos están vigentes, cuáles cambiaron, cuáles fueron retirados y qué reglas deben seguirse para modificarlos.
Este control se apoya en versionado, trazabilidad, aprobación, registro de cambios y comunicación.
39.12 Control de acceso
En algunos proyectos, no todas las personas deben poder modificar requerimientos aprobados. Puede ser necesario definir permisos de lectura, edición, revisión y aprobación.
El control de acceso evita cambios accidentales o decisiones no autorizadas sobre el alcance.
39.13 Aprobación de versiones
Una versión aprobada debe indicar quién la aprobó, cuándo, con qué alcance y qué elementos quedaron pendientes. La aprobación puede registrarse mediante herramienta, acta, correo o firma.
La evidencia de aprobación es especialmente importante cuando hay compromisos contractuales, regulatorios o de entrega.
39.14 Relación con la gestión de cambios
Cuando existe una línea base, cualquier cambio relevante debe compararse contra esa referencia. Esto permite evaluar qué se agrega, elimina o modifica.
La gestión de cambios decide si la modificación se acepta; el versionado registra cómo queda reflejada en el contenido.
39.15 Relación con trazabilidad
La trazabilidad debe indicar qué versión de un requerimiento está relacionada con diseño, código, pruebas, defectos y decisiones. Si cambia el requerimiento, puede cambiar también esa relación.
Mantener trazabilidad por versión evita probar o desarrollar contra una definición antigua.
39.16 Comparación entre versiones
Comparar versiones permite identificar diferencias entre una definición anterior y una nueva. Esto ayuda a revisar impacto, validar acuerdos y comunicar cambios.
Las comparaciones deben enfocarse en contenido relevante: reglas, alcance, criterios de aceptación, restricciones, prioridades y responsabilidades.
39.17 Manejo de borradores
Los borradores permiten trabajar ideas antes de aprobarlas. Deben identificarse como tales para evitar que alguien los use como referencia oficial.
Un error frecuente es distribuir borradores sin aclarar su estado, lo que puede llevar a diseño o desarrollo basado en información no aprobada.
39.18 Requerimientos retirados
Un requerimiento retirado no debe simplemente desaparecer sin registro. Conviene indicar que fue eliminado, por qué, cuándo y qué elementos relacionados deben revisarse.
Esto evita que vuelva a aparecer por desconocimiento y permite entender decisiones de alcance tomadas en el pasado.
39.19 Versionado en herramientas
Las herramientas pueden ayudar a controlar versiones, registrar cambios, comparar contenido, administrar permisos y relacionar requerimientos con tareas o pruebas.
Aun así, la herramienta no reemplaza las reglas del proceso. El equipo debe saber cuándo versionar, quién aprueba y cómo se comunica cada cambio.
39.20 Versionado en enfoques ágiles
En enfoques ágiles también existe control de versiones, aunque muchas veces se expresa mediante estados del backlog, historias refinadas, criterios de aceptación y versiones de entrega.
Una historia aceptada para una iteración funciona como una referencia acordada para el equipo, aunque no se llame formalmente línea base.
39.21 Auditoría y cumplimiento
En proyectos regulados, el versionado y la línea base permiten demostrar qué se aprobó, qué se implementó, qué se probó y qué cambios ocurrieron.
La auditoría requiere evidencia confiable, por lo que los registros deben ser claros, completos y mantenidos durante el proyecto.
39.22 Comunicación de versiones
Cuando se publica una nueva versión o línea base, debe comunicarse a quienes la usarán. La comunicación debe indicar qué cambió, desde cuándo aplica y qué versión deja de estar vigente.
La falta de comunicación puede hacer que equipos distintos trabajen con definiciones diferentes.
39.23 Errores frecuentes
Algunos errores comunes son no distinguir borradores de versiones aprobadas, cambiar requerimientos sin registrar historial, usar identificadores inestables y no comunicar nuevas versiones.
También es un error conservar muchas copias sin control, porque aumenta la posibilidad de que alguien trabaje con contenido desactualizado.
39.24 Buenas prácticas
Conviene definir una convención simple de versiones, identificar líneas base, registrar cambios, conservar historial, controlar permisos y comunicar qué versión está vigente.
Además, las versiones deben relacionarse con trazabilidad y pruebas para asegurar que el equipo verifica el contenido correcto.
39.25 Qué debes recordar
El versionado identifica estados del contenido. La línea base marca una versión aprobada como referencia. El control de requerimientos administra qué está vigente y cómo se modifica.
Estas prácticas reducen confusión y permiten que análisis, diseño, desarrollo y pruebas trabajen sobre el mismo alcance.
39.26 Conclusión
Versionar, establecer líneas base y controlar requerimientos aporta orden cuando el proyecto evoluciona. Permite saber qué fue acordado, qué cambió y qué versión debe usarse para tomar decisiones.
En el siguiente tema veremos cómo se trabajan los requerimientos en enfoques ágiles e iterativos, donde el cambio es esperado pero también necesita claridad y control.