Muchas memorias de Ingeniería Informática no nacen de una pregunta de investigación abstracta: nacen de un problema real que el estudiante detectó durante su práctica profesional en una empresa. Convertir esa experiencia en una memoria completa exige un paso que pocas guías explican bien: separar lo que fue trabajo de práctica (ejecutar tareas bajo supervisión) de lo que se convierte en memoria (un proyecto con problema, objetivos, desarrollo y evaluación propios).
Por qué no es lo mismo un informe de práctica que una memoria
El informe de práctica profesional documenta lo que hiciste durante un periodo determinado, bajo la supervisión de un jefe directo, y normalmente se evalúa con una pauta distinta a la de una memoria de título. La memoria, en cambio, exige que definas tú mismo un problema, propongas una solución con criterio propio, y la desarrolles y evalúes con el mismo rigor metodológico que cualquier otro proyecto de título de Ingeniería Informática. La conversión de práctica a memoria no es transcribir el informe de práctica con otro formato: es extraer de esa experiencia un problema con entidad propia y reconstruirlo como un proyecto de investigación aplicada.
Las seis secciones de una memoria basada en práctica profesional
| Sección | Qué contiene | Diferencia con el informe de práctica |
|---|---|---|
| 1. Contexto de la empresa y el área | Descripción breve de la organización y el equipo donde se detectó el problema, sin datos confidenciales identificables | El informe de práctica describe la empresa en detalle; la memoria la describe solo lo necesario para contextualizar el problema |
| 2. Problema o necesidad detectada | El problema real de la empresa, planteado como problema de investigación acotado | El informe de práctica lista tareas asignadas; la memoria plantea un problema con brecha explícita entre lo esperado y lo observado |
| 3. Objetivo general y específicos | Un verbo evaluable, alineado con el problema, igual que cualquier memoria | El informe de práctica no necesita objetivos de investigación formales |
| 4. Marco teórico y estado del arte | Tecnologías, patrones de diseño y soluciones similares ya existentes, comparadas con la propuesta | El informe de práctica rara vez incluye revisión de literatura técnica |
| 5. Desarrollo e implementación | Arquitectura del sistema, decisiones técnicas justificadas, capturas o diagramas del resultado | Aquí es donde más se reutiliza el trabajo real hecho durante la práctica, pero reescrito con justificación técnica, no como bitácora de tareas |
| 6. Evaluación y reflexión profesional | Cómo se midió que la solución funciona, y qué aprendiste del proceso completo | El informe de práctica evalúa tu desempeño; la memoria evalúa el sistema que construiste |
Ejemplo: de una tarea de práctica a un problema de memoria
Toma un caso realista: durante la práctica, a un estudiante le asignaron automatizar parte del control de inventario de una pyme de retail, que hasta entonces se llevaba en planillas separadas por sucursal sin sincronización entre ellas. Como tarea de práctica, eso se resume en un párrafo del informe. Convertido en problema de memoria, se reformula así: problema «La ausencia de un sistema centralizado de control de inventario en una empresa con múltiples sucursales genera discrepancias entre el stock registrado y el stock real, dificultando la toma de decisiones de reabastecimiento»; objetivo general «Desarrollar un sistema web de control de inventario centralizado que sincronice el stock entre sucursales en tiempo real»; objetivos específicos levantar los requerimientos funcionales con los encargados de cada sucursal, diseñar la arquitectura del sistema y su base de datos, implementar el módulo de sincronización, y evaluar la reducción de discrepancias de inventario tras la implementación piloto. Nota que la tarea original —«automatizar el inventario»— se convirtió en un problema con causa, consecuencia y una solución evaluable, no solo en una descripción de lo que se hizo.
Qué hacer si tu práctica cubrió varias tareas pequeñas, no un sistema completo
No todas las prácticas profesionales terminan con un sistema completo desarrollado por el estudiante: muchas consisten en varias tareas más pequeñas —corregir errores, agregar funcionalidades a un sistema ya existente, automatizar procesos puntuales— repartidas en distintas partes de una plataforma. En ese caso, la conversión a memoria no busca inflar una tarea menor a la categoría de «sistema completo»: busca identificar cuál de esas tareas, o qué patrón común entre varias de ellas, tiene entidad suficiente para convertirse en un problema de investigación aplicada. Por ejemplo, si durante la práctica corregiste varios errores de rendimiento en distintos módulos de un sistema, el problema de memoria podría no ser «corregir errores» sino «identificar y clasificar los patrones de código que generaron cuellos de botella de rendimiento en el sistema, y proponer una guía de buenas prácticas para prevenirlos» —una memoria que sí tiene un objetivo de investigación propio, construida sobre tareas que individualmente parecían menores.
Cómo elegir los criterios de evaluación de tu sistema
Una memoria de producto en Ingeniería Informática necesita evaluar el sistema desarrollado con criterios explícitos, no solo afirmar que «funciona correctamente». Los criterios típicos se agrupan en tres familias: funcionales (¿el sistema cumple los requerimientos levantados con los usuarios?, verificable con pruebas de caso de uso), de rendimiento (tiempo de respuesta, capacidad de manejar el volumen de datos esperado, medido con pruebas de carga si corresponde) y de usabilidad (¿los usuarios reales completan las tareas esperadas sin dificultad?, medido con una prueba de usabilidad estructurada o un cuestionario breve a los usuarios finales). No es necesario cubrir las tres familias en profundidad en una memoria de pregrado, pero declarar explícitamente cuáles se evaluaron y con qué método —en vez de una afirmación genérica de que el sistema «resultó exitoso»— es lo que distingue una evaluación rigurosa de una anécdota.
El rol del profesor guía y del supervisor de la empresa
Una memoria basada en práctica profesional suele tener dos figuras distintas de supervisión, y conviene aclarar desde el inicio qué rol cumple cada una: el supervisor de la empresa evalúa el cumplimiento de las tareas asignadas durante la práctica y, en muchos casos, firma una carta de aceptación o validación del proyecto desarrollado; el profesor guía evalúa el rigor metodológico de la memoria —el problema, la justificación, la evaluación— independientemente de si el supervisor de la empresa quedó conforme con el resultado técnico. Es perfectamente posible que un sistema haya funcionado bien para la empresa y, al mismo tiempo, que la memoria necesite más trabajo metodológico —marco teórico, criterios de evaluación explícitos— para cumplir los estándares académicos. Coordinar ambas evaluaciones desde el principio, en vez de asumir que una reemplaza a la otra, evita sorpresas cerca de la entrega.
Confidencialidad: qué se puede y qué no se puede incluir
Muchas empresas piden firmar un acuerdo de confidencialidad antes de aceptar a un practicante, y ese acuerdo puede seguir vigente para lo que publiques en tu memoria. Tres resguardos concretos evitan un problema legal y ético con la empresa: primero, nunca uses el nombre real de la empresa ni datos identificables si el acuerdo lo prohíbe —usa una descripción genérica del rubro y el tamaño («una empresa de retail con cuatro sucursales en la Región Metropolitana»)—; segundo, nunca publiques datos reales de clientes, ventas o información financiera de la empresa, aunque los hayas usado durante el desarrollo —sustituye por datos ficticios etiquetados como tales para las capturas y ejemplos de tu memoria—; tercero, consulta con la empresa y con tu profesor guía, antes de escribir, qué partes del código o la arquitectura puedes mostrar públicamente si el repositorio del proyecto queda de propiedad de la empresa. Declarar estos resguardos explícitamente en tu memoria —qué se omitió y por qué— es más profesional que simplemente omitirlos sin explicación. Si además tu memoria quedará en el repositorio de tu universidad, revisa qué derechos conservas sobre el documento en de quién son los derechos de autor de tu memoria de título.
Cómo se evalúa una memoria basada en práctica frente a una memoria de investigación
La distinción completa entre una memoria de producto (desarrollo de un sistema) y una memoria de investigación, capítulo por capítulo, está en cómo se estructura una tesis de Ingeniería Informática, capítulo por capítulo. Una memoria basada en práctica profesional suele caer en la categoría de memoria de producto: se evalúa por la calidad de la solución técnica, la justificación de las decisiones de diseño, y el rigor con que se midió su funcionamiento, más que por una contribución teórica al campo. Eso no reduce las exigencias metodológicas: sigue necesitando un problema bien planteado, objetivos evaluables y una evaluación con criterios explícitos, exactamente como cualquier otra memoria. La misma lógica de objetivos con verbo evaluable, alineados uno a uno con el problema, está desarrollada para cualquier carrera en cómo redactar objetivos generales y específicos para tu tesis o memoria.
Reescribir un trabajo de práctica como un proyecto de memoria completo —con problema, marco teórico, arquitectura justificada y evaluación propia— es más trabajo de estructura que de contenido nuevo, porque el desarrollo técnico ya lo hiciste. Con Tesify puedes reorganizar tu experiencia de práctica en la estructura completa de una memoria, con las referencias en APA 7 ya ordenadas. Prueba el plan gratuito antes de decidir si te sirve.
Preguntas frecuentes
¿Puedo usar directamente mi informe de práctica como memoria de título?
No sin reescribirlo: el informe de práctica documenta tareas realizadas bajo supervisión; la memoria exige un problema propio, objetivos evaluables y una evaluación metodológica del resultado, elementos que el informe de práctica normalmente no incluye.
¿Necesito autorización de la empresa para usar mi trabajo de práctica en la memoria?
Revisa el acuerdo de confidencialidad que firmaste al iniciar la práctica; si prohíbe divulgar información de la empresa, necesitas su autorización explícita o debes anonimizar y generalizar todo dato identificable antes de publicarlo en tu memoria.
¿Qué hago si el sistema que desarrollé en la práctica ya no está en uso cuando escribo la memoria?
Puedes documentarlo igual, aclarando en la memoria su estado actual; lo que importa metodológicamente es el proceso de desarrollo y evaluación, no que el sistema siga operativo al momento de la entrega.
¿Toda memoria de Ingeniería Informática basada en práctica es memoria de producto?
Muchas lo son, pero no todas: si tu trabajo además compara enfoques técnicos o evalúa una hipótesis sobre rendimiento o usabilidad con un diseño experimental propio, puede combinar elementos de ambos tipos.
¿Puedo incluir capturas de pantalla del sistema real desarrollado en la empresa?
Solo si no exponen datos confidenciales de clientes, ventas o información sensible de la empresa; en la mayoría de los casos conviene recrear las capturas con datos ficticios etiquetados como tales.
¿Qué hago si mi práctica consistió en varias tareas pequeñas y no en un sistema completo?
Busca el patrón común entre esas tareas y conviértelo en un problema de investigación propio —por ejemplo, una clasificación o guía de buenas prácticas derivada de varios casos— en vez de forzar una tarea menor a la categoría de sistema completo.
¿Qué pasa si el supervisor de la empresa y mi profesor guía evalúan distinto mi trabajo?
Es posible y no es contradictorio: el supervisor evalúa el cumplimiento de las tareas de práctica, el profesor guía evalúa el rigor metodológico de la memoria. Coordina ambas evaluaciones desde el inicio del proceso, no cerca de la entrega.