Diferencia entre revisiones de «Verificación 1617»

De Wiki de EGC
Saltar a: navegación, buscar
(→‎Tiempos individuales)
(→‎Tiempos individuales)
 
(No se muestran 24 ediciones intermedias de 2 usuarios)
Línea 1: Línea 1:
 
= Aspectos organizativos =
 
= Aspectos organizativos =
 +
 +
== Introducción ==
 +
*En el presente documento describimos como se ha desarrollado el proyecto de la asignatura de Evolución y Gestión de la Configuración (EGC), que consiste principalmente  en integrar nuestro proyecto que corresponde a un subsistema, con otros subsistemas para ofrecer una herramienta de voto online.
 +
 +
*En las primeras semanas de curso se propusieron una serie de proyectos o subsistemas que engloban una aplicación o sistema completo, cuya funcionalidad es la de hacer votaciones online.
 +
 +
*Estos proyectos, son proyectos creados de años anteriores, basado en  el proyecto Agora-Us. De estos proyectos, se nos proporcionan su desarrollo para poder realizar lo que será este año nuestro trabajo, que consiste en modificar y  corregir posibles conflictos, incidencias  o simplemente proporcionar mejoras para cumplir el objetivo principal, integrarnos con los demás subsistemas y hacer funcionar el sistema en toda su totalidad.
 +
+
 +
Los distintos subsistemas proporcionados se reparten en subgrupos hechos en el aula, donde cada uno de estos subgrupos tendrá que coordinarse unos con otros para llevar a cabo el objetivo principal antes mencionado.
 +
 +
*Nuestro grupo de trabajo ha tenido que valorar y tomar decisiones tanto internamente cómo con los demás grupos de los demás subsistemas teniendo que establecer procesos y herramientas ya constituidas para crear políticas de trabajo y seguir unas pautas para el desarrollo de nuestro subsistema y para la integración con los demás subsistemas.
 +
 +
*Además de la temática que se imparte en la asignatura, se aportaron una serie de herramientas de gestión de código, gestión de incidencias y depuración para poder desarrollar nuestro subsistema y poder realizar los procesos de integración continua con los demás subsistemas así como el uso de un servidor donde se irá actualizando el desarrollo de cada subsistema y hacer más fácil la integración completa de todos los subsistemas.
  
 
== Miembros ==
 
== Miembros ==
Línea 18: Línea 31:
 
::* [[Acta Reunión VII (09/01/2017) - Grupo 1 - Verificación1617| Acta Reunión VII (09/01/2017)]]
 
::* [[Acta Reunión VII (09/01/2017) - Grupo 1 - Verificación1617| Acta Reunión VII (09/01/2017)]]
 
::* [[Acta Reunión VIII (26/01/2017) - Grupo 1 - Verificación1617| Acta Reunión VIII (26/01/2017)]]
 
::* [[Acta Reunión VIII (26/01/2017) - Grupo 1 - Verificación1617| Acta Reunión VIII (26/01/2017)]]
−
::* [[Acta Reunión IX (/30/2017) - Grupo 1 - Verificación1617| Acta Reunión IX (30/01/2017)]]
+
::* [[Acta Reunión IX (30/01/2017) - Grupo 1 - Verificación1617| Acta Reunión IX (30/01/2017)]]
 +
::* [[Acta Reunión X (01/02/2017) - Grupo 1 - Verificación1617| Acta Reunión X (01/02/2017)]]
  
 
== Ecosistema de desarrollo ==
 
== Ecosistema de desarrollo ==
Línea 26: Línea 40:
  
 
== Gestión de código fuente ==
 
== 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.
+
*Usaremos un repositorio Git llamado AgoraUS-G1-1617 para administrar el código fuente del sistema. En este repositorio, que se ubica en el servicio de alojamiento de repositorios Git Github, cada subsistema se desarrollará en un repositorio diferente dentro del repositorio global. En el repositorio AgoraUS se recogerá el trabajo realizado y funcional de todos los grupos y su correspondiente integración.
−
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.
+
 
 +
*Usar un repositorio global facilita el acceso al código por parte de cada grupo. Podemos obtener el código de otros grupos clonando sus repositorios y haciendo pull, obteniendo así el código más reciente del subsistema en cuestión.
 +
 
 +
*Usar un único repositorio nos facilita aún más el acceso al código ya que solo tendríamos que hacer pull de la rama master para obtener el código de los demás subsistemas pero nos encontraríamos con el inconveniente de que cualquier persona podría modificar lo que quisiera, independientemente del grupo en el que se halle. Este inconveniente no se nos presenta porque sólo tenemos acceso de lectura a los repositorios a los que no pertenecemos.
 +
 +
*Tampoco se nos presentará problemas de conflictos con los demás grupos al alojarnos en repositorios diferentes. Si usáramos un único repositorio tendríamos que crear una carpeta o una rama para cada subsistema con el fin de evitar numerosos conflictos que se presentarían al compartir muchos subsistemas la misma estructura de archivos.
 +
 
 +
== Gestión de conflictos ==
 +
'''*Introducción:''' En el caso de que se genere un conflicto, será el miembro del grupo que lo divise primero el encargado de resolverlo. Para esto tendrá que ponerse en contacto con los demás miembros o con alguno en concreto si fuere necesario para acordar la versión escogida, etc.
 +
 
 +
'''*Implementación''': Utilizamos la consola y el sistema de resolución de conflictos de Git. Este sistema impide un commit o un push en el caso de que haya conflicto además de mostrar un aviso. Para resolver el conflicto, la persona que intentó la operación debe editar manualmente los archivos para quedarnos con el contenido adecuado. Una vez hecho esto, se realiza la operación de nuevo pero sin conflicto.
 +
 
 +
'''*Lecciones aprendidas:''' La resolución de conflictos ha sido intuitiva y rápida, limitándose a conocimiento del proyecto y comunicación con los demás miembros del grupo.
 +
 
 +
== Gestión de la construcción ==
 +
*Para la construcción automática del sistema se utilizara la herramientas Travis CI. Esta herramienta te permite realizar la construcción cada vez que se realiza un commit al repositorio de código de GitHub. Travis aparte de realización la construcción ( crear el .jar del proyecto) previo a esto realiza cada uno de los test de la aplicación, comprobando que funcionan correctamente
 +
 
 +
== Gestión de las liberaciones, despliegue y entregas ==
 +
*Esta sección, abarca toda la información referente a los distintos elementos y/o entregables necesarios para la entrega, así como toda aquella documentación que lo compone, proyecto desarrollado por todo el equipo de trabajo y la correspondiente máquina virtual para el despliegue.
 +
 
 +
== Gestión de la integración continua ==
 +
*El proceso de integración continua tiene como objetivo principal comprobar que cada actualización del código fuente desarrollado por el equipo de trabajo no genere problemas en una aplicación que se está desarrollando.
 +
Por lo tanto, la integración continua se usa como práctica de desarrollo software donde todos los componentes del equipo integran a lo largo del tiempo de vida del proyecto su trabajo, con el fin de conseguir un software de mayor calidad.
 +
 
 +
*Las ventajas que ofrece la integración continua son las siguientes:
 +
 
 +
    -Ejecución automática de pruebas unitarias, conociendo a su vez los resultados de éstos.
 +
 
 +
    -Ofrece información de cualquier incidencia tras un período de codificación, dándonos la posibilidad de saber
 +
      quién y cuándo ha realizado un cambio de impacto negativo en el proyecto.
 +
 
 +
    -Permite detectar los errores lo más pronto posible, en fases tempranas de desarrollo, dando la posibilidad
 +
      de encontrar solución cuanto antes.
 +
 
 +
    -Monitorización continua de las métricas de calidad del proyecto.
  
 
== Gestión de incidencias ==
 
== Gestión de incidencias ==
Línea 86: Línea 134:
 
== Subsistemas relacionados ==
 
== Subsistemas relacionados ==
  
−
* [[Creación Administración Votaciones 1617|Creación de votaciones]]
+
 
−
* [[Cabina de votación Telegram|Cabina de votación]]
+
[[Cabina de votación Telegram|Cabina de votación]]
−
* [[Recuento y modificación G1 1617|Recuento y modificación]]
+
*Un subsistema de AGORA@US donde el votante podrá ver las distintas opciones y votar una de ellas. El voto tiene que cifrarse en cliente, nunca debe llegar al servidor sin cifrar.
 +
 
 +
[[Creación_Administración_Votaciones_1617 | Creación y administración de votaciones]]
 +
*Un subsistema de Agora@US "Administración y Creación de Votaciones". Nuestro grupo es el encargado de comprobar que la creación de las votaciones es la correcta y que los votos no han sido alterados.
  
 
== Tiempos individuales ==
 
== Tiempos individuales ==
Línea 395: Línea 446:
 
|-  
 
|-  
 
| Ernesto Rodriguez Nuñez  
 
| Ernesto Rodriguez Nuñez  
−
| ReuniónVII
+
| Reunión VII
−
| 26-01-2017 09:30
+
| 09-01-2017 09:30
−
| 26-01-2017 14:00
+
| 09-01-2017 14:00
 
| 05:30
 
| 05:30
 
|-  
 
|-  
Línea 425: Línea 476:
 
|-  
 
|-  
 
| Ernesto Rodriguez Nuñez  
 
| Ernesto Rodriguez Nuñez  
−
| ReuniónVIII
+
| Reunión VIII
 
| 26-01-2017 10:30
 
| 26-01-2017 10:30
 
| 26-01-2017 14:00
 
| 26-01-2017 14:00
Línea 460: Línea 511:
 
| 05:00
 
| 05:00
 
|-  
 
|-  
 +
| Rafael Del Rio Franco
 +
| Reunión X
 +
| 01-02-2017 10:00
 +
| 01-21-2017 21:00
 +
| 11:00
 +
|-
 +
| Jesus Navas Inocencio
 +
| Reunión X
 +
| 01-02-2017 10:00
 +
| 01-21-2017 21:00
 +
| 11:00
 +
|-
 +
| Macarena Rufo Palomo
 +
| Reunión X
 +
| 01-02-2017 10:00
 +
| 01-21-2017 21:00
 +
| 11:00
 +
|-
 +
| Jose Carlos Ruiz Navarro
 +
| Reunión X
 +
| 01-02-2017 10:00
 +
| 01-21-2017 21:00
 +
| 11:00
 +
|-
 +
| Ernesto Rodriguez Nuñez
 +
| Reunión X
 +
| 01-02-2017 10:00
 +
| 01-21-2017 21:00
 +
| 11:00
 +
|-
 
| TOTAL  
 
| TOTAL  
 
|   
 
|   
 
|   
 
|   
 
|   
 
|   
−
|137:00:00  
+
|212:00:00  
 
|-  
 
|-  
 
|}
 
|}
Línea 482: Línea 563:
  
 
[http://opera.eii.us.es/egc/public/trabajo/ver/id/56 Verificación en Opera]
 
[http://opera.eii.us.es/egc/public/trabajo/ver/id/56 Verificación en Opera]
 +
 +
== Enlaces interesantes ==
 +
*Repositorio del codigo: https://github.com/EGC-1617/Verificacion-G1
 +
*Proyecto en opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/56
 +
*Mapa de herramientas: https://www.text2mindmap.com/
 +
*Travis: https://travis-ci.org/EGC-1617/Verificacion-G13
 +
*Wiki: https://1984.lsi.us.es/wiki-egc/index.php/Verificaci%C3%B3n_1617
 +
*Repositorio compartido: https://github.com/AgoraUS-G1-1617/Verificacion-G13
 +
*Máquina Virtual (Mega) :

Revisión actual del 18:46 2 feb 2017

Aspectos organizativos

Introducción

  • En el presente documento describimos como se ha desarrollado el proyecto de la asignatura de Evolución y Gestión de la Configuración (EGC), que consiste principalmente en integrar nuestro proyecto que corresponde a un subsistema, con otros subsistemas para ofrecer una herramienta de voto online.
  • En las primeras semanas de curso se propusieron una serie de proyectos o subsistemas que engloban una aplicación o sistema completo, cuya funcionalidad es la de hacer votaciones online.
  • Estos proyectos, son proyectos creados de años anteriores, basado en el proyecto Agora-Us. De estos proyectos, se nos proporcionan su desarrollo para poder realizar lo que será este año nuestro trabajo, que consiste en modificar y corregir posibles conflictos, incidencias o simplemente proporcionar mejoras para cumplir el objetivo principal, integrarnos con los demás subsistemas y hacer funcionar el sistema en toda su totalidad.

+ Los distintos subsistemas proporcionados se reparten en subgrupos hechos en el aula, donde cada uno de estos subgrupos tendrá que coordinarse unos con otros para llevar a cabo el objetivo principal antes mencionado.

  • Nuestro grupo de trabajo ha tenido que valorar y tomar decisiones tanto internamente cómo con los demás grupos de los demás subsistemas teniendo que establecer procesos y herramientas ya constituidas para crear políticas de trabajo y seguir unas pautas para el desarrollo de nuestro subsistema y para la integración con los demás subsistemas.
  • Además de la temática que se imparte en la asignatura, se aportaron una serie de herramientas de gestión de código, gestión de incidencias y depuración para poder desarrollar nuestro subsistema y poder realizar los procesos de integración continua con los demás subsistemas así como el uso de un servidor donde se irá actualizando el desarrollo de cada subsistema y hacer más fácil la integración completa de todos los subsistemas.

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

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 AgoraUS-G1-1617 para administrar el código fuente del sistema. En este repositorio, que se ubica en el servicio de alojamiento de repositorios Git Github, cada subsistema se desarrollará en un repositorio diferente dentro del repositorio global. En el repositorio AgoraUS se recogerá el trabajo realizado y funcional de todos los grupos y su correspondiente integración.
  • Usar un repositorio global facilita el acceso al código por parte de cada grupo. Podemos obtener el código de otros grupos clonando sus repositorios y haciendo pull, obteniendo así el código más reciente del subsistema en cuestión.
  • Usar un único repositorio nos facilita aún más el acceso al código ya que solo tendríamos que hacer pull de la rama master para obtener el código de los demás subsistemas pero nos encontraríamos con el inconveniente de que cualquier persona podría modificar lo que quisiera, independientemente del grupo en el que se halle. Este inconveniente no se nos presenta porque sólo tenemos acceso de lectura a los repositorios a los que no pertenecemos.
  • Tampoco se nos presentará problemas de conflictos con los demás grupos al alojarnos en repositorios diferentes. Si usáramos un único repositorio tendríamos que crear una carpeta o una rama para cada subsistema con el fin de evitar numerosos conflictos que se presentarían al compartir muchos subsistemas la misma estructura de archivos.

Gestión de conflictos

*Introducción: En el caso de que se genere un conflicto, será el miembro del grupo que lo divise primero el encargado de resolverlo. Para esto tendrá que ponerse en contacto con los demás miembros o con alguno en concreto si fuere necesario para acordar la versión escogida, etc.

*Implementación: Utilizamos la consola y el sistema de resolución de conflictos de Git. Este sistema impide un commit o un push en el caso de que haya conflicto además de mostrar un aviso. Para resolver el conflicto, la persona que intentó la operación debe editar manualmente los archivos para quedarnos con el contenido adecuado. Una vez hecho esto, se realiza la operación de nuevo pero sin conflicto.

*Lecciones aprendidas: La resolución de conflictos ha sido intuitiva y rápida, limitándose a conocimiento del proyecto y comunicación con los demás miembros del grupo.

Gestión de la construcción

  • Para la construcción automática del sistema se utilizara la herramientas Travis CI. Esta herramienta te permite realizar la construcción cada vez que se realiza un commit al repositorio de código de GitHub. Travis aparte de realización la construcción ( crear el .jar del proyecto) previo a esto realiza cada uno de los test de la aplicación, comprobando que funcionan correctamente

Gestión de las liberaciones, despliegue y entregas

  • Esta sección, abarca toda la información referente a los distintos elementos y/o entregables necesarios para la entrega, así como toda aquella documentación que lo compone, proyecto desarrollado por todo el equipo de trabajo y la correspondiente máquina virtual para el despliegue.

Gestión de la integración continua

  • El proceso de integración continua tiene como objetivo principal comprobar que cada actualización del código fuente desarrollado por el equipo de trabajo no genere problemas en una aplicación que se está desarrollando.

Por lo tanto, la integración continua se usa como práctica de desarrollo software donde todos los componentes del equipo integran a lo largo del tiempo de vida del proyecto su trabajo, con el fin de conseguir un software de mayor calidad.

  • Las ventajas que ofrece la integración continua son las siguientes:
    -Ejecución automática de pruebas unitarias, conociendo a su vez los resultados de éstos.

    -Ofrece información de cualquier incidencia tras un período de codificación, dándonos la posibilidad de saber 
     quién y cuándo ha realizado un cambio de impacto negativo en el proyecto.

    -Permite detectar los errores lo más pronto posible, en fases tempranas de 	desarrollo, dando la posibilidad 
     de encontrar solución cuanto antes.

    -Monitorización continua de las métricas de calidad del proyecto.

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

Cabina de votación

  • Un subsistema de AGORA@US donde el votante podrá ver las distintas opciones y votar una de ellas. El voto tiene que cifrarse en cliente, nunca debe llegar al servidor sin cifrar.

Creación y administración de votaciones

  • Un subsistema de Agora@US "Administración y Creación de Votaciones". Nuestro grupo es el encargado de comprobar que la creación de las votaciones es la correcta y que los votos no han sido alterados.

Tiempos individuales

Autor Tarea Comienzo Fin Duración (hh:mm)
Rafael Del Rio Franco Reunión I 12-10-2016 17:30 12-10-2016 18:30 01:00
Jesus Navas Inocencio Reunión I 12-10-2016 17:30 12-10-2016 18:30 01:00
Macarena Rufo Palomo Reunión I 12-10-2016 17:30 12-10-2016 18:30 01:00
Jose Carlos Ruiz Navarro Reunión I 12-10-2016 17:30 12-10-2016 18:30 01:00
Ernesto Rodriguez Nuñez Reunión I 12-10-2016 17:30 12-10-2016 18:30 01:00
Rafael Del Rio Franco Milestone 1 09-11-2016 10:40 09-11-2016 12:30 01:50
Jesus Navas Inocencio Milestone 1 09-11-2016 10:40 09-11-2016 12:30 01:50
Macarena Rufo Palomo Milestone 1 09-11-2016 10:40 09-11-2016 12:30 01:50
Jose Carlos Ruiz Navarro Milestone 1 09-11-2016 10:40 09-11-2016 12:30 01:50
Ernesto Rodriguez Nuñez Milestone 1 09-2016 10:40 09-11-2016 12:30 01:50
Rafael Del Rio Franco Reunión II 09-11-2016 17:30 09-11-2016 18:30 01:30
Jesus Navas Inocencio Reunión II 09-11-2016 17:30 09-11-2016 18:30 01:30
Macarena Rufo Palomo Reunión II 09-11-2016 17:30 09-11-2016 18:30 01:30
Jose Carlos Ruiz Navarro Reunión II 09-11-2016 17:30 09-11-2016 18:30 01:30
Ernesto Rodriguez Nuñez Reunión II 09-11-2016 17:30 09-11-2016 18:30 01:30
Rafael Del Rio Franco Milestone 2 30-11-2016 10:40 30-11-2016 12:30 01:50
Jesus Navas Inocencio Milestone 2 30-11-2016 10:40 30-11-2016 12:30 01:50
Macarena Rufo Palomo Milestone 2 30-11-2016 10:40 30-11-2016 12:30 01:50
Jose Carlos Ruiz Navarro Milestone 2 30-11-2016 10:40 30-11-2016 12:30 01:50
Ernesto Rodriguez Nuñez Milestone 2 30-11-2016 10:40 30-11-2016 12:30 01:50
Rafael Del Rio Franco Reunión III 07-12-2016 10:30 07-12-2016 13:40 03:10
Jesus Navas Inocencio Reunión III 07-12-2016 10:30 07-12-2016 13:40 03:10
Macarena Rufo Palomo Reunión III 07-12-2016 10:30 07-12-2016 13:40 03:10
Jose Carlos Ruiz Navarro Reunión III 07-12-2016 10:30 07-12-2016 13:40 03:10
Ernesto Rodriguez Nuñez Reunión III 07-12-2016 10:30 07-12-2016 13:40 03:10
Rafael Del Rio Franco Milestone 3 21-12-2016 10:40 21-12-2016 12:30 01:50
Jesus Navas Inocencio Milestone 3 21-12-2016 10:40 21-12-2016 12:30 01:50
Macarena Rufo Palomo Milestone 3 21-12-2016 10:40 21-12-2016 12:30 01:50
Jose Carlos Ruiz Navarro Milestone 3 21-12-2016 10:40 21-12-2016 12:30 01:50
Ernesto Rodriguez Nuñez Milestone 3 21-12-2016 10:40 21-12-2016 12:30 01:50
Rafael Del Rio Franco Reunión IV 27-12-2016 10:30 27-12-2016 14:00 03:30
Jesus Navas Inocencio Reunión IV 27-12-2016 10:30 27-12-2016 14:00 03:30
Macarena Rufo Palomo Reunión IV 27-12-2016 10:30 27-12-2016 14:00 03:30
Jose Carlos Ruiz Navarro Reunión IV 27-12-2016 10:30 27-12-2016 14:00 03:30
Ernesto Rodriguez Nuñez Reunión IV 27-12-2016 10:30 27-12-2016 14:00 03:30
Rafael Del Rio Franco Reunión V 27-12-2016 15:30 27-12-2016 17:30 02:00
Jesus Navas Inocencio Reunión V 27-12-2016 15:30 27-12-2016 17:30 02:00
Macarena Rufo Palomo Reunión V 27-12-2016 15:30 27-12-2016 17:30 02:00
Jose Carlos Ruiz Navarro Reunión V 27-12-2016 15:30 27-12-2016 17:30 02:00
Ernesto Rodriguez Nuñez Reunión V 27-12-2016 15:30 27-12-2016 17:30 02:00
Rafael Del Rio Franco Reunión VI 28-12-2016 10:30 28-12-2016 13:30 03:00
Jesus Navas Inocencio Reunión VI 28-12-2016 10:30 28-12-2016 13:30 03:00
Macarena Rufo Palomo Reunión VI 28-12-2016 10:30 28-12-2016 13:30 03:00
Jose Carlos Ruiz Navarro Reunión VI 28-12-2016 10:30 28-12-2016 13:30 03:00
Ernesto Rodriguez Nuñez Reunión VI 28-12-2016 10:30 28-12-2016 13:30 03:00
Rafael Del Rio Franco Reunión VII 09-01-2017 09:30 09-01-2017 14:00 05:30
Jesus Navas Inocencio Reunión VII 09-01-2017 09:30 09-01-2017 14:00 05:30
Macarena Rufo Palomo Reunión VII 09-01-2017 09:30 09-01-2017 14:00 05:30
Jose Carlos Ruiz Navarro Reunión VII 09-01-2017 09:30 09-01-2017 14:00 05:30
Ernesto Rodriguez Nuñez Reunión VII 09-01-2017 09:30 09-01-2017 14:00 05:30
Rafael Del Rio Franco Reunión VIII 26-01-2017 10:30 26-01-2017 14:00 03:30
Jesus Navas Inocencio Reunión VIII 26-01-2017 10:30 26-01-2017 14:00 03:30
Macarena Rufo Palomo Reunión VIII 26-01-2017 10:30 26-01-2017 14:00 03:30
Jose Carlos Ruiz Navarro Reunión VIII 26-01-2017 10:30 26-01-2017 14:00 03:30
Ernesto Rodriguez Nuñez Reunión VIII 26-01-2017 10:30 26-01-2017 14:00 03:30
Rafael Del Rio Franco Reunión IX 30-01-2017 09:00 30-01-2017 14:00 05:00
Jesus Navas Inocencio Reunión IX 30-01-2017 09:00 30-01-2017 14:00 05:00
Macarena Rufo Palomo Reunión IX 30-01-2017 09:00 30-01-2017 14:00 05:00
Jose Carlos Ruiz Navarro Reunión IX 30-01-2017 09:00 30-01-2017 14:00 05:00
Ernesto Rodriguez Nuñez Reunión IX 30-01-2017 09:00 30-01-2017 14:00 05:00
Rafael Del Rio Franco Reunión X 01-02-2017 10:00 01-21-2017 21:00 11:00
Jesus Navas Inocencio Reunión X 01-02-2017 10:00 01-21-2017 21:00 11:00
Macarena Rufo Palomo Reunión X 01-02-2017 10:00 01-21-2017 21:00 11:00
Jose Carlos Ruiz Navarro Reunión X 01-02-2017 10:00 01-21-2017 21:00 11:00
Ernesto Rodriguez Nuñez Reunión X 01-02-2017 10:00 01-21-2017 21:00 11:00
TOTAL 212:00:00

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

Enlaces interesantes

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Verificación_1617&oldid=6062»