-
Notifications
You must be signed in to change notification settings - Fork 0
Documento del Proyecto
Este proyecto ha consistido en el desarrollo de una API con todo el programa de las jornadas InnoSoft. Además se ha implementado el registro de usuarios y staff de forma que queden registrados en la plataforma y puedan acceder a la misma; las ponencias y ponentes, de forma que se obtenga toda la información que se pueda necesitar de los mismos; y la posibilidad de que los usuarios se puedan apuntar a las ponencias desde el sistema. Además, para hacer más llevadero el tema de la asistencia se ha implementado un sistema de validación de la asistencia mediante código QR.
(debe dejar enlaces a evidencias que permitan de una forma sencilla analizar estos indicadores, con gráficas y/o con enlaces)
| Miembro del equipo | Horas | Commits | LoC | Test | Issues | Incremento |
|---|---|---|---|---|---|---|
| Cote Medina, Carlos | HH | XX | YY | ZZ | II | Descripción breve |
| Pantión Loza, Moisés | HH | XX | YY | ZZ | II | Descripción breve |
| Pantoja Bas, Miquel Ángel | HH | XX | YY | ZZ | II | Descripción breve |
| Barba Roque, Enrique | HH | XX | YY | ZZ | II | Descripción breve |
| Sánchez Rodríguez, Manuel | HH | XX | YY | ZZ | II | Descripción breve |
| Gracia Barroso, Adrián | HH | XX | YY | ZZ | II | Descripción breve |
| TOTAL | tHH | tXX | tYY | tZZ | tII | Descripción breve |
La tabla contiene la información de cada miembro del proyecto y el total de la siguiente forma:
- Commits: solo contar los commits hechos por miembros del equipo, no lo commits previos
- LoC (líneas de código): solo contar las líneas producidas por el equipo y no las que ya existían o las que se producen al incluir código de terceros
- Test: solo contar los test realizados por el equipo nuevos
- Issues: solo contar las issues gestionadas dentro del proyecto y que hayan sido gestionadas por el equipo
- Incremento: principal incremento funcional del que se ha hecho cargo el miembro del proyecto
Aunque no nos hemos integrado con ningún equipo como tal, si que nos hemos puesto a colaborar con ciertos miembros del staff de las jornadas InnoSoft. Además, tenemos la suerte de que contamos con dos miembros del staff en nuestro propio equipo:
- Comité de logística (Barba Roque, Enrique): coordinador del comité de logística.
- Comité de programa (Cote Medina, Carlos): integrante del comité de programa.
Esta organización ha sido bastante importante a la hora de obtener información sobre el funcionamiento interno de las jornadas, ya que de esta forma hemos podido tener de primera mano (especialmente con nuestros dos miembros que pertenecen a las jornadas) información relevante que nos ha permitido desarrollar la idea principal de forma rápida y sabiendo lo que se podía hacer y lo que no para posteriormente, proceder con el desarrollo.
Se explicará el sistema desarrollado desde un punto de vista funcional y arquitectónico. Se hará una descripción tanto funcional como técnica de sus componentes y su relación con el resto de subsistemas. Habrá una sección que enumere explícitamente cuáles son los cambios que se han desarrollado para el proyecto.
Para este proyecto, dado que hemos realizado una API, hemos desarrollado la parte programática, el back-end, y hemos omitido las vistas ya que no entraba en nuestro alcance. Además hemos creído que puede ser conveniente para que el año que viene un equipo pueda seguir desarrollando a partir de este proyecto para convertir la API en un sistema web completo.
Dicho esto, para explicar el funcionamiento del proyecto se va a dividir la explicación en las tres aplicaciones que tiene:
Registro: La aplicación de registro (o funcionalidad/feature de registro) es tal y lo que indica su nombre, un registro como cualquier otro. Sin embargo hemos decidido priorizar el UVUS antes que el nombre de usuario, de forma que al ser único pueda servir como ID.
Además, un usuario se puede registrar tanto como usuario normal como moderador/parte del staff de las jornadas. Esto es así porque hemos pensado que esta API no solo puede ser útil de cara a usuarios externos sino que a los mismos miembros de las jornadas InnoSoft les puede servir, tanto para publicar información como para llevar registro de asistencia.
Por lo tanto, un usuario que quiera hacer uso del sistema se registraría mediante un administrador del sistema, ya que solo pueden registrarse personas matriculadas en la asignatura de EGC. Dicho administrador sería el encargado de registrar al usuario en el sistema mediante llamadas a la API con sus correspondientes datos. De esta forma ya podría acceder a la función de inscripción a ponencias, por lo que este registro sería el primer paso.
Programa: La aplicación de programa es la primera que se pensó a la hora de desarrollar el proyecto, ya que trata el acceso a la información de las ponencias y los ponentes que las realizan, siendo este el principal motivo de desarrollo de la API. Posteriormente, debido a la simpleza del proyecto, decidimos ampliarlo con las otras aplicaciones que vienen descritas hasta convertirse en lo que es hoy.
Como he dicho, la función de esta aplicación no es otra sino la de poder obtener toda la información de las ponencias (titulo, horario, ponente, etc) así como de los ponentes que las realizan, todo esto pensado para que se pueda usar en otros servicios web de eventos.
Esto tiene dos funcionalidades posibles: o bien como usuario quiero ver información de las ponencias y por lo tanto, mediante llamadas a la API consigo dicha información (actualmente en formato JSON debido a la falta de una vista); o bien consumo dicha información mediante la integración de la API en mi servicio web de forma que presente una vista para los usuarios y añada de esta forma una funcionalidad a mi aplicación.
Inscripción: Por último, tenemos la aplicación de inscripción. Esta aplicación relaciona las otras dos y ofrece una herramienta que creemos que será de gran ayuda para el staff de las jornadas: verificación de asistencia mediante QR.
Primero, una vez hay un usuario y una ponencia registradas, dicho usuario puede inscribirse a esa ponencia para dejar por escrito que piensa (o quiere) asistir a dicha charla, pero como hemos visto este año, el recuento de la asistencia (especialmente en tiempos de pandemia donde las jornadas han de realizarse telemáticamente) tiene dos problemas:
- Es un proceso bastante tedioso y que hay que realizar a mano
- Es algo complicado ya que no siempre se puede saber con certeza si alguien de verdad está pendiente o si tiene la charla de fondo mientras hace cualquier otra cosa.
Respecto al segundo problema no podemos hacer gran cosa, pero para intentar resolver el primero hemos pensado en un sistema de verificación de asistencia mediante QR. Funciona de la siguiente forma:
Una vez el usuario se haya inscrito en la ponencia, el día de la ponencia se generará un código QR al que solo tendrá acceso el moderador (persona encargada de regular la asistencia, ya sea tanto telemática como presencialmente). Será entonces cuando el usuario que se ha inscrito deberá escanear el código QR para verificar su asistencia a la charla, quedando un registro en el sistema y por lo tanto, permitiendo llevar un control de forma más sencilla. Además se han añadido las posibilidades tanto de mostrar las asistencias a las que ha asistido un usuario como la de mostrar todos los asistentes que ha tenido una ponencia, facilitando así el recuento.
Su uso sería el siguiente entonces: un usuario ya registrado en el sistema se inscribe a una ponencia y el día de dicha ponencia, escanea el código QR que le facilitará el moderador de la ponencia, confirmando así su asistencia.
- Un usuario (antes de estar registrado) quiere acceder a información de las ponencias para ver a cuál le interesa asistir, por lo que accede a dicha información mediante:
- Peticiones a la API
- Webs externas que hayan hecho uso de la API y muestren dicha información
- Una vez haya consumido dicha información y ya sepa las charlas a las que desea asistir, se pone en contacto con el administrador (si es que no se registran a todos los matriculados de forma automática) para que realice el registro en el sistema.
- Después de haberse registrado puede acceder a la lista de ponencias para proceder a inscribirse a las que desee.
- Por ultimo, el día de la ponencia ha de asistir a la charla y verificar su asistencia mediante el escaneo del código QR que le facilitara el moderador de la ponencia. En caso de que no se escanee el código, no se verificará la asistencia y por lo tanto será como si no hubiese asistido.
- Finalmente, un miembro del staff de las jornadas puede acceder a la lista de asistentes de una ponencia o bien listar las ponencias a las que ha asistido un usuario para realizar recuento.
TODO: hasta ahora van 970 palabras
- Debe dar una visión general del proceso que ha seguido enlazándolo con las herramientas que ha utilizado. Ponga un ejemplo de un cambio que se proponga al sistema y cómo abordaría todo el ciclo hasta tener ese cambio en producción.
En primer lugar, hemos comenzado con un Brain Storming para plantear una idea de proyecto a desarrollar, con eso obtuvimos la idea de desarrollar un sistema de conteo de asistencias, así como de registro de ponentes y ponencias. A modo de base para el desarrollo decidimos dividir todo el trabajo en 4 aplicaciones independientes entre si, estas son: Asistencia: en esta aplicación se permitía a los alumnos inscritos a las diferentes ponencias generar un código QR a modo de identificación para su usuario para esa ponencia. Por otro lado, permitía a un moderador escanear los códigos QR anteriormente mencionados que muestren los alumnos al entrar a la ponencia, y así registrar su asistencia en la base de datos. Autenticación: en esta aplicación se permitía el registro por parte de un administrador, y el inicio de sesión de los usuarios, haciendo uso de su UVUS como identificador único para su usuario. Inscripción: en esta aplicación se permitía a los usuarios registrarse en una ponencia con su usuario, de manera que en la base de datos quedaban relacionados el usuario con la ponencia. Programa: en esta aplicación se registraban las ponencias que se iban a realizar, incluyendo su horario, fecha y una breve descripción de su contenido, y además de esto su ponente, con algunos datos básicos para poder identificar a la persona. Además, durante el Brain Storming inicial se decidió que el sistema sería una API con función de generación de imágenes QR para la confirmación de la asistencia. También, debido a la necesidad de un tablero cómodo y sencillo de usar donde recopilar las tareas que debía abordar cada integrante del grupo, hemos decidido usar el tablero de la pestaña projects de GitHub, en ella hemos dividido el proyecto en las tareas que hemos visto convenientes y estas han sido asignadas de manera aleatoria a los integrantes del grupo, este tablero posee varias columnas indicando el estado de la tarea, los estados disponibles son los siguientes: To do: este estado corresponde a las tareas que pueden o no haber sido asignadas aún y que aún no han sido comenzadas por nadie. In progress: este estado corresponde a las tareas que, tras haber sido asignadas, han comenzado su desarrollo pero aún no han sido finalizadas. Stuck: este estado corresponde a las tareas que han sido comenzadas y tras un periodo de desarrollo sin ningún tipo de avance destacable ha sido anotado como atascado y espera la contribución de otro miembro del grupo para poder continuar. To check: este estado corresponde a las tareas que han sido finalizadas y comprobadas por el correspondiente desarrollador, pero que aún debe ser comprobada por segunda vez por una segunda persona para ser validada. Done: este estado corresponde a las tareas que han sido finalizadas y validadas por otro integrante del proyecto. El tablero anteriormente mencionado debe ser actualizado a medida que se desarrolla el proyecto, así como modificado según vayan surgiendo cambios en el diseño del proyecto. Será responsabilidad del grupo al completo mantener el tablero actualizado a su propio desarrollo y a los cambios en el diseño que surjan en las reuniones. Más tarde, tras empezar con los primeros commits y pensar con más detenimiento el sistema a seguir, se decidió eliminar una de las cuatro aplicaciones y redefinir el sistema completo, con ello quedaron las siguientes 3 aplicaciones: Participación: las anteriores aplicaciones “Asistencia” e “Inscripción” quedan fusionadas en esta aplicación ya que estaban altamente relacionadas la una con la otra. Tras realizar esta fusión queda que la aplicación dispone de las funcionalidades necesarias para que un usuario se inscriba en una ponencia, la funcionalidad respectiva a la generación de códigos QR para los alumnos asistentes a las diferentes ponencias, y la funcionalidad correspondiente al escaneo por parte de un moderador de los anteriormente mencionados códigos QR para la confirmación de su asistencia. Programa: esta aplicación no varía con respecto a su anterior versión. Registro: esta aplicación es correspondiente a la aplicación “Autenticación”, posee exactamente las mismas funcionalidades que fueron mencionadas antes pero se decidió renombrarla debido a que su anterior nombre generaba confusión. En un principio se comenzó a realizar los documentos necesarios para la creación del proyecto en la plataforma Google Drive, en la que poseíamos una carpeta compartida con todos los miembros del grupo de manera que fuera accesible para todos y se pudiera trabajar en el documento de manera simultánea, pero más tarde se decidió mover los documentos a la pestaña wiki de nuestro repositorio de GitHub. Debido a la necesidad de conteo de palabras para saber si la cantidad de texto era adecuada para cada uno de los apartados y por las dificultades existentes en esta plataforma para la redacción simultanea por parte de dos miembros de un documento, se decidió usar la herramienta Word para desarrollar el apartado que se desea modificar y una vez se deje de trabajar se añadirá a la wiki todo el contenido desarrollado de una vez para no interactuar con las adiciones a la página de los otros miembros.
debe explicar cuál es el entorno de desarrollo que ha usado, cuáles son las versiones usadas y qué pasos hay que seguir para instalar tanto su sistema como los subsistemas relacionados para hacer funcionar el sistema al completo. Si se han usado distintos entornos de desarrollo por parte de distintos miembros del grupo, también debe referenciarlo aquí.
se describirá el proceso de gestión de incidencias que ha seguido en el proyecto. También deberá enlazar partes de su proyectos donde se evidencie que ha seguido ese proceso.
La gestión de incidencias debería contener explícitamente dos apartados. Uno de cómo se han gestionado la incidencias internas y otro el cómo se han gestionado y se ofrece protocolo para gestionar las incidencias externas tanto las recibidas como las que se reporten a otros subsistemas. Las internas son aquellas incidencias relacionadas con el propio equipo, las externas son aquellas que se gestionan con el resto de equipos del proyecto.
Cuando una incidencia esté relacionada con un commit, señalar el commit dentro de la propia incidencia y viceversa.
Céntrese en los aspectos particulares de su proyecto en concreto:
- Guía de cómo y cuándo crear incidencias: dé enlaces concretos a ejemplos que se puedan ver en su repositorio de cómo ha seguido esas guías.
- Plantilla(s) que ha usado para la gestión de incidencias
- Elementos de las incidencias: prioridad, estado, tipo, roles
En este apartado sería ideal que pudiera tener un ejemplo de una incidencia que haya gestionado y que haya dado lugar a un proceso de depuración y cómo, usando el proceso definido, pudo solventarla.
se explicarán los procesos, técnicas y herramientas para la gestión del código del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Guía de cómo y cuándo hacer commits: dé enlaces concretos a ejemplos que se puedan ver en su repositorio de cómo ha seguido esas guías.
- Usage model del repositorio: ¿cómo se gestiona el repositorio tanto del proyecto general como de su subproyecto?
Se explicarán los procesos, técnicas y herramientas para la gestión de la construcción e integración continua del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Proceso de integración continua que usa
- Herramientas que está usando para dar soporte a ese proceso
- Cuáles son los (al menos) 5 indicadores de calidad de los builds que ha utilizado para guiar su proceso. De detalles sobre este aspecto.
Se explicarán los procesos, técnicas y herramientas para la gestión de las liberaciones, despliegue y entregas del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Proceso definido para las liberaciones con un apartado explícito de cómo ha elegido la licencia de software para su proyecto
- Proceso definido para el despliegue
- Proceso definido para las entregas
- Política de nombrado e identificación de los entregables
se presentará un ejercicio con una propuesta concreta de cambio en la que a partir de un cambio que se requiera, se expliquen paso por paso (incluyendo comandos y uso de herramientas) lo que hay que hacer para realizar dicho cambio. Debe ser un ejercicio ilustrativo de todo el proceso de evolución y gestión de la configuración del proyecto.
se enunciarán algunas conclusiones y se presentará un apartado sobre las mejoras que se proponen para el futuro (curso siguiente) y que no han sido desarrolladas en el sistema que se entrega