Diferencia entre revisiones de «Gestión del programa - 17 18 - G2»
(→Tecnologías Usadas) |
|||
(No se muestran 33 ediciones intermedias de 5 usuarios) | |||
Línea 6: | Línea 6: | ||
== Consideraciones == | == Consideraciones == | ||
+ | Debe tener una API para, al menos, consultar los datos del programa y facilitarlos al grupo de Visualización. | ||
+ | <br/> | ||
+ | <br/> | ||
+ | Repositorio donde puede encontrarse el código: | ||
+ | <br/> | ||
+ | https://github.com/laramorilla/project-program | ||
+ | <br/> | ||
+ | <br/> | ||
+ | Wiki de la asignatura referente al módulo: | ||
+ | <br/> | ||
+ | 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: | ||
+ | |||
+ | {| border="1" style="border-collapse:collapse" | ||
+ | |- | ||
+ | ! 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: | ||
+ | {| border="1" style="border-collapse:collapse" | ||
+ | |- | ||
+ | ! 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 == | == Miembros del equipo == | ||
+ | Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software | ||
+ | <br/> | ||
+ | Jose Manuel Luque Mendoza - Ingeniero Software, Gestor de tareas. | ||
+ | <br/> | ||
+ | Samuel Gonzalez Zuluaga - Ingeniero Software, Gestor de código. | ||
+ | <br/> | ||
+ | Felix Blanco Castaño - Ingeniero Software, Gestor de tiempo. | ||
+ | <br/> | ||
+ | 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. | ||
− | == Gestión | + | - 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 == | == 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 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 [http://karma-runner.github.io/1.0/dev/git-commit-msg.html 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> | ||
Línea 40: | Línea 164: | ||
== Gestión de incidencias == | == 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 |
Revisión actual del 16:31 21 dic 2017
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