MIGRACIÓN DE SISTEMAS COMPUTACIONALES

Naguanagua, Junio 2015

Universidad de Carabobo

Facultad Experimental de Ciencias y Tecnología

Departamento de Computación

Metodologías para la Evaluación del Desempeño de

Sistemas Computacionales

Realizado por:

Carlos Gómez CI: 21254227

Jesús Jiménez CI: 23421010

Presentado a: Dra. Mirella Herrera

Migración de Sistemas Computacionales

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

ejecutarse en un entorno diferente. A fin 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 el á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 migración de sistemas destacan las siguientes:

● Ya no existe soporte para el sistema actual.

● No son suficientes las capacidades del hardware actual.

● El mantenimiento del sistema actual resulta ser muy costoso.

● El sistema actual puede no ser compatible con nuevas tecnologías que 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 ideal 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 del hardware. Toda migración incluye una serie de pasos a seguir:

● Determinación de la causa de la migración – Recolección de datos.

● Planificar el momento y procedimiento de migración.

● 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 previsión que deben ser tenidos en cuenta. Todas las

migraciones deben basarse en una cuidadosa planificación para evitar posibles pérdidas 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 e inconvenientes de cada producto. Se

aconseja consultar a los usuarios y explicarles las razones por las que se va a llevar a cabo la

migración y cómo les afectará, para ayudar al éxito del proceso.

Más allá de la migración:

Para solventar los problemas antes planteados, no solo se cuenta con la migración. De

hecho se han propuesto diferentes soluciones que se pueden agrupar en dos categorías,

además de la migración:

a) Reconstrucción:

La reconstrucción implica reescribir las aplicaciones existentes, y dependiendo de la

documentación y conocimiento disponible sobre el sistema actual, puede tratarse desde una

reingeniería hasta el rediseño de un sistema completamente nuevo. Esto último ya fue

referido como abandono del sistema para su sustitución por otro nuevo.

b) Encapsulamiento:

Con encapsulamiento se hace referencia al desarrollo de una envoltura de software

(wrapper) sobre la aplicación existente, con el fin de dotarlo de interfaces con componentes

periféricos que permiten sacarlo de su aislamiento.

La primera es muy poco probable que sea una verdadera opción. La solución casi

siempre recae sobre el encapsulamiento o la migración. El encapsulamiento se puede más

como una solución temporal al problema, quedando la migración como la opción que

verdaderamente representa solidez y previsibilidad futura.

En efecto, en situaciones donde por diferentes motivos se descartan las opciones de

reconstrucción y de encapsulamiento, la migración del sistema a un ambiente abierto se

convierte en la mejor alternativa. Si bien esta es la opción más compleja, las ventajas que se

obtienen a largo plazo justifican ampliamente el esfuerzo que será requerido.

Aquí debe reconocerse que un trabajo de migración es normalmente un proyecto de

ingeniería de sistemas, que por su importancia merece el calificativo de crítico. Esto es así

tanto por la relevancia de los entornos migrados (datos y aplicaciones), que deberán ofrecer

finalmente la misma eficiencia y operatividad que ofrecían en el entorno anterior, como así

también por la necesidad de hacer mínimo el impacto en todos los niveles de la organización.

Se hace referencia aquí al objetivo de enfrentar un cambio de cultura tecnológica, para el que

habrá que prever recursos técnicos y humanos, y que deberá ser acompañado del necesario

entrenamiento del personal y usuarios.

Además, durante el proceso de cambio del sistema será muy importante prever cuál será

la gestión de su evolución posterior; con el fin de evitar que la situación presente vuelva a

repetirse o al menos resulte menos traumática. La gestión de la evolución debe consistir en el

ofrecimiento de una respuesta rápida, preparada y eficiente a los cambios que se produzcan

en el entorno, ya sean de índole tecnológica o de gestión del propio negocio.

Estrategias de migración

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

a) Habilitación gradual:

La nueva aplicación es construida gradualmente en la plataforma de destino, haciéndose

cargo en forma progresiva de las funcionalidades de la aplicación original, por lo que en este

proceso ambas aplicaciones están integradas en un único sistema con una transferencia

gradual de responsabilidades de una a otra. Con este enfoque la información está duplicada y

es necesario un importante esfuerzo de coordinación para asegurar la integridad y

consistencia de los datos.

b) Habilitación súbita:

La aplicación original mantiene todas sus prestaciones mientras la aplicación en la nueva

plataforma es construida, implementada y probada. Las bases de datos de esta última son

progresivamente actualizadas hasta el momento en que se decide la transferencia del control,

momento en que la aplicación original queda desafectada y sus bases de datos quedan como

referencia únicamente para consulta. Se debe tener en cuenta que antes del desarrollo del

nuevo sistema, es imprescindible tener una comprensión intensiva del sistema a ser migrado.

En cualquier sistema a ser migrado, 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 que conciernen al sistema a migrar, y, las

específicas del sistema migrado, para lo cual es necesario entender las características

intrínsecas de los datos, las interfaces y las aplicaciones involucradas, en cualquier proceso

de migración.

Consecuentemente, antes de tomar cualquier decisión sobre la estrategia de migración, 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 Espiñeira

y Sheldon (2005).

Los pilares de todo el proceso de migración:

Una migración debe apoyarse en tres pilares básicos, a saber: 1) una metodología, 2) un

conjunto de herramientas y 3) técnicas de pruebas y personalización. La metodología

garantiza, en primer lugar, un procedimiento sistemático que asegura que el trabajo realizado

sea controlable y sus resultados predecibles. En segundo lugar, que se dispone de un

repositorio con toda la información necesaria para abordar la migración: cadenas de

programas, programas fuente, estructura de bases de datos, librerí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

prueba de las aplicaciones migradas. Por último, define las reglas de generación del código

migrado, conforme a los estándares establecidos, las librerías de funciones usadas y cualquier

otra consideración de interés. Las herramientas de migración permiten obtener un modelo del

negocio a migrar, que lo hace independiente de los lenguajes de las aplicaciones, con lo cual

el modelo obtenido resultará válido en caso de ser necesarias futuras migraciones a otras

tecnologías. Estas herramientas deben permitir, también, la incorporación de las reglas

básicas del negocio a los efectos de obtener aplicaciones optimizadas para su funcionamiento

en el entorno informático existente en una empresa.

Las técnicas de pruebas y personalización incorporan las reglas de generación

introducidas por la metodología a los fines de obtener aplicaciones funcional y

operativamente fiables y las optimizan para su funcionamiento en el entorno informático

existente en la empresa.

La utilización de estos tres pilares permite asegurar el éxito del proyecto, manteniendo

los plazos y costos de realización dentro de las previsiones.

Metodologías para la migración de sistemas:

ISO/IEC 14764

Éste estándar internacional titulado “Ingeniería de Software – Proceso del ciclo de vida

del software – Mantenimiento”, describe los requerimientos para el mantenimiento del

software. En la sección 5.5 de este estándar, se define y plantea una metodología para la

migración de software como parte del proceso de mantenimiento del software así como

también otras actividades que se deben realizar antes y después del proceso de migración.

Entradas El antiguo entorno

El nuevo entorno

Proceso Plan de Migración

Para que se pueda controlar de forma adecuada la migración de un sistema, se

debe crear un plan de migración, además de documentarlo y ejecutarlo. Las

actividades de planificación deberían incluir:

● Análisis de requerimientos y definición de la migración

● Desarrollo de herramientas de ayuda a la migración

● Conversión de datos y productos software

● Ejecución de la migración

● Verificación de la migración

Notificación del intento

a) Declaración de por qué el antiguo entorno ya no se va a soportar.

b) Descripción del nuevo entorno, con su fecha de disponibilidad.

c) Descripción de otras opciones de soporte disponibles, una vez que el apoyo

al antiguo entorno se 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 formación necesaria

Notificación del final

Cuando llega la migración programada, la notificación se enviará a todos los

interesados.

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 utilizados por o asociados con el entorno anterior, deberán ser

accesibles de acuerdo con los requisitos del contrato de protección de datos y

de auditoría aplicables a los datos.

Soporte

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

Salidas Plan de Migración

Herramientas de Migración

Notificación de Intentos

Producto Software Migrado

Notificación de Finalización

Datos archivados

Guí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 desarrollada por el Centro Nacional de Tecnologías de Información con

el fin de servir de referencia a diferentes Entes Gubernamentales que requieran migrar su

Plataforma Tecnológica de Información desde un entorno de 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ón (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 que hacen falta

para empezar todo el proceso de migración, para esto se

deben tomar en cuenta 3 aspectos principales que

influyen directamente en la Plataforma Tecnológica e

Informática de cualquier ente o institución:

● Inventario de Capital Humano.

● Inventario del Hardware utilizado en la

institución.

● Inventario del tipo de Software que utiliza la

institución.

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

el entrenamiento que se 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 incentivar

a la autoformación e investigación.

La capacitación se divide en dos tipos:

● Capacitación del personal técnico.

● Capacitación del usuario final.

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

sistemas operacionales propietarios con la instalación

en éstos de herramientas de software libre que así lo

permitan, ir recopilando información mediante ensayos,

pruebas o investigación acerca de las herramientas y

aplicaciones de software libre que más se adapten a la

plataforma deseada, identificación de los servicios

ofrecidos a los usuarios y las características de la

plataforma que los soporta.

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

sistema. Se migran todos los servicios y se diseñan

herramientas Open Source.

Soporte posterior a la migración Se refiere a la resolución de problemas de primer nivel

que pueda tener el usuario al momento de operar el

equipo ya migrado.

Debe existir un personal de soporte técnico encargado

de resolver estos problemas. La cantidad de personal

técnico por usuario dependerá del tipo y eficiencia de la

plataforma tecnológica de la institución, del tipo de

aplicaciones que utilice y del plan de atención al

usuario que se diseñe.

Documentación de la migración Se deberá documentar todo el proceso paso a paso

resaltando las experiencias que se consideren relevantes

y que puedan ser de utilidad en migraciones a realizar

en otros entes u organismos gubernamentales. Se

deberá documentar todas las pruebas realizadas en el

laboratorio (pruebas de hardware y pruebas de

software), de manera que pueda ser utilizada como

material de apoyo y/o referencia para otras

instituciones. La documentación de estas pruebas

permitirá elaborar un manual de procedimientos y/o

protocolos de pruebas, para usar en el laboratorio. La

documentación deberá realizarse en un formato

estándar, donde se detalle:

● Descripción de la actividad realizada

● Objetivo y resultados obtenidos, estos servirán

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

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

estándar de mejores prácticas para la administración de servicios y en el lente a través del

cual se visualiza y mide el valor de los servicios. Aunque las tasas de adopción 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 ciclo de vida ITIL esta compuesto por:

Estrategia del Servicio (Service Strategy)

Diseño del Servicio (Service Design)

Transición del Servicio (Service Transition)

Operación del Servicio (Service Operation)

Perfeccionamiento Continuo del Servicio (Continual Service Improvement)

El módulo de migración (manual) está dividido en los ciclos 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 el ciclo de vida Service Strategy es el encargado de toda la

evaluación estratégica a seguir paso por paso, esta muestra la conformación del proyecto,

como visualizarlo y ejecutarlo 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 todos los procesos son válidos ya que cada uno

toca 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 el encargado de

hacer el tránsito de del diseño a la puesta en marcha, la gestión de cambios no aplica ya que

la migración no se hace estado de operación, y el 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

Validación y Pruebas

Evaluación

Gestión del Conocimiento

4. Service Operation: En el ciclo de vida ITIL Service Operation se pone en marcha

todo lo diseñado y se gestiona para no tener inconvenientes en la operación, el modo de

ejecución es con el personal de soporte.

Service Operation

Gestión de Eventos

Gestión de Incidencias

Gestión de Peticiones

Gestión de Problemas

Gestión de Accesos

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

Improvement se generan los informes correspondientes para ser evaluación y generar un plan

de mejora.

Continual Service Improvement

Proceso de mejora de CSI

Informes de servicio

Proyecto sourcePYME:

A través de éste se busca promover los beneficios del software libre. Está coordinado por

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

implantación en las pymes de estos sectores, ha desarrollado una guía de 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 de la

situación 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 maneras, un conocimiento

detallado de los documentos o las aplicaciones de base de datos evita realizar ajustes

imprevistos durante la migración y permite el establecimiento de planes de actuación con

suficiente antelació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 qué 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.4. Aspectos Legales

1.5. Recursos temporales

1.6. Recursos económicos

2. Objetivos

Planificación

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 migración a buen término y lograr los objetivos

establecidos en el punto anterior.

El trabajo del proyecto comienza estableciendo un plan que describa el 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 partes, hitos durante el proceso de migración y costes. La

planificación 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 de 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

1.1. Cosas a tener en cuenta

1.2. Inventario

1.3. Diagrama de red

1.4. Diagrama de estructura

1.5. Elección de la estrategia de migración

2. Planificación de comunicaciones

3. Planificación de recursos humanos

3.1. Miedo a lo desconocido

3.2. El temor de que el CV pierda importancia

3.3. Saber es poder

4. Plan de contingencia

5. Planificación temporal

5.1. Planificación de pruebas

6. Plan de evaluación

7. Planificación económica

Implantación

Ha llegado el momento de poner en práctica todo 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

1.1. ¿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.6. Bases de datos

2.7. Sistemas de monitorización y administración

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 mejoras 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 mejorado 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ña. 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 Software).

2. Describir en lenguaje técnico claro cómo se debería llevar a cabo dicha

migración.

Estas directrices van dirigidas a gestores 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 práctica 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 Schwerin 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,

d) hardware,

e) el entorno físico, como el ancho de banda de la red, la ubicación,

f) los requisitos sociales como el 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 llegar de las condiciones iniciales a las condiciones

finales;

2. Una justificación de la migración, incluido el coste asociado a la misma;

3. Una o más fases piloto preparadas para probar si el plan y la justificación funcionan.

Los datos de estas fases piloto pueden luego alimentar el modelo 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 donde la necesidad de migrar sea por una

situación imprevista. Aunque estas situaciones son muy variables se pueden marcar ciertos

lineamientos en común para abordar las mismas.

1. Notificación del problema: El cliente reporta un problema que puede ser del

hardware, de software o la combinación de ambas. El especialista debe tratar de

obtener:

- Breve descripción de la situación.

- Número y Mensaje que arroja 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 “releases” instalados, de cada uno de los

subsistemas manejados.

- Determinar si en la instalación se han realizado modificaciones propias a

los estándares del producto.

- Describir la configuración del hardware e interconexiones.

3. Determinación detallada del problema:

- Elaborar un diagnóstico lo más exacto y detallado 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 cuestión.

- Consultar a los laboratorios de desarrollo de productos, con 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

preste servicio 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 Hardware aplicando algunos tests.

- Cambiar el hardware y/o software.

6. Pruebas de los cambios para la solución definitiva:

- Entonar el sistema: Se requieren mediciones que nos permitan corroborar

que los cambios contribuyeron a la solución del problema.

- Chequear el efecto que pudiera 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 que permitan monitorear el 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.

Un requisito fundamental para el inicio de cualquier proyecto planificado debe

considerar la concientización de la alta gerencia en general, 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

consideraciones especiales, 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 confidencial y otras como posible

acceso a llamadas telefónicas internacionales, paradas planificadas del sistema

con su consecuente implicación para la empresa.

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, Redes, Aplicaciones), operadores del sistema, especialistas en

evaluación del desempeño. Participando en conjunto, tanto personal perteneciente

a la empresa en sí, como un líder que coordine el equipo de trabajo, de acuerdo a

las actividades a realizar y velando por la sinergia del mismo.

A partir de la información recolectada durante el diagnóstico, se elabora un

plan detallado de trabajo en el que se estipulan para cada actividad: orden de

ejecución, tiempo estimado de duración, los recursos empleados y los

responsables. Cabe señalar, que pueden existir actividades que se realicen

paralelamente en el tiempo.

Ejecución del plan: En este paso el líder lleva el control de las actividades, su

avance en el tiempo y posibles ajustes de las mismas.

Prueba y verificación de los efectos esperados.

Comparación de las Metodologías:

Metodología/ Parámetros

ITIL Proactiva Reactiva ISO/ IEC

14764

APN IDA SourcePYME

Calidad de documentación disponible

Buena - - Buena Regular Buena Regular

Tiempo invertido

Alto Alto Bajo Alto Regular Regular Alto

Habilitación gradual o súbita

Súbita Súbita Súbita Súbita Gradual Súbita Súbita

Cantidad/ Calidad de artefactos generados

Alta Baja Baja Baja Alta Regular Alto

Densidad de las fase: Recolección de información

- Alta Alta Baja Regular Regular Alta

Densidad de las fase: Planificación

Alta Alta Regular Baja Baja Regular Alta

Densidad de las fase: Evaluar los resultados

Alta Baja Regular Baja Regular Baja Alta

Bibliografía

Guía para el plan de migración a software libre en la Administración Publica

Nacional (APN) de la República Bolivariana de Venezuela. Centro Nacional de

Tecnologías de Información.

International Standard ISO/IEC 14764 IEEE Std 14764-2006. Second Edition (2006).

Software Engineering- Software Life Cycle Processes – Maintenance.

Maria Elena Ciolli (2007) Testing de migracion de aplicaciones distribuidas a

entornos Web.

Romero Pedro. Migración a un sistema de información colaborativo empresarial.

Caso de estudio: Sistema de venta de repuestos a los trabajadores de General Motors

Venezolana, C.A.

Daniel Enrique Rodriguez. Migración de la herramienta ofimática OTRS a CA

Service Desk Manager en Mesas de Ayuda en Servicio Corporativo utilizando las

buenas practicas ITIL.

Proyecto SourcePYME. Migración al software libre – Guía de buenas prácticas.

Instituto Tecnológico de Informática.

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

Metodologia para la migración de Sistemas Educativo Distribuido a entornos web.

Directrices IDA de migración a software de fuentes abiertas. Netproject Ltd.

Aguirre, J., (Octubre de 2004). Esquema Estratégico para un Proceso de Migración

de Sistemas Tecnológicos e Informáticos para una Empresa Operadora de

Información. Instituto Politécnico Nacional de México.

Galiano, J., (Septiembre de 2012). Proceso de Migración de Sistemas Web.

Aplicación al Sistema de Recomendación REJA. Universidad de Jaén, Escuela

Politécnica Superior (Jaén).