-
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 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.
- Inscripcion: 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 registra????
- 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: falta revisar el tema de registros, hasta ahora van 915 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 empezado 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. En primer lugar decidimos dividir todo el trabajo en 4 aplicaciones independientes entre si, estas son: asistencia, autenticación, inscripción y programa. 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, programa y registro. Además, durante el Brain Storming inicial se decidió que el sistema sería una API con función de generación de imagenes QR para la confirmación de la asistencia.
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