Revista Boliviana de Ingeniería
No. 2 | Volumen 1 | Julio – diciembre 2019
Página 125 - 147
ISSN: 2710 – 0901 | ISNN-L: 2710 – 0901
https://doi.org/10.33996/rebi.v1i2.194
Sistema automatizado para la gestión y control de requerimientos de soporte técnico
An automated system for requirements management and control technical support
Daniel Garófalo
garofalodaniel@gmail.com
Código ORCID: 0000-0001-6313-9382
Universidad Alejandro de Humboldt, Venezuela
Articulo recibido en enero 2019
Arbitrado en febrero 2019
Publicado en julio 2019
Resumen
En algunas empresas, las actividades de control de incidencias de los requerimientos de los usuarios de equipos informáticos se llevaban en forma manual. Este método generaba retraso y lentitud en el registro, control y seguimiento de los incidentes, además del extravío de anotaciones debido a problemas de seguridad en el acceso a los datos, sin respaldo inmediato. En consecuencia, se diseñó para la empresa un sistema pionero capaz de registrar y controlar los diferentes requerimientos, ahorrar tiempo y realizar las tareas de manera rápida, sencilla, eficaz, además de proporcionar seguridad y respaldo. El trabajo se llevó a cabo bajo la modalidad de proyecto factible, con una muestra significativa y una aplicación exitosa en una empresa venezolana de distribución y manejo de géneros farmacéuticos. Se presenta el diseño y un ejemplo de generación de información en la historia de la creación de software. Se concluye con el cumplimiento cabal del propósito.
Palabras clave: Sistemas de control y registro, ambiente web, ingeniería informática, aplicación de software
Abstract
In some companies, the incident control activities of the users' computer equipment requirements were carried out manually. This method generated delay and slowness in the registration, control and monitoring of the incidents, in addition to the loss of annotations due to security problems in the access to the data, without immediate support. Consequently, a pioneer system designed to record and control the different requirements, save time and perform tasks quickly, easily, efficiently, as well as providing security and support, was designed for the company. The work was carried out under the feasible project modality, with a significant sample and a successful application in a Venezuelan pharmaceutical distribution and management company. The design and an example of information generation in the history of software creation are presented. It concludes with the full fulfillment of the purpose.
Keywords: Control and registration systems, web environment, computer engineering, software application
INTRODUCCIÓN
La informática es una herramienta empleada en todo el mundo por toda clase de empresas. La tecnología actual y la informática han ayudado a acrecentar la eficiencia y eficacia de las industrias, ofreciendo seguridad y rapidez en el manejo de la información. Para desarrollar un sistema, es necesario el estudio metódico de toda la información recabada mediante la investigación y el análisis: levantamiento cabal de la información para ofrecer una solución confiable a los problemas encontrados, además de satisfacer las necesidades y requerimientos de los usuarios del sistema en desarrollo.
La administración consiste en la coordinación de todos los recursos a través de los procesos de planificación, ordenación, orientación y control en función de conseguir los objetivos establecidos (Stoner, Freeman y Gilbert, 1996). Es la actividad que, bien ejercida y con las herramientas apropiadas, es factor fundamental en la realización de cualquier empresa y que, además, es vital en las actividades de las industrias pequeñas y medianas.
La necesidad de proveer a las empresas emergentes de un sistema automatizado que registre y controle y actualice los requerimientos de soporte técnico a usuarios de sistemas informáticos ha ido creciendo desde hace décadas, debido a la dependencia de los equipos y software empleados que permiten el manejo de grandes volúmenes de información para el negocio de la empresa, y que crece cada día más (Howard, 2003). Se han necesitado sistemas que puedan llevar el registro, control y actualización de todos los requerimientos de soporte técnico efectuados por los equipos informáticos. Este sistema, en particular, fue aplicado para incrementar el rendimiento y la productividad del personal que labora en el área de Soporte Técnico, aumentando la seguridad de la información y respuesta rápida a las solicitudes de servicio, realizadas por los trabajadores de la empresa. En su momento, fue sumamente importante para el personal que se encontraba en el campo, poder a través de sus teléfonos –sin el proceso de efectuar una llamada- utilizar un vínculo web, colocar la incidencia, recibir la respuesta del servidor y que se registrara directamente en el módulo web en tiempo real, del lado del Administrador.
En el departamento de Sistemas de Información de la empresa vinculada con el mercado farmacéutico y de salud implicada en la propuesta, específicamente en el área de Análisis de Soporte, se llevaba a cabo todo el procesamiento de requerimientos de soporte técnico por parte de usuarios de equipos informáticos y el registro y manejo de base de conocimientos que las operaciones ligadas a estas actividades proveen. Dentro de las principales actividades del Analista de Soporte asignado a esta área están la ejecución de cualquier medida basada en las decisiones tomadas por la Gerencia de Sistemas y el procesamiento de reportes o requerimientos hechos por los usuarios finales de equipos informáticos; equipos que la empresa otorga para la realización de actividades laborales por parte del personal dentro y fuera de las instalaciones.
Debido al procesamiento en forma manual se presentaban fallas, errores o incongruencias en los datos utilizados para el registro y control de la información básica provista por el usuario al momento de la elaboración del reporte y en la información resultante del análisis, resolución y documentación de la falla. Este tipo de operaciones se gestionan a través de computadores, agendas pda, smartphones, sistemas de información y otros equipos electrónicos.
El reporte, registro y control de requerimientos de soporte técnico por parte de usuarios de equipos informáticos se llevaban a cabo de la siguiente manera: (a) si el usuario final percibía alguna falla o desajuste en alguno de sus equipos informáticos asignados, procedía a reportar la dificultad a través de una llamada telefónica o a través de un correo enviado directamente al área de Análisis de Soporte, al analista de guardia; (b) si el reporte llegaba a través de una llamada telefónica se debía llenar el formato en Microsoft Excel con la fecha de realización de requerimiento, su identidad o nombre de usuario y una breve descripción de la falla; (c) si el reporte de la falla llegaba por correo electrónico se llenaba el formato con la información recibida en línea. Esto provocaba retrasos innecesarios en la realización de las actividades propias de cada una de las partes implicadas. De igual manera, no ofrecía un respaldo efectivo, moderno y ajustado a las altas demandas de operatividad en el tiempo, visto en los reclamos y quejas por parte de los usuarios finales por la poca velocidad y falta de precisión de aquellas tareas que deben ser llevadas a cabo por ambos implicados, sea el área de Análisis de Soporte o sea el usuario final.
Debe recordarse que la solución expedita en esos ámbitos es parte fundamental y crítica debido a la alta tasa de uso de sistemas computarizados. Una vez más, el acceso a documentación pública, estudios clínicos, Internet y telefonía está condicionado a la plataforma de red o intranet preestablecida en la empresa. Cualquier falla técnica, sea dentro del área de software, hardware o redes, implicaría un retraso en el desenvolvimiento de las actividades y operaciones del personal. Estas situaciones admiten un alto riesgo para el usuario final al no poder solventar o aclarar cualquier dificultad que esté presentando su plataforma tecnológica (Alcalde, 2001).
Los problemas se extienden desde la posible denegación de acceso a documentos públicos ubicados en la intranet de la empresa, falla del acceso telefónico para el personal que labora dentro y fuera de las instalaciones, posible pérdida de documentos personales o falla de acceso a la intranet e Internet, para el acceso a portales especializados de investigaciones clínicas y falla o demora en el reporte de visitas médicas por parte de los representantes de ventas.
Por otra parte, el Departamento de Sistemas de Información debe proveer servicios y soluciones de carácter tecnológico-informativo y acceso a documentación y redes (voz o datos) de manera confiable, continua y segura, por lo que requiere la constante documentación de fallas, contratiempos y fluctuaciones en la calidad de todos los servicios para los usuarios finales. Si no se tiene el sistema indicado sobrevendrían retrasos y complicaciones en la oferta de servicio y soporte, falla en el registro y documentación de los casos por atender y atendidos y fallas en el registro de información que pueda aumentar la base de conocimientos del área de soporte y que a su vez, suministre datos valiosos para solventar futuros inconvenientes a nivel técnico (Hamidian y Ospino, 2015). Otras desventajas del registro manual son el bajo nivel de seguridad para proteger los archivos informáticos y el nivel de acceso para restringir los cambios indeseados; la pérdida de los archivos de la base de conocimiento compilada, sin ningún respaldo físico actualizado y poca seguridad en el resguardo por la ausencia de claves de acceso a la información.
Este problema afectaba tanto a los usuarios finales, quienes debían trabajar con el uso de documentos (que puede ser de carácter médico, administrativo y de finanzas) y ofrecer soluciones en el área de negocios a todos los proveedores de servicios de laboratorio, como al personal médico asociado y otras sucursales de la empresa con quienes se intercambia información de todo tipo. Es un problema de envergadura, ya que todos los entes mencionados dependen de una administración eficiente y eficaz en el manejo de la documentación, información, servicios informáticos y electrónicos que son parte fundamental de la vida diaria, más aún en el área de negocios.
Por todas las razones expuestas, se propuso diseñar un sistema automatizado para el control, registro y actualización de requerimientos de soporte técnico efectuados por los usuarios de equipos informáticos. Con ello se analizaron previamente los registros, se establecieron la fundación y plan de elaboración arquitectónica del proyecto, se suministró una base para la eliminación de riesgos potenciales de carácter técnico mediante la construcción de una solución preliminar en forma de prototipo, se completó la funcionalidad del sistema mediante el estudio de los requisitos pendientes, administrando los cambios de acuerdo a las evaluaciones realizados por los usuarios y se aseguró que el software estuviera disponible para los usuarios finales, eliminando los errores y defectos encontrados en las pruebas de aceptación y asegurando la capacitación a los usuarios así como el soporte técnico.
Estévez (2008) afirma que este tipo de sistemas por su carácter de interactividad con el usuario sirve de soporte para cualquier tarea que tenga que ver con el adiestramiento del personal, solucionando las dificultades con la preparación de sus analistas. Asimismo, asume que la simplicidad y eficacia de este sistema lo dota de la suficiente flexibilidad para ser incorporado en otro sistema de información aún más complejo, como la incorporación de cursos u otros temas de interés con el que se vea beneficiado el personal.
También, Uzcátegui (2006) asevera que estos sistemas son eficientes en la disminución del fraude electrónico (sobre todo el bancario) mediante el seguimiento y control de reclamos hechos previamente por los usuarios y las posibilidades de confidencialidad debido a la alta sensibilidad de la información manejada por los diversos entes de una empresa. Por su parte, Escandón (2005) determinó la necesidad de mejorar los procesos con los que se llevan a cabo las solicitudes de equipos informáticos, tomando en cuenta la gran importancia de agilizar todos los procesos previamente descritos con la intención de mejorar la operatividad de toda organización.
Cuando se diseña un sistema debe planificarse, sustituirse o perfeccionarse el anterior lo que implica la clasificación e interpretación de los hechos, diagnóstico de problemas empleo de información y recomendación de mejoras en el sistema (Jacobson, Booch y Rumbaugh, 2000; Senn, 1998). Además, se deben examinar las bases de datos; construir los diagramas de ese flujo de datos respondiendo a cómo será la documentación del sistema y elaborar el diccionario de toda la información utilizada (Kendall y Kendall, 2005).
Se utilizó la Metodología RUP, un proceso complejo de ingeniería de software que provee un enfoque para asignar labores y compromisos dentro de una estructura de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible (Cardador, 2014). Tal como lo expresan Jakobson, Booch y Rumbaugh (2000) es una metodología de desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el manejo de la arquitectura. Las fases de inicio, elaboración, construcción y transición permiten el modelamiento, el desarrollo de bases, la aplicación de pruebas y la garantía de entrega del producto, respectivamente.
La ingeniería de software, finalmente, debe tener en cuenta ciertas bases legales sobre los delitos contra los sistemas que utilizan tecnologías. En la mayoría de los países existen disposiciones sobre la autorización a información, daño a los sistemas, la impericia o inobservancia de normas, la falsificación, el delito contra la propiedad y la privacidad de las personas, además de las multas y sanciones, civiles y penales que se pueden recibir.
MÉTODO
Con el propósito de alcanzar las mejoras señaladas se siguieron una serie de pasos para completar el diseño de un sistema automatizado de soporte técnico. De acuerdo con la naturaleza y características de problema objeto de estudio, esta investigación se enmarca dentro del nivel explicativo, en donde se analizaron las variables y los resultados se expresaron mediante hechos verificables.
El diseño utilizado es el del Proyecto Factible que consiste en “la investigación, elaboración y desarrollo de una propuesta o un modelo operativo viable para solucionar problemas, requerimientos o necesidades de organizaciones o grupos sociales; puede referirse a la formulación de políticas, programas, tecnologías, métodos o procesos” (UPEL, 2016, p. 16). El apoyo fue de tipo documental y de campo, debido a que se utilizaron los materiales para revisar la conceptualización, teorías y prácticas, por una parte, y, por la otra, se obtuvieron datos primarios en el de campo en forma directa de la realidad de la empresa.
La población estuvo conformada por 80 hombres y 100 mujeres (180 personas), entre los usuarios finales. En cuanto al personal de Área de Análisis de Soporte estaban comprendidos por 5 hombres y 5 mujeres (10 personas). La muestra de los usuarios finales, debido a la homogeneización del universo, se tomó al azar según la técnica de Arkin y Colton (1995), 10% de esa población: 8 hombres y 10 mujeres. La muestra de personal del Área de Análisis de Soporte estuvo constituida por toda la población finita e intencional, es decir todo el universo: los 5 hombres y las 5 mujeres que trabajan en el área.
Las técnicas de recolección de información fueron la encuesta, la observación y el análisis de documentos (UPEL, 2016). Los instrumentos para el levantamiento de información fueron dos cuestionarios cerrados que se aplicaron tanto a los usuarios finales como a los integrantes del departamento de Sistemas de Información, de forma separada y con diferentes preguntas cerradas. A través de la aplicación de esta herramienta, se logró obtener la información necesaria para la factibilidad y el desarrollo del nuevo sistema libre de las carencias del sistema antiguo usado en el área de Análisis de Soporte.
La validez y confiabilidad del estudio de estableció mediante la evaluación del cuestionario por juicio de cinco expertos y se aplicó a una muestra de 10 personas con características similares, lo que arrojó una validez de 0, 92. No fue necesario utilizar un grupo control debido a que la probabilidad de trabajar con usuarios y personal comporta pocas probabilidades de ausencias. Además, cada ítem se adecuó a la operacionalización de las variables (Tabla 1).
Tabla 1. Conceptualización de Variables
|
Objetivos |
Variable |
Definición |
|
Analizar los procesos y registros que se llevan a cabo en el sistema actual, para identificar sus interacciones, los riesgos y requerimientos básicos y detallados. |
Procesos y registros en el área de Análisis de Soporte del Departamento de Información. |
Procesos llevados a cabo para la recolección de datos de los requerimientos hechos por los usuarios y su posterior documentación pre y post resolución |
|
Establecer la fundación arquitectónica del proyecto, así como su plan de elaboración basándose en los requerimientos planteados |
Fundación arquitectónica del proyecto |
Desarrollo de la estructura básica del proyecto comenzando por el planteamiento de su infraestructura. |
|
Requerimientos planteados para su desarrollo |
Requerimientos como punto de partida para la elaboración del proyecto, que servirán como guía para la incorporación de la infraestructura y lógica necesaria para el proyecto |
|
|
Proveer una base para la eliminación de riesgos potenciales de carácter técnico para el proyecto mediante la construcción de una solución preliminar en forma de prototipo basándose en la arquitectura establecida |
Solución preliminar en forma de prototipo |
Diseño preliminar de una aplicación que pueda servir como base de prueba de funcionalidad del proyecto. |
|
Completar la funcionalidad del sistema mediante el estudio de los requisitos pendientes, administrando los cambios de acuerdo a las evaluaciones realizados por los usuarios. |
Requisitos posteriores con base en evaluaciones |
Todos aquellos requerimientos basados en las pruebas llevadas a cabo en el diseño del prototipo preliminar, lo que ofrece la manera de eliminar cualquier otro riesgo potencial para el proyecto y disminuir o anular sus debilidades. |
|
Asegurar que el software esté disponible para los usuarios finales, eliminando los errores y defectos encontrados en las pruebas de aceptación, asegurando capacitación a los usuarios así como el soporte técnico |
Pruebas y correcciones necesarias al sistema. |
Técnicas informáticas para comprobar la calidad del sistema definitivo |
Fuente: Elaboración propia.
En la fase de análisis se ordenaron los datos obtenidos de la fase de recopilación, para luego poder sacar conclusiones y determinar la situación de estudio. Según Sabino (2000), esa masa de datos, por si sola, no nos dirá en un principio nada, no nos permitirá alcanzar ninguna conclusión si, previamente, no ejercemos sobre ella una serie de actividades tendientes a organizarla, estas acciones son las que integran el llamado procesamiento de los datos. (p. 172)
Se revisaron al detalle y sistemáticamente, se analizaron y decantaron hasta determinar aquellos que fueran útiles para la investigación y el montaje del nuevo sistema. El siguiente paso fue tabular los datos, agrupándolos y construyendo tablas, concentrados y contabilizados para la construcción de un panorama general de la realidad (Hernández, Fernández y Baptista, 2006).
Finalmente, a partir del estudio y de la conceptualización se propuso el nuevo Sistema con sus objetivos, instrumentación e implantación dentro de la estructura de la empresa.
Previo a la fase de resultados, es necesario revisar las variables (Tabla 1) y su definición que depende de la dinámica de la construcción del proyecto, así como los interrogantes del cuestionario para el personal y los usuarios finales ofrecidos en los resultados.
RESULTADOS
Se procedió a analizar y graficar cada una de las respuestas obtenidas a través de la aplicación de los cuestionarios. En el primero, para agilizar las actividades del área de Análisis de Soporte el cuestionario se centraba en los procedimientos llevados a cabo para el registro, control, búsqueda y actualización de requerimientos de soporte técnico. A continuación se presenta el cuerpo del cuestionario y los resultados obtenidos (Tabla 2).
Tabla 2. Cuestionario para el personal
|
Instrucciones: Lea cuidadosamente cada una de las preguntas presentadas en este folio antes de responder, marque su opción con una X. |
||
|
Pregunta |
SÍ |
NO |
|
1. El sistema manual utilizado para el registro y control de incidencias reportadas por los usuarios finales de equipos informáticos cumple con los estándares de manejo de información |
|
|
|
2. La celeridad con que se realiza el registro y búsqueda de información referente a requerimientos de soporte técnico es la apropiada |
|
|
|
3. El proceso que se lleva a cabo actualmente para el registro y búsqueda de información de incidencias funciona de forma eficiente basándose en los estándares del manejo del negocio |
|
|
|
4. El manejo de la información referente a las incidencias reportadas por los usuarios es de alta calidad en lo que se refiere a la identificación de los actores involucrados en su registro, manejo, control y actualización |
|
|
|
5. El procedimiento actual de registro, búsqueda y actualización de incidencias que se realiza en el área de Análisis de Soporte cuenta con copias de seguridad en caso de extravió de información |
|
|
|
6. Cree usted que deban implantarse medidas de seguridad para el acceso a información referente a incidencias previamente reportadas por los usuarios finales |
|
|
|
7. De implementarse un sistema automatizado para el registro, gestión y control de incidencias a nivel de soporte técnico para el área de Análisis de Soporte, cree usted que se agilizarían lo procesos antes mencionados |
|
|
Fuente: elaboración propia.
La primera pregunta sobre el sistema manual arroja un resultado de 8 personas que marcaron NO (80%) y 2 marcaron SÍ (20%); la pregunta 2, sobre la celeridad con que se realiza la búsqueda de información, 1 persona (10%) respondió que SÍ es la apropiada y 9 (90%) respondieron que NO; la pregunta 3, sobre el proceso para el registro y búsqueda de información de incidencias 10 personas (100%) marcaron que NO funcionaba de forma eficiente; la pregunta 4 referente a si las incidencias reportadas por los usuarios es de alta calidad 9 (90%) respondieron que NO y 1 (10%) respondió que SÍ; a la pregunta 5 sobre las copias de seguridad en caso de extravió de información, el 100% (10 personas) respondieron que NO.
Las preguntas 6 y 7 se dirigían hacia las posibilidades de cambio por lo que su redacción se dirigía a las necesidades de los encuestados. Es así que a la pregunta sobre si debían implantarse medidas de seguridad para el acceso a información referente a incidencias previamente reportadas por los usuarios finales, las 10 personas (100%) respondieron que SÍ. La pregunta 7, sobre la urgencia de implementarse un sistema automatizado para el registro, gestión y control de incidencias a nivel de soporte técnico para el área de Análisis de Soporte, recibió un 90% (9) de respuestas SÍ y una persona (10%) marcó que NO.
En total se puede observar que las respuestas a los ítems del 1 al 5, entre 80 y 100 % estuvieron en desacuerdo (marcaron NO) con la eficiencia, eficacia y solvencia del sistema manual, mientras que para los ítems 6 y 7, sobre las necesidades de actualización y cambio entre el 90 y 100% estuvieron de acuerdo (marcaron SÍ). Con respecto al cuestionario para los Usuarios Finales (Tabla 3) la presentación y los resultados fueron los siguientes:
Tabla 3. Cuestionario para usuarios finales
|
Instrucciones: Lea cuidadosamente cada una de las preguntas presentadas en este folio antes de responder, marque su opción con una X. |
||
|
Pregunta |
SÍ |
NO |
|
1. El proceso de reporte de incidencias es rápido |
|
|
|
2. Al momento de solicitar el status de procesamiento de una incidencia previamente reportada, el proceso es rápido |
|
|
|
3. Cree usted que deba mejorarse el sistema para el reporte de incidencias |
|
|
Fuente: elaboración propia