Carpeta TFI
CEMI Sistema Gestor
Centro Municipal de Idiomas
Versión 1.0 - Mayo 2026UTN Facultad Regional Tucumán - Tecnicatura Superior en Programación
1. Carátula y datos del proyecto
| Campo | Detalle |
|---|---|
| Título del sistema | CEMI Sistema Gestor |
| Entidad destinataria | CEMI - Centro Municipal de Idiomas |
| Institución académica | UTN Facultad Regional Tucumán |
| Carrera | Tecnicatura Superior en Programación |
| Tutor académico | Ing. Prado |
| Autores / integrantes | Gómez Micaela, Lucena Carlos, Ruiz Mendoza Eduardo y Sergio Bautista Bareiro |
| Fecha de presentación | Mayo 2026 |
| Repositorio | CEMIPlatform |
| Producción | https://cemi.up.railway.app |
| Documento | Carpeta del Trabajo Final Integrador |
2. Índice documental
La carpeta se organiza siguiendo el orden del documento modelo: resumen ejecutivo, introducción, estado del arte, descripción del proyecto, metodología, recursos, plan de trabajo, resultados, referencias y anexo. La diferencia principal es que cada apartado fue ajustado al dominio real de CEMI, evitando funciones comerciales que no forman parte del sistema.
| Sección | Contenido |
|---|---|
| Resumen ejecutivo | Descripción, objetivos, metodología, resultados y conclusiones generales. |
| Introducción | Contexto, justificación, objetivo general y objetivos específicos. |
| Estado del arte | Sistemas actuales, enfoques tecnológicos, normalización, seguridad y aporte del proyecto. |
| Descripción del proyecto | Problemática, solución, alcance, análisis, diagramas, historias, reglas, requisitos y restricciones. |
| Metodología | SCRUM, herramientas, arquitectura, base de datos, pruebas, integración e implantación. |
| Recursos y plan | Roles, recursos, sprints, calendarización, Gantt, etapas y entregables. |
| Cierre | Resultados esperados, impacto académico, institucional, referencias y anexos. |
3. Resumen ejecutivo
3.1 Breve descripción del proyecto
El presente Trabajo Final Integrador consiste en el diseño, desarrollo, documentación y despliegue de CEMI Sistema Gestor, una aplicación web destinada al Centro Municipal de Idiomas. La solución centraliza procesos académicos, administrativos, financieros y comunicacionales en una arquitectura cliente-servidor con persistencia real.
El sistema permite gestionar alumnos, profesores, administradores, cursos, idiomas, niveles, aulas, inscripciones, pagos, calificaciones, asistencias, tareas, entregas, anuncios, encuestas, recursos, calendario, chat, notificaciones y documentación. También incorpora páginas públicas, perfiles diferenciados, autenticación, recuperación de contraseña y mecanismos de privacidad.
3.2 Objetivos principales
El objetivo general del proyecto es desarrollar un sistema informático que permita digitalizar la gestión integral del Centro Municipal de Idiomas, reduciendo registros dispersos y mejorando la trazabilidad de operaciones académicas y administrativas.
- Diseñar una base de datos relacional normalizada para entidades educativas y administrativas.
- Implementar operaciones CRUD sobre alumnos, profesores, cursos, aulas, idiomas y niveles.
- Registrar inscripciones, pagos, conceptos, estados y comprobantes.
- Incorporar classroom con tareas, entregas, anuncios, recursos, encuestas y calendario.
- Aplicar control de acceso mediante perfiles, JWT y contraseñas cifradas.
- Publicar el sistema en un entorno web accesible y verificable.
3.3 Metodología utilizada
El proyecto fue desarrollado con una metodología ágil basada en sprints, integrando relevamiento, diseño, desarrollo, pruebas, documentación y despliegue. Cada sprint permitió cerrar un conjunto de funcionalidades y validar su integración con el resto del sistema.
- Relevamiento y análisis de requerimientos.
- Diseño del modelo de datos y arquitectura del sistema.
- Implementación del backend y frontend.
- Integración de módulos administrativos, académicos y comunicacionales.
- Pruebas funcionales, revisión de seguridad y validación de despliegue.
- Elaboración de documentación técnica, carpeta TFI, anexo y manual de usuario.
3.4 Resultados esperados
- Sistema web funcional para la administración de CEMI.
- Base de datos persistente, relacional y coherente con el dominio educativo.
- Acceso diferenciado para administradores, profesores, alumnos e invitados.
- Gestión ordenada de cursos, inscripciones, pagos, calificaciones y asistencias.
- Classroom institucional integrado al sistema principal.
- Documentación formal disponible desde la sección Documentación.
3.5 Conclusiones generales
CEMI Sistema Gestor demuestra la capacidad de diseñar e implementar una solución web completa, con base de datos, backend, frontend, seguridad, documentación y despliegue. El proyecto integra conocimientos adquiridos durante la carrera y los aplica sobre una problemática institucional real: la necesidad de centralizar la gestión académica y administrativa del Centro Municipal de Idiomas.
4. Introducción
4.1 Contexto y antecedentes
La digitalización de instituciones educativas se volvió una necesidad central para mejorar la organización interna y la calidad de atención. En un centro de idiomas conviven datos personales, inscripciones, cursos, horarios, profesores, pagos, calificaciones, asistencias y comunicaciones. Cuando estos procesos se gestionan de manera fragmentada, se incrementa el riesgo de errores, duplicación de información y demoras en la consulta de datos.
CEMI requiere una herramienta propia que permita operar de forma ordenada, con usuarios diferenciados y trazabilidad. A diferencia de plataformas genéricas, el sistema propuesto responde al funcionamiento específico de un Centro Municipal de Idiomas y a los módulos desarrollados dentro del proyecto.
4.2 Justificación
La implementación de CEMI Sistema Gestor responde a la necesidad de centralizar información académica, administrativa y financiera en una única plataforma web. Desde la perspectiva académica, el proyecto permite aplicar programación estructurada, diseño de base de datos, arquitectura cliente-servidor, seguridad web, metodología ágil, pruebas e integración continua.
- Permite resolver una problemática real mediante una solución funcional.
- Favorece el aprendizaje aplicado de arquitectura web y bases de datos.
- Integra diseño de interfaz, backend, persistencia y despliegue.
- Genera documentación formal para evaluación y mantenimiento.
4.3 Objetivo general
Implementar un sistema web integral para el Centro Municipal de Idiomas, destinado a digitalizar, centralizar y optimizar procesos académicos, administrativos, financieros y comunicacionales, garantizando trazabilidad, seguridad, disponibilidad y facilidad de uso.
4.4 Objetivos específicos
- Digitalizar la gestión de alumnos, profesores, cursos, idiomas, niveles y aulas.
- Optimizar el control de inscripciones y cupos por curso.
- Automatizar el registro de pagos, conceptos, estados y comprobantes.
- Incorporar un entorno classroom para tareas, entregas, anuncios, recursos y calendario.
- Implementar roles y permisos para administradores, profesores, alumnos e invitados.
- Generar una interfaz clara, responsive y alineada con la identidad de CEMI.
- Asegurar escalabilidad para futuras funciones institucionales.
5. Estado del arte
5.1 Contexto tecnológico actual
En la actualidad existen múltiples soluciones para gestión educativa y comunicación académica. Plataformas como aulas virtuales, sistemas administrativos SaaS y hojas de cálculo compartidas cubren partes del proceso, pero suelen requerir configuración compleja, pagos recurrentes o integraciones externas. Para una institución municipal, una solución web propia permite mayor control del flujo de información y una adaptación más directa al funcionamiento local.
5.2 Sistemas existentes y comparativa
| Tipo de sistema | Fortalezas | Limitaciones frente a CEMI |
|---|---|---|
| Aulas virtuales genéricas | Tareas, recursos y comunicación académica. | No cubren por completo pagos, inscripciones, usuarios institucionales y reportes propios. |
| Sistemas administrativos SaaS | Acceso web y mantenimiento externo. | Costos recurrentes, menor control del código y adaptación limitada. |
| Planillas y registros manuales | Bajo costo inicial y familiaridad. | Duplicidad de datos, baja trazabilidad, errores de carga y dificultad para auditar cambios. |
| Sistema web modular propio | Control del código, datos centralizados, módulos a medida y despliegue propio. | Requiere desarrollo, pruebas, mantenimiento y capacitación inicial. |
5.3 Enfoques tecnológicos actuales
SaaS educativo
Permite acceso remoto y actualizaciones externas, pero puede limitar personalización y generar dependencia del proveedor.
Escritorio local
Funciona en una PC específica, aunque dificulta el acceso distribuido y el trabajo entre perfiles.
Aplicación web modular
Separa frontend, backend y base de datos. Favorece escalabilidad, mantenimiento y acceso desde navegadores modernos.
5.4 Modelado de datos y normalización
La base de datos relacional continúa siendo adecuada para sistemas con reglas claras de integridad. CEMI requiere relacionar personas, usuarios, perfiles, alumnos, profesores, cursos, inscripciones, pagos, asistencias, calificaciones, tareas y chats. La normalización reduce redundancia, evita inconsistencias y permite consultas confiables para reportes institucionales.
5.5 Seguridad y control de acceso en aplicaciones web
El sistema utiliza autenticación mediante JSON Web Token, contraseñas cifradas y middleware de verificación para proteger rutas privadas. La separación por perfiles evita que alumnos o profesores accedan a funciones administrativas. También se contemplan recuperación de contraseña, variables de entorno protegidas, cabeceras de seguridad y validación de datos.
5.6 Fundamentación del aporte del proyecto
- Integra gestión administrativa y classroom en una única plataforma.
- Aplica arquitectura cliente-servidor con Node.js, Express y MySQL.
- Incluye autenticación, roles, chat en tiempo real y documentación navegable.
- Permite evaluar el sistema desde producción mediante Railway.
- Genera una base técnica escalable para futuras necesidades institucionales.
5.7 Conclusión del estado del arte
El análisis demuestra que existen soluciones parciales para administración educativa, comunicación y aula virtual, pero CEMI requiere una herramienta integrada y adaptada a su realidad. El proyecto aporta una solución académica, funcional y documentada que combina conocimientos de desarrollo web, modelado de datos, seguridad, experiencia de usuario y despliegue.
6. Descripción del proyecto
6.1 Problemática detectada
La problemática principal es la dispersión de información institucional. Sin un sistema unificado, la administración debe consultar distintos registros para conocer alumnos activos, cursos, pagos, profesores, horarios, calificaciones y comunicaciones. Esto impacta en la calidad de atención, aumenta la carga manual y reduce la capacidad de seguimiento.
- Dificultad para consultar datos completos de alumnos y profesores.
- Riesgo de duplicidad o pérdida de información en inscripciones.
- Seguimiento poco integrado de pagos, cuotas y comprobantes.
- Comunicación fragmentada entre administración, docentes y alumnos.
- Necesidad de un classroom institucional vinculado a cursos reales.
6.2 Solución propuesta
La solución propuesta es CEMI Sistema Gestor, una aplicación web modular con persistencia en MySQL, backend Express, frontend HTML/CSS/JavaScript y comunicación en tiempo real mediante Socket.IO. La plataforma organiza sus funciones por rol y por dominio: administración, alumnos, profesores, cursos, pagos, classroom, chat, comunidad, seguridad y documentación.
- Gestión de usuarios, perfiles y accesos.
- Gestión de alumnos, profesores y administradores.
- Gestión de cursos, idiomas, niveles, aulas, horarios y cupos.
- Inscripciones, pagos, comprobantes y registros administrativos.
- Classroom con tareas, entregas, anuncios, recursos, encuestas y calendario.
- Chat de soporte, chat académico, notificaciones y comunidad.
6.3 Alcance del proyecto
| Incluye | No incluye en esta versión |
|---|---|
| Registro y administración de alumnos, profesores, administradores y usuarios. | Facturación fiscal externa automatizada. |
| Cursos, idiomas, niveles, aulas, horarios, cupos e inscripciones. | Aplicación móvil nativa independiente. |
| Pagos, conceptos, cuotas, estados y comprobantes PDF. | Firma digital oficial de certificados. |
| Classroom, tareas, entregas, anuncios, recursos, encuestas y calendario. | Conciliación bancaria automática con entidades externas. |
| Chat, notificaciones, comunidad, privacidad, seguridad y documentación. | Integración con sistemas provinciales o nacionales de educación. |
6.4 Análisis del mercado
El mercado ofrece herramientas educativas y administrativas, pero muchas se orientan a instituciones grandes, requieren suscripción o no se ajustan al funcionamiento específico de un Centro Municipal de Idiomas. CEMI Sistema Gestor se plantea como una alternativa propia, accesible y extensible, con módulos desarrollados según el relevamiento del proyecto y con documentación técnica para sostener su mantenimiento.
6.5 Diagrama entidad-relación detallado
El modelo lógico se organiza alrededor de PERSONA y USUARIO. Desde esa base se especializan alumnos, profesores y administradores. CURSO articula idioma, nivel, aula, profesor, inscripciones, pagos, asistencias, calificaciones y classroom. CHAT y NOTIFICACION completan la trazabilidad comunicacional.
PERSONA
- id_persona PK
- nombre
- apellido
- dni
USUARIO
- id_usuario PK
- id_persona FK
- id_perfil FK
- password_hash
- estado
PERFIL
- id_perfil PK
- nombre_perfil
- permisos
ALUMNO
- id_alumno PK
- id_persona FK
- legajo
- estado
PROFESOR
- id_profesor PK
- id_persona FK
- especialidad
- estado
CURSO
- id_curso PK
- id_idioma FK
- id_nivel FK
- id_profesor FK
- cupo_maximo
INSCRIPCION
- id_inscripcion PK
- id_alumno FK
- id_curso FK
- estado
PAGO
- id_pago PK
- id_alumno FK
- id_curso FK
- monto
- estado_pago
CALIFICACION
- id_calificacion PK
- id_alumno FK
- id_curso FK
- parcial1
- final
ASISTENCIA
- id_asistencia PK
- id_curso FK
- id_alumno FK
- fecha
- estado
TAREA / ENTREGA
- id_tarea PK
- id_curso FK
- id_profesor FK
- fecha_limite
- id_entrega
CHAT
- id_conversacion PK
- id_usuario FK
- estado
- mensaje
Una persona puede tener credenciales de acceso y un perfil asignado.
La relación se resuelve mediante INSCRIPCION.
Los pagos se asocian al alumno, curso, concepto y medio utilizado.
Tareas, recursos, anuncios y entregas se vinculan con cursos existentes.
6.6 Historias de usuario
| HU | Historia | Criterios de aceptación | Prioridad |
|---|---|---|---|
| HU01 | Como administrador, quiero registrar alumnos para mantener actualizado el padrón institucional. | Valida datos obligatorios, evita duplicados y guarda estado del alumno. | Alta |
| HU02 | Como administrador, quiero registrar profesores para asignarlos a cursos. | Permite especialidad, estado, usuario asociado y consulta posterior. | Alta |
| HU03 | Como administrador, quiero crear cursos por idioma y nivel. | Solicita profesor, aula, horario, cupo y estado del curso. | Alta |
| HU04 | Como administrador, quiero inscribir alumnos en cursos activos. | Verifica alumno, curso, cupo disponible y estado de inscripción. | Alta |
| HU05 | Como administrador, quiero registrar pagos y generar comprobantes. | Guarda monto, concepto, medio, estado y comprobante PDF. | Alta |
| HU06 | Como profesor, quiero publicar tareas y recursos para mi curso. | Asocia publicaciones al curso y permite entregas de alumnos. | Alta |
| HU07 | Como profesor, quiero registrar calificaciones y asistencias. | Persiste datos por alumno, curso y fecha. | Alta |
| HU08 | Como alumno, quiero consultar cursos, pagos, tareas y calificaciones. | Muestra solo información propia y protegida por sesión. | Alta |
6.7 Reglas de negocio
| Área | Reglas |
|---|---|
| Alumnos e inscripciones | Un alumno debe existir antes de inscribirse. Una inscripción debe asociarse a un curso activo. No debe superarse el cupo definido. |
| Cursos | Todo curso debe tener idioma, nivel, profesor, aula, horario y estado. Los cursos inactivos no deben recibir nuevas inscripciones. |
| Pagos | Todo pago debe asociarse a alumno, curso, concepto, medio de pago y estado. Los comprobantes deben conservar trazabilidad. |
| Usuarios y roles | Un usuario opera únicamente las funciones permitidas por su perfil. Las operaciones sensibles requieren sesión válida. |
| Classroom | Las tareas, anuncios, recursos y entregas deben vincularse a cursos existentes y a usuarios autorizados. |
| Comunicación | Los chats y notificaciones deben conservar estado, emisor, destinatario y fecha para seguimiento institucional. |
6.8 Requisitos específicos
| Código | Requisito funcional | Prioridad |
|---|---|---|
| RF01 | Registrar, modificar, consultar e inactivar alumnos. | Alta |
| RF02 | Registrar, modificar y consultar profesores. | Alta |
| RF03 | Gestionar cursos, idiomas, niveles, aulas, horarios y cupos. | Alta |
| RF04 | Registrar inscripciones de alumnos a cursos. | Alta |
| RF05 | Registrar pagos con medio, concepto, estado y comprobante. | Alta |
| RF06 | Registrar calificaciones parciales y finales. | Alta |
| RF07 | Registrar asistencias por curso y fecha. | Alta |
| RF08 | Gestionar classroom con tareas, entregas, anuncios, encuestas y recursos. | Alta |
| RF09 | Implementar chat de soporte y comunicación académica. | Media |
| RF10 | Gestionar seguridad, recuperación de cuenta, privacidad y notificaciones. | Media |
| Código | Requisito no funcional |
|---|---|
| RNF01 | El sistema debe estar disponible desde navegadores modernos. |
| RNF02 | La interfaz debe ser responsive para escritorio, tablet y móvil. |
| RNF03 | La autenticación debe utilizar JWT y contraseñas cifradas. |
| RNF04 | La base de datos debe mantener integridad referencial. |
| RNF05 | Las operaciones principales deben responder en tiempos adecuados para uso administrativo. |
| RNF06 | El chat debe permitir comunicación en tiempo real. |
| RNF07 | El despliegue debe usar variables de entorno protegidas. |
| RNF08 | La documentación debe estar disponible desde el sistema. |
| RNF09 | El sistema debe contemplar seguridad y privacidad de datos personales. |
6.9 Matriz de trazabilidad
| Historia de usuario | Regla de negocio | Requisito funcional |
|---|---|---|
| HU01 | Alumnos e inscripciones | RF01 |
| HU02 | Usuarios y roles | RF02 |
| HU03 | Cursos | RF03 |
| HU04 | Alumnos e inscripciones | RF04 |
| HU05 | Pagos | RF05 |
| HU06 | Classroom | RF08 |
| HU07 | Classroom | RF06 - RF07 |
| HU08 | Usuarios y roles | RF05 - RF08 - RF10 |
6.10 Restricciones y limitaciones
- Requiere conexión a Internet y disponibilidad del servidor de producción.
- Requiere navegador moderno compatible con JavaScript.
- La seguridad depende de la correcta configuración de variables de entorno.
- Los datos iniciales deben ser cargados y validados por usuarios autorizados.
- La capacitación inicial es necesaria para administración, profesores y alumnos.
6.11 Mejoras a futuro
- Certificados digitales y constancias académicas.
- Reportes analíticos avanzados exportables.
- Conciliación bancaria o integración con medios de pago externos.
- Aplicación móvil nativa.
- Firma digital institucional.
- Gestión avanzada de becas, descuentos y planes de pago.
6.12 Modelo entidad-relación físico
El modelo físico conserva claves primarias y foráneas para sostener integridad. Las entidades principales se agrupan por identidad, gestión académica, gestión financiera, classroom y comunicación.
| Grupo | Tablas principales | Relaciones destacadas |
|---|---|---|
| Identidad | personas, usuarios, perfiles, administradores | usuarios.id_persona, usuarios.id_perfil |
| Académico | alumnos, profesores, idiomas, niveles, aulas, cursos, inscripciones | cursos.id_profesor, inscripciones.id_alumno, inscripciones.id_curso |
| Financiero | pagos, medios_pago, registros_pagos | pagos.id_alumno, pagos.id_curso, pagos.id_medio_pago |
| Seguimiento | calificaciones, asistencias | calificaciones.id_alumno, asistencias.id_curso |
| Classroom | tareas, entregas, anuncios, encuestas, recursos, eventos | contenido asociado a cursos, profesores y alumnos |
| Comunicación | chats, mensajes, notificaciones | mensajes asociados a conversaciones y usuarios |
7. Metodología
7.1 Enfoque metodológico
Para el desarrollo del Trabajo Final Integrador se adoptó una metodología ágil basada en SCRUM, organizada en ciclos iterativos e incrementales. Este enfoque permitió dividir el proyecto en bloques funcionales, revisar avances y ajustar prioridades según el avance del sistema.
- Relevamiento y análisis de requerimientos.
- Modelado del sistema y diseño de base de datos.
- Implementación de funcionalidades principales.
- Pruebas funcionales y validación de reglas de negocio.
- Documentación técnica y elaboración de la carpeta de presentación.
7.2 Técnicas y herramientas utilizadas
7.2.1 Modelado del sistema
- Modelo entidad-relación para diseño de datos.
- Normalización hasta Tercera Forma Normal cuando corresponde.
- Separación de responsabilidades por capas.
- Definición de flujos por perfil de usuario.
7.2.2 Tecnologías implementadas
| Área | Tecnologías | Uso |
|---|---|---|
| Backend | Node.js, Express, MySQL2, JWT, bcryptjs, Socket.IO | API REST, seguridad, persistencia y comunicación en tiempo real. |
| Frontend | HTML5, CSS3, JavaScript, Lucide Icons | Pantallas públicas, dashboards, classroom, seguridad y documentación. |
| Base de datos | MySQL | Persistencia relacional, integridad y consultas. |
| Servicios | Railway, Cloudinary, SendGrid/Nodemailer | Deploy, almacenamiento de archivos y correo. |
| Herramientas | Git, GitHub, Visual Studio Code, Postman | Versionado, desarrollo y prueba de endpoints. |
7.3 Diseño del sistema y arquitectura
Frontend
HTML, CSS y JavaScript. Contiene landing, login, paneles, classroom, comunidad, seguridad, manuales y documentación.
Backend
Express organiza rutas, middlewares, validaciones, controladores y servicios por dominio funcional.
Base de datos
MySQL persiste entidades académicas, administrativas, financieras y comunicacionales.
7.4 Desarrollo e implementación
El desarrollo se realizó de manera progresiva. Primero se estableció la estructura del proyecto y la conexión con base de datos. Luego se implementaron autenticación, usuarios, alumnos, profesores, cursos e inscripciones. Posteriormente se incorporaron pagos, classroom, chat, notificaciones, seguridad y documentación.
La implementación respetó separación entre rutas de API, utilidades, middleware, recursos estáticos y archivos frontend. Esta organización facilita el mantenimiento y permite agregar nuevos módulos sin modificar todo el sistema.
7.5 Base de datos
La base MySQL fue elegida por su estabilidad, disponibilidad y compatibilidad con Node.js. Se definieron tablas con identificadores únicos, claves foráneas y campos de estado para permitir altas, consultas, modificaciones, bajas lógicas y trazabilidad.
- Tablas de identidad: personas, usuarios, perfiles y administradores.
- Tablas académicas: alumnos, profesores, cursos, idiomas, niveles, aulas e inscripciones.
- Tablas financieras: pagos, medios de pago y registros de pago.
- Tablas de seguimiento: calificaciones y asistencias.
- Tablas de classroom y comunicación: tareas, entregas, anuncios, recursos, chat y notificaciones.
7.6 Gestión de versiones y colaboración
Durante el desarrollo se utilizó Git para control de versiones y GitHub como repositorio remoto. Esta práctica permitió conservar historial, documentar cambios y desplegar automáticamente hacia producción. Visual Studio Code se utilizó como entorno principal de desarrollo.
7.7 Pruebas e integración
Las pruebas se orientaron a validar navegación, autenticación, rutas protegidas, persistencia de datos, formularios, comprobantes, classroom, chat, documentación y despliegue. También se verificaron sintaxis del servidor, presencia de recursos, enlaces internos y ausencia de referencias heredadas de documentos no pertinentes.
7.8 Implantación y capacitación
La implantación se realiza en Railway, con variables de entorno y base de datos configurada para producción. La capacitación propuesta se organiza por rol: administración aprende usuarios, alumnos, cursos, inscripciones, pagos y soporte; profesores aprenden classroom, calificaciones, asistencias y chat; alumnos aprenden acceso, pagos, tareas, entregas y consultas.
8. Recursos necesarios
8.1 Recursos humanos
- Analista funcional: relevamiento, reglas de negocio y documentación.
- Desarrollador backend: rutas, controladores, seguridad, lógica y conexión con base de datos.
- Desarrollador frontend: interfaz, navegación, formularios, dashboards y experiencia de usuario.
- Diseñador de base de datos: modelado, normalización, relaciones y consultas.
- Responsable de documentación: carpeta TFI, anexo, manuales y validación final.
8.2 Recursos materiales
- Computadoras personales y conexión a Internet.
- Navegadores modernos para pruebas.
- Entorno de desarrollo Visual Studio Code.
- Node.js, npm, MySQL y Git.
- Servicios de despliegue, almacenamiento y correo.
- Repositorio GitHub para control de versiones.
8.3 Descripción del equipo de trabajo
| Integrante | Roles | Responsabilidades |
|---|---|---|
| Gómez Micaela | Frontend / UI Design / Documentación | Diseño visual, pantallas, navegación, validaciones, estructura documental y revisión de experiencia de usuario. |
| Lucena Carlos | Backend / Base de datos | Rutas, controladores, lógica de negocio, consultas SQL, consistencia de datos y soporte de integración. |
| Ruiz Mendoza Eduardo | Backend / DevOps / Integración | Configuración, despliegue, servicios externos, seguridad, conexión de módulos y validación en producción. |
| Sergio Bautista Bareiro | Frontend / QA Testing / Documentación | Interfaces, pruebas funcionales, revisión de flujos, ajustes visuales y apoyo documental. |
9. Plan de trabajo
9.1 Versión descriptiva
El Trabajo Final Integrador se organizó en tres sprints principales. El primero se concentró en análisis, diseño y estructura; el segundo en módulos principales; y el tercero en integración, pruebas, documentación y despliegue.
Primer sprint: 23/09/2025 al 13/10/2025
| Área | Proceso | Descripción | Tiempo |
|---|---|---|---|
| Análisis | Relevamiento | Entrevistas, definición de necesidades y reglas iniciales. | 8 horas |
| Base de datos | Modelo inicial | Diseño de entidades, relaciones y estructura MySQL. | 8 horas |
| Frontend | Interfaz base | Estructura HTML/CSS, navegación inicial y pantallas públicas. | 7 horas |
| Backend | Servidor inicial | Express, conexión, rutas base y middleware. | 7 horas |
| Seguridad | Autenticación | Login, JWT, perfiles y protección de rutas. | 6 horas |
Segundo sprint: 14/10/2025 al 10/11/2025
| Área | Proceso | Descripción | Tiempo |
|---|---|---|---|
| Backend | Gestión académica | Alumnos, profesores, cursos, aulas, idiomas e inscripciones. | 10 horas |
| Frontend | Panel administrativo | Formularios, listados, edición y validaciones visuales. | 8 horas |
| Financiero | Pagos | Conceptos, estados, medios de pago y comprobantes. | 8 horas |
| Classroom | Entorno académico | Tareas, entregas, anuncios, recursos, calendario y encuestas. | 8 horas |
| Comunicación | Chat y notificaciones | Soporte, conversación académica y eventos del sistema. | 7 horas |
Tercer sprint: 11/11/2025 al 20/11/2025
| Área | Proceso | Descripción | Tiempo |
|---|---|---|---|
| Seguridad | Privacidad y recuperación | Páginas de seguridad, recuperación de cuenta y protección de datos. | 6 horas |
| Pruebas | Integración | Validación de flujos, rutas, navegación y persistencia. | 7 horas |
| Documentación | TFI | Anexo, carpeta, manual de usuario, diagramas y referencias. | 7 horas |
| Deploy | Producción | Railway, variables de entorno, verificación pública y correcciones finales. | 5 horas |
Primer sprint: análisis, diseño y base técnica.
Segundo sprint: módulos principales.
Tercer sprint: pruebas, documentación y despliegue.
Total estimado: 95 horas.
9.2 Calendarización de actividades
| Actividad | Inicio | Fin | Duración | Responsable |
|---|---|---|---|---|
| Relevamiento y análisis | 23/09/2025 | 26/09/2025 | 4 días | Equipo completo |
| Diseño de base de datos | 29/09/2025 | 03/10/2025 | 5 días | Lucena Carlos |
| Interfaz y login | 06/10/2025 | 13/10/2025 | 8 días | Gómez Micaela / Sergio Bautista Bareiro |
| Backend inicial | 14/10/2025 | 20/10/2025 | 7 días | Ruiz Mendoza Eduardo / Lucena Carlos |
| Módulos académicos | 21/10/2025 | 31/10/2025 | 11 días | Equipo completo |
| Pagos y comprobantes | 03/11/2025 | 07/11/2025 | 5 días | Equipo completo |
| Classroom y comunicación | 10/11/2025 | 14/11/2025 | 5 días | Equipo completo |
| Pruebas, documentación y deploy | 17/11/2025 | 20/11/2025 | 4 días | Equipo completo |
9.3 Diagrama de Gantt
| Actividad | 23/9 | 29/9 | 6/10 | 14/10 | 21/10 | 3/11 | 10/11 | 17/11 |
|---|---|---|---|---|---|---|---|---|
| Relevamiento y análisis | ● | |||||||
| Diseño de base de datos | ● | |||||||
| Interfaz y login | ● | |||||||
| Backend inicial | ● | |||||||
| Módulos académicos | ● | |||||||
| Pagos y comprobantes | ● | |||||||
| Classroom y comunicación | ● | |||||||
| Pruebas, documentación y deploy | ● |
9.4 Diagrama de Gantt completo
El Gantt completo consolida las actividades de los tres sprints y permite visualizar la secuencia de avance del proyecto: análisis, diseño, desarrollo base, módulos académicos, pagos, classroom, comunicación, seguridad, pruebas, documentación y despliegue.
9.5 Etapas y entregables
| Etapa | Actividades principales | Entregable |
|---|---|---|
| Análisis | Relevamiento, definición de requerimientos y reglas de negocio. | Documento de requerimientos y anexo. |
| Diseño | Modelo E/R, normalización, arquitectura y prototipos. | Diagrama E/R y estructura del sistema. |
| Backend | CRUD, autenticación, lógica de negocio y conexión MySQL. | API funcional. |
| Frontend | Pantallas, formularios, validaciones e integración con API. | Interfaz web completa. |
| Pruebas | Testing funcional, correcciones y validación final. | Sistema estable. |
| Documentación | Carpeta TFI, anexo, manual de usuario, manual técnico y revisión. | Carpeta final lista. |
10. Resultados esperados
10.1 Resultados y beneficios
CEMI Sistema Gestor permitirá digitalizar procesos institucionales, reducir la dependencia de registros dispersos y mejorar la disponibilidad de información. La centralización de datos facilita consultas administrativas, seguimiento académico, emisión de comprobantes y comunicación entre perfiles.
10.2 El desarrollo del sistema permitirá obtener los siguientes resultados
- Implementación de un sistema funcional de gestión integral.
- Persistencia real de datos mediante base relacional.
- Control de acceso seguro mediante autenticación y roles.
- Automatización de procesos académicos y administrativos.
- Classroom institucional integrado.
- Documento técnico formal acorde a estándares universitarios.
10.3 Impacto académico
- Integración interdisciplinaria de contenidos.
- Aplicación de metodologías ágiles.
- Desarrollo de competencias en arquitectura de software.
- Consolidación de habilidades en modelado de datos.
- Aplicación práctica de conocimientos adquiridos durante la carrera.
10.4 Impacto institucional
- Mejor organización de información académica y administrativa.
- Mayor trazabilidad de pagos, inscripciones y actividad académica.
- Mejora de comunicación entre administración, docentes y alumnos.
- Base tecnológica escalable para futuras ampliaciones.
11. Referencias
12. Anexo
Forman parte complementaria de esta carpeta: Anexo TFI, Manual de Usuario TFI, Manual Técnico, Diagramas UML, Plan de Pruebas, Arquitectura del Sistema, Bibliografía APA7 y Diagrama de Gantt. Estos documentos permiten auditar el proceso completo desde el relevamiento hasta el despliegue.