Sistema Web

PROYECTO DE GRADO
Presentado ante la ilustre UNIVERSIDAD DE LOS ANDES como requisito final para
obtener el Ttulo de INGENIERO DE SISTEMAS
Desarrollo de un Sistema de Informacin Web para la gestin de

incidentes de falla en la plataforma tecnolgica de PDVSA AIT
Servicios Comunes Centro
Por
Br. Carlos Germn Medina Albornoz
Tutor: Prof. Judith Barrios
Asesor Industrial: Ing. Jos Casanova
Febrero 2009
2009 Universidad de Los Andes Mrida, Venezuela
Desarrollo de un sistema de Informacin Web para la Gestin de Incidentes de Falla en

la plataforma tecnolgica de PDVSA AIT SCC.
Br. Carlos Germn Medina Albornoz

Proyecto de Grado Sistemas Computacionales, 170 pginas
Resumen: En el presente proyecto se desarrolla un sistema de informacin web como herramienta

de apoyo a los procesos de negocio llevados a cabo por la Gerencia de Mantenimiento de la
Plataforma (MAP), unidad adscrita a la Gerencia de Automatizacin, Informtica y
Telecomunicaciones de Petrleos de Venezuela S.A., en el rea denominada Servicios Comunes
Centro. El proyecto surge por la iniciativa de la Coordinacin de Confiabilidad, unidad que se encarga
de aplicar tcnicas de ingeniera de confiabilidad para apoyar a la Gerencia MAP en la planificacin del
mantenimiento y en el mejoramiento de la confiabilidad de la plataforma.
Las necesidades de informacin son un factor crtico para los encargados de la toma de
decisiones dentro de la Gerencia MAP. Existe adems una dependencia de la informacin generada
por otras unidades en la organizacin. Es por ello que se ha implementado un sistema de informacin
que, basado en tecnologa web y disponible a los miembros de la Empresa a travs de la intranet,
automatiza el proceso de llenado de los reportes de las fallas ocurridas en la plataforma durante las
guardias de los grupos encargados de su mantenimiento, y a partir de estos reportes obtiene
indicadores de confiabilidad y disponibilidad, que a su vez son complementados con datos registrados
por el sistema Nagios, encargado de monitorear el estado de la plataforma. De este modo se obtiene
un histrico de fallas y una base de conocimientos del mantenimiento realizado para cada equipo y
aplicacin de la plataforma. El proceso de desarrollo del sistema fue guiado por el mtodo Watch para
el desarrollo de aplicaciones empresariales, obtenindose dos versiones funcionales del sistema.
Debido al proceso de soberana tecnolgica que se est llevando a cabo dentro de PDVSA, el sistema
fue desarrollado utilizando software libre.
Palabras clave: Sistema de Informacin Web, Ingeniera de Confiabilidad, mantenimiento,

disponibilidad.
Dedicatoria
A mi madre, a mi padre y a mi hermano, las tres personas ms importantes en mi vida. Sin su

apoyo no lo hubiera logrado, gracias.
ii
ndice
DEDICATORIA................................................................................................................................................. II
NDICE.............................................................................................................................................................III
NDICE DE FIGURAS ...................................................................................................................................... VI
NDICE DE TABLAS ..........................................................................................................................................X
AGRADECIMIENTO........................................................................................................................................ XI
CAPTULO 1 ...................................................................................................................................................... 1
INTRODUCCIN .............................................................................................................................................. 1
1.1 DESCRIPCIN DE LA EMPRESA .................................................................................................................... 2
1.1.1 PDVSA AIT...................................................................................................................................... 3
1.3 ANTECEDENTES.......................................................................................................................................... 7
1.4 PLANTEAMIENTO DEL PROBLEMA ............................................................................................................... 8
1.5 JUSTIFICACIN ........................................................................................................................................ 10
1.5 OBJETIVOS .............................................................................................................................................. 11
1.5.1 Objetivo General............................................................................................................................ 11
1.5.2 Objetivos Especficos ...................................................................................................................... 11
1.6 METODOLOGA ....................................................................................................................................... 12
1.7 ESTRUCTURA DEL DOCUMENTO ................................................................................................................ 13
CAPTULO 2 .................................................................................................................................................... 15
MARCO TERICO Y HERRAMIENTAS DE SOPORTE ................................................................................. 15
2.1 SISTEMAS DE INFORMACIN..................................................................................................................... 15
2.1.1 Actividades que realiza un sistema de informacin ........................................................................ 16
2.1.2 Tipos de sistemas de informacin ................................................................................................... 17
2.1.3 Sistemas de Informacin Web ........................................................................................................ 18
2.2 INGENIERA DE CONFIABILIDAD ............................................................................................................... 19
2.2.1 Conceptos Bsicos........................................................................................................................... 19
2.2.2 Definicin...................................................................................................................................... 20
2.2.3 Estimacin de la confiabilidad ....................................................................................................... 21
2.2.4 Anlisis de confiabilidad basado en historiales de falla ................................................................. 21
2.2.5 Indicadores de confiabilidad .......................................................................................................... 22
2.2.6 Tipos de Mantenimiento................................................................................................................. 23
2.3 BASES DE DATOS ...................................................................................................................................... 23
2.3.1 Bases de datos relacionales ............................................................................................................ 24
2.3.2 Lenguaje Estructurado de Consulta (SQL) ..................................................................................... 24
2.3.3 El sistema de gestin de bases de datos PostgreSQL ....................................................................... 25
2.4 ARQUITECTURA ORIENTADA A SERVICIOS (SOA) ..................................................................................... 26
2.5 PROTOCOLO SOAP ................................................................................................................................. 28
2.5.1 NuSOAP ........................................................................................................................................ 29
2.6 LENGUAJE DE MODELADO UNIFICADO (UML) ......................................................................................... 30
iii
2.6.1 Diagramas de clases ...................................................................................................................... 31

2.6.2 Diagramas de componentes............................................................................................................ 31
2.6.3 Diagramas de objetos .................................................................................................................... 31
2.6.4 Diagramas de despliegue............................................................................................................... 32
2.6.5 Diagramas de paquetes ................................................................................................................. 32
2.6.6 Diagramas de actividades.............................................................................................................. 32
2.6.7 Diagramas de casos de uso............................................................................................................. 32
2.6.8 Diagramas de secuencia................................................................................................................. 33
2.7 EL LENGUAJE DE PROGRAMACIN PHP..................................................................................................... 33
2.8 CONCLUSIONES DEL CAPTULO.................................................................................................................. 34
CAPTULO 3 .................................................................................................................................................... 35
DESARROLLO DE LA PRIMERA VERSIN DEL SISTEMA ........................................................................... 35
3.1 PLANIFICACIN DEL PROYECTO ................................................................................................................ 35
3.2 MODELADO DE NEGOCIOS ....................................................................................................................... 36
3.2.1 Delimitacin del sistema de negocios.............................................................................................. 37
3.2.2 Diagrama de Procesos del negocio.................................................................................................. 38
3.2.3 Estructura de la Gerencia MAP...................................................................................................... 38
3.2.4 Cadena de Valor de la Gerencia MAP............................................................................................. 39
3.2.5 Diagrama de flujo entre procesos para la gestin de incidentes de falla......................................... 45
3.2.6 Identificacin de las reglas de negocio............................................................................................ 48
3.2.7 Modelado de los actores de negocio................................................................................................. 51
3.2.8 Identificacin de los objetos de negocio........................................................................................... 52
3.3 INGENIERA DE REQUISITOS ..................................................................................................................... 54
3.3.1 Definicin de los requisitos de software.......................................................................................... 55
3.3.2 Definicin de requisitos segn actores............................................................................................ 56
3.3.3 Clasificacin de los requisitos y definicin de prioridades ............................................................... 59
3.3.4 Definicin de casos de uso .............................................................................................................. 61
3.3.5 Matriz Casos de Uso vs. Requisitos................................................................................................. 68
3.4 DISEO DEL SISTEMA ............................................................................................................................... 69
3.4.1 Metas de diseo.............................................................................................................................. 69
3.4.2 Definicin del estilo arquitectnico y justificacin.......................................................................... 70
3.4.3 Identificacin de subsistemas......................................................................................................... 71
3.4.4 Diseo de componentes .................................................................................................................. 72
3.4.5 Diagrama de clases del sistema...................................................................................................... 77
3.4.6 Diagrama de despliegue del sistema .............................................................................................. 78
3.4.7 Diseo de la base de datos ............................................................................................................. 80
3.4.8 Diseo de la interfaz del usuario ................................................................................................... 82
3.5 FASE DE IMPLEMENTACIN Y PRUEBAS ..................................................................................................... 84
3.5.1 Implementacin del sistema........................................................................................................... 85
3.5.2 Pruebas del sistema ....................................................................................................................... 89
3.6 CONCLUSIONES DEL CAPTULO.................................................................................................................. 95
CAPTULO 4 .................................................................................................................................................... 97
DESARROLLO DE LA SEGUNDA VERSIN DEL SISTEMA........................................................................... 97
4.1 REVISIN DEL MODELO DE NEGOCIOS ......................................................................................................... 97
4.1.1 Modelado de las reglas de negocio.................................................................................................... 98
iv
4.1.2 Modelado de objetos de Negocio ..................................................................................................... 99

4.2 REQUISITOS DE LA SEGUNDA VERSIN .......................................................................................................100
4.2.1 Redefinicin de los perfiles de usuario ............................................................................................101
4.2.2 Definicin de requisitos segn actores...........................................................................................102
4.2.3 Clasificacin y negociacin de requisitos .........................................................................................103
4.2.4 Elaboracin de casos de uso...........................................................................................................106
4.2.5 Matriz Caso de Uso vs. Requisitos.................................................................................................111
4.3 DISEO DE LA SEGUNDA VERSIN.............................................................................................................112
4.3.1 Metas de diseo.............................................................................................................................112
4.3.2 Identificacin de subsistemas........................................................................................................112
4.3.3 Diseo de componentes .................................................................................................................113
4.3.4 Diagrama de clases del sistema.....................................................................................................119
4.3.5 Diagrama de despliegue del sistema .............................................................................................120
4.3.6 Diseo de la base de datos ............................................................................................................122
4.3.7 Diseo de la interfaz del sistema ..................................................................................................123
4.4 FASE DE IMPLEMENTACIN Y PRUEBAS .....................................................................................................125
4.4.1 Implementacin de componentes ...................................................................................................125
4.4.2 Fase de pruebas del sistema ..........................................................................................................128
4.5 ENTREGA FINAL DEL SISTEMA ....................................................................................................................132
4.6 CONCLUSIONES DEL CAPTULO ...........................................................................................................133
CAPTULO 5 ...................................................................................................................................................134
CONCLUSIONES Y RECOMENDACIONES....................................................................................................134
5.1
5.2
5.3
5.4
5.5
CONCLUSIONES ......................................................................................................................................134
APORTES A LA EMPRESA ..........................................................................................................................135
APORTES A LA UNIVERSIDAD ...................................................................................................................136
APORTES AL TESISTA ...............................................................................................................................136
RECOMENDACIONES ...............................................................................................................................137
REFERENCIAS BIBLIOGRFICAS.................................................................................................................140
ANEXO A ........................................................................................................................................................142
PLANIFICACIN DEL PROYECTO................................................................................................................142
ANEXO B.........................................................................................................................................................144
INTERFACES USUARIO/SISTEMA VERSIN 1............................................................................................144
ANEXO C.........................................................................................................................................................151
INTERFACES USUARIO/SISTEMA VERSIN 2............................................................................................151
ndice de figuras
Figura 1.1 Cadena de valor de PDVSA .4
Figura 1.2 Estructura organizativa de PDVSA AIT .5
Figura 1.2 AIT Servicios Comunes ...6
Figura 1.3 Estructura de PDVSA AIT Servicios Comunes Centro ..6
Figura 2.1 Arquitectura orientada a servicios ...28
Figura 3.1 Delimitacin del sistema de Negocios ..37
Figura 3.2 Diagrama de procesos del Mantenimiento de la Plataforma ..38
Figura 3.3 Estructura Organizativa Gerencia MAP ...39
Figura 3.4 Cadena de Valor de la Gerencia MAP ...40
Figura 3.5 Diagrama del proceso Registrar mantenimiento ejecutado ...43
Figura 3.6 Diagrama del proceso Aplicar Ingeniera de Confiabilidad ...44
Figura 3.7 Diagrama del proceso Monitorear la plataforma 44
Figura 3.8 Diagrama de flujo entre procesos para la gestin de incidentes de falla ..46
Figura 3.9 Flujo de actividades a obtener luego de automatizar el proceso ...47
Figura 3.10 Modelado de objetos de negocio . ..54
Figura 3.11 Perfiles de usuario del sistema ....62
Figura 3.12 Diagrama de casos de uso para usuario general 63
Figura 3.13 Diagrama de casos de uso para usuario intermedio ..64
Figura 3.14 Diagrama de caso de uso para usuario avanzado ..65
Figura 3.15 Diagrama de caso de uso para administrador ....66
Figura 3.16 Identificacin de subsistemas .....71
Figura 3.17 Subsistema de control de usuarios ..74
Figura 3.18 Subsistema de gestin de incidentes y soluciones .75
Figura 3.19 Subsistema de gestin de reportes de monitoreo ..76
Figura 3.21 Diagrama de clases del sistema ...78
Figura 3.22 Diagrama de despliegue del sistema ...79
vi
Figura 3.23 Modelo de la base de datos del sistema ..80

Figura 3.24 Pantalla de inicio del sistema ..83
Figura 3.25 Pantalla general de usuarios ....83
Figura 3.26 Diagrama de flujo de pantallas ...84
Figura 3.27 Formulario de ingreso de incidentes de falla ....87
Figura 3.28 Prueba de ingreso de usuario ..90
Figura 3.29 Mensaje obtenido al ingresar usuario invlido .91
Figura 3.30 Mensaje obtenido al tratar de ingresar un incidente con campos faltantes 91
Figura 3.31 Resultado obtenido al consultar incidentes por perodo de tiempo ...92
Figura 3.32 Incidentes reportados por el Grupo Z-Series entre el 01-01-2008 y el 01-012009 .......93
Figura 3.33 Clculo de indicadores para el grupo Z-Series ..94
Figura 3.34 Resultado obtenido luego de corregir el error de los indicadores ..94
Figura 4.1 Diagrama de objetos de la segunda versin del SINCFA ...100
Figura 4.2 Diagrama de casos de uso para usuario general 107
Figura 4.3 Diagrama de casos de uso para usuario MAP .108
Figura 4.4 Diagrama de casos de uso para usuario GDS ..109
Figura 4.5 Diagrama de casos de uso para usuario de confiabilidad .110
Figura 4.6 Identificacin de subsistemas para la segunda versin del SINCFA 113
Figura 4.7 Componentes agregados y modificados en el subsistema de control de
usuarios ......115
Figura 4.8 Componentes agregados y modificados en el subsistema de gestin de
incidentes y soluciones .....116
Figura 4.9 Componentes agregados y modificados en el subsistema de gestin de
reportes de monitoreo ......117
Figura 4.10 Componentes agregados y modificados en el subsistema de inventario de
componentes AIT ......118
Figura 4.11 Componentes del subsistema de auditoria del SINCFA ..119
Figura 4.12 Diagrama de clases para la segunda versin del sistema .120
Figura 4.13 Diagrama de despliegue para la segunda versin del sistema 121
vii
Figura 4.14 Modelo de la base de datos del sistema ....122

Figura 4.15 Pantalla de inicio del sistema ....123
Figura 4.16 Estructura general de las pantallas del sistema ....124
Figura 4.17 Diagrama de flujo de pantallas .....124
Figura 4.18 Componente de calendario en JavaScript ....125
Figura 4.19 Pantalla de modificacin de componentes ..126
Figura 4.20 Pantalla de modificacin de incidentes 126
Figura 4.21 Asignacin de fecha de minuta directamente por el sistema .127
Figura 4.22 Mensaje de aviso al usuario ...127
Figura 4.23 Prueba de acceso de usuario ya conectado ..129
Figura 4.24 Prueba de cierre de reporte abierto .....129
Figura 4.25 Prueba de consulta de reporte conjunto ..130
Figura 4.26 Prueba de longitud de campos en ingreso de incidente .131
Figura 4.27 Mensaje obtenido al tratar de ingresar el incidente ...131
Figura A.1 Planificacin inicial del proyecto ..142
Figura A.2 Revisin de la planificacin del proyecto .....143
Figura B.1 Pantalla de ingreso de incidentes ...144
Figura B.2 Pantalla de Verificacin de ingreso del incidente 145
Figura B.3 Consulta de incidentes reportados por perodo de tiempo .145
Figura B.4 Reporte de incidentes por perodo de tiempo .....146
Figura B.5 Reporte exportado a una hoja de clculo .146
Figura B.6 Clculo de indicadores operativos de la plataforma 147
Figura B.7 Consulta de incidentes por grupo operativo 147
Figura B.8 Consulta de incidentes por componente ...148
Figura B.9 Consulta de incidentes y soluciones ..148
Figura B.10 Pantalla de eliminacin de incidente ...149
Figura B.11 Reporte conjunto de incidentes de falla .....149
Figura B.12 Ingreso de componentes al inventario AIT .....150
Figura B.13 Consulta de componentes de inventario AIT ..150
Figura C.1 Pantalla de ingreso de incidentes ...151
viii
Figura C.2 Pantalla de Verificacin de ingreso del incidente 152

Figura C.3 Consulta de incidentes reportados por perodo de tiempo .152
Figura C.4 Reporte de incidentes por perodo de tiempo .....153
Figura C.5 Reporte de incidentes por grupo operativo .....153
Figura C.6 Clculo de indicadores para un grupo operativo .154
Figura C.7 Consulta de incidentes por fecha de minuta .....154
Figura C.8 Imprimir minuta .....155
Figura C.9 Reporte de incidentes y soluciones ...155
Figura C.10 Pantalla de eliminacin de incidente ...156
Figura C.11 Consulta de reportes abiertos ...156
Figura C.12 Consulta en conjunto de minutas y Nagios .....157
Figura C.13 Consulta de alertas de Nagios por equipo o aplicacin ..157
Figura C.14 Pantalla de definicin de servicio asociado a una aplicacin 158
Figura C.15 Auditoria del sistema ....158
ix
ndice de tablas
Tabla 3.1 Modelado de actores del negocio.. 52
Tabla 3.2 Clasificacin de los requisitos 59
Tabla 3.3 Casos de uso del sistema ..67
Tabla 3.4 Matriz de Casos de Uso vs. Requisito 69
Tabla 3.5 Pruebas de Caja Negra .90
Tabla 4.1 Clasificacin y Negociacin de requisitos ...104
Tabla 4.2 Descripcin de los nuevos casos de uso incorporados a la versin 2 del
SINCFA ...111
Tabla 4.3 Matriz de Casos de Uso vs. Requisitos para la segunda versin ....112
Tabla 4.4 Pruebas de caja negra del sistema ....128
Agradecimiento
Este documento no hubiera podido realizarse sin el aporte de todas las personas e instituciones que
intervinieron en algn momento sobre el proyecto, y que gracias a su experiencia, inters,
dedicacin, apoyo y confianza hicieron posible su realizacin. Por ello tengo que agradecer:
A la ilustre Universidad de Los Andes, particularmente a la Escuela de Ingeniera de Sistemas, por

contribuir en mi formacin profesional.
A la profesora Judith Barrios, por ser una excelente gua y un gran apoyo desde el comienzo hasta
el final del proyecto.
Al ingeniero Jos Casanova por ser un buen mentor, gua y apoyo dentro de la Empresa.
A todos los miembros de la Coordinacin de Confiabilidad, por el apoyo y confianza

suministrados.
A los miembros de las Gerencias MAP y GDS de PDVSA AIT Servicios Comunes Centro que
contribuyeron en el desarrollo del proyecto.
A mi amigo y compaero de clases Manuel Gmez, quien desarroll su proyecto de grado en la

misma unidad, gracias por ser un excelente apoyo dentro y fuera de la Empresa.
A todos aquellos amigos y compaeros, que de alguna forma intervinieron en la realizacin de

este trabajo.
xi
Introduccin
Captulo 1
Introduccin
En un mundo cada vez ms dominado por las tecnologas, las empresas se esmeran por obtener un
mejor conocimiento de sus procesos productivos y por lograr una mayor explotacin de la
informacin que estos generan. Dicha informacin les permite coordinar sus actividades de una
manera eficiente, rpida y con una mejor administracin de los recursos. Sin embargo, para que la
informacin fluya de manera eficiente y oportuna dentro de las diferentes unidades que se pueden
aprovechar de ella para la toma de decisiones, es necesario que la empresa proporcione un conjunto
de instrumentos y canales que, adems de servir de soporte para la comunicacin entre las unidades
que la integran, posea la flexibilidad suficiente como para adaptarse a los cambios que pueda
experimentar al pasar el tiempo. Es por ello que las grandes empresas dan cada vez ms importancia a
las tecnologas que apoyan el flujo de datos y la transmisin de informacin entre sus miembros.
Petrleos de Venezuela S.A. (PDVSA) no es la excepcin a sta regla. A lo largo de los aos se ha
caracterizado por mantenerse a la vanguardia en lo que respecta a la incorporacin de tecnologas en
sus procesos, convirtindose as en una empresa de alto nivel y dominio tecnolgico. La plataforma
tecnolgica de la Empresa constituye un activo esencial para el correcto desenvolvimiento de todos
los procesos productivos y por ello resulta vital poder garantizar la mejor disponibilidad posible en los
servicios brindados.
La Gerencia de Automatizacin, Informtica y Telecomunicaciones (AIT) es la encargada de
regir, proveer y mantener los servicios y soluciones integrales de tecnologas de automatizacin,
informacin y comunicaciones de la corporacin; contribuyendo al mantenimiento de la continuidad
operativa y la ejecucin de planes de actualizacin e innovacin. El mantenimiento de la plataforma
tecnolgica es una labor a la cual dedican gran cantidad de esfuerzo varias unidades dentro de sta
gerencia, entre las que destaca la Gerencia de Mantenimiento de la Plataforma (MAP).
Introduccin
Como toda labor dentro de la empresa, el poder garantizar una alta disponibilidad de los equipos
y sistemas que conforman la plataforma tecnolgica involucra toma de decisiones por parte de
miembros a distintos niveles en la organizacin. Para poder tomar decisiones es necesario conocer a
profundidad la situacin actual del problema y el impacto de cada una de las alternativas entre las
cuales se puede elegir. Dicho conocimiento demanda cierta cantidad de informacin, que no slo se
requiere que sea veraz, sino tambin oportuna. Es decir, que est disponible en el formato adecuado y
en el momento deseado.
La necesidad de informacin veraz y oportuna ha sido una de las mayores razones para que las
empresas se preocupen ms por la organizacin y procesamiento de dicha informacin. De all, el
auge que han tenido los Sistemas de Informacin Empresariales. El presente proyecto comprende el
desarrollo de un Sistema de Informacin Web de apoyo a algunas de las actividades de gestin del
mantenimiento de la plataforma tecnolgica de PDVSA, particularmente dentro de PDVSA AIT
Servicios Comunes Centro. El sistema automatiza un proceso que era llevado a cabo manualmente y
que comprende el registro y consulta de los reportes de las fallas ocurridas en la plataforma.
1.1 Descripcin de la Empresa

Petrleos de Venezuela S.A. (PDVSA) es la corporacin estatal venezolana que se encarga de la
exploracin, produccin, manufactura, transporte y mercadeo de los hidrocarburos del pas. Por
mandato de la Constitucin de la Repblica Bolivariana de Venezuela, la totalidad de las acciones de
PDVSA pertenecen al Estado Venezolano y se encuentra adscrita al Ministerio del Poder Popular para
la Energa y Petrleo. Es una de las mayores empresas petroleras a nivel mundial y ha sido catalogada
como una de las empresas ms grandes del mundo. Actualmente, es la petrolera con mayores reservas
petrolferas del planeta, alcanzando una suma total de 3,1 billones de barriles. Sus instalaciones se
encuentran distribuidas a lo largo de todo el territorio nacional y posee varias filiales nacionales e
internacionales [1].
PDVSA cumple con todas las actividades propias del negocio petrolero, constituyndose en una
corporacin que abarca todos los procesos, desde la explotacin hasta la comercializacin de los
Introduccin
hidrocarburos gaseosos y no gaseosos, y sus derivados. De su cadena de valor (vase Figura 1.1) se
divide en las siguientes cuatro unidades de trabajo:
x
Exploracin y Produccin: rea encargada de la evaluacin, exploracin, certificacin y

perforacin de yacimientos petroleros. Es el primer eslabn de la cadena, cubre adems la
perforacin y construccin de los pozos petrolferos.
Refinacin: rea encargada de la separacin, mejoramiento y obtencin de productos o

derivados del petrleo a travs de plantas de procesamiento y refineras.
Distribucin y comercializacin: rea encargada de colocar los productos obtenidos (Crudo y

derivados) en los diferentes mercados internacionales.
Gas: rea encargada de la explotacin y comercializacin de los hidrocarburos gaseosos. Con

unas reservas probadas por 147 billones de pies cbicos, Venezuela es una de las potencias
mundiales del sector de hidrocarburos gaseosos.
1.1.1 PDVSA AIT

Para dar apoyo a sus procesos de negocio y ejecutar estos de la manera ms eficiente, PDVSA requiere
de una infraestructura tecnolgica de vanguardia. Es por ello que existe una gerencia dentro de su
organigrama dedicada exclusivamente a proveer, suministrar y coordinar los servicios y las soluciones
integrales en toda el rea que abarca las tecnologas de automatizacin, informacin y comunicacin;
esta gerencia es la Gerencia AIT de PDVSA (Gerencia de Automatizacin, Informacin y
Comunicacin). PDVSA AIT no slo se encarga de contribuir a mantener la continuidad operativa de
la plataforma tecnolgica de la empresa, sino que tambin coordina y ejecuta planes para mantener
dicha plataforma actualizada, todo ello buscando propiciar un ecosistema tecnolgico que estimule los
poderes creadores del pueblo, el conocimiento libre, el desarrollo endgeno sustentable y la
economa social productiva con el fin de alcanzar la soberana tecnolgica [2].
Introduccin
Figura 1.1 Cadena de valor de PDVSA (Fuente: [1])

i) Organizacin
PDVSA AIT se encuentra dividida en unidades dedicadas a dar apoyo a cada uno de los procesos del
negocio petrolero y a las filiales ms importantes de la corporacin. Adicionalmente, existen unidades
de apoyo y coordinacin de recursos para la ejecucin de proyectos de mayor alcance en la empresa.
La organizacin de las unidades dentro de PDVSA AIT se puede observar en el organigrama de la
Figura 1.2.
ii) AIT Servicios Comunes Centro

Dentro de la gerencia AIT, la lnea de servicios comunes es la responsable de coordinar los recursos
necesarios para garantizar la continuidad operativa de los servicios AIT que apoyan los negocios de
PDVSA que conviven en una regin determinada (ver Figura 1.3). Existen tres unidades AIT de
Servicios Comunes: Oriente, Occidente y Centro.
AIT Servicios Comunes Centro comprende los servicios de PDVSA AIT en las regiones
metropolitana, centro y sur. Entre los servicios que abarca se pueden mencionar: el mantenimiento
de la plataforma, la gestin del servicio a los usuarios, la implantacin de nuevas soluciones, la gestin
Introduccin
de necesidades y oportunidades en el negocio, entre otras. La Figura 1.3 muestra la estructura

organizativa de PDVSA AIT Servicios Comunes Centro.
El presente proyecto fue desarrollado dentro de la Gerencia de Mantenimiento de la Plataforma
(MAP) de PDVSA AIT Servicios Comunes Centro, en las instalaciones de Intevep ubicadas en Los
Teques, estado Miranda.
Figura 1.2 Estructura organizativa de PDVSA AIT (Fuente: [2])
Introduccin
Figura 1.2 AIT Servicios Comunes
Figura 1.3 Estructura de PDVSA AIT Servicios Comunes Centro
Introduccin
1.3 Antecedentes
El mantenimiento de un activo tiene como objetivo primordial garantizar su disponibilidad durante el
mayor tiempo posible, alargando as sus ciclos de vida til. Las prcticas tradicionales se orientan a la
ejecucin de mantenimientos correctivos (actividades de mantenimiento que buscan corregir fallas en
la operacin del activo) complementados con mantenimientos preventivos (actividades de
mantenimiento que buscan prevenir fallas en la operacin del activo). Sin embargo, el paradigma est
cambiando, la criticidad de los activos hace necesario que las empresas busquen mejorar la
planificacin de sus mantenimientos preventivos para garantizar una mayor disponibilidad y disminuir
as los costos asociados. Esto ubica al mantenimiento preventivo prcticamente al mismo nivel, o
incluso un nivel mayor, de importancia respecto al mantenimiento correctivo.
Actualmente, con el objetivo de optimizar sus procesos de gestin del mantenimiento, dentro de
PDVSA se estn implantando nuevas prcticas. Entre estas, la Ingeniera de Confiabilidad constituye
una de las principales y ms efectivas herramientas, ya que permite optimizar considerablemente el
mantenimiento de los activos basndose en tcnicas de anlisis estadstico.
La Ingeniera de Confiabilidad (o de fiabilidad) es el estudio de la vida y el fallo de los equipos o
sistemas. El anlisis de la confiabilidad de un equipo o sistema busca determinar, entre otras cosas, la
probabilidad de que este ejecute su funcionalidad prevista durante un perodo de tiempo, operando
bajo un conjunto de condiciones establecidas y para las cuales ha sido diseado. El concepto de
ingeniera de confiabilidad involucra una amplia gama de metodologas, como por ejemplo:
Mantenimiento Centrado en Confiabilidad (MCC), Anlisis Causa Raz (ACR), Anlisis de Datos de
Vida, Modelado y Simulacin de Sistemas, Anlisis de Criticidad, Inspeccin Basada en Riesgo (IBR),
entre otras. [3]
A pesar de que las tcnicas de la ingeniera en confiabilidad parecieran estar dirigidas
exclusivamente al mantenimiento de equipos y sistemas mecnicos, es posible aplicar dichas tcnicas
en cualquier ambiente donde la alta disponibilidad y confiabilidad de los sistemas y equipos sea un
elemento crtico para el negocio [4]. Por ello el enfoque ha sido adaptado a la gestin de
mantenimiento de la plataforma tecnolgica de cualquier empresa. En la actualidad, dicha adaptacin
est siendo llevada a cabo dentro de PDVSA AIT por la Coordinacin de Confiabilidad.
Introduccin
La Coordinacin de Confiabilidad dentro de PDVSA AIT Servicios Comunes Centro (SCC), es

una unidad adscrita a la Gerencia de Mantenimiento Operacional de la Plataforma AIT (MAP) y se
encarga de aplicar prcticas de ingeniera de confiabilidad a la plataforma tecnolgica de la empresa, la
cual comprende un conjunto amplio de equipos y aplicaciones, entre las que se pueden mencionar:
servicios de telecomunicaciones, servidores, sistemas de automatizacin, equipos de infraestructura,
equipos de videoconferencia, redes de alcance local, redes de amplio alcance, sistemas operativos,
herramientas de ofimtica, herramientas de gestin de proyectos, soluciones ERP, sistemas de
autogestin, sistemas desarrollados dentro de la empresa, entre otros.
El objetivo principal de la Coordinacin de Confiabilidad es supervisar que se cumplan las dos
condiciones mencionadas anteriormente para todas estas tecnologas; es decir, garantizar la
confiabilidad y la disponibilidad de todos los sistemas y equipos que conforman la plataforma
tecnolgica de PDVSA AIT Servicios Comunes Centro.
Para el apoyo de su gestin, la Coordinacin de Confiabilidad ha definido un conjunto de
estndares y prcticas que le permiten alcanzar los objetivos de su gestin y han implementado varias
metodologas propias de la ingeniera de confiabilidad. Sin embargo, como en toda tcnica estadstica,
la calidad y precisin de los datos es esencial para que la ingeniera de confiabilidad arroje buenos
resultados. En base a esto, la coordinacin obtiene informacin acerca de las fallas ocurridas y el
mantenimiento realizado para corregirlas a partir de los reportes de falla hechos por los grupos
operativos responsables, tambin adscritos a la Gerencia MAP.
Por otro lado, el Centro Integral de Monitoreo de PDVSA AIT SCC supervisa continuamente el
estado de los componentes que integran la plataforma y cuyo desempeo resulta crtico para el
negocio. Para el monitoreo de los equipos se utilizan varias aplicaciones, entre las que resalta el
programa Nagios. Este programa, basado en software libre, registra constantemente el estado de los
componentes de la plataforma y de los servicios que ellos prestan, generando notificaciones a los
grupos responsables de su mantenimiento en caso de presentarse alguna anomala o cada del servicio.
1.4 Planteamiento del Problema

La Coordinacin de Confiabilidad de PDVSA AIT SCC se encarga de la evaluacin del desempeo de
la plataforma tecnolgica de la empresa, manteniendo un registro de las ocurrencias de fallas y
Introduccin
elaborando, en base a ese registro, anlisis que permiten planificar el mantenimiento de la plataforma
y estimar el impacto de las fallas ocurridas, a fin de sugerir prcticas para disminuir su ocurrencia. El
anlisis de confiabilidad realizado se centra en la determinacin de indicadores de la probabilidad de
que los equipos y sistemas que conforman la plataforma operen sin fallas por un determinado perodo
de tiempo bajo ciertas condiciones de operacin establecidas.
Actualmente se efecta una Reunin de Incidentes Diarios, en la cual los analistas que estn de
guardia por cada una de las especialidades que componen la plataforma AIT reportan los incidentes y
novedades que se presentaron durante su guardia. Con los reportes emitidos en esta reunin se genera
una Minuta de Incidentes Diarios que contiene la informacin sobre las novedades reportadas y en la
que se precisan los detalles de los incidentes ocurridos en la plataforma. Una vez armada, la minuta se
pone a disposicin del personal que la requiera a travs de la intranet de la empresa. Los analistas de
confiabilidad cargan manualmente la informacin contenida en la minuta en una hoja de clculo, y
obtienen indicadores determinsticos, como por ejemplo: Tiempo Promedio entre Fallas (TPEF),
Duracin de la falla (expresada en horas) y Tiempo Promedio de Solucin (TPS). Estos indicadores
sirven como parte del insumo para realizar estudios de criticidad, simulacin de sistemas y otros
anlisis.
La Coordinacin de Confiabilidad desea implementar un Sistema de Informacin Web, basado en
los estndares de software libre, que apoye sus actividades y que suministre la informacin que los
analistas requieren para estudiar la confiabilidad de los componentes que conforman la plataforma
tecnolgica de la empresa. El sistema a desarrollar debe integrar los reportes de los analistas de
guardia en las reuniones de incidentes diarios y a partir de estos reportes calcular los indicadores ya
mencionados, tambin debe permitir tener una base de conocimientos acerca de la naturaleza de las
fallas que se presentan en la plataforma y el mantenimiento realizado para corregirlas; adicionalmente,
debe capturar datos del sistema Nagios, utilizado por el Centro Integral de Monitoreo, sobre las
alertas significativas que se detectaron durante la jornada, complementando as los datos suministrados
por los analistas y los indicadores calculados. Se requiere que el sistema est disponible a travs de la
intranet de la empresa para que de ese modo sea accesible a todo el personal involucrado desde
cualquier punto de la red PDVSA.
Introduccin
10
1.5 Justificacin
Al momento de ocurrir alguna falla en la plataforma, los datos acerca del mantenimiento ejecutado
resultan casi tan importantes como la solucin del incidente y la continuidad operativa del servicio
afectado. La informacin contenida en los reportes elaborados por los analistas debe ser lo ms precisa
y completa posible, pues constituye una base de conocimiento de altsimo valor para la organizacin y
de la cual se pueden obtener muchos productos, como por ejemplo, los indicadores de confiabilidad
de la plataforma.
La generacin y el anlisis de los indicadores de confiabilidad, permite a los analistas estimar la
vida til y la criticidad de todos los equipos y sistemas que conforman la plataforma tecnolgica de
PDVSA. Mediante estos indicadores es posible realizar simulaciones para estimar, entre otras cosas, el
impacto y la frecuencia de posibles fallas en los sistemas y equipos, haciendo tambin posible una
adecuada planificacin del mantenimiento. Por tratarse de un proceso de carcter vital para la gestin
del mantenimiento y estando basado en tcnicas estadsticas, el anlisis de confiabilidad requiere de
datos con la mayor exactitud posible.
El proceso mediante el cual se gestionan actualmente las fallas y se analiza la confiabilidad de la
plataforma podra mejorar su eficiencia y precisin, en el sentido de que el clculo de los indicadores
requiere una dedicacin considerable de tiempo por parte de los miembros de la unidad. Adems, la
precisin de los valores calculados viene determinada por la veracidad de los datos suministrados por
los analistas en sus reportes, particularmente en cuanto al momento exacto en que se produjo la falla y
la duracin de sta. Otro de los problemas asociados es la falta de estandarizacin al momento de
generar el reporte, ya que muchas veces se omiten campos importantes acerca de la naturaleza de la
falla.
Adems de lo anterior, es conveniente complementar los datos de los reportes de incidentes con
las alertas emitidas por el sistema Nagios, ya que, si bien estas se concentran en la disponibilidad de los
componentes en la red y pueden estar sujetas a alteraciones debido a problemas en la comunicacin,
muchas veces aportan datos ms precisos en cuanto al instante en que se produjo la falla y el instante
de su finalizacin, lo que se refleja en los indicadores.
Los problemas de informacin que poseen actualmente las unidades involucradas pudieran ser
solventados mediante la implementacin de un SI que agilice la gestin de los reportes emitidos por
Introduccin
11
los analistas, su recuperacin y almacenamiento, facilitando as la toma de decisiones y convirtindose

en un recurso muy valioso para proporcionar, administrar e interpretar la informacin por l
generada; adems, brindara un insumo de carcter vital para la gestin del mantenimiento de la
plataforma: un repositorio histrico de incidentes de falla.
Uno de los principales requerimientos que tienen los miembros de la Empresa respecto al sistema
es la posibilidad de que todos los actores involucrados en el proceso puedan utilizarlo de manera
oportuna. Es por ello que se hace necesario que el sistema de informacin desarrollado est disponible
a travs de la intranet de la Empresa para todos los usuarios involucrados, tratndose entonces de un
tipo particular de SI, conocido como Sistema de Informacin Web (en ingls Web Information System,
de ahora en adelante SIW).
Enmarcado en el nuevo proyecto que busca la migracin de los sistemas dentro de PDVSA hacia
tecnologas libres, para dar as cumplimiento al decreto 3.390, uno de los principales requerimientos
de la Empresa con respecto al SIW es que est basado en software libre.
1.5 Objetivos
1.5.1 Objetivo General
Desarrollar un Sistema de Informacin Web basado en software libre que automatice el proceso de
gestin de las fallas ocurridas en la plataforma tecnolgica de PDVSA AIT SCC.
1.5.2 Objetivos Especficos

x
Realizar un estudio detallado del dominio de aplicacin en que se enmarca el sistema

(modelado de negocios).
Analizar los requisitos de los actores involucrados.
Realizar un diseo detallado de la estructura y distribucin del sistema.
Desarrollar tablas de datos que almacenen de manera efectiva y organizada las variables de los
procesos involucrados.
Introduccin
12
Disear la interfaz web de manera que est adaptada a los estndares que se manejan dentro
de la empresa y que sea amigable, eficaz y sencilla, para la consulta e interpretacin de los
datos.
Desarrollar los componentes de software que resulten necesarios.
Realizar pruebas al producto de software para verificar su correcto funcionamiento.
Refinar iterativamente el Sistema mediante el versionado sucesivo.
Entregar el sistema listo para su puesta en produccin a los miembros de la Coordinacin de

Confiabilidad, junto con su documentacin y manual de usuarios.
1.6 Metodologa
El mtodo a utilizar para el desarrollo del Sistema fue el mtodo Watch para el desarrollo de
aplicaciones empresariales en su versin 2004 [5]. ste mtodo tiene ventajas en el desarrollo de
aplicaciones, entre las que se pueden mencionar:
x
Agrega visibilidad al proyecto de desarrollo, permitiendo que los usuarios del sistema y el
grupo de desarrollo conozcan el estado del proyecto en cualquier momento.
Facilita al lder del proyecto la planificacin y el control del mismo.
Establece un marco metodolgico nico que estandariza el proceso de desarrollo y unifica la

informacin que se produce a lo largo del proyecto.
Se fundamenta en la ingeniera basada en componentes de software y emplea las mejores

prcticas, tcnicas y notaciones utilizadas actualmente en la industria de software.
El mtodo consta de los siguientes tres componentes:
Modelo del producto: que describe el producto que se va a desarrollar, estableciendo las
caractersticas arquitectnicas generales de la aplicacin.
Modelo del proceso: Mediante el cual se describe de manera estructurada el conjunto de
actividades que el grupo de desarrollo debe seguir para producir la aplicacin.
Introduccin
13
Modelo del grupo de desarrollo: Que describe los roles que tendrn cada uno de los miembros
del grupo de desarrollo y su organizacin1.
Dentro del modelo de procesos establecido en el mtodo Watch se establece un marco

metodolgico cclico, iterativo y controlado, mediante el cual en cada iteracin se desarrolla una
nueva versin del sistema o un nuevo subsistema. Para el desarrollo del SIW se realizaron dos
iteraciones completas y en cada una de ellas se obtuvo una versin operativa del mismo.
Para el modelado del SIW se utiliz el Lenguaje Unificado de Modelado UML en su versin 2.0.
Este lenguaje permite representar los diferentes aspectos de un sistema de software de una manera
clara y verstil, de modo que cualquier persona lo pueda entender, y que se puedan expresar de
manera explcita y clara las diferentes caractersticas del sistema en la etapa previa a su construccin,
obteniendo a la vez una documentacin que permite la evolucin y revisin del mismo [6]. El
modelado del sistema se hizo utilizando la herramienta CASE Enterprise Architect de Sparx Systems en su
versin 6.1.
Para el desarrollo del sistema se utiliz el lenguaje de programacin PHP en su versin 5.2.0-8 y
el manejador de bases de datos PostgreSQL en su versin 8.1.9-0. Se incorporaron funcionalidades en
Javascript para algunos componentes. Para la integracin de servicios web se utiliz la librera nuSOAP
en su versin 0.7.3.
1.7 Estructura del documento

El presente documento se estructura de la siguiente manera:
El Captulo 1 expone los antecedentes del problema de manera introductoria, habla sobre la
Empresa en la que se desarrollo el proyecto y plantea el problema a resolver, justificando su
importancia. Se mencionan los objetivos del proyecto y se habla de la metodologa a utilizar.
Para efectos del proyecto realizado, el grupo de desarrollo estuvo conformado por el tesista (quien
desempe varios de los roles dentro de un grupo de desarrollo), el asesor industrial, el tutor acadmico y
ciertos usuarios clave.
Introduccin
14
En el Captulo 2 se hace una breve resea de las herramientas y conceptos que fueron necesarios
manejar para el desarrollo del proyecto. Se habla acerca de los sistemas de informacin y su
clasificacin, se hace mencin del lenguaje de modelado unificado UML, se desarrollan ciertos
conceptos acerca de las bases de datos relacionales y se hace una breve descripcin de las herramientas
tcnicas ms representativas que se utilizaron en el proyecto: el lenguaje de programacin PHP, el
manejador de Bases de datos PostgreSQL, la arquitectura orientada a servicios (SOA), entre otros.
En el Captulo 3 se desarrolla la primera versin del sistema enmarcada en el modelo de procesos
Watch; se comienza con la fase de modelado de negocios en la que se analiza el dominio de la
aplicacin y se modelan los principales procesos a automatizar. Se habla acerca de los requisitos de la
aplicacin y luego se detalla el diseo del sistema, se mencionan algunos aspectos resaltantes de la
implementacin y se habla sobre la fase de pruebas del mismo, se culmina con una breve revisin de
los resultados ms importantes obtenidos con la entrega de la primera versin del sistema.
El Captulo 4 contiene todos los detalles de la implementacin de la segunda versin del sistema.
Se hace una breve descripcin de los nuevos requisitos incorporados, se resaltan los nuevos
componentes del sistema y se habla acerca de la fase final de pruebas y los resultados obtenidos con la
entrega final del sistema.
El Capitulo 5 abarca las conclusiones y recomendaciones finales del proyecto.
Captulo 2. Marco Terico y Herramientas de Soporte
15
Captulo 2
Marco Terico y Herramientas de Soporte
Para el desarrollo del proyecto se hace necesario dominar un conjunto de conceptos y herramientas.
El presente captulo hace una breve mencin de los conceptos ntimamente vinculados con el
proyecto. Se comienza desarrollando el concepto de sistema de informacin, su clasificacin y se habla
del tipo de sistema de informacin que comprende el proyecto: el sistema de informacin web, se
exponen algunos conceptos relacionados con la ingeniera de confiabilidad, se mencionan brevemente
los aspectos mas resaltantes de las bases de datos relacionales y del manejador de bases de datos
PostgreSQL, se habla acerca de la arquitectura orientada a servicios (SOA), se explica brevemente el
protocolo SOAP (Simple Access Object Protocol) y se comenta sobre la librera nuSOAP utilizada en el
proyecto. En cuanto a otras herramientas utilizadas, se habla un poco acerca del lenguaje de modelado
unificado (UML) y se explica la estructura y utilidad de los diagramas utilizados en el proyecto;
tambin se habla del lenguaje de programacin PHP.
2.1 Sistemas de Informacin

Un Sistema de Informacin es un conjunto de componentes interrelacionados que operan de manera
sistemtica para capturar, procesar, almacenar y distribuir informacin que sirva de apoyo a la toma
de decisiones, la coordinacin, el control y el anlisis dentro de una organizacin [7].
En ese sentido, algunas de las caractersticas que resultan necesarias para cualquier Sistema de
Informacin son las siguientes [8]:
x
Disponibilidad de informacin cuando sea necesario y por los medios adecuados.
Suministro de informacin de manera selectiva.
Variedad en la forma de presentacin de la informacin.
Cierto grado de autonoma para la toma de decisiones
Tiempo de respuesta adecuado a las necesidades del usuario.
Exactitud en la informacin suministrada.
Generalidad, como las funciones para atender a las diferentes necesidades.
Flexibilidad, capacidad de adaptacin.
Fiabilidad, para que el sistema opere correctamente.
Seguridad, proteccin contra prdidas.
Amigabilidad, para el usuario.
16
2.1.1 Actividades que realiza un sistema de informacin

Se distinguen cuatro actividades bsicas que realiza cualquier sistema de informacin, las cuales son: la
captura, el procesamiento, el almacenamiento y la salida o distribucin de la informacin [7].
Captura de la Informacin: Mediante este proceso, el sistema toma los datos que requiere para
procesar la informacin. La forma como se introducen los datos puede ser manual o automtica.
La entrada manual de los datos requiere que estos sean introducidos directamente por el usuario,
mientras que la automtica se produce cuando el sistema captura los datos de entrada de otro
sistema o mdulo.
Procesamiento de la Informacin: Es el proceso mediante el cual el sistema de informacin
realiza transformaciones y clculos sobre los datos basado en una secuencia de operaciones
preestablecida. Las operaciones pueden ser realizadas sobre los datos recientemente capturados o
sobre aquellos ya almacenados. Mediante la transformacin de los datos es posible la toma de
decisiones por parte de los encargados de interpretar la informacin generada por el sistema.
Almacenamiento de la informacin: Permite que la informacin generada en el proceso anterior
pueda ser guardada para ser recuperada ms adelante. Por lo general, la informacin es
almacenada utilizando archivos y bases de datos que utilizan como medio de almacenamiento los
discos magnticos o discos duros, los discos compactos, los dvds, entre otros.
17
Salida de la informacin: Es la capacidad que tiene un sistema de informacin para mostrar la

informacin procesada al exterior. La salida de un sistema puede ser la entrada de otro sistema de
informacin o modulo o puede ser mostrada directamente al usuario en el formato que ste
desee.
2.1.2 Tipos de sistemas de informacin

En [9] se clasifican los sistemas de informacin basndose en tres criterios: el grado de cobertura de
las actividades organizacionales, el grado de apoyo a la ejecucin de las actividades en la organizacin y
las tecnologas en las que se basa su desarrollo2. A continuacin se describen cada una de estas
clasificaciones.
De acuerdo al grado de cobertura de las actividades organizacionales, un sistema de informacin
puede clasificarse en:
Sistemas independientes (Sind): Surgen como resultado de requisitos individuales de los

miembros de una organizacin, apoyando las actividades del usuario en forma completa y sujetos
a las necesidades de stos.
Sistemas integrados (SII): Estn conformados por la conjuncin y colaboracin de los sistemas de
informacin ya existentes en la organizacin.
Sistemas organizacionales (SIO): Proporcionan un grado de cobertura e integracin total de las
actividades y procesos organizacionales, aportando as un grado de apoyo mximo a la toma de
decisiones.
De acuerdo al apoyo brindado a la ejecucin de las actividades organizacionales los sistemas de

informacin pueden ser:
Sistemas operacionales (SIOp): Son sistemas de bajo nivel que apoyan la automatizacin de tareas
y operaciones bsicas dentro de una organizacin, como por ejemplo las actividades
administrativas y de produccin.
2
Esta clasificacin no es exclusiva, pues los criterios permiten caracterizar a un SI como perteneciente a ms de una
clasificacin
18
Sistemas gerenciales (SIGe): Estn orientados a brindar apoyo a las actividades de nivel gerencial y
de coordinacin dentro de la organizacin.
Sistemas de Apoyo a la Toma de Decisiones (SATD): Son sistemas que contribuyen de forma
directa y explcita al proceso de toma de decisiones dentro de una organizacin, permitiendo
visualizar el panorama organizacional desde el punto de vista de los resultados y/o consecuencias
de tomar alguna accin en un momento dado.
De acuerdo a las tecnologas en las que se basan, los sistemas de informacin pueden ser:
x
Sistemas cliente/servidor.
Sistemas basados en tecnologas web.
Sistemas basados en agentes.
Sistemas basados orientados a servicios.
Existe una cuarta clasificacin de los sistemas de informacin en base al apoyo de actividades
organizacionales muy especializadas. Dentro de este grupo se encuentran los ya mencionados SATD,
los Sistemas Expertos (SE), que incorporan la automatizacin de experticia humana en la realizacin
de determinada actividad y Sistemas de Informacin Geogrfica (SIG) que estn relacionados con el
manejo de informacin geogrfica o referenciada espacialmente.
2.1.3 Sistemas de Informacin Web

En [10] se define un Sistema de Informacin Web (SIW) como: Un sistema de informacin que utiliza
una arquitectura web para proporcionar informacin (datos) y funcionalidad (servicios) a usuarios finales a travs
de una interfaz de usuario basada en presentacin e interaccin sobre dispositivos con capacidad de trabajar en la
web. Los SIW varan ampliamente en su mbito, desde sistemas de informacin hasta sistemas de transacciones ebusiness, incluso sistemas de servicios web distribuidos. Se clasifican los sistemas de informacin web como
sigue:
19
Las intranets, que dan apoyo al trabajo interno dentro de la Empresa.
Los sitios de presencia en la web, los cuales son herramientas utilizadas para alcanzar
consumidores fuera de la empresa.
Los sistemas de Comercio electrnico que dan apoyo a la interaccin con el consumidor.
Las extranets que son un conjunto de sistemas internos y externos que apoyan las
comunicaciones entre la empresa y otras empresas.
Por lo general, los SIW manejan una gran cantidad de datos, que se encuentra en fuentes
heterogneas, se maneja en distintos formatos, y un conjunto de componentes que estn por lo
general codificados en diferentes lenguajes de programacin y estn distribuidos en diferentes
plataformas. Al igual que los SI tradicionales, ms all que una infraestructura para la entrega de
informacin (en tiempo de ejecucin), los SIW deben proporcionar una infraestructura de desarrollo
y mantenimiento que permita manejar e interpretar los datos y que proporcione funcionalidades a los
usuarios finales para capturar, almacenar, procesar y mostrar la informacin, dando solucin a sus
necesidades.
Los SIW son diseados, desarrollados y mantenidos con el propsito de alcanzar objetivos
especficos de los usuarios finales. stos objetivos, deben constituir la base del proyecto de desarrollo
de todo SIW.
2.2 Ingeniera de Confiabilidad

Previo a la definicin de las tcnicas propias de la ingeniera de confiabilidad, se desarrollar un
conjunto de trminos que se encuentran ntimamente vinculados con el anlisis de confiabilidad. Los
siguientes conceptos fueron tomados de [10].
2.2.1 Conceptos Bsicos

Confiabilidad: Se define la confiabilidad como:la propiedad de un sistema o equipo de cumplir las
funciones para l previstas, manteniendo su capacidad de trabajo bajo los regmenes y condiciones
20
prescritos y durante el intervalo de tiempo requerido. Dicho de otra forma, la confiabilidad es la

propiedad del sistema de mantenerse sin experimentar un suceso de falla durante el tiempo y las
condiciones de explotacin establecidos. En ste sentido tambin define falla como sigue:
Falla: Suceso despus del cual un sistema tecnolgico deja de cumplir (total o parcialmente) sus funciones. La
falla es la alteracin de la capacidad de trabajo del componente o sistema.
Mantenibilidad: Es la probabilidad de que un sistema, subsistema o equipo que ha fallado pueda ser
reparado dentro de un perodo de tiempo determinado.
Disponibilidad. Es la probabilidad que un sistema, subsistema o equipo est disponible para su uso durante
un tiempo dado.
2.2.2 Definicin
La Ingeniera de Confiabilidad se define como la disciplina tcnica que estima, controla y gerencia la
probabilidad de fallas en dispositivos, equipos o sistemas, con el propsito de garantizar una alta
disponibilidad y confiabilidad [10].
De la definicin anterior, la cuantificacin de la confiabilidad (en trminos de probabilidades)
resulta esencial. El conocimiento de los parmetros de confiabilidad y mantenibilidad son
determinantes en el clculo de la disponibilidad de cualquier dispositivo, sistema o equipo. Mediante
stos parmetros se proporcionan los datos fundamentales para el anlisis del mantenimiento,
generando de se modo gran cantidad de informacin tcnica que resulta vital para la toma de
decisiones.
La gran cantidad de informacin tcnica generada requiere de evaluacin permanente y de la
ayuda de sistemas computarizados que permitan un adecuado anlisis, interpretacin y obtencin de
los datos de manera oportuna. Los resultados del esfuerzo en el conocimiento de los indicadores se
traducen en un aumento de la efectividad del proceso productivo, asociado a menores costos de
penalizacin y mantenimiento; para tales propsitos se desprende la necesidad de un monitoreo
constante mediante un sistema de informacin que, basado en modelos estadsticos y matemticos,
sirva de apoyo tcnico para la planificacin y programacin del mantenimiento.
21
2.2.3 Estimacin de la confiabilidad

Para la estimacin de la confiabilidad o la probabilidad de fallas, existen dos mtodos que dependen
del tipo de data disponible; estos son:
Estimacin Basada en Datos de Condicin: Altamente recomendable para equipos estticos,

que presentan patrones de baja frecuencia de fallas y por ende no se tiene un historial de
fallas que permita algn tipo de anlisis estadstico.
Estimacin Basada en el Historial de Fallas: Recomendable para equipos dinmicos, los cuales
por su alta frecuencia de fallas, normalmente permiten el almacenamiento de un historial de
fallas que hace posible el anlisis estadstico.
Debido a las caractersticas de los equipos y sistemas que conforman la plataforma tecnolgica de
PDVSA AIT se desarrollarn los conceptos asociados a la estimacin del historial de fallas.
2.2.4 Anlisis de confiabilidad basado en historiales de falla

Para una adecuada toma de decisiones es necesario tener datos exactos acerca de la ocurrencia de las
fallas. Por lo general, dentro de las industrias existen registros histricos de las fallas de los equipos,
los cuales se encuentran almacenados en grandes bases de datos. La adquisicin de los datos se reduce
a la consulta en esas bases de datos.
Sin embargo, la recuperacin oportuna de los datos para la realizacin de mejoras en la
confiabilidad resulta un factor crtico en muchas circunstancias. Muchas veces se considera ms
relevante la realizacin de mejoras inmediatas en los equipos y la correccin de las fallas, que el
registro histrico acerca de las acciones tomadas. La educacin de los encargados de tomar las
decisiones y de los recolectores de los datos acerca del valor de la informacin de los bancos de datos
resulta vital para la mejora de los ndices de confiabilidad, ya que se traduce en un incremento en la
veracidad de los datos recolectados [11].
22
2.2.5 Indicadores de confiabilidad

Los datos histricos del desempeo de los equipos o sistemas pueden ser convertidos en indicadores
de comportamiento fciles de analizar. Un simple concepto aritmtico resulta muy til en la
estimacin de la confiabilidad.
La confiabilidad se observa cuando el tiempo medio de fallas, para dispositivos no reparables o el
tiempo medio entre fallas para aquellos dispositivos reparables es largo comparado con el tiempo de
servicio efectivo. Del mismo modo, cuando los valores de los ndices de tiempo medio son pequeos
comparados con el tiempo de servicio efectivo, son indicadores de falta de confiabilidad.
Los recprocos de los indicadores de tiempo medio proporcionan las tasas de fallas que por lo
general tambin proporcionan informacin til y muchas veces considerada mejor para realizar
clculos.
Algunos de los indicadores ms utilizados son [10]:
Tiempo de disponibilidad (tiempo de trabajo sin fallas): Nmero de horas de trabajo de un

componente sin fallas.
Tiempo promedio de solucin o tiempo promedio para reparar: Es el tiempo medio, en
horas, de duracin de la reparacin de un elemento despus de experimentar una falla.
Intensidad de fallas o rata de fallas: Es el nmero de fallas ocurridas en un perodo de tiempo.
Tiempo Promedio entre fallas: Proporciona una medida del tiempo promedio transcurrido entre
las cadas de algn componente.
Probabilidad de trabajo sin fallas o probabilidad de supervivencia: Es la probabilidad de
que en un intervalo de tiempo prefijado (o en los lmites de las horas de trabajo dadas) con
regmenes y condiciones de trabajo establecidos, no se produzca ninguna falla, es decir, la
probabilidad de que el dispositivo dado conserve sus parmetros en los lmites prefijados
durante un intervalo de tiempo determinado y para condiciones de explotacin dadas. Se
denota como Ps(t).
Probabilidad de falla: es la probabilidad de que en un intervalo de tiempo prefijado se produzca al
menos una primera falla. Se denota como Pf(t).
23
Por lo general, la precisin en los ndices mejora entre mayor cantidad de registros histricos
se posea.
2.2.6 Tipos de Mantenimiento

El mantenimiento puede ser clasificado en las siguientes cinco categoras [10]:
Mantenimiento a condicin: actividades preventivas y/o correctivas que surgen de la condicin

de los equipos, generalmente detectada por sus operadores a travs de los dispositivos de
control y monitoreo (scadas, salas de control, panel de instrumentacin).
Mantenimiento de rutina y preventivo: incluye el mantenimiento peridico, como la ejecucin
de tareas previamente programadas, inspecciones y trabajos menores repetitivos.
Mantenimiento correctivo: es el proceso de efectuar reparaciones tan pronto como sea posible
despus del reporte de una falla.
Mantenimiento a frecuencia fija: son los basados en estrategias (horas de operacin, tiempo,
volumen de operaciones, entre otras) que generan un plan de mantenimiento.
Mantenimiento para optimizar: implica determinar las causas de descomposturas repetidas y
eliminar la causa mediante la modificacin del diseo. Generalmente se ejecutan actividades
como la ingeniera de confiabilidad (principalmente metodologas basadas en el anlisis causa
raz) para optimizar el diseo.
2.3 Bases de datos

Una base de datos es una coleccin de datos relacionados, es decir un conjunto de hechos que pueden
registrarse y que tienen un significado implcito. Por lo general, las bases de datos representan
aspectos del mundo real y son diseadas, construidas y pobladas con datos que tienen un propsito
especfico, se caracterizan por la coherencia de los datos que la integran. [12]. Hay cinco modelos
principales de bases de datos: el modelo jerrquico, el modelo en red, el modelo relacional, el
modelo de bases de datos deductivas y el modelo de bases de datos orientado a objetos. Para el
desarrollo del proyecto fue necesario manejar el concepto de bases de datos relacionales.
24
2.3.1 Bases de datos relacionales

Constituye el modelo ms utilizado en la actualidad para el modelado de problemas reales y la
administracin de datos dinmicamente. Almacena la informacin en varias tablas (filas y columnas de
datos) o ficheros independientes y realiza bsquedas que permiten relacionar datos que han sido
almacenados en ms de una tabla. Se basa en el uso de relaciones, donde cada relacin es una tabla
compuesta por registros (las filas de una tabla) y campos (las columnas de una tabla). En el modelo
relacional, cada fila representa un hecho que normalmente se corresponde con un vnculo o una
entidad del mundo real. El nombre de la tabla y de las columnas ayuda a interpretar el significado de
los valores que estn en cada fila. En el modelo relacional una fila se denomina tupla, una cabecera de
columnas se denomina atributo y la tabla se denomina relacin.
En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia. Esto tiene
la considerable ventaja de que es ms fcil de entender y de utilizar para un usuario espordico de la
base de datos. La informacin puede ser recuperada o almacenada mediante consultas que ofrecen
una amplia flexibilidad y poder para administrar la informacin [12].
2.3.2 Lenguaje Estructurado de Consulta (SQL)

Es un lenguaje de base de datos normalizado, utilizado por los diferentes motores de bases de datos
para realizar determinadas operaciones sobre los datos o sobre la estructura de los mismos. Est
diseado como un lenguaje amplio que incluye instrucciones para definir, consultar y actualizar la base
de datos.
Las funcionalidades que proporciona el SQL van ms all de la simple consulta (o recuperacin)
de datos. Permite definir los tipos de datos y manipular los datos. Adems, permite la concesin y
denegacin de permisos, la implementacin de restricciones de integridad y controles de transaccin,
y la alteracin de esquemas.
El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones agregadas.
Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos
[12].
25
2.3.3 El sistema de gestin de bases de datos PostgreSQL

PostgreSQL es un gestor de bases de datos muy conocido y usado en entornos de software libre por el
conjunto de funcionalidades avanzadas que soporta, lo que lo sita al mismo o a un mejor nivel que
muchos otros sistemas gestores comerciales.
El origen de PostgreSQL se sita en el gestor de bases de datos POSTGRES desarrollado en la
Universidad de Berkeley y que se abandon en favor de PostgreSQL a partir de 1994. Ya entonces,
contaba con prestaciones que lo hacan nico en el mercado y que otros gestores de bases de datos
comerciales han ido aadiendo durante este tiempo.
PostgreSQL se distribuye bajo licencia BSD, que permite su uso, redistribucin, modificacin con
la nica restriccin de mantener el copyright del software a sus autores, en concreto el PostgreSQL
Global Development Group y la Universidad de California.
PostgreSQL destaca por su amplsima lista de prestaciones que lo hacen capaz de competir con
cualquier SGBD comercial [13]:
x
Est desarrollado en el lenguaje de programacin C.
Posee interfaces compatibles con C, C++, Java, Perl, PHP y TCL, entre otros.
Cuenta con un rico conjunto de tipos de datos que permiten, adems, su extensin mediante
tipos y operadores definidos y programados por el usuario.
Su administracin se basa en usuarios y privilegios.
Sus opciones de conectividad abarcan TCP/IP, sockets Unix y sockets NT, adems de soportar
completamente ODBC.
Los mensajes de error pueden estar en espaol y hacer ordenaciones correctas con palabras
acentuadas o con la letra .
Es altamente confiable en cuanto a estabilidad se refiere.
Puede extenderse con libreras externas para soportar encriptacin, bsquedas por similitud
fontica (soundex), etc.
26
Control de concurrencia multi-versin, lo que mejora sensiblemente las operaciones de

bloqueo y transacciones en sistemas multi-usuario.
Posee soporte para vistas, claves forneas, integridad referencial, disparadores,

procedimientos almacenados, subconsultas y casi todos los tipos y operadores soportados en
SQL92 y SQL99.
Implementacin de algunas extensiones de orientacin a objetos. En PostgreSQL es posible

definir un nuevo tipo de tabla a partir de otra previamente definida.
2.4 Arquitectura Orientada a Servicios (SOA)

Vista como un marco para el desarrollo de productos de software, la arquitectura orientada a servicios
es un paradigma para utilizar y organizar servicios distribuidos que pueden encontrarse bajo varios
dominios y estar implementados utilizando diferentes tecnologas. Se basa en los conceptos de
escalabilidad y reutilizacin del software. Por lo general, las organizaciones desarrollan funciones y
aplicaciones que son tiles para automatizar ciertas tareas dentro de los procesos de negocio. Sin
embargo, muchas veces una solucin puede ser til a nivel intermedio para varios procesos o unidades
dentro de la organizacin con fines diferentes. El concepto de arquitectura orientada a servicios
implica que los desarrolladores creen un conjunto de funciones independientes entre si (llamadas
servicios) que aceptan llamadas y generan respuestas mediante interfaces bien definidas y que son
puestos a disposicin de los clientes como utilidades que pueden ser reutilizadas por diversas
aplicaciones dentro de la organizacin. La implementacin de los servicios es transparente para los
usuarios ya que a estos no le interesa conocer sino el tipo y formato de las entradas admitidas y de las
salidas generadas por el servicio [14].
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en
la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayora
de las definiciones de SOA identifican la utilizacin de Servicios Web (empleando SOAP y WSDL) en
su implementacin, no obstante se puede implementar SOA utilizando cualquier tecnologa basada en
servicios [15].
27
Las arquitecturas orientadas a servicios difieren de las arquitecturas orientadas a objetos en que se
encuentran formadas por servicios dbilmente acoplados y altamente interoperables. Estos servicios
definen una estructura para comunicarse entre si que es independiente del lenguaje en que se
encuentran implementados y el lenguaje de programacin, todo ello buscando maximizar la
reutilizacin de los componentes desarrollados [15].
La arquitectura SOA es muy utilizada por las grandes organizaciones en la actualidad, entre tantas
cosas por el hecho de permitir la creacin o cambios en los procesos de negocio automatizados de
forma gil, a travs de una composicin de nuevos procesos utilizando las funcionalidades del negocio
contenidas en las aplicaciones actuales o futuras consumidas por medio de servicios web. Una
arquitectura de este tipo es la que se muestra en la figura 2.1. De la figura se observa como los
componentes se distribuyen en tres capas:
x La capa de presentacin, en la que, a travs de las interfaces de usuario generadas, se establece
una relacin entre el usuario y el sistema, logrando de esta forma el uso de la aplicacin por
parte del usuario. Se le da el formato a los datos recibidos desde el bus de integracin con el
fin de que el usuario visualice la informacin en una pgina web.
x El bus de integracin, en el que se encuentran los servicios web del negocio, as como los
objetos manipulados por esos servicios, y todos los servicios comunes para todas las funciones
de negocio. Esta capa implementa la lgica de negocios de la aplicacin.
x La capa de datos que mantiene la implementacin de las estructuras que almacenan los datos
de la aplicacin (bases de datos).
28
Figura 2.1 Arquitectura orientada a servicios (Fuente: [16])
Para la implementacin del proyecto se utiliz un protocolo basado en servicios web, mejor conocido
como Protocolo de Acceso a Objetos Simples (SOAP, por sus siglas en ingls).
2.5 Protocolo SOAP

SOAP es un protocolo de comunicacin definido para el intercambio de datos mediante el paso de
mensajes en formato XML. Define los estndares para la comunicacin entre dos objetos de diferentes
procesos a travs de una conexin de Internet. Es utilizado para el acceso a servicios web. Permite la
llamada de procedimientos remotos mediante http entre aplicaciones distribuidas en distintos
servidores. Existen varios protocolos parecidos, como por ejemplo RMI de Java y ORPC de CORBA.
Sin embargo, SOAP es uno de los ms utilizados y aceptados por las grandes compaas del mundo.
Las principales razones de su xito son [17]:
29
No esta asociado con ningn lenguaje: SOAP no especifica una API, por lo que la
implementacin de la API se deja al lenguaje de programacin y la plataforma.
No se encuentra fuertemente asociado a ningn protocolo de transporte: Un

mensaje de SOAP no es ms que un documento XML, por lo que puede transportarse
utilizando cualquier protocolo capaz de transmitir texto.
No est atado a ninguna infraestructura de objeto distribuido: La mayora de los

sistemas de objetos distribuidos se pueden extender, y muchos de ellos ya lo estn para que
admitan SOAP.
Aprovecha los estndares existentes en la industria: Por ejemplo, SOAP aprovecha

XML para la codificacin de los mensajes, en lugar de utilizar su propio sistema de tipo que ya
estn definidas en la especificacin esquema de XML. Y como ya se ha mencionado, SOAP no
define un medio de trasporte para los mensajes; los mensajes de SOAP se pueden asociar a los
protocolos de transporte existentes como http y SMTP.
Permite la interoperabilidad entre mltiples entornos: SOAP se desarroll sobre los

estndares existentes de la industria, por lo que las aplicaciones que se ejecuten en
plataformas con dichos estndares pueden comunicarse mediante mensaje SOAP con
aplicaciones que se ejecuten en otras plataformas.
Existen varias implementaciones de SOAP que proporcionan la estructura para definir servicios
web bajo un lenguaje particular, entre estas implementaciones, para el proyecto se utiliz la librera
NuSOAP elaborada para PHP.
2.5.1 NuSOAP
NuSOAP es un kit de herramientas (ToolKit) para desarrollar servicios web bajo el lenguaje PHP. Est
compuesto por una serie de clases que facilitan el desarrollo de servicios web. Provee soporte para el
desarrollo de clientes (aquellos que consumen los servicios) y de servidores (aquellos que los
proveen). Incorpora mtodos que generan los mensajes XML a partir de unas pocas lneas de cdigo
por parte del desarrollador. Adems, permite agregar datos nuevos creados por el usuario,
30
incrementando su flexibilidad. NuSOAP est basado en SOAP 1.1, WSDL 1.1 y http 1.0/1.1. Existen
otras herramientas de soporte para el desarrollo de servicios web bajo PHP, sin embargo NuSOAP es
uno de los que se encuentra en la fase de desarrollo ms avanzada, a pesar de que aun se encuentra en
su fase experimental [18].
2.6 Lenguaje de Modelado Unificado (UML)

UML (Unified Modelling Language) es un lenguaje grfico para el modelado de sistemas de software que
permite representar grficamente la estructura de un sistema, haciendo posible que cualquier persona,
ajena o no al proceso de diseo, lo pueda entender. Mediante UML se pueden especificar, visualizar y
documentar de manera explcita las caractersticas de un sistema de software antes y durante su
construccin. UML es slo un lenguaje para el modelado, por lo que su utilizacin es independiente
del proceso de desarrollo, aunque para su uso ptimo debe aplicarse en un proceso centrado en
arquitectura, dirigido a casos de uso, iterativo e incremental [19].
Es lo suficientemente expresivo como para modelar pruebas del sistema, sistemas de hardware,
sistemas de negocios, el flujo de trabajo en una empresa, diseo de estructura de una organizacin,
actividades de planificacin de proyectos y otros sistemas no informticos.
El UML se deriva de la unificacin de tres metodologas de anlisis y diseo orientada a objeto, la
metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones, la tcnica
de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique) y la
aproximacin de Ivar Jacobson (OOSE: Object Oriented Software Engineering) mediante la metodologa de
casos de uso. De estas tres metodologas, las de Rumbaugh y Booch se pueden clasificar como
metodologas directamente orientadas a objetos, mientras que la metodologa de Jacobson est
orientada al usuario, ya que todo en su mtodo se deriva de los escenarios de uso del sistema.
Su desarrollo comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Racional
Software Corporation comenzaron a unificar sus mtodos. A finales de 1995, Ivar Jacobson y su
compaa Objectory se incorporaron, aportando el mtodo OOSE. Los anteproyectos de UML
empezaron a circular en la industria de software y las reacciones resultantes trajeron modificaciones
considerables. Conforme diversos corporativos vieron que el UML era til a sus propsitos se fueron
agregando nuevos aportes. En 1997 se produjo la versin 1.0 del UML y se puso a consideracin del
31
OMG (Object Management Group), propuesto como un lenguaje de modelado estndar. Desde entonces,
UML ha atravesado una serie de revisiones y refinamientos hasta llegar a su versin actual: UML 2.0
[20].
El UML est compuesto por diversos elementos grficos que se combinan para conformar
diagramas. Como se trata de un lenguaje, UML aporta las reglas para combinar tales elementos. Los
diagramas permiten representar diversas perspectivas de un sistema, indicando lo que supuestamente
har, pero no la forma como se implementar. En la versin 2.0 del Uml, se define un total de 13
diagramas para representar la estructura y dinmica del sistema. Sin embargo, para efectos del
proyecto solo se utilizaron ciertos diagramas. Los diagramas utilizados en el proyecto se describen a
continuacin.
2.6.1 Diagramas de clases

Son utilizados durante el proceso de anlisis y diseo conceptual de la informacin manejada por el
sistema. Son estructuras estticas que dan una visin general del conjunto de clases existentes en el
sistema modelado y las relaciones existentes entre casa una de ellas. Se trata de diagramas estticos
pues muestran las relaciones entre las clases pero no especifica su interaccin dinmicamente.
2.6.2 Diagramas de componentes

Son utilizados para modelar la estructura del software y las dependencias entre sus componentes.
Modelan y agrupan los componentes del sistema en forma de paquetes, muestra las interfaces de los
componentes, sus dependencias, relaciones e interacciones.
2.6.3 Diagramas de objetos

Son parte de la vista esttica del sistema. Permiten modelar las instancias de las clases que fueron
representadas en el diagrama de clases. Muestran los objetos y sus relaciones pero en un momento
concreto del sistema. Pueden incorporar clases para mostrar la clase a la que pertenece un objeto
representado.
32
2.6.4 Diagramas de despliegue

Muestran la distribucin fsica de los distintos nodos que componen el sistema, la comunicacin entre
los nodos y la disposicin de los componentes sobre ellos. Un nodo es un recurso de ejecucin tal
como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del
equipo. Los elementos utilizados en la representacin grfica de estos diagramas son los mismos que
son utilizados en los diagramas de componentes.
2.6.5 Diagramas de paquetes

Permiten visualizar la distribucin de los componentes del sistema en paquetes y las dependencias
entre ellos.
2.6.6 Diagramas de actividades

Son utilizados para modelar el flujo de control de las actividades que tienen lugar a lo largo del tiempo
junto a las tareas concurrentes que pueden realizarse a la vez. Muestra las interacciones entre las clases
mediante el flujo de control de actividades ordenadas cronolgicamente con el fin de lograr la
ejecucin de un proceso ms complejo.
2.6.7 Diagramas de casos de uso

Representan la forma como un usuario opera con el sistema en desarrollo y la forma, tipo y orden en
la que interactan sus elementos. Los elementos implicados en un diagrama de casos de uso son:
Actores: Son entidades con un comportamiento definido y que realizan alguna interaccin con el
sistema. Pueden representar usuarios, organizaciones u otros sistemas informticos.
Casos de uso: Son descripciones de las secuencias de acciones que se producen de la interaccin
entre un actor y el sistema.
33
Relaciones entre casos de uso: Las relaciones entre los casos de uso son de inclusin y extensin.
Un caso de uso puede incluir a otro caso de uso como parte de su procesamiento. Generalmente
se asume que los casos de uso incluidos se llamarn cada vez que se ejecute el camino base. Un
Caso de Uso puede ser incluido por uno o ms casos de uso, ayudando as a reducir la duplicacin
de funcionalidad al factorizar el comportamiento comn en los casos de uso que se reutilizan. Un
caso de uso puede extender el comportamiento de otro caso de uso tpicamente cuando ocurren
situaciones excepcionales o cuando depende de ciertos criterios, entonces se realiza una
interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del
sistema a diferencia de la relacin incluye que se da siempre que se realiza la interaccin descrita.
2.6.8 Diagramas de secuencia

Representan la interaccin ordenada entre los objetos de un sistema de acuerdo a una secuencia
temporal de eventos. En particular muestran los objetos que participan en la interaccin y los
mensajes que intercambian en orden temporal.
2.7 El lenguaje de programacin PHP

PHP es un lenguaje de programacin del lado del servidor diseado originalmente para la generacin
de pginas dinmicas. Es un lenguaje de programacin interpretado o de script que permite insertar
fragmentos de cdigo dentro de la pgina HTML y realizar determinadas acciones de una forma fcil y
eficaz sin tener que generar programas en un lenguaje distinto al HTML. Por otra parte, PHP ofrece
un sinfn de funciones para la explotacin de bases de datos de una manera llana y sin complicaciones.
Generalmente se ejecuta en un servidor web, tomando el cdigo en PHP como su entrada y creando
pginas web como salida. Puede ser desplegado en la mayora de los servidores web y en casi todos los
sistemas operativos y plataformas sin costo alguno. PHP se encuentra instalado en ms de 20 millones
de sitios web y en un milln de servidores [21].
Una de sus mayores ventajas es el parecido que posee con otros lenguajes de programacin
estructurada como Perl y C que permite a la mayora de los programadores crear aplicaciones
complejas de manera muy sencilla, pues no se requiere mucho tiempo para su aprendizaje.
34
Cuando el cliente hace una peticin al servidor para que le enve una pgina web, el servidor
ejecuta el intrprete de PHP. ste procesa el script solicitado y genera de manera dinmica el
contenido. El resultado es enviado por el intrprete al servidor, quien a su vez le enva la pgina
HTML al cliente. Mediante extensiones es tambin posible la generacin de archivos PDF, Flash, as
como imgenes en diferentes formatos. PHP puede ser ejecutado bajo casi cualquier plataforma
(UNIX, Windows, Mac OS) [21].
Si bien no es un lenguaje completamente orientado a objetos, en su ltima versin (versin 5.0)
se incorporan varios
onstructor de programacin orientada a objetos. Su creacin y desarrollo se da
en el mbito de los sistemas libres, bajo la licencia GNU. Existen muchos editores y entornos
integrados de desarrollo disponibles en el mercado para desarrollar aplicaciones en PHP. Para el
desarrollo del sistema se utiliz el editor OpenKomodo de ActiveState en su versin 5.0.
2.8 Conclusiones del captulo

La importancia de los temas desarrollados en este captulo radica en que para lograr satisfacer las
necesidades del cliente con respecto al sistema, es necesario tener un conocimiento a profundidad de
los conceptos vinculados y de las herramientas que agilizan el proceso de desarrollo. Este
conocimiento permite abordar el problema de manera eficaz y as obtener un producto de calidad con
el menor esfuerzo posible.
Captulo 3 Desarrollo de la primera versin del sistema
35
Captulo 3
Desarrollo de la primera versin del sistema
El presente captulo describe las fases de desarrollo de la primera versin del Sistema de Gestin de
Incidentes de Falla (SINCFA). Como se mencion en el Captulo 1, para el desarrollo del sistema se
utiliza el Mtodo Watch en su versin 2004 [5]. A continuacin se describe cada una de las fases
contempladas en el mtodo y que son aplicadas para obtener la primera versin del sistema. Se
comienza hablando de la planificacin estimada de recursos y tiempo para la primera fase del
proyecto, se describe el modelado de negocios realizado para la unidad organizativa en estudio (la
Gerencia MAP, especficamente la Coordinacin de Confiabilidad), se comenta acerca de los
requisitos de la aplicacin y de los casos de uso modelados, se describe el diseo de la arquitectura y la
implementacin de los componentes, para finalmente mencionar los resultados obtenidos en las
pruebas de esta primera versin. Se culmina el captulo con una breve revisin de los requisitos y una
discusin acerca de las ocurrencias de mayor impacto durante el desarrollo.
3.1 Planificacin del proyecto

La planificacin y estimacin de los recursos necesarios para el desarrollo del producto resulta esencial
dentro de cualquier proyecto de desarrollo de software. Durante las primeras conversaciones con los
usuarios y el cliente, se tena previsto desarrollar el sistema mediante tres iteraciones del mtodo
Watch: la primera iteracin se iba a concentrar en el modelado de negocios y la especificacin de
requisitos, la segunda iba a enfocarse en el diseo detallado de la arquitectura del sistema y la
implementacin de los primeros componentes, mientras que en la tercera iteracin se iba a obtener la
implementacin definitiva del sistema y las pruebas finales. La planificacin se basaba en el supuesto
36
de que el sistema solamente se encargara de la generacin de indicadores de disponibilidad y fallas en

la plataforma a partir de un conjunto de datos suministrados por los usuarios.
Luego de conversaciones posteriores, durante la fase de anlisis del problema, se observa como
los requisitos y expectativas del cliente, respecto al sistema, abarcan un alcance mucho mayor:
automatizar el vaciado de las minutas de reuniones de incidentes diarios, integrando los datos
reportados en estas minutas con los datos manejados por el Centro Integral de Monitoreo, todo ello
con miras a automatizar el proceso de gestin de incidentes de falla en la plataforma desde el
momento en que los grupos solucionadores reportan el incidente, hasta cuando los analistas de
confiabilidad extraen los indicadores. La cantidad de tiempo y recursos necesarios para desarrollar el
sistema se incrementan considerablemente. Es entonces necesario reducir el nmero de iteraciones
del mtodo Watch a dos e incrementar el tiempo estimado para el desarrollo del proyecto (Ver Anexo
A). En cada iteracin se obtiene una versin operativa del sistema, siendo la segunda una versin
mejorada de la primera. La primera iteracin se concentra en el modelado de los procesos de
negocio, la satisfaccin de los principales requisitos del cliente y el desarrollo de los componentes base
del sistema, En la segunda iteracin los esfuerzos se concentran en incorporar nuevos requisitos,
desarrollar los componentes necesarios, integrar dichos componentes con los componentes ya
desarrollados en la primera iteracin y realizar las pruebas finales al sistema.
3.2 Modelado de Negocios

Esta fase resulta vital dentro del proceso de desarrollo del producto de software, pues permite
obtener un conocimiento a fondo del sistema de negocios u organizacin bajo la cual se enmarca el
proyecto. Un conocimiento a profundidad del dominio de la aplicacin resulta esencial para
determinar de la mejor manera posible sus requisitos [22].
En el contexto de las aplicaciones empresariales, el dominio de aplicacin se refiere a la
organizacin o sistema de negocios que ser apoyada por la aplicacin o SI, obteniendo como
producto final el modelo de negocios de la organizacin. Un modelo de negocios es una
representacin que captura la estructura y dinmica de la organizacin objetivo bajo la cual se
incorporar el SI. Mediante el modelo de negocios es posible obtener un conocimiento a profundidad
37
de la organizacin, sus problemas de informacin y los requisitos funcionales que deben ser satisfechos
por el SI [5].
3.2.1 Delimitacin del sistema de negocios

Dentro de PDVSA AIT Servicios Comunes Centro, la Gerencia de Mantenimiento de la Plataforma
(MAP) coordina los recursos necesarios para la ejecucin del mantenimiento de los equipos y
servicios que integran la plataforma tecnolgica. La ejecucin del mantenimiento de la plataforma
tiene como objetivo maximizar la disponibilidad de los equipos y sistemas a un mnimo costo. A pesar
de que en el proceso intervienen casi todas las subgerencias de PDVSA AIT SCC, dentro de los
subprocesos que seran apoyados por el SIW slo interviene directamente la Gerencia MAP, mientras
que la Gerencia de Gestin del Servicio (GDS) acta indirectamente brindando apoyo en el control de
las reuniones de incidentes diarios. Ambas gerencias aparecen resaltadas dentro del organigrama de la
Figura 3.1.
Figura 3.1 Delimitacin del sistema de Negocios
38
3.2.2 Diagrama de Procesos del negocio

Mediante el modelado de los procesos del negocio es posible la descripcin de la organizacin en
trminos de las actividades que estn diseadas, organizadas y que se llevan a cabo para que sta logre
alcanzar sus objetivos [22].
El proceso fundamental que realiza la Gerencia MAP de PDVSA AIT SCC es la ejecucin del
Mantenimiento de la Plataforma. Dicho proceso aparece resumido en el diagrama de la Figura 3.2. En
l se establece el conjunto de eventos que originan la realizacin del proceso, los actores que generan
dichos eventos, los lineamientos que rigen el proceso, el objetivo principal del mantenimiento, los
productos e informacin que se generan, la informacin requerida por el proceso y el conjunto de
actores encargados de llevarlo a cabo.
Figura 3.2 Diagrama de procesos del Mantenimiento de la Plataforma
3.2.3 Estructura de la Gerencia MAP

La Gerencia MAP se encuentra organizada en seis unidades operativas y tres unidades de apoyo. Las
unidades operativas coordinan a su vez un conjunto de grupos operativos solucionadores, encargados
de realizar mantenimiento a las especialidades dentro de la plataforma. Las unidades de apoyo
39
coordinan y controlan los recursos para la ejecucin del mantenimiento. La figura 3.3 muestra la
estructura de la Gerencia MAP.
Gerencia
MAP
Planificacin y
Programacin del
Mantenimiento
Centro Integral de
Monitoreo
Confiabilidad de la
Plataforma
Infraestructura
Transmisin
Redes
Dispositivos de
Campo
Plataforma TI
Aplicaciones, ATC
y Bases de Datos
Figura 3.3 Estructura Organizativa Gerencia MAP
3.2.4 Cadena de Valor de la Gerencia MAP

La cadena de valor es una representacin del conjunto de procesos que se llevan a cabo dentro de la
organizacin para el logro de sus objetivos. El concepto de cadena de valor fue popularizado por
Michael Porter en 1985 [23]. De acuerdo con Porter, toda compaa puede entenderse como una
organizacin humana que ejecuta un conjunto de actividades mediante las cuales se crea valor para el
cliente. La cadena de valor divide estas actividades en dos categoras: actividades primarias, que
abarcan todos los procesos fundamentales mediante los cuales la organizacin genera valor, y
actividades de apoyo, que no forman parte del proceso productivo como tal, pero brindan soporte
para la ejecucin de las actividades primarias. Analizando cada actividad dentro de una organizacin en
trminos de su cadena de valor, una empresa puede aislar las fuentes potenciales de su ventaja
competitiva. A pesar de que el concepto de cadena de valor est basado en empresas de produccin,
puede ser ampliado para apoyar la planificacin estratgica dentro de cualquier unidad de negocio con
fines claramente establecidos [24].
40
En el caso de la Gerencia MAP, la cadena de valor es un equivalente a su mapa de procesos y

especifica los procesos fundamentales llevados a cabo por la unidad para el logro de sus objetivos junto
con los procesos que no intervienen de manera directa sobre sus actividades pero que permiten la
planificacin y optimizacin del mantenimiento. Dentro del diagrama de la Figura 3.4 se muestra la
cadena de valor de la Gerencia MAP y se resaltan los procesos que seran apoyados por la
implementacin del SIW. Estos procesos sern descritos con mayor detalle.
Figura 3.4 Cadena de Valor de la Gerencia MAP
Vale la pena resaltar que la forma como se representan los procesos fundamentales y de apoyo
dentro del diagrama no implican ningn tipo de secuencia. Si bien existe dependencia entre los
resultados de algunos procesos y las entradas de otros, estos se pueden ejecutar simultneamente o sin
seguir un orden especfico.
La clasificacin del mantenimiento determina la secuencia de actividades que se llevarn a cabo
durante su ejecucin, ste puede ser a condicin, a frecuencia fija, preventivo, de optimizacin y
41
correctivo. Dependiendo de la naturaleza del mantenimiento, la generacin de las rdenes puede ser
una actividad planificada o una reaccin ante algn incidente. La ejecucin del mantenimiento puede
realizarse remotamente o en sitio. El registro de la actividad de mantenimiento es casi tan importante
como la actividad en si, pues garantiza la existencia de datos histricos acerca de la ocurrencia de fallas
en los equipos y sistemas de la plataforma. La planificacin y programacin del mantenimiento
comprende la estimacin de recursos necesarios para las actividades a ejecutar, la definicin de
estrategias a aplicar con el fin de optimizar el desempeo de la plataforma y muchas veces, la
generacin de rdenes de mantenimiento preventivos o de optimizacin. La planificacin del
mantenimiento muchas veces se apoya en los anlisis realizados aplicando ingeniera de confiabilidad.
La aplicacin de ingeniera de confiabilidad utiliza los datos estadsticos generados en el proceso de
registro de las actividades de mantenimiento para emitir anlisis y recomendaciones tiles para
optimizar el desempeo de las actividades de mantenimiento. El proceso de ingeniera de
confiabilidad involucra tambin la supervisin y control del estado de la plataforma. El monitoreo de
la plataforma detecta actividades de mantenimiento a condicin y genera las rdenes
correspondientes. A continuacin se explican detalladamente los procesos resaltados en la Figura 3.4.
i) PF 4 Registrar mantenimiento ejecutado

La existencia de una orden de mantenimiento conlleva a que los analistas dentro de las especialidades
de la Gerencia MAP ejecuten actividades de mantenimiento de manera remota o en el sitio donde
corresponda. Una vez ejecutado el conjunto de actividades, se elabora un registro ordenado y
detallado del mantenimiento realizado. Esto permite reunir datos histricos sobre los incidentes y
problemas ocurridos en sistemas y equipos, los modos en que se pueden producir las fallas, los
tiempos de operacin entre las fallas de la plataforma, el impacto de los incidentes sobre el negocio, la
cantidad de recursos (tiempo, dinero, recursos auxiliares) utilizados en el mantenimiento, y las
actividades necesarias para finalizar el incidente. El registro del mantenimiento es de suma
importancia porque cierra el ciclo de la actividad, reflejando la realidad de la ejecucin de la misma.
Es importante resaltar que no todas las actividades de mantenimiento son generadas por fallas en la
plataforma, como es el caso de los mantenimientos preventivos y a frecuencia fija. Sin embargo, para
efectos del presente proyecto, las actividades de mantenimiento correctivo fueron el centro de
42
atencin. En la Figura 3.5 se muestra el diagrama del proceso PF 4 sealando, entre otras cosas, sus
entradas, salidas y productos.
ii) PA 2 Aplicar Ingeniera de Confiabilidad

La aplicacin de ingeniera de confiabilidad busca lograr la optimizacin de la plataforma mediante las
actividades de diagnstico y control de los equipos y sistemas que la integran. El diagnstico de la
plataforma permite identificar las reas en las que resulta oportuno realizar mejoras al negocio y
ejecutar acciones correctivas para reducir los costos asociados al mantenimiento, representando una
mejora en la seguridad y confiabilidad de los activos. Mediante las actividades realizadas en el
diagnstico de la plataforma es posible establecer una ruta crtica a seguir para aplicar acciones
ptimas. El control de la plataforma se realiza mediante las herramientas propias de la ingeniera de
confiabilidad (Mantenimiento Centrado en Confiabilidad (MCC) y Anlisis Causa Raz (ACR)) que
contribuyen a controlar los parmetros que definen el funcionamiento adecuado de la plataforma y
permiten garantizar que los activos que la conforman se comporten adecuadamente dentro de un
contexto operativo establecido y durante un determinado perodo de tiempo.
De la mano con las actividades de control de la plataforma, se encuentran las actividades de
optimizacin. La optimizacin de la plataforma consiste en el modelado y anlisis de los distintos
escenarios que se pueden presentar para as determinar el momento oportuno en el que se pueda
realizar una actividad (mantenimiento mayor, inspeccin, etc.), permitiendo conocer la viabilidad
econmica del mantenimiento y determinar la cantidad ptima de recursos. Ante alguna necesidad de
optimizar el mantenimiento de la plataforma para prolongar su vida til, se toma la solicitud emitida
por la etapa de control o diagnstico, se evalan las diferentes estrategias a optimizar y las vas de
canalizacin, se ponen en prctica las consideraciones, adecuaciones o mejoras pertinentes y se emiten
las recomendaciones que permiten ajustar el plan de mantenimiento, obtenindose tambin insumos
que generan los indicadores operativos de la plataforma. El diagrama general del proceso de aplicacin
de ingeniera de confiabilidad se muestra en la Figura 3.6.
43
iii) PA 3 Monitorear la plataforma

Mediante esta actividad se identifican los mantenimientos a condicin en la plataforma, cuya necesidad
pudo generarse de forma preactiva (visualizada en los planes de mantenimiento) o de manera
reactiva(a partir de problemas provenientes de GDS o detectados mediante las herramientas propias
de monitoreo). Dependiendo de la naturaleza de la tarea de mantenimiento identificada, se procede a
generar una orden o se realiza un monitoreo continuo de las variables seleccionadas hasta detectar un
incidente (que genere prdida total o parcial de la funcin), el cual genera una orden o tiene una
solucin inmediata remotamente. El diagrama de la Figura 3.7 muestra el proceso de forma general.
Figura 3.5 Diagrama del proceso Registrar mantenimiento ejecutado
Figura 3.6 Diagrama del proceso Aplicar Ingeniera de Confiabilidad
Figura 3.7 Diagrama del proceso Monitorear la plataforma
44
45
3.2.5 Diagrama de flujo entre procesos para la gestin de incidentes de

falla
Con un mayor conocimiento de los procesos llevados a cabo por la Gerencia MAP, se empieza a
analizar el conjunto de actividades que son automatizadas mediante el SIW. Uno de los tipos de
mantenimientos que se llevan a cabo en la plataforma es el mantenimiento correctivo. La ejecucin de
mantenimientos correctivos es generada a partir de incidentes de falla ocurridos durante las guardias
de los analistas de los grupos operativos solucionadores. El flujo de actividades que se describe a
continuacin vincula cada uno de los procesos que ya fueron descritos en la parte anterior e incorpora
sin mayor detalle el proceso PF3 Ejecutar Mantenimiento y el proceso llevado a cabo por la Gerencia
de Gestin de Servicio. Vale la pena destacar que estos dos procesos no fueron descritos con mucho
detalle en la parte anterior pues no se considera que se encuentren vinculados esencialmente con el
dominio de la aplicacin. El diagrama de la Figura 3.8 muestra el flujo de las actividades llevadas a
cabo para gestionar los reportes de incidentes de falla durante el perodo de tiempo en que se realiza
el estudio.
La implementacin de un SIW para automatizar el proceso permitira agilizar la consulta y el
clculo de los indicadores operativos de la plataforma. El papel jugado por la Gerencia GDS se
desplegara del flujo de actividades principal y pasara a ser un agregado dentro del proceso de gestin
de incidentes de falla. Armar la minuta dejara de ser su responsabilidad, pues sta podra ser obtenida
directamente de la consulta al sistema, evitando as que la Coordinacin de Confiabilidad dependiera
de dicho documento para realizar sus anlisis. Adicionalmente los indicadores seran complementados
con los datos manejados por el Centro Integral de Monitoreo acerca de las notificaciones emitidas. El
diagrama de actividades propuesto luego de la implementacin del SIW se muestra en la Figura 3.9
Figura 3.8 Diagrama de flujo entre procesos para la gestin de incidentes de falla
46
Figura 3.9 Flujo de actividades a obtener luego de automatizar el proceso
47
48
3.2.6 Identificacin de las reglas de negocio

Las reglas de negocio describen, controlan y restringen la estructura y las operaciones de la
organizacin, en nuestro caso de la Gerencia MAP. Para los procesos descritos en la parte anterior se
encontraron las siguientes reglas de negocio:
1. Normas de Seguridad Higiene y Ambiente de PDVSA.

2. Lineamientos del Sistema de Gerencia Integral de Riesgos.
3. Normas de Proteccin de Activos de Informacin.
4. Normas de Proteccin de Activos e Informacin.
5. Normas Tcnicas de PDVSA.
6. Norma SAE JA1011 para definir tipos de mantenimiento.
7. Norma ISO 9000-2000.
8. Normas internacionales de instrumentacin y Sistemas (ISA)
9. Normas OSA de administracin de seguridad y salud ocupacional.
10. Diariamente los Grupos Operativos Solucionadores (GOS) se encuentran atentos ante cualquier
incidente que surja respecto al desempeo de los servicios que brinda la plataforma AIT y estn
preparados para resolver tales incidentes. Las guardias que ejecutan los GOS tienen una duracin
de una semana y existe un grupo operativo por cada una de las siguientes especialidades:
x
Centro integral de Monitoreo.
Servidores Windows.
Servidores AS/400.
Servidores UNIX.
Redes WAN.
Redes LAN.
Conmutacin
Redes de Transmisin.
Bases de Datos.
Respaldo y Almacenamiento.
SAP.
SAND.
STARS-PAWS-RD-RDOJD.
SICOPROSA-SIGPLAN Aplicaciones Web-AIT.
FILIP / SIMAF / SIRET RESET, GADET, SIPREFID, NAF, FUP.
ATC.
Servidores Z-Series.
Soporte Integral.
Plataformas de Escritorio.
Dispositivos de campo.
Control de activos.
Infraestructura.
Nmina.
Seguridad AIT.
Video Conferencia.
Instalaciones.
Soporte a Usuarios Crticos.
11. Simultneamente a los GOS, el
49
Centro Integral de Monitoreo supervisa el estado y
funcionamiento de la mayora de los dispositivos fsicos y de algunas aplicaciones. Para ello se

apoya en el uso de sistemas especializados en el monitoreo de los recursos. Uno de los ms
importantes es el sistema Nagios.
12. El sistema Nagios enva seales a travs de la red esperando respuesta por parte de los equipos
(Hosts), en caso de recibir una respuesta, se registra que el equipo est funcionando correctamente
y no se ejecuta ninguna accin. En caso contrario se continan enviando seales en intervalos de
tiempo cada vez menores, de no detectarse respuesta por parte del equipo se generan
notificaciones va SMS a los analistas responsables de su mantenimiento, generndose as una
orden de mantenimiento correctivo. El sistema sigue enviando seales al equipo esperando
50
obtener una respuesta y, al momento de recibirla, registra que el equipo se encuentra

funcionando normalmente.
13. De producirse alguna falla en alguno de los servicios de la plataforma a cualquier nivel dentro de
la organizacin, la persona que detecta la falla la puede reportar por telfono a la Gerencia GDS a
travs del Centro de Atencin al Usuario. El Centro de Atencin al Usuario se encarga de
identificar el grupo solucionador correspondiente y generar la orden de mantenimiento.
14. Es responsabilidad del Centro de Atencin al Usuario garantizar la disponibilidad de todos los
servicios brindados por AIT SCC. Por ello se encarga de rastrear las rdenes de mantenimiento
emitidas utilizando sistemas especializados en el control y seguimiento de los casos generados por
los usuarios.
15. Al ser notificado con el incidente de falla, el analista de guardia verifica que la falla sea de alguno
de los servicios bajo su supervisin. De ser as procede a determinar la solucin del problema, en
caso contrario remite a la persona encargada de reportar la falla (CIM o Centro de Atencin al
Usuario) para que reporte al grupo adecuado.
16. Una vez solucionado el incidente, el GOS comunica a quien la notific que ya ha finalizado el
problema. Tambin le corresponde generar un reporte del mantenimiento ejecutado.
17. Diariamente a las 8:00 a.m. se realiza una reunin de incidentes diarios en la que cada uno de los
analistas de guardia informa acerca de las eventualidades que se produjeron durante la jornada del
da anterior. El analista debe enviar al personal de GDS un reporte escrito indicando los datos del
incidente. La informacin proporcionada contiene datos acerca del analista de guardia, el tiempo
de inicio y de fin de la falla, el impacto sobre el negocio, el diagnstico de la causa de la falla, la
accin ejecutada para resolverla y el estado actual del servicio correspondiente (puede ocurrir que
al momento de la reunin no se haya solucionado del todo la falla).
18. Una vez realizada la reunin, el personal de GDS se encarga de integrar todos los reportes, armar
en un documento la minuta de la reunin de incidentes diarios y de ponerlo a disposicin de todos
los involucrados.
19. El personal de la Coordinacin de Confiabilidad se encarga de revisar la minuta de la reunin
diaria de incidentes y transferir los datos de dicha minuta a una Base de Datos, el proceso de
51
llenado de la base de datos implica la revisin manual y la depuracin del documento de la

minuta.
20. De la base de datos de incidentes se extraen indicadores como tiempo promedio de solucin de
fallas (TPSF), el cual viene dado por la ecuacin:
NumFallas
TPSF
(FechaSolucinFalla FechaInicioFalla ) * 24 (HoraSolucinFalla HoraInicioFalla ) * 24

i 1
NumFallas
21. Otro de los indicadores calculados a partir de la base de datos de incidentes es el Tiempo
Promedio Entre Fallas (TPEF) el cual viene dado por:
TPEF
NumFallas
i 2
( FechaInicioFallai FechaInicioFallai 1 ) * 24 ( HoraInicioFallai HoraInicioFallai 1 ) * 24

NumFallas
22. De la base de datos de incidentes se extrae el nmero de fallas por especialidad, que viene
representado por el conteo de incidentes reportado por cada GOS.
De las reglas descritas en la parte anterior, las reglas 10, 12, 15, 16, 17, 19, 20, 21 y 22 son
implementadas como parte de la lgica de negocios del SINCFA.
3.2.7 Modelado de los actores de negocio

Un actor puede ser una persona o una mquina capaz de ejecutar un conjunto de tareas definidas. Los
actores interactan con el sistema de negocios para satisfacer sus necesidades o proveer recursos. La
identificacin y el modelado de los actores que intervienen en el proceso de negocios permiten lograr
un mayor entendimiento de las necesidades de informacin que motivan el desarrollo del sistema.
Para el desarrollo del SINCFA se identifican cuatro actores principales cuyos objetivos dentro del
dominio de la aplicacin se mencionan en la Tabla 3.1.
Actor
52
Objetivos.
1. Llenar la Base de datos de incidentes a partir de las minutas
de las reuniones de incidentes diarios.
2. Obtener reportes de falla y disponibilidad por especialidad
para un perodo de tiempo determinado.
Analista de Confiabilidad.
3. Obtener reportes de grupos operativos con mayor cantidad

de incidentes.
4. Generar recomendaciones acerca de la criticidad y
confiabilidad de la plataforma
1. Monitorear el estado de la plataforma AIT.
Analistas del Centro Integral de
2. Reportar incidentes de fallas a los GOS correspondientes.

3. Generar Reportes de incidentes detectados durante una
Monitoreo
jornada
1. Atender incidentes ocurridos para los activos de su
especialidad.
Analistas de Grupos Operativos
2. Proporcionar reportes de incidentes diarios.

3. Reportar solucin de incidente de falla.
Solucionadores
4. Determinar impacto de la falla sobre la plataforma.

1. Reunir los reportes enviados por los analistas en las minutas
Centro de Atencin al Usuario
(GDS)
de incidentes diarios.
2. Suministrar minuta de incidentes diarios a todos los
interesados.
Tabla 3.1 Modelado de actores del negocio
3.2.8 Identificacin de los objetos de negocio

En esta actividad se determinan los diferentes tipos de objetos que intervienen en los procesos de
negocio y se definen las relaciones entre estos. La identificacin de los objetos del negocio constituye
53
la primera aproximacin a los tipos de datos que sern implementados a travs del SIW. En el caso del
SINCFA y sus procesos asociados, se han identificado las siguientes entidades:
Incidente: Al producirse una interrupcin o falla en alguno de los componentes de la plataforma se

dice que se ha producido un incidente de falla. Un incidente de falla tiene un nico reporte
asociado.
Componente: Un componente de la plataforma es un equipo o sistema que es responsabilidad de un
grupo operativo. Un componente se distingue por un nombre nico dentro de la plataforma y una
ubicacin.
Minuta: Los incidentes reportados por los analistas durante una reunin de guardia se incluyen en la
minuta de la reunin de incidentes diarios.
AlertaNagios: Cuando el sistema Nagios detecta que un componente no se encuentra funcionando
correctamente se registra una alerta de cada del componente. Cuando sistema detecta que el
componente vuelve a funcionar normalmente se registra el fin de la alerta. Una alerta puede estar
asociada con un nico componente.
Notificacin: Al momento de detectarse la falla en el componente, el sistema Nagios genera una
notificacin a los analistas responsables del mantenimiento. Del mismo modo se generan
notificaciones al momento de finalizar la alerta.
Una vez identificados los objetos que intervienen en los procesos descritos, se procede a modelar
las relaciones entre esos objetos. El diagrama de la Figura 3.10 muestra el modelado de los objetos
principales identificados.
54
Figura 3.10 Modelado de objetos de negocio
3.3 Ingeniera de Requisitos

Dentro del mtodo Watch, la fase de ingeniera de requisitos comprende dos fases primordiales: una
de ellas es la definicin y la otra es la especificacin del conjunto de requisitos funcionales y no
funcionales del producto de software. En la fase de definicin se clasifican los requisitos y se les asigna
prioridades de acuerdo con las necesidades del cliente. Tambin se lleva a cabo la negociacin de los
requisitos, siendo posible que el equipo encargado del desarrollo proponga nuevos requisitos y
modifique algunos de los previamente establecidos a fin de que exista compatibilidad entre los
mismos. La fase de especificacin de requisitos deriva un conjunto de modelos en los que se obtiene la
primera visin de lo que ser la arquitectura del sistema.
Para la ingeniera de requisitos del SINCFA se comienza realizando una descripcin en lenguaje
natural de los necesidades expresadas por el cliente durante las reuniones, a partir de esta descripcin
55
se realiza una clasificacin de los requisitos en funcionales y no funcionales y a partir de los funcionales
se generan los casos de uso del sistema.
3.3.1 Definicin de los requisitos de software

Para definir los requisitos se deben tomar en consideracin los actores del proceso. Dentro de la fase
de modelado de negocio se obtuvo un primer panorama del conjunto de actores dentro de la empresa
que intervenan en los procesos a ser apoyados por el SIW. Sin embargo, en esta fase slo se
determinaron los objetivos de los actores en el contexto del sistema de negocios y no se fue
totalmente explcito en la definicin de los roles de dichos actores en su interaccin con el SIW. A
continuacin se enuncian los principales actores dentro del proceso de Desarrollo:
Cliente: Es quien tiene el problema y desea que sea solucionado, ste solicita el desarrollo de un
determinado sistema de software de acuerdo a sus problemas y necesidades, debe aportar sus
ideas al proceso de diseo. En el caso del SIW a implementar, el cliente es la Gerencia MAP de
PDVSA AIT SCC, particularmente la Coordinacin de Confiabilidad, la cual est representada
por el lder de la unidad Ing. Mximo Silveira.
Desarrolladores/Analistas: Los miembros del equipo de desarrolladores ejecutan diferentes roles
como por ejemplo: coordinador, analista de sistemas, promotor de software y consejero o gua
informtico. Para satisfacer las necesidades del cliente, los desarrolladores intentan cumplir con
sus peticiones en caractersticas especficas de calidad. El grupo de desarrolladores y analistas en
este caso viene representado por el tesista Carlos Germn Medina Albornoz, el tutor acadmico
Prof. Judith Barrios y el tutor industrial ing. Jos Casanova.
Usuarios del sistema final: La experiencia y aportes brindados por las personas a las cuales est
dirigido el SIW son esenciales para el proceso de desarrollo. En este caso, el grupo de usuarios
finales del SIW, hasta los momentos, est constituido por los miembros de la Coordinacin de
Confiabilidad. Sin embargo, se deben permitir diferentes niveles de acceso a los usuarios del
sistema, con miras a que ste pueda ser utilizado por miembros de otras unidades o gerencias. Es
decir, el sistema debe reconocer por lo menos los siguientes perfiles de usuario:
56
Administrador: El administrador debe ser capaz de acceder al sistema para la

correccin de fallas, la incorporacin de nuevos servicios en el inventario de la
plataforma, el ingreso de datos, la consulta sobre la base de datos de incidentes y la
base de datos de Nagios, la modificacin de datos de incidentes ya ingresados y la
eliminacin de registros errneos o que carezcan de inters para el sistema de
negocios.
Usuario Avanzado: El perfil de usuario avanzado debe permitir tanto el ingreso de

datos, la consulta sobre la base de datos de incidentes y la base de datos de monitoreo
y su comparacin, la modificacin de datos ya ingresados y la eliminacin de registros
errneos o que carezcan de inters para el sistema de negocios.
Usuario Intermedio: El usuario intermedio podr realizar la insercin de datos de

incidentes de falla y realizar consultas sobre la base de datos de incidentes.
Usuarios Generales: El usuario general podr consultar sobre la base de datos de

incidentes.
3.3.2 Definicin de requisitos segn actores

i) Requisitos del Cliente.
1. Los estilos del diseo utilizado en el desarrollo de las pginas web deben cumplir con los
estndares de la gerencia AIT, as como tambin, los nombres de las pginas, funciones,
variables, procedimientos almacenados, vistas y tablas de datos del sistema.
2. El acceso al sistema solo puede realizarse a travs de la intranet de la empresa.
3. Que tenga interfaz grfica agradable y de fcil entendimiento.
4. Todas las respuestas a las consultas al servidor de base de datos deben ser lo ms rpidas y
eficientes posible, es por esto, que se ha definido el tiempo mximo a 60 seg., solo se podr
exceder este tiempo con una clara justificacin del tiempo requerido.
5. El sistema debe validar el perfil del usuario al momento de iniciar sesin contra el directorio
activo de PDVSA.
6. Presentar mensajes de error que sean de fcil comprensin.
57
7. El sistema debe estar implementado utilizando una arquitectura de tres capas distribuidas en
tres nodos.
ii) Requisitos de los usuarios.
1. Debe permitir la introduccin individual de los incidentes de fallas. Los datos introducidos
acerca de cada incidente de falla deben incluir la siguiente informacin:
a. Fecha de la minuta.
b. Grupo Operativo que reporta.
c. Localidad en la que se produce el incidente.
d. Componente en que se produce el incidente.
e. Resumen de incidente.
f. Fecha de inicio del incidente.
g. Hora de inicio del incidente.
h. Fecha de fin del incidente.
i. Hora de fin del incidente.
j. Causa del incidente.
k. Acciones tomadas para resolver el incidente.
l. Impacto del incidente.
m. Comentarios sobre el incidente.
n. Nombre del analista que reporta.
2. El sistema debe calcular los siguientes indicadores para cada registro de incidente de falla:
a. Tiempo entre falla actual y falla anterior dentro del grupo.
b. Tiempo entre falla actual y falla anterior del componente.
c. Duracin de la falla.
3. Generar reportes de las fallas totales ocurridas en la plataforma, es decir, debe ser posible la
generacin de reportes que indiquen el nmero de ocurrencias de fallas en los dispositivos
durante un periodo determinado de tiempo fijado por el usuario. Los reportes de fallas totales
ocurridas deben incluir los indicadores de TPEF, TPSF y Nmero de fallas para el grupo.
4. Se debe permitir al usuario filtrar los reportes de Falla por Grupo Operativo.
58
5. Al momento de reportar un incidente, la seleccin del componente en que se produjo la falla

debe ser dinmica, pues se debe permitir al usuario escoger la ubicacin y el grupo operativo
para poder seleccionar luego slo los componentes dentro de esos dos parmetros.
6. Generar reportes de fallas por componente durante un perodo de tiempo determinado. Los
reportes de fallas totales ocurridas deben incluir los indicadores de TPEF, TPSF y Nmero de
fallas para el componente.
7. Generar reportes de soluciones de fallas en los que para cada incidente de falla ocurrido para
un determinado componente, se indiquen las causas, soluciones y acciones tomadas.
8. Permitir realizar reportes conjuntos entre los datos obtenidos de las minutas y los obtenidos a
partir de Nagios.
9. Generar los reportes en formatos fcilmente exportables a alguna hoja de clculo, de modo
que puedan ser utilizados para el apoyo de informes dirigidos a la alta gerencia.
10. El sistema debe permitir cerrar sesin al usuario actual.
11. El sistema debe permitir al usuario verificar informacin del reporte del incidente antes de
ingresarla al sistema.
12. El sistema debe incorporar un mdulo de ayuda en lnea al usuario.
13. Permitir manejar un inventario sencillo de los componentes que integran la plataforma
tecnolgica de PDVSA AIT SCC. Este inventario debe incluir el nombre del componente, el
grupo responsable y su ubicacin.
iii) Requisitos del desarrollador.
1. El software se debe implantar con el lenguaje de programacin PHP en el lado del servidor y
contenidos en HTML y Javascript en el lado del cliente.
2. El sistema gestor de bases de datos debe ser PostgreSQL.
3. El equipo donde se ejecute el sistema debe tener las siguientes caractersticas:
a. Memoria principal de al menos 128 megas
b. Procesador mayor a 1.0 Ghz.
c. Un monitor.
d. Un ratn
59
e. Un Teclado.
f. Una tarjeta de video de 32 MB.
g. Una tarjeta de red con capacidad de conexin a la intranet de la Empresa.
h. El sistema operativo Windows XP o Linux.
i. Navegador Mozilla Firefox 3.0.
3.3.3 Clasificacin de los requisitos y definicin de prioridades

Los requisitos pueden clasificarse en dos tipos:
Requisitos funcionales: describen las funciones y servicios que el sistema debe hacer.
Requisitos no funcionales: describen las diferentes respuestas que debe dar el sistema ante los
distintos tipos de errores, los cuales imponen restricciones y atributos.
Adems de clasificarse, los requisitos son priorizados dependiendo de su importancia para el

desarrollo del producto y el resultado que se desea obtener. Es por esto que los requisitos se clasifican
con nmeros del 1 al 5, siendo el 1 la prioridad ms baja (requisito casi prescindible) y el 5 la
prioridad ms alta (requisito obligatorio). La Tabla 3.2 muestra la clasificacin de los requisitos.
N de
requsito
R1
R2
R3
R4
Nombre del
requisito
El sistema debe cumplir con
los estndares de la gerencia
AIT.
El acceso al sistema slo
puede realizarse a travs de
la intranet de la empresa.
El sistema debe incorporar
interfaz grfica agradable y
de fcil entendimiento.
Las respuestas a las consultas
al servidor de base de datos
deben ser lo ms rpidas y
eficientes posible
Clasificacin. Prioridad.
Tipo de
requisito.
No Funcional.
Restriccin.
No Funcional.
Restriccin.
No Funcional.
Aseguramiento de
la calidad.
No Funcional.
Aseguramiento de
la calidad.
N de
requsito
R5
R6
R7
R8
R9
R10
R11
R12
R13
R14
R15
R16
Nombre del
requisito
Validar el perfil del usuario
al iniciar sesin contra el
directorio activo.
El sistema debe presentar
mensajes de error que sean
de fcil comprensin.
La arquitectura debe ser
implementada en 3 capas
distribuidas en 3 nodos
Permitir introducir los
incidentes de falla.
Calcular indicadores para
cada registro de incidente de
falla.
Generar reportes de las fallas
totales ocurridas en la
plataforma por perodo de
tiempo.
Filtrar los reportes de Falla
por Grupo Operativo.
Ingresar componente en que
se
produjo
la
falla
dinmicamente
seleccionando localidad y
grupo
Generar reportes de fallas
por componente durante un
perodo
de
tiempo
determinado.
Generar
reportes
de
soluciones de fallas.
Realizar consultas sobre las
alertas registradas por el
sistema
Nagios
comparndolas con los
incidentes registrados en las
minutas.
El sistema debe generar los
reportes
en
formatos
fcilmente exportables a una
hoja de clculo.
60
Tipo de
requisito.
Funcional.
Seguridad.
No funcional.
Aseguramiento de
la calidad.
No funcional
Restriccin
Funcional.
Funcionalidad
Funcional.
Funcionalidad
Funcional.
Funcionalidad
Funcional.
Funcionalidad
Funcional
Funcionalidad
Funcional.
Funcionalidad
Funcional.
Funcionalidad
Funcional.
Funcionalidad
No Funcional.
Aseguramiento de
la calidad.
N de
requsito
R17
R18
R19
R20
R21
R22
R23
Nombre del
requisito
61
Permitir cerrar sesin.

Funcional.
El sistema debe permitir al
No Funcional.
usuario
verificar
la
informacin del reporte
antes de ingresarla
Funcional
Manejar un inventario de los
componentes que integran la
plataforma de PDVSA AIT
SCC.
El sistema debe incorporar
No funcional.
ayuda al usuario.
El software se debe
No Funcional.
implantar con el lenguaje
de programacin PHP en el
lado
del servidor y
contenidos en HTML y
Javascript en el lado del
cliente.
El sistema gestor de bases de
No Funcional.
datos debe ser PostgreSQL.
No Funcional.
El equipo donde se ejecute
el sistema debe tener ciertas
caractersticas.
Tabla 3.2 Clasificacin de los requisitos
Tipo de
requisito.
5
4
Funcionalidad.
Uso y factores
humanos.
Funcionalidad
2
5
Aseguramiento de
la calidad.
Restriccin.
Restriccin.
Restriccin.
Vale la pena resaltar que, a pesar de que el producto aqu mostrado es resultado de un proceso de
refinamiento y validacin junto al cliente, en la medida que se sigue avanzando en la primera versin
los requisitos de los actores involucrados y sus expectativas respecto al sistema cambian
constantemente. Por ello se trata de mantener la recoleccin inicial de requisitos, negociando con el
cliente que aquellos que surgieran sobre la marcha sern considerados para el desarrollo de la segunda
versin. De ese modo se trata de abarcar todos los requisitos enunciados.
3.3.4 Definicin de casos de uso

La elaboracin de los casos de uso se realiza clasificando las funciones del sistema de acuerdo al actor
al que van dirigidas. La jerarqua de actores definida se muestra en la Figura 3.11.
62
Figura 3.11 Perfiles de usuario del sistema
La Figura 3.12 indica el modelado de los casos de uso para la interaccin del usuario general con
el sistema. La Figura 3.13 muestra los casos de uso para el usuario intermedio, mientras que las
Figuras 3.14 y 3.15 muestran los diagramas de casos de uso para los usuarios
avanzado y
administrador respectivamente. En cada diagrama, los casos de uso que se incorporan respecto al
diagrama anterior son resaltados en un color ms oscuro.
Figura 3.12 Diagrama de casos de uso para usuario general
63
Figura 3.13 Diagrama de casos de uso para usuario intermedio
64
Figura 3.14 Diagrama de caso de uso para usuario avanzado
65
Figura 3.15 Diagrama de caso de uso para administrador
66
67
i) Descripcin textual de los casos de uso.

Para una mayor comprensin de la secuencia de tareas asociadas a los casos de uso, se hace una breve
descripcin de cada uno de ellos en la Tabla 3.3.
Caso de Nombre del Caso

Uso
de Uso
CU1
Acceder al sistema
CU2
CU3
Validar perfil de
usuario.
Consultar incidentes
por grupo operativo.
CU4
Consultar indicadores
operativos
de
la
plataforma.
CU5
por componente
CU6
por
perodo
de
tiempo.
CU7
Consultar alertas de
Nagios por perodo de
tiempo.
CU8
Procesar log de Nagios
CU9
Consultar reportes de
solucin de incidentes.
Descripcin
El usuario introduce su indicador (nombre de usuario en la red
PDVSA) y su clave en la ventana de inicio del sistema.
El sistema verifica el nombre del usuario y la clave, dndole acceso
a un conjunto de funciones de acuerdo a su perfil.
El usuario introduce el nombre de un grupo operativo. El sistema
genera un reporte de todas las fallas registradas para los
componentes o servicios dentro de ese grupo operativo. Se calcula
la duracin y tiempo entre fallas para cada incidente.
El usuario introduce un perodo de tiempo para consultar los
indicadores de la plataforma. El sistema genera una lista con los
grupos operativos y sus indicadores. Los indicadores calculados son
el TPEF, el TPSF y el nmero total de incidentes.
El usuario introduce el nombre de un componente dentro de la
plataforma AIT. El sistema genera un reporte con todos los
incidentes de falla registrados para ese componente y sus
indicadores. Se calcula la duracin y tiempo entre fallas para cada
incidente.
El usuario introduce una fecha de inicio y una fecha de fin para
consultar los incidentes de falla que se produjeron durante ese
perodo. El sistema genera un reporte de los incidentes registrados
entre esas fechas. Se calcula la duracin y tiempo entre fallas para
cada incidente.
El usuario introduce el perodo de tiempo en el que desea
consultar las alertas detectadas por Nagios. El sistema genera un
reporte con todas las alertas detectadas para ese perodo de
tiempo. Tambin se incluyen los incidentes de falla reportados para
ese perodo.
El sistema procesa el archivo de log del sistema Nagios,
almacenando las alertas relacionadas con la cada y recuperacin de
los componentes de la plataforma.
El usuario introduce el nombre de un componente a consultar. El
sistema genera un reporte de las fallas registradas para ese
componente, los diagnsticos y las soluciones dadas.

Uso
de Uso
CU10
Cerrar sesin.
CU11
CU12
CU13
CU14
CU15
CU16
CU17
68
Descripcin
El usuario cierra su sesin en el sistema.
Ingresar datos
incidente de falla
de El usuario introduce en un formulario los datos de un incidente de

falla. Luego de que el usuario confirme la insercin, el sistema
almacena los datos.
Eliminar incidente.
El usuario elimina los datos de un incidente de falla del sistema,
para ello introduce la fecha del incidente y el nombre del
componente en que se produjo.
Modificar incidente
El usuario actualiza o modifica los datos de algn incidente de falla
almacenado, para ello introduce la fecha del incidente y el nombre
del componente en que se produjo. El sistema carga luego un
formulario para que el usuario edite los datos que considere
necesarios.
Ingresar componente El usuario ingresa un nuevo componente al inventario de
componentes de la plataforma AIT. Luego de que el usuario
confirme la insercin, el sistema almacena los datos del
componente.
Eliminar componente El usuario elimina un componente del inventario de componentes
de la plataforma AIT, para ello introduce el nombre del
componente.
Modificar componente El usuario modifica los datos de un componente dentro del
inventario de componentes de la plataforma AIT, para ello
introduce el nombre del componente. El sistema luego permite la
edicin de los datos del componente.
Consultar inventario El usuario consulta el inventario de componentes de la plataforma
de componentes AIT. AIT. El sistema genera una lista con todos los componentes que
integran la plataforma.
Tabla 3.3 Casos de uso del sistema
3.3.5 Matriz Casos de Uso vs. Requisitos

Parte esencial del proceso de ingeniera de requisitos es la validacin y verificacin de los requisitos
del sistema. Mediante la matriz de Casos de Uso vs. Requisitos es posible determinar si los requisitos
del cliente fueron satisfechos con los casos de uso especificados. En la matriz de la tabla 3.4 se
observa como cada requisito se ve incluido en por lo menos un caso de uso, por lo que se han cubierto
todos los requisitos funcionales del sistema.
Caso de uso CU
Requisito
1
R5
CU CU CU CU CU
2
3
4
5
6
69
CU CU CU CU CU CU CU CU CU CU
7
8
9
10 11 12 13 14 15 16
CU
17
R8
R9
R10
R11

R12
R13
R14
R15
R17

R19
Tabla 3.4 Matriz de Casos de Uso vs. Requisito
3.4 Diseo del sistema

Una vez especificados y definidos los requisitos, se procede a disear el sistema. La fase de diseo
pretende determinar la estructura de la aplicacin a fin de satisfacer los requisitos obtenidos en el paso
anterior, estableciendo la interconexin de los distintos subsistemas que la conforman, junto con los
parmetros que regulan que el sistema apoye los procesos de la organizacin y cumpla con los
objetivos fijados. Dentro de esta fase se establece el conjunto de metas con las que debe cumplir el
diseo, se determina cules de los requerimientos se encuentran relacionados con la arquitectura del
sistema, se describen la arquitectura utilizando distintos enfoques, se disea la interfaz
usuario/sistema y se disea la base de datos.
3.4.1 Metas de diseo

Con el fin de que la aplicacin realmente satisfaga las necesidades expresadas por los actores,
junto con los estndares de rendimiento que se espera que sta cumpla, es necesario fijar un conjunto
70
de objetivos o metas para la fase de diseo del sistema. Las metas de diseo se enuncian a
continuacin:
x La arquitectura del sistema estar basada en el uso de servicios web que estarn claramente
especificados y que podrn ser reutilizados por cualquier componente que los necesite.
x Los componentes diseados van a buscar cumplir los requisitos de los actores involucrados de la
manera ms eficiente posible.
x La arquitectura estar basada en la utilizacin de componentes modulares bien estructurados y
con entradas y salidas claramente definidas.
x El diseo ser fcil de entender y modificar, permitiendo probar y detectar fallas rpidamente.
x El diseo se caracterizar por una alta cohesin de los componentes dentro de cada subsistema y
un bajo acoplamiento, es decir, poca dependencia de componentes de otros subsistemas.
3.4.2 Definicin del estilo arquitectnico y justificacin

Para el desarrollo del SIW se sigue un patrn de diseo basado en una arquitectura de 3 capas. En este
enfoque, la lgica de negocios de la aplicacin se instala y ejecuta en una localidad distinta a la parte
del programa encargada del manejo de los datos y diferente tambin a la utilizada para manejar la
interfaz Usuario/Sistema.
La principal ventaja de la utilizacin de ste patrn est en la capacidad de lograr un sistema
altamente flexible, pues al separar al mximo los tres grupos de componentes dentro de la aplicacin,
se puede modificar alguno de los componentes de una capa sin que ello implique hacer modificaciones
sobre los componentes de las otras capas. Al mismo tiempo se obtiene un cdigo ms limpio y
entendible, garantizando la mantenibilidad y facilidad de prueba.
La distribucin fsica del sistema es otra de las razones que motivan el uso de ste patrn
arquitectnico, pues el SIW se encuentra alojado en 3 servidores distintos: un servidor web, en el
cual se puede alojar todos los componentes relacionados con la presentacin visual del sistema y su
interaccin con los usuarios (ste servidor no posee acceso a la base de datos), un servidor de
aplicaciones, en el cual se puede ejecutar toda la lgica de negocios de la aplicacin y todo lo
71
relacionado al acceso a las bases de datos, y finalmente, un servidor de bases de datos, en el que se
alojan los elementos persistentes del sistema.
Debido a la naturaleza de los servidores, toda la lgica asociada con la manipulacin de los datos
obtenidos mediante consultas con la base de datos es implementada en el servidor de aplicaciones,
mientras que toda la validacin de los datos de entrada y la presentacin a los usuarios es manejada
por el servidor web. La comunicacin entre el servidor de aplicaciones y el servidor web est basada
en la implementacin de servicios web.
3.4.3 Identificacin de subsistemas

Luego de analizar las actividades apoyadas por el sistema, se determina que el mejor criterio para la
subdivisin del SIW es la utilizacin de mdulos o subprogramas.
Se realiza la divisin del sistema en base a los casos de uso, clasificando estos por funcionalidades
similares y dividiendo los subsistemas en funciones ms pequeas que conformarn mdulos ms
simples. De este modo se obtiene una primera divisin del sistema en cuatro subsistemas, tal y como
se muestra en la Figura 3.16.
Figura 3.16 Identificacin de subsistemas
72
El subsistema de control de usuarios se encarga de la validacin del ingreso de usuarios al sistema,

el subsistema de gestin de incidentes y soluciones contiene los componentes relacionados con el
manejo de los datos de incidentes de falla y los reportes obtenidos, el subsistema de gestin de
reportes de monitoreo se encarga de capturar los datos del sistema Nagios y generar los reportes
correspondientes. El subsistema de inventario de componentes AIT maneja la informacin referente a
los componentes que integran la plataforma.
3.4.4 Diseo de componentes

Una de las caractersticas de un buen diseo es que est formado por componentes o mdulos cuyas
entradas y salidas estn bien definidas y sus propsitos estn claramente establecidos. Un componente
de software representa una pieza de software que libera un conjunto de servicios utilizados a travs de
interfaces bien definidas [24].
En base a estos principios, se disea la arquitectura del sistema especificando el conjunto de
componentes que integran cada uno de sus subsistemas. Debido a que se utiliza un enfoque
arquitectnico de 3 capas, se han resaltado los diagramas con colores distintos para indicar que
pertenecen a capas distintas. De este modo, en los siguientes diagramas se muestran los componentes
de la capa de lgica resaltados en color crema, los componentes de la capa de presentacin en color
azul y los componentes de la capa de datos en color verde.
El estilo utilizado en el diseo de los componentes de cada subsistema sigue un mismo patrn que
se caracteriza por:
x
En la capa de presentacin se incluyen componentes de captura y presentacin de datos. Los

componentes de captura de datos por lo general son formularios y se les ha colocado el
estereotipo <<form>> y los componentes de presentacin de datos comienzan con la palabra
Vista. Existen componentes de presentacin que consumen servicios web y se denotan con
el estereotipo <<ws_client>>.
Los componentes de negocio estn representados por el conjunto de servicios web que
implementan la lgica de la aplicacin. Estos componentes se especifican con el estereotipo
<<web_sevicet>>.
73
En la capa de datos los componentes especificados se refieren a cada una de las tablas de la
base de datos.
Otra caracterstica a resaltar del diseo de los componentes es que se logra un mnimo acoplamiento y
una alta cohesin en cada subsistema.
i) Subsistema de control de usuarios

El subsistema de control de usuarios maneja los datos relacionados con los perfiles del usuario,
abarcando los casos de uso CU1, CU4 y CU18. Los componentes que integran el subsistema se
muestran en la figura 3.17. Se observa que se hace referencia a un componente externo que es el
directorio activo de PDVSA. El directorio activo se encuentra alojado en un servidor externo a la
aplicacin y es accedido para validar los perfiles de los usuarios dentro de la red PDVSA.
ii) Subsistema de gestin de incidentes y soluciones

El subsistema de gestin de incidentes y soluciones puede ser visto como el corazn del sistema, pues
maneja los datos relacionados con los incidentes reportados por los analistas que es el objetivo esencial
del sistema dentro de la organizacin. Comprende los casos de uso CU2, CU3, CU5, CU6, CU7,
CU8, CU9, CU11, CU12, CU14 y CU15. Los componentes que integran el subsistema se muestran
en la Figura 3.18. Se especifican entre parntesis los componentes que pertenecen a otros
subsistemas.
iii) Subsistema de gestin de reportes de monitoreo

Este subsistema se encarga de procesar los datos capturados del sistema Nagios y permitir la consulta
en conjunto entre los reportes realizados por los analistas y las notificaciones generadas por dicho
sistema. Para ello se vale de un archivo de texto plano (Nagios.log) que registra todas las
notificaciones emitidas por el sistema, el cual procesa y captura los datos que corresponden a las
74
cadas y recuperaciones de los componentes. Abarca los casos de uso CU10 y CU13. La estructura
del subsistema se muestra en la Figura 3.19.
iv) Subsistema de inventario de componentes AIT.

Este subsistema maneja la informacin de los componentes (equipos y aplicaciones) que integran la
plataforma tecnolgica de PDVSA AIT. Los componentes en l especificados abarcan los casos de uso
CU16, CU18, CU19, CU20 y CU21. Los componentes que integran este subsistema se muestran en
la Figura 3.20.
Figura 3.17 Subsistema de control de usuarios
Figura 3.18 Subsistema de gestin de incidentes y soluciones
75
Figura 3.19 Subsistema de gestin de reportes de monitoreo
76
77
Figura 3.20 Subsistema de inventario de componentes AIT
3.4.5 Diagrama de clases del sistema

A partir del modelo de objetos de negocio obtenido en la primera fase se construye el diagrama de
clases del sistema (Ver Figura 3.21). En l se observa que se han eliminado algunas clases que
aparecan en el diagrama de objetos pero que para efectos de implementacin resultan redundantes,
como es el caso de la clase Reporte. Tambin se observa que algunos de los elementos modelados
78
como actores en la fase de modelado de negocios son incorporados en el diseo, como es el caso de
los analistas y los grupos operativos.
Figura 3.21 Diagrama de clases del sistema
3.4.6 Diagrama de despliegue del sistema

Una vez diseados los componentes y sus interrelaciones, se procede a definir la distribucin de estos
componentes en nodos de proceso. Para especificar el despliegue del sistema se toma en
consideracin el requisito R7 en el que se establece que la arquitectura del sistema debe ser de tres
capas distribuida en tres nodos. En el diagrama de despliegue de la Figura 3.22 se resalta la interaccin
de ciertos componentes dentro de algunos subsistemas y se incorporan algunos elementos de
configuracin.
Figura 3.22 Diagrama de despliegue del sistema
79
80
3.4.7 Diseo de la base de datos

Del modelo de clases obtenido en la parte anterior, se realiza un anlisis de las clases y entidades que
se identificaron junto con sus atributos y relaciones, armando as el modelo relacional. En la Figura
3.23 se muestra el modelo relacional del sistema. Las claves primarias son precedidas por las letras
PK.
Figura 3.23 Modelo de la base de datos del sistema
81
i) Dependencias funcionales y esquema normalizado

Sean a y b atributos de una misma tabla o relacin T. Se dice que b es funcionalmente dependiente de
a y se denota a -> b, si todo posible valor de a tiene asociado un nico valor de b, o lo que es lo
mismo, en todas las tuplas de T en las que el atributo a toma el mismo valor v1, el atributo b toma
tambin un mismo valor v2. Claramente a -> b no implica b -> a.
De este modo, por ejemplo, para la tabla tr003_componente se observa como nombre_comp ->
ubicacin pues conociendo el nombre del componente podemos conocer su ubicacin y
nombre_comp -> grupo_op, ya que en la definicin del problema el componente solo posee un
grupo responsable de su mantenimiento.
La normalizacin consiste pues en descomponer los esquemas relacionales (tablas) en otros
equivalentes (puede obtenerse el original a partir de los otros) de manera que se verifiquen unas
determinadas reglas de normalizacin. Evidentemente las reglas de normalizacin imponen una serie
de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Segn se avance
en el cumplimiento de reglas y restricciones se alcanzar una mayor forma normal.
ii) Primera forma normal

Una tabla est en Primera Forma Normal (1FN) slo si:
x
Todos los atributos son atmicos.
La tabla contiene una clave primaria
La tabla no contiene atributos nulos
La tabla no posee ciclos repetitivos.
Bsicamente la regla de la primera forma normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas [12]. El modelo relacional del sistema se encuentra en 1FN,
pues todas las tablas poseen elementos claves primarios, todos los atributos son atmicos y no se
producen columnas con valores repetidos.
82
iii) Segunda Forma Normal

Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de ninguna clave
dependen de forma completa de la clave principal. Es decir, que no existen dependencias parciales
[12].
En la base de datos se observa cmo para todas las tablas, los atributos dependen exclusivamente y
de forma completa de los valores de la clave principal. Por lo tanto, el esquema se encuentra en
segunda forma normal.
iv) Tercera Forma Normal

Una base de datos se encuentra en Tercera Forma Normal si est en Segunda Forma Normal y cada
atributo que no forma parte de ninguna clave, depende directamente y no transitivamente de la clave
primaria.
Todas las tablas se encuentran en tercera forma normal, pues no existen dependencias de
atributos que no son claves.
3.4.8 Diseo de la interfaz del usuario

Para todos los usuarios, al acceder al sistema a travs de la intranet de la empresa, se carga la misma
pantalla de acceso en la que se pide al usuario que ingrese su indicador y clave de red. La pantalla
inicial del sistema se muestra en la Figura 3.24.
Una vez dentro del sistema, la estructura de la interfaz sigue los estndares de presentacin de
PDVSA para las aplicaciones disponibles a travs de la intranet. En ella se distingue un men lateral en
el que se sealan las opciones disponibles para el usuario de acuerdo a su perfil, el rea de encabezado
en la que se indica el nombre de la aplicacin y la fecha, y el rea de trabajo en la que se cargan los
contenidos a mostrar (formularios, resultados de consultas a la base de datos, mensajes de error, entre
otros). La Figura 3.25 muestra la estructura general de las pantallas.
El flujo entre las pantallas del sistema se muestra en la Figura 3.26, en l se incluyen las
principales pantallas de los mdulos del sistema.
83
Figura 3.24 Pantalla de inicio del sistema
Encabezado
rea de trabajo
Men de usuario
Figura 3.25 Pantalla general de usuarios
84
Figura 3.26 Diagrama de flujo de pantallas
3.5 Fase de Implementacin y Pruebas

Esta fase comprende la implementacin de las tres capas de la arquitectura que fueron diseadas en la
parte anterior. Se construyen e integran los componentes de la capa de presentacin, los componentes
de la capa de lgica de negocios y los componentes de la capa de datos. Estos componentes son
probados individualmente durante su implementacin y, una vez integrados, se realiza un conjunto de
85
pruebas que permiten determinar si la aplicacin cumple con los requisitos funcionales y no
funcionales. El producto final que se obtiene es la primera versin del sistema probada y corregida.
3.5.1 Implementacin del sistema

El sistema es implementado en tres servidores (tal y como se tena previsto durante la fase de diseo).
La capa de presentacin es implementada en un servidor web, el cual slo debe ejecutar las funciones
de captura de datos por parte del usuario y generacin de pginas web ya que slo se puede comunicar
con el servidor de aplicaciones y con el cliente. Los componentes de la capa de lgica de negocios se
implementan en un servidor de aplicaciones que se encarga de la captura y procesamiento de los datos
del servidor de bases de datos, en el que se encuentra implementada la capa de datos del sistema. Los
servidores utilizados para la implementacin del sistema son servidores de desarrollo que tienen las
mismas configuraciones que los servidores de produccin, de modo que no haya que hacer muchas
configuraciones para ubicar el sistema en su ambiente final de operacin.
Se busca garantizar la mantenibilidad del sistema, para ello, se trata de separar al mximo el
cdigo escrito en PHP con el cdigo HTML, se le da particular importancia a la documentacin de los
componentes, y se hace nfasis en lograr un sistema altamente modular. Para la nomenclatura de las
funciones y las variables, as como para documentar los componentes, se sigue un conjunto de
lineamientos establecidos por la Gerencia de Desarrollo e Implementacin de Soluciones de PDVSA
AIT [16]. Entre los principales estndares seguidos para la nomenclatura se pueden mencionar:
x
Se utilizan letras maysculas para el inicio de cada palabra de un mtodo y se evita el uso
de guiones en la nomenclatura de mtodos.
Se utiliza el carcter de guin bajo (_) como separador de palabras para los elementos
de los arreglos.
Se utilizan letras maysculas para las variables globales.
Los comentarios siguen una estructura en la que se indica el autor del cdigo, la versin
del componente, la fecha de ltima modificacin, la descripcin de las funciones, de los
parmetros que reciben y de los valores retornados.
86
La nomenclatura de las tablas de la base de datos sigue el formato

tr_num_Nombre_Tabla donde la r denota que es una tabla regular, num indica el
nmero de la tabla y el nombre de la tabla es separado por caracteres de guin bajo (_).
i) Implementacin de la capa de presentacin

Durante el desarrollo de la primera versin del sistema se comienza ensamblando los componentes de
la capa de presentacin. La interfaz U/S comprende la codificacin e integracin de componentes del
lado del servidor web y componentes del lado del cliente:
x
El cdigo del lado del cliente, contiene los elementos visuales (HTML, controles de servidor
y texto esttico) y el cdigo que se debe ejecutar en el navegador del cliente, en la forma de
funciones JavaScript.
El cdigo del lado del servidor web, contiene la lgica de programacin de las pginas y es
implementado mediante segmentos de cdigo PHP embebidos dentro de las pginas HTML y
mediante funciones contenidas en scripts externos a las pginas.
Para la implementacin de esta capa se desarrollan cada una de las pginas web identificadas en el
diseo del sistema. El formato de las pginas (color y tamao del texto, tablas, imgenes, mens de
usuario y formularios) es tomado de la hoja de estilos CSS que utilizan las aplicaciones disponibles a
travs de la intranet de PDVSA.
Una de las pginas mas complejas en su desarrollo es la de ingreso de incidentes de falla. Los
requisitos asociados a los reportes de los analistas de guardia, hacen que esta pgina incorpore varios
aspectos dinmicos. Por ejemplo, para el ingreso del componente en que se produce la falla, el
requisito R12 establece que la seleccin de este debe ser dinmica, realizndose un filtro previo de
acuerdo al grupo operativo que reporta la falla y la ubicacin del componente. Si el componente o la
ubicacin son nuevos, o no aparecen en la lista, se permite que el usuario ingrese los datos
correspondientes activndose ciertos campos del formulario. Otros campos que se activan
dependiendo del estado del incidente, son los correspondientes a su solucin. Parte de la estructura
87
del formulario, junto con algunos de los estilos utilizados se muestran en la Figura 3.27. Algunas de
las pantallas de la primera versin del sistema pueden ser apreciadas en el Anexo B.
Figura 3.27 Formulario de ingreso de incidentes de falla
Se desarrolla un repositorio de funciones comunes utilizadas por todos los componentes de la capa
de presentacin. Entre las funcionalidades se pueden mencionar: mtodos que generan la estructura
de las pginas y del men dinmicamente de acuerdo al perfil del usuario, funciones de validacin,
funciones que llaman servicios web, entre otras.
ii) Implementacin de la capa de lgica de negocios

En la capa de lgica de negocios obtenida en esta iteracin se implementan las operaciones
encargadas de obtener la informacin de los incidentes de falla de la plataforma, calcular los
indicadores de disponibilidad y falla, manejar el inventario de componentes y procesar las alertas del
88
sistema Nagios. En esta capa se encuentran los componentes encargados de la insercin, edicin y
modificacin de los datos antes mencionados.
La implementacin de la lgica de negocios se hace mediante servicios web utilizando la librera
NuSOAP escrita en PHP. Esta librera se encarga de generar dinmicamente el cdigo WSDL, es decir, el
formato XML mediante el cual se describen los datos transferidos entre el servidor de aplicaciones y el
servidor web. Se desarrollan scripts para agrupar servicios que manipulen las mismas tablas en la base de
datos y el acceso a estos servicios desde el servidor web es implementado en scripts externos a las pginas,
de modo que para los componentes de la capa de presentacin, la llamada a los servicios web resulta
transparente.
Uno de los componentes ms complejos de la capa de lgica de negocios es el encargado de

procesar el log de Nagios. Diariamente se obtiene un archivo de texto que contiene el registro (log) de
las alertas detectadas y las notificaciones emitidas por el sistema durante la jornada. Se desarroll un
mtodo que procesa dicho archivo y captura el momento en que el sistema detecta la cada de un
componente, almacenando el evento en la base de datos (en la tabla tr005_nagios_alert) como una
cada que no ha finalizado, luego sigue procesando el archivo detectando nuevas cadas y en caso de
capturar una alerta que corresponda a la recuperacin de un componente, actualiza el registro
correspondiente en la base de datos. La transferencia del log entre los dos servidores (el servidor de
aplicaciones del SINCFA y el servidor donde se aloja Nagios) y la ejecucin del script que lo procesa
son configuradas para llevarse a cabo todos los das a una misma hora como tareas programadas del
sistema operativo.
iii) Implementacin de la capa de datos

La implementacin de la base de datos del sistema no difiere del diseo que se hizo en el apartado
anterior. La naturaleza de las transacciones y la sencillez de las relaciones hacen que no sea necesario
definir vistas ni restricciones complejas para la recuperacin de los datos. Para la administracin de la
base de datos se utiliza la herramienta pgAdmin, que facilita la ejecucin de las consultas antes de ser
implementadas en la lgica de negocios y hace posible al desarrollador visualizar y manipular
directamente el contenido de la base de datos.
89
3.5.2 Pruebas del sistema

Las pruebas del sistema buscan lograr detectar y corregir el mayor nmero de errores posibles y con
una cantidad razonable de tiempo y esfuerzo. En el caso del SINCFA, las pruebas permiten verificar
que la aplicacin funciona correctamente en condiciones tpicas de operacin y que se satisface los
requisitos funcionales y no funcionales determinados previamente. Para el desarrollo de las pruebas se
sigue la siguiente estrategia:
x
Se comienza probando individualmente cada uno de los componentes utilizando pruebas

caja negra. En este tipo de prueba se toman datos de entrada considerados sin tomar en
cuenta el funcionamiento interno del componente, utilizando valores ubicados justo en los
lmites permitidos y fuera de ellos, donde probablemente ocurran excepciones.
En caso de detectarse un resultado inesperado durante la ejecucin de las pruebas de caja

negra, se realizan pruebas de caja blanca, en las que se rastrea el comportamiento interno
del componente, verificando la ejecucin de cada una de las instrucciones involucradas en el
caso de prueba, esto con el fin de detectar y corregir la instruccin en la que se produce el
error.
La integracin de los componentes es probada utilizando pruebas funcionales orientadas

a caso de uso. En estas pruebas se verifica que los componentes que intervienen en cada
caso de uso funcionan correctamente, cumpliendo as con los requisitos funcionales.
Finalmente se hace una verificacin y validacin de los requisitos de los actores.

Esto con el fin de detectar el grado de cobertura de los requisitos en la primera versin del
sistema y determinar las metas a cumplir en el desarrollo de la segunda versin.
i) Pruebas de caja negra del sistema

El enfoque funcional o de caja negra consiste en estudiar la especificacin de las funciones, la entrada y
la salida con el fin de verificar que los componentes se comportan de la manera esperada. Aqu, la
prueba ideal del software consistira en probar todas las posibles entradas y salidas del programa. Sin
embargo, se puede generalizar un conjunto de valores que abarque el mayor nmero de casos de
90
entrada posibles y de ese modo cubrir varios escenarios a la vez. En el caso del SINCFA se realizan
pruebas de caja negra a los sesenta y ocho (68) componentes del sistema. La Tabla 3.5 muestra
algunas de las pruebas de caja negra realizadas.
Mdulo
Parmetros de
Salida
Resultado
Entrada
Acceso de usuarios
Clave incorrecta Mensaje indicando que el Satisfactorio, pero se
(UsuarioValido.php)
usuario no es vlido.
observa un mensaje de
advertencia
no
esperado y que luego es
corregido. (Ver Figura
3.28 y Figura 3.29).
(Ver
Mensaje indicando que se Satisfactorio
Ingreso de incidentes.
Campo
deben completar todos los Figura 3.30).
(IngresoIncidente.php) obligatorio
campos del formulario.
Faltante.
Reporte de incidentes Perodo
de Lista de los incidentes Satisfactorio
(Ver
por perodo de tiempo. tiempo vlido.
reportados entre las dos Figura 3.31).
(VistaReporteFecha.php)
fechas.
Tabla 3.5 Pruebas de Caja Negra
Figura 3.28 Prueba de ingreso de usuario
Figura 3.29 Mensaje obtenido al ingresar usuario invlido
Figura 3.30 Mensaje obtenido al tratar de ingresar un incidente con campos faltantes
91
92
Figura 3.31 Resultado obtenido al consultar incidentes por perodo de tiempo
ii) Pruebas de caja blanca

El enfoque estructural o de caja blanca consiste en centrarse en la estructura interna (implementacin)
del programa para elegir los casos de prueba. En este caso, la prueba ideal del software consistira en
probar todos los posibles caminos de ejecucin, a travs de las instrucciones del cdigo, que puedan
trazarse. Las pruebas de caja blanca son ms exhaustivas que las pruebas de caja negra, por lo que son
realizadas solo en aquellos casos de prueba en los que los resultados obtenidos difieren de los
resultados esperados. Esto con el fin de poder rastrear y corregir los errores. El dominio que se tiene
del conjunto de instrucciones asociadas a cada mdulo hace que no sea necesario revisar
exhaustivamente el cdigo ni recurrir a anlisis de complejidad ciclomtica para el diseo de las
pruebas.
Uno de los casos de prueba en los que resulta necesario verificar el funcionamiento interno del
componente fue para el mdulo de clculo de indicadores por grupo operativo. En la prueba realizada
se consultan los indicadores de los grupos operativos entre el 01-01-2008 y el 01-01-2009 y para
93
probar que el clculo de los indicadores resulta correcto se toma como prueba el grupo Z-Series (los
incidentes reportados por el grupo se muestran en la Figura 3.32).
Figura 3.32 Incidentes reportados por el Grupo Z-Series entre el 01-01-2008 y el 01-01-2009
De acuerdo a la frmula tomada para el clculo de los indicadores, se espera que el valor de TPS
sea de (15+22+170)/3 = 69 horas, el TPEF debera valer (268+4988)/2 = 2628 horas y el nmero
de incidentes reportados por el grupo debe ser 3. Sin embargo en la Figura 3.33 se observa que los
indicadores calculados para el grupo no son los esperados.
94
Figura 3.33 Clculo de indicadores para el grupo Z-Series
Luego de revisar el funcionamiento interno del algoritmo encargado de calcular los indicadores,
se observa que el error se produce porque el algoritmo recibe correctamente el parmetro de nmero
de incidentes, lo que ocasiona que se omita siempre el ltimo incidente de cada grupo en el clculo de
los indicadores. Se corrige el error y se obtiene el resultado de la Figura 3.34.
Figura 3.34 Resultado obtenido luego de corregir el error de los indicadores
Durante la ejecucin de pruebas al sistema se realizan pruebas de caja blanca a ocho (8) mdulos del
sistema de un total de sesenta y ocho (68) componentes desarrollados.
iii) Pruebas Funcionales

Para verificar que el sistema satisface los requisitos funcionales recolectados en la fase de ingeniera de
requisitos, se desarrolla un conjunto de pruebas en las que los componentes que intervienen en cada
caso de uso son probados de manera general, en condiciones que simulan las condiciones normales de
operacin del sistema. En estas pruebas tambin se revisa que los componentes se integran de manera
adecuada, cumpliendo con las especificaciones hechas en la fase de diseo. Las pruebas realizadas se
95
incluyen en un documento de pruebas que es entregado junto con la primera versin del sistema.
Dicho documento contiene un total de diecisiete (17) casos de prueba, varios de los cuales incluyen
algunos escenarios, se realizan un total de veintiocho (28) pruebas funcionales.
iv) Verificacin y validacin de los requisitos

En esta actividad, se determina que el sistema cumple con los requisitos establecidos en el anlisis y
que estos satisfacen las necesidades de los usuarios. La verificacin consiste en comprobar que el
sistema cumple con la especificacin de requisitos; parte de este proceso fue llevada a cabo durante la
ejecucin de las pruebas funcionales orientadas a caso de uso y se encontr que todos los casos de uso
incluidos en el anlisis fueron construidos en el sistema.
La validacin determina si el sistema satisface las necesidades de los usuarios. Para la entrega final
de la primera versin se hace una presentacin al cliente y a los usuarios principales, en la que se
ejecutan los procesos apoyados por el sistema y se comprueba que el comportamiento en condiciones
tpicas de operacin es el esperado, midindose el grado de aceptacin y de satisfaccin de las
necesidades de informacin de los usuarios finales. En estas pruebas el cliente sugiere correcciones
que se le deben hacer al sistema para que apoye de manera ms efectiva sus funciones. Estas
correcciones son tomadas en cuenta para el desarrollo de la segunda versin.
Vale la pena resaltar que durante todo el proceso de desarrollo, la participacin del cliente y los
usuarios fue activa y se realizaron correcciones al sistema en base a las observaciones que iban
surgiendo. Sin embargo, estas ltimas pruebas permitieron la validacin final de todos los requisitos.

La primera iteracin del mtodo Watch fue la ms compleja, ya que se empez capturando las ideas
difusas que tena el cliente acerca de lo que deseaba que hiciera el sistema, y en base a estas ideas se
fue construyendo un producto esperando satisfacer sus necesidades. La mayor complicacin surgi
debido a que en la medida que el cliente iba madurando sus ideas y participaba en el proceso de
desarrollo, sus expectativas respecto al sistema aumentaban, esto haca que sus requisitos cambiaran y
que hubiera que incorporar nuevos detalles al diseo sobre la marcha. Sin embargo, una vez hechas las
96
mejoras necesarias, los actores quedaron satisfechos con el producto obtenido y se establecieron las
bases para el desarrollo de una segunda versin.
Se observ que una de las principales ventajas de utilizar un diseo arquitectnico de tres capas
orientado a servicios fue la facilidad para separar las funciones de cada componente, lo que permiti
detectar y corregir errores rpidamente.
Captulo 4 Desarrollo de la segunda versin del sistema
97
Captulo 4
Desarrollo de la segunda versin del sistema
En el presente captulo se habla del desarrollo de la segunda versin del sistema SINCFA. Para esta
segunda versin se cuenta con un mayor conocimiento de los procesos de negocio y de las necesidades
de informacin de los usuarios. Este conocimiento, junto con un mayor dominio de las herramientas
utilizadas, permite mejorar los productos obtenidos en la primera versin y alcanzar resultados de
manera ms rpida. Se comienza revisando brevemente algunos de los aspectos del modelo de
negocios, se incorporan los nuevos requisitos y se desarrollan los casos de uso correspondientes, se
disean los nuevos componentes y se habla sobre la fase de implementacin y pruebas de la versin
final. El principal producto de esta fase es el sistema listo para su puesta en produccin.
4.1 Revisin del modelo de negocios

En esta iteracin los cambios que surgen en el dominio de la aplicacin son muy pocos, ya que el
alcance del sistema y los procesos de negocio siguen siendo bsicamente los mismos. Sin embargo, se
incorporan nuevas reglas, principalmente relacionadas con el manejo de servicios por parte del
sistema Nagios y con la automatizacin del proceso de obtencin de la minuta de incidentes (que
aparece especificado en la regla 18 del apartado 3.1.6 y que no fue tomado en cuenta para la primera
versin). La incorporacin de nuevas reglas hace que se incorporen algunos objetos al modelo de
negocios; no obstante, siguen interviniendo los mismos actores con los mismos objetivos.
98
4.1.1 Modelado de las reglas de negocio

Con un mejor conocimiento de los procesos de negocio, se incorporan nuevas reglas que no fueron
tomadas en cuenta durante el desarrollo de la primera versin o que surgieron en la medida que se
conoca mejor el dominio de la aplicacin. Las reglas incluidas son las siguientes:
23. Documento de lineamientos y controles de seguridad para las aplicaciones disponibles en la

intranet PDVSA.
24. El sistema Nagios tambin detecta el estado de servicios dentro de los Hosts. Para Nagios un
servicio es una propiedad de un Host que puede ser monitoreada a travs de la red y que tiene
cierto estado en un momento dado, por ejemplo, el espacio en disco o el uso de memoria en
un servidor. El estado de un servicio puede ser normal (internamente se maneja el trmino
OK), de advertencia (WARNING) o crtico (CRITICAL). El monitoreo de los servicios hace
posible que Nagios supervise el estado de aplicaciones cuyo desempeo resulta crtico para el
negocio. En este sentido, una aplicacin puede abarcar varios servicios dentro de varios Hosts
de la plataforma.
25. Para el monitoreo de los servicios la lgica es bsicamente la misma, el sistema enva seales
esperando respuesta por parte del servicio dentro del Host, al momento de detectar que el
estado de un servicio es crtico se emiten notificaciones a los grupos responsables y se
registran las notificaciones emitidas, del mismo modo se notifica y registra cuando el estado
del servicio vuelve a la normalidad.
26. Para que un incidente aparezca reportado en la minuta de una reunin, es necesario que el
analista enve su reporte a GDS antes de las 9:00 a.m., ya que a esa hora es que se pone a
disposicin la minuta a los grupos operativos, gerentes y dems interesados. de lo contrario el
reporte aparece registrado en la minuta de la prxima reunin.
27. Es posible calcular la disponibilidad de una aplicacin o un componente para un perodo de
tiempo dado. El porcentaje de disponibilidad viene dado por la razn entre el nmero de
horas que opera el componente sin fallas y el nmero total de horas del perodo consultado
99
Estas cuatro reglas fueron tomadas en cuenta durante la implementacin del sistema,
adicionalmente se toma en cuenta la regla 18, que tiene que ver con la estructura de la minuta de
incidentes diarios. Esta regla fue incluida en el modelado de reglas y objetos de negocio del captulo
anterior pero no fue incorporada al diseo ni modelada como un caso de uso.
4.1.2 Modelado de objetos de Negocio

Para el modelado de objetos de negocios en la segunda iteracin, se hace distincin entre dos tipos de
componentes: las aplicaciones y los equipos. Durante la primera iteracin se tomaba en cuenta un solo
tipo de notificaciones asociadas con componentes fsicos de la plataforma. De este modo, los trminos
Equipo y AlertaNagiosHost sustituyen a los trminos Componente y AlertaNagios de la
primera versin. Los objetos que se incorporan son los siguientes:
Reporte: Los analistas arman un reporte con los datos del incidente de falla. El reporte rene los
datos de la falla ocurrida y las acciones llevadas a cabo para solventarla. Esta informacin es
integrada en una minuta de incidentes diarios dependiendo de la hora y la fecha en que se haga el
reporte.
Aplicacin: Las aplicaciones crticas en la plataforma son un tipo especial de componentes que estn
asociadas a un conjunto de servicios monitoreados por la aplicacin Nagios.
Servicio: Tal y como se mencion anteriormente, un servicio es una propiedad de un Host que puede
ser monitoreada por Nagios a travs de la red y que tiene cierto estado en un momento dado.
AlertaNagiosService: Cuando Nagios detecta que un servicio se encuentra en estado crtico, se
registra internamente dicho evento. Cuando sistema detecta que el servicio se encuentra
funcionando normalmente se registra el fin de la alerta. Una alerta puede estar asociada con un
nico servicio.
El diagrama de objetos de la segunda versin del sistema se muestra en la Figura 4.1, en ella se
resaltan con un color ms oscuro las nuevas entidades incorporadas al modelo.
100
Figura 4.1 Diagrama de objetos de la segunda versin del SINCFA
4.2 Requisitos de la segunda versin

Para la segunda versin se incorporan nuevos requisitos, muchos de los cuales fueron surgiendo en la
medida en que se avanzaba en el desarrollo de la primera versin. En esta etapa, los requisitos se
concentran en incorporar las nuevas reglas de negocio y en incrementar los controles de seguridad en
el sistema. Los actores que intervienen en el proceso de ingeniera de requisitos siguen siendo los
mismos, sin embrago, se redefinen los perfiles de los usuarios de la aplicacin.
101
4.2.1 Redefinicin de los perfiles de usuario

Para la primera versin del SINCFA se identificaron cuatro niveles de acceso de los usuarios a las
funciones del sistema. Sin embargo, los perfiles definidos no estaban vinculados con ninguna unidad
especfica dentro de la organizacin. Para la segunda versin se asocia cada uno de los perfiles a un
grupo de usuarios dentro de PDVSA AIT SCC y se obtienen los siguientes tipos de usuario:
Usuario de Confiabilidad: La Coordinacin de Confiabilidad es la unidad responsable del sistema,

y sus miembros son los encargados de administrar el SINCFA. Entre sus privilegios se puede
mencionar: auditar el sistema cuando sea necesario, manejar el inventario de equipos y
aplicaciones de PDVSA AIT SCC, modificar los datos de los reportes de incidentes hechos por los
analistas de guardia y consultar todos los reportes generados por el sistema.
Usuario de GDS: Las funciones de los miembros de la Gerencia de Gestin del Servicio estn
relacionadas con la consulta y generacin de la minuta de incidentes diarios y la supervisin de
que los analistas completen los reportes pendientes por solucin, tambin pueden acceder a
ciertos reportes generados por el sistema.
Usuario de MAP: Son los usuarios que pertenecen a los grupos operativos solucionadores,
responsables de cada una de las especialidades de la plataforma AIT SCC. Sus privilegios se
concentran en la creacin de reportes de incidentes de falla y solo pueden modificar los reportes
que hayan quedado pendientes por solucin. Adems de eso, pueden consultar algunos reportes
generados por el sistema.
Usuario General: Este perfil se mantiene respecto a la primera versin, est representado por los
usuarios dentro de otras unidades de PDVSA AIT SCC y slo puede hacer ciertas consultas sobre
la base de datos de incidentes.
102
4.2.2 Definicin de requisitos segn actores

i) Requisitos del cliente
1. La jerarqua de roles del sistema debe estar estructurada en el Directorio Activo. Es
responsabilidad del administrador del sistema solicitar a la gerencia responsable de dicho
directorio la creacin de los grupos de usuarios correspondientes y las autorizaciones para
cada usuario.
2. Hacer uso de archivos de registros de eventos (Logs) para auditar el sistema y permitir
reconstruir en un momento dado la sesin de algn usuario.
3. Incorporar mdulo para la auditoria del sistema.
4. Bloquear la sesin del usuario despus de cierto tiempo de inactividad.
5. Minimizar a uno (1) el nmero de sesiones simultneas de un usuario en el sistema, evitando
as los accesos no autorizados.
6. La autenticacin de los usuarios en la aplicacin debe hacerse con la utilizacin de un canal
seguro, pudindose utilizar SSL para obtener HTTPS. Este tipo de canal debe ser utilizado
para las transferencias de datos que se consideren confidenciales o cuando se requiera el
llenado de formularios con datos sensibles. Luego de haberse realizado la autenticacin o
transferencia del dato sensible puede proceder a utilizar el protocolo http.
7. Evitar el ingreso a cualquier pgina de la aplicacin, a travs de la manipulacin del URL o
enlace ubicado en Favoritos, sin haber realizado el proceso de autenticacin.
8. Evitar arrojar mensajes de advertencia y errores de la aplicacin en el navegador de Internet.
En estos casos se debe presentar al usuario un mensaje general sobre lo ocurrido (disear una
pgina estndar para cualquier tipo de error; sin especificar el tipo de error).
9. El mdulo de control de inventario de equipos y aplicaciones de la plataforma AIT slo debe
ser manipulado por cierto tipo de usuarios con privilegios especiales dentro del sistema.
10. Incorporar un mdulo para obtener la minuta directamente del sistema, en base a los reportes
ingresados por los analistas.
11. Incorporar un mdulo para capturar las alertas emitidas por Nagios para las aplicaciones de la
plataforma.
103
ii) Requisitos de los usuarios
2. Se deben hacer ms explcitos los mensajes mostrados en la interfaz, permitiendo que el

usuario pueda ubicar fcilmente las funciones dentro del sistema.
3. Incorporar un mdulo para que los analistas cierren los reportes pendientes por solucin y
para hacer un seguimiento de estos reportes.
4. Se debe incorporar un mdulo que lleve control de las guardias de los analistas.
5. Al momento de consultar los incidentes reportados para un equipo o aplicacin, se debe
incorporar un indicador de disponibilidad respecto al perodo de tiempo consultado.
6. Se debe incorporar un mdulo para graficar los indicadores.
7. Distinguir entre los analistas que no hayan reportado novedad y aquellos que hayan estado
ausentes en la reunin de guardia.
8. Incorporar un mdulo de control de datos de los analistas de los Grupos Operativos
Solucionadores.
9. Incluir un mdulo de reportes que permita consultar las alertas emitidas por Nagios y filtrar
dichas alertas por perodo de tiempo, grupo operativo o por equipo o sistema. Los reportes
deben incorporar el clculo de los indicadores correspondientes y solamente sern manejados
por la Coordinacin de Confiabilidad.
10. Incorporar un mdulo de ayuda en lnea.
iii) Requisitos del desarrollador
1. La segunda versin debe incorporar controles que agilicen el llenado de la minuta por parte
de los analistas.
2. Se deben realizar mejoras a la interfaz y documentacin del sistema.
4.2.3 Clasificacin y negociacin de requisitos

Luego de analizar la cantidad de esfuerzo asociada con cada requisito se realizan negociaciones con el
cliente a fin de fijar prioridades a estos y enfocar el desarrollo de la segunda versin del sistema
104
solamente en aquellos ntimamente vinculados con la gestin de incidentes de falla. La clasificacin y

las prioridades de los requisitos se muestran en la Tabla 4.1.
N de
requsito
R1
R2
R3
R4
R5
R6
R7
R8
R9
Nombre del
requisito
Clasificacin
Prioridad
Tipo de
requisito
La jerarqua de roles del

sistema
debe
estar
estructurada en el Directorio
Activo.
Hacer uso de archivos de
registros de eventos (Logs)
para auditar el sistema
Incorporar mdulo para la
auditoria del sistema.
El sistema debe bloquear la
sesin del usuario despus de
cierto tiempo de inactividad.
Se debe minimizar a uno (1)
el nmero de sesiones
simultneas de un usuario en
el sistema
La autenticacin de los
usuarios en la aplicacin
debe hacerse con la
utilizacin de un canal
seguro, pudindose utilizar
SSL para obtener HTTPS.
Se debe evitar el ingreso a
cualquier pgina de la
aplicacin
sin
haberse
autenticado primero
Se deben presentar al
usuario mensajes generales
cuando ocurran errores o
excepciones en el sistema.
El mdulo de control de
inventario de equipos y
aplicaciones de la plataforma
AIT
slo
debe
ser
manipulado por cierto tipo
de usuarios
No Funcional
Restriccin de
seguridad
No Funcional
Aseguramiento de
la calidad
Funcional
No Funcional
Aseguramiento de
la calidad
Restriccin de
seguridad
No Funcional
Restriccin de
seguridad
No Funcional
Restriccin de
seguridad
No Funcional
Restriccin de
seguridad
No Funcional
Restriccin de
seguridad
No Funcional
Restriccin
N de
requsito
R10
R11
R12
R13
R14
R15
Nombre del
requisito
Incorporar un mdulo para
obtener
la
minuta
directamente del sistema
capturar las alertas emitidas
por
Nagios
para
las
aplicaciones
de
la
plataforma.
Se deben hacer ms
explcitos los mensajes
mostrados en la interfaz,
permitiendo que el usuario
pueda ubicar fcilmente las
funciones dentro del sistema
que los analistas cierren los
reportes pendientes por
solucin y para hacer un
seguimiento
de
estos
reportes
Incorporar un mdulo que
lleve control de las guardias
de los analistas
Los
reportes
deben
incorporar un indicador de
disponibilidad respecto al
perodo
de
tiempo
consultado
105
Funcional
Funcionalidad
Funcional
Funcionalidad
No Funcional
Uso y factores
humanos.
Funcional
Funcionalidad
Funcional
Descartado
en
negociacin
5
Funcionalidad
Descartado
en
negociacin
Descartado
en
negociacin
Funcionalidad
Descartado
en
negociacin
Funcionalidad
No Funcional
R16

graficar los indicadores.
Funcional
R17
Distinguir entre los analistas

que no hayan reportado
novedad y aquellos que
hayan estado ausentes en la
reunin.
Incorporar un mdulo de
control de datos de los
analistas.
Funcional
R18
Tipo de
requisito.
Funcional
Restriccin
Funcionalidad
N de
requsito
R19
R20
R21
R22
Nombre del
requisito
Funcional
3
Incluir un mdulo de
reportes
que
permita
consultar las alertas emitidas
por Nagios y filtrar dichas
alertas por grupo y por
equipo o aplicacin.
Incluir un mdulo de ayuda
Funcional
3
en lnea.
La segunda versin debe
No Funcional
2
incorporar controles que
agilicen el llenado de la
minuta por parte de los
analistas.
Se deben realizar mejoras a
No Funcional
2
la interfaz y documentacin
del sistema
Tabla 4.1 Clasificacin y Negociacin de requisitos
106
Tipo de
requisito.
Funcionalidad
Aseguramiento de
la calidad
Uso y factores
humanos
Aseguramiento de
la calidad
4.2.4 Elaboracin de casos de uso

Para la segunda versin se refina el modelo de casos de uso y se consideran los nuevos perfiles de
usuario. Los diagramas se muestran en las Figuras 4.2, 4.3, 4.4 y 4.5. Obsrvese como los casos de
uso agregados para la segunda versin son resaltados en color crema.
La descripcin textual de los nuevos casos de uso aparece en la Tabla 4.2. En ella se observa que
las principales mejoras al sistema ocurren en la incorporacin de nuevos reportes a partir del sistema
Nagios y en la definicin de servicios asociados a aplicaciones. Adicionalmente, se incorpora un caso
de uso para que los usuarios de GDS puedan consultar los reportes que estn pendientes por solucin
y de ese modo hacer seguimiento a los analistas. Un usuario de MAP slo puede consultar y modificar
los reportes que hayan sido creados por l. Se incorpora el caso de uso Auditar sistema y abarca la
consulta de los logs del sistema para reconstruir las sesiones de los usuarios.
Figura 4.2 Diagrama de casos de uso para usuario general
107
Figura 4.3 Diagrama de casos de uso para usuario MAP
108
Figura 4.4 Diagrama de casos de uso para usuario GDS
109
Figura 4.5 Diagrama de casos de uso para usuario de confiabilidad
110

Uso
de Uso
CU18
Consultar ayuda.
CU19
CU20
CU21
CU22
CU23
CU24
CU25
CU26
CU27
111
Descripcin
El usuario consulta el manual de ayuda en lnea.
Consultar incidentes El usuario introduce la fecha de la minuta que desea consultar y el

reportados en minuta. sistema carga una lista con los incidentes reportados en la reunin
de esa fecha.
Consultar incidentes El usuario consulta los incidentes que haya reportado con
pendientes
por anterioridad y hayan quedado pendientes por datos acerca de la
solucin y finalizacin.
solucin.
Cerrar
reporte El usuario agrega datos acerca de la finalizacin y solucin del
abierto.
incidente reportado.
Imprimir minuta.
El usuario de GDS genera la minuta de la reunin de incidentes
diarios automticamente desde el sistema.
Consultar analistas con El usuario consulta los analistas que tengan reportes pendientes por
reportes abiertos
solucin. El sistema genera una lista con los datos de los reportes y
de los analistas responsables.
Definir servicio
El usuario define un servicio asociado a una aplicacin particular y
monitoreada por el sistema Nagios.
Eliminar servicio
El usuario elimina los datos de un servicio.
Nagios por grupo
operativo
Nagios por equipo o
aplicacin.
Auditar sistema
El usuario consulta las alertas detectadas por el sistema Nagios para

los equipos y aplicaciones de un grupo operativo en particular.
El usuario consulta las alertas detectadas por el sistema Nagios para

un equipo o aplicacin en particular. En caso de una aplicacin se
muestran todas las alertas de servicios asociados.
CU28
El usuario consulta el archivo de registro de eventos para
reconstruir las sesiones de otros usuarios y las modificaciones
hechas por estos sobre la base de datos.
Tabla 4.2 Descripcin de los nuevos casos de uso incorporados a la versin 2 del SINCFA
4.2.5 Matriz Caso de Uso vs. Requisitos

La incorporacin de nuevos requisitos y la definicin de nuevos casos de uso hacen que para el
desarrollo de la segunda versin sea necesaria una nueva verificacin de los requisitos cubiertos. La
matriz de Casos de uso vs. Requisitos se muestra en la tabla 4.3. En ella aparecen solamente los
nuevos requisitos funcionales contra los nuevos casos de uso.
Caso de uso CU CU CU
Requisito
18 19 20
112
CU CU CU CU CU CU CU CU
21 22 23 24 25 26 27 28
R3
R10
R11
R13
R19
R20
Tabla 4.3 Matriz de Casos de Uso vs. Requisitos para la segunda versin
4.3 Diseo de la segunda versin

Los componentes diseados durante la primera iteracin del mtodo Watch sirven de base para la
extensin del sistema. La arquitectura de la versin anterior fue diseada de tal forma que facilita la
incorporacin de nuevos componentes sin necesidad de hacer muchos cambios a los ya existentes. De
modo que la mayora de los cambios que surgen sobre el diseo son debidos a los nuevos requisitos. El
enfoque y los estilos utilizados en el diseo de la arquitectura siguen siendo los mismos.
4.3.1 Metas de diseo

Los objetivos planteados para la fase de diseo del sistema siguen se conservan. Solo se incorpora una
meta al diseo de la nueva versin: El diseo incorporar mecanismos que mejoren los niveles de
seguridad del sistema ante fraudes computarizados y lo hagan robusto ante errores por parte del
usuario.
4.3.2 Identificacin de subsistemas

Se incorpora un nuevo subsistema encargado de la auditoria del SINCFA. Este subsistema abarca el
registro de los accesos de usuarios al sistema y de las modificaciones que estos hagan sobre las bases de
datos. Todos esos eventos son registrados en los archivos de registro de eventos (Logs) del SINCFA.
113
De este modo, es posible que el administrador de la aplicacin construya la sesin del usuario a partir
de una simple consulta al log correspondiente. El diagrama de la figura 4.6 muestra la divisin del
sistema en subsistemas.
Figura 4.6 Identificacin de subsistemas para la segunda versin del SINCFA
4.3.3 Diseo de componentes

Dentro de cada uno de los subsistemas que son identificados para la segunda versin del SINCFA se
incorporan nuevos componentes, siguiendo los mismos estilos que se definieron en el diseo de la
primera versin.
i) Subsistema de control de usuarios

A pesar de que ninguno de los casos de uso definidos en la parte anterior est directamente
relacionado con el control de acceso de los usuarios, algunos de los requisitos no funcionales
recolectados sugieren la incorporacin de modificaciones sobre ese subsistema. Tal es el caso de los
requisitos R4, R5, R6 y R7 que tienen que ver con la seguridad del sistema. Estos requisitos motivan
la incorporacin de nuevos elementos al diseo y la modificacin de otros componentes. La Figura
4.7 muestra los componentes que fueron incorporados al subsistema de control de usuarios y aquellos
que fueron modificados en el desarrollo de la segunda versin.
114
ii) Subsistema de gestin de incidentes y soluciones

En este subsistema se incorporan componentes para la generacin de la minuta y el cierre de reportes
abiertos, tal y como est especificado en los casos de uso CU19, CU21, CU22 y CU23. El diagrama
de la Figura 4.8 muestra los componentes diseados y modificados en el subsistema.
iii) Subsistema de gestin de reportes de monitoreo

Los casos de uso que se incorporan en este subsistema son CU26 y CU27. Tambin se hacen
modificaciones considerables al componente que procesa el log de Nagios para que incluya las
aplicaciones. El diagrama de la Figura 4.9 muestra los componentes que se modificaron y los que se
disean para este subsistema.
iv) Subsistema de inventario de aplicaciones AIT

Las modificaciones de este subsistema estn relacionadas con los casos de uso CU24 y CU25, es decir,
con la definicin de servicios por parte de los usuarios. El diagrama de la Figura 4.10 muestra los
componentes diseados y modificados en el subsistema.
v) Subsistema de auditoria del SINCFA

El caso de uso CU28 hace que sea agregado el subsistema de auditoria para revisar las transacciones
hechas por los usuarios del sistema. La estructura del subsistema se muestra en la Figura 4.11.
Vale la pena resaltar que el caso de uso CU18 no fue especificado como un subsistema por su
sencillez, ya que el manual de ayuda del sistema consiste en un documento cargado directamente en
lnea cuando el usuario lo desea.
Figura 4.7 Componentes agregados y modificados en el subsistema de control de usuarios
115
116
Figura 4.8 Componentes agregados y modificados en el subsistema de gestin de incidentes y

soluciones
Figura 4.9 Componentes agregados y modificados en el subsistema de gestin de reportes de

monitoreo
117
118
Figura 4.10 Componentes agregados y modificados en el subsistema de inventario de componentes

AIT
119
Figura 4.11 Componentes del subsistema de auditoria del SINCFA
4.3.4 Diagrama de clases del sistema

En el diagrama de clases desarrollado para la segunda versin se observa que aparecen nuevas clases,
de las cuales la mayora no incorpora atributos nuevos, convirtindose en especializaciones de las
clases base. El diagrama de la Figura 4.12 muestra el nuevo diagrama de clases, se observa que las
clases nuevas son resaltadas con color azul.
120
Figura 4.12 Diagrama de clases para la segunda versin del sistema
4.3.5 Diagrama de despliegue del sistema

La distribucin del sistema sigue siendo bsicamente la misma, se incorporan los componentes
asociados con los nuevos subsistemas y dentro de cada uno de los paquetes presentados se incluyen los
componentes que ya fueron diseados. Las modificaciones a nivel de despliegue son muy pocas, pues
la estructura del sistema sigue no cambia de manera significativa. El diagrama de despliegue de la
Figura 4.13 muestra la distribucin de la segunda versin del sistema en nodos. Los cambios
agregados son resaltados en gris.
Figura 4.13 Diagrama de despliegue para la segunda versin del sistema
121
122
4.3.6 Diseo de la base de datos

Luego de refinar el modelo de clases del sistema se obtiene el modelo conceptual de la base de datos
del SINCFA. A pesar de que tericamente el modelo orientado a objetos deriva en modelo relacional
con las mismas entidades, muchas veces es necesario hacer refinamientos al momento de la
implementacin para optimizar el espacio utilizado [12]. Luego de estos refinamientos se observa que
el nuevo modelo incorpora solamente dos tablas nuevas, una de las cuales corresponde a los datos de
los usuarios conectados al sistema en conformidad con el requisito R5 y la otra comprende los
servicios asociados a las aplicaciones crticas. El esquema conceptual de la base de datos se muestra en
la figura 4.14, en l se resaltan las nuevas tablas en color azul. Al igual que en la primera versin el
esquema se encuentra en Tercera Forma Normal (3FN).
Figura 4.14 Modelo de la base de datos del sistema
123
4.3.7 Diseo de la interfaz del sistema

Los nuevos componentes especificados en el diseo de la capa de presentacin hacen necesario
incorporar pantallas para las nuevas funcionalidades del sistema. Al redefinir el flujo de pantallas se
mantiene el formato y los estilos utilizados en la interfaz de la primera versin, hacindose ligeras
modificaciones principalmente en los mensajes mostrados. En la figura 4.15 se muestra la nueva
pantalla de inicio y se observa como se han hecho mejoras estticas de acuerdo a recomendaciones del
cliente. La Figura 4.16 muestra la nueva estructura general de las pantallas del sistema, como se
puede apreciar, no se agregan muchos cambios, pero resalta la incorporacin de un mensaje de
bienvenida personalizado y de nuevas opciones en el men. El nuevo diagrama de flujo de pantallas se
muestra en la Figura 4.17, en l solamente aparecen las nuevas pantallas agregadas al diseo.
Figura 4.15 Pantalla de inicio del sistema
Figura 4.16 Estructura general de las pantallas del sistema
Figura 4.17 Diagrama de flujo de pantallas
124
125
4.4 Fase de implementacin y pruebas

El dominio que se tiene sobre las herramientas utilizadas reduce considerablemente la cantidad de
tiempo para implementar los nuevos componentes. Adems de codificar los nuevos elementos
diseados, los esfuerzos se concentran en refinar el cdigo de todos los componentes, eliminando
segmentos redundantes y mejorando la documentacin. La fase de pruebas es ms exhaustiva, pues en
esta iteracin se busca corregir todos los detalles y as entregar al cliente el sistema listo para su puesta
en operacin.
4.4.1 Implementacin de componentes

Las modificaciones hechas abarcan la incorporacin de nuevos componentes y la modificacin de
algunos de los mdulos de la primera versin. De los componentes agregados al sistema resalta un
conjunto de controles para agilizar las operaciones de los usuarios. Entre estos controles se incorpora
un botn de calendario para el ingreso de fechas dentro de los formularios3 (Figura 4.18). Otras
modificaciones sobre componentes de la primera versin que se pueden mencionar son: filtros de
bsqueda para el mdulo de inventario AIT (Figura 4.19), cambios en la pantalla principal del mdulo
de modificacin de incidentes para seleccionar el incidente lista (Figura 4.20), ajustes en el mdulo de
ingreso de incidentes para asignar la fecha de minuta automticamente en conformidad con la regla 26
del modelo de negocios (Figura 4.21), mejoras de los mensajes mostrados al usuario (Figura 4.22),
entre otros. Algunas de las pantallas de la segunda versin del sistema pueden ser apreciadas en el
Anexo 3.
Figura 4.18 Componente de calendario en JavaScript

3
El componente es reutilizado a partir de una versin disponible en la web [26]
Figura 4.19 Pantalla de modificacin de componentes del mdulo de inventario AIT
Figura 4.20 Pantalla de modificacin de incidentes
126
Figura 4.21 Asignacin de fecha de minuta directamente por el sistema
Figura 4.22 Mensaje de aviso al usuario
127
128
4.4.2 Fase de pruebas del sistema

Se utiliza la misma estrategia de pruebas que la establecida para el desarrollo de la primera versin: Se
realizan pruebas de caja negra sobre los componentes nuevos y sobre los modificados, en caso de
detectarse un comportamiento inesperado se hacen pruebas de caja blanca y para verificar la
integracin, exactitud y consistencia se siguen realizando pruebas de integracin funcionales
orientadas a caso de uso.
i) Pruebas de caja negra del sistema

Durante el desarrollo de la segunda versin solamente se prueban los componentes agregados y
aquellos cuya estructura cambi considerablemente. Se realizan un total de cincuenta y dos (52)
pruebas de caja negra de las cuales treinta y cinco (35) corresponden a los componentes nuevos y
diecisiete (17) a los componentes modificados. Algunos ejemplos de las pruebas realizadas se
muestran en la Tabla 4.4.
Mdulo
Parmetros de
Salida
Resultado
Entrada
Acceso de usuarios Usuario
ya Mensaje indicando que la Satisfactorio
(ValidarSesion.php).
conectado.
sesin no se puede crear.
(Ver Figura 4.23).
Consulta de reportes
abiertos
(ListarReportesAb.php)
Reporte de incidentes en
minutas y nagios
(ReporteMonitoreo.php)
Analista
con Lista de los reportes abiertos Satisfactorio
reportes Abiertos para el analista.
(Ver Figura 4.24).
Perodo
de Lista de los incidentes Satisfactorio
tiempo vlido.
reportados y las alertas (Ver Figura 4.25).
detectadas entre las dos
fechas.
Tabla 4.4 Pruebas de caja negra del sistema
Figura 4.23 Prueba de acceso de usuario ya conectado
Figura 4.24 Prueba de cierre de reporte abierto
129
130
Figura 4.25 Prueba de consulta de reporte conjunto
ii) Pruebas de caja blanca del sistema

Para la segunda versin es necesaria la realizacin de once (11) pruebas de caja blanca para detectar los
resultados inesperados de las pruebas de caja negra realizadas. Por ejemplo, uno de los componentes
probados (Validar.js) se encarga de la validacin de caracteres en los formularios y valida la longitud
de los campos abiertos para que no excedan el tamao definido en la base de datos. En la prueba
realizada al mdulo de ingreso de incidentes se detectan errores en el componente, pues a pesar de
que genera un mensaje indicando que el usuario se ha excedido de la longitud de caracteres permitida
(Ver Figura 4.26) se permite el ingreso del incidente, generando un error al momento de ingresar en
la base de datos. El mensaje indicando el error se muestra en la Figura 4.27.
Luego de revisar el componente se determina que la secuencia de instrucciones no retorna el
resultado de la validacin al formulario, lo que hace que el usuario pueda saltar el mensaje de
advertencia. Luego de corregir el error no se permite el ingreso de los datos cuando excedan la
longitud permitida.
Figura 4.26 Prueba de longitud de campos en ingreso de incidente
Figura 4.27 Mensaje obtenido al tratar de ingresar el incidente
131
132
iii) Pruebas Funcionales

Parte de la entrega final del sistema comprende un documento en el que se muestran los resultados de
todas las pruebas funcionales realizadas. Las pruebas estn orientadas a cada uno de los casos de uso,
debido a que ocurren cambios en varios componentes de la primera versin y se desea probar la
integracin de los componentes. Se realiza un total de cuarenta y nueve (49) pruebas sobre los
veintiocho (28) casos de uso.
4.5 Entrega final del sistema

Para que el SINCFA entre en operacin es necesario que todas las gerencias encargadas de validar la
calidad, mantenibilidad y seguridad de los sistemas de la corporacin realicen un conjunto de pruebas
para determinar que se ha cumplido con sus lineamientos. Los trmites relacionados con estas pruebas
son principalmente administrativos y el tiempo requerido para su realizacin supera el tiempo
estimado para el proyecto, por lo que la entrega final del sistema comprende la fase previa a su puesta
en produccin. Sin embargo, todas las restricciones y controles establecidos fueron cumplidos
durante las fases del desarrollo y las condiciones del ambiente en el que fue implementado el sistema
simulan completamente a las del ambiente de operacin definitivo, lo que hace que la puesta en
produccin del sistema no presente mayores complicaciones.
La documentacin entregada al cliente junto con el sistema comprende: manuales de usuario para
los perfiles definidos, manual de mantenimiento para el administrador del sistema, diccionario de
datos, diagrama de despliegue y documento de pruebas realizadas. Adems, se hizo una presentacin
orientada a los usuarios en la que se mostraron las funcionalidades del sistema y se dio un
adiestramiento a las personas responsables de su mantenimiento.
Durante la entrega final del sistema se verifica que todos los requisitos de los actores son
satisfechos. Sin embargo, surgen observaciones y recomendaciones acerca de aspectos que se pueden
incorporar para mejorar las funcionalidades del sistema. Estas sugerencias hacen posible pensar en el
desarrollo de una tercera versin ms adelante.
133

El desarrollo de la segunda versin no requiri de una dedicacin considerable de tiempo ni de
recursos, pues la mayor ventaja del enfoque utilizado para el diseo de la primera versin fue la
facilidad para incorporar nuevos componentes sin hacer muchas modificaciones a los ya existentes. En
muy pocos casos fue necesario hacer ajustes sobre los componentes para lograr la compatibilidad con
los nuevos elementos del sistema. Adicionalmente, el probar de forma exhaustiva la primera versin
como si se tratara de la entrega final del sistema permiti concentrar los esfuerzos de prueba de la
segunda versin solamente sobre los nuevos componentes.
Una de las mayores dificultades enfrentadas durante la segunda iteracin del mtodo Watch fue la
negociacin de los requisitos con el cliente, algunos requisitos fueron descartados. Esto debido a que
era necesario hacer un balance entre las necesidades de los actores y la cantidad de recursos
(principalmente tiempo) disponibles. Tambin hubo que considerar que muchos de los nuevos
requisitos surgieron de procesos que se escapaban del dominio de la aplicacin, tal fue el caso del
requisito R18 en el que se estableca la necesidad de un mdulo para llevar el registro de los datos de
los analistas de guardia. Este requisito no fue tomado en cuenta por escaparse del alcance definido
para el sistema. Sin embargo, la participacin activa del cliente durante todo el proceso de desarrollo
fue provechosa, pues permiti refinar constantemente los productos obtenidos hasta alcanzar
resultados plenamente satisfactorios en las reas impactadas.
Captulo 5 Conclusiones y Recomendaciones
134
Captulo 5
Conclusiones y recomendaciones
5.1 Conclusiones
Luego de revisar y verificar los objetivos planteados al comienzo del proyecto, se llega a la conclusin
de que todos esos objetivos fueron alcanzados con xito. Sin embargo, gran parte de ese logro vino
determinado por la metodologa utilizada. El desarrollo de software es un proceso complejo que
requiere la aplicacin de metodologas bien estructuradas para obtener productos de alta calidad a un
costo mnimo. Las metodologas imponen un proceso disciplinado sobre el desarrollo de software con
el propsito de hacerlo ms predecible y eficiente. En el caso del Sistema de Gestin de Incidentes de
Falla, la aplicacin del mtodo Watch fue determinante para poder cumplir con los objetivos
planteados. Este mtodo permiti la aplicacin estructurada de un conjunto de actividades en las que
fue posible para el cliente conocer en todo momento el grado de avance del proyecto y participar de
manera activa sobre el proceso de desarrollo, colaborando en el refinamiento de los productos
intermedios que se iban obteniendo en cada fase.
Una de las mayores ventajas del mtodo Watch es su flexibilidad, pues a pesar de que su modelo
de procesos establece un conjunto de actividades y productos a obtener, en muchos casos se pueden
hacer adaptaciones al contexto de la aplicacin particular, permitiendo al equipo de desarrollo escoger
el nivel de detalle a alcanzar en el diseo. Para el caso del sistema desarrollado, se consider un nivel
de detalle adecuado a su naturaleza y complejidad, buscando agilizar las fases del proceso de
desarrollo. De este modo, todos los productos obtenidos en las fases y descritos en este documento
resultaban necesarios para expresar algn aspecto del sistema.
De todas las fases del mtodo, la ingeniera de requisitos es una de las ms complejas debido a las
variaciones en los requisitos del cliente. Para lidiar con los requisitos cambiantes, la estrategia seguida
consistente en refinar iterativamente los productos de cada fase y generar versiones funcionales
135
sucesivas del sistema fue satisfactoria y permiti realizar correcciones en conjunto con el cliente a
intervalos frecuentes de tiempo, redirigiendo el curso del proyecto en alineacin con sus necesidades.
El impacto que puede tener la implementacin de un Sistema de Informacin en una organizacin
viene dado por la capacidad del sistema para alinearse con el modo de trabajo dentro de sta y slo
sugerir aquellos cambios que sean necesarios para mejorar su desempeo. El apoyo de todos los
niveles dentro de la organizacin resulta vital para el xito de cualquier proyecto de este tipo, pues de
lo contrario el efecto del sistema no ser beneficioso sino perjudicial. En el presente proyecto se logr
integrar procesos involucrados con diferentes unidades dentro de la Gerencia MAP, organizando su
flujo de actividades sin alterar significativamente su modo de trabajo.
La informacin generada por los procesos de mantenimiento resulta vital para optimizar el
desempeo de los equipos y alargar su vida til, pues permite orientar las prcticas no solo a
garantizar una disponibilidad sobre la marcha, sino a planificar y controlar las actividades de
mantenimiento, buscando disminuir a futuro la ocurrencia de errores y cadas de servicios. En base a
ello, el sistema desarrollado proporciona a la Gerencia MAP una herramienta valiosa para tener un
conocimiento global del desempeo de los activos bajo su responsabilidad y tomar decisiones para
optimizar su gestin.
5.2 Aportes a la empresa

El Sistema de Gestin de Incidentes de Falla (SINCFA) permite automatizar un proceso manual
que deja informacin de fallas dispersa, inconcisa y difusa, y que no se puede aprovechar al mximo.
En este sentido se pueden mencionar algunos de sus beneficios puntuales para la gestin de la
Gerencia MAP:
Incorpora un repositorio histrico de fallas detallado por equipos y sistemas. Esta informacin
antes del desarrollo del sistema era manejada de forma difusa, dispersa y muchas veces
incompleta.
Facilita la obtencin de estadsticas de confiabilidad y disponibilidad de la plataforma,

calculados con una mayor precisin que en el proceso manual, pues se cuenta con un
136
repositorio bien estructurado de datos que puede ser incluso utilizado por la Coordinacin de
Confiabilidad para simular el comportamiento de la plataforma.
Hace posible realizar proyecciones y planes de desincorporacin o sustitucin de equipos por

cumplimiento del ciclo de vida til o por fallas recurrentes.
Apoya el proceso de programacin de los planes de mantenimiento de los equipos y sistemas

de la plataforma, mediante las estadsticas de fallas.
Permite la visualizacin de los incidentes y estadsticas de falla en la plataforma, no slo desde

la perspectiva de los grupos operativos, sino tambin desde el punto de vista de los equipos y
sistemas que la integran. Antes de la implementacin del sistema, la forma como se manejaba
el repositorio de incidentes dificultaba la obtencin de una perspectiva centrada en
componentes.
Integra la informacin manejada por el Centro Integral de Monitoreo con los datos
reportados por los Analistas de los Grupos Operativos Solucionadores.
Proporciona las bases para tener un inventario bsico de las aplicaciones y equipos que
integran la plataforma.
Proporciona una base de conocimiento referente a la obtencin de histricos de causas de

fallas y resolucin de problemas por cada equipo o sistema.
Hace posible la obtencin de informacin oportuna y til para la toma de decisiones, pues
est disponible para todos los usuarios involucrados a travs de la intranet de la empresa.
5.3 Aportes a la universidad

Proyectos como el desarrollado permiten crear vnculos estratgicos entre la Universidad de Los
Andes, particularmente, la Escuela de Ingeniera de Sistemas (EISULA) y la industria. Brindando
prestigio a la institucin como formadora de profesionales de alto nivel y permitiendo a la comunidad
estudiantil mejorar su formacin profesional mediante primeros contactos con el campo laboral.
5.4 Aportes al tesista
137
La experiencia adquirida mediante el presente proyecto brinda al tesista una primera idea del trabajo
llevado a cabo dentro de una gran organizacin como lo es PDVSA, permitindole familiarizarse con
sus procesos, lineamientos y con las herramientas que son manejadas en la industria, brindndole a su
vez una idea de la manera como se aplican los conceptos aprendidos durante la carrera a la resolucin
de problemas con la presin, exigencias y restricciones del mundo real. El trabajo desarrollado viene
aportando al tesista una experiencia integral que debe permitir su crecimiento profesional,
capacitndolo para abordar los problemas complejos que se le presenten ms adelante.
5.5 Recomendaciones
En base a las conclusiones y los resultados obtenidos, es conveniente resaltar algunas recomendaciones
que pudieran extender los resultados del proyecto, o que podran ser consideradas por los futuros
trabajos que se realicen en el rea. En este sentido se recomienda:
x
Integrar el Sistema de Gestin de Incidentes de Falla con otros sistemas utilizados por la
Gerencia GDS y la Gerencia MAP: El SINCFA aborda el problema de las fallas en la
plataforma desde el punto de vista de los reportes realizados por los analistas. Una extensin
que se pudiera incorporar al sistema es la integracin con el subproceso de mantenimiento
visto desde la perspectiva del usuario que tiene el problema. La Gerencia de Gestin de
Servicio se encarga de llevar control sobre las solicitudes de los usuarios dentro de PDVSA y
actualmente maneja varios sistemas para el apoyo de sus procesos. Estos sistemas han sido
desarrollados dentro de la organizacin y generan rdenes de mantenimiento para la mayora
de las solicitudes hechas por los usuarios. Una integracin del SINCFA con esos sistemas
impactara positivamente la gestin de ambas gerencias, pues permitira integrar la
informacin manejada por ambas unidades, incorporando aspectos para medir y mejorar la
calidad y continuidad de los servicios de la plataforma.
Incorporar mecanismos que creen los reportes de falla en el sistema directamente de las
alertas detectadas por Nagios: Se pudieran disear procedimientos para que las alertas
detectadas por Nagios creen directamente reportes de incidentes abiertos en el sistema y sus
datos quedaran pendientes por ser completados por parte del analista responsable. Esto
138
permitira que la integracin entre la informacin reunida en los reportes de los analistas de
guardia y la manejada por el sistema Nagios pueda ser aprovechada en una razn aun mayor.
Sin embargo, para lograr este objetivo es necesario terminar de adaptar el sistema Nagios a la
plataforma, haciendo que las alertas que genere sean ms precisas y confiables.
x
Incorporar mdulos al sistema para supervisar el desempeo de los analistas dentro de las
diferentes especialidades de la Gerencia MA: Una primera idea de los mecanismos requeridos
fue incorporada en la fase de ingeniera de requisitos de la segunda versin, los requisitos
fueron descartados por salirse de la delimitacin del problema. El control sobre las guardias
de los analistas y sobre su asistencia a las reuniones de incidentes permitira medir la
efectividad de los grupos y generar indicadores de gestin, tanto para cada uno de ellos, como
para toda la gerencia MAP. Adems hara posible disear estrategias para medir la
confiabilidad del factor humano.
Divulgar la importancia y utilidad del sistema entre las diferentes unidades que se pueden
beneficiar de l: La Coordinacin de Confiabilidad de la Plataforma fue la unidad principal
dentro de MAP en la que se desarroll el proyecto. Muchas de las funcionalidades del
SINCFA buscan apoyar y mejorar considerablemente su gestin, permitiendo la integracin
de sus actividades con las de las otras coordinaciones y el intercambio de informacin entre
ellas. Sin embargo, una de las mayores dificultades que podran enfrentar durante la
transicin del sistema sera lograr que los analistas se sientan identificados con l lo
suficientemente como para integrarlo completamente a sus actividades, esto debido a que
muchos de los beneficios que aportar el sistema sern apreciables a largo plazo, cuando se
cuente con un historial de fallas considerable. Es entonces responsabilidad de la Coordinacin
de Confiabilidad resaltar los beneficios que incorporar el sistema, de modo que se cuente
con el apoyo y colaboracin de las otras unidades.
Incorporar un catlogo de modos de fallas al sistema: La naturaleza de los equipos y sistemas

que integran la plataforma repercute sobre las diferentes formas en las que pueden ocurrir las
fallas. Muchas veces un componente o grupo de componentes presenta un conjunto reducido
de formas en las que pueden fallar, o puede ocurrir tambin que varias de las fallas tengan un
mismo diagnstico o una misma accin a ejecutar. La definicin de categoras para los modos
139
de falla hara que, al momento de reportar un incidente, el analista escoja la novedad, el

diagnstico y la accin ejecutada a partir de una lista. Esto agilizara el llenado de los reportes,
adems de optimizar el uso de la base de datos y eliminar la existencia de datos ambiguos,
redundantes y confusos que se presentan con mucha frecuencia cuando se manejan campos de
texto abiertos. Sin embargo, la categorizacin de los modos de falla de la plataforma implica
un estudio detallado de las caractersticas de los equipos que la integran, que se debe lograr en
conjunto con cada uno de los grupos responsables y debe buscar mantenerse vigente ante
cambios que se incorporen en la plataforma.
x
Estudiar la factibilidad de modificaciones al mtodo Watch para hacerlo ms ligero: A pesar de

que los resultados alcanzados no hubieran sido los mismos sin la aplicacin del mtodo,
pudieran realizarse modificaciones a este para hacer que sus resultados se enfoquen ms en la
obtencin del producto final que en la documentacin del mismo, de modo que para
complementar esta ltima, se puede hacer la participacin del cliente en el proceso de
desarrollo ms activa. Estas modificaciones haran del Watch un mtodo ms adaptable a
cambios en los requisitos del cliente que predictivo en cuanto al tiempo y recursos a utilizar
para cumplir dichos requisitos, ajustando sus actividades a la naturaleza humana de los actores
involucrados y concentrando dichas actividades en la obtencin del producto ms que en el
proceso necesario para obtenerlo.
Referencias Bibliogrficas
140
[1]
Sitio Web de PDVSA, http://www.pdvsa.com
[2]
Intranet de PDVSA, http://intranet.pdvsa.com
[3]
Nachias, J. (1995). Fiabilidad. ISDEFE.
[4]
Perez, C. y Moubray, J. (2003). Mantenimiento centrado en confiabilidad: Aplicacin e

impacto. Actas del Primer Congreso Mexicano de Confiabilidad y Mantenimiento, Len,
Mxico.
Montilva, J. (2004). Desarrollo de aplicaciones empresariales: El mtodo Watch. Universidad
de Los Andes, Mrida, Venezuela.
Object Management Group UML Resource Page, http://www.uml.org/
Schmal, R. y Cisternas, E. (2000). Sistemas de Informacin: Una metodologa para su
estructuracin. Actas de la XXVI Conferencia Latinoamericana de Informtica, Mxico.
Instituto Tecnolgico y de Estudios Superiores de Monterrey.
Muoz, A. (2003). Sistemas de informacin en las empresas,
http://www.hipertext.net/web/pag251.htm.
Barrios, J (2000), Sistemas de Informacin, Universidad de Los Andes, Mrida, Venezuela.
Mosquera, G. (2000). Estimacin de parmetros de confiabilidad y mantenibilidad de sistemas
industriales. Centro de altos estudios gerenciales ISID.
Barringer, P. (1996). An overview of reliability engineering principles. Penn Well
Conferences, Houston, TX.
Elmasri, R. y Navathe S. (2002). Fundamentos de bases de datos. Tercera Edicin. Pearson
Educacin, Madrid.
Prez, O. (2005). Bases de datos. Universitat Oberta de Catalunya,
http://republicajoven.org.ve/archivos/software_libre/UOC/Basededatos.pdf
Nickul D. (2007). Service Oriented Architecture (SOA) and Specialized Messaging Patterns.
Adobe Systems Incorporated,
http://www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture.pdf
Arquitectura Orientada a Servicios (SOA) Wikipedia, la enciclopedia libre,
http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
Modelo de referencia tcnico: Lineamientos para la construccin de aplicaciones (2008).
PDVSA, Gerencia de Desarrollo e Implementacin de Soluciones.
Simple Acces Object Protocol (SOAP) DesarrolloWeb,
http://www.desarrolloweb.com/articulos/1557.php
Comenzando a utilizar NuSOAP DesarrolloWeb,
http://www.desarrolloweb.com/articulos/1884.php
Object Managing Group. Introduction to UML, http://www.omg.org/UML/
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
141
[20] Lenguaje Unificado de Modelado (UML) Wikipedia, la enciclopedia libre,

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
[21] PHP - Wikipedia, la enciclopedia libre, http://es.wikipedia.org/wiki/.php
[22] Montilva, J. y Barrios, J (2004). BMM: A Business Modelling Method for Information Systems
Development. CLEI Electronic Journal, Vol 7, N 2, Paper 3
[23] Porter, M.E.: Competitive Advantage. The Free Press. New York (1985)
[24] Cadena de Valor Wikipedia, la enciclopedia libre,
http://es.wikipedia.org/wiki/Cadena_de_valor
[25] Barrios, J. (2007). Diseo de Software: Programas y Componentes. Apuntes de ingeniera del
software
[26] Garret, A. (2006). Simple calendar Widget,
http://www.garrett.nildram.co.uk/calendar/scw.htm
Anexo A Planificacin del proyecto
Anexo A
Planificacin del proyecto
Figura A.1 Planificacin inicial del proyecto
142
Anexo A Planificacin del proyecto
Figura A.2 Revisin de la planificacin del proyecto
143
Anexo B interfaces Usuario/Sistema Versin 1
Anexo B
Interfaces Usuario/Sistema Versin 1
Figura B.1 Pantalla de ingreso de incidentes
144
Figura B.2 Pantalla de Verificacin de ingreso del incidente
Figura B.3 Consulta de incidentes reportados por perodo de tiempo
145
Figura B.4 Reporte de incidentes por perodo de tiempo
Figura B.5 Reporte exportado a una hoja de clculo
146
Figura B.6 Clculo de indicadores operativos de la plataforma
Figura B.7 Consulta de incidentes por grupo operativo
147
Figura B.8 Consulta de incidentes por componente
Figura B.9 Consulta de incidentes y soluciones
148
Figura B.10 Pantalla de eliminacin de incidente
Figura B.11 Reporte conjunto de incidentes de falla
149
Figura B.12 Ingreso de componentes al inventario AIT
Figura B.13 Consulta de componentes de inventario AIT
150
Anexo C interfaces Usuario/Sistema Versin 2
Anexo C
Interfaces Usuario/Sistema Versin 2
Figura C.1 Pantalla de ingreso de incidentes
151
Figura C.2 Pantalla de Verificacin de ingreso del incidente
Figura C.3 Consulta de incidentes reportados por perodo de tiempo
152
Figura C.4 Reporte de incidentes por perodo de tiempo
Figura C.5 Reporte de incidentes por grupo operativo
153
Figura C.6 Clculo de indicadores para un grupo operativo
Figura C.7 Consulta de incidentes por fecha de minuta
154
Figura C.8 Imprimir minuta
Figura C.9 Reporte de incidentes y soluciones
155
Figura C.10 Pantalla de eliminacin de incidente
Figura C.11 Consulta de reportes abiertos
156
Figura C.12 Consulta en conjunto de minutas y Nagios
Figura C.13 Consulta de alertas de Nagios por equipo o aplicacin
157
Figura C.14 Pantalla de definicin de servicio para monitorear aplicacin
Figura C.15 Auditoria del sistema
158

Sistema Web

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistema Web

Caricato da

Copyright:

Formati disponibili

PROYECTO DE GRADO

Desarrollo de un Sistema de Informacin Web para la gestin de

2009 Universidad de Los Andes Mrida, Venezuela

Desarrollo de un sistema de Informacin Web para la Gestin de Incidentes de Falla en

Br. Carlos Germn Medina Albornoz

Resumen: En el presente proyecto se desarrolla un sistema de informacin web como herramienta

Palabras clave: Sistema de Informacin Web, Ingeniera de Confiabilidad, mantenimiento,

A mi madre, a mi padre y a mi hermano, las tres personas ms importantes en mi vida. Sin su

2.6.1 Diagramas de clases ...................................................................................................................... 31

4.1.2 Modelado de objetos de Negocio ..................................................................................................... 99

Figura 3.23 Modelo de la base de datos del sistema ..80

Figura 4.14 Modelo de la base de datos del sistema ....122

Figura C.2 Pantalla de Verificacin de ingreso del incidente 152

A la ilustre Universidad de Los Andes, particularmente a la Escuela de Ingeniera de Sistemas, por

A todos los miembros de la Coordinacin de Confiabilidad, por el apoyo y confianza

A mi amigo y compaero de clases Manuel Gmez, quien desarroll su proyecto de grado en la

A todos aquellos amigos y compaeros, que de alguna forma intervinieron en la realizacin de

1.1 Descripcin de la Empresa

Exploracin y Produccin: rea encargada de la evaluacin, exploracin, certificacin y

Refinacin: rea encargada de la separacin, mejoramiento y obtencin de productos o

Distribucin y comercializacin: rea encargada de colocar los productos obtenidos (Crudo y

Gas: rea encargada de la explotacin y comercializacin de los hidrocarburos gaseosos. Con

1.1.1 PDVSA AIT

Figura 1.1 Cadena de valor de PDVSA (Fuente: [1])

ii) AIT Servicios Comunes Centro

de necesidades y oportunidades en el negocio, entre otras. La Figura 1.3 muestra la estructura

Figura 1.2 Estructura organizativa de PDVSA AIT (Fuente: [2])

Figura 1.2 AIT Servicios Comunes

Figura 1.3 Estructura de PDVSA AIT Servicios Comunes Centro

La Coordinacin de Confiabilidad dentro de PDVSA AIT Servicios Comunes Centro (SCC), es

1.4 Planteamiento del Problema

los analistas, su recuperacin y almacenamiento, facilitando as la toma de decisiones y convirtindose

1.5.2 Objetivos Especficos

Realizar un estudio detallado del dominio de aplicacin en que se enmarca el sistema

Analizar los requisitos de los actores involucrados.

Realizar un diseo detallado de la estructura y distribucin del sistema.

Desarrollar los componentes de software que resulten necesarios.

Realizar pruebas al producto de software para verificar su correcto funcionamiento.

Refinar iterativamente el Sistema mediante el versionado sucesivo.

Entregar el sistema listo para su puesta en produccin a los miembros de la Coordinacin de

Facilita al lder del proyecto la planificacin y el control del mismo.

Establece un marco metodolgico nico que estandariza el proceso de desarrollo y unifica la

Se fundamenta en la ingeniera basada en componentes de software y emplea las mejores

El mtodo consta de los siguientes tres componentes:

Dentro del modelo de procesos establecido en el mtodo Watch se establece un marco

1.7 Estructura del documento

Captulo 2. Marco Terico y Herramientas de Soporte

2.1 Sistemas de Informacin

Disponibilidad de informacin cuando sea necesario y por los medios adecuados.

Suministro de informacin de manera selectiva.

Captulo 2. Marco Terico y Herramientas de Soporte

Variedad en la forma de presentacin de la informacin.

Cierto grado de autonoma para la toma de decisiones

Tiempo de respuesta adecuado a las necesidades del usuario.

Exactitud en la informacin suministrada.

Generalidad, como las funciones para atender a las diferentes necesidades.

Flexibilidad, capacidad de adaptacin.

Fiabilidad, para que el sistema opere correctamente.

Seguridad, proteccin contra prdidas.

Amigabilidad, para el usuario.

2.1.1 Actividades que realiza un sistema de informacin

Captulo 2. Marco Terico y Herramientas de Soporte

Salida de la informacin: Es la capacidad que tiene un sistema de informacin para mostrar la

2.1.2 Tipos de sistemas de informacin