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

Decide-Part-Zumeta-Censo

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

Miembros del grupo:

Enlaces de interés:

Resumen ejecutivo

El proyecto llevado a cabo por el equipo de decide-part-zumeta-censo ha consistido en desarrollar una serie de mejoras al sistema Decide ofrecido por los profesores de la asignatura EGC. Nuestro equipo decidió antes de comenzar a implementar mejoras centrarse en la parte de censo, que es la encargada de relacionar a los usuarios inscritos en el sistema de votaciones con cada una de las votaciones del sistema. De esta forma, el censo podría entenderse como la autorización que hay que dar a un usuario para votar en una votación. Esto nos facilitaba realizar una integración con el equipo decide-part-zumeta-votaciones, ya que ellos se encargaban de desarrollar mejoras sobre la parte de votaciones.

Tras identificar la parte del sistema que teníamos que mejorar, los distintos miembros del equipo nos dispusimos a analizar el código relacionado con esta parte, y a tratar de aprender cómo funciona Django, ya que no lo habíamos usado hasta ahora en ningún proyecto. Esta ha sido la parte más complicada del proyecto, ya que es una tecnología que nunca habíamos tocado, y que se fundamentada en un lenguaje de programación que apenas hemos podido ver a lo largo de la carrera.

Tras mejoras nuestras habilidades con Python y Django, nos dispusimos a pensar nuevas funcionalidades para la parte de Censo. Este subsistema era bastante simple, y tampoco ha permitido al equipo desarrollar una gran cantidad de funcionalidades nuevas debido a su simple funcionamiento. Por esto, decidimos implementar un frontend que facilitase el manejo de los censos del sistema para poder tener trabajo suficiente como para desarrollar nuestros conocimientos en la asignatura. Esto nos obligaría a tocar Modelo, Controlador y Vista en Django de forma que pudiésemos exprimir al máximo la oportunidad de aprender a trabajar con este framework.

Tras varios meses de trabajo, nuestro equipo ha sido capaz de implementar una interfaz gráfica amigable para manejar los diferentes censos almacenados en la base de datos, permitiendo agrupar y filtrar la información involucrada en este subsistema. Hemos desarrollado funcionalidades para importar y exportar el censo de diferentes votaciones, y se han añadido nuevos datos al modelo del censo. Con el fin de realizar una integración con el equipo decide-part-zumeta-votaciones, agregamos un nuevo modelo que permitiese almacenar los datos de un usuario. En concreto, nos interesaba registrar la edad del usuario para poder desarrollar junto a al equipo de votaciones una funcionalidad que permitiese restringir el censo de una votación por unas edades máximas y mínimas.

Tras desarrollar los diferentes incrementos funcionales, testeamos cada una de las partes que el equipo implementó para asegurar el correcto funcionamiento del sistema a pesar de realizar integraciones con otros equipos. Travis CI nos ha ayudado a cerciorarnos de que cada implementación llevada a cabo cumplía con los tests existentes antes de realizar cualquier deploy de una nueva versión en Heroku.

Además, nuestro equipo se ha hecho cargo de la gestión del repositorio de código compartido con los demás equipos. El despliegue y la configuración de testing y despliegue automático también ha sido parte del trabajo desarrollado por este equipo, implementando los sistemas de testing y despliegue demandados en la asignatura en su totalidad.

Indicadores del proyecto

Miembro del equipo	Horas	Commits	LoC	Test	Issues	Incremento
Angulo Moruno, Fernando	50	15	300 aprox	6	9	Desarrollo del frontend de censo y función de autenticación del frontend.
Calzado Cobo, Moisés	65	39	400 aprox	8	16	Desarrollo del frontend de censo, integración con el equipo de votaciones de forma que cada censo tuviese en cuenta la edad del usuario
Casasola Calzadilla, María	60	45	700 aprox	7	13	Implementación de la funcionalidad del filtrado de censos y agrupado de censos en el frontend por votación y votante. Funcionalidad para mostrar los gráficos de datos de los censos.
Coleto Alcudia, Emilia	58	25	500 aprox	8	12	Implementación de la funcionalidad del listado de todos los censos y agrupado de censos en el frontend por fecha, adscripción y pregunta.
Márquez Trujillo, Antonio Germán	56	18	300 aprox	5	9	Implementación de la exportación e importación de censos tanto para administrador, como para cliente, en formato csv. Así como la propia validación necesaria para estos documentos.
TOTAL	293	142	2200 aprox.	34	59

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

Commits: commits hechos por miembros del equipo.
LoC (líneas de código): líneas producidas por el equipo.
Test: test realizados por el equipo.
Issues: 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

Nuestro equipo se ha integrado con dos equipos, aunque con uno de ellos no ha sido posible realizar ningún incremento funcionar conjunto ya que la parte de censo no afectaba a su parte y viceversa. El equipo con el que hemos podido realizar una integración ha sido el llamado decide-part-zumeta-votaciones, mientras que el equipo con el que se ha tratado de desarrollar una integración y no ha sido posible es decide-part-zumeta-postprocesado. Aún así, se ha realizado una integración con los dos equipos citados para desplegar el proyecto de forma conjunta. El repositorio de código ha sido compartido por los tres equipos aunque cada uno ha trabajado sobre su rama hasta que hemos juntado el trabajo.

[Decide-part-zumeta-votaciones]: Funcionalidad para tener en cuenta la edad de un usuario a la hora de añadirlo al censo de una votación con límites de edad, y despliegue y desarrollo conjunto.
[Decide-part-zumeta-postprocesado]: Despliegue y desarrollo conjunto

Descripción del sistema

El sistema está desarrollado sobre el proyecto Decide basado en "agora-voting" a partir del proyecto en GitHub https://github.com/wadobo/decide/.

Decide es una plataforma electrónica de voto con voto seguro y criptográficamente seguro punto a punto. La funcionalidad principal del sistema general es que una serie de usuarios sean registrados en este y puedan realizar su voto en las votaciones que han sido creadas y están censados en ellas, posteriormente estos votos serán tratados de forma que se reflejen los resultados de cada una de estas votaciones de manera anónima. Todas estas acciones son desarrolladas en cada uno de los ocho subsistemas de los que se compone (autenticación, censo, votaciones, cabina de votación, almacenamiento de votos, recuento, post-procesado y visualización de resultados). Los subsistemas son más o menos independientes entre sí y estos se interconectan a través de una API general. Decide está desarrollado en Django sobre un entorno virtual de Python, lenguaje utilizado en el sistema, utilizando para la gestión de la base de datos PostgreSQL.

Cada subsistema se encarga de gestionar una parte del sistema de voto:

Autenticación: se encarga de la autenticación de los usuarios del sistema a través de un login simple. Se esta manera se asegura que un votante no realice dos votaciones en una misma votación y de lugar a fraudes en el resultado. Por tanto, esta autenticación debe de ser segura.
Censo: el censo es el encargado de registrar qué votantes pueden acceder a las votaciones almacenadas en el sistema. Así, aunque un usuario pueda acceder a la plataforma, si este no está censado en una votación se le denegará el acceso a esta. Este subsistema, por tanto, está fuertemente relacionado con la autenticación pero no son lo mismo puesto que la autenticación se encarga del acceso al sistema completo y el censo del acceso a una determinada votación.
Votaciones: encargado de crear una votación con sus respectivas preguntas y opciones y más configuraciones. También permite comenzar o dar por finalizada las votaciones registradas y realizar el recuento de los resultados obtenidos una vez esta ha acabado (tally).
Cabina de votación: es el subsistema encargado de la interfaz de voto una vez una votación ha comenzado. Los usuarios censados acceden a él y realizan las votaciones pertinentes. Simplemente muestra la pregunta de la votación y sus opciones para que el votante elija según su preferencia y esta sea registrada.
Almacenamiento de votos: se almacenan los votos cifrados de manera que se conozca cuales de los votantes censados han votado y cuales no, pero sin conocer qué opción de la votación ha sido elegida por cada uno.
Recuento: es el responsable de la parte criptográfica de la votación. Es una red de ordenadores que generan claves compartidas para cifrar los votos almacenados. Así, a la hora de realizar el recuento, se tienen que poner de acuerdo todas las autoridades para poder descifrar el voto. En el recuento se elimina el votante del voto de manera que este sea anónimo cuando se obtenga el resultado.
Post-procesado: una vez se ha hecho el recuento se obtiene una lista de números la cual se pasa al post-ptocesado. Este subsistema es el encargado de traducir esos números a un resultado de la votación. Para ello se aplican diferentes reglas de recuento como reglas de paridad, la ley D'Hont o un simple recuento de los resultados.
Visualización de resultados: una vez obtenidos los resultados del subsistema de pos-procesado, estos son mostrados en este subsistema con gráficas y tablas para que sean más entendibles por los usuarios. La visualización de los resultados también se encarga de generar informes de las votaciones en formato web, pdf, texto plano, etc.

Los módulos de los que se compone Decide y con los que trabajan los subsistemas son:

base: contiene las funcionalidades básicas
auth: gestiona la autenticación de los usuarios (votantes) a través de un login.
census: almacena qué usuario puede votar en una determinada votación.
voting: define las votaciones con sus respectivas preguntas.
booth: es la cabina donde el votante censado emite su voto.
mixnet: es el módulo encargado de la anonimación (encriptación) del voto emitido.
store: almacenamiento de los votos una vez cifrados.
postproc: encargado del recuento de los resultados de los votos almacenados aplicando a su vez las reglas necesarias para el procesado de estos.
visualizer: es el módulo que ofrece la visualización de los resultados de las votaciones.

El equipo "decide-part-zumeta" está compuesto por tres subgrupos los cuales trabajan el incremento funcional de los subsistemas votaciones, censo y postprocesado. El objetivo que se ha de conseguir con el desarrollo de este proyecto es realizar una serie de incrementos funcionales sobre cada uno de los sistemas, que finalmente serán integrados entre ellos permitiendo así la comunicación entre estos tres subsistemas.

Se ha elegido esta integración debido a que los tres sistemas se complementan a la hora de la utilización del sistema por parte de los usuarios. En primer lugar, el subsistema de votaciones permitirá al administrador crear las respectivas votaciones con las preguntas pertinentes para cada una de ellas, posteriormente los votantes son censados de manera que se les permita realizar un voto sobre ellas, una vez son censados y han realizado los votos, el subsistema de postprocesado se encarga de procesar los votos de todos los usuarios y aplicar las reglas pertinentes para conseguir un resultado que permita valorar el resultado de esta votación. Cada uno de los subgrupos se encarga del incremento de funcionalidades de su subsistema sin poder realizar cambios en los otros módulos de Decide. En este documento en concreto, se detallará el trabajo realizado por parte del subgrupo "decide-part-zumeta-censo" en el subsistema de censo de la plataforma.

El subsistema del censo se encarga de almacenar quién puede votar o ha votado en las votaciones existentes en la base de datos del sistema de manera que se pueda así controlar el acceso de los usuarios de la plataforma a cada una de las votaciones trabajando con los datos proporcionados tanto por la votación como por los de los usuarios que se les permite votar. Es decir, un usuario que no esté censado en la votación, aunque tenga acceso al sistema, no podrá realizar ninguna acción sobre dicha votación.

Sobre el subsistema de censo ha realizado los siguientes cambios:

Frontend de administración de censo: se realiza el frontend del subsistema censo de manera que se muestra un listado de los censos almacenados en la base de datos y se añaden en esta misma página todos los incrementos realizados por parte del equipo, de esta manera, cualquier usuario registrado en el sistema puede acceder a los censos disponibles sin tener que ir a la página de administración de Django.
Grupos de censo para filtrado y agrupar: para este incremento funcional, ha sido necesario añadir dos propiedades al modelo de censo las cuales son mostradas tanto en el listado como en los detalles del censo: fecha (fecha en la que se ha creado el censo), adscripción (lugar en el que se realiza el censo). En cuanto al filtrado, se ha añadido en el frontend del censo un cuadro de texto el cual permite al usuario encontrar los censos que contienen en los atributos mostrados en el listado la subcadena introducida en este campo. Para el agrupado, se ha creado un panel el cual permite agrupar los censos que comparten alguna propiedad. Se pueden realizar cinco agrupamientos diferentes : por votante, por votación, por adscripción, por fecha y por pregunta de la votación.
Importación de censo: los censos pueden ser creados a través de la importación de un archivo CSV que contenga el id del votante, la adscripción y la fecha del censo, dentro de la plataforma se debe indicar el id de la votación a la que pertenece. De esa forma, se pueden crear un grupo de censos a la misma vez y tardar menos en la creación que creando uno a uno estos censos. Los censos pueden ser importados tanto en el panel de administración de Django como desde el frontend de censo para los usuarios registrados. Hay que tener en cuenta que un censo no puede ser creado si comparte id de votación y votante con uno ya almacenado.
Exportación de censo: con esta nueva funcionalidad se pueden exportar los censos seleccionados desde la página de censo del panel de administración de Django. Los censos son exportados en formato CSV conteniendo el id del censo, de la votación a la que pertenece, el votante censado y la adscripción y fecha del censo.
Integración con el subsistema votaciones: se han integrado los subsistemas de censo y votaciones de manera que al crear una votación se añada un rango de edad de los usuarios que pueden votar en ella. Por lo tanto, un usuario que no se encuentre en este rango, no podrá ser censado en la votación.

Visión global del proceso de desarrollo

Nuestro proyecto está formado por los subsistemas de censo, post-procesado y votaciones. Inicialmente cabe destacar, como visión global del proyecto entero del equipo Zumeta, el trabajo en equipo y la organización por parte de todos los miembros que conforman los distintos subgrupos del equipo.

Lo primero de todo fue crear un grupo de Whatsapp para los equipos y poder mantenernos, así, en contacto continuo. Debido a la necesidad de una buena coordinación por parte de los tres grupos decidimos empezar por determinar una organización interna que nos ayudase a tomar decisiones de una manera eficaz y rápida. Por ello, cada grupo nombró dos representantes que asistirían a las reuniones generales y tomarían las decisiones comunes. Algunas de estas decisiones pueden ser, por ejemplo, el uso de un repositorio compartido por todos los grupos, la creación de la rama Develop para proteger la rama Máster y, también, seguir la misma nomenclatura todos para la creación de las ramas correspondientes a cada equipo, es decir, hacer uso de una metodología de trabajo sistemática, asegurando orden y un mejor avance.

Estas reuniones mencionadas anteriormente se llevaban a cabo a través del servidor de Discord creado para el desarrollo de nuestro sistema. Éste cuenta con tres canales de voz y de texto diferentes para cada equipo y un canal de voz y de texto general para la información común. Además, cada subgrupo cuenta con su tablero de proyecto en GitHub y se organiza de forma interna como considera oportuno de cara al reparto de tareas y creación de columnas de trabajo. La wiki del repositorio también queda dividida en siete páginas, dos de cada grupo correspondientes a documentación y diario de equipo y la página grupal de Home.

La forma de trabajar en común ha consistido en la creación de una rama develop a partir de la rama master para realizar todos los cambios sobre ella y así proteger la rama principal. Además, en GitHub se aplicó la regla de que nadie podría realizar un push sobre la rama master, evitando cualquier conflicto o equivocación. Una vez que cada grupo hubiera realizado sus correspondientes tareas de implementación, nos reuniríamos para unir en las ramas develop y master todos estos cambios desde las ramas creadas para cada grupo a partir de la rama develop.

Una vez que cada equipo ha completado sus correspondientes implementaciones en sus respectivas ramas, estas se revisan en común con los representantes de cada grupo y se unen a la rama develop. Cuando todo está unido a la rama develop y se ha comprobado que no surge ningún tipo de conflicto, se prueba la funcionalidad completa del sistema y se ejecutan todas las pruebas que se han ido desarrollando por parte de cada miembro. Si todo va bien, el último paso cosiste en unir esta rama a la principal (la rama master).

Pasando, ahora, a la organización interna del equipo de censo, habría que destacar el hecho de haber trabajado anteriormente como grupo en otras asignaturas y que conocemos las aptitudes de cada uno y la manera de trabajar que se sigue siempre como equipo.

Tras esto, pasamos a describir en profundidad la metodología de trabajo de nuestro equipo.

Se concierta al inicio de cada sprint una reunión de planificación, en la que se especifican las tareas a realizar a lo largo de todo el intervalo de tiempo que dura el sprint. Una vez quedan determinadas las tareas, se marca el nivel de dificultad de cada una a criterio del equipo haciendo uso de las herramientas que ofrece GitHub como son, en este caso, las etiquetas (labels). El nivel de dificultad marcado nos ayuda a realizar un reparto equitativo de tareas entre todos los miembros, para que, si, por ejemplo, una primera persona cuenta con una tarea de dificultad 2 (mayor) y una segunda con una de dificultad 1 (menor), si queda por repartir una tarea de dificultad 1, sea asignada a la segunda, quedando una persona con una tarea que requerirá más tiempo o esfuerzo y la otra con dos más sencillas. Finalmente, una vez se hayan repartido todas las tareas, se establecen milestones con las fechas límites para cada parte, tanto funcionalidad como documentación.

Al final de la iteración, se convoca una reunión de revisión para revisar todo el trabajo realizado por cada miembro y unir cada parte. Esta reunión suele ser más larga que la reunión de planificación, puesto que se revisa, paso a paso, cada tarea realizada y una vez comprobado que se ha completado con eficacia, se cierra en GitHub.

En nuestro caso, se le ha otorgado el cargo de Project manager a Antonio Germán Márquez Trujillo. Sin embargo, hemos considerado que la asistencia a las reuniones globales puede ser atendida por cualquier miembro que esté disponible en ese momento, ya que consideramos que todo el grupo cuenta con las aptitudes necesarias para tomar decisiones importantes en algún punto del proyecto y nos mantenemos en constante comunicación.

Además, el reparto de funcionalidades no se ha realizado de manera aleatoria como el de documentación. En este caso, cada pareja de trabajo estimó la preferencia entre las distintas opciones, y se asignaron atendiendo a dichas preferencias, para que todos trabajáramos en algo que realmente nos llamaba la atención.

Por último, se procede a poner un ejemplo del protocolo seguido para la realización de un cambio propuesto para el sistema y cómo se ha abordado durante todo el ciclo hasta completar dicha funcionalidad.

Como hemos especificado anteriormente, el primer paso consiste en estipular la tarea en el tablero de GitHub y asignarla a sus correspondientes miembros. Una vez hecho esto, los responsables de dicha tarea comienzan a investigar el código necesario y relacionado con ella. La investigación es la parte más importante de este ciclo, puesto que hasta que no se tiene claro qué hay que hacer y cómo se debe hacer, no se puede empezar a realizar dicho incremento. Posteriormente viene la parte de realización de código y sus correspondientes pruebas. Puede que no sea la parte más importante, pero sí puede ser la parte más costosa y en la que se dedica más tiempo, ya que, aunque se tenga conocimiento del código y un buen manejo del proyecto, hay que enfrentarse a los posibles errores que puedan surgir y solucionarlos, además de conseguir que el sistema cumpla con los requisitos que implica la tarea.

Una vez se ha conseguido todo esto, se realiza una ‘pull request’ de la rama correspondiente a la rama develop, después del push necesario. Esta pull es revisada por una pareja ajena a la implementación en cuestión, que pueda aportar un análisis objetivo del trabajo completado por los compañeros del grupo, asegurando, por tanto, que todo está correcto y se puede unir confiando en el código. Tras esto, se realiza el merge de la rama que corresponde a la issue en la rama que pertenece al trabajo del grupo respectivo. Todo este proceso conlleva que los responsables de esta tarea muevan en el tablero la issue entre las correspondientes columnas, que son To do, In progress, Review y Done, atendiendo al estado en el que se encuentre en cada momento. Solo una vez que la tarea es revisada y unida, se cierra y se mueve automáticamente a la columna Done.

Entorno de desarrollo

Con el fin de facilitar al máximo el proceso de desarrollo de los diferentes incrementos funcionales del subsistema de censo, el equipo de trabajo ha intentado utilizar en su totalidad el mismo entorno de desarrollo. Esto facilita el seguimiento de los errores que puedan aparecer durante el proceso de desarrollo, y garantiza que los incrementos desarrollados no sufran cambios en cuanto al despliegue del subsistema.

Todo el equipo de trabajo ha utilizado la última versión estable del sistema operativo Ubuntu durante el desarrollo del proyecto. Esta ha sido instalada de forma nativa en todos los equipos de desarrollo, y se ha prescindido en todo momento de herramientas de virtualización como pueden ser el caso de VirtualBox o WSL. La versión utilizada de Ubuntu ha sido la 20.04.

En cuanto al software de escritorio utilizado para el desarrollo del proyecto, comentaremos las herramientas utilizadas dependiendo del uso de las mismas.

Editores de texto

La mayoría del equipo ha hecho uso de Visual Studio Code para desarrollar el código de los incrementos de la parte de censo. Este editor es muy configurable, aunque no se considera un IDE debido a que puede utilizarse para desarrollar casi cualquier lenguaje del mercado. En nuestro caso, hemos hecho uso del mismo instalando las siguientes extensiones:

Django: proporciona autocompletado a la hora de desarrollar el código de este framework.
Docker: permite gestionar los contenedores de docker.
Python y Python for VSCode: autocompletado y ayuda en la sintáxis al desarrollar código en Python.

Además, a la hora de debuguear el código de la aplicación acordamos utilizar PyCharm, ya que permite realizar el debugging de una forma más sencilla, y cuenta con una interfaz bastante clara para llevar a cabo esta tarea.

Control de versiones

Para llevar a cabo el control de versiones del desarrollo de nuestro subsistema, hemos utilizado Git. Este software de control de versiones está considerado un estándar dentro de la industria del desarrollo de software, y facilita la integración de las diferentes versiones de código desarrolladas. Para el almacenamiento del código se ha empleado un repositorio en GitHub.

Navegador web

El equipo de desarrollo ha hecho uso de las últimas versiones estables de Google Chrome y de Mozilla Firefox.

Base de datos

Decide hace uso de PostgreSQL, y el equipo de desarrollo ha utilizado la versión 10.15 de esta conocida base de datos para desarrollar los incrementos funcionales de este sistema.

Despliegue

A la hora de desplegar el sistema, el equipo de trabajo ha utilizado diferentes herramientas para asegurar el correcto funcionamiento del mismo. En primer lugar, se ha hecho uso de la herramienta Docker para asegurar el correcto funcionamiento del sistema antes de realizar el despliegue. Travis CI ha ayudado a detectar errores antes del despliegue de nuevas versiones, y Heroku ha alojado los servidores en los cuales nuestro sistema se ha desplegado.

Proceso de instalación del entorno de desarrollo

Ahora que conocemos las diferentes herramientas que han sido utilizadas para desarrollar Decide, procederemos a detallar el proceso de instalación de las mismas para poder preparar el entorno de desarrollo.

En primer lugar, partiremos de un sistema operativo Ubuntu limpio, aunque no debería haber problema a la hora de seguir los pasos en otro sistema operativo. Las primeras herramientas que nos aseguraremos de instalar serán Visual Studio Code, un navegador web, PostgreSQL y Git.

Tras instalar estas herramientas, se tendrá que clonar el repositorio de GitHub, además de crear un usuario con acceso a una base de datos que también crearemos en PostgreSQL. Este usuario deberá estar registrado en el archivo local_settings.py que se creará en la carpeta decide copiando el archivo local_settings.example.py. Además, tendremos que especificar la contraseña para que este usuario tenga acceso a la base de datos, y tendremos que cambiar las URLs de los subsistemas para poder acceder a ellos desde nuestro entorno local.

Cuando completemos estos pasos, procederemos a crear un entorno virtual de python, en el que instalaremos los requisitos especificados en el archivo requirements.txt. Estos requisitos serán imprescindibles para el correcto funcionamiento del sistema, y se pueden instalar de manera automática a través del siguiente comando: pip install –r requirements.txt

Tras instalar los requisitos, navegaremos hasta la carpeta decide y aplicaremos las migraciones sobre la base de datos. Para realizar este paso tendremos que introducir el siguiente comando: ./manage.py migrate, y a continuación crearemos un usuario para acceder al panel de administrador de decide: ./manage.py createsuperuser.

Esto debería ser suficiente para proceder a desarrollar nuevas funcionalidades para decide. Para correr el sistema basta con introducir el siguiente comando: ./manage.py runserver

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

En esta sección se va a tratar las herramientas utilizadas para llevar a cabo la construcción y la integración continua, así como el proceso de esa integración y construcción en cada incremento de código funcional que se ha llevado a cabo. También trataremos el cómo hemos medido la calidad del código en ese proceso y de que métricas se han usado para medirlo, y garantizar que cumple con los requisitos de calidad del proyecto a lo largo del tiempo de desarrollo.

Herramientas a utilizar y objetivo

Para la gestión de la construcción e integración continua hemos trabajado con varias herramientas, las cuales se especificará su función a en el apartado siguiente:

Con estas herramientas hemos gestionado un entorno de construcción e integración continua capaz de cumplir todas las necesidades del proyecto. Para poder hacer más eficaz, eficiente y rápido el desarrollo del proyecto, minimizando en gran medida tiempos, costes y errores, y maximizando la mantenibilidad, la legibilidad y la calidad del código. Siendo esto último el objetivo principal.

Travis CI

Travis CI es un servicio de integración continua que es utilizado para crear y probar proyectos software de toda índole. Es una herramienta muy útil y de la que haremos uso sobre todo para probar continuamente test automatizados.

Esta herramienta puede configurarse de manera sencilla con un archivo YAML que se guarda en el directorio raíz del proyecto y cada cambio que se hace en alguna rama del proyecto es informado por GitHub a Travis, para que este compruebe una vez informado todas las pruebas de la rama modificada por una integración. Haciéndose esto de forma automática y continua a lo largo de la duración del proyecto, o hasta que se precise, con la opción de que se notifique a los desarrolladores automáticamente. También puede ser configurado para que actúe en ciertas ramas o rama en concreto.

Codacy

Codacy es una herramienta que automatiza la revisión de código en commits y pull requests¸ incluso bloqueando merges si estos no cumplen con la calidad. Comprobando la calidad del código y haciendo un seguimiento de la deuda técnica. Soportando más de 30 lenguajes.

La revisión de Codacy es bastante completa comprobando el estado actual del código del repositorio, cuanta deuda técnica tiene el repositorio y cuáles son las áreas más problemáticas. Todo enfocado a medir la salud del código a lo largo de la evolución del proyecto.

Una vez añadido repositorio de GitHub en la aplicación de Codacy podemos obtener acceso a todas estas métricas, la opción más interesante es que trabaje junto a Travis para ser más eficientes midiendo la calidad del código en el estado el actual del proyecto.

Heroku

Heroku es una plataforma en la nube que permite a cualquier tipo de usuario construir, entregar, desplegar, supervisar aplicaciones, y alojarlas en la nube. Soportando casi cualquier tipo de lenguaje de programación.

Es una herramienta muy útil ampliamente usada para resolver el despliegue de una aplicación y no tener que preocuparte por la infraestructura, pudiendo enfocarte solo en el desarrollo de la aplicación. Esto se hace sobre todo en fases tempranas de los proyectos cuando lo más importante es desarrollar algo que interese a un público.

Además, Heroku también te permite manejar los servidores y sus configuraciones, escalamiento y la administración. Todo esto y lo anterior, simplemente indicándole el lenguaje del backend utilizado en el proyecto o la base de datos que se va a utilizar.

Proceso de integración continua y construcción.

El proceso comienza cuando se realiza un commit por un desarrollador del equipo, con su correspondiente push de local al repositorio remoto. Este commit lleva un archivo YAML correspondiente a Travis que se encarga de construir el proyecto con la configuración que tiene. Travis ha sido configurado para que trabaje en nuestro repositorio de GitHub, en el archivo .travis.yml que se encuentra como ya se ha mencionado antes en el directorio raíz. Este script está realizado en concreto para la integración continua de nuestro proyecto (es decir, no es un script genérico, está diseñado para nuestro proyecto, por lo que su uso solo tiene sentido en el mismo).

Este especifica la distribución usada, el lenguaje de programación, los servicios usados (y sus configuraciones), los requisitos, sus versiones y el despliegue de la aplicación en Heroku (con toda la información que necesita para ello, así como la rama que debe ser desplegada tras hacer el commit). Para instalar y preparar el entorno que ejecutará las pruebas en Travis, así como la librería de Codacy para enviar a este el código y medir su calidad. La distribución usada ha sido Linux (Xenial), el lenguaje Python (versión 3.6), el servicio de la base de datos de PostgreSQL (versión 9.4) y su configuración para crear la base de datos, el usuario y los roles del usuario. Así como todos los requisitos con sus versiones para que el proyecto funcione correctamente.

Una vez haya marcado esta rama como pasada, es decir que todas sus pruebas pasan Travis, si el commit se ha hecho sobre la rama master indicada en el despliegue del script de Travis, la aplicación se redesplegará en Heroku. Por el contrario, no se realizará ninguna acción. También se notificará las métricas de calidad medidas por Codacy.

Métricas de calidad del código

Las métricas de calidad del código que hemos seguido son las siguientes:

Tamaño: inicialmente no indica una métrica de calidad como tal, pero si nos indica la magnitud actual del proyecto, información importante pues se debe adecuar al tipo de proyecto en particular que se está desarrollando. Aunque cada caso en particular puede variar bastante si esto está justificado.
Comentarios: los comentarios tienen el propósito de hacer el código fuente más entendible, reutilizable y mantenible, de cara al futuro. Al igual que unos comentarios escasos, un gran número de los mismos no aseguran una buena calidad. Por lo que se intentará que sean los necesarios, y que estos sean lo más aclaratorios posible.
Código duplicado: es código fuente que aparece más de una vez en distintas partes del código, teniendo exactamente las mismas funciones. Un buen desarrollo del código está más asociado a la reutilización del código, por lo que si se detecta código duplicado se intentará reutilizar.
Código muerto: código dentro del proyecto, pero sin ningún tipo de uso a lo largo del tiempo. En caso de ser detectado este será eliminado.
Estándares de codificación: son convenciones a la hora de escribir el código fuente (nombres de variables, indentación, espaciado, …), y que son dependientes del código del lenguaje. Se seguirán estos estándares, para mejorar la calidad del código.
Complejidad ciclomática: es una métrica de calidad basada en el número de caminos independientes que tiene nuestro código. Se debe intentar que sea el mínimo posible, y que no sobrepase los estándares actuales.
Cobertura de código: es la cantidad de código que ha sido validado por los tests. Mientras mayor es la cobertura más libre de errores estará nuestro código, aunque nunca se pueda garantizar que esté 100% libre de errores. El objetivo es mantener y si es posible superar, la cobertura inicial del proyecto base.
Test unitarios y de integración: son la base fundamental de la comprobación del correcto funcionamiento de nuestro código. Estos facilitan la integración de nuevos cambios, ya que nos aseguran que no se han introducido errores en partes ya desarrolladas anteriormente del código. Y a la vez tienen una función documentaria del código. Se precisará tener una gran cantidad de tests para asegurar la cobertura del proyecto.
Diseño: tanto el diseño como la arquitectura de un sistema son aspectos claves, y esenciales para favorecer la calidad del código, o por el contrario empeorarla. El bajo acoplamiento y la alta cohesión son recomendados a la hora de diseñar el sistema, para minimizar la dependencia y maximizar el propósito concreto de cada función del código. Para ello se evitará tener ciclos en el código y un bajo índice de interdependencia en el proyecto, es decir dependencias entre paquetes y ficheros. Siendo lo ideal, 0 ciclos y un índice de 0%.

El objetivo de estás métricas es cumplir con una puerta de calidad, es decir cumplir con unas condiciones del proyecto, antes de que este pueda ser lanzado a producción. Y esto debe cumplirse en cada incremento de código funcional que vaya a ser lanzado a producción.

Gestión de incidencias

El proceso de gestión de incidencias pasa primero por identificar qué tipo de incidencia es, una vez identificada esta seguirá de manera homogénea una plantilla hasta su resolución, donde pasará por una serie de estados, se le asignará un rol específico y una prioridad que dependerá de varios factores. Podríamos clasificar las incidencias en internas y externas.

Forma de gestionar incidencias internas

Las incidencias internas son las ocurridas dentro de nuestro equipo de desarrollo acometidas por las personas que lo conformamos. Dado el caso de que un miembro del equipo encuentre un problema en el código fuente de nuestro subsistema, este seguirá el siguiente proceso para gestionar esa incidencia de forma segura y eficiente:

Un miembro descubre un fallo dentro del proyecto en cualquier tipo de situación, como es de nuestro propio subsistema, esta incidencia se cataloga como interna, y por lo tanto:
- 1.1. Se debe informar del error encontrado, su posición aproximada en el código o concreta si se pudiese (clase, método, línea, …) y, a ser posible, la traza del error que se haya imprimido en la consola o terminal, mediante los canales disponibles para el equipo de nuestro subsistema (WhatsApp o Discord).
- 1.2. Se identificará a la persona o personas implicadas en la implementación de ese código o funcionalidad, pues son las personas que pueden resolverlo de manera más eficiente al haber construido ese código. Y se elegiran esas personas si es posible para solucionar la incidencia.
- 1.3. Las personas elegidas se encargarán de crear una issue dentro del repositorio de GitHub, se le asignará a ellos mismos, le darán el rol de bug y se especificará su prioridad, la cual puede tener varios niveles que se comentaran posteriormente.
Una vez asignada, esta pasará directamente al estado de in-progres donde se intentará solucionar lo antes posible. Y una vez solucionada pasará al estado de review.
A continuación, se informará de su resolución por los canales ya mencionados al resto del equipo, y con la ayuda de una o más personas independientes a la resolución de la issue que comprueben que ha sido correctamente resuelta, esta pasará al estado de done.
Una vez en done, de esta se hará un merge a la rama del quipo (decide-part-zumeta-census), a la rama develop y a la rama master, si las dos últimas se vieran afectadas por el error.
Aquí acabaría el proceso. En caso de que el error no se hubiera resuelto correctamente, se reabrirá la issue y se volverá a repetir el proceso desde el punto 2.

Forma de gestionar incidencias externas

Las incidencias externas son las ocurridas por agentes externos a nuestro equipo de desarrollo y sus integrantes. En otras palabras, ocasionadas por personas de otro subsistema con el cual estamos colaborando. Si un miembro de nuestro equipo encontrase una incidencia externa deberá seguir el siguiente proceso para gestionarla de forma correcta:

Un miembro del equipo encuentra un fallo proveniente de un subsistema ajeno al nuestro, por lo tanto, se cataloga como externa y a continuación:
- 1.1. Se debe informar del error encontrado, su posición aproximada en el código o concreta si se pudiese (clase, método, línea, …) y a ser posible la traza del error que se haya imprimido en la consola o terminal. Mediante los canales disponibles para todos los equipos de los diferentes subsistemas (WhatsApp o Discord).
- 1.2. Se identificará a la persona o personas implicadas en la implementación de ese código o funcionalidad, pues son las personas que pueden resolverlo de manera más eficiente al haber construido ese código.
Esas personas gestionarán la creación de la issue y su resolución siguiendo lo especificado en la plantilla de su propio equipo de desarrollo.
Una vez solucionada, se nos notificará de su solución y, junto a personas independientes a la resolución de la issue, de su equipo o del nuestro, se comprobará.
Si el resultado es satisfactorio, esta issue pasará a estar finalizada y se hará merge a las ramas de los equipos afectados, así como a develop y a master si estas también se encuentran afectadas.
Aquí acabaría el proceso. En caso de que el error no se hubiera resuelto correctamente, se reabrirá la issue y se volverá a repetir el proceso desde el punto 2.

Nota: En caso de tener que gestionar una incidencia externa de otro equipo que haya ocasionado uno de nuestros integrantes, se seguirá la plantilla de gestión de incidencias internas a partir del punto 1.3.

Cálculo de la prioridad de una issue

La prioridad de una incidencia (issue) puede tener varios niveles de prioridad, dependiendo de lo critica que sea la incidencia para el sistema o subsistemas afectados, y para el propio sistema en conjunto puesto en producción:

Incidencia de prioridad 1: Si la incidencia afecta a la rama de producción (master) o afecta directamente a los tres subsistemas, será clasificada con la máxima prioridad (prioridad 1).
Incidencia de prioridad 2: Si la incidencia afecta a la rama de desarrollo (develop) o afecta directamente a dos subsistemas esta será considerada de prioridad 2 o prioridad media.
Incidencia de prioridad 3: Si la incidencia afecta a la rama o ramas de un subsistema, es decir a un solo subsistema, será de la menor prioridad posible (prioridad 3).

Para esclarecer mejor los puntos expuestos, la siguiente tabla puede ser una guía que sirva de ayuda, donde cada casilla se interpreta como una prioridad:

Subsistemas \ Rama	Master	Develop	Rama de un subsistema
Tres	1	1	1
Dos	1	2	2
Uno	1	2	3

Gestión del código fuente

La gestión del código fuente es uno de los puntos mas importantes en lo que se refiere al desarrollo del proyecto (Hoy en dia ningún proyecto de dimensiones un poco “grandes” podría sobrevivir sin una buena gestión del cóidigo fuente), por lo que intentamos hacer bastante incapié en la definición y en el aseguramiento de que absolutamente TODOS los miembros participantes del proyecto siguen estas pautas imprescindibles para el correcto desarrollo del producto.

Asi como el tiempo del que disponemos es muy limitado, nuestro proyecto cuenta con un numero de personas bastante alto trabajando en el, esto da lugar a muchos y muy diferentes posibles conflictos (en lo que al desarrollo del codigo se refiere) debido al necesario desarrollo en paralelo de las diferentes características a implementar. Esto da lugar a que se hace totalmente imprescindible poder llevar un control de cuando, donde y como se realiza un cambio.

Existen muchas y muy diferentes herramientas para la realizacion de esta tarea de gestión. En nuestro caso utilizamos la herramienta creada por Linus Toorvalds, Git. Es la mas extendida y nos ofrece un control de verisiones de forma muy intuitiva y segura, justo lo que necesitamos para un proyecto en el que la mayoría de participantes carecen de una dilatada experiencia en el uso de este tipo de software.

Estos son los diferentes puntos que los desarrolladores del proyecto deben de seguir para un desarrollo sin conflictos:

Trabajar en tu propia rama.
Tener tu rama actualizada.
Hacer commit con frecuencia.
Subir codigo definitivo a una rama de unión.
Documentar y definir correctamente los cambios.

No seguir alguno de estos puntos podría producir un resultado fatal como la perdida de trabajo o la incohomprensión de alguna parte del codigo.

Tener tu rama actualizada

Mantener una constante actualizacion de tu rama de trabajo es esencial para evitar conflictos en el desarrollo. Si comienzas a modificar parte del codigo en el que alguno de tus compañeros ha trabajado sin ser consciente de ello, podría resultar en un quebradero de cabeza, luego, a la hora de comprobar como implementar los cambios, o incluso podría resultar en que se pierda codigo si estos conflictos no se gestionan de forma correcta. La herramienta que estamos utilizando tiene muchos mecanismos para evitar que esto ocurra y que si ocurre, no produzca un error fatal, pero siempre es una buena práctica porque no todas las herramientas de gestión de versiones tienen estas características.

Mantener tu rama actualizada es algo muy sencillo que se resuleve simplemente con descargar la última versión de la rama de unión (master, develop o decide-part-zumeta-censo en el caso de nuestro proyecto). Cualquiera de estas ramas, debemos asumir que no tienen errores y que podremos trabajar en nuestro campo sin ningún tipo de problema.

Para la relización de esta tarea se debe utilizar el comando git pull desde la rama a la que se han ido añadiendo cambios definitivos hacia tu workspace y despues hacer un merge desde tu rama de trabajo única.

Hacer commit con frequencia

La realización de esta práctica es necesaria para evitar errores que no dependen tanto de los humanos si no de las maquinas y es que nunca se sabe cuando se puede perder la información guardada dentro de un disco duro, por supuesto esto podría ocurrir por un error humano pero entendemos que ninguno de los desarrolladores cometerán la fatal decisión de fromatear el ordenador o de borrar archivos que no deben de forma voluntaria.

En cualquier caso, esta perdida de información puede ocurrir y evitarlo requiere desarrollar la costumbre de utilizar la nube que nuestra herramienta gestora de versiones con asiduidad y guardar los cambios que vamos realizando de forma remota cada vez que terminamos de trabajar.

En la herramienta que estamos utilizando basta con utilizar el comando git commit una vez hecho el “stash” de los cambios que queremos guardar en la nube.

Subir codigo definitivo a una rama de unión

Como hemos comentado con anterioridad, cada vez que queramos actualizar nuestra rama con los cambios que nuestros compañeros han hecho, estos deben ser cambios que no me produzcan ningun tipo de problema a la hora de trabajar en mi tarea. Para esto, y es uno de los puntos mas importantes, NO se pueden subir errores a ramas comunes con otros desarrolladores.

El codigo que subamos, como bien dice el título, debe ser código definitivo, esto quere decir que no requiere de ningun tipo de modificación para su correcto funcionamiento.

La forma de comprobar que una parte de código que hemos desarrollado no conlleve errores consigo es la relizacion de pruebas de código, esta practica consiste en poner a trabajar el modulo bajo diferentes situaciones y observar como reacciona. Comprobaremos que las reacciones son las esperadas y en caso contrario no debemos subir el código hasta que todas las pruebas sean satisfactorias. Como es lógico , cuantas mas pruebas realicemos sobre una parte del código, mas fiable será. Tampoco hay que llegar hasta el punto de lo absurdo en el que se realizan pruebas redundantes por querer probar absolutamente todos y cada uno de los aspectos del software, hay cosas que se asume no pueden producir errores por la baja probabilidad con la que estos pueden ocurrir.

Existen herramientas para la automatización de estas tareas, La primera, incluida en el propio framework que utilizamos para el desarrollo de la aplicación, django, TestCase es el módulo que este utiliza para ayudarnos a automatizar estas pruebas.

Tambien utilizamos herramientas como Travis para la realizacion de estas pruebas antes de hacer un merge a una rama de unión.

Documentar y definir correctamente los cambios

Una parte muy importante a la hora de comprobar los diferentes cambios para la comprensión de las diferentes versiones del codigo fuente es el saber que, quien, donde, cuando y como ha realizado estos cambios. Esto esta definido en cada uno de los commit que se realizan gracias al establecimiento de un método para llevar control sobre ello.

El que se ha relizado y como , esta reflejado en un documento o mensaje asociado con cada commit en el que de forma breve, concreta y concisa se define que cambios se han realizado. Este mensaje debe contener el campo en el que se ha estado trabajando, funcionalidad, configuración, arreglo_de_errores… son algunos ejemplos de posibles campos en los que se ha trabajado. Esto viene seguido de un pequeño título que, de forma imperativa define que cambios se han relizado para poder localizarlo mas facilmente. Este documento tambien incluye una descripción de como se han realizado estos cambios y posibles cosas a tener en cuenta cuando se esta estudiando el caso de ese commit en concreto.

Quien donde y cuando, esta refliejado en la propia herramienta que utilizamos para la gestión del código, la cual de forma bastante eficiente, asocia el perfil de la persona que ha hecho el commit, la hora y fecha a la que se ha hecho y tambien nos define en que rama se ha realizado. De forma adicional, nos ofrece información de que documentos has sido modificados, añadidos o eliminados para poder localizar estos cambios de forma eficiente.

Todos los miembros de equipo de desarrollo deben utilizar una plantilla común para el mensaje del commit anteriormente definido siendo imperativo la utilización de la misma. Git nos ofrece una forma de tener todos la misma plantilla y es a traves de la variable template del git Config a que se le alade un archivo .gitmessage con este formato:

(Tipo de cambio) Un encabezado
Cuerpo del commit

Gestión de las ramas

Refireindonos a la gestión de las ramas de “union”, nuestro proyecto cuenta con una rama principal llamada decide-part-zumeta-census, esta es la rama principal, donde se unen definitivamente los cambios realizados en cada una de las tareas asociadas al modulo census. Cada modulo que se va a a ser modificado en este proyecto cuenta con una rama principal gestionada por un grupo diferente.

Se deben crear sub-ramas a la rama principal. El formato del nombre de estas ramas es: task/[nombre_de_la_tarea]. Los desarrolladores trabajarán en esta rama hasta que una parte del codigo esté inplementado y funcional, momento en el que se unen los cambios con la rama principal y se comprueba que no haya conflictos ni errores probando los cambios en diferentes entornos.

Para unir los diferentes cambios realizados en cada uno de los modulos, se utiliza la rama develop. Estos cambios se unen cuando cada una de las ramas principales ha terminado su tarea asignado y esta completamente funcional.

Gestión de liberaciones, despliegue y entregas

Gestión de liberaciones

La liberación del proyecto “decide-part-zumeta” toma lugar una vez están todos los subsistemas (censo, votación y postprocesado) integrados en el sistema final.

Se considera que el desarrollo del proyecto ha concluido cuando se ha implementado toda la funcionalidad correspondiente con el subsistema censo, se ha realizado la integración con los otros dos subsistemas (votaciones y postprocesado) que componen el grupo de “decide-part-zumeta” y se han realizado pruebas del sistema por completo.

Tras la implementación de la funcionalidad esta debe de ser testeada para asegurar el funcionamiento correcto del proyecto, para ello el grupo “decide-part-zumeta-censo” ha realizado pruebas unitarias y de vistas.

Las pruebas unitarias se encargan de comprobar que un fragmento del código funciona correctamente. De esta manera se detectan errores en la implementación de las diferentes funcionalidades y se asegura que estas funcionarán en cualquier caso. Para ello se hace uso del framework de pruebas unittest el cual está inspirado en Junit.

Las pruebas de las vistas son las encargadas de comprobar que se muestran los resultados esperados a la hora de utilizar el sistema. Para estos tests se hace uso del framework Selenium. Se trata de utilizar la extensión de Selenium para el navegador, el cual realiza una grabación de los comandos que se ejecutan a la hora de utilizar el sistema. A la hora de pasar los tests de vistas, Selenium simula cómo actuaría un usuario frente al sistema, determinando así si se consigue mostrar los resultados esperados.

Una vez se han realizado todos estos procesos, se configura Travis en el sistema.

Travis es un servicio de integración continua que se integra con GitHub con el objetivo de probar el código de un determinado proyecto. En este sistema, Travis se encarga de ejecutar los test unitarios que se encuentran en el proyecto determinando si estos no tienen fallos. Una vez se han realizado estos procesos, el desarrollo habrá concluido y se despliega la aplicación en Heroku.

Gestión de despliegue

Una vez el desarrollo del proyecto ha concluido, se despliega la aplicación en la web con el objetivo de que sea accesible por los usuarios. Para ello se hace uso de la plataforma Heroku.

Heroku es una PaaS (plataforma como servicio) de computación en la nube que soporta distintos lenguajes de programación basado en contenedores. Se encarga del despliegue de sistemas en la nube.

El proceso seguido para el despliegue en Heroku es el siguiente:

Se unen todas las ramas principales de cada uno de los subsistemas en la rama develop con el fin de comprobar que todas las funcionalidades implementadas funcionan de forma correcta.
Se configura Heroku en el sistema a través de los archivos “Procfile”, “settings.py” y “requirements.py”.
En la página oficial de Heroku se crea una aplicación, enlazando esta con el repositorio en GitHub del equipo.
Una vez todo está integrado se mergea la rama develop en la rama principal, master.
Se despliega el sistema en Heroku.

Además de esto, el sistema puede ser desplegado también en Docker.

Docker es “un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software automatizando la virtualización de aplicaciones en múltiples sistemas operativos”.

En este proyecto en concreto, docker-compose lanza tres contenedores: uno para el servidor de la base de datos (decide_db), otro para el de django (decide_web) y un último para servir los ficheros estáticos y hacer de proxy al servidor de django (decide_nginx). Para desplegar con Docker se deben configurar los archivos “Dockerfile”, “docker-compose” y docker-settings”. Una vez está todo configurado, se crean las imágenes y despliega el sistema.

Gestión de entregas

El Project Manager será el encargado de realizar las entregas pertinentes a través de la plataforma de Enseñanza Virtual en las fechas especificadas en este apartado, así como el registro del grupo en la plataforma especificada por los profesores para las defensas de este mismo proyecto. Todas las entregas deben incluir el avance en el desarrollo del producto junto a su correspondiente documentación y las actas de reuniones del diario de equipo. Los documentos serán entregados en la wiki del repositorio en GitHub del sistema del equipo “decide-part-zumeta”. Desde el comienzo del desarrollo del producto hasta conseguir su versión final, se han de realizar cinco entregas en las fechas especificadas:

M0 (30 octubre 2020): en la primera de las entregas el equipo se ha de registrar en la plataforma de la asignatura de modo que se asigne un tutor de proyecto.
M1 (6 noviembre 2020): esta entrega debe componerse del “Acta fundacional” en la que el equipo establece los acuerdos que van a guiar a los desarrolladores en el proceso, además de un vídeo que muestre el sistema Decide esté instalado en el equipo, desplegado y pasando todas las pruebas realizadas. Por último, el equipo debe haber decidido cual es el subsistema sobre el que va a trabajar y realizar los incrementos pertinentes.
M2 (7 enero 2021): en el intervalo del 22 de diciembre al 1 de enero el Project Manager debe elegir una franja horaria en la que se realizará una defensa del proyecto en los horarios disponibles del tutor asignado en la primera de las entregas. Esto es un simple seguimiento del trabajo realizado por lo que no debe estar completo pero sí al menos haber desarrollado el 80% del trabajo final. De este modo, el equipo tendrá constancia de cuáles son los cambios que se tienen que realizar en caso de que haya alguno y conocer si el avance realizado por parte del equipo es el esperado.
M3 (18-29 enero 2020): tras elegir una fecha en el horario disponible del tutor asignado en el intervalo del 11 de enero hasta el 14 de enero, se realiza la defensa final del proyecto completado al 100% y desplegado en la nube. Una vez realizada la entrega, no se podrá modificar nada sobre el proyecto. La defensa se realizará frente al tutor el cual puede realizar cualquier tipo de pregunta sobre el sistema que los desarrolladores deben contestar de manera correcta. Cada uno de los integrantes deberá tener en su máquina el sistema operativo y preparado para realizar las pruebas pertinentes.
M4 (5 febrero 2021): este día tienen lugar las mejoras del proyecto, que coincide con la fecha de convocatoria oficial de febrero. En caso de no superar los requisitos mínimos del desarrollo del proyecto en la entrega anterior o querer mejorar este, se realizan ciertas mejoras en él de acuerdo a que los desarrolladores entreguen un producto de mejor calidad que el entregado en el M3.

Conclusiones y trabajo futuro

Tras la finalización de nuestro proyecto podemos sacar una serie de conclusiones de cara a trabajos futuros como equipo. La implementación de las funcionalidades escogidas no ha sido una gran adversidad, aunque sí nos ha costado llevar a cabo algunas tareas en conjunto con todos los equipos debido a que:

La organización grupal no ha sido lo más organizada que podría haber sido, aunque siempre se ha intentado hacer de la forma más sistemática posible. Sin embargo, nunca es fácil avanzar y trabajar a la vez y de forma equitativa en un grupo tan amplio.
El poco conocimiento inicial sobre el proyecto de decide y su funcionamiento también ha sido un obstáculo en el avance rápido, sobre todo en la fase de inicio. Además del uso de nuevas tecnologías y herramientas.
Por la parte de organización interna como grupo censo, cabe destacar que la comunicación no ha sido un punto fuerte en el desarrollo del proyecto. Aunque nos hemos mantenido lo suficiente comunicados, muchos conflictos entre tareas podrían haberse evitado si todo el grupo hubiese estado al día en el avance del proyecto.

Independientemente de esto, se puede decir que hemos cumplido con los objetivos en cuanto a desarrollo, ya que se ha completado con las tareas estipuladas al inicio del sprint e incluso se han añadido tareas adicionales en la fase final para mejorar el subsistema escogido.

Como conclusiones de cara a un futuro trabajo en equipo podemos sintetizar los puntos anteriores en dos ideas claras. Por una parte, la comunicación es un punto muy importante para avanzar correctamente y evitar conflictos innecesarios, y todos debemos aportar mayor implicación para mantener dicha comunicación. En cuanto al trabajo conjunto de los tres equipos, se debe estudiar e investigar inicialmente cada tarea individualmente, para estipular desde un principio las dependencias necesarias entre los grupos y determinar el trabajo ajeno del que debemos disponer antes de comenzar con el nuestro. La implicación de cada miembro, tanto en su subsistema específico como en el proyecto general, debe ser la necesaria por parte de todos.