Wiki de EGC - Contribuciones del usuario [es]

Gestión del programa - 17 18 - G2

2017-12-04T10:57:51Z

Josgomrod3: /* Formato para detallar Api */

== 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)

== 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 ==
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 [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>

== 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

Gestión del programa - 17 18 - G2

2017-12-04T10:16:04Z

Josgomrod3: /* 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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 [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>

== 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

Gestión del programa - 17 18 - G2

2017-12-04T10:11:35Z

Josgomrod3: /* Miembros del equipo */

== 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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 [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>

== 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/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-04T10:09:22Z

Josgomrod3: /* Miembros del equipo */

== 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== Miembros del equipo ==
Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software
 
Jose Manuel Luque Mendoza - Ingeniero Software
 
Samuel Gonzalez Zuluaga - Ingeniero Software, Gestor de repositorio.
 
Felix Blanco Castaño - 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.

- 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 [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>

== 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/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T17:34:40Z

Josgomrod3: /* 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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, 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 [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>

== 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/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T17:32:39Z

Josgomrod3:

== 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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, 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 [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>

== 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.
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T17:07:33Z

Josgomrod3: /* Miembros del equipo */

== 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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, 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 [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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:58:11Z

Josgomrod3: /* Api */

== 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)

== Formato para detallar Api ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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 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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:56:55Z

Josgomrod3: /* Api */

== 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 ==

URL base: http://localhost/splc/wp-json/wp/v2/pages/XXX/

Descipción: donde XXX corresponde al id de la página que quieres obtener.

== 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 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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:47:51Z

Josgomrod3:

== 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 ==

URL: http://localhost/splc/wp-json/wp/v2/pages/XXX/, donde XXX corresponde al id de la página que quieres obtener.

== 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 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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:27:30Z

Josgomrod3:

== 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 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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:24:02Z

Josgomrod3:

== 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 [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>

== 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>"

== Integración continua ==

== Diario del grupo ==

== Gestión de ramas ==
[https://ibb.co/cTRMKb]

Gestión del programa - 17 18 - G2

2017-12-03T16:06:01Z

Josgomrod3:

Gestión del programa - 17 18 - G2

2017-11-22T16:01:25Z

Josgomrod3:

Gestión del programa - 17 18 - G2

2017-11-22T15:15:38Z

Josgomrod3: /* Consideraciones */

Gestión del programa - 17 18 - G2

2017-11-22T15:15:12Z

Josgomrod3: /* Consideraciones */

Gestión del programa - 17 18 - G2

2017-11-22T15:11:53Z

Josgomrod3: /* Miembros del equipo */