Wiki de EGC - Contribuciones del usuario [es]

Censo-G1-2-17-18

2018-08-10T10:42:06Z

Framarore:

* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Entorno de despliegue] (ponga aquí el enlace al entorno de despliegue)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Diario del grupo] (ponga aquí el enlace al diario del grupo)

Aclaraciones:
Esta entrega será hecha por un subgrupo del grupo encargado de la gestión del censo en la primera convocatoria y será una continuacion de dicho proyecto.
El subgrupo estará formado por Juan Diego Guerrero Carbonell y Francisco Márquez Orellana.

Censo-GX-2-17-18

2018-08-10T10:41:05Z

Framarore: Página blanqueada

Censo-G1-2-17-18

2018-08-10T10:40:34Z

Framarore: Página creada con « * [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto) * [http://1984.lsi.us.es/w...»

* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Entorno de despliegue] (ponga aquí el enlace al entorno de despliegue)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Diario del grupo] (ponga aquí el enlace al diario del grupo)

Aclaraciones:
Esta entrega será hecha por un subgrupo del grupo encargado de la gestión del censo en la primera convocatoria y será una continuacion del mismo.
El subgrupo estará formado por Juan Diego Guerrero Carbonell y Francisco Márquez Orellana.

Zona entrega de proyectos - 17/18

2018-08-10T10:40:20Z

Framarore:

[[Página_Principal]] -> [[2017/2018]] -> [[Trabajo - 17/18]] -> [[M6-17 18]]

En esta página se hará entrega de los proyectos y para ello se usará el formato que se muestra a continuación como Ejemplo. Cree una página por cada proyecto que vaya a entregar y copie la plantilla necesaria para hacerlo. Siga el mismo formato que se pide. Los trabajos que no sigan dicho formato tendrán una penalización.

== Entregas segunda convocatoria Septiembre 2017/2018 ==

* [[NombreDeMiProyecto-GX-2-17-18]] (NombreDeMiProyecto será el nombre del proyecto como "Recuento, Cabina, etc.."; GX será o bien el G1 o bien el G2 al que pertenezca el alumno/a; 2-17-18 debe siempre aparecer así y significa que es la segunda convocatoria del curso 2017- 2018.
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[NombreDeMiProyecto-GX-2-17-18]]
* [[Censo-G1-2-17-18]]

Censo-GX-2-17-18

2018-08-10T10:37:31Z

Framarore:

* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Entorno de despliegue] (ponga aquí el enlace al entorno de despliegue)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Diario del grupo] (ponga aquí el enlace al diario del grupo)

Aclaraciones:
Esta entrega será hecha por un subgrupo del grupo encargado de la gestión del censo en la primera convocatoria y será una continuacion del mismo.
El subgrupo estará formado por Juan Diego Guerrero Carbonell y Francisco Márquez Orellana.

Censo-GX-2-17-18

2018-08-10T10:26:34Z

Framarore: Página creada con «* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto) * [http://1984.lsi.us.es/wi...»

* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Entorno de despliegue] (ponga aquí el enlace al entorno de despliegue)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Diario del grupo] (ponga aquí el enlace al diario del grupo)

Aclaraciones:
Esta entrega será hecha por un subgrupo del grupo encargado de la gestión del censo en la primera convocatoria y será una continuacion del mismo.
El subgrupo estará formado por Juan Diego Carbonell Guerrero y Francisco Márquez Orellana.

NombreDeMiProoyecto-GX-2-17-18

2018-08-10T10:26:13Z

Framarore: Página blanqueada

Zona entrega de proyectos - 17/18

2018-08-10T10:25:22Z

Framarore:

NombreDeMiProoyecto-GX-2-17-18

2018-08-10T10:24:05Z

Framarore: Página creada con «* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto) * [http://1984.lsi.us.es/wi...»

* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Documento del proyecto] (ponga aquí el enlace al documento del proyecto)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Entorno de despliegue] (ponga aquí el enlace al entorno de despliegue)
* [http://1984.lsi.us.es/wiki-egc/images/egc/7/7d/TrabajoEGC_17_18.pdf Diario del grupo] (ponga aquí el enlace al diario del grupo)

Aclaraciones:
Esta entrega será hecha por un subgrupo del grupo encargado de la gestión del censo en la primera convocatoria y será una continuacion del mismo.
El subgrupo estará formado por Juan Diego Carbonell Guerrero y Francisco Márquez Orellana.

Zona entrega de proyectos - 17/18

2018-08-10T10:19:22Z

Framarore:

Administración de censos - 17 18 - G1

2018-01-14T22:50:04Z

Framarore: /* Ejercicio de propuesta de cambio */

== '''Miembros''' ==
<ul>
<li>Juan Diego Guerrero Carbonell</li>
<li>Gonzalo López Heredia</li>
<li>Carlos Lozano Toré</li>
<li>Francisco Márquez Orellana</li>
<li>Manuel Serrano Guerrero</li>
</ul>

== '''Proyecto desplegado'''==
Enlace al proyecto desplegado
https://g1admcensos.egc.duckdns.org

== '''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 [https://github.com/Proyecto-EGC-G1/AdminCensos-EGC-G1 enlace]

== '''Opera''' ==

El proyecto en Opera del grupo será accesible a través de este [http://opera.eii.us.es/egc/public/grupo/ver/id/94 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 junto al framework Spring, utilizando como herramienta Eclipse Indigo. Tenía el sistema de librerías de Maven y utilizaba una base de datos MySQL. Montamos y arreglamos todo el entorno de desarrollo ya que tenia algunos problemas. Empezamos a trabajar en ese entorno.
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. Por lo tanto intentamos implementar el uso de ésta nueva base de datos pero fue imposible.
Finalmente decidimos reescribir todo el código en Python usando el framework Django facilitándonos la conexión a la base de datos.

=='''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

=='''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:

<ul>
<li>Lenguaje de desarrollo: python2.7</li>
<li>Base de datos: MariaDB 10.0.31</li>
<li>Framework: Django 1.5</li>
<li>Docker: Despliegue de la base de datos mariaDB</li>
</ul>

== Instalación del subsistema al completo ==

Desde una distribución de linux haremos el despliegue del entorno de desarrollo.

1. En primer lugar desplegamos la base de datos, necesaria para la ejecución del proyecto. Para ello ejecutaremos el siguiente comando en la raíz del archivo docker-compose.yml de la base de datos mariaDB proporcionado por el grupo de integración. Gracias a docker tendremos la base de datos funcionando en pocos segundos.

docker-compose up -d --build

2. Instalar las dependencias del proyecto. Para ello tenemos que ejecutar los siguientes comandos gracias al gestor de dependencias pip de python2.7:

pip install -r requirements.txt
pip install MySQL-python

3. Finalmente podemos ejecutar el servidor del proyecto

=='''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. Se etiquetará en función de sus características. En cada incidencia se intentará aportar la mayor información posible, posteriormente el coordinador del grupo asignará la issue a los encargados del grupo de resolverla.
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

Título: Una breve descripción de qué se ha cambiado

Cuerpo del commit: Descripción detallada del commit realizado.

Pie del commit: Referencia con una almohadilla con el número de la issue que se referencia

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.</li>

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''' ==
<ul>
<li>Proceso definido para las liberaciones: Se creará una liberación con cada versión estable del proyecto. Una vez se haya realizado el merge de la rama develop a master es cuando se liberará una versión del proyecto. El coordinador será la persona responsable de decidir el momento. Cada versión se nombrará con las directivas proporcionadas por el grupo de integración
</li>
<li>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.</li>
<li>Proceso definido para las entregas: Se ha seguido un proceso de entrega diferente dependiendo del milestone:</li>
<li>Milestone 2: A través de correo electrónico.</li>
<li>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.</li>
<li>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.</li>
</ul>

=='''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'''==
Se propone incluir un sistema de censado de usuario, el cual podrá seleccionar a que censo quiere pertenecer. La versión actual del sistema esta implementada en java, lo cual daba problemas a la base de datos a través MariaDB, que es el método de conexión empleado por el resto de subsistemas, por lo que se ha reescrito el código empleando Python como lenguaje de programación.
En primer lugar se crea una issue en github para solicitar el cambio a realizar. Dicha isssue es asignada por el coordinador del equipo, o el propio creador de la misma en caso de que se haya hablado previamente.
El miembro del equipo que tiene asignada una nueva issue recibe un correo electrónico indicándoselo. El desarrollo está siendo realizado en Enclipse Neon y, como se describe en la sección gestión de código, es gestionado mediante el sistema de branches de Github, subiendo los cambios a la rama Develop.
Será necesario que MariaDB esté desplegada para poder ver los cambios en local antes de hacer los commits
TravisCI ejecuta las pruebas funcionales automáticamente una vez llega un cambio al repositorio. Si pasan el build de TravisCI, los cambios son integrados, en caso contrario se indica a través de la issue correspondiente con un comentario.
Las pruebas se ejecutarán con jUnit, en local, antes de subirlas al repositorio.
A partir de este punto se comprobará que el commit no incluye ningún error o en el caso de que se diera se añadiria esta información a la issue de Github (comenzando de nuevo el proceso anteriormente descrito en desarrollo), para conocer si el commit pasa las pruebas utilizaremos la utilidad de contruccion de TravisCI.
Una vez somos conocedores de que los cambios pasan las pruebas de TravisCI podemos unirlo al proyecto, para esto uniremos la rama develop con la rama master a traves del comando git merge, y haremos git push para actualizar el repositorio remoto.
Una vez unidas la rama develop y master TravisCI creara un contenedor Docker y lo subira al repositorio DockerHub aplicando los cambios en el servidor de integración.
Finalmente procederemos a una nueva liberación o release en la que se deberá notificar todos los cambios aplicados.

=='''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.

Administración de censos - 17 18 - G1

2018-01-14T22:49:09Z

Framarore: /* Ejercicio de propuesta de cambio */

== '''Miembros''' ==
<ul>
<li>Juan Diego Guerrero Carbonell</li>
<li>Gonzalo López Heredia</li>
<li>Carlos Lozano Toré</li>
<li>Francisco Márquez Orellana</li>
<li>Manuel Serrano Guerrero</li>
</ul>

== '''Proyecto desplegado'''==
Enlace al proyecto desplegado
https://g1admcensos.egc.duckdns.org

== '''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 [https://github.com/Proyecto-EGC-G1/AdminCensos-EGC-G1 enlace]

== '''Opera''' ==

El proyecto en Opera del grupo será accesible a través de este [http://opera.eii.us.es/egc/public/grupo/ver/id/94 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 junto al framework Spring, utilizando como herramienta Eclipse Indigo. Tenía el sistema de librerías de Maven y utilizaba una base de datos MySQL. Montamos y arreglamos todo el entorno de desarrollo ya que tenia algunos problemas. Empezamos a trabajar en ese entorno.
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. Por lo tanto intentamos implementar el uso de ésta nueva base de datos pero fue imposible.
Finalmente decidimos reescribir todo el código en Python usando el framework Django facilitándonos la conexión a la base de datos.

=='''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

=='''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:

<ul>
<li>Lenguaje de desarrollo: python2.7</li>
<li>Base de datos: MariaDB 10.0.31</li>
<li>Framework: Django 1.5</li>
<li>Docker: Despliegue de la base de datos mariaDB</li>
</ul>

== Instalación del subsistema al completo ==

Desde una distribución de linux haremos el despliegue del entorno de desarrollo.

1. En primer lugar desplegamos la base de datos, necesaria para la ejecución del proyecto. Para ello ejecutaremos el siguiente comando en la raíz del archivo docker-compose.yml de la base de datos mariaDB proporcionado por el grupo de integración. Gracias a docker tendremos la base de datos funcionando en pocos segundos.

docker-compose up -d --build

2. Instalar las dependencias del proyecto. Para ello tenemos que ejecutar los siguientes comandos gracias al gestor de dependencias pip de python2.7:

pip install -r requirements.txt
pip install MySQL-python

3. Finalmente podemos ejecutar el servidor del proyecto

=='''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. Se etiquetará en función de sus características. En cada incidencia se intentará aportar la mayor información posible, posteriormente el coordinador del grupo asignará la issue a los encargados del grupo de resolverla.
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

Título: Una breve descripción de qué se ha cambiado

Cuerpo del commit: Descripción detallada del commit realizado.

Pie del commit: Referencia con una almohadilla con el número de la issue que se referencia

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.</li>

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''' ==
<ul>
<li>Proceso definido para las liberaciones: Se creará una liberación con cada versión estable del proyecto. Una vez se haya realizado el merge de la rama develop a master es cuando se liberará una versión del proyecto. El coordinador será la persona responsable de decidir el momento. Cada versión se nombrará con las directivas proporcionadas por el grupo de integración
</li>
<li>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.</li>
<li>Proceso definido para las entregas: Se ha seguido un proceso de entrega diferente dependiendo del milestone:</li>
<li>Milestone 2: A través de correo electrónico.</li>
<li>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.</li>
<li>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.</li>
</ul>

=='''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'''==
Se propone incluir un sistema de censado de usuario, el cual podrá seleccionar a que censo quiere pertenecer. La versión actual del sistema esta implementada en java, lo cual daba problemas a la base de datos a través MariaDB, que es el método de conexión empleado por el resto de subsistemas, por lo que se ha reescrito el código empleando Python como lenguaje de programación.
En primer lugar se crea una issue en github para solicitar el cambio a realizar. Dicha isssue es asignada por el coordinador del equipo, o el propio creador de la misma en caso de que se haya hablado previamente.
El miembro del equipo que tiene asignada una nueva issue recibe un correo electrónico indicándoselo. El desarrollo está siendo realizado en ….. y, como se describe en la sección gestión de código, es gestionado mediante el sistema de branches de Github, subiendo los cambios a la rama Develop.
Será necesario que MariaDB esté desplegada para poder ver los cambios en local antes de hacer los commits
TravisCI ejecuta las pruebas funcionales automáticamente una vez llega un cambio al repositorio. Si pasan el build de TravisCI, los cambios son integrados, en caso contrario se indica a través de la issue correspondiente con un comentario.
Las pruebas se ejecutarán con jUnit, en local, antes de subirlas al repositorio.
A partir de este punto se comprobará que el commit no incluye ningún error o en el caso de que se diera se añadiria esta información a la issue de Github (comenzando de nuevo el proceso anteriormente descrito en desarrollo), para conocer si el commit pasa las pruebas utilizaremos la utilidad de contruccion de TravisCI.
Una vez somos conocedores de que los cambios pasan las pruebas de TravisCI podemos unirlo al proyecto, para esto uniremos la rama develop con la rama master a traves del comando git merge, y haremos git push para actualizar el repositorio remoto.
Una vez unidas la rama develop y master TravisCI creara un contenedor Docker y lo subira al repositorio DockerHub aplicando los cambios en el servidor de integración.
Finalmente procederemos a una nueva liberación o release en la que se deberá notificar todos los cambios aplicados.

=='''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.