-
Notifications
You must be signed in to change notification settings - Fork 0
Reuniones 📊
David-informatica edited this page Dec 20, 2023
·
24 revisions
Fecha 19/10/2023
Duracion: 1h
Important
- Especificamos los roles que tomaremos cada uno en las primeras iteraciones
- Creación del repositorio
- Configuración del entorno en visual paradigm y en eclipse
- Acuerdo de horario para la celebración de reuniones futuras
- Tareas para el equipo conectarse al repositorio y al proyecto compartido visual paradigm (no se generaron issues al no estar el repositorio creado)
- Los roles de cada persona estan especificados en la planificacion.
- El repositorio esta creado (a falta de incluir al profesor).
- Durante la reunion aclaramos los pasos a seguir para la configuracion de visual paradigm y de eclipse para poder generar codigo a partir del diseño en las proximas iteraciones
- Las reuniones tendran lugar cada miercoles por la mañana.
- Aceptar peticion para incluirnos en el repositorio.
- Configurar el entorno de visual paradigm y conectarse al repositorio compartido
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
- JOSÉ JAVIER BOGADO CANDIA ✔
Fecha 25/10/2023
Duracion: 1h 30 mins
Important
- Añadimos nuevo miembro del grupo (Arturo Avilés Morillas)
- Comprobamos que el nuevo miembro este al día
- Decidimos la estructura que tendrán las reuniones futuras
- Decidimos cuales son los subgrupos
- Comenzamos con la planificación PUD
- Detallamos indice de la planificación:
- Queda incluido Arturo Aviles en el repositorio junto con todo el equipo.
- Le informamos de que hemos hecho en la anterior reunión y le explicamos el proyecto.
- La estructura de las reuniones constara de la siguiente forma: primero anotamos la fecha y tratamos los asuntos mas urgentes o mas convenientes teniendo en cuenta la situación del proyecto, incluyendo sugerencias, quejas o cualquier cosa similar. A continuación anotamos detalladamente todos los aspectos mencionados. Después se revisan los acuerdos que se tomaron el la anterior reunión, para luego tomar nuevos acuerdo para la siguiente reunión. Finalmente se abren los issues correspondientes asignandolos a cada miembro del equipo y se anota el tiempo de duración de la reunión.
- Concretamos los subgrupos o parejas y lo incluimos en la planificación.
- Creamos una nueva pagina en la wiki dedicada a la planificación.
- El indice de la planificación sera el siguiente:
- Organización y roles
- Requisitos del proyecto
- Tiempo estimado
- Calendarios
- Presupuestos y otras estimaciones
- Todos los miembros del equipo estan incluidos en el repositorio
- Todos tienen el entorno configurado y se han conectado al repositorio compartido de visual paradigm
- Abrir una nueva pagina el la wiki para la planificación
- Completar cada uno de los campos de la planificación
No se abren issues en la reunión
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
- JOSÉ JAVIER BOGADO CANDIA ✔
Fecha 01/11/2023
Duracion: 1h
Important
- Configuración del entorno de maven en eclipse
- Puesta en marcha de los issues de github en el repositorio
- Solución de duda en clase sobre los issues (ahora todos tienen nuevos issues y los primeros seran abiertos y cerrados para dejar constancia, pero ya estarán resueltos)
- Concluir iteración 1
- Configuramos Maven para la realización de la parte de implementación y pruebas.
- Comenzamos a abrir los primeros issues.
- Solucionamos duda sobre el método de uso de los issues en el repositorio (resuelta en clase por Ismael).
- Comenzamos a trabajar en la primera iteración teniendo en cuenta cada uno de nuestros roles.
- Incluida la parte de planificación en la wiki
- Todos los campos de la planificación completos
- Queda la planificación terminada con el reparto de trabajo de la siguiente forma:
- Roles, requisitos y estimación: Jesus, Georgi y David
- Case diagrams: Rubén
- Presupuesto: Jose
- Calendario: Ivan
- Priorities assigment: Arturo
- Proporcionar retroalimentación en los issues abiertos
- Cerrar los issues que se han asignado cuando el responsable termine la asignación
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
Fecha 08/11/2023
Duracion: 1h
Important
- Rotación de las tareas del grupo
- Maven check
- El caso de uso "Generar número, código QR o Bluetooth para los asistentes" decidimos hacerlo en la iteración 5
- Hemos decidido cambiar la prioridad del caso de uso anterior por una prioridad menor
- Decidimos rotar las tareas de RADIT de cada pareja.
- Repaso genera a maven para comprobar el funcionamiento y resultados.
- Identificamos un error en la planificación donde el requisito "Generar número, código QR o Bluetooth para los asistentes" forma parte de la interacción 5 y lo corregimos.
- Por consecuencia del punto anterior el caso de uso "Generar número, código QR o Bluetooth para los asistentes" tiene una prioridad menor y lo corregimos en la planificación.
- Retroalimentacion recibida en cada issue
- Todos los issues completados y cerrados
- Proporcionar retroalimentación en los issues abiertos
- Cerrar los issues que se han asignado cuando el responsable termine la asignación
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- ARTURO AVILÉS MORILLAS ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
- JOSÉ JAVIER BOGADO CANDIA ✔
Fecha 15/11/2023
Duracion: 1h 20 mins
Important
- Error en el calendario
- Error en los pull request y los merge
- Error en los modulos de las iteraciones
- Corregir el apartado de branching de la wiki
- Crear rama especifica de documentacion
- Fallo en las issues de la iteracion 2
- Añadir fichero general de configuracion de versionado
- Detectamos un error en el calendario debido a un desfase de los dias seleccionados para las diferentes tareas, se debera volver a ajustar.
- Detectamos otro error en los pull request y los merge debido a que los estaba creando y aceptando otro miembro que no era el director del proyecto.
- Detectamos otro error en los modulos de las diferentes iteraciones ya que deben incluirse en un POM Gestion de configuracion v2.0.
- Se debe corregir la estructura de ramas del repositorio para que concuerden con lo acordado.
- Debemos hacer una rama para incluir la documentacion (actualmente esta donde el codigo, en el main y son principalmente capturas de pantalla).
- Detectamos un fallo en la iteración 2 en las issues de análisis y de requisitos, se decide no vincular ninguna rama con las issues.
- Se debe añadir el fichero general de configuarion de versionado, actualmente no existe ningun fichero de configuracion de versiones.
- Retroalimentacion recibida en cada issue
- Todos los issues completados y cerrados
- Terminada iteración 3
- Solucionado error de la prioridad
- Proporcionar retroalimentación en los issues abiertos
- Cerrar los issues que se han asignado cuando el responsable termine la asignación
- Crear el listado de versiones dentro de gestión de la configuración
- Incluir extractos de las reuniones a partir del word compartido
- Solucionar error de calendario
- corregir apartado branching
- Incluir archivos POM
- Crear rama para incluir la documentación
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
Sesion de control del 21/11/2023 Aspectos a tener en cuenta o corregir:
- Debemos diferenciar los diferentes sistemas en diferentes ramas con cada modulo
- Incluir versiones de cada modulo para identificar la fase en la que se encuentra
- En la parte del codigo añadir un nombre mas identificativo para tener mas trazabilidad en las carpetas de las iteraciones
- Añadir la diferenciación de los sistemas en los diagramas de casos de uso
- Generar la documentación a partir de visual paradigm en html
Fecha 22/11/2023
Duracion: 1h 30 mins
Important
- Se debate forma para diferenciar los sistemas en la parte del codigo
- Se vuelve a plantear la manera de disposicion de las ramas del proyecto
- Se reestructuran las versiones separandolas para cada modulo
- Se deben modificar algunos diagramas de la wiki
- Se realiza prueba para la generacion de documentacion
- Se acuerda separar por ramas cada uno de los diferentes modulos incluyendo su version actual Gestion de configuracion v2.0.
- Se plantea realizar comits en cada una de las ramas de los modulos en lugar de hacer una rama por iteracion.
- Se estructuran las versiones por modulo y se cuadran para cada una de las iteraciones futuras.
- Detectados pequeños errores en los diagramas de casos de uso que se corregiran (delimitacion del sistema).
- Se realiza una prueba para la generacion de documentacion, ya sea pdf o html, a partir de visual paradigm usando los diagramas creados en la iteracion que se encuentre.
- Creado el listado de todas las versiones
- Incluidos los extractos de las reuniones
- Solucionado error de calendario
- Retroalimentacion recibida en cada issue
- Cerrados Issues de proposito general abiertos en la sesion anterior
- Corregidas las diferentes ramas del proyecto actualizadas por sistemas
- Archivos POM incluidos
- Rama de documentacion añadida
- Incluir la version de cada modulo en su correspondiente rama
- Corregir diagramas de casos de uso
- Generar documentacion a partir de visual paradigm
- Cambio en las ramas de cada iteracion
- Cambiar listado de versiones
No se abren issues en la reunión
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- ARTURO AVILÉS MORILLAS ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
Fecha 29/11/2023
Duracion: 1h 30 mins
Important
- Cambio de la planificacion por desfase
- Se debe cambiar la planificacion generando una nueva version de la planificacion que se adapte a la nueva gestion de modulos por el listado de versionado y tenga coherencia con el calendario y con el tiempo estimado: planificacion V2.0
- Incluida la version de cada modulo en su correspondiente rama
- Diagramas de casos de uso corregidos
- La documentacion se empieza a generar a partir de visual paradigm
- Cambiadas las ramas para diferenciarlas por modulos
- Listado de versiones actualizado
- Añadir nueva pagina con la actualizacion de la planificacion
- Proporcionar retroalimentacion en los issues abiertos
- Cerrar issues cuando se completen
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
- JOSÉ JAVIER BOGADO CANDIA ✔
Fecha 06/12/2023
Duracion: 2h
Important
- Comenzamos parte de testing
- Organizamos fechas y grupos para la parte de testing
- Detectamos que se debe reajustar el presupuesto
- Se deben revisar las ramas en visual paradigm debido a un error
- Se comprueba it 4
- Se deben corregir algunos detalles de diagramas
- Se debe modificar la gestion de cambios
- Se linkean la gestion de configuracion con las reuniones en las que se decidio modificar
- Comenzamos la parte de testing a partir de los enunciados proporcionados en teoria.
- Se forman las parejas para trabajar en testing y se acuerda como rotaremos para generar codigo/crear los casos de prueba/ejecutar los casos de prueba.
- Detectamos que se debe ajustar el presupuesto para mayor coherencia con el calendario.
- Se debe solucionar un error producido en la rama de servidor de visual paradigm.
- Comprobamos que la cuarta iteracion se ha hecho de manera correcta (uploads, commits, etc).
- Se corrigen relaciones en los diagramas de la rama servidor en la ultima iteracion.
- Se debe modificar la gestion de cambios de manera que quede actualizada.
- En el apartado de gestion de cambios dentro de la gestion de configuracion se linkean en cada cambio registrado las reuniones en las que se decidio realizar ese cambio.
- Añadida pagina en la wiki con la nueva planificacion
- Retroalimentacion recibida en los issues abiertos
- Issues cerrados como completados
- Comprobada iteracion 4 (se acuerda y se revisa en la misma reunion)
- Se decide abrir los issues una vez se termine la iteracion anterior
- Terminar la codificacion de la parte de testing
- Reajustar presupuesto
- Corregir diagramas server
- Actualizar y enlazar gestion de cambios
- Proporcionar retroalimentacion en los issues abiertos
- Cerrar issues cuando se completen
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- ARTURO AVILÉS MORILLAS ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- JOSÉ JAVIER BOGADO CANDIA ✔
Fecha 14/12/2023
Duracion: 2h
Important
- Añadida pagina para la valoracion personal y grupal del trabajo
- Empezar a desarrollar los casos de prueba de la parte de testing
- Terminar parte de testing
- Incluir tabla workflow
- Fechas release
- Se debe añadir la pagina para la valoracion y modificarla por cada uno de los integrantes del grupo de manera que todos incluyan su valoracion.
- Una vez hecha la codificacion de los casos de prueba se rota para hacer los casos de prueba de otro problema que pertenezca a otra pareja.
- Incluir en los repositorios de testing la ejecucion de los casos de pruebas que se generen.
- Se debe añadir una tabla de flujo de trabajo en el apartado de Autoevaluación que incluya al menos las columnas: iteración, componente, versión, clase o clases, versión de clase, requisitos funcionales y dependencias.
- Se decide que las fechas de las releases sean el 20, 21 y 22. Aun sabiendo que en la planificación estan mucho mas atrasadas debido a que se tendrian que realizar cuando se hayan completado todas iteraciones, pero de todas maneras se adelantan ya que la entrega del trabajo es el dia 22 y es necesario que el proyecto incluya las releases (también estamos teniendo en cuenta que no es necesario completar todas las iteraciones). En conclusion, sabemos que no se deberían adelantar las releases antes de terminar las iteraciones pero por un tema de tiempo y de estructuración del trabajo tomamos la decisión de adelantarlas.
- Issues de la iteracion 5 abiertos en 12/12/23
- Codificacion de la parte de testing terminada
- Presupuesto ajustado
- Diagramas del servidor corregidos
- Gestion de cambios completa y actualizada
- Retroalimentacion recibida en los issues abiertos (solo requisitos y analisis)
- Issues cerrados como completados (solo requisitos y analisis)
- Añadir valoracion personal
- Determinar casos de prueba correspondientes
- Incluir en los repositorios especificos la ejecucion de los diferentes casos de pruebas
- Generar las diferentes releases
- Incluir tabla de flujo de trabajo en el apartartado de autoevaluación
- DAVID CARROBLES ILLÁN ✔
- GEORGI ANGELOV CHERVENYASHKI ✔
- JESÚS DÍAZ-TOLEDO CRIADO ✔
- ARTURO AVILÉS MORILLAS ✔
- IVÁN JIMÉNEZ QUINTANA ✔
- RUBEN ROMERO FERNANDEZ MONGE ✔
- JOSÉ JAVIER BOGADO CANDIA ✔