TESIS DE GESTION DE PROYECTO

8/17/2019 TESIS DE GESTION DE PROYECTO

1/140

UNIVERSIDAD SIMÓN BOLÍVARDECANATO DE ESTUDIOS DE POSTGRADO

COORDINACIÓN DE POSTGRADOS EN GERENCIAESPECIALIZACIÓN EN GERENCIA DE PROYECTOS

TRABAJO ESPECIAL DE GRADO

GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN ENLA GERENCIA DIS

por

LINA TITANIA ARIAS MORENO

Octubre de 2009


2/140




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 ScientiarumJOSSELYN AVILA

Octubre de 2009


3/140




Por: Lina Titania Arias MorenoCarnet 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

TutoraJosselyn Ávila (PDVSA)

28 de octubre de 2009


4/140




Por: Lina Titania Arias MorenoCarnet No.: 0786152Tutora: Josselyn ÁvilaFecha: 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 deSoluciones (DIS) de PDVSA, para esto se diseñó una Metodología de Gestión deProyectos de Tecnología de Información (TI), basada en las Guías de Gerencia paraProyectos 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 aplicabilidadde las GGPIC, en los proyectos de Tecnología de Información. Posteriormente, y en basea las mejores prácticas de metodologías propias para la ejecución de proyectos de TIcomo 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 deTecnologías de Información.La propuesta fue validada y recibida de forma muy positiva por la Coordinación deMetodologías de DIS por lo cual se puede decir que se generó como resultado unametodología para la gestión de proyectos de TI, mucho más completa y acorde a larealidad de este tipo de proyectos debido a la incorporación de todos los elementostécnicos necesarios para lograr una definición adecuada de los mismos, que permiten a suvez su correcto desarrollo y puesta en marcha, así como también fueron incluidas lasactividades, 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 unaherramienta 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ónde Proyectos de Tecnología de Información, Proyectos


5/140

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


6/140

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


7/140

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ÍADE 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 DEINFORMACIÓ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


8/140

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


9/140

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


10/140

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


11/140

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


12/140

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 fueplanificado 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.


13/140

CAPITULO IEl 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


14/140

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 laGestió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:


15/140

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 deInformació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 mismasfrente 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)


16/140

(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 procesoobjeto 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.


17/140

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


18/140

2. CAPITULO IIMARCO 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.


19/140

• 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 pocaslas probabilidades de éxito.

Fig. 1 La Triple restricción

Se considera que en los proyectos el esfuerzo es “temporal” porque tienen un comienzo yun 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.


20/140

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:


21/140

• 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 laempresa.

• 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


22/140

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.


23/140

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


24/140

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 decomunicació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.


25/140

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 denuevos 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 queincluye 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.


26/140

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


27/140

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 delcumplimiento 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


28/140

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 gestadaen 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


29/140

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


30/140

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 Definir2.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


31/140


32/140

“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 el11-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


33/140

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ónconduce 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 laprogramació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.


34/140

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 RationalRose, 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.


35/140

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ólodurante 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:


36/140

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) quecomponen 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.


37/140

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


38/140

• 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 iteracionestempranas, 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:


39/140

• 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 relacionadirectamente 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ñosavances 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.


40/140

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


41/140

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.


42/140

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 comprendenlos 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álisisde 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.


43/140

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., yaseguran 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.


44/140

• 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.


45/140

3. CAPÍTULO IIIMARCO 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.

TESIS DE GESTION DE PROYECTO

Documents

Transcript of TESIS DE GESTION DE PROYECTO