Procedimiento de soporte

Procedimientos Sistemática de trabajo para soporte, laboratorio y subida a producción

2 San Francisco de Sales 1 14010 Córdoba

T. 957 481 267 | F. 957 486 917

[email protected]|www.dosatic.com

Sistemática de trabajo para soporte, laboratorio y subida a producción

Guía de sesiones de formación

Esta guía pretende crear una sistemática de trabajo que nos permita mejorar en nuestros desarrollos, aumentar la satisfacción de nuestros clientes y controlar las subidas a producción por parte de los distintos equipos de trabajo.

Soporte de ticker

Es prioritario que entendamos que un problema/ticker para un coordinador Qe/docente genera una inevitable angustia y en ocasiones insatisfacción con la aplicación. Por ello debemos ser sumamente comprensivos con nuestros “clientes”, entendiendo que ellos no conocen muchas veces en profundidad nuestra aplicación y que gracias al esfuerzo de los coordinadores Qe y su apuesta por nuestro sistema, los centros trabajan con nuestro producto. Si un coordinador Qe no se siente bien atendido las posibilidades de insatisfacción del centro son altas y la opciones de baja de nuestro producto aumentan.

Por lo tanto el trato debe ser cariñoso, respetuoso, comprensivo y paciente. Debemos de tener especial interés en las contestaciones emitidas al cierre de los ticker. En ocasiones denotamos que la interpretación de estas contestaciones o cierres no son lo suficientemente cercanas o claras.

Procedimiento

La asignación de tickers la hará la persona responsable de esta encomienda que normalmente será Jose Ángel. En caso de ausencia de Jose Ángel la función se encomendará a Pau.

Todos los días de 8:00 a 9:30 los técnicos de soporte revisarán los tickets asignados.

Si el ticker es un DUDA debe ser respondida en un plazo inferior a 48 horas laborales. Jose Ángel realizará informe de ticker y responsable que no han cumplido estas acciones.

Si el ticker es una INCIDENCIA y se puede resolver de forma rápida se procede a ello, comprobando en desarrollo su funcionamiento y esperando a laboratorio para volver a probar y marcar resuelta-pendiente. En el caso de que el ticket requiera una actuación más larga se programa. Este tipo de tickers es el más importante y por lo tanto nos computa de carácter muy negativo su falta de atención.

Si el ticker es una SUGERENCIA debemos ver si realmente es una sugerencia o una incidencia encubierta. En caso de incidencia encubierta modificamos su tipo y procedemos. Si la sugerencia proviene del esquema de Valencia deben reflexionarse por Javi Parra. Posteriormente toda sugerencia debemos de asignarla al Equipo Pedagógico para su aprobación. Una vez aprobada la sugerencia se traspasará a Qualitas Nuevos Desarrollos, o a Qualitas Mejoras Internas si la sugerencia proviene del equipo técnico. Sí se puede resolver de forma rápida se procede a ello. En cualquier otro caso la sugerencia se programarán, siempre deben entenderse la sugerencia como “no” errores de la aplicación y mejoras para nuestros clientes, la prioridad son las incidencias.

En el nuevo proyecto de soporte mantis llamado “Laboratorio” incluiremos toda modificación realizada que queramos sea posteriormente revisadas por nuestro tester.

El estado de ticker Resuelta-Pendiente debe marcarse una vez se haya realizado la comprobación en laboratorio.


T. 957 481 267 | F. 957 486 917



Comunicación

La comunicación entre los distintos grupos de trabajo debe ser continua y ágil. No nos podemos permitir el desarrollo o modificación de elementos sin el conocimiento del resto de grupos de trabajo.

Las funciones comunes, librerías y base de conocimiento en nuestros desarrollos deben ser comunes y para ello se enviará la información al grupo mediante correo electrónico en el que nuestro asunto estará encabezado por los literales “Base de conocimiento Qe”.

En caso de no estar conforme con la metodología utilizada para realizar la programación de algunos módulos, se planteará a los responsables de cada grupo y se establecerá una reunión para el debate común y toma de decisiones.

Skype es una “herramienta de trabajo” mediante la cual nos comunicaremos de forma inmediata las veces necesarias y deber estar operativo en toda nuestra jornada laboral.

Base de datos

El acceso a los esquemas de la base de datos de laboratorio son comunes a todos los programadores. Estas bases de datos se actualizarán con la copia de seguridad todos los domingos por la noche. Mientras nos certifican desde sistemas que los índices se traspasan correctamente encomendamos la misión de revisión de índices y actualización a Pau Sánchez los lunes a las 8:00.

El acceso a base de datos de producción sólo está activo para Jacinta y será ella quien determine si en periodo de funcionamiento puede realizar alguna acción directa contra las bases de datos de producción. En caso de que Jacinta no esté disponible se traspasa esta responsabilidad a Ivan de Sistemas.

Toda modificación realizada en base de datos debe enviarse por correo electrónico a [email protected] mediante script y un documento txt explicando los pasos necesarios para su aplicación. Estas modificaciones en bases de datos deben estar preparadas para todos los esquemas dados de alta.

El programador que realiza modificación en base de datos debe “garantizar” que esta modificación no afecta a ningún otro módulo del sistema. Deberá buscar en todos los javas del sistema que no implica error y deberá comprobarlo en laboratorio.

mailto:[email protected]


T. 957 481 267 | F. 957 486 917



Laboratorio y Producción

Las subidas a laboratorio se pueden realizar cuando sea necesario, informando con claridad de los archivos java que deben actualizarse y los módulos flex implicados en ello. Para realizar estas subidas al servidor estarán autorizados Jacinta y Jorge.

Normalmente se establecerá este esquema de trabajo semanal para las subidas a producción, salvo que una semana no se tenga que subir nada a producción o determinemos no tener demasiado valor la actualización y pueda esperar. De esta forma nivelamos producción una semana más.

Lunes Martes Miércoles Jueves Viernes

14:00

Se cierran las subidas a laboratorio de nuevos desarrollos

14:00

Se da el ok de traspaso laboratorio a producción

19:00

Se sube a producción

Laboratorio Tester en laboratorio Sistemas

En el periodo de testeo cada programador probará sus cambios o nuevos desarrollos en laboratorio, si detecta alguna anomalía la corregirá y la volverá a subir a laboratorio durante el periodo de testeo, volviendo a probar en laboratorio la subida.

Durante el periodo de testeo se encomendará a Jose Ángel e Iván el protocolo de testeo del laboratorio sobre las nuevas mejoras y sobre el global de la aplicación. Si detecta anomalías las comunicará al programador correspondiente para que las subsane en periodo de testeo. Revisará no solo aspectos funcionales si no también aspectos de usabilidad y capa visual de los nuevos desarrollos.

Protocolo de testeo

1. Desde la web de soporte.dosatic.com con selección “todos los proyectos” realizará la 2. Revisión de resueltos_pendientes 3. proyecto Laboratorio 4. recorrido mínimo por toda la aplicación 5. Pilotos Córdoba 6. Colegiosqe Valencia. 7. Una vez finalizado el testeo: 8. Generación de documento con las mejoras de información a los Qe. Envío de los documentos

a programadores/coordinadores Qe o responsables en concreto.

En caso de error informa, repara, subir y comienza los tester.


T. 957 481 267 | F. 957 486 917



Si el jueves a las 14:00 h está todo correcto según las pruebas de testeo se procederá a la subida de laboratorio a producción. En caso de error detectado por el testeo, debido a alguna anomalía, si se localiza de donde proviene se subsanará de forma prioritaria si es posible, si no es así se pospone la subida.

En caso de estar localizada la anomalía y no ser subsanable ese día se subirá todo menos esa parte, siempre que sea posible separar el error contra la aplicación o módulo.

El traspaso de laboratorio a producción se realizará con la siguiente secuencia:

1. Jacinta programa con sistemas la subida 2. Si hay que realizar cambios en la estructura de la base de datos, se realiza backup de la base

de datos completa. 3. Se lanzan los Script enviados. 4. Se van sacando los frontales del balanceador y se van actualizando con el nuevo programa. 5. Se realizan las pruebas del frontal y si está correcto se añade al balanceador. 6. Esta operación se realiza con todos los frontales.

Procedimiento de soporte

Documents

Transcript of Procedimiento de soporte