¿Cómo se escribe el resumen y las palabras clave de un TFG de Ingeniería Informática?

Respuesta rápida: El resumen de un TFG de Ingeniería Informática sigue la convención problema-método-resultados-contribución propia de los artículos de ciencia de la computación, no la estructura APA de objetivo-método-conclusión-implicaciones. Las palabras clave (index terms) se eligen del sistema ACM Computing Classification System o de términos técnicos verificables en IEEE Xplore, nunca por traducción libre de conceptos generales.

¿En qué se diferencia el resumen de un TFG de Informática del resumen APA genérico?

El resumen APA que exigen la mayoría de facultades de Ciencias Sociales sigue el orden objetivo → método → resultados → conclusión → implicaciones, en presente y pasado alternados. La comunidad de ciencia de la computación (IEEE, ACM) usa una convención distinta, heredada del formato de artículo científico: problema → enfoque/método → resultados → contribución. La diferencia no es cosmética: el resumen de Informática debe nombrar explícitamente qué problema técnico no estaba resuelto, qué solución propones (algoritmo, arquitectura, sistema) y qué mejora concreta aporta frente al estado anterior, en términos medibles cuando sea posible (tiempo de ejecución, precisión, escalabilidad).

¿Qué debe contener la primera frase del resumen de un TFG de Informática?

La primera frase debe plantear el problema técnico, no el tema general. «Este trabajo trata sobre inteligencia artificial» no dice nada; «los sistemas de recomendación basados en filtrado colaborativo degradan su precisión cuando el catálogo supera cierto tamaño (problema del arranque en frío a escala)» sí lo hace. Un tribunal de Informática valora que el resumen empiece identificando una limitación técnica concreta de un enfoque existente, porque eso es lo que justifica que tu TFG exista.

¿Cómo se redacta la parte de método en un TFG de desarrollo de software?

Si tu TFG es un proyecto de desarrollo (no una investigación empírica), la parte de «método» del resumen debe nombrar la arquitectura, el stack tecnológico esencial y la estrategia de validación: por ejemplo, «se diseñó una arquitectura de microservicios con autenticación OAuth2 y se validó mediante pruebas de carga con 500 usuarios concurrentes», no una lista genérica de tecnologías. El resumen no es el sitio para enumerar todo el stack (eso va en el capítulo de diseño); es el sitio para nombrar la decisión arquitectónica que más defiende tu contribución.

¿Cómo se redactan los resultados cuando el TFG es un sistema, no un experimento?

Los TFG de desarrollo de software no siempre tienen «resultados» en el sentido estadístico, pero sí tienen evidencia de que el sistema funciona: métricas de rendimiento (latencia, throughput, uso de memoria), cobertura de pruebas automatizadas, o una evaluación de usabilidad con usuarios reales. Redacta esta parte con cifras concretas siempre que existan («el sistema procesó 1.200 peticiones por segundo con una latencia media de 45 ms bajo carga simulada») en vez de afirmaciones vagas («el sistema demostró buen rendimiento»). Si tu TFG es de investigación (por ejemplo, comparar algoritmos), reporta la métrica de comparación exacta (F1-score, tiempo de convergencia, complejidad computacional) y frente a qué baseline se comparó.

¿Debo mencionar las limitaciones del sistema en el resumen?

Con una frase, no más. Un resumen de Informática puede incluir una limitación de alcance muy breve al final de la contribución («evaluado en un entorno controlado con hasta 500 usuarios concurrentes; el comportamiento a mayor escala queda como trabajo futuro»), porque acota honestamente lo que el lector puede esperar del sistema. No es el lugar para desarrollar limitaciones metodológicas extensas, que sí van completas en su propio apartado; en el resumen, una cláusula de alcance basta y evita que el tribunal la señale como omitida.

¿Qué es el ACM Computing Classification System y por qué debo usarlo para las palabras clave?

El ACM Computing Classification System (CCS) es la taxonomía jerárquica oficial que usa la Association for Computing Machinery para clasificar la literatura de ciencia de la computación, organizada en categorías como «Ingeniería de software», «Seguridad y privacidad», «Aprendizaje automático» o «Sistemas de bases de datos», cada una con subcategorías específicas (por ejemplo, dentro de aprendizaje automático: «aprendizaje supervisado», «redes neuronales»). Usar los términos exactos del CCS en vez de una traducción libre del español asegura que tus palabras clave coincidan con las que usan los índices bibliográficos reales del campo (ACM Digital Library, IEEE Xplore), lo que mejora la indexación de tu trabajo si acaba en un repositorio con buscador semántico.

¿Cuántas palabras clave lleva un TFG de Informática y en qué orden se ponen?

La convención más extendida en TFG y artículos de Informática es entre 4 y 6 términos, ordenados de más específico a más general: primero la técnica o algoritmo concreto que usas, después el dominio de aplicación, y por último la categoría amplia del campo. Ejemplo: «detección de anomalías; aprendizaje no supervisado; ciberseguridad; sistemas distribuidos». Evita repetir literalmente palabras que ya aparecen en el título, porque los sistemas de indexación las consideran redundantes, igual que en cualquier otra disciplina.

¿Debo incluir el nombre del lenguaje de programación o framework como palabra clave?

Solo si el lenguaje o framework es parte central de la contribución técnica, no un detalle de implementación. Si tu TFG evalúa específicamente el rendimiento de una técnica implementada en Rust frente a C++, «Rust» y «C++» son palabras clave legítimas. Si simplemente usaste Python porque era la herramienta disponible para implementar un algoritmo cuya novedad no depende del lenguaje, no merece ser palabra clave: ocupa espacio que debería ir a un término más informativo del CCS.

¿»Index terms» y «keywords» en inglés son lo mismo en un TFG técnico?

En la práctica se usan casi como sinónimos, pero IEEE prefiere la etiqueta «Index Terms» en sus plantillas de artículo, mientras que ACM y la mayoría de repositorios universitarios usan «Keywords». Si tu escuela no especifica cuál usar, «Keywords» es la opción más segura porque es la que reconocen los repositorios generalistas (TESEO, RiuNet, Dialnet); reserva «Index Terms» solo si estás siguiendo literalmente una plantilla IEEE para convertir el TFG en una comunicación a congreso.

¿Qué verbos en inglés describen mejor la contribución de un TFG técnico?

Los abstracts de IEEE y ACM prefieren verbos de acción directa y específica en vez de verbos genéricos: «we propose», «we design», «we implement», «we evaluate», «we demonstrate that…», en lugar de «this work deals with» o «this work is about». Cada verbo debería corresponder a una fase real de tu TFG: proponer la idea, diseñar la arquitectura, implementar el prototipo, evaluar con datos o usuarios reales, y demostrar el resultado concreto obtenido. Encadenar estos cinco verbos en ese orden es, de hecho, un esqueleto casi automático para redactar el abstract en inglés sin caer en la traducción literal del resumen en español.

¿Cómo se traduce el resumen al inglés en un TFG de Informática sin sonar traducido?

La terminología técnica de Informática en español a menudo calca directamente del inglés (algoritmo, framework, pipeline), lo que en este campo concreto reduce el riesgo de hispanismos que sí afecta a otras disciplinas. El riesgo real está en los verbos de acción: «se realizó una implementación» debería ser «a prototype was implemented», no «an implementation was realized» (realize no significa implementar en inglés técnico). Mantén frases cortas y activas siguiendo el estilo directo de los abstracts de IEEE y ACM en lugar de una traducción literal del resumen en español.

¿Qué extensión tiene el resumen de un TFG de Ingeniería Informática?

La mayoría de escuelas técnicas siguen un rango similar al de otras disciplinas, 150-250 palabras por bloque (español e inglés), aunque algunos TFG orientados a publicación en congresos siguen el límite más estricto de la conferencia de destino (por ejemplo, 150 palabras exactas en muchas call for papers de IEEE). Confirma siempre el límite de tu escuela antes de dar el resumen por cerrado: es de las pocas cifras que sí varía de forma real entre facultades técnicas.

¿En qué se diferencia el resumen si mi TFG es una revisión del estado del arte en vez de un sistema propio?

Si tu TFG es una revisión de literatura técnica (por ejemplo, sobre arquitecturas de modelos de lenguaje), el resumen sustituye «contribución técnica propia» por «síntesis crítica»: cuántos trabajos se revisaron, con qué criterio de selección, y qué vacío o tendencia identifica la revisión que no estaba sintetizado antes en ningún otro trabajo en español. El resumen general para el abstract bilingüe en formato APA sigue siendo útil como referencia de formato y checklist de revisión, aunque el contenido técnico de cada bloque cambie según lo descrito aquí.

¿Qué error de resumen penalizan más los tribunales de Informática?

El más frecuente es un resumen que describe el proceso de desarrollo («primero investigué, después diseñé, después implementé, después probé») en vez de describir el problema y la contribución. Un tribunal de Informática no necesita el cronograma en el resumen; necesita saber en la primera línea qué problema técnico resuelves y en qué se diferencia tu solución de lo que ya existía. Revisa también los 25 temas de TFG de Ingeniería Informática con proyectos software reales si todavía estás definiendo el problema técnico concreto de tu trabajo antes de escribir el resumen.

¿Puedo usar el mismo resumen para depositar el TFG y para enviarlo a un congreso?

Solo como punto de partida. El resumen del TFG suele permitirse algo más largo y contextual (situarlo dentro del grado, aunque mencionar el tutor y la universidad no forma parte del resumen académico en sí); el resumen de un artículo de congreso exige mayor densidad técnica por palabra, sin ninguna frase de relleno. Si tu TFG puede convertirse en una comunicación a congreso, la comparativa entre Google Scholar, Scopus y Web of Science te ayuda a identificar qué congreso o revista indexa mejor el tipo de contribución técnica que estás haciendo.

¿Cómo sé si mis palabras clave están normalizadas o son una invención mía?

Busca cada término candidato entre comillas en el buscador de la ACM Digital Library o en IEEE Xplore. Si el término aparece en el campo de palabras clave de varios artículos publicados en venues reconocidos de tu subárea, está normalizado y es una elección segura. Si solo aparece en trabajos de fin de grado o no aparece en absoluto, probablemente es una etiqueta que has construido tú mismo por comodidad y conviene sustituirla por el término del CCS más cercano, aunque te suene menos natural en español.

¿Qué checklist reviso antes de dar el resumen por terminado?

• La primera frase nombra un problema técnico concreto, no el tema general del TFG.
• La parte de método nombra la decisión arquitectónica o algorítmica clave, no una lista completa de tecnologías.
• Los resultados llevan cifras concretas (latencia, precisión, cobertura de pruebas) siempre que existan datos reales que las respalden.
• La contribución queda en una frase clara, distinguible de la del estado del arte previo.
• Las palabras clave están verificadas en ACM Digital Library o IEEE Xplore, no inventadas por comodidad.
• El resumen en inglés usa verbos de acción directa (propose, design, implement, evaluate) y no calca la sintaxis del resumen en español.
• Ninguna palabra clave repite literalmente un término ya presente en el título.

Con Tesify, el resumen técnico queda alineado con la contribución real del TFG

Tesify te ayuda a redactar el resumen de tu TFG de Ingeniería Informática siguiendo la convención problema-método-resultados-contribución, a elegir las palabras clave dentro del ACM CCS y a revisar que el resumen en inglés no calque estructuras del español, antes de que lo lea el tribunal.