Diferencia entre revisiones de «Verificación 1617»
(→Actas) |
(→Actas) |
||
| Línea 11: | Línea 11: | ||
::* [[Acta Reunión I (18/11/2015) - Grupo 1 - Verificación1617| Acta Reunión I (18/11/2015)]] | ::* [[Acta Reunión I (18/11/2015) - Grupo 1 - Verificación1617| Acta Reunión I (18/11/2015)]] | ||
| + | ::* [[Acta Reunión II (18/11/2015) - Grupo 1 - Verificación1617| Acta Reunión II (18/11/2015)]] | ||
| + | ::* [[Acta Reunión III (18/11/2015) - Grupo 1 - Verificación1617| Acta Reunión III (18/11/2015)]] | ||
== Ecosistema de desarrollo == | == Ecosistema de desarrollo == | ||
Revisión del 12:11 7 dic 2016
Contenido
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
Ecosistema de desarrollo
Gestión de código fuente
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 (distinto al que realizó la resolución), 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
Subsistemas relacionados
- Autenticación (https://github.com/AgoraUS-G1-1617/Autentication)
- Censo (https://github.com/AgoraUS-G1-1617/CensoEGC)
- Cabina de votaciones (https://github.com/AgoraUS-G1-1617/Cabina-de-votaciones)
Tiempos individuales
| Autor | Tarea | Comienzo | Fin | Duración (hh:mm) |
|---|---|---|---|---|
| Rafael Del Rio Franco | Reunión de planificación | 09-11-2016 12:03 | 09-11-2016 12:45 | 00:42 |
| TOTAL | 9:24:33 |
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.
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:
