Administración de censos - 17 18 - G1

Miembros

• Juan Diego Guerrero Carbonell
• Gonzalo López Heredia
• Carlos Lozano Toré
• Francisco Márquez Orellana
• Manuel Serrano Guerrero

Objetivos

Nuestra labor consiste en administrar los diferentes censos que surgen cada vez que se crea una nueva votación y gestionar los usuarios que pueden participar en cada censo

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible a través de este enlace

Opera

El proyecto en Opera del grupo será accesible a través de este enlace

Resumen

Administración de censo es una de las capas más importantes del sistema de votación. En cualquier votación una de las piezas claves es su censo electoral, ya que este determina quienes son las personas que tienen derecho a ejercer su voto, además de controlar si estos lo han ejercido o no. Para que una votación se considere democrática y legítima no pueden ocurrir vulnerabilidades en su censo, como por ejemplo que una misma persona vote más de una vez o que una persona que no esta incluida en el censo ejerza su voto, desde Administración de censo nos proponemos la construcción de un subsistema encargado de garantizar que estas vulnerabilidades no ocurran.

Introducción y contexto

Nuestro subsistema es Administración de Censo, es el encargado de administrar los diferentes censos que surgen cada vez que se crea una nueva votación y gestionar los usuarios que pueden participar en cada una de estas. En principio decidimos utilizar el código heredado del año anterior, este estaba realizado en Java utilizando como herramienta Eclipse Indigo, tenía el sistema de librerías de Maven y utilizaba una base de datos MySQL. El primer problema que encontramos fue que este proyecto no estaba acabado ya que no incluía todas las librerías necesarias además de contener errores y métodos no optimizados. Con este punto de partida nuestros objetivos eran optimizar el código heredado refactorizando los métodos, añadiendo las librerías faltantes así como incluyendo la funcionalidad de poder censar usuarios masivamente. Tras la reunión inicial de todos los grupos encargados de los subsistemas desde integración nos informaron que la base de datos utilizada sería MariaDB lo cual complicaba mucho nuestra conexión a esta. Finalmente decidimos reescribir el código en Python lo cual además de facilitar nuestra conexión a la base de datos nos permitía utilizar un framework más actualizado.

Descripción del sistema

El sistema de Administración de censo se trata de un sistema escrito en Python que garantiza las funcionalidades comentadas en los puntos anteriores. Dependemos directamente de Autentificación y Administración de votaciones depende de nosotros. Nuestra herramienta base es GitHub ya que a través de este hemos creado las distintas tareas y hemos llevado el control sobre estas. También hemos empleado Travis CI para desarrollar las nuevas funcionalidades implementadas asegurando su correcto funcionamiento. TODO: Poner más

Planificación del proyecto

La comunicación para el proyecto se realizará mediante WhatsApp debido a los distintos horarios de los integrantes del grupo se realizarán reuniones presenciales cuando sean indispensables. Para el reparto de tareas hemos utilizado el sistema de issues de Github el cual nos permite asignar a cada miembro una tarea en concreto, el coordinador es el encargado del reparto de tareas. Se intentará equilibrar la implementación del proyecto con la realización de documentación para que todos los integrantes se encarguen de ambas funciones. Las tareas se irán realizando para completar los distintos Milestones de las asignaturas estas pueden verse explícitamente en el Diario del Grupo o en el repositorio de Github.

Entorno de desarrollo

Nuestro entorno de desarrollo se apoya en linux para la ejecución de las librerías que debajo se detallan:

- Lenguaje de desarrollo: python2.7 - Base de datos: MariaDB 10.0.31 - Framework: Django 1.5

Instalación del subsistema al completo:

Una vez estemos en una distribución de ubuntu (linux) empezaremos a instalar las librerías necesarias para la ejecución de nuestro proyecto en el entorno de desarrollo.

Gestión del cambio, incidencias y depuración

Para la gestión de incidencias hemos empleado GitHub, tenemos que diferenciar entre las incidencias internas que serán las originadas en nuestro grupo de trabajo y las incidencias externas que serán las que recibiremos de otros grupos o realizaremos a estos. Incidencias Internas: Una vez se encuentra una incidencia en el subsistema se abre una issue en GitHub la cual se le etiqueta como bug en esta se intentará aportar la mayor información posible, posteriormente el coordinador del grupo asignará resolver este bug como tarea a uno de los integrantes del grupo. Las incidencias pueden tener el estado In Progress o Done en este último caso se considerará resuelta y se cerrara la issue. También deben estar etiquetadas según la preferencia, las posibles etiquetas son High, Medium o Low. Es importante que si una incidencia esta relacionada con un commit determinado en la información de la incidencia debe indicarse. Los commits harán referencia a sus issues correspondientes para llevar el progreso de cada incidencia Incidencias Externas: En el caso de las incidencias que nos notifiquen otro grupo será el coordinador el encargado de asignar el estudio de esta a uno de los integrantes del grupo siguiendo el reparto de funcionalidades interno de nuestro subsistema. Para el caso de las incidencias que deseemos notificar a otros grupos en primer lugar notificaremos al coordinador de nuestro grupo la incidencia aportando toda la información posible así como el subsistema referido, el coordinador genera una issue en el repositorio del grupo correspondiente al que se le quiere hacer la consulta o incidencia.

Gestión del código fuente

Para la gestión del código estamos empleando Github y su sistema de ramas (branches): • Los commits al repositorio los realizaremos con el siguiente formato: Tipo: Titulo del commit Línea en blanco Cuerpo del commit Línea en blanco Pie del commit

Tipo: Puede ser New(archivo nuevo) o Update(Actualización). Título: Se representa con una almohadilla con el número de la issue que se referencia y una breve descripción de la misma. Cuerpo del commit: Descripción detallada del commit realizado. Pie del commit: Indica la etiqueta de cierre del commit.

Nuestro proyecto consta de dos ramas, Master y Develop • Master: Se utilizará para las versiones del proyecto estables que se saquen a producción. • Develop: En esta rama añadiremos las diferentes funciones mientras que el proyecto esté incompleto.

Se hará commit cuando la funcionalidad esté correctamente probada e integrada. Haremos un push en la rama Develop y una vez que la funcionalidad esté aprobada se hará un merge a la rama Master.

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

Como método de construcción e integración continua, en nuestro proyecto estamos empleando Travis CI basada en contenedores, que es la opción por defecto. Es un Linux Ubuntu ejecutándose en un contenedor. Se ejecuta más rápido que la basada en máquinas virtuales, pero no soporte el uso de sudo, setuid o setgid.

Como una plataforma de integración continua, Travis CI respalda el proceso de desarrollo creando y probando automáticamente los cambios de código, proporcionando retroalimentación inmediata sobre el éxito del cambio. Travis CI también puede automatizar otras partes del proceso de desarrollo administrando despliegues y notificaciones.

Cuando se ejecuta una compilación, Travis CI clona el repositorio de GitHub en un nuevo entorno virtual y lleva a cabo una serie de tareas para crear y probar su código. Si una o más de esas tareas falla, la compilación se considera rota. Si ninguna de las tareas falla, la construcción se considera aprobada, y Travis CI puede implementar el código en un servidor web o servidor de aplicaciones.

Gestión de liberaciones, despliegue y entregas

• Proceso definido para las liberaciones: TODO • Proceso definido para el despliegue: Se han implementado los archivos necesarios para introducir la aplicación en un contenedor docker que permita la comunicación con el contenedor de la base de datos MariaDB. • Proceso definido para las entregas: Se ha seguido un proceso de entrega diferente dependiendo del milestone: • Milestone 2: A través de correo electrónico. • Milestone 4: A través de Ópera. Sólo ha habido entregables para esos 2 milestones, el resto de la información se encontrará alojada en la wiki de nuestro grupo. • Política de nombrado e identificación de los entregables: El nombre de los entregables sigue el siguiente formato XX-subsistema-GY.* siendo XX el ID de Ópera e Y el número de nuestro grupo.

Mapa de herramientas

Nuestro proyecto está completamente gestionado con Github y su sistema de issues y branches por lo que no hay diferentes herramientas que tengan relación entre sí.

Ejercicio de propuesta de cambio

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

Conclusiones y trabajo futuro

Nuestra idea inicial era añadir como funcionalidad la posibilidad de censar de manera masiva, pero debido a que tuvimos problemas para conectar con la base de datos MariaDB, fue necesario reescribir todo el código heredado en Python, lo que no nos ha dejó tiempo suficiente para añadirla. Esta funcionalidad en relación al censo sería una buena propuesta para añadir el próximo curso.