Monitorización de Atención al Cliente en tiempo real · El proyecto de fin de grado descrito en...

Jesús Allona del Río

Laureano Lambán Pardo

Facultad de Ciencia y Tecnología

Grado en Ingeniería Informática

2015-2016

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Monitorización de Atención al Cliente en tiempo real

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016

publicaciones.unirioja.esE-mail: [email protected]

Monitorización de Atención al Cliente en tiempo real, trabajo fin de gradode Jesús Allona del Río, dirigido por Laureano Lambán Pardo (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Monitorización de Atención al Cliente en tiempo real

Alumno:

Jesús Allona del Río

Tutores:

Laureano Lamban Pardo

Logroño, junio de 2016

MONITORIZACIÓN DE ATENCIÓN AL CLIENTE EN TIEMPO REAL

Universidad de La Rioja - 3 / 53 -

RESUMEN

El proyecto de fin de grado descrito en la siguiente documentación ha sido desarrollado en colaboración con la empresa Arsys S.L.

Consistirá en el desarrollo de una aplicación web utilizada para monitorizar el rendimiento del Departamento de Soporte, mostrando en tiempo real diferentes estadísticas diarias, así como un apartado donde se puedan consultar dichas estadísticas a nivel mensual.

Además, una vez sobrepasados ciertos límites de porcentaje, que deberán ser configurables, se generarán unas alertas que también serán enviadas por correo.

SUMMARY The Final Degree Project described in the following documentation has been developed in collaboration with Arsys SL company.

The project will involve the development of a web application used to monitoring Support Department performance, showing different daily statistics in real time and a section where you can see monthly statistics.

In addition, when certain configurable percentage limits are exceeded, some alerts will be generated and mailed.



Índice

Resumen ......................................................................................................... 3

Summary......................................................................................................... 3

1 INTRODUCCIÓN ........................................................................................... 6

1.1 Descripción de la empresa ....................................................................... 6

1.2 Antecedentes ....................................................................................... 6

1.3 Alcance del proyecto .............................................................................. 7

1.4 Metodología ......................................................................................... 7

1.5 Planificación ........................................................................................ 8

1.5.1 EDT ............................................................................................... 8

1.5.1.1 Diccionario EDT ..................................................................... 8

1.5.2 Planificación temporal ...................................................................... 10

1.5.3 Calendario ..................................................................................... 11

1.5.4 Planificación Sprints ......................................................................... 11

1.5.4.1 Sprint 0: Sprint de inicio ........................................................ 11

1.5.4.2 Sprint 1: Sección con la información en tiempo real (1) .................. 11



1.5.4.5 Sprint 4: Sección de configuración para los avisos ......................... 12

1.5.4.6 Sprint 5: Sección con información histórica ................................. 12

2 ANÁLISIS ................................................................................................. 13

2.1 Captura de requisitos ........................................................................... 13

2.1.1 Requisitos funcionales....................................................................... 13

2.1.2 Requisitos no funcionales ................................................................... 13

2.2 Identificación de actores ....................................................................... 14

2.3 Casos de uso ...................................................................................... 15

2.3.1 Diagrama de casos de uso .................................................................. 15

2.3.2 Definición de casos de uso ................................................................. 15

2.4 Tecnologías y recursos a utilizar .............................................................. 18

3 DISEÑO ................................................................................................... 19

3.1 Arquitectura del sistema ....................................................................... 19

3.2 Diseño de base de datos ........................................................................ 20

3.3 Diseño de clases .................................................................................. 22

3.4 Diseño de prototipos ............................................................................ 23

4 IMPLEMENTACIÓN ...................................................................................... 25

4.1 Recursos externos ................................................................................ 25

4.1.1 Librerías de C# ............................................................................... 25

4.1.2 Plugins jquery y otros frameworks ........................................................ 25



4.2 Estructura del proyecto ......................................................................... 26

4.3 Desarrollo de la aplicación ..................................................................... 28

4.3.1 Desarrollo Sprint 1 ........................................................................... 28





5 PRUEBAS Y DESPLIEGUE ............................................................................... 48

6 CONCLUSIONES ......................................................................................... 48

7 POSIBLES MEJORAS .................................................................................... 49

8 AGRADECIMIENTOS ..................................................................................... 49

9 BIBLIOGRAFÍA ........................................................................................... 50

10 ANEXO ................................................................................................... 51



1 INTRODUCCIÓN En la siguiente memoria se detallará el proceso de desarrollo y la planificación del trabajo de fin de grado realizado por Jesús Allona del Río en la empresa Arsys Internet S.L. Dicha herramienta servirá para monitorizar la atención al cliente de dicha empresa en tiempo real.

1.1 Descripción de la empresa Arsys es un proveedor europeo de servicios de Presencia en Internet, Hosting Gestionado, Cloud Computing y Soluciones de Infraestructura TIC. Con presencia en España, Francia y Portugal, Arsys figura entre las compañías líderes en tecnología e innovación en Europa.

Tiene una plantilla de más de 300 empleados, y cuenta con más de 1,5 millones de servicios activos y de 275.000 clientes. Arsys es líder en el mercado español y pionero en el desarrollo de la primera plataforma europea de Cloud Hosting.

Arsys cuenta con su propio Contact Center, lo cual les permite comprender las necesidades de sus clientes y facilitarles las soluciones más adecuadas en todo momento.

El 40% de su plantilla se dedica en exclusiva a la atención al cliente y forma parte del Contact Center propio de la compañía. En total, más de un centenar de profesionales, altamente cualificados y con amplia experiencia práctica, conforman el equipo de Atención al Cliente de Arsys, organizado según sus áreas de conocimiento y especialidades.

A través de distintos medios, este equipo está a disposición de sus clientes 24 horas al día y 365 días al año, para resolver sus dudas y consultas.

Estos profesionales resuelven más de 2.700 consultas diarias a través de distintos medios (teléfono, redes sociales, chat, Área de Cliente…) y un millón al año.

Tal magnitud de soporte requiere de una especial gestión y control por parte de dicho departamento y en especial de sus responsables, es por esto que se hace necesario el desarrollo de una herramienta como la que aquí se va a documentar, que facilite estas tareas.

1.2 Antecedentes Hasta la realización de este proyecto, Arsys no dispone de un sistema eficiente de control del Departamento de Soporte.

Actualmente cuentan con un sistema que les manda un correo cada cinco minutos a los responsables del departamento, con un resumen del estado actual de dicho departamento, sea cual sea el estado del mismo, es decir, sin avisar de si se trata de una alerta o no.

El sistema actual puede decirse que es un sistema detallado, ya que cada cinco minutos está mandando un correo con todos los detalles del estado, pero no es un sistema intuitivo ni eficiente.

Por esto, la aplicación a desarrollar será especialmente útil para ver de forma rápida el estado del Contact Center, o recibir avisos al correo cuando sea especialmente necesario, es decir, cuando se haya sobrepasado algún porcentaje de umbral, previamente configurado.

Además, actualmente tampoco hay ningún sistema desde el cual se pueda ver de forma gráfica el progreso reciente o el mensual del departamento, ya que lo visualizan a través de consultas, viendo solamente un listado de datos, lo que es muy poco visual y poco intuitivo.



1.3 Alcance del proyecto El Departamento de Soporte es el encargado de atender todas las consultas diarias que les pueden surgir a los diferentes clientes de Arsys a lo largo de las 24 horas diarias, durante los 365 días del año.

Su objetivo es ser lo más eficiente y efectivo posible, para satisfacer a los clientes en la mayor medida posible.

Para alcanzar dichos objetivos el Departamento de Soporte cuenta con tres responsables que, en todo momento, y en tiempo real, deberán monitorizar el correcto funcionamiento del departamento, controlando los porcentajes de atención de los diferentes medios, como el teléfono y el chat. También deberemos tener en cuenta que el chat se dividirá en dos dominios, chat de Arsys y chat de Piensa (empresa secundaria de Arsys), que se considerarán como dos medios diferentes.

Para llevar a cabo dicho control, los responsables tendrán la posibilidad de configurar ciertas alertas, las cuales serán recibidas a través del correo, o directamente visualizadas en tiempo real a través de la aplicación web.

Así pues, el objetivo de la aplicación es el de poder visualizar en tiempo real los porcentajes de atención al cliente tanto de llamadas como del chat, así como visualizar la cantidad total de llamadas o chats entrantes (atendidos o perdidos).

Además, se mostrará una gráfica en la cual se visualizará el progreso de los porcentajes durante la última hora, y un historial con las alertas surgidas.

También se mostrará el número de agentes conectados a cada uno de los canales a tiempo real.

La aplicación contará con una zona de configuración, desde la que se podrán configurar los límites de porcentaje (inferior/superior) a partir de los cuales, una vez sobrepasados, serán lanzadas las alertas. Desde esta zona también se podrán introducir las direcciones de email que deseen, a las cuales se enviarán los avisos de dichas alertas.

Otra zona de la web será la de historial de datos, a través de la cual se podrá visualizar, por ejemplo, la media de atención alcanzada a lo largo del mes.

La herramienta a desarrollar, se plantea como una aplicación web, que inicialmente se estima posible realizar en ASP.NET (C#), concretamente usando el patrón MVC, además de HTML5 y CSS3.

En cuanto a la persistencia y bases de datos, la empresa usa el sistema gestor SQL Server de manera estándar, por lo que este será el SGBD sobre el que se crearán las tablas necesarias.

Además, habrá que acceder a cierta información almacenada en otro tipo de sistemas como son los estadísticos de las llamadas telefónicas, almacenados en ficheros binarios, o los estadísticos de los chats, almacenados en una BD sobre PostgreSQL, que se encontrará en un servidor al cual se deberá acceder a través de un túnel SSH.

1.4 Metodología Para el desarrollo del proyecto se hará uso de la metodología ágil Scrum.

Esta metodología es perfectamente aplicable al desarrollo de software y se basa en un desarrollo del proyecto de forma iterativa e incremental. Dichas iteraciones reciben el nombre de sprints, y al finalizarlos se deberá mostrar el resultado del mismo al cliente.



Uno de los roles principales en este tipo de metodología es el Product Owner, que representará la voz del cliente, y que en este caso será mi tutora de empresa, Lorea Revilla. En este caso, los sprints tendrán una duración media de dos semanas, tras las cuales me reuniré con ella para revisar los resultados del sprint finalizado, y marcar ciertas pautas de lo que prefiera que realice para el siguiente sprint.

1.5 Planificación La planificación se realizará con el fin de gestionar el proyecto de una manera adecuada, controlando los tiempos y las tareas de la forma más eficiente posible.

Se ha llevado a cabo durante el sprint inicial (0).

1.5.1 EDT

1.5.1.1 Diccionario EDT

Gestión TFG

Tarea que se alargará durante toda la realización del proyecto y que englobará la planificación, seguimiento y redacción de la memoria del mismo.

Planificación

Creación del plan temporal que conllevará la realización del proyecto, marcando la división del mismo en sprints y tareas, así como estableciendo una previsión de tiempos para cada uno de ellos.

Seguimiento

Control del desarrollo del proyecto, comparando las horas planificadas y las reales y teniendo en cuenta las posibles replanificaciones que pudieran surgir.

Reuniones

Reuniones que se realizarán con la tutora, así como con los responsables del Departamento de Soporte para llevar el correcto seguimiento de los sprints.

Memoria

Redacción de la memoria del proyecto.



Análisis

Engloba todas las actividades propias del análisis, como serían la captura de requisitos, la identificación de actores, la realización de casos de uso y la definición de las tecnologías y recursos a utilizar para llevar a cabo la realización del proyecto.

Captura de requisitos

Consistirá en establecer los requisitos funcionales y los no funcionales del proyecto.

Identificación de actores

Identificación de los distintos tipos de usuarios que harán uso de la aplicación y sus correspondientes funcionalidades.

Casos de uso

Consistirá en la creación de los diagramas de casos de uso con su correspondiente especificación, y con sus diagramas de actividad correspondientes.

Tecnologías y recursos a utilizar

Se fijarán las diferentes tecnologías y recursos que se van a utilizar a lo largo del desarrollo del proyecto.

Diseño

Englobará las actividades propias del diseño.

Arquitectura del sistema

Se realizará un diseño de lo que será la arquitectura del sistema, representándolo también de una manera gráfica.

Diseño de BD

Diseño de la base de datos a partir de los requisitos fijados y haciendo uso de los diagramas correspondientes, como E-R, etc.

Diseño de clases

Diseño de las clases necesarias para la realización del proyecto, usando un diagrama de clases.

Diseño de prototipos

Diseño de prototipos para las distintas interfaces, con el fin de lograr las interfaces deseadas por el cliente.

Implementación

Consistirá en la implementación de las diferentes capas que conformen nuestra aplicación, para lo cual usaremos la plataforma Microsoft Visual Studio.

Base de datos

Implementación de la base de datos y su posterior despliegue en SQL Server.

Persistencia

Implementación de la capa de persistencia, que ofrecerá los métodos para obtener o almacenar los datos de la base de datos, tanto de nuestra base de datos como de las bases de datos ya existentes a las cuales deberemos acceder.

Lógica de negocio

Consistirá en la implementación de las capas de lógica de negocio.



Presentación

Implementación de la capa de presentación, es decir las plantillas html (con su javascript, etc.) necesarias.

Defensa

Engloba las tareas correspondientes a la defensa del trabajo de fin de grado.

Desarrollo presentación

Desarrollo de la presentación con ayuda de la herramienta Microsoft PowerPoint.

Exposición

Preparación de la exposición y posterior presentación ante el tribunal correspondiente.

1.5.2 Planificación temporal Descomposición detallada del proyecto y duración estimada.

Tarea Duración Comienzo Fin Total horas

• Gestión TFG 11/01/16 13/04/16 75 horas

Planificación 11/01/16 15/01/16 15 horas

Seguimiento 11/01/16 13/04/16 12 horas

Reuniones 11/01/16 13/04/16 8 horas

Memoria 11/01/16 13/04/16 40 horas

• Análisis 18/01/16 20/01/16 10 horas

Captura de requisitos 18/01/16 19/01/16 5 horas

Identificación de actores 19/01/16 19/01/16 1 horas

Casos de uso 20/01/16 20/01/16 3 horas

Tecnologías y recursos 20/01/16 20/01/16 1 hora

• Diseño 21/01/16 29/01/16 28 horas

Arquitectura del sistema 21/01/16 22/01/16 4 horas

Diseño de BD 22/01/16 24/01/16 6 horas

Diseño de clases 25/01/16 26/01/16 8 horas

Diseño de prototipos 27/01/16 29/01/16 10 horas

• Implementación 01/02/16 13/04/16 172 horas

Base de datos 01/02/16 06/04/16 10 horas

Persistencia 01/02/16 13/04/16 40 horas

Lógica de negocio 01/02/16 13/04/16 80 horas

Presentación 01/02/16 13/04/16 42 horas

• Defensa 13/06/16 13/07/16 15 horas

Desarrollo presentación 13/06/16 17/06/16 10 horas

Exposición 27/06/16 - 5 horas



1.5.3 Calendario El proyecto tendrá una duración total de unas 300 horas, y teniendo en cuenta que la fecha de inicio será el 11 de enero de 2016, y que se realizará en la propia empresa empleando 5 horas diarias, más o menos durará hasta el 13 de abril.

Puesto que me reuniré con mi tutora cada dos semanas, cada sprint tendrá una duración de 10 días (50 horas), por lo que el proyecto se dividirá en 6 sprints de igual duración cada uno de ellos, distribuidos de la siguiente manera:

Sprint 0: Sprint de inicio

Sprint 1: Sección con la información en tiempo real 1



Sprint 4: Sección de configuración para los avisos

Sprint 5: Sección con información histórica

1.5.4 Planificación Sprints

1.5.4.1 Sprint 0: Sprint de inicio

Se trata del sprint de inicio, que durará desde el 11/01/2016 hasta el 29/01/2016.

En él se comenzará la gestión de TFG, realizando la primera reunión con los responsables del Departamento de Soporte. También se realizará la planificación, el análisis y el diseño de la aplicación.

1.5.4.2 Sprint 1: Sección con la información en tiempo real (1)

Se trata del primer sprint de implementación, que durará desde el 01/02/2016 hasta el 12/02/2016.

A lo largo de la realización del sprint se desarrollará el apartado de porcentajes y estadísticos de la sección principal de la herramienta, que corresponderá con un panel en el que se mostrará la información sobre el estado del Departamento de Soporte en tiempo real.



En dicha información deberemos encontrar los siguientes datos:

Los porcentajes actuales de los distintos medios de atención al cliente (Teléfono, Chat(arsys), Chat(piensa)).

Una gráfica donde se muestre la última hora de los porcentajes citados.


Se trata del segundo sprint de implementación de la sección con la información en tiempo real, que durará desde el 15/02/2016 hasta el 29/02/2016.

A lo largo de la realización del sprint se desarrollará la funcionalidad de envío y muestreo de alertas.

En dicha información deberemos encontrar un listado con las últimas alertas lanzadas.


Se trata del tercer y último sprint de implementación de la sección con la información en tiempo real, que durará desde el 01/03/2016 hasta el 14/03/2016.

A lo largo de la realización del sprint deberemos conseguir mostrar la información detallada de los distintos agentes que se encuentran actualmente en sus puestos de trabajo atendiendo las posibles incidencias.

1.5.4.5 Sprint 4: Sección de configuración para los avisos

Este sprint durará desde el 15/03/2016 hasta el 06/04/2016.

En él se desarrollará una sección de configuración desde la cual se configurarán diferentes parámetros referentes a las alertas que serán enviadas cuando se sobrepasen ciertos porcentajes de atención al cliente.

Parámetros de configuración:

Porcentajes límite, inferior y superior, que una vez sobrepasados se generará una alerta en el sistema.

Listado de direcciones de correo a los que se enviará un email en el momento que se produzca una alerta.

Franja horaria en la cual se tendrán en cuenta dichas alertas.

1.5.4.6 Sprint 5: Sección con información histórica

Sprint que durará desde el 07/04/2016 hasta el 13/04/2016.

En este sprint se desarrollará una sección en la que se mostrará una información más histórica sobre los porcentajes de los distintos medios de atención al cliente.

Esta información se mostrará por medio de una gráfica en la que se podrá visualizar el porcentaje atendido de los diferentes medios de atención al cliente a lo largo del mes actual.



2 ANÁLISIS Uno de los primeros pasos necesarios para el desarrollo de un proyecto es la realización de un análisis del mismo. Como primera aproximación comenzamos fijando una serie de requisitos que deberá cumplir la aplicación. Estos fueron indicados por los responsables del Departamento de Soporte a través de un informe entregado al comienzo del proyecto, así como en algunas de las reuniones mantenidas al comienzo del mismo.


2.1 Captura de requisitos Los requisitos describen los servicios que ha de ofrecer el sistema y las restricciones asociadas a su funcionamiento. En esta sección analizaremos los requisitos de nuestra aplicación.

2.1.1 Requisitos funcionales

Permitir el acceso a la aplicación web únicamente a cierto grupo de usuarios.

Una página principal con los siguientes requisitos:

o Mostrar porcentajes de atención de los diferentes medios (Teléfono, Chat(arsys), Chat(piensa)) en tiempo real (5 minutos).

o Mostrar datos entrantes totales y perdidos.

o Mostrar porcentaje mensual.

o Mostrar información referente a los agentes que se encuentran en sus puestos de trabajo.

o Mostrar un listado de las últimas alertas lanzadas.

Una página de configuración que permita establecer:

o Los porcentajes máximo y mínimo de atención, los cuales una vez sobrepasados se lanzará una alerta.

o El listado de direcciones de correo a las que se enviarán las alertas.

o La franja horaria en la cual se tendrán en cuenta las alertas.

o Los días festivos en los que no se tendrán en cuenta las alertas.

Una página que muestre información histórica de todo el mes actual y que cumpla los siguientes requisitos:

o Muestre una gráfica donde se visualice la media de porcentaje de atención de cada día del mes actual.

Una alerta se produce cuando se sobrepasan los porcentajes de límite.

Una alerta corresponde con el envío de un email a cada una de las direcciones indicadas, y con la muestra de la alerta en el listado de la página principal.

El contenido del email de alerta deberá corresponder con la misma información que la mostrada en la página principal.

2.1.2 Requisitos no funcionales

Seguridad

La herramienta será utilizada en la intranet de la empresa, por lo que utilizará la propia autenticación del directorio activo de Windows, para evitar el uso de credenciales y que sea más cómodo su uso.



Concretamente los usuarios que tendrán acceso a la aplicación serán los pertenecientes al grupo “lRSopES”, que son los responsables del Departamento de Soporte.

Disponibilidad

La aplicación deberá tener una disponibilidad de 24/7, incluso cuando se lleve a cabo alguna operación de mantenimiento se deberá tratar de realizar con la mayor celeridad posible.

Navegadores

La aplicación deberá funcionar correctamente en los navegadores más utilizados en la empresa (Firefox, Chrome, Internet Explorer y Edge).

Soporte

Se documentará la aplicación con un manual de usuario con el objetivo de explicar su uso con la mayor claridad posible.

2.2 Identificación de actores Según los diferentes tipos de usuarios que harán uso de la aplicación podremos distinguir los siguientes actores:

Usuario normal

Corresponderá con los usuarios pertenecientes al grupo “lRSopES”, que son los responsables del Departamento de Soporte, y tendrán acceso tanto a la zona principal de la aplicación, donde se muestra la información del estado del soporte en tiempo real, como a la zona de historial, donde se muestra la media de atención alcanzada a lo largo del mes.

Administrador

Corresponderá con un usuario concreto o con unas credenciales almacenadas. Tendrá acceso a la zona de configuración, desde la que podrá configurar ciertos parámetros de la aplicación, como los límites de porcentaje, la franja horaria en la que se tendrán en cuenta las alertas, las direcciones de correo a las que se enviarán alertas, la selección de los días festivos en los cuales no se enviarán alertas, etc.



2.3 Casos de uso En este punto se definirán algunos de los casos de uso más importantes del proyecto junto con su especificación.

2.3.1 Diagrama de casos de uso

2.3.2 Definición de casos de uso

Caso de uso Acceder a aplicación

Descripción El usuario accede a la aplicación.

Actores Usuario normal y administrador.

Precondiciones El usuario debe estar logueado en el directorio activo y pertenecer al grupo de responsable de soporte.



Postcondiciones El usuario accede y es identificado en la aplicación.

Flujo básico

El usuario accede a la dirección de acceso a la aplicación.

El usuario es identificado y redirigido a la aplicación.

Flujo alternativo y excepciones

En caso de que el usuario no pertenezca al grupo de responsables de soporte o que no esté permitido su acceso, mostrará una página de denegación de acceso al servicio.

Caso de uso Acceder a estado

Descripción El usuario accede a la página de estado (página principal de la aplicación)

Actores Usuario normal y administrador.

Precondiciones El usuario debe haber accedido previamente a la aplicación.

Postcondiciones Al usuario se le muestra la página de estado en tiempo real, mostrándole la siguiente información:

Porcentajes de atención de los diferentes medios (Teléfono, Chat (arsys), Chat (piensa)) en tiempo real (5 minutos).

Datos entrantes totales y perdidos.

Porcentaje mensual.

Información referente a los agentes que se encuentran en sus puestos de trabajo.

Listado de las últimas alertas lanzadas.

Flujo básico

El usuario accede a la aplicación.

El usuario es redirigido directamente a la página de estado.

Flujo alternativo

En caso de que el usuario se encuentre en cualquier zona de la aplicación, podrá acceder a través de la barra de menú superior, mediante la opción “Inicio”.



Caso de uso Acceder a configuración de alertas

Descripción El usuario accede a la página de configuración de alertas.

Actores Administrador.

Precondiciones El usuario debe haber accedido previamente a la aplicación.

Postcondiciones Al usuario se le muestra la página de configuración de alertas, con las siguientes opciones a configurar:

Porcentajes máximo y mínimo de atención, los cuales una vez sobrepasados se lanzará una alerta.

Listado de direcciones de correo a las que se enviarán las alertas.

Franja horaria en la cual se tendrán en cuenta las alertas.

Días festivos en los que no se tendrán en cuenta las alertas.

Flujo básico

El usuario accede a la aplicación.

El usuario accede a la opción de configuración desde la barra de menú superior.

Caso de uso Configurar cualquiera de las opciones de configuración

Descripción El usuario puede configurar cualquiera de las opciones de configuración desde la página de configuración.

Actores Administrador.

Precondiciones El usuario debe haber accedido previamente a la configuración de alertas.

Postcondiciones Se guardan en base de datos los cambios realizados en cualquiera de las opciones.

Flujo básico

El usuario accede a la configuración de alertas.

Modifica las opciones de configuración deseadas.

Las opciones que han sido modificadas son almacenadas en base de datos de forma automática, o bien pulsando en el botón de guardar.

Flujo alternativo

En caso de que surja algún problema con el guardado en base de datos de las opciones modificadas, se mostrará un mensaje de error advirtiéndolo.



2.4 Tecnologías y recursos a utilizar A lo largo del desarrollo de este proyecto se utilizarán las siguientes tecnologías y recursos:

Microsoft Visual Studio 2013

Entorno de desarrollo que se utilizará para desarrollar la aplicación.

Herramientas para desarrolladores de Google Chrome

Set de herramientas para desarrolladores web ofrecidas por el navegador y que nos servirán de ayuda para modificar el CSS, inspeccionar el código HTML y depurar javascript.

Gliffy Online Diagram and Flowchart Software

Herramienta de creación de diagramas online, que en este caso utilizaremos su versión gratuita, la cual no será suficiente para la creación de los diagramas de casos de uso, de actividad, de clases y entidad relación.

Microsoft Office Word

Editor de textos utilizado para la realización de la memoria y tutoriales necesarios.

Microsoft Office PowerPoint

Editor de presentaciones utilizado para crear la presentación.

ASP.NET MVC (C#)

Será el lenguaje de programación, junto con el patrón Modelo-Vista-Controlador, utilizado para programar el código backend de la aplicación.

HTM5 + CSS3 + JavaScript

Lenguajes utilizados para diseñar las plantillas web de frontend que contendrá la aplicación.

jQuery

Biblioteca de JavaScript que permite simplificar el uso de este a la hora de manipular el DOM, manejar eventos, usar AJAX, etc.

Bootstrap

Framework utilizado para facilitar el desarrollo de aplicaciones web, ya que contiene plantillas de diseño con tipografía, formularios, botones, menús, etc.

AJAX

Técnica de desarrollo web para crear aplicaciones interactivas, que en este caso utilizaremos para cargar datos y diferentes elementos de forma dinámica, sin necesidad de recargar la página.



3 DISEÑO Este capítulo describirá el diseño de la aplicación, separando el diseño de la arquitectura del sistema, el diseño de la base de datos, el diseño de clases y el diseño de prototipos.


3.1 Arquitectura del sistema En cuanto a la arquitectura utilizada para llevar a cabo el diseño del sistema, puesto que se trata de una aplicación web, se usará el patrón MVC, ya que es uno de los más adecuados para este tipo de aplicaciones.

Pero aparte del patrón MVC utilizado para atender y servir las peticiones HTTP también se utilizarán otro tipo de recursos que describiremos a continuación.

*Sufrirá algunos cambios en el Sprint 2 de la implementación.

El modelo será la capa encargada de gestionar el acceso a la información almacenada en la base de datos principal, la cual cabe avanzar que se tratará de una base de datos SQL Server. Podrá almacenar cierta información en dicha base de datos, como puede ser la información de configuración del sistema. También almacenará las diferentes clases que se usen en la aplicación y que darán forma a los datos obtenidos de la base de datos.

La vista presentará los datos obtenidos por el modelo al usuario.

El controlador es la capa encargada de recibir las peticiones HTTP de los clientes, de tal manera que requerirá los datos necesarios al modelo y posteriormente procesará y enviará las vistas al usuario solicitante.



Además, el sistema también contará con una subtarea que se ejecutará periódicamente (entre 3 y 5 minutos), para solicitar la información actualizada sobre los diferentes canales de soporte (teléfono y chat).

Dicha información se deberá solicitar a través de cuatro medios diferentes:

FTP

Mediante un nombre de usuario y contraseña facilitados, podremos acceder a un servidor FTP, en el cual leeremos ciertos ficheros binarios para obtener la información estadística referente al soporte ofrecido por teléfono.

Telnet

Al servidor citado anteriormente (FTP), también podremos acceder por Telnet para obtener la información detallada referente al soporte ofrecido por teléfono.

BD PostgreSQL

Se nos proporcionará un fichero de clave, y una clave de acceso para acceder mediante un tunel SSH a una base de datos PostgreSQL, desde la cual obtendremos la información estadística referente al soporte ofrecido a través del chat.

Servicio JSON

Mediante un nombre de usuario y contraseña facilitados, podremos acceder a un servicio, al que podremos lanzar peticiones JSON para obtener la información detallada referente al soporte ofrecido a través del chat.

Una vez obtenida la información necesaria, el mismo servicio se encargará de añadirla a la base de datos del servidor (SQL Server), la procesará y enviará al SignalR Hub, el cual mediante WebSockets la reenviará a todos los usuarios conectados, de tal manera que las páginas se actualicen dinámicamente sin necesidad de que el usuario tenga que refrescarla.

3.2 Diseño de base de datos En cuanto a la persistencia y bases de datos, la empresa usa el sistema gestor SQL Server de manera estándar, por lo que este será el SGBD sobre el que se crearán las tablas necesarias.

La base de datos que utilizará nuestra aplicación tendrá por nombre ControlSoporteBD, y estará formada por las seis tablas siguientes:



La tabla Estadisticos almacenará los datos estadísticos que vayan siendo obtenidos mediante el servicio de la aplicación. Su clave primaria estará formada por el “Nombre del tipo de medio” de soporte (teléfono, chat(arsys) o chat(piensa)) y “la fecha y hora” a la que ha sido obtenido dicho estadístico, pero además se almacenarán el número de entradas “totales” y “atendidas” del mismo.

La tabla Alertas almacenará las alertas que puedan surgir en un momento determinado. Concretamente, esto se producirá cuando se obtenga un nuevo estadístico y se compruebe que el porcentaje de atendidos (Atendidos/Total*100) sobrepase el límite configurado, y que estará en la tabla LimitesAlerta. Además de sobrepasar estos límites, para que se considere alerta, estas deberán estar activadas para su tipo correspondiente (AlertasLlam, AlertasChatArsys o AlertasChatPiensa), y que la hora actual de obtención del estadístico se encuentre entre el intervalo de horas a tener en cuenta para las alertas (HoraInicio y HoraCierre).

También habrá que indicar, que esta tabla tendrá el campo “Sobrepasa” de tipo Bit, el cual marcará si la alerta se ha producido por sobrepasar el porcentaje superior (1) o el inferior (0).

Estas dos tablas, serán las únicas tablas sobre las que habrá una relación, de tal manera que la tabla Alertas tendrá una clave foránea con la tabla Estadisticos, sobre los campos Nombre y FechaHora, así cada uno de sus registros corresponderá con uno, y solo uno, de los registros de la tabla Estadisticos, y los de esta podrán tener uno o ningún registro relacionado de la tabla Alertas.

La tabla LimitesAlerta almacenará las opciones de la página de configuración. Los campos LimitLlamInf, LimitLlamSup, LimitChatArsysInf, LimitChatArsysSup, LimitChatPiensaInf, LimitChatPiensaSup almacenarán los límites de porcentaje. Los campos AlertasLlam, AlertasChatArsys y AlertasChatPiensa almacenarán las opciones de activación de las diferentes alertas. Y los campos HoraInicio y HoraCierre almacenarán las horas que marquen el intervalo de horas a tener en cuenta para las alertas.

La tabla CorreosAlerta almacenará los correos a los que se enviarán las alertas.

Las tablas AgenteTelefono y AgenteChat almacenarán la información detallada referente al teléfono y al Chat, es decir, información referente a los agentes que estén atendiendo a dichos medios de atención.

La tabla “AgenteTelefono” estará formada por los siguientes campos:

Usuario: identificador del agente.

Atendidas: número total de llamadas atendidas.

Retiradas: número total de llamadas perdidas.

La tabla “AgenteChat” constará de los siguientes campos:

Dominio: dominio del chat entrante (arsys o piensa).

Usuario: identificador del agente.

Activos: número de chats activos que tiene el agente en este momento.

Anteriores: número de chats activos que llevan más de 60 minutos abiertos.

Tramitados: número de chats activos que llevan menos de 60 minutos abiertos.

UltimoChat: hora a la que se abrió el último chat.

Además, habrá que acceder a cierta información almacenada en otro tipo de sistemas como son los estadísticos de las llamadas telefónicas, almacenados en ficheros binarios, o los estadísticos de los chats, almacenados en una BD sobre PostgreSQL.

3.3 Diseño de clases En cuanto al diseño de clases del modelo de la aplicación principal, todas las clases serán prácticamente iguales a las tablas indicadas en el diseño de base de datos, salvo ciertos matices que comentaremos a continuación.

La clase “Estadistico” tendrá algunos atributos y propiedades adicionales, como el almacenamiento de los datos mensuales (totalMes, atendidosMes) y las propiedades de obtención de porcentajes, tanto actual (Porcentaje) como mensual (PorcentajeMensual).

La propiedad Hora, únicamente devolverá la hora del atributo fechaHora, con el formato 00:00.

La clase “Alerta” será casi idéntica a la tabla de la BD que tiene el mismo nombre. Concretamente tendrá un atributo más (porcentaje), el cual almacenará el porcentaje que se tenía de ese medio de soporte en el momento de producirse la alerta.

La clase “LimitesAlerta” será muy parecida a la tabla anteriormente creada con el mismo nombre, pero además tendrá un atributo que corresponderá con la lista de correos a alertar(List<String>). Así pues, tampoco habrá ninguna clase llamada “CorreosAlerta”.

Las clases “AgenteChat” y “AgenteTelefono” serán idénticas a las tablas con el mismo nombre.

Las clases que encontraremos en el modelo del servicio en segundo plano serán la de Estadístico, AgenteChat y AgenteTelefono. Todas ellas serán idénticas a las tablas almacenadas en la base de datos con el mismo nombre.



3.4 Diseño de prototipos En cuanto al diseño de prototipos, han sido diseñados con la herramienta online gliffy, en su versión gratuita.

Dicho diseño se llevó a cabo durante una reunión con el cliente, directamente haciendo uso de la herramienta citada, para la realización de los bocetos mostrados a continuación, que vendrían a ser como un diseño muy básico realizado a mano alzada.

Página con la información en tiempo real:

Será la página principal de la aplicación, y como podremos ver en el siguiente prototipo constará de los siguientes apartados:

Porcentajes de atención en tiempo real (entre 3 y 5 minutos)

Últimas alertas

Información detallada (detalles teléfono y detalles chat)

Página de configuración:

Será la página de configuración de la aplicación en la cual encontraremos las siguientes opciones para configurar:

Porcentajes límite para las alertas

Correos de alerta

Horario de alerta



Página de información histórica:

Página en la que se mostrará la información histórica del mes actual, mostrando en una gráfica los porcentajes medios diarios de cada día del mes.

Además, en la parte superior de todas ellas dispondremos de un menú para acceder a todas las zonas de la aplicación.



4 IMPLEMENTACIÓN En este capítulo se llevará a cabo la implementación de la aplicación, marcando las tecnologías y recursos externos utilizados, la estructura del proyecto y el desarrollo de la aplicación.

Para esta sección, la explicación seguirá la estructura de Sprints marcada en la planificación.

4.1 Recursos externos A continuación, se describirán algunos de los recursos externos más destacables, utilizados para desarrollar la aplicación.

4.1.1 Librerías de C# En el servicio en segundo plano:

Npgsql

Se trata de una librería utilizada para acceder a las bases de datos PostgreSQL, que en este caso hemos usado para acceder a la base de datos que nos devolverá los estadísticos del chat.

Renci.SshNet

Librería utilizada para realizar conexiones seguras mediante túnel SSH. En este caso la hemos utilizado para realizar la conexión a la base de datos PostgreSQL a través de SSH para obtener los estadísticos del chat.

System.Web.Script.Serialization

Librería utilizada para tratar las respuestas JSON obtenidas del servicio “islpronto” que nos devuelve la información detallada de los agentes de chat.

En la aplicación web principal:

Microsoft.AspNet.SignalR

Librería utilizada para actualizar la web en tiempo real, sin necesidad de recargar la página. De esta manera actualizaremos la gráfica de porcentajes, información detallada y alertas de forma automatizada.

DotNet.Highcharts

Librería utilizada para construir las gráficas que mostrarán los porcentajes de atención. Con la ayuda de esta librería se construirá el objeto que represente a dicha gráfica, y este se pasará a la vista en la que se mostrará.

4.1.2 Plugins jquery y otros frameworks

Moment.js

Plugin utilizado para facilitar el manejo de fechas en javascript.



Custom-content-scroller

Se trata de un plugin utilizado para implementar scrollsbars de forma personalizada y minimalista.

Bootstrap Toggle

Plugin de bootstrap que convierte los checkboxes en interruptores.

4.2 Estructura del proyecto Tal y como remarcamos en la sección de diseño de la arquitectura del sistema, la implementación del proyecto estará dividida en dos subproyectos:

Aplicación principal “ControlAtencion” (Web)

Servicio de Windows “ServicioControlAtencion”

Además, ambos subproyectos compartirán la base de datos principal (construida con SQL Server), de tal manera que el servicio la poblará, y la aplicación principal hará uso de esos datos.



Y relacionando la estructura de nuestro proyecto con la arquitectura que ya realizamos en la etapa de diseño, pasamos a comentar brevemente las diferentes carpetas que conformarían la aplicación principal y su relación con la arquitectura que se estableció en el diseño:

Controlador

Corresponderá con la carpeta “Controllers” de nuestro proyecto.

Vista

Puesto que la vista correspondería con la capa de presentación, esta estaría formada por las carpetas “Views”, “Scripts” (javascript) y “Content” (CSS).

Modelo

Lo encontraríamos en la carpeta “Models”, y estaría conformado por las diferentes clases que ya explicamos en la sección de diseño de clases, además de la capa de persistencia (carpeta “Persistencia”), la cual contendrá las clases con los métodos necesarios para acceder a la información contenida en la base de datos (“Persist_AgenteChat”, “Persist_AgenteTelefono”, “Persist_Estadistico”). También encontraremos la clase “Persist_LimiteAlerta” que nos permitirá tanto modificar como recuperar la configuración de nuestra aplicación.

Subtarea

Esta subtarea estará contenida dentro del fichero “Global.asax”, el cual se ejecutará al desplegar la aplicación web en el servidor, y dejará ejecutándose permanentemente y de forma periódica dicha subtarea, para que cualquier navegador que tenga abierta la propia página web, se actualice de forma automática mediante WebSockets.

Signal Hub

Estará contenido dentro de la carpeta “Hubs”.

Y las diferentes carpetas que conformarían el servicio de Windows:

Modelo

Lo encontraríamos en la carpeta “Models”, y estaría conformado por las diferentes clases que ya explicamos en la sección de diseño de clases, además de la capa de persistencia (carpeta “Persistencia”), la cual contendrá las clases con los métodos necesarios (“Persist_AgenteChat”, “Persist_AgenteTelefono”, “Persist_Estadistico”) para acceder a la información contenida en los diferentes medios (ftp, telnet, postgresql) y almacenarla en la base de datos principal (SQL Server).

Lógica de negocio

La propia lógica de negocio del servicio estará en el método “OnStart” de la clase principal “WindowsService”.



4.3 Desarrollo de la aplicación Como se indicó en el capítulo de introducción, la metodología utilizada para llevar a cabo el desarrollo de la aplicación será Scrum, por lo que a continuación pasaremos a detallar lo realizado en cada uno de los sprints.

4.3.1 Desarrollo Sprint 1 En este sprint se ha comenzado a desarrollar la página con la información en tiempo real, para mostrar los porcentajes actuales de los distintos medios de atención al cliente (Teléfono, Chat(arsys), Chat(piensa)), así como una gráfica donde se muestra la última hora de los porcentajes citados, con el fin de comprobar cómo va evolucionando el progreso de los mismos.

Tanto el contenido de la gráfica, como los porcentajes diarios, porcentajes mensuales, totales, atendidos y perdidos, son actualizados de manera automática sin necesidad de que el usuario actualice manualmente toda la página.

Para conseguir dicho efecto se ha creado una tarea periódica que se encarga de capturar los datos a través de diferentes medios que explicaremos a continuación.



Creación de recursos necesarios

Se creará la tabla “Estadisticos” de la base de datos, como el objeto “Estadistico” del modelo, para almacenar y manipular esos datos. La definición de ambos recursos ya fue explicada en la sección de diseño.

En cuanto a la tabla “Estadisticos” nos servirá para ir guardando un historial de los datos, que nos serán útiles para mostrar los últimos porcentajes obtenidos en la gráfica, además de para la zona del histórico mensual que se diseñará más adelante.

Implementación de tarea periódica

La tarea periódica se ha implementado directamente en el archivo de aplicación, “Global.asax”, el cual se compila en tiempo de ejecución cuando arranca la aplicación, y más concretamente en el método “Application_Start()”, cuyo código se ejecutará cuando se inicie la aplicación.

La tarea periódica se ha implementado haciendo uso de la caché de la aplicación “HttpRuntime.Cache”, dándole un tiempo de expiración. Una vez pasado dicho tiempo, se ejecutará el código de la tarea, y seguidamente se volverá a añadir la tarea a caché de nuevo, con el fin de que se trate en una tarea periódica.

Es decir, estos serían los pasos y el código de ejemplo para construir la tarea periódica:

1. Añadir la tarea al inicio de la aplicación desde el método “Application_Start()” con “AddTask("miProceso", 8)”, para que se ejecute la primera vez lo antes posible (tras 8 segundos).

2. La propia tarea en si añadiría el código de la misma (“CacheItemRemoved”)a la caché de la aplicación (“HttpRuntime.Cache”).

3. Cuando la caché expire se ejecutará dicho código (“CacheItemRemoved”).

4. Al finalizar la ejecución del código, se reañadirá la tarea a caché con “AddTask("miProceso", 60)”, para que se ejecute tras 60 segundos.

Ejemplo de código:

private static CacheItemRemovedCallback OnCacheRemove = null; protected void Application_Start() { AddTask("miProceso", 8); } private void AddTask(string name, int seconds) { HttpRuntime.Cache.Remove(name); OnCacheRemove = new CacheItemRemovedCallback(CacheItemRemoved); HttpRuntime.Cache.Insert(name, seconds, null, DateTime.Now.AddSeconds(seconds), Cache.NoSlidingExpiration, CacheItemPriority.NotRemovable, OnCacheRemove); } public void CacheItemRemoved(string k, object v, CacheItemRemovedReason r) { //El código de la tarea AddTask(k, 30);

}



En cuanto al código de la tarea, lo que hace es obtener los porcentajes actuales de ocupación de los diferentes medios de atención al cliente (teléfono y chat), que se obtendrán de distintas fuentes:

Teléfono: lectura de fichero binario, al cual se accederá a través de FTP.

Chat (Arsys y Piensa): consulta de base de datos remota en postgreSQL a través de tunel SSH.

Obtención de porcentaje de ocupación del teléfono (Llamadas totales y atendidas)

Como ya he citado anteriormente, para obtener el porcentaje de ocupación del teléfono, accederemos a la lectura de un fichero binario a través de FTP, el cual esta alojado en la propia centralita del teléfono.

Esta tarea ha sido bastante tediosa y nos ha llevado bastante tiempo, ya que se ha tenido que analizar la documentación de la centralita del teléfono (Alcatel OmniPCX 4400), para identificar el orden de bytes y tamaño de los campos necesarios.

En primer lugar se deberá acceder por ftp a la dirección 192.168.24.17 (dirección de la centralita), con user “****” y contraseña “****” y descargar los ficheros binarios que contengan los estadísticos.

En cuanto a los ficheros binarios citados, se encontrarán en el directorio “/usr4/afe”, y deberemos tener en cuenta que cada día se generará un fichero independiente que seguirá la siguiente nomenclatura:

tc + “Año actual” + “Mes actual” + “Día actual” + .sta

Ejemplo:

Para el día 15/12/2015: tc151215.sta

Para el día 05/02/2016: tc160205.sta

De esta manera, para obtener los datos estadísticos de cada día deberemos interpretar el contenido del fichero correspondiente a dicho día.

Y para interpretar el contenido de los ficheros deberemos seguir las siguientes pautas, obtenidas al analizar la documentación citada:

Paso 1: Descartar los primeros 516 bytes de cabecera.

Paso 2: Leer 4 bytes e interpretarlos como un entero de 32 bits (long).

o Si el valor de dicho entero es menor que 0: descartar 20 bytes adicionales y volver a comenzar este paso 2.

o Si el valor de dicho entero es mayor o igual a 0: procesaremos los datos, teniendo en cuenta que cada paquete son 236 bytes adicionales.

Paso 3: Procesar los 236 bytes citados, de la siguiente manera:

o Byte 18 a 19: Interpretarlo como un entero de 16 bits (short) y corresponderá al Piloto.

o Byte 20 a 21: Interpretarlo como un entero de 16 bits (short) y corresponderá al Grupo.

o Byte26 a 27: Interpretarlo como un entero de 16 bits (short) y corresponderá al Agente.

Una vez obtenidos dichos datos como son el Piloto, el Grupo y el Agente, deberemos contar únicamente los que cumplen las siguientes características:

o El Piloto es igual a 1001.



o El Grupo es mayor que 0.

Y deberemos tener en cuenta lo siguiente:

o Las llamadas atendidas son aquellas que el campo agente es mayor que 0.

o Las llamadas sin atender son aquellas que el campo agente es menor o igual que 0.

Paso 4: Volver a realizar el paso 2, hasta leer todo el fichero, con lo que obtendremos el total de llamadas, las llamadas atendidas y las perdidas, es decir, el porcentaje total de llamadas atendidas.

Explicación gráfica:

Obtención de porcentaje de ocupación de chat (Chats totales y atendidos)

Como ya he citado anteriormente, para obtener el porcentaje de ocupación del chat, consultaremos una base de datos remota en postgreSQL a través de tunel SSH.

Datos que me facilitaron:

Tunel SSH

Para su implementación, los responsables me han facilitado una dirección remota, una clave y contraseña, y un fichero de clave RSA.

Servidor pgsql

Para realizar la conexión a la propia base de datosse me facilitaron un nombre de usuario, una contraseña y un puerto de conexión.

Para implementar el tunel SSH se hizo uso de la librería ya citada anteriormente “Renci.Sshnet” para .NET, junto con el uso de “Port forwarding”.

Una vez creado el tunel seguro SSH, realizaremos la conexión y consulta a la base de datos PostgreSQL mediante la librería Npgsql.

Podremos ver un ejemplo de código en el anexo “Código de conexión ”

Ejemplo de código:

ConnectionInfo ConnNfo = new ConnectionInfo(Dirección remota, puerto, nombre, new PrivateKeyAuthenticationMethod(nombre, new PrivateKeyFile(Ruta del fichero de clave RSA, ""))); sshSession = new SshClient(ConnNfo);



sshSession.Connect(); port = new ForwardedPortLocal("127.0.0.1", 1111, "127.0.0.1", 1111); sshSession.AddForwardedPort(port); port.Start(); NpgsqlConnectionStringBuilder csb = new NpgsqlConnectionStringBuilder(); csb.Database = "nombreBD"; csb.Host = "127.0.0.1"; csb.Port = 1111; csb.Username = "***"; csb.Password = "******"; csb.Pooling = false; conn = new NpgsqlConnection(); conn.ConnectionString = csb.ConnectionString; conn.Open();

...

Y una vez realizada la conexión, con una subconsulta que me dio el responsable, obtendremos los datos de ocupación del chat (tanto del de arsys como del de piensa). Esta consulta me la dieron ya hecha, porque estaba perfectamente testeada y controlada para que no sature la base de datos en ningún momento, ya que se trata de una base de datos muy sensible, la cual no deberemos saturar en ningún momento.

Cabe destacar que con respecto a la creación del tunel SSH con “Port forwarding”, no había demasiada información por internet, por lo que fue bastante costoso dar con la implementación correcta. Además, tuve algunos problemas que me costó solventar, ya que cuando hacía las consultas a la BD postgreSQL, la primera consulta la hacía bien, pero a partir de la segunda me devolvía una excepción. Tras el correspondiente análisis se comprobó que la excepción provenía de un problema al crear la conexión.

Actualización de web de forma automatizada

Para actualizar la web de forma automática, tanto los datos actuales, como la gráfica con los porcentajes de la última hora, he utilizado la librería citada anteriormente “SignalR”.

Para usar esta librería, únicamente habrá que importarla y seguidamente crear un Hub (AtencionHub) y un Startup, dentro de una carpeta “Hubs”, que serán usados para mandar y recibir los mensajes con los clientes en tiempo real:

El Hub (AtencionHub), será el objeto encargado de establecer el canal de comunicación entre el servidor y los clientes. En este caso no tendrá ningún método, puesto que no se recibirán mensajes desde los clientes, únicamente se enviarán mensajes desde el servidor, pero de todas maneras es necesario crearlo.

El Startup, es la clase invocada por el motor de SignalR al arrancar la web, y se encargará de mapear los hubs de la solución. En este caso será lo más básico para que funcione el sistema:

using Microsoft.Owin; using Owin;

[assembly: OwinStartup(typeof(ControlAtencion.Hubs.Startup))] namespace ControlAtencion.Hubs { public class Startup { public void Configuration(IAppBuilder app) { // Any connection or hub wire up and configuration should go here app.MapSignalR(); } } }

Para enviar los estadísticos desde el servidor a los clientes conectados, en primer lugar deberemos obtener la referencia al hub creado anteriormente, y seguidamente enviaremos los últimos datos, obtenidos mediante la persistencia, a todos los clientes conectados, llamando al método adecuado para ello.

El código del servidor encargado de realizar lo anteriormente descrito será el siguiente:

IHubContext context = GlobalHost.ConnectionManager.GetHubContext<AtencionHub>();

context.Clients.All.actualizaControlDiario(estadisticoTelefono, estadisticoChatArsys, estadisticoChatPiensa);

En el lado de los clientes (en el navegador), los estadísticos se recibirán por javascript, de la siguiente manera:

$(document).ready(function () {

//Arrancamos la conexión con el hub: var atencionHub = $.connection.atencionHub;

atencionHub.client.actualizaControlDiario = function (estadisticoTelefono, estadisticoChatArsys, estadisticoChatPiensa) { //Código que actualizaría la web } }

Creación de la vista para mostrar en el navegador del cliente

En cuanto a la vista que se mostrará en el navegador, merece especial atención la gráfica que muestra los últimos porcentajes obtenidos, ya que es creada de forma dinámica desde el controlador, mediante la librería Highcharts descrita anteriormente, y no había demasiada documentación al respecto en internet. Y una de las cosas que más costó fue el configurar la propia gráfica para personalizar la información mostrada al pasar el ratón sobre la misma (Tooltip).

Para crear dicha gráfica, se han seguido los siguientes pasos:

Obtener un listado con los estadísticos a mostrar.

Crear el objeto "Highcharts", que representará el gráfico.



Crear tres objetos "Series" para declarar cada una de las series que contendrá el gráfico. En este caso serían "Teléfono", "Chat(arsys)" y "Chat(piensa)". Posteriormente les asignaremos el nombre, color y array de datos que contendrán cada una.

Crear los objetos "YAxis" y "XAxis" que representan los dos ejes de la gráfica. Al eje "X" le asignaremos las horas de cada uno de los estadísticos y con el eje "Y" configuraremos el título de dicho eje, el mínimo y máximo, etc.

Asignar todos los objetos creados al objeto "Highcharts".

Cuyo código podremos ver en el anexo “Creación objeto de gráfica”.

Y la gráfica quedaría como vemos a continuación:

4.3.2 Desarrollo Sprint 2

A lo largo de la realización del sprint se desarrollará la funcionalidad de envío y muestreo de alertas.

Se tratará de mostrar un listado con las últimas alertas surgidas, las cuales se irán añadiendo a un listado de forma dinámica, sin necesidad de actualizar la página web, mediante SignalR, como ya describimos en el sprint anterior.

Además, se enviará un correo a las direcciones configuradas, mostrando dichas alertas.



Implementación del Windows Service

Pero, además de esta nueva funcionalidad, también se ha visto oportuno hacer algunos cambios en la estructura del proyecto, ya que, al reunirme con el tutor a la mitad del sprint anterior, se llegó a la conclusión de que sería mucho mejor, y mucho más fiable, que la propia obtención de datos de medios externos, y posterior almacenamiento en nuestra base de datos, se hiciera mediante otra aplicación diferente que desde la propia aplicación web.

Esto es así porque en el caso de que hubiera que hacer algún tipo de mantenimiento en la web, o que esta se viese afectada por algún tipo de problema o lo que fuese, también se vería interrumpida la captación de datos.

Por este motivo, se decidió crear un Windows Service que estuviese constantemente capturando los datos y almacenándolos en nuestra base de datos mediante una tarea periódica, y ya la web únicamente tendría que consultar los datos en nuestra base de datos mediante la subtarea con la periodicidad deseada.

Por lo que la arquitectura del sistema sufriría la siguiente transformación:

El código de implementación del Windows Service podríamos verlo en el anexo “Código Windows Service”.

Y una vez compilado el proyecto del Windows Service, si está todo correcto se nos generará el “.exe” del propio servicio, y para instalarlo deberemos abrir como administrador el “Símbolo del sistema para desarrolladores de VS”, que lo solemos encontrar en la ruta “C:\Program



Files (x86)\Microsoft Visual Studio X\Common7\Tools\Shortcuts\”, y ejecutar los siguientes comandos:

C:\>InstallUtil ServicioControlAtencion.exe

Y en caso de que estemos realizando pruebas, y queramos desinstalar el servicio para volverlo a instalar, usaremos los siguientes comandos:

C:\>sc stop ServicioControlAtencion

C:\>sc delete ServicioControlAtencion


Se crearán las tablas “Alertas” y “CorreosAlerta” de la base de datos, y el objeto “Alerta” del modelo, para almacenar y manipular esos datos. La definición de dichos recursos ya fue explicada en la sección de diseño.

Generación de las alertas

Para generar las alertas se añadirá a la propia tarea periódica, descrita en el sprint anterior, la comprobación de los porcentajes de atención de los distintos medios de atención al cliente, y una vez sobrepasados los porcentajes límite, y si la hora actual se encuentra dentro del horario de alertas, se generarán dichas alertas.

Al generar las alertas, estas se añadirán a la tabla “Alertas”, se enviará un correo a la dirección de correo indicada, y de igual manera que lo hacíamos para los estadísticos, mediante SignalR, se pasarán las alertas a los navegadores de los clientes para que se añadan al listado de últimas alertas de forma automática, sin necesidad de recargar la web.

*En sprints posteriores se añadirá la funcionalidad de configurar los límites de porcentaje, el horario, los correos de alerta, etc. Por ahora se han dejado las horas límite como [8, 22] y los porcentaje límite como [80, 95].

El código del servidor encargado de comprobar las alertas, gererarlas, y enviarlas, podremos encontrarlo en el anexo “Código generación de alertas”.



Actualización de web para añadir nuevas alertas



//Arrancamos la conexión con el hub: var atencionHub = $.connection.atencionHub;

atencionHub.client.enviarAlertas = function (alertas) { //Código que añadiría las nuevas alertas al listado correspondiente } }

Además, como se puede ver en la siguiente imagen, al añadir nuevas alertas al listado, estas quedarán marcadas con fondo amarillo, para que se pueda distinguir perfectamente que son nuevas alertas, y bastará con pinchar sobre cada una de ellas para que se les quite este color, o hacer doble click sobre el mismo listado para que se les quite el fondo amarillo a todas a la vez.

Esto se ha decidido hacer así, ya que como se trata de una aplicación web que se actualizará de forma automática, al tener la misma abierta durante un largo período de tiempo, podría ser posible que al aparecer nuevas alertas se nos pasaran por alto, por lo que se decidió marcarlas de esta manera.

Aquí ha sido donde se ha utilizado el plugin Custom-content-scroller, que ya citamos en el apartado de recursos utilizados, para crear un listado de alertas más personalizado y minimalista, que por ejemplo en este caso, no muestra la barra de desplazamiento vertical hasta que no tenemos el puntero del ratón sobre el mismo.

4.3.3 Desarrollo Sprint 3 Con la realización de este sprint mostraremos la información detallada de los distintos agentes que se encuentran actualmente en sus puestos de trabajo atendiendo las posibles incidencias. De esta manera, los responsables podrán controlar la actividad y eficiencia de cada uno de los agentes (trabajadores) del departamento.



Esta información la dividiremos en dos tablas para diferenciar la actividad del teléfono y la actividad del chat.


Se crearán las tablas “AgenteChat” y “AgenteTelefono” de la base de datos, y los mismos objetos, para almacenar y manipular esos datos. La definición de dichos recursos ya fue explicada en la sección de diseño.

Además crearemos la clase auxiliar “ControlDiario” en el modelo, la cual será utilizada para actualizar todos los datos de la página principal de control diario, que tendrá los siguientes datos:



Que como podemos comprobar, corresponden a cada uno de los datos creados anteriormente (en este sprint y en los anteriores) para actualizar cada una de las zonas de la página principal de control diario.

Obtención de información de los agentes al chat

La herramienta que utilizan en la empresa para realizar y gestionar el soporte a través de chat es “islonline”, que se trata de un software de soporte remoto para las empresas, y del cual hemos podido encontrar documentación en su propia página web.

Para llevar a cabo la obtención de la información referente a los agentes que están atendiendo el chat, se realizarán peticiones http al servidor que los responsables me han indicado, pasando los argumentos necesarios y recibiendo las respuestas en JSON, de lo cual hemos podido encontrar información en la documentación citada.

Estas son las peticiones que he utilizado para obtener diferentes datos:

utils/login/1

{"user":"a", "pwd":"a"}

Utilizada para logear con los datos user y password indicados en el JSON.

islpronto/supporter/get/list/1

{"domain":"arsys"}

Utilizada para obtener la lista de todos los agentes registrados para la herramienta, los cuales se filtrarán para quedarnos únicamente con los del Departamento de Soporte.

islpronto/supporter/info/get/single/1

{"user":"usuario"}

Utilizada para obtener información detallada del usuario pedido, concretamente para obtener los chats que tiene activos y la última hora de creación del chat más reciente.

utils/logout/1

Utilizada para desloguear una vez realizadas las peticiones deseadas.

Y también cabe indicar que, para realizar las peticiones anteriores, enviando el JSON indicado, etc., se realizarían las peticiones http como en el siguiente ejemplo del login:

http://***/webapi2?method=utils/login/1&he=JSON1&heo=JSON1&hedata={"user":"***","pwd":"******"}

Recibiendo las respuestas en JSON con el siguiente aspecto:

{"data":{"sid":"2_O5IOZ3RHDS_5_KMv5cAjKDVmYun3NEB9piIhubb0gh1Oon.DXsPL6uArcwgwFUjC2RRZ411nXxD3rtoHwzK.g9VYY9fMP8GyZlphZ5GK4szYbANXBAABgQ--"},"result":{"code":"OK","hs":"2_O5IOZ3RHDS_5_KMv5cAjKDVmYun3NEB9piIhubb0gh1Oon.DXsPL6uArcwgwFUjC2RRZ411nXxD3rtoHwzK.g9VYY9fMP8GyZlphZ5GK4szYbANXBAAB--","server":-1}}



Para obtener y parsear la información necesaria de estas respuestas, se ha utilizado la librería “System.Web.Script.Serialization”, citada anteriormente en el apartado de recursos externos utilizados.

Así, de esta manera, obtendremos desde el “Windows service” ya descrito, la lista de agentes que se encuentran atendiendo al chat y la información de cada uno de ellos, que seguidamente almacenaremos en la base de datos.

Obtención de información de los agentes al teléfono

Para obtener los datos de los agentes que están atendiendo al teléfono, haremos uso de dos fuentes distintas.

Por un lado, usaremos el mismo método ya descrito anteriormente en el sprint 1 para obtener el porcentaje de ocupación del teléfono, de tal manera que leeremos el mismo fichero binario y de la misma manera, pero en este caso en vez de considerar todas las llamadas en un conjunto, las iremos agrupando por agente en un objeto de tipo dictionary. Este objeto tendrá por key el identificador del agente y por value un int en el cual iremos almacenando dichas llamadas.

Por otro lado, obtendremos los demás datos mediante un nuevo método, conectándonos por telnet a un servidor, con unas credenciales que me ha facilitado mi responsable.

La conexión y envío de los diferentes comandos al servidor Telnet la haríamos a través de un objeto System.Net.Sockets.TcpClient, mediante el cual obtendremos un string con la siguiente información, la cual posteriormente parsearemos para quedarnos con los datos necesarios.

Como podemos ver, la información de un agente la obtendremos con el comando “agacd idAgente”, que lo mandaremos escribiendo en el socket TcpClient ya citado anteriormente.

Y de esta manera, obtendremos desde el “Windows service” ya descrito, la lista de agentes que se encuentran atendiendo al teléfono y la información de cada uno de ellos, que seguidamente almacenaremos en la base de datos.



Actualización de web

Como ya hemos descrito anteriormente en este mismo sprint, hemos creado la clase auxiliar “ControlDiario”, que se utilizaría para actualizar toda la página principal de Control diario.

Para esto hemos hecho unos pequeños cambios, como son unificar los mensajes del Signal Hub que ya describimos en los anteriores sprints en un único mensaje, a través del cual pasaremos el objeto ControlDiario comentado, que contendrá toda la información que antes se pasaba en esos mensajes, pero en este caso unificada en este nuevo objeto.

El código del servidor encargado de actualizar toda la web de Control diario, y que se llamaría periódicamente mediante la subtarea, pasaría a ser el siguiente:

context.Clients.All.actualizaControlDiario(new ControlDiario(estTlf, estArsys, estPiensa, alertas, Persist_AgenteChat.getAgentesChat(), Persist_AgenteTelefono.getAgentesTelefono()));



//Arrancamos la conexión con el hub: $.connection.hub.start();

//Actualizamos toda la página de Control diario atencionHub.client.actualizaControlDiario = function (controlDiario) { actualizaGrafica(controlDiario.EstadisticoTelefono, controlDiario.EstadisticoChatArsys, controlDiario.EstadisticoChatPiensa); actualizaCajetines(controlDiario.EstadisticoTelefono, controlDiario.EstadisticoChatArsys, controlDiario.EstadisticoChatPiensa); actualizaAlertas(controlDiario.Alertas); actualizaDetalleChat(controlDiario.AgentesChat); actualizaDetalleTelefono(controlDiario.AgentesTelefono);

};

}

Una vez actualizada la página web, la información detallada del chat quedará mostrada de la siguiente manera:



Como podemos observar, podrá haber algunos agentes que esten etiquetados con una etiqueta amarilla, y otros que estén sin etiquetar, lo cual significará que en el caso de que estén etiquetados, el agente para ese dominio estará en estado “Ocupado”, y si está sin etiquetar estará en estado “Activo”.

También nos llama la atención el campo de los minutos que lleva el último chat abierto, que nos lo encontramos en diferentes colores, gris si lleva menos de 15 minutos abierto, naranja si lleva más de 15 minutos pero menos de 30 minutos, y rojo si lleva más de 30 minutos abierto dicho chat.

Esta diferenciación de colores si ha hecho así para que se diferencie de forma más rápida e intuitiva cuando se de cada uno de los diferentes casos.

En el caso de la información detallada del teléfono, quedará mostrada de la siguiente manera:

En este caso podemos observar que hay agentes etiquetados con etiquetas rojas o verdes, lo que indicará si el agente está atendiendo una llamada o recibiendo una (etiqueta roja), o si el agente está libre (etiqueta verde).



Toda la página de Control diario completa tendría el siguiente aspecto:

4.3.4 Desarrollo Sprint 4 Durante la realización de este sprint se desarrollará una sección de configuración desde la cual se configurarán diferentes parámetros referentes a las alertas que serán enviadas cuando se sobrepasen ciertos porcentajes de atención al cliente.

Parámetros de configuración:

Porcentajes límite, inferior y superior, que una vez sobrepasados se generará una alerta en el sistema.

Listado de direcciones de correo a los que se enviará un email en el momento que se produzca una alerta.

Franja horaria en la cual se tendrán en cuenta dichas alertas.

También cabe mencionar, que estos parámetros configurables, fueron establecidos en código como “fijos” en el Sprint 2 (Generación de las alertas), con la intención de añadir la funcionalidad de configurarlos posteriormente, como es en este caso.



En principio es todo normal, salvo los interruptores On/Off, que se ha utilizado la librería “Bootstrap Toggle”, citada anteriormente en el apartado de recursos externos utilizados.


Se creará la tabla “LimitesAlerta” de la base de datos, como el objeto “LimiteAlerta” del modelo, para almacenar y manipular los datos de configuración. La definición de ambos recursos ya fue explicada en la sección de diseño.

Programación del sistema de persistencia

Merece especial mención todo el sistema que hay por debajo para guardar la configuración una vez hayamos realizado modificaciones en cualquier opción.

Podremos guardar dicha modificación de manera voluntaria, pulsando sobre el botón azul de la parte inferior, el cual se activará y tendrá como texto “Guardar” cuando

Cuando realicemos modificaciones en cualquiera de las opciones, estas se enviarán al servidor para guardarse en base de datos, y se podrá hacer mediante dos vías:

Voluntariamente

Una vez modifiquemos cualquiera de estas opciones, el botón azul de la parte inferior se activará y tendrá como texto “Guardar”. De esta manera, podremos pulsarlo y se enviará la información al servidor para ser actualizada en la base de datos.

Automáticamente

Una vez modifiquemos cualquiera de las opciones, se activará un timeout, que una vez sobrepasado el tiempo fijado (le he puesto 3 segundos), se lanzará el guardado de forma automática mediante Ajax.

Una vez que se lleve a cabo el guardado a través de cualquiera de las dos vías, el botón azul citado se desactivará y cambiará su texto a “Guardado”.

Además, en caso de que se pretenda abandonar la página de configuración antes de que se hayan guardado los cambios, bien pulsando sobre cualquier enlace o tratando de cerrar la pestaña del navegador, se nos mostrará un aviso advirtiéndonos de que los cambios realizados todavía no han sido guardados, y dándonos la opción a abandonar la página o a permanecer en ella.



Otro detalle a remarcar es que cada vez que se realizan cambios y se envían al servidor para ser guardados, únicamente se enviarán los campos que han sido modificados, no todo el contexto, a fin de conseguir una mayor eficiencia en el proceso.

Para conseguir esto, lo que se hace es, mediante javascript, ir guardando en un array los campos que se van modificando (el id del campo y su nuevo valor).

arrayElementos['limit[' + contadorElements + '].Key'] = id; arrayElementos['limit[' + contadorElements + '].Value'] = val; contadorElements++;

Y una vez que se ha enviado el array al servidor para ser guardado, el array se vaciará automáticamente.

4.3.5 Desarrollo Sprint 5 En este sprint se desarrollará una sección en la que se mostrará la información histórica sobre los porcentajes de los distintos medios de atención al cliente.

Esta información se mostrará por medio de una gráfica en la que se podrá visualizar el porcentaje atendido de los diferentes medios de atención al cliente en cada uno de los días del mes actual.

Además, también se mostrarán unos cajetines con los porcentajes mensuales de cada medio de atención.

Para obtener todos los datos del mes, que se mostrarán en la gráfica deberemos añadir un nuevo método a la persistencia estadísticos, el cual se encargaría de consultar los últimos datos obtenidos en cada día del mes actual, hasta el día en el que nos encontremos.

Remarcar que cuando digo los últimos datos de cada día, eso es así porque los datos almacenados de un mismo día son acumulativos, y siempre los datos más recientes serán los que valen, por lo que los últimos datos recogidos en un día para los diferentes medios de atención al cliente serán los que obtendremos.

public static List<Estadistico> getDatosMes(DateTime fechaActual)

{

...

}

Una vez realizado lo que se pretendía realizar en este sprint, todavía sobraba bastante tiempo, ya que no se calculó del todo bien lo que costaría en implementar este apartado, por lo que se ha ampliado rediseñando el contenido de los emails de alerta, para que tengan un mejor aspecto.

Además, también se restringirá el acceso a la aplicación para que únicamente puedan acceder los responsables del Departamento de Soporte.

Modificación del aspecto de los emails

El aspecto que tenían los emails anteriormente era un aspecto muy básico:

Y se ha creado una vista en html para darles a los emails un formato más visual:

Restricción de acceso a la aplicación

Como ya se detalló, a la aplicación únicamente tendrán acceso los responsables de soporte, por lo que se restringirá el acceso para que únicamente sean estos los que puedan acceder a cualquier parte de la aplicación.

Esto se conseguirá añadiendo ciertas opciones en el fichero de configuración “Web.config”:

<system.web> <compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5" /> <authentication mode="Windows" /> <authorization> <allow roles="Dominio responsables soporte"/> <deny users="*" /> </authorization> </system.web>

Que como podemos ver serían:

<deny users=”*”/>: Para denegar el acceso a cualquier usuario por defecto.

<allow roles=”Dominio responsables soporte”/>: Para permitir el acceso a los responsables de soporte, que pertenecen al dominio indicado.



5 PRUEBAS Y DESPLIEGUE En cuanto a las pruebas de la aplicación, se han ido realizando a lo largo de toda la fase de implementación, ya que el método utilizado para realizar dicha fase ha sido el Scrum.

Puesto que “Scrum” se trata de un método iterativo, sobre todo al finalizar cada una de sus iteraciones (sprints) ha sido cuando se han realizado las pruebas más minuciosas, a observación de mi tutora, Lorea Revilla. Aunque también hay que decir que, puesto que los usuarios finales de la aplicación (responsables del Departamento de Soporte) han estado accesibles durante todo el desarrollo, a menudo se recurría a ellos para aclarar ciertas dudas o probar ciertos detalles de la aplicación.

En cuanto al despliegue de la aplicación en la intranet, este se llevó a cabo a través del técnico de soporte, a quien se le facilitó el proyecto completo y otros datos relevantes, como el script de creación de la base de datos, nombre que usaría la aplicación, etc.

Además, otro dato muy importante que le facilité fue la información sobre donde se encontraban las cadenas de conexión y otros datos configurables, los cuales se encuentran en el fichero “Web.config” de la raíz del proyecto, ya que fue especialmente importante para cambiar las rutas de conexión a base de datos, teniendo en cuenta que la base de datos cambiaría de equipo. En dicho fichero también se encuentra la configuración de accesos a la aplicación, como ya se explicó al final del sprint 5.

En este proceso de despliegue no hubo demasiados problemas, pero si alguno relacionado con rutas de enlaces, los cuales no fueron complicados de solucionar.

6 CONCLUSIONES Como conclusiones destacadas una vez llevada a cabo la realización de este proyecto tendríamos las siguientes:

Al haber realizado dicho proyecto, como un proyecto de cierta envergadura y magnitud, en un entorno empresarial, me ha acercado bastante a lo que podrá ser un “día a día” en un entorno laboral convencional.

La realización de reuniones y la demostración de funcionalidades y objetivos alcanzados me han aportado cierta comodidad y soltura a la hora hablar y razonar abiertamente en un grupo de trabajo.

Puesto que se han utilizado tecnologías muy similares a las usadas en la realización de las prácticas (HTML, ASP.NET, Bootstrap, SQL Server, etc), las cuales no conocía anteriormente, me ha servido para afianzarlas y profundizarlas aún más. Además de adquirir otros nuevos conocimientos.

He aprendido a asumir responsabilidades y a tomar decisiones importantes ante la aparición de ciertos imprevistos durante la realización del proyecto.

El haber realizado una planificación previa al comienzo de realización del proyecto nos ha permitido el cumplir con los plazos y realizarlo e una forma eficiente y organizada.



7 POSIBLES MEJORAS A lo largo del desarrollo del proyecto fueron surgiendo algunas posibles mejoras que podrían ser añadidas en futuras actualizaciones de la aplicación:

Añadir un calendario en el área de configuración, desde el cual se puedan marcar los días deseados en los que no se enviarán alertas al correo, el cual será útil para marcar días festivos, fines de semana, etc., en los que no se quieren recibir dichas alertas.

Añadir una zona de administración, desde la cual se puedan gestionar los accesos a la aplicación, y en la que se muestren los últimos cambios de configuración realizados por los usuarios de la misma.

Mostrar históricos de meses anteriores, a parte del mes actual.

Obtener estadísticas diarias y mensuales de los diferentes agentes que trabajan en el Departamento de Soporte.

8 AGRADECIMIENTOS En primer lugar, agradecer a la empresa Arsys por haberme brindado esta oportunidad de realizar con ellos tanto las prácticas como el proyecto de fin de grado, ya que el trato ha sido inmejorable y en todo momento me he sentido como en casa.

Y de la propia empresa, hacer especial mención de Lorea Revilla Riocerezo, Javier Pesquera Moreno, Nerea Tobía Díez y Sergio Elías Gómez por estar siempre ahí despejando cualquier duda y aportando sus recomendaciones. Sin olvidarme de mis compañeros de garita Javier López Ramos y Álvaro Nalda Saenz que también han sido un gran apoyo y han hecho que el trabajo diario haya sido más ameno y divertido.

A Laureano Lamban Pardo por dirigir este proyecto y aconsejarme con todas las dudas que me han surgido en cuanto a la realización del mismo.

A mi familia, por haber conseguido con gran esfuerzo y paciencia que todo esto haya sido posible.

Y finalmente, agradecer también a la Universidad de La Rioja y más concretamente a los profesores de Informática que me han formado a lo largo de estos años, por haberme aportado los conocimientos que tengo a día de hoy y que han hecho posible la realización de este proyecto.



9 BIBLIOGRAFÍA

Documentación sobre ASP.NET http://www.asp.net/mvc

Documentación sobre SignalR http://www.asp.net/signalr

StackOverflow http://stackoverflow.com/

Recursos sobre HTML, CSS y javascript http://www.w3schools.com/

Documentación sobre Bootstrap http://getbootstrap.com/

Repositorio de TFGs de la biblioteca de la Universidad de La Rioja http://biblioteca.unirioja.es/

http://www.asp.net/mvc

http://www.asp.net/signalr

http://stackoverflow.com/

http://www.w3schools.com/

http://getbootstrap.com/

http://biblioteca.unirioja.es/

10 ANEXO

Creación objeto de gráfica

List<Estadistico> estadisticos = new List<Estadistico>(); estadisticos = Persist_Estadistico.getDatosDia(36); Series seriesLlamadas = new Series(); seriesLlamadas.Name = "Llamadas"; seriesLlamadas.Color = System.Drawing.ColorTranslator.FromHtml("#7CB5EC"); seriesLlamadas.Data = new Data(Persist_Estadistico.getPorcentajesByNombre(estadisticos, "Teléfono").ToArray()); Series seriesChatArsys = new Series(); seriesChatArsys.Name = "Chat(arsys)"; seriesChatArsys.Color = System.Drawing.ColorTranslator.FromHtml("#004ab9"); seriesChatArsys.Data = new Data(Persist_Estadistico.getPorcentajesByNombre(estadisticos, "Chat(arsys)").ToArray()); Series seriesChatPiensa = new Series(); seriesChatPiensa.Name = "Chat(piensa)"; seriesChatPiensa.Color = System.Drawing.ColorTranslator.FromHtml("#ff9933"); seriesChatPiensa.Data = new Data(Persist_Estadistico.getPorcentajesByNombre(estadisticos, "Chat(piensa)").ToArray()); XAxis xaxis = new XAxis(); xaxis.Categories = Persist_Estadistico.getHoras(estadisticos).ToArray(); YAxis yaxis = new YAxis(); yaxis.Title = new YAxisTitle { Text = "Porcentaje(%)" }; yaxis.PlotLines = new[] { new YAxisPlotLines { Value = 0, Width = 1, Color = System.Drawing.ColorTranslator.FromHtml("#808080") } }; yaxis.ShowLastLabel = true; yaxis.Min = 0; yaxis.Max = 100; Highcharts graficoCaliente = new Highcharts("graficoCaliente"); graficoCaliente.SetLegend(new Legend { ItemDistance = 20 }); graficoCaliente.SetCredits(new Credits { Enabled = false }); graficoCaliente.SetXAxis(xaxis); graficoCaliente.SetYAxis(yaxis); graficoCaliente.SetSeries(new[] { seriesLlamadas, seriesChatArsys, seriesChatPiensa }); graficoCaliente.SetTooltip(new Tooltip { ValueSuffix = "%", HideDelay = 0, Shared = true, Crosshairs = new Crosshairs(true), PointFormat = "\u25CF {series.name}: {point.y} \u00a0\u00a0\u00a0\u00a0 Total: {point.total} \u00a0\u00a0\u00a0\u00a0 Atendidos: {point.atendidos} " }); graficoCaliente.SetTitle(new Title { Text = "" });



Código Windows Service

class WindowsService : ServiceBase { private Timer timer; TimeSpan timerInterval; public WindowsService() { this.ServiceName = "ServicioControlAtencion"; timerInterval = new TimeSpan(0, 3, 0); } static void Main() { ServiceBase.Run(new WindowsService()); } protected override void Dispose(bool disposing) { base.Dispose(disposing); } protected override void OnStart(string[] args) { //Inicialización de variables necesarias. timer = new System.Threading.Timer(new System.Threading.TimerCallback(callBack), null, 0, (int)timerInterval.TotalMilliseconds); } protected override void OnStop() { timer.Change(System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite); timer.Dispose(); timer = null; } private void callBack(object state) { //Código de obtención de datos y almacenamiento en base de datos }

}

Código generación de alertas

DateTime horaActual = estadCalientes[0].FechaHora; Estadistico estTlf = estadCalientes.Find(x => x.Nombre == "Teléfono"); Estadistico estArsys = estadCalientes.Find(x => x.Nombre == "Chat(arsys)"); Estadistico estPiensa = estadCalientes.Find(x => x.Nombre == "Chat(piensa)"); List<Alerta> alertas = new List<Alerta>(); if (horaActual.Hour >= 8 && horaActual.Hour < 22) { if (80 > estTlf.Porcentaje && estTlf.Porcentaje > -1) { alertas.Add(new Alerta("Teléfono", estTlf.FechaHora, false, estTlf.Porcentaje)); } else if (95 < estTlf.Porcentaje) { alertas.Add(new Alerta("Teléfono", estTlf.FechaHora, true, estTlf.Porcentaje)); } if (80 > estArsys.Porcentaje && estArsys.Porcentaje > -1) { alertas.Add(new Alerta("Chat(arsys)", estArsys.FechaHora, false, estArsys.Porcentaje)); } else if (95 < estArsys.Porcentaje) { alertas.Add(new Alerta("Chat(arsys)", estArsys.FechaHora, true, estArsys.Porcentaje)); } if (80> estPiensa.Porcentaje && estPiensa.Porcentaje > -1) { alertas.Add(new Alerta("Chat(piensa)", estPiensa.FechaHora, false, estPiensa.Porcentaje)); } else if (95 < estPiensa.Porcentaje) { alertas.Add(new Alerta("Chat(piensa)", estPiensa.FechaHora, true, estPiensa.Porcentaje)); } } if (alertas.Count > 0) { Persist_Alerta.addAlertas(alertas); context.Clients.All.enviarAlertas(alertas); if (limite.Correos != null && limite.Correos.Count > 0) { enviarMail(limite, alertas); } }

Monitorización de Atención al Cliente en tiempo real · El proyecto de fin de grado descrito en...

Documents

Transcript of Monitorización de Atención al Cliente en tiempo real · El proyecto de fin de grado descrito en...