Reglas generales y calificación¶
Reglas generales¶
Asistencia¶
La asistencia a las sesiones del curso es fundamental y obligatoria para el adecuado desarrollo del proyecto y la correcta comprensión de los contenidos. El profesor podrá disminuir hasta un 20% de la nota individual, por cada nivel de evaluación, en caso de inasistencias injustificadas. La aplicación de esta disminución quedará a criterio del profesor, considerando la participación, el compromiso y el desempeño general del estudiante.
Para la validación de las inasistencias, el profesor realizará control de asistencia en cada sesión mediante el registro correspondiente.
Presentaciones¶
Las presentaciones de avances y entregables hacen parte del proceso de evaluación del curso. El profesor podrá disminuir hasta un 10% de la nota correspondiente a cada nivel de evaluación en caso de que un estudiante o grupo no realice las presentaciones acordadas en clase, sin una justificación válida.
Uso de Git y control de versiones¶
El repositorio oficial del proyecto será GitHub. Cada grupo deberá crear una organización y, dentro de ella, un repositorio independiente para cada uno de los siguientes componentes: - Taller: Wiki con Thymeleaf - Proyecto de Backend (Spring Boot) - Proyecto de Frontend (Angular)
No se permite el uso de más de un repositorio por componente.
El trabajo colaborativo deberá realizarse mediante el uso de ramas, donde cada funcionalidad se desarrollará en una rama independiente. Cada integrante del grupo deberá trabajar en la rama correspondiente a la funcionalidad asignada.
Todas las funcionalidades deberán integrarse en una rama principal, la cual será la utilizada para el despliegue y la evaluación final del proyecto.
Durante las presentaciones, el profesor podrá solicitar la revisión del historial de commits y ramas, con el fin de validar la participación y contribución individual de cada estudiante.
Quices¶
Durante el semestre se realizarán quices de manera periódica, orientados a verificar de forma individual la apropiación de los conceptos vistos en clase. Los quices son cortos, se aplican al inicio de la sesión y pueden ser anunciados o sorpresa, por lo que la asistencia y el estudio continuo son determinantes.
Los quices se evalúan sobre los contenidos vistos en las sesiones previas del nivel correspondiente, incluyendo tanto los conceptos teóricos como las herramientas y frameworks trabajados en clase.
Cada nivel de evaluación (taller y las tres entregas del proyecto) incluye un rubro de quices que corresponde al 10% de la nota de ese nivel. La nota del rubro es el promedio de los quices aplicados durante ese nivel. Un quiz no presentado sin justificación válida se califica en cero (0).
Daily¶
Los primeros quince (15) minutos de cada sesión y diez (10) minutos extras para generación del acta estarán destinados al seguimiento del taller y del proyecto del semestre. Durante este espacio, cada grupo deberá revisar avances, dificultades y próximos pasos.
Como evidencia de este seguimiento, se deberá elaborar una acta sencilla por sesión, en la cual se consignen los temas tratados, acuerdos y compromisos. Se recomienda grabar la sesión y, de manera opcional, utilizar herramientas de inteligencia artificial para apoyar la generación del acta, garantizando siempre la claridad y veracidad de la información registrada.
Calificaciones¶
Las estrategias de evaluación están centradas en la valoración de los Resultados de Aprendizaje Esperados (RAE) de la asignatura. Estas pueden ser formativas, que suscitan la comprensión y construcción de conocimiento, y sumativas, que incluyen porcentajes de evaluación con el fin de corroborar el logro de los aprendizajes y el desarrollo de las competencias.
Los porcentajes corresponden a los definidos en el syllabus oficial de la asignatura (34807 · período 2026-30).
| Módulo | Descripción | Fecha | Calificación |
|---|---|---|---|
| Taller · Wiki con Thymeleaf | La evaluación se realizará mediante un taller en el que los estudiantes deberán construir una wiki funcional utilizando Thymeleaf como motor de plantillas, aplicando buenas prácticas de estructuración de vistas, reutilización de fragmentos y renderizado dinámico de información. | 12/08/2026 | Proyecto: 7% Quices y presentaciones: 3% |
| Proyecto · Primera entrega: aplicación web con Spring Boot, Thymeleaf y JPA | Este módulo hace parte de un proyecto transversal que se desarrollará durante todo el semestre, enfocado en la visualización y edición de procesos. El entregable consistirá en una aplicación Spring Boot con modelo en capas, vistas renderizadas con Thymeleaf y persistencia con JPA, que soporte la consulta y gestión de empresas, usuarios y procesos. | 14/09/2026 | Proyecto: 10% Quices y presentaciones: 5% |
| Proyecto · Segunda entrega: API REST y frontend con Angular | Continuando con el proyecto transversal, la evaluación se centrará en la exposición de la lógica del sistema mediante servicios REST con Spring Boot y en el desarrollo de una aplicación SPA en Angular que los consuma, permitiendo la visualización interactiva y la edición de los procesos, junto con el empaquetamiento de la solución en Docker. | 21/10/2026 | Proyecto: 20% Quices y presentaciones: 5% |
| Proyecto · Entrega final: seguridad, pruebas y despliegue | Como cierre del proyecto transversal, este módulo evaluará la integración de seguridad, las pruebas automatizadas y el despliegue de la solución. El entregable incluirá autenticación y autorización, pruebas de integración y de sistema (E2E), el despliegue de la aplicación y una presentación final que evidencie su correcta integración end-to-end. | 25/11/2026 | Proyecto: 15% Quices y presentaciones: 5% |
| Evaluación escrita global | Evaluación escrita individual sobre la totalidad de los contenidos del curso, orientada a validar la comprensión conceptual de computación distribuida, desarrollo web, empaquetamiento, despliegue y pruebas. | 30/11/2026 | 30% |
Las fechas corresponden al calendario del curso y pueden ajustarse según el ritmo del grupo.
Quices
Cada uno de los cuatro niveles anteriores —taller y las tres entregas del proyecto— incluye un rubro de quices equivalente al 10% de la nota de ese nivel, calculado como el promedio de los quices individuales aplicados durante el nivel. Ver Quices.
Taller: Wiki¶
Fecha: 12/08/2026 · Peso: 10% de la nota final
El taller se entrega antes de las clases de Thymeleaf
Thymeleaf se dicta en las clases 9 y 10 (26/08 y 31/08), después de la fecha de entrega de este taller. Esto es intencional: el taller exige aprender la herramienta de forma autónoma a partir de la documentación oficial, lo cual hace parte de los resultados de aprendizaje de la asignatura. Las sesiones de clase servirán luego para consolidar y profundizar lo trabajado aquí.
Se recomienda empezar el taller desde la primera semana y usar los espacios de daily para resolver dudas.
En el contexto de este curso, una Wiki es una aplicación web server-side cuyo objetivo es organizar, presentar y navegar información de manera estructurada, simulando un portal de documentación técnica. No se trata únicamente de contenido estático, sino de una solución que demuestra el uso correcto de vistas dinámicas, integración con backend y buenas prácticas de arquitectura web.
La Wiki funciona como un caso de uso controlado para aplicar Thymeleaf, donde se evalúa la capacidad del estudiante para construir interfaces reutilizables, manejar datos dinámicos y mantener una separación clara de responsabilidades entre controlador, vista y modelo (patrón MVC).
Arquitectura¶
La Wiki debe seguir una arquitectura MVC básica, compuesta por:
- Controladores: responsables de atender las solicitudes HTTP, preparar la información y enviarla a las vistas.
- Vistas (Thymeleaf): encargadas del renderizado dinámico del contenido, sin incluir lógica de negocio compleja.
- Modelo: datos que representan las páginas, secciones o entradas de la Wiki, ya sea simulados, en memoria o persistidos.
A nivel de vistas, se espera el uso de layouts y fragmentos reutilizables, una navegación coherente entre secciones y una estructura clara que facilite la lectura y mantenimiento del proyecto.
Formulario de Contáctenos¶
El proyecto debe incluir un formulario de contacto cuyo objetivo sea permitir la captura estructurada de información por parte del usuario. Este formulario representa un caso de uso típico en aplicaciones web y sirve para evaluar la correcta implementación de interacción cliente–servidor, validaciones en el frontend y usabilidad básica.
El formulario debe contener mínimo cinco (5) campos, incluyendo datos personales y de contexto (por ejemplo: nombre, correo electrónico, teléfono, asunto y mensaje). Los campos obligatorios deben estar claramente identificados y contar con validaciones en JavaScript, tales como verificación de campos requeridos, formato de correo electrónico, longitud mínima de texto y validación de valores numéricos cuando aplique.
Desde el punto de vista funcional, el formulario debe ofrecer retroalimentación clara al usuario en caso de errores de validación y confirmar cuando la información es válida para su envío. No se requiere el envío real de la información a un backend, pero la estructura debe quedar preparada para una futura integración, manteniendo buenas prácticas de organización del código y separación de responsabilidades.
Campos obligatorios
El formulario debe contener como mínimo los siguientes cinco (5) campos obligatorios:
| Campo | Validaciones |
|---|---|
| Nombre completo | Campo obligatorio. Longitud mínima de 3 caracteres. No debe permitir únicamente espacios en blanco. |
| Correo electrónico | Campo obligatorio. Debe tener un formato válido de correo electrónico, incluyendo una @ y un punto (.) posterior a la @. |
| Teléfono | Campo obligatorio. Solo debe permitir números. Longitud mínima de 7 y máxima de 15 dígitos. |
| Asunto o motivo de contacto | Campo obligatorio. No debe permitir valores por defecto como “Seleccione una opción”. |
| Mensaje | Campo obligatorio. Longitud mínima de 20 caracteres y máxima de 400. Debe decir cuantos caracteres hacen falta |
Validaciones adicionales
Además de las validaciones por campo, el formulario debe cumplir con las siguientes reglas generales:
- Las validaciones deben implementarse en JavaScript, sin depender exclusivamente de validaciones HTML.
- Los errores deben mostrarse de forma clara y comprensible para el usuario, indicando qué campo presenta el problema y por qué.
- El formulario no debe enviarse si existe al menos un error de validación.
- Debe existir retroalimentación visual cuando el formulario es válido y está listo para ser enviado.
No es obligatorio implementar el envío de la información a un backend, pero la estructura del formulario y el código de validación deben quedar preparados para una futura integración con servicios del servidor.
Contenido¶
La Wiki debe incluir, como mínimo:
- Página de inicio con descripción general del proyecto.
- Navegación funcional entre secciones.
- Varias páginas o secciones renderizadas dinámicamente.
- Uso de fragmentos comunes (header, footer, menú).
- Estructura clara y consistente del contenido.
- Formulario de Contáctenos con los campos y validaciones descritos anteriormente.
El enfoque está en la estructura, funcionalidad y arquitectura, no en la extensión ni calidad editorial del texto.
Criterios de evaluación¶
| Criterio | Descripción | Peso |
|---|---|---|
| Uso de Thymeleaf | Uso correcto de atributos (th:text, th:each, th:if, etc.) y renderizado dinámico de datos |
35% |
| Formulario | Formulario de contacto funcional con validaciones en JavaScript, código legible y sin lógica de negocio en la vista | 13% |
| Arquitectura MVC | Separación adecuada entre controladores, vistas y modelo | 10% |
| HTML/CSS | La página debe estar construida con HTML semántico y CSS propio o mediante un framework de estilos (Tailwind o Bootstrap) | 10% |
| Estructura de vistas | Uso de layouts y fragmentos reutilizables (th:fragment, th:replace) |
9% |
| Despliegue | Aplicación funcional, accesible vía URL y desplegada según las reglas definidas | 8% |
| Navegación y funcionalidad | Navegación clara y consistente entre páginas de la Wiki | 5% |
| Quices | Promedio de los quices individuales aplicados durante este nivel, sobre HTTP, HTML, CSS, JavaScript y frameworks de estilos | 10% |
Despliegue¶
Para que la Wiki sea evaluada, debe cumplir con las siguientes condiciones de despliegue:
- La aplicación debe compilar y ejecutarse sin errores.
- Debe estar desplegado en una máquina en un contenedor Docker.
- El proyecto debe incluir instrucciones claras de ejecución.
- No se permiten ejecuciones desde el IDE ni directamente sobre la línea de comandos.
El incumplimiento de estas reglas puede afectar la calificación del criterio de despliegue.
Proyecto: Editor procesos¶
El proyecto del semestre consiste en el desarrollo de un visor y editor de procesos empresariales, cuyo objetivo es permitir la visualización y edición de procesos asociados a una empresa, garantizando la separación de información entre distintas organizaciones. Cada empresa contará con sus propios usuarios, y los procesos creados o gestionados serán exclusivos de la empresa a la que pertenece el usuario autenticado.
El sistema estará orientado únicamente a la visualización y edición de procesos, no a su ejecución. Esto implica que los usuarios podrán consultar, crear, modificar y organizar procesos, pero no disparar flujos automáticos ni tareas de procesamiento. El enfoque del proyecto es académico y busca evaluar la correcta aplicación de conceptos de arquitectura web, separación de responsabilidades, seguridad básica y buenas prácticas de desarrollo.
El desarrollo del proyecto se realizará de forma incremental y se evaluará a través de tres (3) entregas diferenciadas, alineadas con los contenidos vistos hasta el momento de cada entrega. La primera entrega corresponde a la aplicación web server-side, donde se deberá implementar el modelo de datos con JPA, la lógica de negocio en un modelo en capas y las vistas con Thymeleaf que gestionan empresas, usuarios y procesos. La segunda entrega corresponde a la API REST y al frontend, en la cual la lógica del sistema se expone mediante servicios REST y se construye una aplicación Angular que los consume para la visualización y edición de los procesos. Finalmente, la entrega final evaluará la integración completa del sistema, incluyendo seguridad, pruebas automatizadas, calidad del código y despliegue, demostrando el funcionamiento coherente de la solución de extremo a extremo.
Historias de usuario¶
Se tienen las siguientes de HU: Historias usuario
Entregas del proyecto¶
El proyecto del semestre se desarrollará de manera incremental y será evaluado a través de tres entregas principales, cada una con objetivos y criterios específicos, orientados a validar la correcta aplicación de los conceptos vistos en clase.
Primera entrega – Aplicación web con Spring Boot, Thymeleaf y JPA¶
Fecha: 14/09/2026 · Peso: 15% de la nota final
El objetivo de esta entrega es que el estudiante diseñe e implemente una aplicación web server-side estructurada, aplicando el patrón MVC, el modelo en capas y buenas prácticas de desarrollo. Se busca evaluar la capacidad de modelar el dominio del problema, persistir la información con JPA y construir vistas dinámicas con Thymeleaf, estableciendo una base sólida sobre la cual se expondrán los servicios REST y se integrarán el frontend y la seguridad en las siguientes fases.
| Criterio | Descripción | Porcentaje |
|---|---|---|
| Servicios | Implementación de la lógica de negocio para la visualización y edición de procesos, asegurando una correcta separación de responsabilidades. | 18% |
| Entidades | Definición correcta del modelo de dominio, incluyendo entidades, atributos y relaciones entre empresas, usuarios y procesos. | 13% |
| Vistas con Thymeleaf | Renderizado dinámico de la información mediante layouts y fragmentos reutilizables, con navegación coherente entre secciones. | 13% |
| Repositorios | Implementación de repositorios para el acceso y persistencia de datos, utilizando correctamente JPA, JPQL y named queries. | 11% |
| Quices | Promedio de los quices individuales aplicados durante este nivel, sobre computación distribuida, Servlets, Spring MVC, Thymeleaf y JPA | 10% |
| Controladores | Implementación de controladores claros y coherentes, con las operaciones del sistema y el flujo entre vistas y modelo. | 9% |
| Validación y manejo de excepciones | Uso de Spring Validation, gestión centralizada de errores, página de error y respuestas adecuadas ante datos inválidos. | 9% |
| Ingeniería de software | Organización del proyecto, claridad del código, nombres adecuados y buenas prácticas generales. Resultado SonarQube. Git. | 7% |
| Inicialización y consistencia de datos | Inicializador de base de datos y manejo correcto de la eliminación en cascada entre entidades relacionadas. | 5% |
| Despliegue | La aplicación compila, ejecuta correctamente y está disponible para su revisión. | 5% |
Segunda entrega – API REST y frontend con Angular¶
Fecha: 21/10/2026 · Peso: 25% de la nota final
En esta entrega se evalúa la capacidad del estudiante para exponer la lógica del sistema mediante servicios REST y para desarrollar una interfaz web funcional que los consuma. El énfasis está en la integración frontend–backend, el manejo de formularios, la paginación, la visualización y edición de información, y la construcción de flujos de navegación coherentes. Esta entrega valida que el estudiante comprenda cómo interactúan las capas del sistema dentro de una arquitectura web completa.
| Criterio | Descripción | Porcentaje |
|---|---|---|
| API REST | Implementación de controladores REST claros y coherentes, con endpoints funcionales, uso adecuado de ResponseEntity y códigos de estado HTTP. |
13% |
| Componentes | Implementación de componentes reutilizables y bien estructurados para la visualización y edición de procesos. | 13% |
| Servicios y RxJS | Consumo correcto de los servicios REST mediante HttpClient, manejo de observables, peticiones HTTP y procesamiento de respuestas. |
13% |
| Despliegue con Docker | La aplicación compila, se empaqueta en contenedores Docker y el frontend se integra correctamente con el backend. | 12% |
| Formularios y paginación | Envío de información al backend mediante formularios y consulta paginada de los listados del sistema. | 11% |
| Quices | Promedio de los quices individuales aplicados durante este nivel, sobre SPA y Angular, RxJS, REST, formularios, paginación y Docker | 10% |
| Ingeniería de software | Organización del proyecto, claridad del código, nombres adecuados y aplicación de buenas prácticas generales. Resultado SonarQube. Git. | 9% |
| Modelos | Definición y uso adecuado de modelos/interfaces para representar la información de empresas, usuarios y procesos. | 7% |
| Manejo de información entre componentes | Uso correcto de mecanismos de comunicación (Input/Output, servicios compartidos, estado) para el flujo de datos entre componentes. | 7% |
| Documentación de la API | Documentación de los servicios con Swagger/OpenAPI y evidencia de pruebas de los endpoints con Postman. | 5% |
Entrega final – Seguridad, pruebas y despliegue¶
Fecha: 25/11/2026 · Peso: 20% de la nota final
La entrega final tiene como propósito que el estudiante demuestre una comprensión integral de la seguridad y la calidad en aplicaciones web, particularmente en escenarios multiempresa. Se evalúa la implementación de autenticación y autorización con Spring Security, garantizando el aislamiento de la información entre empresas y usuarios, junto con las pruebas automatizadas y el despliegue de la solución completa. Esta fase busca consolidar los conocimientos adquiridos y acercar al estudiante a un escenario real de desarrollo profesional.
| Criterio | Descripción | Porcentaje |
|---|---|---|
| Autenticación | Implementación correcta del mecanismo de autenticación con Spring Security, incluyendo login, generación y validación de tokens. | 18% |
| Autorización | Control de acceso a los recursos según empresa y usuario, aplicando un modelo de control de acceso que garantice el aislamiento de la información entre organizaciones. | 18% |
| Funcionalidad total | Funcionamiento completo e integrado del visor y editor de procesos, incluyendo frontend, backend y seguridad. | 13% |
| Pruebas de integración | Pruebas de integración sobre los servicios REST, cubriendo los casos de uso principales y los escenarios de seguridad. | 11% |
| Pruebas de sistema (E2E) | Pruebas automatizadas de extremo a extremo que validen los flujos completos del visor y editor de procesos. | 11% |
| Quices | Promedio de los quices individuales aplicados durante este nivel, sobre pruebas unitarias, de integración y E2E, control de acceso, Spring Security y despliegue | 10% |
| Despliegue final | Aplicación desplegada correctamente, accesible y funcional en un entorno definido (local o remoto). | 7% |
| Presentación | Presentación clara del proyecto, explicación de la arquitectura, seguridad implementada y demostración funcional. | 7% |
| Ingeniería de software | Calidad general del código, organización del proyecto, claridad, mantenibilidad y buenas prácticas. Resultado SonarQube. Git. | 5% |
Evaluación escrita global¶
Fecha: 30/11/2026 · Peso: 30% de la nota final
Se trata de una evaluación escrita individual sobre la totalidad de los contenidos del curso. A diferencia del taller y del proyecto, que son grupales y prácticos, esta evaluación busca validar la comprensión conceptual de cada estudiante frente a los contenidos temáticos de la asignatura:
- Conceptos esenciales de computación distribuida: cliente-servidor, n-tier, objetos distribuidos, web services y microservicios.
- Aspectos esenciales de desarrollo web: HTTP/HTTPS, REST, CSS, JavaScript, inversión de control, inyección de dependencias, programación reactiva, Angular, Spring Boot, JSON, JPA/Hibernate y seguridad web (autenticación, autorización, confidencialidad y canales seguros).
- Empaquetamiento, despliegue y ejecución.
- Pruebas: pruebas de integración sobre servicios REST y pruebas de sistema (E2E).