[Informe de clase] Desarrollo de sistemas (2.º año) — Semana 40
— Finalización de documentación y diseño de handover: la habilidad de “terminar” un proyecto de desarrollo —
En la Semana 40, tomamos el sistema cuya calidad confirmamos en la sesión de mini-presentación anterior y trabajamos en la limpieza final de la documentación y el diseño del handover (traspaso).
El tema fue: dejarlo en un estado en el que la siguiente persona pueda usarlo, arreglarlo y mejorarlo sin atascarse.
■ Introducción del profesor: “Un buen desarrollo se completa con un buen handover”
Sr. Tanaka: “Un proyecto no está terminado solo porque el código funcione.
Solo está completo cuando está en una forma que puedas entregar a otra persona.”
Como ejemplos del mundo real, el profesor comparó:
- Sistemas que se volvieron imposibles de modificar por falta de documentación
- Proyectos que pudieron entregarse rápidamente porque el README estaba bien mantenido
…y explicó que la calidad del handover afecta directamente la eficiencia del desarrollo.
■ Objetivos de hoy
- Finalizar el README hasta un nivel en el que un tercero pueda usarlo a primera vista
- Unificar documentos de diseño, diagramas de flujo y diagramas ER en su versión más reciente
- Crear un memo de operación/resolución de problemas (notas de operación)
- Completar la lista de verificación de handover
■ Ejercicio ①: Pulido final del README
Cada equipo abrió su README y lo refinó desde las siguientes perspectivas.
Elementos obligatorios incluidos en el README
- Resumen del proyecto (qué problema resuelve el sistema)
- Entorno de ejecución y requisitos previos
- Pasos de configuración (crear BD → ejecutar migraciones → iniciar la app)
- Uso básico (por caso de uso)
- Errores comunes y cómo solucionarlos
- Dónde están los logs y cómo leerlos
- Explicación de la estructura de carpetas
Estudiante A: “Cuando me imaginé ‘a mí mismo viendo esto por primera vez’, terminé añadiendo más explicaciones.”
■ Ejercicio ②: Organizar y actualizar documentos de diseño a la versión más reciente
Consolidamos los siguientes materiales en un conjunto coherente y actualizado:
- Definición de requisitos (historias de usuario y criterios de aceptación)
- Diagramas de clases y diagramas de secuencia
- Diagrama ER y definiciones de tablas
- Notas sobre separación de roles entre capas DAO / Service
Puntos de comprobación
- Si la implementación y los diagramas se contradicen
- Si quedan clases o tablas sin uso
- Si los nombres coinciden con el código
Estudiante B: “Al corregir los diagramas me di cuenta de que había ‘funcionalidades innecesarias’.”
■ Ejercicio ③: Crear notas de operación (memo de troubleshooting)
Creamos notas de operación que recopilan la información necesaria “después de que esté en funcionamiento”.
Ejemplos de lo que escribimos
- Problemas comunes y sus causas
- Qué comprobar cuando ocurren errores (logs → BD → configuración)
- Procedimientos seguros de reinicio
- Cómo hacer backup de los datos
- Configuraciones que no deben tocarse
Estudiante C: “Da tranquilidad cuando dice claramente ‘no toques esto’.”
■ Ejercicio ④: Construir una lista de verificación de handover
Por último, convertimos los elementos imprescindibles a comprobar para el handover en una lista de verificación.
Lista de verificación de handover (ejemplo)
- [ ] El sistema puede iniciarse leyendo el README
- [ ] La estructura de la BD coincide con el diagrama ER
- [ ] Se pueden reproducir los casos de uso clave
- [ ] El procedimiento de revisión de logs durante errores es claro
- [ ] Se identifican explícitamente los archivos a modificar para cambios futuros
Superar todas las comprobaciones es la condición para llamar al proyecto “completo”.
■ Práctica de handover por parejas (paso final)
Dentro de cada equipo, los miembros cambiaron roles e hicieron un simulacro de handover en el que:
“El creador no puede explicar.”
- Iniciar el sistema usando solo el README y los documentos
- Anotar los puntos poco claros
- Mejorar la documentación en el momento
Estudiante D: “Esta regla de ‘sin explicar’ es una locura de educativa…”
■ Resumen final del profesor
“Lo que hicieron hoy es
la habilidad de conectar su成果 (trabajo/resultados) con el futuro.
Diseño, implementación, pruebas, mejora y handover—
habiendo experimentado todo este flujo,
ya no son solo personas que ‘solo construyen’.”
■ Comentarios de reflexión (extractos)
- “Me di cuenta de la importancia del README por primera vez.”
- “Cuando construyes pensando en el handover, notas puntos débiles en el diseño.”
- “Siento que el desarrollo en equipo incluye cómo terminas como parte del trabajo.”
■ Vista previa de la próxima semana: cierre del trimestre y revisión de resultados
La próxima semana, repasaremos todo el trimestre y trabajaremos en:
organización del portafolio, autoevaluación y conexión con el próximo curso (3.º año).
Será una sesión hito importante antes de pasar a áreas como IA generativa e integración de servicios externos.
La Semana 40 trató de elevar la calidad no mediante código, sino mediante comunicación y transferibilidad.
El alumnado aprendió el verdadero significado de no terminar en “construir y listo”, sino preparar un sistema en una forma que pueda entregarse a la siguiente persona.