Merge pull request #626 from Black-Dot-2024/develop

Develop

docs/checklist/chk-dgt-005.md

@@ -22,7 +22,7 @@ Garantizar la calidad y estandarización de los Pull Request
 
 - [ ] **Estándar de Pull Request**
 
-  El Pull Request cumple con el [estándar de Pull Request](../estandares/est-dgt-008/est-dgt-008.md) definido por el equipo.
+  El Pull Request cumple con el [estándar de Pull Request](../estandares/est-dgt-008.md) definido por el equipo.
 
 - [ ] **Estándares de código**
 

docs/checklist/chk-dgt-010.md

@@ -20,20 +20,20 @@ La fase de desarrollo es crucial en la creación de software. Es en esta etapa d
 - [ ] Se tiene una rama con la versión más reciente de `origin develop` en la que se trabajó la fase de desarrollo
 - [ ] El código está documentado de acuerdo al <u>[EST-DGT-002 Estándar para Comentarios de Código con Doxygen](../estandares/est-dgt-002.md)</u>
 - [ ] El código está probado, de acuerdo a las guías y pruebas establecidas en los documentos:
-    * <u>[Plan de Pruebas](../zeitgeist/pruebas/plan-de-pruebas.md)</u>
-    * <u>[GUI-DGT-008 Guía de pruebas unitarias en TypeScript](../guias/gui-dgt-008.md)</u>
-    * <u>[GUI-GDT-007 Pruebas con Postman](../guias/gui-dgt-007.md)</u>
+  - <u>[Plan de Pruebas](../zeitgeist/pruebas/plan-de-pruebas.md)</u>
+  - <u>[GUI-DGT-008 Guía de pruebas unitarias en TypeScript](../guias/gui-dgt-008.md)</u>
+  - <u>[GUI-GDT-007 Pruebas con Postman](../guias/gui-dgt-007.md)</u>
 - [ ] Los commits realizados en la rama siguen el <u>[EST-BDT-007 Estándar para commits de código](../estandares/est-bdt-007.md)</u>
-_ [ ] Se tiene o ya está 'mergeado' un PR en el repositorio correspondiente, que sigue el <u>[EST-DGT-006 Envío de Pull Requests DotGeist](../estandares/est-dgt-008/est-dgt-008.md)</u>
+      \_ [ ] Se tiene o ya está 'mergeado' un PR en el repositorio correspondiente, que sigue el <u>[EST-DGT-006 Envío de Pull Requests DotGeist](../estandares/est-dgt-008.md)</u>
 - [ ] En caso de haber encontrado defectos en esta fase, están registrados en los defect logs:
-    * <u>[Defect Log BackEnd](https://github.com/orgs/Black-Dot-2024/projects/5/views/1)</u>
-    * <u>[Defect Log FrontEnd](https://github.com/orgs/Black-Dot-2024/projects/7/views/1)</u>
+  - <u>[Defect Log BackEnd](https://github.com/orgs/Black-Dot-2024/projects/5/views/1)</u>
+  - <u>[Defect Log FrontEnd](https://github.com/orgs/Black-Dot-2024/projects/7/views/1)</u>
 - [ ] El tiempo utilizado para esta fase está documentada en el <u>[PVG Zeitgeist](https://docs.google.com/spreadsheets/d/1mFO9Bb7gJysk4sDaJ2z7ufl0epSR40XKp3J-r4IxFVc/edit#gid=1369995251)</u>
 
 Es fundamental que el desarrollo sea exhaustivamente evaluado y validado para garantizar que cumpla con las expectativas y necesidades de los interesados. Al seguir estos criterios, aseguramos que el desarrollo de requerimientos sea robusto, comprensible y adaptable, formando las bases para una implementación exitosa y una solución de calidad.
 
 ## Control de Cambios
 
-| Versión | Cambio realizado              | Análisis                                                                                           | Autor           | Revisor(es)    | Fecha de Cambio |
-| ------- | ----------------------------- | -------------------------------------------------------------------------------------------------- | --------------- | -------------- | --------------- |
-| v 1.0   | Creación de la checklist      | N/A                                                                                                | Ian Padrón      | -              | 22/05/2024      |
+| Versión | Cambio realizado         | Análisis | Autor      | Revisor(es) | Fecha de Cambio |
+| ------- | ------------------------ | -------- | ---------- | ----------- | --------------- |
+| v 1.0   | Creación de la checklist | N/A      | Ian Padrón | -           | 22/05/2024      |

docs/guias/gui-bdt-019.md

@@ -5,7 +5,7 @@ sidebar_position: 19
 
 # GUI-BDT-019 Llenado de log de problemas/retroalimentación
 
-v 2.0
+v 3.0
 
 ## Objetivo
 
@@ -90,11 +90,10 @@ Para las retroalimentaciones, se debe llenar la hoja que se encuentra en el PVG
 
 La guía nos asegura un seguimiento adecuado a la retroalimentación de los profesores mediante un log estandarizado que documenta detalladamente cada problema, asigna responsabilidades específicas, define planes de acción y verifica la resolución. Esto garantiza una gestión proactiva, responsable y eficiente, promoviendo la mejora continua del proyecto.
 
-
 ## Control de cambios
 
-| Versión | Cambio realizado                                                     | Análisis | Autor          | Revisor(es)   | Fecha de cambio |
-| ------- | -------------------------------------------------------------------- | -------- | -------------- | ------------- | --------------- |
-| v 1.0   | Creación de la guía                                                  | N/A      | Mafer Moreno   | Diego Perdomo | 11/05/2024      |
-| v 2.0   | Se actualizan las tablas de métricas para la evaluación del problema | N/A      | Olimpia Garcia | Mafer Moreno  | 16/05/2024      |
-| v 3.0 | Se añade la sección de retroalimentación asi como la referencia al PVG para el seguimiento. | N/A | Mike Tena |  | 23/05/2024 |
+| Versión | Cambio realizado                                                                            | Análisis | Autor          | Revisor(es)   | Fecha de cambio |
+| ------- | ------------------------------------------------------------------------------------------- | -------- | -------------- | ------------- | --------------- |
+| v 1.0   | Creación de la guía                                                                         | N/A      | Mafer Moreno   | Diego Perdomo | 11/05/2024      |
+| v 2.0   | Se actualizan las tablas de métricas para la evaluación del problema                        | N/A      | Olimpia Garcia | Mafer Moreno  | 16/05/2024      |
+| v 3.0   | Se añade la sección de retroalimentación asi como la referencia al PVG para el seguimiento. | N/A      | Mike Tena      |               | 23/05/2024      |

docs/guias/gui-bdt-024.md

@@ -21,11 +21,10 @@ El WBS es una herramienta que se utiliza para descomponer un proyecto en partes
 
 1. Definir el alcance del proyecto.
 2. Identificar las fases principales del desarrollo de un requerimiento. <br/>
-2.1 Definir las tareas principales de cada fase. Tomando n cuenta los recursos y tiempo que se tienen disponibles.<br/>
+   2.1 Definir las tareas principales de cada fase. Tomando n cuenta los recursos y tiempo que se tienen disponibles.<br/>
 3. Definir en cada fase las tareas más pequeñas a realizar.<br/>
-3.1 Dividir las tareas principales en tareas más pequeñas.<br/>
-3.2 Plasmar estas tareas en cada fase.
-
+   3.1 Dividir las tareas principales en tareas más pequeñas.<br/>
+   3.2 Plasmar estas tareas en cada fase.
 
 ### Ejemplo de WBS
 
@@ -52,6 +51,6 @@ Proyecto de desarrollo de software
 
 ## Control de cambios
 
-| Versión | Cambio realizado              | Análisis                                                                                                                                                          | Autor       | Revisor(es)    | Fecha de cambio |
-| ------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | -------------- | --------------- |
-| v 1.0   | Creación de guía         | Se creo debido a                                                                                                                                                                | Ricardo Rosales | Alejandra Cabrera | 29/05/2024      |
+| Versión | Cambio realizado | Análisis                                                                 | Autor           | Revisor(es)       | Fecha de cambio |
+| ------- | ---------------- | ------------------------------------------------------------------------ | --------------- | ----------------- | --------------- |
+| v 1.0   | Creación de guía | Se creo debido a la necesidad de estandarizar el proceso de hacer un WBS | Ricardo Rosales | Alejandra Cabrera | 29/05/2024      |

docs/guias/gui-dgt-009.md

@@ -25,7 +25,7 @@ El objetivo de esta guía es proporcionar una ayuda y criterios para poder despl
 
 ### 2. Pull Request
 
-- Abrir un Pull Request de la rama `staging` a la rama `main` siguiendo el estándar <u>[EST-DGT-006 Envío de Pull Requests DotGeist](../estandares/est-dgt-008/est-dgt-008.md)</u>.
+- Abrir un Pull Request de la rama `staging` a la rama `main` siguiendo el estándar <u>[EST-DGT-006 Envío de Pull Requests DotGeist](../estandares/est-dgt-008.md)</u>.
 - Revisar el Pull Request utilizando la <u>[CHK-DGT-005 Revisión de Pull Request](../checklist/chk-dgt-005.md)</u>.
 - En caso de encontrar defectos registrarlos en el <u>[Defect Log Frontend](https://github.com/orgs/Black-Dot-2024/projects/7)</u> y solucionarlos hasta que el número de defectos sea 0.
 

docs/guias/gui-tdt-003.md

@@ -5,7 +5,7 @@ sidebar_position: 37
 
 # GUI-TDT-003 Configuración de Odoo
 
-v 2.0
+v 2.1
 
 ## Objetivo
 

docs/guias/gui-tdt-006.md

@@ -1,6 +1,6 @@
 ---
 #Este número indica la posición de este documento en su respectiva carpeta de la sidebar. Favor de actualizarlo de acuerdo al número del identificador que pondrás en el nombre del archivo/título del mismo.
-sidebar_position: 36
+sidebar_position: 40
 ---
 
 # GUI-TDT-006 Guía para detección de defectos de Odoo

docs/manuales/man-bdt-001.md → docs/manuales/deprecated/man-bdt-001.md

@@ -3,9 +3,9 @@
 sidebar_position: 1
 ---
 
-# MAN-BDT-001 Diseño de requisitos del sistema
+# [DEPRECATED] MAN-BDT-001 Diseño de requisitos del sistema
 
-v 2.3
+v 3.0
 
 ## Objetivo
 
@@ -47,3 +47,4 @@ Este manual nos ayudara a comprender las diferentes herramientas con las que con
 | v 2.1   | Actualizar Versión      | N/A                                         | Carlos Velasco                                                                            | David Langarica | 30/04/2024      |
 | v 2.2   | Cambio a link relativo  | Los links relativos avisan si se rompen     | Ricardo Fernández                                                                         |                 | 1/05/2024       |
 | v 2.3   | Arreglar estructura     | El control de cambios se rompe & ortografía | Diego Vega                                                                                |                 | 1/05/2024       |
+| V 3.0   | Se depreca el manual       | El proceso en el que se utilizaba fue deprecado y quedó irrelevante                                                     | Daniel Cajas                                      | Damariz Licea | 07/06/2024      |

docs/manuales/man-bdt-002.md → docs/manuales/deprecated/man-bdt-002.md

@@ -3,9 +3,9 @@
 sidebar_position: 2
 ---
 
-# MAN-BDT-002 Consideraciones para Diseñar un Requerimiento
+# [DEPRECATED] MAN-BDT-002 Consideraciones para Diseñar un Requerimiento
 
-v 2.0
+v 3.0
 
 ## Objetivo
 
@@ -49,3 +49,4 @@ Hacer un diagrama facilitará los siguientes aspectos:
 | ------- | ------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | --------------- |
 | v 1.0   | Creación del manual | N/A                                                                                                              | Uri Gopar <br /> Mafer Moreno <br /> Ricardo Rosales | Ian Padrón <br /> Armando Rosas <br /> Ramona Nájera | 02/03/2024      |
 | v 2.0   | Ajuste de formato   | Se modificó el contenido del manual de acuerdo a la plantilla porque el documento tenía información no requerida | Yuna Chung                                           | Ricardo Fernández                                    | 24/04/2024      |
+| V 3.0   | Se depreca el manual       | El manual en el que se utilizaba fue deprecado y quedó irrelevante                                                     | Daniel Cajas                                      | Damariz Licea | 07/06/2024      |

docs/nosotros/compromisos.md

@@ -76,3 +76,6 @@ En caso de que un miembro del departamento necesite ayuda, se compromete a asist
 #### **Consecuencias de incumplimiento**
 
 1. Se notificará al Team Leader.
+
+## Nota:
+Con la creación de la [POL-BDT-005](../politicas/pol-bdt-005.md) se actualizaron los compromisos el día 26/05/2024

docs/nosotros/mision-vision-valores.md

@@ -20,9 +20,7 @@ Ser líderes en la creación de software que transforme vidas, impulsando el pro
 
 **💡 Emblema (Objetivo 1):** "Alcanzar el nivel 2.6 del CMMI en el semestre."
 
-2. Buscar el crecimiento de las habilidades de todos los miembros del equipo de desarrollo del departamento Black Dot antes del 15 de junio de 2024 sin sacrificar la salud física o mental. Mediante el uso de herramientas como Hapiness Door y Retrospectivas para llevar un registro del estado anímico del equipo. Y el seguimiento de horas donde cada miembro del equipo trabajó al menos el 90% de las horas acordadas, y no más del 110% de las mismas.
-
-**💡 Emblema (Objetivo 2):** "Incrementar la motivación del equipo durante el semestre."
+2. Para el 17 de junio de 2024, cada integrante de BlackDot habrá subido al menos un nivel en cada habilidad definida del curso, registrando su mejora en el log de aprendizaje.
 
 ## Valores
 

docs/nosotros/objetivos-lideres.md

@@ -20,6 +20,14 @@ Poder identificar un logro de los integrantes del departamentoa través del log
 
 Mejorar la comunicación y cooperación entre los integrantes del departamento para el 8 de mayo del 2024. Se busca que a través de una encuesta que todos los miembros del departamento consideren que conocen la información del departamento en mínimo un 9 en una escala del 1 al 10 y que no se hayan suscitado problemas de organización durante la última semana.
 
+### _Denisse Domínguez_
+
+Mi objetivo es que el 7 de junio de 2024, mediante la asignación de tareas especificas planificadas en el PVG departamental y no mediante la asignación voluntaria, el 50% del total de integrantes de BlackDot estará trabajando de manera comprometida en el logro del objetivo 1, que hace referencia a alcanzar el nivel 2.6 del CMMI
+
+### _Alejandra Cabrera_
+
+Mi objetivo como PM es que todos los miembros del departamento sean capaces de saber el estado del proyecto departamental como lo pueden hacer con los proyectos de desarrollo, logrando así contestar las seis preguntas del departamento en el reporte de estado. También busco informarme del estado de los proyectos, lograr la colaboración entre ambos equipos y velar por el término exitoso de ambos hasta el día de la presentación final. 
+
 ## Team Lead
 
 ### _Rodrigo Terán_
@@ -55,6 +63,10 @@ Mi objetivo como uno de los TLs de BlackDot es lograr que el equipo de CR Organi
 Mi objetivo como líder de equipo de TalentDot es mejorar la confianza y el ambiente dentro de nuestro equipo para el 8 de mayo de 2024. Esto se traduce en crear un entorno donde todos los miembros se sientan valorados, seguros para expresar sus opiniones y capaces de pedir ayuda sin temor a ser juzgados. El propósito de esta iniciativa es reflejar la participación activa de nuestros miembros en la calidad de nuestros productos de trabajo.
 El criterio de alcance de este objetivo es que el ambiente de trabajo obtenga 39 puntos en dos encuestas sucesivas
 
+### _María Fernanda Moreno_
+
+Mi objetivo es asegurarme que los miembros de Talent Dot se sientan escuchados y apoyados emocionalmente. Cada semana, tras la aplicación del RULER, me reuniré individualmente con aquellos identificados en los cuadrantes rojo y azul para abordar sus necesidades. Utilizaré encuestas de satisfacción para medir el cumplimiento de mi objetivo, donde se evaluará si los miembros han sentido cambios a favor de mejorar su estado de ánimo. Esto será para el 12 de junio.
+
 ## Product Owner
 
 ### _Ricardo Fernández_
@@ -71,6 +83,15 @@ Mi objetivo es mantener una comunicación clara y continua con las socias para c
 
 Mi objetivo principal como PO es poder establecer la mejor comunicación de mi equipo con los socios, por lo que este objetivo se describe terminando de establecer requerimientos tanto funcionales como no funcionales y que sean validados por el cliente e integrantes del equipo para la semana 3 y tener el backlog de trabajo priorizado para semana 5.
 
+### _Uri Gopar_
+
+Mi objetivo es mejorar mi comunicación asertiva con el socio formador de CR Organizacional para fortalecer nuestro compromiso y crear un ambiente de honestidad, respeto y transparencia. Por medio de juntas semanales los días martes a las 10 a.m, fometando las comunicación de ambas partes.
+Lograré este objetivo en un plazo de 5 semanas, iniciando el 1 de abril y finalizando el 5 de mayo, con el producto final de MVP el cual le generara valor al socio fomrador.
+
+### _Diego Vega_
+
+Mantener una comunicación efectiva con el socio mediante reuniones semanales de actualización, validar el trabajo realizado en cada reunión, y comunicar el estado del proyecto y los cambios generados. Además, organizar y mantener documentación detallada y actualizada. Finalmente, concluir y entregar un producto funcional al socio y validarlo con el mismo antes del 7 de junio de 2024.
+
 ## Architecture Owner
 
 ### _Carlos Salguero_
@@ -85,4 +106,12 @@ Incrementar un 30% las habilidades de Despliegue y competencias en comandos avan
 
 Mi objetivo como uno de los AO de BlackDot, trabajando en el proyecto de CR - Organizacional es definir un stack de tecnologías que balanceé las necesidades de los socios y las habilidades, fortalezas y debilidades del equipo. También asegurarse de que el equipo se encuentre capacitado o con un plan de capacitación para que todos los miembros del equipo puedan trabajar eficientemente en el proyecto.
 
+### _Arturo Díaz_
+
+Mi objetivo como AO es que todo trabajo realizado por el equipo de desarrollo DotGeist deberá apegarse a un proceso correctamente definido y documentado, de tal manera que se asegure que las prácticas comunes del equipo sean repetibles y consistentes, y que los productos de trabajo cumplan con los requisitos establecidos y satisfagan las expectativas de los interesados.
+
+### _Ricardo Rosales_
+
+Aumentar el yield de defectos de las fases de analisis, diseño y desarrollo, un 15% para el 11 de junio.
+
 ---