Documentación

Toma de Decisiones

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

Se decidió usar Django, ya que existían dos compañeros que conocían bien el framework, los cuales explicaron a los demás miembros del equipo 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, ya que significaba que se debía desarrollar menos, pero también era necesario revisar el código para entenderlo y saber que 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, sino que el primer día el cliente que conocía de agilidad propuso empezar haciendo historias de usuario, y como a nadie del equipo le molestó u objeto 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 semestre.

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 cuanto 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 cuanto se iba a realizar una iteración se solicitó que se decidiera como equipo cuantos puntos de historias se entregarían por iteración. Después de discutirlo, se decidió que serían 5 puntos, ya que era como 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 “setings.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 incializa la base de datos.
• python manage.py runserver: instrucción que ejecuta un servidor de desarrollo el que permite visualizar el funcionamiento del sistema.