«Ya tengo la aplicación funcionando, ¿por qué me piden que investigue?» es la frase que más se repite en los comités de Ingeniería de Sistemas cuando revisan un anteproyecto de desarrollo de software. La confusión es comprensible: en esta carrera, a diferencia de otras, el estudiante sí puede construir el objeto de su trabajo de grado con sus propias manos. Pero construir el sistema es la mitad del trabajo, no el trabajo completo — y esa segunda mitad es exactamente lo que un comité busca antes de aprobar la modalidad.
Esta guía explica cuándo un programa de Ingeniería de Sistemas en Colombia acepta el desarrollo de software como modalidad de grado, qué estructura espera el comité y las razones más frecuentes por las que un anteproyecto de este tipo se devuelve.
Cuándo se acepta el desarrollo de software como modalidad de grado
La mayoría de programas de Ingeniería de Sistemas y afines en Colombia contemplan el desarrollo de un producto de software —aplicación web, móvil, sistema de información, prototipo con componente de inteligencia artificial— como una de las modalidades u opciones de grado disponibles, junto a la monografía, la pasantía o el artículo científico. Lo que varía de un programa a otro es el nombre exacto de la modalidad («proyecto de grado aplicado», «trabajo de grado tecnológico», «proyecto integrador») y, sobre todo, cuánto peso relativo tienen el desarrollo técnico y el componente investigativo en la evaluación final.
Antes de proponer el tema, verifica en el reglamento de tu programa tres cosas concretas: si la modalidad exige un cliente o usuario real (no solo un caso hipotético), si pide explícitamente una evaluación del producto con algún instrumento o método, y qué porcentaje de la nota corresponde al documento escrito frente al producto entregado. Esas tres respuestas cambian por completo cómo debes planear las últimas semanas antes de la entrega.
Hay además una distinción que conviene aclarar desde el anteproyecto: no es lo mismo un producto de software como trabajo de grado (donde el sistema es el objeto central de evaluación) que un trabajo de grado que usa software como herramienta para resolver un problema de otra naturaleza —por ejemplo, un análisis de datos con un script propio dentro de una investigación cuantitativa. La estructura de esta guía corresponde al primer caso; si tu software es solo el medio para responder una pregunta de investigación, el documento se organiza como cualquier trabajo empírico y el sistema pasa a ser parte del capítulo de método.
La diferencia entre un producto de software y una tesis sobre ese producto
El error de origen más común es tratar el documento como un manual técnico del sistema: pantallazos, diagrama entidad-relación, listado de funcionalidades. Eso documenta el producto, pero no lo convierte en trabajo de grado. Lo que el comité necesita ver es la misma estructura argumentativa de cualquier investigación aplicada, adaptada al desarrollo:
- Un problema real y delimitado —no «no existe un sistema para X», sino qué proceso concreto falla y con qué evidencia.
- Un estado del arte de soluciones existentes, con criterios explícitos de comparación (no solo «no hay nada parecido»).
- Una metodología de desarrollo declarada y justificada, no solo mencionada de pasada.
- Una evaluación del resultado frente a los objetivos planteados, con un método reconocido, no solo la opinión del propio estudiante de que «funciona bien».
La evaluación es la pieza que más frecuentemente falta. Si tu producto ya está construido y necesitas decidir con qué instrumento validarlo —usabilidad, aceptación tecnológica, cumplimiento de requisitos—, la guía sobre qué instrumento usar para evaluar el software de tu trabajo de grado compara seis opciones con sus requisitos de aplicación.
La estructura que espera el comité, capítulo por capítulo
| Capítulo | Qué debe contener |
|---|---|
| Planteamiento del problema | El proceso o necesidad real, con evidencia de que el problema existe (encuesta corta, entrevistas, datos operativos de la organización) |
| Estado del arte / soluciones existentes | Comparación de al menos tres alternativas ya existentes (comerciales, de código abierto o académicas) con una tabla de criterios, no solo una lista |
| Marco teórico y tecnológico | Los conceptos y las tecnologías que sustentan las decisiones de arquitectura, con la justificación de por qué se eligió ese stack y no otro |
| Metodología de desarrollo | El marco de trabajo elegido (Scrum, RUP, XP, Kanban) con las adaptaciones reales que hiciste, no la teoría genérica copiada de un libro |
| Diseño y arquitectura del sistema | Diagramas de arquitectura, de casos de uso o de componentes, con la decisión de diseño explicada, no solo mostrada |
| Implementación | Descripción de los módulos críticos y las decisiones técnicas relevantes, evitando el listado exhaustivo de todas las pantallas |
| Pruebas y evaluación | Pruebas funcionales, y el instrumento de evaluación elegido aplicado a usuarios reales o representativos |
| Resultados y discusión | Lo que la evaluación mostró, comparado contra los objetivos y contra el estado del arte del capítulo dos |
| Conclusiones y trabajo futuro | Qué se logró, qué limitaciones tuvo el producto y qué módulos quedaron para una versión futura |
Qué metodología de desarrollo declarar (y cómo se justifica)
Las metodologías ágiles (Scrum, Kanban, XP) dominan los trabajos de grado de desarrollo de software en Colombia, y eso está bien siempre que se declaren con honestidad. El punto que más preguntan los jurados es cómo se adaptó una metodología pensada para equipos a un desarrollo hecho por una sola persona: quién asumió el rol de product owner, cómo se hicieron los sprints sin un equipo real, qué artefactos se mantuvieron (historias de usuario, backlog, retrospectivas) y cuáles se simplificaron.
Una alternativa menos usada pero perfectamente válida cuando el sistema tiene requisitos muy estables desde el inicio es un modelo más estructurado como RUP o un ciclo en cascada adaptado, siempre que se justifique por qué el proyecto no se beneficiaba de la iteración ágil —por ejemplo, cuando el alcance viene fijado por un contrato o por un requerimiento institucional cerrado.
Las cinco razones más frecuentes de rechazo
- El documento describe el sistema, pero no argumenta decisiones. Mostrar el diagrama de base de datos sin explicar por qué se normalizó así, o por qué se eligió determinado patrón de arquitectura, convierte el capítulo en un manual, no en una tesis.
- No hay comparación real con el estado del arte. Decir que «no existe nada similar» sin haber buscado sistemáticamente alternativas es la objeción más común en la sustentación.
- La evaluación es la opinión del propio desarrollador. «El sistema funciona correctamente y es fácil de usar» sin un instrumento aplicado a usuarios reales no constituye evidencia.
- El alcance creció sin control (scope creep) y el documento no lo declara. Si el sistema final tiene módulos que no estaban en los objetivos iniciales, el comité pregunta por qué cambiaron los objetivos y espera que quede documentado, no oculto.
- Falta el repositorio de código y el historial de control de versiones como evidencia. Cada vez más programas piden el enlace al repositorio con el historial de commits como prueba de que el desarrollo fue propio y progresivo, no ensamblado la última semana.
Si tu trabajo ya está en desarrollo y quieres organizar el flujo de trabajo, el control de versiones y las pruebas antes de llegar a la sustentación, la guía sobre las preguntas del jurado sobre la metodología te prepara para el mismo tipo de interrogatorio que enfrenta cualquier trabajo de grado, adaptado a las decisiones técnicas de un desarrollo de software.
Cómo se sustenta un desarrollo de software distinto a una investigación
La sustentación de un trabajo de desarrollo de software tiene un ingrediente que las tesis puramente documentales no tienen: la demostración en vivo. Y la demostración en vivo es también donde más se pierden puntos por causas evitables.
- Prueba el entorno de demostración con al menos 48 horas de anticipación, en el mismo computador y la misma red que usarás el día de la sustentación, nunca en el computador de otra persona sin haberlo probado antes.
- Prepara un guion de demostración con datos de prueba ya cargados. Improvisar datos en vivo frente al jurado multiplica el riesgo de un error visible y consume minutos valiosos.
- Ten lista una alternativa sin conexión a internet (video grabado de respaldo, entorno local) si el sistema depende de una API externa o de una base de datos en la nube que podría fallar el día de la sustentación.
- Prepárate para preguntas sobre decisiones que no se ven en pantalla: por qué esa base de datos y no otra, cómo se protegen las contraseñas de los usuarios, qué pasaría si el sistema recibiera diez veces más tráfico. La demostración muestra el «qué»; el jurado pregunta por el «por qué».
Muchos de estos criterios de coherencia entre lo que se promete en los objetivos y lo que finalmente se sustenta se resumen en una sola herramienta de una página: la matriz de consistencia, que en un desarrollo de software conecta cada objetivo específico con el módulo que lo resuelve y con el criterio de evaluación que demuestra que se cumplió.
Preguntas frecuentes
¿Un trabajo de grado de desarrollo de software necesita un cliente real?
Depende del reglamento del programa. Muchos exigen una organización o un grupo de usuarios reales que valide el sistema; otros aceptan un caso de estudio simulado si se declara así explícitamente. Verifícalo antes de diseñar el capítulo de evaluación, porque cambia qué instrumento puedes aplicar.
¿Puedo usar un proyecto que ya hice para una materia o una pasantía como trabajo de grado?
En general sí, siempre que se amplíe con el componente investigativo que el trabajo de grado exige —estado del arte, evaluación formal, discusión de resultados— y que se declare el origen del proyecto con transparencia ante el comité.
¿Qué pasa si el sistema no queda terminado al 100 % para la entrega?
Lo habitual es delimitar el alcance del proyecto desde el anteproyecto a un conjunto de módulos o funcionalidades mínimas viables, y declarar el resto como trabajo futuro. Entregar un sistema parcial pero bien evaluado es preferible a uno completo sin evaluación.
¿Cuántas alternativas debo comparar en el estado del arte?
No hay un número fijo en la norma, pero tres a cinco alternativas con una tabla de criterios comparables (funcionalidades, tecnología, costo, limitaciones) suele ser el estándar que satisface a un jurado de Ingeniería de Sistemas.
¿El repositorio de código debe ser público?
No necesariamente público en internet, pero sí accesible para el comité, con el historial de commits visible como evidencia del proceso de desarrollo. Si el proyecto tiene información sensible de una organización, un repositorio privado compartido con el jurado cumple el mismo propósito.
¿Puedo trabajar en equipo un desarrollo de software como trabajo de grado?
Sí, en la mayoría de programas, siempre que el documento deje claro qué módulos o componentes desarrolló cada integrante. Un reparto de responsabilidades ambiguo es motivo frecuente de preguntas incómodas en la sustentación, porque el jurado evalúa el aporte individual de cada estudiante, no solo el producto final del equipo.
¿Un trabajo de grado de inteligencia artificial o machine learning sigue esta misma estructura?
Sí, con un ajuste: el capítulo de evaluación cambia de instrumento de usabilidad a métricas de desempeño del modelo (precisión, sensibilidad, matriz de confusión, validación cruzada), y el estado del arte compara arquitecturas o algoritmos en vez de productos de software terminados. El resto del esqueleto —problema, marco teórico, metodología, implementación, discusión— se mantiene igual.