La defensa de una tesina de Ingeniería en Sistemas se diferencia de la de otras carreras en un punto concreto: el jurado tiene el código, o al menos el repositorio, y puede preguntar sobre decisiones técnicas específicas que en un trabajo puramente teórico no existirían. Esta guía reúne las preguntas que efectivamente aparecen en esas defensas, agrupadas por tema, con una guía de cómo se responde cada tipo sin quedarse en generalidades y con ejemplos concretos de intercambios entre jurado y estudiante.
Preguntas sobre las decisiones de arquitectura
El jurado no pregunta «¿por qué usaste Python?» esperando una respuesta de gustos; pregunta por qué esa decisión, comparada con las alternativas reales que existían en el momento de diseñar el sistema:
- «¿Por qué eligió esta arquitectura (monolítica, de microservicios, en capas) y no otra? ¿Qué alternativa consideró y por qué la descartó?»
- «¿Qué pasaría si el volumen de usuarios o de datos se multiplicara por diez? ¿Su arquitectura escala o necesitaría rediseñarse?»
- «¿Por qué esa base de datos (relacional o no relacional) y no otra, dado el tipo de datos que maneja el sistema?»
- «¿Qué patrones de diseño aplicó y por qué, más allá de nombrarlos?»
La respuesta que funciona nombra la alternativa descartada explícitamente y el criterio de la decisión (rendimiento, tiempo de desarrollo, familiaridad del equipo, requisitos del cliente), no solo la opción elegida. Un ejemplo de intercambio bien resuelto: Jurado: «¿Por qué eligió una base de datos no relacional?» Estudiante: «Evalué PostgreSQL y MongoDB. Como el sistema maneja documentos con estructura variable entre usuarios y no necesitábamos transacciones complejas entre entidades, MongoDB redujo el tiempo de modelado inicial; el costo fue perder las validaciones de integridad referencial que sí tiene un motor relacional, que compensamos con validación en la capa de aplicación.» El capítulo de desarrollo, donde estas decisiones ya deberían estar documentadas con su justificación, es exactamente lo que la guía sobre el capítulo de desarrollo de una tesina de Ingeniería en Sistemas explica cómo escribir con anticipación a estas preguntas.
Preguntas sobre el código y su calidad
- «¿Cómo garantizó que el código funciona correctamente? ¿Qué pruebas hizo, unitarias, de integración, ambas?»
- «¿Qué porcentaje de cobertura de tests tiene el proyecto, y por qué ese nivel es (o no es) suficiente?»
- «Muéstreme una parte del código que considere especialmente bien resuelta, y explique por qué.»
- «¿Documentó el código? ¿Cómo entendería este sistema alguien que se incorpora al proyecto sin haberlo escrito?»
Estas preguntas buscan verificar que el estudiante entiende su propio código en profundidad, no solo que lo hizo funcionar. Tener preparado un fragmento específico para mostrar y explicar (no elegido al azar en el momento) es una preparación que se nota.
Preguntas sobre metodología de trabajo y control de versiones
- «¿Trabajó con alguna metodología ágil (Scrum, Kanban)? Si es un proyecto individual, ¿tuvo sentido aplicarla o fue solo nominal?»
- «¿Cómo usó el control de versiones? Muéstreme el historial de commits: ¿refleja un desarrollo incremental real o son pocos commits grandes al final?»
- «¿Cómo gestionó los cambios de alcance durante el desarrollo, si los hubo?»
La pregunta sobre el historial de commits es más frecuente de lo que parece, y castiga a quien subió todo el proyecto en dos o tres commits al final: un historial incremental, con mensajes descriptivos, es evidencia de un proceso de desarrollo real y no solo de un resultado final entregado de una vez.
Preguntas sobre seguridad y manejo de datos
- «¿Cómo protege el sistema las credenciales de los usuarios? ¿Las contraseñas se almacenan con hash?»
- «¿Qué pasa si alguien intenta una inyección SQL o un ataque similar? ¿Su sistema está protegido?»
- «Si el sistema maneja datos personales, ¿consideró algún aspecto de la Ley de Protección de Datos Personales?»
No hace falta que la tesina sea un proyecto de ciberseguridad para que aparezcan estas preguntas; alcanza con que el sistema maneje usuarios o datos sensibles para que el jurado quiera saber si el estudiante pensó en los riesgos básicos, aunque la respuesta honesta sea que se aplicaron medidas mínimas por el alcance de un proyecto de grado.
Preguntas sobre validación y pruebas con usuarios
- «¿Cómo probó que el sistema resuelve el problema que dice resolver, más allá de que técnicamente funcione?»
- «¿Alguien fuera de usted usó el sistema? ¿Qué feedback recibió y qué cambió a partir de eso?»
- «¿Qué métricas usó para evaluar el rendimiento (tiempo de respuesta, uso de memoria, concurrencia soportada)?»
La respuesta débil típica es «lo probé yo mismo y funcionó». La respuesta sólida describe al menos una instancia de validación con alguien más (un usuario real, un compañero, el cliente si el proyecto viene de una empresa) y qué se ajustó a partir de esa prueba, con las cifras concretas cuando existan.
Preguntas sobre el contexto empresarial (si el proyecto es para una empresa real)
Si tu tesina desarrolló un sistema para una empresa real, aparecen preguntas específicas sobre esa relación: qué pasa con el código y los datos de la empresa después de la defensa, cómo se resolvió la confidencialidad de la información sensible en la memoria escrita, y si el sistema sigue en uso o quedó como prototipo académico. Esta zona de la defensa está directamente cubierta en la guía sobre tesina de Ingeniería en Sistemas en una empresa, que explica qué firmar, de quién es el código y cómo se anonimizan los datos de producción antes de la defensa.
Preguntas sobre el problema de investigación, no solo sobre el sistema
Aunque el objeto central de la tesina sea un sistema construido, el jurado también hace las preguntas propias de cualquier trabajo de investigación aplicada, y en Sistemas suelen tomar esta forma: «¿Cuál era exactamente el problema que este sistema resuelve, y por qué no existía ya una solución adecuada?», «¿Cómo se relaciona su solución con lo que encontró en el estado del arte o en herramientas similares existentes en el mercado?», «¿Qué parte de este trabajo es un aporte original y qué parte es aplicación de conocimiento ya existente?». Esta última pregunta suele incomodar porque muchos proyectos de Sistemas son, honestamente, la aplicación correcta y bien hecha de tecnologías conocidas a un problema concreto —y esa es una respuesta perfectamente válida, siempre que se diga con esos términos en vez de exagerar la originalidad técnica del trabajo.
Preguntas sobre alternativas no elegidas
Una categoría transversal a toda la defensa: el jurado pregunta reiteradamente «¿y si hubiera hecho X en cambio?» para verificar que el estudiante entiende el espacio de decisiones, no solo el camino que tomó. Ejemplos: «¿Consideró usar un framework existente en vez de construir esto desde cero?», «¿Por qué no tercerizó esta función a un servicio en la nube?», «Si tuviera que rehacer el proyecto hoy, ¿qué cambiaría?». Esta última pregunta es casi universal y conviene tenerla pensada de antemano con al menos dos cambios concretos, no una respuesta genérica de «nada, quedé conforme».
Cómo prepararse específicamente para estas preguntas
Además de preparar la presentación con la guía sobre cómo hacer las diapositivas para defender la tesis, un ejercicio específico de Ingeniería en Sistemas que da resultado es simular la defensa con un compañero que revise el repositorio (no solo la memoria escrita) y pregunte sobre decisiones puntuales del código, exactamente como haría el jurado. Otro ejercicio útil: escribir de antemano, para cada decisión de arquitectura importante, una frase con la alternativa descartada y el motivo, aunque esa frase nunca aparezca textual en la memoria; tenerla lista mentalmente evita el silencio incómodo cuando la pregunta llega.
Sobre la composición general del jurado
Más allá de las preguntas técnicas específicas de Sistemas, la composición general de un jurado de tesina en Argentina y su dinámica de evaluación sigue las reglas comunes a cualquier carrera, explicadas en la guía sobre quiénes forman el jurado de la tesina. Lo específico de Ingeniería en Sistemas es que, entre los tres integrantes, casi siempre hay al menos uno con perfil técnico capaz de leer el código, y esa es la persona de la que suelen salir las preguntas más detalladas de esta guía.
Preguntas frecuentes
¿Tengo que llevar el código para mostrar en vivo durante la defensa?
Conviene tenerlo accesible (en una laptop propia o en el repositorio online) por si el jurado pide ver un fragmento específico, aunque no siempre lo piden. No tenerlo disponible cuando lo piden es peor que no necesitarlo.
¿Qué pasa si no recuerdo por qué tomé una decisión de hace un año?
Es mejor decir «no lo recuerdo con precisión, pero el criterio general en ese momento del proyecto era X» que inventar una justificación sobre la marcha; el jurado nota la diferencia entre una respuesta honesta y una improvisada para quedar bien.
¿El jurado espera que el sistema funcione en vivo durante la defensa?
Depende de la facultad y del formato de defensa; muchas piden una demo en vivo, otras se conforman con capturas o un video grabado por riesgo de fallas técnicas el día de la defensa. Confirmalo con tu director/a antes.
¿Puedo decir que no consideré ninguna alternativa a una decisión?
Es preferible reconocerlo con honestidad («no evalué alternativas en ese punto, fue la primera opción que probé y funcionó») antes que inventar una comparación que no hiciste; el jurado suele valorar más la honestidad metodológica que una justificación fabricada.
¿Qué pasa si el jurado encuentra un bug durante la demo en vivo?
No es el fin del mundo: reconocer el error con calma, explicar brevemente cuál creés que es la causa probable y ofrecer mostrar el mismo flujo en un video de respaldo (si lo tenés preparado) suele valorarse mejor que entrar en pánico o intentar ocultarlo.
¿Es un problema si mi proyecto no tiene ningún aporte técnico original?
No, siempre que lo digas con esos términos: la mayoría de las tesinas de grado en Sistemas son aplicaciones correctas de tecnología existente a un problema concreto, y eso es exactamente lo que se evalúa a ese nivel de formación, no un aporte de investigación propio de un posgrado o un doctorado.