Un producto, dos módulos coordinados

El mismo grupo desarrolla el mismo producto durante los dos trimestres. Conserva tema, autoría/equipo, repositorio de backend e historial. El portfolio presenta ese producto; el cliente utiliza ese backend. El gestor de los ejemplos sirve de referencia y cada proyecto mantiene su propio dominio.

Horario y dependencias

Plan de 26 semanas lectivas: dos sesiones de Servidor y una de Intermodular por semana, de tres horas cada una. Cada sesión reserva 25 minutos de explicación, 140 de trabajo guiado y 15 de cierre. Primer trimestre: 28 sesiones de Servidor (84 horas) y 14 de Intermodular (42 horas). Segundo: 24 de Servidor (72 horas) y 12 de Intermodular (36 horas).

Cada semana empieza con Intermodular y continúa con dos sesiones de Servidor. En Intermodular utilizas la versión que terminaste la semana anterior; en Servidor implementas el siguiente avance. La primera sesión de Intermodular prepara el portfolio y su publicación: el backend se inicia después.

Secuencia de los dos trimestres y punto de encuentro semanal
SemanaServidor · disponible al empezarIntermodular · primer taller de la semanaServidor · después de Intermodular
1Primer trimestreTodavía no se ha iniciado el backend.1. Del repositorio vacío a una URL pública1. Elegir el CRUD y arrancar el servidor2. Rutas y primeras consultas del proyecto
2Primer trimestre1. Elegir el CRUD y arrancar el servidor2. Rutas y primeras consultas del proyecto2. Issues, tablero y la primera pull request3. JSON y primera escritura con un cliente HTTP4. Primera versión CRUD en memoria
3Primer trimestre3. JSON y primera escritura con un cliente HTTP4. Primera versión CRUD en memoria3. Vuestro primer workflow5. De la petición al objeto Java6. Escrituras y respuestas HTTP
4Primer trimestre5. De la petición al objeto Java6. Escrituras y respuestas HTTP4. Enlaces rotos y formato7. Colección ejecutable y entornos8. Contrato en memoria listo para evolucionar
5Primer trimestre7. Colección ejecutable y entornos8. Contrato en memoria listo para evolucionar5. El presupuesto de calidad9. Recursos y contrato REST del dominio10. Representaciones y DTO
6Primer trimestre9. Recursos y contrato REST del dominio10. Representaciones y DTO6. Cerrar el primer proyecto11. Entradas, salidas y mapeo12. Validar las entradas del CRUD
7Primer trimestre11. Entradas, salidas y mapeo12. Validar las entradas del CRUD7. El CI del repositorio de Servidor13. Reglas propias y errores coherentes14. Publicar el contrato que consumirá el portfolio
8Primer trimestre13. Reglas propias y errores coherentes14. Publicar el contrato que consumirá el portfolio8. La API en una URL15. Separar controller, service y repository16. Inyección de dependencias
9Primer trimestre15. Separar controller, service y repository16. Inyección de dependencias9. Comprobar el contrato publicado17. Reglas de negocio probadas18. Consolidar las capas del mismo proyecto
10Primer trimestre17. Reglas de negocio probadas18. Consolidar las capas del mismo proyecto10. Preparar la transición a persistencia19. Preparar PostgreSQL y la persistencia20. Primera entidad persistente
11Primer trimestre19. Preparar PostgreSQL y la persistencia20. Primera entidad persistente11. Preparar el CI de la versión persistente21. CRUD persistente y consultas del dominio22. Probar los repositorios
12Primer trimestre21. CRUD persistente y consultas del dominio22. Probar los repositorios12. La base de datos en producción23. Relaciones uno a muchos24. Relaciones muchos a muchos
13Primer trimestre23. Relaciones uno a muchos24. Relaciones muchos a muchos13. Priorizar la evolución del mismo producto25. Transacciones y reglas de integridad26. Consultas, N+1 y versión persistente desplegada
14Primer trimestre25. Transacciones y reglas de integridad26. Consultas, N+1 y versión persistente desplegada14. La defensa del proceso27. Cerrar la primera versión del proyecto elegido28. Revisión y defensa del backend en producción
15Segundo trimestre27. Cerrar la primera versión del proyecto elegido28. Revisión y defensa del backend en producción15. Planificar el incremento y sus dependencias29. Relaciones expuestas y filtros30. Paginación y ordenación
16Segundo trimestre29. Relaciones expuestas y filtros30. Paginación y ordenación16. Revisar búsquedas y paginación31. Tests HTTP y documentación OpenAPI32. Evolucionar el contrato sin romper el cliente
17Segundo trimestre31. Tests HTTP y documentación OpenAPI32. Evolucionar el contrato sin romper el cliente17. Revisar y publicar un contrato compatible33. Construir el primer cliente y diagnosticar CORS34. Integración del navegador antes de la seguridad
18Segundo trimestre33. Construir el primer cliente y diagnosticar CORS34. Integración del navegador antes de la seguridad18. Integrar el cliente ya construido en Servidor35. Identidad, sesión y permisos del producto36. Contraseñas y Spring Security
19Segundo trimestre35. Identidad, sesión y permisos del producto36. Contraseñas y Spring Security19. Planificar permisos y preparar el entorno de seguridad37. Usuarios persistentes y roles38. Permisos sobre cada recurso
20Segundo trimestre37. Usuarios persistentes y roles38. Permisos sobre cada recurso20. Comprobar roles y propiedad en el proceso de revisión39. Sesión y token: integrar JWT40. CSRF, CORS con credenciales y cierre seguro
21Segundo trimestre39. Sesión y token: integrar JWT40. CSRF, CORS con credenciales y cierre seguro21. Publicar el acceso con JWT sin perder permisos41. Consumir un servicio externo42. Timeouts y fallos parciales
22Segundo trimestre41. Consumir un servicio externo42. Timeouts y fallos parciales22. Comprobar una dependencia externa y su degradación43. Ficheros y comunicación externa44. Integración completa comprobada
23Segundo trimestre43. Ficheros y comunicación externa44. Integración completa comprobada23. Verificar archivos y efectos externos45. Estrategia de pruebas y diagnóstico46. Documentación y revisión de calidad
24Segundo trimestre45. Estrategia de pruebas y diagnóstico46. Documentación y revisión de calidad24. Cerrar una candidata con evidencias de calidad47. Especificar la ampliación final48. Implementar la ampliación por capas
25Segundo trimestre47. Especificar la ampliación final48. Implementar la ampliación por capas25. Ensayar la recuperación y publicar el incremento49. Completar núcleo, seguridad e integración50. Conectar Angular al backend del proyecto
26Segundo trimestre49. Completar núcleo, seguridad e integración50. Conectar Angular al backend del proyecto26. Defender el producto y el proceso sobre la misma versión51. Verificar, documentar y preparar la versión52. Defender el backend completo

Una entrega, criterios diferenciados

En cada cierre de trimestre se utiliza el mismo commit y la misma demostración. Cada módulo conserva sus criterios y calificación; no se repite una memoria ni se concede la misma puntuación dos veces por el mismo requisito. La ponderación se concreta en la programación y rúbrica del módulo.

Qué aporta cada evidencia a la evaluación
Evidencia comúnServidor evalúaIntermodular evalúa
Caso de uso y códigoModelo, reglas, integridad y comportamiento del backend.Criterio de aceptación, dependencias y alcance del cambio.
Test y ejecución CIQué comportamiento comprueba, sus casos y sus aserciones.Entorno reproducible, ejecución efectiva y bloqueo de fusión cuando falla.
Issue y pull requestCorrección de la solución y justificación técnica.Trazabilidad, aportación individual y revisión con observaciones comprobables.
Versión desplegadaFuncionamiento del backend, persistencia y, cuando se hayan trabajado, permisos e integraciones.Identificación de versión, configuración, publicación, comprobación posterior y recuperación.
Cliente y contratoRespuestas, errores y controles de acceso que implementa la API.Compatibilidad entre versiones y recorrido integrado reproducible.
DefensaExplicación del código y sus decisiones.Explicación del proceso y sus evidencias. La demostración del producto se comparte.

Qué debes poder demostrar

Una issue puede servir a ambos módulos. Una revisión externa no cambia la autoría/equipo del proyecto. Cada integrante explica su aportación con cambios, decisiones y comprobaciones; el número de commits o de fallos del pipeline no determina la nota.

Qué se explica una vez y qué se practica después

Cierres coordinados

Intermodular 14 revisa el proceso sobre el backend comprobado hasta Servidor 25–26; Servidor 27–28 completa su demostración técnica esa misma semana. Intermodular 26 explica el proceso de la versión integrada hasta Servidor 49–50; Servidor 51–52 completa la aceptación y defensa técnica. Utiliza el mismo producto y relaciona sus resultados, sin dar por realizada una comprobación futura.