REDISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE MONITOREO DE LA RED DE … · 2018-08-22 · 1.1.1....

REDISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE MONITOREO DE LA

RED DE TELECOMUNICACIONES DE DISTRIBUIDORA NISSAN S.A

MICHAEL GALLEGO ADAMES

UNIVERSIDAD CATÓLICA DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS ALTERNATIVA PRÁCTICA EMPRESARIAL

BOGOTÁ D.C. 2015

REDISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE MONITOREO DE LA RED DE TELECOMUNICACIONES DE DISTRIBUIDORA NISSAN S.A

MICHAEL GALLEGO ADAMES

Trabajo de Grado para optar al título de Ingeniero de Sistemas

Director Carlos Andrés Lozano Garzón

Ingeniería De Sistemas

UNIVERSIDAD CATÓLICA DE COLOMBIA FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS ALTERNATIVA PRÁCTICA EMPRESARIAL

BOGOTÁ D.C. 2015

4

Nota de Aceptación

Aprobado por el comité de grado en cumplimiento de los requisitos

exigidos por la Facultad de Ingeniería y la Universidad

Católica de Colombia para optar título de ingeniero de Sistemas.

__________________________ Carlos Andrés Lozano

Director

__________________________ Cesar Orlando Díaz

Revisor Metodológico

Bogotá, 18, noviembre, 2015

5

CONTENIDO Título Pág. INTRODUCCIÓN 14

1. GENERALIDADES 15

1.1. ANTECEDENTES 15

1.1.1. Software de código abierto/Open Source 16

1.1.2. Software de gestión de red empresarial 17

1.1.3. Software especializado 17

1.2. PLANTEAMIENTO DEL PROBLEMA 18

1.3. OBJETIVOS 20

1.3.1. Objetivo general 20

1.3.2. Objetivos específicos 20

1.4. DELIMITACIÓN 20

1.4.1. Alcances del proyecto 20

1.4.2. Limitaciones del proyecto 21

1.5. MARCO REFERENCIAL 21

1.5.1. Marco conceptual 21

1.5.2. Marco teórico 23

1.6. METODOLOGÍA 32

2. ESPECIFICACIÓN DE REQUERIMIENTOS 34

2.1. INTRODUCCIÓN 34

2.1.1. Propósito 34

2.1.2. Alcance 34

2.1.3. Definiciones, acrónimos y abreviaturas 34

2.1.4. Resumen 35

2.2. DESCRIPCIÓN GENERAL 36

2.2.1. Perspectiva del producto 36

2.2.2. Funcionalidad del producto 36

2.2.3. Características de los usuarios 36

2.2.4. Restricciones. 37

6

2.2.5. Suposiciones y dependencias 37

2.3. REQUERIMIENTOS DE INTERFACE EXTERNA 37

2.3.1. Interfaces de usuario 37

2.3.2. Interfaces de hardware 38

2.3.3. Interfaces de software 38

2.4. REQUERIMIENTOS FUNCIONALES 38

2.5. REQUERIMIENTOS NO FUNCIONALES 59

3. DISEÑO 62

3.1. CASOS DE USO 62

3.2. DIAGRAMA DE ACTIVIDADES 87

3.3. DIAGRAMAS DE SECUENCIA 94

3.4. DIAGRAMA DE DESPLIEGUE 97

3.5. BASE DE DATOS 98

3.5.1. Diccionario de datos 99

4. IMPLEMENTACIÓN 105

4.1. Administrador 105

4.2. Agente 112

4.3. Invitado 113

5. PRUEBAS 114

5.2. Pruebas de estrés 114

5.2.1. Escenario 1 114




6. CONCLUSIONES 127

7. RECOMENDACIONES 128

BIBLIOGRAFÍA 129

8

TABLA DE FIGURAS Título Pág. Figura 1. Capas del modelo OSI 25

Figura 2. Capas del modelo TCP/IP Ataques contra redes 27

Figura 3. Operaciones protocolo SNMP 30

Figura 4. Encapsulamiento de mensajes ICMP 31

Figura 5. Modelo en cascada 33

Figura 6. Caso de Uso Autenticar Usuario 63

Figura 7. Caso de Uso Gestión De Proveedores 66

Figura 8. Caso de Uso Gestión De Sedes (centro de costos) 68

Figura 9. Caso de Uso Gestión De Canales 71

Figura 10. Caso de Uso Gestión De Activos 76

Figura 11. Caso de Uso Gestión De Contactos 80

Figura 12. Caso de Uso Gestión De Credenciales De Administración 83

Figura 13. Caso de Uso Gestión Monitoreo De Canales 86

Figura 14. Diagrama De Actividades – Gestión De Proveedores 88

Figura 15. Diagrama De Actividades – Gestión De Ciudades 89

Figura 16. Diagrama De Actividades – Gestión De Sedes 90

Figura 17. Diagrama De Actividades – Gestión De Canales 91

Figura 18. Diagrama De Actividades – Gestión De Activos 92

Figura 19. Diagrama De Actividades – Gestión De Contactos 93

Figura 20. Diagrama De Actividades – Monitor De Canales 94

Figura 21. Diagrama De Secuencia – Autenticación 95

Figura 22. Diagrama De Secuencia - Consulta 95

Figura 23. Diagrama De Secuencia - Registro 96

Figura 24. Diagrama De Secuencia - Edición 96

Figura 25. Diagrama De Secuencia - Canales 97

Figura 26. Diagrama de despliegue 97

Figura 27. Diagrama Entidad Relación 98

Figura 28. Pantalla De Autenticación 105

Figura 29. Pantalla De Autenticación - Datos Incorrectos 106

Figura 30. Menú De Navegación 106

Figura 31. Módulo De Canales 107

Figura 32. Edición De Canales 107

Figura 33. Adición De Canales 108

Figura 34. Eliminación De Canales 108

Figura 35. Módulo De Sedes 109

Figura 36. Módulo De Contactos 109

Figura 37. Módulo De Proveedores 110

Figura 38. Módulo De Activos Fijos 110

8

Figura 39. Módulo De Administración De Activos Fijos 111

Figura 40. Módulo De Ciudades 111

Figura 41. Módulo De Canales - Usuario Agente 112

Figura 42. Módulo De Proveedores - Usuario Agente 112

Figura 43. Panel De Canales 113

Figura 44. Resumen Prueba 001 115

Figura 45. Tabla De Resultados Prueba 001 116

Figura 46. Grafica De Resultados, Tiempos De Respuesta Prueba 001 117



Figura 49. Grafica De Resultados, Tiempos De Respuesta Prueba 002. 120







9

LISTA DE TABLAS

Título Pág. Tabla 1. Lista de Requerimientos Funcionales 38

Tabla 2. Requerimiento Funcional 1 39


























Tabla 28. Lista de Requerimientos No Funcionales 59

Tabla 29. Requerimiento No Funcional 1 59





Tabla 34. Lista de Casos De Uso 62

Tabla 35. Caso de Uso 1 64




10























Tabla 61. Diccionario Tabla Proveedor 99

Tabla 62. Diccionario Tabla Usuario 99

Tabla 63. Diccionario Tabla Ciudad 100

Tabla 64. Diccionario Tabla Sede 100

Tabla 65. Diccionario Tabla Compañía 100

Tabla 66. Diccionario Tabla Canal 101

Tabla 67. Diccionario Tabla Activo 101

Tabla 68. Diccionario Tabla Contacto 102

Tabla 69. Diccionario Tabla Administración De Activos 102

Tabla 70. Diccionario Tabla Tipo De Falla 103

Tabla 71. Diccionario Tabla Monitoreo De Canal 103

Tabla 72. Diccionario Tabla Promedio Monitoreo De Canal 104

Tabla 73. Escenario De Prueba 001 114




10

LISTA DE CUADROS

Título Pág.

Cuadro 1. Casos De Uso Autenticación 63

Cuadro 2. Gestión De Proveedores 66

Cuadro 3. Gestión De Sedes. 68

Cuadro 4. Gestión De Canales 71

Cuadro 5. Gestión De Activos 76

Cuadro 6. Gestión De Contactos 80

Cuadro 7. Gestión De Credenciales De Administración 83

Cuadro 8. Monitoreo De Canales 86

12

RESUMEN

Distribuidora Nissan S.A, es una compañía constituida hace más de 50 años, que cuenta actualmente con 110 sedes a nivel nacional entre las cuales se encuentran puntos de servicio postventa, puntos de venta de vehículos Nissan, vitrinas de repuestos y vitrinas de maquinaria a nivel nacional. Debido a su vertiginoso crecimiento, se ha visto en la necesidad de mejorar día a día, con el fin de garantizar la prestación del mejor servicio a sus clientes. Bajo este lineamiento, el objetivo principal del presente proyecto es el de rediseñar e implementar un sistema que permita el monitoreo del estado de los diferentes canales que hacen parte de la red de Telecomunicaciones de Distribuidora Nissan S.A en Colombia. El desarrollo de este proyecto constituye una solución que cuente con información centralizada acerca de cada canal de la red, de los proveedores de internet, nombres y números de contacto, direcciones IP, direcciones de las sedes, información actual e histórica del estado de la red, entre otros. Además, representa una herramienta que proporcionará información de utilidad acerca del estado de la red de comunicaciones de Distribuidora Nissan S.A para la solución y seguimiento de incidentes con el fin de garantizar la continuidad en la comunicación entre las diferentes sedes a nivel nacional. PALABRAS CLAVE: Distribuidora Nissan S.A, Red de telecomunicaciones, gestión, información centralizada, solución a incidentes.

ABSTRACT Distribuidora Nissan S.A , is a company founded over 50 years ago , they currently has 110 offices national level including, outlets Nissan vehicles, service points, showrooms parts and machinery showrooms. Due to its rapid growth , it has seen the need to improve day by day , in order to ensure the provision of better service to their customers. Under this guideline, the main objective of this project is the redesign and implements of one system that allows monitoring the status of the different channels that are part of the telecommunications network of Distribuidora Nissan S.A in Colombia. The development of this project is a solution that has centralized information about each network channel, internet providers, names and contact numbers, IP

13

addresses, addresses of offices, current and historical information of network status, and other networks characteristics. It also represents a tool that will provide useful information about the status of the communications network of Distribuidora Nissan S.A to resolve incidents and allow monitoring in order to ensure continuity in communication un multiple Dinissan offices. KEY WORDS: Distribuidora Nissan S.A, Telecommunication network, management, centralized information, incident solution.

14

INTRODUCCIÓN Hoy en día, la calidad de la comunicación interna y externa entre las distintas áreas que componen a una empresa, y con los clientes y socios de negocio; garantiza que los procesos de negocio se efectúen de la mejor manera. Cuando los procesos presentan retrasos o fallas se generan pérdidas económicas y de tiempo para la organización, por este motivo, las empresas se preocupan cada vez más por asegurar la disponibilidad y el rendimiento de la red que les permite la comunicación. Mantener estos dos factores de calidad requiere de un sistema para el monitoreo de la red de comunicaciones, que realice una revisión constante del estado de la red, permitiendo al área administrativa actuar rápidamente ante incidentes detectados. Estos incidentes comprometen de forma crítica la comunicación y pueden llegar a convertirse en problemas que afectan cada vez más sectores de la empresa, temas como demoras en los tiempos de respuesta y uso del ancho de banda son imprescindibles para la toma de decisiones en miras de mantener y mejorar la calidad. Ante este panorama, es importante aclarar que todas las organizaciones tienen necesidades diferentes y procedimientos distintos para el seguimiento y resolución de incidentes, es por eso, que existen varias soluciones para el monitoreo de la red; ya sea software libre, profesional o especializado, su objetivo final es brindar la información requerida para una ágil toma de decisiones con el fin de garantizar un óptimo funcionamiento de la red de comunicaciones. Sin embargo seleccionar la solución más adecuada depende de los procesos y necesidades del negocio. Bajo este contexto, los procesos de una compañía como Distribuidora Nissan S.A, están directamente relacionados con la comunicación, sin embargo, actualmente la organización no cuenta con una herramienta adecuada que garantice la disponibilidad y la calidad de dicha comunicación. Es por esta razón que se requiere de manera prioritaria una solución de monitoreo de red especializada que se adapte a las necesidades de la compañía, con el fin de llevar a cabo una búsqueda ágil de posibles fallas y/o componentes defectuosos; de forma que sea posible definir y ejecutar actividades y procedimientos que permitan mitigar dichos fallos y garantizar la calidad del servicio.

15

1. GENERALIDADES

En el presente capítulo se definen, describen y caracterizan todos los conceptos, métodos y teoría relacionada con el proceso de investigación para el desarrollo del proyecto.

1.1. ANTECEDENTES

En la actualidad, las redes se han convertido en un elemento determinante en el éxito de una empresa, cuando se produce una falla en la red, los empleados y los usuarios quedan “incomunicados”, de forma que es imposible acceder a información vital de la compañía, servicios de correo electrónico, aplicaciones de facturación o incluso servicios básicos de impresión, lo que provoca pérdidas monetarias y productivas para la organización1. Por esta razón, es correcto afirmar que el éxito de muchos de los procesos de una organización depende de la calidad de la comunicación existente. Ante esto, las empresas se interesan por adquirir diversos elementos de infraestructura de red que les garantice; velocidad, confiabilidad y disponibilidad. Para conseguir este objetivo es primordial considerar que un buen servicio de red no depende únicamente de una buena infraestructura, también es necesario tener en cuenta un adecuado diseño en la red, y entre otras cosas, un monitoreo de la red en tiempo real. El monitoreo, es determinante en la prevención y resolución de incidentes con la red de comunicaciones de una organización, ya que permite, entre otras cosas; la detección oportuna de fallas, la verificación del estado de componentes y la medición del desempeño de la red. Las aplicaciones de software especializadas en el monitoreo de red permiten reducir, prevenir, anticipar y gestionar las interrupciones que se puedan presentar, permitiendo una operación continua y evitando pérdidas monetarias a la compañía. Los tipos de aplicaciones de software que existen actualmente presentan diferentes características que permiten el monitoreo de red con funcionalidades distintas. Al ser cada empresa diferente; presenta distintas necesidades respecto a

1 MANAGE ENGINE. Free Network Monitoring Software for Small Networks. [en línea]. [citado 28

Julio, 2015]. Disponible en Internet: < URL: https://www.manageengine.com/network-monitoring/Network-Monitoring-Software.pdf>

16

un software de monitoreo, de modo tal que, una empresa debe analizar qué funcionalidades requiere, y con qué recursos cuenta2. Las principales soluciones de monitoreo que existen pueden agruparse en cuatro categorías principales: 1.1.1. Software de código abierto/Open Source. Las soluciones Open Source, resultan ser muy atractivas para empresas con un ajustado presupuesto debido a que su principal ventaja es, su uso sin costo de licenciamiento2. Sin embargo, en este tipo de aplicaciones, existen varias limitaciones en la falta de funcionalidades y asistencia técnica3. Entre las herramientas de código abierto más utilizadas para el monitoreo de la red se encuentran: Nagios4, Cacti, Zenoss5, ZABBIX, MRGT6y OpenNMS7, a continuación se describen algunas de ellas. 1.1.1.1. NAGIOS. Es un sistema de monitorización de equipos y servicios de red8 [5] de protocolos como SMTP, POP3, HTTP, ICMP y permite también el seguimiento de los recursos de Host como el uso de discos, carga de procesador, estado de puertos, etc.9.Sin embargo, una de sus principales desventajas es la falta de detalles en los reportes que presenta10.

2 TIMMERMANN, Thomas. Criterios para la selección adecuada de una solución de monitoreo de

red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:https://assets.paessler.com/common/files/pdf/whitepaper/selection-criteria_es.pdf> 3 MONGKOLLUKSAMEE, Sophon. PONGPAIBOOL, Panita. ISSARIYAPAT, Chavee. Strengths

and Limitations of Nagios as a Network Monitoring Solution. [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL: http://inms.in.th/inmsweb/paper/Apricot_nagios20091130-final.pdf> 4 NAGIOS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

http://nagios.org> 5 ZENOSS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

http://zenoss.com> 6 MRGT. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

https://www.mrtg.com> 7 OPENNMS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

http://opennm.org>. 8 CAYU. Monitoria y análisis de Red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: <

URL: http://cayu.com.ar/files/manuales-nagios.pdf>. 9 HURTADO, Francisco. Nagios: Caso de aplicación [en línea]. [citado 28 Julio, 2015]. Disponible

en Internet: < URL: http://www.fedoras.com/manuales/redes/nagios.pdf>. 10

SISTEMAMONITOREOUNL. Sistemas de Monitoreo [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL: https://sistemamonitoreounl.wordpress.com/sistemas-de-monitoreo-3/>.

17

1.1.1.2. CACTI. Es una solución desarrollada en PHP que permite tener información en tiempo real para la supervisión de la red y los dispositivos que la conforman; servidores, routers, conmutadores, unidades de procesamiento, etc.11 [8], utiliza el protocolo SNMP para la obtención de los datos y cuenta con una sola consola de administración de fácil configuración12. Una desventaja que presenta la herramienta es que la información que ilustra en sus gráficas; no es muy clara y su interpretación requieren de un proceso adicional por parte del usuario. Adicionalmente, no presenta la posibilidad de añadir varios equipos en una misma configuración, por lo tanto si se tiene gran cantidad de equipos, su configuración debe hacerse una por una. 1.1.1.3. ZABBIX. Es una solución que busca centralizar el monitoreo de la disponibilidad y el rendimiento de la red en tiempo real. A diferencia de muchas herramientas, Zabbix no tiene limitaciones en el número de dispositivos para su monitoreo haciéndola altamente escalable y aplicable en entornos de cualquier dimensión. Actualmente Zabbix cuenta con funcionalidades limitadas para los reportes y su curva de aprendizaje es bastante elevada13. 1.1.2. Software de gestión de red empresarial. Son herramientas que ofrecen una amplia gama de funcionalidades y una buena asistencia técnica del producto. Sin embargo, los costos elevados de licenciamiento generan un gasto muchas veces innecesario, ya que se paga por módulos o funciones que no se utilizan, además son sistemas complejos de usar y configurar. Entre los más utilizados se encuentran; PRTG Network14 y OpManager15 que ofrecen numerosas funciones enfocadas a los centros de datos de vigilancia, redes y servidores. 1.1.3. Software especializado. Esta categoría, abarca los sistemas de monitoreo desarrollados para áreas específicas de la red, son desarrollados a la medida, para satisfacer las necesidades de la compañía, de forma tal que se diseña y se implementa lo que requiere la empresa.

11

BIBING. Guía rápida de cacti [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL: <http://bibing.us.es/proyectos/abreproy/12013/fichero/5.+Anexos%252FANEXO+1_Guia+rapida+de+CACTI.pdf> 12

VICENTE, Carlos Alberto. Monitoreo de recursos de red [en línea]. [citado 29 Julio, 2015]. Disponible en Internet: < URL: https://juliorestrepo.files.wordpress.com/2011/04/monitoreo.pdf>. 13

SHOKHIN, Anatolii. Network monitoring with ZABBIX [en línea]. [citado 29 Julio, 2015]. Disponible en Internet: < URL: http://www.theseus.fi/bitstream/handle/10024/94415/Bachelor_Thesis_Anatolii_Shokhin.pdf?sequence=1>. 14

PAESSLER. Proteger redes por años [en línea]. [citado 30 Julio, 2015]. Disponible en Internet: < URL: https://www.es.paessler.com/prtg>. 15

OPMANAGER. ManageEngine [en línea]. [citado 29 Julio, 2015]. Disponible en Internet: < URL: http://opmanager.com.es/>.

18

Con el software comercial, la empresa debe adaptar sus procedimientos de trabajo a los requerimientos de la aplicación, mientras que con el software especializado es el software quien se adapta las necesidades de la compañía16. Se paga por funcionalidades que necesita el área y debido a su especialización se garantizan los resultados. Con una solución especializada para el monitoreo de red, la división de redes y telecomunicaciones de una empresa, cuenta con la información necesaria para una toma oportuna de decisiones. Como se evidencia, existen múltiples opciones a tener en cuenta para el monitoreo de una red a nivel empresarial, pero, la elección de una solución adecuada, se basa en las necesidades que la organización presente, ante esto, es comprensible que hoy en día, muchas de las grandes organizaciones busquen que sus sistemas se adapten a sus necesidades haciendo del software especializado una elección muy concurrida. Este es el caso de la organización Distribuidora Nissan S.A, una compañía comprometida con sus clientes, y que siempre está mejorando para brindar la mejor calidad. Actualmente, la compañía cuenta con un aplicativo muy básico para la gestión de la red a nivel nacional, esta herramienta no brinda a la unidad administrativa de la red, la información necesaria para una rápida solución de incidentes, tampoco cuenta con un base de datos que almacene la información correspondiente a las fallas que se presentan en la red, lo que provoca, la falta de un registro adecuado de las fallas en la comunicación. Es por estas razones que esta solución, no satisface las necesidades que presenta la organización, por este motivo la compañía ha optado por el desarrollo de un software especializado que les brinde una solución óptima a lo que realmente requiere la unidad de gestión de red para garantizar, la disponibilidad y un alto rendimiento de la red. 1.2. PLANTEAMIENTO DEL PROBLEMA En la actualidad, el crecimiento tecnológico y la expansión empresarial, promueven constantemente; la optimización de los procesos, al aumento productividad y la mejora continua en la calidad de las organizaciones. Bajo esta premisa, ofrecer el mejor servicio es imprescindible para una organización como Distribuidora Nissan S.A, constituida hace más de 50 años, que cuenta actualmente con un red propia de distribución nacional, con más de 28 puntos de servicio postventa, más de 33 puntos de venta de vehículos Nissan, 9 vitrinas de repuestos y 4 vitrinas de maquinaria a nivel nacional.

16

OCTANA. Ventajas del software a la medida [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL: http://www.octana-software.com.mx/software_medida_vs_comercial.pdf>.

19

Hoy en día, la compañía cuenta con 110 sedes a nivel nacional que hacen parte de la familia DINISSAN S.A, las cuales se encuentran interconectadas a través de una red VPN (Virtual Private Network) y la gran mayoría de estas sedes, cuentan con dos proveedores de servicio de internet; un proveedor principal y un proveedor de respaldo, que se activa automáticamente cuando el proveedor principal presenta cinco minutos de inactividad Una actividad imprescindible para la organización es el monitoreo de la red de telecomunicaciones en tiempo real, esta labor es un punto clave en la búsqueda de posibles fallas y/o componentes defectuosos; de forma que sea posible definir y ejecutar actividades y procedimientos que permitan mitigar dichos fallos, a través de la realización de un mantenimiento oportuno y así mejorar tiempos de respuesta en la red, asegurando la operación continua y óptima de la misma. Actualmente, el área de redes y telecomunicaciones de Distribuidora Nissan S.A cuenta con un aplicativo orientado a la web, que realiza una verificación del estado de la red en las diferentes sucursales a nivel nacional en tiempo real, por medio del protocolo ICMP (Internet Control Message Protocol). Este aplicativo, cuenta con un panel, que ilustra únicamente el nivel de latencia que presenta la red en cada sede. Esta solución, no detalla el tipo de falla que provoca la caída o ausencia del servicio de red, por lo tanto, es necesaria la verificación telefónica con la sucursal, con el fin de encontrar la causa, retrasando así, el tiempo de resolución del incidente. Adicionalmente, no se cuenta con una base de datos que almacene la información correspondiente a las fallas que se presentan en la red, lo cual no permite la realización de reportes estadísticos adecuados que evidencien los problemas que aquejan la red de comunicaciones de la organización con el fin de dar seguimiento de forma prioritaria. Así mismo, no es posible conocer en tiempo real qué proveedor de Internet se encuentra activo en cada sede, información que solo puede ser corroborada por medio de una verificación telefónica con la sede respectiva, o con los mismos proveedores. Para el área de redes y telecomunicaciones es de vital importancia contar con mediciones estadísticas detalladas y de fácil comprensión como una herramienta de apoyo para una acertada toma de decisiones, que contribuyan a proporcionar un servicio de disponibilidad de la red igual o superior a 95.5 %. En base a estas necesidades que presenta el área de redes y telecomunicaciones se formula el siguiente interrogante: ¿Cuáles son las características técnicas para el desarrollo de una herramienta que permita el monitoreo del estado del servicio de la red en las sedes a nivel nacional de la compañía Distribuidora Nissan S.A, y que se ajuste a las necesidades de la misma?

20

1.3. OBJETIVOS

1.3.1. Objetivo general. El objetivo general del proyecto es:

Rediseñar e implementar un sistema que permita el monitoreo del estado de la red de las sedes de Distribuidora Nissan S.A en Colombia.

1.3.2. Objetivos específicos. Los objetivos específicos del proyecto son:

Realizar el levantamiento de requerimientos funcionales y no funcionales del sistema. Diseñar el sistema web de monitoreo para la red de comunicaciones de Distribuidora Nissan S.A., acorde con los requerimientos identificados. Desarrollar el sistema de monitoreo de red que permita gestionar la información de cada sede de la distribuidora. Realizar las pruebas para la validación y verificación del sistema de monitoreo desarrollado 1.4. DELIMITACIÓN

1.4.1. Alcances del proyecto. El proyecto se centra en: el levantamiento de

requerimientos, diseño, implementación, y pruebas de una herramienta orientada

a la web para la monitorización del estado de la red de las sedes de Distribuidora

Nissan S.A. De forma específica el proyecto constituye los siguientes alcances:

Brindar una herramienta que proporcione información de utilidad acerca del

estado de la red de comunicaciones de Distribuidora Nissan S.A para la solución y seguimiento de incidentes.

Proporcionar una solución que cuente con información de forma centraliza

acerca de proveedores de internet, nombres y números de contacto, direcciones IP, direcciones de las sedes, información actual e histórica del estado de la red.

21

Agilizar los procesos de actualización, en base a la información suministrada por la herramienta; en aspectos como cambio o adición de proveedores, aumento de ancho de banda, cambio de equipos, entre otros.

Facilitar la generación de reportes estadísticos que permitan la predicción de fallas y la modelación de tendencias.

1.4.2. Limitaciones del proyecto. A continuación se definen las limitación es del

proyecto:

El proyecto será implementado para el uso exclusivo del área de

telecomunicaciones de Distribuidora Nissan S.A Los requerimientos de la herramienta de monitoreo de la red están orientados

de acuerdo con las necesidades expresadas por el departamento de telecomunicaciones de distribuidora Nissan S.A.

En un inicio, la herramienta va a monitorear 110 sedes que hacen parte del

grupo Distribuidora Nissan S.A y que se encuentran ubicadas a nivel nacional. El idioma de la herramienta solo será español. 1.5. MARCO REFERENCIAL

1.5.1. Marco conceptual. A continuación se definen de una manera clara y

concisa los principales términos que tienen relación con la gestión de una red de

telecomunicaciones.

Red de datos: conjunto de equipos de cómputo y dispositivos (comúnmente denominados nodos) conectados por enlaces de un medio físico17. Servicios de red: conjunto de funciones y aplicaciones que se ejecutan a través de la capa de aplicación de la red y que ofrecen un valor a un proceso de negocio18, como lo son, los servicios de acceso e información, de correo, de impresión etc.

17

ROBLES, Luis Fernando. Redes de informática [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: https://sites.google.com/site/redesdeinformaticahermosilloii/home/conceptos-basicos> 18

FERRO, Greg. Basics: What Is a Network Service? [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://etherealmind.com/basics-what-is-a-network-service/.>

22

Monitorización: es una actividad constante de revisión que permite verificar el desempeño y disponibilidad de una red cuyo objetivo principal es la búsqueda de componentes defectuosos19. Gestión De red: hace referencia al conjunto de métodos, procedimientos, actividades y herramientas que permiten la operación, administración, mantenimiento y aprovisionamiento de un sistema de red20. Operación: tiene que ver con mantener activos y en óptimo funcionamiento, la red y los servicios que corren a través de ella20. Administración: proceso que implica el seguimiento de los recursos que componen la red de comunicaciones y las actividades de corrección necesarias para mantener la red en funcionamiento20. Mantenimiento: se refiere a las actividades de reparación y actualización hacia la red asegurando la correcta operación de la red. Aprovisionamiento: Tiene que ver con la configuración de los recursos de la red de para soportar un servicio específico20. ICMP (Internet Control Message Protocol): es un protocolo de control que sirve para informar de los errores en el procesamiento de paquetes IP (Internet Protocol)21. SNMP (Simple Network Management Protocol): es un protocolo del nivel de aplicación del modelo OSI (Open Systems Interconection) que permite monitorizar características cualidades operativas de un Router22.

19

CONATEL. Monitorización de redes en software libre herramientas y recomendaciones [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://www.conatel.gob.ve/monitorizacion-de-redes-en-software-libre-herramientas-y-recomendaciones/> 20

CLEMM, Alexander. Network Management Fundamentals. Indianapolis. 2 ed. 2006. p. 145 21

NEBRIJA. Curso de TCP/IP [en línea]. [citado 29 De Julio, 2015]. Disponible en Internet: < URL: http://www.nebrija.es/~cmalagon/seguridad_informatica/Lecturas/TCP-V_ICMP_hxc.pdf> 22

ROUTER TELDAT. Agente snmp. [en línea]. [citado 29 De Julio, 2015]. Disponible en Internet: < URL: <ftp://ftp.storm.hr/Upload/Teldat_privremeno/Teldat_dokumen12%5CDm712v10-60_Agente_SNMP.pdf.>

23

1.5.2. Marco teórico. Una excelente comunicación con los clientes y socios de negocio, y entre las diferentes áreas de una compañía, son imprescindibles para garantizar la calidad en los procesos de negocio. Hoy en día en las empresas, la dependencia hacia los servicios de comunicaciones ha incrementado, por lo tanto mantener estos servicios en funcionamiento es sinónimo de mantener el negocio en funcionamiento. Por esta razón, es muy importante para las empresas tener un monitoreo constante de los procesos dentro de la red de telecomunicaciones, con el objetivo de mantener un control sobre la disponibilidad y rendimiento de la misma2. Una red es una estructura compleja, por lo tanto requiere de un trato muy especializado. Las fallas que ocurren en una red deben ser detectadas, diagnosticadas y reparadas de forma oportuna. A este conjunto de actividades que buscan mantener el funcionamiento óptimo de una red, se le denomina gestión de red. Según el autor Antoni Martí, la gestión de red siembra sus bases en la planificación, organización, y el control de los elementos de comunicaciones para garantizar la calidad del servicio, mejorando la disponibilidad, el rendimiento y la efectividad23. Por tanto, podríamos entender la gestión de la red como todo un conjunto de procedimientos que se interesan por mantener la red en óptimo funcionamiento, contribuyendo en el incremento de la eficiencia operacional y asegurando el alto nivel de disponibilidad y confiabilidad de los servicios de comunicaciones. La gestión de red, pretende generar información de utilidad en la toma de decisiones, esta información obtenida a partir de la aplicaciones de gestión, pretende establecer dos procesos fundamentales; el monitoreo y el control de red; procesos que se complementan entre sí. Mientras que el control de la red busca mejorar el desempeño de los servicios, el monitoreo pretende mantener información del comportamiento de la red de comunicaciones24. El monitoreo de la red o la monitorización se define como el conjunto de actividades que por medio de la identificación y detección de posibles problemas, hace posible la evaluación del desempeño y la disponibilidad de la red.

23

MARTI, Barba. MORENO, Melus. Network Management and Control. Volume 2. New York, 1994.p.20. 24

MOLERO, Luis. Planificación y gestión de redes. [en línea]. [citado 1 Agosto, 2015]. Disponible en Internet: < URL: http://www.urbe.edu/info-consultas/web-profesor/12697883/archivos/planificacion-gestion-red/Unidad-I.pdf>

24

Las tareas de monitorización utilizan una serie de herramientas, dispositivos y aplicaciones que le permiten al administrador de red, responder a los cambios y garantizar siempre tiempos de respuesta mínimos para los usuarios. 1.5.2.1. ¿Por qué es importante la monitorización?25. A continuación se numeran las principales razones por las cuales es importante monitorear la red de telecomunicaciones. Las herramientas utilizadas en la gestión de redes ayudan a los administradores a identificar y resolver problemas de forma más rápida. Solución y seguimiento de incidentes. Actualización, ya que con la información suministrada por el proceso de monitoreo, los administradores tienen un respaldo para tomar acciones; cambio o adición de proveedores, aumento de ancho de banda, cambio de equipos por fallas constantes, etc. Generar información estadística con el fin de predecir fallas, modelar tendencias. Verificación de cumplimiento de SLAs (Acuerdos A Nivel De Servicio). Asegurar la disponibilidad de los servicios. Mantener histórico del estado de la red. 1.5.2.2. Elementos de la red de comunicaciones que requieren monitoreo1: Recursos LAN: dispositivos que hacen parte de la infraestructura, Switches, servidores, dispositivos inalámbricos e impresoras. Enlaces WAN: Los administradores de la red deben manejar el equilibrio de la tasa de información comprometida (CIR), así como optimizar la utilización del enlace, por lo tanto es necesaria la monitorización del ancho de banda y los Routers.

25

TECNOZER. ¿Por qué es importante monitorizar nuestra red? [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://www.tecnozero.com/blog/por-que-es-importante-monitorizar-nuestra-red/>

25

Aplicaciones de negocio: Herramientas propias de la compañía necesarias para llevar a cabo los procesos, como lo son sistemas de información, páginas web, bases de datos, entre otros. Servidores y servicios: Los servidores tiene la tarea de ejecutar aplicaciones de gran importancia, por lo tanto es necesario el monitoreo del estado de las CPU, memorias, espacio de disco y además los servicios (FTP, DNS, ECHO, IMAP, DHCP, HTTP, POP, LDAP, etc.).

1.5.2.3. Modelo OSI (Open System Interconnection). Es un modelo de red

estandarizado para las comunicaciones en red, que ofrece un marco de trabajo

conceptual que permite describir la forma en que los datos se mueven dentro de la

red. Se creó con el fin de garantizar la interoperabilidad y compatibilidad al

implementar redes con distintos tipos de tecnología, de forma que se pudieran

comunicar entres sí, este modelo fue creado por la Organización Internacional

para la Normalización (ISO) en el año de 198426.

Este modelo de referencia, divide la complejidad de la comunicación en 7 “capas”, donde cada capa ejecuta una determinada parte del proceso de transmisión de información dentro de una red. Las capas que componen el modelo OSI se muestran en la Figura 1. Figura 1. Capas del modelo OSI

Fuente: EMAZE, Modelo osi [en línea]. [citado 1 Agosto, 2015]. Disponible en Internet:

< URL: https://puserscontentstorage.blob.core.windows.net/userimages/a84e6e54-967d-4ede-a47e-beff8ea205fb/533748cd-6928-45f1-a146-fca10c433d02image11.png> 26

BLYX. El modelo OSI y los protocolos de red [en línea]. [citado 1 Agosto, 2015]. Disponible en Internet: < URL: http://blyx.com/public/docs/pila_OSI.pdf >

26

Las ventajas de contar con un modelo de red dividido en capas radica en se divide la comunicación en partes más pequeñas y sencillas, lo que simplifica el aprendizaje, además se impide que los cambios realizados en una capa puedan afectar a las otras capas.

Capa de aplicación: junto con la capa de física son las únicas que interactúan con el usuario. Proporciona la interfaz que utiliza el usuario para el envío de mensajes de correo electrónico, transferencia de archivos (ftp), acceso de base de datos, servicios de directorio, acceso a archivos remotos, administración de la red etc 26.

Capa de presentación: Se encarga del formateo y cifrado de los datos, es un traductor que establece una sintaxis y una semántica de los datos transmitidos, proporciona la conversión e código de caracteres (por ejemplo de ASCI a EBCDICI) y maneja la compresión de los datos.

Capa de sesión: Tiene la función de establecer, administrar y finalizar las sesiones de comunicación entre hosts, además administra el intercambio de datos, sincronizando las capas de presentación de los host.

Capa de transporte: Controla el flujo de datos entre los host que establecen comunicación, garantizando que los mensajes de entregan sin errores, provee la difusión de mensajes a múltiples destinos, evalúa que el tamaño de los paquetes sea el requerido (el tamaño de los paquetes es establecida por la arquitectura de red) y proporciona la segmentación de mensajes.

Capa de red: Maneja la interconexión de redes; la selección de ruta, el direccionamiento y el enrutamiento. También se encarga de la asignación de direcciones lógico-físicas, la fragmentación de la trama y el control de tráfico de subred27.

Capa de enlace de datos: En el momento en que los paquetes de datos llegan a esta capa, se ubican en tramas (unidades de datos) que se encuentran definidas por la arquitectura de red implementada en el sistema (Token Ring, Ethernet, etc.), la capa de enlace de datos ofrece la transferencia de tramas de datos desde un nodo a otro por medio de la capa física, es decir que desplaza los datos por el enlace físico de comunicación hasta el nodo receptor Esta capa también maneja el control del tráfico, la secuenciación, la confirmación y la delimitación de las tramas27.

27

MICROSOFT, Las siete capas del modelo OSI y explicación de las funciones [en línea]. [citado 1 Agosto, 2015]. Disponible en Internet: < URL https://support.microsoft.com/kb/103884/es>

27

Capa física: Cuando llegan las tramas provenientes de la capa de enlace de datos, se convierten en una secuencia única de bits que se puede transmitir por el entorno físico. Adicionalmente, se encarga del uso del medio; define todo tipo de especificaciones eléctricas, mecánicas, y funcionales como lo son niveles de voltaje, temporización de cambio de voltaje, velocidad de datos físicos, conectores, componentes de interfaz con el medio de transmisión etc.

1.5.2.4. Modelo TCP/IP. El modelo de protocolo de control de transmisión y protocolo de internet es un estándar que describe el movimiento de datos entre los equipos host e internet, este modelo cuenta con una simplificación de capas con respecto al modelo OSI y los estándares de los protocolos abiertos28. El modelo de protocolo de control de transmisión y protocolo de internet es un estándar que describe el movimiento de datos entre los equipos host e internet, este modelo cuenta con una simplificación de capas con respecto al modelo OSI y los estándares de los protocolos abiertos29

Figura 2. Capas del modelo TCP/IP Ataques contra redes

Fuente: GARCÍA, Joaquín. Ataques contra redes [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://ocw.uoc.edu/computer-science-technology-and-multimedia/advanced-aspects-of-network-security/advanced-aspects-of-network-security/P06_M2107_01769.pdf>

28

UNIVERSIDAD NACIONAL DEL CENTRO. El modelo OSI. [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf> 29

UNIVERSIDAD NACIONAL DEL CENTRO. El modelo OSI [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: <www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf>

28

Capa De Aplicación. Manejas aspectos relacionados con la representación, la codificación y el control de diálogo.

Trabaja con los protocolos TCP, UDP, RTP¡Error! Marcador no definido..

Capa De Internet. Al llegar aquí, los paquetes son ingresados en datagramas IP, esta capa se encarga del enrutamiento de dichos datagramas. Trabaja con los protocolos IP, ICMP, ARP, RARP¡Error! Marcador no definido..

Capa De Interfaz de red. capa encargada de especificar los detalles de cómo son enviados físicamente los datos a través de la red, controlando los dispositivos de hardware que conforman la red. Trabaja con los protocolos Ethernet, Token Ring, FDDI, X.25, Frame Relay, RS-232, v.35¡Error! Marcador no definido.. 1.5.2.5. Protocolos Estándar para la gestión de red. Existen una serie de protocolos de comunicaciones utilizados en el internet, estos corren en diferentes capas y tienen diferentes funcionalidades, actualmente existen dos protocolos que son usados para la gestión de las redes; Simple Network Management Protocol y el Internet Control Message Protocol.

SNMP. Protocolo Simple de Administración de Red o Simple Network Management Protocol es un protocolo que opera en el nivel de aplicación del modelo estandarizado OSI. Fue concebido para el seguimiento del funcionamiento de redes, para la detección y análisis de fallos30. Es un protocolo soportado por muchos dispositivos de red como PC, servidores, enrutadores, switch, impresoras, etc. La información que se puede monitorear son parámetros simples y estandarizados, entre ellos, el nivel de tráfico de entrada y salida de un interfaz y el bando de ancha utilizado. Un gran atractivo, es el conjunto de operaciones que permiten administrar los dispositivos de la red de forma remota con el fin de recolectar información de funcionamiento, modificar parámetros y procesar alertas. Su principal desventaja es que depende del buen funcionamiento del sistema operativo, el software IP y el software del protocolo de transporte. Su funcionamiento se basa en cinco componentes principales; los nodos administrados, estaciones de administración (Network Management Stations), los agentes Proxy y la información de administración.

30

COMER, Douglas. Redes globales de información con Internet y TCP/IP. 3 ed. Mexico D.F. Prentice hall hispanoamericana, 2000. p.37.

29

Los nodos administrados son todos los dispositivos que son administrados y hacen parte de la infraestructura de la red, estos pueden ser “End Systems” (PCs, estaciones de trabajo y servidores), “Intermediate Systems” (Routers, Hubs o switches) o periféricos (impresoras, módems, UPS, etc.). En cada estación de trabajo debe funcionar un agente, que es un módulo de software o servicio activo de administración de red, el cual se encarga de administrar una base de datos local con la información del funcionamiento y estado actual del dispositivo (número de paquetes IP recibidos, memoria libre). Esta base de datos jerárquica es conocida como MIB (Management Information Base)31. Las estaciones de administración son computadores vinculadas a la red que se dedican la administración y por lo tanto ejecutan las aplicaciones que supervisan a los nodos administrados. Los agentes de proxy son indispensables para dispositivos que no cuentan con un agente activo SNMP, sin embargo la mayoría dispone de un agente incorporado o incorporable. El protocolo SNMP usa unidades de datos de protocolo PDU (Power distribution Unit) como variables para el monitoreo de la red, es el protocolo de mensaje que las estaciones de administración y agentes utilizan para comunicarse. Las operaciones principales del protocolo SNMP son GET, SET Y TRAP. Operación Get. La petición se hace desde la estación de administración para recuperar datos del agente32. Operación GetResponse. Es la respuesta que realiza el agente a la petición de la estación de administración32. Operación GetNex. Se usa para recorrer una tabla de objetos, es decir que una vez se haya usado el mensaje Get para obtener un valor de un objeto, es posible usar la petición GetNext para repetir la operación con el siguiente objeto de la tabla33.

31

AJDBSOFT. Protocolo Simple De Administración [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://www.ajpdsoft.com/modules.php?name=Encyclopedia&op=content&tid=793> 32

UNIVERSIDAD DE VALENCIA. Simple Network Management Protocol. [en línea]. [citado 4 Agosto, 2015]. Disponible en Internet: < URL: informatica.uv.es/iiguia/R/apuntes/snmp.ppt> 33

ROCHA, Diego Javier. Implementación de una MIB para la generación de mensajes de alerta para la administración de un servidor de correo electrónico [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: bibdigital.epn.edu.ec/bitstream/15000/1327/1/CD-2086.pdf>

30

Operación Set. Operación utilizada para modificar el valor de un objeto administrado, aquí la consola de administración establece los valores de los objetos en el agente32. Operación Trap. Es la manera en la que el agente le notifica a la consola de administración acerca de los sucesos de importancia por interrupción32 Figura 3. Operaciones protocolo SNMP

Fuente:JUNIPER, Alertas SNMP. [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: https://www.juniper.net/techpubs/software/aaa_802/imsaaa11/sw-imsaaa-admin/html/SNMP%20Messages5.gif>

ICMP. Protocolo de Mensajes de Control de Internet o Internet Control Message Protocol es un protocolo que trabaja sobre la capa de internet del modelo TCP/IP y permite administrar información relacionada con errores de los equipos en la red. Los mensajes ICMP van encapsulados en datagramas IP como se muestra en la Figura 4, por lo tanto es un protocolo usado para indicar errores del procesamiento de datagramas34.

34

GEOCITIES. Gestión y utilización de redes locales [en línea]. [citado 2 julio, 2015]. Disponible en Internet: < URL: http://www.geocities.ws/rincoes/redes07-icmp.pdf>

31

Figura 4. Encapsulamiento de mensajes ICMP

Fuente: USTUDY, Datagrams. [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://www.ustudy.in/sites/default/files/IP%20Datagram.png>

ICMP debe ser considerado parte del protocolo IP, siendo una utilidad para poder detectar errores en el transporte de datagramas a sus destinos. El protocolo ICMP cuenta con dos tipos de mensajes; los mensajes informativos y los mensajes de error; en los mensajes informativos el remitente envía una consulta a otra máquina que puede ser un host común o un router, y espera una respuesta; mientras que en los mensajes de error el software IP en un host o router detecta un problema al procesar un datagrama IP. En los mensajes de error se encuentran; “Destination unreachable”,”Source quench”, “Time exceeded”, “Parameter problem”, “Redirection”. Mientras que los mensajes informativos son: “Echo request or reply”, “Timestamp request or replay”, “Address mask rewuest or replay”, “Router Solicitation or “advertisement”, entre otros. Uno de las herramientas de depuración más famosas del protocolo ICMP es el “ping”, esta utilidad usa los mensajes informativos “Echo request” y “Echo reply”, y su funcionamiento básico consiste en que cualquier dispositivo IP que recibe un

32

mensaje “Echo request” deberá responder devuelta al dispositivo emisor por medio de un “Echo reply”35. 1.6. METODOLOGÍA Para el desarrollo de la herramienta de gestión de redes basada en la web, se adopta un híbrido entre dos metodologías; la metodología SCRUM, y la metodología de desarrollo de software tradicional en cascada La metodología SCRUM, nace de una percepción guiada al desarrollo de productos basados en el aprendizaje, la innovación y el cambio. Es una metodología que permite acometer problemas complejos adaptativos, a la vez que se posible entregar un producto de máximo valor36. Se ha seleccionado esta metodología debido a que es la indicada para proyectos donde la gestión regular de las expectativas del cliente es imprescindible, también, debido a que se necesitan obtener resultados rápidos y porque la innovación, la flexibilidad y la productividad son fundamentales37. Además de lo anterior, se selecciona también el modelo en cascada, debido a que es un modelo simple, fácil de seguir, de una sencilla planificación, y donde el desarrollo del software es una sucesión de etapas que producen productos intermedios lo que permite la recepción de recomendaciones por parte del usuario final al concluir de cada una de las fases como se muestra en la Figura 5.

35

UPV. El protocolo icmp [en línea]. [citado 5 Agosto, 2015]. Disponible en Internet: < URL: www.redes.upv.es/redesfi/transpa/T11_ICMP.pdf> 36

SCHWABER, Ken. SUTHERLAND,Jeff. La Guía de Scrum [en línea]. [citado 8 Agosto, 2015]. Disponible en Internet: < URL: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf> 37

PROYECTOS AGILES. Scrum [en línea]. [citado 8 Agosto, 2015]. Disponible en Internet: < URL: http://www.proyectosagiles.org/que-es-scrum>

33

Figura 5. Modelo en cascada

Fuente: BLOGSPOT. Modelo de Cascada [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL: http://cmapspublic3.ihmc.us/rid=1JMFTT8DP-1F5Q16M-SKL/ModeloCascada.jpg> Al utilizar una metodología híbrida entre SCRUM y el modelo en cascada, es posible el desarrollo de un proyecto de forma rápida, flexible, y de alta calidad aprovechando ciertos componentes de cada metodología y adaptándolo al beneficio de las partes.

34

2. ESPECIFICACIÓN DE REQUERIMIENTOS

2.1. INTRODUCCIÓN

El presente documento abarca en detalle, las funcionalidades, los tributos de calidad y las restricciones especificas a tener en cuenta en el desarrollo del sistema de monitoreo de la red de comunicaciones de Distribuidora Nissan S.A. 2.1.1. Propósito. El objetivo de este documento es orientar el desarrollo del proyecto de software por medio de una descripción detallada de los requisitos con lo que debe contar el sistema de monitoreo de la red de comunicaciones de Dinissan S.A. Este documento se encuentra dirigido a todas las personas interesadas en el desarrollo del proyecto, principalmente al área administrativa de informática y telecomunicaciones de Distribuidora Nissan S. A; y la comunidad académica de la Universidad Católica De Colombia.

2.1.2. Alcance. El sistema a desarrollar constituye una herramienta de apoyo

para el área de administración de redes de comunicaciones de distribuidora

Nissan S.A. con el fin de garantizar un servicio continuo y de alta calidad en todas

las sedes a nivel nacional. En específico, esta herramienta permitirá:

Obtener información de alta importancia para la toma oportuna de decisiones ante incidentes o irregularidades que se presenten en la red de comunicaciones. Efectuar un registro dinámico de la sedes que se van a monitorear. Realizar una comprobación en tiempo real del estado y el uso de la red de comunicaciones. Almacenar información del estado de la red con el fin de modelar tendencias y predecir fallas. Alertar al administrador vía correo electrónico cuando se presente la caída de un enlace. 2.1.3. Definiciones, acrónimos y abreviaturas. Las siguientes son las definiciones, acrónimos y abreviaturas utilizadas a en el desarrollo del proyecto.

35

2.1.3.1. ISP (proveedor de acceso a Internet). Compañía que ofrece acceso a internet, a cambio de una cuota. La conexión con el ISP se realiza a través de un acceso telefónico o una conexión de banda ancha. 2.1.3.2. PING. Es la forma abreviada para Packet Internet Groper y Es un comando para la administración de redes que sirve para verificar la conectividad de IP, este comando depende del protocolo ICMP38 39. 2.1.3.3. VPN (Redes Privadas Virtuales). Es una interconexión de varias redes locales LAN (Conexión de área local) que se encuentran separadas físicamente, su objetivo es que el grupo de áreas locales se comporte como si se tratara de una única red local, la interconexión entre estas redes se realiza a través de medios como Internet, Red telefónica conmutada o RTC a través de módem, Líneas alquiladas, RDSI o ISDN, X.25, Frame Relay, ATM, etc.)40. 2.1.3.4. ICMP (Internet Control Message Protocol). Es un protocolo de control que sirve para informar de los errores en el procesamiento de paquetes IP (Internet Protocol)21. 2.1.3.5. SNMP (Simple Network Management Protocol). Es un protocolo del nivel de aplicación del modelo OSI (Open Systems Interconection) que permite monitorizar características cualidades operativas de un Router22. 2.1.4. Resumen. El presente documento se encuentra estructurado en tres secciones; la primera sección se centra en contextualizar los alcances del proyecto y los términos necesarios para la comprensión del mismo, la segunda sección se enfoca en presentar más a fondo la funcionalidad del sistema, con sus características, funciones y restricciones del proyecto; y finalmente la tercera sección presenta de manera detallada cada una de las funcionalidades, requerimientos funcionales, y atributos de calidad que debe tener el sistema de monitoreo de la red de telecomunicaciones de distribuidora Nissan S.A.

38

CCM. La herramienta Ping. [en línea]. [citado 10 Agosto, 2015]. Disponible en Internet: < URL: http://es.ccm.net/contents/355-ping> 39

MICROSOFT. Uso del comando Ping. [en línea]. [citado 10 Agosto, 2015]. Disponible en Internet: < URL: https://technet.microsoft.com/es-es/library/cc732509%28v=ws.10%29.aspx> 40

GONZALEZ, Jose Luis. Redes Privadas Virtuales [en línea]. [citado 10 Agosto, 2015]. Disponible en Internet: < URL: http://isa.uniovi.es/~sirgo/doctorado/VPN.pdf>

36

2.2. DESCRIPCIÓN GENERAL 2.2.1. Perspectiva del producto. Se desarrollará un aplicativo web para facilitar la gestión de red comunicaciones de Distribuidora Nissan. Este aplicativo podrá ser accedido desde cualquier equipo que se encuentre conectado a red de internet corporativa. 2.2.2. Funcionalidad del producto. El sistema contará, entre otras cosas, con

un total de siete módulos; módulo de proveedores, módulo de sedes, módulo de

canales, módulo de contactos, módulo de activos, módulo de credenciales de

administración y módulo de monitoreo. Cada uno de los módulos anteriormente

mencionados presentará las opciones de agregar, editar, eliminar y consultar, del

mismo modo, cada transacción que se realice dentro del sistema será registrada y

notificada al administrador del sistema.

2.2.3. Características de los usuarios. Los usuarios presente en el aplicativo

son:

2.2.3.1. Administrador del sistema. Es el usuario encargado de administrar el

sistema y gestionar la información en cada módulo de la herramienta.

2.2.3.2. Agente. Son los usuarios encargados de la gestión de soluciones frente

a incidentes y problemas que se presenten en la red de telecomunicaciones, solo

tienen autorización para visualizar la información en los diferentes módulos del

aplicativo.

2.2.3.3. Invitado. Son los usuarios que realizan el soporte de primer nivel a

incidentes tecnológicos en las diferentes áreas de la compañía, deben estar

enterados si algún canal de la red de telecomunicaciones se ha caído, por lo tanto

solo tendrán acceso a la visualización del monitor que muestra el estado delos

canales.

37

2.2.4. Restricciones. La información será almacenada en una base de datos

relacional montada en Mysql con un diseño que será aprobado por el

administrador del área de telecomunicaciones.

Todas las credenciales que se almacenen dentro del sistema deberán ser guardadas bajo un algoritmo de encriptación, con el fin de mantener esta información segura. 2.2.5. Suposiciones y dependencias. Los equipos en el que se vaya a ejecutar la aplicación deben contar con un navegador de internet actualizado, de preferencia Mozilla Firefox o Google Chrome. Los equipos que deseen hacer uso de la aplicación deben estar conectados a la red corporativa de Distribuidora Nissan S.A. 2.3. REQUERIMIENTOS DE INTERFACE EXTERNA A continuación se detallan cada uno de los requisitos del sistema de monitoreo de la red de comunicaciones de Distribuidora Nissan S.A. 2.3.1. Interfaces de usuario. Las interfaces de usuario que se tienen en el proyecto son: 2.3.1.1. Administrador. El administrador accederá a la herramienta web y observará una interfaz para autenticarse. Si la autenticación es satisfactoria, el administrador se encontrará con un panel en el que aparecerán los vínculos para cada uno de los módulos del sistema (proveedores, sucursales, activos, contactos, ciudades, canales y monitoreo). En cada uno de los módulos existe una interfaz con diferentes campos de información y las opciones de editar, eliminar o agregar según lo requiera el administrador. Cualquier cambio que sea realizado debe ser guardado y lo podrá visualizar el usuario agente. 2.3.1.2. Invitado. Al acceder a la herramienta web, el usuario observará una interfaz para autenticarse. Si la autenticación es satisfactoria, se encontrará con un panel en el que aparecerán los vínculos para cada uno de los módulos del

38

sistema (proveedores, sucursales, activos, contactos, ciudades, canales y monitoreo). En cada uno de los módulos existe una interfaz con diferentes campos de información que el usuario agente únicamente podrá visualizar. 2.3.2. Interfaces de hardware. El sistema estará alojado en un equipo Dell Optiplex 9020, con procesador Intel Core i5, 4GB de memoria Ram, 500GB de disco duro y sistema operativo Windows 7. 2.3.3. Interfaces de software. El sistema de monitoreo de la red de

comunicaciones de Distribuidora Nissan S.A. será desarrollado en lenguaje PHP,

mientras que para el diseño, creación y administración de la base de datos

utilizará MySQL Workbench. Estas herramientas fueron escogidas debido a que

MySQL es un sistema de gestión de bases de datos de uso libre y por lo tanto no

es necesario incurrir en gastos, además de esto, se ha decidido desarrollar con

PHP, debido a que es un lenguaje libre y abierto y sus entornos de desarrollo son

de fácil desarrollo y configuración.

2.4. REQUERIMIENTOS FUNCIONALES Los requerimientos funcionales son identificados por medio de las letras RF y un número consecutivo, del mismo modo cada uno de los requerimientos se encuentra asociado a una interfaz, ya sea, la interfaz administrativa; con la letra A, la interfaz de agente con la letra G o la interfaz de invitado con la letra I. En la Tabla 1 también se especifica la prioridad de cada requerimiento (baja, media y alta) y el riesgo al implementar el requerimiento (despreciable, marginal y crítico). Tabla 1. Lista de Requerimientos Funcionales

ID Requerimiento funcional Interfaz Riesgo Prioridad

RF1 Gestionar acceso al sistema A, G Marginal Alta

RF2 Crear proveedor A Marginal Alta

RF3 Eliminar proveedor A Marginal Alta

RF4 Editar proveedor A Marginal Alta

RF5 Consultar proveedor A, G Marginal Media

RF6 Crear ciudad A Marginal Alta

RF7 Eliminar ciudad A Marginal Alta

RF8 Editar ciudad A Marginal Alta

39

RF9 Consultar ciudad A, G Marginal Media

RF10 Crear sucursal A Marginal Alta

RF11 Eliminar sucursal A Marginal Alta

RF12 Editar sucursal A Marginal Alta

RF13 Consultar sucursal A, G Marginal Media

RF14 Crear canal A Critico Alta

RF15 Eliminar canal A Critico Alta

RF16 Editar canal A Critico Alta

RF17 Consultar canal A, G Critico Media

RF18 Crear activo A Marginal Media

RF19 Eliminar activo A Marginal Media

RF20 Editar activo A Marginal Media

RF21 Consultar activo A, G Marginal Media

RF22 Crear contactos A Marginal Media

RF23 Eliminar contactos A Marginal Media

RF24 Editar contactos A Marginal Media

RF25 Consultar contactos A, G Marginal Media

RF26 Monitoreo de canales A, G, I Critico Alta

Fuente: El Autor

A continuación se realiza la especificación de cada uno de los requerimientos listados anteriormente. Tabla 2. Requerimiento Funcional 1

Identificador: Nombre: Requerimiento que utiliza:

RF1 Gestionar acceso al sistema

-

Actor: Prioridad de desarrollo:

Administrador, agente Alta

Descripción:

El administrador o el usuario ingresa sus datos de usuario y contraseña para posteriormente seleccionar el botón ingresar.

Precondición:

Ingresar los datos correctos en los campos de Usuario y Contraseña.

Entrada: Salida:

Usuario Contraseña

Acceso al sistema

Postcondición:

La aplicación valida los datos que se ingresaron y el usuario accederá a la ventana principal de la plataforma.

40

Manejo de situaciones anormales:

1. Se valida que los campos Usuario y Contraseña tengan un valor, de no ser así el sistema mostrará el siguiente mensaje: ¡Los campos “Usuario” y “Contraseña” no pueden estar vacíos!

2. Si intenta ingresar un usuario que no se encuentra registrado en la base de datos o la contraseña ingresada no pertenece al usuario, el sistema mostrará el siguiente mensaje: ¡El usuario o la contraseña ingresados no son válidos!

Fuente: El Autor

Tabla 3. Requerimiento Funcional 2


RF2 Crear proveedor RF1


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a un proveedor en los campos del formulario y luego hace clic sobre el botón “Crear Proveedor”.

Precondición:

El administrador debe tener la sesión activa en el sistema.

Entrada: Salida:

ID del proveedor Nit del proveedor Razón social Tipo de servicio (de telecomunicaciones/

de cableado) Teléfono de soporte técnico Nombre del ejecutivo de cuenta/

contacto Teléfono del ejecutivo de cuenta/

contacto Correo del ejecutivo de cuenta/ contacto

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información del nuevo proveedor creado.

Postcondición:

El sistema registra en la base de datos la información del nuevo proveedor ingresado en el formulario.


1. Si un campo del formulario se encuentra sin diligenciar cuando el usuario confirma el registro del proveedor en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”.

41

2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF3 Eliminar proveedor RF1, RF2


Administrador Alta

Descripción:

El administrador selecciona el proveedor que desea eliminar y luego hace clic sobre el icono “Eliminar Proveedor”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El proveedor que se desea eliminar debe estar previamente creado. El proveedor no debe estar asociado a ningún canal.

Entrada: Salida:

Hace clic sobre el icono “Eliminar

Proveedor” frente al proveedor que se desea eliminar.

Se muestra en pantalla el mensaje de eliminación exitosa.

Postcondición:

Inhabilitar el registro del proveedor seleccionado de la base de datos.


1. Si el proveedor que se trata de eliminar se encuentra asociado a un canal, el sistema mostrara el mensaje de error: “No se puede borrar - el proveedor se encuentra vinculado a un canal”.

Fuente: El Autor



RF4 Editar proveedor RF1, RF2


Administrador Alta

42

Descripción:

El administrador selecciona el proveedor que desea editar y hace clic sobre el icono “Editar Proveedor”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar Proveedor”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El proveedor que se desea editar debe estar previamente creado.

Entrada: Salida:

Campo(s) a ser actualizado(s) Se muestra en pantalla el mensaje de

actualización satisfactoria y se visualiza la información actualizada del proveedor.

Postcondición:

El sistema actualiza en la base de datos la información del proveedor.


1. Si un campo del formulario es obligatorio, y se encuentra sin diligenciar cuando el usuario confirma la actualización del proveedor en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF5 Consultar proveedor RF1, RF2


Administrador, invitados Media

Descripción:

El administrador accede al módulo de proveedores y visualiza la información de todos los proveedores que se encuentran registrados en el sistema.

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. El proveedor que se desea consultar debe estar previamente creado.

Entrada: Salida:

Ninguna Se muestra en pantalla el listado de los

proveedores que se encuentran registrados.

43

Postcondición:

El sistema muestra en pantalla el listado de los proveedores que se encuentran registrados con su información correspondiente.


1. Si no existe ningún proveedor registrado aparecerá el mensaje: “No existen proveedores registrados en el sistema”

Fuente: El Autor



RF6 Crear ciudad RF1


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a una ciudad en los

campos del formulario y luego hace clic sobre el botón “Crear ciudad”.

Precondición:

El administrador debe tener la sesión activa en el sistema.

Entrada: Salida:

ID de la ciudad Nombre de la ciudad Zona geográfica de la ciudad

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información de la nueva ciudad creada.

Postcondición:

El sistema registra en la base de datos la información de la nueva ciudad ingresada en el formulario.


1. Si un campo del formulario se encuentra sin diligenciar cuando el usuario confirma el registro de la ciudad en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor

44



RF7 Eliminar ciudad RF1, RF6


Administrador Alta

Descripción:

El administrador selecciona la ciudad que desea eliminar y luego hace clic sobre el icono “Eliminar Ciudad”.

Precondición:

El administrador debe tener la sesión activa en el sistema. La ciudad que se desea eliminar debe estar previamente creada. La ciudad de debe estar asociada a ninguna sucursal.

Entrada: Salida:

Hace clic sobre el icono “Eliminar Ciudad” frente a la ciudad que se desea eliminar.


Postcondición:

Inhabilitar el registro de la ciudad en la base de datos.


1. Si la ciudad que se trata de eliminar se encuentra asociado a una sucursal, el sistema mostrara el mensaje de error: “No se puede borrar – la ciudad se encuentra vinculada a una sucursal”.

Fuente: El Autor



RF8 Editar ciudad RF1, RF6


Administrador Alta

Descripción:

El administrador selecciona la ciudad que desea editar y hace clic sobre el icono “Editar Ciudad”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar Ciudad”.

45

Precondición:

El administrador debe tener la sesión activa en el sistema. La ciudad que se desea editar debe estar previamente creada.

Entrada: Salida:


actualización satisfactoria y se visualiza la información actualizada de la ciudad.

Postcondición:

El sistema actualiza en la base de datos la información de la ciudad.


1. Si un campo del formulario es obligatorio, y se encuentra sin diligenciar cuando el usuario confirma la actualización de la ciudad en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF9 Consultar ciudad RF1, RF6



Descripción:

El administrador accede al módulo de ciudades y visualiza la información de todas las ciudades que se encuentran registradas en el sistema.

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. La ciudad que se desea consultar debe estar previamente creado.

Entrada: Salida:

Ninguna Se muestra en pantalla el listado de las

ciudades que se encuentran registrados.

Postcondición:

El sistema muestra en pantalla el listado de las ciudades que se encuentran registrados con su información correspondiente.

46


1. Si no existe ninguna ciudad registrada aparecerá el mensaje: “No existen ciudades registradas en el sistema”

Fuente: El Autor



RF10 Crear sucursal RF1, RF6


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a una sucursal en los campos del formulario y luego hace clic sobre el botón “Crear sucursal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. Debe existir en el sistema al menos una ciudad para especificar la ubicación de la sucursal.

Entrada: Salida:

Nombre de la sucursal Nombre de la ciudad Centro de costo Dirección Teléfono Servicios Voz IP (Análoga o Troncal

SIP) Código de canal (Solo aplica para Voz

IP) IP LAN

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información de la nueva sucursal creada.

Postcondición:

El sistema registra en la base de datos la información de la nueva sucursal ingresada en el formulario.


1. Si no existe una ciudad creada, el sistema mostrará el mensaje “Debe crear una ciudad antes de crear una sucursal”. 2. Si un campo del formulario se encuentra sin diligenciar cuando el usuario confirma el registro de la sucursal en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”.

47

3. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF11 Eliminar sucursal RF1, RF6, RF10


Administrador Alta

Descripción:

El administrador selecciona la sucursal que desea eliminar y luego hace clic sobre el icono “Eliminar sucursal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. La sucursal que se desea eliminar debe estar previamente creada. La sucursal no debe estar asociada a ningún canal.

Entrada: Salida:

Hace clic sobre el icono “Eliminar sucursal” frente a la sucursal que se desea eliminar.


Postcondición:

Inhabilitar el registro de la sucursal en la base de datos.


1. Si la sucursal que se trata de eliminar se encuentra asociada a un canal, el sistema mostrará el mensaje de error: “No se puede borrar – la sucursal se encuentra vinculada a un canal”.

Fuente: El Autor



RF12 Editar sucursal RF1, RF6, RF10


Administrador Alta

48

Descripción:

El administrador selecciona la sucursal que desea editar y hace clic sobre el icono “Editar Sucursal”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar Sucursal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. La sucursal que se desea editar debe estar previamente creada.

Entrada: Salida:


actualización satisfactoria y se visualiza la información actualizada de la sucursal.

Postcondición:

El sistema actualiza en la base de datos la información de la sucursal.


1. Si un campo del formulario es obligatorio, y se encuentra sin diligenciar cuando el usuario confirma la actualización de la sucursal en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF13 Consultar sucursal RF1, RF10



Descripción:

El administrador accede al módulo de sucursales y visualiza la información de todas las sucursales que se encuentran registradas en el sistema.

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. La sucursal que se desea consultar debe estar previamente creada.

Entrada: Salida:

Ninguna Se muestra en pantalla el listado de las

sucursales que se encuentran registradas.

49

Postcondición:

El sistema muestra en pantalla el listado de las sucursales que se encuentran registrados con su información correspondiente.


1. Si no existe ninguna sucursal registrada aparecerá el mensaje: “No existen sucursales registradas en el sistema”

Fuente: El Autor



RF14 Crear canal RF1, RF2, RF10


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a un canal en los campos del formulario y luego hace clic sobre el botón “Crear canal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. Debe existir en el sistema al menos un proveedor para asociarlo al canal. Debe existir en el sistema al menos una sucursal para asociarla al canal.

Entrada: Salida:

Nombre del proveedor Nombre de la sucursal ID del canal Latencia normal Latencia promedio mínima Latencia promedio alta Latencia promedio superior a 130 Tipo de servicio (Dedicado, banda

ancha) Medio del servicio (Radio frecuencia,

hfc, fibra) IP WAN Modo de operación (Backup – principal) Ancho de banda Segmento de red. Costo de canal mensual

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información del nuevo canal creado.

50

Postcondición:

El sistema registra en la base de datos la información del nuevo canal ingresado en el formulario.


1. Si no existe un proveedor creado, el sistema mostrará el mensaje “Debe crear un proveedor antes de crear un canal”. 2. Si no existe una sucursal creada, el sistema mostrará el mensaje “Debe crear una sucursal antes de crear un canal”. 2. Si un campo del formulario se encuentra sin diligenciar cuando el usuario confirma el registro de la sucursal en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”. 3. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF15 Eliminar canal RF1, RF14


Administrador Alta

Descripción:

El administrador selecciona el canal que desea eliminar y luego hace clic sobre el icono “Eliminar canal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El canal que se desea eliminar debe estar previamente creado.

Entrada: Salida:

Hace clic sobre el icono “Eliminar canal” frente al canal que se desea eliminar.


Postcondición:

Inhabilitar el registro del canal en la base de datos.

51


No aplica

Fuente: El Autor



RF16 Editar canal RF1, RF2, RF10, RF14


Administrador Alta

Descripción:

El administrador selecciona el canal que desea editar y hace clic sobre el icono “Editar Canal”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar Canal”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El canal que se desea editar debe estar previamente creado.

Entrada: Salida:


actualización satisfactoria y se visualiza la información actualizada del canal.

Postcondición:

El sistema actualiza en la base de datos la información del canal.


1. Si un campo del formulario es obligatorio, y se encuentra sin diligenciar cuando el usuario confirma la actualización de la canal en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF17 Consultar canal RF1, RF14



52

Descripción:

El administrador accede al módulo de canales y visualiza la información de todos los canales que se encuentran registrados en el sistema.

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. El canal que se desea consultar debe estar previamente creado.

Entrada: Salida:


canales que se encuentran registrados.

Postcondición:

El sistema muestra en pantalla el listado de los canales que se encuentran registrados con su información correspondiente.


1. Si no existe ningún canal registrado aparecerá el mensaje: “No existen canales registrados en el sistema”

Fuente: El Autor



RF18 Crear activo RF1, RF10


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a un activo en los campos del formulario y luego hace clic sobre el botón “Crear activo”.

Precondición:

El administrador debe tener la sesión activa en el sistema. Debe existir en el sistema al menos una sucursal para asociarla al activo.

Entrada: Salida:

Nombre de la sucursal Tipo de activo (Switch, Access Point,

servidor y UPS) Marca Serial Código de activo fijo Descripción Estado (nuevo, reemplazo por garantía,

dado de baja)

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información del nuevo activo creado.

53

Si el estado es reemplazo por garantía Fecha de inicio de garantía Si el estado es nuevo Fecha de puesta en marcha Ultima fecha de revisión Fecha finalización de la garantía

Postcondición:

El sistema registra en la base de datos la información del nuevo activo ingresado en el formulario.


2. Si no existe una sucursal creada, el sistema mostrará el mensaje “Debe crear una sucursal antes de crear un activo”. 2. Si un campo del formulario se encuentra sin diligenciar cuando el usuario confirma el registro del activo en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”. 3. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF19 Eliminar activo RF1, RF18


Administrador Alta

Descripción:

El administrador selecciona el activo que desea eliminar y luego hace clic sobre el icono “Eliminar activo”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El activo que se desea eliminar debe estar previamente creado.

Entrada: Salida:

Hace clic sobre el icono “Eliminar activo” frente al activo que se desea eliminar.


54

Postcondición:

Inhabilitar el registro del activo en la base de datos.


No aplica

Fuente: El Autor



RF20 Editar activo RF1, RF18, RF10


Administrador Alta

Descripción:

El administrador selecciona el activo que desea editar y hace clic sobre el icono “Editar activo”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar activo”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El activo que se desea editar debe estar previamente creado.

Entrada: Salida:


actualización satisfactoria y se visualiza la información actualizada del activo.

Postcondición:

El sistema actualiza en la base de datos la información del activo.


1. Si un campo del formulario es obligatorio, y se encuentra sin diligenciar cuando el usuario confirma la actualización del activo en el sistema, aparecerá un mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF21 Consultar canal RF1, RF18

55



Descripción:

El administrador accede al módulo de activos y visualiza la información de todos los activos que se encuentran registrados en el sistema.

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. El activo que se desea consultar debe estar previamente creado.

Entrada: Salida:


activos que se encuentran registrados.

Postcondición:

El sistema muestra en pantalla el listado de los activos que se encuentran registrados con su información correspondiente.


1. Si no existe ningún activo registrado aparecerá el mensaje: “No existen activos registrados en el sistema”

Fuente: El Autor



RF22 Crear contacto RF1, RF10


Administrador Alta

Descripción:

El administrador ingresa la información correspondiente a un contacto en los campos del formulario y luego hace clic sobre el botón “Crear contacto”.

Precondición:

El administrador debe tener la sesión activa en el sistema. Debe existir en el sistema al menos una sucursal para asociarla al contacto.

Entrada: Salida:

Nombre de la sucursal Nombre del contacto Teléfonos del contacto Cargo (opcional)

Se muestra en pantalla el mensaje de registro satisfactorio y se visualiza la información del nuevo contacto creado.

56

Postcondición:

El sistema registra en la base de datos la información del nuevo contacto ingresado en el formulario.


2. Si no existe una sucursal creada, el sistema mostrará el mensaje “Debe crear una sucursal antes de crear un contacto”. 2. Si los campos nombre de la sucursal, nombre del contacto o teléfonos del contacto se encuentran sin diligenciar cuando el usuario confirma el registro del contacto en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”. 3. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF23 Eliminar contacto RF1, RF22


Administrador Alta

Descripción:

El administrador selecciona el contacto que desea eliminar y luego hace clic sobre el icono “Eliminar contacto”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El contacto que se desea eliminar debe estar previamente creado.

Entrada: Salida:

Hace clic sobre el icono “Eliminar contacto” frente al contacto que se desea eliminar.


Postcondición:

Inhabilitar el registro del contacto en la base de datos.


No aplica

Fuente: El Autor

57



RF24 Editar contacto RF1, RF10, RF22


Administrador Alta

Descripción:

El administrador selecciona el contacto que desea editar y hace clic sobre el icono “Editar contacto”, luego ingresa la información en los campos que desea actualizar y posteriormente hace clic sobre el botón “Actualizar contacto”.

Precondición:

El administrador debe tener la sesión activa en el sistema. El contacto que se desea editar debe estar previamente creado.

Entrada: Salida:


actualización satisfactoria y se visualiza la información actualizada del contacto.

Postcondición:

El sistema actualiza en la base de datos la información del contacto.


1. Si los campos nombre de la sucursal, nombre del contacto o teléfonos del contacto se encuentran sin diligenciar cuando el usuario confirma la actualización del contacto en el sistema, aparecerá el mensaje error: “El campo no puede estar vacío”. 2. Si un dato ingresado en el formulario tiene un formato incorrecto (se excede la extensión del dato, se ingresan caracteres no admitidos, etc.), se visualizará el mensaje de error “Formato de dato incorrecto” y la causa correspondiente.

Fuente: El Autor



RF25 Consultar contacto RF1, RF22



Descripción:

El administrador accede al módulo de contactos y visualiza la información de todos los contactos que se encuentran registrados en el sistema.

58

Precondición:

El administrador o el agente deben tener la sesión activa en el sistema. El contacto que se desea consultar debe estar previamente creado.

Entrada: Salida:


contactos que se encuentran registrados.

Postcondición:

El sistema muestra en pantalla el listado de los contactos que se encuentran registrados con su información correspondiente.


1. Si no existe ningún contacto registrado aparecerá el mensaje: “No existen contactos registrados en el sistema”.

Fuente: El Autor



RF26 Monitoreo de canales RF1, RF14


Administrador, agente Alta

Descripción:

El administrador accede al módulo de monitoreo de canales y visualiza el estado de cada uno de los canales por medio de un color que indica el nivel de latencia correspondiente.

Precondición:

El administrador o el agente debe tener la sesión activa en el sistema.

Entrada: Salida:

Ninguna Se muestra en pantalla un panel que

ilustra el nivel de latencia por canal.

Postcondición:

El sistema muestra en pantalla el listado de los contactos que se encuentran registrados con su información correspondiente.


1. Si no existe ningún canal registrado aparecerá el mensaje: “No existen canales registrados en el sistema para el monitoreo”

Fuente: El Autor

59

2.5. REQUERIMIENTOS NO FUNCIONALES Los requerimientos no funcionales o atributos de calidad con los que contará el sistema se listan en la Tabla 28.

Tabla 28. Lista de Requerimientos No Funcionales

ID Requerimiento no

0funcional

Riesgo Prioridad

RNF1 Seguridad Critico Alta

RNF2 Disponibilidad Critico Alta

RNF3 Mantenibilidad Critico Alta

RNF4 Fiabilidad Marginal Alta

RNF5 Portabilidad Marginal Media

Fuente: El Autor

A continuación se realiza la especificación de cada uno de los requerimientos listados anteriormente.

Tabla 29. Requerimiento No Funcional 1

Identificador: Nombre: Prioridad de desarrollo:

RNF1 Seguridad Alta

Descripción:

Propiedad del sistema que bloquea el control de acceso a usuarios no

autorizados con el fin de prevenir la modificación y eliminación de información.

Criterio conceptual:

El sistema verifica por medio de un nombre de usuario y una contraseña el

control de acceso de un administrado o de un agente, de lo contrario, no se

podrá acceder.

Fuente: El Autor

60



RNF2 Disponibilidad Alta

Descripción:

Es la propiedad del sistema que asegura la continuidad operacional del mismo,

las 24 horas del día, los siete días de la semana.

Fuente: El Autor Tabla 31. Requerimiento No Funcional 3


RNF3 Mantenibilidad Alta

Descripción:

Propiedad del sistema que proporciona facilidad para realizar modificaciones con

el fin de corregir fallos, mejorar su rendimiento u otros atributos o adaptarse a

cambios en el entorno.


La codificación del sistema debe tener una estructura de bajo acoplamiento, de forma que si se debe realizar un cambio en un módulo, este cambio sea invisible para los otros módulos o los afecte en lo más mínimo posible.

Fuente: El Autor



RNF4 Fiabilidad Alta

Descripción:

Propiedad del sistema de presentar el mínimo número de errores posibles

durante su operación.

61


La herramienta no deberá presentar fallos críticos en su operación, en caso de presentarse, deberán ser corregidos en menos de 3 horas.

Fuente: El Autor



RNF5 Portabilidad Media

Descripción:

Cualidad de que una aplicación sea ejecutada fácilmente sobre diferentes

plataformas de software/hardware..


La herramienta podrá ser accedida desde cualquier ordenador que cuente con un navegador web.

Fuente: El Autor

62

3. DISEÑO

En la presente sección se presentan los diagramas UML que describen el comportamiento interno y externo del sistema de monitoreo de red de Distribuidora Nissan S.A.

3.1. CASOS DE USO

Los casos de uso son identificados por medio de las letras CU y un número consecutivo. En la Tabla 34 se ilustra el listado de los casos de uso que describen la relación y las dependencias entre las actividades y los actores en un proceso determinado.

Tabla 34. Lista de Casos De Uso

ID Requerimiento funcional Actor

CU1 Autenticar Ingreso Administrador, agente

CU2 Crear proveedor Administrador

CU3 Eliminar proveedor Administrador

CU4 Editar proveedor Administrador

CU5 Consultar proveedor Administrador, agente

CU6 Crear sede Administrador

CU7 Eliminar sede Administrador

CU8 Editar sede Administrador

CU9 Consultar sede Administrador, agente

CU10 Crear canal Administrador

CU11 Eliminar canal Administrador

CU12 Editar canal Administrador

CU13 Consultar canal Administrador, agente

CU14 Crear activo Administrador

CU15 Eliminar activo Administrador

CU16 Editar activo Administrador

CU17 Consultar activo Administrador, agente

CU18 Crear contactos Administrador

CU19 Eliminar contactos Administrador

CU20 Editar contactos Administrador

CU21 Consultar contactos Administrador, agente

CU22 Crear credencial de administración

Administrador

CU23 Eliminar credencial de administración

Administrador

63

CU24 Editar credencial de administración

Administrador

CU25 Consultar credencial de administración

Administrador, agente

CU26 Visualizar Monitor de Canales

Administrador, agente, invitado

Fuente: El Autor

A continuación se ilustran los diagramas de casos de uso, con las respectivas especificaciones de cada uno.

Cuadro 1. Casos De Uso Autenticación

Figura 6. Caso de Uso Autenticar Usuario

Fuente: El Autor

Descripción:

El sistema debe permitir a los administrativos e invitados acceder al sistema de información

mediante la identificación por medio de credenciales (Login) provistas por el administrador del

sistema y, así mismo permitir a los administrativos e invitados cerrar el acceso personal sobre

el sistema de información (Logout).

Fuente: El Autor

64

Tabla 35. Caso de Uso 1

Fuente: El Autor


Identificador: Nombre

CU1 Autenticar ingreso

Actor: Versión:

Docentes, Administradores 1.0

Curso Normal Alternativas

1) El usuario diligencia el formulario de acceso al sistema. Los campos a llenar son los siguientes:

Nombre del campo

Tipo de dato Longitud

Usuario

Cadena de caracteres

6 - 50

Caracteres

Contraseña


6 - 50

Caracteres

2) El usuario oprime el botón “Iniciar Sesión”.

3) Al oprimir el botón “Iniciar Sesión” se carga la página principal del sistema (Módulos del sistema).

3.1) Si las credenciales no están almacenadas en la base de datos o los datos digitados son incorrectos.


CU2 Crear proveedor

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de proveedores.

2) El usuario oprime el botón “Crear Proveedor”.

3) Al oprimir el botón “Crear Proveedor”, el sistema carga un formulario además de los botones “Crear proveedor” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de proveedores.

65

Fuente: El Autor

4) El usuario mantiene o actualiza todos los campos del formulario. Los campos son:

Nombre del campo

Tipo de dato

Longitud

“Nit del proveedor”


1 – 20 caracteres

“Nombre del proveedor”


1 – 50 caracteres

“Tipo de servicio que ofrece”


1 – 50 caracteres

“Teléfono” Cadena de caracteres

1 – 50 caracteres

“Correo electrónico”


1 – 50 caracteres

“Nombre ejecutivo de cuenta”


1 – 50 caracteres

“Teléfono ejecutivo de cuenta”


1 – 50 caracteres

“Correo ejecutivo de cuenta”


1 – 50 caracteres

5) El usuario oprime el botón “Crear proveedor”

6) El sistema graba los datos del proveedor

6.1) Si el sistema no graba los datos, informa que no fue posible crear el proveedor

66

Cuadro 2. Gestión De Proveedores

Figura 7. Caso de Uso Gestión De Proveedores

Fuente: El Autor

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de los proveedores

(agregar, editar eliminar y consultar), así mismo, al usuario agente, el sistema debe permitirle

realizar únicamente la consulta de información de los proveedores registrados en el sistema.

Fuente: El Autor


Fuente: El Autor


CU3 Eliminar proveedor

Actor: Versión:

Administrador 1.0



2) El usuario oprime el botón “Eliminar Proveedor”.

3) Al seleccionar el proveedor a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación del proveedor.


4) El usuario oprime el botón “Si” de la ventana de dialogo.

4.1) El usuario oprime el botón “No” para cancelar la acción eliminar.

5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar el proveedor

67


Fuente: El Autor


CU4 Editar proveedor

Actor: Versión:

Administrador 1.0



2) El usuario oprime el botón “Editar Proveedor”.

3) Al oprimir el botón “Editar Proveedor”, el sistema carga un formulario de edición, además de los botones “Actualizar proveedor” y “Regresar”.



Nombre del campo

Tipo de dato

Longitud

“Nit del proveedor”


1 – 20 caracteres

“Nombre del proveedor”


1 – 50 caracteres

“Tipo de servicio que ofrece”


1 – 50 caracteres

“Teléfono” Cadena de caracteres

1 – 50 caracteres



1 – 50 caracteres

“Nombre ejecutivo de cuenta”


1 – 50 caracteres

“Teléfono ejecutivo de cuenta”


1 – 50 caracteres

“Correo ejecutivo de cuenta”


1 – 50 caracteres

5) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar datos del proveedor”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información del proveedor

6) El sistema graba los datos actualizados.

68


Fuente: El Autor

Cuadro 3. Gestión De Sedes.

Figura 8. Caso de Uso Gestión De Sedes (centro de costos)

Fuente: El Autor

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de las sedes o centros de

costos (agregar, editar eliminar y consultar), así mismo, al usuario agente, el sistema debe

permitirle realizar únicamente la consulta de información de las sedes registradas en el sistema.

Fuente: El Autor


CU5 Consultar proveedor

Actor: Versión:

Administrador, agente 1.0



2) El usuario oprime el botón “Consultar Proveedor”.

3) Al seleccionar la opción consultar proveedores; el sistema carga una lista con los detalles de todos los proveedores existentes en el sistema

69


Fuente: El Autor


CU6 Crear sede

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Sedes”.

2) El usuario oprime el botón “Crear Sede”.

3) Al oprimir el botón “Crear Sede”, el sistema carga un formulario además de los botones “Crear sede” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de sedes.

4) El usuario llena todos los campos del formulario. Los campos a llenar son:

Nombre del campo

Tipo de dato

Longitud

“Nombre de la sede ”


1 – 50 caracteres

“Teléfono de la sede”


1 – 50 caracteres

“Segmento de red ”


1 – 50 caracteres

“Servicio de Voz IP”


2 caracteres



1 – 50 caracteres

“Código de canal”

Numérico 1 - 99999

“Diagrama de red”


1 – 50 caracteres

5) El usuario oprime el botón “Crear sede”

6) El sistema graba los datos de la sede 6.1) Si el sistema no graba los datos, informa que no fue posible crear la sede

70


Fuente: El Autor



CU7 Eliminar sede

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Sedes”.

2) El usuario oprime el botón “Eliminar Sede”.

3) Al seleccionar la sede a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación de la sede.




5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar la sede.


CU8 Editar sede

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de sedes.

2) El usuario oprime el botón “Editar Sede”.

3) Al oprimir el botón “Editar Sede”, el sistema carga un formulario de edición, además de los botones “Actualizar Sede” y “Regresar”.



Nombre del campo

Tipo de dato

Longitud

“Nombre de la sede ”


1 – 50 caracteres

“Teléfono de la sede”


1 – 50 caracteres

“Segmento de red ”


1 – 50 caracteres

“Servicio de Voz IP”

Cadena de

2 caracteres

71

Fuente: El Autor


Fuente: El Autor

Cuadro 4. Gestión De Canales

Figura 9. Caso de Uso Gestión De Canales

Fuente: El Autor

caracteres



1 – 50 caracteres

“Código de canal”

Numérico 1 - 99999

“Diagrama de red”


1 – 50 caracteres

5) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar datos de la sede”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información de la sede.



CU9 Consultar sede

Actor: Versión:



1) El usuario ingresa al módulo de sedes.

2) El usuario oprime el botón “Consultar Sede”.

3) Al seleccionar la opción consultar sedes; el sistema carga una lista con los detalles de todas las sedes existentes en el sistema

72

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de los canales (agregar,

editar eliminar y consultar), así mismo, al usuario agente, el sistema debe permitirle realizar

únicamente la consulta de información de los canales registrados en el sistema.

Fuente: El Autor

Tabla 44. Caso de Uso 10 Identificador: Nombre

CU10 Crear canal

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Canales”.

2) El usuario oprime el botón “Crear Canal”.

3) Al oprimir el botón “Crear Canal”, el sistema carga un formulario además de los botones “Crear Canal” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de canales.


Nombre del campo

Tipo de dato

Longitud

“Nombre del proveedor ”


1 – 50 caracteres

“Nombre sede”


1 – 50 caracteres

“Ancho de banda ”


2 – 6 caracteres

“Tipo de servicio”


1 – 50 caracteres

“Medio del servicio”


1 – 50 caracteres

“Modo de operación”


1 – 50 caracteres

“Segmento de red”


1 – 50 caracteres

73

Fuente: El Autor


Fuente: El Autor

“Fecha de inicio del contrato”

Fecha DD/MM/AA

“Valor del costo mensual”

Numérico - decimal

1 -99999999999

“SLA” Cadena de caracteres

1 – 50 caracteres

“Nit asociado”


1 – 15 caracteres

“Estado del canal”


1 carácter

“Valor latencia normal”

Numérico - promedio

0 -100

“Valor latencia promedio”


0 -100

“Valor latencia alta”


0 -100

“Valor latencia superior”


0 -100

5) El usuario oprime el botón “Crear canal”

6) El sistema graba los datos del canal 6.1) Si el sistema no graba los datos, informa que no fue posible crear el canal


CU11 Eliminar canal

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Canales”.

2) El usuario oprime el botón “Eliminar Canal”.

3) Al seleccionar el canal a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación del canal.




5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar el canal.

74


CU12 Editar canal

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de canales.

2) El usuario oprime el botón “Editar Canal”.

3) Al oprimir el botón “Editar Canal”, el sistema carga un formulario de edición, además de los botones “Actualizar Canal” y “Regresar”.



Nombre del campo

Tipo de dato

Longitud

“Nombre del proveedor ”


1 – 50 caracteres

“Nombre sede”


1 – 50 caracteres

“Ancho de banda ”


2 – 6 caracteres

“Tipo de servicio”


1 – 50 caracteres

“Medio del servicio”


1 – 50 caracteres

“Modo de operación”


1 – 50 caracteres

“Segmento de red”


1 – 50 caracteres

“Fecha de inicio del contrato”

Fecha DD/MM/AA

“Valor del costo mensual”

Numérico - decimal

1 -99999999999

“SLA” Cadena 1 – 50

75

Fuente: El Autor


Fuente: El Autor

de caracteres

caracteres

“Nit asociado”


1 – 15 caracteres

“Estado del canal”


1 carácter

“Valor latencia normal”


0 -100

“Valor latencia promedio”


0 -100

“Valor latencia alta”


0 -100

“Valor latencia superior”


0 -100

5) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar datos del canal”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información del canal.



CU13 Consultar canal

Actor: Versión:



1) El usuario ingresa al módulo de canales.

2) El usuario oprime el botón “Consultar Canal”.

3) Al seleccionar la opción consultar canales; el sistema carga una lista con los detalles de todos los canales existentes en el sistema

76

Cuadro 5. Gestión De Activos

Figura 10. Caso de Uso Gestión De Activos

Fuente: El Autor

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de los activos (agregar,


únicamente la consulta de información de los activos registrados en el sistema.

Fuente: El Autor


CU14 Crear activo

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Activos”.

2) El usuario oprime el botón “Crear Activo”.

3) Al oprimir el botón “Crear Activo”, el sistema carga un formulario además de los botones “Crear Activo” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de activos.

77

Fuente: El Autor


Nombre del campo

Tipo de dato

Longitud

“Código activo fijo ”


1 – 50 caracteres

“Nombre sede”


1 – 50 caracteres

“Descripción ”


1 – 50 caracteres

“Marca” Cadena de caracteres

1 – 50 caracteres

“Serial” Cadena de caracteres

1 – 50 caracteres

“Observación”


1 – 100 caracteres

“Estado” Cadena de caracteres

1 carácter

“Fecha de inicio del activo”

Fecha DD/MM/AA

“Fecha de revisión del activo”

Fecha DD/MM/AA

“Fecha de finalización de garantía”

Fecha DD/MM/AA

“Fecha de inicio de garantía”

Fecha DD/MM/AA

5) El usuario oprime el botón “Crear activo”

6) El sistema graba los datos del activo 6.1) Si el sistema no graba los datos, informa que no fue posible crear el activo

78


Fuente: El Autor



CU15 Eliminar canal

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Activos”.

2) El usuario oprime el botón “Eliminar Activo”.

3) Al seleccionar el canal a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación del activo.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de activos.



5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar el activo.


CU16 Editar activo

Actor: Versión:

Administrador 1.0


2) El usuario ingresa al módulo de activos.

3) El usuario oprime el botón “Editar Activo”.

4) Al oprimir el botón “Editar Activo”, el sistema carga un formulario de edición, además de los botones “Actualizar Activo” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de Activos.

79

Fuente: El Autor



Nombre del campo

Tipo de dato

Longitud

“Código activo fijo ”


1 – 50 caracteres

“Nombre sede”


1 – 50 caracteres

“Descripción ”


1 – 50 caracteres

“Marca” Cadena de caracteres

1 – 50 caracteres

“Serial” Cadena de caracteres

1 – 50 caracteres

“Observación”


1 – 100 caracteres

“Estado” Cadena de caracteres

1 carácter

“Fecha de inicio del activo”

Fecha DD/MM/AA

“Fecha de revisión del activo”

Fecha DD/MM/AA

“Fecha de finalización de garantía”

Fecha DD/MM/AA

“Fecha de inicio de garantía”

Fecha DD/MM/AA

6) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar datos del activo”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información del activo.



CU17 Consultar activo

Actor: Versión:



1) El usuario ingresa al módulo de activos.

2) El usuario oprime el botón “Consultar Activo”.

80

Fuente: El Autor

Cuadro 6. Gestión De Contactos

Figura 11. Caso de Uso Gestión De Contactos

Fuente: El Autor

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de los contactos (agregar,


únicamente la consulta de información de los contactos registrados en el sistema.

Fuente: El Autor


3) Al seleccionar la opción consultar activos; el sistema carga una lista con los detalles de todos los activos existentes en el sistema


CU18 Editar activo

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de

81

Fuente: El Autor


“Contactos”.

2) El usuario oprime el botón “Crear Contacto”.

3) Al oprimir el botón “Crear Contacto”, el sistema carga un formulario además de los botones “Crear Contacto” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de contactos.


Nombre del campo

Tipo de dato

Longitud

“Nombre del contacto ”


1 – 50 caracteres

“Teléfono(s) del contacto”


1 – 50 caracteres

“Cargo del contacto”


1 – 50 caracteres

“Sede asociada”


1 – 50 caracteres

5) El usuario oprime el botón “Crear contacto”

6) El sistema graba los datos del contacto 6.1) Si el sistema no graba los datos, informa que no fue posible crear el contacto


CU19 Eliminar contacto

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Contactos”.

2) El usuario oprime el botón “Eliminar Contacto”.

3) Al seleccionar el contacto a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación del contacto.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de contactos.



82

Fuente: El Autor


Fuente: El Autor

5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar el contacto.


CU20 Editar contacto

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de contactos.

2) El usuario oprime el botón “Editar Contacto”.

3) Al oprimir el botón “Editar Contacto”, el sistema carga un formulario de edición, además de los botones “Actualizar Contacto” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de Contactos.


Nombre del campo

Tipo de dato

Longitud

“Nombre del contacto ”


1 – 50 caracteres

“Teléfono(s) del contacto”


1 – 50 caracteres

“Cargo del contacto”


1 – 50 caracteres

“Sede asociada”


1 – 50 caracteres

5) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar datos del contacto”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información del contacto.


83


Fuente: El Autor

Cuadro 7. Gestión De Credenciales De Administración

Figura 12. Caso de Uso Gestión De Credenciales De Administración

Fuente: El Autor

Descripción:

El sistema debe permitir al usuario administrador realizar la gestión de las credenciales de

administración para los activos de computo que corresponda (agregar, editar eliminar y

consultar), así mismo, al usuario agente, el sistema debe permitirle realizar únicamente la

consulta de información de credenciales de administración registrados en el sistema.

Fuente: El Autor


CU21 Consultar contacto

Actor: Versión:



1) El usuario ingresa al módulo de contactos.

2) El usuario oprime el botón “Consultar contactos”.

3) Al seleccionar la opción consultar contactos; el sistema carga una lista con los detalles de todos los activos existentes en el sistema

84


Fuente: El Autor



CU22 Crear credencial de administración

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de “Credenciales de administración”.

2) El usuario oprime el botón “Crear Credencial de administración”.

3) Al oprimir el botón “Crear Credencial de administración”, el sistema carga un formulario además de los botones “Crear Credencial de administración” y “Regresar”.

3.1) El usuario oprime el botón “Regresar” para cancelar el proceso y volver al módulo de Credenciales de administración.


Nombre del campo

Tipo de dato

Longitud

“Activo fijo asociado ”


1 – 50 caracteres

“Servicio” Cadena de caracteres

1 – 50 caracteres

“Usuario” Cadena de caracteres

1 – 50 caracteres

“Password” Cadena de caracteres

1 – 50 caracteres

5) El usuario oprime el botón “Crear Credencial de administración”

6) El sistema graba los datos de la Credencial de administración

6.1) Si el sistema no graba los datos, informa que no fue posible crear la Credencial de administración


CU23 Eliminar Credencial de administración

Actor: Versión:

Administrador 1.0

85

Fuente: El Autor



1) El usuario ingresa al módulo de “Credenciales de administración”.

2) El usuario oprime el botón “Eliminar Credencial de administración”.

3) Al seleccionar el contacto a eliminar, el sistema despliega una ventana de dialogo para confirmar la eliminación de la credencial.




5) El sistema elimina los datos. 5.1) Si el sistema no elimina los datos, informa que no fue posible eliminar la Credencial de administración.


CU24 Editar credencial de administración

Actor: Versión:

Administrador 1.0


1) El usuario ingresa al módulo de Credenciales de administración.

2) El usuario oprime el botón “Editar Credencial de administración”.

3) Al oprimir el botón “Editar Credencial de administración”, el sistema carga un formulario de edición, además de los botones “Actualizar Credencial de administración” y “Regresar”.



Nombre del campo

Tipo de dato

Longitud

“Activo fijo asociado ”


1 – 50 caracteres

“Servicio” Cadena de caracteres

1 – 50 caracteres

“Usuario” Cadena de caracteres

1 – 50 caracteres

86

Fuente: El Autor


Fuente: El Autor

Cuadro 8. Monitoreo De Canales

Figura 13. Caso de Uso Gestión Monitoreo De Canales

Fuente: El Autor

“Password” Cadena de caracteres

1 – 50 caracteres

5) El usuario solicita la actualización de los datos oprimiendo el botón “Actualizar credencial de administración”.

5.1) Si el sistema no graba los datos, informa que no fue posible actualizar la información.



CU25 Consultar credencial de administración

Actor: Versión:



1) El usuario ingresa al módulo de credencial de administración.

2) El usuario oprime el botón “Consultar credencial de administración”.

3) Al seleccionar la opción consultar credencial de administración ; el sistema carga una lista con los detalles de todos las credenciales de administración existentes en el sistema

87

Descripción:

El sistema debe permitir al usuario administrador y al usuario agente acceder al módulo de

monitoreo de canales y visualizar el estado de los canales que presentan una alta latencia, y así

mismo, visualizar la información asociada al canal correspondiente.

Fuente: El Autor


Fuente: El Autor

3.2. DIAGRAMA DE ACTIVIDADES

Este tipo de diagramas sirven para representan el comportamiento dinámico de un sistema, haciendo énfasis en la secuencia de actividades que se realizan a lo largo de un proceso. Los diagramas de actividades explican el flujo de acciones e indican los puntos de decisión desde un punto de inicio hasta un punto final41. A continuación se ilustran los diferentes diagramas de actividades que representan el comportamiento del sistema a lo largo de su funcionamiento. La Figura 14 ilustra el diagrama de actividades correspondiente a la gestión de proveedores, el cual describe las acciones referentes al registro, edición, adición y eliminación de proveedores.

41

ALTOVA; Diagramas de actividades UML. [en línea]. < http://www.altova.com/es/umodel/activity-diagrams.html> [citado 02 Octubre de 2015].


CU26 Visualizar monitor de canales

Actor: Versión:



1) El usuario ingresa al módulo de “Monitoreo de canales”

2) El sistema carga una imagen de los canales que presenten una latencia alta, superior o aquellos canales con caída total. Así mismo carga la información asociada a los canales mostrados.

2.b) Si no existe ningún canal registrado aparecerá el mensaje: “No existen canales registrados en el sistema para el monitoreo”

88

Figura 14. Diagrama De Actividades – Gestión De Proveedores

Fuente: El Autor

La Figura 15 ilustra el diagrama de actividades correspondiente a la gestión de las ciudades, el cual describe las acciones referentes al registro, edición, adición y eliminación de ciudades.

89

Figura 15. Diagrama De Actividades – Gestión De Ciudades

Fuente: El Autor

La Figura 16 ilustra el diagrama de actividades correspondiente a la gestión de las sedes, el cual describe las acciones referentes al registro, edición, adición y eliminación de sedes que hacen parte de Distribuidora Nissan S.A.

90

Figura 16. Diagrama De Actividades – Gestión De Sedes

Fuente: El Autor

La Figura 17 ilustra el diagrama de canales correspondiente a la gestión de canales, el cual describe las acciones referentes al registro, edición, adición y eliminación de canales.

91

Figura 17. Diagrama De Actividades – Gestión De Canales

Fuente: El Autor

La Figura 18 ilustra el diagrama de actividades correspondiente a la gestión de activos, el cual describe las acciones referentes al registro, edición, adición y eliminación de activos.

92

Figura 18. Diagrama De Actividades – Gestión De Activos

Fuente: El Autor

La Figura 19 ilustra el diagrama de actividades correspondiente a la gestión de contactos, el cual describe las acciones referentes al registro, edición, adición y eliminación de contactos.

93

Figura 19. Diagrama De Actividades – Gestión De Contactos

Fuente: El Autor

La Figura 20 ilustra el diagrama de actividades correspondiente al monitor de canales, el cual describe las acciones referentes a la visualización de los canales que presentan pérdida de paquetes o se encuentran caídos.

94

Figura 20. Diagrama De Actividades – Monitor De Canales

Fuente: El Autor

3.3. DIAGRAMAS DE SECUENCIA

Los diagramas de secuencia muestran la interacción entre un conjunto de objetos y actores del sistema a través del tiempo. En las figuras 21 a 25 se visualizan los diagramas de secuencia de los principales casos de uso. La Figura 21 muestra el diagrama de secuencia del caso de uso CU1, el cual describe el proceso de autenticación del usuario al sistema de monitoreo de canales.

95

Figura 21. Diagrama De Secuencia – Autenticación

Fuente: El Autor

La Figura 22 muestra el diagrama de secuencia referente a las consultas, el cual describe los procesos de consulta que se llevan a cabo en los diferentes módulos del sistema. Figura 22. Diagrama De Secuencia - Consulta

Fuente: El Autor

96

La Figura 23 muestra el diagrama de secuencia referente al registro, el cual describe los procesos de registro que se llevan a cabo en los diferentes módulos del sistema. Figura 23. Diagrama De Secuencia - Registro

Fuente: El Autor

La Figura 24 muestra el diagrama de secuencia referente a la edición, el cual describe los procesos de edición que se llevan a cabo en los diferentes módulos del sistema. Figura 24. Diagrama De Secuencia - Edición

Fuente: El Autor

97

La Figura 25 muestra el diagrama de secuencia referente al monitor de canales, el cual describe los objetos que interactúan para mostrar en el panel de canales, aquellos canales caídos o con pérdidas.

Figura 25. Diagrama De Secuencia - Canales

Fuente: El Autor

3.4. DIAGRAMA DE DESPLIEGUE

La Figura 26 muestra el diagrama de despliegue que modela la arquitectura en tiempo de ejecución del sistema.

Figura 26. Diagrama de despliegue

Fuente: El Autor

98

3.5. BASE DE DATOS

La Figura 27 presenta el diseño del modelo relacional para la base de datos del sistema de la red Dinissan con el fin de almacenar y gestionar la información necesaria para el funcionamiento del aplicativo. Figura 27. Diagrama Entidad Relación

Fuente: El Autor

99

3.5.1. Diccionario de datos. A continuación se define el diccionario de datos que

describe las características de los datos que se van a almacenar en la base de

dato del sistema.

Tabla 61. Diccionario Tabla Proveedor

Fuente: El Autor

Tabla 62. Diccionario Tabla Usuario

Tabla Usuario

Nombre de la tabla Objetivo

tlmusuar Almacenar las credenciales de los usuarios del sistema.

Llave Campo Tipo Tamaño Max

Descripción

PK cd_logi VARCHAR 50 Nombre de usuario

de_pass VARCHAR 50 Contraseña encriptada

id_esta_logi VARCHAR 1 Estado del usuario (0/1)

id_tipo_logi VARCHAR 1 Tipo de usuario (1=administrador, 2=agente,3=invitado)

Fuente: El Autor

Tabla Proveedor


Inmprove Almacenar la información de los proveedores.


Descripción

PK nu_nit_prov VARCHAR 50 Nit del proveedor

de_nomb_prov VARCHAR 200 Nombre del proveedor

cd_tipo_serv VARCHAR 10 Tipo de servicio (Internet, Cableado, Otros)

nu_telf_prov VARCHAR 50 Teléfono del proveedor

de_nomb_cont VARCHAR 50 Nombre del contacto

nu_telf_cont VARCHAR 50 Teléfono del contacto

de_corr_cont VARCHAR 50 Correo de contacto

de_ciud_oper VARCHAR 50 Ciudad donde opera

id_esta_prov VARCHAR 1 Estado del proveedor (1/0)

100

Tabla 63. Diccionario Tabla Ciudad

Tabla Ciudad


getciuda Almacenar la información de las ciudades

Llave Campo Tipo Tamaño Max Descripción

PK cd_ciud VARCHAR 5 Codigo de la ciudad

de_ciud VARCHAR 200 Nombre de la ciudad

cd_zona VARCHAR 50 Zona de la ciudad (Norte, Sur, Centro, Oriente, Occidente)

id_esta_ciud VARCHAR 1 Estado de la ciudad(0/1)

Fuente: El Autor Tabla 64. Diccionario Tabla Sede

Tabla Sede


cotccost Almacenar la información de las sedes


PK nu_ctro_cost INT 10 Numero de centro de costo

FK cd_ciud VARCHAR 5 Código de la ciudad

de_ccot VARCHAR 50 Descripción del centro de costo

de_obv_ccot VARCHAR 1 Observación de la sede

de_dire_ccos VARCHAR 50 Dirección de la sede

nu_telf_ccos VARCHAR 50 Teléfono de la sede

de_segm_red VARCHAR 50 Segmento de red de la sede (IP LAN)

id_serv_vzip VARCHAR 2 Servicio de voz IP (Si/No)

nu_cod_can INT 4 Número del canal

de_diag_red VARCHAR 50 Ruta del diagrama de red

id_esta_ccos VARCHAR 1 Estado de la sede(0/1)

Fuente: El Autor

Tabla 65. Diccionario Tabla Compañía

Tabla Compañia


tldcomp Almacenar la información de las compañías que hacen parte de Distribuidora Nissan S.A


PK nu_nit_comp VARCHAR 50 Nit de la compañía

de_nomb_comp VARCHAR 45 Nombre de la compañía

Fuente: El Autor

101

Tabla 66. Diccionario Tabla Canal

Tabla Canal


tlmcana Almacenar la información de los canales


Descripción

PK nu_cons_cana INT 10 Numero consecutivo del canal

FK nu_ctro_cost INT 10 Numero de centro de costo

FK nu_nit_prov VARCHAR 50 Nit del proveedor

FK nu_nit_comp VARCHAR 50 Nit de la compañía asociada

de_alias VARCHAR 50 Alias del canal

de_anch_band VARCHAR 50 Ancho de banda (KBPS)

cd_tipo_serv VARCHAR 10 Tipo de servicio (Banda ancha/ Canal dedicado)

de_medi_serv VARCHAR 10 Medio Del Servicio (Fibra Óptica/Cobre)

cd_modo_oper VARCHAR 10 Modo de operación (Principal/Backup)

de_segm_red VARCHAR 50 Segmento de red (IP WAN)

nu_iden VARCHAR 50 Identificación del canal (asignado por el proveedor)

fe_inic_cont DATE DD/MM/AAAA

Fecha de inicio del contrato

vr_cost_mens DECIMAL (20,2) Valor mensual del servicio

pc_sla DECIMAL (3,2) SLA ofrecido por el proveedor

id_esta_cana VARCHAR 1 Estado del canal (0/1)

ct_late_norm INT 5 Latencia normal

ct_late_prom INT 5 Latencia promedio

ct_late_alta INT 5 Latencia alta

ct_late_supr INT 5 Latencia superior

Fuente: El Autor

Tabla 67. Diccionario Tabla Activo

Tabla Activo


afmactfi5 Almacenar la información de las activos fijos


Descripción

PK cd_cia_af INT 10 Número consecutivo del activo fijo

PK cd_acti_fijo VARCHAR 50 Código del activo fijo

102


Descripción

FK nu_ctro_cost VARCHAR 50 Número del centro de costo

de_desc_af VARCHAR 50 Descripción del activo fijo

de_obse_af VARCHAR 50 Observación del activo fijo

de_marc_af VARCHAR 50 Marca del activo fijo

de_seri_af VARCHAR 50 Serial del activo fijo

id_esta_af VARCHAR 50 Estado del activo fijo (Activo/Inactivo)

fe_acti_ini DATE DD/MM/AAAA

Fecha de inicio del activo fijo

fe_revi_af DATE DD/MM/AAAA

Fecha de revisión del activo fijo

fe_fin_gara DATE DD/MM/AAAA

Fecha de fin de garantía del activo fijo

fe_inic_gara DATE DD/MM/AAAA

Fecha de inicio de garantía del activo fijo

Fuente: El Autor

Tabla 68. Diccionario Tabla Contacto

Tabla Contacto


tldcontac Almacenar la información de los contactos por sede.


PK nu_cons_cont INT 10 Número consecutivo del contacto

FK nu_ctro_cost VARCHAR 50 Número del centro de costo

de_nomb_cont VARCHAR 50 Nombre del contacto

de_telf_cont VARCHAR 50 Teléfono del contacto

de_carg_cont VARCHAR 50 Cargo del contacto

id_esta_cont VARCHAR 1 Estado del contacto (0/1)

Fuente: El Autor

Tabla 69. Diccionario Tabla Administración De Activos

Tabla Administración de servicios de activos


tlmadmin Almacenar las credenciales referentes as loas servicios instalados en los activos o la administración de los mismos

103


PK nu_cons_admi INT 10 Número consecutivo De la administración del activo

FK cd_cia_af INT 10 Número consecutivo del activo fijo asociado

FK cd_acti_fijo VARCHAR 50 Código del activo fijo asociado

cd_usua VARCHAR 50 Usuario

de_pass VARCHAR 50 Contraseña

de_serv VARCHAR 50 Servicio (administración del activo, PBX, etc)

Fuente: El Autor

Tabla 70. Diccionario Tabla Tipo De Falla

Tabla Tipo De Falla


tltfalla Almacenar la información de los tipos de fallas que pueden presentarse en los canales.


PK cd_fall INT 10 Número consecutivo del tipo de falla

de_fall VARCHAR 50 Descripción del tipo de falla

Fuente: El Autor

Tabla 71. Diccionario Tabla Monitoreo De Canal

Tabla Monitoreo por canal


tldmont Almacenar de forma temporal la información correspondiente al monitoreo de los canales de la red.


PK nu_cons_moni INT 100 Número consecutivo del monitoreo

FK cd_cana VARCHAR 50 Código del canal asociado

fe_capt DATE DD/MM/AAAA Fecha de captura

hr_capt TIME HH:MM:SS Hora de la captura

pc_perd_paq DECIMAL (3,2) Porcentaje de paquetes perdidos

ct_late INT 5 Cantidad de latencia

Fuente: El Autor

104

Tabla 72. Diccionario Tabla Promedio Monitoreo De Canal

Tabla Promedio de monitoreo por canal


tldprom Almacenar los promedio de la información correspondiente al monitoreo de los canales de la red.


PK nu_cons_prom INT 100 Número consecutivo del monitoreo

FK cd_cana INT 10 Código del canal asociado

FK cd_fall INT 10 Código del tipo de falla

fe_capt DATE DD/MM/AAAA Fecha de captura

hr_capt TIME HH:MM:SS Hora de la captura

pc_prom_ppaq DECIMAL (3,2) Promedio de porcentaje de paquetes perdidos

pc_prom_late INT 5 Promedio de latencia

Fuente: El Autor

105

4. IMPLEMENTACIÓN

Para la implementación del sistema se utilizaron los framework de PHP; Bootstrap, Kickstrap y Fundation, debido a la amplia gama de componentes que ofrecen y a su flexibilidad en cuanto a la integración en el proyecto. El sistema de monitoreo de canales se ha desarrollado en lenguaje PHP, mientras que para el diseño, creación y administración de la base de datos su utilizó MySQL Workbench. Estas herramientas fueron escogidas debido a que MySQL es un sistema de gestión de bases de datos de uso libre y por lo tanto no es necesario incurrir en gastos, además de esto, se decidió desarrollar con PHP, debido a que es un lenguaje libre y abierto y sus entornos de desarrollo son de fácil desarrollo y configuración. El sistema de monitoreo de canales de distribuidora Nissan S.A cuenta con tres tipos diferentes de interfaces que están directamente relacionadas con el tipo de usuario que se autentica en el sistema; los tipos de usuarios son: “Administrador”, “Agente” e “invitado”.

4.1. Administrador La interfaz correspondiente al perfil de administrador, cuenta con la con la posibilidad de realizar las operaciones de consultar, eliminar, agregar, y adicionar en los módulos de: canales, sedes, contactos, proveedores, activos fijos, administración de activos fijos y ciudades. 4.1.1. Autenticación. En la Figura 28 el administrador del sistema ingresa, proporcionando sus credenciales de usuario y contraseña. Figura 28. Pantalla De Autenticación

Fuente: El Autor

106

En caso que el usuario ingrese mal sus credenciales, el sistema mostrará en pantalla el mensaje de “Datos Incorrectos” como se muestra en la Figura 29. Figura 29. Pantalla De Autenticación - Datos Incorrectos

Fuente: El Autor

Una vez las credenciales hayan sido comprobadas por el sistema, la pantalla a la cual tiene acceso el usuario administrador es el panel de monitoreo de canales. En la parte superior derecha de la pantalla es posible observar qué usuario se encuentra autenticado en el sistema, y cuál es su perfil correspondiente, y del mismo modo en el panel superior se encuentra también un menú de navegación hacia los diferentes módulos que componen el sistema. Figura 30. Menú De Navegación

Fuente: El Autor

107

4.1.2. Módulo de canales. Para el perfil de administrador, el módulo de canales está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar”.

Figura 31. Módulo De Canales

Fuente: El Autor En la sección de edición de canales, el usuario podrá editar los datos correspondientes a cada canal según desee, con lo cual, el sistema lo actualizará en la base de datos. Figura 32. Edición De Canales

Fuente: El Autor

En la sección de adición de canales, el usuario debe llenar los campos obligatorios que aparecen con el símbolo (*) y los campos opcionales que desee, al final del

–

108

formulario, se encuentra el botón “Agregar Canal” para confirmar el registro, con lo que el sistema informará si el canal fue registrado de forma satisfactoria.

Figura 33. Adición De Canales

Fuente: El Autor

En la sección de eliminar canales, el usuario puede seleccionar el canal que desee eliminar y dar clic sobre el icono “Eliminar” ubicado en la parte izquierda de cada canal que se encuentra en el sistema, de esta forma el sistema informará si el canal fue eliminado de forma satisfactoria.

Figura 34. Eliminación De Canales

Fuente: El Autor

109

4.1.3. Módulo de sedes. Para el perfil de administrador, el módulo de sedes está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 35. Figura 35. Módulo De Sedes

Fuente: El Autor

4.1.4. Módulo de contactos. Para el perfil de administrador, el módulo de sedes está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 36.

Figura 36. Módulo De Contactos

Fuente: El Autor

110

4.1.5. Módulo de proveedores. Para el perfil de administrador, el módulo de proveedores está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 37. Figura 37. Módulo De Proveedores

Fuente: El Autor

4.1.6. Módulo de activos fijos. Para el perfil de administrador, el módulo de activos fijos está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 38.

Figura 38. Módulo De Activos Fijos

Fuente: El Autor

111

4.1.7. Módulo de Administración De Activos Fijos. Para el perfil de administrador, el módulo de administración activos fijos está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 39.

Figura 39. Módulo De Administración De Activos Fijos

Fuente: El Autor

4.1.8. Módulo De Ciudades. Para el perfil de administrador, el módulo de administración activos fijos está compuesto por cuatro secciones; “Consultar”, “Editar”, “Agregar” y “Eliminar” como se muestra en la Figura 40.

Figura 40. Módulo De Ciudades

Fuente: El Autor

112

4.2. Agente

La interfaz correspondiente al perfil de “Agente” cuenta con la con la posibilidad de realizar únicamente las operaciones de consulta en los módulos de: canales, sedes, contactos, proveedores, activos fijos, administración de activos fijos y ciudades.

Figura 41. Módulo De Canales - Usuario Agente

Fuente: El Autor Como se muestra en la Figura 42, en el módulo de proveedores únicamente aparece la poción de “Consultar”, debido a que su perfil no tiene permisos para realizar las acciones de “Editar”, “Agregar” y “Eliminar”.

Figura 42. Módulo De Proveedores - Usuario Agente

Fuente: El Autor

113

4.3. Invitado

La interfaz correspondiente al perfil “Invitado”, cuenta con la posibilidad de observar unicamente el monitor de canales, este monitor ilustra en pantalla los canales que se encuentran caidos a nivel nacional, y los canales que presentan perdidas de paquetes en tiempo real como se ilistra en Figura 43.

Figura 43. Panel De Canales

Fuente: El Autor

114

5. PRUEBAS

5.2. Pruebas de estrés

Para el desarrollo de las pruebas de estrés se hace uso de Apache Jmeter 2.13, como herramienta de software sobre el sistema de monitoreo de canales de la red de Distribuidora Nissan suponiendo diferentes tipos de escenarios. 5.2.1. Escenario 1

Tabla 73. Escenario De Prueba 001

ID prueba 001

Muestra 10 usuarios concurrentes

Periodo de subida (en segundos)

3

Contador del bucle 2

Método de implementación

HTTP GET

Ruta de acceso http://localhost/monitoreo/canales.php

Fuente: El Autor

5.2.1.1. Resumen de la prueba

La siguiente tabla muestra una fila por cada petición de diferente tipo que se realice, en este caso únicamente se realizaron peticiones de tipo HTTP, por lo tanto solo existe una fila en el reporte, cada fila describe la siguiente información: Etiqueta: El nombre de la muestra (conjunto de muestras). # Muestras: El número de muestras para cada URL. Media: El tiempo medio transcurrido para un conjunto de resultados. Mín: El mínimo tiempo transcurrido para las muestras de la URL dada. Máx: El máximo tiempo transcurrido para las muestras de la URL dada.

http://localhost/monitoreo/canales.php

115

Error %: Porcentaje de las peticiones con errores. Rendimiento: Rendimiento medido en base a peticiones por segundo /minuto /hora. Kb/sec: Rendimiento medido en Kilobytes por segundo. Media de Bytes: Tamaño medio de la respuesta de la muestra medido en bytes.

Como se muestra a continuación el número total de hilos que se utilizaron en la prueba fueron 20, ya que se ejecutaron un grupo de 10 hilos simultanéanos en 2 lapsos de tiempo diferentes. Es posible observar que las pruebas se han realizado sin errores. Esto se deduce de la columna representativa del porcentaje de errores para cada una de las peticiones asociadas a cada conjunto de muestras. El rendimiento muestra que para una simulación de 20 usuarios junto a un periodo de subida de 3 segundos el servidor es capaz de aceptar una media de 7,3 peticiones por segundo.

Figura 44. Resumen Prueba 001

Fuente: El Autor

5.2.1.2 Tabla de resultados

Esta tabla de resultados recoge las muestras ejecutadas a lo largo de la prueba en tiempo real, indicando: El número de petición (“muestra”). El momento de inicio (“tiempo de comienzo”). El nombre del grupo de hilos y el número del hilo que ejecuta (“Nombre de Hilo”). La etiqueta o nombre de la petición o controlador “Etiqueta”. El tiempo de respuesta que en ese caso no supera los 47 milisegundos. El resultado de la petición (“Estado de la petición”) que fue satisfactoria para los 20 hilos ejecutados.

116

El tamaño en bytes de la petición que es de 4634 bytes si se ejecutó satisfactoriamente la petición La latencia (entendida como el tiempo de espera para la renderización de la página, el tiempo en obtener respuesta del servidor) para cada uno de los hilos, en este caso es posible observar que no supera el valor de 45 milisegundos.

Figura 45. Tabla De Resultados Prueba 001

Fuente: El Autor

117

5.2.1.3 Grafica de resultados: Tiempos de respuesta

La grafica de tiempos de respuesta dibuja un gráfico de líneas que muestra la evolución del tiempo de respuesta durante la prueba para cada solicitud, donde un punto de referencia es dibujado cada 50 milisegundos. En el eje X se puede observar la hora exacta cuando se dibuja un punto de referencia, mientras que en el eje Y se muestra cuánto tiempo lleva la petición en proceso.

Figura 46. Grafica De Resultados, Tiempos De Respuesta Prueba 001

Fuente: El Autor

5.2.2. Escenario 2


ID prueba 002


Periodo de subida (en segundos) 3


Método de implementación HTTP GET

118

Ruta de acceso http://localhost/monitoreo/sedes.php

Fuente: El Autor

5.2.2.1 Resumen de la prueba



Fuente: El Autor


Esta tabla de resultados recoge las muestras ejecutadas a lo largo de la prueba en tiempo real, indicando: El número de petición (“muestra”). El momento de inicio (“tiempo de comienzo”). El nombre del grupo de hilos y el número del hilo que ejecuta (“Nombre de Hilo”). La etiqueta o nombre de la petición o controlador “Etiqueta”. El tiempo de respuesta que en ese caso no supera los 9 milisegundos.

http://localhost/monitoreo/sedes.php

119

El resultado de la petición (“Estado de la petición”) que fue satisfactoria para los 20 hilos ejecutados. El tamaño en bytes de la petición que es de 4634 bytes si se ejecutó satisfactoriamente la petición La latencia (entendida como el tiempo de espera para la renderización de la página, el tiempo en obtener respuesta del servidor) para cada uno de los hilos, en este caso es posible observar que no supera el valor de 6 milisegundos.


Fuente: El Autor

120


La grafica de tiempos de respuesta dibuja un gráfico de líneas que muestra la evolución del tiempo de respuesta durante la prueba para cada solicitud, donde un punto de referencia es dibujado cada 50 milisegundos. En el eje X se puede observar la hora exacta cuando se dibuja un punto de referencia, mientras que en el eje Y se muestra cuánto tiempo lleva la petición en proceso. Figura 49. Grafica De Resultados, Tiempos De Respuesta Prueba 002.

Fuente: El Autor 5.2.3. Escenario 3 Tabla 75. Escenario De Prueba 003

ID prueba 003




Método de implementación

HTTP GET

Ruta de acceso http://localhost/monitoreo/panel.php

Fuente: El Autor

http://localhost/monitoreo/panel.php

121




Fuente: El Autor


Esta tabla de resultados recoge las muestras ejecutadas a lo largo de la prueba en tiempo real, indicando: El número de petición (“muestra”). El momento de inicio (“tiempo de comienzo”). El nombre del grupo de hilos y el número del hilo que ejecuta (“Nombre de Hilo”). La etiqueta o nombre de la petición o controlador “Etiqueta”. El tiempo de respuesta que en ese caso no supera los 28 milisegundos. El resultado de la petición (“Estado de la petición”) que fue satisfactoria para los 120 hilos ejecutados.

122

El tamaño en bytes de la petición que es de 4634 bytes si se ejecutó satisfactoriamente la petición La latencia (entendida como el tiempo de espera para la renderización de la página, el tiempo en obtener respuesta del servidor) para cada uno de los hilos, en este caso es posible observar que no supera el valor de 26 milisegundos.


Fuente: El Autor

123


La grafica de tiempos de respuesta dibuja un gráfico de líneas que muestra la evolución del tiempo de respuesta durante la prueba para cada solicitud, donde un punto de referencia es dibujado cada 50 milisegundos. En el eje X se puede observar la hora exacta cuando se dibuja un punto de referencia, mientras que en el eje Y se muestra cuánto tiempo lleva la petición en proceso. Figura 52. Grafica De Resultados, Tiempos De Respuesta Prueba 003.

Fuente: El Autor

5.2.4. Escenario 4


ID prueba 004




Método de implementación HTTP GET

Ruta de acceso http://localhost/monitoreo/panel.php

Fuente: El Autor

http://localhost/monitoreo/panel.php

124


Como se muestra a continuación el número total de hilos que se utilizaron en la prueba fueron 60, ya que se ejecutaron un grupo de 60 hilos únicamente. Es posible observar que las pruebas se han realizado sin errores. Esto se deduce de la columna representativa del porcentaje de errores para cada una de las peticiones asociadas a cada conjunto de muestras. El rendimiento muestra que para una simulación de 60 usuarios junto a un periodo de subida de 30 segundos el servidor es capaz de aceptar una media de 9,2 peticiones por segundo.


Fuente: El Autor


Esta tabla de resultados recoge las muestras ejecutadas a lo largo de la prueba en tiempo real, indicando: El número de petición (“muestra”). El momento de inicio (“tiempo de comienzo”). El nombre del grupo de hilos y el número del hilo que ejecuta (“Nombre de Hilo”). La etiqueta o nombre de la petición o controlador “Etiqueta”. El tiempo de respuesta que en ese caso no supera los 41 milisegundos. El resultado de la petición (“Estado de la petición”) que fue satisfactoria para los 60 hilos ejecutados. El tamaño en bytes de la petición que es de 4634 bytes si se ejecutó satisfactoriamente la petición La latencia (entendida como el tiempo de espera para la renderización de la página, el tiempo en obtener respuesta del servidor) para cada uno de los hilos, en este caso es posible observar que no supera el valor de 39 milisegundos.

125


Fuente: El Autor

126


La grafica de tiempos de respuesta dibuja un gráfico de líneas que muestra la

evolución del tiempo de respuesta durante la prueba para cada solicitud, donde un

punto de referencia es dibujado cada 50 milisegundos.

En el eje X se puede observar la hora exacta cuando se dibuja un punto de

referencia, mientras que en el eje Y se muestra cuánto tiempo lleva la petición en

proceso.

Figura 55. Grafica De Resultados, Tiempos De Respuesta Prueba 004.

Fuente: El Autor

127

6. CONCLUSIONES El sistema desarrollado permite que la información esté centralizada, y que su acceso sea más ágil y de una administración mucho más flexible. El sistema desarrollado permite optimizar los tiempos de respuesta frente a una caída de una canal o una falla del mismo, ya que se cuenta rápidamente con la información necesaria para reportar la falla del canal al proveedor correspondiente. Gracias a la herramienta, se podrá almacenar información histórica que permita obtener estadísticas del estado de los canales activos por proveedores, por ciudad, por fecha, entre otros, y de esta manera tomar las acciones correctivas necesarias. El diseñó de la herramienta permite que puedan ser fácilmente agregados más módulos si así se requirieren, ya que cuenta con una estructura muy dinámica y fácil de comprender.

128

7. RECOMENDACIONES

Se recomienda adicionar un módulo de alertas, que permita enviar automáticamente un mensaje vía correo electrónico a las cuentas de los usuarios administradores del sistema, estas alertas indicaran que la fecha de garantía de un activo fijo está próxima a vencerse y la caída de un canal. Se recomienda agregar un log que guarde históricamente quien realizo un cambio en el sistema y cuando se realizó dicho cambio.

Se recomienda adicionar una modulo que permita exportar informe basado en diferentes parámetros de interés por parte de los administrativos de la red de telecomunicaciones

129

BIBLIOGRAFÍA

AJDBSOFT. Protocolo Simple De Administración [en línea]. [citado 2 Agosto,

2015]. Disponible en Internet: < URL:

http://www.ajpdsoft.com/modules.php?name=Encyclopedia&op=content&tid=793>

BIBING. Guía rápida de cacti [en línea]. [citado 28 Julio, 2015]. Disponible en

Internet: < URL:

<http://bibing.us.es/proyectos/abreproy/12013/fichero/5.+Anexos%252FANEXO+1

_Guia+rapida+de+CACTI.pdf>

BLYX. El modelo OSI y los protocolos de red [en línea]. [citado 1 Agosto, 2015].

Disponible en Internet: < URL: http://blyx.com/public/docs/pila_OSI.pdf >

CAYU. Monitoria y análisis de Red [en línea]. [citado 28 Julio, 2015]. Disponible

en Internet: < URL: http://cayu.com.ar/files/manuales-nagios.pdf>.

CCM. La herramienta Ping. [en línea]. [citado 10 Agosto, 2015]. Disponible en

Internet: < URL: http://es.ccm.net/contents/355-ping>

CLEMM, Alexander. Network Management Fundamentals. Indianapolis. 2 ed.

2006. p. 145

COMER, Douglas. Redes globales de información con Internet y TCP/IP. 3 ed.

Mexico D.F. Prentice hall hispanoamericana, 2000. p.37.

CONATEL. Monitorización de redes en software libre herramientas y

recomendaciones [en línea]. [citado 2 Agosto, 2015]. Disponible en Internet: <

URL: http://www.conatel.gob.ve/monitorizacion-de-redes-en-software-libre-

herramientas-y-recomendaciones/>

FERRO, Greg. Basics: What Is a Network Service? [en línea]. [citado 2 Agosto,

2015]. Disponible en Internet: < URL: http://etherealmind.com/basics-what-is-a-

network-service/.>

GEOCITIES. Gestión y utilización de redes locales [en línea]. [citado 2 julio,

2015]. Disponible en Internet: < URL: http://www.geocities.ws/rincoes/redes07-

icmp.pdf>

GONZALEZ, Jose Luis. Redes Privadas Virtuales [en línea]. [citado 10 Agosto,


http://isa.uniovi.es/~sirgo/doctorado/VPN.pdf>

http://etherealmind.com/basics-what-is-a-network-service/

http://etherealmind.com/basics-what-is-a-network-service/

http://www.geocities.ws/rincoes/redes07-icmp.pdf

http://www.geocities.ws/rincoes/redes07-icmp.pdf

http://isa.uniovi.es/~sirgo/doctorado/VPN.pdf

130

HURTADO, Francisco. Nagios: Caso de aplicación [en línea]. [citado 28 Julio,


http://www.fedoras.com/manuales/redes/nagios.pdf>.

MANAGE ENGINE. Free Network Monitoring Software for Small Networks. [en

línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

https://www.manageengine.com/network-monitoring/Network-Monitoring-

Software.pdf>

MARTI, Barba. MORENO, Melus. Network Management and Control. Volume 2.

New York, 1994.p.20.

MICROSOFT, Las siete capas del modelo OSI y explicación de las funciones [en

línea]. [citado 1 Agosto, 2015]. Disponible en Internet: < URL

https://support.microsoft.com/kb/103884/es>}

MICROSOFT. Uso del comando Ping. [en línea]. [citado 10 Agosto, 2015].

Disponible en Internet: < URL: https://technet.microsoft.com/es-

es/library/cc732509%28v=ws.10%29.aspx>

MOLERO, Luis. Planificación y gestión de redes. [en línea]. [citado 1 Agosto,

2015]. Disponible en Internet: < URL: http://www.urbe.edu/info-consultas/web-

profesor/12697883/archivos/planificacion-gestion-red/Unidad-I.pdf>

MONGKOLLUKSAMEE, Sophon. PONGPAIBOOL, Panita. ISSARIYAPAT,

Chavee. Strengths and Limitations of Nagios as a Network Monitoring Solution. [en

línea]. [citado 28 Julio, 2015]. Disponible en Internet: < URL:

http://inms.in.th/inmsweb/paper/Apricot_nagios20091130-final.pdf>

MRGT. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet:

< URL: https://www.mrtg.com>

NAGIOS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en

Internet: < URL: http://nagios.org>

NEBRIJA. Curso de TCP/IP [en línea]. [citado 29 De Julio, 2015]. Disponible en

Internet: < URL:

http://www.nebrija.es/~cmalagon/seguridad_informatica/Lecturas/TCP-

V_ICMP_hxc.pdf>

OCTANA. Ventajas del software a la medida [en línea]. [citado 28 Julio, 2015].

Disponible en Internet: < URL: http://www.octana-

software.com.mx/software_medida_vs_comercial.pdf>.

https://www.manageengine.com/network-monitoring/Network-Monitoring-Software.pdf

https://www.manageengine.com/network-monitoring/Network-Monitoring-Software.pdf

https://support.microsoft.com/kb/103884/es

http://www.urbe.edu/info-consultas/web-profesor/12697883/archivos/planificacion-gestion-red/Unidad-I.pdf

http://www.urbe.edu/info-consultas/web-profesor/12697883/archivos/planificacion-gestion-red/Unidad-I.pdf

http://www.octana-software.com.mx/software_medida_vs_comercial.pdf

http://www.octana-software.com.mx/software_medida_vs_comercial.pdf

131

OPENNMS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en

Internet: < URL: http://opennm.org>.

OPMANAGER. ManageEngine [en línea]. [citado 29 Julio, 2015]. Disponible en

Internet: < URL: http://opmanager.com.es/>.

PAESSLER. Proteger redes por años [en línea]. [citado 30 Julio, 2015]. Disponible

en Internet: < URL: https://www.es.paessler.com/prtg>.

PROYECTOS AGILES. Scrum [en línea]. [citado 8 Agosto, 2015]. Disponible en

Internet: < URL: http://www.proyectosagiles.org/que-es-scrum>

ROBLES, Luis Fernando. Redes de informática [en línea]. [citado 2 Agosto, 2015].

Disponible en Internet: < URL:

https://sites.google.com/site/redesdeinformaticahermosilloii/home/conceptos-

basicos>

ROCHA, Diego Javier. Implementación de una MIB para la generación de

mensajes de alerta para la administración de un servidor de correo electrónico [en

línea]. [citado 2 Agosto, 2015]. Disponible en Internet: < URL:

bibdigital.epn.edu.ec/bitstream/15000/1327/1/CD-2086.pdf>

ROUTER TELDAT. Agente snmp. [en línea]. [citado 29 De Julio, 2015]. Disponible

en Internet: < URL:

ftp://ftp.storm.hr/Upload/Teldat_privremeno/Teldat_dokumen12%5CDm712v10-

60_Agente_SNMP.pdf.

SCHWABER, Ken. SUTHERLAND,Jeff. La Guía de Scrum [en línea]. [citado 8

Agosto, 2015]. Disponible en Internet: < URL:

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf>

SHOKHIN, Anatolii. Network monitoring with ZABBIX [en línea]. [citado 29 Julio,


http://www.theseus.fi/bitstream/handle/10024/94415/Bachelor_Thesis_Anatolii_Sh

okhin.pdf?sequence=1>.

SISTEMAMONITOREOUNL. Sistemas de Monitoreo [en línea]. [citado 28 Julio,


https://sistemamonitoreounl.wordpress.com/sistemas-de-monitoreo-3/>.

TECNOZER. ¿Por qué es importante monitorizar nuestra red? [en línea]. [citado 2

Agosto, 2015]. Disponible en Internet: < URL: http://www.tecnozero.com/blog/por-

que-es-importante-monitorizar-nuestra-red/>

http://opmanager.com.es/

http://www.proyectosagiles.org/que-es-scrum

ftp://ftp.storm.hr/Upload/Teldat_privremeno/Teldat_dokumen12%5CDm712v10-60_Agente_SNMP.pdf.

ftp://ftp.storm.hr/Upload/Teldat_privremeno/Teldat_dokumen12%5CDm712v10-60_Agente_SNMP.pdf.

https://sistemamonitoreounl.wordpress.com/sistemas-de-monitoreo-3/

http://www.tecnozero.com/blog/por-que-es-importante-monitorizar-nuestra-red/

http://www.tecnozero.com/blog/por-que-es-importante-monitorizar-nuestra-red/

132

TIMMERMANN, Thomas. Criterios para la selección adecuada de una solución de

monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en Internet: <

URL:https://assets.paessler.com/common/files/pdf/whitepaper/selection-

criteria_es.pdf>

UNIVERSIDAD DE VALENCIA. Simple Network Management Protocol. [en línea].

[citado 4 Agosto, 2015]. Disponible en Internet: < URL:

informatica.uv.es/iiguia/R/apuntes/snmp.ppt>

UNIVERSIDAD NACIONAL DEL CENTRO. El modelo OSI [en línea]. [citado 2


www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf

UNIVERSIDAD NACIONAL DEL CENTRO. El modelo OSI. [en línea]. [citado 2


www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf>

UPV. El protocolo icmp [en línea]. [citado 5 Agosto, 2015]. Disponible en Internet:

< URL: www.redes.upv.es/redesfi/transpa/T11_ICMP.pdf>

VICENTE, Carlos Alberto. Monitoreo de recursos de red [en línea]. [citado 29

Julio, 2015]. Disponible en Internet: < URL:

https://juliorestrepo.files.wordpress.com/2011/04/monitoreo.pdf>.

ZENOSS. Monitoreo de red [en línea]. [citado 28 Julio, 2015]. Disponible en

Internet: < URL: http://zenoss.com>

.

http://www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf

REDISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE MONITOREO DE LA RED DE … · 2018-08-22 · 1.1.1....

Documents

Transcript of REDISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE MONITOREO DE LA RED DE … · 2018-08-22 · 1.1.1....