GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE …159.90.80.55/tesis/000150367.pdfCONCLUSIONES DEL EXAMEN...

�

UNIVERSIDAD SIMÓN BOLÍVAR

DECANATO DE ESTUDIOS DE POSTGRADO COORDINACIÓN DE POSTGRADOS EN GERENCIA ESPECIALIZACIÓN EN GERENCIA DE PROYECTOS

TRABAJO ESPECIAL DE GRADO

GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN EN LA GERENCIA DIS

por

LINA TITANIA ARIAS MORENO

Octubre de 2009

�




Trabajo Especial de Grado

presentado a la Universidad Simón Bolívar por

LINA TITANIA ARIAS MORENO

como requisito parcial

para optar al grado académico de

Especialista en Gerencia de Proyectos

Realizado con la tutoría de la Magister Scientiarum

JOSSELYN AVILA

Octubre de 2009

�

��

�




Por: Lina Titania Arias Moreno

Carnet No.: 0786152

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

Universidad Simón Bolívar por el siguiente jurado examinador:

Jurado

Andrés Loriente

Tutora

Josselyn Ávila (PDVSA)

28 de octubre de 2009

�

��

�




Por: Lina Titania Arias Moreno Carnet No.: 0786152

Tutora: Josselyn Ávila Fecha: octubre de 2009

RESUMEN El propósito del presente trabajo fue apoyar la gestión de proyectos de Automatización, Informática y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e Implantación de Soluciones (DIS) de PDVSA, para esto se diseñó una Metodología de Gestión de Proyectos de Tecnología de Información (TI), basada en las Guías de Gerencia para Proyectos de Inversión de Capital (GGPIC), estándar de la corporación. En primer lugar se realizó un análisis de la situación actual para identificar la aplicabilidad de las GGPIC, en los proyectos de Tecnología de Información. Posteriormente, y en base a las mejores prácticas de metodologías propias para la ejecución de proyectos de TI como los son RUP y UML, en conjunto con las fortalezas de las GGPIC, se elaboró la propuesta de diseño de una nueva metodología para ser usada en la Gerencia (DIS) facilitando el trabajo de los líderes, responsables por la gestión de los proyectos de Tecnologías de Información. La propuesta fue validada y recibida de forma muy positiva por la Coordinación de Metodologías de DIS por lo cual se puede decir que se generó como resultado una metodología para la gestión de proyectos de TI, mucho más completa y acorde a la realidad de este tipo de proyectos debido a la incorporación de todos los elementos técnicos necesarios para lograr una definición adecuada de los mismos, que permiten a su vez su correcto desarrollo y puesta en marcha, así como también fueron incluidas las actividades, mas allá de las propiamente técnicas, sino de procesos que hay que cumplir, donde se interactúa con otras organizaciones de AIT y de PDVSA, constituyendo esto una herramienta muy útil para los líderes de proyecto y para la organización de Desarrollo e Implantación de Soluciones, apalancando a su vez la misión de AIT. Palabras clave: Gestión de Proyectos, Tecnología de Información, Metodología de Gestión de Proyectos de Tecnología de Información, Proyectos

�

��

INDICE

INTRODUCCIÓN ....................................................................................................................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. Específicos...................................................................................................................................... 5

1.3. METODOLOGÍA.................................................................................................................................... 5 1.3.1. Elaboración de un Marco Conceptual Referencial .......................................................................... 5 1.3.2. Presentar el Marco Organizacional ................................................................................................. 6 1.3.3. Elaboración del Examen de la Situación ......................................................................................... 6 1.3.4. Elaboración de la Propuesta ........................................................................................................... 6 1.3.5. Evaluación de la Propuesta Elaborada ........................................................................................... 7 1.3.6. Evaluación 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. GESTIÓN DE PROYECTOS................................................................................................................ 10

2.3. TECNOLOGÍA DE INFORMACIÓN (TI) .............................................................................................. 13 2.3.1. Tecnología de Información en la Empresa.................................................................................... 14

2.4. GESTIÓN DE PROYECTOS DE TI...................................................................................................... 15

2.5. GUÍAS DE GERENCIA PARA PROYECTOS DE INVERSIÓN DE CAPITAL (GGPIC): ..................... 16 2.5.1. Objetivo de las GGPIC.................................................................................................................. 17 2.5.2. Ciclo de Vida de Proyectos Según 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. TECNOLOGÍA DE OBJETOS ............................................................................................................. 21 2.6.1. Una Perspectiva Histórica............................................................................................................. 22 2.6.2. Fortalezas de la Tecnología Orientada a Objetos ......................................................................... 23 2.6.3. Análisis y Diseño Orientado a Objetos .......................................................................................... 23

2.7. LENGUAJE DE MODELADO UNIFICADO (UML) .............................................................................. 24 2.7.1. Descripción del Lenguaje.............................................................................................................. 24 2.7.2. Descripción 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 implementación............................................................................................... 27

2.8. PROCESO UNIFICADO RATIONAL (RUP) ........................................................................................ 27 2.8.1. Dimensión 1: Fases del ciclo de vida RUP.................................................................................... 29

2.8.1.1. Inicio ...................................................................................................................................... 29 2.8.1.2. Preparación ........................................................................................................................... 30 2.8.1.3. Construcción.......................................................................................................................... 30 2.8.1.4. Transición .............................................................................................................................. 30

2.8.2. Dimensión 2: Disciplinas ............................................................................................................... 31 2.8.2.1. Modelado del Negocio ........................................................................................................... 31 2.8.2.2. Requerimientos...................................................................................................................... 32 2.8.2.3. Análisis y Diseño.................................................................................................................... 32 2.8.2.4. Implementación...................................................................................................................... 32 2.8.2.5. Pruebas ................................................................................................................................. 32 2.8.2.6. Despliegue............................................................................................................................. 33 2.8.2.7. Gestión y Configuración de Cambios..................................................................................... 33 2.8.2.8. Gestión del Proyecto.............................................................................................................. 33 2.8.2.9. Entorno .................................................................................................................................. 34

3. CAPÍTULO III .............................................................................................................. 35

MARCO ORGANIZACIONAL.............................................................................................. 35

3.1. PETRÓLEOS DE VENEZUELA (PDVSA) ........................................................................................... 35 3.1.1. Descripción 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. Refinación.............................................................................................................................. 40 3.1.2.5. Infraestructura........................................................................................................................ 40 3.1.2.6. Integración ............................................................................................................................. 40

3.2. AUTOMATIZACIÓN, INFORMÁTICA Y TELECOMUNICACIONES (AIT) .......................................... 41 3.2.1. Breve Histórico.............................................................................................................................. 41 3.2.2. Visión ............................................................................................................................................ 42 3.2.3. Misión ........................................................................................................................................... 42 3.2.4. Objetivos Estratégicos .................................................................................................................. 42

3.3. DESARROLLO E IMPLANTACIÓN 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. CAPÍTULO IV.............................................................................................................. 47

�

��

EXAMEN DE LA SITUACIÓN ............................................................................................. 47

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

4.2. PLANIFICACIÓN DEL PROCESO ...................................................................................................... 47

4.3. EJECUCIÓN DEL EXAMEN DE LA SITUACIÓN................................................................................ 48

4.4. RESULTADOS DEL EXAMEN DE LA SITUACIÓN............................................................................ 51

4.5. CONCLUSIONES DEL EXAMEN DE LA SITUACIÓN........................................................................ 51

5. CAPÍTULO V............................................................................................................... 53

PROPUESTA DE METODOLOGÍA DE GESTIÓN DE PROYECTOS DE TECNOLOGÍA DE INFORMACIÓN EN LA GERENCIA DIS ...................................................................... 53

5.1. JUSTIFICACIÓN DE LA PROPUESTA............................................................................................... 53

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

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

5.4. LA PROPUESTA: METODOLOGÍA DE GESTIÓN DE PROYECTOS DE TECNOLOGÍA DE INFORMACIÓN.............................................................................................................................................. 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 Básicos ....................................................................................... 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 Decisión 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 Contratación........................................................................................................ 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 Operación el Ambiente de Producción............................................................... 102 5.4.5.2. Crear estructura de la solución ............................................................................................ 103 5.4.5.3. Completar Plan de Contingencia.......................................................................................... 103 5.4.5.4. Realizar adiestramiento a Gestión 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. Aceptación de Instalaciones ................................................................................................ 105 5.4.5.8. Elaboración de Informes Finales......................................................................................... 105

�

��

6. CAPÍTULO VI............................................................................................................ 106

EVALUACIÓN DE LA PROPUESTA ................................................................................ 106

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

6.3. VIABILIDAD DE IMPLANTACIÓN DE LA PROPUESTA.................................................................. 107

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

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

7. CAPÍTULO VII........................................................................................................... 109

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

7.1. CONCLUSIONES .............................................................................................................................. 109

7.2. RECOMENDACIONES...................................................................................................................... 110

8. ANEXOS ................................................................................................................... 114

Anexo N° 1: Clasificación de Estimados de Costo .................................................................................. 115

Anexo N° 2: Plantilla de Datos Básicos .................................................................................................... 116

Anexo N° 3: Levantamiento del Proceso del Negocio. ............................................................................ 117

Anexo N° 4: Gastos de Conceptualización ............................................................................................... 128

Anexo N° 5: Planilla para solicitar recursos a MAP ................................................................................. 129

�

��

INDICE DE TABLAS

Tabla 1 Cronograma de Ejecución del Proyecto��

Tabla 2 Esfuerzo vs. Fases RUP��

Tabla 3 Aplicabilidad de las GGPIC en Proyectos de TI��

Tabla 4 Atributos de Priorización��

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 Características Generales de la Solución TI��

Tabla 10 Identificación de Servicios��

Tabla 11 Identificación de Intercambio de Datos��

Tabla 12 Especificación de Servicios��

Tabla 13 Especificación de Funcionalidad de Servicios��

Tabla 14 Contenido de un Contrato de Servicios��

Tabla 15 Descripción de Actores��

Tabla 16 Especificación de Casos de Uso��

Tabla 17 Requerimientos de Información��

Tabla 18 Requerimientos No Funcionales��

Tabla 19 Prueba de Aceptación��

Tabla 20 Plan de Desembolsos por Productos��

�

��

INDICE DE FIGURAS

Fig. 1 La Triple restricción................................................................................................................................. 9 Fig. 2 Ciclo de Vida de Proyectos según 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 Programación 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 Decisión .................................................................................................... 58 Fig. 16 Diagrama de Secuencia...................................................................................................................... 65 Fig. 17 Modelo de Casos de Uso.................................................................................................................... 75 Fig. 18 Ejemplo Diseño de Arquitectura.......................................................................................................... 84 Fig. 19 Ejemplo de Diagrama de Clase .......................................................................................................... 86 Fig. 20 Ejemplo Modelo E-R ........................................................................................................................... 87 Fig. 21 Contenido Típico de un DSO .............................................................................................................. 92

�

�

�

INTRODUCCIÓN

La gerencia de proyectos data de hace mas de 4.000 años, donde de manera empírica o,

si se puede decir, informal, se aplicó en la construcción de grandes obras como lo fueron

las pirámides de Egipto; pero es solo hace poco mas de 50 años, cuando la gerencia de

proyectos surge como ciencia y se le ha dado la importancia que amerita en la

consecución 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.

Petróleos de Venezuela (PDVSA), específicamente la gerencia de Automatización,

Informática y Telecomunicaciones (AIT), no es la excepción cuando se afirma que a los

proyectos hoy en día se les ha dado la importancia que requieren, razón por la cual fue

creada la organización Desarrollo e Implantación de Soluciones (DIS), cuyo principal

objetivo es definir e implantar soluciones integrales eficientes y eficaces en términos de

costo y oportunidad, principalmente del área de Tecnología de Información (TI).

La gestión 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 metodología de proyectos propia para el caso de Tecnología de Información, aunque

se cuenta con el estándar de PDVSA denominado Guías de Gerencia para Proyectos de

Inversión de Capital, este fue ideado en sus orígenes para proyectos mayores de

ingeniería y construcción.

Con el presente Trabajo Especial de Grado (TEG) se pretende diseñar una metodología

de gestión de proyectos de Tecnología de Información, que apoye la gestión de la

organización Desarrollo e Implantación de Soluciones, incorporando todos los elementos

técnicos 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 ejecución de los proyectos.

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

Fase de Planificación: está compuesta por el capítulo I donde se aprecia como fue

planificado el proyecto de TEG, su justificación, objetivos de estudio, metodologías para

elaborar el marco conceptual, marco organizacional, examen de la situación, elaboración

de la propuesta, evaluación de la misma y del proceso general cumplido, así como el

cronograma de ejecución.

Fase de Ejecución: esta fase presenta el capítulo II, marco conceptual referencial donde

se encuentran los fundamentos conceptuales pertinentes al caso de estudio; el capítulo III

que contiene el marco organizacional, lo cual permite conocer el ámbito donde se aplicará

la propuesta del TEG; el capítulo IV que permite observar como se llevará a cabo el

examen de la situación, destacando el objetivo del proceso, su planificación, ejecución,

resultados y conclusiones de dicho examen; el capítulo V donde destaca la propuesta del

TEG, su justificación, objetivo, proceso de elaboración, para finalmente concluir con la

propuesta.

Fase de Evaluación: cuenta con el capítulo VI de evaluación de la propuesta, lo cual

incluye los resultados relevantes, la viabilidad de implantación de la propuesta, la revisión

del cumplimiento del cronograma de ejecución y la evaluación del logro de los objetivos.

Por último, el TEG cierra con el capítulo VII donde se reflejan las conclusiones y

recomendaciones.

�

�

�

CAPITULO I

El PROYECTO DE TRABAJO ESPECIAL DE GRADO

En las páginas siguientes se expone el Proyecto de Trabajo Especial de Grado presentado

a las instancias correspondientes. Se expone la justificación, los objetivos, la metodología

establecida, concluyendo con el cronograma de ejecución.

1.1. JUSTIFICACION

“Un proyecto consiste en una combinación de recursos organizacionales integrados para

crear algo que no existía antes, y eso proporcionará una mejor capacidad de desempeño

en el diseño y ejecución de las estrategias organizacionales” (Cleland y Ireland, 2001, p.

12). “La gestión 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/Gestión_de_proyectos,

consultado el 14/04/2009).

“Petróleos de Venezuela (PDVSA) es la corporación estatal de la República Bolivariana de

Venezuela que se encarga de la exploración, producción, manufactura, transporte y

mercadeo de los hidrocarburos, de manera eficiente, rentable, segura, transparente y

comprometida con la protección ambiental”. (http://www.pdvsa.com/, consultado el 14-04-

2009).

“Automatización, Informática y Telecomunicaciones (AIT) es la organización que rige,

provee y mantiene los servicios y soluciones integrales de tecnologías de automatización,

información y comunicaciones de la corporación” (Planificación AIT, 2007).

La Gerencia Desarrollo e Implantación de Soluciones (DIS) debe cumplir la importante

función de definir e implantar soluciones integrales de AIT eficientes y eficaces en términos

�

�

de costo y oportunidad para satisfacer necesidades de PDVSA y la Nación, que

apalanquen las metas y objetivos de PDVSA cumpliendo con lineamientos, estándares y

normas nacionales e internacionales adoptadas por la Corporación (Gestión y

Mejoramiento de Procesos, 2007), por esta razón es de vital importancia contar con una

metodología de Gestión de Proyectos que apoye esta función de manera eficaz.

El lineamiento corporativo indica que AIT debe usar para la Gestión de Proyectos la Guía

de Gerencia para Proyectos de Inversión de Capital (GGPIC), esta guía fue diseñada 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 Ingeniería

y Construcción.

Pareciera entonces que la Gerencia DIS no contara con la metodología apropiada para la

Gestión de Proyectos del área de su competencia, es decir, de Tecnología de Información

(TI).

En ese contexto, surgió la necesidad de contar con una metodología de Gestión de

Proyectos de TI, basada en las GGPIC, que son el estándar de PDVSA, validando su

aplicabilidad y adaptándola con los complementos necesarios de manera de que se

generara una metodología que realmente sirviera de apoyo a la gerencia DIS en la gestión

de sus proyectos.

Con el presente Trabajo Especial de Grado se diseñó una metodología de gestión de

proyectos basada en las GGPIC, adaptada según las necesidades de la gestión de

proyectos de TI, que sirve de referencia para los líderes de proyecto que trabajan en la

gerencia DIS, en el cumplimiento de su función 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 gestión de proyectos de Automatización, Informática y Telecomunicaciones

(AIT), en la Gerencia de Desarrollo e implantación de Soluciones (DIS) de PDVSA;

mediante el diseño de una Metodología de Gestión de Proyectos de Tecnología de

Información, basada en las Guías de Gerencia para Proyectos de Inversión de Capital

(GGPIC) de PDVSA.

1.2.2. Específicos

• Analizar el potencial de uso de las Guías de Gerencia de Proyectos de Inversión de

Capital, GGPIC, para proyectos de Automatización, Informática y

Telecomunicaciones convalidando el real grado de aplicabilidad de las mismas

frente a las características y estrategias de desarrollo de los proyectos de AIT y

ante la organización actual basada en procesos.

• Elaborar una propuesta de Metodología de Gestión de Proyectos de Tecnología de

Información aprovechando la aplicabilidad de las GGPIC, incorporando las

adaptaciones necesarias para manejar proyectos de AIT.

• Validar la aplicabilidad de la propuesta con la Coordinación de Metodologías de la

Gerencia de Desarrollo e Implantación de Soluciones para implantarla como parte

de este proceso en la gestión de los proyectos de AIT.

1.3. METODOLOGÍA

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

1.3.1. Elaboración de un Marco Conceptual Referencial

Inicialmente se expondrían los conceptos básicos del ciclo de vida de los proyectos de

acuerdo a las Guías de Gerencia para Proyectos de Inversión de Capital (GGPIC)

(PDVSA, 1999). Luego, utilizando las referencias bibliográficas 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

realizaría el análisis de aplicabilidad de las GGPIC a la gestión de proyectos de software, y

las adaptaciones correspondientes para lograr diseñar una metodología para gestión de

proyectos de Tecnologías de Información (TI) eficiente incorporando los elementos

necesarios según 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

organización Desarrollo e Implantación de Soluciones (DIS) (Gestión y Mejoramiento de

Procesos, 2007), perteneciente a la Gerencia de Automatización, Informática y

Telecomunicaciones (AIT) de PDVSA, con lo cual se realizaría una breve descripción de

las mismas, destacando sus objetivos, ya que en esta organización se aplica el proceso

objeto de este estudio, es decir, la gestión de proyectos.

1.3.3. Elaboración del Examen de la Situación

Para realizar el examen de la situación se dispuso realizar un análisis comparativo de las

GGPIC vs. la metodología RUP/UML determinando la aplicabilidad de las primeras en

proyectos de Tecnologías de Información. El proceso básico consistiría en revisar cada

una de las fases del ciclo de vida de un proyecto según las GGPIC, utilizando tablas donde

se pudiera seleccionar la aplicabilidad de las actividades de cada fase en el desarrollo de

proyectos de Tecnologías de Información, para finalmente concluir con los resultados.

1.3.4. Elaboración de la Propuesta

Para elaborar la propuesta de diseño de una metodología aplicable a la Gestión de

Proyectos de Tecnologías de Información en la organización DIS, se estableció tomar

todos los elementos considerados como fortalezas identificadas, aplicables de las GGPIC,

utilizando el resultado obtenido del examen de la situación, y complementarlos con los

elementos necesarios que se extraerían de la metodología RUP/UML, obteniendo como

resultado una metodología que permitiría gestionar eficientemente los proyectos de TI, sin

contradecir el lineamiento corporativo que exige el uso de las GGPIC como base para la

gestión de proyectos en PDVSA.

�

�

1.3.5. Evaluación de la Propuesta Elaborada

La propuesta elaborada será presentada a Coordinación de Metodologías que forma parte

de la organización Desarrollo e Implantación de Soluciones (DIS), el coordinador de

acuerdo a su experiencia, evaluará la pertinencia y viabilidad de aplicar la metodología, y,

de ser aceptada, será aplicada en la gestión de un nuevo proyecto que esté por comenzar.

1.3.6. Evaluación del Proceso General cumplido

Para la evaluación del proceso de Trabajo Especial de Grado, se analizaría la

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

ejecución; y, el grado de logro de los objetivos.

1.4. CRONOGRAMA DE EJECUCION.

Para el cumplimiento de los pasos definidos en la metodología se estableció cumplir el

siguiente cronograma:

Tabla 1 Cronograma de Ejecución del Proyecto

�

�

�

�

2. CAPITULO II

MARCO CONCEPTUAL REFERENCIAL

Para entender la necesidad existente de una metodología de gestión de proyectos de TI,

es importante señalar los conceptos básicos de proyecto, gestión de proyectos, tecnología

de información (TI), gestión de proyectos de TI, Guías de Gerencia de Proyectos de

Inversión de Capital (GGPIC), metodología Rational del Proceso Unificado o Rational

Unified Process (RUP), Tecnología 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 diseño,

construcción u otro, el cual contiene un conjunto de actividades formalmente

organizadas a las cuales se les han establecido fechas de inicio y terminación y

consumen recursos humanos, materiales, equipos, tiempo y dinero (IESA, 2005,

p. 2)

Según Kerzner (2001) un proyecto puede ser considerado como una serie de actividades y

tareas que:

• Tienen un objetivo específico para ser completadas bajo ciertas especificaciones.

• Tienen definidas las fechas de comienzo y fin.

�

• Tienen limitaciones en la dotación 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 señalados

anteriormente, que un proyecto es un conjunto de actividades lógicamente 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 características se les

conoce como la triple restricción (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 restricción

Se considera que en los proyectos el esfuerzo es “temporal” porque tienen un comienzo y

un fin definido; el fin debería 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 construcción de edificios, tiene sus propias características. En el ejemplo de la

construcción 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 ubicación, el terreno, etc.

Como punto importante para concluir el concepto de proyectos, debe decirse que la

ejecución de los mismos debe ser gradual, puesto que al inicio solo se tiene una visión

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 serán los resultados que se pretenden obtener.

2.2. GESTIÓN DE PROYECTOS

Desde las más tempranas épocas de la historia de la humanidad la dirección de proyectos

tuvo una gran importancia y repercusión. Desde la construcción de las pirámides de Egipto

y hasta las del pueblo Maya tuvieron que utilizar la dirección de proyectos para su

realización. Los constructores de esas estructuras fueron los primeros directores de

proyectos del mundo. No contaban con la ayuda de computadoras ni con herramientas de

programación como la PERT (Performance Evaluation and Review Technique, técnica de

evaluación y revisión del rendimiento) o el CPM (Critical Path Method, método del camino

crítico), y en ocasiones ni siquiera con papel para dibujar planos. A pesar de ello, dirigieron

proyectos de una complejidad excepcional utilizando las herramientas más sencillas.

Aunque la dirección de proyectos tiene una antigüedad de al menos 4.500 años, hasta

muy recientemente no ha sido reconocido el papel del director de proyectos como

disciplina por derecho propio, sin embargo, hoy en día hay incluso universidades que

dictan cursos de proyectos a nivel de doctorado.

Algunos factores clave que determinan el éxito de un proyecto según 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 misión, los objetivos y los propósitos 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 participación fue una

experiencia valiosa para ellos.

• Se obtuvo un beneficio del trabajo efectuado en el proyecto.

• El trabajo del proyecto produjo algunos avances tecnológicos que prometen dar a la

empresa una ventaja frente a sus competidores.

Para que estos factores estén presentes en los proyectos, es indispensable una adecuada

gestión durante su ejecución. Por esto es importante conocer que la gestión de proyectos

es:

La aplicación de conocimientos, habilidades, técnicas y herramientas con la

intención de satisfacer o superar los requerimientos del dueño 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 número 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 más bajo

costo y con la calidad requerida, es decir, dentro de los parámetros de la triple restricción,

en un ambiente de trabajo seguro, armónico 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

heterogéneo de profesionales y trabajadores; y es una ciencia porque se maneja una gran

cantidad de información necesaria para planificar y controlar el trabajo con el fin de

�

�

mantener un balance entre el tiempo de ejecución y los costos, evitando así una demanda

excesiva y desorganizada de recursos.

Como consecuencia de la gestión 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 país se le puede conocer como Gerente, Administrador, Director o Líder de

Proyecto, incluso pueden convivir varios de estos nombres dependiendo de cómo 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á Líder de Proyectos.

Lo cierto es que el Líder del Proyecto es el responsable de alcanzar los objetivos del

mismo, por lo tanto, entre otras cosas, según el Project Management Institute (2004) el

líder 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 gestión por si sola no garantiza el éxito de los proyectos, para que haya una buena

gestión es necesario contar con un buen líder de proyectos que tenga las siguientes

pericias:

• Liderazgo: indicar la dirección, los lineamientos y motivar al personal, así como

gerenciar la asignación y procura oportuna de recursos para la consecución óptima

de los objetivos.

• Comunicación: Los buenos líderes son básicamente comunicadores. El líder debe:

� Remitir información clara, precisa, completa y oportuna.

� Recibir información completa y entenderla.

�

��

� Proveer canales de comunicación eficaces, lo cual es esencial para el éxito

del proyecto.

� Utilizar diversos tipos de comunicación: escrita u oral; formal o informal;

interna o externa y vertical u horizontal.

• Negociación: alcanzar acuerdos que satisfagan a las partes.

• Solución: definir problemas ya sean internos, externos, técnicos, gerenciales,

económicos 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 aplicación de la Gestión de Proyectos en manos de un buen Líder de

Proyectos, aumenta considerablemente las probabilidades de éxito de los mismos.

2.3. TECNOLOGÍA DE INFORMACIÓN (TI)

Un concepto de Tecnología de Información según http://www.ntn-

consultores.com/paginas/tecnologia.htm:

“Es la plataforma e infraestructura tecnológica que mantiene las operaciones de

los servicios de información de una compañía. La tecnología incluye la

planificación estratégica de sistemas de información, la implantación de

tecnología y paquetes, distribución de datos y procesos, auditoria de sistemas,

diseño de modelos de datos, ingeniería de información con tecnología y

herramientas y técnicas de desarrollo acelerado” (consultado el 10-06-2009)

Asimismo, la TI se comprende como la utilización de tecnología para el manejo y

procesamiento de información, específicamente la captura, transformación,

almacenamiento, protección, y recuperación de datos e información.

Los orígenes de la TI son recientes. Aunque el nombre de Tecnología de Información se

remonta a los años 70, su utilización en los negocios se remonta a mediados del siglo XX,

durante la segunda guerra mundial. Sin embargo, ha sido en los últimos 20 años 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 día es prácticamente

indispensable.

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

comunicación, con lo cual se suele hacer referencia a un tema aún más amplio, conocido

como Tecnología de Información y Comunicaciones, o TIC.

2.3.1. Tecnología de Información en la Empresa

El departamento o equipo que dentro de una organización ejerce las funciones de TI se

encarga de estudiar, diseñar, desarrollar, implementar y administrar los sistemas de

información utilizados para el manejo de datos e información de toda la organización.

Estos sistemas, a su vez, comprenden aplicaciones o software, y equipos o hardware.

Llevar a cabo las tareas de la organización apoyándose en la tecnología de información,

generalmente redunda en un procesamiento más rápido y confiable de su datos. La

información 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, permitiéndoles

aprovechar mejor su tiempo en actividades que agregan más valor

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

A medida que los precios de los equipos de computación bajan, su capacidad aumenta, y

se hacen más fáciles de usar, la TI se utiliza en nuevas y variadas formas. En las

empresas, sus aplicaciones son diversas. Hoy en día, la mayoría de las empresas

medianas y grandes (y cada día más pequeñas 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, facturación,

cobranza, pagos, compras, y mucho más.

�

��

2.4. GESTIÓN 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 gestión de TI, peticiones de

nuevos proyectos y cambios en los mismos; necesitan ser cada vez más eficientes, con

recursos humanos, tecnológicos y financieros, sin embargo, cada vez más 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 definición de gestión de proyectos aplicada a proyectos de tecnologías de información

se puede ver como “un sistema de cursos de acción simultáneos y/o secuenciales que

incluye personas, equipamientos de hardware, software y comunicaciones, enfocados en

obtener uno o más resultados deseables sobre un sistema de información”

(http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/c1/c1.htm,

consultado el 09-06-2009).

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

de estar orientado hacia cinco retos clave:

• Negocio estratégico.

• Globalización.

• Arquitectura de la información.

• Inversión en sistemas de información.

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

El proyecto de TI debe ser entendido como una decisión estratégica de la empresa, bien

como consecuencia de una necesidad de informatizar una tarea o bien para mejorarla, por

propia evolución o por cambios estratégicos.

�

�

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):

• Físicos

� Sistema central

� Periféricos

� Comunicaciones

• Lógicos

� Estructuras de almacenamiento

� Monitores de comunicaciones

� Lenguajes

� Utilidades

� Métodos de desarrollo

� Control de seguridad y desarrollo

• Humanos

� Selección

� Formación

� Incentivación

2.5. GUÍAS DE GERENCIA PARA PROYECTOS DE INVERSIÓN DE CAPITAL

(GGPIC):

Las Guías de Gerencia para Proyectos de Inversión de Capital son unas guías que

contienen lineamientos prácticos para la ejecución de un proyecto de una manera

normalizada en nuestro sistema y ordenada, de modo que ningún 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 Corporación (PDVSA, 1999).

Las GGPIC, son utilizadas en PDVSA como lineamiento Corporativo para la gestión de

proyectos, las mismas abarcan:

“El proceso de ejecución de proyectos mayores (…) desde el momento en que

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

�

��

concretización y definición de propuestas y proyectos en las filiales, pasando por

todo el ciclo presupuestario y aprobatorio, el ciclo de planificación y ejecución 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 divulgación y la evaluación 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 guías de uso práctico en la ejecución de

proyectos, de manera de instituir a nivel de la industria una forma estándar de pensar y

trabajar.

La idea de estas guías es resumir y englobar una serie de reglas y prácticas de gerencia

que permita a los participantes del proyecto conducirse exitosamente a través de todas las

fases, desde su visualización 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 próxima y acometer costos adicionales (PDVSA, 1999).

2.5.2. Ciclo de Vida de Proyectos Según las GGPIC

Según las GGPIC, el ciclo de vida de los proyectos está constituido por cinco fases las

cuales se muestran esquemáticamente en la siguiente figura:

�

Fig. 2 Ciclo de Vida de Proyectos según las GGPIC

�

��

A lo largo de todo el proceso de ejecución de proyectos y al terminar cada una de las

fases hay que tomar decisiones importantes, las cuales están tipificadas por los rombos

D1 al D4 en la figura anterior.

2.5.3. Fases del Ciclo de Vida de Proyectos

Para conocer en términos generales en qué consisten las fases del ciclo de vida de

proyectos según las GGPIC, se dará una breve descripción de cada una de ellas, y se

representará de manera gráfica 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 Corporación, a raíz de un análisis externo/interno, o de un análisis

de Fortalezas, Oportunidades, Debilidades, Amenazas (FODA), que son realizados como

parte de los ciclos de planificación.

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

siguiente gráfica:

�

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 solución del proyecto, así como también se afinan los

estimados de costos, logrando:

• Reducir la incertidumbre y cuantificar los riesgos asociados.

• Determinar el valor esperado para la(s) opción(es) seleccionada(s).

Básicamente, esta fase busca cumplir con dos objetivos principales:

• Organizarse para la fase de planificación del proyecto.

• Seleccionar la(s) opción(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 continuación:

�

Fig. 4 Fase Conceptualizar

2.5.3.3. Definir

En esta fase del ciclo de vida de los proyectos según las GGPIC se trabaja

fundamentalmente en una definición detallada del alcance, al igual que en la planificación

tanto en tiempo como en costos con un nivel de precisión clase II, de la ejecución de la

�

�

opción de solución 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 aprobación del proyecto y de los fondos,

se procede con la materialización 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 transición entre la construcción y la puesta en servicio de las

instalaciones, para finalmente entrar en operación.

En esta transición ocurre un solapamiento ya que en esta fase se le deben dar los toques

finales a la construcción, es decir, completar la lista de pendientes que pueda tener el

proyecto. Posteriormente se realizan las pruebas y la aceptación 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 descripción de las GGPIC, es fácil evidenciar como las mismas

constituyen una herramienta especialmente útil para proyectos de Ingeniería y

Construcción.

2.6. TECNOLOGÍA DE OBJETOS

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de

programación, además se viene aplicando en el análisis y diseño de soluciones de

Tecnología de Información con mucho éxito, al igual que en las bases de datos. Para

hacer una buena programación orientada a objetos hay que desarrollar todo el sistema

aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a

objetos.

�

“La programación orientada a objetos es una de las formas más populares de

programar y ha tenido gran acogida en el desarrollo de proyectos de Tecnología

de Información en los últimos años. 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 Histórica

Según http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ (consultado el 11-

06-2009), tradicionalmente, la programación fue hecha en una manera secuencial o lineal,

es decir, una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.

�

Fig. 8 Programación Tradicional

Los lenguajes basados en esta forma de programación ofrecían 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 líneas de

código en un sólo bloque se vuelve una tarea complicada.

Frente a esta dificultad aparecieron los lenguajes basados en la programación

estructurada. La idea principal de esta forma de programación es separar las partes

complejas del programa en módulos o segmentos que sean ejecutados conforme se

requieran. De esta manera se logra un diseño modular, compuesto por módulos

�

�

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

programación fue reemplazando al estilo “espagueti” impuesto por la programación lineal.

Entonces, se puede observar que la evolución que se fue dando en la programación se

orientaba siempre a ir descomponiendo más la solución. Este tipo de descomposición

conduce directamente a la programación orientada a objetos.

La creciente tendencia de crear programas cada vez más 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 programación estructurada ni mucho menos la programación lineal. Es

así como aparece la Programación Orientada a Objetos (POO). La POO viene de la

evolución de la programación estructurada; básicamente la POO simplifica la

programación con la nueva filosofía y nuevos conceptos que tiene. La POO se basa en

dividir el programa en pequeñas unidades lógicas de código. A estas pequeñas unidades

lógicas de código se les llama objetos. Los objetos son unidades independientes que se

comunican entre ellos mediante mensajes.

2.6.2. Fortalezas de la Tecnología Orientada a Objetos

• Fomenta la reutilización y extensión del código.

• Permite crear sistemas más complejos.

• Permite relacionar el sistema con el mundo real.

• Facilita la creación de programas visuales.

• Favorece la construcción 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. Análisis y Diseño Orientado a Objetos

Para el desarrollo de soluciones de tecnología de información orientado a objetos no basta

usar un lenguaje orientado a objetos. También se necesita realizar un análisis y diseño

orientado a objetos.

�

�

El modelamiento visual es la clave para realizar el análisis orientado a objeto (OO). Desde

los inicios del desarrollo de software OO han existido diferentes metodologías para hacer

el modelamiento, pero sin lugar a duda, el Lenguaje de Modelado Unificado (UML) puso

fin a la guerra de metodologías.

Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier

tipo de sistemas (no solamente de software) usando los conceptos de la orientación a

objetos. Y además, este lenguaje debe ser entendible para los humanos y las máquinas.

Actualmente en la industria del desarrollo de software se tiene al UML como un estándar

para el modelamiento de sistemas OO. Fue la empresa Rational quien creó estas

definiciones y especificaciones del estándar UML, y lo abrió al mercado. La misma

empresa creó uno de los programas más conocidos hoy en día para este fin: el Rational

Rose, pero también 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 fáciles de comunicar, cambiar, expandir, validar y

verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes

plenamente reutilizables, en la sección siguiente se hablará con más detalle de UML.

2.7. LENGUAJE DE MODELADO UNIFICADO (UML)

2.7.1. Descripción del Lenguaje

UML es un lenguaje de propósito 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 ingeniería 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 diseñadores de coches

preparan modelos en sistemas existentes con todos los detalles y los ingenieros de

software deberían igualmente construir modelos de los sistemas software.

�

�

Un enfoque sistemático permite construir estos modelos de una forma consistente

demostrando su utilidad en sistemas de cierto tamaño. Cuando se trata de un programa

de cincuenta, cien líneas, la utilidad del modelado parece discutible pero cuando se

involucra a cientos de desarrolladores trabajando y compartiendo información, el uso de

modelos y el proporcionar información sobre las decisiones tomadas, es vital, no sólo

durante el desarrollo del proyecto, sino una vez finalizado éste, cuando se requiere algún

cambio en el sistema. En realidad, incluso en el proyecto más simple los desarrolladores

hacen algo de modelado, aunque sea de manera informal.

Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se

ignoran los demás, por lo cual con un único modelo no se tiene suficiente (Rueda, 2006).

2.7.2. Descripción de los Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho

sistema, considerando un cierto propósito. Así, el modelo describe completamente

aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un

apropiado nivel de detalle. (Rueda, 2006)

Un diagrama es una representación gráfica de una colección de elementos de modelado,

a menudo dibujada como un grafo con vértices conectados por arcos. Un proceso de

desarrollo de una solución de tecnología de información debe ofrecer un conjunto de

modelos que permitan expresar el producto desde cada una de las perspectivas de

interés. Es aquí donde se hace evidente la importancia de UML en este contexto.

El código fuente del sistema es el modelo más detallado del sistema, y además es

ejecutable. Sin embargo, se requieren otros modelos.

Según Rueda, varios modelos aportan diferentes vistas de un sistema los cuales nos

ayudan a comprenderlo desde varios frentes. Así, UML recomienda la utilización 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 continuación:

�

�

Fig. 9 Partes de un Modelo UML

2.7.2.1. Diagrama de Casos de Uso

Modela la funcionalidad del sistema agrupándola 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 características comunes) que

componen el sistema y cómo 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. También se pueden utilizar

caminos verticales para mostrar los responsables de cada actividad.

• Diagramas de Interacción: Estos diagramas a su vez se dividen en dos tipos de

diagramas, según la interacción que enfatizan:

� Diagrama de Secuencia: enfatiza la interacción entre los objetos y los

mensajes que intercambian entre sí junto con el orden temporal de los

mismos.

� Diagrama de Colaboración: igualmente, muestra la interacción entre los

objetos resaltando la organización estructural de los objetos en lugar del

orden de los mensajes intercambiados.

2.7.2.5. Diagramas de implementación

Estos se subdividen en dos tipos de diagramas:

• Diagrama de Componentes: Muestra la organización y las dependencias entre un

conjunto de componentes.

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

y su distribución en el mismo.

La metodología de modelado UML, por ser estándar, es utilizada por la metodología para

desarrollo de soluciones de tecnologías de información Rational Unified Process (RUP),

de la cual se hablará brevemente a continuación.

2.8. PROCESO UNIFICADO RATIONAL (RUP)

Las siglas RUP en inglés significan Rational Unified Process (Proceso Unificado de

Rational). “RUP es un producto del proceso de ingeniería de software que proporciona un

enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización

de desarrollo de software” (http://www.liderdeproyecto.com/metodologias/index.html,

consultado el 11-06-2009). La meta de RUP es asegurar la producción 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

lógicamente por la naturaleza.

La primera dimensión representa el aspecto dinámico del proceso y se expresa en

términos de fases, de iteraciones, y la finalización de las fases. La segunda dimensión

representa el aspecto estático del proceso: cómo se describe en términos de

componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los

artefactos, y los roles. Estas dimensiones se pueden ver representadas gráficamente en la

figura N° 10.

�

Fig. 10 Proceso Unificado Rational

En la figura precedente se puede observar como varía 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 más tiempo en requerimientos, y en las últimas iteraciones se pasa

más tiempo en poner en práctica la realización del proyecto en si.

Se puede hacer mención de las tres características esenciales que definen al RUP:

�

• Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilización 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

implementación de las fases y disciplinas del RUP. Un Caso de Uso es una

secuencia de pasos a seguir para la realización de un fin o propósito, y se relaciona

directamente con los requerimientos, ya que un Caso de Uso es la secuencia de

pasos que conlleva la realización e implementación 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 implementación del proyecto a realizar

en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteración

y así poder ir completando todo el proyecto iteración por iteración, con lo cual se

tienen varias ventajas, entre ellas se puede mencionar la de tener pequeños

avances del proyectos que son entregables al cliente el cual puede probar mientras

se esta desarrollando otra iteración 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 organización o estructura de sus partes más relevantes. Una

arquitectura ejecutable es una implementación 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. Dimensión 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. Preparación

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

• Se define una arquitectura básica.

• Se planifica el proyecto considerando recursos disponibles.

2.8.1.3. Construcción

• El producto se desarrolla a través de iteraciones donde cada iteración involucra

tareas de análisis, diseño e implementación.

• Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí

refinada de manera incremental conforme se construye.

• Gran parte del trabajo es programación y pruebas.

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

• Esta fase proporciona un producto construido junto con la documentación.

2.8.1.4. Transición

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

• Se incluyen tareas de mercadeo, empaquetado atractivo, instalación, configuración,

entrenamiento, soporte, mantenimiento, etc.

• Los manuales de usuario y de sistema se completan y refinan con la información

anterior.

• Estas tareas se realizan también en iteraciones.

Todas las fases no son idénticas en términos de tiempo y esfuerzo. Aunque esto varía

considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un

proyecto de tamaño mediano debe anticipar la distribución del esfuerzo como sigue:

�

��

Tabla 2 Esfuerzo vs. Fases RUP �

Inicio Preparación Construcción Transición

Esfuerzo ~5 % 20 % 65 % 10%

Lo cual se puede representar gráficamente como se muestra en la figura 11.

�

Fig. 11 Tiempo y Esfuerzo vs. Fases de RUP

2.8.2. Dimensión 2: Disciplinas

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para

la culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias

y las de apoyo. Las primarias son las necesarias para la realización de un proyecto de TI,

aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:

Modelado del Negocio, Requerimientos, Análisis y Diseño, Implementación, Pruebas,

Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las

primarias y especifican otras características en la realización de un proyecto de TI; entre

estas se tienen: Entorno, Gestión del Proyecto, Gestión de Configuración y Cambios. A

continuación 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 dinámica de

la organización, 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 límites del sistema, y una interfaz de usuario, realizar una estimación del costo y

tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden

los CU, Actores y Relaciones, además utiliza los Diagramas de Estado de cada CU y las

especificaciones suplementarias.

2.8.2.3. Análisis y Diseño

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

implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño

se refiere a refinar el análisis para poder implementar los diagramas de clases de análisis

de cada CU, los diagramas de colaboración de de cada CU, el de clases de diseño de

cada CU, el de secuencia de diseño de CU, el de estados de las clases y el modelo de

despliegue de la arquitectura.

2.8.2.4. Implementación

Esta disciplina tiene como objetivos implementar las clases de diseño 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 Implementación, conjuntamente con los Diagramas de

Componentes para comprender cómo se organizan los componentes y su

interdependencia.

2.8.2.5. Pruebas

Con esta disciplina se pretende verificar la integración de los componentes (prueba de

integración), verificar que todos los requisitos han sido implementados (pruebas del

sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución.

�

��

2.8.2.6. Despliegue

Durante el despliegue se tienen como objetivos asegurar que el producto está preparado

para la entrega y recepción por parte del cliente. En esta disciplina se realizan las

actividades de probar la nueva solución de TI en su entorno final (Prueba Beta),

empaquetarlo, distribuirlo e instalarlo, así como la tarea de adiestrar al usuario.

2.8.2.7. Gestión y Configuración de Cambios

La gestión y configuración de los cambios es esencial para controlar el número 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 había arreglado etc., y

aseguran que los resultados de los artefactos no entren en conflicto debido a alguna de

las siguientes situaciones:

• Actualización simultánea: Es la actualización de algo elaborado con anterioridad,

sin saber que alguien más lo está actualizando.

• Notificación limitada: Al realizar alguna modificación, no se deja información sobre

lo que se hizo, por lo tanto no se sabe quién, cómo, y cuándo se hizo.

• Versiones múltiples: No saber con exactitud, cual es la última versión, lo que

ocasiona que no se tenga un orden sobre qué modificaciones se han realizado a las

diversas versiones.

2.8.2.8. Gestión del Proyecto

Su función 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 gestión del

proyecto se logra una mejoría en el logro de una culminación exitosa del mismo. En

resumen su propósito consiste en proveer pautas para:

• Administrar proyectos.

�

��

• Planear, dirigir personal, ejecutar acciones de supervisión 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 propósito es proveer a la organización que ejecutará el proyecto, un ambiente en el

cual basarse, provee procesos y herramientas para poder desarrollar la solución.

�

��

�

3. CAPÍTULO 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 organización de lo general

a lo específico de manera jerárquica, se presentará en primer lugar a Petróleos de

Venezuela (PDVSA), sus características y razón de ser, posteriormente se reseñará la

organización Automatización, Informática y Telecomunicaciones (AIT), y por último se

describirán las funciones de la Organización Desarrollo e Implantación de Soluciones

dónde será propuesta la utilización de la metodología que se desarrollará en este trabajo.

3.1. PETRÓLEOS DE VENEZUELA (PDVSA)

3.1.1. Descripción Ampliada de la Empresa

El 1° de enero de 1976, exactamente al primer segundo después de las doce de la noche,

nació Petróleos de Venezuela S.A. como la empresa encargada de asumir las funciones

de planificación, coordinación y supervisión de la industria petrolera nacional al concluir el

proceso de reversión de las concesiones de hidrocarburos a las compañías extranjeras

que operaban en territorio venezolano. La partida de nacimiento de la principal industria

del país quedó plasmada en el decreto presidencial número 1.123 del 30 de agosto de

1975. Su primer presidente fue el general Rafael Alfonzo Ravard.

Durante el primer año de operación, PDVSA inició sus acciones con 14 filiales, de las

cuales posteriormente quedarían operando solo tres: Lagoven, Maraven y Corpoven, que

absorbieron las actividades de las concesionarias que estaban en Venezuela. Para aquel

año, se mantiene la producción de crudo en 2,3 millones de barriles diarios. Las

inversiones iniciales se sitúan en un principio en 1.200 millones de bolívares. Ya en 1978,

las inversiones de capital se habían cuadruplicado y se ubicaban en 5.000 millones de

bolívares.

�

�

Dentro de esta fase, inicia acciones en 1976, el Instituto Tecnológico Venezolano del

Petróleo (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 años después se crea Petroquímica de Venezuela S.A. (Pequiven),

dirigida a organizar el negocio de la producción petroquímica.

Luego de cinco años de puesta en marcha del decreto que creó a Petróleos de Venezuela,

PDVSA y sus filiales logran avanzar en un proceso de consolidación en lo que respecta al

manejo del negocio petrolero. Así, de esta manera, se consolidó satisfactoriamente la

transición y adaptación 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 país; Corpoven despliega su área de influencia en el centro de la nación, mientras

que Maraven se sitúa en la región oriental.

Asimismo, la compañía estatal enfoca parte de sus esfuerzos a la Faja del Orinoco, la cual

contiene importantes reservas de crudo pesado y extra-pesado. Para su explotación, 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

estratégica de la faja queda plasmada en sus números: las reservas probadas están por el

orden de los 60.000 y 200.000 millones de barriles. Para tener una comparación que

permita apreciar este dato, es importante destacar que desde 1917 hasta 1994, se

produjeron en el país 46.421 millones de barriles de crudo de todo tipo.

El petróleo pesado es la base para la producción de Orimulsión®, combustible destinado

principalmente a las plantas generadoras de electricidad, como un sustituto del carbón por

sus características de baja contaminación ambiental.

PDVSA logra ser considerada como una empresa confiable en el suministro de grandes

volúmenes de petróleo a nivel mundial. En esta fase, Petróleos de Venezuela se consolida

como una las principales compañías petroleras multinacionales.

A mediados de los años 80, la principal empresa del país inicia una expansión tanto a

nivel nacional como mundial, con la compra y participación en diversas refinerías ubicadas

en Europa, Estados Unidos y el Caribe.

�

��

En este sentido, establece operaciones en las refinerías de la Ruhr Oel, en Alemania;

Nynas, en Suecia y Bélgica e Isla, en Curazao.

Por otra parte, el 15 de septiembre de 1986, Petróleos de Venezuela adquirió a la

empresa Citgo, en Tulsa, Estados Unidos, punta de lanza de la estrategia de

comercialización de hidrocarburos en Norteamérica, con más de mil estaciones de servicio

y casi el 20% de las ventas de gasolina en suelo estadounidense.

Para la década de los noventa, PDVSA inicia un proceso de asociaciones estratégicas

destinado a garantizar el inicio y la continuidad en importantes proyectos, como por

ejemplo el Mariscal Sucre, destinado a la exploración y explotación de los recursos de gas

natural licuado (GNL) que se encuentran ubicados en la península de Paria y al este de la

isla de Margarita. Están 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 compañías

extranjeras.

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

exploratorias: La Ceiba (Trujillo, Mérida, Zulia), Golfo de Paria Este, Golfo de Paria Oeste

(Sucre), Guarapiche (Monagas), Guanare (Portuguesa), San Carlos (Cojedes), El

Sombrero (Guárico), Catatumbo (Zulia), Punta Pescador y Delta Centro (Delta Amacuro).

Intervienen Mobil, Enron, Amoco, Elf y Conoco, entre otras.

La faja del Orinoco también entra dentro de una estrategia de asociaciones estratégicas

para producir crudos, mientras que se crean empresas mixtas en el área de la

Orimulsión®.

Entre 1993 y 1996 se realizaron las tres primeras rondas de convenios operativos lo que

produjo para el país una inversión inicial superior a los dos mil millones de dólares y una

producción adicional de crudo estimada en unos 260.000 barriles diarios.

El 1° de enero de 1998, Petróleos de Venezuela integraba en su estructura operativa y

administrativa a las tres filiales que durante más de 20 años habían compartido las

�

��

operaciones. Se establecía de esta manera una empresa con un perfil corporativo

unificado, dirigido a generar altos estándares de calidad y beneficios en lo que respecta a

los procesos que están presentes dentro de la industria de los hidrocarburos.

En este sentido, se creaban tres divisiones funcionales PDVSA Exploración y Producción;

PDVSA Manufactura y Mercadeo, y PDVSA Servicios.

Exploración y Producción se encarga de desarrollar las actividades de búsqueda de

reservas y explotación de petróleo y gas natural, así como los negocios del carbón y la

Orimulsión®, los convenios operativos para la reactivación de los campos petroleros, la

participación de la industria en los contratos de exploración a riesgo y producción en áreas

nuevas bajo el esquema de ganancias compartidas y en las asociaciones estratégicas

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

refinación ubicados en el país, incluso los de la refinería Isla, en Curazao. Igualmente,

comprende la comercialización internacional de hidrocarburos, de productos en el

mercado industrial interno y el mercadeo al detal.

A partir de 1999, PDVSA establece en asociación con la Fuerza Armada Nacional y otras

instituciones del Estado, una serie de programas dirigidos a paliar la emergencia social

que vivía el país.

Surge así el Plan Bolívar con el apoyo de Petróleos de Venezuela, destinado a contribuir a

mejorar los indicadores sociales en lo que respecta a la salud, mediante la realización de

jornadas cívicas de atención integral dirigidas a la población de menores recursos;

educación, enfocado al mantenimiento y reparación de la planta escolar; infraestructura,

con la creación y puesta al día de obras de vialidad, vivienda y de interés para el pueblo,

como ambulatorios; alimentación, para llegar a aquellos venezolanos que necesitan

productos de primera necesidad de calidad y a precios realmente económicos.

Petróleos 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 económica y social de PDVSA y

del país.

Este principio rige la totalidad de las operaciones que se enmarcan dentro de la dinámica

petrolera, ya que PDVSA es uno de los principales responsables en el desarrollo nacional

y por consecuencia de la seguridad de la nación, y de todo lo que ello implica, a través del

beneficio generado con la comercialización 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 política energética de Venezuela hasta el año 2030 están trazadas en

el Plan Siembra Petrolera, que comprende seis grandes proyectos de desarrollo y consta

de dos etapas: una a ejecutarse entre el período 2005-2012, y la otra, a llevarse adelante

en la etapa comprendida entre 2012 y 2030.

Para el primer período del Plan Siembra Petrolera, se han estimado inversiones por el

orden de los 56.000 millones de dólares, 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 cuantificación y certificación de las reservas que posee Venezuela en la

Faja Petrolífera del Orinoco, para lo cual se hará un estudio integrado de geología.

Venezuela tiene, sin contabilizar la Faja, 77 mil millones de barriles de petróleo, 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 Petrolífera del Orinoco. Se han seleccionado 27

bloques que se desarrollarán con esfuerzo propio y empresas. Por la ubicación de este

�

��

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

desconcentración del país. Se estima la realización de desarrollos de servicios y viviendas

para garantizar una explotación petrolera adecuada.

3.1.2.3. Proyecto Delta-Caribe

El gas se incorporará a la oferta energética del país. Este proyecto persigue el desarrollo

del Gas Costa Afuera en las áreas de Plataforma Deltana, en la fachada atlántica

venezolana; en las aguas ubicadas al norte del estado Sucre, al oriente de Venezuela; y

en las inmediaciones de la Península de Paraguaná, al nor-occidente del país.

3.1.2.4. Refinación

Aumentar la capacidad de refinación en Venezuela es una de las puntas de lanza del plan

estratégico de PDVSA. El Plan Siembra Petrolera contempla la creación de nuevos

centros refinadores: Cabruta (con capacidad de 400.000 barriles diarios de crudos

extrapesados), Batalla de Santa Inés (50.000 barriles diarios) y Caripito (50.000 barriles

diarios destinados a la producción de Asfalto). Con estas tres nuevas refinerías y la

potenciación 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 habilitarán más llenaderos y poliductos para garantizar a todo el territorio nacional el

suministro de combustibles.

3.1.2.6. Integración

El petróleo es la herramienta de integración de los pueblos del continente. Venezuela

suple de forma directa volúmenes de crudo y productos al Caribe a través de Petrocaribe,

que también prevé la ampliación de la capacidad de refinación en esa zona. Además se

suscribió Petrosur, con lo que avanza la planificación de proyectos.

�

��

3.2. AUTOMATIZACIÓN, INFORMÁTICA Y TELECOMUNICACIONES (AIT)

3.2.1. Breve Histórico

El servicio de la plataforma de Tecnología de Información (TI) de PDVSA estaba a cargo

de la empresa Informática y Tecnología S.A. (INTESA) desde su creación 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 político-social acaecido a finales del año 2002 y principios del 2003,

y aunado a la finalización programada del contrato, cesó la prestación de sus servicios a

PDVSA.

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

Tecnología de Información 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 Automatización. Surgió entonces la Gerencia de Automatización, Informática

y Telecomunicaciones (AIT).

En el año 2003 se definió en las en las diferentes regiones geográficas de PDVSA, un

Modelo de Procesos para AIT con la visión de orientar la administración, gestión y

ejecución de servicios y productos, enfocado a la satisfacción de los usuarios. En función

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 debía replicarse en cada región.

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

control. Tiene como objetivo proporcionar una representación gráfica de todos los

procesos que son ejecutados dentro de AIT para proveer las soluciones y servicios

desprendidos de su misión dentro de PDVSA. Adicionalmente el modelo proporciona la

descripción general de los objetivos y alcances de cada uno de esos procesos y de cómo

se relacionan entre sí durante la operación.

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. Visión

“Soberanía plena en soluciones AIT para el sector energético aportando valor social”

(PDVSA, 2008).

3.2.3. Misión

“Somos la Organización que rige, provee y mantiene los servicios y soluciones

integrales de tecnologías de automatización, información y comunicaciones de la

corporación; contribuimos a mantener su continuidad operativa y a ejecutar sus

planes; innovamos y actuamos como agentes de transformación en PDVSA y en

la sociedad venezolana con corresponsabilidad social, económica y ambiental;

potenciamos un ecosistema tecnológico que impulsa los poderes creadores del

pueblo, el conocimiento libre, el desarrollo endógeno sustentable y la economía

social productiva para lograr la soberanía tecnológica; alineados con la CRBV y

en coordinación con nuestros organismos rectores” (Planificación y Arquitectura,

2008).

3.2.4. Objetivos Estratégicos �

Según Planificación y Arquitectura los Objetivos Estratégicos 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 rendición de cuentas transparente al pueblo

venezolano.

�

��

• Optimizar los esquemas de mantenimiento y prestación de servicios AIT para

asegurar la continuidad de las operaciones de la Corporación a escala mundial en

condiciones normales y de contingencia.

• Proveer soluciones tecnológicas para habilitar el acercamiento del estado al

ciudadano mediante una red coordinada de instituciones.

• Consolidar el Ecosistema Tecnológico que provee productos y servicios a la

Corporación, profundizando el desarrollo endógeno, el conocimiento libre y la

economía social, orientados al logro de la Plena Soberanía Tecnológica.

• Implantar el Distrito Social Tecnológico AIT para la generación de tecnologías AIT

dirigidas a la industria petrolera y el sector energético.

• Concretar la Transformación Organizacional de AIT a fin de ser proactivos,

eficientes, efectivos e innovadores en la incorporación de tecnologías de AIT y la

provisión de las soluciones y servicios que nos sean demandados.

• Fortalecer la relación con los Órganos Rectores en materia de Tecnología de AIT

para asegurar la alineación e integración con el Estado.

• Establecer el plan estratégico de RRHH que permita la captación y desarrollo del

personal según las competencias y necesidades de la función, apalancando los

requerimientos del Plan Siembra Petrolera y otros Organismos del Estado;

enfatizando la seguridad y protección del ambiente como conducta cotidiana de

trabajo.

• Establecer sistemas corporativos de rendición de cuenta para soportar la gestión

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

emanadas de la Corporación

• Establecer un Plan Comunicacional efectivo para la divulgación de la información

concerniente a todos los aspectos de funcionamiento de AIT a la Corporación

• Convertir la Organización de AIT en un nuevo modelo basado en los valores del

nuevo ciudadano para impulsar el desarrollo de la Corporación y el país y una

nueva relación Estado - Sociedad.

• Adoptar la seguridad y protección del ambiente como conducta cotidiana de trabajo

para garantizar los derechos ambientales de la población.

�

�

�

�

�

�

��

3.3. DESARROLLO E IMPLANTACIÓN DE SOLUCIONES (DIS)

Desarrollo e Implantación de Solución es la organización donde específicamente se

planteó la implantación de la nueva Metodología para la Gestión de Proyectos de TI, que

fue la propuesta en el presente Trabajo Especial de Grado.

3.3.1. Objetivo

“Definir e implantar soluciones integrales de Automatización, Informática y

Telecomunicaciones AIT eficientes y eficaces en términos de costo y oportunidad para

satisfacer necesidades de PDVSA y la Nación, que apalanquen las metas y objetivos de

PDVSA cumpliendo con lineamientos, estándares y normas nacionales e internacionales

adoptadas por la Corporación” (Gestión y Mejoramiento de Procesos, 2007).

3.3.2. Alcance

La organización Gestión y Mejoramiento de Procesos definió que las funciones de DIS se

enmarcan dentro del siguiente alcance:

• Conceptualizar la solución: Conformación del equipo de trabajo, formalización de

objetivos, roles y responsabilidades, preparación del plan para definir la solución, y

selección de la mejor opción.

• Formulación del proyecto. Estimaciones clase II de costos del proyecto. Manejo del

riesgo.

• La definición de la solución: Análisis de riesgos, desarrollo en detalle del alcance y

los planes de ejecución de la opción seleccionada, planificación operacional en

costo, calidad y tiempo óptimo, establecimiento de guías para el control de la

solución, y preparación del paquete para la autorización de la solución.

• El desarrollo e implantación de la solución: Materialización del plan de ejecución de

la solución hasta completar las instalaciones.

• La operación: Puesta en marcha de las instalaciones por parte de custodios o

dueños, preparación y pruebas para el arranque, pruebas de capacidad, entrega y

aceptación de instalaciones y los informes finales.

• El control y seguimiento de las soluciones requeridas y aprobadas.

�

��

• Abarca soluciones tecnológicas dirigidas a satisfacer necesidades de PDVSA y / o

la Nación.

3.3.3. Premisas

• El proceso de Gestión de Necesidades y Oportunidades (GNO) determina cuándo

la oportunidad será desarrollada e implantada por el proceso de Desarrollo e

Implantación de Soluciones (DIS).

• Se aplica en este proceso las normativas externas e internas de Automatización,

Informática y Telecomunicaciones (AIT) y PDVSA.

• Solo serán proyectos para la responsabilidad del proceso DIS, aquellos que

impliquen el diseño y/o implantación de una solución tecnológica de AIT.

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

� Diseñar una solución tecnológica de AIT

� Desarrollar e implantar una solución tecnológica de AIT.

� Evaluar, seleccionar, e implantar una solución tecnológica de AIT.

• El diseño e implantación de soluciones se manejarán a través del enfoque de

proyectos.

• Se usarán las normas de la Guía de Gerencia para Proyectos de Inversión de

Capital (GGPIC) como marco de referencia para el diseño e implantación de

soluciones tecnológicas de AIT.

• El proceso DIS debe aplicar las normativas establecidas por la Corporación y la

Nación, para los consiguientes propósitos, en la formulación y ejecución de las

soluciones tecnológicas de AIT

3.3.4. Diagrama Macro Interfuncional del Proceso

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

�

�

�

�

DSD1 y Propuesta de Solución Tecnológica aprobado

Adecuación de Plataforma

Procura de Activos

Procura de Bienes y Servicios

Respuesta de Solicitud de Aprobación del DSD2



Proyecto Diferido

Cancelado

Solicitud de Almacen. y Respaldo

Solicitud de Adecuación de

Plataforma

Solución Tecnológica

Necesidades de

Formación

Necesidades Monitoreo

de Solución Implantada

Requerimiento de Actualización

Catálogo de Servicios

Reporte de Solicitudes Atendidas

DSD4

Solicitud Procura de

Activos

Solicitud de Contrato

Informe de Cierre del Proyecto

Requerimiento Act.

Elem. Config.

Requerimiento de Control de

Cambio

Solicitud Procura de Bienes y Servicios

DSD3

DSD2

GNO

PBS

MAP

AYR

ARF

GA

Conceptua lizar

Definir

Implantar Operar

Plan de Transferencia de Nueva Infraestructura

�

Fig. 13 Diagrama Macro Interfuncional del Proceso DIS �

�

��

�

4. CAPÍTULO IV

EXAMEN DE LA SITUACIÓN

En el presente capítulo se presenta el procedimiento seguido para realizar el examen de la

situación actual de la gestión de proyectos en la Gerencia de Desarrollo e Implantación de

Soluciones, la cual se realiza siguiendo los lineamientos de las Guías de Gerencia para

Proyectos de Inversión de Capital. El examen de la situación actual se presenta a través

de su objetivo, planificación, ejecución, resultados obtenidos y la conclusión sobre las

áreas a atender.

4.1. OBJETIVO DEL PROCESO

El objetivo del proceso es realizar una examen de la aplicabilidad de las Guías de

Gerencia para Proyectos de Inversión de Capital (GGPIC), determinando su aplicabilidad

en la gestión de proyectos de Tecnología de Información (TI), para que, a partir de este

análisis, se permita hacer una propuesta para incorporar los elementos necesarios de

metodologías propias de gestión de proyectos de TI, como los son RUP/UML, generando

una nueva metodología especialmente diseñada para la gerencia de Desarrollo e

Implantación de Soluciones, acorde a los lineamientos de la corporación así como

también, acorde a las necesidades del tipo de proyectos con los que trabaja la

organización.

4.2. PLANIFICACIÓN DEL PROCESO

Para realizar el examen de la situación 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 prácticamente toda la actividad es aplicable, Medio, el cual refiere

que una porción importante de la actividad es aplicable, y Bajo, el cual indica que

solo una pequeña 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. EJECUCIÓN DEL EXAMEN DE LA SITUACIÓN

Para la ejecución del proceso de examen se siguieron los pasos descritos en la

planificación, dichos pasos se completaron en la elaboración 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

aplicación en proyectos de TI

FASE OBJETIVO ACTIVIDAD Alto Medio Bajo Comentarios ESTABLECER OBJETIVOS Y PROPÓSITOS X VERIFICAR ALINEACIÓN CON OBJ. ESTRATÉGICOS X

DESARROLLO PRELIMINAR Elaborar alcance X Elaborar estimado de costos clase V X Plan de ejecución clase V X

VIS

UA

LIZA

R

Evaluar factibilidad X

Desde la perspectiva de las GGPIC, la factibilidad se enfoca básicamente en el aspecto de rentabilidad del proyecto, sin embargo, los proyectos de TI en PDVSA son en su mayoría calificados como de gastos, razón por la cual el estudio de factibilidad preliminar está dirigido casi siempre a las áreas técnica y operacional.

ORGANIZACIÓN PARA FASE DE PLANIFICACIÓN

CO

NC

EP

- TU

ALI

ZAR

Conformar equipo de trabajo

X

�

�

Formalizar objetivos, roles y responsabilidades X

Preparar plan para conceptualizar y definir X

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.

SELECCIONAR OPCIONES PREFERIDAS / FONDOS

Evaluar la tecnología X

Evaluar el sitio X Aplica para algunos proyectos de telecomunicaciones

Preparar el alcance conceptual y estimados clase IV X

Evaluar rentabilidad de opciones X

Mas que rentabilidad de la opción, por considerarse que la mayoría de los proyectos de TI en PDVSA son calificados como de gastos, lo que se aplica es una evaluación de costos.

Solicitud de fondos X

DESARROLLAR PAQUETE DE DEFINICIÓN

Analizar los riesgos X

Precisar alcance y elaborar el diseño básico X

Desarrollar detalle del Plan de Ejecución X

Preparar estimados clase II X

Evaluar grado de definición del proyecto X

Establecer guías para el control del proyecto X

Desarrollar plan de aseguramiento tecnologico X

ESTABLECER PROCESO DE CONTRATACIÓN

Elaborar/validar estrategia de ejecución/contratación X

Desarrollar documento de solicitud de ofertas DSO X

PREPARAR PAQUETE PARA AUTORIZACIÓN DEL PROYECTO

DE

FIN

IR

Revisar evaluación para solicitud de fondos

X

Es medio porque las GGPIC fueron diseñadas 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 mayoría de gastos, solo se introducen los estimados en las solicitudes de aprobación de presupuesto, a menos que tenga algún rubro de inversión, que igual se somete a aprobación, pero

�

��

nunca por financiamiento externo.

Preparar documentación para evaluación X

Esta actividad aplica medianamente, puesto que para proyectos de TI, se requiere otra documentación que no se contempla en las GGPIC

CONTRATACIÓN

Aprobar estrategia y lista de empresas X

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

Proceso de selección de contratistas X


Revisión y firma del contrato X


Administración del contrato X


EJECUCIÓN

Ingeniería X

En el caso de proyectos de TI la ingeniería de detalle debe obtenerse en la fase de definición

Procura de materiales y equipos X

Pocos proyectos de TI incluyen la compra de equipos puesto que esta función la asume principalemente la gerencia de Matenimiento de Operaciones de AIT

Materialización del plan de aseguramiento de tecnologías x

IMP

LAN

TAR

Construcción X

OPERACIÓN INICIAL

Preparación y pruebas para el arranque X

Arranque X

PRUEBAS DE GARANTÍA

Pruebas de capacidad X

Primer período de aceptación X

ACEPTACIÓN DE INSTALACIONES

OP

ER

AR

Entrega de instalaciones X

�

��

ELABORACIÓN DE INFORMES FINALES

Cierre del proyecto X

Primer informe técnico-económico y divulgación X

Es medio porque si se pueden especificar los resultados técnicos, pero los económicos según 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.

EVALUACIÓN CONTÍNUA x

Este objetivo es asumido en AIT por la organicación de Gestión del Servicio (GDS)

% Grado de aplicabilidad 66 22 12 Alto y medio superior al 80 %

4.4. RESULTADOS DEL EXAMEN DE LA SITUACIÓN

De acuerdo al análisis de aplicabilidad en proyectos de Tecnologías de Información

realizado a la metodología actualmente utilizada en la gerencia de Desarrollo e

Implantación de Soluciones, las Guías de Gerencia para Proyectos de Inversión de

Capital, se obtuvo como resultado que dichas Guías son aplicables en más 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 gestión de

este tipo de proyectos, razón por la cual entra en el estudio el aporte que en este sentido

pueden ofrecer metodologías como RUP y UML, las cuales fueron consideradas en la

elaboración de la metodología propuesta. Estos aportes se describirán en detalle en el

próximo capítulo.

4.5. CONCLUSIONES DEL EXAMEN DE LA SITUACIÓN

Como resultado del análisis realizado durante el examen de la situación donde se pudo

apreciar el grado de aplicabilidad de las Guías de Gerencia para Proyectos de Inversión de

Capital en proyectos de TI, la autora consideró necesario el diseño de una metodología,

que usando como base las GGPIC fuera complementada con las actividades propias de

�

�

proyectos de Tecnología de Información, lo cual redundaría en una mejora significativa en

la gestión de proyectos en la gerencia de DIS.

Algunas premisas que se tomaron en cuenta para la elaboración de la metodología fueron

las siguientes:

• La Metodología de Gestión de Proyectos de Tecnologías de Información en la

Gerencia DIS que se propuso, presenta una guía paso a paso que cualquier líder de

proyecto podrá seguir de manera sencilla para llevar a cabo su ejecución.

• La Metodología propuesta no pretende dar un detalle magistral del cómo deben

hacerse cada una de las actividades, pues, en cada caso, existe material

bibliográfico donde se puede ahondar en la documentación para cumplir con la

actividad mencionada si se requiere, incluso Internet puede proporcionar mayor

detalle si se encuentran dudas en el seguimiento de la guía.

• Finalmente, una vez diseñada la metodología, la misma debe ser difundida entre el

personal encargado de manejar proyectos de TI, para garantizar el uso de un

mismo lenguaje, estándares, documentación y resultados esperados, lo cual

facilitará, no solo la gestión de proyectos, sino el pase de testigo en casos de

movimientos de personal y cambios de responsabilidades.

�

��

�

5. CAPÍTULO V

PROPUESTA DE METODOLOGÍA DE GESTIÓN DE PROYECTOS DE

TECNOLOGÍA DE INFORMACIÓN EN LA GERENCIA DIS

En este capítulo se presenta el proceso realizado para elaborar la propuesta de diseño de

una Metodología de Gestión de Proyectos de Tecnologías de Información en La Gerencia

Desarrollo e Implantación de Soluciones, de acuerdo a las necesidades detectadas en el

capítulo anterior. Se expondrán la justificación de la propuesta, los objetivos, la

planificación del proceso para realizar la propuesta, y, finalmente se concluirá con la

propuesta como tal.

5.1. JUSTIFICACIÓN DE LA PROPUESTA

“La Gerencia Desarrollo e Implantación de Soluciones (DIS) tiene como objetivo

definir e implantar soluciones integrales de AIT eficientes y eficaces en términos

de costo y oportunidad para satisfacer necesidades de PDVSA y la Nación, que

apalanquen las metas y objetivos de PDVSA cumpliendo con lineamientos,

estándares y normas nacionales e internacionales adoptadas por la

Corporación” (GMP, 2007).

El lineamiento corporativo indica que AIT debe usar para la Gestión de Proyectos la Guía

de Gerencia para Proyectos de Inversión de Capital (GGPIC), esta guía fue diseñada 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 Ingeniería

y Construcción.

La experiencia en la gestión 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 técnicas

específicas, necesarias, para la ejecución de este tipo de proyectos.

En ese contexto, surge la necesidad de contar con una metodología de Gestión de

Proyectos de TI, basada en las GGPIC, que son el estándar de PDVSA, validando su

aplicabilidad y adaptándola con los complementos necesarios de manera de que se

genere una metodología que realmente sirva de apoyo a la gerencia DIS en la gestión de

sus proyectos.

5.2. OBJETIVO DE LA PROPUESTA

La propuesta, que consiste en el diseño de de una metodología de Gestión de Proyectos

de Tecnología de Información basada en las Guías de Gerencia para Proyectos de

Inversión de Capital (GGPIC) de PDVSA, tiene como objetivo apoyar la gestión de

proyectos de TI de la Gerencia de Desarrollo e Implantación de Soluciones, mejorando su

eficiencia a través del logro de los objetivos establecidos en los proyectos en cuanto a

tiempo, costo y calidad, parámetros conocidos como la triple restricción.

Con esta propuesta se pretende como propósitos fundamentales:

• Proveer a los líderes de proyectos de una guía paso a paso para la gestión de

proyectos, la cual facilitará su trabajo, apuntando con mayor probabilidad al logro de

los objetivos de los proyectos asignados.

• Manejar un lenguaje común en la Gerencia DIS sobre actividades, productos y

documentación que deben generarse durante la gestión de un proyecto de TI ya

que la metodología los especifica.

• Reducir la curva de aprendizaje de los nuevos líderes de proyecto.

5.3. PROCESO PARA REALIZAR LA PROPUESTA

Para llevar a cabo la propuesta, el primer paso fue el examen de la situación, llevado a

cabo en el capítulo anterior, de allí se obtuvo que las GGPIC son aplicables en más de un

80% a proyectos de TI.

�

��

Como siguiente paso y, luego de haber estudiado en el capítulo II la metodología base del

trabajo GGPIC, en conjunto con la metodología a utilizar para realizar el complemento

para generar una nueva metodología más adecuada para proyectos de TI, RUP; se hizo

un análisis de cómo se correlacionan las fases del ciclo de vida de un proyecto entre

ambas metodologías. Esta correlación se puede apreciar en la siguiente figura:

�

Fig. 14 Fases GGPIC Vs. Fases RUP

De acuerdo a lo estudiado la diferencia más notable se encuentra en que la metodología

RUP tiene cuatro fases y las GGPIC cinco, sin embargo, las actividades de la fase de

preparación, se pueden acoplar perfectamente dentro de las fases conceptualizar y definir

de las GGPIC.

Por último, para elaborar la propuesta se procederá con su ejecución, la cual consistirá en

detallar las actividades que corresponderán a cada fase que, según el propósito de este

estudio, deben respetar el lineamiento corporativo de regirse por las GGPIC. En la

propuesta, se incorporan las actividades técnicas propias de proyectos de TI, logrando de

esta manera, el objetivo que contar con una metodología mas apropiada al tipo de

proyectos que se gestionan en la Gerencia de Desarrollo e Implantación de Soluciones

(DIS).

5.4. LA PROPUESTA: METODOLOGÍA DE GESTIÓN DE PROYECTOS DE

TECNOLOGÍA DE INFORMACIÓN

En este apartado se describirá de manera detallada en qué consiste la Metodología de

Gestión de Proyectos de Tecnología de Información basada en las Guías de Gerencia

para Proyectos de Inversión de Capital (GGPIC) diseñada para apoyar la gestión de los

proyectos en la Gerencia de Desarrollo e implantación de Soluciones (DIS) de PDVSA.

�

�

Se entenderá en qué consiste cada fase del ciclo de vida, y cada una de las actividades

que deberán ser seguidas para la ejecución de un proyecto.

A lo largo de la metodología 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

precisión 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 Corporación, pero son generalmente el producto de los análisis del ambiente

externo e interno a ella, o del análisis F.O.D.A (Fortalezas, Oportunidades, Debilidades,

Amenazas) que se realiza como parte de los ciclos de planificación. Estos análisis se

efectúan en equipo con la participación de todas las organizaciones de la Corporación y

bajo la responsabilidad integradora de las unidades de Planificación 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 líder funcional; el comité de usuarios seleccionado y su líder

deberán participar y formarán parte del equipo durante todo el ciclo de vida del proyecto.

5.4.1.2. Elaborar Plantilla de Datos Básicos

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 visualización se puede identificar con anticipación que miembros

de otros equipos de AIT estarán participando, como por ejemplo el arquitecto de

soluciones, el analista de seguridad lógica, 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 documentación 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 prácticamente un sub-proyecto, el cual debe llevar un cronograma

independiente, cuyo tiempo total será el tiempo de esta actividad en la planificación de

todo el proyecto.

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

mayor información.

5.4.1.5. Desarrollo del Documento de Soporte de Decisión 1 (DSD1)

El DSD1 es el Documento de soporte de Decisión que se genera al ejecutar todas las

actividades de la fase Visualización y que permitirá a él o los autorizadores establecidos

aprobar si el proyecto continúa o no en la siguiente fase. Para efectos de esta metodología

la elaboración de los diversos DSD se propone como una macroactividad dentro de la cual

se ejecutan la mayoría 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 obtención

del producto final de la fase para solicitar la aprobación de continuar con la siguiente.

Gráficamente se puede observar la función de los DSD en la siguiente figura:

�

��

�

Fig. 15 El Proceso de la Toma de Decisión

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 función de la importancia potencial que

representa para el negocio.

Esencialmente en esta actividad se evalúa la problemática u oportunidad de mejora y se

determinan necesidades de alto nivel. Se responderán y documentarán las respuestas a

preguntas básicas: ¿qué? y ¿para qué? ¿dónde?

La ocurrencia de esta actividad es constante en el tiempo ya que los requerimientos se

reciben de esa forma y la exploración 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, evolución del

problema en el tiempo, descripción de la situación 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 descripción 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

tecnológica.

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

que causan.

Necesidades: es la carencia que manifiesta un usuario u organización 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 Propósito / Objetivos y Metas del Proyecto

Indicar cuál es la finalidad del proyecto, identificando claramente el objetivo de la ejecución

del mismo. En este punto se debe ser cuidadoso, puesto que en oportunidades se puede

confundir que la implantación o desarrollo de una nueva tecnología 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 través de la implantación de una determinada tecnología.

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 visualización.

�

�

5.4.1.5.1.6. Definir Situación Actual

Para definir la situación 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 cuál es la expectativa del

usuario al abordar el proyecto.

Luego de que los objetivos y propósitos del proyecto han sido establecidos, y los grupos

de planificación 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 ejecución. Estos estimados se utilizarán en el análisis para

confirmar la factibilidad económica del proyecto y la conveniencia de proseguir con su

desarrollo.

5.4.1.5.1.8. Elaborar Catálogo 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

levantarán en detalle.

5.4.1.5.1.9. Declarar Visión del Negocio

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

necesidad, dejando constancia de la concepción que tiene, la cual, posteriormente se

evaluará dentro de las posibles soluciones si es factible.

�

�

5.4.1.5.1.10. Priorización de los Requisitos Funcionales

Los requisitos funcionales, listados según el punto 4.1.6.1.7 deben priorizarse siguiendo el

siguiente esquema:

Tabla 4 Atributos de Priorización

Atributos de Priorización

ID Requisitos Prioridad

del Cliente

Complejidad

Esfuerzo Estabilidad

<identificador

requisito>

<nombre descriptivo del

requisito>

Prioridad del Cliente

Este atributo se refiere a la relativa importancia de implementar la característica definida

en relación 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

Complejidad

Este atributo se refiere a la búsqueda del nivel de abstracción requerido para comprender

el requerimiento durante el proceso de análisis y diseño.

Tabla 6 Valores de Atributos para Complejidad

Alta Es un requisito crítico y afecta directamente al negocio o

cliente.

Baja Es deseable, pero no se ha identificado el valor para el

negocio o para el cliente.

Alta Requiere un alto nivel de abstracción para la comprensión

del requerimiento.

Baja Requiere un bajo nivel de abstracción para la comprensión

del requerimiento.

�

Esfuerzo

El grupo de desarrolladores analiza el nivel de esfuerzo de la característica, tomando en

cuenta el tiempo y los recursos necesarios, las líneas de códigos requeridas, el número

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

Descripción 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 Características Generales

Son condiciones o capacidades que deben estar incluidas dentro de la solución. Estas, se

deben expresar en lenguaje natural de forma concreta y enumerada.

Por ejemplo:

Tabla 9 Ejemplo de Características Generales de la Solución TI

Id.

Característica Característica Observación

1 Tiempo de respuesta para realizar una transacción debe ser

menor a un segundo.

El tiempo de respuesta

actual es aproximadamente

8 segundos.

�

�

2 El proceso de negocio requiere incorporar nuevos atributos en la

solicitud de información de un servicio.

El proceso de negocio

actualmente no contempla

los atributos requeridos del

servicio.

3

La aplicación debe ser cross browser para garantizar los

estándares usabilidad independientemente del navegador

empleado.

Actualmente la aplicación

únicamente se ejecuta

adecuadamente en un

navegador propietario.

5.4.1.5.1.12. Justificación

Describir los beneficios que se obtendrán con la ejecución exitosa del proyecto e indique

cómo apoya los objetivos estratégicos del negocio.

5.4.1.5.1.13. Premisas Consideradas

• Consideraciones del negocio: Indicar alguna consideración que el negocio solicita

tomar en cuenta, por ejemplo algún proceso que no deba cambiar en su estructura

fundamental, o por el contrario algún proceso que señale deba cambiarse

radicalmente para optimizarlo

• Consideraciones de Tecnología: determinar en conjunto con el representante del

negocio (usuario funcional) los siguientes aspectos:

� Usuarios Totales: representa la cantidad de usuarios que interactuarán con

la solución.

� Localidades: ubicación geográfica donde se encuentran los usuarios.

� Dispositivos involucrados: lista de todos los dispositivos que interactuarán

con la solución.

� Intranet/Extranet: indica si la solución es del ámbito interno o externo de la

red corporativa.

• Limitaciones: listar las posibles limitaciones de la solución.

• Determinar pre-factibilidad técnica de los requerimientos: esta factibilidad no es

un estudio detallado sino una primera opinión del consultor de negocio apoyándose

con líderes de proyecto, consultores tecnológicos, seguridad AIT, etc., que por su

experiencia puedan dar sus observaciones. De acuerdo a este resultado puede

�

�

surgir una investigación exhaustiva y se puede preparar un estudio de factibilidad

detallado en la siguiente.

• Recomendaciones: proponer las soluciones visualizadas a implantar, según las

mejores prácticas de ingeniería, metodologías y nuevas tecnologías, que permitan

desarrollar el proyecto/solución y alcanzar los objetivos propuestos de acuerdo al

resultado del análisis de pre-factibilidad.

5.4.1.5.1.14. Definir Estrategias

• Contratación: 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 también qué estrategia de contratación

puede ser utilizada (si aplica) para la ejecución y operacionalización del proyecto.

• Ejecución: la estrategia de ejecución debe dar respuesta a los siguientes aspectos:

� La división de la ejecución en partes o áreas.

� Ejecución con recursos propios o contratados.

� Fechas de inicio y finalización de cada porción del trabajo.

� El balance adecuado entre la magnitud del proyecto y los recursos

requeridos.

5.4.1.5.2. Identificación de Servicios

Identificar los servicios que puedan ser consumidos o provistos por los componentes

funcionales involucrados en la solución como se puede observar en la siguiente tabla

ejemplo:

�

�

Tabla 10 Identificación de Servicios Nombre

Servicio

Unidad de

Negocio

Proceso(s) de

Negocio

Caso(s) de uso de

Negocio Cliente(s) Proveedor(es)

<Nombre del

Servicio>

Restricción: el

nombre del

servicio es único

en el repositorio.

<Unidad de

Negocio

custodio del

servicio>

<Procesos de

Negocio que

requieren el

servicio>

<Casos de uso de

Procesos de

Negocio que

requieren el

servicio>

<Aplicacione

s o

Componente

s

Funcionales

clientes del

Servicio>

<Componentes

Funcionales o

Aplicaciones

Proveedor(es) del

servicio>

crearCliente Data Maestra Creación de

Clientes

Crear Cliente Data Entry Facturador

asientoContable Finanzas Asientos

Contable

Realizar Asiento

Contable

RESET

GADET

ERP FI/CO

No necesariamente todas las soluciones de TI están 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 solución

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 solución de la necesidad u oportunidad planteada

(estudios de Gartner, etc.)

5.4.1.5.5. Análisis Comercial / Análisis de Prefactibilidad Económica (Clase V)

En el capítulo IV, donde se examinó la situación, se señaló que en AIT la mayoría 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 inversión, debe

cumplir con el análisis comercial.

5.4.1.5.5.1. Determinar Indicadores Económicos

Las propuestas, para efectos de conformar la cartera de inversión, deberán clasificarse en:

• Generan Ingresos (GI)

• Generan Ahorros (AH): Las propuestas que generan ahorros deberán justificarse

por sí mismas mediante una evaluación a nivel unidad de negocio, que compare la

situación actual con la que ocurriría de ejecutarse la propuesta. El DSD del

proyecto debe presentar el flujo de caja de la situación actual, el flujo de caja

propuesto, el flujo de caja diferencial y la metodología para medir los beneficios que

éste aporta una vez entrado en operación el proyecto. Los indicadores económicos

deberán ser calculados a partir del flujo de caja diferencial.

• Consolidan Producción (CP)

• Asociada (AS)

• Proyectos Interés Corporativo (PIC)

• Continuidad Operacional

� Reemplazo/Mantenimiento (RM)

� Normativas/Regulatorias (COPNR)

� Otras Inversiones de Continuidad Operacional (COPOT)

• Exploración (EX)

• Asociaciones/Empresas Mixtas (EM)

�

�

• Investigación y Desarrollo (ID)

Adicionalmente se deben determinar:

• Costos de Inversión

• Costos de operación 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 precisión del tipo orden de

magnitud, el cual se utiliza en la planificación a mediano plazo para establecer si los

proyectos reúnen los méritos suficientes para proseguir su desarrollo.

El mismo deberá incluir un estimado de costos de mayor precisión (clase II) de los fondos

requeridos para el desarrollo de la fase Conceptualizar y de los trabajos de laboratorio

necesarios para mejorar la definición del proyecto. Estos fondos deberán ser solicitados y

aprobados antes de proseguir con dicha fase. Ver anexo N° 1.

Información requerida

Este estimado debe basarse en una definición global, a “grosso modo”, del proyecto y de

sus principales unidades de proceso, en la que la información disponible se limite

esencialmente a:

• Tamaños o capacidades propuestas

• Ubicación geográfica

• Especificación preliminar de insumos y productos

• Fechas tentativas de inicio y finalización del proyecto

Método de estimación

Se basa en datos históricos de costos que provienen de proyectos similares ejecutados o

curvas de costos de unidades de proceso similares (extrapolación estadística),

�

�

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

ubicación geográfica, etc.

Precisión 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 información disponible de proyectos similares ya

completados o que estén en desarrollo y de la pericia con que se evalúen, se ajusten por

factores o se escalen, los datos de costo.

5.4.1.5.7. Elaborar Plan de Ejecución del Proyecto (PEP) Clase V

El PEP documenta y comunica esos asuntos importantes no técnicos a otros participantes

del proyecto. El PEP debe destacar la panorámica total tomando en consideración todas

las facetas del proyecto y aquellas cosas que pueden influenciar en su ejecución.

EL PEP debe contener al menos los siguientes temas:

• Sumario

• Propósito

• Antecedentes del Proyecto

• Temas Críticos

• Programa Ejecutivo de Ejecución

• Plan de Contratación

• Control Del Proyecto

• Organización Del Proyecto

• Tecnología/Ingeniería

• Adquisición de Materiales, Equipos u Horas Hombre

• Construcción en Campo (si aplica)

• Coordinación para El Arranque

• Informes

�

A lo largo de la ejecución del proyecto, resulta conveniente asignarle a este plan, una

clasificación 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 propósito de respaldar la toma

de decisiones, la información 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 precisión clase II para ejecutar la próxima fase

(Conceptualizar).

• Definir recursos requeridos para ejecutar la próxima fase (Conceptualizar) clase II.

Se deben precisar los recursos que serán 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 Documentación del Proyecto en la Base de Datos

de Configuración.

La Base de Datos de Configuración está conformada por dos aplicaciones AIR y

Dimensions, la primera se utiliza principalmente como repositorio de documentación e

información de los Elementos de Configuración y Dimensions es un repositorio de

versiones de software.

Un Elemento de Configuración (EC) es todo componente de hardware o

software de la infraestructura de AIT de la corporación o su documentación, que

está bajo el control del proceso de Gestión de la Configuración (GC). Algunos

ejemplos de EC son: aplicaciones, computadoras personales, servidores,

switches, dispositivos de campo, entre otros. (Gestión de la Configuración, 2007)

Para que un proyecto sea posteriormente recibido por el personal de operaciones de AIT,

el proceso de Gestión de la Configuración, exige cumplir con este paso, de lo contrario la

nueva solución no será aceptada.

�

��

5.4.1.6. Entrega de DSD1

• Revisión del DSD1: La revisión 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.

• Aceptación de DSD1: en este punto, dependiendo del aprobador que corresponda,

se decide si se acepta el proyecto para continuar con la siguiente fase, esta

aceptación 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 propósito de esta fase es la selección de la(s) mejor(es) opción(es) y la mejora en la

precisión de los estimados de costos y tiempo de implantación. En esta fase se detallan

además los requerimientos del negocio para la nueva solución de TI.

Las actividades que están acompañadas de la palabra actualizar, se refiere a actividades

que ya se ejecutaron previamente y que solo es necesario validar si hubo algún 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 documentación que se genera

en cada unas de ellas, como los Planes de Ejecución de Proyectos, o Documentos de

Soporte de Decisión.

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.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 Propósito / Objetivos y metas del Proyecto (actualizar)

5.4.2.2.1.4. Definir Situación Actual (actualizar)

5.4.2.2.1.5. Definir Alcance del Proyecto (actualizar)

5.4.2.2.1.6. Justificación (actualizar)

5.4.2.2.1.7. Definir Estrategias y Recomendaciones para Evaluación de Soluciones

Se deben evaluar las alternativas de solución, en este punto debe explicarse la estrategia

que se utilizará para realizar la evaluación de las posibles soluciones, esto se refiere a los

pasos que se seguirán, metodologías y recursos necesarios para completar con éxito la

evaluación de cada alternativa y el análisis de los resultados para realizar el informe final

de recomendación de solución.

Incluir las recomendaciones relacionadas con lo desarrollado en esta sección, por

ejemplo, para las pruebas de cada alternativa de solución podrían requerirse acuerdos de

confidencialidad, también necesidades de instalaciones, espacio y equipos.

En caso de pruebas de concepto, podrían ser convenientes acuerdos con los proveedores

de la tecnología 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 evaluación 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 conceptualización, 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 sección, sino se coloca el

mismo.

5.4.2.2.4. Especificación 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 físicos de los intercambios de datos entre los

componentes funcionales o aplicaciones involucradas en el proceso de negocio que

apoyarán las decisiones de diseño. Deben documentarse modificaciones, incorporaciones

o desincorporaciones de intercambios de datos del proceso de negocio.

Tabla 11 Identificación de Intercambio de Datos

Orden Origen Des-

tino

Descripción Datos Inter-

cambiados

Síncrono/

Asíncrono

En

línea /

Batch

For-

mato

Volu-

men

Tiempo

de Res-

puesta

1 RMCA CTC Envío de

órdenes de

pago

Según

definición

Síncrono En línea XML 8000 por

día

1.5

segund

os

2 CTC RMC Envío de Según Asíncrono Batch Archiv <= N/A,

�

��

Orden Origen Des-

tino

Descripción Datos Inter-

cambiados

Síncrono/

Asíncrono

En

línea /

Batch

For-

mato

Volu-

men

Tiempo

de Res-

puesta

A pagos

cobrados

definición diario o

plano

31500

registros

mensua-

les

batch

3 CTC RMC

A

Envío de

pagos

rechazados

Según

definición

Asíncrono Batch

diario

Archiv

o

plano

<=

31500

registros

mensua-

les

N/A,

batch

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 Especificación de Servicios

Nombre

Servicio

Unidad de

Negocio

Proceso(s)

de Negocio

Caso(s) de uso

de Negocio Cliente(s) Proveedor(es)

<Nombre del

Servicio>

Restricción:

el nombre del

servicio es

único en el

repositorio.

<Unidad de

Negocio

custodio del

servicio>

<Procesos de

Negocio que

requieren el

servicio>

<Casos de uso

de Procesos de

Negocio que

requieren el

servicio>

<Aplicacion

es o

Component

es

Funcionales

clientes del

Servicio>

<Componentes

Funcionales o

Aplicaciones

Proveedor(es)

del servicio>

asientoContab

le

Finanzas Asientos

Contable

Realizar Asiento

Contable

RESET

GADET

ERP FI/CO

Tabla 13 Especificación de Funcionalidad de Servicios

Funciona-

lidad del

servicio

Tipo de

exposición

del Servicio

Servicio

Concreto Sincronía

En Línea /

Archivo

plano

Transaccio-

nal / Batch

Ca-

nal

Artefact

o

Contrato

Adaptación

ASC.crear

Cliente_4_

DE Síncrono En Línea Transaccional WS

crearClie

nte.wsdl

�

��

5.4.2.2.4.4. Especificación de Contratos

[Si aplica] La interacción básica en un modelo basado en servicios es entre clientes y

proveedores del servicio. El acuerdo entre ambas partes, denominado contrato,

específica los detalles del servicio que el proveedor ofrece, permitiendo una relación

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 información entre las partes, así

como la relación técnica entre las partes. Un contrato de servicios debe contener:

Tabla 14 Contenido de un Contrato de Servicios

Requerimientos

Funcionales Requerimientos No Funcionales Políticas del Servicio

El contrato debe especificar

la data y la funcionalidad

provista por el proveedor del

Servicio.

El contrato puede especificar: 1. la

responsabilidad de los proveedores

para proveer la data y la funcionalidad;

2. responsabilidad de los

consumidores; 3. consideraciones de

seguridad, calidad de servicio,

disponibilidad, entre otros.

El contrato puede especificar las

políticas de intercambio que aplican

a un tipo o número de contrato: 1.

quién accede a un proveedor; 2.

procedimientos de seguridad que los

participantes deben cumplir.

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 políticas.

El contrato debe especificar la petición 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

continuación. El código del actor reseñado como ACT.# se refiere al prefijo ACT. Seguido

por el número de actor asignado. La XX se refiere al nombre del Actor. La descripción se

�

��

refiere a una breve reseña 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 Descripción de Actores

Actor: ACT.# XX

Descripción: <descripción del actor>

Responsabilidades: • <Responsabilidad 1>

• <Responsabilidad 2>

Fuentes: <Stakeholders que identificaron y contribuyeron a definir al actor>

5.4.2.2.4.6. Definir Permisología de los Actores

De acuerdo a los actores definidos y sus responsabilidades se determinarán los diferentes

perfiles a crear en la solución que, posteriormente, si se trata de una aplicación Web de la

intranet (que son la mayoría de los casos) y según los lineamientos bases de seguridad

lógica, se convertirán 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 agrupándola 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 Especificación de Casos de Uso del Sistema

La especificación de los casos de uso viene dada por una tabla donde se señalan los

siguientes detalles:

Tabla 16 Especificación de Casos de Uso

Caso de uso CU.1 XX

Fuentes <Stakeholders que proporcionaron información de esta funcionalidad>

Actor Act.# <nombre de los actores> [(<Pseudónimos>)] [ – secundario]

Descripción Act.# <Descripción del caso de uso>

Flujo básico 1. Titulo del paso

Descripción del paso.

2. Titulo del paso


Flujos alternos 1. Titulo del FA

Descripción del FA

2. Titulo del FA

Descripción del FA.

Pre condiciones 1. Titulo del Precondición

Descripción del PRC

Post condiciones 1. Titulo del Poscondiciones

Descripción de la PTC

Requerimientos

especiales

1. Titulo del requerimiento

Descripción del requerimiento o porqué se enlaza a el desde este caso de uso

Puntos de

Inclusión

1. Título del punto de inclusión

Descripción del punto de inclusión

Puntos de

extensión

1. Título del punto de extensión

Descripción del punto de extensión

Notas 1. Titulo de la Nota

Descripción de la nota

5.4.2.2.4.9. Elaborar Especificación de Requerimientos de Información

Los requerimientos de información deben ser provistos según la tabla N° 17.

Tabla 17 Requerimientos de Información

Requisito de Información

RI-<id>: <nombre descriptivo>

�

��

Requisito de Información

RI-<id>: <nombre descriptivo>

Versión: <Nº de la versión actual> (<fecha de la versión actual>)

Autores: <autor de la versión actual> (<organización del autor>)

Fuentes: <fuente de la versión actual> (<organización de la fuente>)

Descripción: El sistema deberá almacenar la información correspondiente a <concepto relevante>.

Componente Funcional Componente funcional con el que esta relacionado el R.I

Nombre Descripción Tipo Longitud Procedencia

Atributos: <nombre

descriptivo>

<breve descripción del

atributo>

<tipo de

dato>

<longitud

del atributo>

<procedencia del

atributo>

5.4.2.2.4.10. Elaborar Especificación de Requerimientos No Funcionales

Los requerimientos no funcionales deben incluirse según el siguiente modelo:

Tabla 18 Requerimientos No Funcionales

Identificador Nombre Descripción Fuente

RI-<id> <nombre descriptivo> El sistema deberá <capacidad del

sistema>

<autor de la versión

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 priorización de requerimientos realizada en la fase

Visualizar, por lo tanto solo se debe validar con los usuarios funcionales si han cambiado

de opinión con respecto a la prioridad de algún elemento de la tabla originalmente

elaborada.

5.4.2.2.4.12. Elaborar Guión de Interfaz de Usuario

Consiste en elaborar un conjunto de pantallas preliminares diseñadas para la solución.

Estas pantallas o vistas no requieren una estricta navegabilidad o algún tipo de

�

��

funcionalidad. Esta sección únicamente aplica para soluciones que impliquen un Sistema

de Información 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 Tecnología (actualizar)

5.4.2.2.4.14. Elaborar Matriz de Evaluación que se Aplicará a las Posibles Soluciones

Esta matriz debe se elaborada solo cuando existen varias soluciones en el mercado o

dentro de la Organización, que puedan dar respuesta a la necesidad solicitada, por lo que

es necesario compararlas, evaluarlas, y decidir la mejor opción para lograr el objetivo del

proyecto.

Los requisitos serán valorados de acuerdo a las particularidades y prioridades de cada

proyecto.

5.4.2.2.4.15. Definir Arquitectura y Evaluar Solución

5.4.2.2.4.15.1. Describir Solución Propuesta

Se debe realizar una descripción detallada de la solución que se va a proponer,

considerando:

• Tipo Solución: Desarrollo nuevo, adaptación, ajuste, procura

• Consideraciones Preliminares: Son las premisas que debe cumplir la solución

con el objeto de garantizar su éxito.

� Usuarios Concurrentes: Número de usuarios que interactúan con la

aplicación al mismo tiempo.

� Volumen de Datos: Cantidad de información que viaja de la base de datos a

la aplicación o viceversa.

� Usuarios Totales: representa la cantidad de usuarios que interactuarán con

la solución.

� Localidades: ubicación geográfica donde se encuentran los usuarios.

� Interfaces: lista de todos los sistemas o dispositivos que interactuarán con la

solución.

�

�

� Intranet / Extranet: indica si la solución es del ámbito interno o externo de la

red corporativa.

5.4.2.2.4.15.2. Investigar Antecedentes de la Solución

Referencias a trabajos similares que se hayan realizado dentro de la organización o fuera

de esta.

5.4.2.2.4.15.3. Definir Alcance de la Solución Propuesta

El alcance indicará claramente hasta donde llegará la solución propuesta, así como

también lo que no contemplará.

5.4.2.2.4.15.4. Desarrollar Marco teórico referencial

Incluir un marco teórico 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 Estándares de la Solución

Indicar qué estándares, políticas y lineamientos serán considerados en la solución. 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 tecnologías libres, evitando, a menos

que no haya un sustituto aún y que sea de vital importancia para la continuidad operativa o

estratégica del negocio, el uso de tecnologías propietarias.

5.4.2.2.4.15.6. Aplicar Matriz de Evaluación a la Solución

Aplicar a la solución la matriz de evaluación elaborada anteriormente en esta fase para

validar que tanto satisface las necesidades del proyecto

�

��

5.4.2.2.4.15.7. Solicitar Consultoría de Seguridad Lógica

Esta actividad se realiza con el objetivo de que Seguridad Lógica, realice una revisión de

los requerimientos y pueda establecer los criterios mínimos de seguridad que debe cumplir

la solución 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

Solución

Describir y graficar la arquitectura tecnológica (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 Solución / Cronograma para esta

Solución

Realizar en este paso un cronograma preliminar de las siguientes fases del proyecto de

acuerdo a la solución que se esté evaluando

5.4.2.2.4.15.10. Definir Productos

Determinar de acuerdo al tipo de proyecto cuales serán los productos entregables,

validando con mantenimiento de plataforma que sean los necesarios para que luego de

que el proyecto termine, esta organización tenga toda la información indispensable para

garantizar la continuidad operativa de la nueva solución.

5.4.2.2.4.15.11. Elaborar Matriz de Resultados de la Evaluación

Una vez aplicada la matriz de evaluación 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 demás

análisis, determinarán la solución a recomendar. Culminando con la elaboración de un

informe con el resultado de la evaluación y la solución 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 solución tecnológica, se

debe informar a MAP cuales son los recursos necesarios de TI en general para dicha

solución (servidores, disponibilidad de ancho de banda, etc.) de manera de que esta

organización planifique la recepción de esta nueva solución en su plataforma o alerten en

caso de que no dispongan de los recursos para tomar las acciones que competan, como

por ejemplo la adquisición de equipos con presupuesto del proyecto si fuera necesario, lo

cual a su vez se reflejaría 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 características para el

ambiente de desarrollo, donde se irán 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 preparación se deben tomar en cuenta los siguientes aspectos:

• Determinar roles y responsabilidades preliminares para la fase Definir.

• Establecer estrategia de contratación 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 Ejecución del Proyecto (PEP) (actualizar)

5.4.2.2.8. Incluir los Datos y Documentación del Proyecto en la Base de Datos de

Configuración (actualizar)


El proceso de entrega del Documento de Soporte de Decisión se explicó en la fase

Visualizar, lo mismo aplica para la entrega de este documento en las demás fases,

considerando los siguientes pasos:

�

�

• Revisión del DSD2.

• Aceptación del DSD2.

5.4.3. Fase Definir

Las decisiones tomadas en la fase de Conceptualización constituyen el insumo de trabajo

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

El propósito de esta fase es desarrollar en detalle el alcance y los planes de ejecución de

la opción seleccionada para lo que permitirá principalmente obtener los fondos para

ejecutar el proyecto.


• Incorporar nuevo personal de proyectos al equipo

• Definir el Organigrama/Roles y Responsabilidades para el equipo

• Identificar equipos de apoyo


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 Propósito / Objetivos y Metas del Proyecto (actualizar)

5.4.3.2.4. Definir Situación Actual (actualizar)

5.4.3.2.5. Definir Alcance del Proyecto (actualizar)

5.4.3.2.6. Justificación (actualizar)

5.4.3.2.7. Cuantificar los Beneficios

Determinar de una manera tangible los beneficios obtenidos a través de la ejecución del

proyecto. Por ejemplo, si se trata de una sustitución de un software, establecer las

diferencias en especificando mejoras en tiempos de respuestas, o si se trata de la

�

��

automatización de un proceso, señalar la reducción en el número de pasos para ejecutar

el mismo, las ventajas de la automatización, etc.

5.4.3.2.8. Determinar Oferta Social

Verificar con la organización Cadena de Suministros, si de acuerdo al tipo de contratación

que se piensa realizar aplica algún tipo de oferta o aporte social.

5.4.3.2.9. Elaborar Recomendaciones

Se deben describir las acciones para lograr la aprobación del proyecto de manera de

avanzar a la fase de implantación 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 ejecución.

5.4.3.2.10. Análisis de Riesgos

Indicar si existirían riesgos durante la ejecución del proyecto y de ser así, describir si son

técnicos, políticos, económicos, sociales, de mercado, ambientales, entre otros. Los pasos

mínimos son: identificación de riesgos, cuantificación / ponderación de riesgos, análisis

probabilístico de sensibilidad tiempo / costo, acciones para gerenciar el riesgo.

5.4.3.2.11. Documentar el Alcance y Diseño Básico del Proyecto

En esta sección se deben incluir los productos/artefactos que rigen o establecen

lineamientos para la construcción de las soluciones de TI, componentes funcionales,

servicios e interfaces requeridas para el proceso de negocio.

5.4.3.2.12. Elaborar Especificaciones de Construcción

Establecer las especificaciones de construcción para el desarrollo requerido o propuesto.

�

��

5.4.3.2.12.1. Diseño 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

configuración de los componentes de hardware, software y red que soportan el proceso de

negocio.

El diagrama de despliegue permite representar la vista estática de la configuración de los

nodos de hardware y componentes de software, junto con el estereotipo de componentes,

apoya: 1.- el diseño de la configuración de hardware y software para soportar el proceso

de negocio; 2.- la exploración de aspectos relacionados con la ejecución del proceso de

negocio en ambientes de prueba y producción; 3.- explorar las dependencias del proceso

de negocio con otros sistemas actualmente en producción o propuestos para ser

integrados con el proceso de negocio bajo estudio.

�

Fig. 18 Ejemplo Diseño de Arquitectura

5.4.3.2.12.2. Especificación de Servicios (actualizar)

Los servicios, si existen para la solución, 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. Especificación 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 especificación del documento XML o

WSDL.

5.4.3.2.12.4. Realizar Diagrama de Clases

El diagrama de Clases captura la estructura lógica del sistema.

“Es un modelo estático, describiendo lo que existe y qué atributos y

comportamiento tiene, más que cómo se hace algo. Los Diagramas de Clases

son los más ú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 composición 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-Relación (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 y se vinculan mediante relaciones”

(http://www.mitecnologico.com/Main/DiagramasEntidadRelacionER, consultado 03-08-

2009).

�

��

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 representación 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 cómo 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 Colaboración.

5.4.3.2.12.8. Desarrollar Prototipo

El Prototipo es la evolución del Guión de Interfaz de Usuario (que se realizó en la

conceptualización).

El Prototipo contiene vistas navegacionales para la aprobación del usuario, debe proveer

vistas funcionales de la solución.

5.4.3.2.13. Especificación de Pruebas

En esta fase se deben construir los casos de pruebas para los diversos tipos de pruebas

que se realizarán en la siguiente fase, especificando como se ejecutarán cada una de

�

��

ellas. Se deben proponer los participantes, los responsables, fechas estimadas y demás

detalles que sean necesarios.

5.4.3.2.13.1. Pruebas Unitarias

Las pruebas permitirán probar pequeñas e individuales porciones de código. A través de

ellas se verifica que cierto módulo o funcionalidad se ejecuta dentro de los parámetros y

especificaciones concretadas en documentos tales como los casos de uso y el diseño

detallado: proporcionan un contrato escrito que la porción de código debe cumplir

(http://www.slideshare.net/dbaccess/pruebas-unitarias-uso-de-nunit-dentro-de-proyectos-

net , 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 solución funcionan juntos. Adicionalmente estas pruebas deben

contemplar:

• Pruebas funcionales (interfases)

• Validación de la documentación

• Pruebas No funcionales

• Pruebas de Seguridad

5.4.3.2.13.3. Pruebas de Stress

Es una prueba integral que no solo evalúa la capacidad de concurrencia de usuarios, sino

también rendimiento de los servidores y monitoreo de la red.

5.4.3.2.13.4. Pruebas de Aceptación

Las pruebas de aceptación se pueden realizar mediante el siguiente formato:

�

�

Tabla 19 Prueba de Aceptación

Pruebas de Aceptación

Aplicación / Proyecto <nombre del proyecto o aplicación para la que se diseña 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 ejecución de la prueba>

Tipo de Prueba Aceptación Fecha de Ejecución:

Descripción de la Prueba: <Descripción de la prueba>

Resultados Esperados: <Resultados esperados de la prueba>

Errores Encontrados:

Necesita Reprobarse

Prueba Aprobada:

Descripción del error:

Revisada y Aprobada por: Fecha de revisión:

Ruta y/o Ubicación de Log’s de resultados de pruebas:

5.4.3.2.14. Describir Efectos Netos sobre el Personal

Se requiere determinar si la implantación del proyecto tendrá incidencia de en aumentos o

disminución de personal, tanto operacional como administrativo.

5.4.3.2.15. Describir Efecto sobre los Costos de Operación

Señalar si la nueva solución acarreará costos para permitir su continuidad operativa, por

ejemplo si la solución incluye software propietario se puede proyectar los costos en

licenciamiento anual, si un nuevo hardware requiere contrato de mantenimiento posterior a

su implantación, 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 contratación y la construcción que son

las dos macroactividades principales de la fase de Implantación.

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 contratación y procura para la fase implantar: para definir la

estrategia es necesario que el líder de proyecto lleve el caso a Cadena de

Suministros, ya que son ellos los expertos en materia de contratación, y quienes

indicarán 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 próximas fases (Implantar y Operar).

• Establecer guías 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 método del valor ganado.

5.4.3.2.19. Elaborar Plan de Ejecución del Proyecto (PEP) clase II

5.4.3.2.20. Evaluar Grado de Definición del Proyecto

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

alcanzado un buen grado de definición. Esta es la razón por la cual resulta de suma

importancia hacer la evaluación de la definición del proyecto antes de someterlo a

aprobación y solicitud de fondos para su completación. La evaluación del grado de

definición (o “FEL index” como se conoce en idioma inglés por Front End Loading), es una

revisión 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 completación es viable en forma

exitosa de acuerdo con el alcance y la planificación prevista.

Generalmente, esta evaluación es realizada por una organización externa al proyecto, la

cual dependiendo de la magnitud y complejidad del mismo, podría 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 Tecnológico

Para la selección final de la tecnología se deben considerar todos los aspectos necesarios

en el aseguramiento tecnológico según aplique dependiendo del tipo de solución, los

cuales se enumeran a continuación.

• Evaluación de la tecnología.

• Acuerdos de transferencia de tecnología.

• Pagos por el uso de la tecnología.

• Consultas durante la ingeniería 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 información necesaria para concursar. El mismo plasma los

requerimientos básicos del proyecto desde los puntos de vista técnicos, de ejecución y

contractuales.

A continuación, se muestra en forma gráfica el contenido típico del Documento de

Solicitud de Oferta (DSO):

�

Fig. 21 Contenido Típico de un DSO

5.4.3.2.23. Actualizar los Datos y Documentación del Proyecto en la Base de Datos

de Configuración




5.4.4. Fase Implantar

5.4.4.1. Proceso de Contratación

El proceso de contratación se ejecutará de acuerdo a la estrategia de contratación 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

específicas del proceso seleccionado para incorporarlas en el plan.

�

�

5.4.4.1.1. Elaboración de Borrador de Acta de Inicio y Memo para Iniciar Proceso

de Contratación

CDS debe proporcionar a DIS modelos de estos documentos de procesos de contratación

similares para que el líder de proyecto tenga una guía para hacerlos.

5.4.4.1.2. Establecer Roles y Funciones con Organización de CDS

Aclarar con CDS como será la participación del líder de proyecto en el proceso de

contratación, en cuanto a definir qué documentos elabora cada organización, quién es

responsable de la comunicación directa con la Comisión de Contrataciones, en qué partes

del proceso debe participar o no el líder del proyecto.

5.4.4.1.3. Revisión de las Condiciones de Participación o Pliegos

Estas actividades se realizan en conjunto con CDS, el líder principalmente hace

seguimiento y participa en la elaboración de algunos documentos según se haya definido

en el punto anterior, principalmente se deben contemplar los siguientes aspectos:

• Validar modalidad de contratación.

• Elaborar Contrato Modelo.

• Apoyo al perfilamiento de empresas / análisis de mercado (si aplica).

• Verificar aplicabilidad de modelo de contrato propuesto.

• Elaborar la matriz de evaluación técnica de las empresas.

• Solicitud de inicio de proceso en Comisión de Contrataciones.

• Invitación de participación a las empresas al proceso de licitación.

• Reunión aclaratoria.

• Entrega de ofertas.

• Apertura y validación de sobres.

5.4.4.1.4. Evaluación Técnica / Económica (según aplique)

Para la evaluación técnica / económica deben considerarse las siguientes tareas:

�

�

• Realizar la evaluación técnica de las ofertas

• Elaborar informe técnico de resultados

• Elaborar acta de resultados

• Elaborar memo de evaluación

• Notificación de resultados

• Elaboración de contratos definitivos (revisión y visado por consultoría jurídica)

5.4.4.1.5. Otorgamiento de la Buena Pro

• Notificación a las empresas de la Buena Pro

• Recaudación de requisitos administrativos de la empresa contratada para la firma

del contrato

• Revisión y firma del contrato

• Firma de Contrato

5.4.4.2. Elaborar PEP Clase I

Este plan es la base para el control de ejecución del contrato de acuerdo a los productos

definidos. Se elabora una vez otorgado el(los) contrato(s), consolidando la información

contenida en el plan de ejecución 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 medición de avance del proyecto y, por ende, el control de

costos y la facturación 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

límites apropiados del alcance de su trabajo y presentar adecuadamente los detalles.

Todos los contratistas licitantes deben preparar su PEP durante el período de selección, a

objeto de garantizar que las intenciones de ejecución del contratista son bien entendidas

por el ente contratante, en este caso, AIT-DIS.

�

�

Inmediatamente después de otorgársele al contratista la buena–pro, se le deben

suministrar algunas secciones del PEP del proyecto para confirmar su planificación 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 ambigüedad los elementos de trabajo del contratista para

establecer una base idéntica de medición.


En esta fase, la actividad conformar equipo de trabajo, es mas extensa y detallada, ya que

se trata del equipo que debería participar durante esta fase y la siguiente que se podría

decir, son las de mayor peso puesto que se trata de la ejecución 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 tecnología asignado.

• Convocar analista de asuntos públicos asignado.

• Convocar analista de seguridad lógica asignado.

• Convocar analista de auditoría de sistemas asignado.

• Convocar analista de MAP (Servidores, aplicaciones, BD) asignado (Según

aplique).

• Convocar analista de control de la configuración.

• Identificación de equipos de apoyo (riesgos, estimadores).

• Definir el organigrama/roles para el equipo.

5.4.4.4.2. Validar Lineamientos

• Del negocio.

• Tecnológicos.

�

• De requisitos.

5.4.4.4.3. Reunión de Inicio de Proyecto con Equipo PDVSA / Empresa Contratada

• Firma del acta de inicio del servicio.

• Revisar plan detallado del proyecto.

• Revisar lineamientos tecnológicos a considerar en programación del desarrollo del

proyecto.

• Establecer los mecanismos de extracción/exportación de datos e interfaces (para

aquellos proyectos que aplique como en los casos de migración de una solución

tecnológica previa a una nueva).

5.4.4.4.4. Reunión de Inicio de Proyecto con Equipo Proyecto y Usuarios

Funcionales

• Presentación del equipo de trabajo.

• Revisar plan detallado del proyecto.

• Definición de comité de usuarios funcionales.



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 Propósito / Objetivos y Metas del Proyecto (actualizar)

5.4.4.5.1.4. Definir Situación Actual (actualizar)

5.4.4.5.1.5. Definir Alcance del Proyecto (actualizar)

5.4.4.5.1.6. Justificación (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 agregársele el monto a desembolsar por

cada producto por lo cual constituye también el plan de desembolsos. Es importante

verificar muy bien la lista de productos entregables, garantizando que se incluya la

documentación necesaria, así como asociar el último pago al acompañamiento durante el

arranque de la solución, 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. Construcción

5.4.4.5.3.1. Creación 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 producción, en este momento se le puede hacer entrega de la misma

planilla, (actualizada si fue necesario hacer algún ajuste), para que procedan a configurar

el ambiente de desarrollo. (Ver anexo N° 5).

5.4.4.5.3.2. Instalación y Configuración 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 adquisición de componentes de hardware, se deberán considerar los

siguientes pasos:

• Introducir Solicitud de Pedido o Requisición de Pedido de Material (RPM).

• Aprobación en SAP de la RPM.

• Selección de compra según ofertas recibidas.

• Adquisición de equipo.

• Instalación y pruebas del equipo.

5.4.4.5.3.4. Ingeniería de Detalle

El diseño de la solución se realizó en la fase definir, en esta fase, ya teniendo claro quien

ejecutará el proyecto, es necesario revisar todos los aspectos técnicos para validar que

son claros, funcionales y se adaptan perfectamente al objetivo del proyecto. Por lo tanto

se debe:

• Revisar / actualizar Especificación de Servicios.

• Revisar / actualizar Especificación de Contratos.

• Revisar / actualizar Diagrama de Clases.

• Revisar / actualizar Diagrama de Entidad-Relación

• 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 solución debe realizar en base a prioridad de los requerimientos, y en

función de obtener progresivamente como avances los productos definidos, quedando de

parte del líder de proyecto aplicar las estrategias de control y seguimiento que haya

definido.

5.4.4.5.3.6. Elaboración de la Documentación del Sistema (versión preliminar)

La documentación puede variar de acuerdo al tipo de proyecto, sin embargo existen

documentos básicos que deben tomarse en cuenta, como:

• Elaboración del plan de contingencia: para la elaboración de este plan se solicita

el apoyo del Departamento de Seguridad Lógica de AIT, quienes orientan en su

construcción.

• Documento de especificaciones actualizado: Se debe entregar este documento

actualizado de acuerdo a algún 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 Información (RI), Catálogo de Requisitos

Detallado, Consideraciones de Tecnología.

• Documento de desarrollo: contiene los diagramas de clases, modelo lógico de

datos (Diagrama E/R de las nuevas tablas y relaciones incluyendo tablas existentes

relacionadas), estructura física de datos (scripts), diccionario de datos y diagrama

de arquitectura del sistema (de hardware y software).

• Manual de sistema: representa el manual técnico de la solución y se compone de

los siguientes puntos: Introducción, antecedentes, objetivos, alcance, limitaciones,

plataforma tecnológica, tecnologías de desarrollo utilizadas, definición de clases,

componentes, librerías, archivos y script de configuración, descripción de

programas y scripts del sistema, requerimientos de hardware, requerimientos de

software, roles y perfiles, descripción de los procesos del sistema, diagrama de

procesos, diagrama de flujo, definición y descripción de algoritmos de los procesos

medulares del sistema, definición de interfaces con otros sistemas y tareas

programadas.

�

��

• Manual de Instalación: corresponde al manual de cómo realizar la instalación de

la solución tanto en el servidor cómo en la estación cliente (si fuese necesario),

debe contener lo siguiente: requerimientos de hardware, requerimientos de

software, pasos de instalación de la aplicación, configuración de la base de datos,

configuración del Web Site (si aplica), configuración de componentes (si aplica),

pruebas de la instalación, posibles fallas y soluciones.

• Manual de usuario: corresponde al documento de operación de la solución y

estará compuesto por los siguientes puntos: introducción, antecedentes, definición

de la aplicación, ejecución de la aplicación ingreso de usuario y contraseña,

descripción de funcionalidades o módulos del sistema. Debe existir un manual de

acuerdo a cada perfil de usuario del sistema.

• Manual de ayuda a Gestión del Servicio: Este documento explica de forma rápida

y sencilla cómo el personal de GDS perteneciente tanto al personal del centro de

servicios (soporte telefónico) y soporte integral (soporte en sitio), realizará la

solución de los incidentes, Este pequeño manual también 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 ejecución y resultados

esperados, más los resultados obtenidos. En palabras sencillas representan la

especificación y evidencia de que las pruebas formales a la solución han sido

realizadas

• Plan de capacidades: corresponde a la visión de lo que será según la evaluación

del proyecto los requerimientos de capacidad de la solución 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 años

• Documento de garantía: este debe contener la definición de la garantía aplicable

sobre los productos entregados, incluir términos de la garantía 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 Aceptación

• Generar informe de resultado de las pruebas.

• Realizar ajustes al sistema (si aplica).

• Actualizar la documentación para su versión final (si aplica).

5.4.4.5.3.8. Solicitar Evaluación de Seguridad Lógica en Ambiente de Desarrollo

Esta evaluación se realiza en el ambiente de desarrollo cuando han sido ejecutadas

satisfactoriamente todas las pruebas sobre la solución.

5.4.4.5.3.9. Realizar Adiestramientos

Se deben garantizar al menos las siguientes actividades de capacitación:

• Transferencia de conocimiento técnica (servidores, interfaces, base de datos).

• Transferencia de conocimiento funcional de la aplicación.

• Transferencia de conocimiento en cuanto a documentación de la aplicación.

• Adiestramiento a los usuarios funcionales.

5.4.4.5.4. Completar Anexos del DSD4

Es importante anexar al Documento de Soporte de Decisión 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

• Documentación técnica

• Documentar las lecciones aprendidas

�

��

• Listado de personal entrenado

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

continuidad operativa.

• Puntos pendientes de construcción (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 Gestión de Necesidades y

Oportunidades (GNO) para que visualice una nueva solución para dichos

requerimientos, ya sea como una segunda fase del proyecto por terminar, como

cambios a la solución 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 > Operación

• Definir roles y responsabilidades preliminares para la fase Operación

• Verificar disponibilidad de recursos necesarios para la próxima fase.

5.4.4.5.6. Actualizar los Datos y Documentación del Proyecto en la Base de Datos

de Configuración




5.4.5. Fase Operar

5.4.5.1. Colocar en Operación el Ambiente de Producción

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

características para alojar la nueva solución.

�

��

5.4.5.2. Crear estructura de la solución

La nueva solución 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 documentación, etc. Se deben hacer las

solicitudes correspondientes para que la nueva solución 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 operación es

necesario completarlo con los datos que quedaban pendientes referentes al ambiente de

producción, dirección IP de los servidores de producción, etc.

Posteriormente se solicita a Seguridad Lógica que lo evalúe, y de acuerdo a sus

observaciones, se ajusta si es necesario.

5.4.5.4. Realizar adiestramiento a Gestión 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 logística 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 organización de Gestión de la Configuración, solicita para la salida a producción de una

nueva solución dos controles de cambio, en este primer control de cambio se realizan las

siguientes actividades:

• Realizar reunión previa al control de cambio: en esta reunión deben participar todos

los involucrados y de allí debe surgir el plan de acción para la ejecución del control

de cambio y todas las tareas que deben crearse en el mismo.

�

��

• Instalar aplicación en el ambiente de Producción: esta actividad se realiza con el

apoyo de mantenimiento.

• Realizar pruebas:

� Realizar pruebas de stress: esta prueba se realiza independientemente del

número de usuarios, ya que debe ser una prueba integral que no solo evalúe la

capacidad de concurrencia de usuarios, sino también rendimiento de los

servidores y monitoreo de la red.

� Hacer rollback: esto significa que la aplicación debe ser eliminada del ambiente

de producción y mantenerse en el ambiente de desarrollo hasta que se apruebe

el siguiente control de cambio.

� Realizar ajustes a la solución (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 habría que generar un nuevo control de cambio hasta que las

pruebas de estrés resulten exitosas.

� Actualizar documentación (si aplica).

� Actualizar ultima versión de la aplicación Base de Datos de Configuración (si

aplica).

• Cerrar control de cambio

5.4.5.6. Realizar Control de Cambio 2

• Realizar reunión previa al control de cambio.

• Instalar aplicación en el ambiente de Producción.

• Solicitar Evaluación de Seguridad de todos los componentes: esta es la revisión

final que realiza seguridad lógica de la nueva solución ya en el ambiente de

producción.

� Realizar Evaluación de Seguridad.

� Realizar ajustes (si aplica).

� Actualizar ultima versión de la aplicación en la Base de Datos de Configuración

(si aplica).

• Cerrar control de cambio

�

��

Si el control de cambio número dos finaliza de manera exitosa, significa que ya se tiene

una nueva solución de TI en ambiente de producción, y lista para ser entregada

formalmente al personal de continuidad operativa de AIT.

5.4.5.7. Aceptación de Instalaciones

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

que permitirán darle continuidad a la nueva solución. Esta entrega debe ir acompañada de

un acta de recepción.

5.4.5.8. Elaboración de Informes Finales

5.4.5.8.1. Cierre del proyecto

Elaborar el informe de cierre del proyecto tanto de ejecución física, 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 terminación del contrato.

• Respaldos financieros.

• Acta de aceptación Provisional del Sistema.

• Documentar las lecciones aprendidas.

• Cronograma de ejecución.

Al haber completado las cinco fases del ciclo de vida basadas en esta metodología 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 metodológica.

�

��

�

6. CAPÍTULO VI

EVALUACIÓN DE LA PROPUESTA

Este capítulo presenta la evaluación del proyecto de Trabajo Especial de Grado a través

de los resultados relevantes obtenidos, la viabilidad de implantación 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 metodología para la gestión de proyectos de Tecnología de Información, mucho más

completa y acorde a la realidad de este tipo de proyectos, que la metodología estándar

que se sigue hasta el momento. Esto se debe a la incorporación de todos los elementos

técnicos necesarios para lograr una definición adecuada de los proyectos, que permiten a

su vez su correcto desarrollo y puesta en marcha, así como también fueron incluidas

actividades, mas allá de las propiamente técnicas, de procesos que hay que cumplir,

donde se interactúa con otras organizaciones de AIT y de PDVSA, que el líder de proyecto

no debe dejar pasar, logrando así eliminar algunos obstáculos que se presentan en la

actualidad por desconocer todas las actividades que se deben tomar en cuenta.

En función de lo anterior, se considera que se logró una herramienta muy importante y útil

para los líderes de proyecto y para la organización de Desarrollo e Implantación 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 misión, que cita: “Somos la Organización que rige,

provee y mantiene los servicios y soluciones integrales de tecnologías de automatización,

información y comunicaciones de la corporación; contribuimos a mantener su continuidad

operativa y a ejecutar sus planes; innovamos y actuamos como agentes de transformación

en PDVSA (…)”

�

��

Al proveer soluciones de Tecnología de Información, más oportunas y exitosas, se

contribuye con la Misión de AIT, que se reflejará además en el apalancamiento que dichas

soluciones aportan a los diferentes negocios de Petróleos de Venezuela.

6.3. VIABILIDAD DE IMPLANTACIÓN DE LA PROPUESTA

Una vez completada la metodología para gestión de proyectos de TI propuesta en el

presente Trabajo Especial de Grado, la misma fue presentada ante la Coordinación de

Metodologías de la gerencia de Desarrollo e Implantación de Soluciones, siendo recibida

gratamente como un aporte muy importante para la organización.

En este sentido, esta organización, en vista en que está en la capacidad de tomar las

decisiones referentes a los lineamientos de cómo debe trabajar la gerencia, decidió

proceder a divulgar la metodología en el equipo de trabajo, considerando como premisa

que los proyectos que están en curso se terminen de acuerdo a su planificación actual, y

cada nuevo proyecto que se asigne a un líder de la Gerencia DIS, debe seguir lo

establecido en esta metodología.

6.4. CUMPLIMIENTO DEL CRONOGRAMA

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

elaboración, se cumplió a cabalidad con el plan establecido, permitiendo de esta manera

su entrega según 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 diseño de la Metodología de Gestión de

Proyectos de Tecnología de Información definitivamente apoya la gestión de proyectos de

Automatización, Informática y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e

implantación de Soluciones (DIS). De igual forma, abordando los objetivos específicos,

también fueron cubiertos en su totalidad puesto que:

�

��

• Se realizó el análisis del potencial de uso de las Guías de Gerencia de Proyectos de

Inversión de Capital, GGPIC, para proyectos de Automatización, Informática y

Telecomunicaciones y se convalidó el real grado de aplicabilidad de las mismas

frente a las características y estrategias de desarrollo de los proyectos de AIT y

ante la organización actual basada en procesos.

• Se elaboró la propuesta de Metodología de Gestión de Proyectos de Tecnología de

Información 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 Coordinación de

Metodologías de la Gerencia de Desarrollo e Implantación de Soluciones para

implantarla como parte de este proceso en la gestión de los proyectos de AIT.

�

��

�

7. CAPÍTULO VII

CONCLUSIONES Y RECOMENDACIONES

Para cerrar el Trabajo Especial de Grado se expondrán las conclusiones y

recomendaciones pertinentes.

7.1. CONCLUSIONES

Luego de realizar el examen de la situación en el capítulo IV, se pudo observar que las

Guías de Gerencia para Proyectos de Inversión de Capital (GGPIC) se aplican en alto

grado en la gestión de proyectos de Tecnología de Información (TI), sin embargo, en la

Gerencia de Desarrollo e Implantación de Soluciones se ha visto, que siguiendo esta

metodología, siempre se ve afectada alguna de las aristas principales del proyecto

estudiadas en el capítulo II, conocidas como la triple restricción.

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 análisis permitió concluir que es necesaria una nueva metodología mejorada y

adaptada a las particularidades de los proyectos de Tecnología de Información (TI), los

cuales están a cargo de la Gerencia de Desarrollo e Implantación de Soluciones (DIS) de

Automatización, Informática y Telecomunicaciones (AIT) en Petróleos de Venezuela

(PDVSA).

La nueva metodología propuesta en este Trabajo Especial de Grado (TEG) para la

Gestión de Proyectos de TI, contempla los aspectos técnicos 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 gestión de proyectos de TI, sin contradecir el lineamiento corporativo de PDVSA de usar

�

��

las GGPIC como guía metodológica. En este sentido se mantuvo la base de esta

metodología, 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

metodología más completa, mejorada y adaptada a la realidad de los proyectos de

tecnología ejecutados por la gerencia DIS.

Asimismo, se validó la viabilidad de la implantación de la nueva metodología como

lineamiento estándar para la gestión de futuros proyectos del área de Tecnología de

Información, siendo considerada como factible por la Coordinación de Metodologías de la

Gerencia de Desarrollo e Implantación de Soluciones, por lo cual, finalmente se concluye,

que el diseño de una nueva metodología satisface una necesidad real de la organización y

se considera un aporte valioso para el desempeño de las funciones del equipo de trabajo.

Por último, se observa la limitación de no contar con el tiempo necesario para aplicar la

metodología diseñada en un nuevo proyecto de principio a fin, donde se podría evidenciar

con datos precisos, si el uso de ésta, favoreció la gestión del proyecto, observándose en

los resultados del mismo. Esta limitación 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 metodología propuesta como lineamiento estándar de gestión de

proyectos en la gerencia DIS, dada la previa validación y aceptación de la

Coordinación de Metodologías, organización facultada para tomar y ejecutar esta

decisión.

• Divulgar la metodología 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 metodología a todas las organizaciones de AIT, ya que la mayoría se

involucra de alguna manera u otra durante el ciclo de vida de un proyecto, así como

�

��

también, en casos excepcionales, se asigna la ejecución de un proyecto a

organizaciones diferentes a DIS.

• Seleccionar una muestra de los proyectos que estén próximos a comenzar, a los

cuales se les aplique la metodología 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 Portátil del Administrador de Proyectos. Ciudad de México. Ciudad de México, México: McGraw-Hill.

Castro, G. Proyectos Informáticos http://www.monografias.com/trabajos39/proyecto-

informatico/proyecto-informatico2.shtml, consultado el 10-06-2009. Gestión de la Configuración. (2007). Manual para el Taller de Dimensions. Caracas:

PDVSA. Documento mimeografiado. Gestión y Mejoramiento de Procesos. (2007). Diseño del Proceso Desarrollo e

Implantación de Soluciones. Caracas: PDVSA. http://es.wikipedia.org/wiki/Gestión_de_proyectos, consultado el 14/04/2009). http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/, consultado el 11-06-

2009. 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-08-

2009. http://www.pdvsa.com/, consultado el 14-04-2009. http://www.slideshare.net/dbaccess/pruebas-unitarias-uso-de-nunit-dentro-de-proyectos-

net, 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). Guías de Gerencia para Proyectos de Inversión de Capital. Caracas:

Autor. Documento mimeografiado. Planificación AIT. (2007). PDN AIT 2007-2013. Caracas: PDVSA. Planificación y Arquitectura. (2008). Presentación lineamientos estratégicos. Caracas:

PDVSA. Project Management Institute. (2004). Guía de los Fundamentos de la Dirección de

Proyectos (3° ed.). Estados Unidos, Pennsylvania: Autor. Rueda, J. (2006). Aplicación de la Metodología Rup para el Desarrollo Rápido de

Aplicaciones Basado en el Estándar J2EE. Tesis de pregrado no publicada, Universidad de San Carlos de Guatemala, Ciudad de Guatemala, Guatemala.

�

��

8. ANEXOS

�

��

Anexo N° 1: Clasificación de Estimados de Costo

Clase V Clase IV Clase III Clase II Clase I

Grado de

precisión 15% 30% 60% 80% 90%

Nota: Esta clasificación se aplica también a los estimados de tiempo de ejecución del

proyecto.

�

��

Anexo N° 2: Plantilla de Datos Básicos

Datos Básicos SOLICITANTE

Región: Filial: Área Funcional: Distrito/Localidad: Proceso Enmarcado en la cadena de valor del negocio:

Ámbito: � Internacional � Nacional � Regional

Ejemplo : Negocio => Recursos Humanos Cadena de Valor: Captación -> Desarrollo -> Educación. Proceso a estudiar : Educación

Prioridad: � Mandatario � Indispensable � Necesario � Diferible o deseable

Solicitante(s) Aprobador(es) Nombre y Apellido: Indicador: Teléfono:

Nombre y Apellido: Indicador: Teléfono:

Instructivo de llenado:

Región: Nombre de la región, 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 (Exploración y Producción, Refinación, Intevep, Gas, CVP, Corporativo) Área Funcional: Nombre de la función 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é, Maturín, Morichal, Tía Juana, Lagunillas, etc.) Ámbito: El ámbito del proyecto: nacional, internacional o regional, si es regional, especifique. Prioridad:

Mandatario: de máxima prioridad y a ser ejecutada sin dilaciones. Indispensable: Iniciativa con claro componente de valor, lo cual implica su programación en el actual ciclo de planificación Necesario: Casos de menor prioridad pero todavía a desarrollar en el ciclo de planificación actual. Diferible ó deseable: Casos con holgura para ser postergadas para posteriores ciclos de planificación.

Solicitante: Nombre, indicador y teléfono de la(s) persona(s) solicitante(s). Aprobador: Nombre, indicador y teléfono 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 colección 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. Además, estos procesos se hallan sujetos a un conjunto de reglas de

negocio, que determinan las políticas y la estructura de la información 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 extensión de UML que define

cuatro vistas estratégicas: visión, proceso, estructura y comportamiento.

VISTA DE VISIÓN DEL NEGOCIO �

En esta vista se establece “hacia donde va” el negocio y su estrategia global.

• Objetivo del Negocio

• Misión

• Visión

• Matriz DOFA

• Factores Críticos: Elementos necesarios para el crecimiento del negocio

• Estrategias: Planes de acción 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 más 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.

�

��

Patrón de referencia para definición de Procesos de Negocio:

Identificar el dominio del Proceso de Negocio en estudio: Unidades de Negocio, Procesos

y Sub-Procesos relacionados.

Modelado de proceso del negocio, donde se indiquen: entradas, salidas/productos,

procesos, actores de información (relaciones con otros sistemas/bases de datos),

participantes / usuario final, qué/quién regula el proceso, objetivo del proceso. Identifique

nuevas oportunidades o necesidades provenientes de la definición del proceso de

negocio.

cd Procesos EntornoEA 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









Control Interno deFinanzas

Finanzas Recursos Humanos

Gastos y Deudas deltrabajador

Aprobacion de Pagos Niv el AutoridadAdministrativ o y

Financiero

NóminaContabiliadad Tesorería

Logistica

Viajes y Traslado

Reserv acion y Serv iciosde Traslado

�

��

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.

�

�

VISTA DE COMPORTAMIENTO DEL PROCESO DE NEGOCIO En esta vista se representan los elementos dinámicos 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 notación UML.

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
















Recursos Humanos

Gastos y Deudas deltrabajador

Aprobacion de PagosNivel AutoridadAdministrativo y

Financiero

Nómina

Contabiliadad

<<objeto>>

Informacion del trabajador

<<objeto>>

-Centro de Costos-Cuentas de labor

<<objeto>>

Deducciones por deuda

<<objeto>>

Cadenas de aprobacion

<<objeto>>

Solicitud Autorizada

<<objeto>>

Solicitud Firmada

<<objeto>>

Movimientos contables

<<objeto>>

- Normas y Procedimientos Corporativos de Finanzas

<<objeto>>

-Documentos Descontados-Documentos No Descontados

Tesoreria <<objeto>>Numero de Transferencia (Nota de Debito)

Logistica

Reservacion yServicios de Traslado

<<objeto>>

-Informacion del trabajador-Ordenes internas-Cadenas de aprobacion

<<objeto>>

-Informacion de rutas-Informacion de proveedores

<<objeto>>

Archivo de pago de proveedores

Contabilidad (copia)

<<objeto>>

Ordenes de pago

«insumo»

«genera»

«insumo»

«suministra»

«suministra»

«insumo»

«insumo»

«salida»

«genera»

«insumo»

«Salida»

«suministra»

«Salida»

«insumo»

«insumo»

«suministra»

«regula»«genera»

«insumo»

«solicitud firmada» «genera»

«entrada»

«insumo»

«genera»

«insumo»

«suministra»

«genera»

«insumo»

«genera»

«insumo»

�

��

�

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, diseño y distribución de procesos de negocio, así como el control

ejecutivo, administrativo y supervisión de dichos procesos. DPN es una notación estándar

para modelar visualmente flujos de procesos, tiene como objetivo proveer notación común

para analistas del negocio que crean los flujos iniciales de los procesos y desarrolladores

de software responsables por tecnología e implementación de los procesos. DPN está

basado entre Diagramas de Actividad de UML y Diagramas de Flujo Actividad-Decisión y

especifica un único tipo de diagrama, DPN con un conjunto de elementos necesarios para

su elaboración. Estos elementos están divididos en cuatro categorías:

• Objetos del flujo: eventos, actividades, gateways

• Objetos de Conexión: flujo de secuencia, flujo de mensaje y asociación

• 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 información 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 están modelando

uno o más 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 construcción de aplicaciones. Los Casos de Uso del

�

�

Negocio describen como los procesos son llevados a cabo por personas y los activos de la

organización.

Los actores de este modelo pueden representar la figura de Componentes Funcionales

(módulo de software).

Diagramas de Caso de Uso del Negocio

A continuación 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.

Especificación de Caso de Uso del Negocio

El patrón para la especificación de Casos de Uso del Negocio (CUN)

�

��

CASO DE USO CUN.XX Título del CUN

FUENTES <Participantes que proporcionaron información de este CUN >

ACTOR Act.# <nombre de los actores> [(<Pseudónimos>)] [ – secundario]

DESCRIPCIÓN Act.# <Descripción del caso de uso de negocio>

FLUJO BÁSICO 3. Título del paso


4. Título del paso


FLUJOS ALTERNOS 3. Título del FA

Descripción del FA

4. Título del FA

Descripción del FA.

PRE CONDICIONES 2. Título del Precondición

Descripción del PRC

POST CONDICIONES 2. Título del Poscondiciones

Descripción de la PTC

REQUERIMIENTOS

ESPECIALES

1. Título del requerimiento

Descripción del requerimiento o porqué se enlaza a el desde este caso de uso

SUPOSICIONES 1. Título de la suposición

Descripción de la suposición

REGLA DE

NEGOCIOS

2. Título de la suposición

Descripción de la suposición

PUNTOS DE

INCLUSIÓN

1. Título del punto de inclusión

Descripción del punto de inclusión

PUNTOS DE

EXTENSIÓN

1. Título del punto de extensión

Descripción del punto de extensión

NOTAS 2. Título de la Nota

Descripción de la nota

Diagramas de Objetos del Negocio

Un objeto de negocios (ON) o business object es una representación mental de elementos

comúnmente utilizados en un dominio particular del negocio y cubre elementos de

diferentes tipos, tales como:

• Elementos físicos: Un producto, una planta, un empleado.

• Elementos de comunicación: Orden de pago, facturas, una orden de producción.

• Elementos de información: Capacidad de producción, inventario.

�

��

Identificación de los Componentes Funcionales

[Si aplica] Identificación y definición de Componentes Funcionales involucrados en el

Proceso de Negocio y las aplicaciones representativas de los Componentes Funcionales

Un componente de acuerdo a la especificación 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 términos de sus interfases proporcionadas y

requeridas.

Un módulo de software se puede representar como componente.

El Componente Funcional representa un tipo abstracto de aplicación de valor para el

negocio que puede estar instanciado por uno o más aplicaciones concretas.

Patrón para Componentes Funcionales del

Proceso de Negocio

COMPONENTE FUNCIONAL <nombre del Componente Funcional>

Ej.: Gateway de Pagos, Facturador, Recaudador, Nómina.

FUNCIONALIDADES REQUERIDAS

<descripción de la(s) funcionalidad(es) requeridas del

Componente Funcional para el proceso de negocio>

Ej: Aprobaciones financieras; Solicitud de Boletos; Realización

de pagos en línea con las entidades bancarias;

Aprovisionamiento de cuentas recurrentes; Gestión de cuentas

por pagar.

�

��

APLICACIÓN QUE CONSTITUYE EL

COMPONENTE FUNCIONAL

NIVEL DE SATISFACCIÓN APLICACIONES

Ej: NAAF; GADET; RESET. <Nivel de satisfacción de

los usuarios con la(s)

aplicación(es)

involucradas en la

migración>.

Esta información es

provista por VDU

ARQUITECTURA DEL COMPONENTE FUNCIONAL <arquitectura de hardware y software del Componente

Funcional>

Ej: Cliente/Servidor; Mainframe; Aplicación Web en contenedor

Web; Aplicación Web en Servidor de Aplicaciones.

AMBIENTE Ambientes que posee el Componente Funcional y/o Aplicación:

Desarrollo, QA y Producción

PROVEEDOR <Identificación del proveedor del Componente Funcional>

COSTOS LICENCIA <Descripción 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 comprensión del proceso funcional con la configuración de los

componentes de hardware, software y red que soportan el proceso de negocio.

El diagrama de despliegue permite representar la vista estática de la configuración de los

nodos de hardware y componentes de software, junto con el estereotipo de componentes,

apoya: 1. el diseño de la configuración de hardware y software para soportar el proceso de

negocio; 2. la exploración de aspectos relacionados con la ejecución del proceso de

negocio en ambientes de prueba y producción; 3. explorar las dependencias del proceso

de negocio con otros sistemas actualmente en producción o propuestos para ser

integrados con el proceso de negocio bajo estudio.

�

�

Identificación de Intercambios de Datos

�

[Si aplica] Identificación de intercambios de datos entre los componentes funcionales o

aplicaciones involucradas en el proceso de negocio.

�

Orden

[si aplica] Origen Destino Descripción Datos Intercambiados

Síncrono/

Asíncrono

1 Recaudador Gateway Pagos Envío de órdenes

de pago

Según definición Asíncrono

2 Gateway Pagos Recaudador Envío de pagos

cobrados


3 Gateway Pagos Recaudador Envío de pagos

rechazados


�

�

Reglas de Negocio

Las reglas de negocios representan una colección de políticas y restricciones de negocio

de una organización. Están divididas en tres tipos:

• Reglas de Restricción: especifican políticas o condiciones que restringen la

estructura y comportamiento de los objetos y procesos. Estas reglas pueden ser

divididas en reglas de estímulo-respuesta (que restringen el comportamiento y

especifican las condiciones que deben cumplirse para activar una operación),

reglas de restricción de operación (que especifican condiciones que deben

�

��

cumplirse antes y después de ejecutarse una operación) y reglas estructurales (que

especifican restricciones sobre los tipos de objetos y las asociaciones).

• Reglas de Derivación: especifican políticas y condiciones para inferir o calcular

hechos (información) a partir de otros hechos existentes en el negocio.

• Reglas de Existencia: que establecen cuándo puede existir un determinado

objeto.

RN-<ID> Tipo Descripción Ejemplo Observaciones

RN-01 Reglas de Restricción

Para entrar a la intranet de PDVSA, la

persona debe tener una cuenta y clave

de red.

�

��

Anexo N° 4: Gastos de Conceptualización

GASTOS DE CONCEPTUALIZACIÓN

Concepto Costos Contratos u

Órdenes de Servicio M

es 1

Mes

2

Mes

N

Centro de Costo

PROYECTO XXXX

PRUEBAS & ASSESSMENTS

Prueba de Conceptos & Assessment OPCIÓN 1



Prueba de Conceptos & Assessment OPCIÓN N

CONSULTORES EXTERNOS [Según tarifas base de PDVSA]

Analista P1

Analista P5

Concusltor Senior

Viáticos

Boletos [Debe estimarse la necesidad de viajes al interior del país]

Hospedaje

Licenciamiento [si aplica]

Licencias

Software

Infraestructura [Podría alquilarse un local sí no existiera espacio en PDVSA con el propósito de ejecutar las pruebas de concepto]

Alquiler de Local

Hardware [Debe estimarse si aplica]

Laptops

Impresoras & Scanners

Otros

Adiestramiento

Viáticos Empleados

Impuestos

Propinas

Llamadas

Hospedaje

Alimentación

Taxis

Estacionamiento

Refrigerios [Reuniones]

Gestión de Aprovisionamiento [Representa el 10% de los gastos, este fondo es sólo para cubrir emergencias y algún evento atípico]

TOTAL Bolívares (Bs) 0 0 0

TOTAL Bolívares Fuertes (BsF) 0 0 0

TOTAL EN US$ 0 0 0

�

�

Anexo N° 5: Planilla para solicitar recursos a MAP

Nombre del Sistema

Objetivo:

____________________________________________________________________________________

Gerente Responsable: Empresa:

Fecha de pase a producción:

Líder por AIT:

Aplicación:

Base de Datos:

Redes:

Seguridad Lógica:Servidores:

Proyecto:

Web:

Otro:

Características del Servidor(es) donde se va a instalar la aplicación:

Interfase con otras aplicaciones:

Intrerfaz con SAP/R3

Requiere mas de 1 servidor:

Localidad :

Sistema Operativo: Versión:

Memoria:

Paquete(s) requerido(s):

Espacio en disco: Estimación de crecimiento (GB):

Web: Extranet:

Manejador de Base de Datos:

Versión:

Nombre(s) de la(s) instancia(s) de BD: Vendors

Tipo de Servicio: Especifique: ___________ Criticidad:

Información de la Política de Respaldo

Política de Respaldo:

Política de Retención: ______________________________

Data a Respaldar: Toda la base de datos

___________________________________________________________________________________

INFORMACION TECNICA

Puesta en Producción de un ServicioFecha:

IDENTIFICACION DEL SISTEMA / APLICACIÓN

CONTACTOS

____________________________________________________________________________________

��

��

��

��

��

��

��

UNIVERSIDAD SIMON BOLIVAR

DECANATO DE ESTUDIOS DE POSTGRADO NOMBRE DEL ESTUDIANTE: Lina Titania Arias Moreno

TITULO DE LA TESIS: Gestión de Proyectos de Tecnologías de Información en la Gerencia DIS

NOMBRE DEL ASESOR: Josselyn Ávila

MIEMBROS DEL JURADO: Andrés Loriente

PALABRAS CLAVES: Gestión de Proyectos, Tecnología de Información, Metodología de Gestión de Proyectos de Tecnología de Información, Proyectos

SOBRESALIENTE: GRADUADO CON HONORES:

Nº DE PAGS: 139 FECHA DE GRADUACIÓN: Feb - 2010

ESPECIALIZACIÓN EN: Gerencia de Proyectos

RESUMEN El propósito del presente trabajo fue apoyar la gestión de proyectos de Automatización, Informática y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e Implantación de Soluciones (DIS) de PDVSA, para esto se diseñó una Metodología de Gestión de Proyectos de Tecnología de Información (TI), basada en las Guías de Gerencia para Proyectos de Inversión de Capital (GGPIC), estándar de la corporación. En primer lugar se realizó un análisis de la situación actual para identificar la aplicabilidad de las GGPIC, en los proyectos de Tecnología de Información. Posteriormente, y en base a las mejores prácticas de metodologías propias para la ejecución de proyectos de TI como los son RUP y UML, en conjunto con las fortalezas de las GGPIC, se elaboró la propuesta de diseño de una nueva metodología para ser usada en la Gerencia (DIS) facilitando el trabajo de los líderes, responsables por la gestión de los proyectos de Tecnologías de Información. La propuesta fue validada y recibida de forma muy positiva por la Coordinación de Metodologías de DIS por lo cual se puede decir que se generó como resultado una metodología para la gestión de proyectos de TI, mucho más completa y acorde a la realidad de este tipo de proyectos debido a la incorporación de todos los elementos técnicos necesarios para lograr una definición adecuada de los mismos, que permiten a su vez su correcto desarrollo y puesta en marcha, así como también fueron incluidas las actividades, mas allá de las propiamente técnicas, sino de procesos que hay que cumplir, donde se interactúa con otras organizaciones de AIT y de PDVSA, constituyendo esto una herramienta muy útil para los líderes de proyecto y para la organización de Desarrollo e Implantación de Soluciones, apalancando a su vez la misión de AIT.

GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE …159.90.80.55/tesis/000150367.pdfCONCLUSIONES DEL EXAMEN...

Documents

Transcript of GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE …159.90.80.55/tesis/000150367.pdfCONCLUSIONES DEL EXAMEN...