Conformación de equipos
El trabajo se realiza en equipos de 2 o 3 estudiantes. Conviene empezar apenas se explica la letra e ir mostrando los avances a los profesores, sin esperar al último día.
| Grupo A | Grupo B | Grupo C | Grupo D | Grupo E | Grupo F |
|---|---|---|---|---|---|
| Madruga Ríos, Luis Sebastián | Da Silveira Moller, Martín | López Bittencourt, Nahuel | Balarini Pricoli, Pedro Giovanni | Sotillo Mollegas, Carlos Daniel | Esteche Medina, Mateo Esequiel |
| Aguirre Martínez, Agustín Maximiliano | Suárez Carabajal, Santiago | Souza Antúnez, Juan Ignacio | Acosta Romero, Emiliano Germán | Martínez Mareco, Lautaro | Gasdia Leivas, Federico |
| González Rosso, Juan Ignacio | Bordón Espino, Santiago | — | Furtado López, Raúl Sendic | Maldonado Linari, Juan Ignacio | Pimentel Bentancor, Facundo Santiago |
| Salazar Pacheco, Joaquín | — | — | — | Colman, Thiago | — |
Fechas de interés
Cada hito muestra los días restantes. El próximo aparece en verde, los que vencen en una semana o menos en naranja, y los ya pasados en gris.
Uso responsable de la IA
La IA se permite como apoyo para aprender, consultar y revisar. No sustituye el análisis, el diseño ni la comprensión del equipo. Todo uso debe declararse y registrarse.
Se permite el uso de IA siempre que sea apoyo para el aprendizaje, la consulta, la revisión y la resolución de dudas puntuales. No podrá sustituir el análisis, las decisiones de diseño, la implementación ni la comprensión técnica del equipo.
Todo uso de IA deberá:
- ser declarado;
- quedar registrado;
- estar vinculado con una necesidad concreta;
- ser revisado críticamente por el equipo;
- poder ser explicado durante la defensa;
- incorporarse como anexo a la documentación final.
El equipo es responsable de todo el contenido entregado, aunque parte haya sido sugerido o generado con ayuda de IA.
Consultas puntuales, por ejemplo:
- explicación de un concepto de Java, Maven, Swing, FlatLaf o JDBC;
- aclaraciones sobre un error concreto;
- funcionamiento de una clase, método o interfaz;
- ejemplos breves que no resuelvan el proyecto;
- comparar alternativas de diseño;
- revisar una decisión técnica ya tomada;
- mejorar la legibilidad de un fragmento de código;
- interpretar un mensaje de error;
- revisar ortografía y redacción;
- diferencias entre modelo de datos y modelo orientado a objetos;
- organizar paquetes, capas o responsabilidades;
- buenas prácticas de conexión y manejo de excepciones;
- explicar una consulta SQL creada por el equipo;
- evaluar acoplamiento o cohesión.
No se permite delegar la resolución total o sustancial del proyecto. Entre otros:
- copiar y pegar la letra completa para pedir su resolución;
- subir la consigna completa para que se realice el trabajo;
- «hágame el proyecto», «genere toda la aplicación»;
- pedir el modelo completo de clases;
- pedir los diagramas resueltos;
- pedir la base de datos completa con todos sus scripts;
- generar todas las clases, DAO, servicios y pantallas;
- copiar código sin comprenderlo;
- presentar como propias decisiones que no puedan explicar;
- ocultar el uso de IA o borrar partes del chat;
- usar respuestas sin comprobar su funcionamiento;
- usar IA en la defensa sin autorización.
Un buen prompt describe el problema, indica qué intentó el equipo, incluye solo el fragmento necesario y pide explicación en vez de una respuesta terminada.
✅ Ejemplos adecuados
- «Creamos una interfaz para desacoplar el servicio del DAO, pero no sabemos si la dependencia quedó bien orientada. ¿Qué revisar?»
- «Este método JDBC no cierra el ResultSet ante una excepción. ¿Cómo usar try-with-resources?»
- «El sistema debe impedir vender un asiento dos veces en la misma función. ¿Validar en la interfaz, en el servicio o en ambos?»
- «Esta consulta SQL devuelve filas duplicadas. ¿Cómo hallar la causa sin reescribirla toda?»
❌ Ejemplos no adecuados
- «Hágame el proyecto completo del banco en Java.»
- «Resuelva esta consulta en SQL.»
- «Genere todas las clases, tablas, DAO y pantallas.»
- «Le envío la letra. Hágalo para entregar.»
El registro deberá incluir:
- herramienta utilizada;
- fecha de la consulta;
- integrante que consultó;
- prompt enviado y respuesta obtenida;
- motivo de la consulta;
- decisión tomada tras revisar;
- fragmento donde se aplicó;
- modificaciones sobre la respuesta;
- valoración de utilidad o limitaciones.
Estructura de la carpeta
La documentación se presenta en este orden. Se entrega una carpeta por materia; no se aceptan hojas sueltas.
Carátula
- Nombre del grupo.
- Nombre del equipo de trabajo.
- Nombre de cada integrante.
- Nombre de los docentes.
- Fecha de culminación.
Índice
Después de la carátula. Abarca todo el contenido, incluyéndose a sí mismo y a los anexos.
Introducción
Explica en forma clara y concisa lo que se realiza en el proyecto.
Desarrollo del proyecto
El equipo relata con sus palabras los objetivos, la forma y los medios, con argumentación técnica. Mínimo 10 hojas de desarrollo. El trabajo con similitud manifiesta a un artículo de Internet no será calificado.
Anexo
Folletos, planos o datos adicionales necesarios.
Referencias bibliográficas (obligatorias)
Cada referencia: autores, nombre del documento, edición, fecha y —si es sitio web— la dirección clara, precisa y completa.
Aspectos formales del texto
Papel
Tamaño A4, una sola cara, interlineado 1,5.
Márgenes
- Izquierdo 3 cm · Derecho 3 cm
- Superior 3 cm · Inferior 2,5 cm
- Encabezado 1,2 cm · Pie de página 1,25 cm
Numeración
Consecutiva desde el índice, en el ángulo inferior derecho.
Tipo de letra
- Títulos: 16, Arial o Times New Roman, negrita.
- Subtítulos: 14, negrita.
- Párrafos: 12. Redacción impersonal, clara y concisa.
Encabezado y pie
Encabezado: grupo, logo centrado y fecha. Pie: proyecto, siglas de la escuela y grupo.
Generalidades del sistema propuesto
Cada equipo elige UNA de las tres realidades. Las tres tienen dificultad equivalente: una jerarquía de especialización, una relación de muchos a muchos con atributos y un conjunto de restricciones de integridad.
Un banco desea desarrollar un sistema para registrar la información correspondiente a sus sucursales, clientes, cuentas bancarias y transacciones.
De cada sucursal se registra su identificador, nombre, dirección y la ciudad donde se encuentra.
De cada cliente se registra su documento de identidad, nombre completo, fecha de nacimiento, dirección y teléfono.
Cada cliente puede ser titular de una o varias cuentas bancarias. Asimismo, una cuenta bancaria puede tener uno o varios titulares.
De cada cuenta bancaria se conoce su número de cuenta, tipo, fecha de apertura y saldo actual. Las cuentas pueden clasificarse en:
- Cuenta de ahorro.
- Cuenta corriente.
De cada funcionario se registra su identificador, nombre, cargo y fecha de ingreso. Cada funcionario trabaja en una única sucursal, mientras que una sucursal puede tener varios funcionarios.
Cada sucursal administra varias cuentas bancarias. Cada cuenta bancaria es administrada por una única sucursal.
Los clientes realizan operaciones sobre sus cuentas. De cada operación se registra un identificador, la fecha, hora, monto y tipo de operación. Las operaciones pueden clasificarse en:
- Depósito.
- Retiro.
- Transferencia.
Cada operación corresponde a una única cuenta bancaria. Una cuenta bancaria puede registrar múltiples operaciones. En el caso de las transferencias, una operación implica una cuenta de origen y una cuenta de destino.
El banco también registra los préstamos otorgados a los clientes. De cada préstamo se conoce su identificador, el monto otorgado, la tasa de interés aplicada, la fecha en que se otorga y la cantidad de cuotas pactadas. Un cliente puede solicitar varios préstamos y un préstamo pertenece a un único cliente.
Una cadena de cines desea desarrollar un sistema para gestionar la venta de entradas, la asignación de asientos y la asistencia de clientes a las funciones de las películas exhibidas.
De cada complejo de cine se registra su identificador, nombre y dirección.
Cada complejo cuenta con varias salas. De cada sala se registra su identificador, número y capacidad máxima de espectadores.
Cada sala dispone de varios asientos. De cada asiento se registra su identificador, fila y número. Un asiento pertenece a una única sala, mientras que una sala posee múltiples asientos.
De cada película se registra su identificador, título, género, duración, clasificación por edad y año de estreno.
Las películas son exhibidas mediante funciones. De cada función se registra su identificador, fecha, hora y precio base de la entrada. Cada función corresponde a una única película y se realiza en una única sala. Una película puede tener varias funciones y una sala puede albergar múltiples funciones en distintos horarios.
De cada cliente se registra su documento, nombre, correo electrónico y teléfono. Los clientes pueden realizar compras de entradas para distintas funciones.
De cada compra se registra su identificador, fecha, hora, importe total y método de pago. Cada compra es realizada por un único cliente, mientras que un cliente puede realizar varias compras.
Una compra puede incluir una o varias entradas. De cada entrada se registra su identificador, precio pagado y fecha de emisión. Cada entrada corresponde a una única función y tiene asignado un único asiento. Un asiento puede utilizarse en muchas funciones diferentes, pero solamente una vez por función.
Los clientes pueden cancelar una entrada antes del inicio de la función. De cada cancelación se registra la fecha y el motivo.
De cada empleado se registra su identificador, nombre, cargo y fecha de ingreso. Los empleados pueden clasificarse en:
- Cajero.
- Acomodador.
Cada empleado trabaja en un único complejo de cine, mientras que un complejo puede tener varios empleados.
Un restaurante desea desarrollar un sistema para gestionar sus mesas, las reservas de sus clientes, los pedidos realizados y los platos ofrecidos en su carta.
De cada restaurante se registra su identificador, nombre, dirección y teléfono.
Cada restaurante cuenta con varias mesas. De cada mesa se registra su identificador, número, capacidad de comensales y ubicación (por ejemplo, salón interior, terraza o barra). Una mesa pertenece a un único restaurante, mientras que un restaurante posee varias mesas.
De cada cliente se registra su documento, nombre completo, teléfono y correo electrónico.
Los clientes pueden realizar reservas de mesa. De cada reserva se registra su identificador, fecha, hora, cantidad de comensales y estado (confirmada, cancelada o cumplida). Cada reserva corresponde a un único cliente y a una única mesa. Un cliente puede realizar varias reservas y una mesa puede tener varias reservas en distintos horarios.
Los clientes realizan pedidos durante su visita. De cada pedido (comanda) se registra su identificador, fecha, hora, importe total y estado (abierto, cerrado o anulado). Cada pedido es realizado por un único cliente y se sirve en una única mesa. Un cliente puede realizar varios pedidos y una mesa puede recibir varios pedidos en distintos momentos.
De cada plato se registra su identificador, nombre, descripción, precio y categoría. Los platos pueden clasificarse en:
- Entrada.
- Plato principal.
- Postre.
- Bebida.
Un pedido puede incluir uno o varios platos. De cada línea del pedido se registra la cantidad solicitada, el precio unitario aplicado y una observación opcional (por ejemplo, «sin sal» o «sin gluten»). Un mismo plato puede aparecer en muchos pedidos y un pedido puede contener muchos platos.
De cada empleado se registra su identificador, nombre, cargo y fecha de ingreso. Los empleados pueden clasificarse en:
- Mozo.
- Cocinero.
Cada empleado trabaja en un único restaurante, mientras que un restaurante puede tener varios empleados. Cada pedido es atendido por un único mozo. Un mozo puede atender varios pedidos durante su jornada.
Requerimientos — Base de Datos
1. Propósito del proyecto
El proyecto deberá integrar:
- Modelo Entidad–Relación (MER).
- Modelo Relacional (MR).
- Tablas normalizadas hasta 3.ª Forma Normal (3FN).
- Manejo de la base de datos en XAMPP/MySQL.
- Datos de prueba cargados en todas las entidades.
- Operaciones de mantenimiento de datos (alta, baja, modificación).
- Consultas SQL que combinen información de diferentes tablas.
2. Análisis del problema y modelos requeridos
- Elaborar un MER que represente las entidades principales de la realidad elegida.
- Derivar un MR con claves primarias y foráneas, relaciones normalizadas.
Dinámica de Daily — trabajo en el aula
Luego de las vacaciones de setiembre se destinará tiempo de clase al proyecto. Para aprovecharlo, cada equipo realizará una Daily al comenzar ese tiempo.
¿Qué es una Daily?
Es una reunión breve del equipo, de pocos minutos, donde cada integrante cuenta en qué está. Se usa en el trabajo real de software para mantener al equipo coordinado, ver los avances y detectar a tiempo lo que está frenado. No es para resolver el problema ahí mismo, sino para saber quién necesita ayuda.
Las tres preguntas
En cada Daily, cada integrante responde:
- ¿Qué trabajé la semana pasada?
- ¿Qué voy a trabajar esta semana?
- ¿Qué tengo trancado? (qué me está frenando o dónde necesito ayuda).
Cómo la adaptamos
La haremos una vez por semana, al inicio del tiempo de proyecto. Antes de empezar a trabajar, el equipo deberá decir cuál es el objetivo de ese tiempo de clase e indicar qué trabajará cada integrante. Luego cada uno responde las tres preguntas. Esta dinámica es obligatoria y quedará registrada en el proyecto.
Requerimientos — Programación Avanzada
Requerimientos — Sistemas Operativos
Requerimientos — Videojuegos
Cada equipo deberá diseñar y desarrollar un videojuego en dos dimensiones utilizando GameMaker, inspirado en la realidad seleccionada para el proyecto integrador (Banco, Sala de Cine o Restaurante).
El videojuego deberá tomar como base la misma temática trabajada en las restantes asignaturas, procurando mantener coherencia con los actores, objetos, escenarios y reglas del negocio definidas durante el proyecto.
No se espera una adaptación literal del sistema desarrollado en Programación. El objetivo es transformar esa realidad en una experiencia interactiva que resulte entretenida para el jugador, aplicando las técnicas y herramientas trabajadas durante el curso.
Durante el desarrollo deberán integrarse, de forma progresiva, los principales contenidos de la asignatura, entre ellos:
- movimiento del personaje;
- detección de colisiones;
- pasaje de pantallas;
- sistema de puntaje;
- recolección de objetos;
- variables y control del estado del juego;
- sonido y efectos;
- interfaz de usuario.
El videojuego deberá presentar una experiencia jugable completa, donde las mecánicas implementadas tengan sentido dentro de la temática elegida y funcionen de forma integrada.
Integración con el proyecto interdisciplinario
La temática del videojuego deberá corresponder con la propuesta elegida por el equipo para el proyecto integrador. Por ejemplo:
🏦 Sistema Bancario
Atención de clientes; gestión de operaciones; seguridad bancaria; administración de recursos.
🎬 Sala de Cine
Venta de entradas; organización de funciones; gestión de salas; atención al público.
🍽️ Restaurante
Atención de mesas; preparación y entrega de pedidos; administración del tiempo; gestión de clientes.
La mecánica del juego será definida por cada equipo, siempre que mantenga relación con la realidad seleccionada y permita evidenciar la aplicación de los contenidos trabajados en la asignatura.
Los requerimientos específicos, criterios de evaluación y productos esperados para cada entrega se detallan en el documento «Requerimientos de Videojuegos».
📄 Acceso a los requerimientos ↗