El proyecto en equipo se basa en UVLHub, la aplicación con la que hemos estado trabajando en las clases de prácticas. Cada equipo hará un fork de UVLHub para adaptar la aplicación a un dominio diferente, y además tendrá que realizar una serie de modificaciones para dar respuesta a un conjunto de issues, simulando la dinámica de trabajo habitual en la industria y siguiendo las buenas prácticas estudiadas en la asignatura.
Preguntas frecuentes
¿Es obligatorio participar en el proyecto?
No. La participación es voluntaria.
¿Cómo se forman los equipos?
Los equipos, en principio formados por 6 personas, se establecerán en la clase de teoría del 14 de octubre en base a unas directrices que establecerá el profesorado. Si alguna persona no puede acudir justificadamente a esa clase y comunica al coordinador de la asignatura hasta el 21 de octubre su intención de participar en el proyecto, será asignado a un equipo por el profesorado.
¿Cómo se asignan los tutores a los equipos?
Cada equipo tendrá un tutor, que será un profesor de la asignatura. Los tutores los asigna el profesorado de la asignatura. Se publicará un listado tras la creación de los equipos.
¿Qué cambios hay que hacer a UVLHub?
Los cambios están organizados en "Work Items" (WIs). Por un lado, hay dos cambios que tienen que hacer todos los equipos:
- WI de newdataset: para crear un nuevo hub que gestione otro tipo de datos distinto a UVL. Básicamente se trata de que el fork de cada equipo adapte el hub a un dominio diferente. Cada equipo hará una propuesta que tendrá que ser valorada y aceptada por su tutor.
- WI de fakenodo: para no conectarse con Zenodo, se simulará la llamada a una API ficticia. Es importante entender que NO es necesario hacer una réplica de Zenodo.
Además de los dos anteriores, se le asignarán tantos WIs como integrantes tenga el equipo. Estos WIs se basan en las issues que están publicadas en el repositorio, y están clasificados por su nivel de dificultad estimada (H = High; M = Medium; L= Low). Por tanto, además de los dos WIs comunes, se asignarán a cada equipo 2 WIs H, 2 WIs M y 2 WIs L.
Si el equipo tiene menos componentes, se irán eliminando de más simples a más complejos. Por ejemplo, si termino entregando el proyecto con solo 4 componentes en el equipo, tendré que entregar 2 WIs H y 2 WIs M, además de los 2 comunes; si fueran 5 componentes en el equipo, 2 WIs H, 2 WIs M y 1 WI L, además de los 2 comunes.
La dificultad de un WI puede aumentar o disminuir según cómo se aborde. Cualquier cambio en la dificultad asignada a un WI debe ser aprobado por el tutor.
Se pueden hacer otras sugerencias de cambio, pero deberán estar bien justificadas y aprobadas por su tutor.
¿Qué se va a valorar del proyecto?
El trabajo realizado por los equipos debe seguir las buenas prácticas de gestión del código, gestión de incidencias, CI/CD, pruebas automatizadas y entornos aislados que se están estudiando en la asignatura.
Es evidente que el profesorado valorará también la calidad del código desarrollado, especialmente teniendo en cuenta si el alumnado comprende el código que entrega, pero será incluso más importante para la calificación cómo se ha organizado y coordinado el equipo para realizar ese desarrollo.
Por tanto, las decisiones de los equipos deben ser trazables, con evidencias que queden registradas bien en el repositorio o herramientas del equipo, que deben ser accesibles para el profesorado, o bien en los propios documentos del equipo (acta fundacional y diario de equipo, que se describen más adelante).
Equipos y proyectos
- Listado de proyectos y personas inscritas (pendiente hasta el 14 de octubre).
- Listado de WIs asignados a cada equipo (pendiente hasta la creación de los equipos).
Documentos de los equipos
- Acta fundacional: (pendiente de publicar la plantilla)
- Diario del equipo: (pendiente de publicar la plantilla)
Fechas Importantes
- 14 de octubre: clase de teoría para realizar la formación de los equipos. Si alguna persona no puede asistir a esa clase justificadamente, podrá comunicar su intención de participar en el proyecto hasta el 21 de octubre.
- 9 de noviembre: entrega y valoración del acta fundacional.
- 23 de noviembre: seguimiento de la gestión del código fuente e incidencias.
- 30 de noviembre: seguimiento de la automatización de pruebas y workflows CI/CD.
- 14 y 16 de diciembre: defensa y revisión de los proyectos. Se publicará un calendario de pruebas por equipos.
Evaluación del proyecto
Aunque la nota del proyecto está basada en el trabajo en equipo, es importante entender que la calificación del proyecto es individual.
El proyecto puede sumar hasta 2,5 puntos a la calificación de la asignatura, tal como se recoge en el proyecto docente, en función de la implicación demostrada, así como la calidad del proceso seguido y del resultado final del proyecto.
La asistencia a las 3 clases de seguimiento (9, 23 y 30 de noviembre) es obligatoria. La no asistencia a cada uno de estos seguimientos tendrá una penalización de 0,25 puntos.
La asistencia a la defensa y revisión de los proyectos (14 y 16 de diciembre) también es obligatoria. La no asistencia tendrá una penalización de 2,5 puntos (es decir, que implicará que el proyecto se califique con 0 puntos).
Las sesiones de defensa y revisión de proyectos, además de valorar el repositorio y los documentos del equipo, pueden incluir pruebas individuales, por lo que cada persona del equipo tendrá una calificación parcial individual, con un máximo de 2,5 puntos.
La nota final del proyecto se calculará con la fórmula:
NOTA FINAL DEL PROYECTO = Nota parcial del proyecto - penalizaciones
Por ejemplo, si una persona tiene una nota parcial del proyecto de 2,5 puntos y no ha tenido ningún tipo de penalización, su calificación final del proyecto se quedará en 2,5 puntos. Si la misma persona con una nota de un 2,5 parcial ha tenido dos penalizaciones por ausencia a dos de los seguimientos, su nota sería 2,5 - 0,25 - 0,25 = 2 puntos.
La calificación del proyecto no será menor que 0, independientemente de las penalizaciones. No obstante, si un estudiante incurre en plagio o en algún otro comportamiento que conlleve la aplicación de la normativa actual de la US en esta materia, ésta puede implicar otro tipo de consecuencias que serán aplicadas aparte.