DecidePartZumetaPostProcesado Documento del proyecto - moicalcob/decide-part-zumeta GitHub Wiki

Decide-Part-Zumeta-PostProcesado

Grupo 3
ID de opera: el número asignado al proyecto (el de la URL)
Curso escolar: 2020/2021
Asignatura: Evolución y gestión de la configuración
Milestone en el que se entrega la documentación: M3/M4

Miembros del grupo:

Enlaces de interés:

Resumen ejecutivo

Nuestro módulo es el de postprocesado, forma parte del proyecto Decide Zumeta. La función del postprocesado es asignar los escaños pertenecientes a cada partido dependiendo del número de votos. Para esta asignación se han diseñado dos algoritmos, uno basado en la Ley D´hont y otro en la Ley Simple. Además, se ha añadido la opción de paridad, con el fin de que la asignación esté equilibrada entre hombres y mujeres.

El algoritmo basado en la Ley D´hont divide a través de distintos divisores los totales de los votos obtenidos por los distintos partidos, produciéndose secuencias de cocientes decrecientes para cada partido y asignándose los escaños a los promedios más altos.

El algoritmo basado en la Ley Simple divide entre un mismo divisor los votos de los diferentes partidos, haciendo un reparto proporcional. No es posible conseguir la proporcionalidad exacta, ya que no es viable asignar un número decimal de escaños. Este problema lo hemos solucionado asignando el resto de escaños a la mayor parte decimal restante de forma decreciente.

En resumen, al módulo de postprocesado le llegan dos datos: el número de votos por partido y el número total de escaños para la asignación, junto con el algoritmo a utilizar, nombrados anteriormente.

Por último para cerrar este apartado es que se procede a exponer el número de horas invertidas por el equipo de trabajo en cuanto al desarrollo de los incrementos realizados sobre el proyecto decide. Este número de horas total invertido por el todo el equipo ha estado entre las 50 y las 60 horas invertidas.

INDICADORES

Miembros del equipo	Commits	Test	Incremento
Chaghir Chikhaoui, Amine	22	6	Ley de Paridad y Ley D'Hondt con paridad
Cordón Arévalo, Alberto	15	8	Ley Simple y Ley Simple con Paridad
Corredera Lavado, Antonio	19	11	Método de Ganador Único, Método Ganador Único con Paridad
Ruiz Alba, José	13	8	Método Comprobar, Porcentaje Género e integración con Ley Simple Paridad
Pérez Capitán, Sergio	13	8	Sainte Lague Modificado, Sainte Lague Paridad
Frías Balbuena, Alvaro	12	5	Ley D'Hondt y Ley D'Hondt con paridad

Descripción del sistema

El sistema decide, sobre el cual se trabaja en este proyecto es un sistema de voto que implementa un sistema básico para llevar a cabo votaciones electrónicas de una manera más barata y más accesible para todo tipo de personas que vayan a realizar cualquier votación, ya sean personas con discapacidad, movilidad reducida o simplemente personas que quieran acceder a una votación de manera telemática en estos tiempos de pandemia.

EL sistema Decide se compone de distintos módulos independientes que están conectados mediante API requests. Dichos módulos son:

Base
Autentificación
Censo
Votación
Cabina
Mixnet
PostProcesado
Visualizer (Módulo encargado de la visualización de datos)

Nuestro equipo de trabajo se centra en el módulo de postprocesado de datos, por lo que nos centraremos en hablar de este módulo más detalladamente. Pero también dedicaremos unas líneas a describir ligeramente todos los demás módulos para entender mejor cómo funciona todo el conjunto del sistema Decide.

Comenzaremos hablando del módulo base que simplemente actúa como una librería Python, de tal manera que aporta funcionalidades generales y comunes para el resto del sistema.

El módulo de autenticación es el que permite a cada votante mediante un sistema de logueo mediante usuario contraseña ingresar en el sistema de manera que pueda responder a las preguntas de las votaciones, aumentando así la seguridad del sistema Decide.

El módulo de Censo es el módulo que se encarga de registrar la lista de los votantes que están autorizados a realizar las votaciones. De manera que si un votante y una votación no están relacionadas en el censo este usuario no tendrá los privilegios necesarios para poder votar en dicha votación. Además almacena aquellos usuarios que ya han votado evitando así la problemática que surgiría si un votante tuviera la capacidad de votar varias veces en la misma votación favoreciendo sus intereses.

Por otro lado tenemos el módulo de Cabina que se encarga de presentar una interfaz de usuario en la que el votante pueda elegir su respuesta a una votación.

El módulo de votación se encarga de procesar la información que el usuario ha introducido en el módulo de cabina, para posteriormente, enviarla al módulo de mixnet donde se lleva a cabo el cifrado de todos los datos y se envía al módulo de postprocesado. El módulo de visualización es un frontend en el que se muestran los resultados finales de la votación.

Ahora nos centraremos en el módulo de postprocesado. Como se ha mencionado anteriormente, este módulo está conectado con el módulo de votación , del que recibe los datos, y a quién envía los datos una vez han sido tratados. Los datos se presentan al módulo de postprocesado en un formato de tipo JSON, compuesto por las claves option que corresponde a las diferentes respuestas a una pregunta, ‘number’ que se corresponde con el número de esa respuesta dentro de la question y ‘votes’ que se corresponde con el número de votos que ha recibido cada pregunta., además se recibe dentro del JSON todos los candidatos que se hayan registrado para dicha votación en caso de ser necesario, aunque no se trata de un parámetro obligatorio. A estos candidatos se les debe repartir una serie de escaños que vendrán también introducidos en el JSON que se envía desde el módulo de votaciones. De cada candidato llega al postprocesado como atributos su id para identificarlo, su sexo para saber si es hombre o mujer (algo necesario para aplicar la paridad) y su edad.

Tras recibir los datos estos son procesados para realizar el reparto de escaños o asientos a cada option que se recibe como respuesta de la votación. Los métodos que se utilizan para procesar los datos son la Ley D’hondt, la Ley de Sainte Lague, la ley de mayoría simple o la ley del ganador único. Todas estas leyes se hacen valer del option recibido desde el módulo de votaciones y cada una de ellas le añade en la salida tras realizar todo el proceso un campo postproc que tendría el número de escaños en caso de la ley de mayoría simple, la ley del ganador único o en las leyes de D’hondt y Sainte Lage. En caso de querer aplicar el reparto aplicando paridad se le añade al JSON un campo paridad donde se almacenan los candidatos que han sido seleccionados de manera que se cumpla lo máximo posible la igualdad entre candidatos del sexo masculino y femenino, es decir, que se acerque lo máximo posible a un 50-50.

Por lo tanto las posibles salidas del módulo de postprocesado serán un JSON con la option más el campo postproc o un JSON con la option más el campo paridad.

Ya hemos hablado del funcionamiento básico del módulo postproc: recibe los datos en formato JSON, trata esos datos, modifica el fragmento JSON y envía este al módulo de votación. Hablaremos ahora más profundamente de los componentes de este módulo que permiten dicho procesamiento de la información. Como ya explicamos anteriormente, el módulo de postprocesado realiza la asignación de escaños a cada option que llega en el JSON desde el módulo votaciones como respuestas a una votación (pregunta) en función de los votos que reciben estas. Si nos metemos un poco en el contexto de la programación orientada a objetos y el patrón Modelo-Vista-Controlador (Models-Templates-Views en el caso de Django), este es un módulo carente de modelos y vistas (o templates), ya que lo que hace únicamente es procesar datos y reenviarlos. Por tanto, solo está compuesto por controladores (o views). Podemos encontrar una serie de controladores que realizan una función específica dentro del módulo de postprocesado. Cada uno de ellos se encarga de procesar un determinado método de votación, y todos ellos son invocados desde un controlador general (llamado post) que se encarga de procesar todas las requests que se dirijan al módulo de postprocesado. En dicho controlador se comprueba el método de votación asociado al parámetro ‘type’ del JSON, así como el número de escaños disponibles (campo ‘escanios’), y, tras ello, encontramos un grupo de sentencias de control que dependen del tipo de votación. Si el campo ‘type’ tiene el valor SIMPLE, se invocará al controlador “simple”, que ejecuta la asignación de escaños siguiendo la ley de la mayoría simple, y más tarde se devolverá una respuesta HTTP con los datos procesados y modificados (para, posteriormente, ser devueltos al módulo de votación). Si el campo ‘type’ tiene el valor DHONDT, el controlador post actuará del mismo modo que antes, con la diferencia de que en vez de invocar al controlador de la ley de la mayoría simple, invocará al controlador ‘dhondt’ de la ley de D’Hondt.

Hasta ahora hemos hablado de tres controladores: post(), simple() y dhondt(). Debemos hablar también de otros métodos auxiliares que son necesarios para el correcto funcionamiento del módulo. El primero de ellos es el método comprobar(), este método se encarga de realizar una comprobación de que los datos de entrada son compatibles con la ley de la paridad, y que existe una relación 40-60 como máximo entre el total de hombres y el total de mujeres. El siguiente método es el método paridad(), que se encarga de hacer una asignación de escaños a los candidatos de las options siguiendo ley de la paridad. Es decir, reparte los escaños entre los candidatos según su orden en la lista y alternando entre hombres y mujeres. En este caso como se está aplicando la ley de paridad, el método comprobar(), se asegura de que los datos de entrada son compatibles con dicha ley de asignación de escaños. En caso de que comprobar() devuelva True, se procederá a ejecutar el método paridad sin problema. Si el método comprobar() fallase, se devolvería el siguiente mensaje de error: 'la diferencia del número de hombres y mujeres es de más de un 60% - 40%'.

Cambios que se han realizado para el incremento de este proyecto:

Aplicar paridad sobre el reparto de escaños de cada una de las opciones.
Aplicar la Ley D’Hondt.
Aplicar la Ley de Sainte Lage.
Aplicar la ley de la mayoría simple.
Aplicar la ley del ganador único.
Además se desarrolla una comprobación del porcentaje de hombres y mujeres en el caso de querer aplicar paridad para que solo se lleve a cabo esta si el porcentanje de candidatos en funcion del sexo no difiere en mas de un 60-40.

Visión global del proceso de desarrollo

Para explicar la idea de como es nuestro proceso de desarrollo vamos a poner como ejemplo como se ha desarrollado el incremento funcional de la votación con la ley d'hondt. Esta funcionalidad consiste en que la asignación de escaños de las distintas votaciones se hagan por medio de la ley d'hondt, para consultar más sobre ella acceder aquí: d'hondt

Para el proceso de desarrollo hemos utilizado Github para definir las tareas que ha realizar y asignarlas a los distintos miembros del equipo. Definir las tareas y asignarlas a los miembros del equipo es lo primero que se hace, poniendose de acuerdo entre los miembros del equipo a la hora de asignarselas. En la implementación de la ley d'hondt definimos las tareas en GitHub, en la sección Projects en el proyecto creado para el grupo de postprocesado:

Aplicar la ley d'Hont.
Test D'Hondt

Ademas habría mas tareas dedicadas a esta implementación, pero esta sería la más importante. Las otras tareas son correcciones de bugs, e integraciones con los otros algoritmos.

Una vez hecho esto hay que realizar la tarea. Para ello hemos usado el editor Visual Studio Code y todas las herramientas descritas en el apartado entorno de desarrollo. Para la completa realización de la tarea se tendrá que implementar tanto la funcionalidad del algoritmo como los test correspondientes. Tanto lo uno como lo otro sera realizado por el mismo miembro del equipo al que se le asignó la tarea, por lo que no hay ninguna dependencia de que un miembro del equipo deba esperar a que el otro termine. Será ademas este miembro del equipo el que crea la nueva rama de trabajo task/d'Hont. Cabe destacar que si más adelante surgen problemas relacionados con esta funcionalidad pueden resolverse en esta rama o en la principal, y el que lleve a cabo la resolución podría ser otro miembro del equipo que no tuviera relación previa con esta funcionalidad.

Cuando uno de los miembros ha terminado una jornada de trabajo hace un commit a su rama de trabajo, en este caso decide-part-zumeta-postproc-feature-D'Hondt. Este commit se realiza siempre que no se causen problemas a otros miembros del equipo, como por ejemplo que con el código nuevo dejen de funcionar otras funcionalidades o que no se pueda ejecutar el proyecto, o situaciones parecidas. Esta acumulación de commits será lo que produzca el desarrollo final de la tarea.

Una vez están realizadas las tareas se cierran las issues y se mueven en a la columna de 'hecho'. Después, se realiza merge lo desarrollado a la rama decide-part-zumeta-postproc, solucionando los conflictos. Por último se hace la integración con otras funcionalidades si fuera necesario.

En el caso expuesto era necesario integrar el algoritmo d'hondt con la ley de paridad. Para llevar a cabo la integración se mergeo la rama donde se realizó paridad, task/feature-paridad, en la rama base de nuestro grupo, decide-part-zumeta-postproc, y después, se crea la rama task/DHondtParidad, especifica para realizar todos los cambios necesarios para la integración. Una vez finalizados los cambios se realiza merge a la rama base de nuevo.

Una vez hecho esto ya tenemos completado el nuevo incremento funcional de la ley d'hondt.

Entorno de desarrollo

Herramientas utilizadas

VirtualBox Visual Studio Code

Descripción del entorno de desarrollo

Para el entorno de desarrollo algunos miembros de nuestro equipo han utilizado maquinas virtuales con la última versión de Ubuntu 20.04.1 LTS gracias a la herramienta de VirtualBox en su versión 6.1.16., y otros han utilizado una partición directa de Ubuntu. Dentro de estas máquinas virtuales nos encontramos con que tenemos creado un entorno virtual en Python, concretamente la versión 3.6, en los cuales tenemos de manera aislada instalados todos los componentes necesarios para ejecutar el proyecto de decide. Y como IDE hemos utilizado Visual Studio Code, ya que nos ofrece muchas extensiones para python.

Una vez tenemos este sistema funcionando tenemos que instalar los distintos componentes de decide para poder ejecutarlo y probarlo. La lista de los componentes a instalar están en el archivo requeriments.txt, que se encuentra en la carpeta raíz de nuestro proyecto. En este documento aparecen los siguientes componentes:

Django==2.0
pycryptodome==3.6.6
djangorestframework==3.7.7
django-cors-headers==2.1.0
requests==2.18.4
django-filter==1.1.0
psycopg2-binary==2.8.4
django-rest-swagger==2.2.0
coverage==4.5.2
django-nose==1.4.6
jsonnet==0.12.1

Para instalar los componentes tenemos que crear un entorno virtual de python y activarlo. Para ello tendremos que ejecutar el comando: python3 -m venv nombre_entorno

Tras ejecutar el comando tendremos que dirigirnos al directorio raíz de nuestro proyecto y ejecutar el comando pip3 install requeriments.txt

Una vez ejecutado se nos instalarán todos los componentes, aún es necesario instalar postgresSQL y crear el super usuario "decide" junto con la base de datos "decide". Para ello solo tenemos que seguir los pasos descritos en el siguiente enlace: instalación de postgresSQL Luego creamos el superusuario y la base de datos:

sudo su - postgres

psql -c "create user decide with password 'decide'"

psql -c "create database decide owner decide"

psql -c "ALTER USER decide CREATEDB"

Una vez ejecutado los comandos nos desplazamos al directorio "/decide", y ejecutamos los siguientes comandos:

python3 ./manage.py migrate

python3 ./manage.py createsuperuser

Cuando ejecutamos este último comando nos pedirá un usuario y contraseña, el usuario será decide y la contraseña será de uso personal. Una vez tenemos esto hecho ya podemos ejecutar el proyecto decide con el siguiente comando:

python3 ./manage.py runserver

o bien correr los test con ./manage.py test

Gestión de la construcción e integración continua

Herramientas utilizadas para la integración y construcción

Travis, su misión es construir y prorbar el código.
Codacy, mide la calidad de código con Travis.
Heroku, despliega en la nube.

Proceso de integración continua.

Comenzando con el commit de un miebro del equipo al proyecto, el cual tiene un archivo '.travis.yml' que se encarga de que Travis realice una build del proyecto, definiendo los servicios, los lenguajes y las versiones de esto. A continuación este archivo instala los requisitos del proyecto y la librería 'Codacy-coverage' ejecutando los módulos del sistema, para posteriormente enviarlo a Codacy. Una vez en Travis, ya marcado como 'passed' el proyecto se despliega en Heroku.

Métricas de calidad de código

Código sin uso: Eliminar dicho código.
Código duplicado: Eliminar completamente el código.
Cobertura del código por tests: Mantener, como mínimo, la cobertura inicial.
Complejidad ciclomática: Intentar que sea el valor inicial.
Errores de indentación: Procurar que no sucedan de nuevo.

Gestión de incidencias

Forma de gestionar incidencias internas

En cuanto a la forma de gestionar las incidencias de nuestro equipo de desarrollo, en el caso de que el problema sea por algún fallo de un miembro, se creará una Issue donde se adjuntará el miembro o los miembros relacionados con ese error. El proceso será el siguiente:

Un miembro del equipo descubre un fallo en la aplicación o al pasar los tests de Travis, dicho fallo es de nuestro propio subsistema. Lo que se debe hacer:
- 1.1 Ir a GitHub, concretamente al repositorio "/decide-part-zumeta".
- 1.2 Crear una Issue de la siguiente forma: el título será "Problema PostProcesado" seguido de un comentario significativo para poder identificarla fácilmente a la hora de buscar en el repositorio.
- 1.3 En la descripción de este se explicará el problema encontrado y el error que muestra. Aparte de una posible solución, si la hubiese.
El miembro o miembros asignados para resolver la Issue serán notificados por el grupo de WhatsApp y discord, y además verán la Issue para obtener más información acerca del problema, en este momento realizará los cambios oportunos para acatar con el problema.
Una vez arreglado, se avisará al resto de miembros del equipo de desarrollo para comprobar si el problema ha sido resuelto.
Por último, si el problema se ha solucionado con éxito, se cerrará la Issue, escribiendo un comentario que describa la solución al problema.

Forma de gestionar incidencias externas

Por otro lado, en nuestro grupo de trabajo hemos decidido, que al tener un mismo repositorio "decide-part-zumeta" podemos crear Issues y adjuntar a los miembros del grupo con los que tenemos conflictos para que así vean el problema entre ambos subsistemas para poder solucionarlos. El proceso sería el siguiente:

Un miembro del equipo descubre un fallo en la aplicación, dicho fallo no es de nuestro subsistema, sino de otro grupo. Lo que tendrá que hacer será:

Ir a GitHub, concretamente al repositorio "/decide-part-zumeta".
- 1.1 Crear una Issue con el siguiente formato: el título será “Problema PostProcesado-Censo” si existiera un problema entre nuestro subsistema y el de censo, seguido de algún comentario significativo.
- 1.2 En la descripción de este se explicará el problema encontrado y el error que muestra. Aparte de una posible solución, si la hubiese.
- 1.3 El equipo asignado será avisado por el grupo de WhatsApp y verá la Issue, en este momento realizará los cambios oportunos para solucionar el problema.
Una vez arreglado, nos notificarán para comprobar si se ha solucionado el error.
Por último, si el problema se ha solucionado con éxito, se cerrará la Issue, escribiendo un comentario que describa la solución al problema.

Propuesta de cambio

La propuesta del cambio que se va a explicar es como realizar la implementación del algoritmo simple. Comenzamos yendo a nuestro repositorio de "/decide-part-zumeta" y cogiendo la URL de este para realizar un git clone en nuestro ordenador donde queramos, ya sea directamente en el escritorio o en alguna carpeta concreta. Lo siguiente que debemos hacer será ajustar los archivos LocalSettings, Dockerfile y cualquier otro archivo en el que haya que poner información más concreta y dependiente de nuestro sistema.

Después nos creamos una rama según el patrón establecido por el equipo, para ello usamos el comando git branch task/simple que creará la rama, para cambiar a esa rama hacemos git checkout task/simple. Una vez en la rama, comenzaremos a trabajar, usando por ejemplo Visual Studio Code para realizar la implementación del algoritmo.

Recordemos que el algoritmo simple trata de dividir entre un mismo divisor los votos de los diferentes partidos, siendo el reparto proporcional equitativo entre todos. En general, no es posible alcanzar la proporcionalidad exacta, ya que no se puede asignar un número decimal de escaños. Para evitar este problema hemos asignando el resto de los escaños a la mayor parte decimal restante de forma decreciente.

Una vez tenemos el algoritmo acabado debemos comprobar que funciona correctamente mediante la realización de unos tests para poder saber realmente si el algoritmo funciona como se espera. Por cada cambio que hagamos debemos usar los comandos git commit y git push para subirlo a nuestra rama y no perder el progreso que hayamos hecho.

Finalmente para comprobar que los tests corroboran que el algoritmo funciona correctamente debemos probarlo usando el comando “python3 ./manage.py test” y si todo va bien se actualiza el repositorio de GitHub con los comandos commit y push. Luego travis también pasará las pruebas automáticamente. Para poder usar Travis tenemos que ponerle la clave, que sacaremos del repositorio, en la aplicación de Codacy.

Una vez hecho todo esto correctamente, podremos usa el comando git merge a nuestra rama con la principal para unirlo con el resto de algoritmos implementados.

Gestión del código fuente

En cuanto a la gestión del código fuente, hay ciertas partes que han sido acordadas por todo el grupo completo, entre los 3 módulos que se van a integrar, como las distintas funcionalidades que se van a incluir y el formato de los commits que es global para todos cuya estructura es la siguiente:

(Tipo de cambio) Un encabezado

Cuerpo del commit

Respecto a la gestión del código fuente a nivel de módulo, hemos optado por crear una rama principal para cada módulo a partir de la rama develop del proyecto completo. Esta rama principal de cada grupo, llamada "decide-part-zumeta-[nombre del módulo]", hará de rama develop para cada uno de los módulos. Con esto evitamos conflictos entre los diferentes grupos desde un inicio, facilitando así las diferentes integraciones. Una vez que cada grupo tiene su rama principal, cada integrante del grupo se crea una rama, llamada según el grupo decida para garantizar su entendimiento, para realizar su incremento asignado. Cada persona trabaja en su rama hasta tener terminada su tarea y, una vez esto pase, esa persona será la encargada de subir los cambios a su rama personal para que los diferentes miembros del grupo revisen que todo se ha realizado correctamente. Con esto evitamos que se suba código que puede no estar bien a la rama principal del módulo y nos aseguramos de que todo lo que se completa se está haciendo sin conflictos, además de que nos será mucho más fácil ver que los test automáticos de Travis se completan con éxito. Una vez que se comprueba de que lo subido cumple lo anterior,un responsable del módulo mergea todo a la rama principal ayudado por los demás integrantes del grupo para asegurar la correcta unificación. Cuando todos los grupos tienen todas sus integraciones realizadas y subidas a su rama principal, se acuerda entre los responsables de cada módulo un día para realizar la subida de cada módulo a la rama principal develop. En cuanto a las herramientas usadas para la subida del código ha variado según la preferencia de cada persona. En nuestro caso se ha usado GitKraken, Eclipse y la propia terminal de Ubuntu.

Gestión de liberaciones, despliegue y entregas

Esto será una guía de qué procesos hay que realizar para tener un correcto despliegue, viéndose el código a modificar y su correspondiente orden. Además veremos que criterio hemos seguido a la hora de hacer las entregas, sobretodo lo referido a su formato. Por último, veremos como se ha organizado el equipo y donde y como ha trabajado cada grupo.

Para asegurarnos de que todos los cambios realizados y mejoras hechas funcionaban hemos utilizado unos test que comprueban los resultados y nos aseguran que todo va como deseamos. Estos test son los recibidos por los entornos virtuales de Python. A la hora de subir cambios estamos utilizando la política denomianda "GitFlow", la cual se basa en nombrar las ramas de los repositorios con unos nombres específicos para tener un control del mismo.

Respecto a la licencia del software usada, hemos utilizado las siguientes versiones: Python 20.4(la enseñada en practicas), Django 2.0, pip 20.0.2 y psicog2 2.8.4. Todas las licencias usadas han sido de uso gratuito.

Para desplegar hemos usado "Heroku" donde todos los cambios relacionados al mismo se han realizado en la propia rama "Master" para así tener todas las modificaciones a mano para todos los grupos.

Modificación de Procfile

% prepara el repositorio para su despliegue. 
release: sh -c 'cd decide && python manage.py migrate'
% especifica el comando para lanzar Decide
web: sh -c 'cd decide && gunicorn decide.wsgi --log-file -'

El archivo settings.py tendrá el siguiente formato

DEBUG = True

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'decide',
        'USER': 'decide',
        'PASSWORD': 'decide',
        'HOST': 'localhost',
        'PORT': 5432,
    }
}

STATIC_ROOT = '/home/decide/static/'
MEDIA_ROOT = '/home/decide/static/media/'
ALLOWED_HOSTS = ['*']

# Modules in use, commented modules that you won't use
MODULES = [
    'authentication',
    'base',
    'booth',
    'census',
    'mixnet',
    'postproc',
    'store',
    'visualizer',
    'voting',
]

BASEURL = 'http://localhost:8000'

APIS = {
    'authentication': 'http://localhost:8000',
    'base': 'http://localhost:8000',
    'booth': 'http://localhost:8000',
    'census': 'http://localhost:8000',
    'mixnet': 'http://localhost:8000',
    'postproc': 'http://localhost:8000',
    'store': 'http://localhost:8000',
    'visualizer': 'http://localhost:8000',
    'voting': 'http://localhost:8000',
}

Ahora procedemos a modificar el archivo requirements.txt

Django==2.0
pycryptodome==3.6.6
djangorestframework==3.7.7
django-cors-headers==2.1.0
requests==2.18.4
django-filter==1.1.0
psycopg2-binary==2.8.4
django-rest-swagger==2.2.0
coverage==4.5.2
django-nose==1.4.6
jsonnet==0.12.1
django-heroku
gunicorn

Tras hacer todo esto debemos ejecutar estos comandos

heroku create "decide-part-zumeta"
heroku git:remote -a "decide-part-zumeta"
git push heroku master
heroku run decide-part-zumeta python decide/manage.py createsuperuser

Respecto a la realización de los procesos de entregas, se ha decidido que el producto final que se entregue se encontrará únicamente en la rama master, a la cual deben todos los grupos mergear sus cambios e integraciones. Todo esto lo realizamos al estar utilizando GitFlow, ya que cada grupo irá realizando sus incrementos en sus respectivas ramas para al final desembocar todas en la anteriormente nombrada Master.

Conclusiones y trabajo futuro

Algunas de las conclusiones que hemos obtenido tras finalizar el proyecto han sido:

Participar en un proyecto de unas dimensiones más grandes de lo que estamos acostumbrados a lo largo de la carrera, hemos usado tecnologías y herramientas nuevas para la mayoría de los integrantes de los diferentes grupos. Lo que más importancia ha tenido en este tipo de proyecto ha sido la organización entre grupos, ya que gestionar a tantas personas toma su tiempo y tiene su dificultad.

Hemos trabajado todos los grupos en un solo repositorio lo que ha ocasionado tanto ventajas como desventajas:

Ventajas

Mayor comodidad a la hora de juntar los diferentes módulos una vez que las integraciones estén terminadas.
Evitamos problemas a la hora de integrarnos al usar un solo repositorio en lugar de Forks.

Desventajas

Una mala organización o un mal mergeo puede ocasionar problemas en el funcionamiento del proyecto y afectar a todos los grupos.

Al trabajar con un software que no conocíamos, hemos tardado mucha cantidad de tiempo en entender todas sus funcionalidades para, una vez entendido en su totalidad cada una de los módulos que contiene este proyecto, poder plantear nuevas funcionalidades dependiendo del módulo elegido para modificar por cada grupo.

Al ir realizando este proyecto nos hemos dado cuenta de la importancia que tiene tener una buena comunicación entre los diferentes grupos implicados dado que es necesario mantener el contacto para saber como va cada grupo, si va teniendo dificultades o conflictos en su integración y para saber que modificaciones combinando nuestros módulos se pueden hacer. Además, al ser tantas personas en el proyecto, todo el sistema de incidencias y bugs se notifican más al rápido ya que somos más personas revisando el mismo sistema siendo esto una gran ventaja.

Mejoras propuestas para trabajos futuros

Implementación de un método que permita elegir entre los diferentes tratamientos de datos que se usa. Esto conllevaría una integración con algún otro módulo encargado de este tipo de acciones necesarias para llevar a cabo esta mejora, como por ejemplo el módulo de Voting.
Implementación de una interfaz en la que podamos ver todos las funcionalidades añadidas al módulo.

Mejoras realizadas

Una vez que todos implementamos nuestra funcionalidad se la presentamos al profesor en la defensa, y, entre todos, vimos una buena mejora al relacionar estas mismas, es decir, un compañero del equipo realizó la funcionalidad de paridad, la cual reparte los candidatos teniendo en cuenta su sexo y cumpliendo siempre que sean al menos un 60% uno y un 40% el otro. Este método lo relacionamos con el resto de métodos haciendo que todos los métodos, una vez realizados, apliquen paridad, teniendo así todas las funciones necesarias en un mismo método.