Ingeniería de Software (Software Engineering) — Programa del curso
Docente: Gerson Garrido
1. Descripción
Programar es escribir código que funciona hoy. La ingeniería de software es lo que hace falta para que ese código siga funcionando cuando cambian los requisitos, cuando el equipo crece, cuando pasan los años y cuando lo usan personas reales: entender qué se necesita, diseñar para el cambio, comprobar que el software hace lo que dice, revisarlo, integrarlo y desplegarlo sin miedo, y operarlo cuando falla. Como lo resume el texto principal del curso, es programación integrada en el tiempo.
El curso tiene una parte que no tenía hace pocos años: las herramientas de IA que escriben código. Las tratamos como parte del tema, no como un atajo ni como un tabú. Un agente puede escribir en minutos un módulo que pasa sus propias pruebas y está mal; lo que lo hace confiable es lo mismo que hace confiable el código de una persona: una especificación clara, pruebas que de verdad verifican, revisión, integración continua y alguien que entiende lo que se entrega. El curso se organiza en cuatro partes:
- Proceso y requisitos — qué es la ingeniería de software, procesos ágiles, requisitos con un cliente real y especificaciones.
- Diseño y arquitectura — complejidad y módulos profundos, conceptos, APIs, patrones de diseño, arquitectura y decisiones documentadas.
- Calidad — pruebas unitarias, basadas en propiedades y de mutación, revisión de código, análisis estático, integración continua y dependencias.
- Producción y evolución — despliegue y operación, desarrollo con agentes de IA, seguridad, privacidad, ética y mantenimiento.
El proyecto del semestre es un producto real: cada equipo construye, en tres sprints, una aplicación para un cliente de verdad (un negocio, una asociación, una oficina de la universidad), desde las entrevistas hasta el producto desplegado y entregado. Los laboratorios usan Kallpa, la aplicación de reservas de un complejo deportivo que escribimos para el curso, en TypeScript con Node.js 26.
Los términos técnicos van en inglés cuando así se dicen y así aparecen en la documentación (pull request, backlog, sprint, pipeline, deploy); los que de verdad se usan en español (requisito, prueba, revisión de código, despliegue) van en español, con el inglés entre paréntesis la primera vez. El glosario reúne los principales. Las lecturas y la documentación de las herramientas están en inglés.
2. Carga horaria
| Componente | Horas/semana | Formato |
|---|---|---|
| Teoría | 4 h | Dos sesiones de 2 h (Sesión A y Sesión B) |
| Laboratorio | 2 h | Una sesión práctica guiada |
3. Resultados de aprendizaje
Al finalizar el curso, el estudiante será capaz de:
- Explicar en qué se diferencia la ingeniería de software de la programación (tiempo, escala, decisiones con costos) y elegir un proceso de desarrollo adecuado para un equipo y un cliente.
- Obtener requisitos de un cliente real mediante entrevistas, escribirlos como historias de usuario con criterios de aceptación verificables y priorizarlos en un backlog.
- Escribir especificaciones y documentos de diseño, diseñar módulos e interfaces que reduzcan la complejidad, y documentar decisiones de arquitectura con sus alternativas.
- Verificar software con pruebas unitarias, basadas en propiedades y de mutación, revisión de código y análisis estático, y juzgar con qué confianza se puede entregar.
- Construir un pipeline de integración y entrega continuas, desplegar una aplicación en contenedores, observarla en producción y responder a un incidente con un postmortem.
- Usar herramientas y agentes de IA para desarrollar software con criterio: darles especificaciones y contexto, verificar lo que producen y reconocer sus riesgos (código incorrecto que parece correcto, inyección de prompts, dependencias inventadas, licencias).
- Trabajar en equipo con Git y GitHub (ramas, pull requests, revisión), comunicarse con un cliente y considerar la seguridad, la privacidad, la accesibilidad y la ética de lo que se construye.
4. Bibliografía
Texto principal: Titus Winters, Tom Manshreck y Hyrum Wright. Software Engineering at Google: Lessons Learned from Programming Over Time. O’Reilly, 2020. Libre en línea: https://abseil.io/resources/swe-book
Es el libro que mejor describe cómo se trabaja hoy en equipos grandes: código que dura años, revisión de código, pruebas a escala, dependencias, integración y entrega continuas. Es gratuito y cada semana cita sus capítulos.
Complementos:
- John Ousterhout. A Philosophy of Software Design, 2.ª edición. Yaknyam Press, 2021. Para las semanas de diseño (no es gratuito): https://web.stanford.edu/~ouster/cgi-bin/book.php
- Daniel Jackson. The Essence of Software. Princeton University Press, 2021. Diseño por conceptos: https://essenceofsoftware.com/
- Armando Fox y David Patterson. Engineering Software as a Service: An Agile Approach Using Cloud Computing, 2.ª edición. El texto del curso CS 169 de Berkeley: desarrollo ágil, BDD y TDD. El sitio enlaza el libro en PDF, videos y diapositivas: https://www.saasbook.info/
- Betsy Beyer y otros. Site Reliability Engineering. O’Reilly, 2016. Libre en línea: https://sre.google/sre-book/table-of-contents/
- Los reportes de investigación de DORA sobre desempeño de equipos y adopción de IA: https://dora.dev/research/
- OWASP Top 10 y OWASP Top 10 para aplicaciones con LLM: https://owasp.org/www-project-top-ten/, https://genai.owasp.org/llm-top-10/
Cursos de referencia. El programa toma ideas de cursos que se dictan actualmente; sus materiales se enlazan, no se copian:
- Carnegie Mellon, 17-313 Foundations of Software Engineering: uso responsable de IA desde la primera semana, especificaciones, pruebas basadas en propiedades, arquitectura, CI/CD y ética, con un proyecto en sprints: https://cmu-313.github.io/
- Carnegie Mellon, AI Tools for Software Development (curso experimental, otoño de 2025): https://www.cs.cmu.edu/news/2025/ai-tools-for-software
- Stanford, CS146S The Modern Software Developer: desarrollo con agentes, MCP, desarrollo guiado por especificaciones: https://themodernsoftware.dev/
- University of Maryland, CMSC 398Z Coding with AI: https://www.cs.umd.edu/class/fall2025/cmsc398z/
- UC Berkeley, CS 169A Introduction to Software Engineering: https://www2.eecs.berkeley.edu/Courses/CS169A/
- University of Washington, CSE 403 Software Engineering: https://homes.cs.washington.edu/~rjust/courses/CSE403/
Todo este material se enlaza, no se copia: los ejemplos, ejercicios, figuras, la aplicación Kallpa y los enunciados del curso son propios.
5. Calendario
Este es el calendario oficial del curso. Cada semana enlaza a su guía con lecturas, objetivos y actividades de laboratorio. Las sesiones marcadas con ✂️ se pueden comprimir o pasar a lectura autónoma si se pierden clases por feriados.
| Sem. | Sesión A (2 h) | Sesión B (2 h) | Laboratorio (2 h) | Entregas |
|---|---|---|---|---|
| 1 | Presentación del curso · ¿Qué es la ingeniería de software? | La IA en el ciclo de desarrollo: qué hace bien, qué hace mal y cómo usarla con responsabilidad | Entorno y Git en equipo: ramas, pull requests y conflictos sobre Kallpa | P0 publicado |
| 2 | Procesos: cascada, iterativo, Scrum y Kanban | Planificación y estimación · Caso: el Boeing 737 MAX | Issues, tablero y estimación del backlog de Kallpa | |
| 3 | Requisitos: elicitación y entrevistas | Historias de usuario, criterios de aceptación y priorización | Entrevista simulada y backlog de una funcionalidad de Kallpa | P0 entrega · P1 publicado |
| 4 | Especificaciones: contratos, invariantes y tipos | Design docs y desarrollo guiado por especificaciones | De la especificación al código, con y sin un agente | |
| 5 | Diseño: complejidad, módulos profundos y ocultamiento de información | Conceptos, acoplamiento y cohesión | Refactorizar un módulo superficial de Kallpa | P1 entrega · P2 publicado |
| 6 | Interfaces y APIs: REST, errores, versionado e idempotencia | Patrones de diseño que siguen vigentes | Diseñar y documentar una API con OpenAPI | |
| 7 | Arquitectura: capas, hexagonal, monolito y microservicios | Atributos de calidad y decisiones de arquitectura (ADR) · ✂️ diagramas C4 | Un ADR y un diagrama de contenedores para Kallpa | |
| 8 | Repaso | Examen parcial | — | P2 entrega (demo del sprint 1) · P3 publicado |
| 9 | Pruebas: unitarias, dobles de prueba y cobertura | TDD y BDD | Pruebas unitarias de Kallpa con node:test |
|
| 10 | Pruebas basadas en propiedades y fuzzing | Pruebas de mutación y oráculos para código generado | Encontrar con fast-check y Stryker errores que las pruebas no ven | |
| 11 | Revisión de código | Análisis estático, tipos y linters · Revisar código escrito por IA | Revisar pull requests de otro equipo; TypeScript estricto y ESLint | P3 entrega (demo del sprint 2) · P4 publicado |
| 12 | Integración continua y build | Dependencias y cadena de suministro | Un pipeline de GitHub Actions para Kallpa | |
| 13 | Despliegue: contenedores, entornos y feature flags | Operación: observabilidad, SLOs, incidentes y postmortems | Desplegar Kallpa, observarla y escribir el postmortem de un incidente simulado | |
| 14 | Desarrollo con agentes: herramientas, MCP e ingeniería de contexto | Productos con modelos de lenguaje: evals, inyección de prompts y costo | Un conjunto de evals para una funcionalidad con LLM | P4 entrega (demo del sprint 3) · P5 publicado |
| 15 | Seguridad y privacidad desde el diseño | Ética, accesibilidad y licencias · ✂️ procedencia del código generado | Auditoría de seguridad y accesibilidad de Kallpa | |
| 16 | Mantenimiento: código heredado, deuda técnica y deprecación | Presentaciones finales | Defensa oral de los proyectos | P5 entrega |
| — | Examen final en el período de exámenes |
Sobre el examen final: el calendario asume que la universidad tiene un período de exámenes después de la semana 16. Si no lo tiene, el final se toma en la Sesión A de la semana 16 y los temas ✂️ pasan a lectura autónoma.
6. Proyectos
Cada equipo construye un producto para un cliente real: una persona u
organización con un problema que se pueda resolver con una aplicación web
pequeña (un negocio del barrio, una asociación, un laboratorio o una oficina
de la universidad). El cliente se consigue en las primeras semanas y el
docente lo aprueba. P0 es individual y se hace sobre Kallpa; P1–P5 son del
equipo. Cada entrega tiene una revisión automática (make check en el
repositorio del equipo) y una revisión del docente y del cliente. El detalle y
las reglas de entrega están en projects/README.md.
| # | Entrega | Lo que agrega | Publicado | Entrega |
|---|---|---|---|---|
| P0 | Primer aporte | Un issue de Kallpa resuelto en una rama, con pruebas y un pull request revisado (individual) | Sem. 1 | Sem. 3 |
| P1 | Requisitos | Cliente, entrevistas, historias de usuario con criterios de aceptación, backlog priorizado y prototipo | Sem. 3 | Sem. 5 |
| P2 | Diseño y primer sprint | Design doc, ADRs, especificación de la API y un esqueleto que funciona de punta a punta; demo del sprint 1 | Sem. 5 | Sem. 8 |
| P3 | Segundo sprint: calidad | Funcionalidades con pruebas unitarias y de propiedades, cobertura mínima, revisión de todos los pull requests y análisis estático; demo del sprint 2 | Sem. 8 | Sem. 11 |
| P4 | Tercer sprint: entrega continua | Pipeline de CI/CD, despliegue, observabilidad y el postmortem de un incidente; demo del sprint 3 | Sem. 11 | Sem. 14 |
| P5 | Producto final | Revisión de seguridad (OWASP Top 10), producto entregado al cliente, documentación para quien lo mantenga, retrospectiva, registro de uso de IA y defensa oral | Sem. 14 | Sem. 16 |
7. Uso de herramientas e inteligencia artificial
Las herramientas de IA son parte del tema del curso, y algunas semanas enseñan a usarlas. Por eso se permiten en el proyecto y en los laboratorios, con una condición: el equipo responde por todo lo que entrega como si lo hubiera escrito a mano. Los exámenes se rinden sin ellas.
| Herramienta | Proyecto y laboratorios | Exámenes |
|---|---|---|
Diagnósticos del compilador y del intérprete (tsc, los errores de Node.js) y herramientas que revisan el programa mientras corre |
Sí | Solo si el examen se rinde en el contenedor del curso |
| Documentación oficial (Node.js, TypeScript, las herramientas del curso) y búsqueda en la web | Sí | No |
| Autocompletado del editor que completa nombres y líneas, sin generar soluciones enteras | Sí | No |
| Corrector ortográfico, traductor y herramientas de accesibilidad | Sí | Solo las de accesibilidad que el estudiante necesite |
| Formateadores y linters (el formateador del editor, ESLint) | Sí | Solo si el examen se rinde en el contenedor del curso |
| IA generativa para explicar conceptos, errores o código, sin que escriba el código entregado | Sí, con registro | No |
| IA generativa que escribe código, pruebas o documentos (chat, autocompletado de bloques, agentes) | Sí, con registro | No |
Cómo se declara. Cada equipo lleva un registro de uso de IA
(docs/registro-ia.md en su repositorio, desde P1): fecha, herramienta, qué se
pidió, qué se aceptó, qué se rechazó y por qué. En los laboratorios, el
registro va en el mismo archivo del repositorio en el que se trabaja. Un cambio grande hecho con una
herramienta de IA y sin registro cuenta como no entregado. Las herramientas
de las cinco primeras filas no se declaran.
Explicación oral. A cualquier estudiante se le puede pedir que explique de forma oral cualquier parte de lo que entregó su equipo: qué hace, por qué es así y cómo se verificó, lo haya escrito a mano o con ayuda de una herramienta. La defensa oral de la semana 16 es una de esas ocasiones, pero no la única.
8. Políticas
- Equipos: P0 es individual. P1–P5 se hacen en equipos de 4 a 5 personas, que se mantienen durante todo el semestre salvo acuerdo con el docente.
- Integridad académica: se puede discutir ideas con otros equipos, pero el código, los documentos y las pruebas entregados deben ser del equipo. Copiar el trabajo de otro equipo o de un proyecto publicado cuenta como plagio.
- Herramientas e IA: ver la sección 7.
- Clientes: el equipo trata al cliente con respeto y puntualidad, no le promete lo que no puede entregar y no usa sus datos reales sin su permiso escrito (ver semana 15).
9. Entorno de trabajo
Todo el trabajo práctico se hace dentro de un contenedor Docker con Node.js 26
(que ejecuta TypeScript directamente), Git, la CLI de GitHub y las
herramientas de calidad del curso (tsc, ESLint, fast-check, StrykerJS,
Redocly), que funciona igual en Linux, Windows (WSL2) y macOS (incluido Apple
Silicon). Hace falta una cuenta de GitHub. Instrucciones en
labs/README.md.