Entries Tagged 'Organización' ↓

El árbol de navegación, es una forma de representar las opciones que el usuario tiene a la hora de navegar por el site/aplicación. Para este caso he optado por un diagrama de árbol hecho con la herramienta XMind

El nodo raiz representa la página de inicio, en la que se dará la opción de iniciar una sesión o registrarse en la aplicación. Por este motivo los hijos del nodo raiz son register y <username>, donde register representa el formulario de registro y <username> la página de inicio del usuario.

En la aplicación sólo los usuarios logados tendrán permisos para crear, editar y modificar las listas y sus elementos y por ello todas las urls caen por debajo del nodo <username>.

Una vez estamos en la página <username> a.k.a página de inicio del usuario logado, este podrá:

• editar su  datos referentes a la cuenta registrada en la aplicación, para ello deberá acceder a la ruta /<username>/edit.
• configurar la compartición de listas con otros usuarios a través de la ruta /<username>/share.
• ver sus listas, borrarlas, crear nuevas  y buscar sobre ellas a través de las rutas  /<username>/lists/add , /<username>/lists ,  /<username>/lists/<list name>/edit y /<username>/lists/<list name>/delete
• ver los elementos de una lista, editarlos, eliminarlos y añadir nuevos a través de las rutas /<username>/lists/<list name> ,  /<username>/lists/<list name>/<item>/edit , /<username>/lists/<list name>/<item>/delete y /<username>/lists/<list name>/add

Hay que tener en cuenta que  este esquema no se recoge los posibles saltos en la navegación, como por ejemplo el ir desde la ruta  /<username>/lists/<list name> a la página de inicio. Estas relaciones se darán en la aplicación pero añadirlas al esquema provocaría un poco de ruido, por este motivo solo pongo la navegación más relevante de cara al usuario y a las acciones que este puede realizar en la aplicación.

Todavía no he cerrado el prototipo del listado de listas (valga la redundancia), pero está la posibilidad que desde esa vista sea desde la que se creen las entradas. Si es así, el usuario no vería que cambia de url en el momento de creación de una lista, por lo que este esquema estaría mal, ¿no?. Pués desde mi punto de vista no lo estaría  ya que  Django necesita de una url para realizar una acción de forma que para poder añadir una lista habría que hacer la petición a través de la url definida en el esquema, pero sin que esta muestre un nuevo contenido HTML.

¿Este proyecto sigue abandonado?…es la pregunta que ha rondado por mi cabeza el tiempo que no he ausente del proyecto. No porque lo fuera a abandonar sino porque la gente que sigue este proyecto lo pensara.

Creo que ha sido un mes, más o menos, lo que he estado sin escribir por aqui, ni publicar nada en la forja. Los motivos han sido varios, desde tener que apagar fuegos (véase apagar fuegos como el tener que resolver tareas contrarreloj en el curro), hasta estar enfermo durante una semana con uno de esos virus que la gente dice “todo el mundo lo tiene ahora”.

En la oficina hemos tenido varios cierres de proyectos simultáneos y hemos tenido que apretar un poco el cinturón para que todo fuera, como solemos decir en la ofi, peeeeerfe XD. A esto se le ha juntado un par de viajes a Ceuta como formador de Drupal, en los que durante 7 días he impartido un curso en el que explicaba un poco de  metodología para el desarrollo de sites en Drupal, así como también desarrollar módulos para Drupal. La experiencia fue muy buena pero también fue agotadora ( no valgo para ir en ferries :S)

Antes de irme a Ceuta, fui a Barcelona unos días  para asistir a la Drupalcamp 2010 y bueno… no pegaba ponerme con Django en mitad de una conferencia.

A pesar de haber estado ausente, avancé un poco en pequeñas tareas como la definición del árbol de navegación y los prototipos de la aplicación. Las tareas están en la forja [1] pero aún no están cerradas, tengo que darles un par de vueltas para estar seguro, sobre todo a los prototipos que no tengo muy claro que sean la mejor solución.

[1] repositorio svn

Si hace hace un par de días me hubieran preguntado por CouchDB o una base de datos orientada a documentos hubiese contestado WTF y me hubiese puesto a mirar en google porque solo he trabajado con las típicas (Postgresql, Mysql y sqlite).

La pasada semana llegó un correo a la lista [Tech] de emergya (empresa en la que trabajo) en el que se mencionaba a CouchDB y entonces entró a formar parte de mi vocabulario aunque sin saber muy bien de que iba el rollo (solo sabía que era una base de datos, por eso del DB :S).

Hoy mi compañero Juanje me comentó que podría usar CouchDB en The Checker porque veia que se le podría sacar partido  y bueno, tras comentarme un poco como iba el rollo y leer una entrada que escribió en el blog de emergya [1]  lo vi super interesante y ya que estoy en la fase de análisis y diseño, he decidido intentar integrar CouchDB en el proyecto.

[1] No todo es ralacional

Ya que tengo una primera versión del catálogo de requisitos he aprovechado para generar los primeros casos de pruebas de la aplicación. Cuando termine con el documento de análisis y diseño saldrán más casos de pruebas y por eso mismo quiero adelantar un poco la tarea. Es un poco aburrido tener que crear tropecientos casos de pruebas en la forja, creo que es mejor ir generandolos a medida que vaya cerrando documentos.

Cuando los casos de pruebas estén generados, los podré relacionar con las tareas de forma que tenga una matriz de trazabilidad y así pueda ver que funcionalidad tengo lista para testear y validar. No tengo muy claro si la forja lo permite sino pués hare una tabla con los datos que iré actualizando.

El track con los casos de pruebas están en [1] por si alguien los quiere ir viendo aunque por el momento solo tengo 7 definidos.

[1] Casos de pruebas

Un poco tarde pero la vesión 1.0 del catálogo de requisitos ya está lista. En este documento se contemplan los requisitos básicos para esta primera fase( hacer una aplicación muy básica para gestionar listas entre usuarios) a nivel funcional.

A partir de este documento podré generar el documento de análisis y diseño así como también los casos de pruebas para que el proyecto se de por finalizado y sin ningún fallo.

En este mismo instante, que escribo este post estoy pensando que podría dejar de escribir documentos y poner me a programar (que es lo que más me mola) pero creo que estos documento pueden servir a que otros desarrolladores que se interesen por el proyecto sepan de que va y cuales son sus objetivos…..así que toca aguantarse y escribir durante una semana más.

En [1] podeis acceder a la forja y ojear el documento.

[1] catálogo de requisitos

Hoy he comenzado a generar el catálogo de requisitos de la aplicación, lo he hecho con dos días de retraso respecto a la planificación. Tendré que ser más negativo a la hora de estimar tiempos y sobre todo cuando hay fines de semana por medio.

El documento, en estos momentos, solo está iniciado pero no quiero que se quede en mi ordenador local (por lo que pueda pasar), por eso y con el fin de que otros desarrolladores puedan ver los documentos, voy a ir subiendo las distintas revisiones del documento a subversion.

He estructurado el subversion del proyecto en dos carpetas:

• doc
• trunk

En doc iré guardando todos los documentos que vaya generando y en trunk irá el código funte de la aplicación.

Dejo en [1] el enlace al subversion de la aplicación

[1] https://forja.rediris.es/plugins/scmsvn/viewcvs.php/?root=cusl4-thecheker