Una tesis de Ingeniería Informática tiene siete capítulos habituales: introducción, marco teórico o estado del arte, metodología, análisis y diseño, desarrollo e implementación, evaluación de resultados, y conclusiones. El capítulo que la distingue de otras carreras es el de desarrollo e implementación: ahí se documenta el sistema, la aplicación o el algoritmo que construiste, no solo lo que investigaste sobre él.
Esta estructura cambia según si tu memoria es de producto (construyes un sistema funcional y lo evalúas) o de investigación (comparas algoritmos, evalúas un método, propones una mejora sobre trabajo existente). Ambas comparten el esqueleto, pero el peso de cada capítulo se distribuye distinto. Abajo está el detalle de cada uno.
¿Qué va en la introducción de una tesis de Ingeniería Informática?
Lo mismo que en cualquier memoria — contexto, problema, objetivos, alcance — pero con un elemento adicional casi siempre exigido: los límites técnicos del sistema. Qué plataformas soporta, qué no resuelve, con qué volumen de datos o usuarios se probó. Declarar el alcance técnico desde la introducción evita que en la defensa te pregunten por funcionalidades que nunca prometiste construir.
¿Marco teórico o estado del arte: cuál corresponde?
En Ingeniería Informática casi siempre se usan ambos, mezclados en un mismo capítulo o en dos separados según el reglamento de tu escuela:
- Marco teórico: los conceptos técnicos que sustentan tu solución — patrones de arquitectura, algoritmos base, paradigmas de programación, protocolos.
- Estado del arte: qué soluciones existen ya para tu problema — papers, sistemas comerciales, trabajos de tesis anteriores — y en qué se diferencia la tuya. Este es el capítulo que justifica que tu memoria no reinventa algo que ya existe sin aportar nada nuevo.
La lógica general para construir cualquiera de los dos, incluidas las técnicas de búsqueda de literatura, está en qué es el marco teórico.
¿Qué diferencia hay entre metodología y desarrollo e implementación?
Esta es la confusión más frecuente en la carrera. Son dos capítulos distintos que muchos estudiantes mezclan:
| Capítulo | Responde | Contenido típico |
|---|---|---|
| Metodología | ¿Cómo vas a trabajar y a evaluar? | Metodología de desarrollo (Scrum, Kanban, cascada), plan de evaluación, métricas que vas a medir, criterios de éxito |
| Desarrollo e implementación | ¿Qué construiste exactamente? | Arquitectura del sistema, diagramas (casos de uso, clases, componentes, base de datos), decisiones de diseño y por qué se tomaron, stack tecnológico |
La metodología declara el proceso — por ejemplo, sprints de dos semanas con entregables definidos si usaste Scrum. El desarrollo documenta el producto de ese proceso: la arquitectura final, los módulos, las decisiones técnicas relevantes. Confundir ambos suele significar que la memoria describe el proceso de trabajo pero nunca explica realmente cómo quedó construido el sistema — y eso es lo primero que pregunta la comisión.
¿Qué debe incluir el capítulo de desarrollo e implementación?
Cuatro elementos que casi ninguna memoria de Ingeniería Informática puede omitir:
- Arquitectura del sistema. Un diagrama de alto nivel — capas, componentes, cómo se comunican — con una explicación de por qué se eligió esa arquitectura y no otra.
- Modelo de datos. Diagrama entidad-relación o de clases, según corresponda, con las decisiones de normalización o de estructura que se justifiquen.
- Stack tecnológico justificado. No basta con listar el lenguaje y el framework: hay que explicar por qué se eligieron frente a alternativas razonables para el problema.
- Fragmentos de código relevantes. No el código completo — eso va en un anexo o en un repositorio enlazado — sino los fragmentos que ilustran una decisión de diseño importante, comentados.
¿Qué pruebas técnicas se documentan en el capítulo de desarrollo?
Un capítulo de desarrollo sin evidencia de pruebas suele leerse como un sistema que nunca se validó técnicamente, aunque haya funcionado en la demostración. Tres niveles conviene documentar, aunque no todos apliquen a todo proyecto:
- Pruebas unitarias. Verifican que cada función o método aislado hace lo que debe. Documenta qué framework usaste (JUnit, Jest, pytest, según tu stack) y qué porcentaje de cobertura alcanzaste, no solo que «se hicieron pruebas».
- Pruebas de integración. Verifican que los módulos funcionan correctamente entre sí — por ejemplo, que el backend y la base de datos se comunican como se espera bajo condiciones reales, no solo en aislamiento.
- Pruebas de aceptación o de usuario. Verifican que el sistema completo cumple los requisitos desde la perspectiva de quien lo va a usar, muchas veces con un protocolo de tareas guiadas y un cuestionario de satisfacción al final.
Si tu proyecto integró pruebas automatizadas dentro de un pipeline de integración continua, ese es un dato metodológico que vale la pena declarar explícitamente: demuestra que las pruebas corrieron de forma sistemática durante el desarrollo y no solo al final, como una verificación de último minuto antes de la entrega.
¿Cómo se evalúan los resultados en una memoria de software?
A diferencia de una memoria empírica clásica, en Ingeniería Informática los «resultados» no siempre son datos estadísticos de una muestra de personas. Depende del tipo de memoria:
| Tipo de memoria | Qué se evalúa | Cómo |
|---|---|---|
| Producto/sistema | Funcionalidad, usabilidad, rendimiento | Pruebas funcionales, pruebas de carga, pruebas de usabilidad con usuarios reales, métricas de tiempo de respuesta |
| Algoritmo/método | Precisión, eficiencia, escalabilidad | Comparación cuantitativa contra un baseline o algoritmos existentes, con conjuntos de datos estándar del área |
| Aplicación de investigación | Efecto sobre un problema real | Estudio de caso, piloto con usuarios, encuesta de satisfacción |
El error más común es no definir métricas de éxito antes de construir el sistema. Si no declaraste en la metodología qué ibas a medir (tiempo de respuesta bajo cierta carga, tasa de error, puntaje de usabilidad), llegar al capítulo de resultados sin esos números predefinidos deja la evaluación sin punto de comparación.
Un ejemplo aplicado, capítulo por capítulo
Toma un tema típico de memoria: un sistema de agendamiento de horas para un consultorio pequeño. Así se vería cada capítulo:
- Introducción: el problema (agendamiento manual por teléfono, sobrecupos, inasistencias sin aviso), el alcance (web y móvil, hasta 500 pacientes registrados, sin integración con FONASA en esta versión).
- Estado del arte: sistemas comerciales existentes (agendamiento de clínicas grandes), por qué no sirven para un consultorio pequeño con presupuesto acotado, y qué patrón de arquitectura usan trabajos similares.
- Metodología: Scrum con sprints de dos semanas, cuatro entrevistas a personal administrativo para levantar requisitos, métricas de éxito definidas de antemano (reducir el tiempo de agendamiento telefónico en al menos 30%, tasa de error de doble reserva menor al 2%).
- Desarrollo: arquitectura cliente-servidor con API REST, modelo de datos con entidades paciente-hora-profesional, stack justificado por el presupuesto y la curva de aprendizaje del equipo, pruebas unitarias sobre la lógica de disponibilidad de horas.
- Resultados: tiempo de agendamiento medido antes y después con el personal administrativo real, tasa de dobles reservas en el piloto de cuatro semanas, encuesta de usabilidad a los pacientes que usaron la versión web.
- Conclusiones: si se cumplieron las métricas definidas en la metodología, qué decisión de arquitectura limitó la escalabilidad a más de un consultorio, y la integración con FONASA como línea de continuidad.
Este es el patrón que se repite en la mayoría de las memorias de la carrera, cambiando el dominio del problema: control de inventario, gestión académica, monitoreo IoT, o un modelo de aprendizaje automático en vez de un sistema transaccional.
¿Qué va en las conclusiones de una tesis de Ingeniería Informática?
Además de lo habitual — respuesta a los objetivos, limitaciones, trabajo futuro — este capítulo suele incluir dos elementos técnicos propios de la carrera: lecciones de diseño (qué decisión arquitectónica cambiarías si empezaras de nuevo) y líneas de continuidad técnica (qué módulos quedaron pendientes, qué escalabilidad no se probó, qué integración quedó fuera del alcance). Ese segundo punto suele ser justamente lo que un profesor guía sugiere como semilla de una memoria de continuación.
Si todavía no tienes clara la diferencia entre memoria de título y tesis en tu escuela, esa distinción general está en qué es una memoria de título y en qué se diferencia de una tesis, y el recorrido completo con todos los hitos del proceso —no solo los capítulos— está en cómo hacer una memoria de título.
Si tu memoria usa herramientas de IA para generar parte del código o de la documentación, conviene tener claro dónde está el límite entre apoyarse en la herramienta y delegarle la autoría — el mismo problema que enfrenta cualquier carrera, explicado en escribir la tesis con IA sin perder la autoría. Y si tu proyecto tiene un componente metodológico empírico —por ejemplo, evaluar tu sistema con usuarios reales mediante entrevistas o encuestas—, la lógica de declarar el método explícitamente en vez de darlo por sentado es la misma que se exige en cómo redactar la metodología de una tesis, aunque esa guía esté escrita para otra disciplina.
Tesify te ayuda a estructurar y redactar los capítulos de tu memoria de Ingeniería Informática, desde el estado del arte hasta las conclusiones, con sugerencias que apruebas tú y el criterio técnico siempre bajo tu control. Puedes partir con el plan gratuito.
Preguntas frecuentes
¿Cuántos capítulos tiene una tesis de Ingeniería Informática?
Siete es lo más habitual: introducción, marco teórico o estado del arte, metodología, análisis y diseño, desarrollo e implementación, evaluación de resultados y conclusiones. Algunas escuelas fusionan análisis y diseño con desarrollo en un solo capítulo extenso.
¿Qué diferencia hay entre una memoria de producto y una de investigación?
Una memoria de producto construye un sistema funcional completo y lo evalúa con usuarios o pruebas técnicas. Una de investigación compara algoritmos, propone una mejora sobre trabajo existente o evalúa un método, con menos énfasis en un sistema terminado y más en la evidencia comparativa.
¿El código completo va dentro del cuerpo de la memoria?
No. El cuerpo incluye solo los fragmentos que ilustran una decisión de diseño relevante, comentados. El código completo va en un anexo o, más frecuente hoy, en un repositorio enlazado que la comisión puede revisar aparte.
¿Qué metodología de desarrollo debo declarar si trabajé solo?
Puedes declarar una metodología ágil adaptada a un desarrollador individual — sprints personales con entregables definidos — o un enfoque incremental clásico. Lo importante es que el proceso declarado sea el que realmente seguiste, no uno elegido porque suena más riguroso.
¿Cómo defino las métricas de éxito de mi sistema?
Se definen antes de construir, en el capítulo de metodología: qué vas a medir (tiempo de respuesta, tasa de error, puntaje de usabilidad, precisión de un modelo) y qué valor consideras un resultado aceptable. Sin esa definición previa, el capítulo de resultados no tiene con qué compararse.
¿Necesito comparar mi sistema con otros existentes?
Si tu memoria es de investigación, sí, casi siempre contra un baseline o algoritmos ya publicados. Si es de producto, no siempre es indispensable, pero mencionar alternativas existentes en el estado del arte fortalece la justificación de por qué construiste una solución propia.
¿El capítulo de conclusiones necesita trabajo futuro obligatoriamente?
No es obligatorio en todos los reglamentos, pero es una práctica muy extendida en la carrera porque documenta qué quedó fuera del alcance: integraciones no probadas, escalabilidad no evaluada, módulos pendientes. Suele ser lo que un profesor guía sugiere como continuación.
¿Puedo usar herramientas de IA para generar parte del código de mi memoria?
Depende del reglamento de tu escuela, pero en general se acepta como apoyo si tú entiendes, revisas y puedes explicar cada decisión técnica en la defensa. El problema aparece cuando el código se genera sin comprensión propia y no puedes justificarlo frente a la comisión.