Revisión del 11:01 12 ene 2017

Aspectos organizativos

Miembros

• Del Rio Franco, Rafael: Project Manager
• Navas Inocencio, Jesús: Software Developer
• Rodriguez Nuñez, Ernesto: Software Developer
• Rufo Palomo, Macarena: Software Developer
• Ruiz Navarro, Jose Carlos: Software Developer

Actas

• Acta Reunión I (12/10/2016)
• Acta Reunión II (09/11/2016
• Acta Reunión III (07/12/2016)
• Acta Reunión IV (27/12/2016)
• Acta Reunión V (27/12/2016)
• Acta Reunión VI (28/12/2016)
• Acta Reunión VII (09/01/2017)

Ecosistema de desarrollo

El entorno de desarrollo que usaremos será Eclipse, debido a la familiarización de todos los miembros del equipo con este entorno de desarrollo. De este modo, podremos reutilizar la máquina virtual que proveían el grupo Verificacion 15/16 (Tarde)

Descarga del entorno de desarrollo

Gestión de código fuente

Usaremos un repositorio Git llamado Verificacion-G1(https://github.com/EGC-1617/Verificacion-G1), para administrar el código fuente del sistema. Este repositorio es solo para el grupo nuestro. A parte de este, hay un repositorio general llamado continuous-integration-agoraus_g1(https://github.com/AgoraUS-G1-1617/continuous-integration-agoraus_g1), en el que todos los subsistemas del grupo 1 integran sus distintas funcionalidades. Nosotros en este caso, no consumimos recursos de nadie, tan solo generamos un .jar que subiremos a este repositorio para que los subsistemas que hangan uso de el, lo utilicen.

Gestión de incidencias

Para la gestión de incidencias usaremos las Issue de GitHub.

Una vez encontremos una incidencia tendremos que:

- Analizar: Las incidencias serán analizadas por al menos dos miembros del equipo, los cuales reproducirán la incidencia (para ello se espera que el autor de la incidencia de todos los detalles para poder reproducir lo ocurrido), analizaran y clasifican según su prioridad:

• ALTA: Un servicio se ve afectado de manera severa impidiendo su uso y afectando a actividades críticas de negocio.

• MEDIA: Un servicio se ve afectado impidiendo su uso pero no afectando a actividades críticas de negocio.

• BAJA: Un servicio se ve afectado pero no impide su uso.

- Resolución: La resolución de la incidencia será asignada a un miembro del equipo, el cual debe resolverla. En el caso de tener más de una incidencia asignada, se resolverán por orden de prioridad, siendo el orden de prioridad en resolverla ALTA, MEDIA, y BAJA. Una vez solucionado, será subido a gitHub.

- Revisión: Se asignará un miembro del equipo (puede ser el que realizó la incidencia), el cual deberá revisar que la resolución es correcta.

- Cierre: Se cerrará la incidencia y se documentará la solución tomada.

Integración continua

La integración continua del sistema se gestiona haciendo uso de las herramientas Jenkins, Maven y Docker.

Jenkins

• Consiste en hacer integraciones automáticas de un proyecto con el objetivo de detectar fallos cuanto antes. Consta de tres fases: Make, Beta y Stable.

    *Fase Make (URL)
     Se encarga de descargar el proyecto tras una modificación, ejecutar test para comprobar la integridad  y desplegarlo, es decir, ejecutar los test y       
     todas las acciones oportunas antes de desplegar el proyecto.

   *Fase Beta (URL)
     Se encarga de eliminar restos de despliegue anterior, preparar el despliegue y desplegar.

   *Fase Stable (URL)
     Se ejecuta manualmente y las fases principales son las mismas que en la fase Beta y usa los archivos provenientes de la misma con el fin de conseguir    
     la estabilidad del proyecto.

Travis

• Travis será la encargada de comprobar de lanzar comandos de Maven con el objetivo de comprobar los test de la aplicación, y esto lo hará cuando detecte un commit. Además, Travis añadirá automáticamente añade el verificacion1.jar.

• El objetivo de esto, es automatizar la construcción, la entrega y despliegue del sistema y la ejecución de pruebas

Subsistemas relacionados

• Creación de votaciones
• Cabina de votación
• Recuento y modificación

Tiempos individuales

Repositorio de código

Se utilizará Git como herramienta de gestión de código ya que permite la posibilidad de realizar commits locales. Además esto supone el uso de una característica que el equipo no ha utilizado anteriormente, por lo que supone una oportunidad para aprender un nuevo software de control de versiones.

Verificación en GitHub

Sitio de despliegue del subsistema

Este subsistema no está diseñado para despliegue web, sino para despliegue en forma de librería .jar consumida por otros subsistemas.

Proyecto en Opera

La forma en la que haremos entregar los distintos entregables del proyecto para su posterior corrección sera haciendo uso del portal Opera. El espacio usado por este proyecto de opera es el siguiente:

Verificación en Opera