Diferencia entre revisiones de «Cabina de votaciones - 17 18»

De Wiki de EGC
Saltar a: navegación, buscar
(Añadido un espaciado para mejorar la disposición del texto de las plantillas)
(→‎Ramas: Añadida la descripción del sistema de trabajos con ramas introduciendo Pull Requests y explicando el proceso de confirmación de pull request)
 
(No se muestran 12 ediciones intermedias del mismo usuario)
Línea 1: Línea 1:
 
'''
 
'''
−
== Resumen del trabajo ==
+
== Miembros del grupo ==
 
'''
 
'''
−
Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.
+
- Ignacio José Alés López, coordinador del grupo.<br/>
 +
- Juan Carlos López Muñoz, gestor de incidencias.<br/>
 +
- Jorge Gordo Aguilar, programador.<br/>
 +
- Antonio Rodríguez Artacho, programador.<br/>
 +
- Javier Román Bayar, programador.<br/>
  
 
'''
 
'''
−
== Objetivo del subsistema ==
+
 
 +
== Resumen del trabajo ==
 
'''
 
'''
 
Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.
 
Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.
−
 
−
'''Tecnologías que se usarán''':
 
−
Subsistema: Cabina de votación
 
−
Lenguaje/Herramienta: Node.js 9.2 (Javascript v8)
 
−
Bibliotecas:
 
−
- restify: 6.3.4
 
−
- rest: 2.0.0
 
−
- lodash: 4.17.4
 
−
- async: 2.6.0
 
−
Sistema de gestión de bibliotecas: npm
 
−
Base de datos: No (Aunque es necesaria alguna forma de verificar los votos a partir del usuario encriptado).
 
  
 
'''
 
'''
−
== APIs y datos que se usarán y devolverán ==
+
== Modelo de uso del repositorio ==
 
'''
 
'''
 +
En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.
  
−
'''Estructura de un voto''':
+
Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (https://github.com/EGC-G2-Trabajo-1718/egc-cabinas) y en el otro se pondrá el código del programa (https://github.com/EGC-G2-Trabajo-1718/cabina-de-votacion).
−
 
 
−
id: (int) identificador del voto [pk, autoincrementable]
 
−
encrypted_user: (string) identificador del usuario que ha votado de forma encriptada, es única y es posible verificar el voto (voto anónimo) [unique, not null]
 
−
id_election: (int) identificador de la votación [fk, not null]
 
−
encrypted_answers: (string) es un string con el contenido de la votación cifrado.
 
−
 
 
−
'''Obtención de un voto''':
 
−
Tipo: GET
 
−
URL: http://egc-cabina.es/api/get/vote.json?id=x&id_election=y
 
−
Parámetros: id_vote: Identificador del voto (x)
 
−
            id_election: Identificador de la elección del voto (y)
 
−
Formato JSON Ejemplo: Obtención del voto 1
 
−
 
 
−
{
 
−
    "vote": {
 
−
        "id": "1",
 
−
        "encrypted_user": "xgs5fdy2",
 
−
        "id_election": "165",
 
−
        "encrypted_answers": "..."
 
−
    }
 
−
}
 
−
 
 
−
'''Consulta de votos''':
 
−
Tipo: GET
 
−
URL: http://egc-cabina.es/api/get/votes.json?encrypted_user=x&id_election=y
 
−
Parámetros: encrypted_user: (opcional) Identificador del usuario encriptado. (x)
 
−
            id_election (opcional) Identificador de la votación (y)
 
−
Formato JSON Ejemplo: Buscando la votación 165
 
−
 
 
−
{
 
−
    "votos": {
 
−
        "vote1": {
 
−
            "id": "1",
 
−
            "encrypted_user": "xgs5fdy2",
 
−
            "id_election": "165",
 
−
            "encrypted_anwers": "..."
 
−
        },
 
−
 
 
−
        "voto2": {
 
−
            "id": "2",
 
−
            "encrypted_user": "whedvsg3",
 
−
            "id_election": "165",
 
−
            "encrypted_anwers": "..."
 
−
        }
 
−
    }
 
−
}
 
−
 
 
−
'''Creación de voto''':
 
−
Tipo: POST
 
−
URL: http://egc-cabina.es/api/create/vote.json
 
−
Parámetros: id_user: (int) Identificador del usuario (sin encriptar)
 
−
            id_election: (int) Identificador de la votación
 
−
            answers: (list[string]) Lista con las respuestas de la votación de forma ordenada (en la posición 1 estará la respuesta a la pregunta 1 de la votación)
 
−
Formato JSON Ejemplo: Creando un voto por el usuario 23, la votación 34, el grupo de usuarios 13.
 
  
−
{
+
== Commits ==
−
    "result": true,
+
Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato:
−
    "vote": {
 
−
        "id": "1",
 
−
        "encrypted_user": "as5d8gr4",
 
−
        "id_election": "34",
 
−
        "id_group": "13",
 
−
        "encrypted_answers": "..."
 
−
    }
 
−
}
 
  
−
== Plantillas HTML ==
+
  <razón>:<título>
 +
  (<colaboradores>)
 +
  <cuerpo>
 +
  (IMPORTANTE
 +
  <detalles importantes>)
  
−
Se tiene pensado que el formato de la cabina de votación sea el siguiente:
+
Se describirán cada componente del formato ahora:<br/>
 +
- razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros). <br/>
 +
- título: Resumen, de menos de 20 palabras del commit. <br/>
 +
- colaboradores: Miembros del grupo que han ayudado en la realización del trabajo. <br/>
 +
- cuerpo: Explicación más en profundidad del contenido del commit. <br/>
 +
- IMPORTANTE: Sección donde se describe un detalle importante. <br/>
 +
- detalles importantes: Detalles a destacar para otros miembros del grupo. <br/>
  
−
Leyenda:
+
== Ramas ==
−
- <-- variable --> Esta sección será reemplazada por un texto que sea más cercano a lo especificado en el interior de la sección
+
La gestión de ramas será la siguiente:<br/>
−
- <% Comentario %> Comentario
+
- master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción. <br/>
−
- <hX> Un texto de alto tamaño
+
- dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción.<br/>
−
- <\hr/> Una barra horizontal u alguna otra forma de separación.
+
- <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa. <br/>
−
- <\p/> Un parrafo, preferible de una única linea
+
- <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).<br/>
−
- <\span/> Un parrafo de varias lineas
 
  
−
'''Votación de la pregunta X'''
+
El funcionamiento para pasar de una rama a otra será el siguiente.
 +
- miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.<br/>
 +
- funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta).<br/>
 +
- dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.<br/>
  
−
<hX><-- Nombre de la encuesta --></hX><br/>
+
Al implementarse el sistema de integración continua, se usarán Pull Requests para pasar de una rama a otra, como se ve en el apartado anterior. El Pull Request no podrá ser aceptado hasta que la integración continua indique que la nueva versión es compilable y aprueba los tests indicados. Una vez se obtenga una versión correcta, el jefe del proyecto (Ignacio José Alés López) eligirá o él mismo realizará una evaluación del código y hará comentarios pertinentes. Si se decide que el pull request es válido, se procederá a confirmar el merge de las ramas.
−
<\hr/><br/>
 
−
<\p><-- Descripción de la encuesta --><\/p><br/>
 
−
<\hr/><br/>
 
−
<\p>Pregunta <-- X --><\/p><br/>
 
−
<\span><-- Texto de la preguna X --><\/span><br/>
 
−
<% En el caso de que se trate de una lista de posibles opciones donde sólo se selecciona una %><br/>
 
−
    <select><br/>
 
−
        <option value="<-- Valor de la respuesta -->"><-- Texto de la respuesta --><br/>
 
−
    </select><br/>
 
−
<% En el caso de que se trate de una respuesta donde habrá que poner texto %><br/>
 
−
    <label...><-- Texto de la pregunta --></label><br/>
 
−
    <input value="<-- Valor de la pregunta -->" /><br/>
 
−
<% En el caso de existir una pregunta donde se requiera una selección y también un input de pregunta, mezclar las dos disposiciones anteriores %><br/>
 
−
<\hr/><br/>
 
−
<button <% Botón de siguiente pregunta %>>Siguiente pregunta</button><br/>
 
  
−
'''Final de la votación de la encuesta'''
+
== Incidencias ==
 +
Las incidencias realizadas a nuestro módulo deben seguir el siguiente formato:
 +
  Título: (descripción breve del error, debe ser reconocible entre otros posibles errores, por lo que mencionar acción, resultado incorrecto...)
 +
  Grupo: (grupo al que pertenece el creador de la incidencia o grupos a los que le influyen la incidencia)
 +
  Prioridad: (¿Es necesario tener la solución cuanto antes o es un pequeño detalle a arreglar?. Podrá tener los siguiente valores: Baja, Media, Alta)
 +
  Descripción: (Descripción textual del error, un resumen del problema o mejora).
 +
  (Si aplicable) Pasos para reproducir: (Lista de acciones que se debe realizar para que se produzca el error, cuanto más preciso mejor)
  
−
<hX><-- Nombre de la encuesta --></hX><br/>
+
Además, se asignará a un miembro del grupo para gestionar la incidencia, por parte del gestor de incidencias. Se asignará labels que mostrarán el estado de la incidencia y tendrá los siguiente valores:
−
<\hr/><br/>
+
- Estado: Puede ser Por iniciar, En progreso y Por revisar.
−
<\p><-- Descripción de la encuesta --><\/p><br/>
+
- Prioridad: Será asignada por el gestor de la incidencia, según sea necesario. Podrá ser Baja prioridad o Muy importante.
−
<\hr/><br/>
+
- Otros: Estos serán los labels creados por defecto en Github y serán asignados por el gestor de incidencias como sea necesario.
−
<\p>Gracias por responder a <-- Nombre de la encuesta --><\/p><br/>
 
−
<button>Finalizar</button> <% Con este botón, se enviaría a la cabina de votación el voto y los credenciales del usuario que lo ha creado %><br/>
 

Revisión actual del 19:52 15 dic 2017

Miembros del grupo

- Ignacio José Alés López, coordinador del grupo.
- Juan Carlos López Muñoz, gestor de incidencias.
- Jorge Gordo Aguilar, programador.
- Antonio Rodríguez Artacho, programador.
- Javier Román Bayar, programador.

Resumen del trabajo

Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.

Modelo de uso del repositorio

En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.

Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (https://github.com/EGC-G2-Trabajo-1718/egc-cabinas) y en el otro se pondrá el código del programa (https://github.com/EGC-G2-Trabajo-1718/cabina-de-votacion).

Commits

Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato: 

 <razón>:<título>
 (<colaboradores>)
 <cuerpo>
 (IMPORTANTE
 <detalles importantes>)

Se describirán cada componente del formato ahora:
- razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros).
- título: Resumen, de menos de 20 palabras del commit.
- colaboradores: Miembros del grupo que han ayudado en la realización del trabajo.
- cuerpo: Explicación más en profundidad del contenido del commit.
- IMPORTANTE: Sección donde se describe un detalle importante.
- detalles importantes: Detalles a destacar para otros miembros del grupo.

Ramas

La gestión de ramas será la siguiente:
- master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción.
- dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción.
- <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa.
- <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).

El funcionamiento para pasar de una rama a otra será el siguiente. - miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.
- funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta).
- dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.

Al implementarse el sistema de integración continua, se usarán Pull Requests para pasar de una rama a otra, como se ve en el apartado anterior. El Pull Request no podrá ser aceptado hasta que la integración continua indique que la nueva versión es compilable y aprueba los tests indicados. Una vez se obtenga una versión correcta, el jefe del proyecto (Ignacio José Alés López) eligirá o él mismo realizará una evaluación del código y hará comentarios pertinentes. Si se decide que el pull request es válido, se procederá a confirmar el merge de las ramas.

Incidencias

Las incidencias realizadas a nuestro módulo deben seguir el siguiente formato: 

 Título: (descripción breve del error, debe ser reconocible entre otros posibles errores, por lo que mencionar acción, resultado incorrecto...)
 Grupo: (grupo al que pertenece el creador de la incidencia o grupos a los que le influyen la incidencia)
 Prioridad: (¿Es necesario tener la solución cuanto antes o es un pequeño detalle a arreglar?. Podrá tener los siguiente valores: Baja, Media, Alta)
 Descripción: (Descripción textual del error, un resumen del problema o mejora).
 (Si aplicable) Pasos para reproducir: (Lista de acciones que se debe realizar para que se produzca el error, cuanto más preciso mejor)

Además, se asignará a un miembro del grupo para gestionar la incidencia, por parte del gestor de incidencias. Se asignará labels que mostrarán el estado de la incidencia y tendrá los siguiente valores: 

- Estado: Puede ser Por iniciar, En progreso y Por revisar.
- Prioridad: Será asignada por el gestor de la incidencia, según sea necesario. Podrá ser Baja prioridad o Muy importante.
- Otros: Estos serán los labels creados por defecto en Github y serán asignados por el gestor de incidencias como sea necesario.
Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Cabina_de_votaciones_-_17_18&oldid=7034»