Cuando hereda un sistema sin código fuente ni documentación — Procedimiento práctico para operarlo y mantenerlo sin detenerlo

«La empresa que lo desarrolló ya no existe», «la persona que lo creó se fue de la empresa y no se le puede contactar», «en el servidor están el ejecutable y la base de datos, pero no aparecen ni el código fuente ni la documentación» — en las consultas sobre sistemas empresariales de pymes, esta situación no es en absoluto excepcional. Aun así, el sistema sigue funcionando hoy, y el negocio depende de él.

En esta situación, la peor decisión es empezar modificaciones a tientas o cambios improvisados en el entorno solo porque «no se entiende bien cómo funciona». Un sistema sin código fuente no ofrece ninguna garantía de poder repararse cuando se rompe. Por otro lado, concluir de entrada que «no se puede hacer nada, solo queda reconstruirlo por completo» también es precipitado. Existen medios para recuperar las especificaciones aunque no haya documentación, y en algunos casos es posible leer el contenido interno aunque no haya código fuente. Este artículo organiza, en el orden en que se aplican en la práctica, los pasos para lograr operar y mantener un sistema partiendo de la nada.

1. Conclusión inicial

• Lo primero que debe hacerse no es la modificación, sino la «preservación del estado actual». El propio entorno de producción en funcionamiento es el activo más importante. Obtenga una copia de la imagen de disco (por ejemplo, convirtiéndola en máquina virtual con Disk2vhd) y una copia de la base de datos, y confirme que puede restaurarlas antes de continuar.¹
• Aunque no haya documentación, las especificaciones se pueden recuperar. Los principales materiales son las entrevistas a los usuarios del negocio, las pantallas e informes, el esquema de la base de datos, los registros (logs) y la observación del comportamiento real con Process Monitor.²
• La posibilidad de recuperar el código fuente varía enormemente según la pila tecnológica. Si el sistema está hecho en .NET, se puede leer bastante bien con descompiladores como ILSpy, mientras que en código nativo como VB6 o C++ no es realista esperar recuperarlo.³⁴
• La descompilación implica cuestiones legales. Conforme al artículo 30-4 de la Ley de Derechos de Autor, se entiende que el uso con fines de investigación y análisis está permitido en principio, pero es indispensable revisar el contrato (las cláusulas de licencia de uso).⁵
• No espere a «entenderlo todo por completo». Priorice la comprensión de los puntos cuya interrupción detendría el negocio y de aquellos donde el cambio sea inminente, y realice los cambios de uno en uno, en pasos pequeños y reversibles.
• El contrato de mantenimiento debe ser, por regla general, de cuasi-mandato. No se puede prometer la responsabilidad de finalización (contrato de obra) para la investigación de un sistema cuyo funcionamiento interno se desconoce. Contrate por separado la fase de investigación y la fase de modificación.

Este artículo está organizado siguiendo el orden que se sigue en la práctica. La panorámica general es la siguiente.

flowchart TD
    A["Capítulo 3 Preservación<br/>Congelación de cambios · imagen de disco<br/>Copia de la BD y verificación de restauración"] --> B["Capítulo 3 Inventario<br/>Ejecutables · inicio automático · tareas<br/>Configuración · integraciones · cuentas"]
    B --> C["Capítulo 4 Recuperación de especificaciones<br/>Entrevistas · pantallas e informes<br/>Esquema de BD · observación del comportamiento real"]
    C --> D["Capítulo 5 Viabilidad técnica<br/>Evaluación de la pila tecnológica<br/>Descompilación y verificación legal"]
    D --> E["Capítulo 6 Decisión de estrategia<br/>Prolongar · envolver · reconstrucción parcial · reconstrucción total"]
    E --> F["Capítulo 7 Transición a operación<br/>Entorno de verificación · registro de cambios · monitoreo · contrato"]
    C -.->|"El registro de especificaciones recuperadas<br/>es un activo sin importar la estrategia elegida"| E

Figura 1: Flujo general de la transferencia y los capítulos correspondientes

La duración de cada etapa varía mucho según el tamaño del sistema (número de pantallas, informes y procesos por lotes), la pila tecnológica, el tiempo que el área de negocio pueda dedicar a las entrevistas y el objetivo que se fije para «hasta dónde es suficiente entender», por lo que no es posible establecer una referencia uniforme antes de empezar. El único atajo para mejorar la precisión de la estimación es terminar primero el inventario del capítulo 3 y contar el número de elementos objetivo. Hasta que no se obtenga ese número, no se puede estimar la duración de la recuperación de especificaciones. Dicho de otro modo, el inventario es una etapa que debe cerrarse en poco tiempo: si se alarga, ninguna planificación posterior podrá sostenerse.

2. Por qué se llega a la situación de «no hay nada»

Antes de pensar en cómo actuar, conviene confirmar en qué patrón se encuentra su empresa, ya que eso permite intuir qué pistas podrían quedar.

El último patrón suele pasarse por alto, pero en la práctica hay que tratarlo igual que si «no hubiera código fuente». Un incidente típico y frecuente es modificar el sistema dando por buena una versión antigua del código, cuando en realidad el ejecutable de producción tenía años de correcciones adicionales. Aunque se encuentre el código fuente, no confíe en él hasta compilarlo y cotejarlo con el ejecutable de producción.

En cualquiera de los patrones, vale la pena empezar por buscar el contrato, el albarán de entrega y el acta de recepción. Si en ellos consta la titularidad de los derechos de autor o la obligación de entregar el código fuente, servirán de base para negociaciones posteriores y para el análisis legal.

3. Qué hacer en la primera semana — Preservación del estado actual e inventario

3.1 Congelación de cambios

Hasta que termine la investigación, la regla es no tocar el servidor ni los equipos afectados. Ideas como «actualicemos el sistema operativo por si acaso» o «limpiemos los archivos que parecen no usarse» pueden resultar fatales. Como no hay código fuente, no existe la opción de «repararlo» si algo se rompe. También conviene considerar poner bajo control el momento de aplicación de las actualizaciones, para que las actualizaciones automáticas (Windows Update, cambios de comportamiento del antivirus) no modifiquen el entorno por su cuenta.

3.2 Copia de seguridad — Duplicar el propio entorno como activo

Una copia de seguridad a nivel de archivo no es suficiente. En este tipo de sistemas, la configuración del sistema operativo, el registro, el runtime y la propia ubicación de los archivos pueden formar parte, todos ellos, de la «razón por la que funciona», así que hay que preservar la imagen de disco completa.

En la práctica, la herramienta más usada es Disk2vhd, de Sysinternals. Permite convertir el sistema en funcionamiento, sin desconectarlo, en un archivo VHD/VHDX consistente en un momento dado, gracias a la función de instantáneas de volumen de Windows (VSS: Volume Shadow Copy Service, servicio de instantáneas de volumen), y sirve de base para un entorno de verificación que se inicia como máquina virtual en Hyper-V.¹ Su ventaja es que permite avanzar a la vez en la mitigación de la obsolescencia del servidor físico y en la obtención de un entorno de verificación (cabe señalar que, en el caso de Windows con licencia OEM, la migración a un entorno virtual puede no estar permitida por los términos de la licencia, por lo que es necesario confirmar el tipo de licencia¹).

Disk2vhd es una herramienta sencilla, de una sola pantalla, pero una elección equivocada produce «una imagen que no arranca». Siga este orden.¹

1. Prepare el destino de salida. El VHD/VHDX se puede crear incluso en el propio volumen que se está convirtiendo, pero la documentación oficial indica expresamente que el rendimiento es mejor si se envía a un disco distinto del que se está convirtiendo (una unidad externa, un NAS, etc.). Calcule un espacio libre igual o superior a la suma del espacio usado en los volúmenes seleccionados.
2. Verifique BitLocker. Disk2vhd no admite la conversión de volúmenes con BitLocker habilitado. Si el volumen objetivo lo tiene activado, desactive BitLocker de antemano y espere a que termine el descifrado antes de ejecutar la herramienta.
3. Elija los volúmenes que va a incluir. Si ejecuta la herramienta con el sistema iniciado, se muestra la lista de volúmenes de ese sistema. Se crea un VHD por cada disco en el que existan los volúmenes seleccionados; se conserva la estructura de particiones, pero solo se copia el contenido de los volúmenes seleccionados. Por lo tanto, si quiere poder arrancarlo en modo de verificación, seleccione tanto el volumen donde está Windows (normalmente C:) como la partición de sistema necesaria para el arranque (la partición reservada del sistema o la partición de sistema EFI). Si excluye los volúmenes puramente de datos, ahorrará espacio y tiempo.
4. Ejecútelo por línea de comandos si lo necesita. Si quiere lanzarlo por la noche, por ejemplo, puede convertirlo en un script con la forma disk2vhd <unidad:> [unidad:] ... <archivo de salida>. Para incluir todos los volúmenes, especifique *, como en disk2vhd * e:\backup\snapshot.vhdx.
5. Realice el arranque de verificación en Hyper-V. Cree una máquina virtual en el Administrador de Hyper-V y añada el VHD resultante a la configuración como disco IDE. En el primer arranque, Windows detectará el hardware de la máquina virtual e instalará automáticamente los controladores si ya están en la imagen; si no, instale los componentes de integración de Hyper-V.
6. No lo monte en la máquina de origen para arrancarlo. Si monta el VHD en el mismo sistema, Windows le asignará una nueva firma de disco para evitar el conflicto con la firma del disco original. Como los datos de configuración de arranque (BCD) hacen referencia al disco por su firma, si en ese estado intenta arrancar la máquina virtual, fallará porque no podrá encontrar el disco de arranque. Realice siempre el arranque de verificación en otra máquina (el host de Hyper-V).

Asimismo, obtenga la copia de seguridad de la base de datos con los medios estándar del propio DBMS. Y lo más importante es restaurar realmente desde la copia de seguridad y confirmar que arranca. Una copia de seguridad sin prueba de restauración es solo un seguro que se cree tener, pero no se tiene en realidad. Sin embargo, como la imagen restaurada conserva tal cual la configuración de conexión y las tareas programadas de producción, la comprobación de arranque debe hacerse siempre aislada de la red (más detalles en el capítulo 7). Si por descuido se arranca conectada, el entorno que se pretendía usar para verificación terminará actualizando la base de datos de producción o los sistemas con los que se integra.

3.3 Inventario — Elaborar una lista de lo que está en funcionamiento

A continuación, identifique de forma sistemática los componentes del sistema. Esta es una tarea de exhaustividad, no de intuición.

Cuando no se sepa «dónde están» los archivos de configuración o los destinos de salida, el atajo es observar con Process Monitor los accesos del proceso a archivos y al registro. Las rutas que la aplicación realmente lee y escribe aparecen tal cual en una lista.²

4. Aunque no haya documentación, las especificaciones se pueden recuperar

Una vez que el inventario aclara «qué hay», el siguiente paso es recuperar «qué hace». Los materiales ya están disponibles.

• Entrevistas a los usuarios del negocio — La mejor documentación es la que está en la cabeza de quienes usan el sistema todos los días. Siguiendo el flujo del trabajo diario, mensual y anual, pregunte en qué pantalla se ingresa qué y qué sale como resultado. En particular, los procesos anuales (cierre contable, inventario, actualización de año fiscal) a veces ni el propio responsable los recuerda bien, y suelen ser el punto donde ocurren incidentes en la primera ejecución tras la transferencia.
• Pantallas e informes — Documente todas las pantallas y todos los informes con capturas de pantalla y muestras reales en un registro. Solo con la correspondencia entre los campos de entrada y los de salida ya se empieza a ver bastante bien el esqueleto del proceso.
• Esquema de base de datos y datos — La definición de tablas, las restricciones y los datos reales de los valores de código son fósiles de las reglas de negocio. Observaciones como «este indicador solo usa tres valores» revelan especificaciones que no se ven desde la pantalla.
• Registros de la aplicación y del sistema — Si la aplicación tiene sus propios registros, se puede leer en ellos el flujo del proceso, y del registro de eventos de Windows se pueden inferir las tendencias de errores pasados.
• Observación del comportamiento real — Si registra con Process Monitor los accesos a archivos, al registro y a la red, puede confirmar, sin necesidad de código fuente, la correspondencia entre entradas y salidas: por ejemplo, que «este proceso de fin de mes lee un CSV de esta carpeta compartida y se comunica con este servidor de base de datos».² Sin embargo, con Process Monitor solo se conoce hasta la contraparte de la comunicación, no se ve qué tabla se actualizó ni cómo. A partir de ahí hay que identificarlo con las funciones de trazado y auditoría del propio DBMS (los eventos extendidos de SQL Server, por ejemplo) o cotejando el contenido de la base de datos antes y después del proceso.

Lo importante aquí es no intentar documentar todas las funciones por igual. El objetivo no es una enciclopedia, sino la continuidad de la operación, así que priorice los «procesos cuya interrupción detiene el negocio», los «procesos que están dando errores» y los «puntos que necesitarán cambios pronto», y vaya acumulando en el registro lo que investigue.

El modelo de entrevista — A quién, qué y cómo registrar

«Preguntar a los usuarios» es fácil de decir, pero si no se decide de antemano a quién y qué preguntar, la conversación termina siendo solo charla. En la práctica, lo más seguro es dividirla en las siguientes tres capas y dedicar un tiempo distinto a cada una.

Reutilice siempre las mismas preguntas. Las siguientes diez preguntas sirven de base y funcionan incluso al pasar de un sistema a otro.

1. En este sistema, ¿qué operaciones se realizan siempre a diario? ¿A qué hora aproximadamente y con qué volumen?
2. ¿Hay operaciones que se realizan solo mensual o anualmente (cierre, contabilidad, inventario, actualización de año fiscal, etc.)? ¿Cuándo se hizo la última vez y quién la hizo?
3. ¿Cuáles son el papel, el archivo o el correo de origen de la entrada? ¿De dónde vienen?
4. ¿Qué produce este sistema como salida (informes, CSV, envíos externos) y a dónde va después?
5. Si el sistema se detuviera, ¿cuántas horas podría resistir el negocio? ¿Se podría sustituir con trabajo manual en ese caso?
6. ¿Existe alguna «leyenda» del tipo «esta operación en particular no se debe hacer»? ¿Se conoce el motivo?
7. ¿Hay algo que actualmente se compense con trabajo manual (transcripción, recálculo en Excel, verificación visual, etc.)?
8. ¿Hubo errores o problemas en el último año? ¿Cómo se resolvieron?
9. ¿Qué pantallas o funciones no se usan? ¿Desde cuándo no se usan?
10. Si se pudiera arreglar algo, ¿cuál es el problema que más molesta?

Decida también cómo registrar las respuestas. El punto clave es anotar las respuestas vinculadas a nombres propios, como el nombre de la pantalla, del informe o de la tabla; si se baja hasta el nivel de detalle de «imprimir el informe mensual de ventas desde la pantalla de resumen de ventas mensual (F050)» en lugar de «se totaliza a fin de mes», se puede cotejar con la tabla de inventario del capítulo 3 y con la investigación posterior de la base de datos. Si es posible, grabe la conversación y concéntrese, en el momento, en anotar los nombres propios y el orden de las operaciones. La respuesta a la pregunta 5 alimenta la decisión de estrategia del capítulo 6, y las respuestas a las preguntas 6 y 7 son pistas de dónde se esconden especificaciones ocultas.

5. Qué se puede hacer técnicamente sin código fuente

Hasta qué punto se puede esperar «leer el contenido interno» depende casi por completo de con qué esté hecho el sistema. Fije sus expectativas después de estimar la pila tecnológica a partir de las propiedades del ejecutable y de la composición de los DLL.

Antes de continuar, definamos brevemente los términos que se usan en este capítulo.

En el caso de una aplicación .NET distribuida en el formato IL normal, la situación es bastante favorable: el código C# obtenido por descompilación resulta suficientemente práctico para entender el procesamiento. Sin embargo, tal como indica expresamente la documentación oficial, la información innecesaria en tiempo de compilación, como comentarios, nombres de variables locales y espacios en blanco, se pierde, por lo que debe considerarse no un sustituto del código fuente original, sino «material para entender el funcionamiento».³ También hay excepciones. Si se ha aplicado ofuscación, la dificultad de descifrado aumenta mucho, y como los binarios publicados con Native AOT no incluyen IL, no se sostiene la expectativa de que «por estar hecho en .NET, se puede leer». Native AOT es una modalidad de publicación introducida en .NET 7, y la documentación oficial indica expresamente que «en el momento de la publicación, el compilador anticipado convierte el IL a código nativo» y que «las aplicaciones Native AOT no usan el compilador JIT en tiempo de ejecución».⁷ Es decir, el propio objeto que leería el descompilador no queda en el resultado final. Al evaluar la pila tecnológica, confirme no solo el lenguaje de desarrollo, sino también el formato de distribución.

Si el PDB (archivo de símbolos) se conserva junto al ejecutable, en algunos casos se pueden recuperar los nombres de las funciones e incluso el código fuente mismo (si tiene fuente incrustada). Qué contiene y qué se puede esperar se explica en «¿Qué es el PDB (Program Database)?».

Consideraciones legales — La descompilación, «solo después de investigar»

Lo que se puede hacer técnicamente y lo que está permitido hacer son cosas distintas. La ingeniería inversa, incluida la descompilación, plantea cuestiones bajo la Ley de Derechos de Autor; conforme al artículo 30-4 de la Ley de Derechos de Autor (uso que no tiene como finalidad el disfrute de los pensamientos o sentimientos expresados en la obra), introducido en la reforma de 2018 (Heisei 30), se entiende que la reproducción o adaptación con fines de investigación y análisis de un programa está permitida en principio dentro del límite que se considere necesario. Sin embargo, el propio artículo incluye la salvedad de que «esto no se aplica cuando ello perjudique injustamente los intereses del titular de los derechos de autor», por lo que, por ejemplo, usar los resultados del análisis para crear un producto competidor podría recibir una valoración distinta.⁵

Además, si el contrato de licencia de uso del software empaquetado o del entregable incluye una cláusula que prohíbe el análisis, queda pendiente la cuestión contractual de cómo interpretar su validez. Antes de proceder, revise las condiciones de licencia del software en cuestión y el contrato de desarrollo por encargo de aquel momento (la cláusula de titularidad de los derechos de autor), y consulte a un abogado si tiene dudas. Si el entregable es de titularidad de su propia empresa, este problema se simplifica considerablemente. Sobre cómo leer los contratos, puede consultar también «Cómo debe formalizarse el contrato de desarrollo por encargo y mantenimiento».

La argumentación jurídica en sí es terreno de los especialistas, pero los materiales que conviene reunir internamente antes de acudir a una consulta están bien definidos. Si completa de antemano los siguientes puntos, la decisión será más rápida.

6. Prolongar, envolver o reconstruir

Cuando ya se dispone del nivel de comprensión obtenido en la investigación y de las circunstancias del área de negocio, se define la estrategia. Aquí tampoco se debe partir de «reconstruir todo por defecto» ni de «dejarlo congelado por defecto»; conviene organizarlo con una tabla de decisión.

Los cuatro ejes de decisión son: los años de uso restantes, la frecuencia y el sesgo de las solicitudes de cambio, el impacto en el negocio si el sistema se detiene, y el nivel de comprensión recuperado en la investigación. Si se avanza hacia una reconstrucción total con un nivel de comprensión bajo, se pierde el «comportamiento que nadie puede explicar pero que es correcto para el negocio» del sistema antiguo. Aunque se opte por reconstruir, el registro de especificaciones recuperado en el capítulo 4 sirve directamente de base para la definición de requisitos, así que la inversión en la investigación no se desperdicia. En la migración, lo habitual es ejecutar en paralelo el sistema nuevo y el antiguo durante un periodo determinado y cotejar mecánicamente las salidas (informes, totales, archivos) frente a las mismas entradas.

Además, la decisión de prolongar o migrar según la tecnología concreta —como VB6 o Access— se trata en detalle en «Prolongación y migración de aplicaciones VB6 / Access», y la dependencia del modo IE en sistemas web internos se trata en «Guía para salir de la dependencia de sistemas en modo IE».

7. El régimen de operación y mantenimiento tras la transferencia

Cuando la estrategia es «continuar operando por el momento» (que es, en la práctica, la mayoría de los casos), seguir el siguiente modelo reduce los incidentes.

• Contar con un entorno de verificación — pero aislando siempre la red en el primer arranque — Si arranca como máquina virtual la imagen de disco creada en 3.2, obtendrá un entorno de verificación con la misma configuración que producción. Sin embargo, esa imagen conserva tal cual la cadena de conexión, las credenciales, las tareas programadas y los servicios de inicio automático de producción. Si se arranca conectada a la red, el proceso por lotes nocturno podría ejecutarse por duplicado y actualizar la base de datos de producción, se podrían reenviar correos o llamar a API externas. El primer arranque debe hacerse siempre con la NIC virtual desconectada o en una red aislada, deteniendo las tareas programadas y los servicios de inicio automático, reescribiendo los destinos de conexión para el entorno de verificación, y permitiendo la conexión solo en el alcance necesario.
• Cambios de uno en uno y de forma reversible — Ya sea un cambio de configuración o la aplicación de Windows Update, hágalo de uno en uno. Conserve la imagen previa al cambio y revierta si surge algún problema. Acompañe siempre el cambio con un registro de qué se modificó (bitácora de cambios).
• Haga crecer la documentación como «subproducto de lo investigado» — En lugar de emprender un proyecto para redactar especificaciones perfectas, añada al registro lo que vaya descubriendo cada vez que resuelva una incidencia o haga una modificación. Al cabo de un año de operación, la documentación estará completa empezando por las partes más importantes para el negocio.
• Configure el monitoreo — Monitoreo de disponibilidad, espacio libre en disco, registros de error y la detección de «el archivo que siempre debería generarse no se generó». Aunque no se pueda ver el interior de la caja negra, sí se pueden monitorear la entrada y la salida.
• Separe la investigación y la modificación en el contrato — Si se encarga el mantenimiento a un proveedor externo, como no se puede prometer responsabilidad de finalización para la investigación de un sistema cuyo interior se desconoce, lo saludable es dividir el contrato por fases: cuasi-mandato para la investigación y el mantenimiento, y contrato de obra (o cuasi-mandato orientado a resultados) para las modificaciones puntuales una vez definidas las especificaciones.

8. Resumen

• Al heredar un sistema sin código fuente ni documentación, antes que la modificación va la preservación del estado actual. Obtenga copias de la imagen de disco (con Disk2vhd, por ejemplo) y de la base de datos, y confirme que se pueden restaurar.
• Haga el inventario de los ejecutables, el inicio automático, las tareas programadas, la configuración, las integraciones y las cuentas, y elabore una lista con la visión general del sistema.
• Las especificaciones se pueden recuperar a partir de las entrevistas a los usuarios, las pantallas, los informes, el esquema de la base de datos, los registros y la observación del comportamiento real con Process Monitor. Priorice las partes con mayor impacto en el negocio, no todas las funciones por igual.
• La posibilidad de recuperar el contenido depende de la pila tecnológica. .NET se puede leer bastante bien mediante descompilación, pero no sustituye al código fuente original. Antes de proceder, verifique el sentido del artículo 30-4 de la Ley de Derechos de Autor, además de las condiciones de licencia y los contratos.
• Decida la estrategia entre «prolongar, envolver, reconstrucción parcial o reconstrucción total» según los años de uso restantes, la frecuencia de cambios, el impacto en el negocio y el nivel de comprensión. Las especificaciones recuperadas en la investigación se convierten en un activo sea cual sea el camino elegido.
• En la fase de operación, el modelo básico es: entorno de verificación, cambios de uno en uno, bitácora de cambios, monitoreo de entrada y salida, y contrato de cuasi-mandato.

Artículos relacionados

• ¿Qué es el PDB (Program Database)? — Entender la información de depuración, los símbolos y Source Link
• Guía práctica de Process Monitor
• Prolongación y migración de aplicaciones VB6 / Access — Tabla de decisión entre conservar, envolver y reemplazar
• Guía para salir de la dependencia de sistemas en modo IE
• Cómo debe formalizarse el contrato de desarrollo por encargo y mantenimiento — Aprender de “Transacciones y contratos modelo” de la IPA la diferencia entre cuasi-mandato y contrato de obra
• Lo que conviene organizar antes de encargar el desarrollo externo de una aplicación Windows

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de la investigación del estado actual de sistemas empresariales sin código fuente ni documentación (análisis de ejecutables, bases de datos y comportamiento real), la recuperación de especificaciones a partir del comportamiento, la definición de la estrategia de prolongación o migración, y la operación y el mantenimiento posteriores. También son bienvenidas las consultas desde la etapa en la que aún «no se sabe por dónde empezar».

• Aprovechamiento de activos existentes y apoyo a la migración
• Modificación y mantenimiento de software Windows existente
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se puede encargar el mantenimiento o la modificación de un sistema aunque no tenga código fuente?

Sí, se puede encargar. Sin embargo, la forma de proceder cambia respecto al mantenimiento habitual. Lo realista es, primero, preservar y respaldar el entorno en funcionamiento y, después, establecer una fase de investigación que recupere las especificaciones a partir del análisis de pantallas, informes, base de datos, registros y ejecutables, avanzando a la modificación o al desarrollo de funciones periféricas dentro del alcance de la comprensión obtenida en esa fase. Como la investigación es un trabajo cuyo resultado no se puede prometer de antemano, lo habitual es llevarla adelante mediante un contrato de cuasi-mandato, en lugar de un contrato de obra que exige responsabilidad de finalización.

¿No es ilegal la descompilación (ingeniería inversa) de un ejecutable?

No es ilegal de manera uniforme. Conforme al artículo 30-4, introducido en la reforma de la Ley de Derechos de Autor de 2018 (Heisei 30), se entiende que un «uso que no tiene como finalidad el disfrute de los pensamientos o sentimientos expresados en la obra», como la investigación y el análisis de un programa, está permitido en principio dentro del límite que se considere necesario. Sin embargo, quedan excluidos los casos en que «se perjudiquen injustamente los intereses del titular de los derechos de autor», y también queda pendiente la cuestión de cómo tratar los casos en que el contrato de licencia de uso prohíbe el análisis. Antes de proceder, revise las condiciones de licencia y el contrato de desarrollo por encargo de aquel momento, y consulte a un abogado u otro especialista si tiene dudas.

La empresa desarrolladora quebró y no puedo conseguir el código fuente. ¿Qué debo hacer?

Primero, revise los contratos y los entregables anteriores. Si el contrato de desarrollo por encargo establece la titularidad de los derechos de autor o la entrega del código fuente, eso servirá de base para obtenerlo o usarlo. Si hay algún relacionado con quien se pueda contactar, también vale la pena explorar la posibilidad de negociar su obtención. Sin embargo, en la práctica es importante no detenerse en «al final no se pudo conseguir»: se recomienda partir de la premisa de que no se podrá obtener e iniciar en paralelo la preservación y el respaldo del entorno en funcionamiento junto con la recuperación de especificaciones a partir del comportamiento y de la base de datos.

¿Por dónde debo empezar con un sistema que no tiene documentación?

Antes que la modificación va, primero, la preservación del estado actual. Obtenga la imagen de disco del entorno de producción en funcionamiento y una copia de la base de datos, y confirme que se pueden restaurar. Después, realice el inventario de los ejecutables, el inicio automático, las tareas programadas, la configuración, las integraciones y las cuentas, y elabore una lista con la visión general del sistema. A partir de ahí, lo habitual es documentar las especificaciones centrándose en las partes importantes para el negocio, mediante entrevistas a los usuarios y la observación de las pantallas, los informes y el esquema de la base de datos.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.