Se trata de definir un proyecto entre las diferentes posibilidades que se planteen, explicar su arquitectura y organizar los hitos para el trabajo en el mismo. Lo esencial es entender cuál es la arquitectura y la entidad de lo que se despliega en la nube y quién va a ser el cliente del mismo (uno mismo, alguna empresa con la que se haya contactado, el tutor o tutora del TFM). También es conveniente ir pensando si se va o no a coordinar con otro u otros proyectos, documentar la arquitectura del proyecto elegido y las razones por la que se ha hecho y los pasos que se van a dar en el mismo.
Haber alcanzado los objetivos de las sesiones correspondientes de la asignatura.
El proyecto habrá sido descrito (en términos generales) en el hito anterior, aunque se puede ampliar o alterar la misma, siempre que tenga los siguientes requisitos:
- Tener una definición de infraestructura virtual de suficiente entidad.
- Una licencia libre.
Es importante que tengáis en cuenta que lo que se va a evaluar dentro de la asignatura es la infraestructura, no el proyecto en sí; no se va a valorar si es un proyecto con un montón de líneas de código pero realmente el despliegue y la infraestructura virtual necesaria es demasiado sencilla.
Realmente en este hito ni siquiera es necesario desplegar una línea de código.
Aparte de los requisitos anteriores el tema del proyecto es totalmente libre: por ejemplo, infraestructura virtual para el trabajo de fin de grado del año anterior o el trabajo fin de máster, aunque teniendo en cuenta que en enero tiene que estar el proyecto desplegado quizás sea más conveniente sólo abordar una parte del mismo (en este último caso). Se valorará, por otro lado, que el proyecto sea lo más realista posible, así que si, por ejemplo, se hace bajo los requisitos de una empresa externa se valorará también. Cuanto menos "académico" y más útil sea el proyecto, mejor se valorará.
Al final, claro, no en este primer hito. En este nos limitamos a que hayáis entendido el concepto de "proyecto desplegable en la nube" y la arquitectura que se usa en el mismo.
Se trata también de que entendáis qué es lo que se despliega en la nube. En general, desplegar es llevar a producción una aplicación. La parte que realmente se despliega es la parte que se va a colocar en diferentes servidores, junto con la activación de diferentes servicios. Esta es la parte del proyecto que hay que especificar con claridad. Las tecnologías que vaya a usar en el front-end, en principio, son totalmente independientes de lo que se vaya a desplegar y por tanto es mejor no mencionarlas en este hito.
El proyecto será individual. Eso no excluye que el proyecto forme parte de una aplicación mayor creada por varios alumnos de la asignatura o, para el caso, de fuera de la universidad. El caso es que se va a valorar de forma individual y no por el código aportado por el resto de los colaboradores. También se valorará sólo el código (infraestructura como código) relacionado con la asignatura, aunque si se ha tenido que hacer algún código de apoyo para que todo funcione se tendrá en cuenta también.
Este hito será el inicio de despliegue de la infraestructura virtual del proyecto, que eventualmente se tendrá que desplegar completo.
Tendréis que pensar en un cliente potencial que será el que especifique de qué va a ir el proyecto. Podéis ser vosotros mismos, vuestro tutor de TFM/G o una empresa con la que hayáis hablado. Se interaccionará con este cliente a base de entrevistas, que tendrán que explicitarse en los hitos de la asignatura. Si el cliente es sólo imaginario, tendrá que especificarse en todo caso en un documento la infraestructura necesaria y qué ha soliticado tal cliente. En general, no hace falta que describáis en el hito el proyecto completo, sino sólo la parte que se vaya a desplegar, que puede ser (o no) toda la parte servidor de la aplicación.
La planificación del resto dedel proyetco es la esencia de este hito, es decir, donde tendrán que planificarse y crearse explícitamente en GitHub el resto de los hitos del proyecto, que pueden corresponder o no a los hitos de la asignatura; cada hito del proyecto de la asignatura corresponderá a uno o más hitos de nuestro proyecto que tendrán que ponerse explícitamente en el repositorio de GitHub. Por otro lado, tendrán que empezar a usarse las buenas prácticas explicadas en el anterior hito, especialmente
- Todo issue debe estar dentro de un hito y contribuir al mismo.
- Todo commit debe referirse a uno o mas issues.
- Todo issue se tiene que cerrar con un commit.
Los issues correspondientes a los hitos 0 y 1 tendrán que seguir obligatoriamente esta regla. A partir de este hito, el resto tendrá también que hacerse de la misma forma.
Subir los fuentes a GitHub y
editar este fichero enlazando el último commit
en el
que se indique claramente el nombre del alumno y la dirección donde se ha subido el
fuente. Si se va a hacer en coordinación con otros proyectos se
puede indicar en el mismo README.md.
La explicación del proyecto deberá incluir los criterios usados para
elegirlo, una explicación de qué hará la aplicación (o parte de la
misma que se haya elegido para la asignatura) y de
los pasos llevados a cabo para crearla en forma de hitos (un enlace a
los mismos es suficiente). Esta documentación se incluirá
en ficheros MarkDown en una rama diferente a master y enlazada
desde el README.md
- 2 puntos: Entrega sin conflictos y con uso correcto de hitos e issues.
- 3 puntos: Elección correcta de una arquitectura de software desplegable en la nube, abordable dentro de los términos de la asignatura y de acuerdo con lo expuesto en el tema correspondiente.
- 3 puntos: Descripción correcta de cada uno de los componentes o servicios necesarios para el proyecto en la arquitectura anterior y la interrelación entre los mismos.
- 2 puntos: concedidos por originalidad de la aplicación, grado de terminación, utilidad para la asignatura, cantidad de trabajo invertido.
Si el repositorio no existe, tiene algún error, no se ha hecho pull request correctamente o no están los fuentes publicados, la práctica estará suspensa.