Las preguntas de la comisión en la defensa de una memoria de Ingeniería Informática no buscan hacerte tropezar: buscan verificar que entiendes las decisiones técnicas que tomaste, no solo que el sistema funciona. Casi todas nacen del capítulo de diseño, del de pruebas o de la sección de limitaciones, en la misma lógica que explica qué es la defensa de tesis en general y qué te van a preguntar. Esta guía reúne las que aparecen con más frecuencia en esta carrera específica, un mapa de qué capítulo origina cada pregunta, un ejemplo de intercambio real y cómo prepararlas en la semana previa a la defensa.
Cómo se relacionan las preguntas con cada capítulo de tu memoria
Antes de entrar en las preguntas específicas, conviene entender la lógica general: cada pregunta de la comisión sale de un capítulo concreto de tu documento, no de la nada, y esa es la razón por la que dos memorias distintas de la misma carrera terminan con defensas muy diferentes entre sí. Si tu estructura de tesis de Ingeniería Informática incluye un capítulo de diseño de arquitectura, espera preguntas sobre esas decisiones; si incluye un capítulo de pruebas, espera preguntas sobre cobertura y metodología de testing; si tu matriz de consistencia declaró indicadores específicos, espera que te pidan mostrar si se cumplieron. Repasar tu propio documento capítulo por capítulo, imaginando qué preguntaría alguien que lo lee con ojo crítico, es la preparación más eficiente que puedes hacer.
| Capítulo de tu memoria | Tipo de pregunta que suele originar |
|---|---|
| Introducción y problema | Por qué este problema es relevante, quién se beneficia del sistema |
| Estado del arte / marco teórico | En qué se diferencia tu solución de las que ya existen |
| Diseño de arquitectura | Por qué esa arquitectura y no otra, qué alternativas se descartaron |
| Implementación | Por qué ese stack tecnológico, qué limitaciones tiene |
| Pruebas | Cobertura, tipos de prueba, defectos encontrados y cómo se resolvieron |
| Resultados y evaluación | Si se cumplieron los indicadores de la matriz de consistencia |
| Limitaciones y trabajo futuro | Qué no se implementó y qué harías distinto |
Preguntas sobre decisiones de arquitectura
La comisión suele pedir que justifiques, no que describas, cada decisión de diseño. Prepárate para responder: ¿por qué elegiste esta arquitectura (monolítica, de microservicios, en capas) y no otra? ¿Qué alternativas consideraste y por qué las descartaste? ¿Cómo se relaciona esta arquitectura con los requisitos no funcionales que definiste en tu matriz de consistencia o de requisitos? Una respuesta débil típica es «porque es lo que aprendimos en clase»; una respuesta sólida conecta la decisión con un requisito concreto de tu propio proyecto, por ejemplo el volumen de usuarios esperado o la necesidad de escalar un componente de forma independiente del resto.
Preguntas sobre el stack tecnológico
Espera preguntas del tipo: ¿por qué este lenguaje o framework y no otro? ¿Qué limitaciones tiene la tecnología que elegiste? ¿Cómo habría cambiado tu proyecto si hubieras usado una alternativa? No necesitas defender tu elección como la única correcta; necesitas mostrar que la elegiste con criterio (curva de aprendizaje, soporte, rendimiento, lo que ya conocía el equipo) y que conoces sus límites, no solo sus ventajas. Si tu proyecto nació de una práctica profesional convertida en memoria, prepárate además para explicar qué restricciones tecnológicas te impuso la empresa y cuáles fueron decisión propia.
Preguntas sobre pruebas y calidad
Un clásico: ¿qué porcentaje de tu sistema está cubierto por pruebas automatizadas, y por qué ese nivel es suficiente (o no) para este proyecto? ¿Qué tipos de prueba aplicaste (unitarias, de integración, de carga, de usabilidad) y por qué esos y no otros? ¿Qué defectos encontraste durante las pruebas y cómo los resolviste? Si tu cobertura de pruebas es baja, no lo ocultes: explica por qué priorizaste otras partes del desarrollo y qué harías distinto con más tiempo. Ten preparado, si es posible, un reporte o captura de tu suite de pruebas: mostrar evidencia concreta responde la pregunta más rápido que una descripción verbal.
Preguntas sobre escalabilidad y seguridad
Aunque tu sistema sea un prototipo acotado, la comisión puede preguntar: ¿qué pasaría si este sistema tuviera que soportar diez o cien veces más usuarios? ¿Qué vulnerabilidades de seguridad consideraste (inyección, autenticación, exposición de datos) y cómo las mitigaste? No se espera que un proyecto de pregrado resuelva la seguridad a nivel de producción, pero sí que hayas pensado en los riesgos más evidentes de tu propio dominio (por ejemplo, datos de salud o financieros si tu sistema los maneja) y que sepas nombrarlos, aunque la respuesta final sea «no lo implementé, pero identifiqué este riesgo y lo dejo como trabajo futuro».
Preguntas sobre comparación con soluciones existentes
Si tu memoria plantea un sistema nuevo, espera: ¿en qué se diferencia tu solución de las que ya existen en el mercado o en la literatura? ¿Por qué no usar directamente una herramienta ya disponible? La respuesta debe mostrar que investigaste el estado del arte antes de construir, no que asumiste que nada parecido existía sin buscar. Si tu sistema sí reutiliza herramientas existentes (una librería, un framework de terceros), ten claro qué parte del trabajo es tuya y cuál viene de la herramienta, porque la comisión suele preguntar exactamente esa línea divisoria.
Preguntas sobre limitaciones y trabajo futuro
Casi toda defensa cierra con una versión de: ¿qué no alcanzaste a implementar y por qué? ¿Qué harías distinto si empezaras de nuevo? Reconocer limitaciones con honestidad suele valorarse más que insistir en que el proyecto no tiene ningún punto débil; la comisión sabe que ningún proyecto de pregrado está completo en el sentido de un producto comercial. Una buena respuesta nombra una limitación concreta (no genérica, como «faltó tiempo») y explica exactamente qué se necesitaría para resolverla.
Cómo preparar la demo
Si tu memoria incluye una demostración en vivo del sistema, prepara un guion breve que muestre el flujo principal en pocos minutos, y ten un plan B (capturas de pantalla o un video grabado) por si falla la conexión o el entorno el día de la defensa. Practica la demo completa al menos una vez en las condiciones reales (mismo computador, misma red) antes del día de la presentación, no solo en tu entorno de desarrollo habitual, y prepara datos de prueba que no dependan de un servicio externo que pueda estar caído justo ese día.
Un guion mental para responder preguntas técnicas difíciles
Cuando te hagan una pregunta que no anticipaste, un orden razonable de respuesta es: primero, repite la pregunta con tus propias palabras para confirmar que la entendiste; segundo, ubica la respuesta dentro de una decisión que ya tomaste en el proyecto, aunque sea parcial; tercero, si de verdad no sabes la respuesta, dilo con claridad y ofrece cómo la investigarías. Improvisar una respuesta inventada es el error que más rápido se nota cuando la comisión pide profundizar.
Ejemplo de intercambio (ilustrativo)
El siguiente diálogo es ficticio, pero refleja el tipo de intercambio real de una defensa:
Comisión: «¿Por qué eligieron una base de datos NoSQL en vez de una relacional para este sistema?»
Estudiante: «Porque los datos que manejamos no tienen una estructura fija entre registros —cada evento del sistema puede traer campos distintos— y una base relacional habría requerido muchas tablas o columnas vacías. Consideramos PostgreSQL con campos JSON como alternativa, pero descartamos esa opción porque el volumen de escritura esperado favorecía el modelo de documentos.»
Comisión: «¿Y qué pierden al no tener las garantías transaccionales de una base relacional?»
Estudiante: «Perdemos consistencia inmediata entre colecciones relacionadas; lo mitigamos con un patrón de consistencia eventual, que es aceptable para este caso porque ningún proceso crítico depende de leer el dato en el mismo instante en que se escribe.»
Nota cómo la respuesta nombra la alternativa considerada, el criterio de decisión y reconoce explícitamente el costo (no las garantías transaccionales) de la elección. Ese mismo patrón —alternativa, criterio, costo reconocido— funciona para casi cualquier pregunta de justificación técnica que te hagan, sea sobre base de datos, framework, patrón de diseño o estrategia de despliegue.
Cómo prepararte en la semana previa
Dedica un bloque de tiempo, no solo la noche anterior, a releer tu propia memoria completa como si fueras un miembro de la comisión que la ve por primera vez: subraya cada afirmación que no puedas justificar de inmediato en voz alta. Ensaya la presentación completa al menos dos veces frente a otra persona, cronometrando el tiempo para no excederte del que te asigna el reglamento. Revisa también tu capítulo de limitaciones: es, junto con el de decisiones de arquitectura, el que genera más preguntas de seguimiento. Si tu escuela permite llevar apuntes o el documento impreso a la defensa, marca con anticipación las páginas de las tablas y diagramas que más probablemente te van a pedir mostrar.
Preguntas frecuentes
¿Debo saber de memoria todas las líneas de código de mi sistema?
No. La comisión evalúa que entiendas las decisiones de diseño y puedas explicar cómo funciona tu sistema a alto nivel, no que memorices cada línea. Ten a mano el código para mostrar fragmentos específicos si te lo piden.
¿Qué pasa si no sé responder una pregunta técnica en la defensa?
Es preferible reconocer que no lo sabes con certeza y razonar en voz alta hacia una respuesta posible, que inventar una respuesta que no puedes sostener si te piden que profundices.
¿Cuánto dura la defensa de una memoria de Ingeniería Informática?
Varía según la escuela: consulta el reglamento de titulación de tu carrera para el formato exacto de tu defensa, incluida la duración de la presentación y de la ronda de preguntas.
¿Qué pasa si la demo falla en vivo durante la defensa?
Ten siempre un respaldo grabado o capturas de pantalla del flujo principal. Un fallo técnico manejado con calma, mostrando el plan B, suele afectar mucho menos la evaluación que perder tiempo intentando arreglarlo en vivo frente a la comisión.
¿Es buena idea practicar la defensa con alguien que no sea de la carrera?
Sí: si esa persona puede seguir tu explicación sin conocimientos técnicos previos, es una señal de que tu presentación es clara. Complementa esa práctica con al menos una ronda frente a alguien que sí entienda el dominio técnico y pueda hacerte preguntas difíciles de verdad.
¿Qué diferencia hay entre una pregunta de aclaración y una pregunta de objeción?
Una pregunta de aclaración pide que expliques mejor algo que ya está en tu documento; una pregunta de objeción cuestiona una decisión o un resultado. Ambas se responden con el mismo patrón —contexto, justificación, límite reconocido si corresponde—, pero vale la pena distinguirlas mentalmente para no ponerte a la defensiva ante una simple aclaración.
Prepara tu presentación con Tesify
Tesify te ayuda a estructurar la presentación de tu defensa y a redactar un guion de la demostración que después ajustas y practicas tú mismo. La comprensión técnica del sistema que defiendes siempre depende de ti, no de ninguna herramienta.