Proceso de implementación de una compilación de Windchill Navigate
El proceso de implementación implica el envío y la promoción de paquetes a través de varios entornos. El objetivo es garantizar que el paquete se pruebe y valide exhaustivamente en cada etapa antes de llegar al entorno de implementación final.
El proceso de implementación de Navigate incluye los siguientes pasos:
1. La implementación inicial en un entorno inferior
2. Estadio de la curva de madurez
3. La implementación final en el entorno de producción
Considere el siguiente escenario: el equipo selecciona un caso de uso en función de los requisitos actuales y, a continuación, integra el caso de uso en el ciclo de sprint. El proceso implica el envío y la promoción del paquete a través de varias etapas. Inicialmente, se despliega el paquete en un entorno inferior enviándolo. El paquete se promociona en el estadio de la curva de madurez. La promoción final se produce en la etapa de implementación final.
Descripción detallada del proceso
1. Implementación de la primera compilación/inicial: la implementación de la compilación inicial que PTC recibe del cliente se somete a una revisión exhaustiva por parte del equipo de PTC. Entre los artefactos necesarios para esta revisión se incluyen:
◦ Cuestionario completado: un cuestionario detallado completado por el cliente.
◦ Paquete de compilación: un paquete comprimido enviado por los clientes/integradores de sistemas.
 | La compilación inicial avanza al siguiente paso solo si el equipo de PTC la aprueba, lo que garantiza que cumple las directrices necesarias. |
2. Estadio de la curva de madurez: este estadio no requiere la aprobación del equipo de PTC. Durante este estadio, la compilación pasa por una curva de madurez, que incluye las siguientes tareas:
◦ Correcciones de errores: identificación y resolución de incidencias.
◦ Cambios de lógica: refinamiento de la funcionalidad de la compilación.
◦ Pruebas de aceptación del usuario (UAT): garantizar de que la compilación cumpla con los requisitos del usuario.
◦ Cambios cosméticos: ajuste de la interfaz y la experiencia del usuario.
La implementación inicial se produce en un entorno de no producción. Un cliente o integrador de sistemas es responsable de mantener una documentación exhaustiva de todos los cambios realizados en la compilación.
| | Es fundamental que los requisitos que aborda el paquete de compilación y las dependencias de compilación (en bibliotecas de terceros) permanezcan sin cambios durante este proceso. Si se producen cambios, se debe reiniciar el proceso de implementación. |
3. Implementación de la compilación final en el entorno de producción: la implementación final en el servidor del producto se somete a una revisión exhaustiva y detallada por parte del equipo de PTC. Esta revisión garantiza que todos los aspectos de la compilación cumplan los estándares más altos de calidad, funcionalidad y cumplimiento antes de su lanzamiento en el entorno de producción. Entre los artefactos necesarios para esta revisión se incluyen:
◦ Cuestionario completado: un cuestionario detallado completado por el cliente.
◦ Paquete de compilación: un paquete comprimido enviado por los clientes/integradores de sistemas.
◦ Documentación detallada: documentación completa de todos los cambios realizados en la compilación durante el estadio de madurez. Para obtener más información, consulte la sección Creación de documentación completa: directrices clave.
| | Este estadio necesita la aprobación del equipo de PTC. |
Directrices para los clientes
• Coherencia de los requisitos: la compilación inicial que cargue debe tener todo el contenido significativo. Es crucial que el integrador de sistemas evite introducir cambios significativos en los requisitos o dependencias (especialmente en bibliotecas de terceros) durante los dos estadios de implementación: primer estadio y tercer estadio.
• Documentación exhaustiva: se debe mantener una documentación completa de todas las modificaciones realizadas en la compilación.
• Revisión del equipo de PTC: el equipo de PTC revisa todos los cambios antes de promocionar la compilación para la implementación final en el entorno de producción.
Si se cumplen estas directrices, se puede garantizar un proceso de implementación seguro y estable para la compilación de Windchill Navigate.
¿Con qué frecuencia se debe repetir el proceso de implementación?
Al considerar una personalización, se tiene en mente un caso de uso específico y un equipo de desarrollo que trabaja en ciclos de sprint. El equipo selecciona un caso de uso, que podría ser un requisito o un conjunto de requisitos, y comienza a desarrollarlo en ciclos de sprint. A veces, es posible que se necesiten varios ciclos de sprint para preparar la compilación.
Por ejemplo, en un ciclo de lanzamiento de seis meses con cinco sprints, los requisitos se seleccionan y desarrollan dentro de estos sprints. Es posible que tenga diferentes plazos, como sprints de 20 días con fases de desarrollo, control de calidad e implementación. Si los requisitos cambian significativamente durante el ciclo, el proceso debe reiniciarse y se requieren aprobaciones.
La frecuencia del proceso de implementación depende del número de casos de uso y ciclos de sprint. Por ejemplo, si se desarrollan 10 casos de uso en 10 ciclos de sprint, el proceso se sigue 10 veces. Si está desarrollando 5 casos de uso en un ciclo de sprint, el proceso se sigue dos veces.
Ejemplos adicionales:
1. Ejemplo 1: ciclos de sprint más cortos
◦ Tiene un ciclo de sprint de 2 semanas. Se selecciona un requisito, se desarrolla durante 10 días, se dedican 2 días al control de calidad y, a continuación, se implementa. Si tiene 6 requisitos, seguirá el proceso 6 veces en 12 semanas.
2. Ejemplo 2: requisitos solapados
◦ Hay requisitos solapados que abarcan varios sprints. Por ejemplo, un requisito que tarda 3 sprints en completarse seguirá el proceso una vez para cada sprint, lo que garantiza la integración y las pruebas continuas.
3. Ejemplo 3: cambios importantes a mitad de ciclo
◦ Si se realiza un cambio significativo en un requisito a mitad de ciclo, como la modificación del modelo de datos, se debe reiniciar el proceso. De este modo, se garantiza que se vuelvan a evaluar todas las dependencias y se obtengan las aprobaciones.
4. Ejemplo 4: implementaciones frecuentes
◦ Prefiere implementaciones frecuentes y tiene un ciclo de sprint de 1 semana. Se desarrolla durante 4 días, se realiza el control de calidad durante 1 día y se implementa el último día. Con 8 requisitos, sigue el proceso 8 veces en 8 semanas.
5. Ejemplo 5: plazos personalizados
◦ Los plazos personalizados se establecen en función de las necesidades del proyecto. Por ejemplo, se puede tener un ciclo de sprint de 30 días con 20 días de desarrollo, 5 días de control de calidad y 5 días de implementación. La frecuencia del proceso se ajusta en función del número de requisitos y su complejidad.
¿Qué información se incluye en el cuestionario?
Se deben completar dos cuestionarios durante el proceso de implementación:
1. Cuestionario de implementación inicial: este cuestionario es necesario para la primera implementación en un entorno inferior. Garantiza que todas las comprobaciones y configuraciones preliminares estén en su lugar antes de seguir adelante.
2. Cuestionario de implementación final: este cuestionario es necesario para la implementación final en el entorno de producción. Verifica que todos los aspectos críticos se han revisado y aprobado, lo que garantiza una implementación fluida y correcta.
A continuación se muestra un ejemplo de cuestionario:
Pregunta | Respuesta | |
|---|---|---|
Detalles generales | Nombre de cuenta de cliente | |
Versión de Windchill | ||
Versión de Windchill Navigate | ||
Fecha de implementación planificada | ||
Entorno de implementación planificado | ||
Detalles del paquete | ¿Ha probado este paquete en entornos inferiores? (En caso afirmativo, asigne un nombre al entorno) | |
¿Qué tipo de personalizaciones ha implementado? | ||
¿Se utiliza alguna biblioteca de terceros en este paquete? | ||
¿Se utiliza el método de autenticación por defecto o este paquete se basa en claves de aplicación? | ||
¿Cuál es el caso de negocio u objetivo que pretende abordar esta personalización? | ||
¿Se ha asegurado de que ninguna parte de la personalización infrinja las barreras de protección? | ||
¿Cuáles son las diferencias entre el paquete antiguo y el nuevo (si las hay)? |
| | En este cuestionario, debe describir las diferencias entre los paquetes antiguos y nuevos. Por ejemplo, se puede explicar si se han añadido nuevas funciones, si se han corregido errores o si se han realizado cambios en el número de versión. Estas diferencias son importantes porque ayudan a garantizar que todos los implicados en el proceso de implementación comprendan lo que ha cambiado. De este modo, se pueden evitar problemas, garantizar la compatibilidad y asegurarse de que el nuevo paquete cumpla todos los requisitos. |
Creación de documentación completa: directrices clave
Al enviar la compilación final para su implementación en el entorno de producción, es fundamental incluir documentación completa de todos los cambios realizados durante el estadio de madurez. En esta documentación se deben detallar todas las actualizaciones, adiciones de funciones, correcciones de errores y revisiones que se hayan producido a lo largo del proceso de desarrollo.
Al proporcionar documentación exhaustiva, se garantiza que todas las partes interesadas estén al tanto de los cambios, lo que ayuda a solucionar problemas, mantener la coherencia y verificar que la compilación cumpla todos los requisitos. Este paso es esencial para una implementación correcta y fluida, lo que minimiza el riesgo de errores y garantiza que el entorno de producción esté completamente preparado para la nueva compilación.
Considere el escenario siguiente:
Normalmente, se inicia un ciclo de compilación con la versión 1.0. A medida que se revise la compilación en estadios posteriores, se puede actualizar a versiones como 1.1, 1.2, etc. En el momento en que la compilación esté lista para su implementación en el servidor de producción, es posible que se haya revisado varias veces, hasta alcanzar una versión final como la 1.7.
Se debe mantener un registro detallado de los cambios realizados durante cada revisión. Por ejemplo, si cambia 5 elementos, documente estos cambios con claridad. Esta documentación puede adoptar la forma de notas de la versión, cuyo tamaño variará en función del producto.
Por ejemplo, la documentación puede incluir:
• Versión 1.4.6: se ha añadido una corrección para gestionar una incidencia específica.
• Versión 1.4.5: se ha implementado una nueva función.
• Versión 1.4.4: rendimiento mejorado para una función determinada.
Este tipo de documentación ayuda a realizar el seguimiento del recorrido de la compilación desde la versión 1.0 a la 1.7. Puede utilizar capturas de pantalla o cualquier formato que transmita mejor la información relevante. La clave es garantizar un seguimiento exhaustivo de los cambios. Puede diseñar el formato para satisfacer sus necesidades, ya sea un documento de Word, una hoja de Excel o cualquier otro método.
A continuación se muestran ejemplos de un registro de cambios:
Ejemplo 1. Registro de cambios conciso: resumen en una línea para referencia rápida
Ejemplo 2. Registro de cambios detallado: lista completa de actualizaciones
Ejemplo 3. Registro de cambios completo: recopilación exhaustiva de actualizaciones, correcciones y mejoras
