Entries Tagged 'Check' ↓

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.

He subido al repositorio el documento de análisis funcional en el que describo los siguientes puntos:

• Finalidad y objetivos
• Usuarios del sistema
• Análisis de requisitos
• Modelo de datos
• Integración de Couchdb y Django

El documento no es muy extenso, ya que el desarrollo no requiere el uso de extensiones de Django que estén fuera de lo normal,  funcionalmente no es complejo (salvo la gestión de listas compartidas) y en el catálogo de requisitos se definen con detalle lo elementos que entran en juego en cada sección de la aplicación, aportando una descripción funcional suficiente como para afrontar el proyecto.

De los puntos mencionados anteriormente, hay uno que no tengo claro , Integración de Couchdb y Django, ya que no se con certeza cómo va a funcionar Django junto a CouchDB y lo que es más importate, nunca he afrontado un proyecto usando CouchDB ni bases de datos no relacionales.

A medida que vaya peleándome con CouchDB iré actualizando el documento con las decisiones que vaya tomando  en lo relacionado al modelo de datos y la integración con Django.

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

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

Atar todos los cabos y delimitar el alcance del proyecto es desde mi punto de vista la primera gran tarea de todo proyecto. Al principio no lo hacia, cuando quería hacer algo me ponía y del tirón intentaba implementar las ideas que tenía en la cabeza y bueno, algunas veces las cosas salían como yo quería y no se me escapaba nada pero la dura realidad es que la mayoría de las veces terminaba haciendo otras cosas y el tiempo de desarrollo se alargaba más de la cuenta.

Esta experiencia la viví muchas veces en mi primer trabajo en la empresa privada y perdimos muchísimo tiempo que al final se convirtió en agobios. Hoy día las cosas han cambiado mucho, ya no comienzo un proyecto sin haber hecho un catálogo de requisitos detallado y a ser posible validado por el usuario final (como en este caso yo soy el cliente no hace falta).

Las ventajas que veo a la hora de hacer el catálogo de requisitos son:

• las idas que uno tiene del proyecto se afinan, incluso se llegan a desechar porque no tienen sentido,
• de este documento se puede sacar una batería de pruebas para realizar el testeo de la aplicación,
• limita el alcance del proyecto evitando idas de coco,
• permite que otras personas vean en pocas páginas tu idea del proyecto,
• y lo más importante, atas todos los cabos sueltos que puedas tener sobre el proyecto y con el cliente.

La tarea ya está en el track así que en unos días estará disponible.

De una lista de checks por fin estamos en el primero de ellos con dos meses de retraso pero con las mismas ganas que cuando se me ocurrió/surgió la necesidad de realizar este proyecto. No se si estará finalizado a tiempo pero lo voy a intentar.

¿De qué va todo esto?

Pués muy fácil,  va de intentar conseguir implementar una pequeña aplicación web en Django que permita gestionar listas, ya sean de tareas, de cosas, de ideas, de notas o de lo que sea. La idea es simple y su implementación también pero lo que no es tan simple es intentar hacer las cosas a la perfección. Mi idea es centrarme en el usuario final y hacerle muy fácil el uso de esta aplicación trabajando mucho la interfaz.

Una vez terminada la aplicación web, comenzará una segunda fase en la que se creará un servicio con el que poder implementar aplicaciones para móviles .