Tesis - Sistema de Información para El Control y Gestión Del Mantenimiento Preventivo de La Plataforma de Escritorio Del Edificio Sede Guaraguao Pdvsa Refinación Oriente

Universidad de Oriente
Núcleo de Anzoátegui
Escuela de Ingeniería y Ciencias Aplicadas
Departamento de Computación y Sistemas
SISTEMA DE INFORMACIÓN PARA EL CONTROL Y GESTIÓN DEL

MANTENIMIENTO PREVENTIVO DE LA PLATAFORMA DE ESCRITORIO
DEL EDIFICIO SEDE GUARAGUAO PDVSA REFINACIÓN ORIENTE
Autor:
Br. Randolph David Zamora
Trabajo de grado presentado ante la Universidad de Oriente como

requisito parcial para optar al título de
INGENIERO DE SISTEMAS
Barcelona, Junio del 2018
Núcleo Ingeniería de Anzoátegui
Escuela de y Ciencias Aplicadas
_______________________ ______________________
Ing. Manuel Carrasquero MSc. Ing. Néstor García
Tutor Académico Tutor Externo
Trabajo de grado presentado ante la Universidad de Oriente como

requisito parcial para optar al título de
Barcelona, Mayo del 2018
Núcleo de Anzoátegui
Escuela de Ingeniería y Ciencias Aplicadas
Jurado Calificador
__________________________
__
Ing. Manuel Carrasquero MSc.
Asesor Académico
________________________ ____________________
Ing. Víctor Mujica Ing. Héctor Moisés
Jurado principal Jurado Principal
Barcelona, Mayo del 2018

RESOLUCIÓN
De acuerdo al Artículo 41 del reglamento de Trabajos de Grado de la

Universidad de Oriente:
“Los Trabajos de Grado son de la exclusiva propiedad de la Universidad
de Oriente, y solo podrán ser utilizados para otros fines con el
consentimiento del Consejo de Núcleo respectivo, quien deberá participarlo
previamente al Consejo Universitario, para su autorización.”
iv
DEDICATORIA
Al creador del Universo por habernos dado el don más importante de un

ser humano puede tener la vida.
A todas aquellas personas que creyeron en mí y me brindaron una

mano amiga sin recibir nada a cambio.
A la Free Software Foundation, a GitHub y a toda aquella persona que

crea en el proyecto de software libre.
A cada uno de los profesores de la Universidad que me instruyeron en

mi formación académica y profesional a pesar de cientos de dificultades que
la vida pupo ponerles, nunca dejare de estar agradecido por cada uno de
ellos.
A mis padres por todo el apoyo y esfuerzo que ellos hicieron para
brindarme la mejor educación posible, han llevado a convertirme en un
profesional.
A mi hermano Gabriel Zamora
A la Universidad de Oriente y a todos los que la representan.
A mí amada Venezuela.
v
AGRADECIMIENTOS
En primer lugar quiero agradecer al Sr. Tomas Rondón y a la Sra. Iraida

Gamboa por haberme dado la oportunidad de realizar mi tesis en la Gerencia
AIT.
A los integrantes de RRHH en especial a Niurka Castillo, Luis Lozano,

Maria Griman y Elizabeth Romero, fui bastante afortunado por haber
compartido con ustedes, muchas gracias por todo.
A los integrantes de Soporte Básico Diego, Medina, Héctor Quintero,

Ángel Marcado, Iván Ramírez ,Iris Moya, Carmervid Figueroa, Pedro Gómez,
Imaru Rojas, Carlos Rincones, Orlando Leonett, Omar Velásquez y a mi tutor
Néstor García, gracias por tratarme como uno más de su equipo de trabajo.
A mi amigo José Manuel Castro por todo el apoyo y ayuda que me

brindaste en el área de circuito y electrónica.
Quiero agradecerle especialmente a cada uno de los integrantes de

Base de Datos Oriente especialmente a Juan Félix Salazar, Oscar Caraballo,
Joan Boada e Isabel Márquez gracias por su apoyo incondicional.
A mi amigos Franklin Barrero y Arturo Betancourt por la veces que me

apoyaron en realizar asignaciones de la UDO.
A mis compañeros de clases y posteriormente mis amigos del primer

semestre en la UDO, Richard Morocoima, Luis Salazar, Carlos Rivas, Luis
Mata, Wilfredo Rivas, Javier Más (†), Carla Mérida y Arturelys Mejías.
vi
A mis futuros colegas los Ingenieros de Sistemas Cesar Mata Moya
del Centro Integral de Monitoreo y Josel Vargas de Aplicaciones gracias por
todo el apoyo brindado.
A mi profesor de yoga Eduardo Cox, gracias por orientarme en los

momentos difíciles.
A los integrantes del área de Planificación y Programación de

Mantenimiento Eglee Diaz, Yelitza Mujica y Calimar Pinto gracias por todo el
apoyo y conocimiento brindado.
También quiero agradecer a los integrantes de PCP en especial a

Cristian Flores.
A mis amigas y compañeras de estudio Angelica Rich, Fredeleine

Monzant, Aimara Magallanes, Alejandra Miche, Zoremi Balbas y en especial
a una amiga que siempre estuvo conmigo a Roxana Pérez.
A Alfredo García y Elio Cabrera que a pesar de que realizamos nuestra

tesis en distritos distintos de PDVSA, siempre nos apoyamos para conseguir
el mismo propósito.
El destino me ha dado el privilegio de encontrar a personas como

ustedes en mi pasantía, gracias por todo, especialmente a algunas por estar
allí cuando lo necesitaba: María Rodríguez, Osmel Barragan, Franz Suarez,
Jessica Díaz, Luis Chira, Ana Goitia, Zoila Guacaran, Andriannys Turmero,
Karelym Vargas, Andreina Moisés, Yendrys Guacaran y Miguelina Yacua.
vii
A mis amistades de la UDO Miguel Contreras, Jen Colon, Ediannys
Acevedo, Jesús González, Luis Correa, Javier Araujo, Leonmary Betancourt,
Nordy Vilchez, Jean Madrid, Oriana Rojas, Andrés Campos, José Carrero,
José Mendoza, José Perdomo, Fabián José, Johan Useche y Fernando
Martínez de la Riva.
A todos los profesores que me brindaron sus conocimientos en

especial el área de Programación y Base de Datos Carolina Coronado, José
Marval, Jonathan Araujo, Jonathan Duran, Aquiles Torrealba, Aquiles Barreto,
José Guevara, Pedro Dorta, Yulitza Mujica, Gabriela Veracierta, Yesenia
Persad y en especial a mi tutor Manuel Carrasquero.
También quiero agradecer a cada uno de los profesores que me

instruyeron en mi carrera universitaria especialmente a Ronald Rodríguez,
Aurelia Torcasio, Luis Solórzano, Héctor Moisés, Lenin Benitez, Alfonso
Alfonsí, Reinaldo Pastrana, Yulima Anato, ,Aida Caraballo, Juan Fuentes,
Sonia Yu, Andrés Martínez, Luis Felipe Rojas, Ronny Martinez y Carlos Millan
A cada uno de los pasantes y analista que compartieron conmigo en

la Gerencia de Recursos Humanos y a todos lo que me falta nombrar en
estas páginas.
Finalmente quiero agradecer a PDVSA por darme la oportunidad de ser

parte de su familia principalmente en las dos gerencias donde estuve una
como pasante y la otra como tesista.
viii
RESUMEN
El presente proyecto consiste en el desarrollo de un sistema de

información para el apoyo del mantenimiento preventivo de la plataforma de
escritorio. El proyecto fue desarrollado para satisfacer las necesidades del
departamento de soporte básico de la Gerencia de Automatización
Informática y Telecomunicaciones. El departamento de soporte básico se
encarga de realizar diversas actividades que permiten controlar la plataforma
tecnológica de PDVSA, desde la base de la información de sus activos, hasta
los cambios que se realizan sobre ellos y en su configuración. A su vez se
encarga del proceso de análisis, mantenimiento preventivo y correctivo de los
equipos de información o equipos informáticos en general, teniendo en
cuenta computadoras de escritorio, computadoras portátiles, estaciones de
trabajo, y equipos de impresión. Este departamento no cuenta con una
aplicación que permita organizar y recopilar la información de los
mantenimientos que se realiza a los equipos, atendiendo a estas
consideraciones, surge la necesidad de desarrollar un sistema de
información para el control y gestión del mantenimiento preventivo de la
plataforma de escritorio.Las técnicas de datos utilizadas fueron la revisión
bibliográfica, la observación directa y las entrevistas no estructuradas. El tipo
de investigación fue de campo y el nivel de investigación descriptiva. El
diseño y desarrollo de la aplicación web fue elaborado según las fases de
desarrollo de software (RUP), en sus tres primeras etapas, de inicio,
elaboración y construcción. Para el diseño de la arquitectura del software se
utilizó el Lenguaje Unificado de Modelado (UML) y para la construcción del
software se utilizó PHP 5.6 y PostgreSQL 9.3 como base de datos,
cumpliendo con el decreto presidencial 3390 de desarrollo de software libre.
ix
ÍNDICE GENERAL
RESOLUCIÓN.........................................................................................iv
DEDICATORiA..........................................................................................v
AGRADECIMIENTOS..............................................................................vi
RESUMEN...............................................................................................ix
ÍNDICE GENERAL....................................................................................x
ÍNDICE DE FIGURAS............................................................................xvi
ÍNDICE DE TABLA.................................................................................xxi
INDICE DE ANEXOS............................................................................xxiv
CAPITULO I............................................................................................25
EL PROBLEMA.......................................................................................25
1.1 Planteamiento del Problema.........................................................25
1.2 Objetivos.......................................................................................28
1.2.1 Objetivo General....................................................................28
1.2.2 Objetivos Específicos............................................................28
CAPITULO II...........................................................................................29
MARCO TEÓRICO.................................................................................29
2.1 Antecedentes................................................................................29
2.2 Bases teóricas...............................................................................31
2.2.1 Mantenimiento........................................................................31
2.2.1.1 Tipos de mantenimiento..................................................31
2.2.1.2 Mantenimiento Centrado en Confiabilidad (MCC o RCM)

..............................................................................................................32
x
2.2.2 Tecnologías de la información (IT).........................................33
2.2.3 Sistemas de información (SI).................................................33
2.2.3.1 Actividades básicas de un sistema de información.........33
2.2.3.2 Tipos de Sistemas de Información..................................34
2.2.4 Modelado de Lenguaje Unificado (UML)...............................35
2.2.5 Proceso Unificado de Software (R.U.P: Rational Unified

Process)...................................................................................................36
2.2.6 Bases de Datos......................................................................37
2.2.6.1 Data Management Association (DAMA)..........................37
2.2.6.2 Gestión de datos..............................................................38
2.2.6.3 Modelo de Datos..............................................................38
2.2.6.4 Modelo entidad relación..................................................39
2.2.6.5 Modelo relacional.............................................................39
2.2.6.6 Mapeo de Objeto Relacional (ORM)...............................39
2.2.6.7 Sistema de Gestión de Base de Datos (SGBD)..............40
2.2.6.8 PostgreSQL.....................................................................40
2.2.7 Software Libre........................................................................41
2.2.8 Aplicaciones web....................................................................41
2.2.9 PHP (Hypertext Pre-processor).............................................42
2.2.10 Intranet.................................................................................42
2.2.11 Programación Orientada a Objetos (POO)..........................43
2.2.12 Framework...........................................................................44
2.2.12.1 Tipos de Framework web..............................................45
xi
2.2.13 Codeigniter...........................................................................46
2.2.14 Arquitectura MVC (Model-View-Controller)..........................46
2.2.15 Sistema Integral de Gestión Automatizada para la Gerencia

AIT (SIGA-AIT).........................................................................................47
2.2.16 Nagios..................................................................................48
2.2.17 Protocolo Simple de Administración de Red (SNMP)..........49
2.3 Descripción del Sistema...............................................................50
2.3.1 Petróleos de Venezuela, S.A. (PDVSA).................................50
2.3.2 PDVSA Refinación Oriente....................................................50
2.3.3 Reseña Histórica de la Gerencia AIT.....................................51
2.3.4 Declaración de la misión y visión de la Gerencia AIT............52
2.3.4.1 Misión de la Gerencia AIT...............................................52
2.3.4.2 Visión de la Gerencia AIT................................................52
2.3.5 Estructura Organizativa..........................................................52
2.3.5.1 Estructura Organizativa de PDVSA Refinación Oriente.....52
2.3.5.2 Estructura Organizativa de la Gerencia AIT Oriente.......52
CAPITULO III..........................................................................................54
MARCO METODOLÓGICO...................................................................54
3.1 Tipo de Investigación....................................................................54
3.2 Nivel de la Investigación...............................................................54
3.3 Técnicas a Utilizar.........................................................................54
CAPITULO IV.........................................................................................56
RESULTADOS........................................................................................56
xii
4.1 Fase de Inicio................................................................................56
4.1.1 Descripción del Sistema Actual..............................................57
4.1.2 Modelo de Dominio................................................................61
4.1.2.1 Glosario de Términos......................................................61
4.1.2.2 Diagrama Dominio de Sistema........................................62
4.1.3 Diagrama de Sistema y Ambiente Ampliado..........................63
4.1.4 Descripción de la Problemática..............................................65
4.1.5 Flujo de Trabajo de Requisitos...............................................65
4.1.5.1 Contexto del Sistema......................................................66
4.1.5.2 Casos de Uso del Sistema..............................................72
4.1.5.3 Modelo de Casos de Uso................................................73
4.1.5.4 Descripción de los Casos de Uso...................................75
4.1.6 Flujo de Trabajo de Análisis...................................................98
4.1.6.1 Paquetes de Análisis del Sistema.................................100
4.1.6.2 Diagrama de Clases de Análisis....................................101
4.1.6.3 Diagrama de Colaboración............................................118
4.1.7 Flujo de Trabajo de Diseño..................................................135
4.1.7.1 Arquitectura Candidata..................................................136
4.1.7.2 Prototipo de la interfaz Inicio de Sesión........................137
4.1.8 Conclusión de la Fase de Inicio...........................................137
4.2 Fase de Elaboración...................................................................139
4.2.1 Flujo de Trabajo de Requisitos.............................................140
xiii
4.2.1.1 Representación de los nuevos requisitos de clases de
uso......................................................................................................140
4.2.1.2 Modelo de Caso de Uso Mejorado................................140
4.2.1.3 Descripción de los nuevos casos de uso......................142
4.2.2 Flujo de Trabajo de Análisis.................................................147
4.2.2.1 Paquetes de Análisis del Sistema.................................147
4.2.2.2 Diagrama de Clases de Análisis y Colaboración (Nueva

Versión)..............................................................................................148
4.2.3 Flujo de Trabajo de Diseño..................................................159
4.2.3.1 Arquitectura del Sistema................................................160
4.2.3.2 Diagrama de Clase de Diseño......................................161
4.2.3.3 Diseño de la Base de Datos..........................................168
4.2.3.4 Diccionarios de Datos....................................................169
4.2.4 Implementación....................................................................185
4.2.4.1 Identificación de Componentes de la arquitectura........185
4.3 Fase Construcción......................................................................189
4.3.1 Herramientas de Desarrollo de Software Utilizado..............189
4.3.2 Flujo de Trabajo de implementación....................................196
4.3.2.1 Diseño de la Interfaz de Usuario...................................196
4.3.3 Diagrama de Componentes.................................................215
4.3.4 Flujo de Trabajo de Pruebas............................................217
4.3.4.1 Pruebas de Unidad........................................................217
4.3.4.2 Pruebas de Integración.................................................218
xiv
4.3.4.3 Pruebas de Caja Negra.................................................219
4.3.5 Conclusión de la Fase de Construcción..............................225
CONCLUSIONES.................................................................................226
RECOMENDACIONES........................................................................227
BIBLIOGRAFÍA.....................................................................................228
ANEXO.................................................................................................232
METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:.233
xv
ÍNDICE DE FIGURAS
Figura 2.1: Estructura Organizativa de PDVSA Refinación Oriente..............53

Figura 2.2: Estructura Organizativa de la Gerencia AIT Oriente...................53
Figura 4.1: Fase de Inicio...............................................................................56
Figura 4.2: Modelo de servicios de la Gerencia AIT......................................57
Figura 4.3: Diagrama del Dominio del Sistema.............................................63
Figura 4.4: Diagrama de Sistema y Ambiente Ampliado................................64
Figura 4.5: Modelo de Caso de Uso General del Sistema............................74
Figura 4.6: Diagrama del Caso de Uso Login................................................75
Figura 4.7: Diagrama del Caso de Uso Clases de Activos............................76
Figura 4.8 Diagrama del Caso de Uso Tipos de Activos................................78
Figura 4.9: Diagrama del Caso de Uso Listados de Activos..........................80
Figura 4.10: Diagrama del Caso de Uso Planificación de Mantenimiento.. .81
Figura 4.11: Diagrama del Caso de Uso Registro de Mantenimiento...........83
Figura 4.12: Diagrama del Caso de uso Tareas de Mantenimiento...............85
Figura 4.13: Diagrama del Caso Tipos de Mantenimiento.............................87
Figura 4.14 Diagrama del Caso de uso Frecuencia......................................88
Figura 4.15: Diagrama del Caso de uso Herramientas y Materiales.............90
Figura 4.16: Diagrama del Caso de uso Nagios............................................92
Figura 4.17: Diagrama del Caso de uso Configuración de Usuarios.............93
Figura 4.18: Diagrama del Caso de uso Roles del Usuario...........................94
Figura 4.19: Diagrama del Caso de uso Módulos del Sistema......................96
Figura 4.20: Diagrama del Caso de uso Reportes Oficiales..........................98
Figura 4.21: Diagrama de Paquetes de Análisis..........................................100
Figura 4.22: Diagrama de Clase de Análisis del Caso de uso Login...........107
Figura 4.23: Diagrama de Clase de Análisis del Caso de uso “Clases de
Activo”............................................................................................................108
xvi
Figura 4.24: Diagrama de Clase de Análisis del Caso de uso “Tipos de
Activos”..........................................................................................................108
Figura 4.25: Diagrama de Clase de Análisis del Caso de uso Listados de
Activos...........................................................................................................109
Figura 4.26: Diagrama de Clase de Análisis del Caso de uso “Registro de
Mantenimiento”..............................................................................................110
Figura 4.27: Diagrama de Clase de Análisis del Caso de uso “Planificación
de Mantenimiento”.........................................................................................111
Figura 4.28: Diagrama de Clase de Análisis del Caso de uso Tareas de
Mantenimiento...............................................................................................112
Figura 4.29: Diagrama de Clase de Análisis del Caso de uso Tipos de
Mantenimiento...............................................................................................113
Figura 4.30: Diagrama de Clase de Análisis del Caso de uso “Frecuencia”113
Figura 4.31: Diagrama de Clase de Análisis del Caso de uso Herramientas y
Materiales......................................................................................................114
Figura 4.32: Diagrama de Clase de Análisis del Caso de uso “Nagios”......115
Figura 4.33: Diagrama de Clase de Análisis del Caso de uso “Configuración
de Usuarios”..................................................................................................116
Figura 4.34: Diagrama de Clase de Análisis del Caso de uso “Roles del
Usuario”.........................................................................................................116
Figura 4.35: Diagrama de Clase de Análisis del Caso de uso “Módulos”....117
Figura 4.36: Diagrama de Clase de Análisis del Caso de uso “Reportes
Oficiales”........................................................................................................117
Figura 4.37: Diagrama de Colaboración del Caso de Uso “Login”..............119
Figura 4.38: Diagrama de Colaboración del Caso de Uso “Clases de Activos”
.......................................................................................................................120
Figura 4.39: Diagrama de Colaboración del Caso de Uso “Tipos de Activos”
.......................................................................................................................121
xvii
Figura 4.40: Diagrama de Colaboración del Caso de Uso “Listados de
Activos”..........................................................................................................123
Figura 4.41: Diagrama de Colaboración del Caso de Uso “Registro de
Mantenimiento”..............................................................................................125
Figura 4.42: Diagrama de Colaboración del Caso de Uso “Planificación de
Mantenimiento”..............................................................................................126
Figura 4.43: Diagrama de Colaboración del Caso de Uso Tareas de
Mantenimiento...............................................................................................127
Figura 4.44: Diagrama de Colaboración del Caso de Uso “Tipos de
Mantenimiento”..............................................................................................128
Figura 4.45: Diagrama de Colaboración del Caso de Uso “Frecuencia”.....129
Figura 4.46: Diagrama de Colaboración del Caso de Uso “Herramientas y
Materiales”.....................................................................................................130
Figura 4.47: Diagrama de Colaboración del Caso de Uso “Nagios”...........131
Figura 4.48: Diagrama de Colaboración del Caso de Uso “Configuración de
Usuarios”.......................................................................................................133
Figura 4.49: Diagrama de Colaboración del Caso de Uso “Roles del Usuario”
.......................................................................................................................134
Figura 4.50: Diagrama de Colaboración del Caso de Uso “Módulos”.........134
Figura 4.51 Diagrama de Colaboración del Caso de Uso “Reportes Oficiales”
.......................................................................................................................135
Figura 4.52: Arquitectura Candidata Cliente-Servidor.................................137
Figura 4.53: Prototipo de la Interfaz de Usuario..........................................138
Figura 4.54 Fase de Elaboración.................................................................139
Figura 4.55: Modelo de Caso de Uso General del sistema (Nueva Versión)
.......................................................................................................................141
Figura 4.56: Diagrama del Caso de Uso Consultar Marcas y Modelos.......142
Figura 4.57 Diagrama del Caso de Uso Calendario de Tareas...................143
Figura 4.58 Diagrama del Caso de Uso Asignar Tipos de Activos..............144
xviii
Figura 4.59: Diagrama del Caso de Uso Permisología................................146
Figura 4.60: Diagrama de Paquetes de Análisis (Nueva versión)...............148
Figura 4.61: Diagrama de Clase de Análisis del Caso de Uso “Consultar
Marcas y Modelos”........................................................................................151
Figura 4.62: Diagrama de Clase de Análisis del Caso de Uso “Calendario de
Tareas”..........................................................................................................152
Figura 4.63: Diagrama de Clase de Análisis del Caso de Uso “Tareas de
Mantenimiento”..............................................................................................153
Figura 4.64: Diagrama de Clase de Análisis del Caso de Uso “Permisología”
.......................................................................................................................153
Figura 4.65: Diagrama de Colaboración del Caso de Uso “Consultar Marcas
y Modelos”.....................................................................................................154
Figura 4.66: Diagrama de Colaboración del Caso de Uso “Calendario de
Tareas”..........................................................................................................155
Figura 4.67 Diagrama de Colaboración del Caso de Uso “Tareas de
Mantenimiento”..............................................................................................157
Figura 4.68 Diagrama de Colaboración del Caso de Uso “Permisología”...158
Figura 4.69: Diagrama de Capas.................................................................162
Figura 4.70 Diagrama de Clases de Diseño................................................163
Figura 4.71: Base de Datos del Sistema......................................................170
Figura 4.72: Diagrama de Despliegue del Sistema.....................................187
Figura 4.73 Plantilla del sistema..................................................................188
Figura 4.74: Fase de Construcción..............................................................189
Figura 4.75: Interfaz Login...........................................................................197
Figura 4.76:Código fuente HTML de la vista Login......................................198
Figura 4.77:Código fuente del Controlador Login........................................199
Figura 4.78:Código fuente del Modelo Login...............................................200
Figura 4.79: Interfaz Clases de Activos........................................................201
Figura 4.80 interfaz Tipos de Activos...........................................................201
xix
Figura 4.81: Interfaz Listado de Activos.......................................................202
Figura 4.82: Interfaz Consultar Marcas y Modelos......................................202
Figura 4.83: Interfaz Calendario de Tareas..................................................203
Figura 4.84 interfaz Registro de Mantenimiento..........................................204
Figura 4.85 interfaz Planificación de Mantenimiento...................................205
Figura 4.86 interfaz Planificación de Mantenimiento...................................205
Figura 4.87 Interfaz Tareas de Mantenimiento.............................................206
Figura 4.88 interfaz Asignar Herramientas y Materiales..............................207
Figura 4.89 interfaz Asignar Tipos de Activos..............................................207
Figura 4.90 interfaz Tipos de Mantenimiento...............................................208
Figura 4.91 Interfaz Frecuencia..................................................................209
Figura 4.92 interfaz Herramientas y Materiales...........................................209
Figura 4.93 Interfaz Nagios..........................................................................210
Figura 4.94 Configuración de Usuarios........................................................211
Figura 4.95: Roles de Usuarios....................................................................212
Figura 4.96: Interfaz Módulos.......................................................................212
Figura 4.97: Interfaz Permisología...............................................................213
Figura 4.98: Interfaz Reportes Oficiales.......................................................214
Figura 4.99: Interfaz Mantenimiento Culminado..........................................214
Figura 4.100: Interfaz Servicio de Impresión Nagios...................................215
Figura 4.101: Diagrama de Componentes...................................................216
xx
ÍNDICE DE TABLA
Tabla 4.1: Glosario de Términos ....................................................................61

Tabla 4.2:Actores del Sistema........................................................................68
Tabla 4.3: Requisitos no Funcionales del Sistema ........................................69
Tabla 4.4 Identificación de los riesgos del sistema .......................................70
Tabla 4.5: Casos de Uso del Sistema ...........................................................72
Tabla 4.6:Casos de Uso Login .......................................................................75
Tabla 4.7:Caso de Uso Clases de Activos .....................................................77
Tabla 4.8:Caso de Uso Tipos de Activos .......................................................78
Tabla 4.9:Caso de Uso Listados de Activos ..................................................80
Tabla 4.10:Caso de Uso Planificación de Mantenimiento .............................81
Tabla 4.11:Caso de Uso Registro de Mantenimiento.....................................84
Tabla 4.12:Casos de Uso Tareas de Mantenimiento .....................................85
Tabla 4.13:Casos de Uso Tipos de Mantenimiento .......................................87
Tabla 4.14: Caso de Uso Frecuencia ............................................................89
Tabla 4.15:Casos de Uso Herramientas y Materiales ...................................90
Tabla 4.16:Casos de Uso Nagios...................................................................92
Tabla 4.17:Casos de Uso Configuración de Usuarios ...................................93
Tabla 4.18: Caso de Uso Roles del Usuario ..................................................95
Tabla 4.19: Caso de Uso Módulos .................................................................96
Tabla 4.20: Caso de Uso Reportes Oficiales..................................................98
Tabla 4.21:Comparación entre los modelo de casos de uso y modelo de
análisis.............................................................................................................99
Tabla 4.22: Descripción de las Clases Interfaz del Sistema .......................102
Tabla 4.23: Descripción de las Clases de Control del Sistema....................104
Tabla 4.24:Descripción de las Clases de Entidad del Sistema....................105
Tabla 4.25: Descripción de los nuevos Casos de Uso.................................140
xxi
Tabla 4.26: Caso de Uso Consultar Marcas y Modelos...............................142
Tabla 4.27: Caso de Uso Calendario de Tareas ..........................................143
Tabla 4.28: Caso de Uso Asignar Tipos de Activos......................................145
Tabla 4.29: Caso de Uso Permisología........................................................146
Tabla 4.30: Descripción de las Clase interfaz del sistema...........................149
Tabla 4.31: Descripción de las Clase de control del sistema.......................149
Tabla 4.32: Descripción de la Clases de entidad del sistema.....................150
Tabla 4.33: Comparación entre el modelo de análisis y modelo de diseño 159
Tabla 4.34: Persona .....................................................................................171
Tabla 4.35: Clase de Activo..........................................................................172
Tabla 4.36: Clase de activo detalle...............................................................173
Tabla 4.37: Activo .........................................................................................173
Tabla 4.38: Marca ........................................................................................175
Tabla 4.39: Modelo.......................................................................................176
Tabla 4.40: Frecuencia de Mantenimiento...................................................177
Tabla 4.41: Plan de Mantenimiento .............................................................177
Tabla 4.42: Tarea de mantenimiento............................................................178
Tabla 4.43: Tareas de mantenimiento y herramienta...................................179
Tabla 4.44: Tareas de mantenimiento y tipo de activo.................................179
Tabla 4.45: Tipo de Mantenimiento..............................................................180
Tabla 4.46: Unidad de Tiempo......................................................................180
Tabla 4.47: Herramienta...............................................................................181
Tabla 4.48: Histórico de Monitoreo ..............................................................181
Tabla 4.49: Usuario.......................................................................................183
Tabla 4.50: Nivel de Usuario.........................................................................184
Tabla 4.51: Modulo.......................................................................................184
Tabla 4.52 Permisologia...............................................................................185
Tabla 4.53: Clase de Equivalencia...............................................................219
Tabla 4.54: Prueba de Unidad del caso de uso Tipos de Activos................220
xxii
Tabla 4.55: Prueba de Unidad del Caso de Uso Clases de Activo .............220
Tabla 4.56: Prueba de Unidad del caso de uso Realizar Mantenimiento....221
Tabla 4.57: Prueba de Unidad del caso de Uso Tareas de Mantenimiento. 222
Tabla 4.58: Prueba de Unidad del caso de Uso Tipos de Mantenimiento . .222
Tabla 4.59: Prueba de Unidad del caso de uso Frecuencia........................223
Tabla 4.60: Prueba de Unidad del caso de Herramientas y Materiales ......223
Tabla 4.61:Prueba de Unidad del caso de Uso Roles de Usuario...............224
Tabla 4.62: Prueba de Unidad del Caso de uso Módulos............................224
xxiii
INDICE DE ANEXOS
Anexo A:........................................................................................................232
xxiv
CAPITULO I
EL PROBLEMA
1.1 Planteamiento del Problema
Los sistemas de información (SI) y las tecnologías de información (TI)

han cambiado la forma en que operan las organizaciones actuales, su uso en
las organizaciones inducen a importantes mejoras, ya que automatizan los
procesos operativos, suministran una plataforma de información necesaria
para la toma de decisiones y, lo más importante, su implantación logra
ventajas competitivas.
PDVSA requiere de una infraestructura tecnológica de vanguardia, es

por ello que dentro de la empresa existe una gerencia exclusivamente a
proveer, suministrar y coordinar los servicios y las soluciones que abarca el
área de Automatización, Informática y Telecomunicaciones, esta es la
Gerencia AIT, ella se encarga de contribuir a mantener la continuidad
operativa de la plataforma tecnológica de la empresa, también coordina y
ejecuta planes para mantener dicha plataforma actualizada.
En Refinación Oriente de Puerto la Cruz, la plataforma de escritorio

está conformada por tres servicios: el servicio de escritorio (computadoras de
escritorio, portátiles y estaciones de trabajo), el servicio de impresión
(impresoras y plotter) y el servicio de telecomunicaciones (switches,
conmutadores, routers, teléfonos, cableado estructurado). Actualmente la
plataforma de escritorio no cuenta con ningún plan de mantenimiento
preventivo provocando que los servicios de red, de impresión y las
computadoras presenten fallas y permanezcan fuera de servicio.
26
En la Gerencia AIT coexisten dos sistemas que permiten aplicar

mantenimiento correctivo a la plataforma de escritorio, el primero de ellos es
el Sistema Integral de Gestión Automatizada para la Gerencia AIT (SIGA-
AIT), basado en tecnología de software libre que permite dar una solución a
cualquier requerimiento o incidente de forma ordenada, y el segundo es el
sistema de monitoreo Nagios, basado también en software libre que
supervisa constantemente el estado de la plataforma y de los servicios que
ellos prestan, generando notificaciones a los grupos responsables de su
mantenimiento en caso de presentarse alguna anomalía o caída del servicio.
Para el control del mantenimiento de la plataforma de escritorio los

analistas de la Gerencia AIT hacen uso de hojas de cálculo electrónica para
almacenar la información de las fallas que presentan los equipos, debido a
que el sistema SIGA-AIT en el cual se registran las ordenes de servicio, no
permite realizar los estudios, cálculos y seguimientos de forma directa y
simple, esto ocurre ya que en sus relaciones internas hay deficiencia en la
conexión de algunas tablas de la bases de datos, las cuales no permiten que
los reportes de las fallas o incidentes, no contenga la identificación del
equipo. Hay que mencionar además que el sistema de monitoreo Nagios
guarda la información de los incidentes, en archivo de texto plano que
dificultan la consulta de los mismos.
Atendiendo a estas consideraciones se plantea desarrollar un

sistema de información para la gestión y control del mantenimiento
preventivo, enfocado al servicio de escritorio y al servicio de impresión que
permita llevar un cierto control del mantenimiento preventivo de los equipos.
Para comenzar a realizar este proyecto, se debe analizar la situación
actual del mantenimiento preventivo de la plataforma de escritorio que
actualmente se encuentra inoperativa, luego de tener una visión clara de la
27
problemática, se analizarán los requisitos funcionales que tendrá el nuevo

sistema de información, tomando en cuenta las normativa de la Gerencia AIT
para la elaboración de la base de datos y del desarrollo del software. Este
sistema de información será desarrollado utilizando la metodología de
Proceso Unificado de Desarrollo de Software (RUP) y para el modelado del
sistema se utilizara el Lenguaje Unificado de Modelado (UML).
El alcance del proyecto es realizar el desarrollo de un sistema de

información que permita llevar un control del mantenimiento preventivo de la
plataforma de escritorio y su implementación depende de las decisiones que
tomen la Gerencia AIT en cuanto a las necesidades y calidad de este
proyecto.
Es importante señalar que este proyecto es relevante debido a que

sería el primer sistema de mantenimiento preventivo para la plataforma de
escritorio, también hay que destacar que el nuevo software permitirá la
integración con el sistema de monitoreo Nagios y SIGA-AIT. Este sistema
permitirá guardar los datos de monitoreo de Nagios, llevar un control de los
servicios de impresión y asignar tareas de mantenimiento a los equipos.
28
1.2 Objetivos
1.2.1 Objetivo General

Desarrollar un Sistema de Información para Control y Gestión del
Mantenimiento Preventivo de la Plataforma de Escritorio del Edificio Sede
Guaraguao PDVSA Refinación Oriente.
1.2.2 Objetivos Específicos

1. Describir la situación actual de la Plataforma de Escritorio del Edificio
Sede Guaraguao PDVSA Refinación Oriente
2. Establecer los requisitos funcionales del nuevo sistema de

información.
3. Diseñar la estructura del software y de la base de datos.
4. Programar los módulos del sistema de información.
5. Realizar las pruebas de unidad y de integración al software

desarrollado.
CAPITULO II
MARCO TEÓRICO
2.1 Antecedentes
Ortiz (2009), desarrolló un sistema de información para la

Superintendencia de Movimiento de Crudos de PDVSA. Este proyecto tuvo
como objetivo solucionar las deficiencias en el registro de las fallas y
actividades de mantenimiento que se realiza a las bombas centrífugas y
bombas de tornillos. Por esta razón se desarrolló un sistema de información
utilizando la metodología del Proceso Unificado de Desarrollo de Software
(RUP) y para el modelado y diseño de la arquitectura del software se empleó
el Lenguaje Unificado de Modelado (UML). El producto final resultó en un
sistema propio y automatizado que ayuda a agilizar el trabajo que se realiza
en la superintendencia, mejorando la gestión de la información, reduciendo
los tiempos de búsqueda y evitando errores.
Bustamante y Ramos (2009), diseñaron un sistema de gestión de

mantenimiento para una empresa de servicios en el área de
telecomunicaciones. En el cual se identificaron, clasificaron y analizaron los
factores que dan origen a las deficiencias del sistema de mantenimiento de la
empresa. Además se estudiaron los principios básicos Mantenimiento
Productivo Total (TMP) y se justificó su implementación dentro de la
empresa, para diversas necesidades o problemas específicos que se le
plantean a nivel gerencial; por último se propuso un sistema de información
computarizado para la gestión de mantenimiento preventivo.
30
Medida (2009), realizó el desarrollo de un sistema de información web

para la gestión de incidentes de falla en la plataforma tecnológica de la
Gerencia AIT. El estudio tuvo como propósito implementar un sistema de
información que automatice el proceso de llenado de los reportes de las
fallas y a partir de estos reportes se consiguieron indicadores de
confiabilidad y disponibilidad, que fueron complementados con datos
registrados por el sistema de monitoreo Nagios, de este modo se logró
obtener un histórico de fallas y una base de conocimientos del
mantenimiento realizado a cada equipo y aplicación de la plataforma. El
proceso de desarrollo del sistema fue guiado por el método Watch para el
desarrollo de aplicaciones empresariales y como herramienta de modelado
se utilizó el Lenguaje Unificado de Modelado (UML).
Ramírez y Rosas (2012), desarrollaron un sistema para el registro y

seguimiento de las solicitudes y fallas en el ambiente informático. Se logró
desarrollar el sistema utilizando la metodología de la Biblioteca de
Infraestructura de Tecnologías de Información (ITIL). Para el diseño de la
arquitectura del software el Lenguaje Unificado de Modelado (UML). Gracias
al desarrollo del software se garantizó un refuerzo seguro para la línea de
soporte técnico implantada en la organización, ya que permitió dar un
seguimiento continuo y soluciones oportunas a las peticiones hechas y las
fallas reportadas por los usuarios, lo que finalmente facilitará una
administración adecuada de las mismas así como un mejor uso de las
Tecnologías de Información (TI) alojadas en la organización.
Cobos (2010), desarrolló un software para la Superintendencia de

Mantenimiento de la Plataforma (MAP) perteneciente a la Gerencia AIT de
PDVSA Refinación Oriente. Esta aplicación tuvo como objetivo la
automatización de las alarmas generadas por la herramienta de monitoreo
31
Nagios, para obtener beneficios de seguridad de la información, disminución

de esfuerzo, tiempo y rapidez en cuanto a la toma de decisiones. El diseño y
desarrollo de la aplicación fue realizado según las fases del Proceso
Unificado de Desarrollo de Software (RUP), las técnicas utilizadas para el
modelado y diseño fueron, el Lenguaje Unificado de Modelado (UML) y su
extensión WEBML. Para la implementación del sistema se utilizó el lenguaje
PHP y como manejador de base de datos PostgreSQL.
2.2 Bases teóricas
2.2.1 Mantenimiento
Según García (2003), define mantenimiento como el conjunto de

técnicas destinado a conservar equipos e instalaciones en servicio durante el
mayor tiempo posible (buscando la más alta disponibilidad) y con el máximo
rendimiento.
2.2.1.1 Tipos de mantenimiento
 Mantenimiento Preventivo: es el mantenimiento que tiene por misión

mantener un nivel de servicio determinado en los equipos, programando
las correcciones de sus puntos vulnerables en el momento más oportuno.
(Garcia, 2003).
 Mantenimiento Predictivo: es el que persigue conocer e informar

permanentemente del estado y operatividad de las instalaciones mediante
el conocimiento de los valores de determinadas variables, representativas
de tal estado y operatividad. Para aplicar este mantenimiento es
necesario identificar variables físicas (temperatura, vibración, consumo de
32
energía, etc.) cuya variación sea indicativa de problemas que puedan

estar apareciendo en el equipo. Es el tipo de mantenimiento más
tecnológico, pues requiere de medios técnicos avanzados, y de fuertes
conocimientos matemáticos, físicos y técnicos. (Garcia, 2003).
 Mantenimiento Correctivo: este tipo de mantenimiento solo se realiza

cuando el equipo es incapaz de seguir operando. No hay elemento de
planeación para este tipo de mantenimiento. Este es el caso que se
presenta cuando el costo adicional de otros tipos de mantenimiento no
puede justificarse. Este tipo de estrategia a veces se conoce como
estrategia de operación hasta que falle. Se aplica principalmente a
equipos electrónicos. (Duffuaa, Raouf y Dixon, 2000).
2.2.1.2 Mantenimiento Centrado en Confiabilidad (MCC o RCM)
Es una técnica más dentro de las posibles para poder elaborar un plan
de mantenimiento, que presenta algunas ventajas importantes sobre otras
técnicas. Inicialmente desarrollada para el sector de aviación, donde los altos
costes derivados de la sustitución sistemática de piezas amenazaba la
rentabilidad de las compañías aéreas, fue trasladada posteriormente al
campo industrial, después de comprobarse los excelentes resultados que
había dado en el campo aeronáutico. EL RCM propone un análisis minucioso
de la gravedad de cada fallo y de sus consecuencias, asignando un valor
numérico a ésta, de manera que pueda cuantificarse la importancia de cada
fallo. (Garcia, 2003).
33
2.2.2 Tecnologías de la información (IT)
Las Tecnologías de la Información han sido conceptualizadas como la

integración y convergencia de la computación, las telecomunicaciones y la
técnica para el procesamiento de datos, donde sus principales componentes
son: la información, el equipamiento, el factor humano, la infraestructura, el
software y los mecanismos de intercambio de información, los elementos de
política y regulaciones, además de los recursos financieros. (Universidad de
Chile, 2006).
2.2.3 Sistemas de información (SI)
Un sistema de información es un conjunto de elementos que interactúan

entre sí con el fin de apoyar las actividades de una empresa o negocio. En
un sentido más amplio, un sistema de información no necesariamente incluye
equipo electrónico (hardware). Sin embargo, en la práctica se utilizan como
sinónimo de “sistemas de información computarizado”. (Cohen y Asín, 2000).
2.2.3.1 Actividades básicas de un sistema de información
Cohen y Asín (2010), establecen que un sistema de información realiza

cuatro actividades Básicas:
 Entrada de información: proceso en el cual el sistema toma los datos

que requiere para procesar la información, por medio de estaciones de
trabajo, teclado, diskettes, cintas magnéticas, código de barras, etc.
 Almacenamiento de información: es una de las actividades más

importantes que tiene una computadora, ya que a través de esta
34
propiedad el sistema puede recordar la información guardada en la sesión

o proceso anterior.
 Procesamiento de la información: esta característica de los sistemas

permite la transformación de los datos fuente en información que puede
ser utilizada para la toma de decisiones, lo que hace posible, entre otras
cosas, que un tomador de decisiones genere una proyección financiera a
partir de los datos que contiene un estado de resultados o un balance
general en un año base.
 Salida de información: es la capacidad de un SI para sacarla

información procesada o bien datos de entrada al exterior. Las unidades
típicas de salida son las impresoras, cintas magnéticas, diskettes, la voz,
etc.
2.2.3.2 Tipos de Sistemas de Información
De acuerdo a Cohen y Asín (2010), el analista de sistemas desarrolla

diferentes tipos de sistemas de información para satisfacer las diversas
necesidades de una empresa, dentro de estas categorías encontramos:
 Sistemas para el procesamiento de transacciones: este tipo de

sistemas es uno de los más importantes dentro de una organización, los
mismos tienen como finalidad mejorar las actividades rutinarias de una
empresa y de las que esta depende. Las transacciones más comunes
incluyen: facturación, entrega de mercancía, pago de empleados y
depósitos de cheques. Aunque los tipos de transacciones varían de una
organización a otra, la mayor parte de estas procesan dichas
transacciones como una parte de sus actividades cotidianas.
35
 Sistemas de Información Administrativa: este tipo de sistemas ayudan

a los directivos a tomar decisiones y resolver problemas, además
proporciona la información que será empleada en los procesos de
decisiones administrativas. Trata con el soporte de situaciones de
decisión bien estructuradas. Es posible anticipar los requerimientos de
información más comunes.
 Sistemas para soporte de decisiones: estos sistemas ayudan a los

directivos que deben tomar decisiones no muy estructuradas, también
denominadas no estructuradas o semi-estructuradas. Para la toma de
estas decisiones el sistema debe proporcionar información importante
referente a situaciones particulares.
2.2.4 Modelado de Lenguaje Unificado (UML)
Para Rumbaugh, Jacobson y Booch, (2000), el UML ("Unified Modeling

Language"). Es un lenguaje que permite modelar, construir y documentar los
elementos que forman un sistema software orientado a objetos, el mismo
dispone un conjunto de notaciones y diagramas estándar para modelar
dichos sistemas, y describe la semántica esencial de lo que estos diagramas
y símbolos significan.
Rumbaugh y otros aseguran que el UML está consolidado como un

lenguaje estándar para el análisis y diseño de sistemas de cómputo.
Mediante este lenguaje es posible establecer la serie de requerimientos

y estructuras necesarias para plasmar un sistema de software previo al
proceso intensivo de escribir código. Dicho lenguaje está compuesto por
diversos elementos gráficos que se combinan para formar diagramas, debido
36
a que en su lenguaje cuenta con reglas para combinar dichos elementos y de

esta forma presentar diversas perspectivas de un sistema.
2.2.5 Proceso Unificado de Software (R.U.P: Rational Unified Process)
Alonso y Martínez (2005), definen al proceso unificado como el

desarrollo de software que describe el conjunto de actividades necesarias
para transformar los requisitos del usuario en un sistema de software.
Está dirigido por casos de uso, centrado en la arquitectura del sistema,

y es iterativo e incremental. Cada uno de estos se describen a continuación:
 Dirigido por casos de uso: un caso de uso es un fragmento de

funcionalidad del sistema que proporciona al usuario un resultado de
interés. El conjunto de los casos de uso constituye, en el proceso
unificado, el modelo de casos de uso que describe toda la funcionalidad
del sistema. Los casos de uso guían al proceso de desarrollo de software
dado que el modelo de casos de uso producido por el analista de
sistemas durante la captura de requisitos, y que sirve para especificar los
requisitos del sistema.
 Centrado en la Arquitectura: los casos describen la funcionalidad del

sistema mientras que la arquitectura define la forma que va a tener el
sistema para proporcionar esa funcionalidad. La arquitectura del sistema
software se describe, en el proceso unificado, mediante diferentes vistas
del sistema en construcción. La arquitectura describe las partes del
sistema que son importantes para que analistas y desarrolladores
comprendan al sistema.
37
 El proceso unificado es iterativo e incremental: Las iteraciones hacen

referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento
del producto. Para una efectividad máxima, las iteraciones deben estar
controladas; esto es, deben seleccionarse y ejecutarse de una forma
planificada.
2.2.6 Bases de Datos
Las bases de datos no son sólo una colección de archivos. Una base de
datos es una fuente central de datos con el fin de que varios usuarios la
compartan para su uso en varias aplicaciones. El corazón de una base de
datos es el sistema de administración de bases de datos (DBMS), el cual
permite crear, modificar y actualizar la base de datos, la recuperación de los
datos y la generación de informes y pantallas. A la persona que asegura que
la base de datos cumpla con sus objetivos se le conoce como administrador
de bases de datos. (Kendall y Kendall, 2001).
2.2.6.1 Data Management Association (DAMA)
Es la principal asociación de profesionales de datos a nivel mundial, es

una organización internacional, su propósito es promover la comprensión,
desarrollo y práctica de la gestión de datos para soportar las estrategias del
negocio. (DAMA) está conformada por diez procesos los cuales son
nombrados a continuación. (DAMA International, 2015).
 Gobierno de Datos
 Gestión de la Arquitectura de Datos (Data Architecture)
 Desarrollo de Datos (Data Modeling & Design)
 Gestión de Operaciones de Datos (Data Storage)

38
 Gestión de seguridad de Datos (Data Security)
 Gestión de Datos Maestros y Referencia (Reference & Master Data)
 Gestión de Almacenes de Datos e Inteligencia del Negocio
 Gestión de Documentos y Contenidos (Documents & Contents)
 Gestión de Metadatos (Meta-Data)
 Gestión de Calidad de los Datos (Data Quality)
2.2.6.2 Gestión de datos
Se compone de todas las disciplinas relacionadas con gestionar los

datos como un recurso valioso. La definición oficial suministrada por DAMA
es que "La Gestión de Recursos de Datos es el desarrollo y ejecución de
arquitecturas, políticas, prácticas y procedimientos que gestionan
apropiadamente las necesidades del ciclo de vida completo de los datos de
una empresa". Esta definición es suficientemente amplia y abarca un número
de profesiones que pueden no tener contacto técnico directo con aspectos de
bajo nivel de la gestión de datos, tales como la gestión de una base de datos
relacional. (DAMA International, 2015).
2.2.6.3 Modelo de Datos
Bajo la estructura de la base de datos se encuentra el modelo de datos:

una colección de herramientas conceptuales para describir los datos, las
relaciones, la semántica y las restricciones de consistencia.
Para ilustrar el concepto de un modelo de datos, describimos dos

modelos de datos en este apartado: el modelo entidad-relación y el modelo
39
relacional. Los diferentes modelos de datos que se han propuesto se

clasiﬁcan en tres grupos diferentes: modelos lógicos basados en objetos,
modelos lógicos basados en registros y modelos físicos. (Silberschatz, Korth
y Sudarshan, 2002).
2.2.6.4 Modelo entidad relación
El modelo de datos entidad-relación (E-R) está basado en una

percepción del mundo real que consta de una colección de objetos básicos,
llamados entidades, y de relaciones entre estos objetos. Una entidad es una
cosa u objeto en el mundo real que es distinguible de otros objetos. Por
ejemplo, cada persona es una entidad, y las cuentas bancarias pueden ser
consideradas entidades. (Silberschatz, Korth y Sudarshan, 2002).
2.2.6.5 Modelo relacional
En el modelo relacional se utiliza un grupo de tablas para representar

los datos y las relaciones entre ellos. Cada tabla está compuesta por varias
columnas, y cada columna tiene un nombre único. (Silberschatz, Korth y
Sudarshan, 2002).
2.2.6.6 Mapeo de Objeto Relacional (ORM)
Object-relational mapping (ORM), es una técnica de programación para

convertir datos del sistema de tipos utilizado en un lenguaje de programación
orientado a objetos al utilizado en una base de datos relacional. En la
práctica esto crea una base de datos virtual orientada a objetos sobre la base
de datos relacional. Esto posibilita el uso de las características propias de la
orientación a objetos (esencialmente la herencia y el polimorfismo). Entre las
40
ventajas que ofrecen los (ORM) se encuentran: rapidez en el desarrollo,

abstracción de la base de datos, reutilización, seguridad, mantenimiento del
código, lenguaje propio para realizar las consultas. (Yánez y Gracia, 2011)
2.2.6.7 Sistema de Gestión de Base de Datos (SGBD)
Un SGBD consiste en un sistema de software de propósito general que

facilita el proceso de definir, construir y manipular bases de datos para
diversas aplicaciones. Es un conjunto de programas que permiten a los
usuarios crear y mantener una base de datos. La base de datos y el
software, en conjunto, constituyen el sistema de base de datos y los sistemas
más populares están basados en instrucciones que son dadas al SGBD a
través del lenguaje SQL. (Elmasri y Navathe, 2007).
2.2.6.8 PostgreSQL
PostgreSQL es un poderoso sistema manejador de bases datos

relacionales, de código abierto y capaz de ejecutarse en los principales
sistemas operativos, incluyendo Linux, Unix (AIX, BSD, HP-UX, SGI IRIX,
Mac OS X, Solaris, Tru64) y Windows. PostgreSQL provee total soporte a
claves foráneas, vistas, uniones, triggers y procedimientos almacenados (en
múltiples lenguajes) e incluye las mayoría de los tipos de datos SQL92 y
SQL99, tales como: NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE,
INTEGER, INTERVAL, entre otros. PostgreSQL se distribuye bajo licencia
BSD, lo que permite su uso, redistribución, modificación con la única
restricción de mantener el copyright del software a sus autores. (Universitat
Oberta de Catalunya, s.f).
41
2.2.7 Software Libre
Según Stallman (2004). El Software libre es la libertad de los usuarios

para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Nos
referimos especialmente a cuatro clases de libertad para los usuarios de
software:
 Libertad 0: la libertad para ejecutar el programa sea cual sea nuestro

propósito.
 Libertad 1: la libertad para estudiar el funcionamiento del programa y

adaptarlo a tus necesidades, el acceso al código fuente es condición
indispensable para esto.
 Libertad 2: la libertad para redistribuir copias y ayudar así a tu vecino.
 Libertad 3: la libertad para mejorar el programa y luego publicarlo para el

bien de toda la comunidad
2.2.8 Aplicaciones web
Llamadas “webapps”, esta categoría de software centrado en redes

agrupa una amplia gama de aplicaciones. En su forma más sencilla, las
webapps son poco más que un conjunto de archivos de hipertexto vinculados
que presentan información con uso de texto y gráficas limitadas. Sin
embargo, desde que surgió Web 2.0, las webapps están evolucionando hacia
ambientes de cómputo sofisticados que no sólo proveen características
aisladas, funciones de cómputo y contenido para el usuario final, sino que
también están integradas con bases de datos corporativas y aplicaciones de
negocios. En la actualidad, las webapps se han convertido en herramientas
42
sofisticadas de cómputo que no sólo proporcionan funciones aisladas al

usuario final, sino que también se han integrado con bases de datos
corporativas y aplicaciones de negocios. (Pressman, 2010).
2.2.9 PHP (Hypertext Pre-processor)
Es un lenguaje de scripting de código abierto y de propósito general. El

motor intérprete de PHP está escrito en C, lo que permite utilizarlo en casi
todos los tipos de computadores y sistemas operativos.
PHP suele venir instalado en UNIX. En equipos con otros sistemas

operativos, como Windows, Linux o Mac OS. Al igual que ocurre con otros
lenguajes de scripting, PHP es particularmente adecuado para la
manipulación de páginas de texto, y en particular para la manipulación de
páginas HTML dinámicas en el servidor web. (Elmasri y Navathe, 2007).
2.2.10 Intranet
Según Sommerville (2005), una intranet es una red de ordenadores

privados que utiliza tecnología Internet para compartir dentro de una
organización parte de sus sistemas de información y sistemas operacionales.
El término intranet se utiliza en oposición a internet, una red entre

organizaciones, haciendo referencia por contra a una red comprendida en el
ámbito de una organización.
43
2.2.11 Programación Orientada a Objetos (POO)
Según Fernández (1997), la Programación Orientada a Objetos (POO u

OOP según sus siglas en inglés) es un paradigma de programación que usa
objetos y sus interacciones para diseñar aplicaciones y programas de
computadora. Está basado en varias técnicas, incluyendo herencia,
modularidad, polimorfismo, y encapsulamiento. Su uso se popularizó a
principios de la década de 1990. La programación orientada a objetos es una
nueva forma de programar que trata de encontrar una solución a estos
problemas. Introduce nuevos conceptos, que superan y amplían conceptos
antiguos ya conocidos. Entre ellos se destacan los siguientes:
 Clase: definiciones de las propiedades y comportamiento de un tipo de

objeto concreto. La instanciación es la lectura de estas definiciones y la
creación de un objeto a partir de ellas, (de c a d), es la facilidad mediante
la cual la clase D ha definido en ella cada uno de los atributos y
operaciones de C, como si esos atributos y operaciones hubiesen sido
definidos por la misma D.
 Objeto: entidad provista de un conjunto de propiedades o atributos

(datos) y de comportamiento o funcionalidad (métodos). Se corresponde
con los objetos reales del mundo que nos rodea, o a objetos internos del
sistema (del programa). Es una instancia a una clase.
 Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya

ejecución se desencadena tras la recepción de un "mensaje". Desde el
punto de vista del comportamiento, es lo que el objeto puede hacer. Un
método puede producir un cambio en las propiedades del objeto, o la
generación de un "evento" con un nuevo mensaje para otro objeto del
sistema.
44
 Evento: un suceso en el sistema (tal como una interacción del usuario

con la máquina, o un mensaje enviado por un objeto). El sistema maneja
el evento enviando el mensaje adecuado al objeto pertinente. También se
puede definir como evento, a la reacción que puede desencadenar un
objeto, es decir la acción que genera.
 Mensaje: una comunicación dirigida a un objeto, que le ordena que

ejecute uno de sus métodos con ciertos parámetros asociados al evento
que lo genero
 Propiedad o atributo: contenedor de un tipo de datos asociados a un

objeto ó a una clase de objetos, que hace los datos visibles desde fuera
del objeto y esto se define como sus características predeterminadas, y
cuyo valor puede ser alterado por la ejecución de algún método.
 Estado interno: es una variable que se declara privada, que puede ser
únicamente accedida y alterada por un método del objeto, y que se utiliza
para indicar distintas situaciones posibles para el objeto (o clase de
objetos). No es visible al programador que maneja una instancia de la
clase.
 Componentes de un objeto: atributos, identidad, relaciones y métodos.
 Representación de un objeto: un objeto se representa por medio de una

tabla o entidad que esté compuesta por sus atributos y funciones
correspondientes.
2.2.12 Framework
Según Gutiérrez (s.f). El concepto framework se emplea en muchos

ámbitos del desarrollo de sistemas software, no solo en el ámbito de
45
aplicaciones Web. Podemos encontrar frameworks para el desarrollo de

aplicaciones médicas, de visión por computador, para el desarrollo de juegos,
y para cualquier ámbito que pueda ocurrírsenos. En general, con el término
framework, nos estamos refiriendo a una estructura software compuesta de
componentes personalizables e intercambiables para el desarrollo de una
aplicación. En otras palabras, un framework se puede considerar como una
aplicación genérica incompleta y configurable a la que podemos añadirle las
últimas piezas para construir una aplicación concreta.
Los objetivos principales que persigue un framework son: acelerar el

proceso de desarrollo, reutilizar código ya existente y promover buenas
prácticas de desarrollo como el uso de patrones. Un framework Web, por
tanto, podemos definirlo como un conjunto de componentes (por ejemplo
clases en java y descriptores y archivos de configuración en XML) que
componen un diseño reutilizable que facilita y agiliza el desarrollo de
sistemas Web.
2.2.12.1 Tipos de Framework web
Existen varios tipos de frameworks Web: orientados a la interfaz de

usuario, como Java Server Faces, orientados a aplicaciones de publicación
de documentos, como Coocon, orientados a la parte de control de eventos,
como Struts y algunos que incluyen varios elementos como Tapestry.
La mayoría de frameworks Web se encargan de ofrecer una capa de

controladores de acuerdo con el patrón MVC o con el modelo 2 de Servlets y
JSP, ofreciendo mecanismos para facilitar la integración con otras
herramientas para la implementación de las capas de negocio y
presentación. Gutierrez (s.f)
46
2.2.13 Codeigniter
Según EllisLab (2011), CodeIgniter, es un entorno de desarrollo rápido,

con un grupo específico de herramientas para programadores que generan
aplicaciones en lenguaje PHP. Es distribuido bajo licencia de código abierto.
CodeIgniter es un framework para aplicaciones web de código abierto;

muy útil para crear sitios web dinámicos con PHP. Su objetivo es permitir que
los desarrolladores puedan realizar proyectos mucho más rápido que
creando toda la estructura desde cero, brindando un conjunto de bibliotecas
para tareas comunes, así como una interfaz simple y una estructura lógica
para acceder esas bibliotecas
2.2.14 Arquitectura MVC (Model-View-Controller)
Según Márquez (s.f). El patrón Modelo Vista Controlador es una

arquitectura de diseño de software para separar los componentes de la
aplicación en tres niveles: interfaz de usuario, lógica de control y lógica de
negocio. Es una especialización de un modelo de capas, con la diferencia
que se usa para entornos web como patrón por excelencia. Ejemplo: Struts,
Spring, Asp.NET MVC.
 Modelo: es la capa encargada de encapsular toda la lógica de negocio de

nuestra aplicación. Esta capa se puede subdividir en varias:
 Lógica de Negocio: contiene clases para constituir lo referente a la

aplicación, se encarga de atender a las peticiones de los
controladores y así dar una respuesta acorde con lo recibido.
47
 Capa de Datos: se encarga de gestionar toda la interconexión con el

Sistema de Gestor de Base de Datos, así mismo, puede contener un
gestor de Mapeo Objeto-Relacional (ORM) para su aprovechamiento
máximo y mejor mantenimiento. Solo se comunica con la lógica de
negocio.
 Helpers: llamados “ayudantes” apoyan tanto al controlador como a la

vista para hacer más livianas algunas tareas.
 Controlador: es el eje central de nuestra arquitectura, encargada de

gestionar todas las peticiones, validar los inputs recibidos y dirigir
cualquier petición de cualquier tipo. Solo se comunica con el modelo y
responde a través de vistas.
 Vista: es la respuesta de cada controlador y lo que se le presenta al

usuario final, se puede comunicar con el controlador, los “helpers” y el
modelo (en algunas ocasiones).
2.2.15 Sistema Integral de Gestión Automatizada para la Gerencia AIT

(SIGA-AIT)
El proyecto SIGA-AIT nace del requerimiento de PDVSA de diseñar y

desarrollar una aplicación única que permita la administrar sus funciones
principales en forma automatizada, basada en modelos de procesos. El
sistema Integral de Gestión Automatizada está desarrollada bajo los
estándares de software libre. Esta herramienta informática proporciona
respuestas rápidas y eficaces a los requerimientos de los usuarios y
trabajadores acortando el tiempo de los procesos de trabajo y la resolución
de problemas a través del sistema. El sistema SIGA-AIT fue desarrollado por
48
analistas y programadores de la región oriental, con la asesoría de

especialistas de la Universidad de Oriente. (Figueroa, 2007).
2.2.16 Nagios
Según Mariscal (2011). Nagios es un sistema de monitorización SNMP

open source. Monitorea los hosts y servicios que se especifiquen, alertando
cuando algo sale mal y nuevamente cuando está bien. Nagios fue
originalmente diseñado para ser ejecutado en Linux, pero también se ejecuta
bien en variantes de Unix. Está licenciada bajo la GNU General Public
License Version 2 publicada por la Free Software Fundation.
 Monitoreo de servicios de red (SMTP, POP3, HTTP, NTTP, ICMP, SNMP).
 Monitoreo de los recursos de un host (carga del procesador, uso de los

discos, logs del sistema) en varios sistemas operativos, incluso Microsoft
Windows con el plugin NRPE_NT
 Monitoreo remoto, a través de túneles SSL cifrados o SSH.
 Diseño simple de plugins, que permiten a los usuarios desarrollar sus

propios chequeos de servicios dependiendo de sus necesidades, usando
sus herramientas preferidas (Bash, C++, Perl, Ruby, Python, PHP, C#,
etc.).
 Chequeo de servicios paralizados.
 Posibilidad de definir la jerarquía de la red, permitiendo distinguir entre

host caídos y host inaccesibles.
49
 Notificaciones a los contactos cuando ocurren problemas en servicios o

hosts, así como cuando son resueltos (vía email, pager, SMS, o cualquier
método definido por el usuario junto con su correspondiente plugin).
 Posibilidad de definir manejadores de eventos que ejecuten al ocurrir un

evento de un servicio o host para resoluciones de problemas proactivas. •
Rotación automática del archive de log.
 Soporte para implementar host de monitores redundantes.
 Interfaz web opcional, para observar el estado de la red actual,

notificaciones, historial de problemas, archivos de logs, etc.
2.2.17 Protocolo Simple de Administración de Red (SNMP)
Según Mariscal (2011). El SNMP es un protocolo de la capa de

aplicación de la suite de protocolos TCP/IP, que facilita el intercambio de
información administrativa entre dispositivos de red a fin de que los
administradores puedan supervisar el desempeño de la red, buscar y
resolver sus problemas, y planear su crecimiento. Con SNMP se puede
monitorear el estado de un enlace punto a punto para detectar cuando está
congestionado y tomar así medidas oportunas, se puede hacer que una
impresora alerte al administrador cuando se ha quedado sin papel, o que un
servidor envíe una alerta cuando la carga se incrementa significativamente.
SNMP también permite modificar remotamente la configuración de
dispositivos, de forma que se pueden cambiar las direcciones IP de un
sistema a través de su agente SNMP, u obligar a la ejecución de comandos
(si el agente ofrece las funcionalidades necesarias).
50
2.3 Descripción del Sistema
2.3.1 Petróleos de Venezuela, S.A. (PDVSA)
Es una compañía propiedad de la República Bolivariana de Venezuela,

creado por el Estado venezolano en 1975, en cumplimiento de la Ley
Orgánica que reserva el Estado, la industria y el comercio de hidrocarburos
(Ley de Nacionalización). Sus operaciones son supervisadas y controladas
por el Ministerio del Poder Popular para la Energía y Petróleo (MEMPET).
Esta empresa es responsable del desarrollo de la industria de los

hidrocarburos, así como también, de planificar, coordinar, supervisar y
controlar las actividades relacionadas con la exploración, la explotación, la
manufactura, la refinación, el transporte por medios especiales y las ventas
de hidrocarburos y sus derivados, tanto en Venezuela como fuera del país.
2.3.2 PDVSA Refinación Oriente
En el Oriente del territorio nacional Petróleos de Venezuela cuenta con

la refinería de Puerto La Cruz con una capacidad de procesamiento de 192
MBD.
La Refinería Puerto La Cruz está ubicada en el norte y centro del

estado Anzoátegui, Venezuela. Este complejo abarca dos áreas
operacionales: Puerto La Cruz, la cual cuenta con una capacidad de 192
MBD (Millones de Barriles Diarios) y San Roque con una capacidad nominal
de 5 MBD.
51
Los productos obtenidos en este complejo de Refinación (Gasolinas,

Jet, Diesel, Nafta liviana, GLP y Parafina) se destinan en un 46% al mercado
doméstico local y la producción excedente (54%) se destina al mercado de
exportación, dirigida principalmente a los países del Caribe, Centro América,
Sur América y Europa.
En las adyacencias de esta refinería se encuentra el edificio Sede

Guaraguao, en el cual se llevan a cabo funciones de planificación, desarrollo
y coordinación de actividades de diferentes índoles que permiten el buen
funcionamiento de la empresa. Dentro de estas prioridades está garantizar
un correcto funcionamiento en cuanto a rendimiento y seguridad operacional
de los equipos y sistemas que funcionan bajo su dominio.
2.3.3 Reseña Histórica de la Gerencia AIT
La Gerencia de Automatización, Informática y Telecomunicaciones

(AIT) nace a raíz de los sucesos de diciembre de 2002 cuando el encargado
de suministrar los servicios de tecnología informática y redes INTESA, se
unió al paro petrolero ocurrido en dicha fecha. Esta gerencia recién formada
ha dedicado sus esfuerzos a mantener la plataforma de informática y
telecomunicaciones de la industria petrolera, sus actividades diarias y de
proyección convergen con todos los negocios de la industria de manera
directa, esto ha ocasionado que la gerencia se divida en gerencia por
procesos.
52
2.3.4 Declaración de la misión y visión de la Gerencia AIT
2.3.4.1 Misión de la Gerencia AIT
Proveer soluciones de automatización, informática y

telecomunicaciones a la corporación incorporando productos y servicios
innovadores, siendo altamente competitivos, ágiles, flexibles y proactivos en
el asesoramiento tecnológico del negocio, creando diferenciación competitiva
y de alto valor, orientados a lograr la soberanía tecnológica e impulsar el
desarrollo endógeno sustentable.
2.3.4.2 Visión de la Gerencia AIT
Ser en PDVSA la organización de tecnología, innovadora,

transformadora e integradora generadora de ventajas competitivas y
comprometida con la visión del país planteada en la constitución de la
República Bolivariana de Venezuela.
2.3.5 Estructura Organizativa
2.3.5.1 Estructura Organizativa de PDVSA Refinación Oriente
A continuación en la figura 2.1 se muestra el organigrama de PDVSA

Refinación Oriente.
2.3.5.2 Estructura Organizativa de la Gerencia AIT Oriente
A continuación figura 2.2 se muestra el organigrama de la Gerencia AIT

Oriente
53
Figura 2.1: Estructura Organizativa de PDVSA Refinación Oriente

Fuente: PDVSA (2017).
Figura 2.2: Estructura Organizativa de la Gerencia AIT Oriente

CAPITULO III
MARCO METODOLÓGICO
3.1 Tipo de Investigación
Según lo expresado por Arias (2004), el tipo de investigación de este

proyecto será de campo debido a que la recolección de datos se realizará
directamente en el sistema de estudio, para ser más específico en el
departamento de soporte básico de la Gerencia AIT. Razón por la cual la
información obtenida será confiable y sin ningún tipo de perturbaciones.
3.2 Nivel de la Investigación
El nivel de investigación según Arias (2004), será de tipo descriptivo

debido a que se estudiara la estructura y el comportamiento de los procesos
y actividades que involucran el mantenimiento de la plataforma de escritorio,
con el objetivo de encontrar una solución a la problemática.
3.3 Técnicas a Utilizar
Para llevar a cabo la recolección de la información se utilizaran las

siguientes técnicas:
 Análisis y Revisión Bibliográfica: esta técnica es de gran importancia

para el desarrollo inicial del proyecto, debido a que utilizarán
metodologías, bases teóricas y antecedentes que se encontrarán en
materiales bibliográficos como: tesis de grado, libros y documentos
digitales. Además se analizarán las normas y procedimientos utilizados
por la empresa, para definir los lineamientos en el desarrollo del software.
55
 Observación Directa: esta técnica permitirá visualizar, determinar y

documentar, cómo se realizarán las actividades y procesos en la Gerencia
AIT, y de esta forma comprender de una mejor manera la problemática
existente, con la finalidad de describir la situación actual de la plataforma
de escritorio.
 Entrevista No Estructurada: se manejará con preguntas abierta y serán

dirigidas a los analistas de soporte básico, de forma verbal con la
finalidad de obtener información adicional de la situación actual de la
plataforma de escritorio, así como también de sus operaciones y otros
procesos que sean de interés, con el fin de establecer los requisitos
funcionales del nuevo sistema de información.
 Lenguaje de Modelado Unificado (UML: Unified Modeling

Language): a través de la utilización de los diferentes diagramas como el
modelo de dominio que permitirá modelar el contexto del sistema, el del
casos de uso que permitirá identificar y documentar los requisitos
funcionales del sistema, y los diagramas de clase de diseño, clase de
análisis y colaboración, se facilitará la visualización, especificación y
documentación de la estructura del software.
CAPITULO IV
RESULTADOS
4.1 Fase de Inicio
En esta etapa se desarrollará la primera fase del proceso unificado de

desarrollo de software (RUP); donde se hace un plan de fases, se identifican
los principales casos de uso y riesgos del sistema a desarrollar, permitiendo
esto establecer los requisitos que debe cumplir la aplicación y elaborar el
conjuntos de modelos que describirán el comportamiento de la misma.
La fase de inicio es la más importante, ya que es aquí donde se

establece un acuerdo entre todos los interesados acerca de los objetivos del
proyecto. Esta fase es significativamente primaria para el desarrollo de nuevo
software, ya que se asegura de identificar los requerimientos y los riesgos
relacionados con el negocio. A continuación en la figura 4.1 se ilustra el
Proceso Unificado de Desarrollo de Software, resaltando la Fase de Inicio.
Figura 4.1: Fase de Inicio

Fuente: Rumbaugh, Jacobson y Booch, (2000).
57
4.1.1 Descripción del Sistema Actual
El modelo de servicio de la Gerencia AIT, está conformada por 4 niveles

de servicios (Nivel 0 al Nivel 3), que coordinan las actividades que se les
brindan a los usuarios y equipos, la gestión y el control de estos niveles es
realizado por diferentes departamentos de la Gerencia AIT, además existen
diferentes sistemas informáticos que llevan un registro de estos servicios. Si
una solicitud o requerimiento no puede ser resuelto por un nivel, este
requerimiento pasa a un nivel superior hasta que se logre solucionar el
problema. Para ser más específico en la figura 4.2se el modelo de servicio
de la Gerencia AIT.
Figura 4.2: Modelo de servicios de la Gerencia AIT

58
Funcionamiento
Nivel 0:
Es la plataforma automatizada de atención al usuario, esta se encuentra
dentro de las labores de Centro de Servicio de AIT, los casos se crean, por
cualquier equipo que genere una alarma a CIMOR (Centro Integral de
Monitoreo Oriente), como por ejemplo: un servidor, un PLC (Controlador
Lógico Programable), una Estación de Trabajo, entre otros.
Los Usuarios PDVSA, utilizan varios sistemas automatizados como son

el Sistema de Autoservicios AIT y el Sistema de Autogestión AIT, que se
encargan de atender solicitudes recurrentes de los usuarios como: mudanza
de equipos, accesos telefónicos, adquisición y reemplazos de equipos,
emisión de pases de seguridad de equipos, recuperación de claves, entre
otras. También los usuarios PDVSA pueden recibir ayuda a través del IVR
(Repuesta de voz Interactiva), que permite interactuar con el usuario
mediante grabaciones de voz y reconocimiento de respuestas simples, o
generar una solicitud directamente al nivel 2.
Nivel 1:
Atención de Solicitudes al Centro de Servicio AIT. Los usuarios efectúan
sus solicitudes a través de la línea telefónica de la extensión 105, donde son
atendidos por un analista del Centro de Servicio. El analista lo identifica,
valida sus datos, identifica y describe la solicitud en SIGA-AIT (Sistema
Integral de Gestión Automatizada para la Gerencia AIT), verifica si es posible
una solución en línea; de ser positivo, cierra un caso en primer nivel; de lo
contrario, el caso es generado y escalado a un segundo nivel para su
atención.
59
Otra opción que posee el usuario para la canalización de su solicitud es

mediante el envío de un correo electrónico al correo serviciosori@pdvsa.com
mediante esta opción, se atienden básicamente aquellas solicitudes que
requieren de niveles de aprobación o autorización.
Monitoreo de la Plataforma AIT, está conformado por El Centro Integral

de Monitoreo Oriente (CIMOR), que tiene como objetivo principal, la
evaluación y monitorización constante de las condiciones en que se
encuentran los componentes tecnológicos de la corporación, con el fin de
generar alertas puntuales y oportunas. Cuando un equipo presenta una falla
el sistema Nagios genera una alerta, dichas alarmas son inspeccionadas por
los analistas de CIMOR que pueden generar un caso hacia el nivel 2.
Nivel 2:
El Soporte Técnico de los Servicios AIT, se ejecuta el soporte
operacional a las diferentes Aplicaciones, Sistemas de Automatización,
Telefonía, Radios Móviles e Infraestructura de PDVSA. Está conformado por
los analistas de Soporte Básico, Soporte Especializado, Planta externa y
Automatización que se encargan en acudir al lugar donde ocurren la fallas
para poder solventarlas. Si el problema que se presenta requiere un cambio
de una pieza o parte del equipo se genera un caso hacia control de activos.
Nivel 3:
Gestión de Requerimientos realiza los procesos asociados a la procura,
asignación, mantenimiento y desincorporación de los activos, que conforman
la plataforma tecnológica soportada por la Gerencia AIT, a lo largo de su ciclo
de vida, cumpliendo con los niveles de servicio acordados y adoptando las
mejores prácticas, normas y estándares existentes, para asegurar la
continuidad operativa.
60
Control de Activos se encarga de conceder las partes y piezas que

requiera algún equipo. Un equipo puede generar solicitudes hacia otras
áreas como por ejemplo hacia una consultoría de un equipo especializado
que necesite un usuario y esto crea una auditoria para saber las
especificaciones de dicho equipo para posteriormente adquirirla. Por otro
lado Control de Activos se encarga también de la asignación,
desincorporación de los activos a lo largo de su ciclo de vida.
Gestión de la plataforma ejecuta, administra y controla los procesos

asociados a la estandarización de la plataforma tecnológica, cumpliendo con
los niveles de servicio acordados, adoptando las mejores prácticas, normas y
estándares existentes. Pruebas de equipos nuevos, configuración de
políticas de seguridad, imágenes ISO en donde se almacenan la información
de todo un sistema de archivo de un sistema operativo son funciones que
cumple la gestión de la plataforma.
La planificación de Mantenimiento de la plataforma se encarga

principalmente de garantizar la continuidad operativa de la plataforma
tecnológica de la Gerencia AIT, maximizar los tiempos de vida útil de los
activos y adecuar los recursos tecnológicos de AIT a las necesidades del
negocio.
Control de cambio y configuración administra y coordina los cambios

solicitados y/o planificados que estén relacionados con la plataforma
tecnológica de PDVSA, garantizando que las tareas contenga toda la
información necesaria para su evaluación adecuada y correcta.
61
4.1.2 Modelo de Dominio
Un modelo de dominio captura los tipos más importantes de objetos en

el contexto del sistema. Los objetos del dominio representan las “cosas” que
existen o los eventos que suceden en el entorno el que se trabaja el sistema,
el modelo de dominio se describir mediante Diagramas UML.
Estos diagramas muestran a los clientes, usuarios revisores y a otros

desarrolladores las clases del dominio y como se relacionan unas con otras
mediante asociaciones. El objetivo del modelado de dominio es comprender
y describir las clases más importantes dentro del contexto del sistema.
4.1.2.1 Glosario de Términos
Podemos utilizar un glosario de términos para definir términos comunes

que los analistas y otros desarrolladores utilizan al describir el sistema. Un
glosario es muy útil para alcanzar un consenso entre los desarrolladores
relativo a la definición de los diversos conceptos y nociones, y para reducir
en general el riesgo de confusiones Habitualmente un glosario de términos
se obtiene a partir de un modelo de negocios o un modelo de dominio. En la
tabla 4.1 se describen cada uno de los términos utilizados en el sistema.
Tabla 4.1: Glosario de Términos (1/2)

Termino Descripción
Caso Es el número de la orden de servicio requerida por el
usuario. Dicha orden puede ser clasificada en problema,
consulta o requerimiento.
Usuario Son los empleados de PDVSA que realizan alguna
solicitud.
Componente Es la parte de un equipo o sistema.
Fuente: Elaboración Propia
62
Tabla 4.1 Glosario de Términos (2/2)

Termino Descripción
Sistemas de Sistemas automatizados que ayudan a resolver algún
Autogestión y problema cotidiano que presente algún usuario sin la
Autoservicios intervención de algún analista del Centro de Servicio.
Analista de Personal encargado de la visualización,
CIMOR documentación, localización y notificación oportuna
de eventos al personal de soporte técnico y
mantenimiento.
Plataforma AIT Son el conjunto de equipos y servicios que conforman
la plataforma tecnológica de PDVSA.
Nagios Sistema que se encarga de monitorear los equipos
pertenecientes a la plataforma de AIT
(Automatización Informática y Telecomunicaciones)
Servicios Comunes Oriente.
Falla Condición anormal o fuera de los parámetros
establecidos de algún equipo
Centro de Personal encargado de recibir las solicitudes de los
Servicio usuarios.
Alerta Son alarmas que muestra el sistema Nagios cuando
un componente de un equipo está fuera de los
parámetros normales de funcionamiento.
Analista de Personal encargado de mantener en funcionamiento
Soporte Técnico la plataforma de escritorio. Está conformado por los
analistas de Soporte Básico, Soporte Especializado,
Automatización y Planta Externa.
Control de Activo Se encarga de velar por la integridad de los equipos
en todo el ciclo de vida del mismo suministrando las
partes y piezas según sea su caso.
Fuente: Elaboración Propia.
4.1.2.2 Diagrama Dominio de Sistema
Un usuario PDVSA puede generar una o muchas solicitudes hacia los

sistemas de autogestión y autoservicios (IVR, Correo, Web), así como
también puede generar una o muchas solicitudes hacia el centro de
servicios, el centro de servicio puede realizar uno o muchas solicitudes de un
componente de un equipo a Control de Activos.
63
La plataforma AIT genera una o muchas fallas que afectan uno o

muchos componentes de un equipo o sistema, la caída de algún componente
genera una alerta que detecta el sistema de monitoreo Nagios, una alerta la
atiende uno u muchos analista de CIMOR que genera uno o muchos casos,
estos casos los atiende uno o muchos analistas de Soporte Técnico
(analistas de Soporte Básico, analista de Soporte Especializado, planta
externa y Automatización).Cuando algún caso requiere algún componente
especial el analista de soporte técnico puede realizar uno o muchos
solicitudes, hacia Control de Activos. Para ser más específicos en la figura
4.3 se ilustra el diagrama de dominio descrito anteriormente.
Figura 4.3: Diagrama del Dominio del Sistema

4.1.3 Diagrama de Sistema y Ambiente Ampliado
El ambiente interno está conformado por los analistas de Soporte

Básico encargado del mantenimiento correctivo de la plataforma de escritorio
y de impresión, Soporte Especializado encargado del mantenimiento
64
correctivo de la plataforma de escritorio especializada conformada por las

estaciones de trabajo y Planta Externa que realiza mantenimiento del
cableado estructurado y telefonía.
El ambiente externo-interno está conformado por todas aquellas

personas que laboran en PDVDA y cumplen funciones de supervisión,
control, administrativas, entre otras; pero no poseen contacto directo con el
mantenimiento de la plataforma de escritorio.
El ambiente externo está compuesto por todas aquellas dependencias

que no forman parte de la empresa pero que afectan de manera directa o
indirecta su funcionamiento.
A continuación será más preciso mostrar en la figura 4.4 el diagrama

de sistema y ambiente ampliado
Figura 4.4: Diagrama de Sistema y Ambiente Ampliado

65
4.1.4 Descripción de la Problemática
 El sistema de monitoreo Nagios no cuenta con ninguna base de datos

que permita consultar fácilmente la información.
 SIGA-AIT tiene fallas en las relaciones de las tablas que impiden que el
número de caso no este asociado al código del equipo.
 No existe en PDVSA ningún sistema que gestione el mantenimiento

preventivo de la plataforma de escritorio.
 Los procesos del cambio de consumibles de los servicios de impresoras

se registran en hojas de cálculos, lo cual involucra perdida de
información.
 El módulo de mantenimiento SIGA-AIT no está completamente

desarrollado.
 Algunos equipos de la plataforma de escritorio no cuentan con ningún

código de equipo.
 Las tareas de mantenimiento preventivo de la plataforma de escritorio se

están aplicando mas no quedan registradas.
 Los sistemas informáticos de PDVSA no están relacionados entre ellos,

provocando que el control y gestión de la plataforma de escritorio estén
fragmentada en diferentes sistemas informáticos.
4.1.5 Flujo de Trabajo de Requisitos
El propósito fundamental del flujo de trabajo de requisitos es guiar el

desarrollo al sistema correcto. Esto se consigue mediante una descripción de
66
los requisitos del sistema (es decir, las condiciones o capacidades que el
sistema debe cumplir) suficientemente buena como para pueda llevarse a un
acuerdo entre el cliente (incluyendo los usuarios) y los desarrolladores sobre
que debe y que no debe hacerse en el sistema.
4.1.5.1 Contexto del Sistema
Existen dos aproximaciones para expresar el contexto de un sistema en

una forma utilizable para desarrollo de software el modelado del dominio y
modelado de negocio.
Para conocer el modelo de dominio de la Gerencia AIT se utilizaron

diferentes métodos para la recolección de la información necesaria para el
desarrollo del sistema de información web. Entre ellos tenemos:
La observación, en el cual se pudieron comprender las diferentes

actividades que se realizan en la Gerencia AIT, específicamente en el
departamento de Soporte Básico y el Centro Integral de Monitoreo Oriente
(CIMOR), en el cual se logró recopilar la información necesaria para la
elaboración del modelo de dominio. También se empleo de entrevistas no
estructuradas a los diferentes analistas de Soporte Básico y a los analista de
Planificación y Programación de Mantenimiento (PPM), con el propósito de
reunir información general proveniente de personas interesadas en el nuevo
sistema.
La revisión del material bibliográfico en internet, libros, tesis, manuales

y procedimientos de la empresa, relacionados con el proceso de negocio de
PDVSA y del desarrollo del software.
67
Requisitos Esenciales del Sistema
 Almacenar en la bases de datos, la información suministrada por Nagios

referente a los servicios de Impresión.
 Autentificar al usuario con el “Domain Controller ”para el acceso al

sistema.
 El sistema tiene que interoperar con el Sistema Integral de Gestión

Automatizada para la Gerencia AIT (SIGA-AIT).
 Implementar niveles de accesos, que permitan el ingreso de los usuarios,

de acuerdo a los privilegios que posean.
 Generar reportes.
 El software debe cumplir con los estándares de la Gerencia AIT y validar

la informacion registrada por los usuarios.
 El software debe validar la información registrada por los usuarios.
 Permitir a los usuarios del sistema almacenar los datos necesarios para
llevar el control y gestión del mantenimiento preventivo que requiera el
departamento de Soporte Básico.
Identificación de los actores
Los actores son personas, sistemas o hardware externo que interactúan

con el sistema. Pueden proveer funcionalidades al sistema, así como utilizar
las ya provistas por éste, por tanto pueden ingresar o capturar datos al
sistema.
68
A continuación en la tabla 4.2 se muestra los actores del sistema
Tabla 4.2: Actores del Sistema

Actor Descripción
Administrador Actor encargado del control del sistema, tiene acceso a
todos los módulos del sistema
Analista de Actor encargado realizar los mantenimientos
Soporte Técnico planificados a los equipos y visualizar funciones
básicas del sistema.
Supervisor de Actor encargado de planificar y crear tareas de
Soporte Técnico mantenimiento a los equipos y visualizar los reportes
oficiales del sistema
Nagios Sistema de monitoreo que se encarga de monitorear el
estado de la plataforma de escritorio de la Gerencia
AIT.
SIGA-AIT Representa al Sistema Integral de Gestión
Automatizada para la Gerencia AIT. Este sistema
permite dar una solución a cualquier requerimiento o
incidente de un equipo o solicitud del usuario.
Directorio Activo Componente de la base de datos propia de PDVSA,
PDVSA encargado de autentificar a un usuario en la red de la
empresa.
Analista de Actor encargado de gestionar los módulos de activo del
Activos sistema
Planificador de Actor encargado de planificar los mantenimientos y
Mantenimiento gestionar los módulos de mantenimiento del sistema
Requisitos Funcionales del Sistema
La técnica inmediata para identificar los requisitos del sistema se basa

en los casos de uso:
 Mostrar los Activos de la plataforma de escritorio
 Gestionar los tipos de Activos y Clases de Activos
 Registrar el mantenimiento
69
 Planificar los mantenimientos tomando en cuenta la frecuencia.
 Consultar los históricos de monitoreo de Nagios
 Crear tareas y tipos de Mantenimiento
 Registrar los materiales y herramientas necesarias para el

mantenimiento
 Gestionar la Configuración de Usuarios, los roles del usuario y su

acceso a los módulos
 Realizar consulta y generar reportes de la información almacenada
Requisitos no Funcionales del Sistema

Especifican propiedades del sistema, como restricciones del entorno o
de la implementación, rendimiento, dependencia de la plataforma, facilidades
de mantenimiento, extensibilidad y fiabilidad. En la tabla 4.3 se describen los
requisitos no funcionales del sistema
Tabla 4.3: Requisitos no Funcionales del Sistema (1/2).

Requisito no Descripción
Funcional
Accesible La aplicación debe estar disponible en todo momento
para los usuarios autorizados
Amigable La aplicación debe ser fácil de comprender y manejar por
el usuario, es por ello que el diseño de la interfaz del
usuario debe poseer una estructura amigable.
Plataforma El sistema debe ser implantado en un servidor Linux.
de Hardware
Requisitos de El sistema debe estar desarrollado utilizando tecnología
Software de software libre en cumplimiento al decreto 3390
70
Tabla 4.3: Requisitos no Funcionales del Sistema (2/2).

Requisito no Descripción
Funcional
Eficiencia Debe agilizar los procesos cotidianos para lograr
aumentar la productividad en el trabajo realizado, y
disminuir los tiempos de ocio ocasionados por el retardo
en la respuesta del sistema actual.
Extensible El software debe permitir la incorporación de nuevas
funcionalidades en su estructura. Debe estar apto para el
ingreso de futuras ampliaciones y el soporte de mayor
cantidad de datos a través del tiempo.
Mantenible El administrador del sistema puede modificar o actualizar
aspecto del sistema cuando se requiera para así
garantizar su mantenimiento.
Transferencia Que sea accesible a una revisión por alguien distinto a
quien lo ha creado. Que la documentación del sistema
sea clara y precisa.
Identificación de los riesgos del sistema
Para el desarrollo del sistema se identificaron y analizaron todos

aquellos factores que podrían afectar el proyecto y por lo tanto poner en
riesgo su desarrollo. A continuación en la tabla 4.4se muestran los posibles
factores de riesgo.
Tabla 4.4 Identificación de los riesgos del sistema (1/2)
Descripción Nivel de Responsable Contingencia
Impacto
Ingreso de datos Critico Desarrollador Validar cada uno de los
erróneos por formularios, mostrando
parte del usuario mensaje de error
cuando sea necesario
Incompatibilidad Muy Critico Desarrollador Diseñar el modelo físico
con la base de de la base de datos en
datos PostgreSQL
71
Tabla 4.4 Identificación de los riesgos del sistema (2/2)

Descripción Nivel de Responsable Contingencia
Impacto
Incompatibilidad Muy Critico Desarrollador Desarrollar el sistema
con los en un sistema operativo
servidores Linux
La Gerencia AIT, Critico PDVSA, Desarrollar el software
se niega poner en Desarrollador siguiendo los
producción el estándares, de diseño,
sistema programación y
seguridad establecidos
por el departamento de
Aplicaciones
Los usuarios del Moderado Desarrollador, Involucrar a los usuarios
sistema se Usuarios finales en el desarrollo
resisten a usar el del sistema, siguiendo
sistema las sugerencias e ideas
en el desarrollo de las
interfaces.
Cambios de Moderado PDVSA Mantener constante
última hora en los comunicación con los
requisitos del interesados del proyecto
software e identificar
correctamente y las
necesidades de los
clientes en la fase de
inicio
El tiempo Moderado Desarrollador Usar framework que
estimado para el permitan el agilizar el
proyecto no es desarrollo del software,
suficiente para su así como también
desarrollo dedicarle más horas
hombres a los módulos
que pertenezcan a
aplicaciones externas
72
4.1.5.2 Casos de Uso del Sistema
Para el usuario un caso de uso es un modo de utilizar el sistema. En

consecuencia, si los analistas pueden describir todos los casos de uso que
necesita el usuario, entonces saben lo que debe hacer el sistema. Cada
usuario necesita varios casos de uso de los cuales representan el modo de
los cuales él o ella utilizan el sistema. La captura de los casos de uso
requiere que conozcamos en profundidad las necesidades del usuario y del
cliente. Para hacerlo tenemos que comprender el contexto del sistema,
entrevistar a los usuarios, discutir propuestas, entre otras. En la tabla 4.5 se
describen y se identifican los casos de uso del sistema.
Tabla 4.5: Casos de Uso del Sistema (1/2)

Caso de Uso Descripción
Login Este caso de uso valida el acceso al sistema a
través del Directorio Activo PDVSA y los privilegios
que tenga el usuario en el sistema.
Clase de activos Permite ingresar, editar, buscar y eliminar las
clases de activos que conforman la plataforma de
escritorio
Tipo de activos Permite ingresar editar, buscar y eliminar los tipos
de activos que conforman la plataforma de
escritorio.
Listado de Activos Este caso permite visualizar y editar algunas
características de los equipos que conforman la
plataforma de escritorio.
Registro de Caso de uso que permite registrar los
Mantenimiento mantenimiento a los equipos
Planificación de Caso de uso que permite controlar y planificar los
Mantenimiento mantenimiento a los equipos
Tareas de Este caso de uso permite ingresar, editar, eliminar,
Mantenimiento buscar y agregar las herramientas y materiales a
las tareas de mantenimiento
73
Tabla 4.5: Casos de Uso del Sistema (2/2)

Tipos de Permite ingresar, modificar, eliminar y buscar los
Mantenimiento diferentes tipos mantenimiento
Frecuencia Permite la inserción, modificación y eliminación de
las frecuencia
Herramientas y Permite ingresar y modificar las herramientas de
Materiales mantenimiento.
Nagios Este caso de uso permite visualizar el registro
histórico de los parámetros de impresión de los
servicios de impresión.
Configuración de Este caso de uso permite ingresar nuevos usuarios
Usuarios así como también cambiar los tipos de acceso a
cada usuario del sistema
Roles de Usuarios Caso de uso que permite ingresar y modificar los
roles de acceso que poseen los usuarios
Módulos Caso de uso que permite identificar a los módulos
del sistema para identificación de los accesos al
sistema.
Reportes Oficiales Permite la visualización e impresión de la
información referente a los diferentes casos de uso
del sistema.
4.1.5.3 Modelo de Casos de Uso
El modelo de casos de uso permite que los desarrolladores de software

y los clientes lleguen a un acuerdo sobre los requisitos funcionales del
sistema, es decir, sobre las condiciones y posibilidades que se debe cumplir.
El modelo de casos de uso sirve como un acuerdo entre clientes y
desarrolladores, y proporciona, y proporciona la entrada fundamental para el
análisis, el diseño y las pruebas. El modelo de casos de uso es un modelo
del sistema que contiene actores, casos de uso y sus relaciones. En la figura
4.5 se ilustra el modelo de caso de uso obtenido en la fase de inicio
74
Figura 4.5: Modelo de Caso de Uso General del Sistema

Fuente: Elaboración propia.
75
4.1.5.4 Descripción de los Casos de Uso
La descripción de los casos de uso del sistema, son mostrados desde la

tabla 4.6 hasta la tabla 4.20. En esta sección se describen los actores
involucrados, las precondiciones, las descripciones, flujo de eventos
principales y alternos de cada caso de uso.
 Login
En la figura 4.6 se ilustra el Caso de Uso Login
Figura 4.6: Diagrama del Caso de Uso Login.

Tabla 4.6: Casos de Uso Login (1/2)

Actores Analista de Soporte Técnico, Analista de Activo,
Supervisor de Soporte Técnico, Planificador de
Mantenimiento, Administrador y Directorio Activo PDVSA.
Descripción Este caso de uso valida el acceso al sistema a través del
Directorio Activo PDVSA y los privilegios que tenga el
usuario en el sistema.
Pre- Acceder al sistema
Condición
76
Tabla 4.6: Casos de Uso Login (2/2)

Flujo de Pasos Descripción
Eventos
Flujo 1 El actor ingresa al sistema a través de la
Principal dirección URL
2 El sistema muestra el interfaz correspondiente,
donde aparece el formulario de inicio de sesión.
3 El actor ingresa su indicador y clave PDVSA.
4 El sistema verifica la información suministrada y
permite el acceso al mismo.
Flujo 1 En el paso 3 el usuario no ingreso el usuario o
Alternativo contraseña el sistema indicara que es un campo
obligatorio
2 En el paso 4 si el indicador del usuario no existe
en el Directorio Activo PDVSA o no tiene los
privilegios, el sistema muestra un mensaje de
error que el usuario o contraseña es invalido
3 La conexión con la base de datos o al Directorio
Activo PDVSA falla en cualquier momento.
 Clases de Activos
En la figura 4.7 se ilustra el diagrama del Caso de Uso Clases de

Activos
Figura 4.7: Diagrama del Caso de Uso Clases de Activos

77
Tabla 4.7: Caso de Uso Clases de Activos (1/2)

Actores Administrador y Analista de activos.
Descripción Permite crear modificar, buscar y eliminar las clases de
activos que conforman la plataforma de escritorio.
Pre- Los actores deben acceder al sistema, luego darle click
Condición en el menú desplegable, en la opción clases de activos.
Eventos
Flujo A El actor rellena el formulario para ingresar un
Principal registro.
1 El actor selecciona el botón ingresar
2 El sistema almacena los datos
permanentemente
3 El sistema informa que los datos fueron
guardados correctamente.
B El actor selecciona la opción editar
1 Se selecciona la clase de activo a modificar de
la tabla
2 El sistema despliega un formulario del recurso
informático.
3 El actor aprieta la opción editar y se modifican
los datos deseados
4 El sistema muestra un mensaje que los datos
fueron modificados correctamente
C El actor selecciona la opción eliminar
1 Se selecciona el recurso a eliminar y el sistema
muestra un mensaje preguntando si está seguro
de eliminar el recurso seleccionado
2 El sistema elimina de la base de datos la
información correspondiente del recurso
3 El sistema informa al usuario que los datos se
han eliminado satisfactoriamente.
D El actor ingresa un parámetro de búsqueda
1 El sistema muestra en la tabla, los registros que
coincidan con la búsqueda
78
Tabla 4.7: Caso de Uso Clases de Activos (2/2)

Flujo 1 Mensaje de alerta al introducir un tipo de dato
Alternativo incorrecto, repetido o un campo vacío.
2 El sistema falla en cualquier momento
3 El actor cancela la operación de los pasos B o C
4 El actor cierra el sistema o la sesión de usuario.
 Tipos de Activos
En la figura 4.8 se ilustra el diagrama del Caso de Uso Tipos de Activos
Figura 4.8 Diagrama del Caso de Uso Tipos de Activos.

Tabla 4.8: Caso de Uso Tipos de Activos (1/2)

Actores Administrador y Analista de activos.
Descripción Permite ingresar editar, buscar y eliminar los tipos de
activos que conforman la plataforma de escritorio
Condición en el menú desplegable, y seleccionar la opción tipos de
activos.
Eventos
Principal tipo de activo.
2 El sistema guarda los datos permanentemente
79
Tabla 4.8: Caso de Uso Tipos de Activos (2/2)

Flujo 3 El sistema informa que los datos fueron
Principal almacenados correctamente.
1 Se selecciona el tipo de activo a modificar de la
tabla
informático.
los datos deseados
fueron modificados exitosamente.
muestra un mensaje preguntando si está
seguro de eliminar el recurso seleccionado
han eliminado exitosamente.
3 El actor cancela la operación de los pasos B o

C
 Listados de Activos
En la figura 4.9 se puede observar el Caso de Uso Listados de Activos

80
Figura 4.9: Diagrama del Caso de Uso Listados de Activos.

Tabla 4.9: Caso de Uso Listados de Activos (1/2)
Actores Administrador y Analista de Activo, Analista de Soporte

Técnico, Analista de Soporte Especializado y SIGA-AIT.
Descripción Este caso permite visualizar y editar algunas
características de los equipos que conforman la
plataforma de escritorio.
Condición en el menú desplegable, en la opción “activo” y
seleccionar la opción Listados de Activos.
Eventos
Flujo A El actor selecciona la opción editar
Principal 1 Se selecciona el activo a modificar de la tabla
informático.
los datos deseados
81
Tabla 4.9: Caso de Uso Listados de Activos (2/2)
B El actor ingresa un parámetro de búsqueda

Flujo 1 El sistema muestra en la tabla, los registros que
Principal coincidan con la búsqueda
Alternativo incorrecto.
3 El actor cancela la operación de los pasos A o B
 Planificación de Mantenimiento
En la figura 4.10se ilustra el diagrama de Caso de Uso Planificación de

Mantenimiento
Figura 4.10: Diagrama del Caso de Uso Planificación de Mantenimiento.

Tabla 4.10: Caso de Uso Planificación de Mantenimiento (1/3)

Actores Administrador, Planificador de Mantenimiento, Analista de
Soporte Técnico, Supervisor de Soporte Técnico.
Descripción Caso de uso que permite controlar y planificar los
mantenimiento a los equipos.
82

Condición en el menú desplegable, en la opción “Mantenimiento” y
seleccionar la opción Planificación de Mantenimiento.
Eventos
Flujo A El actor Planifica un mantenimiento.
Principal
1 El actor selecciona un activo de la tabla y
aprieta el botón planifica Mtto.
informático.
3 El actor ingresa la fecha del mantenimiento al
activo asociado
4 El sistema guarda la información en la base de
datos
B El actor reprograma un mantenimiento
aprieta la opción replanificar Mtto.
informático.
3 El actor ingresa la fecha reprogramada
4 El sistema guarda permanentemente los datos
en la base de datos
C El actor realiza un Mantenimiento
aprieta el botón Realizar Mtto.
2 El sistema muestra la interfaz Realizar
Mantenimiento con los datos asociados a ese
activo y tarea de mantenimiento
3 El actor aprieta el botón registrar
4 El sistema guarda los datos en la base de datos
y planifica el próximo mantenimiento según la
frecuencia y el intervalo de tiempo.
1 El sistema muestra en la tabla los resultados
dela búsqueda que coinciden con el parámetro
83

Flujo E El actor edita la frecuencia de mantenimiento a
Principal una tarea
1 Se selecciona el registro de mantenimiento a
modificar
2 El sistema despliega un formulario con los datos
de la frecuencia de mantenimiento
3 EL actor edita la frecuencia y aprieta el botón
editar
4 El sistema guarda los datos y muestra un
mensaje que los datos fueron modificados
exitosamente
3 El actor cancela la operación de los pasos A, B

oC
 Registro de Mantenimiento
En la figura 4.11 se ilustra el diagrama de Caso de Uso Registro de

Mantenimiento.
Figura 4.11: Diagrama del Caso de Uso Registro de Mantenimiento

84
Tabla 4.11: Caso de Uso Registro de Mantenimiento

Actores Administrador, Planificador de Mantenimiento, y
Supervisor de Soporte Técnico.
Descripción Caso de uso que permite registrar los mantenimiento a
los equipos.
Condición en el menú desplegable, en la opción “Mantenimiento” y
seleccionar la opción Registro de Mantenimiento.
Eventos
Principal registro de mantenimiento.
1 El actor asigna la tarea de mantenimiento con
su respectiva frecuencia y tipo de
mantenimiento
2 El actor ingresa el serial o activo y aprieta el
botón buscar
3 Se carga en una tabla las tareas disponibles
para el activo y el actor selecciona la de su
preferencia
4 El sistema guarda los datos en la base de datos
3 El actor cancela la operación de los pasos A o B
 Tareas de Mantenimiento
En la figura4.12 se ilustra el diagrama de Caso de Uso Tareas de

Mantenimiento
85
Figura 4.12: Diagrama del Caso de uso Tareas de Mantenimiento.

Tabla 4.12: Casos de Uso Tareas de Mantenimiento (1/2)

Actores Administrador, Supervisor de Soporte Técnico y
Planificador de Mantenimiento.
Descripción Este caso de uso permite ingresar, editar, eliminar, buscar
y agregar las herramientas a las tareas de mantenimiento.
Condición en el menú desplegable la opción Tareas de
Mantenimiento.
Eventos
Flujo A El actor rellena el formulario para ingresar una
Principal tarea de mantenimiento.
almacenados correctamente.
1 Se selecciona la tarea de mantenimiento a
modificar en la tabla
informático que el actor desea modificar
los datos deseados
86
Tabla 4.12: Casos de Uso Tareas de Mantenimiento (2/2)

Flujo Principal 4 El sistema muestra un mensaje que los datos
fueron editados correctamente
de eliminar el registro seleccionado
E El actor selecciona la opción Asignar
herramientas y materiales
1 El actor selecciona la herramienta o material
necesario para ejecutar la tarea.
2 Las herramientas y materiales seleccionados se
agregan en una tabla
3 El actor selecciona la opción guardar
3 El actor cancela la operación de los pasos B o D
 Tipos de Mantenimiento
En la figura 4.13 se ilustra el diagrama de Caso de Uso Tipos de

Mantenimiento.
87
Figura 4.13: Diagrama del Caso Tipos de Mantenimiento.

Tabla 4.13: Casos de Uso Tipos de Mantenimiento (1/2)

Actores Administrador y Planificador de Mantenimiento.
Descripción Este caso de uso permitir operaciones como registrar,
modificar, eliminar y buscar los niveles de
mantenimiento.
Condición en el menú desplegable y seleccionar la opción Tipos
de Mantenimiento.
Eventos
Principal tipo de mantenimiento.
1 Se selecciona el recurso a modificar de la
tabla
2 El sistema despliega un formulario del
recurso informático.
los datos deseados
88
Tabla 4.13: Casos de Uso Tipos de Mantenimiento (2/2)

Flujo 1 Se selecciona el recurso a eliminar y el
Principal sistema muestra un mensaje preguntando si
está seguro de eliminar el registro
seleccionado
1 El sistema muestra en la tabla, los registros
que coincidan con la búsqueda
3 El actor cancela la operación de los pasos B o

C
4 El actor cierra el sistema o la sesión de
usuario.
 Caso de uso Frecuencia
En la figura 4.14 se ilustra el diagrama de Caso de Uso Frecuencia
Figura 4.14 Diagrama del Caso de uso Frecuencia

89
Tabla 4.14: Caso de Uso Frecuencia (1/2)

Descripción Permite la inserción, modificación y eliminación de las
frecuencia
Pre- Los actores deben acceder al sistema, luego darle click en
Condición el menú desplegable y seleccionar la opción frecuencia.
Eventos
Principal registro.
1 Se selecciona la frecuencia a modificar de la
tabla
los datos deseados
C El actor selecciona la opción eliminar de la lista
desplegable de la opciones de la tabla
90
Tabla 4.14: Caso de Uso Frecuencia (2/2)

Alternativo incorrecto, repetido o el campo vacío.
 Herramientas y Materiales
En la figura 4.15 se ilustra el diagrama del Caso de Uso Herramientas y

Materiales
Figura 4.15: Diagrama del Caso de uso Herramientas y Materiales.

Tabla 4.15: Casos de Uso Herramientas y Materiales (1/2)

Descripció Este caso de uso permitir operaciones como registrar,
n modificar, eliminar y buscar las herramientas
Condición el menú desplegable y seleccionar la opción Herramientas y
y Materiales.
Eventos
Flujo A El actor rellena el formulario para ingresar una
Principal herramienta.
Tabla 4.15: Casos de Uso Herramientas y Materiales (2/2)
91
Flujo 2 El sistema guarda los datos permanentemente

Principal 3 El sistema informa que los datos fueron
B El actor selecciona la opción editar.
1 Se selecciona el recurso a modificar de la tabla
3 El actor aprieta la opción editar y se modifican los
datos deseados
1 Se selecciona la herramienta a eliminar y el
sistema muestra un mensaje si está seguro de
eliminar el registro seleccionado
3 El sistema informa al usuario que los datos se han
eliminado satisfactoriamente.
Alternativ incorrecto, repetido o el campo vacío.
o 2 El sistema falla en cualquier momento
 Caso de Uso Nagios
En la figura 4.16 se ilustra el diagrama de Caso de Uso Nagios.

92
Figura 4.16: Diagrama del Caso de uso Nagios.

Tabla 4.16: Casos de Uso Nagios

Actores Administrador del sistema
Descripción Este caso de uso permite visualizar el registro histórico de
los parámetros de impresión de los servicios de impresión.
Pre- El actor debe acceder al sistema y seleccionar la opción
Condición Nagios del menú “Históricos” del menú desplegable del
sistema.
Eventos
Flujo A El actor ingresa un parámetro de búsqueda
Principal
1 El sistema muestra los registros que coincidan
con la búsqueda
Flujo 1 El sistema falla en cualquier momento
Alternativo
2 El actor cancela, cierra sesión, o regresa a la
página anterior
3 Los parámetros de búsqueda no coinciden con los
registro de la base de datos
 Caso de Uso Configuración de Usuarios
En la figura 4.17 se puede observar el diagrama de Casos de Uso

Configuración de Usuarios
93
Figura 4.17: Diagrama del Caso de uso Configuración de Usuarios.

Tabla 4.17: Casos de Uso Configuración de Usuarios (1/2).

Actores Administrador
Descripción Este caso de uso permite ingresar nuevos usuarios así
como también cambiar los tipos de acceso a cada usuario
del sistema
Condición el menú desplegable, en la opción “Seguridad” y
seleccionar la opción configuración de usuarios.
Eventos
Flujo A El actor selecciona el botón ingresar
Principal
1 El actor selecciona la opción buscar y se carga la
lista de usuarios de PDVSA
2 El actor selecciona un usuario y aprieta la opción
ingresar
3 El sistema almacena el nuevo registro en la base
de datos
4 El sistema muestra un mensaje que el usuario se
agregó correctamente
1 Se selecciona el usuario a modificar de la tabla
informático.
3 El actor aprieta la opción editar y se modifican los
datos deseados
94
Tabla 4.17: Casos de Uso Configuración de Usuarios (2/2)

Flujo C El actor selecciona la opción eliminar
Principal 1 Se selecciona el recurso a eliminar y el sistema
Flujo 1 Mensaje de alerta al introducir un indicador
Alternativo repetido
 Caso de Uso Roles del Usuario
En la figura 4.18 se puede observar el diagrama de Caso de Uso Roles

del Usuario.
Figura 4.18: Diagrama del Caso de uso Roles del Usuario.

95
Tabla 4.18: Caso de Uso Roles del Usuario (1/2)

Descripción Caso de uso que permite ingresar y modificar los roles de
acceso que poseen los usuarios
Condición en el menú desplegable, en la opción “Seguridad” y
seleccionar la opción Roles del Usuario.
Eventos
Flujo A El actor rellena el formulario para ingresar un rol
Principal de usuario.
1 Se selecciona el rol de usuario a editar de la
tabla
informático.
los datos deseados
96
Tabla 4.18: Caso de Uso Roles del Usuario (2/2)

 Caso de Uso Módulos
En la figura 4.19 se ilustra el diagrama de Caso de Uso Módulos.
Figura 4.19: Diagrama del Caso de uso Módulos del Sistema

Tabla 4.19: Caso de Uso Módulos (1/2)

Descripción Caso de uso que permite identificar a los módulos del
sistema para identificación de los accesos al sistema.
seleccionar la opción tipos de activos.
Eventos
Principal registro.
97
Tabla 4.19: Caso de Uso Módulos (2/2)

Flujo 3 El sistema informa que los datos fueron
Principal almacenados correctamente.
1 Se selecciona el modulo a modificar de la tabla
informático.
los datos deseados
 Reportes Oficiales
En la figura 4.20 se ilustra el diagrama de Caso de Uso Reportes

Oficiales
98
Figura 4.20: Diagrama del Caso de uso Reportes Oficiales.

Tabla 4.20: Caso de Uso Reportes Oficiales

Actores Administrador y Supervisor de Soporte Técnico
Descripción Permite la visualización e impresión de información
importante, guardada en el sistema
Pre- Los actores selecciona la opción “Reportes oficiales” del
Condición menú desplegable del sistema.
Eventos
Flujo 1 Los actores invoca el caso de uso Reportes
Principal oficiales
2 El sistema muestra una interfaz en donde se
permite al actor seleccionar los tipos del reporte
3 El actor selecciona la opción de su preferencia
4 El sistema muestra procesa la opción
seleccionada y muestra una nueva interfaz con el
reporte seleccionado
5 El actor imprime o guarda el reporte seleccionado
Flujo 1 El sistema falla en cualquier momento.
Alternativo
4.1.6 Flujo de Trabajo de Análisis
Los objetivos generales de este flujo de trabajo es analizar los

requisitos, refinarlos y estructurarlos en un modelo de objetos que sirva como
primera impresión del modelo de diseño. En esta fase, el resultado es un
99
modelo inicial, basado en clases de análisis y paquetes. El desarrollo

completo de la línea base de la arquitectura es asunto de la fase de
elaboración, esto significa que solo una parte del modelo de análisis se
completa en la fase de inicio. A continuación en la tabla 4.21 se compara el
modelo de casos de uso con el modelo de análisis.
Tabla 4.21: Comparación entre los modelo de casos de uso y modelo de

análisis
Modelo de Casos de Uso Modelo de Análisis
Descrito con el lenguaje del Descrito con el lenguaje del
cliente desarrollador.
Vista externa del sistema Vista interna del sistema
Estructurado por los casos de Estructurado por clases y paquetes
uso que proporciona la estereotipados, proporciona la
estructura de la vista externa estructura a la vista interna.
Utilizado como contrato entre el Utilizado fundamentalmente por los
cliente y los desarrolladores desarrolladores para comprender
sobre que debería y que no como debería ser la forma del sistema,
debería hacer el sistema es decir, como debería ser diseñado e
implementado.
Puede contener redundancias, No debería contener redundancias,
inconsistencias, entre requisitos, inconsistencias, entre requisitos
Captura la funcionalidad del Emboza como llevar acabo la
sistema, incluida la funcionalidad funcionalidad dentro del sistema,
significativa para la arquitectura. incluida la funcionalidad significativa
para la arquitectura; sirve como una
primera aproximación al diseño.
Define casos de uso que se Define realizaciones de casos de uso,
analizaran con más profundidad y cada una de ellas representa el
en el modelo de análisis. análisis de un caso de uso del modelo
de casos de uso.
100
4.1.6.1 Paquetes de Análisis del Sistema
Proporcionan un medio para organizar los artefactos del modelo de

análisis en piezas manejables. Un paquete de análisis puede constar de
clases de análisis, de realizaciones de casos de uso, y de otros paquetes del
análisis.
Los paquetes de análisis deberían ser cohesivos (es decir, sus

contenidos deberían estar fuertemente relacionados), y deberían ser
débilmente acoplados (es decir, sus dependencias unos de otros deberían
minimizarse). En la figura 4.21 se muestra el Diagrama de paquete del
sistema.
Figura 4.21: Diagrama de Paquetes de Análisis

101
4.1.6.2 Diagrama de Clases de Análisis
Una clase de análisis representa una abstracción de una o varios clases

y/o subsistemas del diseño del sistema. Las clases análisis encajan en uno
de tres estereotipos básicos: de interfaz, de control o de identidad. Cada
estereotipo implica una semántica específica, lo cual constituye un método
potente y consistente de identificar y describir las clases de análisis y
contribuye a la creación de un modelo de objetos y una arquitectura robusta.
 Clase de interfaz: estas clases se utilizan para modelar la interacción

entre el sistema y sus actores (usuarios y sistemas externos). Esta
interacción a menudo implica recibir (y presentar) información y peticiones
de (y hacia) los usuarios y los sistemas externos. Las clases de interfaz
representan a menudo abstracciones de ventanas, formularios, paneles
interfaces de comunicaciones, impresoras, sensores, terminales y API. Es
suficiente que las clases de interfaz describan lo que se obtiene con la
interacción con sus actores y no es necesario que describan como se
ejecuta físicamente la interacción, ya que esto se considera en las
actividades de diseño e implementación subsiguientes.
 Clase de control: los aspectos dinámicos del sistema se modelan con

clases de control, debido a que ellas manejan y coordinan las acciones y
los flujos de control principales y delegan trabajo a otros objetos (es decir,
objetos de interfaz y de entidad). Las clases de control no encapsulan
aspectos relacionados con las interacciones con los actores, ni tampoco
aspectos relacionados con información de larga vida y persistente
gestionada por el sistema; esto lo encapsulan las clases de interfaz y de
identidad respectivamente. En cambio las clases de control encapsulan, y
por lo tanto aíslan, los cambios del control, la coordinación, la secuencia,
102
las transacciones y la lógica del negocio compleja que implica a varios

otros objetos.
 Clase de entidad: las clases de entidad se utilizan para modelar

información que posee una vida larga y que es a menudo persistente. Las
clases de entidad modelan la información y el comportamiento asociado
de algún fenómeno o concepto, como una persona, un objeto del mundo
real o un suceso del mundo real. Los objetos de entidad aíslan los
cambios en la información que representan. Además suelen mostrar una
estructura de datos lógica y contribuyen a comprender de que información
depende el sistema.
A continuación en la tabla 4.22 se identifican y describen cada una de

las interfaces, utilizadas para realizar los diagramas de análisis del sistema.
Tabla 4.22: Descripción de las Clases Interfaz del Sistema (1/2)

Clase interfaz Descripción
IU: Login Esta clase permite ingresar al sistema, introduciendo el
indicador y clave PDVSA.
IU: Clases de Esta clase clases de activos proporciona una interfaz de
Activos usuario que permite hacer uso de las operaciones CRUD
(Create, Read, Update, Delete, por sus siglas en inglés).
IU: Tipos de Esta clase tipos de activos proporciona una interfaz de
Activos usuario que permite hacer uso de las operaciones CRUD
(Create, Read, Update, Delete, por sus siglas en inglés).
IU: Listados de Esta clave permite visualizar el listado de activos de la
Activos plataforma de escritorio así como también modificar
algunas características de estos activos
IU: Registro de Esta clase permite registrar los mantenimientos a los
Mantenimiento equipos.
IU: Esta clase permite planificar el mantenimiento a los
Planificación equipos, modificar fechas de mantenimiento y visualizar
de su estado.
Mantenimiento
103
Tabla 4.22: Descripción de las Clases Interfaz del Sistema (2/2)

IU: Realizar Esta permite visualizar los datos detallados del activo
Mantenimiento que se aplica el mantenimiento.
IU: Tareas de Esta clase permite a los actores realizar las operaciones
Mantenimiento básicas de un CRUD (Create, Read, Update, Delete, por
sus siglas en inglés).
IU: Asignar Esta clase permite asociar los materiales y herramientas
Herramientas y a las tareas de mantenimientos
Materiales
IU: Tipos de Esta clase permite a los actores involucrados insertar,
Mantenimiento editar, eliminar y buscar los tipos de mantenimientos.
IU: Frecuencia Esta clase permite insertar y modificar, eliminar y buscar
las unidades de tiempo que se utilizan en las frecuencias
de mantenimiento
IU: Esta clase permite a los actores visualizar las
Herramientas y herramientas de mantenimiento, asi como también
Materiales realizas las operaciones básicas de un CRUD
IU: Nagios Esta clase permite visualizar el histórico de los servicios
de impresión de Nagios
IU: Esta clase permite asignarles los privilegios a los
Configuración usuarios del sistema además de modificar dichos
de Usuarios privilegios.
IU: Roles de Esta Clase permite ingresar y modificar los niveles de
Usuario acceso que tienen los usuarios
IU: Módulos Esta clase permite modificar los permisos a los módulos
del sistema
IU: Reportes Esta clase permite visualizar los reportes requeridos por
Oficiales el actor
A continuación en la tabla 4.23 se identifican y describen cada una de

las clases de control, utilizadas para realizar los diagramas de clase de
análisis del sistema.
104
Tabla 4.23: Descripción de las Clases de Control del Sistema

Clase de Descripción
Control
Gestor: Login Esta clase permite validar los datos introducidos y
permitir el acceso al sistema.
Gestor: Clases Este gestor permite procesar y validar la información de
de Activos las clases de activo
Gestor: Tipos de Este gestor permite procesar y validar la información de
Activos los tipos de activos
Gestor: Listados Esta clase permite procesar y validar la información de
de Activos los activos
Gestor: Registro Esta clase procesa y valida el registro de
de mantenimiento
Mantenimiento
Gestor: Se encarga de validar los datos de la planificación de
Planificación de mantenimiento
Mantenimiento
Gestor: Tareas Esta clase permite procesar y validar la información
de referente de las tareas de mantenimiento.
Mantenimiento
Gestor: Se encarga de validar las herramientas que requiere
Herramientas y cada tarea de mantenimiento.
Materiales
Gestor: Tipos de Esta clase permite procesar y validar la información
Mantenimiento referente de los tipos de mantenimiento.
Gestor: Esta clase permite procesar y validar la información
Frecuencia referente a las frecuencia del tiempo
Gestor: Nagios Esta clase permite insertar en la base de datos de
manera automatizada los registro suministrados por
Nagios
Gestor: Esta clase permite validar y procesar los usuarios de
Configuración PDVSA
de Usuarios
Gestor: Roles de Esta clase permite validar y procesar los roles de los
Usuario usuarios
Gestor Módulos Esta clase permite validar y procesar los números que
identifican a los módulos del sistema
Gestor: Este gestor permite al usuario la selección entre las
Reportes opciones de los diferentes reportes oficiales.
Oficiales
105
Para seguir con los lineamientos de Bases de Datos Oriente se

agregara la nomenclatura y estándar de las tablas de la Base de datos
asociadas a la entidad respectiva. En la tabla 4.24 se identifican y describen
la clase de entidad utilizadas en el sistema
Tabla 4.24: Descripción de las Clases de Entidad del Sistema (1/2).

Clase Nombre de la Tabla Descripción
Entidad
Usuario i001t_usuario Almacena los datos que
los usuarios que tienen los
privilegios para ingresar al
sistema.
Directorio N/A Almacena el indicador y
Activo PDVSA contraseña de los
usuarios PDVSA
Clase de i006t_clase_activo_detalle Registra las diferentes
Activo clase de activo de la
plataforma AIT
Tipo de Activo i007t_clase _activo Registra los tipos de
activos de la plataforma
AIT
Marca i004t_marca Almacena las marcas de
los activos
Modelo i003t_modelo Almacena los modelos de
los activos
Activo c001t_activo Almacena la información
de los activos
Registro de c003t_frecuencia_mtto Almacena los registro de
Mantenimiento mantenimiento
Plan de c001t_plan_mtto Almacena los planes de
Mantenimiento mantenimiento
Tarea de i002t_tarea_mtto Registra las tareas de
Mantenimiento mantenimiento que realiza
la Gerencia AIT.
Asignar i004t_tarea_mtto_herramienta Registra las herramienta
Herramienta asociada a las tareas de
mantenimiento
106
Tabla 4.24: Descripción de las Clases de Entidad del Sistema (2/2).

Clase Nombre de la Tabla Descripción
Entidad
Tipo de i001t_tipo_mtto Registra los tipos de
Mantenimiento mantenimiento que
realiza la Gerencia AIT
Herramientas i003t_herramienta Almacena los datos de
las herramientas de
mantenimiento
Frecuencia i005t_unidad_tiempo Almacena las frecuencias
Histórico de x001t_historico_monitoreo Almacena los datos
Monitoreo suministrado por Nagios
Usuario i001t_usuario Almacena los usuarios
que tienen acceso al
sistema
Persona i001t_persona Almacena todos los
usuarios PDVSA
Rol de i003t_nivel_usuario Registra los niveles de
Usuario Acceso que tienen los
usuarios
Módulo i002t_modulo Almacena el código y
nombre de los módulos
del sistema
 Diagrama de Clase de Análisis del Caso de uso “Login”

El caso de uso Login representa la interfaz principal del sistema y le
permite a los usuarios autorizados acceder al sistema con su clave y
contraseña PDVSA, el gestor se comunica con las entidades Usuario y
Directorio Activo PDVSA para comprobar que el usuario existe. En la figura
4.22 se ilustra el diagrama de clase de análisis del caso de uso Login.
 Diagrama de Clase de Análisis del Caso de uso “Clases de Activo”

Los actores que pueden interactuar con este caso de uso son el
Administrador y Supervisor de Activo, estos actores pueden realizar las
operaciones básicas que conforman parte de un CRUD (Crear, Leer,
107
Actualizar y Borrar). Hay que señalar también que este caso de uso
despliega formularios cuando se desea modificar o eliminar algún registro,
que posteriormente son guardados o eliminados en la entidad clase de
activo. A continuación en la figura 4.23 se ilustre este diagrama de clase de
análisis del caso de uso Clases de Activos.
Figura 4.22: Diagrama de Clase de Análisis del Caso de uso Login

 Diagrama de Clase de Análisis del Caso de uso “Tipos de Activo”

Los actores que pueden interactuar con este caso de uso son el
Administrador y Analista de Activo, estos actores pueden realizar las
operaciones básicas que forman parte de un CRUD (Crear, Leer, Actualizar y
Borrar). Hay que señalar también que este caso de uso despliega formularios
108
cuando se desea modificar algún registro, que posteriormente son guardados

en la entidad tipo de activo, hay que mencionar también, que el gestor
requiere la entidad clase de activo para la consulta de datos, para finalizar en
la figura 4.24 se ilustre el diagrama de clase de análisis del caso de uso
Tipos de Activos.
Figura 4.23: Diagrama de Clase de Análisis del Caso de uso “Clases de

Activo”
Figura 4.24: Diagrama de Clase de Análisis del Caso de uso “Tipos de

Activos”
109
 Diagrama de Clase de Análisis del Caso de uso “Listados de

Activos”
En este caso de uso se encuentra disponible los actores Administrador,
Analista de Activo, Analista de Soporte Técnico, Supervisor de Soporte
Técnico y el actor externo SIGA-AIT, el gestor listados de activos se
comunica con múltiples entidades que contiene la información detallada de
los activos que son mostradas en la interfaz listados de activos. En la figura
4.25 se ilustra el diagrama de clases de análisis del caso de uso Listados de
Activos.
Figura 4.25: Diagrama de Clase de Análisis del Caso de uso Listados de

Activos.
 Diagrama de Clase de Análisis del Caso de Uso “Registro de

Mantenimiento
En este caso de uso está disponible para el administrador, supervisor
de soporte técnico y planificador de mantenimiento, en este caso de uso se
110
crean los registro de mantenimiento que son procesados y validados por el

gestor registro de mantenimiento que se encarga de comunicarse con
múltiples entidades necesarias para crear un mantenimiento y mostrar la
interfaz registro de mantenimiento a los actores. En la figura 4.26 se ilustra
el diagrama de clase de análisis del caso de uso Registro de Mantenimiento.
Figura 4.26: Diagrama de Clase de Análisis del Caso de uso “Registro de

Mantenimiento”
 Diagrama de Clase de Análisis del Caso de Uso “Planificación de

Mantenimiento”
En la figura 4.27 se muestra el diagrama de clase de análisis del caso
uso Planificación de Mantenimiento, con respecto a los actores involucrados
son el analista de soporte técnico, el supervisor de soporte técnico, el
administrador y planificador de mantenimiento, así mismo este caso de uso
despliegue formularios cuando algún actor modifica o planifica algún
mantenimiento que son procesadas por el gestor planificación de
111
mantenimiento que a su vez se encarga de mostrar la vistas planificación de

mantenimiento y realizar mantenimiento.
Figura 4.27: Diagrama de Clase de Análisis del Caso de uso “Planificación

de Mantenimiento”
 Diagrama de Clase de Análisis del Caso de uso “Tareas de

Mantenimiento”
Este caso de uso se encuentra disponible para los actores,
Administrador, Planificador de Mantenimiento y Supervisor de Soporte
Técnico, los cuales pueden seleccionar entre las diferentes opciones que
tiene la interfaz como: insertar, modificar, eliminar y buscar las tareas de
mantenimiento. Dependiendo de la necesidad del usuario se desplegara
otras interfaces en el sistema como un formulario que modifique los datos e
información que serán validados por el gestor para finalmente ser guardados
en la base de datos por medio de la entidad. Para comprender mejor en la
112
figura 4.28 se muestra el diagrama representativo al caso de uso Tareas de

Mantenimiento.
Figura 4.28: Diagrama de Clase de Análisis del Caso de uso Tareas de

Mantenimiento
 Diagrama de Clase de Análisis del Caso de uso “Tipos de

Mantenimiento”
Este caso de uso se encuentra disponible para los actores,
Administrador y Planificador de Mantenimiento, los cuales pueden
seleccionar entre las diferentes opciones que tiene la interfaz como: insertar,
modificar, eliminar y buscar los tipos de mantenimiento. Dependiendo de los
deseos del usuario se desplegara otras interfaces en el sistema como un
formulario que modifique los datos e información que serán validados por el
gestor para finalmente ser guardados en la base de datos por medio de la
entidad Tipo de Mantenimiento.
Para ser más específicos en la figura 4.29 se muestra el diagrama

representativo del caso de uso Tipos de Mantenimiento.
113
Figura 4.29: Diagrama de Clase de Análisis del Caso de uso Tipos de

Mantenimiento
 Diagrama de Clase de Análisis del Caso de uso “Frecuencia”

Este caso de uso se encuentra disponible para los actores
Administrador y Planificador de Mantenimiento los cuales pueden realizar
eventos como, insertar, modificar, eliminar, y buscar un registro; si el actor
edita o elimina un registro se desplegara una interfaz con el formulario
respectivo, que será validada por el gestor, para ser guardada por la entidad
frecuencia. En la figura 4.30 se ilustra el diagrama de clase de análisis del
caso de uso Frecuencia
Figura 4.30: Diagrama de Clase de Análisis del Caso de uso “Frecuencia”

114
 Diagrama de Clase de Análisis del Caso de uso “Herramientas y

Materiales”
Este caso de uso está disponible para los actores administrador y
planificador de mantenimiento, los cuales pueden realizar las operaciones
básicas que conforman un CRUD (Crear, Leer, Actualizar y Eliminar),
dependiendo de los eventos que ejecute el usuario se desplegara otras
interfaces en el sistema como un formulario que modifique los datos e
información que serán validados por el gestor, para finalmente ser
guardados en la base de datos por medio de la entidad Herramienta. En la
figura 4.31 se muestra el diagrama de clase de análisis Herramientas y
Materiales.
Figura 4.31: Diagrama de Clase de Análisis del Caso de uso Herramientas y

Materiales
 Diagrama de Clases de Análisis del Caso de uso “Nagios”

En la figura 4.32se representa el diagrama de clase de análisis del
caso de uso Nagios, en este caso de uso están tres actores, Administrador,
Supervisor Soporte Técnico y el actor Nagios que representa el sistema de
monitoreo, los actores Administrador y Supervisor de Soporte Técnico activan
el caso se usó para visualizar el registro histórico que proviene de Nagios
que envía los datos al sistema a través de un objeto JSON (Notación de
115
Objetos de JavaScript), el gestor procesa estos datos y los guarda

permanentemente en la entidad Nagios.
Figura 4.32: Diagrama de Clase de Análisis del Caso de uso “Nagios”

 Diagrama de Clases de Análisis del Caso de uso “Configuración de

Usuarios”
Este caso de uso los actores son el administrador y el actor externo
SIGA-AIT. El administrador puede realizar las operaciones básicas de un
CRUD. Además este caso de uso despliega unos formularios cuando se
ingresar, modifica o elimina algún usuario, el gestor se encarga de validar los
datos introducidos y guarda los cambios en las entidades respectivas. En la
figura 4.33 se muestra este diagrama de clase de análisis.
 Diagrama de Clases de Análisis del Caso de Uso “Roles del Usuario”

En la figura 4.34 se muestra el diagrama de clases de análisis del caso
de uso Roles del usuario, entre las clases del análisis de este caso de uso
está la interfaz que posee las operaciones básicas de un CRUD, esta interfaz
despliega un formulario cuando se elige la opción de editar o eliminar un
registro, el gestor que permite administrar las diferentes opciones que tiene
116
esta interfaz y la entidad rol del usuario que se encarga de registrar las
modificaciones realizadas por el usuario.
Figura 4.33: Diagrama de Clase de Análisis del Caso de uso “Configuración

de Usuarios”
Figura 4.34: Diagrama de Clase de Análisis del Caso de uso “Roles del
Usuario”
 Diagrama de Clases de Análisis del Caso de Uso “Módulos”

En la figura 4.35 se ilustra se muestra el diagrama de clases de
análisis del caso de uso Módulos, entre las clases del análisis de este caso
de uso está la interfaz que posee las operaciones básicas de un CRUD, esta
interfaz despliega un formulario cuando se elige la opción de editar o eliminar
un registro, el gestor que permite administrar las diferentes opciones que
117
tiene esta interfaz y la entidad nivel de usuario que se encarga de registrar

las modificaciones realizadas por el usuario
Figura 4.35: Diagrama de Clase de Análisis del Caso de uso “Módulos”

 Diagrama de Clases del Análisis del Caso de Uso “Reportes

Oficiales”
El caso de uso se encuentra disponible para los actores Administrador y
Supervisor de Soporte Técnico, el gestor Reportes funciona como
procesador principal ya que permite gestionar la elección elegida por el actor
y mostrar en la interfaz visual del reporte respectivo. En la figura 4.36 se
muestra el diagrama de clase de análisis del caso de uso Reportes Oficiales.
Figura 4.36: Diagrama de Clase de Análisis del Caso de uso “Reportes

Oficiales”
118
4.1.6.3 Diagrama de Colaboración
Las secuencia de acciones es un caso de uso que comienza cuando un

actor invoca el caso de uso mediante él envió de algún tipo de mensaje al
sistema.
Si consideramos el “interior” del sistema, un objeto de interfaz recibirá

este mensaje del actor. El objeto de interfaz enviara a su vez un mensaje a
algún otro objeto, y de esta forma los objetos implicados interactuaran para
llevar a cabo el caso de uso. La mejor manera de mostrar esto es con los
diagramas de colaboración.
En los diagramas de colaboración, mostramos las interacciones entre

objetos creando enlaces entre ellos y añadiendo mensajes a esos enlaces. El
nombre de un mensaje debería denotar el propósito del objeto invocante en
la interacción con el objeto invocado.
Para representar un mensaje, hay una flecha cerca de la línea de

asociación entre dos objetos, esta flecha apunta al objeto receptor. El tipo de
mensaje se mostrara en una etiqueta cerca de la flecha; por lo general, el
mensaje le indicara al objeto receptor que ejecute una de sus operaciones. El
mensaje finalizara con un par de paréntesis, dentro de los cuales colocara
los parámetros (en caso de haber alguno) con los que funcionara la
operación. Habría que decir también que un diagrama colaboración se puede
convertir en un diagrama de secuencia y viceversa, por esta razón en este
proyecto de grado no realizamos los diagramas de secuencia.
A continuación se muestra los diagramas de colaboración del sistema

119
 Diagrama de Colaboración del Caso de Uso “Login”

Este Caso de uso se activa cuando un actor inicia la aplicación y se
activa la interfaz login (1), el gestor se encarga de llamar a la interfaz login
(2), para que posteriormente, el actor ingrese el indicador PDVSA y clave de
red (3), luego el gestor valida los datos (4), y establece comunicación con el
Directorio Activo PDVSA (5) y la entidad Usuario (6). Finalmente el gestor
valida dos entidades, la primera si el usuario y contraseña fue validada por el
Directorio Activo PDVSA y la segunda si el indicador está registrado en el
sistema a través de la entidad Usuario, para retornar la información con el
perfil y datos del usuario(7). En la figura 4.37 se ilustra el diagrama de
colaboración correspondiente al caso de uso Login.
Figura 4.37: Diagrama de Colaboración del Caso de Uso “Login”

120
 Diagrama de Colaboración del Caso de Uso “Clases de Activos”

Este caso de uso de activa cuando el actor activa la interfaz Clases de
Activos (1), el gestor llama la interfaz correspondiente (2), para que el ejecute
alguna una de las siguientes opciones disponible: ingresar, editar, eliminar un
registro (3), luego el gestor procesa y valida el evento (4), y después las
entidad Clase de Activo guarde los cambios realizados (5). El gestor muestra
la interfaz Clases de activos con los cambios realizados (6). El actor consulta
un registro (7), que es procesada por el gestor (8) que a su vez se comunica
con la entidad Clase de Activo (9), para finalmente mostrar la consulta al
usuario (10). En la figura 4.38 se ilustra el diagrama de colaboración del
caso de uso Clase de Activos
Figura 4.38: Diagrama de Colaboración del Caso de Uso “Clases de Activos”

 Diagrama de Colaboración del Caso de Uso “Tipos de Activos”

El caso de uso se activa cuando los actores activa la interfaz Tipos de
Activos (1), en el cual el gestor se encarga de cargar la vista (2), luego el
121
usuario realiza alguna de las operaciones básicas como, insertar, editar o

eliminar un registro(3), que inmediatamente es procesado y validado por el
gestor (4), luego la entidad tipo de activo guardan los cambios en la base de
datos (5), y el gestor actualiza la interfaz con los cambios realizados (6). El
actor introduce en el sistema un parámetro de búsqueda (7), el gestor
procesa la consulta (8) y después la entidad Tipo de activo y clase de activo
capturan los datos de la búsqueda en la base de datos (9,10), para
finalmente el gestor muestre la consulta a los actores a través de la interfaz
Tipos de Activos (11).
En la figura 4.39 se representa el diagrama de colaboración

correspondiente al caso de uso Tipos de activos.
Figura 4.39: Diagrama de Colaboración del Caso de Uso “Tipos de Activos”

122
 Diagrama de Colaboración del Caso de Uso “Listados de Activos”

El primer lugar el actor activa la interfaz (1), en segunda lugar el
gestor carga la interfaz Listados de activos (2), luego el actor edita una
características de un activo (3), una vez modificado el gestor procesa y
valida los datos (4), y la entidad activo guarda los datos en la base de
datos de SIGA-AIT (5), luego el gestor muestra la interfaz con los cambios
realizados (6). Si el actor realiza una consulta (7), el gestor procesa la
solicitud (8) y las entidades se encarga de realizar la consulta en la base
de datos (9,10,11,12,13), una vez consultado los datos el gestor se
encarga de transferir la consulta a la interfaz (14). En la figura 4.40 se
representa el diagrama de colaboración correspondiente al caso de uso
Listados de Activos.
 Diagrama de Colaboración del Caso de Uso “Registro de

Mantenimiento”
Este caso de uso se activa cuando el actor llama la interfaz (1), luego
el gestor se comunica con las entidades (2), Frecuencia (3), y Tipo de
Mantenimiento (4), para que el gestor cargue los datos de estas entidades al
usuario (5). El actor ingresa los datos de un activo (6), se procesa y se
valida el evento (7) y se establece comunicación con las entidades activo (8)
y tipo de mantenimiento (9), posteriormente el gestor carga en una tabla las
tareas relacionadas con el activo (10) para que el actor selecciona la tarea
(11), y finalmente el evento es procesado (12) y guardado por la entidad
Registro de Mantenimiento (13). Para ser más específico en la figura 4.41 se
muestra el diagrama de colaboración del caso de uso Registro de
Mantenimiento.
123
Figura 4.40: Diagrama de Colaboración del Caso de Uso “Listados de

Activos”
 Diagrama de Colaboración del Caso de Uso “Planificación de

Mantenimiento”
El caso de inicio inicia cuando el actor activa la interfaz Planificación de
Mantenimiento (1), el gestor procesa el evento y llama la interfaz (2), el actor
realiza un evento el evento de planificar o reprogramar un fecha de
mantenimiento (3), el gestor procesa y valida el evento (4), y posteriormente
124
se guarda los datos en la entidad planificación de mantenimiento (5), el

gestor vuelve a carga la interfaz Planificación de Mantenimiento con los
cambios realizados (6).Cuando el actor consulta un registro (7 el gestor
procesa la consulta (8) y se recopila la información en las entidades
(9,10,11,12,13), para que el gestor muestre la búsqueda en la interfaz
Planificación de Mantenimiento (14). Cuando el actor ejecute el evento de
Realizar Mantenimiento (15), el gestor procesa el evento (16) y se establece
comunicación con las entidades (17,18,19,20,21), con el propósito de carga
la información del mantenimiento en la interfaz Realizar Mantenimiento (22),
en esta interfaz el actor confirma que se culmino el mantenimiento (23), el
gestor procesa el evento (24), y se guarda la información en la entidad
Planificación de Mantenimiento (25) por último se crea en la entidad Registro
de Mantenimiento el próximo mantenimiento (26). El actor modifica la
frecuencia de mantenimiento de un registro (27), el gestor procesa el evento
(28), se guardan los datos en la entidad Registro de Mantenimiento (29) y
finalmente se actualiza la interfaz con los cambios realizados (30). En la
figura 4.42 se ilustra el diagrama de colaboración del caso de uso
Planificación de Mantenimiento.
 Diagrama de Colaboración del Caso de Uso “Tareas de

Mantenimiento”
En primer lugar el actor activa la interfaz “Tareas de Mantenimiento” (1),
que es cargada por el gestor (2), posteriormente el actor editar, eliminar o
agregar una tarea de mantenimiento (3), que es procesada y validada por el
gestor (4), los cambios se guardan en la entidad Tarea de Mantenimiento (5)
y el gestor se encarga de actualizar la interfaz Tareas de mantenimiento (6).
El actor realiza una consulta de una tarea (7), el gestor procesa la consulta
(8), y se comunica con la entidad que captura la información (9), para que
125
finalmente el gestor envíe la consulta a la interfaz Tareas de Mantenimiento

(10). El actor selecciona la opción asignar herramientas y materiales de la
interfaz tareas de mantenimiento (11), el gestor procesa el evento y llama la
interfaz Asignar Herramientas y Materiales (12), luego el actor asigna o
elimina una herramienta (13), se procesa el evento (14), y se guardan los
cambios realizados en la entidad (15),finalmente el gestor actualiza la
interfaz con los cambios realizados (16).El actor consulta una herramienta
(17), se procesa el evento, se recopila la información en las entidades
(19,20), y se muestra la consulta en la interfaz (21). En la figura 4.43 se
ilustra el diagrama de colaboración del caso de uso Tareas de
Mantenimiento.
Figura 4.41: Diagrama de Colaboración del Caso de Uso “Registro de

Mantenimiento”
126
Figura 4.42: Diagrama de Colaboración del Caso de Uso “Planificación de

Mantenimiento”
127
Figura 4.43: Diagrama de Colaboración del Caso de Uso Tareas de

Mantenimiento
 Diagrama de Colaboración del Caso de Uso “Tipos de

Mantenimiento”
En este caso de uso el actor tiene que activar la interfaz Tipos de
Mantenimiento (1); en el cual el gestor se encarga de llamar a esta interfaz
128
(2). El actor puede procesar alguna de las opciones de la interfaz como

Ingresar, editar y eliminar algún registro (3), que son posteriormente
procesadas y validadas por el gestor (4), para luego ser guardados en la
entidad Tipo de Mantenimiento (5) y finalmente el gestor se encarga de
actualizar la interfaz con los respectivos cambios (6). Cuando el actor buscar
algún registro que desee (7), el gestor procesa la consulta (8) y la entidad
captura los datos solicitados en la base de datos (9) para finalmente al gestor
que se encarga de mostrar los datos solicitados a la interfaz (10). En la
figura 4.44 se representa este diagrama de colaboración.
Figura 4.44: Diagrama de Colaboración del Caso de Uso “Tipos de

Mantenimiento”
129
 Diagrama de Colaboración del Caso de Uso “Frecuencia”

El actor activa la interfaz Frecuencia (1), el gestor carga esta interfaz
(2), con la finalidad del que el actor realiza alguna de las operaciones básicas
de esta interfaz (3), luego el gestor valida los el evento (4) y guarda la
información en las entidad Frecuencia (5), después el gestor actualiza la
interfaz con las modificaciones realizadas (6). El actor consulta un registro
(7), el gestor procesa la solicitud (8) y después la entidad Frecuencia captura
la información de la consulta (9), para finalmente el gestor se encarga de
mostrar los datos al actor (10). En la figura 4.45 se representa este diagrama
de colaboración.
Figura 4.45: Diagrama de Colaboración del Caso de Uso “Frecuencia”

130
 Diagrama de Colaboración del Caso de Uso “Herramientas y

Materiales”
El actor activa la interfaz Herramientas (1), el gestor recibe la solicitud y
carga la interfaz al actor (2), luego el actor realiza una operación básica de la
interfaz (3), que posteriormente es validada por el gestor (4), y guardada por
la entidad Herramienta (5), después el gestor carga a la interfaz los cambios
realizados (6). Cuando el actor realiza una consulta (7), el gestor procesa la
solicitud de la consulta (8) y se comunica con la entidad Herramienta que
captura la información de la base de datos (9), para finalmente el gestor se
encarga de devolver la consulta al usuario a través de la interfaz
Herramientas (10). En la figura 4.46 se representa el diagrama de
colaboración del caso de uso Herramientas y Materiales
131
Figura 4.46: Diagrama de Colaboración del Caso de Uso “Herramientas y

Materiales”
 Diagrama de Colaboración del Caso de Uso “Nagios”
El Administrador o el Supervisor de Soporte Técnico activa el caso de
uso (1), el gestor llama la interfaz (2) y después el actor consulta un registro
(3), el gestor procesa la consulta (4), se establece conexión con la entidad
Nagios (5) y el gestor retorna la consulta a la interfaz (6). El actor externo
Nagios envía los datos de monitoreo de una impresora a través de una
dirección URL, esta dirección URL contiene la data de Nagios en formato
JSON (7), el gestor procesa la información (8) y guarda la información en la
entidad Nagios. En la figura 4.47 se ilustra el diagrama de colaboración del
caso de uso Nagios.
132
Figura 4.47:Diagrama de Colaboración del Caso de Uso “Nagios”

 Diagrama de Colaboración del Caso de Uso “Configuración de

Usuarios”
Este caso de uso es activado por el actor Administrador (1), el gestor
carga la interfaz Configuración de Usuarios (2), luego el actor selecciona la
opción buscar del formulario (3), Se procesa la solicitud (4), se establece
comunicación con la entidad Persona que proviene de la base de datos
SIGA-AIT (5), después se retornan la información en una lista desplegable
(6), el actor escoge el usuario e ingresa sus datos (7), se validan los datos
(8), y se guardan en la entidad Usuario (9) para finalmente el gestor actualiza
la interfaz(10).Cuando el actor edita o elimina un usuario (11), se procede a
procesar la solicitud (12) y la entidad Usuario modifica los datos
permanentemente en la base de datos (13), después el gestor vuelve
actualizar la interfaz (14). El actor consulta un usuario del sistema (15), se
procesa la solicitud (16), y se establece comunicación con las entidades que
se encarga de recopilar la información en la base de datos (17,18), y
posteriormente se envía los datos que coinciden con la consulta a la interfaz
Configuración de Usuarios (19). A continuación en la figura 4.48 se
representa el diagrama de colaboración del caso de uso Configuración de
Usuarios.
 Diagrama de Colaboración del Caso de Uso “Roles del Usuario”

El actor activa la interfaz (1) y luego el gestor carga la interfaz Roles del
usuario (2), después el actor realiza el evento de ingresar, editar o eliminar
un registro (3), que es procesado y validado por el gestor (4), y los cambios
se guardan permanentemente en la entidad Rol del Usuario (5),
133
posteriormente el gestor carga la interfaz con los cambios realizados (6), si

el actor ingresa un parámetro de búsqueda (7), rápidamente el gestor
procesa la consulta (8), y se comunica con la entidad (9), para finalmente
enviar la consulta a la interfaz Roles del Usuario (10). En la figura 4.49 se
ilustra el diagrama de colaboración del caso de uso Nivel de Usuario.
Figura 4.48: Diagrama de Colaboración del Caso de Uso “Configuración de

Usuarios”
 Diagrama de Colaboración del Caso de Uso “Módulos”

134
El actor activa la interfaz Módulos (1), después el gestor carga la

interfaz (2) y seguidamente el actor realiza un evento disponible en la interfaz
como agregar, editar o eliminar un módulo (3), el gestor procesa la elección
del actor (4), la entidad Modulo guarda los cambios realizados (5), para
posteriormente el gestor envía los cambios que se realizaron a la interfaz (6).
El actor ingresa un parámetro de búsqueda (7), se procesa la consulta (8), se
comunica con la entidad correspondiente (9), para finalmente retornar a la
interfaz los datos requeridos (10). En la figura 4.50 se representa el
diagrama de colaboración del caso de uso Módulos
Figura 4.49: Diagrama de Colaboración del Caso de Uso “Roles del Usuario”
135
Figura 4.50: Diagrama de Colaboración del Caso de Uso “Módulos”

 Diagrama de Colaboración del Caso de Uso “Reportes”
El actor activa interfaz (1), luego el gestor carga la interfaz (2),
posteriormente el actor selecciona un reporte (3), se procesa la solicitud (4),
después se establece comunicación con las entidades necesarias (5) y
finalmente el gestor procesa y muestra al actor la interfaz que le corresponde
(6). En la figura 4.51 se representa el diagrama de colaboración del caso de
uso Reportes
136
Figura 4.51Diagrama de Colaboración del Caso de Uso “Reportes Oficiales”

4.1.7 Flujo de Trabajo de Diseño
En el diseño modelamos el sistema y encontramos su forma (incluida la

arquitectura) para que soporte los requisitos, incluyendo los requisitos no
funcionales y otras restricciones. Como estamos en la fase de inicio, para
este flujo de trabajo solo mostraremos la arquitectura candidata y el prototipo
de la interfaz.
4.1.7.1 Arquitectura Candidata
El objetivo principal del flujo de trabajo de diseño es embozar un

modelo de diseño de la arquitectura candidata, después de un análisis del
objetivo del proyecto, se determinó que la mejor manera de estructurar el
sistema a través de la arquitectura cliente-servidor. Esta arquitectura se
137
planteó en base a un sistema distribuido en donde los ordenadores estarán

interconectadas a través de la intranet de PDVSA.
El cliente comprende los componentes relacionados con la captura y

validación de datos, y estarán ubicadas en las distintas áreas de trabajo de la
empresa. Habría que decir también que el término cliente no se refiere a las
personas, sino a máquinas conectadas en red que son los puntos típicos de
entrada al sistema cliente-servidor que utilizan los humanos. Por lo tanto, los
clientes podrían ser computadoras de escritorio conectadas en red, una
estación de trabajo, computadoras portátiles o cualquier otra forma en que el
usuario pueda entrar al sistema.
En el servidor se encuentran todos los componentes que toman

decisión sobre el flujo de eventos que son generados por las solicitudes
(consultas, registros, actualizaciones, entre otros) que los clientes envían al
sistema, donde se procesan los datos necesarios y se obtienen los
resultados solicitados. Así mismo, provee los servicios necesarios para
establecer la conexión a la base de datos del sistema, y con sus respectivos
privilegios a los usuarios que intentan acceder a la información. Para ser más
específicos en la figura 4.52 se ilustra la arquitectura candidata
138
Figura 4.52: Arquitectura Candidata Cliente-Servidor

Fuente: Kendall y Kendall (2001).
4.1.7.2 Prototipo de la interfaz Inicio de Sesión
Para el diseño de la interfaz de usuario simplemente se utilizó una

plantilla ya creada por el departamento de aplicaciones mostrada en la
figura 4.53. Para el inicio de sesión el usuario debe tener una cuenta
PDVSA y estar registrado dentro de la base de datos del sistema.
4.1.8 Conclusión de la Fase de Inicio
Los objetivos principales de la fase de inicio son: establecer un análisis

del sistema propuesto, describir el contexto del sistema, capturar los
requerimientos funcionales, identificar los riesgos críticos que pondrían en
139
peligro el desarrollo del proyecto y proponer una arquitectura candidata

factible. Dichos objetivos se cumplieron de una forma satisfactoria, ya que se
obtuvo una primera versión del modelo que describe el contexto del sistema,
una lista inicial de riesgos y un esbozo de los modelos que representan una
primera versión el modelo de casos de uso y de modelo de análisis, los
cuales describen una arquitectura candidata factible. En esta fase se obtuvo
una buena comprensión del proyecto y la factibilidad de culminarlo. Los
resultados alcanzados en esta fase se refinarán en la fase de elaboración.
Figura 4.53: Prototipo de la Interfaz de Usuario

140
4.2 Fase de Elaboración
En esta fase se trabajará con la segunda fase del proceso unificado de

desarrollo de software. Uno de los objetivos principales de esta fase es el
obtener un entendimiento más detallado de los requerimientos de la
aplicación, a pesar de que estos son descritos en la fase de inicio. El otro
objetivo prioritario de esta fase es el diseñar, implementar y validar la
arquitectura del sistema. La funcionalidad a nivel de la aplicación no será
completada, aunque se podrá compilar y probar la arquitectura durante esta
fase.
Se establecerá aquí la arquitectura de la aplicación, así como también

el diseño de la Base de Datos y la interfaz de usuario. Durante esta fase se
especifican la mayoría de los casos de usos, finalizando con las distintas
vistas de los diferentes modelos del sistema.
A continuación en la figura 5.54 se presenta el Proceso Unificado de

Desarrollo de Software, resaltando la Fase de Elaboración.
Figura 4.54 Fase de Elaboración

141
4.2.1 Flujo de Trabajo de Requisitos
En esta segunda fase se identificaron nuevos requisitos, mucho de los

cuales fueron surgiendo a medida que se empezaba a codificar el sistema.
Se añadieron los nuevos casos de uso Consultar Marcas y Modelos,
Calendario de Tareas, Asignar Tipos de Activos que es una extensión del
caso de uso Tareas de mantenimiento y Permisología.
4.2.1.1 Representación de los nuevos requisitos de clases de uso
La descripción de los nuevos casos de uso se detalla en la tabla 4.25.
Tabla 4.25: Descripción de los nuevos Casos de Uso

Consultar En este caso de uso el actor podrá consultar todas las
Marca y marcas y modelos que existen en la plataforma de
Modelos escritorio.
Calendario de En este caso de uso los actores pueden visualizar en un
Tareas calendario las tareas de mantenimiento planificadas y
reprogramadas.
Asignar Tareas En esta extensión caso de uso Tareas de Mantenimiento,
de los actores pueden asignar las tareas de mantenimiento a
Mantenimiento los equipos.
Permisología Este caso de uso permite asignar los accesos a los
módulos del sistema según el rol del usuario.
4.2.1.2 Modelo de Caso de Uso Mejorado
Reconoceremos en la figura 4.55 los nuevos casos de uso del

Sistema de Información.
142
Figura 4.55: Modelo de Caso de Uso General del sistema (Nueva Versión)
143
4.2.1.3 Descripción de los nuevos casos de uso
A continuación desde la tabla 4.26 hasta la tabla 4.29 se describen los

nuevos casos de usos.
 Consultar Marcas y Modelos

En la figura 4.56 se ejemplifica el modelo de casos de uso Consultar
Marcar y Modelos
Figura 4.56: Diagrama del Caso de Uso Consultar Marcas y Modelos

Tabla 4.26: Caso de Uso Consultar Marcas y Modelos (1/2)

Actores Administrador, Supervisor de Soporte Técnico, Analista
de Soporte Técnico, Planificador de Mantenimiento y
SIGA-AIT.
Descripción Permite visualizar las marcas y modelos de los equipos de
la plataforma AIT
Condición el menú desplegable la opción “activo” y seleccionar la
opción Consultar Marcas y Modelos.
144
Tabla 4.26: Caso de Uso Consultar Marcas y Modelos (2/2)

Eventos
Flujo A El actor ingresa un parámetro de búsqueda
Principal 1 El sistema muestra en la tabla, los registros que
Alternativo
 Calendario de Tareas
A continuación en la figura 4.57 se ejemplifica el modelo de casos de
uso Calendario de Tareas.
Figura 4.57 Diagrama del Caso de Uso Calendario de Tareas.

Tabla 4.27: Caso de Uso Calendario de Tareas (1/2)

Actores Administrador, Analista de Soporte Técnico, Planificador de
Mantenimiento, Supervisor de Soporte Técnico y
Administrador.
Descripción En este caso de uso los actores pueden visualizar en un
calendario las tareas de mantenimiento planificadas
Tabla 4.27: Caso de Uso Calendario de Tareas (2/2)
145

Condición el menú desplegable la opción “Mantenimiento” y
seleccionar la opción Calendario de Tareas.
Eventos
Flujo A El actor consulta una tarea de mantenimiento
Principal 1 El actor selecciona una tarea de mantenimiento
del calendario
2 Se muestra en una lista desplegable la
información detallada de la tarea.
Alternativo
 Asignar Tipos de Activos

A continuación en la figura 4.58 se representa el modelo de casos de
Calendario de Tareas.
Figura 4.58 Diagrama del Caso de Uso Asignar Tipos de Activos

Tabla 4.28: Caso de Uso Asignar Tipos de Activos

146
Actores Administrador, Planificador de Mantenimiento y Supervisor

de Soporte Técnico
Descripción En esta extensión caso de uso Tareas de Mantenimiento,
los actores pueden asignar las tareas de mantenimiento a
los equipos.
Pre- Los actores deben ingresar, a la opción tareas de
Condición mantenimiento y seleccionar en la tabla el botón Tipos de
Activos
Eventos
Flujo A El actor ingresa un registro
Principal 1 El sistema muestra las clases y tareas de activos
disponibles en el formulario
2 El selecciona la opción de su preferencia y
guarda los datos
3 El sistema guarda permanentemente los datos
B El actor elimina un tipo de activo
1 El actor selecciona el registro de la tabla y
aprieta la opción eliminar
2 El sistema elimina los datos permanentemente
C El actor busca un registro
1 El actor ingresa un parámetro de búsqueda
2 El sistema muestra los resultados de la
búsqueda
Alternativo
 Permisología
A continuación en la figura 4.59 se representa el modelo de caso de
uso Permisología
147
Figura 4.59: Diagrama del Caso de Uso Permisología

Tabla 4.29: Caso de Uso Permisología (1/2)

Descripción Este caso de uso permite asignar los accesos a los
módulos del sistema según el rol del usuario.
seleccionar la opción Permisología.
Eventos
Principal registro.
1 Se selecciona el recurso a modificar de la tabla
informático.
los datos deseados
148
Tabla 4.29: Caso de Uso Permisología (2/2)

Flujo 1 Se selecciona el recurso a eliminar y el sistema
Principal muestra un mensaje preguntando si está seguro
4.2.2 Flujo de Trabajo de Análisis
En este punto se realiza el análisis correspondiente a los casos de uso

del modelo general del sistema, permitiendo proponer la base para
establecer la arquitectura definitiva del software.
4.2.2.1 Paquetes de Análisis del Sistema
En concreto en la figura 4.60 se puede observar el diagrama de

paquetes redefinido, en el cual se agregaron los nuevos casos de uso que
surgieron de la captura de requisitos que se realizó en la fase de elaboración.
149
Figura 4.60: Diagrama de Paquetes de Análisis (Nueva versión)

4.2.2.2 Diagrama de Clases de Análisis y Colaboración (Nueva Versión)
A continuación se muestra la estructura de los diagramas de clases de

análisis para los nuevos casos de uso “Consultar Marcas y Modelos”,
“Calendario de Tareas”, “Asignar Tipos de Activos” y “Permisología”.
A continuación en la tabla 4.30 se identifican y describen las nuevas

clases de interfaz.
150
Tabla 4.30: Descripción de las Clase interfaz del sistema

IU: Consultar Esta clase permite visualizar las marcas y modelos de
Marca y Modelo los equipos de PDVSA
IU: Calendario Esta clase clases visualizar en un calendario tareas de
de Tareas mantenimiento planificadas
IU: Asignar Esta clase permite asociar las tareas de
Tipos de Activos mantenimiento a los activos de PDVSA. Esta nueva
clase es una herencia del gestor: Tareas de
Mantenimiento.
IU: Permisología Esta clase permite establecer los permisos de los roles
del usuario
A continuación en la tabla 4.31 se identifican y describen las nuevas

clases de control.
Tabla 4.31: Descripción de las Clase de control del sistema

Clase interfaz La Descripción
Gestor: Consultar La clase de encarga procesar y comunicar con las
Marca y Modelo entidades marcas y modelos
Gestor: Esta clase procesa la información a acerca de las
Calendario de fechas de mantenimiento
Tareas
Gestor: Esta clase procesa y valida los eventos que realiza el
Permisología usuario
Hay que señalar que en la fase de elaboración solamente se agregaron

la entidad Asignar Tarea de Mantenimiento y Permisologia, el resto de las
entidades necesarias para el funcionamiento de los caso de uso Consultar
Marca y Modelo, y Calendario de Tareas ya fueron definidas en la fase de
inicio, en la Tabla 4.32 se identifican y describen las nuevas clases de
entidad del sistema.
151
Tabla 4.32: Descripción de la Clases de entidad del sistema

Clase Entidad Nombre de la tabla Descripción
Asignar Tarea i008t_tarea_mtto_activo Almacena la asociaciones
de entre las tareas de
mantenimiento mantenimiento con los tipos
de activos
Permisología i004t_permisologia Almacena los permisos que
tienen los roles del usuario
 Diagrama de Clases de Análisis del caso de Uso “Consultar Marcas y

Modelos”
En este Diagrama de Clase de Análisis los actores involucrados
interactúan con la interfaz Consultar Marcas y Modelos en donde se puede
consultar las marcas y modelos que conforman de los activos de AIT, el
gestor procesa estas consultas y se comunica con las entidades Marca y
Modelo. En la figura 4.61 se representa el diagrama de clase de análisis
Consultar Marcas y Modelos.
 Diagrama de Clase de Análisis del Caso de Uso “Calendario de

Tareas”
Este caso de uso está disponible para los actores Planificador de
Mantenimiento, Supervisor de Soporte Técnico, Analista de Soporte Técnico,
que interactúan con la interfaz Calendario de Tareas, el único evento que
realizan los actores es consultar las fechas de mantenimientos, este evento
es procesado por el gestor Calendario de Tareas que se comunica con las
entidades necesarias. En la figura 4.62 se ilustra este diagrama de clases de
análisis del caso de uso Calendario de Tareas.
152
Figura 4.61: Diagrama de Clase de Análisis del Caso de Uso “Consultar

Marcas y Modelos”
 Diagrama de Clase de Análisis del Caso de Uso “Tareas de

Mantenimiento
Este diagrama de clases de análisis es el diagrama de clase de análisis
del caso de uso Tareas de mantenimiento de la fase de inicio, con la
diferencia que se agregó una nueva interfaz llamada Asignar Tipos de Activos
y también una nueva entidad llamada Asignar Tipo de Activo el gestor se
encarga de gestionar las tres interfaces y se comunica con las entidades. A
continuación en la figura 4.63 se ilustra el renovado diagrama de clase de
análisis del caso de uso Tareas de Mantenimiento.
153
Figura 4.62: Diagrama de Clase de Análisis del Caso de Uso “Calendario de

Tareas”
 Diagrama de Clase de Análisis del Caso de Uso “Permisología”

Este diagrama de clases de análisis el único actor involucrado es el
Administrador que tiene los privilegios modificar los permiso que poseen los
usuarios, además esta interfaz se puede agregar ,editar, eliminar y buscar los
privilegios poseen cada rol de usuario. En la figura 4.64 se muestra el
diagrama de clase de análisis del caso de uso Permisologia.
154
Figura 4.63: Diagrama de Clase de Análisis del Caso de Uso “Tareas de

Mantenimiento”
Figura 4.64: Diagrama de Clase de Análisis del Caso de Uso “Permisología”

 Diagrama de Colaboración del caso de Uso “Consultar Marcas y

Modelos”
Este caso de uso se activa cuando el actor activa la interfaz Consultar

Marcas y Modelos (1),el gestor carga la interfaz respectiva (2), para que el
155
actor introduzca los parámetros de búsqueda que desee (3), luego se validan
los datos introducidos (4), para posteriormente la información sea consultada
en las entidades Marca y Modelo de la Base de datos de SIGA-AIT (5,6), el
gestor envía la consulta a la interfaz (7). En la figura 4.65 se muestra el
diagrama de colaboración del caso de uso Consultar Marcas y Modelos.
Figura 4.65: Diagrama de Colaboración del Caso de Uso “Consultar Marcas

y Modelos”
 Diagrama de Colaboración del Caso de Uso “Calendario de Tareas”

El actor activa la interfaz Calendario de Tareas (1),el gestor carga la
interfaz al usuario (2), el actor consulta una tarea de mantenimiento en el
calendario (3), luego el gestor procesa el evento (4) y se recopila la
156
información en las entidades (5,6,7,8), por último el gestor muestra la

información detallada en la interfaz. En la figura 4.66 se muestra el diagrama
de colaboración del caso de uso “Calendario de Tareas”.
Figura 4.66: Diagrama de Colaboración del Caso de Uso “Calendario de

Tareas”
157
 Diagrama de Colaboración del Caso de Uso “Tareas de

Mantenimiento
En primer lugar el actor activa la interfaz “Tareas de Mantenimiento” (1),
que es cargada por el gestor (2), posteriormente el actor puede editar,
eliminar o agregar una tarea de mantenimiento (3), que es procesada y
validada por el gestor (4), los cambios se guardan en la entidad (5) y el
gestor se encarga de actualizar la interfaz Tareas de mantenimiento (6). El
actor realiza una consulta de una tarea (7), el gestor procesa la consulta (8),
y se comunica con la entidad Tarea de Mantenimiento que captura la
información (9), para que finalmente el gestor envíe la consulta a la interfaz
(10). El actor selecciona la opción Asignar herramientas y materiales en la
interfaz Tareas de Mantenimiento (11), el gestor procesa el evento y llama la
interfaz Asignar Herramientas y Materiales (12), luego el actor asigna o
elimina una herramienta (13), se procesa el evento (14),se guardan los
cambios realizados en la entidad (15), para que finalmente el gestor actualiza
la interfaz con los cambios realizados (16). Cuando el actor consulta un
registro en la interfaz Asignar Herramientas Materiales (17), se procesa el
evento (18), luego se recopila la información en las entidades Herramienta y
Asignar Herramienta (19,20), finalmente el gestor muestra la consulta en la
interfaz (21). El actor selecciona la opción tipo de activo en la interfaz Tareas
de Mantenimiento (22), se procesa el evento y se llama la interfaz
correspondiente (23), el actor ingresa o elimina un tipo de activo (24), se
procesa el evento (25), se guardan los cambios en la entidad (26) y
finalmente se actualiza la interfaz Asignar Herramientas y Materiales (27).
Cuando el actor consulta un tipo de activo (28), el gestor procesa el evento
(29) y se recopila la información en las entidades (30, 31,32), y por último el
gestor muestra la consulta en la interfaz. En la figura 4.67 se muestra el
diagrama de colaboración del caso de uso Asignar Tipos de Activos.
158
Figura 4.67 Diagrama de Colaboración del Caso de Uso “Tareas de

Mantenimiento”
159
 Diagrama de Colaboración del Caso de Uso “Permisología”

El actor activa la interfaz permisologia (1), después el gestor carga la
interfaz al usuario (2), el usuario inserta, modifica o elimina un registro (3) ,el
gestor procesa y valida el evento (4), guarda los cambios en la entidad
permisologia (5)y finamente los cambios realizados se actualiza en la interfaz
permisologia (6). El actor realiza una consulta de un registro (7), el gestor
procesa el evento (8) y se comunica con las entidades correspondientes (9,
10,11), y finalmente el gestor muestra la consulta al actor a través de la
interfaz Permisologia (12). En la figura 4.68 se ilustra el diagrama de
colaboración del caso de uso Permisologia.
Figura 4.68 Diagrama de Colaboración del Caso de Uso “Permisología”

160
4.2.3 Flujo de Trabajo de Diseño
Es en este flujo se moldea el sistema y se establece su forma, es decir,

su arquitectura ello con la intención de dar soporte a sus requisitos
funcionales y no funcionales. Es importante señalar además que el diseño se
vale del modelo de análisis obtenido en el flujo de igual nombre, el cual
proporciona una compresión detallada de los requisitos, esto esencia para
los propósitos establecidos por el diseño.
El diseño se plantea la misión de establecer adecuadas entradas y

correctos puntos de partida para el flujo de implementación mediante la
captura de requisitos o subsistemas individuales, interfaces y clases. A
continuación en la tabla 4.33 se hace una comparación entre el modelo de
análisis y diseño
Tabla 4.33: Comparación entre el modelo de análisis y modelo de diseño(1/2)

Modelo de análisis Modelo de Diseño
Modelo conceptual, porque es Modelo físico, porque es un
una abstracción del sistema y permite plano de la implementación.
aspectos de la implementación
Genérico respecto al diseño No genérico, específico para
(aplicable a varios diseños). una implementación
Tres estereotipos conceptuales Cualquier número de
sobre las clases: Control, Entidad e estereotipos (físicos) sobre las
Interfaz clases, dependiendo del lenguaje
de implementación
Menos caro de desarrollar Más caro de desarrollar
Dinámico (no muy centrado en la Dinámico (muy centrado en
secuencia). las secuencias).
Bosquejo del diseño del sistema, Manifiesto del diseño del
incluyendo su arquitectura sistema, incluyendo su
arquitectura (una de sus vistas).
161
Tabla 4.33: Comparación entre el modelo de análisis y modelo de diseño

(2/2)
Modelo de análisis Modelo de Diseño
Creado principalmente como Creado principalmente como
“trabajo de a pie” en talleres o “programación visual” en
similares ingeniería de ida y vuelta; el
modelo de diseño es realizado
según la ingeniería de ida y vuelta
con el modelo de implementación.
Menos capas Mas capas
Puede no estar mantenido Debe estar mantenido
durante todo el ciclo de vida del durante todo el ciclo de vida del
software. software
Define una estructura que es Da forma al sistema mientras
una entrada esencial para modelar el que intenta preservar la estructura
sistema incluyendo la creación del definida por el modelo de análisis
modelo de diseño lo más posible
4.2.3.1 Arquitectura del Sistema
La arquitectura del sistema se divide en cuatro capas, la capa

específica de la aplicación que comprender los paquetes: Listados de
Activos, Clases de Activos, Tipos de Activos, Registro de Mantenimiento,
Planificación de Mantenimiento, Tipos y Tareas de Mantenimiento,
Herramientas, Nagios, Frecuencia, Roles del Usuario, Modulo, Configuración
de usuarios, Consultar Marcas y Modelos, Calendario de Tareas, Reportes
oficiales y Permisologia.
La capa general de la aplicación que contempla el Login del sistema

que se comunica con el Directorio Activo PDVSA y Nagios, el paquete Login
se conecta con la capa intermedia.
162
La capa del software del sistema y la capa intermedia constituyen los

cimientos de un sistema, ya que toda la funcionalidad descansa sobre
software como sistemas operativos, bases de datos, software de
comunicación y lenguajes de programación. En la capa intermedia se
encuentra el navegador web que procesa las peticiones del cliente, el
servidor HTTP Apache 2, el manejador de la base de datos PostgreSQL 9.
En este nivel también se encuentra, el lenguaje JavaScript y PHP 5 que
ejecuta la funcionalidad que tiene el sistema y Lenguaje de Hoja de Estilo en
Cascada (CSS3). Cada uno de estos lenguajes tienes sus dependencias en
el caso de PHP y CSS los framework Codeigniter y Bootstrap
respectivamente.
Para terminar tenemos la capa del software conformada por el sistema

operativo Debian GNU/Linux y también por el subsistema TCP/IP que
representa el protocolo de comunicación entre el servidor y el cliente. El
diagrama de capa del sistema se ilustra en la figura 4.69
4.2.3.2 Diagrama de Clase de Diseño
Una clase diseño es una abstracción sin costuras de una clase o

construcción similar en la implementación del sistema. El lenguaje utilizado
para especificar una clase de diseño es lo mismo que el lenguaje de
programación (parámetros, atributos, tipos).Los métodos (o lo que es lo
mismo, las realizaciones de operaciones) de una clase del diseño tienen
correspondencia directa con el correspondiente método en la implementación
de las clases (esto es, en el código).
163
El diagrama de clases es el principal diagrama de diseño para un

sistema. Los diagramas de clases de diseño muestran la funcionalidad del
sistema mediante clases relacionadas entre sí por medio de líneas, haciendo
la especificación de las instancias que participan en la relación. Las
relaciones de aquellas clases del diseño implicadas con otras clases, a
menudo tienen un significado directo cuando la clase es implementada.
Figura 4.69: Diagrama de Capas

164
A continuación en la figura 4.70 se ilustra los diagramas de clases

diseño del sistema identificando sus atributos, métodos y las relaciones que
existen entre cada una de ellas.
Figura 4.70 Diagrama de Clases de Diseño (1/6)

165

166

167

168

169

4.2.3.3 Diseño de la Base de Datos
En esta fase del proyecto se pretende el desarrollo de la estructura

interna de la aplicación, por lo que se hace indispensable el diseño de la
base de datos, como una de las partes más importantes de la estructura, ya
170
que esta es la que permite almacenar los datos de manera que puedan ser
manejados de una forma óptima.
El modelo de datos que se diseñó sigue con los lineamientos de

estandarización exigido por Base de Datos Oriente, que se encarga de
establecer la nomenclatura de los objetos de los manejadores de base de
datos para AIT. A continuación se ilustra el modelo de datos del sistema de
información, se utilizó la herramienta de modelado de datos Power Designer,
en una máquina virtual para la elaboración del modelo. A continuación en la
figura 4.71 se ilustra la base de datos del sistema, es necesaria destacar
que las tablas c001_activo, i003t_modelo, i004t_marca y i001t_persona
provienen de la base de datos SIGA-AIT.
4.2.3.4 Diccionarios de Datos
Un diccionario de datos contiene metadatos, es decir, datos acerca de

los datos. El esquema de una tabla es un ejemplo de metadatos. Un sistema
de base de datos consulta el diccionario de datos antes de leer o modificar
datos reales.
Para ser más específico en un diccionario de datos se guarda la

información referente a los nombres de las relaciones, los nombres de los
atributos de cada relación, los dominios y las longitudes de los atributos, los
nombres de las vistas definidas en la base de datos y las decisiones de esas
vistas y las restricciones de integridad (restricciones de las claves)
171
Figura 4.71: Base de Datos del Sistema

172
 Tabla persona
En la tabla 4.34 se almacena todos los datos relacionado a una

persona.
Tabla 4.34: Persona (1/2)

Nomenclatura i001t_persona
Campo Tipo de Tamaño Descripción
Dato
co_persona numeric 9 Código secuencial de
la persona. Clave
primaria
nu_cedula numeric 10 Cedula de identidad de
la persona
co_organizacion numeric 9 Código secuencial de
la organización
co_jerarquia_persona numeric 9 Código que representa
la dependencia de la
persona con respecto
a otra persona
(dependencia
recursiva).
tx_nombre varchar 40 Nombre de la persona
tx_apellido varchar 40 Apellido de la persona
tx_indicador_red varchar 30 Indicador de red de la
persona
tx_correo_electronico varchar 250 Correo electrónico de
la persona
tx_telefono_oficina varchar 40 Número de teléfono de
la persona
tx_oficina varchar 80 Numero de oficina de
la persona
in_vip varchar 1 Indica si la persona
tiene perfil VIP
(gerente)
in_analista varchar 1 Campo bandera que
expresa si la persona
es un analista
173
Tabla 4.34: Persona (2/2)

Nomenclatura i001t_persona
Campo Tipo de Dato Tamaño Descripción
tx_tlf_celular varchar 24 Número de teléfono
celular de la persona
in_logica varchar 1 Campo bandera
empleado para
verificar si la persona
está activa o no
tx_cargo varchar 250 Nombre del cargo que
posee la persona
co_servicio_correo numeric 9 Código del servidor
de correo
tx_contraseña varchar 100 Contraseña de la
persona
 Tabla Clase de Activo
En la tabla 4.35 se almacena las clases de los activos.
Tabla 4.35: Clase de Activo

Nomenclatura i007t_clase_activo
Dato
co_clase_activo numeric 9 Código secuencialde
la clase del activo
tx_clase_activo varchar 50 Nombre de la clase
del activo
tx_abreviatura varchar 3 Abreviatura de la
clase del activo
 Tabla Clase de Activo Detalle
En la Tabla 4.36 se almacena las subcategorías de las clases de un

activo.
174
Tabla 4.36: Clase de activo detalle

Nomenclatura i006t_clase_activo_detalle
Dato
co_clase_activo_detalle numeric 9 Código secuencial
de la clase del
activo
tx_clase_activo_detalle varchar 50 Nombre de la clase
del activo detalle
tx_abreviatura varchar 3 Abreviatura de la
clase del activo
co_clase_activo numeric 9 Código de la clase
del activo
 Tabla Activo
En la tabla 4.37 se almacena los datos de un activo.
Tabla 4.37: Activo (1/3)

Nomenclatura c001t_activo
Dato
co_activo numeric 9 Código que identifica
un activo de manera
única. Clave Primaria
in_valor varchar 1 Especifica si el activo
es de alto o bajo
valor
tx_serial varchar 30 Serial del activo
tx_nota varchar 600 Notas para el activo
In_caso varchar 1 Si el activo puede
generar un caso o
no. Por ejemplo,
servidores o equipos
relacionados con
tareas de monitoreo
175

Dato
co_modelo numeric 6 Código del modelo
seleccionado para el
activo
co_uso numeric 6 Código del uso
activo
co_estado_activo numeric 2 Código del estado
activo
co_ubicacion_general numeric 9 Código ubicación
general
co_organizacion numeric 9 Código secuencial de
la organización
co_activo_padre numeric 9 Código de un activo
padre
tx_etiqueta varchar 10 Etiqueta del activo
co_deposito numeric 6 Código del depósito
activo
tx_url_acuse varchar 255 Dirección Web del
acuse de recibo de
dicho activo.
fe_inicio_asig timestamp 6 Fecha de inicio de
asignación de un
activo a un usuario
fe_fin_asig timestamp 6 Fecha en que caduca
la asignación de un
activo a un usuario.
nu_deposito_anterior numeric 6 Indica el ultimo
depósito en que se
encontraba un activo
antes de ser
asignado a la
persona de Soporte
Integral
176
Dato
fe_actualizacion timestamp 6 Fecha de
Actualización
tx_ubicacion_activo varchar 255 Ubicación del activo
co_tipo_activo numeric 6 Categoría del activo
tx_direccion varchar 300 Dirección del activo
co_activo_original numeric 9 No tiene comentarios
en SIGA-AIT
co_clase_activo_detalle numeric 6 Código de la clase de
activo detalle
nu_prioridad numeric 6 Numero de Prioridad
tx_criticidad varchar 50 Nombre de la
Criticidad
tx_sap varchar 40 Código SAP
co_parte numeric 9 Código de la parte
 Tabla Marca
En la tabla 4.38 se almacena las marcas registradas por cada
categoría.
Tabla 4.38: Marca (1/2)

Nomenclatura i004t_marca
Dato
co_marca numeric 4 Código que
identifica la marca
de un activo de
manera única.
Clave primaria
co_categoria_activo numeric 4 Código de la
categoría
relacionada con
esa marca
Tabla 4.38: Marca (2/2)
177
Nomenclatura i004t_marca
Dato
tx_nombre varchar 255 Nombre de la
marca
co_categoria_activo_original numeric 4 Sin comentarios
en SIGA-AIT
co_marca_original numeric 4 Sin comentarios
en SIGA-AIT
 Tabla Modelo
En la tabla 4.39 se almacena los modelos registrados por cada marca.
Tabla 4.39: Modelo

Nomenclatura i003t_modelo
Dato
co_modelo numeric 4 Código que identifica el
modelo de un activo de
manera única
co_marca numeric 6 Código de la marca
relacionada con ese
modelo
tx_nombre varchar 255 Nombre del modelo
tx_numero_parte varchar 255 Número de la parte
co_modelo_original numeric 6 Sin comentarios en
SIGA-AIT
co_marca_original numeric 4 Sin comentarios en
SIGA-AIT
 Tabla Frecuencia de Mantenimiento

178
En la Tabla 4.40 se almacena la información de la frecuencia que se

realizan las tareas de mantenimiento a los activos.
Tabla 4.40: Frecuencia de Mantenimiento

Nomenclatura c003t_frecuencia_mtto
co_frecuencia_mtto numeric 9 Atributo clave,
autoincremental,
frecuencia de
mantenimiento
co_activo numeric 9 Código del activo.
co_tipo_mtto numeric 4 Código del
mantenimiento tipo
nu_frecuencia_mtto numeric 2 Frecuencia del
mantenimiento
co_unidad_tiempo numeric 2 Código de la unidad de
tiempo
co_tarea_mtto numeric 9 Código de la tarea de
mantenimiento
 Tabla Plan de Mantenimiento
En la tabla 4.41 se almacena la información básica de los planes de

mantenimiento a los activos.
Tabla 4.41: Plan de Mantenimiento (1/2)

Nomenclatura c001t_plan_mtto
co_plan_mtto numeric 9 Atributo clave,
autoincremental, código
del plan de
mantenimiento
Tabla 4.41: Plan de Mantenimiento (2/2)
179
Nomenclatura c001t_plan_mtto
co_frecuencia_mtto numeric 9 Código de la frecuencia
del mantenimiento
tx_descripcion_mtto varchar 500 Descripción del
mantenimiento realizado
fe_planificada timestamp 6 Fecha planificada
fe_reprogramada timestamp 6 Fecha reprogramada
fe_real_culminada numeric 6 Fecha real culminada de
mantenimiento
in_estado_mtto varchar 1 Campo bandera que
indica el estado del
mantenimiento del
activo
co_usuario numeric 9 Código del usuario
 Tabla Tarea de Mantenimiento
En la tabla 4.42 contiene la información relacionada con los tipos de

tareas de mantenimiento.
Tabla 4.42: Tarea de mantenimiento

Nomenclatura i002_tarea_mtto
co_tarea_mtto numeric 9 Atributo clave,
autoincremental,
código de la tarea de
mantenimiento
tx_tarea_mtto varchar 150 Nombre de la tarea
tx_descripcion_mtto numeric 150 Descripción de la tarea
fe_tiempo_tarea timestamp Tiempo estimado de la
tarea.
co_tipo_mtto numeric 4 Código del tipo de
mantenimiento
180
 Tabla Tareas de mantenimiento y herramientas

En la tabla 4.43 se almacena la asociación entre las tareas de
mantenimiento con las herramientas.
Tabla 4.43: Tareas de mantenimiento y herramienta

Nomenclatura i004t_tarea_mtto_herramienta
Dato
co_tarea_mtto_herramienta numeric 9 Código secuencial.
Clave Primaria
co_tarea_mtto numeric 9 Código de la tarea
de mantenimiento
co_herramienta numeric 6 Código de la
herramienta
 Tabla Tareas de mantenimiento y Tipo de activo

En la tabla 4.44 se almacena la asociación entre las tareas de
mantenimiento y los tipos de activos.
Tabla 4.44: Tareas de mantenimiento y tipo de activo

Nomenclatura i008t_tarea_mtto_activo
Dato
co_tarea_mtto_activo numeric 9 Código secuencial.
Clave Primaria
co_tarea_mtto numeric 9 Código de la tarea
de mantenimiento
co_clase_activo_detalle numeric 9 Código del tipo de
activo
181
 Tabla Tipo de Mantenimiento
En la Tabla 4.45 contiene la información relacionada con los tipos de

mantenimiento preventivo.
Tabla 4.45: Tipo de Mantenimiento

Nomenclatura i001t_tipo_mtto
Dato
co_tipo_mtto numeric 4 Atributo clave,
autoincremental, código
del tipo de
mantenimiento
tx_tipo_mtto varchar 50 Nombre del tipo de
mantenimiento.
nu_nivel_mtto numeric 2 Nivel de la tarea, rango
del 1 al 5.
tx_descripcion_mtto varchar 2000 Descripción de la tarea.
 Tabla Unidad de Tiempo

En la tabla 4.46 se almacenan las frecuencias de mantenimiento
Tabla 4.46: Unidad de Tiempo

Nomenclatura i005t_unidad_tiempo
Dato
co_unidad_tiempo numeric 2 Código secuencial
de la unidad de
tiempo
tx_unidad_tiempo varchar 50 Nombre de la unidad
de tiempo
182
 Tabla Herramienta
En la tabla 4.47 se almacena la información de las herramientas para
realizar las tareas de mantenimiento.
Tabla 4.47: Herramienta

Nomenclatura i003t_herramienta
Dato
co_herramienta numeric 9 Código secuencial,
de la herramienta
tx_herramienta varchar 200 Descripción de la
herramienta.
 Tabla Histórico de Monitoreo

En la tabla 4.48 se almacena los datos suministrados por el sistema
Nagios.
Tabla 4.48: Histórico de Monitoreo (1/3)

Nomenclatura x001t_historico_monitoreo
Dato
co_registro_monitoreo numeric 9 Atributo clave,
autoincremen-tal.
Código del
servicio de
monitoreo
tx_nombre_servicio_nagios varchar 100 Nombre del
servicio Nagios
tx_direccion_ip varchar 20 Dirección IP
nu_porcent_toner_negro numeric 3 Porcentaje del
tóner negro
nu_porcent_deposito_toner numeric 3 Porcentaje del
depósito del tóner
183

Dato
nu_porcent_tambor_negro numeric 3 Porcentaje del
tambor
fotoconductor
negro
nu_porcent_revelador_negro numeric 3 Porcentaje del
revelador negro
nu_porcent_toner_cyan numeric 3 Porcentaje del
tónerCyan
nu_porcent_tambor_cyan numeric 3 Porcentaje del
tambor
fotoconductor
cyan
nu_porcent_revelador_cyan numeric 3 Porcentaje del
revelador cyan
nu_porcent_toner_magenta numeric 3 Porcentaje del
tóner magenta
nu_porcent_tambor_magenta numeric 3 Porcentaje del
tambor
fotoconductor
magenta
nu_porcent_revelador_magent numeric 3 Porcentaje del
a revelador
magenta
nu_porcent_toner_yellow numeric 3 Porcentaje del
tóner amarillo
nu_porcent_tambor_yellow numeric 3 Porcentaje del
tambor
fotoconductor
amarillo
nu_porcent_revelador_yellow numeric 3 Porcentaje del
revelador amarillo
nu_total_contador numeric 3 Número total de
impresión
184

Dato
tx_estado varchar 800 Descripción
detallada del
estado del
servicio de nagios
fe_fecha_monitoreo Timesta Fecha del registro
-mp de monitoreo
nu_porcent_fusor numeric 3 Porcentaje de la
unidad fusora
in_estado_host varchar 1 Estado del host
off: 0, on: 1
in_estado_servicio varchar 1 Estado del
serviciocritical: 2,
warning: 1 y ok: 0
 Tabla Usuario
En la tabla 4.49 se almacena los datos del usuario que ingresan al
sistema.
Tabla 4.49: Usuario

Nomenclatura i001t_usuario
Dato
co_usuario numeric 9 Atributo clave,
autoincremental.
Código del usuario.
tx_indicador varchar 25 Nombre del indicador
PDVSA
co_nivel_usuario numeric 9 Código del nivel de
usuario
tx_nombre varchar 50 Nombre del usuario
tx_apellido varchar 50 Apellido del usuario
185
 Tabla Nivel de usuario

En la tabla 4.50 se almacena los roles del usuario de los usuarios.
Tabla 4.50: Nivel de Usuario

Nomenclatura i003t_nivel_usuario
Dato
co_nivel_usuario numeric 9 Atributo clave,
autoincremental.
Código del nivel de
usuario
tx_nivel varchar 100 Nombre del nivel de
usuario
 Tabla Modulo
En la Tabla 4.51 se almacena el código de los módulos del sistema.
Tabla 4.51: Modulo

Nomenclatura i002t_modulo
Dato
co_modulo numeric 9 Atributo clave,
autoincremental.
Código del módulo
del sistema
tx_modulo numeric 100 Nombre del modulo
 Tabla Permisologia
En la tabla 4.52 se almacena la permisologia de los roles de los
usuarios a los módulos del sistema.
186
Tabla 4.52Permisologia
Nombre i004t_permisología
Dato
co_permisologia numeric 4 Código secuencial
de la permisologia
co_nivel_usuario numeric 9 Código del nivel de
usuario
co_modulo numeric 9 Código del modulo
in_entrar varchar 1 Código bandera
verdadero o falso.
4.2.4 Implementación
La mayor parte de la arquitectura del sistema es capturada durante el

diseño el propósito principal de la implementación es desarrollar la
arquitectura y el sistema como un todo. Este punto del proyecto se toma
como referencia para la fase denominada de construcción, donde se muestra
la arquitectura completa del sistema con su respectivo código fuente
generado con PHP y JavaScript.
4.2.4.1 Identificación de Componentes de la arquitectura
El modelo de despliegue es un modelo de objetos que describe la

distribución física del sistema en términos de cómo se distribuye la
funcionalidad entre los nodos de computo. El modelo de despliegue se utiliza
como entrada fundamental en las actividades de diseño e implementación
debido a que la distribución del sistema tiene una influencia principal en su
diseño. El modelo de despliegue en sí mismo representa una
correspondencia entre la arquitectura software y la arquitectura del sistema
(el hardware). El elemento primordial del hardware es un nodo, que es un
187
nombre genérico para todo tipo de recurso de cómputo. En UML un cubo

representa un nodo y una línea que asocie a dos cubos representa una
conexión entre ellos.
Para implementar la arquitectura del software, se identificaron los

componentes en la figura 4.72, en ella se muestra el servidor de la
aplicación en el cual contiene el servidor Web Apache 2 que permite la
distribución de las paginas ,el motor PHP 5 para ejecutar los script que
contienen la funcionalidad del sistema y la aplicación SISGESBAS que se
integra al framework Codeigniter.
Adicionalmente el servidor de la aplicación se conecta con el Servidor

de Autentificación y Autorización que permite ingresar al sistema, el servidor
de la base de datos en el cual es una conexión remota, en donde se
encuentra la base de datos SISGESBAS y SIGA-AIT, y del mismo modo
existe una conexión remota al servidor del sistema de Monitoreo Nagios.
Adicionalmente, en la misma figura, se observa al actor provisto de

navegador Web encargado de generar el documento HTML mediante el cual
los usuarios podrán visualizar e interactuar con la aplicación. El Cliente y el
Servidor se conectan a través de la Intranet mediante el protocolo de
transmisión HTTP.
4.2.4.2 Implementación de la Arquitectura
La implementación es el centro durante las iteraciones de

construcción, aunque también se lleva a cabo trabajo de implementación
durante la fase de elaboración, para crear la línea base ejecutable de la
188
arquitectura, y durante la fase de transición, para defectos tardíos como los

encontrados con distribuciones beta del sistema. En la figura 4.73 se
muestra la estructura básica que contendrá todos los formularios dela
aplicación web.
Figura 4.72: Diagrama de Despliegue del Sistema

4.2.5 Conclusión de la fase de Elaboración
En esta fase se completaron los flujos de trabajo de requisitos,

análisis y diseño, además se obtuvo una clara representación de la
arquitectura del sistema y de la base de datos. Finalmente se implementó
189
parte del sistema como punto de partida para la siguiente fase denominada
de construcción en el cual se limitara a codificar y probar los componentes
del software.
Figura 4.73 Plantilla del sistema

190
4.3 Fase Construcción
El propósito primordial de esta fase es dejar un producto software en su

versión operativa inicial, es decir en una versión alfa del sistema. El producto
debería tener la calidad para su aplicación y asegurarse de cumplir los
requisitos. La fase de construcción está integrada por dos flujos de trabajo
como lo son el de implementación y el de prueba, en implementación
observaremos los subsistemas que componen la aplicación además de las
interfaces, y en prueba se evaluara la calidad del producto desarrollado para
conocer con certeza si se logró el funcionamiento deseado de la aplicación.
A continuación en la figura 4.74 se presenta el Proceso Unificado de

Desarrollo de Software, resaltando la Fase de Construcción.
Figura 4.74:Fase de Construcción

4.3.1 Herramientas de Desarrollo de Software Utilizado

Durante el desarrollo de la fase de construcción se utilizaron
herramientas de computación, herramientas de modelado y lenguajes de
programación que hicieron posible la creación de la aplicación diseñada en la
191
fase de elaboración, los detalles de la codificación del software está incluida

en el Anexo A.
 Debian 8: es un sistema operativo mantenido totalmente por voluntarios

dedicada a desarrollar software libre y promocionar los ideales de la
comunidad del software libre. El Proyecto Debian comenzó en 1993,
cuando Ian Murdock hizo una invitación a todos los desarrolladores de
software a contribuir a una distribución completamente coherente basada
en él, entonces relativamente nuevo, núcleo Linux. Esta distribución de
Linux está formada por un gran número de paquetes. Cada paquete en
la distribución contiene ejecutables, scripts, documentación e información
de configuración, y tiene un encargado, quien es el principal responsable
de mantener el paquete actualizado, hacer un seguimiento de los
informes de fallo y comunicarse con los autores principales del programa
empaquetado.
 Servidor Web Apache 2: el servidor HTTP Apache es un servidor web

HTTP de código abierto, para plataformas Unix (BSD, GNU/Linux, etc.),
Microsoft Windows, Macintosh y otras, que implementa el protocolo
HTTP/1.12 y la noción de sitio virtual. El servidor Apache es desarrollado
y mantenido por una comunidad de usuarios bajo la supervisión de la
Apache Software Foundation dentro del proyecto HTTP Server (httpd).
 PostgreSQL: es un potente sistema de base de datos objeto-relacional,

PosgreSQL es un proyecto de código abierto disponible bajo licencia
BSD,lo que permite su uso, redistribución, modificación con la única
restricción de mantener el copyright del software a sus autores, en
concreto el PostgreSQL Global Development Group y la Universidad de
California, PosgreSQL es compatible con gran parte del estándar SQL y
ofrece muchas características modernas como consultas complejas,
192
claves foráneas, triggers (disparadores), vistas, integridad transaccional,

entre otros.
 Pgadmin III: es la plataforma de administración y desarrollo de código

abierto mas popular para PostgreSQL. La aplicación se puede usar en
plataforma Linux, FreeBSD, Solaris, macOS y Windows para administrar
PostgreSQL 9.2 y versiones posteriores, así como versiones comerciales
y derivadas de PostgreSQL, como EDB Postgres Advanced Server.
 Power Designer 12.5: es una herramienta para el análisis, diseño

inteligente y construcción sólida de una base de datos y un desarrollo
orientado a modelos de datos a nivel físico y conceptual, que da a los
desarrolladores Cliente/Servidor la más firme base para aplicaciones de
alto rendimiento. Se utilizó Virtual Box para emular el software Power
Designer en el sistema operativo Debian.
 Navicat : es una poderosa herramienta de gestión y diseño de bases de

datos para Windows, Mac y Linux. Con una interfaz gráfica intuitiva para
que el usuario administre con gran facilidad MySQL, SQL Server, SQLite,
Oracle y PostgreSQL. Cuenta con un Explorador como interfaz gráfica de
usuario soportando múltiples conexiones para bases de datos locales y
remotas. Su diseño está pensado para satisfacer las diferentes
necesidades de un amplio sector del public; desde administradores y
programadores de bases de datos a diferentes empresas que dan soporte
y o comparten información con clientes o socios.
 Javascript: es un lenguaje de programación interpretado, dialecto del

estándar ECMAScript. Se define como orientado a objetos, basado en
prototipos, imperativo, débilmente tipado y dinámico. Se utiliza
principalmente en su forma del lado del cliente, implementado como parte
193
de un navegador web permitiendo mejoras en la interfaz de usuario y

páginas web dinámicas, en bases de datos locales al navegador. Todos
los navegadores modernos interpretan el código JavaScript integrado en
las páginas web. Para interactuar con una página web se provee al
lenguaje JavaScript de una implementación del Document ObjectModel
(DOM).
 AJAX: (Asynchronous JavaScript and XML), no es un lenguaje de

programación, sino una forma particular de implementar JavaScript. Ajax
permite realizar peticiones HTTP de fondo al servidor web y actualizar
dinámicamente el contenido de la página con la respuesta obtenida, sin
que el usuario espere mientras recarga toda la página, todo esto de forma
transparente para el usuario con peticiones asíncronas realizadas desde
JavaScript. El uso de Ajax evita el patrón "click-wait-refresh" (clic, esperar,
refrescar contenido) que es el patrón típico en páginas web y obliga al
usuario a esperar mientras carga toda una nueva página, al implementar
Ajax el usuario puede seguir interactuando con la aplicación web mientras
los datos cargan, lo que permite la creación de verdaderas aplicaciones
interactivas en la web. Las peticiones realizadas al servidor son servidas
a través de un lenguaje de programación de lado servidor destinado para
tal fin, tal es el caso de PHP.
 JSON: (JavaScript ObjectNotation - Notación de Objetos de JavaScript)

es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple
para humanos, mientras que para las máquinas es simple interpretarlo y
generarlo. Está basado en un subconjunto del Lenguaje de Programación
JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es
un formato de texto que es completamente independiente del lenguaje
pero utiliza convenciones que son ampliamente conocidos por los
194
programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java,

JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que
JSON sea un lenguaje ideal para el intercambio de datos.
 Jquery: es una biblioteca de JavaScript, creada inicialmente por John

Resig, que permite simplificar la manera de interactuar con los
documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar
animaciones y agregar interacción con la técnica AJAX a páginas web.
Fue presentada el 14 de enero de 2006 en el BarCamp NYC. JQuery es
la biblioteca de JavaScript más utilizada. JQuery es software libre y de
código abierto, posee un doble licenciamiento bajo la Licencia MIT y la
Licencia Pública General de GNU v2, permitiendo su uso en proyectos
libres y privados, jQuery, al igual que otras bibliotecas, ofrece una serie de
funcionalidades basadas en JavaScript que de otra manera requerirían de
mucho más código, es decir, con las funciones propias de esta biblioteca
se logran grandes resultados en menos tiempo y espacio.
 PHP 5.6: es un lenguaje de programación de uso general de código del

lado del servidor originalmente diseñado para el desarrollo web de
contenido dinámico. Se puede incorporar directamente en el documento
HTML en lugar de llamar a un archivo externo que procese los datos. El
código es interpretado por un servidor web con un módulo de procesador
de PHP que genera la página Web resultante. PHP puede ser usado en la
mayoría de los servidores web al igual que en casi todos los sistemas
operativos y plataformas sin ningún costo.
 HTML5 :(Hyper Text MarkupLanguaje), en español Lenguaje de Marcado

de Texto. Es la quinta revisión importante del lenguaje básico de la World
Wide Web, HTML. Google Chrome es pionero en soporte HTML5 y es,
actualmente, el navegador que brinda mayor soporte a esta versión de
195
HTML. El desarrollo de este lenguaje de marcado es regulado por el

Consorcio W3C.
 CCS3: las hojas de estilo nos permiten definir de manera eficiente la

representación de nuestras páginas y es uno de los conocimientos
fundamentales que todo diseñador web debe manejar a la perfección para
realizar su trabajo. La primera versión de CSS fue publicada a fines del
año 1996 y fue logrando popularidad y aceptación hasta llegar a la
versión 2.1, estándar actual que ofrece gran compatibilidad con la
mayoría de los navegadores del mercado. A partir del año 2005 se
comenzó a definir el sucesor de esta versión, al cual se lo conoce como
CSS3 o Cascading Style Sheets Level 3. Actualmente en definición, esta
versión nos ofrece una gran variedad de opciones muy importantes para
las necesidades del diseño web actual. Desde opciones de sombreado y
redondeado, hasta funciones avanzadas de movimiento y transformación.
 Bootstrap 3.3.7: es un framework desarrollado y liberado por Twitter que

tiene como objetivo facilitar el diseño web. Permite crear de forma sencilla
webs de diseño adaptable, es decir, que se ajusten a cualquier dispositivo
y tamaño de pantalla. Contiene plantillas de diseño con tipografía,
formularios, botones, cuadros, menús de navegación y otros elementos
de diseño basado en HTML y CSS, así como, extensiones de JavaScript.
 Codeigniter 3.1.5: es un framework para el desarrollo de aplicaciones

web que está basado en el patrón MVC y está construido en PHP versión
5. Su objetivo es permitir el desarrollo de proyectos mucho más rápido de
lo que sería si se escribiese el código desde cero, proporcionando un
amplio conjunto de librerías para tareas comunes y necesarias, así como
una interfaz y estructura lógica sencilla para acceder a estas bibliotecas,
CodeIgniter permite al desarrollador enfocarse creativamente en el
196
proyecto, reduciendo al mínimo la cantidad de código necesario para una

determinada tarea; además, es un framework con una pequeña huella
que brinda un rendimiento excepcional comparado con otras alternativas,
y posee una documentación clara y exhaustiva
 Visual Studio Code: es un editor de texto/IDE de programación

desarrollado y lanzado por Microsoft en 2015 como una herramienta de
código abierto, un hito impensable para Microsoft y para su marca Visual
Studio. Este editor se caracteriza por ser bastante más modular que el
anterior. Por defecto, el editor cuenta con las funciones más básicas y
elementales y está preparado para adaptarse a los principales lenguajes
de programación más utilizados, como HTML/CSS o C. Sin embargo, su
mayor potencial se encuentra en las extensiones, y es que desde el
mismo editor vamos a poder acceder a una gran variedad de extensiones
y complementos que nos va a permitir dotarle de las funciones y
características que necesitemos, sin sobrecargar el editor.
 Brackets: es un editor open source que se basa en Google Chrome y

que ofrece muchas características interesantes a explorar. Es ligero, es
potente, es moderno y cuenta con unas herramientas visuales que te
facilitarán muy mucho el desarrollo. Además, con este editor es posible
convertir un PSD en HTML.
 Firefox Developer Edition: es una versión de Firefox preparada para

desarrolladores, incluye todas las herramientas necesarias para empezar
a trabajar en entorno web, contiene un depurador JavaScript, un editor de
estilo CSS, vista de diseño responsivo, editor web de audio, monitor de
red, herramientas de rendimiento, herramientas de edición visual y
muchos otros complementos de desarrollo web.
197
 UMLet : es una herramienta de código abierto que permite dibujar

diagramas UML de manera rápida y sencilla, esta herramienta permite
construir diagramas de secuencia, diagrama de paquetes, diagrama de
actividad, diagrama de componentes, diagrama de clases, diagrama de
actividad, casos de uso, y además permite crear tus propios elementos
UML. Está disponible en las plataforma Windows, Linux y OS X.
4.3.2 Flujo de Trabajo de implementación
En este flujo se realiza la culminación de la implementación de la

arquitectura del sistema, en conjunto con la codificación del resto de los
componentes de la aplicación, con el fin de llegar a una versión del software
que pueda ser transmitida a la comunidad de usuarios. Aquí se debe finalizar
la construcción del software para que este cumpla con todos los requisitos
estipulados en las fases anteriores.
4.3.2.1 Diseño de la Interfaz de Usuario
A continuación se muestra la descripción de las interfaces en la

aplicación web.
 Interfaz Login
En la figura 4.75se muestra la interfaz de inicio de sesión del sistema

SISGESBAS .Esta interfaz es utilizada para el control de acceso al sistema,
en el centro de la pantalla se encuentra los campos, usuario y contraseña
que permiten el ingreso al sistema, si los datos ingresados por el usuario son
incorrectos se mostrara un aviso en la pantalla, una vez que el usuario
ingrese los datos correcto al sistema, el usuario podrá ingresar al sistema y
198
se mostrara el menú de opciones en la parte izquierda de la pantalla según

los privilegios que el usuario posea.
Figura 4.75: Interfaz Login.

En la figura 4.76 se mostrara el código fuente de la interfaz login,

específicamente el código HTML de la vista.
 Interfaz Clase de Activos
En la figura 4.79 se ilustra la interfaz clases de activo, que permite

gestionar la clase de activos que conforman la plataforma AIT,además
permite visualizar la información detallada de estos registros en la tabla.
 Interfaz Tipos de Activos
En la interfaz mostrada en la figura 4.80 se puede visualizar los

campos Tipo de activo, clase de activo y abreviatura a partir de los cuales el
199
usuario puede realizar las operaciones de un CRUD, las modificaciones

hechas por el usuario se actualizan en la tabla del centro de la interfaz.
Figura 4.76: Código fuente HTML de la vista Login

A continuación en la figura 4.77 se muestra el código fuente del

controlador de la interfaz Login
200
Figura 4.77: Código fuente del Controlador Login

A continuación en la figura 4.78 se muestra el código fuente del

modelo, de la interfaz Login
201
Figura 4.78: Código fuente del Modelo Login

 Interfaz Listado de Activos: En esta ventana se muestra una tabla en el

área de trabajo que contiene los activos de la plataforma AIT, en esta
ventana el actor puede editar algunas propiedades de los activos como la
clase de activo, criticidad y prioridad. En la figura 4.81 se ilustra la
interfaz Listado de Activos
202
Figura 4.79: Interfaz Clases de Activos

Figura 4.80 interfaz Tipos de Activos

203
Figura 4.81: Interfaz Listado de Activos

 Interfaz Consultar Marcas y Modelos
En la figura 4.82 se muestra la interfaz Consultar Marcas y Modelos,

en esta interfaz los actores involucrados pueden buscar información acerca
de las marcas y modelos de los activos de PDVSA.
Figura 4.82: Interfaz Consultar Marcas y Modelos

204
 Interfaz Calendario de Tareas
En la figura 4.83 se muestra la interfaz Calendario de Tareas, en esta

interfaz los actores pueden visualizar en el calendario, las tareas de
mantenimiento que todavía no se han realizado.
Figura 4.83: Interfaz Calendario de Tareas

 Interfaz Registro de Mantenimiento
Esta interfaz permite la creación del mantenimiento preventivo a los

activos, al momento de crear un registro de mantenimiento el usuario deberá
establecer el nivel de mantenimiento, así como también la frecuencia que se
aplicara el mantenimiento, sin la necesidad de establecer la fecha del
205
mantenimiento, ya que esta acción se realiza en la interfaz planificación de

mantenimiento. Para ser más preciso en la figura 4.84 se ilustra la interfaz
Registrar Mantenimiento.
Figura 4.84 interfaz Registro de Mantenimiento

 Interfaz Planificación de Mantenimiento
A través de esta interfaz el usuario puede visualizar el estado de los

mantenimientos disponibles en el sistema, así como también crear y
reprogramar mantenimientos preventivos de los activos. En la figura 4.85 se
ilustra la interfaz Planificación de Mantenimiento.
 Interfaz Realizar Mantenimiento
En esta interfaz se visualiza la información necesaria para ejecutar el

mantenimiento, en el lado izquierda de la interfaz se muestra la ficha técnica
del activo y los detalles de la tarea de mantenimiento y en la parte derecha
de la interfaz se muestra en una tabla las herramientas y materiales
206
necesarios para realizar el mantenimiento. Para ser más específicos en la

figura 4.86 se muestra la interfaz Realizar Mantenimiento.
Figura 4.85 interfaz Planificación de Mantenimiento

Figura 4.86 interfaz Planificación de Mantenimiento

207
 Interfaz Tareas de Mantenimiento
En esta interfaz los usuarios pueden crear y configurar las tareas de

mantenimiento, además se pueden visualizar tareas en la tabla de la interfaz
y realizar las operaciones básicas de un CRUD. A continuación en la figura
4.87 se ilustra la interfaz Tareas de Mantenimiento.
Figura 4.87 Interfaz Tareas de Mantenimiento

 Interfaz Asignar Herramientas y Materiales
En la figura 4.88 se ilustra la interfaz Asignar Herramientas y

Materiales, en el cual los usuarios podrán asignar las herramientas o
materiales que necesitan cada tarea de mantenimiento.
208
Figura 4.88 interfaz Asignar Herramientas y Materiales

 Interfaz Asignar Tipos de Activos
En esta interfaz los actores pueden asignar los tipos de activos

requeridos para cada tarea de mantenimiento. En la figura 4.89 se ilustra
esta interfaz Asignar Tipos de Activos.
Figura 4.89 interfaz Asignar Tipos de Activos

209
 Interfaz Tipos de Mantenimiento
En esta interfaz se gestiona los tipos de mantenimiento y la descripción

de cada uno, el usuario puede visualizar la información de los tipos de
mantenimiento en la tabla de la interfaz. En la figura 4.90 se ilustra la
interfaz mencionada anteriormente.
Figura 4.90 interfaz Tipos de Mantenimiento

 Interfaz Frecuencia
En esta interfaz los usuarios los usuarios con los privilegios necesarios
podrán gestionar las unidades de tiempo que pueden ser diaria, semanal o
mensual. Sera más preciso mostrar en la figura 4.91 la interfaz mencionada
anteriormente.
210
Figura 4.91 Interfaz Frecuencia

 Interfaz Herramientas y Materiales
En la interfaz mostrada en la figura 4.92, los usuarios podrán agregar o

eliminar, las herramientas o materiales necesarios para realizar el
mantenimiento a los activos.
Figura 4.92 interfaz Herramientas y Materiales

211

 Interfaz Nagios
En esta interfaz los usuarios podrán visualizar los histórico de

monitoreo de los equipos de impresión. Sera más preciso mostrar en la
figura 4.93 la interfaz Nagios.
Figura 4.93 Interfaz Nagios

 Interfaz Configuración de Usuarios
Esta interfaz es utilizada por el administrador del sistema y permite

gestionar y conceder el acceso al sistema a los usuarios, así como también
212
establecer el nivel de acceso a cada uno de ellos. En la figura 4.94 se ilustra

la interfaz Configuración de Usuarios.
Figura 4.94 Interfaz Configuración de Usuarios

 Interfaz Roles de Usuarios
Esta interfaz permite la creación, modificación y eliminación de los

grupos o roles de usuarios. Para comprender mejor esta interfaz en la figura
4.95 se ilustra la interfaz roles de usuarios.
 Interfaz Módulos
Esta interfaz permite crear un número de identificación y el nombre de

los módulos del sistema necesarios para la permisología de los usuarios. En
la interfaz 4.96 se ilustra la interfaz Módulos.
 Interfaz Permisologia
213
En esta interfaz se muestra el listado de los grupos de usuarios que

forman parte del sistema y los acceso que tienen a los módulos del sistema,
cuando el acceso es 1 el usuario puede ingresar a ese modulo, en caso
contrario, si es 0 no puede acceder a ese modulo. Para ser más concreto en
la figura 4.97 se ilustra la interfaz Permisologia.
Figura 4.95: Roles de Usuarios

214
Figura 4.96: Interfaz Módulos

Figura 4.97: Interfaz Permisología

 Interfaz Reportes Oficiales
En esta interfaz el actor puede visualizar los reportes que existen en el

sistema. Todos los reportes se pueden guardar en PDF, en formato imagen,
y poseen la opción de imprimir. En la figura 4.98 se muestra la interfaz
Reportes Oficiales.
 Interfaz Mantenimiento Culminado
En la figura 4.99 se muestra la interfaz Mantenimiento Culminado, en

esta interfaz se puede obtener la información por meses del número de
mantenimientos culminados.
215
Figura 4.98: Interfaz Reportes Oficiales

Figura 4.99: Interfaz Mantenimiento Culminado

216
 Interfaz Servicio de Impresión Nagios
En la figura 4.100 se muestra la interfaz Servicio de Impresión Nagios,

en esta interfaz se puede obtener por meses las variables de impresión que
monitoreo Nagios.
Figura 4.100: Interfaz Servicio de Impresión Nagios

4.3.3 Diagrama de Componentes
Un componente es el empaquetamiento físico de los elementos en un

modelo, como son las clases en el modelo diseño, algunos estereotipos
estándar de componentes son los siguientes: ejecutables, archivos, librerías,
tablas y documento. En la figura 4.100 se muestra de manera detallada la
información de los estilos CSS, código JavaScript y PHP, librerías y
componentes propias del framework, que son esencial para el buen
funcionamiento del sistema.
217
Figura 4.101: Diagrama de Componentes

218
4.3.4 Flujo de Trabajo de Pruebas
Una de las fases más importantes del ciclo de vida de Desarrollo de

Software es el Flujo de Trabajo Pruebas, en ella se realizan evaluaciones
para obtener la calidad de un producto, y/o mejorarlo, mediante la
identificación de defectos y problemas; esto permitirá entregar al cliente un
producto de software libre de defectos o de errores. Las pruebas como
técnicas de comprobación dinámica permitirán evaluar la calidad del
producto, en este caso de la aplicación para mejorarla identificando
problemas o defectos.
Cabe destacar que los principales aspectos a ser evaluados en el

software, son la fiabilidad (resistente a fallos), la funcionalidad (hace bien su
trabajo) y el rendimiento (trabaja de manera efectiva), de esta forma las
pruebas se pueden realizar en tres niveles diferentes: Pruebas de unidad,
Pruebas de Integración y Pruebas de caja negra.
4.3.4.1 Pruebas de Unidad
Las pruebas de unidad son una técnica que permite determinar si un

programa cumple con los requisitos solicitados.
Las pruebas de unidad son estrictamente locales, dejando el trabajo de

probar la correcta interacción entre módulos a las Pruebas de Integración.
Este enfoque localista, permite desarrollar pruebas de Caja Blanca
exhaustivas a cada módulo de manera de descentralizar la operación y
diseño de estas a los desarrolladores responsables del módulo en cuestión.
Finalmente es de observar la relación que guardan las Pruebas de Unidad
219
con las Pruebas de Regresión. Siempre y cuando podamos contar con

pruebas automáticas, vamos a poder construir nuestros conjuntos de
pruebas de regresión a partir de lo pensado en las pruebas de unidad.
4.3.4.2 Pruebas de Integración
Las pruebas de integración son aquellas que se realizan en el ámbito

del desarrollo de software una vez aprobadas las pruebas de unidad. Estas
pruebas de integración, son la fase de prueba de software en la cual
componentes individuales de software son combinados y probados como un
grupo, con el objetivo de detectar las fallas de interacción entre las distintas
clases del sistema. Debido a que cada clase probada por separado se
inserta de manera progresiva dentro de la estructura, las pruebas de
integración son realmente un mecanismo para comprobar el correcto
ensamblaje del sistema.
El sistema SISGESBAS está basado en un conjunto de archivos, PHP,

JavaScript y CSS, entrelazados entre sí, por tal motivo, las pruebas de
integración se realizaron probando todos y cada uno de los enlaces y
simuladores presentes en el software.
Se navegó por todas las unidades haciendo link en cada una de las
partes y procesos automatizados probando así su enlace y respuesta con las
demás páginas, de igual manera se probaron los enlaces entre las páginas
por medio del botón salir del menú de la aplicación.
220
4.3.4.3 Pruebas de Caja Negra
Las pruebas de caja negra, también denominada prueba de

comportamiento, se centran en los requisitos funcionales del software. O sea,
la prueba de caja negra permite al ingeniero del software obtener conjuntos
de condiciones de entrada que ejerciten completamente todos los requisitos
funcionales de un programa. La prueba de caja negra no es una alternativa a
las técnicas de pruebas de caja blanca. Más bien se trata de un enfoque
complementario que intenta descubrir diferentes tipos de errores que los
métodos de caja blanca. La prueba de caja negra intenta encontrar errores
de las siguientes categorías: (1) funciones incorrectas o ausentes, (2) errores
de interfaz, (3) errores en estructuras de datos o en accesos a bases de
datos externas, (4) errores de rendimiento y (5) errores de inicialización y de
terminación.
Es importante mencionar que solamente se realizaron las pruebas de

caja negra a los módulos del sistema considerados más vulnerables a fallos
por validaciones de entradas de datos. A continuación desde la tabla 4.54
hasta la tabla 4.62 se documenta las pruebas de unidad del sistema. En la
tabla 4.53 se muestra el modelo de la Clase de Equivalencia
Tabla 4.53: Clase de Equivalencia

Numero Descripción
1 Carácter Alfabético
2 Carácter Alfanumérico
3 Carácter Especial
4 (Vacío)
5 Carácter Numérico
221
En la tabla 4.54 se representa las clases de equivalencia del caso de

uso Tipos de Activos
Tabla 4.54: Prueba de Unidad del caso de uso Tipos de Activos

Dato Clase de Equivalencia Valido No Valido
Tipo de Activo Carácter Alfabético X
Tipo de Activo Carácter Alfanumérico X
Tipo de Activo Carácter Especial X
Tipo de Activo (Vacío) X
Tipo de Activo Carácter Numérico X
Tipo de Activo Longitud > 50 X
Abreviatura Carácter Alfabético X
Abreviatura Carácter Alfanumérico X
Abreviatura Carácter Especial X
Abreviatura (Vacío) X
Abreviatura Carácter Numérico X
Abreviatura Longitud > 2 X
Abreviatura Longitud < 1 X

uso Clases de Activos
Tabla 4.55: Prueba de Unidad del Caso de Uso Clases de Activo (1/2)
Clase de Activo Carácter Alfabético X
Clase de Activo Carácter Alfanumérico X
Clase de Activo Carácter Especial X
Clase de Activo (Vacío) X
Tabla 4.55: Prueba de Unidad del Caso de Uso Clases de Activo (2/2)
222

Clase de Activo Numérico X
Clase de Activo Longitud > 50 X
Abreviatura Carácter Alfabético X
Abreviatura Carácter Alfanumérico X
Abreviatura (Vacío) X
Abreviatura Numérico X
Abreviatura Longitud > 2 X
Abreviatura Longitud < 1 X

uso Realizar Mantenimiento
Tabla 4.56: Prueba de Unidad del caso de uso Realizar Mantenimiento

Intervalo Carácter Alfabético X
Intervalo Carácter Alfanumérico X
Intervalo Carácter Especial X
Intervalo (Vacío) X
Intervalo Carácter Numérico X
Intervalo Numero > 3 X
Activo Carácter Alfabético X
Activo Carácter Alfanumérico X
Activo Carácter Especial X
Activo (Vacío) X
Activo Carácter Numérico X

uso Tareas de Mantenimiento
223
Tabla 4.57: Prueba de Unidad del caso de Uso Tareas de Mantenimiento

Tarea Carácter Alfabético X
Tarea Carácter Alfanumérico X
Tarea Carácter Especial X
Tarea (Vacío) X
Tarea Carácter Numérico X
Tarea Longitud> 150 X
Tiempo Carácter Alfabético X
Tiempo Carácter Alfanumérico X
Tiempo Carácter Especial X
Tiempo (Vacío) X
Tiempo Carácter Numérico X
Descripción Carácter Alfabético X
Descripción Carácter Alfanumérico X
Descripción Carácter Especial x
Descripción (Vacío) X
Descripción Carácter Numérico X
Descripción Longitud > 150 X

uso Tipos de Mantenimiento
Tabla 4.58: Prueba de Unidad del caso de Uso Tipos de Mantenimiento (1/2)
Descripción Carácter Alfabético X
Descripción Carácter Alfanumérico X
Tabla 4.58: Prueba de Unidad del caso de Uso Tipos de Mantenimiento (2/2)
224
Descripción Carácter Especial X

Descripción (Vacío) X
Descripción Carácter Numérico X
Descripción Longitud > 2000 X

uso Frecuencia
Tabla 4.59: Prueba de Unidad del caso de uso Frecuencia

Unidad de Tiempo Carácter Alfabético X
Unidad de Tiempo Carácter Alfanumérico X
Unidad de Tiempo Carácter Especial X
Unidad de Tiempo (Vacío) X
Unidad de Tiempo Carácter Numérico X
Unidad de Tiempo Longitud > 30 X

uso Herramientas y Materiales
Tabla 4.60: Prueba de Unidad del caso de Herramientas y Materiales (1/2)

Herramientas Carácter Alfabético X
Herramientas Carácter Alfanumérico X
Herramientas Carácter Especial X
Herramientas (Vacío) X
Herramientas Carácter Numérico X
Tabla 4.60: Prueba de Unidad del caso de Herramientas y Materiales (2/2)
225
Herramienta Longitud > 100 X


uso Roles del Usuario
Tabla 4.61: Prueba de Unidad del caso de Uso Roles de Usuario

Rol del Usuario Carácter Alfabético X
Rol del Usuario Carácter Alfanumérico X
Rol del Usuario Carácter Especial X
Rol del Usuario (Vacío) X
Rol del Usuario Carácter Numérico X
Rol del Usuario Longitud > 40 X

uso Módulos
Tabla 4.62: Prueba de Unidad del Caso de uso Módulos

Modulo Carácter Alfabético X
Modulo Carácter Alfanumérico X
Modulo Carácter Especial X
Modulo (Vacío) X
Modulo Carácter Numérico X
Modulo Longitud > 35 X
4.3.5 Conclusión de la Fase de Construcción

226
En esta fase, se codificaron, integraron y probaron todos los

componentes del software. Las pruebas de unidad y de integración
permitieron detectar y corregir las fallas en el funcionamiento de los
componentes y en la forma de conectarse unos a otros. Al final de la fase de
construcción se ha logrado poner la primera versión operativa del software.
227
CONCLUSIONES
 La utilización del Proceso Unificado de Desarrollo de Software permitió

recopilar el análisis y diseño de los requerimientos del sistema con una
buena base para el desarrollo de la aplicación.
 El patrón de diseño MVC permitió tener coherencia y claridad en el código

dela aplicación al separar en capas diferentes la lógica de la aplicación, la
interfaz del usuario y el control de la aplicación.
 El uso de framework, librerías y herramientas de computación, simplifico

los tiempos de desarrollo de la aplicación, así como también garantiza
mayor seguridad de la misma, debido a que la mayoría de los framework
como Codeigniter integran capas de seguridad.
 El uso de los diagramas del Lenguaje de Modelado Unificado (UML), para

el modelado del sistema permitió mostrar desde varias perspectivas las
diversas etapas que lo conforman, expresando de una manera simple y
comprensible su estructura del sistema para el posterior desarrollo.
 Para que el sistema entre en producción por la empresa se requiere la

revisión exhaustiva por parte los usuarios para que determinen si el
sistema necesita otros requisitos funcionales, para realizar otra iteración
al software y detectar posibles errores, el tiempo requerido para su
realización supera el tiempo estimado del proyecto, por lo que la entrega
final del sistema, comprende una fase previa a su puesta en producción.
228
RECOMENDACIONES
 Realizar un plan de adiestramiento acerca del mantenimiento preventivo a

los analistas de soporte básico.
 Desarrollar futuras actualizaciones al sistema, que permitan la

automatización de otros procesos realizados por la Empresa y la
renovación de los que ya se encuentran automatizados en el mismo.
 Realizar jornadas de entrenamiento que faciliten el correcto uso de la

aplicación.
 Añadir el código de activo a la tabla c001t_caso de la base de datos

SIGA-AIT, con la finalidad de recopilar información para el análisis de
fallas
 Añadir una opción al sistema que reconozca los usuarios que inician
sesión, tales como la hora de inicio y finalización de la sesión, fecha,
módulos al que accedió, y si inserta, edita o elimina algún registro; con la
finalidad de establecer responsabilidades en cuanto a la información
manejada en el sistema.
 El sistema fue creado tomando en cuenta la expansión del mismo, hacia

otros distritos de PDVSA, por lo tanto se recomienda que el sistema se
realice las pruebas necesarias para su futura implementación.
 Añadir un reporte de mantenimiento que indique los mantenimiento

planificados, diferidos y culminados por mes
229
BIBLIOGRAFÍA
Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software:

modelos de desarrollo de programas. Madrid, España: Delta
Publicaciones.
Arias, F. (2004). El proyecto de investigación: Introducción a la metodología

científica (4a ed.). Caracas, Venezuela: Episteme.
Bustamante L. y Ramos J. (2009). Diseño de un sistema de gestión de

mantenimiento para una empresa de servicios en el área de
telecomunicaciones. [Tesis en línea]. Universidad de Oriente,
Venezuela. Consultada el 22 de Marzo del 2017 en:
http://ri.bib.udo.edu.ve/handle/123456789/1099
Cobos, E. (2010). Desarrollo de una aplicación web bajo software libre para
la automatización de la gestión de las alarmas generadas por una
herramienta de monitoreo de equipos para la superintendencia de
mantenimiento de la plataforma de la gerencia de automatización
informática y telecomunicaciones de PDVSA Puerto la Cruz. [Tesis en
línea]. Universidad de Oriente, Venezuela. Consultada el 7 de Julio
en: http://ri.biblioteca.udo.edu.ve/handle/123456789/2516?mode=full
Cohen, D. y Asín, E (2000). Sistemas de información para los negocios Un

Enfoque de Toma de Decisiones (3a ed.). Ciudad de México, México:
McGraw-Hill.
DAMA International (2015). The DAMA Guide to the Data Management

Body of Knowledge (DAMA-DMBOK) Spanish Edition. New Jersey,
Estados Unidos: Autor.
230
Duffuaa, S.; Raouf, A. y Dixon, J. (2000). Sistemas de Mantenimiento

Planeación y Control. Ciudad de México, México: LimusaWiley.
EllisLab (2011). [Página web en línea]. Disponible en:

https://ellislab.com/codeigniter/
Elmasri, R. y Navathe, S. (2007). Fundamentos de Sistemas de Bases de

Datos. (5a ed.). Madrid, España: Pearson Addison Wesley.
Fernandez, S. (1997). Fundamentos del Diseño y la Programación Orientada

a Objetos. (2a ed.). Madrid, España: McGraw Hill.
Figueroa, A. (25 de Noviembre del 2017). Proyecto SIGA AIT – Rental

Sucre – UDO [Archivo en línea]. Recuperado en:
https://www.youtube.com/watch?v=wqbnvbMBxfY
Garcia, S. (2003). Organización y Gestión Integral de Mantenimiento.

Madrid, España: Díaz de Santos.
Gutiérrez, J. (s.f). ¿Qué es un framework web? [Artículo en línea].

Consultado el 17 de diciembre del 2017 en:
www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf
Kendall, K. y Kendall, J. (2001) Análisis y Diseño de Sistemas (8a ed.).

México, Naucalpan de Juárez: Prentice Hall.
Mariscal, A. (2011). Nagios en servidor Debian. [Documento en línea].

Consultado el 18 de diciembre del 2017 en:
informatica.gonzalonazareno.org/proyectos/2011-12/amc.pdf
Márquez J. (s.f). Arquitectura MVC Visión General [Articulo en linea].

Consultado en 17 de diciembre en: https://jorge.queideas.com/wp-
content/uploads/2011/11/Arquitectura-MVC.pdf
Medina, C. (2009). Desarrollo de un sistema de información Web para la

gestión de incidentes de falla en la plataforma tecnológica de PDVSA
231
AIT Servicios Comunes Centro. [Tesis en línea]. Universidad de los

Andes, Venezuela. Consultada el 2 de Abril del 2017 en:
http://bdigital.ula.ve/index.php/documento/detalledocumento/3528/
Ortiz, R. (2009). Diseño de un sistema de información que permita la

evaluación, cuantificación e identificación de las fallas de las bombas
ubicadas en la superintendencia de movimiento de crudos de la
refinería puerto la cruz. [Tesis en línea]. Universidad de Oriente,
Venezuela. Consultada el 20 de Marzo del 2017 en:
http://ri.biblioteca.udo.edu.ve/handle/123456789/1105?mode=full
Ramírez, A. y Rosas, M. (2012). Implementación de un sistema servicedesk

basado en ITIL. [Tesis en línea]. Universidad Nacional Abierta de
México, México. Consultada en 16 de Abril del 2017 en:
http://www.ptolomeo.unam.mx:8080/xmlui/handle/132.248.52.100/274
9?show=full
Ramírez, T. (2007). Como Hacer un Proyecto de Investigación. Caracas,

Venezuela: Panapo.
Rumbaugh, J.; Jacobson, I. y Booch, G. (2000). El Proceso Unificado de

Desarrollo de Software. UML. Madrid, España: Addison – Wesley
Iberoamericana.
Silberschatz, A.; Korth, H. y Sudarshan,S. (2002).Fundamentos de Bases de

Datos (4a ed.). Madrid, España: McGraw-Hill.
Sommerville, L. (2005). Ingeniería del Software. (7aed). Madrid, España:

Prentice Hall.
Stallman, R. (2004). Software Libre para una sociedad libre. Madrid, España:
Traficantes de Sueños
232
Universitat Oberta de Catalunya (s.f). Bases de datos en PostgreSQL.

Barcelona, España: Autor.
Yanes, E. y Gracia, H. (2011). Mapeo Objeto / Relacional (ORM).

[Documento en línea]. Consultado el 17 de diciembre del 2017
en:https://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile
/23/21
233
ANEXO
Anexo A: La codificación del software esta en el archivo Codigo.docx

METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:

TÍTULO MANTENIMIENTO PREVENTIVO DE LA PLATAFORMA DE
ESCRITORIO DEL EDIFICIO SEDE GUARAGUAO PODVSA
REFINACIÓN ORIENTE
SUBTÍTULO
AUTOR (ES):
APELLIDOS Y NOMBRES CÓDIGO CVLAC / E MAIL

CVLAC: V-20.636.644
Zamora U. , Randolph D.
E MAIL: davidzamorau@gmail.com
CVLAC:
E MAIL:
CVLAC:
E MAIL:
CVLAC:
E MAIL:
PALÁBRAS O FRASES CLAVES:

sistema de información
pdvsa refinación oriente
gerencia ait
aplicación web
nagios
siga-ait
mantenimiento preventivo
postgresql
codeigniter

ÀREA SUBÀREA
ESCUELA DE INGENIERÍA Y Ingeniería de Sistemas
CIENCIAS APLICADAS
RESUMEN (ABSTRACT):
El presente proyecto consiste en el desarrollo de un sistema de información para el apoyo del
mantenimiento preventivo de la plataforma de escritorio. El proyecto fue desarrollado para satisfacer
las necesidades del departamento de soporte básico de la Gerencia de Automatización Informática y
Telecomunicaciones. El departamento de soporte básico se encarga de realizar diversas actividades que
permiten controlar la plataforma tecnológica de PDVSA, desde la base de la información de sus
activos, hasta los cambios que se realizan sobre ellos y en su configuración. A su vez se encarga del
proceso de análisis, mantenimiento preventivo y correctivo de los equipos de información o equipos
informáticos en general, teniendo en cuenta computadoras de escritorio, computadoras portátiles,
estaciones de trabajo, y equipos de impresión. Este departamento no cuenta con una aplicación que
permita organizar y recopilar la información de los mantenimientos que se realiza a los equipos,
atendiendo a estas consideraciones, surge la necesidad de desarrollar un sistema de información para el
control y gestión del mantenimiento preventivo de la plataforma de escritorio. Las técnicas de datos
utilizadas fueron la revisión bibliográfica, la observación directa y las entrevistas no estructuradas. El
tipo de investigación fue de campo y el nivel de investigación descriptiva. El diseño y desarrollo de la
aplicación web fue elaborado según las fases de desarrollo de software (RUP), en sus tres primeras
etapas, de inicio, elaboración y construcción. Para el diseño de la arquitectura del software se utilizó
el Lenguaje Unificado de Modelado (UML) y para la construcción del software se utilizó PHP 5.6 y
PostgreSQL 9.3 como base de datos, cumpliendo con el decreto presidencial 3390 de desarrollo de
software libre.
CONTRIBUIDORES:
APELLIDOS Y NOMBRES ROL / CÓDIGO CVLAC / E_MAIL
Carrasquero M. , Manuel S. ROL CA AS x TU JU
CVLAC: V-7.374.987
E_MAIL manuelscm@hotmail.com
E_MAIL
ROL CA AS TU x JU
CVLAC: V-13.068.139
Garcia B. ,Nestor A.
E_MAIL garcianar@gmail.com
E_MAIL garcianar@pdvsa.com
ROL CA AS TU JU
x
Moisés B. , Héctor E. CVLAC: V-8.277.670
E_MAIL mbhenrique@hotmail.com
E_MAIL
ROL CA AS TU JU
x
Mujica V. , Víctor J. CVLAC: V- 14.054.907
E_MAIL vmujica@udo.edu.ve
E_MAIL
ROL CA AS TU JU
CVLAC:
E_MAIL
E_MAIL
FECHA DE DISCUSIÓN Y APROBACIÓN:
AÑO MES DÍA

2018 06 20
LENGUAJE. SPA
ARCHIVO (S):
NOMBRE DE ARCHIVO TIPO MIME
Tesis. Sistema de información para el control y gestión del Aplication. MS.word
mantenimiento preventivo de la plataforma de escritorio del
edificio sede guaraguao pdvsa refinación oriente.doc
ALCANCE
ESPACIAL:
TEMPORAL:
TÍTULO O GRADO ASOCIADO CON EL TRABAJO:

NIVEL ASOCIADO CON EL TRABAJO:

PREGRADO
ÁREA DE ESTUDIO:
DEPARTAMENTO DE COMPUTACION Y SISTEMAS
INSTITUCIÓN:
UNIVERSIDAD DE ORIENTE/ NÚCLEO DE ANZOÁTEGUI


DERECHOS
De acuerdo al artículo 41 del reglamento de trabajos de grado (Vigente a partir del II

Semestre 2009, según comunicación CU-034-2009)
“Los Trabajos de grado son de la exclusiva propiedad de la Universidad de

Oriente y sólo podrán ser utilizadas para otros fines con el consentimiento del
Consejo de Núcleo respectivo, quien deberá participarlo previamente al Consejo
Universitario para su autorización”
Br. Randolph Zamora
AUTOR
Prof. Manuel Carrasquero Prof. Héctor Moisés Prof. Víctor Mujica
ASESOR JURADO JURADO
POR LA COMISIÓN DE TRABAJOS DE GRADO
_____________________________
Prof. Manuel Carrasquero

Tesis - Sistema de Información para El Control y Gestión Del Mantenimiento Preventivo de La Plataforma de Escritorio Del Edificio Sede Guaraguao Pdvsa Refinación Oriente

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis - Sistema de Información para El Control y Gestión Del Mantenimiento Preventivo de La Plataforma de Escritorio Del Edificio Sede Guaraguao Pdvsa Refinación Oriente

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad de Oriente

SISTEMA DE INFORMACIÓN PARA EL CONTROL Y GESTIÓN DEL

Br. Randolph David Zamora

Trabajo de grado presentado ante la Universidad de Oriente como

Barcelona, Junio del 2018

Trabajo de grado presentado ante la Universidad de Oriente como

Barcelona, Mayo del 2018

Barcelona, Mayo del 2018

De acuerdo al Artículo 41 del reglamento de Trabajos de Grado de la

Al creador del Universo por habernos dado el don más importante de un

A todas aquellas personas que creyeron en mí y me brindaron una

A la Free Software Foundation, a GitHub y a toda aquella persona que

A cada uno de los profesores de la Universidad que me instruyeron en

A mi hermano Gabriel Zamora

A la Universidad de Oriente y a todos los que la representan.

En primer lugar quiero agradecer al Sr. Tomas Rondón y a la Sra. Iraida

A los integrantes de RRHH en especial a Niurka Castillo, Luis Lozano,

A los integrantes de Soporte Básico Diego, Medina, Héctor Quintero,

A mi amigo José Manuel Castro por todo el apoyo y ayuda que me

Quiero agradecerle especialmente a cada uno de los integrantes de

A mi amigos Franklin Barrero y Arturo Betancourt por la veces que me

A mis compañeros de clases y posteriormente mis amigos del primer

A mi profesor de yoga Eduardo Cox, gracias por orientarme en los

A los integrantes del área de Planificación y Programación de

También quiero agradecer a los integrantes de PCP en especial a

A mis amigas y compañeras de estudio Angelica Rich, Fredeleine

A Alfredo García y Elio Cabrera que a pesar de que realizamos nuestra

El destino me ha dado el privilegio de encontrar a personas como

A todos los profesores que me brindaron sus conocimientos en

También quiero agradecer a cada uno de los profesores que me

A cada uno de los pasantes y analista que compartieron conmigo en

Finalmente quiero agradecer a PDVSA por darme la oportunidad de ser

El presente proyecto consiste en el desarrollo de un sistema de

1.1 Planteamiento del Problema.........................................................25

1.2.1 Objetivo General....................................................................28

1.2.2 Objetivos Específicos............................................................28

2.2 Bases teóricas...............................................................................31

2.2.1.1 Tipos de mantenimiento..................................................31

2.2.1.2 Mantenimiento Centrado en Confiabilidad (MCC o RCM)

2.2.3 Sistemas de información (SI).................................................33

2.2.3.1 Actividades básicas de un sistema de información.........33

2.2.3.2 Tipos de Sistemas de Información..................................34

2.2.4 Modelado de Lenguaje Unificado (UML)...............................35

2.2.5 Proceso Unificado de Software (R.U.P: Rational Unified

2.2.6 Bases de Datos......................................................................37

2.2.6.1 Data Management Association (DAMA)..........................37

2.2.6.2 Gestión de datos..............................................................38

2.2.6.3 Modelo de Datos..............................................................38

2.2.6.4 Modelo entidad relación..................................................39

2.2.6.5 Modelo relacional.............................................................39

2.2.6.6 Mapeo de Objeto Relacional (ORM)...............................39

2.2.6.7 Sistema de Gestión de Base de Datos (SGBD)..............40

2.2.7 Software Libre........................................................................41

2.2.8 Aplicaciones web....................................................................41

2.2.9 PHP (Hypertext Pre-processor).............................................42

2.2.11 Programación Orientada a Objetos (POO)..........................43

2.2.12.1 Tipos de Framework web..............................................45

2.2.14 Arquitectura MVC (Model-View-Controller)..........................46

2.2.15 Sistema Integral de Gestión Automatizada para la Gerencia

2.2.17 Protocolo Simple de Administración de Red (SNMP)..........49

2.3 Descripción del Sistema...............................................................50

2.3.1 Petróleos de Venezuela, S.A. (PDVSA).................................50

2.3.2 PDVSA Refinación Oriente....................................................50