Modelo desarrollado junto a nuestro socio en BrasilEntender antes de modernizar.
Un marco de trabajo con Inteligencia Artificial integrada que lee el código de las aplicaciones actuales, reconstruye el conocimiento del sistema y genera la nueva aplicación en la tecnología que la organización elija.
No traslada el problema de una tecnología vieja a otra: reconstruye a partir de la evidencia.
más rápido en la modernización frente a los métodos tradicionales, con libertad total de tecnologías y entornos.
Tres pasos, y una fase que no termina.
Entender
Se lee el código fuente y se reconstruye lo que el sistema realmente hace: módulos, datos, pantallas, dependencias y reglas de negocio.
Decidir
El conocimiento recuperado deja a la vista las brechas, los riesgos, las ambigüedades y la deuda técnica. El equipo las resuelve antes de escribir código nuevo.
Modernizar
Sobre ese conocimiento se construye la nueva aplicación por capas —interfaz, servicios, datos e infraestructura— y se entrega en el repositorio del cliente.
Evolucionar
Fase continua. El sistema se mantiene alineado al modelo a medida que cambia, con documentación derivada del código y no escrita aparte.
Las fases 01 y 02 constituyen el entendimiento profundo y son el punto de entrada natural: producen la evidencia sobre la cual decidir si modernizar, cómo hacerlo y con qué esfuerzo.
Un modelo único, independiente de la tecnología.
Reúne datos, pantallas, componentes y reglas de negocio con sus relaciones. Cada elemento se puede rastrear hasta la línea de código que lo origina.
Se construye en la fase 01, se depura en la 02, guía la generación en la 03 y sirve de referencia en la 04.
El modelo fija los límites dentro de los cuales se genera el código nuevo. Resuelve así los dos problemas conocidos de la IA aplicada a código: que no conoce el contexto del sistema y que no tiene límites definidos.
La IA interviene solo donde hace falta interpretar el sentido de una regla. Ninguna regla de negocio se pierde en el camino.
Qué hace la máquina y qué decide una persona.
Cada actividad está marcada por su naturaleza. La transparencia sobre quién hace qué es lo que permite confiar en el resultado.
Entender
Decidir
Modernizar
Evolucionar
Fase continua¿El entendimiento es suficiente y está respaldado en evidencia?
¿Están resueltas todas las decisiones que requieren criterio humano?
¿La aplicación respeta las reglas catalogadas del sistema original?
Tres pasos para reconstruir el conocimiento del sistema.
Todo parte del código fuente. Nada se asume y nada se estima: lo que entra al modelo está respaldado por una línea de código real.
Lee y aprende la aplicación actual
El código se carga desde un archivo comprimido o desde el repositorio. El motor reconoce el lenguaje en que fue escrito y aprende sus reglas.
Lenguajes que lee: cualquiera. Por ejemplo VB.NET, C#, .NET, ASP.NET, Java, Delphi, Oracle Forms, PHP, Angular, TypeScript.
Construye el modelo del sistema
Un modelo único e independiente de la tecnología —lo llamamos UIR— que reúne datos, pantallas, componentes y reglas de negocio, con sus relaciones.
Cada elemento se puede rastrear hasta la línea de código que lo origina.
Convierte el modelo en evidencia
Sobre ese modelo se producen los catálogos, mapas y hallazgos que sustentan la decisión: qué se reconstruye, qué se retira y qué se deja como está.
Es el insumo directo del informe de entendimiento profundo.
Lo que existe al cerrar la Fase 1.
Un informe de entendimiento profundo, sustentado en el código y no en la memoria de las personas que mantienen el sistema.
Catálogo de módulos
Cada módulo con su nivel de riesgo, sus pantallas, sus campos y las reglas asociadas.
Mapa de dependencias
Qué depende de qué, y cuál es el impacto real de cualquier cambio, dato a dato.
Reglas de negocio extraídas
Con su condición exacta y el fragmento de código que la origina.
Modelo de datos
Entidades, relaciones, pantallas y almacenamiento reconstruidos a partir del código.
Seguridad y cumplimiento
Datos sensibles detectados, hallazgos críticos y riesgos ocultos en la aplicación actual.
Resumen ejecutivo y deuda técnica
Casos de uso, historias de usuario, deuda medida y reportes que se pueden exportar.
No todo se resuelve de forma automática. Las reglas ambiguas, los conflictos de nombres y las decisiones que exigen criterio humano se llevan a un tablero donde el equipo las revisa, las discute y las cierra, antes de generar una sola línea de código nuevo.
Qué entra y qué sale en cada fase.
Entra
- Código fuente, en archivo comprimido o repositorio Git
- Alcance acotado: la aplicación o el dominio a analizar
Sale
- Catálogo de módulos con su nivel de riesgo
- Mapa de dependencias
- Reglas de negocio con su fragmento de código de origen
- Modelo de datos reconstruido
- Hallazgos de seguridad y datos personales
Entra
- Los hallazgos de la fase anterior
- Un interlocutor técnico y funcional por sistema
Sale
- Informe de entendimiento profundo
- Decisiones de alcance documentadas
- Recomendación de ruta de modernización
Entra
- El modelo del sistema, ya depurado
- Plantilla de arquitectura destino definida por el cliente
Sale
- Código fuente de la aplicación nueva en el repositorio del cliente
- Documentación técnica
- Artefactos de despliegue
Entra
- La aplicación nueva en operación
- El modelo del sistema como referencia
Sale
- Un sistema que el equipo del cliente mantiene y evoluciona por sí mismo
- Documentación que se mantiene alineada con el código
Una ventana acotada para decidir con evidencia.
La duración depende del tamaño y la complejidad del sistema analizado.
Lo que necesitamos para empezar
El modelo de despliegue, la ubicación del código y el tratamiento de los datos sensibles se acuerdan y se formalizan por escrito antes de cualquier carga.
Una sesión técnica de 60 minutos para acotar el sistema piloto.
Revisamos la tecnología, el alcance y definimos las condiciones de acceso al código.
Agendar la sesión