Dimensionar sistemas heredados más allá de contar líneas

Un recuento de líneas indica cuánto texto fuente existe. No dice cuánto comportamiento debe conservar un reemplazo, de cuántas formas puede bifurcarse ese comportamiento ni qué parte del código fuente sigue ejecutándose. Tratar esas cantidades como si fueran equivalentes explica por qué algunas estimaciones de modernización, pese a parecer precisas, fallan por un factor entero.

He visto un conjunto pequeño de procesos por lotes tardar más en entenderse que una aplicación mucho mayor porque cada tarea tocaba el mismo registro de cliente mutable y cada excepción aparecía en un informe de control impreso. También he visto directorios intimidantes reducirse después de que un análisis de alcanzabilidad revelara años de variantes retiradas que aún se distribuían en el árbol de código. El recuento era correcto en ambos casos. La conclusión extraída de él era incorrecta.

La unidad útil no es una línea. Es una pieza de comportamiento que hay que descubrir, separar de sus dependencias, implementar y demostrar que es equivalente. Cinco medidas dejan al descubierto ese trabajo: profundidad de las decisiones, fan-in en los datos persistentes, proporción de código muerto, superficie de integración y proporción del comportamiento que solo se conoce por la salida de producción. Ninguna ofrece por sí sola un precio mágico. Juntas proporcionan una forma defendible del sistema.

El recuento de líneas mide inventario, no reescritura

Las líneas de código responden a una pregunta limitada: ¿cuánto texto clasificó como código fuente una regla de recuento concreta? El informe de Robert Park para el Software Engineering Institute, Software Size Measurement: A Framework for Counting Source Statements, dedica un esfuerzo considerable a definir con precisión las líneas físicas y las sentencias lógicas. Esa es la primera advertencia. Dos herramientas pueden discrepar antes de que nadie haya hablado de comentarios, copybooks generados, macros expandidas, SQL incrustado o varios miembros que contienen la misma rutina.

Incluso un recuento perfectamente normalizado mide inventario. Puede ayudar con la ingesta de un repositorio, el almacenamiento, el rendimiento del analizador o una primera comparación aproximada entre versiones escritas en el mismo lenguaje y con las mismas convenciones. No puede decir si 40 líneas implementan una asignación directa o una regla con estado y 16 caminos. No puede indicar si 4.000 líneas copiadas están activas. Tampoco puede revelar que una sola asignación a una columna de estado modifica ocho tareas posteriores.

El lenguaje también distorsiona el denominador. Las declaraciones de datos de COBOL pueden hacer que el diseño de un registro parezca muy grande. APL o SQL pueden expresar bastante comportamiento con unas pocas sentencias. El Java generado puede añadir miles de métodos de acceso repetitivos. Una relación basada en líneas trata implícitamente todo ello como unidades de pensamiento equivalentes. No lo son.

No intentes arreglarlo aplicando una tabla de conversión entre lenguajes, como si una línea de COBOL equivaliera a un número determinado de líneas de Go. Esa recomendación sigue siendo popular porque produce rápidamente una hoja de cálculo y se parece a la planificación histórica de productividad. Falla en una modernización porque la arquitectura de destino no debería conservar la forma textual del origen. Un copybook compartido puede convertirse en un esquema y clientes generados. Veinte programas por lotes casi idénticos pueden convertirse en un servicio con configuración. Un cálculo denso puede seguir siendo denso en Rust porque son las matemáticas, no la sintaxis de origen, las que determinan el trabajo.

Mantén el recuento de líneas en la evaluación, pero etiquétalo con honestidad. Registra por separado las líneas físicas, las sentencias lógicas, las líneas generadas, los comentarios y las líneas duplicadas. Úsalas para describir el conjunto de código. Nunca dejes que su suma represente el esfuerzo de entrega o el riesgo del comportamiento.

La profundidad ciclomática muestra dónde cuestan las decisiones

La complejidad ciclomática cuenta los caminos independientes de un grafo de flujo de control. Thomas McCabe presentó la medida en su artículo de 1976, A Complexity Measure, con la expresión de teoría de grafos que suele escribirse V(G) = E - N + 2P. Es útil porque las obligaciones de prueba crecen alrededor de las decisiones y no de la presentación del código. La descripción tecnológica posterior del Software Engineering Institute también aporta una salvedad importante: un valor alto por sí solo no demuestra que un módulo sea arriesgado ni que deba rediseñarse.

Para evaluar un sistema heredado, la distribución importa más que la media del repositorio. Una media de seis puede describir un código uniforme o uno en el que la mayoría de las rutinas son triviales y unos pocos módulos de liquidación contienen cientos de caminos. Esos sistemas necesitan planes distintos. Informa al menos de la mediana, el percentil 90, el máximo y la proporción de rutinas alcanzables que superan el umbral que el equipo revisará manualmente. Excluye las rutinas generadas y muertas de la distribución principal, pero indícalas a su lado.

La complejidad ciclomática y la profundidad ciclomática están relacionadas, pero no son idénticas. La complejidad cuenta caminos independientes. La profundidad registra hasta dónde se anidan las decisiones antes de que el control vuelva a un nivel más sencillo. Una tabla de despacho plana con 30 casos puede tener una complejidad alta y seguir siendo fácil de dividir. Cinco condiciones anidadas que dependen de mutaciones anteriores pueden tener menos caminos y, aun así, resultar más difíciles de explicar, probar y mover. Los equipos suelen confundir ambas medidas y luego se preguntan por qué un módulo con una puntuación aceptable consume todo el presupuesto de revisión.

Mide las dos por cada rutina alcanzable. Para la profundidad, cuenta las construcciones condicionales, bucles, excepciones y bifurcaciones propias del lenguaje que estén anidadas, después de expandir cualquier preprocesamiento que cambie el flujo de control. Después examina las rutinas que tengan valores altos en cualquiera de los dos ejes. La revisión debe responder cuatro preguntas: ¿depende la rama de un estado persistente? ¿Modifica datos que se usan más adelante en la misma transacción? ¿Está duplicada la condición en otro lugar? ¿Pueden las entradas registradas ejercer ambos resultados?

No sumes todas las puntuaciones de complejidad en un número gigantesco. Una suma premia la división de una rutina aunque no se reduzcan las decisiones reales del sistema y oculta su concentración. Usa un mapa de calor o una tabla ordenada que conserve la identidad del módulo, el contexto de llamada y los datos afectados. Una estimación de reescritura necesita saber dónde se acoplan las decisiones, no solo cuántos elementos de decisión encontró un analizador.

La complejidad también determina el trabajo de demostración. Una rutina con un único camino directo quizá solo necesite casos límite representativos. Una rutina muy anidada que seleccione precios, impuestos o resultados de elegibilidad necesita una matriz de casos observados y construidos. Eso no significa que cada camino matemático merezca su propia prueba. Hay caminos inviables y algunas combinaciones quedan excluidas por una validación anterior. Significa que la estimación debe financiar el trabajo de demostrar qué caminos importan, en vez de suponer que el recuento de líneas ya los recogió.

El fan-in de datos revela el radio de impacto real

El fan-in mide cuántos llamadores o flujos convergen en un componente. En los sistemas heredados, el fan-in a nivel de código es útil, pero el de la capa de datos suele ser una medida más reveladora. Cuenta los programas desplegados de forma independiente, tareas, pantallas, informes, procedimientos almacenados, transferencias de archivos y utilidades de operación que leen o escriben cada registro persistente, tabla, archivo, cola o área de datos compartida.

La diferencia entre fan-in de lectura y de escritura importa. Cincuenta informes que leen un libro mayor de solo adición generan trabajo de migración y compatibilidad, pero una única tarea de conciliación que escriba filas históricas puede imponer una restricción de transición mucho más dura. La propiedad mixta es peor: una transacción en línea actualiza un registro maestro, un lote nocturno lo corrige y una utilidad de operación puede sobrescribir un campo durante una excepción. Un diagrama de esquema muestra el objeto compartido. No muestra el orden, la autoridad ni el motivo operativo de esas escrituras.

Empieza con referencias estáticas y luego contrástalas con evidencias de ejecución. El análisis estático puede resolver SQL directo, nombres de archivo conocidos, uso de copybooks y llamadas literales. No detectará SQL dinámico, nombres construidos en variables, sustituciones del planificador, alias, exits ni accesos realizados por herramientas fuera del repositorio. Los registros de auditoría de la base de datos, los logs de tareas, los metadatos de mensajes y el historial del catálogo de archivos revelan parte de ese fan-in ausente. Las entrevistas pueden añadir utilidades de operación, pero trata los recuerdos como una pista hasta que la evidencia los confirme.

Ordena los activos de datos por algo más que el número bruto de referencias. Separa lectores y escritores, acceso en línea y por lotes, y actualizaciones síncronas y diferidas. Registra si el límite de una transacción abarca varios activos. Marca los campos cuyo significado cambia según el programa, como un estado vacío interpretado como «pendiente» por una tarea y como «no aplicable» por otra. Esos conflictos semánticos generan más trabajo de reescritura que una tabla limpia con muchos lectores normales.

Un registro práctico de fan-in puede ser compacto:

asset,readers,writers,execution_modes,transaction_peer,observed
CUSTOMER-MASTER,14,4,online|batch,ADDRESS-HISTORY,yes
RATE-CONTROL,6,1,batch,none,no
CLAIM-QUEUE,3,3,online|operator,PAYMENT-FILE,partial

La última columna es intencionada. Una referencia estática y un acceso observado son afirmaciones distintas. Conserva ambas. Cuando una estimación las mezcla, una referencia no ejecutada puede inflar el alcance mientras desaparece un acceso dinámico que no se vio.

Un fan-in alto no significa automáticamente «reescribir esto primero». A menudo significa lo contrario. Un activo de datos muy compartido puede necesitar un límite de compatibilidad explícito, una transferencia gradual de propiedad o un periodo de convivencia entre componentes antiguos y nuevos. La medida cambia la secuencia porque muestra dónde una modificación localmente correcta aún puede romper el sistema.

El código muerto cambia el denominador

La proporción de código muerto es la parte del conjunto que no puede ejecutarse en la configuración de producción definida. Debería reducir el alcance de implementación, pero solo después de que el equipo demuestre por qué está muerto. Eliminar un directorio porque nadie lo recuerda no es un análisis.

Usa tres etiquetas. El código inalcanzable no tiene ningún camino desde un punto de entrada configurado. El código no observado tiene un camino posible, pero no se ejecutó durante el periodo de observación. El comportamiento retirado cuenta con una decisión respaldada por su propietario de que el reemplazo no lo conservará. Estas etiquetas no pueden sustituirse entre sí. La documentación de IBM para identificar código COBOL inalcanzable dice expresamente que el resultado procede de un análisis estático y no refleja la ruta real de ejecución. Esa limitación explica por qué las evidencias estáticas y dinámicas deben permanecer separadas.

La configuración define la alcanzabilidad. Un módulo que no se usa en la planificación de los días laborables puede ejecutarse en el cierre trimestral. Una transacción CICS puede estar deshabilitada en una región y activa en otra. Los miembros JCL pueden seleccionarse mediante variables del planificador. Un ejecutable de escritorio puede cargar un complemento mencionado en un archivo de configuración local que nunca llegó al control de versiones. Construye el conjunto de puntos de entrada a partir de planificaciones de producción, definiciones de transacciones, manifiestos de despliegue, procedimientos de comandos, tareas registradas y manuales de operación, no solo a partir de un grafo de llamadas arraigado en el programa principal obvio.

Después calcula varias proporciones: sentencias estáticamente inalcanzables, sentencias alcanzables pero no observadas, sentencias alcanzables duplicadas y comportamiento aprobado para su retirada. Asigna a cada una un nivel de confianza y una referencia de evidencia. La estimación solo debe excluir la parte retirada. El código inalcanzable con una configuración incierta debe ir a una cola de resolución, mientras que el código no observado aún necesita pruebas dirigidas o una decisión de negocio.

El código muerto puede contener pistas útiles. Una rama antigua puede explicar la codificación de un campo o el diseño de un informe que sobrevive en otro lugar. Conserva el código fuente y el registro del análisis aunque el sistema nuevo omita ese comportamiento. El error consiste en pagar por traducir rutinas muertas como si fueran requisitos. El error opuesto consiste en borrarlas antes de que el equipo haya entendido los contratos activos que crecieron a su alrededor.

La superficie de integración se cuenta por contratos

Una integración no es una sola caja en un diagrama de arquitectura. Es un contrato con transporte, forma de los datos, regla temporal, comportamiento ante errores, límite de propiedad, mecanismo de seguridad y procedimiento de recuperación. Cuenta esos contratos y luego mide cuánto difieren entre sí.

Un único archivo nocturno de ancho fijo puede costar más de reproducir que diez endpoints HTTP corrientes. El archivo puede exigir un nombre exacto, página de códigos, longitud de registro, orden de clasificación, total de control, ventana de llegada, convención de repetición y confirmación manual. Un receptor puede analizar bytes de relleno no documentados. Nada de eso aparece en un recuento de líneas. Gran parte quizá ni siquiera aparezca en el programa emisor porque el planificador, el producto de transferencia y el procedimiento del operador llevan parte del comportamiento.

Inventaría cada borde externo y cada borde interno que cruce un límite de propiedad o despliegue. Incluye bases de datos de otro equipo, archivos entrantes y salientes, colas, llamadas a procedimientos remotos, protocolos de terminal, correo electrónico, salida de impresora, proveedores de identidad, interfaces de hardware, hojas de cálculo usadas como plantillas de importación y entregas manuales activadas por un informe. No agrupes cinco archivos como «flujo del socio» si tienen planificaciones o tratamiento de errores diferentes.

Para cada contrato, registra dirección, protocolo, ubicación del esquema, frecuencia, patrón de picos, orden, idempotencia, regla de reintento, tiempo de espera, autenticación, cifrado, productor, consumidor, entorno de pruebas y una muestra capturada de producción. Desconocido es un valor legítimo. También es trabajo. Una celda vacía nunca debería convertirse implícitamente en la suposición de que el valor predeterminado de la plataforma de destino coincidirá.

La superficie de integración tiene dos puntuaciones útiles. El número de contratos mide su amplitud. La novedad de los contratos mide cuántos mecanismos diferentes debe reproducir o sustituir el equipo. Veinte archivos que comparten un generador y un protocolo de confirmación pueden formar una familia de implementación. Cuatro interfaces que usan una cola de mainframe, un flujo de control de impresora, una integración propietaria de automatización de escritorio y un recurso compartido montado manualmente crean cuatro problemas de descubrimiento y prueba.

Presta especial atención al comportamiento negativo. Los consumidores pueden depender de un archivo vacío, un código de retorno concreto, un reintento retrasado, una entrega duplicada o la ausencia de una fila. Las muestras del camino feliz rara vez capturan esos contratos. Recopila registros de fallos y de repeticiones. Pregunta a los operadores qué hacen cuando no llega el artefacto esperado. Su acción suele formar parte del sistema aunque ningún compilador pueda verla.

La salida de producción puede ser la única especificación

Algunos comportamientos heredados solo existen en lo que emite producción. El código los calcula y los usuarios y sistemas posteriores dependen de ellos, pero ningún requisito vigente los explica. Esa brecha merece una medición propia porque cambia el trabajo de descubrimiento y verificación.

Cuenta primero las superficies de comportamiento: respuestas de API, cambios en bases de datos, archivos, mensajes, campos de pantalla, informes impresos, registros de auditoría, códigos de retorno, eventos temporales y avisos para operadores. Para cada superficie, clasifica la fuente de la especificación como documentación vigente, pruebas ejecutables, inferencia del código, confirmación de un especialista u observación de producción. Pueden aplicarse varias fuentes. La categoría peligrosa es «solo producción»: ningún documento o prueba fiable define el resultado y las personas juzgan la corrección comparando lo que produce el sistema antiguo.

«Solo producción» no tiene por qué seguir siendo misterioso. Captura pares representativos de entrada y salida, normaliza los campos volátiles, como las marcas de tiempo o los identificadores generados, y reproduce las entradas en el sistema antiguo bajo condiciones controladas cuando sea posible. Conserva el orden, el redondeo, la codificación, el tratamiento de espacios y la salida de errores antes de que alguien los «limpie». Un espacio final puede ser irrelevante en un informe y marcar el límite de un campo en otro.

Mídelo como una proporción ponderada, no como un número bruto de salidas. Da mayor peso a las salidas que mueven dinero, cierran libros, controlan trabajo físico, satisfacen una revisión de auditoría o alimentan otro sistema. Registra también la cobertura: cuánta variedad de entradas, calendario y errores contiene el tráfico capturado. Treinta días de solicitudes en línea pueden cubrir los caminos ordinarios y omitir el cierre anual. Un millón de comprobaciones de salud repetidas apenas aporta conocimiento sobre el comportamiento.

Aquí se encuentran la estimación y la verificación. Si el comportamiento está documentado y probado, el equipo de reemplazo puede implementar contra un contrato explícito. Si solo vive en la salida, debe descubrir el contrato, construir un comparador, clasificar las diferencias y obtener una decisión cuando el comportamiento antiguo sea incoherente. Ese trabajo existe aunque la rutina responsable solo tenga 80 líneas.

El tráfico registrado es evidencia, no un oráculo. Puede contener resultados incorrectos, defectos enmascarados, datos confidenciales y dependencias accidentales. Aplica controles de acceso y minimización, identifica los campos que no pueden salir del perímetro del cliente y pide a un propietario responsable que determine si una diferencia revela una regresión o un defecto antiguo que conviene retirar. La paridad automatizada sin ese proceso de decisión puede conservar los errores con una precisión impresionante.

Un perfil de tamaño mantiene separados riesgos distintos

Combina las mediciones en un perfil, no en una puntuación ponderada universal. Un solo número parece cómodo, pero destruye la información necesaria para elegir la arquitectura, secuenciar el trabajo y fijar la profundidad de verificación. Dos sistemas pueden recibir la misma puntuación aunque uno tenga una lógica de decisiones concentrada y el otro tenga código sencillo detrás de decenas de interfaces frágiles.

El perfil debe contener varios registros vinculados para la configuración de producción que se evalúa. El registro del conjunto de código contiene sentencias lógicas y proporciones por lenguaje, generación, duplicación y comentarios. El registro de decisiones contiene complejidad y anidación máxima, con mediana, percentil 90, máximo y puntos calientes alcanzables. El registro de concentración de datos contiene lectores y escritores por activo, otros activos de la misma transacción, modos de ejecución y accesos observados.

El registro de alcanzabilidad contiene las proporciones retiradas y sin resolver junto a las raíces estáticas, la ventana de ejecución y las decisiones de propietarios. El registro de contratos contiene interfaces distintas, familias de mecanismos, muestras de fallos y acceso a pruebas. El registro de evidencia de comportamiento contiene superficies ponderadas conocidas solo por producción, variedad de entradas capturadas, vacíos de calendario y el propietario responsable de decidir sobre diferencias. Mantén identificadores estables entre esos registros para que un revisor pueda pasar de un punto caliente a su evidencia sin emparejar descripciones a mano.

Versiona el perfil con los puntos de entrada, el conjunto de configuraciones, el periodo de observación, las versiones de herramientas y las exclusiones. De lo contrario, un análisis posterior puede parecer contradictorio cuando simplemente usó otras raíces del planificador o expandió los copybooks de manera diferente.

Usa bandas en lugar de una precisión falsa. Para la profundidad de decisiones, una banda puede distinguir rutinas ordinarias, puntos calientes de revisión y candidatas a descomposición. Para el fan-in de datos, puede separar activos aislados, modelos de lectura compartidos y propiedad de escritura disputada. Define cada banda en términos de una acción. Una celda roja debería significar «requiere un límite de compatibilidad y revisión del propietario», no «parece peligrosa».

El perfil también hace visible la incertidumbre. Marca si cada valor procede de análisis estático, observación en ejecución, registros de configuración o una decisión del propietario. Adjunta una referencia de evidencia y un nivel de confianza. Una regla de reintento desconocida y un recuento exacto de 200.000 líneas no deberían promediarse para obtener una puntuación tranquilizadora. La incógnita puede dominar el riesgo de transición.

Guarda las observaciones sin procesar junto a los valores derivados. Si un analizador informa de 26 llamadores y los registros de ejecución muestran 19, conserva ambas cifras y el estado de conciliación. Un trabajo posterior quizá demuestre que cinco llamadores pertenecen a planificaciones retiradas y que dos llamadas son alias dinámicos. Sustituir la cifra anterior destruye el rastro de auditoría y hace que la estimación parezca más segura de lo que llegó a ser la evaluación. La misma regla se aplica a la normalización de la complejidad, la detección de duplicados y la cobertura del tráfico.

Para estimar, convierte los elementos del perfil en paquetes de trabajo con condiciones de finalización observables. Un punto caliente de decisiones está completo cuando se aceptan su tabla de comportamiento, su implementación y sus casos de paridad. Un activo de datos está completo cuando se han considerado la propiedad, el comportamiento transaccional, la regla de migración y los consumidores. Una integración está completa cuando los caminos satisfactorios, fallos, reintentos y traspaso operativo funcionan en el entorno de destino. Una superficie conocida solo por producción está completa cuando los casos capturados coinciden o un propietario aprueba cada diferencia intencionada.

Así los multiplicadores permanecen locales. Una rutina de alta complejidad afecta al paquete de trabajo al que pertenece. No hace de forma arbitraria que cada transferencia de archivo y pantalla cueste el doble. Un informe mal especificado añade trabajo de descubrimiento y comparación a esa salida. No infla el código muerto. Los factores locales son más fáciles de cuestionar, revisar y verificar.

Estima unidades de evidencia, no líneas de reemplazo

Una vez creado el perfil, estima unidades de comportamiento conservado y de demostración. Empieza por las capacidades alcanzables y sepáralas cuando difieran la propiedad de los datos, los contratos de integración o los métodos de verificación. El número de líneas de destino es desconocido y casi irrelevante. El trabajo de arquitectura puede eliminar repetición, combinar programas o sustituir lógica procedimental auxiliar por funciones de la plataforma.

Para cada unidad, estima cuatro actividades: descubrimiento, diseño e implementación del destino, construcción de evidencias y aceptación. El descubrimiento incluye resolver llamadas dinámicas, diseños ausentes, propiedad y reglas conocidas solo por producción. La construcción de evidencias incluye captura de tráfico, datos de prueba, comparadores y casos de error esperados. La aceptación incluye la revisión de diferencias por alguien autorizado para decidir si el comportamiento antiguo sigue siendo obligatorio.

No ocultes la incertidumbre dentro de una cifra de esfuerzo mayor. Mantén un registro de supuestos con una prueba y un propietario. «RATE-CONTROL no tiene escritores interactivos» se puede comprobar con registros de acceso y una revisión de operadores. «Todas las tareas de cierre trimestral aparecen en la exportación del planificador» se puede contrastar con el historial de ejecución. Resuelve pronto los supuestos de gran impacto porque pueden cambiar los límites, no solo las horas.

Una comparación práctica deja clara la idea. El sistema A tiene 700.000 sentencias lógicas, un 45 por ciento de comportamiento retirado con aprobación, profundidad de decisiones moderada, dos centros de datos con muchas escrituras y seis familias de integración con casos de error capturados. El sistema B tiene 180.000 sentencias, casi ningún comportamiento retirado, varias rutinas de liquidación muy anidadas, nueve activos de datos en disputa y salidas cuyas reglas solo existen en informes de cierre mensual. Una estimación por líneas hace que A parezca casi cuatro veces mayor. Un perfil de comportamiento puede mostrar razonablemente que B lleva más trabajo de descubrimiento y aceptación. El perfil no demuestra el precio. Muestra por qué el precio debe seguir la evidencia en lugar del volumen de texto.

Este método también hace comparables las estimaciones de los proveedores. Pide a cada licitador sus puntos de entrada contados, clasificación de alcanzabilidad, distribución de complejidad, activos con fan-in alto, inventario de contratos, superficies conocidas solo por producción y supuestos sin resolver. Si uno presenta un multiplicador de líneas y otro identifica los nueve activos con escritores competidores, puedes ver quién ha examinado el sistema y quién ha puesto precio a un relato.

CodeHero lee en paralelo todo el árbol de código y después verifica el comportamiento modernizado con un sistema de paridad frente al tráfico de producción registrado. Esa combinación trata la escala del conjunto de código y la demostración del comportamiento como problemas separados. La distinción importa más que cualquier afirmación sobre cuántas líneas puede ingerir una herramienta.

La aprobación debe seguir el rastro de medición

Una estimación creíble de un sistema heredado permite que otro ingeniero rastree el alcance hasta la evidencia. Debes poder seleccionar cualquier paquete de trabajo importante y encontrar los puntos de entrada que llegan a él, las decisiones que contiene, los datos que lee o escribe, los contratos que atraviesa y los ejemplos de producción que definen la aceptación.

Antes de aprobar un plan, pregunta qué excluyó el evaluador y bajo la autoridad de quién. Pregunta qué periodos de ejecución cubrió la observación, incluidos los caminos de cierre trimestral o anual. Pide los mayores puntos calientes de complejidad en lugar de una media. Pregunta qué activos de datos tienen varios escritores. Pregunta qué interfaces carecen de muestras de fallos. Pregunta qué salidas no tienen otra especificación que producción. Las respuestas directas pueden incluir incertidumbre. La confianza imprecisa debería detener la aprobación.

El recuento de líneas sigue teniendo sitio en la primera página porque describe el material analizado. Debería aparecer junto a la proporción de código muerto y generado, no por encima de las medidas que describen el comportamiento. La estimación debería cambiar cuando aparezca un escritor oculto, cuando una tarea supuestamente muerta resulte activa o cuando una salida carezca de ejemplos suficientes. Si solo cambia cuando alguien encuentra otro directorio de archivos fuente, el modelo está midiendo inventario y llamándolo ingeniería.

El primer entregable por el que merece la pena pagar es el perfil de tamaño versionado y su registro de evidencias. Crea una base concreta para las decisiones arquitectónicas y comerciales, y proporciona al equipo de reemplazo una definición de terminado que resiste el contacto con producción.