DISEÑO Y DESARROLLO DE UNA HERRAMIENTA DE SOFTWARE...
270
DISEÑO Y DESARROLLO DE UNA HERRAMIENTA DE SOFTWARE LIBRE PARA MONITOREO DE DISPONIBILIDAD DE IVR SOBRE SISTEMAS DE TELEFONIA. DIEGO FERNANDO LÓPEZ GONZÁLEZ RAFAEL EDUARDO MORALES OSORIO UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS BOGOTA D.C. 2015
Transcript of DISEÑO Y DESARROLLO DE UNA HERRAMIENTA DE SOFTWARE...
DISEÑO Y DESARROLLO DE UNA HERRAMIENTA DE SOFTWARE LIBRE
PARA MONITOREO DE DISPONIBILIDAD DE IVR SOBRE SISTEMAS DE
TELEFONIA.
DIEGO FERNANDO LÓPEZ GONZÁLEZ
RAFAEL EDUARDO MORALES OSORIO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS
BOGOTA D.C.
2015
DISEÑO Y DESARROLLO DE UNA HERRAMIENTA DE SOFTWARE LIBRE
PARA MONITOREO DE DISPONIBILIDAD DE IVR SOBRE SISTEMAS DE
TELEFONIA.
DIEGO FERNANDO LÓPEZ GONZÁLEZ
RAFAEL EDUARDO MORALES OSORIO
Proyecto de grado para optar al título de Ingeniero de Sistemas
Director
Ing. FERNANDO MARTÍNEZ RODRÍGUEZ M.Sc
Ingeniero de Sistemas
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA DE SISTEMAS
BOGOTA D.C.
2015
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
FACULTA DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS
Rector: Carlos Javier Mosquera Suárez (E)
Decano Facultad de Ingeniería: Roberto Ferro Escobar
Coordinador Proyecto Curricular de Ingeniería de Sistemas: Oswaldo Alberto
Romero Villalobos
Notas de Aceptación:
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_______________________________________________
ING. FERNANDO MARTÍNEZ RODRÍGUEZ M.Sc.
Director del Proyecto
_______________________________________________
ING. ALBERTO ACOSTA M.Sc
Jurado
Bogotá D.C., 26 de octubre de 2015
DEDICATORIAS
Dedico la culminación de este trabajo a mis padres y hermanos por su constante
apoyo y acompañamiento a esta causa y demás proyectos de mi vida, a mi
esposa por su paciencia y solidaridad en todo este tiempo mientras realice este
proyecto y que espero contar con mucho tiempo más; a mi compañero y
compadre Diego López por su amistad y su compromiso para llevar a cabo esta
tarea que ha conllevado grandes sacrificios; y finalmente a mis compañeros de
estudio Tulkas, Gregoria y Christopher que han estado ahí en todo momento.
Rafael Eduardo Morales Osorio
A mi madre, padre, tía y hermanos por haberme brindado su gran apoyo y ser
parte fundamental de mi formación personal.
A mi esposa Carolina quien con su acompañamiento y paciencia fue testigo de
este proceso.
A mi compañero de tesis Rafa, por su impulso y convencimiento de llevar el
proyecto hasta el final.
A Favhyan y Camilo, por sacarnos de apuros en momentos difíciles.
Finalmente, y por conceder tiempo que le pertenecía como hijo para la realización
de este proyecto, a Sebitas… su entusiasmo siempre me ha dado ejemplo de
perseverancia.
Diego Fernando López González
AGRADECIMIENTOS
Agradecemos a la Universidad por brindarnos la oportunidad de formarnos en sus
aulas, así como a los docentes que nos orientaron para ser mejores profesionales
y mejores personas.
Especialmente al profesor e investigador Ing. Fernando Martinez Rodriguez, pues
él fue nuestro guía y tutor en este proyecto, a quién también agradecemos por su
tiempo y dedicación a este.
CONTENIDO
INTRODUCCIÓN.....................................................................................................16
1. PLANTEAMIENTO DEL PROBLEMA................................................................18
1.1 DESCRIPCIÓN DEL PROBLEMA................................................................18
1.2 FORMULACIÓN DEL PROBLEMA..............................................................22
2. JUSTIFICACION DE LA INVESTIGACION........................................................23
3. OBJETIVOS.........................................................................................................26
3.1 OBJETIVO GENERAL DE LA INVESTIGACIÓN........................................26
3.2 OBJETIVOS ESPECÍFICOS.........................................................................26
4. DELIMITACIÓN...................................................................................................28
4.1 ALCANCES...................................................................................................28
4.2 LIMITACIONES.............................................................................................29
5. FACTORES DIFERENCIALES O DE VALOR AGREGADO DE LA PROPUESTA...........................................................................................................30
6. MARCO REFERENCIAL DEL PROBLEMA A INVESTIGAR............................31
6. 1 ANTECEDENTES O ESTADO DEL ARTE..................................................31
6.1.1 Avaya......................................................................................................31
6.1.2 DreamPBX.............................................................................................34
6.1.3 VQManager: Software de Monitoreo de la Calidad VoIP [4]..................35
6.1.4 Pandora FMS.........................................................................................36
6.1.5 HP Business Availability Center (BAC)..................................................41
7
6.2 MARCO TEÓRICO........................................................................................45
6.2.1. Infraestructura de Comunicaciones......................................................45
6.2.2 Desarrollo...............................................................................................52
7. MARCO METODOLOGÍCO................................................................................67
7.1 METODOLOGÍA DE LA INVESTIGACIÓN..................................................67
7.1.3 Tipo de Estudio.......................................................................................67
7.1.2 Metodología de la Investigación.............................................................67
7.1.3 Participantes...........................................................................................68
7.1.4 Instrumentos y Equipos..........................................................................68
7.2 METODOLOGIA DE LA INGENIERIA DEL PROYECTO............................69
7.2.1 Etapa Adecuación de la Infraestructura de Voz.....................................70
7.2.2 Etapa Generación de scripts encargados de la marcación automática 70
7.2.3 Etapa Diseño y Desarrollo de la aplicación de Monitoreo.....................70
7.2.4 Etapa Integración de la aplicación software con el Sistema de Voz el cual se va a monitorear...................................................................................73
7.2.5 Herramientas a Utilizar...........................................................................74
8. RESULTADOS Y DISCUSIÓN............................................................................75
8.1 ADECUACIÓN DE LA INFRAESTRUCTURA DE VOZ :.............................75
8.1.1 Fase 1: Estrategia del Servicio..............................................................75
8.1.2 Fase 2: Diseño.......................................................................................75
8.1.3 Fase 3: Transición..................................................................................76
8
8.1.4 Fase 4: Operación..................................................................................77
8.1.5 Fase 5: Mejora.......................................................................................79
8.2 GENERACIÓN DE SCRIPTS ENCARGADOS DE LA MARCACIÓN AUTOMÁTICA.....................................................................................................79
8.2.1 Fase 1: Estrategia del Servicio..............................................................79
8.2.2 Fase 2: Diseño.......................................................................................79
8.2.3 Fase 3: Transición..................................................................................79
8.2.4 Fase 4: Operación..................................................................................80
8.2.5 Fase 5 : Mejora......................................................................................80
8.3 DISEÑO Y DESARROLLO DE LA APLICACIÓN SOFTWARE..................81
8.3.1 PSI: Planificación de Sistemas de Información.....................................81
8.3.2 DSI: Desarrollo de Sistemas de Información.........................................84
8.3.2.1 Estudio de viabilidad del Sistema (EVS)........................................84
8.3.2.2 Análisis del sistema (ASI)...............................................................86
8.3.2.3 Diseño del sistema (DSI)..............................................................109
8.3.2.4 Construcción del sistema (CSI)....................................................127
8.3.2.5 Implantación y aceptación del sistema (IAS)................................134
8.3.3 Mantenimiento del SI...........................................................................135
8.4 Integración de la aplicación software con el Sistema de Voz el cual se va a monitorear................................................................................................135
8.4.1 Fase 1: Estrategia del Servicio............................................................135
8.4.2 Fase 2: Diseño.....................................................................................135
9
8.4.3 Fase 3: Transición................................................................................136
8.4.4 Fase 4: Operación................................................................................137
8.4.5 Fase 5: Mejora.....................................................................................139
8.5 Publicación del Software bajo licencias GPL.........................................139
9. CONCLUSIONES..............................................................................................141
10. RECOMENDACIONES...................................................................................143
11. BIBLIOGRAFIA Y REFERENCIAS ELECTRÓNICAS...................................144
12. ANEXOS..........................................................................................................147
10
LISTA DE IMÁGENES
Figura 1.1 Comportamiento IVR de acuerdo a pruebas manuales para el mesde Febrero (up-time aproximado: 97,7%).......................................................19
Figura 1.2 Comportamiento IVR de acuerdo a reportes de usuarios recibidos por correo electrónico para el mes de Febrero (up-time aproximado: 85%)4 19
Figura 1.3 Ejemplo de IVR..............................................................................21
Figura 6.1 Aspectos monitoreados en la solución Voice Portal de Avaya......32
Figura 6.2 Configuración del servidor destino a quien se le reportará las alarmas en el Voice Portal...............................................................................32
Figura 6.3 Configuración del trap para enviar por snmp las alarmas del Voice Portal...............................................................................................................33
Figura 6.4 configuración del agente SNMP en el sistema S8400 de Avaya.. 33
Figura 6.5 Configuración del trap en el sistema S8400 de Avaya..................34
Figura 6.6 Alcance de DreamPBX en aplicaciones de IVR............................34
Figura 6.7 Alcance de DreamPBX en monitoreo............................................35
Figura 6.8 Alarmas evidenciadas en VQManager..........................................35
Figura 6.9 Vista general del software VQManager.........................................36
Figura 6.10 Vista general de Pandora FMS....................................................39
Figura 6.11 Vista general de Pandora FMS....................................................39
Figura 6.12 Vista general de BAC...................................................................43
Figura 6.13 Herramientas de monitoreo.........................................................44
Figura 6.14 Evaluación sistemas de monitoreo..............................................45
11
Figura 6.15 Tabla de frecuencias duales para cada símbolo en DTMF.........48
Figura 6.16 Infraestructura de una PBX sobre una red IP..............................49
Figura 6.17 Modelo vista-controlador..............................................................54
Figura 6.18 Infraestructura de Métrica V3......................................................56
Figura 6.19 Fase de planificación de Métrica V3............................................57
Figura 6.20 Actividades de la fase de planificación de Métrica V3.................57
Figura 6.21 Fase estudio de viabilidad de Métrica V3....................................58
Figura 6.22 Actividades de la fase estudio de viabilidad de Métrica V3.........58
Figura 6.23 Fase análisis de Métrica V3.........................................................59
Figura 6.24 Actividades de la fase análisis de Métrica V3..............................59
Figura 6.25 Fase de diseño de Métrica V3.....................................................60
Figura 6.26 Actividades de la fase de diseño de Métrica V3..........................60
Figura 6.27 Fase de construcción de Métrica V3...........................................61
Figura 6.28 Actividades de la fase de construcción de Métrica V3................61
Figura 6.29 Fase de implantación y aceptación de Métrica V3......................62
Figura 6.30 Actividades de la fase de implantación y aceptación de Métrica V3....................................................................................................................62
Figura 6.31 Fase de mantenimiento de Métrica V3........................................63
Figura 6.32 Actividades de la fase de mantenimiento de Métrica V3.............63
Figura 6.33 Ciclo de vida de los servicios TI...................................................64
Figura 6.34 Detalle del proceso planificación y soporte a la transición..........65
12
Figura 6.35 Detalle del proceso gestión de la configuración..........................65
Figura 6.36 Detalle del proceso gestión de entregas y despliegues..............66
Figura 6.37 Detalle del proceso de evaluación...............................................66
Figura 8.1 Detalle del diseño de la Infraestructura.........................................76
Figura 8.2 Esquema del IVR implementado para pruebas.............................78
Figura 8.3 Esquema del manejo de eventos entre los servidores..................80
Figura 8.4 Diagrama de Casos de Uso.........................................................100
Figura 8.5 Diseño página de Inicio de la aplicación.....................................105
Figura 8.6 Diseño página de generación de reportes de la aplicación.........105
Figura 8.7 Particionamiento físico.................................................................110
Figura 8.8 Diagrama de Estructura de alto nivel...........................................112
Figura 8.9 Diagrama de Entidad – Relación (en el Anexo D se encuentra detallado éste diagrama)...............................................................................115
Figura 8.10 Diagrama de Clases (en el Anexo E se encuentra detallado éste diagrama).......................................................................................................116
Figura 8.11 Validación de Requerimientos para la construcción del Software........................................................................................................................129
Figura 8.12 Variables usadas en AMI...........................................................136
Figura 8.13 Script de prueba para conexión al AMI......................................137
Figura 8.14 Eventos recolectados por el cliente TSAPI...............................138
Figura 8.15 Eventos visualizados en el servidor de telefonía remoto..........138
Figura 8.16 Publicación del Software en la comunidad Sourceforge ..........140
13
14
LISTA DE TABLAS
Tabla 7.1 Hardware a Usar..............................................................................................................68
Tabla 7.2 Otras Herramientas y técnicas.........................................................................................69
Tabla 8.1 Requerimientos funcionales del módulo usuarios............................................................93
Tabla 8.2 Requerimientos funcionales del módulo monitor..............................................................94
Tabla 8.3 Requerimientos funcionales del módulo configuración....................................................95
Tabla 8.4 Requerimientos funcionales del módulo incidentes..........................................................95
Tabla 8.5 Requerimientos funcionales del módulo Reportes y Configuración.................................96
Tabla 8.6 Casos de Uso................................................................................................................... 98
Tabla 8.7 Actor del sistema Operador..............................................................................................99
Tabla 8.8 Actor del sistema Administrador.......................................................................................99
Tabla 8.9 Actor del sistema Monitor.................................................................................................99
Tabla 8.10 Matriz Casos de Uso vs Requerimientos Funcionales.................................................102
Tabla 8.11 Catálogo de requisitos..................................................................................................110
Tabla 8.12 Catálogo de Excepciones.............................................................................................111
Tabla 8.13 Ubicación subsistemas - nodos....................................................................................112
Tabla 8.14 Caso de prueba CP001: creación de Usuario..............................................................118
Tabla 8.15 Caso de prueba CP002: borrado de Usuario................................................................119
15
Tabla 8.16 Caso de prueba CP003: creación de Centinela............................................................119
Tabla 8.17 Caso de prueba CP004: borrado de Centinela............................................................120
Tabla 8.18 Caso de prueba CP005: creación de CI.......................................................................120
Tabla 8.19 Caso de prueba CP006: borrado de CI........................................................................121
Tabla 8.20 Caso de prueba CP007: creación de cambios.............................................................121
Tabla 8.21 Caso de prueba CP008: cambio de estado de cambios..............................................122
Tabla 8.22 Caso de prueba CP009: creación manual de incidentes..............................................122
Tabla 8.23 Caso de prueba CP010: cambio de estado de incidentes............................................123
Tabla 8.24 Caso de prueba CP011: creación reportes automáticos..............................................123
Tabla 8.25 Caso de prueba CP012: borrado de reportes automáticos..........................................124
Tabla 8.26 Caso de prueba CP013: Ejecución de un centinela en el sistema para estado En
Servicio.......................................................................................................................................... 125
Tabla 8.27 Caso de prueba CP014: Ejecución de un centinela en el sistema para estado Servicio
Degradado..................................................................................................................................... 125
Tabla 8.28 Caso de prueba CP015: Ejecución de un centinela en el sistema para estado Fuera de
Servicio.......................................................................................................................................... 126
Tabla 8.29 Resultado de ejecución de Pruebas Funcionales.........................................................131
Tabla 8.30 Resultado de ejecución de Pruebas del Sistema.........................................................132
16
LISTA DE ANEXOS
ANEXO A: Especificación de Requerimientos.................................................147
Requerimientos Funcionales – Especificación................................................147
Requerimientos Funcionales del Módulo Usuarios.........................................147
Requerimientos Funcionales del Módulo Monitor...........................................150
Requerimientos Funcionales de Mantenimiento..............................................155
Requerimientos Funcionales de Auditoría y Control.......................................157
Requerimientos Funcionales del Módulo Incidentes......................................158
Requerimientos Funcionales del Módulo Reportes – Configuración............160
Requerimientos no Funcionales........................................................................163
Plataforma de implementación...........................................................................163
Seguridad y control de acceso...........................................................................163
Especificaciones Suplementarias (No Funcionales).......................................164
ANEXO B: Especificación de Casos de Uso.....................................................166
ANEXO C : Glosario terminología ITIL..............................................................205
ANEXO D: Diagrama Entidad – Relación Extendido........................................208
ANEXO E: Diagrama de Clases..........................................................................209
ANEXO F: Manuales y Procedimientos.............................................................210
Procedimientos de Operación y Administración del Sistema........................210
17
Manual de Instalación de Sentinel.....................................................................210
Manual de Usuario Sentinel................................................................................218
Manual de restauración de BD de Sentinel.......................................................264
18
INTRODUCCIÓN
Las llamadas telefónicas de una organización se reciben de dos modos diferentes:el primero se presenta cuando llegan directamente del emisor que se encuentrafuera de la organización al receptor que se encuentra dentro de esta, el segundose presenta cuando existe uno o varios operadores (máquina o humano) quienesse encargan de recibir, clasificar y entregar dichas llamadas de forma adecuada alinterior de la organización. En el caso en que sea una máquina, la herramientatecnológica que realiza la función de recibir estas llamadas de forma centralizadapara dirigirlas automáticamente se conoce como Sistema de Respuesta de VozInteractiva, en adelante IVR (Por su siglas en inglés Interactive Voice Response).Éste sistema se puede entender como un canal de comunicación por el cual losclientes y usuarios de una organización interactúan con ella utilizando el sistemade voz de la misma[1]. Para que el IVR pueda cumplir su función, puede usar lamarcación de tonos multifrecuencial ( o DTMF por sus siglas en inglés, Dual-ToneMulti-Frecuency) o la interacción entre comandos de Voz y la publicación de guíasde voz. A su vez, éste necesita integrarse con un PBX (Private Branch eXchange)para poder realizar la transferencia de las llamadas. Sin embargo, el IVR puedetener otros usos además de servir de “operador telefónico”: En países comoEstados Unidos no es raro que se utilicen para realizar encuestas, o estudiosmédicos[1].
Al ser los IVR una herramienta de uso frecuente se decide realizar un proyectoque busque generar un producto de software de apoyo a las infraestructurastecnológicas en las organizaciones y específicamente a los IVR . Este productoestá basado en dos características del desarrollo de software actual: la tendenciaa ofrecer soluciones de software basadas en desarrollo Web que se hace cadavez más evidente dado por las ventajas a nivel de portabilidad, uso de recursos,rápido desarrollo y acceso ubicuo a datos centralizados[2], y el enfoque desoftware libre basado en licencias GPL (General Public License)1, que brinda laposibilidad del mejoramiento continuo del producto al contar con la colaboraciónde distintos desarrolladores que trabajan para una misma comunidad, así comofácil acceso de las organizaciones a soluciones de software a bajos costos. Esteproducto pretende detectar los fallos que un IVR pueda tener y así pueda cumplirsu función principal, clasificar y conectar de forma exitosa las llamadas.
1 Licencia Publica General de GNU, necesaria para publicar software libre, disponible en http://www.gnu.org/licences.
19
Para lograr esto, se diseñó y desarrolló un producto de uso empresarial que alintegrarse con un sistema de voz Asterisk, permite realizar marcacionesautomáticas (incluyendo envío de tonos DTMF) con el fin de detectar si algunaopción del IVR se encuentra fuera de servicio. A su vez, se desarrolló un clienteque fuera capaz de interpretar los eventos de respuesta de una llamada en lacentral telefónica. Adicionalmente, es capaz de registrar todos los eventosrelevantes que se presentan en cada una de las llamadas o test y almacenarlos enuna base de datos con el fin de generar reportes y analizar resultados paradeterminar el estado del IVR.
Como parte de la adopción de buenas prácticas en la infraestructura tecnológica(ITIL), se integró a éste proyecto los módulos de gestión incidentes y gestión decambios con el fin administrar apropiadamente el servicio suministrado, llevandoun control de las modificaciones sobre la plataforma y un seguimiento a las fallasdetectadas por esta.
En el presente documento se detallan todos los procesos que se usaron parallevar a cabo este producto. Procesos como el de diseño y montaje de lainfraestructura tecnológica que constituyo el entorno para construir el producto; yel desarrollo del software basado en la metodología Métrica V3.
20
1. PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN DEL PROBLEMA
Para contextualizar el problema se describe un caso que pretende reflejar elorigen del proyecto en respuesta a una necesidad identificada en unaorganización, cuyo IVR es un canal electrónico utilizado entre otras cosas pararealizar transacciones, aunque esta necesidad puede ser proyectada a empresasque cuenten con un IVR donde se requiera mantener su funcionalidad ydisponibilidad..
CASO DE OBSERVACIÓN2
De acuerdo a la investigación realizada a una empresa en donde hay personasencargadas de realizar monitoreo al IVR de la entidad, se encontró que dichaspersonas realizan marcaciones manuales al IVR y se lleva una bitácora delestado. El resultado de esta bitácora se puede ver en la figura 1.1 en donde serelacionan las veces que falla la prueba (0) y en donde la prueba es exitosa (1) alo largo del mes (eje y = días del mes).
2Los datos en que se basan este estudio son reales pero no se anexan debido a un acuerdo de confidencialidad con la compañía de la cual se obtuvieron.
21
Figura 1.1 Comportamiento IVR de acuerdo a pruebas manuales para el mes de Febrero (up-timeaproximado: 97,7%)3
En la Figura 1.2, se muestra la disponibilidad del mismo IVR pero teniendo encuenta los reportes enviados por correo electrónico del área afectada, en estecaso la Jefatura de Servicio al Cliente.
Figura 1.2 Comportamiento IVR de acuerdo a reportes de usuarios recibidos por correo electrónicopara el mes de Febrero (up-time aproximado: 85%)4
Observando las 2 gráficas se puede identificar que:
• No se puede obtener un dato confiable del up-time del IVR en cuestión.
3 NA: Fuente propia, las gráficas de disponibilidad se construyen a partir de los datos obtenidos de la organización (correo electrónico y bitácora de control de pruebas de IVR)
22
• Se presentan interrupciones del servicio adicionales a las que se identifican conel monitoreo manual.
• En ambos casos el reporte está sujeto a errores de verificación, es decir, que lapersona que hace la prueba la puede realizar de forma errada, en cuyo caso, nose puede asegurar que efectivamente el IVR se encuentre no disponible.
La oportuna solución a una incidencia4 de un servicio de Tecnologías deInformación IT (por su sigla en inglés. Information Technology) dependedirectamente del tiempo que transcurra entre su ocurrencia y la detección de lamisma. Actualmente, si un usuario llama a una entidad para comunicarse con undepartamento específico o realizar alguna consulta de interés a través de un IVR ysu llamada no puede completarse con éxito porque el servicio no está disponible,la corrección de este evento tardará por lo menos hasta que este usuario reportela falla por algún otro medio (por ejemplo enviando un correo electrónico aldepartamento indicando la falla), es decir, no se cuenta con medio de detecciónautomática de incidentes presentados.
Existen sistemas de gestión de llamadas tales como Genesys, centralestelefónicas (PBX) tales como Asterisk, Cisco Call Manager (CCM) , AlcatelOmniPCX Enterprise (OXE) Avaya S8400 entre otras, cuentan con sistemas demonitoreo de disponibilidad que verifican el estado de la infraestructura quesoporta dicha solución (servidores, enlaces, servicios, etc.) pero ninguno de elloscuenta con un sistema de verificación de opciones de un IVR. En muchasocasiones, la infraestructura no reporta inconvenientes pero puede presentarse elcaso que algunas de las opciones del IVR presente problemas que generen nodisponibilidad.
Para entender un poco más el enunciado anterior, se presenta a continuación unesquema de un IVR sencillo5, y luego el escenario de incidencia.
4 Un incidente según ITIL se define como la interrupción de un servicio de TI.
5 NA: Fuente propia, esquema construido para ilustrar un ejemplo de afectación de servicio.
23
Figura 1.3 Ejemplo de IVR
Si se piensa en la estructura de un IVR como un árbol, se tiene para el ejemploanterior un árbol de 3 niveles, en el primero se presenta el menú de bienvenida alusuario y la posibilidad de tomar una de 2 opciones posibles para pasar alsegundo nivel: La opción 1 le presenta dos opciones más para escoger mientrasque la opción 2 del primer nivel permite entregar la llamada a un asesor pararecibir atención personalizada.
El escenario es el siguiente: un cliente de la empresa que tiene el IVR de la figura1.1 quiere consultar los horarios de atención de una sede (la opción comunicarsecon asesor para clientes) y genera una llamada telefonía a dicha entidad para talfin. Si se presenta una caída inesperada en alguno de los servidores queconstituyen el IVR, posiblemente el IVR no conteste la llamada del usuario, elmenú no se le presente, y su requerimiento no podrá ser atendido aunque elsistema alertará de forma automática la caída de dicho servidor al área de soporteencargada permitiendo tomar acciones respecto a la falla. En un segundoescenario, bajo las mismas condiciones, se puede dar la posibilidad de que losservidores estén funcionando de manera óptima, pero por alguna razón la centraltelefónica no es capaz de interpretar los tonos DTMF que permiten navegar en elIVR y pasar del primer al segundo nivel marcando la opción 1, en este caso elimpacto es el mismo dado que la solicitud del usuario no puede ser atendida, la
24
diferencia radica en que nadie se da cuenta del fallo de forma inmediata y no esposible tomar acciones.
En la actualidad, para detectar dichas fallas, se requiere que un humano realice laprueba marcando todas las opciones para comprobar que estén disponibles o queun usuario reporte la falla, lo que ocasiona dos problemáticas, primera: que segenere más carga laboral para el empleado y pueda presentarse fallas en dichotest al no ser confiable la información que sea entregada por él; segunda: una vezpresentada una caída de una de las opciones de un IVR, no es posible detectarlade forma inmediata si no que debe presentarse el reporte de falla de parte dealgún humano para tomar acciones, entonces la respuesta a fallos depende deque el evento sea reportado, generando una probabilidad mayor de nodisponibilidad en el servicio y en el peor de los casos, descontento en el usuariofinal al no ofrecerle un servicio funcional.
Es por esto que nace la necesidad de crear una solución de software que realiceconstante monitoreo al IVR, programando un test periódico personalizado acualquier estructura de IVR para que recorra todo el árbol de opciones y entregueresultados de dichas pruebas. Pero para poder tener un histórico de ladisponibilidad del IVR, se complementa con el desarrollo de un módulo en dondese pueda guardar y generar un histórico de su comportamiento.
1.2 FORMULACIÓN DEL PROBLEMA
¿Cómo automatizar la verificación del estado de un IVR mediante una solución
software basada en la realización de llamadas telefónicas periódicas y que a partir
de dicha verificación, genere un reporte de estado?
25
2. JUSTIFICACION DE LA INVESTIGACION
Todas las tecnologías de información utilizan recursos para poder operar, para darun ejemplo que ilustra como funcionan los monitores de aplicaciones y porque nose pueden utilizar para monitorear un IVR, se puede pensar en un sencillosoftware encargado de realizar una encuesta a una comunidad específica vía web.Seguramente este software para su funcionamiento requiere de un servidor deaplicaciones web, un servidor de base de datos, un servidor de archivos y una redde comunicaciones (en el mejor de los casos cada recurso lo obtiene de unservidor diferente). Si se quisiera monitorear dicho software, de estos servidoresse deben garantizar elementos como la disponibilidad de espacio en discos duros,memoria RAM libre, servicios, base de datos, entre otros; podría pensarse que degarantizar la disponibilidad de estos elementos, el funcionamiento del software(UP TIME) estaría casi al 100%.
Así mismo, el monitoreo de disponibilidad actual de IVR consiste en la verificaciónde los elementos que el mismo IVR necesita, estos elementos pueden serservicios, servidores, bases de datos, Enlaces de Telefonía Pública (E1 oPrimario6), etc. Éste tipo de monitoreo asegura que el IVR responda a las llamadasque hacen los usuarios, sin embargo, existen otro tipo de recursos de los quenecesita un IVR y que son susceptibles de fallar y pueden afectar el up-time de laaplicación: el reconocimiento de tonos DTMF, el paso de llamadas entreextensiones, enrutamiento, conexión contra la red de telefonía pública Conmutada(PSTN por sus siglas en Inglés Public Switched Telephone Network), etc. Unaherramienta de monitoreo de IVR debería ser capaz de asegurar completadisponibilidad de un IVR, teniendo en cuenta todos los elementos que este utiliza.
El desarrollo de la aplicación propuesta en el presente proyecto, pretende mejorarlos siguientes aspectos:
• Obtener información fiable del comportamiento del IVR en cuestión.
• Evitar el mínimo las fallas no identificadas que se obtienen con el monitoreomanual.
6 E1 o Primarios hace referencia a enlaces de voz que proveen las empresas de telefonía pública
26
• Evitar errores en el reporte que se pueden presentar por omisión de informacióno errores de consulta.
• Contar con un reporte en tiempo real del estado del IVR.
• Contar con histórico del comportamiento del IVR
• permitir la adaptación a cualquier modificación que se realice sobre el árbol delIVR.
Las ventajas competitivas que puedan ofrecer las tecnologías de información a losprocesos funcionales de las organizaciones sirven de apoyo a la operación de lasmismas. Es de suponerse que las empresas que utilicen estas tecnologías, seinteresen en mantenerlas disponibles. Uno de los propósitos de este proyecto escolaborar en esta manutención generando una aplicación que realice seguimientoa una herramienta de TI como lo son los IVR.
COSTO-BENEFICIO
Esta relación que existe en la implementación de un sistema de monitoreo de IVRen una organización, depende en gran medida del interés que posea la misma enmantenerlo disponible, por esta razón no es posible determinarlo de formageneral. En su lugar se hará una relación costo-beneficio descriptiva para el casode estudio que se planteo en el titulo anterior.
Un operador realiza pruebas de marcado al IVR 3 veces al día con el fin deverificar que la opción de consulta de saldo de cuenta esté disponible. Estorequiere 3 llamadas telefónicas al día que en promedio duran 2.5 minutos y sóloevaluaría una de varias opciones, en el caso en que el operador necesite validarotras opciones del IVR o incrementar la periodicidad, el tiempo invertido crecería yocasionaría un gasto adicional de su tiempo y por lo tanto un gasto adicional a laorganización así:
Tiempo invertido en consultar 1 opción del IVR 3 veces al día = 7.5 minutosaproximadamente.
Tiempo invertido en consultar 2 opciones del IVR 3 veces al día = 15 minutosaproximadamente.
27
Tiempo invertido en consultar 2 opciones del IVR 6 veces al día = 30 minutosaproximadamente.
Tiempo invertido en consultar 3 opciones del IVR 6 veces al día = 45 minutosaproximadamente.
De contar con una herramienta que realizara el mismo proceso de formaautomática, el tiempo de un operador necesario para la evaluación, se reduce a 0minutos, la periodicidad de las pruebas se podría aumentar así como también lacantidad de opciones probadas.
Ahora bien, además del tiempo invertido en las pruebas manuales, se considera elingreso que obtiene la organización del servicio prestado: para el mismo periododel que se obtuvo el reporte definido en las figuras 1.1 y 1.2, hubo un total de145596 consultas efectivas por parte de clientes, con un valor de $900 + IVA(Impuesto de 0,16%), es decir, un total de $152,000,224 de ingresos dados poruna disponibilidad 97,7% o 85% teniendo en cuenta los 2 reportes existentes.
En el caso en que el up-time sea mayor (lo ideal sería alcanzar el 100%) habría untotal de 171289,41 consultas efectivas, generado un ingreso de $ 178,826,144esto es, un ingreso adicional de $1 a $26.825.920 tendiendo en cuenta si las145596 consultas efectivas corresponden al 85%, ocasionando que la entidadgenere menos ingresos.
28
3. OBJETIVOS
3.1 OBJETIVO GENERAL DE LA INVESTIGACIÓN
Diseñar y desarrollar una aplicación basada en software libre que se integre acualquier IVR dentro de su misma red, que pueda consultar periódicamente suestado de disponibilidad, genere alarmas en caso de un incidente, manejandohistóricos de comportamiento y reportes de up-time.
3.2 OBJETIVOS ESPECÍFICOS
• Construir la funcionalidad de marcación automática y periódica en Asterisk quemediante llamadas telefónicas y envió de tonos recorra las opciones de un IVRy retorne un valor que represente el estado de cada opción.
• Desarrollar el monitor que recibe los datos del marcador automático y a partir deellos muestre el estado en tiempo real del mismo y genere alertas en el caso enque se presente un incidente.
• Desarrollar un módulo que capture el reporte del estado de disponibilidad delIVR y lo almacene con el fin de contar con históricos de comportamiento ygenerar informes periódicos o personalizados.
• Desarrollar un módulo de gestión de usuarios que permita asignar roles, con elfin de distinguir los privilegios y permisos entre un usuario administrador y unoperador.
29
• Permitir que los usuarios con rol de Administrador, definan la estructura de IVRa monitorear mediante la inclusión o modificación de los parámetros querealizan el test.
• Permitir que los usuarios con rol de Operador interactúen con los módulos delmonitor en tiempo real y de reportes de estado, para que puedan consultar elestado del IVR en tiempo real o histórico.
• Comparar los resultados obtenidos de las pruebas de IVR con marcaciónmanual con los reportes entregados por la herramienta de software.
• Liberar el producto bajo licencia GPL para un facilitando el acceso a pequeñas ymedianas empresas; y mejoramiento por parte otros desarrolladores.
30
4. DELIMITACIÓN
4.1 ALCANCES
El alcance del presente proyecto será la realización del diseño y desarrollo de unaherramienta de software libre que permitirá evaluar el estado de un IVR mediantela marcación automática usando el envío de tonos DTMF para navegar en lasopciones del IVR, con el fin de identificar y notificar fallas presentadas en elsistema para minimizar la permanencia de las mismas. La aplicación debeinteractuar con el IVR como lo haría un humano con el fin de realizar las pruebasde disponibilidad.
La aplicación Web que se pretende desarrollar, deberá proporcionar una interfazque permita administrar la herramienta de monitoreo y auto-dial mencionadaanteriormente, esto quiere decir que permita definir el IVR a monitorear, susniveles y tipos de ramas, capaz de realizar auto marcado a IVR y que nosolamente identifique si la llamada es contestada, sino que sea capaz de navegarpor todas las opciones del IVR automáticamente y explore dichas opcionesdefinidas bajo parámetros, esto quiere decir que la herramienta deberá estar en lacapacidad de comunicarse con asesores, realizar transacciones, consultas, entreotras.
El objetivo principal de la aplicación es el monitoreo de IVR y no la construcción deellos, para realizar las pruebas del caso cuando la aplicación este desarrollada, sehará necesaria la creación de un IVR pero esto no quiere decir que la aplicacióneste en capacidad de hacerlos.
Además de la tecnología DTMF, los IVR también hacen uso de tecnologías comoTTS (Texto a Voz, por sus siglas en Ingles: Text To Speech) y ASR(Reconocimiento de Voz Automático, por sus siglas en Inglés: Automatic SpeechRecognition), para la versión del software que se entregará con la realización deeste proyecto, no se realizará validación exacta de estas dos últimas, esto quieredecir, que no se validará gramaticalmente la información entregada por el IVR nise evaluara el envío de instrucciones de voz.
31
La implementación de la aplicación propuesta, requiere de un servidor Asteriskpara su funcionamiento, ya que él es el que se encargará de realizar las llamadas.Sin embargo, cabe resaltar que dicha aplicación no se integrara como un menúdentro de la administración de Asterisk (el código fuente de Asterisk no semodificará), por el contrario, tendrá su propia interfaz para la administración de losscripts de Asterisk.
Por último, la entidad donde se implemente esta solución, debe garantizar elmonitoreo de infraestructura de los servidores con el fin de que la herramienta semantenga disponible la mayor cantidad de tiempo. Esto implica que el objetivo dela aplicación es monitoreo un IVR y no monitorearse a sí misma.
4.2 LIMITACIONES
Cada organización posee un sistema de voz diferente, por lo que si se planeaintegrar la aplicación con un sistema ya existente, seguramente requiera algunasmodificaciones.
En un principio, la aplicación podrá validar las opciones que sean de tipo consulta,pero si el IVR es usado para otras aplicaciones como la grabación de mensajes oenvió de fax, se deberá realizar un desarrollo adicional para cumplir estosrequerimientos
En caso de evaluar el up-time del IVR que sirvió de caso de estudio de estedocumento expuesto al monitoreo de la aplicación propuesta, se requiere elconsentimiento de la organización para la implementación de la herramienta y a lafecha de la realización de este documento, no se cuenta con dicha aprobación.
32
5. FACTORES DIFERENCIALES O DE VALOR AGREGADO DE LAPROPUESTA
La herramienta a desarrollar será capaz de navegar por todo el árbol u opcionesde un IVR, midiendo no sólo la disponibilidad de la línea donde se encuentraconfigurado el IVR sino de todas las opciones del IVR.
A largo plazo, el producto a entregar podría convertirse en un completo softwarede sistemas de VOZ, es decir, que podría pensarse como trabajo futuro, laampliación de los escenarios y pasar de disponibilidad de IVR a un total monitoreode la red de voz de las organizaciones.
Teniendo en cuenta que en el contexto colombiano, país en vía de desarrollo, lagran cantidad de empresas son MiPymes7., y que las aplicaciones corporativasregularmente son muy costosas, liberar un software bajo licencia GPL que apoyeun canal electrónico empresarial, constituye una oportunidad de fortalecimientopara las tecnologías de información que adoptan estas pequeñas empresas.
Adicionalmente, buscando que el desarrollo no sea usado para ataques de DoS8,la herramienta se diseñará para que no permita el monitoreo de un mismo IVRmas de una vez simultáneamente.
7 Las micro, pequeñas y medianas empresas constituyen un 99 % del total de empresas formales de la capital, según el resumen de la conferencia “Bogotá Emprende” del 2006.
8 DoS: Denegation of Service – Denegación del Servicio
33
6. MARCO REFERENCIAL DEL PROBLEMA A INVESTIGAR
6. 1 ANTECEDENTES O ESTADO DEL ARTE
Para mostrar el estado actual del monitoreo de IVR, se basará en dos aspectos: Elmétodo que usan los proveedores de servicios de IVR (PBX) para garantizar ladisponibilidad de sus servicios y la forma como realiza monitoreo las herramientasmás usadas a nivel corporativo. Algunos de estos proveedores son:
6.1.1 Avaya.
De Avaya se tiene conocimiento de dos productos, uno es el S8400 media Servery el otro es el Voice Portal, ambos usan el protocolo SNMP (Protocolo Simple deAdministración de Red, por sus siglas en ingles: Simple Network ManagmentProtocol) de para reportar a un servidor los eventos que se presenten.
Estos eventos se reportan a una consola y los traduce en alarmas en donde seconfiguran los umbrales para clasificar una alarma como crítica o menor. Los trapso alarmas que se envían desde estos servidores sólo se tiene en cuenta elmonitoreo del servidor o los servicios de este, dejando por fuera los demásfactores que hacen efectiva una llamada de un cliente o usuario. A continuación semuestran pantallas de monitoreo de un Voice Portal en producción de la empresacuyo caso de estudio se presentó en el numeral 1 de este documento
34
Figura 6.1 Aspectos monitoreados en la solución Voice Portal de Avaya
Figura 6.2 Configuración del servidor destino a quien se le reportará las alarmas en el Voice Portal
35
Figura 6.3 Configuración del trap para enviar por snmp las alarmas del Voice Portal
Figura 6.4 configuración del agente SNMP en el sistema S8400 de Avaya.
36
Figura 6.5 Configuración del trap en el sistema S8400 de Avaya.
6.1.2 DreamPBX
DreamPBX es una plataforma de telefonía IP corporativa y call center basada enAsterisk. Es una de las plataformas mas reconocidas en el momento.
Según la página oficial [3], esta plataforma cuenta con muchos servicios como IVRy call center pero no se evidencio nada sobre monitoreo de servicios, por lo que sesupone que solo usa el monitoreo por snmp hacia los servicios del servidor.
Figura 6.6 Alcance de DreamPBX en aplicaciones de IVR
37
Figura 6.7 Alcance de DreamPBX en monitoreo
6.1.3 VQManager: Software de Monitoreo de la Calidad VoIP [4].
Se hace importarte nombrar esta herramienta que ofrece actualmente la empresaManageEngine. Brinda la posibilidad de realizar monitoreo al canal por dondetransita la voz, pero lastimosamente sólo puede realizarlo si ésta es VoIP.
El objetivo de esta herramienta es garantizar la calidad de VoIP en unaorganización, por lo que no es posible usarlo para garantizar la disponibilidad deun IVR.
Figura 6.8 Alarmas evidenciadas en VQManager
38
Figura 6.9 Vista general del software VQManager
6.1.4 Pandora FMS.
Pandora FMS es un software de código abierto que sirve para monitorizar y medirtodo tipo de elementos. Monitoriza sistemas, aplicaciones o dispositivos. Permitesaber el estado de cada elemento de un sistema a lo largo del tiempo.(Información suministrada en la página Web [5]
39
Pandora FMS es capaz de detectar si una interfaz de red se ha caído, un ataquede "defacement" en una web, una pérdida de memoria en algún servidor deaplicaciones, o el movimiento de un valor del NASDAQ.
De acuerdo a la información que suministran en su página web, estas son lascaracterísticas que brindan:
• Detectar nuevos sistemas en la red.
• Test de disponibilidad o rendimiento.
• Disparar alertas cuando algo va mal.
• Permite obtener información dentro de los sistemas usando sus propios agentes(disponibles para todos los sistemas operativos del mercado).
• Permite obtener datos remotos usando peticiones de red, incluyendo SNMP.
• Recibir Traps SNMP de dispositivos de red genéricos.
• Generar informes y gráficos en tiempo real.
• Informes SLA (Acuerdo Nivel Servicio).
• Vistas gráficas definidas por el usuario.
• Almacenamiento de datos de meses, listos para ser usados en informes.
• Gráficos en tiempo real para cada módulo.
• Alta disponibilidad en todos sus componentes.
• Arquitectura escalar y modular.
• Soporta más de 2000 sistemas por servidor.
40
• Alertas definidas por el usuario. También pueden ser asociadas a incidentes.
• Gestión de incidentes integrado.
• Gestión integrada de la base de datos: purgado y compactación.
• Multi-usuario, perfiles múltiples, agrupación de agentes.
• Sistema de eventos con validación por el usuario para trabajo en equipo.
• Acceso granular y perfiles de usuario para cada grupo.
• Los perfiles pueden ser personalizados usando hasta ocho atributos deseguridad sin limitación de grupos o perfiles.
Algunos de los test remotos de Pandora FMS incluyen:
• Respuesta ICMP (Ping)
• Polling SNMP (v1, v2c, v3).
• Servicios Estándar TCP/IP (HTTP, SMTP, etc.)
• Puertos específicos TCP/IP con expresiones regulares.
• Disponibilidad de proceso Linux/Unix (vía SNMP)
• Disponibilidad de una WEB (vía URL).
• Soporte Nagios Plug-In (para ambos, disponibilidad y funcionamiento)
• Tráfico de red en un dispositivo.
41
Figura 6.10 Vista general de Pandora FMS
Figura 6.11 Vista general de Pandora FMS
42
Se ha indicado que esta herramienta tiene soporte Nagios, pero no se ha definidoa que se refiere: según su página Web [6], Nagios es un sistema demonitorización de redes de código abierto que vigila los equipos (Hardware) yservicios (software) que se especifiquen, alertando cuando el comportamiento delos mismos no sea el deseado. Entre sus características principales figuran lamonitorización de servicios de red (SMTP, POP3, HTTP, SNMP...), lamonitorización de los recursos de sistemas hardware (carga del procesador, usode los discos, memoria, estado de los puertos...), independencia de sistemasoperativos, posibilidad de monitorización remota mediante túneles SSL cifrados oSSH, y la posibilidad de programar plugins específicos para nuevos sistemas.
En cuanto a su funcionalidad, se puede definir las siguientes características:
• Monitorización de servicios de red (SMTP, POP3, HTTP, NTTP, ICMP, SNMP).
• Monitorización de los recursos de equipos hardware (carga del procesador, usode los discos, logs del sistema) en varios sistemas operativos, incluso MicrosoftWindows con los plugins NRPE_NT o NSClient++.
• Monitorización remota, a través de túneles SSL cifrados o SSH.
• Diseño simple de plugins, que permiten a los usuarios desarrollar sus propiasrevisiones de servicios dependiendo de sus necesidades, usando susherramientas preferidas (Bash, C++, Perl, Ruby, Python, PHP, C#...).
• Chequeo de servicios paralizados.
• Posibilidad de definir la jerarquía de la red, permitiendo distinguir entre hostcaídos y host inaccesibles.
• Notificaciones a los contactos cuando ocurren problemas en servicios o hosts,así como cuando son resueltos (a través del correo electrónico, buscapersonas,Jabber, SMS, o cualquier método definido por el usuario junto con sucorrespondiente complemento).
• Posibilidad de definir manejadores de eventos que ejecuten al ocurrir un eventode un servicio o host para resoluciones de problemas proactivas.
43
• Rotación automática del archivo de registro.
• Soporte para implementar hosts de monitores redundantes.
• Visualización del estado de la red en tiempo real a través de interfaz web, con laposibilidad de generar informes y gráficas de comportamiento de los sistemasmonitorizados, y visualización del listado de notificaciones enviadas, historial deproblemas, archivos de registros...
Siguiendo con Pandora FMS, algunos ejemplos de test realizados medianteagentes son:
• Uso de CPU, Disco, Memoria
• Sobrecarga del sistema .
• Número de incidencias por segundo en un logfile
• Temperatura de un sistema.
• Salida de un comando en el sistema.
• Obtención de valores WMI o PerfCounters en Windows.
• Disponibilidad de servicio o procesos en ejecución.
• Estado de una base de datos Oracle, sus tablespaces y otros valores.
6.1.5 HP Business Availability Center (BAC)
Esta herramienta a diferencia de Pandora, se encuentra orientada al servicio quepermite avanzar en la gestión de los servicios de TI construyendo modelos oestructuras de servicios formados por grupos de elementos de la infraestructura.De esta forma se obtiene una visión de relaciones, dependencias y afectacionesentre la infraestructura y los servicios que ésta soporta.
44
Para proporcionar una visión y gestión completa de los servicios es recomendablecomplementar la gestión clásica y la visión de servicios mediante unamonitorización activa, de extremo a extremo de los mismos, mediante la utilizaciónde sondas o robots específicos que aportan de forma objetiva información dedisponibilidad y rendimiento de los servicios reales.
HP BAC proporciona métricas para mejorar la gestión de las aplicaciones de laorganización y los procesos de monitorización, evolucionando a una mejora de laproductividad de los usuarios finales.
HP BAC Es una solución de gestión de aplicaciones que ayuda proactivamente aidentificar y resolver problemas rápida y eficientemente antes de que el negocioesté afectado. Utilizando la información que BAC ofrece es posible identificar lacausa raíz del problema generando una colaboración de dominio TI eficiente. [7]
A pesar que esta herramienta se encuentra enfocada al servicio y cuenta conBPM’s (HP Business Process Monitor) [8] capaces de consumir webservices(servicios web) que informen del estado de una Aplicación WEB, en estosmomentos no cuenta con uno de ellos que sea capaz de consumir un Audiorespuesta, por lo que sea hace necesario desarrollarla.
45
Figura 6.12 Vista general de BAC
Actualmente existe software basado en licencia GPL para discado automáticotales como Vicidial o GNUDialer, tanto el uno como el otro tiene sus ventajas ydesventajas pero su objetivo principal es realizar llamadas a diferentes númerosde clientes para realizar trabajos de cobranzas o televentas, pero estos no soncapaces de optar por una opción en un árbol de llamadas, ya que no son capacesde interpretar los tonos DTMF.
Adicionalmente, existen scripts para Asterisk que son capaces de realizar unmarcado automático pero este mismo se queda corto ya que para configurar elnúmero destino es necesario modificar el script como tal, causando dificultades alusuario final en el momento en que se desea configurar varios números. Asímismo, tiene la limitante de no reconocer los tonos DTMF, obstaculizando lasllamadas que se hacen hacia empresas.
DTMF es un anacrónico de Dual-Tone Multi-Frequency, nace de la necesidad deenviar dígitos a través de la línea telefónica tanto para marcar como en medio deuna conversación (más detalle en numeral 6.1.3 de este documento).
Las herramientas de monitoreo de Disponibilidad de servicios de negocio queexisten en la actualidad como BAC o Sitescope, Pandora, NNM, no ofrecen un
46
módulo de monitoreo especializado en IVR y el Up-Time de este servicio dependede la detección manual de eventos y su posterior proceso de solución.
Como soporte de lo mencionado en el párrafo anterior, se puede observar en lasiguiente figura que compara las ventajas de diferentes software de monitoreo deVoIP, que ninguna ofrece una solución orientada al monitoreo de IVR [9].
Figura 6.13 Herramientas de monitoreo
47
Figura 6.14 Evaluación sistemas de monitoreo
6.2 MARCO TEÓRICO
La integración de dos disciplinas de Ingeniería en busca de la solución a unanecesidad da origen al presente documento, por un lado está la Telemática quebrinda el escenario en el que se trabajará y hace parte del medio al que segenerará un aporte, y por el otro, el desarrollo de software como una oportunidadpráctica de automatizar un proceso real.
Así mismo, el marco teórico se divide en 2 secciones que representan la premisaanterior respectivamente: La Infraestructura de Comunicaciones, que involucra losconceptos sobre infraestructura y telefonía que se usarán, y Desarrollo, en dondese encuentran los conceptos que usaran del desarrollo de software.
6.2.1. Infraestructura de Comunicaciones.
6.2.1.1 Asterisk. Asterisk es un framework open source para la creación deaplicaciones de comunicaciones. Asterisk convierte un servidor en una central decomunicaciones. Asterisk es patrocinado por Digium, que desde su fundación en
48
1999, se ha convertido en la alternativa de código abierto a los proveedores decomunicaciones propietarias, con precios mas accesibles. Digium ofrece elsoftware de Asterisk gratuitamente a la comunidad de código abierto y ofreceSwitchvox, solución unificada de comunicaciones para impulsar una amplia familiade productos para las empresas pequeñas, medianas y grandes. La línea deproductos de la compañía incluye una amplia gama de hardware de telefonía ysoftware para permitir a los revendedores y clientes implementar sistemas de VoIPo diseñar sus propias soluciones personalizadas de comunicación.
Mark Spencer, de Digium, creador de Asterisk y actualmente su principaldesarrollador, junto con otros programadores a nivel mundial contribuyen acorregir errores y añadir novedades y funcionalidades. Originalmente desarrolladopara el sistema operativo GNU/Linux, Asterisk actualmente también se distribuyeen versiones para los sistemas operativos BSD, Mac OS X, Solaris y MicrosoftWindows, aunque la plataforma nativa (GNU/Linux) es la que cuenta con mejorsoporte de todas. [10]
Para contextualizar la definición de Asterisk, es prudente hablar primero de unaserie de términos y conceptos propios del medio que permitan abstraerla másfácilmente.
6.2.1.2 Telefonía IP y VoIP. Actualmente se habla mucho de telefonía IP y de VoIP,pero ¿cuál es la diferencia entre uno y el otro?
La telefonía IP se refiere a la utilización de una red IP (privada o pública comoInternet) por la que se transmiten los servicios de voz, fax y mensajería. Esta redinterna puede ser utilizada para transmitir las llamadas internas de la empresa.
La VoIP es la tecnología usada para el funcionamiento de la telefonía IP, gestionael envío de información de voz utilizando IP (Internet Protocol), la informaciónanalógica vocal se transforma en paquetes digitales diferenciados que se envíapor la red, los paquetes de información de voz viajan por la red IP del mismo modoque los datos generados por una comunicación de correo electrónico. La telefoníaIP es una aplicación inmediata de esta tecnología, de manera que permite la
49
realización de llamadas telefónicas ordinarias sobre redes IP u otras redes depaquetes.
Los pasos básicos que tienen lugar en una llamada a través de una red IP, son:Conversión de la señal de voz analógica a formato digital y compresión de la señala protocolo de internet (IP) para su transmisión. En la recepción se realiza elproceso inverso para poder recuperar de nuevo la señal de voz analógica. [11]
6.2.1.3 DTMF. Dual-Tone Multi-Frequency o llamado en español, SistemaMultifrecuencial, es básicamente un método de envío e identificación de dígitos.
Antes de la aparición del DTMF, era muy frecuente ver un aparato telefónico conun disco que se usaba para realizar la marcación, este sistema se basaba enmarcación por pulsos que consistía en Interrupción-Conexión. DTMF es el sistemaque hace posible que se puedan hacer llamadas telefónicas mediante la digitaciónde teclas en aparatos telefónicos. Esto quiere decir que para poder realizar unallamada telefónica es necesario tener un aparato capaz de emitir tonos DTMF(cualquier teléfono de teclas) y que el operador telefónico que presta el servicio,sea capaz de interpretar esos tonos para identificar la solicitud de los usuarios.9
El método consiste en el envío de un par de frecuencias, por cada tecla digitada(Figura 6.15 ), esta pareja se arma tomando una frecuencia baja y una alta de unpar de grupos establecidos:
Grupo de bajas frecuencias (en Hz) [697, 770, 852 y 941]
Grupo de altas frecuencias (en Hz) [1209, 1336, 1477 y 1633]
El receptor de un Tono DTMF debe ser capaz de decodificar la señal, obtener elpar de datos y así sabrá cuál fue la tecla fue marcada. [12]
9 N.A: Actualmente los operadores telefónicos reconoce el sistema de pulsos pero los PBX no. Es decir, aun es posible realizar llamadas desde teléfonos de disco, pero no se puede marcar una extensión telefónica en una entidad.
50
Figura 6.15 Tabla de frecuencias duales para cada símbolo en DTMF
Para que un usuario pueda interactuar con un IVR es indispensable que posea unteléfono capaz de emitir tonos DTMF, por esta razón unos IVR advierten: Si tieneun teléfono de tonos y conoce el numero de la extensión por favor márquela…entonces si se quiere implementar un sistema que haga la operación de monitoreode IVR, se necesita que sea capaz de emitir tonos DTMF.
6.2.1.4 PBX. Las siglas de Private Branch Exchange, básicamente es un conjuntode piezas tanto de software como de hardware que como su nombre lo indica, esde carácter privativo y pertenece a la compañía, edificio u organización a la que lepresta el servicio y está encargada del la administración de las llamadastelefónicas de una organización. Esta administración consiste en la asignación deextensiones telefónicas a los usuarios internos, el direccionamiento de lasllamadas internas o entre extensiones, la interconexión entre el sistema detelefonía interno y la PSTN (Public Switched Telephone Network) o telefoníapública para así permitir la comunicación desde el exterior hacia las extensionestelefónicas de los usuarios y viceversa. Para ilustrar un poco la definición de PBX,es un dispositivo telefónico de carácter privado, que hace las veces de operador ocompañía telefónica.
Las PBX empezaron a hacerse muy populares desde mediados de los 80´s y araíz de esto,[12] la competencia entre proveedores hace que estos desarrollencada vez más un conjunto de servicios de telefonía adicionales a saber: correosde voz, menús interactivos, Llamadas en espera, identificación de llamadas,
51
teleconferencias, música en espera, tal vez la más importante: la inclusión detecnología IP y/o adaptación a redes IP, entre otros. (Figura 6.16)
Figura 6.16 Infraestructura de una PBX sobre una red IP
Ya con los conceptos anteriormente entregados, se puede entender la definiciónde Asterisk proporcionada por el autor del libro Asterisk Hacking: “Asterisk es unaPBX de código abierto que tiene capacidades de VoIP.”… [13]“Hoy en día, Asteriskes una de las más populares PBX VoIP basadas en software que se ejecutan enmúltiples sistemas operativos. Asterisk maneja las funciones más comunes de unaCentral e incorpora muchas más. Trabaja con numerosos protocolos de VoIP y escompatible muchas piezas de hardware que interactúan con la red telefónica.Asterisk está en la actualidad a la vanguardia de la tan comentada "revoluciónVoIP" debido a su bajo costo, la naturaleza de código abierto, y sus enormescapacidades.”
6.2.1.5 IVR. Las siglas de “Interactive Voice Response” se refieren a la tecnologíaque soporta la interacción entre los usuarios y un sistema, pero también implicaque la información será proporcionada a quien genera la llamada por el sistemamismo. [14]
52
Una forma alternativa a la atención de los clientes con técnicas CTI (ComputerTelephony Integration) es el uso de IVR. Estos IVR permiten utilizarse comokioscos automáticos de información para cubrir pequeños servicios que impliquenla realización de tareas rutinarias. De esta forma, los IVR actúan a modo de filtrosde llamadas posibilitando la atención al cliente en puntas de tráfico en la red yfacilitando el trabajo a los agentes del centro de llamadas, que pueden ocuparsede las peticiones de información más significativas.
Los IVR consisten en una plataforma de red que pueden incorporarfuncionalidades de mensajería de voz, fax y unidades de locuciones grabadas.Cuando un cliente llama a un centro de este tipo, una serie de menú con funcionesy servicios distintos le van guiando en la información de la información deseada.
Las ventajas de los IVR pasan por una reducción de costos del sistema, reducciónde tiempos de espera de los usuarios llamantes, utilidad en la recepción dellamadas procedentes de promociones especiales (puntas de trafico), aumento dela disponibilidad como oficina telefónica e identificación/verificación de la identidaddel usuario llamante.
Dentro de las facilidades o servicios más comunes proporcionados por lossistemas IVR se destacan el reconocimiento de voz, la conversión de texto-voz yel fax bajo demanda.[15]
Los primeros IVR fueron introducidos en el mercado a mediados de la década de1970 ( Witten y señores, 1977 ). El IVR utilizó por primera vez Dual Tone Multi-Frequency (DTMF) de entrada mediante el cual el teléfono táctil de tono de tecladose utiliza para la información de entrada. Como IVR’s han prevalecido en latelefonía por más de treinta años.
Entre otras funcionalidades de los IVR’s están: La conversión de Texto a Vos (TTSpor sus siglas en Inglés: Text To Speech, O CTV por sus siglas en Español:Conversión Texto-Voz) que hace referencia a la generación, por mediosautomáticos, de una voz artificial que genera idéntico sonido al producido por unapersona al leer un texto cualquiera en voz alta. Es decir, son sistemas quepermiten la conversión de textos en voz sintética. [16]
Adicional a estos conceptos de voz, es importarte presentar la herramienta con lacual se integrará el sistema de voz con el desarrollo a realizar:
53
6.2.1.6 Asterisk Gateway Interface (AGI). [17 ] Asterisk posee un plan demarcación que se ha convertido en una interfaz de programación simple peropotente para la gestión de llamadas. Aún así, otros desarrolladores prefierenimplementar su aplicación de gestión de llamadas personalizada en un lenguajede programación diferente. Usando otro lenguaje de programación tambiénpermite usar el código existente para la integración con otros sistemas. El AsteriskGateway Interface (AGI), permite el desarrollo de control de llamadas de primeraparte en el lenguaje de programación de su elección.
El AGI viene a ser un programa desarrollado en otro lenguaje de Programaciónque Asterisk ejecuta y que sirve para que interactúe Asterisk con el sistema Linux,que permite acceder a archivos locales, puertos físicos (usb, puertos series,paralelos, etc.), bases de datos, páginas web, entre otros, que pueda manejarnuestro sistema Linux. Esta herramienta permite integrar el software a desarrollarcon el servidor de Asterisk con el fin de dirigir las llamadas y generar losrespectivos reportes. En el caso de éste proyecto, la integración se realizaráejecutando el programa que se desarrolla en PHP para generar la marcaciónAutomática y la integración con Bases de Datos en PostgreSQL en donde sedepositarán los registros de las pruebas para su posterior consulta.
6.2.1.7 Asterisk Manager Interface (AMI). [18 ] La interfaz de Asterisk Manager(IAM) es una interfaz de supervisión y gestión del sistema proporcionada porAsterisk. Permite el monitoreo directo de los eventos que ocurren en el sistema,así mismo, permite solicitarle a Asterisk realizar alguna acción. Las accionesdisponibles son muy variados e incluyen procesos como devolver información deestado y originar nuevas llamadas. Muchas aplicaciones interesantes se handesarrollado en la parte superior de Asterisk que se aprovechan de la AMI comosu interfaz principal de Asterisk.
El AMI viene a ser una conexión (TCP) directamente hacia el Asterisk,permitiéndonos realizar cualquier acción sin necesidad de un interprete.
54
6.2.1.8 Computer Supported Telecommunications Applications (CSTA). [19 ] Esuna capa de abstracción para aplicaciones de telecomunicaciones. Esindependiente de protocolos subyacentes. Tiene un modelo de dispositivotelefónico que permite a las aplicaciones CTI para trabajar con una amplia gamade dispositivos telefónicos. Originalmente desarrollado en 1992, se ha seguidodesarrollando y perfeccionando con los años. A menudo es el modelo que lamayoría de aplicaciones CTI son construidas sobre ésta. Se convirtió en unestándar OSI en julio de 2000. Está siendo mantenido actualmente por ECMAInternational.
El núcleo de CSTA es un modelo de control de llamada normalizada. Adicional alnúcleo hay características de las llamadas relacionadas y características dedispositivos físicos, entre otros. Una implementación de la norma no tiene queproporcionar todas las características, por lo que se proporcionan perfiles. Porejemplo, el perfil de Telefonía Básica ofrece características tales como Realizaruna llamada, respuesta y Clear Connection.
6.2.2 Desarrollo
La implementación de la solución que se propone, requiere de la utilización dealgunos conceptos de la ingeniería de software, estos son:
6.2.2.1 Programación Orientada a Objetos. Según el autor Fray León OsarioRivera, Jefe de Programa en el Instituto Tecnológico Metropolitano de Medellín, laprogramación orientada a objetos puede definirse como el conjunto de disciplinasque desarrollan y modelan software para facilitar la construcción de sistemascomplejos a partir de componentes más sencillos. Su atractivo radica en queproporciona conceptos y herramientas con los cuales se modela y representa elmundo tan fielmente como sea posible. [20]
En otras palabras la orientación a objetos en un conjunto de conceptosmundialmente aceptados que facilitan el moldeamiento del mundo real paragenerar sistemas de software10. Entonces, definitivamente la utilización del
10NA: El conjunto de conceptos que conforma el paradigma el paradigma de orientación de objetosno hace parte de este documento.
55
paradigma de orientación a objetos es parte fundamental del desarrollo de laaplicación propuesta.
6.2.2.2 Desarrollo Web. La innegable propagación del Internet, la aceptaciónmundial de los protocolos de Internet mismo y de las tecnologías TCP/IP, hanhecho que las organizaciones utilicen el desarrollo web para las aplicacionesCliente/Servidor que poseen. [1] Esta es la definición básica de Intranet: es lautilización de las tecnologías de Internet para implementar las tradicionalesaplicaciones Cliente/Servidor dentro de una empresa.
Dentro de las ventajas de este tipo de aplicaciones, se encuentran las siguientes:
• El uso a través de Internet, que a su vez permite la movilidad del Cliente oteletrabajo para aplicaciones empresariales.
• La disminución a cero prácticamente del código necesario para la ejecución dellado del Cliente, todas las modificaciones realizadas a las aplicaciones sehacen en el servidor.
• La reducción de instalaciones de herramientas adicionales a un explorador Webdel lado del Cliente.
• La independencia de la plataforma de ejecución
6.2.2.3 UML. La compatibilidad de UML con el paradigma de la orientación aobjetos, al ser una herramienta que apoya la abstracción del modelo de solucionesen el desarrollo de software, su fácil uso y la ventajas de documentación queofrece, son razones de peso para incluirlo en el desarrollo de PIXQUI, será vitalpara especificar, visualizar, construir y documentar el mismo.
6.2.2.4 Arquitectura. Como modelo de arquitectura que separa claramente loscomponentes visuales de los funcionales, se utilizará Modelo Vista Controlador(MVC), en afán de estructurar de alguna forma el código de la aplicación en 3Capas: El modelo que define toda la lógica del negocio, es decir, todo elrepositorio de datos, el sistema de reportes y de monitoreo. La Vista que se
56
encarga de la interface de interacción con el usuario (administrador y operador) ypor ultimo el Controlador que define el modo en que son consultados los datos delmodelo (reportes, alertas, etc.) y como son presentados al usuario, así comotambién modifica los scripts de monitoreo a partir de las instrucciones entregadaspor el usuario administrador.
Figura 6.17 Modelo vista-controlador
6.2.2.5 Métrica V3. La metodología Métrica en su versión 3, desarrollada por elMinisterio de Política Territorial y Administración Pública de España, busca regularlas actividades de Planificación, Desarrollo y Mantenimiento de Sistemas deinformación dentro del ámbito de la administración pública.[21]
Métrica V3 es de libre utilización, la única restricción es la de citar la fuente de supropiedad intelectual, es decir, el Ministerio de Política Territorial y AdministraciónPública de España
Es una mejora de sus versiones anteriores (Métrica versión inicial, Métrica Versión2 y Métrica Versión 2.1) y está basada principalmente en dos documentos ISO:
57
• ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) 11
• ISO/IEC 15504 SPICE (Software Process Improvement And AssuranceStandards Capability Determination) 12
Los componentes de Métrica V3 son 3 Procesos Principales
• Planificación del SI
• Desarrollo del SI
• Mantenimiento del SI
Apoyados por una serie de interfaces cuyo objetivo es dar soporte al proyecto enaspectos organizacionales paralelamente al desarrollo del software.
• Aseguramiento de la Calidad
• Seguridad
• Gestión de Configuración
• Gestión de proyectos
La infraestructura de la metodología se presenta en la figura 6.18
11 NA: Más Información en el siguiente link: http :// www . bvindecopi . gob . pe / normas / isoiec 12207. pdf
12 NA: Más Información en la pagina oficina de la norma: http://www.iso15504.es/
58
Figura 6.18 Infraestructura de Métrica V3
Los procesos e interfaces de Métrica V3 están compuestos por actividades y estasa su vez por tareas, esta composición le da una visión estructural a lametodología, sin embargo, con la integración de ella y UML, se percibe como unametodología orientada a objetos.
59
• Planificación del SI
Figura 6.19 Fase de planificación de Métrica V3
Figura 6.20 Actividades de la fase de planificación de Métrica V3
60
• Desarrollo del sistema
Estudio de la Viabilidad del Sistema
Figura 6.21 Fase estudio de viabilidad de Métrica V3
Figura 6.22 Actividades de la fase estudio de viabilidad de Métrica V3
61
Análisis del Sistema
Figura 6.23 Fase análisis de Métrica V3
Figura 6.24 Actividades de la fase análisis de Métrica V3
62
Diseño del Sistema
Figura 6.25 Fase de diseño de Métrica V3
Figura 6.26 Actividades de la fase de diseño de Métrica V3
63
Construcción del Sistema
Figura 6.27 Fase de construcción de Métrica V3
Figura 6.28 Actividades de la fase de construcción de Métrica V3
64
Implantación y Aceptación del Sistema
Figura 6.29 Fase de implantación y aceptación de Métrica V3
Figura 6.30 Actividades de la fase de implantación y aceptación de Métrica V3
65
• Mantenimiento del SI
Figura 6.31 Fase de mantenimiento de Métrica V3
Figura 6.32 Actividades de la fase de mantenimiento de Métrica V3
66
6.2.2.6 ITIL V3. Son las siglas de Information Technology Infraestructure Library ybásicamente es un conjunto de buenas prácticas para la gestión de servicios de IT.Desarrollado en los 80’s por la Central Computer Telecommunications Agency(CCTA) de gobierno británico y actualmente los responsables del estándar son laOffice of Government Commerce (OGC) y su última versión es ITIL V3 que datadel 2007.
Como política de adopción de estándares y buenas prácticas en la realización deeste proyecto, la utilización de ITIL es fundamental en la implementación de lainfraestructura en la que se desarrollara el proyecto. La explicación del procesoque se adoptará está más clara en los numerales 6.1, 6.2 y 6.4
Acerca de la definición de servicio, ITIL ofrece la siguiente:“Un servicio es un medio para entregar valor a los clientes facilitándoles unresultado deseado sin la necesidad de que estos asuman los costes y riesgosespecíficos asociados.” [22]ITIL V3 cuenta con toda una serie de documentación de buenas prácticas todasellas enfocadas a la gestión de los servicios de IT a lo largo de su ciclo de vida.
Figura 6.33 Ciclo de vida de los servicios TI
La implementación de ITIL V3 para este proyecto, está limitada a los procesos quese ven involucrados directamente con las fases del mismo, es decir, las fases queutilizarán ITIL para su desarrollo, lo harán en la medida que así se requiera.
67
Figura 6.34 Detalle del proceso planificación y soporte a la transición
Figura 6.35 Detalle del proceso gestión de la configuración
68
Figura 6.36 Detalle del proceso gestión de entregas y despliegues
Figura 6.37 Detalle del proceso de evaluación
69
7. MARCO METODOLOGÍCO
7.1 METODOLOGÍA DE LA INVESTIGACIÓN
7.1.3 Tipo de Estudio.
El tipo de estudio de este proyecto es el de desarrollo tecnológico, teniendo encuenta que se busca solucionar una problemática tecnológica a partir de undesarrollo de software.
Este desarrollo afecta al sector tecnológico de cualquier organización que ofrezcaun servicio o producto, donde la unidad de estudio se centra en la disponibilidadde un IVR ya que actualmente en el país muchas organizaciones usan estatecnología para mejorar y optimizar los tiempos de respuesta en atención al clienteo usuario.
7.1.2 Metodología de la Investigación.
El tipo de metodología que se usó es descriptiva y correlacional. descriptivaporque para mostrar la funcionalidad de la herramienta a desarrollar, es necesarioque se describa el funcionamiento de un IVR. Así mismo, correlacional, porquecon el desarrollo de la herramienta, se conoce el comportamiento de una variablerespecto a modificaciones de otras, en este caso, la disponibilidad del IVR (up-time).
70
7.1.3 Participantes.
La herramienta se diseñó con el propósito de que pueda ser utilizada por cualquierorganización que tenga implementado un IVR.
La muestra proviene de una entidad bancaria la cual tiene implementada un IVRcomo servicio de Audiorespuesta transaccional.
7.1.4 Instrumentos y Equipos.
7.1.4.1 Equipos para Diseño, Desarrollo y Pruebas.
Ítem Descripción Cant.
01
Equipo Desktop AMD Phenom II
x4 955 Proccesor 3.20 GHz ; 4
GB RAM Memory; 580 GB Hard
Disk
1
02
Equipo Laptop Inter Core I5
-2.40 Ghz; 4 GB RAM Memory;
750 GB Hard Disk1
03 Servidor Virtual Asterisk2
04 Servidor Virtual Apache y PHP1
TOTAL EQUIPOS 5
Tabla 7.1 Hardware a Usar
71
7.1.4.2 Otras Herramientas y Técnicas
Item Descripción01 Diagrama de Casos de Uso02 Diagrama de Clases03 Modelo Entidad/Relación Extendido04 Normalización05 Optimización06 Diagrama de Grantt07 Presentaciones Prototipado08 Pruebas Unitarias22 Pruebas de Integración23 Pruebas del Sistema24 Pruebas Funcionales24 Revisión Formal25 Revisión técnica26 Sesiones de Trabajo28 Reuniones29 Formatos para la presentación formal de
requerimientos, casos de uso y clases.
Tabla 7.2 Otras Herramientas y técnicas
7.2 METODOLOGIA DE LA INGENIERIA DEL PROYECTO
Las metodologías que se usaron para éste proyecto son ITIL y MÉTRICA V3.Dichas metodologías se aplicaron de la siguiente forma en las cuatro etapas deeste proyecto:
72
7.2.1 Etapa Adecuación de la Infraestructura de Voz
que será el ambiente para el desarrollo del proyecto. Se aplica la metodologíaITIL.
Los servicios ofrecidos son:
• Central telefónica
• Interconexión entre dos centrales telefónicas
7.2.2 Etapa Generación de scripts encargados de la marcación automática
Se aplica la metodología ITIL.
Los servicios ofrecidos son:
• Crear un algoritmo en cualquier lenguaje de programación compatible conAsterisk que pueda realizar la marcación automática.
7.2.3 Etapa Diseño y Desarrollo de la aplicación de Monitoreo.
Se aplica la metodología Métrica V3.
PSI: Planificación de Sistemas de Información.
1. PSI 1 - Inicio del Plan de SI
2. PSI 2 - Definición y Organización del PSI
3. PSI 3 - Estudio de información relevante
4. PSI 4 - Identificación de Requisitos
5. PSI 5 - Estudio de los SI actual
73
6. PSI 6 - Diseño del Modelo del SI
7. PSI 7 - Definición de la arquitectura tecnológica
8. PSI 8 - Definición del plan de acción
9. PSI 9 - Revisión y aprobación
DSI: Desarrollo de Sistemas de Información.
Estudio de viabilidad del Sistema (EVS)
1. EVS 1 - Establecimiento del Alcance del SI
2. EVS 2 - Estudio de la Situación Actual
3. EVS 3 - Definición de Requisitos del SI
4. EVS 4 - Estudio de Alternativas de Solución
5. EVS 5 - Valoración de las Alternativas
6. EVS 6 - Selección de la Solución
Análisis del sistema (ASI)
1. ASI 1 - Definición del Sistema
2. ASI 2 - Establecimiento de Requisitos
3. ASI 3 - Identificación de Subsistemas de Análisis
4. ASI 4 - Análisis de Casos de Uso
74
5. ASI 5 - Análisis de Clases
6.ASI 6 - Definición de Interfaces de Usuario
7.ASI 7 - Análisis de Consistencia
8. ASI 8 - Especificación para Plan de Pruebas
9. ASI 9 - Presentación y Aprobación del Análisis
Diseño del sistema (DSI)
1. DSI 1 - Definición de la Arquitectura del Sistema
2. DSI 2 - Diseño de la Arquitectura de Soporte
3. DSI 3 - Diseño de Casos de Uso
4. DSI 4 - Diseño de Clases
5. DSI 5 - Diseño Físico de Datos
6. DSI 6 - Verificación y Aceptación de la Arquitectura del Sistema
7. DSI 7 - Generación de Especificaciones de Construcción
8. DSI 8 - Diseño de Migración y Carga Inicial de datos
9. DSI 9 - Especificación Técnica del Plan de Pruebas
10. DSI 10 - Establecimiento de Requisitos de Implantación
11. DSI 11 - Aprobación del Diseño del Sistema
75
Construcción del sistema (CSI)
1. CSI 1 - Preparación del Entorno de Generación y Construcción
2. CSI 2 - Generación del Código de los Componentes y Procedimientos
3. CSI 3 - Ejecución de las Pruebas Unitarias
4. CSI 4 - Ejecución de las Pruebas de Integración
5. CSI 5 - Ejecución de las Pruebas del Sistema
6. CSI 6 - Elaboración de los Manuales de Usuario
7. CSI 7 - Definición de la Formación de Usuarios Finales
8. CSI 8 - Construcción Componentes y Procedimientos de Migración y CargaInicial de Datos
9. CSI 9 - Aprobación del Sistema
Los procesos Implantación y aceptación del sistema (IAS) y Mantenimiento del SI(MSI), no se tendrán en cuenta ya que en el alcance del proyecto no se contemplala implementación de la aplicación en un ambiente real.
7.2.4 Etapa Integración de la aplicación software con el Sistema de Voz el cual se va a monitorear.
Se aplica la metodología ITIL.
Los servicios ofrecidos son:
• Integrar el software
76
7.2.5 Herramientas a Utilizar.
Para el desarrollo del proyecto se usarán las siguientes herramientas:
• Asterisk-1.8.11.0 (para generar el marcador y la emulación del IVR)
• Asterisk Manager Interface (AMI) cuya manipulación dará origen a los scripts demarcado
• Apache Tomcat (Servidor Web)
• OpenProj 1.4(Gestión del Proyecto)
• PostegreSQL 9.1.3
• PHP 5
• Symfony 2.3
• Equipo Desktop para desarrollo
• Equipo Laptop para desarrollo
• Máquinas Virtuales de Asterisk (Oracle VirtualBox)
77
8. RESULTADOS Y DISCUSIÓN
A continuación se detalla los procedimientos y tareas de cada metodologíaaplicados a las 4 Etapas de proyecto:
8.1 ADECUACIÓN DE LA INFRAESTRUCTURA DE VOZ :
8.1.1 Fase 1: Estrategia del Servicio.
se usó una plataforma de virtualización para aprovisionar los servidoresnecesarios para la infraestructura, ya que permite una gestión más amigable,centralizada y un ahorro de costos en Hardware. Así mismo ahorro de espacio yconsumo de energía en un Centenada.
8.1.2 Fase 2: Diseño.
La infraestructura se encuentra soportada de acuerdo al siguiente diagrama
78
Figura 8.1 Detalle del diseño de la Infraestructura
8.1.3 Fase 3: Transición.
El servidor host de virtualización es un equipo con SO Linux Fedora 16 con IP10.10.1.102. Se instaló el software de Virtualización Virtualbox 4.3.8 r92456.Sobre la plataforma Virtualbox, se instalaron 2 servidores Centos 6.4 y en cadauno de ellos se instalo el paquete Asterisk 11. Uno de ellos, que tiene comonombre IVRServer, tiene configurada una IP 10.10.1.107 y es donde se van aconfigurar y operar los IVR de pruebas. El otro servidor, con nombre SentinelIVR,se encuentra configurado con la IP 10.10.1.101 y en éste se encuentran los scriptsde marcado, así como la aplicación que se desarrolló para el monitoreo de IVRs.Se decide crear una troncal SIP y no una AIX ya que el SIP es más compatible conlas demás centrales telefónicas.
79
10.10.1.101
10.10.1.10210.10.1.107
10.10.1.101
IVRServer
SentinelIVR
Troncal SIP
8.1.4 Fase 4: Operación.
En el servidor host se crean dos máquinas virtuales con las siguientescaracterísticas:
IVRServer:
RAM: 512 Mb
Disco: 8 GB
Procesador: 1 cpu
SentinelIVR:
RAM: 512 Mb
Disco: 8 GB
Procesador: 1 cpu
Se crea el servidor virtual con nombre IVRServer con la IP 10.10.1.107. Allí secrea el IVR de prueba con la siguiente configuración:
Al ingresar la llamada, se reproduce el archivo audio_ingreso.wav, en ese primernivel, le dará 5 opciones, las tres primeras es pasar al siguiente nivel, la cuarta esrepetir el menú y la última es salir. En el siguiente nivel tendrán las mismas 4opciones más una adicional, que es volver al menú anterior.
80
Figura 8.2 Esquema del IVR implementado para pruebas.
Se define en el plan de numeración del IVRServer las extensiones que inician con2XXX.
Se crea el otro servidor virtual con nombre SentinelIVR con la IP 10.10.1.101. Allíse crean dos extensiones de prueba con el fin de realizar marcaciones. Se defineen el plan de numeración las extensiones que inician con 1XXX. Asi mismo, sedefine que cuando un usuario marque las extensiones con 2XXX, estasmarcaciones se desvíen por la troncal SIP 107_XXX hacia el servidor IVRServer.
En ambos servidores se validan permisos de Firewall para que permita la conexiónde la troncal SIP. Luego de ésta validación, se verifica que la troncal SIP seregistra en ambos servidores. Se realizan pruebas de llamadas siendo estasexitosas.
81
Nodo1 1
Nodo1 2
Nodo1 3
Nodo2 1
Nodo2 2
Nodo2 3
Nodo3 1
Nodo3 2
Nodo3 3
Nodo1
Nodo2
Nodo3
Raiz
8.1.5 Fase 5: Mejora.
Para ésta fase, se realiza constantemente monitorización de los servicios enambos servidores, para así garantizar que tanto las centrales telefónicas como lainterconexión entre ellas siempre se encuentre disponible.
8.2 GENERACIÓN DE SCRIPTS ENCARGADOS DE LA MARCACIÓN AUTOMÁTICA.
8.2.1 Fase 1: Estrategia del Servicio.
Se usa el lenguaje PHP para realizar el script y se usa el Asterisk ManagerInterface (AMI) como integración entre el algoritmo de marcado y el Asterisk.
8.2.2 Fase 2: Diseño.
En ésta fase se verifica que se cuente con todas las variables (extensiones,usuarios, contraseña de conexión, puertos, etc.) necesarias para realizar lamarcación. Así mismo se verifican permisos y configuraciones en el AsteriskManager Interface (AMI) de ambos servidores para que los script se puedanconectar sin inconvenientes.
8.2.3 Fase 3: Transición.
Se crean script's de prueba en los que se verifica la conexión exitosa con losAsterisk Manager Interface (AMI) de los dos servidores. Se verifican LOGS de lasconexiones para identificar la información relevante que necesita el software paraoperar.
82
8.2.4 Fase 4: Operación.
Se generan los 2 script que se van a conectar a los respectivos Asterisk ManagerInterface (AMI). Se crea una función ValidarEstadoCanal que es la que seencarga, como su nombre lo dice, de verificar el estado del canal donde seestablece la llamada. Luego de definir la función, se abre la conexión por donde sevan a enviar y recibir los eventos.
Figura 8.3 Esquema del manejo de eventos entre los servidores
Luego de abrir la conexión, se envía el primer lote de sentencias que consiste enel logueo de la consola del Asterisk Manager Interface (AMI) en los dos servidores.Cuando se valida que la conexión ha sido exitosa, se sigue con el envío de lote desentencias que de acuerdo al servidor, van a ser distintos.
8.2.5 Fase 5 : Mejora.
Para ésta fase, se realiza una depuración y documentación del código parahacerlo más fácil de entender y más rápido en su tiempo de ejecución; evitandobugs que puedan comprometer el rendimiento de los equipos.
83
IVRServerSentinelIVR
Realiza llamada
Contesta llamada
Se conecta al Asterisk Manager Interface (AMI)Escucha todos los eventos
Ejecuta acción tono DTMF
Ejecuta reacción al tono DTMF
Envía señal de cuelgue
Cuelga la llamadaRecolecta todos los eventos de la llamada
Inserta eventos en Base de Datos
8.3 DISEÑO Y DESARROLLO DE LA APLICACIÓN SOFTWARE.
8.3.1 PSI: Planificación de Sistemas de Información.
8.3.1.1 PSI 1 - Inicio del Plan de SI:
• Análisis de la necesidad del PSI
• Identificación del alcance del PSI
• Determinación de responsables del PSI:
Esta etapa inicial del proyecto involucra a los estudiantes que realizan el trabajode grado y al director del mismo, quienes en reuniones de trabajo establecen loscriterios que definen el plan de SI.
8.3.1.2 PSI 2 - Definición y Organización del PSI
• Especificación del Ámbito y Alcance
• Organización del PSI
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento, respectivamente: sección 1, Planteamiento del problema;Sección 4.1, Alcances.
• Definición del Plan de Trabajo
• Comunicación del Plan de Trabajo
Con respecto a la definición y comunicación del plan de trabajo, estos se llevarona cabo en la etapa del anteproyecto: sección cronograma
84
8.3.1.1 PSI 3 - Estudio de información relevante
• Selección y Análisis de Antecedentes
• Valoración de Antecedentes
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 6.1, Antecedentes o estado del arte.
8.3.1.4 PSI 4 - Identificación de Requisitos
• Estudio de los Procesos del PSI
• Análisis de las Necesidades de la Información
• Catalogación de Requisitos
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 1, Planteamiento del problema.
8.3.1.5 PSI 5 - Estudio de los SI actual
• Alcance y Objetivos del Estudio de los Sistemas de Información Actuales
• Análisis de los Sistemas de Información Actuales
• Valoración de los Sistemas de Información Actuales
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 6.1, Antecedentes o estado del arte.
85
8.3.1.6 PSI 6 - Diseño del Modelo del SI
• Diagnóstico de la Situación Actual
• Definición del Modelo de Sistemas de Información
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 6.1, Antecedentes o estado del arte; 6.2.2.4,Arquitectura.
8.3.1.7 PSI 7 - Definición de la arquitectura tecnológica
• Identificación de las necesidades de Infraestructura Tecnológica
• Selección de la Arquitectura Tecnológica
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 7.2.1, Descripción de la Metodología en contexto..
8.3.1.8 PSI 8 - Definición del plan de acción
• Definición de Proyectos a Realizar
• Elaboración del Plan de Mantenimiento del PSI
Con respecto a la definición del plan de acción, esta se llevó a cabo en la etapadel anteproyecto: sección cronograma
86
8.3.1.9 PSI 9 - Revisión y aprobación
• Convocatoria de la Presentación
• Evaluación y Mejora de la Propuesta
• Aprobación del PSI
La aprobación del PSI se llevó a cabo con el VoBo del director de proyecto yrevisores del mismo.
8.3.2 DSI: Desarrollo de Sistemas de Información.
8.3.2.1 Estudio de viabilidad del Sistema (EVS)
8.3.2.1.1 EVS 1 - Establecimiento del Alcance del SI
• Estudio de la Solicitud
• Identificación del Alcance del Sistema
• Especificación del Alcance del EVS
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento, respectivamente: sección 1, Planteamiento del problema;Sección 4.1, Alcances.
8.3.2.1.2 EVS 2 - Estudio de la Situación Actual
• Valoración del Estudio de la Situación Actual
87
• Identificación de los Usuarios Participantes en el Estudio de la Situación Actual
• Descripción de los Sistemas de Información Existentes
• Realización del Diagnóstico de la Situación Actual
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deeste documento: sección 6.1, Antecedentes o estado del arte
8.3.2.1.3 EVS 3 - Definición de Requisitos del SI
• Identificación de las Directrices Técnicas y de Gestión
• Identificación de Requisitos
• Catalogación de Requisitos
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deeste documento: sección 6.1, Antecedentes o estado del arte. sección Anexo A,Especificación de Requerimientos
8.3.2.1.4 EVS 4 - Estudio de Alternativas de Solución
• Preselección de Alternativas de Solución
• Descripción de las Alternativas de Solución
De acuerdo a la naturaleza de éste proyecto, se evaluaron las alternativasexistentes en el mercado pero al analizarlas, se encontró que ninguna suplíacompletamente la necesidad descrita en el problema. Por tal razón, comoalternativa única de solución, se propuso el desarrollo de la aplicación que seencuentra descrita a lo largo de éste proyecto.
88
8.3.2.1.5 EVS 5 - Valoración de las Alternativas
• Estudio de la Inversión
• Estudio de los Riesgos
• Planificación de Alternativas
Dado que sólo se planteó una alternativa de solución, no aplica ésta actividad.
8.3.2.1.6 EVS 6 - Selección de la Solución
• Convocatoria de Presentación
• Evaluación de Alternativas y Selección
• Aprobación de la Solución
Dado que sólo se planteó una alternativa de solución, no aplica las tareas deConvocatoria de Presentación y Evaluación de Alternativas y Selección. Sinembargo, para la tarea de Aprobación de la Solución, ésta tarea se llevó a cabo enconjunto con el Director y los revisores de éste proyecto.
8.3.2.2 Análisis del sistema (ASI)
8.3.2.2.1 ASI 1 - Definición del Sistema
• Determinación del Alcance del Sistema
89
Para revisar el detalle de éstos procesos, consultar la sección de éste documento:4.1, Alcances
• Identificación del Entorno Tecnológico
El entorno tecnológico necesario para dar solución al problema planteado es:
• Se necesita un servidor sin sistema operativo, exclusivo para poderinstalar la aplicación.
• Se necesita un servidor DHCP que asigne automáticamente la IP alservidor instalado, adicionalmente que ésta IP tenga permisos denavegación a internet para completar la instalación del sistema operativo.Luego que termine ésta tarea, ya no es necesario dicho acceso.
• Se necesita un servidor Asterisk en donde se encuentre configurado losIVR que se van a monitorear.
• Para acceder al servidor donde se instala la aplicación, se necesita teneracceso por los puertos 80 (http), 443 (https) y 22 (ssh). Entre el servidorAsterisk y el servidor donde se instala la aplicación, deben estar abiertoslos puertos 5060 (Troncal SIP), 5038 (Asterisk Manager Interface).
• Se necesita configurar una troncal SIP entre el servidor de la aplicación yel servidor donde se encuentran los IVR.
• Se necesita conocer el detalle de la infraestructura de Voz existente paraintegrarla con la solución de monitoreo. Más específicamente, cuántos IVRestán configurados, que opciones tienen, como están configurados, etc.
90
• Especificación de Estándares y Normas
Para éste proyecto no aplica ninguna normatividad o estándar que pueda limitar orestringir el desarrollo u operación del mismo.
• Identificación de Usuarios Participantes y Finales
A continuación se relaciona los usuarios participantes y Finales:
• Usuarios Participantes:
Dado que la identificación del problema surge a raíz de una experienciapersonal, los participantes son los autores de éste documento.
• Usuarios Finales:
Administrador
El usuario administrador es el encargado de crear/editar/borrar:
• Reportes
• Centinelas (monitores)
• Usuarios
• IVR' a monitorear (CI's)
91
Operador
El usuario Operador es el encargado de Visualizar:
• Reportes
• Centinelas (monitores)
• IVR' a monitorear (CI's)
• Gestión de incidentes.
8.3.2.2.2 ASI 2 - Establecimiento de Requisitos
• Obtención de Requisitos
Antes de obtener un catálogo de requerimientos, se definen los siguientesaspectos que ayudaran a definir las necesidades específicas que debe satisfacerla aplicación a desarrollar, con el fin de solucionar el problema propuesto
• Propósito del Sistema
Generar un entorno web de monitoreo que permita conocer el estado realde disponibilidad en uno o varios IVR, con el fin de tomar accionescorrectivas en caso de falla.
• Restricciones y suposiciones
El sistema está dividido en dos subsistemas: el primero de elloscorresponde a la aplicación que sólo será accesible mediante un navegadorweb; y el segundo , que esta conformado por una central telefónica Asteriskencargada de las operaciones telefónicas.
Para acceder a la aplicación existirán 2 roles (Administrador y Operador)que serán asignados a los usuarios del sistema. Con la instalación de la
92
aplicación, se creará un usuario administrador nativo que servirá pararealizar las configuraciones iniciales y la creación de otros usuarios (inclusootros administradores); este usuario quedara habilitado y sólo se usará encaso de que los demás usuarios presenten bloqueo. En general cualquierusuario administrador puede realizar gestión de usuarios; esto es, creación,borrado, edición y desbloqueo.
La aplicación, entre otras funciones, debe proporcionar a losadministradores un método que permita definirle a la central telefónica unplan de marcación (Centinela) que debe seguir para realizar las pruebassobre los IVR y con los resultados de estas pruebas, la misma aplicaciónrepresentará gráficamente el estado de disponibilidad (En Servicio, ServicioDegradado, Fuera de Servicio o desconocido) de uno o varios IVR. Éstosestados están definidos así:
• En Servicio: el IVR funciona correctamente y la aplicación recibe losparámetros esperados definidos en la configuración. Para ésteestado se definió el color verde.
• Servicio Degradado: el IVR presenta falla en algún nodo no prioritariode acuerdo como se define en la aplicación. Para éste estado sedefinió el color amarillo.
• Fuera de Servicio: el IVR presenta falla en algún nodo prioritario deacuerdo como se define en la aplicación. Para éste estado se definióel color rojo.
• Desconocido: el IVR no tiene asociado ningún centinela que lo vigilede acuerdo como se define en la aplicación. Para éste estado sedefinió el color azul.
Cada Centinela está asociado a un IVR, debe tener un horario de ejecución,se puede deshabilitar y habilitar, y se pueden ejecutar manualmente encaso de que se requiera. Además de la gestión de usuarios, tambiéndepende de los administradores la creación, modificación, y borrado de losCentinelas.
93
La principal función de los usuarios operadores es la consulta permanentede los estados de los IVR, a este rol se debe presentar un monitor quecontinuamente esté interpretando los datos de la ejecución del Centinela yasí refleje un estado general de los IVR.
Para determinar los distintos estados de un IVR, es decir, para definir bajoqué condiciones el estado de un IVR puede catalogarse como Fuera deServicio, En Servicio o Servicio Degradado; la aplicación debe basarse enun conjunto de reglas o criterios; estas reglas (Umbrales de criticidad)deben ser parametrizadas para cada IVR o nodo de IVR dependiendo de suimportancia.
ITIL
• Incidentes
Los incidentes para la aplicación reflejan una interrupción y/o degradacióndel servicio detectada en la operación del sistema, así que se debe generarla apertura de un registro de incidente cuando el estado de un IVR cambiede estado En Servicio a cualquier otro estado y su posterior cierre cuandosalga de este estado a estado En Servicio. Cada incidente debe estaridentificado por un código único y debe contener la informacióncorrespondiente al IVR afectado, la fecha de inicio, fecha de cierre y doscampos de texto no obligatorios en los que se puede documentar elproblema y la solución del incidente en caso que se requiera.
• Cambios
Los cambios para la aplicación reflejan una modificación que afecte elservicio ofrecido por la plataforma, así que para cualquier modificación quese realice en ella, debe existir la apertura de un registro de Cambio endonde se relacione la razón de la modificación y la descripción de dichamodificación. El administrador del sistema debe aprobar el cambio, realizarla modificación solicitada, documentar y cerrar el registro de Cambiogenerado por dicha modificación.
94
Notificaciones
Si es requerido, con cada cambio de estado del IVR, se debe poder enviarun correo electrónico a manera de notificación a las cuentas de correo delas personas interesadas en conocer el estado del sistema. Para esto, sedebe permitir la definición y posterior comunicación de un servidor SMTP(Simple Mail Transfer Protocol).
Reportes
Los reportes son un resumen del comportamiento de los IVR en el tiempo,están constituidos por la información que el sistema recopila y se puedenconsultar en tiempo real mediante el explorador web. Se debenproporcionar reportes en un formato exportable en los que se puedaobservar dicho comportamiento de un IVR. Estos reportes pueden serautomáticos o manuales y en ambos casos debe existir el método paradefinirlos.
Otras Consideraciones
Para todas las configuraciones realizadas en la aplicación , se podránguardar backups o copias de seguridad permitiendo restaurar toda laconfiguración en un momento determinado.
En cuanto a la Base de datos de la aplicación, debe hacerse un continuoseguimiento para que no crezca desproporcionadamente y así no afecte elrendimiento del servidor donde se encuentra implementada la aplicación.Así mismo, se debe verificar el tamaño y la criticidad de los logs tanto de laaplicación como de la BD para que estos no ocupen espacio en disco másde lo necesario.
Finalmente, para efectos de seguimiento y control, la aplicación proporcionalos registros (Log) de las principales actividades, autenticaciones, gestiónde usuarios, gestión de cambios, etc.
95
Requerimientos Funcionales
Teniendo en cuenta las restricciones y suposiciones mencionadasanteriormente, los requerimientos que se infieren son los siguientes:
Requerimientos Funcionales del Módulo Usuarios
IDENTIFICADOR NOMBRE DESCRIPCIÓN
RF001 AutenticaciónSe debe proporcionar una
interfaz que permita realizarautenticación en la aplicación.
RF002 Creación usuariosPermitir la creación de usuariosadministradores y operadores.
RF003 Borrado usuariosPermitir el borrado de
usuarios administradores yoperadores
RF004Modificación
Perfiles
Permitir la modificación de losperfiles de usuarios para
asignar o quitar privilegiosdentro de la herramienta.
RF005 Usuario AdminLa aplicación deberá tener al
menos 1 usuario Administrador
Tabla 8.1 Requerimientos funcionales del módulo usuarios
Requerimientos Funcionales del Módulo Monitor
IDENTIFICADOR NOMBRE DESCRIPCIÓN
RF006CreaciónCentinela
Crear uno o varios Centinelas
RF007 Editar CentinelaLa forma de ejecución puede
ser modificada
RF008Deshabilitar /
Habilitar CentinelaLa forma de ejecución puedeser deshabilitada y habilitada
RF009 Borrar CentinelaSe pueden borrar las formas
de ejecución
RF010 Periodicidad Se deben poder definir
96
IDENTIFICADOR NOMBRE DESCRIPCIÓN
Centinelaintervalos de ejecución para
cada Centinela
RF011 Ejecutar CentinelaLos patrones se pueden
disparar manualmente encualquier momento
RF012 Monitor IVRPresentar gráficamente el
estado actual e histórico de unIVR
RF013 Umbrales Definir umbrales de criticidad
RF014Interpretar Datos
de Test
Interpretar los datos delmonitor constantemente paraidentificar si existe cambio en
el estado de un IVR
RF015 AlarmasGenerar alarmas en caso de
presentarse una alteración delServicio de IVR
Tabla 8.2 Requerimientos funcionales del módulo monitor
97
Requerimientos Funcionales del Módulo Configuración
IDENTIFICADOR NOMBRE DESCRIPCIÓN
RF016Aplicar
Configuración
Debe existir un mecanismo quepermita aplicar los cambios que
se realicen en la consola deadministración del sistema.
RF017Backup y
RestauraciónAplicación
Se debe poder guardar copiasde seguridad de toda la
aplicación (usuarios, roles)
RF018 Control CambiosCada cambio sobre laplataforma debe estar
documentado y aprobado
RF019 Historial Login
Para cada usuario, se debedisponer de un historial deautenticaciones sobre la
aplicación
Tabla 8.3 Requerimientos funcionales del módulo configuración
Requerimientos Funcionales del Módulo Incidentes
IDENTIFICADOR NOMBRE DESCRIPCIÓN
RF020Generación de
Incidentes
Generar incidente en caso depresentarse la interrupción del
servicio
RF021Cierre deIncidentesAutomático
Los incidentes deben cerrarseautomáticamente una vez
finalice la alarmacorrespondiente
RF022Documentación
Incidentes
Permitir que los usuariosoperadores retroalimenten los
incidentes
RF023Cierre de
Incidentes Manual
Permitir que los usuariosoperadores cierren los
incidentes.Tabla 8.4 Requerimientos funcionales del módulo incidentes
98
Requerimientos Funcionales de Reportes y Configuración
IDENTIFICADOR NOMBRE DESCRIPCIÓN
RF024Parámetrosservidor de
telefonía remoto
Definir los parámetros decomunicación con la Central
Telefónica en la cual seencuentra configurado el IVR a
monitorear
RF025 SMTPSe debe definir un servidor de
correo para el envío denotificaciones
RF026Exporte deReportes
Exportar reportes dedisponibilidad para cualquier
rango de fechas
RF027 LogDeben existir registros de las
operaciones de la herramienta.
Tabla 8.5 Requerimientos funcionales del módulo Reportes y Configuración
• Especificación de Casos de Uso
• Casos de Uso
IDENTIFICADOR
NOMBRE DESCRIPCIÓN
CU001 Autenticar UsuarioMediante el cual se permite el ingreso al sistema a los usuarios
CU002 Crear UsuarioAcción que permite la creación de un usuario dentro del sistema
CU003 Borrar UsuarioMediante el cual se elimina un usuario dentro del sistema
CU004 Editar UsuarioOpción para modificar el perfil de un usuario existente
CU005 Listar UsuariosConsulta y muestra el total de usuarios del sistema.
CU006 Crear Centinela Opción para crear un patrón de marcado
99
IDENTIFICADOR
NOMBRE DESCRIPCIÓN
con el que se vigila el IVRCU007 Modificar CentinelaSe utiliza para editar un Centinela existenteCU008 Borrar Centinela Eliminar un patrón de marcado
CU009 Habilitar CentinelaHabilitar un patrón de marcado que se encuentra deshabilitado
CU010Deshabilitar Centinela
Para detener la ejecución de un Centinela sin eliminarlo
CU011 Ejecutar CentinelaLanzar el test de un IVR de forma inmediata
CU012 Crear CIOpción para crear una representación del IVR
CU013 Borrar CIOpción para borrar una representación del IVR
CU014Visualizar Monitores
La interfaz inicial de la aplicación debe mostrar en pantalla un resumen gráfico de los estados de los IVR donde podrá visualizarlos el operador.
CU015 Definir UmbralesCaso de uso que permite definir la criticidad de los IVR
CU016Definir Notificaciones
Son las personalizaciones para enviar correos de notificación
CU017 Identificar Estados
Es la interpretación que realiza la aplicación basada en los umbrales para determinar los cambios de estado en un objeto.
CU018 Cambiar Estado
Es la acción que el sistema ejecuta sobre el estado de un CI cuando detecta una anomalía en el comportamiento de un objeto.
CU019 Generar AlarmaEs la acción que el sistema debe realizar con algunos cambios de estado de los IVR
CU020 Guardar Backups Opción para realizar copias de seguridad
CU021 Restaurar BackupsEs la opción para restablecer una copia de seguridad a la configuración del sistema
CU022 Crear CambioCrear un registro en el que se documenten los cambios del sistema
CU023 Cerrar CambioCerrar el registro creado asociado a un cambio en la plataforma
CU024Documentar Cambio
Actualizar la información asociada a un cambio
CU025 Listar CambiosConsulta y muestra el total de cambios abiertos del sistema.
CU026 Abrir IncidenteLa aplicación debe realizar esta tarea en caso de presentarse una interrupción de algún servicio.
CU027 Listar IncidentesOpción para consultar los incidentes abiertos
100
IDENTIFICADOR
NOMBRE DESCRIPCIÓN
CU028 Cerrar IncidentesLa aplicación y los usuarios pueden cerrar incidentes
CU029Actualizar Incidente
Tarea con la que se pueden documentar los incidentes
CU030 Registrar EventoLa aplicación guarda la evidencia de los eventos
CU031Definir parámetros aplicación
Acción con la que se configuran los parámetros de la PBX al cual se va a conectar, así como el servidor smtp, Base de Datos y servidor Asterisk integrado con la aplicación
CU032Aplicar configuración
Acción con las que se aplican los cambios de configuración realizados en la plataforma.
CU033Crear Reporte Automático
Acción por la que se configura la ejecución de un reporte de manera periódica.
CU034Editar Reporte Automático
Es la opción de modificar la ejecución periódica de un reporte.
CU035Listar Reporte Automático
Es la opción de listar los reportes automáticos configurados
CU036Habilitar Reporte Automático
Es la opción de habilitar los reportes automáticos configurados y deshabilitados.
CU037Deshabilitar Reporte Automático
Es la opción de deshabilitar los reportes automáticos configurados y habilitados
CU038Borrar Reporte Automático
Es la opción de borrar la ejecución periódica de un reporte.
CU039Ejecutar Reporte automático
Es la opción de ejecutar el reporte
CU040Generar Reporte manual
Se utiliza en caso de requerir un reporte deestado de IVR no automático.
CU041 Exportar ReporteGenerar un archivo exportable que contiene un reporte
CU042 Enviar ReporteEnviar por correo electrónico el reporte generado
CU043 Notificar EventoEnviar una notificación por correo electrónico, ventana emergente o reproducir sonido
CU44 Actualizar Monitores
Cada vez que se ejecute se actualiza la información que despliegan los monitores
Tabla 8.6 Casos de Uso
101
• Identificación de actores del sistema
Actor Operador AC01Descripción Este actor está asociado al perfil del usuario operador cuya
función dentro de la aplicación es custodiar la operación del sistema, tomar medidas ante las alertas, documentar incidentes yabrir cambios.
Características Opciones de consulta dentro de la aplicaciónRelaciones AdministradorReferencias CU001, CU014, CU027, CU029, CU033, CU034, CU040, CU041,
CU009, CU035, CU036, CU011, CU028Autor Diego López
Rafael MoralesFecha 04-06-
2014Versión 1.0
Tabla 8.7 Actor del sistema Operador
Actor Administrador AC02Descripción Actor asociado al perfil administrador que tiene la opción de
configurar todos los parámetros de la aplicaciónCaracterísticas Además de sus propias funciones, puede ejecutar también las de
operadorRelaciones OperadorReferencias CU005, CU002, CU003, CU004, CU006, CU007, CU015, CU025,
CU016, CU032, CU021, CU022, CU023, CU024, CU031, CU012, CU013
Autor Diego LópezRafael Morales
Fecha 04-06-2014
Versión 1.0
Tabla 8.8 Actor del sistema Administrador
Actor Monitor AC03Descripción Es el actor que realiza las tareas automáticas referentes al
monitoreo de los IVRCaracterísticas No está asociado a ningún usuarioRelaciones ninguna
ReferenciasCU011, CU017, CU018, CU044, CU039
Autor Diego LópezRafael Morales
Fecha 04-06-2014
Versión 1.0
Tabla 8.9 Actor del sistema Monitor
102
Figura 8.4 Diagrama de Casos de Uso
103
Para revisar la especificación detallada, consultar la sección de éstedocumento: Anexo B, Especificación de Casos de Uso.
• Análisis de Requisitos
• Validación de Requisitos
Para éstas dos tareas, se muestra la siguiente tabla:
Requerimiento Funcionales
Ca
sos d
e Uso
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
01 X X X
02 X X X
03 X X
04 X X
05 X
06 X X X
07 X X X
08 X X
09 X X
10 X X
11 X X
12 X
13 X
14 X
15 X
16 X
17 X
18 X
19 X X
20 X X
21
22 X X
23 X X
24 X X
25 X X
104
Requerimiento Funcionales
Ca
sos d
e Uso
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
26 X X
27 X
28 X X X
29 X X
30 X
31 X X X X
32 X
33 X
34 X X
35 X
36 X X
37 X X
38 X
39 X
40 X X
41 X X
42 X
43 X
44 X
Tabla 8.10 Matriz Casos de Uso vs Requerimientos Funcionales
8.3.2.2.3 ASI 3 - Identificación de Subsistemas de Análisis
• Determinación de Subsistemas de Análisis
• Integración de Subsistemas de Análisis
La realización de ésta tarea se lleva a cabo en paralelo con el análisis derequerimientos y casos de uso efectuado en la tarea ASI2. Así mismo es definidaen la sección 3.2 de éste documento: Objetivos Específicos.
105
8.3.2.2.4 ASI 4 - Análisis de Casos de Uso
• Identificación de Clases Asociadas a un Caso de Uso
En las sesiones de trabajo se identificaron los siguientes objetos como candidatosa clases:
• Usuario.
• Centinela
• CI
• Reporte
• Alarma
• Estado
• Incidente
• Cambio
• Test
• Descripción de la Interacción de Objetos
Los objetos descritos en el numeral anterior interactúan de la siguiente forma:
• El CI es un objeto que representa el IVR
• Test es la tarea que ejecuta el centinela para identificar los estados del CI
• Los centinelas vigilan a los CI's por medio de test.
• Estado es el resultado del análisis del comportamiento de un CI
106
• Alarma es el cambio de estado de un CI
• Reporte es el historial de cambios de estado de un CI
• Incidente es la documentación del cambio de estado de un CI
• Cambio es la documentación por modificaciones realizadas sobre el CI ola aplicación.
8.3.2.2.5 ASI 5 - Análisis de Clases
• Identificación de Responsabilidades y Atributos
• Identificación de Asociaciones y Agregaciones
• Identificación de Generalizaciones
Gran parte de las responsabilidades, atributos, asociaciones y generalizaciones delas clases en la aplicación, fueron identificadas con la realización del modeloentidad-relación. Ver Anexo D.
8.3.2.2.6 ASI 6 - Definición de Interfaces de Usuario
• Especificación de Principios Generales de la Interfaz
• Se define una interfaz limpia que sea cómoda a la vista y fácil de navegar.
• Los colores usados permiten una fácil y cómoda visualización de lasalarmas.
• Los iconos usados permiten una fácil identificación de los módulos de laaplicación.
107
• Todas las pantallas tienen opciones que permitan navegar entre losmódulos de la aplicación, facilitando dicha navegación.
• Especificación de Formatos Individuales de la Interfaz de Pantalla
A continuación se presenta el bosquejo del diseño de las dos pantallas principalesde la aplicación, a partir de ellas se diseñaron las demás pantallas:
Figura 8.5 Diseño página de Inicio de la aplicación
Figura 8.6 Diseño página de generación de reportes de la aplicación 13
13 Para la renderización de la gráfica tipo torta se uso hightcharts. Mas información en el link http://www.highcharts.com/
108
• Especificación del Comportamiento Dinámico de la Interfaz
La interfaz principal de la aplicación (inicio o home) muestra el estado actual de losIVR monitoreados, lo que conlleva a que se actualice automáticamente con cadanuevo estado reportado por los diferentes centinelas. Para que pueda actualizarseautomáticamente, usa un mecanismo de refresco (javascript) y a su vez usa unajax que le permite al operador que se encuentra visualizando la aplicación, ver elregistro detallado de cada ejecución de un centinela, así como de los testrealizados por dicho centinela.
• Especificación de Formatos de Impresión
No Aplica.
8.3.2.2.7 ASI 7 - Análisis de Consistencia
• Verificación de los Modelos
• Análisis de Consistencia entre Modelos
• Validación de los Modelos
La ejecución de las tareas Verificación y Análisis de Modelos se realizó enconjunto con el Director y los autores de éste proyecto. La tarea de Validación fueejecutada por los autores quienes en su rol de desarrolladores realizaron larespectiva lista de chequeo de las funciones creadas en cada una de las versionesque se crearon de la aplicación.
• Elaboración de la Especificación de Requisitos Software (ERS)
Para revisar la especificación detallada, consultar la sección de éste documento:Anexo A, Especificación de Requerimientos.
109
110
8.3.2.2.8 ASI 8 - Especificación para Plan de Pruebas
• Definición del Alcance de las Pruebas
Por el modelo en el que se encuentra basado el desarrollo de la aplicación(modelo vista-controlador) no se realizaran pruebas unitarias sobre las clases yaque en el desarrollo no se encuentran clases independientes. En cambio, estabasada en el uso de controladores que interactúan con el modelo (base de datos)y generan una vista que interactúa con el usuario final.
Tendiendo en cuenta ésta razón, las pruebas que se ejecutaran son las pruebasfuncionales.
• Definición de Requisitos del Entorno de Pruebas
Las pruebas se ejecutaran sobre la misma plataforma en la que se encuentrainstalada la aplicación, haciendo uso del entorno de pruebas del frameworkSymfony; que a su vez, usa el framework independiente PHPUnit 14
Por demás, los recursos de hardware y software usados para el desarrollo y laejecución de las pruebas de software, son los enunciados en el numeral 7.1.4 -Instrumentos y Equipos.
• Definición de las Pruebas de Aceptación del Sistema
Por último, las pruebas de aceptación del software, serán ejecutadas por losautores de este proyecto en conjunto con el Director del mismo, quienes en unasesión de trabajo evaluaran el cumplimiento de los requerimientos definidos en elpresente documento.
14 Documentación oficial del framework en la URL: https://phpunit.de/
111
8.3.2.2.9 ASI 9 - Presentación y Aprobación del Análisis
• Presentación y Aprobación del Análisis del Sistema de Información
Se realiza reunión con los autores y el director del proyecto en donde se exponenlas pruebas realizadas sobre la aplicación y los resultados obtenidos. Así mismo,se compara con los criterios de aceptación definidos en el plan de pruebas. Luegode ésta reunión, se establece que la aplicación satisface los requerimientosestablecidos en el presente documento.
8.3.2.3 Diseño del sistema (DSI)
8.3.2.3.1 DSI 1 - Definición de la Arquitectura del Sistema
• Definición de Niveles de Arquitectura
El siguiente diagrama ilustra el particionamiento físico de la solución:
112
Figura 8.7 Particionamiento físico
• Identificación de Requisitos de Diseño y Construcción
Se define el siguiente catálogo de requisitos:
Catálogo de Requisitos
1 El sistema no cuenta con restricción de usuarios.
2 El sistema cuenta con un periodo de inactividad que al cumplirse, desloguea alusuario.
3 La aplicación WEB está diseñada para que se pueda acceder desde cualquiernavegador. Se recomienda tener instalada la versión mas reciente.
Tabla 8.11 Catálogo de requisitos
• Especificación de Excepciones
Se define el siguiente catálogo de excepciones:
113
SentinelIVR
PBX (IVR)
Troncal SIP
Usuario
Catálogo de Excepciones
1 Fallo de conexión entre la central telefónica donde está el IVR y el servidor dondese instalará la aplicación. No se establecerá la troncal SIP entre los dos servidores.
2 Fallo de conexión entre los usuarios y el servidor donde se encuentra alojada laaplicación. No permitirá acceder a ella.
3 Fallo en el navegador web desde el equipo donde accede el usuario. No permitiráacceder a la aplicación
4 Fallo en el motor de Base de Datos del servidor donde se encuentra alojada laaplicación. No permitirá acceder a la aplicación
5 Fallo en el servicio web del servidor donde se encuentra alojada la aplicación. Nopermitirá acceder a la aplicación
6 Fallo en el servicio asociado a la central telefónica (Asterisk) del servidor donde seencuentra alojada la aplicación. No permitirá realizar llamadas hacia el IVR.
Tabla 8.12 Catálogo de Excepciones
• Especificación de Estándares y Normas de Diseño y Construcción
Para el desarrollo de la aplicación se usó el framework de Symfony que sigue losestándares definidos en los siguientes documentos :
• PSR-0
• PSR-1
• PSR-2
• PSR-415
• Identificación de Subsistemas de Diseño
A continuación se relaciona los subsistemas involucrados:
15 Para Información detallada de los estándares, consultar la siguiente URL: http://www.php-fig.org/psr/
114
Figura 8.8 Diagrama de Estructura de alto nivel
En la siguiente matriz se detalla la ubicación de los subsistemas anodos.
Subsistema Nodo
1 SentinelIVRPBX (IVR)
2 SentinelIVR
3 Usuario
Tabla 8.13 Ubicación subsistemas - nodos
• Especificación del Entorno Tecnológico
Los requisitos se dividen en 3:
• Requisitos de Software:
• un servidor con SO Linux (Distribución Centos)
115
Sentinel
1Servicios
de Telefonía
2Servicios
de Aplicación
3GestiónUsuarios
BD
• Lenguaje de Programación PHP versión 5,4 o superior.
• Servidor web Apache 2.2.15 o superior
• Motor de Base de Datos PostgreSQL 1.8 o superior
• Framework de Desarrollo Symfony 2.3
• Asterisk 11.8.1
• Requisitos de Hardware (mínimos):
• Dos servidores con 2GB de ram , 20 GB de disco y un procesador(físico o virtual) a 2.3 Ghz.
• 1 estación de de trabajo con 1GB de ram, 40 G B de disco y unprocesador a 1.8Ghz.
• Requisitos de Comunicaciones (mínimos):
• Red LAN a 100 mbps
• Un equipo de comunicaciones (switch) que interconectará losequipos.
• Canal de Internet con 1M de ancho de banda para la instalación,
El detalle de éstos requisitos se encuentra en la sección de éste documento:6.2.2.4 Arquitectura y 7.2.2 Herramientas a Utilizar.
• Especificación de Requisitos de Operación y Seguridad
Para revisar la especificación detallada, consultar la sección de éste documento:Anexo B, Manuales y Procedimientos.
116
8.3.2.3.2 DSI 2 - Diseño de la Arquitectura de Soporte
• Diseño de Subsistemas de Soporte
Los componentes de soporte de interacción con la BD, validación y seguridadestán contemplados dentro del framework escogido para el desarrollo, por lo queno se tendrán que diseñar.
• Identificación de Mecanismos Genéricos de Diseño
Al igual que los subsistemas de soporte, los mecanismos genéricos de control dediseño vienen integrados en el framework utilizado para el desarrollo de laaplicación.
8.3.2.3.3 DSI 3 - Diseño de Casos de Uso
• Identificación de Clases Asociadas a un Caso de Uso
• Diseño de la Realización de los casos de Uso
• Revisión de la Interfaz de Usuario
• Revisión de Subsistemas de Diseño e Interfaces
A partir del análisis y diseño del modelo Entidad-Relación se identifican la mayoríade las clases, atributos, métodos y relaciones finales que se plasman en eldiagrama de clases.
Éstas actividades fueron realizadas en paralelo con el diseño del modelo de datos,representado con el diagrama entidad-relación extendido (Figura 8.9) ,indispensable para realizar el análisis de clase.
117
Figura 8.9 Diagrama de Entidad – Relación (en el Anexo D se encuentra detalladoéste diagrama)
8.3.2.3.4 DSI 4 - Diseño de Clases
• Identificación de Clases Adicionales
• Diseño de Asociaciones y Agregaciones
• Identificación de Atributos de las Clases
• Identificación de Operaciones de las Clases
• Diseño de la Jerarquía
• Descripción de Métodos de las Operaciones
• Especificación de Necesidades de Migración y Carga Inicial de Datos
118
Éstas actividades se realizaron para diseñar el diagrama de clases (Figura 8.10)que se relaciona a continuación
Figura 8.10 Diagrama de Clases (en el Anexo E se encuentra detallado éste
diagrama)
8.3.2.3.5 DSI 5 - Diseño Físico de Datos
• Diseño del Modelo Físico de Datos
• Especificación de los Caminos de Acceso a los Datos
• Optimización del Modelo Físico de Datos
• Especificación de la Distribución de Datos
119
Toda la manipulación de datos y la interacción entre la aplicación con la base dedatos, la administra Symfony por medio del componente Doctrine. 16
8.3.2.3.6 DSI 6 - Verificación y Aceptación de la Arquitectura del Sistema
• Verificación de las Especificaciones de Diseño
• Análisis de Consistencia de las Especificaciones de Diseño
• Aceptación de la Arquitectura del Sistema
Estas actividades se llevaron a cabo en varias sesiones de trabajo en las que serefinaron los modelos y se realizaron los ajustes pertinentes.
8.3.2.3.7 DSI 7 - Generación de Especificaciones de Construcción
• Especificación del Entorno de Construcción
• Definición de Componentes y Subsistemas de Construcción
• Elaboración de Especificaciones de Construcción
• Elaboración de Especificaciones del Modelo Físico de Datos
Para revisar el detalle de éstos procesos, consultar las siguientes secciones deéste documento: sección 6.2.1, Infraestructura de Comunicaciones. 6.2.2,Desarrollo, 7.1.4 Instrumentos y Equipos.
16 Para mas detalle, favor diríjase a la siguiente URL: http://symfony.com/doc/current/book/doctrine.html
120
8.3.2.3.8 DSI 8 - Diseño de Migración y Carga Inicial de datos
• Especificación del Entorno de Migración
• Diseño de Procedimientos de Migración y Carga Inicial
• Diseño Detallado de Componentes de Migración y Carga Inicial
• Revisión de la Planificación de la Migración
Según la definición de Métrica, no se requiere que se ejecute ésta actividad si noes necesaria una carga inicia del información o una migración de otros sistemas.
8.3.2.3.9 DSI 9 - Especificación Técnica del Plan de Pruebas
• Especificación Técnica de Niveles de Prueba
De acuerdo a las pruebas a ejecutar establecidas en la tarea ASI 8, se definenlos casos de prueba que se realizarán así:
• Pruebas funcionales
CP001
Objetivo Probar la creación de usuarios en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar nuevo usuario en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta usuario_crearIngresar los datos de prueba en formularioHacer submit del formularioComprobar en la redirección de la pagina que el usuarionuevo esté en el listado
Tabla 8.14 Caso de prueba CP001: creación de Usuario
121
CP002
Objetivo Probar el borrado de usuarios en el sistema
Entrada Usuario de prueba
Salida Registro borrado de BD, el usuario deja de estar enlistado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta usuario_listadoEjecutar la acción “eliminar” del usuario de pruebaverificar en la redirección de la pagina que el usuario deprueba ya no esté en el listado
Tabla 8.15 Caso de prueba CP002: borrado de Usuario
CP003
Objetivo Probar la creación de centinelas en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar nuevo centinela en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta centinela_crearIngresar los datos de prueba en formularioverificar en la redirección de la pagina que el centinelade prueba nuevo esté en el listado
Tabla 8.16 Caso de prueba CP003: creación de Centinela
122
CP004
Objetivo Probar el borrado de centinelas en el sistema
Entrada Centinela de prueba
Salida Registro borrado de BD, el centinela deja de estar enlistado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta centinela_listadoEjecutar la acción “eliminar” del centinela de pruebaverificar en la redirección de la pagina que el centinelade prueba ya no esté en el listado
Tabla 8.17 Caso de prueba CP004: borrado de Centinela
CP005
Objetivo Probar la creación de CI en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar CI en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta ci_crearIngresar los datos de prueba en formularioverificar en la redirección de la pagina que el CI nuevoesté en el listado
Tabla 8.18 Caso de prueba CP005: creación de CI
123
CP006
Objetivo Probar el borrado de CI en el sistema
Entrada CI de prueba
Salida Registro borrado de BD, el CI deja de estar en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta ci_listadoEjecutar la acción “eliminar” del centinela de pruebaverificar en la redirección de la pagina que el CI deprueba ya no esté en el listado
Tabla 8.19 Caso de prueba CP006: borrado de CI
CP007
Objetivo Probar la creación de cambios en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar cambio en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta cambio_crearIngresar los datos de prueba en formularioverificar en la redirección de la pagina que el cambionuevo esté en el listado
Tabla 8.20 Caso de prueba CP007: creación de cambios
124
CP008
Objetivo Probar el cambio de estado de cambio en el sistema
Entrada Cambio de prueba
Salida Registro modificado de BD, el atributo “estado” debecambiar a “cerrado”
Condiciones Ninguna
Procedimiento Hacer un request de la ruta cambio_listadoEjecutar la acción “cerrar” del cambio de pruebaverificar en la redirección de la pagina que el cambio deprueba no esté en el listado
Tabla 8.21 Caso de prueba CP008: cambio de estado de cambios
CP009
Objetivo Probar la creación manual de incidentes en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar incidente en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta incidente_crearIngresar los datos de prueba en formularioverificar en la redirección de la pagina que el incidentenuevo esté en el listado
Tabla 8.22 Caso de prueba CP009: creación manual de incidentes
125
CP010
Objetivo Probar el cambio de estado de incidentes en el sistema
Entrada Incidente de prueba
Salida Registro modificado de BD, el atributo “estado” debecambiar a “cerrado”
Condiciones Ninguna
Procedimiento Hacer un request de la ruta incidente_listadoEjecutar la acción “cerrar” del incidente de pruebaverificar en la redirección de la pagina que el incidentede prueba no esté en el listado
Tabla 8.23 Caso de prueba CP010: cambio de estado de incidentes
CP011
Objetivo Probar la creación de reportes automáticos en el sistema
Entrada Datos de prueba
Salida Registro en BD, mostrar reporte en listado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta repo_auto_crearIngresar los datos de prueba en formularioverificar en la redirección de la pagina que el reportenuevo esté en el listado
Tabla 8.24 Caso de prueba CP011: creación reportes automáticos
126
CP012
Objetivo Probar el borrado de reportes automáticos en el sistema
Entrada Reporte de prueba
Salida Registro borrado de BD, el reporte deja de estar enlistado.
Condiciones Ninguna
Procedimiento Hacer un request de la ruta repo_auto_listadoEjecutar la acción “eliminar” del reporte de pruebaverificar en la redirección de la pagina que el reporte deprueba ya no esté en el listado
Tabla 8.25 Caso de prueba CP012: borrado de reportes automáticos
Las pruebas anteriormente definidas, requieren todas realización deautenticación, por lo que no se creará un caso de prueba específico para estecaso de uso
• Pruebas del sistema
CP013
Objetivo Probar la ejecución de un centinela en el sistema,generando las condiciones para que el IVR se muestreen estado “En Servicio” (Color verde)
Entrada Centinela, CI,
Salida Nuevo estado asociado al CISi el estado anterior del CI es diferente de “En Servicio”,se debe notificar de su normalización y cerrar losincidentes que tenga asociados, estas acciones lasrealiza la aplicación de manera automática
Condiciones • Todos los servidores del sistema deben estaroperativos
• El CI debe representar al árbol real de IVR• En caso de presentar falla en alguno de sus
nodos, este debe estar definido con el umbral“criticidad baja”
Procedimiento • Consultar el listado de centinelas• Ejecutar de manera manual el centinela
127
CP013
• verificar la creación de un nuevo estado “Enservicio” asociado al CI y asegurarse de que semuestre en la interfaz de monitores
• Comprobar que no se abre alerta, incidente ninotificación por esta prueba
• Si existen incidentes asociados al CI, estos debencerrarse de manera automática
Tabla 8.26 Caso de prueba CP013: Ejecución de un centinela en el sistema para estado EnServicio
CP014
Objetivo Probar la ejecución de un centinela en el sistema,generando las condiciones para que el IVR se muestreen estado “Servicio Degradado” (Color amarillo)
Entrada Centinela, CI,
Salida Nuevo estado asociado al CISi el estado anterior del CI es diferente de “ServicioDegradado”, se debe notificar de esta situaciónAbrir incidente asociado al IVREnviar notificación si está definida
Condiciones • Todos los servidores del sistema deben estaroperativos
• El CI debe representar al árbol real de IVR• Se debe generar las condiciones para que existan
nodos con umbral “criticidad media” que no esténdisponibles
Procedimiento • Consultar el listado de centinelas• Ejecutar de manera manual el centinela• verificar la creación de un nuevo estado “Servicio
Degradado” asociado al CI y asegurarse de quese muestre en la interfaz de monitores
• Comprobar que se abre alerta, incidente y seenvía notificación por esta prueba
Tabla 8.27 Caso de prueba CP014: Ejecución de un centinela en el sistema para estado ServicioDegradado
128
CP015
Objetivo Probar la ejecución de un centinela en el sistema,generando las condiciones para que el IVR se muestreen estado “Fuera de Servicio” (Color rojo)
Entrada Centinela, CI,
Salida Nuevo estado asociado al CISi el estado anterior del CI es diferente de “Fuera deServicio”, se debe notificar de esta situaciónAbrir incidente asociado al IVREnviar notificación si está definida
Condiciones • Todos los servidores del sistema deben estaroperativos
• El CI debe representar al árbol real de IVR• Se debe generar las condiciones para que existan
nodos con umbral “criticidad alta” que no esténdisponibles
Procedimiento • Consultar el listado de centinelas• Ejecutar de manera manual el centinela• verificar la creación de un nuevo estado “Fuera
de Servicio” asociado al CI y asegurarse de quese muestre en la interfaz de monitores
• Comprobar que se abre alerta, incidente y seenvía notificación por esta prueba
Tabla 8.28 Caso de prueba CP015: Ejecución de un centinela en el sistema para estado Fuerade Servicio
• Pruebas de aceptación
Este nivel de pruebas, consiste en la validación en general del cumplimientopor parte del sistema desarrollado de los requerimientos funcionales y nofuncionales definidos y especificados en el presente documento.
El objetivo es verificar con pruebas de caja negra, la respuesta de laaplicación a las pruebas realizadas a través de la Interface y así obtener laaceptación final del sistema por parte del cliente, cuyo rol está de algunaforma asumido por el Director de proyecto.
129
• Revisión de la Planificación de Pruebas
En esta tarea culmina la especificación del plan de pruebas, determinando losniveles de prueba, las condiciones de validación de cada una y quedan listos loscasos para ser ejecutados y así finalmente dar aceptación al software.
8.3.2.3.10 DSI 10 - Establecimiento de Requisitos de Implantación
• Especificación de Requisitos de Documentación de Usuario
• Especificación de Requisitos de Implantación
Aunque el alcance de éste proyecto no contempla la implementación en unambiente real, se generan los respectivos manuales de operación en casohipotético de que se llegue a implementar. Para revisar el detalle de éstosdocumentos, consultar la sección de éste documento : Anexo F, Manuales yProcedimientos.
8.3.2.3.11 DSI 11 - Aprobación del Diseño del Sistema
• Presentación y Aprobación del Diseño del Sistema de Información
En sesiones de trabajo realizadas en conjunto con el Director de proyecto, seaprueba el diseño del sistema.
8.3.2.4 Construcción del sistema (CSI)
8.3.2.4.1 CSI 1 - Preparación del Entorno de Generación y Construcción
• Implantación de la Base de Datos Física o Ficheros
130
• Preparación del Entorno de Construcción
La BD generada para éste proyecto se llama pixqui_db y se entrega en formatodigital con todos los entregables, incluido el presente documento.
En cuanto a la preparación del ambiente, se procede a realizar la instalación yvalidación de los requerimientos de operación de Symfony. 17
17 Para mas detalle, favor diríjase a la siguiente URL: http://symfony.com/doc/current/reference/requirements.html
131
Figura 8.11 Validación de Requerimientos para la construcción del Software.
132
8.3.2.4.2 CSI 2 - Generación del Código de los Componentes y Procedimientos
• Generación del Código de Componentes
• Generación del Código de los Procedimientos de Operación y Seguridad
El código fuente se entrega en formato digital con todos los entregables, incluido elpresente documento.
8.3.2.4.3 CSI 3 - Ejecución de las Pruebas Unitarias
8.3.2.4.4 CSI 4 - Ejecución de las Pruebas de Integración
• Preparación del Entorno de Pruebas Unitarias y de Integración
• Realización y evaluación de las Pruebas Unitarias y de Integración
De acuerdo a la definición presentada en la especificación del plan de pruebas, laspruebas unitarias y de integración, serían reemplazadas por pruebas funcionalesque recogen la funcionalidad de las clases y su integración para dar forma a laaplicación del modelo vista-controlador
• Preparación del Entorno de Pruebas Funcionales
Dado que el entorno de pruebas en cuanto a recursos, es el mismo usadopara el desarrollo de la aplicación, no se considera necesaria sudocumentación en esta actividad, dado que ya se ha documentado en elpresente documento.
• Realización y evaluación de las Pruebas Funcionales
El objetivo de esta tarea es llevar a cabo la construcción de las clases Testque probaran los casos de prueba definidos en el plan de pruebas, suposterior ejecución y validación de resultados. En caso de que algunaprueba arroje fallo, se corrigen las clases probadas hasta que se obtenganresultado correcto y pasar a la siguiente.
133
Toda la codificación de las pruebas construidas en esta actividad, será entregadajunto con el código fuente del sistema como anexo físico a este documento.
Resultado de ejecución de pruebas
Prueba Caso de Uso Resultado
CP001 CU001, CU002, CU004, CU005
Correcto
CP002 CU001, CU003, CU004, CU005
Correcto
CP003 CU001, CU006, CU007, CU009, CU0010
Correcto
CP004 CU001, CU007, CU008, CU009, CU0010
Correcto
CP005 CU001, CU012 Correcto
CP006 CU001, CU013 Correcto
CP007 CU001, CU022, CU024, CU025
Correcto
CP008 CU001, CU023, CU024, CU025
Correcto
CP009 CU001, CU026, CU027, CU029
Correcto
CP010 CU001, CU027, CU028, CU029
Correcto
CP011 CU001, CU033, CU035 Correcto
CP012 CU001, CU035, CU028 Correcto
Tabla 8.29 Resultado de ejecución de Pruebas Funcionales
134
8.3.2.4.5 CSI 5 - Ejecución de las Pruebas del Sistema
• Preparación del Entorno de las Pruebas del Sistema
Dado que el entorno de pruebas en cuanto a recursos, es el mismousado para el desarrollo de la aplicación, no se considera necesaria sudocumentación en esta actividad, dado que ya se ha documentado en elpresente documento.
• Realización de las Pruebas del Sistema
• Evaluación del Resultado de las Pruebas del Sistema
El objetivo de estas tareas es usar la aplicación para probarla a través de pruebasde caja negra y analizar el comportamiento de cada una de sus funciones, evaluarel resultado de cada ejecución y validar el cumplimiento adecuado de losrequerimientos.
Resultado de ejecución de pruebas
Prueba Caso de Uso Resultado
CP013 CU001, CU011, CU014, CU017, CU018, CU019, CU026, CU030, CU043, CU044
Correcto
CP014 CU001, CU011, CU014, CU017, CU018, CU019, CU026, CU030, CU043, CU044
Correcto
CP015 CU001, CU011, CU014, CU017, CU018, CU019, CU026, CU030, CU043, CU044
Correcto
Tabla 8.30 Resultado de ejecución de Pruebas del Sistema
135
8.3.2.4.6 CSI 6 - Elaboración de los Manuales de Usuario
• Elaboración de los Manuales de Usuario
Para revisar el detalle de éstos procesos, consultar la siguiente sección de éstedocumento: Anexo F, Manuales y Procedimientos.
8.3.2.4.7 CSI 7 - Definición de la Formación de Usuarios Finales
• Definición del Esquema de Formación
• Especificación de los Recursos y Entornos de Formación
Aunque el alcance de éste proyecto no contempla la implementación en unambiente real, se generan los respectivos manuales de operación en casohipotético de que se llegue a implementar. Para revisar el detalle de éstosdocumentos, consultar la sección de éste documento : Anexo F, Manuales yProcedimientos.
8.3.2.4.8 CSI 8 - Construcción Componentes y Procedimientos de Migración yCarga Inicial de Datos
• Preparación del Entorno de Migración y Carga Inicial de Datos
• Generación del Código de los Componentes y Procedimientos de Migración yCarga Inicial de Datos
• Realización y Evaluación de las Pruebas de Migración y Carga Inicial de Datos
Según la definición de Métrica, no se requiere que se ejecute ésta actividad si noes necesaria una carga inicia del información o una migración de otros sistemas.
136
8.3.2.4.9 CSI 9 - Aprobación del Sistema
• Presentación y Aprobación del Sistema de Información
En sesiones de trabajo realizadas en conjunto con el Director de proyecto, seaprueba el diseño del sistema. Sin embargo, la aprobación del Sistema está acargo del revisor del proyecto asignado por la Universidad.
8.3.2.5 Implantación y aceptación del sistema (IAS)
8.3.2.5.1 IAS 1 - Establecimiento del Plan de Implantación
8.3.2.5.2 IAS 2 - Formación Necesaria para la Implantación
8.3.2.5.3 IAS 3 - Incorporación del Sistema a Entorno de Operación
8.3.2.5.4 IAS 4 - Carga de Datos a Entorno de Operación
8.3.2.5.5 IAS 5 - Pruebas de Implantación de Sistema
8.3.2.5.6 IAS 6 - Pruebas de Aceptación del Sistema
8.3.2.5.7 IAS 7 - Preparación del Mantenimiento
8.3.2.5.8 IAS 8 - Establecimiento del Acuerdo de Nivel de Servicio
8.3.2.5.9 IAS 9 - Presentación y Aprobación de Sistema
8.3.2.5.10 IAS 10 - Paso a Producción
El alcance de éste proyecto no contempla la implementación en un ambiente real,por lo que éstas actividades no se desarrollarán.
137
8.3.3 Mantenimiento del SI
8.3.3.1 MSI 1 - Registro de la Petición
8.3.3.2 MSI 2 - Análisis de la Petición
8.3.3.3 MSI 3 - Preparación de la Implementación de la Modificación
8.3.3.4 MSI 4 - Seguimiento y Evaluación de los cambios Hasta la Aceptación
Por la misma razón del proceso anterior,éstas actividades no se desarrollarán.
8.4 Integración de la aplicación software con el Sistema de Voz el cual se va a monitorear.
8.4.1 Fase 1: Estrategia del Servicio
Se usa el lenguaje PHP para realizar el script y se usa el manager de Asterisk(AMI) como integración entre el algoritmo de marcado y el Asterisk.
8.4.2 Fase 2: Diseño
En ésta fase se verifica que se cuente con todas las variables necesarias pararealizar la marcación. Así mismo se verifican permisos y configuraciones en elmanager de ambos servidores para que los script se puedan conectar sininconvenientes.
138
Figura 8.12 Variables usadas en AMI
8.4.3 Fase 3: Transición
Se crean script's de prueba en los que se verifica la conexión exitosa con losmanager de los dos script. Se verifican LOGS de las conexiones para identificar lainformación relevante que necesita el software para operar.
139
Figura 8.13 Script de prueba para conexión al AMI.
8.4.4 Fase 4: Operación
Se generan los 2 script que se van a conectar a los respectivos AMI (AsteriskManager Interface). Se crea una función ValidarEstadoCanal que es la que seencarga, como su nombre lo dice, de verificar el estado del canal donde seestablece la llamada. Luego de definir la función, se abre la conexión por donde sevan a enviar y recibir los eventos.
Luego de abrir la conexión, se envía el el primer lote de sentencias que consisteen el logueo en el AMI (Asterisk Manager Interface) en los dos servidores. Cuandose valida que la conexión ha sido exitosa, se sigue con el envío de lote desentencias que de acuerdo al servidor, van a ser distintos.
Para la captura de eventos, se desarrolla un cliente TSAPI (Telephony ServerApplication Programming Interface) basado en PHP , que a través del AMI deasterisk permite capturar todos los eventos que están ocurriendo en éste. Elcliente captura los eventos por cada llamada y los inserta en la base de datos paraque la aplicación pueda validar el estado del IVR.
140
Éste cliente se instala en el mismo servidor donde se instala la aplicacióndesarrollada
Figura 8.14 Eventos recolectados por el cliente TSAPI
Adicionalmente, en la consola de Asterisk se puede evidenciar cadaevento durante la llamada:
Figura 8.15 Eventos visualizados en el servidor de telefonía remoto.
141
8.4.5 Fase 5: Mejora
Para ésta fase, se realiza una depuración y documentación del código parahacerlo más fácil de entender y más rápido en su tiempo de ejecución; evitandobugs que puedan comprometer el rendimiento de los equipos.
8.5 Publicación del Software bajo licencias GPL
El software se desarrollo en Software Libre que permite que otros desarrolladoresaccedan a él y puedan realizar modificaciones para que el producto sigamejorando con el paso del tiempo. Al encontrarse bajo esta condición, se hacemas accesible para que se pueda implementar en pequeñas y medianasempresas, con el fin de que puedan contar con un software completo que le brindeun servicio de calidad a un costo mucho menor del software privativo.
Esta publicación se realizó en la comunidad SourceForge como se evidencia en lasiguiente imagen:
142
Figura 8.16 Publicación del Software en la comunidad Sourceforge .
143
9. CONCLUSIONES
Como resultado del proyecto desarrollado, se tienen las siguientes conclusiones:
Se construyó una funcionalidad que realiza llamadas automáticas y envío de tonosDTMF por medio de Asterisk, para recorrer el árbol de opciones de un IVR
Se logró identificar por medio de dichas llamadas si la opción del IVR se encuentradisponible o no disponible.
Se logró desarrollar un cliente TSAPI en código php que se integra con el AsteriskManager Interface (AMI) para capturar los eventos que se presentan en unallamada telefónica.
Se logró que este cliente TSAPI insertara directamente sobre las Base de Datosde la aplicación para que la aplicación pueda procesarlos y así determinar elestado de la opción de un IVR.
Se logró desarrollar un modulo que capture la información filtrada del clienteTSAPI y la almacene en la BD para así conocer y generar un comportamientohistórico.
Se logró que estos comportamientos históricos pudieran ser visualizados por losusuarios en una forma gráfica (Monitor) y en una forma tabular (reporte), aunqueen el reporte también se puede visualizar en forma de gráfica circular, elcomportamiento del IVR.
Se logró desarrollar un módulo de usuarios que permite distinguir los permisosentre un usuario Operador y un usuario Administrador.
Se logró que el usuario Administrador tuviera control total sobre los usuarios,permitiéndole: habilitar, deshabilitar, adicionar, eliminar y editar atributos ( como elnombre de usuario o contraseña).
Se logró que el usuario con rol de Administrador pueda realizar la creación de CI's,así como crear extensiones y asociarlas a dichos CI's
144
Se logró que el usuario con rol de Administrador pueda realizar cambios en losvalores de la plataforma, como el servidor de correo, el servidor de telefoníaremoto o la base de datos, si así lo requiere.
Se logró que el usuario operador pueda interactúar con el estado del IVR pormedio de monitor, para ver los últimos 10 comportamientos de los IVR'sconfigurados. Así mismo, puede ejecutar los centinelas manualmente en caso deser necesario.
Se logró que el usuario administrador y operador puedan generar reporteshistóricos del comportamiento de un IVR y que dicho reporte se envíe por correoelectrónico.
Se liberó el código fuente de éste producto en la comunidad SourceForge, sepuede consultar en el siguiente link: http://sourceforge.net/projects/sentinelivr/
Con el diseño de ésta herramienta, se está dando respuesta a una necesidadlatente en las organizaciones que cuentan con sistemas automáticos deaudiorespuesta y es poder monitorear estos sistemas con el fin de ofrecer unmejor servicio y garantizar que el servicio ofrecido se encuentre disponible lamayor cantidad de tiempo.
A pesar que este proyecto esta delimitado para Centrales telefónicas Asterisk, enel proceso del desarrollo se evidencio la posibilidad de poderlo integrar con otrascentrales, ya que el código es muy flexible y permite modificar su estructura paraadaptarse a lo que se necesite.
145
10. RECOMENDACIONES
Al liberar el código fuente de este producto, se busca que la herramienta crezca enfuncionalidades y que al estar disponible a nivel mundial, desarrolladores con masexperiencia puedan examinarlo y corregir las fallas que pueda tener .
La aplicación, en caso de implementarse, podría acoplarse a otras centralestelefónicas privativas lo cual la haría más robusta y mas accequible a nivelempresarial
Crecimiento horizontal y vertical: el producto está enfocado en el monitoreo aIVRs, sin embargo, eventualmente podría expandir su capacidad y alcance amonitorear otros componentes de infraestructura empresarial de TI. Así mismotambién está en la capacidad de adquirir nuevas funcionalidades ajenas almonitoreo, esto es por ejemplo, administración de plataforma tecnológica, gestiónde configuraciones, correlación de eventos, adopción de otras características ITIL,entre otras.
146
11. BIBLIOGRAFIA Y REFERENCIAS ELECTRÓNICAS
1.Rochelle E. Evans, Philip Kortum. The impact of voice characteristics on user
response in an interactive voice response system. En: Science Direct. 2010. 606 p.
2. S. Luján M, Historia, principios básicos y clientes Web. España: Editorial club
universitario. En: Programación de aplicaciones Web. 2002. p. 48-55.
3. DreamPBX. Ediciones de DreamPBX. Caracteristicas Bogotá, Col. En:
http://www.dreampbx.com/es/caracteristicas/ediciones/
4. Manage Engine. VQ Manager: Software de monitoreo de la calidad. En:
http://www.manageengine.com.mx/products/vqmanager/vqmanager-supported-
devices.html
5. Pandora FMS. Sistema de monitorización flexible. En :
http://pandorafms.org/index.php? sec=project&sec2=home&lng=es
6. Nagios. The Industry Starndard in IT Infraestructure Monitoring. En:
http://www. nagios .org/
7. Abast. Grup Business Availability Center. En:
http://www.abast.es/hp _ business_availability_center_bac.shtml
147
8. Hewlett-Packard. (2011). Business Process Monitor Software. En:
http://www8.hp.com/us/en/software/software-product. html? compURI =tcm:245-
936118
9. Escuela Superior Politécnica del Litoral. Ecuador. Monitoreo de
Sistemas VOIP Usando Software Libre. (2011) En:
http://www.dspace.espol.edu.ec/bitstream/123456789/15830/3/Exposicion.pptx
10. Asterisk. En: http://es.wikipedia.org/wiki/Asterisk
11. HUIDOBRO Moya, José Manuel, CONESA Pastor Rafael. VoIP y Telefonía
sobre IP. En: Sistemas de Telefonía. 5 edición. Editorial Paraninfo. 2006. p. 269.
12. D. Burke. Media Resource Control Protocol (MRCP). John Wiley and Sons. En:
Speech processing for IP networks 2007. P106.
13. JACKSON Ben, CLARK Champ. What is a PBX. En: Asterisk Hacking.
Syngress. 2007. p. 3
14. REGIS J. Bates, DONALD W. Gregory. Interactive Voice Response. En: Voice
and data communications handbook. 4 edicion.McGraw-Hill Professional, 2001.p
237.
15. BARBA MARTI Antoni, HESSELBACH SERRA Xavier. Sistemas de respuesta
vocal interactiva. En: Inteligencia de red. Edicions UPC. 2002. p 51
148
16. Wikipedida. Conversor Texto- Voz. (2012). En:
http :// es . wikipedia . org / wiki / Conversor _ texto - voz
17.MADSEN Leif, VAN MEGGELEN Jim, BRYANT Russell. Chapter 21: Asterisk
Gateway Interface (AGI). En: Asterisk: The Definitive Guide. O'reilly OFPS. 2011.
18.MADSEN Leif, VAN MEGGELEN Jim, BRYANT Russell. Chapter 20: Asterisk
Manager Interface (AMI). En: Asterisk: The Definitive Guide. O'reilly OFPS. 2011.
19.Wikipedia. Computer-supported telecommunications applications (2013). En:
http://en.wikipedia.org/wiki/Computer-supported_telecommunications_applications
20. F. L. Osorio R, Un inicio al desarrollo de software. Colombia: ITM. En: Lógica y
Programación Orientada a Objetos. 2008. p. 35-37.
21. Ministerio de Política Territorial y Administración Pública. (2001) Métrica V3.
En: linea/pdf]. Disponible: http://administracionelectronica.gob.es/?
_nfpb=true&_pageLabel=P60085901274201580632&langPae=es
22. Osiatis. ITIL V3. En: http :// itilv 3. osiatis . es / gestion _ servicios _ ti . php
149
12. ANEXOS
ANEXO A: Especificación de Requerimientos
Requerimientos Funcionales – Especificación
Requerimientos Funcionales del Módulo Usuarios
Identificador: RF001 Nombre: Autenticación
Tipo: Restricción Crítico: Si
Descripción: Se debe proporcionar una interfaz que permita realizar autenticación en laaplicación.
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCIONEl sistema debe proporcionar en primera instancia el campo para ingreso del nombre y
contraseña del usuario y así poder realizar las diferentes funciones que tendrá cada uno,dependiendo del tipo de usuario
ENTRADAS
Nombre de UsuarioContraseña
PROCESOS
Se debe validar que el usuario exista en la aplicaciónSe debe validar que la contraseña suministrada sea correcta para el usuario
Una vez autenticado, el sistema debe validar el tipo de usuario
SALIDASPresentar las opciones a las que el usuario tiene acceso según su rol
Mensaje de error en el caso de no haber llenado algún campoMensaje de error en el caso de ingresar un usuario no existente
Mensaje de error en casos de ingresar contraseña erradaBloqueo del usuario en caso de presentarse varios intentos fallidos para un mismo
usuario
Identificador: RF002 Nombre: Creación usuarios
Tipo: Requisito Crítico: Si
150
Descripción: Permitir la creación de usuarios administradores y operadores.
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Un usuario con rol administrador, puede crear usuarios administradores y operadorespara que tengan también acceso a la aplicación
ENTRADAS
Nombre de UsuarioContraseña
Rol
PROCESOSSe debe validar que el usuario no exista en la aplicación.
Se debe validar que la contraseña sea válida Se carga el nuevo usuario y sus datosal listado actual de usuarios validos de sistema
SALIDASMensaje de creación exitosa en caso de que se cumplan con los parámetros
necesariosMensaje de error en el caso de intentar crear un usuario existente
Mensaje de error en el caso de no haber llenado algún campo obligatorioMensaje de error en casos de ingresar contraseña no valida.
Identificador: RF003 Nombre: Borrado usuarios
Tipo: Restricción Crítico: No
Descripción: Permitir el borrado de usuarios administradores y operadores
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
El usuario administrador, puede borrar usuarios administradores y operadores para queno tengan acceso a la aplicación
ENTRADAS
Nombre de Usuario
151
PROCESOSSe debe validar que el usuario exista en la aplicaciónSe debe validar que no se trate de borrar a sí mismo
El usuario queda definitivamente borrado de la lista de usuarios validos del sistema
SALIDASMensaje de operación exitosa, en cuyo caso el usuario quedará borrado del sistema
Identificador: RF004 Nombre: Modificación Perfiles
Tipo: Restricción Crítico: No
Descripción: Permitir la modificación de los perfiles de usuarios para asignar o quitarprivilegios dentro de la herramienta.
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
El usuario administrador, puede modificar los roles de usuarios para alternar entreadministradores y operadores.
ENTRADAS
Nombre de UsuarioRol
PROCESOS
Modificar el rol del usuario en la aplicación
SALIDASMensaje de operación exitosa
Identificador: RF005 Nombre: Usuario Admin
Tipo: Requisito Crítico: No
Descripción: La aplicación deberá tener al menos 1 usuario Administrador
Prioridad: __Alta-Esencial __Media-Deseado _X_Baja-Opcional
INTRODUCCION
152
Desde el momento mismo de la instalación de la aplicación, quedará habilitado un usuario“admin” que servirá para realizar las primeras configuraciones.
ENTRADAS
No aplica
PROCESOSNo aplica
SALIDAS
No aplica
Requerimientos Funcionales del Módulo Monitor
Identificador: RF006 Nombre: Creación Centinela
Tipo: Restricción Crítico: Si
Descripción: Crear uno a varios Centinelas
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
El Centinela es el patrón de ejecución del monitoreo de un IVR que debe definir eladministrador al sistema y que le indica al mismo de qué forma se realizará la
comprobación sobre dicho IVR
ENTRADASCI asociado
Parámetros de ejecución del monitoreo del CI
PROCESOSEl sistema crea la forma de ejecución del monitoreo del IVR que posteriormente
realizará las llamadas automáticas
SALIDASMensaje de creación exitosa
153
Identificador: RF007 Nombre: Editar Centinela
Tipo: Restricción Crítico: Si
Descripción: La forma de ejecución puede ser modificada
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
La aplicación debe permitir modificar los centinelas para que se ajusten de acuerdo a lanecesidad en que se desean tener disponibles los IVR
ENTRADAS
Centinela a modificarseParámetros de ejecución del monitoreo del CI
PROCESOS
El sistema modifica la forma de ejecución del monitoreo del IVR que posteriormenterealizará las llamadas automáticas
SALIDAS
Mensaje de modificación exitosa.
Identificador: RF008 Nombre: Deshabilitar / Habilitar Centinela
Tipo: Restricción Crítico: Si
Descripción: La forma de ejecución puede ser deshabilitada o habilitada
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Los Centinelas creados pueden ser deshabilitados para evitar que hagan testeo al IVRtemporalmente o habilitarlos nuevamente de acuerdo a la necesidad del usuario.
ENTRADAS
Centinela
PROCESOSLa forma de ejecución no tiene modificaciones, pero debe quedar en estado
deshabilitado
SALIDASMensaje de operación exitosa
154
Identificador: RF009 Nombre: Borrar Centinela
Tipo: Restricción Crítico: Si
Descripción: Se pueden borrar las formas de ejecución
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
En caso de requerirse, la aplicación debe permitir la eliminación de los centinelascreados dentro del sistema.
ENTRADAS
Centinela
PROCESOSSe borra el centinela dentro de la base de datos.
SALIDAS
Mensaje de operación exitosa.
Identificador: RF010 Nombre: Periodicidad Centinela
Tipo: Restricción Crítico: Si
Descripción: Se deben poder definir intervalos de ejecución para cada Centinela
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
De ser necesario que el monitoreo del IVR se realice solo en algunas horas especificas deldía, la aplicación debe permitir programar el horario de ejecución.
ENTRADAS
CentinelaHorario en el que se desea la ejecución
PROCESOS
El sistema creara tareas para el centinela según programación
SALIDASMensaje de creación exitosa
155
Identificador: RF011 Nombre: Ejecutar Centinela
Tipo: Restricción Crítico: Si
Descripción: El centinela se pueden disparar manualmente en cualquier momento
Prioridad: __Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCIONEn caso de requerirse, se debe poder ordenar a la aplicación que ejecute inmediatamente
algún centinela.
ENTRADASCentinela
PROCESOS
La aplicación debe ejecutar el monitoreo correspondiente al centinela sin importar siestá o no en su horario de ejecución.
SALIDAS
Se debe mostrar el resultado de la ejecución una vez finalizada
Identificador: RF012 Nombre: Monitor IVR
Tipo: Restricción Crítico: Si
Descripción: Presentar gráficamente el estado actual e histórico de un IVR
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Se debe representar en todo momento el estado del IVR
ENTRADASResultado de los test realizados por los centinelas
PROCESOS
El sistema debe interpretar los resultados de los test
SALIDASRepresentación gráfica del estado del IVR
156
Identificador: RF013 Nombre: Umbrales
Tipo: Restricción Crítico: Si
Descripción: Definir umbrales de criticidad
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Al configurar los centinelas, que realizan el testeo del IVR, debe existir la posibilidad dedefinir para el IVR que tipo de eventos se consideran críticos, de advertencia o de
normalidad.
ENTRADASIVR
Criterios de alerta
PROCESOSEl sistema actualiza base de datos con los criterios definidos
SALIDAS
Mensaje de operación exitosa.
Identificador: RF014 Nombre: Interpretar Datos
Tipo: Restricción Crítico: Si
Descripción: Interpretar los datos del monitor constantemente para identificar si existecambio en el estado de un IVR
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Para determinar si existe un cambio en el estado de un IVR, se deben validar los datosrepresentados por el monitor contra los umbrales de criticidad definidos.
ENTRADAS
Resultado de testCriterios de alerta
PROCESOS
157
En base a los criterios de alerta y los datos que entregue el centinela, se debemodificar o no el estado del IVR
SALIDAS
Cambio en la representación del estado del IVRAlarma
Incidente (en caso de presentarse interrupción del servicio)
Identificador: RF015 Nombre: Alarmas
Tipo: Restricción Crítico: Si
Descripción: Generar alarmas en caso de presentarse una alteración del Servicio de IVR
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
Cuando un IVR pase al estado de Servicio Degradado, Fuera de Servicio o EstadoDesconocido, se debe generar una alarma representada directamente por el monitor del
IVR
ENTRADASEstado del IVR.
Umbrales de CriticidadPosición del árbol en donde se realiza el test
PROCESOS
Comprobar estados que recibe del Monitor para verificar si debe o no generaralarma.
SALIDAS
Modificar el estado del monitor indicando que se presenta una alarma.Indicarle a la aplicación que se debe notificar a los administradores dicha alarma
Requerimientos Funcionales de Mantenimiento
Identificador: RF016 Nombre: Aplicar Configuración
Tipo: Restricción Crítico: No
Descripción: Debe existir un mecanismo que permita aplicar los cambios que se realicen enla consola de administración del sistema.
158
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
Las modificaciones que se hagan en la aplicación se deben poder ejecutarinmediatamente
ENTRADAS
Cambios realizados
PROCESOSUna vez se indique al sistema que se deben aplicar los cambios, estos deben
modificar la configuración real de la aplicación.
SALIDASMensaje de operación exitosa o fallida.
Identificador: RF017 Nombre: Backup y Restauración Aplicación
Tipo: Restricción Crítico: Si
Descripción: Se debe poder guardar copias de seguridad y restaurarlas
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
La aplicación debe estar en la capacidad de guardar copias de seguridad y luego poderrestaurarlas. (Centinelas, Configuraciones, Usuarios)
ENTRADAS
Configuración del sistema
PROCESOSGuardar copia de seguridad
SALIDAS
Archivos de respaldo
159
Requerimientos Funcionales de Auditoría y Control
Identificador: RF018 Nombre: Control Cambios
Tipo: Restricción Crítico: No
Descripción: Cada cambio debe estar documentado y aprobado
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
Cada modificación realizada en la operación de la aplicación, debe estar soportada por unrequerimiento, una documentación y su respectiva aprobación. En la aplicación debe
haber un mecanismo que permita llevar este control.
ENTRADASRequerimiento de cambio
ActualizacionesAprobaciones
PROCESOS
Se debe abrir un registro con un identificador único que contenga todos los datosdel cambio
SALIDAS
Apertura de cambioDocumentación de cambio
Cierre de cambio
Identificador: RF019 Nombre: Historial Login
Tipo: Restricción Crítico: No
Descripción: Para cada usuario, se debe disponer de un historial de autenticaciones en laaplicación
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
Para efectos de seguridad y control de acceso, el sistema debe enseñar el historial deautenticaciones de los usuarios.
160
ENTRADAS
Nombre de Usuario
PROCESOSConsulta del historial de accesos al sistema en la Base de Datos correspondiente.
SALIDAS
Impresión en pantalla de la información solicitada.
Requerimientos Funcionales del Módulo Incidentes
Identificador: RF020 Nombre: Generación de Incidentes
Tipo: Restricción Crítico: Si
Descripción: Generar incidente en caso de presentarse la interrupción del servicio
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
El sistema debe generar un incidente cuando se presente una alarma crítica, esto con elfin de llevar un seguimiento a los eventos.
ENTRADAS
AlarmaHora y fecha en que se presenta la alarma
PROCESOS
Recibe el estado Fuera de Servicio del IVRCrea un registro en la base de datos con la información recibida,
SALIDAS
Genera un ticket con un número único direccionado al grupo de operadores Publicar el ticket generado en la ventana de incidentes abiertos
Identificador: RF021 Nombre: Cierre de Incidentes Automático
Tipo: Restricción Crítico: Si
Descripción: Los incidentes deben cerrarse automáticamente una vez finalice la alarmacorrespondiente
161
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
El sistema debe generar cerrar los incidentes asociados un CI que normaliza su estado
ENTRADASNumero de incidente
Estado de IVR
PROCESOSSe evalúa el estado del IVR afectado para verificar si pasa a En Servicio
Se cierra el incidente
SALIDASNotificación vía email del cierre del incidente
Identificador: RF022 Nombre: Documentación Incidentes
Tipo: Restricción Crítico: Si
Descripción: Permitir que los usuarios operadores retroalimenten los incidentes
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
El sistema debe permitir la documentación y trámite de un incidente con el fin dedocumentar las fallas.
ENTRADAS
Numero de IncidenteDocumentación correspondiente
PROCESOS
Actualización de la base de datos de incidentes
SALIDASNotificación de actualización
162
Identificador: RF023 Nombre: Cierre de Incidentes Manual
Tipo: Restricción Crítico: Si
Descripción: Permitir que los usuarios operadores cierren los incidentes.
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
El sistema debe permitir el cierre de los incidentes generados automáticamente ymanualmente.
ENTRADAS
El número de IncidenteDocumentación correspondiente
PROCESOS
Se debe cambiar el estado del incidente de abierto a cerrado
SALIDASEl incidente ya no se mostrará en la ventana de incidentes abiertos
Notificación de cierre de incidente
Requerimientos Funcionales del Módulo Reportes – Configuración
Identificador: RF024 Nombre: Parámetros servidor de telefonía remoto
Tipo: Restricción Crítico: Si
Descripción: Definir los parámetros de comunicación con la Central Telefónica en la cual seencuentra configurado el IVR a monitorear
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
En algún lugar dentro de la aplicación se debe poder configurar los parámetros deconexión al servidor de telefonía remoto.
ENTRADAS
Parámetros de conexión (Dirección IP, puerto de conexión, etc.)
PROCESOSSe debe modificar la aplicación para que se conecte al servidor de telefonía remoto
que se defina
SALIDAS
163
Mensaje de configuración exitosa
Identificador: RF025 Nombre: SMTP
Tipo: Restricción Crítico: No
Descripción: Se debe definir un servidor de correo para el envío de notificaciones
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
Varias de las acciones de la aplicación deben enviar notificación, para tal fin debe existirun método que permita definir el servidor smtp que se utilizará
ENTRADAS
Parámetros de conexión (Dirección IP, puerto de conexión, etc.)
PROCESOSSe debe modificar la aplicación para que se conecte al servidor de correo que se
defina
SALIDASMensaje de creación exitosa
Correo de prueba
Identificador: RF026 Nombre: Export de Reportes
Tipo: Restricción Crítico: Si
Descripción: Exportar reportes de disponibilidad para cualquier rango de fechas
Prioridad: _X_Alta-Esencial __Media-Deseado __Baja-Opcional
INTRODUCCION
La aplicación debe estar en la capacidad de generar reportes que indiquen el historial dela disponibilidad. Se debe poder configurar por rangos de fechas.
ENTRADAS
IVRRango de fecha
164
PROCESOS
Se debe consultar el historial de eventos relacionados con el IVR
SALIDASGeneración de archivo exportable con los datos correspondientes.
Identificador: RF027 Nombre: Log
Tipo: Restricción Crítico: Si
Descripción: Deben existir registros de las operaciones de la herramienta.
Prioridad: __Alta-Esencial _X_Media-Deseado __Baja-Opcional
INTRODUCCION
Cada tarea que ejecute la aplicación debe quedar registrada en un archivo.
ENTRADASCualquier evento sobre la aplicación
Fecha y hora del evento
PROCESOSCon cada evento, descripción y tiempo, se debe crear un registro
SALIDAS
Archivo con registros de actividades
165
Requerimientos no Funcionales
Plataforma de implementación
Identificador: RNF01 Nombre: Acceso Web
Tipo: Necesario Crítico: No
Descripción: El único medio de acceso a la administración configuración, y operación de laaplicación debe ser web.
Criterios de Aceptación:
Seguridad y control de acceso
Identificador: RNF02 Nombre: Listas de Acceso
Tipo: Necesario Crítico: No
Descripción: a nivel de aplicación, se restringirá el acceso web a ciertos equipos. Adicionalmente,en el Manager de Asterisk donde se encuentra instalada la aplicación, se definirá que sólo se
podrá acceder desde ese mismo servidor, para evitar la ejecución de software malintencionadodesde otro equipos.
Criterios de Aceptación:
- Al Manager de asterisk śolo se podrá acceder desde el servidor donde se encuentra instalado.
- a la aplicación web sólo se podrá acceder desde lo equipos que se definan comoadministradores y operadores. No tendrán acceso todos los equipos de la LAN y tampoco desde
internet.
Identificador: RNF03 Nombre: Bloqueo de Cuentas
Tipo: Necesario Crítico: Si
Descripción: las cuentas de usuarios se procederán a bloquear después de ciertos intentosfallidos. Ésto con el fin de que no se permita el ingreso no autorizado a través de un ataque de
fuerza bruta.
166
Criterios de Aceptación:
- Una cuenta se bloqueará después del 3 intento fallido.
- La cuenta sólo puede ser desbloqueada por un Administrador
- Una cuenta no se desbloqueara por periodo de inactividad.
Identificador: RNF04 Nombre: Time Out de sesión
Tipo: Necesario Crítico: Si
Descripción: cuando un usuario tiene acceso a al aplicación y se retira de su lugar de trabajo sindesloguearse de la aplicación, corre el riesgo que otra persona use su sesión para realizar
cambios no autorizados, por lo que la sesión debe tener un timeout por inactividad.
Criterios de Aceptación:
- La sesión se desconectará después de 10 minutos de inactividad.
Especificaciones Suplementarias (No Funcionales)
Confiabilidad
Los reportes y monitores que genere la aplicación deben ser consistentes y debenreflejar el comportamiento real del IVR.
Usable
Las interfaces que se presenten tanto a los usuarios Administradores como a losoperadores, deben representar el mundo real de tal forma que sean intuitivas yfaciliten su operación.
167
Seguridad
Verificar el acceso a la aplicación correspondiente del sistema según el tipo de usuario que se hayadefinido en el mismo.
Operatividad
Garantizar que el despliegue de las ventanas y la operatividad de la herramienta, funcionecorrectamente teniendo en cuenta los requerimientos operativos necesarios.
168
ANEXO B: Especificación de Casos de Uso
Caso de Uso Autenticar Usuario CU001
Actores Operador, Administrador
Tipo Esencial
Referencias RF001, RF019, RF027 CU0030
Pre-condición El usuario no debe tener una sesión iniciada
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Brindar un único punto de acceso (inicio de sesión) a las funcionalidades del sistema
Resumen
Los usuarios deben registrar su ingreso a la aplicación mediante un nombre de usuario y unacontraseña, si estos son correctos, el sistema debe mostrar las opciones permitidas según el
rol del usuario.
Curso Normal
1El usuario abre la aplicaciónmediante un explorador Web
2La aplicación despliega formulario
para inicio de sesión
3El usuario ingresa identificador de
usuario y contraseña4
La aplicación muestra lasopciones a las que el usuario
tiene acceso.
Curso Alterno
3A El usuario ingresa datos erróneos 4ALa aplicación debe mostrar
mensaje de error y volver a paso2
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Es obligatorio estar autenticado en la aplicación para realizar cualquier otra tarea, así queeste caso de uso precede a cualquier otro de aquí en adelante
169
Caso de Uso Crear Usuario CU002
Actores Administrador
Tipo Esencial
Referencias RF002, RF005, RF027 CU030, CU005
Pre-condición Previa autenticación
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Posibilitar la creación de usuarios del sistema (Operadores y Administradores).
Resumen
Los administradores ingresan al sistema y luego al módulo de usuarios, allí seleccionan laopción de crear usuarios, diligencian los datos necesarios para su creación y agregan el
usuario al listado general de usuarios.
Curso Normal
1Un administrador ingresa al
módulo de usuarios.2
La aplicación muestra una lista deusuarios existentes CU005
3El usuario solicita la creación de
un nuevo usuario4
El sistema presenta el formulariode creación de usuario
5El usuario diligencia los datos del
nuevo usuario
6Se confirma la creación del
usuario7
El sistema realiza la actualizaciónde la base de datos
8 El sistema vuelve a paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
170
Caso de Uso Borrar Usuario CU003
Actores Administrador
Tipo Opcional
Referencias RF003, RF027 CU0030, CU005
Pre-condición Previa autenticación, el usuario a eliminar debe estar creado
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Eliminar un usuario dentro del sistema
Resumen
Un administrador ingresa al módulo de usuarios y de los usuarios que allí se muestran,selecciona uno con la opción de borrado, la aplicación debe actualizar la base de datos
correspondiente e informar su resultado.
Curso Normal
1El usuario ingresa al módulo de
usuarios2
La aplicación muestra una lista deusuarios existentes CU005
3De los usuarios listados, elusuario escoge borrar uno.
4El sistema realiza el borrado del
usuario
5 vuelve al paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
171
Caso de Uso Editar Usuario CU004
Actores Administrador
Tipo Opcional
Referencias RF004, RF027 CU030, CU005
Pre-condición Previa autenticación, el usuario a editar debe estar creado
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Modificar el perfil de un usuario existente o los atributos del mismo
Resumen
Un administrador ingresa al módulo de usuarios y del listado de usuarios que allí se muestran,elige el que desea modificar, luego de realizar las modificaciones, guarda los cambios.
Curso Normal
1El usuario ingresa al módulo de
usuarios2
La aplicación muestra una lista deusuarios existentes CU005
3Del listado de usuarios, el
administrador escoge realizaredición de uno
4El sistema muestra las opciones
modificables del usuario
5El administrador realiza las
modificaciones6
Se realiza la actualización de labase de datos
7 se vuelve a paso 2
Curso Alterno
5AAun estando en la opción demodificar, el administrador no
realiza modificaciones6A Volver a paso 2
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
172
Caso de Uso Listar Usuarios CU005
Actores Administrador
Tipo Opcional
Referencias RF002 CU002, CU003, CU004
Pre-condición autenticación previa
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Este Caso de Uso es requerido para realizar la gestión de usuarios
Resumen
En ésta página se podrán ver los usuarios creados.
Curso Normal
1El usuario ingresa al módulo de
usuarios2
La aplicación muestra una lista deusuarios existentes
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Crear Centinela CU006
Actores Administrador
Tipo Esencial
Referencias RF006, RF010, RF027 CU030
Pre-condición Autenticación previa
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
173
Crear un patrón de marcado con el que se vigila un IVR
Resumen
Un administrador ingresa al módulo Centinelas y allí debe escoger la opción que permitecrear Centinela, luego de especificar los parámetros del nuevo objeto, guarda cambios y la
aplicación redirecciona a la lista de centinelas creados.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega la lista decentinelas creados
3El usuario selecciona la opción de
adicionar un nuevo Centinela4
El sistema abre el formulario paracreación de Centinelas
5Diligencia los datos necesarios
para la creación de un Centinela6
Se adiciona el nuevo Centinela alrepositorio de Centinelas
7 Se vuelve al paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Modificar Centinela CU007
Actores Administrador
Tipo Opcional
Referencias RF007, RF010, RF027 CU030
Pre-condición autenticación previa, el centinela a modificar debe estar creado
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Editar los parámetros de un Centinela existente
Resumen
Un administrador ingresa al módulo Centinelas, abre las especificaciones de un Centinela yrealiza modificaciones a sus parámetros, luego confirma los cambios y guarda la
174
configuración.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega loscentinelas creados
3El usuario selecciona un
Centinela existente para realizarmodificación
4El sistema carga el Centinela en
modo edición
5Se realizan las modificaciones
que se requiera6
Se actualiza la configuración delCentinela
7 Se vuelve al paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Borrar Centinela CU008
Actores Administrador
Tipo Opcional
Referencias RF009, RF027 CU030
Pre-condición Previa autenticación, el centinela a eliminar debe estar creado
Post-condición Ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Eliminar un patrón de marcado
Resumen
Un administrador ingresa al Modulo Centinelas y del listado de Centinelas, escoge la opciónde eliminar, el sistema debe borrar el objeto.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega loscentinelas creados
175
3El usuario selecciona un
Centinela existente 4
Se borra el patrón de marcadodefinitivamente del sistema
5 Se vuelve al paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Habilitar Centinela CU009
Actores Administrador
Tipo Opcional
Referencias RF008, RF027 CU030
Pre-condiciónautenticación previa, el centinela a habilitar debe estar creado y
deshabilitado
Post-condición Ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Habilitar un Centinela que se encontraba deshabilitado
Resumen
Un administrador ingresa al módulo Centinelas, selecciona un Centinela existente que tengahabilitado el botón habilitar.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega loscentinelas creados
3El usuario selecciona un
Centinela existente ydeshabilitado
4 El sistema habilita el Centinela
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
176
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Deshabilitar Centinela CU010
Actores Administrador
Tipo Opcional
Referencias RF008, RF027 CU030
Pre-condiciónautenticación previa, el centinela a habilitar debe estar creado y
deshabilitado
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Detener la ejecución de un Centinela temporalmente
Resumen
Un administrador ingresa al módulo Centinela, del listado de Centinelas que allí se presentan,selecciona la opción Deshabilitar, con lo que se debe impedir la ejecución del Centinela.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega loscentinelas creados
3El usuario deshabilita un
Centinela existente4 El sistema deshabilita el Centinela
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
177
Caso de Uso Ejecutar Centinela CU011
Actores Operador, Administrador, Monitor
Tipo Esencial
Referencias RF011, RF027 CU030, CU017
Pre-condición El centinela debe estar creado
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Lanzar el test de un IVR de forma inmediata
Resumen
Un administrador ingresa al módulo Centinelas, del listado de Centinelas escoge la opción“ejecutar” para uno de ellos y la aplicación debe lanzar el test independientemente de suhorario de ejecución normal. Seguidamente la aplicación debe dirigirse al módulo monitor
donde se visualizará el resultado del mismo.
Curso Normal
1El usuario ingresa al módulo
Centinelas2
La aplicación despliega loscentinelas creados
3El usuario selecciona la opción
ejecutar de un Centinela existente4
El sistema ejecuta el Centinela deforma inmediata
5Se direcciona al módulo monitor y
muestra el resultado del Test
Curso Alterno
1AEl Centinela se ejecuta
automáticamente
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Crear CI CU012
178
Actores Administrador
Tipo Esencial
Referencias RF027 CU030
Pre-condición Previa autenticación
Post-condición Ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Establecer una representación de un IVR dentro de la aplicación para poderlo monitorear
Resumen
El usuario debe ingresar por el módulo de Configuración y allí crear los CI's para luegoasociarlos a los centinelas.
Curso Normal
1El usuario ingresa al módulo de
configuración2
La aplicación muestra lasopciones que permite configurar
3 El usuario escoge la opción CI 4La aplicación muestra los CI's
creados
5 El usuario escoge la opción crear 6La aplicación muestra un
formulario
7El usuario diligencia los datos del
CI a crear y aplica cambios8 La aplicación crea el nuevo CI
9 Vuelve al paso 4
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Borrar CI CU013
Actores Administrador
Tipo Esencial
Referencias RF027 CU030
179
Pre-condición Previa autenticación, el CI a eliminar debe estar creado
Post-condición Ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Borrar un CI previamente creado
Resumen
El usuario debe ingresar por el módulo de Configuración y allí eliminar uno de los CI'screados
Curso Normal
1El usuario ingresa al módulo de
configuración2
La aplicación muestra lasopciones que permite configurar
3 El usuario escoge la opción CI 4La aplicación muestra los CI's
creados
5El usuario escoge la opción
eliminar6 La aplicación eliminar el CI
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Visualizar Monitores CU014
Actores Operador, Administrador
Tipo Esencial
Referencias RF012
Pre-condición Previa autenticación
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Mostrar en pantalla un resumen gráfico del estado de los IVR
180
Resumen
Los usuarios pueden visualizar los monitores con el inicio de sesión dado que es la página deinicio de la aplicación, o estando en cualquier lugar de la misma al escoger el módulo
monitores
Curso Normal
1El usuario ingresa al módulo
monitores2
La aplicación realiza una consultadel estado de los IVR's
configurados.
3La aplicación muestra el estado
actual e histórico de dichos IVR's
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Definir Umbrales CU015
Actores Administrador
Tipo Esencial
Referencias RF013
Pre-condición El Centinela debe estar creado previamente
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Establecer la criticidad de cada IVR mediante la declaración de condiciones
Resumen
Un administrador ingresa a la especificación de un Centinela y define las condiciones para lascuales el Centinela es considerado Fuera de Servicio, de Servicio Degradado o En Servicio,
seguidamente se guardan cambios
Curso Normal
1El usuario ingresa al módulo
Configuración2
La aplicación despliega losservicios del módulo
181
3El usuario selecciona un CI
existente4
El sistema carga el CI en modoedición
5El usuario selecciona adicionar
nodo al CI6
Carga el formulariocorrespondiente
7Se modifica el umbral para la
acción seleccionada8
Se actualiza configuración delSistema
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Definir Notificaciones CU016
Actores Administrador
Tipo Opcional
Referencias RF013
Pre-condición El elemento de configuración CI debe estar creado.
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Personalizar las notificaciones que informaran el estado de un IVR
Resumen
Un administrador abre las especificaciones de un CI y allí personaliza las notificaciones quese realizarán para los cambios de estado del IVR, posteriormente guarda cambios
Curso Normal
1El usuario ingresa al módulo
Configuración2
La aplicación despliega losservicios del módulo
3 El usuario selecciona un CI 4El sistema carga el CI en modo
edición
5El usuario establece como desea
ser notificado6
El sistema actualiza laconfiguración.
182
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Identificar Estados CU017
Actores Monitor
Tipo Esencial
Referencias RF014 CU018, CU011
Pre-condiciónSiempre lo precede la ejecución de un Centinela, Existencia de
Umbrales e IVR asociados al Centinela
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Interpretar las pruebas hechas por los Centinelas para determinar los cambios de estado enlos IVR
Resumen
Luego de la ejecución de un Centinela, se comparan los resultados con los parámetros(umbrales) para establecer el estado del IVR, luego se actualiza el IVR de ser necesario
Curso Normal
1El sistema envía los resultados de
la ejecución de un Centinela
2El Monitor consulta los umbralesque aplican al Centinela e IVR
asociado
3Compara los resultados obtenidos
con Umbrales
4 Determinar estado de IVR
Curso Alterno
2ANo hay umbrales definidos o IVR
asociado
183
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Cambiar Estado CU018
Actores
Tipo Esencial
Referencias RF014CU017, CU044, CU026, CU028,
CU019
Pre-condiciónSiempre lo precede la ejecución de un Centinela, Existencia de
Umbrales, IVR asociados al Centinela e identificación de estados
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Asignar un nuevo estado al IVR basado en la respuesta de identificar estado.
Resumen
Luego de la ejecución de un Centinela, se comparan los resultados con los parámetros(umbrales) para establecer el estado del IVR, luego se actualiza el IVR por medio del cambio
de Estado.
Curso Normal
1La aplicación recibe la solicitud de
cambio de estado
2Crea el registro del cambio de
estado
3Notifica al monitor el cambio de
estado.
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
184
Comentarios
Caso de Uso Generar Alarma CU019
Actores Monitor
Tipo Esencial
Referencias RF015, RF027 CU018, CU043
Pre-condiciónEl estado de un IVR pasa a ser Fuera de Servicio, Servicio Degradado
o estado desconocido
Post-condición Ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Crear una alerta en los monitores indicando la existencia de un estado Fuera de Servicio, deAdvertencia o estado desconocido
Resumen
Luego de que un IVR pase a estado Fuera de Servicio, Servicio Degradado o estadodesconocido, se debe informar a la aplicación para que modifique los monitores generando
alarmas
Curso Normal
1Cambia el estado de un IVR a
Fuera de Servicio o de ServicioDegradado
2Solicita crear alarmas según el
caso3
Se generan los registrosnecesarios asociados a las
alarmas
4El monitor refleja la existencia de
las alarmas
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
185
Caso de Uso Guardar Backups CU020
Actores Operador, Administrador
Tipo Esencial
Referencias RF017, RF027 CU030
Pre-condición Autenticación previa,
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Guardar copias de seguridad de la configuración del sistema
Resumen
El usuario ingresa al módulo de Configuración y allí selecciona la opción para generar yguardar un backup. La aplicación genera un archivo con la configuración del sistema
Curso Normal
1El usuario ingresa al módulo
Configuración2
La aplicación despliega losservicios del módulo
3El usuario selecciona la opción
generar Backups4
El sistema ejecuta la acción paragenerar el backup
5Genera el correspondiente archivo
e informa la ruta donde seencuentra
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Restaurar Backups CU021
Actores Administrador
186
Tipo Esencial
Referencias CU030
Pre-condición Previamente se debe exportar un Backup
Post-condiciónLa configuración del sistema debe cambiar de acuerdo a la copia de
seguridad
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Es la opción para restablecer una copia de seguridad a la configuración del sistema
Resumen
Un administrador ingresa al servidor por ssh, y ejecuta el script que restaura la BD de laaplicación. Al restaurarlo, la aplicación debe quedar con la configuración que está
especificada en el archivo.
Curso Normal
1El usuario ingresa al servidor por
ssh.
3El usuario ejecuta el script de
restauración
5El usuario valida que se realice la
restauración sin errores.
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Crear Cambio CU022
Actores Operador
Tipo Esencial
Referencias RF018, RF027 CU030
Pre-condición Previa autenticación
Post-condición Ninguna
187
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Crear un registro en el que se documenten los cambios del sistema
Resumen
Un operador ingresa al módulo de Cambios y escoge crear uno nuevo, con esto la aplicacióncaptura los datos del Cambio según la necesidad y al confirmar la creación, se genera un
registro en la base de datos que contiene la información suministrada
Curso Normal
1El usuario ingresa al módulo
Cambios2
La aplicación despliega los cambiosexistentes y en estado abierto
CU025
3El usuario escoge la opción crear
cambio4
El sistema despliega el formulariopara la creación de cambios
5El usuario documenta y confirma la
creación del cambio6 Se crea el registro correspondiente
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Cerrar Cambio CU023
Actores Operador
Tipo Esencial
Referencias RF018, RF027 CU030
Pre-condición El cambio debe existir y debe estar en estado abierto
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Cerrar el registro creado asociado a un cambio en la plataforma
Resumen
188
Un operador ingresa a la sección de Cambios y del listado de cambios pendientes, abre laespecificación de uno y revisa la documentación escrita por el administrador quien realizó el
cambio de configuración. Si lo solicitado coincide con lo configurado, procede a cerrar elcambio
Curso Normal
1El usuario ingresa a la sección
Cambios2
La aplicación muestra una lista decambios abiertos CU025
3El usuario selecciona uno de los
cambios4
Se carga el cambio e modoedición
5El usuario selecciona la opción
cerrar cambio6
El registro cambia su estado acerrado
7Se borra el cambio del listado de
Cambios abiertos
Curso Alterno
8AEl cambio no se puede cerrar por
falta de documentación
9AEl usuario solicita al
administrador, documentar elcambio CU24
10A Pasa al paso 5
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Documentar Cambio CU024
Actores Administrador
Tipo Esencial
Referencias RF018, RF027
Pre-condición El cambio debe existir y en estado abierto
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
189
Propósito
Actualizar la información asociada a un cambio
Resumen
Un administrador ingresa a la sección de Cambios y del listado de cambios pendientes, abrela especificación de uno, realiza las actualizaciones pertinentes y guarda los cambios
Curso Normal
1El usuario ingresa a la sección
Cambios2
La aplicación muestra una lista decambios abiertos CU025
3El usuario selecciona uno de los
cambios4
Se carga el cambio en modoedición
5El usuario realiza la
documentación del cambio6
Se actualiza el registro y sevuelve al paso 2
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Lista Cambio CU025
Actores Administrador, Operador
Tipo Esencial
Referencias RF018
Pre-condición El cambio debe existir y en estado abierto
Post-condición
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Listar todos los cambios pendientes por realizar en la plataforma.
Resumen
Un usuario ingresa a la sección de Cambios y se le mostrará los cambios pendientes porgestionar
Curso Normal
190
1El usuario ingresa a la sección
Cambios2
La aplicación muestra una lista decambios abiertos
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Abrir Incidente CU026
Actores Monitor, Operador, Administrador
Tipo Esencial
Referencias RF020, RF027 CU018, CU043
Pre-condiciónUno de los IVR debe cambiar de estado En Servicio a cualquier otro
estado.
Post-condición Se debe notificar según parámetros establecidos
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Crear un registro en caso de presentarse un comportamiento anormal en un IVR
Resumen
Cuando un IVR pase de estado En Servicio a cualquier otro estado, Fuera de Servicio, elmonitor envía los datos para que se abra un registro con los datos de la afectación., luego el
sistema debe informar del evento
Curso Normal
1El monitor informa que un IVR ha
pasado a estado Fuera deServicio
2El monitor envía los datos de la
incidencia3
La aplicación crea el registroasociado y lo documenta con los
datos del Monitor
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
191
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Listar Incidentes CU027
Actores Operador, Administrador
Tipo Esencial
Referencias RF020
Pre-condición Previa autenticación
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Consultar los incidentes abiertos
Resumen
El usuario debe ingresar al módulo de incidentes, y visualizará los incidentes abiertos.
Curso Normal
1El usuario ingresa al módulo
Incidentes2
El sistema consulta y muestra ellistado de Incidentes abiertos
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Cerrar Incidentes CU028
Actores Monitor, Operador, Administrador
Tipo Esencial
Referencias RF021, RF023, RF027 CU018, CU043
192
Pre-condición Previa autenticación, el incidente debe estar abierto
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Cerrar el registro asociado a un evento inesperado del estado de un IVR
Resumen
El curso normal de esta operación es que cuando un IVR vuelva al estado En Servicio, elincidente asociado sea cerrado. Sin embargo, también existe la posibilidad para los usuarios
de ingresar al módulo y cerrar manualmente los incidentes
Curso Normal (Automático)
1El monitor realiza el cambio deestado de un IVR a En Servicio.
2El sistema notifica que existe un
Incidente asociado
3El monitor suministra la
documentación necesaria para elcierre del caso
4El sistema realiza el cierre del
incidente
Curso Alterno (Cierre Manual)
1AEl usuario lista incidentes abiertos
CU0272A
La aplicación muestra el listadosolicitado
3AEl usuario selecciona uno de los
incidentes del listado4A
El incidente se carga en modoedición
5AEl usuario selecciona la opción
cierre6A Paso 4
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Actualizar Incidente CU029
Actores Operador, Administrador
Tipo Esencial
Referencias RF022, RF027 CU030
Pre-condición Previa autenticación, el incidente debe estar abierto
193
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Documentar un registro de incidente
Resumen
El usuario ingresa al módulo de incidentes y del listado abre las especificaciones de uno deellos, realiza las actualizaciones del caso y guarda cambios
Curso Normal
1El usuario lista incidentes abiertos
CU0272
La aplicación muestra el listadosolicitado
3El usuario selecciona uno de los
incidentes del listado4
El incidente se carga en modoedición
5El usuario realiza las
modificaciones necesarias yconfirma la acción
6Se guardan las actualizaciones
realizadas
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Registrar Evento CU030
Actores
Tipo Esencial
Referencias RF027
CU022, CU023, CU001, CU029,CU033, CU040, CU020, CU009,CU010, CU011, CU002, CU003,CU004, CU006, CU008, CU007,
CU032, CU021, CU0031
Pre-condición ninguna
Post-condición ninguna
Autor Diego López Fecha 04-06-2014 Versión 1
194
Rafael Morales
Propósito
Guardar la evidencia de eventos relevantes dentro del sistema
Resumen
Varias de las operaciones de la aplicación tienen la obligación de dejar registro, así que cadavez que se ejecutan, se debe actualizar un archivo con los datos del evento ocurrido
Curso Normal
1Alguno de los usuarios ejecuta
alguno de los casos de usoreferenciados
2El sistema registra en un archivo
la actividad realizada
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Definir parámetros aplicación CU031
Actores Administrador
Tipo Esencial
Referencias RF024, RF016, RF025, RF027 CU030
Pre-condición Previa autenticación
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Configurar los parámetros de aplicación relacionados con todo el sistema
Resumen
Un administrador ingresa al módulo de configuración, allí existe la opción de configurarparámetros globales, en los que se encuentran los datos con los que la aplicación se adapta a
la infraestructura existente, se trata de un formulario que edita y al que luego guarda. Conesta última acción se modifican definitivamente los parámetros de la aplicación.
Curso Normal
195
1El usuario ingresa al módulo
configuración2
La aplicación muestra lasopciones del módulo
3Escoge la opción “Configurar
parámetros generales”4
La aplicación despliega elformulario correspondiente
5Realiza modificaciones sobre los
parámetros
6 Confirma la solicitud 7El sistema modifica los archivos yparámetros correspondientes a la
solicitud del usuario
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Aplicar Configuración CU032
Actores Administrador
Tipo Esencial
Referencias RF027 CU030
Pre-condición Deben existir cambios en la configuración del sistema
Post-condición Se actualizará configuración en el sistema
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Implementar definitivamente un cambio de configuración
Resumen
Un administrador luego de realizar configuraciones en la aplicación escoge la opciónactualizar para aplicar los cambios con los que se guarda definitivamente la configuración
realizada
Curso Normal
1El usuario realiza modificaciones
sobre la aplicación2
La aplicación realiza el cambio deconfiguración
Curso Alterno
196
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Crear Reporte Automático CU033
Actores Operador, Administrador
Tipo Esencial
Referencias RF027 CU030
Pre-condición Previa autenticación
Post-condición Se ejecuta el reporte
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Configurar la creación y envío de un reporte de manera periódica
Resumen
El usuario ingresa al módulo de reportes
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3Escoge la opción reporte
automático4
Se lista los reportes automáticoscreados CU035
5El usuario escoge la opción crear
reporte6
Se muestra el formulario paracreación de reportes
7Diligencia las opciones del
reporte y hace click en crear8
El sistema activa el reporte yvuelve al paso 4
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
197
Caso de Uso Editar Reporte Automático CU034
Actores Operador, Administrador
Tipo Esencial
Referencias RF027, RF026
Pre-condición Previa autenticación y que el reporte exista
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Editar un reporte automático ya existente
Resumen
El usuario ingresa al módulo de reportes y selecciona el reporte a editar
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3Escoge la opción reporte
automático4
Se lista los reportes automáticoscreados CU035
5El usuario selecciona uno de los
reportes6
Se muestra el formulario paraeditar de reportes
7Diligencia las opciones del
reporte y hace click en actualizar8
El sistema actualizar el reporte yvuelve al paso 4
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso listar Reporte Automático CU035
Actores Operador, Administrador
198
Tipo Esencial
Referencias RF026
Pre-condición Previa autenticación
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Listar los reporte que se ejecutan de manera periódica
Resumen
El usuario ingresa al módulo de reportes y escoge la opción automáticos
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3Escoge la opción reportes
automáticos4
Se lista los reportes automáticoscreados
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso habilitar Reporte Automático CU036
Actores Operador, Administrador
Tipo Esencial
Referencias RF026, RF027
Pre-condiciónPrevia autenticación, que el reporte exista y se encuentre
deshabilitado
Post-condición Se ejecuta el reporte periódicamente
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
199
Habilitar un reporte para que se ejecute de manera periódica
Resumen
El usuario ingresa al módulo de reportes y escoge la opción automáticos, allí visualiza losreportes automáticos creados y habilita los que se encuentren deshabilitados.
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3Escoge la opción reportes
automáticos4
Se lista los reportes automáticoscreados CU035
5El usuario habilita uno de los
reportes deshabilitados6
El sistema habilita el reporteseleccionado
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Deshabilitar Reporte Automático CU037
Actores Operador, Administrador
Tipo Esencial
Referencias RF026, RF027
Pre-condición Previa autenticación, que el reporte exista y se encuentre habilitado
Post-condición Se detiene la ejecución del reporte periódicamente
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Deshabilitar un reporte para que se ejecute de manera periódica
Resumen
El usuario ingresa al módulo de reportes y escoge la opción automáticos, allí visualiza losreportes automáticos creados y deshabilita los que se encuentren habilitados.
Curso Normal
1 El usuario ingresa al módulo de 2 La aplicación muestra las
200
reportes opciones del módulo
3Escoge la opción reportes
automáticos4
Se lista los reportes automáticoscreados CU035
5El usuario deshabilita uno de los
reportes habilitados6
El sistema deshabilita el reporteseleccionado
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Eliminar Reporte Automático CU038
Actores Operador, Administrador
Tipo Esencial
Referencias RF027 CU030
Pre-condición Previa autenticación y que el reporte automático exista.
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Borrar la ejecución de un reporte periódico.
Resumen
El usuario ingresa al módulo de reportes y escoge la opción automáticos, allí visualiza losreportes automáticos creados y escoge la opción eliminar.
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3Escoge la opción reportes
automáticos4
Se lista los reportes automáticoscreados CU035
5El usuario escoge la opción
eliminar de uno de los reportes6
El sistema elimina el reporteseleccionado y detiene su
ejecución.
201
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Ejecutar Reporte Automático CU039
Actores Monitor
Tipo Esencial
Referencias RF027 CU042
Pre-condición ninguna
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2013 Versión 1
Propósito
Ejecutar un reporte periódicamente
Resumen
Ejecutar un reporte periódicamente
Curso Normal
1El monitor solicita la ejecución del
reporte con los parámetrospredefinidos
2La aplicación hace la consultarespectiva y genera el reporte
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
202
Caso de Uso Generar Reporte Manual CU040
Actores Operador, Administrador
Tipo Esencial
Referencias RF026, RF027 CU030
Pre-condición Previa autenticación
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Ejecutar un reporte de un periodo personalizado sin necesidad de hacerlo reiteradamente.
Resumen
El usuario ingresa al módulo de reportes y escoge la opción manual, allí diligencia los valoresnecesarios para generar el reporte.
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3 Escoge la opción reportes manual 4La aplicación despliega un
formulario
5El usuario diligencia el formulario
para generar el reporte6
El sistema realiza las consultasnecesarias y visualiza el reporte.
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Exportar Reporte CU041
Actores Operador, Administrador, Monitor
Tipo Esencial
Referencias RF026, RF027
Pre-condición Que exista el reporte
203
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Exportar el resultado de un reporte manual o automático.
Resumen
El usuario ingresa al módulo de reportes y escoge la opción manual, allí diligencia los valoresnecesarios para generar el reporte. Luego de generarlo, exporta dicho reporte
Curso Normal
1El usuario ingresa al módulo de
reportes2
La aplicación muestra lasopciones del módulo
3 Escoge la opción reportes manual 4La aplicación despliega un
formulario
5El usuario diligencia el formulario
para generar el reporte6
El sistema realiza las consultasnecesarias y visualiza el reporte.
7 El usuario exporta el reporte
Curso Alterno
1El usuario configura el reporte
automático 2
La aplicación ejecuta el reporteautomático
3La aplicación exporta y envía porcorreo electrónico el resultado del
reporte
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Enviar Reporte CU042
Actores Monitor
Tipo Esencial
Referencias RF026 CU039, CU043
Pre-condición Que exista el reporte
Post-condición ninguna
204
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Enviar por correo electrónico el resultado de un reporte automático.
Resumen
Luego que la aplicación genera un reporte automático, el resultado de éste reporte lo envíapor correo electrónico.
Curso Normal
1El usuario configura el reporte
automático 2
La aplicación ejecuta el reporteautomático
3La aplicación exporta y envía porcorreo electrónico el resultado del
reporte
Curso Alterno
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Notificar Evento CU043
Actores
Tipo Esencial
Referencias RF014 CU042, CU026, CU028, CU019
Pre-condición ninguna
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Notificar en forma de correo electrónico, pop-up o sonido la ocurrencia de un evento
Resumen
Ejecutar un acción que notifica la ocurrencia de un evento.
Curso Normal
205
1Ocurre un evento que requiere
notificación 2
La aplicación envía un correoelectrónico notificando el evento.
Curso Alterno
1Ocurre un evento que requiere
notificación 2
La aplicación abre un pop-upnotificando el evento.
Curso Alterno
1Ocurre un evento que requiere
notificación 2
La aplicación reproduce un sonidonotificando el evento.
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
Caso de Uso Actualizar Monitores CU044
Actores Monitor
Tipo Esencial
Referencias RF014 CU018
Pre-condición Que se ejecute un centinela
Post-condición ninguna
AutorDiego López
Rafael MoralesFecha 04-06-2014 Versión 1
Propósito
Refrescar la página de monitores para mantener actualizado el estado de los IVR
Resumen
Actualiza el estado de los IVR's
Curso Normal
1Centinela termina su ejecución
retornando el resultado de éstos
2El sistema valida los resultados y
genera un estado
3Se actualiza el estado del IVR en la
página de monitores
Curso Alterno
206
Otros Datos
Importancia Alta Urgencia Alta
Estado Terminado Estabilidad Alta
Comentarios
207
ANEXO C : Glosario terminología ITIL
ASP: Proveedor de Servicios de Aplicaciones
back-out: Proceso de retirada de una versión ya desplegada
back-up: Copias de seguridad
BCM: Gestión de la Capacidad del Negocio
BCM: Gestión de la Continuidad del Servicio
BIA: Análisis de impacto en el negocio
CAB: Comité Asesor del Cambio
CCM: Gestión de la Capacidad de Recursos
CDB: Base de Datos de la Capacidad
CFIA: Análisis del Impacto de Fallo de Componentes
CI: Elemento de Configuración
CIs: Elementos de Configuración
CMDB: Base de Datos de la Gestión de Configuraciones
CMI: Cuadro de Mando Integral
CMIS: Sistema de Información de Gestión de la Capacidad
CMS: Sistema de Gestión de la Configuración
CRAMM: Método de Gestión y Análisis de Riesgos de la CCTA
CRM:
CSFs: Factores Críticos de Éxito
CSI: Mejora Continua del Servicio
CSP: Paquete de Servicio Esencial
DAFO: Fortalezas, Debilidades, Oportunidades y Amenazas
DML: Biblioteca de Medios Definitivos
DS: Repuestos Definitivos
ECAB: Comité Asesor de Cambios de Emergencia
ELS: Soporte post-implantación
FAQs: Preguntas Frecuentes
FSC: Calendario del Cambio
FTA: Análisis del Árbol de Fallos
GTB: Inversiones de crecimiento del negocio
ISMS: Gestión de la Seguridad de la Información
ISPs: Proveedores de Servicios de Internet
ITIL: Biblioteca de la Infraestructura de Tecnología de Información
ITSCM: Gestión de la Continuidad de los Servicios de TI
208
KB: Base de Conocimiento
KEDB: Base de Datos de Errores Conocidos
KPIs: Indicadores Críticos de Rendimiento
LOPD: Ley Orgánica de Protección de Datos
MTBF: Tiempo Medio entre Fallos
MTBSI: Tiempo Medio entre Incidencias del Servicio
MTTR: Tiempo Medio de Reparación
M_o_R: Gestión de Riesgos
OLA: Acuerdos de Nivel de Operación
OLAs: Acuerdos de Nivel de Operación
PBAs: Patrones de Actividad del Negocio
PIR: Revisión Post-Implantación
PSA: Disponibilidad de Servicio Prevista
PSO: Parada de Servicio Prevista
RACI : Encargado-Responsable-Consultado-Informado
RASCI: Encargado-Responsable-Soporte-Consultado-Informado
RCA: Análisis de la Causa Raíz
RFC: Petición de Cambio
RFCs: Peticiones de Cambio
ROI: Retorno de la inversión
RTB: Inversiones para mantener el negocio
SACs: Criterios de Aceptación del Servicio
SCD: Base de Datos de Proveedores y Contratos
SCM: Gestión de la Capacidad del Servicio
SDP: Paquete de Diseño del Servicio
SIP: Plan de Mejora del Servicio
SKMS: Sistema de Gestión del Conocimiento del Servicio
SLA: Acuerdos de Nivel de Servicio
SLAs: Acuerdos de Nivel de Servicio
SLM: Responsable del Nivel del Servicio
SLP: Paquete de Nivel del Servicio
SLRs: Requisitos del Nivel del Servicio
SLRs: Requisitos del Nivel del Servicio
SOA: Análisis de Interrupción del Servicio
SP: Paquete de Servicio
SPs: Paquetes del Servicio
SQP: Plan de Calidad del Servicio
SQP: Plan de Calidad del Servicio
209
SSIP: Plan de Mejora de Proveedor de Servicios
SWOT: Fortalezas, Debilidades, Oportunidades y Amenazas
TCO: Coste Total de Propiedad
TTB: Inversiones para transformar el negocio
UC : Contrato de Soporte
UCs: Contratos de Soporte
VBF: Función Vital para el Negocio
VOI: Valor de la Inversión
210
ANEXO D: Diagrama Entidad – Relación Extendido
211
ANEXO E: Diagrama de Clases
212
ANEXO F: Manuales y Procedimientos
Procedimientos de Operación y Administración del Sistema
Manual de Instalación de Sentinel
1. Objetivo
Instalar la plataforma necesaria para el monitoreo de un IVR.
2. Alcance
Este documento está dirigido a la instalación del servidor que va alojar laaplicación encargada de monitorear los IVR. No está dirigido para configurar y/oadministrar un servidor Asterisk, así como tampoco un servidor Linux. Paraconfigurar la troncal en el servidor Asterisk donde se encuentra alojado o alojadoslos IVR’s, debe dirigirse al administrador de dicha plataforma en su organización.Para cualquier inconveniente con e servidor, debe dirigirse a su administrador deservidores.
3. Definiciones
Sentinel es infraestructura conformada para el monitoreo de IVR’s (actualmente enla versión 1.0) que se encuentra confirmada por dos componentes:
• Software de Aplicación: También conocido como Pixqui, es el entorno WEBdesde donde se manipularán todos objetos necesarios para el monitoreo deIVR’s (centinelas, IVR’s, usuarios, etc). Ésta aplicación está basada en PHP 5.4y usando el servidor web Apache 2.2
• SO y Hardware: la aplicación usa un servidor de telefonía para poder realizarlas marcaciones. El servidor escogido para tal fin es un Asterisk en la versión11.17. El hardware es suministrado por la organización y debe cumplir lossiguientes requerimientos:
213
Cantidad de Llamadas Procesador RAM120 LlamadasSimultáneas
Intel / AMD 3 GHz 1 GB
350 LlamadasSimultáneas
Intel PIV/ 3.2 GHz 1 GB18
Los procesadores actuales como Xeon (2.8 – 3.0 – 3.2) de múltiples cores,pueden generar un mejor rendimiento, así como una cantidad de llamadas másalta.
También es importante que los servidores (el servidor Asterisk y el servidor dondese va alojar la aplicación) se encuentren sobre la misma red con velocidadessuperiores a los 100mb/s. Si se encuentran sobre segmentos distintos o entre unFirewall, debe validarse con el administrador de la red de la organización paraminimizar la latencia entre los dos equipos. Así mismo, el equipo necesita de unservidor DHCP que le asigne automáticamente la IP y que ésta IP tenga permisosde Internet para descargar los paquetes necesarios en el proceso de instalacióndel SO. Es importante que la IP que se asigne sea reservada para que no setengan complicaciones mas adelante con la aplicación.
4. Instalación
4.1 Instalación del SO.
Se suministra la ISO () para 32 y 64 bits que contiene los paquetes necesariospara que se ejecute la aplicación.(basado en Centos 6.6)
Luego de ingresar el CD y arrancar el equipo, aparecerá la siguiente imagen
18 Tomado de http://www.voip-info.org/wiki/view/Asterisk+dimensioning
214
Allí se debe digitar la palabra install y oprimir la tecla enter
215
Luego de oprimir enter, iniciará la instalación del SO:
216
Al finalizar la instalación, se mostrará la siguiente imágen:
217
4.2 Instalación de la aplicación
Luego que se haya reiniciado el servidor, se debe conectar por SSH al puerto 22.Debe loguearse con las siguientes credenciales:
User: root
Clave: sentinel
Luego de loguearse debe digitarse el siguiente comando para proceder con ladescarga del instalador:
wget https://sourceforge.net/projects/sentinelivr/files/Instalador_Sentinel.sh
Con éste comando, se procederá con la descarga del instalador.
Ya descargado el instalador, cambiamos los permisos para permitirle la ejecución
chmod 777
y luego se ejecuta con
sh Instalador_Sentinel.sh
al ejecutarlo, se mostrará las siguientes imágenes:
218
En éste punto, debe ingresarse la dir IP del servidor Asterisk en el cual seencuentra alojado el o los IVR’s
219
Luego se solicitará los últimos octetos de las direcciones IP tanto del servidorAsterisk remoto (donde se alojan los IVR) como donde se alojará la aplicación(Sentinel). Ésta información es necesaria e importante para crear el plan demarcado del servidor Asterisk que va a realizar las llamadas.
Luego de culminar el proceso, el script reiniciará el servidor para aplicar todos loscambios.
Luego del reinicio, ya se podrá acceder a la aplicación por un navegador web conel siguiente link:
http://XXXXXXXX:8081/app.php
donde XXXXXXXX es el nombre o IP del servidor donde se instaló la aplicación.
220
Manual de Usuario Sentinel
1. Objetivo
Operar y administrar la plataforma necesaria para el monitoreo de un IVR.
2. Alcance
Este documento está dirigido a la operación y administración de la aplicacióndesarrollada para el monitoreo de IVR's. El documento está basado para el rolAdministrador pero también aplica para el rol operador, sólo que éste último notiene acceso a la gestión de usuarios, gestión de configuraciones, creación deincidentes, creación de cambios y creación de centinelas.
3. Administración y Operación
3.1 Ingreso
Para ingresar a la aplicación, solo debe ingresar por medio de un navegador webcon el siguiente link:
http://XXXXXXXX:8081/
donde XXXXXXXX es el nombre o IP del servidor donde se instaló la aplicación.
Al momento de cargar la página, se muestra la siguiente imágen:
221
Si es la primera vez, debe ingresar con el usuario admin y clave adminpass, si noes así, debe ingresar con los datos de su cuenta asignada.
3.2 Monitor
Luego de autenticarse en la aplicación, se muestra la siguiente página:
222
Aquí se mostrará el estado de los IVR's monitoreados y a la fecha del último testrealizado a dicho IVR., en el caso en que no se tenga ninguno configurado, noaparecerá ninguna barra. En el caso en que se requiera conocer la información delos test que se han realizado sobre dicho IVR, se debe hacer click sobre el CI yaparecerá en la parte inferior la lista de test que se han realizado sobre ese IVR:
223
así mismo, si se desea conocer el detalle de cada test realizado, se debe hacerclick sobre la el ID del test y aparecerá una ventana al lado derecho de ésta con eldetalle de las llamadas.
224
Adicionalmente, al ubicar el cursor del mouse sobre la barra, se mostrará la fecha inicial y la fecha final en el que el IVR estuvo en ese estado.
225
3.3 Gestión de Usuarios
El siguiente módulo es la gestión de usuarios y está identificado por el siguienteicono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
226
En esta página se puede
• Editar Usuario:
Se debe hacer click sobre el botón editar el cual desplegará la siguiente pantalla:
227
Allí se pueden editar los campos usuario, correo electrónico, activar o desactivar elusuario, nombre, apellidos y rol. Luego de realizar el cambio, debe hacerse clicken actualizar y lo llevará de nuevo a la pantalla de lista de usuarios.
• Modificar Cuenta
Se debe hacer click sobre el nombre de usuario
y se desplegará la siguiente pantalla:
228
229
En ésta pagina se puede Desactivar / Activar, bloquear / Desbloquear el usuario,cambiar / expirar contraseña.
Sólo se debe hacer click en el botón y se procederá a realizar la acción.
Para bloquearlo, aparecerá el botón rojo
Para desbloquearlo, aparecerá el botón verde
Para desactivar el usuario, aparecerá el botón rojo
Para activar el usuario, aparecerá el botón verde
• Eliminar Usuario
Para eliminar el usuario, sólo debe hacerse click sobre el botón eliminar delusuario que se va a eliminar:
Luego de hacer click en el botón, el usuario desaparecerá del listado y se mostraráel siguiente mensaje
230
• Crear usuarios
Para crear usuario,, sólo debe hacer click sobre el botón nuevo usuario
Y desplegará la siguiente pantalla:
231
232
Allí solo debe diligenciarse los datos que se solicitan y hacer click en el botóncrear
3.4 Módulo de Configuración
El siguiente módulo es la gestión de configuración y está identificado por elsiguiente icono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
233
En ésta pagina se puede realizar las siguientes configuraciones:
• CIs
Luego de hacer click en Cis, se desplega la siguiente ventana:
En esta página se puede realizar las siguientes configuraciones:
• Agregar CI
Para agregar un CI, sólo debe hacerse click sobre el botón Agregar
Luego de hacer click en el botón agregar, desplegará la siguiente ventana:
234
Luego de diligenciar los campos necesarios, sólo debe hacerse click en elbotón crear y la aplicación lo redireccionará a la lista de CIs con el nuevo CIcreado.
• Editar CI
Para editar un CI, sólo debe hacerse click sobre el botón Editar
Luego de hacer click en el botón editar, desplegará la siguiente ventana:
235
Allí se deben modificar los campos que se desee y luego hacer click enActualizar.
236
• Asociar Extensión
Luego de que se cree el CI, se debe asociar la extensión en donde seencuentra configurado el IVR que se va a monitorear, para asociarla sedebe hacer click en el botón asociar
Luego de hacer click en el botón editar, desplegará la siguiente ventana:
En este punto se debe diligenciar el numero de la extensión, la criticidad,persistencia y la guía de audio que se tiene configurada para ese primernivel.
Luego de diligenciar la información solicitada, se debe hacer click en elbotón crear
Si se quiere ver las extensiones ya creadas, se puede hacer click en elbotón Listar Extensiones y se mostrará la siguiente página:
237
• Eliminar CI
Para eliminar el CI, sólo debe hacerse click sobre el botón eliminar del CIque se va a eliminar:
Luego de hacer click en el botón, el CI desaparecerá del listado y semostrará el siguiente mensaje
238
• Extensiones Raíz
Luego de hacer click en Extensiones Raiz, se desplega la siguiente ventana:
En esta página se puede realizar las siguientes configuraciones:
• Crear Hijo
Para agregar un hijo o nodo a la extensión Raiz, sólo debe hacerse clicksobre el botón Crear Hijo
Luego de hacer click en el botón agregar, desplegará la siguiente ventana:
239
En esta pagina se debe diligenciar:
- Dígito: el dígito que se debe marcar para tomar esa opción.
- Tipo de Nodo: Normal si es un nodo intermedio o final si es el último nodode una opción
- Función del Nodo: Informativo, si es un nodo que tiene configurado unaguía de audio. Transferencia, si es un nodo en donde se transfiere a otraextensión o agente.
- Parámetro a validar: se diligencia el parámetro que se va a validar, si esuna guía de voz, se debe colocar el nombre completo tal como estáconfigurado en el servidor de telefonía donde está el IVR. Si es un nodo de
240
transferencia, se debe diligenciar el nro. de la extensión, al cual se va atransferir.
– Criticidad: La criticidad del nodo.
- Descripción: una breve descripción del nodo.
Luego de diligenciar los campos necesarios, sólo debe hacerse click en elbotón crear y la aplicación lo redireccionará a la lista de hijos de ese nodocon el nuevo nodo creado.
• Ver Hijos
Luego de hacer click en el botón Ver Hijos, se mostrará la siguiente página:
En está pagina se mostrará las opciones (dígitos) configuradas para esenodo
Al igual que la opción anterior, aquí también se puede crear hijos, ver hijos yeliminar.
• Eliminar
Para eliminar el hijo, sólo debe hacerse click sobre el botón eliminar de laraíz (hijo u opción en caso de encontrase en la lista de hijos) que se va aeliminar:
241
Luego de hacer click en el botón, la raiz o hijo desaparecerá del listado y semostrará el siguiente mensaje
• Parámetros de la Aplicación
Luego de hacer click en Parámetros de la aplicación, se desplega la siguienteventana:
En esta página se puede realizar las siguientes configuraciones:
• Bases de Datos
Si en la lista desplegable se escoge la opción de Bases de Datos, sedesplegará la siguiente ventana:
242
Allí se puede modificar los datos asociados a la base de datos de laaplicación.
• Servidor de Correo
Si en la lista desplegable se escoge la opción de servidor de correo, sedesplegará la siguiente ventana:
243
Allí se puede modificar los datos asociados al servidor de correo o smtp quese va a usar para enviar las notificaciones de correo.
• Servidor Asterisk Local
Si en la lista desplegable se escoge la opción de Servidor Asterisk Local, sedesplegará la siguiente ventana:
244
Allí se puede modificar los datos asociados al servidor de telefonía que seva a usar para realizar las llamadas telefónicas automáticas.
245
• Servidor de telefonía Remoto
Si en la lista desplegable se escoge la opción de Servidor de telefoníaRemoto, se desplegará la siguiente ventana:
Allí se puede modificar los datos asociados al servidor de telefonía dondese encuentra configurado el IVR.
246
• Respaldo de la BD
Al hacer click en dicho botón, la aplicación realizará un backup de la basede datos y lo depositará en la seiguiente ruta del servidor$SENTINELHOME/db_bk con la fecha y hora del backup
Al realizarlo, la aplicación mostrará el siguiente mensaje:
3.5 Módulo de Incidentes
El siguiente módulo es la gestión de incidentes y está identificado por el siguienteicono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
247
En esta página se muestran todos los incidentes en estado abierto. Aquí se puederealizar las siguientes acciones:
• Crear incidente
Si se necesita crear un incidente adicional al incidente que se creaautomáticamente cuando se presenta una alarma en alguno de los IVR, se haceclick en crear y se mostrará la siguiente ventana:
248
Luego de diligenciar los datos solicitados (código de cierre y solución no sonnecesarios en el momento de la creación) se hace click en crear y se direccionaráa la lista de incidentes, mostrando el nuevo incidente
• Actualizar incidente
Si se necesita modificar un incidente se hace click en actualizar y se mostrará lasiguiente ventana:
Aquí se puede modificar la documentación de un incidente o cerrarlo en caso enque se necesite cerrarse sin que se haya normalizado el estado del IVR. Luego decerrarlo, el incidente ya no aparecerá en la lista de incidentes por encontrarse enestado cerrado
249
3.6 Módulo de Cambios
El siguiente módulo es la gestión de cambios y está identificado por el siguienteicono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
En esta página se muestran todos los cambios en estado abierto. Aquí se puederealizar las siguientes acciones:
• Crear Cambio
Si se necesita modificar algún parámetro de la aplicación, se debe documentarcon un cambio y para crearlo, se hace click en crear y se mostrará la siguienteventana:
250
Luego de diligenciar los datos solicitados (solución no es necesaria en el momentode la creación) se hace click en crear y se direccionará a la lista de cambios,mostrando el nuevo cambio.
• Actualizar Cambio
Si se necesita modificar un cambio se hace click en actualizar y se mostrará lasiguiente ventana:
251
Aquí se puede modificar la documentación de un cambio o cerrarlo en caso enque se necesite cerrarse por algún motivo. Luego de cerrarlo, el cambio ya noaparecerá en la lista de cambios por encontrarse en estado cerrado.
252
3.7 Módulo de Reportes
El siguiente módulo es la gestión de cambios y está identificado por el siguienteicono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
En esta página se pueden generar dos tipos de reportes
• Reportes Automáticos
Si se necesita crear un reporte que se ejecute periódica y automáticamente, sedebe escoger la opción automático, luego de hacer click en dicha opción, semostrará la siguiente pantalla
253
En esta página se muestra el listado de los centinelas configurados sobre laplataforma, así como el estado de los mismos. Adicionalmente, se pueden realizarlas siguientes acciones sobre un Centinela:
• Crear Reporte Automático
Para crear el reporte automático, solo debe hacerse click sobre el botóncrear y se mostrará el siguiente formulario:
254
En esta pagina se debe diligenciar:
- IVR: Se debe seleccionar el IVR del cual se va a generar el reporte
- Periodicidad: Se debe escoger la cantidad de periodo de ejecución a ejecutar elreporte (por ejemplo cada 2 horas, o cada 2 días, etc)
- Periodo de ejecución: Este campo es el complemento del anterior, en el cuadroanterior se indica la cantidad y en éste se escoge si es horas, días, semanas, etc,
- Intervalo Reporte: Aquí se debe escoger del intervalo que se va a generar elreporte automático (último Día, última semana, etc)
Luego de haber diligenciado todos los datos, se hace click sobre el botón crear yla aplicación lo direccionará nuevamente a la lista de reportes automáticos y endonde aparecerá el nuevo reporte.
• Editar Reporte Automático
Para editar el reporte automático, solo debe hacerse click sobre el botóneditar y se mostrará el mismo formulario que se muestra al momento decrearlo, la diferencia es que se muestra los datos con los que ya estabacreado el centinela que se quiere modificar.
255
Luego de modificar los datos que desea modificar, se hace click sobre actualizar yla aplicación lo direcciona nuevamente a la lista de centinelas.
• Eliminar Reporte Automático
Para eliminar el reporte automático, solo debe hacerse click sobre el botóneliminar y se mostrará el siguiente mensaje en la aplicación.
Y el reporte automático no se mostrará mas en la aplicación.
256
• Desactivar Reporte Automático
Para desactivar el Reporte Automático, solo debe hacerse click sobre el botóndesactivar y se mostrará el siguiente mensaje en la aplicación.
Y el Reporte Automático mostrará ahora el botón activar.
• Activar Reporte Automático
Para activar el Reporte Automático, solo debe hacerse click sobre el botón Activary se mostrará el siguiente mensaje en la aplicación.
Y el Reporte Automático mostrará ahora el botón desactivar.
257
• Reporte Manual
Si se necesita crear un reporte que se ejecute sólo na vez, se debe escoger laopción manual, luego de hacer click en dicha opción, se mostrará la siguientepantalla :
En esta pagina se debe diligenciar:
- IVR: Se debe escoger el IVR del cual se va a generar el reporte.
- Intervalo de reporte: Para éste intervalo se tienen unos valores predefinidos:
258
Sin embargo, se puede escoger la opción Personalizado, en el cual puedeescoger la fecha inicial y fecha inicial del cual requiere el reporte:
Luego de escoger la opción que requiera, se debe hacer click en el botón Generar,el cual mostrará la página con el reporte solicitado.
259
En esta página se muestra un gráfico circular con el comportamiento del IVR delperiodo seleccionado:
En la parte inferior, aparecerá los datos de los test realizados por el centinela. Aligual que en el monitor del inicio, si se realiza click sobre el ID del test, se mostrarámas abajo el detalle de dicho test.
260
Haciendo click sobre el botón Exportar, se generará un archivo html con lainformación del reporte.
3.8 Módulo de Centinela
El siguiente módulo es el de centinelas y está identificado por el siguiente icono:
Al hacer click sobre dicho icono, aparecerá la siguiente imagen:
261
En esta página se muestra el listado de los centinelas configurados sobre laplataforma, así como el estado de los mismos. Adicionalmente, se pueden realizarlas siguientes acciones sobre un Centinela:
• Crear Centinela
Para crear el centinela, solo debe hacerse click sobre el botón crear y se mostraráel siguiente formulario:
262
En esta pagina se debe diligenciar:
- Nombre: El nombre que se le va a asignar a dicho centinela.
- Estado: El centinela se puede crear habilitado o deshabilitado. Se si creadeshabilitado no se ejecutará periódicamente.
- Periodicidad: Se debe escoger la cantidad de periodo de ejecución a ejecutar(por ejemplo cada 2 horas, o cada 2 días, etc)
- Periodo de ejecución: Este campo es el complemento del anterior, en el cuadroanterior se indica la cantidad y en éste se escoge si es horas, días, semanas, etc,
- Monitorea: Aquí se debe escoger el CI que va a monitorear el centinela que se vaa crear.
Luego de haber diligenciado todos los datos, se hace click sobre el botón crear yla aplicación lo direccionará nuevamente a la lista de centinelas y en dondeaparecerá el nuevo centinela.
• Editar Centinela
Para editar el centinela, solo debe hacerse click sobre el botón editar y semostrará el mismo formulario que se muestra al momento de crearlo, la diferenciaes que se muestra los datos con los que ya estaba creado el centinela que sequiere modificar.
263
Luego de modificar los datos que desea modificar, se hace click sobre actualizar yla aplicación lo direcciona nuevamente a la lista de centinelas.
• Eliminar Centinela
Para eliminar el centinela, solo debe hacerse click sobre el botón eliminar y semostrará el siguiente mensaje en la aplicación.
Y el centinela no se mostrará mas en la aplicación.
264
• Desactivar Centinela
Para desactivar el centinela, solo debe hacerse click sobre el botón desactivar yse mostrará el siguiente mensaje en la aplicación.
Y el centinela mostrará ahora el botón activar.
• Activar Centinela
Para activar el centinela, solo debe hacerse click sobre el botón Activar y semostrará el siguiente mensaje en la aplicación.
Y el centinela mostrará ahora el botón desactivar.
• Ejecutar Centinela
Para ejecutar el centinela manualmente, solo debe hacerse click sobre el botónejecutar y mostrará que la página se encuentra procesando:
265
Al finalizar, se direccionará hacia la pagina inicial de la aplicación donde se puedevisualizar el resultado del centinela ejecutado.
266
Manual de restauración de BD de Sentinel
1. Objetivo
Restaurar la BD de la aplicación.
2. Alcance
Este documento está dirigido a la restauración de la BD de Sentinel queoriginalmente se encuentra en PostgreSQL 9,5 y con el nombre pixqui_db. Si semodifica alguno de éstos dos parámetros anteriores, la restauración no podríafuncionar por lo que debería dirigirse al administrador de base de datos de suorganización.
3. Definiciones
Sentinel consta de una sola base de datos llamada pixqui_db. Cuando desde laaplicación se realiza un backup de ésta, el archivo queda en la siguiente ruta en elservidor:
$SENTINELHOME\db_bk
cómo se muestra en la siguiente imagen, los backups quedan con el nombre de laBD y la fecha en el que se genera
para realizar el proceso de restauración, se deben cerrar todos los accesos webque se tengan a la aplicación y desconectar las sesiones remotas que se tenganhacia la BD. (por ejemplo desde un PGAdmin)
267
4. Instalación
Para realiza la restauración de la Base de Datos, debe loguearse al servidor porSSH con el usuario root que se suministró en la insalación:
Luego de logueo, debe dirigirse a la carpeta $SENTINELHOME/db_bk
Cuando se encuentre en dicha ruta, debe visualizar los backup que se hangenerado de la aplicación:
Se debe seleccionar el backup que se va a restaurar y copiandolo con el nombreactual.sql, dicha copia se ejecutando el siguiente comando:
cp -rfv XXXXXX.sql actual sql
Donde XXXXX es el nombre del archivo que se va a restaurar:
Ej:
268
Si ya se ha hecho el proceso, se solicitara autorización de sobrescribir el archivoactual.sql, a lo cual se responderá que si
Luego de tener el archivo que se va a restaurar, se procede a ejecutar el script querealiza la restauración, ejecutando el siguiente comando:
sh script_restaurar_bd.sh
Luego de ejecutarlo, el genera un log en la misma carpeta con el proceso derestauración y con la fecha de restauración con el nombre:restaurar_pixquidb_$fecha.log
En dicho log se puede evidenciar si el proceso se ejecuto satisfactoriamente o porel contrario tuvo algún error. Igualmente, se mostrará en pantalla el proceso:
269
270
