Todo lo que necesitas para planificar, desarrollar, documentar y defender el proyecto final del ciclo, con ideas concretas y plantillas. Úsalo como guía: lo que manda es la programación de tu centro.
Qué es el proyecto intermodular
Es un proyecto en el que aplicas a la vez lo aprendido en varios módulos del ciclo para resolver un problema real: analizarlo, diseñar una solución, construirla, probarla, documentarla y defenderla. Con la nueva ley de Formación Profesional (Ley Orgánica 3/2022) ocupa el lugar de los antiguos módulos de proyecto de DAM y DAW.
Su duración, el momento del curso en que se hace y cómo se evalúa los concretan cada comunidad autónoma y cada centro. Lo habitual es entregar un producto (la aplicación), una memoria y hacer una defensa ante un tribunal.
No es un ejercicio más: es tu carta de presentación. Muchos alumnos lo enseñan en las entrevistas de trabajo, así que merece la pena que esté terminado, publicado y bien explicado.
Fases y calendario orientativo
Para un proyecto de unas 14 semanas. Ajusta las fechas a tu calendario, pero no te saltes fases: el diseño ahorra mucho más tiempo del que cuesta.
1
Idea y anteproyecto
Semanas 1-2
Objetivo: Que el tutor apruebe una idea con un alcance realista.
Elige un problema real con un usuario concreto
Redacta el anteproyecto (problema, objetivos, alcance, tecnologías, calendario)
Acuerda con el tutor qué queda dentro y qué fuera
2
Análisis
Semanas 2-3
Objetivo: Saber exactamente qué se va a construir.
Requisitos funcionales y no funcionales
Casos de uso o historias de usuario priorizadas
Estudio de alternativas existentes y qué aporta tu proyecto
3
Diseño
Semanas 3-5
Objetivo: Decidir cómo se construye antes de programar.
Arquitectura y tecnologías justificadas
Modelo de datos (E/R y relacional)
Diagrama de clases y prototipos de pantallas
4
Desarrollo por iteraciones
Semanas 5-11
Objetivo: Tener pronto algo que funcione de principio a fin y ampliarlo.
Primera versión mínima de extremo a extremo
Iteraciones de 1-2 semanas con objetivo claro
Commits frecuentes y reuniones de seguimiento con el tutor
5
Pruebas y despliegue
Semanas 11-12
Objetivo: Demostrar que funciona y que cualquiera puede usarlo.
Pruebas unitarias y de integración de lo crítico
Pruebas con usuarios reales
Despliegue en un servidor o instalador
6
Memoria y defensa
Semanas 12-14
Objetivo: Contar el proyecto con claridad y defenderlo.
Terminar la memoria (que se ha ido escribiendo desde el principio)
Preparar la presentación y la demostración
Ensayar con preguntas difíciles
Cómo elegir la idea
Un problema real
Mejor si tiene un usuario concreto (un comercio, una asociación, tu empresa de prácticas). Te dará requisitos reales y alguien con quien probar.
Un alcance que puedas terminar
Define una versión mínima que funcione de principio a fin en la mitad del tiempo; el resto son ampliaciones.
Que integre el ciclo
Base de datos, lógica en un lenguaje del ciclo, una interfaz cuidada y un despliegue. Así demuestras lo aprendido.
Algo que puedas enseñar
Una demo de 5 minutos con un caso de uso completo luce más que veinte pantallas a medias.
Algo nuevo que aprender
Una tecnología o técnica que no hayas visto en clase, justificada, suma mucho en la defensa.
Datos disponibles
Si dependes de datos que no tienes (o de una API de pago), busca alternativas antes de empezar.
Ideas de proyectos
DAM y DAWDificultad media
Reservas de instalaciones deportivas municipales
Problema: Los vecinos reservan por teléfono y los horarios se gestionan en papel: hay solapes y pistas vacías que nadie sabe que están libres.
Versión mínima (MVP)
Calendario de disponibilidad por instalación
Reserva y cancelación con reglas (antelación, máximo por semana)
Panel del ayuntamiento con ocupación
Avisos por correo
Para subir nota: Pago online en modo de pruebas · Lista de espera automática · Estadísticas de uso por franja
Módulos: Bases de Datos, Programación o DWES, Interfaces o DIW, Despliegue
Tecnologías posibles: Spring Boot o PHP, PostgreSQL, Web responsive o Android
DAMDificultad alta
Gestión de un taller mecánico
Problema: El taller apunta las reparaciones en una libreta: los clientes llaman para preguntar el estado del coche y los presupuestos se hacen a mano.
Versión mínima (MVP)
Órdenes de trabajo con estados
Presupuesto y factura en PDF
App del cliente para ver el estado
Historial por vehículo
Para subir nota: Integración con Odoo · Notificaciones push · Lectura de matrícula con la cámara
Módulos: Acceso a Datos, Desarrollo de Interfaces, PMDM, SGE
Tecnologías posibles: JavaFX o Kotlin Multiplatform, Hibernate, Android para el cliente
DAWDificultad media
Plataforma para un banco de alimentos
Problema: Las donaciones, las caducidades y los repartos a familias se controlan con hojas de cálculo que se pierden o se pisan.
Versión mínima (MVP)
Inventario con caducidades y alertas
Registro de entregas por familia con cupos
Roles de voluntario y coordinador
Informes mensuales
Para subir nota: Escaneo de códigos de barras desde el móvil · Mapa de puntos de recogida · API para otras asociaciones
Módulos: DWES, DWEC, DIW, Despliegue, Bases de Datos
Tecnologías posibles: PHP (Laravel o propio) o Node, MySQL, JavaScript
DAM y DAWDificultad alta
Citas y historial de una clínica de fisioterapia
Problema: La clínica da citas por WhatsApp, olvida recordatorios y el historial de cada paciente está en carpetas.
Versión mínima (MVP)
Agenda de varios profesionales
Reserva online con confirmación
Historial clínico con acceso restringido
Recordatorios automáticos
Para subir nota: Cumplimiento del RGPD documentado (registro de accesos) · Videoconsulta · Encuesta de satisfacción
Módulos: Bases de Datos, DWES o Acceso a Datos, Interfaces, PSP (seguridad de datos)
Tecnologías posibles: Spring Boot o PHP, PostgreSQL, Web o Android
DAMDificultad alta
App de rutas de senderismo con modo sin conexión
Problema: Las rutas de la comarca están en PDF y en el monte no hay cobertura.
Versión mínima (MVP)
Catálogo de rutas con mapa y perfil
Descarga para usar sin conexión
Seguimiento GPS de la ruta
Favoritos y valoraciones
Para subir nota: Avisos de desvío de la ruta · Compartir la ubicación en emergencias · Subida de fotos geolocalizadas
Módulos: PMDM, Acceso a Datos, PSP, Interfaces
Tecnologías posibles: Kotlin y Jetpack Compose, Room, Mapas sin conexión, API REST propia
DAWDificultad media
Campus virtual para una academia
Problema: La academia usa correo y carpetas compartidas para materiales, tareas y notas.
Versión mínima (MVP)
Cursos con lecciones y materiales
Entrega de tareas y calificación
Calendario y avisos
Roles alumno, profesor y administración
Para subir nota: Tests autocorregidos · Foro por curso · Certificados en PDF
Módulos: DWES, DWEC, DIW, Despliegue
Tecnologías posibles: PHP o Node, MySQL, JavaScript, Docker
DAM y DAWDificultad media
Inventario y préstamo de material del instituto
Problema: Portátiles, proyectores y material de laboratorio se prestan sin control y nadie sabe dónde está cada cosa.
Versión mínima (MVP)
Inventario con ubicación y estado
Préstamo y devolución leyendo un QR
Incidencias de averías
Informe de material prestado
Para subir nota: Reservas de aulas · Notificaciones de retraso · Importación del inventario desde CSV
Módulos: Bases de Datos, Programación, Interfaces, Sistemas
Tecnologías posibles: Java o PHP, SQL, Códigos QR
DAWDificultad alta
Marketplace de comercios de barrio
Problema: Los pequeños comercios no pueden vender online porque las plataformas grandes cobran demasiado.
Versión mínima (MVP)
Tienda por comercio con su catálogo
Carrito y pedido con recogida en tienda
Panel del comerciante
Búsqueda por cercanía
Para subir nota: Valoraciones · Envíos con repartidores del barrio · Estadísticas de ventas
Módulos: DWES, DWEC, DIW, Despliegue, Bases de Datos
Tecnologías posibles: PHP o Node, MySQL, JavaScript, Pasarela de pago en modo de pruebas
DAMDificultad alta
Módulo de Odoo para gestionar una asociación
Problema: Una asociación cultural gestiona socios, cuotas y actividades con hojas de cálculo.
Versión mínima (MVP)
Socios con cuotas y recibos
Actividades con inscripción y aforo
Portal del socio
Informes para la junta
Para subir nota: Envío de remesas bancarias · App móvil con la API de Odoo · Votaciones online
Módulos: SGE, Bases de Datos, Programación (Python), Interfaces
Tecnologías posibles: Odoo, Python, PostgreSQL
DAMDificultad alta
Videojuego educativo para primaria
Problema: Un colegio quiere repasar las tablas de multiplicar y la ortografía de forma divertida y ver el progreso de cada alumno.
Versión mínima (MVP)
Juego con varios niveles y dificultad adaptativa
Perfiles de alumno
Panel del profesor con el progreso
Sonido y accesibilidad
Para subir nota: Modo multijugador local · Editor de preguntas para el profesor · Versión para tableta
Módulos: PMDM (motores de juegos), Programación, Acceso a Datos, Interfaces
Tecnologías posibles: Godot o Unity, API REST, Base de datos
DAM y DAWDificultad alta
Panel de monitorización de servidores
Problema: El departamento de informática se entera de las caídas cuando llaman los usuarios.
Versión mínima (MVP)
Agente que envía CPU, memoria y disco
Panel en tiempo real
Alertas por umbral
Historial con gráficas
Para subir nota: Comprobación de webs y certificados · Alertas por Telegram · Despliegue en varios servidores
Módulos: PSP o Despliegue, Sistemas, DWEC, Bases de Datos
Tecnologías posibles: Java o Node, Agentes en los servidores, WebSockets, Docker
DAWDificultad media
Portal de trámites accesible para un ayuntamiento pequeño
Problema: Los vecinos mayores no saben hacer trámites online y la web actual no es accesible.
Versión mínima (MVP)
Catálogo de trámites en lenguaje claro
Formularios accesibles con guardado de borrador
Seguimiento del trámite
Declaración de accesibilidad
Para subir nota: Versión en lectura fácil · Cita previa · Firma con certificado digital (investigación)
Módulos: DIW, DWES, DWEC, Despliegue
Tecnologías posibles: PHP, MySQL, HTML y CSS accesibles
Es la propuesta que presentas al tutor antes de empezar. Un buen anteproyecto deja claro qué entra y qué no: es tu mejor defensa contra los proyectos que crecen sin control. Copia esta plantilla y rellénala:
anteproyecto.md
1ANTEPROYECTO — PROYECTO INTERMODULAR
23Título provisional:
4Alumno/a: Ciclo: DAM / DAW
5Tutor/a: Curso:
671. Problema
8 ¿Qué problema resuelve? ¿A quién afecta? ¿Cómo se resuelve hoy?
9102. Usuarios
11 Tipos de usuario y qué necesita cada uno.
12133. Objetivo general y objetivos específicos (medibles)
14 - El usuario podrá …
15 - El sistema …
16174. Alcance
18 Dentro: funcionalidades de la primera versión (MVP)
19 Fuera: lo que NO se hará (ampliaciones futuras)
20215. Módulos del ciclo que se integran
22 Bases de Datos: … Programación / DWES: … Interfaces / DIW: … Despliegue: …
23246. Tecnologías previstas y motivo de su elección
25267. Calendario por fases (semanas)
27288. Riesgos y plan B
29 Riesgo: … Probabilidad: … Qué haré si ocurre: …
La memoria
Escríbela mientras avanzas: al final no recordarás por qué tomaste cada decisión. Un índice habitual:
Portada, resumen y abstract. Título, autor, ciclo, tutor y curso. Resumen de media página en español y en inglés con el problema, la solución y los resultados.
Introducción y justificación. El problema, a quién afecta, por qué merece la pena resolverlo y qué existe ya (estudio de alternativas).
Objetivos. Objetivo general y objetivos específicos medibles. Qué queda fuera del alcance.
Planificación. Metodología, calendario (Gantt o sprints), recursos y presupuesto estimado. Al final, comparación con lo que pasó de verdad.
Análisis. Requisitos funcionales y no funcionales, casos de uso o historias de usuario.
Diseño. Arquitectura, modelo de datos, diagramas UML, prototipos y guía de estilo. Cada decisión, justificada.
Implementación. Estructura del código, tecnologías, partes más interesantes explicadas (no todo el código) y problemas resueltos.
Pruebas. Plan de pruebas, resultados, cobertura y pruebas con usuarios.
Despliegue y manuales. Cómo instalar y desplegar; manual de usuario con capturas.
Conclusiones y trabajo futuro. Grado de cumplimiento de los objetivos, lo aprendido, dificultades y posibles ampliaciones.
Bibliografía y anexos. Fuentes citadas, licencias de terceros, documentación técnica extensa.
Consejos de redacción: justifica en lugar de describir («elegí PostgreSQL porque…» en lugar de «PostgreSQL es una base de datos»); usa diagramas propios y numera figuras y tablas; no pegues código entero (explica los fragmentos interesantes y enlaza el repositorio); cita todas las fuentes.
La defensa
Estructura de una presentación de 15 minutos
El problema (1 min): quién lo tiene y por qué importa.
La solución (1 min): qué hace tu aplicación, en una frase.
Demostración (5 min): un caso de uso completo, ensayado.
Cómo está hecho (4 min): arquitectura, datos y una decisión técnica interesante.
Pruebas y resultados (2 min): qué se ha comprobado y con quién.
Conclusiones (2 min): qué aprendiste y qué harías después.
Preguntas habituales del tribunal
¿Por qué has elegido esta tecnología y no otra?
¿Qué pasaría si lo usaran 10 000 personas a la vez?
¿Cómo has protegido los datos personales y las contraseñas?
¿Qué fue lo más difícil y cómo lo resolviste?
Si empezaras de nuevo, ¿qué harías de otra forma?
¿Qué parte no está terminada y por qué?
¿Cómo sabes que funciona? ¿Qué pruebas has hecho?
¿Qué módulos del ciclo se reflejan en el proyecto?
Rúbrica orientativa
Criterio
Peso
Para la máxima nota
Análisis y planificación
15 %
Problema real bien acotado, requisitos claros y planificación seguida y revisada
Diseño
15 %
Arquitectura y modelo de datos justificados y coherentes con el producto final
Producto: funcionalidad y calidad
30 %
Cumple los objetivos, funciona sin errores graves y el código es limpio y mantenible
Pruebas y despliegue
10 %
Pruebas de lo crítico y aplicación desplegada o instalable
Memoria
15 %
Completa, bien escrita, con decisiones justificadas y sin relleno
Defensa
15 %
Presentación clara, demostración fluida y respuestas seguras a las preguntas
Orientativa: tu centro publicará los criterios oficiales de evaluación.
Errores típicos
Elegir un proyecto enorme («una red social completa») y no terminar nada. Mejor algo pequeño, terminado y bien hecho.
Programar sin análisis ni diseño y rehacerlo todo a mitad de curso.
Dejar la memoria para la última semana: se olvida por qué se tomaron las decisiones.
No usar control de versiones o hacer un único commit al final.
Una demostración en directo sin ensayar ni plan B (vídeo grabado por si falla la red).
Copiar código o textos sin citarlos: es plagio y el tribunal lo nota.
Diapositivas llenas de texto o de código en la defensa.
No probar con usuarios reales hasta el final.
Antes de entregar
Marca lo que ya tienes: se guarda en este navegador. Llevas 0 de 10.
Preguntas frecuentes
¿Qué es el proyecto intermodular de DAM y DAW?
Es un proyecto, normalmente individual, en el que se aplican de forma conjunta los resultados de aprendizaje de varios módulos del ciclo para resolver un problema real: analizarlo, diseñar y construir una solución, probarla, documentarla y defenderla. Con la Ley Orgánica 3/2022 de FP sustituye a los antiguos módulos de proyecto.
¿Cuándo se hace y cuánto dura?
Suele desarrollarse en segundo curso, a menudo coincidiendo con la formación en empresa o al final del curso. Las horas, el calendario y la forma de evaluarlo los concreta cada comunidad autónoma y cada centro, así que consulta siempre la programación de tu centro.
¿Puede ser en grupo?
Depende del centro. Si se permite, cada persona debe tener una parte claramente identificable y defenderla individualmente.
¿Puedo hacerlo sobre la empresa de prácticas?
Muchos centros lo permiten y suele dar lugar a proyectos muy realistas, pero necesitas el permiso de la empresa para usar sus datos y publicar el código. Si no es posible, anonimiza los datos o crea un caso ficticio basado en ella.
¿Qué tecnologías debo usar?
Las que mejor resuelvan el problema y puedas justificar. Es buena idea apoyarse en las del ciclo (Java, Kotlin, PHP, JavaScript, SQL…) y añadir alguna nueva que aprendas por tu cuenta, explicando por qué la elegiste.
¿Cuánto debe ocupar la memoria?
Lo que diga tu centro; como orientación, entre 40 y 80 páginas sin anexos. Importa más que esté completa y justificada que su extensión.
¿Cómo es la defensa?
Habitualmente una presentación de 10 a 20 minutos ante un tribunal, con demostración del producto, seguida de preguntas sobre las decisiones técnicas, las dificultades y lo aprendido.