-
UNIVERSIDAD DE ORIENTE
NCLEO DE SUCRE
ESCUELA DE CIENCIAS
DEPARTAMENTO DE MATEMTICAS
PROGRAMA DE LA LICENCIATURA EN INFORMTICA
APLICACIN WEB PARA LA EVALUACIN DE TECNOLOGAS DE AIT
APLICADAS
AL NEGOCIO DE EXPLORACIN PETROLERA
(Modalidad: Pasanta)
DAMARYS CAROLINA BERMDEZ CEDEO
TRABAJO DE GRADO PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR
AL
TTULO DE LICENCIADO EN INFORMTICA
CUMAN, 2008
-
APLICACIN WEB PARA LA EVALUACIN DE TECNOLOGAS DE AIT
APLICADAS
AL NEGOCIO DE EXPLORACIN PETROLERA
APROBADO POR:
____________________
Profa. Carmen Romero
Asesor Acadmico
____________________
Ing. Mauro London
Asesor Institucional
____________________
(Jurado)
____________________
(Jurado)
-
INDICE
DEDICATORIA
.................................................................................................................
i AGRADECIMIENTO
.......................................................................................................ii
LISTA DE TABLAS
........................................................................................................iii
LISTA DE
FIGURAS.......................................................................................................
iv LISTA DE
ABREVIATURAS.........................................................................................vi
RESMEN
......................................................................................................................vii
INTRODUCCIN.............................................................................................................
1 CAPTULO I.
....................................................................................................................
4 PRESENTACIN
.............................................................................................................
4
1.1 Planteamiento del
problema.....................................................................................
4 1.2 Alcance
....................................................................................................................
5 1.3
Limitaciones.............................................................................................................
6
CAPTULO II.
...................................................................................................................
7 MARCO DE
REFERENCIA.............................................................................................
7
2.1 Marco
terico...........................................................................................................
7 2.1.1 Antecedentes de la
investigacin......................................................................
7 2.1.2 Antecedentes de la
organizacin.......................................................................
8 2.1.3 rea de estudio
...............................................................................................
10 2.1.4 rea de
investigacin......................................................................................
13
2.2 Marco metodolgico
..............................................................................................
16 2.2.1 Metodologa de la investigacin
.....................................................................
16 2.2.2 Metodologa del rea aplicada
........................................................................
17
CAPTULO
III.................................................................................................................
23 DESARROLLO
...............................................................................................................
23
3.1 Fase de inicio
.........................................................................................................
23 3.1.1 Planificacin de la fase de inicio
....................................................................
23 3.1.2 Estudio del contexto del
sistema.....................................................................
25
3.1.2.1 Proceso GNO
...........................................................................................
25 3.1.2.2 Modelo del negocio
.................................................................................
30 3.1.2.3 Modelo del
dominio.................................................................................
31 3.1.2.4 Riesgos del
sistema..................................................................................
34
3.1.3 Flujo de trabajo (workflow) de requisitos
....................................................... 36 3.1.3.1
Requisitos funcionales
.............................................................................
37 3.1.3.2 Requisitos no funcionales
........................................................................
38 3.1.3.3 Captura de requisitos como casos de
uso................................................. 39 3.1.3.4
Modelo de casos de uso
...........................................................................
41
3.1.4 Flujo de trabajo (workflow) de
anlisis...........................................................
47 3.1.4.1 Modelo de anlisis
...................................................................................
47 3.1.4.2 Diagrama de clases de
anlisis.................................................................
49 3.1.4.3 Diagrama de colaboracin
.......................................................................
52 3.1.4.4 Identificacin de paquetes de
anlisis......................................................
59
3.1.5 Evaluacin de la fase de inicio
.......................................................................
60
-
3.2 Fase de
elaboracin................................................................................................
61 3.2.1 Planificacin de la fase de
elaboracin...........................................................
61 3.2.2 Flujo de trabajo (workflow) de
requisitos.......................................................
63
3.2.2.1 Requisitos funcionales
.............................................................................
64 3.2.2.2 Requisitos no funcionales
........................................................................
64 3.2.2.3 Captura de requisitos como casos de
uso................................................. 64 3.2.2.4
Modelo de casos de uso
...........................................................................
65 3.2.2.5 Prototipo de la interfaz de usuario
........................................................... 69
3.2.3 Flujo de trabajo (Workflow) de anlisis
.......................................................... 70
3.2.3.1 Modelo de anlisis
...................................................................................
70 3.2.3.2 Diagrama de clases de
anlisis.................................................................
72 3.2.3.3 Diagrama de colaboracin
.......................................................................
75 3.2.3.3 Identificacin de paquetes de
anlisis...................................................... 81
3.2.3.4 Diagrama de paquetes de anlisis
............................................................ 82
3.2.4 Flujo de trabajo (workflow) de diseo
............................................................ 84
3.2.4.1 Diseo de la arquitectura
.........................................................................
84 3.2.4.2 Modelo de
diseo.....................................................................................
86 3.2.4.3 Diseo del mtodo de evaluacin tecnolgica del sistema
propuesto ..... 89 3.2.4.4 Diagrama de clases del diseo
.................................................................
89 3.2.4.5 Diagrama de secuencia
............................................................................
90 3.2.4.5 Diseo de la base de datos local del sistema
........................................... 90
3.2.5 Flujo de trabajo (workflow) de implementacin
............................................. 90 3.2.5.1 Cdigos
ejecutables para realizar los casos de
uso.................................. 91
3.2.6 Flujo de trabajo (workflow) de pruebas
.......................................................... 91
3.2.6.1 Particin
equivalente................................................................................
92 3.2.6.2 Aplicacin de casos de
prueba.................................................................
93 3.2.6.3 Casos de prueba basados en casos de
uso................................................ 95 3.3.6.4
Pruebas de integracin
.............................................................................
96
3.2.7 Evaluacin de la fase de
elaboracin..............................................................
97 3.3 Fase de
construccin..............................................................................................
98
3.3.1 Planificacin de la fase de construccin
......................................................... 98 3.3.2
Flujo de trabajo (workflow) de implementacin
............................................. 99
3.3.2.1 Cdigos ejecutables para realizar los casos de
uso.................................. 99 3.3.2.2 Documentacin del
sistema
...................................................................
101
3.3.3 Flujo de trabajo (workflow) de pruebas
........................................................ 101
3.3.3.1 Particin
Equivalente.............................................................................
101 3.3.3.2 Aplicacin de casos de
prueba...............................................................
102 3.3.3.3 Casos de prueba basados en casos de
uso.............................................. 103 3.3.3.4
Pruebas de integracin
...........................................................................
103
3.3.4 Evaluacin de la fase de construccin
.......................................................... 104
CAPITULO IV
..............................................................................................................
105 RESULTADOS Y DISCUSIN
...................................................................................
105
4.1 Aplicacin del mtodo de evaluacin tecnolgica para un caso de
estudio ........ 105 4.2 Discusin de los
resultados..................................................................................
108
CONCLUSIONES.........................................................................................................
109
-
RECOMENDACIONES................................................................................................
110 BIBLIOGRAFA
...........................................................................................................
111 APNDICES
.................................................................................................................
113 ANEXOS
.......................................................................................................................
143
-
i
DEDICATORIA
Dedico este trabajo primeramente a Dios, por guiarme y darme las
condiciones
adecuadas de vida para lograr esta meta.
A mi familia, por estar siempre all y apoyarme en todo momento.
Mis padres
Juana y Lus, por aportarme diversas formas de ver y entender las
cosas. Mis hermanos
Lus, Mara, Imara y Carlos por ayudarme y brindarme su apoyo en
los momentos que
fueron necesarios y en los que no. Mi hermana Mileddy por ser ms
que mi hermana mi
mejor modelo a seguir en la vida. Y a mi perrito adorado King,
que ya no est con
nosotros.
A mis sobrinos Luz, Xioma, Glorianny, Marwil, Cristina,
Cristian, Lus y Sinai
por llevar un poco de alegra a casa.
A la familia Monteverde Calderin, por acogerme en su hogar
durante la duracin
de mi pasanta en la ciudad de Puerto la Cruz. Mi ms sincero y
eterno agradecimiento.
Por ltimo a mis amigos de siempre, mis nuevos amigos y compaeros
de la
universidad, por aportar cada uno de ellos grandes aprendizajes
de vida. Como deca
Pablo Neruda nosotros los de entonces, ya no somos los
mismos.
-
ii
AGRADECIMIENTO
Agradezco a la Universidad de Oriente, por recibirme en esta
etapa de formacin
profesional.
A la Profa. Carmen Victoria, por asesorarme en todo momento
durante el
desarrollo de este trabajo. Por la confianza brindada y el apoyo
total mostrado hacia mi
persona.
A Petrleos De Venezuela S.A. por permitirme realizar la pasanta
dentro de sus
instalaciones. As como a la Superintendencia de GNO, encabezada
por el Ing. Mauro
London, por darme la oportunidad de desarrollar esta innovadora
idea. As como al
equipo en general, por prestar toda la colaboracin posible para
la culminacin de este
trabajo. Tambin a la Superintendencia de Servicios Comunes, en
especial a Jess
Belisario y Lus Daz por el apoyo prestado.
-
iii
LISTA DE TABLAS
Tabla 1. Actividades y artefactos planificados para la fase de
inicio. ............................. 24 Tabla 2. Glosario de
trminos del modelo del dominio del sistema propuesto.
.............. 33 Tabla 4. . Plan de prevencin y contingencia para
los riesgos ms predominantes en el desarrollo de la aplicacin
Web.......................................................................................
36 Tabla 5. Lista de actores de los casos de usos del sistema
SIGENOP-Evaluacin de tecnologas de la fase de inicio.
.......................................................................................
40 Tabla 6. Casos de usos del sistema SIGENOP- Evaluacin de
tecnologas de la fase de inicio.
...............................................................................................................................
40 Tabla 7. Clases de interfaz del sistema de la fase de inicio.
............................................ 48 Tabla 8. Clases de
control del sistema de la fase de inicio.
............................................. 48 Tabla 9. Clases de
entidad del sistema de la fase de inicio.
............................................ 49 Tabla 10. Estatus
de desarrollo de los artefactos generados para la fase de
inicio.......... 61 Tabla 11. Actividades y artefactos planificados
para la fase de elaboracin. ................. 63 Tabla 13. Casos de
uso del sistema SIGENOP - Evaluacin de tecnologa de la fase de
elaboracin.......................................................................................................................
64 Tabla 14. Clases de interfaz del sistema de la fase de
elaboracin. ................................ 71 Tabla 15. Clases de
control del sistema de la fase de elaboracin.
................................. 71 Tabla 16. Clases de entidad
del sistema de la fase de elaboracin.
................................. 72 Tabla 15. Aplicacin de casos
de prueba de la fase de elaboracin. ...............................
93 Tabla 16. Estatus de desarrollo de los artefactos generados para
la fase de elaboracin.98 Tabla 17. Actividades y artefactos
planificados para la fase de construccin................. 99 Tabla
18. Aplicacin de casos de pruebas de la fase de
construccin........................... 102 Tabla 19. Matriz de
decisin tecnologa vs. indicador.
................................................. 106 Tabla 20.
Varianza calculada para cada par tecnologa
indicador.............................. 107 Tabla 21. Aplicacin de
los mtodos de decisin seleccionados.
................................. 107
-
iv
LISTA DE FIGURAS
Figura 1. Estructura del Proceso Unificado de Desarrollo de
Software. ......................... 19 Figura 2. Flujos de trabajo
requisitos, anlisis, diseo, implementacin y prueba de una iteracin
genrica en el Proceso
Unificado......................................................................
21 Figura 3. Esquema del proceso GNO.
.............................................................................
25 Figura 4. Modelo del negocio de la Superintendencia
GNO........................................... 30 Figura 5. Modelo
del dominio.
........................................................................................
32 Figura 6. Diagrama de caso de uso del sistema SIGENOP Evaluacin
de tecnologas de la fase de inicio.
..........................................................................................................
41 Figura 7. Diagrama de clases de anlisis para el caso de uso
Administrar Tecnologa de la fase de inicio.
...............................................................................................................
50 Figura 8. Diagrama de clases de anlisis para caso de uso
Administrar Indicador de la fase de inicio.
...................................................................................................................
51 Figura 9. Diagrama de clases de anlisis para el caso de uso
Evaluar Tecnologa de la fase de inicio.
...................................................................................................................
51 Figura 10. Diagrama de colaboracin del caso de uso Administrar
Tecnologa (agregar) de la fase de inicio.
..........................................................................................................
52 Figura 11. Diagrama de colaboracin del caso de uso Administrar
Tecnologa (modificar) de la fase de inicio.
.......................................................................................
53 Figura 12. Diagrama de colaboracin del caso de uso Administrar
Tecnologa (eliminar) de la fase de inicio.
..........................................................................................................
54 Figura 13. Diagrama de colaboracin del caso de uso Administrar
Indicador (agregar) de la fase de inicio.
...............................................................................................................
55 Figura 14. Diagrama de colaboracin del caso de uso Administrar
Indicador (modificar) de la fase de inicio.
..........................................................................................................
56 Figura 15. Diagrama de colaboracin del caso de uso Administrar
Indicador (eliminar) de la fase de inicio.
..........................................................................................................
57 Figura 16. Diagrama de colaboracin para el caso de uso Evaluar
Tecnologa de la fase de
inicio............................................................................................................................
59 Figura 17. Paquete de anlisis Administracin de Tecnologas.
..................................... 59 Figura 18. Paquete de
anlisis Administracin de Indicadores.
...................................... 60 Figura 19. Paquete de
anlisis Evaluacin de Tecnologas.
............................................ 60 Figura 20. Diagrama
de casos de uso del sistema SIGENOP Evaluacin de tecnologas de la
fase de elaboracin.
.................................................................................................
65 Figura 21. Prototipo de interfaz principal del sistema.
.................................................... 70 Figura 22.
Prototipo de interfaz secundaria del sistema.
................................................. 70 Figura 23.
Diagrama de clases de anlisis para el caso de uso Evaluar Tecnologa
de la fase de
elaboracin...........................................................................................................
73 Figura 24. Diagrama de clases de anlisis para el caso de uso
Realizar Consultas de la fase de
elaboracin...........................................................................................................
74
-
v
Figura 25. Diagrama de clases de anlisis para el caso de uso
Emitir Reportes de la fase de elaboracin.
.................................................................................................................
74 Figura 26. Diagrama de clases de anlisis para el caso de uso
Administrar Mtodos de la fase de
elaboracin...........................................................................................................
75 Figura 27. Diagrama de colaboracin para el caso de uso
Administrar Mtodo (agregar) de la fase de elaboracin.
.................................................................................................
76 Figura 28. Diagrama de colaboracin para el caso de uso
Administrar Mtodo (modificar) de la fase de
elaboracin...............................................................................
77 Figura 29. Diagrama de colaboracin para el caso de uso
Administrar Mtodo (eliminar) de la fase de inicio.
..........................................................................................................
78 Figura 30. Diagrama de colaboracin para el caso de uso Evaluar
Tecnologas de la fase de elaboracin.
.................................................................................................................
80 Figura 31. Diagrama de colaboracin para el caso de uso Realizar
Consultas de la fase de elaboracin.
.................................................................................................................
81 Figura 32. Paquete de anlisis Realizacin de Consultas de la fase
de elaboracin........ 81 Figura 33. Paquete de anlisis Emisin de
Reportes de la fase de elaboracin............... 82 Figura 34.
Paquete de anlisis Administracin de Mtodos de la fase de
elaboracin. .. 82 Figura 35. Paquete de anlisis Evaluacin de
Tecnologas (Actualizado) ...................... 82 Figura 36.
Diagrama de paquetes de anlisis del sistema de la fase de
elaboracin. ...... 83 Figura 37. Vista lgica de las capas de la
arquitectura del sistema. ................................ 85
Figura 38. Clases de diseo a partir de clases de
interfaz................................................ 87 Figura
39. Clases de diseo a partir de clases de entidad.
............................................... 87 Figura 40.
Clases de diseo a partir de las clases de control.
.......................................... 88 Figura 41. Formulario
de carga registrar
tecnologa........................................................
91 Figura 42. Formulario de carga identificacin de la evaluacin
tecnolgica. ................ 99 Figura 43. Pgina de consulta del
sistema de evaluacin de tecnologas. ..................... 100
Figura 44. Resultado de la matriz de decisin para el caso de
estudio seleccionado. ... 107
-
vi
LISTA DE ABREVIATURAS
AIT Automatizacin, Informtica y Telecomunicaciones
AIT EyP AIT Exploracin y Produccin
DNO Documento de Necesidades y Oportunidades
FODA Fortalezas, Oportunidades, Debilidades y Amenazas
GNO Gestin de Necesidades y Oportunidades
GNU General Public License (Licencia Pblica General de GNU)
HTML Hypertext Markup Language (Lenguaje de Marcado de
Hipertexto)
MOSCA Modelo Sistmico de Calidad
PDVSA Petrleos de Venezuela S.A.
PEMEX Petrleos Mexicanos
PHP PHP Hypertext Pre-processor (Preprocesador a Hipertexto)
SIGAIT Sistema de gestin de AIT
SIGENOP Sistema de Gestin de Necesidades y Oportunidades
SGBD Sistema de Gestin de Base de Datos
SS Sistemas de Software
TCP/IP
Transmission Control Protocol / Internet Protocol (Protocolo de
Control de Transmisin/ Protocolo de Internet)
UML Unified Modeling Language (Lenguaje Unificado de
Modelado)
UNE Una Norma Espaola
USB Universidad Simn Bolvar
-
vii
RESMEN
La aplicacin Web para la evaluacin de tecnologas de
Automatizacin, Informtica y Telecomunicaciones (AIT) aplicadas al
negocio de exploracin petrolera fue desarrollada para documentar el
proceso de adopcin tecnolgica llevado a cabo en la Superintendecia
de Gestin de Necesidades y Oportunidades (GNO); a travs del estudio
del comportamiento de las tecnologas por medio de variables
cuantificadas por el uso de indicadores como instrumento de
medicin, as como tambin el uso de mtodos de decisin que apoyarn el
proceso de toma de decisiones para realizar la seleccin de la
tecnologa una vez realizada la evaluacin, lo que generar la creacin
de un histrico del cual se podr obtener informacin de las distintas
evaluaciones realizadas a travs del tiempo. Cabe destacar que el
mismo se desarroll utilizando el Proceso Unificado de Desarrollo de
Software planteado por Jacobson, Booch y Rambaugh (1999). La
formulacin de indicadores estuvo basada el la metodologa de
generacin y seleccin de indicadores (Norma UNE 66175:2003) y el
modelo usado para el proceso de evaluacin fue el modelo racional.
La codificacin y construccin del sistema, se hizo utilizando PHP5
como lenguaje de programacin para la creacin de pginas Web
dinmicas, PostgreSQL 8.0 como manejador de base de datos,
Javascript como lenguaje de programacin interpretado y basado en
objetos para la validacin de los formularios, Quanta + 3.2 como
generador de cdigo HTML, servidor Web Apache 2.1 y GNU/Linux Ubuntu
6.10 como sistema operativo. La aplicacin Web permite solventar los
problemas relacionados con el registro, recuperacin y organizacin
de la informacin concerniente al proceso de evaluacin tecnolgica,
ofreciendo un medio para conocer el estado de una tecnologa en
particular dentro de la gerencia y as considerar diversas
alternativas de solucin para elegir las ms adecuadas; lo que
produce una toma de decisiones ms acertada. Palabras Claves:
aplicacin Web, indicadores, Proceso Unificado.
-
1
INTRODUCCIN
Ante la importancia que representa la informacin dentro de las
organizaciones,
han surgido tecnologas que permiten el manejo eficiente de esta.
Unos de los medios
utilizados son los sistemas de informacin automatizados, los
cuales han contribuido a
trabajar con mayor eficiencia en la ejecucin de sus procesos
(Kendall y Kendall, 2005).
El gran avance de los sistemas de informacin durante las ltimas
dcadas ha
facilitado que se puedan manejar grandes cantidades de datos,
almacenarlos y
transmitirlos en muy poco tiempo; es all donde radica la
importancia de uno de sus
componentes, como es el caso de las redes.
Una red informtica es un conjunto de ordenadores conectados
entre s con el fin
de compartir informacin (Cisco, 2002), donde el modelo
cliente-servidor es el
mecanismo que permite realizar el intercambio de servicios e
informacin en las redes
informticas de forma habitual; siendo Internet el sistema de
redes que conecta
computadores en todo el mundo (Velasco, 2005).
En el mbito empresarial se ha planteado la construccin de
sistemas de
informacin basados en los estndares de la Internet, derivando
esto al uso del trmino
Intranet, la cual es un mecanismo de integracin para personas,
procesos e informacin
dentro de una organizacin con tecnologas basadas en la interfaz
de exploracin
intuitiva de la World Wide Web, resultando ser una Internet
privada (Martnez, 2005).
Los sistemas o aplicaciones basados en la Web son sistemas
confiables, prcticos
y adaptables que ofrecen un complejo arreglo de contenido y
funcionalidad a una amplia
poblacin de usuarios finales, basndose en la utilizacin de un
navegador Web, que
permite la extraccin de los documentos o pginas Web de los
servidores y los muestra
por pantalla a los usuarios. Estos han evolucionado en
sofisticadas herramientas de
-
2
computacin que no slo proporcionan funcin por s misma al usuario
final, sino que
tambin se han integrado como bases de datos corporativas y
aplicaciones de negocios
(Pressman, 2005).
Muchas organizaciones a nivel mundial y nacional estn haciendo
uso de Intranets
y aplicaciones Web en sus redes, entre las cuales se destaca la
empresa PDVSA, la cual
est encargada de los hidrocarburos del pas, de manera eficiente,
rentable, segura,
transparente y comprometida con la proteccin ambiental; con el
fin de motorizar el
desarrollo armnico del pas, afianzar el uso soberano de los
recursos, potenciar el
progreso endgeno y propiciar una existencia digna y provechosa
para el pueblo
venezolano (PDVSA, 2005).
Entre las gerencias que conforman el ncleo general de PDVSA, se
encuentra la
Gerencia de Exploracin encargada de los hallazgos de
hidrocarburos gaseosos y no
gaseosos en el suelo, donde su misin primordial consiste en la
incorporacin de estos
recursos asegurando la continuidad del negocio y convirtindose
en la base fundamental
para que PDVSA exista (PDVSA, 2005).
El ente encargado de la plataforma tecnolgica dentro de PDVSA es
la Gerencia
de AIT, dividida en distintos organismos como es el caso de la
Superintendencia de
GNO, cuya funcin es proponer soluciones tecnolgicas a sus
usuarios, lo que requiere
de evaluaciones constantes entre las mltiples opciones
disponibles, implicando un
tiempo considerable en el hallazgo de alternativas que cumplan
con los requerimientos
de las solicitudes realizadas.
Debido a esta situacin se propuso el desarrollo de una aplicacin
Web para la
evaluacin de tecnologas de AIT aplicadas al negocio de
exploracin petrolera, que
permite acceder a la informacin relacionada con estas tecnologas
y sus respectivas
evaluaciones, como medio de apoyo a la toma de decisiones al
seleccionar soluciones
idneas para sus usuarios, de manera rpida, ordenada y
segura.
-
3
Este trabajo est estructurado en cuatro (4) captulos, como se
especifica a
continuacin:
Captulo I. Presentacin
Est formado por el planteamiento del problema, donde se describe
la situacin
problemtica que motiv este trabajo de investigacin; el alcance,
el cual establece lo
que el sistema ser capaz de hacer y las limitaciones, que son
los inconvenientes u
obstculos presentes durante el desarrollo de la
investigacin.
Captulo II. Marco de referencia
Est conformado por dos secciones principales: el marco terico,
presenta los
fundamentos tericos necesarios para soportar la investigacin,
describiendo los
antecedentes de la investigacin y la organizacin, adems del rea
de estudio e
investigacin, en el cual est enmarcado el trabajo propuesto. El
marco metodolgico,
presenta la metodologa aplicada para elaborar la solucin al
problema planteado.
Captulo III. Desarrollo
Aqu se expone de forma detallada la aplicacin de los
procedimientos en el marco
metodolgico para el logro de los objetivos planteados,
explicando cada uno de los
pasos realizados en el desarrollo del sistema con descripciones,
figuras y diagramas que
permiten una mejor visualizacin y entendimiento.
Captulo IV. Anlisis de los resultados y discusin
Se presenta la aplicacin del mtodo de evaluacin tecnolgica
diseado y los
resultados generados de su aplicacin a un caso de estudio.
Finalmente, se presentan las conclusiones obtenidas durante el
desarrollo del
trabajo y las recomendaciones para mejorar el desempeo del
sistema realizado. Adems
se presentan la bibliografa consultada para complementar las
bases de la investigacin
as como tambin los apndices y anexos correspondientes.
-
4
CAPTULO I.
PRESENTACIN
1.1 Planteamiento del problema
La gerencia de AIT como organismo encargado de velar por el
buen
funcionamiento de la plataforma tecnolgica de PDVSA, cuenta con
distintas
dependencias que hacen posible que se logre dicho propsito.
Entre estas se encuentra la
Superintendencia de GNO, quien tiene como fin identificar,
determinar y administrar
soluciones tecnolgicas integrales de alta calidad, eficientes y
efectivas en trminos de
costo y oportunidad que apalanquen las metas y objetivos de
PDVSA.
GNO para satisfacer una necesidad u oportunidad tecnolgica del
negocio/usuario,
debe analizarla y detallarla para convertirla en un
requerimiento vlido, que
posteriormente ser transformada en una propuesta de solucin
tecnolgica integral.
Para dar respuesta a sus usuarios, se apoya en diferentes
fuentes de informacin, las
cuales se encuentran dispersas, obtenindose en libros, consultas
a expertos dentro y
fuera de la organizacin, sistemas de informacin de uso interno,
Internet, entre otras.
Posteriormente sta informacin hay que ubicarla, filtrarla y
tomar lo necesario de ella,
realizar un anlisis de alternativas para finalmente dar
propuestas de soluciones, lo cual
involucra en ocasiones un consumo de tiempo considerable,
ocasionando que el nmero
de solicitudes se vayan acumulando, provocando malestar o
insatisfaccin en los
usuarios por no obtener respuestas lo ms prontas y acertadas
posibles.
Todo esto trae como consecuencia que en ocasiones los usuarios,
debido al tiempo
de respuesta tardo, se ven obligados a tomar sus propias
decisiones de solucin las
cuales no necesariamente son las mejores, dado que en la mayora
de los casos, no
contemplan las variables propicias para realizar una evaluacin
correcta, sino que se
-
5
apoyan en la experiencia propia, dando como resultado la
adquisicin de tecnologa, que
si bien puede solucionar el problema objeto de la toma de
decisiones en un tiempo
menor, podran no ser las ms adecuadas, por poseer utilidades que
no se requieren,
porque ya existen dentro de la organizacin o porque existen
muchas de estas con el
mismo fin, entre otros. Todo esto produciendo gastos elevados o
innecesarios a la
industria.
En miras de resolver esta problemtica, se propuso el desarrollo
de una aplicacin
Web que permitiera realizar la evaluacin de las tecnologas de
AIT aplicadas al negocio
de exploracin petrolera, la cual contar con un portafolio o
repositorio tecnolgico que
contenga informacin de tecnologas que estn en uso en este
negocio as como las que
no estn pero con fines comunes a l, a partir de las cuales se
formularn indicadores
que permitirn cuantificar el valor dado por el uso, desempeo,
entre otras variables, de
una tecnologa especfica, facilitando la aplicacin de mtodos para
la toma de
decisiones puesto que se manejarn diferentes escenarios que
arrojen las alternativas de
solucin que ayuden ante el requerimiento a ser cumplido. Todo
esto, permitiendo el
seguimiento y progreso de la implantacin de tecnologas que
cumplan con los
lineamientos y objetivos estratgicos de la organizacin, as como
proponer el uso de
tecnologas que puedan reemplazar a las existentes, si esto fuese
necesario.
1.2 Alcance
El presente trabajo estuvo enmarcado en el desarrollo de una
aplicacin Web para
la evaluacin de tecnologas de AIT aplicadas al negocio de
exploracin petrolera, la
cual ofrece la realizacin de registro, actualizacin y consulta
de los datos sobre los
indicadores a ser estudiados, las soluciones tecnolgicas de AIT
y sus respectivas
evaluaciones que permitan conocer el desempeo de las misma
haciendo uso de los
indicadores propuestos para cuantificar, a travs de sus frmulas
asociadas, las variables
objeto de medicin; apoyndose en la utilizacin de mtodos o
criterios de decisin, que
arrojen propuestas o alternativas de solucin ante el escenario
de estudio que se est
-
6
realizando, lo que generar la creacin de un histrico con la
informacin obtenida de
las evaluaciones en el tiempo. Los resultados de la evaluacin se
representan en forma
grfica para su fcil interpretacin. Estas evaluaciones podrn ser
consultadas e impresas
por medio de la generacin de reportes.
1.3 Limitaciones
Los indicadores utilizados en el desarrollo de la aplicacin Web
slo sern
cuantitativos, debido a que el modelo de toma de decisin
empleado se enfoca hacia la
cuantificacin de variables.
-
7
CAPTULO II.
MARCO DE REFERENCIA
2.1 Marco terico
2.1.1 Antecedentes de la investigacin
La necesidad de las empresas que hacen uso de la tecnologa como
pieza clave en
su incremento de competitividad, calidad y confiabilidad en la
realizacin de sus
actividades, las ha conllevado a implementar mtodos que midan de
alguna forma el
rendimiento que suministra cada una de estas en sus procesos,
con el fin de alcanzar los
objetivos planteados, obtener un mejor manejo de la informacin y
conseguir mejores
resultados en el proceso de toma de decisiones.
La empresa PEMEX en la bsqueda de conseguir mejoras en sus
procesos de
exploracin y produccin petrolera, realiz un estudio de sus
activos ms significativos,
entre ellos el uso y desempeo de tecnologas, como medio de medir
la relacin uso de
la tecnologa - desempeo de la organizacin. Basado en la
utilizacin de indicadores,
con los cuales se form un modelo de regresin (Mendizbal,
2001).
Competitividad tecnolgica y especializacin: la lgica del tamao
en las
empresas proveedoras de la industria petrolera; expone el
anlisis realizado a un
conjunto de indicadores en la evaluacin de la gestin tecnolgica,
y su aplicacin a
diferentes empresas venezolanas proveedoras de la industria
petrolera en los sectores de
manufactura, ingeniera y construccin, como forma de medir las
actividades
tecnolgicas e innovadoras para disear nuevas estrategias
orientadas hacia la
innovacin y poder as afrontar los mercados actuales (Testa,
2005).
-
8
La USB, como forma de medir la calidad de los SS y partiendo de
la premisa de
que los modelos se deben formular con base a las caractersticas
competitivas para cada
tipo de SS considerando la alta participacin humana en el
proceso de desarrollo del
mismo, propone la creacin del prototipo de MOSCA para evaluar la
calidad de los SS
integrando el modelo de calidad del producto y el modelo de
calidad del proceso de
desarrollo, soportado en los conceptos de la calidad total
sistmica (Mendoza y cols,
2004).
En la Gerencia de Tecnologa de la empresa Maraven, S.A. (antigua
filial de
PDVSA) ubicada en Lagunillas Edo. Zulia. Se llev a cabo un
estudio sobre el anlisis
del alcance y limitaciones del proceso de gestin tecnolgica,
como forma de reforzar el
posicionamiento tecnolgico de esta gerencia. Esto se llev a cabo
gracias a la
aplicacin de encuestas con el propsito de determinar este
posicionamiento a travs de
un anlisis de FODA (Paredes y Polo, 1995).
En la Gerencia de AIT, como herramienta para medir el logro de
los objetivos que
cada uno de sus procesos se planteara, surgi la creacin de la
aplicacin SIGAIT la cual
en su mdulo de gestin de indicadores se lleva el control de las
actividades que cada
proceso realiza y se miden en funcin del cumplimiento que cada
uno de estos presenten
en un tiempo establecido con el uso de indicadores de gestin
(PDVSA, 2005).
2.1.2 Antecedentes de la organizacin
PDVSA es la corporacin estatal que se encarga de los
hidrocarburos del pas, de
manera eficiente, rentable, segura, transparente y comprometida
con la proteccin
ambiental; con el fin de motorizar el desarrollo armnico del
pas, afianzar el uso
soberano de los recursos, potenciar el avance endgeno y
propiciar una existencia digna
y provechosa para el pueblo venezolano, propietario de la
riqueza del subsuelo nacional
y nico dueo de esta empresa operadora, que est en concordancia
con el principio de
transparencia y rendicin de cuentas (PDVSA, 2005).
-
9
PDVSA cumple con todas las actividades propias del negocio
petrolero,
constituyndose en una corporacin verticalmente integrada, que
abarca todos los
procesos: exploracin, produccin, refinacin y comercializacin,
para el
aprovechamiento del petrleo, gas y bitumen, crudo pesado,
extrapesado, mediano,
liviano, produccin y manufactura de orimulsin, as como la
explotacin de
yacimientos de carbn (Petrleos De Venezuela S.A., 2005); donde
cada uno de estos
procesos corresponden a gerencias dentro de la corporacin (Anexo
1). Su red de
manufactura y mercadeo abarca Venezuela, el Caribe, Estados
Unidos y Europa,
llegando en los ltimos aos hasta mercados del lejano
Oriente.
Exploracin es la gerencia corporativa encargada de los hallazgos
de
hidrocarburos gaseosos y no gaseosos en el suelo, maximizando el
valor econmico a
largo plazo de sus reservas, siendo uno de los procesos vitales
de la industria, cuya
misin primordial consiste en la incorporacin de estos recursos,
de acuerdo a los
lineamientos de la corporacin para asegurar la continuidad del
negocio, por lo cual se
convierte en la base fundamental para que PDVSA exista (PDVSA,
2005).
A esta gerencia estn adscritas once (11) sub-gerencias a nivel
nacional, la
mayora encargadas de la planificacin, gestin y ejecucin de
proyectos exploratorios y
operaciones de geofsica y geodesia, especficamente planificacin
de perforacin,
identificacin de reas de inters, deteccin de trampas y
verificacin de acumulacin
(Anexo 2). Estas operaciones se apoyan en un robusto parque
tecnolgico constituido
por herramientas informticas, de telecomunicaciones y
automatizacin, que garantizan
el desempeo eficiente de las actividades que se llevan a cabo
dentro de las mismas
(PDVSA, 2005).
En PDVSA el ente encargado de la plataforma tecnolgica es la
Gerencia de AIT,
donde son atendidas todas las necesidades tecnolgicas que puedan
presentarse, desde su
gestin hasta el desarrollo e implantacin de soluciones
integrales, eficientes y eficaces
para resolverlas (GNO, 2006).
-
10
La Gerencia de AIT se encuentra divida por distintos organismos,
distribuidos a lo
largo y ancho del pas donde PDVSA se encuentre (Anexo 3). Entre
ellas existe la
Gerencia de AIT EyP, la cual se encuentra subdividida de acuerdo
a la regin: oriente,
occidente y sur. En AIT EyP Oriente se encuentran: AIT Distrito
Norte (Maturn), AIT
Distrito San Tom (San Tom), AIT Distrito Morichal (Morichal) y
AIT Exploracin
(Puerto la Cruz) (Anexo 4). Esta ltima posee, una serie de
superintendencias que
apoyan al negocio de exploracin como lo son: Planificacin,
Desarrollo de
Implantacin de Soluciones, Cadena de Suministro, Gestin del
Servicio,
Administracin de Recursos, Mantenimiento, Control de la
Plataforma y GNO (Anexo
5).
La Superintendencia de GNO se encuentra dividida en tres
unidades: Consultora y
Gestin del Negocio, Consultora y Gestin Tecnolgica y
Planificacin de Necesidades
y Oportunidades (Anexo 6). Estas se encargan de capturar y
analizar las necesidades y
oportunidades de soluciones de automatizacin, informtica y
telecomunicaciones;
generar, promover y gestionar el catlogo y los acuerdos de
servicios con los niveles de
rendimiento ofrecidos a los usuarios, en soluciones tecnolgicas
integrales y determinar,
revisar, aprobar y controlar las propuestas de soluciones
tecnolgicas nuevas o
existentes, respectivamente (GNO, 2006).
2.1.3 rea de estudio
Esta investigacin se enmarca dentro del rea de los sistemas de
informacin
automatizados, debido a que se hace uso del computador para la
automatizacin y
optimizacin del proceso de evaluacin tecnolgica, utilizando
herramientas de anlisis
como los indicadores para la toma de decisiones. Algunos
conceptos enmarcados dentro
de sta rea son los siguientes:
Sistema de informacin de apoyo para la toma de decisiones: son
sistemas de informacin computarizados que se distinguen por hacer
nfasis en el soporte en
-
11
cada una de las etapas de la toma de decisiones ofreciendo de
manera oportuna la
informacin necesaria para este proceso en un ambiente de
incertidumbre. Aunque
la decisin actual es del domino del tomador de decisiones
(Kendall y Kendall,
2005).
Anlisis y diseo de sistemas: el anlisis y diseo de sistemas es
un procedimiento para la resolucin de problemas. Cuando se trata
del diseo de sistemas de
informacin, busca analizar sistemticamente la entrada o flujo de
datos, la
transformacin de los datos, el almacenamiento de datos y la
salida de informacin
en el contexto de una organizacin particular. Tambin es usado
para analizar,
disear e implementar mejoras que puedan incorporarse a la
organizacin y
puedan ser alcanzadas al usar un sistema de informacin
computarizado (Senn,
1992).
Anlisis y diseo de sistemas orientado a objetos: abordando el
anlisis y diseo desde el paradigma orientado a objetos, se describe
el anlisis al poner nfasis en
una investigacin del problema y los requisitos, en vez de
ponerle una solucin. El
anlisis se debe calificar como anlisis de requisitos (mediante
un estudio de los
requisitos) o anlisis de objetos (estudiando los objetos del
dominio). Por otro
lado, el diseo pone nfasis en una solucin conceptual que
satisface los requisitos
y prestando atencin a la definicin de los objetos de software y
en cmo
colaboran para satisfacer los requisitos, en vez de ponerlos en
la implementacin
(Larman, 2003).
Modelado de datos: los modelos de datos aportan la base
conceptual para disear aplicaciones que hacen un uso intensivo de
datos, as como la base formal para las
herramientas y tcnicas empleadas en el desarrollo y uso de
sistemas de
informacin. Con respecto al diseo de bases de datos, el modelado
de datos puede
ser descrito como: dados los requerimientos de informacin y
proceso de una
-
12
aplicacin de uso intensivo de datos (por ejemplo, un sistema de
informacin),
construir una representacin de la aplicacin que capture las
propiedades estticas
y dinmicas requeridas para dar soporte a los procesos deseados
(por ejemplo,
transacciones y consultas). Adems de capturar las necesidades
dadas en el
momento de la etapa de diseo, la representacin debe ser capaz de
dar cabida a
eventuales futuros requerimientos (Moreno, 2000).
Bases de datos: es un conjunto de datos relacionados entre s.
por datos se entiende aquellos hechos conocidos que pueden
registrarse y que tienen un significado
implcito. Toda base de datos se puebla con datos para un
propsito especfico.
Una base de datos es un conjunto de datos lgicamente coherente,
con cierto
significado inherente. Una coleccin aleatoria de datos no puede
considerarse
propiamente una base de datos (Elmasri y Navathe, 1997).
SGBD: se puede definir el SGBD como un conjunto coordinado de
programas, procedimientos, lenguajes, etc. que suministra a los
distintos tipos de usuarios los
medios necesarios para describir y manipular los datos
almacenados en la base de
datos, garantizando su seguridad. Sus funciones esenciales son
las descripcin,
manipulacin y control de los datos (Elmasri y Navathe,
1997).
UML: es un lenguaje grfico para visualizar, especificar,
construir y documentar los artefactos de un sistema con gran
cantidad de software. UML proporciona una
forma estndar de escribir los planos de un sistema, cubriendo
tanto las cosas
conceptuales, tales como los procesos del negocio y funciones
del sistema, como
las cosas concretas, tales como las clases escritas en un
lenguaje de programacin
especfico, esquemas de bases de datos y componentes de software
reutilizables
(Rumbaugh y cols, 1999).
-
13
2.1.4 rea de investigacin
Esta investigacin se ubica dentro del rea de las aplicaciones
Web y gestin de
indicadores, porque se basa en un conjunto de pginas que
interactan entre s,
apoyndose en bases de datos asociadas, con recursos en
servidores Web, que permiten
la administracin del contenido y el procesamiento de informacin
referente a la
evaluacin tecnolgica que es proporcionada a los usuarios finales
del sistema (Kendall
y Kendall, 2005). Los trminos involucrados en esta rea son los
siguientes:
Indicadores: son un conjunto de instrumentos de medicin de las
variables asociadas a las metas. Al igual que estas ltimas, pueden
ser cualitativos o
cuantitativos. En este ltimo caso pueden ser expresados en
trminos de
"Logrado", "No Logrado" o sobre la ase de alguna escala
cualitativa. El principal
objetivo de los indicadores, es poder evaluar el desempeo del
rea mediante
parmetros establecidos en relacin con las metas, as mismo
observar la tendencia
en un lapso de tiempo durante un proceso de evaluacin. Con los
resultados
obtenidos se pueden plantear soluciones o herramientas que
contribuyan al
mejoramiento o correctivos que conlleven a la consecucin de la
meta fijada
(David, 1997).
Tabla o matriz de decisin: es un procedimiento tabular para
analizar alternativas de decisin y estados de la naturaleza. Donde
las alternativas representan las
estrategias o reglas de decisin que indican la accin que debe
tomarse ante una
situacin y los estados de la naturaleza las situaciones o
estados del ambiente
mutuamente excluyente que pueden ocurrir y que no estn bajo el
control del
tomador de decisiones. Para cualquier alternativa y estado de la
naturaleza en
particular existe una consecuencia o resultado, que es una
medida del beneficio
neto o pago recibido por el tomador de decisiones (Moskowitz y
Gordon, 1982).
-
14
Criterios de decisin: Es la especificacin de un procedimiento
para identificar la mejor alternativa en un problema de decisin
(Moskowitz y Gordon, 1982). Los
tipos de criterios de decisin se muestran a continuacin:
Maximin: el criterio Maximin o criterio del pesimismo fue
sugerido por Abraham Wald, el cual indica que el tomador de
decisiones supone que una vez
que l ha elegido un curso de accin, la naturaleza sera
malevolente, con una
probabilidad implcita de uno, y por tanto seleccionara el evento
que
minimizara el pago del tomador de decisiones.
Maximax: el criterio Mximas u optimista, escoge el acto que es
el mejor de lo mejor. Esto es equivalente a elegir una accin cuya
mejor consecuencia sea tan
buena como la mejor consecuencia de cualquier otra accin.
Minimax: el criterio Minimax o pena o pesadumbre fue originado
por el notable estadstico Savage el cual sealaba que despus de que
se ha tomado una
decisin y de que ha ocurrido un evento, el tomador de decisin
puede
experimentar pesar debido a que conoce qu evento ha ocurrido y
desea quiz
haber seleccionado una accin diferente. Savage propuso que el
tomador de
decisiones deba intentar minimizar su pesar mximo. Este criterio
requiere el
desarrollo de una matriz de pesar o de prdida de oportunidad y
el uso del
Minimax para seleccionar una accin. El pesar se define como la
diferencia
entre el pago actual y el posible pago que se habra recibido si
se supiera el
evento que iba a ocurrir.
Hurwicz: el criterio de Hurwicz o del coeficiente de optimismo
fue creado por el econometrista Leonid Hurwicz, el cual propona que
si un tomador de
decisiones se senta optimista, ste deba poder expresar su grado
de optimismo.
Es de all donde nace el coeficiente de optimismo por el cual el
tomador de
-
15
decisiones los pagos ms grandes y pequeos y los pesa de acuerdo
con sus
propios sentimientos de optimismo y pesimismo.
Laplace: el criterio de Laplace o principio de razn insuficiente
proviene del marqus y matemtico de Laplace Pierre Simon, el cual
sugera que se asignara
a cada evento la misma probabilidad de ocurrencia, calcular el
pago (prdida)
esperado para cada acto y elegir el acto con el mayor (menor)
pago (prdida)
esperado. As, se tratara el problema como si tuviera una
distribucin de
probabilidad uniforme sobre los eventos y si los pagos fueran
expresados en
trminos de utilidad, se resolvera el problema encontrando la
accin que
maximiza la utilidad esperada.
Maximizacin del valor esperado: consiste en asignar una
probabilidad a cada evento de tal manera que las probabilidades
sumen 1. Posterior a esto se calcula
el valor esperado de cada accin, multiplicando cada valor por su
probabilidad
correspondiente y sumando estos valores para as elegir la opcin
que mayor
valor esperado posea.
Modelo racional de toma de decisiones: considera que el
comportamiento humano se construye con la idea que las personas
llevan a cabo clculos o
adaptaciones consistentes que maximizan el valor bajo ciertas
restricciones; es
decir, buscan la optimizacin. Una persona tiene metas u
objetivos y una
funcin de utilidad o preferencia que le permite clasificar todas
las posibles
acciones de acuerdo a la contribucin de estas a sus metas.
Finalmente la
persona selecciona la alternativa de valor ms alto en trminos de
las funciones
de retribucin. Supone informacin perfecta, metas claras y alta
capacidad
cognitiva (Gallagher y cols, 1982).
-
16
2.2 Marco metodolgico
2.2.1 Metodologa de la investigacin
Forma de investigacin: la forma de investigacin empleada para
resolver la problemtica descrita fue de tipo aplicada, debido a que
se bas en el estudio y
aplicacin de la investigacin a problemas especficos, en
circunstancias y
caractersticas especificas (Tamayo y Tamayo, 2001). Puesto que
el objetivo
primordial de este proyecto fue desarrollar una solucin
informtica para la
Superintendencia de GNO dirigida a la evaluacin de las
tecnologas de AIT
provistas a la Gerencia de Exploracin, se le puede clasificar de
este modo por
brindar solucin a un problema en forma rpida y directa.
Tipo de investigacin: esta investigacin es descriptiva, porque
busca alcanzar fines directos e inmediatos. Trabaja sobre
realidades de hechos y su caracterstica
fundamental es la de presentar una evaluacin e interpretacin
correcta de las
tecnologas usadas en la Gerencia de Exploracin (Tamayo y Tamayo,
2001).
Diseo de la investigacin: esta investigacin estuvo basada en un
diseo de campo porque los datos fueron recogidos directamente de la
realidad. Se aplicaron
tcnicas para la recoleccin de datos como entrevistas y
observacin directa que
permitieron obtener las necesidades de informacin del sistema.
Tambin
desempe un diseo bibliogrfico debido a que se utilizaron datos
que fueron
obtenidos por otros, llegando elaborados y procesados de acuerdo
a los fines de
quienes inicialmente los elaboraron (Tamayo y Tamayo, 2001).
Donde esta
informacin recogida en formatos, planillas y textos relacionados
con la
investigacin permiti el desarrollo de la misma.
-
17
Tcnicas para la recoleccin de datos: en la recoleccin de la
informacin necesaria para desarrollar este proyecto se realizaron
entrevistas no estructuradas a
los miembros pertenecientes a GNO con el fin de determinar los
requerimientos
funcionales y no funcionales del sistema a desarrollar. Adems se
aplicaron
tcnicas de observacin directa, consultas bibliogrficas y
consultas en Internet, lo
cual permiti fundamentar el aspecto terico de la investigacin
(Kendall y
Kendall, 2005).
2.2.2 Metodologa del rea aplicada
Para la elaboracin de este proyecto se utilizaron las
metodologas de el Proceso
Unificado de Desarrollo de Software planteado por Rumbaugh,
Jacobson y Booch
(1999) y la norma UNE 66175:2003 para la generacin y seleccin de
indicadores.
El Proceso Unificado de Desarrollo de Software es un proceso de
desarrollo de
software con un conjunto de actividades necesarias para
transformar los requisitos de un
usuario en un sistema de software. Sin embargo, el Proceso
Unificado es ms que un
simple proceso; es un marco de trabajo genrico que puede
especializarse para una gran
variedad de sistemas de software, diferentes reas de aplicacin,
tipos de organizaciones,
niveles de aptitud y tamaos de proyecto.
El Proceso Unificado est basado en componentes, lo cual quiere
decir que el
sistema software en construccin est formado por componentes de
software
interconectados a travs de interfaces bien definidas, el cual
hace uso de UML para
preparar todos los esquemas de un sistema software; resultando
ser una parte esencial
del Proceso Unificado.
Los verdaderos aspectos definitorios del Proceso Unificado se
resumen en tres
aspectos claves: dirigidos por casos de uso, centrados en la
arquitectura, iterativo e
incremental.
-
18
Dirigido por casos de uso: cuando un usuario utiliza un sistema,
se lleva a cabo una interaccin que consiste en una secuencia de
acciones (tanto por parte del
usuario como del sistema) que proporcionan al usuario un
resultado de valor
importante para l. Un caso de uso es precisamente una interaccin
de ese tipo,
que deriva en que el sistema debe incluir un fragmento de
funcionalidad para
proporcionar al usuario el resultado de valor esperado.
Centrado en la arquitectura: la arquitectura del software sirve
para poder contemplar el futuro sistema desde varios puntos de
vista antes de que se
construya y durante la construccin. El concepto de arquitectura
software incluye
los aspectos estticos y dinmicos ms significativos del sistema,
es decir,
especifica la forma, estructura y comportamiento del sistema
desde diversos
puntos de vista, todos ellos a un nivel de detalle que permita
tener una idea global,
clara, sin perderse en detalles insignificantes (que,
precisamente, no influyen en la
arquitectura del sistema). De esta forma quedan cubiertos dos
aspectos
fundamentales: Qu hace el sistema para cada usuario? (casos de
uso); Cmo es
el sistema y cmo funciona para realizar esos casos de uso?
(arquitectura
software).
Iterativo e incremental: para manejar el enorme esfuerzo
necesario al ejecutar un proyecto, ste se divide en mini-proyectos
llamados iteraciones. Cada iteracin del
proyecto (trabajo realizado) toma como entrada el producto
resultado de la
iteracin anterior y genera como salida un producto incrementado,
existiendo
incrementos de dos tipos:
Adicin de nuevos artefactos al producto: es decir, creacin o
ampliacin de los modelos (negocio, casos de uso, anlisis, diseo o
implementacin). Se ha
demostrado que los procesos en cascada no son efectivos a la
hora de construir
sistemas medianos/grandes, y que lo correcto es construir el
sistema por partes,
es decir, incrementalmente.
-
19
F lu jo d e tra b a jo s F u n d am e n ta les
F a se s
In ic io E la b o ra c i n C on s tru cc in T ra n s ic i n
R e qu is ito s
A n lis is
D ise o
Im p le m en ta c i n
P ru eb a s
Ite ra c io n e s
Ite r.# 1
Ite r.# 2
Ite r.# n -1
Ite r.# n--- --- --- --- ---
Sustitucin o modificacin de algn artefacto del producto: es
decir, modificacin de alguno de los modelos creados anteriormente.
Al final de una
iteracin, al realizar las pruebas, se pueden descubrir fallos
producidos por
artefactos defectuosos que debern ser revisados en la siguiente
iteracin. En
general, es posible que un modelo no est bien definido, siendo
necesario
revisar el trabajo hecho.
Vida del Proceso Unificado de Desarrollo de Software: el Proceso
Unificado se repite a lo largo de una serie de ciclos los cuales se
dividen en cuatro fases. A
travs de una secuencia de modelos, los implicados visualizan lo
que est
sucediendo en esas fases. Dentro de cada fase, los directores o
los desarrolladores
pueden descomponer adicionalmente el trabajo en iteraciones con
sus incrementos
resultantes. La columna izquierda representa los flujos de
trabajos: requisitos,
anlisis, diseo, implementacin y prueba. Las curvas son una
aproximacin de
hasta dnde se llevan a cabo los flujos de trabajo en cada fase,
como se muestra en
la figura 1.
Figura 1. Estructura del Proceso Unificado de Desarrollo de
Software.
-
20
Las fases de este proceso son las siguientes:
Fase de inicio: se desarroll una descripcin del producto final y
se present el anlisis de negocio para el producto. Se determin las
principales funciones del
sistema con un modelo de casos de uso simplificado que contiene
los casos de uso
ms crticos, la arquitectura del sistema que es un simple esbozo
con los
subsistemas ms importantes. Se identificaron y se priorizaron
los riesgos ms
importantes y se planific en detalle la fase de elaboracin.
Fase de elaboracin. se especific en detalle la mayora de los
casos de uso del producto y se dise la arquitectura del sistema.
Esta se expres en forma de vistas
de todos los modelos del sistema: modelo de caso de uso, de
anlisis, diseo,
implementacin. Se realiz los casos de uso ms crticos que se
identificaron en la
fase de inicio.
Fase de construccin. en esta fase, la lnea base de la
arquitectura creci hasta convertirse en el sistema completo. Al
final de esta fase, el producto contiene
todos los casos de uso que la direccin y el cliente acordaron.
Verificndose si el
producto cubri las necesidades de los usuarios de manera
suficiente como para
hacer una primera entrega.
La Iteracin genrica del Proceso Unificado de Desarrollo de
Software que incluye
los flujos fundamentales: requisitos, anlisis, diseo,
implementacin y pruebas no
ocurrieron una sola vez, como sucede tericamente en el modelo en
cascada; sino que se
repitieron en cada iteracin, una y otra vez, como flujos de
trabajos iterativos. Cada
repeticin, sin embargo, se diferenci en los detalles que se
enfrentaron o asuntos
centrales de cada iteracin. En la siguiente figura, se observa
como, para una iteracin
de cualquier fase, coexisten los cinco flujos de trabajos.
-
21
Figura 2. Flujos de trabajo requisitos, anlisis, diseo,
implementacin y prueba de una iteracin genrica en el Proceso
Unificado.
Para la seleccin de indicadores se utiliz la norma UNE
66175:2003, la cual
define las siguientes fases:
Fase 1. Diseo del indicador. 1.Seleccin del indicador.
Los miembros de la entidad propondrn los indicadores que
consideren
pertinentes atendiendo a todos los planes que afectan a la
entidad y los
procesos que desarrolla dicha entidad.
2. Denominacin del indicador.
Los requisitos que debe cumplir el nombre de un indicador son
brevedad,
claridad y coherencia con lo que se est midiendo. En cualquier
caso conviene
tener en cuenta que ya existen una serie de nombres estndar que
conviene
utilizar para mayor homogeneidad entre las distintas
entidades.
3. Forma de clculo. Especificacin y fuentes de informacin.
Todo indicador debe explicitar la fuente de informacin de la que
se nutre, la
forma concisa de clculo, el perodo y circunstancia en que se
toma el dato,
definir los conceptos que puedan interpretarse de distintas
formas y debern
conservarse las evidencias que avalen los datos.
Requisitos Anlisis Diseo Pruebas Implantacin
Iteracin Genrica
-
22
4. Definicin de responsabilidades.
Se debe designar a las personas responsables de recoger la
informacin, hacer
seguimiento del proceso de recogida, tratamiento de los datos y
transmisin de
los mismos a instancias superiores.
5. Definicin de umbrales.
Representa los valores mnimo o mximo, el valor a conseguir, la
consecucin
sucesiva de valores en el tiempo y los umbrales que se delimiten
deben ser
alcanzables.
Fase 2. Gestin del indicador: a travs de las herramientas que
los responsables, determinen como apropiadas para la gestin del
indicador, estos realizarn el
seguimiento, control y actualizacin del mismo de manera que
asegure la correcta
gestin del indicador en relacin con el objetivo o proceso que
gener su diseo.
Fase 3. Construccin del cuadro de mando: cada entidad tendr un
cuadro de mando conformado por los indicadores que se estimen
oportunos y que informen
el estado actual, de los datos histricos y de las previsiones al
respecto. Se
recomienda que el nmero de indicadores en el cuadro de mando se
ajuste lo
mximo posible a los resultados crticos de la actividad (objetivo
o proceso). Por
lo tanto se recomienda que su nmero oscile entre 5 y 10
indicadores en la medida
de lo posible. En otro caso habr que justificar tcnicamente la
sobredimensin del
cuadro de mando.
-
23
CAPTULO III.
DESARROLLO
3.1 Fase de inicio
En esta seccin se mostrarn los artefactos elaborados durante la
primera fase del
Proceso Unificado de Desarrollo de Software, llamada fase de
inicio, en donde se
establece el concepto inicial del sistema y se crea un esquema
general para su
comprensin, mediante la identificacin de sus funcionalidades y
requisitos; todo esto
con el fin de elaborar un conjunto de modelos iniciales que
capturen la semntica y
comportamiento del sistema asegurando que exista un
entendimiento comn entre los
desarrolladores y los usuarios. A continuacin se describen las
actividades y artefactos
producto de la implantacin de esta fase.
3.1.1 Planificacin de la fase de inicio
Para llevar a cabo esta fase se realiz un anlisis del sistema
tomando en cuenta
varios aspectos esenciales; en primer lugar, se estudi el
contexto en el cual se
desarrollan todas las actividades humanas relacionadas con el
tema de inters,
analizando todos los procesos y procedimientos involucrados; que
sern representados a
travs del modelo del negocio, y adems se cre un modelo del
dominio para
comprender el problema planteado en relacin a su contexto; en
segundo lugar, se
realiz una delimitacin del alcance del sistema propuesto, con el
propsito de
comprender qu deba cubrir la arquitectura y los lmites dentro de
los cuales se
buscaban los riesgos crticos para desarrollar una arquitectura
candidata con el fin de
asegurar el xito del sistema propuesto; en tercer lugar, se
capturaron los requisitos y se
describi la interaccin de los actores implicados en el sistema a
travs del diagrama de
casos de uso; una vez elaborados estos diagramas, se procedi a
modelarlos a travs de
los diagramas de clases de anlisis, como una especificacin
detallada de los requisitos y
-
24
como primera aproximacin al modelo de diseo; posteriormente, se
realizaron los
respectivos diagramas de colaboracin, para representar las
interacciones entre los
objetos del sistema y se construy el diagrama de paquetes de
anlisis para encapsular
los casos de usos que fueron definidos al realizar el anlisis
del sistema; finalmente se
concluye con la evaluacin de la fase estudiada.
Para este proyecto, en esta fase inicial, se realiz una nica
iteracin, conformada
por los flujos de trabajo requisitos y anlisis; presentados en
la tabla 1.
Tabla 1. Actividades y artefactos planificados para la fase de
inicio. Actividad Artefactos
Estudio del contexto del sistema.
Modelo del negocio.
Modelo del dominio.
Contexto del sistema
Glosario de trminos del modelo del dominio.
Riesgos del sistema Lista de riesgos crticos.
Requisitos funcionales y no funcionales.
Requisitos de software y hardware.
Captura de requisitos como casos de usos: identificacin de
actores
y casos de uso.
Modelo de casos de uso.
Requisitos
Descripcin de casos de uso.
Identificacin de clases de anlisis.
Diagrama de clases de anlisis.
Diagrama de colaboracin.
Anlisis
Identificacin de paquetes de anlisis.
A continuacin se procede a describir cada uno de los artefactos
planificados para
la fase de inicio.
-
25
3.1.2 Estudio del contexto del sistema
En el presente proyecto, se llev a cabo un estudio de las
actividades ms
importantes de GNO, con el fin de comprender los procesos de
negocio de mayor
relevancia dentro del rea de inters, y ofrecer una visin
representativa del contexto del
sistema. A continuacin se describen algunos trminos involucrados
en el contexto del
sistema:
3.1.2.1 Proceso GNO
En la figura 3, se puede observar el diagrama macro
interfuncional que representa
los eventos, actividades y resultados que se llevan a cabo
dentro del proceso GNO.
Figura 3. Esquema del proceso GNO. Eventos Actividades
Resultados
A continuacin se describen los eventos, actividades y resultados
involucrados en
el proceso GNO, as como los roles y responsabilidades asignados
para llevarlos a cabo.
DNO (Identificada, valorada y validada)
Portafolio de soluciones tecnol gicas integrales
Cat logo y acuerdos de servicios
Conformar equipo y planificar el
trabajo
Explorar procesos de negocio y
nuevas tecnolog as
Capturar y especificar
oportunidades y necesidades
necesidad
Modelo de proceso/negocio
Elementos comunes*
Necesidades y oportunidades
Revisar y registrarobjetivos y
descripci n del requerimiento
Cartera de nuevas tecnolog as y
mejores prcticas
Comunicaci n alusuario de estatus
de necesidad
*Incluye: Lineamientos. Plan tecnolgico. Inventario de activos.
Reporte de configuracin. Recursos humanos, financieros e
intelectuales
Valorar y validar /oportunidad con usuario
-
26
Eventos Necesidades y oportunidades: este evento se refiere a la
recepcin y/o deteccin
en GNO de una solicitud para satisfacer una necesidad y/u
oportunidad del
negocio/usuario. Algunas maneras como se pueden recibir
necesidades y
detectar oportunidades son por: formatos Ad Hoc (Solicitudes de
los usuarios e
involucrados), correo electrnico, reuniones, de otros procesos o
dentro del
mismo proceso. Las solicitudes recibidas y/o detectadas deben
ser analizadas y
detalladas por los profesionales de GNO para convertirlas en
requerimientos
validados y valorados, que sean posteriormente convertidos en
propuestas de
soluciones tecnolgicas integrales.
Portafolio de soluciones tecnolgicas integrales: contiene todas
las necesidades
y oportunidades detectadas, documentadas, validadas por el
usuario y
jerarquizadas por GNO, con el estatus y sus documentos
relacionados. La
oportunidad o necesidad identificada puede derivar en:
desarrollo de un
proyecto, plantear una investigacin, realizar un diagnstico de
cierre de
brechas, una evaluacin tecnolgica, realizar una asesora tcnica,
realizar una
recomendacin tcnica de mantenimiento u optimizacin de procesos.
A este
resultado tambin se le conoce como portafolio de necesidades
y
oportunidades.
Catlogo y acuerdos de servicios: estos eventos describen la
disponibilidad
tanto del catlogo de los servicios proporcionados a usuarios por
la Gerencia de
AIT, como de los acuerdos de niveles de servicio, que detallan
los niveles
operacionales y a los contratos con terceros, referidos a
servicios prestados a
usuarios. Son generados en la actividad generar y actualizar
acuerdos de
servicios.
-
27
Modelo de proceso-negocio: este evento describe la puesta a
disposicin del mapa de procesos del negocio y sus relaciones, as
como de modelos de negocio
existentes. Esta informacin es provista por Planificacin AIT o
por GNO de
modelos realizados previamente en la actividad de documentar
requerimiento.
Actividades Revisar y registrar objetivos y descripcin del
requerimiento: en esta actividad
se hace la captura inicial del requerimiento proveniente de los
usuarios de
cualquier proceso AIT. De esta actividad sale una versin
preliminar del
documento de necesidad y oportunidad, con la oportunidad
identificada; esta
contiene el objetivo de la solicitud, las expectativas de los
involucrados, el
propsito y la descripcin de la oportunidad.
Conformar equipo y planificar el trabajo: una vez que se tiene
el requerimiento capturado, descrito y validado con el usuario, se
pasa a conformar el equipo de
trabajo que continuar con las actividades siguientes en el flujo
de trabajo. La
conformacin de este equipo se efecta con base en los
conocimientos y
experiencia requerida para evaluar el requerimiento:
conocimiento del
negocio/funcin, tecnologa, disciplina, etc.
Explorar procesos de negocio y nuevas tecnologas: esta actividad
se realiza bien sea por requerimientos recibidos o por
oportunidades detectadas, teniendo
como objetivo explorar los procesos de negocio para
comprenderlos
claramente, determinar cules son sus factores crticos de xito y
apreciar las
eficiencias e ineficiencias actuales con el fin de determinar
con precisin en qu
parte de esos procesos debera aplicarse una solucin solicitada o
detectada. Y
explorar nuevas tecnologas de AIT que surjan en cualquier lugar
interno o
externo (universidades, centros de investigacin, industria,
etc.) a PDVSA y
que puedan representar oportunidades de mejora en sus procesos y
funciones.
-
28
Capturar y especificar necesidades y oportunidades: en esta
actividad se enriquece el documento de necesidades y oportunidades
preliminar elaborado
en la actividad de revisin y registro de objetivos. Se capturan
las
oportunidades ms viables y mejor adaptadas a la situacin
detectada o al
requerimiento recibido. Se especifica en mayor detalle la visin
de la necesidad
u oportunidad.
Valorar y validar necesidad /oportunidad con usuario: en esta
actividad se discuten y validan con el usuario los hallazgos y
conclusiones de las actividades
de exploracin de procesos del negocio y tecnologas, as como las
de captura y
especificacin realizadas. Se hace igualmente la valoracin de la
necesidad u
oportunidad en trminos de su posible aporte a disminuir costos o
generar
ingresos, si se trata de una oportunidad comercial.
Resultados DNO (identificada, valorada y validada): durante el
progreso de la actividad
identificar / atender necesidades y oportunidades, se construye
la primera
versin del documento de necesidades y oportunidades. Este
documento
contiene la descripcin de la necesidad u oportunidad que inicia
el proceso y
luego es transformada en un requerimiento.
Cartera de nuevas tecnologas y mejores prcticas: este documento
es producto de las evaluaciones e investigaciones realizadas por
GNO como parte de la
actividad de identificar / atender necesidades y oportunidades.
La
documentacin en la cartera de las nuevas tecnologas y mejores
prcticas en
automatizacin industrial, informtica y telecomunicaciones, debe
incluir al
menos su descripcin, reas de negocio o funcin de
aplicabilidad,
potencialidad de los beneficios, nivel de madurez, riesgos
potenciales, fecha de
validez, importancia y fuentes adicionales de referencia.
-
29
Comunicacin al usuario del estatus de la necesidad:
continuamente se realiza la comunicacin al usuario del estatus de
avance en la solucin a la necesidad,
la cual puede ser verbal, va telefnica, presencial o
escrita.
Roles y responsabilidades Consultor de negocio: est en relacin
constante con los usuarios, entendiendo
sus problemas y necesidades desde un alto nivel de abstraccin.
Es conocedor
de los procesos de negocio y de las tecnologas disponibles en
AIT. Atiende y
obtiene necesidades; lidera y coordina la exploracin, deteccin y
gestin de
necesidades y oportunidades hasta que la solucin tecnolgica,
informe o
recomendacin es entregada e implantada en el ambiente del
usuario.
Especialista en evaluacin de tecnologas: es el responsable de la
revisin y evaluacin de tecnologas disponibles en el mercado, esto
incluye la seleccin y
propuesta de infraestructuras tecnolgicas, herramientas, equipos
o cualquier
otro recurso tecnolgico, a fin de incorporarlas en las
propuestas, informes y
recomendaciones realizados por GNO. Este rol es responsable de
proveer
retroalimentacin apropiada sobre los productos a ser revisados
en el tiempo
especificado. Debe tambin realizar informes y recomendaciones de
asistencia
tcnica, asesora tecnolgica y redactar problemas de investigacin.
Es tambin
su responsabilidad la coordinacin y seguimiento de los procesos
de
introduccin, configuracin e identificacin del adiestramiento
sobre las
tecnologas seleccionadas.
Planificador: su principal objetivo es asegurar que los miembros
del equipo no tengan dificultades en hacer su trabajo. Es
responsable de adaptar el proceso
para que encaje con las necesidades especficas de propuestas,
informe y
recomendaciones, as como de educar y guiar a los miembros del
equipo en
temas relacionados al proceso.
-
30
3.1.2.2 Modelo del negocio
Para conseguir sus objetivos, una empresa organiza sus
actividades por medio de
un conjunto de procesos de negocio. Cada uno de ellos se
caracteriza por una coleccin
de datos que son producidos y manipulados mediante un conjunto
de tareas, en las que
ciertos agentes (por ejemplo, trabajadores o departamentos)
participan de acuerdo a un
flujo de trabajo determinado.
A continuacin en la figura 4, se muestra el modelo del negocio
que describe los
procesos generales asociados a la Superintendencia de GNO por
medio de su cadena de
valor, identificndose las actividades principales de Consultora
del Negocio y Gestin
Tecnolgica. Tambin las actividades secundarias de Planificacin y
Coordinacin. El
resultado de las responsabilidades de Consultora del Negocio
sirve de insumo a Gestin
Tecnolgica en la realizacin de sus actividades. A su vez Gestin
Tecnolgica da
respuesta a Consultora del Negocio de sus responsabilidades.
Figura 4. Modelo del negocio de la Superintendencia GNO.
Planificacin
Consultara del Negocio Gestin Tecnolgica
Roles Consultor del negocio. Responsabilidades - Entender el
negocio y las necesidades tecnolgicas de sus usuarios. - Obtener
las necesidades tecnolgicas de sus usuarios. - Detectar
oportunidades de desarrollo por medio de la exploracin de procesos
de negocio. - Valorar y validar necesidad u oportunidad con el
usuario. - Realizar el seguimiento de las soluciones tecnolgicas
implantadas. - Documentar los requerimientos atendidos. -
Participar en la presentacin al usuario de la propuesta de solucin
tecnolgica.
Roles Especialista en evaluaciones tecnolgicas.
Responsabilidades - Explorar procesos de negocio. - Desarrollar un
plan de administracin de requerimiento. - Planificar la exploracin
de necesidades y oportunidades. - Analizar las necesidades u
oportunidades del negocio. - Estudiar y documentar las soluciones
tecnolgicas de acuerdo a las necesidades u oportunidades atendidas.
- Administrar la cartera de tecnologas.
Coordinacin
-
31
3.1.2.3 Modelo del dominio
Un modelo del dominio es una representacin visual de las clases
conceptuales u
objetos del mundo real en un dominio de inters, donde se
capturan los objetos ms
importantes en el contexto del sistema realizado.
Los objetos del dominio representan las cosas que existen o los
eventos que
suceden en el entorno en el que trabaja el sistema. El objetivo
de este modelado es
comprender el contexto y los requerimientos del sistema
propuesto, es decir, entender el
problema que el sistema pretende resolver en relacin a su
contexto. Estos objetos se
relacionan a travs de asociaciones, agregaciones y composiciones
para modelar el
desenvolvimiento de las actividades; ayudando a definir qu deber
hacer el sistema
para resolver el problema y no cmo lo har.
En la figura 5 se observa cmo un analista GNO en su rol de
consultor atiende
necesidades expresadas por sus usuarios, los cuales son
empleados de la Gerencia de
Exploracin. Tambin estos pueden detectar oportunidades de
investigacin que
provengan de la exploracin o estudio de los planes de negocio de
la gerencia. Esta
gerencia se encuentra compuesta por procesos de negocio, los
cuales se encuentran
apoyados o utilizan tecnologas para el cumplimiento efectivo de
sus procedimientos.
Un analista GNO en su rol de analista tecnolgico realiza
evaluaciones
tecnolgicas, las cuales requieren de informacin de tecnologas y
de indicadores. Los
indicadores son los encargados de cuantificar las variables que
describan el
comportamiento de las tecnologas objeto de estudio, con el fin
de determinar el
cumplimiento del objetivo que persiga la evaluacin. Para as
encontrar las soluciones o
alternativas adecuadas a ser propuesta a la gerencia con el
objetivo de cumplir con los
requerimientos establecidos.
-
32
Figura 5. Modelo del dominio.
A continuacin en la tabla 3 se presenta una lista de trminos
empleados en el
dominio del sistema de evaluacin de tecnologas propuesto, donde
se definen cada una
de las entidades involucradas en el modelo anteriormente
mostrado.
-
33
Tabla 2. Glosario de trminos del modelo del dominio del sistema
propuesto. Trmino Definicin GNO
Se encarga de capturar y analizar las necesidades y
oportunidades de
soluciones de automatizacin, informtica y telecomunicaciones de
PDVSA,
adems de determinar, revisar, aprobar y controlar las propuestas
de
soluciones tecnolgicas nuevas o existentes.
Analista Consultor Personal que atiende a los usuarios de la
Gerencia de Exploracin con el fin
de proveerles soluciones tecnolgicas.
Analista Tecnolgico
Personal encargado de investigar las soluciones tecnolgicas.
Gerencia de
Exploracin
Ente u organizacin que es atendida por GNO.
Procesos Son elementos de la cadena de valor o procesos
medulares que hacen que
exista la Gerencia de Exploracin.
Evaluaciones
Tecnolgicas
Procedimiento llevado a cabo por el analista tecnolgico de GNO,
para
evaluar soluciones tecnolgicas ante los requerimientos de sus
usuarios.
Indicador ndices o parmetros a medir ante una evaluacin
tecnolgica con el fin de
determinar su valor para cada solucin a evaluar y as conocer su
situacin en
el tiempo.
Variables Magnitud indeterminada que cambia por diversos
factores y que representa
por tanto diversos valores en el tiempo.
Frmula Expresin matemtica con variables y parmetros.
Tecnologas Se refiere a software, hardware o cualquier
herramienta tecnolgica de
inters.
Mtodo de decisin Son los criterios usados para seleccionar una
alternativa de solucin en la
evaluacin tecnolgica.
-
34
Tabla 3. Continuacin. Trmino Definicin
Usuario Empleado de la Gerencia de Exploracin a quien se atiende
y suministra
toda la informacin necesaria para el levantamiento del
requerimiento de la
necesidad u oportunidad.
Oportunidad Es la carencia tecnolgica identificada o detectada
por GNO en los procesos
de trabajo de sus usuarios.
Necesidad Es la carencia manifestada por un usuario para cumplir
o alcanzar un
objetivo determinado.
Objetivo
Propsito o intencin que persigue la evaluacin tecnolgica.
Solucin Tecnolgica Es la respuesta o alternativa de solucin
expresada por GNO a sus usuarios.
Planes de Negocio Es la accin de estudiar y analizar a detalle
los procesos, planes y
estrategias, que se efectan en la gerencia cliente.
3.1.2.4 Riesgos del sistema
Un riesgo es una variable del proyecto que pone en peligro o
impide el xito del
proyecto. Es la probabilidad de que un proyecto experimente
sucesos no deseables.
Los riesgos dirigen la viabilidad del sistema en el Proceso
Unificado de Desarrollo
de Software; ya que existe la probabilidad de que el proyecto se
vea afectado en su
desarrollo o comportamiento futuro. En tal sentido, los riesgos
deben ser ordenados por
el nivel de relevancia o por su influencia en el desarrollo.
Una vez que se han identificado los riesgos, pueden ser tratados
de diferentes
maneras. Algunos pueden ser evitados llevando a cabo acciones
como replanificar el
proyecto, pueden ser tambin evitados haciendo cambios en los
requisitos, otros podran
-
35
ser detectados y aislados de otras partes del proyecto, a manera
de afectar solo una
parte.
Riesgos crticos del sistema Desconocimiento del mbito del
sistema: el no conocer el mbito del sistema en
base al cual se est trabajando, significa un riesgo crtico que
debe ser mitigado
en la fase de inicio. El diseador debe tener conocimiento del
contexto y
entender sus aspectos fundamentales.
Requisitos mal definidos: no disponer de requisitos claros y que
abarquen todas las necesidades de los usuarios, puede significar un
riesgo para el
sistema. Se deben recolectar todas las necesidades de los
usuarios.
Falta de robustez de la arquitectura: el sistema debe poseer una
arquitectura robusta que le permita adaptarse a los cambios y al
mantenimiento de manera
elegante y poco traumtica.
Diseo no adecuado de la base de datos: el mal diseo de la base
de datos es un riesgo crtico, la base de datos del sistema debe
estar diseada de tal manera
que mantenga la integridad referencial, que no sea redundante y
que garantice
el acceso a los datos necesarios, permitiendo al sistema llevar
a cabo sus
funciones.
Para los riesgos que resultaron identificados en el desarrollo
de la aplicacin Web,
se plante un plan de prevencin como forma de evitar los posibles
inconvenientes que
se pudieran presentar en el desarrollo de la aplicacin Web y un
plan de contingencia
para actuar en el caso de que surgiesen dichos inconveniente,
los cuales se ven
enunciados en la tabla 4.
-
36
Tabla 4. . Plan de prevencin y contingencia para los riesgos ms
predominantes en el desarrollo de la aplicacin Web.
Riesgos Probabilidad Impacto Plan de Prevencin Plan de
Contingencia
Desconocimiento del
mbito del sistema.
60% Crtico Aplicar un exhaustivo
levantamiento de
informacin y
detallado modelado del
sistema.
Chequear los
diagramas
realizados y
aplicar las
correcciones
pertinentes.
Requisitos mal
definidos.
40% Crtico Interactuar
constantemente con los
usuarios del sistema en
todas las fases de
desarrollo.
Aplicar
entrevistas no
estructuradas
para aclarar
dudas en los
requerimient