¿Qué incluye una estimación de reescritura de software?

Una estimación de reescritura debe describir la incertidumbre del comportamiento, no premiar a quien haya contado el repositorio más deprisa. Las líneas de código importan porque alguien tendrá que inspeccionarlas y sustituirlas, pero el recuento de líneas es solo un dato de entrada. La profundidad de las bifurcaciones, las integraciones externas, la semántica de los datos, los trabajos operativos y la superficie disponible para las pruebas de paridad suelen mover la estimación más que el tamaño bruto.

He visto motores de facturación compactos que tardaron más en sustituirse que enormes aplicaciones de informes. El sistema pequeño escondía reglas en ramas anidadas, guardaba estados intermedios en tablas que nadie había documentado y llamaba a servicios que se comportaban de otra forma al cierre de mes. El grande repetía patrones CRUD sencillos y tenía registros de solicitudes limpios. Cualquier estimación que empiece y termine en "300.000 líneas" pone una etiqueta precisa a un trabajo que nadie ha medido.

Lo que puede decir el recuento de líneas

El recuento de líneas es una medida útil del volumen que hay que inspeccionar, pero no mide por sí solo la dificultad de una reescritura. Aun así, el equipo necesita un recuento reproducible, porque en las conversaciones comerciales se mezclan el tamaño del repositorio, el número de archivos y las líneas ejecutables.

Defina la regla de recuento antes de comparar propuestas. Como mínimo, separe el código fuente de producción, el código generado, las dependencias de terceros, las pruebas, el código de base de datos, el control de trabajos, la configuración y los comentarios. Un millón de líneas que incluye stubs de cliente generados no es el mismo sistema que un millón de líneas de COBOL, JCL, SQL y copybooks escritas a mano. Si quien estima no muestra esas categorías, el total no se puede auditar.

Un sencillo comando de inventario da a los responsables de ingeniería una primera comprobación. cloc no es una herramienta de estimación, pero genera una forma estable que puede volver a ejecutarse después de cambiar las exclusiones:

cloc . --exclude-dir=vendor,node_modules,dist --by-file --json --out=cloc.json
jq '.SUM | {blank, comment, code}' cloc.json

El resultado tiene esta forma:

{"blank":18420,"comment":27116,"code":263904}

Conserve también la salida por archivo. Permite que un revisor encuentre subsistemas concentrados, bloques generados que escaparon a las exclusiones y lenguajes que el primer análisis no detectó. En un entorno mainframe, cuente JCL, copybooks, salidas en ensamblador, procedimientos SQL, mapas de pantalla y definiciones del planificador junto al lenguaje de la aplicación. Quizá contengan poca lógica de negocio, pero definen cómo se inicia, se detiene, intercambia archivos y se recupera el sistema.

El recuento de líneas funciona mejor como denominador. Los defectos por mil líneas, las ramas por módulo, las llamadas de integración por mil líneas y las pruebas que cubren cada capacidad de negocio aportan información. Un precio creado al multiplicar líneas por una tarifa universal no la aporta. La misma línea puede ser una declaración de campo, un getter generado o la rama que decide si una cuenta recibe intereses después de un ajuste retroactivo.

Las bifurcaciones miden el comportamiento que debe conservarse

Las bifurcaciones importan porque cada ruta de decisión puede codificar un comportamiento observable distinto. Cuente los puntos de decisión, mida cómo se combinan e identifique dónde el estado o los datos externos cambian el resultado. Un módulo plano con veinte validaciones independientes es más fácil de razonar que una rutina donde diez decisiones están anidadas y comparten estado mutable.

La complejidad ciclomática es una primera señal razonable. Thomas McCabe la definió a partir del grafo de flujo de control, que para una rutina conectada suele resumirse como el número de decisiones más uno. La cifra no predice el esfuerzo por sí sola. Indica cuántas rutas independientes existen, mientras que el anidamiento muestra lo difícil que resulta para una persona o una herramienta seguirlas.

El sector confunde a menudo el número de ramas con la profundidad de bifurcación. Supongamos que dos rutinas contienen ocho decisiones cada una. En la primera, ocho cláusulas de guarda rechazan registros no válidos y después se ejecuta un cálculo. En la segunda, la elegibilidad, la jurisdicción, la clase de producto, la fecha de vigencia, el estado de excepción y los ajustes anteriores están anidados en seis niveles. Ambas pueden obtener una puntuación ciclomática parecida. La segunda suele exigir más fixtures, una reconstrucción del estado más cuidadosa y más revisión, porque una condición cambia el significado de todas las que tiene debajo.

Pida una distribución, no una media. Un promedio de todo el repositorio oculta las cinco rutinas que controlan movimientos de dinero o el funcionamiento de una planta. Algunos grupos útiles son las rutinas por encima de un umbral ciclomático acordado, la profundidad máxima de anidamiento, el fan-in, el fan-out y la cantidad de código alcanzable desde puntos de entrada con consecuencias importantes. El umbral debe señalar trabajo de inspección, no declarar que el código es "malo".

Pregunte también si el análisis resuelve el despacho dinámico, las llamadas generadas, las macros y las reglas controladas desde la base de datos. El análisis estático puede omitir un nombre de programa leído de una tabla, un CALL de COBOL construido en tiempo de ejecución o un evento de formulario VB6 conectado fuera de la rutina visible. Un informe honesto marca las aristas sin resolver. No trata en silencio los datos ausentes del grafo como baja complejidad.

La complejidad cambia una estimación por el trabajo de evidencia. Cada ruta con consecuencias necesita una entrada conocida, una salida esperada y un estado inicial pertinente. Si las trazas de producción cubren la mayoría de las rutas, el equipo puede obtener casos de la realidad. Si los registros solo capturan un código de estado final, alguien tendrá que reconstruir las decisiones leyendo el código y haciendo ejecuciones dirigidas. Es una cantidad de trabajo distinta aunque el código sea idéntico.

Las integraciones externas crean riesgo en los límites

Las integraciones externas merecen su propio inventario, porque una reescritura falla en los límites con más frecuencia que en la sintaxis. Una "integración" no es solo una API HTTP. Incluye archivos depositados en almacenamiento compartido, colas de mensajes, sesiones de terminal, enlaces de base de datos, flujos de impresora, SMTP, eventos del planificador, comandos de shell, proveedores de identidad, dispositivos de hardware y personas que trasladan manualmente salidas entre sistemas.

Cuente cada contrato distinto y registre su dirección, protocolo, propietario, frecuencia, autenticación, forma de los datos, comportamiento ante fallos y sustituto de prueba. Diez endpoints detrás de un cliente de servicio documentado pueden ser más sencillos que un único archivo nocturno de ancho fijo cuyo propietario se marchó y cuyos registros rechazados aparecen en el buzón de un operador.

La pregunta incómoda es si una integración puede ejercitarse fuera de producción. Un entorno de pruebas del proveedor con datos artificiales quizá no reproduzca la limitación de tráfico, el orden, la renovación de certificados o el comportamiento de fin de jornada. Puede que una base compartida no tenga copia de pruebas. Un socio quizá solo acepte una ventana de certificación. Estas restricciones pertenecen a la estimación porque determinan con qué rapidez puede aprender el equipo si la sustitución es correcta.

Inventaríe ambos lados de cada límite. Llamar a una API es solo la mitad del contrato. El sistema heredado quizá reintente con códigos concretos, suprima duplicados, dependa del orden de las respuestas o escriba un registro de conciliación después de un timeout. Las interfaces de archivos contienen reglas parecidas sobre nombres, codificación, finales de línea, trailers, archivos vacíos, entregas parciales y repeticiones. Tratarlas como "una integración SFTP" elimina los detalles con más probabilidades de detener la puesta en producción.

La propiedad es un dato del calendario, no una nota organizativa. Marque quién puede responder preguntas, emitir credenciales, aprobar una regla de firewall, proporcionar una muestra y observar una prueba. Si no existe un propietario, valore de forma explícita el descubrimiento y la contingencia. No esconda ese riesgo dentro de un colchón general del proyecto, porque los responsables necesitan la opción de asignar un propietario antes de firmar.

Una estimación creíble distingue la implementación de una integración de su demostración. Escribir un cliente nuevo puede ser rutinario. Demostrar que se comporta correctamente ante reintentos, entradas mal formadas, duplicados, entregas tardías y caídas del socio concentra la incertidumbre. Pida ambas cifras.

La superficie de pruebas fija el nivel de confianza

La superficie de pruebas es el conjunto de comportamientos observables que se pueden provocar y comparar, no el número de archivos de prueba del repositorio. Las pruebas unitarias existentes solo ayudan cuando afirman un comportamiento que el nuevo sistema debe conservar. Una suite llena de mocks puede describir la antigua estructura de clases y decir muy poco sobre facturas, asientos, mensajes o archivos en el límite del sistema.

Mida la superficie por capacidad de negocio y punto de observación. Para cada punto de entrada, registre qué entradas pueden reproducirse, qué estado inicial puede recrearse, qué salidas pueden capturarse y qué efectos secundarios pueden compararse. Incluya respuestas de API, cambios de base de datos, mensajes salientes, archivos generados, asientos contables, permisos, tiempos que afectan al orden y errores visibles para el operador.

El tráfico de producción grabado resulta especialmente útil porque contiene combinaciones que nadie recordó incluir en un plan de pruebas. Aun así, necesita reglas de manejo. Puede que haya que ocultar secretos y datos personales, las solicitudes quizá dependan de un estado caducado y reproducir un comando puede activar un efecto externo. Una traza es evidencia, no una fixture segura por defecto.

La cobertura tiene al menos tres significados en una reescritura, y las propuestas suelen intercambiarlos sin avisar. La cobertura del código pregunta qué instrucciones o ramas antiguas se ejecutaron. La cobertura de requisitos pregunta qué reglas documentadas tienen pruebas. La cobertura del comportamiento pregunta qué combinaciones de entrada y salida visibles desde fuera se han comparado. Una reescritura puede informar de una cobertura alta del código y omitir una convención de archivos no documentada de la que depende operaciones. Para la aceptación, la cobertura de comportamiento pesa más.

Pregunte cómo se clasificarán las diferencias. Algunas son defectos. Otras exponen un error antiguo que el negocio quiere conservar temporalmente. Otras proceden de marcas de tiempo, identificadores generados, orden, redondeo, configuración regional o dependencias no deterministas y necesitan normalización. Sin una política de comparación acordada, un porcentaje de paridad no significa nada, porque un equipo puede mejorarlo ignorando campos difíciles.

La estimación debe indicar el nivel de evidencia propuesto. Una herramienta interna de consulta con pocas consecuencias quizá solo necesite casos representativos y aceptación de usuarios. Un motor de contabilización puede exigir reproducción de tráfico grabado, fixtures enfocadas en ramas, totales de conciliación e inyección controlada de fallos. La confianza objetivo cambia el trabajo. "Reescribir el mismo código" no define ese objetivo.

La semántica de los datos puede pesar más que la aplicación

El trabajo de datos crece con el significado, la historia y el acoplamiento, no solo con el número de filas. Una base de datos pequeña puede contener columnas sobrecargadas, códigos implícitos, claves foráneas rotas, reglas temporales y procedimientos almacenados que llevan la mayor parte del comportamiento del sistema. Una tabla grande de eventos que solo admite anexos puede trasladarse limpiamente porque su contrato es sencillo.

Estime por separado la traducción del esquema, la limpieza de datos, la ejecución de la migración, la conciliación y la reversión. Son trabajos diferentes. Traducir un campo decimal empaquetado a un tipo numérico de Postgres es mecánico. Decidir si un valor vacío, cero y un centinela significan "desconocido" exige evidencia del código y los datos de producción. Después, la conciliación demuestra que el mapeo elegido conservó saldos y recuentos.

El estado oculto es especialmente caro. Los programas heredados suelen comunicarse mediante tablas de trabajo, registros de control, archivos de secuencia, variables de entorno o convenciones de nombres en lugar de llamadas explícitas. Un trabajo por lotes escribe un byte de estado y otro trabajo posterior lo interpreta como permiso para omitir una cuenta. Un diagrama de esquema no muestra ese comportamiento. El análisis de dependencias debe incluir lecturas y escrituras, el orden de los trabajos y la vida de los estados intermedios.

El volumen sigue importando, pero pida distribuciones y límites operativos. El máximo cambio diario, la partición más grande, el ancho de registro, la retención, los registros tardíos y la interrupción permitida importan más que el total histórico de filas. Una migración que cabe en una ventana de mantenimiento tiene un plan distinto a otra que necesita captura de cambios y conciliaciones repetidas mientras ambos sistemas funcionan.

No acepte "migración de base de datos incluida" como medida. Pregunte qué tablas tienen mapeos de origen a destino, qué significados de campos siguen sin resolver, qué rutinas almacenadas pasan a servicios, cuántas reglas de conciliación existen y cómo funciona la reversión después de que el nuevo sistema reciba escrituras. Quien no pueda contestar ha puesto precio a una suposición.

El código operativo pertenece al límite del sistema

Los planificadores, scripts de despliegue, manuales del operador, reglas de acceso, monitorización y procedimientos de recuperación forman parte del comportamiento de la aplicación. Dejarlos fuera de la estimación produce un sustituto que pasa una demostración, pero no puede cerrar una jornada de negocio.

Los entornos por lotes lo muestran con claridad. JCL o CL pueden definir dependencias, ejecución condicional, asignación de conjuntos de datos, puntos de reinicio y notificaciones. El código de la aplicación puede parecer sencillo mientras la red de trabajos contiene el verdadero flujo de control. En sistemas de escritorio, los scripts de instalación, los ajustes del registro, las carpetas compartidas y las tareas programadas cumplen el mismo papel. En monolitos web, las entradas cron y las acciones manuales de administración suelen cubrir el hueco.

Pida un recuento de trabajos programados, disparadores, unidades de despliegue, ajustes específicos del entorno, roles, alertas, informes e intervenciones documentadas del operador. Conéctelos después con capacidades de negocio. Una lista sin un grafo de dependencias no puede mostrar si un trabajo fallido reinicia con seguridad o si una credencial bloquea quince procesos.

El comportamiento de recuperación necesita pruebas directas. Interrumpa un lote después de que escriba la mitad de su salida. Entregue dos veces el mismo mensaje. Haga que una dependencia agote el tiempo después de aceptar una solicitud. Restaure una instantánea de base de datos con trabajo aún pendiente en la cola. El sistema antiguo puede contener años de respuestas prácticas a estos casos, aunque nadie las haya escrito. La reescritura debe conservar esas respuestas o sustituirlas por decisiones que apruebe el negocio.

Esta área también expone una recomendación popular pero equivocada: "modernizar operaciones después de la paridad funcional". A los equipos les gusta porque parece reducir el alcance. En realidad, aplaza el descubrimiento de los requisitos de reinicio, orden, acceso y monitorización hasta que el nuevo diseño se ha endurecido. Los paneles cosméticos pueden esperar. El comportamiento que mantiene coherentes el dinero, los registros y los trabajos después de un fallo no puede hacerlo.

La preparación operativa debe aparecer como trabajo medido, con propietarios y evidencia de aceptación. Si una propuesta la trata como una línea corta cerca del despliegue, el precio está incompleto.

Los cambios de arquitectura necesitan dos estimaciones

Modernizar la arquitectura y conservar el comportamiento son líneas de trabajo relacionadas, pero no son la misma tarea. Valórelas por separado para que una decisión de diseño no rebaje en silencio la evidencia prometida. Un límite de servicio puede mejorar la propiedad y el despliegue, pero también crea contratos, modos de fallo y decisiones de coherencia de datos que el monolito resolvía con llamadas locales y una transacción.

Las estimaciones de transliteración suelen parecer baratas porque asignan una unidad antigua a una nueva. Ese enfoque puede conservar estructuras accidentales, estado global y restricciones de despliegue obsoletas. Una reescritura seria debe identificar capacidades y elegir límites que encajen con el entorno objetivo. La estimación debe incluir el análisis necesario para separar esas capacidades, no solo la producción de una sintaxis equivalente.

El error opuesto es la ambición arquitectónica sin presupuesto para el comportamiento. Una propuesta puede prometer servicios, eventos, un cliente nuevo y una base de datos nueva y reservar poco tiempo para descubrir lo que hace realmente el sistema actual. Ese equipo tomará decisiones de diseño limpias basadas en un modelo incompleto. El resultado puede verse bien en un diagrama y fallar durante un reembolso, una repetición o un fallo parcial.

Pida dos mapas conectados. El mapa de comportamiento une los puntos de entrada antiguos, las decisiones, los cambios de estado y las salidas. El mapa objetivo asigna esos comportamientos a componentes nuevos e indica qué acoplamiento antiguo desaparecerá. Cada responsabilidad trasladada debe tener evidencia en ambos lados: qué demuestra el comportamiento anterior y qué demuestra el contrato nuevo. Así pueden los responsables distinguir una modernización deliberada de una conversión de archivos con nombres de directorio nuevos.

El comportamiento transversal necesita atención especial durante la descomposición. La autenticación, la autorización, el alcance de la transacción, la idempotencia, el redondeo, la configuración regional, los registros de auditoría y el mapeo de errores pueden aparecer en muchos módulos antiguos porque no existía un límite central. Contar cada copia como una función independiente infla la estimación. Contar el asunto una vez e ignorar sus muchas variantes observables la rebaja. Mida los comportamientos distintos y después diseñe la implementación compartida.

Los requisitos de rendimiento pertenecen a la misma comparación. No copie todas las características de tiempo accidentales del sistema heredado, pero identifique los plazos con sentido de negocio: una respuesta de terminal antes de que el operador vuelva a intentarlo, un lote completado antes de que abra el siguiente mercado o una exportación entregada antes del límite del socio. Registre las distribuciones actuales cuando haya evidencia y defina límites objetivo. Una promesa vaga de que el sistema nuevo será más rápido no sirve para la aceptación.

La arquitectura también cambia el plan de transición. Una sustitución única exige paridad completa y una reversión creíble antes de mover el tráfico. Una sustitución incremental exige reglas de enrutamiento, flujos de datos de coexistencia y pruebas de que los componentes antiguos y nuevos coinciden durante la transición. Ningún enfoque es siempre más barato. La estimación debe mostrar la maquinaria temporal que requiere cada uno y cuándo puede retirarse.

Cuando los revisores ven la conservación del comportamiento y el diseño objetivo como filas separadas, las decisiones son honestas. Pueden simplificar un límite objetivo sin fingir que desapareció una regla antigua, o retirar una regla antigua mediante una decisión explícita del negocio. Ese es el control que necesita un responsable de ingeniería antes de aceptar una cifra fija.

Un modelo ponderado hace visibles las suposiciones

Una estimación útil de reescritura de software combina dimensiones medidas y muestra cómo afecta cada una al esfuerzo. No necesita una fórmula universal. Necesita un modelo que los revisores puedan cuestionar, actualizar y conectar con la evidencia.

Empiece con una tabla de inventario al nivel de subsistema. Una fila por unidad desplegable o capacidad de negocio coherente suele informar más que una fila por repositorio. Use columnas como estas:

Puntúe la confianza junto a cada medición. "42 interfaces, 39 inspeccionadas, 3 inferidas" es más útil que "42 interfaces". Registre la fuente de la evidencia, como análisis estático, traza de producción, análisis de configuración, entrevista o datos de muestra. Un elemento inferido debe llevar más contingencia que uno observado.

Después, exprese la estimación como rangos por línea de trabajo. Un modelo interno sencillo podría tener este aspecto:

replacement = source inventory adjusted for repetition and generated code
behavior proof = consequential paths x fixture cost x evidence gap
integration work = contract implementation + failure proof + owner delay risk
data work = mapping + transformation + rehearsal + reconciliation
operations = deployment + observability + recovery exercises

No convierta ese boceto en aritmética fingida. Los multiplicadores deben proceder del trabajo terminado del propio equipo de entrega y las unidades necesitan definiciones. Su propósito es mostrar por qué dos sistemas de tamaño parecido reciben estimaciones distintas.

Los rangos deben estrecharse cuando mejora la evidencia. Antes de acceder al código, una propuesta puede tener límites amplios y suposiciones explícitas. Después del análisis del repositorio, del muestreo de tráfico y de las entrevistas sobre integraciones, el proveedor debe sustituir las suposiciones por recuentos. Si la cifra no cambia mientras lo hace la evidencia, la estimación original era probablemente un objetivo comercial y no un resultado de ingeniería.

CodeHero lee toda la base de código en varios lenguajes y usa tráfico de producción grabado en un banco de paridad, por lo que su estimación puede unir la estructura del código al comportamiento observable en lugar de aplicar una tarifa a cada línea. Eso no justifica entradas poco claras: los responsables de ingeniería deben pedir que se muestre qué se contó, qué representa el tráfico y qué límites siguen sin demostrar.

Cómo falla una estimación en un sistema pequeño

Pensemos en una aplicación de tarificación de siniestros de 38.000 líneas. Una oferta basada en líneas hace que parezca modesta. El repositorio contiene un cliente de escritorio, una biblioteca de cálculo, procedimientos SQL y una exportación nocturna. Las pruebas existentes cubren la biblioteca de cálculo y al principio el equipo trata lo demás como infraestructura normal.

El descubrimiento encuentra cuatro hechos. El cliente elige las rutas de cálculo activando y desactivando campos antes de llamar a la biblioteca. Las reglas de producto viven en seis tablas SQL mantenidas por operaciones. La exportación nocturna solo se acepta cuando los totales de su trailer coinciden con el cálculo independiente de un socio. La retarificación de un siniestro histórico depende de la versión de la tabla de reglas activa en la fecha de servicio original.

Ningún hecho añade muchas líneas de código. Cada uno amplía el comportamiento que debe capturarse. El estado del cliente se convierte en contrato de entrada. Las tablas de reglas necesitan fixtures con versión y reglas de migración. La lógica del trailer necesita ejemplos del socio y pruebas de rechazo. La retarificación histórica necesita reconstrucción de datos basada en el tiempo.

Supongamos ahora que la suite actual ejecuta el 85 por ciento de la biblioteca de cálculo. La cifra suena tranquilizadora, pero solo cubre el componente cuyas entradas ya transformó el cliente. Un plan de paridad debe capturar la acción del usuario, el estado del cliente, la versión de regla elegida, los cambios en la base, la salida del cálculo y el registro exportado. La superficie útil va de extremo a extremo, aunque la arquitectura objetivo separe bien esos asuntos.

La estimación cambia porque la unidad de trabajo pasó de líneas sustituidas a comportamientos demostrados. Puede que el equipo solo reescriba 38.000 líneas. También necesita identificar rutas de decisión de la interfaz, extraer el historial de reglas, emular la validación del socio y comparar las salidas antiguas y nuevas en los casos grabados. Llamarlo desviación sería deshonesto si la oferta original nunca midió esos elementos.

Hay una respuesta práctica cuando el descubrimiento revela esta forma. Congele el precio fijo hasta que el proveedor entregue el inventario de límites y el plan de paridad. No necesita tener todas las pruebas escritas antes de firmar, pero sí recuentos, fuentes de evidencia, exclusiones y un método para convertir incógnitas en decisiones. De otro modo, el contrato transfiere sobre el papel un riesgo imposible de conocer y deja que ambas partes discutan después.

Pida el paquete de medición antes de firmar

Un responsable de ingeniería debe recibir la estimación y la evidencia que la respalda. Un total elegante sin el paquete de medición impide la revisión técnica y hace casi inevitables las discusiones posteriores sobre el alcance.

El paquete debe responder a un conjunto compacto de preguntas:

1. ¿Qué categorías de código se contaron, qué se excluyó y podemos volver a ejecutar el inventario?
2. ¿Dónde están las rutas de decisión más profundas y con más consecuencias, incluidas las llamadas dinámicas no resueltas?
3. ¿Qué contratos externos existen, quién es su propietario y cuáles pueden probarse fuera de producción?
4. ¿Qué significados de datos, migraciones y reglas de conciliación siguen sin resolver?
5. ¿Qué entradas pueden reproducirse, qué salidas compararse y cómo se normalizan las diferencias aceptables?

Pida las respuestas por subsistema, con etiquetas de confianza y fuentes de evidencia. Una media para todo el repositorio no basta. Una interfaz de liquidación que no puede probarse puede dominar el riesgo mientras cincuenta módulos corrientes hacen que la media parezca segura.

Las condiciones comerciales deben seguir las mediciones. Un alcance fijo funciona cuando se conocen los límites y la evidencia de aceptación. Una fase de descubrimiento pagada puede tener sentido si faltan acceso, propietarios o trazas de producción, pero debe producir artefactos reutilizables en lugar de una presentación: inventarios, grafos, mapeos, muestras y un rango actualizado. La contingencia debe asociarse a incógnitas concretas y reducirse cuando el cliente las resuelve.

Rechace estimaciones que ofrecen precisión sin exclusiones. Rechace también el movimiento contrario, cuando un proveedor llama incierto a todo y pide tiempo ilimitado. Una buena estimación reduce la incertidumbre inspeccionando código, siguiendo el comportamiento y probando los límites. Muestra qué incógnitas quedan y quién puede eliminarlas.

CodeHero se compromete a entregar en menos de 30 días, lo que hace obligatoria la medición temprana del código, el comportamiento, las integraciones, los datos y las operaciones. Sea cual sea el proveedor que considere, exija que la estimación nombre el sistema comprobable que pretende entregar. Un total de líneas describe el material que hay en el suelo. El paquete de medición describe el edificio que debe terminar.