Documentación

Toma de Decisiones

1) ¿Por que se decidió usar el framework Django, siendo que había un avance previo con CakePHP?

Se decidió usar Django, ya que existían dos miembros del equipo de desarrollo que conocían bien el framework, los cuales explicaron a los demás que este framework poseía cualidades bastante prácticas y que podían agilizar bastante el trabajo. Era difícil aceptar de inmediato esta propuesta, dado que ya existía trabajo avanzado de la aplicación solicitada en el framework CakePHP. Esto tenía sus pro y sus contra, ya que tener trabajo ya realizado era una ventaja. En efecto, esto significaba que se debía desarrollar menos, pero también era necesario revisar el código para entenderlo y saber qué es lo que estaba hecho, lo que quitaba tiempo. No teniendo muy claro que framework utilizar, se decidió hacer que “compitieran”. Para esto se trató de desarrollar lo mismo que existía en CakePHP con Django. Esto se logró en una tarde, lo que terminó convenciendo al equipo de lo “fácil” que resultaba desarrollar en Django.

2) ¿Por qué se decidió utilizar la metodología ágil para abordar el proyecto?

En realidad nunca se decidió como equipo qué metodología utilizar. El primer día, el cliente, quien conocía de agilidad, propuso empezar haciendo historias de usuario. Dado que a nadie del equipo le molestó u objetó la propuesta, se identificaron todas las historias de usuario, dándoles un peso (valores 1, 2, 3, 5 o 8). Estos pesos fueron estimaciones a priori que se le dieron a las historias, para poder de alguna forma poder asignar una cantidad de puntos semanales a implementar. Esta primera actividad, terminó decidiendo la metodología ágil que se ha llevado a cabo durante el desarrollo del proyecto.

3) ¿Por qué se decidio hacer iteraciones semanales?

En la primera reunión con el cliente, luego de hacer las historias de usuario, y darles un “peso”, el cliente solicitó que se determinara como equipo cada cuánto tiempo se podrían realizar iteraciones para ir mostrándole avances. Luego de discutirlo, se estimó que hacer las iteraciones semanalmente era lo más apropiado.

4) ¿Cómo se decidió que se iban a realizar 5 puntos de historias por iteración?

Luego de elegir cada cuánto se iba a realizar una iteración, se solicitó que se decidiera como equipo cuántos puntos de historias se entregarían por iteración. Después de discutirlo, se decidió que serían 5 puntos, ya que correspondía a un promedio entre la historia con más puntos y la que tenía menos.

5) ¿Cómo se decide que historias se harán cada semana?

Todos los martes, que es el día en que se debe terminar cada iteración, el cliente elige según su prioridad las historias de usuario que sumen 5 puntos en total.

Arquitectura del Sistema:

1) Consideraciones generales:

Django es un entorno de desarrollo web, escrito en Python, que permite construir aplicaciones que se ajustan al patrón arquitectónico MVC. Eso sí, según la terminología de este framework, un Template corresponde a lo que en el MVC se conoce como Vista, mientras que las Vistas de Django corresponden al Controlador del patrón en cuestión. Por esto, la comunidad Django suele denominar el patrón utilizado como MTV (Modelo-Template-Vista) en vez de MVC (Modelo-Vista-Controlador).

En consecuencia, cuando en este documento se hable de las Vistas, se estará haciendo referencia al Controlador del sistema y, cuando se hable de los Templates, se estará hablando en realidad de las Vistas.

2) Detalle del código:

El proyecto “candidator” se articula (hasta el momento) en torno a la aplicación “elections” (contenida en el directorio “elections”) donde reside prácticamente toda la lógica que se ha desarollado. La configuración global del proyecto se define esencialmente en los archivos “settings.py” y “urls.py”, de tal forma que en el primero de ellos se especifican cosas como las aplicaciones incluidas en el sistema o el motor de base de datos a utilizar, mientras que en el segundo se especifican las rutas mediante las que se accederá a las distintas Vistas del sistema.

A continuación se entrega una descripción general de los principales archivos pertenecientes al código fuente del proyecto "candidator":

• settings.py: archivo de configuración del proyecto que permite especificar las aplicaciones utilizadas, el motor de base de datos (sqlite en este caso), etc.
• urls.py: archivo de configuración que permite definir las rutas mediante las que se puede acceder a las vistas que engloban todas las funcionalidades del sistema.
• elections/admin.py: contiene los detalles relacionados con la administración de los objetos existentes en la base de datos, en términos de su visualización en el backend proporcionado por Django.
• elections/forms.py: archivo de clases que permite especificar las características de los formularios utilizados en las diferentes vistas.
• elections/models.py: permite especificar el modelo de datos para la aplicación elections, definiendo clases con atributos de diferente tipo según sea necesario.
• elections/urls.py: archivo de ruteo específico para las vistas de la aplicación elections.
• elections/views.py: contiene todas las funciones (encargadas de procesar los request del usuario) que conforman la vista asociada a la aplicación.
• elections/fixtures: archivo que permite definir los datos con que se poblará la base de datos al momento de inicializarla **
• elections/static: directorio donde se almacenan todos los complementos (images, archivos css, fonts, archivos javascript, etc) requeridos por el sistema.
• elections/templates: directorio donde se almacenan los templates que son utilizados en la aplicación elections.
• elections/tests: directorio donde se almacenan los archivos que contienen los tests asociados a cada una de las vistas de la aplicación.

Ejecución del código

Una vez descargado el código fuente desde github, se deben ejecutar las siguientes instrucciones:

• python manage.py syncdb: instrucción que inicializa la base de datos.
• python manage.py runserver [port]: instrucción que ejecuta un servidor de desarrollo (en el puerto 8000 a menos que se especifique otro valor) el que permite visualizar el funcionamiento del sistema ingresando la ruta http://localhost:8000 en algún browser.

Documentación de funcionalidades

Se puede encontrar en http://localhost:8000/admin/doc/ la documentación de las funcionalidades, urls y de gran parte de los tags para utilizar en los templates.