P5 · Producto final

Publicado: semana 14 · Entrega: semana 16 (presentación y defensa oral) · En equipo, con partes individuales · Tag: p5

El semestre termina cuando el cliente recibe el producto y alguien que no es del equipo lo puede mantener. Esta entrega cierra el proyecto: una revisión de seguridad de la aplicación con OWASP Top 10, la entrega formal al cliente con su aceptación, la documentación para quien venga después, la licencia acordada, la retrospectiva final, el registro de uso de IA completo, la evaluación entre pares, la presentación final y la defensa oral.

Cubre las semanas 15 (seguridad y privacidad, ética, accesibilidad, licencias y procedencia del código generado) y 16 (mantenimiento, código heredado, deuda técnica y deprecación). La revisión de P5 vuelve a correr las de P1 a P4: el producto entregado sigue cumpliendo todo lo anterior.

1. Qué entregan

docs/seguridad.md

Con lo de la semana 15, miren su aplicación como la miraría un atacante: la lista OWASP Top 10:2025 aplicada a su aplicación, antes de entregarla al cliente. Una fila (o una sección ###) por categoría, de A01 (Broken Access Control) a A10 (Mishandling of Exceptional Conditions), con qué miraron en su código, el estado (Cumple, Parcial, No cumple o No aplica) y la evidencia (una prueba, un archivo, una configuración) o lo que queda pendiente.

| Categoría | Qué miramos en nuestra app | Estado | Evidencia o pendiente |
|---|---|---|---|
| A05:2025 Injection | SQL con texto del usuario | Cumple | Todo el SQL usa parámetros (`src/repository.ts`) |

“No aplica” se justifica. “Parcial” dice qué falta y por qué se acepta el riesgo por ahora; lo que no se corrija antes de la entrega va también a ## Pendientes de docs/entrega.md. Agreguen una sección sobre los datos personales que guarda la aplicación: cuáles, por qué, quién los ve y cuándo se borran.

docs/entrega.md

• ## Qué se entregó: la fecha de la entrega, la URL de producción, las historias terminadas (por id), los accesos que recibió el cliente y cualquier guía para su personal.
• ## Aceptación del cliente: cómo aceptó el cliente el producto (un acta firmada, un correo, un mensaje), qué criterios acordados se cumplen y cuáles no. Enlaza la evidencia, guardada en docs/entrega/ (por ejemplo [el correo](entrega/aceptacion-cliente.txt) o un PDF del acta firmada). Quiten de la evidencia los datos personales que no hacen falta (teléfonos, direcciones).
• ## Pendientes: lo que queda por hacer, los errores conocidos y la deuda técnica reconocida, con la prioridad que acordaron con el cliente.

Si el cliente no acepta el producto, no lo escondan: ## Aceptación del cliente dice qué observó y qué hicieron. Lo que se espera es honestidad.

README.md para quien mantenga el producto

El README de P2 y P4 crece hasta ser lo que necesita una persona que hereda el proyecto sin haber estado en el equipo. Además de ## Instalación, ## Convenciones y ## Despliegue, ahora tiene:

• ## Arquitectura: los módulos y qué hace cada uno, dónde están las reglas del negocio, cómo se guardan los datos, con enlaces al design doc y a los ADRs.
• ## Cómo contribuir: cómo se prepara el entorno, el flujo de una rama al merge, qué se revisa en un pull request y cómo se registra el uso de IA. Puede ser corta y enlazar un CONTRIBUTING.md.
• ## Licencia: la licencia y por qué se eligió con el cliente.

Una prueba útil: que alguien de otro equipo siga el README desde cero, en el contenedor del curso, y anote dónde se trabó.

LICENSE

El texto completo de la licencia que acordaron con el cliente (semana 15): una licencia libre conocida (MIT, Apache-2.0, GPL-3.0, AGPL-3.0, MPL-2.0, …) o, si el cliente lo pide, otra, con el motivo en ## Licencia. El README de proyectos recuerda que el código queda en el repositorio del equipo con una licencia acordada.

docs/retrospectiva-final.md

Sobre todo el semestre, con las retrospectivas de cada sprint a la vista:

• ## Qué funcionó: prácticas que repetirían, con un ejemplo concreto.
• ## Qué no funcionó: con datos (pull requests que esperaron días, el incidente, la demo que salió mal) y la causa.
• ## Qué aprendimos: lo que harían distinto en el próximo proyecto.
• ## Uso de IA: dónde ayudaron las herramientas de IA, dónde fallaron, cómo verificaron lo que produjeron y qué cambió en su forma de usarlas.

docs/registro-ia.md completo

La tabla de P1 (Fecha, Herramienta, Qué se pidió, Qué se aceptó, Qué se rechazó y por qué) con todo el semestre: cada fila con todas sus celdas llenas (si no se rechazó nada, la celda lo dice). Si el equipo no usó herramientas de IA, una fila lo declara. El registro se compara con el código y con la defensa oral: un cambio grande hecho con una herramienta y sin registro cuenta como no entregado (reglas generales).

Evaluación entre pares

Cada integrante evalúa, en privado y en el formato que indique el docente, el aporte de cada uno de los demás y el suyo: qué hizo, cómo colaboró, qué tan confiable fue. No va en el repositorio. Junto con la historia de Git, le muestra al equipo y al docente cómo se repartió el trabajo durante el semestre.

Presentación final, demo y defensa oral

• Presentación y demo (semana 16, Sesión B): el problema del cliente, el producto funcionando en producción con una historia completa, una decisión de diseño con sus alternativas, el incidente y lo que aprendieron. Si el cliente puede asistir, mejor.
• Defensa oral (semana 16, laboratorio, individual): el docente pregunta a cada integrante por cualquier parte del producto: una función, una prueba, un ADR, una entrada del registro de IA. Cualquiera tiene que poder explicar cualquier parte, la haya escrito a mano o con una herramienta.

2. Revisión automática

Dentro del contenedor del curso, desde la carpeta del repositorio del equipo, clonado dentro de la carpeta del curso (P1, sección 1):

cd /work/equipo-nombre
make -f /work/projects/p5-producto/Makefile check

Corre las reglas de P1 a P4 y estas:

La evaluación entre pares, la presentación y la defensa oral no están en el repositorio: las revisa el docente.

3. Cómo entregar

Con el tag p5, como en P1, antes de la presentación final. Desde el tag, el repositorio no cambia salvo que el cliente pida una corrección (en un pull request, con un tag p5.1).

4. Consejos y errores comunes

• Pedir la aceptación el último día. Coordinen con el cliente la fecha de la entrega desde la semana 14; si algo no le convence, todavía hay tiempo.
• Un README que solo entiende el equipo. “Corran el script” no sirve si no dice cuál, dónde ni con qué variables. Pruébenlo con alguien de afuera.
• Licencia sin conversar. El cliente tiene que entender qué permite la licencia (que otros usen el código, que el equipo lo muestre en su portafolio). Anoten la conversación.
• Completar el registro de IA al final, de memoria. Se nota. Si faltan entradas, digan cuáles y por qué, en vez de inventarlas.
• Defensa oral. Repasen juntos el código que escribió otra persona, sobre todo las reglas del negocio y las pruebas. “Eso lo hizo mi compañero” o “lo generó la herramienta” no es una respuesta.
• Una revisión de seguridad de lista. Marcar “Cumple” en las diez categorías sin evidencia no es una revisión. Prueben de verdad lo que dicen: una ruta del personal sin token, un ' en un campo de texto, un JSON roto.
• Con IA. Una herramienta puede ayudar a redactar la documentación; lo que no puede es saber qué se le complicó al equipo ni qué necesita quien mantenga el producto. Verifiquen cada comando del README corriéndolo.