Documento del proyecto

decide-part-camaron-3

• Grupo 3, Mañana
• Curso escolar: 2023/2024
• Asignatura: Evolución y Gestión de la Configuración (EGC)

Indicadores del proyecto

Miembro del equipo	Horas	Commits	LoC	Tests	Issues	Incremento
Domínguez-Adame Ruiz, Alberto	60	50	1166	6	6	Varias preguntas en la misma votación. Interfaz de varias preguntas en la misma votación.
Herrera Ramírez, Ismael	60	52	781	8	9	Implementación del nuevo tipo de votación jerárquico. Roles en el censo para votación jerárquica.
Izquierdo Lavado, Mario	60	41	494	13	7	Checkbox de Si/No para una Votación. Checkbox de una tercera opción para una Votación. Interfaz de filtro de tipo de votación.
Merino Palma, Alejandro José	60	21	496	6	7	Votaciones por preferencia. Ayuda en varias preguntas en la misma votación.
Olmedo Marín, Marcos	60	31	774	5	6	Exportación de los resultados de las votaciones a csv. Exportación del censo de una votación a csv
Tomás Vela, Elena	60	22	423	6	3	Visualizador de estadísticas de una votación cerrada.
TOTAL	360	217	4134	44	44	Decide con ampliaciones en tipos de votación y visualizado de resultados.

La tabla contiene la información de cada miembro del proyecto y el total de la siguiente forma:

• Horas: número de horas empleadas en el proyecto
• Commits: solo contar los commits hechos por miembros del equipo, no lo commits previos
• LoC (líneas de código): solo contar las líneas producidas por el equipo y no las que ya existían o las que se producen al incluir código de terceros
• Test: solo contar los test realizados por el equipo nuevos
• Issues: solo contar las issues gestionadas dentro del proyecto y que hayan sido gestionadas por el equipo
• Incremento: principal incremento funcional del que se ha hecho cargo el miembro del proyecto

Integración con otros equipos

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:

• decide-part-camaron-1: Traducción y autenticación.
• decide-part-camaron-2: Hemos trabajado con el equipo tal que las técnicas de postprocesado puedas ser elegidas y aplicadas en las votaciones, y además puedan ser vistas en una vista de visualización.

El equipo decide-part-camaron-1 dejó la comunidad tras realizar la revisión del M2

Resumen ejecutivo

Este documento hace referencia a la metodología de trabajo que hemos seguido y los incrementos que hemos llevado a cabo para mejorar la aplicación de Decide. Todo ello, ha sido desarrollado poniendo en práctica los conocimientos tanto teóricos como prácticos vistos en la asignatura. En el transcurso del desarrollo, hemos trabajado en mejoras al software de Decide: un sistema de voto electrónico educativo que implementa un sistema básico de votación electrónica con voto secreto y criptográficamente seguro punto a punto. Además, nuestros incrementos han estado relacionados mayoritariamente con el subsistema de votaciones (voting) y visualización (visualizer), aunque también hemos tocado el módulo de censo (census), cabina (booth), almacenamiento (store) y aunque no hemos trabajado implícitamente en el módulo de post-procesado, los cambios hechos en el módulo de visualización dependen del trabajo del equipo 2 en este módulo. Nuestra versión enriquece la experiencia de usuario ofreciendo diferentes tipos de votaciones. Están disponibles los siguientes métodos:

• Inclusión de votación con múltiples preguntas: en el Software base de Decide, al realizar una votación, sólo se puede elegir un único tópico sobre el cual votar. Nuestra versión abre la posibilidad de incluir varias preguntas dentro de la misma votación.

• Inclusión de votación con roles dentro de una pregunta: también conocido como votación jerárquica, a la hora de censar a un usuario se le podrá denominar con un rol específico, el cual le entregará al usuario un valor al voto. De esta forma se podrán asignar rangos. Se han usado los rangos de las jornadas. De esta forma, los rangos disponibles son:

  1. Balanceado
  2. Colaborador
  3. Coordinador
  4. Presidente

• Inclusión de votación con checkbox Si/No: durante la creación de una pregunta, ahora es posible seleccionar una checkbox que crea automáticamente las opciones Sí y No y limita las opciones sólo a estas dos impidiendo que se puedan modificar.

• Inclusión de votación con checkbox Depende: durante la creación de una pregunta, ahora es posible seleccionar una checkbox que crea automáticamente la opción Depende y limita las opciones tres, siendo las dos restantes compatibles con la casilla Si/No o con preguntas creadas por el usuario.

• Incursión de votaciones con múltiple elección opciones: inclusión de la modalidad de voto de múltiple elección, pudiendo así el votante responder a las preguntas con el orden de prioridad que le da a cada opción, y considerando la puntuación según la cantidad de distintas opciones, permitiendo ofrecer opciones según su preferencia global.

• Exportación de censo de una votación: Permite exportar en formato csv y hoja de cálculo xls el censo de una votación.

• Exportación de resultado de una votación: permite exportar en formato csv y hoja de cálculo xls los resultados de una votación. El archivo xls es un libro de Excel donde cada hoja es una pregunta y el contenido de cada hoja los resultados de cada pregunta.

• Visualización de estadísticas de una votación: Vista mejorada del módulo visualizer, donde se pueden apreciar con detalle las gráficas correspondientes al resultado de la votación. Además, se muestran en tablas los resultados de postprocesados, número de personas inscritas en el censo, número de personas que han votado y porcentaje de participación.

La intención detrás del desarrollo de estos incrementos funcionales, aparte de agregar valor a la aplicación, es añadir nuevas funcionalidades que aporten una mayor flexibilidad al sistema, creando así la oportunidad de amoldarse a las necesidades de más usuarios. También buscamos aumentar la calidad de la experiencia de usuario con los cambios realizados en el módulo de visualización, permitiendo al usuario visualizar mejor los datos y estadísticas de una votación ya concluida en forma de gráficas.Por último las funcionalidades de exportación de censo y resultados de una votación es ofrece al usuario tratar y estudiar los los resultados de forma externa a la herramienta. Con el objetivo de mantener un seguimiento y control del proyecto de calidad, se ha utilizado la herramienta de Github para coordinar al equipo, gestionar las tareas y seguir el flujo de trabajo de cada una de las issues. Dichas issues fueron creadas y asignadas a cada miembro al comenzar el desarrollo del proyecto, y posteriores issues de incidencias fueron creadas también durante la implementación. Existen 4 estados: Todo, In Progress, Review y Done. Como complemento a las herramientas que ofrece github, el desarrollo del código se ha realizado desde el Entorno de Desarrollo Integrado (IDE) Visual Studio Code. Aunque la dinámica principal a la hora de redacción del código ha sido individual, en los casos donde un integrante del equipo de desarrollo haya encontrado dificultades para progresar, se han realizado reuniones (ya sea del equipo completo o parciales) para evitar retrasos y agilizar la implementación de las tareas, enfocándonos en el objetivo de llegar a la fecha de entrega con todas las funcionalidades completas e integradas entre los subgrupos. Esta metodología de trabajo ha resultado en que todos los integrantes del equipo estén al tanto y hayan ayudado de manera puntual en el resto de tareas a pesar de que cada desarrollado ha estado centrado en sus tareas asignadas.

Además, se ha integrado Codacy para automatizar el análisis de código cada vez que se hace una pull-request desde la rama de algún miembro hacia develop y también se ha integrado el despliegue automático con Render.

Descripción del sistema

El sistema decide-part-camaron-3 se fundamenta en una aplicación que emplea un sistema de voto electrónico llamado Decide. Este sistema, creado en el framework web Django con Python, tiene como objetivo implementar un método básico de votación electrónica que garantiza el secreto del voto y la seguridad criptográfica punto a punto. El proyecto se estructura en varios subsistemas independientes entre sí, conectados mediante API. Para lograr esta interconexión, es necesario un proyecto base en Django que configure las rutas para estas API. Este proyecto estará compuesto por aplicaciones (subsistemas y proyecto base) que pueden ser reemplazadas de manera individual. Cada subsistema se representa a través de modelos distintos (objetos) y se visualiza mediante diversas vistas implementadas para el usuario. Para la implementación, se requiere la creación de un entorno virtual de Python usando el comando: “python3 -m egcenv”. Posteriormente, se activa este entorno con: "source egcenv/bin/activate” y se desactiva con deactivate. PostgreSQL se emplea como base de datos y para crear la nuestra se utilizan los comandos: sudo su - postgres, psql -c “create user decideuser with password ‘decidepass123’” y psql -c “create database decidedb owner decideuser”.

En la aplicación, el administrador puede proponer unas votaciones, con cuestiones específicas y los usuarios autorizados pueden responder. Estas votaciones deben ser cerradas cuando el administrador lo vea adecuado y posteriormente se puede obtener un recuento con los resultados finales. Los subsistemas que componen la aplicación son los siguientes:

• Autenticación: Permite el registro de nuevos usuarios, así como el acceso a la aplicación y a las votaciones.
• Censo: Los censos permiten determinar qué usuarios pueden votar en determinadas votaciones y quienes no.
• Votaciones: la votación puede definir una o varias preguntas, con diferente número de opciones y diferentes configuraciones. Puede ser una votación simple como elección múltiple.
• Cabina de votación: Interfaz para votar. Este subsistema se encarga de mostrar la interfaz de voto de una votación en concreto, permitiendo al votante votar de forma sencilla.
• Almacenamiento de votos: los votos se almacenan de forma cifrada en una base de datos, donde tenemos la relación directa de votante y voto. No se puede saber la intención de voto puesto que el voto está cifrado en la base de datos, pero sí tendremos la información de quién ha votado y quién no.
• Recuento: Post-procesado: Una vez realizado el recuento, tenemos una lista de números, este subsistema se encarga de traducir esa lista de números a un resultado coherente con el tipo de votación. Por ejemplo, si es una votación de tipo simple, simplemente habrá que contar el número de veces que aparece cada opción y se dará como ganadora la opción con más opciones. Este subsistema también es el encargado de aplicar diferentes reglas a los resultados, por ejemplo, aplicar reglas de paridad, ley d'Hondt, etc.
• Visualización de resultados
• Autenticación
• Base: Este módulo contiene información básica del modelo de la base de datos como las claves y las autenticaciones de votación.
• Cabina: Con esta aplicación se pueden realizar los votos en la aplicación, accediendo a las votaciones mediante un enlace.
• Censo: Los censos permiten determinar qué usuarios pueden votar en determinadas votaciones y quienes no.
• Gateway: Un módulo que ofrece un servicio de API de la aplicación de Decide.
• Mixnet: Aplicación que ofrece servicios de encriptado y desencriptado de votos, para mantener a los votantes en el anonimato.
• Post-procesado: Permite realizar un recuento de los votos para obtener los resultados finales de una votación.
• Almacenamiento: Aquí se mantienen guardados todos los votos de la aplicación.
• Visualización: Este módulo ofrece una representación de los votos en una tabla, para saber la opción ganadora.
• Votación: Contiene la información relativa a las votaciones y a las preguntas que se realizan en ellas.
• Cada módulo se encuentra en carpetas específicas del proyecto.

Con respecto al funcionamiento del sistema Decide, este sistema se enfoca principalmente en el módulo de votación que permite crear, modificar y borrar votaciones, además de hacer recuentos, visualizaciones a partir de otros módulos. A partir de una cuenta de administrador se pueden consultar los elementos de la base de datos, así como crearlos, editarlos y eliminarlos. Un administrador, además, podrá dar autorización a otros usuarios para poder realizar algunas acciones, como votar comúnmente. La relación entre los distintos subsistemas es visible durante la creación de una votación, ya que para ello un usuario ya registrado, y con permisos suficientes, puede crear una Auth, esta es una autenticación para alojar la votación en una URL específica, dada por el usuario. Una vez creada esta Auth, con su nombre y URL, se creará las cuestiones que formarán parte de la votación, a la hora de crearlas se deberá indicar una descripción de estas y unas opciones, estás podrán ser múltiples o de tipo sí o no . A continuación, se podrá crear la votación, en esta el administrador podrá rellenar en un formulario de la pregunta, escoger el número de cuestiones necesarias y auth que se desee.

Tras crearla, el administrador podrá, “abrir” esta votación para que sea disponible el votar, pero antes el administrador deberá crear unos censos, en los que se relacionan los usuarios con una votación, a pastor de sus id’s, de esta forma se da permiso a usuarios concretos para poder votar. Una vez parezca conveniente, el administrador podrá “cerrar” esta votación, de esta forma la votación finalizará y no podrá votar ningún usuario más. Será entonces, cuando la votación esté finalizada, cuando se podrá hacer un recuento de los votos con los resultados obtenidos. Una vez obtenidos los resultados, y procesados, será posible comprobar los datos en el visualizador.

Nuestras tareas han implicado cambios en diferentes subsistemas, por lo que ha sido necesaria una gran coordinación entre los distintos participantes del proyecto y del equipo. Los subsistemas desarrollados/modificados son:

• Votación: Se definen las preguntas con su número de opciones y configuración específica. Una votación implica varias preguntas, lo cual se tendrá en cuenta para su recuento y visualización. Además una pregunta puede tener como opciones solamente Sí y No. También, ahora es posible seleccionar una checkbox que crea automáticamente la opción Depende. Luego, a la hora de censar a un usuario se le podrá denominar con un rol específico, el cual le entregará al usuario un valor al voto. De esta forma se podrán asignar rangos. Para finalizar, hablar de la inclusión de la modalidad de voto de múltiple elección, pudiendo así el votante responder a las preguntas con el orden de prioridad que le da a cada opción.

• Visualización: Permite exportar en formato csv y hoja de cálculo xls el censo de una votación. Además, ahora se permite la exportación de resultado de una votación que viene a exportar en formato csv y hoja de cálculo xls los resultados de una votación. Y para finalizar la visualización de estadísticas de una votación, donde se pueden apreciar con detalle las gráficas correspondientes al resultado de la votación. Además, se muestran en tablas los resultados de postprocesados, número de personas inscritas en el censo, número de personas que han votado y porcentaje de participación.

Lista de subsistemas modificados:

• Votación:

  • Inclusión de votación con múltiples preguntas: al realizar una votación, sólo se puede elegir un único tópico sobre el cual votar. Nuestra versión abre la posibilidad de incluir varias preguntas dentro de la misma votación.

  • Inclusión de votación con roles dentro de una pregunta: también conocido como votación jerárquica, a la hora de censar a un usuario se le podrá denominar con un rol específico, el cual le entregará al usuario un valor al voto. De esta forma se podrán asignar rangos. Se han usado los rangos de las jornadas.De esta forma, los rangos disponibles son: Balanceado(1), Colaborador(2), Coordinador(3) y Presidente(4).

  • Inclusión de votación con checkbox Si/No: durante la creación de una pregunta, ahora es posible seleccionar una checkbox que crea automáticamente las opciones Sí y No y limita las opciones sólo a estas dos impidiendo que se puedan modificar.

  • Inclusión de votación con checkbox Depende: durante la creación de una pregunta, ahora es posible seleccionar una checkbox que crea automáticamente la opción Depende y limita las opciones tres, siendo las dos restantes compatibles con la casilla Si/No o con preguntas creadas por el usuario.

  • Incursión de votaciones con múltiple elección opciones: inclusión de la modalidad de voto de múltiple elección, pudiendo así el votante responder a las preguntas con el orden de prioridad que le da a cada opción, y considerando la puntuación según la cantidad de distintas opciones, permitiendo ofrecer opciones según su preferencia global.

• Visualización:

  • Exportación de censo de una votación: Permite exportar en formato csv y hoja de cálculo xls el censo de una votación.

  • Exportación de resultado de una votación: permite exportar en formato csv y hoja de cálculo xls los resultados de una votación. El archivo xls es un libro de Excel donde cada hoja es una pregunta y el contenido de cada hoja los resultados de cada pregunta.

  • Visualización de estadísticas de una votación: Vista mejorada del módulo visualizer, donde se pueden apreciar con detalle las gráficas correspondientes al resultado de la votación. Además, se muestran en tablas los resultados de postprocesados, número de personas inscritas en el censo, número de personas que han votado y porcentaje de participación.

Visión global del proceso de desarrollo

La finalidad de este apartado consiste en dar una explicación sobre el procedimiento seguido para desarrollar cada incremento necesario y conseguir así aportar valor al proyecto.

En cuanto a el proceso de desarrollo empezaremos contando cuál es el proceso de gestión de incidencias.

El equipo ha utilizado github como herramienta para gestionar tanto el proyecto como las incidencias que lo componen para así tenerlos vinculados al repositorio. Las incidencias se crean desde el menú Issues donde, a continuación, detallamos los campos a completar.

• Título: descripción clara y concisa sobre la información de la incidencia.
• Identificador: número generado de forma ordinal por github. Usado para vincular commits a una incidencia determinada.
• Descripción: descripción más detallada de la incidencia.
• Asignación: miembros del equipo encargados de gestionar la incidencia.
• Etiquetas: El equipo decidió crear etiquetas personalizadas para agrupar las incidencias en función del subsistema al que se le va a hacer un incremento. Se usan algunas etiquetas ya creadas por github: bug,enhancement, testing, documentation.
• Proyecto (y estado): vinculamos la incidencia al proyecto correspondiente y le asignamos un estado.
• Estados:
  • Todo: incidencia por hacer.
  • In Progress: se ha comenzado a trabajar en ella.
  • Review: esperando a ser revisada.
  • Done: considerada como hecha.
• Milestone: hito para agrupar las diferentes incidencias que deben estar listas para una fecha de entrega determinada.
• Desarrollo: rama y pull request asociada a la incidencia. Para la gestión del código fuente hemos utilizado git y hemos utilizado todo el equipo un repositorio común con una rama master y otra develop y develop-merge-global para integrar el código antes de que vaya a develop además de una para cada participante y otra para el módulo de voting el cual ayudaba a la integración de cuatro miembros del equipo que tenía cada uno un incremento del módulo de votación. Cada uno ha ido subiendo sus cambios a su rama personal y ha ido realizando pull requests a este módulo de voting siempre que tuviera un fragmento de código funcional y con un valor mínimo. Para la rama develop se hacía lo mismo donde cada uno ha ido subiendo sus cambios a su rama personal en el caso de los otros dos compañeros y de la rama módulo de voting y se han ido realizando pull requests a develop siempre que tuviera un fragmento de código funcional y con un valor mínimo. Hemos realizado una plantilla de commits, que indica que seguirán un formato tal como el siguiente: tipo: Titulo de incidencia descripción
• El tipo será uno de los siguientes opciones:
  • chore
  • feat o feature
  • fix
  • docs
  • test
  • refactor
• La incidencia id debe ser el número identificador asociado a la issue realizada.
• Descripción debe ser una descripción breve de lo realizado. Cuando se hace una PR otra persona del mismo equipo realiza una revisión de dicha PR comprobando que todo funciona correctamente, una vez que esta persona lo ha revisado y verificado, acepta la Pull request.

Tenemos una serie de archivos que no se suben ya que están en el .gitignore. Estos archivos corresponden con configuraciones locales (local_settings.py). Incluido configuraciones del IDE, entornos virtuales de python, etc.

En cuanto a las pruebas, se han desarrollado: los casos de pruebas unitarias, probando el correcto funcionamiento interno de la aplicación, en donde cada uno se ha hecho responsable del código que ha tratado, de manera que antes de integrarlo todo en una misma rama comprobamos que no es errónea la parte subida en el commit, y las pruebas de vistas, realizando pruebas de navegación gracias a Selenium, en las que se ha ido probando que la página mostraba lo que debía y como distintas acciones te llevan a diferentes páginas. Las técnicas de automatización utilizadas han sido el uso de las actions, que ejecutaban los test siempre que se hiciera pull request a develop o master, también se realizaban siempre que se hiciera push a develop o master.

El equipo se ha centrado en la integración continua por sus beneficios. Entre ellos encontramos la detección de errores de una manera más rápida y fácil, así como la mejora de calidad del código. Por lo que en cuanto a la integración continua se ha realizado de la siguiente manera: tenemos una rama de master y otra de develop, adicionalmente cada participante tiene una rama personal en la que sube todos sus cambios. Cada vez que una persona realice una tarea y tenga un cambio mínimo pero significativo esta tendrá que hacer un merge con develop-merge-global en su rama viendo que funciona todo correctamente, luego este hará una pr a develop-merge-global, al hacerla se ejecutarán las actions probando que haga buid y que funcionen los test, además de realizar un código de análisis de codacy, en el que se verán los code smells y el coverage. Adicionalmente cuando se haga un push a master y a develop también se ejecutará el análisis, calculando el coverage de los test, también se probará que haga build y los test. Tenemos dos workflows de github actions en el proyecto. django.yml es un workflow heredado del proyecto base decide que hemos modificado cuando se ejecuta.

Sobre las estrategias utilizadas en el despliegue destacamos principalmente 2 estrategias:

1. La primera estrategia se basa en el despliegue a Docker en la cuál para realizar dicho despliegue creamos un fichero en el repositorio de decide llamado docker-compose.yml que contiene la configuración de la BBDD(base de datos) de postgres y archivos de configuración extra y se realizó el Dockerfile. El repositorio del código que despliega el sistema se divide en tres imágenes: uno para la base de datos de postgres, otro para el servicio web (decide) y otro para un balanceador de carga Nginx. El comando para ejecutar el proyecto en docker es docker compose up. Para poder ejecutarlo deberíamos tener desactivado el entorno virtual.

2. La segunda estrategia se basa en el despliegue a Vagrant en la cuál para realizar dicho despliegue creamos un fichero en el repositorio de decide llamado django.yml que contiene la configuración de la base de datos y admin superuser; dentro del repositorio una carpeta llamada vagrant en la que contiene un archivo Vagrantfile que contiene los comandos que ejecuta Vagrant para construir la imagen de la aplicación (decide) y los ficheros YAML pertinentes para la provisión de Ansible. El comando para ejecutar el proyecto en vagrant es vagrant up.

Al principio fuimos un grupo de 18 personas formado por 3 equipos de 5 cada uno, pero después del M2 uno de los grupos decidió separarse, decide-part-camaron-1, aun así cada grupo ha trabajado su propio repositorio,teniendo entonces dos repositorios. uno para decide-part-camaron-2 y otro para decide-part-camaron-3, teniendo una rama master y una rama develop distinta cada uno de los grupos, además de una rama para cada uno de los participantes. Hemos seguido un modelo democratico en el que todas las reuniones se han realizado con al menos un participante de cada uno de los 3 equipos, hasta que se fue el grupo decide-part-camaron-1 y entonces fueron entre los dos grupos que quedaron. Se han organizado las tareas en el tablero de github projects, permitiendo a todos los participantes conocer el estado de estas en cualquier momento.Se han ido fijando reuniones para repasar el trabajo realizado cuando hemos visto conveniente. Además, en muchos casos se han realizado reuniones informales entre subgrupos para resolver dudas o trabajar juntos en la plataforma de discord y siendo estas siempre avisadas por el grupo de Whatsapp en el que están todos los miembros del grupo, para que asistiera quien quisiese. Las comunicaciones del día como, por ejemplo, avisar de las fechas límite, avisar de finalización de tarea, preguntar dudas o concertar reuniones han sido realizadas por el grupo de Whatsapp del equipo de trabajo.

Además, a lo largo del desarrollo del proyecto, se han ido acordando fechas límites con los demás grupos para la realización de las funcionalidades para una mejor organización del trabajo. Si bien es cierto que no en todos los casos estas fechas límites se han cumplido, en la mayoría de los casos sí ha sido así. Estas fechas han permitido que el trabajo no se fuese acumulando. Estas fechas fueron por ejemplo los milestones M1, M2 entre otros. Para finalizar hablaré sobre los conflictos ocurridos en decide-part-camaron-2 los cuales fueron conflictos menores y han sido resueltos hablando el problema entre los compañeros y acordando una fecha límite para la finalización de la tarea. Si llegaba la fecha límite y la tarea no se había realizado, se estudiaba el caso y las circunstancias de esa persona o personas y se podían dar más días o tener una penalización adjudicándose documentación. Aparte de eso, no ha habido ningún conflicto más reseñable, hemos intentado ayudarnos entre nosotros cuando lo hemos necesitado.

Entorno de desarrollo

En este documento se explicará el entorno de desarrollo utilizado por parte de los miembros del equipo y las distintas opciones que se han usado. La primera de ellas es el uso de una máquina virtual Ubuntu, versión 22.04. Dichas máquinas virtuales eran creadas desde VirtualBox, aplicación la cual sirve para hacer máquinas virtuales con instalaciones de sistemas operativos. Esto quiere decir que, si tienes un ordenador con Windows, GNU/Linux o incluso macOS, puedes crear una máquina virtual con cualquier otro sistema operativo para utilizarlo dentro del que estés usando. Para el uso de estas, previamente tenías que descargar el ISO de Ubuntu e inicializarla desde la aplicación añadiendo la configuración a tu gusto. La segunda es la instalación de Ubuntu en un pendrive, la cual fue usada por un solo miembro del grupo y se realizaba con la descarga e instalación mediante otro programa externo de la imagen de Ubuntu en el dispositivo, para realizar después la configuración de arranque de tu PC para que se inicie con la imagen nueva. Una vez dentro de Ubuntu, realizaremos las siguientes instalaciones desde el terminal, para tener todo a punto para la realización del proyecto Decide.

sudo apt update sudo apt install python3.10 python3.10-dev python3.10-venv python3-pip 
sudo apt install postgresql libpq-dev

En el comando de arriba realizamos la instalación de Python y del entorno virtual.

python3.10 -m venv egcenv
source egcenv/bin/activate 

Activamos el entorno virtual creado previamente.

git clone https://github.com/marolmmar1/decide-part-camaron-3.git 

Una vez clonado el repositorio del proyecto, instalaremos una serie de paquetes para el correcto funcionamiento del proyecto en general. Todos estos paquetes se encuentran incluidos en un requirements.txt con las versiones necesarias para nuestro proyecto. Por lo que, lo primero será acceder a requirements.txt y una vez dentro realizar el comando pip install -r requirements.txt. Se descargarán los siguientes paquetes:

Django==4.1
pycryptodome==3.15.0 
djangorestframework==3.14.0 
django-cors-headers==3.13.0 
django-dbbackup==4.0.1 
requests==2.28.1 
django-filter==22.1 
psycopg2==2.9.4 
coverage==6.5.0 
jsonnet==0.18.0 
django-nose==1.4.6 
django-rest-swagger==2.2.0 
selenium==4.7.2 
cryptography==41.0.5 
pytest channels==3.0.4 
websocket-client==1.2.1 
dj-database-url == 2.1.0 
whitenoise==6.5.0
gunicorn==21.2.0 
pandas==2.0.3 
channels==3.0.4 
openpyxl == 3.1.2

Una vez instalados los paquetes, se procederá a crear una base de datos y el usuario postgres. Esta creación se realiza siguiendo los siguientes comandos (nombre de usuario y contraseña son ejemplos):

sudo su – postgres psql -c "create user decideuser with password decidepass123" 
psql -c "create database decidedb owner decideuser" 
exit 

Para comprobar el correcto uso de código y de realización de tests del proyecto, se siguen una serie de comandos que se detallan a continuación:

Hacemos las migraciones:

./manage.py makemigrations 
./manage.py migrate 

Creamos un superusuario:

./manage.py createsuperuser 

Iniciamos la aplicación:

./manage.py runserver 

Para ejecutar todo el conjunto de tests:

 ./manage.py test  

Para ejecutar sólo los test de un módulo:

./manage.py test <módulo a seleccionar> 

Para la realización y organización local del código, utilizaremos Visual Studio Code, el cuál es un editor de código fuente desarrollado por Microsoft. Es software libre y multiplataforma, está disponible para Windows, GNU/Linux y macOS. VS Code tiene una buena integración con Git, cuenta con soporte para depuración de código, y dispone de un sinnúmero de extensiones, que básicamente te da la posibilidad de escribir y ejecutar código en cualquier lenguaje de programación. En este proyecto, trabajaremos sobre Django, cuya versión que usaremos es la 4.0. Django es un framework web de alto nivel que permite el desarrollo rápido de sitios web seguros y mantenibles. Desarrollado por programadores experimentados, Django se encarga de gran parte de las complicaciones del desarrollo web, por lo que podemos concentrarnos en escribir nuestra aplicación sin necesidad de reinventar la rueda. Es gratuito y de código abierto, tiene una comunidad próspera y activa, una gran documentación y muchas opciones de soporte gratuito y de pago. Para la realización de casos de pruebas, concretamente de vistas, utilizaremos una herramienta llamada selenium, la cual es un entorno de pruebas de software para aplicaciones basadas en la web. Selenium provee una herramienta de grabar/reproducir para crear pruebas sin usar un lenguaje de scripting para pruebas (Selenium IDE). También se instala desde el requirements.txt, pero para esta herramienta en particular necesitamos instalar una cosa más, Chromium, el cual es una versión de código abierto de Google Chrome, pero sin todos los códecs exclusivos y otros elementos con los que Google pretende diferenciar Chrome de otros navegadores. Así pues, Chrome es la suma de Chromium y una serie de plugins propietarios, un mantenimiento dedicado, y opciones diseñadas por los desarrolladores de Google para hacerlo único. Para instalarlo, usaremos el siguiente comando: sudo apt install chromium-browser chromium-chromedriver

Ejercicio de propuesta de cambio

Se presentará un ejercicio con una propuesta concreta de cambio en la que a partir de un cambio que se requiera, se expliquen paso por paso (incluyendo comandos y uso de herramientas) lo que hay que hacer para realizar dicho cambio. Debe ser un ejercicio ilustrativo de todo el proceso de evolución y gestión de la configuración del proyecto.

Añadir una casilla llamada voto en blanco, que no limite la cantidad de opciones en una votación y que se llame voto en blanco.

1. Se presentará una propuesta de cambio para añadir una casilla llamada voto en blanco, que no limite la cantidad de opciones en una votación. El proceso, en pasos generales, es el siguiente:
2. Se creará una issue, asignándole en este caso el tag de enhancement, y un encargado.
3. Desde la rama de develop, se creará una rama con un nombre breve de la característica ("enhancement: Añadir voto en blanco"), junto con una descripción detallando los requisitos de este cambio.
4. Tras eso, se accederá desde el entorno de desarrollo individual del desarrollador y hará los cambios pertinentes. Añadiendo dichos cambios al repositorio mediante commits que sigan las políticas establecidas del grupo.
5. Se subirán los cambios y se creará una PR desde esa rama a develop, y se asignan a los revisores. Los revisores deberán de dar el visto bueno (al menos uno), y las actions deberán de ejecutarse correctamente.
6. Si todo fue correcto, se aceptará la PR a develop.
7. Sino, se rechazara la pull request y se le comunicará al desarrollador los cambios necesarios en los comentarios de la issue.

La issue se crea a partir de una plantilla por defecto, en la que describimos el cambio a realizar, el comportamiento que ocurre, el que debería de hacer después, y finalmente los módulos que afecta.

En este caso particular, el desarrollador deberá de ejecutar, desde el punto 3 hasta el 4 una serie de comandos para crear la rama:

git pull --rebase origin develop # Desde develop local 
git checkout -b escanio
./manage.py flush && ./manage.py makemigrations && ./manage.py migrate && ./manage.py createsuperuser && ./manage.py runserver

En caso que haya problemas con el sistema instalado por la propia base de datos, se deberán de ejecutar los comandos SQL descritos antes.

Abrir el entorno de trabajo y hacer los cambios

./manage.py test voting #Ya que este cambio actua sobre voting, debería de correr correctamente.

git add . && git commit -s && git push origin escanio

El formato del commit está establecido por la misma filosofía que la de git-flow:

(feat|test|style|...)[()]: <Descripción>

Conclusiones y trabajo futuro

Se enuncian algunas conclusiones y se presentará un apartado sobre las mejoras que se proponen para el futuro (curso siguiente) y que no han sido desarrolladas en el sistema que se entrega.

Para cerrar el documento de nuestro grupo, decir que el desarrollo de decide-part-camaron-3 ha sido un trabajo bastante duro.

Decimos esto no únicamente por el proyecto, también porque casi todos los integrantes del grupo optamos por la opción colaborativa en las jornadas, la cual resta mucho tiempo tanto para este cometido como para los de otras asignaturas. Además, tenemos que contar con que el hecho de que estemos en un subgrupo de un trabajo tipo “part”, añade un factor de dificultad en cuanto a la integración continua se refiere. No se trata únicamente de la integración entre los propios compañeros, ha sido clave durante todas estas semanas mantener un contacto activo con las otras dos partes del proyecto decide, con todo lo que eso conlleva: toma de decisiones, reuniones, fechas previas a los milestones, resolución de incidencias que derivan de incrementos ajenos (y propios), etcétera.

• Derivado de esto, el grupo ha recogido una serie de lecciones aprendidas: Hemos aprendido la importancia que tiene la integración continua en un proyecto software. Es clave para que el trabajo avance a buen ritmo. Los mayores problemas que hemos encontrado han sido provocados por issues de otros grupos, sin embargo, estos errores podrían haber sido mucho más críticos sin las anteriormente mencionadas reuniones y comunicaciones.
• La importancia de la limpieza del código, gracias a los análisis que nos ha ido generando la herramienta Codacy. Ha sido común a lo largo del desarrollo realizar commits (antes de aceptar las pull request) para la corrección de code smells y similares.
• La gestión de equipos. Es fundamental tener un buen ambiente de trabajo (y un grupo de gente comprometida con el resto) y respeto mutuo entre los integrantes, tanto en nuestro subequipo como con los demás.

En la pregunta de propuestas para los proyectos futuros, al grupo se le ha ocurrido lo siguiente:

• Una interfaz de usuario para el administrador.
• Almacenar en el sistema el instante en el que un voto se envía para poder hacer un estudio estadístico de los intervalos de tiempo más concurridos durante el periodo de votación.