Evolución del SoftwareModernización + Innovación:Acelerada por IA, dirigida por expertos.

Ingeniería de requisitos y procesos: reconstruir qué hace el sistema para el negocio

El error más común, y más caro, en la modernización es tratar un sistema heredado como solo código que hay que reescribir. Un sistema heredado es tres cosas a la vez: el código, los requisitos y objetivos de calidad que cumple de forma silenciosa, y los procesos de negocio y flujos de trabajo humanos que se construyen sobre él. Los dos últimos suelen estar sin documentar y viven solo en la cabeza de usuarios y responsables de mantenimiento. Leer el código fuente muestra cómo funciona el software; no le dice por qué existe, qué comportamiento es esencial frente a accidental, ni qué soluciones han inventado los usuarios para salvar sus carencias.

Por eso no nos basamos solo en el análisis del código. Entrevistamos y observamos a las personas que usan el sistema, vemos cómo trabajan realmente y reconstruimos los requisitos y procesos a partir de ahí. En un proyecto, el cliente no quiso divulgar el código fuente por motivos de seguridad; todo el análisis, exitoso, se llevó a cabo mediante el estudio de documentos, grabaciones de pantalla, entrevistas y observación in situ. El código es una fuente más entre varias, y a menudo no la decisiva.

Reconstruir requisitos y procesos de negocio es lo que decide si las modernizaciones tienen éxito o fracasan. Para abordarlo, documentamos un enfoque para analizar un sistema heredado de una década de antigüedad y sin documentación [3] y lo publicamos en un artículo revisado por pares. La suite operacionaliza ese enfoque y le añade la aceleración de la IA.

Aplicamos cuatro métodos complementarios de recopilación de datos y los canalizamos hacia tres artefactos de análisis:

• Recopilación de datos: análisis documental (filtrar la masa de archivos existentes hasta los pocos que importan), análisis de vídeo/grabaciones de pantalla (una demostración grabada del sistema suele ser la fuente más rica), entrevistas semiestructuradas con desarrolladores y usuarios, e indagación contextual (observación in situ de los usuarios realizando su trabajo real).
• Análisis de datos: domain storytelling (narrativas visuales, en lenguaje sencillo, de quién hace qué con el sistema, legibles tanto por perfiles técnicos como no técnicos), mapeo de user stories / journeys y modelos de procesos BPMN de los procesos de negocio que soporta el sistema.

Dos lecciones de ese trabajo determinan cómo llevamos a cabo cada proyecto:

• La observación supera a las entrevistas para detectar carencias. Observar a los usuarios trabajar revela de forma fiable pasos del flujo de trabajo (y deficiencias del software) que las entrevistas por sí solas pasan por alto, incluidas las llamadas de teléfono y las hojas de cálculo paralelas que la gente usa para sortear el sistema.
• Cierta redundancia es una ventaja, no un desperdicio. Describir el mismo proceso como domain story y como diagrama BPMN no es duplicar por duplicar; las dos vistas se validan mutuamente y cada una se dirige a un interlocutor distinto; eso construye el entendimiento compartido que necesita una decisión de modernización.

Qué aspecto tiene realmente un entregable. Una domain story, por ejemplo, es un diagrama de una sola página en lenguaje de dominio sencillo: flechas numeradas muestran que un ingeniero de pruebas extrae la orden de fabricación de una máquina del sistema, registra las tolerancias medidasy se lo pasa a control de calidad para su aprobación, legible tanto por un experto de planta como por un arquitecto. El diagrama BPMN correspondiente expresa el mismo proceso en una notación que su organización de TI puede entregar a un motor de flujos de trabajo. Además, recibe un glosario de dominio, una visión general de requisitos y, cuando el código fuente está disponible, un grafo de dependencias entre componentes generado por una herramienta determinista construida con IA.

Cómo acelera la IA este trabajo. La IA cambia la economía de la reconstrucción de requisitos y procesos, pero no su naturaleza. Filtra cientos de documentos hasta los pocos que importan, transcribe y analiza horas de grabaciones de pantalla, redacta la primera versión de una domain story o de un modelo de proceso BPMN en minutos y contrasta los requisitos reconstruidos con el código y la base de datos en busca de contradicciones. Lo que no hace es decidir qué necesita realmente el negocio; ese criterio queda en manos de las personas. El efecto: la costosa fase de análisis, de varias semanas, se comprime a días, mientras se preserva la validación por parte de los expertos de dominio que la mantiene honesta.

El conocimiento experto no es opcional aquí. Sus expertos de dominio actúan como el ancla semántica que valida cada requisito reconstruido y nos permite interpretar correctamente los términos de dominio antiguos; el mismo papel que mantiene honesta la salida de la IA en el resto de la suite.

Generación y transformación basada en especificaciones: el motor de ejecución

Mientras la ingeniería de requisitos reconstruye qué debe hacer el sistema, este componente es el cómo de realizar el cambio. La generación y transformación basada en especificaciones es el motor de ejecución de la suite: generación inteligente de código (incluidas actualizaciones automatizadas de versiones de lenguaje y de framework), migración entre lenguajes y entre frameworks, y generación de código directamente a partir de los requisitos reconstruidos. Siempre se ejecuta dentro del Harness (los controles de arquitectura y calidad restringen cada cambio) y frente a la validación legacy-as-oracle descrita más abajo, de modo que la velocidad nunca se logra a costa del comportamiento.

Pero las partes difíciles de la ejecución rara vez son la migración en sí; son los riesgos que la rodean. Los abordamos de forma explícita en lugar de esperar que no aparezcan:

• Migración de datos y de esquemas. La evolución del esquema, los problemas de calidad de datos y la coexistencia de modelos de datos antiguos y nuevos se gestionan con capas anticorrupción y, cuando es necesario, estrategias de dual-write/backfill, validadas por las mismas pruebas diferenciales que aplicamos al código.
• Requisitos no funcionales. La latencia, el rendimiento, la disponibilidad, la seguridad, la privacidad y la mantenibilidad se capturan como escenarios de atributos de calidad en la evaluación y se aplican como funciones de aptitud, de modo que un segmento no está «terminado» hasta que los cumple, no simplemente cuando pasa las pruebas funcionales.
• Puesta en producción y reversión. Como los segmentos coexisten tras la frontera del strangler, hacemos la transición con feature flags / ejecución en paralelo y podemos revertir un segmento sin una marcha atrás en todo el sistema.
• Observabilidad. Cada segmento modernizado se entrega con registro, métricas y comprobaciones de estado, de modo que las regresiones se detectan en producción, no las detectan los usuarios.
• Riesgo de dependencias y de fin de vida útil. Los frameworks sin soporte, las restricciones de licencias y el fin de vida útil del proveedor se capturan en la fase de descubrimiento y se tienen en cuenta en la decisión de Renovar/Rehacer/Reemplazar.

Legacy-as-oracle: demostrar que el código nuevo se comporta como el antiguo

Este es el mecanismo que nos permite ir rápido sin romper el comportamiento:

1. Antes de cambiar nada, capturamos el comportamiento real del sistema heredado como pruebas de caracterización (pruebas golden-master), a menudo generadas a alto nivel (REST o interfaz de usuario).
2. Durante la transformación ejecutamos pruebas diferenciales: las mismas entradas se envían tanto al sistema heredado como al nuevo componente, y cualquier divergencia en la salida hace fallar la compilación.
3. El sistema heredado es, por tanto, tanto lo que reemplazamos como la implementación de referencia que demuestra que el reemplazo es fiel.

Una nota sobre cómo evitar errores: las pruebas golden-master capturan el comportamiento actual , incluidos los defectos. Nos protegemos de consagrar errores en silencio combinando las pruebas generadas con una revisión por expertos de dominio de los requisitos reconstruidos: cuando el comportamiento es incorrecto, se corrige a nivel de requisito, no se congela como oráculo.

Stacks tecnológicos en los que ya lo hemos hecho realmente: .NET Framework / C#, AngularJS y Angular moderno, TypeScript, migraciones de escritorio (WinForms/WinUI) → nube/web, y código PLC industrial con HMI de WinCC.