Insights

Análisis de código legado: herramientas y método paso a paso

Fri, 03 Jul 2026 11:51:14 GMT

El código legado solía definirse como el código que corresponde mantener a alguien que no lo escribió. Hoy esa definición se queda corta: pasa incluso con aplicaciones desarrolladas por la propia compañía, cuando quienes escribieron el código original ya están en otros proyectos. Una definición más útil es esta: código legado es aquel que resulta difícil de modificar porque su funcionamiento es desconocido, casi siempre por falta de documentación y de tests. Antes de tocar una sola línea, hay que analizarlo. Este artículo repasa qué preparar antes de empezar y qué herramientas de análisis de código legado ayudan a hacerlo en plazos razonables.

Qué es exactamente el código legado (y por qué cuesta tanto tocarlo)

El código legado no es solo el código viejo: es el código que resulta difícil de modificar porque nadie entiende del todo cómo funciona. Suele estar sin documentar o mal documentado, casi nunca tiene tests unitarios, y muchas veces no sigue ninguna pauta de diseño reconocible hoy.

Para hacer cambios que no sean triviales, hace falta entender antes la arquitectura, cómo se relacionan sus componentes y qué limitaciones tiene cada uno. Estas aplicaciones además suelen ser monolíticas, lo que complica todavía más saber hasta dónde llega el alcance real de un cambio.

Antes de analizar el código legado: qué preparar primero

Hay algunos requisitos previos que conviene resolver antes de empezar el análisis. El primero es tener claro el objetivo: no es lo mismo analizar una aplicación para reemplazarla a medio plazo que hacerlo para mantenerla, o para ponerla al día y que siga operativa mucho tiempo.

Recopila toda la información disponible: documentación técnica, manuales de usuario, requisitos iniciales y el historial de modificaciones. Te ayuda a entender por qué se tomaron ciertas decisiones a lo largo de la vida del software.
Si existen repositorios, conserva todas las versiones del código. Ver cómo ha ido cambiando para responder a necesidades que no estaban previstas al principio aporta un contexto que no está en ningún documento.
Consigue una copia de la base de datos, total o parcial, que te permita entender el sistema en funcionamiento real. A veces las partes que parecían más complejas apenas se usan, y eso cambia por completo las prioridades del análisis.

Un caso típico: agendas hechas a medida dentro de aplicaciones heredadas que ya nadie usa porque los clientes de email y las suites ofimáticas hacen ese trabajo mejor. Detectar ese código muerto y sustituirlo por conectores sencillos reduce el coste de mantenimiento sin apenas esfuerzo.

Herramientas de análisis estático: el primer nivel de análisis

¿Cómo analizar una aplicación con cientos de miles de líneas de código? Hacerlo a mano exige recursos y tiempo que casi nunca sobran, sobre todo si la aplicación sigue en uso y hay que modificarla a corto plazo. Aquí es donde entran las herramientas de análisis estático de código, como Helix QAC para C y C++, o Klocwork, que además cubre C# y Java. Hay opciones para casi cualquier lenguaje: la clave es elegir la que encaje con el software que vas a analizar.

Además, hoy la IA generativa ha cambiado este escenario al facilitar la comprensión del software, generar documentación, responder preguntas sobre el código e incluso identificar patrones y posibles problemas en cuestión de minutos. Sin embargo, la IA no sustituye al análisis estático, las herramientas de análisis estático siguen siendo un complemento imprescindible.

A nivel unitario, estas herramientas informan sobre el funcionamiento de partes del código aisladas del resto: datos, benchmarks, comportamiento del sistema. Es un análisis básico, pero necesario, y da una primera idea sólida de la arquitectura general.

A nivel de tecnología, permiten analizar las interacciones entre esas partes para detectar errores potenciales, como un método que entrega una salida que puede hacer fallar a otra clase. En esos casos hace falta adaptar la clase para que valide los datos, o derivarla para tratar ese caso concreto.

Análisis a nivel de sistema: rendimiento, seguridad y base de datos

A nivel de sistema entran en juego otras piezas: el entorno, la base de datos, la infraestructura completa. Aquí las herramientas ya no analizan tanto el código como su comportamiento en tareas concretas, y permiten detectar, por ejemplo, componentes que generan un número innecesario de peticiones a la base de datos y ralentizan toda la aplicación.

Optimizar y racionalizar esas consultas suele mejorar el rendimiento de forma directa.
Incorporar cachés en bases de datos en memoria, o sistemas de autenticación basados en tokens, resuelve buena parte de los problemas de rendimiento y seguridad de forma prácticamente transparente para el resto de la aplicación.

Para este tipo de análisis se suele recurrir a herramientas de profiling o benchmarking generales, que estudian el uso de la base de datos, los recursos del sistema operativo y el acceso a la red.

Checklist: ¿tienes todo listo para analizar tu código legado?

¿Tienes claro si el objetivo es mantener la aplicación, sustituirla o ponerla al día para que siga operativa a largo plazo?
¿Has recopilado toda la documentación técnica, de requisitos y de modificaciones disponible?
¿Conservas todas las versiones del código en el repositorio, no solo la última?
¿Tienes una copia de la base de datos que refleje el uso real del sistema, no solo su diseño original?
¿Sabes qué herramienta de análisis estático encaja con el lenguaje de tu aplicación?

Preguntas frecuentes sobre análisis de código legado

¿Qué es exactamente el código legado?

Es el código que resulta difícil de modificar porque su funcionamiento es desconocido. Casi siempre está sin documentar, sin tests unitarios y sin seguir las pautas de diseño actuales, independientemente de su antigüedad.

¿Por dónde hay que empezar antes de analizar código legado?

Por definir el objetivo del análisis: si es para mantenimiento, para sustitución o para poner al día la aplicación. Después toca recopilar documentación, conservar el historial del repositorio y conseguir una copia realista de la base de datos.

¿Qué herramientas de análisis estático de código se usan más?

Actualmente, el análisis de código combina dos enfoques complementarios. Por un lado, la IA generativa facilita la comprensión del software, la generación de documentación y la exploración rápida de grandes bases de código. Por otro, las herramientas de análisis estático siguen siendo imprescindibles cuando se necesita obtener información precisa, verificable y determinista sobre el comportamiento del código.

Entre las herramientas de análisis estático más utilizadas se encuentran Helix QAC para C y C++, y Klocwork, que además soporta C# y Java. Existen soluciones equivalentes para la mayoría de lenguajes; lo importante es seleccionar la que mejor se adapte a la tecnología de la aplicación que se va a analizar.

¿Qué diferencia hay entre el análisis a nivel unitario y a nivel de tecnología?

El análisis a nivel unitario estudia partes del código de forma aislada: datos, benchmarks, comportamiento. El análisis a nivel de tecnología va un paso más allá y estudia cómo interactúan esas partes entre sí para detectar errores que solo aparecen en esa interacción.

¿Qué se analiza a nivel de sistema en una aplicación legacy?

El entorno completo: base de datos, infraestructura, patrones de acceso. Permite detectar, por ejemplo, componentes que generan peticiones innecesarias a la base de datos y ralentizan toda la aplicación.

¿Es igual analizar código legado para mantenerlo que para migrarlo?

No. Si el objetivo es mantenerlo, el análisis se centra en entender riesgos y dependencias. Si el objetivo es migrarlo o sustituirlo, buena parte de la complejidad detectada puede acabar descartándose junto con el código que ya no se necesita en el sistema nuevo.

Qué es el Machine Learning: definición, ejemplos y cómo funciona

Fri, 03 Jul 2026 11:33:11 GMT

El Machine Learning es una de las tecnologías que más está dando que hablar, y no solo en círculos técnicos: también en sectores tan alejados de la informática como la industria o las fábricas. Para entender por qué, primero hay que saber qué es el Machine Learning, para qué se usa y cómo funciona por dentro. A continuación repasamos los datos más importantes, sin tecnicismos innecesarios.

Qué es el Machine Learning (y por qué se ha vuelto tan popular)

Dentro de la Inteligencia Artificial hay varias ramas o enfoques. Una de ellas es el Machine Learning, que en español se traduce como aprendizaje automático. Se lleva teorizando y desarrollando desde hace décadas, pero solo en los últimos años ha ganado la popularidad suficiente como para salir del ámbito puramente científico y colarse en el lenguaje empresarial y en los medios generalistas.

Parte de esa popularidad viene de que el Machine Learning ya forma parte de la vida cotidiana de casi cualquiera. Muchas empresas de producto y servicio presumen de usarlo como ventaja competitiva, y eso ha ayudado a que el término se vuelva familiar incluso para quien nunca ha escrito una línea de código.

Dónde te encuentras el Machine Learning en tu día a día

El Machine Learning está mucho más cerca de lo que parece. Estos son algunos de los ejemplos más habituales:

Recomendaciones personalizadas: plataformas como Netflix lo usan para sugerir contenido a partir de lo que ya has visto antes.
Asistentes y sugerencias de texto: desde los asistentes virtuales del móvil hasta Gmail, que te sugiere frases justo cuando ibas a escribirlas tú mismo.
Seguridad e identificación: sistemas captcha que distinguen personas de bots con mucha fiabilidad, y algoritmos de reconocimiento facial que desbloquean el móvil o catalogan fotos.

También está detrás de usos menos visibles pero igual de relevantes: detección temprana de enfermedades, previsiones financieras, meteorológicas o deportivas, y cada vez más, la modernización de software que necesita algún tipo de automatización basada en la experiencia.

Desde cuándo se usa el Machine Learning: una breve historia

Hay mucha teoría escrita sobre esta rama de la computación: desde los años 50 se ha ido construyendo la base que hace posible todo esto. Sin embargo, las aplicaciones prácticas fueron muy limitadas hasta las últimas décadas, cuando el aumento de capacidad de proceso y, sobre todo, la caída de las barreras de acceso, marcaron un salto real.

Un buen ejemplo son los buscadores de Internet. A principios de los 90 eran poco más que catálogos hechos a mano. Cuando la red creció, eso dejó de ser viable, y empezaron a aparecer los crawlers: bots que rastreaban e indexaban contenido. Google fue quien primero logró puntuar esos contenidos por relevancia con PageRank, sentando las bases de lo que hoy damos por hecho al buscar algo online.

Hoy los buscadores usan Inteligencia Artificial para identificar de qué trata una página analizando su contenido real, algo que antes se hacía con etiquetas que el propio creador de la web rellenaba y que resultaron fáciles de manipular. También aprenden del comportamiento de los usuarios: si alguien entra en el primer resultado y vuelve atrás enseguida, el sistema toma nota para mejorar la próxima vez.

Cómo funciona el Machine Learning: la lógica detrás del aprendizaje

Existen distintas técnicas algorítmicas para que una máquina aprenda, pero la mayoría de métodos parten del teorema de Bayes: la capacidad de calcular la probabilidad condicionada de que ocurra un suceso determinado. En la práctica, casi todo se reduce a prueba y error.

La máquina analiza los datos disponibles y busca correlaciones que, para un analista humano, tal vez no tendrían ningún sentido. Después contrasta esa hipótesis con otro conjunto de datos para comprobar si acierta más que el azar. Repitiendo este proceso una y otra vez, el algoritmo afina las correlaciones que mejor funcionan. En los casos más avanzados, ni siquiera hace falta construir el algoritmo a partir de conclusiones fijas: el propio sistema se retroalimenta y se ajusta solo con el tiempo.

Checklist: ¿tiene sentido el Machine Learning en tu empresa?

¿Alguno de tus sistemas necesita automatizar decisiones basadas en la experiencia acumulada, no solo en reglas fijas?
¿Generas datos suficientes como para que un algoritmo pueda encontrar correlaciones útiles en ellos?
¿Tienes procesos manuales que hoy dependen de la intuición de una persona con experiencia?
¿Alguno de tus sistemas legacy podría beneficiarse de una capa de predicción o recomendación?
¿Sabrías distinguir un buen caso de uso de Machine Learning de una moda pasajera?

Preguntas frecuentes sobre machine learning

¿Qué es el Machine Learning en términos sencillos?

Es una rama de la Inteligencia Artificial, también llamada aprendizaje automático, en la que una máquina aprende a partir de datos y ejemplos en lugar de seguir reglas fijas escritas por una persona.

¿Qué ejemplos de Machine Learning uso sin darme cuenta?

Las recomendaciones de Netflix, las sugerencias de texto de Gmail, los asistentes virtuales del móvil, los sistemas captcha y el reconocimiento facial son ejemplos que casi todo el mundo usa a diario sin pensar en la tecnología que hay detrás.

¿Desde cuándo existe el Machine Learning?

La teoría se remonta a los años 50, pero las aplicaciones prácticas eran muy limitadas hasta que la capacidad de proceso aumentó y el acceso a la tecnología se abarató, ya entrado el siglo actual.

¿Cómo aprende una máquina en Machine Learning?

Analizando datos y buscando correlaciones mediante prueba y error. Contrasta esas correlaciones con nuevos datos para comprobar si aciertan más que el azar, y repite el proceso hasta afinar un algoritmo que haga predicciones fiables.

¿Es lo mismo Machine Learning que Inteligencia Artificial?

No exactamente. La Inteligencia Artificial es el campo general, y el Machine Learning es una de sus ramas: la que se centra en que los sistemas aprendan de los datos en lugar de seguir instrucciones programadas de forma explícita.

¿Puede el Machine Learning ayudar a modernizar sistemas legacy?

Sí, sobre todo cuando el software necesita algún tipo de automatización basada en la experiencia acumulada: detección de patrones, predicciones o recomendaciones que antes dependían por completo de reglas fijas o de la intuición de una persona.

Sustituto Visual Basic 6: qué opciones existen realmente y cómo migrar sin parar el negocio

Fri, 03 Jul 2026 09:32:11 GMT

Si tienes aplicaciones en producción escritas en Visual Basic 6, ya sabes que Microsoft retiró el soporte en 2008. Llevamos dieciocho años operando sobre un entorno sin parches de seguridad, sin actualizaciones de runtime y sin compatibilidad nativa con sistemas operativos modernos de 64 bits. La pregunta sobre qué programa puede sustituir a Visual Basic 6 no es académica: es una decisión que la mayoría de CTOs e IT Directors tienen pendiente desde hace años y que, en algún momento, deja de ser aplazable. Este artículo no pretende convencerte de nada que no sepas ya. Pretende ser la guía técnica que te faltaba para tomar esa decisión con criterio.

Por qué llevas años aplazando la decisión y qué ha cambiado en 2026

La respuesta más honesta es que aplazar tenía lógica económica. Mientras el sistema funcionara, el coste de no migrar era invisible. Los costes visibles —migración, riesgo operacional, curva de aprendizaje— pesaban más en el presupuesto anual.
Lo que ha cambiado en los últimos tres años es que esa ecuación ya no funciona:
El coste de mantenimiento ha crecido de forma no lineal. Menos del 2% de los desarrolladores activos trabaja con Visual Basic como tecnología primaria (Stack Overflow Developer Survey 2024). El coste por hora de un especialista sénior VB6 en España se ha multiplicado por 2,3 en los últimos cinco años.
La deuda técnica ha alcanzado un punto de inflexión. Las aplicaciones desarrolladas entre 1995 y 2005 en VB6 tienen hoy entre 20 y 30 años de parches, workarounds y lógica de negocio enterrada en módulos que nadie recuerda qué hacen.
Los reguladores no son indiferentes. DORA (Digital Operational Resilience Act), en vigor desde enero de 2025, establece requisitos de resiliencia operacional. Una aplicación sin soporte de fabricante que procesa transacciones financieras es un punto de riesgo regulatorio documentado.

Opciones reales como sustituto de Visual Basic 6

Hay cuatro caminos que se plantean en cualquier proyecto de modernización de VB6:

1. Reescritura manual en un lenguaje moderno (Java, C#, Python)

Tiene sentido cuando el sistema es pequeño y bien documentado. El 74% de las iniciativas de reescritura manual superan el presupuesto inicial, y el 52% no completan la migración funcional en el plazo previsto según un informe de Gartner de 2023. El problema de fondo: la lógica de negocio está en los años de parches que nadie documentó.

2. Reescritura asistida por IA generativa (GitHub Copilot, modelos LLM)

La IA generativa no es determinista: dado el mismo input puede producir outputs distintos. Para sistemas de liquidaciones bancarias o cálculo de pólizas, una variación no prevista es un riesgo regulatorio, no un bug. Según un informe de Forrester Research de 2024, el 68% de los pilotos de migración con IA en sistemas críticos se interrumpieron por problemas de trazabilidad.

3. Emulación y encapsulamiento (wrappers, APIs sobre el sistema existente)

Solución de transición, no de modernización. Útil para ganar 12–18 meses mientras se prepara la migración real. Riesgo: adoptarlo como solución permanente, acumulando una capa adicional de deuda técnica.

4. Migración automática con proceso industrializado y determinista

Nuestro proceso de migración automatizado con lenguaje pivote propio produce una equivalencia funcional verificable y trazable siguiendo reglas formales — no estadísticas —. Resultado: código limpio, legible y mantenible por el equipo propio, sin licencias adicionales. Indicado para sistemas con 50+ unidades funcionales, lógica compleja o mal documentada, y entornos regulados donde la trazabilidad es obligatoria.

¿Es la IA generativa ya es suficientemente buena?

Para aplicaciones secundarias: posiblemente sí. Para aplicaciones de core con 25 años de reglas acumuladas: no, y probablemente no lo será en los próximos tres años para ese nivel de criticidad.
El argumento no es que la IA sea mala tecnología — es excelente en assessment, documentación automática y generación de tests —. El argumento es que el lugar donde una variación no es tolerable es exactamente donde la IA tiene sus limitaciones inherentes. Para esos sistemas, el determinismo no es un argumento de marketing: es un requisito funcional.

Qué ocurre en la práctica: el patrón de decisión que hemos visto en banca y seguros

En los proyectos que hemos ejecutado, el proceso sigue este patrón:

El trigger inicial es casi siempre un incidente, una auditoría o un cambio regulatorio. El plazo en backlog suele ser de 2 a 5 años.
La primera evaluación incluye consultoras grandes y herramientas de IA. El resultado: reescritura manual cara o piloto de IA que no escala a los módulos críticos.
El criterio de selección final no es el precio. Es la certeza técnica: «¿puedo comprometer este proyecto ante mi consejo de administración con garantía de que va a funcionar?»

Una prueba de concepto gratuita sobre los propios módulos del sistema responde a esa pregunta mejor que cualquier presentación.

Checklist de evaluación: antes de decidir qué sustituto usar para tu sistema VB6

¿Cuántas ventanas, módulos o unidades funcionales tiene el sistema? (A partir de 100, la reescritura manual empieza a ser inviable en plazos razonables.)
¿Está documentada la lógica de negocio? (Si la respuesta es «más o menos», hay lógica oculta que una reescritura manual no va a capturar.)
¿El sistema procesa transacciones críticas o datos regulados? (Si es sí, la trazabilidad es un requisito no negociable.)
¿Puede el negocio tolerar una congelación del código durante el proyecto? (La mayoría no puede: el negocio sigue evolucionando mientras migra.)
¿El proveedor puede demostrar equivalencia funcional verificable antes de comprometer el proyecto completo?

Preguntas frecuentes sobre migración y sustitución de Visual Basic 6

¿Cuál es el mejor sustituto para Visual Basic 6 en aplicaciones empresariales críticas?

No hay un sustituto directo en el sentido de «instalo X y el código funciona igual». Lo que existe son estrategias de migración hacia lenguajes modernos como Java, C# o Angular. El criterio más importante no es el lenguaje destino sino el proceso de migración: que garantice equivalencia funcional completa, trazabilidad y que no requiera congelar el código durante el proyecto.

¿Puede la IA generativa (ChatGPT, GitHub Copilot) migrar aplicaciones VB6?

Puede generar código en lenguajes modernos a partir de VB6, pero no de forma determinista. Para sistemas que procesan transacciones financieras o cálculo de pólizas, la falta de trazabilidad verificable es un problema que ninguna revisión manual puede resolver completamente a escala. Los proyectos que lo han intentado suelen alcanzar un 60–70% de cobertura y se bloquean en los módulos más críticos.

¿Cuánto tiempo lleva migrar un sistema VB6 a Java o Angular?

Una prueba de concepto sobre módulos reales: 2–4 semanas. Un proyecto completo de migración automatizada: entre 3 y 18 meses según volumen y complejidad. La variable crítica no es el volumen de código, sino la complejidad de la lógica de negocio y si el negocio puede seguir evolucionando durante la migración.

¿Qué pasa si seguimos manteniendo aplicaciones VB6 en producción sin migrar?

A corto plazo el sistema seguirá funcionando. El riesgo es acumulativo: incompatibilidades con Windows 11/Server modernos, imposibilidad de parches de seguridad, escasez de desarrolladores VB6. En el contexto de DORA (en vigor desde enero 2025), operar con aplicaciones críticas sin soporte de fabricante debe estar documentado como riesgo gestionado.

¿Cuál es la diferencia entre migración automática determinista y reescritura manual de VB6?

La reescritura manual depende de cuánto entendió el equipo de la lógica original. La migración automática determinista parte de reglas formales de transformación: el código se convierte siguiendo un proceso reproducible donde la equivalencia funcional es verificable y trazable. Cualquier auditor puede ver qué línea del código original corresponde a qué línea del nuevo.

¿Cómo sé si mi sistema VB6 es candidato a migración automática?

Los mejores candidatos: sistemas con 50+ unidades funcionales, lógica de negocio consolidada, entornos regulados donde la trazabilidad es obligatoria, y organizaciones que no pueden tolerar una parada del sistema. Una prueba de concepto gratuita sobre los módulos más representativos es la forma más rápida de validar antes de comprometer ningún presupuesto.

GO4IT participa en el proyecto NOCOD4TST

info@go4it.solutions (GO4IT) — Tue, 24 Mar 2026 17:01:53 GMT

GO4IT SOLUTIONS completa con éxito el primer año del proyecto NoCode 4 Testing

En GO4IT SOLUTIONS seguimos apostando por la innovación tecnológica como motor de transformación empresarial. Hoy queremos compartir un hito importante: hemos completado con éxito la primera anualidad del proyecto NoCode4Testing, una iniciativa estratégica orientada a redefinir cómo las organizaciones modernizan y validan sus sistemas software financiado por convocatoria HAZITEK .

Un proyecto para transformar la calidad del software

NoCode4Testing nace con un objetivo claro: revolucionar el proceso de validación en la modernización de sistemas legacy. En un contexto donde muchas organizaciones dependen todavía de tecnologías obsoletas, garantizar la calidad tras una migración sigue siendo uno de los mayores retos, tanto por su complejidad como por su coste.

El proyecto propone un enfoque disruptivo basado en inteligencia artificial generativa multimodal. En lugar de depender de procesos manuales intensivos, la solución busca automatizar la generación de pruebas funcionales a partir del uso real de las aplicaciones legacy, capturando vídeo, audio e interacción de usuario para transformarlos en scripts de testing automáticos .

Innovación basada en IA generativa

Durante este primer año, el foco ha estado en sentar las bases tecnológicas del sistema. En concreto, se ha trabajado en:

La investigación de modelos de IA capaces de interpretar interfaces y procesos de negocio a partir de vídeo y voz.
El desarrollo de agentes inteligentes que transforman esa información en descripciones estructuradas.
La generación automática de scripts de pruebas funcionales para validar sistemas modernizados.

Este enfoque permite avanzar hacia un modelo en el que la calidad del software deja de ser un cuello de botella y pasa a ser un proceso automatizado, continuo y escalable.

Primeros resultados y aprendizajes

La primera anualidad ha estado centrada en la investigación y en la construcción de los primeros prototipos, especialmente en escenarios donde sistemas legacy en entornos Windows evolucionan hacia aplicaciones web modernas .

Entre los principales avances destacan:

Definición de la arquitectura base del sistema.
Desarrollo inicial de pipelines de IA multimodal.
Primeros prototipos funcionales de generación automática de pruebas.

Estos logros validan la viabilidad técnica del enfoque y sientan las bases para las siguientes fases del proyecto.

Impacto esperado: eficiencia y calidad

El potencial impacto de NoCode4Testing es significativo. Se estima que la solución permitirá:

Reducir hasta en un 75% el esfuerzo necesario para realizar pruebas funcionales.
Disminuir en un 50% los errores detectados en fases de validación .

Esto no solo implica una mejora en la eficiencia operativa, sino también una aceleración en los procesos de modernización tecnológica de nuestros clientes.

Mirando hacia el futuro

Tras este primer año, el proyecto entra en una nueva fase en la que se profundizará en:

La ampliación de casos de uso y tipos de sistemas legacy.
La mejora de la precisión y robustez de los modelos.
La integración de pruebas más complejas y escenarios reales.

En GO4IT SOLUTIONS estamos convencidos de que NoCode4Testing marcará un antes y un después en la forma en la que las empresas abordan la modernización de software, combinando automatización, inteligencia artificial y eficiencia operativa.

Seguimos avanzando.