Documentos de Académico
Documentos de Profesional
Documentos de Cultura
por
Octubre de 2009
Octubre de 2009
Jurado
Andrs Loriente
Tutora
Josselyn vila (PDVSA)
28 de octubre de 2009
INDICE
INTRODUCCIN ....................................................................................................................1
CAPITULO I ............................................................................................................................3
EL PROYECTO DE TRABAJO ESPECIAL DE GRADO .....................................................3
1.1.
JUSTIFICACION.................................................................................................................................... 3
CRONOGRAMA DE EJECUCION......................................................................................................... 7
2.
CAPITULO II ..................................................................................................................8
PROYECTO........................................................................................................................................... 8
2.2.
GESTIN DE PROYECTOS................................................................................................................ 10
3.
MARCO ORGANIZACIONAL.............................................................................................. 35
3.1. PETRLEOS DE VENEZUELA (PDVSA) ........................................................................................... 35
3.1.1. Descripcin Ampliada de la Empresa............................................................................................ 35
3.1.2. El Plan Siembra Petrolera (PSP) 2005-2030 ................................................................................ 39
3.1.2.1.
Magna Reserva...................................................................................................................... 39
3.1.2.2.
Proyecto Orinoco ................................................................................................................... 39
3.1.2.3.
Proyecto Delta-Caribe............................................................................................................ 40
3.1.2.4.
Refinacin.............................................................................................................................. 40
3.1.2.5.
Infraestructura........................................................................................................................ 40
3.1.2.6.
Integracin ............................................................................................................................. 40
3.2. AUTOMATIZACIN, INFORMTICA Y TELECOMUNICACIONES (AIT) .......................................... 41
3.2.1. Breve Histrico.............................................................................................................................. 41
3.2.2. Visin ............................................................................................................................................ 42
3.2.3. Misin ........................................................................................................................................... 42
3.2.4. Objetivos Estratgicos .................................................................................................................. 42
3.3. DESARROLLO E IMPLANTACIN DE SOLUCIONES (DIS)............................................................. 44
3.3.1. Objetivo......................................................................................................................................... 44
3.3.2. Alcance ......................................................................................................................................... 44
3.3.3. Premisas ....................................................................................................................................... 45
3.3.4. Diagrama Macro Interfuncional del Proceso ................................................................................. 45
4.
CAPTULO IV.............................................................................................................. 47
4.2.
4.3.
4.4.
4.5.
5.
CAPTULO V............................................................................................................... 53
5.2.
5.3.
6.
6.3.
6.4.
6.5.
7.
7.2.
8.
INDICE DE TABLAS
Tabla 1 Cronograma de Ejecucin del Proyecto
Tabla 2 Esfuerzo vs. Fases RUP
Tabla 3 Aplicabilidad de las GGPIC en Proyectos de TI
Tabla 4 Atributos de Priorizacin
Tabla 5 Valores de Atributos para Prioridad del Cliente
Tabla 6 Valores de Atributos para Complejidad
Tabla 7 Valores de Atributos para Esfuerzo
Tabla 8 Valores de Atributos para Estabilidad
Tabla 9 Ejemplo de Caractersticas Generales de la Solucin TI
Tabla 10 Identificacin de Servicios
Tabla 11 Identificacin de Intercambio de Datos
Tabla 12 Especificacin de Servicios
Tabla 13 Especificacin de Funcionalidad de Servicios
Tabla 14 Contenido de un Contrato de Servicios
Tabla 15 Descripcin de Actores
Tabla 16 Especificacin de Casos de Uso
Tabla 17 Requerimientos de Informacin
Tabla 18 Requerimientos No Funcionales
Tabla 19 Prueba de Aceptacin
Tabla 20 Plan de Desembolsos por Productos
INDICE DE FIGURAS
Fig. 1 La Triple restriccin................................................................................................................................. 9
Fig. 2 Ciclo de Vida de Proyectos segn las GGPIC ...................................................................................... 17
Fig. 3 Fase Visualizar ..................................................................................................................................... 18
Fig. 4 Fase Conceptualizar ............................................................................................................................. 19
Fig. 5 Fase Definir .......................................................................................................................................... 20
Fig. 6 Fase Implantar ...................................................................................................................................... 20
Fig. 7 Fase Operar.......................................................................................................................................... 21
Fig. 8 Programacin Tradicional ..................................................................................................................... 22
Fig. 9 Partes de un Modelo UML .................................................................................................................... 26
Fig. 10 Proceso Unificado Rational................................................................................................................. 28
Fig. 11 Tiempo y Esfuerzo vs. Fases de RUP ................................................................................................ 31
Fig. 12 Modelo de Procesos AIT..................................................................................................................... 42
Fig. 13 Diagrama Macro Interfuncional del Proceso DIS ................................................................................ 46
Fig. 14 Fases GGPIC vs. Fases RUP............................................................................................................. 55
Fig. 15 El Proceso de la Toma de Decisin .................................................................................................... 58
Fig. 16 Diagrama de Secuencia...................................................................................................................... 65
Fig. 17 Modelo de Casos de Uso.................................................................................................................... 75
Fig. 18 Ejemplo Diseo de Arquitectura.......................................................................................................... 84
Fig. 19 Ejemplo de Diagrama de Clase .......................................................................................................... 86
Fig. 20 Ejemplo Modelo E-R ........................................................................................................................... 87
Fig. 21 Contenido Tpico de un DSO .............................................................................................................. 92
INTRODUCCIN
La gerencia de proyectos data de hace mas de 4.000 aos, donde de manera emprica o,
si se puede decir, informal, se aplic en la construccin de grandes obras como lo fueron
las pirmides de Egipto; pero es solo hace poco mas de 50 aos, cuando la gerencia de
proyectos surge como ciencia y se le ha dado la importancia que amerita en la
consecucin de objetivos cuando se tiene un tiempo, un costo y un alcance claramente
definidos, con una calidad especificada, es decir, cuando la actividad debe acometerse
como un proyecto.
Con el presente Trabajo Especial de Grado (TEG) se pretende disear una metodologa
de gestin de proyectos de Tecnologa de Informacin, que apoye la gestin de la
organizacin Desarrollo e Implantacin de Soluciones, incorporando todos los elementos
tcnicos y de procesos necesarios para complementar las GGPIC, de forma tal que sea
considerada como una herramienta til a ser implantada con el fin de mejorar los
Fase de Planificacin: est compuesta por el captulo I donde se aprecia como fue
planificado el proyecto de TEG, su justificacin, objetivos de estudio, metodologas para
elaborar el marco conceptual, marco organizacional, examen de la situacin, elaboracin
de la propuesta, evaluacin de la misma y del proceso general cumplido, as como el
cronograma de ejecucin.
Fase de Ejecucin: esta fase presenta el captulo II, marco conceptual referencial donde
se encuentran los fundamentos conceptuales pertinentes al caso de estudio; el captulo III
que contiene el marco organizacional, lo cual permite conocer el mbito donde se aplicar
la propuesta del TEG; el captulo IV que permite observar como se llevar a cabo el
examen de la situacin, destacando el objetivo del proceso, su planificacin, ejecucin,
resultados y conclusiones de dicho examen; el captulo V donde destaca la propuesta del
TEG, su justificacin, objetivo, proceso de elaboracin, para finalmente concluir con la
propuesta.
CAPITULO I
El PROYECTO DE TRABAJO ESPECIAL DE GRADO
En las pginas siguientes se expone el Proyecto de Trabajo Especial de Grado presentado
a las instancias correspondientes. Se expone la justificacin, los objetivos, la metodologa
establecida, concluyendo con el cronograma de ejecucin.
1.1.
JUSTIFICACION
(Gestin y
Mejoramiento de Procesos, 2007), por esta razn es de vital importancia contar con una
metodologa de Gestin de Proyectos que apoye esta funcin de manera eficaz.
El lineamiento corporativo indica que AIT debe usar para la Gestin de Proyectos la Gua
de Gerencia para Proyectos de Inversin de Capital (GGPIC), esta gua fue diseada por
un grupo de ingenieros de PDVSA en 1999, y, aunque son adaptables a varios tipos de
proyectos, fueron creadas principalmente desde la perspectiva de proyectos de Ingeniera
y Construccin.
Pareciera entonces que la Gerencia DIS no contara con la metodologa apropiada para la
Gestin de Proyectos del rea de su competencia, es decir, de Tecnologa de Informacin
(TI).
1.2.
En ese contexto, como objetivos del Proyecto de Trabajo Especial de Grado se formularon
los siguientes:
1.2.1.
General
1.2.2.
Especficos
GGPIC,
para
proyectos
de
Automatizacin,
Informtica
1.3.
METODOLOGA
Para el logro de los objetivos propuestos se estableci cumplir los siguientes pasos:
1.3.1.
Inicialmente se expondran los conceptos bsicos del ciclo de vida de los proyectos de
acuerdo a las Guas de Gerencia para Proyectos de Inversin de Capital (GGPIC)
(PDVSA, 1999). Luego, utilizando las referencias bibliogrficas sobre el Proceso Unificado
Rational
(RUP)
(http://es.wikipedia.org/wiki/RUP#Ciclo_de_vida),
(http://www-
UML
(http://es.wikipedia.org/wiki/UML)
(http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php),(ISCA,
2006);
se
1.3.2.
1.3.3.
1.3.4.
Elaboracin de la Propuesta
1.3.5.
1.3.6.
de Grado,
se analizara la
1.4.
CRONOGRAMA DE EJECUCION.
2. CAPITULO II
MARCO CONCEPTUAL REFERENCIAL
Para entender la necesidad existente de una metodologa de gestin de proyectos de TI,
es importante sealar los conceptos bsicos de proyecto, gestin de proyectos, tecnologa
de informacin (TI), gestin de proyectos de TI, Guas de Gerencia de Proyectos de
Inversin de Capital (GGPIC), metodologa Rational del Proceso Unificado o Rational
Unified Process (RUP), Tecnologa de Objetos y Lenguaje de Modelado Unificado o
Unified Modeling Language (UML). Conociendo brevemente estos conceptos, se contar
con el contexto necesario para apreciar el resultado del presente Trabajo Especial de
Grado.
2.1.
PROYECTO
Segn Kerzner (2001) un proyecto puede ser considerado como una serie de actividades y
tareas que:
Se puede decir entonces, habida cuenta de las coincidencias de los conceptos sealados
anteriormente, que un proyecto es un conjunto de actividades lgicamente relacionadas
que se llevan a cabo para cumplir unos objetivos y producir un resultado nico, dentro del
tiempo, costo y con el alcance y calidad especificados, a estas tres caractersticas se les
conoce como la triple restriccin (Fig. 1), dichas restricciones se encuentran en todos los
proyectos; en el mejor de los casos, debe haber limitaciones en dos de los aspectos y uno
debe ser negociable, si hay limitaciones estrictas en las tres restricciones son muy pocas
las probabilidades de xito.
Los resultados son nicos, pues cada proyecto, aunque parezca repetitivo, como en el
caso de la construccin de edificios, tiene sus propias caractersticas. En el ejemplo de la
construccin se manifiesta la singularidad de los proyectos, ya que, aunque se trate de
construir edificios, cada uno de ellos puede diferir en diversos aspectos, como el
propietario, el presupuesto, la ubicacin, el terreno, etc.
Como punto importante para concluir el concepto de proyectos, debe decirse que la
ejecucin de los mismos debe ser gradual, puesto que al inicio solo se tiene una visin
general de lo que ser el alcance del proyecto, el cual se va afinando a medida que se
avanza en las primeras etapas, sin que esto signifique que deban existir constantes
cambios de alcance, sino que se especifica en mas detalle y se entienden con mas
claridad cuales sern los resultados que se pretenden obtener.
2.2.
GESTIN DE PROYECTOS
Aunque la direccin de proyectos tiene una antigedad de al menos 4.500 aos, hasta
muy recientemente no ha sido reconocido el papel del director de proyectos como
disciplina por derecho propio, sin embargo, hoy en da hay incluso universidades que
dictan cursos de proyectos a nivel de doctorado.
Algunos factores clave que determinan el xito de un proyecto segn Clealand y Ireland
(2001) son:
Los resultados generales del proyecto culminan a tiempo y dentro del presupuesto.
Los resultados del proyecto se han entregado al cliente, quien considera que el
proyecto se adapta adecuadamente a la misin, los objetivos y los propsitos de la
empresa.
Los beneficiarios del proyecto se sienten satisfechos con el modo en que ste se
administr y con los resultados obtenidos.
Los integrantes del equipo del proyecto creen que su participacin fue una
experiencia valiosa para ellos.
El trabajo del proyecto produjo algunos avances tecnolgicos que prometen dar a la
empresa una ventaja frente a sus competidores.
Para que estos factores estn presentes en los proyectos, es indispensable una adecuada
gestin durante su ejecucin. Por esto es importante conocer que la gestin de proyectos
es:
Todo esto con la finalidad de ejecutar el proyecto en el menor tiempo posible, al ms bajo
costo y con la calidad requerida, es decir, dentro de los parmetros de la triple restriccin,
en un ambiente de trabajo seguro, armnico y cordial.
Se trata entonces de una mezcla entre arte y ciencia: es el arte de conseguir que todas las
actividades de un proyecto se realicen satisfactoriamente con un grupo multidisciplinario y
heterogneo de profesionales y trabajadores; y es una ciencia porque se maneja una gran
cantidad de informacin necesaria para planificar y controlar el trabajo con el fin de
mantener un balance entre el tiempo de ejecucin y los costos, evitando as una demanda
excesiva y desorganizada de recursos.
Lo cierto es que el Lder del Proyecto es el responsable de alcanzar los objetivos del
mismo, por lo tanto, entre otras cosas, segn el Project Management Institute (2004) el
lder debe:
La gestin por si sola no garantiza el xito de los proyectos, para que haya una buena
gestin es necesario contar con un buen lder de proyectos que tenga las siguientes
pericias:
Sin duda, una buena aplicacin de la Gestin de Proyectos en manos de un buen Lder de
Proyectos, aumenta considerablemente las probabilidades de xito de los mismos.
2.3.
Un
concepto
de
Tecnologa
de
Informacin
segn
http://www.ntn-
consultores.com/paginas/tecnologia.htm:
de
informacin,
especficamente
la
captura,
transformacin,
2.3.1.
mejor
su
tiempo
en
actividades
que
agregan
ms
valor
A medida que los precios de los equipos de computacin bajan, su capacidad aumenta, y
se hacen ms fciles de usar, la TI se utiliza en nuevas y variadas formas. En las
empresas, sus aplicaciones son diversas. Hoy en da, la mayora de las empresas
medianas y grandes (y cada da ms pequeas y micro-empresas) utilizan la TI para
gestionar casi todos los aspectos del negocio, especialmente el manejo de los registros
financieros y transaccionales de las organizaciones, registros de empleados, facturacin,
cobranza, pagos, compras, y mucho ms.
2.4.
GESTIN DE PROYECTOS DE TI
Negocio estratgico.
Globalizacin.
Arquitectura de la informacin.
El proyecto de TI debe ser entendido como una decisin estratgica de la empresa, bien
como consecuencia de una necesidad de informatizar una tarea o bien para mejorarla, por
propia evolucin o por cambios estratgicos.
son
(http://www.monografias.com/trabajos39/proyecto-informatico/proyecto-
Fsicos
Sistema central
Perifricos
Comunicaciones
Lgicos
Estructuras de almacenamiento
Monitores de comunicaciones
Lenguajes
Utilidades
Mtodos de desarrollo
Control de seguridad y desarrollo
Humanos
Seleccin
Formacin
Incentivacin
2.5.
Las Guas de Gerencia para Proyectos de Inversin de Capital son unas guas que
contienen lineamientos prcticos para la ejecucin de un proyecto de una manera
normalizada en nuestro sistema y ordenada, de modo que ningn detalle y/o paso
importante se nos escape, y as garantizar, con un alto grado de confianza, que los
proyectos sean exitosos y cumplan con los requisitos de la Corporacin (PDVSA, 1999).
Las GGPIC, son utilizadas en PDVSA como lineamiento Corporativo para la gestin de
proyectos, las mismas abarcan:
2.5.1.
La idea de estas guas es resumir y englobar una serie de reglas y prcticas de gerencia
que permita a los participantes del proyecto conducirse exitosamente a travs de todas las
fases, desde su visualizacin hasta la entrega de las instalaciones a los grupos
operacionales; y asegurarse de que se agoten todas las instancias debidas y establecidas
antes de pasar de una fase a la prxima y acometer costos adicionales (PDVSA, 1999).
2.5.2.
Segn las GGPIC, el ciclo de vida de los proyectos est constituido por cinco fases las
cuales se muestran esquemticamente en la siguiente figura:
2.5.3.
Para conocer en trminos generales en qu consisten las fases del ciclo de vida de
proyectos segn las GGPIC, se dar una breve descripcin de cada una de ellas, y se
representar de manera grfica las principales actividades abarcadas en cada caso.
2.5.3.1.
Visualizar
Esta es la fase donde se inician los proyectos, que pueden provenir de una idea gestada
en cualquier parte de la Corporacin, a raz de un anlisis externo/interno, o de un anlisis
de Fortalezas, Oportunidades, Debilidades, Amenazas (FODA), que son realizados como
parte de los ciclos de planificacin.
2.5.3.2.
Conceptualizar
Seleccionar la(s) opcin(es) preferida(s) y solicitar los fondos para ejecutar las
actividades que permitan obtener un estimado de costo clase II (ver anexo N 1).
Definir
En esta fase del ciclo de vida de los proyectos segn las GGPIC se trabaja
fundamentalmente en una definicin detallada del alcance, al igual que en la planificacin
tanto en tiempo como en costos con un nivel de precisin clase II, de la ejecucin de la
opcin de solucin seleccionada; esta fase es determinante ya que es aqu donde deben
solicitarse los fondos o el financiamiento requerido para ejecutar el proyecto.
Para llevar a cabo esta fase es necesario completar las siguientes acciones:
Implantar
Una vez culminada la fase definir, si se obtuvo la aprobacin del proyecto y de los fondos,
se procede con la materializacin de la idea, dando como resultado unas instalaciones
listas para entrar en servicio.
2.5.3.5.
Operar
En esta transicin ocurre un solapamiento ya que en esta fase se le deben dar los toques
finales a la construccin, es decir, completar la lista de pendientes que pueda tener el
proyecto. Posteriormente se realizan las pruebas y la aceptacin de las instalaciones, para
culminar con los informes finales de cierre del proyecto.
Las acciones necesarias para lograr esta fase y finalmente concluir el proyecto son:
2.6.
TECNOLOGA DE OBJETOS
Segn http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ (consultado el 1106-2009), tradicionalmente, la programacin fue hecha en una manera secuencial o lineal,
es decir, una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.
La creciente tendencia de crear programas cada vez ms grandes y complejos llev a los
desarrolladores a crear una nueva forma de programar que les permite crear sistemas de
niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades
ya no bastaba la programacin estructurada ni mucho menos la programacin lineal. Es
as como aparece la Programacin Orientada a Objetos (POO). La POO viene de la
evolucin de la programacin estructurada; bsicamente la POO simplifica la
programacin con la nueva filosofa y nuevos conceptos que tiene. La POO se basa en
dividir el programa en pequeas unidades lgicas de cdigo. A estas pequeas unidades
lgicas de cdigo se les llama objetos. Los objetos son unidades independientes que se
comunican entre ellos mediante mensajes.
2.6.2.
2.6.3.
El modelamiento visual es la clave para realizar el anlisis orientado a objeto (OO). Desde
los inicios del desarrollo de software OO han existido diferentes metodologas para hacer
el modelamiento, pero sin lugar a duda, el Lenguaje de Modelado Unificado (UML) puso
fin a la guerra de metodologas.
Segn los mismos diseadores del lenguaje UML, ste tiene como fin modelar cualquier
tipo de sistemas (no solamente de software) usando los conceptos de la orientacin a
objetos. Y adems, este lenguaje debe ser entendible para los humanos y las mquinas.
El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en
base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se
construyen en forma correcta, son fciles de comunicar, cambiar, expandir, validar y
verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes
plenamente reutilizables, en la seccin siguiente se hablar con ms detalle de UML.
2.7.
2.7.1.
Para la construccin de modelos, hay que centrarse en los detalles relevantes mientras se
ignoran los dems, por lo cual con un nico modelo no se tiene suficiente (Rueda, 2006).
2.7.2.
Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho
sistema, considerando un cierto propsito. As, el modelo describe completamente
aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un
apropiado nivel de detalle. (Rueda, 2006)
Segn Rueda, varios modelos aportan diferentes vistas de un sistema los cuales nos
ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de nueve
diagramas que, para representar las distintas vistas de un sistema, son muy tiles. Estos
diagramas de UML se presentan en la figura N 9 y se describen a continuacin:
2.7.2.2.
Diagrama de Clases
Muestra las clases (descripciones de objetos que comparten caractersticas comunes) que
componen el sistema y cmo se relacionan entre s.
2.7.2.3.
Diagrama de Objetos
2.7.2.4.
Diagramas de Comportamiento
2.7.2.5.
Diagramas de implementacin
La metodologa de modelado UML, por ser estndar, es utilizada por la metodologa para
desarrollo de soluciones de tecnologas de informacin Rational Unified Process (RUP),
de la cual se hablar brevemente a continuacin.
2.8.
Las siglas RUP en ingls significan Rational Unified Process (Proceso Unificado de
Rational). RUP es un producto del proceso de ingeniera de software que proporciona un
enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin
de desarrollo de software (http://www.liderdeproyecto.com/metodologias/index.html,
consultado el 11-06-2009). La meta de RUP es asegurar la produccin del software de alta
calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo
establecidos. El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso.
Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:
Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los
Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los
artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la
implementacin de las fases y disciplinas del RUP. Un Caso de Uso es una
secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona
directamente con los requerimientos, ya que un Caso de Uso es la secuencia de
pasos que conlleva la realizacin e implementacin de un requerimiento planteado
por el Cliente.
2.8.1.
2.8.1.1.
Inicio
2.8.1.2.
Preparacin
2.8.1.3.
Construccin
Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu
refinada de manera incremental conforme se construye.
2.8.1.4.
Transicin
Todas las fases no son idnticas en trminos de tiempo y esfuerzo. Aunque esto vara
considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para un
proyecto de tamao mediano debe anticipar la distribucin del esfuerzo como sigue:
Esfuerzo
Inicio
Preparacin
Construccin
Transicin
~5 %
20 %
65 %
10%
Dimensin 2: Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para
la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias
y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de TI,
aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:
Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas,
Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las
primarias y especifican otras caractersticas en la realizacin de un proyecto de TI; entre
estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A
continuacin se describen brevemente cada una de estas disciplinas.
2.8.2.1.
2.8.2.2.
Requerimientos
Los requerimientos establecen lo que el sistema debe hacer (especificar requisitos), definir
los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y
tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden
los CU, Actores y Relaciones, adems utiliza los Diagramas de Estado de cada CU y las
especificaciones suplementarias.
2.8.2.3.
Anlisis y Diseo
2.8.2.4.
Implementacin
Esta disciplina tiene como objetivos implementar las clases de diseo como componentes
(ej. fichero fuente), asignar los componentes a los nodos, probar los componentes
individualmente,
integrar
los
componentes
en
un
sistema
ejecutable
(enfoque
para
comprender
cmo
se
organizan
los
componentes
su
interdependencia.
2.8.2.5.
Pruebas
2.8.2.6.
Despliegue
Durante el despliegue se tienen como objetivos asegurar que el producto est preparado
para la entrega y recepcin por parte del cliente. En esta disciplina se realizan las
actividades de probar la nueva solucin de TI en su entorno final (Prueba Beta),
empaquetarlo, distribuirlo e instalarlo, as como la tarea de adiestrar al usuario.
2.8.2.7.
2.8.2.8.
Administrar proyectos.
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.
3. CAPTULO III
MARCO ORGANIZACIONAL
Es importante conocer el marco organizacional en el cual ser implantado el resultado del
presente Trabajo Especial de Grado, para ello se presentar la organizacin de lo general
a lo especfico de manera jerrquica, se presentar en primer lugar a Petrleos de
Venezuela (PDVSA), sus caractersticas y razn de ser, posteriormente se resear la
organizacin Automatizacin, Informtica y Telecomunicaciones (AIT), y por ltimo se
describirn las funciones de la Organizacin Desarrollo e Implantacin de Soluciones
dnde ser propuesta la utilizacin de la metodologa que se desarrollar en este trabajo.
3.1.
3.1.1.
Durante el primer ao de operacin, PDVSA inici sus acciones con 14 filiales, de las
cuales posteriormente quedaran operando solo tres: Lagoven, Maraven y Corpoven, que
absorbieron las actividades de las concesionarias que estaban en Venezuela. Para aquel
ao, se mantiene la produccin de crudo en 2,3 millones de barriles diarios. Las
inversiones iniciales se sitan en un principio en 1.200 millones de bolvares. Ya en 1978,
las inversiones de capital se haban cuadruplicado y se ubicaban en 5.000 millones de
bolvares.
Dentro de esta fase, inicia acciones en 1976, el Instituto Tecnolgico Venezolano del
Petrleo (Intevep), destinado a efectuar los estudios e investigaciones necesarias para
garantizar el alto nivel de los productos y procesos dentro de la industria petrolera.
Igualmente, dos aos despus se crea Petroqumica de Venezuela S.A. (Pequiven),
dirigida a organizar el negocio de la produccin petroqumica.
Luego de cinco aos de puesta en marcha del decreto que cre a Petrleos de Venezuela,
PDVSA y sus filiales logran avanzar en un proceso de consolidacin en lo que respecta al
manejo del negocio petrolero. As, de esta manera, se consolid satisfactoriamente la
transicin y adaptacin de las actividades petroleras privadas de las concesionarias, a la
tutela del estado venezolano. Lagoven se encarga de las operaciones en el occidente y el
sur del pas; Corpoven despliega su rea de influencia en el centro de la nacin, mientras
que Maraven se sita en la regin oriental.
Asimismo, la compaa estatal enfoca parte de sus esfuerzos a la Faja del Orinoco, la cual
contiene importantes reservas de crudo pesado y extra-pesado. Para su explotacin, se
divide en cuatro reas o zonas de influencia: Machete, Hamaca (ambos operados en su
momento por Corpoven), Cerro Negro (Lagoven) y Zuata (Maraven). La importancia
estratgica de la faja queda plasmada en sus nmeros: las reservas probadas estn por el
orden de los 60.000 y 200.000 millones de barriles. Para tener una comparacin que
permita apreciar este dato, es importante destacar que desde 1917 hasta 1994, se
produjeron en el pas 46.421 millones de barriles de crudo de todo tipo.
PDVSA logra ser considerada como una empresa confiable en el suministro de grandes
volmenes de petrleo a nivel mundial. En esta fase, Petrleos de Venezuela se consolida
como una las principales compaas petroleras multinacionales.
A mediados de los aos 80, la principal empresa del pas inicia una expansin tanto a
nivel nacional como mundial, con la compra y participacin en diversas refineras ubicadas
en Europa, Estados Unidos y el Caribe.
La faja del Orinoco tambin entra dentro de una estrategia de asociaciones estratgicas
para producir crudos, mientras que se crean empresas mixtas en el rea de la
Orimulsin.
Entre 1993 y 1996 se realizaron las tres primeras rondas de convenios operativos lo que
produjo para el pas una inversin inicial superior a los dos mil millones de dlares y una
produccin adicional de crudo estimada en unos 260.000 barriles diarios.
A partir de 1999, PDVSA establece en asociacin con la Fuerza Armada Nacional y otras
instituciones del Estado, una serie de programas dirigidos a paliar la emergencia social
que viva el pas.
como dos columnas que soportan parte de la estructura econmica y social de PDVSA y
del pas.
Este principio rige la totalidad de las operaciones que se enmarcan dentro de la dinmica
petrolera, ya que PDVSA es uno de los principales responsables en el desarrollo nacional
y por consecuencia de la seguridad de la nacin, y de todo lo que ello implica, a travs del
beneficio generado con la comercializacin de sus productos y sus aportes al fisco
nacional (http://www.intranet.pdvsa.com, consultado el 18-06-2009).
3.1.2.
Para el primer perodo del Plan Siembra Petrolera, se han estimado inversiones por el
orden de los 56.000 millones de dlares, a ser ejecutados entre 2005- y 2012. De esa
cantidad, 70% ser aportada por la operadora estatal venezolana y el resto por el sector
privado.
3.1.2.1.
Magna Reserva
3.1.2.2.
Proyecto Orinoco
3.1.2.3.
Proyecto Delta-Caribe
El gas se incorporar a la oferta energtica del pas. Este proyecto persigue el desarrollo
del Gas Costa Afuera en las reas de Plataforma Deltana, en la fachada atlntica
venezolana; en las aguas ubicadas al norte del estado Sucre, al oriente de Venezuela; y
en las inmediaciones de la Pennsula de Paraguan, al nor-occidente del pas.
3.1.2.4.
Refinacin
Aumentar la capacidad de refinacin en Venezuela es una de las puntas de lanza del plan
estratgico de PDVSA. El Plan Siembra Petrolera contempla la creacin de nuevos
centros refinadores: Cabruta (con capacidad de 400.000 barriles diarios de crudos
extrapesados), Batalla de Santa Ins (50.000 barriles diarios) y Caripito (50.000 barriles
diarios destinados a la produccin de Asfalto). Con estas tres nuevas refineras y la
potenciacin de las existentes se incrementar en 700.000 barriles diarios la capacidad de
procesamiento de PDVSA en suelo venezolano.
3.1.2.5.
Infraestructura
3.1.2.6.
Integracin
3.2.
3.2.1.
Breve Histrico
Visin
Soberana plena en soluciones AIT para el sector energtico aportando valor social
(PDVSA, 2008).
3.2.3.
Misin
3.2.4.
Objetivos Estratgicos
Segn Planificacin y Arquitectura los Objetivos Estratgicos de AIT son los siguientes:
Consolidar el
transparencia
emanadas de la Corporacin
3.3.
3.3.1.
Objetivo
Definir
implantar
soluciones
integrales
de
Automatizacin,
Informtica
Alcance
Formulacin del proyecto. Estimaciones clase II de costos del proyecto. Manejo del
riesgo.
3.3.3.
Premisas
Solo sern proyectos para la responsabilidad del proceso DIS, aquellos que
impliquen el diseo y/o implantacin de una solucin tecnolgica de AIT.
3.3.4.
DSD2
Solicitud de
Adecuacin de
Plataforma
DSD1 y
Propuesta de
Solucin
Tecnolgica
aprobado
Requerimient
o Act.
Elem. Config.
Concep
tua
lizar
G
N
O
Solicitud
Procura de
Activos
Requerimiento
de Control de
Cambio
Definir
Implanta
r
Solicitud de
Almacen. y
Respaldo
Operar
Adecuacin de
Plataforma
P
B
S
Solicitud
Procura de
Bienes y
Servicios
Proyecto
Diferido
Cancelado
Procura de
Bienes
y Servicios
DSD3
G
A
Necesidades
de
Formacin
Procura de
Activos
DSD4
M
A
P
Respuesta de
Solicitud de
Aprobacin del
DSD2
Respuesta de
Solicitud de
Aprobacin del
DSD3
Respuesta de
Solicitud de
Aprobacin del
DSD4
A
Y
R
Solicitud de
Contrato
Reporte de
Solicitudes
Atendidas
Solucin
Tecnolgica
A
R
F
Requerimiento de
Actualizacin
Catlogo
de Servicios
Necesidades
Monitoreo
de Solucin
Implantada
Informe de
Cierre del
Proyecto
Plan de Transferencia
de Nueva Infraestructura
4. CAPTULO IV
EXAMEN DE LA SITUACIN
En el presente captulo se presenta el procedimiento seguido para realizar el examen de la
situacin actual de la gestin de proyectos en la Gerencia de Desarrollo e Implantacin de
Soluciones, la cual se realiza siguiendo los lineamientos de las Guas de Gerencia para
Proyectos de Inversin de Capital. El examen de la situacin actual se presenta a travs
de su objetivo, planificacin, ejecucin, resultados obtenidos y la conclusin sobre las
reas a atender.
4.1.
4.2.
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.
4.3.
CONCEPTUALIZAR
VISUALIZAR
Evaluar el sitio
Preparar el alcance conceptual y
estimados clase IV
Solicitud de fondos
DEFINIR
X
X
X
X
X
X
X
X
X
IMPLANTAR
CONTRATACIN
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
Aplica medianamente en
royectos de TI, puesto quie
los mismos no
necesariamente se
contratan a terceros.
EJECUCIN
Ingeniera
x
X
OPERAR
OPERACIN INICIAL
Preparacin y pruebas para el
arranque
Arranque
X
X
PRUEBAS DE GARANTA
Pruebas de capacidad
ACEPTACIN DE INSTALACIONES
Entrega de instalaciones
En el caso de proyectos de
TI la ingeniera de detalle
debe obtenerse en la fase
de definicin
Pocos proyectos de TI
incluyen la compra de
equipos puesto que esta
funcin la asume
principalemente la gerencia
de Matenimiento de
Operaciones de AIT
EVALUACIN CONTNUA
% Grado de aplicabilidad
4.4.
66
22
12
Es medio porque si se
pueden especificar los
resultados tcnicos, pero
los econmicos segn las
GGPIC se trata de valores
como la Tasa Interna de
Retorno (TIR), Valor
Presente Neto (VPN), entre
otros, los cuales no aplican
en proyectos de gastos.
Este objetivo es asumido
en AIT por la organicacin
de Gestin del Servicio
(GDS)
Alto y medio superior al 80
%
Si bien es cierto que las GGPIC son aplicables en un alto grado a proyectos de TI, las
mismas no satisfacen completamente las necesidades que se presentan en la gestin de
este tipo de proyectos, razn por la cual entra en el estudio el aporte que en este sentido
pueden ofrecer metodologas como RUP y UML, las cuales fueron consideradas en la
elaboracin de la metodologa propuesta. Estos aportes se describirn en detalle en el
prximo captulo.
4.5.
Como resultado del anlisis realizado durante el examen de la situacin donde se pudo
apreciar el grado de aplicabilidad de las Guas de Gerencia para Proyectos de Inversin de
Capital en proyectos de TI, la autora consider necesario el diseo de una metodologa,
que usando como base las GGPIC fuera complementada con las actividades propias de
Finalmente, una vez diseada la metodologa, la misma debe ser difundida entre el
personal encargado de manejar proyectos de TI, para garantizar el uso de un
mismo lenguaje, estndares, documentacin y resultados esperados, lo cual
facilitar, no solo la gestin de proyectos, sino el pase de testigo en casos de
movimientos
de
personal
cambios
de
responsabilidades.
5. CAPTULO V
PROPUESTA DE METODOLOGA DE GESTIN DE PROYECTOS DE
TECNOLOGA DE INFORMACIN EN LA GERENCIA DIS
En este captulo se presenta el proceso realizado para elaborar la propuesta de diseo de
una Metodologa de Gestin de Proyectos de Tecnologas de Informacin en La Gerencia
Desarrollo e Implantacin de Soluciones, de acuerdo a las necesidades detectadas en el
captulo anterior. Se expondrn la justificacin de la propuesta, los objetivos, la
planificacin del proceso para realizar la propuesta, y, finalmente se concluir con la
propuesta como tal.
5.1.
JUSTIFICACIN DE LA PROPUESTA
normas
nacionales
internacionales
adoptadas
por
la
El lineamiento corporativo indica que AIT debe usar para la Gestin de Proyectos la Gua
de Gerencia para Proyectos de Inversin de Capital (GGPIC), esta gua fue diseada por
un grupo de ingenieros de PDVSA en 1999, y, aunque son adaptables a varios tipos de
proyectos, fueron creadas principalmente desde la perspectiva de proyectos de Ingeniera
y Construccin.
5.2.
OBJETIVO DE LA PROPUESTA
Proveer a los lderes de proyectos de una gua paso a paso para la gestin de
proyectos, la cual facilitar su trabajo, apuntando con mayor probabilidad al logro de
los objetivos de los proyectos asignados.
5.3.
Para llevar a cabo la propuesta, el primer paso fue el examen de la situacin, llevado a
cabo en el captulo anterior, de all se obtuvo que las GGPIC son aplicables en ms de un
80% a proyectos de TI.
Como siguiente paso y, luego de haber estudiado en el captulo II la metodologa base del
trabajo GGPIC, en conjunto con la metodologa a utilizar para realizar el complemento
para generar una nueva metodologa ms adecuada para proyectos de TI, RUP; se hizo
un anlisis de cmo se correlacionan las fases del ciclo de vida de un proyecto entre
ambas metodologas. Esta correlacin se puede apreciar en la siguiente figura:
Por ltimo, para elaborar la propuesta se proceder con su ejecucin, la cual consistir en
detallar las actividades que correspondern a cada fase que, segn el propsito de este
estudio, deben respetar el lineamiento corporativo de regirse por las GGPIC. En la
propuesta, se incorporan las actividades tcnicas propias de proyectos de TI, logrando de
esta manera, el objetivo que contar con una metodologa mas apropiada al tipo de
proyectos que se gestionan en la Gerencia de Desarrollo e Implantacin de Soluciones
(DIS).
5.4.
Se entender en qu consiste cada fase del ciclo de vida, y cada una de las actividades
que debern ser seguidas para la ejecucin de un proyecto.
5.4.1.
Fase Visualizar
Las ideas que originan los proyectos pueden provenir, en cualquier momento, de cualquier
parte de la Corporacin, pero son generalmente el producto de los anlisis del ambiente
externo e interno a ella, o del anlisis F.O.D.A (Fortalezas, Oportunidades, Debilidades,
Amenazas) que se realiza como parte de los ciclos de planificacin. Estos anlisis se
efectan en equipo con la participacin de todas las organizaciones de la Corporacin y
bajo la responsabilidad integradora de las unidades de Planificacin Corporativa.
5.4.1.1.
Acordar con el negocio quien ser el o los puntos focales para el levantamiento de los
requerimientos as como el lder funcional; el comit de usuarios seleccionado y su lder
debern participar y formarn parte del equipo durante todo el ciclo de vida del proyecto.
5.4.1.2.
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.
5.4.1.4.
debe
llevar un cronograma
5.4.1.5.
Describir brevemente los antecedentes del problema: Soluciones previas, evolucin del
problema en el tiempo, descripcin de la situacin que da origen a la necesidad.
Elaborar una lista enumerada con la descripcin de las necesidades, oportunidades y/o
problemas del proceso de negocio bajo estudio.
Se debe tener presente que las necesidades, oportunidades y/o problemas pueden darse
por: lineamientos corporativos, por interoperabilidad, por rendimiento y/u obsolescencia
tecnolgica.
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.
Luego de que los objetivos y propsitos del proyecto han sido establecidos, y los grupos
de planificacin han constatado que cumplen con las estrategias y lineamientos del plan
de negocios, se debe elaborar un alcance preliminar, a fin de utilizarlo de base para
estimar su costo y tiempo de ejecucin. Estos estimados se utilizarn en el anlisis para
confirmar la factibilidad econmica del proyecto y la conveniencia de proseguir con su
desarrollo.
Se debe
Los requisitos funcionales, listados segn el punto 4.1.6.1.7 deben priorizarse siguiendo el
siguiente esquema:
Requisitos
Prioridad
Complejidad
Esfuerzo
Estabilidad
del Cliente
<identificador
requisito>
requisito>
Alta
Baja
Complejidad
Este atributo se refiere a la bsqueda del nivel de abstraccin requerido para comprender
el requerimiento durante el proceso de anlisis y diseo.
Alta
Baja
Esfuerzo
Bajo
Estabilidad
Baja
Son condiciones o capacidades que deben estar incluidas dentro de la solucin. Estas, se
deben expresar en lenguaje natural de forma concreta y enumerada.
Por ejemplo:
Tabla 9 Ejemplo de Caractersticas Generales de la Solucin TI
Id.
Caracterstica
Caracterstica
Observacin
El tiempo de respuesta
actual es aproximadamente
8 segundos.
El proceso de negocio
2
actualmente no contempla
Actualmente la aplicacin
nicamente se ejecuta
adecuadamente en un
navegador propietario.
5.4.1.5.1.12. Justificacin
Describir los beneficios que se obtendrn con la ejecucin exitosa del proyecto e indique
cmo apoya los objetivos estratgicos del negocio.
5.4.1.5.2.
Identificacin de Servicios
Identificar los servicios que puedan ser consumidos o provistos por los componentes
funcionales involucrados en la solucin como se puede observar en la siguiente tabla
ejemplo:
Unidad de
Proceso(s) de
Caso(s) de uso de
Servicio
Negocio
Negocio
Negocio
<Nombre
del
Servicio>
<Unidad
de
Negocio
Restriccin:
nombre
el
custodio
del
servicio>
<Procesos
Negocio
del
requieren
de
que
el
servicio>
Proveedor(es)
<Casos de uso de
<Aplicacione
<Componentes
Procesos
de
Funcionales
Negocio
que
Componente
Aplicaciones
Proveedor(es)
requieren
servicio es nico
Cliente(s)
el
servicio>
Funcionales
en el repositorio.
clientes
del
servicio>
del
Servicio>
crearCliente
Data Maestra
Creacin
de
Crear Cliente
Data Entry
Facturador
RESET
ERP FI/CO
Clientes
asientoContable
Finanzas
Asientos
Realizar
Contable
Contable
Asiento
GADET
5.4.1.5.3.
Diagrama de Secuencia
5.4.1.5.4.
5.4.1.5.5.
En el captulo IV, donde se examin la situacin, se seal que en AIT la mayora de los
proyectos son considerados de gastos, sin embargo, si el proyecto tiene tal magnitud de
componentes que representen que el proyecto sea considerado como de inversin, debe
cumplir con el anlisis comercial.
Las propuestas, para efectos de conformar la cartera de inversin, debern clasificarse en:
Generan Ahorros (AH): Las propuestas que generan ahorros debern justificarse
por s mismas mediante una evaluacin a nivel unidad de negocio, que compare la
situacin actual con la que ocurrira de ejecutarse la propuesta. El DSD del
proyecto debe presentar el flujo de caja de la situacin actual, el flujo de caja
propuesto, el flujo de caja diferencial y la metodologa para medir los beneficios que
ste aporta una vez entrado en operacin el proyecto. Los indicadores econmicos
debern ser calculados a partir del flujo de caja diferencial.
Asociada (AS)
Continuidad Operacional
Reemplazo/Mantenimiento (RM)
Normativas/Regulatorias (COPNR)
Otras Inversiones de Continuidad Operacional (COPOT)
Exploracin (EX)
Costos de Inversin
Flujo de caja
5.4.1.5.6.
Un estimado de costos clase V es un estimado con una precisin del tipo orden de
magnitud, el cual se utiliza en la planificacin a mediano plazo para establecer si los
proyectos renen los mritos suficientes para proseguir su desarrollo.
El mismo deber incluir un estimado de costos de mayor precisin (clase II) de los fondos
requeridos para el desarrollo de la fase Conceptualizar y de los trabajos de laboratorio
necesarios para mejorar la definicin del proyecto. Estos fondos debern ser solicitados y
aprobados antes de proseguir con dicha fase. Ver anexo N 1.
Informacin requerida
Este estimado debe basarse en una definicin global, a grosso modo, del proyecto y de
sus principales unidades de proceso, en la que la informacin disponible se limite
esencialmente a:
Mtodo de estimacin
Precisin y confiabilidad
Es un estimado del tipo orden de magnitud y no tiene una confiabilidad definida sino que
sta depende de la calidad de la informacin disponible de proyectos similares ya
completados o que estn en desarrollo y de la pericia con que se evalen, se ajusten por
factores o se escalen, los datos de costo.
5.4.1.5.7.
Sumario
Propsito
Temas Crticos
Plan de Contratacin
Tecnologa/Ingeniera
Informes
A lo largo de la ejecucin del proyecto, resulta conveniente asignarle a este plan, una
clasificacin similar que concuerda con la del estimado de costos disponible para el
momento.
5.4.1.5.8.
Elaborar plan con una precisin clase II para ejecutar la prxima fase
(Conceptualizar).
Definir recursos requeridos para ejecutar la prxima fase (Conceptualizar) clase II.
Se deben precisar los recursos que sern necesarios para ejecutar la siguiente
fase. Para esto se puede usar como referencia el ejemplo que se incluye en el
anexo N 4.
5.4.1.5.9.
Para que un proyecto sea posteriormente recibido por el personal de operaciones de AIT,
el proceso de Gestin de la Configuracin, exige cumplir con este paso, de lo contrario la
nueva solucin no ser aceptada.
5.4.1.6.
Entrega de DSD1
5.4.2.
Fase Conceptualizar
Los productos de la fase de visualizar constituyen el insumo de trabajo para continuar con
el desarrollo del proyecto y ejecutar la fase de conceptualizar.
El propsito de esta fase es la seleccin de la(s) mejor(es) opcin(es) y la mejora en la
precisin de los estimados de costos y tiempo de implantacin. En esta fase se detallan
adems los requerimientos del negocio para la nueva solucin de TI.
5.4.2.1.
5.4.2.2.
5.4.2.2.1.
Se deben evaluar las alternativas de solucin, en este punto debe explicarse la estrategia
que se utilizar para realizar la evaluacin de las posibles soluciones, esto se refiere a los
pasos que se seguirn, metodologas y recursos necesarios para completar con xito la
evaluacin de cada alternativa y el anlisis de los resultados para realizar el informe final
de recomendacin de solucin.
Incluir las recomendaciones relacionadas con lo desarrollado en esta seccin, por
ejemplo, para las pruebas de cada alternativa de solucin podran requerirse acuerdos de
confidencialidad, tambin necesidades de instalaciones, espacio y equipos.
En caso de pruebas de concepto, podran ser convenientes acuerdos con los proveedores
de la tecnologa para compartir los gastos generados, recursos, equipos e instalaciones.
5.4.2.2.2.
5.4.2.2.3.
Esta actividad aplica si el proceso propuesto difiere del proceso de negocio original.
Lo mismo aplica para el Modelo de Casos de Uso del proceso del negocio, es decir, si el
modelo propuesto difiere del original, se diagrama en esta seccin, sino se coloca el
mismo.
5.4.2.2.4.
Especificacin de Requerimientos
Si aplica, identificar los detalles fsicos de los intercambios de datos entre los
componentes funcionales o aplicaciones involucradas en el proceso de negocio que
apoyarn las decisiones de diseo. Deben documentarse modificaciones, incorporaciones
o desincorporaciones de intercambios de datos del proceso de negocio.
Origen
Des-
Descripcin
tino
Datos Inter-
Sncrono/
En
For-
Volu-
Tiempo
cambiados
Asncrono
lnea /
mato
men
de Res-
Batch
1
RMCA
CTC
Envo
de
Segn
rdenes
de
definicin
de
Segn
Sncrono
En lnea
puesta
XML
8000 por
1.5
da
segund
<=
N/A,
pago
2
CTC
RMC
Envo
os
Asncrono
Batch
Archiv
Orden
Origen
Des-
Descripcin
tino
Datos Inter-
Sncrono/
En
For-
Volu-
Tiempo
cambiados
Asncrono
lnea /
mato
men
de Res-
Batch
A
pagos
definicin
diario
cobrados
puesta
o
31500
batch
plano
registros
mensuales
CTC
RMC
Envo
pagos
de
Segn
Asncrono
definicin
Batch
Archiv
<=
N/A,
diario
31500
batch
plano
registros
rechazados
mensuales
[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.
Unidad
Servicio
Negocio
<Nombre
del
<Unidad
Servicio>
Negocio
Restriccin:
custodio
el nombre del
servicio>
servicio
nico
de
de
del
Proceso(s)
Caso(s) de uso
de Negocio
de Negocio
<Procesos de
<Casos de uso
<Aplicacion
<Componentes
Negocio
de Procesos de
es
Funcionales
Negocio
Component
Aplicaciones
es
Proveedor(es)
Funcionales
del servicio>
que
requieren
el
servicio>
es
en
que
requieren
el
servicio>
el
Cliente(s)
Proveedor(es)
clientes del
repositorio.
Servicio>
asientoContab
Finanzas
le
Asientos
Realizar Asiento
RESET
Contable
Contable
GADET
ERP FI/CO
Tipo de
lidad del
exposicin
servicio
del Servicio
Servicio
Concreto
En Lnea /
Sincrona
Archivo
plano
Transaccio-
Ca-
nal / Batch
nal
Transaccional
WS
Artefact
o
Contrato
ASC.crear
Cliente_4_
Adaptacin
DE
crearClie
Sncrono
En Lnea
nte.wsdl
Requerimientos No Funcionales
la data y la funcionalidad
Servicio.
2.
los
consumidores; 3. consideraciones de
seguridad,
Funcionales
responsabilidad
calidad
de
de
servicio,
Este contrato debe estar especificado en formato No XML (Extensible Markup Language)
en esta fase, para documentar los datos y sus tipos provistos en un servicio, as como los
aspectos no funcionales y polticas.
Para describir a los actores del sistema se utiliza una tabla como la que sigue a
continuacin. El cdigo del actor reseado como ACT.# se refiere al prefijo ACT. Seguido
por el nmero de actor asignado. La XX se refiere al nombre del Actor. La descripcin se
refiere a una breve resea del rol del actor para el sistema y las fuentes son los
involucrados del negocio que ayudaron a definir y describir al actor.
ACT.# XX
Descripcin:
Responsabilidades:
<Responsabilidad 1>
<Responsabilidad 2>
Fuentes:
La especificacin de los casos de uso viene dada por una tabla donde se sealan los
siguientes detalles:
CU.1 XX
Fuentes
Actor
Descripcin
Flujo bsico
1.
1.
Titulo del FA
Descripcin del FA
2.
Titulo del FA
1.
1.
Descripcin de la PTC
Requerimientos
1.
especiales
Puntos
de
Inclusin
Puntos
1.
1.
extensin
Notas
1.
Titulo de la Nota
Descripcin de la nota
<nombre descriptivo>
Requisito de Informacin
RI-<id>:
<nombre descriptivo>
Versin:
Autores:
Fuentes:
Descripcin:
Componente Funcional
Atributos:
Nombre
Descripcin
Tipo
Longitud
<nombre
de <longitud
descriptivo>
atributo>
dato>
Procedencia
<procedencia del
Descripcin
Nombre
<nombre descriptivo>
El
sistema
deber
sistema>
<capacidad
Fuente
del <autor de la versin
actual>
funcionalidad. Esta seccin nicamente aplica para soluciones que impliquen un Sistema
de Informacin con interfaces de usuario.
5.4.2.2.4.13.2.
Esta matriz debe se elaborada solo cuando existen varias soluciones en el mercado o
dentro de la Organizacin, que puedan dar respuesta a la necesidad solicitada, por lo que
es necesario compararlas, evaluarlas, y decidir la mejor opcin para lograr el objetivo del
proyecto.
5.4.2.2.4.15.2.
5.4.2.2.4.15.3.
5.4.2.2.4.15.4.
Incluir un marco terico que pueda ayudar a la toma de decisiones ya que en este proceso
pudieran participar personas no expertas en la materia.
5.4.2.2.4.15.5.
5.4.2.2.4.15.6.
5.4.2.2.4.15.7.
Esta actividad se realiza con el objetivo de que Seguridad Lgica, realice una revisin de
los requerimientos y pueda establecer los criterios mnimos de seguridad que debe cumplir
la solucin esperada para que la misma sea considerada como viable y segura para
PDVSA.
5.4.2.2.4.15.8.
5.4.2.2.4.15.9.
Realizar en este paso un cronograma preliminar de las siguientes fases del proyecto de
acuerdo a la solucin que se est evaluando
Una vez aplicada la matriz de evaluacin a cada una de las soluciones, se debe realizar en
este punto la matriz con los resultados de las mismas, que en conjunto con los dems
anlisis, determinarn la solucin a recomendar. Culminando con la elaboracin de un
informe con el resultado de la evaluacin y la solucin recomendada.
Asimismo, MAP debe considerar tener recursos con las mismas caractersticas para el
ambiente de desarrollo, donde se irn instalando las diferentes versiones de avance para
hacer pruebas. Ver planilla de solicitud en el anexo N 5.
5.4.2.2.5.
5.4.2.2.6.
5.4.2.2.7.
5.4.2.2.8.
5.4.2.3.
Entrega de DSD2
5.4.3.
Fase Definir
5.4.3.1.
5.4.3.2.
5.4.3.2.1.
5.4.3.2.2.
5.4.3.2.3.
5.4.3.2.4.
5.4.3.2.5.
5.4.3.2.6.
Justificacin (actualizar)
5.4.3.2.7.
Determinar de una manera tangible los beneficios obtenidos a travs de la ejecucin del
proyecto. Por ejemplo, si se trata de una sustitucin de un software, establecer las
diferencias en especificando mejoras en tiempos de respuestas, o si se trata de la
5.4.3.2.8.
5.4.3.2.9.
Elaborar Recomendaciones
Se deben describir las acciones para lograr la aprobacin del proyecto de manera de
avanzar a la fase de implantacin del mismo, esto puede ser equivalente a un proceso de
venta, donde se deben evidenciar los beneficios de seguir adelante con el proyecto para
obtener los fondos para su ejecucin.
Indicar si existiran riesgos durante la ejecucin del proyecto y de ser as, describir si son
tcnicos, polticos, econmicos, sociales, de mercado, ambientales, entre otros. Los pasos
mnimos son: identificacin de riesgos, cuantificacin / ponderacin de riesgos, anlisis
probabilstico de sensibilidad tiempo / costo, acciones para gerenciar el riesgo.
Los servicios, si existen para la solucin, fueron identificados en la fase visualizar. En esta
actividad, es probable que se hayan identificado nuevos servicios en vista del mayor
detalle acerca de los requerimientos obtenido en la fase conceptualizar, de ser as, se
actualiza la tabla original.
Mediante el diagrama E-R se modelan las bases de datos, con el fin de visualizar los
objetos que pertenecen a la Base de Datos, como entidades las cuales tienen unos
atributos
se
vinculan
mediante
(http://www.mitecnologico.com/Main/DiagramasEntidadRelacionER,
2009).
relaciones
consultado
03-08-
En esta fase se deben construir los casos de pruebas para los diversos tipos de pruebas
que se realizarn en la siguiente fase, especificando como se ejecutarn cada una de
ellas. Se deben proponer los participantes, los responsables, fechas estimadas y dems
detalles que sean necesarios.
Estas pruebas deben realizarse una vez que se han aprobado las pruebas unitarias.
nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que
componen un proceso, hecha en conjunto, de una sola vez. Se debe verificar que un gran
conjunto de partes de una solucin funcionan juntos. Adicionalmente estas pruebas deben
contemplar:
Validacin de la documentacin
Pruebas No funcionales
Pruebas de Seguridad
Es una prueba integral que no solo evala la capacidad de concurrencia de usuarios, sino
tambin rendimiento de los servidores y monitoreo de la red.
Nombre de la Prueba:
<Nombre de la Prueba>
Coordinador:
Preparada por:
Ejecutada por:
Requerimientos Asociados a la
prueba:
Tipo de Prueba
Aceptacin
Fecha de Ejecucin:
Descripcin de la Prueba:
<Descripcin de la prueba>
Resultados Esperados:
Errores Encontrados:
Necesita Reprobarse
Prueba Aprobada:
Revisada y Aprobada por:
Fecha de revisin:
Sealar si la nueva solucin acarrear costos para permitir su continuidad operativa, por
ejemplo si la solucin incluye software propietario se puede proyectar los costos en
licenciamiento anual, si un nuevo hardware requiere contrato de mantenimiento posterior a
su implantacin, estimar estos cargos anuales, etc.
Elaborar cronograma clase II para ejecutar las prximas fases (Implantar y Operar).
Establecer guas para el control de las fases implantar y operar: definir como se va
a controlar el proyecto, por ejemplo usando la curva S o el mtodo del valor ganado.
Para la seleccin final de la tecnologa se deben considerar todos los aspectos necesarios
en el aseguramiento tecnolgico segn aplique dependiendo del tipo de solucin, los
cuales se enumeran a continuacin.
Evaluacin de la tecnologa.
Soporte continuo.
El Documento de Solicitud de Ofertas (DSO) es una herramienta formal para solicitar a las
empresas o cooperativas la informacin necesaria para concursar. El mismo plasma los
requerimientos bsicos del proyecto desde los puntos de vista tcnicos, de ejecucin y
contractuales.
A continuacin, se
Entrega de DSD3
5.4.4.
5.4.4.1.
Fase Implantar
Proceso de Contratacin
De acuerdo al tipo de proceso estas actividades pueden variar, por eso es importante
validar en esta etapa con Cadena de Suministros (CDS) cuales son las actividades
especficas del proceso seleccionado para incorporarlas en el plan.
5.4.4.1.1.
5.4.4.1.2.
Aclarar con CDS como ser la participacin del lder de proyecto en el proceso de
contratacin, en cuanto a definir qu documentos elabora cada organizacin, quin es
responsable de la comunicacin directa con la Comisin de Contrataciones, en qu partes
del proceso debe participar o no el lder del proyecto.
5.4.4.1.3.
Reunin aclaratoria.
Entrega de ofertas.
5.4.4.1.4.
Notificacin de resultados
5.4.4.1.5.
Firma de Contrato
5.4.4.2.
Este plan es la base para el control de ejecucin del contrato de acuerdo a los productos
definidos. Se elabora una vez otorgado el(los) contrato(s), consolidando la informacin
contenida en el plan de ejecucin de la empresa favorecida con las buena-pro.
Cabe destacar que este plan clase I debe ser visto como la herramienta principal en la cual
se har nfasis para definir la medicin de avance del proyecto y, por ende, el control de
costos y la facturacin del pago.
5.4.4.3.
El PEP del contratista debe ser consistente con el PEP del proyecto. Debe establecer los
lmites apropiados del alcance de su trabajo y presentar adecuadamente los detalles.
Todos los contratistas licitantes deben preparar su PEP durante el perodo de seleccin, a
objeto de garantizar que las intenciones de ejecucin del contratista son bien entendidas
por el ente contratante, en este caso, AIT-DIS.
El PEP del contratista deber incluir una Estructura Detallada de Trabajo (EDT) que sea
compatible con la del proyecto y que, aunque pudiese ser elaborada a un nivel mayor de
detalle, permita relacionar sin ambigedad los elementos de trabajo del contratista para
establecer una base idntica de medicin.
5.4.4.4.
En esta fase, la actividad conformar equipo de trabajo, es mas extensa y detallada, ya que
se trata del equipo que debera participar durante esta fase y la siguiente que se podra
decir, son las de mayor peso puesto que se trata de la ejecucin del proyecto como tal y
su puesta en marcha.
5.4.4.4.1.
5.4.4.4.2.
Validar Lineamientos
Del negocio.
Tecnolgicos.
De requisitos.
5.4.4.4.3.
5.4.4.4.4.
5.4.4.5.
5.4.4.5.1.
Describir de manera sencilla y precisa las recomendaciones propias para esta etapa del
proyecto
5.4.4.5.2.
MONTO
FECHA ESTIMADA DE
ENTREGA
5.4.4.5.3.
Construccin
En esta actividad es importante recordar que MAP fue notificado desde la fase
conceptualizar de cuales eran los recursos que este proyecto iba a necesitar tanto en
desarrollo como en produccin, en este momento se le puede hacer entrega de la misma
planilla, (actualizada si fue necesario hacer algn ajuste), para que procedan a configurar
el ambiente de desarrollo. (Ver anexo N 5).
Sistema operativo.
Bases de datos.
Aplicaciones.
Interfaces.
Adquisicin de equipo.
El diseo de la solucin se realiz en la fase definir, en esta fase, ya teniendo claro quien
ejecutar el proyecto, es necesario revisar todos los aspectos tcnicos para validar que
son claros, funcionales y se adaptan perfectamente al objetivo del proyecto. Por lo tanto
se debe:
5.4.4.5.3.5. Desarrollo
de hardware, requerimientos de
Manual de ayuda a Gestin del Servicio: Este documento explica de forma rpida
y sencilla cmo el personal de GDS perteneciente tanto al personal del centro de
servicios (soporte telefnico) y soporte integral (soporte en sitio), realizar la
solucin de los incidentes, Este pequeo manual tambin es conocido como
Troubleshooting.
5.4.4.5.4.
Documentacin tcnica
Puntos pendientes de construccin (No relacionado con el alcance del proyecto que
se entrega). En el caso de proyectos de TI se debe anexar un informe con todos los
requerimientos adicionales que solicite el usuario y que no puedan ser
considerados en el alcance del proyecto actual. Este informe, aparte de ser un
anexo del DSD4, debe ser entregado a la gerencia de Gestin de Necesidades y
Oportunidades (GNO) para que visualice una nueva solucin para dichos
requerimientos, ya sea como una segunda fase del proyecto por terminar, como
cambios a la solucin una vez se haya puesto en marcha, como un nuevo proyecto
o la mejor alternativa que el consultor considere para estas necesidades.
5.4.4.5.5.
5.4.4.5.6.
5.4.4.6.
Entrega de DSD4
5.4.5.
5.4.5.1.
Fase Operar
Colocar en Operacin el Ambiente de Produccin
5.4.5.2.
La nueva solucin debe versa reflejada en los diferentes sistemas que permiten a la
continuidad operativa llevar el control de las soluciones que tiene AIT, reportar fallas,
gestionar controles de cambio, resguardar la documentacin, etc. Se deben hacer las
solicitudes correspondientes para que la nueva solucin aparezca reflejada en las
siguientes herramientas:
5.4.5.3.
5.4.5.4.
5.4.5.5.
Realizar reunin previa al control de cambio: en esta reunin deben participar todos
los involucrados y de all debe surgir el plan de accin para la ejecucin del control
de cambio y todas las tareas que deben crearse en el mismo.
Realizar pruebas:
Realizar pruebas de stress: esta prueba se realiza independientemente del
nmero de usuarios, ya que debe ser una prueba integral que no solo evale la
capacidad de concurrencia de usuarios, sino tambin rendimiento de los
servidores y monitoreo de la red.
Hacer rollback: esto significa que la aplicacin debe ser eliminada del ambiente
de produccin y mantenerse en el ambiente de desarrollo hasta que se apruebe
el siguiente control de cambio.
Realizar ajustes a la solucin (si aplica): los ajustes se hacen en el ambiente de
desarrollo y si la ventana del control de cambio da oportunidad se repiten las
pruebas sino habra que generar un nuevo control de cambio hasta que las
pruebas de estrs resulten exitosas.
Actualizar documentacin (si aplica).
Actualizar ultima versin de la aplicacin Base de Datos de Configuracin (si
aplica).
5.4.5.6.
Si el control de cambio nmero dos finaliza de manera exitosa, significa que ya se tiene
una nueva solucin de TI en ambiente de produccin, y lista para ser entregada
formalmente al personal de continuidad operativa de AIT.
5.4.5.7.
Aceptacin de Instalaciones
5.4.5.8.
5.4.5.8.1.
Elaborar el informe de cierre del proyecto tanto de ejecucin fsica, como financiera, y los
resultados obtenidos. Para el informe se pueden considerar los siguientes anexos:
Copia de contrato.
Respaldos financieros.
Cronograma de ejecucin.
Al haber completado las cinco fases del ciclo de vida basadas en esta metodologa que
incluye actividades propias de los proyectos de TI, se habr completado un proyecto, el
cual podr tener mayores probabilidades de xito que los proyectos ejecutados antes de
esta propuesta metodolgica.
6. CAPTULO VI
EVALUACIN DE LA PROPUESTA
Este captulo presenta la evaluacin del proyecto de Trabajo Especial de Grado a travs
de los resultados relevantes obtenidos, la viabilidad de implantacin de la propuesta; se
verificar el cumplimiento del cronograma y si fueron logrados los objetivos planteados.
6.2.
RESULTADOS RELEVANTES
En funcin de lo anterior, se considera que se logr una herramienta muy importante y til
para los lderes de proyecto y para la organizacin de Desarrollo e Implantacin de
Soluciones, lo cual a su vez redunda en un beneficio para AIT, que si bien es oportuno, se
puede recordar un extracto de su misin, que cita: Somos la Organizacin que rige,
provee y mantiene los servicios y soluciones integrales de tecnologas de automatizacin,
informacin y comunicaciones de la corporacin; contribuimos a mantener su continuidad
operativa y a ejecutar sus planes; innovamos y actuamos como agentes de transformacin
en PDVSA ()
6.3.
En este sentido, esta organizacin, en vista en que est en la capacidad de tomar las
decisiones referentes a los lineamientos de cmo debe trabajar la gerencia, decidi
proceder a divulgar la metodologa en el equipo de trabajo, considerando como premisa
que los proyectos que estn en curso se terminen de acuerdo a su planificacin actual, y
cada nuevo proyecto que se asigne a un lder de la Gerencia DIS, debe seguir lo
establecido en esta metodologa.
6.4.
6.5.
En cuanto al logro de los objetivos se considera que desde el punto de vista del objetivo
general el mismo fue satisfecho ya que el diseo de la Metodologa de Gestin de
Proyectos de Tecnologa de Informacin definitivamente apoya la gestin de proyectos de
Automatizacin, Informtica y Telecomunicaciones (AIT), en la Gerencia de Desarrollo e
implantacin de Soluciones (DIS). De igual forma, abordando los objetivos especficos,
tambin fueron cubiertos en su totalidad puesto que:
7. CAPTULO VII
CONCLUSIONES Y RECOMENDACIONES
Para cerrar el Trabajo Especial de Grado se expondrn las conclusiones y
recomendaciones pertinentes.
7.1.
CONCLUSIONES
Luego de realizar el examen de la situacin en el captulo IV, se pudo observar que las
Guas de Gerencia para Proyectos de Inversin de Capital (GGPIC) se aplican en alto
grado en la gestin de proyectos de Tecnologa de Informacin (TI), sin embargo, en la
Gerencia de Desarrollo e Implantacin de Soluciones se ha visto, que siguiendo esta
metodologa, siempre se ve afectada alguna de las aristas principales del proyecto
estudiadas en el captulo II, conocidas como la triple restriccin.
Todo este anlisis permiti concluir que es necesaria una nueva metodologa mejorada y
adaptada a las particularidades de los proyectos de Tecnologa de Informacin (TI), los
cuales estn a cargo de la Gerencia de Desarrollo e Implantacin de Soluciones (DIS) de
Automatizacin, Informtica y Telecomunicaciones (AIT) en Petrleos de Venezuela
(PDVSA).
las GGPIC como gua metodolgica. En este sentido se mantuvo la base de esta
metodologa, con sus actividades principales aplicables y manteniendo a su vez las
mismas fases del ciclo de vida de los proyectos, construyendo de esta manera, una nueva
metodologa ms completa, mejorada y adaptada a la realidad de los proyectos de
tecnologa ejecutados por la gerencia DIS.
Por ltimo, se observa la limitacin de no contar con el tiempo necesario para aplicar la
metodologa diseada en un nuevo proyecto de principio a fin, donde se podra evidenciar
con datos precisos, si el uso de sta, favoreci la gestin del proyecto, observndose en
los resultados del mismo. Esta limitacin se puede convertir en una oportunidad para un
nuevo estudio.
7.2.
RECOMENDACIONES
Seleccionar una muestra de los proyectos que estn prximos a comenzar, a los
cuales se les aplique la metodologa y se puedan medir los resultados obtenidos en
cuanto a tiempo, costo y calidad, lo cual evidenciar la utilidad de la propuesta
realizada en este TEG.
REFERENCIAS
Cleland, D. y Ireland, L. (2001). Manual Porttil del Administrador de Proyectos. Ciudad
de Mxico. Ciudad de Mxico, Mxico: McGraw-Hill.
Castro, G. Proyectos Informticos http://www.monografias.com/trabajos39/proyectoinformatico/proyecto-informatico2.shtml, consultado el 10-06-2009.
Gestin de la Configuracin. (2007). Manual para el Taller de Dimensions. Caracas:
PDVSA. Documento mimeografiado.
Gestin y Mejoramiento de Procesos. (2007). Diseo del Proceso Desarrollo e
Implantacin de Soluciones. Caracas: PDVSA.
http://es.wikipedia.org/wiki/Gestin_de_proyectos, consultado el 14/04/2009).
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/, consultado el 11-062009.
http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/c1/c1.htm,
consultado el 09-06-2009.
http://www.degerencia.com/area.php?areaid=2001, consultado el 11-06-2009.
http://www.hispadata.com/servicios/gestion-proyectos-ti.php, consultado el 09-06-2009.
http://www.intranet.pdvsa.com, consultado el 18-06-2009.
http://www.liderdeproyecto.com/metodologias/index.html, consultado el 11-06-2009.
http://www.mitecnologico.com/Main/DiagramasEntidadRelacionER consultado el 03-082009.
http://www.pdvsa.com/, consultado el 14-04-2009.
http://www.slideshare.net/dbaccess/pruebas-unitarias-uso-de-nunit-dentro-de-proyectosnet, consultado 10-08-2009.
http://www.sparxsystems.com.ar/download/ayuda/index.html?classdiagram.htm,
consultado 03-08-2009.
IESA. 25 Programa de Gerencia de Proyectos. (2005). Caracas: IESA. Documento
Mimeografiado.
8.
ANEXOS
Grado de
precisin
Clase V
Clase IV
Clase III
Clase II
Clase I
15%
30%
60%
80%
90%
Nota: Esta clasificacin se aplica tambin a los estimados de tiempo de ejecucin del
proyecto.
Datos Bsicos
SOLICITANTE
Regin:
Filial:
rea Funcional:
Distrito/Localidad:
mbito:
Internacional
Nacional
Regional
Prioridad:
Mandatario
Indispensable
Necesario
Diferible o deseable
Aprobador(es)
Nombre y Apellido:
Indicador:
Telfono:
Instructivo de llenado:
Regin: Nombre de la regin, donde ha sido detectada la necesidad u oportunidad
(Oriente/Centro/Sur/Occidente/Metropolitana).
Filial: Nombre del negocio o filial, donde ha sido detectada la necesidad u
oportunidad (Exploracin y Produccin, Refinacin, Intevep, Gas, CVP,
Corporativo)
rea Funcional: Nombre de la funcin en donde ha sido detectada la necesidad u
oportunidad (Recursos Humanos, Finanzas, PCP, etc.).
Distrito: Nombre del distrito en donde ha sido detectada la necesidad u oportunidad
(San Tom, Maturn, Morichal, Ta Juana, Lagunillas, etc.)
mbito: El mbito del proyecto: nacional, internacional o regional, si es regional,
especifique.
Prioridad:
Mandatario: de mxima prioridad y a ser ejecutada sin dilaciones.
Indispensable: Iniciativa con claro componente de valor, lo cual implica su
programacin en el actual ciclo de planificacin
Necesario: Casos de menor prioridad pero todava a desarrollar en el ciclo
de planificacin actual.
Diferible deseable: Casos con holgura para ser postergadas para
posteriores ciclos de planificacin.
Solicitante: Nombre, indicador y telfono de la(s) persona(s) solicitante(s).
Aprobador: Nombre, indicador y telfono de la(s) persona(s) aprobador(es).
Para el modelado de proceso de negocio se puede usar una extensin de UML que define
cuatro vistas estratgicas: visin, proceso, estructura y comportamiento.
Misin
Visin
Matriz DOFA
cd Procesos Entorno
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Logistica
Finanzas
Recursos Humanos
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Unregistered
Trial Version
EA 5.0 Viaj
Unregistered
Trial Contabiliadad
Version EA 5.0 Control
EA 5.0 Unregistered
Trial Version
es y Traslado
Interno de
Nmina
Tesorera
Finanzas
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Reserv acion y Serv icios
Aprobacion de Pagos
Niv el Autoridad
Administrativ o y
trabaj ador
de Traslado
EA 5.0 Unregistered Trial
Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered
Trial Version
Financiero
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial
Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
suministra
Logistica
<<objeto>>
<<objeto>>
Transferencia
(Nota de Debito)
genera
insumo
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
suministra
EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0insumo
Unregistered Trial Version EA 5.0 Unregistered Trial Version
<<objeto>>
Contabilidad (copia)
insumo
-Informacion de rutas
insumo
EA 5.0 Unregistered
Trial
5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
-Informacion
de Version EA
insumo
proveedores
insumo
<<objeto>>
-Centro de Costos
-Cuentas de labor
<<objeto>>
suministra
Gastos
y Deudas EA
del 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Version EA 5.0 Unregistered Trial
Version
<<objeto>>
Archivo de pago
de proveedores
trabajador
-Documentos Descontados
Salida
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered Trial-Documentos
VersionNo Descontados
EA 5.0 Unregistered Trial Version
<<objeto>>
Contabiliadad
EA
5.0 Unregistered Trial Version EA 5.0<<objeto>>
Unregistered Trial
regulaVersion EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
insumo
Movimientos
contables
- Normas y Procedimientos
genera
insumo
suministra
Corporativos
de Finanzas Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version
EA 5.0
Unregistered
<<objeto>>
genera
Recursos Humanos
Nmina
<<objeto>>
<<objeto>>
Solicitud Firmada
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0
Unregistered Trial
Version EA 5.0 Unregistered
Trial Version EA 5.0 Unregistered
Trial Version
genera
insumo
Deducciones
-Informacion del trabajador
-Ordenes internas
<<objeto>>
por deuda
-Cadenas
aprobacion
insumo EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA
5.0 de
Unregistered
Trial Version EA 5.0 Unregistered
insumo Trial Version
Cadenas de
aprobacion
suministra
Salida
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered
Trial Version
<<objeto>>
Aprobacion de Pagos
<<objeto>>
salida
AutoridadEA 5.0
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered TrialNivel
Version
Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Informacion del
trabajador
insumo
Administrativo y
Financiero
Solicitud Autorizada
entrada
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
Diagrama de Actividad
Se realiza el diagrama del conjunto de actividades que son realizadas para alcanzar el
objetivo del Proceso de Negocio bajo estudio bajo notacin UML.
Define el conjunto de actividades que realizan las Organizaciones para modelar, optimizar,
o adaptar sus procesos de negocio a las nuevas necesidades organizacionales. Involucra
el descubrimiento, diseo y distribucin de procesos de negocio, as como el control
ejecutivo, administrativo y supervisin de dichos procesos. DPN es una notacin estndar
para modelar visualmente flujos de procesos, tiene como objetivo proveer notacin comn
para analistas del negocio que crean los flujos iniciales de los procesos y desarrolladores
de software responsables por tecnologa e implementacin de los procesos. DPN est
basado entre Diagramas de Actividad de UML y Diagramas de Flujo Actividad-Decisin y
especifica un nico tipo de diagrama, DPN con un conjunto de elementos necesarios para
su elaboracin. Estos elementos estn divididos en cuatro categoras:
Esta vista muestra la estructura de los recursos, productos, servicios y la informacin 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 especifican el alcance y las responsabilidades de cada uno
de los sistemas o actores en la construccin de aplicaciones. Los Casos de Uso del
Negocio describen como los procesos son llevados a cabo por personas y los activos de la
organizacin.
Los actores de este modelo pueden representar la figura de Componentes Funcionales
(mdulo de software).
CASO DE USO
FUENTES
ACTOR
DESCRIPCIN
FLUJO BSICO
3.
3.
Ttulo del FA
Descripcin del FA
4.
Ttulo del FA
2.
2.
REQUERIMIENTOS
1.
ESPECIALES
SUPOSICIONES
1.
Descripcin de la PTC
Ttulo del requerimiento
Ttulo de la suposicin
Descripcin de la suposicin
REGLA
DE
NEGOCIOS
PUNTOS
Ttulo de la suposicin
Descripcin de la suposicin
DE
INCLUSIN
PUNTOS
2.
DE
1.
EXTENSIN
NOTAS
2.
Ttulo de la Nota
Descripcin de la nota
FUNCIONALIDADES REQUERIDAS
<descripcin
de
la(s)
funcionalidad(es)
requeridas
del
pagos
en
lnea
con
las
entidades
bancarias;
APLICACIONES
NIVEL DE SATISFACCIN
COMPONENTE FUNCIONAL
Ej: NAAF; GADET; RESET.
<Nivel de satisfaccin de
los
usuarios
con
la(s)
en
la
informacin
es
aplicacin(es)
involucradas
migracin>.
Esta
<arquitectura de
hardware
y software
del
Componente
Funcional>
PROVEEDOR
COSTOS LICENCIA
COSTOS SOPORTE
Sncrono/
Origen
Destino
Descripcin
Datos Intercambiados
Recaudador
Gateway Pagos
Envo de rdenes
Segn definicin
Asncrono
pagos
Segn definicin
Asncrono
pagos
Segn definicin
Asncrono
Asncrono
de pago
2
Gateway Pagos
Recaudador
Envo
Gateway Pagos
Recaudador
Envo
de
cobrados
de
rechazados
Reglas de Negocio
RN-<ID>
Tipo
Descripcin
RN-01
Reglas de Restriccin
Ejemplo
Observaciones
Mes N
Costos Contratos u
rdenes de
Servicio
Mes 2
Concepto
Mes 1
GASTOS DE CONCEPTUALIZACIN
Centro de Costo
PROYECTO XXXX
PRUEBAS & ASSESSMENTS
Prueba de Conceptos & Assessment OPCIN 1
Prueba de Conceptos & Assessment OPCIN 2
Prueba de Conceptos & Assessment OPCIN 3
Prueba de Conceptos & Assessment OPCIN N
CONSULTORES EXTERNOS [Segn tarifas base de PDVSA]
Analista P1
Analista P5
Concusltor Senior
Viticos
Boletos [Debe estimarse la necesidad de viajes al interior del pas]
Hospedaje
Licenciamiento [si aplica]
Licencias
Software
Infraestructura [Podra alquilarse un local s no existiera espacio en
PDVSA con el propsito de ejecutar las pruebas de concepto]
Alquiler de Local
Hardware [Debe estimarse si aplica]
Laptops
Impresoras & Scanners
Otros
Adiestramiento
Viticos Empleados
Impuestos
Propinas
Llamadas
Hospedaje
Alimentacin
Taxis
Estacionamiento
Refrigerios [Reuniones]
Gestin de Aprovisionamiento [Representa el 10% de los gastos, este
fondo es slo para cubrir emergencias y algn evento atpico]
TOTAL EN US$
Fecha:
Gerente Responsable:
Empresa:
CONTACTOS
Lder por AIT:
Aplicacin:
Base de Datos:
Redes:
Seguridad Lgica:
Servidores:
Proyecto:
Web:
Otro:
____________________________________________________________________________________
INFORMACION TECNICA
Caractersticas del Servidor(es) donde se va a instalar la aplicacin:
Sistema Operativo:
Versin:
Memoria:
Paquete(s) requerido(s):
Espacio en disco:
Web:
Extranet:
Manejador de Base de
Datos:
Nombre(s) de la(s)
instancia(s) de BD:
Versin:
Vendors
Tipo de Servicio:
Especifique: ___________
Criticidad:
______________________________
Toda la base de datos
___________________________________________________________________________________
N DE PAGS: 139