casos Uso vs Historias de Usuario en XP

UML es un lenguaje cuyo proposito es la representación de los requerimiento del sistema en un formato que facilitará este proceso de desarrollo. En mi opinión UML no consigue este objetivo. En ese sentido la aparición de continuas extensiones al lenguaje no hacen si no corroborar que surgio con muchas limitaciones.

Desde un punto de vista técnico UML siempre ha tenido muy buena prensa, y se creo una idea compartida por casi todo el mundo en el que se asociaba profesionalidad en el desarrollo con el uso de herramientas que trabajan con UML (como la serie de Rational Rose). Esta es una práctica muy habitual en nuestro entorno. Continuamente se introducen en nuestro ámbito tecnologías cuya dificultad o complejidad hace de ellas que tengan una muy buena prensa. Con esto no quiero decir que UML sea realmente complejo, pero lo que desde luego no se puede dudar es que es una manera mucho mas sofisticada de extraer requisitos que los tipicos monos o esquemas con los que hemos venido trabajado en desarrollos.

Mi opinión es que debe utilizarse en aquellas situaciones en las que las herramientas de modelado UML pueda ayudarnos en plasmar gráficamente los requisitos. No obstante, no perdería demasiado tiempo en conseguir ser estricto en la sintaxis y no dejaria de lado otro tipo de representaciones, como por ejemplo flujos de pantallas, o esquemas de funcionamiento que puedan reflejar de manera mucho mas sencilla nuestros requisitos.

No debemos perder de vista que el objetivo es conseguir reflejar los requisitos que el cliente nos esta pidiendo, en un lenguaje que si es posible entienda el, para poder desarrollar lo que nos esta pidiendo. Mas que nada porque nuestro cliente no valorará una perfecta representación UML de unos requisitos que no son los que el pidio.

Respondiendo directamente a tu pregunta (si los DIAGRAMAS de casos de uso rebasan la frontera ) mi respuesta es si, yo creo que si rebasan la frontera SI los usas como documentacion. Si los usas para modelar y diseñar tu aplicacion cada vez que te vas a comunicar con otro diseñador, arquitecto o cliente que conoce la terminologia, entonces todo bien. Simplemente estas usando un lenguaje para poder comunicar tus ideas. Recordemos que el UML es un lenguaje de diseño, asi que usemosle para diseñar, no para documentar.

Ahora que si hablamos de los casos de usuario (no los diagramas) contra las historias de usuario (usualmente en targetas tipo CRC) yo creo que favorezco la simplicidad y el poder de las historias de usuario.

Ahora que si el cliente quiere que documentes tu trabajo (clasico RUP) y el y su equipo que dara mantenimiento al sistema conoce el UML bueno, yo creo que eso trae a la luz problemas de aceptacion de la metodologia que estas usando, en este caso XP.

Para comprobar que estas usando XP, y no una version modificada de RUP has la siguiente prueba: en la proxima reunion para planear la siguiente iteracion escoje un caso de uso el cual quedara fuera del contexto de la aplicacion que desarrollas, ahora dale el documento al responsable de negocios y dile: "ok, esta parte quedara fuera, ahora por favor rompa en 2 o mas pedazos el caso de usuario que no se implementara" si el cliente lo agarra, lo rompe y lo tira a la basura entonces felicidades!, estas usando XP; si te dice , " no, este, mejor lo archivamos o a lo mejor lo vamos a usar despues" entonces estan usando RUP y tienes que mejor trabajar en la aceptacion de XP.

Saludos!

Miguel Calix

Los casos de uso son un mecanismo poderoso y simple para le definición de requisitos funcionales, son historias del uso de un sistema que pueden ser utilizados por distintas metodologías. Existen CUs con distintos grados de visibilidad y creo que los de Caja Negra serían compatibles con las de historias de usuario de XP. En ambos casos, ya sea con las historias o los casos de uso lo que estás buscando es capturar los requisitos del sistema. Una cosa más: la escritura de CUs consiste en obtener descripciones textuales del uso del sistema no dibujar diagramas.
Para terminar, UML es una herramienta útil si se adapta de manera correcta al proceso que utilizas para desarrollar. Y los CU, al menos en mi experiencia profesional, son una buena forma de definir lo que realmente necesitan los usuarios.