Verificación Grupo 2 (Curso 2016-2017)
Contenido
Miembros
- Hugo Ramos Rico Jefe de Proyecto
- Alberto Castillo Molina Ingeniero Software
- Alejandro García García Ingeniero Software
- Andrés García González Ingeniero Software
- Dylan Moreno Téllez Ingeniero Software
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
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
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
