El proceso de gestión de solicitudes de cambio en la ingeniería de sistemas es el proceso de solicitar, determinar la alcanzabilidad, planificar, implementar y evaluar cambios en un sistema . Sus principales objetivos son respaldar el procesamiento y la trazabilidad de los cambios en un conjunto de factores interconectados. [1]
Introducción
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 la configuración . La siguiente definición aún no integra estas áreas.
La gestión de solicitudes de cambio ha sido aceptada 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 invierten más fondos y trabajo en el mantenimiento del sistema (y 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 general.
En la misma línea, Hinley [3] describe dos de las leyes de la evolución del software de Lehman :
- La ley del cambio continuo : los sistemas que se utilizan deben cambiar o, de lo contrario, automáticamente se volverán menos útiles.
- La ley de la complejidad creciente : a través de los cambios, la estructura de un sistema se vuelve cada vez más compleja y se requieren más recursos para simplificarlo.
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 hasta cierto punto en muchas otras.
Notas: En el proceso a continuación, se puede argumentar que el comité de cambios debe ser responsable no solo de las decisiones de aceptación / rechazo, sino también de la priorización, lo que influye en la forma en que se agrupan las solicitudes de cambio para su procesamiento.
El proceso y sus entregables
Para la descripción del proceso de gestión de solicitudes de cambio, se utiliza la técnica de metamodelado. La Figura 1 muestra el diagrama de datos de proceso , que se explica en esta sección.
Ocupaciones
Hay seis actividades principales, que forman conjuntamente el proceso de gestión de solicitudes de cambio. Estos 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 analizan en la Tabla 1. Las actividades (o sus subactividades, si corresponde) en sí mismas se describen en la Tabla 2.
Papel | Descripción |
---|---|
Cliente | El cliente es el rol que solicita un cambio debido a problemas encontrados o nuevos requisitos de funcionalidad; puede ser una persona o una entidad organizativa y puede ser interno o externo a la empresa a la que se le solicita que implemente el cambio. |
Gerente de proyecto | El director del proyecto es el propietario del proyecto al que se refiere la SOLICITUD DE CAMBIO. En algunos casos hay un administrador de cambios distinto, que en ese caso asume este rol. |
Comité de cambio | El comité de cambios decide si se implementará una SOLICITUD DE CAMBIO o no. A veces, esta tarea también la realiza el director del proyecto. |
Cambiar constructor | El constructor del cambio es la persona que planifica e implementa el cambio; Se podría argumentar que el director del proyecto asume (parcialmente) el componente de planificación. |
Actividad | Subactividad | Descripción |
---|---|---|
Identificar el cambio potencial | Requerir nueva funcionalidad [5] | Un cliente desea una nueva funcionalidad y formula un REQUISITO. |
Problema de encuentro [5] | Un cliente encuentra un problema (por ejemplo, un error ) en el sistema y esto conduce a un INFORME DE PROBLEMA. | |
Solicitar cambio | Un cliente propone un cambio mediante la creación de una SOLICITUD DE CAMBIO. | |
Analizar solicitud de cambio | Determinar la viabilidad técnica | El director del proyecto determina la viabilidad técnica de la SOLICITUD DE CAMBIO propuesta, lo que lleva a un CAMBIO DE VIABILIDAD TÉCNICA. |
Determinar costos y beneficios | El director del proyecto determina los costos y beneficios de la SOLICITUD DE CAMBIO propuesta, lo que resulta en COSTOS Y BENEFICIOS DE CAMBIO. Esta y la subactividad anterior se pueden realizar en cualquier orden y son independientes entre sí, de ahí el modelado como actividades desordenadas. | |
Evaluar el cambio | Con base en la SOLICITUD DE CAMBIO, su CAMBIO DE VIABILIDAD TÉCNICA y CAMBIAR LOS COSTOS Y BENEFICIOS, el comité de cambio toma la decisión de continuar o no. Esto se modela como una actividad separada porque es un paso importante del proceso y tiene otra función desempeñándolo. Se modela como una subactividad (sin ninguna actividad que la contenga) según lo recomendado por Remko Helms (comunicación personal). | |
Cambio de plan | Analizar el impacto del cambio | El alcance del cambio (es decir, qué otros elementos afecta el cambio) se determina en un ANÁLISIS DE IMPACTO DE CAMBIO. Se podría argumentar que esta actividad lleva a otra decisión de pasar o no, o que incluso forma parte de la actividad Analizar solicitud de cambio. Aquí se modela como una tarea de planificación para el generador de cambios debido a su relación con la actividad Propagar cambio. |
Crear planificación | Se crea una PLANIFICACIÓN DEL CAMBIO para la implementación del cambio. Algunas descripciones de procesos (por ejemplo, Mäkäräinen, 2000) ilustran que también es posible "guardar" los cambios y procesarlos más tarde en un lote . Esta actividad podría verse como un buen punto para hacer esto. | |
Implementar el cambio | Ejecutar cambio | El cambio está 'programado'; esta actividad tiene una fuerte relación con Propagar el cambio, porque a veces el cambio tiene que adaptarse a otras partes del sistema (o incluso a otros sistemas) también. |
Propagar el cambio | Los cambios resultantes de Ejecutar cambio deben propagarse a otras partes del sistema que estén influenciadas por él. Debido a que esta y la subactividad anterior son altamente dependientes entre sí, se han modelado como actividades concurrentes. | |
Cambio de prueba | El creador de cambios prueba si lo que ha construido realmente funciona y satisface la SOLICITUD DE CAMBIO. Como se muestra en el diagrama, esto puede resultar en un proceso iterativo junto con las dos subactividades anteriores. | |
Actualizar documentación | La DOCUMENTACIÓN se actualiza para reflejar los cambios aplicados. | |
Cambio de lanzamiento | Se hace pública una nueva PUBLICACIÓN DEL SISTEMA, que refleja el cambio aplicado. | |
Revisar y cerrar el cambio | Verificar cambio | La implementación del cambio en el nuevo SISTEMA DE LIBERACIÓN es verificada por última vez, ahora por el director del proyecto. Tal vez esto tenga que suceder antes del lanzamiento, pero debido a las fuentes de literatura contradictorias y las consideraciones de complejidad del diagrama, se eligió modelarlo de esta manera e incluir este problema. |
Cerrar cambio | Este ciclo de cambio se completa, es decir, se finaliza la ENTRADA DE REGISTRO DE CAMBIOS. |
Entregables
Además de las actividades, el diagrama de datos de 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: CAMBIAR SOLICITUD y CAMBIAR ENTRADA DE REGISTRO.
Algunos conceptos son definidos por el autor (es decir, carecen de una 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 el diagrama podría volverse rápidamente demasiado complejo de otro modo. 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 dejado de lado debido a las limitaciones de complejidad del diagrama.
Concepto | Descripción |
---|---|
REQUISITO | Una funcionalidad requerida de un componente (o artículo; NASA, 2005). |
INFORME DE PROBLEMA | Documento que describe un problema que no puede ser resuelto por un empleado de la mesa de ayuda de nivel 1; contiene elementos como fecha, información de contacto de la persona que informa el problema, qué está causando el problema, ubicación y descripción del problema, acción tomada y disposición, pero esto no se muestra en el diagrama (Dennis, et al., 2002). |
SOLICITUD DE CAMBIO | Documento que describe el cambio solicitado y por qué es importante; puede tener su origen en INFORMES DE PROBLEMAS, mejoras del sistema, otros proyectos, cambios en los sistemas subyacentes y la alta dirección, aquí resumidos como REQUISITOS (Dennis, et al., 2002). Atributo importante: 'decisión de ir / no ir', es decir, ¿el cambio se ejecutará o no? |
CAMBIAR ENTRADA DE REGISTRO * | Entrada distinta en la colección de todos los cambios (por ejemplo, para un proyecto); consta de una SOLICITUD DE CAMBIO, CAMBIO DE VIABILIDAD TÉCNICA, CAMBIO DE COSTOS Y BENEFICIOS, CAMBIO DE ANÁLISIS DE IMPACTO, CAMBIO DE PLANIFICACIÓN, INFORME DE PRUEBA y VERIFICACIÓN DE CAMBIO. No todos estos deben incluirse si el proceso finaliza antes (es decir, si el cambio no se implementa). |
CAMBIAR LA VIABILIDAD TÉCNICA | Concepto que indica si “hardware y software confiables, recursos técnicos capaces de satisfacer las necesidades de un sistema propuesto [es decir, solicitud de cambio] pueden ser adquiridos o desarrollados por una organización en el tiempo requerido” (Vogl, 2004). |
CAMBIAR COSTOS Y BENEFICIOS | El esfuerzo esperado requerido para implementar y las ventajas (por ejemplo, ahorro de costos, aumento de ingresos) obtenidas al implementar el cambio. También denominada viabilidad económica (Vogl, 2004). |
ANÁLISIS DE IMPACTO DE CAMBIOS | Una evaluación del alcance del cambio (Rajlich, 1999). |
CAMBIAR PLANIFICACIÓN | “Un esquema, método o diseño para el logro de algún objetivo o para lograr algo [es decir, el cambio]” (Universidad de Georgetown, sf), en este caso el cambio. |
ARTICULO | “Un término no específico que se usa para designar cualquier producto , incluidos sistemas, subsistemas, ensamblajes, subconjuntos, unidades, conjuntos, accesorios, programas de computadora, software de computadora o partes” (Rigby, 2003); tiene subtipos (superpuestos) ARTÍCULO AÑADIDO y ARTÍCULO CAMBIADO. |
ARTÍCULO AÑADIDO * | Se explica por sí mismo: un ARTÍCULO recién creado; subtipo de ARTÍCULO. |
ARTÍCULO CAMBIADO * | Se explica por sí mismo: un ARTÍCULO que ya existía, pero que ha sido alterado; subtipo de ARTÍCULO. |
INFORME DE PRUEBA | “Un documento que describe la realización y los resultados de las pruebas realizadas para un sistema o componente [afectado por el cambio]” (IEEE, 1991). |
DOCUMENTACIÓN | De acuerdo con la definición de las Bibliotecas de la Universidad Estatal de Pensilvania (2004), DOCUMENTACIÓN es “material impreso que acompaña a otros materiales (generalmente que no son libros) y que explica, brinda instrucciones de uso o funciona como una guía de los materiales principales . " En este contexto, también puede tratarse de materiales digitales o incluso de formación, siempre que se relacione con (piezas de) el sistema. |
LIBERACIÓN DEL SISTEMA | “[M] mercadería emitida para la venta o exhibición pública” (Universidad de Princeton, 2003). Consta de uno o más ARTÍCULOS y la DOCUMENTACIÓN adjunta. |
VERIFICACIÓN DE CAMBIO | Una determinación de si el resultado de la implementación del cambio cumple o no con los requisitos establecidos anteriormente (Rigby, 2003). |
Además de los "cambios", también se pueden distinguir las desviaciones y las exenciones. [7] Una desviación es una autorización (o una solicitud para ello) para apartarse de un requisito de un artículo, antes de su creación. 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 de solicitudes de cambio minimalista (es decir, sin una solución real al problema en cuestión).
Ejemplos de
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 una nueva funcionalidad de sus programas de software, lo que conduce a una solicitud de cambio . El software del producto empresa, entonces se ve en la viabilidad técnica y económica de implementar este cambio y por lo tanto se decide si el cambio realmente se dio cuenta. 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 haga que también cambien otros fragmentos de código. Una vez que los resultados de la prueba inicial 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 en la forma en que se trata aquí es el dominio de fabricación . Tomemos, por ejemplo, el diseño y la producción de un automóvil . Si, por ejemplo, se descubre que las bolsas de aire del vehículo se llenan automáticamente de aire después de conducir largas distancias, esto sin duda dará lugar a quejas de los clientes (o, con suerte, 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, se debe realizar un análisis de costos y beneficios, probablemente simplista, después del cual se puede aprobar la solicitud de cambio. Después de un análisis del impacto en el diseño del automóvil y los programas de producción, se puede crear la planificación para la implementación del cambio. De acuerdo con esta planificación, el cambio realmente se puede realizar, después de lo cual se espera que la nueva versión del automóvil se pruebe a fondo antes de su lanzamiento al público.
En plantas industriales
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 instalaciones y procesos industriales es fundamental para la seguridad. 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 de cambios o MOC. Es solo uno de los muchos componentes de la Gestión de la seguridad de los procesos , sección 1910.119 (l) .1
Ver también
- Cambio de control
- Gestión de solicitudes de cambio
- Orden de cambio de ingeniería , solicitud de cambio
- PRINCE2
- ITIL
- Control de versiones
- Gestión de la liberación
- Ciclo de vida de la versión de software
- Gestión del ciclo de vida de las aplicaciones
- Ingeniería de Sistemas
- Sistema de seguimiento de problemas
Referencias
- ^ Crnkovic, Asklund y Persson-Dahlqvist, 2003
- ^ Dennis, Wixom y Tegarden, 2002.
- ^ Hinley, 1996.
- ^ Huang y Mak, 1999.
- ^ a b En realidad, para obtener una SOLICITUD DE CAMBIO no tienen que ocurrir tanto Requerir nueva funcionalidad como un problema de Encuentro ; por lo general, solo uno de los dos lo hará. Modelarlos como actividades desordenadas se aproxima aproximadamente a este significado; una alternativa sería crear dos 'puntos de partida' separados (es decir, estados iniciales), ambos apuntando a Solicitar cambio.
- ^ Weerd 2006
- ^ Scott y Nisse, 2001.
Otras lecturas
- Crnković I., Asklund, U. y Persson-Dahlqvist, A. (2003). Implementación e integración de la gestión de datos del producto y la gestión de la configuración del software . Londres: Artech House.
- Dennis, A., Wixom, BH y Tegarden, D. (2002). Análisis y diseño de sistemas: un enfoque orientado a objetos con UML . Hoboken, Nueva York: John Wiley & Sons, Inc.
- Universidad de Georgetown (nd). Almacén de datos: Glosario . Consultado el 13 de abril de 2006 en: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html .
- Hinley, DS (1996). Gestión de la evolución del software: una perspectiva orientada a procesos. Tecnología de la información y el software, 38 , 723-730.
- Huang, GH y Mak, KL (1999). Prácticas actuales de gestión de cambios de ingeniería en las industrias manufactureras del Reino Unido. Revista internacional de gestión de operaciones y producción, 19 (1), 21-37.
- IEEE (1991). Glosario estándar de terminología de ingeniería de software (ANSI) . The Institute of Electrical and Electronics Engineers Inc. Consultado el 13 de abril de 2006 en: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6 .
- Mäkäräinen, M. (2000). Procesos de gestión de cambios de software en el desarrollo de software embebido . Tesis doctoral. Espoo: Publicaciones de VTT. Disponible en línea: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf .
- NASA (2005). Programa de datos de métricas de instalaciones IV&V de la NASA: glosario y definiciones . Consultado el 4 de marzo de 2006 en: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html .
- Bibliotecas de la Universidad Estatal de Pensilvania (2004). Manual CCL: Glosario de términos y acrónimos . Consultado el 13 de abril de 2006 en: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/ cataloging / ccl / glossary.htm.
- Universidad de Princeton (2003). WordNet 2.0 . Consultado el 13 de abril de 2006 en: http://dictionary.reference.com/search?q=release .
- Rajlich, V. (1999). Cambio y evolución de software. En Pavelka, J., Tel, G. & Bartošek, M. (Eds.), SOFSEM'99, Lecture Notes in Computer Science 1725 , 189-202.
- Rigby, K. (2003). Normas de gestión: Glosario de términos . Consultado el 1 de abril de 2006 en: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm .
- Scott, JA y Nisse, D. (2001). Gestión de la configuración de software, Guía del cuerpo de conocimientos de ingeniería de software , Capítulo 7, IEEE Computer Society Press.
- Vogl, G. (2004). Sistemas de información gerencial: Glosario de términos . Obtenido el 13 de abril de 2006 del sitio web de Uganda Martyrs University: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm .
- Weerd, I. van de (2006). Técnica de Metamodelado: Anteproyecto de la asignatura Ingeniería de Métodos 05/06 . Consultado el 1 de marzo de 2006 en: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions [ enlace muerto permanente ] para el diagrama de datos de proceso.pdf [acceso restringido].