Proyecto de DAM: ejemplos, arquitectura, pruebas y memoria

El nombre oficial del llamado «TFG de DAM» es Proyecto de desarrollo de aplicaciones multiplataforma, módulo 0492 del Real Decreto 450/2010. Sus resultados de aprendizaje no describen una aplicación concreta: piden detectar una necesidad, diseñar una respuesta, planificar su ejecución y establecer seguimiento. La tecnología debe estar al servicio de esa secuencia.

Una aplicación modesta no obtiene mejor valoración solo por ser pequeña, ni una ambiciosa fracasa por ser grande. Lo decisivo es que el alcance sea viable, cubra competencias relevantes y deje evidencias verificables. Antes de elegir framework, defina usuario, problema, contexto de uso y criterio de éxito.

De la idea a requisitos comprobables

«Una app de hábitos» es un género, no una necesidad. Precise quién la utiliza, qué tarea resuelve, en qué dispositivo, con qué conectividad y qué información trata. Entreviste a usuarios cuando sea posible; si el caso es simulado, documente los supuestos.

Redacte requisitos con condiciones observables: crear una reserva evitando solapamientos, consultar datos sin conexión, sincronizar cambios, exportar un informe o restringir una acción por rol. Añada requisitos no funcionales: privacidad, accesibilidad, rendimiento, compatibilidad, recuperación y mantenibilidad. Luego conecte cada requisito con diseño, implementación y prueba mediante una matriz de trazabilidad.

Ideas que permiten demostrar el ciclo

Una herramienta operativa para una entidad de la FCT puede tener usuarios y restricciones reales. Una aplicación de inventario puede demostrar persistencia, cámara o lector, sincronización y control de permisos. Una app de campo puede trabajar sin conexión y resolver conflictos posteriores. Un sistema de citas puede abordar reglas de negocio, notificaciones y protección de datos. También son válidos un cliente de una API pública o un juego si el alcance permite justificar arquitectura, persistencia, pruebas y experiencia de uso.

No incorpore geolocalización, inteligencia artificial o notificaciones solo porque «suman». Cada dependencia añade permisos, errores, límites, privacidad y pruebas. Una función aporta valor cuando resuelve un requisito y se puede demostrar en condiciones normales y adversas.

Arquitectura proporcionada al problema

Explique límites entre interfaz, lógica, datos y servicios; modelo de dominio; flujo de estado; persistencia local; comunicación y estrategia de errores. Si hay sincronización, defina fuente de verdad, identificadores, reintentos, conflictos y comportamiento sin red. Si hay varias plataformas, enumere qué se comparte y qué necesita una implementación específica.

No convierta la memoria en un tutorial del framework. Compare alternativas con criterios del proyecto —competencias del equipo, soporte, licencias, acceso a hardware, plazo y facilidad de prueba— y registre la decisión. Un diagrama pequeño que coincide con el código vale más que una arquitectura de moda nunca implementada.

Seguridad, privacidad y secretos

Modele quién puede hacer qué y sobre qué datos. Valide entradas, aplique el principio de mínimo privilegio y no almacene contraseñas, claves de API o tokens en el repositorio. Si maneja datos personales, reduzca su recogida y defina retención, eliminación, acceso y copias. Use datos sintéticos en la demo.

La guía oficial de calidad de aplicaciones Android es útil para revisar experiencia, compatibilidad y aspectos técnicos cuando esa plataforma forma parte del proyecto. Para controles de aplicación y backend, el OWASP Application Security Verification Standard sirve como lista de referencia graduable; no es necesario afirmar que se cumple un nivel si no se ha verificado.

Pruebas que demuestran, no capturas que adornan

La matriz de pruebas debe enlazar requisito, datos iniciales, pasos, resultado esperado, resultado obtenido y evidencia. Pruebe lógica relevante, integración con base de datos o API, flujos completos, permisos, errores de red, datos inválidos y plataformas declaradas. Automatice donde aporte repetibilidad y documente pruebas manuales cuando dependan del dispositivo o de la interacción.

Incluya incidencias reales y cómo cambiaron el diseño. Ocultarlas produce una memoria poco creíble; analizarlas demuestra control del proceso. Mida solo lo que tenga relación con un requisito, por ejemplo tiempo de arranque o consumo en una operación crítica, indicando dispositivo y condiciones.

Entrega reproducible y memoria

El repositorio debe incluir estructura limpia, dependencias fijadas, configuración de ejemplo sin secretos, instrucciones de construcción, esquema o migraciones, datos de demostración y licencia de recursos. Etiquete la versión entregada. Compruebe desde un entorno limpio que otra persona puede construir o ejecutar el proyecto siguiendo el documento.

Ordene la memoria alrededor de decisiones: necesidad y alcance; requisitos; alternativas; diseño; planificación; implementación relevante; seguridad; pruebas; despliegue o empaquetado; resultados, límites y mantenimiento. Lleve a anexos listados extensos y no vuelque el código en el cuerpo. La plantilla del centro tiene prioridad sobre cualquier índice online.

Una defensa basada en una historia técnica

Prepare una demo corta con datos controlados y un vídeo de respaldo. Explique problema, decisión arquitectónica principal, flujo representativo, prueba que lo valida y límite conocido. Tenga previsto qué hacer si falla la red o un servicio externo. El tribunal debe poder distinguir qué funciona, qué se ha simulado y qué queda fuera.

Consulte también DAW para proyectos web y ASIR para infraestructura. El hub de proyectos de FP reúne el resto de ciclos.

Cuando el reto está en acotar el producto y documentar lo construido, podemos plantear un apoyo profesional para el proyecto final de DAM ajustado a la plantilla de su centro.