Documento del proyecto Equipo 3
- Grupo de clase: 2
- Curso: 4º Ingeniería de Software
- Curso escolar: 2021/2022
- Asignatura: Evolución y gestión de la configuración
| Miembro del equipo | Horas | Commits | LoC | Test | Issues | Incremento |
|---|---|---|---|---|---|---|
| García Cáceres María | 74 | 32 | 436 | 5, ubicadas aquí y aquí | 14 | Mostrar datos en tiempo real, pintado de gráficas en visualizer y pruebas de navegación sobre dichos incrementos |
| Gutierrez Ceballos Pablo | - | 1 | 60 | 1 | URL personalizada en votaciones | |
| Parrado Gordón Raúl | 72 | 20 | 1107 | 6, ubicadas aquí y aquí | 10 | Importación de censo y pruebas unitarias y de navegación sobre dichos incrementos |
| Roldán Cadena Jesús | 73 | 15 | 595 | 8, ubicadas aquí y aquí | 15 | Exportación de censo, filtrados de sexo y edad en censo y pruebas unitarias y de navegación sobre dichos incrementos |
| Torres Gómez Lucía | 75 | 21 | 925 | 4 | 8 | Múltiples preguntas en votaciones, tipo de post-procesado en votación y pruebas de navegación sobre la validación de censo, validación de censo |
Equipos con los que se ha integrado y los motivos por lo que lo ha hecho y lugar en el que se ha dado la integración:
-
Sierrezuela-part-1: El grupo sierrezuela-part-1 ha añadido nuevos tipos de postprocesado (5 en total). Nuestro equipo, para ello, ha tenido que realizar cambios en el modelo Voting y Question. Estos cambios en post-procesado han afectado también al módulo de cabina de votación, que ha sido cambiado por el grupo sierrezuela-1. Asimismo, al depender directamente de post-procesado, el módulo visualizer, perteneciente a nuestro grupo, también ha sufrido cambios a la hora de mostrar los resultados de las votaciones.
-
Sierrezuela-part-2: Nuestro grupo ha añadido filtros en el panel de administración de censo que permiten filtrar los censos por sexo o por edad del votante. Para ello, el grupo sierrezuela-part-2 ha tenido que modificar el modelo User, realizando cambios al módulo authentication. Concretamente, el grupo sierrezuela-2 modificó el modelo User para añadirle los atributos sexo, edad, región y dirección ip.
Nuestro equipo egc-sierrezuela-3 parte de la herramienta de votaciones Decide como base. En él, se han desarrollado diferentes incrementos funcionales como parte del proyecto de la asignatura Evolución y Gestión de la Configuración.
Concretamente, nuestro equipo se ha centrado en mejorar los módulos censo, visualización y votación. Estas mejoras se definieron en el M1, y se tomaron las propuestas de mejora tanto de ideas originales como del documento de posibles tareas que ofrece la wiki de la asignatura. Estos incrementos funcionales se detallan en el apartado Incrementos Funcionales de este mismo documento. A continuación, incluimos un resumen de los mismos:
Exportación de censo: La funcionalidad de exportación de censo permite guardar en un archivo csv los censos que el usuario desee. Para acceder a esta funcionalidad es imprescindible que el usuario tenga el rol de administrador.
Importación de censo: Esta funcionalidad permite importar un censo completo dado un archivo csv con el formato indicado.
Validación de creación de censos: La validación de creación de censos se encarga de comprobar si los ids que hacen referencia a la votación y a los usuarios existen en la base de datos. Si ese es el caso, el censo se creará correctamente
Filtro de censos por edad o sexo: Otro incremento funcional que se ha realizado sobre el módulo de censos ha sido la implementación de filtros de edad o sexo. De esta manera, un usuario administrador podrá filtrar los censos por votación (opción original del sistema Decide) por sexo “Hombre”, “Mujer” u “Otro” y por edad “18-30 años”, “31-50 años” y “+50 años”.
Elección de tipo de post-procesado en la pregunta de una votación: Esta funcionalidad consiste añadir un cambio en el modelo de Question dentro del módulo Voting para poder elegir el tipo de postprocesado a aplicar en el recuento de los votos de dicha pregunta.
Soporte para preguntas múltiples en votación (Sin finalizar). Esta funcionalidad permite añadir varias preguntas a una votación. Sin embargo, después de muchas horas de integración con los módulos de cabina y post-procesado, debido a todos los problemas que surgieron se decidió no incluir esta funcionalidad en el repositorio general de los equipos, aunque sí se encuentra en el repositorio del equipo egc-sierrezuela-3.
Enlaces personalizados para votar. Esta funcionalidad permite tener una URL personalizada de acceso a la cabina. No obstante, esta funcionalidad nunca se llegó a integrar con el módulo de cabina debido a que esta fue desarrollada por un compañero que abandonó el proyecto.
Mostrar información en tiempo real en visualización de resultados: Antes de realizar esta implementación, los únicos datos de una votación que se podían conocer eran los resultados obtenidos una vez que esta finalizara. Conocer cuántas personas están censadas en la votación e, incluso, cuantas han votado ya se vuelve algo fácil de conocer.
Pintado de gráficas en visualización: Esta funcionalidad consiste en representar los datos en tiempo real para aquellas votaciones que se encuentran en progreso de una manera mucho más visual.
Para minimizar el número de fallos se han realizado pruebas. Cuando un incremento funcional terminaba de desarrollarse, inmediatamente se realizaban pruebas para comprobar que la aplicación se comportaba de la manera esperada. En concreto, se han realizado pruebas unitarias, para probar pequeñas partes del código, y pruebas de navegación, para probar recorridos complejos por la aplicación. La aplicación, por otro lado, ha sido desplegada en remoto mediante la Plataforma como Servicio Heroku. Además, esta ha sido desplegada también mediante máquinas virtuales gracias a la herramienta Vagrant. Sin embargo, para desarrollar la aplicación, nuestro equipo ha optado por el uso de entornos virtuales de Python mediante virtualenv.
Finalmente, se ha utilizado un servidor de Integración Continua para la ejecución de las pruebas de manera automática, así como el despliegue continuo de la aplicación en Heroku. Para ello, se ha utilizado la herramienta GitHub Actions, en la que hemos definido un workflow que contiene dos jobs y que se ejecuta cuando se realiza un push sobre la rama de integración continua.
GitHub. Se ha usado para obtener los commits y las líneas de código del apartado Insights. Además, las métricas sobre incidencias se han obtenido del apartado Issues.
La integración con otros equipos viene detallada en el apartado Integración con otros equipos de este mismo documento. Nos hemos integrado con 2 equipos, por lo que nuestro proyecto es de tipo Part. Estos equipos tienen desplegados sus proyectos individuales en sus respectivos repositorios egc-sierrezuela-part-1 y egc-sierrezuela-part-2, y la integración se ha realizado en el proyecto general llamado egc-sierrezuela.
El sistema desarrollado se trata de una aplicación derivada de la plataforma de voto electrónico Decide, ubicado en este repositorio
Tal y como se menciona en dicho repositorio, Decide “se trata de un proyecto educativo, pensado para el estudio de sistemas de votación, por lo que prima la simplicidad por encima de la eficiencia cuando sea posible”.
Decide es una aplicación desarrollada en Python mediante el framework Django, siguiendo una estructura arquitectónica muy similar al patrón Modelo-Vista-Controlador (MVC). En el caso de Decide se sigue un patrón basado en Model-Template-View (MTV), en el que los modelos sirven para acceder a la información, las Views almacenan la lógica y tratan la información de los modelos y las Templates se utilizan para mostrar la información al usuario. Los modelos se encuentran en el archivo models.py, las views en el archivo views.py y las templates en la carpeta templates.
Tal y como se ha mencionado anteriormente, la aplicación ha sido desarrollada mediante el framework de Django. El flujo de ejecución de las aplicaciones que hacen uso de este framework suele ser el siguiente:
- El usuario realiza una petición HTTP a través de una url ubicada en el archivo urls.py
- Esta url está asociada a una vista (view), la cual se encarga de procesar la petición. Para ello, utiliza el modelo para leer/escribir datos y después produce una respuesta HTTP, enviando los datos pertinentes a una template (view).
- La plantilla recibe los datos de la vista y muestra el resultado producido por la vista.
El sistema Decide se divide en varios módulos, tal y como define Wadobo en este documento:
-
Autenticación. Módulo que permite iniciar sesión a los votantes a la hora de votar.
-
Censo. Módulo que registra las personas que pueden votar en una votación.
-
Votaciones. Este módulo se encarga de crear las votaciones y sus características.
-
Cabina de votación. La cabina de votación muestra la interfaz para votar.
-
Almacenamiento de votos cifrados. El almacenamiento de votos se encarga de guardar los votos cifrados en una base de datos.
-
Recuento / MixNet. El módulo de MixNet también está bastante relacionado con el cifrado de votos. Tal y como menciona Wadobo, una mixnet es “una red de ordenadores que generarán una clave compartida para cifrar los votos”. Por tanto, un voto será descifrado para recuento cuando todos los componentes de la mixnet se pongan de acuerdo.
-
Post-procesado. El post-procesado recoge los valores calculados por el módulo de recuento y los transforma en un resultado.
-
Visualizaciones de resultados. Por último, el módulo de visualización se encarga de representar los resultados del post-procesado.
A continuación se resume brevemente las relaciones entre los distintos módulos:
-
El eje central del sistema decide es el módulo de votaciones. Todos los módulos dependen de él en algún aspecto.
-
El módulo de autenticación está relacionado con cabina y censo, los cuales también están estrechamente relacionados con el módulo de votación. Se debe comprobar que la persona que va a votar mediante la cabina ha iniciado sesión en la aplicación y que, además, se encuentra censada en la votación correspondiente.
-
El módulo de cabina, a su vez, depende del módulo de almacenamiento. El almacenamiento, como se ha explicado previamente, guarda el resultado votado en la cabina de votación de manera cifrada. El módulo MixNet recoge los votos del almacenamiento y los descifra de manera que no se sepa las opciones que han votado las personas.
-
Por último, el post-procesado recoge los recuentos realizados sobre la votación pertinente y utiliza un método determinado para producir el resultado final. Gracias al post-procesado, el módulo de visualizer muestra los resultados de la votación de alguna manera (gráfica, tablas, estadísticas…).
El equipo egc-sierrezuela-3 se ha encargado de realizar incrementos funcionales sobre los módulos de censo, votación y visualización, tal y como se detalla en el siguiente apartado.
La funcionalidad de exportación de censo permite guardar en un archivo csv los censos que el usuario desee. Para acceder a esta funcionalidad es imprescindible que el usuario tenga el rol de administrador.
Esta función se encuentra accesible en /admin/census/census. Una vez que el usuario administrador accede ahí, para utilizar esta funcionalidad deberá seleccionar los censos que desea exportar y acto seguido selecciona en el desplegable “actions” la funcionalidad de exportar censo.
Tras realizar la acción de exportar censo, se descargará en el equipo del usuario un archivo denominado “censo.csv” con los censos seleccionados. El archivo presenta la información en estructura de columnas. La primera columna se denomina “Id votante” y la segunda columna se denomina “Id votación”. Las filas siguientes representan los pares id del votante e id de la votación que se seleccionaron en la lista de censos del panel de administración.
Análogamente, se ha desarrollado una funcionalidad que consiste en la importación de censos. Esta funcionalidad, al igual que la anterior, se encuentra en el panel de administración de censos (admin/census/census) y es imprescindible que el usuario tenga el rol de administrador.
El usuario administrador selecciona los censos que desea eliminar y a continuación elige los nuevos censos que quiere importar mediante la acción “Import census” del desplegable. Tras ello, el usuario será redirigido a una vista en la que deberá seleccionar el archivo de los censos que quiere importar en el formato indicado, teniendo en cuenta que no puede insertar censos que hagan referencias a votaciones o usuarios que no estén almacenados en la base de datos.
Si todo va bien, al realizar la importación de censos, el usuario obtendrá un mensaje de éxito con los censos que se han importado. Por el contrario, si el usuario ha intentado importar un archivo con el formato erróneo o con datos incorrectos, será avisado.
Como se ha mencionado en la funcionalidad anterior, la importación de censos requiere que los datos que se pretenden importar correspondan a votaciones y usuarios ya existentes en la base de datos. Para garantizar esto se ha realizado una validación del formulario de creación de censos que se encuentra en el panel de administrador.
La validación de creación de censos se encarga de comprobar si los ids que hacen referencia a la votación y a los usuarios existen en la base de datos. Si ese es el caso, el censo se creará correctamente. Sin embargo, si se introducen ids que no se corresponden con votaciones o usuarios ya existentes, entonces el usuario administrador será avisado y no se creará el censo correspondiente.
Otro incremento funcional que se ha realizado sobre el módulo de censos ha sido la implementación de filtros de edad o sexo. De esta manera, un usuario administrador podrá filtrar los censos por votación (opción original del sistema Decide) por sexo “Hombre”, “Mujer” u “Otro” y por edad “18-30 años”, “31-50 años” y “+50 años”. Para este incremento funcional nuestro equipo se ha tenido que integrar con el equipo egc-sierrezuela-2, que se ha encargado de modificar el módulo de autenticación. Concretamente, entre otras tareas, realizó una modificación del modelo User de Django, añadiéndole una relación OneToOne a otra entidad denominada “Persona”, la cual posee los atributos edad, dirección ip, región y sexo.
Esta funcionalidad, al igual que las anteriores, se encuentra en /admin/census/census, y para acceder a ella es fundamental que el usuario tenga roles de administrador. Una vez que acceda al panel de administración de censo deberá elegir el filtro que desea aplicar en el panel de la derecha, pudiendo combinar si lo desea varios filtros, como por ejemplo filtrar por votación y edad.
Esta funcionalidad consiste en añadir un cambio en el modelo de Question dentro del módulo Voting para poder elegir el tipo de postprocesado a aplicar en el recuento de los votos de dicha pregunta. Su finalidad es la preparación del módulo para la integración con el módulo Postproc y así poder realizar distintos tipos de recuentos según se desee al crear una votación. En el modelo de Question se añade un nuevo atributo llamado type que será un IntegerField con un campo Choices que contiene los distintos tipos de postprocesado a integrar: Identity, D’Hont, Borda, Sainte Lague y Equality. Por defecto, se elegirá el postprocesado D’Hont al crear una pregunta.
El modelo de Voting también fue modificado para poder crear votaciones con múltiples preguntas. La relación con Question pasó a ser un ManyToManyField y era posible la creación de votaciones con 1 o más preguntas, con sus respectivos tipos de postprocesado.
Al comienzo de la integración con los módulos Booth y Postproc, se preparó la cabina para mostrar todas las preguntas de una votación, se modificó el módulo Store para almacenar correctamente los votos de las múltiples preguntas y se adaptaron los métodos Tally y Do Postproc del módulo Voting. Tras todos estos cambios, detectamos que por alguna razón que aún desconocemos, el decrypt de los votos no funcionaba correctamente, por lo que no era posible hacer el recuento de la votación.
Tras muchos intentos y horas de pruebas, decidimos conjuntamente con el equipo egc-sierrezuela-1, abandonar esta funcionalidad e integrar las votaciones de preguntas simples con los distintos tipos de postprocesado.
Todo el trabajo realizado para esta funcionalidad, finalmente no acabada, pueden encontrarse en la rama Booth del repositorio común egc-sierrezuela/decide.
Esta funcionalidad crea un nuevo atributo en el modelo de Voting llamado url del tipo URLField. La finalidad de este cambio era tener una url personalizada de acceso a la cabina de votación. En lugar de acceder a través de /booth/{voting_id}, hacerlo a través de /booth/tu-color-preferido por ejemplo.
Este incremento funcional lo estaba llevando a cabo un compañero que abandonó la asignatura por lo que nunca llegó a integrarse con el módulo Booth para poder ser utilizado correctamente. Soporte para integración con Cabina y Postprocesado Inicialmente, no se planificó ninguna modificación más en el módulo Voting pero al realizar la integración con los módulos Booth y Postproc se realizaron varios cambios que se describen a continuación.
El método do_postproc se adapta a los diferentes tipos de postprocesado según el tipo de postprocesado elegido en la pregunta. Recuenta los votos de cada opción y recoge los datos necesarios y en el formato requerido para realizar correctamente la función de postprocesado correspondiente.
Además, para el postprocesado Equality, también llamado Paridad o Ley de Paridad, se crean dos nuevos atributos en el modelo Voting para almacenar el recuento de votos femenino (tallyM) y el masculino (tallyH). Ambos son de tipo JSONField, al igual que el tally inicial de la votación.
Para realizar los dos nuevos tally se crean 3 nuevas funciones:
-
get_votes_equality: Recoge todos los votos de una votación y los devuelve integros con todos los datos, ya que necesitamos acceder al voter_id de cada voto para comprobar su sexo. Para el resto de postprocesados, con obtener los votos como la tupla a y b, es suficiente.
-
tally_votes_H y tally_votes_M: Ambas funciones filtran los votos por sexo, Hombre o Mujer y los añaden a una lista auxiliar. Esta lista es recorrida para coger la tupla a y b de cada voto que será procesada posteriormente al igual que el tally original (Shuffle, Decrypt). Finalmente devuelven el tallyH y el tallyM respectivamente.
Antes de realizar esta implementación, los únicos datos de una votación que se podían conocer eran los resultados obtenidos una vez que esta finalizara. La funcionalidad titulada como “visualización en tiempo real” permite conocer datos de las votaciones mientras se encuentran en progreso, por lo que saber cuántas personas están censadas en la votación e, incluso, cuantas han votado ya se vuelve algo fácil de conocer.
Para acceder a esta funcionalidad se debe iniciar una votación y dirigirse a /visualizer/id-votación. Dependiendo del estado de la votación que queremos visualizar, podremos ver tres posibilidades:
-
Si la votación todavía no se ha iniciado mostrará el título de la votación y en el campo estado indicará que la votación no ha comenzado.
-
Si la votación se encuentra en progreso se mostrará el estado, el número de personas censadas en esa votación, el porcentaje de participación y el número de votos totales.
-
Si la votación está finalizada se indicará en el estado y se mostrarán los resultados obtenidos.
Esta funcionalidad consiste en representar los datos en tiempo real para aquellas votaciones que se encuentran en progreso. Para realizar la representación se ha utilizado Charts y lo aprendido de esta web
En nuestro proyecto, esta funcionalidad es accesible desde el módulo visualizer y eligiendo la votación que se quiere mostrar: visualizer/id-votación.
Para gestionar el desarrollo de nuestro proyecto hemos utilizado la herramienta Github. Github permite poder centralizar un repositorio remoto de fácil acceso para todos nuestros miembros y, en nuestro caso, facilita mucho el desarrollo al ya estar familiarizados con él. Permite la creación de diferentes ramas totalmente independientes entre sí, por lo hemos podido definir que cada funcionalidad o prueba nueva implementada se llevaría a cabo en una rama.
Para desarrollar el proyecto se han creado issues. Cada issue representa una tarea a realizar, que puede ser redactar documentación, desarrollar o testear una funcionalidad, realizar un despliegue, etc. Al inicio del proyecto, el equipo creó una serie de tableros en el apartado Projects de nuestro repositorio de GitHub. Estos tableros representan los módulos de Decide sobre los que hemos desarrollado nuevos incrementos funcionales. El tablero “Voting” se ha utilizado también para almacenar las issues relacionadas con la documentación del proyecto o con tareas relacionadas con el despliegue de la aplicación. Una vez que estos tableros fueron creados, se definió el proceso de gestión de incidencias, en el que se detalla la creación y gestión de incidencias. En cada tablero se crearon diferentes columnas que representaban los estados de las issues:
-
Module ideas: Las issues contenidas en esta columna son ideas no vinculantes que surgieron en la primera reunión que tuvo el equipo. Son tareas que dependiendo de la duración del proyecto pueden ser abordadas o no.
-
To do: Son tareas que se deben realizar obligatoriamente. Antes de pasar a la siguiente columna, deben ser asignadas.
-
In progress: Estado en el que se encuentran las tareas en desarrollo y poseen una asignación a una persona concreta.
-
Review: Estado en el que se encuentran las tareas que han finalizado su implementación pero necesitan de una revisión por parte de una persona distinta a la que lo ha realizado para asegurar que la tarea ha sido completada con éxito.
-
Done: Estado de las tareas finalizadas correctamente y que no necesitan más trabajo.
A continuación se define el proceso de desarrollo que ha seguido cada funcionalidad realizada en el proyecto:
En primer lugar se crea la incidencia relacionada con la funcionalidad. Si es una idea se crea en la columna “Module Ideas”, mientras que si es una tarea obligatoria se crea directamente en el tablero “To Do” y se asigna a una persona, tal y como se ha explicado previamente. La issue debe contar con un título breve, una descripción y una serie de etiquetas que permitan clasificarla de diferentes maneras, tal y como se describe en nuestro proceso de gestión de incidencias
A partir de este punto, supongamos que la tarea es obligatoria de realizar, por lo que se encuentra en la columna “To Do”. Cuando la persona asignada empieza a trabajar en esa issue, entonces debe moverla al estado “In Progress”. En ese mismo instante comienza el desarrollo de la funcionalidad. Asimismo, tal y como se ha descrito en nuestro proceso de gestión del código fuente, el responsable deberá crear una rama para trabajar en ella. Para ello, debe tener el repositorio clonado en su equipo.
Una vez que el desarrollador ha terminado su tarea y ha subido su rama correspondiente, creará una pull request hacia la rama develop, en la que explica el trabajo realizado y moverá su tarea a la columna “Review”, comenzando así el proceso de revisión de la tarea. Además, en la pull request asignará a un revisor que se encargará de comprobar que la tarea ha sido completada con éxito.
El revisor es el rol que se encarga de aprobar o denegar los cambios. Para informar de su decisión, el revisor dejará un breve comentario en la pull request, tal y como se puede ver en la siguiente imagen.
Si el revisor acepta los cambios, entonces debe aceptar el merge hacia la rama develop. Una vez que se ha producido la aceptación del trabajo realizado en la tarea, entonces su responsable debe cambiar su estado a “Done” y cerrar la issue.
Sin embargo, si el revisor deniega los cambios, se realizarán los cambios pertinentes y se volverá a subir la rama. Este paso se repetirá hasta que el revisor no apruebe los cambios desarrollados.
Una vez que la funcionalidad se encuentra en develop, comienza su etapa de testeo. Para ello, se realiza un proceso análogo al que se ha explicado previamente: se crea la tarea en la que se detalla la funcionalidad que se quiere probar, el desarrollador crea una nueva rama a partir de develop, realiza el trabajo correspondiente, sube su rama, crea la pull request y espera a que el revisor acepte el trabajo realizado.
Una vez que se ha realizado el merge hacia develop, la funcionalidad ya está lista para ser transferida a la rama máster del proyecto. Si la rama develop se encuentra en un estado estable, entonces se creará una pull request hacia máster, en la que se volverá a asignar a un revisor.
Una vez que el contenido de develop se encuentra en máster, entonces se procede a realizar la integración con el resto de equipos. Para ello, se creará una pull request de máster hacia una rama de integración del repositorio padre. Esta rama de integración debe ser creada a partir de la rama develop del repositorio en el que se va a integrar. Una vez que el contenido de máster está en esa rama, se creará una issue en la columna “To Do”. Para comenzar con la integración, la issue debe ser movida al estado “In Progress”. El resto del proceso hasta la finalización de la tarea es análogo al previamente explicado.
Para aquellas tareas que son de documentación el proceso es bastante similar al anterior, aunque lógicamente no se han creado pull requests, sino que la documentación ha sido directamente revisada en la wiki.
Para el desarrollo del proyecto todos los miembros del equipo han utilizado el sistema operativo Ubuntu 20.04. Todo el equipo ha optado por el uso de máquinas virtuales mediante VirtualBox salvo Lucía Torres Gómez, quien utiliza Ubuntu mediante un disco duro externo.
Durante el desarrollo del proyecto se han utilizado las siguientes herramientas y tecnologías:
- Git. Git se ha utilizado como sistema de control de versiones.
- GitHub. Esta herramienta se ha utilizado como repositorio de código. Con GitHub hemos realizado también la gestión de incidencias gracias al apartado "Projects", en el que se pueden crear diversos tableros.
- GitHub Actions. Esta herramienta se ha empleado para crear el servidor de integración continua.
- Heroku, para realizar el despliegue de la aplicación.
- Vagrant, para desplegar la aplicación mediante máquinas virtuales y aislar las diferentes partes del sistema.
- Postgres. Se ha utilizado como base de datos de la aplicación.
El lenguaje de programación ha sido Python y se han utilizado los siguientes módulos en estas versiones:
- 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: 2.8.4
- django-rest-swagger: 2.2.0
- coverage: 4.5.2
- django-nose: 1.4.6
- jsonnet: 0.12.1
Además, se ha instalado la librería de selenium y el navegador web Chromium junto con el driver chromedriver para realizar pruebas de navegación.
Para desarrollar el código del proyecto todos los miembros del equipo han utilizado el IDE Visual Studio Code y la extensión de Python para poder ejecutar el código sin errores. A continuación se explica cómo se ha instalado el sistema Decide en los equipos de los miembros del grupo.
Lo primero que tenemos que hacer es crear un entorno virtual de Python mediante el comando python3 -m venv <nombre>. Para acceder al entorno virtual ejecutamos el comando source <nombre>/bin/activate
Creamos una carpeta y accedemos con la consola de comandos a ella
mkdir proyecto
cd proyecto
Clonamos en local el proyecto y accedemos a él
Git clone https://github.com/egc-sierrezuela-3/decide.git
cd decide/decide
Creamos un usuario decide y una base de datos para que guarden nuestra información:
sudo su - postgres
psql -c “create user decide with password ‘decide’”
psql -c “create database decide owner decide”
exit
instalamos el contenido del requirements.txt
pip install -r requirements.txt
Para ejecutar el programa es necesario poseer un archivo local_setting.py localizado en decide/decide que contega:
MODULES = [
'authentication',
'base',
'booth',
'census',
'mixnet',
'postproc',
'store',
'visualizer',
'voting',
]
BASEURL = 'http://localhost:8000'
APIS = {
'authentication': BASEURL,
'base': BASEURL,
'booth': BASEURL,
'census': BASEURL,
'mixnet': BASEURL,
'postproc': BASEURL,
'store': BASEURL,
'visualizer': BASEURL,
'voting': BASEURL,
}
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': 'decide',
'USER': 'decide',
'PASSWORD': 'decide',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
KEYBITS = 256
Creamos un usuario que tenga los permisos necesarios para poder modificar Decide. En nuestro caso lo llamaremos admin1.
./manage.py createsuperuser usuario: admin1 password: decideadmin1
Migramos la base de datos
./manage.py makemigration
./manage.py migrate
Desplegamos la aplicación con la configuración estipulada en el local_settings.py:
./manage.py runserver
Accedemos a la URL que muestra por consola y ya tendríamos nuestra aplicación desplegada en local.
El ejercicio de propuesta de cambio que vamos a presentar es modificar el módulo votaciones para aplicar distintos métodos de postprocesado. El equipo egc-sierrezuela-1 se encargará de realizar los cambios pertinentes en los módulos Booth y Postproc, mientras que el equipo egc-sierrezuela-3 los realizará en los módulos Voting y Visualización. Vamos a contar todo el proceso desde la perspectiva del equipo egc-sierrezuela-3.
En primer lugar, se crea la issue, siguiendo el proceso de gestión de incidencias, que describe el cambio a realizar en el tablero de projects adecuado, en este caso Votaciones. La tarea se etiqueta correctamente: functionality, location:backend, priority:medium y type:internal. También es asignada al integrante encargado de llevarla a cabo, en este caso Lucía Torres Gómez y pasa del estado To Do inicial al estado In progress.
A continuación procedemos a clonar el proyecto para comenzar a trabajar. Para ello abrimos una terminal y realizamos los siguientes pasos:
- Creamos un entorno virtual de python y entramos en él.
$ source python3EnvDec/bin/activate
- Creamos un directorio y clonamos el proyecto en él.
$ cd decide-sierrezuela-3
$ git clone https://github.com/egc-sierrezuela-3/decide.git
- Entramos en decide/decide, creamos la rama para la issue con la nomenclatura correcta (tipo-issue/modulo-id_issue) y nos situamos en ella.
$ git branch #Para asegurarnos que nos hemos cambiado correctamente
- Preparamos el entorno para utilizar decide.
$ pip install -r requirements.txt
$ sudo su - postgres
$ psql -c “create user decide with password ‘decide’”
$ psql -c “create database decide owner decide”
$ exit
$ cd decide #Entramos en decide
$ ./manage.py migrate #Migramos la base de datos
$ ./manage.py createsuperuser #Creamos un superusuario
$ ./manage.py runserver #Para runnear la aplicación
Ahora ya podemos comenzar a trabajar. Se realizarán los cambios que deseemos, creando commits cuando creamos convenientes. Recordamos que los commits deberían ser atómicos para poder describir correctamente el cambio y tener trazabilidad de ello. Los comandos a utilizar son los siguientes:
$ git commit #Commitear los cambios siguiendo la plantilla adecuada.
$ git push #En caso de que se quiera actualizar la rama remota.
Antes de hacer commit, es conveniente revisar que no se suban archivos no necesarios como los de configuración, si no están definidos en el gitignore previamente.
El proceso definido anteriormente será la forma de trabajo del equipo durante todo el proyecto. No será necesario repetir el proceso de creación de entornos virtuales una vez que hayamos configurado el nuestro.
Una vez finalizada la issue, esta pasará a la columna In review y será supervisada por otro compañero. Por último, cuando se acepte el trabajo realizado, la issue pasará al estado Done y se cerrará la issue.
Como hemos mencionado al comienzo de esta sección, para que esta funcionalidad pueda ser utilizada debe ser integrada con los compañeros de egc-sierrezuela-1. Como el resto del equipo egc-sierrezuela-3 necesita que Voting siga funcionando para el correcto desarrollo de sus issues, crearemos una pull request de nuestra rama a una rama dedicada únicamente a la integración, llamada feature/booth-voting-6.
Por su parte, el equipo egc-sierrezuela-1, creará sus issues y las desarrollará siguiendo su propio proceso de gestión de incidencias y del código fuente. Cuando su trabajo esté completado pasarán esa información también a la rama de integración mencionada anteriormente.
Una vez que todo el contenido de la rama de integración funcione correctamente y haya sido probada, se realizará una pull request a la rama develop para integrar la nueva funcionalidad con el resto del proyecto. La issue pasará en el tablero de la columna In Progress a In Review. Un compañero que no haya participado en esta integración se descargará la rama y comprobará el correcto funcionamiento de la misma. En el caso en el que se detecte algún error, se creará una nueva issue con la estructura necesaria. Será fundamental explicar cómo reproducir paso a paso el error. Si todo funciona correctamente, se aprobará la pull y la issue pasará a la columna Done y será cerrada.
Una vez que la rama develop haya alcanzado una versión estable y posea todas aquellas implementaciones y pruebas necesarias, se realizará una pull request a la rama principal del proyecto, la rama master. Se realizará una review a todas las funcionalidades implementadas y si todo funciona correctamente, se aprobará la pull request y el contenido de la rama master se actualizará.
El equipo egc-sierrezuela-3 se muestra satisfecho, de manera general, sobre el trabajo realizado y los resultados obtenidos. Nos gustaría destacar tanto el proceso de gestión de incidencias como el proceso de gestión del código fuente, ya que estos han sido claves para conseguir los objetivos propuestos.
Por un lado, el uso de etiquetas y descripciones para las issues ha sido fundamental a la hora de organizar y clasificar el trabajo. Aunque el uso de etiquetas no pueda parecer útil, gracias a ello el equipo ha sabido distinguir y acotar muy bien el trabajo que había que realizar en cada tarea. Asimismo, redactar las descripciones de las tareas nos ha ayudado a conocer los detalles necesarios para que estas fueran realizadas con éxito. Nos gustaría destacar este aspecto ya que nuestro equipo ha trabajado en otros proyectos previamente en los que no se ha llevado a cabo un proceso de gestión de incidencias, por lo que surgían muchas contradicciones y conflictos a la hora de ejecutar las tareas.
Por otro lado, utilizar una rama por funcionalidad ha ayudado a los miembros del equipo a realizar el trabajo de manera ordenada. Además, al estar trabajando sobre una rama de una funcionalidad en concreta se favorece la realización de commits atómicos, por lo que se puede ver claramente en qué ha estado trabajando cada miembro del equipo y su aportación sobre el proyecto.
Uno de los puntos negativos a destacar en la realización del proyecto ha sido la integración con los miembros de los otros equipos. La organización de los equipos se fundamentó en crear un repositorio de trabajo por cada equipo, y crear un repositorio padre en el que se han introducido los incrementos funcionales una vez que estos estuvieran finalizados. Llevar a cabo esta práctica ha provocado la aparición de muchos conflictos y problemas bastante complejos de solucionar. Quizá habría sido buena idea crear un repositorio padre y repositorios por cada integración a realizar. De esta manera, las integraciones se habrían realizado de manera continua, y no al final del proyecto, tal y como ha ocurrido en nuestro caso. Además, al ser la primera vez en la que varios equipos trabajan sobre un mismo proyecto, pensamos que se deberían haber realizado más reuniones para planificar la realización del trabajo y tener un mayor control sobre el estado del proyecto.
Debido a la falta de tiempo, nuestro equipo tenía ideas que finalmente no han sido posible llevar a cabo, lo que ha provocado que algunas funcionalidades no estén tan completas como nos gustaría. A continuación se describen algunas ideas para mejorar el sistema en el futuro:
-
Rediseñar el modelo de censo. Actualmente, un censo es un par de dos ids, uno perteneciente a la votación y otro perteneciente al votante. Sería bastante interesante realizar una agrupación de censos, de manera que un censo estuviera formado por personas que cumplan una serie de características. Por ejemplo, un censo que agrupara a las personas de 18 a 25 años.
-
En relación con el punto anterior, se podría haber implementado una funcionalidad que permitiera reutilizar los censos desde la propia aplicación. Esto se puede realizar de manera indirecta con la funcionalidad de importación de censos, aunque para ello es necesario importar un archivo con un formato determinado que debe estar guardado en el equipo local.
-
En cuanto al módulo de visualizaciones, en un futuro se podrían añadir filtros que permitieran generar gráficos o tablas estadísticas de las votaciones según las características de los votantes. Por ejemplo, si la votación se ha realizado a personas de varias ciudades de España, se podría implementar una funcionalidad que permitiera ver el porcentaje de personas de cada ciudad que ha votado. Otro ejemplo podría ser el análisis estadístico de los resultados según el género de los votantes.
-
Finalmente, tal y como se ha mencionado en el apartado de Incrementos Funcionales, de cara a futuros proyectos se propone terminar la integración de la implementación de múltiples preguntas de votación con los módulos de cabina y post-procesado. De este modo se conseguirían votaciones más elaboradas y se podrían realizar votaciones de varias preguntas sobre un mismo tema.
Finalmente, como conclusión general, estamos satisfechos con la gestión interna realizada en nuestro equipo, aunque de cara al futuro será fundamental estudiar nuevas formas de trabajo en proyectos que impliquen la participación de un mayor número de personas, para así evitar (o al menos mitigar) los problemas anteriormente descritos.