Wiki de EGC - Contribuciones del usuario [es]

Frontend y visualización de resultados

2016-01-08T13:13:18Z

Danmarrod: /* Actas */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

Nota: Procedimiento basado en trabajo de años anteriores.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (02/12/2015)]]
* [[Actas del primer taller de integración (GVR) |Informe 01 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Informe 02 - Segundo taller de integración (01/12/2015)]]
* [[Actas del primer taller de integración (GVR) |Informe 03 - Tercer taller de integración (15/12/2015)]]

----

Diario de Grupo

2016-01-08T12:59:20Z

Danmarrod:

'''[08 Octubre, 2015]'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Redactamos posibles mejoras que pueden aplicarse al subsistema:
*Actualización automática de gráficas (Ajax).
*Cambiar la base de datos.
*Nuevas funcionalidades (exportar resultados).
*Nuevas librerías de visualización (GoogleCharts, Bootstrap).
*Compatibilidad con dispositivos móviles.

Se redacta [[Acta de creación de grupos (GVR) |Acta01]].

<gallery>
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
</gallery>

'''[13 Octubre, 2015]'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

<gallery>
Archivo:EGCG10-05.jpg | Fechas de integracion
</gallery>

'''[20 Octubre, 2015]'''

Se acuerda uso de repositorio distribuido GIT y se establecen las directrices generales del modelo de uso:

Pautas a la hora de realizar commits en GIT
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

'''[10 Noviembre, 2015]'''

Se fija la fecha para la entrega del proyecto el día 26 de diciembre de 2015 (hasta las 23:59).
Se indica que habrá una segunda entrega de recuperación o para subir nota.

'''[11 Noviembre, 2015]'''

Previo a la primera fecha de integración se acuerda el estudio de los documentos y códigos disponibles sobre los subsistemas.
Se redefinen las modificaciones a aplicar:

*Cambio Base de Datos
*Aplicar geolocalización a los resultados.
*Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

Se crea equipo de trabajo y repositorio GIT en www.github.com

Se crea grupo en projetsii para documentación interna y gestión de tareas

Se analizan posibles herramientas para la gestión de incidencias

Se redacta [[Actas del primer taller de integración (GVR) |Acta 03]]

'''[17 Noviembre, 2015]'''

Primer día de integración:
*Toma de contacto con el resto de subsistemas, se busca la forma de hacer funcionar el sistema anterior.
*Se crea grupo informal de whatsapp como comunicación temporal con el subsistema de Recuento.
*Se define el responsable de la comunicación con el resto de grupo >> Daniel Sánchez Navarro.
*Se propone usar github con el resto de subsistemas para registro de incidencias.

Se redacta ACTA04

'''[19 Noviembre, 2015]'''

Se toman las siguientes decisiones y asignan las responsabilidades:

*Gestión tareas y grupo en projetsii >> Daniel Martín Rodrigo
*Diario de grupo (wiki,actas) >> Daniel Martín Rodrigo
*Responsable de comunicación externa (coordinador) >> Daniel Sánchez Navarro
*Metodología de trabajo SCRUM
*Modelo de uso del repositorio
*Gestor de incidencias GitHub
*Se define la plantilla para documentación
*Fijar fecha para reuniones

Se fijan los siguientes hitos y se planifican las tareas hasta la siguiente fecha de integración, día 1 de Diciembre:

*Martes 24 fecha tope para levantar el sistema heredado.
(cerrar la baseline)

*Investigar alternativas para integrarse con los subsistemas directos implicados Recuento y Creación de votos.

*Ponerse de acuerdo con Recuento para compartir información
(lenguaje, formato, variables)

*Investigar unificación de los subsistemas Visualización - Frontend

*Investigar Bootstrap

*Investigar para aplicar Angula

*Investigar para sustituir Base de Datos

Se redacta ACTA05

'''[24 Noviembre, 2015]'''

Se propone al resto de grupo crear una '''Organización en GitHub''' para integrar todos los equipos. Se crean nueve grupos con dos repositorios para cada grupo, uno individual del grupo y otro común con el resto de equipo para la integración. Se asignan los permisos oportunos y se agrega a cada uno de los coordinadores que tendrán privilegios sobre su equipo y repositorio, será responsable de añadir a los miembros de cada uno de sus equipos.

La propuesta no fue bien recibida salvo un par de grupos. Quizás llegó demasiado tarde, había grupos que tenían avanzado su subsistema en otros repositorios. Sí se acuerda utilizar los equipos creados de la organización para el '''registro de incidencias'''. Algunos equipos terminan también utilizando los repositorios de la organización.

'''[30 Noviembre, 2015]'''

No es posible levantar nuestro subsistema si los subsistemas de Creación de votaciones y Recuento, de los que dependemos para la lista de votaciones y los resultados, no nos devuelven los JSON con esa información. Se decide simular la información con unos stubs que resuelven tales peticiones. De este modo ya podemos levantar el sistema.

Hasta tener avanzado la integración con Angular se decide posponer el cambio de la base de datos y centrarnos en la integración.

'''[01 Diciembre, 2015]'''

Día de la segunda integración. Tenemos el sistema más maduro pero aún no podemos integrarlo con el resto, los subsistemas de Recuento y Creación están teniendo algunos problemas. Se acuerda incorporar al formato JSON información sobre el código postal.
Se acuerda con todos los subsistemas desplegar cada uno de los subsistemas y publicar la url en la Organización de GitHub.

Se registra INFORME02

'''[02 Diciembre, 2015]'''

Se asiste a una reunión para el reparto de tareas hasta la próxima integración. Se analiza el impacto de la segunda integración y se toman las medidas para mejorar el sistema.
Reparto de tareas:
* Crear nueva rama y aplicar Angular : Daniel Sánchez
* Desplegar aplicación en Openshift: Valentín Barquero y Daniel Martín
* Aplicar nueva funcionalidad, donaciones por PayPal: Moisés Llamas

Se redacta ACTA04

'''[08 Diciembre, 2015]'''

De cara a formalizar el uso que hacemos inevitablemente de aplicaciones tipo WhatsApp, se busca una herramienta de comunicación más profesional. Se propone y decide usar la aplicación '''Slack''' de comunicación de equipos, con soporte para intercambio de archivos y con integración con GitHub (muestra commits e incidencias).

'''[15 Diciembre, 2015]'''

Día de la tercera integración. En vista de la situación general sobre la integración con otros subsistemas se decide aplazar la evaluación de esta integración y posponer la integración para después de las vacaciones de navidad.

Se registra INFORME03

'''[23 Diciembre, 2015]'''

Se hace un balance de la situación de todos los subsistemas y se resuelven dudas sobre la documentación a entregar. Nuestro subsistema se encuentra en la siguiente situación:
* Aplicación desplegada en Openshift: www.resultados-visualización.rhcloud.com
* Integración principal completada con Angular
* Integración completada con pago con PayPal

Frontend y visualización de resultados

2016-01-08T12:43:04Z

Danmarrod: /* Pautas a la hora de realizar commits en GIT */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

Nota: Procedimiento basado en trabajo de años anteriores.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

Frontend y visualización de resultados

2016-01-08T12:41:47Z

Danmarrod:

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

Nota: Información extraida de la documentación de los subsistemas anteriores.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

Frontend y visualización de resultados

2016-01-08T12:39:06Z

Danmarrod: /* Flujo entre subsistemas */

Frontend y visualización de resultados

2016-01-08T12:38:31Z

Danmarrod: /* Gestión de la construcción */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:38:16Z

Danmarrod: /* Trabajo por realizar */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:38:03Z

Danmarrod: /* Trabajo realizado */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:37:36Z

Danmarrod: /* Definición del usage model y gestión del codigo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:37:06Z

Danmarrod: /* Pautas a la hora de crear una incidencia en GIT */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==

Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
*El título debe seguir el siguiente formato
**1.Si es para reportar algún error en general: ERROR + breve descripción del problema
**2.Si es para solicitar algún tipo de información: INFO + breve descripción del tema de la solicitud

*Indique los pasos para reproducir el problema.
*Indique cual sería el resultado correcto y que recibe en su lugar.
*Indique la versión del software utilizado de desarrollo y el sistema operativo.

Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:32:26Z

Danmarrod: /* Gestión de reuniones */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión convocada para todos los miembros del grupo. Dicha reunión tendrá lugar los miércoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática. Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía Slack o Whatsapp. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==
Para tener un procedimiento común para todos los integrantes del grupo se define las siguientes pautas para crear una incidencia.
1. Se debe de indicar los pasos para reproducir el problema.
2. Indique cual sería el resultado correcto y que recibe en su lugar.
3. Indique la versión del software utilizado de desarrollo y el sistema operativo.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:30:23Z

Danmarrod: /* Gestión del trabajo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:

*1. Integración del sistema heredado (puesta en funcionamiento).
*2. Evolución del sistema heredado.
*3. Integración con el resto de subsistemas.

== Gestión de reuniones ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:
1. Integración del sistema heredado (puesta en funcionamiento).
2. Evolución del sistema heredado.
3. Integración con el resto de subsistemas.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==
Para tener un procedimiento común para todos los integrantes del grupo se define las siguientes pautas para crear una incidencia.
1. Se debe de indicar los pasos para reproducir el problema.
2. Indique cual sería el resultado correcto y que recibe en su lugar.
3. Indique la versión del software utilizado de desarrollo y el sistema operativo.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2016-01-08T12:29:08Z

Danmarrod: /* Gestión de reuniones */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

La organización de las diferentes tareas de trabajo se realizará de forma iterativa estableciendo como hitos las diferentes fechas de integración de los subsistemas. De esta forma se organizará el trabajo a realizar cada 2 semanas dependiendo de la evolución del proyecto y siempre teniendo como finalidad la integración del sistema. A grandes rasgos se podría definir los siguientes pasos:
1. Integración del sistema heredado (puesta en funcionamiento).
2. Evolución del sistema heredado.
3. Integración con el resto de subsistemas.

== Gestión de la construcción ==
Se usará maven para la getión de las dependencias.

Cada vez que se añada una dependencia nueva se debe modificar en el archivo pom.xml para que luego se haga un build del proyecto.

== Definición del usage model y gestión del codigo ==

'''Creación de las ramas:'''

Se crearán ramas para experimentar sobre la integración de nuevas bibliotecas como angular que supongan un cambio en la arquitectura de la aplicación y en la forma de comunicación. Esta forma de trabajo permite la dividir las tareas que tengan que realizar los miembros del grupo.

'''Unión de ramas:'''

Se unirán las ramas cuando el grupo vea el resultado de la integración de nuevos componentes y se compruebe que los resultados eran los estimados.

'''Proceso habitual de trabajo:'''

Los miembros del grupo descargarán los cambios en el repositorio local mediante la operación "pull" desde el repositorio central https://github.com/AgoraUS1516/G10.git.

Los miembros realizarán sus cambios en los ficheros que determinen necesarios. Si se da el caso de tener que crear una rama para investigar una nueva funcionalidad o la incorporación de una nueva tecnología, se creará dicha rama previa comunicación al grupo.

Una vez hechos los cambios si se han añadido nuevos ficheros se deberá seguir la pista a los nuevos ficheros mediante "add".

Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.

Antes de hacer "push" para subir los cambios al repositorio, se debe comunicar al resto miembros la acción a realizar. Debemos revisar si ha habido más commits posteriores a las modificaciones.

Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.

== Pautas a la hora de crear una incidencia en GIT ==
Para tener un procedimiento común para todos los integrantes del grupo se define las siguientes pautas para crear una incidencia.
1. Se debe de indicar los pasos para reproducir el problema.
2. Indique cual sería el resultado correcto y que recibe en su lugar.
3. Indique la versión del software utilizado de desarrollo y el sistema operativo.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Diario de Grupo

2015-12-22T14:05:16Z

Danmarrod:

Diario de Grupo

2015-12-22T14:01:06Z

Danmarrod:

Diario de Grupo

2015-12-01T13:20:00Z

Danmarrod:

Diario de Grupo

2015-12-01T13:13:40Z

Danmarrod: Página creada con «'''[08 Octubre, 2015]''' Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsi...»

Frontend y visualización de resultados

2015-12-01T13:13:32Z

Danmarrod: /* Diario de Grupo */

Frontend y visualización de resultados

2015-12-01T13:02:59Z

Danmarrod: /* Actas */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''[08 Octubre, 2015]'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Redactamos posibles mejoras que pueden aplicarse al subsistema:
*Actualización automática de gráficas (Ajax).
*Cambiar la base de datos.
*Nuevas funcionalidades (exportar resultados).
*Nuevas librerías de visualización (GoogleCharts, Bootstrap).
*Compatibilidad con dispositivos móviles.

Se redacta [[Acta de creación de grupos (GVR) |Acta01]].

<gallery>
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
</gallery>

'''[13 Octubre, 2015]'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

<gallery>
Archivo:EGCG10-05.jpg | Fechas de integracion
</gallery>

'''[20 Octubre, 2015]'''

Se acuerda uso de repositorio distribuido GIT y se establecen las directrices generales del modelo de uso.

'''[10 Noviembre, 2015]'''

Se fija la fecha para la entrega del proyecto el día 26 de diciembre de 2015 (hasta las 23:59).
Se indica que habrá una segunda entrega de recuperación o para subir nota.

'''[11 Noviembre, 2015]'''

Previo a la primera fecha de integración se acuerda el estudio de los documentos y códigos disponibles sobre los subsistemas.
Se redefinen las modificaciones a aplicar:

*Cambio Base de Datos
*Aplicar geolocalización a los resultados.
*Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

Se crea equipo de trabajo y repositorio GIT en www.github.com

Se crea grupo en projetsii para documentación interna y gestión de tareas

Se analizan posibles herramientas para la gestión de incidencias

Se redacta el siguiente [[Acta]]

'''[17 Noviembre, 2015]'''

Primer día de integración:
*Toma de contacto con el resto de subsistemas, se busca la forma de hacer funcionar el sistema anterior.
*Se crea grupo informal de whatsapp como comunicación temporal con el subsistema de Recuento.
*Se define el responsable de la comunicación con el resto de grupo >> Daniel Sánchez Navarro.
*Se propone usar github con el resto de subsistemas para registro de incidencias.

Se redacta ACTA 2

'''[19 Noviembre, 2015]'''

Se toman las siguientes decisiones y asignan las responsabilidades:

*Gestión tareas y grupo en projetsii >> Daniel Martín Rodrigo
*Diario de grupo (wiki,actas) >> Daniel Martín Rodrigo
*Responsable de comunicación externa (coordinador) >> Daniel Sánchez Navarro
*Metodología de trabajo SCRUM
*Modelo de uso del repositorio
*Gestor de incidencias GitHub
*Se define la plantilla para documentación
*Fijar fecha para reuniones

Se fijan los siguientes hitos y se planifican las tareas hasta la siguiente fecha de integración, día 1 de Diciembre:

*Martes 24 fecha tope para levantar el sistema heredado.
(cerrar la baseline)

*Investigar alternativas para integrarse con los subsistemas directos implicados Recuento y Creación de votos.

*Ponerse de acuerdo con Recuento para compartir información
(lenguaje, formato, variables)

*Investigar unificación de los subsistemas Visualización - Frontend

*Investigar Bootstrap

*Investigar para aplicar Angula

*Investigar para sustituir Base de Datos

Se redacta ACTA 3

'''[24 Noviembre, 2015]'''

Se crea una '''Organización en GitHub''' para integrar con el resto de grupo. Se crean nueve grupos con dos repositorios para cada grupos,
uno individual del grupo y otro común con el resto de equipo para la integración. Se asignan los permisos oportunos, cada coordinador
tiene privilegios sobre su equipo y es reponsable de añadir al equipos a los diferentes integrantes.

----
----

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Reunión de grupo (19/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 05 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-12-01T13:01:17Z

Danmarrod: /* Actas */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''[08 Octubre, 2015]'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Redactamos posibles mejoras que pueden aplicarse al subsistema:
*Actualización automática de gráficas (Ajax).
*Cambiar la base de datos.
*Nuevas funcionalidades (exportar resultados).
*Nuevas librerías de visualización (GoogleCharts, Bootstrap).
*Compatibilidad con dispositivos móviles.

Se redacta [[Acta de creación de grupos (GVR) |Acta01]].

<gallery>
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
</gallery>

'''[13 Octubre, 2015]'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

<gallery>
Archivo:EGCG10-05.jpg | Fechas de integracion
</gallery>

'''[20 Octubre, 2015]'''

Se acuerda uso de repositorio distribuido GIT y se establecen las directrices generales del modelo de uso.

'''[10 Noviembre, 2015]'''

Se fija la fecha para la entrega del proyecto el día 26 de diciembre de 2015 (hasta las 23:59).
Se indica que habrá una segunda entrega de recuperación o para subir nota.

'''[11 Noviembre, 2015]'''

Previo a la primera fecha de integración se acuerda el estudio de los documentos y códigos disponibles sobre los subsistemas.
Se redefinen las modificaciones a aplicar:

*Cambio Base de Datos
*Aplicar geolocalización a los resultados.
*Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

Se crea equipo de trabajo y repositorio GIT en www.github.com

Se crea grupo en projetsii para documentación interna y gestión de tareas

Se analizan posibles herramientas para la gestión de incidencias

Se redacta el siguiente [[Acta]]

'''[17 Noviembre, 2015]'''

Primer día de integración:
*Toma de contacto con el resto de subsistemas, se busca la forma de hacer funcionar el sistema anterior.
*Se crea grupo informal de whatsapp como comunicación temporal con el subsistema de Recuento.
*Se define el responsable de la comunicación con el resto de grupo >> Daniel Sánchez Navarro.
*Se propone usar github con el resto de subsistemas para registro de incidencias.

Se redacta ACTA 2

'''[19 Noviembre, 2015]'''

Se toman las siguientes decisiones y asignan las responsabilidades:

*Gestión tareas y grupo en projetsii >> Daniel Martín Rodrigo
*Diario de grupo (wiki,actas) >> Daniel Martín Rodrigo
*Responsable de comunicación externa (coordinador) >> Daniel Sánchez Navarro
*Metodología de trabajo SCRUM
*Modelo de uso del repositorio
*Gestor de incidencias GitHub
*Se define la plantilla para documentación
*Fijar fecha para reuniones

Se fijan los siguientes hitos y se planifican las tareas hasta la siguiente fecha de integración, día 1 de Diciembre:

*Martes 24 fecha tope para levantar el sistema heredado.
(cerrar la baseline)

*Investigar alternativas para integrarse con los subsistemas directos implicados Recuento y Creación de votos.

*Ponerse de acuerdo con Recuento para compartir información
(lenguaje, formato, variables)

*Investigar unificación de los subsistemas Visualización - Frontend

*Investigar Bootstrap

*Investigar para aplicar Angula

*Investigar para sustituir Base de Datos

Se redacta ACTA 3

'''[24 Noviembre, 2015]'''

Se crea una '''Organización en GitHub''' para integrar con el resto de grupo. Se crean nueve grupos con dos repositorios para cada grupos,
uno individual del grupo y otro común con el resto de equipo para la integración. Se asignan los permisos oportunos, cada coordinador
tiene privilegios sobre su equipo y es reponsable de añadir al equipos a los diferentes integrantes.

----
----

==Actas==

* [[Acta de creación de grupos (GVR) |Acta 01 - Creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 02 - Reunión de grupo (11/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 03 - Primer taller de integración (17/11/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta 04 - Segundo taller de integración (01/12/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Acta

2015-12-01T12:55:38Z

Danmarrod:

'''1. Objetivo de la reunión'''

*Preparación previa para primera integración.
*Estudio de subsistemas.
*Redefinir cambios a realizar en el subsistema.
*Sistema para incidencias.

'''2. Participantes'''

A continuación, se adjunta una tabla para anotar los participantes de la reunión.
{| class="wikitable"
! Nombre
! Asistencia

|-
|Barquero Saucí, Valentín||Sí
|-
|Bellido Millán, Miguel Ángel||Sí
|-
|Llamas García, Moisés||Sí
|-
|Martín Rodrigo, Daniel||Sí
|-
|Sánchez Navarro, Daniel (coordinador)||Sí
|}

'''3. Desarrollo de la reunión'''

*Fecha y hora: 17/11/2015, 10:40-12:30
*Lugar: ETSII, Sala de estudios
*Acontecimientos reseñables:

1) Previo a la primera fecha de integración se ponen en común todos los subsistemas implicados y se analiza el flujo de la información. Se comparte la información que los miembros del grupo ha avanzado por su cuenta hasta la fecha y se ponen en común. Se intenta hacer funcionar la aplicación completa pero no se consigue, se aisla el subsistema de visualización y frontend y se intentar lanzar aisladamente.

2) Posteriormente y vista la documentación analizada se redefinen las posibles modificaciones a aplicar en el subsistema.

3) Se analizan posibles herramientas para la gestión de incidencias.

'''4. Acuerdos alcanzados'''

Modificaciones a aplicar:

1) Cambiar Base de Datos

2) Aplicar geolocalización a los resultados.

3) Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

*Se crea equipo de trabajo y repositorio GIT en www.github.com

*Se crea grupo en projetsii para documentación interna y gestión de tareas.

*Posible sistema para incidencias: GitHub

'''5. Validación de la reunión'''

La reunión ha sido validada por los miembros del grupo asistentes y están conformes con lo descrito en este documento.

Acta

2015-12-01T12:54:29Z

Danmarrod: Página creada con «'''1. Objetivo de la reunión''' *Preparación previa para primera integración *Estudio de subsistemas *Redefinir cambios a realizar en el subsistema '''2. Participante...»

'''1. Objetivo de la reunión'''

*Preparación previa para primera integración
*Estudio de subsistemas
*Redefinir cambios a realizar en el subsistema

'''2. Participantes'''

A continuación, se adjunta una tabla para anotar los participantes de la reunión.
{| class="wikitable"
! Nombre
! Asistencia

|-
|Barquero Saucí, Valentín||Sí
|-
|Bellido Millán, Miguel Ángel||Sí
|-
|Llamas García, Moisés||Sí
|-
|Martín Rodrigo, Daniel||Sí
|-
|Sánchez Navarro, Daniel (coordinador)||Sí
|}

'''3. Desarrollo de la reunión'''

*Fecha y hora: 17/11/2015, 10:40-12:30
*Lugar: ETSII, Sala de estudios
*Acontecimientos reseñables:

1) Previo a la primera fecha de integración se ponen en común todos los subsistemas implicados y se analiza el flujo de la información. Se comparte la información que los miembros del grupo ha avanzado por su cuenta hasta la fecha y se ponen en común. Se intenta hacer funcionar la aplicación completa pero no se consigue, se aisla el subsistema de visualización y frontend y se intentar lanzar aisladamente.

2) Posteriormente y vista la documentación analizada se redefinen las posibles modificaciones a aplicar en el subsistema.

3) Se analizan posibles herramientas para la gestión de incidencias.

'''4. Acuerdos alcanzados'''

Modificaciones a aplicar:

1) Cambiar Base de Datos

2) Aplicar geolocalización a los resultados.

3) Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

*Se crea equipo de trabajo y repositorio GIT en www.github.com

*Se crea grupo en projetsii para documentación interna y gestión de tareas.

*Posible sistema para incidencias: GitHub

'''5. Validación de la reunión'''

La reunión ha sido validada por los miembros del grupo asistentes y están conformes con lo descrito en este documento.

Frontend y visualización de resultados

2015-12-01T12:38:52Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''[08 Octubre, 2015]'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Redactamos posibles mejoras que pueden aplicarse al subsistema:
*Actualización automática de gráficas (Ajax).
*Cambiar la base de datos.
*Nuevas funcionalidades (exportar resultados).
*Nuevas librerías de visualización (GoogleCharts, Bootstrap).
*Compatibilidad con dispositivos móviles.

Se redacta [[Acta de creación de grupos (GVR) |Acta01]].

<gallery>
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
</gallery>

'''[13 Octubre, 2015]'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

<gallery>
Archivo:EGCG10-05.jpg | Fechas de integracion
</gallery>

'''[20 Octubre, 2015]'''

Se acuerda uso de repositorio distribuido GIT y se establecen las directrices generales del modelo de uso.

'''[10 Noviembre, 2015]'''

Se fija la fecha para la entrega del proyecto el día 26 de diciembre de 2015 (hasta las 23:59).
Se indica que habrá una segunda entrega de recuperación o para subir nota.

'''[11 Noviembre, 2015]'''

Previo a la primera fecha de integración se acuerda el estudio de los documentos y códigos disponibles sobre los subsistemas.
Se redefinen las modificaciones a aplicar:

*Cambio Base de Datos
*Aplicar geolocalización a los resultados.
*Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

Se crea equipo de trabajo y repositorio GIT en www.github.com

Se crea grupo en projetsii para documentación interna y gestión de tareas

Se analizan posibles herramientas para la gestión de incidencias

Se redacta el siguiente [[Acta]]

'''[17 Noviembre, 2015]'''

Primer día de integración:
*Toma de contacto con el resto de subsistemas, se busca la forma de hacer funcionar el sistema anterior.
*Se crea grupo informal de whatsapp como comunicación temporal con el subsistema de Recuento.
*Se define el responsable de la comunicación con el resto de grupo >> Daniel Sánchez Navarro.
*Se propone usar github con el resto de subsistemas para registro de incidencias.

Se redacta ACTA 2

'''[19 Noviembre, 2015]'''

Se toman las siguientes decisiones y asignan las responsabilidades:

*Gestión tareas y grupo en projetsii >> Daniel Martín Rodrigo
*Diario de grupo (wiki,actas) >> Daniel Martín Rodrigo
*Responsable de comunicación externa (coordinador) >> Daniel Sánchez Navarro
*Metodología de trabajo SCRUM
*Modelo de uso del repositorio
*Gestor de incidencias GitHub
*Se define la plantilla para documentación
*Fijar fecha para reuniones

Se fijan los siguientes hitos y se planifican las tareas hasta la siguiente fecha de integración, día 1 de Diciembre:

*Martes 24 fecha tope para levantar el sistema heredado.
(cerrar la baseline)

*Investigar alternativas para integrarse con los subsistemas directos implicados Recuento y Creación de votos.

*Ponerse de acuerdo con Recuento para compartir información
(lenguaje, formato, variables)

*Investigar unificación de los subsistemas Visualización - Frontend

*Investigar Bootstrap

*Investigar para aplicar Angula

*Investigar para sustituir Base de Datos

Se redacta ACTA 3

'''[24 Noviembre, 2015]'''

Se crea una '''Organización en GitHub''' para integrar con el resto de grupo. Se crean nueve grupos con dos repositorios para cada grupos,
uno individual del grupo y otro común con el resto de equipo para la integración. Se asignan los permisos oportunos, cada coordinador
tiene privilegios sobre su equipo y es reponsable de añadir al equipos a los diferentes integrantes.

----
----

==Actas==

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-12-01T12:26:19Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''[08 Octubre, 2015]'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Redactamos posibles mejoras que pueden aplicarse al subsistema:
*Actualización automática de gráficas (Ajax).
*Cambiar la base de datos.
*Nuevas funcionalidades (exportar resultados).
*Nuevas librerías de visualización (GoogleCharts, Bootstrap).
*Compatibilidad con dispositivos móviles.

Se redacta [[Acta de creación de grupos (GVR) |Acta01]].

<gallery>
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
</gallery>

'''[13 Octubre, 2015]'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

<gallery>
Archivo:EGCG10-05.jpg | Fechas de integracion
</gallery>

'''[20 Octubre, 2015]'''

Se acuerda uso de repositorio distribuido GIT y se establecen las directrices generales del modelo de uso.

'''[10 Noviembre, 2015]'''

Se fija la fecha para la entrega del proyecto el día 26 de diciembre de 2015 (hasta las 23:59).
Se indica que habrá una segunda entrega de recuperación o para subir nota.

'''[11 Noviembre, 2015]'''

Previo a la primera fecha de integración se acuerda el estudio de los documentos y códigos disponibles sobre los subsistemas.
Se redefinen las modificaciones a aplicar:

*Cambio Base de Datos
*Aplicar geolocalización a los resultados.
*Aplicar Angula y Bootstrap para el apartado estético y de visualización de gráficas.

Se crea equipo de trabajo y repositorio GIT en www.github.com

Se crea grupo en projetsii para documentación interna y gestión de tareas

Se analizan posibles herramientas para la gestión de incidencias

'''[17 Noviembre, 2015]'''

Primer día de integración:
*Toma de contacto con el resto de subsistemas, se busca la forma de hacer funcionar el sistema anterior.
*Se crea grupo informal de whatsapp como comunicación temporal con el subsistema de Recuento.
*Se define el responsable de la comunicación con el resto de grupo >> Daniel Sánchez Navarro.
*Se propone usar github con el resto de subsistemas para registro de incidencias.

Se redacta ACTA 2

'''[19 Noviembre, 2015]'''

Se toman las siguientes decisiones y asignan las responsabilidades:

*Gestión tareas y grupo en projetsii >> Daniel Martín Rodrigo
*Diario de grupo (wiki,actas) >> Daniel Martín Rodrigo
*Responsable de comunicación externa (coordinador) >> Daniel Sánchez Navarro
*Metodología de trabajo SCRUM
*Modelo de uso del repositorio
*Gestor de incidencias GitHub
*Se define la plantilla para documentación
*Fijar fecha para reuniones

Se fijan los siguientes hitos y se planifican las tareas hasta la siguiente fecha de integración, día 1 de Diciembre:

*Martes 24 fecha tope para levantar el sistema heredado.
(cerrar la baseline)

*Investigar alternativas para integrarse con los subsistemas directos implicados Recuento y Creación de votos.

*Ponerse de acuerdo con Recuento para compartir información
(lenguaje, formato, variables)

*Investigar unificación de los subsistemas Visualización - Frontend

*Investigar Bootstrap

*Investigar para aplicar Angula

*Investigar para sustituir Base de Datos

Se redacta ACTA 3

'''[24 Noviembre, 2015]'''

Se crea una '''Organización en GitHub''' para integrar con el resto de grupo. Se crean nueve grupos con dos repositorios para cada grupos,
uno individual del grupo y otro común con el resto de equipo para la integración. Se asignan los permisos oportunos, cada coordinador
tiene privilegios sobre su equipo y es reponsable de añadir al equipos a los diferentes integrantes.

----
----

==Actas==

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-30T12:21:48Z

Danmarrod: /* Diario de Grupo */

Frontend y visualización de resultados

2015-11-27T23:51:17Z

Danmarrod: /* Diario de Grupo */

Frontend y visualización de resultados

2015-11-27T23:45:41Z

Danmarrod: /* Diario de Grupo */

Frontend y visualización de resultados

2015-11-27T23:44:16Z

Danmarrod: /* Diario de Grupo */

Archivo:EGCG10-05.jpg

2015-11-27T23:20:00Z

Danmarrod: Fechas de integración

Fechas de integración

Archivo:EGCG10-04.jpg

2015-11-27T23:19:24Z

Danmarrod: Subsistemas Agora@US

Subsistemas Agora@US

Archivo:EGCG10-03.jpg

2015-11-27T23:18:58Z

Danmarrod: Subsistemas AgoraVoting

Subsistemas AgoraVoting

Frontend y visualización de resultados

2015-11-27T23:15:07Z

Danmarrod: /* Miembros */

Frontend y visualización de resultados

2015-11-27T23:14:07Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Ficha de conformación de grupo y subsistema elegido [[EGCG10-02.jpg]].

Se redacta el siguiente [[Acta de creación de grupos (GVR) |Acta]].

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----
----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T23:10:26Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Ficha de conformación de grupo y subsistema elegido[[EGCG10-02.jpg]]

Se redacta la siguiente [[Acta de creación de grupos (GVR) |Acta]].

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----
----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

EGCG10-02.jpg

2015-11-27T23:09:44Z

Danmarrod: Página creada con «Archivo:EGCG10-02.jpg»

[[Archivo:EGCG10-02.jpg]]

Archivo:EGCG10-02.jpg

2015-11-27T23:08:10Z

Danmarrod: Danmarrod subió una nueva versión de «Archivo:EGCG10-02.jpg»: Ficha de creación de equipo y subsistema elegido

Ficha de miembros del equipo y subsistema asignado.

Archivo:EGCG10-02.jpg

2015-11-27T23:04:10Z

Danmarrod: Ficha de miembros del equipo y subsistema asignado.

Ficha de miembros del equipo y subsistema asignado.

Frontend y visualización de resultados

2015-11-27T15:11:30Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Se redacta la siguiente [[Acta de creación de grupos (GVR) |Acta]].

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----
----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T15:09:55Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Se redacta la siguiente [[Acta de creación de grupos (GVR) |Acta]].

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T15:06:16Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''

Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]
* [[Usuario:dansannav|Daniel Sánchez Navarro]]
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]
* [[Usuario:moillagar|Moisés LLamas García]]
* [[Usuario:valbarsau|Valentín Barquero Saucí]]

Se redacta acta de la sesión de hoy.

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T15:04:57Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''08 Octubre, 2015'''
Se crean los nuevos equipos de trabajo y se eligen los subsistemas a desarrollar por cada equipo. Nuestro equipo será el responsable de dos subsistemas, Frontend y Visualización de Resultados. El equipo está integrado por los alumnos:
* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

Se redacta acta de la sesión de hoy.

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:57:26Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''13 Octubre, 2015'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:55:48Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

'''15:40 13 oct 2015 (CET)'''

Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:54:14Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

--[[Usuario:Danmarrod|Danmarrod]] ([[Usuario discusión:Danmarrod|discusión]]) 15:40 13 oct 2015 (CET)
Se realiza reunión de coordinadores para fijar las fechas de las diferentes integraciones entre subsistemas. Los días de integración acordados son finalmente los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:52:35Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

--[[Usuario:Danmarrod|Danmarrod]] ([[Usuario discusión:Danmarrod|discusión]]) 15:40 13 oct 2015 (CET)

Durante el taller de hoy se realiza una reunión de coordinadores para fijar las fechas de las diferentes integraciones de subsistemas. Los días acordados de integración son los siguientes:

*Integración 1: 17 de noviembre de 2015
*Integración 2: 01 de diciembre de 2015
*Integración 3: 15 de diciembre de 2015
*Integración 4: 12 de enero de 2016

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:40:34Z

Danmarrod: /* Diario de Grupo */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

--[[Usuario:Danmarrod|Danmarrod]] ([[Usuario discusión:Danmarrod|discusión]]) 15:40 27 nov 2015 (CET)

----

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

----

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Acta de creación de grupos (GVR)

2015-11-27T14:32:28Z

Danmarrod:

'''1. Objetivo de la reunión'''
*Consolidación del grupo de trabajo.
*Elección del subsistema a desarrollar por el grupo.
*Conocer con detalle la función del subsistema escogido.
*Definir cómo se comunicarán los integrantes del grupo de trabajo.
*Definir la periodicidad con la que los integrantes del grupo detrabajo se reunirán.
*Dejar constancia del método de trabajo escogido.
*Elección de coordinador, como representante del grupo.

'''2. Participantes'''
A continuación, se adjunta una tabla para anotar los participantes de la reunión.
{| class="wikitable"
! Nombre
! Asistencia

|-
|Barquero Saucí, Valentín||Sí
|-
|Bellido Millán, Miguel Ángel||Sí
|-
|Llamas García, Moisés||Sí
|-
|Martín Rodrigo, Daniel||Sí
|-
|Sánchez Navarro, Daniel (coordinador)||Sí
|}

'''3. Desarrollo de la reunión
*Fecha y hora: 08/10/2015, 10:40-12:30
*Lugar: ETSII, Aula I2.32
*Acontecimientos reseñables:
Una vez consolidado el grupo de trabajo, el grupo eligió el subsistema
en el que estaba interesado. También se dejó constancia de la periodicidad de las
reuniones que el grupo habría de mantener en función de los horarios
de cada integrante y de posibles solapamientos temporales con otras
asignaturas. Se establecieron los medios de comunicación a utilizar por
los integrantes con el fin de poder aplicar correctamente el método de
trabajo elegido, que no es más que el reparto constante y equitativo de
tareas. Para ello, se eligió a un coordinador para el grupo, como representante del equipo y para coordinar el trabajo.

'''4. Acuerdos alcanzados'''
*El subsistema a desarrollar escogido fue ‘Frontend y visualización de resultados’,
previa resolución de conflicto con otro grupo interesado.
*Se llega a un acuerdo entre los integrantes del grupo por el que el
método de comunicación que más beneficia a todos es la mensajería
instantánea (WhatsApp), aplicaciones VoIP (Skype) o mensajería de
correo electrónico.
*En principio, las reuniones tendrán lugar cada miercoles en un periodo
de tiempo situado entre las 10:30 y las 12:30, aunque puede
concertarse una reunión para el día que el grupo estime oportuno en
base a sus restricciones de horario. No se ha establecido una
duración concreta para las reuniones.
*El método de trabajo será el de repartir tareas de manera equitativa
y constante entre los distintos integrantes. Si la tarea es demasiado
compleja, se formarán subgrupos que deberán llevar a cabo dicha
tarea. La no realización de una tarea asignada constará en el diario
de grupo como una incidencia a la que se deberá dar solución.

'''5. Validación de la reunión'''
La reunión ha sido validada por los miembros del grupo asistentes y están
conformes con lo descrito en este documento.

Frontend y visualización de resultados

2015-11-27T14:23:45Z

Danmarrod: /* Actas de Reuniones y talleres */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Diario de Grupo ==

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:19:49Z

Danmarrod: /* Definición */

== Definición ==
Subsistemas responsables de la visualización y gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Actas de Reuniones y talleres ==

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''

Frontend y visualización de resultados

2015-11-27T14:18:32Z

Danmarrod: /* Flujo entre subsistemas */

== Definición ==
Subsistema relacionado con la visualización y la gestión de resultados en AGORA@US

== Miembros ==

* [[Usuario:danmarrod|Daniel Martín Rodrigo]]: Ingeniero Software
* [[Usuario:dansannav|Daniel Sánchez Navarro]]: Ingeniero Software
* [[Usuario:migbelmil|Miguel Ángel Bellido Millán]]: Ingeniero Software
* [[Usuario:moillagar|Moisés LLamas García]]: Ingeniero Software
* [[Usuario:valbarsau|Valentín Barquero Saucí]]: Ingeniero Software

== Gestión del trabajo ==

Una vez recibida la carga de trabajo, el reparto de tareas se realizará de forma equitativa, y será realizado de forma individual o bien en subgrupos, dependiendo de cuán compleja sea la tarea.
Si una tarea es asignada a un miembro del grupo y éste no es capaz de realizarla, puede cambiarla si otro miembro está de acuerdo en intercambiarla por otra tarea del mismo peso. En caso de que nadie quisiera intercambiarla y la persona encargada se niegue a realizarla, será responsable de la misma y se informará al profesor de dicho altercado.

== Gestión de reuniones ==

De forma periódica, se realizará una reunión compuesta por todos los miembros del grupo. Dicha reunión tendrá lugar los miercoles laborales a las 10:30-12:30 en la Escuela Técnica Superior de Ingeniería Informática.
Si estas reuniones no son suficientes, se avisará a todos los miembros del grupo para llegar a un acuerdo sobre el día, hora y lugar de la reunión prevista. Los miembros recibirán el aviso vía e-mail, WhatsApp o Skype. En caso de no ser posible asistir a la reunión, se deberá avisar al resto de miembros de dicho suceso.

== Pautas a la hora de realizar commits en GIT ==

Tras completar las sesiones de prácticas de GIT, se han establecido una serie de pautas para homogeneizar los commits en GIT, siguiendo las guías expuestas por el profesor de prácticas:
* En primer lugar, el título comenzará con una palabra clave en mayúsculas y en español. Esta palabra hará referencia al tipo de cambio del que se trata. Ejemplos:
ADICIÓN: [título del commit]
CORRECCIÓN: [título del commit]
APIGET: [título del commit]
PERSISTENCIA: [título del commit]
CONFIGURACIÓN: [título del commit]
DESPLIEGUE: [título del commit]
* Una vez especificado el tipo de cambio, en la parte [título del commit] se expondrá con un poco más de detalle el cambio lógico que supone dicho commit, sin superar los 80 caracteres.
* Por último, se añadirá una descripción detallada que responda al por qué del cambio y explique en qué consiste.

== Pautas a la hora de realizar las actas de las reuniones ==
Se seguirá el siguiente formato para realizar las actas:
*Objetivos de la reunión
*Lista de asistentes a la reunión
*Desarrollo de la reunión. Se especificará la fecha y el lugar de la reunión.
*Acuerdos alcanzados.
*Validación de la reunión.

== Trabajo realizado ==
* Esqueleto del diario de grupo.
* Planificación de reuniones.
* Método de comunicación entre los miembros de grupo.
* Método de trabajo.
* Plantilla de las actas de reunión.
* Creación de repositorio.

== Trabajo por realizar ==

== Herramientas a utilizar ==
* GIT
* ProjETSII
* AngularJS
* Spring/Hibernate
* Java
* HTML5/CSS

== Actas de Reuniones y talleres ==

* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]

==Subsistemas Relacionados==
*Recuento de votos
*Modificación de Resultados
*Creación de votación

==Flujo entre subsistemas==

El flujo de información entre los diferentes subsistemas heredados implicados en la visualización de los resultados es el siguiente:

'''Frontend-Recuento-Visualización'''

Si la votación que necesita Visualización está en la base de datos es devuelta, y
en caso contrario se realiza la petición a la API de Recuento de Votos.

El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
necesita el recuento de votos original o el modificado.Básicamente realizan la comunicación con la base de datos para comprobar si pueden devolver las votaciones directamente o deben pedírselas a los subsistemas correspondientes.

'''Visualización-Creación-Frontend'''

El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
de las votaciones a partir de los datos obtenidos de los otros subsistemas.

Para la obtención de datos nos conectamos con dos subsistemas, siempre como clientes.
Estos subsistemas son frontend de resultados y creación de votaciones.

*Creación de votaciones: nos transmitirán un json en el que obtendremos el nombre y el
identificador de todas las votaciones finalizadas. Con esta información creamos un menú en el
cual el usuario puede elegir la votación de la cual quiere ver las gráficas.

*Frontend de resultados: tras enviarles el identificador de la votación en la que estamos
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
los cuales dibujaremos las gráficas.

'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''