El acuerdo al que llegamos en nuestra super-clase presencial fue: arrancamos varios desarrollos independientes el esqueleto básico, y luego unificamos en un solo desarrollo en un trac común. Para antes de que tengamos la clase quizá seria interesante subirlo a 3 ramas (branches) diferentes del mismo proyecto, asi vemos todos como lo están haciendo los otros, y después unificamos en la forma que mas nos interese.
Bueno pero este post es para presentar una definición de requisitos para la memoria. Eso, dicho asi, con ese peso, no lo voy a poder llevar palante. Así es que lo que voy a hacer es presentar algunas ideas de lo que tendría que ser la aplicación (que quizá son también parte del análisis).
La idea general de la aplicación es que los diferentes trabajadores de iepala, entren periódicamente al sistema y reflejen información sobre las actividades que están desarrollando. Con esto se va elaborando colectivamente la memoria de la organización, que puede ser accesible online (con todos los temas de transparencia que esto conlleva) y que podría tener una salida “por atrás” en forma de documento unificado (para presentar a patronatos y cosas de esas).
Echarle un ojo a la web y os haréis una idea: http://www.memoria.iepala.es
Pongo una especie de modelo de datos simplificado con lo primero que se me ha ocurrido:
La idea central del mismo es que todo se podría resolver con simples (o complejas “etiquetas”, pero la realidad de IEPALA demuestra que gustan de las jerarquías. Entonces en vez de crear una campos para cada tema vamos a categorizar las etiquetas. Por otro lado esas categorías deberían tener 2 características basicas:
- Poder bloquear el editar o añadir etiquetas en una determinada categoría.
- Poder clasificar esas categorías en algo asi como “descriptivas” (serian las que tenemos en la barra de navegación derecha) o “contenidos” (medios de comunicación, organizaciones,… etc)
Lo bueno de dejar este modelo de etiquetas y categorías es que puede crecer conforme se les vaya ocurriendo. Y además refleja una jerarquía que le aporta control a la gente. Finalmente añada una batería de fechar que se pueden asociar con una actividad y el tema de vincular adjuntos (esto es para que empecéis a utilizar plugins). Por supuesto cualquier idea en en el modelo de datos sera bienvenida.
Por otro lado aqui os pongo el diagrama de casos de uso
Rápidamente describo:
- Evidentemente hay dos tipos de usuarios registrados: El editor y el administrador (no hace falta mas complejidad para nuestro sistema).
- El administrador gestiona usuarios y categorías. (NOTA: Y además tiene permisos para modificar cualquier “post”)
- Un editor puede crear, modificar y eliminar sus actividades.
- El visitante vera el sistema como un blog (aunque por defecto las actividades aparecerán en orden de realización de la misma y no de creación en el sistema) y podrá hacer filtrados por las etiquetas (algunas le aparecerán a la izquierda) y búsquedas mas complejas.
Evidentemente un tema clave para esta aplicacion lo tendremos en el tema de la impresion de informes. Pero eso no sera para esta proxima clase.
Vale pues con esto nos juntaremos en otra clase presencial y unificaremos en un solo código.
Salud.
—————-
Como nota final dejar constancia de que lo mas importante aun no lo hemos abordado: ¿Por que estamos migrando esta aplicación? ¿Por que a Rails?.
Entradas (RSS)