Proyecto final de DAM y DAW: ideas que sí se terminan y cómo organizarte
El proyecto final es lo que más agobia en segundo de DAM y DAW. Y casi siempre por el mismo motivo: la idea es demasiado grande.
Lo vemos cada año. En enero alguien nos cuenta que va a hacer "una red social con chat en tiempo real, pagos y app móvil". En abril tiene un login que funciona a medias y una pantalla de inicio muy bonita. Lo demás, sin empezar.
Esta guía va de eso: elegir una idea que puedas terminar, organizarte para no llegar con el agua al cuello y defenderla con tranquilidad.
Antes de nada: con la nueva ley de FP, muchos centros lo llaman proyecto intermodular y algunos ya hacen una parte en primero. Las normas cambian bastante según la comunidad y el centro. Pide la guía o la rúbrica de evaluación de tu centro y tenla a mano. Todo lo que viene aquí lo tienes que adaptar a lo que pidan ahí.
Qué suelen valorar de verdad
No hace falta que tu idea sea original. Lo que suele contar es:
- Que funcione de principio a fin. Que se pueda crear, ver, editar y borrar lo importante, con usuarios y permisos si tiene sentido.
- Una base de datos bien pensada. Tablas con sentido, relaciones correctas, nada de datos repetidos por todas partes.
- Código ordenado. Nombres claros, separado en capas o paquetes, sin métodos de 300 líneas.
- La memoria. Qué has hecho, por qué, cómo y qué mejorarías.
- La defensa. Que sepas explicar tu proyecto y tu código sin titubear.
Un gestor de reservas sencillo que funciona entero suele puntuar más que una idea brillante que se queda a medias.
Cómo elegir la idea: tres filtros
1. Que quepa en el tiempo que tienes
Una buena fórmula: login + una gestión completa (crear, ver, editar, borrar) + una cosa que lo haga especial. Con eso tienes un proyecto sólido. Si te sobra tiempo, añades. Al revés es mucho peor: recortar cuando ya vas tarde duele.
2. Que use sobre todo lo que ya sabes
Usa las tecnologías que has visto en el ciclo y, como mucho, añade una nueva. Si pretendes aprender a la vez un framework, una base de datos distinta y a desplegar en la nube, te vas a pasar el proyecto peleándote con la configuración en vez de programando.
3. Que sepas explicarlo
En la defensa te van a preguntar por qué hiciste las cosas así. Si eliges algo que no entiendes del todo, se va a notar. Elige una idea que te haga sentir cómodo cuando te pregunten.
Un extra que ayuda mucho: que resuelva un problema real. La pista de pádel de tu pueblo que apunta las reservas en una libreta, el bar de un amigo que lleva el stock en un Excel... Te da requisitos concretos y algo que contar en la defensa.
Ideas de proyecto final para DAM
| Idea | Lo mínimo | El extra que lo hace destacar |
|---|---|---|
| App de reservas para un club deportivo | Usuarios, pistas, reservas por franja horaria | Notificación antes de la reserva y lista de espera |
| Gestor de inventario para una tienda pequeña | Productos, proveedores, entradas y salidas de stock | Avisos de stock bajo y exportar informes a PDF o CSV |
| App de entrenamiento o hábitos | Rutinas, registro diario, historial | Gráficas de progreso y funcionamiento sin conexión |
| Gestión de citas para un fisio o una peluquería | Clientes, servicios, agenda | Recordatorios y vista de agenda por profesional |
| App para una protectora de animales | Fichas de animales, solicitudes de adopción | Filtros de búsqueda y estado de cada solicitud |
Ideas de proyecto final para DAW
| Idea | Lo mínimo | El extra que lo hace destacar |
|---|---|---|
| Web de reservas para un restaurante | Reservas, mesas, panel de administración | Control de aforo por franja y confirmación por correo |
| Gestor de ligas amateur | Equipos, jugadores, partidos, resultados | Clasificación y calendario que se generan solos |
| Tablón de prácticas para tu instituto | Empresas publican ofertas, alumnos se apuntan | Roles distintos (alumno, empresa, tutor) con permisos |
| Mercadillo de segunda mano entre alumnos | Anuncios con fotos, búsqueda, contacto | Filtros por categoría y precio, favoritos |
| Web para una academia o gimnasio | Clases, horarios, inscripciones | Pagos simulados y área privada del alumno |
Cógelas como punto de partida. Lo bueno es que todas tienen una parte mínima que se puede acabar y un extra que puedes recortar si vas justo.
Ideas que mejor evitar (o recortar mucho)
- Clonar Instagram, Netflix o Spotify. Detrás hay equipos de cientos de personas. Tú tienes unos meses.
- Chat en tiempo real si nunca has trabajado con WebSockets. Puede ser un buen extra, pero no lo pongas como base.
- Pagos reales. Simúlalos. Integrar una pasarela de pago de verdad trae problemas que no te van a puntuar.
- "Una app con IA" sin saber exactamente qué hace la IA. Si la usas, que sea una pieza concreta, no todo el proyecto.
Qué tecnologías usar
La regla es fácil: lo que te han enseñado en el ciclo. El tribunal lo conoce y tú ya has pasado los primeros golpes.
- DAM: Java o Kotlin, Android (o JavaFX si es de escritorio), MySQL o PostgreSQL. Si quieres separar app y servidor, una API sencilla con Spring Boot.
- DAW: HTML, CSS y JavaScript en el front (con un framework solo si ya lo has visto), PHP con Laravel o Java con Spring en el servidor, y MySQL.
- Para los dos: Git desde el primer día. Haz commits pequeños y súbelo a GitHub o GitLab. El día que rompas algo (y lo vas a romper) lo vas a agradecer.
Un plan por semanas que funciona
Si tienes unas 10 semanas, algo así:
- Semana 1: idea cerrada y lista de requisitos. Escribe qué tiene que hacer sí o sí y qué es extra.
- Semana 2: diseño de la base de datos (diagrama entidad-relación) y bocetos de las pantallas. En papel vale.
- Semanas 3 a 6: lo básico. Login y la gestión principal funcionando de principio a fin. Aunque sea feo.
- Semanas 7 y 8: el extra que lo hace destacar y lo visual.
- Semana 9: pruebas, arreglar errores y despliegue (en DAW, la web publicada; en DAM, una APK o instalable que funcione en otro ordenador o móvil).
- Semana 10: memoria y defensa.
Si vas justo de tiempo, recorta el extra, nunca las pruebas.
Un truco para la memoria: ve apuntando cada semana qué has hecho, qué problema tuviste y cómo lo resolviste. Cinco minutos. Cuando llegue la semana 10, tendrás la mitad de la memoria escrita y no tendrás que acordarte de lo que hiciste en febrero.
Los errores que más vemos
- Empezar por lo bonito. Pasar dos semanas con colores y animaciones antes de tener nada funcionando.
- No pensar la base de datos. Y tener que rehacer tablas en la semana 6, con todo el código ya montado encima.
- Trabajar sin Git. Se rompe algo, no hay vuelta atrás y pierdes días.
- Copiar código que no entiendes. De un tutorial o de una IA. Funciona, pero en la defensa te preguntan "¿por qué usaste esto?" y no sabes qué decir.
- Dejar el despliegue para el último día. Siempre falla algo: una variable de entorno, la versión de PHP o Java, la conexión a la base de datos. Despliega algo pronto, aunque esté a medias.
Cómo preparar la defensa
Suele ser una presentación corta con demo y luego preguntas del tribunal. Para que salga bien:
- Guion de la demo. Decide qué vas a enseñar y en qué orden. No improvises clicando por la app.
- Datos de prueba creíbles. Nada de "asdf" ni "prueba1". Rellena la base de datos con datos que parezcan reales.
- Plan B. Graba un vídeo de la demo por si falla la wifi o el portátil. Pasa más de lo que crees.
- Prepara las preguntas típicas: por qué elegiste esas tecnologías, cómo diseñaste la base de datos, qué fue lo más difícil y qué mejorarías con más tiempo.
- Ten a mano un trozo de código que sepas explicar bien. Muchas veces te piden que abras uno y lo expliques.
Si te atascas
Atascarse en el proyecto es lo normal. Lo importante es no pasarse dos semanas parado.
Tener ayuda está bien. Un profesor de programación puede revisar contigo el diseño de la base de datos, explicarte esa parte de Spring o de Android que no hay manera de entender o depurar contigo un error que te tiene bloqueado. Lo que no debe hacer es hacerte el proyecto. Además de no estar bien, no te conviene: lo tienes que defender tú.
Si necesitas ese apoyo, en nuestras clases particulares de programación para DAM y DAW trabajamos sobre tu propio proyecto, en sesiones uno a uno online. Y si el problema es una tecnología concreta, también tenemos clases de Java, de SQL y de JavaScript.
Preguntas frecuentes
¿El proyecto final se puede hacer en grupo?
Depende del centro. Lo más habitual es que sea individual, pero hay centros que dejan hacerlo en parejas o grupos pequeños. Si es en grupo, deja claro desde el principio qué hace cada uno, porque en la defensa os pueden preguntar por separado.
¿Tiene que ser una idea original?
No. Puede ser un gestor de reservas como hay cientos. Lo que cuenta es que esté bien hecho, que funcione y que sea tuyo. La originalidad suma, pero no salva un proyecto que no funciona.
¿Puedo usar IA para el proyecto?
Depende de las normas de tu centro, así que pregúntalo. Si te dejan, úsala para entender y desatascarte, no para generar el proyecto entero. Y asegúrate de que entiendes cada línea que entregas, porque te la pueden preguntar.
¿Qué hago si voy muy tarde?
Recorta. Quédate con el login y la gestión principal funcionando bien, quita el extra y dedica el tiempo que te quede a probar y a la memoria. Un proyecto pequeño y terminado es mucho mejor que uno grande a medias. Si estás muy perdido, pide ayuda cuanto antes: con unas cuantas sesiones bien enfocadas se puede reorganizar mucho.