Al cerrar Estilo, legibilidad y refactorización quedaba pendiente una sola cosa, la más importante de todas: construir algo entero desde cero, tú solo. Este módulo es exactamente eso. Durante ocho módulos, cada pieza de TareaFácil venía propuesta —el enunciado decía qué clase hacía falta, qué método faltaba, qué prueba escribir—; a partir de aquí las decisiones son tuyas. Y la primera decisión, la que condiciona todas las demás, es qué vas a construir y hasta dónde. Esta lección no escribe una línea de código: sirve para elegir una idea que merezca la pena, recortarla hasta un tamaño que puedas terminar y dejarla escrita en un documento de una página que será tu contrato contigo mismo. Suena poco espectacular comparado con programar, pero es la diferencia entre un proyecto acabado y otra carpeta a medias en el disco duro.

1. Qué se espera del proyecto final
2. Cómo te vas a evaluar: la rúbrica
3. Elegir la idea: cinco criterios
4. Catálogo de seis ideas de proyecto
5. Delimitar el alcance con MoSCoW
6. Requisitos funcionales y no funcionales
7. Criterios de aceptación
8. Casos de uso y casos límite
9. El documento de definición
10. Ejemplo resuelto: MisGastos
11. Cómo se definió TareaFácil en su día
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

El proyecto final es una aplicación de línea de comandos, escrita por ti, que resuelve un problema concreto de principio a fin. No busca ser original ni impresionante: busca demostrar que sabes recorrer el camino completo desde una idea hasta un programa que otra persona puede descargar, ejecutar y entender.

Estas son las características que debe tener:

• Funciona sin ti delante. Alguien clona el repositorio, lee el README.md, ejecuta un comando y el programa arranca.
• Guarda datos entre ejecuciones. Cierras el programa, lo vuelves a abrir y tus datos siguen ahí (módulo 5).
• Está organizado en módulos y funciones, no en un único fichero de 600 líneas (módulos 4 y 7).
• No se rompe con una entrada rara. Escribir «treinta» donde pide un número no debe producir un traceback (módulo 8).
• Tiene pruebas automatizadas de lo que de verdad importa (08-04).
• Vive en Git, con historial legible y un README.md que lo explica (08-01 y 08-03).

Y una nota sobre el tamaño: un proyecto de este tipo son entre 300 y 800 líneas de código, repartidas en cuatro o cinco ficheros, y entre 15 y 25 horas de trabajo para alguien que acaba de terminar este curso. TareaFácil, en su v1.0, tiene ese orden de magnitud. Si tu idea parece necesitar mucho más, no es que seas lento: es que la idea es demasiado grande y hay que recortarla, que es justo lo que hace el apartado 5.

El recorrido del módulo completo es este, y esta lección es solo la primera casilla:

Conviene entender por qué el orden es ese. Cada casilla reduce la incertidumbre de la siguiente: sin definición no sabes qué diseñar, sin diseño programas a ciegas y reescribes tres veces, y sin un proyecto terminado no hay nada que presentar. No es burocracia: es la forma más barata de equivocarse, porque cambiar una frase del documento cuesta un minuto y cambiar una decisión ya programada cuesta una tarde.

No hay un profesor que te ponga nota, así que la nota te la pones tú —y para que eso signifique algo hace falta una rúbrica escrita antes de empezar, no después. Léela ahora, guárdala y vuelve a ella en Presentación del proyecto, donde la usarás de verdad.

Para calcular la nota, multiplica la puntuación de cada fila por su peso y suma. Un proyecto que saca 2,5 de media ya es un proyecto digno para alguien que empieza; apuntar al 4 en todo desde el primer intento es la forma más rápida de no terminar. Y fíjate en algo importante: solo el 25 % es «funcionalidad». El resto es cómo está hecho. Eso también es una decisión pedagógica deliberada.

La tentación es elegir la idea más ambiciosa que se te ocurra. Resiste. Un buen proyecto final cumple estos cinco criterios:

1. Resuelve un problema que tú tienes. Si el programa te va a resultar útil de verdad, lo terminarás; si es un ejercicio abstracto, lo abandonarás en la primera dificultad. Piensa en qué anotas hoy en un papel, en una nota del móvil o en una hoja de cálculo desordenada.
2. Es abarcable. Debe caber en cuatro o cinco entidades como mucho y en un puñado de operaciones. Si al describirlo necesitas más de cinco frases, es demasiado grande.
3. Usa datos que puedes inventarte. Nada de depender de una API externa, de una base de datos corporativa o de un fichero que no tienes. Debes poder crear veinte registros de prueba en diez minutos.
4. Se puede terminar. Existe una versión mínima identificable que ya es útil. Si el proyecto solo tiene sentido «cuando esté todo», es mal proyecto.
5. Encaja con lo que sabes. Este curso te ha dado ficheros, colecciones, clases y línea de comandos. Un proyecto que necesite gráficos, web o audio te obligará a aprender otra cosa antes de aplicar lo aprendido, y eso es para más adelante.

Un contraste útil: «una red social para aficionados a la fotografía» falla en todos los criterios; «un registro de las plantas de casa con cuándo toca regar cada una» los cumple todos y, además, se usa.

Si no se te ocurre nada, elige de aquí. Todas están dimensionadas para el tamaño del apartado 1 y todas ejercitan el curso completo, pero cada una insiste en cosas distintas:

Esa última fila merece una aclaración, porque es la más honesta de las seis: copiar la estructura de TareaFácil y cambiarle el dominio es un proyecto final perfectamente válido. No aprendes menos por tener un mapa; el trabajo de traducir un diseño a otro dominio es exactamente lo que se hace en la vida profesional. Eso sí: cámbialo de verdad —entidades propias, campos propios, informes propios—, no renombres variables.

Y un aviso sobre la quinta: el generador de menús es la más divertida y la más traicionera, porque la generación con restricciones (no repetir plato, equilibrar categorías) se complica muy deprisa. Elígela solo si empiezas por la versión tonta: elegir al azar sin restricción alguna.

El mayor peligro de tu primer proyecto no es que sea difícil: es que no se acabe nunca. Y no se acaba porque el alcance crece mientras programas. Estás implementando la lista de gastos, se te ocurre que estaría bien filtrar por rango de fechas, y ya que filtras, exportar a Excel, y ya que exportas, un gráfico... A las tres semanas no hay ni gráfico ni lista. A esto se le llama scope creep, deslizamiento del alcance, y el antídoto es escribir el alcance antes y no negociar con él.

La técnica MoSCoW clasifica todo lo que se te ocurra en cuatro cajones:

El cajón W parece un cajón de basura y es justo lo contrario: es el que te protege. Escribir «no habrá interfaz gráfica», «no habrá multiusuario», «no habrá sincronización en la nube» convierte una carencia en una decisión. Cuando en la presentación te pregunten por qué no hay interfaz gráfica, la respuesta «lo dejé fuera a propósito para centrarme en el modelo de datos» es profesional; «no me dio tiempo» no lo es. Y durante el desarrollo, cada vez que se te ocurra una idea nueva, no la implementas: la apuntas en el cajón C y sigues.

Ejemplo, para un gestor de gastos:

• Must: registrar gasto, listar gastos del mes, total por categoría, guardar y cargar, borrar un gasto.
• Should: editar un gasto, filtrar por rango de fechas, exportar a CSV.
• Could: presupuesto mensual con aviso al superarlo, gastos recurrentes.
• Won't: interfaz gráfica, varios usuarios, multidivisa, importar del banco, gráficos.

Con los cajones llenos, toca convertir los Must y Should en requisitos: frases precisas y verificables. Hay dos tipos y conviene no mezclarlos:

Los funcionales se escriben bien con la plantilla de historias de usuario:

Como <rol> quiero <acción> para <beneficio>.

Las tres partes tienen función. El rol te obliga a pensar quién usa esto (aunque seas tú). La acción debe ser un verbo concreto: «registrar», «listar», «exportar», nunca «gestionar» ni «manejar», que no significan nada. Y el beneficio es el que justifica el requisito: si no sabes terminar la frase, probablemente el requisito sobra. Numéralos —RF-1, RF-2...— porque los vas a citar en los commits, en las pruebas y en el README.

Escribe entre cinco y ocho requisitos funcionales y tres o cuatro no funcionales. Menos de cinco funcionales suele indicar un proyecto demasiado pequeño; más de ocho, uno que no vas a terminar.

Un requisito sin criterio de aceptación es una intención. El criterio de aceptación responde a: ¿cómo sé, sin discusión posible, que esto está hecho? Se escribe como una lista de comprobaciones observables, y su gran virtud es que se convierte casi literalmente en pruebas cuando llegues a 09-03.

Compara:

La segunda columna es comprobable por cualquiera, incluido tú mismo dentro de dos semanas. Un buen criterio de aceptación tiene entre tres y cinco puntos, describe lo que se observa desde fuera (no cómo está implementado) e incluye al menos un caso de error.

Un caso de uso es el recorrido completo de una tarea del usuario, del principio al final, contado como una secuencia. Sirve para descubrir pasos que los requisitos no mencionan:

Escrito así se ven cosas que no estaban en el requisito: que hay que cargar datos al arrancar, que hace falta un identificador, que conviene confirmar con un mensaje. Con dos o tres casos de uso de los flujos principales es suficiente.

Los casos límite son las situaciones raras que rompen el programa si no las previste. Piénsalas ahora, no cuando aparezcan:

La fila de ficheros es la que más veces olvida quien empieza, y es la que garantiza un traceback en la primera demo: el programa se probó siempre con datos ya existentes y nadie ejecutó nunca el primer arranque.

Todo lo anterior cabe en una página. Copia esta plantilla en un fichero DEFINICION.md dentro del repositorio y rellénala; es tu contrato contigo mismo y la referencia a la que volverás cuando dudes si algo entra o no en el proyecto.

El apartado 9 merece atención especial. Escribe hoy, por escrito, qué significa «terminado»: «Todos los RF marcados como Must funcionan, hay pruebas del modelo y del almacén, el README explica cómo instalar y usar, y existe la etiqueta v1.0». Sin esa frase escrita, «terminado» se desplaza cada semana.

Este es el documento de definición completo del proyecto de muestra que acompañará las lecciones 09-02, 09-03 y 09-04. Lo llamaremos MisGastos.

1. Problema. Llego a fin de mes sin saber en qué se me ha ido el dinero. Apunto los gastos en notas del móvil que nunca reviso y no tengo forma de ver cuánto gasto en comida frente a transporte.

2. Solución propuesta. Una aplicación de línea de comandos que registra gastos e ingresos con categoría y fecha, los guarda en un fichero JSON y muestra informes mensuales por categoría.

3. Alcance (MoSCoW).

4. Requisitos funcionales.

5. Requisitos no funcionales.

• RNF-1. Ninguna entrada del usuario provoca un traceback: todo error se muestra como mensaje y devuelve al menú.
• RNF-2. Los datos se guardan en un único fichero JSON legible, editable a mano y con codificación UTF-8.
• RNF-3. Cualquier operación responde en menos de un segundo con hasta 2.000 movimientos.
• RNF-4. El programa funciona con Python 3.10 o superior sin instalar dependencias externas.

6. Casos de uso principales. CU-1 registrar un gasto (el del apartado 8); CU-2 consultar el desglose de un mes; CU-3 corregir un error borrando y volviendo a registrar.

7. Casos límite previstos. Primer arranque sin fichero; JSON corrupto a mano; mes sin movimientos; importe con coma decimal (12,50); id inexistente al borrar; categoría escrita como «Comida» y «comida»; mes mal escrito (2026-13).

8. Datos de ejemplo. Un datos_ejemplo.json con 20 movimientos repartidos en dos meses y cinco categorías, generado a mano una vez y versionado en el repositorio.

9. Definición de terminado. Los siete RF funcionan; hay pruebas de modelo, agregación y ciclo guardar/cargar; el README explica instalación, uso y limitaciones; existe la etiqueta v1.0.

TareaFácil pasó por este mismo proceso, aunque no lo vieras. Su documento de definición decía: «Marta coordina tres personas en Estudio Alba y lleva el reparto de trabajo en un cuaderno; cuando alguien pregunta qué le toca, hay que buscarlo a mano». Sus Must fueron añadir tarea, listar, marcar completada, eliminar y guardar. Sus Won't fueron explícitos y sostenidos hasta el final: sin interfaz gráfica, sin varios usuarios simultáneos, sin notificaciones y sin sincronización. Todo lo demás que aprendiste con él —las prioridades, TareaRecurrente, el resumen por responsable, el CSV— eran Should que entraron cuando los Must ya estaban en verde.

Comparar los dos documentos enseña algo: son casi idénticos en forma y completamente distintos en contenido. El proceso es el mismo siempre; lo único que cambia es el dominio.

• Elegir un proyecto demasiado grande. Es el error número uno y no tiene remedio a mitad de camino. Norma práctica: si al terminar de definirlo te parece «demasiado fácil», el tamaño es probablemente el correcto. Un proyecto pequeño y acabado enseña diez veces más que uno ambicioso y abandonado.
• Saltarse el documento por «ganas de programar». La tentación es empezar a teclear en la primera hora. Escribir la definición cuesta 45 minutos y ahorra días de reescritura, porque descubres antes de programar que necesitabas un identificador o que dos entidades eran en realidad la misma.
• Requisitos que no se pueden verificar. «Que sea intuitivo», «que vaya rápido», «que sea bonito». Reescríbelos como algo observable: «el menú cabe en pantalla sin desplazamiento», «responde en menos de un segundo con 2.000 registros».
• Dejar el cajón Won't vacío. Si no hay nada que no vayas a hacer, es que no has decidido nada. Fuérzate a escribir al menos cuatro exclusiones.
• Confundir requisito con solución. «Quiero guardar los datos en JSON» no es un requisito, es una decisión de diseño y le toca a Planificación y diseño. El requisito es «quiero que mis datos no se pierdan al cerrar».
• Consejo: elige un dominio que conozcas. Si eres músico, un catálogo de partituras; si corres, un registro de entrenamientos. Conocer el dominio te ahorra la mitad de las dudas de diseño, porque ya sabes qué campos importan.
• Consejo: la regla de las 20 fichas. Antes de escribir código, imagina 20 registros reales de tu proyecto. Si no eres capaz de inventártelos, el dominio no está claro todavía.

Estos ejercicios son los primeros pasos reales de tu proyecto. Hazlos en un fichero DEFINICION.md de verdad; lo usarás en las cuatro lecciones siguientes.

Escribe tres ideas candidatas —al menos una salida del catálogo del apartado 4 y al menos una propia— y evalúa cada una contra los cinco criterios del apartado 3 en una tabla con puntuación de 1 a 3. Elige la ganadora y escribe un párrafo de tres o cuatro frases explicando el problema real que resuelve y a quién.

Para la idea ganadora, llena los cuatro cajones: 5 o 6 Must, 3 o 4 Should, los Could que quieras y un mínimo de 4 Won't. Después haz la prueba del ácido: tapa los Should y los Could y pregúntate si lo que queda ya te resultaría útil. Si la respuesta es no, algún Should debe subir a Must; si la respuesta es «me sobra la mitad», baja algún Must.

Convierte los Must y Should en 5 a 8 requisitos funcionales numerados con la plantilla «Como / quiero / para», cada uno con tres o más criterios de aceptación, y añade 3 o 4 requisitos no funcionales. Después recorre la tabla de familias del apartado 8 y escribe al menos un caso límite de cada familia aplicado a tu proyecto.

Solución 1. El apartado 10 es la solución completa del ejercicio para MisGastos. La tabla de evaluación previa fue esta:

La tercera cae por su propio peso: depende de datos externos que no controlas. La segunda era viable pero el problema era menos propio —«estaría bien tenerlo» no es lo mismo que «me hace falta»—, y ese matiz es el que sostiene la motivación en la semana tres. Rúbrica de autoevaluación: ¿has puntuado al menos tres ideas? ¿La ganadora tiene un 3 en «terminable»? ¿Sabrías explicar el problema a alguien ajeno en 30 segundos?

Solución 2. El MoSCoW de MisGastos está en el apartado 10. Fíjate en dos decisiones concretas: «editar un movimiento» está en Should y no en Must porque con borrar y volver a registrar ya se corrige un error —el valor añadido de editar es comodidad, no capacidad—, y «gráficos» está en Won't aunque sea lo primero que uno imagina en una aplicación de gastos, porque exige una biblioteca externa y todo un aprendizaje que no es el de este curso. Rúbrica: ¿tienes 4 o más Won't? ¿Cabe cada Must en menos de tres horas de trabajo? ¿Los Must solos ya componen un programa útil?

Solución 3. Los siete RF, los cuatro RNF y los casos límite de MisGastos están en el apartado 10. Compara tus criterios de aceptación con los de RF-3: mira que incluye el caso vacío («Sin movimientos en 2026-08») y el formato de entrada (AAAA-MM). Esas dos cosas son las que después se convierten en dos def test_... casi sin traducción. Rúbrica: ¿todos tus RF tienen verbo concreto? ¿Cada uno tiene tres o más criterios observables? ¿Al menos un criterio por requisito describe qué pasa cuando algo va mal? ¿Tienes un caso límite de cada una de las siete familias?

El proyecto final es tuyo: una aplicación de línea de comandos de entre 300 y 800 líneas que resuelve un problema real, guarda datos, está organizada en módulos, no se rompe con entradas raras, tiene pruebas y vive en Git. Te evaluarás con la rúbrica de seis criterios —funcionalidad, estructura, robustez, documentación, pruebas y Git—, escrita antes de empezar precisamente para que signifique algo. La idea se elige con cinco criterios: que resuelva un problema propio, que sea abarcable, que use datos inventables, que se pueda terminar y que encaje con lo aprendido; y si no aparece ninguna, ahí está el catálogo de seis, incluida la opción perfectamente legítima de rehacer TareaFácil para otro dominio.

Después viene lo que de verdad decide si el proyecto se acaba: el alcance. MoSCoW reparte todo en imprescindible, debería, podría y no ahora, y el cajón Won't —explícito, escrito, sin remordimientos— es el que impide que el proyecto crezca mientras lo programas. Los Must y Should se convierten en requisitos funcionales con la plantilla «Como <rol> quiero <acción> para <beneficio>» y en requisitos no funcionales que describen cómo debe comportarse; cada uno con sus criterios de aceptación, que responden sin discusión a cuándo está hecho y que en 09-03 se convertirán casi literalmente en pruebas. Los casos de uso revelan los pasos que los requisitos olvidan, y las siete familias de casos límite —vacío, uno, muchos, entrada inválida, duplicados, ficheros y extremos— evitan el traceback en la primera demo. Todo ello cabe en un DEFINICION.md de una página que termina con la frase más útil del documento: qué significa exactamente «terminado». MisGastos, el gestor de gastos que acompañará el resto del módulo, ya lo tiene escrito entero.

Con el qué cerrado toca el cómo. En Planificación y diseño convertiremos este documento en decisiones técnicas: qué entidades hay y si son clases o diccionarios, en qué formato se guardan los datos, cómo se reparte el código en capas y módulos, qué aspecto tiene el menú, qué algoritmos necesitas escritos en pseudocódigo antes de programarlos y en qué orden vas a hacerlo todo, sesión a sesión.