Escolar Documentos
Profissional Documentos
Cultura Documentos
Presentado ante la ilustre UNIVERSIDAD DE LOS ANDES como requisito final para
obtener el Ttulo de INGENIERO DE SISTEMAS
Por
Br. Carlos Germn Medina Albornoz
Tutor: Prof. Judith Barrios
Asesor Industrial: Ing. Jos Casanova
Febrero 2009
Dedicatoria
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
iv
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
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 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 los miembros de las Gerencias MAP y GDS de PDVSA AIT Servicios Comunes Centro que
contribuyeron en el desarrollo del proyecto.
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.
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
Introduccin
Introduccin
Introduccin
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
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
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.
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.
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.
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.
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.
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.
16
17
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.
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.
19
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.
20
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
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.
22
23
Por lo general, la precisin en los ndices mejora entre mayor cantidad de registros histricos
se posea.
24
25
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.
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 .
Puede extenderse con libreras externas para soportar encriptacin, bsquedas por similitud
fontica (soundex), etc.
26
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
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).
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.
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].
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.
32
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.
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
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.
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.
36
37
de la organizacin, sus problemas de informacin y los requisitos funcionales que deben ser satisfechos
por el SI [5].
38
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
40
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.
42
atencin. En la Figura 3.5 se muestra el diagrama del proceso PF 4 sealando, entre otras cosas, sus
entradas, salidas y productos.
43
44
45
Figura 3.8 Diagrama de flujo entre procesos para la gestin de incidentes de falla
46
47
48
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.
ATC.
Servidores Z-Series.
Soporte Integral.
Plataformas de Escritorio.
Dispositivos de campo.
Control de activos.
Infraestructura.
Nmina.
Seguridad AIT.
Video Conferencia.
Instalaciones.
49
50
51
TPSF
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
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.
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.
Monitoreo
jornada
1. Atender incidentes ocurridos para los activos de su
especialidad.
Analistas de Grupos Operativos
Solucionadores
de incidentes diarios.
2. Suministrar minuta de incidentes diarios a todos los
interesados.
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:
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
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.
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
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.
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
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.
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.
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
Clasificacin. Prioridad.
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
Clasificacin. Prioridad.
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.
62
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.
63
64
65
66
67
Validar perfil de
usuario.
Consultar incidentes
por grupo operativo.
CU4
Consultar indicadores
operativos
de
la
plataforma.
CU5
Consultar incidentes
por componente
CU6
Consultar incidentes
por
perodo
de
tiempo.
CU7
Consultar alertas de
Nagios por perodo de
tiempo.
CU8
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.
CU12
CU13
CU14
CU15
CU16
CU17
68
Descripcin
El usuario cierra su sesin en el sistema.
Ingresar datos
incidente de falla
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
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.
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.
72
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.
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.
75
76
77
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.
79
80
81
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
83
Encabezado
rea de trabajo
Men de usuario
84
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.
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.
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
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.
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.
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.
89
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.30 Mensaje obtenido al tratar de ingresar un incidente con campos faltantes
91
92
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
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.
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.
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.
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.
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.
98
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.
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
101
102
103
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.
104
N de
requsito
R1
R2
R3
R4
R5
R6
R7
R8
R9
Nombre del
requisito
Clasificacin
Prioridad
Tipo de
requisito
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
Incorporar un mdulo para
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
Incorporar un mdulo para
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
Clasificacin. Prioridad.
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
Funcional
R17
Funcional
R18
Tipo de
requisito.
Funcional
Restriccin
Funcionalidad
N de
requsito
R19
R20
R21
R22
Nombre del
requisito
Clasificacin. Prioridad.
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
107
108
109
110
CU20
CU21
CU22
CU23
CU24
CU25
CU26
CU27
111
Descripcin
El usuario consulta el manual de ayuda en lnea.
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
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.
114
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.
115
116
117
118
119
120
121
122
123
124
125
126
127
128
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
129
130
131
132
133
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.
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.
136
repositorio bien estructurado de datos que puede ser incluso utilizado por la Coordinacin de
Confiabilidad para simular el comportamiento de la plataforma.
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.
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.
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.
139
Referencias Bibliogrficas
140
Referencias Bibliogrficas
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
Referencias Bibliogrficas
141
Anexo A
Planificacin del proyecto
142
143
Anexo B
Interfaces Usuario/Sistema Versin 1
144
145
146
147
148
149
150
Anexo C
Interfaces Usuario/Sistema Versin 2
151
152
153
154
155
156
157
158