Mi idea de una herramienta para gestionar RUP

Empezamos por el modelado de la DB, eso me hizo ver el libro de RUP como si fuera un conjunto de especificaciones, fue mucho más divertido así que leer el libro como material educativo la verdad, y es que a ser sinceros no encontré un libro tipo "RUP para DUMMIES" así que tuve que interpretar varias cosas.

Para empezar la herramienta que estoy diseñando no es un CASE o un MODELADOR, es una herramienta de apoyo a la gestión de un proyecto, osea más pensada en organizar las iteraciones, tareas y artefactos a generar en cada una de ellas, almacenarlos en un repositorio central (PostgreSQL obviamente) y nada más (de momento al menos).

Tengo publicado 4 cosas:

1. El diseño de la db en Mogwai (quizás te guste leer esto primero)
2. El SQL de PostgreSQL para generar las tablas, y algo de data base que fui llenando
3. El diseño en JPG, por si no quieren instalar el Mogwai
4. El diccionario de datos en PDF, aunque el modelo sql incluye todos los comentarios de tablas y campos para que sea más práctico.

Pueden descargar todo esto de AQUI.

Ahora como creo que debe funcionar el software (y de paso explicando el modelo)

a. El software empieza por definir un "proyecto", para ello tenemos la tabla "dat_proyecto", también podemos definir un glosario del proyecto en la tabla "dat_glosario".
b. Al proyecto se le genera un "equipo", el equipo sale de la tabla de usuarios del sistema, tablas "dat_team" y "mae_usuarios" respectivamente, fíjense que el administrador del sistema solo se define en un flag, y básicamente podríamos decir que lo único que hará es crear usuarios nuevos y aperturar un proyecto (no definí perfiles, accesos, etc.), también tenemos una tabla "mae_rol" donde definimos los posibles roles en todos mis proyectos, luego cada miembro del equipo podrá marcarse como uno o más roles gracias a la tabla "dat_team_rol".
c. Luego de crear el proyecto creamos los requerimientos, tabla "dat_requerimientos", básicamente los escribimos, podemos especificar si es Funcional o No Funcional
d. Luego creamos la iteración, tabla "dat_proyecto_iteracion" y especificamos en esa iteración que requerimientos serán atendidos, tabla "dat_requerimientos_rel_dat_proyecto_iteracion", el requerimiento puede ser "C" creado ó "M" modificado en esa iteración.
e. Después de definir la iteración definimos tareas en la tabla "dat_proyecto_iteracion_tareas", estas tareas tienen fecha de cierre, de aviso y responsable a un miembro del equipo (tengo que hace un cambio, debe ser al dat_team y no al mae_usuarios, primer bug ).


Ahora la parte más compleja:

Cada requerimiento es atendido en una o varias iteraciones, pero cada requerimiento generará una serie de artefactos, estos artefactos están definidos en la tabla "mae_tipo_disenio" y pueden ser Casos de Uso, Test, Diagrama de Clases, etc., cada uno de ellos puede tener varios campos customizados, estos campos customizados se definen en la tabla "mae_tipo_disenio_dato". Cuan al requerimiento (en la iteración que esta) se le genera un nuevo artefacto este se almacena en la tabla "art_disenio" y los campos customizados se almacenarán en la tabla "art_disenio_dato", si no se han dado cuenta aún, le programa debe construir la interface para el llenado de los datos dinámicamente, se lee la estructura y orden de presentación de los datos (según el artefacto) en la tabla mae_tipo_disenio_dato.

Un artefacto puede, y seguramente lo hará, generar TAREAS, por ello encontrarán que en la tabla "art_disenio" se marca como si el artefacto genera tareas y en la tabla de "dat_tareas" se puede llenar el ID del artefacto al que pertenece.

Para hacer un poco más compleja la cosa, un artefacto puede generar otro artefacto, es por ello que esa tabla tiene una referencia recursiva, por ejemplo, un CASO de USO genera TESTs y DIAGRAMAs entonces podemos especificar la dependencia entre ellos.

Un artefacto también puede depender de la iteración y no del requerimiento, es decir el artefacto es general, como por ejemplo PLAN de PRUEBAS ó DIAGRAMA de ARQUITECTURA.

Hasta el momento con eso gestionamos los documentos y tareas al menos, ahora toca programarlo, todos los amigos que preguntaron por Twitter sobre mi iniciativa aquí esta, pienso programarla en PHP con P4A pero si desean hacer un fork en Python, Scala o lo que sea pues bienvenido, mi idea en los siguientes días es seguir afinando el diseño de la db, esto lo saqué en 3 días y falta mucho por pulir aún.