Casos_de_Uso_contra_el_software_equivocado

0:00

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

En la industria del desarrollo tecnológico existe un tipo de desastre muy particular. Y mira que no me refiero a cuando un servidor se incendia o cuando un hacker vulnera una base de datos. Ah, claro. Estos son los desastres ruidosos. Exacto. Yo me refiero a un escenario mucho más, digamos, insidioso. Imagínate a un equipo de ingenieros brillantes que pasa meses o incluso años escribiendo millones de líneas de código perfecto.

0:28

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

con una arquitectura impecable. El producto se lanza, no tiene un solo error técnico y, sin embargo, es un fracaso absoluto. Totalmente. Y la gente se pregunta por qué pasa esto. Pues porque el sistema hace maravillosamente bien algo que absolutamente nadie necesitaba que hiciera. La comunicación entre los humanos que querían el producto y los técnicos que lo construyeron fue desde el día 1

0:54

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

un teléfono descompuesto. Es un fenómeno aterradoramente común, la verdad. Y lo más grave es que solemos culpar a la falta de habilidad técnica, cuando en realidad el colapso ocurre en la etapa de traducción. Es este abismo gigante que existe entre, a ver, la ambigüedad del lenguaje humano y la rigidez binaria del código. Y precisamente para cruzar ese abismo existe una herramienta que funciona como un mapa de navegación.

1:20

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Así que bienvenidos a esta nueva exploración profunda.

1:24

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Hoy nos vamos a sumergir en una montaña de investigación muy reveladora. Sí, tenemos muchísimo material de primer nivel para analizar hoy. Así es. Tenemos presentaciones académicas rigurosas de la Universidad de Granada y la Universidad Carlos III de Madrid, análisis profundos de firmas especializadas como Avistar y Testing Vitis, y por supuesto la visión más pragmática de plataformas de gestión como White y Visual Paradigm.

1:51

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

El objetivo hoy es desmitificar una metodología que suena puramente técnica, pero que en el fondo trata sobre el comportamiento humano. Me refiero a los famosos casos de uso.

2:03

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Que son fundamentales, ¿eh? Absolutamente fundamentales. Ok, vamos a desempacar esto. Porque para cualquier persona que busque entender cómo evitar construir el producto equivocado, o bueno, cómo alinear a desarrolladores y directivos en la misma página sin que corra sangre, fíjate que esta información es oro puro. Es la pieza clave del rompecabezas. Y para entender por qué esta herramienta es tan vital, tenemos que observar el problema original que intentaba resolver, ¿no?

2:31

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Si miramos cómo era la documentación de software antes de los años 80, te das cuenta de que era básicamente una autopsia técnica. Una autopsia. ¡Qué buena analogía! Sí. O sea, los manuales describían cómo estaban engranadas las piezas internas de la máquina.

2:47

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Todo, absolutamente todo, se documentaba desde adentro hacia afuera. Describir los engranajes en lugar de explicar para qué sirve el reloj, básicamente. Yo como usuaria no quiero saber de las tuercas, quiero saber la hora. Exactamente, esa es la mentalidad.

3:04

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Y fue una perspectiva que se volvió insostenible por ahí de 1987. El ingeniero informático sueco Ivar Jacobson trabajaba en Ericsson, la gigante de telecomunicaciones. Claro, Ericsson en esa época era un monstruo. Imagínate la infraestructura de Ericsson en esos años. Centrales telefónicas masivas, enrutamiento global, una interacción brutal entre hardware físico pesado y redes de software incipientes.

3:30

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Jacobson se dio cuenta de que si seguían documentando el código por sus funciones internas, bueno, la complejidad los iba a sepultar vivos. No había forma de mantener ese ritmo. Ninguna. Necesitaban imperiosamente invertir el modelo. Había que describir el sistema basándose exclusivamente en cómo un agente externo interactuaba con él. Pero a ver, detengámonos ahí un segundo porque, cruzando esa historia con las metodologías ágiles que dominan la industria actual, me surge un choque de conceptos. Yo estoy un poco confundida.

3:58

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

A ver, dime. Si un caso de uso describe simplemente lo que un agente externo quiere hacer con el sistema, no es eso una historia de usuario. Ya sabes, el clásico user story de la metodología Agile. Siento que la industria a veces recicla ideas de los 80, les pone un nombre en inglés moderno para los sprints y bueno, finge que inventó algo nuevo. Entiendo perfecto por qué te da esa impresión. Y de hecho, es una confusión que plaga a muchísimos equipos hoy en día.

4:26

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Pero no, no son lo mismo disfrazado. La fuente de Testing Virus aborda esta discrepancia con una precisión quirúrgica y todo se reduce a la profundidad topográfica del documento. Ok, a ver, déjame probar una analogía para ver si aterrizo bien la diferencia. Imaginemos la producción de una película de Hollywood. Me gusta, te sigo. La historia de usuario sería el pitch o discurso de ascensor que le das al estudio. Algo así como un cliente abre la aplicación y compra un boleto en dos clics.

4:56

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Mientras que el caso de uso sería el guión técnico completo con pos...

5:00

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Posiciones de cámara, iluminación y diálogo exacto. La analogía del guión cinematográfico suena muy bien el principio, pero tiene un peligro oculto. ¿Ah, sí? ¿Cuál? Un guión es estrictamente lineal. Pasa de la escena A a la escena B a la escena C sin desviarse.

5:18

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Un caso de uso, en realidad, se parece muchísimo más a un libro de Elige tu propia aventura. Oh, ya, claro. Las ramificaciones. Exacto. Testing Byres lo aclara así. La historia de usuario es deliberadamente concisa, escrita desde la perspectiva del valor de negocio. Su fórmula clásica, que todos conocemos, es, como usuario X, quiero Y para lograr Z. Claro, es el titular de la noticia. Es el titular, sí.

5:44

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Se enfoca en las necesidades y en los criterios de aceptación para que el equipo ágil pueda estimar el trabajo rápidamente durante una reunión. OK. Te dice qué problema hay que resolver y por qué es valioso, pero no te dicta la arquitectura técnica de cómo vas a resolverlo. Exactamente. El caso de uso, por el contrario, es altamente detallado y estructurado. No se queda en el simple qué. Documenta precondiciones, poscondiciones, flujos principales.

6:12

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Y lo más crucial de todo, ramifica todos los escenarios alternativos posibles. Ya veo. Lo fascinante aquí es que a pesar de los debates tóxicos que ves en foros de desarrolladores, donde casi obligan a la gente a elegir un bando, la realidad es que ambas herramientas no compiten, sino que los analistas exitosos las combinan. Se potencian mutuamente entonces. Totalmente.

6:33

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

La historia de usuario mantiene al equipo enfocado en el valor real para el cliente humano, y el caso de uso actúa como el diseño estructural que evita que el programador tenga que adivinar qué demonios pasa si la base de datos se cae a mitad de la transacción de pago.

6:50

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Entonces la historia de usuario te da la brújula para saber hacia dónde ir, pero el caso de uso te da el mapa topográfico detallado con todas las minas terrestres marcadas. Esa es una descripción perfecta. Sabiendo esto, pasemos de la historia y la teoría a la anatomía pura.

7:06

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Porque si revisamos las guías de WIC y el material académico de la Universidad Carlos III, nos muestran que un caso de uso no es un párrafo libre escrito en Word. Tiene componentes innegociables. Tenemos el sistema, que es la frontera de lo que estamos construyendo, y el objetivo. Y luego están las famosas precondiciones. Uf, las precondiciones son fundamentales. Establecen el estado exacto en el que debe estar el universo antes de que la acción siquiera comience a ejecutarse.

7:34

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

¿Cómo revisar si tienes las llaves antes de intentar arrancar el coche? Tal cual. El usuario ya inició sesión. Hay conexión activa a la pasarela de pagos externa. Si la precondición no se cumple, el caso de uso ni siquiera arranca. Se aborta antes de empezar.

7:49

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Pero leyendo las fuentes, el componente que me generó más fricción, y te lo confieso, fue el de los actores. Se clasifican en principales, secundarios, internos, y aquí te lanzo una objeción, porque la palabra actor sugiere inherentemente a una persona, ¿no? Alguien tecleando en un teclado o deslizando el dedo en una pantalla. Siento que esa nomenclatura puede llevar a los analistas junior a ignorar la mitad de las interacciones críticas de un sistema.

8:15

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Y es una crítica muy, muy válida a la terminología estándar de UNL. La palabra actor es engañosa. Como humanos, asumimos un antropomorfismo inmediato. Pero en el modelado de sistemas moderno, un actor es absolutamente cualquier entidad externa que cruza la frontera del sistema para interactuar con él. No tiene que tener pulso. Espera, los actores no siempre son personas, ¿verdad?

8:39

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Entonces, ¿un actor puede ser, digamos, un trozo de hardware? Un componente de hardware, un servidor de un tercero, un temporizador interno tonto que dispara una limpieza de base de datos a las 3 de la mañana todos los domingos, o incluso toda una organización corporativa. Para visualizar eso mejor, el ejemplo que da Wrike sobre una plataforma de entrega de comida es perfecto.

9:02

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

A ver, el actor principal es fácil. Es el cliente humano que tiene hambre, busca Sushi Lab y paga. Ese es el que inicia la acción. El sistema procesa la orden. Pero luego entra el actor secundario que es el restaurante. Exacto. Y fíjate cómo funciona.

9:19

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

El restaurante no está pidiendo comida. No inicia la transacción. Está siendo notificado e impulsado a la acción por el sistema. Recibe un servicio del sistema para poder operar sus cocinas. Por lo tanto, cae en la categoría de actor secundario. Y modelar correctamente a ese actor secundario es lo que define si el sistema de la plataforma escala de forma global o colapsa el primer viernes por la noche. Ahora bien.

9:46

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Si queremos ver la verdadera anatomía en acción, el material de la Universidad Carlos III nos presenta el caso de un cajero automático. Ese ejemplo me pareció brillante, porque sacar dinero parece la transacción más trivial del mundo.

10:00

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Todos lo hacemos. Metes el plástico, pones tu pin de cuatro dígitos, sacas los billetes y te vas. Es el famoso Happy Path o flujo básico. Sí, pero el gran problema con la industria del software es que nos enamoramos ciegamente del Happy Path. Es este escenario idílico donde el usuario hace todo perfecto, la red es rapidísima y los servidores cantan al unísono.

10:22

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Pero te digo algo. El analista de casos de uso profesional realmente gana su sueldo diseñando los cursos alternativos. Las excepciones. El caos absoluto de la vida real. El caos controlado preferiblemente. En el documento expandido que nos muestran, si la línea 3 del flujo básico dice, el usuario introduce su PIN, tienes que detenerte y ramificar. ¿Qué pasa en la línea 3.1 si el PIN es incorrecto? Claro, no puedes dejar eso al aire. El sistema simplemente muestra un mensaje de…

10:51

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

error genérico en la pantalla. Le da tres intentos al usuario. Y si al tercer intento la máquina retiene la tarjeta físicamente, bloquea la cuenta localmente o manda una alerta de fraude al banco central. Todo eso tiene que estar escrito. Todo.

11:06

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Más adelante en el flujo, si el usuario pide 100 dólares en efectivo, pero su saldo real es de 5 dólares, el cajero rechaza la transacción inmediatamente y expulsa la tarjeta. O el sistema tiene una regla de negocio donde le ofrece un préstamo de sobregiro con una comisión extra. ¡Guau! ¡Claro!

11:22

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Y si no defines esa lógica de negocio específica en el documento desde el principio, básicamente estás dejando que el desarrollador de turno a las 2 de la mañana un viernes con sobredosis de café tome una decisión financiera crítica basándose en lo que a él le parezca más fácil de programar en ese momento. Y eso, honestamente, es negligencia corporativa. Total y absolutamente. Evitas la negligencia documentando meticulosamente.

11:49

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Ahora, leer un documento de texto larguísimo con ramificaciones tipo 3.1.a es súper útil para el programador que está tecleando, pero es intragable para el resto del equipo.

12:01

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

necesitamos visualizar la arquitectura de alguna forma. Entre el lenguaje visual. Así es. Por eso el Object Management Group, el famoso OMG, tomó las ideas originales de Jacobson y las estandarizó en el lenguaje visual UML, con los famosos Stickmen, ya sabes, los diagramitas de monigotes de palitos y los óvalos. Aquí es donde se pone realmente interesante. Porque al momento de pasar del papel aburrido al dibujo,

12:27

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Es donde la comunidad de desarrollo entra en una especie de guerra civil tecnológica constante. Uf, ni me lo digas. Tema visual que, te lo juro, causa más reuniones improductivas que cualquier otra cosa en tecnología. El debate eterno entre las relaciones include, o sea, incluye, y extend, extiende. Es el hoyo negro de la productividad en el diseño de software, sin duda.

12:52

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Para quienes no están familiarizados, ambas son simplemente flechas punteadas que conectan dos óvalos, o sea, dos casos de uso, en el diagrama para mostrar que uno depende del otro o que lo complementa.

13:03

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

El objetivo original de esto era muy simple, reutilizar el diseño, pero en la práctica te genera una confusión monumental. A ver, voy a intentar aterrizarlo con una situación cotidiana, a ver si me sale. Imagina que volvemos a la época de rentar películas físicas en un videoclub. Qué buenos tiempos, claro. El caso de uso base, el flujo principal de nuestro sistema imaginario, es rentar película.

13:29

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Ahora, para que ese flujo exista y tenga sentido comercial, obligatoriamente tengo que cobrarte el alquiler. El caso de uso procesar pago sería un include. Es una inclusión porque sin el pago procesado, la renta está incompleta. Falla.

13:50

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

El caso base necesita desesperadamente al caso incluido para cumplir su objetivo principal. Es inegociable, ¿verdad? La definición es sumamente sólida, sí. El include se usa estrictamente cuando el comportamiento del caso incluido es esencial. Si lo quitas o falla, el caso base se rompe o pierde todo su sentido de negocio. No hay renta sin tag. Bien, hasta ahí vamos bien.

14:14

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Pero supongamos que este videoclub tiene un sistema de recompensas. Si durante esa misma transacción el sistema detecta que soy cliente VIP frecuente, me acumula puntos en mi cuenta.

14:28

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Ese cálculo de puntos sería un extend. Ajá, a ver por qué. Es un extensión, porque el flujo principal de rentar película funciona perfectamente sin él. O sea, si el servidor de puntos se cae ese día, yo igual pago y me llevo mi película a casa. El extend simplemente añade un comportamiento extra, un valor agregado, que solo se dispara bajo ciertas condiciones específicas. En este caso, ser un cliente VIP. Impecable.

14:57

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

La diferencia clave ahí radica en la obligatoriedad.

15:00

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

El incluido es vital e indispensable. El extendido es opcional o condicional.

15:05

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Sin embargo, aunque la teoría parece muy sencilla cuando usamos tu analogía del videoclub, la fuente de Avistar advierte sobre un fenómeno muy destructivo que ocurre cuando los analistas se enfrentan a un lienzo en blanco en su software de diagramación. Uy, sí, lo leí. Si conectamos esto con el panorama general de los errores de diseño, llegamos a lo que ellos denominan la creación de casos de abuso. Esa frase me encanta. Casos de abuso.

15:31

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Suena a que alguien está utilizando el estándar UML como un arma contundente contra su propio equipo, ¿no? ¿A qué se refieren exactamente con eso? Literalmente es un abuso de la herramienta visual. Se refieren a diagramas que, cuando los ves, parecen un plato de espagueti enredado.

15:49

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Y esto tiene una raíz histórica y psicológica muy interesante en el gremio. A ver, cuéntame. Muchos analistas y programadores, especialmente los que se formaron en la vieja escuela de la era de la programación estructurada y los diagramas de flujo lógicos, sienten una necesidad casi compulsiva de modelar cada pequeña decisión del sistema. Ya sabes, cada si pasa esto, si no, mientras, utilizando decenas de flechas de include y extend.

16:13

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

O sea, intentan usar un diagrama de altísimo nivel para escribir pseudocódigo de programación. Quieren meter todas las excepciones detalladas, como lo del pin incorrecto del cajero que hablábamos antes, directamente en el dibujo visual creando 50 óvalos nuevos interconectados. Exactamente. Y eso destruye por completo el propósito comunicativo del diagrama.

16:37

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Un diagrama de casos de uso debe mostrar qué hace el sistema avista de pájaro, no cómo lo hace paso a paso por debajo del capó. Tiene sentido. Además, avistar señala otro error garrafal que es súper común.

16:50

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

usar estas relaciones visuales para modelar la navegación de la interfaz de usuario. Espera, ¿cómo es eso? ¿Te refieres a como poner una flecha que vaya del óvalo, ver carrito de compras, al óvalo, términos y condiciones, solo porque hay un enlace de texto en el pie de página de la web? Tal cual.

17:08

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

He visto literalmente cientos de diagramas corporativos donde un analista crea una relación extend entre iniciar sesión y recuperar contraseña simplemente porque en la pantalla física hay un botoncito que te lleva a ese otro formulario. Ay, no, eso es mezclar peras con manzanas. Es terrible. Las decisiones estéticas de diseño de interfaz gráfica jamás deben dictar las relaciones estructurales del caso de uso. ¿Si caes en esa trampa?

17:34

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Cada vez que el diseñador web cambie de lugar un botón en la pantalla, el equipo de backend tendrá que refactorizar toda la arquitectura del sistema documentado. Es absurdo e insostenible. Entiendo perfecto el problema, pero entonces, a ver, si no debemos usar estas herramientas visuales para flujos lógicos complejos ni para mapas de navegación de clics, ¿cuál es la regla de oro?

17:55

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

¿Por qué la industria sigue usando el include en primer lugar si solo nos va a traer problemas de interpretación? La respuesta corta y contundente a eso es el reuso, reutilización pura de código y esfuerzo.

18:07

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

El único motivo real y justificable para extraer un comportamiento a un caso de uso separado e incluirlo es si lo vas a usar idéntico en múltiples lugares. Dame un ejemplo práctico de eso. Claro. Si tú identificas que el proceso complejo de validar huella digital ocurre cuando el usuario inicia sesión, pero también ocurre al autorizar un pago fuerte y también al intentar cambiar datos sensibles de la cuenta, lo que haces es sacarlo, haces un óvalo independiente llamado validar huella y haces que los tres casos base apunten hacia él con una flechita de include.

18:36

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Ah, OK. Así le dices claramente al equipo de desarrollo. Muchachos, programen la biometría una sola vez como un módulo independiente, pruébenlo exhaustivamente una sola vez y simplemente conéctenlo en todas estas partes. Optimización de recursos, puro y duro. Ahorras muchísimo tiempo de código, evitas duplicar errores y estandarizas la seguridad de la app. Exactamente.

18:58

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Pero bueno, aquí quiero presionar un poco sobre la viabilidad de todo esto en el mundo real, allá afuera, porque toda esta teoría sueca suena fantástica para un proyecto estático, digamos enviar un cohete a la luna. Pero hoy en día la industria trabaja casi exclusivamente con metodologías ágiles. Así es. Los equipos iteran en ciclos súper cortos de dos semanas, despliegan nuevo código a producción todos los viernes y las prioridades de los directivos cambian todos los lunes por la mañana. Sí, es un caos constante.

19:25

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Entonces, te pregunto, ¿no es exigir este nivel de documentación exhaustiva, con precondiciones, poscondiciones y diagramas inmaculados un regreso a la burocracia paralizante de los años 90? ¿Cómo sobrevive un caso de uso tradicional al ritmo vertiginoso de un sprint? Es la crítica más común y ruidosa desde la trinchera ágil. Y mira, es una objeción 100% justa si el modelado se intenta hacer con una mentalidad rígida y anticuada.

19:52

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Pero las fuentes que analizamos nos ofrecen mecanismos para adaptar el rigor analítico del caso de uso a la velocidad moderna.

20:00

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

La Universidad Carlos III, por ejemplo, aporta un atajo mental brillante que salva a los analistas de hundirse en burocracia infinita.

20:07

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Y es el tratamiento del modelo CRUD. Ah, claro. El famoso acrónimo CRUD en bases de datos. Create, Read, Update, Delete. O en español, crear, leer, actualizar y borrar. Es el pan de cada día de cualquier interacción con un sistema. Y precisamente por ser tan ubicuo y repetitivo, es donde los analistas junior pierden la mayor parte de su tiempo valioso. Si aplicas la teoría pura de casos de uso rígidamente a...

20:36

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

digamos, un sistema de catálogo de productos de una tienda, podrías terminar sin darte cuenta creando un documento exhaustivo gigante para añadir producto, otro enorme para ver detalle de producto, otro para modificar precio y otro más para eliminar producto. Claro, generas cuatro documentos pesarísimos para una funcionalidad súper trivial que cualquier programador hace en una tarde.

21:00

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Te entierras en papel antes de escribir la primera línea de código real. Exacto. Por eso la Carlos III aconseja un pragmatismo radical. Recomiendan colapsar esas cuatro operaciones estándar en un solo caso de uso generalizado, que habitualmente se etiqueta como gestionar entre paréntesis. OK. En este ejemplo sería gestionar catálogo. Documentas el acceso general, las reglas amplias de validación y en los flujos internos agrupas rápidamente las acciones de lectura y escritura.

21:29

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Esto reduce drásticamente la carga documental a una cuarta parte, sin perder el control de la lógica de negocio subyacente. Ese nivel de pragmatismo conecta directamente con algo que me llamó muchísimo la atención en la fuente de Wrike. ¿Por qué? A ver, Wrike no es una plataforma de desarrollo de software per se. Es un software de gestión de proyectos y tareas. Correcto. Y su enfoque revela que un caso de uso trasciende las fronteras del equipo de programadores en el sótano.

21:58

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Para un líder de proyectos, para un project manager, el caso de uso es, en esencia, un contrato de expectativas, ¿no? Es un contrato de alcance, sin duda alguna. Un buen PM, un gestor experimentado, utiliza los casos de uso para establecer fronteras clarísimas con las partes interesadas del negocio.

22:16

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Los inversores o los directores de marketing no van a leer el esquema de la base de datos, obviamente, pero sí pueden leer un escenario en español plano que dice, el usuario busca un hotel, el sistema muestra opciones, el usuario reserva. Es lenguaje común. Y es el escudo perfecto contra el temido Scope Grip, esta expansión fantasma y descontrolada del proyecto.

22:38

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Porque imagínate que a mitad del desarrollo de la app de hoteles, el cliente exige en una reunión que la aplicación también permita reservar vuelos de avión. Típico. Pasa todos los días. El PME saca los diagramas de casos de uso firmados y aprobados y demuestra visualmente sobre la mesa que el actor secundario Aerolínea y el caso de uso Buscar Vuelo sencillamente no existen en el modelo acordado.

23:06

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Se puede añadir por supuesto que sí, pero implica renegociar tiempo de entrega y presupuesto, porque altera la arquitectura base. Es una herramienta de negociación invaluable. Además, Rake enfatiza cómo estos documentos textuales no se tiran a la basura una vez programados, sino que se reciclan al final del ciclo de vida del software para convertirse en casos de prueba. ¡Ah, qué inteligente!

23:29

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

El equipo de control de calidad toma esos cursos alternativos que diseñaste con tanto sudor como diseñario del pin incorrecto e intenta romper el sistema a propósito, introduciendo pines malos para verificar si el código realmente responde como el documento original prometió que lo haría.

23:45

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

han tenido que evolucionar muchísimo. Atrás quedaron los días grises donde necesitabas licencias carísimas de software corporativo, súper pesado, instalado en una máquina específica de la oficina, solo para dibujar un diagrama UML. Afortunadamente, esos días ya pasaron. Ese es un punto crucial que tocamos en la investigación al analizar plataformas como Visual Paradigm Online.

24:09

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Y ojo, la revelación aquí no es simplemente que exista un editor donde puedas arrastrar Stickman en una pestaña del navegador web. Lo verdaderamente transformador para los equipos modernos es la enorme fricción que elimina del proceso. Claro, la barrera de entrada. En el pasado, si un requerimiento de negocio cambiaba a mitad de semana, al desarrollador le daba una pereza tremenda abrir el software pesado de diseño, esperar a que cargue, para actualizar un par de flechas en el diagrama. Así que nadie lo hacía.

24:36

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Así que el código cambiaba en el servidor y la documentación quedaba obsoleta en el día 2 del proyecto. Todo ese esfuerzo previo se volvía arqueología inútil. La verdadera ventaja entonces de estas plataformas en la nube con editores drag and drop es la democratización total del modelo visual. Si el arquitecto de software está sentado en Bogotá y el Product Manager está en Madrid, pueden coeditar el diagrama.

25:00

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

de casos de uso simultáneamente en la misma pantalla. Exacto. Permite que esa discusión intensa sobre si una función es un include o un extend suceda de forma visual, en tiempo real, manteniendo el diseño como un ente vivo que evoluciona a la par del código y no como un PDF muerto guardado en una carpeta compartida que nadie lee.

25:24

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

Es pasar de la documentación estática a la colaboración dinámica Entonces, ¿qué significa todo esto que hemos estado hablando?

25:31

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Hemos desempacado una cantidad masiva de conocimiento y perspectivas el día de hoy. Vimos como una crisis de complejidad en los sistemas masivos de telecomunicaciones de Ericsson obligó al buen Ivar Jacobson a voltear la cámara, por así decirlo, y mirar los sistemas de software desde la perspectiva externa de sus actores. Un cambio de paradigma total. Descubrimos también que...

25:55

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Contrario a ese mito popular en los foros, las historias de usuario ágiles no reemplazan a los casos de uso.

26:04

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Las primeras definen el valor del negocio, mientras que los segundos trazan el terreno arquitectónico completo, incluyendo esos temidos flujos alternativos donde los proyectos realmente fracasan en producción. Así es. Aprendimos a limpiar nuestros diagramas evitando los horribles casos de abuso visuales y utilizando las inclusiones y extensiones solo cuando el objetivo genuino es reutilizar el esfuerzo de programación.

26:32

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Y finalmente vimos que, a través de atajos inteligentes como la agrupación CRUD y el uso de herramientas colaborativas modernas en la nube, esta disciplina no es un ancla burocrática del pasado, sino un escudo dinámico que protege el alcance y la salud mental del proyecto.

26:51

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

La síntesis perfecta de un proceso que sí, exige disciplina al principio, pero que paga dividendos incalculables a largo plazo al evitar la tragedia de construir perfectamente la aplicación equivocada. Y bueno, habiendo analizado tan a fondo esta obsesión arquitectónica por prever cada excepción, cada mínimo fallo de red y cada entrada inválida del usuario, fíjate que esto plantea una pregunta importante.

27:17

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

A ver, ¿te escucho? Si consideramos que la estricta metodología de los casos de uso es el estándar de oro en la industria para diseñar interacciones sólidas, anticipando exactamente qué haremos cuando el escenario ideal de la vida colapsa.

27:30

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

¿qué pasaría si aplicáramos este mismo nivel de rigor analítico a nuestra propia vida personal? Mmm, qué interesante. Imagínatelo. Si diseñáramos un caso de uso estricto de nuestras interacciones humanas más complejas, o incluso algo tan simple como nuestra rutina diaria de las mañanas, ¿cuáles descubriríamos que son nuestras propias precondiciones invisibles? Esas cosas que asumimos ingenuamente que siempre estarán ahí, hasta que un día fallan y no podemos arrancar. El Internet.

28:00

S… Speaker 1 (Casos_de_Uso_contra_el_software_equivocado)

El café, el despertador. Exacto. Y aún más desafiante. Cuando nuestros planes originales se descarrillan inevitablemente y salimos de nuestro propio Happy Path personal, ¿tenemos realmente definidos y pensados nuestros cursos alternativos? ¿O simplemente dejamos que nuestro sistema interno colapse por completo ante el primer error? Un enfoque diferente y, creo yo, provocativo para reflexionar mientras damos por terminada esta exploración profunda de hoy y volvemos a intentar compilar nuestro propio día a día.

28:28

S… Speaker 2 (Casos_de_Uso_contra_el_software_equivocado)

Me encanta esa idea. A diseñar nuestros propios flujos alternativos entonces. Gracias por acompañarnos en esta sesión y seguiremos desempacando el mundo de la tecnología en nuestra próxima exploración profunda.

Casos_de_Uso_contra_el_software_equivocado

Përmbledhja

Pyet AI rreth kësaj transkripte