Proyecto de Redes de Datos

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
TESIS DE GRADO
“CONSULTAS REMOTAS A UN SERVIDOR DE BASE DE DATOS

POR MEDIO DE LAS REDES DE TELEFONÍA”
Para obtener el Título de Licenciatura en Informática

Mención: Ingeniería de Sistemas Informáticos
POR: CESAR NILTON ROJAS VALERO

TUTOR: M.SC. ROSA FLORES MORALES
ASESOR: LIC. CELIA ELENA TARQUINO PERALTA
LA PAZ – BOLIVIA
2013
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
DEDICATORIA
A mi madre, que es un apoyo invaluable para mí, que

me impulsa a creer que todo en este mundo es
posible con la ayuda de Dios.
AGRADECIMIENTOS
A Dios nuestro Señor, sin tu ayuda Padre Amado nunca lo hubiese logrado… gracias.
A mi madre y hermanos, por estar siempre dispuestos y prestos a colaborarme en todo lo

que necesito.
A mi novia, que con tremenda paciencia logró soportar mi mal humor e irritabilidad.
A mi Asesora Lic. Celia Elena Tarquino Peralta, por su disponibilidad y sugerencias en

el proceso de revisión de este trabajo.
A mi Tutora M.Sc. Rosa Flores Morales, por sus aportes, sugerencias y observaciones
que apoyaron a la conclusión de este trabajo.
ÍNDICE
ÍNDICE DE CONTENIDOS I
ÍNDICE DE FIGURAS V
ÍNDICE DE TABLAS VII
RESUMEN VIII
ÍNDICE DEL CONTENIDO
1 MARCO PRELIMINAR ............................................................................... 1

1.1 Introducción ..................................................................................................... 1
1.2 Antecedentes .................................................................................................... 3
1.2.1 Antecedentes de la institución ......................................................................... 3
1.2.2 Antecedentes del tema ..................................................................................... 4
1.3 Planteamiento del problema............................................................................. 8
1.3.1 Formulación del problema ............................................................................... 9
1.4 Objetivos .......................................................................................................... 9
1.4.1 Objetivo general ............................................................................................... 9
1.4.2 Objetivos específicos ....................................................................................... 9
1.5 Justificación ................................................................................................... 10
1.5.1 Justificación económica ................................................................................. 10
1.5.2 Justificación tecnológica ................................................................................ 10
1.6 Metodologías y herramientas ......................................................................... 11
1.6.1 Recolección de datos e información .............................................................. 11
1.6.2 Metodología ................................................................................................... 11
1.7 Alcance, límites y aportes .............................................................................. 12
1.7.1 Alcances ......................................................................................................... 12
1.7.2 Límites ........................................................................................................... 13
1.7.3 Aportes ........................................................................................................... 14
2 MARCO TEÓRICO .................................................................................... 15
2.1 Introducción ................................................................................................... 15
2.2 La telefonía tradicional .................................................................................. 15
2.2.1 Sistemas analógicos ....................................................................................... 16
2.2.2 Sistemas digitales........................................................................................... 16
2.2.2.1 Red Digital de Servicios Integrados .............................................................. 16
2.2.2.2 E1/T1 ............................................................................................................. 16
2.2.3 Redes móviles ................................................................................................ 16
2.2.3.1 GSM ............................................................................................................... 16
2.2.3.2 UMTS ............................................................................................................ 17
2.2.3.3 4G................................................................................................................... 18
2.2.4 Centralitas tradicionales PBX ........................................................................ 18
2.3 VoIP ............................................................................................................... 19
2.3.1 Arquitectura general del sistema de telecomunicaciones .............................. 19
2.3.2 Protocolo de señalización en VoIP ................................................................ 20
2.3.2.1 Session Initiation Protocol (SIP).................................................................... 21
2.3.2.2 H323............................................................................................................... 22
2.3.2.3 Inter-Asterisk eXchange (IAX) ..................................................................... 22
2.4 Asterisk .......................................................................................................... 22
2.4.1 Arquitectura ................................................................................................... 23
2.4.2 Interfaces de programación de aplicaciones .................................................. 24
2.4.2.1 Asterisk Manager Interface, AMI .................................................................. 24
2.4.2.2 Asterisk Gateway Interface, AGI................................................................... 25
2.4.3 PHP-AGI para Asterisk ................................................................................. 27
2.5 Dialplan o plan de marcado ........................................................................... 28
2.5.1 Contextos ....................................................................................................... 28
2.5.2 Extensiones .................................................................................................... 29
2.5.3 Prioridades ..................................................................................................... 30
2.5.4 Aplicaciones y funciones ............................................................................... 31
2.5.5 Interactive Voice Response (IVR) ................................................................. 31
2.6 Sintetización de voz - Text To Speach (TTS)................................................ 33
2.6.1 Análisis textual .............................................................................................. 34
2.6.2 Análisis lingüístico ........................................................................................ 34
2.6.3 Generación de la prosodia.............................................................................. 35
2.6.4 Festival ........................................................................................................... 35
2.7 Metodología ágil ............................................................................................ 36
2.7.1 Scrum ............................................................................................................. 37
2.8 Norma IEEE 830 ............................................................................................ 40
3 MARCO APLICATIVO ............................................................................. 43
3.1 Introducción ................................................................................................... 43
3.2 Definición de roles ......................................................................................... 43
3.3 Recopilación de requerimientos..................................................................... 43
3.3.1 Historias de usuario ....................................................................................... 44
3.3.2 Especificación de requerimientos en base a la norma IEEE 830 ................... 47
3.3.2.1 Introducción ................................................................................................... 47
3.3.2.1.1 Propósito ........................................................................................................ 47
3.3.2.2 Descripción general del producto .................................................................. 47
3.3.2.2.1 Perspectiva del producto ................................................................................ 47
3.3.2.2.1.1 Interfaces de usuario .................................................................................. 48
3.3.2.2.1.2 Interfaces de hardware ............................................................................... 49
3.3.2.2.1.3 Interfaz de software .................................................................................... 50
3.3.2.2.1.4 Interfaz de comunicación ........................................................................... 51
3.3.2.2.1.5 Operaciones ................................................................................................ 51
3.3.2.2.2 Funciones del producto .................................................................................. 52
3.3.2.2.2.1 Consultas a almacén ................................................................................... 56
3.3.2.2.3 Atenciones y dependencias ............................................................................ 60
3.4 Agenda del proyecto ...................................................................................... 61
3.5 Desarrollo del Sprint ...................................................................................... 61
3.5.1 Sprint 1........................................................................................................... 62
3.5.1.1 Planificación .................................................................................................. 62
3.5.1.2 Desarrollo....................................................................................................... 64
3.5.1.3 Finalización del Sprint 1 ................................................................................ 67
3.5.2 Sprint 2........................................................................................................... 69
3.5.2.1 Planificación .................................................................................................. 69
3.5.2.2 Desarrollo....................................................................................................... 70
3.5.3 Sprint 3........................................................................................................... 81
3.5.3.1 Planificación .................................................................................................. 81
3.5.3.2 Desarrollo....................................................................................................... 82
3.5.4 Sprint 4........................................................................................................... 88
3.5.4.1 Planificación .................................................................................................. 88
3.5.4.2 Desarrollo....................................................................................................... 89
3.5.5 Sprint 5........................................................................................................... 95
3.5.5.1 Planificación .................................................................................................. 95
3.5.5.2 Desarrollo....................................................................................................... 97
3.5.5.3 Finalización del Sprint 5 .............................................................................. 103
3.6 Pruebas, verificación y validación de resultados ......................................... 104
4 CONCLUSIONES Y RECOMENDACIONES ...................................... 110
4.1 Conclusiones ................................................................................................ 110
4.2 Recomendaciones ........................................................................................ 112
BIBLIOGRAFÍA ................................................................................................................
ANEXO A - Cuadro comparativo de servicio de internet en Sud América .................
ANEXO B - Situación actual de la cobertura de internet móvil en Bolivia ..................
ANEXO C - Canales de comunicación estándar .............................................................
ANEXO D - Modelos de formularios de evaluación del sistema IVR ...........................
Formulario de evaluación – subsistema de consultas a almacén .........................................
Formulario de evaluación – subsistema de alertas ...............................................................
ANEXO E - Reglamento de almacén – Experts Inova Networks srl.............................
ANEXO F - Requerimientos del sistema ivr según la metodología scrum ...................
Historias de usuario ..............................................................................................................
Pila del producto ..................................................................................................................
Fichas de usuario ..................................................................................................................
Actividades de ingeniería - Historias técnicas .....................................................................
Fichas técnicas .....................................................................................................................
ANEXO G - Casos de uso para las funciones del sistema IVR ......................................
Módulo área de ventas .........................................................................................................
Módulo de área administrativa .............................................................................................
Subsistema de alerta de desabastecimiento ..........................................................................
ÍNDICE DE FIGURAS
Figura 2.1: Arquitectura general de la telefonía tradicional ........................................................ 15
Figura 2.2: Arquitectura general de VoIP..................................................................................... 20
Figura 2.3: Proceso de registro entre clientes y el servidor proxy. La señalización (SIP) y
las conversaciones de voz (RTP) viajan por caminos diferentes.................................................. 21
Figura 2.4: Arquitectura de Asterisk ............................................................................................ 24
Figura 2.5: Lógica de funcionamiento de AGI .............................................................................. 25
Figura 2.6: Sintaxis de configuración básica de dialplan para una extensión .............................. 30
Figura 2.7: Sintaxis de configuración ........................................................................................... 30
Figura 2.8: Esquema de Conversión de texto a voz con Festival. ................................................ 36
Figura 2.9: Flujo de la metodología Scrum .................................................................................. 39
Figura 2.10: Estructura de una ERS según IEEE 830 ..................................................................... 42
Figura 3.1: Fichas de historias de usuario .................................................................................... 46
Figura 3.2: Ficha de historia técnica ............................................................................................ 48
Figura 3.3: Interfaz de usuario ..................................................................................................... 49
Figura 3.4: Interfaz de hardware.................................................................................................. 50
Figura 3.5: Interfaz de software ................................................................................................... 51
Figura 3.6: Diagrama de paquetes del sistema IVR ..................................................................... 53
Figura 3.7: Diagrama de flujo de IVR principal y consultas a almacén ........................................ 54
Figura 3.8: Diagrama de flujo de alertas automáticas ante desabastecimientos ........................ 55
Figura 3.9: Diagrama de caso de uso – subsistema consultas a almacén .................................... 56
Figura 3.10: Cronograma de agenda de proyecto Scrum ............................................................ 61
Figura 3.11: Backlog inicial, Sprint 1 ............................................................................................ 63
Figura 3.12: Backlog inicial, Sprint 1 ............................................................................................ 63
Figura 3.13: Configuración para integrar Asterisk y festival. ....................................................... 64
Figura 3.14: comando para acceder al log de actividades en tiempo real de Asterisk ................ 65
Figura 3.15: Código de prueba de funcionamiento de Festival ................................................... 66
Figura 3.16: Configuración para acceso remoto a MySQL ........................................................... 66
Figura 3.17: Cadena de conexión a base de datos remota con AdoDB y éxito de conexión ....... 66
Figura 3.18: Comando de cron en Crontab para realización de una tarea .................................. 67
Figura 3.19: Detalle del log de actividades y tareas ejecutadas por el comando Cron ............... 67
Figura 3.20: Backlog Final – Sprint 1 ............................................................................................ 68
Figura 3.21: Burdown Final - Sprint 1........................................................................................... 68
Figura 3.22: Cronograma estimado para el Sprint 2 .................................................................... 69
Figura 3.23: Backlog inicial Sprint 2 ............................................................................................. 70
Figura 3.24: Sistema de grabación de mensajes .......................................................................... 73
Figura 3.25: Flujo de llamada para el IVR principal, subsistema de consultas a almacén ........... 75
Figura 3.26: Flujo de llamada para el IVR del subsistema de alertas ante desabastecimiento ... 76
Figura 3.27: Log de sucesos internos en Asterisk durante el flujo de inicio llamada .................. 78
Figura 3.28: Contexto para enlace a sistema IVR principal, subsistema de consultas a almacén 78
Figura 3.29: Comportamiento respecto a la elección de la primera opción del menú principal 79
Figura 3.30: Comportamiento respecto a la elección de la segunda opción del menú principal 79
Figura 3.31: Backlog final sprint 2 ................................................................................................ 80
Figura 3.35: Consulta para validación de acceso a usuario ......................................................... 83
Figura 3.36: Consulta para obtención de datos respecto a los productos en almacén. .............. 84
Figura 3.37: Mensaje de petición de ingreso de clave y mensaje de clave invalida .................... 85
Figura 3.38: Mensaje de petición de ingreso de código de producto y mensaje de código
invalido ......................................................................................................................................... 86
Figura 3.39: Mensaje de petición de ingreso de código de producto y mensaje de código valido
..................................................................................................................................................... 86
Figura 3.44: Flujo de llamada - Subsistema de consultas a almacén ........................................... 90
Figura 3.45: Resultados de una consulta a base de datos remota .............................................. 92
Figura 3.46: Formato de cadenas a ser sintetizadas por festival ................................................. 92
Figura 3.47 Sintetización de información referente a stock actual y dictado de opciones de
consulta ........................................................................................................................................ 93
Figura 3.48: Verificación de la funcionalidad de la opción cuatro del menú de consultas ......... 93
Figura 3.50: Burdown Final – Sprint4........................................................................................... 94
Figura 3.53: Consulta para conteo de productos desabastecidos. .............................................. 97
Figura 3.54: Consulta para obtención de datos de usuario autorizado. ...................................... 98
Figura 3.55: Contexto para enlace a sistema IVR – subsistema de alertas.................................. 98
Figura 3.56: Registro de actividades durante la llamada automática.......................................... 99
Figura 3.57: Registro del flujo de llamada inicial para el subsistema de alertas ante
desabastecimiento ..................................................................................................................... 100
Figura 3.58: Resultados de consulta a base de datos remota ................................................... 100
Figura 3.59: Consulta para obtención de datos de productos desabastecidos. ........................ 101
Figura 3.60: Formato de cadenas a ser sintetizadas por festival ............................................... 102
Figura 3.61: Comprobantes de envío de correo electrónico ..................................................... 102
Figura 3.62: Backlog final Sprint 5.............................................................................................. 103
Figura 3.63: Burdown Final – Sprint 5 ........................................................................................ 104
Figura 3.64: Intentos de validación de usuario para acceso a los subsistemas de consultas y
alertas ........................................................................................................................................ 105
Figura 3.65: Log de actividades durante rechazo de llamadas .................................................. 105
Figura 3.66: Disponibilidad del sistema IVR durante la evaluación ........................................... 107
Figura 3.67: Causas para la no accesibilidad al sistema IVR ...................................................... 107
Figura 3.68: Éxito de obtención de información de los productos en almacén ........................ 108
Figura 3.69: Claridad de la voz emitida por el sistema IVR para la entrega de información de
productos ................................................................................................................................... 108
Figura 3.70: Reutilización del sistema IVR ................................................................................. 109
ÍNDICE DE TABLAS
Tabla 2.1: Requerimientos mínimos según los propósitos .......................................................... 22

Tabla 3.1: Historias de usuario ..................................................................................................... 44
Tabla 3.2: Pila de producto .......................................................................................................... 45
Tabla 3.3: Historias técnicas......................................................................................................... 46
Tabla 3.4: Caso de uso 3.1 - Recibir información ......................................................................... 57
Tabla 3.5: Caso de uso 3.2 – Atención al cliente.......................................................................... 57
Tabla 3.6: Caso de uso 3.3 – Validar usuario ............................................................................... 58
Tabla 3.7: Caso de uso 3.4 – Ingresar código de producto .......................................................... 58
Tabla 3.8: Caso de uso 3.5 – Validar código de producto ............................................................ 59
Tabla 3.9: Caso de uso 3.6 – Entregar información consultada ................................................... 60
Tabla 3.10: Scripts de grabaciones para el sistema IVR ............................................................... 71
Tabla 3.11: Zonas sin acceso óptimo a una red de telefonía ..................................................... 106
Resumen
El requerimiento de la información en tiempo real se ha convertido en una necesidad

para varias empresas en nuestro medio. En busca de lograr un medio de conexión a una
base de datos alternativo al internet, se optó por el uso de las redes de telefonía. A través
de la experimentación con el sistema web de control y gestión de almacenes de Inova
Networks y su central de telecomunicaciones Asterisk, se verificó que dicha empresa
contaba con la necesidad de acceder a la información de los productos registrados en su
sistema web, también se verificó la necesidad de contar con un sistema de alertas que
informe automáticamente el desabastecimiento de alguno de sus productos.
Para tal fin, se creó un sistema interactivo de respuesta de voz (IVR) basado en Asterisk,
que permite al usuario acceder, por medio de las redes de telefonía, a la información de
productos registrados en la base de datos de un sistema web, por medio de scripts
programados en lenguaje PHP y la utilización de la interfaz pasarela de Asterisk. Para el
sistema de alertas se utilizó, como herramienta fundamental, el demonio Cron, con el
que se verifica cada dos minutos las cantidades existentes de los productos en almacén,
si se halla algún desabastecimiento, se ejecuta un programa encargado de utilizar la
funcionalidad outgoing de Asterisk, el cual permite realizar llamadas automáticamente.
Los resultados obtenidos una vez concluido el proyecto, demostraron que la información
requerida es proporcionada por el sistema IVR en tiempo real. Las alertas respecto al
desabastecimiento de productos fueron oportunas, permitiendo realizar una correcta
toma de decisiones y un mejor control del almacenamiento de los productos.
Se concluye que el uso de la tecnología IVR, como mediador al acceso de información

almacenada en una base de datos remota, es factible y funcional, aún más si se utilizan
herramientas y software con licencia de dominio público.
Palabras clave: Consultas remotas, base de datos, redes de telefonía, respuesta de voz
interactiva (IVR), Asterisk.
Abstract
The requirement of real-time information has become a necessity for several companies
in our environment. Looking for an alternative means of connecting to alternate database
to the internet, it was opted by the use telephone networks. Through the experimentation
with the web system of control and management of Inova Network‟s stores and the
telecommunications exchange Asterisk, was verified that the company had the necessity
to access the information of product stored on their web system. Also it is verified the
necessity for an alert system that automatically reports the shortages of any of its
products.
To reach this objective, it was created an interactive voice response (IVR) based on
Asterisk , which allows users to access , through telephone networks , information
products registered in the database of a web system, programmed through scripts in PHP
and using the Asterisk gateway interface. To alert system was used as a fundamental
tool, the Cron daemon, with which checks every two minutes existing quantities of
products in stock, if a shortage is, runs a program in charge of using the functionality
outgoing of Asterisk, which allows automatic call.
The results obtained after the completed project, showed that the information required is
provided by the IVR system in real time. Regarding alerts the shortages of products were
timely; it allows a correct decision-making and better control of the storage of the
products.
It is concluded that the use of technology IVR, as mediator to access information stored
in a remote database, is feasible and functional, even more if tools and software are
licensed in the public domain.
Keywords: Remote queries, database, networks of telephony, interactive voice response

(IVR), Asterisk.
1 MARCO PRELIMINAR
1.1 Introducción
Actualmente la cobertura de telefonía móvil va creciendo vertiginosamente,
convirtiéndolo en un gran candidato para solventar las necesidades de conectividad. Una
de las aplicaciones más utilizadas en base a este medio es el sistema IVR (Intereactive
Voice Responce, Respuesta Interactiva de Voz) el mismo que puede ser considerado
como una tecnología CTI1 (Computer Telephone Integration) que permite la
interactividad entre los usuarios y computadoras por medio de aplicaciones escritas en
un determinado lenguaje de programación.
En el territorio boliviano, según la Autoridad de Transportes y Telecomunicaciones

(ATT, 2012) basados en los resultados del informe de la Unión Internacional de
Telecomunicaciones (UIT, Union International of Telecomunications) (UTI, 2012, p. 7),
el crecimiento de las TIC‟s corresponde a un índice de crecimiento del 3.13 para el 2011
respecto al 2.93 de la gestión 2010, teniendo entre los principales avances las redes de
telefonía móvil, con un total de 8.79 millones de abonados y una cobertura física
abarcada por un mil quinientos cuarenta y cuatro radio bases en el territorio boliviano,
dicha cifra refleja un incremento de un 350% respecto a la gestión 2008 (MOPSV,
2012, pág. 84).
La empresa Inova Networks se encontraba en la necesidad de acceder a la información

de su sistema de control de almacenes en forma remota y en tiempo real, con el fin de
mejorar la productividad de dicha empresa, contar con las cantidades reales existentes
de los diversos productos almacenados, planificar correctamente los proyectos que
inicia, evitar problemas de sobre almacenaje y preventa de productos con stock cero.
1
Las tecnologías CTI son un conjunto de componentes tanto de hardware como de software capaz de
traducir señales entre sistemas telefónicos y computadores con el objetivo de manipular llamadas para
integrarlas a servicios especiales por medio de procesos computacionales.
1
También se vio la necesidad de contar con un sistema automático que informe sobre el
desabastecimiento de productos oportunamente.
La obtención de información desde el sistema de control de almacenes, realizado a

través de una conexión a internet móvil se ve limitada, pues a pesar del crecimiento de
las TIC‟s en nuestro medio, se evidencia que la conectividad a internet es una de las más
caras y lentas en la región, según la comparativa de costos y velocidad de conexión
presentada en el anexo A. Por lo que se vio necesario buscar distintas formas de acceder
a la información registrada en bases de datos externos o remotos, sin la necesidad de
depender exclusivamente de una conexión a internet.
En el presente proyecto se diseña e implementa un sistema IVR, el cual posibilita la

integración de la red de telefonía conmutada (RTC2) y la red de telefonía móvil, con un
sistema web de control de almacenes, permitiendo al usuario acceder a la información de
los productos almacenados y registrados en la base de datos de dicho sistema.
Para la elaboración del sistema IVR se utilizó la metodología sistémica, reconociendo

los problemas y documentándolos utilizando la recopilación de historias de usuario
planteado por la metodología de desarrollo Scrum y la especificación de los requisitos
utilizando la norma IEEE 830. Seguidamente se identificó los problemas de
accesibilidad a la información remotamente, la solución a dicho problema radicó en el
desarrollo de un sistema de interacción para proveer información de forma remota
utilizando la telefonía como medio de comunicación y acceso a la misma.
Una vez procesado los resultados que se obtuvieron por medio de formularios de
evaluación a fin de observar el comportamiento de la aplicación en determinados casos
de estudio, se verificó el correcto funcionamiento del sistema, siempre y cuando este
sea utilizado fuera de las zonas de riesgo identificados en el proceso de realización de
pruebas, verificación y validación de resultados.
2
Red Telefónica Conmutada, estas son redes de telecomunicación basados en la conmutación de
circuitos
2
1.2 Antecedentes
1.2.1 Antecedentes de la institución

La empresa de telecomunicaciones Inova Networks, se dedica principalmente a la
comercialización de equipos de telecomunicación de larga y corta distancia, además
presta servicios técnicos referentes al área de telecomunicaciones y brinda soluciones
completas tales como el cableado estructurado, instalación de servidores de distinta
índole, entre otros, para los cuales esta empresa dispone de los materiales que tiene en
almacén para concretar los proyectos y negocios que dicha empresa tiene. Para tales
tareas, ventas y prestación de servicios esencialmente, los ejecutivos de marketing se
encuentran en constante movimiento realizando proformas a soluciones requeridas por
distintos clientes, obligándolos a darse modos para acceder a información respecto a los
materiales existentes en almacén.
Las áreas en las que se desenvuelve esta empresa de telecomunicaciones, abarca desde
las capitales de departamentos hasta poblados ubicados en las fronteras del territorio
boliviano. Su oficina principal está ubicado en la avenida ComercioN°210, edificio
Ismar, piso 5, en la ciudad de La Paz.
Misión: Inova Networks es una institución comprometida con el desarrollo tecnológico

local, regional y nacional respecto a las comunicaciones globalizadas, haciendo de este
país un territorio interconectado.
Visión: Ser una institución modelo tecnológicamente, haciendo constante y sostenible la

mejora de las comunicaciones, brindando servicio y productos de calidad.
Actualmente esta entidad cuenta con una PBX-IP virtual basado en el software de
Asterisk, el cual es utilizado primordialmente como contestadora automática dando el
saludo de bienvenida y agradecimientos por la llamada, verificando también el horario
en que se realiza dicha llamada para efectuar ciertas acciones, programando de esta
forma la atención a clientes por horarios de oficina, en caso de no estar disponibles se
graba un mensaje y es enviada al buzón de voz de esta entidad.
3
También cuentan con un sistema web de control de almacenes alojado en un servidor de
aplicaciones propio, dicho sistema utiliza el gestor de base de datos MySQL y PHP
como gestor de lógica de negocios.
El sistema emite reportes sobre los movimientos de los productos en almacén, así como
reportes globales sobre la cantidad física existente de cada ítem, además de varias otras
funciones relacionadas con el control efectivo del almacén e inventarios.
La forma en la que se accede a dichos reportes e información requerida del sistema es

por medio del protocolo de comunicaciones HTTP, utilizando algún navegador como ser
Firefox, Google Chrom, internet Explorer u otros compatibles con las especificaciones y
principios de la 3WC. Las conexiones permitidas al servidor son por medio de la
dirección www.inova.com.bo. Dichos accesos son actualmente realizados desde
computadoras estacionarias, vale decir que para obtener información sobre los productos
en almacén, necesariamente se tendrá que contar mínimamente con una conexión a
internet y un computador de escritorio.
1.2.2 Antecedentes del tema

En la actualidad existen grandes avances respecto a la automatización de tareas,
surgiendo sistemas de toda índole entendidos como soluciones completas para distintos
problemas. En el área de las telecomunicaciones, las tecnologías de integración entre
sistemas telefónicos y sistemas informáticos, se han ido incrementando al punto que en
el mercado tecnológico la comercialización de soluciones IVR alcanzó los 2.78 mil
millones de dólares por concepto de ventas en la gestión 2011 solo en EE.UU. (AGI,
2012) evidenciado de esta manera que los sistemas de respuesta automática vocal
interactivos son la aplicación más popular de la tecnología CTI dada su cercanía al
público en general.
Estos sistemas, los IVR, permiten esencialmente automatizar la interacción entre una
llamada entrante y un sistema informático que realice la recepción de dicha llamada e
interactúe con la misma, además ofrece varias ventajas vanguardistas que parten
4
inicialmente como contestador automático de llamadas hasta funciones completamente
complejas de integración con sistemas externos. (Lopez, 2008, págs. 133,134)
Los sistemas IVR se utilizaron inicialmente en el ámbito bancario en la década de los

setenta con el fin de optimizar y mejorar los tiempos de atención a los clientes, estas
soluciones eran de código cerrado y de costo alto. Con el avance de las tecnologías
dichas soluciones proliferaron en distintas áreas como las gubernamentales, educación y
centros de salud. Actualmente gracias al crecimiento vertiginoso de herramientas y
sistemas informáticos de código abierto se cuenta con soluciones IVR con licencia GPL
GNU basados en distintas plataformas PBX virtuales tal como Asterisk.
“Asterisk es una plataforma telefónica de código abierto (GPL) que pretende

revolucionar el mundo de las comunicaciones IP frente a las tradicionales soluciones de
grandes corporaciones como Cisco, Nortel, Ericsson, Siemens, etc., caracterizadas por
su falta de transparencia hacia el usuario, sus protocolos propietarios y cerrados, así
como su elevado coste.” (Lopez, 2008, pág. 8)
El software libre para soluciones de respuesta interactiva por voz, como el API de
Asterisk, el cual es una aplicación para controlar y gestionar comunicaciones de
cualquier tipo, ya sean analógicas, digitales, móviles o VoIP, es implementada en una
gran variedad de empresas e incluso pymes, con las funcionalidades de: operador
automático, interacción con base de datos, interacción con sistemas externos, voz mail,
entre otros.
A continuación se listarán algunas empresas en el territorio boliviano que utilizan el IVR

como solución para gestionar de forma automática las llamadas que ingresan a la
entidad.
Unidad de proyectos especiales dependiente del ministerio de la presidencia, utiliza la

solución IVR como enrutador de llamadas enumerando las extensiones para posibilitar la
comunicación con sus distintas áreas administrativas.
5
El Call Center de COTEL es un centro de llamadas en el que se reciben todo tipo de
consultas vía teléfono, los servicios ofrecidos son: 104 información de números
telefónicos, 113 reclamos técnicos, 2315353 atención al cliente, 2372323 central
telefónica de COTEL y marcando al 102 información de deuda telefónica.
El servicio de información ciudadana en el ayuntamiento de Murcia – España le permite

al usuario realizar trámites por teléfono con servicio gratuito. Llamando al 900222900 se
puede realizar los siguientes trámites: alta en el padrón de habitantes, cambio de
domicilio, certificados de pago de impuestos, domicilio bancario de impuestos, volante
de empadronamiento.
El uso del sistema IVR embebido en Asterisk, ha sido aceptado primordialmente por el
bajo costo que conlleva para ser implementado, es por esta razón que instituciones como
las anteriormente citadas optan por el uso de esta solución, también se tienen
identificadas a empresas internacionales como Google, Yahoo, IBM, e incluso el
Ejército de EE.UU (Quarea, 2010) que utilizan dicha solución como sistema de
implementación libre de una central telefónica.
A continuación se cita proyectos de grado y tesis consultada en distintas bibliotecas

virtuales de informática y otras fuentes, los cuales tratan temas relacionados con este
proyecto pero se enfocan a áreas específicas en cuanto a la utilización del sistema IVR.
Título: Diseño e implementación de un sistema interactivo de respuesta de voz

(IVR) piloto para la reserva de boletos del ferrocarril Cuzco – Machu Pichu
Autor: David Alfonso Ortega Gallegos
Año: 2007
Institución: Facultad de Ciencias e Ingeniería, Pontificia Universidad Católica del
Perú
Descripción: El proyecto de tesis consiste en el estudio, diseño e implementación de un
sistema IVR IP de interfaz telefónica bilingüe (español- inglés) para la reserva de
6
boletos del ferrocarril de Cuzco para el viaje desde la estación de San Pedro hasta la
ciudadela Machu – Picchu (Aguas Calientes).
Título: Análisis, diseño y desarrollo de un sistema IVR para el módulo de ventas:

estado de petición de una nueva solicitud de servicio para la corporación nacional de
telecomunicaciones E.P.
Autor: Andres Paul Toscano Vaca
Año: 2012
Institución: Carrera de ingeniería de sistemas, escuela politécnica del ejercito Ecuador
Descripción: Diseño de un IVR utilizando metodología SCRUM e IDE de desarrollo
para IVR de Avaya Inc., operando en la plataforma de desarrollo eclipse. Con el objetivo
principal de brindar un servicio de atención y entrega de información inmediata, para
conocer el estado de instalación de nuevos servicios de telefonía e internet que hayan
contratado los clientes de la CNT E.P.
Título: Sistema Telefónico Automático para Consultas de Deudas y Fechas de

Pago
Autores: Andrea Solange Freire Morán, Eduardo Arturo López Yaguana, Gabriel
Astudillo Brocel
Año: 2012
Institución: Escuela Superior Politécnica del Litoral, Centro de Investigación
Científica y Tecnológica
Descripción: El proyecto expuesto en esta tesis es una de las muchas soluciones para
darles a los usuarios de una institución comercial o educativa información de sus
movimientos en este caso de sus deudas de una forma ágil, rápida y sencilla con una
llamada telefónica y usando un campo clave para identificarse en este caso el número de
cédula. Cuando un usuario realice una llamada a la central telefónica este escuchará un
menú y tendrá que ingresar su identificador; de acuerdo a lo que el presione se pueden
dar varios casos, los cuales se explican en la descripción del proyecto.
7
1.3 Planteamiento del problema
Según la comparativa de precios y velocidad de transmisión de datos de internet
realizada en el anexo A, se evidencia que la conexión a internet en Bolivia se sitúa entre
los más caros y lentos de la región latinoamericana, razón por la que los requisitos
mínimos y los montos económicos para acceder a una conexión a internet se convierten
en barreras tecnológicas y económicas que limitan el acceso a la información. Además
se ha evidenciado que la conectividad a internet no está disponible en varias regiones del
territorio boliviano (ver Anexo B). Debido a estas situaciones la empresa Inova
Networks se ve imposibilitada de contar con una tecnología de conexión a internet móvil
con una velocidad de transferencia de datos aceptable a corto plazo, a fin de lograr
obtener la información necesaria del sistema web de almacenes en tiempo real y de
forma remota, la cual es imprescindible para lograr concretar negocios o ventas serias en
el menor tiempo posible, así como también el poder realizar planificaciones correctas
para el emprendimiento de proyectos referentes a los servicios prestados por la empresa
o para una correcta adquisición de nueva mercancía.
También se evidencia el problema de la no disponibilidad del personal en modo

continuo, es decir veinticuatro horas al día siete días a la semana y que esté dedicado al
manejo del sistema de almacén, para principalmente, obtener la información emitida por
dicho sistema y remitirla al personal de marketing o al personal de nivel administrativo
para la toma oportuna de decisiones, repercutiendo en una inoportuna toma de
decisiones, afectando directamente a los intereses de la empresa.
Esta necesidad de obtención de la información del sistema web de almacenes en forma

remota, nace a raíz de la agilidad que tiene la empresa en cuanto a la distribución de sus
productos y servicios, siendo que el centro de comercialización radica en el lugar en que
se encuentren sus potenciales clientes.
8
1.3.1 Formulación del problema
¿Cómo posibilitar una conectividad móvil continua con un sistema web de control y
gestión de almacenes para obtener información específica del mismo de forma remota
prescindiendo del internet como medio de interconexión?
1.4 Objetivos
1.4.1 Objetivo general

Lograr la conectividad entre el sistema web de control y gestión de almacenes y la
telefonía como medio de interacción por medio del diseño e implementación un sistema
IVR bajo Asterisk.
1.4.2 Objetivos específicos

A continuación se describirán las actividades necesarias para lograr el cumplimiento
total del objetivo general planteado.
 Analizar las tecnologías que posibiliten la conectividad entre un sistema IVR y un

gestor de base de datos, en este caso en particular a un DBMS MySQL.
 Verificar la disponibilidad de los módulos necesarios en el servidor de
telecomunicaciones para la implementación del IVR propuesto
 Analizar y diseñar un dialplan3 que encamine a una correcta consulta respecto a la
información emitida por el sistema web de almacenes.
 Implementar el sistema IVR diseñado en la central telefónica Asterisk
 Analizar, diseñar e implementar un subsistema dentro del sistema IVR, que permita
realizar llamadas automáticas a fin de alertar oportunamente el desabastecimiento
de productos en almacén.
 Analizar, diseñar e implementar un subsistema dentro del sistema IVR, que permita
realizar consultas sobre la información de los productos en almacén.
3
Dialplan o plan de marcados, se refiere a la asignación de una determinada extensión a un determinado
usuario o a una secuencia de pasos a realizarse en base a la marcación que realice la llamada entrante al
PBX. En Asterisk el dialplan es configurable en el archivo extensions.conf
9
 Realizar pruebas de conectividad entre cualquier dispositivo telefónico conectado a
una red de telecomunicaciones dentro de la RTC o a una red de telefonía móvil, con
el sistema web de almacenes.
1.5 Justificación
1.5.1 Justificación económica

El presente trabajo está orientado bajo el desarrollo y utilización de tecnologías con
licencias de dominio público GPL, la utilización de dichas tecnologías disminuye los
costos en cuanto a la adquisición de licencias para un correcto funcionamiento de la
solución propuesta.
La conectividad al sistema web de control de almacenes por medio de las redes

telefónicas, presente en nuestro medio, aminora considerablemente los gastos frente a
una conectividad móvil por medio de internet.
Así también se considera que al proveer a la entidad Inova Networks una herramienta
tecnológicamente avanzada, para un correcto y oportuno control de la información que
emite el sistema web de almacenes en forma remota y continua, se posibilita una mejor y
rápida toma de decisiones que afectara positivamente a la economía de la empresa.
1.5.2 Justificación tecnológica

La utilización de las redes telefónicas conmutadas y móviles (independientemente de los
dispositivos que se utilicen, siempre y cuando éstas estén dentro de la cobertura de
comunicación para recibir y realizar llamadas), como alternativa a la conexión a internet,
para acceder a información específica emitida por un sistema web informático e
interactuar con ella, es conocida como tecnología CTI, dicha tecnología permite la
integración de distintos protocolos de señalización, protocolos de empaquetamiento de
datos, especificaciones sobre redes móviles de comunicación y
codificadores/decodificadores también conocidos como codec. Por lo cual el presente
trabajo propuesto abarca un variado abanico de temáticas concernientes a la informática
y las telecomunicaciones.
10
Al disponer la empresa Inova Networks de tecnologías de telecomunicación, como ser:
la central telefónica Asterisk, acceso a líneas troncales de la RTC, el software y
hardware necesarios, se hace factible la implementación de soluciones vanguardistas.
1.6 Metodologías y herramientas

Para el diseño e implementación del sistema IVR propuesto se utilizarán las siguientes
metodologías y herramientas, tanto para la etapa de recolección de datos, análisis y
revisión de documentación, los mismos que servirán para la detección de problemas,
cada uno de estos serán descritos a continuación.
1.6.1 Recolección de datos e información

El tipo de investigación llevado a cabo para la recopilación de información y requisitos
necesarios para la elaboración y diseño del sistema IVR propuesto, se fundamentó en la
exploración, ya que se efectúa sobre un tema u objeto desconocido o poco estudiado en
nuestro medio, por lo que sus resultados constituyen en una visión aproximada de dicho
objeto. Luego se realiza una investigación descriptiva ya que se conocen las situaciones
y actitudes predominantes a través de la descripción exacta de las actividades objetos y
personas.
1.6.2 Metodología
Para el logro de los objetivos propuestos en el presente trabajo se realizó la recopilación
de información por medio de historias de usuario de la metodología de desarrollo Scrum
y se especificaron los requerimientos utilizando la norma IEEE 830, seguidamente se
adecuó el servidor de telecomunicaciones Asterisk a fin de lograr una correcta
integración con el producto desarrollado. El diseño del sistema IVR con los subsistemas:
consultas a almacén y alertas ante desabastecimiento, está basado en las historias de
usuario recopiladas y enmarcadas en la especificación realizada con la norma IEEE 830,
para dicho desarrollo fue necesario la creación de tres archivos en lenguaje PHP, que
cumplen la función de recepción de la llamada entrante y el procesamiento de la misma
para su correcto enrutamiento respecto a la obtención de información necesaria para el
usuario. Se realizó la instalación de una librería PHP con el propósito de posibilitar la
11
conexión remota al DBMS MySQL y así permitir realizar consultas a la base de datos
remota, seguidamente se realizó la instalación un servidor de sintetización de voz (TTS,
Text To Speach) el cual fue configurado de tal manera que pueda ser utilizado por los
módulos de aplicaciones y funciones de Asterisk, el objetivo principal del TTS instalado
es el de comunicar audiblemente la información obtenida desde la base de datos a
consultar. Finalmente se configuró el enlace de comunicaciones entre el lenguaje PHP y
Asterisk por medio de comandos AGI4.
Una vez concluido el diseño y desarrollo del sistema IVR para consultas a almacén y
alertas ante desabastecimientos se realizaron pruebas en base a un estudio de casos, la
información recopilada para dichas pruebas fueron registradas utilizando como
herramientas, formularios de evaluación para el subsistema de consultas a almacén y
subsistema de alertas ante desabastecimientos.
1.7 Alcance, límites y aportes
1.7.1 Alcances
La tesis contempla el logro de la obtención de información en tiempo real y de forma
remota desde una base de datos a través de las redes de telefonía, por medio de un
sistema interactivo de respuesta de voz, en el caso concreto, instalado en la central
telefónica Asterisk perteneciente a la empresa Inova Networks, permitiendo la
realización de consultas a la base de datos de dicho sistema desde un dispositivo
telefónico móvil o fijo no conectado a internet.
Para tal fin y acorde a los requerimientos de la empresa Inova Networks, el sistema IVR
estará compuesto por dos subsistemas, esto son:
 Subsistema de consultas a almacén, proporcionará información específica de un

producto registrado en el sistema web de control y gestión de almacenes.
4
AGI (Asterisk Gateway Interface), es una interfaz de software y el protocolo de comunicaciones para
Asterisk.
12
 Subsistema de alertas automáticas ante desabastecimiento de productos, permitirá
conocer que productos se encuentran con un stock mínimo, para ello se dispone de
dos modos de acceso a dicha información, la primera, realizando una llamada al
número de interno asignado al subsistema, el segundo, mediante llamadas
automáticas a la línea telefónica del usuario autorizado.
El acceso a la información de los productos registrados en el sistema web de almacenes

por medio del sistema IVR, será restringido por medio de inicios de sesión de usuario,
solicitando el ingreso de una contraseña de validación al usuario, sin el cual no podrá
acceder al menú de opciones para la entrega de información de los productos en
almacén.
1.7.2 Límites
 El sistema IVR propuesto deberá ser accedido desde las redes de telefonía móvil,
fija, o redes de telefonía IP.
 Los dispositivos telefónicos móviles o fijos que son funcionales o compatibles con
la solución propuesta en el presente trabajo, deberán estar conectados a alguna red
perteneciente a la RTC o red de telefonía móvil y estar dentro del área de cobertura
para esa red de telecomunicaciones.
 El sistema IVR dependerá totalmente de la disponibilidad y funcionamiento continuo
de los servidores, servicios y aplicaciones que influyen en el correcto desempeño del
sistema IVR, sin ser esto responsabilidad del desarrollador del sistema IVR después
de realizadas las pruebas respectivas.
 Las marcaciones numéricas en el teclado del dispositivo telefónico serán el único
método de ingreso de datos u órdenes para la navegabilidad en el menú de opciones
del IVR.
 El castellano es el único idioma con el cual se expondrá el árbol de opciones y la
información de productos emitidos por los subsistemas de consultas y alertas.
13
 Los formatos de entrega de la información por parte del sistema IVR serán:
información audible para la consulta de datos de un determinado producto, e informe
escrito para el caso de los productos desabastecidos.
 La gestión de los usuarios autorizados para el acceso a la información registrada en
la base de datos, será gestionada por la empresa Inova Netwoks e independiente del
sistema IVR.
 La empresa Inova Networks cuenta solamente con un canal de comunicación, es
decir que tiene una única línea troncal instalada en su central de telecomunicaciones
Asterisk, por lo que las llamadas concurrentes al sistema IVR no serán posibles.
 El stock mínimo de productos está definido por el reglamento interno de la empresa
Inova Networks, el cual puede ser visto en el anexo E.
 Según los estudios de George Miller (Miller, 1956) y complementados por los
estudios de Gordon Parker (Parker, 2011), ha determinado que el número de ítems
máximos creados en los arboles de opciones en el IVR no sobre pasen la cantidad de
5 opciones por grupo de menú. Por lo que el menú principal del subsistema de
consultas a almacén tendrá cuatro opciones, el menú secundario dedicado a la
gestión de las consultas tendrá cuatro opciones y el menú principal del subsistema de
alertas tendrá tres opciones para la adquisición de información de productos
desabastecidos.
1.7.3 Aportes
La culminación del presente trabajo es pasible a ser utilizado como una guía para la
implementación de tecnologías CTI y sistemas IVR en diversos ámbitos, así también
sirve como base fundamental para posteriores investigaciones y trabajos en el área de las
telecomunicaciones.
Es también un aporte tecnológico a la sociedad debido a la implementación de una

solución de bajo coste, que ofrece una herramienta tecnológicamente avanzada.
14
2 MARCO TEÓRICO
2.1 Introducción
En el presente capítulo se expondrá los conceptos y teorías que permitirán entender de
forma clara el ámbito y el área de investigación, los cuales también se podrá enmarcar
las herramientas y tecnologías que serán utilizadas en el desarrollo del presente proyecto
de grado.
2.2 La telefonía tradicional

La telefonía tradicional está compuesta por al menos dos grandes sistemas de la
telecomunicación, entre estas están los sistemas analógicos y los sistemas digitales. A
continuación se muestra en la figura 2.1 la arquitectura general de la telefonía
tradicional.
A continuación se desarrollará la descripción conceptual de los componentes y las

tecnologías más relevantes para el presente proyecto mostradas en el anterior gráfico.
FIBRA OPTICA / SDH

LINEA DE COBRE
PSTN / RTB CENTRO TELEFONICO CENTRO TELEFONICO

HOGAR
CENTRO DE CONMUTACION
GSM / UMTS / 4G BRI
E1 / T1 / PRI
EMPRESA
Figura 2.1: Arquitectura general de la telefonía tradicional

Fuente: Elaboración propia
15
2.2.1 Sistemas analógicos
Los sistemas analógicos tuvieron sus inicios a mediados del siglo IXX, están
conformados básicamente por la red telefónica básica (RTB) que en definitiva son
circuitos analógicos comúnmente formados por pares de cobre que llegan a los abonados
del servicio telefónico y por el cual se transmite la señal eléctrica de la voz de manera
analógica.
2.2.2 Sistemas digitales
2.2.2.1 Red Digital de Servicios Integrados

Los trabajos de desarrollo de la Red Digital de Servicios Integrados (RDSI o ISDN,
Integrated Services Digital Network) comenzaron en la década de los 80.
La RDSI permite que en una línea coexistan múltiples canales, pudiendo contener cada
uno de ellos, datos (canales B) o señalización (canales D) y cada canal con un ancho de
banda de 64Kpbs. La RDSI básica o también conocida como línea BRI (Basic Rate
Interface) pose tres canales (dos canales B y un canal D), de forma que pueden realizarse
dos llamadas telefónicas de forma simultánea en una única BRI.
2.2.2.2 E1/T1
Un T1 es un acceso digital que dispone de 24 canales, pudiéndose realizar en veintitrés
canales una llamada individual, esta tecnología es común en Estados Unidos y Japón, en
Europa se emplea con mayor frecuencia el E1. A diferencia del T1, el E1 dispone de 32
canales.
La tecnología T1 y E1 utilizan el método de señalización por robo de bit, que consiste

en: que cada cierto tiempo se usa un bit de cada canal para así señalizar y enviar
información a través de la línea o mediante multiplexación del bit en un canal común
2.2.3 Redes móviles
2.2.3.1 GSM
GSM (Global System lor Mobile communications, proveniente en un principio de
Groupe Special Mobile) es el estándar más popular y extendido para teléfonos móviles
16
mundialmente. En 1991 la primera red GSM fue lanzada comercialmente,
concretamente en Finlandia. Su promotor, la Asociación GSM, estima que el 82% del
mercado global de teléfonos móviles emplea este estándar (Lopez, 2008, pág. 25).
GSM, a diferencia de la RTB, digitaliza tanto los datos de voz y los datos de
señalización., por lo cual se considera a GSM como un sistema de telefonía móvil de
segunda generación (2G) y gracias a esta ventaja, este estándar posibilita con mucha más
facilidad el poder establecer comunicaciones de datos.
GSM a fin de lograr una comunicación entre sus usuarios emplea varios codecs5 de
audio para comprimir el sonido transmitido a través de los terminales móviles. Al
principio, fueron empleados dos codecs, Half Rafe y Full Rate, que se llamaban así
debido a la relación que éstos guardaban con la forma en la que usaban el canal de
transferencia, de forma parcial o de forma completa, respectivamente. A partir de 1997
comenzó a emplearse el codec Enhanced Full Rate (EFR), que mejoró el estándar y
usaba el canal de transferencia completamente, en el mismo año el estándar añadió
capacidad para transportar paquetes de datos a través del servicio General Packet Radio
Service (GPRS), incluyendo entre otras cosas mensajes multimedia (Multimedia
Messaging Servíce o MMS) o aplicaciones de Internet a través del Wireless Application
Protocol (WAP). GPRS es comúnmente conocido como 2.5G, debido a que es una
especificación que se encuentra entre la segunda y la tercera generación de telefonía
móvil.
2.2.3.2 UMTS
UMTS (Universal Mobile Telecommunications System) es una tecnología de tercera
generación (3G) para telefonía móvil. Está estandarizado por 3GPP (3rd Generation
Partnership Program), una colaboración entre grupos de telecomunicaciones de varios
lugares del mundo para desarrollar una especificación de un sistema de telefonía
aplicable globalmente y que cumpla las exigencias de ITU IMT-2000. Ese sistema está
5
Codec, abreviatura de codificación y decodificación. Su uso se refiere a la capacidad de codificar y
decodificar una señal de audio en un sistema.
17
basado en una evolución de las especificaciones de OSM. 3GPP fue creado a finales de
1998, pero no sería hasta principios de 2000 cuando surgiría la especificación de la
primera red UMTS de uso comercial.
UMTS proporciona una gran mejora en la transferencia de datos con respecto a sus
predecesores, pudiendo alcanzar de forma teórica hasta 14 Mbps. En la práctica se han
llegado a alcanzar tasas de transferencia de bajada de 7.2 Mbps, una velocidad muy
superior a los 9.6 Kbps que ofrecían los primeros canales de datos empleados en GSM.
2.2.3.3 4G
Esta tecnología es la sucesora de las tecnologías de telecomunicación 2G y 3G
anteriormente expuestos, está basada en completamente en el protocolo IP gracias a la
convergencia de las tecnologías existentes.
4G provee una mayor velocidad de acceso a internet, siendo este factor la principal
diferencia con las anteriores tecnologías, esta velocidad de acceso es mayor a los 100
Mbps en movimiento, vale decir que el dispositivo conectado con esta tecnología se
encuentra desplazándose físicamente y en reposo llega en teoría a los 1 Gbps.
El WWRF (Wireless World Research Forum, foro mundial de investigación wireless)

propone que esta tecnología englobe a varias otras incluyendo protocolos, similar a
como ocurrió con la tecnología 3G, el cual incluye a las redes GSM, CDMA.
2.2.4 Centralitas tradicionales PBX

Una centralita telefónica privada o PBX (Private Branch Exchange) es un dispositivo de
telefonía que actúa como conmutador de llamadas en una red telefónica o de
conmutación de circuitos.
En los años 60 las centrales telefónicas, mayoritariamente analógicas, fueron

transformando su tecnología a digital, la intención inicial fue digitalizar el bucle local
pero por motivos meramente económicos el bucle local continuó siendo analógico.
Finalmente, la medida que se adoptó fue la de digitalizar la comunicación entre las
18
centralitas telefónicas, manteniendo el bucle local analógico, esta medida dio lugar a lo
que se conoce como RDI (Red Digital Integrada).
La centralita permite a los usuarios o abonados compartir un determinado número de

líneas externas, analógicas o digitales, para hacer llamadas telefónicas entrantes o
salientes, así como establecer comunicaciones internas entre todos los dispositivos que
dependen de la PBX. Entre las muchas ventajas que ofrece, una PBX es una solución
mucho menos costosa que proporcionar a cada usuario de la empresa una línea
telefónica externa.
2.3 VoIP
Esta tecnología tuvo sus inicios en los años noventa, comenzando en esta gestión las
investigaciones y experimentaciones sobre el transporte de voz y video sobre redes IP.
En 1999 VoIP inicio su uso comercial, registrándose en el año 2000 un crecimiento del
tráfico de voz por red IP alcanzando el tres por ciento del tráfico total de voz en Estados
Unidos.
Gracias a la mejora de las redes de datos en cuanto a la velocidad de conexión y

transferencia de datos se prolifero esta tecnología, brindando una mejor calidad de voz y
una comunicación fiable a través de las redes IP, además que surgieron una gran
cantidad de soluciones tanto privativas como libres, entre ellos se encuentran Avaya,
Cisco, Telesynergy , Asterix, FreeSWITCH y otros.
2.3.1 Arquitectura general del sistema de telecomunicaciones

Genéricamente VoIP se compone de al menos cuatro elementos estos son el dispositivo
de origen de la llamada, la red mundial de comunicaciones Internet, el protocolo de
comunicaciones (SIP, IAX, etc.) y el dispositivo o terminal de destino de la llamada,
todos estos componentes pueden ser vistos a continuación en la figura 2.2, en el que se
puede apreciar la arquitectura genérica de la tecnología VoIP.
19
Figura 2.2: Arquitectura general de VoIP
Fuente: (Simionovich, AsteriskNow, 2008, pág. 24), (Lopez, 2008, pág. 39)
2.3.2 Protocolo de señalización en VoIP

La realización de una llamada entre dos teléfonos cualesquiera implica la utilización de
diversos equipos electrónicos, los cuales deben comunicarse entre sí, para poder
garantizar que la comunicación entre los equipos se realice adecuadamente, son
necesarias diversas reglas y/o normas. Estas reglas y/o normas de las que se habla es lo
que se conoce como protocolo de señalización.
En las redes analógicas o redes de conmutación de circuitos antes de que ambos

extremos puedan comunicarse, se produce la reserva de recursos necesarios para que la
comunicación tenga éxito. Si por cualquier circunstancia no puede llevarse a cabo esta
reserva de camino entre ambos extremos se informa al emisor de este hecho. A la acción
de reservar un camino de recursos entre ambos extremos es lo que se le conoce como
señalización.
En la telefonía tradicional los protocolos de señalización se pueden clasificar en dos

categorías:
 Channel Associated Singnalling (CAS). Tanto la información de señalización como
los datos (voz) se transmiten por los mismos canales. Protocolos de señalización
pertenecientes a esta categoría: G.732, E&M, etc.
20
 Common Channel Signalling (CCS) Aquí la información correspondiente a la
señalización se transmite en un canal independiente al de los datos (voz). Protocolos
de señalización pertenecientes a esta categoría es, por ejemplo, SS76.
En conmutación de paquetes los protocolos de señalización realizan acciones muy

similares a los protocolos de señalización en conmutación de circuitos, además de cuidar
de que se cumplan ciertas garantías de calidad. Los protocolos de señalización más
utilizados en conmutación de paquetes son: SIP, IAX 2 y H323.
2.3.2.1 Session Initiation Protocol (SIP)

El protocolo SIP es un protocolo de señalización a nivel de aplicación encargado de la
iniciación, modificación y terminación de sesiones multimedia, las cuales se llevan a
cabo de manera interactiva. Por sesiones multimedia se refiere a aplicaciones de
mensajería instantánea, aplicaciones de video, de audio, conferencias y aplicaciones
similares.
Este protocolo de modo similar al protocolo SS7, transporta los datos y las
señalizaciones por canales distintos, enviando las transacciones y peticiones de registro
y autentificación al proxy SIP por un canal y enviando los datos por medio del Real
Time Protocol. (Ver figura 2.3)
Figura 2.3: Proceso de registro entre clientes y el servidor proxy. La señalización (SIP) y
las conversaciones de voz (RTP) viajan por caminos diferentes.
Fuente: (Pascual, 2006, pág. 9)
6
SS7 es un grupo de estándares desarrollados originalmente por la AT&T y la Unión Internacional de las
Telecomunicaciones (UIT), que se encarga de la gestión del establecimiento de llamadas y su
encaminamiento entre centrales telefónicas en la RTB.
21
2.3.2.2 H323
El protocolo H.323 fue diseñado por ITU en 1996. Fue diseñado para ser un estándar en
la transmisión de audio, video y datos a través de las redes IP, este protocolo es rápido,
en comparación al protocolo SIP, la cual utiliza paquetes de gran tamaño. Esto es debido
a que el formato de los mensajes en H.323 es binario, mientras que en los mensajes SIP
el formato es texto plano. El diseño de H.323 está muy arraigado a la filosofía seguida
en el diseño de la PSTN: simplicidad y alta disponibilidad.
2.3.2.3 Inter-Asterisk eXchange (IAX)

Es un protocolo de telefonía IP que utiliza un reducido número de bits en las cabeceras y
que está diseñado para permitir la comunicación entre centralitas y clientes Asterisk, la
principal diferencia entre SIP o H.323 es que IAX no utiliza RTP, sino que en su lugar
implementa su propio mecanismo de transmisión de voz, además todas las
comunicaciones (registro, señalización de llamada, transmisión de voz) hacen uso de un
único puerto UDP. Por lo tanto el NAT7 no supone un problema en IAX a diferencia de
SIP, ya que tanto los datos de señalización como el audio viajan por el mismo puerto.
2.4 Asterisk
Asterisk es una implementación de software libre de una centralita telefónica. El
programa permite tanto que los teléfonos analógicos o digitales conectados a la
centralita puedan hacer llamadas entre ellos como servir de pasarela a la red telefónica
tradicional. Al ser una PBX virtual, es decir un software en su totalidad, los
requerimientos de hardware para poderlo implementar son mínimos, ver tabla 2.1.
Tabla 2.1: Requerimientos mínimos según los propósitos
Fuente: (Meggelen, 2007, pág. 12)
Propósito Número de canales Mínimo recomendado
Hobby system No más de 5 400 Mhz x86, 256 MB RAM
SOHO system 5 a 10 1 GHz x86, 512 MB RAM
Small business system Arriba de 25 3 GHz x86, 1GB RAM
Medium to large system Mucho más 30 En lo posible servidores
distribuidos con doble
procesador
7
Traductor de Direcciones de Red, Network Address Translator, es la técnica que se utiliza para permitir
que varios ordenadores compartan una misma IP pública a través de IP’s privadas.
22
2.4.1 Arquitectura
Asterisk fue desarrollado de manera modular con el objetivo de hacer de este software
escalable y extensible, permitiendo al usuario final seleccionar los módulos que este
requiera. El esquema general de la arquitectura modular de Asterisk es conformado por
siete categorías principales (ver figura 2.4)
A continuación se describirán de manera general las categorías mostradas en la anterior

figura.
 Core. Se trata del núcleo de Asterisk, que incluye las funciones más básicas y
posibilita la carga de módulos.
 Recursos. Aportan funcionalidades adicionales al core, como la posibilidad de leer
ficheros de configuración (res_config), música en espera (res_musiconhold), etc.
 Canales. Permiten a Asterisk manejar un dispositivo de una determinada tecnología.
Por ejemplo, para manejar dispositivos SIP se utiliza el módulo chan_sip, para IAX2
chan_iax y para canales analógicos/digitales chan_zap.
 Aplicaciones y funciones. Estos módulos conforman la "caja de herramientas" de
Asterisk, ya que son los módulos que aportan las distintas herramientas para
configurar nuestro sistema Asterisk.
 CDR. Estos módulos controlan la escritura del registro telefónico generado por
Asterisk a diferentes formatos, por ejemplo a un fichero CSV, una base de batos
MySQL, etc.
 Codecs. Para que Asterisk pueda codificar y decodificar la información de
audio/vídeo que tiene que enviar y recibir dispone de distintos codecs (Simionovich,
AsteriskNow, 2008, pág. 18).
 Formatos. Estos módulos posibilitan a Asterisk "entender" y manejar ficheros en
distintos formatos.
23
Figura 2.4: Arquitectura de Asterisk
Fuente: (Lopez, 2008, pág. 63)
2.4.2 Interfaces de programación de aplicaciones

En Asterisk existen dos interfaces que posibilitan la programación de aplicaciones y la
integración con bases de datos, estos son: AMI (Asterisk Manager Interface) y AGI
(Asterisk Gateway Interface). Gracias al uso de alguna de estas interfaces se posibilita
el desarrollo de tecnologías CTI y sistemas de comunicaciones unificadas.
2.4.2.1 Asterisk Manager Interface, AMI

Asterisk Manager Interface o Interfaz para la Gestión de Asterisk (AMI) es un protocolo
interno de Asterisk que nos permite controlar, administrar, conocer e interactuar en
tiempo real con todo lo que sucede en forma interna en Asterisk desde sistemas externos.
AMI es utilizado para la realización de distintas tareas, entre las cuales se puede
mencionar: transferencia de llamada, verificación en tiempo real del consumo en tiempo
de la llamada, Caller ID popup.
AMI tiene un modelo del tipo cliente servidor basado en TCP, que generalmente por
medio del puerto 5038 se posibilita la interacción entre la central telefónica y una
determinada aplicación o sistema externo, a este puerto se puede acceder por medio de
24
Telnet o mediante una aplicación con sockets y es configurable modificando los valores
predeterminados escritos en el archivo manager.conf.
También existe la posibilidad de habilitar la funcionalidad de conectar con interfaces

basadas en la web y aplicaciones como navegadores, utilizando el protocolo HTTP,
gracias a una tecnología diseñada específicamente para Asterisk basada en Java y AJAX,
llamada AJAM (Asynchronous Javascript Asterisk Manager), parecida a AJAX con
respecto a la equivalencia con uso de mensajes XML, y para ello se utiliza por defecto el
puerto 8088.
AMI recibe comandos llamados acciones, estos generan respuestas que contienen
información respecto al comportamiento que tuvo Asterisk en base a las acciones.
2.4.2.2 Asterisk Gateway Interface, AGI

Asterisk Gateway Interface o Interfaz Pasarela de Asterisk (AGI), provee una interfaz
estándar con la cual los programas externos son controlados por el dialplan de Asterisk
haciendo uso de scripts con una lógica de negocios avanzada, conectando, por ejemplo,
base de datos relacionales y acceso a otros recursos externos (ver figura 2.5).
Figura 2.5: Lógica de funcionamiento de AGI

Fuente: www.asterisk.org.il/downloads/OSDC_PHPAGI.pdf, 10 julio 2013
25
A diferencia de AMI, AGI ejecuta las aplicaciones en forma directa tan pronto sea
invocada dicha aplicación o función desde el dialplan. El comportamiento avanzado del
dialplan es derivado a un programa externo, permitiendo a Asterisk fácilmente contar
con tareas de complejidad avanzada, que de otro modo serian dificultosos de realizar con
las herramientas nativas de Asterisk.
El modo en que funciona el AGI es por medio del uso de los canales de comunicación
STDIN, STDOUT y STDERR, que sirven para lograr la interacción entre la central
telefónica Asterisk y programas externos a fin de enviar y recibir información.
STDIN o el estándar de entrada (standard input), es la información que es enviada al

programa externo ya sea desde keyboard, tonos DTMF u otro programa, en una central
telefónica como Asterisk, estos datos son provistos por el mismo Asterisk.
STDOUT o estándar de salida (standard output), es la información enviada en respuesta

a un posible evento generado por el STDIN o a petición del mismo, por lo general en el
ámbito de las telecomunicaciones y tecnologías CTI, esta respuesta está dada por medio
de voz sintetizada.
Finalmente el script AGI puede hacer también el uso del STDERR o error estándar que
es en el que se pueden escribir los mensajes de error que se imprimirán en la consola de
Asterisk para su posterior depuración.
Los principales lenguajes en los que son escritos los programas como AGI scripts son:
Perl, PHP, Pyton, y cualquier otro lenguaje que soporte la utilización de los canales de
comunicación antes descritos. Por lo cual para cada lenguaje de programación existen
librerías especializadas para el manejo de los canales de comunicación para cada
lenguaje en específico.
Existen cuatro formas generales de utilizar AGI, una distinta de la otra, estos son: el AGI
estándar, el dead AGI, fast AGI y el EAGI.
26
El AGI estándar es el más utilizado en el ámbito del desarrollo de aplicativos y el cual
permite el uso de todos los comandos existentes para esta librería, ésta se ejecuta de
manera local en el servidor de Asterisk y se comunica con Asterisk por medio de los
canales de comunicación estándar anteriormente mencionados, con lo cual puede ser
manipulado el plan de discados desde el archivos extensions.conf y por consiguiente el
flujo de la llamada.
El dead AGI es una forma simplificada de AGI, este permite la realización de tareas y el
control de la lógica de programación una vez concluida el flujo de la llamada o cuando
el canal pasa al estado de espera, esta aplicación no puede ser utilizada si el canal en el
que se desea ejecutarla tiene un flujo de llamada.
Fast AGI permite realizar el uso intensivo de recursos de un servidor dedicado,

permitiendo la programación de aplicaciones complejas para AGI descentralizadas del
servidor de Asterisk, de esta forma el servidor de Asterisk procesa únicamente el flujo
de las llamadas y deriva la ejecución de la lógica de AGI al servidor dedicado. El uso de
Fast AGI es recomendado para el desarrollo de aplicaciones de gran envergadura.
EAGI, hace referencia a enhanced AGI, permite la utilización de todos los comandos
AGI y además agrega a la entrada estándar el acceso directo a los canales de audio del
flujo de la llamada en proceso, permitiendo de esta forma realizar un análisis de datos de
audio en bruto.
Por defecto Asterisk encuentra las aplicaciones que leerá el AGI en el directorio
/var/lib/asterisk/agi-bin/
2.4.3 PHP-AGI para Asterisk

El PHP-AGI es un contenedor de clases escrita en lenguaje PHP para posibilitar la
interacción con el Asterisk Gateway Interface, a esta se le puede entender como una
librería que posibilita la programación de aplicaciones complejas en PHP para procesar
las peticiones realizadas desde el dialplan. Los datos de entrada se los obtiene por medio
del STDIN y son enviadas las respuestas por el canal STDOUT. Esta librería también
27
permite ejecutar comandos AGI dentro de la aplicación PHP como si esos comandos
estuvieran escritos en el dialplan. (Simionovich, pág. 103)
2.5 Dialplan o plan de marcado

El dialplan o Plan de marcado es el lenguaje de scripting nativo de Asterisk y es el
corazón de toda central telefónica PBX y por lo tanto de todo servidor basado en
Asterisk, su función principal es gestionar las rutas o acciones que serán realizaras a
partir del marcado de una extensión, es por esto que se puede decir que un dialplan actúa
de similar manera a una tabla de enrutado. Este scripting es interpretado por Asterisk el
cual es almacenado en memoria y permite la configuración del dialplan, en Asterisk se la
hace modificando el contenido del archivo extensión.conf, que generalmente se
encuentra en la ruta /etc/asterisk/, para ello es necesario contar con los permisos
necesarios para la edición de archivos.
El dialplan como tal no admite una estructuración de código procedimental estándar ni

estructuras condicionales o de flujo básico. Pero para su programación se dispone de
etiquetas o funciones tales como el Goto y condicionales nativas básicas.
El dialplan está constituido por cuatro principales conceptos, estos son: contextos,
extensiones, prioridades y aplicaciones.
2.5.1 Contextos
El dialplan está dividido en varias secciones las cuales son conocidas como contextos,
estos contextos son agrupaciones de extensiones que cumplen un determinado propósito
en el flujo de la llamada en base a las extensiones en interacción entre el usuario
llamante y la central telefónica.
Al estar estas extensiones agrupadas en un contexto, dichas extensiones están aisladas

de cualquier otro contexto, pero se permite la interacción de la misma de forma
explícita.
Los contextos tienen la función principal de ordenar y agrupar las extensiones por los
comportamientos en común que estos tienen y de esta forma posibilitar e incluso el
28
compartir una misma central telefónica para diversos objetivos. De forma indirecta al
utilizar los contextos en un dialplan, se provee una capa de seguridad a las extensiones
que estén definidas en los contextos, al ser estas extensiones configuradas para un
determinado acceso de llamadas entrantes y salientes a la misma, o habilitación de
determinadas características para los mismos.
Un contexto está definido por un nombre, pudiendo ser este nombre formado por letras
de la A a la Z, números 0 al 9, guion y la barra baja. Este nombre debe de estar
encerrado entre corchetes ([]) para ser reconocido en el tiempo de ejecución por el
compilador.
2.5.2 Extensiones
El termino extensión en el ámbito de las telecomunicaciones generalmente hace
referencia a un identificador numérico de un dispositivo telefónico en particular,
dotándole de un tono para permitir la comunicación entre otros dispositivos, sin embargo
las extensiones definidas dentro de Asterisk, tiene muchas más funcionalidades ya que
es posible definir en el plan de marcado, una serie de pasos y ejecución de aplicaciones
en el proceso de interacción entre extensiones. Estas extensiones también pueden ser
definidas con comportamientos de telefonía tradicional para algunos usos específicos.
La sintaxis para la definición de una extensión comienza con la palabra “exten” seguida
del signo igual y mayor que, luego de esta sintaxis viene el nombre o número de
extensión.
Una completa definición de extensión, en Asterisk, está formada por tres componentes,
estos son:
 El numero o nombre alfanumérico de la extensión

 La prioridad con la que se ejecutaran las acciones durante la llamada
 Las aplicaciones o comandos que realizaran alguna acción en el transcurso de la
llamada
29
Estos tres componentes son separados por comas en su sintaxis de la siguiente forma:
exten => nombre/número de la extensión, prioridad, aplicación/acción
2.5.3 Prioridades
Cada extensión puede poseer múltiples pasos, llamados prioridades. Cada prioridad esta
enumerada secuencialmente, empezando en uno, el cual ejecuta una específica
aplicación.
A continuación en la figura 2.6 se mostrará un ejemplo de la sintaxis que tendría una

breve configuración de dialplan, en ella se define una extensión con dos prioridades, las
cuales son Answer() y Hangup() con prioridades 1 y 2 respectivamente.
En anteriores versiones de Asterisk las prioridades tenían que ser estrictamente

enumeradas en forma secuencial de tal manera que si se deseaba agregar una acción en
una prioridad inicial tendría que reenumerarse las prioridades de que los precedían, lo
cual hacía del dialplan un código poco mantenible. Es por esta razón en principal que
desde la versión 1.2 de Asterisk se emplea la priorización indirecta, la cual consiste en
especificar de manera obligatoria la primera prioridad con el numeral uno “1” y las
siguientes prioridades especificadas con la letra “n”, ver 2.7.
Internamente Asterisk calculara el siguiente número de prioridad cuando se encuentre la

referencia de la prioridad n.
exten => 123,1,Answer()

exten => 123,2,Hangup()
Figura 2.6: Sintaxis de configuración básica de dialplan para una extensión


exten => 123,n,hacer algo
exten => 123,n,Hangup()
Figura 2.7: Sintaxis de configuración

30
2.5.4 Aplicaciones y funciones
Se denominan aplicaciones a aquellos módulos que realizan algún tipo de acción sobre
algún canal u extensión, y funciones a aquellos que realizan otro tipo de procesamiento
que no afecte directamente a un canal u extensión.
Las aplicaciones son potentes herramientas que proveen complejidad al dialplan, siendo
que cada aplicación realiza una determinada acción a un específico canal, entre estas
acciones se puede mencionar: reproducción de música en espera, aceptación de entrada
de datos por códigos DTMF, finalización de llamada, etc.
Como se pudo ver en las anteriores figuras, se hicieron uso de las aplicaciones Answer(),
Hangup() las cuales tiene la función de aceptar la llamada y finalizarla respectivamente.
Estas aplicaciones no necesitan de información adicional para su correcto
funcionamiento, esta información adicional es conocida como argumento y pueden ser
pasadas a las aplicaciones o funciones para modificar el comportamiento de las mismas
y obtener ciertos resultados.
2.5.5 Interactive Voice Response (IVR)

El sistema de respuesta de voz interactiva se encarga de proveer la funcionalidad
compleja a un plan de marcado dentro de una central telefónica, permitiendo realizar
diversas tareas centradas en la consulta de datos a sistemas externos o bases de datos.
Este sistema permite la captación de datos de entrada durante el transcurso de una
llamada por medio de tonos DTMF o inclusive por órdenes de voz, la cual se conoce
como tecnologías ASR8. En base a la información captada durante la llamada, el sistema
IVR realiza determinadas acciones en respuesta a dicha información, de esta forma el
IVR se constituye como una solución tecnológica que permite la integración de la
telefonía e informática para facilitar las operaciones de negocio o la automatización de
los mismos.
8
ASR, Automatic Speech Recognition, reconocimiento automático del habla, permite al usuario enviar
comandos por medio de la voz humana a un sistema informático.
31
Debido al uso de esta tecnología, las empresas han ido disminuyendo el capital humano
que se encargaba en la realización de esas tareas, aumentando la satisfacción del cliente
respecto a la velocidad de obtención de respuestas en tiempo real. La aplicación de una
solución IVR permite atender a múltiples clientes de forma simultánea 24 horas al día,
365 días al año, gestionar un gran volumen de consultas usuales veloz y eficazmente,
rentabilizar los recursos humanos y materiales dedicados a la atención telefónica,
aumentando la productividad de los departamentos de atención al cliente.
El modo de funcionamiento de IVR inicia cuando el usuario realiza una llamada a un

número de teléfono o extensión perteneciente a una central telefónica configurada con el
sistema IVR, el IVR contesta el llamado y presenta al usuario una serie de acciones a
realizar, esto se hace mediante mensajes (menús de opciones). El usuario elige la opción
al introducir un número a través del teclado numérico del teléfono y navega por los
diferentes menús hasta encontrar la información deseada. La información que
proporciona son respuestas apropiadas en forma de voz, fax, por correo electrónico y
quizá otros medios de comunicación; la información puede ser numérica, puede tratarse
de mensajes pregrabados o de lectura directa desde una base de datos a través de la
tecnología text-to-speech.
El IVR en Asterisk hace uso de AMI y/o de AGI para lograr la interacción con sistemas
externos o permitir la conectividad a distintas base de datos, para de esta forma contar
con un complejo plan de marcados, el cual no solo se limitaría a una contestadora
automática.
Para la configuración y creación de un IVR básico, serán necesarios son los sonidos que
se van a reproducir al ingreso de una llamada. Estos sonidos deben encontrarse en el
directorio de sonidos de Asterisk (normalmente /var/lib/asterisk/sounds/) y tener un
formato reconocido por éste. Junto con Asterisk se distribuye un juego de sonidos
estándar en inglés, pero además existen juegos de voces de gran calidad en castellano,
pero normalmente se requerirán de algunos sonidos personalizados ('gracias por llamar a
la empresa, 'pulse 1 para hablar con el departamento de ventas... ').
32
Para una programación básica de IVR se dispone de algunas aplicaciones básicas para el
dialplan:
 Playback(sonido). Reproduce un sonido.

 WaitExten(tiempo). Espera a que el usuario teclee una opción (o un número de
extensión).
 Background(sonido). Reproduce un sonido, pero el usuario puede interrumpir la
reproducción, tecleando un número de opción. Sería el equivalente a utilizar las
aplicaciones Playback y WaitExten de forma simultánea.
 GotolITime(hora/dias_ semana/dias _ mes/año? si_cierto : si_falso ).Realiza un salto
a otro punto del dialplan dependiendo de la fecha y hora. Resulta muy útil para
actuar de manera distinta dependiendo de un horario dispuesto para la atención de
clientes.
 Set(TIMEUOT(digit)=x). Establece el tiempo máximo permitido entre dígitos una
vez que el usuario teclear una opción. Si pasa este tiempo desde el último dígito
tecleado, el sistema considera que el usuario ha terminado de teclear el número de la
opción y saltará a esa extensión (u opción).
 Set(TIMEOUT(response)=x). Establece el tiempo máximo de espera para digitar una
opción, en caso de que no se digite alguna opción el sistema saltara a la extensión „t‟
2.6 Sintetización de voz - Text To Speach (TTS)

El TTS o sistema de conversión de texto a voz, es la generación, por medios
automáticos, de una voz artificial o sintética que genera idéntico sonido al producido por
una persona al leer un texto cualquiera en voz alta. Es decir, son sistemas que permiten
la conversión de textos en voz sintética por medio de la generación de sonidos a base de
una serie de expresiones generadas por algoritmos.
En 1939 los laboratorios Bell desarrollaron VOCODER, que era un dispositivo de

reconocimiento de voz que utilizaba electrónica y que podía producir sonidos
comprensibles, su finalidad original era la de reconocer voz para luego poder
transmitirla de manera codificada por un medio y sintetizarla en otro extremo.
33
Según el avance tecnológico, los sistemas TTS fueron evolucionando respecto a la
fluidez y claridad con la que se sintetizaban las oraciones. En un inicio estos sistemas
eran propietarios y de código cerrado y por lo tanto de altos costos, por lo cual los
usuarios que podían acceder a esta tecnología eran escasos, siendo el sector bancario el
principal consumidor.
La conversión de texto al habla se desarrolla en varias etapas. El sistema TTS tiene

como punto de entrada un texto, a partir del cual se puede generar una señal sonora. Este
texto debe ser primero analizado, luego transformado en una descripción fonética y en la
siguiente fase se genera la prosodia, a partir de las informaciones existentes, se genera la
señal sonora.
2.6.1 Análisis textual

Esta etapa es la que se encarga de normalizar el texto, es decir traducirlo a un formato de
palabras estándar y por lo tanto más entendible para ser manipulado en la siguiente
etapa. En el caso de la abreviatura "Nr." se genera por expansión la forma ortográfica
"Número", el valor "12" contiene la forma ortográfica "doce" y "1997" se transforma en
"mil novecientos noventa y siete", en el caso de la expresión "1 gata caza a 1 ratón", "1"
será expandido primero como "una" y luego como "un".
2.6.2 Análisis lingüístico

Esta etapa es la que se encarga de convertir el texto normalizado en fonemas. Los
fonemas son las unidades fonéticas que componen un lenguaje hablado. Son sonidos
únicos y diferentes entre sí.
Las letras no se pueden transformar 1:1 en fonemas, ya que la transformación no

siempre es paralela. Una sola letra puede corresponder en ciertos entornos a ningún
fonema o a varios.
Para determinar la entonación correcta de las palabras existen dos estrategias:
 Soluciones basadas en diccionarios con componentes morfológicos, los cuales
almacenan tantos morfemas como sea posible en un léxico. Las distintas formas son
34
captadas por medio de reglas de flexión, derivación y composición.
Alternativamente, se construye un léxico que contiene las distintas formas.
La pronunciación de las palabras que no están en el léxico, se determina por medio
de reglas de entonación.
 En la solución basada en reglas se generan reglas de pronunciación, a partir de la
información fonológica de los diccionarios. Sólo aquellas palabras que en su
pronunciación constituyen la excepción a las reglas, son integradas al diccionario de
excepciones.
2.6.3 Generación de la prosodia

Una vez obtenido el texto representado en fonemas se prosigue a la generación de los
audios para cada fonema, para lo cual son unidas o concatenadas los trozos de audio
correspondientes a cada fonema, alternadas con silencios entre las palabras.
Este proceso tiene un nivel alto de complejidad, pues dependiendo de los algoritmos que
se utilicen para la concatenación de los fonemas audibles, puede resultar en un audio de
baja calidad que tener un tono robótico o inhumano. El algoritmo utilizado por el TTS
Festival se llama Residual Excited Linear Prediction (RELP), con el cual se puede
obtener una voz sintética muy parecida al habla humano.
2.6.4 Festival
Festival es un sistema de síntesis de voz de propósito general para múltiples lenguajes,
desarrollado originalmente por el Centro de Investigación de Tecnologías del Lenguaje
de la Universidad de Edimburgo. La Universidad Carnegie Mellon así como otros
centros de enseñanza han ido realizando contribuciones substanciales al proyecto.
Este TTS se distribuye como software libre con licencia similar a la licencia BSD9.
Festival y las herramientas de síntesis de voz se distribuyen bajo licencia tipo MIT-
9
BSD, es una licencia de software libre permisiva con menos restricciones que una licencia del tipo GLP,
esta licencia permite utilizar el código fuente en software no libre estando muy cercana al dominio
público.
35
X1110 permitiendo uso comercial y no comercial sin restricción, este está escrito en
lenguaje C++ y está implementado como un intérprete de comandos el cual puede
conectarse con diversos módulos y aplicaciones.
El proyecto festival es multilingüe, actualmente soporta inglés (británico y americano), y

español, siendo el inglés es el más avanzado. Las herramientas y la documentación
completas para la utilización de nuevas voces en el sistema están disponibles en el
proyecto FestVox de la Carnegie Mellon University.
En la figura 2.8 se ilustra el proceso general de la conversión de texto a voz por el

sistema Festival.
2.7 Metodología ágil

Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería del
software que están acaparando gran interés y controversia. A mediados de los años 90
comenzó a forjarse una definición moderna de desarrollo ágil del software como una
reacción contra las metodologías utilizadas hasta el momento, consideradas
excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de
planificaciones detalladas previas al desarrollo.
Figura 2.8: Esquema de Conversión de texto a voz con Festival.

Fuente: (Landivar, 2009, pág. 65)
10
Licencia originada en el instituto de Massachusetts (MIT, Massachusetts Institute of Technology), Esta
licencia permite reutilizar el software así licenciado tanto para ser software libre como software
propietario permitiendo no liberar los cambios realizados al programa original.
36
En contraposición a las metodologías convencionales, las metodologías ágiles son
apropiadas cuando los requisitos son emergentes y cambian rápidamente. De este modo,
presentan diversas ventajas en el contexto actual:
 Capacidad de respuesta a cambios a lo largo del desarrollo ya que no los perciben

como un lastre sino como una oportunidad para mejorar el sistema e incrementar la
satisfacción del cliente, considerando la gestión de cambios como un aspecto
característico del propio proceso de desarrollo software.
 Trabajo conjunto entre el cliente y el equipo de desarrollo con una comunicación
directa que pretende mitigar malentendidos, que constituyen una de las principales
fuentes de errores en productos software, y exceso de documentación improductiva.
 Importancia de la simplicidad, eliminando el trabajo innecesario que no aporta valor
al negocio.
 Entrega continúa y en plazos breves de software funcional lo que permite al cliente
verificar in situ el desarrollo del proyecto
 El desarrollo en ciclos de corta duración favorece que los riesgos y dificultades se
repartan a lo largo del desarrollo del producto, principalmente al comienzo del
mismo y permite ir aprendiendo de estos riesgos y dificultades
2.7.1 Scrum
Scrum es el término que describe una forma para desarrollar productos iniciada en
Japón, este un proceso para la gestión y control del producto que trata de eliminar la
complejidad en estas áreas para centrarse en la construcción de software que satisfaga
las necesidades del negocio. Se concentra, principalmente, a nivel de las personas y
equipo de desarrollo que construye el producto. Su objetivo es que los miembros del
equipo trabajen juntos y de forma eficiente obteniendo productos complejos y
sofisticados.
Los elementos generales de un Scrum, están constituidos por:
37
Roles.- Scrum distingue distintos actores con diferentes papeles dentro del proceso. De
forma general, podemos distinguir:
 Propietario del producto o Product Owner, quien es la única persona encargada de la

dirección y control del Product Backlog, es decir, de las historias de usuario que
debe cumplir el sistema.
 Maestro de scrum o Scrum Master, es la persona responsable del éxito al aplicar la
metodología SCRUM en el desarrollo del proyecto o producto, asegurando que los
valores, prácticas y reglas son seguidos por el resto del equipo.
 Equipo de desarrollo ó Scrum Team y cliente o usuario, lo conforman las personas
responsables de implementar la funcionalidad o funcionalidades elegidas por el
Product Owner.
 El cliente es o son los beneficiarios finales del producto, y quienes viendo los
progresos, pueden aportar ideas, sugerencias o necesidades. Su participación es
importantísima e imprescindible en esta metodología.
Product Backlog.- Es un listado de tareas representadas por historias de usuario, que son
el elemento base que utiliza SCRUM para describir las características que el usuario
espera que tenga el software que se va a desarrollar. Por lo tanto, pueden incorporar
tanto cuestiones relacionadas con las funciones del sistema como con cualquier otro
aspecto del mismo (restricciones, rendimiento, etc.). Las historias de usuario se
presentan desde la perspectiva del usuario. Así, no se describen utilizando una
terminología técnica sino que se escriben utilizando un lenguaje cercano al dominio de
la aplicación que se está desarrollando de forma que sea comprensible por los clientes y
por los desarrolladores. Las historias de usuario se construyen bajo un mismo esqueleto
que centra el foco de las características del producto.
Sprint.- En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas, cada

iteración tiene que proporcionar un resultado completo, un incremento de producto que
sea potencialmente entregable, de manera que cuando el cliente lo solicite sólo sea
38
necesario un esfuerzo mínimo para que el producto esté disponible para ser utilizado.
Para este fin el sprint se compone de:
 La planificación del sprint se refiere a la selección de los requisitos o historias de

usuario más prioritarios que se compromete el equipo de desarrollo a completar en la
iteración, de manera que puedan ser entregados si el cliente lo solicita.
 El sprint backlog es un documento detallado conformado por los requisitos
seleccionados en la planificación, donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas
con ninguna tarea de duración superior a 16 horas.
 Scrum daily meeting, tiene por objetivo facilitar la transferencia de información y la
colaboración entre los miembros del equipo para aumentar su productividad, al
poner de manifiesto puntos en que se pueden ayudar unos a otro
La figura 2.9 se muestra los elementos anteriormente descritos y el ciclo de vida del
desarrollo que propone Scrum para un producto software.
Figura 2.9: Flujo de la metodología Scrum

Fuente: (Mitchlacey, 2008)
39
2.8 Norma IEEE 830
El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del
desarrollo de software, puesto que en ella se determinan los “planos” de la nueva
aplicación.
En cualquier proyecto software los requisitos son las necesidades del producto que se
debe desarrollar. Por ello, en la fase de análisis de requisitos se deben identificar
claramente estas necesidades y documentarlas. Como resultado de esta fase se debe
producir un documento de especificación de requisitos en el que se describa lo que el
futuro sistema debe hacer. Por tanto, no se trata simplemente de una actividad de
análisis, sino también de síntesis.
El análisis de requisitos se puede definir como el proceso del estudio de las necesidades
de los usuarios para llegar a una definición de los requisitos del sistema, hardware o
software, así como el proceso de estudio y refinamiento de dichos requisitos, definición
proporcionada por el IEEE (Piattini, 1996). Asimismo, se define requisito como una
condición o capacidad que necesita el usuario para resolver un problema o conseguir un
objetivo determinado (Piattini, 1996).
La figura 2.10 se muestra la estructura de la especificación de requisitos software (ERS)

propuesta por el IEEE en su estándar 830.
A continuación se describirán los elementos mostrados en la anterior estructura.
 Introducción, en esta sección se proporcionará una introducción a todo el documento

de Especificación de Requisitos Software. Consta de varias subsecciones, las cuales
son propósito, ámbito del sistema, definiciones, referencias y visión general del
documento.
 En el acápite propósito se definirá el propósito del documento ERS y se especificará
a quién va dirigido el documento.
40
 Ámbito del sistema, en esta subsección se pondrá nombre al futuro sistema, se
explicará lo que el sistema hará y lo que no hará, se describirán los beneficios,
objetivos y metas que se espera alcanzar con el futuro sistema.
 En definiciones, acrónimos y abreviaturas se definirán todos los términos, acrónimos
y abreviaturas utilizadas en el desarrollo de la ERS.
 En referencias se presentará una lista completa de todos los documentos
referenciados en la ERS.
 Visión General del Producto, en esta subsección describirá brevemente los
contenidos y la organización del resto de la ERS
 Descripción general, en esta sección se describen todos aquellos factores que afectan
al producto y a sus requisitos.
 Perspectiva del Producto, en esta subsección debe relacionar el futuro sistema con
otros productos.
 Funciones del Producto, en esta subsección debe proporcionar un resumen de las
funciones principales que el software debe llevar a cabo.
 Características de los usuarios, aquí se indica el tipo de usuario al que se dirige la
aplicación, así como su experiencia técnica, nivel de conocimientos, etc.
 En restricciones se debe indicar cualquier tipo de limitación como pueden ser
políticas de la empresa, limitaciones hardware, seguridad, protocolos de
comunicación, estándares de la empresa en cuanto a interfaces, etc.
 Requisitos Específicos, en esta sección de la especificación de requisitos software
contiene todos los requerimientos hasta un nivel de detalle suficiente para permitir a
los diseñadores diseñar un sistema que satisfaga dichos requisitos.
 Interfaces Externas, en esta subsección se definirán los requisitos que afecten a la
interfaz de usuario, así como a interfaces de comunicaciones.
 Requisitos de Rendimiento, en esta subsección se incluyen los requisitos
relacionados con la carga que se espera que tenga que soportar el sistema
41
 Restricciones de Diseño, se incluyen aquí todas las restricciones que afecten al
diseño de la aplicación, como pueden ser estándares internos de la organización,
limitaciones hardware, etc.
Figura 2.10: Estructura de una ERS según IEEE 830

Fuente: (IEEE, 1998)
42
3 MARCO APLICATIVO
3.1 Introducción
En este capítulo se aplicarán los conceptos descritos en el marco teórico (Capitulo 2),
con el fin de cumplir con los objetivos propuestos. Se desarrolló la aplicación utilizando
la metodología de desarrollo ágil Scrum y la especificación de los requerimientos
utilizando la norma IEEE 830.
Por medio del uso de esta metodología y la norma se hace posible la recopilación de los
requisitos, la asignación correcta de roles respecto a la participación del desarrollo del
sistema de respuesta de voz interactiva, la planificación de las tareas a realizar, la
gestión y control de los avances del desarrollo del sistema propuesto en el presente
documento.
3.2 Definición de roles

Inova Netwoks como Product Owner será quien define los requerimientos del producto
o sus objetivos y priorizará las tareas en el proyecto.
El Scrum master estará conformado por la docente tutora y la docente asesora quienes se
encargan de eliminar los posibles obstáculos para la culminación de las tareas previstas
en un determinado sprint.
El equipo que estará conformado por el tesista, quien tiene la responsabilidad de diseñar
y desarrollar, conjuntamente con el Producto Owner y el Scrum master, el producto
requerido y de esta forma concretar la entrega del mismo.
3.3 Recopilación de requerimientos

La recopilación de los requerimientos es esencial para el desarrollo del producto, para
este fin se utilizaron herramientas tales como los propuestos por la metodología Scrum
(historias de usuario, fichas de historias de usuario, fichas técnicas e historias técnicas),
la norma IEEE 830 y métodos de diseño y diagramación basados en UML para una
correcta documentación y recopilación.
43
3.3.1 Historias de usuario
En base a la información obtenida por el uso de los instrumentos de investigación
mencionados anteriormente, se puede realizar el análisis de dicha información. Este
análisis deriva en la tabulación de los requisitos identificados por el Product Owner
conocidos también como historias de usuario que además conformarán los
requerimientos funcionales, ver tabla 3.1. Las demás historias de usuario pueden ser
vistas en el anexo F en la sección de historias de usuario.
En base a las historias de usuarios recopiladas, se formó: el Product Backlog o pila de

producto, el cual nos permite asignar el orden en que serán desarrolladas las historias de
usuario y el nivel de prioridad de cada una. A continuación en la tabla 3.2 se mostrarán
diez historias de usuario con sus respectivas prioridades y definición del Sprint, en el
cual serán desarrolladas. El resto de la pila de producto puede ser visto en el anexo F en
la sección de pila de producto.
Tabla 3.1: Historias de usuario

ID Nombre Usuario Descripción

HU-1 Bienvenida Cliente Se escucha la bienvenida al cliente
HU-2 Menú principal Cliente Se escucha el menú principal con todas las opciones
que permitan brindar un servicio al cliente
HU-3 Elección de la primera Cliente El cliente presiona la tecla uno, con la cual elige la
opción del menú primera opción, la cual es el contactarse con el área
principal de ventas
HU-4 Contacto directo con el Cliente La llamada es transferida a un agente de ventas.
área de ventas
HU-5 Elección de la segunda Cliente El cliente presiona la tecla dos, con la cual elige la
opción del menú segunda opción, la cual es el contactarse con el área
principal administrativa.
HU-6 Contacto directo con el Cliente La llamada es transferida al número de interno de
área administrativa recepción del área administrativa
HU-7 Elección de la tercera Cliente El cliente presiona la tecla tres, con la cual elige la
opción del menú tercera opción del menú principal que es el consultar
principal datos respecto a los productos en almacén.
HU-8 Petición de identificación Central Se hace audible la petición de la contraseña que
identifique la validez del usuario para poder realizar
esta acción (consultar información referente a los
productos en almacén)
HU-9 Ingreso de contraseña Cliente El cliente digita, por medio de las teclas numerales en
44
el dispositivo de telecomunicación, la contraseña que
lo identifica como usuario autorizado
HU-10 El cliente ingresa una Cliente En caso de que el cliente no digite una contraseña
contraseña de usuario valida, se escuchará un mensaje de error.
no valida El número de intentos deberá ser menor a tres.
Tabla 3.2: Pila de producto

Spr
ID Nombre Usuario Descripción Importancia
int
HU-1 Bienvenida Cliente Se escucha la bienvenida al cliente 100 2
Se escucha el menú principal con todas
HU-2 Menú principal Cliente las opciones que permitan brindar un 100 2
servicio al cliente
Elección de la primera El cliente presiona la tecla uno, con la
HU-3 opción del menú Cliente cual elige la primera opción, la cual es el 60 2
principal contactarse con el área de ventas
Contacto directo con La llamada es transferida a un agente
HU-4 Cliente 40 3
el área de ventas de ventas.
El cliente presiona la tecla dos, con la
Elección de la segunda
cual elige la segunda opción, la cual es
HU-5 opción del menú Cliente 60 2
el contactarse con el área
principal
administrativa.
La llamada es transferida al número de
Contacto directo con
HU-6 Cliente interno de recepción del área 40 3
el área administrativa
administrativa
El cliente presiona la tecla tres, con la
Elección de la tercera
cual elige la tercera opción del menú
principal que es el consultar datos
principal
respecto a los productos en almacén.
Se hace audible la petición de la
contraseña que identifique la validez
Petición de
HU-8 Central del usuario para poder realizar esta 90 3
identificación
acción (consultar información referente
a los productos en almacén)
El cliente digita, por medio de las teclas
numerales en el dispositivo de
HU-9 Ingreso de contraseña Cliente 80 3
telecomunicación, la contraseña que lo
identifica como usuario autorizado
En caso de que el cliente no digite una
El cliente ingresa una contraseña valida, se escuchará un
HU-10 contraseña de usuario Cliente mensaje de error. 70 3
no valida El número de intentos deberá ser
menor a tres.
45
Ahora se definirán las fichas de historias de usuario en base a la pila de producto, a
continuación en la figura 3.1, se mostrarán las dos primeras fichas de historias de
usuario y el resto de las fichas pueden ser vistas en el anexo F en la sección de fichas de
historias de usuario.
Las actividades de ingeniería identificadas en base a las historias de usuario, aportarán al

desarrollo del proyecto aun cuando no están contempladas en las historias de usuario y
tampoco están directamente relacionadas con estas. Las actividades mencionadas son
también llamadas historias técnicas, de las cuales se describen las diez primeras en la
tabla 3.3, las historias restantes pueden ser vistas en el anexo F en la sección de historias
técnicas.
HISTORIA DE USUARIO HISTORIA DE USUARIO

ID HU-1 Importancia 100 ID HU-2 Importancia 100
Nombre Nombre
Bienvenida Menú principal
Usuario Usuario
Cliente Cliente
Figura 3.1: Fichas de historias de usuario

Tabla 3.3: Historias técnicas

Estimación
ID Nombre Responsable Sprint
horas
Instalación y configuración de servidor

HT-1 2 Cesar Nilton Rojas Valero 1
de aplicaciones web en Centos
Instalación y configuración de TTS

Festival
Instalación de librerías AdoDB PHP
HT-3 como manejador de conexiones a 6 Cesar Nilton Rojas Valero 1
DBMS
Configurar DBMS MySQL para permitir Cesar Nilton Rojas Valero
HT-4 1 1
conexiones remotas Administrador de hosting
Configuración de Crontab para

realización de tareas en segundo plano
46
Pruebas de conexión remota desde
HT-6 servidor local de aplicaciones web, a 1 Cesar Nilton Rojas Valero 1
servidor de base de datos exterior
Pruebas de efectividad de realización
de tareas con Crontab
Crear y documentar el diseño general

del sistema IVR principal
Crear y documentar las grabaciones

para el menú principal
Crear y documentar el inicio de la

llamada al sistema IVR (Saludo)
Una vez definidas las historias técnicas, se crearon las fichas técnicas, en las cuales de
describe a mayor detalle el modo de desarrollo de cada historia, a continuación en la
figura 3.2 se pueden ver las fichas de la primera y segunda historia técnica, el resto de
las fichas técnicas pueden ser vistas en el anexo F en la sección de fichas técnicas.
3.3.2 Especificación de requerimientos en base a la norma IEEE 830
3.3.2.1 Introducción
A continuación se desarrollará los acápites propuestos por la norma IEEE 830 adecuados
al ámbito de estudio del presente trabajo.
3.3.2.1.1 Propósito
El propósito de la presente especificación es definir los requerimientos que deberá de
satisfacer el sistema IVR propuesto en el presente trabajo, el cual abordará la consulta de
información de los productos respecto a su almacenaje y la automatización de alertas
tempranas ante un posible desabastecimiento de productos en almacén.
3.3.2.2 Descripción general del producto
3.3.2.2.1 Perspectiva del producto

El presente producto deberá ser capaz de funcionar correctamente en la central de
telecomunicaciones de la empresa Inova Networks, pues esta central será la que
administre la ruta hacia el IVR para una llamada entrante a la línea troncal de la
empresa.
47
HISTORIA TÉCNICA HISTORIA TÉCNICA
ID HT-1 ID HT-2
Nombre Nombre
Instalación y configuración de servidor de Instalación y configuración de TTS Festival
aplicaciones web en Centos
Descripción Descripción
Se instala y/o actualiza PHP en el sistema Se instala el sintetizador de voz Festival,
operativo Centos obteniéndolo desde la dirección: “apt-getinstall
Se modifican festival festvox-ellpc11k”, se modifican los archivos
de configuración etc/asterisk/festival.conf para
redireccionar el ejecutable de festival,
/usr/share/festival/festival.scm para permitir que
Asterisk utilice los servicios de festival,
/usr/share/festival/init.scm para acceso al log de
actividades durante la sintetización.
Usuario Usuario
Cliente Cliente
Importancia Estimación Importancia Estimación

100 2 100 6
Figura 3.2: Ficha de historia técnica

El producto tendrá la capacidad de realizar conexiones en tiempo real con la base de

datos del sistema web de control y gestión de almacenes. El fin del producto es
satisfacer la obtención y recepción de información en tiempo real, de forma precisa y
actualizada.
3.3.2.2.1.1 Interfaces de usuario

La interacción con el usuario se realizó a través del sistema IVR, el cual se ejecutará al
momento en que la central de telecomunicaciones Asterisk reciba una llamada a la línea
troncal, seguidamente se reproducirá un sonido audible con las opciones de
navegabilidad y también realizará el dictado de la información requerida, conociéndose
esto como una interfaz de voz. El esquema de funcionamiento de esta interfaz puede ser
visto en la figura 3.3.
48
Realiza llamada a la
línea
telefonica2XXXXXX
Interfaz con el usuario
RTC, GSM, Respuesta audible
UMTS, 4G, VoIP

Usuario
Asterisk IVR
Figura 3.3: Interfaz de usuario

3.3.2.2.1.2 Interfaces de hardware

El sistema IVR inicia sus procesos una vez que recibe alguna llamada por medio del
servidor de telecomunicaciones Asterisk, por lo cual el usuario que desea interactuar con
el sistema IVR tendrá que contar con un dispositivo telefónico conectado a una red de
telefonía conmutada o a una red móvil o estar dentro de la red interna de la empresa
Inova Networks, a fin de que el usuario pueda realizar llamadas a la línea troncal
telefónica de la empresa. El esquema de la interfaz definida anteriormente puede ser
visto en la figura 3.4.
El dispositivo telefónico del usuario deberá contar con la emisión de tonos DTMF, los
cuales serán indispensables para el ingreso a las opciones del IVR e ingreso de los
parámetros de entrada tales como los códigos de productos y contraseña de usuario
requeridos por el sistema IVR.
49
INTERNET BD_ALMACEN
Servidor para el sistema almacenes
Telefono IP
Vo
IP
Interfaz de harware
Telefono IP
RTC, GSM,
UMTS, 4G
Asterisk
Movil Red interna Inova
Softphone
Softphone
Telefono fijo Telefono IP
Figura 3.4: Interfaz de hardware

3.3.2.2.1.3 Interfaz de software

El servidor de comunicaciones Asterisk deberá de contar con todos los sistemas y
dependencias internos como: sistema de síntesis de voz, sistema de correos electrónicos,
gestor de procesos en segundo plano Crontab y PHP, que permitan el correcto
funcionamiento del producto propuesto en el presente trabajo.
Se deberá contar con mínimo de 100Mb de espacio libre en disco duro para poder
guardar los archivos de configuración, líneas de código y los archivos de audio
necesarios para el funcionamiento del sistema IVR.
Todas las dependencias, sistemas y servidores requeridos e involucrados durante el

funcionamiento del sistema IVR, pueden ser vistos en la figura 3.5.
50
3.3.2.2.1.4 Interfaz de comunicación
Para el correcto funcionamiento y correcta interacción con el sistema IVR, el dispositivo
telefónico en caso de estar conectado a la red de telefonía conmuta deberá de contar con
tono de llamada y en caso de estar conectado a una red de telefonía móvil deberá de
estar dentro del rango de -50 dBm11 y -69 dBm que indica una intensidad de señal
celular aceptable (Winder, 2001, pág. 17).
3.3.2.2.1.5 Operaciones
Las operaciones descritas a continuación, se basan principalmente en la abstracción de
las tarjetas de historias técnicas y las historias de usuario, anteriormente identificadas.
Al ingresar al sistema IVR, los usuarios podrán acceder hasta un primer nivel de
opciones sin ninguna restricción y de manera libre, lo que favorecerá la aceptación por
parte del usuario para consultar algunos servicios. Para el ingreso al segundo nivel de
opciones de la opción tres del primer nivel se pedirá el ingreso de una contraseña al
usuario a fin de autentificarlo y verificar la autorización. Esta contraseña deberá de ser
ingresada por medio de los tonos DTMF. Seguidamente se le pedirá al usuario el ingreso
del código de producto del cual desea realizar consultas.
Servidor de telecomunicaciones local
Driver de
Servidor de aplicaciones remoto
conexión a Canales
TTS
DBMS AGI Sip, Iax, Servidor de aplicaciones web
Festival
Zap Servidor de
Interfaz de software
externo
Cron base de
datos
Servidor de correos
Servidor de
aplicaciones Asterisk
Servidor remoto – hosting externo

Sistema operativo Centos
Figura 3.5: Interfaz de software

11
Unidad de medida utilizada principalmente en telecomunicaciones para expresar la potencia absoluta
mediante una relación logarítmica, se define como el nivel de potencia en decibelios en relación a un
nivel de referencia de 1 miliwatt
51
La descripción del flujo de la llamada y el árbol de opciones para los menús principal y
secundario del sistema IVR, para el subsistema de consultas a almacén, están detalladas
en el diagrama de flujo en la figura 3.7.
El subsistema de alertas tempranas automática seleccionará a al usuario autorizado a

recibir información de desabastecimiento y realizará la llamada pertinente a dicho
usuario a fin proporcionar la información en formato audible, seguidamente por medidas
de seguridad se pedirá al usuario ingresar su código de usuario. En caso de que el
usuario desease obtener la información de desabastecimiento, deberá de ingresar su
código de usuario y contar con los privilegios necesarios para acceder a la información
de los productos. Una vez validado el usuario tendrá acceso a obtener información sobre
los productos que se encuentren desabastecidos e inclusive el de recibir un informe
detallado de los mismos en el correo electrónico al cual este asociado el usuario.
La descripción del flujo de la llamada y el árbol de opciones para el menú IVR del
subsistema de alerta temprana, están detalladas en el diagrama de flujo en la figura 3.8.
3.3.2.2.2 Funciones del producto

Las funciones que realizará el producto son clasificados en los siguientes bloques, ver
figura 3.6, en el cual puede observarse la relación que guardan dichas bloques y la forma
en la que interactúan en un alto nivel.
El procesamiento de la llamada tanto como el procesamiento de la información de

entrada y salida respecto al sistema IVR, para las consultas a almacén y consultas sobre
el desabastecimiento de productos, será descrito en los siguientes diagramas de flujo, ver
figura 3.7, 3.8.
52
Alerta de
Menú principal
desabastecimiento
Area de Consultas a
Area de ventas
administración almacen
Procesamiento de
datos
Personal Gestor de consultas Gestor de alertas de

Personal de ventas
administrativo a almacnes stock minimo
Comunicación de
resultados
Figura 3.6: Diagrama de paquetes del sistema IVR

53
A
Mensaje de Se lista las opciones

SI
bienvenida del menú principal
ANSWER
ANSWER
Se captura el tono
DTMF ingresado
por el usuario
Transferencia de
Mensaje de opción ¿Menor a tres
llamada al área de Opción 1 ¿Opción válida? No NO
no valida intentos?
ventas
HANGUP
HANGUP
Transferencia de Transferencia a
llamada al área Opción 2 Opción 3 gestor de consultas
administrativa a almacenes
Opcion 4
Mensaje de
petición de
Iconografía B contraseña de
Reproducción de un Transferencia de usuario
mensaje llamada a operador SI
Se capturan los
Listado de opciones tonos DTMF
en forma audible ingresados por el
usuario
Captura de datos
Mensaje de acción Mensaje de saludo ¿Usuario Mensaje de clave
NO
incorrecta a usuario valido? erronea
Control de acceso
Consulta a base de Mensaje de

petición de código SI ¿Menor a tres
datos de producto intentos?
NO
NO
Se capturan los
tonos DTMF A
ingresados por el
usuario
¿Código de
producto NO
no valida intentos?
NO B
valido?
Op. 4 SI
Mensaje de producto
seleccionado
(categoría y nombre )
Se lista las opciones

C del menú de SI
almacenes

¿Opción válida? NO
no valida intentos?
Op. 1 Op. 2 Op. 3
Consulta de stock Consulta de

actual Consulta de precios descripción general
del producto
Figura 3.7: Diagrama de flujo de IVR principal y consultas a almacén

54
Mensaje de Se capturan los
¿Menor a tres petición de tonos DTMF
SI
intentos? contraseña de ingresados por el
usuario usuario
NO
Mensaje de clave ¿Usuario
erronea valido?
Mensaje: usuario
no autorizado
Mensaje de
bienvenida
HANGUP
HANGUP Verifica la
existencia de
productos
desabastecidos
Mensaje que
Mensaje que indica ¿Cantidad de
comunica la
que los productos productos con
SI existencia de
tiene un stock stock mínimo
productos con
aceptable mayor a 0?
stock minimo
Se lista las opciones

SI del menú de A
Mensaje de consultas
despedida
¿Menor a tres Se captura el tono

NO DTMF ingresado
intentos?
por el usuario
Iconografía
Reproducción de un
mensaje Mensaje de opción
NO ¿Opción Valida?
no valida
Listado de opciones
en forma audible
Op. 1 Op. 3
Captura de datos Op. 2
Envio de correo con

Mensaje de acción Listado de id’s de
informe de
incorrecta los productos con Listado de los productos con
stock minimo nombres de los stock minimo
Control de acceso productos con
stock minimo
Consulta a base de
datos A
Envío de email
Figura 3.8: Diagrama de flujo de alertas automáticas ante desabastecimientos

55
En base al flujo de la llamada y los bloques identificados, pueden definirse de mejor
manera las funciones globales que conforman el producto final y detallar las tareas
específicas de cada funcionalidad en forma de casos de uso. A continuación se describirá
extensamente el bloque de consultas a almacén. Los demás bloques vistos en la figura
3.6 serán descritos en el anexo G.
3.3.2.2.2.1 Consultas a almacén

El subsistema de consultas a almacén, cumplirá la función de mantener informado a un
grupo de usuarios autorizados, sobre el almacenaje de los distintos productos, a fin de
controlar y administrar de mejor manera los recursos de la empresa, evitando el sobre
almacenaje y principalmente evitando el desabastecimiento de productos en el almacén.
A continuación se describirá por medio de un diagrama de casos de uso, (ver figura 3.9)
el comportamiento general del subsistema de consultas a almacén.
En las tablas 3.4 al 3.9, se describirán las funciones que tendrán que cumplir los casos de
uso mostrados en la figura 3.9.
Recibir información
Ingresar información
requerida (contraseña de
usuario)
Usuario
Validar usuario
Ingresa código de
producto
Validar Codigo
producto
Gestor de consultas
Entregar
información consultada
Figura 3.9: Diagrama de caso de uso – subsistema consultas a almacén

56
Tabla 3.4: Caso de uso 3.1 - Recibir información
CU – 3.1 Recibir información
Descripción Al ingreso del menú principal del sistema IVR, el cliente recibirá un
mensaje audible de bienvenida e información sobre el digito de
opción que permitirá realizar consultas respecto a la información de
productos en almacén. Posteriormente, con una pausa de al menos
2 segundos, se volverá a repetir las opciones del menú principal del
IVR
Actores Cliente
Precondiciones El cliente deberá de estar en línea para poder escuchar los mensajes
audibles del sistema IVR
Secuencia normal de eventos Paso Acción
1 El cliente recibirá un mensaje de bienvenida
2 El cliente escuchará como menú el digito de opción que le
dirigirá a la aplicación que gestionara las consultas
respecto a la información de productos en almacén
Postcondición No aplica, puesto el cliente solamente recibirá información y solo
escuchara las opciones de un menú
Excepciones Paso Acción
1 Si el cliente no elige alguna de las opciones indicadas en el
menú, se le informará que la opción seleccionada no es
válida.
2 Si existiesen tres intentos erróneos de elección de alguna
opción del menú, el cliente recibirá un mensaje de
despedida y se concluirá la llamada.
Tabla 3.5: Caso de uso 3.2 – Atención al cliente

CU – 3.2 Ingresar información requerida (contraseña de usuario)
Descripción Una vez ingresado al subsistema de consultas a almacén, el usuario
escuchará un mensaje en el cual se le pedirá ingresar su contraseña, a
fin de validar el acceso del usuario.
Actores Cliente
Precondiciones El usuario deberá de contar con un dispositivo telefónico que emita
tonos DTMF.
El usuario deberá de discar la opción del menú principal para la
realización de consultas a almacén.
1 El cliente elegirá la opción de consultas a almacén
2 Se hará audible un mensaje de petición de contraseña de
usuario
3 El usuario ingresará una secuencia de números vía tonos
DTMF que representaran la contraseña del usuario
Postcondición Los tonos DTMF ingresados por el usuario llamante, deberán de ser
capturados por el sistema DTMF y almacenados en una variable para
su posterior validación contra la base de datos.
57
1 Si el cliente no digita ningún numero en su teclado de
dispositivo telefónico durante los próximos 1.5 segundos, ,
este recibirá un mensaje en el que se le informa que la
contraseña es errónea y se volverá a escuchar el mensaje de
requerimiento de contraseña
2 Si existiesen tres intentos erróneos de ingreso de contraseña
y se le remitirá al menú principal del sistema IVR.
Tabla 3.6: Caso de uso 3.3 – Validar usuario

CU – 3.3 Validar usuario
Descripción Una vez que el usuario termine de ingresar la contraseña requerida
en CU - 3.2, se captura y almacena los tonos DTMF digitados,
posteriormente se verifica la validez de dicha contraseña en base a
una consulta a la base de datos del sistema web de almacenes.
Actores Gestor de consultas
Precondiciones Se deberá de contar con tonos DTMF ingresados por el usuario
1 Se captura los tonos DTMF
2 Se realiza una consulta a la base de datos a fin de validar la
contraseña introducida vía tonos DTMF
Postcondición El usuario estará informado de si está autorizado a acceder a la
información referente a los productos y se le dará acceso a la
realización de consultas respecto a la información de los productos
en almacén.
1 Si el cliente ingresa una contraseña no valida, este
escuchara un mensaje de error de clave de usuario
2 Si el cliente ingresa una contraseña valida y es
autentificado contra la base de datos, este escuchara un
mensaje de bienvenida con el nombre del usuario validado
3 Si existiesen tres intentos erróneos ingreso de contraseña,
el cliente recibirá un mensaje de error de clave de usuario y
se lo remitirá al menú principal del IVR.
Tabla 3.7: Caso de uso 3.4 – Ingresar código de producto

CU – 3.4 Ingresar código de producto

Descripción Una vez que el usuario sea validado para el acceso a la información
de los productos, se hace audible un mensaje en el que se pide al
usuario ingresar el código del producto que desea consultar.
Actores Usuario validado
Precondiciones El usuario deberá ser válido para el acceso a la información de los
productos.
1 El usuario escuchara el mensaje de petición de código de
producto
58
2 El usuario ingresara el código de producto a consultar vía
tonos DTMF
Postcondición Los tonos DTMF ingresados por el usuario llamante, deberán de ser
capturados por el sistema DTMF y almacenados en una variable
para su posterior validación contra la base de datos.
1 Si el usuario no ingresa ningún código de producto, este
escuchará un mensaje de error de código de producto y
seguidamente se le pedirá al usuario ingresar el código de
producto nuevamente.
2 Si existiesen tres intentos erróneos de ingreso de código, el
cliente recibirá un mensaje de error de código y se le
pedirá al usuario ingresar nuevamente su contraseña de
usuario CU – 3.2.
Tabla 3.8: Caso de uso 3.5 – Validar código de producto

CU – 3.5 Validar código de producto

Descripción Una vez que el usuario termine de ingresar el código de producto
requerido en CU - 3.4, se captura y almacena los tonos DTMF
digitados, posteriormente se verifica la validez de dicho código en
base a una consulta a la base de datos del sistema web de
almacenes.
Actores Gestor de consultas
Precondiciones El usuario deberá ser válido para el acceso a la información de los
productos.
1 El usuario escuchara el mensaje de petición de código de
producto
2 El usuario ingresara el código de producto a consultar vía
tonos DTMF
Postcondición El usuario tendrá conocimiento de la validez del código de
producto ingresado
1 Si el usuario ingresa un código no valido, este escuchará un
mensaje de error de código de producto y seguidamente se
le pedirá al usuario ingresar el código de producto
nuevamente.
2 Si el usuario ingresa un código valido y es autentificado
contra la base de datos, este escuchará un mensaje de
compuesto por la categoría del producto y el nombre del
producto, seguidamente el usuario recibirá un mensaje
audible del menú de opciones para el sistema IVR
cliente recibirá un mensaje de error de código y se le
pedirá al usuario ingresar nuevamente su contraseña de
usuario CU – 3.2.
59
Tabla 3.9: Caso de uso 3.6 – Entregar información consultada
CU – 3.6 Entregar información consultada

Descripción Una vez que sea validado el código de producto ingresado, se hará
audible un menú de opciones referente a las consultas permitidas
sobre los productos en almacén, los cuales emitirán la información
requerida en forma audible.
Estas opciones son: Consulta de stock en almacén, consulta de
precios del producto seleccionado, consulta sobre la descripción
general del producto seleccionado.
Actores Usuario, Gestor de consultas
Precondiciones El usuario deberá ser válido, el código de producto deberá de ser
válido.
El usuario deberá de estar en línea para poder escuchar los
mensajes audibles de respuesta a las consultas.
1 El usuario recibirá un mensaje audible de las opciones
permitidas de consulta
2 El usuario elige alguna de las opciones de consulta
3 El usuario recibe en forma audible la respuesta a sus
requerimientos, enmarcado en la lista de opciones antes
mencionada
4 Una vez concluida la recepción de la respuesta, se redirigirá
al paso 1
Postcondición El usuario recibirá información concerniente a los productos en
almacenen.
1 Si el usuario ingresa un digito de opción no valido, este
escuchará un mensaje de error y seguidamente se hará
audible el listado de opciones para la realización de
consultas.
2 Si el usuario ingresa un código valido, este escuchará la
información requerida y seguidamente se listarán las
opciones para la realización de nuevas consultas.
usuario recibirá un mensaje de error de código y un
mensaje de despedida finalizando la llamada.
3.3.2.2.3 Atenciones y dependencias

El servidor de aplicaciones web (PHP), servidor de base de datos (MySQL), servicios de
sintonización de voz TTS (Festival), servicios de procesamiento en segundo plano de
Unix (Cron), el servidor de telecomunicaciones (Asterisk), servidor de correos
electrónicos, línea telefónica troncal conectado a Asterisk, deberán de estar disponibles y
funcionales sin ningún tipo de interrupción, o ser restablecidos a la brevedad posible, a
60
fin de que el sistema IVR y todos los módulos y servicios que ofrece funcionen
adecuadamente.
3.4 Agenda del proyecto

A continuación en la figura 3.10 se detallan las tareas que se llevarán a cabo para la
realización y culminación del producto propuesto en el presente documento, a fin de
desarrollar todos los Sprint propuestos en los lapsos de tiempo mostrados en dicha
figura.
3.5 Desarrollo del Sprint

Los requerimientos recopilados hasta el momento por medio de las herramientas tales
como las historias de usuario de Scrum en el acápite 3.4 y la utilización de la norma
IEEE 830 para la especificación de los requerimientos, son utilizados para la correcta
definición del Product Backlog, de las actividades de ingeniería y a su vez para la
planificación de los Sprint. Cada uno de estos Sprint serán vistos en detalle en los
siguientes acápites.
Tomar en cuenta que se tomó como semana de trabajo los días habilites laborales, es
decir los días lunes a viernes y cada una con 6 horas diarias de trabajo, adecuados a la
disponibilidad de tiempo por parte de la empresa Inova Networks.
sep. 2013 oct. 2013
Id. Nombre de tarea Comienzo Fin Duración
1/9 8/9 15/9 22/9 29/9 6/10
SPRINT 1 - Instalación y
1 configuración de dependencias y 30/08/2013 02/09/2013 3d
servicios
SPRINT 2 – Diseño y desarrollo de
2 03/09/2013 14/09/2013 11d
sistema IVR principal
SPRINT 3 - Verificación y validación
3 de ingreso de usuario a modulo 16/09/2013 21/09/2013 6d
gestor de consultas a almacén
SPRINT 4 - Diseño de modulo de
4 23/09/2013 27/09/2013 5d
consultas a almacén
SPRINT 5 - Diseño y desarrollo de
5 menú para modulo de alerta ante 30/09/2013 10/10/2013 10d
desabastecimiento
Figura 3.10: Cronograma de agenda de proyecto Scrum

61
El esquema de presentación general de cada Sprint se basara en los siguientes puntos:
 Planificación: Definición del objetivo inicial para el sprint en curso

 Desarrollo: Desarrollo de las tareas definidas para el sprint
 Finalización: verificación dl cumplimiento del objetivo inicial, reporte de novedades
finales
Dentro del desarrollo de los Sprint se consideran el cronograma que contiene las tareas
del sprint, el Backlog inicial, el Backlog final y el Burndown como referente al avance
de la culminación de las tareas del Sprint.
3.5.1 Sprint 1
3.5.1.1 Planificación
El objetivo del Sprint 1, es adecuar los servidores de Inova Networks a los
requerimientos del producto en desarrollo, para tal fin se realizarán las instalaciones de
distintos servicios, servidores y configuración de dependencias en los servidores ya
existentes pertenecientes a la empresa.
En la figura 3.11 se presenta el Sprint inicial con su cronograma estimado de trabajo y el

listado de tareas a cumplir. Estas tareas están adecuadas a fin de cumplir el objetivo de
este Sprint. A continuación en la figura 3.12 se mostrará a detalle las tareas que serán
realizadas en el Sprint 1 cada uno con su respectiva estimación de esfuerzo, los cuales a
su término se constituirán en las bases del desarrollo del producto.
62
ago. 2013 sep. 2013
30 31 1 2
SPRINT 1 - Instalación y configuración de

1 30/08/2013 02/09/2013 3d
dependencias y servicios
Instalación y configuración de servidor de
2 aplicaciones web en Centos (servidor que aloja a 30/08/2013 30/08/2013 1d
Asterisk)
3 Instalación y configuración de TTS Festival 30/08/2013 31/08/2013 2d
Configurar DBMS MySql para permitir
4 31/08/2013 31/08/2013 1d
conexiones remotas
Instalación de librerías AdobDB Php como
5 02/09/2013 02/09/2013 1d
manejador de conexiones a DBMS
Pruebas de conexión remota desde servidor
6 local de aplicaciones web, a servidor de base de 02/09/2013 02/09/2013 1d
datos exterior
Configuración de Crontab para realización de
7 02/09/2013 02/09/2013 1d
tareas en segundo plano
Pruebas de efectividad de realización de tareas
8 02/09/2013 02/09/2013 1d
con Crontab
Figura 3.11: Backlog inicial, Sprint 1

Sprint 1inicial: Instalación y configuración de dependencias y servicios

Sprint Inicio Núm. días
1 30/08/2013 3
Tareas pendientes 6
Horas de trabajo pendientes 18
Esfuerzo
PILA DEL SPRINT
estimado
Backlog ID Tarea Tipo Estado Responsable horas
Instalación y configuración de servidor de
HT-1 Instalación Pendiente Cesar Rojas 2
aplicaciones web en Centos
HT-2 Instalación y configuración de TTS Festival Instalación Pendiente Cesar Rojas 6
Cesar Rojas
Configurar DBMS MySQL para permitir
HT-3 Configuración Pendiente Administrador 6
conexiones remotas
de hosting
Instalación de librerías AdoDB PHP como
HT-4 Instalación Pendiente Cesar Rojas 1
manejador de conexiones a DBMS
Pruebas de conexión remota desde servidor local
Pruebas de
HT-6 de aplicaciones web, a servidor de base de datos Pendiente Cesar Rojas 1
conectividad
exterior
Configuración de Crontab para realización de
HT-5 Configuración Pendiente Cesar Rojas 1
tareas en segundo plano
Pruebas de efectividad de realización de tareas
HT-7 Pruebas Pendiente Cesar Rojas 1
con Crontab
Figura 3.12: Backlog inicial, Sprint 1

63
3.5.1.2 Desarrollo
La instalación y configuración del software fue realizado en los servidores y equipos de
los que disponen en la empresa Inova Networks, siendo estos: un servidor de
telecomunicaciones Asterisk, un servidor de aplicaciones web alojado en un hosting
externo, un servidor de base de datos MySQL alojado en un hosting externo.
Se verificó que el servidor local Asterisk ya contaba con una versión de PHP instalada,
sin embargo dicha versión era ya obsoleta por lo cual utilizando la herramienta YUM12
se descarga, actualiza e instala el compilador e interprete para el lenguaje PHP en su
versión 5.1.6 para aun correcto funcionamiento respecto los programas a ser
desarrollados.
Para la instalación y configuración de TTS Festival, inicialmente se descargó el paquete

de instalación del TTS con el comando: apt-getinstall festival. Una vez instalado, se
modificó los archivos de configuración para permitir que Asterisk pueda utilizar los
servicios de Festival, para dicho fin se debe de acceder al directorio: /usr/share/festival y
editar el fichero festival.scm, agregando el script mostrado en la figura 3.13
También se editó el fichero init.scm que se encuentra en el directorio /usr/share/festival.

La modificación que se debe de realizar es el de comentar las líneas uno y dos mostradas
en la figura 3.14 y agregar las líneas tres y cuatro mostradas en dicha figura.
(set! voice_default 'voice_el_diphone)

(define (tts_textasterisk string mode)
"(tts_textasterisk STRING MODE)
Apply tts to STRING. This function is specifically designed for
use in server mode so a single function call may synthesize the string.
This function name may be added to the server safe functions."
(let ((wholeutt (utt.synth (eval (list 'Utterance 'Text string)))))
(utt.wave.resamplewholeutt 8000)
(utt.wave.rescalewholeutt 5)
(utt.send.wave.clientwholeutt)))
Figura 3.13: Configuración para integrar Asterisk y festival.

12
Herramienta libre de gestión de paquetes para sistemas Linux basados en Red HatPackage Manager
(RMP)
64
;(eval (list voice)) ;línea 1
;(provide 'init) ;línea 2
;; cambiar las dos líneas anteriores Por
(eval (list voice_el_diphone)) ;línea 3
(provide 'init) ;línea 4
Figura 3.14: comando para acceder al log de actividades en tiempo real de Asterisk
Para probar la funcionalidad correcta del sintetizador de voz Festival y la integración

con Asterisk, se debe de agregar las líneas de código mostradas en la figura 3.15, en el
archivo de configuración de las extensiones de Asterisk, el cual se encuentra en el
directorio /etc/Asterisk/extensions.conf. Este código permite sintetizar y hacer audible el
texto enviado como parámetro a la función Festival.
Para configurar el DBMS MySQL y permitir conexiones remotas se realizó una petición
al administrador de base de datos del hosting externo, en el cual se aloja el servidor,
solicitándole la edición de privilegios para el usuario U a fin de que este usuario tenga
permitido realizar consultas remotas. El comando utilizado para la modificación de
privilegios de usuario y asignarle privilegios de acceso remoto puede ser visto en la
figura 3.16 sección A. También se agregaron permisos de acceso al servidor de
telecomunicaciones Asterisk, registrando la IP publica de dicho servidor en la lista de
host remotos en el sistema del hospedaje, dicha configuración puede ser vista en la
figura 3.16 sección B.
Las pruebas de conexión remota al servidor de base de datos alojado en un hosting

externo, son realizadas en modo gráfico, desde una pequeña aplicación que consume
datos de una tabla de pruebas creada en el DBMS MySQL, esto es posible por la
configuración y asignación de privilegios de acceso remoto a un usuario registrado en el
DBMS y por la utilización de la librería AdoDB en PHP que se encarga de la gestión de
la conexión con la base de datos, siendo que se le provee a esta librería el nombre de
dominio o dirección IP del DBMS, el nombre de usuario, su contraseña y el nombre de
la base de datos al cual se desea acceder remotamente, el modo en que se provee esta
65
información, a la función conect() de la librería AdoDB, puede ser vista en la figura 3.17
en la sección A.
A continuación en la figura 3.17 sección B, se muestra una captura de pantalla
verificando el éxito de conexión remota a la base de datos.

exten => 650,n,Festival(esta es una prueba)
exten => 650,n,Hangup()
Figura 3.15: Código de prueba de funcionamiento de Festival

//Sección A - Configuración de usuario U para acceso remoto.

#mysql -u root –p *
mysql> GRANT ALL PRIVILEGES ON *.* TO u@'%' IDENTIFIED BY 'p' WITH GRANT
OPTION;
mysql> FLUSH PRIVILEGES;
mysql> exit
//Sección B – Agregación de host para el acceso remoto.
Figura 3.16: Configuración para acceso remoto a MySQL

//Sección A
ADONewConnection('mysql://U:P@XXX.XXX.XXX.XXX/xxxxxx_tienda')
//Sección B
Figura 3.17: Cadena de conexión a base de datos remota con AdoDB y éxito de conexión
66
Las pruebas respecto a la efectividad de la realización de tareas con Crontab, son
realizadas en modo consola, agregando comandos cron al Crontab en Centos (ver figura
3.18), y configurándolo de tal forma que realice una tarea cada lapso de tiempo, la
verificación del correcto funcionamiento del comando puede ser visto en la figura 3.19,
en la cual se puede ver el log sobre las tareas realizadas por el demonio cron, este log fue
obtenido desde el directorio /var/log ingresando al archivo cron.log
3.5.1.3 Finalización del Sprint 1

Se realizó la revisión de las tareas efectuadas en el Sprint uno y no se tiene ninguna
observación sobre el desarrollo de las mismas, el tiempo estimado del sprint fue de 18
horas en el Backlog inicial concluyendo sin horas de trabajo a favor.
En los siguientes gráficos se mostrarán el Backlog final y el burdown del Sprint uno, que
muestran las horas invertidas por día para la realización de las tareas del Sprint (ver
Figuras 3.20, 3.21)
Figura 3.18: Comando de cron en Crontab para realización de una tarea

Figura 3.19: Detalle del log de actividades y tareas ejecutadas por el comando Cron
67
Sprint: Instalación y configuración de dependencias y servicios
30/08/2013
31/08/2013
02/09/2013
Sprint Inicio Num. días
Dias de
trabajo
1 30/08/2013 3
Tareas pendientes 7 6 5 0
Horas de trabajo pendientes 18 12 6 0
PILA DEL SPRINT Horas de
Esfuerzo
Backlog ID Tarea Tipo Estado Responsable diferencia
HT-1 Instalación y configuración de servidor de Instalación Finalizado Cesar Rojas Valero 2 2 0 0 0
aplicaciones
Instalación y web en Centosde TTS
configuración
HT-2 Instalación Finalizado Cesar Rojas Valero 6 4 2 0 0
Festival Cesar Rojas Valero
Configurar DBMS MySql para permitir
HT-3 Configuración Finalizado Administrador 6 0 4 2 0
conexiones remotas
hosting
HT-4 Instalación de librerías AdobDB Php Instalación Finalizado Cesar Rojas Valero 1 0 0 1 0
como manejador
Pruebas de conexiones
de conexión remota desdea DBMS
HT-5 Pruebas Finalizado Cesar Rojas Valero 1 0 0 1 0
servidor local de aplicaciones
Configuración de Crontab para web, a
HT-6 Configuración Finalizado Cesar Rojas Valero 1 0 0 1 0
realización
Pruebas de de tareas ende
efectividad segundo plano
realización de Pruebas
HT-7 Finalizado Cesar Rojas Valero 1 0 0 1 0
tareas con Crontab
Total de horas empleados por dia 6 6 6 0
Figura 3.20: Backlog Final – Sprint 1

Figura 3.21: Burdown Final - Sprint 1

68
3.5.2 Sprint 2
El objetivo del Sprint 2 es el de crear el diseño general del sistema IVR, para lo cual se
utilizará la información recabada en el acápite de 3.3, una vez concluido el diseño
general se procederá a la programación de los requisitos identificados desarrollando el
menú principal del sistema IVR, en el cual se detallan inicialmente los servicios básicos
que son: contacto con el área de ventas, contacto en el área administrativa, contacto con
un operador y finalmente permitir la interacción con el sistema de consultas a almacén.
Para la verificación del correcto funcionamiento de las tareas presentadas anteriormente
se realizarán las pruebas necesarias las cuales serán documentadas para su presentación
en este capítulo.
A continuación se mostrarán las tareas definidas para el segundo sprint, en la figura 3.22
se muestra la agenda general con estimaciones sobre la culminación de trabajos en días y
en la figura 3.23 se muestran en detalle los trabajos a ser realizados con estimaciones en
horas.
sep. 2013
3 4 5 6 7 8 9 10 11 12 13 14
SPRINT 2 - Diseño y desarrollo de sistema

1 03/09/2013 14/09/2013 11d
IVR principal
Crear y documentar las grabaciones para el
2 03/09/2013 04/09/2013 2d
menu principal
Crear y documentar el diseño general del
3 05/09/2013 10/09/2013 5d
sistema IVR
Crear y documentar el inicio de la llamada
4 11/09/2013 11/09/2013 1d
al sistema IVR (Saludo)
5 Bienvenida, menú principal 11/09/2013 12/09/2013 2d
Crear y documentar la transferencia a un

6 13/09/2013 13/09/2013 1d
agente de ventas

7 número de interno de recepción del área 13/09/2013 13/09/2013 1d
administrativa

8 13/09/2013 13/09/2013 1d
operador de Inova Networks
Pruebas de menú principal de IVR en modo
9 13/09/2013 14/09/2013 2d
de desarrollo (simulador de aplicación)
Figura 3.22: Cronograma estimado para el Sprint 2

69
Sprint 2 inicial: Diseño y desarrollo de sistema IVR principal

2 03/09/2013 11
Tareas pendientes 8
Esfuerzo
PILA DEL SPRINT
estimado
Crear y documentar las grabaciones para el Análisis
HT-9 Pendiente Cesar Rojas 12
menú principal Diseño
Crear y documentar el diseño general del Análisis y
HT-8 Pendiente Cesar Rojas 30
sistema IVR diseño
HT-10 Crear y documentar el inicio de la llamada al
Desarrollo Pendiente Cesar Rojas 2
HU-1 sistema IVR (Saludo)
HU-2 Menú principal Pendiente Cesar Rojas
Crear y documentar el menú principal del
HT-11 Desarrollo Pendiente Cesar Rojas 8
sistema IVR
Elección de la primera opción del menú
HU-13 Pendiente Cesar Rojas
principal
HT-12
agente de ventas (Contacto directo con el área Desarrollo Pendiente Cesar Rojas 2
HU-4
de ventas)
Elección de la segunda opción del menú
principal
HT-13 número de interno de recepción del área
HU-6 administrativa.(Contacto directo con el área
administrativa)
HU-25 Elección de la cuarta opción del menú principal Pendiente Cesar Rojas
HU-26
operador de Inova Networks. (Contacto directo Desarrollo Pendiente Cesar Rojas 1
HT-14
con un operador)
Pruebas de IVR principal en modo de desarrollo
(simulador de aplicación)
Figura 3.23: Backlog inicial Sprint 2

3.5.2.2 Desarrollo
Inicialmente basados en los requisitos obtenidos, se identifican las grabaciones que
formarán parte del menú principal del sistema IVR, estas grabaciones son presentadas al
Product Owner para su posterior aprobación en un formato de texto y posteriormente ser
grabadas por una voz humana o sintetizadas por el TTS Festival.
Todas las grabaciones son presentadas a continuación, en la tabla 3.10, según el

escenario en que se necesite una determinada locución.
70
Tabla 3.10: Scripts de grabaciones para el sistema IVR
Escenario Mensaje grabado

Bienvenida Bienvenido a Inova Networks
Menú principal Si desea comunicarse con el área de ventas presione uno, Si
desea comunicarse con el área administrativa presione dos,
para consultas a almacén presione tres, si desea comunicarse
con un operador presione cero.
Petición de contraseña de usuario Ingrese su contraseña de usuario.
(Ingreso a la tercera opción del menú
principal)
Saludo a usuario valido (Buenos días/Buenas tardes/Buenas noches) (apellido paterno
del usuario) (tono robótico)
Transferencia a agente de ventas Estimado usuario, se le está transfiriendo al área de ventas,
espere un momento por favor.
Transferencia al área administrativa Estimado usuario, se le está transfiriendo al área administrativa,
espere un momento por favor
Transferencia a operador Estimado usuario, se le está transfiriendo a un operador, espere
un momento por favor
Ingreso de contraseña errónea La contraseña de usuario que ha ingresado es errónea
Petición de código de producto Ingrese el código del producto que desea consultar
Ingreso de código de producto El código de producto ingresado es erróneo
erróneo o inexistente
Identificación de producto Producto seleccionado (categoría del producto, nombre del
seleccionado producto) (Tono robótico)
Menú secundario, gestor de Marque uno para consultar stock a la fecha, dos para precios del
consultas a almacén producto, tres para una descripción general del producto, si
desea consultar un nuevo ítem marque cuatro.
Stock a la fecha Stock actual: [stock del producto según el sistema web de
control y seguimiento de almacenes] unidades (Tono robótico)
Precio de producto Precio por cantidad [precioCantidad][0] bolivianos
con[precioCantidad[1]] centavos, precio unitario
[PrecioUnitario[0]] bolivianos con [PrecioUnitario[1]] centavos
Descripción del producto [Categoría del producto] [Nombre del producto] [Referencia del
producto] (Tono robótico)
Opción elegida no valida La opción elegida no es valida
Despedida Gracias por comunicarse con Inova Networks, hasta luego.
Bienvenida a subsistema de alertas Bienvenido al sistema de alertas, por favor ingrese su código de
usuario.
Saludo a usuario (subsistema de (Buenos días/Buenas tardes/Buenas noches) (apellido paterno
alertas de desabastecimiento) del usuario)
Existencia de desabastecimiento Le informamos que existen productos en almacén con stock
mínimo
Sin desabastecimiento Actualmente las cantidades de los productos están por encima
del stock mínimo.
Usuario no autorizado Usuario no autorizado, finalizando la llamada
Menú para subsistema de alertas Presione uno para listar los id’s de los productos, presione dos
71
para listar los nombres de los productos, presione tres para que
le enviemos a su correo electrónico un informe detallado
Listado de id’s de productos con stock Los id´s de los productos con stock mínimo son: id [id del
mínimo producto i] stock [stock del producto i], id [id del producto i+1]
stock [stock del producto i+1],… , id [id del producto n] stock
[stock del producto n]
Listado de nombres de productos con Los productos con stock mínimo son: [nombre del producto i]
stock mínimo stock [stock del producto i], [nombre del producto i+1] stock
[stock del producto i+1],… , [nombre del producto n] stock
Envío de correo electrónico con Se le ha enviado a su correo electrónico un informe detallado de
informe los productos con stock mínimo.
Las grabaciones de los mensajes son realizadas desde un dispositivo telefónico en un

ambiente cerrado y libre de ruidos para maximizar la claridad del mensaje. El
dispositivo telefónico es configurado de tal manera que tenga asignado un número de
interno y este a su vez registrado en los archivos de configuración de Asterisk.
Una vez que se cuente con los elementos necesarios para la grabación, esta se la realiza
utilizando el sistema de grabación disponible en el panel de administrador de la interfaz
web de gestión de Asterisk. El panel mencionado anteriormente puede ser visto en la
figura 3.24, en el cual puede observarse que inicialmente nos indica marcar *77 en el
teléfono configurado para utilizar este sistema, una vez que se realiza esta acción, el
sistema de grabación requiere que se inicie el dictado del mensaje que se desea grabar,
concluido el dictado se finaliza la llamada y se debe de ingresar un nombre para el
archivo grabado, el cual esta temporalmente almacenado en el directorio
/var/spool/asterisk/tmp/temp.wav hasta que es guardado en el directorio
/var/lib/asterisk/sounds con el nombre elegido.
Una vez recopilados los mensajes de audio que serán parte del sistema IVR, se crea el
diseño general de dicho sistema. Para esta tarea se utilizará como base de elaboración los
diagramas de flujo desarrollados en el acápite 3.3.2.2.2.
72
Figura 3.24: Sistema de grabación de mensajes
A continuación en la figura 3.25, se muestra el flujo de llamada para el menú principal,

este flujo inicia con la llamada recibida por Asterisk, seguidamente se da la bienvenida
al cliente y se le listan las opciones de contacto con el área de ventas, contacto con el
área administrativa, contacto con un operador y contacto con el gestor automático de
consultas a almacén, el número máximo de intentos para elegir una opción válida es de
tres, en caso de exceder este limite el sistema se despide la usuario y se finaliza la
llamada. Para la opción de contacto con el gestor de consultas, se pide una contraseña
para autentificar al usuario, si se ingresa una contraseña errónea se le informa al usuario
sobre la invalidez del mismo y se le pide nuevamente la contraseña hasta tres veces, si se
excede la cantidad de intentos regresa al usuario al menú principal y se le listan
nuevamente las opciones. Una vez validado el usuario se le saluda y se le pide el código
del producto del cual se desea obtener información, el número de intentos para ingresar
un código de producto correcto es de tres, en caso de exceder ese límite se pide al
usuario que se autentifique nuevamente. Cuando el producto este validado se identificará
al producto seleccionado dictando su categoría y su nombre, seguidamente se listaran las
73
opciones de consulta que son: consulta de stock actual, consulta de precios al menor y
mayor, descripción general y opción de consulta de otro producto.
En la figura 3.26 se muestra el flujo de llamada para el subsistema de alertas ante el

desabastecimiento de productos. Este flujo puede ser iniciado de dos distintas formas,
estas son:
 Se produce una llamada automática al número telefónico o interno de la persona

autorizada para recibir esta información, al ser contestada la llamada se le pedirá
ingresar su contraseña, una vez que sea validado el usuario se le informa que existe
desabastecimiento de productos
 El usuario realiza una llamada a la línea telefónica troncal de Inova Netwoks para
efectuar las consultas respectivas, para tal caso el sistema verifica la validez del
usuario llamante pidiéndole ingresar su contraseña de usuario, esta contraseña se
contrastada con los datos registrados del usuario en la base de datos de Inova
Networks, una vez validado, el usuario escucha un mensaje de bienvenida y se le
informa que existe de desabastecimiento de productos. En caso de que el usuario no
ingrese una contraseña correcta, éste escuchará un mensaje de no autorización y se
finalizará la llamada. En caso de no existir desabastecimiento de productos, el
usuario escuchará un mensaje en el que se indique dicha situación y se finalizará la
llamada.
Seguidamente se listan las opciones de consulta respecto a los productos con stock
mínimo, las opciones son: listado de los identificadores o id‟s de los productos con el
stock actual, listado de los nombres de los productos con sus respectivos stock y
finalmente un envío de correo electrónico el cual tiene adjunto un informe de los
productos desabastecidos. El usuario tiene un máximo de tres intentos para elegir una
opción correcta, en caso de sobrepasar este limite el usuario escuchara un mensaje de
despedida y se finalizará la llamada. Concluido el dictado de la información requerida se
listan nuevamente las opciones del menú de consultas.
74
A
«Si desea comunicarse con el área de ventas

presione uno, Si desea comunicarse con el área
«Bienvenido a
administrativa presione dos, para consultas a SI
Inova networks»
almacenes presione tres, si desea comunicarse con
ANSWER
ANSWER un operador presione cero.»
Se captura el tono «La opción «Gracias por

DTMF ingresado ¿Menor a tres
elegida no es NO comunicarse con
por el usuario intentos?
valida» Inova networks»
Transferencia de No
Opcion 4
llamada a operador
¿Opción Valida?
HANGUP
HANGUP
Opción 1
Opción 2
Opción 3 Transferencia a
«Estimado usuario, se le
«Estimado gestor de consultas
está transfiriendo al
usuario, se le está a almacenes
área de ventas, espere
un momento por favor» transfiriendo al
área
administrativa,
«Ingrese su
espere un
momento por
B contraseña de
usuario»
Transferencia de favor»
llamada al área de
SI
ventas
Se capturan los
Transferencia de
tonos DTMF
llamada al área
ingresados por el
administrativa
usuario
Iconografía
(Buenos días/Buenas «La contraseña
Reproducción de un tardes/Buenas noches) ¿Usuario de usuario que ha
NO
mensaje (apellido paterno del valido? ingresado es
usuario) errónea»
Listado de opciones
en forma audible
«Ingrese el código del
producto que desea SI ¿Menor a tres
Captura de datos consultar» intentos?
Mensaje de acción NO
incorrecta Se capturan los NO
tonos DTMF
Control de acceso ingresados por el A
usuario
Consulta a base de
datos «El código de
¿Código de producto ¿Menor a tres
producto NO
ingresado es intentos?
NO B
valido?
erróneo»
SI
Op. 4 «Producto seleccionado

(categoría del producto, nombre
del producto)»
«Marque uno para consultar

stock a la fecha, dos para
precios del producto, tres
C para una descripción general SI
del producto, si desea
consultar un nuevo item
marque cuatro.»
«La opción
¿Menor a tres
¿Opción Valida? NO elegida no es
intentos?
valida»
Op. 1 Op. 2 Op. 3
«Stock actual: [stock del «[Categoría del

«Precio por cantidad
producto según el sistema producto] [Nombre
[precioCantidad][0] bolivianos
de control y seguimiento de del producto]
con[precioCantidad[1]] centavos,
almacenes] unidades» [Referencia del
precio unitario [PrecioUnitario[0]]
bolivianos con [PrecioUnitario[1]] producto]»
centavos»
Figura 3.25: Flujo de llamada para el IVR principal, subsistema de consultas a almacén
75
«Usuario no «Bienvenido al Se capturan los
autorizado, ¿Menor a tres sistema de alertas, tonos DTMF
NO SI
finalizando la intentos? por favor ingrese su ingresados por el
llamada» código de usuario.» usuario
«La contraseña de
usuario que ha ¿Usuario
ingresado es valido?
errónea »
«(Buenos días/
Buenas tardes/
Buenas noches)
(apellido paterno del
usuario)»
HANGUP
HANGUP Verifica la
existencia de
productos
desabastecidos
«Actualmente las
¿Cantidad de «Le informamos la
cantidades de los
productos con existencia de productos en
productos están SI
stock mínimo almacenes con stock
por encima del mayor a 0? mínimo»
stock mínimo. »
«Presione uno para listar los id’s

de los productos, presione dos
para listar los nombres de los
SI productos, presione tres para que A
le enviemos a su correo
«Gracias por
electrónico un informe
comunicarse con
detallado»
Inova networks,
hasta luego.»
¿Menor a tres Se captura el tono
NO
intentos? DTMF ingresado
por el usuario
Iconografía
Reproducción de un
mensaje «La opción
elegida no es NO ¿Opción Valida?
Listado de opciones valida»
en forma audible
Op. 1 Op. 3
Op. 2
Captura de datos
Mensaje de acción «Los id´s de los productos con «Se le ha enviado a
«Los productos con stock
incorrecta stock mínimo son: id [id del su correo electrónico
mínimo son: [nombre del
producto i] stock [stock del un informe detallado
producto i] stock [stock del
producto i], id [id del producto
Control de acceso producto i], [nombre del de los productos con
i+1] stock [stock del producto stock mínimo»
producto i+1] stock [stock del
i+1],… , id [id del producto n]
Consulta a base de producto i+1],… , [nombre
stock [stock del producto n]»
datos del producto n] stock [stock
del producto n]»
Envío de email
A
Figura 3.26: Flujo de llamada para el IVR del subsistema de alertas ante desabastecimiento
76
En base a los flujos de llamada descritos anteriormente y haciendo uso de las
grabaciones realizadas para la navegación en el sistema IVR, se procederá a la
programación de las tareas ya identificadas. Para la estructuración del menú principal,
inicialmente se utilizarán comandos AGI y el lenguaje PHP, la secuencia normal de
eventos será:
 Contestado de la llamada entrante con la función AGI: answer()

 Despliegue audible de las opciones del menú principal y captura de datos de entrada
con la función AGI: get_data()
 Configuración de los parámetros de espera y cantidad de datos de ingreso: según los
parámetros de la función get_data()
 Verificación de los datos recogidos por medio de los tonos DTMF y validación de
los mismos
 Enrutamiento de la llamada según la opción elegida por medio de un Switch y
derivándolo a los debidos internos.
 Para cada opción se informará al usuario la opción que haya elegido advirtiéndole
que se le está transfiriendo a un agente de ventas o a un personal administrativo o a
un operador.
La realización de pruebas de funcionamiento consiste en la monitorización de la llamada

como tal, esta puede ser realizada desde el modo consola de Asterisk, ingresando
remotamente al servidor, se ejecuta el comando:”asterisk –vdcr”, el cual permite
verificar el funcionamiento del sistema IVR en modo consola.
A continuación se mostrará el registro de sucesos al ingresar una llamada para la

realización de consultas a almacén, ver figura 3.27, en esta figura se puede observar toda
la secuencia de tareas que realiza Asterisk para entablar la comunicación, inicialmente
se obtiene la información del destino de llamada, se realiza el enrutamiento al destino de
llamada y finalmente se ejecuta el archivo PHP el cual se encargara de la lógica de
negocio.
77
Figura 3.27: Log de sucesos internos en Asterisk durante el flujo de inicio llamada
Como se vio en la anterior figura el archivo iverAgi.php es ejecutó de manera exitosa.

Para que esto suceda, se creó un contexto que permite, por medio del uso de la función
AGI() en el dialplan, ejecutar el archivo PHP anteriormente mencionado a fin de que
sirva como puente entre la línea troncal y el archivo PHP. Este contexto será el mostrado
en la figura 3.28.
La prueba realizada para verificar la funcionabilidad de la tarea anteriormente

mencionada es el de visualizar el comportamiento del mismo por medio del log de
Asterisk, a continuación en las figuras 3.29, 3.30 se pueden observar la interacción del
usuario con el sistema IVR eligiendo la opción uno del menú y la opción dos
respectivamente.
[agiinova]
exten => s,1,Answer
exten =>s,n,AGI(iverAgi.php)
exten =>s,n,Hangup
Figura 3.28: Contexto para enlace a sistema IVR principal, subsistema de consultas a almacén
78
Figura 3.29: Comportamiento respecto a la elección de la primera opción del menú principal
Figura 3.30: Comportamiento respecto a la elección de la segunda opción del menú principal

Realizada la revisión de las tareas efectuadas en el Sprint dos, de la cual no se tiene
ninguna observación sobre el desarrollo de las mismas, el tiempo estimado del sprint fue
de 62 horas en el Backlog inicial, concluyendo sin horas de trabajo a favor. En el
siguiente grafico se mostrará el Backlog final y el burndown del Sprint dos (ver Figuras
3.31, 3.32)
79
Sprint: Diseño y desarrollo de sistema IVR principal
2 03/09/2013 11
03/09/2013
04/09/2013
05/09/2013
06/09/2013
07/09/2013
09/09/2013
10/09/2013
11/09/2013
12/09/2013
13/09/2013
14/09/2013
Dias de
trabajo
Tareas pendientes 8 8 8 7 7 7 7 7 6 5 1 0
Horas de trabajo pendientes 62 56 52 44 38 33 26 20 14 10 4 0
Esfuerzo
Crear y documentar las grabaciones para

HT-9 Análisis Finalizado Cesar Rojas Valero 12 6 4 2 0 0 0 0 0 0 0 0 0
el menú principal
Crear y documentar el diseño general del
HT-8 Diseño Finalizado Cesar Rojas Valero 30 0 0 6 6 5 7 6 0 0 0 0 0
sistema IVR
HT-10 Crear y documentar el inicio de la
Desarrollo Finalizado Cesar Rojas Valero 2 0 0 0 0 0 0 0 2 0 0 0 0
HU-1 llamada al sistema IVR (Saludo)
Crear y documentar el menú principal del
HT-11 Desarrollo Finalizado Cesar Rojas Valero 8 0 0 0 0 0 0 0 4 4 0 0 0
sistema IVR
HT-12
agente de ventas (Contacto directo con el Desarrollo Finalizado Cesar Rojas Valero 2 0 0 0 0 0 0 0 0 0 2 0 0
HU-4
área de ventas)
HT-13 número de interno de recepción del área
HU-6 administrativa.( Contacto directo con el
área administrativa)
HU-26
operador de Inova Networks. (Contacto Desarrollo Finalizado Cesar Rojas Valero 1 0 0 0 0 0 0 0 0 0 1 0 0
HT-14
directo con un operador)
Pruebas de IVR principal en modo de
HT-16 Pruebas Finalizado Cesar Rojas Valero 6 0 0 0 0 0 0 0 0 0 2 4 0
desarrollo (simulador de aplicación)
Total de horas empleados por dia 6 4 8 6 5 7 6 6 4 6 4 0
Figura 3.31: Backlog final sprint 2


80
3.5.3 Sprint 3
El objetivo del sprint 3 es el de crear una plataforma de inicio de sesión de usuario, para
lo cual se utilizarán los tonos DTMF como método de ingreso de datos, conexión a base
de datos para validar los datos ingresados, TTS Festival para sintetizar una bienvenida al
usuario valido y grabaciones para los distintos escenarios durante el transcurso de la
llamada. A continuación en la figura 3.33 se mostrará la planificación del sprint 3, en la
que se enlista las tareas a ser desarrolladas, estimando su culminación en un rango de
días.
En la figura 3.34 se muestra el Backlog inicial para el sprint 3, definiendo la estimación

de culminación de las tareas en unidades de horas.
sep. 2013
16 17 18 19 20 21
SPRINT 3 – Verificación y validación de

1 ingreso de usuario a subsistema de 16/09/2013 21/09/2013 6d
consultas a almacén
Crear y documentar la transferencia al
2 subsistema de gestión de consultas a 16/09/2013 16/09/2013 1d
almacén
3 Petición de identificación 16/09/2013 16/09/2013 1d
Crear y documentar el ingreso y validación
4 16/09/2013 17/09/2013 2d
de datos de usuario
El cliente ingresa una contraseña de
5 18/09/2013 18/09/2013 1d
usuario no valida
6 Crear y documentar saludo a usuario valido 18/09/2013 18/09/2013 1d
Crear y documentar el ingreso y validación
7 18/09/2013 19/09/2013 2d
de codigo de producto a consultar
El cliente ingresa un código de producto
8 20/09/2013 20/09/2013 1d
inexistente
Crear y documentar identificación del
9 20/09/2013 20/09/2013 1d
producto según el código ingresado
Pruebas de validación de usuario en modo
10 21/09/2013 21/09/2013 1d
de desarrollo (simulador de aplicación)

81
Sprint 3 inicial: Verificación y validación de ingreso de usuario a subsistema gestor de consultas a almacén
3 16/09/2013 6
Tareas pendientes 9
PILA DEL SPRINT Esfuerzo
HU-7 Elección de la tercera opción del menú principal Pendiente Cesar Rojas
Crear y documentar la transferencia al subsistema
de gestión de consultas a almacén
HU-8 Petición de identificación Desarrollo Pendiente Cesar Rojas 1
HT-17 Crear y documentar el ingreso y validación de datos
HU-9 para usuario
El cliente ingresa una contraseña de usuario no
HU-10 Desarrollo Pendiente Cesar Rojas 1
valida
HU-11
Crear y documentar saludo a usuario valido Desarrollo Pendiente Cesar Rojas 2
HT-18
HU-12
Crear y documentar el ingreso y validación de
código de producto a consultar
HT-19
HU-14 El cliente ingresa un código de producto inexistente Desarrollo Pendiente Cesar Rojas 1
HU-15 Crear y documentar identificación del producto
HT-20 según el código ingresado
Pruebas de validación de usuario y productos en
HU-7A Pruebas Pendiente Cesar Rojas 6
modo de desarrollo (simulador de aplicación)

3.5.3.2 Desarrollo
En cuanto el usuario llamante disque la opción tres del menú principal del IVR, se
transfiere la llamada al sistema de gestión de consultas a almacén, esta tarea se realiza
por medio de la función AGI: exec("Dial", "Protocolo de señalización / #interno"), la
cual permite redireccionar el flujo de la llamada a un archivo PHP, que contiene la
lógica de negocio para la gestión de las consultas.
Una vez ingresado al sistema, el usuario escucha un mensaje de petición de

identificación, el cual es una clave única asignada por la empresa Inova Netwoks a cada
usuario autorizado. Seguidamente se capturan los datos ingresados por el usuario
utilizando la función get_data() y guardados en la variable $clave, este datos es
contrastado en la base de datos verificando la validez de dicho dato. Para este fin se
realiza la consulta mostrada en la figura 3.35 sección A, a la tabla mostrada en la figura
82
3.35 sección B, con la que se obtiene el título, que tiene el rango de valores (señor,
señora, señorita) y lastname que hace referencia al apellido paterno del usuario. Al ser
los valores de retorno de la consulta distintos de NULL, se afirma que el usuario que
ingreso la clave $clave, es un usuario valido, los datos obtenidos por la consulta servirán
para formar la cadena de saludo mostrada en la tabla 3.10 en el escenario: saludo a
usuario valido.
En caso de ser válido la clave de ingreso los resultados de la consulta serán distintos a
NULL, el usuario escuchará un mensaje de bienvenida con su apellido paterno. El
formato de este saludo es: (Buenos días/Buenas tardes/Buenas noches) (Apellido paterno
del usuario). El mensaje de bienvenida será sintetizado por el TTS Festival utilizando
la función AGI text2wav().
En caso de no ser válido la clave de ingreso los resultados de la consulta serán nulos, el
usuario escuchará un mensaje de invalidez y se le realizará la petición nuevamente, hasta
un máximo de tres veces.
//Sección A – consulta a base de datos

select titulo, lastname
from ps_employee
where claveivr = $clave
//Sección B – Tabla empleados a la cual se accede
Figura 3.35: Consulta para validación de acceso a usuario

83
Validado el usuario y verificado los permisos de acceso contra la base de datos, se hace
audible un mensaje de petición de código de producto siguiendo la misma lógica de la
petición de clave de usuario. Los datos introducidos por el usuario vía tonos DTMF son
capturados utilizando la función AGI get_data() y almacenados en la variable
$idproducto para posteriormente ser validados contra la base de datos según la consulta
mostrada en la figura 3.36 sección A. Las tablas de la base de datos involucradas en la
consulta son:
 ps_product de cual se obtiene los datos generales como el identificador del producto,
precio por menor y precio por mayor.
 ps_product_lang, de esta tabla se obtiene el nombre del producto
 ps_stock_available, proporciona la cantidad de productos existentes y registradas en
el sistema web de almacenes de Inova.
 ps_category_lang, contiene la columna categoría, la cual es utilizada en la opción de
consulta número tres.
El diagrama de entidad relación de las tablas anteriormente mencionadas puede ser visto
en la figura 3.36 sección B.
select distinct a.id_product,b.name nombreProducto, reference, price, wholesale_price,
d.quantity as cantidad,(select c.name from ps_category_lang c where c.id_category =
a.id_category_default and length(c.description)>0) categoria from ps_product a left
join ps_product_lang b on a.id_product = b.id_product left join ps_stock_available d on
d.id_product = a.id_product where a.id_product = '".$idproducto."' and
length(b.description)>0
//Sección B – Tablas involucradas en la consulta
Figura 3.36: Consulta para obtención de datos respecto a los productos en almacén.
84
En caso de ser válido el código de producto, se reproduce un audio en el que se
identifica al producto seleccionado y seguidamente de listan las opciones del menú de
consulta en forma audible.
Concluida la consulta se lista nuevamente el menú de IVR del subsistema de consultas a

almacén para permitir consultar la información de algún otro producto.
Las pruebas de funcionalidad y correcto funcionamiento de las tareas planteadas en el

sprint 3, son demostrados en el modo consola de Asterisk, viendo de esta forma el
comportamiento durante el transcurso de una llamada que interactúa con el sistema de
gestión de consultas a almacén.
En la figura 3.37, se puede ver el despliegue del mensaje audible en formato .wav, el
cual le indica al usuario ingresar su código de identificación y también el despliegue del
mensaje audible de clave invalida.
En la figura 3.38 puede observarse como, una vez ingresado una clave de usuario valida,
se inicia el mensaje de petición de código de producto y en caso de haber ingresado un
código de producto no valido como se despliega el mensaje de error.
En la figura 3.39 se puede apreciar las rutas de los archivos de audio temporal creados
por el TTS Festival para emitir el mensaje de saludo a un usuario validado y la
identificación de un producto seleccionado respectivamente. Estos archivos son
ejecutados y reproducidos a fin de que el usuario pueda oír los datos obtenidos a raíz de
la validación del usuario y la validación del producto.
Figura 3.37: Mensaje de petición de ingreso de clave y mensaje de clave invalida

85
Figura 3.38: Mensaje de petición de ingreso de código de producto y mensaje de código invalido
Figura 3.39: Mensaje de petición de ingreso de código de producto y mensaje de código valido

El tiempo estimado del sprint fue de 33 horas de trabajo en el Backlog inicial,
concluyendo sin horas de trabajo a favor.
En el siguiente grafico se mostrará el Backlog final y el burndown del Sprint tres (ver
figuras 3.40, 3.41).
86
Sprint: Verificación y validación de ingreso de usuario a modulo gestor de consultas a almacén
Dias de trabajo
16/09/2013
17/09/2013
18/09/2013
19/09/2013
20/09/2013
21/09/2013
3 16/09/2013 6
Tareas pendientes 8 6 5 3 2 1 0
Horas de trabajo pendientes 33 27 22 16 11 6 0
Esfuerzo
HT-15 sistema de gestión de consultas a Diseño Finalizado Cesar Rojas Valero 2 2 0 0 0 0 0 0
almacén
HU-8 Petición de identificación Desarrollo Finalizado Cesar Rojas Valero 1 1 0 0 0 0 0 0
HT-17 Crear y documentar el ingreso y

Desarrollo Finalizado Cesar Rojas Valero 8 3 5 0 0 0 0 0
HU-9 validación de datos para usuario
El cliente ingresa una contraseña de
HU-10 Desarrollo Finalizado Cesar Rojas Valero 1 0 0 1 0 0 0 0
usuario no valida
HU-11 Crear y documentar saludo a usuario
HT-18 valido
HU-12 Crear y documentar el ingreso y
HU-13 validación de código de producto a Desarrollo Finalizado Cesar Rojas Valero 8 0 0 3 5 0 0 0
HT-19 consultar
El cliente ingresa un código de producto
HU-14 Desarrollo Finalizado Cesar Rojas Valero 1 0 0 0 0 1 0 0
inexistente
HU-15 Crear y documentar identificación del
HT-20 producto según el codigo ingresado
Pruebas de validación de usuario y
HU-7A productos en modo de desarrollo Pruebas Finalizado Cesar Rojas Valero 6 0 0 0 0 0 6 0
(simulador de aplicación)
Total de horas empleados por dia 6 5 6 5 5 6 0


87
3.5.4 Sprint 4
El objetivo del Sprint 4 es desarrollar la plataforma que permita la interactividad entre el
usuario validado y el subsistema de consultas a almacén, permitiéndole la navegabilidad
por las opciones del menú utilizando tonos DTMF. Una vez elegida una opción de
consulta, el usuario escuchará la información requerida, la cual será extraída desde la
base de datos remota y normalizada para su correcta sintetización por el TTS Festival.
En la figura 3.42, puede observarse el cronograma de tareas definidas, las cuales tienen
una estimación de tiempo en ser concluidas. En la figura 3.43 puede observarse el
Backlog inicial para el sprint 4, en dicho grafico puede evidenciarse la cantidad de
horas estimadas para cada elemento del sprint, así como también un listado de las tareas
a ser realizadas.
sep. 2013
23 24 25 26 27
SPRINT 4 - Diseño de subsistema de consultas a

1 23/09/2013 27/09/2013 5d
almacén
2 Menú secundario (menú IVR para almacenes) 23/09/2013 27/09/2013 5d
3 menú secundario (gestor de consultas a 23/09/2013 23/09/2013 1d
almacén)
Crear y documentar el menú secundario del
4 24/09/2013 24/09/2013 1d
sistema IVR (consultas a almacén)
Crear y documentar la consulta a base de datos
5 25/09/2013 26/09/2013 2d
respecto al producto seleccionado en HT-19
6 25/09/2013 25/09/2013 1d
secundario
7 Dictado del stock actual en almacenes 25/09/2013 25/09/2013 1d
8 25/09/2013 25/09/2013 1d
secundario
Dictado del precio por mayor y menor del
9 25/09/2013 25/09/2013 1d
producto
Elección de la tercera opción del menú
10 26/09/2013 26/09/2013 1d
secundario
11 Dictado de la información general del producto 26/09/2013 26/09/2013 1d
Elección de la cuarta opción del menú
12 26/09/2013 26/09/2013 1d
secundario (retorno a menu secundario)
El cliente digita una opción inexistente en el
13 26/09/2013 26/09/2013 1d
menú secundario
Pruebas de IVR secundario en modo de
14 27/09/2013 27/09/2013 1d

88
Sprint 4 inicial: Desarrollo del subsistema de consultas a almacén

4 23/09/2013 5
Tareas pendientes 8
Esfuerzo
PILA DEL SPRINT
estimado
Menú secundario (menú IVR para consultas a
almacén)
HT-21 menú secundario (gestor de consultas a Desarrollo Pendiente Cesar Rojas 5
almacén)
Crear y documentar el menú secundario del
sistema IVR (consultas a almacén)
HT-23 Crear y documentar la consulta a base de datos
Pendiente Cesar Rojas
HU-9 respecto al producto seleccionado en HT-19
secundario
HU-18 Dictado del stock actual en almacén Desarrollo Pendiente Cesar Rojas 3
secundario
producto
Elección de la tercera opción del menú
HU-21 Desarrollo Pendiente Cesar Rojas
secundario
HU-22 Dictado de la información general del producto Desarrollo Pendiente Cesar Rojas 2
secundario (retorno a menú secundario)
menú secundario

3.5.4.2 Desarrollo
El desarrollo del subsistema de consultas el cual gestiona la petición de información de
productos del almacén, inicia con la grabación de los mensajes definidos en el sprint 2
con el mismo sistema mencionado en dicho sprint, estos mensajes tienen la finalidad de
orientar al usuario durante el transcurso de la llamada respecto a la navegabilidad de las
opciones, también el de informarle sobre el ingreso de datos validos o erróneos.
Una vez recopiladas las grabaciones necesarias se inicia con el desarrollo del menú
secundario del sistema IVR para el subsistema de gestión de consultas a almacén, para
89
este fin se utiliza como modelo de desarrollo los diagramas diseñados en el sprint 2,
también son utilizados las definiciones de las funciones descritas en el acápite
3.3.2.2.2.1.
A continuación en la figura 3.44 se muestra el flujo de la llamada el cual se programó a

fin de cumplir con el objetivo del sprint 4. En esta figura, se puede observar las distintas
opciones de consulta a la base de datos (stock actual, precios, descripción del producto),
también puede verse la validación de las opciones ingresadas y las decisiones que son
tomadas a partir de ciertos escenarios dados.
La lógica de negocio para validar una opción introducida por medio de tonos DTMF, se
basa inicialmente con la petición de ingreso de dicha opción, una vez ingresada, se
captura el tono DTMF y verifica la validez del dato ingresado por medio de una
sentencia switch, siendo que la salida por default indicara el ingreso de una opción no
valida.
Figura 3.44: Flujo de llamada - Subsistema de consultas a almacén

90
Respecto al desarrollo de las opciones, que permiten obtener información de un producto
en almacén, se optó por crear una consulta global, que incluya la información necesaria
para cada una de las opciones, a fin de minimizar tiempo de respuesta al usuario. La
primordial ventaja de realizar esta acción radica en que una vez obtenido los resultados
de la consulta, estos pueden ser almacenados en una variable en la memoria y de esta
forma acceder de forma más rápida a los demás datos, sin necesidad de consultar
nuevamente la base de datos remota.
Las columnas de las que dispone la consulta pueden ser vistas en la figura 3.45, con
estas seis columnas se pueden proveer la información necesaria para las opciones de
consultas disponibles en el menú del subsistema de consultas a almacén. También se
puede apreciar en dicha figura que el tiempo para el procesamiento de la consulta
general es de 0.156 segundos, asegurando de esta forma que el tiempo de respuesta al
usuario será considerablemente rápido.
En caso de elegirse la opción número uno, la cual es el de consultar el stock actual de un

determinado producto, primeramente se normalizará los datos obtenidos por la consulta
a base de datos, puntualmente el valor de la columna con el nombre cantidad,
seguidamente se concatenara la información obtenida en base al formato mostrado en la
figura 3.46 sección A.
En caso de elegirse la opción número dos, el usuario recibirá información audible del
precio unitario y precio por mayor del producto seleccionado, el formato de la
información entregada puede ser visto en la figura 3.46 sección B.
En caso de elegirse la opción número tres, el usuario escuchará la descripción general

del producto, el formato de la información entregada puede ser visto en la figura 3.46
sección C.
91
Figura 3.45: Resultados de una consulta a base de datos remota
//Sección A
// "stock actual" + $cantidad + "unidades"
//Sección B
/*
"precio por cantidad, " +
$parteEnteraDelPrecioPorMayor +
"bolivianos con " +
$parteDecimalDelPrecioPorMayor +
"centavos, precio unitario " +
$parteEnteraDelPrecioPorMenor +
"bolivianos con " +
$parteDecimalDelPrecioPorMenor +
"centavos"
*/
//Sección C
// $categoria + $nombreProducto + $reference;
Figura 3.46: Formato de cadenas a ser sintetizadas por festival

En caso de que el usuario digite una opción fuera del rango de opciones validas (del uno
al cuatro), este escuchará un mensaje en el que se le informe sobre el error cometido, el
número de intentos máximo para el ingreso de una opción válida es de tres, en caso de
exceder este limite el sistema emitirá un mensaje de despedida y se concluirá la llamada.
Para poder verificar la funcionabilidad del flujo de la llamada descrito en la figura 3.44
se visualizará el comportamiento del log de Asterisk, a continuación en la figura 3.47 se
puede observar la interacción del usuario con el subsistema de consultas a almacén,
eligiendo la opción uno del menú de consultas.
Las opciones dos y tres (consulta de precios y descripción general de producto

respectivamente) tiene el mismo comportamiento que la opción número uno del menú
de consultas, puesto que ambos también concatenan el resultado obtenido y también son
sintetizadas dichas cadenas tal como se muestra en la figura anterior.
92
Archivos temporales creados a partir de la sintetización de las cadenas descritas en la figura 3.46
Dictado de las opciones del menú de consultas a almacén
Figura 3.47 Sintetización de información referente a stock actual y dictado de opciones de consulta
El funcionamiento correcto de la opción cuatro el cual permite consultar la información

de algún otro producto puede ser visto en la figura 3.48, en la cual se muestra la
secuencia de tareas realizadas para lograr probar dicha opción, pidiendo inicialmente el
código de producto de cual se desea obtener información, seguidamente se marca la
opción cuatro y como se puede ver en la figura, se realiza nuevamente la petición de un
código de producto.

Se concluyó las tareas programadas del Sprint cuatro sin evidenciar ninguna observación
sobre el desarrollo de las mismas. El tiempo estimado del sprint fue de 27 horas de
trabajo en el Backlog inicial, concluyendo sin horas de trabajo a favor.
En el siguiente grafico se mostrará el Backlog final y el burndown del Sprint tres (ver
Figuras 3.49, 3.50).
Figura 3.48: Verificación de la funcionalidad de la opción cuatro del menú de consultas

93
Sprint 4:Desarrollo del subsistema de consultas a almacén
Dias de trabajo
23/09/2013
24/09/2013
25/09/2013
26/09/2013
27/09/2013
4 23/09/2013 5
Tareas pendientes 8 7 6 4 1 0
Horas de trabajo pendientes 27 22 16 11 6 0
Esfuerzo
HT-21 el menú secundario (gestor de consultas Desarrollo Finalizado Cesar Rojas Valero 5 5 0 0 0 0 0
a almacén)
Crear y documentar el menú secundario
HT-22 Desarrollo Finalizado Cesar Rojas Valero 6 0 6 0 0 0 0
del sistema IVR (consulta a almacén)
HU-18 Dictado del stock actual en almacén Desarrollo Finalizado Cesar Rojas Valero 3 0 0 3 0 0 0
HU-20 Desarrollo Finalizado Cesar Rojas Valero 2 0 0 2 0 0 0
producto
Dictado de la información general del
producto
secundario (retorno a menú secundario)
El cliente digita una opción inexistente
en el menú secundario
HT-24 Pruebas Finalizado Cesar Rojas Valero 6 0 0 0 0 6 0
Total de horas empleados por dia 5 6 5 5 6 0

Figura 3.50: Burdown Final – Sprint4

94
3.5.5 Sprint 5
El objetivo del Sprint 5 es el de desarrollar el subsistema de alertas tempranas ante
desabastecimiento de los productos en almacén, el cual automáticamente realiza una
llamada telefónica al usuario autorizado a conocer dicha información. Así también el
usuario podrá acceder a la información de desabastecimiento llamando al número
telefónico que está configurado como línea troncal en Inova Networks, por medio del
cual el usuario podrá conocer en detalle los productos que tengan un stock mínimo. Las
opciones permitidas para conocer qué productos se encuentran desabastecidos son las
siguientes: listado de los identificadores de los productos, listado de los nombres de los
productos, envío de correo electrónico con el informe detallado de los productos. Para
tal fin se utilizará la información recopilada hasta el momento, tales como las fichas
historias de usuario, fichas técnicas y mensajes para ser gravados acordes a los
escenarios del subsistema de alertas. En la figura 3.51, puede observarse el cronograma
de tareas definidas para el logro del objetivo del sprint 5.
oct. 2013
30 1 2 3 4 5 6 7 8 9 10
SPRINT 5 - Diseño y desarrollo de

1 subsistema de alerta automática ante 30/09/2013 10/10/2013 10d
desabastecimiento
2 menu de IVR de alertas tempranas (gestor 30/09/2013 30/09/2013 1d
de alertas ante desabastecimiento)
Crear y documentar la validación y
3 01/10/2013 01/10/2013 1d
verificación de productos desabastecidos
Crear y documentar llamada
4 02/10/2013 03/10/2013 2d
automática y saludo a usuario valido
Crear y documentar el menú de alertas
5 04/10/2013 04/10/2013 1d
tempranas
Crear y documentar la consulta a base de
6 datos respecto a los productos 05/10/2013 05/10/2013 1d
desabastecidos
Listado de los identificadores de productos
7 07/10/2013 07/10/2013 1d
desabastecidos
Listado de los nombres de productos
8 07/10/2013 07/10/2013 1d
desabastecidos
Crear y documentar el envió de informe de
9 productos desabastecidos a un correo 08/10/2013 09/10/2013 2d
electrónico
El cliente digita una opción inexistente en
10 09/10/2013 09/10/2013 1d
el menú de stock mínimo
Pruebas del menú del subsistema de
11 10/10/2013 10/10/2013 1d
alertas

95
En base al cronograma de tareas mostrado anteriormente, las fichas de historias de
usuario y fichas técnicas se elabora el Backlog inicial para el sprint 5 definiendo las
horas que serán invertidas en el desarrollo de cada elemento del sprint, el Backlog puede
ser visto en la figura 3.52.
Sprint 5 inicial: Diseño y desarrollo de subsistema de alerta automática ante desabastecimiento

5 30/09/2013 11
Tareas pendientes 11
Esfuerzo
PILA DEL SPRINT
estimado
HT-25 menú de IVR de alertas tempranas (gestor de Desarrollo Pendiente Cesar Rojas 6
alertas ante desabastecimiento)
HU-16 Verificación de stock mínimo Pendiente Cesar Rojas
Crear y documentar la validación y verificación
de productos desabastecidos
HU-29 Alerta automática de stock mínimo
Pendiente Cesar Rojas
HU-30 Usuario contesta la llamada (saludo al usuario)
HT-29 Crear y documentar llamada automática y
HT-27 saludo a usuario valido
HU-31 Menú IVR de stock mínimo Pendiente Cesar Rojas
tempranas
Crear y documentar la consulta a base de datos
respecto a los productos desabastecidos
Elección de la primera opción del menú de
stock mínimo
Listado de los identificadores de productos
desabastecidos
Elección de la segunda opción del menú de
stock mínimo
desabastecidos
Elección de la tercera opción del menú de stock
mínimo
Crear y documentar envió de informe de
HT-32 productos desabastecidos a un correo Desarrollo Pendiente Cesar Rojas 8
electrónico
menú de stock mínimo
HT-33 Pruebas del subsistema de alertas tempranas Pruebas Pendiente Cesar Rojas 6

96
3.5.5.2 Desarrollo
El subsistema de alertas se desarrolla siguiendo el flujo de llamada definido en el sprint
2, el cual puede ser visto en la figura 3,26. Inicialmente se realiza las grabaciones
audibles de los mensajes definidos en el sprint 2 utilizando el método de grabación
descrito en dicho sprint.
Una vez establecidas las grabaciones necesarias, se creó un archivo PHP con el nombre
llamada.php, dentro de este se tiene un script que permite verificar las cantidades de
productos existentes en almacén según el sistema web de control y gestión de almacenes
de Inova Networks, para tal fin fue necesario realizar una conexión remota al servidor de
base de datos de dicho sistema, seguidamente se realiza una consulta respecto al stock
actual de todos los productos, se filtra los productos con un stock por debajo del mínimo
permitido (este parámetro de desabastecimiento está definido por las normas internas de
la empresa, ver anexo E) y se almacena el conteo de los productos coincidentes con el
filtro. La consulta para lograr lo mencionado anteriormente puede ser vista en la figura
3.53 sección A y en la sección B se puede observar las tablas involucradas en la
consulta.

select a.id_product from ps_product a left join ps_product_lang b on a.id_product =
b.id_product left join ps_stock_available d on d.id_product = a.id_product where
d.quantity < 3 and numllamada<3
Figura 3.53: Consulta para conteo de productos desabastecidos.

97
En caso de que el conteo de productos desabastecidos sea mayor o igual a uno, el
sistema recupera los datos del usuario autorizado a recibir la alerta por medio de la
consulta mostrada en la figura 3.54, la tabla desde la cual se extraen los datos puede ser
vista en la figura 3.35 sección B. Seguidamente se realiza una llamada automática al
número de usuario registrado. Para este fin se utilizó la funcionalidad outgoing de
Asterisk, creando dinámicamente un archivo temporal con la extensión .call y guardada
en la dirección /var/spool/asterisk/outgoing para que sea ejecutada automáticamente.
El contenido del archivo temporal permite entablar una comunicación entre una línea
troncal gestionada por Asterisk y un número externo registrado en la base de datos, este
último vendría a ser el número del usuario autorizado. La línea troncal está asociada a un
sistema IVR con el cual se permite al usuario navegar por las opciones de consulta de
productos desabastecidos, esta asociación es lograda por la configuración de la línea
troncal y registro de la misma en un contexto que permita redirigir el flujo de la llamada
a un archivo PHP que contendrá la lógica de negocios, en la figura 3.55 puede verse el
contexto mencionado, la ejecución de la llamada automática puede ser vista en la figura
3.56, mostrando en la sección A el registro de actividades del demonio al ejecutar el
archivo PHP la cual realizará la llamada automática y en la sección B el log de
actividades de Asterisk al entablarse la comunicación, verificando de esta forma el
correcto funcionamiento.
select titulo,lastname,allamar
from ps_employee
where reporteAlmacen = 's'
Figura 3.54: Consulta para obtención de datos de usuario autorizado.
[autoAlmacen]
exten => s,1,Answer
exten =>s,n,AGI(autoAlmacenAgi.php)
exten =>s,n,Hangup
Figura 3.55: Contexto para enlace a sistema IVR – subsistema de alertas
98
En caso de que el número de productos desabastecidos sea menor a uno, se informa al
usuario que las cantidades de productos actualmente se encuentran con un stock por
encima del mínimo permitido, esto es realizado por medio de la reproducción de un
mensaje grabado y la utilización de la función AGI en PHP: exec();
Se creó también un script dentro del archivo almacenAgi.php, el cual valida a un usuario
que llame al subsistema de alertas, siendo esta una opción para que el usuario acceda a la
información de desabastecimiento el momento en que este lo requiera, para esta tarea se
capturó la contraseña ingresada por el usuario por medio del comando AGI: get_data (),
almacenándolo en una variable y seguidamente realizando una consulta a la base de
datos para verificar la validez de la contraseña, los usuarios autorizados son definidos
por la empresa Inova Networks los cuales están registrados en la tabla de usuario en la
base de datos del sistema web de control y gestión de almacenes.
En caso de ser válido el usuario este escuchará un mensaje un saludo sintetizado con el
formato: (Buenos días/Buenas tardes/Buenas noches) + (apellido paterno del usuario),
esta sintetización es lograda por el uso de la función text2wav(). Si el usuario no es
válido este escuchará un mensaje de no autorización el cual fue anteriormente grabado,
la reproducción de dicho mensaje se la realiza utilizando la función exec().
//Sección A
//Sección B
Figura 3.56: Registro de actividades durante la llamada automática

99
Una vez que se entable la comunicación con el usuario autorizado, se reproduce el
listado de opciones para conocer los productos que se encuentran desabastecidos, se
espera a que el usuario digite una opción, la opción elegida es evaluada y validada, en
caso de que el usuario ingrese una opción no valida se reproduce un mensaje que le
indique el error cometido y se enlista nuevamente las opciones de consulta de productos
desabastecidos. En la figura 3.57 puede observarse el registro de los sucesos
anteriormente descritos.
Se optó por crear una consulta general que permita obtener la información necesaria para
las opciones uno y dos del menú de alertas, esta consulta devuelve los resultados
mostrados en la figura 3.58, lo cuales serán utilizados para ser sintetizados y expuestos
según sea la elección de usuario, estos datos son obtenidos en base a la consulta
mostrada en la figura 3.59 sección A y en la sección B de la misma figura puede verse
las tablas involucradas en dicha consulta.
Figura 3.57: Registro del flujo de llamada inicial para el subsistema de alertas ante desabastecimiento
Figura 3.58: Resultados de consulta a base de datos remota

100
select a.id_product, b.name nombreProducto,reference, price, wholesale_price, d.quantity
as cantidad, (select c.name from ps_category_lang c where c.id_category =
a.id_category_default and length(c.description)>0) categoria, numllamada from
ps_product a left join ps_product_lang b on a.id_product = b.id_product left join
ps_stock_available d on d.id_product = a.id_product where d.quantity < 3 and
length(b.description)>0 order by categoria
Figura 3.59: Consulta para obtención de datos de productos desabastecidos.

La primera opción del menú de alertas dicta los identificadores de los productos con
stock mínimo seguido de la cantidad existente actualmente registrada en la base de
datos, el formato que seguirá la cadena a ser sintetizada por Festival puede ser visto en la
figura 3.60 sección A.
La segunda opción del menú de alerta dicta los nombres de los productos seguidos del
stock registrado hasta el momento de la llamada, el formato de la cadena a ser
sintetizada por Festival puede ser visto en la figura 3.60 sección B.
La tercera opción del menú de alertas envía un correo electrónico, en el cual se adjunta
un informe detallado de los productos desabastecidos, para tal fin se crea una cuenta de
correo como remitente del informe, el correo al cual es enviado dicha información será
el que este asociado al usuario autorizado. En la figura 3.61 se puede ver el éxito del
envío de correo electrónico, en la sección A de dicha figura se observa el registro de
101
actividades del log de Asterisk evidenciando la reproducción del mensaje de envío del
correo electrónico, en la sección B se puede ver la captura de pantalla de la bandeja de
entra de correos electrónicos con el correo recibido.
//Sección A
/*
"id " + $idProducto[1] + " stock "+ $stockProducto[1]+ ", "+
"id " + $idProducto[2] + " stock "+ $stockProducto[2]+ ", "+
...
"id " + $idProducto[i] + " stock "+ $stockProducto[i]
*/
//Sección B
/*
"id " + $nombreProducto[1] + " stock "+ $stockProducto[1]+ ", "+
"id " + $nombreProducto[2] + " stock "+ $stockProducto[2]+ ", "+
...
"id " + $nombreProducto[i] + " stock "+ $stockProducto[i]
*/
Figura 3.60: Formato de cadenas a ser sintetizadas por festival

//Sección A
//Sección B
Captura de correo en bandeja de entrada
Figura 3.61: Comprobantes de envío de correo electrónico

102
Realizada la revisión de las tareas efectuadas en el Sprint 5 se verifica que no se tiene
ninguna observación sobre el desarrollo de las mismas, el tiempo estimado del sprint fue
de 58 horas en el Backlog inicial. En el siguiente grafico se mostrará el Backlog final y
el burndown del Sprint 5 (ver Figuras 3.62, 3.63)
Sprint 5:Diseño y desarrollo de subsistema de alerta automática ante desabastecimientos
Dias de trabajo
30/09/2013
01/10/2013
02/10/2013
03/10/2013
04/10/2013
05/10/2013
07/10/2013
08/10/2013
09/10/2013
10/10/2013
11/10/2013
11 23/09/2013 11
Tareas pendientes 11 10 9 9 9 7 6 5 3 2 1 0
Horas de trabajo pendientes 58 52 46 40 36 34 28 22 16 10 6 0
Esfuerzo
el menú de IVR de alertas tempranas
(gestor de alertas ante
desabastecimientos)
HT-28 verificación de productos Desarrollo Finalizado Cesar Rojas Valero 6 0 6 0 0 0 0 0 0 0 0 0 0
desabastecidos
HT-29 Crear y documentar llamada automática
HT-27 y saludo a usuario valido
tempranas
Crear y documentar la consulta a base de
HT-31 datos respecto a los productos Desarrollo Finalizado Cesar Rojas Valero 6 0 0 0 0 0 0 6 0 0 0 0 0
desabastecidos
Listado de los identificadores de
HU-33 Desarrollo Finalizado Cesar Rojas Valero 3 0 0 0 0 0 0 0 3 0 0 0 0
productos desabastecidos
desabastecidos
Crear y documentar envió de informe de
HU-32 productos desabastecidos a un correo Desarrollo Finalizado Cesar Rojas Valero 8 0 0 0 0 0 0 0 0 6 2 0 0
electrónico
El cliente digita una opción inexistente
en el menú de stock mínimo
HT-30
Pruebas del subsistema de alertas Pruebas Finalizado Cesar Rojas Valero 6 0 0 0 0 0 0 0 0 0 0 6 0
HT-33
Total de horas empleados por dia 6 6 6 4 2 6 6 6 6 4 6 0
Figura 3.62: Backlog final Sprint 5

103
Figura 3.63: Burdown Final – Sprint 5
3.6 Pruebas, verificación y validación de resultados

Con la finalidad de evaluar la información y el funcionamiento del subsistema de
consultas a almacén y subsistema de alertas ante desabastecimientos de productos se
utilizó como herramienta de recolección y validación de resultados un formulario de
evaluación para cada subsistema. En dicho formulario se identifican los siguientes
criterios de evaluación:
La seguridad del sistema en cuanto a la accesibilidad de los servicios de consulta de

datos de productos en el subsistema de consultas a almacén y el subsistema de alertas
ante desabastecimiento, están restringidas por el ingreso de la contraseña de usuario.
En base a los resultados obtenidos por el formulario de evaluación se constató que un

ocho por ciento de los usuarios requirió dos intentos de ingreso de contraseña, para ser
validados correctamente y así lograr acceder a la información de los productos, en
cambio un cuatro por ciento de los usuarios requirió de tres intentos, el ochenta y ocho
por ciento de los usuarios requirió de solo un intento de ingreso de contraseña para ser
validados correctamente. La grafica estadística de lo anteriormente expuesto puede ser
vista en la figura 3.64.
104
4% 0%
8%
1er intento
2do intento
3er intento
88%
4to intento
Figura 3.64: Intentos de validación de usuario para acceso a los subsistemas de consultas y alertas
En cuanto a las llamadas recibidas, se advirtió el rechazo de llamadas entrantes que

ingresaron contraseñas de usuario no registradas como autorizadas para conocer
información de los productos. El log de actividades y el registro del rechazo de una
llamada durante el intento de acceso al subsistema de alertas ante desabastecimiento con
contraseñas inválidas, puede ser visto en la figura 3.65.
Figura 3.65: Log de actividades durante rechazo de llamadas

105
Las zonas de riesgo identificadas, descritas a continuación en la tabla 3.11, representan
los lugares físicos en los que no se logró concretar una interacción con el sistema IVR,
siendo la principal razón la baja intensidad de señal celular ofrecida por los operadores
de telefonía en dichas zonas, este aspecto pudo evidenciarse en base al procesamiento de
datos proporcionados por los formularios de evaluación de los cuales se tomaron en
cuenta los casos en que la causa de incomunicación con el sistema IVR fueron: sin señal
de dispositivo y fuera de cobertura.
En base a los resultados emitidos por el formulario de evaluación se constató que el diez
por ciento de las llamadas realizadas evidencio la indisponibilidad del sistema IVR, ver
figura 3.66, de este total el sesenta y dos por ciento fue debido a la inexistencia de señal
telefónica, el veinticinco por ciento debido a que la línea troncal de la empresa se
encontraba ocupado y el trece por ciento por la falta de cobertura de la red celular del
operador. La gráfica estadística de lo mencionado anteriormente se puede ver en la
figura 3.67.
Tabla 3.11: Zonas sin acceso óptimo a una red de telefonía

Dirección Característica del lugar Operador Causa

Zona Kupini Quebradas Entel Sin señal en el dispositivo
Carretera a Oruro Planicie Entel Fuera de cobertura
Zona Central, calle Subterráneo Entel Sin señal en el dispositivo
Comercio, edificio Ismar
sótano 1
Zona Ciudadela Quebradas Tigo Sin cobertura
Zona Vino Tinto Quebradas Tigo Sin señal en el dispositivo
Zona plan autopista Hoyada Tigo Sin cobertura
Zona San Isidro alto Quebrada Viva Sin señal
Provincia Larecaja – Yungas Viva Sin cobertura
población Santa Rosa
106
10%
Disponible
No Disponible
90%
Figura 3.66: Disponibilidad del sistema IVR durante la evaluación

0% Sin señal
13%
Linea ocupada
25%
62%
Sin cobertura
Linea de destino sin

servicio
Figura 3.67: Causas para la no accesibilidad al sistema IVR

Se pudo evidenciar que el cien por ciento de las personas encuestadas, que contaban con
una señal celular aceptable, lograron acceder e interactuar con el sistema IVR y realizar
consultas respecto a la información de los productos en almacén de forma exitosa, sin
presentar ninguna dificultad respecto a la navegabilidad de las opciones en el menú
primario y secundario del subsistema de consultas a almacén. Sin embargo del total de
las pruebas realizadas durante la evaluación, un dieciséis por ciento de los usuarios no
lograron interactuar con el sistema IVR (ver figura 3.68) debido a las razones expuestas
en la figura 3.67, pero el ochenta y cuatro por ciento de los usuarios si lograron obtener
información de los productos.
107
16%
Éxito
84% Fallido
Figura 3.68: Éxito de obtención de información de los productos en almacén

Se verificó que el nivel de claridad auditiva durante la entrega de la información de

producto, está condicionado por la calidad de la señal entregada por el operador de
telefonía, por lo cual en las zonas de riesgo identificadas párrafos arriba la claridad de
los datos entregado es baja o nula, debido a la producción de interferencias durante la
interacción con el sistema y el usuario. Basados en los resultados de la evaluación del
producto, el nivel de claridad auditiva entre los rangos: excelente, muy bueno y bueno,
suman el noventa y seis por ciento, este porcentaje representa a los usuarios que
escucharon con claridad y de forma fluida las opciones y respuestas entregadas por el
sistema, el restante cuatro por ciento, ver figura 3.69, está conformado por aquellos
usuario que se encontraban dentro de las zonas de riesgo identificadas en la tabla 3.11,
por tal razón no lograron interactuar con el sistema IVR de manera óptima.
0% 4%
Exelente
22% 30%
Muy buena
Buena
44% Regular
Mala
Figura 3.69: Claridad de la voz emitida por el sistema IVR para la entrega de información de productos
108
El criterio de evaluación de la velocidad de respuesta, está condicionado por la
velocidad en la que se obtienen los datos por medio de las consultas a la base de datos
externa, las pruebas de velocidad realizadas durante el desarrollo del sprint 4, vistos en
el acápite 3.5.4 y 3.5.5 indican que dichas consultas emiten las respuestas en un tiempo
menor a dos segundos, gracias a esta alta velocidad de respuesta, durante la evaluación
del desempeño de los subsistemas se observó que el inicio para las interacciones entre
el usuario y los subsistemas, duró en promedio 2.5 segundos como máximo.
La precisión de los datos se evaluó verificando si la información proporcionada por el

sistema respecto a los datos de los productos en almacén, coinciden con los datos
registrados en la base de datos del sistema web de almacenes. Así también se verificó si
los productos enlistados como desabastecidos coinciden con aquellos que tienen
registrado un stock mínimo en la base de datos del sistema web de almacenes. En base a
los resultados obtenidos durante la evaluación se evidenció que todas las respuestas
emitidas por el sistema IVR coinciden completamente con los registros de la base de
datos en el momento en que son entregados, tanto en la utilización del subsistema de
consultas a almacén como en el subsistema de alertas ante desabastecimiento. Es por lo
cual que el nivel de reutilización del sistema para la obtención de información de los
productos es alta, siendo que el noventa y seis por ciento de los usuarios que
interactuaron con el sistema indican que utilizarían nuevamente el servicio, ver figura
3.70.
Si
0% 4%
No
Ocasionalmente
96%
Figura 3.70: Reutilización del sistema IVR

109
4 CONCLUSIONES Y RECOMENDACIONES
4.1 Conclusiones
En el presente trabajo de tesis se realizó el desarrollo e implementación de un sistema
interactivo de respuesta de voz o IVR, con el que se logró posibilitar la obtención de
información de un sistema web a través de las redes de telefonía como alternativa al
acceso por medio del internet.
En el caso concreto de la empresa Innova Networks y con base a los resultados

obtenidos en los distintos casos de estudio realizados, se concluye que el sistema IVR
satisface las necesidades de obtención de información remota y por consiguiente se
afirma que se logró el cumplimiento de los objetivos específicos y el objetivo general
del presente trabajo de tesis. A continuación se describen los detalles de estos logros:
 La metodología y la norma utilizadas permitieron definir de forma correcta los

requisitos del usuario y plantear un diseño consistente de la solución, con los cuales
se logró crear el sistema IVR cubriendo los requisitos recopilados, esta afirmación se
ve reflejada en el alto porcentaje obtenido en el formulario de evaluación respecto a
la reutilización del sistema, así como también los altos valores cuantitativos, en
relación a la fácil navegabilidad y la claridad de la información y listado de opciones
reproducidas durante la interacción con el usuario.
 Las tecnologías utilizadas como el sintetizador de voz Festival, la interfaz pasarela
de Asterisk AGI, la conexión remota a base de datos por medio de librerías PHP, ha
demostrado que unidos pueden lograr generar tecnologías del tipo CTI, por lo cual el
producto finalizado en el presente trabajo, al permitir interactuar aun ser humano con
un computador, puede ser definido como una solución CTI.
 Para el desarrollo e implementación del sistema IVR se utilizaron los siguientes
elementos: servidor de telecomunicaciones Asterisk, servidor de base de datos
MySQL, líneas troncales instaladas y configuradas al PBX Asterisk, demonio Cron.
Para lo cual se configuró dichos elementos a fin de adecuarlos a la solución
110
propuesta, además de instalar las dependencias: sintetizador de voz TTS festival,
servidor de aplicaciones web, compilador e intérprete de PHP. Con los anteriores
elementos, software y hardware mencionados se logró concluir el sistema propuesto
en la tesis. Cabe señalar que las dependencias instaladas son de licencia GLP GNU,
por que los costos en los que se incurrieron para su instalación fueron nulos.
 Se pudo evidenciar en base a los resultados obtenidos por el estudio de casos, que el
correcto funcionamiento del sistema durante la interacción del IVR con el usuario,
es independiente del dispositivo telefónico utilizado en esa acción, pero que si está
condicionado por la calidad de la señal celular en el caso de los dispositivos móviles,
siendo que estos deben de encontrarse en el rango de señal de -50 dBm y -69 dBm,
en el caso de las líneas telefónicas estas deben de tener el tono de llamada.
 El sistema IVR concluido permitió realizar consultas a un sistema web de almacenes
por medio de las distintas redes de telefonía, accediendo de esta forma a la
información en tiempo real independientemente del lugar en que se realice dicha
consulta. Contrastando el acceso tradicional a la base de datos por medio del sistema
web de almacenes con conexión a internet, el producto finalizado es más factible,
respecto a los costos de conectividad, portabilidad, rapidez de acceso a la
información
 Con el producto se logró automatizar las alertas de desabastecimiento, con lo cual la
empresa Inova Netwoks tiene un mayor control de las cantidades existentes de los
productos en almacén, logrando de esta forma gestionar de mejor manera y de forma
más ágil los recursos de la empresa.
 Concluido el desarrollo de los subsistemas de consultas a almacén y alertas de
desabastecimiento, se logró implementar un sistema IVR disponible continuamente,
que permite al usuario interactuar con él y obtener información referente a los
productos registrados en el sistema web de control y gestión de almacenes de Inova
Networks, utilizando como medio de comunicación principal las redes de telefonía,
tanto móviles (redes de telefonía celular) como fijas (red de telefonía conmutada,
RTC).
111
4.2 Recomendaciones
 Es recomendable que al realizar las llamadas necesarias para el acceso a la
información de los productos en almacén y la información sobre el
desabastecimiento, el dispositivo telefónico cuente con una intensidad de señal
celular aceptable en el caso de ser un teléfono móvil.
 Se recomienda el uso de mensajes de texto, funcionalidad disponible en el módulo
GNU desarrollado por Iberoxarxa13 que se instala en Asterisk, como alternativa a la
sintetización de voz, principalmente para el subsistema de alertas ante
desabastecimiento respecto al listado de los productos con stock mínimo, también
permitiría la utilización del sistema IVR a personas con discapacidad auditiva.
 Para mejorar la experiencia respecto a la interactividad con el sistema IVR, es
aconsejable el uso de dispositivos conocidos como manos libres, para de esta forma
permitir al usuario manipular con mayor facilidad el teclado del teléfono para el
ingreso de datos vía tonos DTMF.
 Se recomienda el uso de sistemas de reconocimiento de voz ASR (Automatic Speech
Recognition) para una mayor satisfacción y mejor experiencia del usuario durante la
interactividad con el sistema IVR.
 Para lograr un número mayor de llamadas concurrentes al sistema de consultas a
almacén, se recomienda incrementar el número líneas troncales conectadas a la PBX
Asterisk y configurarlos de tal forma que el flujo de la llamada de las mismas este
direccionado al sistema IVR de consultas a almacén.
 En un futuro, en el cual el acceso al internet sea rápida y fluida, además de que los
costos al acceso sean menores, la utilización de teléfonos inteligentes sea mayor y el
precio de los mismos sea menor, es recomendable cambiar el medio de conexión
propuesto en el presente trabajo por el medio de comunicación VoIP, el cual en
países tecnológicamente más desarrollados se demostró que los costos de
comunicaciones son mucho menores.
13
Empresa española de desarrollo de soluciones de software libre, fundada en 2009.
112
BIBLIOGRAFÍA
AGI, A. G. (2012). Interactive Voice Responce systems, complet report. New York.
Alvares, P. (1999). Reflexiones sobre el papel de la información como recurso competitivo de la

empresa.
Asterisk. (2013). Comunidad Asterisk. Retrieved Abril 10, 2013, from http://comunidad.asteris-
es.org
ATT. (2012). Portal de la ATT. Retrieved 03 15, 2013, from

http://att.gob.bo/index.php/tics/mediciones-de-la-sociedad-de-informacion
IEEE. (1998). IEEE Recommended Practice for Software Requirements Speciﬁcations. New York:
The Institute of Electrical and Electronics Engineers, Inc.
Landivar, E. (2009). Comunicaciones unificadas con Elastix. Los Angeles, EEUU: Elastix.
Lopez, J. G. (2008). VoIP y Asterisk redescubriendo la telefonía. Almería: Alfaomega ra-ma.
Meggelen, J. V. (2007). Asterisk. Sebastopol, E.E.U.U.: O´reilly.
Miller, G. (1956). El número mágico site. Charleston.
Mitchlacey. (2008, 1 1). Mitch Lacey & Associates, Inc. Retrieved 10 15, 2013, from
http://www.mitchlacey.com/intro-to-agile
MOPSV. (2012). TOTAL INSTALACIÓN DE RADIOBASES, 2000-2012. La Paz: Ministerio de Obras

Públicas Servicios y Vivienda (MOPSV).
Parker, G. (2011). El magico numero 4. Acta Psychiatrica Scandinavica.
Pascual, A. E. (2006). VoIP para el desarrollo. Toronto - Canada: CRDI.
Piattini, M. G. (1996). Análisis y diseño detallado de aplicaciones. Madrid: RA-MA Editorial.
Quarea. (2010). Que es asterisk? Retrieved 03 15, 2013, from

http://www.quarea.com/es/centralitas_ip_asterisk/intro
Simionovich, N. (2004). Asterisk Gateway Interface 1.4 and 1.6 Programming. Birmingham:
Packt publishing.
Simionovich, N. (2008). AsteriskNow. Birmingham: Packt Publishing Ltd.
Torralba, F. (2002). Dilemes étics de les TIC a la societat global. Facultat Blanquerna.
UTI, U. I. (2012). Measuring the information society. Geneva Switzerland.
Winder, S. (2001). Understanding telephone electronics. Massachusetts: Butterworth-

Heinemann.
Cuadro comparativo de servicio de internet en sud América ANEXO A
Velocidad
Empresa Costo en
de País Sitio de consulta
proveedora/Plan bolivianos
conexión
Entel (Súper
http://www.entel.bo/informa/?m=
banda ancha) 1024 kbps 230 Bs Bolivia
201301
ADSL
http://www.antel.com.uy/antel/pe
rsonas-y-
Antel (Plano 1) 1024 kbps 182 Bs Uruguay hogares/internet/planes/internet/i
nternet-tarifa-plana/internet-
plano-1
http://vtr.com/hogar/banda-
VRT (MEGA 10) 10 Mbps 154 Bs Chile
ancha/
http://www.claro.com.pe/portal/p
Claro (Internet
1000 kbps 200 Bs Perú e/pc/hogar/internet/internet-
1000 Kbps)
banda-ancha/
*Datos consultados a la fecha 18 de abril de 2013, con cambios de moneda oficiales para esta
fecha
La conexión a internet en Bolivia se sitúa entre los más caros de la región latinoamericana,
llegando a costar doscientos treinta bolivianos la mensualidad de conexión por ADSL de 1024
kbps a una computadora estacionaria y para conectividad móvil hasta trescientos ochenta
bolivianos por cada 100Mb de tráfico realizado con conectividad GPRS. En cuanto a la
conectividad de cuarta generación 4G se presentan las barreras tecnologías, puesto que esta
conexión requiere teléfonos inteligentes de última generación compatibles con dicha
tecnológica o caso contrario contar una computadora portátil que cuente mínimamente con un
puerto USB apartado para un modem que posibilite la conexión a internet.
Situación actual de la cobertura de internet móvil en Bolivia ANEXO B
En Bolivia existen 337 municipios, según el acta de computo nacional de elecciones

departamentales, municipales y regionales del cuatro de abril de 2010, de los cuales, en base a
los informes emitidos por la operadora nación de telecomunicaciones Entel14, 260 municipios
tienen acceso a internet que en su mayoría son por medio de la tecnología 4G. Sin embargo
dicha conexión es solo posible si el usuario está ubicado en las capitales de dichos municipios o
sus cercanías. También se ha evidenciado que la cobertura total de internet en el territorio
boliviano llega a un ochenta por ciento, en pero teniendo a solo 1,2 usuario conectado a la red
de redes por cada cien habitantes.
Otro de los grandes operadores en el área de las telecomunicaciones, VIVA, muestra la

cobertura que brinda en el territorio boliviano en la siguiente URL:
http://avl.nuevatel.com/4G.html15, haciéndose evidente que la conectividad en regiones no
troncales del territorio boliviano es por medio de tecnologías 2G la cual permite utilizar no más
de 64Kbps de banda ancha para la descarga de datos y que solamente en el eje troncal del
territorio boliviano, específicamente en las capitales de los departamentos se cuenta con una
conectividad 4G.
El gobierno boliviano, para poder solucionar esta escasa cobertura de acceso a internet, se ha
propuesto ampliar la cobertura de internet en los próximos años y de esta forma democratizar
el servicio. Para tal fin se ha promulgado la ampliación e instalación de redes de fibra óptica en
la ley de telecomunicaciones, tecnologías de información y comunicación. Este
emprendimiento por parte del gobierno boliviano se lo hace paralelamente al proyecto de
puesta en órbita de un satélite propietario del estado boliviano denominado satélite Tupac
Katari que pretende lograr una cobertura al 100% de conectividad a la red mundial.
14
http://www.cambio.bo/noticia.php?fecha=2011-05-24&idn=45947 , sitio web visitado en fecha cinco
de mayo de 2013
15
Sitio web visitado en fecha 03 de mayo de 2013
Canales de comunicación estándar ANEXO C
STDIN, STDOUT, STDERR
En todas las variantes de UNIX existen tres flujos estándar que actúan como canales de
comunicación que permiten enviar y recoger los datos que surgen de la ejecución de un script,
comando o aplicación., conectan la entrada y salida (I/O) de un comando o aplicación con la
terminal cuando esta es ejecutada, estos canales son:
 Standard input (stdin)
 Standard output (stdout)
 Standard error (stderr)
Standard input
STDIN, o standard input representa los datos que son enviados al programa para ser
procesados, por lo general este canal no es utilizado frecuentemente ya que lo normal suele
ser interpretar los datos que el programa o comando envía, y no al revés. Normalmente STDIN
es texto enviado por el usuario al programa o aplicación. En un script en perl, se puede solicitar
la interacción del usuario mediante STDIN, por ejemplo en este caso se recoge mediante STDIN
el valor de dos variables que el usuario escribe, ver figura A1.
#!/usr/bin/perl
print "Introduce tu nombre:\n";
my $nombre = <STDIN>;
print "Introduce tu apellido:\n";
my $apellido = <STDIN>;
Figura 1: Código fuente que muestra el uso de STDIN
Standard output
A través de la salida estándar, “STDOUT” se reciben los datos que vuelca el comando o
programa durante su ejecución, un uso básico del STDOUT se refleja en los resultados emitidos
por el uso de los comandos “ls”,”cat” o cualquier otro comando de terminal. En cambio, hay
otros comandos o programas que no muestran salida (a no ser que se especifique), como por
ejemplo mover o copiar ficheros. Cualquiera de estos flujos de datos se puede manipular de
forma tal que el resultado que emita un comando, programa o aplicación pueda ser enviado al
STDIN del mismo, a continuación se mostrará el uso del STDOUT sobre el comando ls, enviando
sus resultados a un archivo en específico.
$ ls
backups cpq games local log opt spool www
cache crash lib lock mail run tmp
Figura 2: Salida de datos (STDOUT) el cual es impreso en la terminal

$ ls > fichero.txt
Figura 3: Manipulación de la salida estándar, enviando el STDUOT de ls a ficheto.txt
$ cat fichero.txt
backups cpq games local log opt spool www
cache crash lib lock mail run tmp
Figura 4: Visualización de los resultados a los anteriores comandos, figura 2-3.
Standard error (STDERR)

A través del canal STDERR los programas o comandos suelen enviar el informe de error de la
ejecución de un comando en caso de fallar. En estos scripts o comandos se puede combinar el
uso de STDOUT y STDERR para separar la salida estándar de los errores, almacenarlos en
registros independientes o manipularlos por separado.
En el siguiente ejemplo se ejecutará el comando “ls” con parámetros incorrectos, por defecto la
salida de errores se volcará en pantalla (terminal)
$ ls -7
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.
Para almacenar los errores de la ejecución del comando, estos pueden ser volcarlos usando en
lugar del símbolo “>” el número 2 seguido de “>”, “2>”:
$ ls -7 2> errores.log
Como se puede ver los errores ya no aparecen por pantalla pues estos son almacenados en el
fichero de log
$ cat errores.log
ls: opción incorrecta -- '7'
Pruebe `ls --help' para más información.
A continuación se mostrara el uso del STDOUT y el STDERR simultáneamente en una misma

línea de instrucción, en esta se almacena la información del STDOUT en un archivos llamado
test.sql y en caso de existir errores estos son almacenados en el log llamado error.
$ mysqldump test > test.sql 2> error.log

Modelos de formularios de evaluación del sistema IVR ANEXO D
FORMULARIO DE EVALUACIÓN – SUBSISTEMA DE CONSULTAS A ALMACÉN
Datos generales del usuario final
Código de usuario ::
Cargo en la empresa ::
Edad ::
Nivel de instrucción tecnológica :: Avanzado Medio Básico Ninguna
Datos del sitio de la prueba

Ciudad ::
Zona ::
Datos técnicos del dispositivo telefónico con el que cuenta el usuario final
Tipo de dispositivo :: Móvil/táctil Móvil/teclado Teléf. Fijo OTRO
Marca ::
Modelo ::
Empresa operadora :: Tigo Viva Entel OTRO
¿Le fue fácil navegar por las opciones del menú del subsistema de consultas a almacén?
Si No
¿Qué nivel de claridad de voz pudo captar en los mensajes emitidos por el subsistema de
consultas?
Excelente Muy buena Buena Regular Mala
¿Obtuvo la información que buscaba?

Si No
¿Le fue de utilidad dicha información?

Si No
¿La información registrada en el sistema web de control y gestión de almacenes, coincidió con
la información entregada por el subsistema de consultas a almacén?
Si No
¿En algún momento, usted advirtió la inexistencia del servicio ofrecido por el sistema?
Si No
En caso de ser afirmativa la respuesta a la anterior pregunta, por favor indique la hora y lugar
donde se advirtió la indisponibilidad del servicio.
Hora ::
Lugar exacto ::
:: Fuera Línea Línea de destino
OTRO
Posible causa Sin señal
de cobertura ocupada sin servicio
Métricas de eficiencia
Indique el número de intentos para lograr interactuar con el sistema IVR ::
Indique la cantidad de intentos, ingresando su código de usuario, necesarios
::
para acceder al gestor de consultas a almacén
Indique la duración total en segundos requeridos para obtener el stock
::
actual de algún producto
Indique la duración total en segundos necesarios para conocer los precios
::
por mayor y menor de algún producto
Indique la duración total en segundos necesarios para conocer la
::
descripción general de algún producto
Basándose en la reciente experiencia que tuvo con el sistema, ¿lo volvería a usar regularmente
como un medio alterno para la consulta de datos en el almacén?
Si No Ocasionalmente
FORMULARIO DE EVALUACIÓN – SUBSISTEMA DE ALERTAS
Datos generales del usuario final

Código de usuario ::
Cargo en la empresa ::
Edad ::
Nivel de instrucción tecnológica :: Avanzado Medio Básico Ninguna
Datos técnicos del dispositivo telefónico con el que cuenta el usuario final
Tipo de dispositivo :: Móvil/táctil Móvil/teclado Teléf. Fijo OTRO
Marca ::
Número de línea telefónica ::
En caso de llamar al subsistema de alertas ante desabastecimientos
¿El sistema le permitió acceder a la información de productos desabastecidos?

Si No
En caso de ser negativa la respuesta anterior, por favor escriba el número de la línea telefónica
y el nombre del operador de dicha línea desde el cual realizó la llamada
Número de linea telefónica ::
En caso de recibir alertas automáticas
Indique la cantidad de veces que fue alertado por el sistema ante algún desabastecimiento de
producto
Conociendo la hora y fecha en que se produjo algún desabastecimiento de productos, ¿Cuál fue
el tiempo de retraso máximo en minutos de la alerta del sistema ante tal suceso?
Indique la cantidad máxima de insistencias de llamadas de alerta recibidas por el sistema
¿Sintió algún grado de molestia ante las insistencias del subsistema de alertas?
Ninguna Poca Mucha
Por favor responda las siguientes preguntas independientemente de si usted realizo la llamada
o la recibió
¿Le fue fácil navegar por las opciones del menú del IVR?
Si No
¿Qué nivel de claridad de voz pudo captar en los mensajes emitidos por el sistema IVR?
Excelente Muy buena Buena Regular Mala
¿Le fue de utilidad la información entregada por el sistema?

Si No
¿La información registrada en el sistema web de control y gestión de almacenes coincidió con
la información entregada por el subsistema de alertas de productos desabastecidos?
Si No
¿En algún momento, usted advirtió la inexistencia del servicio ofrecido por el sistema?
Si No
En caso de ser afirmativa la respuesta a la anterior pregunta, por favor indique la hora y lugar
donde se advirtió la indisponibilidad del servicio.
Hora ::
Lugar exacto ::
:: Fuera Línea Línea de destino
OTRO
Posible causa Sin señal
de cobertura ocupada sin servicio
Métricas de eficiencia
Indique el número de intentos para lograr interactuar con el sistema IVR ::
Indique la cantidad de intentos necesarios para interactuar con el
::
subsistema de alertas
Reglamento de almacén – Experts Inova Networks Srl. ANEXO E
CAPITULO I
DISPOSICIONES GENERALES
ARTICULO 1o.- El jefe del Departamento del almacén tendrá las llaves del almacén, no podrán
ser prestadas a personal ajeno.
ARTICULO 2o.- Cuando se requiera de encender instrumentos eléctricos y/o electrónicos como
cafeteras, ventiladores, taladros, computadoras, etc. se cuidará que se desconecten una vez
terminados de usar, a fin de evitar chispas que ocasionen incendios.
ARTICULO 3o.- El personal deberá utilizar los uniformes e instrumentos de trabajo y de

seguridad que se le entreguen, ya que de lo contrario la empresa se eximirá de toda
responsabilidad en caso de accidentes o enfermedades profesionales derivadas de la
negligencia o descuido de parte del trabajador.
ARTICULO 4o.- Por seguridad personal y limpieza del almacén, se deberá de colocar el material
en las áreas y anaqueles que les correspondan, como se señala en el manual de Almacenes.
CAPITULO II
CONTROL DE ALMACENAJE
ARTICULO 5o.- El jefe del almacén tendrá la función de revisar periódicamente las cantidades
de productos existentes en el almacén para evitar desabastecimientos.
ARTICULO 6o.- El jefe del almacén deberá de verificar que todos los productos en el almacén
tengan una cantidad mayor a diez unidades.
ARTICULO 7o.- Las reposiciones, compras y reabastecimiento de productos no deberán de

sobrepasar en lo posible el límite de tres semanas.
Fragmentos extraídos del reglamento interno del almacén de la empresa Inova Networks
Requerimientos del sistema IVR según la metodología Scrum ANEXO F
Historias de usuario
ID Nombre Usuario Descripción
HU-11 Saludo a usuario autorizado Central Se hace audible un saludo al usuario autorizado
según el horario en que se realiza el proceso de
la llamada
(Buenos días/Buenas tardes/Buenas noches)
(apellido paterno del usuario)
HU-12 Petición de código numérico de Central Se hace audible la petición del ingreso de código
producto numérico del producto a consultar
HU-13 Ingreso de código numérico de Cliente El cliente ingresa el código numérico del
producto producto a ser consultado
HU-14 El cliente ingresa un código de Cliente En caso de que el cliente no digite un código de
producto inexistente producto valido, se escuchará un mensaje de
error.
El número de intentos deberá ser menor a tres.
HU-15 Dictado del nombre del Central Se escucha el nombre del producto
producto seleccionado seleccionado
HU-16 Menú secundario (menú IVR Cliente Se escucha el listado de opciones del menú
para consultas a almacén) secundario respecto a las posibilidades de
obtención de información de los productos.
HU-17 Elección de la primera opción Cliente El cliente presiona la tecla uno, con la cual elige
del menú secundario la primera opción del menú secundario que es
el consultar la información de existencia física
en el almacén del producto anteriormente
seleccionado.
HU-18 Dictado del stock actual en Central Se escucha el número total de productos
almacén existentes en el almacén en tiempo real
HU-19 Elección de la segunda opción Cliente El cliente presiona la tecla dos, con la cual elige
del menú secundario la segunda opción del menú secundario que es
el consultar la información respecto a los
precios por menor y mayor del producto
seleccionado.
HU-20 Dictado del precio por mayor y Central Se escucha el precio por mayor y menor del
menor del producto producto seleccionado
HU-21 Elección de la tercera opción Cliente El cliente presiona la tecla tres, con la cual elige
del menú secundario la segunda opción del menú secundario que es
el consultar la información general, conformada
por la categoría del producto y el nombre del
producto anteriormente seleccionado.
HU-22 Dictado de la información Central Se escucha el dictado de la categoría del
general del producto producto y el nombre del mismo
HU-23 Elección de la cuarta opción del Cliente El cliente presiona la tecla cuatro, con la cual
menú secundario elige la cuarta opción del menú secundario que
es el retornar a HU-12.
HU-24 El cliente digita una opción Cliente En caso de que el cliente no digite una opción
inexistente en el menú válida se escucha un mensaje de error.
secundario El número de intentos deberá ser menor a tres.
HU-25 Elección de la cuarta opción del Cliente El cliente presiona la tecla cero, con la cual elige
menú principal la cuarta opción del menú principal
HU-26 Contacto directo con un Cliente La llamada es transferida a un operador.
operador
inexistente en el menú válida se escucha un mensaje de error.
principal El número de intentos deberá ser menor a tres.
HU-28 Verificación de stock mínimo Central Se verifica automáticamente la existencia de
productos con stock mínimo
HU-29 Alerta automática de stock Central Se realiza hasta tres llamadas para informar
mínimo sobre el desabastecimiento de productos
HU-30 Usuario contesta la llamada Central (Buenos días/Buenas tardes/Buenas noches)
(saludo al usuario) (apellido paterno del usuario)
HU-31 Menú IVR de stock mínimo Cliente Se escucha el listado de opciones del menú del
subsistema de alertas automáticas respecto al
desabastecimiento de productos.
HU-32 Elección de la primera opción Cliente El cliente presiona la tecla uno, con la cual elige
del menú de stock mínimo la primera opción del menú de stock mínimo
que es el listado de los identificadores de los
productos con un stock mínimo
HU-33 Listado de los identificadores de Cliente Se escucha el listado de los identificadores de
productos desabastecidos los productos en base al siguiente formato:
Los id´s de los productos con stock mínimo son:
id [id del producto i] stock [stock del producto
i], id [id del producto i+1] stock [stock del
producto i+1],… , id [id del producto n] stock
HU-34 Elección de la segunda opción Cliente El cliente presiona la tecla dos, con la cual elige
del menú de stock mínimo la segunda opción del menú de stock mínimo
que es el listado de los nombres de los
productos con un stock mínimo
HU-35 Listado de los nombres de Cliente Se escucha el listado de los productos en base
productos desabastecidos al siguiente formato:
Los productos con stock mínimo son: [nombre
del producto i] stock [stock del producto i],
[nombre del producto i+1] stock [stock del
producto i+1],… , [nombre del producto n] stock
HU-36 Elección de la tercera opción Cliente El cliente presiona la tecla tres, con la cual elige
del menú de stock mínimo la tercera opción del menú de stock mínimo que
es el envío de un informe detallado de los
productos con un stock mínimo al correo
asociado del usuario autorizado.
HU-37 Listado de los nombres de Cliente Se escucha el listado de los productos en base
productos desabastecidos al siguiente formato:
Los productos con stock mínimo son: [nombre
del producto i] stock [stock del producto i],
[nombre del producto i+1] stock [stock del
producto i+1],… , [nombre del producto n] stock
inexistente en el menú de válida se escucha un mensaje de error.
stock mínimo El número de intentos deberá ser menor a tres.
Pila del producto

ID Nombre Usuario Descripción Importancia Sprint
Se hace audible un saludo al usuario
autorizado según el horario en que se
Saludo a usuario
HU-11 Central realiza el proceso de la llamada(Buenos 60 3
autorizado
días/Buenas tardes/Buenas noches)
(apellido paterno del usuario)
Se hace audible la petición del ingreso
Petición de código
HU-12 Central de código numérico del producto a 90 3
numérico de producto
consultar
Ingreso de código El cliente ingresa el código numérico del
HU-13 Cliente 90 3
numérico de producto producto a ser consultado
En caso de que el cliente no digite un
El cliente ingresa un código de producto valido, se escuchará
HU-14 código de producto Cliente un mensaje de error. 90 3
inexistente El número de intentos deberá ser
menor a tres.
Dictado del nombre
Se escucha el nombre del producto
HU-15 del producto Central 70 3
seleccionado
seleccionado
Se escucha el listado de opciones del
Menú secundario
menú secundario respecto a las
HU-16 (menú IVR para Cliente 90 4
posibilidades de obtención de
consultas a almacén)
información de los productos.
El cliente presiona la tecla uno, con la
cual elige la primera opción del menú
Elección de la primera
secundario que es el consultar la
información de existencia física en el
secundario
almacén del producto anteriormente
seleccionado.
Se escucha el número total de
Dictado del stock
HU-18 Central productos existentes en el almacén en 100 4
actual en almacén
tiempo real
cual elige la segunda opción del menú
Elección de la segunda
información respecto a los precios por
secundario
menor y mayor del producto
seleccionado.
Dictado del precio por
Se escucha el precio por mayor y menor
HU-20 mayor y menor del Central 90 4
del producto seleccionado
producto
cual elige la segunda opción del menú
información general, conformada por la
secundario
categoría del producto y el nombre del
producto anteriormente seleccionado.
Dictado de la
Se escucha el dictado de la categoría del
HU-22 información general Central 90 4
producto y el nombre del mismo
del producto
Elección de la cuarta
El cliente presiona la tecla cuatro, con la
opción del menú
HU-23 Cliente cual elige la cuarta opción del menú 100 4
secundario (retorno a
secundario que es el retornar a HU-12.
menú secundario)
El cliente digita una opción válida se escucha un mensaje de
HU-24 opción inexistente en Cliente error. 100 4
el menú secundario El número de intentos deberá ser
menor a tres.
Elección de la cuarta El cliente presiona la tecla cero, con la
HU-25 opción del menú Cliente cual elige la cuarta opción del menú 60 2
principal principal
Contacto directo con La llamada es transferida a un
HU-26 Cliente 60 3
un operador operador.
El cliente digita una opción válida se escucha un mensaje de
HU-27 opción inexistente en Cliente error. 70 2
el menú principal El número de intentos deberá ser
menor a tres.
Se verifica automáticamente la
Verificación de stock
HU-28 Central existencia de productos con stock 100 5
mínimo
mínimo
Se realiza hasta tres llamadas para
Alerta automática de
HU-29 Central informar sobre el desabastecimiento de 100 5
stock mínimo
productos
Usuario contesta la
(Buenos días/Buenas tardes/Buenas
HU-30 llamada (saludo al Central 70 5
noches) (apellido paterno del usuario)
usuario)
Se escucha el listado de opciones del
Menú IVR de stock menú del subsistema de alertas
HU-31 Cliente 100 5
mínimo automáticas respecto al
desabastecimiento de productos
El cliente presiona la tecla uno, con la
Elección de la primera cual elige la primera opción del menú
HU-32 opción del menú de Cliente de stock mínimo que es el listado de los 90 5
stock mínimo identificadores de los productos con un
stock mínimo
Se escucha el listado de los
identificadores de los productos en
base al siguiente formato:Los id´s de los
Listado de los
productos con stock mínimo son: id [id
identificadores de
HU-33 Cliente del producto i] stock [stock del 90 5
productos
producto i], id [id del producto i+1]
desabastecidos
stock [stock del producto i+1],… , id [id
del producto n] stock [stock del
producto n]
Elección de la segunda cual elige la segunda opción del menú
HU-34 opción del menú de Cliente de stock mínimo que es el listado de los 95 5
stock mínimo nombres de los productos con un stock
mínimo
Se escucha el listado de los productos
en base al siguiente formato:
Los productos con stock mínimo son:
Listado de los
[nombre del producto i] stock [stock del
HU-35 nombres de productos Cliente 95 5
producto i], [nombre del producto i+1]
desabastecidos
stock [stock del producto i+1],… ,
[nombre del producto n] stock [stock
del producto n]
cual elige la tercera opción del menú de
stock mínimo que es el envío de un
HU-36 opción del menú de Cliente 95 5
informe detallado de los productos con
stock mínimo
un stock mínimo al correo asociado del
usuario autorizado.
Se escucha el listado de los productos
en base al siguiente formato:
Los productos con stock mínimo son:
Listado de los
[nombre del producto i] stock [stock del
HU-37 nombres de productos Cliente 95 5
producto i], [nombre del producto i+1]
desabastecidos
stock [stock del producto i+1],… ,
[nombre del producto n] stock [stock
del producto n]
El cliente digita una
opción válida se escucha un mensaje de
opción inexistente en
HU-38 Cliente error. 95 5
el menú de stock
El número de intentos deberá ser
mínimo
menor a tres.
Fichas de usuario

Nombre Nombre
Bienvenida Menú principal
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la primera opción del menú Contacto directo con el área de ventas
principal
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la segunda opción del menú Contacto directo con el área
principal administrativa
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la tercera opción del menú Petición de identificación
principal
Usuario Usuario
Cliente Cliente

Nombre Nombre
Ingreso de contraseña El cliente ingresa una contraseña de
usuario no valida
Usuario Usuario
Cliente Cliente

Nombre Nombre
Saludo a usuario autorizado Petición de código numérico de
producto
Usuario Usuario
Cliente Cliente

Nombre Nombre
Ingreso de código numérico de producto El cliente ingresa un código de producto
inexistente
Usuario Usuario
Cliente Cliente

Nombre Nombre
Dictado del nombre del producto Menú secundario (menú IVR para
seleccionado consultas a almacén)
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la primera opción del menú Dictado del stock actual en almacén
secundario
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la segunda opción del menú Dictado del precio por mayor y menor
secundario del producto
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la tercera opción del menú Dictado de la información general del
secundario producto
Usuario Usuario
Cliente Central

Nombre Nombre
Elección de la cuarta opción del menú El cliente digita una opción inexistente
secundario (retorno a menú secundario) en el menú secundario
Usuario Usuario
Cliente Cliente

Nombre Nombre
Elección de la cuarta opción del menú Contacto directo con un operador
principal
Usuario Usuario
Cliente Cliente

Nombre Nombre
El cliente digita una opción inexistente Verificación de stock mínimo
en el menú principal
Usuario Usuario
Cliente Central

Nombre Nombre
Alerta automática de stock mínimo Usuario contesta la llamada (saludo al
usuario)
Usuario Usuario
Central Cliente, Central

Nombre Nombre
Menú IVR de stock mínimo Elección de la primera opción del menú
de stock mínimo
Usuario Usuario
Cliente Cliente

Nombre Nombre
Listado de los identificadores de Elección de la segunda opción del menú
productos desabastecidos de stock mínimo
Usuario Usuario
Cliente Cliente

Nombre Nombre
Listado de los nombres de productos Elección de la tercera opción del menú
desabastecidos de stock mínimo
Usuario Usuario
Cliente Cliente

Nombre Nombre
Listado de los nombres de productos El cliente digita una opción inexistente
desabastecidos en el menú de stock mínimo
Usuario Usuario
Cliente Cliente
Actividades de ingeniería - Historias técnicas
Estimación
ID Nombre horas
Responsable Sprint
Instalación y configuración de servidor

de aplicaciones web en Centos
Instalación y configuración de TTS
Festival
Instalación de librerías AdoDB PHP
como manejador de conexiones a DBMS
Configurar DBMS MySQL para permitir Cesar Nilton Rojas Valero
HT-4 1 1
conexiones remotas Administrador de hosting
Configuración de Crontab para

realización de tareas en segundo plano
Pruebas de conexión remota desde

HT-6 servidor local de aplicaciones web, a 1 Cesar Nilton Rojas Valero 1
servidor de base de datos exterior
Pruebas de efectividad de realización de

tareas con Crontab
Crear y documentar el diseño general
del sistema IVR principal
para el menú principal
Crear y documentar el inicio de la
llamada al sistema IVR (Saludo)
Crear y documentar el menú principal
del sistema IVR
Crear y documentar la transferencia a
un agente de ventas

HT-13 un número de interno de recepción del 1 Cesar Nilton Rojas Valero 3
área administrativa

un operador de Inova Networks
HT-15 sistema de gestión de consultas a 2 Cesar Nilton Rojas Valero 3
almacén
Pruebas de IVR principal en modo de
Crear y documentar el ingreso y
validación de datos para usuario
Crear y documentar saludo a usuario
valido
Crear y documentar el ingreso y
HT-19 validación de código de producto a 8 Cesar Nilton Rojas Valero 3
consultar
Crear y documentar identificación del
producto según el código ingresado

HT-21 para el menú secundario (gestor de 5 Cesar Nilton Rojas Valero 4
consultas a almacén)
Crear y documentar el menú secundario

del sistema IVR (consulta a almacén)
Crear y documentar la consulta a base

HT-23 de datos respecto al producto 10 Cesar Nilton Rojas Valero 4
seleccionado en HT-19

para el menú de IVR de alertas
tempranas (gestor de alertas ante
desabastecimiento)
tempranas
Crear y documentar la validación de la
contraseña de usuario del llamante
HT-28 verificación de productos 6 Cesar Nilton Rojas Valero 6
desabastecidos
Crear y documentar saludo a usuario
valido
Pruebas del menú del subsistema de
alertas
Crear y documentar la consulta a base
HT-31 de datos respecto a los productos 6 Cesar Nilton Rojas Valero 6
desabastecidos
Crear y documentar el envió de informe
HT-32 de productos desabastecidos a un 8 Cesar Nilton Rojas Valero 6
correo electrónico
Pruebas del subsistema de alertas
tempranas
Fichas técnicas

ID HT-3 ID HT-4
Nombre Nombre
Configurar DBMS MySQL para permitir Instalación de librerías AdoDB PHP como
conexiones remotas manejador de conexiones a DBMS
Contactarse con el administrador de hosting que Conectarse vía ftp al servidor Asterisk y agregar la
aloja a el DBMS y pedirle conceda privilegios de librería AdoDB PHP a los directorios:
acceso remoto al usuario XXX /var/lib/asterisk/agi-bin y
/var/www/html/conexionRemortaMysql
Usuario Usuario
Cliente Cliente

100 6 100 1

ID HT-5 ID HT-6
Nombre Nombre
Configuración de Crontab para realización de Pruebas de conexión remota desde servidor local
tareas en segundo plano de aplicaciones web, a servidor de base de datos
exterior
Se crea comandos en cron a fin de que se realice Se crea un script escrito en lenguaje PHP a fin de
y ejecute un script PHP para la revisión que consulte datos de la base de datos “product”
constante de posibles desabastecimientos de del DBMS MySQL alojado en un hosting exterior.
productos en almacén. Desde un ordenador conectado a la LAN de Inova
Utilizar el comando cron –e y cron -l ingresar a la dirección:
192../conexionRemortaMysql/conexion.php
Usuario Usuario
Cliente Cliente

100 1 100 1
ID HT- 7 ID HT- 8
Nombre Nombre
Pruebas de efectividad de realización de tareas Crear y documentar el diseño general del sistema
con Crontab IVR principal
Se verifica con un cronometro y registro de las Levantamiento de requisitos, creación de diagrama
tareas realizadas a partir de los comandos cron de flujo y definición del flujo de las llamadas.
creados en el Crontab de Centos.
Usuario Usuario
Cliente Cliente

100 1 100 30

ID HT-9 ID HT-10
Nombre Nombre
Crear y documentar las grabaciones para el Crear y documentar el inicio de la llamada al
menú principal sistema IVR (Saludo)
Se realiza grabaciones en base a los escenarios Se desarrolla el inicio de la llamada para el sistema
identificados para el menú principal del sistema IVR, emitiendo un saludo al cliente si se entabla el
IVR. enlace de comunicación.
Usuario Usuario
Cliente Cliente

100 12 100 2
ID HT-11 ID HT-12
Nombre Nombre
Crear y documentar el menú principal del Crear y documentar la transferencia a un agente de
sistema IVR ventas
Mediante Scripts en el lenguaje PHP y el uso de Se crea un número interno dedicado al área de
comandos AGI, desarrollar las opciones de ventas en el sistema Asterisk con el objetivo de
navegabilidad del sistema IVR para el menú recepcionar las llamadas transferidas.
principal. Se desarrolla la transferencia de la llamada a un
Utilizar las grabaciones de HT-9 y siguiendo la número de interno perteneciente al área de ventas,
lógica de negocio definida en HT-8. esta transferencia es realizada por medio de
comandos AGI.
Usuario Usuario
Cliente Cliente

100 8 100 2

ID HT-13 ID HT-14
Nombre Nombre
Crear y documentar la transferencia a un Crear y documentar la transferencia a un operador
número de interno de recepción del área de Inova Networks.
administrativa.
Se crea un número interno dedicado al área de Se crea un número interno dedicado al área de
ventas en el sistema Asterisk con el objetivo de ventas en el sistema Asterisk con el objetivo de
recepcionar las llamadas transferidas. recepcionar las llamadas transferidas.
Se desarrolla la transferencia de la llamada a un Se desarrolla la transferencia de la llamada a un
número de interno perteneciente al área número de interno perteneciente al área
administrativa, esta tarea es realizada por medio operadores, esta tarea es realizada por medio de
de comandos AGI. comandos AGI.
Usuario Usuario
Cliente Cliente

100 1 100 1
ID HT-15 ID HT-16
Nombre Nombre
Crear y documentar la transferencia al sistema Pruebas de IVR principal en modo de desarrollo
de gestión de consultas a almacén (simulador de aplicación)
Se desarrolla la transferencia de la llamada a una Se ejecuta el sistema IVR, realizando llamadas
aplicación en lenguaje PHP, el flujo de la llamada desde números internos dentro de la red de Inova
es controlado por comandos AGI. Networks y se depura posibles errores.
Usuario Usuario
Cliente Cliente

100 2 100 6

ID HT-17 ID HT-18
Nombre Nombre
Crear y documentar el ingreso y validación de Crear y documentar saludo a usuario valido
datos para usuario
Por medio de comandos AGI se obtiene los tonos Se desarrolla el flujo de la llamada que permita
DTMF enviados por el usuario a raíz de la escuchar un saludo con el formato: “(Buenos
petición realizada por el sistema IVR (HT-9 días/Buenas tardes/Buenas noches) Señor (Apellido
[Petición de contraseña de usuario]). paterno del usuario)”.
Se desarrolla la validación de los datos obtenidos
contra los registro en la base de datos.
Usuario Usuario
Cliente Cliente

100 8 100 2
ID HT-19 ID HT-20
Nombre Nombre
Crear y documentar el ingreso y validación de Crear y documentar identificación del producto
código de producto a consultar según el código ingresado
Por medio de comandos AGI se obtiene los tonos Se desarrolla el flujo de la llamada que permita
DTMF enviados por el usuario a raíz de la escuchar la identificación del producto con el
petición realizada por el sistema IVR (HT-9 código capturado y validado en HT-19.
[Código de producto]). El formato de la identificación será: “Producto
Se desarrolla la validación de los datos obtenidos seleccionado [categoría del producto] [nombre
contra los registro en la base de datos para el producto]”
código del producto ingresado.
Usuario Usuario
Cliente Cliente

100 8 100 4

ID HT-21 ID HT-22
Nombre Nombre
Crear y documentar las grabaciones para el Crear y documentar el menú secundario del sistema
menú secundario (gestor de consultas a IVR (consulta a almacén)
almacén)
Se realiza grabaciones en base a los escenarios Mediante Scripts en el lenguaje PHP y el uso de
identificados para el menú secundario del comandos AGI, desarrollar las opciones de
sistema IVR, el cual será parte del subsistema navegabilidad del sistema IVR para el menú
gestor de consultas a almacén. secundario.
Utilizar las grabaciones de HT-21 y siguiendo la
lógica de negocio definida en HT-8.
Usuario Usuario
Cliente Cliente

100 5 100 6
ID HT-23 ID HT-24
Nombre Nombre
Crear y documentar la consulta a base de datos Pruebas de IVR secundario en modo de desarrollo
respecto al producto seleccionado en HT-19 (simulador de aplicación)
Se desarrolla las consultas a la base de datos Se ejecuta el sistema IVR, realizando llamadas
remota en base a los parámetros obtenidos en desde números internos dentro de la red de Inova
HT-19 y las elecciones de las opciones de Networks, se ingresa al menú secundario que es el
consultas. Se normaliza los datos obtenidos para gestor de consultas a almacén y se depura posibles
la sintetización de los mismos utilizando Festival errores.
para hacer audible los resultados.
Usuario Usuario
Cliente Cliente

100 10 100 6

ID HT-25 ID HT-26
Nombre Nombre
Crear y documentar las grabaciones para el Crear y documentar el menú de alertas tempranas
menú de IVR de alertas tempranas (gestor de
alertas ante desabastecimiento)
Se realiza grabaciones en base a los escenarios Mediante Scripts en el lenguaje PHP y el uso de
identificados para el menú del IVR de alertas comandos AGI, desarrollar las opciones de
tempranas del sistema IVR, el cual será parte del navegabilidad del sistema IVR para el menú de IVR
subsistema gestor de alertas ante de alertas tempranas.
desabastecimientos. Utilizar las grabaciones de HT-25 y siguiendo la
lógica de negocio definida en HT-8.
Usuario Usuario
Cliente Cliente

100 6 100 6
ID HT-27 ID HT-28
Nombre Nombre
Crear y documentar la validación de la Crear y documentar la validación y verificación de
contraseña de usuario del llamante productos desabastecidos
Se desarrolla la validación de la contraseña Se desarrolla un controlador automático de las
ingresada del llamante obteniendo este cantidades de stock en almacén de todos los
parámetro por medio del uso de comandos AGI. productos ahí registrados, esta tarea se realiza por
Se verifica la existencia de esta variable en la medio del uso de comandos cron y la modificación
base de datos para su aceptación. del Crontab.
Se obtiene la cantidad total de productos
desabastecidos
Usuario Usuario
Cliente Cliente

100 10 100 6

ID HT-29 ID HT-30
Nombre Nombre
Crear y documentar llamada automática y saludo Pruebas del menú del subsistema de alertas
a usuario valido tempranas
En caso de existir desabastecimiento y de aun no Para las pruebas de este menú, se preparan dos
tener entablada una comunicación con el escenarios distintos: Se modifica la cantidad de
usuario autorizado, se realiza una llamada algunos productos almacenados a un stock mínimo
automática por medio de creación de un script de almacenaje a fin de que se realice la llamada
que posibilite esta tarea. El archivo con el script automática desarrollada en HT-29. Se ejecuta el
estará almacenado en la dirección: sistema IVR, realizando llamadas desde números
/var/spool/asterisk/outgoing/xxx.call internos dentro de la red de Inova Networks, se
Una vez establecida la comunicación con el marcará el número de interno dedicado al gestor de
usuario, se reproducirá un saludo con el nombre alertas tempranas para probar la funcionabilidad
de usuario contactado. del menú.
Usuario Usuario
Cliente Cliente

100 2 100 1
ID HT-31 ID HT-32
Nombre Nombre
Crear y documentar la consulta a base de datos Crear y documentar envió de informe de productos
respecto a los productos desabastecidos desabastecidos a un correo electrónico
Se desarrolla las consultas a la base de datos Se desarrolla una plantilla en Excel para el informe,
remota en base a las elecciones de las opciones el cual será creado dinámicamente en base a los
de consultas listadas en el menú creado en HT- productos desabastecidos.
30. Se enviara un correo electrónico a petición del
Se normaliza los datos obtenidos para la usuario, a este correo se adjunta el informe creado
sintetización de los mismos utilizando Festival dinámicamente.
para hacer audible los resultados.
Las consultas son respecto al listado de los id’s
de los productos desabastecidos, el listado de los
nombres de los productos desabastecidos
Usuario Usuario
Cliente Cliente

100 6 100 8
HISTORIA TÉCNICA
ID HT-33
Nombre
Pruebas del subsistema de alertas tempranas
Descripción
Para las pruebas de este subsistema, se preparan nuevamente dos escenarios distintos: Se
modifica la cantidad de algunos productos almacenados a un stock mínimo de almacenaje
a fin de que se realice la llamada automática. Se ejecuta el sistema IVR, realizando
llamadas desde números internos dentro de la red de Inova Networks, se marcará el
número de interno dedicado al gestor de alertas tempranas para probar la funcionabilidad
respecto a las consultas y obtención de información respecto a los productos son stock
mínimo.
Usuario
Cliente
Importancia Estimación
100 5
Casos de uso para las funciones del sistema IVR ANEXO G
Módulo área de ventas
El módulo de área de ventas, cumplirá la función de comunicar al cliente con un represéntate de ventas
de la empresa Inova Networks, por lo cual se describirán a continuación por medio de un diagrama de
casos de uso (ver Figura 1) el comportamiento general del módulo de área de ventas.
Recibir
información
Atención del
Cliente cliente Ejecutivo de ventas
Figura 1: Diagrama de caso de uso – módulo de área de ventas
A continuación se describirán las funciones que tendrán que cumplir los casos de uso mostrados en la
anterior figura.
Tabla 1: Caso de uso 1.1 - Recibir información

Descripción Al ingreso del menú principal del sistema IVR, el cliente recibirá un mensaje
audible de bienvenida e información sobre el digito de opción de comunicación
directa con el área de ventas. Posterior a la entrega de información del servicio,
se presentará las opciones restantes del menú IVR
Actores Cliente
Precondiciones El cliente deberá de estar en línea para poder escuchar los mensajes audibles del
sistema IVR
Secuencia normal de Paso Acción
eventos
2 El cliente escuchará como menú el digito de opción que le dirigirá a la
transferencia de la llamada a un ejecutivo de ventas
3 Se transfiere la llamada a un operador de ventas
Postcondición No aplica, puesto el cliente solamente recibirá información y solo escuchara las
opciones de un menú
1 Si el cliente no elige alguna de las opciones indicadas en el menú, se le
informará que la opción seleccionada no es valida
2 Si existiesen tres intentos erróneos de elección de alguna opción del
menú, el cliente recibirá un mensaje de despedida y se concluirá la
llamada.
Tabla 2: Caso de uso 1.2 - Atención al cliente
CU – 1.2 Atención al cliente

Descripción Una vez realizada la transferencia automática de la llamada al área de ventas, un
ejecutivo atenderá la llamada realizada y brindara información respecto a la venta de
productos de Inova Networks al cliente.
Actores Cliente, Ejecutivo del área de ventas
Precondiciones Para que se posibilite el contacto directo del cliente con un ejecutivo del área de
ventas, el cliente deberá de discar la opción del menú principal para el contacto con el
área de ventas.
Secuencia normal Paso Acción
de eventos
1 El cliente elegirá la opción de contacto con el área de ventas
2 Se transferirá automáticamente la llamada a un agente de ventas
3 Se entablara una conversación entre el cliente y el agente de ventas
Postcondición Se entregara por parte del agente de ventas, información detallada respecto a la
comercialización de los productos en la empresa Inova Networks
Módulo de área administrativa

El módulo de área administrativa, cumplirá la función de comunicar al cliente con un represéntate del
área administrativa de la empresa Inova Networks, a fin de atender a las solicitudes del cliente. Se
describirán a continuación por medio de un diagrama de casos de uso, (ver figura 3.5) el
comportamiento general del módulo de área administrativa.
Recibir información
Atención del
Cliente cliente Operador del área administrativa
Figura 2: Diagrama de caso de uso – módulo de área administrativa
figura 2.
Tabla 3: Caso de uso 2.1 - Recibir información

Descripción Al ingreso del menú principal del sistema IVR, el cliente recibirá un mensaje audible
de bienvenida e información sobre el digito de opción de comunicación directa con
el área administrativa. Posterior a la entrega de información del servicio, se
presentará las opciones restantes del menú IVR
Actores Cliente
Precondiciones El cliente deberá de estar en línea para poder escuchar los mensajes audibles del
sistema IVR
Secuencia normal de Paso Acción
eventos
2 El cliente escuchará como menú el digito de opción que le dirigirá a la
transferencia de la llamada a un operador del área admirativa
3 Se transfiere la llamada a un operador del área administrativa
Postcondición No aplica, puesto el cliente solamente recibirá información y solo escuchara las
opciones de un menú
informará que la opción seleccionada no es valida
2 Si existiesen tres intentos erróneos de elección de alguna opción del menú,
el cliente recibirá un mensaje de despedida y se concluirá la llamada.
Tabla 4: Caso de uso 2.2 – Atención al cliente
CU – 2.2 Atención al cliente

Descripción Una vez realizada la transferencia automática de la llamada al área administrativa, un
operador atenderá la llamada realizada, brindará información respecto a la gestión de
papeleo y aspectos burocráticos para la realización de transacciones o negocios con la
empresa Inova Networks.
Actores Cliente, Operador del área administrativa
Precondiciones Para que se posibilite el contacto directo del cliente con un agente del área de ventas,
el cliente deberá de discar la opción del menú principal para el contacto con el área
administrativa.
de eventos
1 El cliente elegirá la opción de contacto con el área administrativa
2 Se transferirá automáticamente la llamada a un operador del área
administrativa
3 Se entablara una conversación entre el cliente y el operador del área
administrativa
Postcondición Se entregará por parte del operador, información detallada respecto a la
administración de las compras, ventas, aspectos burocráticos y temas referentes a
papeleos.
Subsistema de alerta de desabastecimiento

El subsistema de alertas ente desabastecimiento de productos, cumplirá la función de mantener
informado a un grupo de usuarios autorizados, sobre el almacenaje de los distintos productos que
tengan un stock mínimo pertenecientes a la empresa Inova Networks, a fin de controlar y posibilitar una
rápida toma de decisiones ante tal situación, evitando principalmente el desabastecimiento de
productos en almacén.
Este subsistema tendrá un comportamiento autónomo, siendo que estará en constante funcionamiento
buscando posibles productos con stock mínimo, para así de forma inmediata se informe a los usuarios
sobre dicho desabastecimiento
Se describirán a continuación por medio de un diagrama de casos de uso, (ver figura 3) el

comportamiento general del subsistema de alertas de desabastecimiento.
Valida usuario
Verificar stock
minimo
«uses»
Recibe informacion
Gestor de alertas
Usuario de desabastecimiento
Entrega
información de consulta
Figura 3: Diagrama de caso de uso – subsistema de alertas de desabastecimiento
figura 3.
Tabla 5: Caso de uso 4.1 - Valida usuario
CU – 4.1 Valida usuario

Descripción Una vez entablada la comunicación entre el usuario y el gestor de alertas de
desabastecimiento, se verifica la validez de la contraseña de usuario requerida por el
sistema, buscando si este se encuentra registrado en la base de datos de Inova
Networks y además se verifica si está autorizado a recibir información sobre el
desabastecimiento de productos.
Actores Usuario, Gestor de alertas
Precondiciones Debe de existir una comunicación en línea entre el usuario y el PBX Asterisk a fin de
obtener los tonos DTMF que representan la contraseña del usuario llamante y
posteriormente ser validado
de eventos
1a Se realiza una llamada automática al usuario autorizado una vez que se
constate la existencia de productos con stock mínimo
1b El cliente realiza una llamada a la extensión que le permitirá recabar
información sobre los productos desabastecidos
2 Se obtiene y almacena en una variable la contraseña ingresada por el usuario
3 Se verifica la validez de la contraseña del usuario llamante o del usuario al que
se le llama automáticamente
Postcondición Se verificara la valides y autorización del usuario respecto al acceso a la información
de productos con stock mínimo
1 Si la contraseña de usuario obtenido no está registrado y autorizado en la
base de datos, el usuario recibirá un mensaje de no autorización, un mensaje
de despedida y se concluirá la llamada.
Tabla 6: Caso de uso 4.2 - Verificar stock mínimo
CU – 4.2 Verificar stock mínimo

Descripción Una vez validado el usuario y verificado los privilegios para la recepción de la
información sobre desabastecimiento, se obtiene un conteo de los productos que
tengan un stock mínimo en base a consultar directa a la base de datos del sistema
web de control y gestión de almacenes de Inova Netwoks. Una vez que se conoce la
cantidad de productos, se informa al usuario sobre la existencia o no existencia de
desabastecimientos.
Actores Usuario, Gestor de alertas
Precondiciones El usuario debe de contar con los privilegios necesarios para poder acceder a la
información de productos desabastecidos.
La base de datos del sistema web de control y gestión de almacenes de Inova Netwoks
deberá de estar disponible y deberá de aceptar conexiones remotas para la
realización de consultas.
de eventos
1 Entablar una conexión remota con la base de datos del sistema web de control
y gestión de almacenes de Inova Netwoks
2 Obtener la cantidad de productos que tengan un stock menor o igual al
mínimo permitido por la empresa Inova Networks
Postcondición Dependiendo de la cantidad de productos con stock mínimo obtenidos a raíz de la
consulta a la base de datos del sistema web de almacenes de Inova Netwoks, se
emitirá en formato audible, la cantidad de posibles productos con stock mínimo.
1 Si la cantidad de productos que tengan un stock menor al mínimo permitido
por la empresa Inova Networks es mayo estricto a cero, el usuario recibirá un
mensaje en el que se le informe sobre la cantidad de productos
desabastecidos.
2 Si no existieran productos con un stock mínimo, el usuario recibirá un mensaje
en el que se le informe que todos los productos esta con un stock aceptable y
mayor al mínimo permitido, seguidamente recibirá un mensaje de despedida y
se concluirá la llamada.
Tabla 7: Caso de uso 4.3 - Recibe información de desabastecimiento
CU – 4.3 Recibe información de desabastecimiento

Descripción Siempre y cuando la cantidad de productos obtenidos en CU – 4.2 sea mayor estricto
a cero, el usuario recibirá un mensaje audible sobre la cantidad de productos
desabastecidos, seguidamente escuchará un menú de opciones referente a las
consultas sobre los productos desabastecidos (con stock mínimo).
Estas opciones son: Consulta de id´s de productos desabastecidos, consulta de los
nombres de productos desabastecidos, envió de correo electrónico con el informe
detallado de los productos con stock mínimo.
Actores Usuario
Precondiciones Deberá de existir al menos un producto que tenga un stock menor al mínimo
permitido por la empresa Inova Netwoks.
de eventos
1 Se verifica la existencia de al menos un producto con stock mínimo.
2 El usuario recibe un mensaje en que se le informa la cantidad de productos
con stock mínimo
3 El usuario escuchará un menú de opciones que le permitirán obtener
información de los productos desabastecidos
4 El usuario digitara en su dispositivo telefónico el número de opción que dese
utilizar.
Postcondición En base a la opción elegida por el usuario, este obtendrá la información requerida en
forma audible, seguidamente el usuario escuchará nuevamente el menú de opciones.
1 Si el usuario elige la opción de consulta de id´s de productos desabastecidos,
inmediatamente escuchara un listado de los productos que tengan un stock
menor al mínimo permitido, el formato de esta lista será: el identificador del
primer producto seguido del stock actual del mismo, luego se dictara el
identificador del segundo producto seguido del stock actual del mismo y así de
esta forma hasta dictar todos los productos desabastecidos.
Una vez concluido el dictado de los productos el usuario escuchara
nuevamente el menú de opciones.
2 Si el usuario elige la opción de consulta de nombres de productos
desabastecidos, inmediatamente escuchará un listado de los productos que
tengan un stock menor al mínimo permitido, el formato de esta lista será: el
nombre del primer producto seguido del stock actual del mismo, luego se
dictará el nombre del segundo producto seguido del stock actual del mismo y
así de esta forma hasta dictar todos los productos desabastecidos.
3 Si el usuario elige la opción de envió de correo electrónico con el informe
detallado de los productos con stock mínimo, se enviará un correo electrónico
al correo asociado al usuario llamante. Este correo electrónico contendrá
adjuntado un informe detallado sobre los productos desabastecidos.
informará que la opción seleccionada no es válida.
5 Si existiesen tres intentos erróneos de elección de alguna opción del menú, el
cliente recibirá un mensaje de despedida y se concluirá la llamada.

Proyecto de Redes de Datos

Cargado por

Copyright:

Formatos disponibles

Proyecto de Redes de Datos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto de Redes de Datos

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

“CONSULTAS REMOTAS A UN SERVIDOR DE BASE DE DATOS

Para obtener el Título de Licenciatura en Informática

POR: CESAR NILTON ROJAS VALERO

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

A mi madre, que es un apoyo invaluable para mí, que

A mi madre y hermanos, por estar siempre dispuestos y prestos a colaborarme en todo lo

A mi Asesora Lic. Celia Elena Tarquino Peralta, por su disponibilidad y sugerencias en

ÍNDICE DEL CONTENIDO

1 MARCO PRELIMINAR ............................................................................... 1

Tabla 2.1: Requerimientos mínimos según los propósitos .......................................................... 22

El requerimiento de la información en tiempo real se ha convertido en una necesidad

Se concluye que el uso de la tecnología IVR, como mediador al acceso de información

Keywords: Remote queries, database, networks of telephony, interactive voice response

En el territorio boliviano, según la Autoridad de Transportes y Telecomunicaciones

La empresa Inova Networks se encontraba en la necesidad de acceder a la información

La obtención de información desde el sistema de control de almacenes, realizado a

En el presente proyecto se diseña e implementa un sistema IVR, el cual posibilita la

Para la elaboración del sistema IVR se utilizó la metodología sistémica, reconociendo

1.2.1 Antecedentes de la institución

Misión: Inova Networks es una institución comprometida con el desarrollo tecnológico

Visión: Ser una institución modelo tecnológicamente, haciendo constante y sostenible la

La forma en la que se accede a dichos reportes e información requerida del sistema es

1.2.2 Antecedentes del tema

Los sistemas IVR se utilizaron inicialmente en el ámbito bancario en la década de los

“Asterisk es una plataforma telefónica de código abierto (GPL) que pretende

A continuación se listarán algunas empresas en el territorio boliviano que utilizan el IVR

Unidad de proyectos especiales dependiente del ministerio de la presidencia, utiliza la

El servicio de información ciudadana en el ayuntamiento de Murcia – España le permite

A continuación se cita proyectos de grado y tesis consultada en distintas bibliotecas

Título: Diseño e implementación de un sistema interactivo de respuesta de voz

Título: Análisis, diseño y desarrollo de un sistema IVR para el módulo de ventas:

Título: Sistema Telefónico Automático para Consultas de Deudas y Fechas de

También se evidencia el problema de la no disponibilidad del personal en modo

Esta necesidad de obtención de la información del sistema web de almacenes en forma

1.4.1 Objetivo general

1.4.2 Objetivos específicos

 Analizar las tecnologías que posibiliten la conectividad entre un sistema IVR y un

1.5.1 Justificación económica

La conectividad al sistema web de control de almacenes por medio de las redes

1.5.2 Justificación tecnológica

1.6 Metodologías y herramientas

1.6.1 Recolección de datos e información

1.7 Alcance, límites y aportes

 Subsistema de consultas a almacén, proporcionará información específica de un

El acceso a la información de los productos registrados en el sistema web de almacenes

Es también un aporte tecnológico a la sociedad debido a la implementación de una

2.2 La telefonía tradicional

A continuación se desarrollará la descripción conceptual de los componentes y las

FIBRA OPTICA / SDH

PSTN / RTB CENTRO TELEFONICO CENTRO TELEFONICO

GSM / UMTS / 4G BRI

Figura 2.1: Arquitectura general de la telefonía tradicional

2.2.2 Sistemas digitales

2.2.2.1 Red Digital de Servicios Integrados