El capítulo de desarrollo de tu tesina de Ingeniería en Sistemas: cómo escribirlo en 2026

El sistema anda. Compila, se despliega, tiene tests que pasan y una demo que mostrás sin transpirar. Y sin embargo estás frente a un documento en blanco titulado «Capítulo 4 — Desarrollo» y no sabés qué poner. Es el punto exacto donde se traba la mayoría de las tesinas de Ingeniería en Sistemas en la UTN, en la UNLP, en la UNC y en las licenciaturas en Sistemas de las universidades del conurbano: el trabajo técnico está hecho, pero el trabajo de escribir sobre el trabajo técnico ni siquiera arrancó.

La confusión de fondo es que nadie te enseñó que son dos productos distintos. El sistema es un artefacto. La tesina es un argumento sobre ese artefacto. El capítulo de desarrollo es donde el artefacto se convierte en argumento, y por eso no se escribe volcando el README ni pegando pantallas.

Lo primero: tu capítulo de desarrollo no es el manual de usuario

Hay tres textos que los estudiantes confunden con el capítulo de desarrollo, y los tres hunden la nota:

• El manual de usuario. «Al hacer clic en el botón Guardar, el sistema almacena el registro.» Eso va al anexo, si va a algún lado. No aporta ni una línea de conocimiento.
• El tutorial de la tecnología. Tres páginas explicando qué es React, qué es Docker, qué es una API REST. El jurado ya sabe. Copiar la documentación oficial parafraseada además te sube el informe de similitud sin darte nada a cambio.
• El diario de obra. «Primero probé con MongoDB, después me di cuenta de que no servía, entonces pasé a PostgreSQL.» El orden cronológico de tu frustración no es una estructura.

El capítulo de desarrollo responde una sola pregunta, repetida en distintas escalas: ante este problema, ¿qué alternativas había, cuál elegiste y con qué criterio? Todo lo que no sirva para responder eso es relleno.

La estructura que funciona: cuatro bloques

1. Del problema a los requerimientos

Abrís retomando el problema que planteaste en la introducción y lo bajás a requerimientos concretos. No una lista de cincuenta ítems copiada de una plantilla: entre ocho y quince requerimientos funcionales y entre cuatro y ocho no funcionales, cada uno con un identificador (RF-01, RNF-03) que vas a reutilizar en la validación.

Los requerimientos no funcionales son los que después te salvan en la defensa, porque son medibles. «El sistema debe ser rápido» no es un requerimiento; «el tiempo de respuesta del endpoint de búsqueda debe mantenerse por debajo de 400 ms con 1.000 registros cargados» sí lo es, y podés demostrar que se cumple. Si tu tesina tiene hipótesis o preguntas de investigación explícitas, este es el punto donde tienen que engancharse con los requerimientos; si no sabés si tu trabajo lleva hipótesis o no, revisá cuándo una tesina lleva hipótesis y cuándo no antes de forzar una.

2. Decisiones de arquitectura, no descripción de arquitectura

Este es el bloque que separa una tesina de un informe de práctica profesional. No describas la arquitectura: justificala. El formato que mejor funciona es el registro de decisión de arquitectura (ADR, Architecture Decision Record), que se adapta perfecto a la prosa académica porque ya tiene la estructura de un argumento:

• Contexto: qué restricción del problema obliga a decidir algo acá.
• Alternativas consideradas: dos o tres opciones reales, con sus ventajas y sus costos.
• Decisión: cuál elegiste.
• Criterio: por qué, atado a un requerimiento no funcional identificado antes.
• Consecuencias: qué ganaste y qué resignaste. Siempre resignaste algo.

Tres o cuatro decisiones bien argumentadas (persistencia, estilo arquitectónico, estrategia de autenticación, formato de intercambio) valen más que veinte páginas describiendo cada módulo. Y las consecuencias que declarás acá alimentan directamente el capítulo donde vas a redactar las limitaciones sin debilitar tu trabajo.

3. Implementación: qué mostrar y qué no

Regla práctica: en el cuerpo del capítulo entran fragmentos de código de no más de quince líneas, y solo cuando el fragmento es el argumento. El algoritmo de matching que diseñaste vos, sí. El docker-compose.yml, no: va al anexo o al repositorio.

Los diagramas hacen el trabajo pesado. Con dos niveles del modelo C4 (contexto y contenedores) más un diagrama de secuencia del caso de uso central y el modelo entidad-relación, cubrís el 90% de lo que el jurado necesita ver. Numerá cada figura y referenciala en el texto («como se observa en la Figura 4.2»), nunca la dejes flotando; el formato exacto de numeración y epígrafe lo tenés resuelto en la guía de tablas y figuras en APA 7 dentro de Word.

Un detalle que casi nadie hace y que suma puntos: indicar la versión exacta de cada dependencia relevante y el commit hash del estado del repositorio que corresponde a lo que estás describiendo. Es reproducibilidad, y en 2026 es lo mínimo que se espera de un trabajo técnico.

4. Validación: la parte que casi todos escriben mal

«Se realizaron pruebas y el sistema funcionó correctamente» no valida nada. La validación tiene que ser una tabla donde cada requerimiento identificado en el bloque 1 tiene un método de verificación y un resultado.

Tenés tres familias de evidencia, y conviene combinar al menos dos:

• Verificación técnica: cobertura de tests, resultados de pruebas de carga (JMeter, k6, Locust), tiempos de respuesta medidos con percentiles p50/p95, consumo de memoria. Reportá la media y la dispersión, y decí cuántas corridas hiciste.
• Evaluación con usuarios: si tu sistema tiene interfaz, una prueba con entre cinco y ocho usuarios ya detecta la mayoría de los problemas graves de usabilidad. La escala SUS (System Usability Scale) tiene versión validada en español y te da un número comparable contra un promedio de referencia de 68 puntos.
• Comparación contra una línea de base: el proceso manual que reemplazás, una herramienta existente, o una implementación ingenua del mismo algoritmo. Sin línea de base, «mejora el rendimiento» no significa nada.

Si evaluás con usuarios reales, aunque sean compañeros de la facultad, estás haciendo investigación con personas: necesitás consentimiento informado y, según el reglamento de tu unidad académica, aval del comité. Revisá cómo se arma el consentimiento informado en una investigación de tesina antes de mandar el formulario, no después.

Cómo se cita el software en una tesina de sistemas

Tres casos que aparecen siempre y que se resuelven distinto:

• Un framework o biblioteca que usaste como herramienta (Spring, Django, PostgreSQL): se menciona en el texto con su versión. No necesita entrada en la bibliografía salvo que tu director/a lo pida.
• Un paper cuyo algoritmo implementaste: cita completa, obligatoria, y explicitá qué adaptaste respecto del original.
• Un dataset, una API pública o un software que es objeto de análisis: lleva referencia formal con autor, versión, año y DOI o URL. El detalle de cómo se arma cada una de esas entradas está en la guía para citar bases de datos, datasets y software en APA 7.

El orden real en que conviene escribirlo

No empieces por el principio. El orden que menos fricción genera es: primero la tabla de validación (ya tenés los datos), después los requerimientos (salen de la tabla, hacia atrás), después las decisiones de arquitectura, y al final la introducción del capítulo, que ahora podés escribir porque sabés qué estás introduciendo.

Con eso ya tenés la materia prima del capítulo siguiente. La discusión de lo que esos números significan no va acá: el capítulo de resultados se escribe sin interpretar de más, y la interpretación tiene su propio lugar.

Extensión y formato

Un capítulo de desarrollo de una tesina de grado en Sistemas suele quedar entre 25 y 40 páginas, con los anexos técnicos afuera. Si vas muy por encima, casi seguro te sobra manual de usuario. Si vas muy por debajo, probablemente te falten decisiones justificadas.

Sobre la herramienta: si tu tesina tiene mucho código, fórmulas o referencias cruzadas, LaTeX te va a ahorrar dolores de cabeza; si tu director/a corrige con control de cambios, Word gana por goleada. La comparación honesta entre Word, Google Docs y LaTeX para la tesina te evita cambiar de herramienta a mitad de camino, que es lo peor que podés hacer.

Las cuatro preguntas que te va a hacer el jurado

1. ¿Por qué elegiste X y no Y? Si el ADR está bien escrito, la respuesta ya está en el capítulo y la leés casi textual.
2. ¿Cómo sabés que funciona? Tabla de validación. Requerimiento, método, resultado.
3. ¿Qué pasa si esto escala diez veces? Por eso medís con percentiles y declarás las consecuencias de cada decisión.
4. ¿Qué harías distinto hoy? Es una invitación, no una trampa. Se responde desde las limitaciones que vos mismo declaraste.

Todo eso se ensaya. La preparación concreta de la exposición, los tiempos y el manejo de las preguntas está desarrollada en la guía de defensa de la tesina y coloquio final.

Si estás trabado en la hoja en blanco

El bloqueo típico en Sistemas no es de ideas: es de traducción. Tenés todo en la cabeza y en el repositorio, y no sabés cómo suena eso en prosa académica. Ahí sirve trabajar sobre un esqueleto ya armado en vez de empezar de cero.

Con Tesify podés armar la estructura del capítulo de desarrollo y empezar a escribirlo a partir de tus requerimientos y tus decisiones técnicas, con las referencias ordenadas en APA 7 desde el principio. El criterio de ingeniería sigue siendo tuyo —Tesify no decide tu arquitectura ni inventa tus métricas—, pero deja de ser tuyo el trabajo de pelearte con la hoja en blanco a las once de la noche. Se arranca con el plan gratuito.

Preguntas frecuentes