Una tesis de Ingeniería en Sistemas no se estructura como una de ciencias sociales. Cuando el producto es un software, los capítulos centrales son análisis de requerimientos, diseño, implementación y pruebas, y el capítulo de resultados no cuenta cómo se programó: demuestra que el sistema cumple los requerimientos que se fijaron antes de escribir una línea de código. Aquí va la estructura capítulo por capítulo, qué contiene cada uno, qué se manda a anexos y los errores que producen las rondas de corrección más largas.
La decisión previa —si tu trabajo es investigación, desarrollo tecnológico o mejora de proceso, y qué tipo de evidencia exige cada uno— está resuelta en cómo hacer una tesis de Ingeniería. Este artículo toma la ruta más frecuente en Sistemas Computacionales, Informática y Software, que es la de desarrollo tecnológico, y la convierte en un índice defendible.
El índice que esperan los comités de Sistemas
Los nombres varían entre escuelas —en algunos programas del IPN el trabajo recepcional se llama trabajo terminal y se desarrolla en dos semestres; en el TecNM conviven la tesis y el informe de residencia—, pero el esqueleto es notablemente estable:
| Capítulo | Qué contiene | El error más frecuente |
|---|---|---|
| 1. Introducción | Contexto, planteamiento del problema con números, objetivos, justificación, alcance y limitaciones | Un problema descrito como «la empresa no tiene sistema», sin medir qué cuesta no tenerlo |
| 2. Marco teórico y estado del arte | Conceptos, tecnologías candidatas y una tabla comparativa de soluciones existentes | Definir «qué es una base de datos» y no comparar ningún sistema similar |
| 3. Metodología | Metodología de desarrollo (Scrum, cascada, XP, RUP) y método de evaluación del sistema | Decir «se usó Scrum» sin sprints, sin roles y sin evidencia |
| 4. Análisis y diseño | Requerimientos funcionales y no funcionales, casos de uso, arquitectura, diagramas UML, modelo de datos | Diagramas sin decisiones: nadie explica por qué esa arquitectura y no otra |
| 5. Implementación | Pila tecnológica justificada, módulos, fragmentos de código explicados, integración | Cientos de páginas de código en el cuerpo del documento |
| 6. Pruebas y resultados | Plan de pruebas, matriz de casos, resultados contra los requerimientos, métricas de calidad | Reportar que «todas las pruebas pasaron» sin decir cuáles ni cómo |
| 7. Conclusiones y trabajo futuro | Cumplimiento de objetivos, aportación, límites y siguiente versión | Prometer en trabajo futuro lo que el capítulo uno ya prometía |
| Anexos | Manual de usuario, manual técnico, código o enlace al repositorio, instrumentos de evaluación | Anexos que nadie cita desde el cuerpo |
Lo que sigue es cada capítulo en detalle, con lo que un sínodo de la carrera pregunta al leerlo.
Capítulo 1: el problema se plantea con números
En Sistemas, el planteamiento del problema tiene una trampa: el estudiante ya decidió que va a construir un sistema y escribe el problema al revés, para justificarlo. La forma correcta es medir el estado actual antes de proponer nada: cuántos minutos toma el proceso manual, cuántos errores de captura hay por semana, cuántas solicitudes se pierden. Sin esa línea base, el capítulo de resultados no tiene contra qué comparar.
Los objetivos específicos de una tesis de software suelen mapearse uno a uno con los capítulos centrales: analizar los requerimientos, diseñar la arquitectura, implementar los módulos, evaluar el sistema. Es legítimo y ordena el documento, pero cada objetivo necesita un criterio de cumplimiento verificable, no solo un verbo. El alcance, además, es el lugar para decir qué módulos no se construyen; los comités de Sistemas leen esa lista con atención porque es la que evita que el examen se convierta en una lista de funcionalidades faltantes.
Capítulo 2: el estado del arte es una tabla, no un glosario
El marco teórico de una tesis de software tiene dos partes que conviene separar. La primera son los conceptos y tecnologías necesarios para entender la solución, y debe ser breve: nadie necesita tres páginas sobre qué es HTTP. La segunda es el estado del arte, y es la que sostiene la aportación: una tabla de sistemas existentes —comerciales, de código abierto, publicados en congresos— comparados por las mismas características que tu sistema va a ofrecer, con el hueco que tú vas a llenar en la última columna.
La literatura de esta carrera se publica en gran parte en memorias de congreso y en repositorios de código, y se cita con frecuencia en estilo IEEE y no en APA; la elección depende del manual de tu escuela y está discutida en formato institucional frente a APA 7.
Capítulo 3: dos metodologías, no una
Es el capítulo más confuso de la carrera porque la palabra «metodología» significa dos cosas distintas y las dos tienen que estar:
- La metodología de desarrollo —Scrum, cascada, XP, RUP, Kanban— describe cómo se construyó el software. Si dices Scrum, el capítulo tiene que mostrar el product backlog, los sprints con sus fechas, los roles y al menos un ejemplo de revisión. Si en realidad trabajaste solo y en cascada, dilo: un comité prefiere una cascada honesta a un Scrum de papel.
- El método de evaluación describe cómo vas a demostrar que el sistema funciona: qué se mide, con qué instrumento, contra qué criterio. Aquí entran las métricas de desempeño, la matriz de pruebas y, si evalúas con usuarios, el instrumento de usabilidad y el tamaño de la muestra.
Cómo se definen variables, indicadores y métricas de desempeño en una tesis de esta área, y cuántas repeticiones se necesitan para hablar de desempeño, está en metodología de una tesis de Ingeniería.
Capítulo 4: análisis y diseño, donde se toman las decisiones
Es el capítulo que distingue a una tesis de un proyecto de materia, y el que más preguntas recibe en el examen.
Requerimientos
Separa funcionales (qué hace el sistema) de no funcionales (qué tan bien lo hace: tiempo de respuesta, usuarios concurrentes, seguridad, compatibilidad). Numéralos, porque el capítulo de pruebas los va a citar uno por uno. El estándar de referencia para especificar requerimientos es ISO/IEC/IEEE 29148, que sustituyó al antiguo IEEE 830; si tu escuela todavía pide la plantilla de IEEE 830, úsala y menciona la relación entre ambos. Si trabajas con historias de usuario, cada una necesita criterios de aceptación escritos, no solo la frase «como usuario quiero».
Casos de uso y diagramas
Los diagramas UML —casos de uso, clases, secuencia, actividades— no son ilustraciones: son evidencia de análisis. La regla práctica es que cada diagrama vaya acompañado de un párrafo que explique qué decisión documenta y que ningún diagrama aparezca sin ser citado en el texto. Diez diagramas sin explicación valen menos que tres explicados.
Arquitectura y datos
Aquí va la decisión más importante del documento y casi siempre la peor justificada: por qué esa arquitectura (monolítica, en capas, cliente-servidor, microservicios), por qué ese modelo de datos y por qué esa pila tecnológica. La justificación se escribe como comparación de alternativas contra los requerimientos no funcionales, no como preferencia personal. «Se eligió porque el equipo lo conocía» es una razón real, y se puede decir, pero no puede ser la única.
Capítulo 5: implementación sin volcar el código
El error clásico: pegar el código completo en el cuerpo del documento. El código va en un anexo o, mejor, en un repositorio con licencia y enlace permanente, y el capítulo lleva solo los fragmentos que explican una decisión no trivial: el algoritmo central, el manejo de un caso difícil, la integración con un servicio externo. Cada fragmento se explica; un bloque de cuarenta líneas sin párrafo alrededor no es evidencia de nada.
Dos advertencias propias de la carrera. La primera: las bibliotecas, fragmentos y componentes que reutilizaste tienen licencia y autor, y se declaran; la frontera entre reutilizar y plagiar está en plagio de código fuente en tesis. La segunda: si usaste asistentes de programación, la política de tu escuela decide qué se declara y cómo; lo que nunca es aceptable es presentar como propio un módulo que no puedes explicar línea por línea en el examen.
Capítulo 6: los resultados son la comparación contra los requerimientos
Este capítulo no narra la construcción. Recorre la lista de requerimientos del capítulo cuatro y muestra, para cada uno, la prueba que lo verificó y su resultado. Tres niveles que un comité espera ver:
- Pruebas funcionales. Una matriz con identificador del requerimiento, caso de prueba, datos de entrada, resultado esperado, resultado obtenido y estado. Las que fallaron se reportan con su corrección o con su justificación.
- Pruebas no funcionales. Tiempo de respuesta bajo carga, consumo de recursos, compatibilidad. Se miden varias veces, no una, y se reportan con promedio y dispersión. Si comparas dos configuraciones o tu sistema contra el proceso anterior, la comparación de promedios se resuelve con una prueba estadística, no a ojo.
- Evaluación con usuarios. Si el sistema tiene interfaz, la usabilidad se mide con un instrumento publicado —la escala SUS de diez reactivos es la más usada por su brevedad— aplicado a un grupo de usuarios reales del perfil objetivo, con el número de participantes justificado.
Para organizar las pruebas no funcionales, el modelo de calidad de producto de ISO/IEC 25010 es la referencia habitual: sus ocho características —adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad— sirven como lista de verificación de qué evaluaste y qué dejaste fuera. No hace falta cubrir las ocho; hace falta decir cuáles y por qué.
Capítulo 7 y anexos
Las conclusiones responden objetivo por objetivo, con el criterio de cumplimiento que fijaste en el capítulo uno, y nombran lo que no se logró. El trabajo futuro es la siguiente versión del sistema, no la lista de lo que faltó por tiempo. Los anexos habituales en esta carrera son el manual de usuario, el manual técnico o de instalación, los instrumentos de evaluación y el código o el enlace al repositorio; todos se citan desde el cuerpo, o no existen para el lector.
Cómo cambia el índice según el tipo de sistema
| Tipo de trabajo | Qué se refuerza | Qué se reduce |
|---|---|---|
| Sistema de información para una organización | Levantamiento de requerimientos con el usuario, manual de usuario, pruebas de aceptación | Estado del arte académico |
| Aplicación móvil | Usabilidad, compatibilidad entre dispositivos, consumo de batería y datos | Diagramas de despliegue complejos |
| Sistema con aprendizaje automático | Conjunto de datos, métricas del modelo, comparación con líneas base publicadas | Casos de uso tradicionales |
| Prototipo de hardware con software embebido | Pruebas de desempeño físico, repeticiones, tolerancias | Manual de usuario extenso |
Si tu trabajo tiene memoria de cálculo, normativa y obra en lugar de código, la estructura equivalente para esa rama está en estructura de una tesis de Ingeniería Civil; y si tu ruta de titulación es la residencia profesional del TecNM, el formato es otro y está en el informe de residencia profesional.
Los cinco errores que más rondas de corrección cuestan
- Empezar a programar antes de escribir los requerimientos. Se nota porque el capítulo cuatro describe lo que el sistema ya hace, en lugar de lo que debía hacer.
- Requerimientos sin numerar. Sin identificadores no hay trazabilidad, y sin trazabilidad el capítulo de pruebas no se puede escribir.
- Una sola medición de desempeño. Un tiempo de respuesta medido una vez es una anécdota; diez mediciones con promedio y desviación son un resultado.
- El manual de usuario dentro del capítulo de implementación. Va en anexos; el capítulo explica decisiones, no botones.
- Conclusiones que describen el sistema. Las conclusiones evalúan el cumplimiento de objetivos; la descripción ya se hizo en cinco capítulos.
Cuando el sistema ya funciona y las pruebas están hechas, lo que queda es convertir el repositorio, la bitácora de sprints y las hojas de resultados en siete capítulos con estructura académica. Tesify te ayuda a redactar cada capítulo de tu tesis de Ingeniería en Sistemas con este orden, a mantener la trazabilidad entre objetivos, requerimientos y pruebas, y a dar formato a las referencias en IEEE o APA 7 según lo pida tu escuela. Las decisiones de arquitectura y cada resultado de prueba siguen siendo tuyos, porque son exactamente lo que te van a preguntar.
Preguntas frecuentes
¿Cuántos capítulos tiene una tesis de Ingeniería en Sistemas?
Lo habitual son siete: introducción, marco teórico y estado del arte, metodología, análisis y diseño, implementación, pruebas y resultados, y conclusiones, más los anexos. Algunas escuelas fusionan análisis y diseño con implementación, o pruebas con resultados; el reglamento de tu programa decide los nombres, no el número.
¿El código completo va en la tesis?
No en el cuerpo. El código va en un anexo o en un repositorio con enlace y licencia, y el documento incluye solo los fragmentos que explican una decisión no trivial, cada uno con su párrafo de explicación. Un comité evalúa las decisiones, no la cantidad de líneas.
¿Necesito hipótesis en una tesis de desarrollo de software?
Normalmente no. Una tesis de desarrollo tecnológico se plantea con objetivos, requerimientos y criterios de aceptación, y el capítulo de resultados verifica su cumplimiento. Lleva hipótesis cuando compara dos algoritmos, dos arquitecturas o el sistema contra el proceso anterior con una medición estadística.
¿Qué diferencia hay entre la metodología de desarrollo y la metodología de investigación?
La de desarrollo (Scrum, cascada, XP) describe cómo se construyó el software. La de investigación o evaluación describe cómo se demostró que funciona: qué se midió, con qué instrumento y contra qué criterio. Una tesis de Sistemas necesita las dos, en el mismo capítulo o en dos secciones separadas.
¿Cómo evalúo la calidad del sistema?
Con una matriz de pruebas que recorra los requerimientos numerados, mediciones repetidas de los requerimientos no funcionales y, si hay interfaz, un instrumento de usabilidad aplicado a usuarios reales. El modelo de ISO/IEC 25010 sirve para decidir qué características evaluar y para justificar cuáles quedaron fuera.
¿Uso IEEE o APA en una tesis de Sistemas?
Lo fija el manual de titulación de tu escuela. Muchas escuelas de Ingeniería piden IEEE con referencias numeradas entre corchetes; otras, sobre todo cuando comparten reglamento con otras carreras, piden APA 7. Confírmalo por escrito antes de capturar la bibliografía.