Help Desk

Introducción

Help Desk es un sistema de resolución de incidencias para servicios de mantenimiento, ayuda al usuario en la resolución de problemas presentes en el software o dudas acerca de las funcionalidades del mismo. Permite establecer flujos de trabajo para soportar las problemáticas derivadas de alteraciones en el software Dabsoft.

La incidencia puede recibirse de forma: e-mail, entrada a través de una web, o bien ser abierta por el servicio de atención con nuestros números telefónicos. Una vez en marcha seguirá el flujo establecido por el cliente para su resolución confiable y eficiente. Permite: resolución inmediata.

Mediante nuestro  Help Desk podrá reportar las incidencias o aclarar dudas sobre nuestro producto.

Declaración de la misión

Proporcionar al cliente un servicio extra de calidad para la aclaración de problemas con soporte técnico de manera fiable de acuerdo a las condiciones pactadas en el presente documento.

Objetivos del servicio             

•  Incrementar la satisfacción del cliente.

•  Incrementar la eficiencia y efectividad a través de la aplicación incesante de buenos métodos de servicios de soporte.

•  Garantizar la disponibilidad de los servicios en los horarios propuestos.

•  Garantizar la recuperación en caso de alguna falla en el software.

Alcance del Servicio

•       Cobertura de 365 días x 7 días a la semana x 24 horas al día.

•       Gestión de la demanda para el control de incidencias y mejoras.

•       Sistemas de información en tiempo real.

•       Análisis de las incidencias y su causa para la mejora continua y evolución de los procesos del software.

.

Este Servicio se soportará con un mecanismo de control y seguimiento a cambios e incidencias proporcionado al cliente a través de tres niveles de soporte.

Como forma de representar la idea del proceso de Help Desk se presenta un diagrama.

Diagrama de contexto de servicio

                 NIVEL 0                      NIVEL 1                                  NIVEL 2                                                   CLIENTES

           

 

Usuario en Centro Logístico de Cliente

Representado por el operador logístico González Calderón Elías Neftalí dentro del centro del cliente, que realizará un primer filtro y registrará la correspondiente incidencia/mejora en la herramienta de ticketing indicada.

 

Encargado de Soporte Inicial 

Lorea Sánchez Alejandro y De la Cruz Flores Itzel Selena recogerán y realizarán un primer examen de la incidencia. Se trata de un nivel de soporte inicial, responsable de las incidencias básicas del cliente. Se encargará de recepcionar por cualquiera de las vías disponibles (vía telefónica, web, mail) todas las incidencias registradas por el Nivel 0, reunir toda la información del cliente y evaluar la incidencia mediante el análisis de los síntomas y la determinación del problema. Complementa con información adicional la apertura del ticket. El analista debe diagnosticar si el incidente presentado tiene solución inmediata, en cuyo caso implementa la solución ya sea mediante llamada al cliente y/o vía remota. En caso contrario escala a nivel 1/2 de resolución.

 

Gamboa del Ángel Alan Alejandro y Salazar Paz Omar encargados del Soporte Avanzado 

Se encarga de la resolución de incidencias que requieran de una especialización técnica elevada: Funcional, Desarrollo (Java, C++, .NET).

MODO DE FUNCIONAMIENTO.

•       El procedimiento de Help Desk se inicia con una solicitud de asistencia técnica publicada en un ticket. Un ticket puede ser presentado en una serie de formas:

Haciendo clic en el botón "¿No encontraste suficiente ayuda?" que se encuentra en el sitio WEB de Junosty;

Enviando un correo electrónico a Junosty al Departamento de soporte técnico en HelpDeskDabsoft@hotmail.com Después de enviar una solicitud (de que un ticket de soporte técnico se presente), será procesado por el equipo de soporte técnico o comercial de Junosty según sea el caso.

•       Cada ticket debe incluir la siguiente información con el fin de reducir el tiempo de resolución.

La descripción del problema y el procedimiento paso a paso para reproducir el error (si es posible).

La dirección URL del sitio donde se produce el problema.

El número de versión de software y el nombre de edición.

Nuestro sistema recabará la siguiente información del usuario que envía el ticket, de tal manera que el equipo de soporte pueda tener acceso a dichos datos:

-Configuración del Software del Servidor

-Versiones del mismo

-Navegador del cliente

•       Si es necesario llevar acabo alguna acción en el servidor WEB del cliente para resolver algún problema, el especialista de soporte puede solicitar  Los datos de autorización (nombre de usuario y contraseña) enviados al equipo de soporte técnico de Junosty se debe cambiar inmediatamente después de la resolución del problema.

•       Cada vez que un usuario envíe un ticket de soporte técnico o envíe un mensaje al personal del Equipo de Soporte Técnico de Junosty, como un ticket, el sistema genera y enviará automáticamente una notificación indicando que la cuestión será atendida.

•       El servicio de Help Desk no ofrece otros canales de comunicación (por ejemplo, foro, GoogleTalk, etc). Las preguntas a través de estos canales no se tratarán como solicitudes oficiales y no serán registradas por nuestro Help Desk. Estos otros canales podrán ser usados, para comunicaciones generales ventas y otros.

•       Al crear un ticket o al realizar un envío de solicitud de soporte por correo electrónico, puede incluir capturas de pantalla y otras imágenes que pueden deberán ser creadas en formatos PNG, GIF, JPG (imágenes en formato BMP debe ser comprimido utilizando un RAR o un software de archivo ZIP).

•       Las respuestas a las preguntas más comunes y frecuentes se pueden dar en forma de enlaces a las páginas correspondientes de la documentación, o directamente se dirigen al usuario a la sección de preguntas frecuentes. El personal del equipo de soporte técnico de Junosty le puede proporcionar enlaces a otros recursos web si lo estima conveniente.

Hay una serie de circunstancias que pueden retrasar o anular el proceso de resolución de problemas como son:

-El problema requiere mejoras personalizadas de productos Dabsoft que se están desarrollando actualmente.

-El uso inadecuado de los productos Dabsoft, incluida la modificación del núcleo del producto, Violación general de los términos y condiciones de Dabsoft SLA (Service Level Agreement) Información Incorrecta, incompleta o engañosa proporcionada por el usuario. 

Procesos de Gestión de Configuración de Software

El proceso de gestión de la configuración de software define una serie de tareas que tienen cuatro objetivos principales : identificar los elementos, gestionar los cambios, facilitar la construcción de diferentes versiones, y garantizar que la calidad del software.

Se dividen en las siguientes etapas:

Identificación de objetos en la configuración del software 

Se  nombra cada uno de los elementos por separado y luego se organizan mediante un enfoque orientado a objetos. Se pueden clasificar en dos tipos de objetos : básico y agregado. Un objeto básico es un fragmento de información, y un objeto agregado es una colección de objetos básicos.

Control de versiones

Se combinan procedimientos y herramientas para gestionar las diferentes versiones del software que se generen a lo largo de su desarrollo. También se implementa un "seguimiento de conflictos" que permiten registrar y dar seguimiento al estado de todos los errores del proyecto.

Control de cambio

En un proyecto donde son muchos los que interactúan con el código, se necesita llevar un control para evitar que haya malentendidos y cambios inecesarios en el código. Para esto se utiliza un mecanismo dónde el desarrollador al cambiar el código, genera una versión que solo el puede ver, para después de asegurarse que los cambios fueron correctos, puedan ser implementados

Auditoria de la configuración.

Es la revisión de los cambios y configuraciones realizadas a lo largo del desarrollo del proyecto de software. Se enfoca en la corrección técnica del objeto que se ha configurado.

Se necesita responder a estas preguntas:

1. ¿Se ha realizado un cambio especifico?
2. ¿Se ha seguido el proceso de cambio?
3. ¿El cambio ha resaltado en el ECS?

Reporte

Es una actividad que responde a las siguientes preguntas 1)¿Que ocurrió?, 2)¿Quien lo hizo?, 3)¿Cuando ocurrió?

Cada vez que se le asigna una identificación nueva o actualización se necesita explicar porque se hizo.

Gestión de Cambios y de Software

Gestión de Cambio de Software

La gestión de cambios de software acelera la entrega de software mediante el soporte ágil a flujos de trabajo y procesos, además de simplificar la administración de la gestión de configuración y cambios.

Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento y se debe estar preparado, las actividades de la Gestión de Cambio de Software sirven para :

• Identificar el cambio de nuestro software
• Controlar el cambio
• Garantizar que el camio quede bien implementado
• Informar de el cambio

La meta es maximizar la productividad, minimizando los errores.

Gestión de Cambios

El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.

La Gestión de Cambios debe trabajar para asegurar que los cambios:

• Están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio TI.
• Están convenientemente registrados, clasificados y documentados.
• Han sido cuidadosamente testeados en un entorno de prueba.
• Se ven reflejados en la CMDB.
• Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación.

Las actividades principales de la Gestión de Cambios se resumen sucintamente en el siguiente diagrama:

Ingeniería Inversa

Ingeniería Inversa

La ingeniería inversa puede obtener información de diseño a partir del código fuente, pero el grado de abstracción, la completud de la documentación, y el grado en que las herramientas son variables.

Ingeniería Inversa para comprender los datos

La ingeniería inversa de las actuales estructuras globales de datos establece el escenario para la introducción de una nueva base de datos que abarque todo el sistema.

Estructura de base de datos internos. Las técnicas de ingeniería inversa para datos internos del programa se enfoca en la definición de clases de objetos. Esto se logra al examinar el código del programa con el propósito de agrupar las variables de programa relacionadas.

Estructura de bases de datos. La re ingeniería de un esquema de un esquema de base de datos en otro requiere comprender los objetos existentes y sus relaciones.

Ingeniería Inversa para comprender el procesamiento

Comienza con un intento por comprender y luego extraer abstracciones de procedimientos representadas por el código fuente. Para comprender las abstracciones de procedimientos el código se analiza en grados variables.

Cada uno de los programas que conforman el sistema de la aplicación representa una abstracción funcional en un mayor grado de detalle. Se crea un diagrama de bloques que representa la interacción entre dichas abstracciones funcionales.

En sistemas grandes, la ingeniería inversa se logra utilizando un enfoque semiautomático. Las herramientas automatizadas se utilizan para ayudar al ingeniero de software para comprender la semántica del código existente.

Ingenieria Inversa de Interfaces de usuario

Las IGU sofisticadas ahora son indispensables en productos básicos en computadora y en sistema de todo tiempo. En consecuencia, desarrollar de nuevo las interfaces de usuario se ha vuelto uno de los tipos mas comunes de actividad de reingenieria. Se sugieren tres preguntas básicas que deben responder conforme a la ingeniería inversa de la IGU:

• ¿Cuales son las acciones básicas que debe procesar la interfaz?
• ¿Cual es la descripción compacta de las respuestas de comportamiento del sistema a estas acciones?
• ¿Que se entiende por "reemplazo", que concepto de equivalencia de interfaces es relevante en este caso?

Es importante señalar que una IGU de reemplazo tal vez no refleje exactamente la interfaz antigua. Con frecuencia vale la pena desarrollar nuevas metáforas de interacción. Una IGU sometida a reingeniería puede utilizar una barra de deslizamiento y un ratón para realizar la misma función.

Reingeniería de Software

REINGENIERRIA DE SOFTWARE

 La Re-ingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, re-utilización, comprensión o evaluación.” a

Esta consiste en 6 pasos:

Análisis de inventarios: Las organizaciones de software deberían tener un inventario de todas sus aplicaciones. El inventario tal vez no sea más que un modelo en una hoja de cálculo que contenga información que proporcione una descripción detallada.

Re-estructuración de documentos: La documentación débil es la marca de muchos sistemas heredados.

1. Crear documentación consume mucho tiempo. Si el sistema funciona, vivirá con lo que se tenga. En algunos casos éste es el enfoque correcto. No es posible recrear documentación para cientos de programas de computadora.

2.- La documentación debe actualizarse, pero se tienen recursos limitados. Se utilizará un enfoque de "documentar cuando se toque". Se documentan completamente aquellas porciones del sistema que en la actualidad presentan cambios.

3.- El sistema es crucial para el negocio y debe volverse a documentarse por completo. Incluso en este caso un enfoque inteligente es recortar la documentación a un mínimo esencial.

Ingenieria Inversa. El termino ingeniería inversa tiene sus orígenes en el mundo del hardware. Una compañia desensambla un producto de hardware de un competidor con la finalidad de comprender sus "secretos" de diseño y fabricación. La ingenieria inversa del software es el proceso de analizar un programa con la finalidad de crear una representación del programa en un mayor grado de abstracción que el código fuente.

Re-estructuración de código. El tipo más común de reingeniería es la reestructuración de código. Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de reestructuración, Se indican las violaciones de las estructuras de programación estructurada y entonces el código se reestructura. El código resultante se revisa y prueba para garantizar que no se han introducido anormalidades.

Re-estructuración de datos. Un programa con arquitectura de datos débil será dificil de adaptar y mejorar. La re-estructuración de datos comienza con una actividad de ingeniería inversa. La arquitectura de datos actual se analiza con minusciosidad y se definen los modelos de datos necesarios.

Ingeniería Directa. El programa antiguo sería insertado en el motor, analizando, reestructurado, y luego regenerado en una forma que exhibiese los mejores aspectos de la calidad del software. A corto plazo es improbable que tal "motor" aparezca, pero las empresas han introducido herramientas que mejoran un limitado subconjunto de dichas capacidades que aborden dominios de aplicación específico.