Diferencia entre revisiones de «Gestión del programa - 17 18 - G2»

Revisión del 19:03 2 dic 2017

Objetivo del subsistema

Mejorar la introducción y gestión del programa así como facilitar los datos necesarios al grupo de visualización.

Consideraciones

Debe tener una API para, al menos, consultar los datos del programa y facilitarlos al grupo de Visualización.

Repositorio donde puede encontrarse el código:
https://github.com/jagalindo/program-manager-wpp

Wiki de la asignatura referente al módulo:
https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_del_programa_-_17_18

Tecnologías Usadas

Subsistema: Gestión de programas
Lenguaje/Herramienta: Eclipse -> Php
Sistema de gestión de bibliotecas:  Composer
Bibliotecas: <Listado de bibliotecas usadas en el desarrollo.>
Necesita Base de datos: Sí (todavía no definida)

Api

Consultar los datos del programa

Miembros del equipo

Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software
Jose Manuel Luque Mendoza Ingeniero Software
Samuel Gonzalez Zuluaga Ingeniero Software
Felix Blanco Castaño Ingeniero Software
Jose Manuel Lara Morilla Ingeniero Software

Gestión de las tareas

La gestión y asignación de tareas se llevará a cabo mediante Trello. Dentro del tablero aparecerán 3 columnas, que serían las siguientes:

- Tareas a realizar: aquellas tareas que estén pendientes de su comienzo.

- Tareas en proceso: aquellas tareas que ya han comenzado.

- Tareas finalizadas: aquellas tareas que han sido terminadas.

Entorno de desarrollo

Gestión del código

Formato general de commits

El formato general de los commits parte de la siguiente base.

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

Título del commit: fix: redirección errónea tras emitir voto
Cuerpo del commit: Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
Pie del commit: Closes #<número de la incidencia en GitHub>

Gestión de incidencias

Detallar incidencias:

  Título: <breve título sobre la incidencia>
  Prioridad: a seleccionar entre distintos valores: urgente, alto, medio, bajo.
  Estado: pendiente, en curso, finalizado. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce 
   cuando se cierra la incidencia en GitHub.
  Descripción: <descripción detallada del error>
   La descripción puede incluir imagenes o la salida emitida por el fallo.
  Etiquetas: <etiquetas de GitHub para clasificar las incidencias>
   enhancement: propuesta de mejora.
   bug: fallos encontrados en el sistema.
   help wanted: incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro.
   question: (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión.

Procedimiento para la gestión de incidencias:

  # Establecer a un miembro del equipo el rol de gestor de incidencias.
  # Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la 
  incidencia.
  # El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Integración continua

Diario del grupo