GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE …159.90.80.55/tesis/000150367.pdfCONCLUSIONES DEL EXAMEN...
Transcript of 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
�
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS DE POSTGRADO COORDINACIÓN DE POSTGRADOS EN GERENCIA ESPECIALIZACIÓN EN GERENCIA DE PROYECTOS
GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN EN LA GERENCIA DIS
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
�
��
�
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS DE POSTGRADO COORDINACIÓN DE POSTGRADOS EN GERENCIA ESPECIALIZACIÓN EN GERENCIA DE PROYECTOS
GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN EN LA GERENCIA DIS
Por: Lina Titania Arias Moreno
Carnet No.: 0786152
Este Trabajo Especial de Grado ha sido aprobado en nombre de la
Universidad Simón Bolívar por el siguiente jurado examinador:
Jurado
Andrés Loriente
Tutora
Josselyn Ávila (PDVSA)
28 de octubre de 2009
�
���
�
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS DE POSTGRADO COORDINACIÓN DE POSTGRADOS EN GERENCIA ESPECIALIZACIÓN EN GERENCIA DE PROYECTOS
GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN EN LA GERENCIA DIS
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
Respuesta de Solicitud de Aprobación del DSD3
Respuesta de Solicitud de Aprobación del DSD4
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
Aplica medianamente en royectos de TI, puesto quie los mismos no necesariamente se contratan a terceros.
Revisión y firma del contrato X
Aplica medianamente en royectos de TI, puesto quie los mismos no necesariamente se contratan a terceros.
Administración del contrato X
Aplica medianamente en royectos de TI, puesto quie los mismos no necesariamente se contratan a terceros.
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. Realizar Resumen Ejecutivo
�
��
5.4.2.2.1.1. Definir Objetivo de la Fase Conceptualizar
Indicar cual es la finalidad de esta fase, que se logrará al completarla.
5.4.2.2.1.2. Definir Antecedentes (actualizar)
5.4.2.2.1.3. Definir 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
Descripción 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)
5.4.2.3. Entrega de DSD2
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.
5.4.3.1. Conformar Equipo de Trabajo
• Incorporar nuevo personal de proyectos al equipo
• Definir el Organigrama/Roles y Responsabilidades para el equipo
• Identificar equipos de apoyo
5.4.3.2. Desarrollo del DSD3
5.4.3.2.1. Definir Objetivos de la Fase Definir
Indicar cual es la finalidad de esta fase, que se logrará al completarla.
5.4.3.2.2. Definir Antecedentes (actualizar)
5.4.3.2.3. Definir 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.3.3. Entrega de DSD3
• Revisión del DSD3.
• Aceptación del DSD3.
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.
5.4.4.4. Conformar Equipo de Trabajo
En esta fase, la actividad conformar equipo de trabajo, es mas extensa y detallada, ya que
se trata del equipo que 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. Desarrollo del DSD4
5.4.4.5.1. Realizar Resumen Ejecutivo
5.4.4.5.1.1. Definir Objetivos de la Fase Implantar
Indicar cual es la finalidad de esta fase, qué se logrará al completarla.
5.4.4.5.1.2. Definir Antecedentes (actualizar)
5.4.4.5.1.3. Definir 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.4.6. Entrega de DSD4
• Revisión del DSD4.
• Aceptación del DSD2.
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
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version 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
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
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
Descripción del paso.
4. Título del paso
Descripción 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
Según definición Asíncrono
3 Gateway Pagos Recaudador Envío de pagos
rechazados
Según definición Asíncrono
�
�
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 2
Prueba de Conceptos & Assessment OPCIÓN 3
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.