Monitorización de productividad de atención al cliente · Dado que las tablas origen están...

David Rueda Lejárraga

Beatriz Pérez Valle

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Monitorización de productividad de atención al cliente

Autor/es

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

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

Monitorización de productividad de atención al cliente, trabajo fin de gradode David Rueda Lejárraga, dirigido por Beatriz Pérez Valle (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 los titulares del copyright.

Facultad de Ciencias, Estudios Agroalimentarios e Informática

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática


Alumno:

David Rueda Lejárraga

Tutores:

Beatriz Perez Valle

Logroño, junio de 2015

Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación

Grado en Ingeniería Informática Título

Monitorización de productividad de atención al cliente Autor/es

David Rueda Lejarraga Tutor/es

Beatriz Pérez Valle Departamento

Departamente de Matemáticas y Computación Curso académico

2014-2015


Resumen

En la actualidad, los valores más importantes de una empresa son los empleados. No obstante, es posible que por alguna razón (motivos personales, laborables…) éstos no respondan correctamente. Por ello, a la empresa conviene seguir un control para ver cuál es el rendimiento de sus empleados. Existen diferentes formas de realizar esta tarea, siendo la manera más adecuada aquella que afecte lo menos posible al trabajo diario tanto del empleado como del responsable de la empresa que desea realizar dicho control.

El objetivo de Arsys Internet S.L. es disponer de una herramienta que permita realizar un seguimiento y control del rendimiento de sus empleados, sin que ello afecte en el trabajo diario de los mismos. Este proyecto fin de grado pretende llevar a cabo el desarrollo de dicha herramienta particularizando a los empleados del Departamento de Soporte. Además, la herramienta desarrollada permitirá consultar determinada información sobre la atención que reciben los clientes de Arsys cuando solicitan ayuda al Departamento de Soporte.

Abstract

At present, the most important values of a company are employees. However, it is possible that for some reason (personal or business issues... ) they do not respond properly. Therefore, the company should follow a control to check the performance of their employees. There are different ways to accomplish this task, being the most suitable way that which has less impact on the daily work of both the employees and the person in charge of carrying out such a control.

The aim of Arsys Internet S.L. is to have a tool to track and control the performance of their employees, without affecting their daily work. This project attempts to carry out the development of this tool focusing mainly on the employees of the Support Department. In addition, the tool will allow to consult specific information regarding the attention provided to the clients when they ask for help to the Support Department.

1


CONTENIDO 1. DOCUMENTO DE OBJETIVOS DEL PROYECTO.............................................................4

1.1. INTRODUCCIÓN ................................................................................................4 1.2. ANTECEDENTES ................................................................................................4

1.2.1. ACERCA DE ARSYS .................................................................................4 1.2.2. MOTIVACIÓN .......................................................................................4

1.3. ALCANCE ........................................................................................................5 1.4. PLANIFICACIÓN DEL PROYECTO.............................................................................5

1.4.1. EDT ..................................................................................................5 1.4.2. ESTUDIO DE HORAS ...............................................................................6 1.4.3. CALENDARIO DE TRABAJO Y DIAGRAMA DE GANTT .........................................8

1.5. PLAN DE RIESGOS .............................................................................................9 1.6. METODOLOGÍA .............................................................................................. 11

2. ANÁLISIS ................................................................................................................ 12

2.1. CAPTURA DE REQUISITOS.................................................................................. 12 2.1.1. TERMINOLOGÍA .................................................................................. 12 2.1.2. REQUISITOS FUNCIONALES .................................................................... 13 2.1.3. REQUISITOS NO FUNCIONALES ................................................................ 14

2.2. DIAGRAMAS DE CASOS DE USOS ......................................................................... 15 2.2.1. DIAGRAMA DE CASOS DE USO ................................................................. 15 2.2.2. ESPECIFICACIÓN DE CASOS DE USO ........................................................... 16

2.3. TECNOLOGÍAS A UTILIZAR ................................................................................. 20 2.4. PLAN DE PRUEBAS........................................................................................... 21

3. DISEÑO .................................................................................................................. 22

3.1. PROTOTIPOS DE LA INTERFAZ WEB ...................................................................... 22 3.2. ARQUITECTURA DEL SISTEMA............................................................................. 33 3.3. DISEÑO DE LA BASE DE DATOS............................................................................ 33

3.3.1. ANTECEDENTES .................................................................................. 33 3.3.2. DIAGRAMA ENTIDAD-RELACIÓN.............................................................. 36 3.3.3. DISEÑO LÓGICO .................................................................................. 37

3.4. DISEÑO DE CLASES .......................................................................................... 38

4. IMPLEMENTACIÓN ................................................................................................. 39

4.1. ESTRUCTURA DE LA APLICACIÓN ......................................................................... 39 4.2. LIBRERÍAS UTILIZADAS...................................................................................... 39

4.2.1. LIBRERÍAS DE C# ................................................................................. 39 4.3.2. LIBRERÍAS Y MÉTODOS DE JQUERY ........................................................... 41

4.3. DESARROLLO DE LA APLICACIÓN ......................................................................... 43 4.3.1. IMPLEMENTACIÓN DE LA BD .................................................................. 43 4.3.2. IMPLEMENTACIÓN DE LA CAPA DE PERSISTENCIA.......................................... 44 4.3.3. IMPLEMENTACIÓN DEL MODELO DE DOMINIO ............................................. 46 4.3.4. IMPLEMENTACIÓN DEL MODELO DE NEGOCIO ............................................. 46 4.3.5. IMPLEMENTACIÓN DE LA CAPA DE PRESENTACIÓN ........................................ 46

2


5. PRUEBAS ............................................................................................................... 48

6. GESTIÓN DEL PROYECTO ........................................................................................ 49

6.1. SPRINT......................................................................................................... 49 6.1.1. SPRINT 1 .......................................................................................... 49 6.1.2. SPRINT 2 .......................................................................................... 49 6.1.3. SPRINT 3 .......................................................................................... 49 6.1.4. SPRINT 4 .......................................................................................... 49 6.1.5. SPRINT 5 .......................................................................................... 49

6.2. TIEMPO REAL ................................................................................................ 50

7. CONCLUSIÓN ......................................................................................................... 51

8. BIBLIOGRAFÍA ........................................................................................................ 52

9. ANEXO 1. ACTAS DE REUNIONES ............................................................................ 53

10. ANEXO 2. MANUAL DE INSTALACIÓN Y USO DE LA APLICACIÓN .............................. 58

3

Monitorización de productividad de atención al cliente Capítulo 1 - DOCUMENTACIÓN

1. DOCUMENTO DE OBJETIVOS DEL PROYECTO Esta memoria recoge todos los aspectos más destacables del proyecto “Monitorización de productividad de atención al cliente”, el cual ha sido desarrollado por David Rueda Lejárraga en la empresa Arsys Internet S.L (a partir de ahora se referirá solamente como Arsys). Tras su finalización, se pretende que la herramienta resultante de la realización del proyecto sea integrada dentro de todo el conjunto de herramientas de la propia empresa y sea accesible dentro de su red interna.

1.1. Introducción La herramienta ayudará a los responsables del Departamento de Soporte a controlar las estadísticas de sus empleados. En particular, la herramienta permitirá gestionar cuáles son las debilidades y fortalezas de un empleado, con el objetivo de mejorar el rendimiento del Departamento de Soporte.

1.2. Antecedentes

1.2.1. Acerca de Arsys

Arsys es un proveedor europeo de servicios de Presencia en Internet, Hosting Gestionado, Cloud Computing y Soluciones de Infraestructura TIC y que tiene presencia en España, Francia y Portugal. Además figura entre las compañías líderes en tecnología e innovación en Europa. Arsys tiene una plantilla de más de 300 empleados y alcanzó 42,7 millones de euros de facturación en 2011.

1.2.2. Motivación

Teniendo en cuenta la dedicación de la empresa y el gran número de empleados en plantilla, se podrá entender mejor el motivo del proyecto. Arsys es una gran empresa con un gran número de departamentos dentro del organigrama interno. Merece la pena destacar que, anteriormente a la realización de este proyecto, el alumno realizó sus prácticas externas en esta empresa y, en particular, en el Departamento de Soporte. En concreto, este departamento se encarga de ayudar a los clientes en los problemas técnicos de sus respectivas contrataciones. Dentro del Departamento de Soporte podemos encontrar dos tipos de empleados: responsables de soporte o empleados de soporte.

Durante el transcurso de las prácticas, los responsables de soporte se dieron cuenta de la dificultad que conllevaba realizar un control de las tareas llevadas a cabo por los empleados. Aunque en la empresa se registraban determinados aspectos relacionados con el seguimiento de las tareas realizadas por los empleados, se carecía de una aplicación que facilitara la explotación de dichos datos. En particular, esos datos se encontraban almacenados en varias tablas de una BD, carentes de relaciones entre ellas. Además, como dichas tablas no habían sido creadas para el seguimiento de las tareas realizadas por los empleados, sino que eran parte de otras aplicaciones de la empresa, muchas de ellas almacenaban datos innecesarios para realización del seguimiento de los empleados.

4


Teniendo esto en cuenta, se planteo la posibilidad de desarrollar una nueva herramienta dirigida principalmente a la ayuda de los responsables, para facilitar el control de los empleados de soporte. Además de dicha funcionalidad, la herramienta también permitiría poner en conocimiento a los distintos empleados del departamento de la información referente a ellos, como objeto de motivar su rendimiento. Asimismo se mostraría cierta información de aquellos clientes que se pongan en contacto con el departamento de soporte.

1.3. Alcance

El alcance de este proyecto comprende la creación de una aplicación web que permita la visualización de distintas estadísticas y el envío de éstas a sus correspondientes empleados. También deberá ofrecernos algunas estadísticas de los clientes que contactan con los empleados del Departamento de Soporte.

La herramienta tendrá que dar soporte al envío de correos de dos formas distintas: de forma manual, el cual deberá ser realizado por el usuario de la aplicación, y de forma automática, que deberá realizarse semanalmente.

Para la creación de esta aplicación web se utilizará el framework ASP.NET (en lenguaje c#), junto con HTML5 y CSS3. Dado que las tablas origen están implementadas en SQL Server, se utilizará SQL Server para gestionar la Base de Datos en la que se apoya la aplicación. Además se crearán una serie de procedimientos almacenados que se encargarán de realizar todas las consultas que necesitaremos para obtener las estadísticas.

1.4. Planificación del proyecto Para poder dar respuesta a todos los requisitos, cumpliendo los plazos del proyecto y sobre todo en un proyecto de este tamaño, deberemos crear una buena planificación.

1.4.1. EDT

Con objeto de una correcta planificación del trabajo, lo primero que se ha realizado es una Estructura de Descomposición del Trabajo (EDT). A continuación se muestra un diagrama con la estructura del proyecto y posteriormente se pasa a describir cada una de las tareas que lo conforman.

5


1.4.2. Estudio de horas

P.1. Gestión del TFG

Esta tarea se va a desarrollar durante todo el transcurso del TFG. Engloba tanto el seguimiento del TFG, como la creación de la memoria.

a) P.1.1. Seguimiento del TFG

Esta tarea consiste en realizar un seguimiento durante todo el TFG, apuntando de forma esquemática lo realizado en ese intervalo de tiempo. En particular, se realizarán sprints cada 15 días. Esfuerzo estimado: 5 horas.

b) P.1.2. Creación de la memoria

Esta tarea consiste en la redacción de la memoria del TFG. Esfuerzo estimado: 25 horas.

c) P.1.3. Planificación

Consiste en la creación de una planificación del proyecto. Se crearán una EDT, un diagrama de Gantt… Esfuerzo estimado: 15 horas.

d) P.1.4. Reuniones

Esta tarea consiste en la realización de las reuniones con el tutor académico del TFG y del tutor de la empresa. Esfuerzo estimado: 10 horas.

e) P.1.5. Defensa

Esta tarea consiste en la preparación de la defensa. Esfuerzo estimado: 15 horas.

6


P.2. Análisis de requisitos

Engloba todas las actividades propias del análisis necesarias para el desarrollo del proyecto.

a) P.2.1. Captura de requisitos

Esta tarea consiste en establecer los requisitos funcionales y no funcionales del proyecto. Esfuerzo estimado: 15 horas.

b) P.2.2. Diagramas de casos de uso

Esta tarea consiste en la creación de los diagramas de casos de uso con su correspondiente especificación. En los casos de uso que así lo requieran, se añadirán diagramas de actividad para su aclaración. Esfuerzo necesario: 15 horas.

P.3. Diseño

Consta de las actividades propias del diseño.

c) P.3.1. Diseño de la BD

Esta tarea consiste en la creación de un diagrama Entidad/Relación de la BD. Como se ha comentado anteriormente, ya disponemos de parte de la fuente de datos, por lo que en esta tarea deberemos realizar un análisis del esquema de la BD existente y posteriormente crear un buen diseño usando los datos anteriores e incorporando nuevos datos y relaciones según corresponda. Esfuerzo estimado: 15 horas.

d) P.3.2. Diseño de clases

Esta tarea consiste en la creación de un diseño de clases. Esfuerzo estimado: 13 horas.

e) P.3.3. Diseño de los prototipos

Esta tarea consiste en el diseño de los prototipos de interfaces. Esfuerzo estimado: 12 horas.

P.4. Implementación

En esta tarea trataremos la implementación de las distintas capas de la aplicación, así como la implementación de la BD.

a) P.4.1. Base de Datos

Esta tarea consiste en la implementación de la BD. Esfuerzo estimado: 35 horas.

b) P.4.2. Capa de persistencia

Esta tarea consiste en la implementación de la capa de persistencia. Esfuerzo estimado: 35 horas.

c) P.4.3. Capa de lógica de negocio

Esta tarea consiste en la implementación de la capa de lógica de negocio. Esfuerzo estimado: 35 horas.

7


d) P.4.4. Capa de presentación

Esta tarea consiste en la implementación de la capa de presentación. Esfuerzo estimado: 35 horas.

P.5. Pruebas

Comprende la realización de las distintas pruebas necesarias para comprobar el correcto funcionamiento de la aplicación web, además de las correspondientes correcciones y ajustes sobre el sistema.

e) P.5.1. Establecer el plan pruebas

Esta tarea consiste en establecer un plan de pruebas establecido para comprobar el correcto funcionamiento de la aplicación. Esfuerzo estimado: 3 horas

f) P.5.2. Análisis de las pruebas

Esta tarea consiste en la ejecución del plan de pruebas, es decir, una vez realizadas las tareas del plan de pruebas, analizaremos los resultados obtenidos. Esfuerzo estimado: 4 horas.

g) P.5.3 Realización de mejoras

Esta tarea consiste en la realización de las mejoras encontradas en el análisis de las pruebas, es decir corregir o mejorar todos los problemas que se detecten durante el análisis de las pruebas. Esfuerzo estimado: 3 horas.

1.4.3. Calendario de trabajo y diagrama de Gantt

Se estima que para la realización del proyecto se dedicarán 300 horas desde el 2 de febrero de 2015 hasta el 19 de junio de 2015.

Durante el transcurso de este proyecto, también se han cursado dos asignaturas, cuya dedicación ya está contemplada en la distribución de los tiempos.

Destacar la tarea de Gestión del TFG, la cual se extenderá durante todo el transcurso del TFG. Solo se señalan con un color diferente los días en los que se trabajó explícitamente para esa tarea.

Febrero Marzo Abril L M X J V S D L M X J V S D L M X J V S D 1 1 1 2 3 4 5 2 3 4 5 6 7 8 2 3 4 5 6 7 8 6 7 8 9 10 11 12 9 10 11 12 13 14 15 9 10 11 12 13 14 15 13 14 15 16 17 18 19

16 17 18 19 20 21 22 16 17 18 19 20 21 22 20 21 22 23 24 25 26 23 24 25 26 27 28 23 24 25 26 27 28 29 27 28 29 30

30 31

Mayo Junio L M X J V S D L M X J V S D Gestión

1 2 3 1 2 3 4 5 6 7 Análisis 4 5 6 7 8 9 10 8 9 10 11 12 13 14 Diseño 11 12 13 14 15 16 17 15 16 17 18 19 20 21 Implementación 18 19 20 21 22 23 24 22 23 24 25 26 27 28 Pruebas 25 26 27 28 29 30 31 29 30 Inicio y Fin

8


Procuraremos ceñirnos en la medida de lo posible, al tiempo estimado. Para posibles contratiempos, se establecerá un plan de riesgos que deberemos utilizar en dichas situaciones.

A continuación, mostramos una tabla y el gráfico asociado, en el que se muestra el tiempo dedicado por tarea:

Tarea Horas por tarea Gestión del TFG 70

Análisis 30 Diseño 40

Implementación 140 Pruebas 20

Proyecto completo 300

En la siguiente imagen se muestra el diagrama de Gantt diseñado para la realización del proyecto.

1.5. Plan de riesgos Para intentar evitar o solucionar los problemas que puedan acontecer durante el desarrollo del proyecto de la mejor manera posible se ha creado un plan de riesgos. En particular, se han identificado los posibles riesgos y un plan de dirección de riesgos a seguir para cada uno de ellos.

23%

10%

13%

47%

7% Gestión del TFG

Análisis

Diseño

Implementación

Pruebas

9


Cambio de requisitos: se dará en el caso de que los responsables de soporte decidan añadir o cambiar cierta funcionalidad.

• Probabilidad: alta. • Momento previsto: durante todo el desarrollo. • Plan de dirección de riesgos: se estudiará la nueva funcionalidad y en caso de ser

factible se añadirá al proyecto.

Requisitos poco claros: puede darse en el caso de haber realizado una descripción demasiado breve de algún requisito.

• Probabilidad: medio. • Momento previsto: durante la etapa de análisis. • Plan de dirección de riesgos: se revisará cuáles son los requisitos que estén poco claros

y se volverán a redactar para mejorar su descripción.

Errores de diseño, omisiones o malentendidos: durante cualquier etapa del proyecto puede darse el caso de que los responsables de soporte puedan ver algo que no esté a su gusto.

• Probabilidad: baja. • Momento previsto: durante todo el proyecto. • Plan de dirección de riesgos: se volverá a la etapa correspondiente a realizar los

cambios necesarios.

Errores en la planificación: puede darse el caso que, debido a la falta de experiencia por parte del proyectante, la estimación de tiempos no se ajuste suficiente a la realidad.

• Probabilidad: muy alta. • Momento previsto: durante todo el desarrollo. • Plan de dirección de riesgos: si el tiempo de desfase fuera pequeño no se implantará

ningún plan de riesgos. En caso de grandes tiempos de desfase, se volverá a reajustar la planificación.

Falta del desarrollador: puede darse el caso de que el alumno no pueda realizar el TFG debido a distintas causas (indisponibilidad, viajes…).

• Probabilidad: media. • Momento previsto: durante todo el desarrollo. • Plan de dirección de riesgos: si el tiempo de indisponibilidad fuera pequeño no se

implantará ningún plan de riesgos. En caso de grandes tiempos de indisponibilidad, se volverá a reajustar la planificación.

Falta del director del proyecto: puede darse el caso de que el director no pueda reunirse debido a distintas causas (indisponibilidad, conferencias, clases…).

• Probabilidad: media. • Momento previsto: durante todo el desarrollo.

10


• Plan de dirección de riesgos: para minimizar este problema, se mantendrá al director del proyecto lo más al día posible, para minimizar el impacto en el proyecto.

Fallo hardware: puede darse el caso de que falle el hardware del ordenador del proyecto y se pierda toda la información del proyecto.

• Probabilidad: baja. • Momento previsto: durante todo el desarrollo. • Plan de dirección de riesgos: para ello se crean copias en Google Drive y en un servidor

de red de Arsys.

Desconocimiento de ciertas herramientas: puede darse el caso de que el alumno no sepa cómo utilizar alguna herramienta software de las necesarias para el desarrollo del producto.

• Probabilidad: baja. • Momento previsto: durante todo el desarrollo. • Plan de dirección de riesgos: se buscarán manuales para su aprendizaje.

1.6. Metodología

Para el control avanzado de algunas etapas, se utilizará la metodología ágil Scrum. Dicha metodología es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para la obtención del mejor resultado posible de un proyecto. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto.

En este caso los sprints se realizarán cada 15 días coincidiendo con la primera y segunda quincena de cada mes. Los entregables van a ser documentaciones resumidas del trabajo realizado en el periodo de tiempo intervenido.

Decir que esta metodología se va empezar a utilizar a partir de la etapa de diseño.

11

Monitorización de productividad de atención al cliente Capítulo 2 - ANÁLISIS

2. ANÁLISIS El siguiente capítulo se centra en presentar los aspectos referentes al análisis del proyecto.

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. Terminología

A continuación, se describirán una serie de términos propios del contexto que se utilizarán a lo largo de esta memoria:

• Directorio activo: es un servicio establecido en uno o varios servidores en donde se crean objetos tales como usuarios, equipos o grupos, con el objetivo de administrar los inicios de sesión en los equipos conectados a la red, así como también la administración de políticas en toda la red.

• UN (Unidad de Negocio): a lo largo de la vida de Arsys, la empresa ha ido absorbiendo a otras empresas secundarias. Por ello, se distinguen los clientes propios de la empresa original de los que ha ido adquiriendo por mediación de las empresas absorbidas. Teniendo esto en cuenta, se distinguen la unidad de negocio que refiere a los clientes de Arsys, de las unidades de negocio de los clientes de las otras empresas.

• Canal: es el medio por el cual se ha producido la comunicación entre el empleado y el cliente.

• Mapa de calor: es un gráfico en el que se resaltan mediante un código de colores zonas concretas de una mapa, utilizando datos de los usuarios que se conectan con el Departamento de Soporte.

• Clientes: con este término nos referimos a las personas que tienen contratado algún servicio con Arsys y se comunican con el Departamento de Soporte para resolver algún problema.

• Aportaciones: se refiere al comentario que debe añadir el responsable de soporte sobre el rendimiento de un empleado en una semana de trabajo.

• Chat: refiere al uso de la herramienta chat que usan empleados del Departamento de Soporte y clientes para comunicarse.

• Estadísticas cliente: refieren a estadísticas del cliente generadas de la comunicación entre cliente empleados del Departamento de Soporte.

• Estadísticas empleado: son las estadísticas obtenidas de un empleado durante la jornada de trabajo.

• Estadísticas chats: son las estadísticas obtenidas de un empleado durante el uso del chat.

• Grupos empleados: Dentro de todos los empleados de soporte se distinguen distintos tipos de grupos de empleados.

• Vista dinámica: Es una tabla que se crea a partir de otra. Antes de crear una nueva tabla deberemos seleccionar qué parámetros de la tabla origen los usamos como filas y cuáles como columnas.

12


2.1.2. Requisitos Funcionales

En este proyecto se especifican los siguientes requisitos:

Requisitos generales:

R.1) La aplicación obligará a loguearse para poder acceder a ella. La comprobación de los usuarios se hará a través del directorio activo sólo para usuarios del tipo de responsables de soporte.

R.2) La aplicación permitirá el cierre de la sesión. R.3) La aplicación permitirá crear una vista dinámica de las notas obtenidas por los

empleados. R.4) La aplicación permitirá seleccionar un intervalo de tiempo para obtener los datos con los

cuales trabajar en la vista dinámica. R.5) La aplicación permitirá seleccionar una función (realizar la suma, contar o hacerla la

media) con la cual trabajar en la vista dinámica. R.6) La aplicación deberá dar la posibilidad de exportar la tabla dinámica en un archivo csv. R.7) La aplicación permitirá añadir aportaciones a todos los empleados. R.8) La aplicación permitirá seleccionar la semana en la que deseamos añadir los

comentarios a aportaciones de los empleados. R.9) La aplicación deberá dar la posibilidad de ver todas las aportaciones realizadas por un

empleado. R.10) La aplicación automatizará el envío semanal de las estadísticas con sus comentarios, en

caso de falta de comentarios avisará a los responsables.

Requisitos de las estadísticas empleado.

R.11) La aplicación deberá mostrar las estadísticas empleado de todos los empleados de un grupo.

R.12) La aplicación permitirá distinguir entre los distintos grupos de empleados que hay en el Departamento de Soporte para ver las estadísticas empleado.

R.13) La aplicación permitirá seleccionar un intervalo de tiempo del cual queremos ver las estadísticas empleado.

R.14) La aplicación permitirá seleccionar de que UN queremos ver las estadísticas empleado. R.15) La aplicación permitirá seleccionar de que canal queremos ver las estadísticas empleado. R.16) La aplicación deberá dar la posibilidad de ver todas las notas obtenidas por un

empleado. R.17) La aplicación deberá dar la posibilidad de crear un archivo csv de las notas. R.18) La aplicación deberá mostrar quién es el mejor empleado en el periodo de tiempo

indicado. R.19) La aplicación deberá dar la posibilidad de enviar un email a los empleados con sus

correspondientes estadísticas.

Requisitos de las estadísticas chats:

R.20) La aplicación deberá mostrar las estadísticas chats de los empleados en el chat con los clientes.

13


R.21) La aplicación permitirá seleccionar un intervalo de tiempo del cual queremos ver las estadísticas chats.

R.22) La aplicación permitirá distinguir entre los distintos grupos de empleados que hay en soporte dentro de estadísticas chats.

R.23) La aplicación permitirá seleccionar de que UN queremos ver las estadísticas dentro de estadísticas chats.

R.24) La aplicación permitirá seleccionar de que canal queremos ver las estadísticas dentro de estadísticas chats.

Requisitos de las estadísticas cliente:

R.25) La aplicación permitirá ver en un mapa de calor la posición de los clientes del chat. R.26) La aplicación permitirá seleccionar un intervalo de tiempo del cual queremos ver la

posición de los clientes del chat. R.27) La aplicación permitirá ver las estadísticas cliente. R.28) La aplicación permitirá seleccionar un intervalo de tiempo del cual queremos ver las

estadísticas cliente. R.29) La aplicación deberá mostrar todos los clientes del intervalo de tiempo indicado y elegir

de cuáles queremos ver las estadísticas cliente. R.30) La aplicación deberá dar la posibilidad de crear un archivo csv de las estadísticas cliente.

2.1.3. Requisitos no funcionales

A continuación, se presentan los requisitos no funcionales que serán divididos en cuatro grupos.

Requisitos de los navegadores

La aplicación deberá funcionar correctamente en los navegadores más utilizados en la empresa (Firefox 31 o superior, Chrome 42 o superior y Explorer 11 o superior).

Requisitos de disponibilidad

La aplicación deberá tener una disponibilidad de 24/7 semanales, exceptuando los periodos de tiempo en los que se encuentre en mantenimiento.

Requerimientos de Soporte

Se documentará la aplicación con un manual de ayuda con el objetivo de explicar el uso e instalación de la herramienta.

Además, se debe crear el proyecto de forma versionable para que permita realizar mantenimientos al sistema a fin de aumentar las funcionalidades y/o corregir los errores del mismo. A través de versiones posteriores podremos continuar mejorando el proyecto.

Requerimientos de Seguridad

La información estará protegida contra accesos no autorizados, utilizando mecanismos de validación.

14


2.2. Diagramas de casos de usos

En esta sección presentaremos los diagramas de casos de uso del proyecto y su respectiva especificación. Los casos de uso más complejos vienen acompañados por un diagrama de actividad para facilitar su legibilidad.

2.2.1. Diagrama de casos de uso

Destacar que la aplicación solo constará de un actor que se referirá a los responsables de soporte y al que nos referiremos como “Usuario”. El diagrama de casos de uso es el siguiente:

15


2.2.2. Especificación de casos de uso

A continuación, vamos a mostrar la especificación de los casos de uso. La descripción de cada caso de uso consta de un nombre, una pequeña descripción, los actores que intervienen, los requisitos funcionales que cubre, una precondición y postcondición, un flujo básico y, en algunos casos, un flujo alternativo y anotaciones.

Como se ha comentado anteriormente, la aplicación solamente constará con un actor que será el usuario.

Caso de uso Iniciar sesión Descripción El usuario se identifica en la aplicación. Actores Usuario Requisitos implementados R.1 Precondiciones El usuario debe tener un login en el directorio activo y

pertenecer al grupo de responsable de soporte. Postcondiciones El usuario es logueado en la aplicación. Flujo básico

1. El usuario debe dirigirse a la página de login. 2. Debe introducir su usuario y su contraseña. 3. El sistema valida los datos. 4. El sistema lo redirige a la aplicación.

Flujo alternativo y excepciones En caso de validación incorrecta el sistema mostrará un mensaje de error y no dará permiso para entrar a la aplicación. Anotaciones Para poder entrar en la aplicación, el usuario deberá pertenecer al grupo de

responsable de soporte dentro del directorio activo. Exceptuando el usuario administrador que no pertenece a ese grupo.

Caso de uso Cerrar sesión Descripción El usuario cierra la sesión y sale de la aplicación. Actores Usuario Requisitos implementados R.2 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El usuario cierra la sesión. Flujo básico

1. El usuario pulsa en cerrar sesión. 2. El sistema cierra la sesión del usuario. 3. El sistema lo redirige a la página de login.

16


Caso de uso Ver vista dinámica Descripción El usuario obtendrá una tabla con los datos seleccionados

anteriormente. Actores Usuario Requisitos implementados R.3, R.4, R.5, R.6 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El sistema muestra la vista al usuario. Flujo básico

1. El usuario debe dirigirse al apartado de “Vista dinámica”. 2. El usuario deberá indicar qué valores quiere en columnas y cuáles en fila. 3. El usuario deberá indicar el intervalo de tiempo. 4. El usuario deberá indicar qué función deseará aplicar. 5. El sistema analizará las opciones elegidas y creará la tabla correspondiente.

Flujo alternativo y excepciones 1. Flujo1 (corresponde al caso de uso “Exportar tabla”)

a. El usuario podrá exportar la tabla. b. El sistema creará un archivo con la tabla correspondiente.

Caso de uso Ver estadísticas empleado Descripción El usuario obtiene el listado de las estadísticas de los

empleados. Actores Usuario Requisitos implementados R.11, R.12, R.13, R.14, R.15, R.16, R.17, R.18, R.19 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El usuario visualiza las estadísticas. Flujo básico

1. El usuario debe dirigirse al apartado de “Estadísticas empleados”. 2. El usuario indica el grupo de empleados a listar. 3. El usuario debe seleccionar la UN de las que quiere ver las estadísticas de los

empleados. 4. El usuario debe seleccionar el canal de los que quiere ver las estadísticas de los

empleados. 5. El usuario deberá seleccionar el intervalo de tiempo correspondiente. 6. El sistema analizará las opciones elegidas y mostrará las estadísticas

correspondientes. Flujo alternativo y excepciones

1. Flujo1: (corresponde al caso de uso “Envío de estadísticas”) a. El usuario podrá seleccionar un usuario para el envío de las estadísticas. b. El sistema creará una vista previa de cómo el usuario verá sus estadísticas y

un cuadro para la introducción del comentario. c. El usuario deberá introducir el comentario. d. El sistema enviará las estadísticas al empleado correspondiente.

2. Flujo2: (corresponde al caso de uso “Ver notas empleado”) a. El usuario podrá seleccionar la nota de un empleado. b. El sistema lista todas las notas de ese empleado por encuesta. c. El usuario podrá exportar las notas. d. El sistema creará un archivo con el listado de las notas.

17


A continuación se muestra el Diagrama de actividad diseñado para el caso de uso:

18


Caso de uso Incluir aportaciones Descripción El usuario añadirá aportaciones a todos los usuarios de la

semana indicada. Actores Usuario Requisitos implementados R.7, R.8, R.9 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El sistema añade a la BD las aportaciones indicadas. Flujo básico

1. El usuario debe dirigirse al apartado de “Incluir aportaciones”. 2. El usuario deberá indicar una semana. 3. El sistema mostrará todos los empleados y solicitará una aportación para cada uno de

ellos. En caso de existir aportaciones, las mostrará. 4. El usuario añadirá una aportación para cada usuario. 5. El sistema añadirá la aportación a la BD. En caso de ya existir, las sobrescribirá.

Flujo alternativo y excepciones 1. Flujo1: (corresponde al caso de uso “Ver historial de aportaciones empleado”)

a. El usuario podrá seleccionar un usuario para ver el historial de aportaciones. b. El sistema mostrará una lista de las aportaciones.

Caso de uso Envío automático de estadísticas Descripción El sistema realizará un envío masivo a todos los empleados con

sus estadísticas de la última semana. Actores Usuario Requisitos implementados R.10 Precondiciones Postcondiciones Cada empleado obtendrá las estadísticas y la aportación de la

semana anterior. Flujo básico

1. El usuario activará el sistema de envío automático de estadísticas. Flujo alternativo y excepciones En caso de no existir aportación para los usuarios en esa semana, creará un mensaje de aviso para los responsables de soporte avisándoles que deben añadir las aportaciones.

Caso de uso Estadísticas chats empleados Descripción El usuario obtendrá una vista con todas las estadísticas de los

empleados en el chat. Actores Usuario Requisitos implementados R.20, R.21, R.22, R.23, R.24 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El sistema mostrará las estadísticas de los empleados en el chat. Flujo básico

1. El usuario debe dirigirse al apartado de “Estadísticas chat”. 2. El usuario indica el grupo de empleados a listar. 3. El usuario debe seleccionar la UN de las que quiere ver las estadísticas de los

empleados. 4. El usuario debe seleccionar el canal de los que quiere ver las estadísticas de los

empleados. 5. El usuario debe seleccionar el intervalo de tiempo correspondiente. 6. El sistema analizará las opciones elegidas y mostrará las estadísticas pertinentes.

19


Caso de uso Ver mapa de calor Descripción El usuario podrá ver un mapa de calor el cual muestre los

puntos en los cuales han iniciado el chats los clientes de arsys. Actores Usuario Requisitos implementados R.25, R.26 Precondiciones El usuario debe estar logueado en la aplicación Postcondiciones El sistema creará el mapa de calor con los con los valores

correspondientes. Flujo básico

1. El usuario debe dirigirse al apartado de mapa. 2. El usuario deberá elegir un intervalo de tiempo. 3. El sistema analizará las opciones elegidas y creará un mapa de calor con los valores

obtenidos de la BD.

Caso de uso Ver estadísticas clientes Descripción El usuario podrá ver las estadísticas de los usuarios indicados. Actores Usuario Requisitos implementados R.27, R.28, R.29, R.30 Precondiciones El usuario debe estar logueado en la aplicación. Postcondiciones El sistema muestra las estadísticas de los clientes indicados. Flujo básico

1. El usuario debe dirigirse al apartado de “Estadísticas clientes”. 2. El usuario deberá elegir el intervalo de tiempo. 3. El usuario deberá elegir los clientes para los cuales se desea mostrar las estadísticas. 4. El sistema analizará las opciones elegidas y mostrará las estadísticas de esos clientes.

Flujo alternativo y excepciones 1. Flujo1: (corresponde al caso de uso “Exportar estadísticas”)

a. El usuario podrá exportar las estadísticas de los clientes. b. El sistema creará un archivo con las estadísticas correspondientes.

2.3. Tecnologías a utilizar

En el transcurso de este proyecto se utilizarán distintas herramientas y lenguajes de programación que se muestran a continuación.

Las herramientas necesarias serán:

• Visual studio 2010: será necesario para la creación de la aplicación web. • Framework .Net: será necesario para la ejecución de la aplicación web. • Herramientas para desarrolladores de Firefox: se utilizarán para la comprobación de

fallos en el javascript, así como para realizar pruebas en los css, y para ver y modificar el html.

• Microsoft Office Word: utilizado para la creación de la documentación. • Microsoft Office Excel: se utilizara para ver las exportaciones de la aplicación web. • Microsoft Office Visio: se utilizará para la creación de los casos de usos, así como el

diagrama de EDT y GANT. Además de utilizar para la creación de los prototipos web.

20


• Microsoft Office Project: se utilizará para la creación de la planificación del presente proyecto.

Los lenguajes utilizados serán:

• ASP.NET en c#: será el lenguaje más utilizado y será el encargado de la implementación de la aplicación.

• HTML5 y CSS3: estos lenguajes los utilizaremos para la creación de la página web y el diseño de la misma.

• Javascript: este lenguaje será utilizado para la implementación de las interfaces. • T-SQL: este lenguaje será utilizado para la creación de la BD y de los procedimientos

almacenados.

2.4. Plan de pruebas

Se creará un plan de pruebas que será utilizado en el proyecto. Este plan será comprobado punto por punto, de forma que nos aseguraremos de que todo funciona correctamente. En caso de detección de algún fallo, se pasará a su correción o mejora.

• Comprobar que solo pueden loguearse los usuarios indicados. • Evitar inyecciones sql en el login en el logueo. • Comprobar que la sesión se cierra correctamente. • Las estadísticas que se generen para los empleados son correctas. • Comprobar que las opciones de las estadísticas funcionan correctamente. • Comprobar que el envío del correo manual funciona correctamente. • Comprobar el listado de notas obtenido para cada usuario es el correcto. • Comprobar los archivos que se crea al exportar las notas sean correctos. • Comprobar que las aportaciones se añaden o actualizan correctamente. • Comprobar que el historial de aportaciones por usuario es correcto. • Ver si el envío automático se realiza correctamente. • Comprobar que la vista dinámica es la correcta. • Comprobar el archivo que se crea al exportar la vista dinámica. • Comprobar que las marcas del mapa de calor son las correctas. • Comprobar que las estadísticas para todos los clientes son correctas. • Comprobar el archivo que se crea al exportar las estadísticas de los clientes. • Comprobar que las estadísticas para todos los chats empleado son correctas.

21

Monitorización de productividad de atención al cliente Capítulo 3 - DISEÑO

3. DISEÑO En este apartado vamos a tratar los aspectos relacionados en el diseño de la aplicación, tanto en lo que se refiere al diseño de los prototipos de la interfaz web, como al diseño de las clases del sistema y al diseño de la base de datos.

3.1. Prototipos de la interfaz web

Los prototipos de la aplicación han sido diseñados con el programa Visio, utilizando la plantilla sketchGUIShapes, la cual nos ha facilitado bastante el trabajo.

Para el diseño de los prototipos nos hemos basado en las explicaciones iniciales expuestas por los responsables de soporte. Además, durante todo el proceso, su diseño ha sido revisado y finalmente, aprobado por el responsable de soporte.

• Página login: esta página será utilizada para loguearse en la aplicación. Consta simplemente de dos cuadros de texto, así como de un botón para enviar dichos datos (Botón “Acceder”)

22


• Página inicio: esta página será la primera que se muestre una vez logeado el usuario. En ella encontraremos además de las diferentes opciones que ofrece la herramienta (situados en la parte superior), una pequeña descripción de algunas de las funcionalidades de la aplicación web. Destacar que la parte superior de la ventana coincidirá en la mayor parte de las páginas, que comprende desde el menú hasta la parte de arriba.

23


• Página estadísticas: para acceder a ella deberemos pulsar sobre “Estadísticas” del menú principal. Mediante esta página se podrá seleccionar un intervalo de fechas y una serie de parámetros. El resultado se mostrará en una tabla situada en la parte inferior de la página. Si pulsamos sobre enviar correo, iremos a la opción de enviar las estadísticas al usuario y si pulsamos sobre score iremos a ver todas las notas del empleado.

24


• Página aportaciones: para acceder a ella deberemos pulsar sobre la pestaña “Aportaciones” del menú principal. Esta página permitirá elegir la semana de la cual deseemos ver las aportaciones. El resultado se nos mostrará en una tabla en la parte inferior de la página, en la cual deberemos añadir o modificar las aportaciones de los usuarios. Desde esta tabla se podrá, pinchando en la foto del empleado, acceder al historial de aportaciones del empleado.

25


• Página estadísticas chat: se accede a esta página cuando se selecciona la pestaña “Estadísticas chat” del menú principal. Esta página es parecida a la página Estadísticas con la única diferencia de la tabla que se muestra en la parte inferior que contiene las estadísticas del chat de los empleados.

26


• Página mapa de calor: se accede a esta página cuando se selecciona la pestaña “Mapa de calor” del menú principal. En esta página deberemos introducir el intervalo de fechas del cual obtendremos los resultados. En la parte inferior se nos mostrará un mapa y en el que mostrarán desde dónde se conectan los clientes.

27


• Página estadísticas clientes: se accede a esta página cuando se selecciona la pestaña “Estadísticas cliente” del menú principal. Esta página nos permitirá ver las estadísticas delos clientes. En particular, el usuario deberá introducir el intervalo de fechas del cual obtener los resultados. Después se mostrará una lista de clientes a elegir. Por último se nos añadirán las estadísticas de los clientes elegidos, es decir, se podrán ver desde qué ciudades se conectan los clientes seleccionados, qué protocolo utilizan (http o https)...

28


• Página vista dinámica: se accede a esta página cuando se selecciona la pestaña “Vista dinámica” del menú principal. En esta página deberemos introducir el intervalo de fechas y una lista de opciones. En función de las opciones elegidas, se mostrará una tabla con el resultado.

29


• Página Error: esta página se mostrará cuando se produzca algún error en la aplicación. En particular, se indicará el número del error producido y una pequeña descripción del motivo de ese error.

30


• Página NotasEmpleado: Esta página estará disponible desde la página “Estadísticas”, pinchando en la nota de un empleado. En esta página podemos ver todas las notas realizadas sobre un empleado en un intervalo de tiempo determinado.

• Página EmailManual: Esta página estará disponible desde la página “Estadísticas”, pinchando en “Enviar correo”. En esta página podemos ver cómo será el email que le llegará al empleado cuando el usuario decida manualmente enviarle las estadísticas correspondientes a un periodo de tiempo determinado.

31


• Página EmailAutomatico: esta será el formato de email que le llegará al empleado de forma automática todas las semanas.

• Página AportacionesEmpleado: Esta página estará disponible desde la página “Aportaciones”, pinchando sobre la foto de un empleado. En esta página podemos ver todas las aportaciones que tiene un empleado.

32


3.2. Arquitectura del sistema

El sistema se base en la arquitectura en 3 capas (presentación, negocio y persistencia). La arquitectura en 3 capas es una arquitectura que tiene por objetivo primordial la separación por capas.

En lo que se refiere a la separación topológica o física de la aplicación, decir que dispondremos de dos servidores. Uno, donde estará alojada la BD, y otro diferente donde estará alojada el resto de la aplicación.

Cada capa tendrá una funcionalidad determinada:

1. Capa de presentación: la que interactuará con el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario. Esta capa se comunica únicamente con la capa de negocio.

2. Capa de negocio: es donde se establecen todas las reglas de negocio que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de persistencia, para solicitar al gestor de base de datos almacenar o recuperar datos de él. Estará formada por el modelo de dominio, que refiere a las entidades propias del dominio de la aplicación, y por el modelo de negocio, que corresponde a las entidades propias que implementan la lógica de la aplicación, atendiendo a las reglas de negocio.

3. Capa de persistencia: es la encargada de acceder a la BD. En particular, recibe las solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

3.3. Diseño de la base de datos

La aplicación necesitará conectarse a una BD que almacenará la información referente a los datos de los empleados y de los clientes. A continuación, se muestra el diseño de dicha BD, en particular, su modelo E/R.

3.3.1. Antecedentes

Para poder entender mejor el diagrama entidad-relación diseñado para la base de datos que utilizará nuestra aplicación, vamos a explicar unas pautas que hemos seguido para su diseño.

33


En particular, a partir de ahora, cuando hablemos de tickets nos referiremos a la información que se almacena cuando un empleado tiene una comunicación (vía teléfono, chats, fax…) con clientes de Arsys. Dependiendo de la acción realizada puede ser un tipo de ticket distinto.

a. Tickets cerrados: Estos son creados cuando un empleado da por finalizada la comunicación entre un cliente y él.

b. Tickets escalados: Estos son creados cada vez que un empleado decide pasar al cliente a un departamento distinto del que se encuentra.

c. Tickets tramitadas: Estos son creados cada vez que un empleado interviene en una consulta con un cliente.

d. Tickets encuestados: Estos son creados cuando un cliente valora la atención con la que le trato el empleado.

Anteriormente se ha comentado que ya se disponía de unas tablas que almacenaban determinada información que se podía usar para monitorizar la productividad de los empleados y de los clientes. Teniendo esto en cuenta se muestran las entidades asociadas a las tablas ya existentes en Arsys, que tenemos como punto de partida para nuestra aplicación.

• AUX_CERRADOS: es la entidad que almacena todos los “tickets cerrados” por empleado. Es decir, cada vez que un empleado termine la comunicación con un cliente de Arsys, se creará un “ticket cerrado”, el cual almacenara la fecha y el empleado encargado de cerrarlo.

• AUX_ESCALADOS: es la entidad que almacena todos los “tickets escalados” por empleado. Es decir, cuando un empleado está tratando de resolver un problema o duda a un cliente pero este problema o duda debe tratarse por otro departamento, el empleado pasará a otro departamento y por tanto se creará un “ticket escalado” el cual almacenará la fecha y el empleado encargado de escalarlo.

• AUX_ENCUESTADOS: es la entidad que almacena todos los “tickets encuestados” por empleado. Es decir, cada vez que un cliente termine la comunicación con un empleado deberá rellenar un cuestionario, el cual se almacenará en esta entidad.

• AUX_TRAMITADOS: Es la entidad que almacena todos los “tickets tramitados” por empleado. Es decir, cada vez que un empleado interviene en una comunicación con un cliente se crea un “ticket tramitado”. Para la consulta de un cliente se crearán tantos “tickets tramitados” como empleados intervengan en la resolución de la consulta.

• Objetivos: para cada empleado se van a obtener cuatro estadísticas globales, pero dependiendo del grupo al que pertenezca el empleado, cada estadística deberá superar una nota.

• Ponderaciones: para cada empleado se van a obtener cuatro estadísticas globales, pero dependiendo del grupo al que pertenezca el empleado va a tener un valor distinto cada estadística. Con las estadísticas y sus correspondientes valores se creará una nota total del empleado que, cuanto mayor sea, mejores estadísticas tendrá el empleado.

• AUX_Chats: es la entidad que almacena los detalles de los chats por empleado. Es decir, almacena todos los detalles de la comunicación que se produce entre un cliente y un empleado a través del chats, desde el primer mensaje del cliente que abre el chat hasta que el empleado lo da por finalizado.

34


A continuación, se presenta el diagrama de las tablas.

35


3.3.2. Diagrama Entidad-Relación

En primer lugar, se mostrará el diagrama:

A continuación, se describen las entidades del sistema:

• DatosLogin: es la entidad principal de diagrama. Almacenará el login y nombre de los distintos empleados, de los cuales tendremos que calcular y mostrar sus estadísticas.

• Grupo: es la entidad encargada de almacenar los distintos grupos de empleados. • DuracionLogeosDia: es la entidad encargada de almacenar el tiempo de logue en chat

por empleado. Es decir, almacena el tiempo que un empleado ha estado conectado al chat cada día.

• MaxAgrupadosSoporte: es la entidad encargada de almacenar el máximo número de chats simultáneamente por empleado. Un empleado puede estar atendiendo a más de un cliente a través del chat, esta entidad almacenará cuál ha sido el mayor número de chats que ha atendido un empleado en una hora concreta.

36


Por otro lado, podemos identificar las siguientes relaciones entre las entidades:

• La entidad DatosLogin tiene una relación con Grupo. Un empleado puede pertenecer a más de un grupo en una determinada fecha y un grupo puede contener a más de un usuario.

• La relación entre DatosLogin con AUX_CERRADOS, AUX_TRAMITADOS, AUX_ENCUESTADOS, AUX_ESCALADOS, AUX_Chats, DuracionLogueoDia y MaxAgrupadosSoporte es similar. Cada una de las entidades anteriores contendrá un login de la entidad DatosLogin.

• Las relaciones entre Grupo con Ponderaciones y Objetivos son similares. Cada una de las entidades anteriores corresponderá a un grupo de la entidad Grupo.

• Las entidades ChatsDetallados y DatosLogin tienen dos relaciones entre ellas. Esto es debido a que en un chat se almacena tanto el empleado que acepto la petición del cliente como el empleado que lo finaliza (el que lo inicia y el que lo finaliza). Destacar que ambas pueden ser nulas si el empleado que lo aceptó o el que lo finaliza no pertenece al departamento de soporte.

3.3.3. Diseño lógico

A continuación se muestra el diseño lógico normalizado para el diagrama E/R definido anteriormente.

DatosLogin Login CP

LoginGrupo Login NombreGrupo Fecha CP CE:DatosLogin CP CE:Grupo

Grupo Nombre Jornada CP

Ponderaciones Grupo Aport Nota NEscalados Cerrados Logon CP CE:Grupo

Objetivos Grupo Objetivo1 Objetivo2 Objetivo3 Objetivo4 CP CE:Grupo

AUX_CERRADOS Ticket Login Mes Dia Canal UN CP CP CE:DatosLogin CP CP

AUX_ESCALADOS Ticket Login Mes Dia Hora Canal UN UFDestino CP CP CE:DatosLogin CP CP CP

AUX_ENCUESTADOS Ticket Login Mes Dia Canal UN Nota Comentario CP CP CE:DatosLogin CP CP

37

Monitorización de productividad de atención al cliente Capítulo 3 ‐ DISEÑO

38

AUX_TRAMITADOS

Ticket Login Mes Dia Canal UN CP CP CE:DatosLogin CP CP

AUX_Chats

ChatID Dominio TipoChat AñoMes Dia EmailCliente Selección Navegador CP

Protocolo Latitude Longitude City Country loginInicio loginFinal CE:DatosLogin CE:DatosLogin

DuracionLogeosDia

Login Mes Dia Dominio Canal UN CP CE:DatosLogin CP CP CP

MaxAgrupadosSoporte

Login Mes Dia Hora Maximo MaxArsys MaxPiensa CP CE:DatosLogin CP CP CP

3.4. Diseñodeclases

Como ya se ha comentado anteriormente, el proyecto contará de tres capas. Cada capa solo

podrá conectarse con la que tiene contigua. Además, la capa de lógica de negocio estará

formada por el modelo de negocio y por el modelo de dominio. A continuación, se presenta el

diagrama de paquetes.

En particular en la siguiente figura se muestra el diagrama de clases asociado al modelo de

dominio.

Tal y como se puede ver en el diagrama éste consta de una clase abstracta Empleado, que

generaliza las clases: EmpleadoEstdisticas, EmpleadoAportacion y EmpleadoChat.

Monitorización de productividad de atención al cliente Capítulo 4 – IMPLEMENTACIÓN

4. Implementación En este apartado se tratarán los aspectos más relevantes de la fase de implementación.

4.1. Estructura de la aplicación

El lenguaje utilizado para la implementación de las capas de presentación, lógica de negocio y persistencia es ASP.NET C#, con objeto de evitarnos problemas circulares entre los diferentes paquetes de la aplicación, hemos tenido que crear dos paquetes separados con el modelo de dominio (paquete Modelo) y el modelo de negocio (paquete Negocio), respectivamente. La capa de presentación esta referencia como paquete Supervision. A continuación, veremos los cuatro paquetes que se encuentran dentro del proyecto.

Debido a dicha separación, la comunicación entre las capas también cambia un poco respecto a la explicada en la estructura en tres capas. A continuación, se muestra las relaciones entre los diferentes paquetes que forman la aplicación.

4.2. Librerías utilizadas Antes de empezar a realizar el desarrollo de la aplicación, se investigó la existencia de librerías que podrían facilitar el desarrollo de la misma. A continuación, se destacan las librerías que se han utilizado junto con su descripción.

4.2.1. Librerías de C#

• System.Net.Mail

El espacio de nombres System.Net.Mail contiene clases que se utilizan para enviar correo electrónico a un servidor SMTP (Simple Mail Transfer Protocol, Protocolo simple de transferencia de correo).

39


En particular, existe la clase MailMessage que representa el contenido de un mensaje de correo. La clase SmtpClient transmite el correo electrónico al host SMTP que se designe para la entrega del correo.

A continuación, podemos ver un ejemplo del uso del espacio de nombres System.Net.Mail en el proyecto:

Como se aprecia en el código anterior, primero deberemos crear un objeto de la clase SMTPServer, y posteriormente se le asignarán unos requisitos: el puerto, las credenciales, etc.

• Newtonsoft.Json

Es una librería externa a .Net la cual nos ayuda a trabajar con archivos JSON. Para poder utilizarla deberemos importarla al proyecto. En particular hemos usado la clase JSONConvert, en particular el método DesielizeObject al cual deberemos pasarle un string con la cadena en formato JSON y el tipo de objeto al cual se desea convertir los datos JSON de dicha cadena. Posteriormente, nos devolverá una lista de objetos del tipo indicado anteriormente, con sus correspondientes valores.

A continuación mostramos un ejemplo de uso en nuestro proyecto:

En el caso anterior, indicamos que convierta la cadena postJSON con los datos en formato JSON, en objetos de tipo EmpleadoAportacion.

• System.Web.UI.DataVisualization.Charting

Es una librería propia de .Net la cual nos facilita la creación de gráficos (barras, lineal…). En nuestro caso será utilizada para la creación de gráficos de barras que muestren las estadísticas de los clientes de Arsys, para los empleados solo serán utilizadas estadísticas numéricas.

40


A continuación, podemos ver un ejemplo del resultado de su uso:

4.3.2. Librerías y métodos de JQuery

• jquery.tablesorter.js

Un requisito de la aplicación es visualizar tablas para ver las estadísticas, es por ello que se decidiera usar esta librería, la cual nos ayuda a mostrar las tablas.

En primer lugar, nos permite aplicar un formato determinado a las tablas de una manera sencilla. En particular, el estilo de visualización de las tablas que hemos elegido ha sido el “zebra”, que muestra las filas pares de un estilo distinto a las impares.

Esta librería también nos ayuda a ordenar los datos por filas. En caso de que el usuario quiera ver la tabla ordenada por una determinada columna simplemente deberá pulsar en la celda de arriba en esa columna y la librería cambiará el orden a las filas para su correspondiente ordenación. También deberemos indicarle qué columnas no pueden utilizarse para cambiar la ordenación de las filas.

• JSON.stringify()

El método JSON.stringify() convierte un valor dado en javascript a una cadena JSON.

• tcal.js

Se usa esta clase para facilitar al usuario de la aplicación la elección de una fecha dentro de un cuadro de texto. Esta clase se activará cuando el usuario pulse sobre el cuadro de texto y mostrará un calendario en el cual el usuario deberá elegir un día. Automáticamente ese día pasará a formato texto dentro del cuadro de texto.

Se decidió que los cuadros de texto estuvieran disabled para que la única forma de añadir una fecha al cuadro de texto fuera a través del calendario.

41


A continuación veremos como se muestra el calendario en la aplicación:

• Google Maps JavaScript API HeatMaps

Para la creación de los mapas de calor (HeatMaps) se decidió utilizar el API de google HeatMaps que nos facilita todo el proceso de creación. Para usarlo, simplemente debemos importar el API, crear la función initialize y crear el vector de puntos a marcar en el mapa.

A continuación se presenta la función initialize:

Y por último, el ejemplo de cómo crear un punto a pintarse en el mapa:

42


4.3. Desarrollo de la aplicación

En este apartado vamos a tratar todo lo referido con la implementación de la aplicación en sí.

4.3.1. Implementación de la BD

Como se ha comentado anteriormente, para la implementación de la BD se ha utilizado SQL Server, ya que las tablas existentes residían en una BD SQL Server. Ha sido necesario crear las tablas nuevas de la BD y sus respectivas relaciones. A continuación, se muestra una vista resumen de la BD.

Una vez creadas las tablas, hemos decidido implementar una serie de procedimientos almacenados necesarios para conseguir determinadas funcionalidades de la aplicación y que estén disponibles en la BD, si es el caso, para su uso por otras aplicaciones en la empresa. Para ello ha sido necesario estudiar cómo se crean, qué estructura siguen y qué nomenclatura tienen. Para lo que he tenido que documentarme previamente.

En particular, se han definido un total de 26 procedimientos almacenados. Por ejemplo, getGrupos se encargá de obtener todos los grupos de empleados, getCordenadas se encarga de obtener las coordenadas de los clientes que han solicitado ayuda en una franja de tiempo y getConcurrenciaMaxima se encargá de obtener cuál ha sido el mayor número de chats atendidos a la vez en una franja determinada por un empleado concreto.

43


A continuación podremos ver el ejemplo del procedimiento almacenado getEnviogetAport:

En el ejemplo anterior podemos ver las características más importantes de un procedimiento almacenado.

Las instrucciones anteriores al CREATE serán comunes en todos los procedimientos. Estas instrucciones son creadas por el asistente de SQLServer. Después de CREATE PROCEDURE le asignaremos el nombre de getEnviogetAport al procedimiento. Posteriormente creamos dos variables de entrada, de tipo nvarchar, que refieren a la semana del comentario y al login del empleado. Y por último, añadimos la instrucción SQL que deseamos que ejecute el procedimiento almacenado. Dicha instrucción nos devolverá el login, la fecha y el comentario introducido para ese usuario en esa semana.

4.3.2. Implementación de la capa de Persistencia

La capa de persistencia se encargará de acceder a la BD. Dentro de la capa de persistencia solo tendremos una clase llamada GestorBD la cual contendrá todos los métodos encargados de comunicarse con la BD.

En particular, para acceder a la BD necesitaremos establecer una conexión con la BD. Para ello crearemos una cadena de conexión, en un archivo de configuración. Para facilitar ese trabajo, Visual Studio nos ofrece una vista gráfica para trabajar con el archivo de configuración.

44


Realizando esta cadena de conexión (CadenaConexion) nos ahorramos el tener que escribir todos los aspectos de conexión a la BD cada vez que queramos realizar una nueva conexión con la BD. Además nos permite asegurarnos de que el usuario y contraseña de la BD pueda ser visto por cualquier persona que tenga acceso a la capa de persistencia.

La utilización de la cadena de conexión creada anteriormente es muy sencilla. Cuando queramos conectarnos a la BD, deberemos indicarle que el ConnectionString es la cadena de conexión creada anteriormente. Para poder obtener esa cadena, deberemos apuntar a Settings, Default y el nombre con el que la hayamos identificado (en nuestro caso CadenaConexion).

Y modo de ejemplo se muestra el método getEmpleadoAportaciones,el cual se conecta a la BD e invoca al procedimiento almacenado presentado anteriormente.

45


En particular se crea un objeto SqlCommand, al que deberemos pasarle el nombre del procedimiento almacenado y la conexión. También habrá que añadirles las variables de entrada (en este caso @Fecha y @Login).

El siguiente paso consiste en crear un objeto SqlDataReader, el cual nos va a permitir recorrer los valores devueltos.

4.3.3. Implementación del modelo de dominio

Como se ha explicado anteriormente, el modelo de dominio ha sido creado separado del modelo de negocio. Dentro del paquete Modelo podremos encontrar las cuatro clases que han sido especificadas en el diseño. Cada clase estará compuesta por sus correspondientes métodos y atributos. Estas clases serán utilizadas desde cualquier capa del proyecto.

A continuación se presenta la distribución del modelo de dominio:

4.3.4. Implementación del modelo de negocio

El modelo de negocio llamará a los métodos de la capa de persistencia. Dentro del modelo de negocio solo encontraremos una clase llamada NegocioDatos, la cual contiene todos los métodos que se encargarán de llamar a los métodos de la persistencia.

A continuación se presenta el método getEmpleadoAportaciones del paquete Negocio, que invoca al método de la capa de persistencia getEmpleadoAportaciones:

4.3.5. Implementación de la capa de presentación

Cada interfaz de la aplicación está compuesta por tres ficheros. Un fichero tendrá extensión aspx, donde se incluirá todo lo relacionado con la interfaz de usuario. Otro tendrá extensión aspx.cs, donde pondremos el código de los eventos que se ejecuten desde el formulario. Y el último fichero, que tendrá extensión aspx.designer.cs, donde encontraremos el código que se genera automáticamente. Este último fichero no deberemos modificarlo.

46


A modo de ejemplo, mostramos los ficheros creados para la interfaz VistaDinamica:

A continuación, se remarcaran algunos aspectos a resaltar de dos páginas de la aplicación:

• Página Master

Una Master Page es una estructura base para un conjunto de páginas pertenecientes a un mismo sitio Web. Este esqueleto base se almacena en un archivo independiente y luego es heredado por otras páginas que requieren esa estructura base.

Para el proyecto ha sido utilizada en algunas de las páginas para que compartan la misma cabecera y el mismo menú. También ha sido necesario utilizar la parte dinámica para cambiar el indicador del menú.

• Página Login

Como ya se indicó anteriormente, para que un usuario pueda entrar a la aplicación deberá logearse en esta. Este logeo se realiza mediante la autentificación de los Servicios de dominio de Active Directory. Para realizar este proceso ha sido necesario realizar una serie de modificaciones en el proyecto.

Primero deberemos crear la clase LdapAuthentication.cs, la cual deberá contener dos métodos: GetGroups y IsAuthenticated. Para crear estos métodos necesitaremos de dos librerías: System.Security.Principal y System.DirectoryServices. El primer método nos devuelve los grupos a los que pertenece ese usuario y el segundo nos dice si está autentificado en el Directorio Activo.

Después deberemos modificar el método Application_AuthenticateRequest del archivo Global.asax. Global.asax es un archivo opcional usado en las aplicaciones web de ASP.NET para declarar y manejar eventos y objetos a nivel de aplicación y de sesión. El método modificado nos permite comprobar si nos encontramos autentificados al entrar en una página.

Lo siguiente es modificar el archivo de configuración, llamado Web.config. En él deberemos indicar el modo de autentificación, la página de logeo, el tiempo de sesión activa…

Una vez realizado todo lo anterior, solo falta crear la página de logeo en el proyecto, página que se denominará logon.aspx. Esta página contendrá un control de login, el cual se encuentra en el toolbox de VisualStudio. Deberemos crear un evento para el botón de logearse, el cual utiliza la clase LdapAuthentication.cs para comprobar el usuario y la contraseña introducidos por el usuario.

47

Monitorización de productividad de atención al cliente Capítulo 5 - PRUEBAS

5. Pruebas A continuación se presentado el resultado de la ejecución del plan de pruebas.

ID Descripción Resultado 1 Comprobar que solo pueden loguearse los usuarios indicados. Correcto 2 Evitar inyecciones sql en el login. Correcto 3 Comprobar que la sesión se cierra correctamente Correcto 4 Las estadísticas que se generen para los empleados funcionan

correctamente. Correcto

5 Comprobar que las opciones de las estadísticas funcionan correctamente. Correcto 6 Comprobar que el envío del correo manual funciona correctamente. Correcto 7 Comprobar el listado de notas para cada usuario es el correcto. Correcto 8 Comprobar el archivo que se crea al exportar las notas. Correcto 9 Comprobar que las aportaciones se añaden o actualizan correctamente. Correcto

10 Comprobar que el historial de aportaciones por usuario es correcto. Correcto 11 Ver si el envío automático se realiza correctamente y en el tiempo

indicado. Correcto

12 Comprobar que la vista dinámica es la correcta. Correcto 13 Comprobar el archivo que se crea al exportar la vista dinámica. Correcto 14 Comprobar que las marcas del mapa de calor son las correctas. Correcto 15 Estadísticas correctas para todos los clientes. Correcto 16 Comprobar el archivo que se crea al exportar las estadísticas de los

clientes. Correcto

17 Estadísticas correctas para todos los chats de empleados. Correcto

Aunque se muestren que finalmente la comprobación es correcta para todos los apartados, decir que para ello ha sido necesario corregir varios errores de código y de mal funcionamiento.

48

Monitorización de productividad de atención al cliente Capítulo 6 – GESTION

6. Gestión del proyecto En este apartado se van a mostrar todos los sprints realizados durante el transcurso del proyecto, así como una planificación real en comparación con la planificación estimada.

6.1. Sprint Como ya se indicó anteriormente se va a utilizar la metodología scrum para tener cada 15 días pequeñas versiones del proyecto. En cada uno de ellas se expondrá las tareas realizadas en ese periodo de tiempo.

6.1.1. Sprint 1

Este sprint ha sido desarrollado entre el 01/03/2015 hasta el 15/03/2015.

En este tiempo se han realizado las siguientes tareas:

• Creación de los prototipos para la interfaz web. • Arquitectura en 3 capas. • Diseño de la BD. • Diseño del diagrama de clases.

6.1.2. Sprint 2



• Implementar la BD. • Implementación de los Procedimientos Almacenados.

6.1.3. Sprint 3



• Configuración de la conexión con la BD. • Implementación de la capa de Persistencia.

6.1.4. Sprint 4



• Implementación del modelo de dominio. • Implementación del modelo de negocio.

6.1.5. Sprint 5


49

Monitorización de productividad de atención al cliente Capítulo 6 – GESTION


• Implementación de la capa de presentación. o Página Master. o Página Login. o Resto de páginas.

6.2. Tiempo Real En este apartado se muestra para cada tarea las horas estimadas para su desarrollo y las horas reales que han sido dedicadas para su realización. Las tareas se han organizado de acuerdo a la EDP creada anteriormente.

Tarea Horas estimadas Horas reales Desfase Gestión del TFG 70 50 -20

Análisis 30 50 +20 Diseño 40 30 -10

Implementación 140 155 +15 Pruebas 20 25 +5

Proyecto completo 300 310 +10

A continuación, se presenta un gráfico de barras en el cual se muestra la comparación entre ambos tiempos.

0

50

100

150

200

250

300

350

Horas estimadas

Horas reales

50

Monitorización de productividad de atención al cliente Capítulo 7 – Conclusión

7. Conclusión Aunque es la primera vez que me enfrento a un proyecto de estas dimensiones, he podido cumplir todos los plazos de una manera satisfactoria. Esto ha sido posible gracias a una buena planificación realizada anteriormente, a la ayuda de los empleados de Arsys y a la tutora del TFG.

Uno de los problemas con los que me he encontrado ha sido enfrentarme al uso de diferentes tecnologías como ASP.NET y SQL Server sin haberlos utilizado durante la carrera. Sin embargo, sí pude utilizarlos durante el transcurso de mis prácticas, cosa que fue de gran ayuda para poder agilizar la implementación del presente proyecto.

En referencia a la aplicación, destacar que ya está siendo utilizada por los responsables del departamento de soporte y que se encuentra dentro del conjunto de herramientas que se utilizan habitualmente en el equipo de Arsys. También quiero resaltar que ha sido presentada al concurso CEX 2015 (http://www.mplus.es/premioscex2015/) y ha sido seleccionada entre las finalistas para ganar el concurso. Este concurso se presenta con el objetivo de reconocer las mejores prácticas de gestión en empresas. En esta edición las prácticas deberán versar sobre la “Orientación al Cliente”.

Por otro lado, esta aplicación ha sido preparada con la idea de poder mejorarla en un futuro, con nuevas estadísticas, nuevos datos, etc. Para su facilitación se ha documentado y redactado un manual de usuario

51

http://www.mplus.es/premioscex2015/

Monitorización de productividad de atención al cliente Capítulo 8 – Bibliografía

8. Bibliografía En este apartado se presentan las páginas web y documentos utilizados para la realización del proyecto.

1. Apuntes y trabajos obtenidos durante el grado. Accedido entre febrero y junio de 2015.

2. Stackoverflow. Disponible en: http://stackoverflow.com. Accedido entre marzo y mayo de 2015.

3. MSDN, Microsoft Developer Network. Disponible en: http://msdn.microsoft.com. Accedido entre marzo y mayo de 2015.

4. W3Schools.com The world´s Largest web developer site. Disponible en: http://w3schools.com. Accedido entre marzo y mayo de 2015.

5. Repositorio de trabajos de fin de grado de la biblioteca de la universidad de la rioja. Disponible en: http://investigadoresur.unirioja.es. Accedido entre febrero y junio de 2015.

52

http://stackoverflow.com/

http://msdn.microsoft.com/

http://w3schools.com/

http://investigadoresur.unirioja.es/

Monitorización de productividad de atención al cliente Anexo 1

9. Anexo 1. Actas de reuniones

TFG de “Monitorización de productividad de atención al cliente”

Actas de la primera reunión 9 de Febrero de 2015

I. Llamada al orden Beatriz Pérez Valle ha llamado al orden a la reunión ordinaria del TFG de “Monitorización de productividad de atención al cliente” a las 16:00 del 9 de Febrero de 2015 en el edificio Vives del despacho -----.

II. Pasar lista Las siguientes personas estuvieron presentes: David Monforte, David Rueda Lejárraga y Beatriz Pérez Valle.

III. Nuevas actividades a) Puesta en marcha de los TFG:

En este punto la directora del TFG (Beatriz Pérez Valle) nos informó de cómo poder realizar el TFG. Se acordó que cada cierto tiempo se realizarán reuniones para ver el seguimiento del TFG o para futuras dudas, así como el deber de realizar entregables durante el transcurso de la realización del TFG.

b) Información de herramientas para el apoyo en la realización de los TFG: En este punto la directora del TFG (Beatriz Pérez Valle) nos informó de que disponemos de dos herramientas para el apoyo del TFG. La primera es un grupo de Facebook en el cual el director de estudios pondrá futuras noticias de nuestro interés, así como un medio para poder proponer futuras dudas del TFG y solucionar las de otros TFGs. La segunda es una herramienta para la entrega de la documentación de los TFGs, así como medio para poder ver información de otros TFGs.

IV. Ruegos y preguntas La reunión se dio por finalizada a las 16:30.

Actas propuestas por: David Rueda Lejárraga y Beatriz Pérez Valle

Actas aprobadas por: David Rueda Lejárraga y Beatriz Pérez Valle

53



Actas de la segunda reunión 11 de Marzo de 2015

I. Llamada al orden Beatriz Pérez Valle ha llamado al orden a la reunión ordinaria del TFG de “Monitorización de productividad de atención al cliente” a las 15:15 del 11 de Marzo de 2015 en el edificio Vives del despacho 231.

II. Pasar lista Las siguientes personas estuvieron presentes: David Rueda Lejárraga y Beatriz Pérez Valle.

III. Nuevas actividades a) Revisión de la documentación:

En este punto la directora del TFG (Beatriz Pérez Valle) y David Rueda realizaron una rápida revisión de la documentación. Se encontraron varios puntos a mejorar.

b) Puntos a mejorar: En este punto la directora del TFG mando a David Rueda la mejora de algunas partes del TFG. Además le pidió que una vez realizadas estas mejoras procediera a enviarle de nuevo la documentación para realizar una revisión más detallada. El listado de punto a mejora es:

• Añadir una pequeña introducción en algunos puntos. • Arreglar las flechas del diagrama de casos de uso. • Añadir una dirección de riesgos y plan de dirección de riesgos • Detallar de una forma más detallada la estimación de los tiempos. • Relacionar cada requisito funcional con su caso de uso (Usar identificadores),

asegurándose de que no queda ningún requisito funcional que no esté representado por algún caso de uso y vice versa.

• Crear un plan de pruebas • Pensar en algún prototipo de interfaz gráfica más (puedes establecer, ayudándote de

la que ya tienes, un patrón que se repita en todas las interfaces y, basándose en ese patrón, pensar en cómo cambiaría más o menos las interfaces concretas en función de la opción del menú elegida). Igual también puedes pensar en ventanas de advertencia, de error, confirmación, etc. c) Diseño de la BD:

En este punto David Rueda le propuso una duda a Beatriz Pérez. La duda era que al tener que usar la base de datos interna de la empresa, cómo debería reflejarlo esto en la documentación. La respuesta fue que informaría que el diseño de la BD es el de la empresa y luego creara el diagrama con su correspondiente estructura.




54



Actas de la tercera reunión 23 de Marzo de 2015

I. Llamada al orden Beatriz Pérez Valle ha llamado al orden a la reunión ordinaria del TFG de “Monitorización de productividad de atención al cliente” a las 14:15 del 23 de Marzo de 2015 en el edificio Vives del despacho 231.




b) Puntos a mejorar: En este punto la directora del TFG mando a David Rueda la mejora de algunos partes del TFG. Además le pidió que una vez realizadas estas mejoras procediera a enviarle de nuevo la documentación para realizar una revisión más detallada. El listado de punto a mejora es:

• Evitar dos puntos en los títulos. • Quitar lo de capítulo 0. • Cambiar algunas frases del texto. • Repara la numeración de la descripción de la EDT. • Cambiar de apartado el seguimiento y control. • Añadir itálica, en las palabras necesarias. • Realizar una pequeña introducción antes de los requisitos. • Quitar el actor Sistema, de la especificación de requisitos. • Usar un solo prototipo para representar todas las páginas de errores. • Cambiar el diseño de clases.




55



Actas de la cuarta reunión 29 de Mayo de 2015

I. Llamada al orden Beatriz Pérez Valle ha llamado al orden a la reunión ordinaria del TFG de “Monitorización de productividad de atención al cliente” a las 13:00 del 29 de Mayo de 2015 en el edificio Vives del despacho 231.





• Cambiar las estructura de la planificación del proyecto. • Revisar faltas de ortografía y coherencia en todas las frases. • Añadir apartado de metodología. • Plasmar que además del proyecto. También debes realizar asignaturas durante el

semestre. • Cambiar de apartado el plan de pruebas. • Cambiar de nombre a los requisitos de rendimiento. • Mejorar la explicación del diagrama Entidad-Relación. • Usar Courier para métodos, clases… • Añadir la planificación real, conclusión y anexos. • Incorporarle la portada y la introducción en español e inglés.




56



Actas de la quinta reunión 19 de Junio de 2015

I. Llamada al orden Beatriz Pérez Valle ha llamado al orden a la reunión ordinaria del TFG de “Monitorización de productividad de atención al cliente” a las 13:00 del 19 de Junio de 2015 en el edificio Vives del despacho 231.





• Añadir una página en blancos después de la portada. • Revisar el resumen. • Dejar más espacios entre algunos párrafos. • Quitar dos puntos en los títulos. • Aclarar la captura de requisitos • No cortar la especificación de un caso de uso. • Rescribir para qué se utiliza cada capa de la aplicación. • Aclarar cuáles son las tablas que ya existían antes de implementar el diseño de la BD. • No separar la BD de los procedimientos almacenados. • Separar la bibliografía de la conclusión.




57


10.Anexo 2. Manual de instalación y uso de la aplicación

Manual de utilización de la aplicación

“Monitorización de productividad de atención al cliente”.

1. Introducción

El objetivo de Arsys Internet S.L es disponer de una herramienta que permita realizar un seguimiento y control del rendimiento de sus empleados, sin que ello afecte en el trabajo diario de los mismos. Este proyecto fin de grado pretende llevar a cabo el desarrollo de dicha herramienta particularizando a los empleados del Departamento de Soporte. Además, la herramienta desarrollada permitirá ver información sobre los clientes que solicitan ayuda al Departamento de Soporte.

2. Instalación

Para poder instalar la aplicación necesitaras los siguientes componentes:

• Servidor IIS • Framework .NET 3.5 o superior

En caso de cumplir con los requisitos anteriores, simplemente debes crear un debes llevar toda la aplicación al servidor IIS y darle al usuario IIS permiso de escritura para la carpeta Estadisticas de la aplicación.

3. Utilización

Vamos a explicar las páginas más importantes de la aplicación:

• Página inicio.

58


En ella veremos una pequeña descripción de los apartados más importantes de la aplicación.

• Página estadísticas empleado

Primero deberemos elegir un intervalo de fechas en los cuadro de texto correspondientes. Después, elegiremos que UN y Canal queremos ver. Y elegiremos que grupo de empleados deseamos ver las estadísticas. Una vez realizado lo anterior deberemos pulsar en el botón Aplicar para ver los resultados.

• Página Aportaciones

59


En ella deberemos elegir un día de la semana a la cual añadir un comentario. Después pulsaremos en el botón buscar y se nos mostraran todos los empleados con un cuadro de texto. Rellenamos esos cuadros con el comentario correspondiente al empleado y pulsamos Actualizar Comentario para añadirlos.

• Página Vista dinámica

En ella deberemos arrastrar las variables disponibles al recuadro que deseemos y elegir una función a aplicar. Después seleccionaremos un intervalo de fechas. Y por último, pulsar en el botón actualizar para ver la tabla correspondiente.

• Página HeatMap

60


En ella simplemente seleccionamos un intervalo de fechas y pulsamos en el botón Enviar. Después se nos actualizara el mapa marcándonos los puntos de los lugares de los clientes que se han puesto en contacto con el departamento de soporte.

• Página Estadísticas clientes

Primero deberemos elegir un intervalo de fechas y pulsaremos en Buscar Clientes. Aparecerá el recuadro de cliente con los nombres de todos los clientes que se han contratado con el departamento de soporte en esas fechas. Después marcaremos los clientes de los cuales ver sus estadísticas y pulsaremos en el botón Ver estadísticas. Por último, se crearan las estadísticas para los clientes seleccionados.

61


• Página Chats empleados

Primero elegiremos un intervalo de fechas y de que protocolo ver las estadísticas. También seleccionaremos el Grupo de empleados que deseemos. Pulsaremos el botón Aplicar y se nos mostrará las estadísticas correspondientes.

62

Monitorización de productividad de atención al cliente · Dado que las tablas origen están...

Documents

Transcript of Monitorización de productividad de atención al cliente · Dado que las tablas origen están...