Qué hace la aplicación
Las pantallas muestran una parte. También hay procesos nocturnos, intercambios de ficheros y tareas manuales que completan el trabajo.
Software y bases de datos
Una aplicación con años de uso suele guardar decisiones que ya nadie recuerda. El código y los datos ayudan a recuperar esa historia y a entender qué debe conservarse cuando llega el momento de cambiar.
En pocas palabras
Es un sistema heredado que sigue en uso y puede resultar difícil de mantener, comprender o integrar. Su antigüedad es solo una parte del problema: también importan la documentación, las dependencias y el conocimiento que conserva el equipo. Antes de cambiarlo conviene averiguar qué trabajo sostiene.
El mapa del tema
Las pantallas muestran una parte. También hay procesos nocturnos, intercambios de ficheros y tareas manuales que completan el trabajo.
Un código o una fecha pueden tener un significado que no se deduce de su nombre. Las personas que utilizan la información ayudan a interpretarla.
Cambiar una tabla puede afectar a una consulta, un informe o una aplicación distinta. Conocer esas relaciones permite preparar el cambio y sus comprobaciones.
Un expediente existe en la base de datos, pero no aparece en el informe. La consulta se ejecuta sin errores. El problema puede estar en un filtro, en el estado del expediente, en cómo se unen las tablas o en el tratamiento de un valor nulo.
Revisar solo la sintaxis no basta. Hay que recuperar la pregunta que el informe debía responder y contrastar casos concretos: qué datos deberían aparecer, cuáles deben quedar fuera y por qué.
SQL permite consultar y modificar datos. PL/SQL es la extensión de Oracle que añade construcciones de programación y permite organizar lógica en procedimientos, funciones y paquetes. Una aplicación Java puede llamar a esos programas de la base de datos.
Por eso una regla puede estar repartida entre varias capas. Una validación en la pantalla, otra en Java y una tercera en un procedimiento pueden participar en la misma operación. Entender el comportamiento exige seguir ese recorrido.
Antes de transformar un dato conviene aclarar qué representa. Una fecha histórica, un código que dejó de usarse o un valor aparentemente vacío pueden explicar decisiones que el sistema nuevo también necesita respetar.
La modernización puede hacerse por etapas: mejorar una función, sustituir un módulo o preparar una migración. La decisión depende de la utilidad, el riesgo y el esfuerzo. Los casos de prueba deben permitir comprobar que el negocio sigue obteniendo el resultado esperado.
Preguntas frecuentes
La edad no decide por sí sola. Hay que valorar si resuelve la necesidad, si puede mantenerse y qué riesgos o límites introduce. A veces conviene sustituirlo; otras, documentar, probar o mejorar una parte.
Sí. La base de datos comprueba que puede ejecutar la consulta, pero no sabe si responde a la pregunta del negocio. Los filtros, las relaciones entre tablas y los valores nulos pueden cambiar el resultado sin provocar un error de ejecución.
Qué aplicaciones y procesos la utilizan, qué significado tienen los datos y qué resultados deben conservarse. Identificar dependencias y preparar ejemplos de comprobación ayuda a detectar consecuencias antes de aplicar el cambio.
Seguir leyendo
Automatización y supervisión humana
De los triggers a los agentes de IA: deuda cognitiva, deuda de intención y continuidad de contexto. Con Bainbridge, Endsley, Elish y Storey.
Análisis funcional
Por qué descubrir y acordar las reglas es tan importante como escribir el código.
Sistemas legacy
Qué conviene descubrir en una aplicación antes de decidir cómo modernizarla.
Bases de datos
Las reglas que se esconden en vistas, consultas y programas de base de datos.
Del contenido a la práctica
La línea de programación y bases de datos trabajará con Java, SQL y PL/SQL a partir de problemas completos. En Formación se indicará qué materiales están disponibles y cómo plantear una propuesta para un grupo.
Ver recursos y propuestas