closes #301 reescribe y aclara

Cuando hay que hablar de soluciones al problema y qué forma deben tener estas

documentos/proyecto/0.Repositorio.md

@@ -89,66 +89,80 @@ inicialmente:
 
 * Otro fichero u otra serie de ficheros de uso habitual en repositorios.
 
-En cuanto a la idea o problema que se quiere resolver, tiene que ser un problema
-del cual tengas *conocimiento personal*, preferiblemente. Cuanto más involucrado
-estés con el problema, o las personas que lo tienen, más interés vas a tener en
-hallar una solución al mismo y mejor entenderás qué sería lo que lo soluciona.
+En cuanto a la idea o problema que se quiere resolver, debería ser
+preferiblemente un problema del cual tengas *conocimiento personal*. Cuanto más
+involucrado estés con el problema, o las personas que lo tienen, más interés vas
+a tener en hallar una solución al mismo y mejor entenderás qué sería lo que lo
+soluciona.
 
 Otra cuestión es que ese problema tenga entidad suficiente para poder crear,
-eventualmente, algún tipo de servidor que se pueda desplegar en la nube; es
-decir, tiene que tener descrita correctamente una **lógica de negocio**, que es
-el código propio que resuelve el problema. El centrarnos en la lógica de negocio
-(extraer información del texto de una página web *ya descargada*, por ejemplo)
-en vez de en los aspectos mecánicos (cómo obtener el URL de la página y cómo
-descargársela) permite que tengamos el foco en lo esencial de nuestra
-aplicación, que es lo que añade valor al cliente (no el hecho de que uno se
-descargue una página, o extraiga información de un API o como sea).
+eventualmente, algún tipo de servidor que se pueda desplegar en la nube, o sea
+válido para superar el resto de los objetivos de la asignatura.
+
+En este objetivo sólo es necesario que la descripción del problema sea correcta,
+y efectivamente describa un problema o necesidad de un cliente concreto. Pero lo
+principal es que hay que trabajar con este problema el resto de la asignatura, y
+el profesor que apruebe el objetivo tiene que asegurarse de que efectivamente se
+pueda hacer así. Por eso, en caso de que no esté claro a partir de la
+descripción qué tipo de soluciones se tienen en mente, hay que describir la
+**lógica de negocio**, que es el código *propio* que resuelve el problema.
 
 > Propio quiere decir que toda la lógica de negocio tendrá que ser programada
 > por el estudiante, principalmente en el [objetivo 4](4.Tests.md), y de ahí en
 > adelante. Es decir, *en este punto* tienes que tener al menos una idea vaga de
 > cómo resolver el problema mediante código con tus propios medios.
 
+Más adelante, el centrarnos en la lógica de negocio (extraer información del
+texto de una página web *ya descargada*, por ejemplo) en vez de en los aspectos
+mecánicos (cómo obtener el URL de la página y cómo descargársela) permite que
+tengamos el foco en lo esencial de nuestra aplicación, que es lo que añade valor
+al cliente (no el hecho de que uno se descargue una página, o extraiga
+información de un API o como sea).
+
 En general, este tipo de problemas requieren, por parte de la solución
 informática, una parte considerable de "computación" o "procesamiento" o
 "generación". Si la idea y la descripción del problema sólo incluye palabras
 como "almacenamiento" y "búsqueda", mientras que puede ser una aplicación
 completa perfectamente válida (dotada de un interfaz de usuario adecuado), los
 diferentes pasos por los que pasará la resolución del problema en los siguientes
-objetivos no van a dar mucho de sí. Es decir, si se trata simplemente de objetos
-con un ciclo CRUD (create, read, update y delete), descártala y piensa en otra
-que sí realice algún tipo de procesamiento.
+objetivos no van a dar mucho de sí en esta asignatura. Es decir, si se trata
+simplemente de objetos con un ciclo CRUD (*create*, *read*, *update* y
+*delete*), descártala y piensa en otra que sí realice algún tipo de
+procesamiento.
 
 De la misma forma, aplicaciones que tengan una dependencia externa fuerte (por
-ejemplo, que recojan datos de un API externo, que pidan una gran cantidad de
-datos al usuario o que simplemente integren una biblioteca externa para llevar a
-cabo una operación sobre datos también externos) tampoco van a ser buenos
-proyectos, porque sus pruebas van a ser complicadas y no van a incluir ningún
-tipo de modelo. Lo esencial siempre es que la aplicación incluya un valor
-añadido en forma de lógica de negocio, y que se describa correctamente el
-problema a solucionar de forma que haga falta tal lógica de negocio para
-solucionarlo.
-
-En este objetivo no se pide que se especifique la solución al problema. Sin
-embargo, sí habrá que hacerlo más adelante y si se trata de un problema cuyas
-posibles soluciones no sean válidas para esta asignatura, se rechazará en este
-objetivo. Por eso hay que pensar en la solución al problema, y en caso de que no
-quede claro su entidad por la sola descripción del mismo, especificarlo. Y esta
-descripción (que tiene que pasar por la lógica de negocio), sea explícitamente
-porque sea necesaria en este objetivo, o en objetivos siguientes, debe:
+ejemplo, que necesiten para cada interacción del usuario recoger datos de un API
+externo, que pidan una gran cantidad de datos al usuario o que simplemente
+integren una biblioteca externa para llevar a cabo una operación sobre datos
+también externos) tampoco van a ser buenos proyectos, porque sus pruebas van a
+ser complicadas y no van a incluir ningún tipo de modelo. Lo esencial siempre es
+que la aplicación incluya un valor añadido en forma de lógica de negocio, y que
+se describa correctamente el problema a solucionar de forma que haga falta tal
+lógica de negocio para solucionarlo.
+
+Insistimos que *en este objetivo* no se pide que se especifique la solución al
+problema. El desarrollo ágil va evolucionando la solución al problema en pasos
+sucesivos, y hablar desde el principio de "la solución" impide que se avance
+paulatinamente hacia *una* solución (entre las posibles). Sin embargo, sí habrá
+que hacerlo más adelante y si se trata de un problema cuyas posibles soluciones
+no sean válidas para esta asignatura, se rechazará en este objetivo. Por eso hay
+que pensar en la solución al problema, y en caso de que no quede claro su
+entidad por la sola descripción del mismo, especificarlo. Y esta descripción
+(que tiene que incluir la lógica de negocio), sea explícitamente porque sea
+necesaria en este objetivo, o en objetivos siguientes, debe:
 
 * Incluir palabras como *calcular*, *generar*, *procesar*, *predecir*,
   *visualizar* (teniendo en cuenta en esta última que se va a hacer en el
   servidor), *extraer*, *resumir*, *filtrar*, *validar*, *analizar*.
 * **No** incluir palabras como "buscar", "dar de alta", "poner en contacto",
-  "recuperar", "integrar", "alertar", "comunicar".
+  "avisar", "enviar", "recuperar", "integrar", "alertar", "comunicar".
 
 La lógica de negocio será creada y testeada más adelante, a partir del [objetivo
 4](4.Tests.md). Por eso es esencial que sea no trivial, para que los tests
 efectivamente comprueben que se está resolviendo el problema correctamente. Así
 mismo, los tests deben servir para validar que se ha resuelto el problema a
 través del programa, por lo que el problema debe ser formulado de forma que
-efectivamente, el procesamiento de la información que lleva a cabo el programa
+efectivamente el procesamiento de la información que lleva a cabo el programa
 se pueda validar como una solución aceptable al problema.
 
 ### Dónde buscar proyectos