Diferencia entre revisiones de «Gestión del programa - 17 18 - G2»
Línea 21: | Línea 21: | ||
'''Subsistema''': Gestión de programas | '''Subsistema''': Gestión de programas | ||
− | '''Lenguaje/Herramienta''': Eclipse -> Php | + | '''Lenguaje/Herramienta''': Eclipse Oxygen Php -> Php |
'''Sistema de gestión de bibliotecas''': Composer | '''Sistema de gestión de bibliotecas''': Composer | ||
'''Bibliotecas''': <Listado de bibliotecas usadas en el desarrollo.> | '''Bibliotecas''': <Listado de bibliotecas usadas en el desarrollo.> | ||
Línea 62: | Línea 62: | ||
== Entorno de desarrollo == | == Entorno de desarrollo == | ||
− | - | + | - Se utiliza el ide Eclipse Php. |
+ | |||
+ | - Wordpress como gestor de contenido o cms. | ||
+ | |||
+ | - Xammp como gestor de base de datos MySQL. | ||
+ | |||
+ | - Apache como servidor http. | ||
== Gestión del código == | == Gestión del código == | ||
− | + | La gestión de código se realizara | |
== Formato general de commits == | == Formato general de commits == |
Revisión del 18:24 3 dic 2017
Contenido
- 1 Objetivo del subsistema
- 2 Consideraciones
- 3 Tecnologías Usadas
- 4 Api
- 5 Miembros del equipo
- 6 Gestión de las tareas
- 7 Gestión del tiempo
- 8 Entorno de desarrollo
- 9 Gestión del código
- 10 Formato general de commits
- 11 Gestión de incidencias
- 12 Integración continua
- 13 Diario del grupo
- 14 Gestión de ramas
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/laramorilla/project-program
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 Oxygen Php -> 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.
Gestión del tiempo
La gestión del tiempo se llevará a cabo mediante toggl.
- Se utiliza la herramienta online de toggl para crear el proyecto y el espacio de trabajo.
- Se utiliza también el complemento del navegador de toggl, integrando éste con el gestor de tareas de trello.
Entorno de desarrollo
- Se utiliza el ide Eclipse Php.
- Wordpress como gestor de contenido o cms.
- Xammp como gestor de base de datos MySQL.
- Apache como servidor http.
Gestión del código
La gestión de código se realizara
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 produce 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>"