Método de Migración de Sistemas Legados Hacia Tecnologías
Vigentes
L.A. Gutiérrez Romo, J. Muñoz López, L. Garza González
Resumen: Mantener un sistema legado consume
recursos y es muy complejo, debido a que se
requiere contar con gente especializada, sistemas
de software y hardware de cómputo que ya no son
soportados ni están disponibles en el mercado; por
lo que es necesario migrarlo a una tecnología más
actualizada y con mejor soporte, más sencilla de
mantener y resulte menos costosa. En esta
investigación se propone un método de migración,
de sistemas legados hacia nuevos sistemas basados
en tecnologías vigentes minimizando el
acoplamiento para facilitar su evolución
arquitectónica y aumentar su disponibilidad, en
comparación con el sistema legado.
Abstract: Maintaining a legacy system consumes
resources and is very complex, because people are
required to have specialized software systems and
computer hardware that are no longer supported or
available in the market, hence it is necessary to
migrate to a technology updated with better
support, easier to maintain and are least costly. This
research proposes a method for migration legacy
systems to new systems based on existing
technologies while minimizing the coupling to
facilitate architectural evolution and increase its
availability, compared with the legacy system
Palabras claves: sistema legado, acoplamiento,
disponibilidad, método de migración de sistemas
legados a nuevas tecnologías.
Introducción El avance de las tecnologías de información
proporciona beneficios a las organizaciones que
hacen uso de estas, pero al paso de los años estos
beneficios o ventajas competitivas se pierden
debido a que los procesos del negocio son
dinámicos y cambian junto a su entorno. En la
presente investigación se ha propuesto un método
de migración de sistemas legados hacia tecnologías
vigentes para ayudar a recuperar las ventajas que se
tenían en un principio y agregar nuevas
funcionalidades, esto gracias a que se cuenta con la
experiencia de los años que se han trabajado con
los sistemas legados. La propuesta se basa en
disciplinas como la ingeniería de requerimientos y
la arquitectura orientada a servicios.
Este trabajo se divide en tres secciones: la primera
abarca la problemática actual de los sistemas
legados, algunas maneras de tratarlos y una breve
explicación del objetivo de la migración a una
arquitectura orientada a servicios; Posteriormente
se definen teorías que sustentan esta investigación
y por último se presenta la propuesta del método de
migración de sistemas legados hacia tecnologías
vigentes definiendo y describiendo brevemente
cada una de sus actividades. Al final se presentan
propuestas de trabajos futuros enfocadas a la
consolidación y ampliación de la propuesta.
Problemática A lo largo de los años las organizaciones han
utilizado las ventajas que brindan las tecnologías de
información pero dichas ventajas se comienzan a
volver menos evidentes debido al paso del tiempo.
Las empresas que cuentan con sistemas desde hace
algún tiempo, han invertido recursos para
actualizarlos hacia una nueva tecnología; sin
embargo muchos de estos intentos no han resultado
y se ha desistido de realizarlos.
Varios autores han notado la proliferación de
sistemas que han dejado de evolucionar los cuales
han denominado “Sistemas legados” o “Sistemas
heredados”. Estos tipos de sistemas han sido
definidos como: “aquel software que fue
desarrollado hace décadas y ha sido modificado en
forma continua para cumplir con los
requerimientos de los cambios en los negocios y en
las plataformas de computo. La proliferación de
dichos sistemas ha causado dolores de cabeza a las
__________________________________________________
Luis Antonio Gutiérrez Romo, Universidad autónoma de
Aguascalientes, Av. Universidad #940 C.P. 20100 Ciudad
Universitaria, México. E-mail: [email protected]
Juan Muñoz López, Universidad autónoma de Aguascalientes, Av.
Universidad #940 C.P. 20100 Ciudad Universitaria, México. E-mail:
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
grandes organizaciones, las cuales los perciben
como costosos en su mantenimiento y riesgosos en
su evolución” [1]. Al entender la definición
anterior se puede comprender que a los sistemas
legados se les han realizados cambios, a esto se le
conoce como mantenimiento lo cual para algunos
autores como Bennett et al [2], el mantenimiento es
la primera forma de evolución del software. El
mantenimiento ayuda a corregir fallas, mejorar el
rendimiento u otros atributos y/o adaptar el
software a un ambiente modificado [3].
Existen desventajas al aplicar esta estrategia como
lo es el aumento en la complejidad del sistema y la
inversión de más recursos en comparación a los
recursos utilizados en el desarrollo original de la
aplicación.
Otras estrategias que han sido utilizadas son:
La reingeniería de software la cual se
encarga de reestructurar el cuerpo del
código sin alterar su comportamiento
externo, pero la realización de esto no
asegura su mantenibilidad en comparación
a la mantenibilidad de un sistema nuevo
realizado con técnicas de ingeniería de
software.
La reconstrucción arquitectónica, la cual
se encarga de recobrar la arquitectura de
algún sistema ya implantado, ayudando a
tener un mejor entendimiento del sistema
legado e identificar y documentar las
dependencias que no han sido
documentadas o no se conocían, su
desventaja es que es la técnica que lleva
más tiempo al aplicarla.
En la actualidad existen tecnologías como la
Arquitectura Orientada a Servicios (SOA por sus
siglas en inglés) la cual puede ayudar a minimizar
los problemas de tener implementado los sistemas
legados. Algunas de las ventajas que menciona la
Organización para la formulación de normas de
información estructurada (OASIS, por sus siglas en
inglés) es que los sistemas construidos bajo esta
arquitectura facilitando que sean escalables,
evoluciónales y manejables [4], además que gracias
al ser una arquitectura basada en servicios permite
la comunicación entre computadoras, vendedores y
diferentes programas de diferentes áreas
funcionales en otras palabras se puede decir que
pueden ayudar a la globalización e integración de
organizaciones dispersas geográficamente [5].
Para evolucionar un sistema legado hacia SOA será
necesario realizar una serie de tareas entre las
cuales está la identificación de servicios y la
reconstrucción arquitectónica, esto es, habrá que
modificar su estructura interna para que sus
módulos y componentes se adapten al nuevo
paradigma.
Software legado Como ya se mencionó anteriormente el software
legado que fue desarrollado hace varios años y que
además ha sido modificado de manera continua
para ir a la par de los procesos del negocio y las
plataformas de cómputo y estos persisten como el
soporte de las funciones de las organizaciones y
cualquier falla puede llegar a ser critica [1] [6] [7].
Algunas de las razones que las organizaciones se
decidan a realizar la evolución de sus sistemas son
[6]:
Tanto las tecnologías como los ambientes
cambian provocando la adaptación de los
sistemas.
Los nuevos requerimientos del negocio
provocan la necesidad de cambiar el
software.
Los sistemas aumentan su tamaño a causa
de las modificaciones y los nuevos
requerimientos.
El aumento de información hace necesario
la utilización de base de datos
El rediseño de un software para trabajar
dentro de un ambiente de red además de
tener en cuenta que algunas veces es
necesario realizar cambios en hardware,
sistemas operativos, protocolos de
comunicación y/o estándares
Técnicas de migración de sistemas En la actualidad existen varias técnicas para
realizar la evolución o mantenimiento de los
sistemas que ahora se consideran como sistemas
legados, estas técnicas son:
Wrapping: esta técnica permite el re uso de los
componentes que ya han sido probados y se tiene
confianza en ellos, la forma más barata y efectiva
de esta técnica es la llamada envoltura de pantalla
ya que mantiene la información sin modificaciones,
la desventaja de esta técnica es que no aborda los
problemas graves como la sobre carga,
funcionalidad estática y los altos costos de
mantenimiento [8].
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Redesarrollo: se refiera a reescribir el software
legado para esto es necesario tener conocimiento de
las funcionalidades del sistema legado y ninguna
parte del código original es reutilizado,
desafortunadamente el riesgo de fallar es muy alto
además que la tecnología y los procesos del
negocio cambian constantemente [9].
Migración: esta técnica reúne lo mejor de las
anteriores ya que dependiendo de las necesidades
es la técnica que aplica obteniendo mejor eficiencia
de diseño y costo en comparación de utilizarlas de
manera individual [9].
Reingeniería: se encarga de reestructurar el cuerpo
del código sin alterar su comportamiento externo.
El realizar la reingeniería ayuda a limpiar el código
disminuyendo la probabilidad de introducir nuevos
errores y convertirlo de un mal diseño a uno bueno.
Los costos aumentan debido a la baja calidad del
software, el aumento de documentación, falta de
personal para el mantenimiento. La desventaja de la
utilización de esta técnica es que no asegura la
mantenibilidad como la de un nuevo sistema
realizado con técnicas de ingeniería de software
[10].
Evolución Arquitectónica: técnica que se encarga
de reconstruir o recobrar la arquitectura de algún
sistema ya implantado, la cual ayuda para tener un
mejor entendimiento del sistema legado e
identificar y documentar las dependencias que no
han sido documentadas o no se conocían [11]. Sus
principales objetivos son la reducción de costos,
utilización de ambientes distribuidos (cliente-
servidor) y la tendencia de las organizaciones a no
mantener todos sus recursos en una sola ubicación
[12]. Esta técnica es la mejor pero su desventaja es
que es la técnica que lleva más tiempo al aplicarla.
Mantenimiento: el mantenimiento es tomado
como una técnica de migración debido a que este
considerado como la primera forma de evolución
del software [12]. El mantenimiento de software es
“La modificación a un producto de software
después de haber sido entregado para corregir
fallas, mejorar el rendimiento u otros atributos o
adaptar el producto a un ambiente modificado” [3].
Las desventajas de esta técnica es una
implementación lenta y representa el costo más alto
de todo el ciclo de sistemas además que aumentará
la complejidad del sistema.
Arquitectura Orientada a Servicios La Arquitectura Orientada a Servicios (SOA)
establece un marco de diseño para la integración de
aplicaciones independientes de manera que desde la
red pueda accederse a sus funcionalidades, las
cuales se ofrecen como servicios. La forma más
habitual de implementarla es mediante Servicios
Web, una tecnología basada en estándares e
independiente de la plataforma, con la que SOA
puede descomponer aplicaciones monolíticas en un
conjunto de servicios e implementar esta
funcionalidad en forma modular [13].
El objetivo de la arquitectura orientada a servicios
logra una reducción en los costos de los entregables
de los servicios esto se logra a través de la
estandarización y el re uso [14]. Los beneficios que
se pueden obtener de utilizar una Arquitectura
Orientada a Servicios (SOA) son [15]:
Los sistemas pueden ser fácilmente
modificados o remplazados por otros
servicios.
El desarrollo es rápido y barato, gracias a
la reutilización, el desarrollo de sistemas
por separado y el uso de estándares.
La operación y costos de mantenimiento
pueden ser reducidos
La calidad puede aumentar y ser
homogénea
El aislamiento de fallas es sencillo.
Se eligió el uso de esta arquitectura para esta
investigación debido a que utiliza los servicios para
construir el sistema facilitando la integración
empresarial y el re uso de componentes gracias al
bajo acoplamiento [16].
Ingeniería de Requerimientos
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
La ingeniería de requerimientos debe de adaptarse
a las necesidades del proceso, proyecto, el producto
y las personas que realizan el trabajo [6], es por
esto que se decidió la utilización de esta actividad
de la ingeniería de software ya que para el método
de migración es necesario tomar los requerimientos
de los usuarios del sistema legado y de los nuevos
usuarios.
Esta actividad es la manera más apropiada para
comprender lo que el cliente quiere, analiza las
necesidades, evaluar que tan factible es, negocia la
solución, se especifica las soluciones, se valida
dicha especificación y se administran hasta que se
convierten en el sistema [6].
Un proceso propuesto por Sommerville en [12]
para llevar acabo las actividades de la ingeniería de
requerimientos lo cual lo divide en cuatro dichas
actividades son:
1. Estudio de viabilidad
2. Obtención y análisis de requerimientos
3. Especificación de requerimientos
4. Validación de requerimientos
Estas actividades como ya se mencionó
anteriormente se verán reflejadas en el método de
migración propuesto.
Desarrollo El método de migración de sistemas legados hacia
tecnologías vigentes (Imagen 1) se encuentra
dividido en las fases del diseño normal de sistemas
las cuales son Análisis, diseño, programación,
pruebas e implantación esto con la finalidad de que
se facilite y entienda las actividades que se
desempeñaran durante la migración. En cada una
de estas fases se encuentran doce actividades y
cada una de estas actividades contiene tareas
específicas que se deben de realizar para lograr la
migración del sistema. Se considera método de
migración puesto que se pueden utilizar partes del
sistema legado para el funcionamiento del nuevo
sistema. Estas actividades son:
Análisis
1. Comprensión del dominio
2. Establecer el estado del sistema
legado
3. Nuevos requerimientos
4. Identificación de servicios y
análisis de riesgo
5. Especificación de requerimientos
6. Validación de requerimientos
Método de Migración de sistemas legados hacia tecnologías vigentes
Impl
anta
ción
Pru
ebas
Pro
gram
ació
nD
iseñ
oA
nális
is
Comprensión
del Dominio
Establecer
el estado
del Sistema legado
Nuevos
Requerimientos
Identificación
de servicios
y análisis de Riesgos
Especificación
de RequerimientosValidación
de requerimientosPriorización
de requerimientos
Establecer
el diseño del
sistema objetivo
Plan de
Migración
Migración
del
Sistema
Pruebas al
Sistema
Sistema
Migrado
Imagen 1. Método de migración.
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
7. Priorización de requerimientos
Diseño
8. Establecer el diseño del sistema
objetivo
9. Plan de migración
Programación
10. Migración del sistema
Pruebas
11. Pruebas al sistema
Implantación
12. Sistema Migrado
Estas actividades fueron tomadas para obtener toda
la experiencia del sistema legado y no desperdiciar
todos los años en que la empresa utilizo sus
sistemas.
Comprensión del dominio
El objetivo de esta actividad es el comprender en
qué ambiente se encuentra en funcionamiento el
sistema legado y en donde se desempeñará el nuevo
y se obtendrá un documento de comprensión del
dominio. Para esta actividad se tomó como base el
trabajo de Sommerville [12] y se enriqueció con
algunos aspectos adicionales, identificando tareas
específicas como la obtención de los objetivos del
sistema, entradas y salidas de información, que
sistemas se utilizan en la organización, los procesos
del negocio y la lista de interesados (stakeholders).
Ver tabla 1.
1.- Compresión del Dominio
Entradas Salidas
1.1.- Objetivos del sistema
Documento de compresión
del Dominio
1.2.- Entradas y salidas de Información
1.3.- Sistemas utilizados en la
organización
1.4.- Procesos del negocio
1.5.- Lista de stakeholders
Tabla 1. Comprensión del dominio.
Establecer el estado del sistema legado
Una que se ha establecido en donde trabaja el
sistema legado se debe de reunir toda la
información con la que se cuente acerca de este y
así obtener un documento del estado actual del
sistema legado. Las tareas que se deberán de
realizar en esta actividad son (ver tabla 2):
La recopilación de la documentación que
se produjo cuando se diseñó por primera
vez el sistema o durante el
mantenimiento.
La arquitectura del sistema, si no se
cuenta con esta se deberá de realizar una
reconstrucción arquitectónica para
obtenerla.
Funcionalidad desde el punto de vista de
los usuarios del sistema, para esto se
deberá de recolectar toda la información
referente de como los usuarios perciben el
sistema.
Errores que se presentan al usuario y no
han sido corregidos esto con la finalidad
de corregirlos o evitarlos en el nuevo
sistema.
Partes del sistema que ya no son
utilizadas, se busca entender que
variaciones han surgido durante la vida de
la organización y del sistema.
Ubicación y estructura de los datos, esto
para tener toda información que se ha
recopilados por los largos de los años.
Tabla de función del proceso del negocio,
el cual es una guía para establecer que
partes del sistema cubren los procesos del
negocio.
Información de la interacción con otros
sistemas, esto debido a que actualmente
debe de haber intercomunicación entre los
sistemas de la misma empresa u otras
organizaciones.
Documento de compresión del dominio el
cual se desprende de la actividad anterior.
2.- Establecer el estado actual del Sistema legado
Entradas Salidas
2.1.- Recopilación de documentación existente
Documento del estado actual del sistema legado
2.2.- Arquitectura del sistema
2.3.- Funcionalidad desde el
punto del usuario del sistema
2.3.1.- Errores que se presentan al usuario y no han sido
corregidos
2.3.2.- Partes del sistema que ya no son utilizadas (y porque)
2.4.- Ubicación y estructura de
los datos
2.5.- Tabla de funciones que
cubren procesos del negocio
2.6.- Información de la
interacción con otros sistemas
2.7.- Documento de comprensión del dominio
Tabla 2. Establecer el estado actual del Sistema legado.
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Nuevos requerimientos
Para esta actividad se tomaran en cuenta los
requerimientos que aporten los usuarios del sistema
legado ya que ellos tienen mayor contacto con el
sistema legado y los procesos del negocio y los
requerimientos de los nuevos usuario ya que un
servicio debe de tener la capacidad de ser utilizado
por varios usuarios (ver Tabla 3).
3.- Nuevos Requerimientos
Entradas Salidas
Requerimientos de
Stakeholders
Documento de nuevos requerimientos
3.1.- Requerimientos de los usuarios del sistema
legado
3.2.- Requerimientos de nuevos usuarios
Tabla 3. Nuevos Requerimientos
Identificación de servicios y análisis de Riesgos
Para la realización de esta actividad se de tener
finalizada las actividades anteriores ya que a partir
de los requerimientos y del estado actual del
sistema se determinará que puede llegar a
convertirse en un servicio para el nuevo sistema,
obteniendo con esto un documento de
identificación de servicios y un análisis de riesgos
de lo que pueda ocurrir durante la migración (ver
Tabla 4).
4.- Identificación de servicios y análisis de Riesgos
Entradas Salidas
4.1.- Documento de nuevos
requerimientos Documento de Identificación
de servicios y análisis de
Riesgos 4.2.- Documento del estado actual del sistema
Tabla 4. Identificación de servicios y análisis de Riesgos
Especificación de requerimientos
Para esta actividad se requiere el documento de
identificación de servicios y análisis de riesgos y
ayudará a realizar una especificación a detalle de
todos aquellos requerimientos que serán tomados
en cuenta para la migración del sistema legado y
como resultado se tendrá un documento con la
especificación de los requerimientos (ver Tabla 5).
5.- Especificación de requerimientos
Entradas Salidas
5.1.- Documento de Identificación de servicios y
análisis de Riesgos
Documento de especificación de requerimientos
Tabla 5. Especificación de requerimientos
Validación de requerimientos
Será necesario tener el documento de
especificación de requerimientos y a partir de este
documento se asegurará que todos los requisitos de
software se descrito de manera precisa además de
detectar las inconsistencias omisiones y errores
(ver Tabla 6).
6.- Validación de los requerimientos
Entradas Salidas
6.1.- Documento de
especificación de
requerimientos
Documento de requerimientos
validados
Tabla 6. Validación de los requerimientos
Priorización de requerimientos
Es necesario que se realice la priorización de los
requerimientos, esto con el objetivo de que se
comience a desarrollar lo que es vital para el
funcionamiento de la organización, es necesario
contar con el documento de requerimientos
validados (ver Tabla 7).
7.- Priorización de Requerimientos
Entradas Salidas
7.1.- Documento de
requerimientos validados
Lista de requerimientos (por
prioridad de desarrollo)
Tabla 7. Priorización de requerimientos
Establecer el diseño del sistema objetivo
Esta actividad ocupa una gran cantidad de recursos
del método, debido a que aquí se tomarán los
documentos de requerimientos validados,
comprensión del dominio, estado actual del sistema
legado y especificación de requerimientos y se
deberán de hacer tareas como la realización de la
nueva arquitectura, determinación de que parte del
sistema legado será reutilizado, los requerimientos
funcionales y no funcionales y los servicios
candidatos además del Análisis y diseño de SOA
(ver Tabla 8).
8.- Establecer el diseño del sistema objetivo
Entradas Salidas
8.1.- Documento de
requerimientos
validados
Servicios candidatos
Que parte del sistema legado será
utilizado para el sistema migrado
8.2.- Documento de compresión del
Dominio Arquitectura del nuevo sistema
8.3.- Documento del estado actual del
sistema legado Requerimientos funcionales
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
8.4.- Documento de
especificación de
requerimientos
Requerimientos no Funcionales
Análisis de SOA
Diseño de SOA
Tabla 8. Establecer del diseño del sistema objetivo.
Plan de migración
Esta actividad se agregó para llevar un control de
los objetivos que se plantearon para el nuevo
sistema y así optimizar los recursos que se
utilizaran para la migración. Para lograr esto es
necesario tener los documentos obtenidos de la
actividad anterior y así obtener el plan de
migración (ver Tabla 9).
9.- Plan de migración
Entradas Salidas
9.1.- Servicios candidatos Plan de Migración
9.2.- Que parte del sistema
legado será utilizado para el sistema migrado
Estructura de división de
trabajo
9.3.- Arquitectura del nuevo
sistema
Diagrama de identificación
de puntos de control
9.4.- Requerimientos funcionales
Asignación de responsabilidades
9.5.- Requerimientos no
Funcionales
Diagrama de Hitos
9.6.- Análisis de SOA Grafica de Gantt
9.7.- Diseño de SOA Plan de pruebas (en base a
los requerimientos
funcionales y no funcionales)
Tabla 9. Plan de Migración
Migración del sistema
Gracias al plan de migración y a la información
recabada durante las actividades anteriores se
desarrollaran los servicios del nuevo sistema con el
objetivo de obtener el nuevo sistema con una
arquitectura orientada a servicios (ver Tabla 10).
10.- Migración del sistema
Entradas Salidas
10.1.- Plan de migración Servicios desarrollados en base
a los requerimientos
Tabla 10. Migración del sistema
Pruebas
Guiados por el plan de pruebas se le realizaran las
pruebas necesarias a los servicios desarrollados
esto con el objetivo de que sean confiables, no
presenten errores y que puedan ser utilizados por la
organización que está realizando la migración del
sistema y socios (ver Tabla 11).
11.- Pruebas
Entradas Salidas
11.1.- Servicios Servicio (que cumple con los
requerimientos y no presente errores… y pueda ser utilizado
por en los ambientes dentro y
fuera de la organización), Retroalimentación
11.2.- Plan de pruebas
Tabla 11. Pruebas
Sistema migrado a SOA
Cuando los servicios son aceptados después de las
pruebas cumpliendo con los requerimientos y no
presenten errores el sistema migrado a SOA será
implantado para que la organización y socios
comiencen a utilizarlo y así obtener el producto
final de la utilización del método de migración (ver
Tabla 12).
12.- Sistema migrado a SOA
Entradas Salidas
12.- Servicio Sistema migrado a SOA
Tabla 12. Sistema migrado a SOA
A continuación se presenta un pequeño caso de
estudio donde se demuestra de manera sencilla y
resumida la utilización del método de migración
propuesto.
El sistema de una empresa de productos químicos
ha sido utilizado por al menos seis años por los
cuales la organización y sus procesos del negocio
han cambiado de solo ser una empresa dedicada al
solo almacenaje de productos químicos agrego
también la fabricación de otros.
Desafortunadamente el sistema ha perdido aquella
ventaja que se obtuvo en un principio cuando dicho
sistema fue desarrollado.
En base esto la empresa se decidió a migrar su
sistema a un nuevo sistema el cual sea más fácil de
mantener, capaz de evolucionar como lo hace la
empresa y pueda ser útil tanto a la empresa, sus
socios y clientes.
Comprensión del dominio: se comenzó realizando
entrevistas a los stakeholders en cual se comienza a
crear la lista de estos para tener conocimiento con
quienes se podrá dirigir durante la migración (tabla
13).
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Identificador Nombre Puesto Procesos del
negocio en
el que
participa
US1 Juan Pérez Gerente
US2 Raúl
Hernández
Químico
US3 Pamela
Martínez
Ventas
Tabla 13. Lista de interesados
Después de tener la lista de interesados se
entrevistaron a estos para conocer qué es lo que
esperan de la migración del sistema y se obtuvo la
siguiente tabla (tabla 14):
Nombre de la organización: Químicos
Nombre del proyecto: Migración SysQuim
Identificador Nombre del
objetivo
Descripción
OM1 Actualización Que los equipos de cómputo se
actualicen y que
más empleados puedan hacer uso
del sistema.
OM2 Interacción Que los socios y
clientes interactúen directamente con el
sistema para
agilizar el trabajo.
Tabla 14. Objetivos de la migración
Después de determinar los objetivos se realizó una
lista con todos documentos que proporcionan
información. (ver tabla 15)
Identificador Nombre de
quien
proporciona
y utiliza la
entidad
Entidad Datos Datos
útiles
al
sistema
EI1 US3 US1 Orden
de
venta
Nombre
del cte.,
Cantidad,
Monto de
la venta,
fecha de
entrega
Todos
EI2 US3 US2 Orden
de
Formula,
cantidad,
Todos
pedido fecha de
entrega
Tabla 15. Documentos con información útil para el sistema.
Se creó una relación de los sistemas que existen
dentro de la organización y de la interacción que
existen entre estos (ver tabla 16).
ID Nom
bre
del
siste
ma
Funciona
lidad
Departame
nto o
personas
que hacen
uso del
sistema
Sistem
a con
el que
interact
úa
Informaci
ón que
interactúa
entre los
sistemas
SYS
1
Siste
ma
Quí
mico
Registrar
venta
US3 N/A N/A
SYS
2
Siste
ma
Quí
mico
inventari
o local
US2 N/A N/A
SYS
3
Siste
ma
Quí
mico
reportes
de venta
US1 N/A N/A
Tabla 16. Sistemas en la organización.
La siguiente actividad que se realizo fue el llevar
un control de los procesos del negocio de la
organización principalmente de aquellos procesos
que interactúan con el sistema legado. (ver tabla
17)
ID Nombre del
proceso del
negocio
Descripción Objetivo
del
proceso
del
negocio
PN1 Venta Un cliente llega a la
empresa o a través de
un representante de
ventas realiza un
pedido de un químico o
de una formula
específica. Después de
recibir el pedido se
capturan los datos en el
sistema se acepta por el
Realizar la
venta de
un
producto
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
gerente y el encargado
del inventario verifica
que se tengan los
productos adecuados
para surtir el pedido si
es así se realiza el
pedido dando de baja
del inventario lo
utilizado y cuando se
encuentra listo se da
aviso al área de ventas
para que se realice la
entrega.
Tabla 17. Descripción de procesos del negocio.
La última tarea que se realizó durante la primera
actividad del método fue el completar la lista de
interesados en el sistema indicando en que procesos
del negocio participa cada stakeholder (ver tabla
18).
Identificador Nombre Puesto Procesos del
negocio en
el que
participa
US1 Juan Pérez Gerente PN1
US2 Raúl
Hernández
Químico PN1
US3 Pamela
Martínez
Ventas PN1
Tabla 18. Lista de interesados.
Establecer el estado actual del sistema legado: se
comenzó recopilando la documentación referente al
sistema en donde solo se consiguió lo siguiente (ver
tabla 19).
ID Nombre de
documento
Descripción
DC1 Manual de
usuario
Un pequeño manual el cual indica
brevemente el funcionamiento del
sistema.
Tabla 19. Documentación existente.
Al no tener documentación del sistema se tuvo que
realizar una reconstrucción arquitectónica para
obtener la arquitectura actual del sistema la cual
quedo de la siguiente manera (ver arquitectura 1).
Inventario Local
Registrar Venta
Reportes de Venta
Archivo de datos
SysQuim
Arquitectura 1. Sistema legado.
Después de esto se realizó una serie de entrevistas
con los usuarios del sistema donde se obtuvo lo
siguiente (ver tabla 20). ID Identificado
r del
interesado
(usuario del
sistema
legado)
Nombr
e error
Descripción del
error
Secuenci
a de
pasos
que
provoca
el error
ERR
1
US3 Perdida
de
datos
El sistema se
cierra
inesperadament
e y se pierden
datos
importantes de
la venta.
No
recuerda
la
secuenci
a
Tabla 20. Errores del sistema
Se determinó que no se ha dejado de utilizar nada
del sistema así que la tabla 21 no fue utilizada para
este caso.
Identificador Nombre de la
funcionalidad
desechada
Descripción
de la
funcionalidad
Razón del
desuso de la
funcionalidad
Tabla 21. Funcionalidades desechadas.
Debido a que no se cuenta con la documentación de
la forma en que se encuentran almacenados los
datos del sistema se realizó un listado a partir de los
datos de los reportes y de las pantallas del sistema
depurándolos (ver tabla 22)
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
ID
Nombre
funcionalidad o
posible tabla
Datos Validación
(Tipo y tamaño)
DT1 Clientes Nombre Alfabético
DT2 Clientes RFC Alfanumérico
Tabla 22. Ubicación y estructura de los datos.
La siguiente tarea que se realizo fue el hacer un
mapeo de cuales funcionalidades del sistema
cubren los procesos del negocio y en qué cantidad
lo cubre.
Identificador proceso del
negocio
Identificador
Funcionalidad
del sistema
PN1
SYS1 Parcial
Tabla 23. Relación proceso del negocio-funcionalidad
Se consideró que lo cubre parcialmente debido a
que solo registra la venta pero no genera facturas o
la compra se puede realizar desde diferentes
ubicaciones.
Nuevos requerimiento: se realizó la lista de los
posibles nuevos requerimientos tanto de los
usuarios del sistema legado como los nuevos
usuarios que en este caso serán los proveedores y
clientes.
Poder hacer pedidos vía internet
Capturar formulas y que verifique en el
inventario si existe lo necesario
Que los pedidos puedan ser realizado por
cualquier cliente sin importar su ubicación
Cuan se realice una formula en la cual se
necesite más materia prima se haga el
pedido automático para completar la
venta.
Identificación de servicios y análisis de riesgo: se
descompuso el proceso del negocio PN1 en partes
más granulares para determinar que partes de dicho
proceso pueden convertirse en servicios y en base
en esto y en lo recopilado en la actividad anterior se
llegó a que el único servicio que será necesario
para la migración es el encargado de las ventas. El
cual podrá ser descubierto por cualquier cliente que
necesite de manera rápida y eficaz realizar pedidos
de un químico o una formula específica.
Además se determinó que las funcionalidades del
sistema y los nuevos requerimientos que no son
necesarios llevar a cabo como servicio se migrarán
a algún lenguaje que pueda interactuar más fácil
con dicho servicio, como podría ser cualquiera que
sea orientado a objetos.
En cuanto al análisis de riesgos se consideró que
para la parte de servicios no presenta riesgo alguno
ya que actualmente no existe alguna función a la
que reemplace solo se deberá tomar en cuenta que
es necesario extraer la información recabada
durante los años del trabajo del sistema.
Especificación de requerimientos: para esta
actividad se realizó un documento basado en el
estándar 830-1998 de la IEEE, en donde se
tomaron en cuenta los requerimientos de servicio
como del sistema orientado a objetos.
Validación de requerimientos: del documento
anterior se validó que los requerimientos se
encuentren correctamente definidos y que estos
puedan llegar a realizarse.
Priorización de requerimientos: al hacer un
análisis del documento anterior que contiene los
requerimientos ya validados se llegó a la
conclusión que se desarrollaría a la par el sistema
orientado a objetos junto al servicio.
Establecer el diseño del sistema objetivo: el
servicio candidato que se identifico es el encargado
de pedidos de químicos y ventas. Se determinó que
debido a que el sistema legado presenta algunos
errores y no se cuenta con el código fuente solo se
utilizará la información almacenada en el sistema,
la arquitectura del nuevo sistema es la siguiente
(ver arquitectura 2):
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Reportes de Venta
Base de datos
SysQuim Servicio Pedido
Servicio Inventario
Sistema de Producción
Arquitectura 2. Nuevo sistema
Los requerimientos funcionales y no funcionales se
encuentran separados en el documento de
especificación de requerimientos.
Para la realización del análisis se comenzó con la
definición de los procesos del negocio los cuales ya
se encuentran definidos en la tabla 17. Después fue
necesario hacer un análisis de que partes de la
empresa será afectados lo cual se realizó en la
actividad de identificación de servicios y análisis
de riesgo.
Cuando se obtuvo la información del análisis se
comenzó con el modelado de servicios donde se
realizó la descomposición del servicio.
Llenado de pedido de manera electrónica
El documento es enviado al gerente
electrónicamente
Se verifica automáticamente que se tenga
la materia prima necesaria
Se envía pedido al área de producción para
que se surta
Automáticamente se da de baja el
producto del inventario
Se llena informe de producción
Se envía informe de manera electrónica al
área de ventas y al cliente que realizo el
pedido
Después se eliminaron aquellas actividades que no
son parte del servicio.
Llenado de pedido de manera electrónica
(no es parte del servicio debido que es una
tarea manual)
Se llena informe de producción (no es
parte del servicio debido que es una tarea
manual)
Ya con las actividades identificadas y separadas se
definieron los servicios candidatos del negocio el
cual quedo de la siguiente manera (ver imagen 2).
Imagen 2. Servicio candidato del negocio (notación tomada de
[17] ).
Cuando se realizó lo anterior se notó que el servicio
contenía actividades que no pertenecían a este, así
que esto nos llevó a la siguiente actividad que es la
refinación del servicio y aplicación de los
principios de SOA. Debido a esto se separó las
actividades de verificación de materia prima y baja
de inventario para la creación de un nuevo servicio
quedando de la siguiente manera (ver imagen 3 y
4).
Imagen 3. Servicio Pedidos (notación tomada de [17] ).
Imagen 4. Servicio Inventario (notación tomada de [17] ).
-Enviar orden a gerencia -verificación de materia prima
-Enviar orden a producción
-baja de inventario
-informe de pedido realizado
Servicio Pedidos
-Verificación de materia
prima. -Baja de Inventario
Servicio Inventario
-Enviar orden a
gerencia -Enviar orden a
producción
-informe de pedido
realizado
Servicio Pedidos
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Después de realizar la separación de servicios se
realizó la composición de dichos servicios
quedando de la siguiente manera (ver imagen 5):
Servicio Inventario
Servicio Pedidos
Capa de Servicio
Capa de aplicación de servicio
Imagen 5. Composición de Servicio candidato.
Con esto se finalizó el análisis orientado a servicios
y se comenzó con el diseño obteniendo los
siguientes resultados.
Se comenzó comprobando si es que ya se
encuentran desarrollados dichos servicios, lo cual,
no se encontró nada que pudiera ayudar. Después
se realizó la definición del esquema:
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace= "http://www.quimi.com/xls/orden/schema/pedidos/">
<xsd:element name="FormulaPedidoRequestType">
<xsd:complexType> <xsd:sequence>
<xsd:element name="IDQ" type="xsd:integer"/>
</xsd:sequence> </xsd:complexType>
</xsd:element>
Ya con el esquema definido se realizó el archivo
WSDL con las operaciones candidatas.
<message name="updatePedidoResponseMessage">
<part name="ResponseParameter"
element="hr: FormulaPedidoRequestType "/>
</message>
<portType name="PedidosInterface"> <operation name="GetCantidaQuimico">
<input message= "tns:getCantidaQuimicoRequestMessage"/>
<output message=
"tns:getCantidaQuimicoResponseMessage"/> </operation>
Se creó el metadato del servicio con la finalidad de
que sea más sencillo de encontrarlo para su
reusabilidad.
<portType name="PedidosInterface"> <documentation>
GetCantidaQuimico usa el IDQ para saber cuánto
químico está disponible como materia prima y así determinar si es posible el surtir un pedido en
específico.
</documentation> <operation name=" GetCantidaQuimico t">
<input message=
"tns:getCantidaQuimico RequestMessage"/> <output message=
"tns:getCantidaQuimico ResponseMessage"/> </operation>
Con esto se realizó una versión abstracta del
servicio la cual más adelante se le agrego toda la
funcionalidad necesaria para poder implementarla
en la empresa pero antes de estos se realizó el plan
de migración. Se comenzó realizando el diagrama
de estructura de división de trabajo (ver imagen 6).
Migración
Creación BD
Obtener datos del sistema legado
Creación del sistema Orientado a
Objetos
Creación de Servicios
Pruebas
Plan de pruebas
Implantación
Imagen 6. Estructura de división de trabajo.
En base a lo anterior se definió un diagrama de
Gantt el cual mostró una calendarización la cual
ayudo a realizar las tareas a tiempo (ver grafica de
Gantt tabla 24).
Tareas Semana
1
Semana
2
Semana
3
Semana
4
Creación de
la base de
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
datos
Creación
Sys. O.O.
Creación del servicio
Pruebas
Implantación
Tabla 24. Grafica de Gantt.
Gracias al diagrama de puntos de control se
identificó todas aquellas cosas que pueden salir mal
durante el desarrollo de las aplicaciones (ver tabla
25).
Etapa ¿Qué puede
salir mal? ¿Cuándo y cómo me voy
a dar cuenta?
¿Qué voy hacer para
corregir el
problema?
Creación del
servicio
Falta de
conocimientos
en el desarrollo de
servicios
Cuando se
comience el
desarrollo del servicio
Tener gente
capacitada
para desarrollar
servicios
Implantación Falta de
hardware dentro de la
organización
para la utilización del
servicio.
Cuando se
comience la implantación
Buscar la
mejor alternativa
existente
que concuerde
con las
necesidades
de la
empresa
Tabla 25. Diagrama puntos de control.
Después de obtener esta información se realizó la
asignación de responsabilidades ya que con esto se
pudo tener una mejor idea de quién era el indicado
para realizar la tarea (ver tabla 26).
Personal Actividad
Daniel Santa Cruz Migración servicios
Erika Pimentel Migración O.O.
Tabla 26. Asignación de responsabilidades.
El diagrama de hitos es otra actividad que se
realizó durante la planeación pero este se completó
al finalizar la migración (ver tabla 27).
Hecho Fecha planeada Fecha Real
Programación de
servicio
12/01/2008 20/01/2008
Prueba de servicio 15/02/2008 22/02/2008
Tabla 27. Diagrama de Hitos.
La última parte de la planeación es el realizar el
plan de pruebas que se realizará a los servicios
donde por lo menos se le realizaron la prueba de
carga para determinar el rendimiento del sistema.
Después de tener lista la planeación se comenzó la
migración donde se siguió el plan de migración y
se utilizaron herramientas como Eclipse, TomCat,
Axis y java para obtener como resultado la
programación de los servicios.
Las pruebas fue la siguiente actividad que se
realizó la cual tomo como base el plan de prueba
realizado en las actividades anteriores. Lo primero
que se realizo fue el realizar las pruebas de carga
buscando que los servicios tengan el rendimiento
normal bajo condiciones de carga cercano a lo
normal. El segundo tipo de prueba fue las de
volumen las cuales determinan si el servicio puede
soportar grandes cantidades de datos durante
periodos prolongados.
Ya que las pruebas anteriores solo miden el
rendimiento del servicio también fue necesario
hacer pruebas unitarias, integración y de sistema
con la finalidad de que se cumpla con lo
especificado dentro los requerimientos definidos.
Este proceso se volvió un proceso iterativo debido
a que se encontraron varios errores de
programación los cuales no cumplían con lo
esperado dentro de los requerimientos.
La última actividad que se realizó para lograr la
migración fue la implantación del sistema lo cual
fue el dejar los servicios para ser descubierto por
los consumidores de este. También se realizó un
curso de capacitación para los principales clientes
de la empresa en donde se le explico el cómo
pueden utilizar los servicios desarrollados y así
obtener los beneficios de estos.
Con esto concluye el caso práctico de la utilización
del método de migración propuesto en donde se
siguió cada una de sus actividades y tareas
específicas logrando con esto el objetivo que era el
utilizar toda la experiencia del sistema legado para
desarrolla un nuevo sistema basado en una
arquitectura orientada a servicios.
Contribuciones y limitaciones
En la tabla 28 se muestran las contribuciones y
limitaciones de los principales trabajados
relacionados, a partir de esta tabla se consideraron
aquellas contribuciones que mejorarían al método
propuesto y además las limitaciones ayudaron a
reforzarlo y mejorarlo.
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Nombre Autores Contribucion
es
Limitaciones
Migration of
legacy
software to
service
oriented
architecture
Edward
Stehle,
Brian Piles,
Jonathan
Max-Sohmer,
Kevin
Lynch [18]
Muestra
algunos de los
métodos utilizados para
la migración
de software legado a una
arquitectura
orientada a servicios
No define
algún proceso
para lograr la migración y
no menciona
la integración de nuevos
requerimiento
s
Integration
of legacy
system in
software
architecture
Maria
Wahid
Chowdhury,
Muhammad Zafar
Iqbal [19]
Muestra
algunas
estrategias para integrar
el software legado a
algunas
arquitecturas
No define
algún proceso
para lograr la migración y
no menciona la integración
de nuevos
requerimientos
Supporting
Migration to
services
using
software
architecture
reconstructio
n
Liam
O´Brien,
Dennis Smith,
Grace
Lewis [11]
Muestran
como la
reconstrucción de la
arquitectura
puede ser usada para
soportar la
modernización de los
sistemas
No logra un
sistema
nuevo, no define un
proceso de
migración, no utiliza un
plan de
migración
Redesigning
legacy
systems into
the object-
oriented
paradigm
W. Eric
Wong, Jenny Li.
[20]
Contribuye
con un método semiautomátic
o asistido por
computadora, el cual abstrae
a diseño
orientado a objetos del
código fuente
procedural
no menciona
la integración de nuevos
requerimiento
s, no logra un sistema
arquitectura
orientado a servicios
Legacy
information
system
migration: a
brief review
of problems,
solutions and
research
issues
Jesús Bisbal,
Deirdre
Lawless, Bing Wu,
Jane
Grimson [8]
Hacen una revisión de
algunas
estrategias de migración
además de
algunos de sus problemas así
como también
dos nuevos
métodos de
migración
no menciona la integración
de nuevos
requerimientos, no logra un
sistema
arquitectura orientado a
servicios
Tabla 28. Contribuciones y limitaciones.
Conclusión
El método propuesto aporta una serie de
actividades y tareas específicas para la migración
de sistemas legados hacia tecnologías vigentes
como es la arquitectura orientada a servicios
intentando sacar provecho de las ventajas que esto
nos brinda. Para la consolidación de la propuesta se
está planteando el realizar un caso de estudio el
cual sea en una entidad real la cual tenga la
necesidad de migrar sus sistemas y con esto afinar
aquellas actividades dentro del método para que sea
más sencilla su aplicación y se saque provecho de
toda la experiencia de la utilización del sistema
legado.
Bibliografía
[1] Dayani-Fard, Homy, Müller, Hausi and Mylopoulos, John., "Legacy Software Systems: Issues, Progress, and Challenges." CASCON '98 Workshop Report. 1999.
[2] Bennett, Keith and Rajlich, Vaclav., Software Maintenance and Evolution: a Roadmap. Future of Sofware Engineering Limerick Ireland. s.l. : ACM, 2000.
[3] Engineers, The Institute of Electrical and Electronics., IEEE Std 1219-1998: IEEE Standard for Software Maintenance. Nueva York : The Institute of Electrical and Electronics Engineers, 1998. ISBN 0-7381-0336-5.
[4] MacKenzie, Matthew C., et al., Reference Model for Service Oriented Architecture 1.0. s.l. : OASIS Standard, 12 October 2006.
[5] Sanders , Derek T., Hamilton, J.A. and MacDonald, Richard A. ., Supporting A Service-Oriented Architecture. s.l. : SpringSim, 2008.
[6] Pressman, Ph.D. Roger S., Ingeniería de Software: Un Enfoque Práctico (Sexta Edición). s.l. : McGraw Hill, 2007.
[7] Bisbal, Jesús, et al., "Legacy Information Systems: Issues and Directions." IEEE Software, September/ October 1999.
[8] Bisbal, Jesús, et al., Legacy Information System Migration: A Brief Review of Problems, Solutions and Research Issues. Trinity College, Dublin, Ireland : s.n., 1999.
[9] Stehle, Edward, et al., Migration of Legacy Software to Service Oriented Architecture. Drexel University. Philadelphia : s.n.
[10] Fowler, Martin, et al., "Refactoring, Improving the design of the existing code." [book auth.] Martin Fowler. Refactoring, Improving the design of the existing code. s.l. : Addison-Wesley, pp. 17-18.
[11] O'Brien, Liam, Smith, Dennis and Lewis, Grace., Supporting Migration to Services using Software Architecture Reconstruction. Carnegie Mellon University. Pittsburgh, PA : Software Engineering Institute.
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
[12] Sommerville, Ian., Ingenieria de Software, Sexta Edición. s.l. : Addison Wesley, 2002.
[13] Microsoft., La Arquitectura Orientada a Servicios (SOA) de Microsoft aplicada al mundo real. s.l. : Whitepaper:Microsoft, 2006.
[14] Castro-Leon, Enrique, He, Jackson and Chang, Mark., Scaling Down SOA to Small Businesses. Intel Corporation. s.l. : IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07), 2007.
[15] Komoda, Norihisa., Service Oriented Architecture (SOA) in Industrial Systems. Osaka University. s.l. : IEEE, 2006.
[16] Hewitt, Eben., Java SOA Cookbook. Estados Unidos : O’Reilly Media, Inc, 2009. 978-0-596-52072-4.
[17] Pressman, Roger S., Ingeniería del software, un enfoque práctico. s.l. : McGraw Hill, 2005.
[18] Stehle, Edward, et al., Migration of Legacy Software to
Service Oriented Architecture. Drexel University. Philadelphia :
s.n.
[19] Wahid Chowdhury, Maria and Zafar Iqbal, Muhammad.,
Integration of legacy system in software architecture.
California, USA. : 12th ACM SIGSOFT Symposium on the
Foundations of Software Engineering Newport Beach, 2004.
[20]Wong, W. Eric and Li, Jenny., Redesigning legacy systems
into the object-oriented paradigm. s.l. : International Journal of
Software Engineering and Knowledge Engineering Vol. 14, No. 3
(2004) 255-276, 2004.
Currículo corto de los autores
Luis Antonio Gutiérrez Romo, Licenciado en
informática egresado de la Universidad Autónoma
de Aguascalientes en el año 2008. Actualmente
cursando el cuarto semestre de la Maestría en
Ciencias Exactas, Sistemas y de la Información en
el área de Ingeniería de Software.
Juan Muñoz López, Doctor en Ciencias de la
Computación por la Universidad Autónoma de
Aguascalientes; Profesor de dedicación parcial en
la misma institución y Director de Planeación y
normatividad Informática en el Instituto Nacional
de Estadística, Geografía e Informática (INEGI).
Dra. Laura Garza González: Lic. en Sistemas
Computacionales Administrativos (ITESM),
Maestra en Administración (UAA), Doctora en
Administración (UAA). PTC asignado a la
Secretaría de Docencia del Centro de Ciencias
Básicas, UAA, en la línea de Adopción de
Tecnología.
CIINDET 2010 VIII Congreso Internacional sobre Innovación y Desarrollo Tecnológico,
24 al 26 de noviembre de 2010, Cuernavaca Morelos, México.
Recommended