Rediseño e Implementación Del Sistema de Monitoreo de La Red PDF

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
3
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
4
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
5
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
6
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
8
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
9
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
10
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
12
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.
13
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.
14
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>
15
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/>.
16
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?seque
nce=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/>.
17
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>.
18
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?
19
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.
20
 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ísico 17.
 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/.>
21
 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.>
22
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 misma 2.
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>
23
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/>
24
 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 >
25
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>
26
 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].
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].
<www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf>
27
 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.
28
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>
29
 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ón 32
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>
30
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
31
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>
32
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.
33
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.
34
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>
35
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.
36
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
37
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
38
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:
Gestionar acceso al
RF1 -
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
 Acceso al sistema
 Contraseña
Postcondición:
La aplicación valida los datos que se ingresaron y el usuario accederá a la
ventana principal de la plataforma.
39
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

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/
 Se muestra en pantalla el
de cableado)
mensaje de registro satisfactorio
 Teléfono de soporte técnico
y se visualiza la información del
 Nombre del ejecutivo de cuenta/
nuevo proveedor creado.
contacto
 Teléfono del ejecutivo de cuenta/
contacto
 Correo del ejecutivo de cuenta/ contacto
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”.
40
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
mensaje de eliminación exitosa.
Proveedor” frente al proveedor que se
desea eliminar.
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
41
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 proveedor que se desea editar debe estar previamente creado.
Entrada: Salida:
 Se muestra en pantalla el mensaje de
 Campo(s) a ser actualizado(s) 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”.

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:
 Se muestra en pantalla el listado de los
 Ninguna proveedores que se encuentran
registrados.
42
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:

Entrada: Salida:
 ID de la ciudad
mensaje de registro satisfactorio y
 Nombre de la ciudad
se visualiza la información de la
 Zona geográfica de la ciudad
nueva ciudad creada.
Postcondición:
El sistema registra en la base de datos la información de la nueva ciudad
ingresada en el formulario.
confirma el registro de la ciudad en el sistema, aparecerá el mensaje error: “El

Fuente: El Autor
43
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:

 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  Se muestra en pantalla el
Ciudad” frente a la ciudad que se desea mensaje de eliminación exitosa.
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”.
44
Precondición:
 La ciudad que se desea editar debe estar previamente creada.
Entrada: Salida:
información actualizada de la ciudad.
Postcondición:
El sistema actualiza en la base de datos la información de la ciudad.

el usuario confirma la actualización de la ciudad en el sistema, aparecerá un

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:
 La ciudad que se desea consultar debe estar previamente creado.
Entrada: Salida:
 Se muestra en pantalla el listado de las
 Ninguna
ciudades que se encuentran registrados.
Postcondición:
El sistema muestra en pantalla el listado de las ciudades que se encuentran
45
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:
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
mensaje de registro
 Teléfono
satisfactorio y se visualiza la
 Servicios Voz IP (Análoga o Troncal
información de la nueva
SIP)
sucursal creada.
 Código de canal (Solo aplica para Voz
IP)
 IP LAN
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”.

confirma el registro de la sucursal en el sistema, aparecerá el mensaje error: “El
46
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:
 La sucursal que se desea eliminar debe estar previamente creada.
 La sucursal no debe estar asociada a ningún canal.
Entrada: Salida:
sucursal” frente a la sucursal que se mensaje de eliminación exitosa.
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
47
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:
 La sucursal que se desea editar debe estar previamente creada.
Entrada: Salida:
información actualizada de la sucursal.
Postcondición:
El sistema actualiza en la base de datos la información de la sucursal.
el usuario confirma la actualización de la sucursal en el sistema, aparecerá un

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:
 La sucursal que se desea consultar debe estar previamente creada.
Entrada: Salida:
 Se muestra en pantalla el listado de las
 Ninguna
sucursales que se encuentran registradas.
48
Postcondición:
El sistema muestra en pantalla el listado de las sucursales que se encuentran
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:

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
 ID del canal
 Latencia normal
 Latencia promedio mínima
 Latencia promedio alta
 Latencia promedio superior a 130  Se muestra en pantalla el
 Tipo de servicio (Dedicado, banda mensaje de registro satisfactorio
ancha) y se visualiza la información del
 Medio del servicio (Radio frecuencia, nuevo canal creado.
hfc, fibra)
 IP WAN
 Modo de operación (Backup – principal)
 Ancho de banda
 Segmento de red.
 Costo de canal mensual
49
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”.

confirma el registro de la sucursal en el sistema, aparecerá el mensaje error: “El

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 canal que se desea eliminar debe estar previamente creado.
Entrada: Salida:
 Hace clic sobre el icono “Eliminar canal”
mensaje de eliminación exitosa.
frente al canal que se desea eliminar.
Postcondición:
Inhabilitar el registro del canal en la base de datos.
50
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 canal que se desea editar debe estar previamente creado.
Entrada: Salida:
 Campo(s) a ser actualizado(s) 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”.

Fuente: El Autor

RF17 Consultar canal RF1, RF14
51
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 canal que se desea consultar debe estar previamente creado.
Entrada: Salida:
 Ninguna
canales que se encuentran registrados.
Postcondición:
El sistema muestra en pantalla el listado de los canales que se encuentran
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:
Debe existir en el sistema al menos una sucursal para asociarla al activo.
Entrada: Salida:
 Tipo de activo (Switch, Access Point,
servidor y UPS)
 Marca  Se muestra en pantalla el
 Serial mensaje de registro satisfactorio
 Código de activo fijo y se visualiza la información del
 Descripción nuevo activo creado.
 Estado (nuevo, reemplazo por garantía,
dado de baja)
52
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.
una sucursal antes de crear un activo”.

confirma el registro del activo en el sistema, aparecerá el mensaje error: “El

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 activo que se desea eliminar debe estar previamente creado.
Entrada: Salida:
activo” frente al activo que se desea mensaje de eliminación exitosa.
eliminar.
53
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 activo que se desea editar debe estar previamente creado.
Entrada: Salida:
 Campo(s) a ser actualizado(s) 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”.

Fuente: El Autor

RF21 Consultar canal RF1, RF18
54
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 activo que se desea consultar debe estar previamente creado.
Entrada: Salida:
 Ninguna
activos que se encuentran registrados.
Postcondición:
El sistema muestra en pantalla el listado de los activos que se encuentran
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:

Debe existir en el sistema al menos una sucursal para asociarla al contacto.
Entrada: Salida:
 Nombre del contacto
mensaje de registro satisfactorio
 Teléfonos del contacto
y se visualiza la información del
 Cargo (opcional)
nuevo contacto creado.
55
Postcondición:
El sistema registra en la base de datos la información del nuevo contacto
ingresado en el formulario.
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”.

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 contacto que se desea eliminar debe estar previamente creado.
Entrada: Salida:
contacto” frente al contacto que se mensaje de eliminación exitosa.
desea eliminar.
Postcondición:
Inhabilitar el registro del contacto en la base de datos.
No aplica
Fuente: El Autor
56
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 contacto que se desea editar debe estar previamente creado.
Entrada: Salida:
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”.

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.
57
Precondición:
 El contacto que se desea consultar debe estar previamente creado.
Entrada: Salida:
 Ninguna
contactos que se encuentran registrados.
Postcondición:
El sistema muestra en pantalla el listado de los contactos que se encuentran
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:
 Se muestra en pantalla un panel que
 Ninguna
ilustra el nivel de latencia por canal.
Postcondición:
El sistema muestra en pantalla el listado de los contactos que se encuentran
1. Si no existe ningún canal registrado aparecerá el mensaje: “No existen canales
registrados en el sistema para el monitoreo”
Fuente: El Autor
58
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 Riesgo Prioridad
0funcional
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
59
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

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.
60
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
61
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 Administrador
administración
CU23 Eliminar credencial de Administrador
administración
62
CU24 Editar credencial de Administrador
administración
CU25 Consultar credencial de Administrador, agente
administración
CU26 Visualizar Monitor de Administrador, agente, invitado
Canales
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
63
Tabla 35. Caso de Uso 1
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 Tipo de dato Longitud

campo
Usuario Cadena de 6 - 50
caracteres Caracteres
Contraseña Cadena de 6 - 50
caracteres Caracteres
2) El usuario oprime el botón “Iniciar Sesión”.
3) Al oprimir el botón “Iniciar Sesión” se carga 3.1) Si las credenciales no están

la página principal del sistema (Módulos del almacenadas en la base de datos o los datos
sistema). digitados son incorrectos.
Fuente: El Autor

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 3.1) El usuario oprime el botón “Regresar”
sistema carga un formulario además de los para cancelar el proceso y volver al módulo
botones “Crear proveedor” y “Regresar”. de proveedores.
64
4) El usuario mantiene o actualiza todos los
campos del formulario.
Los campos son:
Tipo de Longitud
Nombre del dato
campo
“Nit del Cadena 1 – 20
proveedor” de caracteres
caracteres
“Nombre del Cadena 1 – 50
caracteres
“Tipo de Cadena 1 – 50
servicio que de caracteres
ofrece” caracteres
“Teléfono” Cadena 1 – 50
de caracteres
caracteres
“Correo Cadena 1 – 50
electrónico” de caracteres
caracteres
“Nombre Cadena 1 – 50
ejecutivo de de caracteres
cuenta” caracteres
“Teléfono Cadena 1 – 50
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
Fuente: El Autor
65
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

CU3 Eliminar proveedor
Actor: Versión:
Administrador 1.0
proveedores.
2) El usuario oprime el botón “Eliminar
Proveedor”.
3) Al seleccionar el proveedor a eliminar, el 3.1) El usuario oprime el botón “Regresar” para
sistema despliega una ventana de dialogo cancelar el proceso y volver al módulo de
para confirmar la eliminación del proveedor. proveedores.
4) El usuario oprime el botón “Si” de la 4.1) El usuario oprime el botón “No” para
ventana de dialogo. 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
Fuente: El Autor
66
CU4 Editar proveedor
Actor: Versión:
Administrador 1.0
1) El usuario ingresa al módulo de proveedores.
2) El usuario oprime el botón “Editar Proveedor”.
3) Al oprimir el botón “Editar Proveedor”, el 3.1) El usuario oprime el botón “Regresar”
sistema carga un formulario de edición, además de para cancelar el proceso y volver al
los botones “Actualizar proveedor” y “Regresar”. módulo de proveedores.
Los campos son:
Tipo de Longitud
Nombre del dato
campo
“Nit del Cadena 1 – 20
caracteres
caracteres
servicio que de caracteres
ofrece” caracteres
“Teléfono” Cadena 1 – 50
de caracteres
caracteres
caracteres
“Teléfono Cadena 1 – 50
5) El usuario solicita la actualización de los datos 5.1) Si el sistema no graba los datos,
oprimiendo el botón “Actualizar datos del informa que no fue posible actualizar la
proveedor”. información del proveedor
6) El sistema graba los datos actualizados.
Fuente: El Autor
67
CU5 Consultar proveedor
Actor: Versión:
Administrador, agente 1.0
1) El usuario ingresa al módulo de proveedores.
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
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
68
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 3.1) El usuario oprime el botón “Regresar”
botones “Crear sede” y “Regresar”. de sedes.
4) El usuario llena todos los campos del
formulario.
Los campos a llenar son:
Nombre del Tipo de Longitud

campo dato
“Nombre de Cadena 1 – 50
la sede ” de caracteres
caracteres
“Teléfono de Cadena 1 – 50
la sede” de caracteres
caracteres
“Segmento Cadena 1 – 50
de red ” de caracteres
caracteres
“Servicio de Cadena 2 caracteres
Voz IP” de
caracteres
caracteres
“Código de Numérico 1 - 99999
canal”
“Diagrama de Cadena 1 – 50
red” de caracteres
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
Fuente: El Autor
69
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 3.1) El usuario oprime el botón “Regresar”
despliega una ventana de dialogo para para cancelar el proceso y volver al módulo
confirmar la eliminación de la sede. de sedes.
4) El usuario oprime el botón “Si” de la ventana 4.1) El usuario oprime el botón “No” para
de dialogo. 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 la sede.
Fuente: El Autor

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 3.1) El usuario oprime el botón “Regresar”
sistema carga un formulario de edición, además para cancelar el proceso y volver al módulo
de los botones “Actualizar Sede” y “Regresar”. de sedes.

Los campos son:

campo dato
“Nombre de Cadena 1 – 50
la sede ” de caracteres
caracteres
“Teléfono de Cadena 1 – 50
la sede” de caracteres
caracteres
de red ” de caracteres
caracteres
“Servicio de Cadena 2 caracteres
Voz IP” de
70
caracteres
caracteres
“Código de Numérico 1 - 99999
canal”
“Diagrama de Cadena 1 – 50
red” de caracteres
caracteres
5) El usuario solicita la actualización de los 5.1) Si el sistema no graba los datos,
datos oprimiendo el botón “Actualizar datos de informa que no fue posible actualizar la
la sede”. información de la sede.
Fuente: El Autor
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
Fuente: El Autor
Cuadro 4. Gestión De Canales

Figura 9. Caso de Uso Gestión De Canales
Fuente: El Autor
71
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

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 3.1) El usuario oprime el botón “Regresar”
botones “Crear Canal” y “Regresar”. de canales.
formulario.

campo dato
proveedor ” de caracteres
caracteres
sede” de caracteres
caracteres
“Ancho de Cadena 2 – 6
banda ” de caracteres
caracteres
servicio” de caracteres
caracteres
“Medio del Cadena 1 – 50
caracteres
“Modo de Cadena 1 – 50
operación” de caracteres
caracteres
de red” de caracteres
caracteres
72
“Fecha de Fecha DD/MM/AA
inicio del
contrato”
“Valor del Numérico 1 -
costo - decimal 99999999999
mensual”
“SLA” Cadena 1 – 50
de caracteres
caracteres
“Nit Cadena 1 – 15
asociado” de caracteres
caracteres
“Estado del Cadena 1 carácter
canal” de
caracteres
“Valor Numérico 0 -100
latencia - promedio
normal”
latencia - promedio
promedio”
latencia alta” - promedio
latencia - promedio
superior”
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
Fuente: El Autor

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 3.1) El usuario oprime el botón “Regresar”
confirmar la eliminación del canal. de canales.
informa que no fue posible eliminar el canal.
Fuente: El Autor
73
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 3.1) El usuario oprime el botón “Regresar”
de los botones “Actualizar Canal” y “Regresar”. de canales.

Los campos son:

campo dato
proveedor ” de caracteres
caracteres
caracteres
“Ancho de Cadena 2 – 6
banda ” de caracteres
caracteres
caracteres
“Medio del Cadena 1 – 50
caracteres
“Modo de Cadena 1 – 50
operación” de caracteres
caracteres
de red” de caracteres
caracteres
inicio del
contrato”
“Valor del Numérico 1 -
costo - decimal 99999999999
mensual”
“SLA” Cadena 1 – 50
74
de caracteres
caracteres
“Nit Cadena 1 – 15
asociado” de caracteres
caracteres
“Estado del Cadena 1 carácter
canal” de
caracteres
latencia - promedio
normal”
latencia - promedio
promedio”
latencia alta” - promedio
latencia - promedio
superior”
datos oprimiendo el botón “Actualizar datos del informa que no fue posible actualizar la
canal”. información del canal.
Fuente: El Autor

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
Fuente: El Autor
75
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 3.1) El usuario oprime el botón “Regresar”
botones “Crear Activo” y “Regresar”. de activos.
76
Los campos son:

campo dato
“Código Cadena 1 – 50
activo fijo ” de caracteres
caracteres
caracteres
“Descripción Cadena 1 – 50
” de caracteres
caracteres
“Marca” Cadena 1 – 50
de caracteres
caracteres
“Serial” Cadena 1 – 50
de caracteres
caracteres
“Observación Cadena 1 – 100
” de caracteres
caracteres
“Estado” Cadena 1 carácter
de
caracteres
inicio del
activo”
revisión del
activo”
finalización
de garantía”
inicio de
garantía”
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
Fuente: El Autor
77
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 3.1) El usuario oprime el botón “Regresar”
confirmar la eliminación del activo. de activos.
informa que no fue posible eliminar el activo.
Fuente: El Autor

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 3.1) El usuario oprime el botón “Regresar”
de los botones “Actualizar Activo” y “Regresar”. de Activos.
78
Los campos son:
campo dato
“Código Cadena de 1 – 50
activo fijo ” caracteres caracteres
“Nombre Cadena de 1 – 50
sede” caracteres caracteres
“Descripción Cadena de 1 – 50
” caracteres caracteres
“Marca” Cadena de 1 – 50
caracteres caracteres
“Serial” Cadena de 1 – 50
caracteres caracteres
“Observación Cadena de 1 – 100
” caracteres caracteres
“Estado” Cadena de 1 carácter
caracteres
inicio del
activo”
revisión del
activo”
finalización
de garantía”
inicio de
garantía”
activo”. información del activo.
Fuente: El Autor

CU17 Consultar activo
Actor: Versión:
1) El usuario ingresa al módulo de activos.
2) El usuario oprime el botón “Consultar Activo”.
79
3) Al seleccionar la opción consultar activos; el
los activos existentes en el sistema
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

CU18 Editar activo
Actor: Versión:
Administrador 1.0
80
“Contactos”.
Contacto”.
3) Al oprimir el botón “Crear Contacto”, el 3.1) El usuario oprime el botón “Regresar”
botones “Crear Contacto” y “Regresar”. de contactos.
formulario.

campo dato
contacto ” de caracteres
caracteres
“Teléfono(s) Cadena 1 – 50
del contacto” de caracteres
caracteres
“Cargo del Cadena 1 – 50
contacto” de caracteres
caracteres
“Sede Cadena 1 – 50
asociada” de caracteres
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
Fuente: El Autor

CU19 Eliminar contacto
Actor: Versión:
Administrador 1.0
1) El usuario ingresa al módulo de “Contactos”.
Contacto”.
3) Al seleccionar el contacto a eliminar, el 3.1) El usuario oprime el botón “Regresar”
sistema despliega una ventana de dialogo para para cancelar el proceso y volver al módulo
confirmar la eliminación del contacto. de contactos.
81
informa que no fue posible eliminar el
contacto.
Fuente: El Autor

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 3.1) El usuario oprime el botón “Regresar”
de los botones “Actualizar Contacto” y de Contactos.
“Regresar”.
Los campos son:

campo dato
contacto ” de caracteres
caracteres
“Teléfono(s) Cadena 1 – 50
del contacto” de caracteres
caracteres
“Cargo del Cadena 1 – 50
contacto” de caracteres
caracteres
“Sede Cadena 1 – 50
asociada” de caracteres
caracteres
contacto”. información del contacto.
Fuente: El Autor
82
CU21 Consultar contacto
Actor: Versión:
1) El usuario ingresa al módulo de contactos.
contactos”.
3) Al seleccionar la opción consultar contactos; el
los activos existentes en el sistema
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
83
CU22 Crear credencial de administración
Actor: Versión:
Administrador 1.0
“Credenciales de administración”.
Credencial de administración”.
3) Al oprimir el botón “Crear Credencial de 3.1) El usuario oprime el botón “Regresar”
administración”, el sistema carga un formulario para cancelar el proceso y volver al módulo
además de los botones “Crear Credencial de de Credenciales de administración.
administración” y “Regresar”.
formulario.

campo dato
“Activo fijo Cadena 1 – 50
asociado ” de caracteres
caracteres
“Servicio” Cadena 1 – 50
de caracteres
caracteres
“Usuario” Cadena 1 – 50
de caracteres
caracteres
“Password” Cadena 1 – 50
de caracteres
caracteres

Credencial de administración”
6) El sistema graba los datos de la 6.1) Si el sistema no graba los datos,

Credencial de administración informa que no fue posible crear la
Credencial de administración
Fuente: El Autor

CU23 Eliminar Credencial de administración
Actor: Versión:
Administrador 1.0
84
“Credenciales de administración”.
3) Al seleccionar el contacto a eliminar, el 3.1) El usuario oprime el botón “Regresar”
sistema despliega una ventana de dialogo para para cancelar el proceso y volver al módulo
confirmar la eliminación de la credencial. de Credenciales de administración.
informa que no fue posible eliminar la
Credencial de administración.
Fuente: El Autor

CU24 Editar credencial de administración
Actor: Versión:
Administrador 1.0
Credenciales de administración.
2) El usuario oprime el botón “Editar
3) Al oprimir el botón “Editar Credencial de 3.1) El usuario oprime el botón “Regresar”
administración”, el sistema carga un formulario para cancelar el proceso y volver al módulo
de edición, además de los botones “Actualizar de Credenciales de administración.
Credencial de administración” y “Regresar”.

Los campos son:

campo dato
“Activo fijo Cadena 1 – 50
asociado ” de caracteres
caracteres
“Servicio” Cadena 1 – 50
de caracteres
caracteres
“Usuario” Cadena 1 – 50
de caracteres
caracteres
85
“Password” Cadena 1 – 50
de caracteres
caracteres

datos oprimiendo el botón “Actualizar credencial informa que no fue posible actualizar la
de administración”. información.
Fuente: El Autor

CU25 Consultar credencial de administración
Actor: Versión:
1) El usuario ingresa al módulo de credencial de
administración.
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
Fuente: El Autor
Cuadro 8. Monitoreo De Canales
Figura 13. Caso de Uso Gestión Monitoreo De Canales
Fuente: El Autor
86
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

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 2.b) Si no existe ningún canal registrado
que presenten una latencia alta, superior o aparecerá el mensaje: “No existen canales
aquellos canales con caída total. Así mismo carga registrados en el sistema para el
la información asociada a los canales mostrados. monitoreo”
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].
87
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.
88
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.
89
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.
90
Figura 17. Diagrama De Actividades – Gestión De Canales
Fuente: El Autor

activos, el cual describe las acciones referentes al registro, edición, adición y
eliminación de activos.
91
Figura 18. Diagrama De Actividades – Gestión De Activos
Fuente: El Autor

contactos, el cual describe las acciones referentes al registro, edición, adición y
eliminación de contactos.
92
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.
93
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.
94
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
95
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
96
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
97
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
98
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

Tabla Proveedor
Nombre de la tabla Objetivo
Inmprove Almacenar la información de los
proveedores.
Llave Campo Tipo Tamaño Descripción
Max
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)
Fuente: El Autor
Tabla 62. Diccionario Tabla Usuario

Tabla Usuario
tlmusuar Almacenar las credenciales de los
usuarios del sistema.
Max
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
99
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
100
Tabla 66. Diccionario Tabla Canal
Tabla Canal
tlmcana Almacenar la información de los canales
Max
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/AA Fecha de inicio del contrato
AA
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
Max
PK cd_cia_af INT 10 Número consecutivo del
activo fijo
PK cd_acti_fijo VARCHAR 50 Código del activo fijo
101
Max
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/AA Fecha de inicio del activo fijo
AA
fe_revi_af DATE DD/MM/AA Fecha de revisión del activo
AA fijo
fe_fin_gara DATE DD/MM/AA Fecha de fin de garantía del
AA activo fijo
fe_inic_gara DATE DD/MM/AA Fecha de inicio de garantía
AA 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
102
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
103
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
104
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
105
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
106
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
107
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
108
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
109
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
110
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
111
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
112
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
113
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

3
segundos)
Contador del bucle 2
Método de implementación HTTP GET
http://localhost/monitoreo/canales.php
Ruta de acceso
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.
114
 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.
115
 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
116
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

117
http://localhost/monitoreo/sedes.php
Ruta de acceso
Fuente: El Autor
5.2.2.1 Resumen de la prueba

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,4 peticiones por segundo.
Fuente: El Autor


Hilo”).
118
Fuente: El Autor
119


proceso.
Figura 49. Grafica De Resultados, Tiempos De Respuesta Prueba 002.
Fuente: El Autor
5.2.3. Escenario 3

ID prueba 003
Método de implementación
HTTP GET
http://localhost/monitoreo/panel.php
Ruta de acceso
Fuente: El Autor
120

para una simulación de 120 usuarios junto a un periodo de subida de 3 segundos
el servidor es capaz de aceptar una media de 40,3 peticiones por segundo.
Fuente: El Autor


Hilo”).
121
Fuente: El Autor
122

proceso.
Fuente: El Autor
5.2.4. Escenario 4

ID prueba 004
Ruta de acceso http://localhost/monitoreo/panel.php
Fuente: El Autor
123

prueba fueron 60, ya que se ejecutaron un grupo de 60 hilos únicamente.
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


Hilo”).
124
Fuente: El Autor
125


proceso.
Fuente: El Autor
126
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.
127
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
128
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>
129
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>.
130
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].
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/>
131
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>
132

Rediseño e Implementación Del Sistema de Monitoreo de La Red PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rediseño e Implementación Del Sistema de Monitoreo de La Red PDF

Încărcat de

Drepturi de autor:

Formate disponibile

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

MICHAEL GALLEGO ADAMES

Trabajo de Grado para optar al título de

UNIVERSIDAD CATÓLICA DE COLOMBIA

Aprobado por el comité de grado

Bogotá, 18, noviembre, 2015

Figura 1. Capas del modelo OSI 25

Tabla 1. Lista de Requerimientos Funcionales 38

Cuadro 1. Casos De Uso Autenticación 63

Bajo este lineamiento, el objetivo principal del presente proyecto es el de rediseñar

PALABRAS CLAVE: Distribuidora Nissan S.A, Red de telecomunicaciones,

KEY WORDS: Distribuidora Nissan S.A, Telecommunication network,

Hoy en día, la calidad de la comunicación interna y externa entre las distintas

En el presente capítulo se definen, describen y caracterizan todos los conceptos,

En la actualidad, las redes se han convertido en un elemento determinante en el

El monitoreo, es determinante en la prevención y resolución de incidentes con la

Las aplicaciones de software especializadas en el monitoreo de red permiten

Los tipos de aplicaciones de software que existen actualmente presentan

Las principales soluciones de monitoreo que existen pueden agruparse en cuatro

1.1.1. Software de código abierto/Open Source. Las soluciones Open Source,

Entre las herramientas de código abierto más utilizadas para el monitoreo de la

1.1.1.1. NAGIOS. Es un sistema de monitorización de equipos y servicios de

1.1.1.3. ZABBIX. Es una solución que busca centralizar el monitoreo de la

1.1.2. Software de gestión de red empresarial. Son herramientas que ofrecen

1.1.3. Software especializado. Esta categoría, abarca los sistemas de

Como se evidencia, existen múltiples opciones a tener en cuenta para el

Este es el caso de la organización Distribuidora Nissan S.A, una compañía

1.2. PLANTEAMIENTO DEL PROBLEMA

En la actualidad, el crecimiento tecnológico y la expansión empresarial,

Bajo esta premisa, ofrecer el mejor servicio es imprescindible para una

Una actividad imprescindible para la organización es el monitoreo de la red de

Actualmente, el área de redes y telecomunicaciones de Distribuidora Nissan S.A

Adicionalmente, no se cuenta con una base de datos que almacene la información

En base a estas necesidades que presenta el área de redes y telecomunicaciones

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

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

 Realizar el levantamiento de requerimientos funcionales y no funcionales del

 Diseñar el sistema web de monitoreo para la red de comunicaciones de

 Desarrollar el sistema de monitoreo de red que permita gestionar la información

 Realizar las pruebas para la validación y verificación del sistema de monitoreo

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

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

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

 Facilitar la generación de reportes estadísticos que permitan la predicción de

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

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

 Los requerimientos de la herramienta de monitoreo de la red están orientados

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

 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

 Red de datos: conjunto de equipos de cómputo y dispositivos

 Servicios de red: conjunto de funciones y aplicaciones que se ejecutan a

 Gestión De red: hace referencia al conjunto de métodos, procedimientos,

 Operación: tiene que ver con mantener activos y en óptimo funcionamiento,

 Administración: proceso que implica el seguimiento de los recursos que

 Mantenimiento: se refiere a las actividades de reparación y actualización

 ICMP (Internet Control Message Protocol): es un protocolo de control que

 SNMP (Simple Network Management Protocol): es un protocolo del nivel