Embed Size (px)
Citation preview
1
DESARROLLO DE UN APLICATIVO PARA EL CONTROL Y SEGUIMIENTO DE
INCIDENTES PARA EL PROYECTO BANCO AGRARIO DE LA EMPRESA
THOMAS MTI
DANIEL ALBERTO SALAMANCA AVELLANEDA
20161373001
WILSON FERNANDO VARGAS PIZA
20161373004
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELECOMUNICACIONES
2018
2
DESARROLLO DE UN APLICATIVO PARA EL CONTROL Y SEGUIMIENTO DE
INCIDENTES PARA EL PROYECTO BANCO AGRARIO DE LA EMPRESA
THOMAS MTI
DANIEL ALBERTO SALAMANCA AVELLANEDA
20161373001
WILSON FERNANDO VARGAS PIZA
20161373004
TRABAJO DE MONOGRAFÍA PARA OPTAR AL TITULO DE INGENIERO EN
TELECOMUNICACIONES
DIRECTOR DEL PROYECTO:
ING. LUIS FERNANDO PEDRAZA MARTÍNEZ PHD
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA EN TELECOMUNICACIONES
2018
3
NOTA DE ACEPTACIÓN
___________________________________
___________________________________
___________________________________
___________________________________
___________________________________
FIRMA DIRECTOR
___________________________________
FIRMA COORDINADOR
___________________________________
FIRMA CALIFICADOR
___________________________________
Bogotá D.C. Mayo 09 de 2018
4
Resumen
El presente trabajo, es el desarrollo de un aplicativo enfocado en el control interno
y seguimiento de incidentes de alto impacto, definidos como cualquier evento que
no hace parte del proceso y que puede causar una interrupción en el mismo, tales
como indisponibilidad, lentitud, entre otros para el proyecto BANCO AGRARIO de
la empresa THOMAS MTI, donde primero se encuentra los fundamentos teóricos
en desarrollo de aplicativos y software, así como la seguridad que se deben
brindar para los mismos, adicionalmente se tiene una contextualización de la
empresa, del proyecto banco agrario y los problemas que presenta; se realiza el
levantamiento de información correspondiente para identificar las categorías
necesarias del aplicativo, para verificar su funcionamiento se realizaron las
pruebas correspondientes con el fin de determinar su disponibilidad, seguridad y
calidad de servicio para la correcta cuantificación de los incidentes reportados,
para finalizar se exponen unas recomendaciones basadas en los resultados
obtenidos.
Palabras clave: Incidente, cuantificación, seguridad, disponibilidad, calidad de
servicio.
Abstract
The present work, is the development of an application focused on the internal
control and monitoring of high impact incidents defined as any event that is not part
of the process and that can cause an interruption in it, such as unavailability,
slowness, among others. for the BANCO AGRARIO project of the company
THOMAS MTI, where first the theoretical foundations are found in the development
of applications and software, as well as the security that must be provided for
them, in addition there is a contextualization of the company, of the agrarian bank
project and the problems it presents; the corresponding information is collected to
identify the necessary categories of the application, to verify its operation, the
corresponding tests were carried out in order to determine its availability, safety
and quality of service for the correct quantification of the incidents reported, to
finalize it is exposed some recommendations based on the results obtained.
Key words: Incident, quantification, security, availability, quality of service.
5
Tabla de contenido
INTRODUCCIÓN .................................................................................................. 10
1. GENERALIDADES ......................................................................................... 11
1.1. DESCRIPCIÓN DE LA EMPRESA........................................................... 11
1.2. PRINCIPALES INCIDENTES DE ALTO IMPACTO EN EL PROYECTO . 11
2. PLANTEAMIENTO DEL PROBLEMA ............................................................ 12
2.1. JUSTIFICACIÓN ...................................................................................... 12
2.2. IMPACTO ESPERADO ............................................................................ 12
3. OBJETIVOS ................................................................................................... 13
3.1. OBJETIVO GENERAL ............................................................................. 13
3.2. OBJETIVOS ESPECÍFICOS .................................................................... 13
4. MARCO CONCEPTUAL ................................................................................ 14
5. ESTADO DEL ARTE ...................................................................................... 16
6. MARCO TEÓRICO ........................................................................................ 18
6.1. DESARROLLO DE SOFTWARE SEGURO ............................................. 18
6.2. DIAGRAMA DE CASOS DE USO ............................................................ 19
6.3. MODELO DE AMENAZAS ....................................................................... 20
6.3.1. PASOS GENÉRICOS ........................................................................ 20
6.4. SEGURIDAD INFORMÁTICA .................................................................. 21
6.4.1. OBJETIVOS DE LA SEGURIDAD INFORMÁTICA. .......................... 21
6.4.2. MEDIDAS PARA LA SEGURIDAD INFORMÁTICA. ......................... 23
6.5. SEGURIDAD DE LAS APLICACIONES Y SOFTWARE .......................... 23
6.6. FUNDAMENTOS DE LA PROTECCIÓN: AMENAZAS,
VULNERABILIDADES Y RIESGOS .................................................................. 24
6.7. OBJETIVOS GENERALES DE SEGURIDAD PARA LAS REDES DE
TELECOMUNICACIONES ................................................................................. 25
6.8. CALIDAD DE SERVICIO (QOS). ............................................................. 26
6.8.1. PUNTOS DE VISTA DE LOS CRITERIOS DE QOS. ........................ 26
6.9. MÉTRICAS DE CÓDIGO PARA “.NET” ................................................... 28
6.9.1. MEDIDAS DEL SOFTWARE ............................................................. 28
6
6.9.2. MÉTODOS ANÓNIMOS .................................................................... 29
6.10. IIS DE WINDOWS SERVER ................................................................. 29
6.10.1. DESCRIPCIÓN DEL ROL .............................................................. 29
6.10.2. APLICACIONES PRÁCTICAS ....................................................... 30
6.11. CACTI ................................................................................................... 30
6.12. APACHE JMETER ................................................................................ 32
7. METODOLOGÍA PROPUESTA ..................................................................... 34
8. DESARROLLO DEL PROYECTO .................................................................. 35
9. LEVANTAMIENTO DE INFORMACIÓN ......................................................... 35
9.1. ANÁLISIS ................................................................................................. 38
9.1.1 IDENTIFICACIÓN Y CONTEXTUALIZACIÓN ................................... 38
9.1.2. REQUERIMIENTOS ............................................................................. 38
9.1.3. REQUERIMIENTOS FUNCIONALES ................................................ 38
9.1.4. REQUERIMIENTOS NO FUNCIONALES ......................................... 40
9.1.5. DIAGRAMAS DE CASOS DE USO ................................................... 40
9.1.6. DIAGRAMA DE FLUJO ..................................................................... 43
10. DISEÑO ....................................................................................................... 45
10.1. DISEÑO DE BASE DE DATOS ............................................................ 45
10.2. INTERFAZ (FRONT) ............................................................................. 47
10.2.1. PANTALLA INGRESO USUARIO .................................................. 47
10.2.2. PANTALLA PRINCIPAL USUARIO FINAL ..................................... 47
10.2.3. REPORTAR INCIDENTE ............................................................... 48
10.2.4. GUARDAR Y REPORTAR SOLUCIÓN .......................................... 49
10.2.5. REPORTAR SOLUCIÓN ................................................................ 49
10.2.6. CONSULTAS ................................................................................. 50
10.2.7. EXTRACCIÓN DE INFORMACIÓN................................................ 50
10.3. PRUEBAS Y AJUSTE DE PRUEBAS ................................................... 51
10.4. SEGURIDAD EN EL APLICATIVO BITÁCORA .................................... 53
11. CALIDAD DE SERVICIO ............................................................................. 53
11.1. USABILIDAD ......................................................................................... 53
11.1.1. TIEMPOS DE RESPUESTA ........................................................... 53
7
11.2. FIABILIDAD .......................................................................................... 56
11.2.1. DISPONIBILIDAD ........................................................................... 56
11.2.2. TOLERANCIA A FALLOS .............................................................. 59
11.3. SEGURIDAD ......................................................................................... 63
11.3.1. ANÁLISIS DE VULNERABILIDADES ................................................. 63
11.3.2. MODELO DE AMENAZAS ............................................................. 66
11.3.2.3. NIVELES DE CONFIANZA ......................................................... 67
12. ANÁLISIS DE TRÁFICO .............................................................................. 69
13. ANÁLISIS MÉTRICAS DE CÓDIGO ........................................................... 71
13.1. ÍNDICE DE MANTENIMIENTO ............................................................. 71
13.2. ACOPLAMIENTO DE CLASES ............................................................ 73
14. RESULTADOS ............................................................................................ 75
14.1. RESULTADOS GENERALES. .............................................................. 75
14.2. ENCUESTA .......................................................................................... 75
CONCLUSIONES .................................................................................................. 77
REFERENCIAS BIBLIOGRÁFICAS ...................................................................... 78
ANEXOS: .............................................................................................................. 81
Anexo 1: Manual de Usuario .............................................................................. 81
Anexo 2: Modelo DREAD .................................................................................. 97
Anexo 3: Configuración JMeter .......................................................................... 98
Anexo 4: Métricas de Código ........................................................................... 101
8
Lista de tablas
Tabla 1. Descripción de Categoría. Fuente: Autores. ............................................ 37
Tabla 2. Ingreso de Usuario. Fuente: los autores. ................................................. 38
Tabla 3. Registro de Incidencias. Fuente: los autores. .......................................... 39
Tabla 4. Registro de Solución. Fuente: los autores. .............................................. 39
Tabla 5.Consultas. Fuente: los autores. ................................................................ 39
Tabla 6. Exportar Información. Fuente: los autores. .............................................. 40
Tabla 7. Actores. Fuente: los autores. ................................................................... 40
Tabla 8. Ingreso Usuario Al Sistema. Fuente: los autores. ................................... 41
Tabla 9. Registro de Incidencias. Fuente: los autores. .......................................... 41
Tabla 10. Registro de Solución. Fuente: los autores. ............................................ 42
Tabla 11. Consultas. Fuente: los autores. ............................................................. 42
Tabla 12. Exportar Información. Fuente: los autores. ............................................ 43
Tabla 13. Portada. Fuente: Los autores. ............................................................... 67
Tabla 14. Dependencias Externas. Fuente: Los autores. ...................................... 67
Tabla 15. Niveles de Confianza. Fuente: Los autores. .......................................... 67
Tabla 16. Puntos de Entrada. Fuente: Los autores. .............................................. 68
Tabla 17. Activos. Fuente: Los autores. ................................................................ 68
Tabla 18. STRIDE. Fuente: Los autores. .............................................................. 69
Tabla 19. Cálculo de medidas de tendencia central. Fuente: Los autores. ........... 71
Tabla 20. Cálculo de Parámetros de Tabla de Distribución de Frecuencias. Fuente:
Los autores. ........................................................................................................... 71
Tabla 21. Tabla de Distribución de Frecuencias. Fuente: Los autores. ................. 72
Tabla 22. Cálculo de Medidas de Tendencia Central. Fuente: Los autores. ......... 73
Tabla 23. Cálculo de Parámetros de Tabla de Distribución de Frecuencias. Fuente:
Los autores. ........................................................................................................... 73
Tabla 24. Tabla de Distribución de Frecuencias. Fuente: Los autores. ................. 74
Tabla 25. Resultados Tabulados Pruebas. Fuente: Autores ................................. 75
Tabla 26. Resultados Análisis De Tráfico. Fuente: Autores. ................................. 75
9
Lista de imágenes
Figura 1. Proceso de digitalización y custodia de documentos proyecto Banco
Agrario, Fuente: Los autores. ................................................................................ 11
Figura 2. Ejemplo Modelo de caso de uso. Fuente: Imágenes Prediseñadas de
Windows ................................................................................................................ 19
Figura 3. Diagrama de bloques, fuente: los autores. ............................................. 34
Figura 4. Comparación Número de Casos GLPI vs Correo. Fuente: Autores ....... 35
Figura 5. Diagrama de flujo aplicativo BITACORA. Fuente: Los autores. ............. 44
Figura 6. Modelo Entidad Relación. Fuente: Los autores. ..................................... 45
Figura 7. Ingreso Usuario. Fuente: Los autores. ................................................... 47
Figura 8. Pantalla Principal Usuario Final. Fuente: Los autores. ........................... 48
Figura 9. Reportar Incidente. Fuente: Los autores. ............................................... 48
Figura 10. Guardar y Reportar Solución. Fuente: Los autores. ............................. 49
Figura 11. Reportar Solución. Fuente: Los autores. .............................................. 49
Figura 12. Consultas. Fuente: Los autores............................................................ 50
Figura 13. Extracción de Información. Fuente: Los autores. ................................. 50
Figura 14. Archivo XLS. Fuente: Los autores. ....................................................... 51
Figura 15.Página de autenticación (resultados JMeter). Fuente: Los autores....... 54
Figura 16. Autenticación Usuario (resultados JMeter). Fuente: Los autores. ........ 54
Figura 17. Página principal (resultados JMeter). Fuente: Los autores. ................. 55
Figura 18.Cerrar sesión (resultados JMeter). Fuente: Los autores. ...................... 55
Figura 19. Página de autenticación (resultados JMeter). Fuente: Los autores...... 56
Figura 20. Uso de Memoria. Fuente: Los autores. ................................................ 57
Figura 21. Tráfico. Fuente: Los autores. ............................................................... 58
Figura 22. Uso Disco C. Fuente: Los autores........................................................ 59
Figura 23. Asignación de 1000 hilos JMeter. Fuente: Los autores. ....................... 60
Figura 24. Reporte resumen (Resultado JMeter). Fuente: Los autores. ............... 60
Figura 25. Conexiones establecidas en el servidor (Resultados ProcessExplorer).
Fuente: Los autores. ............................................................................................. 61
Figura 26. Información del sistema (Resultados ProcessExplorer). Fuente: Los
autores. ................................................................................................................. 61
Figura 27. Comportamiento de la CPU (Resultados ProcessExplorer). Fuente: Los
autores. ................................................................................................................. 62
Figura 28. Escaneo Vulnerabilidades del Servidor. . Fuente: NESUS Scan. ........ 66
Figura 29. Histograma y Polígono de Frecuencias. Fuente: Los autores. ............. 72
Figura 30. Histograma y Polígono de Frecuencias. Fuente: Los autores. ............. 74
10
INTRODUCCIÓN
La empresa THOMAS MTI se dedica al manejo de documentos en la
administración y la seguridad de sus procesos de información. Se enfoca en
servicios de confidencialidad, disponibilidad inmediata e integridad de la
información; en el área de tecnología de la empresa THOMAS MTI se manejan
varios proyectos, para el desarrollo del proyecto de grado se centró en el proyecto
Banco Agrario, la empresa cuenta con la herramienta GLPI (sistema de
seguimiento de incidencias y de solución service desk) para el registro de
incidentes y solicitudes relacionados a la aplicación de Gestión Documental
(SIGDOC) y lo relacionado a soporte nivel I (soporte a equipos y periféricos) y
teniendo en cuenta que de acuerdo a lo pactado con el cliente los incidentes de
alto impacto como indisponibilidad, lentitud, entre otros que afecten el proceso
normal se deben manejar vía telefónica o mediante correo electrónico, se
evidencio la necesidad de cuantificar y realizar los seguimientos correspondientes
a dichos incidentes para el control interno, por lo tanto se realizó el desarrollo de
un aplicativo que permitiera realizar la cuantificación de estos.
Para el desarrollo se plantearon distintas fases que van desde el levantamiento de
información hasta la realización de pruebas y un ajuste de las mismas, por
disposición de la empresa se realiza un manual de usuario el cual se encuentra en
el primer anexo del documento.
En la “BITACORA” (nombre que la empresa sugirió para el aplicativo), se realiza el
registro del inconveniente almacenando la información en una base de datos
creada en un servidor con sistema operativo Windows server 2012, el motor de la
base de datos es SQL server 2012, para la publicación de la aplicación se utilizó el
IIS de Windows server, para garantizar mayor seguridad se utiliza una
autenticación con el usuario de SIGDOC.
11
1. GENERALIDADES
1.1. DESCRIPCIÓN DE LA EMPRESA
Thomas MTI es una empresa del grupo Thomas Greg & Sons, creada en el 2005
para prestar servicios de seguridad, manejo y administración de procesos de
información; la empresa Thomas MTI se encarga de la prestación de los servicios
de gestión documental para diferentes bancos y empresas ofreciendo la
plataforma tecnológica SIGDOC.
1.2. PRINCIPALES INCIDENTES DE ALTO IMPACTO EN EL
PROYECTO
Antes de definir los incidentes de alto impacto que se presentan en el proyecto
Banco Agrario, se muestra a continuación un diagrama del proceso general que se
realiza para la digitalización y custodia de los documentos.
Figura 1. Proceso de digitalización y custodia de documentos proyecto Banco Agrario, Fuente: Los autores.
Teniendo en cuenta que el activo principal en el proyecto Banco Agrario son las
imágenes, los principales incidentes que se presentan o se pueden presentar son
los relacionados con la visualización de estas, por ejemplo lentitud,
indisponibilidad, entre otros.
12
2. PLANTEAMIENTO DEL PROBLEMA
A nivel empresarial se presentan diferentes incidentes que afectan de manera más
critica los procesos diarios, generando inconformidades por parte del cliente final
que utiliza el servicio que ofrece la empresa, por lo tanto nace la interrogante
¿Cómo realizar el control interno y seguimientos de los incidentes de manera
eficiente y rápida, que afectan los procesos diarios en un proyecto?
En aras de dar respuesta a esta pregunta y tomando como referencia el proyecto
Banco Agrario de la empresa Thomas MTI, focalizado en el área de tecnología, se
cuenta con la herramienta GLPI para la gestión y reporte de incidencias
relacionadas a la aplicación de Gestión Documental (SIGDOC) y lo concerniente a
soporte nivel I de infraestructura (Soporte equipos, dispositivos, periféricos, etc.), y
debido a lo pactado con el cliente donde los incidentes de mayor impacto que
afectan el proceso diario se deben manejar mediante correo electrónico o vía
telefónica, se evidenció la necesidad de controlar y realizar el seguimiento de
estos incidentes de manera interna para cuantificar lo que genera efectos
negativos en el flujo normal del proceso.
2.1. JUSTIFICACIÓN
La importancia del desarrollo de la aplicación radica en poder llevar un control
interno y seguimiento de los incidentes que se presentan en el proceso normal del
proyecto Banco Agrario de la empresa Thomas MTI, de tal manera que estos se
puedan cuantificar y escalar para su solución definitiva, teniendo una mejor
gestión de incidentes, gestión de problemas (incidentes recurrentes), y en caso
que se requiera una gestión de cambios.
La necesidad que tienen todas las empresas, independiente el producto o servicio
que ofrecen, es de mantener una alta calidad, para no tener afectaciones de alto
impacto en sus procesos, por tal razón las aplicaciones o plataformas web juegan
un papel fundamental debido a la reducción de tiempos y simplificación de tareas.
2.2. IMPACTO ESPERADO
Se esperan tener impactos positivos para la empresa con la implementación de la
aplicación, porque con la ayuda de éste se espera identificar los incidentes
recurrentes que afectan el proceso y de acuerdo a esto analizar si se pueden
considerar problemas, para realizar el escalamiento correspondiente para su
solución con el fin de mitigar la afectación o indisponibilidad que se pueda
presentar en el proceso diario, así mismo se desea cuantificar la mejora en el
servicio que pueda tener la identificación y solución de incidentes y/o problemas
una vez se hayan solucionado.
13
3. OBJETIVOS
3.1. OBJETIVO GENERAL
Desarrollar un aplicativo para el control y seguimiento de incidentes para el
proyecto Banco Agrario de la empresa THOMAS MTI.
3.2. OBJETIVOS ESPECÍFICOS
Realizar el levantamiento de información para conocer qué afecta al
proceso, definir categorías y así poder estandarizar y cuantificar las
deficiencias actuales en el proyecto Banco Agrario.
Diseñar e implementar una plataforma que contenga FRONT, base de
datos, soporte de fallas y una estrategia que permita el registro de datos,
registro de fallas y seguridad de la aplicación.
Evaluar la plataforma desarrollada a nivel de parámetros de Calidad de
Servicio (QoS) y seguridad.
14
4. MARCO CONCEPTUAL
Amenaza: Cosa o persona que constituye una posible causa de riesgo o
perjuicio para alguien o algo.
Aplicación: Programa o conjunto de programas informáticos que realizan
un trabajo específico, diseñado para el beneficio del usuario final.
Categoría: Clase que resulta de una clasificación de personas o cosas
según un criterio o jerarquía.
Cuantificación: Cantidad que resulta de cuantificar una cosa.
Disponibilidad: Una vez que la información ha sido capturada en un
sistema de cómputo, debe ser almacenada de manera segura y estar
disponible para los usuarios cuando la necesiten.
IIS (Internet Information Services): Conjunto de servicios para servidores
usando Microsoft Windows. Es especialmente usado en servidores web.
Incidente: Hecho que se puede presentar en cualquier momento y afecta
de manera considerable el proceso normal del proyecto.
Interfaz: Se denomina así a todo aquel medio físico que conecta un
dispositivo periférico con la computadora; también se le conoce así a todo
el software que comunica al usuario con la misma.
Login: Nombre dado al momento de autentificación al ingresar a un servicio
o sistema.
Query: Cadena de consulta es un término informático que se utiliza para
hacer referencia a una interacción con una base de datos.
Seguridad (Informática): Es el área relacionada con la informática y la
telemática que se enfoca en la protección de la infraestructura
computacional y todo lo relacionado con esta y, especialmente, la
información contenida en un computador o circulante a través de las redes
de computadoras.
15
SQL (Structured Query Language): Es un lenguaje de programación
estándar e interactiva para la obtención de información desde una base de
datos y para actualizarla.
Usuario: Son las personas que interactuarán con el sistema reportando los
incidentes que se les hayan presentado.
Vulnerabilidad: es una debilidad del sistema informático que puede ser
utilizada para causar un daño. Las debilidades pueden aparecer en
cualquiera de los elementos de una computadora, tanto en el hardware, el
sistema operativo, cómo en el software.
W3wp: es un proceso asociado al Pool de conexiones en el ISS.
16
5. ESTADO DEL ARTE
A continuación se presentan proyectos de los cuales se tuvieron en cuenta para la
revisión y evaluación de ciertos parámetros como la Calidad de Servicio, modelo
entidad-relación, siendo parte importante del proyecto a desarrollar.
Platform of Electronic Marketing for Development of ICTs Application [1]:
Proyecto de diseño de una plataforma de marketing electrónico llamada
"MiMercado", la plataforma es dirigida a la comunidad de la localidad de
Ciudad Bolívar en Bogotá, Colombia. Por medio de la plataforma se permite
la oferta de productos y servicios a los residentes locales y tiene como
objetivo mejorar la competitividad y el desarrollo económico de las
empresas locales; especialmente pequeñas y medianas empresas,
permitiendo en el proceso la creación de nuevas oportunidades de mercado
y objetivos comerciales. Para el desarrollo del proyecto se realizó el diseño
de la plataforma con PHP y MySQL, posteriormente se realiza un estudio
del impacto que podrá generar el aplicativo en la sociedad.
En primera instancia logra ser de gran interés el proyecto desarrollado
(“MiMercado”) debido a su locación al compartir ciertas condiciones legales
y normativas de la Ciudad de Bogotá D.C. en la que se desarrolla el
proyecto “BITACORA”, así mismo las herramientas de medición logran ser
de gran ayuda debido al interés de visibilizar el impacto que se logra dar en
la empresa y en el grupo social que hace uso de la información de la
empresa.
Requirements Change Management Based on Object-Oriented Software
Engineering with Unified Modeling Language [2]: Proyecto en el cual se
realiza un estudio para proponer un cambio de requisitos en el modelo de
gestión de metodología orientada a objetos con UML. Para demostrar el
modelo propuesto se eligen modelos comerciales del estudio de caso
seleccionado “Mission Hospital Phuket” como requisitos del usuario para el
sistema del prototipo. Se evalúan dos aspectos del desempeño del sistema
propuesto:
Se rescata el papel que se le otorga a los usuarios del programa al ser la
razón por la cual se da la creación de estos proyectos, apoyado en el
sistema UML encargado del modelado de amenazas y diagrama de casos
de uso, encontrando cierta similitud al proyecto que se desarrolla.
17
Engineering Privacy for Big Data Apps with the Unified Modeling Language
[3]: El proyecto describe las extensiones de privacidad propuestas a UML
para ayudar a los ingenieros de software a visualizar rápidamente la
privacidad, requisitos, y diseño de privacidad en aplicaciones de Big Data.
Para cumplir con los requisitos legales y las mejores prácticas, Big Data las
aplicaciones aplican los principios de Privacidad por Diseño y utilizar
servicios de privacidad, hablando de la anonimización, seudonimización,
seguridad, aviso de uso y consentimiento para uso. Se extiende UML con
iconos de cinta que representan necesarios servicios de privacidad de Big
Data. Dichas extensiones de UML ayudan a los ingenieros de software a
modelar visualmente y rápidamente los requisitos de privacidad en el
análisis fase. Rescatando la importancia de la privacidad de la información
en el que se resalta la importancia de un programa que cumpla con
condiciones de confiabilidad, privacidad y vulnerabilidad.
The Application of Unified Modeling Language in the Performance
Evaluation of R&D Staff [4]: Se toma como ejemplo el diseño de un sistema
de evaluación de desempeño para el personal de R&D Staff de un instituto
biológico. Se utiliza el diagrama de casos de uso, paquetes, clases, de
despliegue, secuencia, y el diagrama de actividades en el análisis y diseño
para la programación orientada a objetos para simplificar el análisis y
modelado del sistema porque minimiza la diferencia entre lenguajes de
modelado.
La metodología que se desarrolla para la creación del proyecto es de gran
interés al contar con herramientas como diagramas de caso de uso y
modelado de amenazas facilitando de esta forma la identificación de
problemas que pueda tener la plataforma
Desarrollo de un Sistema de Información Para la Empresa Datecsa S.A. [5]:
Se realiza un estudio, implementación y análisis de un sistema para
administra la información de la empresa Colombiana Datecsa S.A. Se tiene
en cuenta los requerimientos de los usuarios del sistema, se selecciona la
opción tecnológica más viable para su implementación. Por último se
realiza un análisis de seguridad del sistema desarrollado. Aportando con
esto la importancia que se da por los requerimientos de los usuarios siendo
esto un tipo de diagnóstico de lo que es necesario implementar en términos
de software y sistemas de comunicación, y por último el elemento más
importante para el desarrollo de la BITACORA como es el análisis de
seguridad que se puede ofrecer y brindar por medio de este sistema.
18
6. MARCO TEÓRICO
6.1. DESARROLLO DE SOFTWARE SEGURO
La comunidad WeLiveSecurity menciona algunos consejos para el diseño de un
software seguro:
1. Delinear mecanismos de autenticación difíciles de eludir
La autenticación es el proceso por el cual se permite acreditar la identidad del
usuario y además asignarle un identificador único. Uno de los pilares en la
construcción de aplicaciones seguras es el desarrollo de métodos de
autenticación centralizados que cubran cada posible camino de ingreso.
2. Autorizar, además de autenticar
Con la autenticación se puede designar si un usuario que es previamente
autenticado puede o no realizar acciones para cambiar el estado del sistema. Los
procesos de autorización en los usuarios autenticados se deben pensar desde el
diseño y así evitar sesiones que pueden caer en personas no autorizadas.
3. Separar datos de instrucciones de control
Es importante sobre todo cuando se trabaja con código que es capaz de
modificarse a sí mismo, o con lenguajes que compilan su código en tiempo de
ejecución, por ejemplo JavaScript, donde las instrucciones también se reciben
como datos. Por ende es trascendental sanear las entradas que recibe el sistema
evitando que posibles atacantes puedan manipular el flujo de ejecución
ingresando datos maliciosos.
4. Utilizar criptografía correctamente
Es necesario comprender la criptografía que se aplica al sistema en desarrollo y
así entender los elementos y las características que se buscan proteger, contra las
formas de ataque.
5. Identificar datos sensibles y cómo se los debería gestionar
Es importante proteger toda la información, sin embargo es más importante tener
bien claro qué es lo que realmente se debe cuidad. Es fundamental para el
desarrollo de un sistema definir los datos cuya protección resulta fundamental,
debido a que a partir de la definición se puede esbozar los procesos para el
diseño de la seguridad desde el inicio del ciclo de desarrollo.
19
6. Considerar cambios futuros en objetos y actores
Cuando se empieza con el diseño se debe considerar los contantes cambios de
las propiedades del sistema. Factores a considerar tales como son el crecimiento
de la población de usuarios del sistema, migraciones que puedan afectar al
sistema, además de las vulnerabilidades futuras. Los procedimientos de
actualización se deben implementar de manera segura y además se deben
diseñar con visión de meses, años y en ocasiones décadas [6].
6.2. DIAGRAMA DE CASOS DE USO
La Universidad de Congreso de Mendoza Argentina, define los diagramas de
casos de uso como la forma de documentar el comportamiento deseado del
sistema que se quiere desarrollar, se comunica el comportamiento, se puede
identificar quién y qué interactúa con el sistema, se puede describir lo que el
sistema debería hacer para dichos actores.
Un diagrama es una manera de verificar que el sistema haya capturado todos los
requerimientos necesarios, además de que permite planificar las acciones del
sistema.
Brindan un contexto para los requerimientos además de que son fáciles de
entender y reflejan por qué es necesario el sistema definiendo el caso de uso
(para qué es usado el sistema) y el actor (quién o qué desea interactuar con el
sistema) [7].
En la figura 2 se observa un ejemplo de un modelo de caso.
Figura 2. Ejemplo Modelo de caso de uso. Fuente: Imágenes Prediseñadas de Windows
20
6.3. MODELO DE AMENAZAS
Según la organización OWASP (Open Web Application Security Project) el modelo
de amenazas es la representación estructurada de toda la información que afecta
la seguridad de una aplicación. En pocas palabras es la perspectiva de la
aplicación desde el punto de la seguridad.
Es un proceso para capturar, organizar y analizar toda la información. Permite
tomar decisiones sobre los riesgos de seguridad en las aplicaciones. Con esto se
puede realizar una lista priorizada para las mejoras de seguridad en los requisitos,
diseño e implementación de las aplicaciones.
El modelado de amenazas es un proceso que se utiliza para optimizar la
seguridad en redes, aplicaciones, internet mediante la identificación de objetivos y
vulnerabilidades, definiendo posteriormente las medidas para contrarrestar o
mitigar los efectos de esas amenazas en el sistema [8].
6.3.1. PASOS GENÉRICOS
OWASP presenta una metodología genérica para el modelado de amenazas junto
a sus significados:
Alcance de Evaluación: Inicialmente se debe identificar los activos
tangibles, como bases de datos o archivos sensibles y/o confidenciales. Se
debe realizar la valoración de las capacidades proporcionadas por la
aplicación, adicional se deben tener en cuenta cosas menos concretas,
tales como reputación y el renombre comercial generalmente esto es más
difícil de medir, pero a menudo son considerados como los más críticos.
Identificar agentes de amenaza y posibles ataques: Se debe hacer un
análisis de los posibles atacantes que puede tener la aplicación. Se deben
tener en cuenta elementos internos y externos, errores involuntarios y
ataques maliciosos.
Entender contramedidas existentes: El modelo debe incluir las
contramedidas existentes.
Identificar las vulnerabilidades explotables: Una vez que se tiene una
mejor comprensión de la seguridad en la aplicación, se analizaran las
vulnerabilidades que están relacionadas a nuevos ataques y las
consecuencias negativas que se pueden identificar.
Identificar riesgos prioritarios: Es fundamental en el modelado de
amenazas priorizar los riesgos que tienen una mayor afectación con el fin
de determinar la probabilidad y el nivel de gravedad en el uso de la
aplicación.
21
Identificar las contramedidas para reducir la amenaza: Por último se
debe identificar las contramedidas para reducir el riesgo a niveles
aceptables. [9]
6.4. SEGURIDAD INFORMÁTICA
El uso de internet en las empresas actualmente es un requisito para su
funcionamiento, por lo cual su información se encuentra expuesta a muchos
peligros, por esto la empresa se ve obligada a la implementación de aplicativos
que le permitan controlar el acceso a su red y por ende mantener a salvo la
información de infiltrados más aún cuando se implementan servicios como el
teletrabajo.
La Universidad Internacional de Valencia España, define la seguridad informática
como el proceso de prevenir y detectar el uso no autorizado o indebido de un
sistema informático, esto implica el proceso de proteger contra intrusos el uso de
los recursos informáticos con intenciones maliciosas evitando también el acceso
accidental de los mismos.
Por otra parte, la seguridad informática es el término más genérico de la seguridad
de la información y contiene medidas de seguridad como programas de software
antivirus, firewall y medidas que dependen del usuario final como la activación y
desactivación de funciones en el software y cuidar el uso adecuado de los equipos
terminales, recursos de red e internet.
La seguridad informática es muy importante para las empresas debido a que
ayuda a prevenir el robo de información sensible como contraseñas o incluso
cuentas bancarias [10].
6.4.1. OBJETIVOS DE LA SEGURIDAD INFORMÁTICA.
Los sistemas de información incluyen todos los datos que son de vital importancia
para una compañía y también en el material y los recursos de software que
permiten a una compañía almacenar y hacer circular estos datos. Los sistemas de
información son fundamentales para las compañías y por dicha razón deben ser
protegidos.
Generalmente, la seguridad informática consiste en garantizar que el material y los
recursos de software de una organización se usen únicamente para los propósitos
para los que fueron creados y dentro del marco previsto.
CCM, una comunidad informática española sugiere que la seguridad informática
es posible resumirla con cinco objetivos primordiales:
22
“Integridad, que garantiza que los datos sean los que se supone que son;
Confidencialidad, que asegura que solo los individuos autorizados tengan acceso
a los recursos que se intercambian; Disponibilidad, que garantiza el correcto
funcionamiento de los sistemas de información; Evitar el rechazo, que garantiza de
que no pueda negar una operación realizada; Autenticación, que asegura que solo
los individuos autorizados tengan acceso a los recursos” [11].
Confidencialidad: La confidencialidad consiste en asegurar que sólo los individuos autorizados
tengan acceso a los recursos que se intercambian [12].
Integridad: La información no se puede falsificar. Los datos recibidos o recuperados son los
mismos que fueron enviados o almacenados. [13]
Disponibilidad: Garantizar que los usuarios autorizados tengan acceso a la información y a los
recursos relacionados con la misma, toda vez que lo requiera [14].
No repudio: Garantiza que el remitente del mensaje no puede negar posteriormente haber
enviado el mensaje y así mismo el receptor tampoco puede negar la recepción del
mensaje.
Incluye el no repudio de origen, prueba de que el mensaje fue enviado por el
emisor correspondiente, y no repudio de recepción, prueba de que el mensaje fue
recibido por el destinatario [15].
Autenticación: La autenticación consiste en la confirmación o corroboración de la identidad de un
usuario; es decir, la garantía para cada una de las partes de que su interlocutor es
realmente quien dice ser. Un control de acceso permite (por ejemplo gracias a una
contraseña codificada) garantizar el acceso a recursos únicamente a las personas
autorizadas [16].
23
6.4.2. MEDIDAS PARA LA SEGURIDAD INFORMÁTICA.
La Universidad Internacional de Valencia menciona algunas prácticas o medidas
para el mantenimiento de la seguridad informática y la prevención de intrusiones:
Asegurar la instalación de software legalmente adquirido: Por lo
general el software legal está libre de troyanos y gusanos.
Suites Antivirus: Con las reglas de configuración y del sistema
adecuadamente definidos.
Hardware y Software Corta-Fuegos: Los firewalls ayudan con el bloqueo
de usuarios no autorizados que intentan acceder al computador o a la red.
Uso de contraseñas grandes y complejas: Las contraseñas deben
constar de varios caracteres especiales, números y letras; esto ayuda
bastante a evitar que descifren las claves.
Ingeniería Social: Actualmente a través de las redes sociales los datos
personales están muy expuestos para que los ciber-delincuentes los
puedan obtener.
Criptografía y encriptación: La criptografía es muy importante en una red
debido a que con ésta se puede mantener la información sensible, segura y
secreta [17].
6.5. SEGURIDAD DE LAS APLICACIONES Y SOFTWARE
Actualmente todos los sistemas deben incorporar cuestiones de seguridad para la
defensa de un posible ataque malicioso. Los desarrolladores ya no deben centrar
su atención en los usuarios sino también en los posibles atacantes que quieran
extraer la información, lo cual ha motivado a hacer cambios relevantes en el
proceso de diseño y desarrollo de software para incorporar la seguridad dentro de
los requerimientos del sistema [18].
24
6.6. FUNDAMENTOS DE LA PROTECCIÓN: AMENAZAS,
VULNERABILIDADES Y RIESGOS
Para la definición de seguridad es importante tener claro cuáles son los elementos
que se deben proteger, las amenazas que puede tener, cada una de las
vulnerabilidades que tiene cada elemento y el riesgo general que corren dichos
elementos respecto a las amenazas.
Para las TIC (Tecnologías de la Información y Comunicación) es necesario
proteger elementos como:
Servicios de comunicación e informática.
Información y datos, incluyendo el software y los datos relacionados con los
servicios de seguridad.
Equipos e instalaciones.
Por ejemplo la X.800 (Recomendaciones de características básicas de conexión
de computadoras según la Unión Internacional de Telecomunicaciones ‘ITU’)
menciona que una amenaza de seguridad es una posible violación de seguridad
cuando hay:
Divulgación no autorizada de información.
Destrucción o modificación no autorizada de los datos, equipos u otros
recursos.
Robo, eliminación o pérdida de información o demás recursos.
Interrupción o denegación de servicios.
Usurpación de identidad o simulación de una entidad autorizada.
La ITU proporciona algunas definiciones importantes, las cuales se mencionan a
continuación.
Una amenaza puede ser accidental o intencional además de activas o pasivas.
“Una amenaza accidental es aquélla no premeditada, como un disfuncionamiento
o fallo físico de un sistema o del software. Una amenaza intencionada es aquélla
que una persona realiza como un acto deliberado. (Cuando la amenaza es
intencionada se denomina ataque.)” [19].
Las amenazas activas ocasionan un cambio de estado, es decir la alteración de
datos o incluso la destrucción de equipos físicos. Por otro lado una amenaza
pasiva no ocasiona ningún cambio de estado, como ejemplo tenemos las
escuchas clandestinas. Las vulnerabilidades de seguridad pueden ser defectos o
debilidades que son potencialmente explotables para la violación de un sistema o
la información que contiene. “Hay cuatro tipos de vulnerabilidades: vulnerabilidad
por forma de amenaza que resulta de la dificultad de prever posibles amenazas
25
futuras; vulnerabilidad por diseño y especificación, producida por errores o
descuidos en el diseño de un sistema o del protocolo, que los hacen
inherentemente vulnerables; vulnerabilidad por implementación que se produce
como resultado de errores en la implementación del sistema o el protocolo; y
vulnerabilidad por funcionamiento y configuración que resulta de la utilización
errónea de opciones en las implementaciones o de políticas insuficientes de
instalación (por ejemplo, no se impone la utilización de la criptación en una red
WiFi)” [19].
El riesgo de seguridad se define como: “la medida de los efectos negativos que
pueden resultar de explotarse una vulnerabilidad de seguridad, es decir, si se
ejecuta una amenaza. Si bien nunca puede eliminarse el riesgo, uno de los
objetivos de la seguridad es reducirlos a un nivel aceptable. Para ello es necesario
entender las amenazas y vulnerabilidades para aplicar las contramedidas
adecuadas (es decir, los servicios y mecanismos de seguridad)” [19].
“Las amenazas y los agentes que originan las vulnerabilidades pueden cambiar,
pero siempre habrá vulnerabilidades de seguridad durante toda la vida del sistema
o el protocolo, a menos que se adopten las medidas necesarias para solventarlas.
Si se trata de protocolos normalizados, los riesgos de seguridad relativos al
protocolo pueden ser bastante importantes y de escala global, por lo que es
importante entender e identificar estas vulnerabilidades y adoptar las medidas
necesarias para contrarrestarlas” [19].
6.6.1. OBJETIVOS GENERALES DE SEGURIDAD PARA LAS REDES DE
TELECOMUNICACIONES
Es de vital importancia garantizar la seguridad en la red, para esto la ITU
menciona que principalmente lo que se debe lograr son los requisitos de
seguridad, más que la forma de aplicación.
Los objetivos de seguridad de las redes de telecomunicaciones son:
a. Únicamente los usuarios autorizados deben poder acceder y utilizar las
redes de telecomunicaciones.
b. Los usuarios autorizados han de poder acceder a los elementos
autorizados y utilizarlos.
c. Las redes de telecomunicaciones deben proporcionar privacidad al nivel
fijado por las políticas de seguridad en la red.
d. Todos los usuarios deben ser responsables únicamente y exclusivamente
de sus acciones en las redes de telecomunicaciones.
e. Para garantizar la disponibilidad, las redes de telecomunicaciones deben
estar protegidas contra accesos u operaciones no solicitadas.
26
f. Debe ser posible extraer información relacionada con la seguridad de las
redes de telecomunicaciones (pero sólo por parte de los usuarios
autorizados).
g. Si se detectan violaciones de seguridad, deberán tratarse de manera
controlada de conformidad con un plan predefinido para minimizar los
posibles daños.
h. Cuando se detecte una violación de seguridad, debe ser posible restaurar
los niveles de seguridad normales.
i. La arquitectura de seguridad de las redes de telecomunicaciones debe
proporcionar cierta flexibilidad para soportar diversas políticas de seguridad,
por ejemplo, una aplicación más o menos estricta de los mecanismos de
seguridad [19].
Al implementar dichas medidas de seguridad permite lograr los objetivos de la
seguridad informática: Confidencialidad, integridad, disponibilidad, no repudio y
autenticación.
6.7. CALIDAD DE SERVICIO (QOS).
La Unión Internacional de Telecomunicaciones define la calidad de servicio como
la totalidad de características de un servicio de telecomunicaciones que
determinan su capacidad de satisfacer las necesidades explícitas e implícitas del
usuario del servicio.
6.7.1. PUNTOS DE VISTA DE LOS CRITERIOS DE QOS.
La ITU menciona que la gestión de la QoS resulta más simple si se clasifica según
los diferentes puntos de vista abarcando todos sus aspectos, desde la perspectiva
del proveedor hasta la del usuario o cliente.
6.7.1.1. Necesidades Qos Del Cliente.
Estas necesidades definen el nivel de calidad que se exige en un determinado
servicio, se pueden expresar con un lenguaje común. Al cliente o usuario no le
interesa saber cómo está constituida la red ni el diseño interno que tiene, así que
solo le importa la calidad total del servicio de origen a fin, de extremo a extremo.
La ITU en su apartado G.1000 menciona que la calidad de servicio desde el
ámbito del cliente se expresa mediante parámetros que:
“Se centran en los efectos percibidos por el usuario, más que en sus
causas dentro de la red.
Su definición no depende de las hipótesis del diseño interno de la red.
Tienen en cuenta todos los aspectos del servicio desde el punto de vista del
cliente.
27
El proveedor de servicio puede garantizárselos al cliente y hasta incluirlos
en el contrato.
Se describen en términos independientes de la red e instauran un lenguaje
común, que comprende tanto el usuario como el proveedor de servicio” [20].
6.7.1.2. Qos Ofrecida Por El Proveedor De Servicio.
Es la calidad de servicio que el proveedor espera entregar al cliente y se expresa
en valores atribuidos a los parámetros. “Esta forma de calidad de servicio es
especialmente útil para la planificación y para los acuerdos de nivel de servicio.
Cada servicio tendrá su propio conjunto de parámetros QoS (como en las clases
de QoS de la Rec. UIT-T Y.1540 para los servicios IP). El proveedor de servicio
puede expresar la QoS ofrecida en lenguaje corriente para el cliente, y en lenguaje
técnico para su uso en la industria” [20].
6.7.1.3. Qos Conseguida o Entregada Por El Proveedor.
La calidad de servicio que consigue el proveedor de servicio es una declaración
del nivel real alcanzado y entregado al usuario o cliente, expresándose en valores
asignados a parámetros y deben ser idénticos a los especificados para la QoS
ofrecida, de tal manera que se pueda hacer una comparación para evaluar la
calidad de funcionamiento lograda.
“El proveedor de servicio puede, por ejemplo, declarar que la disponibilidad
obtenida en el trimestre anterior fue de 99,95% con cinco interrupciones de
servicio, una de las cuales duró 65 minutos. La industria, y a veces los
reguladores, publican la QoS conseguida o entregada para información de los
clientes” [20].
6.7.1.4. Qos Percibida Por El Cliente.
La calidad de servicio que percibe el cliente o usuario es la declaración en la que
expresa el nivel de calidad que ellos piensan que experimentaron y generalmente
se expresa en grado de satisfacción evitando los términos técnicos. “Esta calidad
de servicio se mide con encuestas a los clientes y sus comentarios sobre los
niveles de servicio, y puede ser utilizada por el proveedor de servicio para
determinar la satisfacción del cliente en cuanto a la calidad de servicio. Así, por
ejemplo, un cliente puede decir que durante una cantidad inaceptable de
ocasiones tuvo dificultad para realizar una llamada a través de la red y otorgar una
calificación de 2 en una escala de 5, donde 5 corresponde a un servicio excelente.
Idealmente, debería haber una correspondencia uno a uno entre la QoS entregada
y la percibida” [20].
28
6.8. MÉTRICAS DE CÓDIGO PARA “.NET”
Según Microsoft las métricas de código son un conjunto de medidas sobre el
software que proporciona al programador una mejor visión del código que se está
desarrollando. Con dichas métricas de código se puede entender qué tipos y
métodos se deben volver a hacer o realizar pruebas más rigurosas. Se pueden
identificar los riesgos potenciales, entender el estado actual de un proyecto y
realizar un seguimiento durante el desarrollo del software [21].
6.8.1. MEDIDAS DEL SOFTWARE
Las métricas de código que calcula Visual Studio junto con su definición según
Windows definidas en su página oficial son:
Índice de mantenimiento: representa la facilidad relativa del
mantenimiento de un código al calcular un valor de índice entre 0 y 100. Al
obtener un valor alto se interpreta como una mayor facilidad de
mantenimiento. Se puede clasificar por colores, un color verde se encuentra
entre 20 y 100 e indica que el mantenimiento del código es bueno. Una
clasificación entre 10 y 19 es de color amarilla e indica que el
mantenimiento de dicho código es moderado, una clasificación roja se
encuentra entre 0 y 9 indicando que el mantenimiento del código es pobre.
Complejidad ciclomática: mide la complejidad estructural del código.
Calcula el número de rutas de acceso del código de diferentes partes del
flujo del programa. Un flujo de control complejo requerirá muchas más
pruebas para obtener una buena cobertura de código y además será más
difícil de mantener.
Profundidad de herencia: indica el número de definiciones de clase que
se extienden a la raíz de la jerarquía de clases. Entre más profunda es la
jerarquía, más difícil puede ser entender dónde se definen y se vuelven a
definir determinados métodos y campos.
Acoplamiento de clases: por medio de parámetros, variables locales, tipos
de valores devueltos, llamadas a métodos, instancias genéricas o plantillas
mide el acoplamiento de clases únicas. Un buen diseño de software indica
que los tipos y métodos deberán tener alta cohesión y bajo acoplamiento. Al
tener un acoplamiento alto sugiere un diseño difícil de reutilizar y mantener
al tener interdependencia entre otros tipos.
Líneas de código: muestra el número aproximado de líneas de código. Se
basa en el recuento de líneas de código IL y por ende no representa
exactamente el número de líneas que contiene el archivo del código fuente.
Un número alto en el recuento se puede interpretar que el método hace o
intenta hacer demasiado trabajo y se sugiere dividir, además también
puede indicar que el tipo o método podría ser difícil de mantener [21].
29
6.8.2. MÉTODOS ANÓNIMOS
Se define como métodos que no tienen ningún nombre. Se utilizan con más
frecuencia para pasar un bloque de código como parámetro delegado. “Los
resultados de las métricas para un método anónimo declarado en un miembro, ya
sea como método o como descriptor de acceso, se asocian al miembro que
declara el método. No se asocian con el miembro que llama al método” [21].
6.9. IIS DE WINDOWS SERVER
IIS (Internet Information Server) es un conjunto de servicios para servidores
usando Microsoft Windows. Se usa especialmente en servidores web. Es una
plataforma unificada que integra IIS, ASP.NET, Windows Communication
Foundation y Windows SharePoint Services. Permite compartir información en
internet, una intranet o en una extranet [22].
6.9.1. DESCRIPCIÓN DEL ROL
El rol Servidor Web (IIS) en Windows Server 2012 proporciona una plataforma
segura, fácil de administrar, modular y extensible donde hospedar sitios web,
servicios y aplicaciones de manera confiable. “Con IIS 8, puede compartir
información con usuarios en Internet, en una intranet o en una extranet.IIS 8 es
una plataforma web unificada que integra IIS, ASP.NET, servicios de FTP, PHP y
Windows Communication Foundation (WCF)” [22].
Windows proporciona algunas ventajas al usar IIS 8, fueron extraídas de su página
oficial:
La seguridad web se refuerza gracias a una superficie reducida de servidor
y al aislamiento automático de aplicaciones.
Podrá implementar y ejecutar aplicaciones web de ASP.NET, ASP clásico y
PHP en el mismo servidor de forma sencilla.
Se logra el aislamiento de aplicaciones al proporcionar a los procesos de
trabajo una identidad única y una configuración en espacio aislado de
manera predeterminada, lo que reduce aún más los riesgos de seguridad.
Podrá agregar y eliminar componentes IIS integrados e incluso
reemplazarlos fácilmente por módulos personalizados que se adapten a las
necesidades del cliente.
Aumenta la velocidad del sitio web mediante el almacenamiento en caché
dinámico integrado y la compresión mejorada.
30
6.9.2. APLICACIONES PRÁCTICAS
El rol de Servidor Web se puede usar para instalar y administrar varios sitios web,
aplicaciones web o sitios FTP. Algunas características se mencionan a
continuación:
Use el Administrador de IIS para configurar características de IIS y
administrar sus sitios web.
Use el Protocolo de transferencia de archivos (FTP) para permitir que los
propietarios de sitios web carguen y descarguen archivos.
Use el aislamiento de sitios web para protegerse contra la interferencia de
un sitio web con otros sitios en el servidor.
Configure aplicaciones web que están escritas con varias tecnologías,
como ASP clásico, ASP.NET y PHP.
Use Windows PowerShell para automatizar la administración de la mayor
parte de las tareas de administración del servidor web.
Configure varios servidores web en una granja de servidores que puede
administrar mediante IIS.
Aproveche al máximo el hardware NUMA y obtenga un rendimiento óptimo
del servidor con NUMA habilitado.
6.10. CACTI
La información sobre éste software y cada una de las características y
aplicaciones fue extraída de su página web oficial y se citan textualmente a
continuación:
“Cacti es una interfaz completa para RRDTool (Round Robin Database Tool),
almacena toda la información necesaria para crear gráficos y llenarlos con datos
en una base de datos MySQL. La interfaz está completamente dirigida por
PHP. Además de ser capaz de mantener gráficos, fuentes de datos y archivos
Round Robin en una base de datos, Cacti maneja la recolección de
datos. También hay soporte SNMP (Simple Network Management Protocol) para
aquellos que se utilizan para crear gráficos de tráfico con MRTG (Multi Router
Traffic Grapher)” [21].
“Fuentes de datos: Para manejar la recopilación de datos, puede
alimentar las rutas a cualquier script/comando externo junto con cualquier
información que el usuario necesite "completar", cacti luego reunirá estos
datos en un cron-job y poblará una base de datos MySQL / los archivos
round robin.
31
También se pueden crear orígenes de datos, que corresponden a datos
reales en el gráfico. Por ejemplo, si un usuario quisiera graficar los tiempos
de ping a un host, podría crear una fuente de datos utilizando un script que
haga ping a un host y devuelva su valor en milisegundos. Después de
definir las opciones para RRDTool, como la forma de almacenar los datos,
podrá definir cualquier información adicional que la fuente de entrada de
datos requiera, como un host para hacer ping en este caso. Una vez que se
crea una fuente de datos, se mantiene automáticamente en intervalos de 5
minutos.
Gráficos: Una vez que se definen una o más fuentes de datos, se puede
crear un gráfico RRDTool utilizando los datos. Cacti le permite crear casi
cualquier gráfico de herramienta RRD imaginable usando todos los tipos de
gráficos y funciones de consolidación RRDTool estándar. Un área de
selección de color y una función de relleno de texto automático también
ayudan en la creación de gráficos para facilitar el proceso.
No solo puede crear gráficos basados en RRDTool en cacti, sino que hay
muchas maneras de mostrarlos. Junto con una "vista de lista" estándar y un
"modo de vista previa", que se asemeja a la interfaz RRDTool 14all, hay
una "vista de árbol", que le permite colocar gráficos en un árbol jerárquico
para fines de organización.
Administración de usuarios: Debido a las muchas funciones de cacti, una
herramienta de administración basada en el usuario está integrada para
que pueda agregar usuarios y otorgarles derechos a ciertas áreas de
cacti. Esto permitiría a alguien crear algunos usuarios que pueden cambiar
los parámetros del gráfico, mientras que otros solo pueden ver los
gráficos. Cada usuario también mantiene su propia configuración cuando se
trata de ver gráficos.
Templating: Finalmente, cacti puede escalar a una gran cantidad de
fuentes de datos y gráficos mediante el uso de plantillas. Esto permite la
creación de un único gráfico o plantilla de origen de datos que define
cualquier gráfico o fuente de datos asociada con él. Las plantillas de host le
permiten definir las capacidades de un host para que cacti pueda
sondearlas en busca de información al agregar un nuevo host” [23].
32
6.11. APACHE JMETER
Es un programa o software de código abierto, soportada en JAVA que sirve para
cargar el comportamiento funcional para una prueba en específico y poder medir
el rendimiento de una página web o un aplicativo web, actualmente ya se ha
expandido a otras funciones de prueba.
Ésta aplicación se puede usar para realizar pruebas de rendimiento a recursos
estáticos o dinámicos y aplicaciones web dinámicas. Se puede utilizar para simular
una gran carga en un servidor, grupo de servidores, red y objetos para probar su
fortaleza o analizar el rendimiento general bajo diferentes tipos de cargas.
Las características de Apache JMeter que se encuentran en la página web del
desarrollador son:
“Capacidad para cargar y probar el rendimiento de diferentes
aplicaciones/servidores/tipos de protocolos:
o Web: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, ...)
o Servicios web SOAP / REST
o FTP
o Base de datos a través de JDBC
o LDAP
o Middleware orientado a mensajes (MOM) a través de JMS
o Correo: SMTP (S), POP3 (S) e IMAP (S)
o Comandos nativos o scripts de Shell
o TCP
o Objetos de Java
IDE de prueba con todas las funciones que permite la grabación rápida de
Plan de prueba (desde navegadores o aplicaciones nativas), compilación y
depuración.
Modo de línea de comandos (modo no guiado / sin cabeza) para cargar la
prueba desde cualquier sistema operativo compatible con Java (Linux,
Windows, Mac OSX, ...)
Un informe HTML dinámico completo y listo para presentar
Fácil correlación mediante la capacidad de extraer datos de los formatos de
respuesta más populares, HTML , JSON , XML o cualquier formato de texto
Portabilidad completa y pureza 100% Java.
El marco completo de multi-threading permite el muestreo concurrente por
muchos hilos y el muestreo simultáneo de diferentes funciones por grupos
de hilos separados.
Almacenamiento en caché y fuera de línea / reproducción de resultados de
pruebas.
33
Núcleo altamente extensible:
o Los Samplers conectables permiten capacidades de prueba
ilimitadas.
o Samplers Scriptable (lenguajes compatibles con JSR223
como Groovy y BeanShell)
o Se pueden elegir varias estadísticas de carga con temporizadores
conectables.
o Los complementos de análisis y visualización de datos permiten una
gran extensibilidad y personalización.
o Las funciones se pueden usar para proporcionar una entrada
dinámica a una prueba o para proporcionar manipulación de datos.
o Integración Continua fácil a través de 3 rd bibliotecas partido de
código abierto para Maven, Graddle y Jenkins” [24].
34
7. METODOLOGÍA PROPUESTA
Para el desarrollo del aplicativo, se siguió la metodología secuencial en etapas
definidas por las necesidades teóricas y prácticas reflejadas a continuación:
Etapa I: “Levantamiento de Información”. Se identificará toda la información
relacionada al proceso.
Etapa II: “Diseño y Creación Base de Datos”. Se diseñará y se creará la
base de datos para el registro de fallas.
Etapa III: “Diseño y Creación FRONT BITACORA”. Se diseñará y se creará
el FRONT o interfaz de usuario
Etapa IV: “Pruebas y ajuste de pruebas”. Se realizarán pruebas de
funcionamiento del aplicativo y se ajustarán las fallas que puedan suceder
Etapa V: “Manual de Usuario”. Se realizará un manual de usuario para el
uso correcto del aplicativo
El diagrama de bloques dado en la figura 3, define las etapas junto con los
procesos que debe surtirse.
Figura 3. Diagrama de bloques, fuente: los autores.
35
8. DESARROLLO DEL PROYECTO
Para el desarrollo del proyecto se siguió la metodología antes mencionada,
empezando por el levantamiento de información, etapa en la cual se estudian los
casos reportados en el proyecto, realizando posteriormente un análisis de los
casos reportados por el aplicativo GLPI y por correo electrónico, para definir las
categorías que se van a manejar para el reporte de fallas.
Para el diseño y creación de la base de datos se definieron las tablas y campos de
las mismas respecto a las necesidades, se hizo el diagrama del modelo entidad
relación.
En la fase de pruebas y ajuste de pruebas se realizó el testeo a cada uno de los
distintos bloques o secciones del aplicativo, tales como Login, Reporte Incidente,
Reporte Solución, Consulta, Verificación de Estándares, arrojando distintos
resultados los cuales se documentaron y analizaron para su posterior ajuste en el
aplicativo.
9. LEVANTAMIENTO DE INFORMACIÓN
Para conocer los canales de recepción de incidentes de alto impacto y el número
de casos para cada canal, se realizó el levantamiento de información donde se
hizo una comparación entre los casos de alto impacto registrados en la
herramienta GLPI (Aplicativo principal de la empresa THOMAS MTI) por parte del
cliente interno y externo del proyecto Banco Agrario de la empresa THOMAS MTI,
contra los casos reportados por correo donde se informaban las inconsistencias
que estaban afectando a la operación.
Los resultados obtenidos se muestran en la figura 4.
Figura 4. Comparación Número de Casos GLPI vs Correo. Fuente: Autores
0
2
4
6
8
10
12
14
16
Agosto Septiembre Octubre Noviembre
No
. Cas
os
Mes
GLPI
Correo
36
Como se evidencia la cantidad de incidentes reportados mediante correo
electrónico supera los registrados en GLPI por lo tanto no es posible agrupar de
manera correcta los mismos, esto se debe a que se tiene estipulado que las
incidencias que generan mayor impacto en la operación se deben manejar vía
telefónica y por correo electrónico para darle una mayor prioridad; por lo tanto se
observa la necesidad de tener una herramienta donde se puedan reportar estos
incidentes con el fin de agruparlos y generar de ser necesario un control de
cambios.
Para la definición de categorías se tuvo en cuenta los diferentes aplicativos que se
utilizan para la realización del proceso en el proyecto, estos son:
o SIGDOC (Sistema de Gestión Documental): Aplicativo principal del proyecto
Banco Agrario, el activo principal son las imágenes de los documentos
solicitados por el Banco a los clientes.
o COBIS: Sistema de Gestión del Banco.
o Correo Electrónico.
o GLPI.
Teniendo en cuenta la infraestructura en la que está soportada la operación del
proyecto también puede presentar afectación en algún momento, se agregó la
categoría de fallas de red que se pueden presentar en las diferentes sucursales.
De acuerdo a lo anterior y a los posibles inconvenientes que se pueden presentar
en los aplicativos se decidió expandir las categorías de la forma en que se observa
en la tabla 1, descripción de categorías.
Descripción categoría Descripción Aplicativo
Lentitud SIGDOC
Corresponde o se utiliza
cuando el cliente percibe
lentitud en la visualización de
imágenes o creación de
inventarios.
SIGDOC Indisponibilidad SIGDOC
Cuando el usuario no puede
ingresar al aplicativo
Visualización de imágenes SIGDOC
Cuando puede ingresar al
aplicativo pero no puede
visualizar imágenes
generandole diferentes errores
37
Cambio de Vol.
Proceso en el cual se realiza el
cambio de almacenamiento en
el servidor de las imágenes
digitalizadas
Rollback
Categoría asociada a
despliegues por parte de la
fabrica de desarrollo que no
fueron exitosos
Lentitud COBIS
Cuando el usuario persive
lentitud en la consulta de los
clientes en el aplicativo
COBIS Indisponibilidad COBIS Cuando el usuario no puede
ingresar al aplicativo
Actualización COBIS
Cuando se realiza algún
despliegue a una versión del
aplicativo
Soporte correo electrónico Incidentes relacionados al
correo electrónico -
Fallas de red Incidente relacionado a la red -
Lentitud GLPI
Cuando el usuario persive
lentitud en la consulta de los
incidentes y solicitudes en el
aplicativo
GLPI Indisponibilidad GLPI
Cuando el usuario no puede
ingresar al aplicativo
Inconsistencia GLPI
Cuando el aplicativo genera
resultados erroneos a las
consultas generadas
Tabla 1. Descripción de Categoría. Fuente: Autores.
38
9.1. ANÁLISIS
9.1.1 IDENTIFICACIÓN Y CONTEXTUALIZACIÓN
Como se ha mencionado con anterioridad el desarrollo de un aplicativo donde se puedan registrar las incidencias de alto impacto que afectan el proceso normal del proyecto Banco Agrario de la empresa Thomas MTI, radica en la necesidad por cuantificar y poder analizar las afectaciones que son informadas principalmente mediante correo electrónico por el cliente interno y externo.
9.1.2. REQUERIMIENTOS
Teniendo como base la norma IEEE 830 (Especificación de Requisitos Software), se definieron los requerimientos funcionales y no funcionales para la elaboración del aplicativo BITACORA, de la siguiente manera:
Requerimientos funcionales: Aquellos que son necesarios para el funcionamiento del registro de incidencias de alto impacto que son reportadas mediante correo electrónico, son la base para el diseño del aplicativo adecuado de acuerdo a las necesidades del proyecto.
Requerimientos no funcionales: Hacen referencia a las especificaciones del sistema como sus propiedades, confiabilidad y seguridad. Esto define la infraestructura más adecuada de acuerdo a los recursos disponibles para el correcto funcionamiento del aplicativo.
9.1.3. REQUERIMIENTOS FUNCIONALES
9.1.3.1. Ingreso de usuario
Tabla 2. Ingreso de Usuario. Fuente: los autores.
Nombre Ingreso de usuario
Resumen Se requiere el nombre y contraseña del usuario del aplicativo SIGDOC para el ingreso al aplicativo
Entrada
Contraseña
Nombre de usuario
Resultados
El sistema valida si el usuario existe en la plataforma Manager User (Herramienta para la administración de
usuarios de SIGDOC) y cuenta con el permiso "HagaloUsedMismo" (Aplicación para soporte de Banco Agrario)
39
9.1.3.2. Registro de incidencias
Tabla 3. Registro de Incidencias. Fuente: los autores.
9.1.3.3. Registro de solución
Tabla 4. Registro de Solución. Fuente: los autores.
9.1.3.4. Consultas
Tabla 5.Consultas. Fuente: los autores.
Nombre Registro de incidencias
Resumen
Se debe registrar el incidente que se esta presentando o se presento y genero alguna afectación en
el proceso, se asigna al área responsable.
Fecha inicio
Descripción
Resultados
El usuario tiene dos opciones, la primera de guardar el incidente reportado y esperar un tiempo para registrar la
solución, o guardar el incidente y reportar la solución inmediatamente. Al guardar el incidente se debe mostrar
un mensaje con el número con el cual quedo registrado.
Categoría
Área encargada
Entrada
Nombre Registro de solución
Resumen
Se debe registrar un pequeño resumen de lo que se realizo para solucionar el incidente reportado,
y se asigna al líder del área que ejecuto la solución.
El usuario cuando reporta la solución desde la opción de registro de incidencias no debe ingresar el número de
incidente ya que este debe aparecer por defecto, al guardar la solución se debe mostrar un mensaje si fue o no
exitosa la tarea.
Entrada
Número de incidente
Fecha de solución
Persona asignada
Descripción de solución
Resultados
Nombre Consultas
Resumen
Se debe contar con la opción de consultar las incidencias reportadas y mostrar cuales tienen o no
solución.
Resultados
El usuario debe tener la opción de consultar los incidentes reportados mediantes tres opciones, por el número
de incidente, por la categoría asignada o por un rango de fechas en el que se realizo la creación de los mismos. El
sistema muestra el resultado de acuerdo a la opción seleccionada por el usuario, en caso tal de tener registros
con dicha opción se debe mostrar un mensaje.
Entrada
Nro. De incidente
Categoría
Fecha de creación
40
9.1.3.5. Exportar información
Tabla 6. Exportar Información. Fuente: los autores.
9.1.4. REQUERIMIENTOS NO FUNCIONALES
El aplicativo BITACORA debe tener una disponibilidad de 98%.
La velocidad de respuesta para los usuarios finales no debe ser mayor a 10
segundos.
Debe contar con una interfaz sencilla y fácil de entender para el usuario
final.
9.1.5. DIAGRAMAS DE CASOS DE USO
9.1.5.1. Actores
A continuación se listan los usuarios y su identificación:
Tabla 7. Actores. Fuente: los autores.
Nombre Exportar información
Resumen Se debe contrar con una opción de exportar la información resultante de las consultas realizadas.
Resultados
El sistema arroja el resultado de una consulta realizada y debe extraer la misma a un archivo .xls
Entrada
Extraer información
Código Nombre Caracterización
ACT-001 Usuario
Cualquier usuario de la aplicación, es en general cualquier
integrante de la organización en la que se implemente el
sistema. Este usuario puede pertenecer a cualquiera de los
"roles" que se presentan a continuación.
ACT-002 AdministradorEste usuario es el encargado de gestionar los usuarios y
permisos dentro del sistema.
ACT-003 Usuario final
Este usuario se encarga de realizar el registro de los
incidentes y la solución de los mismos, adicional puede
generar reportes de los incidentes.
ACTS-001 Sistema Este hace referencia al sistema del proyecto Banco Agrario.
Representación gráfica
41
9.1.5.2. CUS-01 Ingreso de usuario al sistema
Tabla 8. Ingreso Usuario Al Sistema. Fuente: los autores.
9.1.5.3. CUS-02 Registro de incidencias
Tabla 9. Registro de Incidencias. Fuente: los autores.
CUS-01
Descripción
Precondición
Paso Acción
1
El Usuario (ACT-001) abre la dirección web designada para el funcionamiento de la
aplicación.
2
El Sistema (ACTS-001) presenta el formulario de ingreso, solicitando usuario y
contraseña.
3 El Usuario (ACT-001) digita sus datos personales.
4 El Sistema verifica la información digitada.
5
En caso que el Sistema compruebe que la información es correcta presentará al
usuario la interfaz correspondiente a los permisos asignados.
Pos condición
Secuencia
Este caso de uso permitirá el inicio de una sesión de un Usuario (ACT-001) dentro del sistema.El Usuario (ACT-001) debe haber sido creado por un Administrador (ACT-002) y debe habérsele
asignado los permisos correspondientes.
Representación gráfica
Ingreso de usuario al sistema
El usuario se ha identificado correctamente en el sistema y su sesión está abierta.
CUS-02
Descripción
Precondición
Paso Acción
1
El Sistema (ACTS-001) presenta el formulario principal, el usuario final (ACT-003) selecciona la pestaña
de registrar incidente.
2 El usuario (ACT-003) ingresa la información correspondiente para el registro del incidente.
3 El sistema (ACTS-001) genera un número de incidente.
Pos condición
Registro de incidencias
Este caso de uso permitirá que un usuario (ACT-003) crear un incidente, del cuál registrara la solución
El usuario (ACT-003) debe seleccionar una categoría, la fecha y hora en que sucedió o esta sucediendo el
inconveniente, asigna el área responsable y escribe una pequeña descripción, para que el sistema guarde el
Secuencia
Representación
gráfica
El usuario final ha reportado correctamente en el sistema su incidente, generando el sistema el número
42
9.1.5.4. CUS-03 Registro de solución
Tabla 10. Registro de Solución. Fuente: los autores.
9.1.5.5. CUS-04 Consultas
Tabla 11. Consultas. Fuente: los autores.
CUS-03
Descripción
Precondición
Paso Acción
1
El Sistema (ACTS-001) presenta el formulario principal, el usuario final (ACT-003) selecciona la
pestaña de registrar solución.
2 El usuario (ACT-003) ingresa el número del incidente.
3 El sistema (ACTS-001) muestra la información del incidente.
4 El usuario (ACT-003) ingresa los datos necesarios para registrar la solución correspondiente.
5 El sistema (ACTS-001) guarda la información y genera un mensaje de tarea finalizada.
Pos condición
Representación
gráfica
Registro de solución
En este caso de uso el usuario (ACT-003) una vez tenga la solución del incidente va a registrarla.
El usuario (ACT-003) va a ingresar en el registro de solución y digitara el número del incidente que no
tiene solución, debe escoger la fecha de solución, el líder del área encargada y una descripción de la
solución.
Secuencia
El usuario final a diligenciado la solución con éxito, el sistema almacena la información
correspondiente.
CUS-04
Descripción
Precondición
Paso Acción
1
El Sistema (ACTS-001) presenta el formulario principal, el usuario final (ACT-
003) selecciona la opción de consulta.
2 El sistema (ACTS-001) muestra las opciones de consulta.
3 El usuario (ACT-003) selecciona la opción de consulta.
4
El sistema (ACTS-001) muestra la información del incidente y la solución en
caso de tenerla.
Pos condición
Representación
gráfica
Consultas
En este caso de uso el usuario (ACT-003) va a consultar uno o varios incidentes, de
acuerdo a la opción seleccionada.
El usuario (ACT-003) va a ingresar en el modulo de consulta donde se visualizara tres
opciones de consulta, por número de incidente, categoría o un rango de fecha
cuando se reporto la incidencia.
Secuencia
El usuario final selecciona una opción de consulta, en caso tal que no se cuente con
información el sistema arrojara un mensaje informando esto, en caso contrario el
sistema mostrara la información de la consulta.
43
9.1.5.6. CUS-05 Exportar información
Tabla 12. Exportar Información. Fuente: los autores.
9.1.6. DIAGRAMA DE FLUJO
En la siguiente figura (Figura 5) se muestra el diagrama de flujo del aplicativo
BITACORA para cada proceso.
CUS-05
Descripción
Precondición
Paso Acción
1
El Sistema (ACTS-001) presenta el formulario principal, el usuario final (ACT-
003) selecciona la opción de consulta.
2 El sistema (ACTS-001) muestra las opciones de consulta.
3 El usuario (ACT-003) selecciona la opción de consulta.
4
El sistema (ACTS-001) muestra la información del incidente y la solución en
caso de tenerla.
5 El usuario (ACT-003) selecciona la opción de exportar información.
6 El sistema (ACTS-001) extrae la información en una archivo .xls
Pos condición
Representación
gráfica
Exportar información
En este caso de uso el usuario (ACT-003) puede exportar la información generada en
las consultas.
El sistema (ACTS-001) muestra la información de la consulta realizada por el usuario
(ACT-003).
Secuencia
El usuario final extrae la información que el sistema arroja de la consulta realizada.
44
Figura 5. Diagrama de flujo aplicativo BITACORA. Fuente: Los autores.
45
10. DISEÑO
Para la etapa de diseño, se empezó con la base de datos realizando el modelo
entidad relación y posteriormente se realizó el diseño e implementación del
FRONT del aplicativo.
10.1. DISEÑO DE BASE DE DATOS
Para el diseño se definieron las tablas y los campos de las mismas de acuerdo a
las necesidades planteadas para el registro de las incidencias y la solución de
estas, posteriormente se realizó el modelo entidad-relación que se muestra a
continuación.
Figura 6. Modelo Entidad Relación. Fuente: Los autores.
En el modelo entidad-relación, se analiza el esquema de diferentes entidades o
tablas, y su correlación entre ellas, a continuación se explica la relación existente:
• Relación BIT_Incon – BIT_Categorías: La relación entre las categorías y los
incidentes es de una a muchas, ya que una categoría puede tener diferentes
incidentes, pero un incidente solo puede tener una categoría.
• Relación BIT_Incon – BIT_Area: La relación entre las áreas y los
inconvenientes es de una a muchas, ya que un incidente solamente puede tener
un área asignada pero un área puede tener diferentes inconvenientes.
46
• Relación BIT_Incon – BIT_Solucion: La relación entre los inconvenientes y
la solución es de una a una, ya que un inconveniente solamente puede tener una
solución.
• Relación BIT_Solucion – BIT_Responsable: La relación entre los
responsables y las soluciones es de una a muchas, ya que un responsable puede
tener diferentes soluciones asignadas, pero una solución solo puede tener un
responsable.
• Relación BIT_Responsable – BIT_Area: La relación entre responsables y
áreas es de una a una, ya que un responsable solamente puede tener un área
asignada.
Para la selección del motor de base de datos se tuvo en cuenta los recursos con
los que disponía el proyecto y de acuerdo a la cantidad y la sensibilidad de los
datos que se iban a manejar en el aplicativo se escogió Microsoft SQL Server
2012, adicionalmente se seleccionó este motor debido a que la autenticación del
aplicativo se realiza con los usuarios de SIGDOC y este aplicativo también se
soporta sobre ese mismo motor; agregando solamente un permiso adicional para
garantizar mayor seguridad.
Se dispuso de un servidor para la base de datos con las siguientes características
técnicas:
o Espacio de almacenamiento disco fuente: 40GB.
o RAM: 10GB.
o Procesador de 8 núcleos.
o Sistema Operativo: Windows server 2012.
Teniendo en cuenta la cantidad de datos y usuarios (aproximadamente 20) que
tiene el aplicativo de registro de incidentes, agregando a esto una mayor
disponibilidad del mismo.
47
10.2. INTERFAZ (FRONT)
Para la diseño del FRONT se buscó una interfaz amigable, sencilla y fácil de
entender para el usuario final, se desarrolló bajo el software Visual Studio debido a
que se contaba con esta licencia en la empresa y por su facilidad y versatilidad de
manejo.
10.2.1. PANTALLA INGRESO USUARIO
En esta interfaz se muestra la página de ingreso, donde el usuario debe digitar su
usuario y contraseña.
Figura 7. Ingreso Usuario. Fuente: Los autores.
10.2.2. PANTALLA PRINCIPAL USUARIO FINAL
Una vez ingresado el usuario y contraseña, podrá visualizar el menú principal
donde podrá Consultar, Reportar la inconsistencia o Reportar la Solución
correspondiente:
48
Figura 8. Pantalla Principal Usuario Final. Fuente: Los autores.
10.2.3. REPORTAR INCIDENTE
El formulario que el usuario debe diligenciar para reportar la inconsistencia se
muestra a continuación
Figura 9. Reportar Incidente. Fuente: Los autores.
49
10.2.4. GUARDAR Y REPORTAR SOLUCIÓN
El aplicativo BITACORA cuenta con la opción de guardar la inconsistencia
y reportar la solución correspondiente, desde la página de Reportar
inconsistencia:
Figura 10. Guardar y Reportar Solución. Fuente: Los autores.
10.2.5. REPORTAR SOLUCIÓN
Figura 11. Reportar Solución. Fuente: Los autores.
50
Para diligenciar la solución, el usuario debe ingresar el número del incidente en el
formulario anterior, y completar los campos solicitados.
10.2.6. CONSULTAS
Figura 12. Consultas. Fuente: Los autores.
Como se puede visualizar se cuenta con las siguientes opciones, para realizar una
consultar:
Consultar por número de la novedad reportada.
Consultar por categoría.
Consultar por fecha de creación.
Consultar por fecha de creación y por categoría.
10.2.7. EXTRACCIÓN DE INFORMACIÓN
Una vez realizada la consulta, la información se vera de la siguiente manera:
Figura 13. Extracción de Información. Fuente: Los autores.
51
En esta página se cuenta con la opción de extraer la información, solamente se
debe dar click en el botón “EXTRAER INFORMACIÓN”, automáticamente se
descargara un archivo con el nombre Export con extensión XLS.
Figura 14. Archivo XLS. Fuente: Los autores.
10.3. PRUEBAS Y AJUSTE DE PRUEBAS
Durante la fase de desarrollo del aplicativo BITACORA, se realizaron diferentes
pruebas funcionales, inicialmente unas por secciones del aplicativo para analizar
el correcto funcionamiento del mismo, obteniendo los siguientes resultados:
Login: En la página inicial donde se ingresa el Login de cada usuario se
identificó una vulnerabilidad de seguridad en el campo donde se ingresa la
contraseña, ya que el navegador estaba almacenando el caché de la
aplicación por lo tanto al ver en otro label de las páginas del aplicativo era
posible visualizar la contraseña, la manera en que se identificó esta
vulnerabilidad fue en los resultados obtenidos después de testear la
aplicación con el software Nessus Scan; la manera en que se ajustó esta
inconsistencia, fue en el manejo correcto del caché de la aplicación, desde
el desarrollo se quitó la opción del almacenamiento automático de la
información ingresada.
Reporte incidente: En la página donde se registra el incidente, no se
estaba cumpliendo la condicional de que la totalidad de los campos deben
estar diligenciados, por lo tanto los incidentes reportados estaban quedando
de manera incompleta en la base de datos, se identificó que esto se debía a
una inconsistencia en la clase de datos donde se estaba insertando la
información en la base de datos, se realizó el ajuste en query y quedo
funcionando correctamente.
52
Reporte solución: La opción de guardar la solución desde el botón
“Guardar y continuar” no estaba funcionando correctamente, al validar este
problema se identificó un error en la programación de la información que
estaba arrojando al momento de consultar el número de incidente, adicional
la clase que se estaba utilizando no se estaba conectando correctamente a
la base de datos, esto se solucionó mediante la validación del web config ya
que el usuario que se estaba utilizando no tenía los permisos suficientes
para realizar la operación solicitada.
Consulta: Al realizar la prueba funcional en esta página se presentaron
diferentes problemas relacionados a la consulta por la opción fecha y
categoría, ya que no estaba arrojando ningún resultado al momento de
utilizar estas opciones, adicional no se contaba con ninguna notificación al
momento de consultar por alguna categoría que no contara con incidentes
reportados. Los incidentes reportados no estaban quedando de manera
secuencial, para esto se eliminó por completo la tabla Bit_Incon y se creó
nuevamente modificando los campos de las llaves foráneas y se truncó la
tabla para eliminar por completo los valores existentes, al momento de
realizar esta acción los incidentes reportados ya quedaban correctamente
registrados.
Los principales problemas que se presentaron en la fase de desarrollo fueron
relacionados en la creación de los querys para realizar las consultas y para
insertar la información, adicional de un problema asociado al usuario que se tenía
para la conexión a la base de datos, por lo que se realizó la creación de otro
usuario con mayores privilegios en el manejo de datos, adicional se hizo el ajuste
correspondiente en los querys que se habían creado teniendo en cuenta las
buenas prácticas de desarrollo.
Verificación de Estándares: aunque los sitios web pueden ser construidos
a partir de diferentes lenguajes, todos deben cumplir ciertas normas de
organización de su código fuente (sintaxis), que permitan su visualización
por software equivalente en diferentes plataformas, para este aplicativo se
tuvo en cuenta la validación de CSS, lo que indico que la Hoja de Cascada
de Estilo (Cascade Style Sheet) cumple con la sintaxis estándar y por lo
tanto podrá ser visualizada correctamente en todos los sistemas.
53
10.4. SEGURIDAD EN EL APLICATIVO BITÁCORA
Para restringir el acceso de los usuarios al aplicativo BITACORA y garantizar una
mayor seguridad los parámetros de ingreso son los mismos (Usuario y
contraseña) a los utilizados para SIGDOC, adicional se tiene un permiso adicional
para dicho ingreso.
El método de encriptación para la contraseña de los usuarios que se utilizo fue la
clase SHA512 de Visual Studio. Se restringió el almacenamiento del usuario y
contraseña en la página principal de la autenticación, adicional se dejaron
mensajes de advertencia genéricos para mitigar que se pueda forzar el acceso a
la página. La conexión a la base de datos se realizó mediante web.config para
evitar dejar en las páginas de diseño las credenciales de la misma.
Los permisos para el acceso al aplicativo BITACORA se dejaron solamente al
segmento del área de tecnología del proyecto Banco Agrario, para evitar que otros
usuarios intenten ingresar al sitio web.
11. CALIDAD DE SERVICIO
Con base en algunos criterios establecidos en la norma ISO 25000 (Sistemas y
requisitos de calidad del software y evaluación (SQuaRE)) [25] [26]; se
establecieron los siguientes requisitos de evaluación para la calidad de servicio del
aplicativo web BITACORA:
11.1. USABILIDAD
11.1.1. TIEMPOS DE RESPUESTA
Con base a las conclusiones del estudio presentado en 1968 por Robert Miller que
aún siguen siendo válidas, los tiempos recomendados son los siguientes:
“Una décima de segundo (0.1 s) es el tiempo normal de respuesta para que
el usuario sienta que el sistema está reaccionando instantáneamente.
Un segundo (1 s) es el tiempo límite para que el usuario se dé cuenta de
que hay una demora y que la misma no es una interrupción”.
Mostrar una página en menos de un segundo le da al usuario la sensación
de que está accediendo a la información sin demoras.
Diez segundos (10 s) es el tiempo máximo que un usuario puede
permanecer atento a una tarea. Si el tiempo de respuesta es mayor, los
usuarios tienden a ocupar su tiempo en otras cosas por lo que ya no están
atentos a lo que la computadora está haciendo” [27].
54
A partir de esto se realizaron las mediciones de los tiempos de respuesta que
tiene el sitio web BITACORA al momento de mostrar la página de autenticación,
adicional se muestran los tiempos para cada interacción realizada para el ingreso
a la página inicial:
Figura 15.Página de autenticación (resultados JMeter). Fuente: Los autores.
A partir de los resultados obtenidos se evidencia un tiempo de carga a la página
de autenticación de la BITACORA (Figura 15) de 42ms con una latencia de 24ms,
de acuerdo a esto no se supera el tiempo establecido para que el usuario final
perciba lentitud, demostrando que la comunicación con el servidor es óptima y la
navegabilidad del sitio web está dentro de los parámetros establecidos en los
requerimientos no funcionales.
Figura 16. Autenticación Usuario (resultados JMeter). Fuente: Los autores.
55
En la figura 16 se muestran los resultados del JMeter al momento de la
autenticación del usuario, por lo tanto los tiempos son superiores en cuanto a la
respuesta del servidor, a pesar de que el tiempo de carga aumenta hasta 74ms no
es un tiempo considerable para que el usuario final perciba algún tipo de lentitud.
Figura 17. Página principal (resultados JMeter). Fuente: Los autores.
Como se evidencia en la figura 17 el tiempo de respuesta para que el aplicativo
BITACORA muestre la página principal es de 21ms, con una latencia de 9ms, lo
que indica que la demora es mínima para que cargue esta página.
Figura 18.Cerrar sesión (resultados JMeter). Fuente: Los autores.
56
Figura 19. Página de autenticación (resultados JMeter). Fuente: Los autores.
En la figura 18 y en la figura 19, se visualizan los tiempos de respuesta al
momento de cerrar sesión, teniendo un tiempo máximo de 26ms para mostrar
nuevamente la página de autenticación.
11.2. FIABILIDAD
En este ítem se evaluaron los parámetros de disponibilidad y de tolerancia a fallos,
a continuación se muestra de manera detallada cada uno de estos:
11.2.1. DISPONIBILIDAD
Para el cumplimiento de este parámetro se realizó el monitoreo del
comportamiento de la aplicación durante una semana (por disposición de recursos
de la empresa), el aplicativo que se utilizó para este monitoreo fue el Cacti, en
este caso se analizaron los siguientes ítems:
57
11.2.1.1. Uso de la memoria
Figura 20. Uso de Memoria. Fuente: Los autores.
Como se muestra en la gráfica la memoria no se ve comprometida con el uso de la
aplicación, en el pico que se visualiza del martes 03-04-2018 se debe a un
proceso de actualización que se ejecutó para otras funciones compartidas con la
aplicación BITACORA (Actualización de COBIS) que tiene el servidor.
Teniendo en cuenta que en este servidor no se encuentra la base de datos es
coherente que no se presente una afectación en la memoria. Con el servidor
funcionando de manera correcta el monitoreo muestra un uso de memoria de 5.2
GB con una disponibilidad del 49% y un promedio de uso del 39% garantizando
así el funcionamiento correcto del servicio web; el porcentaje restante los destina a
procesos reservados del mismo. El espacio que se tiene desde el día 20 de marzo
al 23 de marzo se debe a que en ese momento no se contaba con el monitoreo del
servidor.
58
11.2.1.2. Trafico
Figura 21. Tráfico. Fuente: Los autores.
En este caso se evidencia un espacio sin monitoreo desde el día 20 de marzo al
23 de marzo, debido a que en este lapso de tiempo no se contaba con este, en la
gráfica se observan distintos valores atípicos o picos en la señal por ejemplo en el
tráfico entrante el día martes de la semana de pruebas se obtiene un valor máximo
de 100.1Kbits por segundo teniendo en cuenta que ese día se realizaron pruebas
de carga con varios usuarios del aplicativo con el fin de cuantificar el tráfico de la
plataforma.
Para el tráfico de salida se realizaron pruebas volumétricas el día martes
03/04/2018 para poder verificar la plataforma y confirmar si es posible que el
aplicativo pueda soportar una alta contingencia, el valor atípico para ese día se
encuentra en 110.3Kbps, observando que la plataforma responde acorde a las
necesidades de la empresa y resaltando que la probabilidad de que en la puesta
en marcha el aplicativo llegue a dicho tráfico es baja, debido a que las personas
encargadas del registro no son demasiadas.
59
11.2.1.3. Uso del disco C
Figura 22. Uso Disco C. Fuente: Los autores.
El fin de la prueba consiste en monitorear la unidad de almacenamiento para
verificar el uso y las posibles falla que pueda tener, en la gráfica se observa que el
porcentaje de inactividad de la unidad alcanza un promedio del 91.8% lo que
indica que la plataforma no se utilizó constantemente o no se registraron muchas
fallas en el tiempo de prueba, el porcentaje promedio de tiempo de escritura y
lectura se encuentra en 0.1% evidenciando el poco uso de la plataforma.
11.2.2. TOLERANCIA A FALLOS
En este caso se realizaron pruebas de estrés de la aplicación, por lo tanto se
dispuso del aplicativo JMeter, en el cual se crearon 1000 hilos de Login para
validar el acceso a la BITACORA (Figura 23), para así verificar el comportamiento
del servidor con pruebas de volumetría. Para ver en tiempo real el comportamiento
del servidor donde se soporta el sitio web se utilizó la aplicación ProcessExplorer
ya que esta proporciona la funcionalidad del Administrador de tareas de Windows
junto con un amplio conjunto de características para recopilar información sobre
los procesos que se ejecutan en el sistema del usuario. Los resultados se
muestran a continuación:
60
Figura 23. Asignación de 1000 hilos JMeter. Fuente: Los autores.
En la figura 24, se muestra el resumen de los resultados obtenidos con las
pruebas de volumetría, en el ítem # Muestras hace referencia a la cantidad de
iteraciones que se realizó en cada página, como se evidencia todas las
conexiones se realizaron de manera exitosa,
Figura 24. Reporte resumen (Resultado JMeter). Fuente: Los autores.
Las conexiones establecidas para la autenticación del usuario en el servidor se
muestran en la figura 25, las que se encuentran en rojo corresponden a
conexiones cerradas, las que se encuentran en verde hacen referencia a las
conexiones establecidas correctamente y las que no tienen ningún color son
61
conexiones pendientes; una vez realizada la correcta autenticación del usuario por
seguridad se cierran las conexiones, adicional esto se usa para liberar recursos
en el servidor. En la figura 25, solo hay una muestra de las 1000 conexiones
establecidas con las pruebas de estrés.
Figura 25. Conexiones establecidas en el servidor (Resultados ProcessExplorer). Fuente: Los autores.
A continuación se muestran las gráficas del comportamiento del servidor, frente a
las pruebas de estrés.
Figura 26. Información del sistema (Resultados ProcessExplorer). Fuente: Los autores.
Como se evidencia en la figura 27, la CPU es la que se ve más comprometida en
las pruebas de estrés, los picos de la gráfica de entradas contra salidas
corresponden a respuesta de escritorio remoto ya que para acceder al servidor se
realiza mediante RDP (Protocolo de Escritorio Remoto). Por lo tanto en la figura 27
se ve de manera detalla el comportamiento de la CPU en las pruebas de
volumetría.
62
Figura 27. Comportamiento de la CPU (Resultados ProcessExplorer). Fuente: Los autores.
De acuerdo a los resultados obtenidos se evidencia que el servidor responde de
manera adecuada para soportar una carga mayor de usuarios, sin comprometer
sus recursos, ya que el pico máximo de uso de CPU con estas pruebas fue de
36.88%. Las pruebas de estrés se realizaron solamente con un grupo de mil
(1000) hilos teniendo en cuenta la capacidad de JMeter.
NOTA: Para el desarrollo del proyecto y mediciones de QoS se presentaron
ciertas limitaciones como la negativa de la empresa para usar software libre
además de los permisos necesarios para la realización de ciertas pruebas como
pruebas de volumetría para la medición de pérdida de paquetes con el fin de no
afectar los procesos normales que se encuentran en el ambiente de producción.
63
11.3. SEGURIDAD
11.3.1. ANÁLISIS DE VULNERABILIDADES
La empresa THOMAS MTI cuenta con políticas de seguridad de la información
muy rigurosas, por lo tanto para los datos suministrados por el personal se debe
garantizar la integridad, disponibilidad y confidencialidad de los mismos.
Por ejemplo el acceso a las instalaciones es restringido, por ende para acceder a
los servidores y computadores de la empresa es bastante difícil, lo que permite
que personas ajenas a la empresa no tengan acceso a la información ni realizar
un posible ataque a los servidores.
Para restringir el acceso de los usuarios al aplicativo BITACORA se re utilizo un
recurso ya existente pero que actualmente no se encontraba en uso, cuya
funcionalidad consistía en permitir el ingreso a un recurso temporal de SIGDOC
(Aplicativo de Gestión Documental). Este recurso se denomina
“HagaloUsedMismo”; dicho permiso solamente se les asignará a los usuarios ya
creados para el ingreso a SIGDOC y que puedan ingresar a la BITACORA. Los
parámetros de ingreso serán los mismos (Usuario y contraseña) a los utilizados
para SIGDOC.
Se dispuso por parte del proyecto Banco Agrario la utilización de un servidor para
soportar el sitio web del aplicativo BITACORA con las siguientes características
técnicas:
o Espacio de almacenamiento disco fuente: 10GB.
o RAM: 4GB.
o Procesador de 10 núcleos.
o Sistema Operativo: Windows server 2012.
Se utilizó el Rol del IIS (Internet Information Services) para alojar el servicio web.
La conexión con la Base de datos de SIGDOC (Para la autenticación de los
usuarios) y la Base de datos de la BITACORA (Donde se almacena toda la
información registrada en el aplicativo), se realizó mediante Web.Config.
Para garantizar la seguridad del servidor donde se soporta el sitio web del
aplicativo se realizó un escaneo de vulnerabilidades con el software Nessus Scan,
evidenciando los siguientes resultados (figura 28).
64
Analizando los resultados obtenidos, se identificó que el servidor no cuenta con
vulnerabilidades críticas ni altas, las cuales por definición pueden comprometer de
manera seria los recursos y funcionamiento del equipo.
Por otra parte se encontró cinco (5) vulnerabilidades de nivel medio relacionadas
a inconvenientes que se tienen con el certificado SSL, estas se encuentran en
proceso de corrección por parte del grupo encargado de la administración de
plataformas de la empresa Thomas MTI. Este proyecto no profundizara en la
mitigación y resolución de las vulnerabilidades descubiertas, ya que no
corresponde al alcance del mismo.
Los 33 mensajes informativos corresponden a características de seguridad
establecidas en Nessus que se presentan como recomendaciones para evitar
riesgos de vulnerabilidades en el servidor.
65
66
Figura 28. Escaneo Vulnerabilidades del Servidor. Fuente: Nessus Scan.
11.3.2. MODELO DE AMENAZAS
El modelado de amenazas es un procedimiento para optimizar la seguridad de la
red/aplicaciones/Internet mediante la identificación de objetivos y vulnerabilidades,
y luego definir las contramedidas para prevenir o mitigar los efectos de las
amenazas al sistema.
Para el modelo de amenazas del aplicativo BITACORA, se utilizó el modelo
propuesto por OWASP (Open Web Application Security Project, ‘Proyecto abierto
de seguridad de aplicaciones web’) este último es un proyecto de código abierto
dedicado a determinar y combatir las causas que hacen que el software sea
inseguro.
En los numerales del 1 al 5 se realizó la descomposición de la aplicación,
identificando las entidades externas, los puntos de entrada que puede tener la
misma y los activos, de esta manera se definieron los niveles de confianza (Nota:
los niveles de confianza se dejaron en el ítem 3, para mejor comprensión de los
numerales 4-7), en los ítems 6 y 7 se definieron las amenazas y las sugerencias
para mitigar las mismas.
67
11.3.2.1. PORTADA
Tabla 13. Portada. Fuente: Los autores.
11.3.2.2. DEPENDENCIAS EXTERNAS
Tabla 14. Dependencias Externas. Fuente: Los autores.
11.3.2.3. NIVELES DE CONFIANZA
Tabla 15. Niveles de Confianza. Fuente: Los autores.
Versión Aplicación V1
Autor: Wilson Vargas, Daniel Salamanca
Participantes: Wilson Vargas - Daniel Salamanca
Revisor: Andres Reyes - Administrador de Plataformas
Modelo de Amenazas
Descripción:
BITACORA es una aplicación web, que permite realizar el registro de incidentes de alto
impacto que afectan el proceso normal del proyecto Banco Agrario de la empresa
THOMAS MTI.
ID Descripción
1 Base de datos SQLServer 2012
2 Usuarios MTI
3 S.O. Windows server 2012
4 Internet Information Service
5 Firewall
6 Manager User
External Dependencies
ID Nombre Descripción
1 Usuarios Manager User
Todo usuario existente activo en Manager User con el permiso
"HagaloUsedMismo" tiene acceso a la Bitácora con un usuario y
contraseña.
2 Directorio activo MTIUsuarios que se encuentran registrados en el directorio activo de
MTI en el grupo de infraestructura tiene acceso a la Base de datos
3 Usuarios anónimos Usuario que puede tener acceso a la página de login
Niveles de Confianza
68
11.3.2.4. PUNTOS DE ENTRADA
Tabla 16. Puntos de Entrada. Fuente: Los autores.
11.3.2.5. ACTIVOS
Tabla 17. Activos. Fuente: Los autores.
11.3.2.6. STRIDE
Para la identificación de las amenazas críticas se utilizó el método STRIDE
(Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service,
Elevation of Privilege por sus siglas en inglés), donde se definieron cuáles son los
posibles puntos de entrada que puede tener un atacante de acuerdo a cada
amenaza, de esta manera definir los activos que se ven expuestos.
ID Nombre Descripción Niveles de Confianza
1
1
1
1
1
2
3
2
5 Protocolo HTTP
6 Motor Base de datos SQL Server 2012
3 Usuario final Consultas
4 Usuario final Extracción de información
Puntos de Entrada
1 Usuario final Reporte inconsistencias
2 Usuario final Reporte solución
ID Nombre DescripciónNiveles de
Confianza
1
2
1
2
1
2
2
4 Código aplicación Código compilado
1 Incidentes Poseen la información de los incidentes reportados.
2 Reportes Información de los incidentes y soluciones reportados.
Activos
3 Datos usuarios Información básica de usuarios que ingresan en la aplicación
69
Tabla 18. STRIDE. Fuente: Los autores.
11.3.2.7. DREAD
En el modelo DREAD (Damage, Reproducibility, Exploitability, Affected users,
Discoverability por sus siglas en inglés), es un esquema de calificación para
cuantificar, comparar y dar prioridad a la cantidad de riesgo que presenta una
amenaza específica, las cuales se definieron con el método STRIDE.
Para la sugerencia de contramedidas y mitigaciones se tomó como referencia los
requisitos y sugerencias que se realizan en la norma de seguridad de datos de
PCI (Payment Card Industry), ya que esta se desarrolló para fomentar y mejorar la
seguridad de los datos de los usuarios, esta facilita la adopción de medidas de
seguridad uniformes, adicional el Proyecto Banco Agrario se encuentra en el
proceso de certificación de dicha norma, por lo tanto la mayoría de
recomendaciones ya se encuentran implementadas en el proceso o en proceso de
implementación.
Tabla modelo DREAD. Anexo 2.
12. ANÁLISIS DE TRÁFICO
Para el aplicativo se tiene un servidor de 40 GB de capacidad, cuenta con un
canal dedicado de 50MBps.
Para el cálculo de N (Elementos de red con capacidad infinita), se tiene que el
máximo peso de un archivo a guardar que para este caso al ser un archivo plano
de Excel se estima un peso aproximado de 12 MB.
N =50MBps
12MB
N = 4.1666666667
Aproximando al siguiente entero se obtiene:
N = 5
Amenazas Puntos de entrada Activos
Robo de identidad 1 al 6 1,2,3,4
Manipulación de datos 5 y 6 1,3,4
Repudiación 5 y 6 1
Divulgación de información 1 al 6 1,2,3,4
Negación de servicio 5 y 6 3,4
Elevación de privilegios 5 y 6 3,4
70
El sistema fue diseñado para tener una probabilidad de bloqueo de 10% debido a
que la cantidad de usuarios reales con que cuenta la plataforma no es
significativamente mayor, se procede a calcular el tráfico con N=5 y se obtiene:
ATot = 2.319999 [Erlangs]
Con el tráfico total del sistema y el tráfico por usuario que es aproximadamente
0.005 Erlangs (Auss) se obtiene el número total de usuarios asumiendo que todos
los archivos tienen un tamaño de 12 MB.
#Uss =ATot
AUss
#Uss =2.319999
0.005
#Uss = 463.9998
Por ende la cantidad máxima de usuarios es 463.
Para calcular el total de archivos que puede almacenar el servidor se procede a
dividir la capacidad total del servidor con el tamaño máximo por archivo de 12 MB,
obteniendo así:
#Archivos =40GB
12MB
#Archivos = 3333.33333333
En este caso se debe aproximar por debajo porque solo es posible almacenar
archivos incompletos obteniendo una capacidad máxima de 3333 archivos
guardados.
71
13. ANÁLISIS MÉTRICAS DE CÓDIGO
13.1. ÍNDICE DE MANTENIMIENTO
El índice de mantenimiento indica la facilidad relativa de mantenimiento de un
código obteniendo un valor que varía entre 0 y 100, Microsoft define que un índice
de mantenimiento adecuado debe estar por encima de 20 puntos. Para el análisis
de dicho parámetro se organizaron los datos de forma ascendente y para luego
calcular las medidas de tendencia central de los datos obtenidos, los datos
originales se pueden observar en el anexo 4.
En las tablas 19, 20 y 21 se pueden observar los resultados del análisis por medio
de la tabla, histograma y polígono de distribución de frecuencias para poder
observar mejor los datos.
Promedio 80.89261745
Mediana 95
Cuartil 0 31
Cuartil 1 61
Cuartil 2 95
Cuartil 3 98
Cuartil 4 100 Tabla 19. Cálculo de medidas de tendencia central. Fuente: Los autores.
# de Datos 149
Valor Máx 100
Valor Min 31
Rango 69
# de Intervalos 8
Amplitud de clase
9
diferencia 1
Tabla 20. Cálculo de Parámetros de Tabla de Distribución de Frecuencias. Fuente: Los autores.
72
Intervalo de clase
Marca de clase
fi Fi hi[%] Hi[%]
30 40 35 3 3 2.013422819 2.013422819
41 50 45.5 10 13 6.711409396 8.724832215
51 60 55.5 23 36 15.43624161 24.16107383
61 70 65.5 10 46 6.711409396 30.87248322
71 80 75.5 13 59 8.724832215 39.59731544
81 90 85.5 8 67 5.369127517 44.96644295
91 100 95.5 82 149 55.03355705 100
Acumulado 149 100
Tabla 21. Tabla de Distribución de Frecuencias. Fuente: Los autores.
Figura 29. Histograma y Polígono de Frecuencias. Fuente: Los autores.
Al analizar los resultados obtenidos con promedio de 80.8, mediana y moda de 95
y debido a que cuenta con una distribución de datos la cual el 50% son iguales o
mayores a 95, además el valor mínimo (Cuartil 0) se encuentra en 31,
presentando solo 12 datos con valor de 100 siendo estos valores atípicos para
nuestro análisis y teniendo en cuenta lo anterior se concluye que al no haber un
solo dato por debajo de esa cifra el código cuenta con un índice de mantenimiento
general óptimo.
0
10
20
30
40
50
60
70
80
90
35 45.5 55.5 65.5 75.5 85.5 95.5
Histograma y Polígono de Frecuencias
Histograma
Polígono
73
13.2. ACOPLAMIENTO DE CLASES
El acoplamiento de clases se mide a través de parámetros variables, locales,
métodos etc. Microsoft sugiere un acoplamiento de clases bajo lo que indica un
diseño fácil de reutilizar y mantener puesto que existe independencia de variables,
clases, etc, Para el análisis de dicho parámetro se organizaron los datos de forma
ascendente y para luego calcular las medidas de tendencia central de los datos
obtenidos, en el anexo 4 se observa la totalidad de datos.
En las tablas 22, 23 y 24 se pueden observar los resultados del análisis por medio
de la tabla, histograma y polígono de distribución de frecuencias para poder
observar mejor los datos.
Promedio 5.624161074
Mediana 1
Moda 0
Cuartil 0 0
Cuartil 1 0
Cuartil 2 1
Cuartil 3 7
Cuartil 4 67 Tabla 22. Cálculo de Medidas de Tendencia Central. Fuente: Los autores.
# de Datos 149
Valor Máx 67
Valor Min 0
Rango 67
# de Intervalos 8
Amplitud de clase
9
diferencia 1
Tabla 23. Cálculo de Parámetros de Tabla de Distribución de Frecuencias. Fuente: Los autores.
74
Intervalo de clase marca de
clase fi Fi hi[%] Hi[%]
-1 9 4 114 114 76.510067 76.510067
10 19 14.5 27 141 18.120805 94.630872
20 29 24.5 6 147 4.0268456 98.657718
30 39 34.5 0 147 0 98.657718
40 49 44.5 1 148 0.6711409 99.328859
50 59 54.5 0 148 0 99.328859
60 69 64.5 1 149 0.6711409 100
Acumulado 149 100
Tabla 24. Tabla de Distribución de Frecuencias. Fuente: Los autores.
Figura 30. Histograma y Polígono de Frecuencias. Fuente: Los autores.
Los resultados arrojan un promedio de 5.62, mediana de 1, moda de 0, valor
mínimo de 0 (Cuartil 0) y un valor máximo de 67 (Cuartil 4), lo que se evidencia en
los resultados obteniendo que aproximadamente el 75% de los datos se
encuentran con un acoplamiento de clases igual o inferior a 7 indicando la
independencia de la mayoría del código.
0
20
40
60
80
100
120
4 14.5 24.5 34.5 44.5 54.5 64.5
Histograma y Polígono de Frecuencias
Histograma
Polígono
75
14. RESULTADOS
A continuación se muestran tabulados los resultados de algunas pruebas que se
realizaron en el aplicativo Bitácora.
14.1. RESULTADOS GENERALES.
Parámetro Valor
Memoria Uso de Memoria 5.2 [GB]
Disponibilidad 49%
Tráfico Entrante 100.1K[bits]
Saliente 110.3K[bits]
Disco C Inactividad 91.8%
Porcentaje Promedio Escritura 0.1%
Tabla 25. Resultados Tabulados Pruebas. Fuente: Autores
Parámetro Valor
N (Elementos de Red con Capacidad Infinita) 5
Tráfico Total 2.319999 [Erlangs]
Número de Usuarios 463
Tamaño Máximo por Archivo 12MB
Total Archivos Guardados 3333
Tabla 26. Resultados Análisis De Tráfico. Fuente: Autores.
14.2. ENCUESTA
Teniendo en cuenta que el aplicativo BITACORA se encuentra en ambiente
productivo desde el 02 de abril del 2018 con dos usuarios autorizados para el
registro y seguimiento de incidencias, se realizaron las siguientes preguntas para
analizar el nivel de satisfacción y funcionabilidad del aplicativo con respecto al
proceso:
A. Mida el nivel de satisfacción del uso del aplicativo BITACORA, con respecto
a tiempos de respuesta y disponibilidad de la información, siendo 1 el peor
5 el mejor.
76
1. .
2. .
3. .
4. X (Usuario 1)
5. X (Usuario 2)
Observaciones: Se sugiere ajustar el campo de fechas para optimizar el registro
de incidencias.
B. Respecto al proceso del proyecto Agrario, ¿Cómo ha ayudado el aplicativo
BITACORA para reducir el número de incidentes?, siendo 1 nada y 5
mucho.
1. X (Usuario 1)
2. X (Usuario 2)
3. .
4. .
5. .
Observaciones: A la fecha no es posible realizar dicha medición ya que se
requiere tener un mayor tiempo el aplicativo en el ambiente productivo para
generar un informe de los incidentes recurrentes.
77
CONCLUSIONES
o La información recogida con el levantamiento logró estandarizar y definir a
las distintas categorías que son necesarias para una selección eficiente de
la información, con esta información se logró el diseño de las categorías y
el diseño del FRONT de usuario para el registro de incidentes.
o Se logró implementar por completo la plataforma con FRONT, base de
datos, soporte de fallas que permiten el registro de datos, fallas con la
seguridad de la aplicación establecida por la empresa implementando el
método de encriptación SHA512 de Visual Studio siendo éste junto a
Microsoft Windows Server 2012 herramientas importantes para el desarrollo
exitoso del aplicativo ya que se contaba con la limitante del uso de software
licenciado y fueron proporcionados por la empresa.
o Con las pruebas de volumetría realizadas al servidor y a la plataforma en
generar se puede concluir que la evaluación de parámetros de calidad del
servicio y seguridad fue satisfactoria al igual que el análisis de tráfico
debido a los resultados arrojados.
o Por medio de las encuetas a los usuarios se determinó que el aplicativo ha
sido una buena herramienta para los mismos, debido a que cuentan con un
concepto favorable en cuanto a tiempos de respuestas y disponibilidad de
78
la información además de la facilidad de registro y el fácil acceso a los
mismos.
REFERENCIAS BIBLIOGRÁFICAS
[1] PEDRAZA, L; HERNANDEZ, C; SALCEDO, O. Platform of Electronic Marketing
for Development of ICTs Application. IEEE, 2011.
[2] TOMYIM, J; POHTHONG, A. Requirements Change Management Based on
Object-Oriented Software Engineering with Unified Modeling Language. IEEE,
2016.
[3] JUTLA, D; BODOWIK, P; ALI, S. Engineering Privacy for Big Data Apps with
the Unified Modeling Language. IEEE, 2013.
[4] LAN, Y; LI, T. The Application of Unified Modeling Language in the
Performance Evaluation of R&D Staff. IEEE, 2012.
[5] REYES, N; CASTIBLANCO, A; PEDRAZA L. Desarrollo de un Sistema de
Información Para la Empresa Datecsa S.A. REDES DE INGENIERÍA, 2013.
[6] GIUSTO, D. 10 Consejos Para el Desarrollo Seguro de Aplicaciones [En Línea]. Disponible en <https://www.welivesecurity.com/la-es/2015/03/12/10-consejos-desarrollo-seguro-de-aplicaciones/> [7] PINCIROLI, F. Análisis de sistemas orientado a objetos: estado del arte. [En Línea]. Disponible en < http://ucongreso.edu.ar/grado/carreras/lsi/Introduccion_al_UML1.pdf>
[8] OWASP. Modelado de Amenazas. [En Línea]. Disponible en < https://www.owasp.org/index.php/Modelado_de_Amenazas#Introducci.C3.B3n > [9] OWASP. Modelado de Amenazas [En Línea]. Disponible en <https://www.owasp.org/index.php/Modelado_de_Amenazas> [10] UNIVERSIDAD INTERNACIONAL DE VALENCIA. ¿Qué es la seguridad informática y cómo puede ayudarme? [En Línea]. Disponible en: <https://www.universidadviu.es/la-seguridad-informatica-puede-ayudarme/>
79
[11] Introducción a la Seguridad Informática. [En Línea]. Disponible en <https://es.ccm.net/contents/622-introduccion-a-la-seguridad-informatica> [12] CARDONA, J. SALCEDO, W. Análisis y evaluación de riesgos de seguridad
informática para la cámara de comercio de La Dorada, Puerto Boyacá, Puerto
Salgar y Municipios de Oriente de Caldas. Universidad Nacional Abierta y a
Distancia, 2017. [En Línea]. Disponible en <
http://repository.unad.edu.co/bitstream/10596/14418/1/10174106.pdf>
[13] ROMERO, L. Seguridad Informática, Conceptos Generales. Universidad de
Salamanca. [En Línea]. Disponible en: <
http://campus.usal.es/~derinfo/Activ/Jorn02/Pon2002/LARyALSL.pdf>
[14] BAADER, R. Seguridad de la Información. Universidad de Buenos Aires,
2018. [En Línea]. Disponible en: < https://www-
2.dc.uba.ar/materias/seginf/material/Clase01-Unidad1_vf.pdf>
[15] SORIANO, M. Seguridad en Redes y Seguridad de la Información. České
vysoké učení technické v Praze. [En Línea]. Disponible en: <
http://improvet.cvut.cz/project/download/C2ES/Seguridad_de_Red_e_Informacion.
pdf>
[16] GRUPO DE SEGURIDAD INFORMÁTICA. Seguridad Informática.
Universidad De La República Uruguay, 2018. [En Línea]. Disponible en: <
https://eva.fing.edu.uy/pluginfile.php/58016/mod_resource/content/6/FSI-2018-
IAA.pdf>
[17] UNIVERSIDAD INTERNACIONAL DE VALENCIA. ¿Qué es la seguridad informática y cómo puede ayudarme? [En Línea]. Disponible en: <https://www.universidadviu.es/la-seguridad-informatica-puede-ayudarme/> [18] TALENS-OLIANG, S. Seguridad en el Desarrollo de Aplicaciones. Escuela
Politécnica Superior, 2004. [En Línea]. Disponible en: <
https://www.uv.es/sto/charlas/SDA/SDA.pdf>
[19] UNIÓN INTERNACIONAL DE TELECOMUNICACIONES. La Seguridad de las
Telecomunicaciones y las Tecnologías de la Información, 2006.
[20] UNIÓN INTERNACIONAL DE TELECOMUNICACIONES. Serie G: Sistemas y Medios de Transmisión, Sistemas y Redes Digitales, 2001. Página 5. [21] MICROSOFT. Valores de Métricas de Código. [En Línea]. Disponible en
<https://msdn.microsoft.com/es-es/library/bb385914.aspx>
80
[22] MICROSOFT. Introducción al Servidor Web IIS. [En Línea]. Disponible en
<https://msdn.microsoft.com/es-es/library/hh831725(v=ws.11).aspx>
[23] CACTIL [En Línea] Disponible en <https://www.cacti.net/what_is_cacti.php> [24] JMeter. Disponible en <https://jmeter.apache.org/>
[25] Norma ISO 25000. Calidad Del Producto Software. [En Línea]. Disponible En
<http://iso25000.com/index.php/normas-iso-25000/10-iso-iec-2503n>
[26] Guía 02. ISO 25000. Calidad del Producto Software. [En Línea]. Disponible en
<http://artemisa.unicauca.edu.co/~cardila/CS_02_Calidad_Producto_SW__ISO_25
000__2017.pdf>
[27] NIELSEN, J. Designing Web Usability. 2001. [En Línea]. Disponible en
<https://es.slideshare.net/webconomia/jakob-nielsen-usabilidad>
81
ANEXOS
Anexo 1: MANUAL DE USUARIO
BITACORA, su herramienta On-Line que le permite realizar el reporte de
inconsistencias de alto impacto que afecta la operación del proyecto Banco
Agrario relacionadas a despliegues, inconvenientes con el volumen activo, entre
otras.
¿Cómo acceder a BITACORA?
Acceda a la URL http://BITACORA/Login.aspx desde el navegador de su
preferencia y a continuación digite su usuario y contraseña de SIGDOC,
Una vez ingresado su usuario y contraseña, podrá visualizar el menú principal
donde podrá Consultar, Reportar la inconsistencia o Reportar la Solución
correspondiente, para cada una de las opciones se profundizara a lo largo del
presente manual:
82
1. Reporte inconsistencias
Para reportar la inconsistencia presentada se debe dar click en la opción
“REPORTAR INCONSISTENCIA” y después se le da click en el botón ACEPTAR,
como se muestra a continuación:
El siguiente menú se visualizara una vez realizada la acción anterior:
83
Para reportar la inconsistencia presentada se cuenta con las siguientes opciones
de selección:
FECHA INICIO: Fecha en la que se empezó a presentar la inconsistencia:
CATEGORÍA: Se cuentan con las siguientes categorías de acuerdo a los
inconvenientes que se presentan con mayor frecuencia en el proyecto Banco
Agrario:
Descripción categoría
Lentitud SIGDOC
Indisponibilidad SIGDOC
Visualización de imágenes SIGDOC
Cambio de Vol.
Rollback
Lentitud COBIS
Indisponibilidad COBIS
Actualización COBIS
Soporte correo electrónico
Fallas de red
Lentitud GLPI
Indisponibilidad GLPI
Inconsistencia GLPI
AREA ENCARGADA: En este campo se seleccionada el área responsable de la
inconsistencia presentada, se cuenta con las siguientes áreas:
84
Descripción área
Mesa de servicios
Soporte Infraestructura
Infraestructura
Banco
Implementación
Mesa de servicios MTI
Descripción: en este campo se debe escribir de manera detallada un resumen de
la inconsistencia que se está presentando.
NOTA: Para registrar el inconveniente con éxito se deben diligenciar todos los
campos.
Una vez diligenciados todos los campos se le da click en el botón GUARDAR Y
CONTINUAR, y se mostrara el número de la inconsistencia reportada, como se
visualiza a continuación:
85
Se le da click en el botón aceptar, y esto lo retornara al menú principal.
1.1. Guardar y reportar solución
El aplicativo BITACORA cuenta con la opción de guardar la inconsistencia y
reportar la solución correspondiente, desde la página de Reportar inconsistencia,
como se muestra a continuación:
Una vez dado click en el botón “Guardar y reportar solución”, lo enviara a la página
de reporte solución, indicando el número de incidente y la descripción del mismo:
86
Para reportar la solución se cuentan con los siguientes ítems:
FECHA DE SOLUCIÓN: Fecha en la que se dio solución a la inconsistencia
presentada.
PERSONA ASIGNADA: Persona encargada de solucionar el inconveniente
reportado. En este caso se visualizan los líderes de cada área.
DESCRIPCIÓN: Una breve descripción de cómo se solucionó el inconveniente
presentado.
Para finalizar se da click en el botón ACEPTAR.
87
NOTA: Tener en cuenta que se deben completar la totalidad de campos para
reportar la solución con éxito.
88
2. Reporte solución
Para reportar la solución de una inconsistencia ya reportada se debe dar click en
la opción “REPORTAR INCONSISTENCIA” y después se le da click en el botón
ACEPTAR, como se muestra a continuación:
El siguiente menú se visualizara una vez realizada la acción anterior:
Para reportar la solución se consulta por un número de incidente y se da click en
el botón aceptar que se encuentra, como se muestra a continuación:
89
Si se encuentra con información de dicho incidente, se va a mostrar la descripción
del inconveniente, la categoría, el área encargada y la fecha en que se reportó:
NOTA: En caso tal que no exista el número de incidente se va a mostrar un
mensaje indicando que se valide este número de incidente.
Como se había mencionado anteriormente en el inciso 1.1 Guardar y reportar
Solución, para reportar la solución se cuentan con los siguientes ítems:
FECHA DE SOLUCIÓN: Fecha en la que se dio solución a la inconsistencia
presentada.
PERSONA ASIGNADA: Persona encargada de solucionar el inconveniente
reportado. En este caso se visualizan los líderes de cada área.
DESCRIPCIÓN: Una breve descripción de cómo se solucionó el inconveniente
presentado.
Para finalizar se da click en el botón ACEPTAR.
90
NOTA: Tener en cuenta que se deben completar la totalidad de campos para
reportar la solución con éxito.
3. Consulta
Para realizar una consulta desde el aplicativo “BITACORA”, se debe dar click en la
opción Consultar, después en el botón ‘ACEPTAR’:
El siguiente menú se visualizara una vez realizada la acción anterior:
91
Como se puede visualizar se cuenta con las siguientes opciones, para realizar una
consultar:
* Consultar por nro. de la novedad reportada.
* Consultar por categoría.
* Consultar por fecha de creación.
* Consultar por fecha de creación y por categoría.
A continuación se detallara la manera correcta en la que se deben realizar las
consultas de acuerdo a la opción seleccionada:
3.1. Consulta por inconsistencia
Para realizar la consulta por el número de la inconsistencia, se da click en la
opción “Nro. Novedad” se habilitara el label para ingresar el número de la
inconsistencia, una vez realizado esto se da click en el botón aceptar:
92
NOTA: Tener en cuenta que una vez seleccionada dicha opción, no se permitirá
escoger la opción por categoría o fecha de creación.
El resultado obtenido se muestra a continuación:
En esta página se cuenta con la opción de extraer la información, solamente se
debe dar click en el botón “EXTRAER INFORMACIÓN”, automáticamente se
descargara un archivo con el nombre Export con extensión XLS.
93
NOTA: Para las opciones de consulta de Categoría y/o fecha se podrá descargar
la información de la misma manera.
3.2. Consulta por categoría
Para realizar la consulta por las categorías de las inconsistencias, se da click en la
opción “Categoría” se habilitara un menú desplegable con las categorías que ya se
han mencionado con anterioridad, una vez seleccionada la categoría se da click
en el botón aceptar:
NOTA: Una vez seleccionada la opción de categoría se podrá escoger la fecha de
creación, pero quedara inactiva la opción de “Nro. Novedad”.
El resultado obtenido se puede visualizar a continuación:
94
Para extraer la información, se siguen los pasos mencionados en el inciso 3.1.
Consulta por inconsistencia.
3.3. Consulta por fecha de creación
Para realizar la consulta por un rango de fecha de creación, se da click en la
opción “Fecha de creación” se habilitara la opción para escoger el rango de las
fechas, una vez seleccionada las dos fechas se da click en el botón aceptar:
NOTA: Una vez seleccionada la opción de fecha de creación se podrá escoger la
categoría, pero quedara inactiva la opción de “Nro. Novedad”.
El resultado obtenido se puede visualizar a continuación:
95
Para extraer la información, se siguen los pasos mencionados en el inciso 3.1.
Consulta por inconsistencia.
3.4. Consulta por fecha/categoría
Para realizar la consulta por un rango de fecha de creación y una categoría, se da
click en la opción “Fecha de creación” se habilitara la opción para escoger el rango
de las fechas, adicional se da click en la opción Categoría; una vez seleccionada
la categoría y las dos fechas se da click en el botón aceptar:
NOTA: Una vez seleccionada la opción de categoría y de fecha de creación,
quedara inactiva la opción de “Nro. Novedad”.
96
El resultado obtenido se puede visualizar a continuación:
Para extraer la información, se siguen los pasos mencionados en el inciso 3.1.
Consulta por inconsistencia.
NOTA: Para cualquier opción seleccionada para consultar se deben diligenciar
todos los campos que se habiliten de lo contrario no podrá continuar con la
consulta requerida.
97
Anexo 2: Modelo DREAD
98
Anexo 3: Configuración JMeter
Para la configuración del Jmeter se realizan los siguientes pasos:
1. Se descarga el Jmeter desde la página:
https://jmeter.apache.org/
2. Se descomprime el archivo descargado.
3. En la carpeta obtenida se busca el archivo jmeter.bat en la ruta
\apache-jmeter-2.13\bin
4. Cuando se ejecuta el archivo, se abre el programa Jmeter
5. Para generar la grabación de las pruebas que se van a realizar sobre el
aplicativo (Bitácota) y ejecutarla desde el Jmeter se debe instalar la
extensión BlazeMeter en el navegador (Preferiblemente Google Chrome).
6. Después de inscribirse en la página de BlazeMeter e instalar la extensión
en el navegador ya se puede realizar la grabación correspondiente del
aplicativo. Como se muestra a continuación:
99
7. Una vez terminada la grabación se extrae un archivo .jmx
8. El archivo .jmx se abre en el aplicativo Jmeter y ahí se mostraran los pasos
realizados en la grabación como un grupo de hilos, para ejecutar estos
pasos se da click sobre el botón arrancar:
9. Los resultados obtenidos se pueden visualizar como árbol de resultados y/o
generar un reporte resumen (entre otras opciones), como se muestra a
continuación:
100
101
Anexo 4: Métricas de Código
# Ámbito Espacio de nombres
Tipo Miembro Índice de
mantenimiento Acoplamiento de
clases
1 Proyecto
73 67
2 Espacio de nombres
BITACORA
61 47
3 Tipo BITACORA Consulta
57 23
4 Miembro BITACORA Consulta Button1_Click(object, EventArgs) : void 77 3
5 Miembro BITACORA Consulta Button2_Click(object, EventArgs) : void 83 5
6 Miembro BITACORA Consulta Button3_Click(object, EventArgs) : void 77 3
7 Miembro BITACORA Consulta Button4_Click(object, EventArgs) : void 83 5
8 Miembro BITACORA Consulta Button5_Click(object, EventArgs) : void 31 14
9 Miembro BITACORA Consulta Button6_Click(object, EventArgs) : void 88 3
10 Miembro BITACORA Consulta Calendar1_SelectionChanged(object,
EventArgs) : void 73 6
11 Miembro BITACORA Consulta Calendar2_SelectionChanged(object,
EventArgs) : void 73 6
12 Miembro BITACORA Consulta CheckBox1_Click(object, EventArgs) : void 65 4
13 Miembro BITACORA Consulta CheckBox2_Click(object, EventArgs) : void 53 6
14 Miembro BITACORA Consulta CheckBox3_CheckedChanged(object,
EventArgs) : void 48 7
15 Miembro BITACORA Consulta Consulta() 100 1
16 Miembro BITACORA Consulta lb_CerrarSesion_Click(object, EventArgs) : void 73 5
17 Miembro BITACORA Consulta Page_Load(object, EventArgs) : void 55 11
18 Tipo BITACORA Inicio
68 12
19 Miembro BITACORA Inicio Button1_Click(object, EventArgs) : void 62 7
20 Miembro BITACORA Inicio Inicio() 100 1
21 Miembro BITACORA Inicio lb_CerrarSesion_Click(object, EventArgs) : void 73 5
22 Miembro BITACORA Inicio Page_Load(object, EventArgs) : void 62 7
23 Tipo BITACORA Login
63 18
24 Miembro BITACORA Login Button1_Click(object, EventArgs) : void 60 7
25 Miembro BITACORA Login Front(Class1) : void 50 13
26 Miembro BITACORA Login Login() 100 1
27 Miembro BITACORA Login Page_Load(object, EventArgs) : void 95 3
28 Tipo BITACORA ReporteI
nc 62 20
29 Miembro BITACORA ReporteI
nc Button1_Click(object, EventArgs) : void 77 3
30 Miembro BITACORA ReporteI
nc Button2_Click(object, EventArgs) : void 83 5
31 Miembro BITACORA ReporteI
nc Button3_Click(object, EventArgs) : void 51 13
32 Miembro BITACORA ReporteI
nc Button4_Click(object, EventArgs) : void 52 13
33 Miembro BITACORA ReporteI
nc Button5_Click(object, EventArgs) : void 88 3
34 Miembro BITACORA ReporteI
nc Calendar1_SelectionChanged(object,
EventArgs) : void 72 6
35 Miembro BITACORA ReporteI
nc lb_CerrarSesion_Click(object, EventArgs) : void 73 5
36 Miembro BITACORA ReporteI Page_Load(object, EventArgs) : void 51 11
102
nc
37 Miembro BITACORA ReporteI
nc ReporteInc() 100 1
38 Tipo BITACORA ReporteS
ol 61 24
39 Miembro BITACORA ReporteS
ol Button1_Click(object, EventArgs) : void 77 3
40 Miembro BITACORA ReporteS
ol Button2_Click(object, EventArgs) : void 83 5
41 Miembro BITACORA ReporteS
ol Button3_Click(object, EventArgs) : void 47 11
42 Miembro BITACORA ReporteS
ol Button4_Click(object, EventArgs) : void 56 12
43 Miembro BITACORA ReporteS
ol Button5_Click(object, EventArgs) : void 88 3
44 Miembro BITACORA ReporteS
ol Calendar1_SelectionChanged(object,
EventArgs) : void 72 6
45 Miembro BITACORA ReporteS
ol lb_CerrarSesion_Click(object, EventArgs) : void 73 5
46 Miembro BITACORA ReporteS
ol Page_Load(object, EventArgs) : void 48 17
47 Miembro BITACORA ReporteS
ol ReporteSol() 100 1
48 Tipo BITACORA ResulCon
sul 53 28
49 Miembro BITACORA ResulCon
sul Button1_Click(object, EventArgs) : void 64 5
50 Miembro BITACORA ResulCon
sul Button2_Click(object, EventArgs) : void 45 19
51 Miembro BITACORA ResulCon
sul Button3_Click(object, EventArgs) : void 64 5
52 Miembro BITACORA ResulCon
sul lb_CerrarSesion_Click(object, EventArgs) : void 60 5
53 Miembro BITACORA ResulCon
sul Page_Load(object, EventArgs) : void 40 11
54 Miembro BITACORA ResulCon
sul ResulConsul() 100 1
55 Espacio de nombres
BITACORA.Class
86 29
56 Tipo BITACORA.Clas
s BitSoluci
on 93 1
57 Miembro BITACORA.Clas
s BitSoluci
on BitSolucion() 100 0
58 Miembro BITACORA.Clas
s BitSoluci
on DesSol.get() : string 98 0
59 Miembro BITACORA.Clas
s BitSoluci
on DesSol.set(string) : void 95 0
60 Miembro BITACORA.Clas
s BitSoluci
on FechaSol.get() : DateTime 98 1
61 Miembro BITACORA.Clas
s BitSoluci
on FechaSol.set(DateTime) : void 95 1
62 Miembro BITACORA.Clas
s BitSoluci
on idinconv.get() : int 98 0
63 Miembro BITACORA.Clas
s BitSoluci
on idinconv.set(int) : void 95 0
64 Miembro BITACORA.Clas
s BitSoluci
on Idres.get() : int 98 0
65 Miembro BITACORA.Clas
s BitSoluci
on Idres.set(int) : void 95 0
66 Miembro BITACORA.Clas
s BitSoluci
on IdSol.get() : int 98 0
67 Miembro BITACORA.Clas
s BitSoluci
on IdSol.set(int) : void 95 0
103
68 Tipo BITACORA.Clas
s Busqued
a 93 1
69 Miembro BITACORA.Clas
s Busqued
a Area.get() : string 98 0
70 Miembro BITACORA.Clas
s Busqued
a Area.set(string) : void 95 0
71 Miembro BITACORA.Clas
s Busqued
a Busqueda() 100 0
72 Miembro BITACORA.Clas
s Busqued
a Categoría.get() : string 98 0
73 Miembro BITACORA.Clas
s Busqued
a Categoría.set(string) : void 95 0
74 Miembro BITACORA.Clas
s Busqued
a Descripción.get() : string 98 0
75 Miembro BITACORA.Clas
s Busqued
a Descripción.set(string) : void 95 0
76 Miembro BITACORA.Clas
s Busqued
a DescripciónSolución.get() : string 98 0
77 Miembro BITACORA.Clas
s Busqued
a DescripciónSolución.set(string) : void 95 0
78 Miembro BITACORA.Clas
s Busqued
a FechaFin.get() : string 98 0
79 Miembro BITACORA.Clas
s Busqued
a FechaFin.set(string) : void 95 0
80 Miembro BITACORA.Clas
s Busqued
a FechaInicial.get() : DateTime 98 1
81 Miembro BITACORA.Clas
s Busqued
a FechaInicial.set(DateTime) : void 95 1
82 Miembro BITACORA.Clas
s Busqued
a FechaInicial2.get() : DateTime 98 1
83 Miembro BITACORA.Clas
s Busqued
a FechaInicial2.set(DateTime) : void 95 1
84 Miembro BITACORA.Clas
s Busqued
a NroInconveniente.get() : int 98 0
85 Miembro BITACORA.Clas
s Busqued
a NroInconveniente.set(int) : void 95 0
86 Miembro BITACORA.Clas
s Busqued
a Responsable.get() : string 98 0
87 Miembro BITACORA.Clas
s Busqued
a Responsable.set(string) : void 95 0
88 Tipo BITACORA.Clas
s Class1
94 0
89 Miembro BITACORA.Clas
s Class1 autorizado.get() : string 98 0
90 Miembro BITACORA.Clas
s Class1 autorizado.set(string) : void 95 0
91 Miembro BITACORA.Clas
s Class1 cadena.get() : string 98 0
92 Miembro BITACORA.Clas
s Class1 cadena.set(string) : void 95 0
93 Miembro BITACORA.Clas
s Class1 Class1() 100 0
94 Miembro BITACORA.Clas
s Class1 usuario.get() : string 98 0
95 Miembro BITACORA.Clas
s Class1 usuario.set(string) : void 95 0
96 Tipo BITACORA.Clas
s Connecti
on 50 29
97 Miembro BITACORA.Clas
s Connecti
on Connection() 100 0
98 Miembro BITACORA.Clas
s Connecti
on ConnectionBitacora() : SqlConnection 60 4
99 Miembro BITACORA.Clas
s Connecti
on ConnectionManagerUser() : SqlConnection 60 4
104
100 Miembro BITACORA.Clas
s Connecti
on Consult(Busqueda) : IList<Busqueda> 50 17
101 Miembro BITACORA.Clas
s Connecti
on Consult1(Busqueda) : List<Busqueda> 50 16
102 Miembro BITACORA.Clas
s Connecti
on Consult11(Busqueda) : List<Busqueda> 50 17
103 Miembro BITACORA.Clas
s Connecti
on Consult12(Busqueda) : List<Busqueda> 49 17
104 Miembro BITACORA.Clas
s Connecti
on Fecha(Busqueda) : bool 52 12
105 Miembro BITACORA.Clas
s Connecti
on FechaCateg(Busqueda) : bool 52 12
106 Miembro BITACORA.Clas
s Connecti
on GetArea() : IList<Criterios> 52 17
107 Miembro BITACORA.Clas
s Connecti
on GetCriterios() : IList<Criterios> 52 17
108 Miembro BITACORA.Clas
s Connecti
on GetResponsable() : IList<Criterios> 52 17
109 Miembro BITACORA.Clas
s Connecti
on GetSolucion(Solucion) : IList<Solucion> 51 17
110 Miembro BITACORA.Clas
s Connecti
on IdCateg(Criterios) : bool 53 11
111 Miembro BITACORA.Clas
s Connecti
on IdInc(Criterios) : bool 53 11
112 Miembro BITACORA.Clas
s Connecti
on IdSol(Criterios) : bool 53 11
113 Miembro BITACORA.Clas
s Connecti
on LoginUser(Class1) : bool 33 19
114 Miembro BITACORA.Clas
s Connecti
on ReporteInc(Criterios) : int 55 7
115 Miembro BITACORA.Clas
s Connecti
on ReporteSol(BitSolucion) : void 55 9
116 Tipo BITACORA.Clas
s Criterios
93 1
117 Miembro BITACORA.Clas
s Criterios Area.get() : string 98 0
118 Miembro BITACORA.Clas
s Criterios Area.set(string) : void 95 0
119 Miembro BITACORA.Clas
s Criterios Criterios() 100 0
120 Miembro BITACORA.Clas
s Criterios Descategoria.get() : string 98 0
121 Miembro BITACORA.Clas
s Criterios Descategoria.set(string) : void 95 0
122 Miembro BITACORA.Clas
s Criterios DesInconv.get() : string 98 0
123 Miembro BITACORA.Clas
s Criterios DesInconv.set(string) : void 95 0
124 Miembro BITACORA.Clas
s Criterios FechIni.get() : DateTime 98 1
125 Miembro BITACORA.Clas
s Criterios FechIni.set(DateTime) : void 95 1
126 Miembro BITACORA.Clas
s Criterios IdArea.get() : int 98 0
127 Miembro BITACORA.Clas
s Criterios IdArea.set(int) : void 95 0
128 Miembro BITACORA.Clas
s Criterios Idcategoria.get() : int 98 0
129 Miembro BITACORA.Clas
s Criterios Idcategoria.set(int) : void 95 0
130 Miembro BITACORA.Clas
s Criterios Idinconv.get() : string 98 0
131 Miembro BITACORA.Clas
s Criterios Idinconv.set(string) : void 95 0
105
132 Miembro BITACORA.Clas
s Criterios IdResponsable.get() : int 98 0
133 Miembro BITACORA.Clas
s Criterios IdResponsable.set(int) : void 95 0
134 Miembro BITACORA.Clas
s Criterios Login.get() : string 98 0
135 Miembro BITACORA.Clas
s Criterios Login.set(string) : void 95 0
136 Miembro BITACORA.Clas
s Criterios Responsable.get() : string 98 0
137 Miembro BITACORA.Clas
s Criterios Responsable.set(string) : void 95 0
138 Tipo BITACORA.Clas
s Solucion
93 1
139 Miembro BITACORA.Clas
s Solucion Área.get() : string 98 0
140 Miembro BITACORA.Clas
s Solucion Área.set(string) : void 95 0
141 Miembro BITACORA.Clas
s Solucion Categoría.get() : string 98 0
142 Miembro BITACORA.Clas
s Solucion Categoría.set(string) : void 95 0
143 Miembro BITACORA.Clas
s Solucion Descripción.get() : string 98 0
144 Miembro BITACORA.Clas
s Solucion Descripción.set(string) : void 95 0
145 Miembro BITACORA.Clas
s Solucion Fecha.get() : DateTime 98 1
146 Miembro BITACORA.Clas
s Solucion Fecha.set(DateTime) : void 95 1
147 Miembro BITACORA.Clas
s Solucion NroIncidente.get() : int 98 0
148 Miembro BITACORA.Clas
s Solucion NroIncidente.set(int) : void 95 0
149 Miembro BITACORA.Clas
s Solucion Solucion() 100 0
