PRO-BDT-022 Crear o realizar cambios en un elemento de configuración de la Wiki
v 13.0 / CM, OPD, OPF, VER
Propósito
Describir cómo crear o realizar un cambio a un elemento de configuración de dinámico a controlado en la Wiki
Notas introductorias
- En los repositorios de código, el nivel dinámico es
develop, el nivel controlado esmainy el nivel estático son losreleasesde GitHub. - En la Wiki, el nivel dinámico son las ramas
personalesydevelop, el nivel controlado es la ramamainy el nivel estático son losreleasesde GitHub.
Involucrados
- Autor del cambio
- Revisor del cambio
- Black Dot
Entradas
- Elemento de configuración a crear o modificar
- Checklists
- Plantillas
Salidas
- Elemento de configuración creado o modificado integrado en la wiki
- Matriz de Configuración actualizada
Descripción
| Fase | Actividades | Responsables | Prácticas Asociadas al CMMI |
|---|---|---|---|
| Identificación | Identificar cuál es el elemento de trabajo a crear o modificar. | Autor del cambio | CM SP 1.1 |
| Identificación | Si el proceso mejora o reemplaza un proceso existente, deprecar el proceso anterior. Además, actualizar el proceso en la Matriz de Configuración con el tag de [DEPRECATED] en el títiulo del proceso. Finalmente mueve el proceso a la carpeta de deprecado dentro de procesos. | Autor del cambio | CM SP 3.1 OPF SP 3.3 |
| Preparación | Verificar que no está implementado o siendo implementado en la Matriz de Configuración. En caso de no haber sido implementado todavía, agregar una nueva fila a la hoja correspondiente de la matriz de configuración y asignarle un nuevo identificador conforme a la GUI-BDT-020. | Autor del cambio | CM SP 2.1 CM SP 2.2 OPD SP 1.5 VER SP 1.1 VER SP 1.2 |
| Ejecución | Crear una nueva rama a partir de la rama develop donde se realizarán las modificaciones. El nombre de la nueva rama debe seguir el EST-BDT-006. | Autor del cambio | CM SP 1.2 CM SP 2.2 OPD SP 1.6 VER SP 1.3 |
| Ejecución | Realizar cambios pertinentes en la nueva rama. Si se está creando un docuemento por primera vez, seleccionar la plantilla correspondiente de las entradas del proceso. | Autor del cambio | CM SP 2.2 |
| Ejecución | Versionar el documento conforme a la estándar EST-BDT-003. | Autor del cambio | CM SP 2.2 CM SP 3.1 VER SP 1.3 |
| Ejecución | Revisar que el producto de trabajo creado o modificado pase su checklist correspondiente. Si no pasa, realizar los cambios pertinentas hasta que pase todos los criterios de aceptación | Autor del cambio | CM SP 2.1 CM SP 2.2 CM SP 3.2 VER SP 3.1 VER SP 3.2 |
| Ejecución | Al terminar los cambios, solicitar a un miembro del departamento que los revise. Atender a la retroalimentación y anotar al revisor en la tabla de control de cambios del documento. | Autor del cambio Revisor | CM SP 2.1 CM SP 2.2 |
| Registro | Registrar en la Matriz de Configuración los cambios realizados conforme a la GUI-BDT-020. | Autor del cambio | CM SP 1.2 CM SP 2.1 CM SP 2.2 OPF SP 3.1 |
| Solicitud | Realizar la petición de cambio (Pull Request) a la rama develop siguiendo el estándar para PR de la Wiki. | Autor del cambio Revisor | CM SP 2.1 CM SP 2.2 OPD SP 1.6 VER SP 1.3 VER SP 2.1 |
| Solicitud | El autor del cambio debe solicitar al revisor del documento que revise y apruebe la petición de cambio (Pull Request). El revisor analiza que se cumplan los puntos mencionados en el estándar para PR de la Wiki. Si no se sigue el estándar, el revisor solicita los cambios necesarios y no se integra con develop hasta que los cambios se vean reflejados en el producto de trabajo. | Autor del cambio Revisor | CM SP 2.1 CM SP 2.2 VER SP 1.3 VER SP 2.2 VER 2.3 OPD SP 1.1 |
| Auditoría | En caso de que el producto de trabajo sea un proceso, el autor del documento debe solicitar al revisor que realice una auditoría del nuevo producto de trabajo o de los cambios conforme al PRO-BDT-021 | Autor del cambio Revisor | CM SP 3.2 OPF SP 1.2 PPQA SP 1.2 OPF SP 3.2 |
| Revisión | El revisor aprueba o rechaza los cambios, escribiendo comentarios de la razón de su decisión. Si los cambios son aprobados, el proceso continua. Si los cambios son rechazados, el autor de los cambios debe atender la retroalimentación recibida. | Autor del cambio Revisor | CM SP 2.1 CM SP 2.2 OPF SP 1.2 OPF SP 1.3 |
| Comunicación | El autor del documento debe presentar los cambios realizados al departamento en la junta departamental del día. En caso de no haber junta ese día, solicitar a un PM que organice un espacio en el día para presentar los cambios. El PM debe solicitar a todos los que realizaron cambios durante ese día a presentarlos también. | Autor del cambio PM | CM SP 2.1 CM SP 2.2 OPF SP 3.1 |
Control de cambios
| Versión | Cambio realizado | Análisis | Autor del cambio | Revisor(es) | Fecha de cambio |
|---|---|---|---|---|---|
| v 1.0 | Creación del proceso | N/A | Carlos Velasco Diego Perdomo Sergio Garnica | Carlos Salguero | 22/04/2024 |
| v 2.0 | Actualización fase de Ejecución, Revisión y Conclusión | N/A | Carlos Velasco | Sergio Garnica | 24/04/2024 |
| v 3.0 | Actualización fase de Conclusión | N/A | Sergio Garnica | Carlos Salguero | 24/04/2024 |
| v 4.0 | Actualización de Propósito | N/A | Carlos Velasco | Sergio Garnica | 25/04/2024 |
| v 5.0 | Adaptación del proceso siguiendo la retro del departamento | N/A | Carlos Velasco | Sergio Garnica | 26/04/2024 |
| v 6.0 | Añadir ramas dinámicas para realizar cambios en fase de ejecución, mapa de procesos, PRO-BDT-001 y fase de Experimentación | N/A | Sergio Garnica | Carlos Salguero | 29/04/2024 |
| v 7.0 | Añadir el proceso 001 para la creación de procesos en la fase de Ejecución | N/A | Carlos Salguero | Sergio Garnica | 29/04/2024 |
| v 8.0 | Mejora del proceso | El proceso era un poquito confuso de entender con la referencia a los otros procesos, guías, e ítmes del trabajo y por esta razón, se mejoró para que tenga más sentido con nuestra forma de trabajo | Yuna Chung | Sergio Garnica | 29/04/2024 |
| v 8.1 | Actualizar Versión | N/A | Carlos Velasco | David Langarica | 30/04/2024 |
| v 9.0 | Actualizar flujo del proceso | El proceso contenía fases innecesarias y se simplificó. Se eliminó la referencia al PRO-BDT-001, se cambió el uso de la rama main por develop para crear nuevas ramas, se elimina la fase de conclusión, agregar la fase de comunicación y de verificación junto con las checklists | Sergio Garnica, Diego Perdomo, Carlos Velasco | Denisse Domínguez | 13/05/2024 |
| v 10.0 | Plantillas de productos de trabajo | Se agregaron las plantillas de los productos de trabajo como entradas al proceso. | Sergio Garnica | Denisse Domínguez | 15/05/2024 |
| v 11.0 | Fase de auditorías y prácticas de VER | Se modificó la fase de auditorías para que solo aplica si el producto de trabajo es un proceso. Además se agregaron las prácticas de VER en el proceso. | Carlos Velasco | Alejandra Cabrera | 21/05/2024 |
| v 12.0 | Actualización de la fase de identificación para deprecar procesos | Se añade como deprecar procesos CM 3.1 | Carlos Salguero Diego Llaca | Alejandra Cabrera | 23/05/2024 |
| v 12.1 | Se añade la nueva mejora de wording para deprecar procesos | Se añade la nueva mejora de wording para deprecar procesos para que sea mas entendible | Carlos Salguero Diego Llaca | Alejandra Cabrera | 23/05/2024 |
| v 12.2 | Se añade prácticas de OPF | Identificar las fases en la que se usa OPF | Denisse Domínguez Rodrigo Terán | Sergio Garnica | 27/05/2024 |
| v 12.3 | Se añade prácticas de CM | Identificar las fases en la que se usa CM | Sergio Garnica | Diego Perdomo | 07/06/2024 |
| v 12.4 | Se añade prácticas de OPD 1.1 | Identificar las fases en la que se usa OPD 1.1, en el proceso de aceptar la petición de pull request | Uri Gopar | Ramona Nájera | 07/06/2024 |
| v 13.0 | Se añade prácticas de VER | Faltaba identificar la SP 1.1 de VER en uno de los pasos | Diego Llaca | Alejandra Cabrera | 07/06/2024 |