Proyecto de DAW: ejemplos, seguridad, pruebas y despliegue

El proyecto final de DAW se denomina oficialmente Proyecto de desarrollo de aplicaciones Web, módulo 0616 del Real Decreto 686/2010. El módulo integra capacidades del ciclo, pero no obliga a construir un comercio electrónico ni a utilizar una combinación concreta de frameworks. La programación del centro y el problema elegido determinan el alcance.

Una aplicación desplegada no es automáticamente un buen proyecto. Debe existir una relación verificable entre necesidad, requisitos, diseño, implementación, pruebas y operación. La URL es una evidencia más, no el objetivo académico.

Defina el servicio antes del stack

Empiece con usuarios y tareas: quién necesita hacer qué, qué información consulta o modifica, qué reglas limitan la acción y qué sucede cuando algo falla. Una «web de reservas» puede ser un simple formulario o un sistema con disponibilidad, concurrencia, roles, cancelaciones y trazabilidad. El alcance se vuelve defendible cuando esas reglas quedan explícitas.

Escriba requisitos funcionales y no funcionales. Incluya privacidad, accesibilidad, rendimiento, compatibilidad, disponibilidad, copia y recuperación en la medida en que afecten al servicio. Una matriz que conecte requisito, ruta o componente y prueba evita que la memoria describa una versión distinta del código.

Ideas con una necesidad reconocible

Una herramienta interna de la FCT permite validar flujos con personas que conocen el proceso. Una aplicación de citas puede centrarse en disponibilidad y roles; un inventario, en movimientos y consistencia; una plataforma de contenidos, en permisos, búsqueda y moderación; un portal de incidencias, en estados, notificaciones y auditoría. Un cliente de API externa es válido si añade lógica propia, persistencia y manejo de fallos.

Evite convertir el proyecto en una suma de funcionalidades. Cierre primero el flujo principal de extremo a extremo. Después incorpore mejoras que tengan un criterio de aceptación. Una pasarela en sandbox, por ejemplo, no equivale a un comercio listo para producción y debe describirse con ese límite.

Arquitectura, datos y autorización

Explique límites entre navegador, servidor, almacenamiento y servicios externos. Presente el modelo de datos con restricciones, no solo tablas. Defina qué capa valida reglas, cómo se gestionan transacciones, qué puede hacer cada rol y qué respuesta recibe el usuario ante un error. Si usa una API, documente contrato, versiones, autenticación, límites y reintentos.

La elección tecnológica debe responder a criterios: aprendizaje previo, ecosistema, mantenimiento, despliegue, licencias, pruebas y tiempo. Registre alternativas descartadas. No dedique páginas a explicar qué es React, Laravel o una base de datos; explique por qué esa versión y esa estructura resuelven este caso.

Seguridad y privacidad como requisitos

No basta con hashear contraseñas. Valide entradas, codifique salidas, aplique protección de sesión y CSRF cuando corresponda, limite intentos, separe autenticación de autorización y evite controles exclusivamente en el cliente. Los secretos deben quedar fuera del repositorio; los registros no deben exponer credenciales ni datos innecesarios.

El OWASP Application Security Verification Standard ofrece una referencia estructurada para seleccionar controles. Use los que sean pertinentes y conserve pruebas. No afirme que la aplicación «cumple OWASP» por haber pasado un escáner. Si maneja datos personales, documente finalidad, minimización, acceso, conservación y eliminación, y utilice datos sintéticos en la demostración.

Accesibilidad que pueda comprobarse

El currículo de DAW incluye accesibilidad y usabilidad. Las WCAG del W3C proporcionan criterios verificables. Defina el nivel o subconjunto que realmente evaluará y combine herramientas automáticas con revisión manual: navegación por teclado, foco, jerarquía, etiquetas, mensajes de error, contraste, ampliación y lectura con tecnología de apoyo cuando proceda.

Describa hallazgos y correcciones. Una puntuación de herramienta no demuestra por sí sola que la aplicación sea accesible; tampoco debe ocultarse una limitación que no pudo resolverse. La evaluación honesta es parte del resultado.

Pruebas y operación

Pruebe la lógica de negocio, la integración con datos, las rutas principales, la autorización negativa, los formularios, los errores y la compatibilidad declarada. Añada pruebas de seguridad y accesibilidad ligadas a requisitos. Para cada evidencia indique entorno, datos y resultado. La captura aislada de una pantalla no muestra que un caso se haya ejecutado correctamente.

Si despliega, documente construcción, variables, migraciones, TLS, permisos, copias, restauración, observabilidad y rollback. Use una cuenta y datos de demostración. El proyecto debe poder reconstruirse desde el repositorio sin publicar secretos. Si depende de un servicio gratuito o externo, explique el plan ante indisponibilidad.

Estructura de la memoria

Presente necesidad, alcance y requisitos; alternativas y arquitectura; modelo de datos y diseño; planificación; implementación de decisiones relevantes; seguridad y privacidad; accesibilidad; pruebas; despliegue y operación; resultados, incidencias, límites y mejoras. Coloque listados y manuales extensos en anexos. La plantilla del centro prevalece, pero la trazabilidad no debería perderse por seguir un índice.

Prepare una demo resistente

Elija un flujo que represente el problema y muestre una regla de negocio, una decisión de seguridad y una prueba. Prepare datos estables, evite depender de un servicio no controlado y conserve vídeo o capturas como respaldo. Explique también un fallo encontrado y su resolución: suele revelar más criterio que una sucesión de pantallas perfectas.

Vea DAM si el núcleo es una aplicación multiplataforma y ASIR si predomina la infraestructura. El resto está en proyectos de FP.

Si necesita alinear la aplicación, las pruebas y la memoria, podemos estudiar un plan de ayuda para su proyecto final de DAW según los requisitos de su ciclo.