Si tu trabajo de grado es un desarrollo de software, hay tres herramientas que el comité espera ver evidenciadas en el documento y que muchos estudiantes dejan para última hora: el control de versiones, los diagramas UML y el registro de pruebas. No son un requisito burocrático — son la evidencia de que el sistema se construyó de forma progresiva y de que las decisiones de diseño se pueden rastrear. Esta guía es paso a paso: qué configurar desde el primer día, cómo se conecta cada herramienta con un capítulo del documento y qué capturas o exportaciones debes guardar desde ya.
Paso 1. Configurar el control de versiones desde el primer commit
Crea el repositorio (GitHub, GitLab o Bitbucket funcionan igual de bien para este propósito) el mismo día que empieces a escribir código, no cuando el sistema ya esté avanzado. Un repositorio con historial de tres meses es evidencia; uno creado la semana de la entrega con veinte commits del mismo día es una bandera roja que cualquier jurado con experiencia técnica detecta de inmediato.
- Crea el repositorio en privado si el proyecto tiene información sensible de una organización, y agrega a tu director o a un correo institucional como colaborador con permiso de lectura, para que pueda verificar el historial sin que tengas que hacer capturas.
- Configura un archivo
.gitignoredesde el primer commit, para no subir archivos de configuración local, credenciales ni carpetas generadas automáticamente. - Crea una rama principal estable (
main) y trabaja los avances en ramas de funcionalidad (feature/login,feature/reportes), aunque trabajes solo. Esa práctica, documentada en el capítulo de metodología, demuestra que aplicaste una convención profesional y no solo escribiste código de corrido. - Etiqueta (tag) las versiones que entregas a tu director o al comité, por ejemplo
v0.1-anteproyecto,v0.5-avance-medio,v1.0-entrega-final. Esas etiquetas son las que después citas en el capítulo de implementación como hitos del proyecto.
Paso 2. Adoptar una convención de commits que sirva como evidencia
Un historial con mensajes como «cambios», «arreglos», «asdf» no sirve como evidencia de nada, aunque el historial exista. Adopta una convención simple desde el inicio, por ejemplo tipo: descripción breve, donde tipo es feat (nueva funcionalidad), fix (corrección), docs (documentación) o test (pruebas). Con esa convención, generar un resumen de lo que hiciste cada semana para tu bitácora de avance con tu director toma minutos, no horas reconstruyendo la memoria.
Si además llevas reuniones periódicas con tu director, la guía sobre la agenda, el acta y la bitácora de esas reuniones te ayuda a conectar cada acta con el rango de commits correspondiente, de modo que el avance quede documentado desde dos fuentes independientes.
Paso 3. Elegir la herramienta de diagramas UML
| Herramienta | Cuándo conviene | Limitación a tener en cuenta |
|---|---|---|
| draw.io / diagrams.net | Gratuita, sin instalación, se integra con Google Drive; suficiente para casos de uso, clases y despliegue de un trabajo de grado típico | No valida la sintaxis UML automáticamente; el diagrama puede verse bien y ser técnicamente incorrecto |
| StarUML | Cuando el programa exige diagramas generados desde un modelo, no solo dibujados, y valida relaciones entre clases | La versión gratuita tiene límites de exportación que conviene revisar antes de comprometerte a usarla en todo el proyecto |
| Lucidchart | Trabajo colaborativo en equipo con comentarios en tiempo real | Las funciones completas requieren plan pago; la cuenta educativa gratuita cubre lo básico |
| PlantUML | Cuando prefieres generar los diagramas desde texto y versionarlos junto con el código en el mismo repositorio | Curva de aprendizaje de la sintaxis; no es la opción más rápida si nunca la has usado |
Independientemente de la herramienta, exporta cada diagrama en un formato vectorial (SVG o PDF) además de la imagen que insertas en el documento, y guarda el archivo fuente editable en el repositorio junto con el código. Si el comité pide un ajuste al diagrama después de la sustentación, editarlo desde el archivo fuente toma minutos; rehacerlo desde cero porque solo queda la imagen final puede tomar una tarde.
Paso 4. Dejar registro de las pruebas, no solo ejecutarlas
Ejecutar pruebas sin dejar registro es indistinguible, ante el jurado, de no haberlas hecho. El registro mínimo defendible incluye:
- Casos de prueba documentados, con la entrada, el resultado esperado y el resultado obtenido, en una tabla o en la salida de un framework de pruebas (JUnit, PyTest, Jest según tu stack).
- Capturas o logs de ejecución guardados con fecha, no solo la afirmación de que «todas las pruebas pasaron».
- Pruebas de API con Postman o Insomnia, exportadas como colección, si tu sistema expone servicios web — la colección exportada es un artefacto verificable que puedes anexar.
- Un resumen de cobertura si tu lenguaje lo permite fácilmente, aunque sea aproximado, para mostrar qué proporción del sistema quedó cubierta por pruebas automatizadas frente a pruebas manuales.
Cómo conectar cada artefacto con un capítulo del documento
Cada una de estas herramientas alimenta un capítulo distinto del documento, y tenerlo claro desde el inicio evita reconstruir evidencia al final:
- Historial de commits → capítulo de metodología (evidencia del proceso iterativo) y anexos (enlace o capturas del repositorio).
- Diagramas UML → capítulo de diseño y arquitectura del sistema, con el archivo fuente en anexos.
- Casos de prueba y colecciones de API → capítulo de pruebas y evaluación, y anexos con los reportes completos.
- Etiquetas de versión → capítulo de implementación, como hitos que muestran el avance progresivo del sistema.
Si necesitas repasar qué va exactamente en cada uno de esos capítulos y cómo se justifica ante el comité, la guía sobre la tesis de desarrollo de software en Ingeniería de Sistemas desarrolla la estructura completa y las razones más frecuentes de rechazo.
Una forma rápida de verificar que no falta ningún artefacto antes de la entrega es cruzar esta lista con tu matriz de consistencia: por cada objetivo específico deberías poder señalar qué commit, qué diagrama y qué caso de prueba lo respaldan. Si un objetivo no tiene ningún artefacto asociado, es una señal temprana de que ese frente quedó pendiente.
Paso 5. Documentar el ambiente de desarrollo y las dependencias
Un artefacto que casi nadie deja preparado a tiempo es la lista exacta de dependencias y versiones que usaste, y es justo lo que necesitas si el sistema falla al reinstalarlo en el computador de la sustentación o si alguien más quiere ejecutarlo después de tu graduación.
- Exporta el archivo de dependencias de tu gestor de paquetes (
requirements.txten Python,package.jsonen Node,pom.xmlen Java) y súbelo al repositorio desde el inicio, no al final. - Escribe un archivo README con los pasos exactos de instalación y ejecución, probado literalmente en un computador distinto al tuyo al menos una vez antes de la entrega.
- Registra la versión del motor de base de datos y del lenguaje que usaste, porque un cambio de versión menor puede introducir comportamientos distintos que compliquen la demostración en vivo.
Este paso es también el que más frecuentemente salva una demostración cuando algo falla: si el README funciona, puedes reinstalar el sistema en minutos en un computador de respaldo. Si tu evaluación del sistema todavía está pendiente, la guía sobre qué instrumento usar para evaluar el software de tu trabajo de grado compara las opciones más usadas en Ingeniería de Sistemas en Colombia.
Errores que le cuestan puntos a un desarrollo bien hecho
- Un solo commit gigante al final. Aunque el sistema funcione perfectamente, un historial sin progresión sugiere que el trabajo no se hizo cuando dice el cronograma.
- Diagramas UML hechos después de programar, solo para el documento. El comité pregunta por decisiones de diseño que deberían haber precedido al código; un diagrama post hoc rara vez es consistente con la implementación real.
- No guardar el archivo fuente editable de los diagramas. Si solo tienes la imagen final, no puedes demostrar cómo evolucionó el diseño.
- Pruebas que no se pueden volver a ejecutar. Si el jurado pide repetir una prueba en la sustentación y el entorno no está preparado para eso, la evidencia deja de ser verificable en el momento que más importa.
Preguntas frecuentes
¿Es obligatorio usar Git para un trabajo de grado de desarrollo de software?
No está escrito como obligación en la mayoría de reglamentos, pero es la forma estándar de demostrar que el desarrollo fue progresivo. Cada vez más programas de Ingeniería de Sistemas en Colombia lo piden explícitamente como evidencia.
¿Qué pasa si empecé el proyecto sin control de versiones y ya llevo varios meses?
Inicializa el repositorio ahora mismo con el código actual como primer commit, y documenta en el capítulo de metodología que el control de versiones formal se adoptó a partir de esa fecha, explicando cómo llevabas el respaldo antes (copias fechadas, por ejemplo). Es preferible ser honesto sobre el origen tardío que simular un historial completo.
¿Cuántos diagramas UML necesito?
Depende de la complejidad del sistema, pero un mínimo defendible incluye el diagrama de casos de uso, el diagrama de clases y un diagrama de despliegue o de componentes. Sistemas con lógica de negocio compleja suelen necesitar además diagramas de secuencia para los flujos críticos.
¿Debo incluir el código fuente completo en el documento?
No, salvo que tu programa lo exija explícitamente. Lo habitual es incluir fragmentos de código relevantes para explicar una decisión técnica en el cuerpo del documento, y dejar el código completo accesible mediante el enlace al repositorio.
¿Postman es suficiente para documentar las pruebas de un sistema sin API?
No; Postman sirve específicamente para pruebas de servicios web. Si tu sistema no expone una API, el registro de pruebas debe adaptarse al tipo de sistema: pruebas de interfaz, pruebas unitarias del código o pruebas de integración con la base de datos, según corresponda.
¿Debo pagar por GitHub, StarUML o Postman para mi trabajo de grado?
No debería ser necesario. Las versiones gratuitas de GitHub, draw.io, la mayoría de frameworks de pruebas y el plan básico de Postman cubren lo que exige un trabajo de grado típico. Reserva un plan pago solo si tu proyecto necesita una función muy específica que la versión gratuita no ofrezca, y compáralo primero con las alternativas de código abierto.
¿El README cuenta como parte de la evaluación del comité?
Generalmente no se califica como un capítulo aparte, pero es lo primero que revisa cualquier persona que intente ejecutar tu sistema después de la sustentación, incluido un jurado que quiera probarlo por su cuenta. Un README claro y probado suma a la percepción general de calidad del trabajo, aunque no tenga una nota asignada explícitamente.
¿Estás documentando el desarrollo de tu trabajo de grado? Organiza los capítulos de tu trabajo de grado en Tesify mientras avanzas con el repositorio, los diagramas y las pruebas, y mantén todo listo para la sustentación.