39. Mantenimiento y evolución de los casos de uso

39.1 Introducción

Los casos de uso no deberían quedar congelados después de la primera versión. En un proyecto real, los procesos cambian, aparecen nuevas reglas de negocio, se detectan excepciones, se incorporan usuarios y el sistema evoluciona.

Por eso, mantener los casos de uso es tan importante como escribirlos correctamente al inicio. Un caso de uso desactualizado puede confundir al equipo, generar pruebas incorrectas y provocar decisiones basadas en información vieja.

El mantenimiento consiste en revisar, actualizar y controlar los cambios para que la documentación siga representando el comportamiento esperado del sistema.

39.2 Por qué cambian los casos de uso

Un caso de uso puede cambiar por muchas razones. Algunas provienen del negocio y otras surgen durante el desarrollo o las pruebas.

• Cambia una regla de negocio.
• Se incorpora un nuevo actor.
• Aparece un flujo alternativo que no había sido considerado.
• Se modifica una integración con otro sistema.
• Se decide simplificar o dividir una funcionalidad.
• Un usuario valida el caso y detecta que el flujo real es diferente.

Estos cambios son normales. El problema no es que los casos de uso cambien, sino que cambien sin control.

39.3 Mantener no significa reescribir todo

Mantener un caso de uso no implica empezar de cero cada vez que aparece una modificación. En la mayoría de los casos alcanza con ajustar una regla, agregar una precondición, aclarar un paso, corregir un flujo alternativo o actualizar el resultado esperado.

La clave es identificar qué parte del caso de uso fue afectada y modificar solo lo necesario, sin perder consistencia con el resto del documento.

39.4 Ciclo de evolución de un caso de uso

La evolución de un caso de uso suele comenzar con una necesidad de cambio. Esa necesidad se analiza, se determina su impacto, se modifica la especificación, se valida la nueva versión y se comunica al equipo. Si el cambio afecta pruebas, diseño o desarrollo, también deben actualizarse esos elementos relacionados.

39.5 Control de versiones

Cada caso de uso debería tener una versión identificable. Esto permite saber cuál es la especificación vigente y evita que distintas personas trabajen con copias diferentes.

Una forma simple de controlar versiones es registrar:

• número o fecha de versión;
• autor del cambio;
• motivo de la modificación;
• partes afectadas;
• estado de validación o aprobación.

Este registro no necesita ser complejo, pero debe ser claro y fácil de consultar.

39.6 Impacto sobre otros artefactos

Cuando cambia un caso de uso, puede ser necesario actualizar otros elementos del proyecto. Por ejemplo, un cambio en el flujo principal puede afectar casos de prueba, prototipos de pantalla, historias de usuario, diagramas, reglas de negocio o tareas de desarrollo.

Por eso, antes de aceptar una modificación conviene analizar su impacto. Un cambio pequeño en apariencia puede provocar efectos importantes si modifica una regla central del sistema.

39.7 Trazabilidad del cambio

La trazabilidad permite responder preguntas como: ¿por qué se modificó este caso de uso?, ¿quién pidió el cambio?, ¿qué prueba se actualizó?, ¿qué pantalla fue afectada?

No siempre hace falta una herramienta compleja. En proyectos pequeños puede alcanzar con una tabla de cambios. En proyectos más grandes puede utilizarse un sistema de gestión de requisitos, tareas o incidencias.

39.8 Cuándo conviene dividir un caso de uso

Durante la evolución, un caso de uso puede crecer demasiado. Si acumula muchos objetivos, demasiados flujos alternativos o reglas que pertenecen a procesos distintos, puede ser conveniente dividirlo.

La división ayuda cuando cada parte tiene un objetivo propio, puede ejecutarse de manera independiente o es usada por actores diferentes.

39.9 Cuándo conviene unir casos de uso

También puede ocurrir lo contrario: varios casos de uso muy pequeños describen fragmentos inseparables de una misma interacción. En ese caso, mantenerlos separados puede generar repetición y confusión.

Conviene unir casos de uso cuando comparten el mismo objetivo, el mismo actor principal y forman parte de una única conversación funcional con el sistema.

39.10 Cambios en actores

Si aparece un nuevo actor o cambia la responsabilidad de uno existente, se debe revisar qué casos de uso puede iniciar, en cuáles participa y qué permisos necesita.

Por ejemplo, si en un sistema de turnos se agrega el actor Recepcionista, puede ser necesario modificar casos de uso como Registrar paciente, Solicitar turno, Cancelar turno o Consultar agenda.

39.11 Cambios en reglas de negocio

Las reglas de negocio suelen ser una de las principales causas de modificación. Un caso de uso puede cambiar si se modifica una política de aprobación, un límite, una condición, un cálculo o una validación.

Cuando una regla cambia, no alcanza con editar una frase. Hay que revisar si afecta precondiciones, pasos del flujo principal, flujos alternativos, excepciones y resultados esperados.

39.12 Cambios por errores detectados

Durante el desarrollo o las pruebas pueden aparecer errores en la especificación: pasos ambiguos, datos faltantes, condiciones contradictorias o excepciones no contempladas.

Estos hallazgos deben corregirse en el caso de uso, no solo comentarse informalmente. Si el documento queda desactualizado, el mismo error puede repetirse en futuras modificaciones.

39.13 Estado de un caso de uso

Para mantener ordenado el conjunto de casos de uso, conviene indicar el estado de cada uno. Algunos estados posibles son:

• Borrador: todavía se está elaborando.
• En revisión: está siendo evaluado por el equipo.
• Validado: fue confirmado con usuarios o negocio.
• Aprobado: puede usarse como base formal de trabajo.
• Obsoleto: ya no representa una funcionalidad vigente.

39.14 Tabla de historial de cambios

Una tabla sencilla puede ayudar a mantener el control de la evolución.

39.15 Errores frecuentes

• Actualizar el sistema pero no actualizar el caso de uso.
• No registrar quién solicitó el cambio.
• Modificar el flujo principal sin revisar los flujos alternativos.
• Mantener casos de uso obsoletos como si siguieran vigentes.
• No comunicar al equipo que existe una nueva versión.
• Convertir el caso de uso en una mezcla de versiones anteriores y actuales.

39.16 Buenas prácticas

• Mantener una versión vigente claramente identificada.
• Registrar los cambios importantes.
• Validar modificaciones funcionales con usuarios o negocio.
• Revisar el impacto sobre pruebas, pantallas y reglas.
• Eliminar o marcar como obsoletos los casos que ya no se usan.
• Evitar cambios informales que no queden reflejados en la documentación.

39.17 Qué debes recordar de este tema

• Los casos de uso evolucionan junto con el sistema y el negocio.
• Un caso de uso desactualizado puede provocar errores de análisis, desarrollo y prueba.
• Todo cambio importante debe tener motivo, responsable y versión.
• La trazabilidad ayuda a entender el impacto de una modificación.
• Mantener casos de uso claros es una actividad continua, no una tarea única del inicio del proyecto.

39.18 Conclusión

El mantenimiento de los casos de uso permite que la documentación siga siendo útil durante todo el ciclo de vida del software. No se trata de escribir documentos extensos, sino de conservar una descripción confiable del comportamiento esperado del sistema.

Cuando los casos de uso se actualizan con criterio, el equipo puede tomar mejores decisiones, reducir malentendidos y mantener alineados requisitos, diseño, desarrollo y pruebas.