Diferencia entre revisiones de «Gestión del programa - 17 18 - G2»

Revisión actual del 16:31 21 dic 2017

Contenido

1 Objetivo del subsistema
2 Consideraciones
3 Tecnologías Usadas
4 Formato para detallar 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 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:  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

@@ Línea 11: / Línea 11: @@
 Repositorio donde puede encontrarse el código:
 <br/>
-https://github.com/jagalindo/program-manager-wpp
+https://github.com/laramorilla/project-program
 <br/>
 <br/>
@@ Línea 21: / Línea 21: @@
   '''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''':  Ninguno
-  '''Bibliotecas''': <Listado de bibliotecas usadas en el desarrollo.>
+  '''Bibliotecas''': Ninguna
-  '''Necesita Base de datos''': Sí (todavía no definida)
+  '''Necesita Base de datos''': Sí, MySQL
-== Api ==
+== Formato para detallar Api ==
-  Consultar los datos del programa
+''' 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 ==
 Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software
 <br/>
-Jose Manuel Luque Mendoza Ingeniero Software
+Jose Manuel Luque Mendoza - Ingeniero Software, Gestor de tareas.
 <br/>
-Samuel Gonzalez Zuluaga Ingeniero Software
+Samuel Gonzalez Zuluaga - Ingeniero Software, Gestor de código.
 <br/>
-Felix Blanco Castaño Ingeniero Software
+Felix Blanco Castaño - Ingeniero Software, Gestor de tiempo.
 <br/>
-Jose Manuel Lara Morilla Ingeniero Software
+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.
@@ Línea 50: / Línea 123: @@
 - 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 [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 61: / Línea 164: @@
 == 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:'''
-== Integración continua ==
+   # 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 ==
-== Diario del grupo ==
+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