Wiki de EGC - Contribuciones del usuario [es]

Gestión del programa - 17 18 - G2

2017-12-02T17:25:59Z

Samgonzul: /* 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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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-02T17:19:42Z

Samgonzul:

Gestión del programa - 17 18 - G2

2017-12-02T17:06:36Z

Samgonzul: /* Miembros del equipo */

Gestión del programa - 17 18

2017-12-02T17:05:36Z

Samgonzul: /* Datos básicos del proyecto */

[[Página_Principal]] -> [[2017/2018]] -> [[Trabajo - 17/18]] -> [[Lista de proyectos a realizar 17-18 ]]
== Datos básicos del proyecto ==

* Repositorio donde puede encontrarse el código: https://github.com/laramorilla/project-program
* Sitio web en donde se puede ver una instancia del proyecto funcionando: http://congreso.us.es/splc2017/program-at-a-glance/program-full/

== Posibles evoluciones ==

Gestión del programa - 17 18 - G2

2017-12-02T17:05:14Z

Samgonzul: /* Consideraciones */

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

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T17:04:02Z

Samgonzul:

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T17:03:03Z

Samgonzul:

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

=== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T17:00:24Z

Samgonzul: /* Gestión de incidencias */

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T16:59:02Z

Samgonzul: /* Gestión de incidencias */

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T16:58:44Z

Samgonzul: /* Gestión de incidencias */

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

== 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 prouduce
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 del programa - 17 18 - G2

2017-12-02T16:58:25Z

Samgonzul: /* Gestión de incidencias */

== 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/jagalindo/program-manager-wpp
 
 
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 -> 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.

== Entorno de desarrollo ==

== Gestión del código ==

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

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

== Integración continua ==

== Diario del grupo ==