Diferencia entre revisiones de «Verificación Grupo 2 (Curso 2016-2017)»

De Wiki de EGC
Saltar a: navegación, buscar
(→‎Gestión de incidencias)
 
(No se muestran 28 ediciones intermedias del mismo usuario)
Línea 24: Línea 24:
 
* Cabina de votación
 
* Cabina de votación
 
* Almacenamiento
 
* Almacenamiento
−
 
  
 
== Gestión de tareas ==
 
== Gestión de tareas ==
−
*Para la gestión de tareas se usará TRELLO
+
*Las tareas del equipo, su avance, y el flujo general de trabajo seguido en la organización se realiza apoyándose en el uso de la herramienta Trello.
 +
 +
*La ventaja que ofrece Trello que al ser un tablón digital nos permite centralizar información de interés general, y el backlog de tareas. Otra característica a tener en cuenta de Trello es su gestión basada en Kanban lo que nos ayudará a etiquetar las tareas y a conocer el estado del proyecto en todo momento.
  
−
https://trello.com/b/RyU5wy2S/trabajo-egc-verificacion
+
== Gestión de la comunicación ==
 +
*Para centralizar la comunicación usaremos la herramienta Slack debido a las grandes ventajas que está nos proporciona.
  
−
== Repositorio de código ==
+
*Como nos encontramos ante la adversidad de no poder reunirnos de manera física, el equipo ha decidido realizar las reuniones vía Hangouts
 +
  
−
* Se utilizará Git como herramienta de gestión de código y se podrá acceder al repositorio desde [https://github.com/AgoraUS-G2-1617/G27 https://github.com/AgoraUS-G2-1617/G27]
+
[https://trello.com/b/r7L0EKgX/verificaci%C3%B3n-septiembre Trello Verificación Grupo2]
  
 
== Actas de reunión ==
 
== Actas de reunión ==
 +
'''Primera convocatoria'''
  
 
::* [[Acta de Reunión de creación de grupo (26/10/2016) - Grupo 2 - Verificación G27| Acta Reunión creación de grupo (26/10/2016)]]
 
::* [[Acta de Reunión de creación de grupo (26/10/2016) - Grupo 2 - Verificación G27| Acta Reunión creación de grupo (26/10/2016)]]
Línea 46: Línea 50:
  
 
::* [[Anexo de trabajo realizado - Grupo 2 - Verificación G27 |  Anexo de trabajo]]
 
::* [[Anexo de trabajo realizado - Grupo 2 - Verificación G27 |  Anexo de trabajo]]
 +
 +
 +
''' Segunda convocatoria '''
 +
::* [[Acta Reunión I Grupo 2 - Verificación G27 | Acta Reunión I  (06/07/2017)]]
 +
::* [[Acta Reunión II Grupo 2 - Verificación G27 | Acta Reunión II  (20/07/2017)]]
 +
::* [[Acta Reunión III Grupo 2 - Verificación G27 | Acta Reunión III  (11/08/2017)]]
 +
::* [[Acta Reunión IV Grupo 2 - Verificación G27 | Acta Reunión IV  (05/09/2017)]]
  
 
== Ecosistema de desarrollo ==
 
== Ecosistema de desarrollo ==
Línea 66: Línea 77:
  
 
''*Credenciales MySQL  => usuario:root //contraseña:desarrollo''
 
''*Credenciales MySQL  => usuario:root //contraseña:desarrollo''
 +
 +
'''[https://www.dropbox.com/s/7baeq23wxb24cm1/W7.zip?dl=0 Descargar máquina virtual]
  
 
== Gestión de código fuente ==
 
== Gestión de código fuente ==
Línea 71: Línea 84:
 
'''Introducción'''
 
'''Introducción'''
  
−
*Para que todos los alumnos de la asignatura tengan acceso al código fuente del sistema AGORA-US se ha creado un grupo en la plataforma Github llamado AgoraUS-G2-1617. En este grupo encontraremos un repositorio git para cada subsistema.
+
*Para que todos los alumnos de la asignatura tengan acceso al código fuente del sistema AGORA-US se ha creado un grupo en la plataforma Github llamado [https://github.com/AgoraUS-G2-1617 AgoraUS-G2-1617]. En este grupo encontraremos un repositorio git para cada subsistema.
  
 
'''Primeros pasos'''
 
'''Primeros pasos'''
−
* El jefe de proyecto se encargará de crear el repositorio para el subsistema de Verificación dentro del grupo AgoraUS-G2-1617.Justo después de crear el repositorio correspondiente al sistema de Verificación,  realizará un fork al repositorio que contiene al subsistema de Verificación desarrollado por los compañeros del Grupo2 del año 15/16.
+
* El jefe de proyecto se encargará de crear el repositorio para el subsistema de Verificación dentro del grupo [https://github.com/AgoraUS-G2-1617 AgoraUS-G2-1617].Justo después de crear el repositorio correspondiente al sistema de Verificación,  realizará un fork al repositorio que contiene al subsistema de Verificación desarrollado por los compañeros del Grupo2 del año 15/16.
  
 
* El jefe de proyecto añadirá a todo el equipo al repositorio una vez el fork haya sido realizado.
 
* El jefe de proyecto añadirá a todo el equipo al repositorio una vez el fork haya sido realizado.
  
−
'''Metodología para subir los cambios'''
+
'''Modelo de flujo de trabajo : Gitflow'''
 +
*Gitflow es un modelo de flujo de trabajo creado por Vincent Driessen. Esta metodología de trabajo se basa en el uso de ramas para la gestión del código.
 +
 
 +
*El trabajo se organiza en dos ramas principales:
 +
  -'''Rama master''': esta rama tiene como objetivo ser el contenido del servidor de producción.
 +
  -'''Rama develop''': esta rama contiene todo el desarrollo del proyecto hasta el último commit realizado, funciona paralelamente a la rama master
 +
  -'''Ramas features''': cada vez que queramos añadir una funcionalidad nueva en nuestro proyecto debemos crear una rama de este tipo, una vez la funcionalidad este terminada estas ramas se unirán a la develop
 +
  -'''Ramas releases''': ramas intermedias para indicar las versiones en las que se encuentra el proyecto, hacen de puente entre la rama master y la rama develop
 +
  -'''Ramas hotfix''' : este tipo de ramas se crean para solucionar fallos que deben corregirse, se crean desde la rama master.
  
 
'''Repositorio código Verifiación G2 16/17'''
 
'''Repositorio código Verifiación G2 16/17'''
  
−
[https://github.com/AgoraUS-G2-1617/G27 https://github.com/AgoraUS-G2-1617/G27]
+
[https://github.com/AgoraUS-G2-1617/G27-Sept https://github.com/AgoraUS-G2-1617/G27-Sept]
  
 
'''Repositorio código Verificación G2 15/16'''
 
'''Repositorio código Verificación G2 15/16'''
Línea 91: Línea 112:
 
'''Introducción''' : si se diera el caso de un conflicto, el miembro del equipo que se haya topado con el mismo será el responsable de resolverlo. Para ello tendrá que comunicarlo al equipo para ponerse de acuerdo con el miembro o miembros para acordar la versión correcta del código.
 
'''Introducción''' : si se diera el caso de un conflicto, el miembro del equipo que se haya topado con el mismo será el responsable de resolverlo. Para ello tendrá que comunicarlo al equipo para ponerse de acuerdo con el miembro o miembros para acordar la versión correcta del código.
  
−
''' Resolución de conflictos ''' : cuando se produce un conflicto Git nos impide realizar el push correspondiente mostrándonos un aviso del mismo. Una vez se ha comunicado el conflicto al miembro o los miembros implicados se resuelve el conflicto manualmente y se vuelve a realizar el push.
+
''' Resolución de conflictos ''' : cuando se produce un conflicto, Git nos impide realizar el push o commit correspondiente mostrándonos un aviso del mismo. Una vez se ha comunicado el conflicto al miembro o los miembros implicados se resuelve el conflicto manualmente y se vuelve a realizar el push.
  
 
== Gestión de la integración continua ==
 
== Gestión de la integración continua ==
  
 
== Gestión de incidencias ==
 
== Gestión de incidencias ==
 +
 +
*Las incidencias son gestionadas haciendo uso del sistema de issues que provee GitHub.
 +
 +
*Se ha definido un patrón que debe seguirse al reportar una incidencia:
 +
  -Título: Resumen de la incidencia
 +
  -Descripción general :
 +
    *En caso de ser una mejora: descripción detalla de la mejora y las funcionalidades afectadas por la misma
 +
    *En caso de ser un error: pasos para reproducir la incidencia, comportamiento observado, comportamiento esperado.
 +
  -Otros comentarios.
 +
 +
*Las issues son etiquetadas por quien las reporta, pudiendo ser re-etiquetadas durante su ciclo de vida.
 +
 +
*Procedimiento que seguimos en el ciclo de vida de la incidencia:
 +
  1. Cuando una incidencia es reportada, los miembros del equipo son notificados vía e-mail.
 +
  2. El jefe de proyecto:
 +
    2.1 Primero comprueba si se disponen de los detalles suficientes o debe recabarse más información.
 +
    2.2 Si se necesita más información  encarga al responsable de la incidencia a hacerlo.
 +
  3.El miembro o los miembros del equipo encargado/s de la incidencia procede/n a su resolución.
 +
  4.Se cierra la issue y se notifica al jefe de proyecto
 +
 +
== Proyecto Opera ==
 +
La entrega del proyecto se realizará mediante la plataforma Opera, espacio perteneciente proporcionado por la Universidad de Sevilla
 +
 +
[http://opera.eii.us.es/egc/public/grupo/ver/id/78 Grupo27]

Revisión actual del 22:08 11 sep 2017

Miembros

Aspectos Organizativos

Introducción

Punto de partida: en las primeras semanas de clase se explica la composición del sistema de votación online Agora-US y cada uno de los módulos/subsistemas que lo componen. Estos subsistemas han sido desarrollados por alumnos que han cursado la asignatura en años anteriores. Tras conocer cuales van a ser los módulos que componen Agora-US y haber formado los equipos, el profesor David Benavides organiza una reunión para que los alumnos de la asignatura elijan sus subsistemas y empiecen a comunicarse con los grupos cuyos subsistemas están relacionados

Objetivo del proyecto: estudiar el subsitema desarrollado anteriormente, viendo las posibles mejores o posibles bugs que existán en el mismo y realizar una documentación lo más óptima posible para que así quede constancia de la evolución que este subsistema ha sufrido a lo largo del tiempo. Todo ello sin perder de vista la integración con los demás subsistemas de Agora-US


Subsistema de verificación : el módulo de verificación es aquel que se encargará de las siguientes funciones dentro de Agora-US: 

 * Creación de claves públicas y privadas para las distintas votaciones.
 * Comprobar si un voto ha sido cifrado correctamente o no.
 * Comprobar que la votación no ha sido adulterada.


Subsistema relacionados con Verificación :

  • Administración de votos
  • Cabina de votación
  • Almacenamiento

Gestión de tareas

  • Las tareas del equipo, su avance, y el flujo general de trabajo seguido en la organización se realiza apoyándose en el uso de la herramienta Trello.
  • La ventaja que ofrece Trello que al ser un tablón digital nos permite centralizar información de interés general, y el backlog de tareas. Otra característica a tener en cuenta de Trello es su gestión basada en Kanban lo que nos ayudará a etiquetar las tareas y a conocer el estado del proyecto en todo momento.

Gestión de la comunicación

  • Para centralizar la comunicación usaremos la herramienta Slack debido a las grandes ventajas que está nos proporciona.
  • Como nos encontramos ante la adversidad de no poder reunirnos de manera física, el equipo ha decidido realizar las reuniones vía Hangouts


Trello Verificación Grupo2

Actas de reunión

Primera convocatoria


Segunda convocatoria

Ecosistema de desarrollo

Tecnologías y herramientas

El equipo de trabajo decide crear una máquina virtual para facilitar la gestión del código a futuros compañeros de la asignatura, dicha máquina virtual cuenta con las siguientes tecnologías y herramientas:

  • Windows7
  • Java7
  • Maven 3.3.9
  • Tomcat 8.5
  • MySQL 5.7
  • MySQL Workbench 6.3
  • Jenkins
  • Github
  • Eclipse Neon


*Contraseña Windows7 => desarrollo

*Credenciales MySQL => usuario:root //contraseña:desarrollo

Descargar máquina virtual

Gestión de código fuente

Introducción

  • Para que todos los alumnos de la asignatura tengan acceso al código fuente del sistema AGORA-US se ha creado un grupo en la plataforma Github llamado AgoraUS-G2-1617. En este grupo encontraremos un repositorio git para cada subsistema.

Primeros pasos

  • El jefe de proyecto se encargará de crear el repositorio para el subsistema de Verificación dentro del grupo AgoraUS-G2-1617.Justo después de crear el repositorio correspondiente al sistema de Verificación, realizará un fork al repositorio que contiene al subsistema de Verificación desarrollado por los compañeros del Grupo2 del año 15/16.
  • El jefe de proyecto añadirá a todo el equipo al repositorio una vez el fork haya sido realizado.

Modelo de flujo de trabajo : Gitflow

  • Gitflow es un modelo de flujo de trabajo creado por Vincent Driessen. Esta metodología de trabajo se basa en el uso de ramas para la gestión del código.
  • El trabajo se organiza en dos ramas principales:
 -Rama master: esta rama tiene como objetivo ser el contenido del servidor de producción.
 -Rama develop: esta rama contiene todo el desarrollo del proyecto hasta el último commit realizado, funciona paralelamente a la rama master
 -Ramas features: cada vez que queramos añadir una funcionalidad nueva en nuestro proyecto debemos crear una rama de este tipo, una vez la funcionalidad este terminada estas ramas se unirán a la develop
 -Ramas releases: ramas intermedias para indicar las versiones en las que se encuentra el proyecto, hacen de puente entre la rama master y la rama develop
 -Ramas hotfix : este tipo de ramas se crean para solucionar fallos que deben corregirse, se crean desde la rama master.

Repositorio código Verifiación G2 16/17

https://github.com/AgoraUS-G2-1617/G27-Sept

Repositorio código Verificación G2 15/16

https://github.com/jeparca/EGCVerificacion15

Gestión de conflictos

Introducción : si se diera el caso de un conflicto, el miembro del equipo que se haya topado con el mismo será el responsable de resolverlo. Para ello tendrá que comunicarlo al equipo para ponerse de acuerdo con el miembro o miembros para acordar la versión correcta del código.

Resolución de conflictos  : cuando se produce un conflicto, Git nos impide realizar el push o commit correspondiente mostrándonos un aviso del mismo. Una vez se ha comunicado el conflicto al miembro o los miembros implicados se resuelve el conflicto manualmente y se vuelve a realizar el push.

Gestión de la integración continua

Gestión de incidencias

  • Las incidencias son gestionadas haciendo uso del sistema de issues que provee GitHub.
  • Se ha definido un patrón que debe seguirse al reportar una incidencia:
 -Título: Resumen de la incidencia
 -Descripción general :
   *En caso de ser una mejora: descripción detalla de la mejora y las funcionalidades afectadas por la misma
   *En caso de ser un error: pasos para reproducir la incidencia, comportamiento observado, comportamiento esperado.
 -Otros comentarios.
  • Las issues son etiquetadas por quien las reporta, pudiendo ser re-etiquetadas durante su ciclo de vida.
  • Procedimiento que seguimos en el ciclo de vida de la incidencia:
 1. Cuando una incidencia es reportada, los miembros del equipo son notificados vía e-mail.
 2. El jefe de proyecto:
    2.1 Primero comprueba si se disponen de los detalles suficientes o debe recabarse más información.
    2.2 Si se necesita más información  encarga al responsable de la incidencia a hacerlo.
 3.El miembro o los miembros del equipo encargado/s de la incidencia procede/n a su resolución.
 4.Se cierra la issue y se notifica al jefe de proyecto

Proyecto Opera

La entrega del proyecto se realizará mediante la plataforma Opera, espacio perteneciente proporcionado por la Universidad de Sevilla

Grupo27

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Verificación_Grupo_2_(Curso_2016-2017)&oldid=6154»