Es imprescindible que el estudiante lea este documento desde el principio al final, entendiendo su intención y qué es lo que pide. El realizar correctamente este primer objetivo, y hacerlo a tiempo, le permitirá continuar en la asignatura con más fluidez, pero sobre todo le ahorrará trabajo de corrección de las entregas y le permitirá alcanzar los objetivos de aprendizaje más rápidamente.
Esta asignatura tiene una serie de mecanismos específicos (es decir, que no hay ninguna otra asignatura en la ETSIIT que los tenga) para su entrega y evaluación; el trabajo se preparará y se evaluará usando los mismos mecanismos que se usan en las empresas de desarrollo de software. Con este objetivo se pretende que el estudiante aprenda a usar correctamente estos mecanismos, así como el proceso de aprendizaje guiado que se va a llevar en esta asignatura.
A la vez, el estudiante tendrá que describir un problema general de un cliente que se irá resolviendo, a lo largo de la asignatura, usando software. Este problema tendrá que incluir obligatoriamente un componente que se pueda desplegar en la nube. Este es el objetivo secundario: que el estudiante entienda el concepto de “problema”, de “cliente” y de “solución basada en la nube”.
This first project deliverable needs to be in Spanish, since the analysis will look for Spanish words and phrases to pass the pre-evaluation test. You can request feedback in English if you want.
Pensar en un problema a resolver que tenga entidad suficiente para poder llevar a cabo su desarrollo durante el resto de la asignatura. Este objetivo es bloqueante, si el estudiante no lo supera equivale a un no apto en la convocatoria correspondiente.
Se hace énfasis en el resto de la asignatura. Realmente el estudiante tendrá que intentar desarrollar un producto que resuelva parcialmente el problema que ha planteado aquí. En el siguiente objetivo tendrá que plantear los hitos de desarrollo del proyecto y reflejar con más detalle qué problemas se van a resolver y para qué clientes y plasmar las necesidades del usuario, y en el segundo objetivo comenzar a modelizar el problema de forma que se pueda empezar a trabajar en él en los objetivos siguientes.
El estudiante trabajará con este problema desarrollando un proyecto durante el resto del curso. Sin embargo, cabe destacar que en algunos objetivos (como el objetivo 2) trabajará sobre el problema de otro compañero, y habrá revisión por pares (peer-review) a lo largo de todo el proyecto.
En resumen: el estudiante va a tener que convivir con esta idea, trabajar con ella, entender qué problemas plantea, especificarlos y darle cuerpo y realidad el resto de la asignatura. Debe tenerlo en cuenta a la hora de plantearlo. Por eso es muy importante que proponga una idea con la cual se sienta cómodo, entienda a las personas que quieren que se resuelva el problema y, en general, sienta cierto interés por que efectivamente se resuelva.
El concepto de problema es posiblemente el más importante que el estudiante tendrá que aprender a usar. Durante esta asignatura tendrá que formular problemas, y reconocer cuando lo está haciendo. El resto de los objetivos van a ser esencialmente formulaciones de problemas relacionados entre sí (y con el problema del usuario). El estudiante puede consultar el objetivo 2 y el 4 para ver cómo tiene que usar en la práctica este concepto para poder avanzar en el desarrollo de un producto.
En general, el estudiante va a tener que aprender una serie de técnicas y metodologías que le serán útiles en su carrera. Usándolas en la práctica se aprenden rápidamente y sin dolor (y no habrá exámenes de ello).
En este objetivo cero de la asignatura, y punto de partida del proyecto que se
desarrollará en la misma, se trata de poner a punto las herramientas que se van
a usar para mostrar el progreso del aprendizaje durante el resto del curso, a la
vez que se busca que se interioricen una serie de buenas prácticas en desarrollo
de software, que están siempre mediadas por git en los entornos de trabajo
actuales y en general siguen el denominado manifiesto
ágil.
Un factor esencial en el desarrollo ágil es la preocupación por la calidad. Las personas formadas en una ingeniería deben ser capaces de proporcionar productos de calidad al cliente, y en esta asignatura se persigue que, en cada uno de los pasos, el estudiante se preocupe por la calidad de lo que entrega. Y la calidad está en el proceso, no en el producto final. Lo que se entrega no tiene tanta importancia como el proceso que haya seguido para llegar a ese producto; si lo único para asegurar la calidad es el producto final es imposible hacerlo. Por eso *el estudiante no debe fijarse en lo que otras personas han entregado, porque no es eso lo que se evalúa: la evaluación (como en el desarrollo ágil) consiste en comprobar que el estudiante ha sido capaz de aplicar una serie de metodologías para crear un producto de calidad.
Por eso, se aconseja que el estudiante no se quede satisfecho con poner algo que parezca suficiente, sino que compruebe que efectivamente muestra que ha comprendido y puesto en práctica lo que se persigue que aprenda en cada objetivo. En este caso concreto bastará con que repase de forma crítica la lista de comprobación; más adelante, además, habrá que pasar algunos tests, pero una vez pasados los tests para poder entregar el objetivo, la preocupación por la calidad exige que efectivamente se pruebe manualmente que lo que se requiere en cada objetivo es efectivamente lo que se está entregando. Eso servirá para asimilar mejor las prácticas de cada objetivo, pero también para evitar trabajo por parte de quien corrige y también por parte del propio estudiante, que tendrá que revisar el trabajo repetidas veces si no tiene la calidad requerida.
Para ello, se creará un repositorio que se usará durante el resto de la asignatura para mostrar el avance del proyecto en diferentes hitos en el desarrollo y despliegue de una aplicación. El repositorio contendrá inicialmente:
Un fichero con el nombre, formato y extensión convencional, que explique de qué va a ir el proyecto, en qué va a estar basado y algunas referencias relacionadas con el mismo. El fichero sólo hablará del problema que se quiere resolver. Las herramientas (excepto el lenguaje) se irán decidiendo sobre la marcha (a partir del objetivo 3).
Licencia que se va a usar en el proyecto, ya que se trata de un proyecto de software libre.
Otro fichero u otra serie de ficheros de uso habitual en repositorios.
En cuanto a la idea o problema que se quiere resolver, debería ser preferiblemente un problema del cual el estudiante tenga conocimiento personal. Cuanto más involucrado esté con el problema, o las personas que lo tienen, más interés va a tener en hallar una solución al mismo y mejor entenderá 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, o sea válido para superar el resto de los objetivos de la asignatura.
IMPORTANTE: En este entregable, el objetivo es documentar EXCLUSIVAMENTE el problema a resolver, no la solución tecnológica. El desarrollo ágil evoluciona la solución paso a paso, por lo que anticipar detalles de implementación ahora es prematuro. Las herramientas (excepto el lenguaje) se irán decidiendo a partir del objetivo 3.
Sin embargo, el estudiante debe tener en mente una solución basada en lógica de negocio propia y sustancial. Esto significa que debe tener una idea clara de cómo resolver el problema programando código propio a partir del objetivo 4. Si durante la corrección del PR el profesor considera que la entidad del problema es dudosa o ambigua, pedirá explícitamente que se detalle esta lógica de negocio en el README.
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 pongamos 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, el tipo de problemas adecuados para la asignatura 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í en esta asignatura. Es decir, si la primera (o la segunda) solución en la que has pensado pasa por programar una serie 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 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.
Cuando se piense en la solución (o si el profesor pide que se especifique la lógica de negocio en este u otros objetivos), ésta debe:
En ningún caso la inclusión de estas palabras implica automáticamente que la lógica de negocio sea correcta. El cálculo debe ser suficientemente complejo, por ejemplo; la generación debe seguir una serie de pasos no triviales. El filtrado si es sólo búsqueda tampoco será suficiente y deberá combinarse con alguna otra operación un poco más compleja.
La lógica de negocio será creada y testeada más adelante, a partir del objetivo 4. 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 se pueda validar como una solución aceptable al problema.
En clase se hará un juego de rol para enfocar el problema, o poder hallar uno en caso de que se necesite ayuda.
En general, encontrar un proyecto que se pueda desarrollar en la asignatura es una cuestión personal, sobre todo porque es necesario que se trate de un proyecto donde uno tiene algún interés y conocimiento, y pueda identificar claramente cuáles son los retos y qué es lo que funciona y aporta valor al cliente (que puede ser uno mismo). La metodología denominada design thinking proporciona al estudiante una serie de pasos para poder entender posibles contextos en los cuales existe un problema, definirlo y proponer posibles soluciones.
En la primera sesión de clase se hará un juego de rol para poder abordar bien la fase de empatía de este proceso. Por tanto, se aconseja muy vivamente que se asista a esta primera clase y se participe en la actividad. Requisito obligatorio: Para asegurar que el problema surge de la dinámica en clase , el
README.mddebe incluir obligatoriamente una fotografía de la tarjeta o material físico utilizado durante el juego de rol. Si no has asistido a clase, tendrás que imprimirlo en tu casa y rellenarlo a mano trabajando con alguna persona de tu entorno, preferiblemente con conocimientos informáticos.Nota sobre Git y Markdown: Para incluir esta imagen, el estudiante debe añadir el archivo de la fotografía a su repositorio. Esto se hace copiando la imagen al directorio del repositorio, y luego usando
git add nombre_de_la_imagen.jpgseguido de su correspondientegit commitygit push. Una vez en el repositorio, se enlaza en elREADME.mdusando la sintaxis de Markdown con una ruta relativa, por ejemplo:.
Incluso con interés, un problema adicional es encontrar proyectos en los cuales existan ya datos. No se va a ser suficientemente empático (como pide la metodología de design thinking) en un proyecto que requiera del usuario introducir gran cantidad de datos para obtener un resultado puntual. Por eso, y también porque las fuentes de datos públicos suelen coincidir con problemas y preocupaciones de la ciudadanía, pueden ser interesantes como base para un proyecto en esta asignatura. Por ejemplo, pueden ser interesantes estos portales:
Estos se pueden usar tanto para completar datos de una aplicación, como para crear un backend de la aplicación, siempre que se le añada valor suficiente en forma de una lógica de negocio.
En los últimos objetivos, el proyecto será desplegado en la nube, tras la descripción de la infraestructura virtual que necesitará para ello. El problema que se plantee será tal que pueda ser resuelto de esa forma. No se requerirá que se resuelva el problema totalmente, pero la mejor solución tiene que estar en una infraestructura virtual en la nube.
Si el estudiante no encuentra ningún problema, si no explica el problema de forma que sea comprensible y quede claro que hay una lógica de negocio sustancial, o si ante el requerimiento del profesor de que incluya esta lógica de negocio no es capaz de probar que la lógica de negocio que tiene en mente tiene la entidad suficiente para la asignatura, este objetivo puede no superarse.
La superación de este objetivo es requisito indispensable para continuar en la asignatura en la convocatoria en la que se esté trabajando.
El estudiante nunca debe cerrar un PR, ya que es el medio de comunicación con el profesor; cualquier error debe repararse mediante commits en la rama asociada al PR.
Solo se debe fusionar el PRen el repositorio propio tras la aceptación explícita del profesor.
Toda la interacción debe realizarse de forma personal por parte del estudiante, porque se trata de que el estudiante entienda que el planteamiento de un problema es siempre el requisito previo para crear una aplicación que lo resuelva; el uso de herramientas de IA generativa para resolver el problema o redactar la documentación es una falta grave, y el plagio de otros compañeros (o el uso de sus soluciones como base) invalidará automáticamente la entrega sin más retroalimentación por parte del profesor.
En estos primeros compases de la asignatura es obligatoria la asistencia a clase, tanto las conjuntas como las divididas. Como la metodología se basa en tratar de ayudar al estudiante a superar el objetivo, lo mejor es intentar el diálogo con el profesor u otros compañeros para probar diferentes ideas o enfoques, y para evitar malas prácticas que puedan retrasar la aceptación de los siguientes objetivos.
ssh (no https).Primero, hay que configurar correctamente el entorno de desarrollo para este y otros proyectos, lo que incluye
Usar un repositorio de forma correcta no solo permite organizar el trabajo de desarrollo de forma más eficiente, sino que también contribuye a que sea más fácil colaborar a través de él y a la creación de buenos hábitos de trabajo colaborativo. Hay una serie de buenas prácticas, que incluyen, pero no se limitan, a
Usar o bien el sistema de control de versiones que se incluya en el entorno de desarrollo, y con esto quiero decir, por ejemplo, que si se suele usar Emacs, VSCode, o algún editor específico para el lenguaje de programación que se vaya a usar, suelen tener un sistema de control de versiones integrado, o bien la línea de órdenes, lo que se recomienda, pero solo para las órdenes propias de git (es decir, excluyendo órdenes de GitHub como crear repositorios, que son propias de la web y del cliente de línea de órdenes de GitHub).
Entender bien el concepto de commit; por esa razón, hacer commits que abarquen una sola funcionalidad o tarea, pero solo si la funcionalidad es correcta (no tiene errores sintácticos, por ejemplo). Hacer commits a menudo.
De la misma forma, recordar que commit y push no son inseparables. Se hace push cuando se quiere sincronizar, y cuando se quieren pasar los tests. En caso de recursos de test limitados (créditos limitados, por ejemplo), cuantos menos push se hagan, mejor. Por eso, hacerlos sólo cuando se haya terminado una sesión de trabajo o se quiera sincronizar con el resto del equipo.
Usar desde el principio un fichero .gitignore para evitar añadir
accidentalmente ficheros que no deban estar en el repositorio, tales como
ficheros de respaldo o ficheros generados en compilación o construcción. Si se
encuentran estos ficheros, se advertirá en la corrección.
Siempre comprobar, antes de hacer un pull request, que se está trabajando
sobre la última copia del fichero compartido (el de la entrega) para evitar
conflictos que imposibiliten que se lleve a cabo la fusión por parte de la
persona encargada del mismo. Para ello, hacer git pull --rebase
inmediatamente antes de hacer push a una rama desde la que se vaya a
hacer PR. En general, sin embargo, se aconseja que se use directamente la
edición de la página de entrega en la web para asegurarse de que se crea una
rama nueva sobre la última versión.
El proceso de design thinking para decidir sobre qué problema trabajar está descrito también en esta presentación o este tema.
El concepto de lógica de negocio se explica en este vídeo.
Cada proyecto tendrá su propio repositorio en GitHub. La documentación se incluirá en ficheros con el formato Markdown (en su sabor GitHub, en caso de que se desee). Esta descripción de la aplicación irá evolucionando con los diferentes objetivos.
En este objetivo, los ficheros solicitados se crearán, en general,
simplemente respondiendo a las preguntas de creación del
repositorio. Sin embargo, adicionalmente hay que incluir en el fichero
README.md una descripción de un problema que se vaya a intentar
solucionar a lo largo de la asignatura, en las sucesivas entregas de un
proyecto que se desplegará en la nube. A partir
de ahora, en todos los objetivos se seguirá el siguiente
procedimiento.
Para auxiliar al estudiante en estas labores se ha creado un plugin de
gitespecífico para la asignatura. Seguir las instrucciones en el mismo plugin para descargarlo e instalarlo.
git iv
objetivo 0, que creará la rama y se trabajará en la misma.Una vez hecho lo anterior, se añadirá al fichero de entrega del proyecto en el
repositorio anual de la asignatura en la fila correspondiente,
el nombre del proyecto, un enlace al PR que se ha creado desde una rama del
repositorio y una versión, que seguirá el formato estándar vx.y.z, llamado
versionado semántico.
Entre estos números,
xsería la versión major que habrá que mantener a 0 durante toda la asignatura.yse denomina minor, y la haremos corresponder a cada uno de los objetivos. El tercer grupo de dígitos,zse llama patchlevel, y será lo que hay que aumentar cada vez que se corrige el PR y se busca que se pasen de nuevo los tests en el repo de la asignatura. No usar el formato correcto lanzará un error en el test que pasa el PR. En este objetivo tendremos, por tanto, que usar el formatov0.0.z.
Para enviar este PR el estudiante creará también una rama específica del repositorio de la asignatura, y hará un nuevo PR desde la misma.
Por si queda poco claro, son dos PRs en dos repositorios diferentes. Uno en el repositorio del estudiante, desde una rama creada específicamente para cada objetivo a la principal, y otro en el de la asignatura, desde una rama también específica del objetivo a la principal.
El sistema de tests que se ejecutan cuando se hace este envío asegura la contención de cualquier tipo de cambio por parte del estudiante en el que se haga algo que pueda afectar al repositorio de la asignatura.
El README.md del proyecto será, efectivamente, la descripción del
mismo. Documentación adicional (por ejemplo, en la documentación de este
objetivo mostrar que se han llevado a cabo las configuraciones que se han
solicitado) se deben poner en un directorio aparte y enlazarse desde el
README.md en un apartado específico (al final del mismo, por ejemplo). Por
ejemplo, pantallazos u otro tipo de documentación que pruebe que se ha
configurado correctamente git.
En general, el README.md sólo incluirá temas relativos al proyecto en sí. Lo necesario para valorar si se ha alcanzado el objetivo o no deberán ir en documentos aparte, para que se puedan corregir.
Cuando el profesor apruebe el PR en el repositorio del estudiante, se podrá fusionar ese contenido con su rama principal; en ese momento se estimará que se ha alcanzado el objetivo requerido. El profesor revisará, uno por uno, todos los envíos y hará preguntas (que habrá que aclarar generalmente investigando algún aspecto que no quede claro y cambiando el código) o sugerencias, que encaminarán al estudiante a entender mejor los objetivos correspondientes, y eventualmente a superar el objetivo.
Por esto, se puede entregar el objetivo varias veces mejorándolo siguiendo los consejos del profesor. El estudiante no debe tratar de poner lo que pide en la primera ocasión, ni en la segunda. Debe tratar de entender qué es lo que tiene que aprender en cada objetivo, y transmitirlo en lo que entregue. Lo importante siempre es lo que aprenda y que aplique la metodología correctamente, no lo que ponga o escriba. Esto se aplica a este objetivo, y por supuesto al resto de la asignatura.
Por si no queda claro, lo que ponga otro compañero o lo que le devuelva una IA generativa en general, va a ser incorrecto en tu entrega, porque es el estudiante el que tiene que aplicar la metodología, y esto no incluye en ningún momento el uso de herramientas generativas para que lo hagan por él. Si por cualquier razón el estudiante lee lo que ha puesto otro compañero, que sea para no repetir en ningún caso ni sus decisiones ni sus palabras.
Por eso, no tiene que esperar a tenerlo perfecto para entregarlo; basta con que pase los requisitos mínimos, que se comprueban como tests. No se espera que esté perfecto con la entrega, se espera que con la ayuda del profesor y, a partir del objetivo siguiente, de los compañeros, se alcancen los objetivos de aprendizaje.
Por esto también es importante que el estudiante asista a clase, y no deje el aula cuando terminen las “explicaciones”. La metodología de esta asignatura está centrada en el estudiante, y en ayudar al estudiante sobre la marcha, cuando se produzca el problema. De esta forma también podrá hacer el envío en clase y que se le corrija sobre la marcha, si es posible.
Importante: el título de este pull request tiene que incluir la cadena
[IV-26-27] para que pueda filtrar fácilmente los mensajes recibidos.
El no hacerlo así lanzará también un error en el PR.
El estudiante debe hacerse estas preguntas cuando envíe el objetivo. Tendrá que ser positiva la respuesta a todas, si quiere tener posibilidades de superación del objetivo, pero que las marque como conseguidas no garantiza ni tiene relación alguna con la consecución del mismo. Así que debe marcar solamente las que efectivamente haya superado, pero en ese caso debe volver sobre las que no haya marcado y revisar su envío para hacerlo correctamente.
* [ ] ¿Se trata de un problema real del que se tenga conocimiento personal?
* [ ] ¿Se trata de un problema que para solucionar requiera el despliegue
de una aplicación en la nube?
* [ ] ¿La solución requiere una cierta cantidad de lógica de negocio, en vez de
solucionarse sólo almacenando y buscando?
* [ ] ¿Se ha incluido la configuración del repositorio y se ha enlazado desde el
`README`?
* [ ] ¿Se ha incluido y enlazado correctamente la fotografía de la tarjeta del juego de rol en el `README.md` subiéndola al repositorio?
* [ ] ¿El estudiante tiene todos los datos necesarios para poder resolver el problema, o va
a requerir que el usuario los introduzca?
* [ ] ¿Se está marcando al buen tuntún todo?
Lo importante es que el estudiante verifique esta lista de comprobación. Puede incluir en el mensaje de commit cuál de estas preguntas está respondiendo, porque los mensajes de commit explican por qué se ha hecho algo.
El alcanzar este objetivo avanzará, aproximadamente, 5% de la parte correspondiente de la asignatura.
Los plazos para la convocatoria ordinaria (a partir del comienzo del curso) son:
En cursos anteriores,
A partir de la entrega, si se tarda más de 17 días en superar el objetivo la probabilidad de aprobar la asignatura en convocatoria ordinaria desciende del 50%; por esto se establece el plazo máximo. Es conveniente, por lo tanto, que se realicen con celeridad las correcciones siguiendo las indicaciones del profesor.
Si el estudiante no supera el objetivo 0, no podrá superar la asignatura en convocatoria ordinaria. Sin embargo, dado que la evaluación en la convocatoria extraordinaria sigue el mismo proceso que en la ordinaria, se puede seguir intentando superar este y los siguientes objetivos y solicitar revisiones, aunque en ningún caso se considerará superado en la ordinaria.
Si no se ha entregado el objetivo en el plazo indicado solo hay una opción, entregarlo, si se quiere seguir optando en la convocatoria extraordinaria. La entrega de cada objetivo es condición necesaria para la entrega de los siguientes. Una vez entregado hay una vez más las dos opciones que se muestran anteriormente.
Una vez entregado, el estudiante puede comenzar por su cuenta con el siguiente objetivo. Se pueden tener todos los PRs que se deseen abiertos en el repositorio.
Se aconseja en todo caso que se inicie el trabajo en ese objetivo inmediatamente en cuanto que se entregue este objetivo, no es necesario esperar a que se explique en clase. Se puede solicitar al profesor que lo explique individualmente, si se está en clase, o simplemente leerlo y plantear las dudas que surjan en el grupo de Telegram de la asignatura; si hay suficientes que lo hayan superado y está lejos la siguiente clase se propondrá una tutoría grupal.