Migrar RPG de formato fijo y la frontera del formato libre

El RPG de formato fijo y el RPG de formato libre pueden compilarse en la misma partición IBM i, tocar los mismos archivos físicos y usar el mismo vocabulario de negocio. Aun así, son dos trabajos de migración distintos. Tratar la diferencia como un detalle de formato produce una estimación que parece ordenada y falla en cuanto el equipo encuentra indicadores, especificaciones de entrada o un programa cuyo flujo de control vive en parte dentro del ciclo generado por el compilador.

Una estimación creíble empieza por preguntar dónde está codificado el comportamiento. En un programa procedural de formato libre, buena parte aparece en sentencias que un ingeniero moderno puede seguir. En el código antiguo de formato fijo, las columnas, el orden de las especificaciones, los indicadores que identifican registros, los cortes de nivel y las condiciones de salida pueden contener significado. La migración debe recuperar ese significado antes de que alguien pueda poner un precio sensato a la reescritura.

Las columnas forman parte del programa

En RPG de formato fijo, la posición horizontal es sintaxis, así que una herramienta de migración no puede normalizar espacios antes de entender el código fuente. La referencia ILE RPG de IBM indica que el tipo de especificación ocupa la posición 6 en código limitado por columnas: H para control, F para archivos, D para definiciones, I para entrada, C para cálculos, O para salida y P para procedimientos. Otros campos también ocupan posiciones prescritas. Un carácter desplazado a la columna equivocada puede cambiar una operación, una condición de indicador o incluso si el compilador lee la línea.

Esto cambia la ingestión. Un analizador debe conservar el ancho original del registro, los campos de secuencia, los tabuladores, el CCSID del miembro fuente y los límites de los miembros copiados. Exportar un miembro por una ruta que expanda tabuladores o recorte espacios finales puede destruir pruebas antes de iniciar el análisis. El registro fuente sin modificar debe tratarse como un artefacto y la versión para visualizarse debe derivarse de él, nunca al revés.

Una comprobación útil de entrada registra tanto la línea original como una regla de columnas. Por ejemplo, un informe de inventario debería mostrar la siguiente salida, aunque la extracción real se ejecute en IBM i:

member=ORDRPT line=184 bytes=80 spec=C cond_1=03 cond_2=N04 opcode=EXCPT
000001  C   03N04             EXCPT    ORDTOTAL
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

El formato del informe no es lo importante. Hay que capturar 03, N04, EXCPT y ORDTOTAL como campos distintos y con sus posiciones originales. Un analizador de texto genérico ve elementos léxicos. Uno que entiende RPG ve un cálculo condicionado por un indicador encendido y otro apagado, seguido de una operación de salida excepcional cuya definición puede estar mucho más abajo en el miembro.

El RPG de formato libre elimina gran parte de esa dependencia posicional. En código totalmente libre, **FREE aparece en la columna 1 de la primera línea y las demás sentencias pueden extenderse más allá de la antigua zona limitada. Sentencias como ctl-opt, dcl-f, dcl-s y dcl-proc muestran su función mediante una palabra clave y terminan en punto y coma. Resultan más fáciles de analizar, pero no demuestran que el programa sea procedural ni que esté libre de construcciones heredadas. La sintaxis es la primera clasificación, no la última.

Los indicadores forman una red oculta de control

Los indicadores numerados condensan estado, condiciones y efectos secundarios en dos caracteres. Un cálculo fijo puede probar indicadores en sus columnas de condición y activar indicadores de resultado alto, bajo o igual en otras columnas. Las especificaciones de entrada pueden activar indicadores de identificación de registro, nivel de control y campo. Las operaciones de archivo pueden activar indicadores de error o fin de archivo. Las especificaciones de salida pueden usar esos estados para decidir si emiten un registro o una línea impresa.

Por eso sustituir *IN03 por un booleano llamado indicator03 es transliteración, no modernización. El nombre conserva la ubicación de almacenamiento y pierde la razón de que exista. La migración debe construir un grafo de definiciones y usos: todos los lugares que pueden activar el indicador, cada operación condicionada por él, cada reinicio y cada límite que atraviesa aún activo. Solo entonces puede decidirse si significa customerChanged, writeTotals, recordFound, validationFailed o varias cosas sin relación reutilizadas en momentos diferentes.

La reutilización de indicadores es el caso incómodo que ocultan los conteos de líneas. Un indicador puede significar algo en cálculos de detalle, borrarse y significar otra cosa dentro de una subrutina. Una búsqueda global informa de dos grupos, pero no demuestra que sean independientes. El analista debe incluir el orden de llamadas, la fase del ciclo y los efectos de las operaciones de archivo. Si un valor cruza un límite EXSR o sobrevive hasta los cálculos de totales, un cambio de nombre informal puede unir estados que el original separaba en el tiempo.

IBM documenta *IN como una matriz que abarca los indicadores numerados y advierte que valores distintos de cero, uno, *OFF o *ON vuelven impredecibles las pruebas posteriores. Este detalle importa al convertir porque algunos programas manipulan secciones de la matriz de indicadores como datos. Un destino moderno no debería reproducir una matriz mágica de 99 booleanos salvo que una frontera lo exija por compatibilidad. Debe descodificar las escrituras de la matriz, dar nombre a los estados buscados y fijar el comportamiento ambiguo con pruebas antes de retirar la representación antigua.

El artefacto práctico es un registro de indicadores, no un recuento:

| Indicador | Activado por | Leído por | Fase del ciclo | Significado posible | Confianza | | | | | | | | | 03 | tipo de registro en I-spec | C-spec condicionada | detalle | registro de pedido elegido | alta | | 04 | resultado de CHAIN | condición EXCPT | detalle | cliente ausente | media | | L1 | cambio de campo de control | cálculos de totales | total | corte de cuenta | alta | | LR | fin del archivo primario | totales y cierre | último ciclo | finalización | alta |

Ese registro ofrece a los revisores algo que se puede refutar. También muestra dónde hace falta investigar para estimar. Diez indicadores bien nombrados y con un solo propósito pueden ser más baratos que tres cuyo significado cambia según la fase del ciclo.

El ciclo RPG controla un flujo que no se ve

Un programa dirigido por el ciclo delega la secuencia en lógica generada por el compilador, por lo que leer las especificaciones de cálculo de arriba abajo no revela el orden de ejecución. La documentación de IBM sobre programación por ciclos describe una secuencia repetida que lee un registro, activa indicadores de registro y nivel de control, ejecuta el trabajo de totales para un corte, genera la salida total, comprueba la condición de último registro, mueve los campos de entrada y después ejecuta los cálculos de detalle. La primera y la última pasada tienen sus propias reglas.

Este orden sorprende a los ingenieros que esperan un bucle explícito. Los totales del grupo que acaba de terminar pueden ejecutarse después de leer lo suficiente del siguiente registro para detectar un corte de control, pero antes de que sus campos sean los datos de detalle actuales. Las salidas de cabecera o detalle también pueden producirse en momentos definidos por el ciclo. Una reescritura que coloque read() al principio de un bucle convencional y los totales al final puede ser razonable, legible e incorrecta.

Los archivos primarios y secundarios añaden más comportamiento implícito. Puede que el programa nunca ejecute la lectura que avanza un archivo primario porque lo hace el ciclo. La lógica de coincidencia de registros, los campos de control, los registros de entrada y las especificaciones de salida colaboran mediante reglas del compilador. El indicador LR puede llegar de forma implícita tras el último registro primario o secundario, e IBM señala que activar LR también activa los indicadores de nivel de control para el procesamiento final de totales. Esto es semántica de ejecución, no una curiosa señal de terminación.

La conversión segura hace explícita la máquina de estados oculta antes de cambiar su arquitectura. Representa fases como inicialización, selección de entrada, detección de cortes de control, totales del grupo anterior, procesamiento de detalle y totales finales. Registra qué campos contienen el registro anterior, el recién seleccionado y los datos actuales en cada fase. Después escribe el destino procedural contra ese modelo.

Una traza mínima de comportamiento puede ser así:

seq=411 phase=read       account=170 record=invoice
seq=412 phase=break      level=L1 old_account=160 new_account=170
seq=413 phase=total      account=160 amount=9284.15 output=ACCT_TOTAL
seq=414 phase=detail     account=170 invoice=88412 amount=73.20
seq=415 phase=final      lr=on output=REPORT_TOTAL

Si el sistema antiguo no puede emitir una traza de forma segura, hay que derivar los eventos esperados de entradas grabadas y salidas observables. La prueba esencial es el orden. No basta con que coincidan los totales finales si el destino escribe un registro posterior, actualiza un saldo o llama a otro programa en la fase equivocada.

Formato libre no significa una sola cosa

El RPG de formato libre abarca varios estilos y solo algunos se comportan como código procedural corriente. Un miembro puede contener cálculos libres entre /FREE y /END-FREE y conservar especificaciones F, I u O fijas. Un miembro más nuevo puede usar declaraciones libres, pero seguir dependiendo de un procedimiento principal cíclico. Un módulo totalmente libre puede usar ctl-opt nomain, procedimientos, lecturas explícitas, estructuras de datos cualificadas y prototipos. Llamar «formato libre» a los tres destruye la señal más útil para la estimación.

La documentación de IBM establece claramente los límites técnicos. El código totalmente libre usa **FREE en la primera línea; las sentencias fijas que todavía necesita, como viejas especificaciones de entrada o salida, deben residir en un archivo copiado. Las reglas de especificación de RPG IV también indican que MAIN o NOMAIN impide un procedimiento principal cíclico, mientras que un módulo sin esas palabras clave aún puede tenerlo. Por tanto, **FREE no dice por sí solo si existe el ciclo.

Clasifico los miembros en ejes independientes:

• modo fuente: fijo, mixto limitado por columnas o totalmente libre
• modelo de ejecución: principal cíclico, principal lineal o procedimientos MAIN/NOMAIN
• acceso a datos: archivos controlados por ciclo, E/S nativa explícita, SQL embebido o mezcla
• modelo de estado: indicadores numéricos, indicadores con nombre, variables explícitas o mezcla
• forma externa: llamadas a programas y áreas de datos, procedimientos de servicio, colas, archivos o mandatos de trabajo

Esta clasificación evita un fallo habitual de estimación. Dos miembros totalmente libres pueden ser radicalmente distintos si uno es un procedimiento pequeño con SQL explícito y el otro trae O-specs antiguas mediante /COPY, conmuta indicadores numerados y termina mediante *INLR. A la inversa, un miembro de formato fijo puede ser mecánicamente regular y quedar bien cubierto por reglas repetibles. El formato influye en la dificultad, pero el comportamiento la decide.

También importa el nivel de compilación. La sintaxis de un miembro muestra lo que usa, pero no todas las restricciones del compilador o del entorno productivo. Hay que inventariar versiones de destino, grupos de activación, directorios de enlaces, archivos descritos externamente, copybooks, programas de servicio y mandatos de compilación. Un plan que ignore el grafo de compilación descubrirá «código ausente» que en realidad se inyectaba o resolvía al compilar.

La modernización empieza por un modelo de comportamiento

El destino debe expresar la intención de negocio y mantener la compatibilidad en límites con nombre. Para un informe cíclico, eso suele significar un lector que produce registros tipados, un componente que detecta cortes de control, un calculador para detalles y totales, y un adaptador de salida que reproduce los registros externos necesarios. Para un programa interactivo, puede significar separar estado de pantalla, validación, acceso a archivos e invocación de mandatos. La forma sigue al comportamiento, no a las letras de las especificaciones.

No convierta cada C-spec en una sentencia y cada indicador en un booleano para llamar Go o TypeScript al resultado. El enfoque es popular porque se puede medir: cada línea fuente obtiene una línea de destino, los informes automáticos de diferencias parecen productivos y los revisores encuentran etiquetas conocidas. Es incorrecto porque conserva estructura accidental y dificulta reconocer las reglas implícitas de ejecución. El destino acaba siendo semántica RPG antigua escrita en un lenguaje cuyos mantenedores no conocen RPG.

Una buena representación intermedia conserva hechos que el diseño final descartará a propósito. Debe retener ubicación de origen, tipo de especificación, operación, factores, resultado, indicadores de condición y resultado, referencias de archivo y formato de registro, aristas de subrutinas, llamadas de procedimientos, origen del miembro copiado y fase del ciclo. También debe distinguir una arista derivada por el compilador de una escrita en el código. Sin esa diferencia, la migración no puede explicar por qué existe una rama en el destino.

La decisión arquitectónica también depende del límite del sistema. Si los llamantes dependen de la lista de parámetros de un programa RPG, mensajes de cola de datos, formatos descritos externamente, control de confirmaciones o estado del trabajo, hay que conservar primero ese contrato. Los componentes internos cambian detrás de un adaptador. Intentar rediseñar a la vez todos los contratos vecinos transforma una migración de lenguaje en un proyecto sin límites sobre el modelo operativo.

Ciertos comportamientos no deben sobrevivir. El alias de indicadores, los campos globales mutables, las aperturas implícitas y los tiempos del ciclo no merecen un hogar permanente en el destino. Conserve sus consecuencias observables, demuestre la paridad y retire después el andamiaje. Esa secuencia separa «mismo comportamiento» de «misma implementación», una diferencia que muchos programas de modernización confunden.

El descubrimiento debe revisar todo el sistema ejecutable

Una estimación basada en líneas de miembros RPG deja fuera buena parte del programa. El sistema ejecutable incluye miembros copiados, archivos de pantalla e impresora, definiciones de base de datos, envoltorios CL, mandatos, descripciones de trabajos, directorios de enlaces, programas de servicio, áreas de datos, colas de datos, archivos de mensajes, objetos SQL y el proceso de compilación. Un miembro de 300 líneas puede ocupar el centro de una superficie de comportamiento mucho mayor.

Empiece con un inventario reproducible cuyas filas puedan rastrearse hasta pruebas. Como mínimo, debe capturar identidad del objeto o miembro, tipo de código, metadatos de última compilación si existen, referencias directas, llamantes entrantes, dependencias de copia, modo de acceso a archivos, número de indicadores por función, uso del ciclo, subrutinas y procedimientos, SQL embebido, llamadas externas y código no disponible. Marque el código generado y las variantes duplicadas en lugar de deduplicarlos en silencio.

La pregunta incómoda es si existe todo el código de producción. En IBM i, un objeto ejecutable no garantiza que sigan disponibles el código exacto o sus opciones de compilación. Los equipos suelen encontrar un miembro que parece más nuevo en una biblioteca mientras producción ejecuta un objeto compilado desde otra revisión. Compare metadatos de objetos, listas de bibliotecas, información de enlaces y comportamiento desplegado. Si la procedencia es incierta, ponga precio explícito a esa incertidumbre en vez de suponer que el repositorio es canónico.

El muestreo debe seguir el riesgo, no la comodidad. Leer el programa de servicio de formato libre más limpio dice poco sobre un informe de facturación dirigido por el ciclo. Elija muestras que cubran cada modo fuente, modelo de ejecución, estilo de E/S, patrón de indicadores, tipo de objeto y ruta de negocio. Incluya el miembro que todos evitan, el que tiene O-specs copiadas y el programa que solo se ejecuta al cierre. Ahí es donde la estimación debe ganarse la confianza.

Un resultado de descubrimiento debe separar hechos conocidos, inferidos y sin verificar. «El programa A llama al programa B» puede conocerse por un grafo resuelto. «El indicador 42 significa reintento» puede inferirse de operaciones y mensajes. «Esta rama está muerta» sigue sin verificar hasta que lo respalden datos de producción o una prueba controlada. Los distintos niveles de confianza necesitan contingencias diferentes; reducirlos a una puntuación única de complejidad oculta el trabajo.

La paridad necesita pruebas con forma de producción

Compilar demuestra sintaxis y las pruebas unitarias demuestran funciones escogidas. Ninguna de las dos cosas demuestra que un sistema RPG reescrito se comporte como producción. Las pruebas de paridad deben comparar los sistemas antiguo y nuevo con entradas parecidas al trabajo real, incluido orden de registros, valores vacíos y cero, límites decimales empaquetados, códigos de estado, cortes de control, registros ausentes, claves duplicadas, fin de archivo y contexto del trabajo.

La unidad de comparación debe coincidir con el contrato. Para un informe, compare el contenido normalizado de spool, los límites de páginas y totales, y cualquier registro generado como efecto secundario. Para una actualización por lotes, compare cambios en base de datos, mensajes, llamadas, límites de confirmación y estado de reinicio. Para un flujo interactivo, compare transiciones de pantalla, mensajes de validación, comportamiento de teclas de función y escrituras resultantes. Las marcas de tiempo, identificadores generados y órdenes no deterministas necesitan reglas declaradas de normalización, no exclusiones improvisadas tras una diferencia.

Use un manifiesto para cada repetición:

{"case":"account-break-final-record","input_set":"sha256:...","old_build":"LIBA/ORDRPT:...","new_build":"git:...","normalizers":["run_timestamp"],"expected_events":417}

El arnés debe conservar la identidad de la entrada, las dos compilaciones, las salidas normalizadas, las originales cuando la política lo permita y el primer evento divergente. «Los archivos difieren» abre una investigación. «En el evento 413, el código antiguo emitió ACCT_TOTAL antes de procesar la cuenta 170 y el nuevo después» identifica el modelo erróneo de corte de control.

El tráfico de producción grabado resulta muy útil porque incluye combinaciones que los diseñadores de pruebas olvidan. Aun así necesita reglas: enmascarar o tokenizar campos sensibles de forma coherente, conservar la igualdad relacional, capturar los atributos necesarios del trabajo e impedir que las repeticiones llamen a sistemas externos reales. Si el tráfico no puede salir del perímetro del cliente, la comparación se ejecuta allí. CodeHero aplica este modelo: lee todo el árbol, reescribe la arquitectura y comprueba el comportamiento con un arnés de paridad contra tráfico de producción grabado.

La paridad no exige conservar para siempre cada accidente. Primero clasifique cada diferencia como comportamiento necesario, defecto tolerado, ruido ambiental o cambio aprobado. Después haga auditable la decisión. «Corregir» discretamente un cálculo durante la migración puede ser más peligroso que conservarlo por un tiempo, porque los archivos posteriores o procesos de conciliación pueden depender del resultado antiguo.

Las estimaciones de fijo y libre necesitan unidades distintas

Una migración procedural de formato libre suele poder estimarse mediante unidades explícitas: procedimientos, sentencias SQL, contratos de archivos, llamadas externas, pantallas y pruebas. El código cíclico de formato fijo necesita unidades adicionales para la semántica recuperada: grupos de indicadores, redes de especificaciones de entrada y salida, grupos de niveles de control, archivos controlados por ciclo, rutas de salida excepcional, estado de subrutinas y reconstrucción del código. Esas unidades representan análisis y verificación, no escritura.

Separe la estimación en cuatro bloques: inventario y procedencia, recuperación semántica, implementación del destino y pruebas de paridad. El código procedural de formato libre puede gastar más presupuesto en implementación. El código cíclico fijo suele desplazar esfuerzo hacia la recuperación semántica y el diseño de repeticiones. Aplicar la misma tarifa por línea a ambos vuelve invisible el trabajo difícil y premia la métrica menos informativa.

La complejidad debe aumentar cuando se multiplican las interacciones. Un indicador de corte de nivel con una línea de total está acotado. Varios niveles de control combinados con registros coincidentes, indicadores compartidos, salida excepcional y especificaciones copiadas generan combinaciones de estados. No añada un recargo fijo por cada función fingiendo que sus efectos son independientes. Calcule los recorridos combinados de comportamiento que deben entenderse y probarse.

Use intervalos hasta que el descubrimiento resuelva incógnitas concretas. Una estimación útil registra junto a cada intervalo su base y condición de salida: «semántica del ciclo, confianza media, se estrecha tras dos trazas representativas» se puede defender. «Conversión RPG, 500 líneas al día» no. El intervalo debe reducirse cuando el equipo resuelve la procedencia, genera el registro de indicadores, valida el grafo de llamadas y repite casos representativos.

La estimación también debe decir qué excluye. Limpiar datos, cambiar reglas de negocio, sustituir la planificación previa de trabajos, rediseñar pantallas o fusionar aplicaciones duplicadas puede ser razonable, pero no forma parte automáticamente de una reescritura de lenguaje. Si los interesados lo quieren, cada trabajo necesita sus decisiones, pruebas y precio. De otro modo, todo cambio deseable se cobrará como «dificultad de RPG» y nadie aprenderá cuánto cuesta realmente la migración.

Ponga ambos estilos en la misma hoja de estimación y la diferencia se vuelve concreta. Para un servicio procedural de formato libre, el analista suele identificar un procedimiento de entrada, seguir lecturas explícitas o SQL, enumerar llamadas, mapear valores devueltos y contar contratos que necesitan adaptadores. Persisten incógnitas, sobre todo acerca del estado del trabajo y objetos externos, pero cada una se vincula con una operación o frontera visible. La estimación puede pasar rápido del inventario al diseño porque el programa dice cuándo sucede el trabajo.

Para un informe cíclico fijo, la primera hoja empieza antes. El analista debe determinar qué archivo controla el ciclo, qué especificaciones de entrada identifican registros, qué campos causan cortes de nivel, cuándo se ejecutan los totales, qué líneas O-spec condicionan y qué activa LR. Después llega el registro de indicadores, incluidos los valores que activan implícitamente las operaciones de archivo. Solo entonces el destino puede exponer la misma secuencia con lector, lógica de agrupación, cálculos y adaptadores de salida. Contar ambos programas como un «miembro RPG» borra una capa completa de entregables.

Los criterios de aceptación difieren del mismo modo. El servicio procedural puede cubrirse con casos de solicitud y respuesta, efectos de base de datos y rutas de error explícitas. El informe cíclico necesita casos ordenados alrededor del primer registro, cada nivel de control, registros que cambian varios niveles a la vez, una entrada vacía o ausente cuando proceda y el último registro. Si existen coincidencia de registros o salida excepcional, la matriz crece alrededor de esas interacciones. Las pruebas adicionales no compensan una mala conversión. Demuestran que el nuevo flujo explícito coincide con el antiguo implícito.

Las capacidades de revisión también forman parte de la estimación. Un ingeniero de Go puede evaluar la estructura de destino, pero quizá no reconozca que un cálculo de totales lee campos de otra fase del ciclo. Un profesional de RPG puede recuperar ese comportamiento y aceptar una arquitectura literal porque le resulta familiar. Empareje las revisiones hasta que las trazas de paridad y la representación intermedia hagan visible el razonamiento. El punto de entrega debe basarse en pruebas: el revisor debe poder rastrear una rama del destino hasta una regla RPG, una condición fuente o un rediseño aprobado.

Estime la repetición de trabajo por separado de la implementación prevista. Una regla conocida que se aplica a cientos de cálculos regulares es trabajo de implementación. Un indicador sin resolver que controla cinco formatos de salida es un riesgo de descubrimiento; adivinarlo genera repetición, no progreso. Registre responsable, prueba necesaria y fecha de decisión para cada riesgo. Así la reserva se puede explicar y la incertidumbre de unos pocos miembros fijos no infla el precio del código procedural limpio.

Las cifras aún pueden unirse en una propuesta comercial, pero esta debe conservar las clases internas. La entrega puede adelantar componentes procedurales de baja incertidumbre mientras el trabajo semántico cierra rutas cíclicas arriesgadas, sin fingir que el rendimiento será uniforme. Si una dependencia común bloquea ambas clases, muéstrela una vez a nivel de cartera. Si solo la recuperación del ciclo la necesita, conserve el coste en esa clase. Así un precio de proyecto puede ser honesto sin imponer una estimación a dos tipos de trabajo.

La separación también aclara el control de cambios: cuando una regla del ciclo recién descubierta modifica la estimación, los interesados ven qué clase cambió y por qué no lo hizo la previsión procedural.

Una cifra combinada crea el plan equivocado

La misma estimación no puede cubrir código cíclico de formato fijo y RPG procedural de formato libre porque el trabajo comienza con grados distintos de certeza. En el caso procedural, el equipo suele ver el flujo de control y dedica su tiempo a reconstruir los contratos con limpieza. En el ciclo fijo, primero debe reconstruir el flujo a partir de columnas, especificaciones, indicadores, reglas del compilador y pruebas de ejecución. Ambos pueden migrarse, pero no entran en la fábrica por la misma puerta.

Esto no justifica un proyecto arqueológico sin final. Limite el descubrimiento por tiempo y por clases representativas de riesgo, y exija resultados concretos: censo de modos fuente, clasificación de modelos de ejecución, grafo de compilación resuelto, registros de indicadores para miembros arriesgados, trazas de ciclo, inventario de contratos y casos de paridad. Si una tarea no puede decir qué incertidumbre de estimación reduce, elimínela.

Para una cartera, cotice intervalos distintos al menos para código fijo o mixto dirigido por ciclo, código fijo o mixto procedural y código procedural totalmente libre. Después ajuste por código ausente, número de objetos externos, sensibilidad de contratos de datos y pruebas existentes. Mantenga visible la clasificación en el plan de entrega, ya que también determina las habilidades de revisión y el orden en que deben trasladarse los componentes.

CodeHero se compromete a completar cada reescritura en menos de 30 días, incluidos sistemas de más de un millón de líneas, así que nuestra entrada debe distinguir estas clases de inmediato en lugar de ocultarlas bajo una tarifa combinada. Use o no nuestros servicios, pida a cualquier proveedor que muestre cómo su estimación contempla fases del ciclo, reutilización de indicadores, especificaciones copiadas, procedencia productiva y paridad en cortes de control. Si la respuesta vuelve al número de líneas, la estimación no ha descrito el trabajo.