Proyecto: un producto para un cliente real

Durante el semestre, cada equipo construye una aplicación web pequeña para un cliente real: una persona u organización con un problema concreto que se puede resolver con software. Puede ser el negocio de un familiar, una asociación de vecinos, un club, una ONG, un laboratorio o una oficina de la universidad. El equipo entrevista al cliente, decide con él qué construir, lo diseña, lo construye en tres sprints con las prácticas del curso, lo despliega y se lo entrega con lo necesario para que alguien más lo mantenga.

El proyecto sigue el mismo orden que el curso:

P0, individual: antes de tener cliente, cada estudiante hace su primer aporte a un código que no escribió: un issue de Kallpa, la aplicación del laboratorio.
P1–P5, en equipo: requisitos, diseño y primer sprint, un segundo sprint centrado en la calidad, un tercero centrado en la entrega continua, y el producto final.

Las semanas de cada entrega están en el calendario del SYLLABUS. Cada entrega tiene su enunciado detallado en su carpeta:

#	Enunciado	Carpeta
P0	Primer aporte	`p0-primer-aporte/`
P1	Requisitos	`p1-requisitos/`
P2	Diseño y primer sprint	`p2-diseno/`
P3	Segundo sprint: calidad	`p3-calidad/`
P4	Tercer sprint: entrega continua	`p4-entrega-continua/`
P5	Producto final	`p5-producto/`

#	Entrega	Lo que agrega	Temas del curso	Publicado	Entrega
P0	Primer aporte	Un issue de Kallpa resuelto en una rama, con pruebas y un pull request revisado (individual)	Semanas 1–3	Sem. 1	Sem. 3
P1	Requisitos	Cliente, entrevistas, historias de usuario con criterios de aceptación, backlog priorizado y prototipo	Semanas 2–4	Sem. 3	Sem. 5
P2	Diseño y primer sprint	Design doc, ADRs, especificación de la API, un esqueleto que funciona de punta a punta y la demo del sprint 1	Semanas 4–7	Sem. 5	Sem. 8
P3	Segundo sprint: calidad	Pruebas unitarias y de propiedades, cobertura mínima, revisión de todos los pull requests, análisis estático y la demo del sprint 2	Semanas 9–11	Sem. 8	Sem. 11
P4	Tercer sprint: entrega continua	Pipeline de CI/CD, despliegue, observabilidad, el postmortem de un incidente y la demo del sprint 3	Semanas 12–14	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	Semanas 15–16	Sem. 14	Sem. 16

El cliente

Lo propone el equipo en la semana 3 y lo aprueba el docente. Tiene que ser una persona real, con un problema real, dispuesta a reunirse con el equipo al menos cuatro veces en el semestre (entrevistas en P1, demos al final de cada sprint) y a responder mensajes entre reuniones.
El alcance tiene que caber en el semestre: una aplicación web con unas pocas pantallas, datos propios y al menos una regla de negocio que no sea trivial (horarios, precios, turnos, inventario, permisos). Si el problema es más grande, el equipo y el cliente eligen la parte que se entrega.
Si el equipo no consigue cliente a tiempo, el docente le asigna uno.
El cliente no paga ni firma un contrato; el equipo no le promete lo que no puede entregar. El código queda en el repositorio del equipo, con una licencia acordada con el cliente (semana 15).
Datos personales: durante el desarrollo se usan datos inventados. Si el producto va a guardar datos reales de personas, el equipo pide permiso escrito al cliente y aplica lo visto en la semana 15.

Reglas de entrega

P0 es individual. P1–P5 se hacen en equipos de 4 a 5 personas que se mantienen durante el semestre salvo acuerdo con el docente.
Cada equipo trabaja en un repositorio de GitHub creado para el curso. Cada entrega es un tag en ese repositorio (p1, p2, …, p5) y se revisa el commit de ese tag; el tag tiene que estar en GitHub antes del plazo que fije el docente.
Todo cambio entra a main por un pull request revisado por otra persona del equipo, y se fusiona con un merge commit o con squash, nunca con rebase: así cada pull request deja rastro en la historia. La historia de Git es parte de lo que se revisa: quién hizo qué, cómo se revisó y cómo se resolvieron los desacuerdos.
El código corre dentro del contenedor del curso (env/run.sh), en TypeScript con Node.js 26. Las herramientas del curso (las de env/Dockerfile) se fijan como dependencias de desarrollo con sus mismas versiones (semana 12); cualquier otra dependencia de npm se justifica en un ADR.
Registro de uso de IA: cada equipo mantiene docs/registro-ia.md desde P1: fecha, herramienta, qué se pidió, qué se aceptó, qué se rechazó y por qué. Se entrega con cada tag. Un cambio grande hecho con una herramienta de IA y sin registro cuenta como no entregado.
Identificadores en inglés y comentarios en español, según la guía de estilo.

Cómo se revisa

Cada entrega tiene dos partes:

Revisión automática. Cada enunciado trae un Makefile con make check, que se corre dentro del contenedor en el repositorio del equipo. Comprueba lo que se puede comprobar con un programa: que los documentos pedidos existan y tengan las secciones pedidas, que las historias tengan criterios de aceptación, que el código pase tsc, eslint y sus pruebas, que la cobertura supere el mínimo, que cada pull request haya tenido revisión, que el pipeline exista y tenga los pasos pedidos. Una entrega que no pasa make check no se revisa a mano.

El repositorio del equipo se clona dentro de la carpeta del curso (por ejemplo en equipo-nombre/, que el .gitignore del curso ignora), y el contenedor se abre desde la carpeta del curso: así, dentro, el curso está en /work y el repositorio del equipo en /work/equipo-nombre.
```
./env/run.sh                   # desde la carpeta del curso
cd /work/equipo-nombre
make -f /work/projects/p3-calidad/Makefile check
```
Revisión del docente y del cliente. El docente y el cliente revisan lo que un programa no puede juzgar: si las historias reflejan lo que el cliente pidió, si el diseño tiene sentido, si las pruebas verifican algo importante, si las revisiones de código fueron reales, si la demo funcionó.

Defensa oral

Puede haber una defensa oral breve durante el laboratorio: cualquier integrante debe poder explicar cualquier parte del producto y del código entregado, lo haya escrito a mano o con ayuda de una herramienta.