M3-20 21

M3: Defensa de trabajos

M3: 🔊,🔊 🔊 🔊 🔊 🔊

tercer milestone

➖➖➖➖➖➖➖➖➖

👉🏾 M3: Defensa de trabajos

Debe reservar turno para la defensa a través de esta tabla(use su UVUS). El plazo para reservar hueco para la defensa se abrirá el día 13 de Enero a las 12.00 y debe reservar un hueco antes de las 10:00 del día 18 de Enero de 2021. Solo tiene que reservar un hueco para el equipo en las distintas defensas que se han programado en los horarios disponibles.
Debe rellenar el siguiente formulario también y debe hacerlo igualmente antes de las 10:00 del día 18 de Enero de 2021.

➖➖➖➖➖➖➖➖➖

Dirigido a: todos los equipos, de todos los proyectos y todos los alumnos del equipo. Si un alumno no se presenta a la defensa, se considerará a ese alumno/a como no presentado a la evaluación continua en la parte del proyecto.

Presentarse al M3 es obligatorio para poder tener una nota en el proyecto puesto que al M4 solo se podrán presentar proyectos que se hayan presentado al M3 y quieran mejorarlo.

Las defensas se harán online usando las salas virtuales que se señalarán con la debida antelación

Cada equipo tendrá un espacio de 30 minutos estrictos en el que se hará una presentación del trabajo desarrollado con el tutor que tenga asignado dicho proyecto

El tutor, previamente, habrá visualizado el vídeo de 10 minutos que haya preparado el equipo (ver más indicaciones adelante)

El equipo se identificará usando una cámara web y estará provisto de su DNI. Si por algún motivo no pudiera usar su cámara, se permitirá que se identifique físicamente en la ETSII y haga la defensa desde esas dependencias. Para ello tendrá que avisar antes de la entrega a su tutor, es decir, antes de las 10:00 del día 18 de Enero de 2021.

No se trata de defender como tal los entregables del trabajo (diario del equipo, documentación, código). Dichos entregables serán evaluados a posteriori por parte del profesorado.

La defensa se hace con el equipo al completo y el profesor correspondiente de la asignatura, es decir, no se trata de una defensa pública a donde asistan el resto de compañeros/as de clase.

El profesor podrá hacer preguntas individuales así como pedir que se realicen tareas a cada miembro del equipo lo que deberá efectuarse sin consultar al resto de componentes del mismo.

que tiene trabajada la presentación para el tiempo que se le ha asignado
que el subsistema que presenta (producto) es lo suficientemente complejo y está bien terminado para poder haber puesto en práctica todos los conceptos y herramientas vistas en la asignatura.
En su caso, con cuántos otros proyectos se ha integrado completamente, sea porque consume sus servicios o sea porque ofrece dichos servicios teniendo en cuenta que debe ser otro(s) proyecto(s) que también haya(n) evolucionado con respecto al sistema base.
por otro lado, tras una petición de cambio por parte del profesor, el equipo mostrará el proceso general de desarrollo del proyecto partiendo de una petición de cambio hasta llegar al despliegue de la aplicación con el cambio aplicado y para eso pasar por todas las tareas de gestión incidencias, código, construcción, integración continua, etcétera. El nivel de automatización alcanzado es algo que se mirará con mucho detalle.
para este último punto, el equipo podría traer un cambio propuesto previamente preparado y proponérselo al profesor y éste podría aceptar dicho cambio o proponer algún otro. Se espera que en ese cambio participen todos los miembros del equipo.

El equipo debe preparar un vídeo de un máximo de 10 minutos (este tiempo es estricto) que tendrá que entregar junto con el resto de entregables

El vídeo debe mostrar, sobre todo, qué cambios ha hecho el equipo al proyecto y cómo se ha integrado con el resto de miembros del proyecto. Este vídeo está pensado para ser visualizado por los profesores antes de la defensa del equipo de modo que el profesor pueda estar en contexto antes de la defensa.

El equipo habrá hecho la entrega, a través del formulario de los entregables del proyecto además del vídeo en los plazos establecidos.

Sólo se entregará una vez por cada proyecto. Si se hubiese cometido algún error, se volverá a hacer la entrega y se considerará solo la última entrega que se haya efectuado.

NOTA IMPORTANTE: Después de esa fecha NO se podrán hacer cambios ni en la documentación, ni en el proyecto (no se pueden por tanto hacer cambios ni en el repositorio de código ni en ninguno de los elementos del proyecto). Si se detecta algún cambio después de esa fecha y esa hora, se considerará el proyecto no presentado por defecto de forma. Para ello, todos los entregables deben dejar rastro de la última modificación hecha y que esto pueda ser fácilmente auditable por el profesor. Use por lo tanto un sistema para la entrega que permita dicha autidoría. Si no se pudiese auditar la fecha de la última modificación se considerará defecto de forma.

Cada miembro del equipo debe tener una máquina con el entorno de desarrollo y despliegue listo para trabajar de manera individual

El sistema deberá estar desplegado en local y en remoto para hacer las pruebas correspondientes

Debe tener abierta tantas pestañas en el navegador como sea necesario para poder acceder al repositorio de código, al de integración continua, a la gestión de incidencias, al sistema en remoto y/o en local, etcétera.

Todos los miembros del equipo deben ser capaces de realizar todas las tareas de evolución y gestión de la configuración que sean necesarias.

Impacto en la nota: Se tomará nota de la asistencia. Se considerarán presentados a los alumnos que hayan ido y se hayan identificado en la defensa. Se considerarán no presentados, y por lo tanto tendrán una nota de cero en la parte del proyecto, a los alumnos/as que no vayan a la defensa. De esta defensa y la corrección a posteriori del proyecto saldrá la nota del proyecto de cara a la nota para la evaluación continua de la asignatura.

Obligatoriedad de este entregable: En la fecha fijada para el M4, se permitirá solamente entregar mejoras con respecto a este milestone pero no se podrá entregar nada si no se ha hecho la defensa y entrega de este M3.

Si hay miembros del equipo que no quieren ir a M4, el resto de miembros que sí quieran ir a M4 podrán hacerlo pero para ello tendrán que dejar claro cuál ha sido su trabajo desde M3. Para esto usarán los mecanismos que sean más sencillos (e.g. fork de los repositorios, documentación,..) dejando clara la diferencia entre lo entregado en M3 y lo que se entregue en M4