Gestión del programa - 17 18 - G2

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:
gestion_del_programa_17_18_a_p.html

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