Decide-part-zumeta-Votaciones

Grupo 2 
Curso escolar: 2020/2021
Asignatura: Evolución y gestión de la configuración
Milestone en el que se entrega la documentación: M3

Indice

• Miembros del equipo
• Enlaces de interés
• Resumen ejecutivo
• Indicadores del proyecto
• Integración con otros equipos
• Descripción del sistema
• Visión global del proceso de desarrollo
• Entorno de desarollo
• Gestión de incidencias
• Gestión del código fuente
• Gestión de la construcción e integración continua
• Gestión de liberaciones, despliegue y entregas
• Ejercicio de propuesta de cambio
• Conclusiones y trabajo futuro

Implicación de cada miembro en el proyecto

Miembro del equipo	Implicación
Delgado Serrano, Jose	10
Fernández Manzano, Antonio	10
González Díaz, Alejandro	5
Hu, Chao	10
Padilla Molina, Pedro	9
Rodríguez Vidosa, Luis	6

Enlaces de interés:

Sistema desplegado en Heroku

Resumen ejecutivo

En este sistema de votaciones Decide hemos realizado varia cambios para hace una aplicación con múltiples funcionalidades. Para ello hemos pensado ideas para dar diferentes usos a las votaciones y también hemos implementado ideas de otros equipo en conjunto.

Las primeras de todas fueron la creación de una end_date y start_date predefinidas por el admin a la hora de crear la votación. Así no se tiene que preocupar por abrir y cerrar la votación manualmente, si no que cuando crea esa votación define cuando se va iniciar y cuando se va a cerrar y el sistema de ocupará de hacerlo por ti.

Luego vino la implementación de question_prefer y question_ordering. Esta primera fue una implementación que nos pidió el grupo de post-proc pero finalmente decidieron abandonarla pero nosotros dejamos la implementación realizada por si en algún momento fuese necesaria. Ésta manda un campo "YES" en las question en caso de que el admin decide que las question tiene que tener preferencia, las cuales serian asignadas por cabina. Las ordering fue otra idea de poder ordenar las question en un orden diferente al que propone Decide por defecto, así si quieres que la última question de la vista salga la primera en la cabina de votación, solo tienes que indicarlo. Nos falto un equipo con Cabina de votación para poder llegar a ver esto en la vista de booth, pero aún así todo estas implementaciones pueden ser reutilizadas en un futuro por si algún equipo que elije Cabina.

En paralelo a estas se realizo la implementación de age_range conjunto a censo. Esto hace que a la hora del admin crear una votación pueda elegir un rango de edad para esa votación. Así el censo solo tendría que ver ese rango y mirar si los users que se añaden a esa votación cumplen esa restricción.

El equipo de post-proc tambien nos pidió implementar un sistema de candidatos a la votación, para ellos después poder realizar varios algoritmos sobre los datos recogidos de estos candidatos. Para crearlos tuvimos en cuenta el nombre, edad, comunidad, sexo y el partido político y de esta manera ellos podían hacer múltiples implementos.

Luego llegaron la read_only_voting y multiple_voting, donde en la primera una vez creada la votación no podrá ser modificada de ninguna manera. La múltiple_voting como bien dice el nombre se podrá elegir multiples question creadas anteriormente. Estas votaciones no se podrá hacer el tally debido al problema anterior. no contamos con Cabina de votaciones.

También posteriormente se implementó la custom_url y exporta la votacion. El primero te permite crear un votación con la url que deseemos. Al exporta la votación nos creará dos archivos zip después de hacer el tally con los datos de esa votacion.

Finalmente, se decició expandir la funcionalidad de la clase Candidate al dotarla, primero, de una relación con la nueva clase "Party" donde se podían crear nuevos partidos políticos, y después, expandiendo la funcionalidad de estos mismos partidos al enlazarles otra nueva clase llamada Program donde se podían detallar los programas políticos de estos partidos y sus respectivas promesas electorales ("Planks", otra clase más)

Indicadores del proyecto

Miembro del equipo	Horas	Commits	LoC	Test	Issues	Incrementos
Delgado Serrano, Jose	65	19	326	7	16 (6 Incidencias)	1.End Date, 2.Question Ordering, 3.Question Prefer, 4.Candidates, 5.Desplegable comunidades
Fernández Manzano, Antonio	69	10	308	11	16 (5 Incidencias)	1.Question Ordering, 2.Question Prefer, 3.Candidates, 4.Desplegable comunidades
González Díaz, Alejandro	48	8	128	7	5 (1 Incidencia)	1.Party, 2.Program y Planks
Hu, Chao	58	17	195	9	12 (5 Incidencias)	1.Start Date, 2.Age Range
Padilla Molina, Pedro	58	13	300	12	10 (3 Incidencias)	1.Readonly Voting, 2.Multiple Voting
Rodríguez Vidosa, Luis	51	18	102	4	4	1. URLs personalizables 2.Guardado de tally y postprocesado

• Commits: En esta columna pondremos los commits totales de cada miembro en todos las ramas que ha participado.
• LoC (líneas de código): Se contarán todas la líneas de códigos escritas o modificadas en su mayor parte. También se contaran las líneas escritas al realizar los test.
• Test: Se contabilizarán todos los test realizados por cada miembro en las diferentes ramas. También se cuenta el caso en que mas de un miembro haya realizado test sobre la misma implementación, en este caso de contarán los test de forma individual.
• Issues: Contamos tanto las issues de implementación y documentación asignadas a cada miembro como la issues asignadas para las incidencias.
• Incremento: Se pondrá el número de incrementos realizado junto con su nombre, ya que más adelante habrá una pequeña descripción de cada uno.

Evidencias de commits y LoC

Como podemos aprecicar no concuerdan los datos sacados de Insights, ya que éste tiene en cuenta los espacios, imports, comentarios y otras líneas que no sean realmente "código útil". Lo mismo ocurre con los commits ya que tambien cuenta los mergeos entre ramas, que en nuestro equipo no lo hemos contado como commits.

Integración con otros equipos

El equipo de votaciones ha realizado dos implementaciones en conjunto, una con el equipo de censo y otra con el equipo de post-proc. También hemos realizado varias implementaciones que si hubiésemos contado con el equipo de cabina de votaciones se pudiesen haber hecho en conjunto.

• Decide-Part-Zumeta-Post-Proc: Creación de candidatos, con sus atributos necesarios, para que el equipo de post-proc pudiese realizar diferentes recuentos de votos y otros algoritmos necesarios.

• Decide-Part-Zumeto-Censo: Creación de rango de edades para las votaciones, estos datos le llegaran al censo para comprobar que el usuario a votar cumpla las restrinciones del rango.

Descripción del sistema

Decide es una aplicación construida sobre el framework Django basada en una serie de aplicaciones o “apps” que trabajan conjuntamente aunque con cierto grado de aislamiento, de tal forma que pueden ser configuradas por separado.

A continuación voy a listar estas aplicaciones, a la par que dar una descripción de cómo funcionan y de cómo se interrelacionan con las demás.

-Censo

El censo es la parte del sistema en la que se establece qué personas pueden votar en las votaciones, y qué personas no. Esto puede sonar similar al papel de la autentificación, pero no es lo mismo. En la autentificación comprobamos que las personas tengan permisos para acceder a la página web, mientras que en el censo sólo comprobamos que estas personas puedan votar en las correspondientes votaciones que existen.

Estas personas mencionadas tienen que ser, una a una, añadidas al sistema mediante el correspondiente formulario, especificando el id de la votación en el que se quiera que puedan participar, junto al id de la persona que queremos registrar en el censo. El censo es uno de los tres subsistemas de los que se compone nuestro grupo “Decide-Part-zumeta" y por tanto, como parte de nuestro trabajo, hemos tenido que realizar incrementos en colaboración con ellos. Estos incrementos mencionados son listados al final de este apartado.

-Votaciones

El subsistema de votaciones es la parte de Decide en la que ha trabajado nuestro grupo. Por lo tanto, su funcionamiento ha cambiado mucho respecto del que estaba antes de que empezaramos a trabajar en el proyecto.

La clase principal del módulo de Votacion es "voting". Desde ella podemos crear votaciones que constan de un nombre, una descripcion, una pregunta (formada a su vez por varias opciones de respuesta tanto normales como con relacion de orden y preferencia), candidatos políticos que se presentan a las elecciones (con nombre, sexo, partido político, programas políticos, etc), escaños, fechas de comienzo y fin seleccionables a priori, edad minima y máxima para votar, url de auth y URL personalizada opcional. Además de estas votaciones mas completas, hay otros dos tipos mas simples pero que ofrecen sus caracteristicas únicas: unas votaciones que admiten varias preguntas, y otras que una vez creadas no pueden ser editadas.

-Autenticación

Desde este subsistema se realiza la autentificación de los votantes. Esta es una parte fundamental de los subsistemas, y es muy importante que sea segura y sin errores, pues es crucial asegurarnos de que los votantes tengan acceso al sistema y de que no se produzcan errores en el recuento, como por ejemplo en el caso de que los votantes votaran más de una vez ahí.

-Post-procesado

Al igual que ocurría con el censo, esta es una parte de Decide de la que se encargan unos de los grupos que se integran con nosotros. Al terminar la votación, el subsistema de votaciones se relaciona con el subsistema de post procesado para que, en base al recuento anonimizado de las votaciones que recibe del subsistema de mixnet (en forma de dos cadenas de numeros muy largas etiquetadas como “a” y “b”), post procesado devuelva una visualización de los resultados entendible por el usuario. El intercambio de información entre los diferentes subsistemas se realiza mediante lenguaje Json. Además de esto, este subsistema también puede aplicar reglas, como es el caso de las de paridad.

-Visualización de resultados/ visualizer

El propósito de este subsistema es el de ofrecer al usuario la correcta visualización de los resultados recogidos por post procesado. Es el caso, por ejemplo, de cuando ocurre un recuento de votos y se ha de mostrar al usuario el resultado de la votación. Esta visualización ocurre de diversas formas pues, aunque en el caso de las votaciones sea en formato HTML, este subsistema también puede proporcionar el resultado en diversos tipos de archivos.

-Mixnet

En este subsistema, que también se relacionan con el de votación, se realiza un barajado y una posterior desencriptación de los datos encriptados de los votos. Al subsistema llegan dos números enteros larguísimos etiquetados con "a” y “b” como mencioné anteriormente. Estos números son los datos encriptados de la votación y lo primero que se hace con ellos es barajarlos para que no se pueda saber qué usuario ha votado qué opción. Una vez barajados, se desencriptan y posteriormente se hace el recuento, que es lo que finalmente se pasa a post-procesado para su manejo.

-Cabina de votación

Es el subsistema de Decide encargado de mostrar a los usuarios votantes las votaciones que se están llevando a cabo, es decir, la interfaz de usuario a través de la cual el votante vota. Es una interfaz muy sencilla que simplemente muestra las preguntas y las respuestas para que el usuario elija con facilidad la opción que prefiera.

-Store o almacenamiento

En esta parte son almacenados, de forma cifrada, los votos. Esto además nos da la informacion de qué personas han votado y quienes no, aunque no de qué ha votado cada una, pues en tal caso sería absurdo almacenar estos votos de forma cifrada.

Incrementos

Entonces, en base a estos subsistemas, mi equipo ha estado realizando por el momento los siguientes incrementos. Hay incrementos que estaban originalmente planteados y que finalmente no han podido ser llevados a cabo por diversos motivos, entre ellos el haberse encontrado obstáculos como la falta de comprensión de algunos apartados menores del programa o que dichos incrementos requiriesen finalmente realizar integraciones con otros subsistemas que no fueron escogidos por los otros equipos de nuestro grupo para centrarse ellos en esa parte del trabajo.

En todo caso, estos son los incrementos mencionados:

• Predefinir fecha fin de una votación (Realizado por Jose en la Task 002): En este incremento se busca que el administrador que crea las votaciones pueda ser capaz desde el momento de creación de la misma, de predefinir la fecha de finalización, en contrapuesto con lo que ocurre en el programa original donde la fecha de finalización se introduce al realizar su votación manualmente, dificultando la automatización.

• Implementar votaciones de múltiples cuestiones (Intentada por Alejandro y Pedro en la Task 003): (Finalmente esta task no se implementó de esta manera y pasó a ser la Task/011 realizada por Pedro)

• Predefinir la fecha de inicio de la votación (Realizado por Chao en la Task 004): Al igual que ocurría con la task 002, en este incremento se busca que el administrador pueda ser capaz desde el momento de creación de la misma, de predefinir la fecha de inicio de la misma. Hasta el momento, la única forma de iniciar votaciones era realizar su inicio manualmente desde el menú de las votaciones, lo cual no es lo mejor desde el punto de vista de la automatización.

• Creación de URLS configurables para las votaciones(Realizado por Luis en la Task 005): En el programa original, a cada votación se le asigna de forma automática un identificador entero creciente, de forma que la primera votacion creada es la 1, la siguiente la 2, etcétera; y estas se usaran para acceder a la cabina mediante la url: booth/{id}. En este incremento se busca que cada administrador pueda, en el momento de creación de la votación ( o mediante edición posterior) asignarle una url a la votación para acceder a ella en lugar de usar la id.

• Votación por preferencia(Realizada por Jose y Antonio en la Task 006): Implemento que consisten de decidir si la question elegida debe ser de tipo preferencia, donde posteriormente en cabina indicarian los valores de cada preferencia. Inicialmente iba destinada a hacer un incremento junto al equipo de post-proc, pero debido a inconvenientes del equipo post-proc no llegaron a ser usadas por ellos.

• Creación de rango de edad a la hora de crear votaciones (Realizada por Chao en la Task 007, conjunto al equipo de censo): El objetivo de este incremento es el de añadir al modelo de las votaciones dos campos en los que el usuario pueda introducir una edad mínima y máxima para poder votar, que es una funcionalidad que nos había pedido el equipo de censo.

• Votaciones por ordenación del admin (Realizada por Jose y Antonio en la Task 008): Creación de un tipo de question para realizar una votación con una ordenación diferente a la que trae Decide por defecto. A la hora de crear la question, el admin decidirá la posición en la que aparecerá question seleccionada.

• Creación de candidatos (Realizada por Jose y Antonio Task 009, conjunto al equipo de post-proc): Incremento que permite usar decide como plataforma para votaciones políticas, permitiendo crear candidatos políticos, con escaños, partidos, etc y ser añadidos como elementos de las votaciones.

• Votaciones fijas (Realizado por Pedro en la Task 010): Incremento que supone la realización de un tipo de votacion llamadas "Readonly voting" mas cortas que constan de una descripciones más cortas y obligatorias y en las que se no se puede editar ningun apartado de las mismas una vez creadas.

• Creacion de nuevo tipo de votación con preguntas múltiples (Realizado por Pedro en la Task 011): Nueva clase "MultipleVoting" con sus vistas asociadas que permite crear votaciones que tienen varias preguntas, cada una de las cuales con sus respectivas opciones.

• Almacenamiento del tally y postproc en un fichero (Realizado por Luis en la Task 012): la realización de este incremento supone que a partir de ahora el resultado del tally de la votación pueda ser almacenado en un fichero que el usuario pueda guardar y acceder al mismo cuando prefiera.

• Creación de la clase "Party" (Realizado por alejandro en la Task 013). Clase creada para poder añadir partidos políticos no prefirados a los Candidatos, de forma que puedan elegirse más de los que ya aparecían en su lista prefijada.

• Creacion de las clases Program y Plank (Realizado por alejandro en la Task 014). Estas clases son creadas para trabajar, respectivamente, con programas políticos y sus respectivas promesas electorales como elementos que se relacionan con la clase Party.

• Lugar de la votación con un desplegable con las comunidades autónomas de españa (Realizado por Jose y Antonio en la Task 015). Creacion de un nuevo atributo de las votaciones, siendo este un desplegable con las comunidades autónomas de españa, para una futura implementacion con el grupo de censo.

Visión global del proceso de desarrollo

Antes de empezar el proyecto tuvimos que crear dos grupos de la aplicación “WhatsApp” para la comunicación de los diferentes miembros que formamos el proyecto. El primer grupo era para discutir y comunicarse entre los diferentes equipos que constituían el proyecto, por lo que en este grupo estaban todos los integrantes de todos los equipos. Mientras que, en el segundo grupo sólo estaban los integrantes de nuestro equipo (decide-part-zumeta-votaciones) donde principalmente se debatían los problemas surgidos en el transcurso o se planificaba las diferentes fechas para realizar reuniones y revisiones.

Para realizar las reuniones y revisiones mencionadas anteriormente, se creó un servidor común para todos los miembros en la plataforma “Discord” y de allí se dividieron en un canal general para todos los miembros y otros tres canales donde cada uno pertenecería al canal de su equipo. Una vez dentro del canal es donde se realizaban las reuniones y actividades en conjunto. Para una organización más eficiente y organizada, se propuso la idea de escoger dos representantes por cada equipo ya que era muy difícil conseguir que todos los miembros estuvieran disponibles en la misma franja horaria y aunque se diera el caso, organizar una reunión con tantas personas es más fácil pisarse unos con otros y sería contraproducente. En caso de que alguno más quisiera estar en la reunión grupal, podría estar, pero cumpliría más la función de oyente.

Todos los miembros del equipo debíamos tener una configuración similar para trabajar en el mismo proyecto. Los miembros del equipo podían optar por diferentes opciones, la más recomendable y eficiente es partir de un sistema operativo Linux, otra opción muy acertada sería utilizar el subsistema de Windows para Linux, y por última opción se podría instalar una máquina virtual básica para el proyecto.

Para una buena integración con los diferentes equipos y mantener todos los miembros una misma estructura, se contempló una metodología basada en GitFlow. Donde existen dos ramas principales (master y develop), a partir de develop nos creamos una rama para cada equipo el cual en nuestro caso llamamos “decide-part-zumeta-votaciones” y a partir de allí se crearon las ramas a los correspondientes incrementos propuestos.

Una vez se contempla un posible incremento primero se identifica y se documenta como una “issue” del proyecto para que se quede reflejado, se diferencian entre sí dado que algunas tienen dependencias entre ellas o entre otros equipos. El cambio se le asignaría a uno o varios miembros del grupo y se establecería una fecha límite. Esta fecha puede variar dependiendo de su prioridad, es decir, si el cambio tiene dependencias con otras tareas también va a tener más prioridad y una fecha límite más cercana.

El cambio siempre es debatido y aprobado por los miembros del equipo antes de entrar en la fase de implementación. En esta fase es cuando se realizan los cambios pertinentes al código de las ramas predefinidas, una vez acabada se realizan tests sobre el código donde se comprueba que el incremento realizado cumple su función y no genera errores a la hora de ejecutar la aplicación. Después de comprobarlo todo se mergea la rama, donde se han ejercido los cambios, con la rama “decide-part-zumeta-votaciones” y a partir de ella se mergea con la rama “develop” del trabajo. A continuación, ya se seguiría la metodología de GitFLow.

Entorno de desarollo

Debido a que cada miembro del equipo trabaja con sus propios medios tenemos varios entornos de desarrollo diferente, todos ellos cuenta con Python. Por ello usamos : WSL2, Linux nativo y maquina virtual básica con putty.

-WSL2

Es un entorno que usan los miembros Jose Delgado y Chao Hu.

Para instalarlo tenemos que seguir los pasos del siguiente post de Microsoft https://docs.microsoft.com/es-es/windows/wsl/install-win10. También deberemos descargarnos desde la tienda de Microsoft la versión de Ubuntu deseada, en este caso hemos elegido Ubuntu 20.04 LTS, desde aquí https://www.microsoft.com/en-us/p/ubuntu-2004-lts/9n6svws3rx71?activetab=pivot:overviewtab. Todo esto también nos lo explican en el primer post de Microsoft

Lo primero que tendremos que hacer es descargar VisualCode. Una vez lo tengamos, instalamos la extensiones como el interprete de python además de aquellas que suelas utilizar por comodidad. En la esquina derecha de VsCode nos saldrá la opción de abrir el entorno de WSL2 y VsCode prepara el entorno para su correcto funcionamiento.

Nos dirigimos al directorio raíz y creamos una carpeta para meter el proyecto. Dentro de esa carpeta hacemos git clone https://github.com/marcascal2/decide-part-zumeta.git.

Una vez aquí podemos crear el entorno virtual de Python, version-3.6, con el comando python3 -m venv enviorement_name y posteriormente lo lanzamos con source enviorement_name/bin/activate. A continuación buscamos el archivo requeriments.txt y pasamos a instalarlo con pip3 install -r requeriments.txt.

Cuando tengamos el entorno configurado necesitaremos la base de datos, para ello usaremos postgresSQ. Primero iniciamos el servidor con sudo service postgresql start, entramos en él con sudo -su postgres y creamos tanto la base de datos,psql -c "create database decide owner decide", como el super usuario psql -c "create user decide with password 'decide'".

Finalmente con todo listo hacemos la migración para preparar la base datos, para ellos vamos a la carpeta decide y ejecutamos ./manage.py migrate y lanzamos el proyecto con ./manage.py runserver.

-Linux Nativo

Es un entorno que usan los miembros Antonio Fernández y Alejandro González Díaz

Para ello contamos con el sistema por defecto es Linux, en este caso ha sido la versión 20.04.1 LTS. Creamos una carpeta donde mejor nos convenga y dentro hacemos git clone https://github.com/marcascal2/decide-part-zumeta.git.

Una vez aquí podemos crear el entorno virtual de Python, version-3.6, con el comando python3 -m venv enviorement_name y posteriormente lo lanzamos con source enviorement_name/bin/activate. A continuación buscamos el archivo requeriments.txt y pasamos a instalarlo con pip3 install -r requeriments.txt.

Cuando tengamos el entorno configurado necesitaremos la base de datos, para ello usaremos postgresSQ. Primero iniciamos el servidor con sudo service postgresql start, entramos en él con sudo -su postgres y creamos tanto la base de datos,psql -c "create database decide owner decide", como el super usuario psql -c "create user decide with password 'decide'".

Finalmente con todo listo hacemos la migración para preparar la base datos, para ellos vamos a la carpeta decide y ejecutamos ./manage.py migrate y lanzamos el proyecto con ./manage.py runserver.

-Maquina virtual básica con putty

Este entorno de desarrollo ha sido usado por los miembros Pedro Padilla y Luis Rodríguez Vidosa,

Para este entorno hemos requerido de maquinas virtuales, que en nuestro caso a sido gracias VirtualBox, con putty y una carpeta compartida. Primero instalamos VirtualBox con la versión 6.0, también necesitaremos la imagen del sistema que en este caso será Ubuntu 20.04 server. Con todo esto preparado creamos una máquina virtual en VirtualBox con al menos un 1GB de RAM y 20GB de almacenamiento, pasamos a añadirle la unidad óptica de Ubuntu y dejamos marcada la opción de instalar un servidor openSHH.

A continuación descargamos Putty, abrimos la configuración de puertos de VirtualBox donde abriremos el puerto SHH y el 8000 para posteriormente desplegar decide. Desde Putty ingresamos la configuración Host: localhost y Port:"pondremos el puerto SHH".

Por último pasamos a compartir una carpeta con la máquina virtual. Desde VirtualBox habilitamos esta opción y creamos esa carpeta, despues desde la maquina con SHH ejecutamos los siguientes comandos sudo apt-get update, sudo apt-get install virtualbox-guest-dkms, sudo apt-get install virtualbox-guest-utils y añadimos el usuario usermod -aG vboxsf username. Finalmente reiniciamos y ya todo debería funcionar, ahora todo cambio realizado se verá reflejado en ambos lados.

Ahora pasamos a usar VisualCode donde abriremos la carpeta compartida con la maquina virtual donde ya podremos realizar nuestras modificaciones.

Una veza ahí nos dirigimos al directorio raíz y creamos una carpeta para meter el proyecto. Dentro de esa carpeta hacemos git clone https://github.com/marcascal2/decide-part-zumeta.git.

Una vez aquí podemos crear el entorno virtual de Python, version-3.6, con el comando python3 -m venv enviorement_name y posteriormente lo lanzamos con source enviorement_name/bin/activate. A continuación buscamos el archivo requeriments.txt y pasamos a instalarlo con pip3 install -r requeriments.txt.

Cuando tengamos el entorno configurado necesitaremos la base de datos, para ello usaremos postgresSQ. Primero iniciamos el servidor con sudo service postgresql start, entramos en él con sudo -su postgres y creamos tanto la base de datos,psql -c "create database decide owner decide", como el super usuario psql -c "create user decide with password 'decide'".

Finalmente con todo listo hacemos la migración para preparar la base datos, para ellos vamos a la carpeta decide y ejecutamos ./manage.py migrate y lanzamos el proyecto con ./manage.py runserver.

Gestión de incidencias

Para la gestión de incidencias distinguimos entre dos apartados: incidencias internas (las de nuestro equipo de trabajo) e incidencias externas (las que afectan a otros subsistemas). Para ambos tipos de incidencias usaremos el tablero de Zenhub que es especialmente útil y representativo para saber si ha ocurrido algún problema con las tareas repartidas. En este tablero añadimos las tareas tanto de documentación como de programación. También, como se ha dicho anteriormente, contamos con dos grupos de WhatsApp: uno general para todos los subgrupos y uno específico para las votaciones y, como tambien se dijo, con un servidor de Discord con varios canales: un canal de texto y voz general y canales de voces y texto específicos para cada subgrupo. Ambas herramientas las usaremos para notificar las incidencias que vayamos encontrando y solucionando a lo largo del proyecto como viene definido en los procesos de los siguientes apartados.

Zenhub

Incidencias internas

Cuando tengamos que gestionar una incidencia, si el fallo es debido a algún miembro del equipo de desarrollo, crearemos una nueva "Issue" donde se especificarán los miembros relacionados con la incidencia.

A continuación se detalla el proceso que se debe seguir para una incidencia que afecte a nuestro subsistema:

• Primero: un miembro descubre un fallo que afecta a nuestro subsistema, independientemente de si es un fallo en la aplicación o los test de Travis, el usuario creará una "Issue" en el Zenhub del repositorio "decide-part-zumeta" con el título "Error Votaciones" o asignarlo en el milestone del grupo correspondiente con una breve descripción del problema ocurrido. Esta descripción vendrá seguida del error que aparece y, si la hubiese, una posible solución al problema.
• Segundo: se les notificará por el grupo de WhatsApp (el del subgrupo) y por el Discord (en el canal de texto del subgrupo votaciones) a las personas encargadas de resolver este fallo, normalmente la/s persona/s seleccionadas serán las que han producido o descubierto el fallo en cuestión y contarán con la "Issue" en Zenhub para guiarse (donde podrán ver el error que produce el fallo en la mayoría de ocasiones).
• Tercero: estas personas intentarán solucionar el problema en cuestión y una vez resuelto, avisarán al resto del equipo para que revisen si se ha solucionado correctamente.
• Cuarto: si estas personas no son capaces de solucionar el fallo, tendrán que notificarlo al subgrupo por WhatsApp o Discord y se les buscará ayuda (más personas que se añaden a las que lo estaban resolviendo anteriormente o se sustituyen las personas que estaban solucionando el fallo por otras)
• Quinto: una vez estas personas hayan solucionado el problema, se cerrará la "Issue" y se le añadirá la solución que se ha usado para resolver el problema, bien en la descripción de la "Issue", o bien en el commit donde se haya solucionado el problema.
• Sexto: se notificará al resto del subgrupo por WhatsApp o Discord de que el problema ya ha sido solucionado.

A continuación se detalla el proceso que se debe seguir para una incidencia que afecte a nuestro subsistema que nos haya derivado otro subgrupo:

• Primero: un miembro de otro subgrupo descubre un fallo que afecta a nuestro subsistema, independientemente de si es un fallo en la aplicación o los test de Travis, el usuario creará una "Issue" en el Zenhub del repositorio "decide-part-zumeta" con el título "Error Votaciones" o asignarlo en el milestone del grupo correspondiente con una breve descripción del problema ocurrido. Esta descripción vendrá seguida del error que aparece y, si la hubiese, una posible solución al problema.
• Segundo: se les notificará por el grupo de WhatsApp (el del subgrupo) y por el Discord (en el canal de texto del subgrupo votaciones) a nuestro subgrupo y seleccionaremos de nuestro subgrupo a la/s persona/s que serán las encargadas de solucionar el fallo en cuestión y contarán con la "Issue" en Zenhub para guiarse (donde podrán ver el error que produce el fallo en la mayoría de ocasiones).
• Tercero: estas personas intentarán solucionar el problema en cuestión y una vez resuelto, avisarán a su subgrupo para que revisen si se ha solucionado correctamente, también avisarán al subgrupo que encontró el fallo para que revisen si les continua ocurriendo.
• Cuarto: si estas personas no son capaces de solucionar el fallo, tendrán que notificarlo al subgrupo por WhatsApp o Discord y se les buscará ayuda (más personas que se añaden a las que lo estaban resolviendo anteriormente o se sustituyen las personas que estaban solucionando el fallo por otras)
• Quinto: una vez estas personas hayan solucionado el problema, se cerrará la "Issue" y se le añadirá la solución que se ha usado para resolver el problema, bien en la descripción de la "Issue", o bien en el commit donde se haya solucionado el problema.
• Sexto: se notificará al subgrupo que encontró el fallo y al propio por WhatsApp o Discord de que el problema ya ha sido solucionado.

Incidencias externas

La forma de gestionar las incidencias externas no difiere mucho de la anterior. Teniendo en cuenta que compartimos repositorio con el resto de grupos "decide-part-zumeta", podemos crear "Issues" que afecten a varias personas de grupos distintos. De esta forma se puede conocer los miembros del grupo con los que hay problemas y, de la misma manera, los subgrupos afectados en estos.

A continuación se detalla el proceso que se debe seguir para una incidencia que involucra a varios subgrupos:

• Primero: un miembro descubre un fallo que involucra a varios subgrupos, este miembro creará una "Issue" en el Zenhub del respositorio "decide-part-zumeta" con el título "Error Votaciones-XXXX", siendo XXXX el otro subgrupo afectado por el problema (Censo o Postprocesado) o asignarlo en los milestone de los grupos correspondientes, con una breve descripción del problema ocurrido. Esta descripción vendrá seguida del error que aparece y, si la hubiese, una posible solución al problema.
• Segundo: se les notificará por el grupo de WhatsApp (el general, no el del subgrupo) y por el Discord (en el canal de texto general) a las personas encargadas de resolver este fallo, normalmente la/s persona/s seleccionadas serán las que han producido o descubierto el fallo en cuestión y contarán con la "Issue" en Zenhub para guiarse (donde podrán ver el error que produce el fallo en la mayoría de ocasiones).
• Tercero: estas personas intentarán solucionar el problema en cuestión y una vez resuelto, avisarán al equipo completo del proyecto para que revisen si se ha solucionado correctamente.
• Cuarto: si estas personas no son capaces de solucionar el fallo, tendrán que notificarlo al equipo completo por WhatsApp o Discord y se les buscará ayuda (más personas que se añaden a las que lo estaban resolviendo anteriormente o se sustituyen las personas que estaban solucionando el fallo por otras).
• Quinto: una vez estas personas hayan solucionado el problema, se cerrará la "Issue" y se le añadirá la solución que se ha usado para resolver el problema, bien en la descripción de la "Issue", o bien en el commit donde se haya solucionado el problema.
• Sexto: se notificará al resto del grupo completo por WhatsApp o Discord de que el problema ya ha sido solucionado.

A continuación se detalla el proceso a seguir para una incidencia relativa a otro subgrupo que no sea el de "Votaciones":

• Primero: un miembro descubre un fallo que involucra a otro subgrupo, este miembro creará una "Issue" en el Zenhub del respositorio "decide-part-zumeta" con el título "Error XXXX", siendo XXXX el subgrupo afectado por el problema (Censo o Postprocesado) o asignarlo en el milestone del grupo correspondiente, con una breve descripción del problema ocurrido. Esta descripción vendrá seguida del error que aparece y, si la hubiese, una posible solución al problema.
• Segundo: se les notificará por el grupo de WhatsApp (el general, no el del subgrupo) y por el Discord (en el canal de texto general) al subgrupo involucrado en este fallo, el subgrupo en cuestión seleccionará a la/s persona/s que se encargarán de solucionar el fallo en cuestión y contarán con la "Issue" en Zenhub para guiarse (donde podrán ver el error que produce el fallo en la mayoría de ocasiones).
• Tercero: estas personas intentarán solucionar el problema en cuestión y una vez resuelto, avisarán a su subgrupo para que revisen si se ha solucionado correctamente, también avisarán al subgrupo que encontró el fallo para que revisen si les continua ocurriendo el fallo encontrado.
• Cuarto: si estas personas no son capaces de solucionar el fallo, tendrán que notificarlo al subgrupo por WhatsApp o Discord y se les buscará ayuda (más personas que se añaden a las que lo estaban resolviendo anteriormente o se sustituyen las personas que estaban solucionando el fallo por otras).
• Quinto: una vez estas personas hayan solucionado el problema, se cerrará la "Issue" y se le añadirá la solución que se ha usado para resolver el problema, bien en la descripción de la "Issue", o bien en el commit donde se haya solucionado el problema.
• Sexto: se notificará al subgrupo que encontró el fallo y al propio por WhatsApp o Discord de que el problema ya ha sido solucionado.

Un ejemplo de una "Issue" creada para una incidencia, en este caso una incidencia interna:

Ejemplo issue incidencia

Para resolver dichas incidencias, las personas encargadas deben crearse una rama partiendo de la rama donde esta el fallo. El formato para el nombre de la rama es:

incidencia/#XX/NombrePersonas

donde, "#XX" es el código de Zenhub para la "Issue" creada para la incidencia y "NombrePersonas" es el nombre de la/s persona/s encargadas de resolver la incidencia.

Si esta/s persona/s desean resolver varias incidencias en una misma rama, deben encadenar los códigos de Zenhub de la forma: "#XX#YY".

Las incidencias que se detecten en una rama "task" podrán ser resueltas sin crear otras ramas, si la/s persona/s encargadas de la tarea son los especificados en NOMBRES: "task/XXX/NOMBRES" sin necesidad de crear una rama a parte. Deben crear la "Issue" en Zenhub obligatoriamente.

Incidencias creadas por los miembros del equipo

Miembro del equipo	Código Incidencia en Zenhub	Persona/s Asignada/s	Descripción	Solución
Delgado Serrano, Jose	#69	Delgado Serrano, Jose	Error al realizar los tests por defecto de decide y se obtenía el error NoneType object is iterable	Añadir una comprobación en el modelo para que en caso de que el atributo sea nulo no lo recorra
Delgado Serrano, Jose	#71	Fernández Manzano, Antonio	Error al realizar los tests por defecto de decide. Se obtenía los errores "Candidate matching query does not exit" y "NotNullViolation"	Introducir la variable escanios a los tests. Inicializar el objeto candidato
Delgado Serrano, Jose	#83	Fernández Manzano, Antonio	Error con los test después de mergear todas las implementaciones realizadas en la rama decide-part-zumeta-votaciones. Se observan varios errores posiblemente debido a diferentes dependencias entre las nuevas implementaciones.	Se añadieron los atributos y relaciones faltantes al código
Delgado Serrano, Jose	#119	Hu, Chao	Error a la hora de confirmar fecha sin fecha de inicio predefinida	Se añadió una comprobación con la fecha de inicio para que pueda ser nula
Fernández Manzano, Antonio	#67	Fernández Manzano, Antonio	Error al realizar los tests por defecto de decide y se obtenía el error NoneType object is iterable	Comprobar previamente que el atributo no es nulo
Fernández Manzano, Antonio	#73	Delgado Serrano, Jose	Al realizar los test del módulo store se obtenía el siguiente fallo: no null violation constraint. Esto es debido a que el atributo escanios no puede ser nulo.	Se modifcaron los test del módulo store para añadir el atributo escanios
Fernández Manzano, Antonio	#84	Delgado Serrano, Jose	Error con el valor por defecto de los escaños.A la hora de realizar los tests, el sistema devuelve 19 fallos. Esto es debido al valor nulo de escaños. Una posible solucion es añadirle un valor por defecto a la variable. Se ha comentado con el sisitema de postprocesado puesto que es la integración con ellos, y han dado su aprobación.	Añadir valor por defecto a la variable
Fernández Manzano, Antonio	#86	Hu, Chao	Al introducir una edad máxima menor que la edad mínima el sistema no devuelve un error	Realizar la validación el save en lugar de con un validator
Fernández Manzano, Antonio	#87	Hu, Chao	Al predefinir la fecha de inicio en una votación, la votación no se lanza correctamente y no deja acceder a la vista de votación	Añadir una acción nueva que confirmara la fecha y cree la clave pública asociada a la votación
Fernández Manzano, Antonio	#88	Hu, Chao	Se obtuvo el error al lanzar el test de fecha de inicio e la api: null value escanios Violation constraint. El error es debido a que no se añadía un valor a la variable	Modificar los tests añadiendo la variable escanios con un valor
González Díaz, Alejandro	134	González Díaz, Alejandro	Error Program no serializable	Cambiar "Program Serializer" a False
Hu, Chao	#64	Hu, Chao	Error a la hora de crear votaciones en decide cuando no está definido el min_age y el max_age se obtiene un "server error"	Se introdujo una sentencia if para comprobar que el atributo sea nulo
Hu, Chao	#65	Delgado Serrano, Jose. Fernández Manzano, Antonio	Error a la hora de crear una votación con preferencias en el entorno decide. A la hora de crear una cuestión con preferencias en el entorno decide se obtenía un "server error"	Se modificó el atributo prefer, de un BooleanField a un TextField
Hu, Chao	#77	Delgado Serrano, Jose	Error a la hora de comprobar los tests predefinidos lanza el error "NotNullViolation"	Añadir posibilidad de atributos en blanco para end_date
Padilla Molina, Pedro	#76	Hu, Chao	Error Votaciones falla un test al crear votaciones readonly (ERROR: str object is not callable)	Comprobar objeto bien definido y ver que no lo estaba
Padilla Molina, Pedro	#82	Padilla Molina, Pedro	Error Votaciones Readonly voting no hace el tally correctamente	Eliminando el tally del desplegable en "admin.py"
Padilla Molina, Pedro	#81	Padilla Molina, Pedro	Error Votaciones Multiple votings no hace el tally correctamente	Eliminando el tally del desplegable en "admin.py"
Padilla Molina, Pedro	#140	Padilla Molina, Pedro	Error Votaciones coverage bajo	Crear nuevos tests y comentar cierto código que no se usa

Gestión del código fuente

Gestión global

El equipo decide-part-zumeta decidió en consensos realizar un repositorio común para los tres grupos que trabajarán juntos. El código se gestionará utilizando metodología GitFlow de la siguiente forma:

• Se creará una rama develop a partir de la cual se usará para las distintas modificaciones e incrementos que cada grupo crea necesario realizar.
• Se creará una rama principal para cada grupo a partir de la rama develop, como una rama develop secundaria. Esta rama llevará el nombre del equipo en cuestión. En nuestro caso, la rama se llama decide-part-zumeta-votaciones.
• Se crearán las distintas ramas que cada grupo necesite a partir de la rama principal de cada proyecto. El formato a utilizar para las ramas lo decide cada equipo.

Una vez todos los equipos terminen sus tareas, se mergeará todo el código a las ramas principales de cada equipo y se comprobará que no aparentan fallos. Desde cada rama, se mergeará a la rama develop previa subida a la rama master como código final. En caso de necesitar arreglar algún fallo, se creará una rama para cada bug encontrado que presente una magnitud elevada, dejando a cada equipo su manejo y control.

Gestión interna

En cuanto al equipo de Votaciones en cuestión, se trabajará utilizando en la medida de lo posible pair programming, es decir, programación en parejas. Se ha utilizado una metodología de nombramiento de ramas que sigue la siguiente estructura:

• task/XXX/personasimplicadas.

Siendo _XXX _el número de la tarea, y personasimplicadas las iniciales de las personas que realizarán dichas tareas. El nombre de la rama debe coincidir con las issues creadas para un mejor control y conocimiento sobre qué se esta realizando en dicha rama.

Como hemos comentado anteriormente, para cada funcionalidad se creará una rama. ¿Cuándo realizar un commit en esa rama?

El equipo de Votaciones ha fijado que, para realizar un commit, el incremento que desee subir debe estar al 80% de su implementación y no debe tener fallos que puedan afectar al proyecto. En el caso de las tareas que hayan sido asignadas a una pareja, los commit quedan a disposición de dicha pareja que organizará y gestionará su uso. Se utilizará una plantilla de commits definida y subida al repositorio que muestra la siguiente estructura:

• (TIPO)Título descriptivo (no más de 50 palabras)
• Cuerpo del commit donde se explica por qué y para qué se realiza el commit. Conveniente también indicar qué partes del código se ha modificado.

Finalmente, para cada rama debe haber una Issue previamente creada que seguirá la misma metodología de nombramiento que las ramas. Cada Issue debe estar asignada a un milestone y al proyecto del equipo correspondiente. Una Issue creada correctamente debe incorporar también una estimación acorde a su dificultad, una etiqueta acorde a su funcionalidad y las personas asignadas que coincidirá con las personas que realicen commits a dichas ramas. Las Issues deberán estar en Sprint Backlog inicialmente, y se deberán mover a la columna In progress para un mejor control de las implementaciones.

Gestión de integración con otros equipos

Para integrar una funcionalidad que dependa de otra funcionalidad de otro equipo, se gestionará siguiendo los pasos siguientes:

1. Acuerdo entre ambos equipos sobre qué tarea tiene prioridad
2. Creación de Issue y rama para la primera tarea. Esta rama e Issue seguirá la nomenclatura fijada por el equipo que la cree.
3. Realización de la tarea en el tiempo fijado por el equipo dependiente.
4. Los miembros del equipo dependiente crearán una rama a partir de la rama de la tarea finalizada. Esta rama se utilizará para realizar la implementación necesaria que complemente la integración.
5. Una vez terminada la integración, se mergeará todo a una sola rama, y cada equipo hará un merge a la rama principal de cada uno.
6. Se cierran las Issues creadas.

Ejemplos

Un ejemplo de la gestión del equipo de Votaciones podemos verla en el commit https://github.com/marcascal2/decide-part-zumeta/commit/1ee193deec3126ad70f0c516a1fb770b81bc4c8b donde Jose Delgado Serrano realizó un commit utilizando la plantilla especificando el tipo de commit que realizaba (BUG) y una breve descripción del mismo. Como vemos también, este commit se realizó en la rama task/009/josAnt, una rama para la tarea por parejas de Jose Delgado y Antonio Fernández, en la que ambos realizaron commits. La Issue task/009/josAnt describe la funcionalidad que se implementa en esta rama.

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

Respecto a la construcción del proyecto cabe mencionar las tres ramas de cada equipo creadas a partir de la rama develop (decide-part-zumeta-votaciones, decide-part-zumeta-censo y decide-part-zumeta-post procesado). Una vez que estas tres ramas tengan sus respectivas funcionalidades implementados y funcionando. Éstas se mergean en develop, se comprueba entre todos los miembros y posteriormente se mergea develop con master.

Respecto a la integración continua la herramienta utilizada es Travis CI, dado que proporciona el servicio de integración continua para proyectos software ubicados en GitHub. Éste comprueba que los tests de la aplicación se realizan correctamente cada vez que se realice alguna modificación en la rama correspondiente. Con ello se obtiene estos datos de forma continua y se facilita el trabajo de encontrar bugs o fallos del programa. Así se simplifican procesos posteriores ya que encontrar y resolver un fallo siempre es más conveniente que se realice en una fase temprana del proyecto, obteniendo una mejora en el uso de los recursos y del tiempo empleado. Teniendo cierta seguridad en el funcionamiento del código a la hora de realizar un “build”, y ya desde allí podríamos saber si dicho build tuvo éxito o no.

En cuanto al despliegue de la aplicación en la nube se ha escogido la herramienta Heroku. Puesto que es una herramienta fácil de desplegar y no supone un gasto mayor para el proyecto, aunque debe ser cuidadoso en este tema. Soportando una multitud de lenguajes de programación. Y el despliegue se realizará después del procedimiento mencionado anteriormente, es decir, una vez ya habiendo pasado todos los tests y que estos mismos se ejecuten perfectamente también en la herramienta de integración cotinua Travis CI.

Indicadores de calidad

1. No se encuentra código muerto: no debe haber imports, variables o funciones que no se utilicen
2. No se encuentra código duplicado: no debe haber dos sitios donde se realice la misma función, es decir, se extrae para crear una función donde posteriormente se llamará desde el sitio donde se necesite. Así se evita códigos ilegibles o difíciles de comprender.
3. Intentar declarar las variables antes de entrar en un bucle, para así no crearlo en cada iteración del bucle.
4. Éxito en superar los tests predefinidos y los nuevos creados, los miembros del equipo han creado nuevos tests para comprobar las nuevas funcionalidades que se han creado de los incrementos.
5. Intentar no aumentar la complejidad cilomática del proyecto inicial, para un mejor rendimiento del código.

Gestión de liberaciones, despliegue y entregas

En este apartado se detallan los procesos a seguir para la gestión de las liberaciones, despliegue y entregas que se realizarán en el proyecto.

Gestión de liberaciones y despliegue

Para la gestión de las liberaciones y despliegue se usará la herramienta Heroku, la cual nos ofrece "Plataformas como servicios" y es bastante intuitiva permitiéndonos despreocuparnos de cualquier tarea de mantenimiento de infraestructura.

Información Heroku

Licencia de Heroku: usa el sistema operativo basado en Debian Ubuntu. Soporta PHP, Java, Python y otros lenguajes de programación. Para desplegar nuestro proyecto funcionando correctamente, la herramienta nos da "piezas fundamentales" para el modelo llamadas "Dynos". Cada "dyno" se aisla del resto por lo que los comandos que se ejecutan no afectan a otros. Todo esto se almacena en un archivo denominado "_Procfile _". Usaremos para nuestro proyecto una gama de productos que nos ayudarán en el despliegue, en concreto nosotros usaremos "Heroku Postgres" que es necesario para nuestra base de datos.

Fases para el despliegue en Heroku:

• Primero: mergeamos todas las ramas del proyecto en la rama "decide-part-zumeta" y, una vez registrados en la web, iniciaremos sesión en la plataforma y veremos los proyectos que tenemos desplegados.

Si queremos desplegar la aplicación desde la web:

• Segundo: creamos la nueva aplicación desde la web asociando nuestra cuenta de "GitHub" y seleccionamos el proyecto "decide-part-zumeta". Podemos usar una opción que permita esperar a que se hayan pasado todas las pruebas de integración continua, para nosotros las pruebas de "Travis".

Si queremos desplegar la aplicación desde el terminal:

• Segundo: usamos el comando "heroku create NOMBRE_APLICACION", donde "NOMBRE_APLICACION" es el nombre que queremos para la nueva aplicación.
• Tercero: usamos el comando "heroku git:remote -a NOMBRE_APLICACION", donde "NOMBRE_APLICACION" es el nombre que hemos usado antes para crear nuestra aplicación
• Cuarto: con estos comandos ya se ha creado nuestra aplicación y solo nos falta crear un archivo llamado "Procfile" en nuestro proyecto donde se definen varias partes importantes de nuestro proyecto.
• Quinto: debemos modificar el archivo "settings.py" añadiendo la url de la aplicación en heroku.
• Sexto: tenemos que añadir las dependencias con heroku en el archivo "requirements.txt".
• Séptimo: usamos el comando "git push heroku master" para enviar el despliegue.
• Octavo: para conectarnos a la app usamos el comando: "heroku run -a NOMBRE_APLICACION", para que este comando funcione correctamente debemos crear un superuser que nos permita hacer nuestra labor de administrador.

Para las pruebas usamos "Travis", con lo mencionado anteriormente ya estará configurado para funcionar adecuadamente con Heroku y realizar las pruebas directamente.

Travis

Gestión de entregas

El equipo en su conjunto será el encargado de llevar las entregas al día, será el Project Manager el encargado de realizarlas a través de la Enseñanza virtual en las fechas que serán detalladas más abajo. Las entregas deben tener el avance que ha realizado el equipo para el proyecto junto con la documentación, que incluyen las actas de reuniones. Estos documentos vienen especificados en la "Wiki" del repositorio de "Github" llamado "decide-part-zumeta".

Enseñanza Virtual Universidad de Sevilla

Github - Wiki - decide-parte-zumeta

Se han de realizar cinco entregas detalladas a continuación:

• Milestone cero (M0): la fecha es el 30 de octubre de 2020. En esta primera entrega los miembros del equipo se registran en la plataforma de la asignatura como grupo para que se les asigne un tutor de proyecto así como para empezar a concretar que trabajaríamos en la parte de decide de votaciones.
• Milestone uno (M1): la fecha es el 6 de noviembre de 2020. En esta segunda entrega se creará el "Acta fundacional" donde el equipo pone las condiciones que se acuerdan entre los desarrolladores de cara al proyecto. También se crea un vídeo donde se muestra el proyecto instalado en el equipo, en nuestro caso el sistema Decide desplegado y pasando las pruebas. El equipo debe decidir finalmente la parte de Decide sobre la que va a trabajar, en nuestro caso desde el "Milestone cero" ya teníamos más o menos claro que sería sobre la parte de "Votaciones". Para terminar, planificamos y realizamos los incrementos correspondientes.
• Milestone dos (M2): la fecha es el 7 de enero de 2021. Este milestone es un seguimiento del trabajo realizado y este no debe estar completo pero si se debe haber desarrollado el ochenta por ciento del trabajo final de los incrementos. Con este seguimiento el equipo conocerá cuáles deben ser los cambios que deben realizar y las partes que deben mejorar de cara al entregable final. También el equipo sabrá si el avance es el adecuado o van retrasados.
• Milestone tres (M3): la fecha es entre el 18 y el 29 de enero de 2021. Se realiza la defensa final del proyecto que debe estar terminado y desplegado en la nube, el día de la defensa será en un horario disponible del tutor asignado al proyecto. Cuando se entregue el proyecto no se podrá modificar nada hasta la defensa. Esta defensa consistirá en una prueba en la que el tutor podrá realizar cualquier preguntar sobre el sistema a la que los desarrolladores deben contestar de manera correcta. Todos los integrantes tendrán en su máquina el sistema funcionando y preparado para realizar cualquier tipo de prueba.
• Milestone cuatro (M4): la fecha es el 5 de febrero de 2021. Es el día de la convocatoria oficial de febrero de la asignatura en la cual tienen lugar las mejoras del proyecto. Si no se superan los requisitos mínimos del desarrollo del proyecto en la entrega anterior o querer mejorarlo se realizan cambios en él para que los miembros del equipo entreguen un proyecto y, por lo tanto, un producto de mejor calidad que el que se entregó en el "Milestone tres".

Usaremos la nomenclatura "vX.Y.Z" en GitHub, donde X, Y, Z son tres números que identifican la versión en la que se encuentra el proyecto.

Ejercicio de propuesta de cambio

Ahora explicaremos la metodología a seguir para realizar un cambio: El esquema a seguir para realizar un cambio de tipo incremento en el proyecto es el siguiente:

1. Crear la issue y asignarla a un miembro del equipo. La issue tendrá el formato de task/XXX/miembros.
2. El miembro asignado la actualiza a la columna In progress.
3. Actualizar el repositorio.
4. Generar la nueva rama feature para el cambio. La rama tendrá el mismo nombre que la issue.
5. Generar el entorno virtual, instalar los requisitos y realizar las migraciones.
6. Lanzar las pruebas.
7. Hacer los cambios oportunos.
8. Hacer los test necesarios y relanzar las pruebas.
9. Hacer add de los cambios.
10. Hacer commit de los cambios.
11. Hacer push de los cambios.
12. Comprobar que el cambio pasa los test de travis.
13. Merge de las ramas a la rama principal.
14. Pasar la issue del cambio a la columna Done.

El esquema a seguir para realizar un cambio de tipo incidencia en el proyecto es el siguiente:

1. Crear la issue y asignarla a un miembro del equipo. La issue tendrá el formato Error... y un título descriptivo del error/incidencia.
2. El miembro asignado la actualiza a la columna In progress.
3. Actualizar el repositorio.
4. Generar la nueva rama feature para el cambio. La rama tendrá el formato Incidencia/#XXX/Miembro(s)
5. Generar el entorno virtual, instalar los requisitos y realizar las migraciones.
6. Lanzar las pruebas.
7. Aislar el error descrito en la incidencia.
8. Analizar las posibles soluciones descritas en la incidencia creada.
9. Solucionar la incidencia.
10. Hacer los test necesarios y relanzar las pruebas.
11. Hacer add de los cambios.
12. Hacer commit de los cambios.
13. Hacer push de los cambios
14. Comprobar si la rama pasa los test de travis
15. Mergear con la rama principal.
16. Actualizar la issue pasándola a la columna Done

En primer lugar, vamos a realizar el incremento de modificar el atributo descripción de la votación para que sea máximo de 20 caracteres.

1. Se crea la issue en github y se asigna. Supongamos que es la 128 y se le asigna a Chao y Luis. En este caso sería:

Título: Task/128/ChaLui

Descripicón: Modificar el atributo descripción de la votación para que sea máximo de 20 caracteres.

Labels: enhancement

Asignado: luirodvid, ChaoHu99

2. Luis o Chao cuando comienzan su tarea, pasan la issue a la columna In Progress.

3. Actualizar nuestra rama decide-part-zumeta-votaciones:

3.1. git checkout decide-part-zumeta-votaciones

3.2. git pull

4. Crear a partir de nuestra rama principal actualizada, una rama con el formato indicado: git checkout -b task/128/ChaLui

5. Instalar el requirements.txt en el entorno virtual por si hubiera paquetes nuevos: source nombre/bin/activate, pip install -r requirements.txt, ./manage.py makemigrations, ./manage.py migrate

6. Lanzar las pruebas existentes del sistema para comprobar que el sistema no presenta fallos antes de iniciar el incremento: ./manage.py test voting

7. Aislar el error descrito en la incidencia. Antonio lee la incidencia y ve que el error está en: voting -> models -> desc = models.TextField(blank=True, null=True, max_length=20).

8. Analizar las posibles soluciones. Antonio lee la incidencia y ve en la descripción que una posible solución puede ser aumentar el valor máximo de caracteres para la descripción. ver el cambio, lanzar la aplicación ./manage.py runserver

9. Lanzar las pruebas para comprobar que el sistema no falla: ./manage.py test voting

10. Añadir los cambios

9.1. git add .

10. Hacer commit de los cambios

10.2. git commit

10.2.1 Se abrrirá la plantilla de commits, con el siguiente formato: (Implementación)Añadido incremento en la longitud de la descripción. Se ha añadido al atributo descripción una longitud máxima de 20 caracteres.

11. Hacer push de la rama

11.1 git push

12. Comprobar que la rama pasa travis.

12.1 Esperamos a que travis confirme que la rama ha pasado los tests

13. Mergear con la rama principal.

13.1 git checkout decide-part-zumeta-votaciones 13.2 git pull 13.2 git merge task/128/ChaLui

14. Pasar la tarea a Done. Luis o Chao actualizan su tarea en zenhub

En segundo lugar, nos damos cuenta de que el cambio realizado no es el adecuado, por lo que vamos a solucionarlo poniendo una longitud máxima de 100.

1. Se crea la issue en github y se asigna. Supongamos que es la 129 y se le asigna a Antonio. En este caso sería:

Título: Error en el módulo votaciones

Descripción: "Se obtuvo un error al intentar poner la siguiente descripción: Hola esto es una votación de prueba de más de 20 caracteres. Pasos para obtener el error:

1. Crear una votación
2. Poner en el campo descripción: Hola esto es una votación de prueba de más de 20 caracteres
3. Guardar la votación

Este error es debido a que la longitud máxima de la descripción es menor que el texto introducido.

Posible solución: Modificar la longitud máxima del atributo descripción"

Labels: bug

Asignado: Antonio

2. Antonio cuando comienzan su tarea pasa la issue a la columna In Progress.

3. Actualizar nuestra rama decide-part-zumeta-votaciones:

3.1. git checkout decide-part-zumeta-votaciones

3.2. git pull

4. Crear a partir de nuestra rama principal actualizada, una rama con el formato indicado: git checkout -b Incidencia/#129/Antonio

5. Instalar el requirements.txt en el entorno virtual por si hubiera paquetes nuevos: source nombre/bin/activate, pip install -r requirements.txt, ./manage.py makemigrations, ./manage.py migrate

6. Lanzar las pruebas existentes del sistema para comprobar que el sistema no presenta fallos antes de iniciar el arreglo de la incidencia: ./manage.py test voting

7. Aislar el error descrito en la incidencia. voting -> models -> desc = models.TextField(blank=True, null=True, max_length=20).

8. Analizar las posibles soluciones descritas en la incidencia. Antonio lee la incidencia y ve que una de las posibles soluciones es modificar el atributo descripción.

9. Solucionar la incidencia. voting -> models -> desc = models.TextField(blank=True, null=True, max_length=100). Lanzamos el servidor para ver el cambio. ./manage.py runserver

10. Relanzamos las pruebas para comprobar que la solución no ha creado ningún conflicto. ./manage.py test voting

11. Añadir los cambios

11.1. git add .

12. Hacer commit de los cambios

12.2. git commit

12.2.1 Se abrrirá la plantilla de commits, con el siguiente formato: (Incidencia #129)Arreglada incidencia al introducir descripciones grandes. Se ha añadido al atributo descripción una longitud máxima de 100 caracteres para solucionar la incidencia descrita

13. Hacer push de la rama 13.1 git push

14. Comprobar que la rama pasa travis. 14.1 Esperamos a que travis confirme que la rama ha pasado los tests

15. Mergear con la rama principal.

15.1 git checkout decide-part-zumeta-votaciones 15.2 git pull 15.2 git merge Incidencia/#129/Antonio

16. Pasar la tarea a Done. Antonio actualiza la issue a la columna Done.

Conclusiones y trabajo futuro

Como conclusión final, creemos que nuestro equipo ha trabajado bien desde un primer momento, obviando puntuales baches, y que siempre se ha complementado bien con los otros subsistemas del grupo. Aun así, han surgido problemas por el camino, como es el caso de algunos incrementos que hemos intentado desarrollar y que no han sido posibles de hacer porque más tarde hemos visto que los subsistemas con los que deberíamos trabajar no estaban en manos de nuestros compañeros. O también el caso de algunos compañeros que han encontrado una mayor dificultad inicial para meterse en el proyecto, lo cual ha acabado acarreando problemas extra a los demás. Respecto a los incrementos qué hemos tenido problemas de desarrollar, creemos que en la wiki, en la sección de posibles ideas, debería especificarse mejor con qué subsistemas se relacionan estas ideas, pues es difícil verlo en un primer momento cuando no se ha tenido anteriormente experiencia con el código. También creemos que se debería explicar mejor en qué consisten las distintas partes del código pues, aunque nuestro trabajo en otras asignaturas (como diseño y pruebas) ya nos dé un cierto grado de habilidad para comprender este tipo de frameworks desde cero, resulta costoso en tiempo tener que estar prácticamente realizando ingeniería inversa para comprender partes menores del código.

En cuanto a trabajo futuro, tanto readonlyvoting como multiplevoting podrian ser expandidas para acabar siendo opciones tan extensas de votacion como es el caso de Voting. Tambien se podria intentar jugar con otras ideas, como la realizacion de encuestas no anónimas que podrían dar lugar a otro tipo de votaciones, como concursos donde se repartieran premios.