Memoria
Video ayuda
Hay algunos fallos de sonido al principio pero que no afentan a la explicación.
Índice propuesto de la memoria del proyecto
1. Introducción
1.1. Descripción del proyecto
1.2. Departamento asignado
1.3. Objetivo de la aplicación
2. Análisis y diseño
2.1. Requisitos funcionales
2.2. Requisitos no funcionales
2.3. Casos de uso
2.4. Modelo entidad-relación
2.5. Modelo relacional
2.6. Diagramas de secuencia
3. Arquitectura del sistema
3.1. Estructura general del sistema
3.2. Reverse proxy
3.3. Autenticación y sesiones
3.4. Comunicación entre servicios
3.5. Contenedores Docker utilizados
4. Desarrollo
4.1. Backends
4.1.1. Backend Java
4.1.2. Backend Python
4.1.3. Backend PHP
4.2. Bases de datos
4.3. Interfaces
4.4. Automatizaciones
5. Pruebas
5.1. Test unitarios
5.2. Pruebas de integración
5.3. Pruebas manuales
5.4. Errores detectados y correcciones realizadas
6. Sesiones de trabajo
6.1. Sesión 1: ../../.. (fecha)
6.2. Sesión 2: ../../..
6.3. Sesión 3: ../../..
6.x ...
7. Conclusiones
7.1. Resultado final
7.2. Dificultades encontradas
7.3. Mejoras futuras
8. Anexos
8.1. Capturas de pantalla
8.2. Scripts SQL
8.3. Configuración Docker
8.4. Configuración del reverse proxy
8.5. Repositorio Git
Explicación breve de cada apartado
1. Introducción
Sirve para presentar el proyecto de forma general. Aquí se explica qué se está construyendo, qué departamento ha tocado al grupo y cuál es la finalidad principal de la aplicación.
1.1. Descripción del proyecto
Debe explicar en pocas líneas en qué consiste el proyecto completo: una plataforma formada por varios servicios y departamentos, con acceso mediante reverse proxy, autenticación centralizada y aplicaciones desarrolladas con distintas tecnologías.
1.2. Departamento asignado
Debe indicar qué departamento desarrolla el grupo y qué función tiene dentro del sistema general. Por ejemplo: recursos humanos, eventos, mantenimiento, formación, logística, etc.
1.3. Objetivo de la aplicación
Debe explicar para qué sirve la aplicación concreta del grupo. No basta con decir “gestionar datos”; hay que indicar qué problema resuelve y qué usuarios la utilizarán.
2. Análisis y diseño
Este apartado recoge la planificación previa al desarrollo. Debe demostrar que la aplicación se ha pensado antes de programarla.
2.1. Requisitos funcionales
Son las funciones que debe realizar la aplicación. Por ejemplo: crear registros, consultar información, modificar datos, eliminar elementos, filtrar resultados o generar avisos.
2.2. Requisitos no funcionales
Son condiciones de calidad o funcionamiento. Por ejemplo: seguridad, facilidad de uso, organización del código, rendimiento básico, uso de Docker o integración con el sistema común.
2.3. Casos de uso
Deben mostrar qué puede hacer cada tipo de usuario dentro de la aplicación. Pueden presentarse mediante una lista, una tabla o un diagrama.
2.4. Modelo entidad-relación
Debe incluir el diseño conceptual de la base de datos. Aparecen las entidades principales, sus atributos y las relaciones entre ellas.
2.5. Modelo relacional
Debe mostrar cómo se transforma el modelo entidad-relación en tablas reales. Deben aparecer tablas, claves primarias, claves ajenas y relaciones.
2.6. Diagramas de secuencia
Deben representar el orden de comunicación entre usuario, interfaz, backend, base de datos y otros servicios. Por ejemplo, el proceso de crear un registro o consultar información.
3. Arquitectura del sistema
Explica cómo está montado técnicamente el proyecto y cómo se comunican sus partes.
3.1. Estructura general del sistema
Debe incluir una visión global del sistema: usuario, reverse proxy, servicios backend, bases de datos y aplicaciones de cada departamento.
3.2. Reverse proxy
Debe explicar qué papel tiene el reverse proxy en el proyecto. También debe indicar qué rutas o dominios se han usado para acceder a la aplicación.
3.3. Autenticación y sesiones
Debe explicar cómo se identifica el usuario y cómo la aplicación recibe la información de sesión. Si se usan cabeceras como X-User-Id, X-Username o X-Role, deben mencionarse.
3.4. Comunicación entre servicios
Debe indicar cómo se comunican las distintas partes: navegador, proxy, backend, base de datos, APIs internas o automatizaciones.
3.5. Contenedores Docker utilizados
Debe listar los contenedores necesarios para que funcione la aplicación y explicar brevemente para qué sirve cada uno.
4. Desarrollo
Describe qué se ha programado y cómo se ha organizado el código.
4.1. Backends
Debe explicar qué partes del proyecto se han desarrollado en backend y qué responsabilidad tiene cada una.
4.1.1. Backend Java
Debe describir las funcionalidades desarrolladas en Java, si el grupo lo ha utilizado. Se pueden mencionar servlets, controladores, conexión con base de datos o generación de respuestas.
4.1.2. Backend Python
Debe explicar las partes realizadas en Python, especialmente si se usa Flask para autenticación, sesiones, rutas o APIs.
4.1.3. Backend PHP
Debe describir las páginas o funcionalidades implementadas en PHP, si forman parte del departamento asignado.
4.2. Bases de datos
Debe explicar qué tablas se han creado, qué información almacenan y cómo se relacionan. También puede incluir decisiones tomadas sobre claves, tipos de datos y restricciones.
4.3. Interfaces
Debe mostrar las pantallas principales de la aplicación y explicar qué puede hacer el usuario en cada una.
4.4. Automatizaciones
Debe explicar las automatizaciones realizadas, si existen. Por ejemplo, flujos con n8n, envío de correos, generación de avisos o integración con otros servicios.
5. Pruebas
Este apartado demuestra que la aplicación se ha comprobado y no solo se ha programado.
5.1. Test unitarios
Deben incluir pruebas sobre funciones concretas del código. Por ejemplo, validar datos, comprobar cálculos, probar funciones auxiliares o verificar respuestas esperadas.
5.2. Pruebas de integración
Deben comprobar que varias partes funcionan juntas. Por ejemplo: interfaz con backend, backend con base de datos, o aplicación con reverse proxy.
5.3. Pruebas manuales
Deben recoger pruebas realizadas usando la aplicación como usuario. Se puede incluir una tabla con acción realizada, resultado esperado y resultado obtenido.
5.4. Errores detectados y correcciones realizadas
Debe incluir problemas encontrados durante el desarrollo y cómo se solucionaron. Esto da valor a la memoria porque demuestra trabajo real.
6. Sesiones de trabajo
Recoge el seguimiento del trabajo realizado durante el proyecto (incluyendo el panel Planka)
6.1. Sesión 1
Debe indicar qué se hizo ese día, qué decisiones se tomaron, qué problemas aparecieron y qué tareas quedaron pendientes.
6.2. Sesión 2
Debe seguir la misma estructura: trabajo realizado, avances, dificultades y próximos pasos.
6.3. Sesión 3
Debe continuar el registro del trabajo, incluyendo capturas o evidencias si son necesarias.
...
7. Conclusiones
Resume el resultado del trabajo y valora el proceso seguido.
7.1. Resultado final
Debe explicar qué se ha conseguido entregar y qué funcionalidades están operativas.
7.2. Dificultades encontradas
Debe recoger los principales problemas técnicos u organizativos encontrados durante el proyecto.
7.3. Mejoras futuras
Debe indicar qué se podría mejorar si se continuara el desarrollo: nuevas funciones, mejor interfaz, más seguridad, más pruebas o mejor documentación.
8. Anexos
Incluye material de apoyo que no encaja bien en el cuerpo principal de la memoria.
8.1. Capturas de pantalla
Deben incluir imágenes de las pantallas principales, pruebas realizadas, contenedores funcionando o configuración relevante.
8.2. Scripts SQL
Debe incluir el código SQL necesario para crear tablas, relaciones, datos iniciales o consultas importantes.
8.3. Configuración Docker
Debe incluir archivos o fragmentos relevantes de Docker, como docker-compose.yml, variables de entorno o comandos usados.
8.4. Configuración del reverse proxy
Debe incluir capturas o explicación de las rutas configuradas, servicios internos y puertos utilizados.
8.5. Repositorio Git
Debe indicar el repositorio utilizado, ramas principales y forma de organizar el trabajo.