El proceso de gestión de solicitudes de cambios en ingeniería de sistemas es el proceso de solicitar, determinar la alcanzabilidad, planificar, implementar y evaluar cambios en un sistema . Sus principales objetivos son apoyar el procesamiento y la trazabilidad de los cambios en un conjunto interconectado de factores. [1]
Existe una considerable superposición y confusión entre la gestión de solicitudes de cambio, el control de cambios y la gestión de la configuración . La definición que figura a continuación aún no integra estas áreas.
La gestión de solicitudes de cambios ha sido adoptada por su capacidad de ofrecer beneficios al mejorar el sistema afectado y, por lo tanto, satisfacer las "necesidades del cliente", pero también ha sido criticada por su potencial para confundir y complicar innecesariamente la administración de cambios. En algunos casos, especialmente en el ámbito de la tecnología de la información , se dedican más fondos y trabajo al mantenimiento del sistema (y a la gestión de solicitudes de cambio) que a la creación inicial de un sistema. [2] La inversión típica de las organizaciones durante la implementación inicial de grandes sistemas ERP es del 15 al 20 por ciento del presupuesto total.
En la misma línea, Hinley [3] describe dos de las leyes de evolución del software de Lehman :
La gestión de solicitudes de cambios también es de gran importancia en el campo de la fabricación, que se enfrenta a muchos cambios debido a la creciente competencia mundial , los avances tecnológicos y los clientes exigentes. [4] Debido a que muchos sistemas tienden a cambiar y evolucionar a medida que se utilizan, los problemas de estas industrias se experimentan hasta cierto punto en muchas otras.
Notas: En el proceso siguiente, se puede argumentar que el comité de cambios debería ser responsable no sólo de las decisiones de aceptación/rechazo, sino también de la priorización, lo que influye en cómo se agrupan las solicitudes de cambio para su procesamiento.
Para la descripción del proceso de gestión de solicitudes de cambio se utiliza la técnica del metamodelado . La Figura 1 muestra el diagrama de datos del proceso , que se explica en esta sección.
Hay seis actividades principales, que en conjunto forman el proceso de gestión de solicitudes de cambio. Ellos son: Identificar cambios potenciales, Analizar la solicitud de cambio, Evaluar el cambio, Planificar el cambio, Implementar el cambio y Revisar y cerrar el cambio. Estas actividades son ejecutadas por cuatro roles diferentes , que se analizan en la Tabla 1. Las actividades (o sus subactividades, si corresponde) en sí se describen en la Tabla 2.
Además de las actividades, el diagrama de datos del proceso (Figura 1) también muestra los entregables de cada actividad, es decir, los datos. Estos entregables o conceptos se describen en la Tabla 3; En este contexto, los conceptos más importantes son: SOLICITUD DE CAMBIO y ENTRADA DE REGISTRO DE CAMBIO.
Algunos conceptos son definidos por el autor (es decir, carecen de referencia), porque no se pudieron encontrar (buenas) definiciones o son el resultado obvio de una actividad. Estos conceptos están marcados con un asterisco ('*'). Las propiedades de los conceptos se han dejado fuera del modelo porque la mayoría de ellos son triviales y, de lo contrario, el diagrama podría volverse demasiado complejo rápidamente. Además, algunos conceptos (por ejemplo, SOLICITUD DE CAMBIO, LIBERACIÓN DEL SISTEMA) se prestan para el enfoque de control de versiones propuesto por Weerd, [6] pero esto también se ha omitido debido a restricciones de complejidad del diagrama.
Además de los "cambios", también se pueden distinguir desviaciones y renuncias. [7] Una desviación es una autorización (o una solicitud para ello) para apartarse de un requisito de un artículo, antes de la creación del mismo. Una renuncia es esencialmente lo mismo, pero que durante o después de la creación del artículo. Estos dos enfoques pueden verse como una gestión minimalista de solicitudes de cambio (es decir, sin una solución real al problema en cuestión).
Un buen ejemplo del proceso de gestión de solicitudes de cambio en acción se puede encontrar en el desarrollo de software . A menudo, los usuarios informan de errores o desean nuevas funciones en sus programas de software, lo que lleva a una solicitud de cambio . Luego, la empresa de software del producto analiza la viabilidad técnica y económica de implementar este cambio y, en consecuencia, decide si el cambio realmente se realizará. Si ese es realmente el caso, el cambio debe planificarse, por ejemplo mediante el uso de puntos de función . La ejecución real del cambio conduce a la creación y/o alteración del código de software y cuando este cambio se propaga probablemente provoca que otros fragmentos de código también cambien. Una vez que los resultados de las pruebas iniciales parezcan satisfactorios, la documentación se puede actualizar y publicar junto con el software. Finalmente, el director del proyecto verifica el cambio y cierra esta entrada en el registro de cambios.
Otra área típica para la gestión de solicitudes de cambio, tal como se trata aquí, es el ámbito de fabricación . Tomemos, por ejemplo, el diseño y la producción de un automóvil . Si, por ejemplo, se descubre que los airbags del vehículo se llenan automáticamente de aire después de recorrer largas distancias, esto sin duda dará lugar a quejas de los clientes (o, con suerte, a informes de problemas durante la fase de prueba). A su vez, estos producen una solicitud de cambio (ver Figura 2 a la derecha), que probablemente justificará un cambio. Sin embargo, es necesario realizar un análisis de costes y beneficios (probablemente simplista) tras el cual se puede aprobar la solicitud de cambio. Tras un análisis del impacto en el diseño del automóvil y los cronogramas de producción, se puede crear la planificación para la implementación del cambio. Según esta planificación, el cambio podrá realizarse, después de lo cual se espera que la nueva versión del coche se pruebe minuciosamente antes de su lanzamiento al público.
Dado que los procesos complejos pueden ser muy sensibles incluso a cambios pequeños, se reconoce que la gestión adecuada de los cambios en las plantas de procesos industriales es fundamental para la seguridad. Los cambios no documentados y sin una evaluación adecuada de los riesgos son una receta para el desastre. Un ejemplo eminente de esto es la explosión de Flixborough , donde cambios improvisados que implicaron el desvío de una etapa en un tren de reactores fueron el origen del accidente. El cambio no se había pensado, documentado ni evaluado adecuadamente los riesgos, por lo que no se había identificado el caso de violación de la contención. [8] En los EE. UU., OSHA tiene regulaciones que rigen cómo se deben realizar y documentar los cambios. El requisito principal es que un equipo multidisciplinario realice una revisión exhaustiva de un cambio propuesto para garantizar que se utilicen tantos puntos de vista posibles para minimizar las posibilidades de pasar por alto un peligro. En este contexto, la gestión de solicitudes de cambio se conoce como Gestión del Cambio o MOC. Es solo uno de los muchos componentes de la Gestión de la seguridad de procesos , sección 1910.119(l).1.