Diseño e Implementación de una Aplicación Android para la Configuración de una Central Asterisk

Texto completo

(1)Diseño e implementación de una aplicación Android para la configuración de una central Asterisk. Juan Carlos Carrillo Moreno Nelson Javier Pinzón López. Universidad Distrital Francisco José de Caldas Facultad de ingeniería Ingeniería de sistemas Bogotá D.C Abril de 2017.

(2) Diseño e implementación de una aplicación Android para la configuración de una central Asterisk. Juan Carlos Carrillo Moreno Nelson Javier Pinzón López. Proyecto de Grado en Calidad de Monografía para Obtener el Título de Ingenieros de Sistemas. Tutor Ing. Luis Felipe Wanumen Silva. Universidad Distrital Francisco José de Caldas Facultad de ingeniería Ingeniería de sistemas Bogotá D.C Abril de 2017.

(3) Tabla de Contenido. Tabla de Contenido ................................................................................................................. 4 Introducción ............................................................................................................................ 8 1. Organización, Definición y Análisis................................................................................... 9 1.1 Tema. ................................................................................................................................ 9 1.2 Titulo................................................................................................................................. 9 1.3 Objetivos .......................................................................................................................... 9 1.3.1 Objetivo general............................................................................................................. 9 1.3.2 Objetivos específicos ..................................................................................................... 9 1.4 Descripción del Problema .............................................................................................. 10 1.5 Pregunta de Investigación ............................................................................................... 11 1.6 Alcances y Limitaciones ................................................................................................. 11 1.6.1 Alcances....................................................................................................................... 11 1.6.2 Limitaciones ................................................................................................................ 12 1.7. Justificación ................................................................................................................... 12 1.8 Marco de Referencia ....................................................................................................... 13 1.8.1 Marco Histórico ........................................................................................................... 13 1.8.1. Marco Teórico ............................................................................................................ 15 1.8.1.1 Linux ......................................................................................................................... 15 1.8.1.2 VoIP .......................................................................................................................... 16 1.8.1.3Asterisk ...................................................................................................................... 17 1.8.1.4 Aplicaciones Móviles ............................................................................................... 18 1.8.1.5 SIP- Session Initiation Protocol ................................................................................ 19 1.8.1.6 RMI: Remote Method Invocation (Invocación de Método Remota)........................ 21 1.9 Marco Metodológico ...................................................................................................... 22 1.9.1 Definición del Sprint.................................................................................................... 23 1.9.2 Definición de roles....................................................................................................... 23 1.9.2.1 Team ......................................................................................................................... 23 1.9.2.2 Scrum Master ......................................................................................................... 23 1.9.2.3 Product Owner ....................................................................................................... 23.

(4) 1.9.3. Definición de las reuniones.................................................................................... 23. 1.9.5. Herramientas de Scrum .......................................................................................... 25. 1.10 Factibilidad ................................................................................................................... 25 1.10.1 Factibilidad Técnica................................................................................................... 25 1.10.1.1 Recurso Humano .................................................................................................... 25 1.10.1.2 Recurso de Hardware.............................................................................................. 26 1.10.1.3 Recursos Tecnológicos ........................................................................................... 26 1.10.2 Factibilidad Operativa ............................................................................................... 26 1.10.3 Factibilidad Legal ...................................................................................................... 27 1.10.4 Factibilidad Económica ............................................................................................. 27 1.11. Relación Beneficio Costo....................................................................................... 30. 1.12. Cronograma............................................................................................................ 33. 2. Requerimientos de la aplicación ....................................................................................... 35 3 Modelado de casos de uso ................................................................................................. 36 3.1 Actores ............................................................................................................................ 37 3.2 Casos de Uso................................................................................................................... 38 3.3 Especificación de casos de uso ....................................................................................... 39 3.4 Elegir plataforma y operación ........................................................................................ 40 3.5 Conectar Framework ...................................................................................................... 40 3.6 Ejecutar operación .......................................................................................................... 41 3.7 Enviar mensaje de texto .................................................................................................. 42 3.8 Modelo de casos de uso .................................................................................................. 42 3.9 Documentación de casos de uso ..................................................................................... 44 3.10 Diagrama De Clases ..................................................................................................... 55 4. Implementación ................................................................................................................ 57 4.1 Diseño físico de la red .................................................................................................... 57 4.2 Diseño lógico de la red ................................................................................................... 57 4.3 Opciones de ejecución de Asterisk ................................................................................. 58 4.5 Selección de Operación Asterisk .................................................................................... 59 4.6 Conectar Framework ...................................................................................................... 60 4.7 Ejecutar Operación ......................................................................................................... 60.

(5) 4.8 Enviar mensaje de texto .................................................................................................. 60 4.9 Descripción de la aplicación Servidor ............................................................................ 61 4.10 Descripción de la Implementación Aplicación móvil .................................................. 62 4.10.1 Integración de APIsAndroid en eclipse .................................................................... 66 4.10.2 Desarrollo de la aplicación móvil .............................................................................. 67 5 Conclusiones ..................................................................................................................... 69 6 Referencias ........................................................................................................................ 70.

(6) Lista de Tablas. Tabla 1. Recursos Tecnológicos ........................................................................................... 26 Tabla 2. Factibilidad Operativa ............................................................................................ 27 Tabla 3 Recursos Financieros ............................................................................................... 29 Tabla 4. Relación beneficio costo para una proyección de 5 años. ...................................... 32 Tabla 5. Lista de actores. ...................................................................................................... 37 Tabla 6. Lista de casos de uso .............................................................................................. 38 Tabla 7. Autenticar administrador. ....................................................................................... 44 Tabla 8. Elegir plataforma y operación. ............................................................................... 45 Tabla 9. Enviar datos. ........................................................................................................... 47 Tabla 10. Reenviar datos a framework ................................................................................. 48 Tabla 11. Conectar framework ............................................................................................. 50 Tabla 12. Ejecutar operación Asterisk. ................................................................................. 51 Tabla 13. Enviar mensaje de texto........................................................................................ 53 Tabla 14. Diseño lógico de la red. ........................................................................................ 57.

(7) Lista de Figuras. Figura 1. Actores del sistema................................................................................................ 37 Figura 2. Caso de uso para el acceso a la aplicación ............................................................ 39 Figura 3. Caso de uso para definir operación ....................................................................... 40 Figura 4. Caso de uso para la conexión del sistema móvil con Framework de telefonía. ... 41 Figura 5. Caso de uso para la ejecución de la operación Asterisk........................................ 41 Figura 6. Caso de uso para el envío de mensajes desde el dispositivo móvil. ...................... 42 Figura 7. Modelo general de casos de uso. ........................................................................... 43 Figura 8. Diagrama de clase de la aplicación. ...................................................................... 55 Figura 9. Diseño físico de la red ........................................................................................... 57 Figura 10. Configuración LAN del punto de acceso. ........................................................... 58 Figura 11. Configuración WIFI ............................................................................................ 58 Figura 12. Opciones Asterisk. .............................................................................................. 59 Figura 13. Estructura de paquetes aplicación servidor. ........................................................ 62 Figura 14. Paquetes de APIs necesarias para el proyecto. .................................................... 64 Figura 15. Paquetes extra necesarios para implementar el proyecto. ................................... 65 Figura 16. PluginAndroid para eclipse. ................................................................................ 66 Figura 17. Integración Android a eclipse. ............................................................................ 66 Figura 18. Configuración de propiedades para dispositivo virtual. ...................................... 67 Figura 19. Dispositivo Android virtual................................................................................. 68.

(8) 8. Introducción Desde el origen de los tiempos la necesidad de comunicación por parte de los seres humanos ha sido inherente, como se ha evidenciado a lo largo de la historia. Muestra de ello es el uso de diferentes tecnologías para transmitir mensajes e ideas, desde las antiguas pinturas rupestres (Sidar.org, s.f.) hasta llegar a los tiempos actuales, con ejemplos como la telefonía digital y análoga, así como los avances en la mensajería instantánea. Dentro de las necesidades de la sociedad, actualmente se contempla el tema de las comunicaciones como la posibilidad de interactuar en tiempo real con personas que se encuentran en diferentes partes del mundo. Además los individuos han incluido en todos los aspectos de su vida la capacidad de comunicación por diversos medios, que les permiten compartir contenidos, ideas, pensamientos según requieran. Por esto, las redes de telefonía se han convertido en pilares importantísimos para el funcionamiento de los procesos comunicativos, siendo consideradas por algunos como servicios básicos. En este contexto, y gracias a la actual presencia y facilidad de acceso de la telefonía móvil con respecto a su contraparte fija, es que comenzamos a depender de este servicio con mayor fuerza. En el presente proyecto se especifica el desarrollo de una aplicación para dispositivos móviles con sistema operativo Android que permite configurar una central Asterisk. Esta aplicación móvil es una herramienta que provee una interfaz de usuario para realizar modificaciones al Dialplan de Asterisk, de una manera más ágil y sencilla. Durante el desarrollo del proyecto se describen los objetivos planteados, definiendo alcances y limitaciones para dar solución a la problemática que se definirá más adelante en este documento..

(9) 9. 1. Organización, Definición y Análisis 1.1 Tema. Actualmente la telefonía IP, constituye una forma de convergencia en las redes, para enviar tráfico de voz y datos por un canal común. Permitiendo utilizar una misma infraestructura física, y evita adecuar accesorios adicionales para separar los tipos de tráfico. Una poderosa herramienta que ha sido implementada con éxito en muchas organizaciones para soluciones de telefonía IP es Asterisk, por su robusta unión de tecnologías de hardware y software. Una de las características más importantes de Asterisk es el estar libre de licencias, lo cual implica muchas ventajas con respecto a otras alternativas. En contraparte, muchos de sus procedimientos de configuración son llevados a cabo manualmente, haciendo más lentas las configuraciones de llamadas y el funcionamiento del sistema telefónico. Lograr la automatización de estos procesos, aumenta el desempeño de estos sistemas basados en Asterisk y permite mejorar los tiempos de respuesta de las operaciones. El tema central de éste proyecto, consiste en la automatización del dialplan Asterisk, por medio de dispositivos móviles. 1.2 Titulo. Diseño e implementación de una aplicación Android para la configuración de una central Asterisk. 1.3 Objetivos. 1.3.1 Objetivo general. Diseñar y construir una aplicación para dispositivos móviles Android con la cual se puede administrar automáticamente una central Asterisk, que brinde una interfaz de fácil uso para el usuario final. 1.3.2 Objetivos específicos Determinar los procesos y los protocolos que contendrá la aplicación para la configuración de una central Asterisk..

(10) 10. Diseñar una interfaz gráfica de fácil uso basada en los procesos y protocolos identificados. Construir la aplicación móvil a partir de un modelo de análisis y diseño para la administración de una central Asterisk. Realizar un análisis económico que permita determinarla viabilidad del proyecto.. 1.4 Descripción del Problema Uno de los problemas críticos, de la telefonía Asterisk, es la variedad de configuraciones y parámetros necesarios para establecer el dialplan, ya que su arquitectura permite esta flexibilidad. Si un administrador de red no configura los contextos, no queda activo el sistema telefónico. La configuración de contextos es una operación manual, de sintaxis compleja, basada en funciones de programación en el lenguaje C. Se utilizan patrones, caracteres especiales, expresiones regulares y direcciones IP. Es necesario para un administrador de red conocer a fondo la estructura de los contextos Asterisk. Aún con un conocimiento amplio del núcleo Asterisk, se está propenso a errores. Las operaciones manuales son lentas, ya que es necesario realizar reinicios consecutivos, para que los cambios tengan efecto. Es fácil modificar un contenido correcto, por equivocación. Toda la información del sistema de archivos de telefonía es crítica, cualquier cambio involuntario produce fallas severas en el sistema telefónico, puede detener parcial o totalmente la funcionalidad. La creación de líneas telefónicas, inclusión de nuevos usuarios, creación de dependencias, hace necesario modificar múltiples archivos de configuración. Al ser operaciones frecuentes en las organizaciones, la configuración de los módulos Asterisk es permanente, si se realiza manualmente. Esto requiere de intervención exclusiva y especializada del administrador de la red. Cuando se realiza la configuración de contextos Asterisk, se hace uso de comandos de Linux los cuales quedan registrados en un historial, lo que implica que la ejecución errónea de ellos, pueda incidir en fallas de configuración de contextos, como en los módulos sip.conf, extensions.conf y voicemail.conf, necesarios para la funcionalidad mínima del sistema telefónico. Cada procedimiento es potencialmente peligroso y permite que un usuario malintencionado, ejecute comandos de sistema que puedan causar una posible falla..

(11) 11. 1.5 Pregunta de Investigación ¿Es posible la reducción de las incidencias en los procesos de configuración y administración de la central Asterisk, por medio de la implementación de una aplicación móvil Android?. 1.6 Alcances y Limitaciones 1.6.1 Alcances Se configurará un servidor Asterisk en intranet, con alcance WiFi 802.11b/g hacia el dispositivo móvil, con dos líneas telefónicas habilitadas por medio de softphone en equipos de la red LAN. El proyecto incluye tres sistemas principales: 1 Sistema Móvil: Este módulo contendrá las opciones de configuración del dialplan Asterisk, en una aplicación Android. 2 Sistema Web: Este módulo recibe solicitudes desde la aplicación Android, vía WiFi, conecta el módulo Asterisk y posteriormente le envía las operaciones de configuración a ejecutar. 3 Sistema Envió de Mensajes: Este módulo se encargara de enviar mensajes a dispositivos móviles, cuando las llamadas no son atendidas en los teléfo no IPfijos, tendrá interoperabilidad entre el sistema móvil y el sistema web. 4 Modulo Asterisk: Este módulo es el núcleo Asterisk, que recibe las operaciones y por medio de la interfaz de línea de comandos ejecuta la configuración del dialplan, en los contextos: sip.conf extensions.conf voicemail.conf..

(12) 12. 1.6.2 Limitaciones La aplicación realiza configuraciones Asterisk de nivel LAN, para llamadas en intranet, el módulo WAN se reserva para futuras versiones de la aplicación. El tiempo estimado para la elaboración e implementación del proyecto son 6 meses. Limitación del acceso a la información, teniendo en cuenta que Asterisk no es un software popular por su compleja administración. El presupuesto del proyecto se limita a $ 36.540.000 de pesos. Los investigadores solo pueden dedicar 3 días a la semana a la investigación. La seguridad del proyecto está limitada a la seguridad establecida por Asterisk.. 1.7. Justificación Es preciso implementar una aplicación que permita a utomatizar la configuración del dialplan Asterisk, para dar solución al problema planteado, ya que permite lidiar con una gran cantidad de operaciones y parámetros necesarios para definir el comportamiento de las llamadas. Al brindar un entorno visual sencillo le facilita la administración del sistema Asterisk al usuario, así mismo, las tareas de configuración son realizadas por un servicio web, que no requiere un conocimiento profundo, de la sintaxis de comandos, expresiones regulares, patrones ni direccionamiento IP, para la definición de contextos. Esto significa que la presencia del administrador de la red, no es indispensable y otras personas sin el conocimiento profundo, pueden realizar el trabajo desde la aplicación. Los procesos de configuración, son realizados rápidamente, utilizando dispositivos móviles para automatizar el proceso. Lo que implica ahorro de tiempo, cada vez más considerable, en la medida que se habiliten nuevas extensiones para otros usuarios. Con esto, también se evitan los errores de digitación manual o modificación de archivos críticos para el buen funcionamiento de la telefonía IP. La aplicación móvil, facilita la ejecución de las operaciones, no es necesario acceder al servidor, para ejecutar configuraciones críticas, que puedan alterar otros procesos. Y es posible ejecutar las operaciones dentro del alcance que permita la red WiFi de la organización. Además, al realizar una llamada a una extensión, si la llamada no es atendida, ante esta situación, la aplicación enviará un mensaje al dispositivo móvil del responsable de la extensión telefónica, para informar acerca de la llamada. Así cada mensaje de urgencia, tiene la recepción adecuada, en el tiempo propicio..

(13) 13. 1.8 Marco de Referencia. 1.8.1 Marco Histórico. Para este proyecto usaremos como guía implementaciones realizadas en diferentes áreas  Caso práctico de la implantación de un sistema de Telefonía VoIP en una empresa Este sistema desarrollado en el año 2009, en la Escuela Técnica superior de Ingeniería informática, logra destacar la comprensión de los protocolos que se utilizan para transmitir la voz a través de la red IP y los destinados a complementarlos en aspectos relacionados con la seguridad, señalización y calidad del servicio. El funcionamiento de las redes de telefonía clásica y la forma de interactuar con ellas, el dominio de sistemas informáticos para el correcto funcionamiento de las aplicaciones (Luengo, 2009). A través de este trabajo se proporciona una guía para que una persona con unos conocimientos medios en las tecnologías de información se pueda iniciar en la telefonía IP. Así, mediante la síntesis de las principales tecnologías implicadas en la VoIP y la inclusión de numerosos ejemplos, el proceso de aprendizaje resulta mucho más liviano. El hecho de incluir un caso práctico, explicando con todo detalle y de forma didáctica la implantación de un sistema de comunicaciones VoIP en una empresa, brinda la posibilidad de descubrir en un contexto real las bondades que ofrece la telefonía de código abierto así como los problemas a los que hay que enfrentarse al utilizarla..  Asterisk y Telefonía Tradicional. Este proyecto, desarrollado en el año 2006, consistió en el estudio e implementación de un sistema de Telefonía IP, manteniendo la potencialidad de un PBX IP tradicional. Además de aprovechar las características propias que nos presenta un sistema de telefonía IP basado en GNU/Linux. (González, 2006). En la década de los 70s, ya existía la red telefónica. Está en un principio simplemente consistía en líneas conectadas a un concentrador o también llamado conmutador (Central). Cada Central solo proporcionaba servicio a los usuarios que estaban conectados a esta. En realidad cada Central estaba aislada de las demás existentes en otras zonas, ciudades o regiones. Fue entonces que se empezó a observar que la forma más eficiente de extender la distancia que podía cubrir una llamada telefónica era simplemente conectando las Centrales existentes. Esto también incremento.

(14) 14. enormemente las posibilidades de enrutamiento de una llamada; fue entonces que realmente nació la primera red telefónica. Hoy en día esa red es conocida como la Red Telefónica Publica Conmutada (RTPC) o en ingles PSTN..  Estudio y diseño de una red de telefonía de voz sobre IP para plataforma siglo XXI Esta investigación fue realizada en el Año 2007, en Colombia; Universidad de Pamplona. Las comunicaciones han tenido una evolución bastante acelerada en las últimas décadas, es un avance exitoso para toda la humanidad, ahora mismo las comunicaciones mueven en si todas las empresas y es una herramienta indispensable para la evolución, el sostenimiento y la producción de estas. Una de las tecnologías que está minimizando costo y es una ventaja para cualquier institución es la telefonía IP. Este trabajo trata del diseño de la red para la empresa Plataforma Siglo XXI, así como de las características de los dispositivos que se utilizan, los elementos que se necesitan para el diseño de la misma. En el proyecto de diseño de la red de telefonía IP se incluyen los diferentes tipos de protocolos de señalización para la realización de una llamada con sus ventajas y desventajas a su vez se escoge el protocolo que más se acople a este diseño (Gómez, 2007). En las últimas décadas la telefonía ha prestado un gran servicio a todas las comunidades, empresas y demás; la telefonía por hilos o telefonía básica ha hecho un gran aporte a la tecnología para las comunicaciones, se puede decir que es el pilar de todas ellas como lo es para la telefonía móvil, satelital y ahora para la telefonía IP, el sistema de comunicación analógica o la red de circuitos integrados a medida de los años está perdiendo adeptos por los servicios que ofrece y otros tipos de comunicación han ganado ventaja..  Creación de una Central Telefónica a través del Módulo Asterisk-Ubuntu Esta Investigación fue realizada en el año 2007, en la Universidad Austral de Chile. La presente tesis está enfocada principalmente a descubrir el cambio que se realizara en las telecomunicaciones en el futuro, con una visión practica de cómo es la transmisión de telefonía que está emergiendo y desplazara a la telefonía actual, en la parte práctica consiste en la instalación de una central de telefo nía y analizar cómo se transmite la información de voz a través de paquetes IP. Este proyecto está enfocado a Ingenieros.

(15) 15. electrónicos e ingenieros informáticos, que quieran aprender a desarrollar esta tecnología e implementarla en forma práctica en cualquier parte que se desee, este proyecto tiene una enorme importancia en conectividad ya que se une a través de Internet redes de telefonía, por lo que podemos llegar a cualquier parte que se desee y este bien implementada una red ya sea alambica e inalámbrica (Urtubia, 2007). La utilización de una red ya existente da pie a la maximización de los recursos de esta red, la red IP, por esto nace la implementación de esta telefonía y con esto se abaratan costos y se otorgan mayores prestaciones a la telefonía convencional.. 1.8.1. Marco Teórico. 1.8.1.1 Linux GNU/Linux es el primer sistema operativo basado en UNIX que es 100% Software Libre. Si bien anteriormente había otros sistemas operativos de libre distribución (como MINIX), éstos no eran totalmente Software Libre, ya que eran regidos por licencias más restrictivas. GNU/Linux es un proyecto con muy fuertes cimientos, El sistema ha sido diseñado y programado por multitud de programadores alrededor del mundo. El núcleo del sistema sigue en continuo desarrollo bajo la coordinación de Linus Torvalds, la persona de la que partió la idea de este proyecto, en 1991(Linux-es.org, 2014).Es prácticamente imposible parar un proyecto de estas magnitudes. Hablando técnicamente, GNU/Linux es un sistema operativo de software libre basado en UNIX, que cumple las normas POSIX. Su base es un núcleo monolítico llamado Linux (a secas), desarrollado originalmente por Linus Torvalds a principios de la década de los noventa. Su estructura general es la típica de cualquier sistema UNIX (núcleo – intérprete de comandos – aplicaciones), aunque actualmente debe de ser el más desarrollado de ellos. Cuenta con una interfaz gráfica llamada Xfree86 (versión libre del sistema de ventanas Xwindow original del MIT) y con muchas aplicaciones para realizar las más diversas tareas, desde procesamiento de textos hasta montaje de servidores de red, pasando por aplicaciones multimedia y juegos. Paralelamente con el desarrollo de este sistema operativo, surgió la Fundación del Software Libre, la cual fomenta, entre otras cosas, la utilización de herramientas de Software Libre en las computadoras de todo el mundo..

(16) 16. Como afirma Héctor F. Arena (2003) cuando se habla de libertad, del software lo hacemos en el sentido más filosófico de la palabra. Hablamos de la libertad de tener un programa incluyendo su código fuente, la libertad de usarlo, copiarlo, modificarlo, y además poder compartirlo con otros. Ése es el espíritu del sistema GNU/Linux (p. 21). El software libre presenta una innumerable cantidad de ventajas para el desarrollador frente a otros sistemas desarrollados bajo modelos cerrados. La primera y principal ventaja es que el desarrollador obtendrá ayuda de parte de personas que quizá ni siquiera conoce, gracias a la gran red de redes. La segunda ventaja es que su proyecto crecerá mucho más rápido que antes gracias a la cantidad de colaboradores que quieran sumarse a la causa (siempre que ésta sea buena). 1.8.1.2 VoIP VoIP intenta permitir que la voz viaje en paquetes IP y a través de Internet. El concepto de recepción de un paquete en el instante que el remitente quiere que sea recibido es complejo. De hecho, la construcción de una red para ejecutar VoIP e s compleja (Davidson, Peters y Gracely, 2000). Sin embargo la telefonía IP conjuga dos mundos históricamente separados: la transmisión de voz y la de datos. Se trata de transportar la voz, previamente convertida a datos, entre dos puntos distantes. Esto posibilita utilizar las redes de datos para efectuar las llamadas telefónicas, y desarrollar una única red convergente que se encargue de cursar todo tipo de comunicación, ya sea voz, datos, video o cualquier tipo de información. La voz IP, por lo tanto, no es en sí mismo un servicio, sino una tecnología que permite encapsular la voz en paquetes para poder ser transportados sobre redes de datos sin necesidad de disponer de los circuitos conmutados convencionales PSTN, las redes desarrolladas a lo largo de los años para transmitir las conversaciones vocales, se basaban en el concepto de conmutación de circuitos, o sea, la realización de una comunicación que requiere el establecimiento de un circuito físico durante el tiempo que dura ésta, lo que significa que los recursos que intervienen en la realización de una llamada no pueden ser utilizados en otra hasta que la primera no finalice, incluso durante los silencios que se suceden, dentro de una conversación típica. En cambio, la telefonía IP no utiliza circuitos para la conversación, sino que envía múltiples de ellas (conversaciones) a través del mismo canal, codificadas en paquetes y flujos independientes. Cuando se produce un silencio en una conversación, los paquetes de datos de otras conversaciones pueden ser transmitidos por la red, lo que implica un uso más eficiente de la misma. Según esto son evidentes las ventajas que proporciona el segundo tipo de red, ya que con la misma infraestructura podrían prestar más servicios, la calidad de servicio y la.

(17) 17. velocidad serían mayores; pero existe la desventaja de la seguridad, ya que no es posible determinar la duración del paquete dentro de la red, hasta que este llegue a su destino y además existe la posibilidad de pérdida de paquetes, ya que el protocolo IP no cuenta con esta herramienta. 1.8.1.3Asterisk Asterisk es un software PBX que usa el concepto de software libre (GPL). Digium, empresa que promueve el Asterisk, invierte en ambos aspectos, el desenvolvimiento de código fuente y en hardware de telefonía de bajo costo que funciona con Asterisk. “El Asterisk corre en plataforma Linux y otras plataformas Unix con o sin hardware conectado a la red pública de telefonía, PSTN (Public Service Telephony Network)” (Goncalves, Flavio.2007. P. 11). El Asterisk permite conectividad en tiempo real entre las redes PSTN y redes VoIP.. Con Asterisk en la red, se pueden crear actividades como: Conectar empleados trabajando desde casa para un PBX de la oficina sobre conexiones de banda ancha. Conectar oficinas en varias provincias sobre IP. Esto puede ser hecho por internet o por una red IP privada. Construir aplicaciones de repuesta automática por voz, que puede conectarlo a un sistema de pedidos, por ejemplo, o a otras aplicaciones internas. Asterisk incluye muchos recursos que sólo eran encontrados en sistemas de mensajería unificada, como: Música en espera para clientes en fila de espera, soportando streaming de media así como música en MP3. Filas de llamada donde agentes de forma conjunta atienden las llamadas y monitorean dicha fila. Integración para sintetización de la conversación. Registro detallado de llamadas para integración con sistemas de tarificación. Integración con reconocimiento de voz. Con el nacimiento de Asterisk surge una revolución: Ya que este concepto fue revolucionario, y hacía muchas ondas en la industria, yo decidí después nombrar la tecnología y organización como el famoso revolucionario mexicano Emiliano Zapata. Decidí llamar a la tarjeta de hardware, la “tormenta ” (Dixon, 2009)..

(18) 18. 1.8.1.4 Aplicaciones Móviles Las aplicaciones móviles se han definido como los conjuntos de instrucciones lógicas, procedimientos, reglas, documentación, datos e información asociada a estas que funcionan específicamente en dispositivos móviles, como por ejemplo teléfonos inteligentes, televisores inteligentes, tabletas, reloj, entre otros(UNAD, 2012). Están desarrolladas en su mayor parte en las principales plataformas existentes IOS y Android, lo cual tendrá una incidencia en la demanda por servicios de desarrollo y testeo de parte de las distintas empresas que buscan consolidar un posicionamiento competitivo en la industria. Constantemente se realizan revisiones y actualizaciones de los principales sistemas operativos para asegurar la compatibilidad de los dispositivos móviles con la usabilidad esperada de parte de los usuarios, es por ello que constantemente surgen nuevas aplicaciones que sustituyen distintos servicios disponibles en otros medios, como: banca comercial, software corporativo, software operacional, juegos, aplicaciones de productividad, entre otros. La incorporación de nuevas tecnologías en los dispositivos móviles ha permitido una mayor versatilidad de uso en cuanto a las prestaciones ofrecidas por las aplicaciones, si en un inicio el foco de atención se fijaba en mensajería instantánea, en la actualidad el espectro de usabilidad se ha expandido a tal punto que los usuarios pueden utilizar sus celulares o tabletas como terminales de software de CRM(Customer Relationship Management), procesadores de texto, administración de planillas e inventarios, editores de contenido audiovisual, y para funciones de administración de red. Lo anterior implica un incremento en el nivel de complejidad en los procesos de desarrollo y programación. En vista de lo anterior, es posible corroborar que a medida que el foco de interés de los usuarios se vuelve cada vez más específico el número de aplicaciones disponibles en el mercado se incrementa de manera significativa cada año, así también la cantidad de descargas y utilización de distintas plataformas de distribución de software. En otros términos, “durante 2008 se registraron alrededor de 530 millones de descargas, 3.590 millones en 2009, 6.610 millones en 2010, 9.880 millones en 2011, 13.250 millones en 2012, en 2013 se contabilizaron más de 16.210 millones solo en el primer semestre. ” ("World Mobile ApplicationsMarket Worth US$25 Billionby 2015", 2016) Esto referencia las aplicaciones gratuitas y de pago sin contemplar juegos..

(19) 19. 1.8.1.5 SIP- Session Initiation Protocol. Es un protocolo de control y señalización usado mayoritariamente en los sistemas de Telefonía IP, que fue desarrollado por el IETF (RFC 3261). Dicho protocolo permite crear, modificar y finalizar sesiones multimedia con uno o más participantes y sus mayores ventajas recaen en su simplicidad y consistencia. Hasta la fecha, existían múltiples protocolos de señalización tales como el H.323 de la ITU, el SCCP de Cisco, o el MGCP, pero parece que poco a poco SIP está ganando la batalla del estándar: Cisco está progresivamente adoptando SIP como protocolo en sus sistemas de telefonía IP en detrimento de H.323 y SCCP, Microsoft ha elegido SIP como protocolo para su nuevo OCS (Office Communication Server), y los operadores (de móvil y fijo) también están implantando SIP dentro de su estrategia de convergencia, aprovechando de este modo la escalabilidad e interoperabilidad que nos proporciona el protocolo SIP.. Funciones SIP El protocolo SIP actúa de forma transparente, permitiendo el mapeo de nombres y la redirección de servicios ofreciendo así la implementación de la IN (Intelligent Network) de la PSTN o RTC. Para conseguir los servicios de la IN el protocolo SIP dispone de distintas funciones. A continuación se enumeran las más importantes: Localización de usuarios (SIP proporciona soporte para la movilidad). Capacidades de usuario (SIP permite la negociación de parámetros). Disponibilidad del usuario Establecimiento y mantenimiento de una sesión. En definitiva, el protocolo SIP permite la interacción entre dispositivos, cosa que se consigue con distintos tipos de mensajes propios del protocolo que abarca esta sección. Dichos mensajes proporcionan capacidades para registrar y/o invitar un usuario a una sesión, negociar los parámetros de una sesión, establecer una comunicación entre dos a más dispositivos y, por último, finalizar sesiones. Beneficios del protocolo SIP frente otros protocolos En la actualidad, los protocolos más usados en ToIP son tres: SIP, H.323 y IAX2..

(20) 20. H.323 es un estándar de la ITU que provee especificaciones para ordenadores, sistemas y servicios multimedia por redes que no proveen QoS (calidad de servicio). Como principales características de H.323 tenemos: Implementa QoS de forma interna. Control de conferencias IAX2 (Inter Asterisk eXchange) es un protocolo creado y estandarizado por Asterisk. Unas de sus principales características son: Media y señalización viajan en el mismo flujo de datos. Trunking Cifrado de datos Una de las ventajas de este protocolo es que al enviar el “streaming” y la señalización por el mismo flujo de datos, se evitan problemas derivados del NAT. Así pues, no es necesario abrir rangos de puertos para el tráfico RTP. Por último, IAX2 nos permite hacer trunking de forma que podemos enviar varias conversaciones por el mismo flujo, lo cual supone un importante ahorro de ancho de banda. Finalmente, veamos qué hace de SIP un protocolo cada día más sólido. Aspectos importantes referentes a dicho protocolo se enumeran como sigue: El control de llamadas es stateless o sin estado, y proporciona escalabilidad entre los dispositivos telefónicos y los servidores. SIP necesita menos ciclos de CPU para generar mensajes de señalización de forma que un servidor podrá manejar más transacciones. Una llamada SIP es independiente de la existencia de una conexión en la capa de transporte. SIP soporta autentificación de llamante y llamado mediante mecanismos HTTP. Autenticación, criptográfica y encriptación son soportados salto a salto por SSL/TSL pero SIP puede usar cualquier capa de transporte o cualquier mecanismo de seguridad de HTTP, como SSH o S-HTTP. Un proxy SIP puede controlar la señalización de la llamada y puede bifurcar a cualquier número de dispositivos simultáneamente. En definitiva, vemos que SIP es un protocolo con una gran escalabilidad, modular y muy apto para convertirse en el futuro inmediato de la ToIP..

(21) 21. Arquitectura SIP El estándar define varios componentes SIP y hay varias formas de implementarlos en un sistema de control de llamadas. servidores User Agent, Proxies Registrars, Redirect Location. A menudo, estos elementos son entidades lógicas que se ubican todas juntas para conseguir una mayor velocidad de procesamiento que dependerá a su vez de una buena configuración.. 1.8.1.6 RMI: Remote Method Invocation (Invocación de Método Remota) Es un protocolo propietario de Java que permite que métodos de objetos que existen en una máquina virtual puedan ser invocados desde otros objetos en otra máquina virtual, probablemente en un host distinto. RMI sólo permite la comunicación entre tecnología Java. Si se requiere comunicar con otras tecnologías debe usarse CORBA o SOAP. Al estar específicamente diseñado para Java, RMI puede darse el lujo de ser muy amigable para los programadores, proveyendo pasaje por referencia de objetos (cosa que no hace SOAP), "recolección de basura" distribuida y pasaje de tipos arbitrarios (funcionalidad no provista por CORBA). Por medio de RMI un programa puede hacer disponible un objeto en la red. Otro programa entonces podría invocar métodos de dicho objeto como si invocara métodos de objetos propios, de un modo transparente al programador, sin tener que lidiar con sockets de bajo nivel. Cuando un programador invoca un método de un objeto remoto, los parámetros son serializados (convertidos en un flujo de bytes capaz de ser enviados a través de un socket). Luego se envían a través de la red, mientras que el método que hizo la invocación queda esperando. El método remoto realiza el procesamiento, serializa el valor de retorno y se lo devuelve al llamador. Esto implica que el pasaje de parámetros que no tienen interfaz remota definida (objetos no remotos), cuando se trata de métodos remotos, es por copia..

(22) 22. Por este motivo se requiere que los parámetros del método remoto y del dato que retorna sean de clases que se puedan serializar (en Java, que implementen la interfaz "Serializable"). El encargado de hacer públicos los objetos remotos es el registro RMI. Se trata de un servicio, cuyo puerto TCP por defecto es el 1099 (aunque es posible elegir otro), que mantiene información acerca de los objetos exportados y sus correspondientes direcciones. El servidor debe registrar en él sus objetos remotos mediante el método "Naming.bind ("dirección", objeto)" y el cliente debe solicitarlos llamando a "Naming.lookup ("dirección")".. 1.9 Marco Metodológico. La metodología que mejor se acomoda a las necesidades para el desarrollo del proyecto es SCRUM ya que se realizan entregas parciales y regulares del producto final, cuyo enfoque esta guiado a obtener resultados prontamente, de esta manera se puede conocer el estado del proyecto mediante la experiencia que se adquiere en cada entrega. La metodología SCRUM es basada en sprints, que son iteraciones realizadas por el grupo de trabajo dentro de un lapso previamente establecido, que permite entregar avances incrementales del proyecto. Roles: Scrum Master Team Product Owner Reuniones: Sprint planning Sprint review Sprint retrospective Daily scrum Artefactos Product backlog Sprint backlog.

(23) 23. 1.9.1 Definición del Sprint. Se definieron los tiempos requeridos para la culminación del proyecto, en este caso se acordó que la duración de cada Sprint será de 12 días, y que la duración de la totalidad del proyecto incluirá 8 Sprints y una fase de configuración SCRUM donde se definirá el plan de trabajo para el proyecto (Ver cronograma).. 1.9.2 Definición de roles. 1.9.2.1 Team Para realizar el proyecto se cuenta con el equipo de trabajo conformado por Juan Carlos Carrillo Moreno y Nelson Javier Pinzón López, quienes presentaran adelantos del proyecto de forma iterativa e incremental; bajo la asesoría y retroalimentaciones del Ingeniero Luis Felipe Wanumen Silva. El grupo de trabajo esta concientizado de las responsabilidades individuales que poseen durante el desarrollo de todo el proyecto. La multifuncionalidad de los integrantes del equipo de trabajo será vital para lograr los objetivos definidos.. 1.9.2.2 Scrum Master Por lo reducido del equipo de trabajo se ha definido que el Scrum Master por su experiencia y conocimiento será el Ingeniero Luis Felipe Wanumen Silva. 1.9.2.3 Product Owner El rol de Product Owner no está definido para este proyecto por el tamaño del mismo.. 1.9.3. Definición de las reuniones. 1.9.3.1 Daily scrum Estas son reuniones que se efectúan a diario, es en donde el equipo se entera del estado del proyecto esta reunión tiene unas características especiales como lo son: La reunión comienza puntualmente a su hora. Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar..

(24) 24. La reunión tiene una duración máxima de 15 minutos. La reunión debe realizarse en el mismo sitio y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas: ¿Qué se hizo ayer?, ¿Qué se hará hoy? y ¿Qué impedimentos tienen? (Es papel del Scrum Master recolectar estos impedimentos).. 1.9.3.2 Sprint planning El Sprint planing se realiza al inicio de cada ciclo de Sprint, en esta reunión se selecciona el trabajo se hará, además de preparar con el equipo el Sprint Backlog. Se estima cuánto del trabajo se puede realizar durante el Sprint.. 1.9.3.3 Sprint review Esta reunión tiene un tiempo máximo de 3 horas en donde se realiza una demostración del producto, la idea es que en cada presentación se demuestren nuevas funcionalidades en esta reunión participa todo el equipo y las funcionalidades no implementadas no se presentan.. 1.9.3.4 Sprint retrospective Al finalizar de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual el Team deja sus opiniones, se responden las preguntas ¿qué fue lo bueno del sprint? y ¿Qué se puede mejorar? El propósito de la retrospectiva es realizar una mejora continua del proceso.. 1.9.4. Definición de artefactos. 1.9.4.1 Product backlog Es una lista priorizada de requerimientos (el Qué) definidos en un alto nivel y priorizado por el Product Owner también es repriorizada al inicio de cada Sprint manteniéndose durante todo el ciclo de vida..

(25) 25. 1.9.4.2 Sprint backlog Es un subconjunto del Product Backlog son los requerimientos detallados a más bajo nivel (el Cómo), en el están definidas las tareas a realizar por requerimiento pero no son asignadas, el equipo elige las tareas a realizar y cualquier miembro del equipo puede tomar tareas del Sprint Backlog.. 1.9.5. Herramientas de Scrum. Una de las herramientas utilizadas dentro de la metodología Scrum son las historias de usuario, que son la especificación de un requerimiento donde se proporciona información sobre el comportamiento que debe tener dentro de la aplicación. Para dar un control sobre las tareas a realizar por parte de los integrantes del grupo de trabajo, se establecerá un panel de tareas divido en tres columnas que simbolizan los estados de cada tarea: por hacer, haciendo y terminado. Se deben realizar pruebas de cada una de las tareas de desarrollo terminadas, validando que se hayan solucionado completamente los requerimientos definidos en cada reunión para cada sprint.. 1.10 Factibilidad 1.10.1 Factibilidad Técnica 1.10.1.1 Recurso Humano El proyecto será desarrollado por los estudiantes de la Universidad Distrital Francisco José de Caldas del proyecto Curricular en Ingeniería de Sistemas, Juan Carlos Carrillo Moreno y Nelson Javier Pinzón López, contando con la colaboración y asesoría del Ingeniero Luis Felipe Wanumen Silva. Este es un proyecto viable operativamente porque cuenta con los recursos Humanos necesarios para llevarlo a cabo..

(26) 26. 1.10.1.2 Recurso de Hardware Para el desarrollo del sistema se cuenta con un equipo, el cual posee un procesador Pentium Dual Core 2.6 GHz, disco duro de 300Gb y memoria de 4Gigas, ya que el proyecto exige un equipo con buena capacidad de procesamiento. 1.10.1.3 Recursos Tecnológicos La siguiente tabla indica los recursos tecnológicos necesarios.. Tabla 1. Recursos Tecnológicos Recursos Servidor Linux. Debian-7.5.0-i386-netinst Tarjeta de Telefonía Ip Tarjeta de Red Inalámbrica IDE Netbeans Mysql Dispositivo Móvil que soporte aplicaciones Java MIDP 2.0, CLCD 1.0. Características Disco duro de 300 GB, 4 GB de Memoria RAM, procesador Intel Dual Core de 2.6 GHz. Sistema operativo de 32 bits. TDM410P / 2FXO 2FXS Tarjeta de Red Ethernet 802.11 Versión 6.9.1 Sistema manejador de base de datos Mínimo Android 4.0. Tipo de Recurso Hardware. Software Hardware Hardware. Software Software. Hardware. De acuerdo a los recursos mencionados el proyecto es factible técnicamente ya que se cuenta con los recursos de hardware y de software para el desarrollo de este.. 1.10.2 Factibilidad Operativa El proyecto requiere de un asesor, el director del proyecto; así como un administrador de red y un desarrollador de software (Ver tabla 2)..

(27) 27. Tabla 2. Factibilidad Operativa Función. Persona Encargada. Director Proyecto. Luis Felipe Wanumen Silva. Desarrollador de Software. Juan Carlos Carrillo Moreno. Administrador de Red. Nelson Javier Pinzón López. De acuerdo al grupo de trabajo mencionado el proyecto es factible operativamente ya que los encargados de desarrollar e implementar la aplicación móvil, cuentan con los conocimientos apropiados para realizar dicha labor, siendo estudiantes de ingeniería de sistemas de la Universidad Francisco José de Caldas, conocen los temas relacio nados que dan solución a la problemática establecida. 1.10.3 Factibilidad Legal Las herramientas de desarrollo utilizadas en este proyecto son de licencia libre. Existe una licencia GPL Versión 3.0 que permite la modificación de código por parte de terceros, pero determina que cualquier desarrollo que se haga sobre el código desarrollado debe seguir siendo de código abierto. 1.10.4 Factibilidad Económica Para determinar el presupuesto con que se debe contar para la realización del proyecto se efectuaron los siguientes cálculos:. Tiempo de uso del PC = 6 MESES TUPC = Tiempo de uso del PC TUPC = (6 MESES) *(4 Semanas mensuales) TUPC = 24 semanas TUPC = (24 semanas) * (4 Días a la semana) TUPC = (96 Días) * (6 Horas) TUPC = 576 Horas del proyecto Valor uso Internet por hora = $1000 VUIH = Valor uso Internet por hora.

(28) 28. VUIH = $1000 * TUPC _______________________________ VUIH = $576.000. Valor depreciación hora PC = $2000 VDPC= Valor depreciación hora PC VDPC = $2000 * TUPC ________________________________ VDPC = $1.152.000 CI = Costo de impresiones CI = 5000 hojas * $ 100(costo por impresión) _____________________________________ CI = $500.000. Valor Reserva Imprevistos _________________ VRI = $3.300.000. Otros = Transportes, medios magnéticos de almacenamiento, etc. ______________________________________________ Otros = $500.000 TAT = Tiempo Asesoría Tutor TAT = (6 MESES) *(4 Semanas mensuales) TAT = 24 semanas TAT = (24 semanas) * (3 Días a la semana) TAT = (72 Días) * (4 Horas) TAT = 288 Horas de asesoría del tutor. CAT = Costo asesoría del tutor CAT = TAT * ($50.000 hora) __________________________ CAT = $14.400.000 TTE = Tiempo de Trabajo Estudiantes TTE = (6 MESES) *(4 Semanas mensuales) TTE = 24 semanas.

(29) 29. TTE = (24 semanas) * (4 Días a la semana) TTE = (96 Días) * (6 Horas) TTE = 576 Horas de trabajo estudiantes CTE = Costo Trabajo Estudiantes CTE = TTE * ($25.000 hora) ________________________ CTE = $14.400.000. Tabla 3 Recursos Financieros Recursos. Hardware. Costo. Computador Depreciación computador. $ 2.000.000 $ 864.000. Horas de Internet. $576.000. Asesorías Tutor Trabajo estudiantes Papelería, fotocopias, Impresiones, transportes, medios magnéticos de almacenamiento. Imprevistos. $14.400.000 $14.400.000 $1.000.000. Internet Humano Otros. Imprevistos. $3.300.000. El desgaste del equipo es el valor de depreciación que tiene un computador por el uso durante el tiempo estimado del proyecto. El costo de los recursos que son Software Libre, se atribuye al costo de la hora de internet, que se invierte para la descarga de los programas. El costo de las asesorías y tutorías es la relación entre el valor de la hora de trabajo del profesor, como tutor. Este valor es de $50.000, para un total de $14.400.000, con 288 horas de asesorías. Costo total del proyecto = VUIH + VDPC + CI + CAT + CTE + VRI+ otros + Costo Hardware.

(30) 30. Costo total del proyecto = $ 36.540.000 Este proyecto es factible económicamente ya que se cuenta con las herramientas de hardware y software, las asesorías del tutor son cubiertas por la Universidad Distrital Francisco José de caldas, los demás recursos como papelería, Internet entre otros, serán cubiertos por los ejecutores del proyecto, quienes cuentan con los recursos financieros.. 1.11. Relación Beneficio Costo. El análisis de beneficio costo, permite establecer la rentabilidad al implementar el proyecto, de esta manera se puede determinar la viabilidad del proyecto y su ejecución.. Beneficios La aplicación móvil tiene una serie de beneficios que afectan directamente a la organización que la implemente. A continuación se enumeran los más importantes: Conocer los procesos utilizados con mayor frecuencia por los usuarios de la central Asterisk, mediante el número de solicitudes aplicadas a cada proceso. Esta información es de gran utilidad en términos de trazabilidad para dar cumplimiento a las expectativas del usuario acerca de la aplicación, y dar un enfoque apropiado hacia qué procesos se debe hacer énfasis en futuras versiones del producto. La aplicación cuenta con una mayor cobertura geográfica ya que hace uso de redes inalámbricas. Procesar con mayor rapidez las solicitudes. Los horarios de funcionamiento de la aplicación móvil pueden extenderse, ya que no hay necesidad de tener acceso físico a los servidores Asterisk. La aplicación permite alternar distintos flujos de trabajo sin riesgo a confusiones permitiendo una mayor escalabilidad. Facilidad de uso de la aplicación móvil para el usuario final, este beneficio se ve reflejado en las horas de capacitación al personal y soporte. Beneficios cuantificables A efectos de contar con la información requerida para generar los cálculos, es importante considerar y la forma en que se deben estimar los montos (Agesic.gub, 2013). Actual mente Bogotá es la región que tiene mayor crecimiento de mipymes en el país. En Colombia hay 2,5 millones de micro, pequeñas y medianas empresas, según Confecámaras. Por regiones, 66% de este segmento productivo se concentra en Bogotá (Cantillo. Diana, 2016). Para.

(31) 31. nuestro proyecto vemos un nicho de negocio en este tipo de empresas, en donde un sistema de telefonía puede ser de gran utilidad, además los costos actuales de implementarlo puede ser muy elevados. Dentro de los beneficios cuantificables se establecen los siguientes: Tiempo por concepto de traslados de personal y automatización de procesos. Se establece que el tiempo hora-hombre por concepto de traslados y automatización de procesos en 1.5 horas diarias. (1.5 horas) * (6 días a la semana) = 9 Horas a la semana (9 horas) * (4 semanas mensuales) = 36 Horas al mes (36 oras) * (12 meses) = 432 horas al año __________________________________________ Valor en pesos $1.241.136. Comercializar la aplicación en una tienda de Apps. La aplicación se puede comercializar en la Play Store en donde se puede llegar a muchos de las Mipymes del país, además de la venta de espacios publicitarios dentro de la aplicación. La aplicación se puede vender al usuario final a 15.000 pesos si tenemos en cuenta que la cantidad de Mipymes en Colombia es de alrededor de 2.5 millones estimamos una venta anual a 15000 de ellas (1500 Mipymes)*($ 15.000) ____________________________ Valor en pesos $ 15.000.000al año Soporte: Haciendo uso de la aplicación móvil se disminuyen los errores de digitación al momento de configuración de los contextos de Asterisk, debido a esto el soporte puede reducirse considerablemente el equivalente al salario de un técnico mensual. $1.200.000 * 12 meses _____________________________ Valor en pesos $14.400.000 al año Mejora la interoperabilidad del sistema Asterisk.

(32) 32. Al utilizar un medio de comunicación genérico y de fácil acceso como los dispositivos móviles permite usar dispositivos desde 400 o 500 mil pesos en comparación con equipos de escritorio. Valor en pesos $1.500.000. Los costos ya fueron calculados en la factibilidad económica, y después del primer año se reducen a solamente el mantenimiento de la aplicación, la cual se estima en un 10% del valor del costo total del proyecto, lo que muestra una disminución considerable de los costos.. Tabla 4. Relación beneficio costo para una proyección de 5 años.. Año. Beneficios. Costos. 1. $ 32.141.136. $ 36,540,000. 2. $ 32.141.136. $ 3,654,000. 3. $ 32.141.136. $ 3,654,000. 4. $ 32.141.136. $ 3,654,000. 5. $ 32.141.136. $ 3,654,000. $ 160.705.680. $ 51,156,000. Calculo de la elación beneficio-costo B/C. $ 160.705.680 = 3.1415 $ 51.156.000. Según el análisis beneficio-costo esta relación es mayor a 1. Lo que nos permite deducir que el proyecto es viable en términos de rentabilidad..

(33) 33. 1.12. Cronograma.

(34) 34.

(35) 35. 2. Requerimientos de la aplicación. En esta etapa, se define cuáles son los procesos y procedimientos que se tienen en el escenario para el cual se va a desarrollar la aplicación. Esto permite identificar los casos concretos que debe automatizar el sistema, con el fin de aclarar el enfoque que quiere tener el cliente con el software. Como en cualquier proceso de desarrollo de software, es necesario definir las especificaciones y requerimientos con las que la ap licación debe contar se establecen los siguientes requisitos:.

(36) 36. Identificador del requerimiento (RQT). RQT- 1: Creación de un formulario de Autenticación de Usuario Construir en la aplicación móvil un formulario con los campos usuario y contraseña, y el botón enviar, con el fin de verificar si el usuario tiene acceso o no a la aplicación. RQT- 2: Creación de un formulario para seleccionar la operación Asterisk Construir un módulo en la aplicación móvil, en el cual el administrador de la red pueda elegir alguna de las siguientes opciones Asterisk; Sip, Voice mail, Extensions, Sip show peers y Reload. RQT- 3: Enviar Datos Elaborar un mecanismo para reenviar la operación seleccionada desde el dispositivo móvil al Framework de telefonía. RQT- 4: Conectar Framework Construir un artefacto de software con el fin de integrarlo en el servicio web y lograr comunicación con la consola Asterisk. RQT- 5: Ejecución de comandos Asterisk Implementar un método que permita enviar comandos desde el sistema web a la consola Asterisk. RQT- 6: Envío de mensajes de Texto Construir un servicio en la aplicación móvil encargado de realizar consultas periódicas al servidor web, sobre las llamadas sin atender y posteriormente enviar un mensaje de texto al número telefónico celular que corresponda, informado al usuario que ha sido solicitado. 3 Modelado de casos de uso Se describe un sistema en términos de sus distintas formas de utilización, cada una de las cuales se conoce como un caso de uso (UNAD, 2015).Para este proyecto se definen los casos de uso que representan los procesos con los que se interactúa en la aplicación, así mismo encontramos un conjunto de actores que modelan cualquier entidad externa que necesite intercambiar información con el sistema..

(37) 37. 3.1 Actores El administrador de la red, interactúa con el dispositivo móvil a través de una interfaz gráfica, con opciones de plataforma Asterisk y comandos para cada plataforma. El sistema móvil es el encargado de ejecuta el evento de enviar solicitudes al siste ma web, según lo decidido por el administrador de la red. Cuando el sistema web recibe las solicitudes, se comunica con el Framework Telefonía, que finalmente ejecuta y despliega las operaciones en una interfaz gráfica.. Tabla 5. Lista de actores.. Administrador de red Sistema móvil. Sistema web. Framework Telefonía. uc Actores. Sistema móv il. Administrador de red. Figura 1.. Framew ork telefonía. Sistema w eb. Actores del sistema. Fuente: elaboración propia..

(38) 38. 3.2 Casos de Uso. Después de haber definido a los actores del sistema, se establece la funcionalidad propia del sistema por medio de los casos de uso. El administrador de la red se encarga de seleccionar en la aplicación móvil, cual es la plataforma a ejecutar. También elige la operación que desea ejecutar en esa plataforma. El sistema móvil envía la solicitud de configuración al sistema web, el cual conecta el Framework Telefonía y le envía los datos de plataforma y la operación a ejecutar seleccionada por el administrador. Finalmente, el Framework conecta el dispositivo de la plataforma indicada, ejecuta la operación y despliega el proceso en su interfaz gráfica. Las operaciones que se pueden ejecutar en Asterisk, son; SIP, VOICEMAIL, EXTENSIONS, SIP_SHOW_PEERS y RELOAD. Tabla 6. Lista de casos de uso. Administrador Autenticación del Administrador Elegir plataforma Seleccionar Operación Sistema móvil Enviar solicitudes de configuración Sistema web Conectar Framework Telefonía Enviar comando y plataforma al Framework Framework de Configuración de Telefonía Conectar dispositivo Ejecutar operación de configuración La lista de operaciones incluye: SIP.

(39) 39. EXTENSIONS VOICEMAIL SIP_SHOW_PEERS RELOAD. 3.3 Especificación de casos de uso. Autenticar administrador El administrador de la red ejecuta la aplicación móvil, un formulario es desplegado con los campos usuario, contraseña y un botón enviar. El administrador ingresa sus datos de registro, al pulsar el botón los datos son enviados al Servidor Web para realizar la validación de usuario. uc Acceso a la aplicacion Sistema móvil. CU001 Autenticar usuario. «include». CU002 Validar datos de autenticación. Administrador de red. Figura 2.. Caso de uso para el acceso a la aplicación. Fuente: elaboración propia..

(40) 40. 3.4 Elegir plataforma y operación. Si la validación del usuario es correcta, la aplicación móvil despliega un segundo formulario con opciones de configuración Asterisk. Entre las opciones se incluyen la creación de extensiones telefónicas y buzones de correo, así como la verificación de extensiones en uso y el reinicio de la terminal Asterisk, con el fin de guardar las modificaciones realizadas en los archivos de configuración de la central telefónica, producto de la interacción del administrador de red con el sistema. uc Definición de operación. Operaciones que se pueden ejecutar -SIP -VOICEMAIL -EXTENSIONS -SIP_SHOW_PEERS -RELOAD Si stema móvi l. CU003 Elegir plataforma y operación. «i ncl ude». CU004 Env iar operación. Administrador de red (from Actores). Figura 3.. Caso de uso para definir operación. Fuente: elaboración propia.. 3.5 Conectar Framework. La conexión al Framework consiste en una etapa intermedia entre la solicitud de operaciones por el administrador de la red desde la aplicación móvil y el consumo del servicio web. El Framework se encarga de lograr conectividad IP y enviar los comandos a la consola Asterisk, así como obtener las respuestas de las operaciones y reenviarlas al servicio web. El sistema web sólo puede reenviar la operación a ejecutar al Framework de telefonía, hasta que reciba la operación desde el sistema móvil..

(41) 41. uc Conexion con framew ork Sistema web. CU004 Env iar operación. «include». CU005 Conectar con framew ork telefonía. «include». CU006 Reenv iar operación. Sistema móv il (from Actores). Figura 4.. Caso de uso para la conexión del sistema móvil con Framework de telefonía. Fuente: elaboración propia.. 3.6 Ejecutar operación. El servicio web realiza la conexión al Framework de Telefonía, el cual se encarga de realizar la conexión de red con el servidor Asterisk, ingresar a la consola de telefonía y ejecutar los comandos Linux. El sistema web primero debe conectar el Framework de Telefonía, antes que éste ejecute la operación en el sistema Asterisk. uc Ej ecutar operacion Framework telefonía. CU005 Conectar con framework telefonia. «include». CU007 Ej ecutar operación Asterisk. Sistema web (from Actores). Figura 5.. Caso de uso para la ejecución de la operación Asterisk. Fuente: elaboración propia..

(42) 42. 3.7 Enviar mensaje de texto. Un mensaje de texto es enviado si una llamada Asterisk no es atendida. El Framework de Telefonía se encarga de verificar la recepción de las llamada s, el sistema móvil envía un mensaje de texto al número registrado con el usuario responsable de la extensión desatendida.. uc Env io de mensaj es Framework telefonía. CU004 Env iar operacion. «include». CU008 Verificar estado de llamada. «extend». CU009 Env iar mensaj e de texto. Sistema w eb (from Actores). Figura 6.. Caso de uso para el envío de mensajes desde el dispositivo móvil. Fuente: elaboración propia.. 3.8 Modelo de casos de uso. Inicialmente el administrador de red se autentica y elije plataforma y operación en la aplicación móvil, esto es prerrequisito para que los datos sean enviados desde el dispositivo móvil, hacia la aplicación web. Una vez el sistema web tiene los datos, realiza la conexión al Framework de Telefonía y le reenvía los datos, para que finalmente, él ejecute la operación en Asterisk. El Framework de Telefonía detecta las llamadas que no son atendidas y comunica el evento al sistema mó vil, la cual envía un mensaje de texto al usuario de la extensión telefónica correspondiente..

(43) 43. uc Diagrama general. CU001 Autenticar usuario. «include». CU002 Validar datos de autenticacion. Administrador de red. Sistema mov il. (from Actores). (from Actores). CU003 Elegir plataforma y operacion. «include». CU004 Env iar operacion. «include». CU005 Conectar con framework telefonia. «include». CU006 Reenv iar operacion. Sistema web (from Actores). «include» CU009 Env iar mensaje de texto. «extend». CU008 Verificar estado de llamada. CU007 Ejecutar operacion Asterisk. Framework telefonia (from Actores). Figura 7.. Modelo general de casos de uso. Fuente: elaboración propia..

(44) 44. 3.9 Documentación de casos de uso. Autenticar administrador. El sistema permite habilitar y acceder a las operaciones. Tabla 7. Autenticar administrador.. Autenticar usuario Caso de Uso:. Autenticar usuario. Actores:. Administrador. Descripción:. El sistema valida si el usuario está registrado y que la contraseña es la que está asignada a ese usuario, permitiendo aprobar o denegar el acceso al Administrador de la red a las operaciones de configuración dentro de la aplicación.. Casos de Asociados. Uso Elegir plataforma y Operación. Flujo Principal:.  El sistema visualiza un formulario con los campos usuario y contraseña, además un botón ingresar que permite enviar al servidor los datos diligenciados por el usuario.  Una vez enviada la información, el sistema comprueba si los datos del formulario de ingreso son correctos.  En caso de coincidencia el sistema permite acceso al usuario y despliega un menú con opciones de configuración.  Si los campos diligenciados usuario o contraseña son incorrectos el sistema informará por medio de una alerta, que el campo de texto usuario o contraseña no son válidas.. Flujo Alternativo.  El sistema muestra un mensaje de validación fallida, indicando que el usuario o la contraseña no son válidas y limpia los campos de texto para realizar un nuevo intento.  Después de 3 intentos fallidos la aplicación se cierra..

(45) 45. Propósito. Permite habilitar y acceder a configuración Asterisk.. Precondiciones:. Ninguna.. Excepciones:. E1: No es posible Validacion_Usuario. invocar. las. el. operaciones. Método. de. Remoto. Se presenta cuando no se ha desplegado el Servicio Web o no hay comunicación con el Servidor, por lo tanto no se puede realizar la llamada al procedimiento remoto. Prioridad:. Alta. Post-Condición:. Luego de terminar el proceso de validación, el sistema activa un menú con las opciones SIP, SIP_SHOW_PEERS, EXTENSIONS, VOICEMAIL y RELOAD.. Complejidad:. Media. Tabla 8. Elegir plataforma y operación.. Elegir Plataforma Caso de Uso:. Elegir plataforma y operación. Actores:. Administrador de la red. Descripción:. Otorga al administrador la función de seleccionar la plataforma Asterisk para la ejecución de tareas.. Casos de Asociados Flujo Principal:. Uso Enviar operación y plataforma. El sistema móvil despliega varias opciones de selección, con las operaciones del sistema Asterisk para la configuración del sistema.  La actividad de la aplicación móvil despliega la opción SIP con el fin de registrar un número telefónico móvil y.