Análisis y diseño de un sistema software para el registro y seguimiento de las incidencias de los clientes e la empresa Kernel Informática S.L.

Ingeniería Superior en Informática Análisis y Diseño de un sistema software para el registro y seguimiento de las incidencias de los clientes de la empresa Kernel Informática SL. Autor: • Francisco Javier Montero Vega Tutores: • Francisco José Santana Pérez • Yeray Tejera León • Norberto Navarro Espósito Las Palmas de Gran Canaria, Julio 2017 Agradecimientos Mi más sincero agradecimiento a todos los que me han apoyado. En especial a mi Familia. Contenido Introducción .................................................................................................................................. 4 Estado del Arte y Objetivos ........................................................................................................... 5 Historia ...................................................................................................................................... 5 Motivación ................................................................................................................................ 8 Objetivos ................................................................................................................................. 14 Recursos necesarios .................................................................................................................... 17 Entorno de desarrollo y pruebas ............................................................................................. 17 Entorno de producción ........................................................................................................... 18 Análisis, Diseño e Implementación ............................................................................................. 19 Requisitos funcionales............................................................................................................. 24 Requisitos no funcionales ....................................................................................................... 48 Diseño de la arquitectura del sistema ..................................................................................... 61 Diseño detallado ..................................................................................................................... 64 Implementación ...................................................................................................................... 92 Temporalización ........................................................................................................................ 109 Pruebas y mantenimiento ......................................................................................................... 110 Pruebas unitarias y funcionales ............................................................................................ 112 Pruebas de Integración ......................................................................................................... 112 Pruebas de sistema ............................................................................................................... 113 Implantación ............................................................................................................................. 114 Instalación, configuración y carga inicial ............................................................................... 115 Simulación ............................................................................................................................. 124 Personalización de Asterisk ................................................................................................... 132 Resolución de problemas ...................................................................................................... 141 Análisis de costos ...................................................................................................................... 146 Conclusiones y trabajos futuros ................................................................................................ 149 Referencias ................................................................................................................................ 154 pág. 4 Introducción El objetivo de este Proyecto Final de Carrera es la realización de un sistema software que capture y gestione las llamadas de los clientes de la empresa Kernel Informática S.L y optimice el proceso de atención, registro y seguimiento de sus incidencias. La terminología ITIL define que: “La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio.” ([ITILv3]) En una empresa el sistema informático juega un papel fundamental al posibilitar la integración entre todos sus individuos, acercando la información y haciendo la comunicación más fácil. En los procesos que se llevan a cabo dentro de la empresa, hay que disponer de conexión y coordinación para asegurar el buen funcionamiento de todas las partes. La disponibilidad de un buen sistema de comunicación puede ser de gran ayuda, incrementando la eficiencia y la rentabilidad de la empresa. Kernel Informática S.L es una empresa canaria, ubicada en Las Palmas de Gran Canaria, con una amplia experiencia en el sector de la informática. Su parque de clientes es extenso. Abarcan servicios técnicos software y hardware, desarrollo de aplicaciones, robótica y autómatas. El sistema software actual de Kernel informática S.L, posee varias deficiencias funcionales en el sistema de recepción de llamadas y gestión de incidencias que provocan el malestar de los clientes y el sobresfuerzo de los empleados. En resumen, se pretende la mejora de calidad de los procesos de atención al cliente. Hay una cita de un experto que dice: “Fallar en la atención al cliente es una forma bastante efectiva de dinamitar el futuro de una compañía.” ([Servicio]) Los riesgos de desarrollar procesos de atención ineficientes o sin el control adecuado, pueden ser tan determinantes para la evolución y el futuro de una compañía, que es tan imperioso como vital, fortalecerlos y evaluarlos. Es decir, que si la empresa fracasa en la atención al cliente, 6 de cada 10 clientes le darán la espalda, con una consecuencia dramática en los resultados de negocio. pág. 5 Estado del Arte y Objetivos Historia Kernel Informática S.L es una empresa canaria con una amplia experiencia en el sector de la informática. Su parque de clientes es extenso. Abarcan servicios técnicos software y hardware, desarrollo de aplicaciones, robótica y autómatas. El servicio de captación, atención, seguimiento y registro se ha visto renovado en varias ocasiones para ofrecer la mejor calidad de servicio a sus clientes Kernel Informática S.L desarrolló hace muchos años un paquete software de escritorio PC que atiende y gestiona a sus clientes. Este software era capaz de realizar desde la captación de la llamada entrante por medio de una centralita telefónica física, en aquel entonces estaba ubicada dentro de la oficina, que posteriormente procesaba para obtener de una agenda contenida en una base de datos local, el nombre del cliente. Posteriormente todos los puestos internos de la oficina leían la información del servidor local y mostraban en un breve pop-up de escritorio, quien estaba llamando. Conjuntamente se implementó una solución software completa para la generación de notas de incidencias para su posterior seguimiento, registro y generación de partes. Debido al auge de las nuevas tecnologías de la comunicación en centralitas telefónicas virtuales en la nube, Movistar ofreció un paquete de soluciones para empresas denominado “Movistar Fusión”. Las características de este pack de soluciones, en palabras de los comerciales de Movistar, convencieron a los responsables de Kernel Informática S.L, por lo que contrataron dicho servicio, prometiendo que mejoraría significativamente la calidad de los servicios, algo en el que siempre la empresa se ha esforzado y comprometido a mejorar durante mucho tiempo. Se exponen los casos con más detalles: 1. Reunión con comerciales que proponen el producto de movistar. 2. Kernel informática contrata los servicios 3. El servicio tarda mucho en ser implantado, teniendo múltiples visitas de los técnicos a los largo de varios meses. 4. Los técnicos de movistar instalan terminales IP en todos los puestos de la oficina, les asigna una extensión. Solo instalan un softphone en el puesto de un técnico del servicio técnico. 5. Surgen problemas con el servicio a causa de la configuración. Los técnicos tienen que configurar los terminales y la centralita virtual. 6. Pasado un tiempo siguen con problemas a la hora de identificar las llamadas, tal como les prometieron los comerciales. o El software de PC tiene notificación por pop-up pero no se utiliza porque hay que configurar el servidor virtual y el software. Tras la configuración sigue sin funcionar, salvo para llamadas internas. Los técnicos se desentienden y en la actualidad, dos años más tarde, siguen con el mismo problema. pág. 6 o La solución que ofreció Movistar es que hay que insertar en la agenda de cada puesto de trabajo, el nombre de cada teléfono de todos los clientes individualmente, ya que no existe una agenda cooperativa en la centralita Movistar en la nube. Esto es una gran desventaja y un paso atrás frente a lo que Kernel Informática S.L tenía anteriormente. Tener que replicar la base de datos de clientes, de forma descentralizada, con el consiguiente mantenimiento de tener al día en todos los puestos voz-ip la información de los clientes, es inviable. La centralita al estar en la nube cambia el escenario y el software implementado por Kernel Informática S.L, encargado de capturar las llamadas queda obsoleto, al no poder acceder a las llamadas entrantes como hacía anteriormente porque está en la nube, no en local como antiguamente. Al carecer del reconocimiento de clientes durante las llamadas entrantes, se ven obligados a improvisar y realizar un sobresfuerzo. Actualmente miran el número que llama en pantalla, siendo un parque de clientes muy amplio y diverso, es muy difícil poder prestar un servicio en condiciones, mermando la calidad en general. Por otro lado, el software para poder realizar la petición del cliente, realizar el seguimiento, registro y generar los partes aún no se ha actualizado ni mantenido en mucho tiempo: Ilustración 1 – Ventana de seguimiento de llamadas e incidencias pág. 7 Ilustración 2 – Ventana del menú principal. Programa de partes 2011 Ilustración 3.-Ventana de partes de trabajos pendientes pág. 8 Por otro lado el aplicativo para captura y seguimiento de incidencias debido a su antigüedad, Kernel Informática S.L ve la necesidad de renovarlo para aportarle mayor funcionalidad y estabilidad. En resumen: - Problema de captura de llamadas: No tienen una agenda corporativa, de tal manera que cuando un cliente llama, la centralita muestra el número en la pantalla de los teléfonos. Los comerciales prometieron que identificarían las llamadas, pero no que pudieran estar igual que antes, con la posibilidad de gestionar dicho número para obtener información del cliente y poder mostrarlo en la pantalla de los empleados. - Necesidad de actualización: El software se divide en varios aplicativos donde cada ventana tiene su función, tal como muestra las capturas por lo tanto: o Pérdida de rendimiento general al perder tiempo entre las pantallas. o El sistema está desarrollado en una plataforma Visual Fox Pro, que está obsoleta y no recibe mantenimiento de Microsoft. o No ha habido más actualizaciones ni ampliaciones de funcionalidad. Motivación Captura de llamadas Por parte de Movistar no llega la solución que solvente la necesidad de capturar el número de teléfono cuando un cliente, de Kernel Informática S.L, llame a la oficina. Lo cual impulsa la búsqueda de soluciones que permitan volver a gestionar las llamadas de los clientes. Tal como hacían antes de contratar la solución Movistar Fusión (Centralita telefónica virtual). Tras analizar el mercado y actualizar los conocimientos sobre las centralitas telefónicas virtuales, se puede entender una serie de conceptos básicos y necesarios para encontrar una solución. pág. 9 Se realizan las siguientes operaciones para intentar capturar, dentro de la oficina, el número de llamada entrante, que es la principal prioridad: 1. Capturar el número entrante mediante el único softphone instalado: a. Los técnicos de telefónica instalaron un solo softphone. Está en un puesto dentro del departamento técnico. Se presenta un problema importante, es un software cerrado y de pago. Tras multitud de pruebas ha sido imposible obtener una solución para la captura del número. 2. Sniffer: a. Se prueba a conectar un PC a la red de la oficina, concretamente al cable de red de uno de los teléfonos IP. La idea es capturar los datagramas del protocolo SIP ([RFC-SIP]) y volcarlo en un fichero. Las conclusiones son las siguientes: i. Se pueden capturar los datagramas. ii. El problema es que los campos de datos contenidos en los datagramas están encriptados, por lo que no es legible la obtención del número telefónico y por lo tanto no es una solución. 3. Acceder a la centralita o a los terminales IP: a. Se analiza toda la documentación para el acceso a la centralita telefónica en la nube y a los teléfonos ip de la oficina, pero no hay solución viable. Ante la falta de opciones, hubo que buscar soluciones alternativas. Entre estas alternativas, se consideró analizar el mercado de las centralitas telefónicas software. En el mercado actual destaca con gran diferencia la solución de Asterisk y FreePBX. Ilustración 4: Ejemplo de centralita virtual en la nube pág. 16 10.2. Una vez capturado el número de teléfono, hay que consultar si se trata de un cliente y en caso positivo, obtener toda su información del sistema de incidencias, siendo otro objetivo importante la centralización para toda la empresa de los números de teléfono, o sea, la creación de una agenda corporativa. 10.3. Además surge otro objetivo, identificar el aplicativo encargado de procesar las llamadas ya que Asterisk por sí misma no puede realizarla, por lo tanto: Hay dos sistemas definidos. Primero, el sistema Asterisk que captura de la línea telefónica el número de teléfono y el segundo es el sistema que ha de procesar dicho número. Cuando se busca un aplicativo que aporte interoperabilidad entre dos sistemas diferentes, como este caso un Sistema Linux con servidor Asterisk ([Asterisk]) y un aplicativo realizado en Webdev sobre Windows, estamos definiendo un aplicativo de servicios web o webservice ([WS]). 10.4. Otro objetivo es detectar como y cuando ha de llamarse al webservice de modo que procese en el menor tiempo posible la llamada. Disponiendo de los datos de la llamada del cliente en la menor brevedad. 10.5. Otra necesidad es la comunicación dentro de la oficina de Kernel Informática S.L de los datos generados por el webservice al sistema de incidencias. Se propone el estudio de los siguientes métodos: 10.5.1. Compartir la base de datos del webservice y del sistema de incidencia en el mismo servidor de la oficina. La consulta se realiza directamente sobre base de datos. 10.5.2. La posibilidad de implantar un sistema de RSS (Sistema para compartir información en la web de manera muy simple) ([RSS]). Se basaría en consultar el fichero RSS dentro de la red de la oficina. 10.6. En resumen, se pretende conseguir un sistema de captación de llamadas entrantes parecido al que Kernel Informática S.L tenía antes de la implantación de Movistar Fusión (página 5). Pero en este caso, mediante centralita telefónica software (vía protocolo SIP ([RFC-SIP]) ). pág. 17 Recursos necesarios Entorno de desarrollo y pruebas Hardware: • Portatil HP pavilion g6 + monitor Sony x72 o 4GB ram 800 mhz. o Procesador intel I3-2350M. o SSD 240gb o Pantalla de 15’4 pulgadas. Resolución: 1366x768.. o Segunda pantalla, Sony x72. Resolución: 1280x1024. o Teclado Querty integrado. o Ratón Logitech M210 óptico. Resolución: 1000dpi. o Controlador de sonido: 1-IDT High Definition. o Wifi Intel tipo n • Samsung S4 GT-I9505 o Android 5.0.1. o Pantalla AMOLED de 5”. Resolución: 1920x1080. o 2GB ram. o Capacidad 16GB. o Conectividad: Wifi, bluetooth, nfc, gps y 4g. o Cámara: trasera de 13Mpx/frontal 5Mpx. • Servidor en la nube para pruebas. o Facilitado por Kernel Informática S.L Software: • Windows 7 profesional 64bits o Licencia Original (HP pavilion g6) • Programación en WebDev 21 o Licencia obtenida por Kernel Informática S.L. • USB Network Gate Vesión 7.0 (build 7.0.1370) o Licencia obtenida por Kernel Informática S.L. • WampServer 3.0.4 64bits o Licencia GPL. o Apache 2.4.18 - PHP 5.6.19 - MySQL 5.7.11. • Navegador Chrome Versión 58.0.3029.110 (64-bit) o Licencia de software libre. • Avira Free Antivirus Versión 15.0.26.48. o Licencia Free • Microsoft Office o Licencia obtenida por Kernel Informática S.L • Umbrello UML Modeler 2.18.2 o Licencia GNU versión 2 • Dia (diagramas estructurados) 0.97.2 o Licencia de software libre pág. 18 • Virtualbox 5.1.10 o Código abierto bajo los términos GPL 2 o Contiene una máquina virtual con:  Centos 6.5 (Final); Free software, GPL • Ejecutando: AsteriskNOW (Servidor PBX) v10.13 • Xmind 7 free o Licencia open source (LGPL v3 y EPLv1) • Google Drive 2.34.5075 o Código abierto Entorno de producción Hardware: • Equipo Acer Aspire XC-605 o 4GB ram 1066 mhz. o Procesador intel I5-4440. o SSD 240gb. o Monitor ACER 19” V193W. Resolución: 1440x900 o Teclado y ratón originales de Acer. o Ethernet Gigabit • Multifunción Lexmark X3550 o 24 ppm negro y 17 ppm color o Impresión máxima 4800x1200 ppp o Resolución óptica 600 x1200 ppp Software: • Windows 7 profesional 64btis o Adquirido con el equipo ACER Aspire XC-605 • Webdev 21 application server o Licencia obtenida por Kernel Informática S.L. • HiperFileSQL server o Libre distribución • HiperFileSQL control center o Libre distribución • WampServer 3.0.4 64bits o Licencia GPL. o Apache 2.4.18 - PHP 5.6.19 - MySQL 5.7.11. • Virtualbox 5.1.10 o Código abierto bajo los términos GPL 2 o Contiene una máquina virtual con:  Centos 6.5 (Final); Free software, GPL • Ejecutando: AsteriskNOW (Servidor PBX) v10.13 pág. 19 Análisis, Diseño e Implementación Adquisición de información La primera toma de contacto, es mantener una reunión con el máximo responsable de la empresa Kernel Informática S.L. El propósito el obtener una vista global del proyecto. Primera entrevista La entrevista con D. Norberto Navarro Espósito, director de la empresa Kernel Informática S.L, se orienta a la necesidad de desarrollar un software que tengan como objetivo mejorar la calidad del servicio de atención al cliente, el seguimiento y gestión de sus incidencias. La solución software la utilizará internamente el propio personal de la empresa y de forma externa, los clientes. Aportará una mejora en la eficiencia de la actividad rutinaria de los empleados y en la atención del cliente. Se ha estudiado múltiples razones por el cual se decide desarrollar una solución software a medida. La principal es que tras estudiar soluciones software que hay actualmente en el mercado, estas no se ajustan plenamente a los requerimientos de la empresa. Las necesidades que actualmente no tienen son: • Captura y procesamiento de la llamada entrante. Identificando a los clientes antes de descolgar. • Integración del registro de llamadas entrantes conjuntamente con el sistema de registro y seguimiento de incidencia de clientes. • Reducir el número de llamadas de los clientes solicitando información del estado de su incidencia vía telefónica. Los clientes tendrán acceso al aplicativo donde podrán consultar y a su vez enviar incidencias. • Optimizar el seguimiento de incidencias (temporización de tareas y alertas) • Mejor organización, monitorización, consulta y acceso a los registros de incidencias y documentos mediante un sistema de conocimiento. Todos los empleados estarán informados del seguimiento y estado de las incidencias, reduciendo las interrupciones y llamadas internas entre ellos. • Permitir acceder al aplicativo desde el exterior. • Control de acceso según los diferentes roles de usuario. pág. 20 Entorno de la solución Se describe un entorno web principalmente por la portabilidad necesaria para acceder e interactuar remotamente, tanto a empleados como a clientes. La integración del registro de llamadas conllevará a un esfuerzo adicional donde será necesario buscar una solución para interceptar las llamadas entrantes de la oficina, filtrarlas y procesarlas para obtener, en caso de que sea un cliente, toda la información para que el personal pueda prestar un servicio de calidad. ¿Hay alguna limitación o aspecto especial de rendimiento que vaya a afectar a la forma en la que se enfoque la solución? Antes de la primera reunión de grupo se plantean aspectos generales a tener en cuenta. Sin tener definidos los requisitos del proyecto, se enfocan los siguientes riesgos: • Al tratarse de una aplicación que va a tener comunicación con varios puestos de trabajo de usuarios, se plantea que un bajo rendimiento en la comunicación de red pueda repercutir, y de manera global, con un nivel no óptimo de rendimiento. • La navegación tiene que ser rápida, siendo un interface minimalista. • Desde que se captura la llamada hasta que informa al aplicativo y por ende a los empleados, tiene que ser en los primeros tonos. • La respuesta del sistema al estar muchos usuarios conectados no debe suponer un problema. • El hardware de la máquina donde corra tiene que tener suficiente potencia para garantizar un trabajo fluido. Establecimiento de reuniones en grupo mediante TFEA Mediante la técnica para facilitar las especificaciones de la aplicación ([Press10], 2010), se pretende involucrar a todos los usuarios del aplicativo. Las reuniones tendrán como fin ahorrar tiempo, consensuar conjuntamente los requerimientos y minimizar los riesgos. Se tomarán en conjunto las medidas para la resolución de problemas, negociación y especificación. pág. 21 Los participantes en la reunión fueron: Representante del grupo administrativo: Participante Norberto Navarro Organización Kernel Informática S.L Rol Directivo Es desarrollador Si Es cliente No Es usuario Si Comentarios • Director de Kernel Informática S.L. • Analista y programador con 30 años de experiencia. • Tutor del proyecto Representante del grupo técnico: Participante Armando Organización Kernel Informática S.L Rol Administrador de sistemas Es desarrollador No Es cliente No Es usuario Si Comentarios • Jefe del servicio técnico. Representante de administración: Participante Susana Organización Kernel Informática S.L Rol Recepcionista Es desarrollador No Es cliente No Es usuario Si Comentarios • Encargada de recepción de llamadas de clientes. pág. 22 Representante de cliente: Participante José Organización Empresario Rol Cliente de Kernel Informática S.L Es desarrollador Si Es cliente Si Es usuario Si Comentarios • Asesor de Kernel Informática • Cliente de Kernel Informática Se define como moderador a Norberto Navarro Esposito, Director de Kernel Informática S.L y tutor. Expone ante el grupo presente su visión general del proyecto, su necesidad y justificación del nuevo producto. Posteriormente, los representantes de forma coordinada exponen sus propuestas de refinamiento, puntos de vistas y pasos concretos hacia el desarrollo de la aplicación. Como resultado se obtiene las listas consensuadas. Cada representante, posteriormente a la visión general del proyecto expuesta por Norberto, analiza sus prioridades y necesidades esenciales, confeccionando individualmente una lista de objetos que se encuentren en el entorno que rodea al sistema, operaciones que manipulen o interactúen, restricciones y criterios de rendimiento. Obteniendo un conjunto de mini especificaciones. Finalmente, las mini especificaciones se presentan a todo el grupo para pasar a analizarlas. Con ello se obtuvo que añadir correcciones, adiciones y eliminaciones de requerimientos, servicios y restricciones en las listas originales. El análisis de todas las mini especificaciones pasó por una siguiente etapa de validación, donde se tiene en cuenta repasar los riesgos y la viabilidad del conjunto de requisitos. La primera reunión finaliza con la obtención de un borrador inicial. Tras analizar todas las mini especificaciones y validar las ideas de equipo se redacta un borrador en conjunto que plasme todos los aspectos consensuados y revisados en la reunión. pág. 23 Los aspectos que no pudieron ser resueltos en la reunión se conservaron para posteriores reuniones, donde se trataron y resolvieron. En algunos casos puntuales con técnicas de observación y entrevistas con empleados durante la jornada de trabajo. Ilustración 6 . Proceso de ingeniería de requerimientos ([Somm05], 2005) Ilustración 5: Obtención y análisis de requerimientos ([Somm05], 2005) pág. 24 Las necesidades nombradas de mayor a menor prioridad son: 1. El sistema SRIC tiene que realizar los procesos de gestión de incidencias, cumpliendo con las reglas de negocio establecidas, respetando los roles, aportando mayor funcionalidad y facilidad en general. 2. Otra prioridad es la búsqueda de una solución al reconocimiento de las llamadas entrantes a través de la centralita virtual Movistar. 3. De cara al desarrollo del proyecto, es importante poder empezar a utilizarlo en la menor brevedad, comenzando por la tarea de captura y registro de la llamada. Progresivamente ir implementando otras necesidades. Como resultado de los documentos generados en las reuniones establecidas mediante TFEA, se obtiene como salida el siguiente documento de requisitos funcionales y no funcionales. Requisitos funcionales Identificación inicial del Aplicativo Web Inicialmente se identifica la composición del sistema software, compuesta por los siguientes sistemas: 1. Sistema de administración: El administrador o supervisor es la máxima autoridad, tiene control total sobre el sistema, incluyendo la gestión. El resto de empleados, según sus diferentes perfiles de usuario, podrán administrar de forma limitada. 1.1 Gestión de usuarios: Consulta y administración de usuarios. 1.2 Gestión de Clientes: Consulta y administración de clientes. • Gestión de direcciones • Gestión de Contactos • Importación desde Visual Fox Pro 1.3 Gestión de dispositivos-aplicativos: Administración de dispositivos y elementos software de los clientes. 1.4 Gestión de informes: Se encargará de generar informes administrativos y estadísticos. 1.5 Gestión de reglas: Orientado al control del comportamiento de ciertas tareas o eventos del sistema. El administrador podrá configurar un conjunto de reglas. • Calendario lectivo • Control de tiempos (tipo incidencia-prioridad) 1.6 Gestión de incidencias: Todos los empleados tendrán acceso al sistema de incidencias. pág. 25 2. Sistema de incidencias: Encargado del registro, documentación, seguimiento, notificación y resolución de incidencias. • Base de conocimiento (Histórico de incidencias): Provee de funciones que facilitan el seguimiento de las incidencias además de los medios para la recolección, organización y recuperación de conocimiento. • Sistema de Notificación: La base de conocimiento notificará sobre la caducidad de las fechas de solución y resolución para un correcto seguimiento de las incidencias. • Comentarios internos: La comunicación e información de eventos y estados son relevantes para un buen seguimiento. • Portal web del cliente: Funciones que puede realizar el cliente. • Procedimiento de captura, seguimiento y cierre: Requisitos para el procesamiento de las incidencias. 3. Sistema de control • Control de acceso por usuario: El sistema tiene que gestionar el control de acceso al sistema, mediante usuario y contraseña. • Control de estimación de tiempos (tipo incidencia-prioridad): Gestiona la estimación de tiempo durante la creación de una incidencia, determinado las reglas del calendario laborable y la tabla de tiempos en función del tipo de incidencia y prioridad. • Control de llamadas entrantes: Capturar las llamadas entrantes de la centralita telefónica virtual en la nube, mostrarlas con información detallada del cliente, facilitando al usuario de atención al cliente saber su situación antes de descolgar. 4. Sistema de mantenimiento • Gestión de mantenimiento software: Se generará logs e información que facilite el mantenimiento y depuración. pág. 32 2.3.5. Para localizar una incidencia en concreto se puede indicar el identificador de la incidencia o número de ticket directamente. 2.3.6. Todas las incidencias podrán contener múltiples marcadores personalizados (Tags) que faciliten la categorización e identificación de las incidencias. Con la intención de remarcar y facilitar el acceso a aquellas incidencias (cerradas o no) y documentadas con soluciones sobre problemas específicos, ayudando a generar documentación técnica en base a todos los comentarios y documentos adjuntos a los mismos, más la redacción de la resolución técnica al cerrar la incidencia. 2.3.7. Mínimo el rol de técnico pueden acceder a la sección de resolución de una incidencia donde podrán redactar la resolución de cara al cliente y además añadir o quitar marcadores o tags, que estarán visibles en una lista. 2.3.8. Toda búsqueda de conocimiento además podrá aplicar filtros. 2.4. Sistema de notificación 2.4.1. Posee notificación visual de caducidad de fechas y notificación de mensajes en el sistema de conocimiento (cambios, o bien, nuevo comentario interno en una incidencia) 2.4.2. El sistema de conocimiento informará con color amarillo sobre la fecha de estimación para dar una solución al cliente si esta se caducara. 2.4.3. El sistema de conocimiento informará con color rojo si ha sobrepasado la fecha para resolver la incidencia. 2.4.4. El sistema de conocimiento informará marcando toda la incidencia de gris si el responsable de la incidencia (que no es el empleado que la observa) no ha accedido a ver algún comentario nuevo que ha escrito un compañero/a dentro de su incidencia, o bien, acceder a cualquier evento sucedido. 2.4.5. Si un usuario con rol mínimo de técnico cambia el estado de una incidencia, sea o no suya, el sistema notificará al supervisor responsable de la misma. 2.4.6. Estos avisos serán visible por todos los empleados. 2.5. Sistema de comentarios internos por cada incidencia 2.5.1. Por cada incidencia, los usuarios de rol técnico como mínimo pueden añadir comentarios personales en la ficha de la incidencia. 2.5.2. Por cada comentario además del mensaje, permite adjuntar cualquier fichero que quedará adjunto al comentario. 2.5.3. Los comentarios serán visibles por todos los empleados, pero si no son técnicos como mínimo no podrán adjuntar ficheros al comentario. 2.5.4. Todos los empleados desde la vista del gestor de conocimiento pueden seleccionar una incidencia y observar los comentarios y descargar los ficheros adjuntos de sus comentarios si tuvieran. 2.5.5. En caso de cambio de estado de una incidencia el sistema registrará en la base de datos la transición de un estado a otro. Además añadirá un comentario de pág. 33 diferente color dentro de la incidencia informando del evento ocurrido y el nombre del usuario que lo realizó. 2.6. Portal web del cliente 2.6.1. Los clientes pueden consultar el registro de sus incidencias, así como el estado de cada una de ellas, por medio del portal web. 2.6.2. El cliente desde su portal web puede enviar una incidencia. El sistema le asignará un número de ticket que podrá consultar en la información de su incidencia, además mostrará el estado y la fecha de registro. 2.6.3. Como parte de los informes generados, el cliente puede rellenar y enviar un formulario de satisfacción, incluida su opinión personal, por cada incidencia que tenga en su portal. Quedando registrado en el sistema. Esta acción envía al instante un email a los empleados, previamente seleccionados mediante una regla de supervisión, donde adjuntará el documento en formato pdf. Datos de tipo de incidencia o Incidencia-ID o Denominación  Hardware  Software  Operativo  Antivirus  Comunicaciones  Otras Datos de histórico de incidencia o Incidencia-ID o Fecha y hora o Cliente-ID o Dirección-ID o Incidencia-ID (Tipo) o Prioridad-ID (Tipo) o Dispositivo-ID o Aplicativo-ID o Descripción de la incidencia manual o Estado  Abierta  En resolución  Pendiente pieza del fabricante o proveedor  Cancelada  Cerrada o Fecha último cambio estado o Agente-ID (persona asignada para su resolución) o Tiempo estimado resolución o Tiempo real de resolución pág. 34 Datos de prioridad o Prioridad_ID o Tipo: • Normal • Baja • Alta • Urgente Datos de comentarios en incidencias o Incidencia-ID o Fecha y hora o Contacto-ID / Agente-ID o Comentario-ID (Tipo) o Comentario 2.7. Procedimiento de captura de incidencia, seguimiento y cierre 2.7.1. Los procesos de captura son los siguientes: Datos requeridos en la captura de una incidencia telefónica o El agente de atención al cliente crea una nueva incidencia. o Localiza el cliente, dirección y contacto o Selecciona un técnico que supervisará la incidencia. o Selecciona el dispositivo involucrado en la incidencia. o Selecciona el aplicativo involucrado. o Fecha y hora de la creación o Minutos de atención telefónica. o Tipo de problema y la prioridad de la misma. o Fecha mínima y máxima para la solución (calculado automáticamente mediante el control de fechas (RF 3.236) o Inserta el título y redacta el problema en detalle. o Si es una incidencia breve y queda resuelta se creará una incidencia rápida o nota, siendo el usuario creador de la incidencia el mismo que el supervisor. La incidencia pasará a estado cerrado. Si no quedara resuelta, se crea con normalidad y pasaría a la atención del técnico supervisor seleccionado quedando la incidencia en estado “abierta”. pág. 35 Datos requeridos al cliente para enviar una incidencia o Estar logueado identifica cliente, dirección y contacto. o Escribir el título de la incidencia o Redactar la incidencia y enviar. El sistema crea la incidencia. o El agente encargado de recibirla revisará los datos si es necesario. 2.7.2. Si la incidencia está abierta el usuario, que como mínimo es un técnico, irá resolviendo la incidencia e informando de su estado además de redactar la información relevante que considere tanto para los demás compañeros como para registrar algún conocimiento al respecto. 2.7.3. Si fuera necesario otro usuario de rol técnico como mínimo, podrá participar en la resolución de dicha incidencia. Pudiendo modificar el responsable de la incidencia si fuera necesario. 2.7.4. Una vez resuelta la incidencia. Si el usuario es un técnico, marcará el estado de “cerrada”. El sistema mostrará un recuadro donde tiene que redactar la solución de cara al cliente. Igualmente se mostrará la lista de marcadores o tags para que facilite, si ve que es necesario, información. Tendrá la opción de previsualizar el parte en formato pdf, cuando considere que está correcto tendrá una opción de “informar al jefe técnico” que es el responsable de revisar y verificar el parte y el encargado de enviar el parte al cliente vía email. 2.7.5. Todo evento de cerrar la incidencia y el envío, por parte del jefe técnico, del parte de trabajo al cliente, quedará registrado en comentarios automáticos dentro de la incidencia para información de todos. 2.7.6. Los únicos que pueden enviar un parte de trabajo son los usuarios que como mínimo tienen el rol de jefe técnico. 2.7.7. El parte se podrá previsualizar y reenviar siempre. 2.7.8. A pesar de que una incidencia esté cerrada, seguirá siendo accesible y cualquier empleado podría añadir un comentario. 2.7.9. Toda incidencia cerrada puede ser reabierta. Mínimo hay que ser usuario con rol de técnico. 3. Sistema de control 3.1. Control de acceso de usuario 3.1.1. El sistema tiene que gestionar un control de acceso al sistema mediante usuario y contraseña. 3.1.2. En el proceso de alta en el sistema, el usuario será el nombre del email y su clave la que haya definido. 3.1.3. En caso de olvidar su contraseña, en el login, podrá solicitar “recordar contraseña” y el sistema le enviará un email recordándoselo, a su nombre de usuario pág. 36 3.1.4. La contraseña tendrá que tener un tamaño mínimo de 5 caracteres alfanuméricos. 3.1.5. Con el fin de facilitar el acceso, el sistema utilizará una cookie que recuerde el último usuario y contraseña logueado con éxito. 3.2. Estimación de tiempos (Tipo incidencia-Prioridad) 3.2.1. En el proceso de creación de una nueva incidencia, el sistema facilitará el registro mediante el cálculo automático de la fecha estimada para la solución y resolución de dicha incidencia. Se calcula tomando los datos de la regla de supervisión Calendario lectivo (requisito funcional 1.5.3) y Tiempos en función de tipo de incidencia y prioridad de la misma (requisito funcional 1.5.4) donde se obtiene el calendario lectivo y el tiempo estimado por la empresa (o por contrato de mantenimiento). El sistema localiza el tiempo mínimo y máximo para una solución y resolución. Estas fechas se incluyen en la incidencia y el sistema de conocimiento hará uso de ellas para notificar si están en vigor o han caducado, para organizar por prioridad o tiempo de caducidad, etc. 3.3. Captura e identificación de llamadas entrantes 3.3.1. Hay que capturar e identificar el número de llamada entrante proveniente de la centralita telefónica virtual (PBX) contratada por Kernel Informática S.L para su posterior procesamiento. 3.3.2. El número debe de ser localizado en la base de datos, para identificar a un posible cliente. 3.3.3. Cuando detecta que es un cliente tiene que extraer información relevante del mismo para que el usuario de atención al cliente esté informado de su estado. 3.3.4. La información será: Nombre del cliente, resumen de incidencias no cerradas y descripción o notas informativas redactadas en la ficha del cliente. 4. Sistema de mantenimiento Gestión de mantenimiento software 4.1.1. Los empleados exclusivamente tendrán acceso a esta gestión. 4.1.2. El sistema software generará logs que faciliten el mantenimiento y depuración: 4.1.2.1. Mantenimiento: • Se controlará el login de los usuarios de modo que los administradores del sistema puedan controlar la entrada y salida del sistema de los usuarios. 4.2.1.2. Se registrará eventos del sistema que faciliten la depuración, el log lo podrá reiniciar el usuario que como mínimo tenga rol de técnico: • Comportamientos erróneos del software. • Registro de eventos críticos o relevantes. pág. 37 Definición de los Actores ACTOR-01 Usuario de atención Versión 2.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hace referencia al empleado de Kernel Informática S.L que captura, atiende la llamada del cliente y realiza gestiones básicas. Comentarios • Tiene que tener correctamente cumplimentado sus datos de empresa. • Tiene habilidad comunicativa de cara al cliente. • Su prioridad es cuidar la imagen de la empresa, ofreciendo el mejor servicio. • Tiene la posibilidad de resolver pequeños problemas cotidianos, de fácil resolución. Esto permitirá la mejora de gestión de tiempo. Ilustración 7: Jerarquía de actores pág. 38 ACTOR-02 Técnico Versión 2.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hace referencia a los empleados de Kernel Informática S.L que heredan todas las funciones del ACTOR-01. Ejecutan las tareas adecuadas para la resolución de incidencias. Bajo la supervisión del ACTOR-03. Administran los recursos del servicio técnico. Comentarios • Tiene que tener correctamente cumplimentado sus datos de empresa. • Dispone de conocimientos avanzados de resolución de problemas informáticos, tanto software y hardware. • Su lugar de trabajo son: su puesto del departamento técnico dentro de Kernel Informática S.L y sus visitas a los clientes. ACTOR-03 Encargado Técnico Versión 2.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Armando Rol Hace referencia a los empleados de Kernel Informática S.L que heredan todas las funciones del ACTOR -02. Su gestión del departamento está supervisado por el ACTOR -04. . Las funciones adicionales con respecto a un técnico son:  Controlar el flujo de trabajo dentro del departamento, ordenando tareas al resto de técnicos.  Es el responsable directo del departamento.  Encargado de verificar y enviar el parte de trabajo al cliente. Comentarios • Tiene que tener correctamente cumplimentado sus datos de empresa. • Solo puede haber un encargado técnico por departamento. • Tiene que estar informado de toda la actividad del departamento para facilitar su gestión. pág. 39 ACTOR-04 Supervisor Versión 2.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hereda todas las funciones de gestión y administración del ACTOR-03. Hace referencia a los directivos de Kernel Informática S.L, encargados de gestionar y administrar todos los recursos humanos, materiales y documentales. Comentarios • Tiene que tener correctamente cumplimentado sus datos de empresa. • Ejemplo de supervisor: El gerente y el Director. • Constantemente monitorizan la salud de la empresa. • Son los responsables de todas las decisiones importantes. • Tienen acceso a toda la funcionalidad del sistema software. ACTOR-05 Cliente Versión 1.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hace referencia a los clientes registrados en Kernel Informática S.L Comentarios • Tienen que tener correctamente cumplimentado sus datos en el sistema. • Todo cliente tiene un contrato de mantenimiento con Kernel Informática S.L ACTOR-06 Usuario Versión 1.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol El actor hace referencia a todo usuario del aplicativo. Pudiendo ser: ACTOR-01, ACTOR-02, ACTOR-03, ACTOR-04, o bien, ACTOR-05. Comentarios Ninguno pág. 40 ACTOR-07 Empleado Versión 1.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hará referencia exclusiva a todo empleado de Kernel Informática S.L, que esté registrado en el sistema. Comentarios • Los empleados se distribuyen en los diferentes departamentos de Kernel Informática S.L. ACTOR-08 Solicitante Versión 1.0 ( 04/11/16 ) Autores Francisco Javier Montero Vega Fuentes Norberto Navarro Esposito Rol Hace referencia a un cliente de Kernel Informática S.L que aún no tiene un usuario para acceder al portal web, pero tiene intención de hacerlo poniéndose en contacto con Kernel Informática S.L. Comentarios • El solicitante tiene que ser cliente de Kernel Informática S.L • El Solicitante no es un usuario del sistema. • El solicitante puede solicitar el alta de su usuario por dos vías: Registro a través de la web, o bien, por solicitud directa a un administrador. pág. 41 Casos de uso Ilustración 8: Casos de uso del sistema SRIC pág. 48 Requisitos no funcionales 1. Para obtener una mejora de la accesibilidad, flexibilidad y movilidad, se decide el desarrollo de un software Web. 2. El entorno de desarrollo a utilizar será de la empresa PCSoft, concretamente la herramienta WebDev versión 21. 3. El software tiene que ser sencillo de mantener. 4. El sistema tiene que trabajar con los navegadores más comunes (Chrome, Internet Explorer y Firefox) 5. La Base de datos actual está en Visual Fox Pro, Por lo que hay que realizar la migración a la base de datos HFSQL de WebDev. 6. El cliente puede consultar el estado y datos relativos a sus incidencias pendientes, pero hay que restringir el acceso a comentarios internos de los empleados, asociados a sus incidencias. La información será filtrada para mostrarle solo lo que solicita. 7. Se establecerá un tiempo máximo de inactividad en el sistema, de modo que si un usuario que se haya logueado en el sistema, sobrepasa dicho tiempo de inactividad, el sistema automáticamente le cerrará la sesión. Razón de seguridad para evitar el hackeo del sistema. 8. La resolución de pantalla mínima será de 1024x768 pixeles. 9. El servidor debe de ser compatible con la plataforma PCSoft WebDev. 10. El proyecto debe simplificar las tareas de mantenimiento del propio sistema. 11. Debe de contener mecanismos de seguridad que eviten el uso malintencionado del software. 12. El proyecto debe de cumplir con la ley oficial de protección de datos, acorde con la ley orgánica 15/1999 del 13 de diciembre (nota: el servidor no puede estar fuera de Europa). 13. El sistema ha de informar al usuario de atención al cliente, si el cliente al que va a atender su problema no ha pagado su cuota mensual. Tanto si el cliente se ha puesto en contacto vía telefónica o por el portal web (Portal web, el sistema software no reconocerá email, es la encargada de recepción, principal actor que atiende al cliente, el que lee el correo con regularidad, por lo que el software de correo de la empresa tiene que notificar al empleado). 14. Sistema tiene que facilitar información al gerente de los usuarios que no hayan pagado la cuota mensual de mantenimiento. 15. Proceso de baja del sistema: El supervisor tendrá presente la ley actual de protección de datos. 16. Todos los informes que se generan siempre serán al momento, y solo se guardarán temporalmente en el servidor hasta que finalice la tarea de visualizarlo o descargarlo. La razón son motivos de seguridad a estar desactualizado y por razones de espacio. pág. 49 17. Respecto al caso de uso “Descarga uniforme” derivan: a. El navegador debe de estar configurado, de modo que si no tiene predefinido una carpeta de descarga, deberá mostrar un dialogo donde el usuario seleccione la carpeta de descarga. b. En la máquina local tendrá que tener instalado algún software que permita abrir el fichero PDF. 18. Respecto a los informes: a. El navegador ha de ser compatible para visualización PDF. Actualmente hay pocos que no lo sean. b. El PDF tiene que tener un formato listo para ser impreso a papel, teniendo el logo de la empresa, todos los datos identificativos (identificadores, fechas, etc…). Además de todos los detalles. 19. Todo informe del sistema ha de tener dos partes diferenciadas: a. En la parte superior irá la cabecera donde tendrá todos los datos que guarden relación con el documento. b. En la parte inferior y posteriores páginas se indicaran todos los datos referentes a los detalles del informe. 20. Se dan dos requisitos no funcionales derivados del requisito funcional “cerrar incidencia” : a. Generar un informe de parte para el cliente. Para ello se mostrará la información abreviada: i. Cabecera de datos de la incidencia ii. Tareas realizadas y sus tiempos dedicados. b. El sistema ante el cierre de incidencia tiene que enviar un email al encargado técnico para que este quede informado. Tiene que adjuntarse el informe de incidencia y el de parte, ambos en formato PDF y que no superen un tamaño máximo de 1Mb para facilitar el envío de email. 21. El sistema ha de crear una incidencia si al registrar una nota (el usuario de atención al cliente) se especifica : a. Que esté sin resolver. b. Ha llevado un largo tiempo resolverla y tiene que crearse un registro de incidencia. 22. La web seguirá un diseño web minimalista. 23. Se debe mantener una lógica en la navegación de la web cada vez que se pulse la tecla tabulador, principalmente en formularios, con el fin de facilitar el diseño minimalista. 24. En los controles más sensibles (datos obligatorios, información sensible, etc.) se precisará de un control adicional que verifique la correctitud de los datos insertados. Ejemplo: El campo de email tiene que ser correcto, siguiendo las normas estándar del formato email. pág. 50 Diagrama de Estado ([UML]) Ilustración 9: Diagrama de estado – Atención al cliente pág. 51 Ilustración 10: Diagrama de estado – Procesar incidencia Ilustración 11: Estados de las incidencias pág. 52 Ilustración 12: Registro y login de un cliente vía web pág. 53 Diagrama de clase Ilustración 13: diagrama de clases del sistema SRIC pág. 54 Ilustración 14: Vista detallada del diagrama de clases del sistema SRIC pág. 55 Ilustración 15: Vista detallada del diagrama de clases del sistema SRIC pág. 56 Ilustración 16: Vista detallada del diagrama de clases del sistema SRIC pág. 57 Ilustración 17: Vista global del diagrama de clases detallado del sistema SRIC Identificación inicial del Webservice (Solución Centralita Virtual) Para la solución de uno de los objetivos del proyecto, (página 16, apartado 10.3), se estudia la necesidad de un webservice para el procesamiento de las llamadas entrantes de los clientes de Kernel Informática S.L. Se elige un webservice debido a la interoperabilidad ([WS]) entre dos sistemas diferentes. El sistema Linux con Asterisk enviará la información de las llamadas y el webservice realizará el procesamiento de estas llamadas. Este webservice se encargará de procesar las llamadas que el sistema Asterisk le pondrá en una carpeta compartida. Al llamar al webservice, comenzará el procesamiento de las llamadas, registro y actualización de su tabla de registro de llamadas y externamente el fichero RSS, que informa de las llamadas a todos los puestos de la intranet de Kernel Informática S.L. pág. 64 Diseño detallado Definición de sistemas, subsistemas y módulos Sistema de base de datos: Representado por el servidor HFSQL de PCSsoft. Ilustración 23: Diseño del servidor HFSQL pág. 65 Sistema software SRIC Representación del sistema SRIC: Ilustración 24: Sistema software pág. 66 Subsistema Software de SRIC Ilustración 25: Subsistema software pág. 67 Subsistema de gestión Módulo de incidencias pág. 68 Módulo de clientes pág. 69 Módulo de usuarios Módulo de dispositivos pág. 70 Módulo de informes Subsistema de mantenimiento pág. 71 Subsistema de Control Sesión de usuario pág. 72 Subsistema de administración pág. 73 Identificación de módulos críticos Tras revisión de cada módulo hay que identificar cuáles son críticos teniendo en cuenta los siguientes criterios: 1. Están dirigidos a varios requisitos 2. Tiene un mayor nivel de control 3. Son complejos o propensos a errores 4. Tienen requisitos no funcionales muy definidos. Por lo tanto, los módulos que cumplen en gran medida con estos puntos son: 1. Subsistema de gestión o Módulo de incidencias o Módulo de usuarios 2. Subsistema de control o Módulo de control de sesiones Patrones de diseño Patrón controlador vista modelo Se aplicará el patrón MVC por las siguientes razones: 1) Interactúan con el usuario a través de la interface de usuario o vista. 2) El controlador está presente para cualquier evento proveniente de la vista. Es el encargado de informar al modelo el cual aplicará las reglas y acciones a realizar para mostrarlo en la vista. 3) Separadamente, el modelo tiene comunicación bidireccional con el sistema de base de datos. Ilustración 26: Patrón MVC pág. 80 Diseño de módulo de gestión de incidencias Ilustración 35: Gestión de incidencias pág. 81 Diagramas de interacción Ilustración 36: Diagrama de interacción – Iniciar sesión Ilustración 37: Diagrama de interacción – Capturar incidencia telefónica pág. 82 Ilustración 38: Diagrama de interacción – Cerrar incidencia pág. 83 Diseño de Base de datos: Modelado Entidad – Relación. Ilustración 39: Modelo de base de datos del sistema SRIC pág. 84 Origen Clave Cardinal Destino Clave Cardinal Ilustración 40: Cardinalidad de las relaciones entre tablas En cada una de las relaciones por defecto se aplican unas reglas automáticas para las operaciones de borrado y modificación de la clave compartida, tanto para la tabla origen como destino. Por defecto, las reglas son: 1. Prohibido borrar un registro si la clave relaciona las tablas origen y destino. 2. Prohibido modificar la clave si ésta relaciona las tablas origen y destino. El modelo de base de datos requiere la personalización de algunas relaciones entre tablas para obtener mayor estabilidad. • Tabla Clientes y Dirección: - Al borrar un cliente borra todas sus direcciones (Tabla Dirección) - Prohibido modificar el identificador del cliente si tiene al menos una dirección. • Tabla Dirección y Contacto: - Prohibido borrar una dirección que tenga al menos un contacto - Prohibido modificar el identificador de Dirección si al menos tiene un contacto. • Tabla Cliente y Contacto: - Al borrar un cliente borra todos sus contactos - Prohibido modificar Cliente_ID si al menos tiene un contacto. pág. 85 • Tabla Usuario y Cliente: - Al borrar un usuario, mantener todas sus incidencias - Prohibido modificar su Usuario_ID si al menos tiene una incidencia. • Tabla Usuario y SesionUsuario: - Prohibido borrar un usuario si al menos tiene una entrada en SesionUsuario - Modificar Usuario_ID en la tabla Usuario implicará que cambie igualmente en Sesión de Usuario. • Tabla incidencia y Comentario: - Al borrar una incidencia se eliminará todos los comentarios relacionados - Prohibido modificar la clave compartida. • Tabla Encuesta e Incidencia: - Al borrar una encuesta, no borrará el registro de incidencia. - Prohibido modificar la clave compartida. pág. 86 Diseño del Webservice Sistemas y subsistemas La llamada al webservice se realiza desde Linux mediante un script situado dentro del Dialplan de Asterisk durante el proceso de una llamada entrante. La llamada al webservice ejecuta el método que procesa la llamada. El método necesita los siguientes datos: • Cada llamada es un fichero de texto formato TXT, cuyo nombre contiene el número de teléfono origen, teléfono destino, fecha y hora exacta de la llamada. • Como salida depositará en formato XML v2.0 dentro del RSS estas llamadas y esto permitirá que quien se conecte a dicho RSS (por razón de seguridad y protección de datos) será en la intranet de Kernel Informática S.L, podrá leer en tiempo real las llamadas entrantes. Ilustración 41: Subsistemas del webservice pág. 87 Ilustración 42: Diagrama de flujo del método que procesa las llamadas en el webservice. pág. 88 Arquitectura de Base de Datos del webservice Diseño arquitectónico para trasferir las llamadas desde Asterisk A continuación se muestra un diagrama completo que indica el proceso de captura de la llamada desde el dialplan de Asterisk. Posteriormente, el nombre del fichero se pasa por parámetro al script Procesar_Registro.sh, quien se encarga de asegurar de conexión con el servidor WebDev. Si consigue conectar, transfiere el fichero de la llamada a la carpeta compartida y se llama al webservice para que obtenga los datos que necesita. Actualiza el RSS y finaliza. Ilustración 44: Captura de llamada mediante Asterisk y procesamiento del webservice. Ilustración 43: Base de datos del webservice pág. 89 Estudio de herramientas para el sistema SRIC Entorno de programación (Webdev 21) La herramienta web a utilizar es WebDev en su versión 21 de la plataforma PCSoft Es una herramienta orientada al desarrollo de aplicaciones web dinámicas. Adaptado para aplicaciones web con gestión de datos en tiempo real. W-Language es el lenguaje de programación que utiliza WebDev. Permite la programación por procedimientos y la programación orientada a objetos. WebDev se basa en HTML, HTML5, XML, CSS, JavaScript o PHP. Genera el código necesario automáticamente. Además, soporta de manera integrada AJAX 2.0. HyperFileSQL server HFSLQ (HyperFileSQL) es un potente SABR (Sistema de Administración de Base de datos Relacional). Existente en cuatro versiones: 1. Versión móvil (integrada) 2. Versión Cliente/Servidor 3. Versión local (independientemente o en red) 4. Versión para grupos (clúster) Para la realización de este proyecto se requerirá de la versión local ya los ficheros HFSQL se alojaran en el servidor proporcionado por Kernel Informática S.L. HFSQL está disponible para todos los tipos de aplicaciones: aplicaciones de negocios, aplicaciones críticas en tiempo real 24/7, software, servidores de aplicación, servidores web, PC independiente o dispositivos móviles. Ilustración 45: Servidor HFSQL pág. 96 El código es el siguiente: Formulario is ST_Alta_Cliente Formulario.Contacto_Alta.Cargo = Cargo_usuario IF Length(NoSpace(NIF))<8 THEN Info("El nif del contacto tiene que tener 8 números") RETURN ELSE Formulario.Contacto_Alta.Nif = NIF END IF NoSpace(Nombre)="" THEN Info("Tiene que poner el nombre del contacto") RETURN ELSE IF Length(NoSpace(Nombre))<3 THEN Info("El nombre del contacto es demasiado corto") RETURN END END Formulario.Contacto_Alta.Nombre = Nombre Formulario.Contacto_Alta.Primer_Apellido = Primer_Apellido Formulario.Contacto_Alta.Segundo_Apellido = Segundo_Apellido IF Length(NoSpace(Email_contacto))<3 THEN Info("El email del contacto tiene que ser correcto") RETURN ELSE Formulario.Contacto_Alta.Email_contacto = Email_contacto END Formulario.Direccion_Alta.Calle= edt_calle Formulario.Direccion_Alta.Pais = edt_pais Formulario.Direccion_Alta.Poblacion = edt_población Formulario.Direccion_Alta.Provincia = edt_provincia Formulario.Direccion_Alta.ZIP = edt_zip Formulario.Direccion_Alta.Edif_Num = direccion_EdifNum Formulario.Direccion_Alta.Email= direccion_email Formulario.Direccion_Alta.Telefono = Telefono_direccion Formulario.Direccion_Alta.Zona = direccion_zona Formulario.Direccion_Alta.Planta = direccion_planta Formulario.Direccion_Alta.Departamento = "" IF Length(NoSpace(CIF_Empresa))<3 THEN Info("El CIF de la empresa tiene que ser correcto") RETURN END Formulario.Empresa_Alta.CIF = CIF_Empresa IF Length(NoSpace(Nombre_Empresa))<3 THEN Info("El Nombre de la empresa tiene que ser correcto") RETURN END Formulario.Empresa_Alta.NombreCliente = Nombre_Empresa pág. 97 Formulario.Usuario_Alta.Email=Cell_Usuario.Email IF NoSpace(Cell_Usuario.Pass)=NoSpace(Cell_Usuario.Pass_repetido) THEN Formulario.Usuario_Alta.Pass=Cell_Usuario.Pass ELSE Info("La clave de usuario no coincide.") RETURN END //SEGURIDAD: //Si conocen la ruta de la página de registro podrán saltar la consulta //del botón de "registro" en el login. Volver a consultar. IF NOT gn_Controlador.Ctrl_Regla_Permitir_alta() THEN Info("Función deshabilitada temporalmente, disculpe las molestias") RETURN END IF gn_Controlador.SU_Nuevo_Cliente_Formulario(Formulario) THEN Info("En breve recibirá un email, Gracias.") Cell_Contacto.Cargo_usuario ="" Cell_Contacto.Email_contacto="" Cell_Contacto.NIF="" Cell_Contacto.Nombre="" Cell_Contacto.Primer_Apellido="" Cell_Contacto.Segundo_Apellido="" Cell_Contacto.Telefono_contacto="" Cell_Direccion.direccion_EdifNum="" Cell_Direccion.direccion_email="" Cell_Direccion.direccion_planta="" Cell_Direccion.direccion_zona="" Cell_Direccion.edt_calle="" Cell_Direccion.edt_pais="" Cell_Direccion.edt_población="" Cell_Direccion.edt_provincia="" Cell_Direccion.edt_zip="" Cell_Direccion.Telefono_direccion="" Cell_empresa.CIF_Empresa="" Cell_empresa.Nombre_Empresa="" Cell_Usuario.Email="" Cell_Usuario.Pass="" Cell_Usuario.Pass_repetido="" ELSE Info("No ha sido posible crear su cuenta, Por favor contacte con Kernel Informática."+CR+"Disculpe la molestias ocasionadas.") END Ilustración 50: Aviso pág. 98 Captura de incidencia telefónica. Se observa el formulario de captura de incidencias. Al seleccionar un cliente SRIC notifica visualmente en rojo que el cliente no tiene contrato de mantenimiento en vigor. El usuario de atención, puede acceder a la ficha del cliente y ver la descripción donde el administrador ha escrito la razón, para más información. De todos modos tiene que informar al gerente. En la parte superior central, SRIC informa visualmente con una campana, al usuario “Administrador” , en este ejemplo, que tiene un mensaje pendiente. Si hace “Click” sobre la campa accede directamente al sistema de conocimiento (Tab: Gestión->Conocimiento) donde muestra en color Cyan la incidencia nueva o ya existente pero con comentario o algún cambio nuevo. En la parte superior derecha, el pop-up fijo que muestra las llamadas en orden cronológico. Adjunta el nombre del cliente, Número de teléfono emisor y receptor y además información adicional, siendo “I_” el termino “Incidencias” la estadística calculada en el instante y debajo el texto que contiene en ese momento el campo descripción en la ficha del cliente. Todo esto se muestra en el primer o segundo tono, mientras la llamada suena : I_Abiertas:3 ; I_En_Resolucion:0 ; I_Pendiente_Proveedor:0 ===== Descripción Cliente ====== El cliente se ha registrado via web Ilustración 51: Formulario de captura de incidencias del sistema SRIC pág. 99 Código servidor del evento “Click” del botón “Crear”: IF YesNo(No,"¿ Desea crear la incidencia de tipo "+COMBO_Tipo_Incidencia..DisplayedValue+" ?") THEN Tab_Captura_Guardar_Incidencia() END Código del procedimiento servidor “Tab_Captura_Guardar_Incidencia”: PROCEDURE Tab_Captura_Guardar_Incidencia(captura_resuelta is boolean = False) Estructura_Incidencia is ST_Incidencia Estructura_Incidencia.Fecha_creacion = tab_Menu_Principal.tab_Captura_Atención.edt_fecha_captura Estructura_Incidencia.Hora_Creacion = tab_Menu_Principal.tab_Captura_Atención.edt_hora_captura Estructura_Incidencia.Fecha_cierre_Real = "" Estructura_Incidencia.Hora_Cierre_real = "" //Calculada la estimación al seleccionar el tipo y prioridad de la incidencia. Estructura_Incidencia.Fecha_MAX_Solucion = tab_Menu_Principal.tab_Captura_Atención.edt_fecha_estimada_max Estructura_Incidencia.Hora_MAX_Solucion = tab_Menu_Principal.tab_Captura_Atención.edt_hora_estimada_max Estructura_Incidencia.Fecha_MIN_Solucion = tab_Menu_Principal.tab_Captura_Atención.edt_fecha_estimada_min Estructura_Incidencia.Hora_MIN_Solucion = tab_Menu_Principal.tab_Captura_Atención.edt_hora_estimada_min //CALCULO AUTOMÁTICO DE FECHAS DE ESTIMACIÓN (Basado en reglas de negocio) //Fecha y horas estimadas para el técnico debug_str is string = gn_Controlador.Ctrl_Calculo_Fecha_estimada(tab_Menu_Principal.tab_Captura_Aten ción.edt_fecha_captura,tab_Menu_Principal.tab_Captura_Atención.edt_hora_captur a,tab_Menu_Principal.tab_Captura_Atención.COMBO_Tipo_Incidencia,tab_Menu_Princ ipal.tab_Captura_Atención.COMBO_Incidencia_prioridad,"MIN_RES") Estructura_Incidencia.Fecha_MIN_Resuelto=Left(debug_str,8) Estructura_Incidencia.Hora_MIN_Resuelto=Right(debug_str,4) debug_str = gn_Controlador.Ctrl_Calculo_Fecha_estimada(tab_Menu_Principal.tab_Captura_Aten ción.edt_fecha_captura,tab_Menu_Principal.tab_Captura_Atención.edt_hora_captur a,tab_Menu_Principal.tab_Captura_Atención.COMBO_Tipo_Incidencia,tab_Menu_Princ ipal.tab_Captura_Atención.COMBO_Incidencia_prioridad,"MAX_RES") Estructura_Incidencia.Fecha_MAX_Resuelto=Left(debug_str,8) Estructura_Incidencia.Hora_MAX_Resuelto=Right(debug_str,4) pág. 100 //El técnico tiene que indicar estos datos IF captura_resuelta THEN temp_datetime is DateTime= DateSys()+TimeSys() temp_date is Date temp_time is Time FOR i=1 TO Val(tab_Menu_Principal.tab_Captura_Atención.edt_tiempo_atencion) temp_datetime..Minute++ END temp_date..Year=temp_datetime..Year temp_date..Month=temp_datetime..Month temp_date..Day=temp_datetime..Day temp_time..Hour=temp_datetime..Hour temp_time..Minute=temp_datetime..Minute Estructura_Incidencia.Fecha_Resolucion_Real=DateToString(temp_date,"YYY YMMDD") Estructura_Incidencia.Hora_Resolucion_Real=TimeToString(temp_time,"HHM M") Estructura_Incidencia.Fecha_Solucion_Real= DateSys() Estructura_Incidencia.Hora_Solucion_Real=TimeSys() ELSE Estructura_Incidencia.Fecha_Resolucion_Real = "" Estructura_Incidencia.Hora_Resolucion_Real = "" Estructura_Incidencia.Fecha_Solucion_Real = "" Estructura_Incidencia.Hora_Solucion_Real = "" END Estructura_Incidencia.Agente_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_tecnicos Estructura_Incidencia.Aplicativo_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_Captura_Aplicativo Estructura_Incidencia.Asunto = tab_Menu_Principal.tab_Captura_Atención.edt_titulo Estructura_Incidencia.Cliente_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_Clientes Estructura_Incidencia.Contacto_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_Contactos Estructura_Incidencia.Creador_ID = ComboBox_Creador Estructura_Incidencia.Descripcion = tab_Menu_Principal.tab_Captura_Atención.edt_TextoIncidencia Estructura_Incidencia.Direccion_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_Direccion Estructura_Incidencia.Dispositivo_Elemento_ID = tab_Menu_Principal.tab_Captura_Atención.ComboBox_Dispositivo Estructura_Incidencia.Incidencia_ID = -1 Estructura_Incidencia.Minutos_atencion = tab_Menu_Principal.tab_Captura_Atención.edt_tiempo_atencion Estructura_Incidencia.Prioridad_ID = tab_Menu_Principal.tab_Captura_Atención.COMBO_Incidencia_prioridad Estructura_Incidencia.Tipo_Incidencia_ID = tab_Menu_Principal.tab_Captura_Atención.COMBO_Tipo_Incidencia IF captura_resuelta THEN pág. 101 IF HReadSeekFirst(Estado,Denominación,"Cerrada") THEN Incidencia.Estado_ID = Estado.Estado_ID ELSE gn_Depuracion.Log_Depuracion("Incoherencia - Error al asignar el estado a la incidencia") Incidencia.Estado_ID = -1 END ELSE IF HReadSeekFirst(Estado,Denominación,"Abierta") THEN Estructura_Incidencia.Estado_ID = Estado.Estado_ID ELSE gn_Depuracion.Log_Depuracion("Incocherencia -Error al asignar el estado a la incidencia") Estructura_Incidencia.Estado_ID = -1 END END //NOTAS: //1) Fecha y hora del último movimiento, se realiza posteriormente llamando al controlador con el id incidencia. //2) El campo aviso de incidencia se marcará true/false en Ctrl_Nueva_Incidencia IF gn_Controlador.Ctrl_Nueva_Incidencia(Estructura_Incidencia) THEN //Ha creado la incidencia con éxito, hay que marcar el último movimiento IF gn_Controlador.Ctrl_actualizar_fechahora_modificacion(Estructura_Incidencia.In cidencia_ID) THEN //Correcto,continúa. ELSE gn_Depuracion.Log_Depuracion("Error después de crear una incidencia no permite actualizar su último movimiento, Incidencia ID:"+Estructura_Incidencia.Incidencia_ID) END ELSE gn_Depuracion.Log_Depuracion("Error al crear el registro Incidencia para Incidencia ID:"+Estructura_Incidencia.Incidencia_ID) END IF Estructura_Incidencia.Incidencia_ID > 0 THEN Estructura_Estado_Incidencia is ST_Estado_Incidencia Estructura_Estado_Incidencia.IncidenciaID = Estructura_Incidencia.Incidencia_ID Estructura_Estado_Incidencia.EstadoID = Estructura_Incidencia.Estado_ID Estructura_Estado_Incidencia.Descripcion = "Creación de la incidencia ID: "+Estructura_Incidencia.Incidencia_ID pág. 102 IF gn_Controlador.Ctrl_Nuevo_Estado_Incidencia(Estructura_Estado_Incidencia) THEN ELSE gn_Depuracion.Log_Depuracion("Error al crear el registro Estado_Incidencia para Estado id:"+Estructura_Incidencia.Estado_ID+" , e Incidencia ID:"+Estructura_Estado_Incidencia.IncidenciaID) END END //Todo ha ido bien, reiniciar el formulario. tab_Menu_Principal.tab_Captura_Atención.edt_Busqueda="" ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.btn_busqueda,trtClick) tab_Menu_Principal.tab_Captura_Atención.ComboBox_Dispositivo=0 tab_Menu_Principal.tab_Captura_Atención.ComboBox_Captura_Aplicativo=0 tab_Menu_Principal.tab_Captura_Atención.COMBO_Tipo_Incidencia=1 tab_Menu_Principal.tab_Captura_Atención.COMBO_Incidencia_prioridad=1 ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.edt_fecha_captura,trtIn it) ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.edt_hora_captura,trtIni t) ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.COMBO_Tipo_Incidencia,t rtInit) //Inicializa la fecha y horas estimadas ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.COMBO_Incidencia_priori dad,trtInit) tab_Menu_Principal.tab_Captura_Atención.edt_titulo="" tab_Menu_Principal.tab_Captura_Atención.edt_TextoIncidencia="" Slider1..Value=1 edt_tiempo_atencion=1 tab_Menu_Principal.tab_Captura_Atención.edt_Busqueda="" ExecuteProcess(tab_Menu_Principal.tab_Captura_Atención.btn_busqueda,trtClick) pág. 103 Ilustración 52 – Sistema de conocimiento y vista de los comentarios de una incidencia. Ilustración 53: Ficha detallada de una incidencia, vista superior. pág. 104 Esta en la interface al indicar en la ficha de la incidencia el cambio de estado a “cerrado”. Se abre automáticamente mostrando los siguiente: Parte superior izquierda: Titulo de la incidencia Recuadro central: Redacción que acompañará al parte de trabajo. Lo verá el cliente. Parte inferior izquierda: Conocida la resolución se puede aportar información que ayude al sistema de conocimiento a identificar incidencias que ayuden en el futuro a técnicos que estén en incidencias con algún nexo común. Campo de Emails alternativos: Si hay que notificar puntualmente a alguien más, se insertan emails separados por “;” Previsualizar parte: Descarga el parte en PDF para revisarlo Notificar al Supervisor: Seleccionar un supervisor previamente. Envía al supervisor el parte para que lo apruebe y envíe al cliente. Enviar parte al cliente: Adjunta el parte técnico pdf en un email como destinatario el cliente. Ilustración 54: Vista del cierre de una incidencia. pág. 105 El código servidor del evento “click” del botón “Enviar parte al cliente”: Procesar_Parte_Email("Enviar_Cliente") Dicho procedimiento servidor contiene este fragmento importante: PROCEDURE Procesar_Parte_Email(Opcion is string ="Previsualizar") ….. …… CASE "Enviar_Cliente" Destinatarios is string =Registro_Incidencia.Email_Cliente Aviso is string="" IF Length(NoSpace(Text_emails_envio_reporte))>8 THEN //Hay correos adicionales Destinatarios = Destinatarios+";"+Text_emails_envio_reporte Aviso = "Incidencia en estado ' "+gn_Controlador.Ctrl_Nombre_Estado_IDIncidencia(IDIncidencia)+" ' "+… CR+"¿Esta seguro de querer enviar el parte de trabajo? "+CR+"Cliente: "+Registro_Incidencia.Nombre_Cliente+CR+"Direccion: "+Registro_Incidencia.Direccion_Cliente+CR+"Email: "+Registro_Incidencia.Email_Cliente+CR+CR+"Copias ocultas a las direcciones:"+Text_emails_envio_reporte ELSE //Sin destinatarios adicionales Aviso = "Incidencia en estado ' "+gn_Controlador.Ctrl_Nombre_Estado_IDIncidencia(IDIncidencia)+" ' "+CR+"¿Esta seguro de querer enviar el parte de trabajo? "+CR+"Cliente: "+Registro_Incidencia.Nombre_Cliente+CR+"Direccion: "+Registro_Incidencia.Direccion_Cliente+CR+"Email: "+Registro_Incidencia.Email_Cliente END IF NOT fFileExist(RutaPDF) THEN gn_Depuracion.Log_Depuracion("El parte de trabajo no se ha creado, no se puede enviar email al cliente '"+Registro_Incidencia.Nombre_Cliente+" , su ruta PDF es: "+RutaPDF+CR+CR+"Solucion: Revisar caracteres especiales en el nombre del cliente") Info("Error, el nombre del cliente contiene caracteres especiales,"+CR,"No puede crearse el fichero:"+RutaPDF) RETURN END IF YesNo(No,Aviso) THEN pág. 112 Pruebas unitarias y funcionales Todos los requisitos funcionales se han tenido presente en estas pruebas ([Ed97], 1997). Las pruebas empezaron por las clases contenidas dentro de la clase “Controlador”. Testeo de los objetos haciendo uso de las dos herramientas citadas anteriormente: • Objeto Vista: Todos los métodos pasan las pruebas correctamente. • Objeto Sesion_Usuario: Todos los métodos pasan las pruebas correctamente. Se repite el proceso, quedando sólo las clases declaradas en el inicio del proyecto: • Objeto Controlador: Todos los métodos pasan las pruebas correctamente. • Objeto Depurador: Todos los métodos pasan las pruebas correctamente. Pruebas de Integración Los objetos Vista y Sesion_Usuario que son parámetros dentro del objeto Controlador han sido correctamente integrados, ya que se ha realizado controles en todas las llamadas de sus métodos desde el controlador. Siguiendo la siguiente metodología: Ilustración 59: Diagrama de estado de una prueba de integración pág. 113 Pruebas de sistema Se ha realizado todo el proceso de detección, captura, gestión de incidencia, cierre de incidencia y posterior generación de informe de parte de trabajo y encuesta. En general no ha habido errores que destacar, la estabilidad es correcta y el rendimiento óptimo. Pruebas en Webservice + Virtualbox::Centos::AsteriskNow La realización del webservice ha sido en WebDev 21 por lo que tiene el mismo fundamento de depuración que SRIC. La llamada principal del webservice es sólo un método, el encargado de procesar las llamadas. Por lo tanto no hay clases ni métodos, sólo este procedimiento que se secciona en varios estados. Todos los estados y procesos que realiza han sido expuestos en la Ilustración 42. Pruebas unitarias y funcionales: Han sido totalmente satisfactorias al separar en varias funciones externas los subprocesos pesados. Como resultado se testearon cada uno de los métodos externos, con tareas específicas, por ejemplo: Actualizar_RSS(…) : El único propósito es actualizar el fichero RSS por lo tanto se puede realizar pruebas específicas. Todos los resultados fueron correctos. De igual modo con el resto de métodos externos. Pruebas de integración: Después de la correspondiente integración mediante carpeta compartida con Linux Centos, el cual corre la máquina Asterisk, la cual deposita las llamadas e invoca el método del webservice, encargado del procesamiento de llamadas. Todo el proceso ha sido exitoso ya que el resultado final es que las llamadas entrantes se muestren lo antes posible en el RSS, tras múltiples pruebas, todas han sido exitosas. Prueba de sistema: Realizando varias pruebas llamadas desde softphone al servidor Asterisk, captura y deposita las llamadas desde Linux al servidor Windows, posteriormente llama al método (procesamiento de llamadas) del webservice. Realiza el procesamiento de varias llamadas a la vez con éxito ya que el fichero de llamadas RSS se actualizó exitosamente y muy rápidamente. Destaca la prueba de rendimiento, donde el webservice tenía que procesar en una sola llamada a su método de procesamiento 500 ficheros de llamadas. Procesó y actualizó el fichero RSS en 5 segundos. Simulando llamadas que permanecieron offline en Linux por no tener conexión con la carpeta compartida con el servidor Windows. pág. 114 Implantación En esta fase de desarrollo software se pretende comprobar el correcto funcionamiento de los aplicativos desarrollados dentro de un entorno real de operación. Durante el proceso de implantación se necesita preparar y configurar toda la infraestructura necesaria para configurar el entorno, la instalación de componentes, la activación de los procedimientos manuales y automáticos asociados y cuando proceda la migración de datos o carga inicial. Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad. Con los siguientes propósitos: - Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de cualquier detalle de diseño hasta aspectos tales como las comunicaciones. Se debe comprobar que el sistema puede gestionar en su conjunto los volúmenes de información requeridos. - Las pruebas de aceptación se realizan por y para los usuarios. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades. Las pruebas de implantación y aceptación del sistema deben ejecutarse en el entorno real de operación. El propósito es comprobar que el sistema satisface todos los requisitos especificados por el usuario en las mismas condiciones que cuando se inicie la producción. La implantación del sistema inicial de cara al usuario ayudará en el proceso de refinamiento. Si fuera necesario, se creará algún caso de prueba adicional que se considere importante y que no se haya tenido en cuenta hasta entonces. Se preparan las condiciones que permitan simular las situaciones límite previstas para las pruebas. El objetivo de estas pruebas es asegurar que el sistema se comporta de la forma prevista en el entorno de operación, y que responde a todas las especificaciones dadas en cuanto al cumplimiento de los objetivos, tiempos de respuestas, seguridad, comunicaciones, etc. pág. 115 Instalación, configuración y carga inicial Previamente, antes de generar los instalables del Webservice y de SRIC (Seguimiento y Registro de Incidencia de Clientes), hay que ejecutar, en los controles del entorno WebDev, los comandos de sincronización y refresco del proyecto. Con esto se pretende asegurar que se compila la última versión de los dos aplicativos. Posteriormente hay que indicar durante la instalación en el servidor, las rutas donde ambos se van a alojar: Intervienen los instalables de SRIC y Webservice (Procesador de llamadas): 1. Rutas de instalación (Indicado durante la instalación) SRIC: pathWeb: c:\PFCWeb\SRIC\ pathData: c:\PFCWeb\SRIC\data Webservice: pathWeb: c:\PFCWeb\SRIC\ pathData: c:\PFCWeb\SRIC\data //Parámetro adicional PathLlamadas: C:\PFCWeb\SRIC\Llamadas_Asterisk 2. No hay más configuración a destacar, salvo avanzar e instalar primero SRIC y después el Webservice. Ambos aplicativos se instalarán en las siguientes rutas: C:\PFCWeb\SRIC\SRIC_WEB C:\PFCWeb\SRIC\WS Se ha indicado la siguiente ruta para situar los ficheros de bases de datos. Ambos aplicativos compartirán sus ficheros. C:\PFCWeb\SRIC\data Hay que asegurar que en la configuración del fichero HTTPD.CONF de WAMP (Servidor Apache) se defina correctamente una ruta raíz en “C:\PFCWeb\SRIC”, de tal modo que permita al webservice y a SRIC acceder a la carpeta donde alojan sus ficheros de base de datos. No ha habido que realizar cambios, es correcta. pág. 116 3. Las rutas de lectura de los INI son las siguientes: a. Ruta para SRIC: i. C:\PFCWeb\SRIC\SRIC_WEB\SRICConfig.ini b. Ruta para Webservice i. C:\PFCWeb\WS_PROCESARLLAMADAS_WEB\WSConfig.ini Distribución de los directorios (después de la instalación) El directorio raíz “C:\PFCWeb\SRIC” contiene: • La carpeta “data”: o Los ficheros de bases de datos de SRIC y webservice, están compartidos. • La carpeta “Llamadas_Asterisk”: o Como indica su nombre, será la carpeta compartida en red con Linux. En ella se depositarán los ficheros de las llamadas. En encargado de transferir dichos ficheros es el sistema Linux mediante unos scripts que se encargarán de establecer la comunicación y de transferir los ficheros con los datos de las llamadas. El webservice leerá las llamadas desde esta carpeta. • Finalmente, las dos carpetas restantes son los aplicativos: o “SRIC_WEB”: Carpeta creada durante la instalación. Contiene los ficheros y carpetas del proyecto. o “WS_PROCESADORLLAMADAS_WEB”: Carpeta creada durante la instalación. Contiene los ficheros html y ejecutables del webservice. Comprobación de Base Datos Verificación de los datos alojados en los tablas, evitar que tengan información de posibles testeos durante la fase de implementación, o bien, pruebas. i. Tablas de Registro_llamadas y Cliente_Dirección correspondientes al webservice ii. Comprobación del modelo de análisis de SRIC. Limpieza de registros de las tablas de datos. Las tablas de configuración deben estar correctas. Se pretende que se genere un modelo base donde poder comenzar utilizar el aplicativo SRIC desde cero. • Nota importante: o Además, se crea manualmente la carpeta “data_init”, el cual contiene los ficheros de base de datos inicializados para su primer uso, tanto para el webservice como para el SRIC. pág. 117 Inicialización de carpetas y ficheros Con el fin de facilitar el arranque del sistema inicial, se crea manualmente una carpeta llamada “Restauración”. Contendrá las siguientes carpetas con todos los ficheros de base de datos y de configuración necesarios para su primer uso: Llamadas_asterisk: Internamente tiene 3 carpetas, que son: carpeta “scripts”, contiene los scripts necesarios en el sistema Linux, la carpeta “XML” para la generación y actualización del fichero RSS (XML) y finalmente la carpeta “Prueba-cliente-Dir_1_2_3” con 3 llamadas reales de ejemplo, para realizar una comprobación inicial de que el webservice trabaja correctamente. En el interior de la carpeta “scripts” contiene los ficheros con extensión *.sh, que son ejecutados en Linux, en el momento que Asterisk ejecute su dialplan durante una llamada entrante. Uno de los scripts se encargará de llamar al webservice para procesar las llamadas y actualizar el RSS. La carpeta “XML” es donde se almacena: Fichero “XML_RSS.xml”: Cuando el webservice ha terminado de procesar los ficheros de las llamadas. Actualiza el fichero RSS con toda la información. Finalmente mueve los ficheros procesados a la carpeta de Backup de forma organizada. Backup de las llamadas: Internamente se crea otra carpeta, llamada “Backup”. En ella se clasifica por año, mes y día, todas las llamadas del día. Estas se almacenan de forma automática cada jornada de trabajo. Al igual que el fichero RSS, se hace una copia de seguridad y se crea uno nuevo cada día. INI_Init: Siguiendo los pasos anteriores, esta carpeta contiene los dos INI con la configuración por defecto, listo para usarse. Si la ruta por defecto es cambiada, entonces hay que editar estos dos ficheros y colocar las nuevas rutas. RSS_Init: Contiene el RSS limpio. Data_Init: Contiene todos los ficheros de base de datos limpios, tanto del webservice como de SRIC. pág. 118 A continuación se especifica el procedimiento para la inicialización del sistema: 1. Copiar la carpeta “Llamadas_asterisk” en la ruta “C:\PFCWeb\SRIC”. 2. Dentro de la carpeta INI_init: a. Copiar SRIConfig.ini y pegar en “C:\PFCWeb\SRIC\SRIC_WEB”. b. Copiar WSConfig.ini y pegar en “C:\PFCWeb\SRIC\WS_PROCESADOR_LLAMADAS_WEB”. 3. Copiar el contenido de la carpeta “Data_Init” y pegar en “C:\PFCWeb\SRIC\data” Finalmente, el directorio raíz “C:\PFCWeb\SRIC” contiene 5 carpetas que son: “data”, “Llamadas_Asterisk”, “Restauración”, “SRIC_WEB” y “WS_PROCESARLLAMADAS_WEB”. Verificar la comunicación entre SRIC y el Webservice Comprobación del webservice El webservice ha sido instalado y hay que comprobar que dentro de la carpeta “C:\PFCWeb\SRIC\Llamadas_Asterisk\XML” no exista la carpeta “BACKUP”, ya que guarda una copia de seguridad todas las llamadas. Si existe, hay que renombrarla, o bien, borrarla. Al igual que el fichero “XML_RSS.xml”, o sea, no tiene quedar nada dentro de la carpeta “XML.”. Lo siguiente es copiar las 3 llamadas *.txt de prueba situadas en “C:\PFCWeb\SRIC\Llamadas_Asterisk\Prueba-cliente-Dir_1_2_3”, y pegarlas en “C:\PFCWeb\SRIC\Llamadas_Asterisk”. Finalmente, acceder al navegador y colocar la siguiente dirección: http://“IP del servidor”/WS_PROCESARLLAMADAS_WEB/awws/index.htm Pulsamos en la opción “Estado_Escucha” y luego en “test”. Tiene que obtener el mensaje “El RSS ha sido actualizado”. pág. 119 Si es así, el webservice trabaja correctamente. La vista del fichero “XML_RSS.xml” contendrá las 3 llamadas de prueba, indicando “número desconocido” porque no hay clientes en la base de datos. Simula la llamada de los número ficticios “1111”,”2222” y “3333” a la extensión 3008. Comprobación de SRIC Después de su instalación, se acceder mediante el navegador a la siguiente dirección: http:// “IP del servidor”/SRIC/ Aparece el portal web de login. Con lo cual significa que es correcto. pág. 120 Instalación y configuración de las máquinas virtuales en Virtualbox Configuración virtualbox Se pretende instalar dos centralitas Asterisk en la máquina Virtualbox. La razón de que haya dos centralitas es para realizar hacer pruebas entre ellas posteriormente. Cada centralita está instalada en Linux Centos. Desde la web oficinal de AsteriskNOW es posible descargar la imagen ISO de Linux con el servidor Asterisk y el framework FreePBX, ya instalados. Por lo tanto, únicamente hay que configurar virtualbox de la siguiente manera: Paso 1) Crear una nueva máquina virtual Paso 2) Tipo: Linux debían 32 bits (ha sido compatible y estable) Paso 3) Configurar opciones en Virtualbox para ambas máquinas. • Sistema o Placa base:  RAM: 512MB  Orden de Arranque: Disco Duro, CD  Chipset PIIX3  Características extendidas: Habilitar I/O APIC + Reloj hardware en tiempo UTC. o Procesador:  Procesadores: 2  Limite ejecución: 100%  Habilitar PAE/NX o Aceleración  Habilitar VT-x/AMD-V  Habilitar paginación anidada o Audio  Deshabilitar audio o Red  Adaptador 1 • Conectado a: “Adaptador puente”: o Seleccionar tarjeta de red física del servidor o USB  Deshabilitar controlador USB pág. 121 Instalación de Centos 6.5 (AsteriskNOW) en Virtualbox Una vez descargada la imagen de la web oficinal de AsteriskNOW se procede a la instalación en la máquina virtual. Hay que acceder a la configuración de Virtualbox, opción de almacenamiento e insertar una nueva unidad IDE. En la cual hay que seleccionar la imagen ISO. Cuando se inicia la máquina virtual por primera vez, ejecutará el arranque desde CD y mostrando la pantalla de instalación de la distribución Centos. Durante la instalación se define el usuario root y su contraseña del sistema Linux, necesarias para acceder al terminal una vez se haya reiniciado y en posteriores inicios del operativo. La imagen corresponde a una máquina virtual con AsteriskNOW ya instalado. Una vez inicia el login del sistema Linux mostrará la dirección IP del interface de red “eth0”. En el primer arranque, la red no está configurada, se explicará en el siguiente apartado. En esta captura se observa la máquina virtualbox ejecutando una de las dos máquinas virtuales que aparecen a la izquierda, que son: “Movistar_Fusion” y “Oficina”. En este caso se ejecuta “Oficina”. Como se observa es un Linux Centos 6.5 (Release) corriendo FreePBX Asterisk (AsteriskNow es una distribución Linux Centos que contiene Asterisk y FreePBX). Ilustración 60: Máquina Virtualbox ejecutando AsteriskNOW en Linux pág. 128 A continuación muestra un formulario donde hay que completar los siguientes campos: 1. User Extension: Número de teléfono asociado. 2. Display Name: Nombre con el que se identifica el dispositivo. Cuando el destino vea su llamada, aparecerá su nombre en la pantalla. 3. Device options: a. Secret: Clave de acceso al terminal. b. NAT Mode: Yes (force_rport) c. Context: El nombre del context es importante a la hora de personalizar, por defecto se indica “from-internal” d. Port: 5060, dicho Puerto tiene que estar abierto tanto para udp como tcp en el router. Por defecto el resto de campos del formulario, son válidos para realizar la prueba de conexión entre dos terminales SIP. Como desviar la llamada entrante (vía Trunk-sip) a la extensión de “Recepción” en la centralita “Kernel Informática SL”(3008) Hay que acceder a la opción del menú “Conectivity””Inbound Routes”. A la derecha seleccionar Route: “General”. Al final del formulario en donde indica “set Destination”. Seleccionar la opción “Extensions”, se habilita un combo donde se puede seleccionar el terminal “3008 - Recepción”. Una vez seleccionado, pulsar Submit. pág. 129 Conectar dos centralitas Asterisk vía SIP Trunk->Extensión SIP La centralita de Kernel informática (Servidor 1) tendrá configurada una línea Trunk SIP con los datos de la extensión creada en la centralita Movistar (Servidor 2). Concretamente la extensión SIP correspondiente a la cuenta “928998877” (Ilustración 62). Creación de una línea SIP Trunk En el portal de la centralita de Kernel Informática S.L. Acceder a la opción del menú “Conectivity””Trunks”, tal como indica la siguiente captura: Posteriormente, pulsar en: Add SIP (chan_sip) Trunk Indicar los siguientes parámetros: 4. General Settings  Trunk Name = “Conexión a la Centralita Movistar” Borrar PEER Detail USER Detail 5. Outgoing Settings: a. Trunk Name = 928998877-out b. PEER Details = “sin datos” 6. Incoming Settings: a. User Context = 92878998877 b. USER Details = “sin datos” 7. Registration (Ristra de conexión a la cuenta sip del servidor 2)(Ilustración 62) a. Register String: 928998877:[email protected]/928998877 i. El formato es el siguiente: 1. Extension:Clave@IP_Movistar/Extension Finalmente pulsar en Submit para aplicar los cambios. Ilustración 65: Configuración mediante FreePBX de una línea Sip-Trunk pág. 130 Configuración de los terminales (softphone) Como se puede ver en la Ilustración 62 , el cliente utilizará un Smartphone con softphone y el empleado de Kernel Informática un softphone instalado en un PC. En el caso del softphone de PC, se utilizará el aplicativo X-Lite para Windows. El softphone de Smartphone, será en Android mediante la aplicación softphone Zoiper, obtenido vía google play. Ambas son versiones gratuitas. Parámetros a configurar en ambos terminales: 1. Nombre Identificación de la cuenta SIP. 2. Dominio: IP de la centralita. 3. Usuario SIP definido en la extensión. 4. Contraseña asociada al usuario SIP. 5. Display name: Identifica su extensión con un nombre. Configuración X-Lite (Windows) como softphone de Kernel Informática S.L a. Dominio: Se conectará a la IP Centralita Kernel Informática b. Usuario: “3008” c. Contraseña: “teléfono_del_recepcionista_Kernel_Informatica” Ilustración 66 Configuración del Softphone X-Lite en Windows pág. 131 Configuración Zoiper (Android), como softphone del cliente “Farmacia Extremadura” a. Dominio: se conectará a la IP Centralita Movistar b. Usuario: “927 11 22 33” c. Contraseña: “Cliente_Farmacia_Extremadura” A continuación, se muestra las capturas de pantalla del aplicativo Zoiper, donde se puede observar que la cuenta SIP ha quedad activada en el Smartphone: Se observa que después de introducir los datos, la extensión 3008 y el cliente “Farmacia Extremadura” se conectaron satisfactoriamente, cada uno a la IP de su centralita, como indica la Ilustración 62. pág. 132 Llamada entre centralitas. En este punto ya se ha configurado y conectado las dos centralitas. Además de sus teléfonos IP correspondientes. Con esta prueba se demostrará que los dos servidores PBX Asterisk mediante protocolo SIP pueden conectarse mutuamente. Habiendo utilizado el protocolo SIP-Trunk del servidor 1 (Ilustración 62) configurado con el usuario y contraseña de una extensión telefónica en el servidor 2. Como si se tratase de un teléfono ip más. Una vez seguido todos los pasos indicados, se ha finalizado de configurar. De modo que se procede a hacer una prueba sencilla. Llamar desde el terminal de un cliente (por ejemplo, “Cliente-Farmacia Extremadura”) a la “recepción” de la oficina de Kernel Informática S.L. Se efectúa la llamada desde el la Farmacia Extremadura (927112233) a Kernel Informática S.L (928998877). Siendo la prueba satisfactoria. Los dos teléfonos dan tono y al descolgar la comunicación es correcta. Se puede hablar bidireccionalmente y el sonido es de buena calidad. No ha surgido ningún problema. Por lo que se cuelga y finaliza la prueba. Personalización de Asterisk Continuando con la verificación del sistema, se pasa a la siguiente etapa de la implantación. Demostrar en un entorno real de operación que la personalización del dialplan ([Dialplan], 2013) de Asterisk, obtiene los datos de cada llamada entrante correctamente. El objetivo es capturar quien llama y transferir la información al webservice. Por lo tanto se procede a explicar la personalización del servidor Asterisk: Captura de llamada – personalización del Dialplan Para la captura de las llamadas hay que realizar un desvío en el flujo de ejecución del Dialplan que tiene por defecto el servidor Asterisk. Para empezar, explicar los dos ficheros relevantes de Asterisk, que son: Sip.conf: Es el encargado de configurar todo lo relacionado con el protocolo SIP y añadir nuevos usuarios o conectar con proveedores SIP (Conexiones Sip-Trunk). En la Ilustración 65 hemos definido los parámetros necesarios para las pruebas, mediante el framework FreePBX de Asterisk. Extensions.conf: Define el comportamiento que va a tener una llamada en nuestra centralita, las reglas que siguen en su enrutamiento. Es por ello, que será necesario alterar el flujo principal de ejecución de reglas o Dialplan para insertar unas subrutinas que permitan la captura de las llamadas entrantes. pág. 133 La personalización no es posible directamente sobre extensions.conf, debido a que todos los ficheros importantes son controlados por el framework FreePBX, y toda personalización que se realice será sobrescrita de forma automática. La arquitectura de Asterisk contiene los ficheros de personalizaciones preparados y definidos, pero sin configuración alguna (comentados y vacíos). Por lo tanto se procede a explicar cómo realizar la personalización del flujo de entrada de una llamada. Análisis y configuración del fichero Extensions.conf La primera cabecera del Dialplan tiene que ver con PSTN y como desvía la llamada a otras cabeceras para su procesamiento. La red telefónica pública conmutada (PSTN, Public Switched Telephone Network) es una red con conmutación de circuitos tradicional optimizada para comunicaciones de voz en tiempo real. Cuando llama a alguien, cierra un conmutador al marcar y establece así un circuito con el receptor de la llamada. Cuando hay una llamada entrante, esta bifurca según su procedencia: Dialplan Externo: Si la llamada proviene del exterior, o sea, que proveniente de una red externa. En este caso la llamada es captada por medio de su conexión Sip-Trunk, que estará configurada y conectada a su proveedor de telefonía. Dialplan Interno: La llamada es interna a la red de la centralita, o sea, es una llamada de una extensión a otra extensión de la misma centralita telefónica. pág. 134 Se ha creado un esquema que muestre los dos flujos de entrada a la centralita y como se realiza la personalización, de tal modo que en fichero Extensions_custom.conf se ejecuten las órdenes personalizadas a partir del punto 3: En el paso 4, se ejecutarán las órdenes para obtener los sientes valores: 1. Día, mes y año de la llamada. 2. Hora, minutos y segundos de la llamada. 3. Identificador numérico de llamada entrante. 4. Identificador numérico de la extensión que tiene como destino. Ilustración 67 Dialplan personalizado para capturar la llamada pág. 135 Comandos para capturar la llamada a partir del punto 4. Para la extracción de información de la llamada, dentro del Dialplan, se ha creado el script “Procesar_Registro.sh”. (Ilustración 44) El propósito de este script es el siguiente: 1. Desde Linux se establece comunicación con el servidor Windows donde se aloja el webservice, conectando con carpeta compartida de red donde lee el webservice. 2. Generar un fichero vacío con toda la información estructurada en el nombre del fichero: “AAMMDD_HHMM_Tlfn1_to_Tlfn2.txt“. “Tlfn1” es quien llama y “Tlfn2” es quien recibe la llamada. 3. Será el responsable de mantener una copia de seguridad de todas las capturas, tanto si tiene conexión con el servidor (Backup Online) como si no tiene (Backup Offline). 1) Backup Offline: i. Encargado de mantener guardado todos los ficheros de las llamadas, hasta que se reestablezca la comunicación con la carpeta compartida en el servidor Webdev. En ese momento, volcará todas las llamadas almacenadas, incluida la llamada actual, para que el webservice las registre en base de datos y lo procese ordenadamente. 2) Backup Online: i. Hay comunicación con el servidor Webdev. El script deposita en la carpeta compartida de llamadas (“Llamadas_asterisk”), que se ubica en el servidor Webdev, todos los ficheros del Backup Offline, si hubiera. Además de la llamada actual. Finalmente, ejecuta la llamada al webservice para que lo procese y actualice el fichero RSS de llamadas y su base de datos compartida. pág. 136 “Procesar_Registro.sh” contiene un algoritmo que hace uso de otros scripts que realizan tareas más sencillas, son los siguientes: 1) startwin.sh: Encargado de montar la carpeta de red llamada “WinLlamadas”. Necesita previamente tener configurado la carpeta “Llamadas_asterisk” en el servidor Webdev, con los permisos necesarios para montar la carpeta mediante credencial (usuario y contraseña). Surge un problema importante, al montar la carpeta de red sobre una carpeta ya existente en Linux. El problema surge una vez se ejecuta el comando “mount”, no hay manera de saber si tuvo o no éxito. Después de varias ideas, ha surgido una solución viable. Para comprobar si ha montado la unidad correctamente se recurre a un método muy simple. Consiste en colocar un fichero llamado “Baliza_linux.lnx” (creado manualmente) en la carpeta compartida del servidor Webdev, de tal modo, que al ejecutar “startwin.sh”, consulte si dicho fichero existe, si es así, ha montado la unidad con éxito. Tras muchas pruebas la solución es robusta y no ha fallado. Surge la necesidad de configurar los permisos de la carpeta de red en el servidor Windows donde se aloja el webservice. Los permisos son los siguientes, una vez se accede a las propiedades de la carpeta: • Agregar los nombres: “Administradores” y ”Todos” • Nivel de permiso: Lectura y escritura • Uso compartido avanzado – Permisos: o Usuario”Todos”: “Control total(Cambiar,Leer)” • Nota: Con esta configuración, al acceder por red a la carpeta compartida, solicitará el usuario y la contraseña, o sea, la acreditación. El script “startwin.sh” conoce el usuario y la contraseña. 2) wget.sh: Su propósito es ejecutar el comando “wget” cuyo parámetro es la ruta del servidor Webdev donde invoca el método “Estado_Escucha” del webservice que procesa la llamada y actualiza el fichero RSS. Es el último comando que se ejecuta en Procesar_Registro.sh. pág. 137 Para facilitar la tarea de conocer la dirección del servidor. Si no es una IP fija, existe la posibilidad de configurar un servidor de nombres de red, ya contenido en Linux, llamado WINS (Windows Internet Naming Service). Este servidor ([WINS]) mapea los nombres de las máquinas a direcciones. Se ha decido configurar esta opción por comodidad. No hay que instalar, ya lo tiene instalado. Inicialmente al hacer ping “Nombre_máquina”se obtiene: unknow host “Nombre_máquina” A continuación se edita “/etc/nsswitch.conf” y se añade “wins” en la siguiente línea: hosts: files wins dns A partir de ahora al hacer ping al nombre de una máquina responderá con su IP y latencia, por ello el script “wget” puede ahora usar la ruta “//Nombre_servidor/…” como parámetro. Prueba de captura de llamada (solo script – sin dialplan) La prueba consiste en ejecutar el script “Procesar_Registro.sh” que se lanzará desde el Dialplan de Asterisk en el momento que entre una llamada. Para capturar los mensajes que emite el script, a modo de depuración, se ha volcado la salida de la siguiente manera: Como se puede observar, ha detectado que la unidad de red ya estaba montada y ha procedido a copiar las llamadas offline y la llamada actual sobre el servidor Windows. Donde se encuentra el webservice. Finalmente, llama al método del webservice para procesar las llamadas. Sudo sh Procesar_Registros.sh> Salida.txt, obteniendo lo siguiente: La carpeta de red está montada. Iniciando copia Online. Transferir las llamadas offline al server + Llamada actual. Llamada al webservice.. Finalizado. pág. 144 Este fichero de configuración define el orden de búsqueda en la resolución de los nombres de red. Es necesario introducir el parámetro “wins”, que es un servidor de nombres de Microsoft para NetBIOS que mantiene una tabla de correspondencia entre el nombre de las máquinas y su dirección IP. En definitiva, no hace falta conocer la dirección IP del servidor WebDev, únicamente el nombre de la máquina. Por ejemplo, si hay que llamar desde Linux al webservice que está en el Servidor_Uno, antes había que escribir lo siguiente: “wget \\192.168.0.103\Webservice” Ahora se realiza de la siguiente manera: “wget \\Servidor_Uno\webservice “ Error de acceso a la carpeta de red Inicialmente se configuró el sistema para que el webservice accediera a leer las llamadas que se encontraban en una carpeta de red (realizado con un servidor Samba) en Linux. Asterisk depositaba las llamadas en esta carpeta. El webservice nunca podía acceder a la carpeta de red para leer los ficheros. La ruta venía dada por \\IP_servidor\Carpeta_Samba . Sin embargo la carpeta existía y se podía acceder a ella remotamente sin ningún problema de permisos o credenciales. Solución: Se detectó el problema, provenía del servidor Apache (WAMP). El fichero de configuración “httpd.conf” define las rutas visibles, donde se puede acceder y sus atributos. Por definición, en apache no se puede indicar como carpeta accesible a una dirección UNC (define una sintaxis común para especificar la localización de un recurso de red), por ejemplo, \\dirección_IP es una ruta UNC, carece letra de unidad. Por esta razón no era accesible y esta fue la razón por el cual se descartó la solución median Samba desde Linux y se apostó por una carpeta compartida en el servidor WebDev con Windows 7. Desde Linux (dentro de virtualbox) a través del script “startWin.sh”, monta la carpeta de red en una carpeta local dentro del propio sistema Linux, siendo muy práctico y sencillo de utilizar a la hora de volcar los ficheros de las llamadas generados desde Asterisk, que se ejecuta en el mismo sistema Linux. Esta decisión sirvió de inspiración para invocar posteriormente el webservice desde el sistema Linux y sólo cuando hay una llamada entrante. Evitando de este modo la llamada activa cada cierto intervalo de tiempo que se había planificado en un principio. pág. 145 Error UUID al hacer una copia de una máquina Virtualbox Durante las pruebas de implantación se ha copiado el fichero virtualbox que representa al disco duro que contiene el sistema Linux CentOS, Asterisk y FreePBX. El problema es que el software Virtualbox detecta que es una copia por medio de su UUID y no permite utilizarla en una nueva máquina virtual. Muestra un mensaje de error indicando que el identificador del disco duro ya pertenece a otra máquina. Solución: Es necesario acceder a la consola de Windows y ejecutar el comando que aparece en la siguiente ilustración. Acto seguido al crear la nueva máquina virtual no hay mensaje de error. Ilustración 71: Cambio de UUID del disco duro virtual. pág. 146 Análisis de costos A continuación se confecciona el desglose de costes de este proyecto para la venta directa al cliente. 1. Autor: • Francisco Javier Montero Vega 2. Departamento: • Ingeniería del software 3. Descripción • Título: Análisis y Diseño de un sistema software para el registro y seguimiento de las incidencias de los clientes 4. Presupuesto total del proyecto • 38620 euros. 5. Costes laborales Duración del proyecto: 12 meses Coste por hora trabajada: 23 euros/hora Horas de trabajo del proyecto: 950 horas Coste total= 950horas x 23 euros/hora = 21850 euros 6. Costes materiales Costes materiales necesarios para la ejecución del proyecto: Precio del Portatil HP pavilion g6 + mantenimiento = 2000 euros Teléfono Samsung S4 GT-I9505 = 300 euros Disco duro externo Seagate 1tb = 85 euros Licencia de Windows = Incluida en portátil Vida útil del portatil = 4 años = 48 meses Vida útil del teléfono = 2 años = 24 meses Vida útil del disco duro = 1 años = 12 meses Cálculos de amortización: Coste del portátil: 2.000 euros * 0,25 uso * 12 meses proyecto / 48 meses = 83,33 euros Coste del teléfono: 300 euros * 0,10 uso * 12 meses proyecto / 24 meses = 15 euros Coste del disco duro: 85 euros * 0,50 uso * 12 meses proyecto / 12 meses = 42,50 euros Coste total = 83,33euros + 15euros + 42,50euros = 140,83 euros pág. 147 7. Gastos de viajes y dietas Gastos de transporte: Número de visitas acordadas: 7 Distancia al cliente: 60 km Precio medio de combustible: 0,93euros/litro Consumo: 7 litros cada 100km 7 visitas * 60km = 420km totales Coste: 420km * 7 litros /100km * 0,93 euros/litro = 27,34 euros Gastos de dietas: Presupuesto: 50 euros Coste total = 27,34euros + 50euros = 77,34 euros 8. Material fungible Coste medio de papeles: 3 euros/mes Coste medio de tinta de impresora: 15 euros/mes Coste de papeles = 3 euros/mes * 12 meses = 36 euros Costes de tinta de impresora= 10 euros/mes*12meses = 120 euros Coste total = 156 euros 9. Gastos de documentación Coste por fotocopia: 0,035 euros Número de páginas aproximado: 160 Encuadernación: 6 euros Número de ejemplares: 5 Coste por ejemplar = 160 página * 0,035 euro/página * 6 euros= 33,60 euros Coste total = 33,60 euros * 5 ejemplares = 168 euros 10. Costes indirectos Tasa de costes indirectos: 10% 11. Beneficio empresarial Porcentaje de beneficio de la empresa: 50% sobre los costes del proyecto pág. 148 Tabla de Costes totales: Presupuesto Coste Totales Costes laborables 21850 euros Costes materiales 140,83 euros Gastos de viajes y dietas 73,44 euros Material fungible 156 euros Gastos de documentación 168 euros Costes indirectos 15% Beneficio empresarial 50% Total: 38620 euros pág. 149 Conclusiones y trabajos futuros Conclusiones El producto obtenido cumple con todos los objetivos propuesto en la definición del proyecto. Su administración y gestión de incidencias también cumplen con las funcionalidades mínimas necesarias que se requieren en este tipo de aplicativos. Añadiendo características interesantes, como por ejemplo, el sistema de conocimiento con búsquedas avanzadas, el cálculo automático de fechas estimadas en función de reglas temporales y dentro del calendario laboral personalizado, las notificaciones visuales ante caducidad de fechas desde el sistema de conocimiento, o bien, la capacidad de informar en tiempo real de una llamada entrante, con más información que el simple nombre del cliente. El trabajo realizado ha abordado un problema real de la empresa Kernel Informática S.L y se ha afrontado desde cero, con muchas incógnitas por delante que se han ido disipando a medida que se obtenían los requerimientos mediante técnicas de observación, comunicación con los empleados de Kernel informática S.L, documentación y entrevistas. Todo en base a las técnicas vistas en ingeniería del software para la obtención de requerimientos. Durante cuatro años trabajé en Kernel Informática S.L. Concretamente en atención técnica al cliente de la sección de robótica farmacéutica y he vivido de primera mano la captura, seguimiento y resolución de las incidencias. Entiendo la gran importancia de cumplir con los tiempos de respuesta de solución y resolución, la necesidad de comunicarse con el resto de compañeros, redactar soluciones que ayuden en incidencias futuras y organizar el conocimiento. Toda esta experiencia personal me ha servido de inspiración a la hora de afrontar cualquier duda durante el desarrollo de este proyecto. El proyecto ha seguido la planificación inicial para el desarrollo de un sistema de registro y seguimiento de incidencias pero vista la complejidad de todo el estudio e implantación del servidor Asterisk y del webservice, han hecho que el proyecto haya alcanzado una magnitud mucho mayor. Destaco que no ha sido sencillo abordar un problema que inicialmente no aparentaba complejidad pero que a medida que se intentaba avanzar se iba complicando. En este sentido hago especial hincapié al problema de la centralita telefónica virtual Movistar, donde ha sido necesario un gran esfuerzo de investigación y búsqueda, ya que a pesar de que abunda la información de centralitas telefónicas virtuales, apenas hay información para capturar el número de teléfono de una llamada entrante mientras suena. Fue el hecho de probar varios caminos diferentes el que produjo el logro de configurar la centralita telefónica software Asterisk. pág. 150 El aprendizaje de Asterisk fue muy duro ya que había que personalizar sus ficheros de configuración. Por lo tanto había que aprender cómo se programaba. Vuelvo a recalcar que hay mucha documentación pero muy poco que explique cómo bifurcar llamadas o ideas de cómo obtener el número de teléfono solamente. En definitiva, abreviando los problemas más destacados fueron: • Tras editar los ficheros de configuración el sistema Asterisk los sobrescribía. La razón es que utiliza un framework, el cual sobrescribe los ficheros de configuración. La solución era bifurcar el flujo de órdenes de una llamada entrante en un punto concreto de su configuración y de esta manera poder insertar código desde otro fichero personalizado. • Para extraer el número de teléfono durante el flujo de una llamada entrante, se recurre a usar un script que hace uso de comandos Linux. Se genera un fichero con el número de teléfono obtenido de las variables de entorno global de la programación de Asterisk. • Otro problema fue que el webservice tenía que conocer siempre la ip de la máquina Linux, sino no podía conectar mediante Samba para recibir la llamada capturada. Finalmente, configuré Linux para obtener la ip de una máquina, por su nombre de red mediante un servidor de nombres WIND. • ¿Cuándo se ejecuta el método que procesa la llamada en el webservice? ¿Cómo sabe si tiene una llamada por procesar? Se estudió un sistema de hilos para llamar al webservice cada poco tiempo, pero nunca llegó a funcionar porque el lenguaje Wlanguage de Webdev no tiene hilos persistentes, solo en la versión para móviles. Además, un webservice no se puede llamar a sí mismo a no ser recursivamente y sin condición de parada, es inviable, por lo tanto tenía que invocarse externamente. La solución fue añadir otro script en Linux para invocar al webservice cada vez que entraba una llamada en el código personalizado del Dialplan de Asterisk. De este modo es muy eficiente al no haber espera activa. • Hubo que configurar los permisos y credenciales de una carpeta de red en Windows. Un script en Linux se encarga de montar dicha carpeta y depositar ahí las llamadas. El problema es que desde el script no hay manera de saber si está o no montada la carpeta de red por lo que hubo que buscar una manera. Se añadió un fichero “baliza” llamado “Baliza_linux.lnx” en la carpeta compartida de red en Windows. Cuando el script monte la carpeta de red preguntará si existe el fichero, en caso afirmativo es que ha montado la carpeta de red Windows en Linux con éxito. • Los scripts desarrollados en Linux habían pasado las pruebas, pero al ejecutarlos en el Dialplan de Asterisk ocurría un error inesperado y colgaba las llamadas. Hubo que hacer una traza completa usando el debugger propio de Asterisk, se detectó un timeout en el Dialplan. Los scripts son pesados, tardan en ejecutarse y frena la ejecución de órdenes críticas de Asterisk. Por lo que cuelga las llamadas. La solución fue lanzar los scripts en segundo plano con “&”. Inicialmente no funcionó, porque el usuario Linux “Asterisk” es quien los pág. 151 ejecuta mediante la orden “sudo”. Debido a que se lanza el comando “sudo” el sistema Linux obliga a que inserte la clave del root. Solución, acceder a la configuración de root para que el sistema no le solicite la clave root al usuario de Linux “Asterisk”. A partir de este punto, es posible capturar y transferir las llamadas al webservice e invocarlo posteriormente. Se ha tenido en cuenta pequeños detalles para garantizar que todas las llamadas de los clientes han sido registradas. Tanto desde Linux como en el webservice, se ha hecho un esfuerzo adicional para no perder ni una sola llamada, implementando soluciones offline en ambos. Permitiendo continuar con la captura de llamadas entrantes en modo offline y a través de los scripts lanzados desde Asterisk restaurar todas las llamadas offline, desde que detecte que existe comunicación con el webservice. Ninguna llamada se pierde. Además el webservice genera el registro de llamadas y crear una copia de seguridad automática de las llamadas por cada jornada de trabajo. El webservice mientras toma la información de los clientes, cuando estos llaman, además alimenta su propia agenda independiente del sistema de incidencias, para que en el caso de trasladar el servidor Asterisk a otra máquina, el webservice pueda trabajar desde su base de datos local alimentando el RSS en cada llamada. El entorno de desarrollo de PCSoft (Webdev) facilitó las herramientas de depuración y el acceso automático a la base de datos tanto del sistema de incidencias como del webservice. Es la primera vez que implemento un webservice y que configuro un servidor Asterisk. Pero sin embargo tengo que decir que es una gran satisfacción completar la integración entre Asterisk desde Linux, el webservice y el sistema de seguimiento y registro de incidencias. Con el fin de obtener la notificación de la llamada de un cliente en tiempo real. Destaco que es la primera vez que implemento un RSS. En este caso es versión 2.0. El sistema que lee cada 2 segundos el RSS por red me ha gustado porque no ofrece perdida de rendimiento y ejecuta su objetivo perfectamente. Informar de la llamada entrante en tiempo real. He de señalar un dato importante y es que hasta la fecha Movistar no ofrece entre sus servicios de centralita telefónica en la nube para empresas, la opción de una agenda corporativa. Que significa que solo hay una agenda para toda la empresa y sus terminales. En este proyecto se ha conseguido implementar una agenda corporativa mediante la comunicación del webservice con la base de datos compartida con el sistema de incidencias. Adicionalmente no se limita sólo a mapear por su número telefónico y extraer el nombre del cliente, ya que además adjunta información actualizada del estado de sus incidencias y avisos importantes respecto al cliente. Por lo tanto, todo empleado podrá no solo detectar quien llama sino estar informado del estado del cliente antes de descolgar. pág. 152 Trabajos futuros Partiendo de todo lo hecho, se puede llevar a cabo una serie de mejoras de ampliación de su funcionalidad, para que sea más completo y flexible, con el fin de cubrir un amplio rango de necesidades. Las mejoras se irían repartiendo por distintas fases de implementación para conseguir un producto mucho más completo y que permita una mayor distribución. Se contemplan diversos puntos a mejorar en el sistema, de los cuales los más destacados son los siguientes: 1. Actualmente se importa el cliente, su dirección y su contacto desde un fichero del sistema Visual Fox Pro. Como trabajo futuro, seguir importando los demás datos relevantes, tales como las incidencias y partes de cada cliente. 2. Implementar un sistema de seguridad para nuevos usuarios que deseen darse de alta en el sistema: o Que el sistema les envíe un email con un enlace, el cual tendrá que acceder para finalizar el registro. Si no fuera así, el registro no se hará efectivo. Actualmente se controla con un número máximo de usuarios no validados por el administrador. o Insertar un código captcha en el formulario de registro. 3. Generación de informes internos por cada incidencia. El objetivo es plasmar en un documento su seguimiento en detalle. Incluirá todos sus comentarios asociados, los estados transitados desde su creación hasta su cierre y los tiempos entre cada cambio de estado. 4. Aumentar el número de informes estadísticos. 5. Debido a problemas ya sufridos con cierta frecuencia, la empresa se queda sin comunicación ante fallos de la centralita Movistar. Se plantea, ya que se ha implantado y configurado dentro de la red interna de la oficina, una centralita virtual Asterisk, facilita enormemente tener contratado una línea SIP-Trunk (con número de teléfono asociado). El objetivo es tener su propia centralita telefónica software, interna a la oficina, tal como lo hacían en los inicios de Kernel Informática S.L. Las posibilidades son: o Número alternativo de empresa en caso de problema en la centralita principal Movistar. o El coste de los proveedores actuales ronda los 16 euros/mes incluido el número de teléfono para recibir llamadas desde fijos, móviles o softphone externos a la empresa. pág. 153 6. El sistema formado por la centralita Asterisk y el webservice puede ser mejorado haciendo uso de una de las características del sistema de base de datos HFSQL de WebDev, las tablas Cliente/Servidor. Únicamente hay que sustituir las tablas actuales HFSQL clásico, por tablas Cliente/Servidor HFSQL. Este cambio permitirá el acceso remoto a la base de datos. Por lo tanto, la información de las tablas serán accesibles desde internet. Sólo necesitaría la dirección IP y el credencial de conexión. 7. La arquitectura empleada, basada en capas, permite que se pueda implementar sobre otras plataformas, como por ejemplo plataformas móviles ya que toda la lógica de negocio la provee los servicios web, conjuntamente con los patrones de diseño, que permitirán la realización de este tipo de aplicativos. Es por ello que proponemos su desarrollo en una posterior versión del producto.