Revisión del 20:58 28 nov 2017

Miembros y contacto

• Pablo Tinoco Castillo, ptinococastillo@gmail.com Coordinador
• Francisco Fernández Angulo
• Jesús Martos Alé
• Miguel Medrano Gil
• Gonzalo Trabado García

Especificaciones

Objetivo del subsistema

• Gestionar la creación de una votación
• Gestionar la edición de una votación
• Gestionar el borrado de una votación

Consideraciones

• Repositorio del proyecto: https://github.com/martos93/EGC1718
• Página Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/98
• Dependencias con otros módulos: Recibimos datos de "Autenticación" y "Censo", enviamos datos a "Cabina de votaciones"

Tecnología usada

Subsistema: Administración de votaciones
Lenguaje/Herramienta: PHP -> PHPStorm
Sistema de gestión de bibliotecas: ¿?
Bibliotecas: 
   Larabel framework: versión 5.5
Necesita Base de datos: Sí (Ninguna empleada actualmente, a la espera de directrices)

Estructura de datos

Haremos uso de la tablas votación, pregunta y respuesta:

   Votación:
       - id: (int) identificador de la votación [pk, autoincrementable]
       - id_censo: (int) identificador del censo [fk, not null]
       - id_grupo: (int) identificador del grupo que puede votar en la votación [fk, not null]
       - titulo: (string/varchar) titulo de la votación a crear [blank, not null]
       - descripcion: (string/varchar) descripción de los objetivos de la votación [blank, not null]
       - fecha_ini: (datetime) fecha de inicio de la votación [not null, default=fecha_actual]
       - fecha_fin: (datetime) fecha de fin de la votación[not null]
   Pregunta:
       - id: (int) identificador de la pregunta [pk, autoincrementable]
       - id_votacion: (int) identificador de la votación a la que pertenece [fk, not null]
       - texto_pregunta: (string/varchar) texto de la pregunta que se realiza [blank, not null]
       - tipo_pregunta: (string/varchar ?) parametro para establecer el tipo de pregunta (Abierta, cerrada) [blank, not null]
       - id_dependencia: (int) identificador para definir dependencias entre preguntas [fk]
   Respuesta:
       - id: (int) identificador de la respuesta [pk, autoincrementable]
       - id_pregunta: (int) identificador de la pregunta [fk, not null]
       - id_pregunta: (int) identificador de la pregunta [fk, not null]
       - texto_pregunta: (string/varchar) texto de la respuesta [blank, not null]
       - seleccionada: (boolean) parámetro para establecer la selección de la respuesta

Esta sería la estructura de las tablas sobre las que trabajaríamos, una votación tendrá varias preguntas que podrán ser abiertas o cerradas, y estas a su vez podrán depender de otras preguntas. Las preguntas podrán tener una o más respuestas.

API

Las funcionalidades aquí descritas y especificadas no son finales. Debido a la diversidad de funcionalidades y necesidades de los otros grupos, éstas pueden variar a lo largo del desarrollo (sea debido al despliege, conflictos, etc).

Dependencias

En primer lugar estableceremos cuales van a ser las dependencias de nuestro módulo con otros.

Por una parte, necesitaremos información a cerca de si el usuario tiene los permisos necesarios para crear, editar o borrar una votación. Obtendremos esta información recibiendo los datos pertinentes del módulo de "Autenticación", para que a la hora de crear una votación se le asignen los permisos con los que se podrá crear.

Por otro lado, necesitamos saber qué usuarios van a poder votar en dicha votación. Para ello necesitaremos obtener esta información recibiendo los datos necesarios del módulo de "Censo", para que a la hora de crear la votación también podamos asignar al grupo de usuarios que podrán votar.

Para terminar, nuestro módulo deberá poder ofrecer la información completa de la votación al módulo de "Cabina de votación" para que se lleve a cabo. Para ello, ofreceremos una API que procedemos a definir.

Obtención de una votación

Se hace una petición GET con los parámetros siguientes y se devolverá un JSON con la siguiente información.

URL:

   http://egc-votacion1718.es/api/get/votacion.json

Parámetros:

   * id: Identificador de la votación.

Ejemplo:

   GET http://egc-votacion1718.es/api/get/votacion.json?id=1

Formato JSON:

 {
     "votacion": {
     "id": "1",
     "id_censo": "288",
     "id_grupo": "31",
     "titulo": "Votación sobre consolas",
     "descripción": "En esta votación comprobaremos si hay mas gamers de PC o consolas",
     "fecha_ini": "31/07/2017 07:07",
     "fecha_fin": "31/08/2017 07:07"
   }
 }

Creación de una votación

Se hace una petición POST (a través del formulario descrito en su correspondiente vista) con los parámetros siguientes y se devolverá un JSON con la siguiente información.

URL:

     http://egc-votacion1718.es/api/create

Parámetros:

       * id_censo: identificador del censo
       * id_grupo: identificador del grupo que puede votar en la votación
       * titulo: titulo de la votación a crear
       * descripcion: descripción de los objetivos de la votación
       * fecha_ini: fecha de inicio de la votación
       * fecha_fin: fecha de fin de la votación

Ejemplo:

   POST http://egc-votacion1718.es/api/create?id_censo=1&id_grupo=2&titulo=Prueba&descripcion=Descripcion&fecha_ini=10/10/17&fecha_fin=11/10/17

Formato JSON:

 {
     "votacion": {
     "id": "1",
     "id_censo": "288",
     "id_grupo": "31",
     "titulo": "Votación sobre consolas",
     "descripción": "En esta votación comprobaremos si hay mas gamers de PC o consolas",
     "fecha_ini": "31/07/2017 07:07",
     "fecha_fin": "31/08/2017 07:07"
   }
 }

Edición de una votación

Se hace una petición POST (a través del formulario descrito en su correspondiente vista) con los parámetros siguientes y se devolverá un JSON con la siguiente información.

URL:

     http://egc-votacion1718.es/api/post/votacion.json

Parámetros:

       * id: identificador de la votación
       * id_censo: identificador del censo
       * id_grupo: identificador del grupo que puede votar en la votación
       * titulo: titulo de la votación a crear
       * descripcion: descripción de los objetivos de la votación
       * fecha_ini: fecha de inicio de la votación
       * fecha_fin: fecha de fin de la votación

Aquellos parámetros que no se introduzcan no se modificarán.

Ejemplo:

   POST http://egc-votacion1718.es/api/post/votacion.json?id=1&titulo=Titulo_modificado

Formato JSON:

 {
   "exito": true,
   "mensaje": "Editado con éxito",
  "votacion": {
     "id": "1",
     "id_censo": "288",
     "id_grupo": "31",
     "titulo": "Votación sobre consolas",
     "descripción": "En esta votación comprobaremos si hay mas gamers de PC o consolas",
     "fecha_ini": "31/07/2017 07:07",
     "fecha_fin": "31/08/2017 07:07"
   }
 }

Eliminación de una votación

Se hace una petición DELETE (a través del formulario descrito en su correspondiente vista) con los parámetros siguientes y se devolverá un JSON con la siguiente información.

URL:

   http://egc-votacion1718.es/api/delete/votacion.json

Parámetros:

   * id: Identificador de la votación a eliminar.

Ejemplo:

   DELETE http://egc-votacion1718.es/api/delete/result.json?id=1

Formato JSON:

 {
   "exito": true,
   "mensaje": "Eliminado con éxito"
 }

Gestión

Gestión de la comunicación

Se realizará la comunicación mediante la aplicación "Telegram", creando un grupo en el que se encuentran todos los miembros del equipo. Las reuniones no presenciales serán gestionadas telematicamente con "Skype".

Gestión del trabajo

La gestión del trabajo, la creación de tareas y la asignación de las mismas se harán mediante la plataforma "Trello". Se crearán los siguientes tableros:

  * Lista de tareas: Se añadirán las tareas que se vayan identificando durante el desarrollo del trabajo.
  * En proceso: Se añadirán las tareas a este tablero una vez se asignen y se empiecen a trabajar.
  * En revisión: Se añadirán las tareas finalizadas a falta de una revisión por el resto del equipo.
  * Hecho: Se añadirán las tareas terminadas una vez revisadas.
  * Q&A: Tablero para preguntas y respuestas.

Gestión del código

Gestionaremos el código a desarrollar mediante la plataforma "GitHub".

Nuestra rama master contendrá la última versión estable, y de ella sacaremos una rama para cada funcionalidad del módulo que implementemos (Editar,Crear,Borrar votación). Una vez finalizadas las pruebas de cada funcionalidad, se procederá a hacer un merge de cada rama con la rama master.

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

Gestionaremos las incidencias que vayan apareciendo durante el trabajo con la herramienta propia de GitHub.

Crearemos en primer lugar un Milestone en GitHub por cada Milestone de la asignatura para saber el plazo que tenemos para resolver la incidencia y a ellos asignaremos las incidencias (Según proceda). Además, crearemos un proyecto "Administración de votaciones" al que asignar dichas incidencias. Usaremos las labels por defecto de GitHub, y crearemos nuevas si fuese necesario.

Plan de actuación

Las incidencias se tratarán con la siguiente nomenclatura:

Título: <breve título>
Prioridad: a seleccionar: 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 de la incidencia>
   La descripción puede incluir imagenes o la salida emitida por la incidencia.
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

El plan de actuación cuando se encuentre una incidencia será el siguiente:

• Se identificará cual es la incidencia.
• Añadiremos dicha incidencia con la nomenclatura descrita en github al proyecto, milestone y label que corresponda.
• En caso de no tener claro quien podría resolver la incidencia, se notificará al coordinador del grupo via "Telegram" para que la revise y asigne según su criterio; además de al resto del equipo por "Telegram".
• Una vez resuelta (Antes del plazo del Milestone asignado) se cerrará en "GitHub", previa validación del jefe de proyecto y el creador de la issue. Se notificará por "Telegram" al equipo.