Develop

docs/checklist/CHK-BDT-001.md

@@ -7,7 +7,7 @@ sidebar_position: 1
 
 v 1.0
 
-## Resumen
+## Propósito
 
 Este checklist de Contenido de Reporte de Estado proporciona una guía estructurada para garantizar la calidad y el contenido del la presentación del Reporte de Estado
 

docs/checklist/CHK-BDT-002.md

@@ -1,59 +1,36 @@
 ---
+#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: 2
 ---
 
-### CHK-BDT-002 Checklist de Revisión de Código
+# CHK-BDT-002 Checklist de Creación de Procesos
 
-#### Organización de Archivos
+v 1.0
 
-- [ ] Confirmar que los archivos están organizados en las carpetas correctas según su tipo y función dentro del proyecto.
-- [ ] Asegurarse de que todos los archivos necesarios están incluidos y que no hay archivos obsoletos o sin utilizar.
+## Propósto
 
-**Enlaces a los estándares de nomenclatura de archivos:**
+La checklist de procesos tiene como objetivo describir los criterios de aceptación de un proceso, asegurando que aporte valor y siga los lineamientos de nuestros procesos departamentales.
 
-- [Estandar para nombrar archivos](https://black-dot-2024.github.io/docs/estandares/est-bdt-009)
-- [Documento donde se explica la estructura de los archivos](https://docs.google.com/document/d/1iwTGu-eL6Lcx2_N8lxLuYtCtFQs3rUThMujLJHEizo0/edit)
+## Notas introductorias
 
-#### Uso de Funciones y Modularización
+La creación de un nuevo proceso debe pasar completamente por la siguiente lista de verificación, asegurando que cumpla con los lineamientos del departamento.
 
-- [ ] Comprobar que todas las funciones están bien documentadas, incluyendo descripciones claras en los comentarios y, si es aplicable, documentación generada con herramientas como Doxygen. [EST-BDT-010](https://black-dot-2024.github.io/docs/estandares/est-bdt-010)
-- [ ] Confirmar que las implementaciones de interfaces y módulos están completas, claras y siguen los principios de diseño limpio.
+## Criterios de Aceptación
 
-#### Seguridad y Configuración
+- [ ] Se creó siguiendo el [PRO-BDT-001 Creación de Procesos](../procesos/pro-bdt-001.md)
+- [ ] Resuelve una necesidad
+- [ ] Es relevante con la forma de trabajo
+- [ ] Aporta valor a la forma de trabajo
+- [ ] No existe otro proceso que sustente la misma necesidad
+- [ ] Los enlaces de referencia son correctos y relevantes
+- [ ] Los pasos del proceso son concisos, claros y completos
+- [ ] Los nombres de fases son claros, concisos y fácil de entender
+- [ ] En caso de ser necesario, se incluyen guías o estándares relevantes
+- [ ] Está libre de faltas de ortografía
 
-- [ ] Verificar que no se revela información confidencial en el código, como claves API, URLs de bases de datos, etc..
-- [ ] Asegurarse de que todas las claves secretas y configuraciones sensibles están en variables de entorno y no están codificadas directamente en el código fuente.
+## Control de Cambios
 
-#### Nomenclatura
-
-- [ ] Revisar que todos los nombres (funciones, variables, archivos) están en inglés y siguen las convenciones de nomenclatura establecidas en los estándares de codificación del equipo.
-
-**Enlaces a los estándares de codificación:**
-<!-- [Backend]()
-[Frontend]() -->
-
-- [ ] Comprobar que los nombres de tablas y campos de base de datos están en snake_case y son descriptivos.
-
-#### Estándares y Prácticas
-
-- [ ] Confirmar que no hay errores de linting reportados por herramientas como ESLint.
-- [ ] Verificar que no hay variables, funciones o módulos importados sin utilizar, asegurando un código limpio y eficiente.
-
-#### Manejo de Errores
-
-- [ ] Verificar que los errores en funciones asíncronas están adecuadamente manejados y que se utilizan promesas o async/await correctamente.
-
-#### Formato de Código
-
-- [ ] Confirmar que el código está formateado de acuerdo a la configuración de Prettier.
-- [ ] Asegurarse de que el código sigue los principios de programación como DRY (Don't Repeat Yourself) y KISS (Keep It Simple, Stupid).
-
-#### Pruebas Unitarias
-
-- [ ] Comprobar que todas las nuevas funciones o módulos están acompañados de pruebas unitarias y/o de integración.
-- [ ] Verificar que la cobertura de pruebas no disminuye con la incorporación del nuevo código.
-
-| Versión | Cambio                                    | Autor del cambio | Revisado por | Fecha de cambio |
-| ------- | ----------------------------------------- | ---------------- | ------------ | --------------- |
-| v 1.0   | Creación de la checklist                  | Sergio Garnica   |              | 18/04/2024      |
-| v 2.0   | Refactorización de items y añadir enlaces | Daniel Hurtado   |              | 22/04/2024      |
+| Versión | Cambio realizado            | Análisis                                                                                                      | Autor             | Revisor(es)       | Fecha de Cambio |
+| ------- | --------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------- | ----------------- | --------------- |
+| v 1.0   | Creación del checklist      | N/A                                                                                                           | Denisse Domínguez | Yuna Chung        | 20/04/2024      |
+| v 2.0   | Eliminación de involucrados | Como es un checklist que puede usar cualquier persona del departamento, la sección de involucrados se eliminó | Yuna Chung        | Ricardo Fernández | 22/04/2024      |

docs/checklist/CHK-ZGT-001.md

@@ -7,7 +7,7 @@ sidebar_position: 3
 
 v 1.0
 
-## Resumen
+## Propósito
 
 Este checklist de UXUI proporciona una guía estsructurada para evaluara y garantizar la calidad y coherencia en el proceso de diseño de una vista dentro del departamento.
 

docs/checklist/CHK-ZGT-002.md

@@ -0,0 +1,72 @@
+---
+#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: 3
+---
+
+# CHK-ZGT-002 Checklist de Revisión de Código
+
+v 1.0
+
+## Propósito
+
+Este es un checklist creado con el fin de revisar el código para que todos los códigos que estamos escribiendo como equipo de desarrollo del proyecto LinkBridge tenga un estándar y no tenga errores
+
+## Criterios de Aceptación
+
+### Organización de Archivos
+
+- [ ] Confirmar que los archivos están organizados en las carpetas correctas según su tipo y función dentro del proyecto.
+- [ ] Asegurarse de que todos los archivos necesarios están incluidos y que no hay archivos obsoletos o sin utilizar.
+
+**Enlaces a los estándares de nomenclatura de archivos:**
+
+- [Estandar para nombrar archivos](https://black-dot-2024.github.io/docs/estandares/est-bdt-009)
+- [Documento donde se explica la estructura de los archivos](https://docs.google.com/document/d/1iwTGu-eL6Lcx2_N8lxLuYtCtFQs3rUThMujLJHEizo0/edit)
+
+### Uso de Funciones y Modularización
+
+- [ ] Comprobar que todas las funciones están bien documentadas, incluyendo descripciones claras en los comentarios y, si es aplicable, documentación generada con herramientas como Doxygen. [EST-BDT-010](https://black-dot-2024.github.io/docs/estandares/est-bdt-010)
+- [ ] Confirmar que las implementaciones de interfaces y módulos están completas, claras y siguen los principios de diseño limpio.
+
+### Seguridad y Configuración
+
+- [ ] Verificar que no se revela información confidencial en el código, como claves API, URLs de bases de datos, etc..
+- [ ] Asegurarse de que todas las claves secretas y configuraciones sensibles están en variables de entorno y no están codificadas directamente en el código fuente.
+
+### Nomenclatura
+
+- [ ] Revisar que todos los nombres (funciones, variables, archivos) están en inglés y siguen las convenciones de nomenclatura establecidas en los estándares de codificación del equipo.
+
+**Enlaces a los estándares de codificación:**
+
+<!-- [Backend]()
+[Frontend]() -->
+
+- [ ] Comprobar que los nombres de tablas y campos de base de datos están en snake_case y son descriptivos.
+
+### Estándares y Prácticas
+
+- [ ] Confirmar que no hay errores de linting reportados por herramientas como ESLint.
+- [ ] Verificar que no hay variables, funciones o módulos importados sin utilizar, asegurando un código limpio y eficiente.
+
+### Manejo de Errores
+
+- [ ] Verificar que los errores en funciones asíncronas están adecuadamente manejados y que se utilizan promesas o async/await correctamente.
+
+### Formato de Código
+
+- [ ] Confirmar que el código está formateado de acuerdo a la configuración de Prettier.
+- [ ] Asegurarse de que el código sigue los principios de programación como DRY (Don't Repeat Yourself) y KISS (Keep It Simple, Stupid).
+
+### Pruebas Unitarias
+
+- [ ] Comprobar que todas las nuevas funciones o módulos están acompañados de pruebas unitarias y/o de integración.
+- [ ] Verificar que la cobertura de pruebas no disminuye con la incorporación del nuevo código.
+
+## 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                                                                                                                                                                  | Sergio Garnica | Olimpia García        | 18/04/2024      |
+| v 2.0   | Agregar resumen de checklist              | Para que se pueda entender mejor qué podemos lograr con este checklist, se agregó el resumen                                                                         | Yuna Chung     | Sergio Garnica        | 22/04/2024      |
+| v 3.0   | Refactorización de items y añadir enlaces | Algunos criterios de aceptación estaban muy ambiguos, entonces para que sea más fácil de revisar y verificar, los ítems se refactorizaron y se añadieron los enlaces | Daniel Hurtado | Yuna Chung 22/04/2024 |

docs/comunicacion/comunicacion-cr.md

@@ -0,0 +1,34 @@
+# Plan de comunicación con CR Organizacional
+
+## Objetivo
+
+Mantener una comunicación continua, respetuosa y efectiva con los socios formadores representantes de CR Organizacional.
+
+## Comunicación responsable
+
+En nuestro departamento, reconocemos la importancia de una comunicación responsable y respetuosa con nuestros profesores. Es fundamental que se sigan los [valores](https://github.com/Black-Dot-2024/docs/wiki/Misión,-Visión,-Valores-y-Objetivos:) y el [Código de ética](www.blackdot/codigoEtica) del departamento.
+
+## Medios
+
+El canal de comunicación principal será el grupo de WhatsApp de CR Organizacional, donde se encuentran tanto los socios formadores como los representantes de Black Dot (Team Leader, Architecture Owner y Product Owner). Aquí, organizamos las reuniones.
+
+El canal de comunicación secundario será el correo electrónico para comunicaciones formales y para enviar documentos importantes.
+
+
+Para las comunicaciones formales, utilizaremos la [plantilla de comunicación](https://docs.google.com/document/d/1eO7YG_qw98ETbj0fJPgfsT9RfVy2-64SvPJLLYbAQnA/edit?usp=sharing). Esta plantilla está membretada con los colores del equipo (Blue Dot), e incluye el logo de Black Dot y el logo del Tecnológico de Monterrey.
+
+## Reuniones
+
+Tendremos reuniones presenciales con los socios formadores y los representantes de Black Dot para validar avances y tomar decisiones importantes los días martes a las 9am todas las semanas.
+
+
+## Control de cambios
+
+| Versión | Cambio                                                                                             | Autor del cambio | Aprobado por    | Fecha de cambio |
+| ------- | -------------------------------------------------------------------------------------------------- | ---------------- | --------------- | --------------- |
+| v 1.0   | Creación del plan                                                                                  | Diego Sandoval   | David Langarica | 29/02/2024      |
+| v 2.0   | <ul> <li>Actualización de versionamiento.</li> <li>Revisión y corrección de ortografía.</li> </ul> | David Langarica  |                 | 03/03/2024      |
+| v 3.0   | <ul> <li>Actualización de medios.</li> <li>Revisión y corrección de ortografía.</li> </ul>         | Mike Tena        | David Langarica | 04/03/2024      |
+| v 3.1   | Revisión y corrección de ortografía                                                                | Mike Tena        | David Langarica | 04/03/2024      |
+| v 4.0   | Reestructuracion del plan de comunicación                                                          | Mike Tena        |        ?         | 08/03/2024      |
+

docs/cr/Análisis/impact_mapping_cr.md

@@ -2,7 +2,7 @@
 
 ![ImpactMappingCR](./images/impact_mapping_cr.png)
 
-| Versión | Cambio                    | Autor del cambio                | Aprobado por | Fecha de cambio |
-| ------- | ------------------------- | ------------------------------- | ------------ | --------------- |
-| v 1.0   | Crear el Impact Mapping   | Damariz Licea y David Langarica | NA           |                 |
-| v 2.0   | Actualizar Impact Mapping | Diego Vega y José Riosmena      | NA           | 03/04/2024      |
+| Versión | Cambio                    | Autor del cambio                | Revisor(es) | Fecha de cambio |
+| ------- | ------------------------- | ------------------------------- | ----------- | --------------- |
+| v 1.0   | Crear el Impact Mapping   | Damariz Licea y David Langarica | NA          |                 |
+| v 2.0   | Actualizar Impact Mapping | Diego Vega y José Riosmena      | NA          | 03/04/2024      |

docs/cr/Análisis/user-story-mapping.md

@@ -2,7 +2,7 @@
 
 ![UserStoryMappingCR](./images/user_story_mapping.png)
 
-| Versión | Cambio      | Autor del cambio           | Aprobado por      | Fecha de cambio |
+| Versión | Cambio      | Autor del cambio           | Revisor(es)       | Fecha de cambio |
 | ------- | ----------- | -------------------------- | ----------------- | --------------- |
 | v 1.0   | Creado      | Diego Llaca                | Alejandra Cabrera |                 |
 | v 2.0   | Actualizado | Diego Vega y José Riosmena | NA                | 03/04/2024      |

docs/cr/Check-List/checklist_analisis.md

@@ -27,7 +27,7 @@ El análisis de requerimientos es un componente crítico para el éxito del desa
 
 Este checklist debe ser aplicado meticulosamente durante la fase de análisis de requerimientos para garantizar un desarrollo del proyecto alineado, eficiente y orientado a satisfacer las necesidades del cliente y los usuarios finales.
 
-| Versión | Cambio                   | Autor del cambio | Aprobado por      | Fecha de cambio |
-| ------- | ------------------------ | ---------------- | ----------------- | --------------- |
-| v 1.0   | Creación de la checklist | Uri Gopar        | Miguel Ángel Tena | 05/04/2024      |
-| v 2.0   | Ajuste de checklist      | Alejandra Cabrera y Juan Pablo|  Uri Gopar | 12/04/2024|
+| Versión | Cambio                   | Autor del cambio               | Revisor(es)       | Fecha de cambio |
+| ------- | ------------------------ | ------------------------------ | ----------------- | --------------- |
+| v 1.0   | Creación de la checklist | Uri Gopar                      | Miguel Ángel Tena | 05/04/2024      |
+| v 2.0   | Ajuste de checklist      | Alejandra Cabrera y Juan Pablo | Uri Gopar         | 12/04/2024      |

docs/cr/Check-List/checklist_codificación.md

@@ -28,7 +28,7 @@ Asegurar el manejo de errores en llamadas asíncronas.
 
 Comprobar el uso correcto de comillas dobles para strings en Python y XML. Asegurarse de que se utilizan template strings (f-strings) para construir mensajes que incluyen variables.
 
-| Versión | Cambio                           | Autor del cambio           | Aprobado por               | Fecha de cambio |
-| ------- | -------------------------------- | -------------------------- | -------------------------- | --------------- |
-| v 1.0   | Creación de la checklist         | Juan Pablo Cabrera Quiroga | Diego Sandoval             | 16/04/2024      |
-| v 2.0   | Corrección de estilo y checklisr | Diego Sandoval             | Daniel Cajas y Ale cabrera | 18/04/2024      |
+| Versión | Cambio                           | Autor del cambio           | Revisado por                     | Fecha de cambio |
+| ------- | -------------------------------- | -------------------------- | -------------------------------- | --------------- |
+| v 1.0   | Creación de la checklist         | Juan Pablo Cabrera Quiroga | Diego Sandoval                   | 16/04/2024      |
+| v 2.0   | Corrección de estilo y checklist | Diego Sandoval             | Daniel Cajas y Alejandra Cabrera | 18/04/2024      |

docs/cr/Check-List/checklist_diseno.md

@@ -26,6 +26,6 @@ La fase de diseño es clave para entender qué partes componen la solución del
 
 Es fundamental que el diseño sea exhaustivamente evaluado y validado para garantizar que cumpla con las expectativas y necesidades de los interesados. Al seguir estos criterios, aseguramos que el diseño de requerimientos sea robusto, comprensible y adaptable, formando las bases para una implementación exitosa y una solución de calidad.
 
-| Versión | Cambio                   | Autor del cambio               | Aprobado por | Fecha de cambio |
-| ------- | ------------------------ | ------------------------------ | ------------ | --------------- |
-| v 1.0   | Creación de la checklist | José Riosmena, David Langarica |              | 08/04/2024      |
+| Versión | Cambio                   | Autor del cambio               | Revisor(es) | Fecha de cambio |
+| ------- | ------------------------ | ------------------------------ | ----------- | --------------- |
+| v 1.0   | Creación de la checklist | José Riosmena, David Langarica |             | 08/04/2024      |

docs/cr/Check-List/checklist_revision_pr.md

@@ -47,7 +47,7 @@ La revisión de un Pull Request es una parte fundamental del proceso de desarrol
 
 Es fundamental que la revisión de un Pull Request sea rigurosa y exhaustiva, para garantizar la calidad del código y la correcta implementación de la user story. Al seguir estos criterios, aseguramos que el código cumpla con los estándares de calidad y que la solución propuesta sea robusta y eficiente.
 
-| Versión | Cambio                                                     | Autor del cambio             | Aprobado por      | Fecha de cambio |
+| Versión | Cambio                                                     | Autor del cambio             | Revisor(es)       | Fecha de cambio |
 | ------- | ---------------------------------------------------------- | ---------------------------- | ----------------- | --------------- |
 | v 1.0   | Creación de la checklist                                   | Diego Sandoval, Daniel Cajas | Alejandra Cabrera | 10/04/2024      |
 | v 2.0   | Modificación de la checklist                               | Juan Pablo Cabrera           |                   | 16/04/2024      |