Gestión del programa - 17 18 - G2
Contenido
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: Ninguno Bibliotecas: Ninguna Necesita Base de datos: Sí, MySQL
Formato para detallar Api
URL base
URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/
Descripción
XXX corresponde al id de la página que quieres obtener.
Petición HTTP
Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)
Parámetros de petición
Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).
Por ejemplo:
Nombre | Tipo | Descripción | Valor por defecto |
---|---|---|---|
user | integer | Nombre del usuario |
Ejemplo de petición
Ejemplo de uso de la url (Ej: GET http://localhost/splc/wp-json/wp/v2/pages/639/)
Respuesta
Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg
Por ejemplo:
Nombre | Tipo | Descripción |
---|---|---|
result | Boolean | Resultado de la operación |
msg | String | Mensaje de resultado o error |
Ejemplo de respuesta
Ejemplo de la respuesta a recibir.
{ "result" : true, "msg" : "Successfull" "username" : "tansalalv", "name" : "Tania", "surname" : "Salguero Álvarez", "email" : "mail@example.com", "genre" : "Femenino", "autonomous_community" : "Andalucía", "age" : "21", "role" : "USUARIO" }
Miembros del equipo
Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software
Jose Manuel Luque Mendoza - Ingeniero Software, Gestor de tareas.
Samuel Gonzalez Zuluaga - Ingeniero Software, Gestor de código.
Felix Blanco Castaño - Ingeniero Software, Gestor de tiempo.
Jose Manuel Lara Morilla - Ingeniero Software, Gestor de incidencias.
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 mediante el gestor de control de versiones GIT.
- Para el alojamiento de nuestro proyecto utilizaremos GitHub.
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>"
Gestión de ramas
Se utilizará un "git flow" parecido al del equipo de integración pero en nuestro caso usaremos una rama por cada nueva funcionalidad que vayamos añadir a nuestro proyecto, a parte de las ramas development y master. https://ibb.co/eeQ14b