Objetivo

El presente documento tiene como objeto estandarizar las solicitudes de intervención, reportes de errores y requerimientos que efectúen a la Dirección General de Sistemas (DGS) los usuarios del Sistema de gestión integral de expedientes SUDOCU implementado en la Universidad Nacional de Luján. El fin último de la observación de lo aquí mencionado será facilitar la intervención del personal técnico, mediante el reporte de la mayor cantidad de información de relevancia para el caso y, al mismo tiempo, efectuar la adecuada documentación del proceso, dando lugar, además, a su correcto seguimiento.
 

Alcance

En el presente procedimiento tendrá intervención el personal técnico a cargo de la administración del sistema SUDOCU y el personal Nodocente afectado a la utilización del mismo, llamados también Usuarias/os.
 

Responsabilidades

Existen dos responsabilidades primarias en relación al presente procedimiento. La primera es relativa a la actualización de este mismo documento. La segunda es la que tiene que ver con el observar el cumplimiento y ejecución del procedimiento definido aquí.

Responsable del documento

El responsable de la actualización del presente documento es el Equipo Técnico del sistema SUDOCU, dependiente de la DGS, de acuerdo al esquema establecido y en concordancia con las políticas de seguridad informática de la Universidad.
 

Responsable de cumplimiento y ejecución del procedimiento

El responsable del cumplimiento del presente plan es la parte usuaria del Sistema SUDOCU de la UNLu.
 

Régimen de actualización

El presente documento será actualizado en el caso de detectarse la necesidad de efectuar modificaciones en relación a la realidad de la estructura funcional y del ambiente informático. Los avisos sobre posibles cambios pueden ser solicitados tanto por la parte técnica como por la parte usuaria y debidamente notificados el resto de los miembros del proyecto.

Ante cada actualización, será obligatorio incluir una breve reseña en la sección Historial de Cambios a fin de facilitar su revisión. Se asentará el contenido modificado (agregado, eliminado, cambiado) y el autor.
 

Medio y Forma de Comunicación

Se pone a disposición de la parte usuaria el siguiente correo electrónico del proyecto:

soporte-gitlab+eei-sudocu-88-issue-@unlu.edu.ar

Cualquier usuario podrá enviar un correo a dicha casilla y este será respondido con un mensaje automático y un número de seguimiento o número de Ticket. Es importante guardar este número ya que podrá ser utilizado tanto por la parte técnica como por la parte usuaria a futuro, para referirse al trabajo solicitado.

TIP

Es importante mencionar que el uso de este correo deja constancia en un sistema interno de todos los intercambios entre Usuarios y Técnicos, siendo esta la única forma de contar con un respaldo persistente de la solicitud. Esto es una ventaja para ambas partes, evita la ambigüedad y ofrece un registro de los avances del proyecto.

Una vez recibido el correo electrónico de respuesta, es posible ampliar la información del Ticket RESPONDIENDO ↩️ ese correo. Al Responder, se le está indicando al sistema que es un comentario que se anexa al correo original. Estos comentarios anexos pueden realizarse la cantidad de veces que considere necesario.

En algún momento puede recibir un correo que le adjunta un comentario de algún técnico. Puede RESPONDER ↩️ dicho correo para anexar una respuesta al comentario en cuestión.
 

Tipos de Solicitudes

Existe una serie de situaciones que pueden dar lugar a una solicitud o pedido:
 

• Solicitud de intervención técnica
• Reporte de error en software
• Solicitud de actualización de versiones

A continuación se describe cada tipo de pedido y se da un ejemplo de correo electrónico que puede ser tomado como plantilla.

Solicitud de intervención técnica

Es el tipo de pedido más general. Existe alguna situación o inconveniente por el cual alguien necesita realizar una operación que implica el uso del sistema SUDOCU y por algún motivo no se puede llevar a cabo. Se espera entonces que el título del correo sea una breve descripción del problema y en el cuerpo del mail se detallen las siguientes cuestiones:
 

• Detalle ampliado del problema
• Descripción acerca de lo que debería suceder si anduviera correctamente
• Adjuntos (Opcional)
  • Capturas de pantallas
  • Video con el problema
  • Archivos relacionados (PDF, DOC, etc...)
• Persona que solicita / Sector
• Forma de contacto alternativa (P.e. Número Interno) (Opcional)

Ejemplo de Solicitud de intervención técnica

Título del correo

Pantalla de inicio del sistema no aparece

Cuerpo del correo

Hoy 10 de Septiembre, al querer ingresar al sistema por la url habitual https://portal.unlu.edu.ar/sudocu en lugar de aparecer la pantalla de inicio habitual donde solicita usuario y contraseña, aparece una pantalla con el texto "404 Not Found".

Se adjunta captura.

Verifiqué con otros compañeros y les sucede lo mismo. Hasta las 9:15 AM el problema persiste.

Atte.
Nicolas Dovico
DGS
Interno 1316
Correo ndovico@unlu.edu.ar

TIP
Si bien en el ejemplo se incluye el email, esto no es estrictamente necesario, ya que la parte técnica recibirá el correo electrónico del remitente, siendo esto redundante.

Cuando un correo de este tipo es enviado, se dará de alta en el sistema de Pedidos y se le responderá con un número de Ticket. A futuro, un técnico se pondrá en contacto por la misma vía, en lo posible, para ofrecerle pasos a seguir, información sobre lo que está sucediendo, o solicitud de ampliación, en caso de ser necesaria.

INFO
Es importante destacar que la información enviada por usted al correo proporcionado es visible para todo el sector técnico de la DGS que sea miembro del proyecto SUDOCU. Nadie de la parte usuaria salvo usted podrá ver el contenido, a menos que reenvíe los correos desde su propia casilla.

Reporte de error en software

Este tipo de solicitud se debe realizar cuando existe algún problema del software para llevar a cabo la tarea correspondiente. Los errores pueden acarrear la necesidad de arreglos o simplemente solicitudes al SIU para que se solucione el problema en alguna versión futura.

¿Cuándo una solicitud es urgente?

Es importante diferenciar entre errores que cortan la operatoria del sistema y errores que permiten realizar las tareas. Los primeros tienen carácter de urgente, ya que no permiten alcanzar los objetivos del software y debe indicarse dicha circunstancia para que su solución sea tratada como tal. Los segundos pueden ser dilatados en pos de mejoras, pero no necesariamente deben ser resueltos en el menor tiempo posible.

Es habitual que el arreglo de este tipo de problemas tenga un retraso añadido, ya que el software es desarrollado por un agente externo a UNLu (SIU). En caso de ser necesaria la intervención de ellos, en las comunicaciones sucesivas al reporte la parte técnica indicará dicha situación.

TIP
Es útil recordar que la parte técnica no es experta en el uso de SUDOCU. Por ello puede ahorrar tiempo explicar los pasos seguidos hasta llegar al error que se está reportando. Esto puede incluir pasos dentro del menú, capturas de pantalla con marca en botones a ser pulsados y cualquier otro tipo de información que sea necesaria para reproducir el error. Es posible, además, que esta reproducción se intente en el servidor de pruebas del sistema, así que puede hacer uso del mismo para intentar que el error vuelva a aparecer.

El título del correo debe ser un resumen del error y en el cuerpo del mail deberían detallarse las siguientes cuestiones:
 

• Explicación del error
• Pasos para reproducir el error
• Indicación de si el error permite finalizar la tarea o la bloquea (en este último caso podría ser urgente su arreglo).
• Adjuntos (Opcional)
  • Capturas de pantallas
  • Video con el problema
  • Archivos relacionados (PDF, DOC, etc...)
• Persona que solicita / Sector
• Forma de contacto alternativa (P.e. Número Interno) (Opcional)

Ejemplo de Reporte de errores en software

Título del correo

Error al grabar generando un Tramite nuevo

Cuerpo del correo

El dia 13 de septiembre, aproximadamente a las 10 hs se intentó dar de alta un documento nuevo (documento tipo "Expediente") y al querer guardarlo el sistema mostró un error.

Los pasos ejecutados fueron los siguientes:

Ingreso al sistema a través de :

https://portal.unlu.edu.ar/sudocu

y me logueo con el usuario "ndovico"

Ingreso al modulo "Gestión" y clico en el botón "Nuevo documento". Elijo el documento "Expediente". Completo los datos correspondientes en el formulario desplegado, y al clicar en el botón "Crear" para guardar el documento y generar el nro correspondiente muestra el error que se adjunta en la captura.

También adjunto captura de los datos cargados en el formulario.

Probé eligiendo otro tipo de documento y muestra el mismo error.

Verifiqué con otros compañeros y les sucede lo mismo. Hasta las 9:15 AM el problema persiste.

Atte.
Nicolas Dovico
DGS
Interno 1316
Correo ndovico@unlu.edu.ar
 

Solicitud de actualización de versiones

La parte técnica estará monitorizando rutinariamente sobre nuevas versiones de SUDOCU liberadas por el equipo del SIU dedicado a EEI. En cuanto una versión sea liberada, el equipo técnico procederá a instalarla en el servidor de pruebas lo más pronto posible. Pueden consultarse los detalles de este proceso en el documento correspondiente.

Por cuestiones de coordinación, algún miembro de la parte usuaria será designado como responsable de la prueba. Su deber es notificar a los sectores que la prueba debe ser realizada tal como indique el procedimiento e ir recibiendo las notificaciones cuando dichos sectores finalicen la prueba en cuestión.

Una vez que todos los sectores terminen de probar, el Usuario Responsable notificará a la parte técnica de los resultados de la prueba y en caso que haya sido positivo, se procederá a coordinar una fecha para su actualización en producción. Esta fecha puede variar en función de diversos factores tales como:
 

• Necesidad de resguardo de datos ante posibles fallas en la actualización
• Tiempo que el sistema estará no operativo durante el proceso de actualización
• Tiempo necesario para validar que la actualización se realizó correctamente

En general, el tiempo que se intenta minimizar es el de la parte usuaria no pudiendo interactuar con el software, aunque se deja abierta la posibilidad para que esto sea consensuado entre ambas partes atendiendo a circunstancias particulares.

Como se puede notar, este tipo de solicitud tiene una naturaleza diferente a las descritas anteriormente. Esto es debido a que el origen del pedido se invierte, siendo la parte técnica la que inicia el pedido de pruebas. Por ello, en este caso el uso del correo no es posible.

Se propone entonces que ciertos miembros de la parte usuaria dispongan de acceso al software Gitlab, herramienta sobre la cual se les asignará el aviso de la disponibilidad de la nueva versión y a través de la cual dicha persona podrá notificar una vez que los sectores usuarios de SUDOCU terminen de realizar las pruebas. Sobre dicha herramienta se podrán plasmar, además, todos los inconvenientes y problemas encontrados durante estas pruebas.

Se explican a continuación los pasos involucrados en esta solicitud y la parte responsable de ejecutarlo:
 

• Liberación de nueva versión del SUDOCU (Equipo EEI del SIU)
• Instalación de nueva versión en Pruebas (Equipo Técnico UNLu)
• Creación de Ticket de Trabajo para ejecución de Pruebas (Equipo Técnico UNLu)
• Coordinación de Pruebas con Sectores Usuarios (Responsable Usuarios)
• Ejecución de Pruebas (Parte usuaria UNLu)
• Notificación de resultados de las pruebas (Responsable Usuarios)
• Si hubiera problemas o errores
  • Notificación del error (Parte usuaria UNLu)
  • Aviso de error a DGS (Responsable Usuarios)
  • Aviso de error al SIU (Equipo Técnico UNLu)
  • Solución del error (Equipo EEI del SIU)
  • Arreglo del error y aviso a Usuarios (Equipo Técnico UNLu)
  • Ejecución de Pruebas (Parte usuaria UNLu)
  • Notificación de resultados de las pruebas (Responsable Usuarios)
• Cuando no haya problemas
  • Coordinación de Fecha para instalación en Producción (Equipo Técnico UNLu, Responsable Usuarios, Parte usuaria UNLu)
  • Instalación en Producción de nueva Versión (Equipo Técnico UNLu)
  • Validación de la instalación (Responsable Usuarios)

Vigencia de la Solicitud

Es difícil establecer un punto de cierre automático de las solicitudes, porque los tiempos de trabajo son variables entre diferentes sectores. Sin embargo, la experiencia muestra que solicitudes sin actividad durante una cierta cantidad de tiempo tienen baja probabilidad de ser relevantes.

Por ello se establece que cualquier solicitud donde la parte usuaria no responda por un periodo de 3 meses desde la última comunicación por la parte técnica, podrá ser dado por concluido o considerado que no necesita intervención.

En caso de ser necesario retomar, el usuario puede iniciar una nueva solicitud, agregando en el detalle que es un seguimiento de la solicitud anterior vía el número de ticket. Eso permitirá a ambas partes hacer la trazabilidad de ambos tickets.
 

Contingencia del Circuito

Se considera una contingencia en el circuito de solicitud cualquier escenario que impida realizar alguno de los pedidos de intervención descritos en este documento. Se detallan a continuación cada escenario y su circuito alternativo.

El Servidor de correo electrónico no funciona

En caso de problemas con el servidor de correo, no es posible dar de alta solicitudes de intervención ante problemas o ante errores. En este caso, se plantean medios alternativos que las partes deberán acordar según el contexto lo requiera. En todos los casos deberá reportarse tanto la contingencia sobre que no es posible generar la solicitud vía el circuito principal, así como también el problema original. Los medios alternativos pueden ser:
 

• Comunicación vía teléfonos internos.
• Comunicación vía correos personales (no institucionales).
• Comunicación vía sistemas de mensajería personales (SMS, Whatsapp, etc...)

Es responsabilidad de la parte técnica verificar los motivos por los cuales el circuito principal no está funcionando (vía comunicación con los administradores del servidor de correo electrónico de la UNLu) así como de comenzar la investigación del problema reportado. Por el lado de la parte usuaria, la responsabilidad será dar de alta el ticket por el canal convencional, en cuanto sea reportada de su normalización.

El Servicio Gitlab UNLu no funciona

El Servicio de Gitlab permite dar el alta de reportes de pruebas de nuevas versiones, por lo cual, en caso que no funcione, no resulta posible avanzar en dicho circuito. Al estar frente a esta contingencia, se sugiere un curso de acción análogo al escenario de contigencia con el servidor de correo, comunicando el problema y el resultado de las pruebas por el mismo canal alternativo, quedando pendiente el reporte hasta el momento que el servicio Gitlab UNLu vuelva a estar operativo.

Historial de Cambios

Septiembre 2022

Migración docu a Gestor de contenidos UNLu (Betina Marazzo)
 

Septiembre 2021

Cambio de estado: Preliminar
Correcciones y mejoras de redacción (Betina Marazzo, Silvina Echecopar)
Ejemplos y correcciones (Nicolás Dovico)
Versión inicial del Procedimiento (Tomás Delvechio)