Está en la página 1de 140

UNIVERSIDAD SIMN BOLVAR

DECANATO DE ESTUDIOS DE POSTGRADO


COORDINACIN DE POSTGRADOS EN GERENCIA
ESPECIALIZACIN EN GERENCIA DE PROYECTOS

TRABAJO ESPECIAL DE GRADO

GESTIN DE PROYECTOS DE TECNOLOGAS DE INFORMACIN EN


LA GERENCIA DIS

por

LINA TITANIA ARIAS MORENO

Octubre de 2009

UNIVERSIDAD SIMN BOLVAR


DECANATO DE ESTUDIOS DE POSTGRADO
COORDINACIN DE POSTGRADOS EN GERENCIA
ESPECIALIZACIN EN GERENCIA DE PROYECTOS

GESTIN DE PROYECTOS DE TECNOLOGAS DE INFORMACIN EN


LA GERENCIA DIS

Trabajo Especial de Grado


presentado a la Universidad Simn Bolvar por
LINA TITANIA ARIAS MORENO

como requisito parcial


para optar al grado acadmico de
Especialista en Gerencia de Proyectos
Realizado con la tutora de la Magister Scientiarum
JOSSELYN AVILA

Octubre de 2009

UNIVERSIDAD SIMN BOLVAR


DECANATO DE ESTUDIOS DE POSTGRADO
COORDINACIN DE POSTGRADOS EN GERENCIA
ESPECIALIZACIN EN GERENCIA DE PROYECTOS

GESTIN DE PROYECTOS DE TECNOLOGAS DE INFORMACIN EN


LA GERENCIA DIS
Por: Lina Titania Arias Moreno
Carnet No.: 0786152

Este Trabajo Especial de Grado ha sido aprobado en nombre de la


Universidad Simn Bolvar por el siguiente jurado examinador:

Jurado
Andrs Loriente

Tutora
Josselyn vila (PDVSA)

28 de octubre de 2009

UNIVERSIDAD SIMN BOLVAR


DECANATO DE ESTUDIOS DE POSTGRADO
COORDINACIN DE POSTGRADOS EN GERENCIA
ESPECIALIZACIN EN GERENCIA DE PROYECTOS

GESTIN DE PROYECTOS DE TECNOLOGAS DE INFORMACIN EN


LA GERENCIA DIS
Por: Lina Titania Arias Moreno
Carnet No.: 0786152
Tutora: Josselyn vila
Fecha: octubre de 2009
RESUMEN
El propsito del presente trabajo fue apoyar la gestin de proyectos de Automatizacin,
Informtica y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e Implantacin de
Soluciones (DIS) de PDVSA, para esto se dise una Metodologa de Gestin de
Proyectos de Tecnologa de Informacin (TI), basada en las Guas de Gerencia para
Proyectos de Inversin de Capital (GGPIC), estndar de la corporacin.
En primer lugar se realiz un anlisis de la situacin actual para identificar la aplicabilidad
de las GGPIC, en los proyectos de Tecnologa de Informacin. Posteriormente, y en base
a las mejores prcticas de metodologas propias para la ejecucin de proyectos de TI
como los son RUP y UML, en conjunto con las fortalezas de las GGPIC, se elabor la
propuesta de diseo de una nueva metodologa para ser usada en la Gerencia (DIS)
facilitando el trabajo de los lderes, responsables por la gestin de los proyectos de
Tecnologas de Informacin.
La propuesta fue validada y recibida de forma muy positiva por la Coordinacin de
Metodologas de DIS por lo cual se puede decir que se gener como resultado una
metodologa para la gestin de proyectos de TI, mucho ms completa y acorde a la
realidad de este tipo de proyectos debido a la incorporacin de todos los elementos
tcnicos necesarios para lograr una definicin adecuada de los mismos, que permiten a su
vez su correcto desarrollo y puesta en marcha, as como tambin fueron incluidas las
actividades, mas all de las propiamente tcnicas, sino de procesos que hay que cumplir,
donde se interacta con otras organizaciones de AIT y de PDVSA, constituyendo esto una
herramienta muy til para los lderes de proyecto y para la organizacin de Desarrollo e
Implantacin de Soluciones, apalancando a su vez la misin de AIT.

Palabras clave: Gestin de Proyectos, Tecnologa de Informacin, Metodologa de Gestin


de Proyectos de Tecnologa de Informacin, Proyectos

INDICE

INTRODUCCIN ....................................................................................................................1
CAPITULO I ............................................................................................................................3
EL PROYECTO DE TRABAJO ESPECIAL DE GRADO .....................................................3
1.1.

JUSTIFICACION.................................................................................................................................... 3

1.2. OBJETIVOS DEL ESTUDIO.................................................................................................................. 4


1.2.1. General ........................................................................................................................................... 5
1.2.2. Especficos...................................................................................................................................... 5
1.3. METODOLOGA .................................................................................................................................... 5
1.3.1. Elaboracin de un Marco Conceptual Referencial .......................................................................... 5
1.3.2. Presentar el Marco Organizacional ................................................................................................. 6
1.3.3. Elaboracin del Examen de la Situacin ......................................................................................... 6
1.3.4. Elaboracin de la Propuesta ........................................................................................................... 6
1.3.5. Evaluacin de la Propuesta Elaborada ........................................................................................... 7
1.3.6. Evaluacin del Proceso General cumplido...................................................................................... 7
1.4.

CRONOGRAMA DE EJECUCION......................................................................................................... 7

2.

CAPITULO II ..................................................................................................................8

MARCO CONCEPTUAL REFERENCIAL ..............................................................................8


2.1.

PROYECTO........................................................................................................................................... 8

2.2.

GESTIN DE PROYECTOS................................................................................................................ 10

2.3. TECNOLOGA DE INFORMACIN (TI) .............................................................................................. 13


2.3.1. Tecnologa de Informacin en la Empresa.................................................................................... 14
2.4.

GESTIN DE PROYECTOS DE TI...................................................................................................... 15

2.5. GUAS DE GERENCIA PARA PROYECTOS DE INVERSIN DE CAPITAL (GGPIC): ..................... 16


2.5.1. Objetivo de las GGPIC.................................................................................................................. 17
2.5.2. Ciclo de Vida de Proyectos Segn las GGPIC .............................................................................. 17
2.5.3. Fases del Ciclo de Vida de Proyectos........................................................................................... 18
2.5.3.1.
Visualizar ............................................................................................................................... 18
2.5.3.2.
Conceptualizar ....................................................................................................................... 19
2.5.3.3.
Definir .................................................................................................................................... 19
2.5.3.4.
Implantar................................................................................................................................ 20
2.5.3.5.
Operar.................................................................................................................................... 21

2.6. TECNOLOGA DE OBJETOS ............................................................................................................. 21


2.6.1. Una Perspectiva Histrica ............................................................................................................. 22
2.6.2. Fortalezas de la Tecnologa Orientada a Objetos ......................................................................... 23
2.6.3. Anlisis y Diseo Orientado a Objetos .......................................................................................... 23
2.7. LENGUAJE DE MODELADO UNIFICADO (UML) .............................................................................. 24
2.7.1. Descripcin del Lenguaje.............................................................................................................. 24
2.7.2. Descripcin de los Diagramas....................................................................................................... 25
2.7.2.1.
Diagrama de Casos de Uso ................................................................................................... 26
2.7.2.2.
Diagrama de Clases .............................................................................................................. 26
2.7.2.3.
Diagrama de Objetos ............................................................................................................. 26
2.7.2.4.
Diagramas de Comportamiento ............................................................................................. 26
2.7.2.5.
Diagramas de implementacin............................................................................................... 27
2.8. PROCESO UNIFICADO RATIONAL (RUP) ........................................................................................ 27
2.8.1. Dimensin 1: Fases del ciclo de vida RUP.................................................................................... 29
2.8.1.1.
Inicio ...................................................................................................................................... 29
2.8.1.2.
Preparacin ........................................................................................................................... 30
2.8.1.3.
Construccin.......................................................................................................................... 30
2.8.1.4.
Transicin .............................................................................................................................. 30
2.8.2. Dimensin 2: Disciplinas ............................................................................................................... 31
2.8.2.1.
Modelado del Negocio ........................................................................................................... 31
2.8.2.2.
Requerimientos...................................................................................................................... 32
2.8.2.3.
Anlisis y Diseo.................................................................................................................... 32
2.8.2.4.
Implementacin...................................................................................................................... 32
2.8.2.5.
Pruebas ................................................................................................................................. 32
2.8.2.6.
Despliegue............................................................................................................................. 33
2.8.2.7.
Gestin y Configuracin de Cambios..................................................................................... 33
2.8.2.8.
Gestin del Proyecto.............................................................................................................. 33
2.8.2.9.
Entorno .................................................................................................................................. 34

3.

CAPTULO III .............................................................................................................. 35

MARCO ORGANIZACIONAL.............................................................................................. 35
3.1. PETRLEOS DE VENEZUELA (PDVSA) ........................................................................................... 35
3.1.1. Descripcin Ampliada de la Empresa............................................................................................ 35
3.1.2. El Plan Siembra Petrolera (PSP) 2005-2030 ................................................................................ 39
3.1.2.1.
Magna Reserva...................................................................................................................... 39
3.1.2.2.
Proyecto Orinoco ................................................................................................................... 39
3.1.2.3.
Proyecto Delta-Caribe............................................................................................................ 40
3.1.2.4.
Refinacin.............................................................................................................................. 40
3.1.2.5.
Infraestructura........................................................................................................................ 40
3.1.2.6.
Integracin ............................................................................................................................. 40
3.2. AUTOMATIZACIN, INFORMTICA Y TELECOMUNICACIONES (AIT) .......................................... 41
3.2.1. Breve Histrico.............................................................................................................................. 41
3.2.2. Visin ............................................................................................................................................ 42
3.2.3. Misin ........................................................................................................................................... 42
3.2.4. Objetivos Estratgicos .................................................................................................................. 42
3.3. DESARROLLO E IMPLANTACIN DE SOLUCIONES (DIS)............................................................. 44
3.3.1. Objetivo......................................................................................................................................... 44
3.3.2. Alcance ......................................................................................................................................... 44
3.3.3. Premisas ....................................................................................................................................... 45
3.3.4. Diagrama Macro Interfuncional del Proceso ................................................................................. 45

4.

CAPTULO IV.............................................................................................................. 47

EXAMEN DE LA SITUACIN ............................................................................................. 47


4.1.

OBJETIVO DEL PROCESO ................................................................................................................ 47

4.2.

PLANIFICACIN DEL PROCESO ...................................................................................................... 47

4.3.

EJECUCIN DEL EXAMEN DE LA SITUACIN................................................................................ 48

4.4.

RESULTADOS DEL EXAMEN DE LA SITUACIN ............................................................................ 51

4.5.

CONCLUSIONES DEL EXAMEN DE LA SITUACIN........................................................................ 51

5.

CAPTULO V............................................................................................................... 53

PROPUESTA DE METODOLOGA DE GESTIN DE PROYECTOS DE TECNOLOGA


DE INFORMACIN EN LA GERENCIA DIS ...................................................................... 53
5.1.

JUSTIFICACIN DE LA PROPUESTA ............................................................................................... 53

5.2.

OBJETIVO DE LA PROPUESTA ........................................................................................................ 54

5.3.

PROCESO PARA REALIZAR LA PROPUESTA ................................................................................ 54

5.4. LA PROPUESTA: METODOLOGA DE GESTIN DE PROYECTOS DE TECNOLOGA DE


INFORMACIN .............................................................................................................................................. 55
5.4.1. Fase Visualizar ............................................................................................................................. 56
5.4.1.1.
Identificar Responsables de los Procesos de Negocio........................................................... 56
5.4.1.2.
Elaborar Plantilla de Datos Bsicos ....................................................................................... 56
5.4.1.3.
Definir el Equipo de Trabajo de la Fase Visualizar................................................................. 57
5.4.1.4.
Obtener / Elaborar Documento de Proceso de Negocio ........................................................ 57
5.4.1.5.
Desarrollo del Documento de Soporte de Decisin 1 (DSD1) ................................................ 57
5.4.1.6.
Entrega de DSD1................................................................................................................... 70
5.4.2. Fase Conceptualizar ..................................................................................................................... 70
5.4.2.1.
Conformar Equipo de Trabajo................................................................................................ 70
5.4.2.2.
Desarrollo del DSD2 .............................................................................................................. 70
5.4.2.3.
Entrega de DSD2................................................................................................................... 81
5.4.3. Fase Definir................................................................................................................................... 82
5.4.3.1.
Conformar Equipo de Trabajo................................................................................................ 82
5.4.3.2.
Desarrollo del DSD3 .............................................................................................................. 82
5.4.3.3.
Entrega de DSD3................................................................................................................... 92
5.4.4. Fase Implantar .............................................................................................................................. 92
5.4.4.1.
Proceso de Contratacin........................................................................................................ 92
5.4.4.2.
Elaborar PEP Clase I ............................................................................................................. 94
5.4.4.3.
Verificar PEP del Contratista.................................................................................................. 94
5.4.4.4.
Conformar Equipo de Trabajo................................................................................................ 95
5.4.4.5.
Desarrollo del DSD4 .............................................................................................................. 96
5.4.4.6.
Entrega de DSD4................................................................................................................. 102
5.4.5. Fase Operar................................................................................................................................ 102
5.4.5.1.
Colocar en Operacin el Ambiente de Produccin............................................................... 102
5.4.5.2.
Crear estructura de la solucin ............................................................................................ 103
5.4.5.3.
Completar Plan de Contingencia.......................................................................................... 103
5.4.5.4.
Realizar adiestramiento a Gestin del Servicio (GDS)......................................................... 103
5.4.5.5.
Realizar Control de Cambio 1. ............................................................................................. 103
5.4.5.6.
Realizar Control de Cambio 2 .............................................................................................. 104
5.4.5.7.
Aceptacin de Instalaciones ................................................................................................ 105
5.4.5.8.
Elaboracin de Informes Finales......................................................................................... 105

6.

CAPTULO VI............................................................................................................ 106

EVALUACIN DE LA PROPUESTA ................................................................................ 106


6.2.

RESULTADOS RELEVANTES.......................................................................................................... 106

6.3.

VIABILIDAD DE IMPLANTACIN DE LA PROPUESTA.................................................................. 107

6.4.

CUMPLIMIENTO DEL CRONOGRAMA............................................................................................ 107

6.5.

LOGRO DE LOS OBJETIVOS .......................................................................................................... 107

7.

CAPTULO VII........................................................................................................... 109

CONCLUSIONES Y RECOMENDACIONES .................................................................... 109


7.1.

CONCLUSIONES .............................................................................................................................. 109

7.2.

RECOMENDACIONES ...................................................................................................................... 110

8.

ANEXOS ................................................................................................................... 114

Anexo N 1: Clasificacin de Estimados de Costo .................................................................................. 115


Anexo N 2: Plantilla de Datos Bsicos .................................................................................................... 116
Anexo N 3: Levantamiento del Proceso del Negocio. ............................................................................ 117
Anexo N 4: Gastos de Conceptualizacin ............................................................................................... 128
Anexo N 5: Planilla para solicitar recursos a MAP ................................................................................. 129

INDICE DE TABLAS
Tabla 1 Cronograma de Ejecucin del Proyecto
Tabla 2 Esfuerzo vs. Fases RUP
Tabla 3 Aplicabilidad de las GGPIC en Proyectos de TI
Tabla 4 Atributos de Priorizacin
Tabla 5 Valores de Atributos para Prioridad del Cliente
Tabla 6 Valores de Atributos para Complejidad
Tabla 7 Valores de Atributos para Esfuerzo
Tabla 8 Valores de Atributos para Estabilidad
Tabla 9 Ejemplo de Caractersticas Generales de la Solucin TI
Tabla 10 Identificacin de Servicios
Tabla 11 Identificacin de Intercambio de Datos
Tabla 12 Especificacin de Servicios
Tabla 13 Especificacin de Funcionalidad de Servicios
Tabla 14 Contenido de un Contrato de Servicios
Tabla 15 Descripcin de Actores
Tabla 16 Especificacin de Casos de Uso
Tabla 17 Requerimientos de Informacin
Tabla 18 Requerimientos No Funcionales
Tabla 19 Prueba de Aceptacin
Tabla 20 Plan de Desembolsos por Productos

INDICE DE FIGURAS
Fig. 1 La Triple restriccin................................................................................................................................. 9
Fig. 2 Ciclo de Vida de Proyectos segn las GGPIC ...................................................................................... 17
Fig. 3 Fase Visualizar ..................................................................................................................................... 18
Fig. 4 Fase Conceptualizar ............................................................................................................................. 19
Fig. 5 Fase Definir .......................................................................................................................................... 20
Fig. 6 Fase Implantar ...................................................................................................................................... 20
Fig. 7 Fase Operar.......................................................................................................................................... 21
Fig. 8 Programacin Tradicional ..................................................................................................................... 22
Fig. 9 Partes de un Modelo UML .................................................................................................................... 26
Fig. 10 Proceso Unificado Rational................................................................................................................. 28
Fig. 11 Tiempo y Esfuerzo vs. Fases de RUP ................................................................................................ 31
Fig. 12 Modelo de Procesos AIT..................................................................................................................... 42
Fig. 13 Diagrama Macro Interfuncional del Proceso DIS ................................................................................ 46
Fig. 14 Fases GGPIC vs. Fases RUP............................................................................................................. 55
Fig. 15 El Proceso de la Toma de Decisin .................................................................................................... 58
Fig. 16 Diagrama de Secuencia...................................................................................................................... 65
Fig. 17 Modelo de Casos de Uso.................................................................................................................... 75
Fig. 18 Ejemplo Diseo de Arquitectura.......................................................................................................... 84
Fig. 19 Ejemplo de Diagrama de Clase .......................................................................................................... 86
Fig. 20 Ejemplo Modelo E-R ........................................................................................................................... 87
Fig. 21 Contenido Tpico de un DSO .............................................................................................................. 92

INTRODUCCIN
La gerencia de proyectos data de hace mas de 4.000 aos, donde de manera emprica o,
si se puede decir, informal, se aplic en la construccin de grandes obras como lo fueron
las pirmides de Egipto; pero es solo hace poco mas de 50 aos, cuando la gerencia de
proyectos surge como ciencia y se le ha dado la importancia que amerita en la
consecucin de objetivos cuando se tiene un tiempo, un costo y un alcance claramente
definidos, con una calidad especificada, es decir, cuando la actividad debe acometerse
como un proyecto.

Petrleos de Venezuela (PDVSA), especficamente la gerencia de Automatizacin,


Informtica y Telecomunicaciones (AIT), no es la excepcin cuando se afirma que a los
proyectos hoy en da se les ha dado la importancia que requieren, razn por la cual fue
creada la organizacin Desarrollo e Implantacin de Soluciones (DIS), cuyo principal
objetivo es definir e implantar soluciones integrales eficientes y eficaces en trminos de
costo y oportunidad, principalmente del rea de Tecnologa de Informacin (TI).

La gestin de proyectos de TI ha tenido tropiezos en parte reflejados en los resultados de


los proyectos que se han ejecutado, y esto se debe, entre otras cosas, a la carencia de
una metodologa de proyectos propia para el caso de Tecnologa de Informacin, aunque
se cuenta con el estndar de PDVSA denominado Guas de Gerencia para Proyectos de
Inversin de Capital, este fue ideado en sus orgenes para proyectos mayores de
ingeniera y construccin.

Con el presente Trabajo Especial de Grado (TEG) se pretende disear una metodologa
de gestin de proyectos de Tecnologa de Informacin, que apoye la gestin de la
organizacin Desarrollo e Implantacin de Soluciones, incorporando todos los elementos
tcnicos y de procesos necesarios para complementar las GGPIC, de forma tal que sea
considerada como una herramienta til a ser implantada con el fin de mejorar los

resultados de la ejecucin de los proyectos.

El Trabajo Especial de Grado se despliega en tres fases definidas de la siguiente manera:

Fase de Planificacin: est compuesta por el captulo I donde se aprecia como fue
planificado el proyecto de TEG, su justificacin, objetivos de estudio, metodologas para
elaborar el marco conceptual, marco organizacional, examen de la situacin, elaboracin
de la propuesta, evaluacin de la misma y del proceso general cumplido, as como el
cronograma de ejecucin.

Fase de Ejecucin: esta fase presenta el captulo II, marco conceptual referencial donde
se encuentran los fundamentos conceptuales pertinentes al caso de estudio; el captulo III
que contiene el marco organizacional, lo cual permite conocer el mbito donde se aplicar
la propuesta del TEG; el captulo IV que permite observar como se llevar a cabo el
examen de la situacin, destacando el objetivo del proceso, su planificacin, ejecucin,
resultados y conclusiones de dicho examen; el captulo V donde destaca la propuesta del
TEG, su justificacin, objetivo, proceso de elaboracin, para finalmente concluir con la
propuesta.

Fase de Evaluacin: cuenta con el captulo VI de evaluacin de la propuesta, lo cual


incluye los resultados relevantes, la viabilidad de implantacin de la propuesta, la revisin
del cumplimiento del cronograma de ejecucin y la evaluacin del logro de los objetivos.
Por ltimo, el TEG cierra con el captulo VII donde se reflejan las conclusiones y
recomendaciones.

CAPITULO I
El PROYECTO DE TRABAJO ESPECIAL DE GRADO
En las pginas siguientes se expone el Proyecto de Trabajo Especial de Grado presentado
a las instancias correspondientes. Se expone la justificacin, los objetivos, la metodologa
establecida, concluyendo con el cronograma de ejecucin.

1.1.

JUSTIFICACION

Un proyecto consiste en una combinacin de recursos organizacionales integrados para


crear algo que no exista antes, y eso proporcionar una mejor capacidad de desempeo
en el diseo y ejecucin de las estrategias organizacionales (Cleland y Ireland, 2001, p.
12). La gestin de proyectos es la disciplina de organizar y administrar recursos de
manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del
alcance, el tiempo, y coste definidos (http://es.wikipedia.org/wiki/Gestin_de_proyectos,
consultado el 14/04/2009).

Petrleos de Venezuela (PDVSA) es la corporacin estatal de la Repblica Bolivariana de


Venezuela que se encarga de la exploracin, produccin, manufactura, transporte y
mercadeo de los hidrocarburos, de manera eficiente, rentable, segura, transparente y
comprometida con la proteccin ambiental. (http://www.pdvsa.com/, consultado el 14-042009).

Automatizacin, Informtica y Telecomunicaciones (AIT) es la organizacin que rige,


provee y mantiene los servicios y soluciones integrales de tecnologas de automatizacin,
informacin y comunicaciones de la corporacin (Planificacin AIT, 2007).

La Gerencia Desarrollo e Implantacin de Soluciones (DIS) debe cumplir la importante


funcin de definir e implantar soluciones integrales de AIT eficientes y eficaces en trminos

de costo y oportunidad para satisfacer necesidades de PDVSA y la Nacin, que


apalanquen las metas y objetivos de PDVSA cumpliendo con lineamientos, estndares y
normas nacionales e internacionales adoptadas por la Corporacin

(Gestin y

Mejoramiento de Procesos, 2007), por esta razn es de vital importancia contar con una
metodologa de Gestin de Proyectos que apoye esta funcin de manera eficaz.

El lineamiento corporativo indica que AIT debe usar para la Gestin de Proyectos la Gua
de Gerencia para Proyectos de Inversin de Capital (GGPIC), esta gua fue diseada por
un grupo de ingenieros de PDVSA en 1999, y, aunque son adaptables a varios tipos de
proyectos, fueron creadas principalmente desde la perspectiva de proyectos de Ingeniera
y Construccin.

Pareciera entonces que la Gerencia DIS no contara con la metodologa apropiada para la
Gestin de Proyectos del rea de su competencia, es decir, de Tecnologa de Informacin
(TI).

En ese contexto, surgi la necesidad de contar con una metodologa de Gestin de


Proyectos de TI, basada en las GGPIC, que son el estndar de PDVSA, validando su
aplicabilidad y adaptndola con los complementos necesarios de manera de que se
generara una metodologa que realmente sirviera de apoyo a la gerencia DIS en la gestin
de sus proyectos.

Con el presente Trabajo Especial de Grado se dise una metodologa de gestin de


proyectos basada en las GGPIC, adaptada segn las necesidades de la gestin de
proyectos de TI, que sirve de referencia para los lderes de proyecto que trabajan en la
gerencia DIS, en el cumplimiento de su funcin de lograr los objetivos de los proyectos
desde sus tres aristas principales como lo son tiempo, costo y calidad.

1.2.

OBJETIVOS DEL ESTUDIO

En ese contexto, como objetivos del Proyecto de Trabajo Especial de Grado se formularon
los siguientes:

1.2.1.

General

Apoyar la gestin de proyectos de Automatizacin, Informtica y Telecomunicaciones


(AIT), en la Gerencia de Desarrollo e implantacin de Soluciones (DIS) de PDVSA;
mediante el diseo de una Metodologa de Gestin de Proyectos de Tecnologa de
Informacin, basada en las Guas de Gerencia para Proyectos de Inversin de Capital
(GGPIC) de PDVSA.

1.2.2.

Especficos

Analizar el potencial de uso de las Guas de Gerencia de Proyectos de Inversin de


Capital,

GGPIC,

para

proyectos

de

Automatizacin,

Informtica

Telecomunicaciones convalidando el real grado de aplicabilidad de las mismas


frente a las caractersticas y estrategias de desarrollo de los proyectos de AIT y
ante la organizacin actual basada en procesos.

Elaborar una propuesta de Metodologa de Gestin de Proyectos de Tecnologa de


Informacin aprovechando la aplicabilidad de las GGPIC, incorporando las
adaptaciones necesarias para manejar proyectos de AIT.

Validar la aplicabilidad de la propuesta con la Coordinacin de Metodologas de la


Gerencia de Desarrollo e Implantacin de Soluciones para implantarla como parte
de este proceso en la gestin de los proyectos de AIT.

1.3.

METODOLOGA

Para el logro de los objetivos propuestos se estableci cumplir los siguientes pasos:

1.3.1.

Elaboracin de un Marco Conceptual Referencial

Inicialmente se expondran los conceptos bsicos del ciclo de vida de los proyectos de
acuerdo a las Guas de Gerencia para Proyectos de Inversin de Capital (GGPIC)
(PDVSA, 1999). Luego, utilizando las referencias bibliogrficas sobre el Proceso Unificado
Rational

(RUP)

(http://es.wikipedia.org/wiki/RUP#Ciclo_de_vida),

(http://www-

01.ibm.com/software/rational/), as como los conceptos de Lenguaje de Modelado


Unificado

UML

(http://es.wikipedia.org/wiki/UML)

(http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php),(ISCA,

2006);

se

realizara el anlisis de aplicabilidad de las GGPIC a la gestin de proyectos de software, y


las adaptaciones correspondientes para lograr disear una metodologa para gestin de
proyectos de Tecnologas de Informacin (TI) eficiente incorporando los elementos
necesarios segn RUP y UML.

1.3.2.

Presentar el Marco Organizacional

En el presente trabajo de grado se prescribi utilizar los documentos de proceso de la


organizacin Desarrollo e Implantacin de Soluciones (DIS) (Gestin y Mejoramiento de
Procesos, 2007),

perteneciente a la Gerencia de Automatizacin, Informtica y

Telecomunicaciones (AIT) de PDVSA, con lo cual se realizara una breve descripcin de


las mismas, destacando sus objetivos, ya que en esta organizacin se aplica el proceso
objeto de este estudio, es decir, la gestin de proyectos.

1.3.3.

Elaboracin del Examen de la Situacin

Para realizar el examen de la situacin se dispuso realizar un anlisis comparativo de las


GGPIC vs. la metodologa RUP/UML determinando la aplicabilidad de las primeras en
proyectos de Tecnologas de Informacin. El proceso bsico consistira en revisar cada
una de las fases del ciclo de vida de un proyecto segn las GGPIC, utilizando tablas donde
se pudiera seleccionar la aplicabilidad de las actividades de cada fase en el desarrollo de
proyectos de Tecnologas de Informacin, para finalmente concluir con los resultados.

1.3.4.

Elaboracin de la Propuesta

Para elaborar la propuesta de diseo de una metodologa aplicable a la Gestin de


Proyectos de Tecnologas de Informacin en la organizacin DIS, se estableci tomar
todos los elementos considerados como fortalezas identificadas, aplicables de las GGPIC,
utilizando el resultado obtenido del examen de la situacin, y complementarlos con los
elementos necesarios que se extraeran de la metodologa RUP/UML, obteniendo como
resultado una metodologa que permitira gestionar eficientemente los proyectos de TI, sin
contradecir el lineamiento corporativo que exige el uso de las GGPIC como base para la
gestin de proyectos en PDVSA.

1.3.5.

Evaluacin de la Propuesta Elaborada

La propuesta elaborada ser presentada a Coordinacin de Metodologas que forma parte


de la organizacin Desarrollo e Implantacin de Soluciones (DIS), el coordinador de
acuerdo a su experiencia, evaluar la pertinencia y viabilidad de aplicar la metodologa, y,
de ser aceptada, ser aplicada en la gestin de un nuevo proyecto que est por comenzar.

1.3.6.

Evaluacin del Proceso General cumplido

Para la evaluacin del proceso de Trabajo Especial

de Grado,

se analizara la

correspondencia entre lo planificado y lo ejecutado, el cumplimiento del cronograma de


ejecucin; y, el grado de logro de los objetivos.

1.4.

CRONOGRAMA DE EJECUCION.

Para el cumplimiento de los pasos definidos en la metodologa se estableci cumplir el


siguiente cronograma:

Tabla 1 Cronograma de Ejecucin del Proyecto

2. CAPITULO II
MARCO CONCEPTUAL REFERENCIAL
Para entender la necesidad existente de una metodologa de gestin de proyectos de TI,
es importante sealar los conceptos bsicos de proyecto, gestin de proyectos, tecnologa
de informacin (TI), gestin de proyectos de TI, Guas de Gerencia de Proyectos de
Inversin de Capital (GGPIC), metodologa Rational del Proceso Unificado o Rational
Unified Process (RUP), Tecnologa de Objetos y Lenguaje de Modelado Unificado o
Unified Modeling Language (UML). Conociendo brevemente estos conceptos, se contar
con el contexto necesario para apreciar el resultado del presente Trabajo Especial de
Grado.

2.1.

PROYECTO

Se pueden revisar algunos conceptos de proyecto desde el punto de vista de varios


autores, de all pues, se logran observar las coincidencias de criterios para definir un
proyecto.

Un proyecto es cualquier trabajo finito, complejo y no repetitivo sea de diseo,


construccin u otro, el cual contiene un conjunto de actividades formalmente
organizadas a las cuales se les han establecido fechas de inicio y terminacin y
consumen recursos humanos, materiales, equipos, tiempo y dinero (IESA, 2005,
p. 2)

Segn Kerzner (2001) un proyecto puede ser considerado como una serie de actividades y
tareas que:

Tienen un objetivo especfico para ser completadas bajo ciertas especificaciones.

Tienen definidas las fechas de comienzo y fin.

Tienen limitaciones en la dotacin de fondos.

Consume recursos (dinero, labor, equipos, etc.)

A su vez, un proyecto es un esfuerzo temporal que se lleva a cabo para crear un


producto, servicio o resultado nico (Project Management Institute, 2004, p. 5).

Se puede decir entonces, habida cuenta de las coincidencias de los conceptos sealados
anteriormente, que un proyecto es un conjunto de actividades lgicamente relacionadas
que se llevan a cabo para cumplir unos objetivos y producir un resultado nico, dentro del
tiempo, costo y con el alcance y calidad especificados, a estas tres caractersticas se les
conoce como la triple restriccin (Fig. 1), dichas restricciones se encuentran en todos los
proyectos; en el mejor de los casos, debe haber limitaciones en dos de los aspectos y uno
debe ser negociable, si hay limitaciones estrictas en las tres restricciones son muy pocas
las probabilidades de xito.

Fig. 1 La Triple restriccin


Se considera que en los proyectos el esfuerzo es temporal porque tienen un comienzo y
un fin definido; el fin debera determinarlo el momento en que se cumplen los objetivos, sin
embargo, existen otras razones que pueden fijar el final de un proyecto, como lo son la
evidencia de que los objetivos no van a lograrse o un cambio en las necesidades que
amerite cancelar el proyecto.

Los resultados son nicos, pues cada proyecto, aunque parezca repetitivo, como en el
caso de la construccin de edificios, tiene sus propias caractersticas. En el ejemplo de la
construccin se manifiesta la singularidad de los proyectos, ya que, aunque se trate de
construir edificios, cada uno de ellos puede diferir en diversos aspectos, como el
propietario, el presupuesto, la ubicacin, el terreno, etc.

Como punto importante para concluir el concepto de proyectos, debe decirse que la
ejecucin de los mismos debe ser gradual, puesto que al inicio solo se tiene una visin
general de lo que ser el alcance del proyecto, el cual se va afinando a medida que se
avanza en las primeras etapas, sin que esto signifique que deban existir constantes
cambios de alcance, sino que se especifica en mas detalle y se entienden con mas
claridad cuales sern los resultados que se pretenden obtener.

2.2.

GESTIN DE PROYECTOS

Desde las ms tempranas pocas de la historia de la humanidad la direccin de proyectos


tuvo una gran importancia y repercusin. Desde la construccin de las pirmides de Egipto
y hasta las del pueblo Maya tuvieron que utilizar la direccin de proyectos para su
realizacin. Los constructores de esas estructuras fueron los primeros directores de
proyectos del mundo. No contaban con la ayuda de computadoras ni con herramientas de
programacin como la PERT (Performance Evaluation and Review Technique, tcnica de
evaluacin y revisin del rendimiento) o el CPM (Critical Path Method, mtodo del camino
crtico), y en ocasiones ni siquiera con papel para dibujar planos. A pesar de ello, dirigieron
proyectos de una complejidad excepcional utilizando las herramientas ms sencillas.

Aunque la direccin de proyectos tiene una antigedad de al menos 4.500 aos, hasta
muy recientemente no ha sido reconocido el papel del director de proyectos como
disciplina por derecho propio, sin embargo, hoy en da hay incluso universidades que
dictan cursos de proyectos a nivel de doctorado.

Algunos factores clave que determinan el xito de un proyecto segn Clealand y Ireland
(2001) son:

Las etapas/fases de trabajo del proyecto culminan a tiempo y dentro del


presupuesto.

Los resultados generales del proyecto culminan a tiempo y dentro del presupuesto.

Los resultados del proyecto se han entregado al cliente, quien considera que el
proyecto se adapta adecuadamente a la misin, los objetivos y los propsitos de la
empresa.

Los beneficiarios del proyecto se sienten satisfechos con el modo en que ste se
administr y con los resultados obtenidos.

Los integrantes del equipo del proyecto creen que su participacin fue una
experiencia valiosa para ellos.

Se obtuvo un beneficio del trabajo efectuado en el proyecto.

El trabajo del proyecto produjo algunos avances tecnolgicos que prometen dar a la
empresa una ventaja frente a sus competidores.

Para que estos factores estn presentes en los proyectos, es indispensable una adecuada
gestin durante su ejecucin. Por esto es importante conocer que la gestin de proyectos
es:

La aplicacin de conocimientos, habilidades, tcnicas y herramientas con la


intencin de satisfacer o superar los requerimientos del dueo o de los
inversionistas. A su vez, es la encargada de de visualizar y establecer
prioridades del proyecto, ubicarlas en un espacio de tiempo determinado y
asignar el tipo y nmero de recursos necesarios para satisfacer esas prioridades
(IESA, 2005, p. 5).

Todo esto con la finalidad de ejecutar el proyecto en el menor tiempo posible, al ms bajo
costo y con la calidad requerida, es decir, dentro de los parmetros de la triple restriccin,
en un ambiente de trabajo seguro, armnico y cordial.

Se trata entonces de una mezcla entre arte y ciencia: es el arte de conseguir que todas las
actividades de un proyecto se realicen satisfactoriamente con un grupo multidisciplinario y
heterogneo de profesionales y trabajadores; y es una ciencia porque se maneja una gran
cantidad de informacin necesaria para planificar y controlar el trabajo con el fin de

mantener un balance entre el tiempo de ejecucin y los costos, evitando as una demanda
excesiva y desorganizada de recursos.

Como consecuencia de la gestin de proyectos es posible conocer en todo momento qu


problemas se producen y resolverlos o paliarlos de manera oportuna.

Al Gestor de Proyectos se le denomina de diversas formas; dependiendo de la empresa o


incluso del pas se le puede conocer como Gerente, Administrador, Director o Lder de
Proyecto, incluso pueden convivir varios de estos nombres dependiendo de cmo se
defina la estructura organizacional del proyecto y los roles y responsabilidades que se
asignen a cada uno. Para los efectos del presente Trabajo Especial de Grado, al Gestor de
Proyectos se le llamar Lder de Proyectos.

Lo cierto es que el Lder del Proyecto es el responsable de alcanzar los objetivos del
mismo, por lo tanto, entre otras cosas, segn el Project Management Institute (2004) el
lder debe:

Identificar los requisitos.

Establecer unos objetivos claros y posibles de realizar.

Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos.

Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y


expectativas de los diferentes interesados. (p. 8)

La gestin por si sola no garantiza el xito de los proyectos, para que haya una buena
gestin es necesario contar con un buen lder de proyectos que tenga las siguientes
pericias:

Liderazgo: indicar la direccin, los lineamientos y motivar al personal, as como


gerenciar la asignacin y procura oportuna de recursos para la consecucin ptima
de los objetivos.

Comunicacin: Los buenos lderes son bsicamente comunicadores. El lder debe:


Remitir informacin clara, precisa, completa y oportuna.
Recibir informacin completa y entenderla.

Proveer canales de comunicacin eficaces, lo cual es esencial para el xito


del proyecto.
Utilizar diversos tipos de comunicacin: escrita u oral; formal o informal;
interna o externa y vertical u horizontal.

Negociacin: alcanzar acuerdos que satisfagan a las partes.

Solucin: definir problemas ya sean internos, externos, tcnicos, gerenciales,


econmicos o personales, y estar en la capacidad de analizar o evaluar opciones,
tomar decisiones y aplicar correctivos.

Proactividad: debe poseer poder y libertad para elegir; responder a acuerdos o


principios; aceptar responsabilidades y concentrarse en su mbito de influencia.

Sin duda, una buena aplicacin de la Gestin de Proyectos en manos de un buen Lder de
Proyectos, aumenta considerablemente las probabilidades de xito de los mismos.

2.3.

Un

TECNOLOGA DE INFORMACIN (TI)

concepto

de

Tecnologa

de

Informacin

segn

http://www.ntn-

consultores.com/paginas/tecnologia.htm:

Es la plataforma e infraestructura tecnolgica que mantiene las operaciones de


los servicios de informacin de una compaa. La tecnologa incluye la
planificacin estratgica de sistemas de informacin, la implantacin de
tecnologa y paquetes, distribucin de datos y procesos, auditoria de sistemas,
diseo de modelos de datos, ingeniera de informacin con tecnologa y
herramientas y tcnicas de desarrollo acelerado (consultado el 10-06-2009)

Asimismo, la TI se comprende como la utilizacin de tecnologa para el manejo y


procesamiento

de

informacin,

especficamente

la

captura,

transformacin,

almacenamiento, proteccin, y recuperacin de datos e informacin.

Los orgenes de la TI son recientes. Aunque el nombre de Tecnologa de Informacin se


remonta a los aos 70, su utilizacin en los negocios se remonta a mediados del siglo XX,
durante la segunda guerra mundial. Sin embargo, ha sido en los ltimos 20 aos donde ha
alcanzado niveles de uso y aplicaciones tan variadas y difundidas, que se ha convertido

en un rea de gran amplitud e impacto en todos los aspectos de la vida cotidiana,


incluyendo la gerencia de cualquier empresa, en la cual hoy en da es prcticamente
indispensable.

Desde el surgimiento de Internet, se ha incorporado masivamente a la TI el aspecto de


comunicacin, con lo cual se suele hacer referencia a un tema an ms amplio, conocido
como Tecnologa de Informacin y Comunicaciones, o TIC.

2.3.1.

Tecnologa de Informacin en la Empresa

El departamento o equipo que dentro de una organizacin ejerce las funciones de TI se


encarga de estudiar, disear, desarrollar, implementar y administrar los sistemas de
informacin utilizados para el manejo de datos e informacin de toda la organizacin.
Estos sistemas, a su vez, comprenden aplicaciones o software, y equipos o hardware.

Llevar a cabo las tareas de la organizacin apoyndose en la tecnologa de informacin,


generalmente redunda en un procesamiento ms rpido y confiable de su datos. La
informacin resultante tiene mayor movilidad y accesibilidad, y cuenta con mayor
integridad, que cuando se procesa en forma manual. Igualmente, las computadoras
relevan a los empleados de numerosas actividades repetitivas y aburridas, permitindoles
aprovechar

mejor

su

tiempo

en

actividades

que

agregan

ms

valor

(http://www.degerencia.com/area.php?areaid=2001, consultado el 11-06-2009).

A medida que los precios de los equipos de computacin bajan, su capacidad aumenta, y
se hacen ms fciles de usar, la TI se utiliza en nuevas y variadas formas. En las
empresas, sus aplicaciones son diversas. Hoy en da, la mayora de las empresas
medianas y grandes (y cada da ms pequeas y micro-empresas) utilizan la TI para
gestionar casi todos los aspectos del negocio, especialmente el manejo de los registros
financieros y transaccionales de las organizaciones, registros de empleados, facturacin,
cobranza, pagos, compras, y mucho ms.

2.4.

GESTIN DE PROYECTOS DE TI

Actualmente, las organizaciones que gestionan TI necesitan hacer frente a la complejidad


de gestionar la demanda que puede venir desde: servicios, recursos hardware / software,
peticiones de soporte, y, como una parte muy importante de la gestin de TI, peticiones de
nuevos proyectos y cambios en los mismos; necesitan ser cada vez ms eficientes, con
recursos humanos, tecnolgicos y financieros, sin embargo, cada vez ms limitados y, al
mismo tiempo, deben ser capaces de responder en el menor tiempo posible. Esta
complejidad y urgencia es especialmente significativa en los proyectos de desarrollo de
aplicaciones.

La definicin de gestin de proyectos aplicada a proyectos de tecnologas de informacin


se puede ver como un sistema de cursos de accin simultneos y/o secuenciales que
incluye personas, equipamientos de hardware, software y comunicaciones, enfocados en
obtener uno o ms resultados deseables sobre un sistema de informacin
(http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/c1/c1.htm,
consultado el 09-06-2009).

Segn http://www.hispadata.com/servicios/gestion-proyectos-ti.php todo proyecto de TI ha


de estar orientado hacia cinco retos clave:

Negocio estratgico.

Globalizacin.

Arquitectura de la informacin.

Inversin en sistemas de informacin.

Responsabilidad y control (consultado el 09-06-2009).

El proyecto de TI debe ser entendido como una decisin estratgica de la empresa, bien
como consecuencia de una necesidad de informatizar una tarea o bien para mejorarla, por
propia evolucin o por cambios estratgicos.

Al abordar un proyecto de TI se deben considerar los recursos necesarios, algunos de


ellos

son

(http://www.monografias.com/trabajos39/proyecto-informatico/proyecto-

informatico2.shtml, consultado el 10-06-2009):

Fsicos
Sistema central
Perifricos
Comunicaciones

Lgicos
Estructuras de almacenamiento
Monitores de comunicaciones
Lenguajes
Utilidades
Mtodos de desarrollo
Control de seguridad y desarrollo

Humanos
Seleccin
Formacin
Incentivacin

2.5.

GUAS DE GERENCIA PARA PROYECTOS DE INVERSIN DE CAPITAL


(GGPIC):

Las Guas de Gerencia para Proyectos de Inversin de Capital son unas guas que
contienen lineamientos prcticos para la ejecucin de un proyecto de una manera
normalizada en nuestro sistema y ordenada, de modo que ningn detalle y/o paso
importante se nos escape, y as garantizar, con un alto grado de confianza, que los
proyectos sean exitosos y cumplan con los requisitos de la Corporacin (PDVSA, 1999).

Las GGPIC, son utilizadas en PDVSA como lineamiento Corporativo para la gestin de
proyectos, las mismas abarcan:

El proceso de ejecucin de proyectos mayores () desde el momento en que


se genera la base de recursos a nivel corporativo, para luego pasar a la

concretizacin y definicin de propuestas y proyectos en las filiales, pasando por


todo el ciclo presupuestario y aprobatorio, el ciclo de planificacin y ejecucin de
los proyectos, y culminando con la puesta en marcha de las instalaciones, su
entrega a operaciones, los informes de cierre hasta el primer informe Post
Mortem (normativa PDVSA), su divulgacin y la evaluacin continua del
cumplimiento de las premisas del negocio durante la vida til del activo
construido (PDVSA, 1999, p. 3).

2.5.1.

Objetivo de las GGPIC

El objetivo de las GGPIC es el de establecer unas guas de uso prctico en la ejecucin de


proyectos, de manera de instituir a nivel de la industria una forma estndar de pensar y
trabajar.

La idea de estas guas es resumir y englobar una serie de reglas y prcticas de gerencia
que permita a los participantes del proyecto conducirse exitosamente a travs de todas las
fases, desde su visualizacin hasta la entrega de las instalaciones a los grupos
operacionales; y asegurarse de que se agoten todas las instancias debidas y establecidas
antes de pasar de una fase a la prxima y acometer costos adicionales (PDVSA, 1999).

2.5.2.

Ciclo de Vida de Proyectos Segn las GGPIC

Segn las GGPIC, el ciclo de vida de los proyectos est constituido por cinco fases las
cuales se muestran esquemticamente en la siguiente figura:

Fig. 2 Ciclo de Vida de Proyectos segn las GGPIC

A lo largo de todo el proceso de ejecucin de proyectos y al terminar cada una de las


fases hay que tomar decisiones importantes, las cuales estn tipificadas por los rombos
D1 al D4 en la figura anterior.

2.5.3.

Fases del Ciclo de Vida de Proyectos

Para conocer en trminos generales en qu consisten las fases del ciclo de vida de
proyectos segn las GGPIC, se dar una breve descripcin de cada una de ellas, y se
representar de manera grfica las principales actividades abarcadas en cada caso.

2.5.3.1.

Visualizar

Esta es la fase donde se inician los proyectos, que pueden provenir de una idea gestada
en cualquier parte de la Corporacin, a raz de un anlisis externo/interno, o de un anlisis
de Fortalezas, Oportunidades, Debilidades, Amenazas (FODA), que son realizados como
parte de los ciclos de planificacin.

Las principales actividades que se ejecutan en esta fase se pueden apreciar en la


siguiente grfica:

Fig. 3 Fase Visualizar

2.5.3.2.

Conceptualizar

La fase visualizar genera las entradas de la fase conceptualizar, en la cual se determinan


la o las mejores opciones para la solucin del proyecto, as como tambin se afinan los
estimados de costos, logrando:

Reducir la incertidumbre y cuantificar los riesgos asociados.

Determinar el valor esperado para la(s) opcin(es) seleccionada(s).

Bsicamente, esta fase busca cumplir con dos objetivos principales:

Organizarse para la fase de planificacin del proyecto.

Seleccionar la(s) opcin(es) preferida(s) y solicitar los fondos para ejecutar las
actividades que permitan obtener un estimado de costo clase II (ver anexo N 1).

En esta fase se ejecutan principalmente las actividades a continuacin:

Fig. 4 Fase Conceptualizar


2.5.3.3.

Definir

En esta fase del ciclo de vida de los proyectos segn las GGPIC se trabaja
fundamentalmente en una definicin detallada del alcance, al igual que en la planificacin
tanto en tiempo como en costos con un nivel de precisin clase II, de la ejecucin de la

opcin de solucin seleccionada; esta fase es determinante ya que es aqu donde deben
solicitarse los fondos o el financiamiento requerido para ejecutar el proyecto.

Para llevar a cabo esta fase es necesario completar las siguientes acciones:

Fig. 5 Fase Definir


2.5.3.4.

Implantar

Una vez culminada la fase definir, si se obtuvo la aprobacin del proyecto y de los fondos,
se procede con la materializacin de la idea, dando como resultado unas instalaciones
listas para entrar en servicio.

De esta fase se derivan las siguientes actividades:

Fig. 6 Fase Implantar

2.5.3.5.

Operar

En la fase operar ocurre la transicin entre la construccin y la puesta en servicio de las


instalaciones, para finalmente entrar en operacin.

En esta transicin ocurre un solapamiento ya que en esta fase se le deben dar los toques
finales a la construccin, es decir, completar la lista de pendientes que pueda tener el
proyecto. Posteriormente se realizan las pruebas y la aceptacin de las instalaciones, para
culminar con los informes finales de cierre del proyecto.

Las acciones necesarias para lograr esta fase y finalmente concluir el proyecto son:

Fig. 7 Fase Operar


Al revisar grosso modo la descripcin de las GGPIC, es fcil evidenciar como las mismas
constituyen una herramienta especialmente til para proyectos de Ingeniera y
Construccin.

2.6.

TECNOLOGA DE OBJETOS

Hoy en da la tecnologa orientada a objetos ya no se aplica solamente a los lenguajes de


programacin, adems se viene aplicando en el anlisis y diseo de soluciones de
Tecnologa de Informacin con mucho xito, al igual que en las bases de datos. Para
hacer una buena programacin orientada a objetos hay que desarrollar todo el sistema
aplicando esta tecnologa, de ah la importancia del anlisis y el diseo orientado a
objetos.

La programacin orientada a objetos es una de las formas ms populares de


programar y ha tenido gran acogida en el desarrollo de proyectos de Tecnologa
de Informacin en los ltimos aos. Esta acogida se debe a sus grandes
capacidades y ventajas frente a las antiguas formas de programar.
(http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/, consultado el
11-06-2009)
2.6.1.

Una Perspectiva Histrica

Segn http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ (consultado el 1106-2009), tradicionalmente, la programacin fue hecha en una manera secuencial o lineal,
es decir, una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.

Fig. 8 Programacin Tradicional


Los lenguajes basados en esta forma de programacin ofrecan ventajas al principio, pero
el problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos
al estilo espagueti no ofrecen flexibilidad y el mantener una gran cantidad de lneas de
cdigo en un slo bloque se vuelve una tarea complicada.

Frente a esta dificultad aparecieron los lenguajes basados en la programacin


estructurada. La idea principal de esta forma de programacin es separar las partes
complejas del programa en mdulos o segmentos que sean ejecutados conforme se
requieran. De esta manera se logra un diseo modular, compuesto por mdulos

independientes que puedan comunicarse entre s. Poco a poco este estilo de


programacin fue reemplazando al estilo espagueti impuesto por la programacin lineal.

Entonces, se puede observar que la evolucin que se fue dando en la programacin se


orientaba siempre a ir descomponiendo ms la solucin. Este tipo de descomposicin
conduce directamente a la programacin orientada a objetos.

La creciente tendencia de crear programas cada vez ms grandes y complejos llev a los
desarrolladores a crear una nueva forma de programar que les permite crear sistemas de
niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades
ya no bastaba la programacin estructurada ni mucho menos la programacin lineal. Es
as como aparece la Programacin Orientada a Objetos (POO). La POO viene de la
evolucin de la programacin estructurada; bsicamente la POO simplifica la
programacin con la nueva filosofa y nuevos conceptos que tiene. La POO se basa en
dividir el programa en pequeas unidades lgicas de cdigo. A estas pequeas unidades
lgicas de cdigo se les llama objetos. Los objetos son unidades independientes que se
comunican entre ellos mediante mensajes.

2.6.2.

Fortalezas de la Tecnologa Orientada a Objetos

Fomenta la reutilizacin y extensin del cdigo.

Permite crear sistemas ms complejos.

Permite relacionar el sistema con el mundo real.

Facilita la creacin de programas visuales.

Favorece la construccin de prototipos.

Agiliza el desarrollo de soluciones de TI.

Facilita el trabajo en equipo.

Simplifica el mantenimiento de las soluciones de TI.

2.6.3.

Anlisis y Diseo Orientado a Objetos

Para el desarrollo de soluciones de tecnologa de informacin orientado a objetos no basta


usar un lenguaje orientado a objetos. Tambin se necesita realizar un anlisis y diseo
orientado a objetos.

El modelamiento visual es la clave para realizar el anlisis orientado a objeto (OO). Desde
los inicios del desarrollo de software OO han existido diferentes metodologas para hacer
el modelamiento, pero sin lugar a duda, el Lenguaje de Modelado Unificado (UML) puso
fin a la guerra de metodologas.

Segn los mismos diseadores del lenguaje UML, ste tiene como fin modelar cualquier
tipo de sistemas (no solamente de software) usando los conceptos de la orientacin a
objetos. Y adems, este lenguaje debe ser entendible para los humanos y las mquinas.

Actualmente en la industria del desarrollo de software se tiene al UML como un estndar


para el modelamiento de sistemas OO. Fue la empresa Rational quien cre estas
definiciones y especificaciones del estndar UML, y lo abri al mercado. La misma
empresa cre uno de los programas ms conocidos hoy en da para este fin: el Rational
Rose, pero tambin existen otros programas como el Poseidon que trae licencias del tipo
Community Edition que permiten su uso libremente.

El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en
base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se
construyen en forma correcta, son fciles de comunicar, cambiar, expandir, validar y
verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes
plenamente reutilizables, en la seccin siguiente se hablar con ms detalle de UML.

2.7.

LENGUAJE DE MODELADO UNIFICADO (UML)

2.7.1.

Descripcin del Lenguaje

UML es un lenguaje de propsito general para el modelado orientado a objetos, que


combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de
Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows).

En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones


de la realidad, para comprender mejor el sistema que se va a desarrollar: los arquitectos
utilizan y construyen planos (modelos) de los edificios, los grandes diseadores de coches
preparan modelos en sistemas existentes con todos los detalles y los ingenieros de
software deberan igualmente construir modelos de los sistemas software.

Un enfoque sistemtico permite construir estos modelos de una forma consistente


demostrando su utilidad en sistemas de cierto tamao. Cuando se trata de un programa
de cincuenta, cien lneas, la utilidad del modelado parece discutible pero cuando se
involucra a cientos de desarrolladores trabajando y compartiendo informacin, el uso de
modelos y el proporcionar informacin sobre las decisiones tomadas, es vital, no slo
durante el desarrollo del proyecto, sino una vez finalizado ste, cuando se requiere algn
cambio en el sistema. En realidad, incluso en el proyecto ms simple los desarrolladores
hacen algo de modelado, aunque sea de manera informal.

Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se
ignoran los dems, por lo cual con un nico modelo no se tiene suficiente (Rueda, 2006).

2.7.2.

Descripcin de los Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho
sistema, considerando un cierto propsito. As, el modelo describe completamente
aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un
apropiado nivel de detalle. (Rueda, 2006)

Un diagrama es una representacin grfica de una coleccin de elementos de modelado,


a menudo dibujada como un grafo con vrtices conectados por arcos. Un proceso de
desarrollo de una solucin de tecnologa de informacin debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las perspectivas de
inters. Es aqu donde se hace evidente la importancia de UML en este contexto.

El cdigo fuente del sistema es el modelo ms detallado del sistema, y adems es


ejecutable. Sin embargo, se requieren otros modelos.

Segn Rueda, varios modelos aportan diferentes vistas de un sistema los cuales nos
ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve
diagramas que, para representar las distintas vistas de un sistema, son muy tiles. Estos
diagramas de UML se presentan en la figura N 9 y se describen a continuacin:

Fig. 9 Partes de un Modelo UML


2.7.2.1.

Diagrama de Casos de Uso

Modela la funcionalidad del sistema agrupndola en descripciones de acciones ejecutadas


por un actor para obtener un resultado.

2.7.2.2.

Diagrama de Clases

Muestra las clases (descripciones de objetos que comparten caractersticas comunes) que
componen el sistema y cmo se relacionan entre s.

2.7.2.3.

Diagrama de Objetos

Muestra una serie de objetos (instancias de las clases) y sus relaciones.

2.7.2.4.

Diagramas de Comportamiento

Dentro de estos diagramas se encuentran:

Diagrama de Estados: Modela el comportamiento del sistema de acuerdo con


eventos.

Diagrama de Actividades: Simplifica el Diagrama de Estados modelando el


comportamiento mediante flujos de actividades. Tambin se pueden utilizar
caminos verticales para mostrar los responsables de cada actividad.

Diagramas de Interaccin: Estos diagramas a su vez se dividen en dos tipos de


diagramas, segn la interaccin que enfatizan:
Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los
mensajes que intercambian entre s junto con el orden temporal de los
mismos.
Diagrama de Colaboracin: igualmente, muestra la interaccin entre los
objetos resaltando la organizacin estructural de los objetos en lugar del
orden de los mensajes intercambiados.

2.7.2.5.

Diagramas de implementacin

Estos se subdividen en dos tipos de diagramas:

Diagrama de Componentes: Muestra la organizacin y las dependencias entre un


conjunto de componentes.

Diagrama de Despliegue: Muestra los dispositivos que se encuentran en un sistema


y su distribucin en el mismo.

La metodologa de modelado UML, por ser estndar, es utilizada por la metodologa para
desarrollo de soluciones de tecnologas de informacin Rational Unified Process (RUP),
de la cual se hablar brevemente a continuacin.

2.8.

PROCESO UNIFICADO RATIONAL (RUP)

Las siglas RUP en ingls significan Rational Unified Process (Proceso Unificado de
Rational). RUP es un producto del proceso de ingeniera de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin
de desarrollo de software (http://www.liderdeproyecto.com/metodologias/index.html,
consultado el 11-06-2009). La meta de RUP es asegurar la produccin del software de alta
calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo
establecidos. El RUP tiene dos dimensiones:

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso.

El eje vertical representa las disciplinas, que agrupan actividades definidas


lgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa en


trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin
representa el aspecto esttico del proceso: cmo se describe en trminos de
componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los
artefactos, y los roles. Estas dimensiones se pueden ver representadas grficamente en la
figura N 10.

Fig. 10 Proceso Unificado Rational


En la figura precedente se puede observar como vara el nfasis de cada disciplina en un
cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones
tempranas, se invierte ms tiempo en requerimientos, y en las ltimas iteraciones se pasa
ms tiempo en poner en prctica la realizacin del proyecto en si.

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:

Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los
Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los
artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la
implementacin de las fases y disciplinas del RUP. Un Caso de Uso es una
secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona
directamente con los requerimientos, ya que un Caso de Uso es la secuencia de
pasos que conlleva la realizacin e implementacin de un requerimiento planteado
por el Cliente.

Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo


de un proyecto de TI. Este modelo plantea la implementacin del proyecto a realizar
en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin
y as poder ir completando todo el proyecto iteracin por iteracin, con lo cual se
tienen varias ventajas, entre ellas se puede mencionar la de tener pequeos
avances del proyectos que son entregables al cliente el cual puede probar mientras
se esta desarrollando otra iteracin del proyecto, con lo cual el proyecto va
creciendo hasta completarlo en su totalidad.

Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, y una


arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un
sistema es la organizacin o estructura de sus partes ms relevantes. Una
arquitectura ejecutable es una implementacin parcial del sistema, construida para
demostrar algunas funciones y propiedades. RUP establece refinamientos
sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo
(Rueda, 2006).

2.8.1.

Dimensin 1: Fases del ciclo de vida RUP

El ciclo de vida de los proyectos de TI del RUP se descompone en cuatro fases


secuenciales:

2.8.1.1.

Inicio

Define el mbito y objetivos del proyecto.

Se define la funcionalidad y capacidades del producto.

Se identifican los principales casos de uso.

Se identifican los riesgos.

2.8.1.2.

Preparacin

Tanto la funcionalidad como el dominio del problema se estudian en profundidad.

Se define una arquitectura bsica.

Se planifica el proyecto considerando recursos disponibles.

2.8.1.3.

Construccin

El producto se desarrolla a travs de iteraciones donde cada iteracin involucra


tareas de anlisis, diseo e implementacin.

Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu
refinada de manera incremental conforme se construye.

Gran parte del trabajo es programacin y pruebas.

Se documenta tanto el sistema construido como el manejo del mismo.

Esta fase proporciona un producto construido junto con la documentacin.

2.8.1.4.

Transicin

Se libera el producto y se entrega al usuario para un uso real.

Se incluyen tareas de mercadeo, empaquetado atractivo, instalacin, configuracin,


entrenamiento, soporte, mantenimiento, etc.

Los manuales de usuario y de sistema se completan y refinan con la informacin


anterior.

Estas tareas se realizan tambin en iteraciones.

Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara
considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un
proyecto de tamao mediano debe anticipar la distribucin del esfuerzo como sigue:

Tabla 2 Esfuerzo vs. Fases RUP

Esfuerzo

Inicio

Preparacin

Construccin

Transicin

~5 %

20 %

65 %

10%

Lo cual se puede representar grficamente como se muestra en la figura 11.

Fig. 11 Tiempo y Esfuerzo vs. Fases de RUP


2.8.2.

Dimensin 2: Disciplinas

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para
la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias
y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de TI,
aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:
Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas,
Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las
primarias y especifican otras caractersticas en la realizacin de un proyecto de TI; entre
estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A
continuacin se describen brevemente cada una de estas disciplinas.

2.8.2.1.

Modelado del Negocio

El Modelado del Negocio tiene como objetivos comprender la estructura y la dinmica de


la organizacin, comprender problemas actuales e identificar posibles mejoras,
comprender los procesos de negocio. Utiliza el Modelo de Casos de Uso (CU) del Negocio
para describir los procesos del negocio y/o los clientes.

2.8.2.2.

Requerimientos

Los requerimientos establecen lo que el sistema debe hacer (especificar requisitos), definir
los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y
tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden
los CU, Actores y Relaciones, adems utiliza los Diagramas de Estado de cada CU y las
especificaciones suplementarias.

2.8.2.3.

Anlisis y Diseo

Define la arquitectura del sistema y tiene convierte requisitos en especificaciones de


implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo
se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis
de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de
cada CU, el de secuencia de diseo de CU, el de estados de las clases y el modelo de
despliegue de la arquitectura.

2.8.2.4.

Implementacin

Esta disciplina tiene como objetivos implementar las clases de diseo como componentes
(ej. fichero fuente), asignar los componentes a los nodos, probar los componentes
individualmente,

integrar

los

componentes

en

un

sistema

ejecutable

(enfoque

incremental). Utiliza el Modelo de Implementacin, conjuntamente con los Diagramas de


Componentes

para

comprender

cmo

se

organizan

los

componentes

su

interdependencia.

2.8.2.5.

Pruebas

Con esta disciplina se pretende verificar la integracin de los componentes (prueba de


integracin), verificar que todos los requisitos han sido implementados (pruebas del
sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin.

2.8.2.6.

Despliegue

Durante el despliegue se tienen como objetivos asegurar que el producto est preparado
para la entrega y recepcin por parte del cliente. En esta disciplina se realizan las
actividades de probar la nueva solucin de TI en su entorno final (Prueba Beta),
empaquetarlo, distribuirlo e instalarlo, as como la tarea de adiestrar al usuario.

2.8.2.7.

Gestin y Configuracin de Cambios

La gestin y configuracin de los cambios es esencial para controlar el nmero de


artefactos producidos por la cantidad de personal que trabaja en un proyecto
conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan
confusiones costosas como la compostura de algo que ya se haba arreglado etc., y
aseguran que los resultados de los artefactos no entren en conflicto debido a alguna de
las siguientes situaciones:

Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad,


sin saber que alguien ms lo est actualizando.

Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre


lo que se hizo, por lo tanto no se sabe quin, cmo, y cundo se hizo.

Versiones mltiples: No saber con exactitud, cual es la ltima versin, lo que


ocasiona que no se tenga un orden sobre qu modificaciones se han realizado a las
diversas versiones.

2.8.2.8.

Gestin del Proyecto

Su funcin principal es procurar el logro de los objetivos establecidos, administrar el riesgo


y superar restricciones para entregar un producto que satisfaga las necesidades de ambos
clientes con xito, los que proporcionan el dinero y los usuarios. Con la gestin del
proyecto se logra una mejora en el logro de una culminacin exitosa del mismo. En
resumen su propsito consiste en proveer pautas para:

Administrar proyectos.

Planear, dirigir personal, ejecutar acciones de supervisin y toma de decisiones.

Administrar el riesgo.

2.8.2.9.

Entorno

Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que
engloba el desarrollo de un proyecto y describe las actividades requeridas para el
desarrollo de las pautas que apoyan un proyecto.

Su propsito es proveer a la organizacin que ejecutar el proyecto, un ambiente en el


cual basarse, provee procesos y herramientas para poder desarrollar la solucin.

3. CAPTULO III
MARCO ORGANIZACIONAL
Es importante conocer el marco organizacional en el cual ser implantado el resultado del
presente Trabajo Especial de Grado, para ello se presentar la organizacin de lo general
a lo especfico de manera jerrquica, se presentar en primer lugar a Petrleos de
Venezuela (PDVSA), sus caractersticas y razn de ser, posteriormente se resear la
organizacin Automatizacin, Informtica y Telecomunicaciones (AIT), y por ltimo se
describirn las funciones de la Organizacin Desarrollo e Implantacin de Soluciones
dnde ser propuesta la utilizacin de la metodologa que se desarrollar en este trabajo.

3.1.

PETRLEOS DE VENEZUELA (PDVSA)

3.1.1.

Descripcin Ampliada de la Empresa

El 1 de enero de 1976, exactamente al primer segundo despus de las doce de la noche,


naci Petrleos de Venezuela S.A. como la empresa encargada de asumir las funciones
de planificacin, coordinacin y supervisin de la industria petrolera nacional al concluir el
proceso de reversin de las concesiones de hidrocarburos a las compaas extranjeras
que operaban en territorio venezolano. La partida de nacimiento de la principal industria
del pas qued plasmada en el decreto presidencial nmero 1.123 del 30 de agosto de
1975. Su primer presidente fue el general Rafael Alfonzo Ravard.

Durante el primer ao de operacin, PDVSA inici sus acciones con 14 filiales, de las
cuales posteriormente quedaran operando solo tres: Lagoven, Maraven y Corpoven, que
absorbieron las actividades de las concesionarias que estaban en Venezuela. Para aquel
ao, se mantiene la produccin de crudo en 2,3 millones de barriles diarios. Las
inversiones iniciales se sitan en un principio en 1.200 millones de bolvares. Ya en 1978,
las inversiones de capital se haban cuadruplicado y se ubicaban en 5.000 millones de
bolvares.

Dentro de esta fase, inicia acciones en 1976, el Instituto Tecnolgico Venezolano del
Petrleo (Intevep), destinado a efectuar los estudios e investigaciones necesarias para
garantizar el alto nivel de los productos y procesos dentro de la industria petrolera.
Igualmente, dos aos despus se crea Petroqumica de Venezuela S.A. (Pequiven),
dirigida a organizar el negocio de la produccin petroqumica.

Luego de cinco aos de puesta en marcha del decreto que cre a Petrleos de Venezuela,
PDVSA y sus filiales logran avanzar en un proceso de consolidacin en lo que respecta al
manejo del negocio petrolero. As, de esta manera, se consolid satisfactoriamente la
transicin y adaptacin de las actividades petroleras privadas de las concesionarias, a la
tutela del estado venezolano. Lagoven se encarga de las operaciones en el occidente y el
sur del pas; Corpoven despliega su rea de influencia en el centro de la nacin, mientras
que Maraven se sita en la regin oriental.

Asimismo, la compaa estatal enfoca parte de sus esfuerzos a la Faja del Orinoco, la cual
contiene importantes reservas de crudo pesado y extra-pesado. Para su explotacin, se
divide en cuatro reas o zonas de influencia: Machete, Hamaca (ambos operados en su
momento por Corpoven), Cerro Negro (Lagoven) y Zuata (Maraven). La importancia
estratgica de la faja queda plasmada en sus nmeros: las reservas probadas estn por el
orden de los 60.000 y 200.000 millones de barriles. Para tener una comparacin que
permita apreciar este dato, es importante destacar que desde 1917 hasta 1994, se
produjeron en el pas 46.421 millones de barriles de crudo de todo tipo.

El petrleo pesado es la base para la produccin de Orimulsin, combustible destinado


principalmente a las plantas generadoras de electricidad, como un sustituto del carbn por
sus caractersticas de baja contaminacin ambiental.

PDVSA logra ser considerada como una empresa confiable en el suministro de grandes
volmenes de petrleo a nivel mundial. En esta fase, Petrleos de Venezuela se consolida
como una las principales compaas petroleras multinacionales.

A mediados de los aos 80, la principal empresa del pas inicia una expansin tanto a
nivel nacional como mundial, con la compra y participacin en diversas refineras ubicadas
en Europa, Estados Unidos y el Caribe.

En este sentido, establece operaciones en las refineras de la Ruhr Oel, en Alemania;


Nynas, en Suecia y Blgica e Isla, en Curazao.

Por otra parte, el 15 de septiembre de 1986, Petrleos de Venezuela adquiri a la


empresa Citgo, en Tulsa, Estados Unidos, punta de lanza de la estrategia de
comercializacin de hidrocarburos en Norteamrica, con ms de mil estaciones de servicio
y casi el 20% de las ventas de gasolina en suelo estadounidense.

Para la dcada de los noventa, PDVSA inicia un proceso de asociaciones estratgicas


destinado a garantizar el inicio y la continuidad en importantes proyectos, como por
ejemplo el Mariscal Sucre, destinado a la exploracin y explotacin de los recursos de gas
natural licuado (GNL) que se encuentran ubicados en la pennsula de Paria y al este de la
isla de Margarita. Estn presentes como socios comerciales Shell, Exxon y Mitsubishi.

En aquel momento, se inicia un programa de convenios operativos de viejos campos


petroleros entre las tres filiales de PDVSA para la poca y por lo menos veinte compaas
extranjeras.

Igualmente, se comienza con un esquema de ganancias compartidas en diez reas


exploratorias: La Ceiba (Trujillo, Mrida, Zulia), Golfo de Paria Este, Golfo de Paria Oeste
(Sucre), Guarapiche (Monagas), Guanare (Portuguesa), San Carlos (Cojedes), El
Sombrero (Gurico), Catatumbo (Zulia), Punta Pescador y Delta Centro (Delta Amacuro).
Intervienen Mobil, Enron, Amoco, Elf y Conoco, entre otras.

La faja del Orinoco tambin entra dentro de una estrategia de asociaciones estratgicas
para producir crudos, mientras que se crean empresas mixtas en el rea de la
Orimulsin.

Entre 1993 y 1996 se realizaron las tres primeras rondas de convenios operativos lo que
produjo para el pas una inversin inicial superior a los dos mil millones de dlares y una
produccin adicional de crudo estimada en unos 260.000 barriles diarios.

El 1 de enero de 1998, Petrleos de Venezuela integraba en su estructura operativa y


administrativa a las tres filiales que durante ms de 20 aos haban compartido las

operaciones. Se estableca de esta manera una empresa con un perfil corporativo


unificado, dirigido a generar altos estndares de calidad y beneficios en lo que respecta a
los procesos que estn presentes dentro de la industria de los hidrocarburos.

En este sentido, se creaban tres divisiones funcionales PDVSA Exploracin y Produccin;


PDVSA Manufactura y Mercadeo, y PDVSA Servicios.

Exploracin y Produccin se encarga de desarrollar las actividades de bsqueda de


reservas y explotacin de petrleo y gas natural, as como los negocios del carbn y la
Orimulsin, los convenios operativos para la reactivacin de los campos petroleros, la
participacin de la industria en los contratos de exploracin a riesgo y produccin en reas
nuevas bajo el esquema de ganancias compartidas y en las asociaciones estratgicas
para el desarrollo de los crudos pesados de la Faja del Orinoco.

La responsabilidad de Manufactura y Mercadeo pasa por integrar todos los sistemas de


refinacin ubicados en el pas, incluso los de la refinera Isla, en Curazao. Igualmente,
comprende la comercializacin internacional de hidrocarburos, de productos en el
mercado industrial interno y el mercadeo al detal.

A partir de 1999, PDVSA establece en asociacin con la Fuerza Armada Nacional y otras
instituciones del Estado, una serie de programas dirigidos a paliar la emergencia social
que viva el pas.

Surge as el Plan Bolvar con el apoyo de Petrleos de Venezuela, destinado a contribuir a


mejorar los indicadores sociales en lo que respecta a la salud, mediante la realizacin de
jornadas cvicas de atencin integral dirigidas a la poblacin de menores recursos;
educacin, enfocado al mantenimiento y reparacin de la planta escolar; infraestructura,
con la creacin y puesta al da de obras de vialidad, vivienda y de inters para el pueblo,
como ambulatorios; alimentacin, para llegar a aquellos venezolanos que necesitan
productos de primera necesidad de calidad y a precios realmente econmicos.

Petrleos de Venezuela contribuye al desarrollo nacional con un alto sentido de


corresponsabilidad que surge en dos direcciones que corren paralelas y al final confluyen

como dos columnas que soportan parte de la estructura econmica y social de PDVSA y
del pas.

Este principio rige la totalidad de las operaciones que se enmarcan dentro de la dinmica
petrolera, ya que PDVSA es uno de los principales responsables en el desarrollo nacional
y por consecuencia de la seguridad de la nacin, y de todo lo que ello implica, a travs del
beneficio generado con la comercializacin de sus productos y sus aportes al fisco
nacional (http://www.intranet.pdvsa.com, consultado el 18-06-2009).

3.1.2.

El Plan Siembra Petrolera (PSP) 2005-2030

Las directrices de la poltica energtica de Venezuela hasta el ao 2030 estn trazadas en


el Plan Siembra Petrolera, que comprende seis grandes proyectos de desarrollo y consta
de dos etapas: una a ejecutarse entre el perodo 2005-2012, y la otra, a llevarse adelante
en la etapa comprendida entre 2012 y 2030.

Para el primer perodo del Plan Siembra Petrolera, se han estimado inversiones por el
orden de los 56.000 millones de dlares, a ser ejecutados entre 2005- y 2012. De esa
cantidad, 70% ser aportada por la operadora estatal venezolana y el resto por el sector
privado.

El Plan Siembra Petrolera 2005-2012 comprende seis ejes fundamentales:

3.1.2.1.

Magna Reserva

Destinado a la cuantificacin y certificacin de las reservas que posee Venezuela en la


Faja Petrolfera del Orinoco, para lo cual se har un estudio integrado de geologa.
Venezuela tiene, sin contabilizar la Faja, 77 mil millones de barriles de petrleo, mientras
que en la vasta zona del Orinoco se contabilizan 235 millones de barriles.

3.1.2.2.

Proyecto Orinoco

Es el encargado del desarrollo de la Faja Petrolfera del Orinoco. Se han seleccionado 27


bloques que se desarrollarn con esfuerzo propio y empresas. Por la ubicacin de este

reservorio de hidrocarburos, se considera de vital importancia en el proyecto de


desconcentracin del pas. Se estima la realizacin de desarrollos de servicios y viviendas
para garantizar una explotacin petrolera adecuada.

3.1.2.3.

Proyecto Delta-Caribe

El gas se incorporar a la oferta energtica del pas. Este proyecto persigue el desarrollo
del Gas Costa Afuera en las reas de Plataforma Deltana, en la fachada atlntica
venezolana; en las aguas ubicadas al norte del estado Sucre, al oriente de Venezuela; y
en las inmediaciones de la Pennsula de Paraguan, al nor-occidente del pas.

3.1.2.4.

Refinacin

Aumentar la capacidad de refinacin en Venezuela es una de las puntas de lanza del plan
estratgico de PDVSA. El Plan Siembra Petrolera contempla la creacin de nuevos
centros refinadores: Cabruta (con capacidad de 400.000 barriles diarios de crudos
extrapesados), Batalla de Santa Ins (50.000 barriles diarios) y Caripito (50.000 barriles
diarios destinados a la produccin de Asfalto). Con estas tres nuevas refineras y la
potenciacin de las existentes se incrementar en 700.000 barriles diarios la capacidad de
procesamiento de PDVSA en suelo venezolano.

3.1.2.5.

Infraestructura

Se habilitarn ms llenaderos y poliductos para garantizar a todo el territorio nacional el


suministro de combustibles.

3.1.2.6.

Integracin

El petrleo es la herramienta de integracin de los pueblos del continente. Venezuela


suple de forma directa volmenes de crudo y productos al Caribe a travs de Petrocaribe,
que tambin prev la ampliacin de la capacidad de refinacin en esa zona. Adems se
suscribi Petrosur, con lo que avanza la planificacin de proyectos.

3.2.

AUTOMATIZACIN, INFORMTICA Y TELECOMUNICACIONES (AIT)

3.2.1.

Breve Histrico

El servicio de la plataforma de Tecnologa de Informacin (TI) de PDVSA estaba a cargo


de la empresa Informtica y Tecnologa S.A. (INTESA) desde su creacin en 1996, con un
40% de capital accionario de PDVSA y un 60% del capital accionario de Science
Application International Corporation (SAIC). sta, al igual que PDVSA, al verse afectada
por el mismo entorno poltico-social acaecido a finales del ao 2002 y principios del 2003,
y aunado a la finalizacin programada del contrato, ces la prestacin de sus servicios a
PDVSA.

En consecuencia, PDVSA se enfrent a la necesidad de crear una nueva Gerencia de


Tecnologa de Informacin para continuar con el soporte y entrega de este servicio, e
incorporar a su vez otras reas de conocimiento relacionadas directamente con TI como lo
es el rea de Automatizacin. Surgi entonces la Gerencia de Automatizacin, Informtica
y Telecomunicaciones (AIT).

En el ao 2003 se defini en las en las diferentes regiones geogrficas de PDVSA, un


Modelo de Procesos para AIT con la visin de orientar la administracin, gestin y
ejecucin de servicios y productos, enfocado a la satisfaccin de los usuarios. En funcin
de aprovechar los esfuerzos realizados, se unen todos los Modelos de Procesos y se
elabora un Modelo de Procesos nico para toda la Gerencia de AIT a nivel Nacional, la
cual deba replicarse en cada regin.

El modelo est compuesto por procesos direccionales, medulares, habilitadores y de


control. Tiene como objetivo proporcionar una representacin grfica de todos los
procesos que son ejecutados dentro de AIT para proveer las soluciones y servicios
desprendidos de su misin dentro de PDVSA. Adicionalmente el modelo proporciona la
descripcin general de los objetivos y alcances de cada uno de esos procesos y de cmo
se relacionan entre s durante la operacin.

Este modelo de procesos a su vez se corresponde con la estructura organizacional de


AIT, tal como se puede apreciar en la figura 12:

Fig. 12 Modelo de Procesos AIT


3.2.2.

Visin

Soberana plena en soluciones AIT para el sector energtico aportando valor social
(PDVSA, 2008).

3.2.3.

Misin

Somos la Organizacin que rige, provee y mantiene los servicios y soluciones


integrales de tecnologas de automatizacin, informacin y comunicaciones de la
corporacin; contribuimos a mantener su continuidad operativa y a ejecutar sus
planes; innovamos y actuamos como agentes de transformacin en PDVSA y en
la sociedad venezolana con corresponsabilidad social, econmica y ambiental;
potenciamos un ecosistema tecnolgico que impulsa los poderes creadores del
pueblo, el conocimiento libre, el desarrollo endgeno sustentable y la economa
social productiva para lograr la soberana tecnolgica; alineados con la CRBV y
en coordinacin con nuestros organismos rectores (Planificacin y Arquitectura,
2008).

3.2.4.

Objetivos Estratgicos

Segn Planificacin y Arquitectura los Objetivos Estratgicos de AIT son los siguientes:

Construir la Infoestructura segura y en tiempo real requerida para el logro de los


retos del Plan Siembra Petrolera y la rendicin de cuentas transparente al pueblo
venezolano.

Optimizar los esquemas de mantenimiento y prestacin de servicios AIT para


asegurar la continuidad de las operaciones de la Corporacin a escala mundial en
condiciones normales y de contingencia.

Proveer soluciones tecnolgicas para habilitar el acercamiento del estado al


ciudadano mediante una red coordinada de instituciones.

Consolidar el

Ecosistema Tecnolgico que provee productos y servicios a la

Corporacin, profundizando el desarrollo endgeno, el conocimiento libre y la


economa social, orientados al logro de la Plena Soberana Tecnolgica.

Implantar el Distrito Social Tecnolgico AIT para la generacin de tecnologas AIT


dirigidas a la industria petrolera y el sector energtico.

Concretar la Transformacin Organizacional de AIT

a fin de ser proactivos,

eficientes, efectivos e innovadores en la incorporacin de tecnologas de AIT y la


provisin de las soluciones y servicios que nos sean demandados.

Fortalecer la relacin con los rganos Rectores en materia de Tecnologa de AIT


para asegurar la alineacin e integracin con el Estado.

Establecer el plan estratgico de RRHH que permita la captacin y desarrollo del


personal segn las competencias y necesidades de la funcin, apalancando los
requerimientos del Plan Siembra Petrolera y otros Organismos del Estado;
enfatizando la seguridad y proteccin del ambiente como conducta cotidiana de
trabajo.

Establecer sistemas corporativos de rendicin de cuenta para soportar la gestin


global de AIT, bajo las premisas de la eficiencia, eficacia, y

transparencia

emanadas de la Corporacin

Establecer un Plan Comunicacional efectivo para la divulgacin de la informacin


concerniente a todos los aspectos de funcionamiento de AIT a la Corporacin

Convertir la Organizacin de AIT en un nuevo modelo basado en los valores del


nuevo ciudadano para impulsar el desarrollo de la Corporacin y el pas y una
nueva relacin Estado - Sociedad.

Adoptar la seguridad y proteccin del ambiente como conducta cotidiana de trabajo


para garantizar los derechos ambientales de la poblacin.

3.3.

DESARROLLO E IMPLANTACIN DE SOLUCIONES (DIS)

Desarrollo e Implantacin de Solucin es la organizacin donde especficamente se


plante la implantacin de la nueva Metodologa para la Gestin de Proyectos de TI, que
fue la propuesta en el presente Trabajo Especial de Grado.

3.3.1.

Objetivo

Definir

implantar

soluciones

integrales

de

Automatizacin,

Informtica

Telecomunicaciones AIT eficientes y eficaces en trminos de costo y oportunidad para


satisfacer necesidades de PDVSA y la Nacin, que apalanquen las metas y objetivos de
PDVSA cumpliendo con lineamientos, estndares y normas nacionales e internacionales
adoptadas por la Corporacin (Gestin y Mejoramiento de Procesos, 2007).
3.3.2.

Alcance

La organizacin Gestin y Mejoramiento de Procesos defini que las funciones de DIS se


enmarcan dentro del siguiente alcance:

Conceptualizar la solucin: Conformacin del equipo de trabajo, formalizacin de


objetivos, roles y responsabilidades, preparacin del plan para definir la solucin, y
seleccin de la mejor opcin.

Formulacin del proyecto. Estimaciones clase II de costos del proyecto. Manejo del
riesgo.

La definicin de la solucin: Anlisis de riesgos, desarrollo en detalle del alcance y


los planes de ejecucin de la opcin seleccionada, planificacin operacional en
costo, calidad y tiempo ptimo, establecimiento de guas para el control de la
solucin, y preparacin del paquete para la autorizacin de la solucin.

El desarrollo e implantacin de la solucin: Materializacin del plan de ejecucin de


la solucin hasta completar las instalaciones.

La operacin: Puesta en marcha de las instalaciones por parte de custodios o


dueos, preparacin y pruebas para el arranque, pruebas de capacidad, entrega y
aceptacin de instalaciones y los informes finales.

El control y seguimiento de las soluciones requeridas y aprobadas.

Abarca soluciones tecnolgicas dirigidas a satisfacer necesidades de PDVSA y / o


la Nacin.

3.3.3.

Premisas

El proceso de Gestin de Necesidades y Oportunidades (GNO) determina cundo


la oportunidad ser desarrollada e implantada por el proceso de Desarrollo e
Implantacin de Soluciones (DIS).

Se aplica en este proceso las normativas externas e internas de Automatizacin,


Informtica y Telecomunicaciones (AIT) y PDVSA.

Solo sern proyectos para la responsabilidad del proceso DIS, aquellos que
impliquen el diseo y/o implantacin de una solucin tecnolgica de AIT.

El proceso DIS se responsabiliza de los siguientes tipos de proyectos:


Disear una solucin tecnolgica de AIT
Desarrollar e implantar una solucin tecnolgica de AIT.
Evaluar, seleccionar, e implantar una solucin tecnolgica de AIT.

El diseo e implantacin de soluciones se manejarn a travs del enfoque de


proyectos.

Se usarn las normas de la Gua de Gerencia para Proyectos de Inversin de


Capital (GGPIC) como marco de referencia para el diseo e implantacin de
soluciones tecnolgicas de AIT.

El proceso DIS debe aplicar las normativas establecidas por la Corporacin y la


Nacin, para los consiguientes propsitos, en la formulacin y ejecucin de las
soluciones tecnolgicas de AIT

3.3.4.

Diagrama Macro Interfuncional del Proceso

La figura 13 representa el diagrama macro interfuncional del proceso DIS:

DSD2

Solicitud de
Adecuacin de
Plataforma

DSD1 y
Propuesta de
Solucin
Tecnolgica
aprobado

Requerimient
o Act.
Elem. Config.

Concep
tua
lizar

G
N
O

Solicitud
Procura de
Activos

Requerimiento
de Control de
Cambio

Definir
Implanta
r

Solicitud de
Almacen. y
Respaldo

Operar

Adecuacin de
Plataforma

P
B
S

Solicitud
Procura de
Bienes y
Servicios
Proyecto
Diferido
Cancelado

Procura de
Bienes
y Servicios

DSD3

G
A
Necesidades
de
Formacin

Procura de
Activos
DSD4

M
A
P
Respuesta de
Solicitud de
Aprobacin del
DSD2

Respuesta de
Solicitud de
Aprobacin del
DSD3

Respuesta de
Solicitud de
Aprobacin del
DSD4

A
Y
R

Solicitud de
Contrato
Reporte de
Solicitudes
Atendidas

Solucin
Tecnolgica

A
R
F

Requerimiento de
Actualizacin
Catlogo
de Servicios

Necesidades
Monitoreo
de Solucin
Implantada
Informe de
Cierre del
Proyecto
Plan de Transferencia
de Nueva Infraestructura

Fig. 13 Diagrama Macro Interfuncional del Proceso DIS

4. CAPTULO IV
EXAMEN DE LA SITUACIN
En el presente captulo se presenta el procedimiento seguido para realizar el examen de la
situacin actual de la gestin de proyectos en la Gerencia de Desarrollo e Implantacin de
Soluciones, la cual se realiza siguiendo los lineamientos de las Guas de Gerencia para
Proyectos de Inversin de Capital. El examen de la situacin actual se presenta a travs
de su objetivo, planificacin, ejecucin, resultados obtenidos y la conclusin sobre las
reas a atender.

4.1.

OBJETIVO DEL PROCESO

El objetivo del proceso es realizar una examen de la aplicabilidad de las Guas de


Gerencia para Proyectos de Inversin de Capital (GGPIC), determinando su aplicabilidad
en la gestin de proyectos de Tecnologa de Informacin (TI), para que, a partir de este
anlisis, se permita hacer una propuesta para incorporar los elementos necesarios de
metodologas propias de gestin de proyectos de TI, como los son RUP/UML, generando
una nueva metodologa especialmente diseada para la gerencia de Desarrollo e
Implantacin de Soluciones, acorde a los lineamientos de la corporacin as como
tambin, acorde a las necesidades del tipo de proyectos con los que trabaja la
organizacin.

4.2.

PLANIFICACIN DEL PROCESO

Para realizar el examen de la situacin actual se siguieron los siguientes pasos:

Primero se realiz un examen detallado de cada una de las fases de la GGPIC sus
objetivos y actividades, lo cual permiti emitir juicio sobre su aplicabilidad para
proyectos de TI.

Para el examen fueron considerados tres niveles de aplicabilidad, a saber: Alto, el


cual refiere que prcticamente toda la actividad es aplicable, Medio, el cual refiere
que una porcin importante de la actividad es aplicable, y Bajo, el cual indica que
solo una pequea parte de la actividad es aplicable.

El grado de aplicabilidad global se obtuvo calculando inicialmente el porcentaje total


alcanzado por cada nivel alto, medio y bajo de un universo de 41 actividades de las
GGPIC, para luego en base a estos resultados estimar su grado de aplicabilidad
total.

4.3.

EJECUCIN DEL EXAMEN DE LA SITUACIN

Para la ejecucin del proceso de examen se siguieron los pasos descritos en la


planificacin, dichos pasos se completaron en la elaboracin de una tabla en la cual se
engloban los resultados que analizaremos en el siguiente punto.

La tabla present los siguientes resultados:

Tabla 3 Aplicabilidad de las GGPIC en Proyectos de TI


Grado de
aplicacin en
proyectos de TI

CONCEPTUALIZAR

VISUALIZAR

FASE OBJETIVO ACTIVIDAD


Alto Medio Bajo Comentarios
ESTABLECER OBJETIVOS Y PROPSITOS
X
VERIFICAR ALINEACIN CON OBJ.
X
ESTRATGICOS
DESARROLLO PRELIMINAR
Elaborar alcance
X
Elaborar estimado de costos clase V
X
Plan de ejecucin clase V
X
Desde la perspectiva de las
GGPIC, la factibilidad se
enfoca bsicamente en el
aspecto de rentabilidad del
proyecto, sin embargo, los
proyectos de TI en PDVSA
Evaluar factibilidad
X
son en su mayora
calificados como de gastos,
razn por la cual el estudio
de factibilidad preliminar
est dirigido casi siempre a
las reas tcnica y
operacional.
ORGANIZACIN PARA FASE DE
PLANIFICACIN
Conformar equipo de trabajo

Formalizar objetivos, roles y


responsabilidades

Preparar plan para conceptualizar y


definir

SELECCIONAR OPCIONES PREFERIDAS /


FONDOS
Evaluar la tecnologa

Evaluar el sitio
Preparar el alcance conceptual y
estimados clase IV

Aplica para algunos


proyectos de
telecomunicaciones

Mas que rentabilidad de la


opcin, por considerarse
que la mayora de los
proyectos de TI en PDVSA
son calificados como de
gastos, lo que se aplica es
una evaluacin de costos.

Evaluar rentabilidad de opciones

Solicitud de fondos

Aplica en grado medio


porque en los proyectos de
TI el plan de la fase
conceptualizar se prepara
al final de la fase visualizar,
y el plan de la fase definir
se prepara al final de la
fase conceptualizar.

DESARROLLAR PAQUETE DE DEFINICIN

DEFINIR

Analizar los riesgos


Precisar alcance y elaborar el
diseo bsico
Desarrollar detalle del Plan de
Ejecucin
Preparar estimados clase II
Evaluar grado de definicin del
proyecto
Establecer guas para el control del
proyecto
Desarrollar plan de aseguramiento
tecnologico
ESTABLECER PROCESO DE CONTRATACIN
Elaborar/validar estrategia de
ejecucin/contratacin
Desarrollar documento de solicitud
de ofertas DSO

X
X
X
X
X
X
X

X
X

PREPARAR PAQUETE PARA AUTORIZACIN


DEL PROYECTO

Revisar evaluacin para solicitud de


fondos

Es medio porque las


GGPIC fueron diseadas
para proyectos mayores, y
esta actividad se refiere a
los documentos formales
para obtener recursos
definiendo si son propios o
por financieamiento. En
proyectos de TI, al ser la
mayora de gastos, solo se
introducen los estimados
en las solicitudes de
aprobacin de
presupuesto, a menos que
tenga algn rubro de
inversin, que igual se
somete a aprobacin, pero

nunca por financiamiento


externo.

Preparar documentacin para


evaluacin

Esta actividad aplica


medianamente, puesto que
para proyectos de TI, se
requiere otra
documentacin que no se
contempla en las GGPIC

IMPLANTAR

CONTRATACIN

Aprobar estrategia y lista de


empresas

Proceso de seleccin de contratistas

Revisin y firma del contrato

Administracin del contrato

Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.

EJECUCIN

Ingeniera

Procura de materiales y equipos

Materializacin del plan de


aseguramiento de tecnologas
Construccin

x
X

OPERAR

OPERACIN INICIAL
Preparacin y pruebas para el
arranque
Arranque

X
X

PRUEBAS DE GARANTA
Pruebas de capacidad

Primer perodo de aceptacin

ACEPTACIN DE INSTALACIONES
Entrega de instalaciones

En el caso de proyectos de
TI la ingeniera de detalle
debe obtenerse en la fase
de definicin
Pocos proyectos de TI
incluyen la compra de
equipos puesto que esta
funcin la asume
principalemente la gerencia
de Matenimiento de
Operaciones de AIT

ELABORACIN DE INFORMES FINALES


Cierre del proyecto

Primer informe tcnico-econmico y


divulgacin

EVALUACIN CONTNUA

% Grado de aplicabilidad

4.4.

66

22

12

Es medio porque si se
pueden especificar los
resultados tcnicos, pero
los econmicos segn las
GGPIC se trata de valores
como la Tasa Interna de
Retorno (TIR), Valor
Presente Neto (VPN), entre
otros, los cuales no aplican
en proyectos de gastos.
Este objetivo es asumido
en AIT por la organicacin
de Gestin del Servicio
(GDS)
Alto y medio superior al 80
%

RESULTADOS DEL EXAMEN DE LA SITUACIN

De acuerdo al anlisis de aplicabilidad en proyectos de Tecnologas de Informacin


realizado a la metodologa actualmente utilizada en la gerencia de Desarrollo e
Implantacin de Soluciones, las Guas de Gerencia para Proyectos de Inversin de
Capital, se obtuvo como resultado que dichas Guas son aplicables en ms de un 80%
considerando los niveles de aplicabilidad Alto y Medio.

Si bien es cierto que las GGPIC son aplicables en un alto grado a proyectos de TI, las
mismas no satisfacen completamente las necesidades que se presentan en la gestin de
este tipo de proyectos, razn por la cual entra en el estudio el aporte que en este sentido
pueden ofrecer metodologas como RUP y UML, las cuales fueron consideradas en la
elaboracin de la metodologa propuesta. Estos aportes se describirn en detalle en el
prximo captulo.

4.5.

CONCLUSIONES DEL EXAMEN DE LA SITUACIN

Como resultado del anlisis realizado durante el examen de la situacin donde se pudo
apreciar el grado de aplicabilidad de las Guas de Gerencia para Proyectos de Inversin de
Capital en proyectos de TI, la autora consider necesario el diseo de una metodologa,
que usando como base las GGPIC fuera complementada con las actividades propias de

proyectos de Tecnologa de Informacin, lo cual redundara en una mejora significativa en


la gestin de proyectos en la gerencia de DIS.

Algunas premisas que se tomaron en cuenta para la elaboracin de la metodologa fueron


las siguientes:

La Metodologa de Gestin de Proyectos de Tecnologas de Informacin en la


Gerencia DIS que se propuso, presenta una gua paso a paso que cualquier lder de
proyecto podr seguir de manera sencilla para llevar a cabo su ejecucin.

La Metodologa propuesta no pretende dar un detalle magistral del cmo deben


hacerse cada una de las actividades, pues, en cada caso, existe material
bibliogrfico donde se puede ahondar en la documentacin para cumplir con la
actividad mencionada si se requiere, incluso Internet puede proporcionar mayor
detalle si se encuentran dudas en el seguimiento de la gua.

Finalmente, una vez diseada la metodologa, la misma debe ser difundida entre el
personal encargado de manejar proyectos de TI, para garantizar el uso de un
mismo lenguaje, estndares, documentacin y resultados esperados, lo cual
facilitar, no solo la gestin de proyectos, sino el pase de testigo en casos de
movimientos

de

personal

cambios

de

responsabilidades.

5. CAPTULO V
PROPUESTA DE METODOLOGA DE GESTIN DE PROYECTOS DE
TECNOLOGA DE INFORMACIN EN LA GERENCIA DIS
En este captulo se presenta el proceso realizado para elaborar la propuesta de diseo de
una Metodologa de Gestin de Proyectos de Tecnologas de Informacin en La Gerencia
Desarrollo e Implantacin de Soluciones, de acuerdo a las necesidades detectadas en el
captulo anterior. Se expondrn la justificacin de la propuesta, los objetivos, la
planificacin del proceso para realizar la propuesta, y, finalmente se concluir con la
propuesta como tal.

5.1.

JUSTIFICACIN DE LA PROPUESTA

La Gerencia Desarrollo e Implantacin de Soluciones (DIS) tiene como objetivo


definir e implantar soluciones integrales de AIT eficientes y eficaces en trminos
de costo y oportunidad para satisfacer necesidades de PDVSA y la Nacin, que
apalanquen las metas y objetivos de PDVSA cumpliendo con lineamientos,
estndares

normas

nacionales

internacionales

adoptadas

por

la

Corporacin (GMP, 2007).

El lineamiento corporativo indica que AIT debe usar para la Gestin de Proyectos la Gua
de Gerencia para Proyectos de Inversin de Capital (GGPIC), esta gua fue diseada por
un grupo de ingenieros de PDVSA en 1999, y, aunque son adaptables a varios tipos de
proyectos, fueron creadas principalmente desde la perspectiva de proyectos de Ingeniera
y Construccin.

La experiencia en la gestin de proyectos de TI, usando como referencia las GGPIC, ha


demostrado que hay altas desviaciones en cuanto al tiempo, costo y calidad originalmente

esperados de los proyectos. Esto se debe a la carencia deactividades tcnicas


especficas, necesarias, para la ejecucin de este tipo de proyectos.

En ese contexto, surge la necesidad de contar con una metodologa de Gestin de


Proyectos de TI, basada en las GGPIC, que son el estndar de PDVSA, validando su
aplicabilidad y adaptndola con los complementos necesarios de manera de que se
genere una metodologa que realmente sirva de apoyo a la gerencia DIS en la gestin de
sus proyectos.

5.2.

OBJETIVO DE LA PROPUESTA

La propuesta, que consiste en el diseo de de una metodologa de Gestin de Proyectos


de Tecnologa de Informacin basada en las Guas de Gerencia para Proyectos de
Inversin de Capital (GGPIC) de PDVSA, tiene como objetivo apoyar la gestin de
proyectos de TI de la Gerencia de Desarrollo e Implantacin de Soluciones, mejorando su
eficiencia a travs del logro de los objetivos establecidos en los proyectos en cuanto a
tiempo, costo y calidad, parmetros conocidos como la triple restriccin.

Con esta propuesta se pretende como propsitos fundamentales:

Proveer a los lderes de proyectos de una gua paso a paso para la gestin de
proyectos, la cual facilitar su trabajo, apuntando con mayor probabilidad al logro de
los objetivos de los proyectos asignados.

Manejar un lenguaje comn en la Gerencia DIS sobre actividades, productos y


documentacin que deben generarse durante la gestin de un proyecto de TI ya
que la metodologa los especifica.

5.3.

Reducir la curva de aprendizaje de los nuevos lderes de proyecto.

PROCESO PARA REALIZAR LA PROPUESTA

Para llevar a cabo la propuesta, el primer paso fue el examen de la situacin, llevado a
cabo en el captulo anterior, de all se obtuvo que las GGPIC son aplicables en ms de un
80% a proyectos de TI.

Como siguiente paso y, luego de haber estudiado en el captulo II la metodologa base del
trabajo GGPIC, en conjunto con la metodologa a utilizar para realizar el complemento
para generar una nueva metodologa ms adecuada para proyectos de TI, RUP; se hizo
un anlisis de cmo se correlacionan las fases del ciclo de vida de un proyecto entre
ambas metodologas. Esta correlacin se puede apreciar en la siguiente figura:

Fig. 14 Fases GGPIC Vs. Fases RUP


De acuerdo a lo estudiado la diferencia ms notable se encuentra en que la metodologa
RUP tiene cuatro fases y las GGPIC cinco, sin embargo, las actividades de la fase de
preparacin, se pueden acoplar perfectamente dentro de las fases conceptualizar y definir
de las GGPIC.

Por ltimo, para elaborar la propuesta se proceder con su ejecucin, la cual consistir en
detallar las actividades que correspondern a cada fase que, segn el propsito de este
estudio, deben respetar el lineamiento corporativo de regirse por las GGPIC. En la
propuesta, se incorporan las actividades tcnicas propias de proyectos de TI, logrando de
esta manera, el objetivo que contar con una metodologa mas apropiada al tipo de
proyectos que se gestionan en la Gerencia de Desarrollo e Implantacin de Soluciones
(DIS).

5.4.

LA PROPUESTA: METODOLOGA DE GESTIN DE PROYECTOS DE


TECNOLOGA DE INFORMACIN

En este apartado se describir de manera detallada en qu consiste la Metodologa de


Gestin de Proyectos de Tecnologa de Informacin basada en las Guas de Gerencia
para Proyectos de Inversin de Capital (GGPIC) diseada para apoyar la gestin de los
proyectos en la Gerencia de Desarrollo e implantacin de Soluciones (DIS) de PDVSA.

Se entender en qu consiste cada fase del ciclo de vida, y cada una de las actividades
que debern ser seguidas para la ejecucin de un proyecto.

A lo largo de la metodologa se mencionar en varias actividades las clases que se


asignan a los diferentes estimados tanto de costos como de tiempo que se realizan en las
diversas fases, estas clases van de la clase V a la clase I. Para entender el detalle de la
precisin que implican cada una de estas clases de estimados es necesario revisar el
anexo N 1.

5.4.1.

Fase Visualizar

Las ideas que originan los proyectos pueden provenir, en cualquier momento, de cualquier
parte de la Corporacin, pero son generalmente el producto de los anlisis del ambiente
externo e interno a ella, o del anlisis F.O.D.A (Fortalezas, Oportunidades, Debilidades,
Amenazas) que se realiza como parte de los ciclos de planificacin. Estos anlisis se
efectan en equipo con la participacin de todas las organizaciones de la Corporacin y
bajo la responsabilidad integradora de las unidades de Planificacin Corporativa.

A estas ideas se les da un orden en la fase visualizar, donde se decidir si es viable


convertirlas en un proyecto y continuar con las siguientes fases.

5.4.1.1.

Identificar Responsables de los Procesos de Negocio

Acordar con el negocio quien ser el o los puntos focales para el levantamiento de los
requerimientos as como el lder funcional; el comit de usuarios seleccionado y su lder
debern participar y formarn parte del equipo durante todo el ciclo de vida del proyecto.

5.4.1.2.

Elaborar Plantilla de Datos Bsicos

Esta plantilla identifica brevemente datos importantes del proyecto, como su prioridad y el
negocio al que est dirigido. Ver anexo N 2.

5.4.1.3.

Definir el Equipo de Trabajo de la Fase Visualizar

Al inicio de la fase de la visualizacin se puede identificar con anticipacin que miembros


de otros equipos de AIT estarn participando, como por ejemplo el arquitecto de
soluciones, el analista de seguridad lgica, analista de base de datos, servidores, etc.

5.4.1.4.

Obtener / Elaborar Documento de Proceso de Negocio

Si el negocio ya tiene el proceso definido, se modela y se integra en la documentacin de


la fase visualizar. Si no lo tiene AIT debe levantarlo; es necesario tomar en cuenta que
esto impacta en gran medida el tiempo total del proyecto, ya que levantar un proceso de
negocio es prcticamente un sub-proyecto, el cual

debe

llevar un cronograma

independiente, cuyo tiempo total ser el tiempo de esta actividad en la planificacin de


todo el proyecto.

Si es necesario levantar el proceso del negocio, se puede revisar el anexo N 3 para


mayor informacin.

5.4.1.5.

Desarrollo del Documento de Soporte de Decisin 1 (DSD1)

El DSD1 es el Documento de soporte de Decisin que se genera al ejecutar todas las


actividades de la fase Visualizacin y que permitir a l o los autorizadores establecidos
aprobar si el proyecto contina o no en la siguiente fase. Para efectos de esta metodologa
la elaboracin de los diversos DSD se propone como una macroactividad dentro de la cual
se ejecutan la mayora de las actividades de cada fase, cuyos resultados se plasman en el
documento DSD al culminar cada una de ellas, y facilita el trabajo ordenado y la obtencin
del producto final de la fase para solicitar la aprobacin de continuar con la siguiente.
Grficamente se puede observar la funcin de los DSD en la siguiente figura:

Fig. 15 El Proceso de la Toma de Decisin


5.4.1.5.1.

Realizar Resumen Ejecutivo

5.4.1.5.1.1. Identificar Necesidades y Oportunidades

En esta actividad se identifica y documenta la necesidad/oportunidad y se valida que ella


refleje correctamente un requerimiento del negocio. Una vez documentada, se valora y
valida con el usuario calificado e involucrados, en funcin de la importancia potencial que
representa para el negocio.

Esencialmente en esta actividad se evala la problemtica u oportunidad de mejora y se


determinan necesidades de alto nivel. Se respondern y documentarn las respuestas a
preguntas bsicas: qu? y para qu? dnde?
La ocurrencia de esta actividad es constante en el tiempo ya que los requerimientos se
reciben de esa forma y la exploracin de necesidades y oportunidades ocurre en igual
manera. El producto fundamental de esta actividad es una Documento de Necesidades y/u
Oportunidades (DNO) identificada, valorada y validada.

5.4.1.5.1.2. Definir Antecedentes

Describir brevemente los antecedentes del problema: Soluciones previas, evolucin del
problema en el tiempo, descripcin de la situacin que da origen a la necesidad.

5.4.1.5.1.3. Planteamiento de la Necesidad y/u Oportunidad

Elaborar una lista enumerada con la descripcin de las necesidades, oportunidades y/o
problemas del proceso de negocio bajo estudio.

Se debe tener presente que las necesidades, oportunidades y/o problemas pueden darse
por: lineamientos corporativos, por interoperabilidad, por rendimiento y/u obsolescencia
tecnolgica.

Problemas: Describir los problemas encontrados en el escenario, indicando el impacto


que causan.

Necesidades: es la carencia que manifiesta un usuario u organizacin para cumplir o


alcanzar un objetivo determinado.

Oportunidades: es la carencia o necesidad del usuario que es identificada o detectada


por el consultor de negocios asignado por AIT.

5.4.1.5.1.4. Definir Propsito / Objetivos y Metas del Proyecto

Indicar cul es la finalidad del proyecto, identificando claramente el objetivo de la ejecucin


del mismo. En este punto se debe ser cuidadoso, puesto que en oportunidades se puede
confundir que la implantacin o desarrollo de una nueva tecnologa de por s sea el
objetivo, cuando realmente se trata de la mejora del proceso X o Y que se lograr en el
negocio a travs de la implantacin de una determinada tecnologa.

5.4.1.5.1.5. Definir Objetivos de la Fase de Visualizar

Indicar la finalidad de esta fase, qu se espera lograr la culminar la fase de visualizacin.

5.4.1.5.1.6. Definir Situacin Actual

Para definir la situacin actual es necesario revisar el proceso de negocio, el cual se


obtuvo o se levant en el paso 4.1.4.

Es importante destacar que los negocios son responsable de tener sus procesos
levantados, y proporcionarlos a AIT como un insumo, ya que si no lo tienen esto puede
convertirse en un proyecto por si mismo.

5.4.1.5.1.7. Definir Alcance Preliminar

Se deben delimitar las necesidades u oportunidades, indicando cul es la expectativa del


usuario al abordar el proyecto.

Luego de que los objetivos y propsitos del proyecto han sido establecidos, y los grupos
de planificacin han constatado que cumplen con las estrategias y lineamientos del plan
de negocios, se debe elaborar un alcance preliminar, a fin de utilizarlo de base para
estimar su costo y tiempo de ejecucin. Estos estimados se utilizarn en el anlisis para
confirmar la factibilidad econmica del proyecto y la conveniencia de proseguir con su
desarrollo.

5.4.1.5.1.8. Elaborar Catlogo de Requisitos Generales

Se deben listar los requerimientos que se hayan identificado de acuerdo al problema,


oportunidad o necesidad detectada, en la siguiente fase estos requerimientos se
levantarn en detalle.

5.4.1.5.1.9. Declarar Visin del Negocio

Se debe

registrar la forma como el cliente visualiza que se puede solucionar su

necesidad, dejando constancia de la concepcin que tiene, la cual, posteriormente se


evaluar dentro de las posibles soluciones si es factible.

5.4.1.5.1.10. Priorizacin de los Requisitos Funcionales

Los requisitos funcionales, listados segn el punto 4.1.6.1.7 deben priorizarse siguiendo el
siguiente esquema:

Tabla 4 Atributos de Priorizacin


Atributos de Priorizacin
ID

Requisitos

Prioridad

Complejidad

Esfuerzo

Estabilidad

del Cliente
<identificador

<nombre descriptivo del

requisito>

requisito>

Prioridad del Cliente

Este atributo se refiere a la relativa importancia de implementar la caracterstica definida


en relacin al beneficio del negocio. En la tabla se muestra los posibles valores que puede
tomar este atributo.

Tabla 5 Valores de Atributos para Prioridad del Cliente

Alta

Baja

Es un requisito crtico y afecta directamente al negocio o


cliente.
Es deseable, pero no se ha identificado el valor para el
negocio o para el cliente.

Complejidad

Este atributo se refiere a la bsqueda del nivel de abstraccin requerido para comprender
el requerimiento durante el proceso de anlisis y diseo.

Tabla 6 Valores de Atributos para Complejidad

Alta

Baja

Requiere un alto nivel de abstraccin para la comprensin


del requerimiento.
Requiere un bajo nivel de abstraccin para la comprensin
del requerimiento.

Esfuerzo

El grupo de desarrolladores analiza el nivel de esfuerzo de la caracterstica, tomando en


cuenta el tiempo y los recursos necesarios, las lneas de cdigos requeridas, el nmero
estimado de personas; por lo tanto el esfuerzo es proporcional a la cantidad de horas
invertidas para satisfacer el requerimiento. En la tabla se muestra los posibles valores que
puede tomar este atributo.

Tabla 7 Valores de Atributos para Esfuerzo


Alto

Alto esfuerzo, mayor cantidad de h/h para solucionar.

Bajo

Bajo esfuerzo, menor cantidad de h/h para solucionar

Estabilidad

Descripcin general de la probabilidad de cambio del requerimiento. En la tabla se


muestra los posibles valores que puede tomar este atributo.

Tabla 8 Valores de Atributos para Estabilidad


Alta

Poca probabilidad de cambios.

Baja

Mucha probabilidad de cambios.

5.4.1.5.1.11. Definir Caractersticas Generales

Son condiciones o capacidades que deben estar incluidas dentro de la solucin. Estas, se
deben expresar en lenguaje natural de forma concreta y enumerada.

Por ejemplo:
Tabla 9 Ejemplo de Caractersticas Generales de la Solucin TI
Id.

Caracterstica

Caracterstica

Tiempo de respuesta para realizar una transaccin debe ser


menor a un segundo.

Observacin
El tiempo de respuesta
actual es aproximadamente
8 segundos.

El proceso de negocio
2

El proceso de negocio requiere incorporar nuevos atributos en la

actualmente no contempla

solicitud de informacin de un servicio.

los atributos requeridos del


servicio.

La aplicacin debe ser cross browser para garantizar los


3

estndares usabilidad independientemente del navegador


empleado.

Actualmente la aplicacin
nicamente se ejecuta
adecuadamente en un
navegador propietario.

5.4.1.5.1.12. Justificacin

Describir los beneficios que se obtendrn con la ejecucin exitosa del proyecto e indique
cmo apoya los objetivos estratgicos del negocio.

5.4.1.5.1.13. Premisas Consideradas

Consideraciones del negocio: Indicar alguna consideracin que el negocio solicita


tomar en cuenta, por ejemplo algn proceso que no deba cambiar en su estructura
fundamental, o por el contrario algn proceso que seale deba cambiarse
radicalmente para optimizarlo

Consideraciones de Tecnologa: determinar en conjunto con el representante del


negocio (usuario funcional) los siguientes aspectos:
Usuarios Totales: representa la cantidad de usuarios que interactuarn con
la solucin.
Localidades: ubicacin geogrfica donde se encuentran los usuarios.
Dispositivos involucrados: lista de todos los dispositivos que interactuarn
con la solucin.
Intranet/Extranet: indica si la solucin es del mbito interno o externo de la
red corporativa.

Limitaciones: listar las posibles limitaciones de la solucin.

Determinar pre-factibilidad tcnica de los requerimientos: esta factibilidad no es


un estudio detallado sino una primera opinin del consultor de negocio apoyndose
con lderes de proyecto, consultores tecnolgicos, seguridad AIT, etc., que por su
experiencia puedan dar sus observaciones. De acuerdo a este resultado puede

surgir una investigacin exhaustiva y se puede preparar un estudio de factibilidad


detallado en la siguiente.

Recomendaciones: proponer las soluciones visualizadas a implantar, segn las


mejores prcticas de ingeniera, metodologas y nuevas tecnologas, que permitan
desarrollar el proyecto/solucin y alcanzar los objetivos propuestos de acuerdo al
resultado del anlisis de pre-factibilidad.

5.4.1.5.1.14. Definir Estrategias

Contratacin: prever si se requiere contratar recursos en la siguiente fase por


ejemplo para levantar requerimientos, hacer evaluaciones de seguridad, realizar
pruebas de concepto, etc., as como sugerir tambin qu estrategia de contratacin
puede ser utilizada (si aplica) para la ejecucin y operacionalizacin del proyecto.

Ejecucin: la estrategia de ejecucin debe dar respuesta a los siguientes aspectos:


La divisin de la ejecucin en partes o reas.
Ejecucin con recursos propios o contratados.
Fechas de inicio y finalizacin de cada porcin del trabajo.
El balance adecuado entre la magnitud del proyecto y los recursos
requeridos.

5.4.1.5.2.

Identificacin de Servicios

Identificar los servicios que puedan ser consumidos o provistos por los componentes
funcionales involucrados en la solucin como se puede observar en la siguiente tabla
ejemplo:

Tabla 10 Identificacin de Servicios


Nombre

Unidad de

Proceso(s) de

Caso(s) de uso de

Servicio

Negocio

Negocio

Negocio

<Nombre

del

Servicio>

<Unidad

de

Negocio

Restriccin:
nombre

el

custodio

del

servicio>

<Procesos
Negocio

del

requieren

de
que
el

servicio>

Proveedor(es)

<Casos de uso de

<Aplicacione

<Componentes

Procesos

de

Funcionales

Negocio

que

Componente

Aplicaciones

Proveedor(es)

requieren

servicio es nico

Cliente(s)

el

servicio>

Funcionales

en el repositorio.

clientes

del

servicio>

del

Servicio>
crearCliente

Data Maestra

Creacin

de

Crear Cliente

Data Entry

Facturador

RESET

ERP FI/CO

Clientes
asientoContable

Finanzas

Asientos

Realizar

Contable

Contable

Asiento

GADET

No necesariamente todas las soluciones de TI estn basadas en servicios, por lo tanto


esta actividad se ejecuta si aplica de acuerdo al proyecto.

5.4.1.5.3.

Diagrama de Secuencia

[Si aplica] Realizar el diagrama de secuencia que describa el escenario de la solucin


contemplando los servicios y los componentes funcionales/aplicaciones identificados. El
objetivo de realizar el diagrama de secuencia es que el negocio valide las interacciones
entre componentes funcionales y servicios en el proceso de negocio.

Fig. 16 Diagrama de Secuencia

5.4.1.5.4.

Establecer Consideraciones de Mercado

Definir las tendencias del mercado en la solucin de la necesidad u oportunidad planteada


(estudios de Gartner, etc.)

5.4.1.5.5.

Anlisis Comercial / Anlisis de Prefactibilidad Econmica (Clase V)

En el captulo IV, donde se examin la situacin, se seal que en AIT la mayora de los
proyectos son considerados de gastos, sin embargo, si el proyecto tiene tal magnitud de
componentes que representen que el proyecto sea considerado como de inversin, debe
cumplir con el anlisis comercial.

5.4.1.5.5.1. Determinar Indicadores Econmicos

Las propuestas, para efectos de conformar la cartera de inversin, debern clasificarse en:

Generan Ingresos (GI)

Generan Ahorros (AH): Las propuestas que generan ahorros debern justificarse
por s mismas mediante una evaluacin a nivel unidad de negocio, que compare la
situacin actual con la que ocurrira de ejecutarse la propuesta. El DSD del
proyecto debe presentar el flujo de caja de la situacin actual, el flujo de caja
propuesto, el flujo de caja diferencial y la metodologa para medir los beneficios que
ste aporta una vez entrado en operacin el proyecto. Los indicadores econmicos
debern ser calculados a partir del flujo de caja diferencial.

Consolidan Produccin (CP)

Asociada (AS)

Proyectos Inters Corporativo (PIC)

Continuidad Operacional
Reemplazo/Mantenimiento (RM)
Normativas/Regulatorias (COPNR)
Otras Inversiones de Continuidad Operacional (COPOT)

Exploracin (EX)

Asociaciones/Empresas Mixtas (EM)

Investigacin y Desarrollo (ID)

Adicionalmente se deben determinar:

Costos de Inversin

Costos de operacin referenciales

Flujo de caja

5.4.1.5.6.

Elaborar Estimado de Costos Clase V

Un estimado de costos clase V es un estimado con una precisin del tipo orden de
magnitud, el cual se utiliza en la planificacin a mediano plazo para establecer si los
proyectos renen los mritos suficientes para proseguir su desarrollo.

El mismo deber incluir un estimado de costos de mayor precisin (clase II) de los fondos
requeridos para el desarrollo de la fase Conceptualizar y de los trabajos de laboratorio
necesarios para mejorar la definicin del proyecto. Estos fondos debern ser solicitados y
aprobados antes de proseguir con dicha fase. Ver anexo N 1.

Informacin requerida

Este estimado debe basarse en una definicin global, a grosso modo, del proyecto y de
sus principales unidades de proceso, en la que la informacin disponible se limite
esencialmente a:

Tamaos o capacidades propuestas


Ubicacin geogrfica
Especificacin preliminar de insumos y productos
Fechas tentativas de inicio y finalizacin del proyecto

Mtodo de estimacin

Se basa en datos histricos de costos que provienen de proyectos similares ejecutados o


curvas de costos de unidades de proceso similares (extrapolacin estadstica),

correlacionadas por su capacidad y corregidas por ndices de precios, factores de


ubicacin geogrfica, etc.

Precisin y confiabilidad

Es un estimado del tipo orden de magnitud y no tiene una confiabilidad definida sino que
sta depende de la calidad de la informacin disponible de proyectos similares ya
completados o que estn en desarrollo y de la pericia con que se evalen, se ajusten por
factores o se escalen, los datos de costo.

5.4.1.5.7.

Elaborar Plan de Ejecucin del Proyecto (PEP) Clase V

El PEP documenta y comunica esos asuntos importantes no tcnicos a otros participantes


del proyecto. El PEP debe destacar la panormica total tomando en consideracin todas
las facetas del proyecto y aquellas cosas que pueden influenciar en su ejecucin.
EL PEP debe contener al menos los siguientes temas:

Sumario

Propsito

Antecedentes del Proyecto

Temas Crticos

Programa Ejecutivo de Ejecucin

Plan de Contratacin

Control Del Proyecto

Organizacin Del Proyecto

Tecnologa/Ingeniera

Adquisicin de Materiales, Equipos u Horas Hombre

Construccin en Campo (si aplica)

Coordinacin para El Arranque

Informes

A lo largo de la ejecucin del proyecto, resulta conveniente asignarle a este plan, una
clasificacin similar que concuerda con la del estimado de costos disponible para el
momento.

El PEP en la clase visualizar es clase V y se utiliza con el propsito de respaldar la toma


de decisiones, la informacin aqu presentada es preliminar y se ajusta en las siguientes
fases.

5.4.1.5.8.

Prepararse para la Siguiente Fase > Conceptualizar

Elaborar plan con una precisin clase II para ejecutar la prxima fase
(Conceptualizar).

Definir recursos requeridos para ejecutar la prxima fase (Conceptualizar) clase II.
Se deben precisar los recursos que sern necesarios para ejecutar la siguiente
fase. Para esto se puede usar como referencia el ejemplo que se incluye en el
anexo N 4.

5.4.1.5.9.

Registrar los Datos y Documentacin del Proyecto en la Base de Datos


de Configuracin.

La Base de Datos de Configuracin est conformada por dos aplicaciones AIR y


Dimensions, la primera se utiliza principalmente como repositorio de documentacin e
informacin de los Elementos de Configuracin y Dimensions es un repositorio de
versiones de software.

Un Elemento de Configuracin (EC) es todo componente de hardware o


software de la infraestructura de AIT de la corporacin o su documentacin, que
est bajo el control del proceso de Gestin de la Configuracin (GC). Algunos
ejemplos de EC son: aplicaciones, computadoras personales, servidores,
switches, dispositivos de campo, entre otros. (Gestin de la Configuracin, 2007)

Para que un proyecto sea posteriormente recibido por el personal de operaciones de AIT,
el proceso de Gestin de la Configuracin, exige cumplir con este paso, de lo contrario la
nueva solucin no ser aceptada.

5.4.1.6.

Entrega de DSD1

Revisin del DSD1: La revisin de un DSD1, y de todos los DSD, la realiza el


equipo de Calidad de la Gerencia DIS quien definir si el documento cumple con la
calidad esperada y el contenido que se requiere para ser aceptado.

Aceptacin de DSD1: en este punto, dependiendo del aprobador que corresponda,


se decide si se acepta el proyecto para continuar con la siguiente fase, esta
aceptacin debe venir tanto por parte del negocio como por parte de AIT.

5.4.2.

Fase Conceptualizar

Los productos de la fase de visualizar constituyen el insumo de trabajo para continuar con
el desarrollo del proyecto y ejecutar la fase de conceptualizar.
El propsito de esta fase es la seleccin de la(s) mejor(es) opcin(es) y la mejora en la
precisin de los estimados de costos y tiempo de implantacin. En esta fase se detallan
adems los requerimientos del negocio para la nueva solucin de TI.

Las actividades que estn acompaadas de la palabra actualizar, se refiere a actividades


que ya se ejecutaron previamente y que solo es necesario validar si hubo algn cambio o
mejora que sea necesario incorporar, de lo contrario se mantiene igual que en la fase
anterior. Estas actividades no pretenden ser repetitivas, al contrario se mencionan en
varias fases debido a que es necesario incorporarlas en la documentacin que se genera
en cada unas de ellas, como los Planes de Ejecucin de Proyectos, o Documentos de
Soporte de Decisin.

5.4.2.1.

Conformar Equipo de Trabajo

Incorporar nuevo personal de proyectos al equipo

Definir el Organigrama/Roles y Responsabilidades para el equipo

Identificar equipos de apoyo

5.4.2.2.

Desarrollo del DSD2

5.4.2.2.1.

Realizar Resumen Ejecutivo

5.4.2.2.1.1. Definir Objetivo de la Fase Conceptualizar

Indicar cual es la finalidad de esta fase, que se lograr al completarla.

5.4.2.2.1.2. Definir Antecedentes (actualizar)


5.4.2.2.1.3. Definir Propsito / Objetivos y metas del Proyecto (actualizar)
5.4.2.2.1.4. Definir Situacin Actual (actualizar)
5.4.2.2.1.5. Definir Alcance del Proyecto (actualizar)
5.4.2.2.1.6. Justificacin (actualizar)
5.4.2.2.1.7. Definir Estrategias y Recomendaciones para Evaluacin de Soluciones

Se deben evaluar las alternativas de solucin, en este punto debe explicarse la estrategia
que se utilizar para realizar la evaluacin de las posibles soluciones, esto se refiere a los
pasos que se seguirn, metodologas y recursos necesarios para completar con xito la
evaluacin de cada alternativa y el anlisis de los resultados para realizar el informe final
de recomendacin de solucin.
Incluir las recomendaciones relacionadas con lo desarrollado en esta seccin, por
ejemplo, para las pruebas de cada alternativa de solucin podran requerirse acuerdos de
confidencialidad, tambin necesidades de instalaciones, espacio y equipos.

En caso de pruebas de concepto, podran ser convenientes acuerdos con los proveedores
de la tecnologa para compartir los gastos generados, recursos, equipos e instalaciones.

Otro punto a considerar es la transferencia de conocimientos del negocio a los encargados


de realizar tanto la evaluacin de las soluciones, como las pruebas de concepto. Del
mismo modo, se debe contemplar la transferencia de conocimientos de terceros, que
participen en la fase de conceptualizacin, hacia el personal de PDVSA.

5.4.2.2.2.

Plan para Ejecutar Fase Conceptualizar Clase II (actualizar)

5.4.2.2.3.

Elaborar Proceso de Negocio Propuesto (si aplica)

Esta actividad aplica si el proceso propuesto difiere del proceso de negocio original.

Se debe colocar el diagrama de proceso deseable o propuesto, cadena de valor y


diagrama de entorno en caso de que el proyecto considere modificar, optimizar o
evolucionar los procesos del negocio, de lo contrario, colocar el mismo de la fase
visualizar

De la misma manera, es necesario colocar el diagrama de actividades del proceso


deseable o propuesto, en caso de que el proyecto considere modificar, optimizar o
evolucionar los procesos del negocio, de lo contrario, al igual que en el punto anterior, se
coloca el mismo de la fase visualizar.

Lo mismo aplica para el Modelo de Casos de Uso del proceso del negocio, es decir, si el
modelo propuesto difiere del original, se diagrama en esta seccin, sino se coloca el
mismo.

5.4.2.2.4.

Especificacin de Requerimientos

5.4.2.2.4.1. Determinar Componentes Funcionales

Si aplica, modificar, incorporar, desincorporar los componentes funcionales involucrados


en el proceso de negocio.

5.4.2.2.4.2. Identificar Intercambio de Datos

Si aplica, identificar los detalles fsicos de los intercambios de datos entre los
componentes funcionales o aplicaciones involucradas en el proceso de negocio que
apoyarn las decisiones de diseo. Deben documentarse modificaciones, incorporaciones
o desincorporaciones de intercambios de datos del proceso de negocio.

Tabla 11 Identificacin de Intercambio de Datos


Orden

Origen

Des-

Descripcin

tino

Datos Inter-

Sncrono/

En

For-

Volu-

Tiempo

cambiados

Asncrono

lnea /

mato

men

de Res-

Batch
1

RMCA

CTC

Envo

de

Segn

rdenes

de

definicin

de

Segn

Sncrono

En lnea

puesta
XML

8000 por

1.5

da

segund

<=

N/A,

pago
2

CTC

RMC

Envo

os
Asncrono

Batch

Archiv

Orden

Origen

Des-

Descripcin

tino

Datos Inter-

Sncrono/

En

For-

Volu-

Tiempo

cambiados

Asncrono

lnea /

mato

men

de Res-

Batch
A

pagos

definicin

diario

cobrados

puesta
o

31500

batch

plano

registros
mensuales

CTC

RMC

Envo

pagos

de

Segn

Asncrono

definicin

Batch

Archiv

<=

N/A,

diario

31500

batch

plano

registros

rechazados

mensuales

5.4.2.2.4.3. Especificar Servicios Web

[Si aplica] Definir y especificar de los servicios identificados para intercambios de datos
entre componentes funcionales/aplicaciones/actores involucrados en el proceso de
negocio. Deben documentarse modificaciones, incorporaciones, desincorporaciones de
servicios involucrados en el proceso de negocio.

Tabla 12 Especificacin de Servicios


Nombre

Unidad

Servicio

Negocio

<Nombre

del

<Unidad

Servicio>

Negocio

Restriccin:

custodio

el nombre del

servicio>

servicio
nico

de

de

del

Proceso(s)

Caso(s) de uso

de Negocio

de Negocio

<Procesos de

<Casos de uso

<Aplicacion

<Componentes

Negocio

de Procesos de

es

Funcionales

Negocio

Component

Aplicaciones

es

Proveedor(es)

Funcionales

del servicio>

que

requieren

el

servicio>

es
en

que

requieren

el

servicio>

el

Cliente(s)

Proveedor(es)

clientes del

repositorio.

Servicio>

asientoContab

Finanzas

le

Asientos

Realizar Asiento

RESET

Contable

Contable

GADET

ERP FI/CO

Tabla 13 Especificacin de Funcionalidad de Servicios


Funciona-

Tipo de

lidad del

exposicin

servicio

del Servicio

Servicio
Concreto

En Lnea /
Sincrona

Archivo
plano

Transaccio-

Ca-

nal / Batch

nal

Transaccional

WS

Artefact
o
Contrato

ASC.crear
Cliente_4_
Adaptacin

DE

crearClie
Sncrono

En Lnea

nte.wsdl

5.4.2.2.4.4. Especificacin de Contratos

[Si aplica] La interaccin bsica en un modelo basado en servicios es entre clientes y


proveedores del servicio. El acuerdo entre ambas partes, denominado contrato,
especfica los detalles del servicio que el proveedor ofrece, permitiendo una relacin
desacoplada entre las partes. Al garantizar el cumplimiento del contrato en las interfases
entre las aplicaciones, se permite que cada parte pueda implementar de manera
independiente su parte del contrato.

El contrato establece el acuerdo de intercambio de informacin entre las partes, as


como la relacin tcnica entre las partes. Un contrato de servicios debe contener:

Tabla 14 Contenido de un Contrato de Servicios


Requerimientos

Requerimientos No Funcionales

Polticas del Servicio

El contrato debe especificar

El contrato puede especificar: 1. la

El contrato puede especificar las

la data y la funcionalidad

responsabilidad de los proveedores

polticas de intercambio que aplican

provista por el proveedor del

para proveer la data y la funcionalidad;

a un tipo o nmero de contrato: 1.

Servicio.

2.

los

quin accede a un proveedor; 2.

consumidores; 3. consideraciones de

procedimientos de seguridad que los

seguridad,

participantes deben cumplir.

Funcionales

responsabilidad

calidad

de

de

servicio,

disponibilidad, entre otros.

Este contrato debe estar especificado en formato No XML (Extensible Markup Language)
en esta fase, para documentar los datos y sus tipos provistos en un servicio, as como los
aspectos no funcionales y polticas.

El contrato debe especificar la peticin y respuesta de un servicio, transformaciones que


deban realizarse de los datos, as como cualquier cabecera que deba incorporarse.

5.4.2.2.4.5. Definir Actores

Para describir a los actores del sistema se utiliza una tabla como la que sigue a
continuacin. El cdigo del actor reseado como ACT.# se refiere al prefijo ACT. Seguido
por el nmero de actor asignado. La XX se refiere al nombre del Actor. La descripcin se

refiere a una breve resea del rol del actor para el sistema y las fuentes son los
involucrados del negocio que ayudaron a definir y describir al actor.

Tabla 15 Descripcin de Actores


Actor:

ACT.# XX

Descripcin:

<descripcin del actor>

Responsabilidades:

<Responsabilidad 1>

<Responsabilidad 2>

Fuentes:

<Stakeholders que identificaron y contribuyeron a definir al actor>

5.4.2.2.4.6. Definir Permisologa de los Actores

De acuerdo a los actores definidos y sus responsabilidades se determinarn los diferentes


perfiles a crear en la solucin que, posteriormente, si se trata de una aplicacin Web de la
intranet (que son la mayora de los casos) y segn los lineamientos bases de seguridad
lgica, se convertirn en grupos dentro del directorio activo.

5.4.2.2.4.7. Elaborar Modelo de Casos de Uso

Los casos de uso modelan la funcionalidad del sistema agrupndola en descripciones de


acciones ejecutadas por un actor para obtener un resultado.

Fig. 17 Modelo de Casos de Uso

5.4.2.2.4.8. Elaborar Especificacin de Casos de Uso del Sistema

La especificacin de los casos de uso viene dada por una tabla donde se sealan los
siguientes detalles:

Tabla 16 Especificacin de Casos de Uso


Caso de uso

CU.1 XX

Fuentes

<Stakeholders que proporcionaron informacin de esta funcionalidad>

Actor

Act.# <nombre de los actores> [(<Pseudnimos>)] [ secundario]

Descripcin

Act.# <Descripcin del caso de uso>

Flujo bsico

1.

Titulo del paso

Descripcin del paso.


2.

Titulo del paso

Descripcin del paso.


Flujos alternos

1.

Titulo del FA

Descripcin del FA
2.

Titulo del FA

Descripcin del FA.


Pre condiciones

1.

Titulo del Precondicin

Descripcin del PRC


Post condiciones

1.

Titulo del Poscondiciones

Descripcin de la PTC
Requerimientos

1.

especiales

Descripcin del requerimiento o porqu se enlaza a el desde este caso de uso

Puntos

de

Inclusin
Puntos

1.

Titulo del requerimiento

Ttulo del punto de inclusin

Descripcin del punto de inclusin


de

1.

Ttulo del punto de extensin

extensin

Descripcin del punto de extensin

Notas

1.

Titulo de la Nota

Descripcin de la nota

5.4.2.2.4.9. Elaborar Especificacin de Requerimientos de Informacin

Los requerimientos de informacin deben ser provistos segn la tabla N 17.

Tabla 17 Requerimientos de Informacin


Requisito de Informacin
RI-<id>:

<nombre descriptivo>

Requisito de Informacin
RI-<id>:

<nombre descriptivo>

Versin:

<N de la versin actual> (<fecha de la versin actual>)

Autores:

<autor de la versin actual> (<organizacin del autor>)

Fuentes:

<fuente de la versin actual> (<organizacin de la fuente>)

Descripcin:

El sistema deber almacenar la informacin correspondiente a <concepto relevante>.

Componente Funcional

Componente funcional con el que esta relacionado el R.I

Atributos:

Nombre

Descripcin

Tipo

Longitud

<nombre

<breve descripcin del <tipo

de <longitud

descriptivo>

atributo>

dato>

Procedencia
<procedencia del

del atributo> atributo>

5.4.2.2.4.10. Elaborar Especificacin de Requerimientos No Funcionales

Los requerimientos no funcionales deben incluirse segn el siguiente modelo:

Tabla 18 Requerimientos No Funcionales


Identificador
RI-<id>

Descripcin

Nombre
<nombre descriptivo>

El

sistema

deber

sistema>

<capacidad

Fuente
del <autor de la versin
actual>

5.4.2.2.4.11. Realizar Matriz de Apoyo a la Toma de Decisiones para el Proyecto


(actualizar)

Esta actividad ya viene dada por la priorizacin de requerimientos realizada en la fase


Visualizar, por lo tanto solo se debe validar con los usuarios funcionales si han cambiado
de opinin con respecto a la prioridad de algn elemento de la tabla originalmente
elaborada.

5.4.2.2.4.12. Elaborar Guin de Interfaz de Usuario

Consiste en elaborar un conjunto de pantallas preliminares diseadas para la solucin.


Estas pantallas o vistas no requieren una estricta navegabilidad o algn tipo de

funcionalidad. Esta seccin nicamente aplica para soluciones que impliquen un Sistema
de Informacin con interfaces de usuario.

5.4.2.2.4.13. Premisas Consideradas


5.4.2.2.4.13.1.

Consideraciones del Negocio (actualizar)

5.4.2.2.4.13.2.

Consideraciones de Tecnologa (actualizar)

5.4.2.2.4.14. Elaborar Matriz de Evaluacin que se Aplicar a las Posibles Soluciones

Esta matriz debe se elaborada solo cuando existen varias soluciones en el mercado o
dentro de la Organizacin, que puedan dar respuesta a la necesidad solicitada, por lo que
es necesario compararlas, evaluarlas, y decidir la mejor opcin para lograr el objetivo del
proyecto.

Los requisitos sern valorados de acuerdo a las particularidades y prioridades de cada


proyecto.

5.4.2.2.4.15. Definir Arquitectura y Evaluar Solucin


5.4.2.2.4.15.1.

Describir Solucin Propuesta

Se debe realizar una descripcin detallada de la solucin que se va a proponer,


considerando:

Tipo Solucin: Desarrollo nuevo, adaptacin, ajuste, procura

Consideraciones Preliminares: Son las premisas que debe cumplir la solucin


con el objeto de garantizar su xito.
Usuarios Concurrentes: Nmero de usuarios que interactan con la
aplicacin al mismo tiempo.
Volumen de Datos: Cantidad de informacin que viaja de la base de datos a
la aplicacin o viceversa.
Usuarios Totales: representa la cantidad de usuarios que interactuarn con
la solucin.
Localidades: ubicacin geogrfica donde se encuentran los usuarios.
Interfaces: lista de todos los sistemas o dispositivos que interactuarn con la
solucin.

Intranet / Extranet: indica si la solucin es del mbito interno o externo de la


red corporativa.

5.4.2.2.4.15.2.

Investigar Antecedentes de la Solucin

Referencias a trabajos similares que se hayan realizado dentro de la organizacin o fuera


de esta.

5.4.2.2.4.15.3.

Definir Alcance de la Solucin Propuesta

El alcance indicar claramente hasta donde llegar la solucin propuesta, as como


tambin lo que no contemplar.

5.4.2.2.4.15.4.

Desarrollar Marco terico referencial

Incluir un marco terico que pueda ayudar a la toma de decisiones ya que en este proceso
pudieran participar personas no expertas en la materia.

5.4.2.2.4.15.5.

Especificar Estndares de la Solucin

Indicar qu estndares, polticas y lineamientos sern considerados en la solucin. En


esta actividad es importante recalcar que, por ser PDVSA un organismo del estado, las
soluciones de TI deben apuntar, en el caso de software particularmente, a cumplir con el
decreto 3.390, el cual tiene por lineamiento el uso de tecnologas libres, evitando, a menos
que no haya un sustituto an y que sea de vital importancia para la continuidad operativa o
estratgica del negocio, el uso de tecnologas propietarias.

5.4.2.2.4.15.6.

Aplicar Matriz de Evaluacin a la Solucin

Aplicar a la solucin la matriz de evaluacin elaborada anteriormente en esta fase para


validar que tanto satisface las necesidades del proyecto

5.4.2.2.4.15.7.

Solicitar Consultora de Seguridad Lgica

Esta actividad se realiza con el objetivo de que Seguridad Lgica, realice una revisin de
los requerimientos y pueda establecer los criterios mnimos de seguridad que debe cumplir
la solucin esperada para que la misma sea considerada como viable y segura para
PDVSA.

5.4.2.2.4.15.8.

Documentar y Validar Arquitectura de Hardware y Software de la


Solucin

Describir y graficar la arquitectura tecnolgica (software y hardware) en la que se va a


desarrollar el proyecto.

5.4.2.2.4.15.9.

Definir Tiempos de Desarrollo de la Solucin / Cronograma para esta


Solucin

Realizar en este paso un cronograma preliminar de las siguientes fases del proyecto de
acuerdo a la solucin que se est evaluando

5.4.2.2.4.15.10. Definir Productos

Determinar de acuerdo al tipo de proyecto cuales sern los productos entregables,


validando con mantenimiento de plataforma que sean los necesarios para que luego de
que el proyecto termine, esta organizacin tenga toda la informacin indispensable para
garantizar la continuidad operativa de la nueva solucin.

5.4.2.2.4.15.11. Elaborar Matriz de Resultados de la Evaluacin

Una vez aplicada la matriz de evaluacin a cada una de las soluciones, se debe realizar en
este punto la matriz con los resultados de las mismas, que en conjunto con los dems
anlisis, determinarn la solucin a recomendar. Culminando con la elaboracin de un
informe con el resultado de la evaluacin y la solucin recomendada.

5.4.2.2.4.15.12. Solicitar Recursos a Mantenimiento de la Plataforma (MAP)

Esta actividad consiste en que, luego de haber seleccionado la solucin tecnolgica, se


debe informar a MAP cuales son los recursos necesarios de TI en general para dicha
solucin (servidores, disponibilidad de ancho de banda, etc.) de manera de que esta
organizacin planifique la recepcin de esta nueva solucin en su plataforma o alerten en
caso de que no dispongan de los recursos para tomar las acciones que competan, como
por ejemplo la adquisicin de equipos con presupuesto del proyecto si fuera necesario, lo
cual a su vez se reflejara en un cambio de alcance o, por el contrario validar si la compra
de equipos debe asumirla MAP directamente.

Asimismo, MAP debe considerar tener recursos con las mismas caractersticas para el
ambiente de desarrollo, donde se irn instalando las diferentes versiones de avance para
hacer pruebas. Ver planilla de solicitud en el anexo N 5.

5.4.2.2.5.

Prepararse para la Siguiente Fase > Definir

En esta preparacin se deben tomar en cuenta los siguientes aspectos:

Determinar roles y responsabilidades preliminares para la fase Definir.

Establecer estrategia de contratacin y procura para la fase Definir.

Realizar estimado de costos clase II de la siguiente fase (ver anexo N 1).

Elaborar cronograma fase Definir clase II.

5.4.2.2.6.

Elaborar Estimado de Costos Clase IV del Proyecto

5.4.2.2.7.

Elaborar Plan de Ejecucin del Proyecto (PEP) (actualizar)

5.4.2.2.8.

Incluir los Datos y Documentacin del Proyecto en la Base de Datos de


Configuracin (actualizar)

5.4.2.3.

Entrega de DSD2

El proceso de entrega del Documento de Soporte de Decisin se explic en la fase


Visualizar, lo mismo aplica para la entrega de este documento en las dems fases,
considerando los siguientes pasos:

Revisin del DSD2.

Aceptacin del DSD2.

5.4.3.

Fase Definir

Las decisiones tomadas en la fase de Conceptualizacin constituyen el insumo de trabajo


para continuar con el desarrollo del proyecto y ejecutar la fase de definir.

El propsito de esta fase es desarrollar en detalle el alcance y los planes de ejecucin de


la opcin seleccionada para lo que permitir principalmente obtener los fondos para
ejecutar el proyecto.

5.4.3.1.

Conformar Equipo de Trabajo

Incorporar nuevo personal de proyectos al equipo

Definir el Organigrama/Roles y Responsabilidades para el equipo

Identificar equipos de apoyo

5.4.3.2.

Desarrollo del DSD3

5.4.3.2.1.

Definir Objetivos de la Fase Definir

Indicar cual es la finalidad de esta fase, que se lograr al completarla.

5.4.3.2.2.

Definir Antecedentes (actualizar)

5.4.3.2.3.

Definir Propsito / Objetivos y Metas del Proyecto (actualizar)

5.4.3.2.4.

Definir Situacin Actual (actualizar)

5.4.3.2.5.

Definir Alcance del Proyecto (actualizar)

5.4.3.2.6.

Justificacin (actualizar)

5.4.3.2.7.

Cuantificar los Beneficios

Determinar de una manera tangible los beneficios obtenidos a travs de la ejecucin del
proyecto. Por ejemplo, si se trata de una sustitucin de un software, establecer las
diferencias en especificando mejoras en tiempos de respuestas, o si se trata de la

automatizacin de un proceso, sealar la reduccin en el nmero de pasos para ejecutar


el mismo, las ventajas de la automatizacin, etc.

5.4.3.2.8.

Determinar Oferta Social

Verificar con la organizacin Cadena de Suministros, si de acuerdo al tipo de contratacin


que se piensa realizar aplica algn tipo de oferta o aporte social.

5.4.3.2.9.

Elaborar Recomendaciones

Se deben describir las acciones para lograr la aprobacin del proyecto de manera de
avanzar a la fase de implantacin del mismo, esto puede ser equivalente a un proceso de
venta, donde se deben evidenciar los beneficios de seguir adelante con el proyecto para
obtener los fondos para su ejecucin.

5.4.3.2.10. Anlisis de Riesgos

Indicar si existiran riesgos durante la ejecucin del proyecto y de ser as, describir si son
tcnicos, polticos, econmicos, sociales, de mercado, ambientales, entre otros. Los pasos
mnimos son: identificacin de riesgos, cuantificacin / ponderacin de riesgos, anlisis
probabilstico de sensibilidad tiempo / costo, acciones para gerenciar el riesgo.

5.4.3.2.11. Documentar el Alcance y Diseo Bsico del Proyecto

En esta seccin se deben incluir los productos/artefactos que rigen o establecen


lineamientos para la construccin de las soluciones de TI, componentes funcionales,
servicios e interfaces requeridas para el proceso de negocio.

5.4.3.2.12. Elaborar Especificaciones de Construccin

Establecer las especificaciones de construccin para el desarrollo requerido o propuesto.

5.4.3.2.12.1. Diseo de la Arquitectura de Sistema

Mediante un diagrama de despliegue, se representa la arquitectura propuesta para el


proceso de negocio. Empleando los estereotipos necesarios para describir la
configuracin de los componentes de hardware, software y red que soportan el proceso de
negocio.

El diagrama de despliegue permite representar la vista esttica de la configuracin de los


nodos de hardware y componentes de software, junto con el estereotipo de componentes,
apoya: 1.- el diseo de la configuracin de hardware y software para soportar el proceso
de negocio; 2.- la exploracin de aspectos relacionados con la ejecucin del proceso de
negocio en ambientes de prueba y produccin; 3.- explorar las dependencias del proceso
de negocio con otros sistemas actualmente en produccin o propuestos para ser
integrados con el proceso de negocio bajo estudio.

Fig. 18 Ejemplo Diseo de Arquitectura


5.4.3.2.12.2. Especificacin de Servicios (actualizar)

Los servicios, si existen para la solucin, fueron identificados en la fase visualizar. En esta
actividad, es probable que se hayan identificado nuevos servicios en vista del mayor
detalle acerca de los requerimientos obtenido en la fase conceptualizar, de ser as, se
actualiza la tabla original.

5.4.3.2.12.3. Especificacin de Contratos

En la fase Conceptualizar se especificaron los contratos en lenguaje natural, ya en esta


fase es necesario especificarlos en formato XML (WSDL), preferiblemente un XSD
(Schema) el cual debe emplearse para la formal especificacin del documento XML o
WSDL.

5.4.3.2.12.4. Realizar Diagrama de Clases

El diagrama de Clases captura la estructura lgica del sistema.

Es un modelo esttico, describiendo lo que existe y qu atributos y


comportamiento tiene, ms que cmo se hace algo. Los Diagramas de Clases
son los ms tiles para ilustrar las relaciones entre las clases e interfaces. Las
generalizaciones, las agregaciones y las asociaciones son todas valiosas para
reflejar la herencia, la composicin o el uso y las conexiones respectivamente.
(http://www.sparxsystems.com.ar/download/ayuda/index.html?classdiagram.htm,
consultado 03-08-2009)

Fig. 19 Ejemplo de Diagrama de Clase

5.4.3.2.12.5. Realizar Diagrama de Entidad-Relacin (E-R)

Mediante el diagrama E-R se modelan las bases de datos, con el fin de visualizar los
objetos que pertenecen a la Base de Datos, como entidades las cuales tienen unos
atributos

se

vinculan

mediante

(http://www.mitecnologico.com/Main/DiagramasEntidadRelacionER,
2009).

relaciones
consultado

03-08-

Fig. 20 Ejemplo Modelo E-R


5.4.3.2.12.6. Realizar Diagramas de Secuencia para Casos de Uso del Sistema y para
Servicios

Este diagrama es una representacin estructurada de comportamiento como una serie de


pasos secuenciales a lo largo del tiempo. Se usa para representar el flujo de trabajo, el
paso de mensajes y cmo los elementos en general cooperan a lo largo del tiempo para
lograr un resultado (Fig. 16).

5.4.3.2.12.7. Realizar Otros Diagramas que Apliquen

Se sugieren los diagramas UML de Estados y Colaboracin.

5.4.3.2.12.8. Desarrollar Prototipo

El Prototipo es la evolucin del Guin de Interfaz de Usuario (que se realiz en la


conceptualizacin).
El Prototipo contiene vistas navegacionales para la aprobacin del usuario, debe proveer
vistas funcionales de la solucin.

5.4.3.2.13. Especificacin de Pruebas

En esta fase se deben construir los casos de pruebas para los diversos tipos de pruebas
que se realizarn en la siguiente fase, especificando como se ejecutarn cada una de

ellas. Se deben proponer los participantes, los responsables, fechas estimadas y dems
detalles que sean necesarios.

5.4.3.2.13.1. Pruebas Unitarias

Las pruebas permitirn probar pequeas e individuales porciones de cdigo. A travs de


ellas se verifica que cierto mdulo o funcionalidad se ejecuta dentro de los parmetros y
especificaciones concretadas en documentos tales como los casos de uso y el diseo
detallado: proporcionan un contrato escrito que la porcin de cdigo debe cumplir
(http://www.slideshare.net/dbaccess/pruebas-unitarias-uso-de-nunit-dentro-de-proyectosnet , consultado 10-08-2009)

5.4.3.2.13.2. Pruebas Integrales

Estas pruebas deben realizarse una vez que se han aprobado las pruebas unitarias.
nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que
componen un proceso, hecha en conjunto, de una sola vez. Se debe verificar que un gran
conjunto de partes de una solucin funcionan juntos. Adicionalmente estas pruebas deben
contemplar:

Pruebas funcionales (interfases)

Validacin de la documentacin

Pruebas No funcionales

Pruebas de Seguridad

5.4.3.2.13.3. Pruebas de Stress

Es una prueba integral que no solo evala la capacidad de concurrencia de usuarios, sino
tambin rendimiento de los servidores y monitoreo de la red.

5.4.3.2.13.4. Pruebas de Aceptacin

Las pruebas de aceptacin se pueden realizar mediante el siguiente formato:

Tabla 19 Prueba de Aceptacin


Pruebas de Aceptacin
Aplicacin / Proyecto

<nombre del proyecto o aplicacin para la que se disea la prueba>

Nombre de la Prueba:

<Nombre de la Prueba>

Coordinador:

<Nombre del coordinador de la prueba>

Preparada por:

<Nombre de quien preparo la prueba>

Ejecutada por:

<Nombre de quien ejecutara la prueba>

Requerimientos Asociados a la
prueba:

<Requerimientos necesarios para la ejecucin de la prueba>

Tipo de Prueba

Aceptacin

Fecha de Ejecucin:

Descripcin de la Prueba:

<Descripcin de la prueba>

Resultados Esperados:

<Resultados esperados de la prueba>

Errores Encontrados:
Necesita Reprobarse

Descripcin del error:

Prueba Aprobada:
Revisada y Aprobada por:

Fecha de revisin:

Ruta y/o Ubicacin de Logs de resultados de pruebas:

5.4.3.2.14. Describir Efectos Netos sobre el Personal

Se requiere determinar si la implantacin del proyecto tendr incidencia de en aumentos o


disminucin de personal, tanto operacional como administrativo.

5.4.3.2.15. Describir Efecto sobre los Costos de Operacin

Sealar si la nueva solucin acarrear costos para permitir su continuidad operativa, por
ejemplo si la solucin incluye software propietario se puede proyectar los costos en
licenciamiento anual, si un nuevo hardware requiere contrato de mantenimiento posterior a
su implantacin, estimar estos cargos anuales, etc.

5.4.3.2.16. Elaborar Matriz de Riesgos para la Fase Implantar

Se deben considerar riesgos relacionados con la contratacin y la construccin que son


las dos macroactividades principales de la fase de Implantacin.

5.4.3.2.17. Considerar los Aspectos Financieros

Elaborar Estimado de Costos clase II del proyecto

Elaborar Plan de Desembolsos

5.4.3.2.18. Prepararse para la Siguiente Fase > Implantar

Definir roles y responsabilidades preliminares para la fase implantar.

Definir estrategia de contratacin y procura para la fase implantar: para definir la


estrategia es necesario que el lder de proyecto lleve el caso a Cadena de
Suministros, ya que son ellos los expertos en materia de contratacin, y quienes
indicarn cual es el camino a seguir ya sea por la Ley de Contrataciones o por la
Normativa Interna de PDVSA.

Elaborar cronograma clase II para ejecutar las prximas fases (Implantar y Operar).

Establecer guas para el control de las fases implantar y operar: definir como se va
a controlar el proyecto, por ejemplo usando la curva S o el mtodo del valor ganado.

5.4.3.2.19. Elaborar Plan de Ejecucin del Proyecto (PEP) clase II


5.4.3.2.20. Evaluar Grado de Definicin del Proyecto

El xito de desarrollo de un proyecto est relacionado directamente con el hecho de haber


alcanzado un buen grado de definicin. Esta es la razn por la cual resulta de suma
importancia hacer la evaluacin de la definicin del proyecto antes de someterlo a
aprobacin y solicitud de fondos para su completacin. La evaluacin del grado de
definicin (o FEL index como se conoce en idioma ingls por Front End Loading), es una
revisin que permite verificar que cada una de las reas de importancia del proyecto se
han desarrollado a un cierto nivel de tal forma de poder inferir que el proyecto ha sido

definido lo suficiente y, por ende, determinar que su completacin es viable en forma


exitosa de acuerdo con el alcance y la planificacin prevista.

Generalmente, esta evaluacin es realizada por una organizacin externa al proyecto, la


cual dependiendo de la magnitud y complejidad del mismo, podra variar desde de una
empresa especializada en este tipo de servicio para un proyecto de gran magnitud y
complejidad, hasta un equipo de trabajo interno, pero diferente al grupo ejecutor del
proyecto.

5.4.3.2.21. Desarrollar Plan de Aseguramiento Tecnolgico

Para la seleccin final de la tecnologa se deben considerar todos los aspectos necesarios
en el aseguramiento tecnolgico segn aplique dependiendo del tipo de solucin, los
cuales se enumeran a continuacin.

Evaluacin de la tecnologa.

Acuerdos de transferencia de tecnologa.

Pagos por el uso de la tecnologa.

Consultas durante la ingeniera de detalle.

Adiestramiento del personal.

Asistencia durante el arranque.

Asistencia durante la prueba de capacidad.

Soporte continuo.

5.4.3.2.22. Elaborar las Instrucciones a los Participantes o Pliego (DSO)

El Documento de Solicitud de Ofertas (DSO) es una herramienta formal para solicitar a las
empresas o cooperativas la informacin necesaria para concursar. El mismo plasma los
requerimientos bsicos del proyecto desde los puntos de vista tcnicos, de ejecucin y
contractuales.

A continuacin, se

muestra en forma grfica el contenido tpico del Documento de

Solicitud de Oferta (DSO):

Fig. 21 Contenido Tpico de un DSO


5.4.3.2.23. Actualizar los Datos y Documentacin del Proyecto en la Base de Datos
de Configuracin
5.4.3.3.

Entrega de DSD3

Revisin del DSD3.

Aceptacin del DSD3.

5.4.4.
5.4.4.1.

Fase Implantar
Proceso de Contratacin

El proceso de contratacin se ejecutar de acuerdo a la estrategia de contratacin definida


en la fase previa, la cual ha debido ser revisada y validada por Cadena de Suministros,
quienes realmente ejecutan este proceso, DIS solo entrega los documentos necesarios
para el inicio del mismo.

De acuerdo al tipo de proceso estas actividades pueden variar, por eso es importante
validar en esta etapa con Cadena de Suministros (CDS) cuales son las actividades
especficas del proceso seleccionado para incorporarlas en el plan.

5.4.4.1.1.

Elaboracin de Borrador de Acta de Inicio y Memo para Iniciar Proceso


de Contratacin

CDS debe proporcionar a DIS modelos de estos documentos de procesos de contratacin


similares para que el lder de proyecto tenga una gua para hacerlos.

5.4.4.1.2.

Establecer Roles y Funciones con Organizacin de CDS

Aclarar con CDS como ser la participacin del lder de proyecto en el proceso de
contratacin, en cuanto a definir qu documentos elabora cada organizacin, quin es
responsable de la comunicacin directa con la Comisin de Contrataciones, en qu partes
del proceso debe participar o no el lder del proyecto.

5.4.4.1.3.

Revisin de las Condiciones de Participacin o Pliegos

Estas actividades se realizan en conjunto con CDS, el lder principalmente hace


seguimiento y participa en la elaboracin de algunos documentos segn se haya definido
en el punto anterior, principalmente se deben contemplar los siguientes aspectos:

Validar modalidad de contratacin.

Elaborar Contrato Modelo.

Apoyo al perfilamiento de empresas / anlisis de mercado (si aplica).

Verificar aplicabilidad de modelo de contrato propuesto.

Elaborar la matriz de evaluacin tcnica de las empresas.

Solicitud de inicio de proceso en Comisin de Contrataciones.

Invitacin de participacin a las empresas al proceso de licitacin.

Reunin aclaratoria.

Entrega de ofertas.

Apertura y validacin de sobres.

5.4.4.1.4.

Evaluacin Tcnica / Econmica (segn aplique)

Para la evaluacin tcnica / econmica deben considerarse las siguientes tareas:

Realizar la evaluacin tcnica de las ofertas

Elaborar informe tcnico de resultados

Elaborar acta de resultados

Elaborar memo de evaluacin

Notificacin de resultados

Elaboracin de contratos definitivos (revisin y visado por consultora jurdica)

5.4.4.1.5.

Otorgamiento de la Buena Pro

Notificacin a las empresas de la Buena Pro

Recaudacin de requisitos administrativos de la empresa contratada para la firma


del contrato

Revisin y firma del contrato

Firma de Contrato

5.4.4.2.

Elaborar PEP Clase I

Este plan es la base para el control de ejecucin del contrato de acuerdo a los productos
definidos. Se elabora una vez otorgado el(los) contrato(s), consolidando la informacin
contenida en el plan de ejecucin de la empresa favorecida con las buena-pro.

Cabe destacar que este plan clase I debe ser visto como la herramienta principal en la cual
se har nfasis para definir la medicin de avance del proyecto y, por ende, el control de
costos y la facturacin del pago.

5.4.4.3.

Verificar PEP del Contratista

El PEP del contratista debe ser consistente con el PEP del proyecto. Debe establecer los
lmites apropiados del alcance de su trabajo y presentar adecuadamente los detalles.

Todos los contratistas licitantes deben preparar su PEP durante el perodo de seleccin, a
objeto de garantizar que las intenciones de ejecucin del contratista son bien entendidas
por el ente contratante, en este caso, AIT-DIS.

Inmediatamente despus de otorgrsele al contratista la buenapro, se le deben


suministrar algunas secciones del PEP del proyecto para confirmar su planificacin y la
compatibilidad entre los dos PEP.

El PEP del contratista deber incluir una Estructura Detallada de Trabajo (EDT) que sea
compatible con la del proyecto y que, aunque pudiese ser elaborada a un nivel mayor de
detalle, permita relacionar sin ambigedad los elementos de trabajo del contratista para
establecer una base idntica de medicin.

5.4.4.4.

Conformar Equipo de Trabajo

En esta fase, la actividad conformar equipo de trabajo, es mas extensa y detallada, ya que
se trata del equipo que debera participar durante esta fase y la siguiente que se podra
decir, son las de mayor peso puesto que se trata de la ejecucin del proyecto como tal y
su puesta en marcha.

5.4.4.4.1.

Conformar Equipo de Proyecto PDVSA

Convocar a consultor de negocio asignado.

Convocar a consultor de requisitos asignado.

Convocar a consultor de tecnologa asignado.

Convocar analista de asuntos pblicos asignado.

Convocar analista de seguridad lgica asignado.

Convocar analista de auditora de sistemas asignado.

Convocar analista de MAP (Servidores, aplicaciones, BD) asignado (Segn


aplique).

Convocar analista de control de la configuracin.

Identificacin de equipos de apoyo (riesgos, estimadores).

Definir el organigrama/roles para el equipo.

5.4.4.4.2.

Validar Lineamientos

Del negocio.

Tecnolgicos.

De requisitos.

5.4.4.4.3.

Reunin de Inicio de Proyecto con Equipo PDVSA / Empresa Contratada

Firma del acta de inicio del servicio.

Revisar plan detallado del proyecto.

Revisar lineamientos tecnolgicos a considerar en programacin del desarrollo del


proyecto.

Establecer los mecanismos de extraccin/exportacin de datos e interfaces (para


aquellos proyectos que aplique como en los casos de migracin de una solucin
tecnolgica previa a una nueva).

5.4.4.4.4.

Reunin de Inicio de Proyecto con Equipo Proyecto y Usuarios


Funcionales

Presentacin del equipo de trabajo.

Revisar plan detallado del proyecto.

Definicin de comit de usuarios funcionales.

5.4.4.5.

Desarrollo del DSD4

5.4.4.5.1.

Realizar Resumen Ejecutivo

5.4.4.5.1.1. Definir Objetivos de la Fase Implantar

Indicar cual es la finalidad de esta fase, qu se lograr al completarla.

5.4.4.5.1.2. Definir Antecedentes (actualizar)


5.4.4.5.1.3. Definir Propsito / Objetivos y Metas del Proyecto (actualizar)
5.4.4.5.1.4. Definir Situacin Actual (actualizar)
5.4.4.5.1.5. Definir Alcance del Proyecto (actualizar)
5.4.4.5.1.6. Justificacin (actualizar)
5.4.4.5.1.7. Elaborar Recomendaciones

Describir de manera sencilla y precisa las recomendaciones propias para esta etapa del
proyecto

5.4.4.5.2.

Elaborar (actualizar) Matriz de Productos / Plan de Desembolsos a ser


Generados en las Fases: Implantar y Operar

La matriz de productos se genera desde la fase conceptualizar, en esta etapa si es


necesario se actualiza y, adicionalmente, debe agregrsele el monto a desembolsar por
cada producto por lo cual constituye tambin el plan de desembolsos. Es importante
verificar muy bien la lista de productos entregables, garantizando que se incluya la
documentacin necesaria, as como asociar el ltimo pago al acompaamiento durante el
arranque de la solucin, para garantizar que se culminen apropiadamente todos los
detalles del proyecto.

Tabla 20 Plan de Desembolsos por Productos


PRODUCTO

MONTO

FECHA ESTIMADA DE
ENTREGA

5.4.4.5.3.

Construccin

5.4.4.5.3.1. Creacin de Ambiente de Desarrollo en PDVSA

En esta actividad es importante recordar que MAP fue notificado desde la fase
conceptualizar de cuales eran los recursos que este proyecto iba a necesitar tanto en
desarrollo como en produccin, en este momento se le puede hacer entrega de la misma
planilla, (actualizada si fue necesario hacer algn ajuste), para que procedan a configurar
el ambiente de desarrollo. (Ver anexo N 5).

5.4.4.5.3.2. Instalacin y Configuracin del Ambiente de Desarrollo

Preparar todo lo concerniente a:

Sistema operativo.

Bases de datos.

Aplicaciones.

Interfaces.

5.4.4.5.3.3. Procura de Equipos

Si aplica la adquisicin de componentes de hardware, se debern considerar los


siguientes pasos:

Introducir Solicitud de Pedido o Requisicin de Pedido de Material (RPM).

Aprobacin en SAP de la RPM.

Seleccin de compra segn ofertas recibidas.

Adquisicin de equipo.

Instalacin y pruebas del equipo.

5.4.4.5.3.4. Ingeniera de Detalle

El diseo de la solucin se realiz en la fase definir, en esta fase, ya teniendo claro quien
ejecutar el proyecto, es necesario revisar todos los aspectos tcnicos para validar que
son claros, funcionales y se adaptan perfectamente al objetivo del proyecto. Por lo tanto
se debe:

Revisar / actualizar Especificacin de Servicios.

Revisar / actualizar Especificacin de Contratos.

Revisar / actualizar Diagrama de Clases.

Revisar / actualizar Diagrama de Entidad-Relacin

Revisar / actualizar Diagramas de Secuencia para Casos de Uso del Sistema y


para Servicios.

Revisar / actualizar otros diagramas que apliquen.

5.4.4.5.3.5. Desarrollo

El desarrollo de la solucin debe realizar en base a prioridad de los requerimientos, y en


funcin de obtener progresivamente como avances los productos definidos, quedando de
parte del lder de proyecto aplicar las estrategias de control y seguimiento que haya
definido.

5.4.4.5.3.6. Elaboracin de la Documentacin del Sistema (versin preliminar)

La documentacin puede variar de acuerdo al tipo de proyecto, sin embargo existen


documentos bsicos que deben tomarse en cuenta, como:

Elaboracin del plan de contingencia: para la elaboracin de este plan se solicita


el apoyo del Departamento de Seguridad Lgica de AIT, quienes orientan en su
construccin.

Documento de especificaciones actualizado: Se debe entregar este documento


actualizado de acuerdo a algn cambio solicitado por el usuario o por AIT durante el
desarrollo, o que los desarrolladores hayan considerado necesario y haya sido
aprobado implantar: Requerimientos Funcionales (RF), Requerimientos No
Funcionales (RNF), Requerimientos de Informacin (RI), Catlogo de Requisitos
Detallado, Consideraciones de Tecnologa.

Documento de desarrollo: contiene los diagramas de clases, modelo lgico de


datos (Diagrama E/R de las nuevas tablas y relaciones incluyendo tablas existentes
relacionadas), estructura fsica de datos (scripts), diccionario de datos y diagrama
de arquitectura del sistema (de hardware y software).

Manual de sistema: representa el manual tcnico de la solucin y se compone de


los siguientes puntos: Introduccin, antecedentes, objetivos, alcance, limitaciones,
plataforma tecnolgica, tecnologas de desarrollo utilizadas, definicin de clases,
componentes, libreras, archivos y script de configuracin, descripcin de
programas y scripts del sistema, requerimientos de hardware, requerimientos de
software, roles y perfiles, descripcin de los procesos del sistema, diagrama de
procesos, diagrama de flujo, definicin y descripcin de algoritmos de los procesos
medulares del sistema, definicin de interfaces con otros sistemas y tareas
programadas.

Manual de Instalacin: corresponde al manual de cmo realizar la instalacin de


la solucin tanto en el servidor cmo en la estacin cliente (si fuese necesario),
debe contener lo siguiente: requerimientos

de hardware, requerimientos de

software, pasos de instalacin de la aplicacin, configuracin de la base de datos,


configuracin del Web Site (si aplica), configuracin de componentes (si aplica),
pruebas de la instalacin, posibles fallas y soluciones.

Manual de usuario: corresponde al documento de operacin de la solucin y


estar compuesto por los siguientes puntos: introduccin, antecedentes, definicin
de la aplicacin, ejecucin de la aplicacin ingreso de usuario y contrasea,
descripcin de funcionalidades o mdulos del sistema. Debe existir un manual de
acuerdo a cada perfil de usuario del sistema.

Manual de ayuda a Gestin del Servicio: Este documento explica de forma rpida
y sencilla cmo el personal de GDS perteneciente tanto al personal del centro de
servicios (soporte telefnico) y soporte integral (soporte en sitio), realizar la
solucin de los incidentes, Este pequeo manual tambin es conocido como
Troubleshooting.

Documento de casos de prueba: Documento de Casos de Prueba: el caso de


prueba contiene un conjunto de entradas, condiciones de ejecucin y resultados
esperados, ms los resultados obtenidos. En palabras sencillas representan la
especificacin y evidencia de que las pruebas formales a la solucin han sido
realizadas

Plan de capacidades: corresponde a la visin de lo que ser segn la evaluacin


del proyecto los requerimientos de capacidad de la solucin incluyendo los
siguientes puntos:
Cantidad de usuarios promedio definidos y concurrentes.
Cantidad de transacciones promedio diarias, semanales etc.
Espacio ocupado y estimaciones de crecimiento para 2 aos

Documento de garanta: este debe contener la definicin de la garanta aplicable


sobre los productos entregados, incluir trminos de la garanta y acuerdos de
servicio si aplica.

5.4.4.5.3.7. Pruebas del Sistema

Ejecutar las pruebas de acuerdo a lo especificado en la fase definir:


Pruebas Unitarias
Pruebas Integrales
Pruebas de Aceptacin

Generar informe de resultado de las pruebas.

Realizar ajustes al sistema (si aplica).

Actualizar la documentacin para su versin final (si aplica).

5.4.4.5.3.8. Solicitar Evaluacin de Seguridad Lgica en Ambiente de Desarrollo

Esta evaluacin se realiza en el ambiente de desarrollo cuando han sido ejecutadas


satisfactoriamente todas las pruebas sobre la solucin.

5.4.4.5.3.9. Realizar Adiestramientos

Se deben garantizar al menos las siguientes actividades de capacitacin:

Transferencia de conocimiento tcnica (servidores, interfaces, base de datos).

Transferencia de conocimiento funcional de la aplicacin.

Transferencia de conocimiento en cuanto a documentacin de la aplicacin.

Adiestramiento a los usuarios funcionales.

5.4.4.5.4.

Completar Anexos del DSD4

Es importante anexar al Documento de Soporte de Decisin 4 que se genera en esta fase,


al menos los siguientes anexos, los cuales pueden variar de acuerdo al tipo de proyecto:

Acta de inicio del contrato

Copia del contrato

Documentacin tcnica

Documentar las lecciones aprendidas

Listado de personal entrenado

Acta de entrega de equipos, licencias, otros necesarios para garantizar la


continuidad operativa.

Puntos pendientes de construccin (No relacionado con el alcance del proyecto que
se entrega). En el caso de proyectos de TI se debe anexar un informe con todos los
requerimientos adicionales que solicite el usuario y que no puedan ser
considerados en el alcance del proyecto actual. Este informe, aparte de ser un
anexo del DSD4, debe ser entregado a la gerencia de Gestin de Necesidades y
Oportunidades (GNO) para que visualice una nueva solucin para dichos
requerimientos, ya sea como una segunda fase del proyecto por terminar, como
cambios a la solucin una vez se haya puesto en marcha, como un nuevo proyecto
o la mejor alternativa que el consultor considere para estas necesidades.

5.4.4.5.5.

Prepararse para la Siguiente Fase > Operacin

Definir roles y responsabilidades preliminares para la fase Operacin

Verificar disponibilidad de recursos necesarios para la prxima fase.

5.4.4.5.6.

Actualizar los Datos y Documentacin del Proyecto en la Base de Datos


de Configuracin

5.4.4.6.

Entrega de DSD4

Revisin del DSD4.

Aceptacin del DSD2.

5.4.5.
5.4.5.1.

Fase Operar
Colocar en Operacin el Ambiente de Produccin

En esta actividad se debe solicitar al personal de mantenimiento que tenga preparada la


plataforma que desde la fase conceptualizar le fue solicitada y especificadas sus
caractersticas para alojar la nueva solucin.

5.4.5.2.

Crear estructura de la solucin

La nueva solucin debe versa reflejada en los diferentes sistemas que permiten a la
continuidad operativa llevar el control de las soluciones que tiene AIT, reportar fallas,
gestionar controles de cambio, resguardar la documentacin, etc. Se deben hacer las
solicitudes correspondientes para que la nueva solucin aparezca reflejada en las
siguientes herramientas:

Sistema Integrado de Control, Seguimiento y Soluciones (SICSES)

Action Request System (ARS)

5.4.5.3.

Completar Plan de Contingencia

El plan de contingencia se comenz en la fase implantar, en esta fase de operacin es


necesario completarlo con los datos que quedaban pendientes referentes al ambiente de
produccin, direccin IP de los servidores de produccin, etc.

Posteriormente se solicita a Seguridad Lgica que lo evale, y de acuerdo a sus


observaciones, se ajusta si es necesario.

5.4.5.4.

Realizar adiestramiento a Gestin del Servicio (GDS)

Si es necesario se ajusta el manual de ayuda a GDS que se elabor en la fase implantar,


luego se coordina la logstica para dictar las charlas al personal de los centros de servicio
y al personal de soporte integral.

5.4.5.5.

Realizar Control de Cambio 1

La organizacin de Gestin de la Configuracin, solicita para la salida a produccin de una


nueva solucin dos controles de cambio, en este primer control de cambio se realizan las
siguientes actividades:

Realizar reunin previa al control de cambio: en esta reunin deben participar todos
los involucrados y de all debe surgir el plan de accin para la ejecucin del control
de cambio y todas las tareas que deben crearse en el mismo.

Instalar aplicacin en el ambiente de Produccin: esta actividad se realiza con el


apoyo de mantenimiento.

Realizar pruebas:
Realizar pruebas de stress: esta prueba se realiza independientemente del
nmero de usuarios, ya que debe ser una prueba integral que no solo evale la
capacidad de concurrencia de usuarios, sino tambin rendimiento de los
servidores y monitoreo de la red.
Hacer rollback: esto significa que la aplicacin debe ser eliminada del ambiente
de produccin y mantenerse en el ambiente de desarrollo hasta que se apruebe
el siguiente control de cambio.
Realizar ajustes a la solucin (si aplica): los ajustes se hacen en el ambiente de
desarrollo y si la ventana del control de cambio da oportunidad se repiten las
pruebas sino habra que generar un nuevo control de cambio hasta que las
pruebas de estrs resulten exitosas.
Actualizar documentacin (si aplica).
Actualizar ultima versin de la aplicacin Base de Datos de Configuracin (si
aplica).

Cerrar control de cambio

5.4.5.6.

Realizar Control de Cambio 2

Realizar reunin previa al control de cambio.

Instalar aplicacin en el ambiente de Produccin.

Solicitar Evaluacin de Seguridad de todos los componentes: esta es la revisin


final que realiza seguridad lgica de la nueva solucin ya en el ambiente de
produccin.
Realizar Evaluacin de Seguridad.
Realizar ajustes (si aplica).
Actualizar ultima versin de la aplicacin en la Base de Datos de Configuracin
(si aplica).

Cerrar control de cambio

Si el control de cambio nmero dos finaliza de manera exitosa, significa que ya se tiene
una nueva solucin de TI en ambiente de produccin, y lista para ser entregada
formalmente al personal de continuidad operativa de AIT.

5.4.5.7.

Aceptacin de Instalaciones

Hacer entrega al personal de mantenimiento de los productos generados por el proyecto y


que permitirn darle continuidad a la nueva solucin. Esta entrega debe ir acompaada de
un acta de recepcin.

5.4.5.8.

Elaboracin de Informes Finales

5.4.5.8.1.

Cierre del proyecto

Elaborar el informe de cierre del proyecto tanto de ejecucin fsica, como financiera, y los
resultados obtenidos. Para el informe se pueden considerar los siguientes anexos:

Copia de contrato.

Acta de inicio del contrato.

Acta de terminacin del contrato.

Respaldos financieros.

Acta de aceptacin Provisional del Sistema.

Documentar las lecciones aprendidas.

Cronograma de ejecucin.

Al haber completado las cinco fases del ciclo de vida basadas en esta metodologa que
incluye actividades propias de los proyectos de TI, se habr completado un proyecto, el
cual podr tener mayores probabilidades de xito que los proyectos ejecutados antes de
esta propuesta metodolgica.

6. CAPTULO VI
EVALUACIN DE LA PROPUESTA
Este captulo presenta la evaluacin del proyecto de Trabajo Especial de Grado a travs
de los resultados relevantes obtenidos, la viabilidad de implantacin de la propuesta; se
verificar el cumplimiento del cronograma y si fueron logrados los objetivos planteados.

6.2.

RESULTADOS RELEVANTES

La propuesta elaborada en el presente Trabajo Especial de Grado gener como resultado


una metodologa para la gestin de proyectos de Tecnologa de Informacin, mucho ms
completa y acorde a la realidad de este tipo de proyectos, que la metodologa estndar
que se sigue hasta el momento. Esto se debe a la incorporacin de todos los elementos
tcnicos necesarios para lograr una definicin adecuada de los proyectos, que permiten a
su vez su correcto desarrollo y puesta en marcha, as como tambin fueron incluidas
actividades, mas all de las propiamente tcnicas, de procesos que hay que cumplir,
donde se interacta con otras organizaciones de AIT y de PDVSA, que el lder de proyecto
no debe dejar pasar, logrando as eliminar algunos obstculos que se presentan en la
actualidad por desconocer todas las actividades que se deben tomar en cuenta.

En funcin de lo anterior, se considera que se logr una herramienta muy importante y til
para los lderes de proyecto y para la organizacin de Desarrollo e Implantacin de
Soluciones, lo cual a su vez redunda en un beneficio para AIT, que si bien es oportuno, se
puede recordar un extracto de su misin, que cita: Somos la Organizacin que rige,
provee y mantiene los servicios y soluciones integrales de tecnologas de automatizacin,
informacin y comunicaciones de la corporacin; contribuimos a mantener su continuidad
operativa y a ejecutar sus planes; innovamos y actuamos como agentes de transformacin
en PDVSA ()

Al proveer soluciones de Tecnologa de Informacin, ms oportunas y exitosas, se


contribuye con la Misin de AIT, que se reflejar adems en el apalancamiento que dichas
soluciones aportan a los diferentes negocios de Petrleos de Venezuela.

6.3.

VIABILIDAD DE IMPLANTACIN DE LA PROPUESTA

Una vez completada la metodologa para gestin de proyectos de TI propuesta en el


presente Trabajo Especial de Grado, la misma fue presentada ante la Coordinacin de
Metodologas de la gerencia de Desarrollo e Implantacin de Soluciones, siendo recibida
gratamente como un aporte muy importante para la organizacin.

En este sentido, esta organizacin, en vista en que est en la capacidad de tomar las
decisiones referentes a los lineamientos de cmo debe trabajar la gerencia, decidi
proceder a divulgar la metodologa en el equipo de trabajo, considerando como premisa
que los proyectos que estn en curso se terminen de acuerdo a su planificacin actual, y
cada nuevo proyecto que se asigne a un lder de la Gerencia DIS, debe seguir lo
establecido en esta metodologa.

6.4.

CUMPLIMIENTO DEL CRONOGRAMA

Para el presente Trabajo Especial de Grado, gracias al esfuerzo dedicado en su


elaboracin, se cumpli a cabalidad con el plan establecido, permitiendo de esta manera
su entrega segn la fecha propuesta.

6.5.

LOGRO DE LOS OBJETIVOS

En cuanto al logro de los objetivos se considera que desde el punto de vista del objetivo
general el mismo fue satisfecho ya que el diseo de la Metodologa de Gestin de
Proyectos de Tecnologa de Informacin definitivamente apoya la gestin de proyectos de
Automatizacin, Informtica y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e
implantacin de Soluciones (DIS). De igual forma, abordando los objetivos especficos,
tambin fueron cubiertos en su totalidad puesto que:

Se realiz el anlisis del potencial de uso de las Guas de Gerencia de Proyectos de


Inversin de Capital, GGPIC, para proyectos de Automatizacin, Informtica y
Telecomunicaciones y se convalid el real grado de aplicabilidad de las mismas
frente a las caractersticas y estrategias de desarrollo de los proyectos de AIT y
ante la organizacin actual basada en procesos.

Se elabor la propuesta de Metodologa de Gestin de Proyectos de Tecnologa de


Informacin aprovechando la aplicabilidad de las GGPIC, incorporando las
adaptaciones necesarias para manejar proyectos de AIT.

Y, finalmente, se valid la aplicabilidad de la propuesta con la Coordinacin de


Metodologas de la Gerencia de Desarrollo e Implantacin de Soluciones para
implantarla como parte de este proceso en la gestin de los proyectos de AIT.

7. CAPTULO VII
CONCLUSIONES Y RECOMENDACIONES
Para cerrar el Trabajo Especial de Grado se expondrn las conclusiones y
recomendaciones pertinentes.

7.1.

CONCLUSIONES

Luego de realizar el examen de la situacin en el captulo IV, se pudo observar que las
Guas de Gerencia para Proyectos de Inversin de Capital (GGPIC) se aplican en alto
grado en la gestin de proyectos de Tecnologa de Informacin (TI), sin embargo, en la
Gerencia de Desarrollo e Implantacin de Soluciones se ha visto, que siguiendo esta
metodologa, siempre se ve afectada alguna de las aristas principales del proyecto
estudiadas en el captulo II, conocidas como la triple restriccin.

El tiempo, el costo o la calidad sufren consecuencias negativas, impactando el resultado


de los proyectos, disminuyendo las posibilidades de xito de los mismos.

Todo este anlisis permiti concluir que es necesaria una nueva metodologa mejorada y
adaptada a las particularidades de los proyectos de Tecnologa de Informacin (TI), los
cuales estn a cargo de la Gerencia de Desarrollo e Implantacin de Soluciones (DIS) de
Automatizacin, Informtica y Telecomunicaciones (AIT) en Petrleos de Venezuela
(PDVSA).

La nueva metodologa propuesta en este Trabajo Especial de Grado (TEG) para la


Gestin de Proyectos de TI, contempla los aspectos tcnicos y de procesos que se
requieren cumplir para llevar a cabo con altas probabilidades de xito los proyectos de
esta rea. La idea fundamental del TEG, fue lograr aportar una herramienta que apoyara
la gestin de proyectos de TI, sin contradecir el lineamiento corporativo de PDVSA de usar

las GGPIC como gua metodolgica. En este sentido se mantuvo la base de esta
metodologa, con sus actividades principales aplicables y manteniendo a su vez las
mismas fases del ciclo de vida de los proyectos, construyendo de esta manera, una nueva
metodologa ms completa, mejorada y adaptada a la realidad de los proyectos de
tecnologa ejecutados por la gerencia DIS.

Asimismo, se valid la viabilidad de la implantacin de la nueva metodologa como


lineamiento estndar para la gestin de futuros proyectos del rea de Tecnologa de
Informacin, siendo considerada como factible por la Coordinacin de Metodologas de la
Gerencia de Desarrollo e Implantacin de Soluciones, por lo cual, finalmente se concluye,
que el diseo de una nueva metodologa satisface una necesidad real de la organizacin y
se considera un aporte valioso para el desempeo de las funciones del equipo de trabajo.

Por ltimo, se observa la limitacin de no contar con el tiempo necesario para aplicar la
metodologa diseada en un nuevo proyecto de principio a fin, donde se podra evidenciar
con datos precisos, si el uso de sta, favoreci la gestin del proyecto, observndose en
los resultados del mismo. Esta limitacin se puede convertir en una oportunidad para un
nuevo estudio.

7.2.

RECOMENDACIONES

Del presente Trabajo Especial de Grado se derivan las siguientes recomendaciones:

Implantar la metodologa propuesta como lineamiento estndar de gestin de


proyectos en la gerencia DIS, dada la previa validacin y aceptacin de la
Coordinacin de Metodologas, organizacin facultada para tomar y ejecutar esta
decisin.

Divulgar la metodologa al equipo de trabajo de DIS, lo cual pudiera hacerse en


varias sesiones de trabajo donde se aclaren las dudas e incluso se realicen ajustes
de ser necesario, en pro del principio de calidad de procurar siempre una mejora
continua.

Divulgar la metodologa a todas las organizaciones de AIT, ya que la mayora se


involucra de alguna manera u otra durante el ciclo de vida de un proyecto, as como

tambin, en casos excepcionales, se asigna la ejecucin de un proyecto a


organizaciones diferentes a DIS.

Seleccionar una muestra de los proyectos que estn prximos a comenzar, a los
cuales se les aplique la metodologa y se puedan medir los resultados obtenidos en
cuanto a tiempo, costo y calidad, lo cual evidenciar la utilidad de la propuesta
realizada en este TEG.

REFERENCIAS
Cleland, D. y Ireland, L. (2001). Manual Porttil del Administrador de Proyectos. Ciudad
de Mxico. Ciudad de Mxico, Mxico: McGraw-Hill.
Castro, G. Proyectos Informticos http://www.monografias.com/trabajos39/proyectoinformatico/proyecto-informatico2.shtml, consultado el 10-06-2009.
Gestin de la Configuracin. (2007). Manual para el Taller de Dimensions. Caracas:
PDVSA. Documento mimeografiado.
Gestin y Mejoramiento de Procesos. (2007). Diseo del Proceso Desarrollo e
Implantacin de Soluciones. Caracas: PDVSA.
http://es.wikipedia.org/wiki/Gestin_de_proyectos, consultado el 14/04/2009).
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/, consultado el 11-062009.
http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/c1/c1.htm,
consultado el 09-06-2009.
http://www.degerencia.com/area.php?areaid=2001, consultado el 11-06-2009.
http://www.hispadata.com/servicios/gestion-proyectos-ti.php, consultado el 09-06-2009.
http://www.intranet.pdvsa.com, consultado el 18-06-2009.
http://www.liderdeproyecto.com/metodologias/index.html, consultado el 11-06-2009.
http://www.mitecnologico.com/Main/DiagramasEntidadRelacionER consultado el 03-082009.
http://www.pdvsa.com/, consultado el 14-04-2009.
http://www.slideshare.net/dbaccess/pruebas-unitarias-uso-de-nunit-dentro-de-proyectosnet, consultado 10-08-2009.
http://www.sparxsystems.com.ar/download/ayuda/index.html?classdiagram.htm,
consultado 03-08-2009.
IESA. 25 Programa de Gerencia de Proyectos. (2005). Caracas: IESA. Documento
Mimeografiado.

Kerzner, H. (2001). Project Management a Systems Approach to Planning and


Controling (7a ed.). Estados Unidos, Nueva York: John Wiley & Sons, Inc.
PDVSA. (1999). Guas de Gerencia para Proyectos de Inversin de Capital. Caracas:
Autor. Documento mimeografiado.
Planificacin AIT. (2007). PDN AIT 2007-2013. Caracas: PDVSA.
Planificacin y Arquitectura. (2008). Presentacin lineamientos estratgicos. Caracas:
PDVSA.
Project Management Institute. (2004). Gua de los Fundamentos de la Direccin de
Proyectos (3 ed.). Estados Unidos, Pennsylvania: Autor.
Rueda, J. (2006). Aplicacin de la Metodologa Rup para el Desarrollo Rpido de
Aplicaciones Basado en el Estndar J2EE. Tesis de pregrado no publicada,
Universidad de San Carlos de Guatemala, Ciudad de Guatemala, Guatemala.

8.

ANEXOS

Anexo N 1: Clasificacin de Estimados de Costo

Grado de
precisin

Clase V

Clase IV

Clase III

Clase II

Clase I

15%

30%

60%

80%

90%

Nota: Esta clasificacin se aplica tambin a los estimados de tiempo de ejecucin del
proyecto.

Anexo N 2: Plantilla de Datos Bsicos

Datos Bsicos
SOLICITANTE
Regin:
Filial:
rea Funcional:
Distrito/Localidad:

Proceso Enmarcado en la cadena de valor


del negocio:
Ejemplo : Negocio => Recursos Humanos
Cadena de Valor: Captacin -> Desarrollo ->
Educacin.
Proceso a estudiar : Educacin
Solicitante(s)
Nombre y Apellido:
Indicador:
Telfono:

mbito:

Internacional
Nacional
Regional
Prioridad:
Mandatario
Indispensable
Necesario
Diferible o deseable
Aprobador(es)
Nombre y Apellido:
Indicador:
Telfono:

Instructivo de llenado:
Regin: Nombre de la regin, donde ha sido detectada la necesidad u oportunidad
(Oriente/Centro/Sur/Occidente/Metropolitana).
Filial: Nombre del negocio o filial, donde ha sido detectada la necesidad u
oportunidad (Exploracin y Produccin, Refinacin, Intevep, Gas, CVP,
Corporativo)
rea Funcional: Nombre de la funcin en donde ha sido detectada la necesidad u
oportunidad (Recursos Humanos, Finanzas, PCP, etc.).
Distrito: Nombre del distrito en donde ha sido detectada la necesidad u oportunidad
(San Tom, Maturn, Morichal, Ta Juana, Lagunillas, etc.)
mbito: El mbito del proyecto: nacional, internacional o regional, si es regional,
especifique.
Prioridad:
Mandatario: de mxima prioridad y a ser ejecutada sin dilaciones.
Indispensable: Iniciativa con claro componente de valor, lo cual implica su
programacin en el actual ciclo de planificacin
Necesario: Casos de menor prioridad pero todava a desarrollar en el ciclo
de planificacin actual.
Diferible deseable: Casos con holgura para ser postergadas para
posteriores ciclos de planificacin.
Solicitante: Nombre, indicador y telfono de la(s) persona(s) solicitante(s).
Aprobador: Nombre, indicador y telfono de la(s) persona(s) aprobador(es).

Anexo N 3: Levantamiento del Proceso del Negocio.


PROCESO DE NEGOCIO
Los procesos de negocios se caracterizan por ser 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. Adems, estos procesos se hallan sujetos a un conjunto de reglas de
negocio, que determinan las polticas y la estructura de la informacin de la empresa. Por
tanto, la finalidad del modelado del negocio es describir cada proceso del negocio,
especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio.

Para el modelado de proceso de negocio se puede usar una extensin de UML que define
cuatro vistas estratgicas: visin, proceso, estructura y comportamiento.

VISTA DE VISIN DEL NEGOCIO


En esta vista se establece hacia donde va el negocio y su estrategia global.

Objetivo del Negocio

Misin

Visin

Matriz DOFA

Factores Crticos: Elementos necesarios para el crecimiento del negocio

Estrategias: Planes de accin para cumplir los objetivos

Roles: Funciones que cumplen los recursos humanos en el negocio

Unidades Organizacionales: rea de negocio

Procesos Claves: Son los procesos que traen ms valor al negocio

VISTA DE PROCESO DE NEGOCIO


En esta vista se representa las actividades de cada proceso de negocio y el valor
generado por cada uno de ellos.

Patrn de referencia para definicin de Procesos de Negocio:

Identificar el dominio del Proceso de Negocio en estudio: Unidades de Negocio, Procesos


y Sub-Procesos relacionados.

cd Procesos Entorno

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Logistica

Finanzas

Recursos Humanos

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version

Unregistered
Trial Version
EA 5.0 Viaj
Unregistered
Trial Contabiliadad
Version EA 5.0 Control
EA 5.0 Unregistered
Trial Version
es y Traslado
Interno de
Nmina
Tesorera
Finanzas

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Reserv acion y Serv icios

Gastos y Deudas del

Aprobacion de Pagos

Niv el Autoridad

Administrativ o y
trabaj ador
de Traslado
EA 5.0 Unregistered Trial
Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version
Financiero

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version

Modelado de proceso del negocio, donde se indiquen: entradas, salidas/productos,


procesos, actores de informacin (relaciones con otros sistemas/bases de datos),
participantes / usuario final, qu/quin regula el proceso, objetivo del proceso. Identifique
nuevas oportunidades o necesidades provenientes de la definicin del proceso de
negocio.

Modelado de entorno del proceso de negocio: es un diagrama de los procesos en nivel


1, en donde se muestran las relaciones que existen entre cada uno de los sub-procesos
en estudio y los procesos identificados en el dominio del negocio.

cd Interaccion entre procesos

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial
Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
suministra
Logistica

<<objeto>>
<<objeto>>

Tesoreria EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version


genera
EA 5.0 Unregistered Trial Version
EA 5.0
Unregistered
Trial Version EA 5.0 Unregistered Trial Version
Ordenes
de pago
Numero de
solicitud firmada

Transferencia
(Nota de Debito)

genera

insumo
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
suministra

EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0insumo
Unregistered Trial Version EA 5.0 Unregistered Trial Version
<<objeto>>
Contabilidad (copia)

insumo

-Informacion de rutas

insumo
EA 5.0 Unregistered
Trial
5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
-Informacion
de Version EA
insumo
proveedores

insumo

<<objeto>>

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered


Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
genera
Reservacion y
EA 5.0
Unregistered
Servicios
de Traslado Trial
genera

-Centro de Costos
-Cuentas de labor

<<objeto>>

suministra

Gastos
y Deudas EA
del 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Version EA 5.0 Unregistered Trial
Version
<<objeto>>
Archivo de pago
de proveedores

trabajador

-Documentos Descontados

Salida
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial-Documentos
VersionNo Descontados
EA 5.0 Unregistered Trial Version
<<objeto>>

Contabiliadad

EA
5.0 Unregistered Trial Version EA 5.0<<objeto>>
Unregistered Trial
regulaVersion EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
insumo
Movimientos
contables

- Normas y Procedimientos

genera

insumo

suministra
Corporativos
de Finanzas Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version
EA 5.0
Unregistered
<<objeto>>

genera

Recursos Humanos

Nmina

<<objeto>>

<<objeto>>

Solicitud Firmada
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0
Unregistered Trial
Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered
Trial Version
genera
insumo
Deducciones
-Informacion del trabajador
-Ordenes internas

<<objeto>>

por deuda

-Cadenas
aprobacion
insumo EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA
5.0 de
Unregistered
Trial Version EA 5.0 Unregistered
insumo Trial Version
Cadenas de
aprobacion

suministra

Salida
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version
<<objeto>>

Aprobacion de Pagos

<<objeto>>

salida
AutoridadEA 5.0
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered TrialNivel
Version
Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Informacion del
trabajador

insumo

Administrativo y
Financiero

Solicitud Autorizada

entrada

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version

VISTA DE COMPORTAMIENTO DEL PROCESO DE NEGOCIO


En esta vista se representan los elementos dinmicos del proceso de negocio.

Diagrama de Actividad

Se realiza el diagrama del conjunto de actividades que son realizadas para alcanzar el
objetivo del Proceso de Negocio bajo estudio bajo notacin UML.

Diagrama Proceso de Negocio (DPN)

Define el conjunto de actividades que realizan las Organizaciones para modelar, optimizar,
o adaptar sus procesos de negocio a las nuevas necesidades organizacionales. Involucra
el descubrimiento, diseo y distribucin de procesos de negocio, as como el control
ejecutivo, administrativo y supervisin de dichos procesos. DPN es una notacin estndar
para modelar visualmente flujos de procesos, tiene como objetivo proveer notacin comn
para analistas del negocio que crean los flujos iniciales de los procesos y desarrolladores
de software responsables por tecnologa e implementacin de los procesos. DPN est
basado entre Diagramas de Actividad de UML y Diagramas de Flujo Actividad-Decisin y
especifica un nico tipo de diagrama, DPN con un conjunto de elementos necesarios para
su elaboracin. Estos elementos estn divididos en cuatro categoras:

Objetos del flujo: eventos, actividades, gateways

Objetos de Conexin: flujo de secuencia, flujo de mensaje y asociacin

Swimlanes: pool, lane

Artefactos: objetos de los datos, grupos y anotaciones

VISTA DE ESTRUCTURA DEL PROCESO DE NEGOCIO

Esta vista muestra la estructura de los recursos, productos, servicios y la informacin del
negocio.

Modelo de Caso de Uso del Negocio

Los Casos de Uso del Negocio definen una secuencia de eventos que proveen valor a los
actores del negocio. Los actores del negocio son roles expresados por individuos,
organizaciones o sistemas que son externos al negocio.

Los Casos de Uso del Negocio permiten incrementar el conocimiento de un dominio y


entender el ambiente/contexto en el que un sistema ser utilizado, incorporado o
integrado, as como obtener el acuerdo de los requerimientos cuando se estn modelando
uno o ms sistemas para soportar procesos de negocio.

Los Casos de Uso del Negocio especifican el alcance y las responsabilidades de cada uno
de los sistemas o actores en la construccin de aplicaciones. Los Casos de Uso del

Negocio describen como los procesos son llevados a cabo por personas y los activos de la
organizacin.
Los actores de este modelo pueden representar la figura de Componentes Funcionales
(mdulo de software).

Diagramas de Caso de Uso del Negocio

A continuacin se muestra el diagrama de los Casos de Uso del Negocio. El diagrama de


casos de uso muestra los actores, los casos de uso y las relaciones entre ellos.

Especificacin de Caso de Uso del Negocio

El patrn para la especificacin de Casos de Uso del Negocio (CUN)

CASO DE USO

CUN.XX Ttulo del CUN

FUENTES

<Participantes que proporcionaron informacin de este CUN >

ACTOR

Act.# <nombre de los actores> [(<Pseudnimos>)] [ secundario]

DESCRIPCIN

Act.# <Descripcin del caso de uso de negocio>

FLUJO BSICO

3.

Ttulo del paso

Descripcin del paso.


4.

Ttulo del paso

Descripcin del paso.


FLUJOS ALTERNOS

3.

Ttulo del FA

Descripcin del FA
4.

Ttulo del FA

Descripcin del FA.


PRE CONDICIONES

2.

Ttulo del Precondicin

Descripcin del PRC


POST CONDICIONES

2.

Ttulo del Poscondiciones

REQUERIMIENTOS

1.

ESPECIALES

Descripcin del requerimiento o porqu se enlaza a el desde este caso de uso

SUPOSICIONES

1.

Descripcin de la PTC
Ttulo del requerimiento

Ttulo de la suposicin

Descripcin de la suposicin
REGLA

DE

NEGOCIOS
PUNTOS

Ttulo de la suposicin

Descripcin de la suposicin
DE

INCLUSIN
PUNTOS

2.

1. Ttulo del punto de inclusin


Descripcin del punto de inclusin

DE

1.

Ttulo del punto de extensin

EXTENSIN

Descripcin del punto de extensin

NOTAS

2.

Ttulo de la Nota

Descripcin de la nota

Diagramas de Objetos del Negocio

Un objeto de negocios (ON) o business object es una representacin mental de elementos


comnmente utilizados en un dominio particular del negocio y cubre elementos de
diferentes tipos, tales como:

Elementos fsicos: Un producto, una planta, un empleado.

Elementos de comunicacin: Orden de pago, facturas, una orden de produccin.

Elementos de informacin: Capacidad de produccin, inventario.

Identificacin de los Componentes Funcionales


[Si aplica] Identificacin y definicin de Componentes Funcionales involucrados en el
Proceso de Negocio y las aplicaciones representativas de los Componentes Funcionales
Un componente de acuerdo a la especificacin de UML es una parte modular de un
sistema que encapsula su contenido y que es reemplazable en su entorno. Un
componente define su comportamiento en trminos de sus interfases proporcionadas y
requeridas.
Un mdulo de software se puede representar como componente.
El Componente Funcional representa un tipo abstracto de aplicacin de valor para el
negocio que puede estar instanciado por uno o ms aplicaciones concretas.
Patrn para Componentes Funcionales del
Proceso de Negocio
COMPONENTE FUNCIONAL

<nombre del Componente Funcional>


Ej.: Gateway de Pagos, Facturador, Recaudador, Nmina.

FUNCIONALIDADES REQUERIDAS

<descripcin

de

la(s)

funcionalidad(es)

requeridas

del

Componente Funcional para el proceso de negocio>

Ej: Aprobaciones financieras; Solicitud de Boletos; Realizacin


de

pagos

en

lnea

con

las

entidades

bancarias;

Aprovisionamiento de cuentas recurrentes; Gestin de cuentas


por pagar.

APLICACIONES

APLICACIN QUE CONSTITUYE EL

NIVEL DE SATISFACCIN

COMPONENTE FUNCIONAL
Ej: NAAF; GADET; RESET.

<Nivel de satisfaccin de
los

usuarios

con

la(s)

en

la

informacin

es

aplicacin(es)
involucradas
migracin>.

Esta

provista por VDU


ARQUITECTURA DEL COMPONENTE FUNCIONAL

<arquitectura de

hardware

y software

del

Componente

Funcional>

Ej: Cliente/Servidor; Mainframe; Aplicacin Web en contenedor


Web; Aplicacin Web en Servidor de Aplicaciones.
AMBIENTE

Ambientes que posee el Componente Funcional y/o Aplicacin:


Desarrollo, QA y Produccin

PROVEEDOR

COSTOS LICENCIA

<Identificacin del proveedor del Componente Funcional>

<Descripcin del licenciamiento del Componente Funcional y su


costo>

COSTOS SOPORTE

<Costo de soporte del Componente Funcional>

Arquitectura del Proceso de Negocio

La relevancia de representar la arquitectura del proceso de negocio radica en


complementar la comprensin del proceso funcional con la configuracin de los
componentes de hardware, software y red que soportan el proceso de negocio.

El diagrama de despliegue permite representar la vista esttica de la configuracin de los


nodos de hardware y componentes de software, junto con el estereotipo de componentes,
apoya: 1. el diseo de la configuracin de hardware y software para soportar el proceso de
negocio; 2. la exploracin de aspectos relacionados con la ejecucin del proceso de
negocio en ambientes de prueba y produccin; 3. explorar las dependencias del proceso
de negocio con otros sistemas actualmente en produccin o propuestos para ser
integrados con el proceso de negocio bajo estudio.

Identificacin de Intercambios de Datos


[Si aplica] Identificacin de intercambios de datos entre los componentes funcionales o
aplicaciones involucradas en el proceso de negocio.
Orden
[si aplica]
1

Sncrono/

Origen

Destino

Descripcin

Datos Intercambiados

Recaudador

Gateway Pagos

Envo de rdenes

Segn definicin

Asncrono

pagos

Segn definicin

Asncrono

pagos

Segn definicin

Asncrono

Asncrono

de pago
2

Gateway Pagos

Recaudador

Envo

Gateway Pagos

Recaudador

Envo

de

cobrados
de

rechazados

Reglas de Negocio

Las reglas de negocios representan una coleccin de polticas y restricciones de negocio


de una organizacin. Estn divididas en tres tipos:

Reglas de Restriccin: especifican polticas o condiciones que restringen la


estructura y comportamiento de los objetos y procesos. Estas reglas pueden ser
divididas en reglas de estmulo-respuesta (que restringen el comportamiento y
especifican las condiciones que deben cumplirse para activar una operacin),
reglas de restriccin de operacin (que especifican condiciones que deben

cumplirse antes y despus de ejecutarse una operacin) y reglas estructurales (que


especifican restricciones sobre los tipos de objetos y las asociaciones).

Reglas de Derivacin: especifican polticas y condiciones para inferir o calcular


hechos (informacin) a partir de otros hechos existentes en el negocio.

Reglas de Existencia: que establecen cundo puede existir un determinado


objeto.

RN-<ID>

Tipo

Descripcin

RN-01

Reglas de Restriccin

Para entrar a la intranet de PDVSA, la


persona debe tener una cuenta y clave
de red.

Ejemplo

Observaciones

Anexo N 4: Gastos de Conceptualizacin

Mes N

Costos Contratos u
rdenes de
Servicio

Mes 2

Concepto

Mes 1

GASTOS DE CONCEPTUALIZACIN

Centro de Costo
PROYECTO XXXX
PRUEBAS & ASSESSMENTS
Prueba de Conceptos & Assessment OPCIN 1
Prueba de Conceptos & Assessment OPCIN 2
Prueba de Conceptos & Assessment OPCIN 3
Prueba de Conceptos & Assessment OPCIN N
CONSULTORES EXTERNOS [Segn tarifas base de PDVSA]
Analista P1
Analista P5
Concusltor Senior
Viticos
Boletos [Debe estimarse la necesidad de viajes al interior del pas]
Hospedaje
Licenciamiento [si aplica]
Licencias
Software
Infraestructura [Podra alquilarse un local s no existiera espacio en
PDVSA con el propsito de ejecutar las pruebas de concepto]
Alquiler de Local
Hardware [Debe estimarse si aplica]
Laptops
Impresoras & Scanners
Otros
Adiestramiento
Viticos Empleados
Impuestos
Propinas
Llamadas
Hospedaje
Alimentacin
Taxis
Estacionamiento
Refrigerios [Reuniones]
Gestin de Aprovisionamiento [Representa el 10% de los gastos, este
fondo es slo para cubrir emergencias y algn evento atpico]

TOTAL Bolvares (Bs)

TOTAL Bolvares Fuertes (BsF)

TOTAL EN US$

Anexo N 5: Planilla para solicitar recursos a MAP

Fecha:

Puesta en Produccin de un Servicio


IDENTIFICACION DEL SISTEMA / APLICACIN
Nombre del Sistema
Objetivo:
____________________________________________________________________________________

Gerente Responsable:

Empresa:

Fecha de pase a produccin:

CONTACTOS
Lder por AIT:
Aplicacin:
Base de Datos:
Redes:
Seguridad Lgica:
Servidores:
Proyecto:
Web:
Otro:

____________________________________________________________________________________

INFORMACION TECNICA
Caractersticas del Servidor(es) donde se va a instalar la aplicacin:

Interfase con otras


aplicaciones:
Requiere mas de 1
servidor:
Localidad :

Intrerfaz con SAP/R3

Sistema Operativo:

Versin:

Memoria:
Paquete(s) requerido(s):
Espacio en disco:

Estimacin de crecimiento (GB):

Web:
Extranet:
Manejador de Base de
Datos:
Nombre(s) de la(s)
instancia(s) de BD:

Versin:

Vendors

Tipo de Servicio:

Especifique: ___________

Criticidad:

Informacin de la Poltica de Respaldo


Poltica de Respaldo:
Poltica de Retencin:
Data a Respaldar:

______________________________
Toda la base de datos
___________________________________________________________________________________

UNIVERSIDAD SIMON BOLIVAR


DECANATO DE ESTUDIOS DE POSTGRADO
NOMBRE DEL ESTUDIANTE: Lina Titania Arias Moreno
TITULO DE LA TESIS: Gestin de Proyectos de Tecnologas de Informacin en la Gerencia
DIS
NOMBRE DEL ASESOR: Josselyn vila
MIEMBROS DEL JURADO: Andrs Loriente
PALABRAS CLAVES: Gestin de Proyectos, Tecnologa de Informacin, Metodologa de
Gestin de Proyectos de Tecnologa de Informacin, Proyectos
SOBRESALIENTE:

GRADUADO CON HONORES:

N DE PAGS: 139

FECHA DE GRADUACIN: Feb - 2010

ESPECIALIZACIN EN: Gerencia de Proyectos


RESUMEN
El propsito del presente trabajo fue apoyar la gestin de proyectos de Automatizacin,
Informtica y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e Implantacin de
Soluciones (DIS) de PDVSA, para esto se dise una Metodologa de Gestin de Proyectos
de Tecnologa de Informacin (TI), basada en las Guas de Gerencia para Proyectos de
Inversin de Capital (GGPIC), estndar de la corporacin.
En primer lugar se realiz un anlisis de la situacin actual para identificar la aplicabilidad de
las GGPIC, en los proyectos de Tecnologa de Informacin. Posteriormente, y en base a las
mejores prcticas de metodologas propias para la ejecucin de proyectos de TI como los son
RUP y UML, en conjunto con las fortalezas de las GGPIC, se elabor la propuesta de diseo
de una nueva metodologa para ser usada en la Gerencia (DIS) facilitando el trabajo de los
lderes, responsables por la gestin de los proyectos de Tecnologas de Informacin.
La propuesta fue validada y recibida de forma muy positiva por la Coordinacin de
Metodologas de DIS por lo cual se puede decir que se gener como resultado una
metodologa para la gestin de proyectos de TI, mucho ms completa y acorde a la realidad
de este tipo de proyectos debido a la incorporacin de todos los elementos tcnicos
necesarios para lograr una definicin adecuada de los mismos, que permiten a su vez su
correcto desarrollo y puesta en marcha, as como tambin fueron incluidas las actividades,
mas all de las propiamente tcnicas, sino de procesos que hay que cumplir, donde se
interacta con otras organizaciones de AIT y de PDVSA, constituyendo esto una herramienta
muy til para los lderes de proyecto y para la organizacin de Desarrollo e Implantacin de
Soluciones, apalancando a su vez la misin de AIT.

También podría gustarte