Universidad de Carabobo

Facultad Experimental de Ciencias y Tecnolog fa

Departamento de Computación
Metodologías para la Evaluación del Desempeño de
Sistemas Computacionales

MIGRACIÓN DE SISTEMAS COMPUTACIONALES

Presentado a: Realizado por:

Dra. Mirella Herrera Carlos Gómez CI: 21254227
Jesús Jiménez CI: 23421010

Naguanagua, Junio 2015

 Migración de Sistemas Computacionales

Durante el ciclo de vida de un software, puedc surgir la necesidad de modificarlo para

ejecutarse en un entorno diferente. A ron de migrar un sistema a un entorno diferente, se debe
determinar las acciones necesarias para lograr la migración, y luego desarrollar y documentar
los pasos requeridos para efectuar la migración.

Específicamente, se puede definir la migración de sistemas como el conjunto de

actividades para actualizar, modificar o eliminar equipos informáticos y recursos
relacionados a la tecnología y sistemas de información incluyendo cl área de
telecomunicaciones. Tiene por finalidad el traslado del sistema a un nuevo ambiente
operativo, conservando su funcionalidad y datos originales. En todos los casos se persigue
posibilitar el mantenimiento y posterior adecuación a nuevos requerimientos.

Entre las causas por las cuales se realiza núgración de sistemas destacan las siguientcs:

o Ya no existe soporte para el sistema actual.

o No son suficientes las capacidades del hardware actual.
o El mantenimiento del sistema actual resulta ser muy costoso.
o El sistema actual pucde no ser compatible con nuevas tecnologías quc se desee
incluir.

Es importante acotar que la migración no debe efectuarse sólo con el propósito de

solventar las situaciones anteriores, lo más i‹1eal sería efectuar la migración antes de
presentarse la situación para así prevenirlas.

La migración es un proceso de cambio que puede efectuarse tanto en los elementos del
software como ilel hardware. Toda migración incluye una seric de pasos a seguir:

o Determinación de la causa de la migración - Recolección de datos.

o Planificar el momento y procedimiento de migración.
o Evaluar los resultados de la migración.

Un proceso de migración no puede darse sólo con la sustitución del software, pues están
involucrados factores de preparación y previsifin tjue deben ser tenidos en cuenta. Todas las
migraciones deben basarse en una cuidadosa p1anificacif›n para evitar posibles pérdiilas de
información o funcionalidad.
Antes de tomar cualquier decisión, hay que tener en cuenta cuáles son las
funcionalidades del nuevo software. Cuando se tienen varias opciones, los responsables del
proceso de migración deben conocer las ventajas c inconvenientes de cada producto. Sc
aconseja consultar a los usuarios y explicarles las razones por las que se va a llevar a cabo la
nfigració n y có mo les afectará, para ayudar al éxito del prc›ceso.

Más allá de la migración:

Para solventar los problemas antes p1anteatios, no solo se cuenta con la migració n. De
hechu se han propuesto diferentes soluciones tjue se pueden agrupar en dos categorías,
ademá s de la migració n:

a) Reconstrucció n:
La rcconstrucci4n implica rccscribir las aplicaciones cxistcntes, y dependiendo tie la
duc umcntació n y conocimiento disponible sobre cl sistema actual, pucde tratarse tlcsde una
reingeniería hasta el rctiisc ñ o Mc un sistema completamente ntievci. Esto ú ltimo ya fue
referido como abandono del sistema para su sustitució n por otro nuevo.

b) Encapsulamientu:
Con encapsulamiento se hace referencia al desarrollo de una cnvoltura de software
(wrappcr) sobre la aplicació n e xistentc, con el fin de tlotarlo dc interfaces con componentes
periféricos que permiten sacarlo de su aislamiento.

La primera es muy pto:o probablc que sea una verdadera opció n. La so1uci/in casi
siempre recae sobre el encapsulamiento o la migració n. El encapsulamiento se puede má s
como una solució n te mpural al problema, t]uedando la migració n como la opció n tjrie
verdaderamente representa solidez y prcvisibilitlad ftittira.

En efecto, en situaciones donde per diferentes motivos se descartar las opciones de

reconstrucció n y de cncapsulamiento, la migriició n del sistcma a un ambiente abierta se
convierte en la mejor alternativa. Si bien esta es la opciÚ n fRá s compleja, las ventajas que se
obtiene n a largo plazo justifican ampliamente el esfuerzo tjue será requeritio.

Atjuí de be reconocerse tjuc un trabajo de naigraciú n es norm almcntc un proyecto de

ingeniería de sistemas, Rut pur su importancia merece el calificativo Ü e crítico. Esto es así
tanto por la relevanciii de los entornos migrados (datos y aplicaciones), tjue deberá n ofrecer
finalmente la misma eficiencia y opcratividati 'luc ofrecían en cl entorno anterior, conan así
también por la necesidad de hacer nú nimo cl impacto en todos los niveles de la organizació n.
Se hace refcrencia aquí al objetivo Mc enfrentar un cambio de cultura tic nolú gica, para el 'luc
habrá que prever recursos tecnicos y humanos, y tjuc deberá ser acompañ atlti dcl ncccsario
entrenamiento del personal y usuarios.

Ademas, durante el proceso de ciunbio del sistema será muy importante prever cuá l será
la gestif›n de su evoluciéin posterior; con el fin de evitar que la situaciéin presente vuelva a
repetirse o al rrlenos resulte menos zaumá tica. La gcstiéin Ü c la evolució n debe consistir en cl
ofrecimiento de una respuesta rá pida, prepararla y eficiente a los cambios que se produzcan
en el entorno, ya sean de índole tecnoló gica o de gestif›n del propio ne guciti.
Estrategias de migración

Las estrategias de migración reconocen los dos enfoques siguientes.

a) Habilitación gradual:
La nucva aplicación es construída gradualmente en la plataforma de destino, haciendose
cargo en forma progresiva de las funcionali‹1adcs de la aplicación original, por lo que en este
preceso ambas aplicaciones e.stán integradas en un único sistema con nua transferencia
gradual de responsabilidades de una a otra. Con este enfot¡ue la informaciíín está duplicatia y
es necesario un importante esfuerzo de coordinacif›n para asegurar la integridad y
consistencia de los datos.

b) Habilitación súbita:
La aplicación original mantiene tcdas sus prestaciones mientras la aplicación en la nueva
plataforma es constniida, implementada y probada. Las bases ne datos de esta última son
progrcsivamentc actualizadas hasta el momento en que se ilecide la transferencia del control,
momento en que la aplicación original queda desafectada y sus bases de datos quedan como
rcfcrencia únicamente para consulta. Se debe tener en cucnta que antes del desarrollo del
nuevo sistema, cs imprescindible tencr una comprensión intensiva del sistema a ser mimado.

En cualquier sistema a ser niigrado, algunas características son comunes con todo
proyecto de ingeniería de software, tales como metodología de desarrollo, testing y selección
del modelo de bases de datos. Otras, son específicas de la migración, por lo que se puede
clasificarlas en dos grandes categorías: aquellas tjue conciernen al sistema a migrar, y, las
específicas del sistema mimado, para lo cual es necesario entender las características
intríñsecas de los datos, las interfaces y las aplicaciones involucradas, en cualquier proceso
de migración.

Consecuentemente, antes de tomar cualquier ilecisión sobre la estrategia de migraciéin, se

debe realizar un estudio intensivo a los efectos de cuantificar los riesgos y beneficios, con el
fin de justificar acabadamente la migración a un nuevo sistema, según lo proponen Espiiieira
y Sheldon (2005).

Los pilares de todo el proeeso de migración:

Una niigració n debe apuyarse en tres pilares bá sicos, a saber: 1) una metodologia, 2) un
conjunto de herramientas y 3) técnicas de pruebas y personalizació n. La metodología
garantiza, en primcr lugar, un precedimiento sistcmátieo que asegura que cl trabajo realizado
sea controlable y sus resultados predecibles. En se gundo lug=. °l** s* dÍS{3ORC Ô C tlil
repositorio con toda la informació n necesaria para abordar la migració n: cadenas de
programas, programas fuente, estructura de bases de datos, 1ibren°as de funciones, etc. En
tercer lugar, contempla la obtenció n del modelo de negocio a migrar, a partir de la
informació n contenida en el repositorio, y considera además la realizació n de los planes de
prucba de las aplicacioncs migradas. Por ú ltimo, define las reglas de gencració n dcl có digo
mimado, conforme a los está ndares establecidos, las librerías de funcionem usadas y cualquier
otra consideració n de interés. Las herramientas de migracif›n permiten obtcncr un motlc1o del
negocio a migrar, que lo hace independiente ele los lenguajes de las aplicaciones, con lo cual
el modelo obtenido resultaréi v álido en caso de ser necesarias futums migraciones a otras
tecnologías. Estas hcrranfientas deben permitir, también, la incorporació n de las reglas
bá sicas del negocio a los cfcctos de obtener aplicacioncs optiniizaÜ as para su funciunanú cnto
cn el entorno informá tico existente en una empresa.

Las tecnicas de pruebas y personalizació n incorporan las reglas de generació n

introilucidas por la metodología a los fines Ve obtener aplicaciones funcional y
opcrativamc nte fiables y las opiimiziin para su funcionanucnto en cl entorno inforniá tic u
existente cn la empresa.

La utilizació n Mc cstos tres pilares permite asegurar el éxito del proyecto, mantenicndo
los plazos y costos Ü c realizació n dentro dc las prc visiones.

Metodologías para la migración de sistemas:

I$OfIEC 14764

É ste está ndar internacional titulado “Ingeniería de Software — Prc›ceso del ciclo dc vivia
del software — Mantenimiento”, describe los requerimientos para el mantenimiento del
softwarc. En la secció n 5.5 de cstc está ndar, sc dcfinc y plantea una metodología pam la
migraciíin de software como parte tlel proceso de mantenimiento del software así cunio
también otras actividades quc se deben realizar antes y Ü cspucs del proceso de migració n.

EntradaS El antiguo entc›mo

El nuevo entorno

Proceso Plan de Migración

Para que se pueda cuntrc›1iir de forma atlecuada la migració n de un sistema, se
debe crear un plan de migració n, además de documentarlo y ejecutarlo. Las
actividades de planificaciéin deberían incluir:

Anális is dc requerimientos y tJefinició n dc la migració n

Desarrollo Ue herramientas de ayuda ii la nú graciú n
Conversió n tIe datos y productos software
Ejecució n de la migració n
Vcrificaciú n ú c la migraciÚ n

Notificación del intento

a) Dccliiració n de por qui cl antiguo entorno yii no sc va a soportar.
b) Descripció n ticl nuevo eniurno. con su fccha de dispunibilidad.
 c) Descripción de otras opciones de soportc disponibles, una vez que el apoyo
al antiguo entorno sc ha retirado.

Implementación de las operaciones y entrenamiento

Operaciones paralelas del antiguo y el nuevo entorno se pueden llevar a cabo
para facilitar la transición al nuevo ambiente. Durante este
periodo, se proporcionará la forniación ncccsaria

Notificación del Pinal

Cuando llega la migraciéin programada, la notifieaeió n se enviará a todos los
intercsatlos.

Revisió n post-operació n
Una revisión posterior a la operación se realiza para evaluar el impacto
del cambio al nuevo entorno.

Archivado de datos
Los datos utilizarlos por o asociados con el entorno anterior, deberán scr
accesibles de acuerdo con los requisitos del contrato de protección de datos y
de auditoría aplicables a los datos.

Se basa en los proccxos de la norma ISO/IEC 12207.

Plan de Migraciéin
Herramientas de Migración
Notificación de Intentos
Producto Software Mimado
Notificación de Finalizaciéin
Datos archivados

Cuía para el Plan de Migración a Software Libre en la Administración Pública

Nacional (APN) de La República Bolivariana de Venezuela:

Esta guía fue desarrollaila por cl Centro Nacional de Tecnologías de Informacitin con
el fin de servir de referencia a diferentes Entes Gubernamentales t}ue requieran migrar su
Plataforma Teenolíígica dc Informacitin desde un entorno dc Software Propietario a un
entorno basado en el Software Libre para el uso y/o prestació n de servicios de Tecnologías de
Informació n y Comunicaci/in (TIC).
Esta guía propone las siguientes fases para la migració n efectiva:

Fase Actividades

Recolección de Información
Esta fase brindará los datos necesarios t¡uc hacen falta
para empezar todo el proceso de migración, para esto se
deben tomar en cuenta 3 aspectos principales que
influyen directamcnte en la Plataforma Tecnológica c
Informática de cualquier ente o institución:

u Inventario de Capital Humano.

u Inventario del Hardware utilizado en
la institución.
o Invcntario del tipc de Software que utiliza la
institución.

Capacitaciíín Uno de los puntos claves en cl proceso de migración es

el entrenamiento que sc le debe proporcionar a los
usuarios, el mismo debe contribuir a que el factor de
resistencia al cambio sea lo más bajo posible y las
metodologías de aprendizaje a utilizar deben inccntivar
a la autoformación e investigación.

La capacitación se divide en dos tipos:

o Capacitación del personal técnico.

u Capacitación del usuario final.

Migración Parcial La Migración Parcial contempla el combinar el uso de

sistemas opcracionalcs propietarios con la instalación
en estos de herramientas de software libre que así lo
permitan, ir rccopilando información mediante
ensayos, pniebas o investigación acerca de las
herramientas y aplicaciones de softwarc libre que más
se adapten a la plataforma dcscada, identificación de
los servicios ofrecidos a los usuarios y las
características de la pliitaforma que los soporta.

Migració n Total La Migración Total contempla el cambio total del

 sistema. Se migran todos los servicios y se diseiian
herramientas Open Source.

Soporte posterior a la migraciíín Se refiere a la resolucitin de problemas de primer

nivel que pueda tencr cl usuario al momento de
operar cl equipo ya mimado.
Dcbc existir un pcrsonal de soporte técnico cnc=argado
de resolver estes problemas. La cantidad de personal
técnico por usuario dependerá del tipo y eficiencia de la
plataforma tecnológica de la institucitin, dcl típu de
aplicacioncs que utilize y del plan de atención al
usuario tjue se diverte.

Docuincntación de la migración Se debcrá documentar tedo el precede paso a paso

resaltando las cxpcriencias que se conxidcrcn relevantes
y que puedan ser de utilidad en migracioncs a realizar
en otros entes ti organismos gubcmamentales. Se
dcbcrá documentar tcdas las pruebas realizadas en cl
laboratorio (pruebas de hardware y pruebas de
software), de manera que pueda ser utiliraúa como
material de apuyo y/o referencia para otras
instituciones. La documentaeión de estas pruebas
permitirá elaborar un manual de prccedimicntos y/o
pmtocolos de pruebas, para usar en ellaboratorio. La
documentación deberá realizarem en un formato
cstãndar, donde se detalhe:

Descripción de la actividad realizada

Objetivo y resultados obtenidos, estos
servinin como protocolos de pruebas para
futuras aplicaciones y hardware que necesite
ser verificado.

También deberá realizarse un documento donde

se definan las políticas de uso interno del
laboratorio.

ITIL, Según la organización CA Technologies se ha convertido rápidamente en el

estándar de mejores pnicticas para la administración de servicios y en el lente a través del
cual se visualiza y mide el valor de los servicios. Aun°l*e las tasas de adopciéin varían, no
hay
duda de que muchas organizaciones de TI están recurriendo a ITIL en un intento por mejorar
la calidad y rentabilidad de los servicios que brindan al negocio.

El cielo de vida ITIL esta compuesto por:

• Estrategia del Servicio (Service Strategy)
• Diseiio del Servicio (Service Design)
• Transición del Servicio (Service Transition)
• Operación del Servicio (Service Opcration)
• Perfeccionamiento Continuo del Servicio (Continual Service Improvement)

El módulo de migración (manual) está dividido en los cielos de vida ITIL para su fácil
desarrollo y trazabilidad de los pasos a desarrollar, en cada uno de los procesos y su
ejecución.

1. Service Strategy: En cl ciclo de viila Service Strategy es el encargado de tonta la

cvaluación estratégica a seguir paso por paso, esta muestra la conformación del proyecto,
como visualizarlo y cjccutarlo para todos los otros ciclos de vida ITIL.

Service Strategy

Gestión Financiera

Gestión del Portafolio de Servicios

Gestión de la Demanda

2. Service Design: En el ciclo de vida ITIL Service Design se planea el proceso que se
pensó en ciclo de vida ITL Service Strategy y ponen los puntos de acción que se deben llevar
a cabo y como ejecutarla en este ciclo de vida textos los procesos son válidos ya que cada uno
teca una parte esencial de cómo se lleva a cabo la migración.

Service Design

Gestión del Catálogo de Servicios

Gestión de la Capacidad

Gestión de la Disponibilidad

Gestión de la Seguridad de la Información

Gestión de Proveedores
 3. Service Transition: En el ciclo de vida ITIL Service Transition es cl encargado de
hacer cl tránsito de dcl diseiio a la puesta en marcha, la gestión de cambios no aplica ya quc
la migración no se hace estado de operación, y cl resto de procesos si aplica.

Service Transition

Planificación y Soporte a la Transición

Gestión de Cambios

Gestión de la Configuración y Activos del

Servicio
Valiilación y Pruebas

Evaluació n

Gestión del Conocimiento

4. Service Operation: En el ciclo de vida ITIL Service Opcration sc ponc en marcha

todo lo diseíiado y se gestiona para no tener inconvenientes en la operación, el modo de
ejecución es con el personal de soporte.

Service Operacion

Gestión de Eventos

Gestión de Incidencias

Gestión de Problemas

Gestión de Accesos

5. Continual Service Improvement: En el ciclo de vida ITIL Conlinual Servicc•

Improvenient se generan los informes correspondientes para ser evaluación y generar un plan
de mejora.

Continual Service Improvemcnl

Proceso de mejora de CSI

Informes de servicio
Proyecto sourcePYXfE:

A través de éste se busca promover los beneficios del software libre. Está coordinailo pur
AIMME en cooperación con AIMPLAS, ITI y UPV y promovido por el IMPIVA. El
proyecto, aparte de colaborar en la adaptación de software ya existente y facilitar su
implantacitin en las pymes de estos sectores, ha desarrollado una guía ne buenas prácticas
para la migración desde sistemas propietarios.
La guía plantea las siguientes fases:

Requisitos

Un factor crucial para el éxito de la migració n es el aná lisis en profundidad tte la

situacitin de partida. Esta tarea usualmente consumir a gran parte de los recursos iniciales del
proyecto, tanto en tiempo como en mano de obra. De todas mancras, un conocimiento
detallado de los documentos o las aplicaciones de base de datos evita realizar ajustes
imprevistos durantc la migració n y permite el establecimiento de planes de actuació n con
suficiente antclació n. Además, la determinació n de la situació n de partida es también la base
para identificar los requisitos funcionales del nuevo sistema.
Aspectos importantes a tener en cuenta en este contexto incluyen, por ejemplo, los
siguientes:

• Bases de datos y estructuras de datos

• Documentos y formatos de documentos
• Aplicaciones y sus interfaces
• Funcionalidades disponibles
• Disponibilidad de datos y aplicaciones
• Atajos y problemas
• etcétera

En este punto se da una visión global de tjué es lo que debemos saber sobre la empresa,
sus sistemas de información y su funcionamiento, para maximizar las posibilidades de éxito
en una migración a software libre.

La fase de requisitos se divide en los siguientes puntos:

1. Estado actual
1.1. Descripción general de la empresa
1.2. Aspectos técnicos
1.3. Aspectos de recursos humanos

1.5. Recursos temporales

1.6. Recursos económicos
2. Objetivos
 Una vez se ha llevado a cabo la toma de requisitos, ya se conoce perfectamente el estado
de la empresa en cuanto a software se refiere. Es el momento de empezar a planificar la
estrategia que se va a seguir para llevar la nugración a buen término y lograr los objetivos
establecidos en el punto anterior.

El trabajo del proyecto conficnza estableciendo un plan que describa cl camino a seguir
para llegar al objetivo. El plan de migración debería contener como mínimo la siguiente
información: fecha final del proceso de migración, recursos materiales y humanos,
participaciíín de terceras panes, hitos durante el proceso de migracifín y costes. La
planificaciéin del proyecto es también la base para una gestión eficiente de la migración.

Este es el momento de tomar decisiones en base a la información recogida y dc estas

decisiones depende en gran medida el éxito de la migración.

La fase de planificación se divide en los siguientes puntos:

1. Planificación técnica
l.l. COSfis a tener en cuenta
1.2. Inventario
1.3. Diagrama de red
1.4. Diagrama de estnictura
1.5. Elección de la estrategia ble migración
2. Planificación de comunicaciones
3. Planificación de recursos humanos
3.1. Miedo a lo ilesconocido
3.2. El temor ble que el CV pierda importancia
3.3. Saber es poder
4. Plan de contingencia
5. Planificación temporal
5.1. Planificación de pruebas
S. Plan de evaluación
7. Planificación económica

Implantación

Ha llegado el momento de poner en práctica tcdo lo que se ha estado planificando,

cuantos más recursos se hayan dedicado a la planificación del proyecto, menos incidencias se
encontrarán a la hora de ponerlo en marcha y realizarlo. En este punto se debe empezar a
ejecutar paso a paso todas las tareas planificadas, formación e implantación técnica.

La fase de implantación se divide en los siguientes puntos:

1. Formación
l.l. ¿Cómo realizar la formación?
2. Implantación técnica
2.1. Instalando muchos equipos
2.2. Migrando datos de usuarios a sistemas GNU/Linux
 2.3. Realización de copias de seguridad
2.4. Emulación de aplicaciones
2.5. Servidores de archivos
2.11. Bases de datos
2.7. Sistemas de monitorización y administraciiin
2.8. Otros elementos a migrar
3. Consejos de implantación
3.1. Introducir nuevas aplicaciones en un entorno familiar
3.2. Lo fácil primero
3.3. Mirar hacia adelante

Evaluación

Ejecutar el plan de evaluación y continuar monitorizando el sistema en el tiempo

identificando carencias o mc,joras para incrementar paulatinamente la calidad del sistema de
información de la empresa.

Para evaluar si la migración ha tenido éxito, podemos valorar los siguientes puntos:

• ¡,Se ha migrado el Sistema Operativo de manera satisfactoria?

• (,Se han migrado las aplicaciones?
• (,Se han adaptado los usuarios?
• (,Se ha mejorddo con el cambio?

Directrices IDA de migración a software de fuentes abiertas:

Este documento fue desarrollado por European Comunities y adaptado al español por la
Comisión Europea y el Ministerio de Administraciones Públicas de Espaíia. El objeto de estas
directrices es doble'

1. Ayudar a los Administradores a decidir si se debe emprender una migració n a

OSS (Open Source Sohware).
2. Describir en lenguaje técnico claro có mo se deben"a llevar a cabo dicha
migració n.

Estas directrices van dirigidas a gestorcs y profesionales de Tecnología de la Información

(TI) que estén planificando o ejecutando una migración a software de fuentes abiertas (OSS).
Se basan en la experiencia practica de los autores y en el contenido de un número limitado de
experiencias públicamente accesibles. Estas directrices se han validado en el proceso de
migración a OSS realizado por el Tribunal de Cuentas de Sehwerin en el Lander alemán de
Mecklenberg Vorpommern.

Cualquier ejercicio de migración debe incluir, en general, lo siguiente:

1. Una fase de definición del proyecto y de recopilación de datos, en la que se
contemplen:
A. La descripción del conjunto de condiciones iniciales relevantes consistentes,
por ejemplo, en:
 a) arquitectura o arquitecturas de los sistemas,
b) aplicaciones y sus datos asociados,
c) protocolos y normas empleados,
ú ) hardware.
e) el cntorno físico, como cl ancho de banda ne la red, la ubicació n,
f) los requisitos sf›cialcs como cl idioma o idiomas y la capacitació n del
personal;
B. Un conjunto de condiciones finales con el mismo detalle,
C. Una descripció n de có mo lle gar tte las condiciones iniciales a las condiciones
finales;
2. Una justificació n de la migració n, incluirlo el coste asociado a la misma;
3. Una o más fases piloto preparadas para prcbar si el plan y la justificació n funcionan.
Los status de estas fase s piloto puedc n luego alimentar el moilelo de costes usado en
el plan,
4. Despliegue del plan
5. Seguimiento de la experiencia real en relació n con el plan.

Metodología Caso de estudio — Estrategia Reactiva:

El autor presenta una estrategia para casos úonde la necesidad de migrar sea por una
situación imprevista. Aunque estas situaciones son mu y variables se pueden marcar ciertos
lineamientos en común para abordar las mismas.

1. Notificación úel problema: El cliente reporta un problema que puedc ser úc1
hardware, de software o la combinación úe ambas. El especialista debe tratar úe
obtcncr:
Breve descripción de la situación.
Número y Mensaje que arruja el sistema.
2. Descripción del ambiente:
Describir la plataforma software instalada, con un nivel de detalle en el
que se conozcan las versiones y “re le ases” instalaclos, de calla uno ne los
subsistemas manejados.
Determinar si en la instalación se han realizado motlificaciones propias a
los estándares del producto.
Describir la configuración dcl hardware c interconexiones.
3. Determinación detallada del problema:
Elaborar un diagnóstico lo más exacto y dctallailo posible del problema.
4. En búsqueda de una solución factible:
Apelar a la experiencia y memoria del o los especialistas de servicio a
cargo del problema.
Buscar en las Bases de Datos de Fallas reportadas, para conocer si ha
ocurrido una falla del tipo en c uestión.
Consultar a los laboratorios de ilcsarrollo de productos, cnn una espera
máxima de 48 horas para la respuesta. Mientras se espera, de ser posible,
 debe proveerse al cliente una solució n momentá nea para que al menos
prestc scrvicio a las aplicaciones más importantes para la instalació n.
5. Plan de acciones para la solució n:
- Cambiar valores en algunos pará metros.
Aplicar correctivos al producto.
- Cambiar los índices de rendimiento.
- Chequear el Hartlware aplicando algunos tesis.
Cambiar cl hardware y/o software.
ó . Pruebas de los cambios para la solució n definitiva:
Entonar el sistema: Sc requieren me‹1iciones tjue nos permitan corroborar
que los cambios contribuyeron a la solució n del problema.
- Chequear el efecto que putlicra generar algú n cambio realizado para la
solució n del problema.

Metodología Caso de estudio — Estrategia Proactiva:

ñ Identificació n preliminar del problema: Se realizan los estudios preliminares

para diagnosticas la situació n actual. Es muy probable que sea necesario instalar
algunas aplicaciones •l** permitanmonitorear cl sistema, su carga de trabajo y el
consumo que ésta realiza sobre los diferentes recursos del sistema para así
obtener de una manera sistemática los datos reales y hacer a un lado la intuició n.

S Un requisito fundamental para el inicio de cualquier proyecto planificado debe

considerar la concientizacif›n de la alta gerencia cn gcneral, puesto que para
cualquier proyecto (entonació n, planificació n de capacidades, migració n, prueba
de nuevos productos, respaldos/recuperació n, etc.), se requiere invertir en tiempo,
recurso humano y dinero, para su implantació n y puesta en marcha. Ademá s de
considcrac-iones especialcs, en cuanto a: accesos a las instalaciones en horas no
laborales, permanencia de personal externo a la empresa, traslado de equipos,
incluso situaciones en las que se hacen necesarias modificaciones de la planta
física de la empresa, acceso a informació n confiilencial y otras como posible
acceso a llamadas telefó nicas internacionales, paradas planificadas del sistema
con su consecuente implicació n para la empresa.

P Una vez ganada la alta gerencia, el siguiente paso consiste en conformar un

equipo interdisciplinario que involucre al personal técnico especialista en el
hardware instalado y por instalar, especialistas en soporte a software (Sistemas
Operativos, Reales, Aplicaciones), operadores del sistema, especialistas en
evaluació n del desempeiio. Participanilo en conjunto, tanto personal perteneciente
a la empresa en sí, como un líder que coordina el equipo de trabajo, de acuerdo a
las actividades a realizar y velando por la sinergia del mismo.
 “w A partir Mc la informaciÚ n rccolcctada durante el diagnó stico, se elabora un
plan cictallario Pie trabajo en cl que se estipulan para cacia activiclad: eric n Mc
ejecució n, tiempo estimado tic tiiiraciú n, lus recursos cniplcados y los
responsables. Cabe scñ alar, q ue pueden existir activ idatlcs que se rcalicc n
pizalcliimcntc cn cl tic nipo.

“w Ejccuciéin del plan: En este paso el líder llcva cl control ne las actividades, su
avuncc en cl ticnipu y posibles ajustes de las mismas.

Prucba y verificació n de los efectos esperados.

Comparación de las Metodologías:

Metodología/ ITIL Proactiva Reactiva ISO/ APN IDA SourcePYME

Parámetros IEC
14764

Calidad de Buena Buena Regular Buena Regular

documentación
disponible
Tiempo Alto Alto Bajo Alto Regular Regular Alto
invertido
Habilitación Súbita Súbita Súbita Súbita Gradual Súbita Súbita
gradual o
súbita

Cantidad/ Alta Baja Baja Baja Alta Regular Alto

Calidad de
artefactos
generados
Densidad de Alta Alta Baja Regular Regular Alta
las fase:
Recolección de
información
Densidad de Alta Alta Regular Baja Ba¡a Regular Alta
las fase:
Planificación

Densidad de Alta Baja Regular Baja Regular Baja Alta

las fase:
Evaluar los
resultados
 Bibliografía

Tecnologías Pie Informació n.

International StantJard ISO/IEC 147 64 IEEE Std 147 64-200S. Sccond Edition (200S).

Softsi•nre Enf fu eerinp- SOftsv'nre Lf’fe C ycle Processex - fnixrenonce.

eninmos Web.

Rumero Peilro. Mi prariñn n iii JfÚ rf?ftn ble infnm?fIUf’Gii rolnbrirri finn emprexnrinL

Daniel Enrique Rc›driguez. Mi proc ión r/e In lierrarn fEH te o iftÚ ffC£f t TRS a
CA

Instituto Tecnoló gico ‹le Informá tica.

Aliaga Varillas, Nick Jonathan, Londoñe Ñahuincopa. Jose Luis (2011). Pro5erto the

Aguirre, 1., (Octubre de 2004). Esquema Extrotépico pam un Proceso rle MfgPRCff7fí

IiifoK IRCf O'n. Instituto Politécnico Nacional de Me xico.

t• Galiano, J., (Septiembre de 2012). Proceso de ñ fi#rució ii de Sistemas Weh.

Aplicación al Sistema de RecomeiidRClnn REJA. Univers'idad üe Jaén, Escuela

Politécnica Superior (Jaén).