Administración de votaciones - 17 18 - G1

De Wiki de EGC
Revisión del 23:00 3 ene 2018 de Elvgarrui (discusión | contribuciones) (Entorno de trabajo)
Saltar a: navegación, buscar

Miembros

  • Domingo Muñoz Daza (coordinador)
  • Ana Rosa Aparicio Ramos
  • Elvira García Ruiz
  • Javier Centeno Vega
  • Jose Manuel Pallero Hidalgo

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace Cualquier decisión importante añadida a él o cambio que pueda implicar al resto de grupos se notificará a los coordinadores previamente.

Entorno de trabajo

Nuestro entorno de trabajo será variado, ya que desarrollamos tanto desde Linux, como Windows y Mac, debido a los terminales de los componentes del grupo. Todos usamos Eclipse con el plugin Pydev para el desarrollo en Python, así como eGit para el control de versiones con eclipse.

Formatos y procedimientos

De carácter optativo hasta el 30/11/17 y obligatorio a partir de dicha fecha distinguimos el formateado de los siguientes elementos:

Formato para detallar tecnologías elegidas

Subsistema: Administración de Votaciones
Lenguaje/Herramienta: Python 2.7 
Sistema de gestión de bibliotecas: Pip
Bibliotecas:
   python-mysql: latest
   django: 1.5
Necesita Base de datos: Sí, MariaDB 10.1

Procedimiento de gestión de tareas, cambios e incidendias

Para la gestión de las incidencias, se usarán los Issues que GitHub permite gestionar en cada repositorio. El uso de estos Issues está basado en las diapositivas de clase de (Gestión de Incidencias), haciéndose de la siguiente manera:

  • Cada grupo es responsable de la gestión de sus Issues.
  • Cada Issue representará una tarea o problema encontrado por el grupo.
  • Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre las fases TO DO, En progreso, En espera/Con problemas, En revisión y Hecho según corresponda a su avance.
  • Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.
  • Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Hecho se su proyecto correspondiente.
  • Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo. Los tipos son Cambio/Mejora y Bug, que sólo se incluirán en dichos casos. Las temáticas son libres para cada subgrupo. Las prioridades son Critical, High, Medium y Low, y los estados son New, Accepted (sólo para cambios), Started, Fixed, Verified, Duplicate (cambios y bugs) y Wontfix (cambios y bugs).
  • Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.