Estándares de Programación

ESTP-T

ARQUEOLOGIA DE SOFTWARE
Una situación en la que muchas veces nos vemos inmersos es que así como la gran mayoría de
sistemas que cambian de manos para su soporte y mantenimiento, éste tiene una escasa y pobre
documentación, los desarrolladores originales ya no están y por supuesto, hay mucho más que
hacer con la plataforma como corregir problemas de desempeño o ir acomodando nuevos
requerimientos de nuestros stakeholders. Muchos se las ven negras debido a esto, ya que ocurre
el típico “aquí está el código y cómo instalarlo; lo demás lo aprenderás sobre la marcha”. Sin
embargo, para ahorrarnos sangre, sudor y lágrimas estaremos echando mano de una disciplina
relativamente madura de la ingeniería de software que nos puede ayudar a resolver este tipo de
situaciones: la arqueología de software.

La arqueología de software es el estudio de pobremente documentadas implementaciones de

software legado, formando parte del mantenimiento de software. Nombrada por analogía
con la arqueología convencional, es una metodología usada para realizar ingeniería inversa y
aplicación de herramientas y procesos sobre piezas de software existente para extraer y
entender su estructura y diseño. Todo ello para comprender exactamente qué se tiene en
términos del código sobre el que se va a trabajar y encontrar patrones de diseño y desarrollo
que puedan ser cosechados para desarrollos futuros.

En términos específicos, se trata de “explorar” el código para encontrar la arquitectura original, el

diseño y las áreas de oportunidad que debemos resolver al tomar las riendas del sistema. La
ventaja de este enfoque es que se debe seguir un proceso metódico para obtener la información
que necesitamos; la primera vez que se le definió formalmente fue en la Conferencia OOPSLA
(Object-Oriented Programming, Systems, Languages & Applications – Sistemas, Lenguajes y
Aplicaciones Orientados a Objetos) celebrada durante el 2001 en Tampa Bay, Florida. Ahí se
realizó un taller enfocado a “…permitir a los programadores hacerse cargo rápidamente de
sistemas de software de gran tamaño que nunca antes habían visto”.

Algunos años después, Mike Rozlog, gerente de producto en soluciones Delphi para Embarcadero
Technologies refinó el término, publicando un sencillo proceso compuesto por seis pasos,
enumerados a continuación:

1. Visualización. Obtener una representación visual del diseño de la aplicación. Es decir, a

través de herramientas de ingeniería inversa debemos obtener un diagrama de clases para
identificar dependencias entre objetos. Posteriormente debemos realizar esta misma
conversión a los métodos localizados en la aplicación, para obtener un diagrama de
secuencia que nos permita conocer el proceso de ejecución. Es necesario tener en cuenta
que a Rozlog le faltó algo fundamental para realizar nuestra labor: los diagramas de
arquitectura y despliegue. Esto porque en el mundo moderno de las arquitecturas de N-
capas, distribuidas u orientadas a servicios, no todo se encuentra en el código ya que
pueden existir stored procedures o llamadas a servicios web de un tercero para recuperar

1
 Estándares de Programación
ESTP-T

o procesar información; de la misma manera podemos detectar dependencias que no

necesariamente pueden verse reflejadas en un diagrama estático. Así, tendremos los
siguientes artefactos después del primer paso:

• Diagrama de arquitectura tecnológica (físico, lógico, de red, de aplicaciones)

• Diagrama de clases
• Diagramas de secuencia

2. Violaciones de diseño. Una vez que se ha obtenido la visualización del sistema y ésta ha
sido revisada, deberemos hacer una inspección del diseño. Esto se realiza mediante
métricas de calidad de software que incluyan cobertura, complejidad ciclomática o
violación del principio del menor conocimiento. Los artefactos resultantes son:
• Matriz de dependencias
• Análisis de cobertura
• Tabla de métricas de calidad de software

Esto es para detectar áreas de oportunidad que deberán ser corregidas por un
programador de buen nivel.

3. Violaciones de estilo. Como parte complementaria a la revisión de diseño, es necesario

encontrar problemas de estilo como valores hardcodeados o el uso indiscriminado de
instrucciones System.out.println. La detección temprana de estos detalles ayudará a iniciar
la limpieza del código y en algunos casos, a mejorar su desempeño. En la actualidad una
gran cantidad de herramientas pueden realizar este tipo de revisión, como RefactorIT o el
humilde checkstyle. El principal artefacto resultante de esta tarea es:
• Listado de violaciones de estilo

4. Lógica de negocio. Ya que hemos comprobado si la llanta está desinflada o le falta

aceite al motor, es necesario manejar el automóvil en carretera para ver cómo se
comporta: comprobando el flujo de la aplicación podremos ver si existen problemas en
tiempo de ejecución. Una manera de saberlo es mediante la automatización de pruebas
unitarias en conjunto con pruebas de cobertura que nos dejen ver la interacción entre los
diferentes componentes arquitectónicos. Será indispensable generar toda una suite de
pruebas basada en el comportamiento de la plataforma. Por otro lado, para correr el
sistema es necesario instalar un ambiente de ejecución lo más parecido al ambiente
productivo, pues así serán identificadas las últimas dependencias del sistema como
variables de entorno o archivos de internacionalización:
• Ambiente de ejecución de pruebas integrales
• Suite de pruebas unitarias
• Resultados de pruebas de cobertura

2
 Estándares de Programación
ESTP-T

5. Desempeño. Es de tener en cuenta que más del 85 por ciento de las compañías
presenta problemas de desempeño en sus aplicaciones. Por ello, es necesario incluir
pruebas de este tipo durante el proceso que estamos llevando a cabo. El Wait-Based-
Tuning es una buena metodología para realizarlo y aunque Rozlog sólo menciona que el
5% del código será el que nos esté poniendo el pie, generalmente hay tres lugares donde
hay que buscar por áreas de oportunidad: la base de datos (índices, columnas, tablespace),
la máquina virtual de java en caso sea utilizada (garbage collector, permspace, memoria
asignada) y llamadas a fuentes de datos (servicios web, DAOs y EJBs). El documento
resultante de nuestra labor:

• Análisis de desempeño

6. Documentación. Rozlog es poco específico al respecto, indicando que sería genial si

todo este trabajo fuera capturado para uso futuro. Sin embargo, no indica QUÉ
documentos deberían incluirse. En la vida real, son necesarios los siguientes documentos
que conforman el principal entregable después de nuestra “excavación”:

• Documento de arquitectura tecnológica

• Documento de definición de base de datos
• Documento de modelo de diseño
• Lista de acciones a tomar (incluyendo correcciones y tareas no funcionales).

Al final del proceso el equipo debería tener una visión general de qué componentes
integran la plataforma y cómo deben ser desplegados y configurados para funcionar
correctamente. Adicionalmente, se habrán localizado los principales puntos de falla que
impactan el funcionamiento y rendimiento del sistema; Rozlog los llama las “secciones
tenebrosas del código”. Finalmente se tendrá una buena lista de Santa Claus o backlog con
los siguientes pasos a seguir, que podrán ser implementados como parte del
mantenimiento de la aplicación o como un proyecto aparte.

Algunos autores nos animan a no sólo estudiar la arquitectura del sistema, sino también a explorar
sus inicios y razón de ser, incluyendo la historia del repositorio de versiones o contactar a los
participantes del desarrollo original para entender cuál era la intención inicial de la plataforma y
cómo se llegó a la versión que estamos recibiendo. Aunque esto es poco común, debemos
intentarlo pues facilita descubrir situaciones como que “este modulo fue pensado como una
demo, no para un ambiente productivo” y tomar cartas en el asunto.

Así, con información recopilada a través de medios formales e informales como herramientas de
auditoría o realizar una reunión con el ex-desarrollador y jefe, encontraremos la manera de salir
del laberinto al descubrir cuatro propiedades fundamentales del sistema heredado: estructura,
comportamiento, contexto y propósito; mejorando nuestras posibilidades de llevar correctamente
nuestra misión de soporte y mantenimiento de un sistema complejo.

3
 Estándares de Programación
ESTP-T

SISTEMAS LEGADOS
Los recursos tecnológicos que soportan los procesos de negocio de una organización deben
ofrecer una infraestructura adecuada para el desarrollo y la evolución del software y deben
proveer la seguridad de que su continuidad operativa permanecerá en el tiempo. La necesidad de
integración de servicios implementados sobre plataformas disimiles, y la percepción de ciertos
riesgos en la obtención de soporte suficiente y en la certeza de continuidad de las operaciones
soportadas por sistemas o plataformas legadas, llevan a la consideración de evolucionar,
mantener o migrar dichos sistemas.

El tiempo de vida de los sistemas de software es bastante variable, muchos sistemas han sido
creados desde hace más de 15 años y son aún sistemas de misión crítica. Esto es, la continuidad
operativa de las empresas que los operan depende de los servicios provistos por el sistema y una
falla en este puede traer consecuencias negativas sobre la operación diaria del negocio. Las
decisiones que se toman sobre este tipo de sistemas son de orden estratégico debido a su
importancia. Sistemas con estas características son los comúnmente denominados sistemas
legados.

Diversos factores internos y externos, económicos, de mercado, legales, administrativos o políticas

de organización, exigen cambios continuos en el negocio. Estos cambios generan o causan
modificaciones en los requerimientos de software que recaen sobre los sistemas tecnológicos,
haciendo necesaria la introducción de cambios para alinearse a los nuevos requerimientos del
negocio.

"Entre mayor sea el numero de cambios en un sistema, menor se hace su calidad"

Un número elevado de cambios en un sistema tiende a desestabilizar su estructura y hacer que los
cambios subsiguientes sean más difíciles de incorporar. Entre mayor sea el numero de cambios en
el sistema (cambios no enfocados a mejorar la estructura del sistema), menor se hace la calidad
del sistema.

El mantenimiento de los sistemas legados es usualmente complejo y presenta una curva de

aprendizaje bastante empinada debido principalmente a:

• Las diversas partes del sistema se encuentran desarrolladas en lenguajes de programación

desactualizados. Contar con recursos que dominen estos lenguajes no es sencillo por lo
que el costo de mantenimiento del sistema es elevado.
• La documentación de los sistemas es escasa e insuficiente.
• El número de años de mantenimiento continuo sobre el sistema hace que la estructura del
software se incremente sustancialmente y sea propensa a la existencia de código muerto
(que nunca se ejecuta) dentro de algunos programas.

4
 Estándares de Programación
ESTP-T

• Existen limitaciones propias de las plataformas y sistemas legados, como limitantes en

tamaño de los nombres de archivo, limitantes en el tamaño disponible para carga de
programas en memoria, limitantes en la longitud de las variables, etc.
• Existencia de duplicidad de datos, datos desactualizados y datos incompletos.
• La base de soporte disponible para un sistema legado es limitada, y en ocasiones
requerida tanto para aspectos técnicos, como funcionales y de proceso. La mayor parte
del conocimiento del sistema se encuentra concentrado en pocas personas, y la
disponibilidad de estos recursos puede no ser inmediata o no responder con la agilidad
que se requiere.

Cuando se trata de modernizar un sistema de misión critica, se enfrenta un dilema propio a la

evolución de un sistema legado: Continuar utilizando el sistema e introduciendo cambios en él,
implica que los costos de mantenimiento se vean gradualmente incrementados y la complejidad
del sistema continúe en ascenso; Decidir reemplazar el sistema por uno nuevo puede ser muy
costoso y el soporte de los procesos de negocio puede resultar no ser tan eficiente como el
ofrecido por el sistema legado.

La evolución del sistema legado hacia otro sistema más moderno involucra varios riesgos que
provienen de razones como:

• Ausencia de una especificación completa del sistema. Por lo cual no existe una forma
directa de especificar un sistema que sea funcionalmente equivalente al sistema actual.
• Los procesos de negocio soportados por el sistema se han desarrollado en base a las
características propias del sistema, y si éste es reemplazado, los procesos también se
verían modificados.
• La mayor parte de las reglas de negocio se encuentran inmersas en el código de las
aplicaciones dentro del sistema y no se encuentran documentadas en otra parte.
• El desarrollo de nuevos sistemas de software implica en si mismo riesgos que son difíciles
de controlar y pueden llevar a demoras en la entrega del nuevo sistema.

Existen cuatro estrategias para evolucionar un sistema legado:

• Eliminar completamente el sistema. Esta opción debe considerarse cuando el sistema no

está haciendo ninguna contribución en los procesos de negocio, caso que sucede cuando
los procesos de negocio han cambiado y se hacen independientes de los procesos
soportados por el sistema.

• Tolerar y continuar con el mantenimiento del sistema. Esta estrategia es aplicable

cuando el sistema es aún requerido, permanece estable, y no existen muchos
requerimientos de cambio sobre el sistema.

5
 Estándares de Programación
ESTP-T

• Transformar o integrar el sistema para mejorarlo. Esta opción debería escogerse cuando
la calidad del sistema se ha visto degradada por los cambios adicionados al sistema y aún
existen nuevos requerimientos funcionales para el sistema.

• Migrar o reemplazar el sistema por otro sistema. La migración es un proceso que

transforma el sistema existente en uno nuevo. Cuando debido a diversos factores
(cuestiones técnicas, contractuales, estratégicas, etc) la operatividad o el soporte a futuro
del sistema sea incierto, se debe considerar esta alternativa.
"Los sistemas que proporcionan alto valor al negocio y representan poco riesgo son los sistemas
que cualquier negocio debería procurar tener"

La decisión de eliminar un sistema puede ser fácilmente tomada cuando éste ofrece poco valor al
negocio y representa un riesgo elevado. Igualmente la decisión de mantenerlo se toma fácilmente
cuando el riesgo que el sistema representa para el negocio es mínimo. Los sistemas que
proporcionan alto valor al negocio y representan poco riesgo son los sistemas que cualquier
negocio debería procurar tener. Los sistemas que ofrecen alto valor y a su vez representan un
riesgo alto son los sistemas donde más factores deben considerarse antes de tomar una decisión
respecto a su futuro.

El impacto sobre el sistema es proporcional al número de cambios que lo afecten, así, tolerar y
mantener el sistema tiene menos impacto que su transformación o reemplazo. Obviamente, entre
mayor sea el impacto sobre el sistema actual, mayor será el riesgo que se corra durante su
proceso de evolución.

El mantenimiento involucra actualizaciones en la aplicación sin hacer cambios drásticos en el

código y sin modificar su arquitectura interna. La estrategia tiene tres variantes: mantenimiento
adaptativo, mantenimiento correctivo y mantenimiento perfectivo.

El mantenimiento adaptativo se encarga de hacer cambios menores en la funcionalidad del

sistema para asegurarse que permanece alineado con los nuevos requerimientos del negocio. Las

6
 Estándares de Programación
ESTP-T

actividades de mantenimiento pueden dirigirse también hacia la eliminación de errores en el

código (mantenimiento correctivo) o la optimización del código existente para cumplir mejor con
los requerimientos funcionales y de calidad de servicio (mantenimiento perfectivo).

La migración es una alternativa con alto impacto en el sistema y es considerada una solución de
largo plazo. La migración busca reutilizar, tanto como le sea posible, los procesos existentes en el
sistema legado, incluyendo el diseño y la especificación, de tal forma que se conserve la
funcionalidad del sistema original a pesar de residir ahora en una plataforma tecnológica
diferente.

La migración requiere generalmente el re-desarrollo de partes del sistema partiendo de la

definición actualizada de algunos procesos de negocio. Esta metodología se denomina ‘top-down’
o de arriba hacia abajo. La metodología inversa, que parte desde el código legado para identificar
los procesos de negocio, se denomina ‘bottom-up’ o ingeniería en reversa.

La migración puede llevarse a cabo de manera incremental, donde ciertos procesos de negocio
presentes en el sistema original, son implementados sobre el nuevo sistema y posteriormente se
hace una transferencia gradual de control desde el sistema original hacia el nuevo sistema; o con
una aproximación conocida como Big-Bang, donde el sistema original es desconectado para dar
paso al nuevo sistema. En los procesos de migración es importante evitar, de ser posible, la
interrupción de las operaciones soportadas por el sistema.

"Una valoración sobre el sistema, considerando los aspectos necesarios para garantizar su
continuidad y disponibilidad en el tiempo, permite tomar una decisión sobre la estrategia
adecuada para su evolución"

No siempre es posible categorizar un problema de evolución en base a una de estas alternativas.

Estas pueden combinarse o ser aplicadas en distintas partes del sistema para cumplir con el
objetivo de modernización. Aun cuando estas acciones se definen a nivel del sistema en general,
su aplicación se hace típicamente a nivel de componente funcional.

Una valoración sobre el sistema, considerando los aspectos necesarios para garantizar su
continuidad y disponibilidad durante el tiempo (aspectos que incluyen factores como la
disponibilidad de soporte en hardware y software), y la determinación de continuar con la
operación de los procesos soportados en el sistema, permite tomar una decisión sobre la
estrategia adecuada para evolucionar el sistema.
7
 Estándares de Programación
ESTP-T

Durante el proceso de migración se debe procurar evitar que nuevos componentes de alto riesgo
sean introducidos en el portafolio de soluciones de la empresa.

La evolución del sistema puede ser aproximada de dos maneras: mediante la integración del
sistema con nuevas aplicaciones y componentes, técnica conocida como modernización de caja
negra, donde un conocimiento general del sistema permite iniciar labores de integración; o
mediante la transformación con un esquema de ‘caja blanca’, donde se requiere un conocimiento
detallado del sistema, sus procesos, operaciones e interacciones para poder definir correctamente
los requerimientos de negocio que serían soportados en el sistema objetivo. Un entendimiento
insuficiente del sistema podría llevar a una especificación de requerimientos incorrecta, lo que
llevaría a un proceso de migración no satisfactorio.

TRANSICIÓN HACIA EL NUEVO SISTEMA

El último paso en un proyecto de migración consiste en la transición hacia el nuevo sistema.

Existen tres estrategias principales de transición:

• La estrategia Big-Bang. Consiste en apagar el sistema y reemplazarlo por el nuevo sistema

(todo o nada).
• La estrategia de interoperabilidad por fases (gradual o incremental). Donde la transición se
llevaría a cabo en pasos pequeños e incrementales, cada paso reemplazando unos pocos
componentes del sistema legado con componentes correspondientes en el sistema
objetivo.
• Estrategia de operación en paralelo. Donde los sistemas legado y el sistema objetivo
funcionarían simultáneamente y ambos ejecutarían todas las operaciones. Durante este
periodo el sistema objetivo sería continuamente probado, y una vez certificada su
conformidad, se retiraría el sistema legado.

La estrategia Big-Bang es algo irrealista por los riesgos que implica. La transición hacia el nuevo
sistema en un solo paso cede el control total de operaciones y del flujo de información a un
sistema que no ha demostrado sus méritos. Por otro lado, la interoperabilidad por fases es
potencialmente compleja. Para ser exitosa requiere que los servicios soportados en el sistema
legado sean descompuestos y separados en módulos funcionales que puedan ser migrados
independientemente. La naturaleza monolítica y no estructurada de muchos de los sistemas
legados hace que esta tarea no sea sencilla.

Una estrategia de transición para un sistema legado probablemente involucraría una combinación
de estas tres aproximaciones aplicadas a partes distintas del sistema.

Para la estrategia combinada se seguirían los siguientes pasos para migrar componentes del
sistema legado al nuevo sistema (aproximación incremental):

1. Análisis de la porción del sistema legado involucrada en la migración

8
 Estándares de Programación
ESTP-T

2. Descomposición del componente o módulo funcional

3. Diseño de la interfaz objetivo (puntos de contacto o interacción con otros componentes o
módulos)
4. Diseño de la aplicación objetivo
5. Diseño de la base de datos (o tablas) objetivo
6. Instalación del ambiente destino (aplicaciones middleware necesarias, activación de
servicios, etc)
7. Migración de los datos desde el sistema legado
8. Migración de las aplicaciones del sistema legado
9. Migración de las interfaces del sistema legado
10. Transición al nuevo sistema

Usando esta estrategia, las aplicaciones del sistema legado serían gradualmente reconstruidas en
el sistema objetivo usando tecnología moderna. El sistema objetivo sería inicialmente pequeño
pero crecería según el proceso de migración sea llevado a cabo. Eventualmente el sistema
soportaría toda la funcionalidad requerida del sistema, permitiendo el retiro del sistema legado
(phase-out).

"La migración de un sistema legado puede considerarse como una oportunidad para aproximarse
hacia una arquitectura empresarial soportada en servicios"

Dadas las expectativas que se generan durante los proyectos de migración, debido a la
incorporación de tecnologías más modernas y flexibles, usualmente se espera contar con la
adición de nuevas funcionalidades para justificar el tiempo, el riesgo y el costo invertido en el
proyecto. No es recomendable la introducción de nuevas funcionalidades al sistema objetivo
durante el proceso de migración. Dada la naturaleza de misión crítica de los sistemas legados, las
salidas del sistema objetivo deberían ser completamente consistentes con aquellas producidas por
el sistema original. Cuando la funcionalidad es equivalente, los planes de testing, que serían
ejecutadas continuamente durante el proceso de migración, podrían enfocarse en comparar las
salidas del sistema original con aquellas del nuevo sistema para determinar su validez.

La migración de un sistema legado puede considerarse como una oportunidad para aproximarse
hacia una arquitectura empresarial soportada en servicios, siendo un driver para iniciar la
modernización de algunos componentes o aplicaciones contenidas en la plataforma de la
organización.