prj cjg

Transcripción

prj cjg

PROYECTO FINAL DE CARRERA
Memoria de trabajo en empresa
Memoria de trabajo realizado en empresa,
Technical Account Manager
Alumna: I. Cristina Jiménez García
Director URV: Benet Campderrich Falgueras
Director Soluziona: Julio Silvosa Castosa
Junio 2005
Junio 2005
Página 1 de 1
Autora: Cristina Jiménez
ÍNDICE
1. ÍNDICE DE CONTENIDOS
1
2
3
4
5
6
6.1
6.2
6.3
INDICE DE CONTENIDOS ....................................................................................................... 2
INDICE DE FIGURAS Y DIAGRAMAS .................................................................................... 2
INTRODUCCIÓN Y OBJETIVO ................................................................................................ 3
DESCRIPCIÓN DE LA EMPRESA ........................................................................................... 3
UBICACIÓN DEL PROYECTO DENTRO DE LA EMPRESA .................................................. 4
DESCRIPCIÓN DEL TRABAJO REALIZADO .......................................................................... 5
Descripción del departamento Sistemas de Información........................................................ 5
Descripción del área de Explotación del departamento Sistemas de Información................. 8
Definición del puesto de trabajo desarrollado, TAM ............................................................ 11
6.3.1
6.3.2
6.3.3
6.4
6.5
Aproximación histórica......................................................................................................................11
Contexto y alcance ...........................................................................................................................11
Rol y funciones ................................................................................................................................11
Tipología de Proyectos ......................................................................................................... 12
Gestión y coordinación de Proyectos según tipología .......................................................... 12
6.5.1
6.5.2
6.5.3
Proyectos de Desarrollo de Software ...............................................................................................12
Proyectos de Arquitectura e Infraestructura .....................................................................................14
Proyectos de Técnica de Sistemas...................................................................................................15
6.6
Proceso de implantación de proyectos ................................................................................ 16
6.6.1. Entornos de trabajo en la implantación de Proyecto ....................................................... 16
6.6.2. Objetivos del proceso de implantación de Proyectos ...................................................... 17
6.6.3. Roles ................................................................................................................................. 17
6.6.4. Documentación ................................................................................................................ 18
6.6.5. Diagrama de Detalle de la implantación de nuevos proyectos ........................................ 20
6.7
Proyectos realizados ............................................................................................................ 25
7
HERRAMIENTAS UTILIZADAS .............................................................................................. 28
8
APORTACIONES DEL PROYECTO A LOS CONOCIMIENTOS DEL ALUMNO .................. 29
9
APORTACIONES DE LOS ESTUDOIS REALIZADOS AL PROYECTO ............................... 29
10
CONCLUSIONES.................................................................................................................... 30
11
AGRADECIMIENTOS ............................................................................................................. 30
12
GLOSARIO.............................................................................................................................. 31
2. ÍNDICE DE FIGURAS Y DIAGRAMAS
Figura 1. Organización empresa: Divisiones de Soluziona por área de negocio ................................. 3
Figura 2. Consultoría en Soluziona: división sectorial en la oferta de servicios ................................... 4
Figura 3. Organigrama departamento Sistemas de Información ........................................................... 7
Figura 4. Diagrama de ciclo del flujo de peticiones ............................................................................... 7
Figura 5. Organigrama área Explotación ............................................................................................. 10
Diagrama de flujo 1. Fase inicial del proyecto .................................................................................... 20
Diagrama de flujo 2. Fase intermedia del proyecto ............................................................................. 21
Diagrama de flujo 3. Fase de implantación del proyecto en Preproducción ....................................... 22
Diagrama de flujo 4. Fase de implantación del proyecto en Producción ............................................. 23
Diagrama de flujo 5. Fase post-implantación del proyecto, Período de Garantía .............................. 24
Junio 2005
Página 2 de 2
3. INTRODUCCIÓN Y OBJETIVO
En el presente documento se proporciona la memoria de trabajo realizado en empresa con el
objetivo de exponer detalladamente las funciones, tareas y competencias llevadas a cabo en el
proyecto desarrollado en la empresa Soluciona como Technical Account Manager.
4. DESCRIPCIÓN DE LA EMPRESA
Soluziona es la empresa del grupo UNION FENOSA que integra la oferta de servicios
profesionales en las áreas de negocio de Ingeniería, Calidad y Medio Ambiente,
Telecomunicaciones y Consultoría. Con casi un total de 8.000 trabajadores, la presencia de
Soluziona alcanza 28 países en todo el mundo, significando el mercado nacional el 65% de su
actividad frente al 35% internacional.
Enmarcados en la división de Consultoría y Tecnología se ofrecen diferentes servicios, entre
los que se encuentra el de Outsourcing Tecnológico, área en que se ubica el proyecto aquí
descrito.
El cada vez más extendido servicio de Outsourcing Tecnológico nace para cubrir la necesidad
de adaptación de las empresas al cambio continuo y constante que sufren las Tecnologías de
la Información, debido a la complejidad del entorno y a la rápida evolución de todas las
alternativas y soluciones.
En la siguiente figura se muestra la organización de Soluziona por divisiones y se especifican
las áreas que integran cada división. Asimismo se enmarca el área de Outsourcing, donde se
ubica el desarrollo del proyecto que nos ocupa.
Soluziona
Ingeniería
•
•
•
•
Ingeniería
Energética
Ingeniería
Civil
Consultoría
Tecnológica
Gestión de la
Explotación
•
•
•
Calidad y
Medio
Ambiente
Telecomunicaciones
Ingeniería de
Calidad y
Procesos
Industriales
Consultoría y
Auditoría
Gestión de
Proyectos
•
•
•
Telemática
Redes
Infraestructuras
Consultoría
•
•
•
•
Estrategias
Procesos
RR.HH.
Sistemas
•
Outsourcing
Figura 1. Organización empresa: Divisiones de Soluziona por área de negocio.
Junio 2005
Página 3 de 3
5. UBICACIÓN DEL PROYECTO DENTRO DE LA EMPRESA
Como se ilustra en la Figura 1, el proyecto desarrollado en el puesto laboral se ubica en el área
de Outsourcing dentro de la división de Consultoría, que se dedica a ofrecer servicios y
soluciones en el ámbito de la gestión del ciclo de vida de las infraestructuras Tecnologías de la
Información.
El Outsourcing Tecnológico se dedica a diseñar soluciones y servicios innovadores e
implantarlos en el cliente, con el objetivo de alinear sus Tecnologías de la Información con los
objetivos de su organización, asegurando un funcionamiento 24x7, la máxima seguridad y
disponibilidad, y garantizando la calidad del servicio.
En Soluziona, la consultoría se caracteriza por organizar los servicios ofertados en base a una
escisión sectorial del mercado. Los sectores de mercado en que se desarrolla la actividad de
consultoría, y por tanto el outsourcing, son:
Utilities: soluciones integrales para las empresas del sector.
Telecomunicaciones y Media: soluciones integrales para el negocio de
Telecomunicaciones.
Banca y Servicios: banca transaccional por Inet, gestión bancaria, etc.
Industria y Gobierno: administración pública, consultoría en industria (ebusiness, e-consulting), etc.
CONSULTORÍA
S
E
R
V
I
C
I
O
S
DIMENSIÓN SECTORIAL
UTILITIES
TELECOMU
NICACIONES
Y MEDIA
INDUSTRIA
Y
GOBIERNO
BANCA Y
SERVICIOS
CENTROS DE
COMPETENCIA
MANAGEMENT
CONSULTING
SOFTWARE
FACTORY
OUTSOURCING
PROYECTO
GESTION DE
PROCESOS
Figura 2: Consultoría en Soluziona: división sectorial en la oferta de servicios.
Junio 2005
Página 4 de 4
En la matriz de la Figura 2 se muestra la relación entre los diferentes servicios de consultoría y
los sectores de mercado en que se ofertan. Además en ésta se ha señalado la ubicación
exacta del proyecto, que se sitúa en el área de Outsourcing para el sector de las
Telecomunicaciones y Media.
Por tanto el proyecto que se está desarrollando está enmarcado dentro del servicio de
Outsourcing que Soluziona, junto con otra multinacional del sector de las Tecnológicas (IBM),
ofrece a uno de sus clientes del sector de empresas de Telecomunicaciones y Media,
concretamente se trata de la empresa nacional de transmisión de señal audiovisual (Abertis
Telecom).
6. DESCRIPCIÓN DEL TRABAJO REALIZADO
Este capítulo tiene como objetivo describir detalladamente en qué consiste el trabajo
desempeñado en la empresa. Llegados a este punto y con el fin de facilitar la comprensión del
rol del puesto de trabajo desarrollado, creo conveniente proceder, mediante una liviana
introducción, a realizar una aproximación de cómo está organizado el departamento de
Sistemas de Información del cliente en el que se lleva a cabo el proyecto.
6.1. Descripción del departamento Sistemas de Información
El departamento de Sistemas de Información del cliente está dividido en tres grandes áreas
técnicas, que son Desarrollo, Explotación y Arquitectura e Infraestructura.
A continuación se perfila brevemente, para cada área del departamento, las funciones que
tienen en la compañía, el perfil de los profesionales que la integran y la interacción con otros
departamentos.
•
Desarrollo. El objetivo del área de Desarrollo es la creación de nuevas aplicaciones en
la empresa, tanto de negocio como corporativas, mediante el desarrollo de software.
Esta área está formada por profesionales con perfiles propios del mundo de la
Ingeniería del Software, como jefes de proyecto, analistas, diseñadores,
programadores, ejecutores de planes de prueba, expertos en mantenimiento correctivo
o evolutivo del software, etc.
Desarrollo da servicio al resto de departamentos de la compañía. Es decir, cuando
cualquier otro departamento de la empresa tiene un requerimiento especial para llevar
a cabo su operativa diaria y no está soportado por ningún sistema informático, si se
desea informatizarlo, nace la petición de un nuevo proyecto de desarrollo de software
para crear la aplicación o sistema que dé solución a la carencia detectada. Asimismo,
cuando debido a la evolución de los procedimientos de la compañía alguno de los
sistemas necesita incluir nuevas funcionalidades, también surge la solicitud de proyecto
para desarrollar una nueva fase del aplicativo o sistema ya existente.
•
Explotación. El área de Explotación se encarga de la explotación de todos los
sistemas que componen la infraestructura informática de la compañía. La función
principal de este grupo es velar por el correcto estado y funcionamiento de los
sistemas, garantizando el servicio de todos los servidores y equipos informáticos. Este
equipo humano se encarga de la administración, parametrización, monitorización,
mantenimiento y optimización de todos los servidores y equipos de red, a todos los
niveles, desde el sistema operativo hasta cualquier producto de software base
instalado, como pueden ser motores gestores de base de datos, motores de servidores
web, sistemas de correo, etc.
El grupo de Explotación es también el responsable de garantizar la recuperación de los
sistemas ante cualquier contingencia al ser de su competencia la administración y
mantenimiento de la infraestructura de backup de la compañía. En este sentido el área
Junio 2005
Página 5 de 5
de Explotación tiene un papel clave en el departamento de Sistemas de Información, ya
que en caso de desastre es a quien compete tanto poner en marcha como ejecutar con
éxito el SRD (Sistema de Recuperación ante Desastres).
De igual forma, es también responsabilidad de Explotación la gestión de la
monitorización de los sistemas, función importantísima en entornos productivos 24x7
desde el punto de vista que permiten una detección anticipada de posibles incidencias
en los servidores, ya que en muchas ocasiones estos mecanismos de monitorización
permiten una proactividad en la detección de futuros problemas potenciales, en el
sentido en que se pueden tomar medidas correctivas consiguiendo así evitar la
aparición del problema.
El equipo de profesionales que integra esta área tiene un grado de especialización muy
elevado en aquellos sistemas que administra. Luego los perfiles que predominan son
los de expertos en productos de software base, ya sea el sistema operativo, o un
sistema gestor de BBDD, o un software de gestión de monitorización, o bien el sistema
de correo, incluso software de gestión de almacenamiento, etc. Es decir, son
especialistas en las infraestructuras de Tecnologías de la Información, como son los
técnicos de sistemas, administradores de S.O., administradores de BBDD (DBAs),
ingenieros de hardware, etc.
Explotación da servicio a toda la compañía en el sentido en que se encarga de explotar
las Tecnologías de la Información que soportan los sistemas que se utilizan en todos
los departamentos, pero los peticionarios directos hacia Explotación son las otras áreas
de Sistemas de Información: Desarrollo y Arquitectura e Infraestructura.
•
Arquitectura e Infraestructura. Entre otros de menor relevancia, los objetivos
prioritarios del área de Arquitectura e Infraestructura son dos, por una parte la
definición de nuevas arquitecturas en las Tecnologías de la Información de la
compañía, y por otra la gestión de las infraestructuras físicas de CPD existentes.
Los perfiles profesionales de los integrantes de esta área son los de Arquitecto e
Ingeniero Hardware. Por lo general, los arquitectos acostumbran a ser profesionales
con una dilatada experiencia en el área de la técnica de sistemas, es decir personal
técnico que tiene a sus espaldas un largo recorrido de años de experiencia en la
Explotación de Sistemas.
Al igual que sucedía en Explotación, las áreas que realizan peticiones directas a
Arquitectura e Infraestructuras son las otras de Sistemas de Información: Desarrollo y
Explotación.
Ya perfilado el rol que juega cada área en el departamento de Sistemas de Información, se
incluyen a continuación dos figuras para ilustrar gráficamente lo descrito anteriormente.
En la Figura 3 se muestra el organigrama del departamento de Sistemas de Información por
áreas con las competencias fundamentales de cada una.
En la Figura 4 se incluye un diagrama de ciclo para reflejar el proceso del flujo de peticiones
entre las áreas que integran el departamento de Sistemas de Información. Como se puede
observar, se trata de un departamento que se retroalimenta, desde el punto de vista que el
trabajo que realiza un área tiene su origen en las peticiones que genera otra área para
conseguir sus objetivos.
Junio 2005
Página 6 de 6
Sistemas de
Información
Arquitectura e
Infraestructura
Desarrollo
•
•
•
•
Desarrollo de
software
Definición
nuevos
proyectos
Diseño
nuevas
aplicaciones
Programación
nuevas
aplicaciones
•
•
•
Definición nuevas
arquitecturas
Provisión nuevas
infraestructuras
tecnológicas de CPD
Mantenimiento
infraestructuras CPD
Explotación
•
•
•
•
•
•
•
Explotación sistemas
Administración sistemas
Monitorización sistemas
Mantenimiento HW
Plan SRD
Operación 24x7
Ingeniería y Proyectos
Figura 3. Organigrama departamento Sistemas de Información
Departamentos
externos
Flujo de peticiones entre las áreas del
Departamento Sistemas de Información
Desarrollo
Explotación
Arquitectura e
Infraestructura
Figura 4. Diagrama del ciclo de flujo de peticiones
Junio 2005
Página 7 de 7
6.2. Descripción del área Explotación del departamento Sistemas de Información
El puesto de trabajo desarrollado dentro del servicio de Outsourcing de la gestión de los
Sistemas de Información del cliente se enmarca en el área de Explotación.
El equipo de Explotación integra el área más extensa y numerosa de Sistemas de Información.
Por este motivo está a su vez subdividida en tres niveles organizativos: Técnica de Sistemas,
Operación, e Ingeniería y Proyectos, en adelante, TECSI, OPER e INPRO, respectivamente
(permítanme la utilización de acrónimos para abreviar). En esta última subárea de INPRO se
ubica el puesto de trabajo cuyo desarrollo da lugar al proyecto expuesto en esta memoria.
A continuación se describen brevemente los equipos que componen el área de Explotación.
•
Operación CPD. Debido a la existencia de sistemas críticos para el negocio de la
empresa, los cuales requieren una disponibilidad de 24 horas los 7 días de la semana,
existe el equipo de OPER que se encarga de la monitorización de todos los sistemas y
de la ejecución de los procedimientos automatizados y definidos por el resto de
subáreas de Explotación.
Este grupo tiene una presencia de 24 horas al día, organizado por turnos, precisamente
para poder monitorizar los sistemas críticos en cualquier franja horaria.
OPER es el área que asume bajo su responsabilidad los siguientes procedimientos y
además en este orden: monitorización de sistemas, detección de alarmas, identificación
de los procedimientos asociados a estas alarmas, y finalmente, cuando aplica,
escalado de incidencias a otros grupos de Explotación.
Este equipo también se encarga de la ejecución de los procesos batch de la compañía,
así como de su implementación en los sistemas de software de agentes de
programación de trabajos.
En caso de incidencias o desastre, es el equipo encargado de la detección de alertas
así como de iniciar el mecanismo de resolución. De hecho es el grupo que, ante una
crisis, activa el engranaje de funcionamiento de Explotación.
•
Técnica de Sistemas. El área de TECSI la integra el conjunto de administradores de
sistemas tales como DBAs, administradores de sistema operativo Unix,
administradores de sistema operativo Wintel, administradores de sistemas de
almacenamiento, técnicos de servidores web, administradores de sistema de correo,
administradores de red, técnicos de Seguridad, etc.
Sus integrantes conforman el personal con el perfil de mayor especialización en
conocimiento técnico por áreas tecnológicas.
Son competencia de este grupo las siguientes responsabilidades: implementación de la
monitorización de los servidores y equipos de red, definición de los planes de seguridad
y cumplimiento de la L.O.P.D., implementación de los planes de backup, elaboración de
los planes de contingencia de los sistemas de la compañía, así como la administración,
optimización, parametrización y mantenimiento hardware y software de todos los
sistemas.
Además, son también responsables, mancomunadamente junto al área de INPRO, de
la aplicación y ejecución del plan de recuperación ante desastres.
•
Ingeniería y Proyectos. Como su propio nombre anuncia, este equipo juega un rol
más cercano a la investigación y desarrollo de las Tecnologías de la Información. El
grupo de Ingeniería y Proyectos se crea en Explotación para dar cabida a todas
aquellas funciones que no acaban de encajar en un área relativamente hermética como
puede ser TECSI o OPER.
Junio 2005
Página 8 de 8
Entre otras, las dos grandes competencias que recaen bajo la responsabilidad de
INPRO son la gestión de proyectos y albergar el centro de conocimiento.
a) Centro de Conocimiento:
INPRO es el área que tiene una visión global de toda la Infraestructura Informática de
la compañía, a diferencia de las áreas hermanas OPER y TECSI en las que prevalece
la especialización y por tanto una visión segmentada de los sistemas. Precisamente
INPRO equilibra, dentro del departamento de Explotación, la carencia acaecida en las
áreas de OPER y TECSI en lo que respecta a la falta de conocimiento global a favor de
la especialización.
De hecho INPRO alberga el mayor centro de conocimiento de todos los sistemas de la
empresa, ya que sus integrantes son los conocedores de todos los servidores y
equipos de red, independientemente del sistema operativo o el motor de base de datos
instalado (como sucedería en los grupos de TECSI), incluso independientemente de si
están o no monitorizados (como sucedería en los grupos de OPER).
No sólo eso, ya que no en vano este equipo concentra el saber de todas las
aplicaciones de la compañía. Por ejemplo INPRO es el grupo de referencia para
establecer o determinar la criticidad de cada sistema, información clave en caso de
caídas o planificación de intervenciones, desde el punto de vista que sería el área que
indicaría cómo (área de negocio) y a quién (área usuaria) afectaría esa caída o
intervención. También es de su competencia el conocimiento de las relaciones entre los
diferentes sistemas y aplicaciones, es decir las interficies y procesos entre los distintos
entornos, de manera que ante cualquier incidencia en un punto determinado del mapa
global de procesos y sistemas, INPRO es capaz de identificar todas las posibles
implicaciones y afectaciones en el resto de sistemas.
Como consecuencia de la centralización del conocimiento de los sistemas en esta área,
los profesionales que la integran tienen un papel endémico de coordinación e
intermediación en Explotación.
b) Gestión de Proyectos:
La otra vertiente fuerte de INPRO se encuentra en la gestión de proyectos, donde juega
un papel que hace converger a todas las áreas implicadas en el ciclo de vida de un
proyecto. Las tareas que se llevan a cabo en INPRO con respecto a la gestión de
proyectos abarca diferentes frentes, como son,
Junio 2005
La definición de la metodología a seguir en la coordinación e implantación de
proyectos.
La definición del procedimiento a seguir en la puesta en producción de nuevos
sistemas.
La coordinación técnica de las áreas implicadas a lo largo de todas las fases
del ciclo de vida del proyecto.
La recopilación y gestión de la documentación relativa a proyectos.
La definición de documentos exigibles y entregables para los proyectos.
La planificación del proyecto y el seguimiento de la misma, realizando las
correcciones que sean necesarias en caso de desviación.
Ayuda en el diseño de proyectos.
Estrecha colaboración con Arquitectura y Desarrollo en las fases de diseño e
implementación.
Adaptación de los requerimientos de proyecto a las infraestructuras disponibles
en la compañía.
Investigación nuevas tecnologías y estudio de su aplicación a los proyectos.
Interlocución entre todas las áreas implicadas en el proyecto, la figura de
INPRO representa el punto focal entre el resto de departamentos.
Una vez implantado el proyecto, traspaso de conocimiento del sistema a las
áreas de Explotación a quien corresponda su administración.
Página 9 de 9
c) Otros:
Adicionalmente a las dos principales, existen otras varias y divergentes funciones que
ejerce el grupo de INPRO; a continuación se detallan:
Centro de conocimiento.
Gestión de proyectos.
Definición de metodología en gestión de cambios.
Definición de metodología en gestión de problemas.
Adaptación del Outsourcing a metodología ITIL.
Gestión y seguimiento del servicio.
Definición procedimientos de Explotación.
Gestión de la documentación de Explotación.
Investigación de nuevas tecnologías.
Soporte a aplicaciones productivas.
Administración entornos de Reporting.
Debido a la miscelánea que constituye la lista de responsabilidades de INPRO, el perfil
de los profesionales que integran esta área tiene un origen diverso, si bien es cierto
que principalmente proceden, o bien de las áreas de Desarrollo o bien de las áreas de
Técnica de Sistemas. El perfil más habitual es el de ex jefe de proyecto o ex técnico de
sistemas, aunque también pueden encontrarse perfiles de antiguos arquitectos.
Con el fin de plasmar todo lo expuesto en este apartado y a modo de resumen se
incluye a continuación, en la Figura 5, el organigrama del área de Explotación.
Explotación
Técnica de
Sistemas
•
•
•
•
•
•
•
•
•
Admin. Unix
Admin Wintel
Admin BBDD
Admin Backup
Admin PSA
Capacity Planning,
gestión almacenamiento
Admin Sistema Correo
Técnicos Networking
Seguridad Informática
Operación
CPD
•
•
•
•
•
•
Operación 24x7
Ejecución procesos
batch
Ejecución procesos
especiales
Monitorización
sistemas 24x7
Gestión de alarmas
Escalado de
incidencias
Ingeniería y
Proyectos
•
TAM:
Investigación
nuevas
tecnologías
o Gestión de
proyectos
o Metodología de
proyectos
o Gestión del
servicio
Metodología ITIL en
Outsourcing
Gestión de Datos
Soporte aplicaciones
productivas
Gestión Documentación
o
•
•
•
•
Figura 5. Organigrama área Explotación
Junio 2005
Página 10 de 10
6.3. Definición del puesto de trabajo, TAM (Technical Account Manager)
Como ya se ha adelantado en el apartado anterior, el puesto de trabajo desarrollado como
TAM (Technical Account Manager) está ubicado en el área de Ingeniería y Proyectos de
Explotación.
6.3.1. Aproximación histórica
El origen del puesto de TAM se remonta a la época de auge y crecimiento de los
departamentos de Sistemas de Información en las empresas americanas a finales de la década
de los ochenta. Nació como resultado de la histórica confrontación entre los departamentos de
Desarrollo y Explotación, con el objetivo de atenuar las diferencias entre ambos e intentar
aproximarlos. Por tanto la figura del TAM surgió en sus inicios como un elemento conciliador
que se hacía necesario en aquellas empresas que veían crecer sus departamentos de
Sistemas de Información hasta niveles ciertamente difíciles de controlar. Se intentaba crear un
elemento neutral para establecer procedimientos que facilitasen la relación entre los equipos de
desarrollo y explotación de sistemas, de manera que el proceso global de implantación de
proyectos mejorase notablemente al tener un interlocutor y coordinador entre todas las áreas
implicadas en las fases del ciclo de vida de un proyecto.
Con el tiempo el rol del TAM se fue adaptando a nuevas situaciones en la empresa, de manera
que acabó por transformarse en un perfil técnico de gestión y coordinación entre diferentes
áreas técnicas, que no tenían porqué ser necesariamente Desarrollo y Explotación.
En la actualidad, al menos en el caso que nos ocupa, la figura de TAM ha evolucionado
incluyendo en su catálogo de responsabilidades otras tareas adicionales a las de sus inicios.
No obstante, la principal ocupación de la figura de TAM sigue siendo la gestión y coordinación
técnica de proyectos junto a la interlocución entre áreas técnicas.
6.3.2. Contexto y Alcance
El proceso de implantación de nuevos proyectos forma parte del ciclo de desarrollo e
implantación de nuevos aplicativos de negocio o infraestructuras de sistema en la empresa.
Para su realización, todas las áreas implicadas se apoyan en el TAM como punto focal.
En este contexto, las relaciones que se establecen entre las diferentes áreas que participan en
el ciclo de vida de un proyecto, tienen siempre como mediador un TAM.
6.3.3. Rol y Funciones
El rol esencial del TAM estriba en la coordinación de nuevos proyectos, ejerciendo la
interlocución entre los equipos implicados, orientándolos hacia la metodología de trabajo a
seguir y colaborando estrechamente en el diseño, la planificación y la puesta en producción.
Se procede a pormenorizar las funciones que abarca el rol del TAM en la gestión de proyectos:
•
Coordinación y gestión de proyectos:
Coordinación de los recursos así como de la disponibilidad de infraestructuras.
Estrecha colaboración con todas las áreas implicadas para la consecución de
los objetivos del proyecto.
Mediación entre las áreas técnicas copartícipes.
Evaluación de riesgos y toma de decisiones ante los hitos de proyecto.
Planificación y seguimiento de la misma.
Definición de plan de acción correctivo en caso de desvío en la planificación.
Orientación a los equipos de desarrollo hacia la metodología de trabajo de
Explotación.
Adecuación del diseño del proyecto a las infraestructuras disponibles.
Junio 2005
Página 11 de 11
En caso de inviabilidad técnica del diseño facilitado, elaboración y entrega de
propuesta de arquitectura alternativa a los equipos de desarrollo.
Apoyo en las tareas de análisis.
Supervisión y seguimiento de la consecución de hitos en cada fase del ciclo de
vida del proyecto.
Recopilación, validación, corrección y aceptación de la documentación
entregada sobre el nuevo sistema.
Aprobación técnica de la implantación del sistema en Producción.
Inclusión del nuevo sistema en las herramientas de gestión de Explotación
(monitorización, backup, gestión de escalado de incidencias, etc).
Coordinación de la Puesta en Producción del proyecto.
Traspaso de conocimiento del proyecto a las áreas técnicas que deban asumir
la explotación del nuevo sistema.
Otras funciones responsabilidad del TAM, que complementan y ayudan en la gestión de
proyectos, son:
•
•
•
•
Creación de procedimientos para definir estándares de trabajo.
Control de los entornos de trabajo utilizados en la implantación de proyectos:
Desarrollo, Integración, Preproducción y Producción.
Gestión de la documentación.
Centro de conocimiento de los sistemas implantados en Explotación.
Además, de forma más o menos activa según el grado de implicación, el TAM colabora e
interviene en todas las tareas y funciones vinculadas a la responsabilidad del grupo INPRO
descritas en el episodio 6.2.
6.4. Tipología de Proyectos
En este apartado se procede a separar por tipos los proyectos que se coordinan desde el
puesto de TAM. La clasificación se ha realizado en base a tres criterios:
I. El área o departamento origen que genera el proyecto
II. Las funciones que realiza el TAM en el proyecto
III. La metodología de trabajo utilizada en el proyecto
Luego si aplicamos como principio de división las variables anteriores resulta la siguiente
tipología de proyectos:
Proyectos de Desarrollo de Software.
Proyectos de Arquitectura e Infraestructura.
Proyectos de Técnica de Sistemas.
6.5. Gestión y coordinación de Proyectos según tipología
En las próximas secciones se definen los tres tipos de proyecto gestionados, concretando las
características y peculiaridades en la gestión y coordinación de cada tipo.
6.5.1. Proyectos de Desarrollo de Software
Los proyectos de Desarrollo de Software son aquellos en los que se crea una aplicación a
medida para dar solución a los requerimientos y necesidades de un área de la empresa
mediante el desarrollo y la implantación de un sistema de información.
En éstos, el equipo que genera la solicitud de nuevo proyecto es el área de Desarrollo del
departamento de Sistemas de Información.
Junio 2005
Página 12 de 12
El orden en el flujo de trabajo para la gestión de este tipo de proyecto es el que sigue:
1. El Jefe de Proyecto del equipo de Desarrollo convoca al TAM a reunión de kick off para
realizar la presentación del proyecto, estableciéndose en ésta una fecha de
compromiso para la entrega de documentación inicial.
2. El equipo de Desarrollo realiza las fases de análisis de requerimientos y diseño lógico
del ciclo de vida del proyecto y lo hace llegar al TAM en la fecha acordada en el punto
1.
3. Entre Desarrollo y el TAM se fija la planificación del resto de fases del proyecto.
4. El TAM evalúa el diseño lógico y verifica su compatibilidad con la arquitectura,
infraestructuras tecnológicas y herramientas de desarrollo disponibles en la empresa.
5. Concluso el estudio del punto 4, el TAM resuelve la viabilidad técnica del diseño lógico
presentado por Proyecto, en función de si existen o no todos los elementos necesarios
para el desarrollo.
6. En caso afirmativo (viable técnicamente), el TAM lo notifica a Proyecto y se inicia la
fase de diseño físico o programación.
7. En caso negativo (inviable técnicamente), el TAM lo notifica a Proyecto. En este punto
el TAM, junto con el apoyo de las áreas de Arquitectura y Técnica de Sistemas, se
encarga de elaborar una propuesta alternativa para los elementos afectados en la
inviabilidad, de manera que el diseño encaje en las infraestructuras disponibles en la
compañía. El cambio propuesto y recomendado puede afectar a un software o
herramienta de desarrollo, o al gestor de base de datos, a las características hardware
del servidor, a la ubicación física de los datos, o, en definitiva, a un sinfín de elementos
implicados. El criterio aplicado en esta toma de decisiones se basa en el conocimiento
del resto de sistemas de la compañía, en la posibilidad de implicaciones negativas en
sistemas críticos, en el posible impacto en el rendimiento de algún servidor afectado,
etc. Si el equipo de Desarrollo acepta la propuesta, se realiza el cambio en el diseño y
se procede a iniciar la fase de programación. Si por el contrario la propuesta es
rechazada, se debe crear un comité de conflicto para desbloquear la situación hasta
llegar a consenso.
8. Finalizado el diseño físico o programación, el equipo de Desarrollo procede a implantar
y probar el sistema en el entorno de Desarrollo.
9. El TAM realiza seguimiento de los hitos de cada fase y verifica si se cumplen los
objetivos, para en caso negativo, reconducir la situación.
10. Cuando el punto 8 ha finalizado con éxito, el equipo de Desarrollo implanta y prueba el
sistema en el entorno de Integración.
11. Cuando el punto 10 termina satisfactoriamente, el equipo de Desarrollo realiza fase de
pruebas en el entorno de Preproducción.
12. A continuación se realiza el TAU (Test de Aprobación de Usuarios) en el entorno de
Preproducción.
13. El equipo de Proyecto entrega la documentación del proyecto al TAM.
14. El TAM valida, corrige, y finalmente aprueba toda la documentación necesaria para
Explotación.
15. El TAM dictamina si todo está preparado para la Puesta en Producción del proyecto, es
decir la implantación del sistema en el entorno Productivo real y definitivo.
16. El TAM prepara, organiza y planifica las sesiones de traspaso de conocimiento y
formación hacia los grupos que se van a encargar de la administración, mantenimiento
y escalado de incidencias de las plataformas implicadas en el nuevo sistema.
17. Una vez los grupos receptores de la administración del sistema han asumido el
conocimiento y la documentación está al 100% entregada y validada, el TAM junto con
todas las áreas implicadas planifica y coordina la Puesta en Producción del proyecto.
18. El Jefe de Proyecto elabora y define el Plan de Marcha Atrás.
19. Implantación del sistema.
20. En caso de fracaso en la implantación, el Jefe de Proyecto y el TAM coordinan
mancomunadamente el Plan de Marcha Atrás.
21. Si la implantación finaliza con éxito, se inicia el periodo de Garantía.
22. Sistema en explotación estable.
Junio 2005
Página 13 de 13
6.5.2. Proyectos de Arquitectura e Infraestructura
Los proyectos de Arquitectura e Infraestructura son aquellos en los que se cambia o sustituye
arquitectura clave de la Infraestructura Tecnológica de la compañía. Los motivos que dan lugar
a proyectos de tal envergadura acostumbran a ser la propia evolución de las Tecnologías de la
Información, tan rápida que en ocasiones deja obsoleto a un sistema que hace relativamente
poco tiempo era lo sumo de la innovación. Otras veces las razones que generan este tipo de
proyecto son la política de renovación tecnológica de la empresa. En ocasiones incluso, estos
proyectos surgen como consecuencia de restricciones económicas en la compañía para
conseguir una reducción de costes, varía en cada caso.
En estos proyectos, el equipo que genera la solicitud de nuevo proyecto puede ser bien el área
de Arquitectura e Infraestructuras del departamento de Sistemas de Información, o bien la
propia Dirección del departamento de Sistemas de Información.
La gestión y las tareas llevadas a cabo por el TAM varían en este tipo de proyectos, generando
el flujo de trabajo detallado a continuación:
1. El Jefe de Proyecto del área de Arquitectura e Infraestructura (en adelante, ARQIN)
convoca al TAM a reunión de kick off para realizar la presentación del proyecto,
explicando en qué estriba la transformación tecnológica que se va a producir. En esta
reunión se establece un calendario para la primera entrega de documentación.
2. El equipo de ARQIN remite al TAM la documentación sobre arquitectura y diseño del
cambio en la fecha consensuada en el punto 1.
3. Entre ARQIN y el TAM se fija la planificación del resto de fases del proyecto.
4. El TAM evalúa los cambios propuestos e identifica las implicaciones en los equipos de
Explotación.
5. El TAM elabora un informe con las implicaciones del cambio a todos los niveles, tanto
en el trabajo de los recursos humanos como en el resto de infraestructura tecnológica.
6. El TAM calcula los costes y esfuerzo en horas de técnicos para las diferentes fases del
proyecto, tarea necesaria para planificar.
7. Las áreas de Explotación afectadas por estos cambios (OPER, INPRO y TECSI) deben
validar, asumir y aprobar estos cambios.
8. En caso de consenso (resolución afirmativa punto 7), se inicia la elaboración del plan
de puesta en marcha del cambio tecnológico.
9. En caso negativo (resolución negativa punto 7), el TAM, unido en estrecha
colaboración con ARQIN, debe resolver los cambios necesarios y redefinir el proyecto
de manera que sea viable para las áreas de Explotación.
10. Una vez aceptada la viabilidad técnica por parte de todos los equipos implicados, el
TAM conjuntamente con ARQIN planifica y define el plan de implantación.
11. Los equipos de ARQIN y TECSI llevan a cabo el cambio en un entorno de pruebas lo
más aproximado posible con el entorno productivo real.
12. Si las pruebas del punto 11 se llevan a cabo con éxito, el TAM confecciona la lista de
tareas técnicas necesarias y las planifica.
13. El equipo de Proyecto entrega al TAM la documentación del nuevo sistema.
14. El TAM recopia, valida, corrige y finalmente aprueba toda la documentación necesaria
para la explotar la nueva infraestructura o arquitectura a implantar.
15. El TAM y el resto de áreas implicadas deciden si todo está listo para la Puesta en
Producción del proyecto, es decir la implantación del cambio en el entorno Productivo
real.
16. El TAM prepara, organiza y planifica las sesiones de traspaso de conocimiento y
formación hacia los grupos que se van a encargar de la administración y
mantenimiento de las plataformas implicadas en el nuevo sistema.
17. Una vez los grupos receptores de la administración del sistema han asumido el
conocimiento y la documentación está al 100% entregada y validada, el TAM junto con
todas las áreas implicadas planifica y coordina la Puesta en Producción del proyecto.
18. El TAM elabora y define el Plan de Marcha Atrás de la implantación.
20. En caso de fracaso en la implantación, el TAM coordina el Plan de Marcha Atrás.
Junio 2005
Página 14 de 14
6.5.3. Proyectos de Técnica de Sistemas (Proyectos Internos)
Los proyectos de Técnica de Sistemas son aquellos que nacen dentro del departamento de
Explotación para ser diseñados e implementados por el propio departamento de Explotación y
a los que por este motivo también llamamos PI (Proyectos Internos). Los ejemplos más
frecuentes de este tipo de proyecto son los upgrades de versión de productos de plataforma
estandar, o cambios en las herramientas de trabajo propias y exclusivas del área de
Explotación.
De hecho la gestión de este tipo de proyecto tiene un flujo de trabajo muy similar al de los
proyectos de Arquitectura e Infraestructura, la única diferencia se basa en que los partícipes en
la gestión son de un único departamento, Explotación, con lo que el proceso se simplifica y
agiliza.
A continuación se precisa el flujo de trabajo en la coordinación de este tipo de proyecto,
identificando las funciones desarrolladas por el TAM:
1. El Jefe de Proyecto del área de Explotación (en ocasiones podría ser el mismo TAM)
convoca al TAM (o Explotación, según el caso) a reunión de kick off para realizar la
presentación del proyecto, explicando en qué estriba el proyecto interno que se va a
desarrollar. En esta reunión se establece un calendario para la primera entrega de
documentación.
2. El TAM recopila la documentación inicial sobre arquitectura y diseño del cambio en la
fecha consensuada en el punto 1.
3. El TAM efectúa planificación para el resto de fases del proyecto.
4. El TAM evalúa los cambios propuestos e identifica las implicaciones en los equipos de
Explotación, elaborando al fin del estudio un informe con las implicaciones que la
implantación del proyecto puede originar a todos los niveles, tanto en procesos ya
existentes como en el resto de infraestructura tecnológica.
5. Las áreas de Explotación afectadas por estos cambios (OPER, INPRO o TECSI) deben
validar, asumir y aprobar estos cambios.
6. En caso de consenso (resolución afirmativa punto 5), el TAM precisa el plan de puesta
en marcha del proyecto.
7. En caso negativo (resolución negativa punto 6), el TAM, unido en estrecha
colaboración con el área de Explotación que se posiciona en contra, debe resolver los
cambios necesarios y redefinir el proyecto de manera que sea viable técnicamente.
8. Una vez aceptada la viabilidad técnica por parte de todos los equipos implicados, el
TAM planifica y define el plan de implantación un entorno de pruebas lo más parecido
posible al entorno productivo real.
9. Si las pruebas del punto 8 se llevan a cabo con éxito, el TAM confecciona la lista de
tareas técnicas necesarias y las planifica.
10. El equipo de Proyecto entrega al TAM la documentación del nuevo sistema.
11. El TAM recopia, valida, corrige y finalmente aprueba toda la documentación necesaria
para la explotar la nueva infraestructura o arquitectura a implantar.
12. Explotación decide si todo está listo para la Puesta en Producción del proyecto, es
decir la implantación del cambio en el entorno Productivo real.
13. Explotación prepara las sesiones de traspaso de conocimiento y formación hacia los
grupos que se van a encargar de la administración y mantenimiento de las plataformas
implicadas en el nuevo sistema, mientras que el TAM organiza los grupos y planifica
las sesiones.
14. El TAM elabora y define el Plan de Marcha Atrás de la implantación.
16. En caso de fracaso en la implantación, el TAM coordina el Plan de Marcha Atrás.
Junio 2005
Página 15 de 15
6.6. Proceso de implantación de Proyectos
El proceso de implantación de nuevos proyectos forma parte del trabajo realizado por el TAM.
Además representa el desarrollo de Ingeniería en el departamento de Sistemas de Información
y se considera el resultado de su I+D. En los siguientes apartados se describe el proceso.
A priori y con el fin de explicar en todo su alcance el proceso de implantación de proyectos,
creo necesario definir previamente el contexto o ámbito tecnológico en que se desarrolla, que
contempla cuatro entornos:
Desarrollo
Integración
Preproducción
Producción
6.6.1. Definición entornos de trabajo en la implantación de Proyectos
En este punto se traza una breve descripción de cada uno de los entornos que componen el
escenario físico del proceso global de implantación de proyectos.
Conviene tener presente que la existencia de los cuatro entornos que a continuación se perfilan
se da únicamente en los proyectos de Desarrollo de Software.
•
Entorno de Desarrollo. Es el primer entorno de pruebas del proyecto. Por lo general la
arquitectura de este entorno consiste en un único servidor que desempeña una función
multiplataforma en el sentido en que se utiliza como servidor de BBDD, servidor web,
servidor de aplicación, etc. Se utiliza por el equipo de Proyecto que desarrolla el
sistema a implantar. Explotación administra y opera este entorno.
•
Entorno de Integración. Es el segundo entorno en que se implanta el sistema
desarrollado para la realización de pruebas. Acostumbra a ser un entorno similar al de
Desarrollo, aunque el servidor suele disponer de mejores características HW que lo
hacen más potente en cuanto a capacidad de procesamiento, y por tanto más
apropiado para realizar pruebas con un mayor número de usuarios, de manera que
simule lo más fielmente posible el futuro funcionamiento real. Se utiliza por el equipo de
Proyecto para realizar las pruebas unitarias, integradas a nivel funcional. Explotación
administra y opera este entorno hasta que el proyecto pasa a Producción.
Normalmente este entorno no seguirá vigente después del paso a Producción,
eliminando las subidas de aplicativo realizadas en él.
•
Entorno de Preproducción. Es el entorno previo al entorno productivo definitivo en
que se instalará el nuevo sistema. Por tanto debe ser, si no idéntico, sí lo más parecido
posible al entorno de Producción tanto en características HW de los servidores y
equipos que totalizan la arquitectura, como en la configuración de los mismos. Es decir
el entorno de Preproducción debe ser una réplica del entorno de Producción. La subida
del sistema a este entorno constituye un ensayo real por ser una simulación
estrictamente exacta de lo que será la subida del sistema a Producción. Se utiliza
conjuntamente por el equipo de Proyecto y Explotación para realizar las pruebas de
carga (stress) y de sistema.
•
Entorno de Producción. Es el entorno final. Su arquitectura corresponde a la imagen
precisa del diseño desarrollado y aprobado para el proyecto. Se trata del entorno crítico
por antonomasia al ser el que da servicio a los usuarios y a las áreas de negocio de la
empresa, ya que es el entorno que alberga el aplicativo en explotación. Se utiliza por el
equipo de Explotación para la explotación del sistema, quien opera y administra este
entorno.
Los entornos de Integración, Preproducción y Producción deberían ser copias replicadas en
cuanto a especificaciones de aplicativos. Es decir, las versiones del software desarrollado
deberían ser idénticas.
Junio 2005
Página 16 de 16
Además de la premisa anterior, añadir para los entornos de Preproducción y Producción que
deberían ser copias replicadas en cuanto a volumen de datos y capacidad de concurrencia de
usuarios.
6.6.2. Objetivos del proceso de implantación de Proyectos
En este punto se precisan los objetivos básicos del proceso de implantación de proyectos:
Recoger los requerimientos de plataforma y operación de todo nuevo
proyecto.
Alinear dichos requerimientos con las características de sistema y
operativas de las instalaciones actuales de los entornos de desarrollo,
integración, preproducción y producción.
Coordinar las actividades de los distintos grupos involucrados de manera
que se puedan automatizar al máximo y evitar así errores humanos.
Minimizar los riesgos de implantación.
Realizar el Paso a Producción del nuevo sistema.
6.6.3. Roles
A continuación se especifican los roles que ejercen los integrantes del equipo que participa en
el proceso de implantación de proyectos:
•
Área que genera petición de proyecto (puede ser cualquier área de SINFO:
ARQIN, DESA o EXPLO):
o
o
o
o
o
o
•
Explotación:
o
o
o
•
Coordina las acciones entre las Areas Funcionales y el equipo de Proyecto,
desde el comienzo del proyecto
Elabora y desarrolla el Plan del proyecto, incluyendo el plan de pruebas.
Supervisa la evolución y los hitos del proceso.
Propone la disponibilidad del sistema para su paso a producción, velando
especialmente por la viabilidad de la explotación del sistema.
Realiza la verificación y las pruebas técnicas en los entornos de preproducción
y Producción.
Mantiene informado en todo momento al TAM del seguimiento del proyecto.
Supervisa la evolución y los hitos del proceso
Acepta la disponibilidad del entorno de preproducción antes de su paso a
explotación.
Valida la viabilidad de compromisos temporales y de nivel de servicio exigido.
Coordinador de nuevos proyectos, TAM:
o
o
o
o
o
o
o
o
o
Junio 2005
Coordina los recursos así como la disponibilidad de infraestructuras
Colabora estrechamente con el área peticionaria y Explotación para la
consecución de los objetivos del proyecto.
Valida la documentación entregada sobre el nuevo sistema como requisito
previo a la implantación del proyecto.
Evalúa riesgos y decide ante los hitos de proyecto.
Coordina la puesta a punto de la monitorización y seguimiento del nuevo
servicio correspondiente al nuevo proyecto.
Coordina los grupos técnicos de explotación.
Planifica todas las fases del proyecto.
Elabora plan de puesta en producción del sistema.
Coordina las áreas técnicas durante la puesta en producción del sistema.
Página 17 de 17
6.6.4. Documentación
Enmarcado dentro del proceso de implantación de nuevos proyectos, la recopilación de
documentación del sistema es un factor sustancial para garantizar el traspaso de conocimiento
a las áreas técnicas implicadas y la correcta explotación del sistema.
Por estas razones, para la puesta en producción de un nuevo sistema o aplicación es
imprescindible disponer por parte de Explotación de toda una serie de documentación referente
al proyecto o aplicación a fin de ofrecer el máximo nivel de servicio una vez puesto en
Explotación. Asimismo es necesario que el nuevo sistema o aplicación cumpla una serie de
requisitos en cuanto a tecnología de sistemas, bases de datos, seguridad y aplicación.
El objeto de este apartado es detallar toda la documentación y requisitos exigidos para
completar la implantación del proyecto en Explotación y el flujo para su validación para todo
tipo de proyecto desarrollado en SINFO y gestionado por un TAM.
El Jefe de Proyecto del sistema a poner en producción es el responsable de la entrega de toda
la documentación. Sólo una vez aceptada por completo la documentación obligatoria, se podrá
dar paso a la puesta en producción de la aplicación o sistema.
De igual modo se va a detallar una serie de documentos que si bien no son de carácter
obligatorio, al no significar su ausencia un impedimento para su puesta en producción, si es
recomendable que se pongan a disposición de EXPLO con el fin de tener la máxima
información para la correcta explotación de la aplicación o sistema.
El TAM es el encargado de poner a disposición del Jefe de Proyecto toda la documentación
que debe facilitar y los distintos plazos para la entrega de la misma con el fin de conocer con
suficiente antelación la viabilidad de la implantación.
En cualquier caso, siempre somos los TAM quienes podemos valorar la obligatoriedad de la
entrega de determinados manuales en función de su necesidad para la explotación y garantía
del servicio exigido.
Los TAM nos encargamos pues de exigir, recibir, corregir, aceptar o rechazar, validar y
finalmente aprobar y archivar toda la documentación del proyecto.
A continuación se lista el conjunto de documentos entregables por parte del Jefe de Proyecto al
TAM:
• Manuales y procedimientos,
Manual de Arquitectura
Manual de Instalación de la parte servidor de la aplicación
Manual de Instalación de la parte cliente de la aplicación
Plan de Capacidad de Sistemas
Plan de Capacidad de BBDD
Manual de Administración de la aplicación
Formulario de Monitorización
Plan de Seguridad
Manual de ABM De Usuarios
Procedimiento de Producción
Manual de Usuario
Solucionario de incidencias para el CAU
Solucionario de peticiones para el CAU
•
Documentación técnica de requerimientos de Tecnología de Sistemas,
Checklist de material Hw
Checklist de software de base para el sistema
Checklist de instalación y configuración del sistema
Requerimientos de la estructura de BBDD Oracle
Requerimientos De Seguridad
Junio 2005
Página 18 de 18
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Manual de Arquitectura: el documento debe tener como finalidad determinar claramente
todos los componentes, tanto de Hardware como de Software, necesarios para la
aplicación. Este punto de la documentación deberá presentarse en la fase inicial (fase en
que se realiza la memoria de adquisición de equipos).
Manual de Instalación de la parte servidor de la aplicación: el objeto de este
documento es describir los pasos necesarios para realizar la instalación de la parte servidor
de la aplicación. Se deben indicar las necesidades sobre las instalaciones a realizar en los
sistemas. Su elaboración cuenta con el apoyo de TECSI, debido a que no únicamente se
debe definir la instalación de la aplicación sino también las variaciones sobre el sistema
operativo.
Manual de Instalación de la parte cliente de la aplicación: el objeto de este documento
debe ser describir los pasos necesarios para realizar la instalación del sistema o aplicación
de la parte cliente. Su elaboración cuenta con el respaldo del departamento de
“Homologación de SW”, que es quien realiza las pruebas y homologa la instalación.
Plan de Capacidad de Sistemas: es el documento cuyo fin es recoger por parte de TECSI
los requerimientos a nivel de sistema operativo y capacidad de almacenamiento en disco
por parte del sistema previstos inicialmente, así como también la estimación de crecimiento
de consumo durante el primer año de explotación del sistema. Durante la primera fase
(fase M. A.) se entrega este documento con información de tipo genérico. En una segunda
fase se entrega el documento más detallado.
Plan de Capacidad de BBDD: el documento debe recoger los requisitos en memoria de
cada una de las tablas de la base de datos utilizadas por la aplicación, definiendo tanto la
capacidad inicial como las previsiones de crecimiento. A partir de este documento TECSI
puede determinar el tamaño que tendrá la base de datos.
Manual de Administración de la aplicación: este documento debe aportar la información
necesaria para la administración de la aplicación. Este manual debe definir todas las
posibles funciones que los administradores deben hacer, todas aquellas que no queden
definidas continuarán siendo responsabilidad del área de desarrollo.
Formulario de Monitorización: el fin de este documento es determinar las métricas de
monitorización específicas para cada aplicación o sistema antes de su implantación en
Producción.
Plan de Seguridad: el objetivo de este documento es obtener el plan de seguridad
completo para un proyecto. Incluye temas de L.O.P.D., control de acceso, nivel de
restricciones, etc. Esta es una tarea multidisciplinar y las diferentes necesidades se
delegan en diferentes áreas de Sistemas de Información. Una vez en explotación, el área
de Seguridad Informática realiza el seguimiento del cumplimiento del plan y asegura su
revisión.
Manual de ABM De Usuarios: aquí se deberán definir los procedimientos operativos
necesarios para el alta, baja y posteriores modificaciones de usuarios en el sistema que se
vaya a implantar en Producción. El manual recogerá todos los pasos necesarios y deberá
ser comprobado por los administradores para verificar la correcta alta en el sistema antes
del paso a producción.
Procedimiento de Producción: aquí se hace referencia a un procedimiento efectuado por
el área de Eplotación donde se detalla la información necesaria para el grupo de
Producción con el fin de explotar el Sistema.
Manual de Usuario: en éste se debe aportar información acerca del funcionamiento de la
aplicación o sistema a nivel de usuario, incluyendo imágenes y explicaciones de las
diferentes pantallas con las que va a interactuar el mismo.
Solucionario de incidencias para el CAU: en este documento se detallan de forma
precisa las actuaciones a llevar a cabo por el CAU para la resolución de incidencias
conocidas que se puedan producir en la aplicación o sistema.
Solucionario de peticiones para el CAU: en este documento se describe de forma
precisa las actuaciones a llevar a cabo por el CAU ante peticiones predefinidas respecto a
la aplicación o sistema por parte del usuario.
Plan de Marcha Atrás: es el documento que recoge toda la checklist técnica que se
debería llevar a cabo en caso de desastre o fracaso en la puesta en producción del sistema
o aplicación.
Junio 2005
Página 19 de 19
6.6.5. Diagrama de Detalle de la implantación de nuevos proyectos
En esta sección se ilustra, mediante diagramas de flujo de trabajo, el proceso de implantación
de nuevos proyectos explicado en el capítulo 6.
ELABORA DOCS
PARA EL
ENTORNO DE
DESARROLLO Y
• CONVOCA
PETICIONARIO
NUEVO
PROYECTO:
ARQIN
DESA
TECSI
APORTA
DOCUMENTACION
•PLAN DE PROYECTO
•DOC ARQUITECTURA
•ORGANIGRAMA
•PLAN DE ENTORNOS
REUNION
• INFORMA DE LA
PUESTA EN
MARCHA DE UN
NUEVO PROYECTO
PRUEBAS:
-ARQUITECTURA
-CONFIGURACION
DE EXPLOTACION
-MONITORIZACION
-BACKUP
-PLANIFICACION
-REDES
- RECURSOS
•
REALIZA
MODIFICACIONES
RECIBE
INFORMACIÓN
Y LA
VALIDA
(1 SEMANA)
EXPLOTACIÓN
TAM
SOLICITA
LA NUEVA
INFRAESTRUCTURA
Y ENTORNO PARA
DESARROLLO Y PRUEBAS
PARA CADA ENTORNO
SUPERVISA PLANIFICACION,
VALIDA ESPECIFICACIONES
CONTRA DOC ARQUITECTURA
RECIBE
INFORMACIÓN
Y LA
VALIDA CON
GRUPOS TÉCNICOS
(1 SEMANA)
SISTEMAS
REPOSITORIO
DOCUMENTACIÓN
HERRAMIENTA DE
GESTION DEL SERVICIO
Diagrama de flujo 1. Fase inicial del proyecto.
En esta primera fase se convoca reunión de presentación de proyecto y se entrega la
documentación inicial.
Junio 2005
Página 20 de 20
1
ELABORA DOCS PARA
EL ENTORNOD PRE Y
PRODUCCIÓN
ARQIN
DESARROLLA
APLICATIVO
SOLICITA
ACTUACIONES
SOBRE ENTORNO
DESA
TECSI
ACTUALIZA
DOCUMENTACIÓN
GENERA
VERSIÓN 0
APLICATIVO
LIBERA
VERSIÓN 0
Y REALIZA PRUEBAS
CORRIGE ERRORES
EMITE INFORME
MODIFICA DOCS
-ARQUITECTURA
-CONFIGURACION DE
EXPLOTACION
- MONITORIZACION
- BACKUP
- PLANIFICACION
-REDES
- RECURSOS
- PLAN MARCHA
ATRAS
REALIZA
REALIZA
MODIFICACIONES
EXPLOTACIÓN
RECIBE
CAMBIOS
DOCS
TAM
1
INSTALA / ACTUALIZA
ENTORNO DE
DESARROLLO
Y/O PRUEBAS
ACTUALIZA
INVENTARIO
RECIBE
CAMBIOS
DOCS
SUPERVISA
PRUEBAS
RECIBE INFORME
Y DOCS
SUPERVISA
PRUEBAS
RECIBE INFORME
Y DOCS
RECIBE
INFORMACIÓN
Y LA
VALIDA
(1 SEMANA)
RECIBE
INFORMACIÓN
Y LA
VALIDA CON
GRUPOS TÉCNICOS
(1 SEMANA)
SISTEMAS
HERRAMIENTA DE
HERRAMIENTA
INVENTARIO
REPOSITORIO
DOCUMENTACIÓN
Diagrama de flujo 2. Fase intermedia del proyecto.
En esta fase intermedia se realiza el desarrollo del proyecto y se produce la subida del
aplicativo o sistema a los entornos de pruebas de Desarrollo e Integración.
Junio 2005
Página 21 de 21
2
INSTALA
APLICATIVO EN
PREPRODUCCIÓN
REALIZA PRUEBAS
FUNCIONALES Y
DE CARGA
ACTUALIZA
DOCUMENTACIÓN
SOLICITA PASO A
PRODUCCIÓN
ARQIN
DESA
TECSI
2
SOLICITA
LA NUEVA
INFRAESTRUCTURA
Y ENTORNO PARA PRE Y
PREPRODUCCIÓN
PLANIFICAN
CONJUNTAMENTE
LA INSTALACION Y
VALIDACION DEL
ENTORNO DE
PREPRODUCCION
Y PRODUCCIÓN
PARTICIPA EN LA
PLANIFICACION
SUPERVISA
PRUEBAS
EXPLOTACIÓN
TAM
VALIDA LA
PLANIFICACIÓN
SISTEMAS
HERRAMIENTA DE
INSTALA
ENTORNOS
ACTUALIZA
INVENTARIO
SUPERVISA
PRUEBAS
HERRAMIENTA DE
HERRAMIENTA
INVENTARIO
Diagrama de flujo 3. Fase de implantación del proyecto en Preproducción.
En esta fase se lleva a cabo la implantación del proyecto en el entorno de Preproducción. Es la
fase previa a la subida del sistema o aplicativo a Producción.
Junio 2005
Página 22 de 22
3
VERIFICA
ENTORNO
JUNTO A
DESA
TECSI
¿RESULT
ADOS
OK ?
NO
USUARIO FINAL
3
SI
TAM
VALIDA DOCUMENT Y
FECHA PASO A PROD.
PLAN MARCHA ATRÁS
SISTEMA SEGÚN
POLÍTICAS SEGURIDAD
APRUEBA CAMBIO
TRASPASO APLICATIVO A
ENTORNO PRODUCCIÓN
VALIDA
DOCUMENTACIÓN,
SISTEMAS Y
FECHA PASO A
PROD
IDENTIFICACION CONJUNTA DE ACCIONES
DECISIÓN EJECUCIÓN MARCHA ATRÁS
ARQIN
PASO A EXPLOTACION
DEL SISTEMA COMPLETO
NOTIFICA A GRUPOS
EXPLOTACIÓN
INICIO PERIODO
GARANTIA
ACTUALIZA INVENTARIO
VALIDA
PROCEDIMIENTOS
PARA OPERACION
CORRIGE
ERRORES
CORRIGE
ERRORES
CORRIGE
ERRORES
4
ACTIVA
MONITORIZACION
PROCEDIMIENTOS
PROCESOS BATCH
TECSI
HERRAMIENTA DE
ENTORNO PROD
LISTO Y ACEPTADO
REPOSITORIO
DOCUMENTACIÓN
HERRAMIENTA
INVENTARIO
Diagrama de flujo 4. Fase de implantación del proyecto en Producción.
En esta fase final se lleva a cabo la implantación del proyecto en el entorno de Producción y
control de calidad de la misma.
Junio 2005
Página 23 de 23
ARQIN
IDENTIFICACION CONJUNTA DE ACCIONES
DESA
TECSI
EXPLO
SI
TAM
4
¿PROBLEMAS
DURANTE
PERIODO DE
GARANTIA ?
PROPORCIONA
SOPORTE A
EXPLOTACIÓN
CORRIGE
ERRORES
CORRIGE
ERRORES
NO
CORRIGE
ERRORES
CIERRE DEL
PROYECTO
F
SISTEMAS
ENTORNO DE
PRODUCCIÓN
Diagrama de flujo 5. Fase post-implantación del proyecto, Período de Garantía.
La fase posterior a la implantación en Producción del sistema o aplicativo es la conocida como
periodo de garantía, que dura aproximadamente un mes. Durante este período no se considera
el sistema implantado estable, pudiendo surgir o identificarse problemas tanto funcionales
como de rendimiento. Una vez transcurrida la fase de garantía, si no se han identificado
problemas, se cierra el proyecto y el sistema se considera un entorno de producción.
Junio 2005
Página 24 de 24
6.7. Proyectos realizados
Para finalizar la explicación del trabajo realizado en el proyecto desarrollado en Soluciona, en
este sub-capítulo se procede a describir algunos de los proyectos llevados a cabo como TAM,
incluyéndose ejemplos para todos los tipos de proyecto.
Proyecto de Arquitectura: Traslado CPD.
El proyecto Traslado de CPD surgió debido a razones internas del cliente, que comunicó la
necesidad de trasladar todas sus infraestructuras de Tecnologías de la Información desde
el CPD que entonces ocupaban hasta otro CPD en un edificio distinto.
El parque tecnológico del cliente alberga unos ciento cincuenta servidores
aproximadamente, de los cuales noventa se vieron afectados por el traslado al estar
ubicados en la sede del CPD a trasladar.
Para este proyecto han sido de mi competencia y responsabilidad las tareas de diseño y
planificación del Plan de Traslado, además del diseño del Plan de Contingencia.
Para diseñar y planificar el Plan de Traslado debía decidir cuándo, en qué orden, cómo y
con qué duración en el corte de servicio trasladaría todos los servidores y equipos de red
del CPD. Para poder tomar estas decisiones me basé en los siguientes criterios:
o Criticidad del sistema respecto al negocio de la compañía
o Criticidad del sistema respecto a la afectación a los usuarios de la compañía
o Entorno (desarrollo, integración, preproducción y producción)
o Datos físicos de los servidores (peso, altura, etc)
o Disponibilidad de técnicos de guardia
Además tenía una serie de premisas que condicionaban el propio traslado, como eran:
o La inviabilidad de trasladar servidores de forma separada, al ser el rack la unidad
de traslado.
o La agrupación de servidores por fabricante debido a la separación de racks por
fabricante.
Estuve trabajando durante tres semanas en la preparación del plan de traslado de CPD,
durante las que me entrevisté con todos los responsables de las áreas técnicas implicadas
de los equipos a trasladar. También me entrevisté con los diferentes responsables de los
fabricantes Hardware para conocer de primera mano los detalles técnicos y
consideraciones fundamentales a tener en cuenta en operaciones de traslado. La
colaboración de todas las áreas en estas reuniones unidas al conocimiento que el puesto
de TAM me ha proporcionado sobre los sistemas de la compañía del cliente, dieron su fruto
pudiendo completar a tiempo el plan de traslado detallado.
Confeccionar el Plan de Contingencia fue algo más complejo. Por razones políticas, en
caso de desastre no era posible realizar un Plan de Marcha Atrás ya que el CPD origen
debía ser desafectado definitivamente, con lo cual el Plan de Contingencia se tuvo que
ceñir a una situación de alto riesgo. Tras varias reuniones con expertos en SRD,
identificamos el mayor peligro del traslado, que consistía en la posibilidad de crash del
equipo DMX800, una cabina de discos Symmetrix de EMC que contenía el 80% de los
datos de la compañía. Luego el Plan de Contingencia consistió en definir un plan de acción
por si sucedía un desastre con el equipo Symmetrix. Lo que se hizo fue contratar el alquiler
de un equipo de características similares que se configuró y preparó en el CPD destino de
manera que si algo ocurría con la cabina de discos que contenía los datos, una vez
trasladada la infraestructura de backup al CPD destino, proceder a restaurar los datos de
los backups previos. Para el caso de desastre en alguno de los servidores que no contenía
datos, como son los servidores de aplicación o miembros de granjas de metaframes, la
contingencia se definió basándonos en la conclusión que sería más fácil y menos costoso
en tiempo reinstalar que restaurar de backup.
Junio 2005
Página 25 de 25
Finalmente el fin de semana planificado se llevó a cabo el traslado de CPD con resultado
satisfactorio, minimizando en todo lo posible el tiempo de corte de servicio de los sistemas
críticos de negocio para la compañía. Incluso para que el corte de servicio no afectase de
manera notoria a la imagen del cliente, de forma paralela al diseño de plan de traslado se
configuró una arquitectura temporal con servidores web y de aplicación donde se montó
una aplicación estática en su URL de internet, de manera que acceder a la web de la
compañía era posible aun estando parados los verdaderos equipos de la arquitectura de su
e-Company.
Para clarificar el diseño y planificación, en el Anexo A se incorpora un resumen del plan de
traslado.
Proyecto de Arquitectura: Unificación dominio correo.
Como consecuencia de la fusión del cliente con otra empresa de su mismo sector, se ha
iniciado una fase de integración entre ambas que origina y da lugar a una considerable
cartera de proyectos de unificación.
Uno de estos proyectos ha sido la Unificación del dominio de correo. El objetivo del
proyecto era pues unificar el dominio de correo de ambas compañías en uno único de cara
a la imagen comercial de la fusión de ambas empresas.
La situación del punto de partida era la existencia de dos plataformas de correo diferentes:
o Lotus Notes y dominio @dominioA
o Exchange 2003 y @dominioB
o Utilización de dos pasarelas diferentes de correo hacia internet.
El objetivo es llegar, en una primera Fase I del proyecto, a la unificación del dominio en un
único dominio @dominioUnificadoC; en la Fase II se procederá a unificar también la
plataforma de correo, bien migrando Exchange a Lotus Notes o a la inversa.
De momento ha finalizado la Fase I del proyecto, mientras que la Fase II aún no se ha
lanzado pues se está estudiando desde el área Arquitectura e Infraestructura cuál es la
mejor opción.
La solución ha consistido en unificar el correo entrante y modificar los firewalls, servidores
de antivirus y pasarelas de correo de la DMZ para que admitan el nuevo dominio unificado.
Asimismo, al mantenerse aún dos plataformas de correo independientes, se han tenido que
definir en los respectivos listines corporativos todos los usuarios de la otra plataforma y se
han configurado las redirecciones necesarias.
En este proyecto las labores desarrolladas por mi parte han sido,
o La realización de la checklist técnica para realizar el cambio de dominio de correo,
gracias a la estrecha e inestimable colaboración de los equipos de administración
de correo debido a mi inexperiencia en estas tecnologías.
o Planificación del cambio de dominio en base a la identificación de tareas realizada
en el punto anterior.
o Coordinación entre los administradores que realizan el cambio y las áreas del
cliente para certificar las notificaciones a todos los usuarios.
Actualmente se está trabajando en el diseño de la Fase II para unificar las plataformas de
correo.
Proyecto de Desarrollo de Software: Nueva e-Company de la empresa.
También a raíz de los proyectos de fusión e integración, se ha llevado a cabo el proyecto
de implantación de la nueva web corporativa de la empresa.
Junio 2005
Página 26 de 26
Aunque técnicamente no tienen ninguna similitud, conceptualmente la situación origen y
destino es idéntica al proyecto descrito en el punto anterior (unificación dominio correo). La
situación de partida era la existencia de dos URLs correspondientes a las respectivas webs
corporativas de cada empresa, siendo el objetivo la creación de la nueva e-Company
correspondiente a la web de la empresa unificada.
Los productos utilizados para el desarrollo de la aplicación e instalados en cada capa de la
Arquitectura han sido:
o BBDD: Oracle Server
o IAS: BEA Weblogic
o IWS: iPlanet
En este caso la solución ha pasado por redirigir las antiguas URLs de cada empresa a la
nueva URL de la e-company unificada, actualizando las IPs públicas en los registros MX de
los DNS externos del proveedor de ISP de la compañía, para replicar la nueva web en todo
el mundo incluso cuando se intente acceder a las antiguas web corporativas escindidas.
Para este proyecto las funciones asumidas y llevadas a cabo por mi parte han sido,
o Ayuda en el diseño de arquitectura de BBDD. Es decir, el equipo de proyecto ha
sido quien ha definido el modelo de base de datos, el volumen de datos, las clases
del IAS, etc. Mientras yo he decidido en qué servidores del cliente se debía ubicar
la nueva arquitectura de la e-company al tener conocimiento y experiencia en la
arquitectura de la web corporativa anterior del cliente.
o Apoyo a los desarrolladores en la orientación hacia la metodología de trabajo de
Explotación.
o Planificación y coordinación del proceso de implantación del sistema en
producción.
Proyecto de Desarrollo de Software: Gestión Documental de la compañía.
En las últimas semanas se ha lanzado un nuevo proyecto para llevar a cabo la Gestión
Documental de la compañía, es decir, crear un único repositorio con toda la documentación
que se genera en la empresa cliente, con control de acceso restringido por áreas y con
cumplimiento de las últimas incorporaciones de la L.O.P.D.
La interfaz de acceso a la aplicación que gestionará la Documentación será la propia ecompany. Luego los productos SW utilizados vuelven a ser Oracle, Bea Weblogic e Iplanet.
El proyecto está aún en una fase inicial, pues sólo se ha producido la reunión de kick off
por parte del Jefe de Proyecto del área de Desarrollo para presentarme el proyecto y me
encuentro en etapa de recogida de información (ver Diagrama de flujo1. Fase inicial de
proyecto).
Sin embargo las funciones que llevaré a cabo serán las mismas que en el caso del
proyecto anterior, ayuda en el diseño, planificación y coordinación de áreas técnicas.
Proyecto de Técnica de Sistemas: Migración del Software de Backup.
La empresa cliente decidió migrar su antiguo software de backup e infraestructura
hardware de backup, que englobaba librería, robot de copias y demás.
La migración del software fue del antiguo sistema con Netbackup hacia Legato Networker.
Debido a su elevada complejidad técnica se trata de un proyecto cuya planificación dio
lugar a más de un año de ejecución, diferenciando las siguientes fases generales:
o Pruebas y homologación del backup con el nuevo software y robótica de copias en
todas las plataformas y sistemas del cliente (unix, wintel, notes, oracle, etc).
o Fase de coexistencia de backup con ambos sistemas.
Junio 2005
Página 27 de 27
o
Pasado un tiempo prudencial de backup exitoso en el nuevo sistema, eliminación
paulatina del antiguo software de backup.
En este proyecto las funciones de mi responsabilidad son de planificación y coordinación,
junto a la elaboración del plan de backup:
o Definición plan de backup. Al cambiar la infraestructura hardware de copias, hubo
que redefinir de nuevo el plan de backup, es decir cuándo, con qué periodicidad,
con qué retención en cinta y qué tipo de backup (total o incremental) se copia la
información para todos y cada uno de los servidores.
o Planificación del cambio de backup en todos los servidores.
o Coordinación de las áreas técnicas para el cambio de cada servidor o grupo de
servidores, notificando los cortes de servicio e intentando minimizar el impacto en
el cliente.
El proyecto de backup está a punto de finalizar, aún en período de garantía (Diagrama de
flujo 5. Fase post-implantación del proyecto, Periodo de Garantía).
Proyecto de Técnica de Sistemas: Cambio direccionamiento IP.
Debido a grandes cambios en la infraestructura de redes y comunicaciones del cliente,
floreció un proyecto interno de Tecnología para cambiar el direccionamiento IP de todas las
máquinas de la empresa.
En este caso lideré el cambio llevando a cabo las siguientes labores:
o Identificación de checklist técnica para el cambio de IP en un servidor Unix.
o Identificación de checklist técnica para el cambio de IP en un servidor Wintel.
o Confección de sendos procedimientos para cada caso.
o Identificación de implicaciones en procesos batch, servidores DNS, enlaces entre
bases de datos,… en definitiva, identificar cualquier proceso que pudiese contener
una IP.
o Planificación del cambio completo de direccionamiento IP en la compañía.
o Coordinación de las áreas técnicas para el cambio de cada servidor o grupo de
servidores, notificando los cortes de servicio e intentando minimizar el impacto en
el cliente.
El proyecto finalizó habiendo completado el cambio de direccionamiento IP en los 147
servidores en el plazo de cinco semanas.
7. HERRAMIENTAS UTILIZADAS
Las herramientas utilizadas en el puesto de trabajo son, principalmente, aquellas de consulta y
administración de los sistemas informáticos como las que se listan a continuación:
•
•
•
•
•
•
DBA Studio de Oracle, para operaciones de consulta y administración de las instancias de
base de datos Oracle
X-terminal client, para establecer consolas o terminales de acceso a servidores Unix
Cliente Citrix, para establecer consolas de acceso a servidores Wintel
Consola Administración Legato Networker para realizar consultas
Consola Administración Bussines Objects para gestión universos
Consola Administración BEA Weblogic para realizar consultas
Asimismo, las herramientas de trabajo para la gestión de peticiones que se generan en la
coordinación de proyectos son herramientas de ticketing como las siguientes:
•
•
•
Remedy
Managenow.
Service Desk.
Junio 2005
Página 28 de 28
8. APORTACIONES DEL PROYECTO A LOS CONOCIMIENTOS DEL
ALUMNO
El proyecto desarrollado en el puesto de trabajo de TAM, por su naturaleza multidisciplinar y
multiplataforma, me ha permitido tener una visión global de los Sistemas de Información, que
se traduce en el conocimiento de áreas tecnológicas muy diversas entre sí que difícilmente en
otro perfil profesional se puede adquirir.
Al gestionar, coordinar y colaborar activamente en proyectos de tan diferente índole, he tenido
la ocasión de descubrir tecnologías, infraestructuras informáticas y arquitecturas que en un
puesto de trabajo orientado a la especialización no habría podido disfrutar.
Igualmente, al tener un puesto de trabajo que interactúa con todas las áreas del departamento
de Sistemas de Información por ser el punto focal en las interrelaciones de sus áreas, he
tenido un privilegiado puesto de observación para lograr entender cómo funciona un
departamento como Sistemas de Información en una gran empresa.
Asimismo, tras varios años trabajando en las áreas de Tecnología de Sistemas como
administradora de diferentes entornos, desempeñar funciones de TAM, un puesto ubicado en el
área de Ingeniería y Proyectos de la empresa, ha posibilitado que pueda introducirme en el
mundo de la gestión de proyectos, aprendiendo diferentes metodologías de trabajo y
despertando mi interés en otras cuya existencia antes incluso desconocía, como por ejemplo la
metodología ITIL en las soluciones de Explotación.
De igual modo, al ser estudiante de I.T.I.G., desarrollar mi carrera profesional en este campo
ha enriquecido mis conocimientos en aquellas áreas más relacionadas con la I.T.I.S., como por
ejemplo conocimientos de redes, comunicaciones o arquitectura de sistemas.
Por último, comentar que la ubicación del puesto en el área de negocio de Outsourcing me ha
brindado la oportunidad de conocer de primera mano cómo funciona un Outsourcing
Tecnológico global para una empresa cliente. Esta parte además la considero de vital
importancia por lo que me ha curtido como profesional y persona.
9. APORTACIONES DE LOS ESTUDIOS REALIZADOS AL
PROYECTO
Haber cursado los estudios de I.T.I.G. me ha permitido no sólo acceder al mercado laboral del
sector informático, sino darme una base fundamental, esencial e imprescindible para poder
entender y desarrollar todas las funciones del puesto de TAM.
En el proyecto que desarrollo en la empresa, las asignaturas cursadas en mis estudios de las
que más utilidad y provecho he extraído son:
• Las de Ingeniería del Software por darme la visión y conocimiento base de la gestión
del ciclo de vida de los proyectos de Desarrollo de Software, que como he podido
comprobar ejerciendo el puesto de TAM se pueden extrapolar a otra tipología de
proyectos como los de arquitectura o sistemas.
• Los conocimientos adquiridos en las asignaturas relacionadas con la administración de
Ficheros y Bases de Datos me han sido de gran utilidad y quizá los que más he
aplicado a lo largo de toda mi carrera profesional. En el puesto de TAM estos
conocimientos son imprescindibles para desarrollar las tareas de colaboración y apoyo
en el diseño. Por ejemplo gestionar o administrar un gestor de base de datos Oracle es
mucho más fácil con conocimientos previos como el modelo de base de datos
relacional.
• Por último, las asignaturas relacionadas con sistemas operativos y su administración
también han sido cruciales al estar en un puesto de trabajo estrechamente hermanado
con las áreas de TECSI. Por ejemplo cualquier consulta sobre un servidor Unix a nivel
de sistema operativo agradece haber cursado asignaturas como A.S.O.
Junio 2005
Página 29 de 29
10. CONCLUSIONES
Las conclusiones del proyecto descrito en la presente memoria son una mezcla de los dos
capítulos anteriores: las aportaciones del trabajo desempeñado a mis conocimientos y
viceversa, es decir las aportaciones de los estudios realizados al puesto de trabajo.
Por una parte, las tareas que se llevan a cabo ocupando el puesto de trabajo de TAM, por su
naturaleza multidisciplinar y multiplataforma, me han permitido tener una visión global de los
Sistemas de Información de una empresa al ser espectadora de lujo de todo lo que acontece
en los entresijos del departamento de Sistemas de Información, que se traduce en el
conocimiento de áreas tecnológicas completamente diferentes entre sí, conocimiento de las
relaciones que se establecen entre las áreas integrantes del departamento y de cómo se
establecen estas relaciones.
Las aportaciones más relevantes del desarrollo de proyecto como TAM, las resumiría en la
instrucción técnica que me ha aportado, la cultura general que he cultivado sobre el
funcionamiento de departamentos informáticos, la aproximación inicial y el conocimiento
posterior sobre la gestión de proyectos, así como poder aplicar en la vida profesional los
conocimientos teóricos adquiridos durante los estudios de la carrera.
Asimismo, gestionar y coordinar proyectos de diferente tipología en una empresa grande me ha
ofrecido la ocasión de conocer las tecnologías de la información de última generación,
pudiendo así comprender y codearme con las infraestructuras más innovadoras y de referencia
en el mercado.
Para concluir puedo afirmar sin duda que la parte más importante y enriquecedora adquirida a
raíz del proyecto ha sido a nivel personal, por haber facilitado mi realización profesional con la
consiguiente realización personal, al permitirme trabajar en algo que realmente me entusiasma
acompañada de profesionales al lado de quienes es tan fácil aprender y adquirir un
compromiso constante con el conocimiento.
11. AGRADECIMIENTOS
Quisiera dejar constancia en esta memoria del agradecimiento hacia los tutores del PFC.
Gracias al profesor Benet Campderrich Falgueras por la aceptación de la dirección del proyecto
por parte de la Universidad URV y su tiempo dedicado.
Gracias a mi responsable en la empresa Soluziona, Julio Silvosa Castosa, por su colaboración
para facilitar la tramitación del Convenio de Colaboración entre la empresa y la Universidad así
como por su orientación en mi trayectoria.
Junio 2005
Página 30 de 30
12. GLOSARIO
•
ABM: Alta, Baja y Modificación de Usuarios.
•
ARQIN: área de Arquitectura e Infraestructuras del departamento de Sistemas de
Información.
•
CAU: Centro de Atención al Usuario, área que da soporte y apoyo a los usuarios ante
probleas e incidencias.
•
DESA: área de Desarrollo del departamento de Sistemas de Información.
•
DNS: Domain Name System, protocolo DNS.
•
Equipos de red: todos aquellos componentes informáticos ubicados en un CPD que no
son un servidor, como por ejemplo: Firewall, Switch, Router y Balanceador.
•
IAS: Internet Application Server, servidor de aplicaciones de Internet/Intranet.
•
I+D: Investigación y Desarrollo.
•
INPRO: área de Ingeniería y Proyectos del departamento de Sistemas de Información.
•
ITIL: acrónimo de Information Technology Infraestructure Library. Se trata de una
metodología estándar para la gestión de servicios de Tecnologías de la Información, cada
vez más extendida y aceptada por constituir en sí una guía completa sobre la provisión y el
soporte de los servicios de Tecnologías de la Información.
•
IWS: Internet Web Server, servidor web de aplicaciones de Internet/Intranet.
•
OPER: área de Operaciones CPD del departamento de Sistemas de Información.
•
Outsourcing Tecnológico: práctica empresarial que consiste en la externalización de los
departamentos de Sistemas de Información en una compañía para contratar estos servicios
a una empresa del sector tecnológico especializada.
•
SINFO: departamento de Sistemas de Información.
•
SRD: acrónimo Sistema de Recuperación ante Desastres.
•
TAM: acrónimo de Technical Account Manager. Puesto desarrollado en la empresa cuya
descripción se expone en esta memoria.l
•
TAU: acrónimo de Test de Aprobación del Usuario, consiste en una fase de pruebas previa
a la implantación de un proyecto en Producción.
•
TECSI: área del Tecnología de Sistemas del departamento de Sistemas de Información.
Junio 2005
Página 31 de 31

prj cjg

Transcripción

Documentos relacionados

Presentación de PowerPoint