Diferencia entre revisiones de «Frontend y visualización de resultados»

De Wiki de EGC
Saltar a: navegación, buscar
(Diario de Grupo)
(Actas)
 
(No se muestran 28 ediciones intermedias de 4 usuarios)
Línea 10: Línea 10:
 
* [[Usuario:valbarsau|Valentín Barquero Saucí]]
 
* [[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.
+
==Subsistemas Relacionados==
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.
+
*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.
  
  
== Gestión de reuniones ==
+
'''Visualización-Creación-Frontend'''
  
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.
+
El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
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.
+
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.
  
== Pautas a la hora de realizar commits en GIT ==
+
*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.''
  
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 ==
+
== Gestión del trabajo ==
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 ==
+
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:
* 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 ==
+
*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 ==
  
== Herramientas a utilizar ==
+
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.
* GIT
 
* ProjETSII
 
* AngularJS
 
* Spring/Hibernate
 
* Java
 
* HTML5/CSS
 
  
  
 +
== Definición del usage model y gestión del codigo ==
  
== Diario de Grupo ==
 
  
'''08 Octubre, 2015'''
+
'''Creación de las ramas:'''
  
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:
+
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.
* [[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:  
+
'''Unión de ramas:'''
*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]].
+
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:'''
  
<gallery>
+
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.
Archivo:EGCG10-03.jpg | Subsistemas AgoraVoting
 
Archivo:EGCG10-04.jpg | Subsistemas Agora@US
 
Archivo:EGCG10-02.jpg | Equipo y subsistemas asignados
 
</gallery>
 
  
 +
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".
  
'''13 Octubre, 2015'''
+
Hacer "commit" para confirmación de cambios incluyendo un mensaje lo suficientemente descriptivo siguiendo las pautas que se definen en el siguiente apartado.
  
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:
+
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.
  
*Integración 1: 17 de noviembre de 2015
+
Se debe hacer "push" de las ramas para que se pueda ver el avance que se realizando.
*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>
 
  
----
+
== Pautas a la hora de crear una incidencia en GIT ==
----
 
  
* [[Acta de creación de grupos (GVR) |Acta de creación de grupos (08/10/2015)]]
+
Para reportar una incidencia deberá realizarse desde GitHub y el procedimiento a seguir es el siguiente:
* [[Actas del primer taller de integración (GVR) |Acta del primer taller de integración (17/11/2015)]]
+
*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.
  
==Subsistemas Relacionados==
+
Si dispone información adicional que pueda ser de ayuda puede indicarlo en la parte inferior.
*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:
+
== 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.
  
'''Frontend-Recuento-Visualización'''
 
  
Si la votación que necesita Visualización está en la base de datos es devuelta, y
+
Nota: Procedimiento basado en trabajo de años anteriores.
en caso contrario se realiza la petición a la API de Recuento de Votos.  
+
''Fuente: https://1984.lsi.us.es/wiki-egc/index.php/Grupo_Frontend_de_Resultados(2014-15)#Pautas_a_la_hora_de_realizar_commits_en_GIT''
  
El subsistema Frontend realiza las consultas al subsistema de Recuento de Votos o al de  
+
== Pautas a la hora de realizar las actas de las reuniones ==
Modificación de Resultados, dependiendo de si el subsistema de Visualización de Resultados
+
Se seguirá el siguiente formato para realizar las actas:
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.
+
*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.
  
  
'''Visualización-Creación-Frontend'''
+
== Herramientas a utilizar ==
 +
* GIT
 +
* ProjETSII
 +
* AngularJS
 +
* Spring/Hibernate
 +
* Java
 +
* HTML5/CSS
 +
* Trello
 +
* Slack
  
El subsistema de visualización es el responsable de mostrar gráficas sobre los resultados
+
== Diario de Grupo ==
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.
+
El diario de Grupo se encuentra en el siguiente enlace [[Diario de Grupo]]
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
+
==Actas==
interesados, nos transmitirán un json en el que obtendremos los resultados de las votaciones, con
 
los cuales dibujaremos las gráficas.
 
  
 +
* [[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)]]
 +
* [[Acta 05 - Reunión de grupo (26/01/2016)]]
 +
* [[Acta 06 - Reunión de grupo (01/02/2016)]]
 +
* [[Acta 07 - Reunión de grupo (05/02/2016)]]
 +
* [[Acta 08 - Reunión de grupo (08/02/2016)]]
  
'''''Nota''': Información extraida de la documentación de los subsistemas anteriores.''
+
----

Revisión actual del 10:56 10 feb 2016

Definición

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

Miembros


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. Fuente: https://1984.lsi.us.es/wiki-egc/index.php/Grupo_Frontend_de_Resultados(2014-15)#Pautas_a_la_hora_de_realizar_commits_en_GIT

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
  • Trello
  • Slack

Diario de Grupo

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


Actas