Ciencias de la computación y telecomunicaciones

Artículo de investigación  

                                                                                 

 

Guía para la anticipación y prevención de errores en procesos empresariales al efectuar cambios en sistemas informáticos. Caso de estudio: ETAPA EP

Guide for the anticipation and prevention of errors in business process to effectuate changes in computer systems. Study case: ETAPA EP

Guia para a antecipação e prevenção de erros nos processos de negócios ao fazer alterações nos sistemas de computadores. Estudo de caso: EP STAGE

 

Pablo Esteban Cazorla-Matute ^I

pcazorla@yahoo.com

Carlos Enrique Encalada-Loja ^II

cencalada@ucacue.edu.ec

 

 

Correspondencia: pcazorla@yahoo.com

 

 

 

          ^I.            Magíster en Tecnologías de la Información, Ingeniero de Sistemas, Jefatura de Posgrados, Universidad Católica de Cuenca, Cuenca, Ecuador.

        ^II.            Ingeniero en Sistemas, Docente de la Unidad Académica de Tecnologías de la Información, Jefatura de Posgrados, Universidad Católica de Cuenca, Cuenca, Ecuador.

 

 

 

Resumen

En las entidades públicas, específicamente ETAPA EP, se tienen automatizados, total o parcialmente, sus procesos de negocio, con los cuales se realizan las transacciones para los productos que ofertan.

Las aplicaciones informáticas desarrolladas para el efecto requieren la realización de cambios de forma frecuente, incluso de forma urgente, debido a las necesidades propias del negocio o de la organización. La ejecución de estos cambios con la relativa urgencia, con la que se le impone al área de tecnología, acarrea la presencia de errores o resultados no deseados en el o los sistemas informáticos.

Se demuestra esta problemática mediante la descripción de un caso específico, la aplicación de un nuevo valor para el impuesto IVA dispuesto por ley en el país, luego de la implementación correspondiente en el sistema informático, se recopila la información de los errores reportados como incidentes e incluso otros cambios necesarios para solventar los inconvenientes que se presentaron.

En base a esto y al marco de referencia con el que el área de tecnología desarrolla sus actividades, el presente artículo presenta una guía que procura dar una pauta de actividades a ser realizadas previo a la modificación en el sistema informático, y en la entrega o publicación, buscando la disminución de la incidencia posterior, basándose en aspectos como: el o los stakeholder(s), áreas y procesos de negocio involucrados, recopilación de documentación, etc. Teniendo como referencia el proceso de mantenimiento de software del estándar IEEE 1219.

Palabras clave: Requerimiento de cambio; errores o incidentes; prevención; proceso de negocio; guía; stakeholder; documentación.  

Abstract

In public entities, specifically ETAPA EP, their business processes are fully or partially automated, with which transactions are made for the products they offer.

Computer applications developed for this purpose require changes to be made frequently, even urgently, due to the needs of the business or the organization. The execution of these changes with relative urgency, with which it is imposed on the technology area, leads to the presence of errors or unwanted results in the computer system (s).

This problem is demonstrated by describing a specific case, the application of a new value for the VAT tax provided by law in the country, after the corresponding implementation in the computer system, the information of the errors reported as incidents is collected and even other changes necessary to solve the problems that arose.

Based on this and the frame of reference with which the technology area develops its activities, this article presents a guide that seeks to give a guideline of activities to be carried out prior to the modification in the computer system, and in the delivery or publication, seeking the reduction of the subsequent incidence, based on aspects such as: the stakeholder (s), areas and business processes involved, documentation collection, etc. Having as reference the software maintenance process of the IEEE 1219 standard.

Keywords: Change requirement; errors or incidents; prevention; business process; guide; stakeholder; documentation.

Resumo

Em entidades públicas, especificamente na ETAPA EP, seus processos de negócios são total ou parcialmente automatizados, com os quais são feitas transações para os produtos que eles oferecem.

Os aplicativos de computador desenvolvidos para esse fim exigem que as alterações sejam feitas com frequência, até mesmo com urgência, devido às necessidades da empresa ou da organização. A execução dessas mudanças com relativa urgência, com a qual é imposta na área de tecnologia, leva à presença de erros ou resultados indesejados no (s) sistema (s) de computador.

Este problema é demonstrado, descrevendo um caso específico, a aplicação de um novo valor para o imposto IVA previsto por lei no país, após a correspondente implementação no sistema informático, a informação dos erros relatados como incidentes é recolhida e até mesmo outras mudanças necessárias para resolver os problemas que surgiram.

Com base nisso e no referencial com o qual a área de tecnologia desenvolve suas atividades, este artigo apresenta um guia que busca orientar as atividades a serem realizadas antes da modificação no sistema de informática e na entrega ou publicação, buscando a redução da incidência subseqüente, baseada em aspectos como: o (s) stakeholder (s), áreas e processos de negócio envolvidos, coleta de documentação, etc. Tendo como referência o processo de manutenção de software do padrão IEEE 1219.

Palavras chaves: Requisito de mudança; erros ou incidentes; prevenção; processo de negócios; guia; stakeholder; documentação

Introducción

Las organizaciones deben mantenerse al día en el entorno en el cual sus actividades o su giro de negocio, así lo imponen, debiendo con mucha frecuencia, efectuar modificaciones en el software con los que gestionan sus procesos (Serna Montoya, 2010).

En las entidades públicas, cuyos procesos de negocio se encuentran automatizados total o parcialmente, y cuyo mantenimiento o nuevos desarrollos se efectúan con un área de tecnología que pertenece a la entidad, se tiene que, por múltiples factores, ya sea internos o externos, las entregas deben realizarse de manera rápida o con carácter de urgente, omitiéndose fases de pruebas o comprobaciones que un producto de software requiere, teniendo como consecuencia que se presenten errores o incidentes, que el mantenimiento sea complejo o se afecten otros procesos de negocio e incluso nuevas solicitudes de cambio para remediar los problemas encontrados.

Estos errores se producen generalmente por desconocimiento de los procesos de negocio o reglas de negocio. Estas reglas o conjuntos de reglas de negocio están embebidas en procesos, sistemas informáticos, reglamentación, etc., y permiten que la organización funcione, en las condiciones que la misma organización establece (Contreras Baez & Bolanos Rodriguez, 2011). Tanto de los funcionarios que hacen el requerimiento, como de quienes lo implementan (área de tecnología), ya que, si bien el cambio en el área que lo solicita se da con aparente éxito, se producen inconvenientes en procesos subsecuentes, que producen retrasos en las operaciones.

Con la premura que con frecuencia se deben atender estos requerimientos de cambio, se pueden también presentar, errores de programación, de la lógica que se busca implementar, ya que, al no tener un conjunto de pruebas efectivas, no se pueden detectar a tiempo estos fallos.

La realización de cambios efectuados en un módulo o componente de un sistema o aplicación tiende a presentar afectaciones en otros módulos como una especie de efecto dominó o Ripple (Bennett, 2008). En la fase de análisis, como parte del proceso de mantenimiento de software descrito, se determina el impacto del cambio en el sistema que se encuentra en operación. Con los insumos adecuados, como documentación, se pueden identificar los programas afectados y los no afectados. Una traza de referencias permite identificar los módulos que sufrirían afectaciones por el cambio propuesto a nivel de código fuente, con la ayuda de las herramientas de desarrollo, identificando otras partes de código afectadas. Sin embargo, esta trazabilidad se puede realizar a otro nivel, como son otros módulos del sistema, arquitectura, manuales de configuración, además de documentación de diseño disponible y especificaciones de los requerimientos (Delplanque, 2017), dependiendo de los artefactos que se crean convenientes utilizar.

El problema científico planteado se fundamentó en si se requiere un marco de referencia para la elaboración de cambios en los sistemas informáticos de una empresa pública, en función a la afectación a los procesos empresariales que pueda producirse y al desarrollo como tal, es decir, la programación realizada y las pruebas ejecutadas para el efecto.

El objetivo del presente artículo se basó en elaborar una metodología o marco de referencia para comprobar la calidad de los entregables de la gestión de cambios o nuevos desarrollos de software y su impacto en los procesos empresariales, en el ámbito de una empresa pública.

Los resultados de este proyecto permiten proporcionar al personal, tanto del área de tecnología como de las áreas que gestionan el negocio de una empresa pública, una visión amplia de la afectación de los cambios que se implementan en los sistemas informáticos, que se utilizan en los procesos de negocio, y, prevenir la corrección de errores o cambios consecuentes; ya que se puede ahorrar el uso de recursos, tanto humanos como económicos, que pueden ser invertidos en nuevos desarrollos o solicitudes, que tenga el área tecnológica.

Adicionalmente, se podrá aportar con nuevos conceptos que buscan minimizar el impacto producido por la implementación de cambios en los sistemas informáticos, por ende, se pretende esquematizar la forma en que los entregables de estos cambios no produzcan incidencia (errores que produzcan detenciones en la operación), o tener que efectuarse nuevos cambios como consecuencia de un cambio anterior.

Desarrollo

La Subgerencia de Tecnologías de la Información de la empresa ETAPA EP, para su estructura tiene COBIT 5.0 como marco de referencia, basado en los procesos de gobierno y gestión, designándose a las áreas que componen la Subgerencia de Tecnologías de la Información la responsabilidad de la ejecución de actividades y cumplimiento de indicadores de gestión (mediciones), ver la tabla 1.

Tabla 1. Procesos COBIT 5.0 con áreas designadas STI

           

El proceso de gestión de cambios (BAI06 Gestionar los Cambios), que le corresponde al área de Sistemas en Producción, es la encargada de gestionar este tipo de requerimientos sobre los servicios que la STI, ofrece a la organización ETAPA EP.  De acuerdo con los procesos establecidos y aprobados en función del proceso del marco de referencia, los requerimientos de cambio o actualización se realizan de manera formal, mediante comunicación dirigida a la Subgerencia de TI (memorando u oficio con firma de responsabilidad). Luego el requerimiento es asignado al área de Sistemas en Producción, para la gestión respectiva.

Tras la recepción del requerimiento, el responsable del área de Sistemas en Producción (persona encargada para esta actividad o puede conformarse un grupo de trabajo), efectúa la revisión y análisis, para determinar el alcance y tener una perspectiva inicial del impacto que tendrá el cambio solicitado. Con este análisis, se realiza una priorización para la atención efectiva del cambio a realizarse.

Una vez que se determina la atención del requerimiento, se asigna al o los analistas del área de Sistemas en Producción encargados de su realización, de acuerdo con la planificación y estimación, que la mencionada área efectúa, dentro de la metodología utilizada. En las figuras 1 y 2, se coloca el flujo del proceso gestión de cambios.

 

 

Figura 1. Proceso de Gestión de Cambios – STI (1)

 

 

 

 

 

Figura 2. Proceso Gestión de Cambios – STI (2)

Para la implementación correspondiente, se ha establecido el proceso BAI07, gestionar la Aceptación del Cambio y la Transición, incluyendo la publicación o puesta en producción, dependiendo del impacto del cambio, se tiene un período de seguimiento o una especie de despliegue, para una atención primaria en caso de que se presente algún incidente. El proceso mencionado, se muestra a continuación (figura 3), el procedimiento ejecutar pruebas de aceptación, para ilustrar la interacción con el usuario final para el requerimiento.

 

 

Figura 3. Procedimiento Ejecutar Pruebas de Aceptación

Como parte de la designación de procesos a las áreas de la Subgerencia de TI, el soporte informático le corresponde a Infraestructura y Soporte, que recibe o se comunica con los usuarios finales de los sistemas informáticos, que, en caso de presentarse un inconveniente para la utilización o funcionamiento en alguna funcionalidad, ingresando un ticket o un denominado incidente, en el sistema de gestión que se utiliza para el seguimiento de estas actividades.

Para un incidente reportado, se analiza y se identifica la causa que lo origina, para solventar el inconveniente. Si se tiene que efectuar un cambio mayor o mantenimiento a la funcionalidad que presenta el error, se escala al área de Sistemas en Producción, para en base al incidente o reporte, efectuar el cambio o cambios pertinentes. Esta atención se realiza con carácter prioritario, ya que se debe solventar un problema que se tiene en el sistema informático.

La cantidad de incidencia presentada, luego de efectuar cambios en los sistemas informáticos, es importante, la misma que se observa una vez que se publica la implementación realizada. Para esto, se ha recopilado información del sistema en el cual se gestionan los procesos de la Subgerencia de Tecnologías de la Información, específicamente de los registros de incidentes producidos por efectos de un cambio, se ha tomado como rango de tiempo desde el 1 de octubre de 2016 hasta el 30 de septiembre de 2018, como se muestra en la figura 4, a continuación: 

Figura 4. Nro. Incidentes por Cambios Fuente: Sistema Gestión Procesos TI

En promedio se tienen 17 incidentes mensuales de esta índole, representando un inconveniente importante para el área de tecnología, ya que estos deben ser solventados con la prioridad que amerita, ya que incluso puede presentarse una detención en la operación.

De lo mencionado en los párrafos anteriores, a continuación, se describe una situación existente, con la que se pretende describir lo que ocurre cuando se presenta una solicitud de cambio en una aplicación en un módulo importante y las afectaciones producidas.

Se remite al área de Tecnología un requerimiento en el cual se solicita aplicar una ley que impone el cambio del porcentaje del impuesto IVA, vigente en el país, figura 5.

Figura 5. Requerimiento Emergente

 

 

 

 

 

 

 

 

 

 

 

Adicionalmente se presenta un formulario, que forma parte de la gestión de cambios, en el cual se detalla el requerimiento, figura 6.

Figura 6. Formulario Cambio de Aplicación

Con estos documentos, se realiza la implementación, con el desarrollo y pruebas en el plazo disponible, como se puede observar el requerimiento en sí, es escueto y sin detalle de los módulos o sistemas en los que se debe intervenir.

Luego de la publicación o puesta en producción de los cambios efectuados en los módulos respectivos, con la debida aceptación y conformidad de los usuarios requirentes, se presenta varios incidentes, al tratarse de la emisión de valores que se realiza en las diferentes áreas por diversas índoles, en un total de 12 incidentes.

En el mismo contexto, se tienen nuevos requerimientos de las áreas de la organización, para remediar o adaptar sus procesos, como se observa en la tabla 2.

 

Tabla 2. Solicitudes de Cambio luego de realizar la publicación

 

Esta situación, incluyendo tanto incidentes como solicitudes de cambio, traen como consecuencia:

-           Usuarios finales del sistema informático desinformados, quienes consultan a soporte informático sobre el cambio o reportan fallos, reales como supuestos.

-           Interfaces con detalles incompletos, ya que las leyendas y/o datos mostrados no contemplan la situación actual, producida por el cambio realizado.

-           Procesos consecuentes con datos de entrada con modificaciones, por ende, sus salidas tendrán valores a ser evaluados y/o corregidos.

-           Posibles retrasos en la entrega de reportes para instancias internas de la empresa y organismos externos.

Para solventar los puntos indicados las áreas de soporte y desarrollo, debe asignar su personal a las actividades que se generan, que en algunos casos es de carácter urgente su atención.

Se produce un efecto negativo, ya que esta situación incide en volver a realizar las tareas ya ejecutadas, teniendo el personal que laborar en horario extendido, y la imagen de la Subgerencia de TI se vea afectada ante el resto de la empresa.

 

Metodología

Para el desarrollo de la presente investigación se aplicó un enfoque inductivo – deductivo, aplicado para generar una respuesta particular al problema, para luego generalizarlo.

El estudio se realizó en el contexto de una empresa pública, en este caso de ETAPA EP, y el ámbito de sus procesos de negocio, que han sido automatizados mediante sistemas informáticos, por lo que el tamaño de la muestra corresponde a este mismo universo de estudio.

Resultados

En el contexto de los procesos establecidos para la gestión de cambios y la transición y aceptación del cambio (basados en el marco de referencia COBIT 5.0) en el área de tecnología de la empresa ETAPA EP, se realiza la presente propuesta como una guía para la atención de un cambio que se debe realizar en los sistemas informáticos que se encuentran en operación.

El principal obstáculo que se tiene en la realidad actual de la empresa ETAPA EP es la no consolidación de los procesos de negocio mediante un manual o documento de procesos debidamente establecido, con la aprobación y sobre todo la aplicación por parte de las áreas de la organización, a su vez, esto conlleva que la automatización de los procesos o parte de ellos, por parte del área tecnológica, no tenga una perspectiva o traza completa, ya que la ausencia indicada de procesos no permite determinar las entradas y peor aún los efectos de las salidas del proceso que está siendo afectado por el requerimiento de cambio, de forma clara y concreta, impidiendo tener un verdadero dimensionamiento del impacto que produciría el cambio, y de igual manera una estimación y recursos necesarios para la implementación a realizarse.

Esto se produce realizando el lanzamiento o publicación del producto del cambio realizado, acarreando de forma inmediata o a corto e incluso mediano plazo, la presencia de incidencias ya sea por errores, desconocimiento de los usuarios finales o afectaciones no consideradas en otras instancias o procesos subsecuentes.

Resulta, por tanto, imprescindible determinar en una etapa temprana de este tipo de implementaciones, las implicaciones del requerimiento a ser atendido, es decir, el alcance e impacto en el o los procesos de negocio, y con estos insumos, determinar el costo del cambio (tiempo y recursos), incluyendo la estrategia de pruebas y la documentación que debe ser realizada y analizada.

Para esta guía se toma como referencia el proceso de mantenimiento de software del estándar (IEEE 1219, 1998), en las fases de:

-           Identificación del cambio

-           Análisis

-           Aceptación

-           Entrega

Objetivo

La presente guía procura dar una pauta para los encargados de la gestión de cambios o de implementar actualizaciones en módulos o sistemas, de los pasos o actividades a ser realizadas previo a la realización de la modificación en el sistema informático, así como en la entrega o publicación, buscando la disminución de la incidencia posterior.

•           Identificación del cambio

Luego de la recepción del requerimiento, se debe verificar si el funcionario que realiza la petición tiene la autorización del área a la que pertenece. La Subgerencia de TI solicitó a los diferentes departamentos de la organización las personas autorizadas a efectuar requerimientos, de no estar en el listado, se rechazaría la solicitud.

Si posee la mencionada autorización, el o los funcionarios(s) se convierte(n) en el principal stakeholder(s) del requerimiento del cambio, por lo cual se debe procurar su compromiso, ya que se tiene la premisa de que tiene conocimiento del proceso de negocio y a detalle el cambio solicitado.

Con el stakeholder plenamente identificado, se debe determinar el o las áreas de negocio que son afectadas en sus procesos bajo su responsabilidad, coordinando las acciones con las implicaciones que tendrían, ejecución de pruebas o simplemente teniendo conocimiento del cambio. En este punto es de fundamental importancia la experiencia del equipo de gestión de cambios, ya que debe procurar en conjunto con el stakeholder, hacer una traza del efecto que tendrá la realización del cambio en los procesos, tanto el directamente afectado como en los que se están alrededor, especialmente los subsecuentes, esto con la finalidad de determinar el alcance e impacto, que implicaría inclusive en un rechazo del cambio, logrando una validación del requerimiento.

El conocimiento en el ámbito del negocio y del sistema tanto de los stakeholders, como del equipo asignado por parte del área tecnológica (en caso de sistemas que se encuentren en operación) contribuye en forma preponderante en el éxito ya sea de un proyecto de desarrollo de software (Hofmann & Lehner, 2016) , así como en el mantenimiento de aplicaciones en operación,.

De ser factible, efectuar un diagrama de flujo, con datos relevantes de la(s) entrada(s) del proceso sobre el cual impacta el cambio directamente, para identificar la(s) salida(s) y visibilizar los procesos posteriores y que su(s) entrada(s) tendría modificaciones. Como documento habilitante y resultado de este análisis se puede conformar un acta, con los acuerdos a los que se llegue con las firmas correspondientes.

Otro aspecto importante es la recopilación de documentación existente de la funcionalidad involucrada en el cambio, tanto de índole técnico como para usuarios finales, ya que esta debe ser actualizada, si es el caso. En esta documentación se puede detectar aspectos importantes de la implementación a ser realizada. Si la documentación no existe, su elaboración debe formar parte de la atención del cambio, por lo menos cubriendo el alcance determinado.

Esta evaluación permitirá al equipo de gestión de cambios, efectuar una estimación inicial de tiempo y recursos necesarios para la atención del cambio, además de la priorización, en relación con otras solicitudes de cambio pendientes, provenientes de las diferentes áreas de la organización.

Como resultado de esta fase se tiene una planilla en la cual se registra la información obtenida, con el resultado de este análisis, que servirá como referencia para futuras solicitudes de cambio, como se observa en la figura 7.

 

 

 

 

 

 

Figura 7. Plantilla de Evaluación Requerimiento

•           Análisis del Requerimiento

Con el insumo de la identificación del requerimiento, se puede tener una mejor perspectiva del cambio desde el punto de vista técnico, ya que se pueden considerar aspectos adicionales, entre otros, la documentación del sistema, realizar la actualización respectiva o incluso su elaboración.

La determinación del tipo de pruebas que se deben realizar como parte de la implementación, muestra que estas pueden ser unitarias, íntegras, de estrés, desempeño, integración, etc. Es importante mencionar que, si no se efectúa la o las pruebas adecuadas, se puede presentar otro tipo de incidencia, como un bajo desempeño, o la presencia de errores y desconocimiento de los usuarios finales de la funcionalidad. Por lo tanto, el involucramiento del o los stakeholder(s) en la realización de pruebas del desarrollo realizado permitirá identificar aspectos que requieren ser ajustados, a más del resultado que se busca obtener del cambio, previniendo incidencias como la indicada.

Como resultado de esta fase se pueden determinar los recursos necesarios para la implementación como tal, además de la participación comprometida de los stakeholder(s) identificado(s), el plan de pruebas, el tipo de pruebas necesarias, y tener una estimación aproximada del tiempo que tomará la atención del cambio a ser atendido.

•           Aceptación del Cambio

Luego de que culmine la fase de desarrollo, y de acuerdo con el plan de pruebas establecido, se deben ejecutar las pruebas determinadas en el ambiente que se tenga disponible, registrando en el documento pertinente a los resultados obtenidos, y de igual manera la o las pruebas en las que intervengan el(los) stakeholder(s). En el caso de que los resultados no sean los esperados, se deben realizar los ajustes necesarios en la aplicación modificada, y ejecutar nuevamente la o las pruebas que no tuvieron resultados exitosos.

Los registros de las pruebas realizadas deben ser validados por los usuarios solicitantes para que se constante la consecución del objetivo por el cual se hizo el cambio en la aplicación, así como de las pruebas adicionales efectuadas. quedando así, por lo menos en conocimiento de las partes involucradas en la gestión del cambio, el alcance e impacto que conllevó la ejecución de la actualización de la aplicación previo a su publicación (puesta en producción). Estos documentos pueden ser revisados también por otras instancias del área tecnológica para que de igual manera se verifique que se han realizado las pruebas pertinentes como parte de la implementación.

Adicionalmente se debe verificar que la documentación del sistema o aplicación, tanto técnico como de usuario, tenga la actualización requerida, o en el caso de que no exista, la elaboración de esta en el ámbito del cambio requerido.

A continuación, en la tabla 3, se muestra el esquema, con el cual se obtendrá la validación por parte de los actores principales en el desarrollo del cambio, estos son: stakeholders, desarrollador(es), operador – soporte.

           

Tabla 3. Casos de Prueba. RFC-HU1. Denominación/Título del Requerimiento
Descripción		Fecha		*Requerimientos de Ambiente de Pruebas	Dependencias con otros casos de Prueba	Datos / Acciones de Entrada	Resultado Esperado (datos o acciones)	Resultado Obtenido (datos o acciones)	Tipo de Error
Descripción del caso de prueba 01									Ninguno
Descripción del caso de prueba 02									Ninguno

             

 

 

 

 

 

 

                                                                                                 

·         Aprobaciones de casos de prueba Los usuarios expertos (stakeholders), el analista de operación y soporte y el desarrollador asignado por TI validan la correcta ejecución de los presentes casos de prueba, como se observa en la tabla 4.   Tabla 4. Casos de prueba para aceptación del cambio por parte de las partes
Nombre		Cargo			Área	Fecha	Firma
Stakeholder 1		Cargo del funcionario			Departamento donde labora
Stakeholder 2		Cargo del funcionario			Departamento donde labora
Funcionario Desarrolla		Desarrollo de Software			Desarrollo
Funcionario Operación - Soporte		Cargo Operación - Soporte			Operación

Una vez aprobados los casos de pruebas, tabla 5, los cambios realizados se implementarán en ambiente de producción y estarán disponibles para los usuarios. Cualquier inconveniente que se presente se deberá reportar a soporte TI por cualquiera de los canales establecidos.

 

 

 

 

 

 

 

 

 

 

 

Tabla 5. Aceptación del cambio para el área tecnológica

ACEPTACIÓN DEL CAMBIO
RFC
Documentación
Proceso de Negocio:
Documentación Creada		(S/N)		Documentación Actualizada		(S/N)
Archivo de Documentación Actualizado
Pruebas Realizadas
Tipo			Resultado
Unitarias		(S/N)
Íntegras		(S/N)
Integración		(S/N)
Desempeño		(S/N)
Estrés		(S/N)
Otras:
Observaciones – Comentarios
Revisión – Aceptación
Supervisor de Desarrollo		Desarrollador(es)			Operación - Soporte

 

Entrega del Cambio

Con la aceptación de parte de las partes interesadas e involucradas, que formaron parte de la atención del cambio mediante las pruebas de aceptación debidamente validadas (firmas de conformidad), se procede a la publicación de la aplicación actualizada.

Se debe efectuar la comunicación a los usuarios del sistema informático, al área de soporte, de ser el caso, realizar la capacitación respectiva al o los usuarios.

Dependiendo del alcance o complejidad de la implementación realizada, es conveniente realizar un período de seguimiento o monitoreo luego de la publicación de la aplicación actualizada, por parte de los funcionarios asignados a la atención del cambio en el sistema informático, esto con la finalidad de dar atención de manera inmediata, en caso de presentarse algún inconveniente, como un reporte de errores o interrupción en el sistema informático, teniendo incluso, de ser el caso, que retornar a la aplicación en su versión anterior al cambio efectuado, para que la operación se reanude. Este período se lo puede denominar como de despliegue.

Es importante indicar que la adición de algunos de los pasos descritos puede provocar un aumento del tiempo que toma la ejecución de las fases en la actualidad, o a su vez realizar actividades que no se las realiza. Si bien esto representaría un costo adicional para la gestión del cambio, en cuanto al factor tiempo, pero repercutiría en la estabilidad de las aplicaciones luego de las actualizaciones que se publican.

Conclusiones

La realización de un cambio en un sistema informático impacta en los módulos o programas que intervienen en los procesos de negocio, tanto en el que es afectado directamente como los relacionados, como se pudo determinar en el caso de estudio presentado. Si las afectaciones no son claramente reconocidas, se produce una fuente de errores (incidencia) en los aplicativos, los que deben ser atendidos en forma prioritaria o emergente, ocasionando que el área de tecnología tenga que dedicar recursos para solventarlos. Esta situación se torna frecuente si no se tienen los insumos que permitirían evitarla, como sería un manual o mapa de procesos, participación de usuarios expertos, así como de documentación de la aplicación informática correspondiente.

La guía presentada en el presente trabajo busca en el contexto de un cambio en el sistema informático, minimizar el impacto negativo en los sistemas informáticos relacionados. El identificar los procesos adyacentes (precedente y consecuente) al involucrado en el cambio, en la fase de análisis permite encontrar afectaciones o consideraciones a tener en cuenta en el momento de la implementación del cambio. La participación y aporte del o los stakeholders (partes interesadas) es de suma importancia, ya que, como usuario experto del proceso de negocio, se visibiliza aspectos no descritos directamente en la solicitud del cambio informático. Aunque sea escasa en existencia o en su contenido, la documentación (técnica o manuales) disponible acerca de la funcionalidad a ser afectada en el cambio, debe ser revisada y analizada para que, de igual manera a lo indicado, se establezcan aspectos a ser considerados en el desarrollo a ejecutarse. Esta documentación debe ser actualizada o elaborada como parte del cambio.

Las actividades adicionales a realizarse producto de la utilización de la guía presentada pueden aumentar, en la mayoría de los casos, el tiempo que toma en promedio la implementación de un requerimiento de cambio, sin embargo, los recursos y por ende el tiempo, que se utilizarían en solventar los errores presentados, es mayor. Esto representa una optimización en el uso de los recursos que dispone el área de tecnología de la entidad.

La disminución de los errores presentados como efecto de la realización de un cambio, al aplicarse la guía presentada requiere la realización de un seguimiento por un lapso prolongado, cuya recopilación, análisis y resultados se realizarán en un trabajo subsiguiente.

Referencias Bibliográficas

Bennett, K. H. (2008). SOFTWARE MAINTENANCE : A TUTORIAL.

Contreras Baez, C., & Bolanos Rodriguez, H. (2011). MÉTODO PARA LA EXTRACCIÓN DE REGLAS DE NEGOCIO APLICADOS A CASOS DE USO EN PROCESOS EMPRESARIALES.

Delplanque, J. (2017). Analysis model Proposition and evaluation of a software Change Impact Analysis model.

Hofmann, H. F. (General M., & Lehner, F. (University of R. (2016). Requirements Engineering as a Success Factor in Software Projects, (August). https://doi.org/10.1109/MS.2001.936219

IEEE 1219, S. E. S. C. of the. (1998). IEEE Standard for Software Maintenance (Vol. 1219).

Serna Montoya, E. (2010). Acercamiento ontológico a la gestión del conocimiento en el mantenimiento del software. Rev. Fac. Ing. Univ. Antioquia, 184–193.