Sistema web transaccional para gestionar herramientas y materiales de Telecom Power Systems, mejorar la trazabilidad del inventario y registrar las operaciones asociadas a proyectos y personal técnico.
Important
TelecomTrack es el proyecto final del curso SC-403 Desarrollo de Aplicaciones Web y Patrones de la Universidad Fidélitas.
La implementación debe respetar las tecnologías, dependencias, estructura MVC y forma de codificación trabajadas durante el curso. Un cambio fuera de esos parámetros puede invalidar el avance correspondiente.
Telecom Power Systems administra herramientas y materiales mediante hojas de cálculo y registros manuales. Esto dificulta conocer las existencias reales, identificar responsables, controlar las asignaciones y consultar el historial de movimientos.
TelecomTrack busca centralizar ese proceso mediante una aplicación web con inventario, solicitudes, aprobaciones, devoluciones, proyectos, usuarios, roles y registros transaccionales.
Estado actual: desarrollo del Avance 2.
| Entrega | Estado |
|---|---|
| Avance 1 | Finalizado |
| Avance 2 | En desarrollo |
| Entrega final y defensa | Planificada |
El primer avance definió el problema, el cliente, los usuarios, las historias de usuario, los criterios de aceptación, la priorización del backlog, el flujo de navegación, el modelo preliminar de datos y el prototipo inicial.
La documentación de esta entrega se encuentra en docs/avance1/.
El segundo avance debe demostrar una implementación funcional del proyecto e incluir:
- Al menos el 50 % de las historias de usuario o los flujos de mayor prioridad completamente funcionales.
- Proyecto Java con Spring Boot organizado en
domain,repository,serviceycontroller. - Vistas dinámicas con Thymeleaf.
- Bootstrap incorporado según lo trabajado en clase.
- Persistencia mediante Hibernate/JPA y una base de datos relacional.
- CRUD de las entidades principales.
- Navegación coherente con el prototipo del Avance 1.
- Participación verificable de todos los integrantes mediante ramas, commits, revisiones y pull requests.
- Instrucciones preliminares de configuración y ejecución.
- Demostración del funcionamiento real del sistema.
La tercera entrega debe completar el alcance académico y técnico del proyecto:
- Aplicación web transaccional terminada.
- Base de datos con al menos ocho tablas y una tabla destinada a registrar transacciones.
- Autenticación, roles y restricciones de acceso funcionales.
- Internacionalización mediante archivos de idioma.
- Integración de al menos seis temas desarrollados en el curso.
- Una funcionalidad o tecnología adicional investigada por el equipo.
- Script, respaldo o instrucciones para crear y poblar la base de datos.
- Usuarios de prueba para los roles implementados.
- README técnico actualizado.
- Artículo científico en formato IEEE.
- Evidencia final de colaboración en GitHub.
- Presentación y demostración funcional durante la defensa.
Las responsabilidades se asignan y actualizan en cada avance según el backlog aprobado por el equipo.
| Integrante | GitHub | Responsabilidad actual |
|---|---|---|
| Allan Fauricio Fonseca Batista | @fauricio9656 | Issue #4 — Materiales y control de stock |
| Carlos Roberto Pérez Rodríguez | @ZerepSolrac412 | Issue #3 — Gestión de herramientas |
| Sebastián Segura Camacho | @SebastianSC11 | Issue #5 — Solicitudes e historial del técnico |
| Alberto Manuel Zúñiga Sánchez | @BetoxPrograming | Issues #1 y #2 — Configuración base, usuarios, autenticación y roles |
El trabajo del Avance 2 está organizado mediante el milestone Avance 2 — Implementación funcional del 50% y cinco issues asignados entre los integrantes.
La rama main contiene únicamente versiones estables y entregables. La rama develop se utiliza para integrar y probar el trabajo del equipo antes de actualizar main.
El flujo establecido es:
main
└── develop
├── chore/project-foundation
├── feature/hu-10-user-security
├── feature/tools-management
├── feature/materials-stock
└── feature/requests-history
Cada rama de trabajo debe crearse desde la versión más reciente de develop.
Al completar un issue:
- El responsable publica su rama.
- Abre un pull request hacia
develop. - Relaciona el pull request con su issue mediante
Closes #<número>. - Documenta las pruebas realizadas y cualquier limitación conocida.
- Solicita la revisión correspondiente.
- Atiende las observaciones antes de la integración.
Los pull requests creados por otros integrantes requieren la aprobación de @BetoxPrograming, administrador del flujo de integración. Los pull requests creados por @BetoxPrograming requieren la aprobación de al menos otro integrante.
Cuando todos los issues del milestone estén integrados y el sistema haya sido probado, se abrirá un pull request final desde develop hacia main.
| Área | Tecnología o herramienta | Estado |
|---|---|---|
| Lenguaje | Java 21 | Preparación |
| Framework | Spring Boot | Preparación |
| Arquitectura | Modelo MVC | Preparación |
| Vistas | HTML5, CSS y Thymeleaf | Preparación |
| Interfaz | Bootstrap mediante WebJars | Preparación |
| Persistencia | Spring Data JPA e Hibernate | Preparación |
| Base de datos | MySQL | Preparación |
| Construcción | Maven Wrapper | Preparación |
| Control de versiones | Git y GitHub | En uso |
| Prototipado | Figma | Utilizado en el Avance 1 |
Note
Las tecnologías marcadas como Preparación se actualizarán cuando su implementación quede integrada y validada en la rama principal.
telecomtrack/
├── docs/
│ └── avance1/
├── src/
├── .gitignore
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
└── README.md
docs/: documentación y evidencias de cada entrega.src/: código fuente de la aplicación.CONTRIBUTING.md: flujo de trabajo, ramas, commits, issues y pull requests.CODE_OF_CONDUCT.md: normas de convivencia y responsabilidad académica.
La estructura se actualizará conforme se incorpore la base oficial del proyecto Spring Boot.
El desarrollo directo corresponde a los integrantes del equipo y debe mantenerse dentro del alcance definido por el curso.
Antes de realizar cambios, es obligatorio leer:
El incumplimiento de las normas académicas, técnicas o de colaboración puede poner en riesgo la entrega y será comunicado al docente cuando corresponda.