5.3 Taller E05: construir y revisar CU-01

Al terminar esta lección

• Producir tres versiones fechadas de CU-01 (V0 a V2) y registrar qué evidencia obliga a cada cambio.
• Dibujar un diagrama de casos de uso con actores externos y relaciones include y extend con la dirección y la condición correctas.
• Redactar cinco alternativos con condición observable y seis criterios de aceptación con oráculo de efectos y no-efectos.
• Presentar el caso a un cliente con ejemplos, y revisar el gate contra evidencia dejando visibles los desconocidos.

Práctica E05 · Construir CU-01 por iteraciones

Situación. Partí de la versión inicial y aplicá la nueva evidencia sobre crédito/reserva.

Entregá. diagrama UML revisado; especificación CU-01; 5 alternativos; 6 criterios de aceptación.

Está listo cuando. las relaciones UML tienen dirección correcta; el curso habla Actor ↔ Sistema; cada alternativo tiene condición observable; las garantías expresan ausencia/presencia de efectos.

Solución comentada: Solución comentada E05. Comparala después de producir tu entrega.

Construí CU-01 en tres versiones, no una sola. Guardá cada versión y escribí qué nueva evidencia obliga al cambio. Las cantidades de "Entregá" son el mínimo para aprobar; los pasos que siguen te piden un poco más (por ejemplo, ocho escenarios en lugar de seis criterios) porque los escenarios son la materia prima de los criterios. Las versiones v3 y v4 de la lección 5.2 (garantías explícitas y validación con tres personas) quedan como material de contraste: la garantía mínima la definís ya en V1, y la validación la hacés vos en el cuaderno de campo.

Antes de empezar, juntá los insumos: el pedido 48172 (23 códigos, acuerdo de precio, saldo sobre el límite, AX-442 con 8 en CBA, 6 reservadas y 3 pedidas), el caso del cliente de contado, RN-01 a RN-05, RN-07 como BLOCKED y la política de método de entrega (retiro o envío). Tené a mano la Figura 5 (hipótesis inicial) de la lección 5.1.

Paso 1 · V0: el caso con la información disponible (15 min)

Objetivo. Redactar la primera versión con lo que se sabía antes de conocer autorización y múltiplos. Es deliberadamente corta y deliberadamente rota: sirve para tener algo que el pedido 48172 pueda romper.

Incluí objetivo, actor primario, disparador, precondiciones, curso principal y garantía de éxito. Escribí cada paso como diálogo actor-sistema y evitá verbos de interfaz.

Ejemplo parcial trabajado.

1CU-01 Registrar pedido
2Actor primario: Vendedor
3Disparador: un cliente le pide mercadería al vendedor.
4Objetivo: dejar el pedido cargado para que se prepare.
5Precondiciones:
6- vendedor autenticado
7Curso principal:
81. El vendedor identifica al cliente y envía las líneas.
92. El sistema ...   <- completalo vos

Fijate qué le falta: no dice quién decide el precio, qué pasa si el crédito no alcanza ni qué significa "cargado". Eso es lo que van a atacar los pasos siguientes.

Paso 2 · V1: crédito pendiente y garantía mínima (20 min)

Objetivo. Incorporar la política de crédito pendiente y definir la garantía mínima. Es el paso donde más tentaciones hay de inventar.

Regla del paso. Evitá inventar si la reserva se mantiene o no mientras el pedido espera autorización, y no pongas un plazo. Lo que sí sabés: el pedido queda en PENDIENTE_AUTORIZACION, existe un actor que decide (Responsable de crédito) y el plazo de la reserva blanda es RN-07, BLOCKED. Si falta evidencia, marcala como desconocida con responsable.

Ejemplo parcial trabajado. Un alternativo A3 incompleto y su corrección.

1-A3. Crédito no alcanza: rechazar el pedido.
2+A3. Crédito requiere autorización: el pedido queda en PENDIENTE_AUTORIZACION con la causa,
3+    se crea la solicitud para el Responsable de crédito y la reserva, si existe, es blanda
4+    con vencimiento según RN-07 (plazo BLOCKED).

La garantía mínima, ahora sí:

1Garantía mínima:
2Ante rechazo o fallo no existe pedido confirmado con reserva parcial.
3Cualquier estado pendiente conserva la causa y el actor que debe resolverlo.

Paso 3 · V2: cantidad, unidad de venta y método de entrega (15 min)

Objetivo. Incorporar las reglas de cantidad y el método de entrega, y revisar si cambian actores, frontera o granularidad. La respuesta suele ser que no: eso es un resultado válido.

Ejemplo parcial trabajado. La validación de cantidad ya no es trivial.

12. El sistema valida identidad, cantidades y productos:
2   - la cantidad es un entero positivo;
3   - respeta la unidad de venta y el múltiplo del SKU (caja cerrada, unidad, o el múltiplo del acuerdo);
4   - el SKU existe y, si fue reemplazado, aplica la equivalencia vigente a la fecha del pedido.
51. ... método de entrega: retiro o envío

Mirá lo que ocurre con el método de entrega: entra como dato del paso 1, pero el caso no se extiende hasta despachar. Si lo hicieras, estarías metiendo logística dentro de un caso que termina cuando el pedido queda registrado.

Paso 4 · El diagrama UML revisado (15 min)

Objetivo. Partir de la Figura 5 y producir la versión que refleja la evidencia nueva. Lo que se evalúa es la dirección de las flechas, los actores y la frontera, no la prolijidad del dibujo.

Qué corregir de la Figura 5. Consultar catálogo no es un objetivo. Faltan CU-02 (autorizar excepción de crédito, con su actor), el operario de depósito y la preparación del pedido. El ERP es actor secundario. La relación entre "Registrar pedido" y la autorización no es un include.

Ejemplo parcial trabajado. Un fragmento con la dirección correcta, para que lo extiendas.

Paso 5 · Cinco alternativos (15 min)

Objetivo. Escribir cinco alternativos, cada uno con condición observable, resultado de negocio y efectos que no deben ocurrir.

Ejemplo parcial trabajado. Un alternativo bien armado sigue el patrón condición, resultado, efectos.

1A2. Stock insuficiente
2Condición: para al menos una línea, disponible por depósito (onHand - reserved) es menor que la cantidad.
3Resultado: no confirma; informa faltante por SKU y las alternativas permitidas.
4Efectos que no ocurren: pedido confirmado, reservas parciales, descuento de disponibilidad.

Observá la condición: es algo que un test puede preparar. "Cuando no hay stock" no lo es; "cuando AX-442 tiene 8 en el ERP, 6 reservadas y el pedido pide 3" sí.

Paso 6 · Escenarios y seis criterios de aceptación (20 min)

Objetivo. Derivar al menos ocho escenarios que incluyan borde exacto de crédito, cantidad inválida, SKU inexistente, falta de stock y autorización, y quedarte con seis criterios de aceptación para entregar. Cada criterio traduce una regla a una propiedad observable.

Ejemplo parcial trabajado. Dos escenarios sobre RN-01, que ya conocés de la matriz de riesgo: el borde exacto y un centavo sobre el borde.

1Característica: Evaluación de crédito al registrar un pedido
2​
3  Escenario: AC-02 exactamente en el límite
4    Dado un cliente ESTÁNDAR con límite 500.000,00 y saldo deudor 480.000,00
5    Y un pedido con total 20.000,00
6    Cuando el vendedor registra el pedido
7    Entonces el pedido queda CONFIRMADO
8    Y existe evidencia de la decisión de crédito
9​
10  Escenario: AC-03 un centavo sobre el límite
11    Dado un cliente ESTÁNDAR con límite 500.000,00 y saldo deudor 480.000,00
12    Y un pedido con total 20.000,01
13    Cuando el vendedor registra el pedido
14    Entonces el resultado es un rechazo por crédito
15    Y no existe pedido confirmado
16    Y no hay stock reservado

La numeración AC-02 y AC-03 sigue el catálogo que consolida el módulo 6; si el tuyo difiere, mantené la tuya y explicá la correspondencia. Lo que no se negocia es que cada escenario tenga un oráculo con efectos y no-efectos: "no hay stock reservado" pesa tanto como "queda rechazado".

Paso 7 · Playback oral con el cliente (10 min)

Objetivo. Presentar el caso oralmente como si hablaras con el cliente. No expliques include, extend ni otros símbolos. Contá el objetivo, las decisiones y qué pasa en los casos difíciles.

Ejemplo parcial trabajado. Una apertura que funciona:

"Quiero confirmar con ustedes qué significa dejar un pedido registrado. Les cuento tres casos: uno normal, uno que se pasa del límite y uno con la última unidad. Corríjanme donde no sea así."

Después elegí números del caso (límite 500.000, deuda 480.000, pedido 30.000), movelos un centavo y registrá cada respuesta como confirmación, corrección o desconocido con responsable. Si el cliente pregunta algo cuya respuesta no sabés (el plazo de la reserva en espera, por ejemplo), no improvises: decí que queda pendiente, quién lo define y cómo lo vas a medir.

PROMPT DE REVISIÓN DE CU
Revisá este caso de uso contra las RN adjuntas. Buscá: pasos que sean UI y no comportamiento, decisiones sin regla, alternativos sin garantía mínima, estados inventados, duplicación de reglas y actores que en realidad sean componentes internos. No corrijas silenciosamente: listá el problema, la evidencia que falta y una propuesta que requiera aprobación.

Criterio de revisión. El CU está listo cuando negocio puede validar comportamiento, desarrollo puede implementar sin inventar una decisión y testing puede derivar escenarios sin adivinar el oráculo.

Nexo B2B · El caso de uso que cambió cuatro veces antes de ser útil

La primera versión de CU-01 decía: "El vendedor crea un pedido, el sistema valida datos y guarda". Era correcta sintácticamente y casi inútil para construir. No decía qué significa validar, qué resultado busca el vendedor, quién controla precio, qué ocurre con crédito ni qué garantía conserva el sistema si algo falla. Dos desarrolladores podían leerla y construir comportamientos incompatibles sin violar una sola frase.

En una segunda conversación, depósito introduce una diferencia que ventas no había mencionado. Para pedidos chicos, la reserva se realiza en el depósito habitual del cliente. Para pedidos grandes, logística puede dividir preparación entre dos depósitos (CBA y CEN). El equipo pregunta si esa división debe entrar en el primer slice. La respuesta es no: existe operacionalmente, pero representa menos del cinco por ciento de los pedidos y todavía no está documentado cómo se elige depósito. El caso de uso no la borra. La registra como escenario fuera de alcance del release y como riesgo para una expansión posterior.

Luego aparece el precio. Ventas afirma que "el precio es el de la lista del cliente", pero una factura reciente muestra un acuerdo temporal por SKU. La especificación cambia otra vez. El actor no entrega un precio autoritativo. Entrega intención de compra, cliente, SKU y cantidad. El sistema debe resolver el precio desde las fuentes aprobadas y guardar un snapshot del precio aplicado para que una actualización posterior de listas no reescriba pedidos ya confirmados.

La última modificación ocurre al revisar crédito. Antes, el flujo alternativo decía "si supera el límite, rechazar". El responsable comercial muestra tres pedidos que fueron autorizados manualmente. El caso de uso deja de tratar esa situación como error y la expresa como resultado de negocio: PENDIENTE_AUTORIZACION. Queda explícito que el sistema no confirma ni reserva definitivamente lo que la política no permite, y que una autorización posterior debe registrar actor, fecha, motivo y regla aplicada.

El valor de ver estas versiones no es aprender que un caso de uso debe ser largo. Es aprender que el artefacto funciona como superficie de negociación. Cada modificación elimina libertad interpretativa que antes iba a terminar en código.

Nexo B2B · Expediente 05: tres pedidos contra CU-01

Pedido A: cliente estándar, stock suficiente, exposición debajo del límite. Pedido B: cliente con acuerdo de precio y exposición que requiere autorización. Pedido C: última unidad, dos vendedores y un retry de red. CU-01 debe explicar A y B; C además expone propiedades arquitectónicas que el caso de uso referencia como garantías e invariantes.

Si el CU solo explica A, es un happy path. Si intenta describir locks y SQL para explicar C, se volvió diseño. La frontera correcta conserva comportamiento y garantías, dejando mecanismo para arquitectura.

Cuaderno de campo 05 · Walkthrough por ejemplos

Entregable: CU-01 validado con al menos cinco episodios o escenarios y registro de cambios entre versiones.

1. Leé el curso principal usando Pedido A y comprobá que cada paso tenga actor o sistema responsable.
2. Recorré Pedido B y confirmá que autorización sea un flujo definido, no un "error".
3. Recorré Pedido C y señalá qué propiedades deben preservarse aunque el mecanismo no esté en el CU.
4. Tomá un episodio que no encaje. Antes de agregar un alternativo, verificá si pertenece realmente al mismo objetivo.
5. Pedí al cliente que reformule con sus palabras qué significa éxito y qué queda pendiente. Ajustá vocabulario si difiere.

Criterio de revisión. Revisión: el caso de uso debe ser suficientemente preciso para generar tests, pero suficientemente tecnológico-agnóstico para sobrevivir a un cambio de framework.

Errores frecuentes

Hoja de entrega 5 · completá antes de pasar el gate

Este bloque no se completa "de memoria". Volvé a tus artefactos, evidencia y resultados. El objetivo es obligarte a hacer explícito qué vas a defender frente a un mentor o cliente.

Artefacto que entrego y versión:

Tres evidencias que sostienen mis decisiones:

Decisiones que tomé yo y que un agente no podía tomar:

Desconocidos o riesgos que siguen abiertos:

Feedback o propuesta de IA que rechacé, y por qué:

Qué tendría que ocurrir para que yo mismo cambie esta conclusión:

Revisión de calidad: qué corregí antes de enviar o presentar:

Firma del mentor/reviewer o referencia del feedback:

Gate 5 · el comportamiento está suficientemente definido

Guardá tu entrega

Cuando termines tu entrega, compará tu razonamiento con la solución comentada E05. No hay una única respuesta correcta: la comparación busca fuentes, decisiones y evidencia.

Para llevarte

• Construir un caso en versiones deja a la vista qué evidencia cambia cada decisión; sin esa traza el caso es una opinión.
• Un alternativo se escribe como condición preparable, resultado de negocio y efectos que no ocurren.
• Las relaciones UML se justifican por completitud y condición: include sale del base, extend llega al base.
• Los criterios de aceptación valen por su oráculo: efectos y no-efectos, con datos concretos.
• Lo que depende de un dato desconocido (RN-07, RN-02) queda BLOCKED con dueño, sin frenar lo demás.
• El playback valida comportamiento con ejemplos; el cliente no tiene por qué ver UML.