-
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