Hasta no hace demasiado, pensaba que los documentos de textos eran una herramienta bastante válida para la creación y consulta de análisis funcionales basados en casos de uso. Eso sí, trabajando en aplicaciones de tamaño medio o incluso en servicios/módulos con funcionalidades muy específicas para aplicaciones grandes.
Actualmente estoy trabajando en un proyecto grande, y por ello se dividen los análisis funcionales en diferentes documentos de texto. Hasta ahí no tendría por qué haber ningún problema, ya que están divididos por subsistema para no tener un macro-documento funcional. Pero en este caso no es así, por que en muchos de los diferentes subsistemas, se encuentran repetidos casos de uso.
Esto es, que encuentras copy/paste de la descripción de un mismo caso de uso en diferentes documentos, y ésto en mi opinión nos lleva a dos grandes problemas:
- Problemas del mantenimiento del caso de uso para el analista, que debe controlar en qué documentos se repite para no perder coherencia.
- Desconocimento por parte del desarrollador de si es o no exáctamente el mismo caso de uso, debe comparar varios documentos, y aquí podemos heredar el problema de si están correctamente actualizados los documentos o no, lo que conlleva a péridas de tiempo y a posibles errores funcionales o duplicación de código.
Por otro lado, un compañero me ha prestado el libro UML Distilled(en mi caso la second edition) de Martin Fowler, muy recomendable por lo que he leído hasta el momento, sobre todo para los que no tenemos demasiados conocimentos sobre UML, y que además toca otros temas interesantes sobre desarrollo de software, aunque de forma superficial, como Extreme programming, diseño por contrato… En éste libro, encontramos en el tercer capítulo el tema de los casos de uso, y nos encontramos con que UML soluciona éste problema, forma similar a cómo lo haríamos programando, con los includes.
Un include es un tipo de relación de casos de uso (las otras relaciones serían generalization y extend), que como hemos comentado sería algo así a como lo haríamos programando, entonces llegamos a la conclusión que sí, se podría hacer en un documento de texto por ejemplo de ésta forma:”CU X ir a documento Y CU Z“, que claro sigue teniendo el problema de mantenimiento del documento, puede cambiar el nombre del documento, el nombre del caso de uso…
Todo ésto me lleva a hacerme un par de preguntas, ¿existen herramientas para la gestión correcta de casos de uso? ¿open source 
?
December 3rd, 2007 at 12:20
Busqué un poco (no demasiado la verdad) para gestionar un poco los del TFC pero no encontré ninguno. Encontré plantillas.
Alguno tiene que haber sino ya sabes que toca xD, puede ser una herramienta bastante útil.
December 3rd, 2007 at 12:36
Una lástima que el tiempo sea limitado y no se pueda hacer todo lo que se nos pasa por la cabeza:(, sería muy interesante desarrollar una herramienta de este tipo si no hay ninguna hecha ya, claro.
December 4th, 2007 at 0:29
Aparte de los clásicos (y caros) de la gestión de requisitos (DOORS, Requisite Pro, CaliberRM, etc.) han salido cosas innovadoras para integrar de una forma más adecuada el ciclo de vida de los casos de uso. Algunos se quedan en requisitos, otros integran el prototipado, la parte funcional, el diseño… incluso llegan a entrar en la generación de código. Unos cuantos:
http://www.simunication.com
http://www.stpsoft.co.uk/quew/
http://www.gatherspace.com/
http://www.casecomplete.com/
http://www.irise.com/
http://www.visualusecase.com/
http://www.erequirements.com/
http://www.adalon.net (si te llama FuseBox, la versión Struts está desactualizada desde hace años)
Lamentablemente nada medio aprovechable en código abierto… a ver si alguien se anima
December 4th, 2007 at 15:59
Documentos maestros en MSO/oOO, y creo que todos los sistemas wiki te permiten hacerlo (al menos tanto Wikimedia como Atlassian Confluence lo permiten).
Ámbos sistemas permiten hacer que un documento se “incruste” en otro documento mayor/padre/contenedor/etc…
El problema es hacer que todos los que escriban en el sistema estén al tanto de esta capacidad y sepan usarla correctamente.
July 11th, 2008 at 20:53
Saludos.
Lo cierto es que incluso en sistemas muy grandes el número de casos de uso debe ser pequeño. Digamos que no más de 20, incluso para sistemas ENORMES…
Si tienes más que eso quizás es que no tienes el nivel de abstracción apropiado y te has empantanado en micro-especificar cada aspecto del sistema, algo pesado y no muy productivo.
Por otra parte, si tienes módulos y los quieres reflejar en tus casos de uso lo correcto no es utilizar > para eso, sino utilizar paquetes de casos de uso.
Esto es, la relación > no es para gestionar modelos de casos de uso muy grandes, la característica que debe utilizar para estos modelos grandes son los paquetes de casos de uso.
Y finalmente, en lo que a tener las descripciones repetidas, te recomiendo que generes en forma automática tu documentación a partir del modelador de UML, con lo cual se alivia mucho el trabajo de edición.
July 11th, 2008 at 20:55
oops… el sistema de etiquetas del mensaje me ha ha jugado una broma… cada vez que salen esos menores que en mi mensaje anterior me estaba refiriendo a la relación include, la cual estaba escribiendo como en UML con comillas francesas emuladas con dobles menores-que y mayores-que.
Ah! otra cosa que te queria comentar era que posiblemente mi comentario ha llegado muy tarde cierto?
July 13th, 2008 at 2:45
Hola Iván,
La verdad que sí, llega un poco tarde, ya hace bastante que salí de ese proyecto (y de la empresa no hace tanto
).
Empiezo por aclarar que yo no era el que generaba la documentación, sólo la “sufría”
. La cuestión es que(sin usar UML) ya se hacía precisamente algo que se podría considerar paquetes de caso de uso(por documento), el problema son las “pequeñas” funcionalidades comunes entre paquetes, para lo que veo una buena solución el hacer includes en el caso de usar UML y que sería interesante una herramienta que facilite algo así para hacerlo con análisis funcionales.