Documentación

Sobre la fundación

La Fundación Ciudadano Inteligente es una organización sin fines de lucro que promueve el ejercicio responsable e informado de la ciudadanía en Chile y América Latina, por la vía de nuevas tecnologías y el acceso a la información.

Problema de Negocio

Durante las elecciones presidenciales del año 2011 en Argentina, surgió la necesidad de ayudar a la ciudadanía a informarse sobre las posturas de cada candidato a la presidencia, entregando información que les permitiera comparar de manera transversal qué opinaba cada uno en distintos ámbitos que competen a la realidad nacional argentina, para lo cual nació el sitio web Vota Inteligente Argentina.

Este sitio web llamó la atención de muchas organizaciones latinoamericanas, por lo que la fundación se encontró con la necesidad de tener la capacidad de replicar esta herramienta para cualquier proceso eleccionario que se les presentara. Sin embargo, se busca que cualquier usuario sea capaz de usar esta nueva herramienta para transparentar información sobre el proceso eleccionario que desee.

Por esto, el problema busca solucionar tres necesidades fundamentales:

• Transparentar la información eleccionaria e incentivar el voto informado.
• Incorporar a las personas en los procesos eleccionarios como entidades generadoras de conciencia cívica.
• Recopilar información transversal sobre cada candidato en distintos procesos eleccionarios

Solución propuesta

La solución que como equipo se ha propuesto al problema de negocio planteado por el cliente, es crear una máquina creadora de procesos informativos sobre elecciones. En esta solución existen dos tipos de usuario:

1. Creador de procesos informativos o CPI: El usuario que crea los procesos informativos es el encargado de definir que datos tendrá su elección y qué enfoque tendrá la información presentada sobre los candidatos.
2. Visitante: Es el usuario que busca informarse sobre algún proceso eleccionario que esté presente en el sitio. Este puede llegar directamente a un proceso informativo o puede llegar al sitio principal en busca del proceso informativo que más se acomode a sus preferencias.

La herramienta a construir posee 4 fronts ends, el primero orientado al CPI y los otros 3 al usuario visitante:

• Creador de procesos informativos: En este front-end el usuario podrá crear los procesos informativos, agregando candidatos, datos relevantes sobre estos, las áreas sobre las que quiere informar, y las preguntas que le quiere realizar a cada candidato.

• Perfil de candidato: sección del sitio donde el visitante puede averiguar toda la información ingresada en un proceso informativo sobre un candidato en particular.

• Comparar candidatos: se presenta en paralelo la información sobre dos candidatos, de manera de permitirle al usuario comparar la información transversal ingresada en el proceso y que pueda tomar una decisión más informada.

• Media Naranja: el usuario visitante debe contestar una serie de preguntas para encontrar el candidato más afín de acuerdo a la información transparentada en este proceso informativo.

Objetivos de la solución

Se busca que la solución desarrollada cumpla los siguientes objetivos:

Ser de fácil uso, tanto para creadores de procesos informativos, como para visitantes.

En el caso de los primeros, se busca que puedan seguir el flujo del wizard de una manera intuitiva al crear y administrar un proceso eleccionario. Para los segundos, se espera poder facilitar el acceso y mostrar la información de manera clara y precisa.

El lograr este objetivo depende de la usabilidad y, eventualmente, la accesibilidad de la aplicación. Para ello, se realizará un estudio de usabilidad, idealmente con usuarios expertos (consideración de elementos técnicos de diseño de interfaces, bajo la forma de una pauta de evaluación heurística) y finales (observación, ejecución de tareas y cuestionario de satisfacción).

Permitir una fácil difusión, tanto para creadores de procesos informativos, como para visitantes.

Se buscará que la aplicación sea visible y difundible en canales no tradicionales (social media). En el caso de creadores de procesos informativos, se espera que sean capaces de poder transmitir fácilmente la plantilla de elecciones a los distintos candidatos con la finalidad de obtener sus respuestas y poder alimentar el sistema. Igualmente, se espera aumentar la notoriedad del sitio y las distintas aplicaciones en el círculo social de los distintos visitantes, con la finalidad de aumentar el alcance y la tasa de tráfico en el sitio por proceso eleccionario.

El lograr esto depende de introducir, por un lado, mecanismos que faciliten a los creadores de procesos el enviar y recopilar información por parte de los candidatos. En el caso de los visitantes, el acento deberá estar puesto en establecer técnicas de motivación para que respondan y utilicen el sitio con la finalidad de obtener información, así como actuar como "evangelizadores" del proceso eleccionario en cuestión dentro de sus círculos sociales y de interés, según sea el caso.

Permitir que la aplicación sea fácilmente extensible.

Se buscará que el producto final sea extensible, no solo en incorporar una abstracción genérica de procesos eleccionarios (como por ejemplo, ser capaz de soportar en un futuro listas de candidatos o elecciones con candidato anónimo - plebiscitos), sino también en la internacionalización de la aplicación.

Para lograr esto, se desarrollará en torno a tests unitarios, de funcionalidad y de comportamiento. Además, a nivel técnico, se debe definir una estrategia de documentación y estandarización de código a la par con el cliente, con la finalidad de que el producto sea en efecto mantenible por futuros equipos de trabajo.

Riesgos del proyecto

• Que nos ganen el quién vive: Hace referencia a que el sitio no logre alcanzar una masa crítica suficiente para tener un impacto importante en el ecosistema en el cual subsiste, debido a que ha perdido la ventaja competitiva de ser el primer entrate. Para aminorar este riesgo, se busca salir a producción (es decir, en ambiente de producción con usuarios ya activos) lo antes posible. Es necesario enfocarse en terminar las interfaces, hacer pruebas de usabilidad y de estabilidad del sistema para que pueda estar en producción para la entrega de la segunda iteración.

• Duplicidad e invalidez de los datos: Hace referencia a la existencia de datos duplicados (usuarios y procesos informativos) y además, que estos datos no sean válidos a futuro. Para aminorar este riesgo, se busca dar la flexibilidad suficiente al sistema para agregarle una API de acceso a los datos, y de ser necesario, un sistema de autenticación centralizado de la fundación.

• Datos falsos o difamación de entidades: Hace referencia al abuso del sistema por parte de CPI maliciosos que solo busquen difamar candidatos o corromper de alguna manera los procesos eleccionarios. Para esto, se le dará la opción al usuario visitante de denunciar una elección que considere ofensiva.

Toma de Decisiones

1) ¿Por qué 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.