El proceso de gestión de solicitudes de cambio en ingeniería de sistemas es el proceso de solicitar, determinar la viabilidad, planificar, implementar y evaluar los cambios en un sistema . Sus principales objetivos son respaldar el procesamiento y la trazabilidad de los cambios en un conjunto interconectado de factores. [1]
Existe una superposición y confusión considerables entre la gestión de solicitudes de cambio, el control de cambios y la gestión de configuración . La definición que figura a continuación aún no integra estas áreas.
La gestión de solicitudes de cambio ha sido bien recibida por su capacidad de generar beneficios mejorando el sistema afectado y satisfaciendo así 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, sobre todo en el ámbito de la tecnología de la información , se invierten más fondos y trabajo en el mantenimiento del sistema (y en la gestión de solicitudes de cambio) que en 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 Lehman sobre la evolución del software :
La gestión de solicitudes de cambio 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 en algún grado en muchas otras.
Notas: En el proceso a continuación, se puede argumentar que el comité de cambios debería ser responsable no solo de las decisiones de aceptación o rechazo, sino también de la priorización, 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 de metamodelado . En la Figura 1 se muestra el diagrama proceso-datos , que se explica en esta sección.
Existen seis actividades principales que, en conjunto, forman el proceso de gestión de solicitudes de cambio. Son: identificar el cambio potencial, 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 describen en la Tabla 1. Las actividades (o sus subactividades, si corresponde) se describen en la Tabla 2.
Además de las actividades, el diagrama de proceso-datos (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 CAMBIOS.
Algunos conceptos están definidos por el autor (es decir, carecen de una referencia), ya sea porque no se pudieron encontrar (buenas) definiciones o porque son el resultado obvio de una actividad. Estos conceptos están marcados con un asterisco ('*'). Las propiedades de los conceptos se han omitido del modelo, ya que la mayoría de ellas son triviales y, de lo contrario, el diagrama podría volverse rápidamente demasiado complejo. Además, algunos conceptos (por ejemplo, SOLICITUD DE CAMBIO, VERSIÓ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 las restricciones de complejidad del diagrama.
Además de los "cambios", también se pueden distinguir desviaciones y exenciones. [7] Una desviación es una autorización (o una solicitud de esta) para apartarse de un requisito de un elemento, antes de su creación. Una exención es esencialmente lo mismo, pero durante o después de la creación del elemento. Estos dos enfoques pueden considerarse como una gestión minimalista de las solicitudes de cambio (es decir, no hay 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 funcionalidades para sus programas de software, lo que da lugar a una solicitud de cambio . La empresa de software del producto analiza entonces la viabilidad técnica y económica de implementar este cambio y, en consecuencia, decide si el cambio realmente se realizará. Si ese es 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 provoque también cambios en otros fragmentos de código. Una vez que los resultados de las pruebas iniciales parecen 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.
Otro ámbito típico de gestión de solicitudes de cambio, tal y como se aborda aquí, es el ámbito de la fabricación . Tomemos como ejemplo el diseño y la producción de un coche . Si, por ejemplo, se descubre que los airbags del vehículo se llenan de aire automáticamente 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, esto genera una solicitud de cambio (véase la Figura 2 a la derecha), que probablemente justificará un cambio. No obstante, se debe realizar un análisis de costes y beneficios (probablemente simplista), tras lo cual se puede aprobar la solicitud de cambio. Tras un análisis del impacto en el diseño del coche y en los cronogramas de producción, se puede crear la planificación para la implementación del cambio. Según esta planificación, el cambio puede realmente realizarse, tras lo cual, con suerte, se prueba exhaustivamente la nueva versión del coche antes de lanzarla al público.
Dado que los procesos complejos pueden ser muy sensibles incluso a pequeños cambios, 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 no evaluados adecuadamente en términos de riesgos son una receta para el desastre. Un ejemplo eminente de esto es la explosión de Flixborough , donde los cambios improvisados que implicaban la derivación de una etapa en un tren de reactores fueron el origen del accidente. El cambio no se había pensado, documentado ni evaluado adecuadamente en términos de riesgos, por lo que no se había identificado el evento de ruptura 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 seguridad de procesos , sección 1910.119(l).1.