-
Notifications
You must be signed in to change notification settings - Fork 0
Documento del Proyecto
Este proyecto ha consistido en el desarrollo de una API con todo el programa de las jornadas InnoSoft. Además se ha implementado el registro de usuarios y staff de forma que queden registrados en la plataforma y puedan acceder a la misma; las ponencias y ponentes, de forma que se obtenga toda la información que se pueda necesitar de los mismos; y la posibilidad de que los usuarios se puedan apuntar a las ponencias desde el sistema. Además, para hacer más llevadero el tema de la asistencia se ha implementado un sistema de validación de la asistencia mediante código QR.
(debe dejar enlaces a evidencias que permitan de una forma sencilla analizar estos indicadores, con gráficas y/o con enlaces)
| Miembro del equipo | Horas | Commits | LoC | Test | Issues | Incremento |
|---|---|---|---|---|---|---|
| Cote Medina, Carlos | HH | XX | YY | ZZ | II | Descripción breve |
| Pantión Loza, Moisés | HH | XX | YY | ZZ | II | Descripción breve |
| Pantoja Bas, Miquel Ángel | HH | XX | YY | ZZ | II | Descripción breve |
| Barba Roque, Enrique | HH | XX | YY | ZZ | II | Descripción breve |
| Sánchez Rodríguez, Manuel | HH | XX | YY | ZZ | II | Descripción breve |
| Gracia Barroso, Adrián | HH | XX | YY | ZZ | II | Descripción breve |
| TOTAL | tHH | tXX | tYY | tZZ | tII | Descripción breve |
La tabla contiene la información de cada miembro del proyecto y el total de la siguiente forma:
- Commits: solo contar los commits hechos por miembros del equipo, no lo commits previos
- LoC (líneas de código): solo contar las líneas producidas por el equipo y no las que ya existían o las que se producen al incluir código de terceros
- Test: solo contar los test realizados por el equipo nuevos
- Issues: solo contar las issues gestionadas dentro del proyecto y que hayan sido gestionadas por el equipo
- Incremento: principal incremento funcional del que se ha hecho cargo el miembro del proyecto
Aunque no nos hemos integrado con ningún equipo como tal, si que nos hemos puesto a colaborar con ciertos miembros del staff de las jornadas InnoSoft. Además, tenemos la suerte de que contamos con dos miembros del staff en nuestro propio equipo:
- Comité de logística (Barba Roque, Enrique): coordinador del comité de logística.
- Comité de programa (Cote Medina, Carlos): integrante del comité de programa.
Esta organización ha sido bastante importante a la hora de obtener información sobre el funcionamiento interno de las jornadas, ya que de esta forma hemos podido tener de primera mano (especialmente con nuestros dos miembros que pertenecen a las jornadas) información relevante que nos ha permitido desarrollar la idea principal de forma rápida y sabiendo lo que se podía hacer y lo que no para posteriormente, proceder con el desarrollo.
Se explicará el sistema desarrollado desde un punto de vista funcional y arquitectónico. Se hará una descripción tanto funcional como técnica de sus componentes y su relación con el resto de subsistemas. Habrá una sección que enumere explícitamente cuáles son los cambios que se han desarrollado para el proyecto.
Para este proyecto, dado que hemos realizado una API, hemos desarrollado la parte programática, el back-end, y hemos omitido las vistas ya que no entraba en nuestro alcance. Además hemos creído que puede ser conveniente para que el año que viene un equipo pueda seguir desarrollando a partir de este proyecto para convertir la API en un sistema web completo.
Dicho esto, para explicar el funcionamiento del proyecto se va a dividir la explicación en las tres aplicaciones que tiene:
Registro: La aplicación de registro (o funcionalidad/feature de registro) es tal y lo que indica su nombre, un registro como cualquier otro. Sin embargo hemos decidido priorizar el UVUS antes que el nombre de usuario, de forma que al ser único pueda servir como ID.
Además, un usuario se puede registrar tanto como usuario normal como moderador/parte del staff de las jornadas. Esto es así porque hemos pensado que esta API no solo puede ser útil de cara a usuarios externos sino que a los mismos miembros de las jornadas InnoSoft les puede servir, tanto para publicar información como para llevar registro de asistencia.
Por lo tanto, un usuario que quiera hacer uso del sistema se registraría mediante un administrador del sistema, ya que solo pueden registrarse personas matriculadas en la asignatura de EGC. Dicho administrador sería el encargado de registrar al usuario en el sistema mediante llamadas a la API con sus correspondientes datos. De esta forma ya podría acceder a la función de inscripción a ponencias, por lo que este registro sería el primer paso.
Programa: La aplicación de programa es la primera que se pensó a la hora de desarrollar el proyecto, ya que trata el acceso a la información de las ponencias y los ponentes que las realizan, siendo este el principal motivo de desarrollo de la API. Posteriormente, debido a la simpleza del proyecto, decidimos ampliarlo con las otras aplicaciones que vienen descritas hasta convertirse en lo que es hoy.
Como he dicho, la función de esta aplicación no es otra sino la de poder obtener toda la información de las ponencias (titulo, horario, ponente, etc) así como de los ponentes que las realizan, todo esto pensado para que se pueda usar en otros servicios web de eventos.
Esto tiene dos funcionalidades posibles: o bien como usuario quiero ver información de las ponencias y por lo tanto, mediante llamadas a la API consigo dicha información (actualmente en formato JSON debido a la falta de una vista); o bien consumo dicha información mediante la integración de la API en mi servicio web de forma que presente una vista para los usuarios y añada de esta forma una funcionalidad a mi aplicación.
Inscripción: Por último, tenemos la aplicación de inscripción. Esta aplicación relaciona las otras dos y ofrece una herramienta que creemos que será de gran ayuda para el staff de las jornadas: verificación de asistencia mediante QR.
Primero, una vez hay un usuario y una ponencia registradas, dicho usuario puede inscribirse a esa ponencia para dejar por escrito que piensa (o quiere) asistir a dicha charla, pero como hemos visto este año, el recuento de la asistencia (especialmente en tiempos de pandemia donde las jornadas han de realizarse telemáticamente) tiene dos problemas:
- Es un proceso bastante tedioso y que hay que realizar a mano
- Es algo complicado ya que no siempre se puede saber con certeza si alguien de verdad está pendiente o si tiene la charla de fondo mientras hace cualquier otra cosa.
Respecto al segundo problema no podemos hacer gran cosa, pero para intentar resolver el primero hemos pensado en un sistema de verificación de asistencia mediante QR. Funciona de la siguiente forma:
Una vez el usuario se haya inscrito en la ponencia, el día de la ponencia se generará un código QR al que solo tendrá acceso el moderador (persona encargada de regular la asistencia, ya sea tanto telemática como presencialmente). Será entonces cuando el usuario que se ha inscrito deberá escanear el código QR para verificar su asistencia a la charla, quedando un registro en el sistema y por lo tanto, permitiendo llevar un control de forma más sencilla. Además se han añadido las posibilidades tanto de mostrar las asistencias a las que ha asistido un usuario como la de mostrar todos los asistentes que ha tenido una ponencia, facilitando así el recuento.
Su uso sería el siguiente entonces: un usuario ya registrado en el sistema se inscribe a una ponencia y el día de dicha ponencia, escanea el código QR que le facilitará el moderador de la ponencia, confirmando así su asistencia.
- Un usuario (antes de estar registrado) quiere acceder a información de las ponencias para ver a cuál le interesa asistir, por lo que accede a dicha información mediante:
- Peticiones a la API
- Webs externas que hayan hecho uso de la API y muestren dicha información
- Una vez haya consumido dicha información y ya sepa las charlas a las que desea asistir, se pone en contacto con el administrador (si es que no se registran a todos los matriculados de forma automática) para que realice el registro en el sistema.
- Después de haberse registrado puede acceder a la lista de ponencias para proceder a inscribirse a las que desee.
- Por ultimo, el día de la ponencia ha de asistir a la charla y verificar su asistencia mediante el escaneo del código QR que le facilitara el moderador de la ponencia. En caso de que no se escanee el código, no se verificará la asistencia y por lo tanto será como si no hubiese asistido.
- Finalmente, un miembro del staff de las jornadas puede acceder a la lista de asistentes de una ponencia o bien listar las ponencias a las que ha asistido un usuario para realizar recuento.
En paralelo con la descripción funcional, procedemos ahora a proporcionar la descripción técnica de nuestra API a través de las tres aplicaciones que la componen.
Permisos presentes en la aplicación: existen permisos de acceso que ofrecen granularidad al acceso de las funcionalidades de la API que van relacionadas con el grupo al que pertenece cada usuario registrado que realiza una petición. Estos grupos son Administrador, Moderador, Staff y Participante.
En primer lugar, tenemos la app de registro que cuenta con un único modelo que es un usuario que hemos creado de forma personalizada utilizando AbstractUser puesto que estábamos conformes con los atributos presentes en el modelo de usuario presenten en django por defecto, pero queríamos cambiar el username field para que se identificara con el uvus. La lógica de esta aplicación suministra las siguientes funcionalidades: Listar los usuarios, registrar, actualizar y eliminar un usuario. La lógica implementada requiere autorización mediante Token, por lo que todas aquellas peticiones que se realicen sin suministrar un Token no serán atendidas, además se restringe el acceso a las funcionalidades anteriormente mencionadas de la siguiente forma: para listar un usuario, bastará con ser un usuario administrador, moderador o staff. Para registrar, actualizar o eliminar un usuario deberá ser un usuario perteneciente al grupo administrador. A su vez, existe una funcionalidad que emplea Djoser para la recuperación del Token que nos permite realizar la autenticación proporcionando un uvus y una contraseña que correspondan con los de un usuario registrado actualmente en el sistema.
En segundo lugar, tenemos la app de programa, que presenta los modelos de Ponencia y Ponente. Estos modelos, hacen referencia al evento que se produce en las jornadas innosoft y a las personas encargadas de llevarlos y proporcionar su contenido respectivamente. Dada una ponencia, podemos saber el nombre de la ponencia, los ponentes que la ofrecen, la descripción de la misma, la fecha, el lugar y la categoría a la que pertenece. Dado un ponente, podemos saber sus nombres y apellidos, su teléfono y su correo electrónico. La lógica de esta aplicación nos permite visualizar un ponente, estemos o no registrados en el sistema, crear un nuevo ponente, actualizarlo o eliminarlo, solamente si somos administradores y de la misma forma para una ponencia.
En tercer lugar, tenemos la app de participación que cuenta con un modelo de asistencia(ACABAR )
A continuación se contará lo transcurrido a lo largo del diseño y desarrollo del proyecto, exponiendo las distintas versiones de diseño que han existido y como estas han ido evolucionando hasta el software que ha sido desarrollado finalmente.
En primer lugar, hemos comenzado con un Brain Storming para plantear una idea de proyecto a desarrollar, con eso obtuvimos la idea de desarrollar un sistema de conteo de asistencias, así como de registro de ponentes y ponencias. A modo de base para el desarrollo decidimos dividir todo el trabajo en 4 aplicaciones independientes entre si, estas son:
Asistencia: en esta aplicación se permitía a los alumnos inscritos a las diferentes ponencias generar un código QR a modo de identificación para su usuario para esa ponencia. Por otro lado, permitía a un moderador escanear los códigos QR anteriormente mencionados que muestren los alumnos al entrar a la ponencia, y así registrar su asistencia en la base de datos.
Autenticación: en esta aplicación se permitía el registro por parte de un administrador, y el inicio de sesión de los usuarios, haciendo uso de su UVUS como identificador único para su usuario.
Inscripción: en esta aplicación se permitía a los usuarios registrarse en una ponencia con su usuario, de manera que en la base de datos quedaban relacionados el usuario con la ponencia.
Programa: en esta aplicación se registraban las ponencias que se iban a realizar, incluyendo su horario, fecha y una breve descripción de su contenido, y además de esto su ponente, con algunos datos básicos para poder identificar a la persona.
Además, durante el Brain Storming inicial se decidió que el sistema sería una API que incluiría la función de generación de imágenes QR para la confirmación de la asistencia entre otras muchas más.
Más tarde, tras empezar con los primeros commits y pensar con más detenimiento el sistema a seguir, se decidió eliminar una de las cuatro aplicaciones y redefinir el sistema completo, con ello quedaron las siguientes 3 aplicaciones:
Participación: las anteriores aplicaciones “Asistencia” e “Inscripción” quedan fusionadas en esta aplicación ya que estaban altamente relacionadas la una con la otra. Tras realizar esta fusión queda que la aplicación dispone de las funcionalidades necesarias para que un usuario se inscriba en una ponencia, la funcionalidad respectiva a la generación de códigos QR para los alumnos asistentes a las diferentes ponencias, y la funcionalidad correspondiente al escaneo por parte de un moderador de los anteriormente mencionados códigos QR para la confirmación de su asistencia.
Programa: esta aplicación no varía con respecto a su anterior versión.
Registro: esta aplicación es correspondiente a la aplicación “Autenticación”, posee exactamente las mismas funcionalidades que fueron mencionadas antes pero se decidió renombrarla debido a que su anterior nombre generaba confusión.
Tras realizar estos cambios se pudo continuar con el desarrollo de la API sin ningún problema con respecto al diseño.
En un principio se comenzó a realizar los documentos necesarios para la creación del proyecto en la plataforma Google Drive, en la que poseíamos una carpeta compartida con todos los miembros del grupo de manera que fuera accesible para todos y se pudiera trabajar en el documento de manera simultánea, pero más tarde se decidió mover los documentos a la pestaña wiki de nuestro repositorio de GitHub. Debido a la necesidad de conteo de palabras para saber si la cantidad de texto era adecuada para cada uno de los apartados y por las dificultades existentes en esta plataforma para la redacción simultanea por parte de dos miembros de un documento, se decidió usar la herramienta Word para desarrollar el apartado que se desea modificar y una vez se deje de trabajar se añadirá a la wiki todo el contenido desarrollado de una vez para no interactuar con las adiciones a la página de los otros miembros.
Para poder administrarnos de forma sencilla y eficaz necesitábamos un tablero donde recopilar las tareas que debían abordar cada uno de los integrantes del grupo, hemos decidido usar el tablero de la pestaña projects de GitHub, en ella hemos dividido el proyecto en las tareas que hemos visto convenientes y estas han sido asignadas de manera aleatoria a los integrantes del grupo, este tablero posee varias columnas indicando el estado de la tarea, los estados disponibles son los siguientes:
To do: este estado corresponde a las tareas que pueden o no haber sido asignadas aún y que aún no han sido comenzadas por nadie.
In progress: este estado corresponde a las tareas que, tras haber sido asignadas, han comenzado su desarrollo pero aún no han sido finalizadas.
Stuck: este estado corresponde a las tareas que han sido comenzadas y tras un periodo de desarrollo sin ningún tipo de avance destacable ha sido anotado como atascado y espera la contribución de otro miembro del grupo para poder continuar.
To check: este estado corresponde a las tareas que han sido finalizadas y comprobadas por el correspondiente desarrollador, pero que aún debe ser comprobada por segunda vez por una segunda persona para ser validada.
Done: este estado corresponde a las tareas que han sido finalizadas y validadas por otro integrante del proyecto.
El tablero anteriormente mencionado debe ser actualizado a medida que se desarrolla el proyecto, así como modificado según vayan surgiendo cambios en el diseño del proyecto. Será responsabilidad del grupo al completo mantener el tablero actualizado a su propio desarrollo y a los cambios en el diseño que surjan en las reuniones.
También era necesario disponer de un repositorio en el que poder compartir y descargar código entre los miembros del equipo por lo que decidimos usar los repositorios de GitHub, en este hemos definido una estrategia tanto de ramas como de commits.
La estrategia de ramas consistía en la disposición de varias ramas según la tarea que tuvieran que hacer:
Main: en esta rama se encontraría el código inicial, y una vez el proyecto estuviera terminado y pulido se subiría la versión final del producto.
Develop: esta rama fue creada a partir de Main, y sería actualizada a medida que las distintas ramas que parten de esta fueran siendo finalizadas, una vez terminadas todas las ramas inferiores se pulirían errores y se subiría a Main.
Dev-: las ramas siguiendo esta estructura serían ramas de desarrollo creadas a partir de Develop, y en estas los desarrolladores crearían el código necesario para completar su tarea, además de los correspondientes módulos de testing necesarios para la comprobación correcta del código producido. Tras cumplir lo dicho anteriormente, la rama estaría lista para ser unida a la rama Develop.
La estrategia de commits consiste en el uso de un dialecto común para poder saber en que consiste cada commit realizado por los otros integrantes del grupo o con los de uno mismo. Esta consistiría en la siguiente estructura “tipo(objeto): descripción corta”. El tipo sería el objetivo del commit, principalmente se usarán los tipos “feat”(feature, código desarrollado para cumplir una de las tareas asignadas), “fix”( reparación de código en mal estado) o “test”(código desarrollado para la comprobación del correcto funcionamiento del código).
Para comunicarnos entre nosotros usamos Telegram debido a su comodidad, además de esto, realizamos reuniones semanales para discutir los avances realizados, ayudar a las personas que se encuentran atascadas y, normalmente, trabajar en grupo. Para las reuniones, debido a la situación en la que nos encontramos por la pandemia mundial del Covid-19, usamos la aplicación Discord, en la que podemos hacer llamadas grupales y compartir pantalla para poder exponer información o problemas a los compañeros y poder comunicarnos de manera eficaz.
debe explicar cuál es el entorno de desarrollo que ha usado, cuáles son las versiones usadas y qué pasos hay que seguir para instalar tanto su sistema como los subsistemas relacionados para hacer funcionar el sistema al completo. Si se han usado distintos entornos de desarrollo por parte de distintos miembros del grupo, también debe referenciarlo aquí.
En esta sección abordaremos cual ha sido nuestro plan de gestión de incidencias a la hora de abordar este proyecto.
Enunciemos pues cuales son los pasos para seguir a la hora de realizar la gestión de incidencias que se producen internamente dentro de nuestro grupo de desarrollo, en definitiva, cual sería el flujo de la gestión de la incidencia.
En primer lugar, se debe detectar la incidencia lo antes posible y así minimizar el alcance de las consecuencias de la misma. Las incidencias son reportadas inmediatamente son detectadas a través de varios canales: Telegram y Discord. De esta forma, garantizamos con certeza el día que fue detectada y que todos los miembros que componen el grupo de desarrollo se encuentran al tanto de la detección de dicha incidencia. Si la incidencia tuviera relación con algún commit se debería reflejar en el registro de que commit se trata proporcionando su identificador.
En segundo lugar, se debe registrar la incidencia de forma individual incluyendo la mayor cantidad de información disponible para así disponer de datos que puedan ayudar en si resolución. El registro contiene información de vital importancia sobre la incidencia, tales como si hay un commit relacionado con la misma, el estado, el tipo de incidencia que es, la prioridad, una descripción detallada, el día que se abrió, quien informó de su existencia, a quien se le asigna su resolución y la cantidad de días que ha estado abierto hasta su resolución. Estos últimos datos se deben cumplimentar a lo largo del ciclo de vida de la incidencia por diferentes miembros del equipo.
En tercer lugar, el miembro adecuado debe categorizar la incidencia ya que categorizarla y describir de que tipo es la incidencia nos permite en primer lugar clasificarlos, nos permite priorizar los problemas y nos proporciona también un seguimiento preciso de los diferentes incidentes ya que una vez que clasificamos los diferentes incidentes surgen patrones que nos permitirán cuantificar con qué frecuencia pueden darse nuevos incidentes y señalar tendencias.
En cuarto lugar, procederemos a priorizar las incidencias, para ello, debemos evaluar si un incidente puede ser solucionado de forma inmediata o si es necesario de la intervención de otro miembro del equipo. La prioridad de un incidente estará determinada, como ya hemos comentado, por el impacto que pueda suponer a los diferentes miembros de desarrollo, por tanto, el impacto lo entendemos como la medida del alcance del daño potencial que el incidente puede provocar.
Por tanto, definiremos que los incidentes graves, por ejemplo, deben ser solucionados en un tiempo menor debido a su impacto, de esta forma los priorizaremos por encima de otros incidentes. Por el contrario, los incidentes con baja prioridad serán aquellos que no supongan un impacto fuerte al desempeño de los diferentes miembros. Finalmente, los incidentes de prioridad media suponen un impacto, afectan a algunos miembros e interrumpen el trabajo hasta cierto punto.
Finalmente, una vez que ya hemos identificado, definido el tipo, asignado una prioridad de resolución y esta debidamente registrado podemos pasar a la resolución de la incidencia.
Una vez que empezamos a resolver la incidencia, debemos realizar un diagnóstico inicial de la misma. Una vez realizado el diagnóstico inicial es importante investigar y una vez que sabemos y se confirma que la hipótesis inicial del incidente se confirma ya podemos pasar a la resolución. Una vez encontremos la solución para la incidencia, esta debe ser aplicada realizando las pruebas necesarias para asegurar que la solución aplicada sea óptima y quede resuelta.
Cuando ya hayamos resuelto la incidencia, podremos pasar a la fase de cierre del incidente. Dentro de esta fase, actualizaremos el registro reflejando el nuevo estado y los días que ha ocupado para su resolución.
-
Prioridad de la incidencia: Definiremos la escala de la prioridad de los incidentes en graves, medios y bajos atendiendo siempre al tipo de incidencia que se trate a la hora de determinar la prioridad en la resolución de los mismos.
-
Estado de la incidencia: Definiremos el estado de la incidendia en abierta o cerrada, para referirnos si se trata de una incidencia que todavía no ha sido atendida y resuelta y para aquellas que ya han sido resueltas respectivamente.
-
Tipo de incidencia: Definiremos los incidentes en cuatro tipos. Incidentes críticos, incidentes altos, incidentes medios e incidentes bajos. Para definir de qué tipo es cada incidencia, nos basaremos en la cantidad de miembros del equipo que se vean afectados y el nivel de interrupción que esté causando dicho incidente. Este campo servirá para definir la prioridad que se le otorgue a una incidencia.
-
Roles asignados a la gestión de la incidencia: Definiremos los roles que intervienen en el proceso de resolución de la incidencia, entendiendo el rol encargado de solventarla, el encargado de documentarla y el que la ha detectado.
Las nuevas incidencias se deben registrar utilizando la siguiente plantilla:
| #Incidencia | Commit relacionado | Estado | Tipo | Prioridad | Descripción | Abierto el día | Informado por | Asignado a | Fecha de resolución | Cantidad de días abierto |
|---|---|---|---|---|---|---|---|---|---|---|
En nuestro caso, no nos encontramos directamente con incidencias externas recibidas por otros grupos puesto que no nos coordinamos con otros grupos que estén realizando algún tipo de incremento en un subsistema de Decide ya que nuestro desarrollo parte de cero y solamente dependemos exclusivamente de coordinarnos con los comités de las jornadas innosoft. La coordinación con dichos comités ha sido fluida debido al hecho que dos miembros de nuestro grupo de desarrollo pertenecen a dichos comités con una posición relevante en los mismos.
| #Incidencia | Commit relacionado | Estado | Tipo | Prioridad | Descripción | Abierto el día | Informado por | Asignado a | Fecha de resolución | Cantidad de días abierto |
|---|---|---|---|---|---|---|---|---|---|---|
| 4 | Merge sistema de Registro #40 | Cerrada | Incidente medio | Media | Al realizar las pruebas de programa surge un error debido a los permisos de acceso al contenido debido que no se encuentran disponibles. Adjunto error (Creating test database for alias 'default'...) | 27 de Diciembre de 2020 | Carlos Cote | Enrique Barba | 28 de Diciembre de 2020 | 1 día |
se explicarán los procesos, técnicas y herramientas para la gestión del código del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Guía de cómo y cuándo hacer commits: dé enlaces concretos a ejemplos que se puedan ver en su repositorio de cómo ha seguido esas guías.
- Usage model del repositorio: ¿cómo se gestiona el repositorio tanto del proyecto general como de su subproyecto?
Se explicarán los procesos, técnicas y herramientas para la gestión de la construcción e integración continua del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Proceso de integración continua que usa
- Herramientas que está usando para dar soporte a ese proceso
- Cuáles son los (al menos) 5 indicadores de calidad de los builds que ha utilizado para guiar su proceso. De detalles sobre este aspecto.
Se explicarán los procesos, técnicas y herramientas para la gestión de las liberaciones, despliegue y entregas del proyecto. Evite poner información de las herramientas en sí que se pueda encontrar en fuentes bibliográficas o internet. Si es del caso haga referencia a ellas. Céntrese en los aspectos particulares de su proyecto en concreto:
- Proceso definido para las liberaciones con un apartado explícito de cómo ha elegido la licencia de software para su proyecto
- Proceso definido para el despliegue
- Proceso definido para las entregas
- Política de nombrado e identificación de los entregables
se presentará un ejercicio con una propuesta concreta de cambio en la que a partir de un cambio que se requiera, se expliquen paso por paso (incluyendo comandos y uso de herramientas) lo que hay que hacer para realizar dicho cambio. Debe ser un ejercicio ilustrativo de todo el proceso de evolución y gestión de la configuración del proyecto.
se enunciarán algunas conclusiones y se presentará un apartado sobre las mejoras que se proponen para el futuro (curso siguiente) y que no han sido desarrolladas en el sistema que se entrega